Subscribe
Re: Pil vs Pil21 performances
Ok, I managed to turn on the optimization (opt -O3) and the results improved *** recursive -- picolisp 3.007 sec -- pil21 4.249 sec *** iterative -- picolisp 0.515 sec -- pil21 0.368 sec Apparently with the optimization cache does not segfault... Cheers, Davide On Fri, Sep 4, 2020, 22:50 Davide BERTOLOTTO wrote: > Hi all, > > I compiled pil21 with llvm on termux and then I ran some simple fibonacci > benchmark. Here the results > > *** recursive > n 37 fib 24157817 > -- picolisp 3.013 sec > -- pil21 5.332 sec > -- python 21.247 sec > > *** iterative > n 8 fib 4589178984+ > -- picolisp 0.518 sec > -- pil21 0.409 sec > -- python 0.124 sec > > I got also a segmentation fault while trying to use cache to speed up the > calculation with pil21 (don't know if Alex is aware of that) > > From the results it seems that performance of llvm are slightly better for > iterative solutions and fairly worse for recursive solutions > > Question: I used the makefile in the pil21.tgz to compile pil21. Is there > any optimization in? I didn't dig (yet) into llvm compiler flags :) > > Regards, > Davide >
Pil vs Pil21 performances
Hi all, I compiled pil21 with llvm on termux and then I ran some simple fibonacci benchmark. Here the results *** recursive n 37 fib 24157817 -- picolisp 3.013 sec -- pil21 5.332 sec -- python 21.247 sec *** iterative n 8 fib 4589178984+ -- picolisp 0.518 sec -- pil21 0.409 sec -- python 0.124 sec I got also a segmentation fault while trying to use cache to speed up the calculation with pil21 (don't know if Alex is aware of that) >From the results it seems that performance of llvm are slightly better for iterative solutions and fairly worse for recursive solutions Question: I used the makefile in the pil21.tgz to compile pil21. Is there any optimization in? I didn't dig (yet) into llvm compiler flags :) Regards, Davide
Re: httpGate for non-picolisp apps
I suppose so, you can start it from the command line and have it listen to a port. I am not sure that it will work with the configuration file tough, since I understood that it takes care of stopping and starting the picolisp processes. Someone more expert can confirm or deny that ;-) D. On Thu, Aug 27, 2020, 22:10 Grant Shangreaux wrote: > Can httpGate be used as a reverse proxy for other web applications that > don't happen to be PicoLisp? I like how simple it is compared to the other > servers I've tried to configure. > > Thanks! > Grant > > >
Re: Issue with pipe and file descriptors
Thanks a lot Alex, with the "wait" is working fine! Cheers, Davide On Tue, Aug 4, 2020, 16:42 Alexander Burger wrote: > Hi Davide, > > > I have encountered a strange behavior while running some pipes (the > number > > of "do" iterations may require some adjustment to trigger the effect): > > (do 1 (pipe (prin "A string") (make (while (rd 1) (link @) > > > > The execution stops with an error like this (the actual number may vary) > > ? 1345 FD too high > > > > In Termux this happened with something as low as 300. Note also that in > > Termux I have a pretty high number of files that can be open at the same > > time (~65K). > > > > I would expect that the file descriptors are closed after the pipe > > execution. > > This is correct, but it takes a while. After the pipe'd child process > terminated, the Linux kernel sends a SIGCHLD signal to the parent process, > which > then does a waitpid() system call in the signal handler. > > So it is necessary not to create too many child processes at the same > time. The > above should work if you add a short delay, e.g. > >(do 1 > (pipe (prin "A string") > (make (while (rd 1) (link @))) ) > (wait 10) ) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Issue with pipe and file descriptors
Hi all, I have encountered a strange behavior while running some pipes (the number of "do" iterations may require some adjustment to trigger the effect): (do 1 (pipe (prin "A string") (make (while (rd 1) (link @) The execution stops with an error like this (the actual number may vary) ? 1345 FD too high In Termux this happened with something as low as 300. Note also that in Termux I have a pretty high number of files that can be open at the same time (~65K). I would expect that the file descriptors are closed after the pipe execution. I tested it and it seems that if one prints the (fd) at every loop it is always the same number. Why is this happening? It looks like the actual FD number in the underlying system is too big... Regards, Davide
Re: Fridays for Functions (Was: PilCon 2020)
Wonderful idea On Wed, Jun 3, 2020, 13:27 O.Hamann wrote: > ++ > > On 03.06.20 07:54, Alexander Burger wrote: > > I would propose informal Jitsi meetings every second Friday or so. The > time > > could be alternating 8:00 and 16:00 UTC, to allow attendance from most > time > > zones. No big planning and schedule. Let's start with questions, > tutorials and > > demonstrations. > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Land of Lisp
Hi all, For those familiar with Land of Lisp (http://landoflisp.com/), I have rewritten the wizard's game in Picolisp here: https://github.com/dbertolotto/pil-land-of-lisp In my opinion the wizard's game is the most iconic (and educational) game of the book: it shows the code-as-data, the macros and how to create a custom REPL. If you want to follow the game creation and you don't have the book you can do it here: http://www.lisperati.com/casting.html It is worth to read it to better understand how lisp works in general. If I find the time I'll try to convert more games in the future. Cheers, Davide
issue with circular lists
Hi everyone, I had recently an issue with both pil64 and pil21. I was trying to create a large circular list and got a segmentation fault with a size of >200'000 elements. Is that expected? (apply circ (range 1 20)) Regards, Davide
Re: issue with circular lists
Just found out that it is an issue with apply. Probably the number of arguments is too large. (eval (cons 'circ (range 1 20))) Works fine. Could someone confirm please? Regards Davide On Wed, Dec 23, 2020, 13:16 Davide BERTOLOTTO wrote: > Hi everyone, > > I had recently an issue with both pil64 and pil21. I was trying to create > a large circular list and got a segmentation fault with a size of >200'000 > elements. Is that expected? > > (apply circ (range 1 20)) > > Regards, > Davide >
Re: issue with circular lists
Thanks for the clarification Alex! The ulimit command did the trick. Cheers, Davide On Wed, Dec 23, 2020, 14:16 Alexander Burger wrote: > On Wed, Dec 23, 2020 at 01:57:10PM +0100, Alexander Burger wrote: > > The result is a little different though: > > > >: (let L NIL (for I 7 (fifo 'L I)) L) > >-> (7 1 2 3 4 5 6 .) > > .. but of course the fix is trivial :) > >: (cdr (let L NIL (for I 7 (fifo 'L I)) L)) >-> (1 2 3 4 5 6 7 .) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Advent of Code 2020
Hi all, For anyone who is interested, I am participating to the advent of code 2020 (https://adventofcode.com/) using Picolisp. Here is the repository https://github.com/dbertolotto/advent-of-code-2020 Cheers, Davide
Re: Advent of Code 2020
I am using the one from the package manager of ubuntu 18, so it's probably pil 64. I am waiting for the new package on thermux ;) On Wed, Dec 16, 2020, 17:36 Mike wrote: > December 16, 2020 6:09 PM, "Davide BERTOLOTTO" < > davide.bertolo...@gmail.com> wrote: > > > Hi all, > > > > For anyone who is interested, I am participating to the advent of code > 2020 > > (https://adventofcode.com/) using Picolisp. > > > > Here is the repository > https://github.com/dbertolotto/advent-of-code-2020 > > > > Thanks for sharing, congratulations. > BTW, did you use pil64 or pil21? > You definitely could switch to newer pil21 for testing and fun. > > (mike) > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe > >
Re: Advent of Code 2020
Thanks Alex, I did manage to compile pil21 some time ago on termux, but it was not the latest version. Waiting for the package is for satisfying my laziness by having automatic updates ;) Sad to hear about termux, I hope that there will be a solution for that. It is a great tool! Cheers, Davide On Thu, Dec 17, 2020, 08:30 Alexander Burger wrote: > Hi Davide, > > > I am using the one from the package manager of ubuntu 18, so it's > probably > > pil 64. > > Right. > > > > I am waiting for the new package on thermux ;) > > Me too! However, I'm not sure about the state. > > I wrote to Fredrik (the developer of Termux) in November and again in > December, > asking him to package pil21. Usually he always immediately replied, but > this > time I did not get any answer. > > In general, the future of Termux is uncertain. The requirement from Google > for > Android-10 make it virtually impossible. It looks like Termux will stay on > Android-9 (API 28) as long as possible. > > > Getting pil21 on Termux is easy though. I developed it completely on > Termux, so > it builds without problem. Just do > >apt install make clang llvm readline libffi openssl pkg-config >tar xfz pil21.tgz >cd pil21 >(cd src; make) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: PilCon Friday
Saturdays with the usual schedule sounds good for me On Sat, Nov 7, 2020, 09:49 Alexander Burger wrote: > Hi Kashyap, Wilhelm, > > thanks a lot Wilhelm! I think you protocolled all topics. > > And no worries Kashyap, we were all aware that we will repeat some topics > anyway, whatever comes up. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: Flame wars
Great! :) On Sun, Nov 22, 2020, 15:17 Alexander Burger wrote: > On Sun, Nov 22, 2020 at 02:49:58PM +0100, Davide BERTOLOTTO wrote: > > Well, outside of the "flame wars", I think that this it is a genuine > > problem that has to be solved by Alex. > > Yes, OK, and it *is* solved. > > > > * use readline and make pil21 GPL > > * Make readline optional ... > > * Ditch readline completely ... > > None of them. > > 1. PicoLisp is MIT/X11, so anybody can change to GPL if she does not like > it. >But *I* will not limit freedom. > > 2. It is not a problem anyway. I follow the link in Wikiqedia > > https://www.linuxjournal.com/article/6366 > >the opinion of Lawrence Rosen (a one-time Open Source Initiative general >counsel). PicoLisp is not derivative work and linking is mostly > irrelevant. > > End of discussion. > > ☺/ A!ex > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Licence Dilemma
>From the wiki page they you shared, quoting the FSF Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. This means that 'call' is not a problem Since native doesd dynamic linking (does it?), in principle it may be a problem. Legally this is always in the hands of the judge. In my view I don't believe that someone will sue Picolisp for using readline like Alex is doing, but there is always a possibility. What about any of the mentioned replacements? Is there any viable one? On Sun, Nov 22, 2020, 11:31 Alexander Burger wrote: > On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote: > > In my understanding it is irrelevant how the library is linked, or the > fact that > > pil21 "depends" on it > > This is all such a mess! What is "linking" other than calling external > code at > runtime? > > In pil you can call any other library at any time with 'native'. At that > moment > the library gets linked. How should we prevent that? > > Or calling a GPLed program with (call "program" "arg" ...). This is > functionally > also equivalen to linking, as it "uses" the code in another program. > > If 'native' does not violate the GPL, then pil21 could be rewritten to use > 'native' to call the readline API. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Licence Dilemma
According to the GPL FAQ *technically* a dynamically linked object still falls under GPL https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic However it seems that not everyone agrees on that fundamentalist view: https://www.linuxjournal.com/article/6366 As far as I know, there has not been any court ruling on such issues, so we are a bit in the gray zone here. In my personal opinion it will be okay if we use the readline library in pil21, since it is a *library* and we are not making a 'derivative' work out of it Regards, Davide On Sun, Nov 22, 2020, 09:30 Alexander Burger wrote: > Hi Tomas, > > > even though pil21 is MIT licensed, the GPL dependency makes the combined > > work GPL licensed > > > > if i understand the raised issue correctly, alex wants the combined work > > to be MIT licensed, which means pil21 cannot depend on GPL software > > On Sun, Nov 22, 2020 at 09:08:32AM +0100, Tomas Hlavaty wrote: > > the question is: does pil21 depend on GPL software? if yes, the > > combined work has GPL licence. if not, pil21 has MIT licence. if you > > Yes, I want pil21 as a piece be completely "free", in the spirit of MIT. > > But you focus on the term "depend" / "dependency". > > >From what I underseod so far, the GPL is all about "distributing". > PicoLisp does > *not* distribute any GPLed code (neither source nor binary), but "uses" > what it > finds on the target system at runtime and just *calls* it by creating a > dynamic > link. Am I wrong? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: Flame wars
Well, outside of the "flame wars", I think that this it is a genuine problem that has to be solved by Alex. Using readline for pil21 in the current form requires him to use GPL for Picolisp. I know it's nasty and almost nobody likes that, but it is the way the GPL license works, at least on paper. If anyone will complain in the future about him not doing that has to be seen, but legally he's on the weak side. Let's close this topic by putting the possible options on the table - Alex will have to take a decision: * use readline and make pil21 GPL * Make readline optional (i.e. that can be activated via config), maybe with a thin pil interface calling readline via native. The interface file will be GPL, but pil can be released with MIT license and the reworked led.l * Ditch readline completely and use an alternative with a more permissive license Any other suggestion is welcome. :) Regards, Davide On Sun, Nov 22, 2020, 14:25 Alexander Burger wrote: > On Sun, Nov 22, 2020 at 07:36:57AM -0500, r cs wrote: > > Have you been putting up with flame wars this often in the past, or is it > > worse during COVID-19? > > No flame war please! :) > > The question came up at PilCon, so I asked here. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: PilCon Friday
For me later in the evening after 17-18 CET would be Better. On Thu, Nov 5, 2020, 19:41 Alexander Burger wrote: > On Thu, Nov 05, 2020 at 01:23:13PM -0500, r cs wrote: > > Raw video would be welcomed. The timing of the PilCon can be challenging > > in some time zones. > > Independent of the recording issue, the current scheduling is not an > absolute > must. I did a proposal initially, and nobody complained, so we stayed with > it. > > Should we consider a change for the future? Perhaps Saturday would be > better > than Friday? And/or some other UTC time(s)? Should we try some democratic > decision process? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: PilCon Friday
I am not sure if I'll be able to join, but would be good to hear about best practices in error handling (how to catch and throw errors properly) Regards, Davide On Wed, Nov 4, 2020, 12:03 Alexander Burger wrote: > Hi all, > > next Friday (Nov 6th) is PilCon again! > >https://meeting.itship.ch/PilCon > > As it is the first Friday of the month, we'll meet at 8:00 UTC. > > Perhaps we should talk about more basic issues this time? > Any newcomer's questions should be welcome. > > ☺/ A!ex > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: PilCon Saturday
I should be able to join. On Thu, Dec 31, 2020, 09:00 Alexander Burger wrote: > On Thu, Dec 31, 2020 at 08:36:48AM +0100, Alexander Burger wrote: > > in two days, Saturday the second of January, we have the next PilCon. > > Sorry, forgot to refresh the details: > > As ever on a first Saturday, 8:00 UTC at https://meeting.itship.ch/PilCon > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: PilCon Schedule
Oooops... I forgot to join this Saturday :-P Anyway, in general any day is fine for me, even if I may not be able to attend every time. What about making shorter seminars with a specific topic? It seems that this is the favored way by many people and could be recorded for the benefit of everyone. These could be tutorial for beginners, showing small projects, community libraries, etc. I would also keep some free Q sessions for shorter topics and general questions (like we have done till now) Regards, Davide On Mon, Jan 18, 2021, 08:35 Alexander Burger wrote: > Hi all, > > before and after the PilCon last Saturday the discussion about its > schedule came > up again. > > Currently we meet at the first and third Saturday each month, at 8:00 UTC > on the > first, and 16:00 UTC on the third. > > Before, we used the first and third Friday. > > It seems that Saturdays are not optimal. Many people have other duties. In > general, it is not possible to find a certain weekday where everybody can > attend. > > > So what if we discard the principle of weekdays, in favor of fixed *days*? > > I would propose the 10th and 20th of each month. > > This is easy to memorize, and will fall on all weekdays over time. The 10th > would be at 8:00 UTC, and the 20th at 16:00 UTC. > > For me this would be all right, as I'm working from home office. > > What do you think? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Question for understanding usage of pipes
In a more functional way:
(de proc-char (C)
(case C
("B" 1)
("R" 1)
("F" 0)
("L" 0)))
(de proc-str (S)
(pack (mapcar 'proc-char S)))
(de proc-file (F)
(let Inp (filter 'and (split (in F (till)) "\n"))
(mapcar 'proc-str Inp)))
(println (proc-file "5.input"))
If you need some help with the exercises:
https://github.com/dbertolotto/advent-of-code-2020
Regards,
Davide
On Fri, Jan 15, 2021, 19:29 Mike wrote:
> January 15, 2021 7:21 PM, "Christos Gitsis" wrote:
>
>
> >
> > Is there a way to do this and get the result:
> > -> ("0001110111" "1000110111" "1100110100")
> > ?
>
> https://envs.sh/BF.l
>
> This is my code how i *feel* this task.
>
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>
>
Re: Picolisp Outlook
After all these years I am still wondering how people like complicated sintaxes full of special forms more than the simplicity of lisp. After all, the parentheses and the prefix notation do not look so terrible to me, especially considering that you gain a lot in clarity and simplicity of the language. Probably is the same reason that pushes people to create yet another programming language every now and then xD. On Tue, Feb 23, 2021, 21:03 pd wrote: > > > On Tue, Feb 23, 2021 at 5:00 PM Danilo Kordic > wrote: > >> 'float' could be implemented as a lib. >> > > yes, but the point here it is not at core and even having a float lib or > whatever science lib, python is plenty of them and a nicer syntax > > it's not about me neither talking about (pico)lisp features and better > syntax, I'm yet convinced 'cause I'm a schemer thus a lisper and I'm here > in that list after all > But most people don't think so and no matter how better and nicer I find > the lisp syntax, the world thinks the opposite ;-) > > maybe you can find a killer app or even a killer science app leting > picolisp shine but as soon as people has to program in picolisp (I mean > scripting) they will feel uncofortable, they will always prefer R or > python, just for syntax, not talking about huge amount of libraries and > community support, developers should enjoy (pico)lisp facilities to > develop and organice knowledge but as soon as had practical issue the lack > of specialized libraries will make them comply thinking in wide spread > python or ruby (just talking dynamic 'script' languages only)... > > It's not a problem of picolisp only, it's common to all lisp dialects and > even cool minor languages... This is the reason for using lua for scripting > rather than picolisp, guile or even tcl > Also this is the problem for all lisp about their use in real apps, I see > this in common lisp, in scheme, ... The only lisp-like with hype and > relative wide use is clojure and one key reason is libraries (achieved by > jvm side) > > And this is how it's gonna be... we live in the dictatorship of C-like > syntax world! ;-) > > (damnification is not only in lisp world, same happen to smalltalk and > derivatives, forth-like derivatives and so on) > >
Re: Is there a mechanism to save the last defined function?
Sorry for the weird formatting: (de de+ Rest (let ((@Name @Args Doc . @Body) Rest) (macro (de @Name @Args ~'@Body)) (put @Name 'Doc Doc) @Name)) # there was a typo in my previous post Then you can do: (de+ f (A) "docstring" A) Otherwise just after the function declaration you can do (put 'f 'docstr "docstring") On Tue, Apr 20, 2021, 07:30 Davide BERTOLOTTO wrote: > I don't know of any *Function global, but hey, it's lisp ;) you can do > your own 'de' like this, with a docstring clojure-style (after args) > > (de de+ Rest > (let ((@Name @Args Doc . @Body) Rest) (macro (de @Name > @Args ~'@Body)) (put @Name 'Doc Doc) > Name)) > > Maybe Alex has something more to add > > Regards, > Davide > > On Tue, Apr 20, 2021, 04:45 polifemo wrote: > >> Inspired by the way methods are defined, by just defining them and >> looking which class a method belongs to by looking into the global variable >> *Class, I'd like to have a similar mechanism for creating docstrings. >> >> My idea is something like this: >> ``` >> (de f (A) A) >> (mkdocstr "A test function that returns its argument evaluated") >> ``` >> >> where mkdocstr is defined like this: >> ``` >> (de mkdocstr (Docstr) >>(put *Function 'docstr Docstr) ) >> ``` >> >> This, of course, requires some global variable *Function that saves the >> last symbol defined by 'de. Is there such a variable? Or is there a way to >> change 'de to write to that variable? >> >
Re: Is there a mechanism to save the last defined function?
I don't know of any *Function global, but hey, it's lisp ;) you can do your own 'de' like this, with a docstring clojure-style (after args) (de de+ Rest (let ((@Name @Args Doc . @Body) Rest) (macro (de @Name @Args ~'@Body)) (put @Name 'Doc Doc) Name)) Maybe Alex has something more to add Regards, Davide On Tue, Apr 20, 2021, 04:45 polifemo wrote: > Inspired by the way methods are defined, by just defining them and looking > which class a method belongs to by looking into the global variable *Class, > I'd like to have a similar mechanism for creating docstrings. > > My idea is something like this: > ``` > (de f (A) A) > (mkdocstr "A test function that returns its argument evaluated") > ``` > > where mkdocstr is defined like this: > ``` > (de mkdocstr (Docstr) >(put *Function 'docstr Docstr) ) > ``` > > This, of course, requires some global variable *Function that saves the > last symbol defined by 'de. Is there such a variable? Or is there a way to > change 'de to write to that variable? >
Re: [PicoLisp] [PiL] im Betreff verwenden
As others already said, it's enough to tag/sort/redirect the incoming mails according to the sender, no need for keywords in the title :) On Wed, Dec 29, 2021, 19:25 Karl-Heinz Kreis wrote: > > Hi all, > > I let my Mailprog simply sort the incomming into previously created > subfolders by the values in the Mail Header... > > Happy New Year, Karl-Heinz >
Advent of code 2021
It is again that time of the year :) https://adventofcode.com/2021 https://github.com/dbertolotto/advent-of-code-2021 Cheers, Davide
