Hi Jeremy,

I incorporated your edits and some more documentation. It is all in the tarball I have attached. Please treat it as the current version.

Here's the current state of things:

-- pythononlisp does NOT asdf-install on SBCL 0.9.11, OSX/intel

I suspect this has nothing to do with pythononlisp, and everything to do with the immaturity of SBCL and cffi on OSX/intel, so this should be ignored.

-- pythononlisp does not asdf-install on cmucl Debian.

I think this is just a small matter of getting the right define-foreign-library form for Linux. One of the cffi guys should be able to solve this very quickly, so I am ignoring it.

-- pythononlisp DOES asdf-install without errors on SBCL 0.97, OSX/ppc

It installs but it still doesn't work. When you try to run (py::py "print \""Hello world\""), you get a stacktrace with the following message:

The value "Hello world" is not of type SYSTEM-AREA-POINTER. [Condition of type TYPE-ERROR].

The good news is, this means the Python print statement is in fact being processed correctly. This is further than I have gotten so far. The bad news is that it's output is not being returned out correctly. The error suggests to me that somewhere within the function PYTHONLISP, a function is expecting a pointer to a foreign string but that foreign string has already been converted into a valid Lisp string.

Within the doc/ directory in the tarball, I've added a subdirectory debuglog. It contains subdirectories meant to be write-only stores for recording stacktrace and debugging scripts. I enclose the entire stacktrace of the error in one of those subdirectories, along with this email.

If you have a clue about how to fix this problem quickly, I'm happy to test it. However, next Tuesday I'll be leaving for about a month, so if you don't think we're likely to resolve this problem quickly I suggest we put the tarball that I am sending you online, post a note to cl-gardeners, and hope that more expert hands will take this the rest of the way.

Hopefully someone will pick it up. It baffles me to think that so many folks are busily reproducing rather primitive libraries, when this single project alone -- if it could be made to work well -- would effectively introduces HUNDREDS of excellent libraries in one stroke. But we've talked about this before

all the best,
alexis




Jeremy Smith wrote:
> Alexis Gallagher wrote:
>> Cool,
>>
>> I didn't know you were going to have a go at installing it yourself.
>> (I only knew my constant flight from the spammers was scrambling some
>> of my addresses) Good luck!
>>
>> a
>
> Hi,
>
> Here it is! I simply moved the Python DLL definitions to the top so they
> are initialised before defpyfun is called. Now it compiles. It would be
> great if you could test this (load it as an ASDF in other words) and
> tell me how it goes.
>
> I also fixed a bug in dumpstd where it was using pygetarg *inside* a
> defpyfun! Not a good idea as the string has already been converted and
> thus is not a pointer! Which meant that get-web-page was broken.
>
> Once you've looked it over for any problems (shouldn't take 5 minutes),
> give me the go-ahead and I'll put it in the tar.gz with an update to the
> docs to say it compiles okay, and works fine. Then maybe people will use
> it!
>
> Cheers,
>
> Jeremy.