<geri>
technically less code, but its all moved to pil side and loses performance because of that...
<abu[7]>
I have some GUI functions which do not evaluate, so I'm forced to 'macro' them, as you said, ugly
<geri>
very
<geri>
also i think on C side it'd be easier to do this way ive posted
<geri>
just eval first arg and pass everything to let
<geri>
not like it really matters, but it makes sense if thinking about minimizing code repetition
<geri>
(except bind and let take arguments differently so it wont work XD)
<abu[7]>
Sometimes code repetition is also more clear
<abu[7]>
in addition to performance
<geri>
*some* times
<abu[7]>
In any case built-ins should be as fast as possible
<geri>
ye i know
<geri>
does pilsrc have macros :)
<abu[7]>
It is normal pil
<abu[7]>
Unless overridden, everything is available
<abu[7]>
And t
<abu[7]>
oops
<abu[7]>
RET instead of BS
<geri>
aight, going for a walk
<geri>
laters
<abu[7]>
See you! :)
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
f8l has quit [Remote host closed the connection]
f8l has joined #picolisp
* geri
is totally still walking
<abu[7]>
Wow
<geri>
:D
<geri>
nah i worked for the whole day
<abu[7]>
ok
<geri>
also on my laptop bluetooth has seemingly died so i cant use my fancy keyboard atm :()
<geri>
:(*
<abu[7]>
brb
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
rob_w has quit [Ping timeout: 256 seconds]
<geri>
abu[7]: did the cat attack you again
<geri>
)
<abu[7]>
No :) I did some experiments
<geri>
iyo, what are downsides of dynamic scoping (or binding? idk :D)
<abu[7]>
Yes, binding. You may get hygenic problems analog to macros in CL
<geri>
hygienic*?
<geri>
that the thing you got naming conventions for?
<abu[7]>
Yes
<abu[7]>
There is a note about t
<abu[7]>
hat in the FAQ
<abu[7]>
doc/faq.html#problems
<geri>
right
<geri>
i saw some comments about for example
<geri>
(de x () y) (de z (y) (x)) (z 5) => 5
<geri>
"oh that's not intuitive and hard to read"
<abu[7]>
T, free vars
<geri>
imo dont just have free variables sprinkled around without a reason if you find it hard to read
<abu[7]>
(lint) will complain
<abu[7]>
I recommend (lintAll) from time to time
<geri>
i mean, free vars can be good, just dont abuse them
<abu[7]>
right
<geri>
its not such a hard footgun to avoid anyway
<abu[7]>
Another reason is that lexical binding is better to compile
<abu[7]>
Gives more efficient code
<abu[7]>
Moment, brb
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<geri>
the cat won't stop crashing you!
<geri>
(very bad joke, but I doubt I'll never stop it :D)
<abu[7]>
Nope, it sleeps on the floor
<abu[7]>
Experimenting with the irc client
<geri>
i know, just being silly
<geri>
what's lit for?
<abu[7]>
It means "literal"
<abu[7]>
for quoting after eval
<geri>
after eval?
<geri>
got an example?
<abu[7]>
There are several in the distro
<abu[7]>
once more
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<geri>
can't you open a second client and join with a different nickname instead of leaving all the time?
<abu[7]>
I did
<geri>
hmm
<abu[7]>
A separate new channel
<abu[7]>
But I wanted to test something
<abu[7]>
For now I reverted here to old versipn
<geri>
aighty
<geri>
did you ever need to drop down to C for performance reasons?
<abu[7]>
In pil32 ?
<geri>
in any pil
<abu[7]>
I think I always anticipated a potential bottleneck
<geri>
but never found one? :D
<abu[7]>
I don't remember *any* performance problems in code
<beneroth>
with pil, performance problems are usually just bad programming
<abu[7]>
I DB on pil32 early
<abu[7]>
needed B-Trees then
<beneroth>
or something which picolisp is not optimal for, then you can always implement it as pil library
<abu[7]>
T
<beneroth>
abu[7], ht library you did just out of anticipation? or mainly for the buffered ht:Out ?
<abu[7]>
anticipation
<beneroth>
top
<abu[7]>
I thought it is heavily used
<beneroth>
geri, you saw the bit about ":" being an optional read macro.. kinda
<beneroth>
abu[7], it is
<geri>
beneroth: when?
<abu[7]>
T, but perhaps even here not critical
<beneroth>
geri, when a symbol has : in the name, the reader looks first for the symbol/function in a library (in the run dir). e.g. (ht:pack ...) will fetch 'pack from 'ht' library
<geri>
sounds cl-ish!
<abu[7]>
It is not a read maco
<beneroth>
the library is assumed to be implemented in the picolisp "host language"(?), so in C for the 32bit picolisp C implementation, in asm for the 64bit picolisp AMD-asm implementation, and in compiled LLVM for pil21
<geri>
did you implement that as a library?
<beneroth>
abu[7], is it upon reading or upon function call?
<abu[7]>
it is an error fallback
<beneroth>
right!
<beneroth>
when the reader does not find it, before creating it, it looks for the lib. <-- correct?
<abu[7]>
Not the reader
<abu[7]>
the interpreter
<abu[7]>
if undefined, it looks for a lib
<abu[7]>
foo:bar
<beneroth>
geri, check out @lib/ht.so and @lib/ext.so and @src/ht.l @src/ht.ll etc.
<beneroth>
abu[7], ok, so during evaluation
<abu[7]>
a legal symbol
<abu[7]>
yss
<beneroth>
I will try to remember, thanks for correcting :)
<abu[7]>
:d
<abu[7]>
:)
<geri>
i dont have ht.l/ll, only .so
<abu[7]>
not @src/ext.l ?
<abu[7]>
and ht.l
<abu[7]>
Must be
<geri>
oh, in src
<abu[7]>
yeah
<abu[7]>
It builds @lib/ext.so
<geri>
again with the two letter name for the library file without any explanation header...
* geri
craves docstrings
<beneroth>
yeah, unfortunately ht and ext are not really documented :(
<geri>
what does ht stand for at least
<beneroth>
I used to say I will make one eventually, but so far I haven't neither :$
<beneroth>
http xD
<abu[7]>
@oc/ref.html#libs
<beneroth>
help library for low level http functionalities
<abu[7]>
Yes, ht is for hypertext
<beneroth>
url encoding and url decoding, and most importantly: chunked output
<geri>
ah okay
<abu[7]>
Right, chunked is indeed time critical
<abu[7]>
complicated at least
<abu[7]>
and an insane concept
<beneroth>
I would say the complicated part is the buffering, buffering up until its a chunk
<beneroth>
not so feasible to do on lisp level
<beneroth>
abu[7], insane? you mean, because it's kinda unnecessary and bloated, instead of just sending a stream?
<abu[7]>
T
<abu[7]>
use dynamic buffers on the receiver side
<beneroth>
ah, but dynamic buffers are not C-style
<beneroth>
much to safe
<beneroth>
not enough prone to security critical bugs
<abu[7]>
You can do fine in C
<geri>
itsd funny that pil breaks tradition on lambdas & quote, backquote and other stuff, but is traditional in being a dynamically scoped interpreted lisp :D
<abu[7]>
realloc()
<beneroth>
yeah, but not stylish enough. like dynamic sized arrays :P
<beneroth>
abu[7], you are right about chunked http stream. It gives additional metadata for the client to decide upon, maybe - but then what options does the client has? either it can handle it or not. so same options when receiving the stream directly without additional metadata.
<geri>
didnt get the comment about dynamic arrays
<geri>
functions just being lists is real stylish imo
<beneroth>
T I think so too
<abu[7]>
Tests finished, last time brb ;)
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<geri>
wb
<abu[7]>
☺
rick42 has quit [Server closed connection]
rick42 has joined #picolisp
<geri>
is there an example of a picolisp-based REST API anywhere?
<abu[7]>
Perhaps pablo_escobert
<abu[7]>
I'm not sure about the terminology. I believe the pil web server is REST out of the box, but I never really cared what exactly that means.
<abu[7]>
eg. PUT is not supported
<geri>
in this case just a server you start and then can curl different endpoints of it as needed
<abu[7]>
(redundant as I believe)
<abu[7]>
That is possible
<geri>
cool
<geri>
any very basic examples?
<abu[7]>
How about the wiki?
<abu[7]>
In any case you can even call any Lisp function on the server