[Scons-dev] Schedule for redesign?

[William Deegan]

Dirk,

If you have changes which substantially improve SCons's memory footprint and/or runtime.
I would ask that you break those up into smaller submissions and send pull requests.

While we want to be aware of Jason's Part's work. We don't necessarily want to be held up by it.

Once you submit the pull requests, then it would be great if Jason could comment on any changes which might impact his Parts work.

That said. Let's not make better the enemy of good.
If we can release your improvements in the near term that would be wonderful.
Assuming your changes as they are today don't break any tests, then we should get them in as quickly as possible.

If the changes are just organizational, then it's worth taking more time to consider impact on other projects.

Thanks,
Bill

On Oct 28, 2013, at 11:44 AM, Dirk Bächle <tshortik at gmx.de> wrote:


> Hi Jason,

> 

> and thanks for chiming in.

> 

> On 28.10.2013 17:07, Kenny, Jason L wrote:

>> I hope I would not be a wrench in engine :-)

>> 

>> Honestly The issue that this is work and I have to do this at home is the main reason I have not pushed anything at this point. ( And having twin 3 years-old means I don't have the go power at the end of the day...)

>> 

>> I would agree with what is being stated. I would go a bit farther however.

> 

> I understand that you have done some work on redesigning/refactoring parts of SCons, and you certainly don't want to lose it for nothing. So, I'd like to make the following suggestion: I'll factor out some attributes of the Node class into their own module and commit these changes (together with the other rewritings I mentioned) to a named branch in my personal "experimental" SCons fork.

> Then you can have a look at it and check whether you'd be able to base your further work on that. If not, you can tell me what should be changed such that you can continue properly with your work. If I get your "okay", the changes find their way into the SCons core and you can take it from there whenever you find the time. How does that sound?

> 

>> I would redesign the Node API. But also redo the executioner logic. Ideally we want I have learned is that the task logic needs to be updated. Greg Noel was on the correct path with TNG in that we want to execute "builders" not nodes. We also need the API ( internal) to decouple the relationships with the tasks and the nodes.

>> 

>> I would also look at fixing up the subst engine. I found that this is another area of memory waste at the moment ( and not in the good way). This might be more of an issue with Parts as I currently use the subst engine to share data between different "parts"/ components. Until I do a new part file format and or a "continuous loader" I have no way to pass data correctly.

> 

> During my investigations I tried to speedup subst() by caching some pre-expanded strings, but it didn't work out. My current impression is that you either have to compile it (including optimizations by hand, simply running Cython over it is not enough!) or reduce functionality (like cutting down the support for callables) to get it faster.

> 

> But don't let me stop you from trying... ;)

> 

> Best regards,

> 

> Dirk

> 

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev