Hello,
>...
> In my experience, it's definitely not ok to capture a pointer to a
> scheme object and store it for later use without protecting the scheme
> object from gc by holding a reference.
I recently had a similar conversation, here is one of the emails of the thread,
the
one that lists a
> On 27 Jun 2019, at 21:52, Greg Troxel wrote:
>
> I have been down this path before, with guile and with lua. Basically,
> if C (or non-scheme) has a pointer to a scheme object, then you need to
> hold a logical reference for it and protect the scheme object, and when
> the C pointer is dropp
On Sat, Jun 29, 2019 at 7:44 PM Greg Troxel wrote:
> Isaac Jurado writes:
>
> > On Thu, Jun 27, 2019 at 9:52 PM Greg Troxel wrote:
> >
> >> I have been down this path before, with guile and with lua. Basically,
> >> if C (or non-scheme) has a pointer to a scheme object, then you need to
> >> h
We are delighted to announce GNU Guile release 2.2.6, the sixth bug-fix
release in the 2.2 stable release series. See the NEWS excerpt that
follows for full details.
* * *
Guile is an implementation of the Scheme programming language.
The Guile web page is located
SRFI-121 Generators.
All tests(49/49) are passing in my testing. I am not sure if the tests
file is put in the correct place.
0001-add-SRFI-srfi-121-generators.patch
Description: Binary data
Hi Isaac,
Isaac Jurado writes:
> I'm playing with event loop libraries implemented in C (libev,
> libevent, etc... in my case libsystemd), but configuring them from
> Guile.
>
> The qsort example in the documentation [1] seems safe because the
> qsort C function directly calls back, so the callb
Hi Amar,
> SRFI-121 Generators.
>
> All tests(49/49) are passing in my testing. I am not sure if the tests
> file is put in the correct place.
>
> From 0352f9be13aba1e8acc9a8f700f3673334d48d28 Mon Sep 17 00:00:00 2001
> From: Amar Singh
> Date: Mon, 1 Jul 2019 05:14:53 +0530
> Subject: [PATCH] ad
Hi again,
I wrote earlier:
> With this in mind, if SRFI-121 is to be added to Guile, it should be a
> high performance implementation. The implementation that you provided,
> which I guess is primarily taken from the sample implementation, is far
> too inefficient, at least on Guile.
I should em
On July 1, 2019 11:30:38 AM GMT+05:30, Mark H Weaver wrote:
>Hi again,
>
>I wrote earlier:
>> With this in mind, if SRFI-121 is to be added to Guile, it should be
>a
>> high performance implementation. The implementation that you
>provided,
>> which I guess is primarily taken from the sample impl
