<beneroth>
I didn't now about this special twist of Mac
<Regenaxer>
me neither. I believed ints default to 64 bits
<beneroth>
not sure if its worth to change waitFd just for Mac at the current usage rates
<Regenaxer>
and poll(2) is a bad design too
<Regenaxer>
hmm, but iOS probably too, no?
<beneroth>
as anyone ever got pil21 working on iOS?
<Regenaxer>
I'd like to see PilBox ported to iOS
<Regenaxer>
I don't think so
<beneroth>
how long would that work anyway, when Apple is switching to their new custom chips in mobile soonish? (and PC's too)
<beneroth>
packaged app without sideloading might be acceptable for Apple policies
<beneroth>
hmmm
<beneroth>
well ok I guess we can expect LLVM to support the new Apple chip too
<Regenaxer>
On Mac it is not an issue of tfne CPU
<Regenaxer>
but the Unix
<beneroth>
previously we thought only the Mach binary format was the issue, and maybe outdated posix tooling
<beneroth>
but posix implementation seeems to be too big of a difference too, to run smoothly
<beneroth>
which appears not to be an issue on the BSD's as far as we know
<Regenaxer>
It is this ABI
<Regenaxer>
in BSD
<Regenaxer>
defined ints as 32
<Regenaxer>
not a
<Regenaxer>
CPU or compiler issue
<beneroth>
ah, so the Mac issue is also a BSD issue?
<Regenaxer>
Not sure which BSDs use which ABI
<beneroth>
but then how did bignums ever work on Mac?
<Regenaxer>
Bignums are pil only
<beneroth>
I mean all numbers between 32bit and 64bit
<Regenaxer>
it is the system calls
<Regenaxer>
no
<beneroth>
ah only there
<beneroth>
ok
<beneroth>
yeah makes sense
<beneroth>
of course
<beneroth>
sorry
<Regenaxer>
llvm code uses i64 everywhere
<beneroth>
ok
<beneroth>
so native and system calls
<Regenaxer>
yes
<Regenaxer>
It is my fault in src/lib.c
<Regenaxer>
gPoll()
<Regenaxer>
it does a cast to (int) when calling poll()
<Regenaxer>
But I don't like timeouts to be limeted to 24 days only
<Regenaxer>
so poll(2) is a mis-design
<Regenaxer>
Most posix system calls use long
<Regenaxer>
buw poll() uses int
<Regenaxer>
So I could rewrite the logic of waitFd(), but the 24 day limit will remain then
<Regenaxer>
I don't even need to rewrite waitFd() probably
<Regenaxer>
just use a smaller maximum
<beneroth>
what is the limit in pil64 ?
<beneroth>
same as pil21?
<Regenaxer>
good question
<Regenaxer>
I don't remember :)
<Regenaxer>
pil64 uses select() which does not have that problem
<Regenaxer>
it uses even 128 bits for the timeout iirc
<beneroth>
I have one app which has a background process, just an extra child which might get stuff to do via DB. sometimes it hangs up, strace shows its endless looping in select() call. Haven't had time to investigate properly, but I suspect an issue with a broken pipe.
<beneroth>
no pattern to when it happens... sometimes not for months
<beneroth>
ah ok
<Regenaxer>
looping in select() is usually a bad file desc
<beneroth>
yeah
<Regenaxer>
the 128 bits are 2 numbers
<Regenaxer>
seconds and nanoseconds
<Regenaxer>
poll() uses millisecs
<beneroth>
I see
<beneroth>
different use cases
<Regenaxer>
yeah
<Regenaxer>
select() has other limits
<Regenaxer>
1024 FDs only
<beneroth>
ah
<beneroth>
also pretty limiting for some use cases.
<Regenaxer>
indeed
<Regenaxer>
a problem if many child processes
<Regenaxer>
so I switched to poll()
<beneroth>
yeah good decision I'd think
<Regenaxer>
So I should switch to 32 bits for the timeout
<Regenaxer>
feels not right
<Regenaxer>
Is a max timeout of 24d acceptable?
<Regenaxer>
If a bigger value is specified, it would use -1 internally and just be infinite
<Regenaxer>
ugly :(
<Regenaxer>
I thought 292 million years are not a problem
<Regenaxer>
but 24 days are very short :(
<beneroth>
aye, would cause problems for mostly-doing-nothing
<beneroth>
might even be a problem for webservers when there is no connection/request for more than 24d ?
<beneroth>
or it's a just a return, which does nothing, and starts the poll for 24d again?
<Regenaxer>
probably no problem
<Regenaxer>
there is no such timeout
<Regenaxer>
Max timeout I used was 1 day iirc
<beneroth>
ah ok
<beneroth>
well then just do it
<Regenaxer>
yeah
<beneroth>
as I understand currently: not beautiful, but not relevant
<Regenaxer>
T. I take a look later what it implies
<beneroth>
thank you :)
<Regenaxer>
:)
<Regenaxer>
The result would be that if passing more than 24 days to (wait), (key) etc., it would *not* wake up after that time but sleep forever. Other timeout (i.e. 'task's) wake it up meanwhile of course.
<beneroth>
I see
<beneroth>
document and ok
<Regenaxer>
yep
<Regenaxer>
Technically a simple change
<Regenaxer>
Hmm, good idea!
<Regenaxer>
As this is a C glue function in src/lib.c, we can even make a compile-time sxitch
<Regenaxer>
*switch
<beneroth>
oh nice
<beneroth>
right
<beneroth>
ifdef
<Regenaxer>
Only systems with sizeof(int) == 4
<Regenaxer>
hmm, but how? syntactically
<beneroth>
well it's ugly because that means application code would be executed differently depending on the OS/platform. doesn't matter for most code, but not so nice
<Regenaxer>
it is not an ifdef
<Regenaxer>
true
<Regenaxer>
But is it legal in C to do #if sizeof(int) < 8 ?
orivej has quit [Ping timeout: 252 seconds]
<Regenaxer>
or how else to code it?
<aw->
hi all
<aw->
i saw the mailing list post
<aw->
i dont like the idea
<Regenaxer>
Hi aw-!
<Regenaxer>
The idea of changing 24 days to infinite?
<aw->
i dont like the idea of changing to 32 bits
<Regenaxer>
Yeah
<Regenaxer>
ugly
<Regenaxer>
But on such ABIs there is no other way, right?
<Regenaxer>
poll() uses only the lowest 32 bits of the timeout
<aw->
not familiar
<Regenaxer>
If we find a good syntax for #if, then "good" sysystems do not change ;)
<aw->
sorry
<Regenaxer>
familiar with what?
<aw->
with those low-level C ABIs
<Regenaxer>
In this case it is only sizeof(int), I think usually you are aware of it when writing C
<Regenaxer>
ABIs imply more, like register assignments, argument and return value passing etc.
<Regenaxer>
but also which C type has which size
<Regenaxer>
Does anyone know the syntax spec of the C #if ?
<Regenaxer>
can I use it with sizeof()?
<Regenaxer>
I never used it this way
<Regenaxer>
Will search later
<beneroth>
Regenaxer, afaik the C you posted is legal. Probably not meaningful, as int is likely at least 8 bits
<Regenaxer>
sizeof() gives bytes, not bits
<beneroth>
Regenaxer, I guess because many C programmers are used to see int = 32bits (as that was true for mainstream C programming for a while) was the reason that BSD said lets define this fix
<beneroth>
ah right
<Regenaxer>
I try #if sizeof(int) < 8 later
<beneroth>
must be fine
<Regenaxer>
cool
<Regenaxer>
will try, just need to finish something
<beneroth>
most C programs I see do these days define their own numeric types (e.g. int32, int16, ...) based on char (char is fixed as always 1 byte independent of platform)
<Regenaxer>
yeah
<Regenaxer>
same in llvm
<Regenaxer>
i64 etc
<Regenaxer>
even i1
<beneroth>
no reliability otherwise
<Regenaxer>
right
<Regenaxer>
System calls usually also use e.g. size_t
<beneroth>
language design mistake
<beneroth>
yeah
<beneroth>
or counts of iterations/sizes in linked lists etc. also, because you just want the biggest numeric datatype
<beneroth>
(not that this use would be safe concerning overflows, but that is a slightly different problem)
olaf_h has joined #picolisp
<beneroth>
hey olaf_h :)
<olaf_h>
hi beneroth
<Regenaxer>
mom, tel
<Regenaxer>
done
<Regenaxer>
hi olaf_h!
<olaf_h>
hi regenaxer - no questions today so far from my side :-)
<Regenaxer>
good :) Though questions are always welcome
<olaf_h>
I know, astonishing how quick your answers appear, most of the times.
<Regenaxer>
I hear the ping :)
<Regenaxer>
But atm we were discussing here anyway
<Regenaxer>
Puh, I need the number o s files in 420 directories :(
<Regenaxer>
s/o s/of
<Regenaxer>
(penti "o s" is a failed "f" ;)
<Regenaxer>
"of" I mean
<beneroth>
find can probably do it
<beneroth>
iterating over many files (even when tiny) is always a consuming struggle too
<Regenaxer>
yes, but perhaps too slow
<Regenaxer>
I need it in a seach dialog
<Regenaxer>
so called 20 times
<beneroth>
build a cache
<beneroth>
update with inotify or so
<Regenaxer>
these files change all the time
<beneroth>
I would think 'find' is the fastest way to do file iteration
<tankf33der>
Even hard to understand what they talking about, thats why i was passive
<Regenaxer>
Strange!
<Regenaxer>
Andras writes that int's are 32 bits
<Regenaxer>
so poll(2) will not work with a big timeout
<Regenaxer>
So are there different versions of MacOS?
<olaf_h>
new macs have new processor and emulator inside or sth like this?
<Regenaxer>
The processor does not matter
<Regenaxer>
It is the operating system
<Regenaxer>
poll(2) is a system call
<Regenaxer>
man 2 poll
<Regenaxer>
it takes an 'int' for the timeout value
<Regenaxer>
And pil assumes 64 bit timeout values
<Regenaxer>
Anyway, I built a conditional into src/lib.c
<Regenaxer>
which handles this *if* int's are only 32 bits
<Regenaxer>
But I had believed that on modern OSes int'sare always 64 bits
<Regenaxer>
Obviously not ... :(
<Regenaxer>
Question is also what happens on iOS
<beneroth>
re
<Regenaxer>
wb :)
<Regenaxer>
See turn of insights above ;)
<olaf_h>
thanks for the hints, beneroth and regenaxer, command line output now fetched by using (in '(xmlstarlet...) (line T))
<beneroth>
nice
<Regenaxer>
👍
<Regenaxer>
Sh.t. Now one process on my production server hangs
<olaf_h>
and my initial unknown^^ question was solved like this: (mapcar name '( <... words typed in as if I were on the bash ....> )
<Regenaxer>
No idea if this is caused by the changed timeout logic
<Regenaxer>
olaf_h, how do you type in like in bash?
xkapastel has joined #picolisp
<beneroth>
olaf_h, using name seems wrong to me.
pp has joined #picolisp
<beneroth>
olaf_h, (name) is a function you probably never need in most programming. Only maybe when you exchange data between multiple picolisp applications or when you want to communicate pilDB identifiers (external symbols) to input/output
<tankf33der>
Testing macos
<beneroth>
Regenaxer, correct me, but I've used (name) for anything else yet :)
<beneroth>
thx tankf33der
<beneroth>
Regenaxer, s/anything/nothing
<Regenaxer>
I do use 'name' sometimes to get a new transient symbol
<Regenaxer>
cool tankf33der!
<Regenaxer>
(name 'a) is a little more efficient than (pack 'a)
<beneroth>
ah I see
<Regenaxer>
Probably more efficient, not much
<beneroth>
yeah. also counts as atypical edge case, I would say :P
<olaf_h>
i do not want to read from the repl, i want to reduce keyboard strokes while typing in the code line into the .l file
<Regenaxer>
Tab expansion?
<olaf_h>
no, just convert the string without quotes into a string with quotes .... foo -w -t into "foo" "-w" "-t" because the last is what (in) requires to execute a command)
<Regenaxer>
ah
<Regenaxer>
But for 'call' or 'in' this is not necessary
<Regenaxer>
(call 'ls '-l)
<Regenaxer>
you need to quote somehow
<Regenaxer>
(in '(ls -l) ...)
<Regenaxer>
But note that these symbols are interned unnecessarily
<olaf_h>
yeah, only for development, not for productive use
<olaf_h>
how to put a filename var *Fn in the example (in '(ls -l *Fn )...) ?
<Regenaxer>
then you cannot quote it
<Regenaxer>
(in (list "ls" "-l" *Fn) ...
<olaf_h>
could'nt one use the reader somehow .... is the reason for 'then you cannot' that there is no quote in picolisp?
<olaf_h>
no ... forget it .... sorry .... i'm fine with using the editor for a region regexp replace
<Regenaxer>
It is not a reader thing
<Regenaxer>
it is how evaluation works
<Regenaxer>
Quoted is quoted :)
<beneroth>
quoted = not evaluated = taken as written in source code, variable value not looked at
<beneroth>
what you want is possible
<beneroth>
(in (list 'ls '-l *Fn) ...)
<olaf_h>
okay. and i'm only thinking of editing, so one day perhaps (if my pil knowledge would grow) i could do this in vip somehow, like i would now in emacs
<beneroth>
now the list argument is not quoted, but actually the (list) function is calling building a list before passing it to (in)
<beneroth>
so 'ls and '-l must be quoted, as they would be evaluated otherwise (and as you probably haven't defined/bound any variables with that name, they evaluate to value NIL)
<beneroth>
*Fn is then evaluated and it's value built into the list instead of the symbol *Fn
<beneroth>
so make the (in) as I did just here above, and before that (in) gets called/evaluated, to somewhere (setq *Fn "blablabla file blabl whatever") before
<beneroth>
was my explanation understandably worded?
<olaf_h>
yes, beneroth, thank you.
<Regenaxer>
perfect beneroth!
<beneroth>
things things might look confusing at the beginning (when to quote, when not to quote), but it's the very essence of picolisp (important to keep in mind that it's purely an interpreter, no compilation or translation of the source code happening)
<beneroth>
once you grokked how that works, the code writing becomes logical, natural and easy
<beneroth>
I made the same experiences as you in the beginning :) no worries
<olaf_h>
:-)
<olaf_h>
my issue was an off-repl topic i think :-) it was more kind of an editor topic .... or coders best practice topic
<beneroth>
yeah
<beneroth>
olaf_h, you did see the external paste I made? it's deleted in the meantime, but was example for making some wrapping function to (call) for easier use in source code (or also interactively in repl)
<olaf_h>
yes i saw the paste, beneroth, thanks. that gave me a hint to study call doc again so i saw that you were right to guide me towards (in
<beneroth>
ah alright
<olaf_h>
i tried to use the stdout and err redirection i saw there but that didnt work in my repl.
<olaf_h>
idea was to check if the tool exists by (call 'tool "--version")
<olaf_h>
but the 1>/dev/null 2>&1 did not work
<olaf_h>
so the version output spammed the repl
<beneroth>
ah
<beneroth>
that doesn't work because output redirection is a shell program feature, not a feature of calling other programs in general (and neither of the OS)
<beneroth>
don't call the target program directly, but call a shell ( /bin/sh in this case, but you can also use /bin/bash or whatever you have/prefer)
<beneroth>
I learned this actually from Regenaxer :) a bit longer ago ^^
<beneroth>
olaf_h, same applies to path autocompletion with *, e.g. somedirectory/* or *.pdf or such things.. that is also a mechanic/feature of the shell which turns it into a list of all possible matches before calling the program you entered in the terminal
<olaf_h>
ah, that makes sense ....
<beneroth>
when you know it, then its kinda obvious and natural
<beneroth>
but one has to know that
<beneroth>
not obvious if you always worked directly in the shell
<beneroth>
and as Regenaxer said, system() call function in other language appears to be calling the shell always
<beneroth>
which ends up with another process in between, so a bit more overhead
<olaf_h>
i did not know that it's possible to run commandline tools without a shell
<beneroth>
in picolisp you can decide if you need/want that or not, and it's clearly visible in the code
<beneroth>
well that is how the shell itself is doing it, as shell in unix is also just a normal program
<beneroth>
might not be true for windows, no idea
<beneroth>
if you want to be funny, you could also replace your login shell in linux directly with a picolisp repl :DD
<beneroth>
so you will already be trained to use PilOS when it gets released in some utopian year :P
<olaf_h>
:-)
<olaf_h>
PilOS had no internet or network stack as i remember, i never looked into
<beneroth>
yep exactly xD
<beneroth>
and can only be started on some very few chipsets
<beneroth>
or qemu emulator
<beneroth>
(which is ok and standard for virtual servers)
<olaf_h>
ah, okay, good to know, i never tried on my hardware here.
<beneroth>
so it's quite useless at the moment and implementing a network stack is a huge undertaking and not very funny (the spec is clear, but the real life de-facto standards and bullshit you have to tolerate from buggy implementations/devices is horrible, I heard)
<Regenaxer>
T
<beneroth>
you might be able to run PilOS as a virtual server, and connect via emulated serial console to it and use it for computing, that might actually be possible and probably pretty secure
<beneroth>
but the uses cases for that.. aren't so many neither
<beneroth>
I haven't tested that, just an idea which might be work
<beneroth>
could be a sandbox environment which could be made available public to the internet without much risks, I guess
<olaf_h>
bye for today. thanks for the help and explanations!
olaf_h has quit [Quit: Leaving]
<Regenaxer>
tankf33der: In the mail Andras wrote "The pil21 demoApp does not work on macOS". Is that the case?
<Regenaxer>
oh, just now he wrote a new mail
<tankf33der>
reading
<Regenaxer>
I answer now
<Regenaxer>
Sent
<tankf33der>
i will try demoapp in several hours
<Regenaxer>
It looks like the socket descriptor is wrong somehow