Re: Scmutils in guile-2.0

[Mikael Djurfeldt]

Daniel Gildea reported problems for guile-2.0 guile-scmutils.  Those
are fixed in the attached diff.

Best regards,
Mikael D.


guile-scmutils-v0.8-2.0-2.diff
Description: Binary data

[PATCH] update old references in FFI doc

[Daniel Hartwig]

* doc/ref/api-foreign.texi (Foreign Types): Replace references to the
  old foreign->bytevector and bytevector->foreign with the new procedure
  names using pointer.
---
 doc/ref/api-foreign.texi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi
index 2473870..e595668 100644
--- a/doc/ref/api-foreign.texi
+++ b/doc/ref/api-foreign.texi
@@ -803,8 +803,8 @@ int64_t a; uint8_t b; @}}:
 @end example
 
 As yet, Guile only has convenience routines to support
-conventionally-packed structs. But given the @code{bytevector->foreign}
-and @code{foreign->bytevector} routines, one can create and parse
+conventionally-packed structs. But given the @code{bytevector->pointer}
+and @code{pointer->bytevector} routines, one can create and parse
 tightly packed structs and unions by hand. See the code for
 @code{(system foreign)} for details.
 
-- 
1.7.10.4

avoiding SEGV during SMOB GC with gc 7.3

[Mike Gran]

Hi-

There's something we discussed in bug report #13611 that
might be of general interest.

If you're using a gc built with --enable-parallel-marks
with Guile, you can get a SEGV during garbage collection
of a SMOB.  BDW-GC v7.3 has that flag enabled by default.
It allows the garbage collector to spawn a new thread
to mark data.


Also, Fedora has that flag enabled by default with v7.2.

This only applies if you run Guile on a multi-core system.


It appears you can disable this behavior, even if you
compiled GC with --enable-parallel-marks, by 

setenv GC_MARKERS to 0 or 1.

-Mike

Re: Dynamic FFI vs Static FFI (was Re: About Guile crypto support)

[William ML Leslie]

On 13 February 2013 05:24, Mark H Weaver  wrote:
> Okay, but here I'm using "Static FFI" to mean something very different
> than the C API: I'm talking about a pure scheme-based API that would be
> quite similar to the API our current dynamic FFI, except that a lot of
> the work would be done at compilation time (probably during macro
> expansion).

Maybe even something like LuaJIT FFI or python's CFFI - that can parse
C code at compile time to produce the data structures for the dynamic
FFI?

-- 
William Leslie