<anddam>
how do I (stress)test the newly packaged picolisp?
<anddam>
the REPL works
<aw->
anddam: hi, what do you mean by stress test?
<aw->
in general you shouldn't need to stress test it, if it builds and the REPL works, then it's fine :)
seninha has quit [Remote host closed the connection]
lispnik has joined #picolisp
<abu[m]>
anddam: Tte normal unit tests are $ ./pil lib/test.l -bye +
<abu[m]>
And a DB stress test is $ ./pil misc/stress.l -main -go -bye; rm db/test jnl db/test2
lispnik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
m_mans has joined #picolisp
<abu[m]>
Hmm, concerning opaque pointers: I more and more suspect that I cannot escape from the conversion
<abu[m]>
The LLVM docs talk about a "transition" phase. So probably after LLVM 16 it *must* use opaques in IR
<abu[m]>
So for one thing I must rewrite, but the other problem is that of distributing, because then the *.ll files cannot be compiled any more on systems < LLVM 15
<abu[m]>
We must restrict to >= 15 or 16 then
<abu[m]>
A mess!
seninha has joined #picolisp
<beneroth>
abu[m] :(
<m_mans>
We can't escape from progress...
<abu[m]>
That's true
<tankf33der>
abu[m]: i hope they will have CLI argument for this as we use now
<abu[m]>
As I understand it, typed pointers in IR will be supported only in this "transient" phase
<abu[m]>
Looks like it will no longer work then
<tankf33der>
i will catch it as earlier as possible
<abu[m]>
good
<abu[m]>
And I will start to rewrite (after the next Debian release end of this month)
<beneroth>
picolisp is quite useful as a scripting language
<anddam>
beneroth: for the same purpose that the corresponding programs are, I guess
<beneroth>
I prefer it over bash
<beneroth>
abu[m] is such a youngster, not even using a PC, just on the phone all the time...
<beneroth>
;-)
<anddam>
my question is if the `vip` and `pil` shell script that are left after building the source are of any use once I install the package, when the alternative is using the actual pil scripts
<beneroth>
open them and look at them
<anddam>
I did
<abu[m]>
I see! They are to be installed in a global installation
<abu[m]>
e.g. bin/pil to /usr/bin/pil
<beneroth>
pil is the actual script usually used to start picolisp, as it loads standard libraries. there is hardly a case for using the picolisp binary directly (unless you make your own variant of the pil script for some reason)
<abu[m]>
yes, the one in pil21/pil
<beneroth>
vip is abu[m] implementation of vim, in picolisp, optimized for picolisp source code editing
<abu[m]>
and pil21/bin/pil can be copied to /usr/bin/
<anddam>
beneroth: ok, thanks I was clear on what were those
<beneroth>
ah okay, sorry then, I'm confused ^^'
<anddam>
beneroth: I was left with two couples, (`vip` `bin/vip`) and (`pil` `bin/pil`)
<anddam>
now I can use a text editor (vis is my favorite) so I can see what the shell script and the picolisp script do, my question was what were the shell script intended for
<anddam>
abu[m]: I followed the AUR script and installed pil21/bin/pil in /usr/bin/
<abu[m]>
ok
<anddam>
to be more clear I just wrote the template for the void packaging system, since that's what I prefer
<anddam>
prefer*
<abu[m]>
I always have a local bin/ directory in my search path
<anddam>
local as in system local (/usr/local), user local (~/.local/bin) or local to the pil21 source dir?
<abu[m]>
in /home/abu/bin/vip
<abu[m]>
It has #!/home/app/pil21/bin/picolisp /home/app/pil21/lib.l
<abu[m]>
and then just one line (load "@bin/vip")
<abu[m]>
and a symbolic link vi -> vip
<anddam>
I see
<abu[m]>
So I just do $ vi ... everywhere
<anddam>
I am a noob lisper, can I try and use picolisp along the way while learning or should I stick to a more "mainstream" implementation?
<anddam>
also does vip offer any advantage over <other editor I know already well>?
<abu[m]>
It depends where you want to go. PicoLisp is quite different, so not useful to learn Lisp in general
<abu[m]>
Vip is useful for Pil, because it runs *inside* Pil and knows everything
<abu[m]>
and interacts with everything
<anddam>
oh, that is neat, no slime required
<abu[m]>
exactly
<abu[m]>
Vip knows all 'load'ed and built-in symbols, including their namespaces
<abu[m]>
And it can either directly evaluate Pil code, or interact with the current application because Vip runs as a coroutine *in* the application
<abu[m]>
"evaluate pil code" means in the source text with Ctrl-E on an expression, or in the Vip REPL in the bottom command window
<abu[m]>
anddam: I suppose yoc checked the Vip article in picolisp.com, it explains some details
<beneroth>
anddam, PicoLisp is not closely related to any other contemporary lisp. So learning picolisp makes you a lisper, but will not make it easy to work with other lisps/schemes. Of course the general lisp basics are all the same, but PicoLisp is quite particular in some ways (arguably closer to older lisps than newer ones)
<beneroth>
picolisp is a language optimized for interpreter, while other lisps over years/decades get optimized for compilers (and somewhat got a bit distant to some of the original lisp core concepts picolispers might argue)
<beneroth>
picolisp cannot be compiled (no compiler exists, and even theoretically only a subset of picolisp could be compiled)
<beneroth>
some core lisp stuff is both simplified and more expanded/powerful in picolisp than other lisps
<beneroth>
the basics lisp knowhow probably transfers to other lisp languages, but the "muscle memory" of picolisp is a bad fit for most other lisp languages, and vic versa
<beneroth>
primarily coming from the big difference of optimizing for compilation or ditching compilation altogether
<beneroth>
picolisp only has some very few macros. you could build and use macros in picolisp, but it's not really the picolisper way, we have F-Expressions (Fexpr) instead.
<beneroth>
it's functions which decide themselves when/if to evaluate their arguments. a fexpr is like an interpreter in itself.
<beneroth>
nearly all other lisps removed fexpr from the language somewhere in 70s because fexprs can not really be compiled. They went for macros instead. Fexprs are a bit more powerful than macros.
<beneroth>
if you want to compare to other languages, look through some code on rosettacode.org/
<beneroth>
for me, the main things where picolisp shines and I haven't found something else more powerful yet: building flexible maintainable business applications, huge applications from small code snippets. excellent database framework for such kinds of data. easy to change when requirements change (and requirements are rarely ever set in stone when human users are directly involved). and very handy for scripting tasks and wrapping other CLI tools.
<abu[m]>
Cool beneroth, a very good and detailed explanation!