Thousand Parsec: Mail Archives

I'm converting PyPy Scheme's test cases to Schemepy. Then I noticed our
Schemepy segment faulted on the continuation test case. I tracked the
code and make a minimized case to reproduce it, here's the code:

#------------------------------------------------
from ctypes.util import find_library
from ctypes import *

lib = find_library("guile")
guile = cdll.LoadLibrary(lib)

guile.scm_c_eval_string.argtypes = [c_char_p]

guile.scm_c_eval_string("(define cont #f)")
guile.scm_c_eval_string("(call-with-current-continuation (lambda (k)
(set! cont k) 3))")
guile.scm_c_eval_string("(cont 3)")
#-------------------------------------------------

The code above doesn't rely Schemepy. So there might be a bug in either
ctypes or libguile. I noticed it seemed to be object ref counting error,
like double freeing and minus ref count.

I then write a C program to exam this:

/* ------------------------------------------------ */
#include <libguile.h>

static void
inner_main(void *closure, int argc, char **argv)
{
    printf("1\n");
    scm_c_eval_string("(define cont #f)");
    printf("2\n");
    scm_c_eval_string("(call-with-current-continuation (lambda (k)
(set! cont k) 3))");
    printf("3\n");
    scm_c_eval_string("(cont 3)");
    printf("4\n");
}

int main(int argc, char **argv)
{
    scm_boot_guile(argc, argv, inner_main, 0);
    return 0;
}
/* ------------------------------------------------------------- */

The program prints lots of 3. So I'm wondering guile is manipulating
both the Scheme
stack and the C stack for the continuation. That would be OK in C, but
maybe not in
ctypes.

I don't have any ideas on how to solve this problem. Maybe we should
suggest not using
continuation ? But it seems call/cc is an important feature in Scheme.
Do you have some
suggestions?


-- 
pluskid