pinterface / burgled-batteries

A bridge between Python and Lisp (FFI bindings, etc.)
Other
113 stars 21 forks source link

Can't build on Allegro #10

Open ghost opened 8 years ago

ghost commented 8 years ago

Hi, when I try to load it on Allegro CL, it reports this platform does not support :long-long. and this is reported by CFFI.

This is embarrassing, is there any possible way to fix this problem? Any suggestions would be appreciated.

pinterface commented 8 years ago

Hrm... in theory, one could qualify the forms in ffi-interface.lisp which mention :long-long with a #-cffi-sys::no-long-long.

You'd lose access to that particular functionality (so no PyLong_FromLongLong, etc.), but if you can do without that stuff, it might be good enough.

So give that a whirl. If it works for you, send me a patch and I'll get it applied.

ghost commented 8 years ago

Hi again :)

I've talked to Allegro's engineers, they tell me on a 64bit Allegro, CFFI actually does support :long-long type. By the way, we'd also discussed it can be helpful if we are using a :case-sensitive-lower lisp, which is also called modern case lisp in Allegro; you may wanna take a look here. In that case, at least we don't have to use strings everywhere to designate Pythons's names directly, and we can put those names in another package to eliminate possible conflicts with Lisp symbols.

In your opinion, is it possible to implement such a package dealing with the readtable such that it can be configured to be switched between the ANSI case(that would be :case-insensitive-upper) and the modern case?

pinterface commented 8 years ago

-no-long-long should already account for CFFI supporting :long-long on

64bit Allegro, no?

I'm not sure I understand what you're asking in relation to modern mode. Are you saying you want to be able to do something like

(defpyfun Python_Name ...)

and have that interpreted as if you had done

(defpyfun ("Python_Name" Python_Name) ...)

? If so, that should be relatively straightforward to implement, and seems entirely reasonable to support.

If, on the other hand, you're asking about making the python->lisp name auto-conversion respect modern mode, that would likely be a bit more involved, but I've certainly no objection to it in principle.