Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> I have changed it to use a pointer. It seems to work, and it seems to
> compile.
That can't be right can it? It's supposed to be an array of structs,
not a pointer.
___
Guile-devel mailing list
Guile-d
Mikael Djurfeldt wrote:
Eval closures can be any arbitrary procedure which fulfills the
obligations of an eval closure. This has been used in the guile-tcltk
interface to make Tcl variables and functions look like ordinary
Scheme variables. The SMOB eval closures is an optimization for the
stan
Mikael Djurfeldt wrote:
Eval closures can be any arbitrary procedure which fulfills the
obligations of an eval closure. This has been used in the guile-tcltk
interface to make Tcl variables and functions look like ordinary
Scheme variables. The SMOB eval closures is an optimization for the
standa
I found a couple errors while compiling the most current snapshot of guile:
libguile/numbers.c uses SCM_BOOL rather than scm_from_bool at lines
3231 and 3285.
srfi/srfi-1.c uses SCM_NULLP instead of scm_is_null at lines 723 and 745.
Hope this helps.
Peter Gavin
<[EMAIL PROTECTED]>
___
On 7/9/05, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> > That would be good, because the current fix (which is already
> > committed to CVS HEAD, and which removes the setting of the
> > procedure-property) still leaves code in modules.c which expects the
> > procedure-property to be set. If Han
Neil Jerram wrote:
>
> Yes, I did say that - sorry, I didn't mean to. For the sake of
> reassurance (and review), I'll try again: [...]
This removal is now complete - please let me know if you see any problems.
Neil
___
Guile-devel mailing l
Mikael Djurfeldt wrote:
On 7/7/05, Marius Vollmer <[EMAIL PROTECTED]> wrote:
I've fixed this by introducing a new function (eval-closure-module)
which returns the module of a closure via the eval-closure smob.
I think the right fix is to change the weak hashtable marking
algorithm to properly
