On Sat, Apr 10, 2021 at 11:52 PM Linus Björnstam <
linus.bjorns...@veryfast.biz> wrote:
> I still want to write an implementation of srfi-158 for guile, but given
> the current state I believe it is quite far in the future. I have had a
> bout 2 hours of serious computer time per week since the n
Hi Arthur!
I have been looking for the code, seemingly in vain. I had a disk failure not
too long ago, and it was probably in one directory not backed up. I will keep
looking for it, since I am still in some kind of low-effort journey to restore
my home directory, but I don't think I will find
On Tue, Jan 26, 2021 at 3:54 AM Linus Björnstam <
linus.bjorns...@veryfast.biz> wrote:
> The code's internet presence is apparently gone (bitbucket mercurial. I
> don't know how I missed that ). I won't have access to that code for about
> 2 weeks, but I will upload it and try to get it up to par
The code's internet presence is apparently gone (bitbucket mercurial. I don't
know how I missed that ). I won't have access to that code for about 2 weeks,
but I will upload it and try to get it up to par with the updated SRFI-158.
Lg. Linus Björnstam
On Tue, 26 Jan 2021, at 08:14, Marc Nieper-
Am Di., 26. Jan. 2021 um 08:08 Uhr schrieb Linus Björnstam <
linus.bjorns...@veryfast.biz>:
> Hi Y'all!
>
> I have an efficient, almost done implementation of srfi-121. I believe it
> lacks generator-unfold, but that is all. make-coroutine-generator is
> implemented using delimited continuations a
Sorry, I though this was in the guile mailing list.
--
Linus Björnstam
On Tue, 26 Jan 2021, at 07:48, Linus Björnstam wrote:
> Hi Y'all!
>
> I have an efficient, almost done implementation of srfi-121. I believe
> it lacks generator-unfold, but that is all. make-coroutine-generator is
> imp
Hi Y'all!
I have an efficient, almost done implementation of srfi-121. I believe it lacks
generator-unfold, but that is all. make-coroutine-generator is implemented
using delimited continuations and runs a lot faster than the one in the
reference implementation, with the caveat that it is appar
Note that 121 is withdrawn, so people should implement 158.
On Sat, Jan 23, 2021 at 1:38 AM Mark H Weaver wrote:
> Hi Arthur,
>
> "Arthur A. Gleckler" writes:
> > It's not a bad idea for the sample implementation to be as clear as
> > possible at the expense of performance.
>
> I agree that it'
Hi Mark,
I agree that the whole point of generators is performance. When combined
with lazy sequences (srfi-127), it covers many typical use cases of streams
much more efficiently.
I've written Gauche version with performance in mind, but it depends on a
few non-standard features and can not be us
On Fri, Jan 22, 2021 at 6:15 PM Shiro Kawai wrote:
> Hi Mark,
> I agree that the whole point of generators is performance. When combined
> with lazy sequences (srfi-127), it covers many typical use cases of streams
> much more efficiently.
> I've written Gauche version with performance in mind,
Hi Arthur,
"Arthur A. Gleckler" writes:
> It's not a bad idea for the sample implementation to be as clear as
> possible at the expense of performance.
I agree that it's desirable for one of the sample implementations to be
as simple and clear as possible, for the purpose of clarifying the
speci
Hi John,
John Cowan writes:
> Mark: I'm interested to know if you have a sketch of ideas for a more
> efficient implementation of SRFI 121/158. You say it requires specific
> knowledge of Guile internals, but are you willing to sketch how you might
> do it? Thanks.
Here are a few suggestions
Back in July 2020, Mark Weaver wrote:
Also, the provided implementations of 'generator-find', 'generator-any'
> and 'generator-every' are incorrect:
Shiro Kawai has now fixed these bugs, and they have been merged into SRFI
121. Note that even if it doesn't become part of Guile's
batteries-inclu
Marc Nieper-Wißkirchen writes:
>>> While I have been contributing to R7RS-large, I have to agree with you
>>> to some extent. Most of the SRFIs that have been voted into R7RS-large
>>> or are to be submitted for it don't have the quality of the R6RS or
>>> R7RS(-small) specifications
>
>> Inevita
Am Di., 4. Aug. 2020 um 17:24 Uhr schrieb John Cowan :
>> At the moment,
>> there is no general programmatic way to know whether a specific
>> implementation is up-to-date with respect to these post-finalization
>> notes or not.
>
>
> How could there be? The implementations are written in a Turi
On Mon, Aug 3, 2020 at 3:41 PM Marc Nieper-Wißkirchen
wrote:
> It didn't occur to me that the reference implementation of a finalized
> > SRFI would include comments like "the spec would have me return #f, but
> > I think it must simply be wrong".
It certainly should not. But it can happen whe
Am Mo., 3. Aug. 2020 um 21:41 Uhr schrieb Marc Nieper-Wißkirchen
:
> > I'm sorry to say it, but in my opinion SRFI-121 and SRFI-158 should be
> > deprecated and avoided. The reference implementations do not match the
> > specifications, and the specifications themselves are self-contradictory
> >
Am Mo., 3. Aug. 2020 um 18:00 Uhr schrieb :
> Message: 1
> Date: Sun, 02 Aug 2020 18:39:32 -0400
> From: Mark H Weaver
> To: John Cowan
> Cc: guile-devel@gnu.org
> Subject: Re: [PATCH] add SRFI: srfi-121; generators
> Message-ID: <87v9i0zn7k@netris.org>
>
Hi John,
John Cowan wrote:
> Mark Weaver wrote in July 2019:
>
>> Also, the provided implementations of 'generator-find', 'generator-any'
>> and 'generator-every' are incorrect:
>
>
> I appreciate your finding these bugs. I wish, however, that you had also
> sent them to .
Sorry about that.
Mark Weaver wrote in July 2019:
Also, the provided implementations of 'generator-find', 'generator-any'
> and 'generator-every' are incorrect:
I appreciate your finding these bugs. I wish, however, that you had also
sent them to .
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
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
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
23 matches
Mail list logo
