04:41 <abu[m]> Welcome xigoi! And thanks benerothfor the perfect explanations! ☺

05:06 <abu[m]> xigoi: You could also take a look at https://picolisp-blog.hashnode.dev and https://twitter.com/PicoLispREPL

09:49 <xigoi> I'm a first-year university student (Mathematical Informatics)

09:49 <abu[m]> Great!

09:59 <beneroth> cool :D

14:53 <anddam> possibly Stupid Question of The Month: is there an editor written in picolisp, like Emacs is in elisp?

14:55 <abu[m]> anddam: Good question. I do not know of any

14:56 <abu[m]> Pil21 had some glue functions to interface to real Emacs, perhaps these should be put into a separate lib?

14:57 <abu[m]> I think I misunderstood your question

14:57 <abu[m]> I read: Is there *another* editor ...

14:57 <abu[m]> *One* editor is there. It is Vip (VI in pil)

14:59 <abu[m]> Vip is in the standard PicoLisp distribution. Just call (vi 'car) or (vi "file.l".

14:59 <abu[m]> Or (vi 'vi) if course ;)

15:01 <anddam> is pil best installed from source rather than a system package?

15:02 <anddam> I ask since I am on Void and I see no picolisp package

15:02 <abu[m]> yes. You could use Debian testing too, which is quite up-to-date

15:02 <abu[m]> But installing from the TGZ is the best

15:03 <anddam> is it updated often?

15:04 <abu[m]> Yes, it is a rolling release. Sometimes several times per week

15:05 <abu[m]> https://software-lab.de/doc/ChangeLog

15:06 <anddam> man, that's a lot of effort

15:07 <anddam> does it have an ultimate "goal" in terms of features to be implemented in the language?

15:07 <abu[m]> Not so much, all tiny steps

15:07 <anddam> i.e. do you see a point where you say "that's it"

15:07 <anddam> "it's complete"

15:08 <abu[m]> I thought that so often :) But as I'm using it for all my work, new requirements kept popping up

15:10 <abu[m]> or bugs :(

15:10 <abu[m]> Other things were necessary to make it work well on PilBox/Android

15:17 <anddam> I see

15:29 <anddam> I have a tarball named "foo", that extracts as bar/ and then has a makefile (no configure required) in bar/src

15:30 <anddam> so I set build_style=gnu-makefile and wrksrc=bar/ but how do I exec into src?

15:30 <anddam> do I cd in pre-configure or pass a flag to make?

15:31 <anddam> x/-configure/c/_build/

15:31 <abu[m]> Is this about the Pil build?

15:33 <abu[m]> I mean, doesn't this simply work? https://software-lab.de/INSTALL

15:34 <anddam> ohoh yes

15:34 <anddam> I thought I was in #void, I dropped a simple port for 22.6

15:38 <abu[m]> Sorry, what is #void ? An IRC channel

15:38 <abu[m]> ?

15:44 <anddam> yes it is

15:44 <anddam> is openssl fine for building 22.6? I followed Debian desc that has libssl-dev but in turn relies on openssl-dev

15:45 <abu[m]> All right :)

15:45 <anddam> https://termbin.com/233w

15:45 <anddam> namely it is #voidlinux, the official channel for Void Linux distribution

15:45 <abu[m]> OK

15:46 <abu[m]> On Termux I do also just have "openssl"

15:47 <anddam> ohh sorry the termbin didn't go through, I bet there's a 013 in that output

15:48 <anddam> https://termbin.com/yzox

15:49 <abu[m]> Uh, this looks a bit like an outdated LLVM. Is it 7 or above?

15:50 <anddam> llvm is at 12 but it seems it's not installed in the chroot

15:51 <abu[m]> llvm-link is there though

15:51 <anddam> not it is installed, and is 12

15:51 <anddam> x/not /c/no /

15:52 <abu[m]> ok, hmm

15:52 <abu[m]> The error is quite cryptic

15:53 <abu[m]> The error is in lib.bc, not base.bc (which is built first iirc)

15:53 <abu[m]> lib.bc has system-dependent stuff, it is built from lib.c

15:59 <anddam> makefile has no verbose option

15:59 <anddam> should I try an older llvm?

15:59 <abu[m]> No, 12 is fine. tankf33der even tested with 14 I think

16:00 <abu[m]> What does "file src/lib.bc" say?

16:02 <abu[m]> should be "LLVM IR bitcode"

16:02 <anddam> https://termbin.com/gidj

16:02 <anddam> not yet

16:03 <anddam> I am checking before the make now

16:03 <abu[m]> yeah, it compiled to ELF

16:04 <anddam> as the error log said

16:04 <abu[m]> indeed

16:04 <anddam> $(CC) -O3 -w -c -o lib.bc -D_OS='"$(OS)"' -D_CPU='"$(CPU)"' `pkg-config --cflags libffi` -emit-llvm lib.c

16:04 <abu[m]> Perhaps "make clean" and then fetch "base.ll" from the tarball

16:06 <abu[m]> So CC should be clang

16:06 <abu[m]> and emit LLVM

16:11 <abu[m]> Is there any pre-build package for PicoLisp (no matter which version) in Void Linux?

16:11 <anddam> no, that's why I tossed out a template

16:11 <abu[m]> ok

16:12 <abu[m]> Cause otherwise you could bootstrap. But as base.ll built successfully, it would probably not make a difference

16:18 <beneroth> void linux - void of picolisp

16:18 <beneroth> let's hope you can change that, anddam :)

16:18 <abu[m]> Indeed! ☺

16:27 <anddam> yea, it's building now

16:28 <abu[m]> Cool!

16:28 <abu[m]> Why is it all in a chroot?

16:29 <abu[m]> (I always build as normal user -> local install)

16:47 <anddam> abu[m]: due to the way the packaging tool works on Void

16:47 <anddam> xbps-src

16:48 <anddam> I need to sort the install phase

16:48 <anddam> INSTALL > "Global Installation"

16:48 <abu[m]> ok

16:49 <anddam> why no installation target in Makefile?

16:50 <abu[m]> Because the local installation is the recommended way

16:51 <abu[m]> PicoLisp is so tiny and changes so often, so that several local installations are useful

16:51 <abu[m]> Then just the global links are enough

16:51 <abu[m]> I personally never use the global calls

16:51 <abu[m]> Always ../somePath/pil21 app.l ...

16:52 <abu[m]> But you are right, a global install is kind of expected

16:54 <anddam> "In a global installation, the 'pil' command should be used." I see there are two "pil commands" (and two vip ones)

16:55 <anddam> a shell script that calls picolisp with lib.l and ext.l and the script arguments

16:55 <abu[m]> yes, they are provided, so that they can be copied into /usr/...

16:55 <anddam> and a picolisp program loading slightly different libs and then pilog

16:55 <anddam> I see installation instructions refers to the picolisp one

16:55 <abu[m]> They both load the same libs

16:56 <abu[m]> I use ~/pil21/pil

16:56 <anddam> shell script has exec ${0%/*}/bin/picolisp ${0%/*}/lib.l @ext.l "$@"

16:56 <anddam> pil program has (load "@lib/net.l" "@lib/misc.l" "@lib/btree.l" "@lib/db.l" "@lib/pilog.l")

16:56 <anddam> doesn't the latter lack the argument and load different libs?

16:57 <abu[m]> They are in ext.l

16:58 <anddam> ok

16:58 <abu[m]> The one in bin/pil uses absolute paths, and is thus less general

16:59 <abu[m]> The /bin/sh one examines the path of "lib.l"

16:59 <abu[m]> (in fact bin/picolisp always inspects the path of lib.l)

17:00 <abu[m]> In summary, the difference is that bin/pil can be called just as 'pil' while the other one expects an absolute or relative path

17:02 <abu[m]> I never even thought about an install target. My bad, it simply never was an issue

17:02 <abu[m]> The Debian packaging took care of that (thanks Kanru!)

17:04 <anddam> I figure I need all the stuff in bin/, right?

17:04 <anddam> ah bin/watchdog is going to be an issue

17:04 <anddam> I'll do what Debian does

17:05 <abu[m]> Good. I think bin/watchdog is not really needed

17:05 <abu[m]> It is just a nice to have tool

17:07 <abu[m]> And also comes with a relative path ;) I think nobody except our company ever used it, at least I never heard any questions

17:07 <anddam> why are img/* in /usr/lib rather than /usr/share?

17:07 <abu[m]> They are loaded relative to the "installation" path, determined by lib.l

17:08 <abu[m]> in pil syntax it is "@img/xxx.png"

17:08 <abu[m]> Same goes for @doc/

17:09 <abu[m]> which is linked I think to /usr/share/doc/

17:09 <abu[m]> Yes, on Debian the "installation" dir is /usr/lib/picolisp/

17:10 <anddam> Debian seems to not install /usr/share/doc at all

17:10 <anddam> no wait, doc-base

17:10 <abu[m]> lrwxrwxrwx 1 root root 28 Jan 3 2021 doc -> ../../share/doc/picolisp/doc/

17:14 <anddam> yea, I am unfamiliar with deb packaging

17:18 <beneroth> abu[m], I've used @bin/ssl, but not yet @bin/watchdog. I believe watchdog is very specific to the form.l web application setup. but when running a bigger form.l environment then I would think watchdog is strongly recommended to be used.

17:19 <abu[m]> It has nothing to do with GUI and form.l. It just sends a mail if registered applications don't ping, and kills them after a while

17:34 <anddam> abu[m]: do you need both /usr/lib/picolisp and /usr/share/picolisp?

17:34 <anddam> I mean debian seems to symlink those, I wonder if that's required due to some hardcoded path when searching this or that other object inside pil

17:34 <abu[m]> Just /usr/lib/picolisp is enough

17:35 <abu[m]> I thought it is just for standardization, i.e. where people look for docs etc.

17:36 <abu[m]> At runtime whole pil can be encapsulated into the single installation directory

17:37 <abu[m]> This makes it so easy to run it in e.g. PilBox

17:48 <beneroth> abu[m], ah, so really just a watchdog. thanks.

17:48 <beneroth> thanks for the clarification.

17:51 <beneroth> anddam, I think there are no hardcoded paths, the paths are all relative to the picolisp directory. If you install bin/pil globally it takes the execution path to run in its own directory (otherwise, when starting it as ./pil you're obviously in the current dir as run dir, and picolisp files will be assumed relative from there unless specified as absolute path)

17:51 <abu[m]> T