Recent Forum Posts
From categories:
page 1 of 212next »
Re: Simple loop
Marcosu (guest) 16 Jun 2010 08:06
in discussion Forum / Development & bugs » Simple loop

Thanks Alex,

I use version 3.0.1 and this explain all.

I'll upgrade asap.

- Marco

Re: Simple loop by Marcosu (guest), 16 Jun 2010 08:06

Hi Marcosu,

do you perhaps have a rather old version of picoLisp? This short-cut syntax of 'for' is available only since picoLisp-3.0.2 (last March).

For older versions, you need either write

(do 5 (prinl "foo"))


(for (N 1 (>= 5 N) (inc N)) (prinl "foo"))

- Alex

Re: Simple loop by Alexander BurgerAlexander Burger, 15 Jun 2010 15:29
Simple loop
Marcosu (guest) 15 Jun 2010 13:59
in discussion Forum / Development & bugs » Simple loop

(for N 5 (prinl "foo"))

why doesn't print 5 times "foo"?

Simple loop by Marcosu (guest), 15 Jun 2010 13:59

Well, performance was deliberately not a design goal, as we took simplicity and flexibility more important than raw speed.

Still, PicoLisp compares relatively well. It is, for example, at least 3 to 6 times faster than Python, and also to compiled Lisps there is not a really significant difference.

You might want to take a look at an article in "": Go to "Articles & Essays", and click on "Need For Speed".

I am impressed at seeing problems/inconveniences fixed so fast.
Thanks a lot, Alexander.

I am still just poking around with picolisp, exploring what it is and how i can make use of it.

I am mainly interested in finding technology that is easy to use in non-critical applications. I am lazy, and that is why I have found the Lisp family of languages suitable … quickly get something up and running, and gradually turn an early hack into someting useful.

But I am curious… are there any picolisp performance benchmark data? If I understand it correctly, runtime performance was one of the design goals. So how well does it succeed there?

OK, as discussed in IRC and the mailing list, we have now a patch for (what appears to be a bug in) Cygwin.

A new "picoLisp.tgz" is available for download.

Many thanks!

However, this looks all OK

The varning: argument 'x' might be clobbered by ‘longjmp’ or ‘vfork’ is due to a somewhat stupid C compiler.

The other warnings mainly result from 'fcntl' being defined to "empty" in the beginning of "src/io.c" for CYGWIN. The reason is that (at least a few years ago) fcntl() simply didn't work under Cygwin.

Just for fun I recreated the installation in a fresh place.
Maybe there is something to be seen from the generated messages. See below.

Seen in the shell

bash-3.2$ (cd src; make picolisp > /home/olleo/tmp/picol.log )
flow.c: In function ‘doCatch’:
flow.c:1344: varning: argument 'x' might be clobbered by ‘longjmp’ or ‘vfork’
io.c:2623: varning: unused parameter 'cmd'
io.c:2623: varning: unused parameter 'f'
io.c:34: varning: unused parameter 'fd'
io.c:34: varning: unused parameter 'cmd'
io.c:51: varning: unused parameter 'fd'
io.c:46: varning: unused parameter 'fd'
io.c: In function ‘nonblocking’:
io.c:54: varning: statement with no effect
io.c: In function ‘slow’:
io.c:123: varning: statement with no effect
io.c: In function ‘rdBytes’:
io.c:143: varning: statement with no effect
io.c: In function ‘doEcho’:
io.c:2090: varning: 'op' might be used uninitialized in this function
net.c: In function ‘doHost’:
net.c:117: varning: passing arg 1 of ‘mkStr’ discards qualifiers from pointer target type

Seen in /home/olleo/tmp/picol.log

gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' main.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' gc.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' apply.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' flow.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' sym.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' subr.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' big.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' io.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' net.c
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' tab.c
gcc -o ../bin/picolisp.dll -shared main.o gc.o apply.o flow.o sym.o subr.o big.o io.o net.o tab.o
strip ../bin/picolisp.dll
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' start.c
mkdir -p ../bin ../lib
gcc -o ../bin/picolisp.exe start.o -L../bin -l../bin/picolisp
strip ../bin/picolisp.exe
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' ext.c
gcc -o ../lib/ext.dll -shared ext.o ../bin/picolisp.dll
strip ../lib/ext.dll
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' ht.c
gcc -o ../lib/ht.dll -shared ht.o ../bin/picolisp.dll
strip ../lib/ht.dll
gcc -c -O2 -m32 -pipe -falign-functions -fomit-frame-pointer -fno-strict-aliasing -W -Wimplicit -Wreturn-type -Wunused -Wformat -Wuninitialized -Wstrict-prototypes -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_OS='"Cygwin"' z3d.c
gcc -o ../lib/z3d.dll -shared z3d.o ../bin/picolisp.dll
strip ../lib/z3d.dll

OK, the DLL's are there. The problem seems not to be in the build process.

Then it must be the runtime dlopen() and/or dlsym() processing. Would be interesting to know _when_ this broke (I never used Cygwin). The code in "src/main.l" didn't change for quite some time.

