From: AJ Rossini
Subject: SBCL/CMUCL, CFFI, signal handling, and R
Date: 
Message-ID: <1141277580.680814.110960@z34g2000cwc.googlegroups.com>
Greetings!

I've got a bit of a technical query regarding POSIX SIG handling in
SBCL/CMUCL  with respect to embedding languages which mangle the signal
handlers.

The goal, for various reasons is to embed R (http://www.r-project.org/)
within CommonLisp (in general, not a specific implementation) as a
bridge while other code I'm designing gets written.    I'm following
the Rpy approach, which is basically to "swap out" the python SIG
handling calls for the R ones when evaluating R objects, swap back in
to python when we are back in that context" (using context in a
non-technical way, here).  CFFI head (due to excellent docs) is what
I'm using for a general solution.

With CLISP, it seems to work part of the way (I can load the R
interpreter and initialize the R REPL).   However, I'm completely
stopped with SBCL and CMUCL as I can't initialize the REPL without a
SIGFPE being thrown.   It looks like something is getting weird "on the
way back" from R to SBCL.  I've read the section on FFIs which state
"don't use C code which mucks with signal handling", and the error is
apparently getting called on the way back as I'm seeing funcall3 in the
dump frame.

Okay, having partially provided background, here are the questions:

1. debugging in the C library code -- since the errors are getting
through in foreign functions (even funcall3, SBCL core I think?, is a
foreign function), is there any strategies to debug such a mixture?
(GDB plus SBCL debug plus ---?  but I can't figure out how to attack a
SBCL thread with GDB).

2. storing the SBCL sig handlers on a stack and popping them -- is this
possible without mangling internals?  (a simple Y/N would be helpful).
 One idea that I had was to bring in the relevant objects via CFFI and
do my own sig handler swap, but I suspect that means that I'd be
hanging off to dry if an error occurred during transition.   What I'd
like to do would be to keep Lisp in control, but catch and pass along
to appropriate handlers any error handling needs from R (this is
possibly, i.e. the R handlers are exposed both for use and
modification).

I'd be happy to send my toy code (work-in-progress) at this point for
embedding R via CFFI if anyone wants to look (regardless if they want
to figure it out).

best,
-tony

From: rif
Subject: Re: SBCL/CMUCL, CFFI, signal handling, and R
Date: 
Message-ID: <wj0zmk850ky.fsf@five-percent-nation.mit.edu>
We should maybe talk, because I've actually done this already and it
might make sense to combine efforts.  I do have my code working on
SBCL.

What is essentially happening is that the R code, on initialization,
performs some "bad" floating point operations (division by zero and
invalid, IIRC).  The fix I am using is a macro wrapped around calls to
R, that masks:

(defmacro with-r-traps (&body body)
  `(sb-int:with-float-traps-masked  (:invalid :divide-by-zero)
    ,@body))

In any case, I do have a more-or-less working CL-to-R gateway for
SBCL.  I haven't tested it on any other CLs, although I do expect it
to work on CLISP fairly easily.

Cheers,

rif
From: AJ Rossini
Subject: Re: SBCL/CMUCL, CFFI, signal handling, and R
Date: 
Message-ID: <1141318323.631694.154730@v46g2000cwv.googlegroups.com>
Wonderful -- I'll get in touch off-line -- but that looks very
reasonable.

(I've got CLISP working on the tram in to work today, so this would
perhaps finish the general approach).

More later, I'm heading home now.

best,
-tony
From: ·············@gmail.com
Subject: Re: SBCL/CMUCL, CFFI, signal handling, and R
Date: 
Message-ID: <1141356566.360077.111890@t39g2000cwt.googlegroups.com>
Would it be possible to have a look at this code if you are going to
release it? I do not think I'll ever contribute (I am using CL to
rarely for that), but I could provide some testing and error
feedback....

Thx!