Hello!
Andy Wingo writes:
> Guess what I found ;-)
>
> On Sat 05 May 2007 22:48, l...@chbouib.org (Ludovic Courtès) writes:
>
>> My intent is to eventually document all (or most of) the `module-'
>> procedures, for instance under an "Introspection" node within the
>> "Modules" node.
>
> /me taps
Heya,
Guess what I found ;-)
On Sat 05 May 2007 22:48, l...@chbouib.org (Ludovic Courtès) writes:
> My intent is to eventually document all (or most of) the `module-'
> procedures, for instance under an "Introspection" node within the
> "Modules" node.
/me taps fingers, wondering about the mean
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Folks, I'm willing to install this patch in HEAD one of these days since
> it provides an appreciable performance improvement. Please let me know
> if you are strongly opposed to this.
I just committed this lazy duplicate binding handling thing
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Attached is a patch that implements lazy duplicate checking.
> `process-duplicates' is gone and `module-variable' plays its role when
> an imported variable is looked up for the first time. Subsequent
> lookups for the same variable result in a "
Oops, I hit `C-c C-c' too early. :-)
Ludo'.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> One possibility for duplicates would be lazy checking, only check for
> a clash when actually using a symbol. That's sort of the prolog
> theory: don't worry now about what might never come up. I suspect the
> total work would end up greater though.
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> One possibility for duplicates would be lazy checking, only check for
> a clash when actually using a symbol. That's sort of the prolog
> theory: don't worry now about what might never come up. I suspect the
> total work would end up greater though.
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> It's rather unfair to the data structure to say it's no good when
> there's likely to be an easy speedup between perhaps 2x and 5x.
Can you be more specific?
> In principle all core primitives should be implemented in C;
"Developers are the compiler
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Writing in C or assembly doesn't free from choosing appropriate
> algorithms.
It's rather unfair to the data structure to say it's no good when
there's likely to be an easy speedup between perhaps 2x and 5x. In
principle all core primitives should b
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> If that's true you'll have to start from the beginning again,
> everyone's eyes glaze over at "1000 modules".
Quoting the original message in this thread:
An application of mine [1], although it modifies `the-scm-module' at
run-time, requiring 40
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Well it _does_ hurt, even with real-life numbers of imports, as the
> experiments I made tend to show
If that's true you'll have to start from the beginning again,
everyone's eyes glaze over at "1000 modules".
> From a performance viewpoint, the que
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> The measurements in the `module-duplicates.scm' file I posted choose
>> USES = 1 by default, which is arguably unrealistic.
>
> Was that 1 imported modules? That's well outside the realm of
> r
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> The measurements in the `module-duplicates.scm' file I posted choose
> USES = 1 by default, which is arguably unrealistic.
Was that 1 imported modules? That's well outside the realm of
reason! :) Normally there'll be perhaps up to 20 import
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> Actually, `process-duplicates' is O(N*USES) _for each module used_. So
>> the overall duplicate processing is really O(N*USES^2). With the
>> patched version, the whole process is O(N*USES). That can
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Actually, `process-duplicates' is O(N*USES) _for each module used_. So
> the overall duplicate processing is really O(N*USES^2). With the
> patched version, the whole process is O(N*USES). That can make quite a
> difference when USES > 1.
It shoul
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> (1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
>> was discussed recently). Namely the fact that duplicate processing is
>> not always performed, depending on whether one uses
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> (1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
> was discussed recently). Namely the fact that duplicate processing is
> not always performed, depending on whether one uses `module-use!' or
> some other means to use a module
Hi,
The patch below (against HEAD) is a proposal to "improve" the module
system in several ways:
1. Remove inconsistencies in how it behaves.
2. Get better documentation and test coverage.
3. Improve performance.
(1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
wa
18 matches
Mail list logo
