Jason,
Can you do svn update and try again? I think I've fixed this problem, but I'd like you to test it.
Thanks.
Liam
On 3/1/08, Jason Nielsen jdn@math.carleton.ca wrote:
Done. Ticket #3.
Thanks,
Jason
On Sat, 1 Mar 2008, Liam Healy wrote:
Jason,
Thanks for the report.
I'm not sure what is causing this problem; I think you are doing everything you are supposed to. I have to admit I haven't done a save-lisp-and-die with a GSLL image. I know that the SBCL developers have discussed issues related to save-lisp-and-die in the past; it could perhaps be some SBCL state that is not being saved in the image, either intentionally or accidentally.
If it's not too much trouble, can you file a bug report on the Trac page http://trac.common-lisp.net/gsll/ -> New Ticket I will ask the sbcl developers if I don't come up with any other ideas.
Liam
On 3/1/08, Jason Nielsen jdn@math.carleton.ca wrote:
First of all, thank you for making these bindings available. They are great! Much better that the bare-bones cffi wrappers I've been using for the small subset of gsl I've needed.
I think there is a small bug with exceptions in the code. I usually make my own image with code that I use regularly (sbcl 1.0.14), i.e.
(require 'asdf) (require 'asdf-install) (require 'cffi) (require 'gsll)
(sb-ext:save-lisp-and-die "sbcl-with-slime.core")
then start up sbcl with "sbcl --core sbcl-with-slime.core". In this mode of operation gsll hangs when an exception is caught, e.g.
(jacobian-elliptic-functions 0.61802d0 1.5d0)
just sits and the repl prompt is not returned (endless loop or something).
If I just fire up sbcl and load gsll normal everything works fine and I get the expected warning that |m|>1.
Hope this is a useful enough description of the problem for you to track it down.
With kind regards, Jason _______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel