Dependency resolving got slower...

[Nicola Ken Barozzi <ni...@apache.org>]

The build.py run got much slower (3x) it seems, and maybe it's in the 
dependency resolving code... Sam, any idea why this has happened? Maybe 
the dependency inheritance code (BTW, thanks)?

BTW, if I cd into the python dir and runb gumpview, it does not find the 
descriptor, and the exception causes this:

...
IOError: workspace PC103.xml not found
23:16:07: Debug: e:\projects\wx\src\msw\app.cpp(439): 
'UnregisterClass(canvas)'
failed with error 0x00000584 (la classe ha ancora finestre aperte.)


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Dependency resolving got slower...

[Nicola Ken Barozzi <ni...@apache.org>]

Sam Ruby wrote, On 28/04/2003 0.09:
> Nicola Ken Barozzi wrote:
> 
>>
>> The build.py run got much slower (3x) it seems, and maybe it's in the 
>> dependency resolving code... Sam, any idea why this has happened? 
>> Maybe the dependency inheritance code (BTW, thanks)?
> 
> 
> Most of the time is in determining the global build order... something 
> that the current implementation of the inheritDependencies relies on.  I 
> am aware of the issue and looking into alternatives.

Ok.

> Expect to see performance both improve and degrade periodically as more 
> of the functionality of gump comes on line.  My hope is that there will 
> not need to be a 'gen' step when we are done, and I will do my best to 
> avoid it if at all possible, but it may end up being required.

Ok. Anyway, we will also make it transparent, so that users will not 
have a gen step to manually perform.

This Gump is really cool :-)  I know I keep saying it, but I can't help 
it ;-)  It finally rings to life the thing I wanted to have since I 
started looking at Gump and musing over the famous "ubercron/Vindico" 
stuff. Looking at Vindico and at this Gump in Python, I'm still amazed 
by the *enormous* difference in readability, code size and coding speed.

I'm now learning Python unit tests, I hope to use them soon, but don't 
count on it just yet ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Dependency resolving got slower...

[Sam Ruby <ru...@apache.org>]

Nicola Ken Barozzi wrote:
> 
> The build.py run got much slower (3x) it seems, and maybe it's in the 
> dependency resolving code... Sam, any idea why this has happened? Maybe 
> the dependency inheritance code (BTW, thanks)?

Most of the time is in determining the global build order... something 
that the current implementation of the inheritDependencies relies on.  I 
am aware of the issue and looking into alternatives.

Expect to see performance both improve and degrade periodically as more 
of the functionality of gump comes online.  My hope is that there will 
not need to be a 'gen' step when we are done, and I will do my best to 
avoid it if at all possible, but it may end up being required.

- Sam Ruby