Re: Special Build Modes
Hi all, > PicoLisp can now optionally be built as a shared library (picolisp.so), > and/or with some protective armor to make it more robust against attacks > and errors. > > Details can be found here: > >https://software-lab.de/doc/SpecialBuilds Now I released a slightly updated version, with a more realistic library build. It is meant as an example, or a template for indivdual configuration. Under "# Base system as shared library" all libraries -lc -lutil -lm -ldl `pkg-config --libs readline libffi` are omitted now. The base system is configured for the lib in "src/lib/so.l" to remove -- Signal handling -- GNU readline -- Native FFI -- The 'byte' function A reduced version of "src/lib.c" is provided as "src/lib.so.c". Finally, a minimal C program to link and test the lib is in "soTest.c". ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
On Tue, Sep 02, 2025 at 01:43:53PM +0530, SuperSaiyanBlue wrote: > Superb. The webpage says the picolisp will be 10-30% slower. And the binary > will be 15% larger. > > Is building picolisp in this manner going to make it permanently slower or > only when you invoke the Quiche > Mode? Once compiled with -quiche, it will be permanently slower. The checks are built-in on the lowest code levels, in many places, everywhere memory or functions are accessed. ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Superb. The webpage says the picolisp will be 10-30% slower. And the binary will be 15% larger. Is building picolisp in this manner going to make it permanently slower or only when you invoke the Quiche Mode? 31 Aug 2025 14:26:32 Alexander Burger : > Hi all, > > PicoLisp can now optionally be built as a shared library (picolisp.so), > and/or with some protective armor to make it more robust against attacks > and errors. > > Details can be found here: > > https://software-lab.de/doc/SpecialBuilds > > I can explain more about it at our next Fridays for Functions meeting. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
On Tue, Sep 02, 2025 at 09:04:03AM +0200, Alexander Burger wrote: > True. To avoid WhatsApp, I first tried DeltaChat and then Matrix > (Element, FluffyChat, Element X). .. and, in between, I experimented with Bitmessage, Briar, Veilid and perhaps more :( -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Tomas, > You change chat apps quite often. True. To avoid WhatsApp, I first tried DeltaChat and then Matrix (Element, FluffyChat, Element X). > How do you migrate or archive all the data? > With email I have have maildir but chat apps are like /dev/null. I save attachments that I want to keep locally on Termux, so they go into my backups. The rest is not so important, but I still have the old clients around an can look. ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Alex, On Mon 01 Sep 2025 at 07:01, Alexander Burger wrote: > I plan to completely switch to it. I tried it and it seems to work pretty well. You change chat apps quite often. How do you migrate or archive all the data? With email I have have maildir but chat apps are like /dev/null. Cheers Tomas -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Tomas, > > BTW, you can contact me with SimpleX Chat on > ... > I still haven't found time to setup the chat server > according to your instructions. You do not need to set up a server. Just install a SimpleX Chat client and paste the contact link. > Is this yet another chat protocol? Indeed :) https://simplex.chat > I have tried a few chat protocols and none were good enough. I plan to completely switch to it. > >> What about a tag for functions? > > > > Why a tag? The values of symbols are ideal. > > A tag would allow to discriminate functions from other types > as an alternative to the fixed index table. Ah, yes, a tag on the pointer level. > I guess you do not have any spare tag available Right. And I suspect that the interpretation of such a tag at runtime would be more expensive than a simple indirection. ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Alex, On Sun 31 Aug 2025 at 15:39, Alexander Burger wrote: >>: (cdr 7) >>!? (cdr 7) >>7 -- List expected >> >> that's nice. > > This has always been (direct argument check). > > What I meant is things like (cdr . 7) or (nth '(a b c d . 7) 3). I see, I misunderstood what has changed. > The reason I made the library and quiche modes is to allow an embeddable > PicoLisp, accsssible by users (to be exact, in SimpleX Chat). For that, > of course, also all memory access, I/O, signals, and POSIX stuff must be > removed. Interesting. > BTW, you can contact me with SimpleX Chat on > > > https://smp17.simplex.im/i#InbbhFW96Dr6Ny_YS45uSBHz05bCdBTF/sA0KcV2Isq0fC7hRPaWZqnc1Kl3plo3u2E1a6EBwZHg > > or the PicoLisp group at > >https://smp16.simplex.im/g#wfyp5lU6OdOjLCqe09kVyyme5yTE9rM8ov83glwgA7I I still haven't found time to setup the chat server according to your instructions. Is this yet another chat protocol? I have tried a few chat protocols and none were good enough. So far email pretty much "just works". >> Do you have an example where this is used? > > The shared libs like ext and ht use that. I see. >> What about a tag for functions? > > Why a tag? The values of symbols are ideal. A tag would allow to discriminate functions from other types as an alternative to the fixed index table. I guess you do not have any spare tag available or maybe there would be other issues. Cheers Tomas -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Tomas, >: (cdr 7) >!? (cdr 7) >7 -- List expected > > that's nice. This has always been (direct argument check). What I meant is things like (cdr . 7) or (nth '(a b c d . 7) 3). > You have resisted this for decades. > What has changed? I'm still resisting :) Such checks are not needed normally. The reason I made the library and quiche modes is to allow an embeddable PicoLisp, accsssible by users (to be exact, in SimpleX Chat). For that, of course, also all memory access, I/O, signals, and POSIX stuff must be removed. BTW, you can contact me with SimpleX Chat on https://smp17.simplex.im/i#InbbhFW96Dr6Ny_YS45uSBHz05bCdBTF/sA0KcV2Isq0fC7hRPaWZqnc1Kl3plo3u2E1a6EBwZHg or the PicoLisp group at https://smp16.simplex.im/g#wfyp5lU6OdOjLCqe09kVyyme5yTE9rM8ov83glwgA7I >Quiche Mode does not allow user-controlled function pointers. > > What are user-controlled function pointers? You can set an arbitrary number which can be then called. > Do you have an example where this is used? The shared libs like ext and ht use that. > What about a tag for functions? Why a tag? The values of symbols are ideal. ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Re: Special Build Modes
Hi Alex, On Sun 31 Aug 2025 at 10:43, Alexander Burger wrote: >https://software-lab.de/doc/SpecialBuilds : (cdr 7) !? (cdr 7) 7 -- List expected that's nice. You have resisted this for decades. What has changed? Quiche Mode does not allow user-controlled function pointers. What are user-controlled function pointers? Do you have an example where this is used? It uses small numberic indexes into a table of allowed functions. What about a tag for functions? Cheers Tomas -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
Special Build Modes
Hi all, PicoLisp can now optionally be built as a shared library (picolisp.so), and/or with some protective armor to make it more robust against attacks and errors. Details can be found here: https://software-lab.de/doc/SpecialBuilds I can explain more about it at our next Fridays for Functions meeting. ☺/ A!ex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