Or did something in Cygwin change? No idea.

As the same problem also came up in the mailing list, I hope we'll get some feedback there from a cygwin user perhaps.

The following is what I have got:

bash-3.2$ ls -ltr lib/*.dll
-rwxr-xr-x 1 olleo Ingen 10752 15 apr 15.58 lib/ext.dll
-rwxr-xr-x 1 olleo Ingen 12288 15 apr 15.58 lib/ht.dll
-rwxr-xr-x 1 olleo Ingen 16896 15 apr 15.58 lib/z3d.dll

So there is an ht.dll.

Yes, too bad. Looks like we have a build problem on Cygwin.

There should be DLL been built: lib/ht

Does this exist?

Running on cygwin 1.7.5

bash-3.2$ ./dbg lib/http.l -traceAll -'server 8080 "doc/hello.l"' -wait
server : 8080 doc/hello.l
task : 4 ((http @))
task = (4 (http @))
http : 4
_htHead :
_htHead = NIL
!? (ht:Pack @U)
ht:Pack — Undefined

So I get a show-stopper ;-(

Any advice?

The problem is not so much the build, as the functionality. PicoLisp depends totally on POSIX system calls, as the event handling is done via select() or poll(), interprocess-communication is handled via fork() and pipes, and the REPL depends on terminal handling (process groups, controlling terminal etc.).

What might be possible, though, is to compile "miniPicoLisp" on a Microsoft system. It is however very limited, as most of the "interesting" functionality (socket I/O, database, IPC and so on) is stripped. Also, it has only short integers, no UTF-8 support or console handling.

I would like to build picolisp with mingwin32 or microsoft compiler. Cygwin is nice but too slow !

Hi all,

If you are interested in an IDE other than emacs for PicoLisp, please check out Lisp IDE at It has a picolisp setting and you can attach a picolisp executable to the IDE and you are off and running. Niek (creator of Lisp IDE) just released the picolisp mode and I have not used it extensively yet but it looks promising.

- Naghi

Lisp IDE for PicoLisp by NaghiNaghi, 22 Feb 2010 07:39

Hi Nikolaus,

well, there are ways, though they differ between the 32- and 64-bit versions.

As far as the 32-bit version is concerned (as in your case), you need
to write a glue function to call non-PicoLisp libraries. You can do that
either as a normal, separate shared object (.so), or with inline-C.
Examples for libraries are 'ext', 'ht' or 'z3d' in the PicoLisp release.
Examples for inline-C (via "lib/gcc.l") you can find in "lib/readline.l",
"rcsim/tone", "misc/fibo.l" or "misc/crc.l".

Is this what you were looking for?

Re: PicoLisp on AVR32 by Alexander BurgerAlexander Burger, 15 Feb 2010 08:07
PicoLisp on AVR32
Nikolaus Klepp (guest) 14 Feb 2010 20:05
in discussion Forum / Development & bugs » PicoLisp on AVR32

PicoLisp 3.0.1 compiles & runs fine in minimal buildroot environments. I've it running on AVR32 Grasshopper (AVR32AP7000 CPU) - nice :-) I would just like a portable way to all C libraries.

PicoLisp on AVR32 by Nikolaus Klepp (guest), 14 Feb 2010 20:05

one of the best research papers site, try to check it out :)

research papers by ReyVaughnReyVaughn, 14 Jan 2010 15:35

Yes, as I thought. The crash seems to occur just the moment the
first function from a dynamic library (here 'ht') is called.

So I think it should work if you download the latest release
(see the "Download" section) and re-compile.

You are using 32-bit Cygwin, right? Is there any 64-bit version?
If so, we might need to insert the -m32 flag there, too.

Not sure how to capture the screen output in Cygwin, so have it 'by hand'

./dbg lib/http.l -traceAll -'server 8080 "doc/hello.l"' -wait

server : 8080 "doc/hello.l" APPEARS ON ENTERING ABOVE

Following appears as soon as browser tries to connect

task : 4 ((http @))
task = (4 (http @))
http : 4
_htHead :
_htHead = NIL
script : "doc/hello.l"
allow : *Menu NIL
allow = *Menu
allow : *Tab NIL
allow = *Tab
allow : *ID NIL
allow = *ID
httpHead : NIL 0 NIL NIL
http1 : NIL 0 NIL NIL
httpDate : 734049 59193
day : 734049 (Mon Tue Wed Thu Fri Sat Sun . )
day = Wed
pad : 2 2
pad = "02"
tim$ : 59193 T
pad 2 16
pad = "16"
pad : 2 26
pad = "26"
pad : 2 33
pad = "33"
tim$ = "16:26:33"
httpDate = " GMT^M"
http1 = NIL
httpCookies :
httpCookies = NIL
httpHead = "^M"
baseHRef : NIL
baseHRef = "http://localhost:8080"
2648 SIG-11

Quite repeatable, and happens in IE (6) and Chrome browsers

Re: Newbie: cannot use GUI by techdir0techdir0, 02 Dec 2009 16:46
page 1 of 212next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License