beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
tmpee has joined #picolisp
X-Scale has quit [Ping timeout: 250 seconds]
tmpee has quit [Ping timeout: 250 seconds]
X-Scale has joined #picolisp
seninha has quit [Remote host closed the connection]
_whitelogger has joined #picolisp
rob_w has joined #picolisp
<abu[m]> For example, what does this do?
<abu[m]> (tell 0 'tell *Pid ''msg ''*Variable)
<abu[m]> btw, this is the same as the now deprecated (boss 'tell *Pid ''msg ''*Variable)
<abu[m]> oops, wrong
<abu[m]> Better is (tell 0 'tell *Pid ''msg '(lit *Variable))
<abu[m]> Confusing indeed ;)
<tankf33der> pil's IPC unknown for me, never used.
<abu[m]> No big thing in fact
<abu[m]> Confusing here is more a general Lisp issue: What is evaluated where and when
<abu[m]> If we call (tell 0 'tell *Pid ''msg '(lit (foo arg)))
<abu[m]> Then the parent executes (tell 12345 'msg (lit (foo arg))) if 12345 is my PID
<abu[m]> So I get (msg '(x y z)) if (x y z) is the result of foo
<abu[m]> Thus 'msg' prints (x y z) locally
<abu[m]> I used this (or the old 'boss') quite often, but without redirecting to the current psh session
<abu[m]> (tell 0 'msg '(foo arg)) prints to the log fille
<beneroth> abu[m], thanks for the info! I think this is an improvement and making things easier
<abu[m]> ☺
<beneroth> I think I never actually used boss.l, but there were multiple times were I considered it. The functionality is needed for some cases.
<beneroth> I think I usually solved it than by queuing via the database for other reasons (logging/debugging/tracking)
<abu[m]> Exactly. I also used it less often than needed, cause boss.l had to be loaded before, and it creates named pipes etc.
<abu[m]> What I did by far most often is (boss 'load "app/lib.l") or so
<abu[m]> to update system files at runtime
<beneroth> the new functionality uses the normal pipes established anyway whenever (forking) ?
<abu[m]> Now it is (tell 0 'load "app/lib.l")
<abu[m]> yes, the normal family IPC
<beneroth> what was the reason for having explicit separate boss pipes before?
<abu[m]> 'tell' sends to the parent anyway
<abu[m]> The reason was that I thought it more tricky than it was :)
<beneroth> okay :)
<abu[m]> Normally the parent simply redirects the stream from the child to other child(ren)
<beneroth> that is the main reason for a lot of unrealized stuff everywhere :D
<abu[m]> I did not really think hard enough. In the end it was quite simple
<beneroth> yeah it just does message passing/dispatching
<abu[m]> T
<beneroth> so now it's just a kind of flag indicating that it's for the parent itself
<beneroth> well it's id 0 of course
<abu[m]> yes
<beneroth> elegant
<beneroth> weird you overlooked it before, now in hindsight :D
<beneroth> but completely understandable
<abu[m]> The parent just needed a short function to parse the PLIO from the child's data block
<abu[m]> Easier than expected ☺
<abu[m]> And I had to change the protocol a little. Zero meant "all children" internally
<abu[m]> Now "all children" is -1
<abu[m]> This required some changes, also in 'commit' and related places
<abu[m]> I hope I did not destroy something
<beneroth> ah yes, that is a breaking change
<beneroth> why not keeping 0 for broadcast and using -1 for parent?
<abu[m]> This would also be possible, but required more changes. And feels not so right
<abu[m]> The -1 is used only internally
<abu[m]> (tell 0 ... looks better
<abu[m]> somehow ;)
<beneroth> yeah I get you, it's more in line with id per process
<abu[m]> Perhaps 1 would have been good too. Analog to PID 1 for the Unix 'init' process
<abu[m]> Thus 1 will never be a picolisp process
<abu[m]> In total, zero is good. Zero and negative are optimal to check on the machine level anyway.
<abu[m]> Sigh. Google takes sooo long to accept the PentiKeyboard release
<abu[m]> I uploaded it to PlayStore on the 20th
<abu[m]> So it is now one week! It still says "your app is being processed".
<abu[m]> Ridiculous for a 50 KiB app
<abu[m]> It is always that Penti takes a few days, but never a full week until now
<abu[m]> And strangely PilBox always passes within 12 hours or so
<abu[m]> I would suspect that there is a lot more to check in PilBox than in Penti
genpaku has quit [Remote host closed the connection]
genpaku has joined #picolisp
<tankf33der> Tried s390x platform on newer llvm system, the same issue as before.
<tankf33der> llvm 13 -> 15
<abu[m]> The include of ppoll() issue?
<abu[m]> or opaque pointers?
<tankf33der> ext:Snx issue
<abu[m]> ah
<abu[m]> It was something with the names of shared libs, right?
<abu[m]> IIRC it does not find the lib *file*
<abu[m]> strace
<abu[m]> Some naming convention for shared libs?
<abu[m]> strace or ltrace will show that dlopen() fails
<abu[m]> hmm, no, it can also be dlsym(), i.e. naming of symbols in the lib
<tankf33der> open("/root/pil21/lib/ext", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<abu[m]> indeed
<abu[m]> I think Makefile creates it as @lib/ext.so
<tankf33der> ext.so
<abu[m]> and sharedLib in src/main.l accesses it as (strcpy (ofs Q Len) ($ ".so"))
<abu[m]> So why is the .so gone?
<abu[m]> (dlOpen Q)
<abu[m]> Can you put a printf() into @src/lib.c?
<abu[m]> Print 'lib' before the line return dlopen(lib, ...
andyjpb has joined #picolisp
<tankf33der> i can
<abu[m]> Thanks!
<abu[m]> Perhaps dlopen() strips off the .so
<abu[m]> Are all shared libs without .so perhaps?
<tankf33der> i see ext.so and ht.so in @lib
<abu[m]> I mean in /usr/lib
<abu[m]> the system libraries without .so, so that dlopen() strips it off (just suspecting)
<tankf33der> i see many so files in usr lib
<abu[m]> ok
<tankf33der> lib:'/root/pil21/lib/ext'
<abu[m]> Ah!
<tankf33der> so dlopen received without so
<abu[m]> So the pil code is wrong. Concat of ".so" failed. Strange!
<tankf33der> we already checked concat on this platform
<abu[m]> Was this a big endian arch?
<tankf33der> and saw ext and so and wrong result of concat
<abu[m]> We already fixed some things
<tankf33der> this is big endian system
<abu[m]> I don't remember well
<abu[m]> But this explains it
<abu[m]> Still I don't understand. strcpy is just bytes
<abu[m]> (strcpy (ofs Q Len) ($ ".so"))
<abu[m]> Do you remember what we changed last time for big endian?
<tankf33der> no.
<abu[m]> I'm looking at the source of sharedLib. The other strcpy's work fine
<tankf33der> maybe Len is too small ?
<abu[m]> (setq Len (+ Len N 4)) is to skip "lib/"
<abu[m]> So here it is still right
<abu[m]> If Len were too small, the copy would work, but we get a buffer overflow perhaps
<abu[m]> But if Len were too big, the copy is behind the last null byte and thus invisible
<abu[m]> But then the name would stop after "lib/", not after "lib/ext"
<abu[m]> Perhaps 'S' is already wrong here?
<abu[m]> Forget that
<abu[m]> If Len were too big, the copy behind "lib/ext" would be after the null byte
<abu[m]> So a too big Len would explain it
<tankf33der> how to print Len ?
<abu[m]> (dbg Len $T)
<abu[m]> or (dbg Len 0) to get just the number
<tankf33der> doing
<abu[m]> Perhaps it is wrong already here: (let (Len (strlen S)
<abu[m]> strlen is declared to return 64 bits
<abu[m]> Perhaps it returns 32 bits here?
<abu[m]> Can you check the string.h include file?
<abu[m]> it is size_t
<abu[m]> So some other include file
<abu[m]> yes, size_t
<abu[m]> Pil assumes it is 64 bits
<tankf33der> this is standart linux distro like debian
<tankf33der> all the same
<abu[m]> I'm quite sure size_t is 32 bits
<abu[m]> So Len is garbage
<abu[m]> I think it is 32 on Linux too
<abu[m]> hmm, 19 looks good
<tankf33der> Len is 19 without .so
<abu[m]> Is it just before (strcpy (ofs Q Len) ($ ".so")) ?
<tankf33der> before, right.
<abu[m]> So it is correct, right?
<tankf33der> where is space for .so then ?
<abu[m]> The buffer is allocated above, in (b8 (+ N Len (+ 4 3 1)))
<tankf33der> length of /root/pil21/lib/ext is 19
<tankf33der> where is space for .so ?
<abu[m]> The 3 in (+ 4 3 1)
<abu[m]> 4 is lib/ and 1 is the terminating null byte
<tankf33der> bug (dbg Len 0) prints 19 and not 22
<tankf33der> ok then
<abu[m]> If the buffer had the wrong size, we get other effects (buffer overflow1 silent or crash)
<abu[m]> s/overflow1/overflow,/
<abu[m]> Mysterious ;)
<tankf33der> let me try (ext:Snx "mike") under memory sanitizer
<abu[m]> Good idea!
<tankf33der> passed.
<abu[m]> ok
<abu[m]> so probably no buffer overflow?
<tankf33der> yeap
<abu[m]> The (ofs Q Len) is not the problem, I suppose, as 'ofs' is used everywhere
aw- has quit [Ping timeout: 250 seconds]
<tankf33der> the same for ht call
<abu[m]> consistent ;)
aw- has joined #picolisp
andyjpb has quit [Quit: Connection closed]
rob_w has quit [Remote host closed the connection]
<abu[m]> To be sure, let's print the buffer before calling dlOpen!
<abu[m]> After (strcpy (ofs Q Len) ($ ".so")) can you put two lines?
<abu[m]> (outString Q)
<abu[m]> (newline)
<tankf33der> doing
<abu[m]> ☺
<abu[m]> Thanks! No new insight :(
<abu[m]> Really strange
<tankf33der> out in 15mins
<abu[m]> And before the last strcpy it is also /root/pil21/lib/ext right?
<abu[m]> ok
<tankf33der> right
<abu[m]> (outString ($ ".so")) gives something?
<tankf33der> doing
<abu[m]> good
<abu[m]> out of ideas
<beneroth> isn't size_t supposed to be always mapped to the largest integer size of the platform?
<abu[m]> Really? Not sure
<abu[m]> there is also ssize_t which seems 64 bits on Linux
<abu[m]> Grepping include files for that is a nightmare. Better would be to extend @src/sysdefs.c
<abu[m]> I think as far as return values are concerned, it should not matter on a 64-bit machine
<abu[m]> Cause the value is returned in a register which is 64 bit anyway
<beneroth> haha, nice point
<abu[m]> Same goes for (at least the first few) arguments
<beneroth> unless part of its might be garbage in some cases for weird reasons?
<abu[m]> yes, conceivable
<abu[m]> But I don`t think so
andyjpb has joined #picolisp
seninha has joined #picolisp
seninha has quit [Ping timeout: 255 seconds]
andyjpb has quit [Quit: Connection closed]
TeddyDD is now known as teddydd
teddydd has quit [Remote host closed the connection]
teddydd has joined #picolisp
seninha has joined #picolisp
seninha has quit [Ping timeout: 244 seconds]
f8l has quit [Ping timeout: 260 seconds]