xkapastel has quit [Quit: Connection closed for inactivity]
jibanes has quit [Ping timeout: 268 seconds]
jibanes has joined #picolisp
namra has joined #picolisp
<namra>
greetings
<namra>
trying to get to know things and can't figure out why the following doesn't work as i though it would: https://pastebin.com/Axa9RbA9
<namra>
So there's one todo added to the db initially which i want to list with a chart
<namra>
so i use the "+Init" class and try to get some initial todos from the db with "collect"
<namra>
but nothing shows up and nothing will be stored on submitting.
<namra>
can't figure out why
<namra>
ok found the mistake for things not showing up
<namra>
missing the quote for the property names
aw- has joined #picolisp
libertas has quit [Ping timeout: 246 seconds]
libertas has joined #picolisp
<namra>
ok finally got it
namra has quit [Ping timeout: 256 seconds]
rob_w has joined #picolisp
aw- has quit [Quit: Leaving.]
viaken has quit [Quit: reboot]
viaken has joined #picolisp
jibanes has quit [Ping timeout: 240 seconds]
jibanes has joined #picolisp
aw- has joined #picolisp
aw- has quit [Remote host closed the connection]
aw- has joined #picolisp
ubLIX has joined #picolisp
xkapastel has joined #picolisp
namra has joined #picolisp
<Regenaxer>
namra: Seems you solved your problem? :)
grp has joined #picolisp
<grp>
Regenaxer: hi there
<tankf33der>
o/
<Regenaxer>
Hi grp, tankf33der!
<grp>
Regenaxer: been struggling with something really simple(!)
<grp>
need to (in '(....) ...) and retrieve the exit code of the process
<grp>
been trying stuff with tell, pipe, call, whatever
<grp>
'call returns the exit code as @@
<Regenaxer>
I think only 'call' would work
<grp>
but there's no such thing for 'in
<Regenaxer>
redirect the output
<Regenaxer>
or 'call' in 'pipe'
<grp>
yes, but (pipe (call ...) ...) runs the call in another thread
<grp>
can't setq
<grp>
not to the main thread anyways
<Regenaxer>
right
<Regenaxer>
So better (call "process" "-o" (tmp "file"))
<Regenaxer>
check the value then read (tmp "file")
<grp>
=/
<Regenaxer>
Not good?
<grp>
ugly
<grp>
specially for long input
<grp>
I could use a ramdisk anyway, but still...
<Regenaxer>
The exit code is available anyway only *after* the process is done
<Regenaxer>
A pipe would block
<Regenaxer>
PIPE_BUF
<Regenaxer>
So there is no other way. The data must be saved until the return code is available
<grp>
I'd like to be able to do something like (pipe (prog (call ...) (setq-parent *Exit @@)) ...)
<Regenaxer>
ramdisk? You worry abeut speed?
<grp>
ideally (in '(...) ...) @@ = $?
<grp>
(in '(false)) @@ = 256
<Regenaxer>
right
<Regenaxer>
Good suggestion
<grp>
that'd allow many scripting practices that are currently a PITA in picolisp
<grp>
I could ditch sh bash zsh
<Regenaxer>
In which cases did you need that?
<grp>
hell, I'd run picolisp as my login shell
<Regenaxer>
Non-error exit codes?
<Regenaxer>
Normally process exit codes are rather useless. 0 or -1
<Regenaxer>
and error conditions are written to stderr
<grp>
have a command that connects to CPE equipment to check/set wifi. If it can't connect, the exit code is 1. If it connects but it's not wifi, exits with 2. Otherwise exit 0 with proper output
<Regenaxer>
So you need to distinguish between 1 and 2
<Regenaxer>
?
<grp>
yes (in this case)
<Regenaxer>
If not, just (ifn (in '() ) (error) (do ...
<grp>
no, that's equivalent to (in '(...) NIL) which must be NIL
<grp>
since it's the body of the prg
rob_w has quit [Quit: Leaving]
<namra>
Regenaxer: yes. thanks.
<Regenaxer>
Anyway you are right. As 'call' supports it, other places should do it too
<Regenaxer>
namra, great!
<grp>
I propose this: (in '(exit 3) NIL) -> NIL @@ -> 3
<grp>
the process exit code is set after in's prg evaluation
<grp>
<grp>
how do you like that?
<Regenaxer>
yes, good
<Regenaxer>
A trivial change to waitFileC
<namra>
though i was wondering why there are duplicates. as the docs for request mention that if such an object already exists it'll be returned. and the check is done via the db function.
<Regenaxer>
There is no unique key
<Regenaxer>
but true, you mean request. Moment.
<Regenaxer>
Where do you see duplicates?
<Regenaxer>
I see only one 'request' call
<Regenaxer>
BTW, I recommend to omit the '+Need' prefixes
<Regenaxer>
They should be used only when it is sure that an initial value is supplied by the T method
<namra>
great thank you very much! will have a look at those.
<Regenaxer>
The trick is '((L D) ... in the chart's get function
<Regenaxer>
The existing object is passed in 'D', and the line of the chart in 'L'
<Regenaxer>
This allows you to modify all values in an object, without creating new ones each time as with 'request'
<namra>
great
<Regenaxer>
And the above mentioned problem with +Need is that if you show a new (empty) object in the GUI, you get in a deadlock because you cannot fill two or more fields at the same time ;)
<Regenaxer>
So my rule is to use +Need only for pre-filled attributes which the user may modify but not clear
<namra>
thanks will note that down
<Regenaxer>
(also a boolean +Need is a contradiction, because false is NIL which is "empty")
Nistur has quit [Ping timeout: 250 seconds]
<namra>
right
<Regenaxer>
grp: I added you proposal to my todo list
Nistur has joined #picolisp
<grp>
I was actually implementing it
<Regenaxer>
cool
<grp>
(or trying)
<grp>
:P
<grp>
struggling to understand rdOpen/rdOpenEXY
<grp>
so I can store the exit code somewhere
<Regenaxer>
take code from 'doCall' into 'waitFileC'
<grp>
then set At2
<Regenaxer>
Not in the open function
<Regenaxer>
it must be in the closing part
<grp>
I was following the code from doIn
<Regenaxer>
yes, good
<Regenaxer>
But the exit code is available after cc waitpid((C II) 0 0)
<Regenaxer>
just like in 'doCall'
<grp>
what I need to modify is popInFiles
<grp>
and doIn
<Regenaxer>
no
<Regenaxer>
only 'waitFileC'
<Regenaxer>
it is called by 'popInFiles'
<Regenaxer>
hmm
<Regenaxer>
it is also called by 'doCo'
<Regenaxer>
coroutine switching
<Regenaxer>
Can't research in detail at the moment
<Regenaxer>
Must investigate the consequences if '@@' is set during coroutine switching
<Regenaxer>
Give me some time, I have some other stress here
<grp>
no worries, I wouldn't want to disturb your work. I just wanted to agree on a solution so it won't get rejected once I send the patch
<Regenaxer>
Thanks! No need for a patch thoug, I need to research the implications
<Regenaxer>
The actual change is simple, just a few lines from 'doCall' folloing the waitpid
<Regenaxer>
And the same must be done for pil32 too (no problem with coroutinel here)
<grp>
I actually implemented it in pil32, but it's not working as I expect it to
<grp>
checking wtf is going on
libertas has quit [Ping timeout: 240 seconds]
libertas has joined #picolisp
grp has quit [Ping timeout: 272 seconds]
alexshendi has joined #picolisp
namra has quit [Ping timeout: 256 seconds]
grp has joined #picolisp
libertas has quit [Ping timeout: 240 seconds]
<grp>
ok, implemented it in pil32
<grp>
now need to figure out a few bits to do it in pil64
libertas has joined #picolisp
ubLIX has quit [Quit: ubLIX]
xkapastel has quit [Quit: Connection closed for inactivity]
<Regenaxer>
I have it for pil64, not tested however. Want to see it?
<Regenaxer>
Or try yourself?
<Regenaxer>
Have also pil32 now. Want to see for comparison?
<Regenaxer>
grp, you don't need to look up the link
<Regenaxer>
tankf33der, posted the functions and diffs
* grp
is still segfaulting in pilasm
<Regenaxer>
oh
<Regenaxer>
I have not tested mine, not even built
<Regenaxer>
As you have a test case, I was hoping you would test it
<Regenaxer>
But no hurry
<Regenaxer>
first try to find the error
<Regenaxer>
Meanwhile I extend the references
<Regenaxer>
Also for 'pipe'
<Regenaxer>
and 'load'
<Regenaxer>
wow
<grp>
yes!!! not segfaultig, now need to fix the num size
<grp>
ok, I'll post the diff in a second
<grp>
hmm
<grp>
wait, this is just worikng, haven't refactored the code yet
<grp>
(I've just duplicated and edited functions to avoid breaking stuff I'm not paying attention to right now)
ubLIX has joined #picolisp
<Regenaxer>
Correction. Not 'pipe'
<Regenaxer>
The setting of @@ happens at unpredictable times, as the child runs asynchronously with (pipe exe), but *fortunately* in the child only, which terminates at that moment :D
<Regenaxer>
The other form of 'pipe' waits just as 'in' so it should be OK
<Regenaxer>
Sigh. Fixing up all the references is a lot more work than the actual code
<Regenaxer>
pil64 is almost the same. I just used 'sub S I' instead of 'push X'
<grp>
please use unified diff
<grp>
diff -u
<Regenaxer>
I don't like the patch diff. Too verbose
<Regenaxer>
I use diff to detect differences
<Regenaxer>
Your pil32 version is a bit too complicated, and it does not cover 'load' and 'pipe'
<Regenaxer>
There is no need to first return the value and then assign it to '@@', is it?
<Regenaxer>
After all, '@@' is a global :)
<Regenaxer>
OK, I just release it. Will you test again? Possibly with both pil64 *and* pil32
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<Regenaxer>
oops, ^D again :)
<grp>
err, yes, didn't refactor the C code
<grp>
I kind of forgot
<Regenaxer>
OK, released it
<Regenaxer>
no problem, it was correct
<grp>
the code would have turn out the same
<Regenaxer>
T
<grp>
(as in the case of the pil64 version)
<grp>
now, there's a difference
<grp>
crucial difference
<Regenaxer>
The C code is almost obsolete anyway
<grp>
you are not shifting the return value of waitpid
<Regenaxer>
oh
<Regenaxer>
hmm, I do shl A 4 # Make short number
<grp>
turns out it has to be shr
<grp>
check my version
<Regenaxer>
You are loading into X first. This is not needed
<grp>
btw, regarding diffs, please use unified, don't be a caveman ;¬) Reason is, with unified diff *I can read context*
<Regenaxer>
oh, and yours is very wrong!
<grp>
how so?
<Regenaxer>
you pop X in the loop
<grp>
err, what
* grp
checks
<Regenaxer>
if an interrupt occurs, you pop repeatedly
<Regenaxer>
did not notice due to the verbose diff ;)
<grp>
I pop in the loop? what?
<grp>
where?
<grp>
I push and pop outside the loop
<Regenaxer>
do
<Regenaxer>
- cc waitpid((C II) 0 0) # Wait for pipe process
<Regenaxer>
+ cc waitpid((C II) S 0) # Wait for pipe process
<Regenaxer>
nul4 # OK?
<Regenaxer>
+ ld X A
<Regenaxer>
+ ld4 (S)
<Regenaxer>
+ add S I # Drop expression
<Regenaxer>
while s # No
<Regenaxer>
add S I #
<grp>
I don't see pop X there
<Regenaxer>
And then pop in the end again
<Regenaxer>
add S is like a pop
<Regenaxer>
ignoring the value
<Regenaxer>
Check my version, it puts the sub and add S into the if body
<grp>
didn't see it, can't read standard diff and patch was failing
<Regenaxer>
The pil64 version surely crashes, as the stack is imbalanced
<Regenaxer>
you copied this line too much:
<Regenaxer>
+ add S I # Drop expression
<grp>
yes, I assumed wrong
<Regenaxer>
Hmm, also 'shr' can't be right. It must be 'shl'
<Regenaxer>
making a short number
<Regenaxer>
So you tested only pil32?
<grp>
maybe I needed shr due to the add S I
<Regenaxer>
no, this adds only to the stack pointer. Independent
<grp>
it is indeed shr
<grp>
doesn't crash whether I add add S I or not
<Regenaxer>
Can you test your use case for pil64? Or can we make up an example"
<grp>
(for I 255 (in (list "sh" "-c" (pack "exit " I)) NIL) (prinl @@)) should print from 1 to 255
<Regenaxer>
Hmm, I think it *must* crash
<Regenaxer>
when it returns
<Regenaxer>
and X has not its old value
<grp>
why shouldn't it?
<Regenaxer>
Another problem is the check 'while s' after the 'add S I '
<Regenaxer>
this way you check the sign of the stack
<Regenaxer>
the 'while s' must be after the 'nul4'
<Regenaxer>
to check that roturn value
<grp>
ok, seems I messed it up big time
<grp>
but still, it's not crashing
<grp>
xD
<Regenaxer>
X does not have its old value, because it receives the return address
<Regenaxer>
the return address to the caller of 'waitFileC'
<Regenaxer>
not crashing is interesting :)
<Regenaxer>
Must be a lucky coincidence
<Regenaxer>
do you get a meaningful value in '@@} ?
<Regenaxer>
'@@}
<Regenaxer>
grr
<Regenaxer>
'@@'
<Regenaxer>
The cat on my lap does not let me type penti
<grp>
yes, that for loop prints 256 lines with the right value
<grp>
and doesn't crash
<Regenaxer>
strange
<Regenaxer>
you are testing on pil64?
<Regenaxer>
I think it does *not* crash because the next stack entry is that of the *next* higher function
<Regenaxer>
popInFile
<Regenaxer>
So it returns from *that* function
<Regenaxer>
No direct crash, but popInFiles did not finish
<grp>
it didn't?
<Regenaxer>
popInFiles did not push any data on the stack, so the next entry is another return address -> no direct crash
<Regenaxer>
You might test it when calling your test inside another 'in' or 'load'
<Regenaxer>
Then the frame stack will not be popped do to the skip in popInFiles
<Regenaxer>
s/do/due/
<Regenaxer>
Or test it by letting the input process hang, and then send a signal
<Regenaxer>
For each signal the stack will be popped another time
<Regenaxer>
Then I'm sure it will crash ;)
<grp>
I ended up adding add S I because: I was trying stuff to stop it from segfaulting and thought I had to add it after using S in a cc call since in doCall there were no other explicit mention of S
<Regenaxer>
The next call level is 'doIn' which pushed data on the stack which are guaranteed not to be valid return addresses
<Regenaxer>
(X and Y, which hold Lisp data)
<Regenaxer>
OK
<Regenaxer>
yes, valid assumption
<grp>
which rises the question: what's with that in doCall?
<grp>
why add S I?
<grp>
by the way, you really got to shift right in pil64, the error codes are messed up
<grp>
and in pil32 too
<Regenaxer>
What do you mean with "what's with that in doCall"?
<Regenaxer>
I'm sure to make a number you have to shift it left and or 2
<Regenaxer>
How can I test easily?
<grp>
what's the purpose of the add S I in doCall?
<grp>
just do: (in '(sh -c "exit 250")) @@
<grp>
must return 250
<Regenaxer>
'add S I' is always to clean up the stack
<Regenaxer>
remove an 8 byte buffer
<grp>
when did that buffer appear in that code?
<grp>
call wifstoppedS_F ?
<Regenaxer>
Ah, yes, I know
<Regenaxer>
it is the higher byte in Unix
<Regenaxer>
the return code is in fact 64000
<Regenaxer>
which is correct
<Regenaxer>
250 << 8
<grp>
indeed
<grp>
that's why you need to shift right
<Regenaxer>
no
<Regenaxer>
: (call "sh" "-c" "exit 250") @@
<Regenaxer>
-> 64000
<Regenaxer>
It is the true full return value
<Regenaxer>
The calle must shift right or divide if the lower bits are not needed
<Regenaxer>
caller
<Regenaxer>
The 'wifstoppedS_F' happens if the child process gets a STOP signal
<Regenaxer>
often via ^Z
<Regenaxer>
in bash or in pil or vim or vip
xkapastel has joined #picolisp
<grp>
not practical... @@ should be the equivalent of any shell's #?
<Regenaxer>
Then pil goes into a repl with '+' prompt
<Regenaxer>
I do not think so. There must be a reason for the lower bits
<grp>
if it is ever needed, put it back, but no shell ever returns the complete code because it's not practical, and I have never known of any case where such code was needed
<grp>
so, adding the full return is not practical
<grp>
not convenient in the least
<grp>
and not necessary
<Regenaxer>
It is trivial to do
<Regenaxer>
: (in '(sh -c "exit 250")) (>> 8 @@)
<Regenaxer>
-> 250
<grp>
you can add the useless part in @@@ if you want
<Regenaxer>
No!
<Regenaxer>
Not another concept!!!
<Regenaxer>
Introducing @@ was a big PITA
<Regenaxer>
The process return code is 16 bits. Period.
aw- has quit [Quit: Leaving.]
<Regenaxer>
Why throw it away without need?
<Regenaxer>
(>> 8 @@) insted of @@ is really trivial
<Regenaxer>
and in sync with 'call'
<Regenaxer>
We can't change call now, might break code
<Regenaxer>
All the error codes of rsync cannot be handled by a script at runbime
<grp>
Not possible on Unix and derivatives. The exit status information returned consists of two 8-bit fields, one containing the exit status, and the other containing information about the cause of death (0 implying orderly exit under program control, other values indicating that a signal killed it, and indicating whether a core was dumped).
<Regenaxer>
yes
<Regenaxer>
So we need 16 bits
<grp>
*sigh*
<Regenaxer>
The pil ref talks of "exit status code", not just "exit code"
<grp>
waitpid() will NEVER EVER TILL THE ENDS OF TIME return anything significative past the 8bit exit code
<grp>
The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] [Option Start] or any other value, though only the least significant 8 bits (that is, status & 0377) shall be available from wait() and waitpid(); the full value shall be available from waitid() and in the siginfo_t passed to a signal handler for SIGCHLD. [Option End]
<grp>
hope this brings some sanity to this discussion
<grp>
no offence
<Regenaxer>
No
<grp>
I'll test it thoroughly once the exit code issue is settled
<Regenaxer>
it *does* return something in case of errors
<Regenaxer>
ie if the value of 'call' is NIL
<Regenaxer>
Anyway we should not change 'call' now
<Regenaxer>
breaks code
<grp>
you sometimes have to break code to fix stuff
<grp>
else you immortalize mistakes
<grp>
aka backwards compatibility
<tankf33der>
cant today
<tankf33der>
very busy
<grp>
to summarize: wait() and waitpid() --> *always* 8bit (even if the return value is 16bit due to sharing the return type with waitid())
<Regenaxer>
It is *not* a "mistake"!! It just returns the full information returned by the internal system call
<Regenaxer>
There must be a reason for it
<Regenaxer>
Why is it in 16 bits?
<grp>
save 1 type definition? they defined the type to express the return of waitid(), then reused it for the other 2
<Regenaxer>
So fine
<grp>
what I just posted is from IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)
<Regenaxer>
Pil cares as little as possible about internals
<Regenaxer>
So it returns it to the user
<Regenaxer>
It is definitely not *wrong*
<Regenaxer>
OK, so shall I remove it all again?
<Regenaxer>
I can still undo the release
<grp>
Pil cares as little as possible about internals <-- in that case, returning an arcane 16bit with empty info that will be never needed is not fine
<Regenaxer>
A single shell command
<grp>
the spirit of picolisp has been always to keep simple and practical
<grp>
you even omited many things commonly found in other languages for the sake of practicity
<Regenaxer>
OK, so I remove it
<grp>
and now you point in the opposite direction
<Regenaxer>
It is also because I'm not sure of the consequences
<Regenaxer>
Setting @@ after the body returns mad override @@ set in the body
<grp>
I also prefer it that you don't release as it was. It will only break more code if it's ever set right
<grp>
s/practicity/practicality
<grp>
anyway.. I'm off, see you another time
grp has quit [Quit: WeeChat 1.6]
<Regenaxer>
removed
<Regenaxer>
Wasted a lot of time on a busy day! :(
<Regenaxer>
I think gpr is deadly wrong. It is better here to return the full internal information. Same as 'native' would do.
<Regenaxer>
Interpreting system values is up to the application
<Regenaxer>
Too bad noone of the "community" had and comments on this :(
mtsd has joined #picolisp
freemint has joined #picolisp
<Regenaxer>
s/and/any/
<freemint>
i just read up on it
<Regenaxer>
Hi freemint
<freemint>
do you return status-exit code or exit-status code?
<Regenaxer>
It is the full status plus exit code
<freemint>
which is stored in the more significant place?
<Regenaxer>
Pil does not care, it is system dependent
<Regenaxer>
On Linux, the lower 8 bit may contain the number of the signal which terminated the child
<Regenaxer>
On some Unixes it has a core dump flag in the highest bit of the lower byte
<Regenaxer>
same if the process was stopped
<Regenaxer>
All those macros in C like WEXITSTATUS WTERMSIG WCOREDUMP WSTOPSIG
<freemint>
mhh ok. I dislike that picolisp does not abstract different unixes away and just gives me a symbol.
<Regenaxer>
I don't want to put in system assumptions and throw away these infos just because grp is too lazy to (>> 8 @@)
<Regenaxer>
It could do, but not for such seldom used cases
<Regenaxer>
this is system programming
<Regenaxer>
like 'native'
<freemint>
I do not need it so far but that would mean that everytime i need work with it and want to write code which runs on any unix i would need to call a boilerplate for every call
<freemint>
furthermore the interpreter has no access to WEXITSTATUS while a picolisp which gets built might have
<Regenaxer>
It must be coded for each architecture
<Regenaxer>
look at src64/sys/x86-64.linux.code.l
<Regenaxer>
this needs to be maintained
<Regenaxer>
and there are limits how system-aware we want to be for each and any esotheic case
<freemint>
maintained once centrally or maintained many time, bug ridden by each user
<Regenaxer>
System programming by definition means to be aware of the system at user time (not pil maintainer time)
<Regenaxer>
For each and any seldom-used case?
<Regenaxer>
where is the limit?
<Regenaxer>
Please you do it!
<Regenaxer>
I'm fed up with iw
<Regenaxer>
it
<freemint>
is getting a return code from a script really system programming?
<Regenaxer>
bye
Regenaxer has left #picolisp [#picolisp]
<freemint>
bye
<freemint>
I get your position and i just stated my opinion
<freemint>
In an ideal world that would have to be done only once. But i do not expect you to do it Regenxer since the worls is not ideal.
pointfree has joined #picolisp
alexshendi has quit [Ping timeout: 250 seconds]
<beneroth>
I agree with Regenaxer. I can understand grp, but he most likely hasn't thought about non-LINUX cases. And Regenaxer is right about not wanting to have always running a parser for the return-value of call, because in like 90% of all uses of (call) it is needless overhead.
<beneroth>
also in case you need this, you can easily do a (redef call ...) to add the required functionality :)
<mtsd>
Hi beneroth
<mtsd>
I missed the discussion leading up to this
<beneroth>
me too, as I just came home and wasn't online
<beneroth>
as I understand it, grp wished an change to (call) concerning the exit code of the called command (or something like this, I didn't understand whats wrong/suboptimal with the current behaviour)
<beneroth>
but this exit codes have (on OS level) a weird definition, they come in 16 bit even when USUALLY only 8 bits of it are meaningful, and only those 8 bit should usually be interpreted as an integer returned from the command, the rest is USUALLY padding, the value is just 16 bit instead of 8 bit for some arcane historic reason.
<beneroth>
I ran into that weird thing before, so yes, this is some weird shit (nothing to do with picolisp)
<beneroth>
now grp wanted that picolisp throws away the (usually) meaningless 8 bits, so that the result is a nice number equaling the exit code of the command.
<beneroth>
but Regenaxer doesn't want to do this, as there might be cases where the full 16 bit value is desired. and there is an OS-independent standard for the format of this value, but in fact different implementations have different variations, and in some cases there is meaningful data in those 8 bits
<beneroth>
so parsing this would 1) throw away stuff that might be needed/wanted by the picolisp programmer, and 2) add a general additional cost to (call) for doing that post-processing of that value, and this cost is not really justified as in most uses of (call) the return value is ignored :)
<beneroth>
3) its OS-dependent, so multiple implementation would be necessary and must be maintained, which is an additional long-term cost
<beneroth>
mtsd, I hope this brings some light :) your thoughts?
* beneroth
goes to read up the full log, to see what the initial feature request was about
<mtsd>
me too
<mtsd>
I always feel like an idiot trying to understand what is going on in these deeper level discussions, haha
<tankf33der>
im not available this week
<mtsd>
I am simply going to trust Regenaxer on this. After all, he is the inventor of Pil and because of that the most experienced Pil programmer in the world ;)
andyjpb has joined #picolisp
mtsd has quit [Quit: WeeChat 1.6]
<beneroth>
tankf33der, ok, thanks for the info :)
<beneroth>
though I will be away tomorrow morning and whole weekend too
<beneroth>
ok
<beneroth>
got it now, idea was to bring the exit code is in @@ also to (in), like it is in (call). good thing. I think Regenaxer should do this.
<beneroth>
the discussion about the format of that value was a fail. just same as (call) and then its fine.