Re: PicoLisp source: how to recursive call?
Hi Constantine, > I have a crazy idea to make a patch to PicoLisp that would allow > handling signals even during long native call (i. e. libcurl > download). Yeah, I remember our discussion about this in IRC :) > The idea is to process signals immediately if PicoLisp not > in critical section of the code. I’m trying to modify `sig` function > in `main.l` as follows: > > (de void sig ((i32 . N)) >(if (val $TtyPid) > (kill @ N) > (set $Signal (+ (val $Signal) 1)) > - (let P (ofs $Signal (gSignal N)) > - (set P (+ (val P) 1)) ) ) ) > + (if (val $Protect) > + (let P (ofs $Signal (gSignal N)) > +(set P (+ (val P) 1)) ) > + (sighandler 0) ) ) ) > > However `sighandler` is undefined at this moment. I can’t move the > `sig` function after `sighandler`, since `sighandler` itself calls > `sig`. In such cases, a forward declaration is needed. You could write somewhere before `sig` (de void sighandler (any)) However: The reason for PicoLisp handling signals this way (i.e. not calling (sighandler 0) immediately, but accumulating all signals in the global $Signal array) is *not* to protect critical code sections (as indicated by $Protect). The reason is that a signal may occur at any moment, and 'sighandler' wants to run Lisp code. But Lisp code can be executed only at very well defined places in the code, when PicoLisp is not in the middle of building or modifying stack or heap structures, or even doing a garbage collection. At such safe places 'sigChk' is called, which may call 'sighandler' if any signals were accumulated meanwhile. An exception is 'sigChld', which handles the signal immediately. But this is safe too, as it neither calls Lisp code, nor does it modify any global structures. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Test - please ignore
Test ☺ -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Garbage collected coroutines?
Hi František, > I've used the following method in other programming languages (Lua, Janet) > and I'm wondering whether I can do something similar in PicoLisp: > > I've got a coroutine that generates an infinite sequence of data. > ... > The upshot of this method is that I don't have to manually kill any of the > coroutines, they are all automatically garbage collected when I no longer > use them. In PicoLisp, execution and garbage collection of coroutines are related in this way: While a coroutine is running - *independent* from whether it is referenced from anywhere else - it will not be garbage collected. Only if it finished execution (either by dropping off the end of its code, by doing a 'throw' outside itself, or by being explicitly stopped by another (co)routine), it will be garbage collected. Collected are then all data which are referenced from the now freed stack segment. > If I understand it correctly, creating a coroutine in PicoLisp creates > a global symbol that keeps the reference to this coroutine This not correct. The coroutine does not create a symbol. It is the Lisp *reader* which finds or creates a symbol 'myCoroutine' when reading an expression like (co 'myCoroutine (...)) But this symbol is just a tag to access the coroutine. It is not relevant for garbage collecting the coroutine itself. This symbol does not need to be global. You can use a transient symbol (co "myCoroutine" (...)) and thus have a file-local scope, or use a namespace. The transient symbol may go out of scope, but the coroutine continues to exist until it terminates as described above. > explicitly remove the coroutine when I no longer need it - it can never get > automatically garbage collected because it's linked to a global symbol. So you indeed need to call (co 'myCoroutine) if you are not sure if it did not already terminate by itself. But this has nothing to do with the tag symbol. Let's clear up this in IRC :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Noobie query
On Sun, Jun 02, 2024 at 02:57:18PM -0400, Lloyd R. prentice wrote: > Unless it’s inconvenient for any and all. I’ll post here. Perfect! Please ask. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Noobie query
Hi Lloyd, > I’ve subscribed to the mailing list. Have received posts. But I can’t find the > webpage to post questions. Is posting via email as I’ve done here the only > way? Posting here is fine. But more discussions currently take place in the "#picolisp" IRC channel on libera.chat, or the #picolisp:7fach.de Matrix room. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Coroutine produces segmentation fault
Hi František,
> I wrote a small script to generate and print the values of sine wave, as
> follows:
> ...
> (for N 44100 (printsp (co 'masterOut T)))
> ...
>
> wave. However, when I increase the number on the next-to-last row tenfold
> (from 44100 to 441000), the script produces a segmentation fault (after
> printing lots of "(" parentheses) on line 13 (the "for" loop). What am I
> doing wrong?
It looks all good so far. Also, it runs fine here with 441000.
What version of Pil are you using?
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Blog: Discrete-Event Simulation
Hi all, Mia posted a new article about Discrete-Event Simulation: https://picolisp-explored.com/a-railroad-simulation-with-des It is a demo for a model railroad system. Lots of fun playing with it! :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Android keyboad for terminal
Hi Edgaras, thanks for your work! On Wed, Mar 13, 2024 at 06:55:27PM +0200, Edgaras Šeputis wrote: > Who is writing here actually? Alex? No, not me. Strange that there is no name ... ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 1brc
On Sun, Mar 10, 2024 at 08:42:21AM +0100, picolisp@software-lab.de wrote: > I would like to share picolisp single process version: > https://git.envs.net/mpech/tankf33der/raw/branch/master/1brc/demo.l > ... > Parallelized version is a question of future research. Thanks Mike! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: "macros" in miniPicoLisp
On Sat, Mar 02, 2024 at 10:05:00AM -0800, C K Kashyap wrote: > Another installment of the video - > https://www.youtube.com/watch?v=O52fRAsr7Vg Very nice indeed! This is probably the first time PiccLisp does something non~triwial on Windows. Tharks for sharing! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Printed representation of (char 0) ?
Hi Thorsten, > I wonder if there actually is a way to directly print ^@ in PicoLisp for a > "non-printable" hex "00", instead of NIL? As we see from the previous discussion, this is not an issue of printability. Other control characters may also be non-printable. It is an issue of binary data vs. symbol names. But you can of course print a caret and an at-mark instead of NIL (prin (or (something) "\^@")) > Wrt the application, I just have to deal with fixed length hex strings (!) > where the values at certain offsets carry semantics, conversions are done, > and it's crucial that values stay in that position, the NUL values matter. Yes, but why do you need to convert it to a string? I would process these data all exclusively as a list of numbers, and do the final printing explicitly (if needed at all). This printing may print '0' as "\^@", and also take care of other control characters and non-printable stuff. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Printed representation of (char 0) ?
Hi Thorsten, > But shouldn't hex 23232424 print to something like ##^N^N$$ instead of > ##$$ ? The problem is that you try to handle binary data as symbols. This is not a good idea. Binary data are numbers. First of all, do you really have a hex message? Where does it come from? Normally I would expect a list of numbers as obtained with e.g. (make (do 96 (link (rd 1 If it is really a hexadecimal string, you can obtain the list of numbers with : (make (for (L (chop "23232424") (cut 2 'L)) (link (hex @ -> (35 35 0 0 36 36) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Printed representation of (char 0) ?
Hi Thorsten, > it's been some time .. ;-) Welcome back! :) > I'm playing around a bit with hex<->ascii conversion in PicoLisp, and I > have the problem that (char 0) = NIL > > (hex "00") > -> 0 > : (char (hex "00")) > -> NIL This is correct. 'char' converts a number to a (transient) symbol here. A symbol's name is a string, a null-terminated sequence of UTF-8 characters. In case of 'char', this string has a single character and a terminating null byte. This is the same as in other languages like C. So the number 65 gives a symbol "A": : (char 65) -> "A" But what happens with 0? It gives an empty string, i.e. a null-byte : (char 0) -> NIL and an empty string in PicoLisp is NIL. : "" -> NIL ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: "macros" in miniPicoLisp
Hi Kashyap, > Does this look like a reasonable way to create the "create-adder" function? > > (de create-adder Args >(let > (N (car Args) > Adder (intern (pack "add-" N)) > P > (list > 'de > Adder > '(X) > (list '+ N 'X) ) ) > (eval P) ) ) > > : (create-adder 10) > -> add-10 > : (add-10 20) > -> 30 Yes, but you can do it a little simpler by directly calling 'def': (de create-adder (N) (def (intern (pack "add-" N)) (list '(X) (list '+ N 'X)) ) ) Note also that I use (N), i.e. an evaluated argument, as this makes the function more general. Even simpler if you use 'curry': (de create-adder (@N) (def (intern (pack "add-" @N)) (curry (@N) (X) (+ @N X) ) ) ) It is especially simpler if the function body, which is here just (+ N X), is more complicated, because then the 'list'ing and 'cons'ing of the body would become very unreadable. > If I understand correctly, the "macro" capability of miniPicoLisp is not at > par with PicoLisp right? The 'macro' function of mini and normal PicoLisp is the same I think. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: miniPicoLisp + libuv +libSDL
On Thu, Feb 01, 2024 at 09:05:17AM -0800, C K Kashyap wrote: > I finally got around to recording a video (my video recording muscles have > atrophied :) ) > > https://www.youtube.com/watch?v=Uv0ZiZAfcGc Wow, that's cool! Now I see what your intentions are! Thanks! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: minipicolisp with big num
Hi Kashyap, Mike, > Hey Mike ... I am actually asking if there is such a port/variation of > miniPicoLisp that has big num support - just like the regular picoLisp. I have never heard of any such version. In fact, I believe that at the moment you are the de-facto specialist of miniPicoLisp. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: miniPicoLisp + libuv +libSDL
Hi Kashyap, > ping Alex :) Yes, very good! There is just not much I can say here :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bye from forks sends signals?
Hi Dmitry,
> Is this newsletter alive?:)
Yes, just not so noisy :)
> I'm playing around with `native` and ZeroMQ and found a curious behaviour.
>
> (unless (fork)
> (wait 2000)
> (bye))
>
> (setq Context (native "libzmq.so" "zmq_ctx_new" 'P))
> (setq ZMQ_REP 4)
> (setq Socket (native "libzmq.so" "zmq_socket" 'P Context ZMQ_REP))
> (native "libzmq.so" "zmq_bind" 'I Socket "tcp://*:")
>
> (buf
> Buffer 10
> (prinl "Waiting for messages")
> (when (= -1 (native "libzmq.so" "zmq_recv" 'I Socket Buffer 10 0))
>(prinl (pack "Error: " (errno)
This looks good.
> The `errno` is 4 (which is signal interrupt as i understand).
Yes. EINTR is 4 on most systems. You can see it with
: (sysdefs "errno")
-> EACCES
: EINTR
-> 4
or (vi "@lib/sysdefs").
> My assumption here is that `bye` throws some signal? Why else would it affect
> zeromq in the parent process?
> Actually, while writing this I found out about SIGCHLD which is apparently
> sent to parent on child's exit so I guess zmq_recv gets interrupted by that
> for some reason?
Absolutely correct. The child sends a SIGCHLD signal, which must be handled or
ignored.
I don't have libzmq at the moment and cannot test it, but I think it should be
something like
(while (lt0 (native "libzmq.so" "zmq_recv" 'I Socket Buffer 10 0))
(unless (== EINTR (errno))
(quit (errno) "Signal") ) )
> P.S. completely offtopic but since I'm here. I just noticed that semicolons
> aren't treated as comments. Why?
Comments in PicoLisp are # or #{...}#.
> Can it be enabled? Otherwise my Emacs' lisp-mode comment/uncomment function is
> useless and no comment highlight either.
There is no built-in way to change it. There are some Emacs libs for PicoLisp,
but I don't use Emacs and cannot be helpful here.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: External allocations using miniPicoLisp
Hi Kashyap, > I think "finally" will do what I need :) Yes, good idea! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: External allocations using miniPicoLisp
Hi Kashyap, > Is there a reference implementation of external allocation using > miniPicoLisp? > > Here's what I'd like to do - Create a new function called "alloc" that > allocates some memory. > > (let A (alloc 100) > (poke A 0 10)) # poke simply writes a byte(10) at offset 0 I do not know if anybody has done this in miniPicoLisp, but the official PicoLisp has functions 'buf' and 'byte' which behave that way: (buf A 100 # Allocate on the stack (byte A 10) (byte (+ A 7) 11) ... ) 'buf' allocates memory on the runtime stack, and cleans it up when done. You can also explicitly allocate system memory to get the same effect, but this has more overhead: (let A (%@ "malloc" 'P 100) # Allocate memory (byte A 10) ... (%@ "free" NIL A) ) # Clean up > The part I want to ensure is that the memory that's allocated by alloc gets > collected by the GC. This does not make sense. The garbage collector traverses the 'heap' structures, managing used and unused cells (as discussed in our last mail). Memory allocated by 'buf' or malloc() does not contain cells reachable from Lisp data structures, and is therfore not known by the garbage collector. And as it is not part of the linked list of 'heap's, it will not be free'd. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: possible bug in miniPicoLisp?
On Wed, Nov 29, 2023 at 08:08:33PM -0800, C K Kashyap wrote: > Thanks Alex - half a dozen worked in my example :) Great :) > I completely get the idea of the inefficiency of CELLS=1 - the segfault OK > however seems like a silent bug (more likely some optimistic avoidance of a > NULL check somewhere perhaps). What do you think? Yes, it is definitely a bug if YOU set the heap to a bad size. As long as it is big enough, a runtime check is meaningless and will never fire. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: possible bug in miniPicoLisp?
Hi Kashyap,
> I attempted to use 1 as the CELLS value in pico.h and immediately ran into
> segfault
Yes, this is not a good idea ;)
CELLS is the number of cells per heap
typedef struct heap {
cell cells[CELLS];
struct heap *next;
} heap;
and PicoLisp allocates as many heaps as needed.
Setting it to 1 creates a huge overhead, because then you'll have one 'next'
link for every cell.
The cells in the heaps are maintained to hold internal linked lists for the
unused cells. Probably this will not work if CELLS is 1.
> Why am I trying CELLS = 1? Just poking around - I was just trying to figure
> out the min number of CELLS I needed for certain programs.
You can get the number of cells in a function with 'size':
: (size '(a b c))
-> 3
: (pp 'test)
(de test ("Pat" . "Prg")
(bind (fish pat? "Pat")
(unless (match "Pat" (run "Prg"))
(msg "Prg")
(quit "'test' failed" "Pat") ) ) )
-> test
: (size test)
-> 23
Even a minimal system needs a few thousand cells.
Setting CELLS to just a few dozens would work, but the overhead of maintaining
so many heaps will become relatively large.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil21 installation fail
On Sat, Nov 11, 2023 at 04:14:02PM -0500, polifemo wrote: > clang-16: error: unable to make temporary file: No such file or directory > make: *** [Makefile:32: ../lib/sysdefs] Error 1 > ``` > > I think it's trying to search for the sysdefs.c file in pil21/lib, but the > file is in pil21/src. But I can be wrong. It does not say that sysdefs.c is not found, but that clang cannot create a temporary file. Where does clang create its temporary files? https://stackoverflow.com/questions/13336168 says: When not using the --save-temps option the temporary files are created in a default directory (i.e. $TMPDIR such as /tmp) Can you find but more? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Thu, Nov 09, 2023 at 08:08:22AM +0100, Alexander Burger wrote: > Now I understand the problem! > > "App.l" has three garbage bytes in the beginning; I tried on another device. It is all not such a big problem :) Though PilBox cannot initialize with that faulty file, you can just fix it, and zip and termux-share it once more. PilBox then starts up fine again. So it is not true what you wrote, i.e. that termux-share does not work in this broken state. The unpacking and installation of ZIP files happens on the Java level *before* any Lisp is started, so you can always undo any mistakes. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen PilBox
On Thu, Nov 09, 2023 at 02:37:12AM +, Shaughan Lavine wrote: > The cache needs to cleared for a new style to take effect. Is that a bug? No. PilBox (and PicoLisp in general) caches CSS files for 24 hours. See line 34 in @lib/http.l (`(chop "css") "text/css" 86400) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
Hi Shaughan, > Yeah, I'm pretty curious too. The zip opens fine in at least one other App. > I've attached it. Maybe you will see something. Now I understand the problem! "App.l" has three garbage bytes in the beginning; ~/tmp ~/pil21/pil + : (hd "test/App.l") EF BB BF 22 54 65 73 74 22 0A 0A 28 6D 65 6E 75 ..."Test"..(menu 0010 20 22 54 65 73 74 22 0A 20 20 20 28 3C 68 31 3E "Test". ( 0020 20 22 63 65 6E 74 65 72 20 66 68 22 20 22 54 65 "center fh" "Te 0030 73 74 21 22 29 20 29 0A st!") ). -> NIL : (bin (hex "EF")) -> "1110" : (bin (hex "BB")) -> "10111011" : (bin (hex "BF")) -> "1011" The first byte is "1110", which is the first byte of a *four* byte UTF-8 sequence. This usually not really a problem, PicoLisp just reads a garbage character. I have of course not tried to install the file, but obviously PilBox gets confused. It expects a certain structure in the first line of each "App.l" found upon startup. It skips until the *next* double quote, and 'load's possible further files. As the *first* double quote is already eaten up by that bad byte sequence, it starts from the last double quote of "Test". I will try to make this more robust. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Wed, Nov 08, 2023 at 07:06:59PM +, Shaughan Lavine wrote: > "termux-share test.zip" once again froze everything. "termux-share hello.zip" > worked fine. I'm stumped by that, but I'm going back to what I was doing > before—with better backups. I'd really like to know the reason. Is the ZIP damaged? Or is it the name "test" which conflicts somehow? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
Hi Shaughan, > The update did nothing, so I uninstalled then reinstalled, and, lo and behold, > my main app was still there, with only two days worth of data missing. Great! I remember the opposite case. We could not get rid of old data, even over a re-install, unless we went to "Memory and Cache" in the Android settings for PilBox, and cleared memory and cache explicitly. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Tue, Nov 07, 2023 at 10:07:12PM +, Shaughan Lavine wrote: > I'll most certainly wait till tomorrow and see if updating does the job. Now I released PilBox 23.11.8 to PlayStore. It may take some time to propagate, but you can also download it as ever from https://software-lab.de/pilBox.apk and the sources from https://software-lab.de/PilBox.tgz Hope this helps :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
Hi Shaughan, > A!ex– > I'll most certainly wait till tomorrow and see if updating does the job. I > would have tried that earlier, but I don't know how to force a reinstall. When PilBox starts up, it checks the file "Version". If this file does not exist or has a different value, all Lisp files from the APK replace the old ones. If I messed something up, I sometimes simply do (call "rm" "Version") and then restart PilBox, but this is no option here as you cannot get a REPL. If you build or get a new version, "Version" will have changed in the new APK and everything is installed. Other data in PilBox are not deleted or modified. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
Hi Shaughan, > Ah well, unless you have any further suggestions, lesson learned. I'll only > lose 12 days of data, and I'll fix permissions so it won't happen again. > For want of a permission, the data was lost, and all for the wane of a chmod > 660 I don't quite understand. What permissions did you change, and how? Would it help to install a new PilBox version? This would overwrite just PilBox itself, but not your data. I was planning a new release tomorrow anyway. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Announce: Database 'search' Function
Hi Abraham,
> I see how I can 'and' criteria together, but can I 'or'?
Yes, but you need to supply Custom Generator and Filter functions.
The documentation has an example for this in "Multiple Indexes", where a
telephone number being searched for may be in the landline *OR* in the mobile
index. The example uses the existing 'relQs' function which in turn generates
the necessary generator and filter functions.
> For instance I
> have a search for items where I want to return all of them that have a link
> to 1 or more tags in a list. Right now I was running the search for each of
> my tags and using 'push1' to get the desired results. Is there a better way?
Perhaps, but it is a bit tedious to supply the proper functions.
What are the "tags" in your case? As you talk about "link"s, I assume they are
(+Ref +Link)s to other objects.
If so, if we take itams and supuliers from the demo app, then items can be
searched by suppliers. Let's assume we have a list of 2 suppliers ({C1} {C2}),
we can search for their items with:
(for
(Q
(search
'({C1} {C2}) # List of suppliers
(quote
((X) (cons (list X) pop)) # Generator
((X Val) (memq X Val)) # Filter
(sup +Item) ) ) # Association to item by 'sup' index
(search Q) )
(show @) )
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Tue, Nov 07, 2023 at 07:33:29AM +, Shaughan Lavine wrote: > Would it have been ok to just create the test directory (!mkdir test), copy > App.l into it, and add PIL-test? I would find that simpler than the zip then > share dance. Yes. You don't even need PIL-test. The PIL-* files are only for the zip uploading, and viewing and deleting in the GUI. Just creating a directory with a file "App.l" is enough. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Tue, Nov 07, 2023 at 07:15:07AM +, Shaughan Lavine wrote: > ~ $ unzip -l storage/shared/Download/test.zip > Archive: storage/shared/Download/test.zip > Length Date Time Name > - -- - > 0 2023-11-06 16:27 test/ > 56 2023-11-06 16:28 test/App.l > ... > -- > "Test" > > (menu "Test" > ( "center fh" "Test!") ) > -- This looks all perfectly correct. > I can't use bin/pty, since pilbox isn't starting properly. I tried, but it > just times out. Then perhaps somehow the file "App.l" in the PilBox home directory (i.e. the PilBox app itself) got overwritten? You could try to restore "App.l", by extracting it from the sources. You probably know, but for the records: $ curl -O https://software-lab.de/PilBox.tgz $ tar xfz PilBox.tgz PilBox/assets/run/App.l $ cd PilBox/assets/run/ $ zip -r a.zip App.l $ termux-share a.zip Let's hope ;) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
On Tue, Nov 07, 2023 at 07:28:27AM +0100, Alexander Burger wrote: > The easiest fix is connecting via 'bin/pty' to a REPL and doing "rm -r test/". This was not completely correct. Of course it is : (call "rm" "-r" "test/") Just in case you have not enabled PTY yet: As you cannot use the built-in REPL of PilBox now, you can upload the necessary ".pty" file also via zip. E.g. on Termux: $ cd $ vi .pty $ zip -r x.zip .pty $ termux-share x.zip $ pil21/bin/pty ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Frozen Pilbox
Hi Shaughan, > I created a copy of the Hello World example, changed "Hello World" to "Test" > everywhere placed in a folder named "test", zipped it, then used Termux to > share > it with Pilbox. This sounds all correct. > > Pilbox now displays as a completely black screen with the logo in the > > middle, > and does nothing. I cleared the cache, force stopped the app, ano rebooted. No > change. I have lots of data in another app within Pilbox, so I can't just > reinstall. Any suggestions? I can provide further details of other things I > had > done before, but I don't know whether it would be relevant. Android 13. What might be wrong with the ZIP? Does it contain just one single file named "App.l"? If so, nothing else in PilBox should be overwritten, and the problem can be only in the first line of that file, because nothing else is read at PilBox startup. Can you post the output of "unzip -l test.zip" and the content of "App.l"? Attaching the whole ZIP to a mail here is probably not a good idea due to spam filtering. The easiest fix is connecting via 'bin/pty' to a REPL and doing "rm -r test/". ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pilbox, view html
Hi Shaughan, > Is there a way to view the generated html within pilbox? Yes, though a bit tricky, as this is not built-in. Get a PTY (pseudo TTY) to the REPL in your PilBox, as described in: https://picolisp-explored.com/mobile-app-development-in-picolisp-v-getting-a-remote-shell-to-your-pc Then temporarily modify the 'http' function in-memory (without actually modifying the source code!!): : (v http) Move down to line 49 (out *HtSock change it to e.g. (out "src.html" and type :w Now 'http' is modified in-memory. No need to exit Vip yet. In the PILBox GUI, click on something where you want to see the source. As the output is written to the file instead of the WebView component, you will see no reaction at all in the GUI. Now, in Vip in the PTY REPL, undo the change by typing "u" twice, an exit Vip with :x Now the PilBox GUI works normally again. You can look at the generated file with : (vi "src.html") or get it to the shell (Termux or PC) where you started 'pty' from : (pbGet "src.html") This is just a quick shot, a prove of concept. The whole process could probably be made more convenient. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Announce: Database 'search' Function
On Wed, Oct 25, 2023 at 09:57:52AM -0700, wayne horner wrote: > the demo app requires a login Oh, sorry! This was communicated a long time ago ;) User is admin, password is admin For tho OSM demo, user is osm and password is osm ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Announce: Database 'search' Function
Hi Christos, > I did notice a small spelling error in the documentation of search, > namely the word "referst". Ah, cool, thank you! I fixed it. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Announce: Database 'search' Function
Hi all, since version 23.10.23 PicoLisp has a new 'search' function. It allows to search the database for a combination of search criteria: https://software-lab.de/doc/search.html 'search' provides the same functionality as the Pilog 'select/3' predicate https://software-lab.de/doc/select.html but is much simpler to use, two to three times faster, and more general. It is recommended to use 'search' instead of 'select/3' for new projects. In the long term, 'select/3' will be deprecated. I have already replaced 'select/3' and the other Pilog database predicates in public projects: -- The PicoLisp tutorial https://software-lab.de/tut.tgz Relevant here is the "family" application -- Demo app https://software-lab.de/demoApp.tgz Online at https://picolisp.com/app The old version is still available for comparisons in https://software-lab.de/demoApp.pilog.tgz -- PicoLisp Wiki https://software-lab.de/wiki.tgz Online at https://picolisp.com/wiki -- Open StreetMap demo https://software-lab.de/osm.tgz Described in https://picolisp.com/wiki/?osmgeodata Online at https://picolisp.com/osm I hope that 'search' turns out to be useful. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: mailing list source?
Hi Yiorgos, > I am preparing a new mail server for the small mailing list I am > running with picolisp's software, and I see now that the source code > for it is not included (or it escapes my eyes). I don't remember if it was announced somewhere, but the source for this list is a single file "mailing.l" in https://software-lab.de/mailing.tgz I start it on the server in a tmux session as $ ./mailing.l It expects a file "Mailings" in the same directory, with a single mail address per line. Before you start it, edit it to set the globals in the first 'setq' (list name, domain, host, password etc.) Did I forget something? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: building pilos
On Thu, Oct 05, 2023 at 08:53:23AM -0700, C K Kashyap wrote: > How about something that runs on qemu using a bootloader like limine/grub? > It could be really vanilla without even the need for a keyboard driver > (using UART for io using --serial stdio option in qemu). The drivers/rest > of the kernel infrastructure could then be crowd sourced :) Will you give it a try? > Btw .. perhaps you have already answered this but, does it make sense to > have a different extension for the assembly files? Technically, I don't > believe that they are plicolisp sources right? You mean Pil64 and PilOS? (Beause pil21 has no assembly sources) The sources of Pil64 and PilOS *are* Lisp files. They are evaluated via 'load' in "src64/mkAsm.l". That's why I said in the last mail that a running PicoLisp is nneded to bootstrap the build. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: building pilos
On Thu, Oct 05, 2023 at 07:32:26AM -0700, C K Kashyap wrote: > Any chance that we could expect a pil21 based pilos? This would indeed be fascinating. Perhaps there is some LLVM backend to Verilog? But PilOS is a huge task, and needs lots of drivers etc. for some target hardware. I have no hope for the near future. > I had not been watching pil21 for a while - I looked at it now and I really > liked "lib.c" :) If I understood right, then all the platform > dependencies are in there (atleast as far as the picolisp executable) Yes, this is correct. In that way it is possible to distribute the pre-built *.ll files, and a running PicoLisp is no longer needed to bootstrap the build. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: building pilos
Hi Kashyap, > It looks like pilos build may be broken :( I think it has dependency on > pil64. This may well be. PilOS is built by PicoLisp, and is a modified and partially scaled down version of Pil64. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog on minipicolisp
Hi Kashyap, > It looks like the pilog support in minipicolisp is perhaps different from > picolisp. Am I missing something? The "diff" file does not really call out > anything. Hmm, I did not look at MiniPicoLisp for a long time ... ;) > kashyap@DESKTOP-NICP8CC:~/s/embeddedpicolisp/miniPicoLisp/src$ ../pil > : (be age (Paul 19) ) > !? (clause CL) > clause -- Undefined 'clause' is defined in "mini/lib/pilog.l". "mini/pil" however loads only "lib/misc.l". This would explain it. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: sigUnblock in stopTerm
Hi Constantine, > I'm studying PicoLisp sources and have 2 questions about `sigUnblock` func. > > 1. Does it called by `main` func in `main.l` because signals can be > blocked by parent process? Yes. The signal block mask is inherited across exec() calls. In fact, I don't remember exactly why this is recommended or needed in the PicoLisp main() function. > 2. Why it called in `stopTerm` func in `lib.c`? Is there is > possibility to block signals by external process? (I didn't found any > code for blocking signals inside PicoLisp.) stopTerm() calls sigUnblock(SIGTSTP), to block further SIGTSTP signals while being stopped. Here, too, I don't remember the exact reason. All this signal handling code is in PicoLisp since around April 2009. Do you think these calls are not needed? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Question about get/put REPL vs executing a file
Hi Kashyap, > kashyap@CPC-ckk-S75640M:~$ cat a.l > (de add (N D) >(put 'STORE N D) ) > (add "A" 10) > (add "B" 20) > (prinl (get 'STORE "A")) > (prinl (get 'STORE "B")) > kashyap@CPC-ckk-S75640M:~$ pil a.l > 10 > 20 > : (get 'STORE "A") > -> NIL > : version > -> 274406 > > Shouldn't I get 10 as a result of (get 'STORE "A") from the REPL? No, because transient symbols like "A" and "B" have a file-local scope (just like symbols in the 'private' namespace). Property functions like 'put' and 'get' access the value by the symbol itself (using pointer equality, '=='), not by the name. So the "A" in (get 'STORE "A") in the REPL *after* the file is loaded is another symbol than the "A" in the file *while* it is loaded. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: LLVM17
Hi Mike, > LLVM17 released and PicoLisp successfully > compiled out of the box and passed > all tests on it. > Happy coding. > > p.s. LLVM18-nightly works too so far. Great, good to hear that! Thanks a lot! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: SSL connection approaches...
Hi Todd, > I've been porting my "pure" Common Lisp MQTT client to Picolisp, and it has > gone > very well for non-SSL connections (I just used "connect"), but I am looking > for > a canonical way to connect to a SSL/TLS encrypted socket (no certs needed, I > just need basic encryption). > (de mq-open (Host Port SSL) >(if SSL > (pipe > (exec "ncat" "--ssl" Host Port) ) > (connect Host Port) ) ) > > Is this a good approach? Yes, looks good. > Using the FFI to call openssl library is more efficient, but I didn't want to > go > that path yet... I would not worry about efficiency here, because just a single process is started once. > Once concern I have with the above code is dealing with when a connection is > dropped. I would use the file descriptor returned from the above function in a 'task', and close (and perhaps restart) it when reading returns NIL (EOF). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: vip losing datStr definition?
Hi Abraham, > I'm stumped how this is happening if anyone can help. I had a little script > that used `datStr` that I was writing/testing in vip and the function > definition was undefined. > ... > But if I then run `vip` with a new blank file I see when evaluating the > same: > ... > : (datStr (date)) > !? (datStr (date)) > Undefined If you run Vip from the command line, it loads only a minimal system, "@lib.l" and "@lib/term.l". The function 'datStr' is in "@lib/misc.l", however, and thus not loaded. There are two possibilities: 1. You load "@ext.l" from the command line, and ideally also start debug mode: $ vip -'load "@ext.l"' myfile + 2. Better still is to call 'vi' from inside a running PicoLisp system, ideally inside the full application: $ pil myFile + Then you have everything in place and edit functions with : (vi 'foo) etc. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilBox & Java object lifecycle
On Sat, Aug 26, 2023 at 11:56:42AM -0400, Todd Coram wrote:
> Of course, tracking every object instantiation that gets stuffed into the
> HashArray isn't trivial,
The opposite (i.e. which objects are still referenced from Lisp) is easy though:
(filter
'((Obj) (== 32769 (car (id Obj T
(all 0) )
This returns a List of all accessible Java objects.
> It seems that any object returned by a Java method call is subject to be
> placed
> there so calls like (java (java someobject 'getResultingObject) 'doSomething))
> will place the inner object in the HashArray, correct?
Yes. The call inserts the result of (java someobject ...) into the hashmap, and
perhaps also the result of the outer 'java' call if it is an object.
For example,
: (java "java.io.File" T "name")
-> {H@@@10327432}
inserts *one* new object.
If that object's internals are accessed, for example by
: (show @)
{H@@@10327432} ({H@@@751603011} . "java.io.File")
filePath NIL
path "name"
prefixLength 0
status NIL
fs {H@@@1172500016}
pathSeparator ":"
pathSeparatorChar 58
separator "/"
separatorChar 47
serialVersionUID 301077366599181567
-> {H@@@10327432}
then also all objects referred by it (i.e. {H@@@751603011} and {H@@@1172500016}
will be inserted.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilBox & Java object lifecycle
Hi Todd,
> Perhaps something like:
> (java NIL 'obj) for removing it from the hashtable? The "complex management"
> of this could then be handled in pure Picolisp...
Very good idea! This fits nicely into the 'java' syntax, and has no harmful
effects if used wisely ;)
> Would it be as simple as something like (in Reflector.java reflect()):
>if (y == InOut.Nil) { // Release
> reference to Object
> Object o = lst[1]; // object to
> release
> int idx = o.hashCode();
> InOut.Obj.remove(idx);
> Io.Out.write(InOut.NIX);
> Io.Out.write(InOut.NIX);
> x = null;
>
> Or am I heading in the wrong direction?
No, this is basically correct. The write's are not needed, as they happen at the
end of reflect() anyway.
So I inseted:
1c1
< // 31jul23abu
---
> // 25aug23abu
58a59
>// (java NIL 'obj) -> NIL Release reference to object
120c121,125
if (y == InOut.Nil) { // Release
reference to object
> InOut.Obj.remove(lst[1].hashCode());
> x = null;
>}
>else if (y == InOut.T) { // Define
interface
and did some test. Works fine, and gives - as expected - a null pointer
exception if the object is accessed from Lisp again.
I cannot make a release to PlayStore now, as PilBox is in the process of some
changes to prepare for Android 14. So I made a temporary release available at:
https://picolisp.com/pub/pilBox.apk
https://picolisp.com/pub/PilBox.tgz
Thanks a lot for the good idea! :)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilBox & Java object lifecycle
Hi Todd, > I have a long running PilBox Android app that tends to just "crash" (with a > "Webpage not Available... net:ERR_CONNECTION_REFUSED") after running for a few > hours. At this point, the REPL is unresponsive at this point and nothing is in > the PilBox log file. I need PilBox open all day for various reasons, and monitor it constantly. So I notice quickly if something goes wrong. In fact it crashes sometimes, but it is usually longer than a few hours (more like about once or twice a week). Typical crashes are usually not PilBox's fault. Android is a nasty host system, it kills apps whenever it feels it needs memory (kills with -9, not -15 !!!). Other situations are when Android updates system components in the background (most notably the System WebView), then PilBox is also killed. But: In most of the above cases, there is no connection error, but PilBox "resets", i.e. it goes to the home screen and lost its context. Technically, this means a new instance of the internal PicoLisp process was started. If you see the above connection errors, it seems that the PicoLisp process is gone and not restarted. Not sure. Also you probably know that you can force a full stop of PilBox and PicoLisp by swiping it off. This stopping did not work reliable in older PilBoxes and was improved a few months ago. BTW, do you use a current version of PilBox? Latest official release was 23.7.13 (183) > My app makes heavy use of Java calls (dozens every 5 seconds) and this got me > wondering about how PilBox treats the Java object life-cycle. A valid question. > I don't see clearly how the Java objects themselves are referenced so as not > to > be collected by the Java GC. I do see a static HashMap in InOut.java. Are Java > objects "put" there to save them from the GC? Yes, this is exactly the reason. > If so, when are they removed from the HashMap? I don't see any "remove" in > InOut.java or other PilBox Java sources. > > If objects are referenced there Is it possible that these objects are never > freed? > ... 2nd mail > I should be a little clearer: I "instantiate" dozens Java object every 5 > seconds > and wonder how Pilbox affects their life-cycle I understand the question well. And was aware of the trade offs from early on. The objects in the hash map are indeed never removed. This would be difficult to implement, because the Java side has no information about which objects are still in use on the Lisp side. Is this is really the cause of the problem? Most java calls do not make a new object each time, and stored in the hash map are not all involved objects, but only those which are reflected back to Lisp (and not all created internally). And: The objects in the hash map are truly minimal. They have no local data, they are just stubs. They seem big when looked at with (show Obj), but all these data are generated on the fly via reflection and not part of the objects themselves. Still, you are right that this mechanism will use more and more memory. Have you checked it? I did occasionally, using something like this code in the REPL: (let R (java "java.lang.Runtime" 'getRuntime) (java R 'gc) (let (Fmt (-7 9) Mem (java R 'totalMemory) Free (java R 'freeMemory) ) (tab Fmt "Total" (format Mem 3 "." ",")) (tab Fmt "Free" (format Free 3 "." ",")) (tab Fmt "Used" (format (- Mem Free) 3 "." ",")) ) R ) Perhaps we can come up with ideas how to improve the situation. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Note: Function names inside the interpreter
Hi all, with the Pil21 release of today (version 23.8.8), the names of all Lisp entry point functions inside the binary interpreter (bin/picolisp) were changed. Until now, they were e.g. _car, _cdr, _read, _print etc. They were changed to an upper case first letter, _Car, _Cdr, _Read, _Print etc. The reason was a possible name conflict with system call functions in some operating systems (most notably FreeBSD). For "normal" PicoLisp programs nothing changes. Only if you called built-in functions directly via native calls, e.g. (%@ "_cons" T '(T cons (+ 3 4) (* 3 4))) you need to change that now to (%@ "_Cons" T '(T cons (+ 3 4) (* 3 4))) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: best Shebang line for executable scripts
On Sun, Aug 06, 2023 at 11:33:32AM +0100, Jason Vas Dias wrote: > Yes, but please mention something about '(script ...) in the > main 'ref' "Invocation" Section. It took me a long time to find! Can you first explain what you are trying to achieve? 'script' in the hashbang line makes no sense to me, because it is the *essence* of hashbang that the whole file gets scripted. Moreover, if there is no (bye) at the end, the script will be loaded TWICE! You wrote: #!/usr/bin/pil -script (car (nth (argv) 1)) (nth (argv) 2) (let (ars (car (rest))) (prinl (car (nth (file) 2)) " ARGS: " (sym ars)) ) (bye) First of all: PLEASE, PLEASE stop publishing code that violates the rules! How often do I have to say that??? Newcomers of PicoLisp will take those bad habits too! At least 'ars' should be 'Ars'. Then, (car (rest))) could be just (next) here. And - again - (car (nth (file) 2)) is unlispy. Use (cadr (file)). BUT: Why do you go through all that trouble? This does the same: #!/usr/bin/pil (prinl (cadr (file)) " ARGS: " (sym (argv))) (bye) Note that 'sym' is bad here. Does a lot of unnecessay conversions. Better is: #!/usr/bin/pil (prin (cadr (file)) " ARGS: ") (println (argv)) (bye) So why do we need 'script'? The example with 'load' #!/usr/bin/pil -load "@lib/http.l" "@lib/xhtml.l" is useful because it has dual use. You can execute it as ./myscript.l and "@lib/http.l" get loaded, or you can (load "myscript.l") in a program where thes files *are* already loaded. Then the hashbang is a comment and the files are not loaded again. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: best Shebang line for executable scripts
On Sun, Aug 06, 2023 at 07:20:40AM +0100, Jason Vas Dias wrote: > Wow ! I've just figured out the best execve(2) Shebang line for pil scripts: > > $ cat myscript.l > #!/usr/bin/pil -script (car (nth (argv) 1)) (nth (argv) 2) Just for the records, note that (car (nth Lst 1)) is the same as (get Lst 1) which is the same as (car Lst) And (nth Lst 2) is (cdr Lst) > Awesome! I've been missing something like this for ages. I use it sometimes to set up proper namespaces: #!/usr/bin/pil -symbols 'ap 'pico > I'd suggest adding documentation of this to the 'ref.html' > 'Invocation' section . There are examples for this around (though not very prominent), for example in https://picolisp.com/wiki/?serversentevents there is #!/usr/bin/pil -load "@lib/http.l" "@lib/xhtml.l" ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
Hi Jason, > ie. we should really track down what is making it coredump in the > non-'+'-suffixed > '(argv)' case when no error was reported when debugging is enabled by > '+' argv suffix - that was my only picolisp specific complaint . As I tried to explain several times in this thread (in this list and in direct mails), this has NOTHING to do with the debug mode. It is accidental that it happens only in debug mode here. Typical for such kinds of bugs which access memory in the wrong way. We call them "Heisenbugs" because they are often hard to reproduce, and disappear as soon as the memory layout is changed some way (e.g. by inserting debug code, calling garbage collection in another moment etc.). More often it is the opposite: Production code crashes, but when trying to debug it it does not. In your case, you accessed the heap via an additional indirection (using the value of the variable instead of the variable itself). So it depends where that indirection points to: If it is some "safe" place to access, nothing happens, if not, it crashes. You should have noticed early on by testing that the code is wrong and does never deliver reasonable results, because it can never have worked correctly. I have lots of other critics too. You seem quite resistant to advices ;) 1. In https://www.mail-archive.com/picolisp@software-lab.de/msg11265.html I told you three errors in the code but you still did not fix them. 2. In https://www.mail-archive.com/picolisp@software-lab.de/msg11264.html I wrote that binding 'cnt' to zero is a fatal mistake (setting a buit-in function to a null pointer. This is also not fixed. 3. In the mails I told you to PLEASE stick with the PicoLisp naming conventions! Having all local variables in lower case is an absolute no-go. You can see this very well with your 'cnt' example above. Using 'Cnt' (case!) would solve it. Please call (lintAll) after loading your code, and fix all those many issues with wrong, unused and unbound variables. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
On Wed, Aug 02, 2023 at 09:15:54PM +0200, Alexander Burger wrote: > On Wed, Aug 02, 2023 at 07:41:23PM +0200, Alexander Burger wrote: > > Though I don't know the reason for the crash, pleaes > > try to stick with pil conventions Other issues are: 1. In 'ipv4-route-flag' there is (let ... fs NI Probably a mistype and NIL was meant. 2. 'load-routes' uses 'ratr' without binding it in an argument or a 'let'. 3. 'prin_route' binds 'dstr' but never uses it. (I found these isskes with (lintAll)) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
On Wed, Aug 02, 2023 at 07:41:23PM +0200, Alexander Burger wrote: > Though I don't know the reason for the crash, pleaes > try to stick with pil conventions For example, in 'load-routes' there is (let ( cnt 0 tits NIL) However, 'cnt' is a built-in function, which is now bound to 0 (null-pointer). If some code (in 'load-routes' or any other function called from within it, it is sure to crash. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
> So the code MUST be in this loop when the coredump occurs :
OK
Though I don't know the reason for the crash, pleaes
try to stick with pil conventions
>(for r (idx ratr)
(foa R (idx Ratr)
> (when (and (bool r) (lst? r))
(when (and R (lst? R))
which is
(when (pair R)
> (let
> ( k (car r) v (cdr r) )
(let
((K . V) R)
> (case k
>('( "dst" "gateway" "dev" "metric" "mtu" ))
'case' does not eval the keys, so the quote is wrong.
> Why, only when the trailing '+' "Enable Debug Mode" is in '(argv)' ,
> should the behaviour of 'idx' change so drastically ?
> I can send you hundreds of such coredumps - they are not very helpful
Mike Pechkin tried to reproduce it, also with your recommended invocation, but
it does not crash. I think it is an heisenbug.
> unless you can combine using GDB with use of a live picolisp to inspect
> the stack . That is what I'd like to get working .
>
> I suspect the CFA stack frame info being generated and possibly data layouts
> when not in debug mode may be different to when in debug mode ?
Debug mode does not change anything in the interpreter.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
Hi Jason, > >Can you debug this a little more? E.g. look at the output of (traceAll) and > >see > > *where* exactly it happens. > > That's the whole problem - doesn't 'traceAll' depend on Debug Mode > being enabled by trailing '+' ? Oh, right, you said it happens only if *not* in debug mode. Still, as I said, I'm quite sure it does not directly have to do with debug mode. Rather it looks like a heisenbug to me, where the error appears and disappears depending on unrelated things like memory or stack layout, timing etc. It *can* be, though, that your program conflicts with stuff loaded only in debug mode. I did not succeed to test it here, but some parts of your code look suspicioos, at least noy following the Pil conventions. Perhaps some of your lower-cased locally bound symbbls conflict somewhere? In any case you could try other ways to debug it without complete debug mode, e.g. by inserting (msg '<1>) or so in various parts of the program until you find which 'idx' call crashes, and what the environment is at that moment. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
Hi Mike, > > Can you debug this a little more? E.g. look at the output of (traceAll) and > > see > > *where* exactly it happens. > > I am interested in debug this. Can i get a copy of script? I have fedora > rawhide instance. Great, thanks! I've sent you Jason's mails/ ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: coredump without '+' final argument
Hi Jason,
I did not try to install and run it.
But I think it is by chance that "+" has an influence on the crash. There must
be a "hard" reason.
What I can see from the stack backtrace, it crashes in 'consTree', so it must be
in one of the 'idx' calls.
Can you debug this a little more? E.g. look at the output of (traceAll) and see
*where* exactly it happens.
BTW, I cannot see your mail in the mail archive. Not sure if anyone else except
me got it. Probably because you mailed to me and put the list only into CC.
I send this directly to the list.
☺/ A!ex
On Tue, Aug 01, 2023 at 10:34:48PM +0100, Jason Vas Dias wrote:
>
> Good day -
>
> Why, without a final '+' argument, does the attached program coredump,
> when with a final '+' argument (enabling debugging) , it does not ?
>
> This is with picolisp 23.07.28 on my Fedora 36 12-core x86_86 laptop
> PC - my route printing / processing program:
>
> $ ./L_RT.l -pr +
> 0.0.0.0/0 wlp59s0 192.168.43.1
> UP,GW 600 { dev:wlp59s0 gateway:192.168.43.1
> metric:600 prefsrc:192.168.43.70 protocol:dhcp scope:global
> type:unicast}
> 0.0.0.0/32* 0.0.0.0
> UP,HO 0 { protocol:boot scope:global
> type:blackhole }
> ...
>
> $ ./L_RT.l -pr
> 192.168.42.1/32 ppp00.0.0.0
> UP,HO 0 { dev:ppp0metric:50
> prefsrc:192.168.42.10 protocol:kernel scope:link type:unicast}
> ...
> Segmentation Fault
> :
> [jvd@jvdspc]:~/src/pil21/src [3292] 22:05:06 [#:980!:28555]{1}
> $ gdb ../bin/picolisp /tmp/pil.1800629.core
> GNU gdb (GDB) Fedora 12.1-2.fc36 ...
> Reading symbols from ../bin/picolisp...
> (No debugging symbols found in ../bin/picolisp)
> [New LWP 1800629]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/bin/picolisp /usr/lib/picolisp/lib.l
> /usr/bin/pil /home/jvd/bin/L_RT.l -pr'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00444921 in consTree ()
> Missing separate debuginfos, use: dnf debuginfo-install
> libffi-3.4.2-8.fc36.x86_64 ncurses-libs-6.2-9.20210508.fc36.x86_64
> readline-8.2-2.fc36.x86_64
> (gdb) where
> #0 0x00444921 in consTree ()
> #1 0x00422428 in _for ()
> #2 0x004212f7 in _prog ()
> #3 0x0042324d in _let ()
> #4 0x0042324d in _let ()
> #5 0x00432469 in evExpr ()
> #6 0x0041fd02 in _eval ()
> #7 0x004211d8 in _bool ()
> #8 0x00421218 in _not ()
> #9 0x004214ac in _if ()
> #10 0x004212f7 in _prog ()
> #11 0x0042324d in _let ()
> #12 0x0043e505 in loop1 ()
> #13 0x00422573 in _for ()
> #14 0x0042324d in _let ()
> #15 0x0042324d in _let ()
> #16 0x004238c7 in _catch ()
> #17 0x00434476 in repl ()
> #18 0x004495b8 in main ()
> (gdb)
>
> quit
>
>
> This is from the route which has 2 identical idx tree 'keys':
> 192.168.42.1/32 ppp00.0.0.0
> UP,HO 0 { dev:ppp0metric:50
> prefsrc:192.168.42.10 protocol:kernel scope:link type:unicast}
> 192.168.42.1/32 ppp00.0.0.0
> UP,HO 50 { }
>
> Why does this situation cause a coredump / inability to process 'ip
> route' output without final '+' command line argument in effect ?
> Very strange - if the debugger is enabled , it
> should detect a problem and trap to it, no ?
>
> Any constructive ideas / suggested workarounds gratefully received .
>
> Note, it is not fixed by doing a '(load "@lib/debug.l") in the program .
>
> I'd like to be able to NOT have to specify '+' on the command line to
> avoid a coredump, OR , since debugging is enabled (with Emacs terminal
> settings in effect) , and I have a valid $EMACS_SERVER_FILE setting
> and Emacs server running, to bring up an Emacs debug session on
> occurrence of SIGSEGV / SIGBUS - is this going to be possible with
> a new picolisp version sometime soon ?
>
> Best Regards,
> Jason
>
>
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Announce: HTTP access in Vip
Hi all, with PicoLisp version 23.7.23 the Vip editor now has three new key commands, which allow to access pages on the Web. Vip already had "gf", which (like Vim) opens a *File* whose name the cursor is on, in a new buffer. 1. In a similar way, "gw" now renders a *Web* page whose URL the cursor is on, as text into a new buffer. 2. "gh" does the same, but shows the plain *HTTP* code. 3. Finally, "gb" opens a Browser (w3m) on that address. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: monocypher library
Hi Mike, > Here you could find various bindings against monocypher crypto library: > https://git.envs.net/mpech/monocypher-pil > > I will add more functions asap. Thanks for sharing! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Signal processing subsystem
Hi Constantine,
> I still want to use `libcurl` in PicoLisp and want default signal processing
> during long operations like `curl_easy_perform`, so I can i.e. terminate the
> script by Ctrl-C. I made this function (naming convensions are not so good):
>
> (de defsigint Prg
>(let action_size 160
> (buf defaction action_size
> (%@ "memset" NIL defaction 0 action_size)
> (buf oldaction action_size
> (%@ "sigaction" 'N 2 defaction oldaction)
> (run Prg)
> (%@ "sigaction" 'N 2 oldaction 0) ) ) ) )
Off~Topic, two notes:
* The naming conventions are good, just the three local variables should be
upper-cased)
* sigaction() returns an integer, so the call is better
(%@ "sigaction" 'I 2 ...
> This function sets SIGINT to default and then restores the original.
OK
I think you could instead simply reset SIGINT at the beginning of your script:
#!/usr/bin/pil
(%@ "signal" NIL 2 0)
...
There is no need to restore the original signal handler, as you want to
terminate the script anyway.
> This code is non-portable and hacky
The only nonportable things here are the constant SIGINT (which is usually 2
anyway) and the structure size. It would be sufficient to extend @src/sysdefs.c
by adding a "signal" section
ttl("errno");
and constants like
num("SIG_DFL", SIG_DFL);
num("SIG_IGN", SIG_IGN);
num("SIGINT", SIGINT);
and then call
#!/usr/bin/pil
(sysdefs "signal")
(%@ "signal" NIL SIGINT SIG_DFL)
> so I decided to patch PicoLisp to implement
> signal processing right way: make tools for saving, restoring signal handlers
> and make them universal instead of predefined set of signals. (I have an idea
> to
> make PicoLisp the only scripting tool on my Linux.)
OK, which other signals than SIGINT do you have in mind?
> But I confused with the source code. I.e. I see `sighandler` func, I see that
> it
> used only in `sigChk` func. So I can't get a picture of how signal processing
> is
> working in PicoLisp.
Correct, 'sighandler' does the actual dispatching of signals to the handlers
defined in Lisp code.
> Could you make some brief explanations of functions of signal processing in
> PicoLisp please?
Sure! I try!
The low-level signal handler, installed via sigaction() in iSignal(), is sig():
(de void sig ((i32 . N))
(if (val $TtyPid)
(kill @ N)
(set $Signal (+ (val $Signal) 1))
(let P (ofs $Signal (gSignal N))
(set P (+ (val P) 1)) ) ) )
It basically does nothing except remembering (counting) the signal in the global
'$Signal' array.
This is necessary, because a running PicoLisp must not be interrupted the hard
way. It may be in a critical phase like garbage collection or database
transactions. If for example a garbage collection is interrupted, no Lisp code
can be run, because the heap is in an unusable state (all pointers are
modified).
Thus, the interpreter needs to check for possibly remembered signals at "safe"
points. These are the 'sigChk' calls you saw.
(inline sigChk (Exe)
(when (val $Signal)
(sighandler Exe) ) )
The interpreter will handle all signal(s) which arrived meanwhile in
'sighandler', and then continue with normal processing.
> If I will make a patch with new signal processing will you accept such patch?
I'm not sure if this is possible without a major changes in the base system. Let
me know what your strategy is.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Security Update!
Hi all, we detected a critical security issue in the PicoLisp HTTP GUI: Per default, process-local temporary files (as maintained with the 'tmp' function) were implicitly 'allow'ed. This is OK for e.g. documents generated by the application to be downloaded by the user's browser. But in principle this allows also access to other temporary files not intended to be seen by the user, and - worst of all - execute such files if they have the ".l" extension. As a result, if a malicious user manages to upload an ".l" file to a running session, he can execute it in that session's environment. This is not trivial, as he must know the port, session ID, and process ID of that session, but not impossible with enough knowledge and a finite number of trials. The issue is fixed with version 23.7.17. Temporary files now must be explicitly 'allow'ed to be accessible via HTTP. Please download and install the rolling release from https://software-lab.de/pil21.tgz For most applications no change is needed, because the document functions in the PicoLisp runtime libraries take care to 'allow' what they generate. If your application creates other 'tmp' files which must be accessible in the GUI, please change all relevant (tmp ..) calls to (allow (tmp ..)) Sorry for the trouble! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Signal processing during FFI have no action
Hi Constantine, > I wrote a function that downloads file using libcurl. I found out that > when the the downloading process in progress by `curl_easy_perform` I > cannot interrupt downloading by Ctrl-C. Even `killall picolisp` does > not work. > > How I can make signals work during FFI? PicoLisp FFI does not do anything with signals. However, PicoLisp itself sets a signal handler for SIGINT (which is normally sent by Ctrl-C) to interrupt running Lisp code and drop into a breakpoint. While code is executing in a library like libcurl, all signals defined to be handled by PicoLisp will be *delayed* until the native code completes and Lisp takes back control. Note that killing will indeed work if you don't start a REPL (i.e. in a script). Then SIGINT retains its default behavior of terminating the process. I see no way at the moment for a native function called from a REPL, simply because such foreign functions do not know about Pil's signals. What if you do (call "curl" ...) instead of a native call, and kill the curl process? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: abort in less than a second
On Mon, Apr 24, 2023 at 06:45:06AM +0200, Danilo Kordic wrote: > I would use Linux.epoll. pil doesn't have it... yrt. PicoLisp has 'poll', which uses poll(2) or ppoll(2) internally. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: abort in less than a second
Hi polifemo, > I have a loop that executes a prg and then waits for the user to input > something. If the user does not input anything within the timeout, the > waiting is aborted and the loop restarts. > The problem is that, I want the timeout to be much faster, but 'abort only > works in seconds. Is there a way to abort a program after M milliseconds? Your question can be interpreted in two ways: 1. The program really just waits for user input. If this input can be handled on the keystroke level, you can call (key 100) to wait for 100 ms. 2. The loop is doing something and you want to interrupt that Then you can either use (poll 0) to check standard input in the loop, or install a signal handler like *Sig1 and do a (throw ...) in it. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Unsubscribe
On Sat, Apr 15, 2023 at 07:03:28PM -0400, picolisp@software-lab.de wrote: > Good bye r...@tamos.net :-( > Just changing (swapping) email addys. Yes, I saw the new one :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Subscribe
Hi Rick, On Sat, Apr 15, 2023 at 02:55:18PM -0400, Rick Hanson wrote: > Hello "Rick Hanson" :-) > You are now subscribed Cool! Welcome back! :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: DMARC and the PicoLisp mailing list
On Wed, Apr 12, 2023 at 08:23:18AM +0300, Yiorgos [George] Adamopoulos wrote: > I am using picolisp as the mailing list software for the Greek database > community. However, in order to mitigate issues with mail receivers I > relay outgoing email via Mailgun (it can be any of the mail sending relays > not them especially). It costs something like $7 per month (depends on the > volume) but complains went away. Ping me privately if you want to discuss > this further. Thanks Yiorgos! I'll keep an eye on it. As far as I see though, the current setup seems to work fine. At least I have no negative feedback so far. If anyone wants to check the PicoLisp source of the mailing script: It can be downloaded from https://software-lab.de/mailing.tgz ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: DMARC and the PicoLisp mailing list
Hi Frithjof, Jean-Christophe > As a data point: I am still getting mails. Cool! Thanks for the feedback :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: DMARC and the PicoLisp mailing list
On Sat, Apr 08, 2023 at 09:46:45AM +0200, Alexander Burger wrote: > I changed the PicoLisp mailer now, so that it puts the *name* of the sender > (if > known), combined with the e-mail address of the list, into the "From:" header, > and the original "From:" address into "Sender:".. > > A drawback of this change is that now the author's real e-mail address is not > immediately visible in e-mail clients. You have to inspect the "Sender:" > header > field to get it. > > Or is that even and advantage (privacy)? Hmm, no signs of life. Perhaps I broke it completely now? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: LLVM16
Hi Mike, > LLVM16 released and PicoLisp successfully compiled out of the box and passed > all tests on it. > Happy coding. > > p.s. LLVM17-nightly works too so far. Very good, thanks for the tests! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
DMARC and the PicoLisp mailing list
Hi all, we noticed that many mails did not reach the members of this list, due to new DMARC policies of some e-mail providers. The problem is that DMARC uses the mail header's "From" address (and not the "Sender:"). But in a mailing list, this address is the author of the mail, and not the list server which relays the postings. As a result, the postings are not transmitted. I changed the PicoLisp mailer now, so that it puts the *name* of the sender (if known), combined with the e-mail address of the list, into the "From:" header, and the original "From:" address into "Sender:".. A drawback of this change is that now the author's real e-mail address is not immediately visible in e-mail clients. You have to inspect the "Sender:" header field to get it. Or is that even and advantage (privacy)? Let's see how this works out! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Test with new From header
Test, please ignore! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: adj Re: Test Mail
On Thu, Apr 06, 2023 at 10:20:50PM -0700, Zgj Vjn wrote: > chvb Works, thanks! :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Test Mail
This is a test. Please ignore! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: mastodon account ?
Hi Jean-Christophe, > I really miss the Twitter picolisp updates. Would it be possible to consider > resuming the micro-blogging activity on a mastodon instance? I'm sorry, but I do not feel like I can do that. I found that micro blogging is not really my cup of tea after all. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: libffi.so.8 problem
On Sat, Mar 04, 2023 at 09:19:01AM -0600, Galaxy Being wrote: > I'm on a new machine, thus the old issues all over again. Yes, switching > back to the Debian apt install version works. Good. However, isn't it the case that PicoLisp in Debian 11 is not Pil21 yet, so the situation is different (libffi not needed)? > BTW, did the "@lib/edit.l" -- > Open error: No such file or directory problem with org mode ever get > figured out? I vaguely remember you and Thorsten J talking about it? Oh, yeah, I also don't remember. "@lib/edit.l" is not part of Pil21, and I think it is not needed anyway (?. > BTBTW, what happened with the picolisp email last night? Bisli angsterregend. What do you mean? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: libffi.so.8 problem
On Fri, Mar 03, 2023 at 08:47:00PM -0600, Galaxy Being wrote: > When I'm trying to start picolisp I get > > error while loading shared libraries: libffi.so.8: cannot open shared > object file: No such file or directory > > I'm on Debian 11 and it has version 7. Should I just do a symbolic link to > it? Did you install PicoLisp with "apt get"? If so, the right libffi-dev should be installed automatically. If you installed it locally, try also to install the libs $ sudo apt install binutils make clang llvm libreadline-dev libffi-dev libssl-dev pkg-config ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: methods receive more arguments than defined?
On Wed, Dec 21, 2022 at 05:14:15PM +0100, Frithjof Schulze wrote: > I can’t say much about other the rest of the code, but “This” is not an > argument, but a global variable managed by the system to have the current > object > as a value: Right. > > On 21. Dec 2022, at 16:51, polifemo wrote: > > What does this mean? Why is This being passed as an extra argument that is > > not > > in the method definition? When can you pass extra arguments and have it make > > sense? The syntax of message passing (i.e. method calls) in PicoLisp is (message> object arg1 arg2) Read as "message is sent to object". The object is not really passed as an *argument*, but is the target of the message sending, and is implicitly bound to the symbol 'This' while the method body runs. The method would be defined as (dm message> (Arg1 Arg2) ... ) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: the purpose of *KeyMap in vip
On Mon, Dec 19, 2022 at 05:39:18PM -0500, polifemo wrote: > I'm slowly studying the @lib/vip.l source, and I've run into a global > variable that appears to not be documented. > > What's the use of *KeyMap ? I guess it's something to do with custom > keyboard remappings? Correct. It allows (re)definitions of command-mode keys. This can be done with the ":map" command, e.g. :map @ :bd or with an entry in ~/.pil/viprc or ./.viprc, e.g. (map+ "@" ":bd\r") Both will delete the current buffer by typing "@". ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Knowable REPL
On Thu, Dec 08, 2022 at 10:40:49PM -0600, Galaxy Being wrote: > This issue came up in a talk or a Reddit group. Can't remember. So let's > say you have a REPL and you've loaded code into it. Let's say you want to > add code to the running REPL, but you'd like to "deactivate," take out some > of the previously loaded running code. It depends on what you mean with "deactivate". A 'load'ed code can do anything. It may create (i.e. "intern") new symbols, give them a value or definition, redefine other (already existing) symbols, or may even have side effects like deleting files. You can undo some of these things. New symbols may be 'zap'ped. Redefined symbols can have their original definition reloaded. To just get rid of new symbols, instead of 'zap'ping each of them, you can also put them all in a separate namespace and 'zap' only that. > Can you get a dump and actually see what's running somehow? What is meant by "running"? Currently executing? Then you might stop the running program with Ctrl-C and do a backtrace with (bt). Or just existing symbols? Then you can see them with (all) for the whole current namespace search order or only those from a given namespace with (all 'myNamespace). Does this help? Or can you elaborate a little more? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: org-mode with picolisp
On Wed, Nov 30, 2022 at 03:25:31PM -0600, Galaxy Being wrote: > The old picolisp file structure had ~/.../lib/edit.l and .../lib/el which > is no longer the case. That functionality went somewhere else? And yet both lib/edit.l was an in-memory editor for symbols in pil64, which called Vim internally. It is now obsolete, as this functionality is handled by Vip (the built-in Vi-style editor) in pil21. It is strange that lib/edit.l is loaded at all. Org-Mode should not care about it, and lib/edit.l is loaded at start-up by pil64, but never by pil21. lib/el/ is no longer part of the distro in pil21 to keep things small. It should probably better be made a separate tarball or repo. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: org-mode with picolisp
Hi Lawrence, > Having trouble with getting picolisp to work with org-mode Babel code > blocks. I'm guessing it's because I have an out of date ob-picolisp.el > which I had to scrounge on the Internet. (Got one latest 2021.) Sorry, yes. Org-Mode is not ported to Pil21 (yet). Let us investigate a little :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp Wiki: Embed Content?
Hi Thorsten, > I thought about security too. I even would like to have 2 embed options, > one only for iframes, the other for any html (produced by an external tool) This is indeed a potential security risk. A public Wiki can be edited by everyone and malicious HTML code might sneak in. As discussed yesterday, I commented the change in the release and on the public site. It is useful in environments where edit access is controlled, so it can be un-commented in such cases. Released. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp Wiki: Embed Content?
Hi Thorsten,
> it's actually extremely easy to embed content in a picolisp wiki file, when
> adding the syntax element from the PS 1 to wiki/lib.l :
> §{ }
> ...
> Would you consider to add something like this in wiki/lib.l ?
Yes, sounds like a good idea :)
> or better a check like this, then if the §{content} does not start with
>
> ("§" # > iframe
> (let Lnk (till "}" T)
> (if (= "(prin Lnk)
>(ht:Prin Lnk) ) ) )
Thanks!!
I simplified this a little to:
("§" # iframe
(let Lnk (till "}" T)
((if (pre? "mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pointer to a symbol: how to know it
Hi SJain, we just found your mail by chance in the archive. I did not receive it the normal way :( Anyway ... > I shall be grateful if someone could explain how to get the 'value' of a > pointer > to a symbol. It is said in the documentation that evaluation of, for example, > the function * returns its address or the pointer to it. Evaluation of a > symbol > however returns it's value. How to get the pointer to the symbol? This is just > curiosity as Ms Mia's blog says one can know what is stored where in memory. The function 'adr' gives you the low-level pointer to the symbol's cell: : (adr '*) -> 389215306216 So 389215306216 is the pointer to the symbol. 389215306216 | V +-+-+ | "*" | VAL | +-+-+ VAL in turn is a pointer here, pointing to the code for multiplication. : * -> 24325940465 To access the value from the raw pointer you can use 'struct': : (struct 389215306216 T) -> 24325940465 Does this help? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pastebin CLI
Hi Mike, > I have setup pastebin CLI based on code from: > https://git.envs.net/mpech/skudra > > http://pb1n.de > > Easy to use from command line or favorite editor. Great! So I changed Vip a little: I removed the hard-coded "ix.io" command, and put it into ~/.pil/viprc (and to @doc/viprc.sample in the distribution). Then added a "pb1n" command to both files. This makes selecting your favourite pastebin servce easier. Thanks! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: LISP with GC in 436 bytes
Hi Henry, > https://justine.lol/sectorlisp2/ > > LISP with GC in 436 bytes Great, yes, I think I saw it in HN. Very cool!! That's how it should be :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp Wiki: Embed Content?
Hi Thorsten, > is there a way to embed content in a PicoLisp Wiki file? > ... > But when sharing e.g. a youtube video, there is the "embed" option, that > gives this iframe: > https://www.youtube.com/embed/xEKHU4zCRpY"; title="YouTube video player" > ... > I could not figure out how to include this in a page with the PicoLisp Wiki > Syntax - probably it's not possible? I'm afraid so. I think there is no syntax for that in the markup language. Maybe Erik has an idea? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: bug: (hex) - decoding non-hex characters
On Fri, Jul 15, 2022 at 08:39:03AM +0200, Alexander Burger wrote: > yes, 'hex' does not verify the input (this was not intended). > > But you are right. For consistency with other conversion functions like > 'format' > or 'date' it should do so. I will fix. Done and released. > ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: bug: (hex) - decoding non-hex characters
Hi frostbyte, yes, 'hex' does not verify the input (this was not intended). But you are right. For consistency with other conversion functions like 'format' or 'date' it should do so. I will fix. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Small error in httpGate doc
Hi Thorsten, > First I thought it's some WSL2 peculiarity as usual, but I think it's just > outdated documentation: > ... > "Building httpGate > Next, go to the 'src' directory in the distribution and run make gate. When > ... > Looking into the makefile, it seems now there is a single "all" target, and > httpGate is built together with pil21? Right! Thanks! This is obsolete. I removed this section. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp-22.6
On Thu, Jul 07, 2022 at 07:44:47PM +0200, Alexander Burger wrote: > Hmm, seems I reported this a bit too early. > > It is still in unstable ... but will be in testing within the next few days. Yep. Now it is in testing :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp-22.6
On Thu, Jul 07, 2022 at 07:33:17PM +0200, pd wrote: > great! > > On Wed, Jul 6, 2022 at 8:30 AM Alexander Burger wrote: > > PicoLisp-22.6 was released, and is now available in Debian Testing. Hmm, seems I reported this a bit too early. It is still in unstable ... but will be in testing within the next few days. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
PicoLisp-22.6
Hi all, PicoLisp-22.6 was released, and is now available in Debian Testing. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
