<Regenaxer>
: (in '(sleep 1000)) @@ # killall -9 sleep
<Regenaxer>
-> 9
orivej has joined #picolisp
<Regenaxer>
Issue closed
xkapastel has joined #picolisp
beneroth_ has joined #picolisp
beneroth_ has left #picolisp [#picolisp]
beneroth|mobile has joined #picolisp
beneroth has quit [Disconnected by services]
beneroth|mobile has left #picolisp [#picolisp]
beneroth_ has joined #picolisp
beneroth has joined #picolisp
mtsd has joined #picolisp
<mtsd>
Good morning!
<beneroth>
Good morning mtsd
<Regenaxer>
Good morning mtst!
<Regenaxer>
mtsd ;)
<mtsd>
Morning Regenaxer :)
<mtsd>
Morning beneroth!
<Regenaxer>
:)
<mtsd>
I spent some time reading through the irc log from yesterday
<mtsd>
A bit rude attitude from gpr, I think.
<Regenaxer>
Yeah, this was a frustrating discussion
<mtsd>
I mean, picolisp solves your use cases, Regenaxer, right? It is not there to solve every single possible issue for everyone
<Regenaxer>
Yes, but in this case I supported the general use, not grp's
<Regenaxer>
He wanted a *restricted* version
<mtsd>
My uses happen to coincide with some of your needs, and I am very happy about that. But if I need something else, that is my problem. Up to me to sort out
<Regenaxer>
It can always be discussed
<mtsd>
Of course
<Regenaxer>
In my use cases, I think I never needed this exit status. But *if* we support it, we should support it fully and consistently
<Regenaxer>
So I added it upon his request, because he was right that if 'call' supports it, the pipe functions should also support it
<Regenaxer>
'in', 'out', 'load' and 'pipe'
<Regenaxer>
The quarrel was only about whether do throw away part of the result, just to avoid a shift (>> 8 @@) instead of a direct @@
<mtsd>
Ok..
<Regenaxer>
And even change the current 'call', possibly breaking other people's code
<Regenaxer>
I'd like to hear aw- about this, perhaps he used it
<mtsd>
I haven't used it, so I'm not much help here, I'm afraid
<mtsd>
That said, I trust your judgment here. As always ;)
<Regenaxer>
Thanks! And also I never used it as far as I remember
<mtsd>
By the way, a new Pil user e-mailed me some time ago, sundar from India
<mtsd>
He had found my presentation on the wiki, I have been helping him getting started
<Regenaxer>
Cool!
<Regenaxer>
India seems to be a PicoLisp hotspot ;)
<beneroth>
cool, thanks mtsd !
<beneroth>
I'm usually not using the exit code, but I remember I had once this issue that I had to parse the exit code and also at first stumbled about this 16bit idiocy (idiocy from the C function, not picolisp. I'm not even sure if I was picolisp programming when I encountered this)
razzy has quit [Ping timeout: 246 seconds]
<beneroth>
picolisp-wise: gpr can do once a nice (redef call ...) to add his functionality to call (or in or whatever)
<Regenaxer>
I think this status code is not idiotic. It makes a lot of sense
<Regenaxer>
It needs to encode two values, success and errors
<Regenaxer>
So the convention is that zero is success
<Regenaxer>
and all other values have 8 bit of general info and 8 bit for system info like signal number and core dump flag. Perhaps more
<Regenaxer>
Perhaps idiotic is that it has only 16 bits
<Regenaxer>
a remainder from times (PDP 11) when ints were 16 bits in C
<Nistur>
mornin' all
<Regenaxer>
Hi Nistur
<Regenaxer>
A better design might have been to define positive numbers for success and negative ones for interrupts and failures] eg -1 ... -255 for signals. But that' also not really beautiful
<Regenaxer>
This exit status is not really meant to carry much info
<beneroth>
yeah, so it could also be just always 8 bits :P
<beneroth>
but yes, one of the fundamental principles of picolisp software design is to never restrict anything, unless that restriction is essential to the functionality.
<beneroth>
this is the source of the amazing emergent re-usability of picolisp pieces
<beneroth>
very important.
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
xkapastel has quit [Quit: Connection closed for inactivity]
<beneroth>
bbl
<Regenaxer>
cu
beneroth has quit [Quit: Farewell]
<aw->
Regenaxer: hi
<aw->
is there anything in PicoLisp which would cause $HOME/.pil/ directory to be wiped or removed?
<aw->
this hasn't happened.. i'm just wondering if I can rely on $HOME/.pil/ to store files
<Regenaxer>
Not without coding that explicitly
<Regenaxer>
What *is* removed is $HOME/.pil/tmp/<pid>
<Regenaxer>
but not $HOME/.pil/tmp/ or above
<Regenaxer>
aw-, btw, do you use the exit status code in '@@' after 'call'?
<Regenaxer>
There was a long discussion yesterday evening
<aw->
ok thanks!!
<aw->
hmmmm
<aw->
wait let me check
<aw->
ok I only found @@ in one place, but I think its use is different
<aw->
not sure why I wrote this though:
<aw->
(maxi '((N) (length (car N))) List)
<aw->
(let Strmax (- (+ 4 @@))
<aw->
ok so no, I don't use exist status @@
<Regenaxer>
right, this is another case of @@
<Regenaxer>
ok
<aw->
is it broken?
<Regenaxer>
No, but extended
<Regenaxer>
to 'in' 'out' 'load' and 'pipe'
<aw->
OH
<Regenaxer>
They now also set '@@' just like 'call' does
<aw->
that's great!!
<aw->
i've wished for this for so many years
<Regenaxer>
But grp requested to change the value returned in @@
<Regenaxer>
oh, really?
<Regenaxer>
What kinds of checks would you do?
<aw->
yeah, I often asked you how to get the exit code from (in) and (out)
<aw->
i have lots of scripts which use (in (list 'cmd)) and then i always hack my way around getting the exist code
<aw->
exit* code
<Regenaxer>
What kind of info is sent in these codes?
<Regenaxer>
and why did you not use it in 'call' at least?
<Regenaxer>
use cases for pipes but not calls?
<aw->
depends on the scripts. Some scripts I output to stderr and then I check if there's output then it failed, no output = success
<aw->
because (call) doesn't return output
<Regenaxer>
ok
<aw->
with (in) i can get the output and use that to return an error message of the output
<aw->
etc
<aw->
i use (call) a lot as well, don't worry ;)
<Regenaxer>
:)
<aw->
ex: (call 'mkdir "-p" Ext_dir)
<aw->
but then I also have stuff like this: (in (list 'openssl "rand" "-hex" "16") (line T))
<Regenaxer>
I use pipes a lot, and just log stderr
<Regenaxer>
There is not much a script can do
<aw->
what change did grp request?
alexshendi has joined #picolisp
<Regenaxer>
It gets no data, but the problem usually the admin must fix
<Regenaxer>
He wanted to return only the high byte of the code
<aw->
high byte?
<Regenaxer>
to avoid (>> 8 @@)
<aw->
shift by 8 bits?
<aw->
what
<aw->
why?
<Regenaxer>
The exit code consists of 2 bytes
<Regenaxer>
see man system(3)
<Regenaxer>
and waitpid(2)
<Regenaxer>
If the child was killed by a signal, the number is in the lower byte
<Regenaxer>
The explicit exit code is in the higher byte
<aw->
this is C right?
<Regenaxer>
system(3) yes
<aw->
how does the shell interpret/display the code? an integer, no?
<Regenaxer>
I don't know what shells are doing
<aw->
hmmmm
<aw->
i think maybe it's un-necessarily complicated
<Regenaxer>
$? in bash seems the upper byte
<aw->
tbh i would be happy with just a binary result, 0 = success, anything else = error
<Regenaxer>
but how do you know then that the process was terminated by a signal?
<aw->
don't care
<Regenaxer>
The binary result is the 'flg' of 'call'
<Regenaxer>
the direct return, not @@
<Regenaxer>
but 'in' etc return the result of 'prg'
<aw->
personally I rarely/never need to know who/what/how something was terminated. I just need to know if termination was successful or errored
<aw->
i see
<Regenaxer>
This you have in call, and in 'in' you can handle in the body
<Regenaxer>
ie return T or something
<Regenaxer>
depends on the data
<aw->
yes i know
<aw->
that's what i've been doing so far
<Regenaxer>
Usually the default NIL, yes
<aw->
ok ok wait
<Regenaxer>
So I was wondering who that really needs
<aw->
so, you're debating whether to return the high byte or low byte?
<Regenaxer>
I say correct is to return both
<Regenaxer>
the full info from the system call
<aw->
that would be my first assumption as well
<Regenaxer>
ok
<aw->
i didn't know there were two haha
<Regenaxer>
It is indeed confusing
<Regenaxer>
buw has some logic
<Regenaxer>
and history ;)
<aw->
i can't find these man pages either
<Regenaxer>
waitpid(2) and system(3)?
<Regenaxer>
$ man 3 system
<Regenaxer>
Is in stdlib
<aw->
i don't have it
<Regenaxer>
Strange
<aw->
can you link to online man page which discusses it?
<Regenaxer>
It does basically the same as 'call' in pil
<aw->
is it same for BSD ?
<Regenaxer>
though it in fact calls a shell internally afaik
<Regenaxer>
Yes, even on DOS, Windows, MacOS etc.
<Regenaxer>
It is the most basic standard
<Regenaxer>
The return value is system dependent probably
<aw->
ok
<Regenaxer>
So if the child segfaults, you get back 11 in the lower byte
<Regenaxer>
and 'call' returns NIL
<Regenaxer>
'call' returns T if the code is zero only
<aw->
ok so essentially, here's what I think is important:
<aw->
if I do (in 'kill myprog) and the exit code of @@ is DIFFERENT from be doing # kill myprog ; # then that's a problem
<Regenaxer>
What does (in 'kill ...) mean?
<aw->
sorry
<aw->
(in '(kill myprog) …
<Regenaxer>
hmm, kill outputs to stdout?
<aw->
no, sorry
<Regenaxer>
The exit code of @@ is clear. I don't know what you compare it to
<aw->
never mind
<Regenaxer>
what bash has in $?
<aw->
my point is, if the exit code from @@ is different from what I get in bash $?, then we have a problem
<Regenaxer>
This is perhaps (>> 8 @@)
<Regenaxer>
I dont know for sure what bash does
<Regenaxer>
What does it return if the child was killed?
<aw->
bash sets high bit when not killed cleanly
<Regenaxer>
Can you investigate this? High bit means negative? Or ORed with (hex "80")?
<Regenaxer>
Pil just delivers the bare metal code
<Regenaxer>
what other apps do with it is beyond its reach
<Regenaxer>
Perhaps bash negates the signal number (as I proposed this morning for a better design of the exit status)?
<aw->
OK got it
<aw->
"The exit() function causes normal process termination and the value of status & 0377 is returned to the parent"
<Regenaxer>
This means the lowest 8 bits
<Regenaxer>
which are zero for normal termination
<aw->
yes
<aw->
exactly
<Regenaxer>
But what I saw is that $? holds the higher 8 bits. Again, check the log, we discussed all this
<Regenaxer>
A highly confusing issue
<Regenaxer>
My knowledge results from ancient readings of R. Stevens and using system() etc. I did not use exit values in bash ever
<aw->
Regenaxer: it adds 128
<aw->
that's all
<aw->
it adds 128 when terminated incorrectly
<aw->
bash adds 128
<aw->
to be more specific
<Regenaxer>
I see, cool, sounds simple
<Regenaxer>
hmm
<Regenaxer>
but adds to what?
<Regenaxer>
to the low byte, ok
<Regenaxer>
otherwise it returns the high byte, right
<Regenaxer>
This so the value in the high byte should be less than 128
<Regenaxer>
Sorry, must go
<Regenaxer>
bbl
<Regenaxer>
Thanks so far!
<aw->
yeah
<aw->
no problem
<aw->
not sure if I helped haha
<aw->
in any case, Regenaxer i think (>> 8 @@) is correct
<aw->
assuming the program didn't exit correctly
<aw->
i don't know
beneroth_ has left #picolisp [#picolisp]
beneroth has joined #picolisp
<beneroth>
hi all
rob_w has quit [Quit: Leaving]
<beneroth>
yeah, aw- we (you, Regenaxer, me) all agree on this :)
<beneroth>
gpr wished the same behaviour as bash and got a bit rude.
<aw->
hmmmm
<aw->
hi beneroth
<aw->
i'm not sure
<aw->
tbh I also want the same behaviour as bash
<beneroth>
then you do (redef call ...)
<beneroth>
I'd say
<aw->
ew
<aw->
i don't see why PicoLisp should do something completely different from every other system out there
<beneroth>
the problem is, adding the (>> 8 @@) always is 1) restricting users who actually are interested in the higher bits too 2) adds overhead which in most uses is likely needless as @@ is ignored often
<aw->
i mean.. an exit code is 8-bits even though we're working with 16-bits, bash returns 8-bits by checking if the exit was clean or not. If it wasn't then it sets the high bit (adds 128) to the code.
<beneroth>
the argument is, that bash is doing something different
<aw->
This is simple to implement in PicoLisp IMO
<beneroth>
yes it is, but it destroys the original use - which is system (OS) dependent
<aw->
how does it destroy the original use? every program does it that way
<aw->
every language
<aw->
every interpreter
<aw->
every shell
<beneroth>
system() in C ?
<aw->
except C
<aw->
actually you know what
<aw->
I don't care
<aw->
i don't
<aw->
really
<aw->
all i want is _an exit code for (in) and (out)_
<aw->
i don't care if it's a 256-bit hash
<aw->
all this discussion is pointless
<aw->
nobody cares
<aw->
in real life terms, you just need to know "did it fail? yes or no"
<aw->
the details about the failure are seriously __not important__ for 99% of programs
<aw->
and if they are, I think a lower-level approach to accessing that info should be made available, but not at the expense of breaking existing code.
<aw->
so you guys can argue all you want, in the end just make sure you don't breaks shit when implementing new stuff.
<beneroth>
aye, that's my view too
<beneroth>
adding exit code: good. rest of discussion: pointless.
alexshendi has quit [Ping timeout: 246 seconds]
<aw->
Yes exactly. I don't care about the implementation details or what it returns, as long as it returns something I can work with, which is much more useful than returning NOTHING.
<aw->
In any case, whatever Regenaxer implements, we find a way to work with or around it. Not a big issue… and if @@ ends up being useless, then I simply won't use it, back to square one ;)
<Regenaxer>
ret
<Regenaxer>
I think, if the program returns 7, I would do (= @@ '(>> -8 7))
<Regenaxer>
This means that signals are not encoded?
<tankf33der>
unknown.
<Regenaxer>
If in bash I do
<Regenaxer>
$ sleep 1000; echo $?
<Regenaxer>
and in another window
<Regenaxer>
$ killall sleep
<Regenaxer>
I get
<Regenaxer>
$ sleep 1000; echo $?
<Regenaxer>
Terminated
<Regenaxer>
143
<Regenaxer>
143 is 128+15
<Regenaxer>
15 is SIGTERM, correct
<Regenaxer>
But this cannot be distinguished from a correct return value of 143
<Regenaxer>
So bash is broken in my view
<Regenaxer>
OR bash does have a way to retrieve the full value somehow
<tankf33der>
try zsh
<Regenaxer>
Too much hassle. Did you?
<Regenaxer>
I think all shells will behave the same for reasons of tradition
<Regenaxer>
Perhaps not broken, but it limits processes in the range of return values
<Regenaxer>
Can return only values up to 127
<Regenaxer>
So nobody worries
<Regenaxer>
At least I don't worry, as I don't stress those values ;)
<tankf33der>
the same.
<mario-goulart>
Regenaxer: "Generally, you'd want to only use values 0 (generally meaning success) to 125 only, as many shells use values above 128 in their $? representation of the exit status to encode the signal number of a process being killed and 126 and 127 for special conditions." <- from https://unix.stackexchange.com/a/418802
<beneroth>
don't worry. soon programs will not communicate with return values anymore, but only via HTTP(S). /irony
<beneroth>
see DNS-over-HTTP m(
<beneroth>
(facepalm-smiley)
aw- has quit [Quit: Leaving.]
<Regenaxer>
mario-goulart, thanks! Thats what I assumed
<mario-goulart>
yw
<Regenaxer>
They add 128 to the signal number in the exit status, as aw- said before
<Regenaxer>
So I stand with my proposal. I would compare @@ with (>> -8 7) if the program output is expected to be 7, and compare @@ with 7 if I expect a bus error (SIGBUS)
<Regenaxer>
Then *all* possible values are caught
<beneroth>
"sometimes referred as the exit code to avoid the ambiguity with exit status which is also referring to an encoding of either the exit code or signal number and additional info"
<beneroth>
@@ is exit STATUS
<Regenaxer>
without conflict
<beneroth>
not exit code
<beneroth>
words matter.
<Regenaxer>
Exactly
<Regenaxer>
beneroth: As you may have noticed, I have left #penti and I don't refer to it on the penti home page any longer. Hope this is OK for you
<Regenaxer>
The channel was kind of too calm ;)
<beneroth>
yeah I noticed. ok. no surprise.
<Regenaxer>
Hmm, I should stop ChanServ, but forgot how to do that
<Regenaxer>
ok :)
<beneroth>
I guess you have to /msg Chanserv help or something
<Regenaxer>
right
<Regenaxer>
Something with /privmsg ChanServ ... probably
<Regenaxer>
It *should* be /privmsg ChanServ :drop #penti but nothing happens
<beneroth>
well for nickserver its /msg
<beneroth>
maybe you should join the channel first, so you get OP ?
<Regenaxer>
I think some clients change it. Internally in IRC protocol it is /privmsg
<Regenaxer>
Same as if you write /me <msg> I see it a /action <msg>
<beneroth>
./msg ChanServ DROP channel
<beneroth>
. /msg
<beneroth>
. /msg <msg>
<beneroth>
the command is /msg I think
<beneroth>
I've never used /privmsg :)
<Regenaxer>
does not work
<Regenaxer>
All clients seem to change it
<Regenaxer>
(not mine ;)
<beneroth>
>ChanServ< DROP #picolisp
<beneroth>
-ChanServ- You are not authorized to perform this operation.
<beneroth>
that's what I get
<beneroth>
when I do ./msg ChanServ DROP #picolisp
<Regenaxer>
There are more commands different in the RFC
<beneroth>
ok. possible my client changes it. and possible freenode differs from the RFC :/
<Regenaxer>
I'm sure it must be here /privmsg ChanServ :drop #<channel>
<Regenaxer>
But for some reason *nothing* works at the moment
<Regenaxer>
no error even
<beneroth>
did you try /msg ChanServ DROP #picolisp?
<beneroth>
without ?
<Regenaxer>
Even /foobar
<beneroth>
maybe error is shown in server channel, not in your current channel
<beneroth>
I get permission error.
<Regenaxer>
ha, right, it is here in the control channel of course ;)
<beneroth>
ok granted, T, he might be one level above.
<beneroth>
but he is not on Knuth wunderkind-level, is he?
<Regenaxer>
Several
<Regenaxer>
A different type
<Regenaxer>
Extremely creative
<beneroth>
well Knuth is quite different in many ways :D
<beneroth>
good :)
<Regenaxer>
Knuth is extremely exact
<pointfree>
I have met Chuck at svfig meetups a few times. He speaks very deliberately.
<beneroth>
I don't think I have enough RAM in my brain to even have a chance to be like Knuth. Probably also not for Chuck.
<beneroth>
ah nice
<Regenaxer>
cool
<beneroth>
the nice thing about the good "tricks" (as in craft receipts, not as in cheating) of these wise sages is, that most of them work with not much requirements beside discipline
<beneroth>
or so I believe and hope
<pointfree>
^
<Regenaxer>
Knuth is indeed a god
<beneroth>
he got automatically master degree awarded with his bachelor degree
<Regenaxer>
And Chuck is practical at a genius level or above
<Regenaxer>
I see :)
<Regenaxer>
I would need a month for one page of his books to write
<beneroth>
does he write as dense as you do? :P
<Regenaxer>
And with Chuck's ideas I would never come up in my lifetime
<Regenaxer>
Denser I would sad
<Regenaxer>
say
<Regenaxer>
uops sorry
<Regenaxer>
must go
<Regenaxer>
bbl
<pointfree>
Greenarrays is going to tape out a new chip. A friend of mine wants to put lisp on it.
<pointfree>
I have a Forth book with a chip design eda toolchain in one screen of source code written by Chuck.
<beneroth>
so how is the ranking going? code monkey > interested > enthusiast (has good taste but lacks yet the skills) > disciplined & experienced > guru > genius > demi-god > god > von-neumann ?
<beneroth>
pointfree, yeah!
alexshendi has joined #picolisp
xkapastel has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
<Regenaxer>
ret
<Regenaxer>
beneroth, you put von-neumann on top?
<beneroth>
I thought, but right after I doubted it again
<Regenaxer>
:)
<beneroth>
he prolly belongs into same layer as Knuth, no? :)
<beneroth>
and he gets minus points for helping with the bomb
<Regenaxer>
I can't say, don't know enough about him
<Regenaxer>
Then better Einstein
<beneroth>
T
<beneroth>
Einstein was good both in creativity, physics, math, human rights/politics I find. just in personal relationship he was an asshole apparently.
<beneroth>
but well, that was in the days you usually didn't marry for love.
<Regenaxer>
T
<beneroth>
Von Neumann was very famous for the fact that even extremely clever smart people were very afraid of telling him about their inventions or theories, because we would develop an improved a few minutes after you told him your live-work.
<beneroth>
s/we/he
<beneroth>
hm
<beneroth>
damn
<Regenaxer>
I see, impressing
<beneroth>
one-dimensional ranking is not working out.
<Regenaxer>
cyclic graph
<beneroth>
not enough, but yeah I see what you mean, good point.
<beneroth>
must also be a dimension for craziness.
<Regenaxer>
right
<beneroth>
e.g. the guy from Temple-OS (incredible smart, but nuts, paranoid) and the founder of the JPL (the space rocktet inventor), very clever, huge fan of Alaster Crowley okkult magic, so fanatic it was too much for Crowley and he detested the guy. fascinating :)
<beneroth>
I find the claim very plausible about artists/inventors having more loose filters in their brain, that allow creativity/insights/out-of-box-thinking but also higher probability for going insane or paranoid of information overflow/over-interpreting
<beneroth>
of course it is possible that common sense is completely wrong and they were right :)
<beneroth>
(I'm not talking about value when I talk about such things, only maybe about practicability to navigate/handle people/society/"reality")
<Regenaxer>
It is the mutation component in evolutionary algorithms
<beneroth>
T
<Regenaxer>
Artist need to be this way
<Regenaxer>
artists
<beneroth>
well I see a good software designer as an artist.
<beneroth>
crafter
ubLIX has joined #picolisp
orivej has quit [Ping timeout: 250 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
alexshendi has joined #picolisp
rob_w has joined #picolisp
alexshendi2 has joined #picolisp
alexshendi has quit [Ping timeout: 240 seconds]
alexshendi2 has quit [Client Quit]
alexshendi has joined #picolisp
orivej has joined #picolisp
grp has joined #picolisp
<grp>
yo~!
<grp>
Regenaxer: I've been munching the issue and I've come to agree with your point of view. Just in case: any chance it returns the codes as a cons?
<Regenaxer>
Hi grp!
<grp>
for example: @@ -> (250 . 0)
<grp>
instead of 64000
<Regenaxer>
Why the hell as a cons? A lot less efficient
<Regenaxer>
and the values are extracted so easily with shift or and
<grp>
¯\_O_/¯
<Regenaxer>
It needs to extract and box two numbers plus cons
<Regenaxer>
despite the value is almost never needed
<grp>
just saying... it's less consing than the code to call shift/and 2 times, plus it's more intuitive: 2 values
<Regenaxer>
And as I wrote, a check for `(>> -8 250) is the way
<Regenaxer>
a single constant compare at the caller's side
<Regenaxer>
I wrote: So I stand with my proposal. I would compare @@ with (>> -8 7) if the program output is expected to be 7, and compare @@ with 7 if I expect a bus error (SIGBUS)
<Regenaxer>
soo simple
<Regenaxer>
and covers all possible values :)
<grp>
aye
<grp>
done deal then
<Regenaxer>
ok :)
<Regenaxer>
Thanks that you inited the issue!
<grp>
sorry for being so dense yesterday (not that you could point your finger at me for that though ;¬) (remember the exit on enter thing? we argued for days back then)
<grp>
s/dense/stubborn
<grp>
(did a bad translation from 'denso')
<Regenaxer>
yes, and I often regretted that I implemented this inconsistency
<Regenaxer>
but understand that it is easier for newbies : sn
<Regenaxer>
:)
<grp>
why? you yourself got caught by the repl closing when stepping through breakpoints
<grp>
it was just a PITA to close on enter
<grp>
just one extra enter and BAM! out of the repl you go
<Regenaxer>
In a sub-repl it is still there and needed
<grp>
agreed
<grp>
but it's a different thing on top level
<Regenaxer>
I exit very frequently, so it was convenient
<Regenaxer>
but I accept that it is surprising
<grp>
any repl, be it *sh, py, rb, hs... you name it, terminates on top level only on stdin EOF, which is ^D on most terminal emulators
<Regenaxer>
right
<grp>
so, all good?
* grp
grins
<Regenaxer>
sure :)
<grp>
good
<Regenaxer>
Nothig harmed
<grp>
I was going bonkers over the issue since POSIX specifies that only waitid() returns a meaningful code on the lower 8bit, and picolisp uses waitpid() which (according to posix) does not
<grp>
but after a few tests, I see that it actually does(!!!)
<grp>
(wtf!)
<grp>
besides every system/language returns the higher 8bit only, be it *sh, py, rb, java, hs, whatever