A while ago I posted this patch:
http://lists.gnu.org/archive/html/guile-devel/2014-08/msg00058.html
No-one had anything to say about it. But I would like to know what to do if
I want my code to work with the next release of Guile.
I think in retrospect this patch is too much. A better patch
Thanks Neil, that works. This is what I did: but I made no attempt to make
the C-level interface backwardly compatible. It seems the same option could
apply to scm_with_throw_handler, but I left that alone. Can anyone tell me
what where the semantics to the latter when the LAZY_THROW_P paramerter w
On 2014-08-18 03:14, Ian Grant wrote:
Hi Neil,
Sorry, I am replying to my message because I'm not on guile-devel, it
seems. I'll join later.
Thanks for clarifying that. The misleading statement in the manual is
just above the paragraph you quote: on
https://www.gnu.org/software/guile/manual/htm
Hi Neil,
Sorry, I am replying to my message because I'm not on guile-devel, it
seems. I'll join later.
Thanks for clarifying that. The misleading statement in the manual is just
above the paragraph you quote: on
https://www.gnu.org/software/guile/manual/html_node/Catch.html#Catch it says
Han
On 2014-08-16 00:13, Ian Grant wrote:
Hello Guile types,
Hi Ian,
I have been experimenting with using libguile from within another
byte-code interpreter: Moscow ML. I have a version of Moscow ML with
an GNU lightning interface in which I JIT compile primitives to give
access to libguile funct
Hello Guile types,
I have been experimenting with using libguile from within another byte-code
interpreter: Moscow ML. I have a version of Moscow ML with an GNU lightning
interface in which I JIT compile primitives to give access to libguile
functions from Standard ML.
Moscow ML uses an old versi
