() Noah Lavine
() Wed, 2 May 2012 11:26:22 -0400
Unfortunately, it looks like the changes for these do not have
copyright assigned to the FSF, so we can't use them directly.
Is that correct?
Partially (details below).
Also, I hope this isn't a sensitive topic, but why is there a
Hello,
> The short answer is that the fork (from 2001 or so) was a reaction
> to losing repo write privs. Now that i have regained them, i am
> interested in merging back the relevant bits, w/ copyright notice
> modified to the proper FSF standards. Details up to you...
That sounds great to me!
Hi Thien-Thi,
It would be great if you could help with documenting these modules.
What do you think about copying the doc for these modules from 1.4 to
1.8/2.0? Would you be willing to transfer copyright to the FSF for
that?
If Noah is OK to help with the actual transfer of the doc bits, then I
Hi Noah!
Noah Lavine skribis:
> Okay, I can write documentation this way too. I have a question about
> this: what is the distinction between the sections "API Reference" and
> "Guile Modules"? I need to figure out where documentation for
> different modules goes.
>From “Organisation of this Ma
Noah Lavine writes:
> Hello,
>
>> The short answer is that the fork (from 2001 or so) was a reaction
>> to losing repo write privs. Now that i have regained them, i am
>> interested in merging back the relevant bits, w/ copyright notice
>> modified to the proper FSF standards. Details up to you
>> Luckily, I haven't actually started the rewrite, because I also have
>> limited time to work on this. So I'm very glad to hear that you're
>> interested in transfering them. If you are the only author of the
>> pieces, then I think the transfer is simple - you put the FSF
>> copyright notice at
Hello,
> From “Organisation of this Manual”:
>
> *Chapter 6: Guile API Reference*
> This part of the manual documents the Guile API in
> functionality-based groups with the Scheme and C interfaces
> presented side by side.
>
> *Chapter 7: Guile Modules*
> Describes some i
URL changed:
SRFI 64: "A Scheme API for test suites by Per Bothner" Guile implementation
-
https://gitorious.org/srfi-64-port/srfi-64-guile
SRFI 78: "Lightweight testing by Sebastian Egner" Guile module -
https://gitorious.org/srfi-78-guile
Test code added:
Modified test suite for the testing SR
Noah Lavine writes:
>>> Luckily, I haven't actually started the rewrite, because I also have
>>> limited time to work on this. So I'm very glad to hear that you're
>>> interested in transfering them. If you are the only author of the
>>> pieces, then I think the transfer is simple - you put the F
Hi!
Noah Lavine skribis:
> Unless there is going to be some other distinction between core and
> extensions, it would seem more natural to me to document everything by
> functionality, in the same part of the manual. Some sections would
> correspond to modules, because modules are also supposed
Hello,
>> Unless there is going to be some other distinction between core and
>> extensions, it would seem more natural to me to document everything by
>> functionality, in the same part of the manual. Some sections would
>> correspond to modules, because modules are also supposed to group
>> thin
() l...@gnu.org (Ludovic Courtès)
() Mon, 14 May 2012 14:44:17 +0200
What do you think about copying the doc for these modules from
1.4 to 1.8/2.0? Would you be willing to transfer copyright to
the FSF for that?
Sure (see other reply to Noah).
If Noah is OK to help with the actual t
In our work to look into how Python 3 could be implemented for Guile we
have figured out that the only way to make a goops object applicable is to
have it inherit . This does not always work the way it
could be expected, for example when inheriting from several classes.
Apparently this works by som
Hello,
> If Noah is OK to help with the actual transfer of the doc bits,
> then I guess we’re almost all set. :-)
>
> 1.4 snarfs comments from .scm files for interpolation in template
> files to create the final texinfo, but i'm almost certain you
> don't need/want that flow, but would rather
I do have a cludgy fix for this but are in search for a better solution.
consider the problem:
(define-syntax-class a (pattern (1 x:b)) (pattern ()))
(define-syntax-class b (pattern (2 x:a)) (pattern ()))
the syntax class definitions above would expand to something like
(begin
(define parser
Hi,
syntax-parse is kind of heavy right now. The parser function produced are
huge and the main reason
is that the stored syntax objects are enormous. I know that Mark Weaver had
done something to make
these creatures less fatty. The question is if there is anything a guile
user can do?
Regards
S
Hi Andy!
This all looks pretty exciting! Being able to get rid of all repeated
‘local-{ref,set}’ instructions sounds compelling. And it does seem to
bring us one step closer to native code.
Presumably the tricky part will be the register allocator, right?
Looking at the ‘countdown’ example, I
Noah Lavine wrote:
> Hello,
>
> > From “Organisation of this Manual”:
> >
> > *Chapter 6: Guile API Reference*
> > This part of the manual documents the Guile API in
> > functionality-based groups with the Scheme and C interfaces
> > presented side by side.
> >
> > *Cha
On Mon, May 14, 2012 at 5:09 PM, Ludovic Courtès wrote:
> Hi Andy!
>
> This all looks pretty exciting! Being able to get rid of all repeated
> ‘local-{ref,set}’ instructions sounds compelling. And it does seem to
> bring us one step closer to native code.
>
> Presumably the tricky part will be t
Hi Stefan,
Stefan Israelsson Tampe writes:
> syntax-parse is kind of heavy right now. The parser function produced
> are huge and the main reason
> is that the stored syntax objects are enormous.
Yes, this is very unfortunate. These syntax-objects add a huge amount
of bloat to our entire syste
Krister Svanlund writes:
> In our work to look into how Python 3 could be implemented for Guile
> we have figured out that the only way to make a goops object
> applicable is to have it inherit . This does not
> always work the way it could be expected, for example when inheriting
> from several c
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>> l...@gnu.org (Ludovic Courtès) writes:
>
>>> I’ll let you see whether/how you can borrow from this in your code, if
>>> that’s fine with you.
>>
>> Okay, will do.
>
> Any progress on this? ;-)
I apologize for dropping on the ball
l...@gnu.org (Ludovic Courtès) writes:
> Try something like:
>
> $ GUILE_LOAD_PATH=/foo/bar: make check
>
> … and see the LALR tests fail with:
>
> ERROR: In procedure primitive-load-path: Unable to find file
> "home/ludo/src/guile/test-suite/lalr/common-test.scm" in load path
>
> (These tests
-- Forwarded message --
From: Krister Svanlund
Date: Tue, May 15, 2012 at 2:45 AM
Subject: Re: Making every goops object applicable
To: Mark H Weaver
On Tue, May 15, 2012 at 12:16 AM, Mark H Weaver wrote:
> Krister Svanlund writes:
> > In our work to look into how Python 3 co
24 matches
Mail list logo
