views:

64

answers:

2

I'm trying to create a binding to libpython using scheme's FFI. To do this, I have to get the location of python, create the ffi-lib, and then create functions from it. So for instance I could do this:

(module pyscheme scheme
  (require foreign)
  (unsafe!)

  (define (link-python [lib "/usr/lib/libpython2.6.so"])
    (ffi-lib lib))

This is all well and good, but I can't think of a way to export functions. For instance, I could do something like this:

(define Py_Initialize (get-ffi-obj "Py_Initialize" libpython (_fun -> _void)))

...but then I'd have to store a reference to libpython (created by link-python) globally somehow. Is there any way to export these functions once link-python is called? In other words, I'd like someone using the module to be able to do this:

(require pyscheme)
(link-python)
(Py_Initialize)

...or this:

(require pyscheme)
(link-python "/weird/location/for/libpython.so")
(Py_Initialize)

...but have this give an error:

(require pyscheme)
(Py_Initialize)

How can I do this?

A: 

I have not made many modules, but I think you need to 'provide' the functions that you want to load into the new namespace.

(module pyscheme scheme
  (provide
   link-python
   Py_Initialize
   <...>)
  (require foreign)
  (unsafe!)

  (define (link-python [lib "/usr/lib/libpython2.6.so"])
    (ffi-lib lib)))
(require pyscheme)
(link-python "/weird/location/for/libpython.so")
(Py_Initialize)
Davorak
+2  A: 

Probably the easiest way to do something like this is to delay the binding until they're needed. Something like this (untested) code:

#lang scheme

(require scheme/foreign)
(unsafe!)

(define libpython #f)

(define (link-python [lib "/usr/lib/libpython2.6.so"])
  (if libpython
    (error "Foo!")
    (begin (set! libpython (ffi-lib lib))
           (set! Py_Initialize
                 (get-ffi-obj "Py_Initialize" libpython
                              (_fun -> _void))))))

(define (Py_Initialize . args)
  (error 'Py_Initialize "python not linked yet"))

Ir you can do the setting inside the function itself, so you don't bind functions that are never called:

#lang scheme

(require scheme/foreign)
(unsafe!)

(define libpython #f)

(define (link-python [lib "/usr/lib/libpython2.6.so"])
  (if libpython (error "Foo!") (set! libpython (ffi-lib lib))))

(define (Py_Initialize . args)
  (if libpython
    (begin (set! Py_Initialize
                 (get-ffi-obj "Py_Initialize" libpython
                              (_fun -> _void)))
           (apply Py_Initialize args))
    (error 'Py_Initialize "python not linked yet")))

and since you won't want to do this for every single function, you should wrap it in a macro:

#lang scheme

(require scheme/foreign)
(unsafe!)

(define libpython #f)

(define (link-python [lib "/usr/lib/libpython2.6.so"])
  (if libpython (error "Foo!") (set! libpython (ffi-lib lib))))

(define-syntax-rule (defpython <name> type)
  (define (<name> . args)
    (if libpython
      (begin (set! <name> (get-ffi-obj '<name> libpython <type>))
             (apply <name> args))
      (error '<name> "python not linked yet"))))

(defpython Py_Initialize (_fun -> _void))
(defpython Py_Foo (_fun _int _int -> _whatever))
...more...

But two highlevel notes:

  • Even though it's possible, it seems ugly to delay things this way. I'd rather use some environment variable that is known when the code starts.

  • There have been an attempt in the past to link plt scheme to python, and IIRC, dealing with memory issues was not pleasant. (But this is before we had the current foreign system in place.)

Eli Barzilay
Two things: 1. This is going to be a library. I'd prefer to leave configuration up to the application developer. 2. I didn't realize this had been attempted in the past. To be honest, I jut thought it would be an interesting project to work on while I'm doing benchmarks.
Jason Baker
As it turns out, the previous approach was a bit different. They wrote a Python-to-Scheme compiler. It looks like as of that paper, they hadn't done anything with Python's C API.
Jason Baker
I'm don't remember what was actually described in the paper, but I know that Daniel tried several approaches, and one of them involved dealing directly with the Python C level. IIRC, the fundamental differences in approaches (is Python doing only reference counting?) was the real PITA that made the whole thing very difficult.
Eli Barzilay