beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
retropikzel has joined #picolisp
retropikzel has quit [Quit: Leaving.]
geri has joined #picolisp
retropikzel has joined #picolisp
<geri> hoi, it's a bit trashy but i wrote a combinator parser in pil: https://0x0.st/XBmo.l
<geri> (was fun!)
retropikzel has quit [Quit: Leaving.]
retropikzel has joined #picolisp
retropikzel has quit [Client Quit]
<abu[7]> Hoi geri! Nice!
Iacob has quit [Ping timeout: 260 seconds]
retropikzel has joined #picolisp
<geri> does anything look like a very bad practice logically in the code?
<geri> i guess i could make some more chops read-time
<geri> like in _parse_symbol
<abu[7]> Looks good (have not studied all though)
<geri> oki, thanks
<geri> too much code to study for fun anyway
<geri> :D
<abu[7]> :)
<geri> i remember you saying something about overhead of running functions
<geri> is it mostly because of env extension in pil's case?
<geri> or that + C call stack stuff
<abu[7]> It it is the binding of the parameters and other interpretation overhead (llvm~evList -> llvm~evExpr)
<abu[7]> Simply much to do
<abu[7]> What do you mean with env extension?
<geri> (quote (X) (print X)) - extends environment with X then does eval on body, no?
<geri> except its a bit different cause symbols store values
<abu[7]> Correct
retropikzel has quit [Ping timeout: 264 seconds]
<abu[7]> It is the current binding env
<abu[7]> llvm~eval is inlined, and fast for numbers and symbols
<abu[7]> Else evList is called
retropikzel has joined #picolisp
Iacob has joined #picolisp
<geri> does inlining really just repeatedly inject the code every time it would be called?
<abu[7]> Yes, it is duplicated in @src/base.ll
<abu[7]> (llvm does further inlining if the optimizer thinks so)
<geri> so larger executable cause duplication but faster cause no messing with call stack?
<abu[7]> The executable size is not related to the stack size
<geri> those are 2 separate sentences
<abu[7]> But larger executable may in fact be slower
<abu[7]> cache misses
<geri> inlining makes executables larger cause code is duplicated
<abu[7]> T
<geri> inlining makes code faster cause you dont need to assign variables or anything - it just evaluates stuff in-place
<geri> connected with "but"
<geri> :D
<abu[7]> It is mostly only faster because a call/return is avoided
<abu[7]> Vars are mainly in registers
<geri> i kinda meant that, didnt say it properly tho
<geri> okay, cool
<abu[7]> Perfect
<geri> lambdas just being encoded lists makes so much sense now
<geri> if it were a list with "lambda" symbol as first argument it'd be slightly innacurate for non-evaluating functions
<geri> and its a bit simpler like that too
<geri> and makes perfect sense with the quote returning all args decision
<geri> :D
<abu[7]> ☺
<geri> surprised vip doesn't have ; command implemented
<geri> how do you jump to second paren in the line?
<geri> f(f( is not so nice
<geri> oh wait, maybe 3f(
<abu[7]> T
<abu[7]> And Penti and Steno have a "repeat the last two keys" key :D
<geri> haha
<geri> also how do you comment multiple lines quickly?
<geri> i only figured out !}sed 's/^/# /'
<geri> or 5!sed ...
<abu[7]> Usually I do "j," repeatedly
<abu[7]> "j." I mean
<abu[7]> just keeping the above double key on auto-repeat
<abu[7]> Of course also #{...}#
<geri> wtf it had block comments?
<geri> XD
<abu[7]> Yes
<geri> and its the type you can do mid-line
<geri> amazing
<abu[7]> Often I use NIL to "comment" the rest
<geri> oh you reminded me
retropikzel has quit [Ping timeout: 264 seconds]
<geri> in the combinator parser i wanted to only run main function when not in debug mode
<geri> i wanted to do (not *Dbg) but it didnt seem to work
<geri> so i had an unless *Dbg
<abu[7]> `*Dbg
<geri> oh
<abu[7]> It is used often in the sources
<abu[7]> lib.l
<geri> okay, i thought if it evals to nil itll be an exit too for some reason
<geri> just had to do readtime eval
<geri> cool
<abu[7]> T, just stops 'load'
<geri> overall, is inverted dbg weird? :D
<geri> i just dont like main running when im trying to edit stuff
<abu[7]> I often use :l in Vip
<geri> itll evaluate everything though, no?
<abu[7]> save + load
<abu[7]> T
<abu[7]> ^E evals 1 exe
<geri> yeah, i use that
<geri> rn workflow was > pil combinators.l + > (vi 'combinators.l) > mess with stuff
<abu[7]> 👍
<abu[7]> You can also "qz"
<abu[7]> to drop back into REPL
<abu[7]> Then (v) to continue editing
<geri> yeah
<geri> i wish i could see whole print outputs when using ^E
<abu[7]> You can do "-"
<abu[7]> increases the command win
<abu[7]> or "+" *in* the command win
<abu[7]> "qj" into the command win lets you edit it
<abu[7]> Return re-executes commands
<geri> oh hell yeah, - is exactly what i needed
<abu[7]> I never understood whv Vim has different editing for the command win
<abu[7]> (or just "command line")
<geri> there was a hotkey to make command window into a properly-editable buffer
<geri> but i forgot what it was
<abu[7]> Oh, I see
<abu[7]> did not know
<abu[7]> Vim has very many features
<geri> mhm
<geri> not as many as emacs though B)
<abu[7]> True
<abu[7]> another dimension ;)
<geri> yes!
<geri> wanted to send the editor learning curve meme but its kinda hard to find a proper pic url
geri has quit [Ping timeout: 268 seconds]
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
user3456 has quit [Quit: I use ZNC - https://znc.in]
geri has joined #picolisp
confucian-refact has joined #picolisp
<confucian-refact> hello
<confucian-refact> i am new to picolisp
<geri> o7
<geri> (i indoctorated him btw)
<confucian-refact> can picolisp programs fit in l1 cache
user3456 has joined #picolisp
<confucian-refact> obviously it depends how large the cache is i feel dumb asking that
<geri> how much does the size differ for normal consumer hardware?
<confucian-refact> google says on a single core 16-64kb
<confucian-refact> since many consumer hardware has like what 8 cores now
<confucian-refact> that's 512 which is the size of the interpreter
<confucian-refact> (i think)
<confucian-refact> so... i don't know what i would need to figure out to determine this further
<confucian-refact> that would have to be spread out accross multiple cores.
<confucian-refact> and i don't think that's how this works...
<geri> i remember abu said picolisp on hardware wasn't very fast because cpu needs intricate cache setup
<confucian-refact> hmm
<geri> check it out
<confucian-refact> *checking it out*
<geri> )
<confucian-refact> no way there is a picolisp operating system... you are shitting me
<geri> ikr
<geri> on it every program would be compiled down to a lisp
<geri> doesnt it sound sweet?
<confucian-refact> A special bonus is the support of the "Penti" chorded keyboard. You operate it with a single hand, by typing chords and arpeggios on five keys on the numeric keypad ('0', '7', '8', '9', and '+'). A reference table is in https://software-lab.de/penti.html.
<confucian-refact> wild
<geri> theres another one you can operate with a single finger
pablo_escoberg has joined #picolisp
<confucian-refact> pablo_escoberg: haha
<confucian-refact> nice name
<pablo_escoberg> Glad you like it :)
<geri> what's the reference?
<pablo_escoberg> geri do you mean the name?
<geri> ye
<pablo_escoberg> Pablo Escobar was possibly the world biggest drug lord at one time.  I went through some crap with the DEA, where they treated me like I was him.  I'm Jewish, so I Yiddish-ized the name for my handle.
<geri> :D
<geri> self irony is a great thing to have
<pablo_escoberg> indeed.  And I've gotten a ton of mileage out of that handle.  I even registered pabloescoberg.com in case I ever want it for anything.
<geri> haha
<geri> amazing
<pablo_escoberg> thanks :)
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<geri> wb abu[7]
<abu[7]> Hi :)
<geri> there was a question from confucian-refact about running picolisp in l1 cache
<abu[7]> Yes, I see
<abu[7]> Not sure, I think we don't have to worry
<abu[7]> CPU's take care to optimize cache usage
<abu[7]> The interpreter binary is about 1 MiB, but most of it is not executing most of the time
<abu[7]> Ah, no
<abu[7]> just 348K
<geri> enough for the interpreter and a program :)
<abu[7]> T
<abu[7]> but the program allocates more heap usually
<abu[7]> Initially the heap is 1 MiB
<abu[7]> ~/pil21 bin/picolisp
<abu[7]> : (heap)
<abu[7]> -> 1
<geri> pil is 2
<abu[7]> T
<abu[7]> libs
<geri> do you update the release tarball often?
<abu[7]> Rather yes, You see that in @doc/ChangeLog
<abu[7]> Each date is a release
<geri> i gotta update my package; im still on basically the first version i installed after going to 21
<geri> 24.4.5
<abu[7]> Good :)
<abu[7]> You see in ChangeLog ifaa
<abu[7]> nathing is relevant for you
<geri> aighty
<abu[7]> (I cannot write well on my mobile with the cat on my lap ;)
<geri> lapwarmer
<abu[7]> T☺
<geri> do you run your irc client on the same interpreter you edit stuff with or another tmux window?
<abu[7]> It is a separate server
<abu[7]> in fact picolisp.com
<abu[7]> (cause it it always up)
<geri> *confused cat noises*
<geri> you run tmux on picolisp.com and connect via the phone?
<abu[7]> yes
<geri> amazing
<abu[7]> ssh
<geri> almost a bouncer
<geri> wait, so when it says you dis/reconnected, thats problems with the network on the website?
<abu[7]> No network problem. I hit ^C by accident
<abu[7]> Evil cat!
<geri> :D
<abu[7]> It was ^D, not ^C, but anyway ;)
<geri> i use an emacs irc client
<geri> i wonder how comparable they are performance/stability-wise
<abu[7]> Performance is not critical
<abu[7]> for irc
<geri> its just a curiousity
<geri> emacs is byte/natively compiled now...
<abu[7]> ok
<geri> have you ever had performance problems with pil?
<beneroth> I only ever had performance problems with pil when I programmed something stupid :)
<abu[7]> Never a real problem I think
<geri> aighty
<abu[7]> Never had a show stopper :)
<geri> mhmm
<geri> i mean, most of my stuff isnt performance critical
<beneroth> I'd guess pil isn't so cache-friendly because of the fragmented memory model. Then again it is so small that it's again well.
<geri> i just like optimizing
<beneroth> pil is definitely not made for number crunching. but that's not the intention.
<abu[7]> Yep
<geri> oh right - how does pil have a small memory footprint if its pointers upon pointers upon pointers?
<geri> cause apparently pointers are relatively large on their own
<abu[7]> Good question
<beneroth> well they're cpu architecture size. so 64bit
<abu[7]> Probably a lot of reuse and sharing
<beneroth> yeah
<geri> when the author says "Probably" its very inspiring :D
<abu[7]> :D
<beneroth> he is a scientist. he doesn't say anything for sure unless he is absolutely sure ;)
<beneroth> politicians hate this trick
<abu[7]> haha
<geri> thats fair, but if you wrote it you should know about degree of reuse, no?
<geri> that's the joke
<beneroth> well geri if you name all your variables the same then the name gets reused and not many times allocated, if you use every variable different, you need more space.
<geri> hm
<abu[7]> In pil code is generally small
<abu[7]> number of cells
<beneroth> I like the equivalence of source and running program
<abu[7]> "succinctness"
<beneroth> if your source is smaller, then the programs binary representation in memory will also be smaller.
<beneroth> better code, better runtime behavior
<geri> eh, that depends
<abu[7]> So we are back to cache
<geri> if you use libraries its not guaranteed - theres way more code in the background
<beneroth> generally untrue in picolisps cache xD
<beneroth> s/cache/case
<geri> cries in not many libs
<geri> still has a json parser, which is amazing
<geri> to have
<beneroth> even multiple ones xD
<beneroth> damn lisp curse
<abu[7]> T
<geri> oh yeah?
<geri> im gonna roll my own
<geri> uwu
<beneroth> same here. I should publish it.
<abu[7]> aw- made a more general one
<beneroth> mine is more general than the one from aw- I believe.
<abu[7]> oh, good
<beneroth> but abu[7]s or aw- is kinda more optimized if you just need the functionality they provide, I think
<beneroth> currently working on a JSON inspector/explorer, interactive repl too which lets you explore a big JSON file to understand its structure
<geri> generally speaking, parsing json means you gotta have at least enough RAM to hold the whole source in, right?
<geri> maybe whole representation too but thats questionable
<beneroth> not the whole source. you can read it in stream
<beneroth> your representation can be smaller then the text version
<abu[7]> Same with xm.l
<beneroth> e.g. when handling numbers as picolisp 'num instead of strings
<geri> thats an amazing name abu[7]
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<abu[7]> l
<beneroth> cat?
<abu[7]> oops
<geri> cat attack!
<abu[7]> No, touching repeat keg
<abu[7]> key
<beneroth> In Bavaria, kegs are important :P
<abu[7]> But yes, I still cannot rest my phone
<abu[7]> ot th lap
<beneroth> can you not rest it on the cat?
<abu[7]> It is sleeping
<abu[7]> Not allowed to disturb
<abu[7]> Cat is always the boss
<beneroth> use -quiet
<abu[7]> Good :)
<beneroth> :)
<geri> :D
<geri> aight i gotta undistract myself from japanese learning
<geri> laters
<abu[7]> cu o/
geri has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<abu[7]> brb
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
confucian-refact has quit [Ping timeout: 264 seconds]