ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
_whitelogger has joined #picolisp
aw- has quit [Quit: Leaving.]
orivej has joined #picolisp
_whitelogger has joined #picolisp
<DKordic> aw-: http://man.he.net/man7/fifo . open as non-blocking exactly when needed and as write-only eor read-only.
aw- has joined #picolisp
<DKordic> aw-: http://man.he.net/man7/fifo . open as non-blocking exactly when needed and as write-only eor read-only.
<DKordic> ""read""ers will ""poll"" after non-blocking ""open"", and ""write""rs will check for ""errno(3)"" ""ENOXIO"" after ""open"".
<Regenaxer> Right. As we discussed yesterday
<Regenaxer> Same for non-named pipes
<Regenaxer> The pil kernel does this for sibling processes
<Regenaxer> nonblock, poll()
<Regenaxer> The hard thing is what to do with the *data* if the reader is not ready
<Regenaxer> so the parent maintains growing buffers
<Regenaxer> and if the reading end closes (the sibling terminated), the buffers are discarded
<Regenaxer> (the whole 'child' structure)
<DKordic> Well ""read""er should signal (by convention) that it is ready by opening for read-only.
<Regenaxer> it *is* open already
<DKordic> Which means the ""read""er is ready?
<Regenaxer> no
<Regenaxer> well, it is ready until the pipe is full
<Regenaxer> PIPE_BUF
<DKordic> Then it could signify it by closing the ""fifo"?
<Regenaxer> poll() indicates that the *write* would not block
<DKordic> s/"?/""?
<Regenaxer> No, why should it close? We don't want to lose data, no?
<Regenaxer> The *writer* must delay sending until the reader is ready (or gone)
<Regenaxer> See waitFd in pil
<Regenaxer> pil32, pil64 or pil21
<DKordic> Yes, and I am saying that ""read""er _could_ signify that it is not _ready_ by closing the fifo. Will it be useful?
<Regenaxer> I do not think so. The writer has to wait then.
<Regenaxer> poll() and write() with nonblocking handles all that
<Regenaxer> no need for a signal
<DKordic> Sorry, I am not speaking about the pil "tell" mechanism, but an application speciffic fifo.
<Regenaxer> yes. I just gave pil as an example for an implementation
<Regenaxer> for completely transparent pipes
<Regenaxer> the application logic does not care
<Regenaxer> just sends to the pipes what it needs to
<DKordic> I do not mean ""signal(7)"", only ""errno(3)"".
<Regenaxer> so we are back at write()
<Regenaxer> returns EAGAIN
<Regenaxer> see the sources of wrChild() in pil
<Regenaxer> All this is needed because the kernel buffers for (named or not) pipes are so small
<Regenaxer> PIPE_BUF size
<Regenaxer> so you must maintain buffers to avoind blocking
<Regenaxer> (unless you can simply discard the data)
<DKordic> How will ""read""er signify that it is _ready_? My 2 cent sugestion is by ""open""ing the fifo.
<Regenaxer> No, it is really simple
<Regenaxer> write() returns -1 and errno is EAGAIN
<aw-> DKordic: thanks
<Regenaxer> meaning that the nonblocking write did not succeed
<Regenaxer> DKordic, sure, opening is the premisse
<aw-> i'm no sure what i did yesterday, it looked like the read was blocking
<aw-> anyways i deleted all the code but i couldn't debug it correctly
<Regenaxer> the fd must be nonblocking for the above
<aw-> i use mkfifo to create the named pipe
<aw-> is tthere an option to make it non-blocking?
<aw-> or i need (native) ?
<Regenaxer> yeah
<Regenaxer> (open / does not set to nonblock
<aw-> right right
<aw-> yeahhhhh
<aw-> that's what i was looking for yesterday
<aw-> (out) uses (open), correct?
<Regenaxer> not directly
<Regenaxer> it calls open()
<aw-> ahh wow there's a LOT of options for open()
<Regenaxer> T
<Regenaxer> I set nonblocking with fcntl()
<Regenaxer> In pil21 it is the easiest
<Regenaxer> you can call nonBlocking() with 'native'
<Regenaxer> needs only a FD
<Regenaxer> (let Fd (open ..) (%@ "nonBlocking" Fd) ...
<Regenaxer> but it does not help
<Regenaxer> there is no interface to poll() or select() for writing on the Lisp level :(
<Regenaxer> *Run only handles reading and timeouts
<aw-> i can just use (native @ "open" ...)
<Regenaxer> yes, but you need the C constants
<aw-> (native "@" "open"...
<aw-> ah, for O_NONBLOCK etc?
<Regenaxer> yes
<Regenaxer> no real problem
<Regenaxer> just portability
<aw-> pil64 also has nonblocking
<Regenaxer> yes, but not directly callable by 'native'
<aw-> ohhh
<Regenaxer> it is all asm
<aw-> so that's a pil21 feature
<DKordic> As we can see ""portability"" is an excuse of C(11) programmers.
<aw-> ahahahaha
<Regenaxer> Anyway the problem is that (poll ..) does not handle writes
<aw-> yes, that too
<Regenaxer> What was the purpose? Avoid blocking when writing to the pipes, right?
<aw-> (and (poll *Fd) (out @ ...)) would be nice
<aw-> yes exactly
<Regenaxer> The easiest is using the internal pil mechanism
<aw-> is there a way to check if an *Fd (pipe) has a reader?
<Regenaxer> use a sibling process
<Regenaxer> yes
<Regenaxer> write gives EAGAIN
<Regenaxer> see above
<aw-> ah yes, correct
<aw-> but only in NONBLOCKING mode
<Regenaxer> right
<aw-> i read that yesterday before dozing off
<Regenaxer> As I said, the problems start *after* you get EAGAIN
<Regenaxer> what to do on the sender`s side?
<Regenaxer> you must buffer the data
<Regenaxer> otherwise you are "blocked" again
<Regenaxer> Pil RPC handles that
<Regenaxer> So I would use a separate process
<Regenaxer> it gets the data via 'tell' and then may block without harm
<Regenaxer> the sender will not block
<aw-> no no, i can handle it my own way
<Regenaxer> good
<aw-> if I get EGAIN, i can choose what to do
<aw-> dont need picolisp to decide for me
<aw-> just "knowing" the write fail would be sufficient
<aw-> failed*
<Regenaxer> And discard the data?
<Regenaxer> losing the data is OK?
<aw-> yes
<aw-> why lose the data? i have the data
<Regenaxer> yes, but you get EAGAIN if the pipe is full, e.g. because the reveiver is busy
<Regenaxer> then you block
<Regenaxer> it is the *only* reason for the blocking
<Regenaxer> the receiver is not fast enough to handle the data
<aw-> i see
<Regenaxer> otherwis no worry about the pipe
<aw-> yes i guess the only real solution is to have a buffer
<Regenaxer> or have the sender block for a moment
<Regenaxer> in worst cases
<Regenaxer> The pil kernel cannot allow to block
<Regenaxer> sender may be in a DB commit
<Regenaxer> that's why all the trouble
<aw-> maybe i'll use POSIX message queues with librt.so
<aw-> it's actually exactly what i want to do
<Regenaxer> ok
<Regenaxer> They have bigger buffers?
<aw-> instead of trying to bend picolisp code for something not obvious
<aw-> no they have very small buffers by default
<aw-> you have to change the settings to get larger buffers
<aw-> i think max is 16MiB, but the default is like 256 Bytes or something ridiculous
<aw-> and linux/freebsd only
<aw-> a few limitations, but actually my use-case is exactly that: extremely small/lightweight message queue
<aw-> perhaps that could be my first pil21 (native) project ;)
<Regenaxer> Yeah
<aw-> i like old stuff that's built-into linux kernel by default, much less headache than these big buggy softwares/protocols like MQTT
<DKordic> Regenaxer, beneroth: Please try http://www.netsurf-browser.org/ ! It seems to be as efficient as w3m! A GUI alternative. Doesn't depend on WebKit or something like that.
<Regenaxer> DKordic, does it support VI-style key bindings? Does it run in Termux?
<Regenaxer> aw-: It is really a bad design that the buffer size is not dynamic
<Regenaxer> you either waste space or lose data
<tankf33der> morning.
<Regenaxer> Hi tankf33der!
<aw-> sorry, default is 8KB
mtsd has joined #picolisp
mtsd_ has joined #picolisp
<DKordic> Regenaxer: Not in Terminal, it has GUI. No vi key bindings that I am aware of. Key bindings seems to be like FireFox.
<Regenaxer> Not Terminal, but Termux. My working environment
mtsd has quit [Ping timeout: 240 seconds]
<Regenaxer> also VI bindings are essential
<DKordic> tankf33der: What is the latest source code of Tiny C Compiler, https://repo.or.cz/tinycc.git ?
<DKordic> Good morning everyone.
<tankf33der> DKordic: correct, use it
<Regenaxer> yeah, good morning :)
rob_w has joined #picolisp
<DKordic> Regenaxer: :) Now I remeber ""Termux"" is an ""Android app"". I confused it with ""tmux"". https://xkcd.com/1668/ !!
<DKordic> tankf33der: Thank You.
<Regenaxer> Yeah. And in fact I use tmux inside termux :)
mtsd has joined #picolisp
mtsd_ has quit [Ping timeout: 240 seconds]
<aw-> Regenaxer: in pil64, shouldn't 'src64/sysdefs' be compiled automatically with 'make' ? or has that changed now?
<Regenaxer> I don't remember well. I think it is not needed for normal pil64
<Regenaxer> it uses src64/sys/*.l
<Regenaxer> only for 'emu' sysdefs is used
<aw-> yes i saw
<Regenaxer> (or initially to create src64/sys/*.l)
<aw-> is there another way to obtain those values through (native) ?
<Regenaxer> native does not help. We need to parse the include files
<Regenaxer> can be done with gcc -E perhaps
<aw-> oh ok
<aw-> we discussed this 2 years ago
<Regenaxer> but the easiest is to build a C program
<aw-> when i wanted to create an atomic file
<Regenaxer> T
<aw-> but i was wondering why on this system @src64/sysdefs wasnt there.. had to 'make sysdefs'
<Regenaxer> yeah, not in the targets
<Regenaxer> pil21 always builds it (for a different usage)
<aw-> ohh yeah you're right
<aw-> in @lib/sysdefs
<aw-> lovely
<aw-> not many values in there
<Regenaxer> yeah, not needed yet
<Regenaxer> only for pil21 itself
<Regenaxer> The idea is to create such files app-specific
<Regenaxer> for using them with 'sysdefs' in @lib.l
<aw-> how is it loaded?
<aw-> oh never mind, we discussed this already
<aw-> ;)
<Regenaxer> yeah, 'sysdefs' simply opens such a file
<Regenaxer> like in @lib/net.l
<aw-> right
<Nistur> mornin'
<Regenaxer> Hi Nistur
<Nistur> o7
<beneroth> DKordic, thanks for the hint! Will look into it!
<beneroth> Ahoy Nistur!
<beneroth> Hi Regenaxer, aw- :)
<mtsd> Hi everyone
<Regenaxer> Hi beneroth!
<beneroth> Hey mtsd :)
<Regenaxer> Hi mtsd!
<mtsd> :)
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #picolisp
<Regenaxer> Hmm, looks like the pil21 base system in done
<Regenaxer> DB not really tested yet
<Regenaxer> but works basically
<Regenaxer> Probably still lots of bugs
<tankf33der> what i need to get (rel) function in pil21 ?
<Regenaxer> I have not yet put @lib/btree.l and @lib/db.l into pil21/lib/
<tankf33der> ok.
<Regenaxer> First wanted to make sure plain external symbols work
<Regenaxer> Soon :)
<Regenaxer> new, zap, commit, rollback, dbck seem to work
<Regenaxer> not sure if correct in all situations
<tankf33der> db tests from pil64 passed.
<Regenaxer> What do they involve?
<tankf33der> id, new, mark, dbck, lieu, commit, rollback.
<Regenaxer> wow, thats cool
<Regenaxer> I did not expect that it really works
<Regenaxer> good news indeed
<Regenaxer> I just coded without testing because all these functions only work together
<Regenaxer> Then I did some singular tests and fixed some errors today
<Regenaxer> But I thought there must be more
<tankf33der> i cant test db, i dont understands it. i have several trivial tests and 1 complex. lets see.
<Regenaxer> ok
<aw-> Regenaxer: how to access 'errno' with (native) ?
patrixl has quit [Read error: Connection reset by peer]
<aw-> my call returns -1
<Regenaxer> yeah, there is no way
<aw-> but according to the docs 'errno' is set with the error
<Regenaxer> errno is not a global
<Regenaxer> usually highly system dependent
<aw-> i tried (native "@" "errno" 'I)
patrixl has joined #picolisp
<aw-> it segfaults
<Regenaxer> pil21 has a glue function
<Regenaxer> yes
<aw-> hmmm
<Regenaxer> errno was never a *function*
<Regenaxer> In ancient Unix it used to be a global
<Regenaxer> But all Unixes handle it as a macro now
<Regenaxer> No way to access by a native call
<aw-> i see
<Regenaxer> See what pil21 does
<Regenaxer> it has a Lisp level function (errno)
<Regenaxer> It boils down to a function nErrno() in src/lib.c
<Regenaxer> So the target platform's C compiler expands the macro in a proper way
<Regenaxer> If you need to use pil64 for now,
<Regenaxer> let me check
<Regenaxer> You can call with 'native' the right function from sys/<arch>.code.l
<Regenaxer> (native "@" "errno_A" 'I) *might* work (never tried)
<Regenaxer> I looked in sys/x86-64.linux.code.l
<Regenaxer> Yes, 'errno_A' is in all sys/<arch>.code.l
<aw-> oh
<Regenaxer> You can see that it is different for each version
<aw-> it works!
<Regenaxer> Cool!
<aw-> ok i will use this
<aw-> and perror
<Regenaxer> great
<Regenaxer> Later with pil21 it will be more portable
<aw-> looking forward to it
<aw-> hmmm
<aw-> (native "@" "perror" 'S)
<aw-> returns garbage: String
<aw-> it returns more than a string
<aw-> oh.. it doesnt return anything
mtsd has quit [Quit: Leaving]
<Regenaxer> head, void
<aw-> i look the man page
<Regenaxer> Yep, void perror(const char *s);
<aw-> ok ok
<aw-> i use strerror() instead
<aw-> thanks!
<Regenaxer> great
<Regenaxer> :)
orivej has quit [Ping timeout: 265 seconds]
<aw-> haven't worked with (native) in so long
<aw-> i don't remember anything haha
<Regenaxer> :)
<Regenaxer> Now I released PilBox for API 29
<Regenaxer> No more starting of dynamically loaded bin/picolisp, bin/ssl etc
<Regenaxer> So I do no longer support 32-bit mobiles via 'emu'
<aw-> wow
<aw-> almost everything is 64-bit nowadays
<Regenaxer> yeah
<Regenaxer> (which is a good thing)
<aw-> good riddance
<aw-> exactly
<Regenaxer> But I hate restricting Android more and more
<aw-> i can still see the benefit of 8-bit and 16-bit systems, but 32-bit is useless
<Regenaxer> true
<Regenaxer> A slight cost advantage in hardware perhaps
<aw-> hmmm
<aw-> Regenaxer:
<aw-> we have (errno)
<aw-> i just found it in the docs
<Regenaxer> oh
<Regenaxer> in pil64 too?
<Regenaxer> haha!
<Regenaxer> Sorry
<aw-> yes
<aw-> hahahaha
<Regenaxer> makes sense
<Regenaxer> Seems I already garbage collected pil64 in my memory
<aw-> oops
<aw-> you didn't implement it in pil21?
<Regenaxer> No, it is there
<aw-> ah yes, returns 0 when no error
<Regenaxer> That's why I said the issue will be no problem in pil21
<Regenaxer> I think it always returns the last value
<aw-> forgot it was also in pil64
<Regenaxer> Like in C
<Regenaxer> yeah
<aw-> how would you convert this argument to a struct: (list NIL (4 (N . 0) (N . 1) (N . 2) (N . 0)) 0 100 1024 0)
<aw-> struct mystuct { long a; long b; long c; long d; };
<aw-> is that correct?
<aw-> hmm i think that's wrong
<Regenaxer> yes (N . 0) is not good
<Regenaxer> just N is a long
<Regenaxer> (N . 4) would be long[4]
<aw-> right
<aw-> so the size of the struct is wrong too, should be 16 ?
<aw-> (list NIL (16 ..?
<Regenaxer> one long has 8 bytes, so 32
<aw-> hmm.. can I just do (list NIL (32 (N N N N)) ...?
<Regenaxer> and the init is wrong too
<Regenaxer> it is *bytes*
<aw-> ohhh
<Regenaxer> yes
<aw-> so 1024 is too big
<Regenaxer> no init then
<Regenaxer> yes, and needs more zeroes
<Regenaxer> lots of zeroes ;)
<aw-> right, 32 bytes
<Regenaxer> '(NIL (32 N N N N) . 0)
<Regenaxer> this would init all to zero
<aw-> i want to initialize some of them though
<Regenaxer> then use struct
<Regenaxer> 'struct'
<Regenaxer> allocated with malloc()
<Regenaxer> pil21 has a function for a local buffer
<Regenaxer> on the stack
<Regenaxer> no need for malloc/free then
<Regenaxer> Is used in @lib/net.l
<Regenaxer> (buf Addr sockaddr_in6 ...
<aw-> ok let me try some things
<Regenaxer> good
<aw-> Regenaxer: what's the advantage of using (struct) compared to just sending the arguments?
<aw-> i'm trying to send a simple struct like: struct mystuct { long a; long b; long c; long d; }; ... where a=0,b=1,c=2,d=0
<Regenaxer> You can fill in data, which is not possible with the above init bytes
<aw-> ohhhh
<aw-> ok
<aw-> can only provide 'fill' bytes
<Regenaxer> yeah
<Regenaxer> I think there is some explanation in doc/native.html in the distro
<aw-> same approach in pil21?
<Regenaxer> yes
<aw-> from native.html 'The CDR is ignored for input-only arguments, '
<Regenaxer> With some minor "improvements"
<aw-> got it
<Regenaxer> I used native extensively in pil21/lib/net.l
<Regenaxer> kind of first real usage
<Regenaxer> except for simple system calls
<Regenaxer> So in fact it might be a good idea if you test your code also in pil21
<aw-> you're using (struct) without calling malloc, how?
<aw-> yes i will test in pil21 once i get it working
<Regenaxer> In pil21 there is 'buf', which allocates on the stack
<Regenaxer> like a C automatic variable
<aw-> ahhh i see
<Regenaxer> a little faster I suppose
<Regenaxer> doc/ref is still missing though
<Regenaxer> but I think you know what to do
<aw-> yes no problem
<Regenaxer> best and first example is net.l :)
<Regenaxer> You can compare with pil32 src/net.c
<Regenaxer> should be analog
<aw-> ok
<aw-> ok good night, will continue tomorrow
<aw-> thanks for the help
aw- has quit [Quit: Leaving.]
rob_w has quit [Quit: Leaving]
orivej has joined #picolisp
orivej has quit [Remote host closed the connection]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
_whitelogger has joined #picolisp
<tankf33der> tests for @lib/math.l passed.
<Regenaxer> Thanks!
<Regenaxer> We are progressing fast :)