ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
xkapastel has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #picolisp
orivej_ has quit [Ping timeout: 240 seconds]
patrixl has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
patrixl has joined #picolisp
aw- has quit [Quit: Leaving.]
_whitelogger has joined #picolisp
Nistur has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
Nistur has joined #picolisp
_whitelogger has joined #picolisp
aw- has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
_whitelogger has joined #picolisp
<aw-> Regenaxer: here?
<aw-> well, when you wake up, I made a small patch to pil21 in lib/net.l
<aw-> something i've often needed when working with sockets: the source port of the client connection
<aw-> it's not pretty, maybe you can tweak it.. but I think it would be very useful to have something like *SPort (or other var name?)
<Regenaxer> Hi aw-!
<aw-> i also literally just copied your code from (port)
<aw-> haha
<Regenaxer> Up since many hours, fixed the ^C issue :)
<aw-> oh great! good morning
<Regenaxer> Already walked the fields
<Regenaxer> I see, you introduce *SPort
<aw-> right
<Regenaxer> Is it the port on the remote side?
<aw-> often needed to identify a specific connection
<aw-> yes
<Regenaxer> Ok, good
<Regenaxer> I'll patch
<aw-> in C you can also do: port = ntohs(s->sin6_port);
<aw-> seems simpler, but i couldn't get it to work
<Regenaxer> I think I avoided ntohs and htons
<Regenaxer> just accesses two bytes
<aw-> yes i saw you're doing direct bitops
<Regenaxer> yeah
<aw-> so i copied it ;)
<Regenaxer> no need for native call overhead
<aw-> right
<aw-> perfect
<Regenaxer> should be fine
<Regenaxer> I think on some systems ntohs and htons are just macros
<aw-> this is CPU arch independent, right? because network byte order
<Regenaxer> yeah
<Regenaxer> always big endian
<aw-> ok good
<Regenaxer> I released it. Can you check?
<aw-> hmmm
<aw-> yyou forgot in (export)
<Regenaxer> oh! Sorry
<aw-> np
<Regenaxer> I was too lazy to set up for calling 'patch' :)
<Regenaxer> done
orivej has joined #picolisp
<aw-> Regenaxer:
<aw-> if i type make clean; before 'make' should it empty/delete the .ll files too?
<aw-> also, when i press ctrl+c, it doesn't seem to exit
<aw-> only the child process exits, parent still running
<aw-> ctrl+c twice is "normal" ?
<Regenaxer> Not sure about clean
<Regenaxer> If the parent gets SIGTERM, it should send SIGTERM to all children, wait until they terminated, then terminate too
<Regenaxer> SIGINT just does a console break
<Regenaxer> does not terminate
<aw-> i see
<aw-> hmmm
<aw-> i did find one issue in my code, from using pil21
<aw-> wait i'll try to reproduce and then explain
<Regenaxer> ok
<aw-> 3 issues :(
<Regenaxer> Hmm, SIGTERM does not work
<aw-> 1) it seems pil history doesn't get reloaded
<Regenaxer> yes
<Regenaxer> history is not loaded and saved anymore
<Regenaxer> you must do it
<Regenaxer> I have my history in ~/.pil/rc
<Regenaxer> (history
<Regenaxer> (quote
<Regenaxer> "..."
<Regenaxer> and you can save it in a *Bye expression
<aw-> oh.. well that's not fun :(
<aw-> i find pil history quite useful
<Regenaxer> yes, so do it
<Regenaxer> it is trivial
<Regenaxer> (history ...)
<Regenaxer> I don't want it hard-coded
<aw-> ok
<aw-> next problem
<aw-> 2) (abort) behaves differently
<aw-> previously: : (abort 5 (in "LICENSE" (line T)))
<aw-> -> "The MIT License (MIT)"
<aw-> pil21: : (abort 5 (in "LICENSE" (line T)))
<aw-> -> 5
<Regenaxer> OK, thanks
<Regenaxer> let me check
<Regenaxer> first the SIGTERM issue
<aw-> yes yes, no rush ;)
<Regenaxer> why are the children not terminated
<aw-> yes, that was problem 3)
<Regenaxer> ok
<Regenaxer> but not related to ^C ?
<aw-> actually
<aw-> the children are terminated, but not the parent
<Regenaxer> But you used ^C, right?
<aw-> no
<aw-> 'kill'
<aw-> just kill (default -TERM)
<aw-> kill -TERM <parent> ; child dies, parent still running
<Regenaxer> I see
<Regenaxer> I had the impression that the parent died
<Regenaxer> I did (kill *Pid 15)
<Regenaxer> and the child remained
<Regenaxer> I try again
<Regenaxer> You are right, the child terminates, not the parent
<aw-> haha
<Regenaxer> Should be simple
<aw-> funny bug
<aw-> indeed it seems like maybe you swapped some variables somewhere
<Regenaxer> yeah
<aw-> in signal handler
<Regenaxer> or checking the wrong signal
<Regenaxer> It is in a loop in the signal handler
<Regenaxer> It maps all children and sends SIGTERM
<Regenaxer> until all are gone
<Regenaxer> so this does not work
<aw-> it does? all children are killed when parent receives the SIGTERM
<aw-> only parent remains
<Regenaxer> Yes, "until all are gone" does not work
<Regenaxer> not detected
<aw-> right
<Regenaxer> Seems just wrong decrement of the signal counts
<Regenaxer> yes, workds
<Regenaxer> works now
<Regenaxer> released
<Regenaxer> I check 'abort'
<Regenaxer> oh
<Regenaxer> after killing myself, the tty is in raw mode
<Regenaxer> Dont know how to avoid that here
<Regenaxer> It is in readline(), out of my control
<Regenaxer> ok, have an idea
<Regenaxer> doesn't work
<Regenaxer> I tried 'rlSigEnd' from src/lib.c
<Regenaxer> which calls rl_reset_after_signal()
<Regenaxer> ok, needs (rlSigBeg)
<Regenaxer> yep, good now
<Regenaxer> released
<aw-> hmmm.. i can't seem to compile it now
<Regenaxer> oh
<Regenaxer> what happens?
<Regenaxer> The 'abort' but seems to be in 'finally'
<aw-> Putting child 0x55c19a7780 (base.ll) PID 22480 on the chain.
<aw-> Live child 0x55c19a7780 (base.ll) PID 22480
<aw-> ../pil: 2: exec: ../bin/picolisp: not found
<aw-> make: *** [Makefile:34: base.ll] Error 127
<aw-> Reaping losing child 0x55c19a7780 PID 22480
<aw-> Removing child 0x55c19a7780 PID 22480 from chain.
<Regenaxer> uh
<aw-> base.ll was turned to 0 bytes
<Regenaxer> 'abort' now works
<Regenaxer> it was 'finally'
<Regenaxer> released
<aw-> oh ok
<aw-> :\ can't compile it anymore
<Regenaxer> stupid error, returned the value of finally clause instead of that of the body
<Regenaxer> With the above errors?
<aw-> yes
<aw-> cd src; make -d;
<aw-> fails to make
<Regenaxer> what does -d do?
<aw-> debug
<Regenaxer> Never seen such error messages
<aw-> ok, not relevant then
<Regenaxer> Does it work after clean?
<aw-> no
<aw-> bbiab
<Regenaxer> ?
<Regenaxer> Here an example to save your history:
<Regenaxer> Put this into ~/.pil/rc
<Regenaxer> (history (in "file" (make (while (line) (link @))) ) )(push1 '*Bye '(out "file" (mapc prinl (history))))
<Regenaxer> oops
<Regenaxer> again:
<Regenaxer> (history
<Regenaxer> (in "file"
<Regenaxer> (make (while (line) (link @))) ) )
<Regenaxer> (push1 '*Bye '(out "file" (mapc prinl (history))))
<aw-> ok thanks
<Regenaxer> Could you compile again?
<aw-> can't compile :(
<aw-> it can't bootstrap itself anymore
<aw-> was working earlier today, and yesterday, etc...
<Regenaxer> strange
<Regenaxer> What is different?
<Regenaxer> one of my changes?
<aw-> yes definitely
<aw-> i'm checking the diffs now, one sec
<aw-> not sure.. the diff is really big :(
<Regenaxer> big? It were only a few changes
<aw-> base.ll
<Regenaxer> ah
<Regenaxer> yes, that's always big, as the ssa numbers shift
<aw-> i'm comparing with something pushed to the git repo on this date:
<aw-> Date: Sat Aug 8 11:12:02 2020 +0300
<aw-> 2020-08-08
<aw-> you added this line:
<aw-> ++ 'info' returns the file argument in '@@'
<aw-> in doc/diff
<Regenaxer> yes, this morning 09:38:08 CEST
<aw-> and you added my patch from earlier
<aw-> but now the most recent code (not in git) doesn't bootstrap itself
<aw-> anymore
<Regenaxer> src/flow.l for finally
<Regenaxer> src/main.l for signal stuff
<Regenaxer> hmm
<Regenaxer> Is there no pil error before?
<Regenaxer> when make base.ll
<aw-> no
<aw-> when i compiled previously, it used the base.ll that you supply
<Regenaxer> The error is mysterious
<Regenaxer> exec: ../bin/picolisp: not found
<Regenaxer> so it *tries* to build base.ll
<Regenaxer> Perhaps I released a partially changed src/db.l ?
<Regenaxer> I released once more
<Regenaxer> Could you try again?
<Regenaxer> This version definitely builds here (Termux)
<aw-> oh
<aw-> now it works!
<Regenaxer> New version?
<aw-> yes
<aw-> new .tgz compiles
<Regenaxer> So it was my fault, I released some fragment
<Regenaxer> Perfect
<Regenaxer> There must have been a pil error
<Regenaxer> unbalanced paren or so
<Regenaxer> nevermind
<aw-> ok so
<aw-> testing the 'kill' thing now
<Regenaxer> T
<aw-> kill the parent now works on first -TERM
<aw-> but it seems the child are killed uncleanly
<aw-> my child process has a (finally) and it's not being called
<Regenaxer> ah, that's still missing
<Regenaxer> coroutines and unwinding
<Regenaxer> all those details in unwinding the stack
<aw-> oh ok
<aw-> but it was working previously with the two ctrl+c
<Regenaxer> From the other bug in finally we see that I never even tested ;)
<aw-> first ctrl+c killed them child process cleanly
<aw-> oh ok
<aw-> ok no problem
<aw-> take your time
<Regenaxer> not sure atm what exactly is missing in that area
<Regenaxer> I will look at it soon
<Regenaxer> Just finish db first
<aw-> ok thanks
<Regenaxer> :)
<aw-> i have so many things i want to implement with (native) now
<Regenaxer> Great!
<aw-> so much easier with pil21
<Regenaxer> yeah, it is more usable
<Regenaxer> especially with the system constants
<aw-> in sysdefs?
<Regenaxer> yes
<aw-> yeah i saw that
<Regenaxer> Can be customized with more app-specific files
<aw-> how can i customize it?
<Regenaxer> Generate one for the application domain
<aw-> ohhh ok
<aw-> then just call (sysdefs ..) ?
<Regenaxer> yes, but the file must be prepared for the target system
<Regenaxer> can be done manually
<Regenaxer> or with a C program like in make
<aw-> yes i saw what you did with sysdefs.c and Makefile
<Regenaxer> yeah
<Regenaxer> and then call (sysdefs "Section" "myFile")
<aw-> does (sysdefs) always read from @lib/sysdefs?
<Regenaxer> yes, but an optional second arg
<Regenaxer> the sections are named as [Section]
<aw-> hmmm
<Regenaxer> Only that part till the next section is parsed
<Regenaxer> very fast
<aw-> so if i want specific constants, i need to place them in @lib/sysdefs, no other file?
<Regenaxer> no, in "myFile"
<aw-> ohhh ok i see now
<Regenaxer> @lib/sysdefs is just the default
<aw-> second argument
<aw-> i see it now
<Regenaxer> you can extend it of course too
<aw-> i have one question
<aw-> maybe stupid
<aw-> with pil21, does it mean (native) will work on 32-bit as well?
<aw-> or is pil21 64-bit only?
<Regenaxer> Yes, I did not manage to build it for 32 bits
<Regenaxer> pointer size needs to be 64 bits
<aw-> ok
<Regenaxer> It would have really been nice
<Regenaxer> I tried initially
<aw-> what was the problem?
<Regenaxer> I dont remember exactly. Found no syntax to specify unions of 64 bit numbers and pointers
<Regenaxer> pil21 operates on 64 bits
<Regenaxer> but pointers on a 32 bit arch are 32 bitj
<Regenaxer> bits
<Regenaxer> btw, a sysdefs file must have a comment in the first line
<Regenaxer> then one entry per line
<Regenaxer> separated by TAB
<Regenaxer> first line not necessarily a comment, but searching starts at the second line
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<Regenaxer> I meant, it starts after the first newline
orivej has quit [Ping timeout: 260 seconds]
<aw-> ok got it
<aw-> brb
aw- has quit [Quit: Leaving.]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
joncfoo has joined #picolisp
joncfoo has quit [Client Quit]
joncfoo has joined #picolisp
joncfoo has quit [Quit: Leaving]
joncfoo has joined #picolisp
<joncfoo> Is https://github.com/picolisp/picolisp the official repository?
<tankf33der> yea
<joncfoo> It seems not since the one PR submitted was told to publish to the mailing list.
<joncfoo> Is there an issue tracker or is all development done on the mailing list?
<tankf33der> no known issues for picolisp. everything is working.
<joncfoo> hah ok :)
<joncfoo> I noted that all scripts have /usr/bin/picolisp hardcoded. In a local installation all scripts need to be modified.
<joncfoo> I was going to suggest in an issue that /usr/bin/env be leveraged so it PATH would be taken into account
<tankf33der> in general this is ok
<tankf33der> feel free to avoid it
<Regenaxer> Hi joncfoo, in fact the official recommendations are "local" installs
<Regenaxer> See the INSTALL file
<Regenaxer> The inst in /usr/bin/ etc are a kind of bootstrap
<Regenaxer> I always wondered what advantage /usr/bin/env would have
<Regenaxer> It would not help eg on Termux, where the path is picolisp is /data/data/com.termux/files/usr/bin/picolisp
<Regenaxer> or picolisp is /data/data/com.termux/files/usr/bin/env
<Regenaxer> BTW, concerning "all development done", I would rather say it is *here* :)
<Regenaxer> At least as far as it is pil21
<tankf33der> if i would like use env then i should add picolisp binary to PATH and just execute “env picolisp”.
<tankf33der> but i need pil so:
<tankf33der> i just added /home/mpech/picolisp to PATH and just execute pil
<tankf33der> the same for pil21.
<joncfoo> ok so maybe I'm missing something ... I did the following:
<joncfoo> 2. ran `make src64 && make -C src tools gate`
<joncfoo> 3. try to run `./bin/pil` but it fails due to hardcoded:
<joncfoo> 1. Download and unpack picoLisp-20.6.tgz in $HOME
<joncfoo> `#!/usr/bin/picolisp /usr/lib/picolisp/lib.l`
* joncfoo smacks head on desk
<joncfoo> I missed the `pil` file in the root directory (there's another one in `bin`)
<Regenaxer> Ah, no, it is ./pil :)
<Regenaxer> bin/pil is meant for global installs, to be copied to /usr/bin
<Regenaxer> The best is to start it as:
<Regenaxer> $ ./pil +
<Regenaxer> or, from another directory:
<Regenaxer> ../picoLisp/pil +
<Regenaxer> or whatever
<Regenaxer> so a relative path works always
<joncfoo> gotcha, thanks!
<Regenaxer> The runtime looks for all 'load'ed files in that directory tree then
<Regenaxer> So 'pil' kind of does its own 'env' ;)
<joncfoo> I did a thing: https://hatebin.com/jgldztrshz
<joncfoo> I wanted a executable script file so ^ is my attempt at it
<joncfoo> I think modifying `pil` to what's in there would be good (it reads through symlinks)
<joncfoo> took me long enough to get to "Hello World" in a script file :)
<tankf33der> joncfoo: good, keep coding.
<Regenaxer> Hmm, now what is doing /usr/bin/env what we don't have before?
<joncfoo> the picolisp dir is not in my path, just the `pil` file is
<Regenaxer> And why not simply set symbolic links as described in INSTALL?
<Regenaxer> yes
<tankf33der> Regenaxer: nothing. in general this is not issue.
<Regenaxer> So if you call it via /usr/bin/env, does it have the necessary runtime info for "@" path names?
<Regenaxer> i.e. can you do (load "@lib/http.l") etc.?
<Regenaxer> is the @ properly expanded?
<joncfoo> yes I just tested adding that line to the hello.l file - it works
<Regenaxer> ok, good
<Regenaxer> I still don't get it. How does 'env' find 'pil'? Where is the modified 'pil' lying?
<Regenaxer> Ah, ok
<Regenaxer> in your pbth
<Regenaxer> But then the suggested link in your path is easier, no?
<Regenaxer> no need to modify anything I mean
<joncfoo> yep, if I add the picolisp dir to PATH it would all be ok w/o modification
<joncfoo> I think maybe I just went down a complicated path for no reason... :(
<Regenaxer> Not sure, if it works it is fine :)
<Regenaxer> I never tried that way, as I always use pil relatively in production
<Regenaxer> usually with several local installations on the same machine
<Regenaxer> so just the path ../foo/bar/pil lets me select which one to use
<joncfoo> I can see that working to support multiple versions
<Regenaxer> yeah
<Regenaxer> The global one I usually just leave where it is
<Regenaxer> for bootstrapping only
<Regenaxer> or a quick test or so
<Regenaxer> I work mostly in Termux, so 'pil' runs the one in
<Regenaxer> $ type pil
<Regenaxer> pil is /data/data/com.termux/files/usr/bin/pil
<Regenaxer> (took a moment to find ;)
<joncfoo> you run it on an Android device most of the time?
<Regenaxer> yes
<joncfoo> oh interesting - for work?
<Regenaxer> using Termux with multiple sessions of tmux inside
<joncfoo> oh I see
<Regenaxer> Though meanwhile I even don't use a tablet any mmore
<Regenaxer> but a plain phone with 6.7 inch
<Regenaxer> I'm writing this here now also in that environment
<Regenaxer> ssh to a server running this irc client permanently
<Regenaxer> (hehe, and the irc client is also written in picilisp of course ;)
<joncfoo> that's one heck of a workflow but hey, whatever works :)
<Regenaxer> true :)
<Regenaxer> I want to be as flexible as possible
<Regenaxer> I walk the fields and woods here for hours each day, and want to continue working at any moment
<Regenaxer> So a smartphone must be enough
joncfoo_ has joined #picolisp
<joncfoo_> Is the PicoLisp Works ebook the recommended way to learn PicoLisp?
<beneroth> I would say the recommend way is to do some actual project with it :-9
<Regenaxer> I think it is outdated meanwhile
<Regenaxer> beneroth, true
<Regenaxer> For learning, you are always welcome to ask here
<joncfoo_> oh ok - what would you recommend nowadays? FWIW I have a little bit of prior exposure of Clojure
<Regenaxer> A very good source of examples is RosettaCode
<Regenaxer> I see
<Regenaxer> Clojure is quite different
<joncfoo_> I'm familiar with FP concepts in general - parens don't scare me :P
<Regenaxer> Very good :)
<joncfoo_> I realize PicoLisp isn't a FP thing in general so that's fine too
<Regenaxer> Well, it is functional but also procedural and oop, like most Lisps
<Regenaxer> but it differs a lot from Clojure, Common Lisp or Scheme
<Regenaxer> The paren syntax is the same
<Regenaxer> except for Clojure's [ and ]
<Regenaxer> PicoLisp has no vectors
<joncfoo_> I think that's what drew me to PicoLisp - the insane marrying of DB, Application Code, and UI :D
<Regenaxer> only lists
<Regenaxer> yeah
<joncfoo_> I'm looking forward to dabbling and learning
<Regenaxer> Just try
<joncfoo_> maybe I'll stick with the book for now and yea like you said "Just try"
<Regenaxer> yes, the book is not wrong at all
<Regenaxer> just not sure if all still applies
<joncfoo_> I'll find out soon enough :)
<Regenaxer> IIRC it was more for pil32, now you have pil64
<Regenaxer> In any case, PicoLisp is extremely simple, even if there are many things around the simple base system meanwhile
<Regenaxer> the key concepts are not changes
<Regenaxer> i.e. only 3 data types
<joncfoo_> Numbers, Symbols, and Lists ;)
<joncfoo_> I got that far in the book
<Regenaxer> yep :)
<joncfoo_> ah you have advent of code - I don't wanna look :P
<joncfoo_> I'm going to take a slow stab at implementing the game Boggle
<joncfoo_> it'll get me building a Trie and some traversals
<joncfoo_> plus a UI piece to display the game board
xkapastel has joined #picolisp
joncfoo_ has quit [Ping timeout: 240 seconds]