<Regenaxer>
For function parameters, I made a compromize
Blue_flame has joined #picolisp
<Regenaxer>
Supports now also lists of symbols
<Regenaxer>
but only one-dimensional
<Regenaxer>
(de foo (A (B . C) D) ...
<Regenaxer>
i.e. only a top-level list
<Regenaxer>
Full nesting is too expensive
<Regenaxer>
and not so necessary, as seldom used and can be combined with 'let' anyway
<Regenaxer>
But the version of 'let' yesterday was definitely wrong
<Regenaxer>
may explain the test failure
mtsd has joined #picolisp
orivej has quit [Ping timeout: 264 seconds]
<tankf33der>
good
<tankf33der>
i will try create test for that
<Regenaxer>
good
<mtsd>
Good morning everyone
<Regenaxer>
Good morning mtsd!
<mtsd>
Pil21 is progressing well, it seems?
<Regenaxer>
yeah, slowly
<mtsd>
I smiled at a thing you wrote the other day. First, "sigh, I have to re-design some of the co structures again.."
<mtsd>
Then, 30 minutes later: "There, done"
<Regenaxer>
so fast?
<mtsd>
Yes, I think it was something like that.
<Regenaxer>
Coroutines were heavy stuff
<mtsd>
Same afternoon at least.
<Regenaxer>
ok :)
<Regenaxer>
I'm glad that it seems all right now
<Regenaxer>
yesterday also some remaining details
<mtsd>
Similar things happened when you ported to ARM, some years ago. Problems were fixed quickly.
<Regenaxer>
env in varargs
<mtsd>
ok
<Regenaxer>
Let's see how it all turns out
<mtsd>
How is llvm to work with, compared to assembler?
<Regenaxer>
llvm itself is tedious, but writing in the pil frontend lang is a lot easier than pilasm
<Regenaxer>
well, not easier
<Regenaxer>
but a lot more readable
<Regenaxer>
-> maintenance
<Regenaxer>
In some way pilAsm is easier to write
<Regenaxer>
because of more freedom and power
<mtsd>
I see
aw- has joined #picolisp
pointfree has quit [Ping timeout: 260 seconds]
michelp has quit [Ping timeout: 272 seconds]
<aw->
Regenaxer: hi
pointfree has joined #picolisp
michelp has joined #picolisp
<Regenaxer>
Hi aw-
<aw->
is there a quick way to convert 448378203247 into a string?
<Regenaxer>
'format'
<aw->
hmmm
<aw->
wait my question is wrong
<aw->
tell me, is this "slow": (make (if Fd (do 5000 (link (rd 1)))))
<aw->
oops
<aw->
not if
<aw->
in
<Regenaxer>
ok
<aw->
(make (in Fd (do 5000 (link (rd 1)))))
<Regenaxer>
I think this is fine
<aw->
the idea is to read individual bytes, rather than (in Fd (rd 5000))
<aw->
(rd 5000) just gives a really large integer
<Regenaxer>
yeah
<Regenaxer>
Even better would be to process the bytes directly
<Regenaxer>
instead of building a long list first
<aw->
how?
<aw->
what do you mean 'process' ?
<Regenaxer>
I assume you want to do something with the bytes, otherwise you won't read them
<aw->
no, just pass them as-is to another program
<Regenaxer>
Then even more better not to build a list
<Regenaxer>
how about 'echo'?
<Regenaxer>
(echo 5000)
<Regenaxer>
In a pipe
<aw->
ah i see..
<aw->
what if I want to store it in a variable temporarily?
<Regenaxer>
Then a list is needed
<aw->
ok thanks!
<Regenaxer>
:)
<tankf33der>
i should add tests for plio, i dont remember where i use it
<Regenaxer>
Some IPC perhaps?
<tankf33der>
works.
<Regenaxer>
plio?
<tankf33der>
yea.
<Regenaxer>
ok
orivej has joined #picolisp
<aw->
is there plio in javascript?
<Regenaxer>
nope
<aw->
how can i generate it?
<Regenaxer>
ah, wait
<Regenaxer>
there is one direction
<Regenaxer>
I use it in canvas.l for drawing
<aw->
oh you're right!
<aw->
plio.js
<Regenaxer>
@lib/plio.js
<Regenaxer>
yeah
<Regenaxer>
But the other direction is missing
<aw->
amazing
<aw->
this reads it
<aw->
or writes it?
<aw->
reads
<Regenaxer>
yes
<Regenaxer>
Sender is Pil in this case
<aw->
hmmm
<Regenaxer>
It is similar to the C version
<aw->
the C version is easier to grok
<Regenaxer>
I think so too
<aw->
i've been using plio quite a bit in pil21
<aw->
works fine
<Regenaxer>
T
razzy has joined #picolisp
<beneroth>
I like how it makes use of the control characters
<beneroth>
I mean.. like they were supposed to be used...
<beneroth>
who is doing that these days...
<beneroth>
hehe
<Regenaxer>
Hi beneroth! Which control chars do you mean?
<beneroth>
If I remember correctly, plio uses ^A and ^C, no?
<beneroth>
hm...maybe that was not by purpose, just by numbering?
<Regenaxer>
well, it uses 1 or 3 or any number
<Regenaxer>
it is not ASCII in that case
<beneroth>
okay
<Regenaxer>
tag bits
<beneroth>
so..not even Regenaxer uses those control characters, it's just legacy cruft :P
<Regenaxer>
I use ^I, ^M, ^J, ^H :)
<beneroth>
yeah those are not yet legacy :)
<Regenaxer>
I think there is no intention that they will be
<beneroth>
T
<Regenaxer>
And in Vim/Vip almost all are used
<aw->
and ^L
<beneroth>
but well.. there is never the intention that it will be, no? who makes something just to delete it again? except for javascript fans?
<beneroth>
aw-, right, e.g. in CSV.. but not seen so often
<beneroth>
I had ^K in data I had to import, but probably an artifact of the previous database
<Regenaxer>
Also ^S and ^Q for flow control
<Regenaxer>
I would never think they are obsolete
<Regenaxer>
Also ^C
<Regenaxer>
^D
<beneroth>
oh I fully agree with you
<Regenaxer>
^B is used even more often by me, the Tmux command char
<beneroth>
I meant it a tad ironic.. in the context of things like.. doing DNS over HTTP
<Regenaxer>
I even put it on a single arpeggio
<beneroth>
oh I see
<aw->
Regenaxer: can you explain how (line T 1 2 3) works?
<Regenaxer>
ok :)
<aw->
i'm looking at the example but i have no idea
<Regenaxer>
the numbers are fixed widths
<Regenaxer>
for reading a file withe defined columns
<aw->
of the string?
<Regenaxer>
not needed any more so often
<Regenaxer>
yeah
<Regenaxer>
COBOL imports
<beneroth>
unix-style database files
<Regenaxer>
(or FORTRAN)
<beneroth>
basically text files with fixed length columns
<Regenaxer>
T
<aw->
hmm.. so if I want to read a string that is 5 characters, i can do (in Fd (line T 5)) ?
<Regenaxer>
I use 'cutQ
<Regenaxer>
'cut'
<beneroth>
aw-, I think so. If you are sure you will get 5 or more characters, else it will block I think
<Regenaxer>
But yes, (line T 5) is perfect
<aw->
i'm using it to read a stream of bytes
<aw->
from network
<beneroth>
in a way equivalent for (rd 5), but for characters instead of bytes
<Regenaxer>
I think it then skips the rest of the line
<Regenaxer>
hmm, not skips, but returns as a list
<beneroth>
aw-, keep in mind that byte <> char, unless that is ensured (often the case for network) somehow (though who knows what those malicious clients might send you)
<beneroth>
aw-, I also switched for network stuff to using (rd 1) and then immediate processing (with a (state) FSM)) instead of using the text input functions
<beneroth>
more tedious, and probably a bit slower
<beneroth>
so depends on your risk/threat model
<Regenaxer>
I wonder if a malitious input could damage anything somehow
<Regenaxer>
any idea?
<Regenaxer>
as opposed to (rd 1)
<aw->
beneroth: yeah that's what i'm trying to figure out now.. if i want to use (rd 1) and check each byte individually
<aw->
or just blindly accept the bytes as a string
<aw->
"hoping" it's valid
<beneroth>
Regenaxer, I don't think so, not damage. but DoS
<aw->
i think (rd 1) will be much safer
<beneroth>
if you control the number of connections, or even the other side, then I would not worry to much
<beneroth>
if its open to public internet, then better check I would say
<aw->
no control
<Regenaxer>
yeah, no control possible
<Regenaxer>
but DoS is hard to avoid, even with 'rd'
<aw->
too bad... (line T N) is so great
<beneroth>
Regenaxer, as long as no input is stuffed into eval or equivalent, not much risk, code and data is pretty separated in picolisp even when all code can be accessed like data
<Regenaxer>
I think (line T N) is safe
<beneroth>
Regenaxer, NULL-byte as second character in the input? :P
<Regenaxer>
this is no problem
<beneroth>
hm.. T
<Regenaxer>
it gives invalid syms
<Regenaxer>
but (line T N) will not terminate, right
<Regenaxer>
if no eol
<beneroth>
if N is 5, and the other end sends exactly 5 characters, then (line T 5) will also not terminate, btw.
<Regenaxer>
So 'char' is better than 'rd'
<Regenaxer>
not terminate, but just wait
<beneroth>
T
<Regenaxer>
can be 'abort'ed
<beneroth>
I don't find char better, necessarily
<beneroth>
because the sender could shovel you and endless big unicode character, no?
<Regenaxer>
But re-assembling UTF8 is tough
<Regenaxer>
no
<beneroth>
then you also never terminate but keep busy reading garbage, no?
<Regenaxer>
max 4 bytes
<beneroth>
ok
<Regenaxer>
nonsense unicode
<aw->
like (char (hex "dfff"))
<beneroth>
yeah
<Regenaxer>
right
<Regenaxer>
Most random combinations are not legal utf8
<Regenaxer>
Must be of the form
<Regenaxer>
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
<Regenaxer>
for 4 bytes
<Regenaxer>
single byte (ASCII) is 0xxxxxxx
<Regenaxer>
BTW, pil uses one special char 0xFF
<Regenaxer>
it is "infinite"
<Regenaxer>
used only internally
<Regenaxer>
(char T)
<beneroth>
no way to inject it?
<beneroth>
ah ok
<Regenaxer>
I think upon input it gives normal nonsense
<Regenaxer>
It also cannot be printed
mtsd has quit [Quit: Leaving]
<Regenaxer>
only 'pack'ed with other chars
<Regenaxer>
useful for string comparisons
<Regenaxer>
(>= (pack "z" (char T)) Chr "a") or so
<Regenaxer>
otherwise you cannot do range checks
<Regenaxer>
eg in DB tree searches
<beneroth>
ooh
<beneroth>
I was not aware of this trick
<Regenaxer>
:)
<Regenaxer>
It is in pil since the earliest DB versions
<beneroth>
should be documented in the DB stuff or at (pack) :P
<Regenaxer>
I thought it is there (?)
<Regenaxer>
yes, in 'char'
<beneroth>
not at pack
<aw->
sorry to jump in again, Regenaxer regarding UTF-8
<Regenaxer>
special case
<beneroth>
T
<Regenaxer>
ok
<beneroth>
aw-, feel free, I'm mostly just babbling...
<Regenaxer>
me too :)
<aw->
the unicode sequence 'EF B7 90' in UTF-8, is FDD0 in UTF-16
<aw->
how do i make sense of that?
<beneroth>
you have UTF-16 input you must convert to UTF-8 ?
<Regenaxer>
it is packed as this: 1110xxxx 10xxxxxx 10xxxxxx
<Regenaxer>
the x's are the bits
<Regenaxer>
16 bits in this case
<aw->
16 bits? but there's 3 bytes
<Regenaxer>
yes
<Regenaxer>
and 16 x's
<aw->
so the utf-8 representation requires 3 bytes due to the encoding?
<Regenaxer>
1110xxxx is EF in your example
<aw->
yep
<Regenaxer>
it takes more space, but is variable in length
<aw->
hmmm
<Regenaxer>
it is a brilliant format I think
<aw->
so if I want to read a stream of bytes, I can't just check each byte
<Regenaxer>
preserves order
<Regenaxer>
you cannot?
<aw->
assuming i'm using (rd 1) and placing each byte into a list
<Regenaxer>
You can, but this is why I said it is tough
<Regenaxer>
assembling the chars
<aw->
righttt...
<aw->
that's what i was getting to
<aw->
how to reassemble
<Regenaxer>
Calling 'char' is the easiest
<Regenaxer>
it does exactly that
<aw->
(mapcar char Lst) ?
<aw->
doesn't seem right
<Regenaxer>
you could look at 'mkChar' in pil21/src/sym.l
<Regenaxer>
no, this won't work
<beneroth>
manual reassembly would mean 1) identifying which bytes belong to one character 2) turning that list of bytes into a single number 3) put that into (char) ?
<Regenaxer>
right
<Regenaxer>
pil has no built-in which does this from a list
<aw->
ok
<aw->
so how do I do it?
<Regenaxer>
Why not call 'char'?
<aw->
if I have a list ("ef" "b7" "90") it should really be "fdd0"
<Regenaxer>
otherwise you need to implement it
<Regenaxer>
yes
<Regenaxer>
look at the masks and shifts in 'mkChar'
<Regenaxer>
such code is in several places in pil
<aw->
what do you mean 'call char' ?
<aw->
(char "ef" "b7" "90")
<aw->
-> 101
<Regenaxer>
also in packing etc
<aw->
yes it looks complex ;)
<Regenaxer>
(in Fd (make ... (link (char))
<Regenaxer>
instead of (link (rd 1))
<aw->
ohhhhh...
<aw->
i didn't know that was possible
rob_w has quit [Quit: Leaving]
<Regenaxer>
ah, ok :)
<aw->
"(char "ef" "b7" "90")
<aw->
"When called without arguments, the next character from the current input stream is returned"
<Regenaxer>
no, this is not supported
<Regenaxer>
yes
<aw->
i seem to have missed that part of the doc ;)
<aw->
the first line
<Regenaxer>
char takes care to fetch the bytes
<aw->
well this is wonderful
<beneroth>
(char) returns a UTF-8 character
<beneroth>
:)
<beneroth>
so with if you have things like byte size of content in your network protocol... well hard to check :)
<Regenaxer>
At worst read into a buffer
<Regenaxer>
tmp file or so
<Regenaxer>
hmm, not really
<Regenaxer>
It all depends on the situation, as always