Andrew [last name withheld] wrote:
>
> Using Allegro CL 6.2/linux
> cffi-060130
> python 2.2 [*]
>
> I get the following failure:
>
> (PYTHONLISP::GET-WEB-PAGE "http://www.common-lisp.net/")
> Error: NIL is not a Lisp string or pointer.
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart).
> 1: Abort entirely from this process.
> [1] CL-USER(26): :bt
> Evaluation stack:
>
> (METHOD CFFI:TRANSLATE-TO-FOREIGN (T #)) <-
> (METHOD CFFI::TRANSLATE-TYPE-TO-FOREIGN (T CFFI::FOREIGN-TYPEDEF)) <-
> PYTHONLISP::PYTHONLISP <-
> PYTHONLISP::GET-WEB-PAGE <- [... EXCL::%EVAL ] <- EVAL <-
> TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <-
> TPL:START-INTERACTIVE-TOP-LEVEL
>
> [1] CL-USER(27):
>
> [*] I didn't have a reasonable preinstalled libpython.so, so I made
> one using
>
> mkdir /tmp/libpython; cd /tmp/libpython
> ar x /usr/lib/python2.2/config/libpython2.2.a
> sudo ld -shared -export-dynamic *.o -ldl -lpthread -lutil -lm -lc -o
> /usr/lib/libpython2.2.so
>
> which might not have been a good idea. The .so does load into lisp
> fine, but that doesn't necessarily mean anything.
>
> Andrew
[Forwarding to Lisp Gardener's list because other people may have the
same problem]
Hi,
I've fixed it. It was passing a NIL, which is a valid NULL pointer on
Clisp, but not on Lispworks or Allegro. I know because I got the same
error (even though I'm using Windows). I fixed it by using CFFI's
explicit null-pointer function.
Also, I didn't realise that Python's output to stdout wouldn't show anything
on non-console Lisps, such as Lispworks or Allegro. So now the printing out
of Python stdout, to the Lisp REPL, is default, for people without stdout. I
expect anyone who used it must have been bemused by the fact that nothing was
ever printed out, assuming anyone even got that far considering the NULL
pointer issue! ;-)
I've also (just now) made a 'CONSOLE or 'STRING argument to determine where
Python STDOUT ends up. 'STRING goes to both (for now), while NIL means
neither.
I've tried running web.py (Aaron Swartz's web framework on top of a Python
webserver) in CLisp (from the DOS console) and had noproblems whatsoever - it
would serve up webpages and even do callbacks, so you could define a Lisp
callback function (or LispEval string) as a 'GET' method in a webpage class.
Not bad when I've never got a webserver running in CLisp before.
Unfortunately, web.py turns Lispworks 4.4 and Allegro 7.0 into a mess.
Lispworks eventually bombs out with some huge stack trace, while Allegro
just kind of erases the menu bar and refuses to do anything. I haven't tested
it with the newer improvements yet, but I will do soon.
Thanks for the feedback Andrew - It's early days yet so I'll make sure
all these little issues are ironed out.
Also thanks to Marc for his comments. I've taken care of those issues, I hope!
Oh, and finally, I might continue this discussion on the mailing list for
Python-on-lisp so as not to clog up CL Gardeners. Then again, the volume will
be pretty low.
I've uploaded a new version to
http://common-lisp.net/project/python-on-lisp/pol.lisp
And enabled the link on the webpage for everyone to try it out.
There's a list (in the above file) of a few major changes I've made.
Thanks for everyone's support and encouragements and help setting this
up! I hope people find this library useful.
Cheers,
Jeremy.
--
| Jeremy Smith BSc (Hons)
| Chief Scientist, Decompiler Technologies
| Member, British Computer Society
| England
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners