On 20 Nov 2007, at 15:52 , Stéphane Ducasse wrote:
> - __state__ is the main abandoned construction site (the idea
> is to considerable recue the memory footprint of moose and trade-off
> performance in the same time. I stopped mid way, when all my
> suggestion to use meta-programming got rejected as I dont think we
> can reduce the memory-footprint with Java-like code as it is now.
I do not understand what is Java-like code?
Non-meta-programming-using-code :) sorry for the pun.
> I was mainly thinking of (i) collective instance variables for the
> model backlink,
Sorry I do not know what is a collective instance variable
Take a group of instances, change them to same anonymous subclass and
attach a class var to that subclass. The plan is to use this for
entity's model backlink.
> (ii) dynamic instance variables (ie wide classes) for
> all none FAMIX.Core properties and metrics, adn (iii) collective
> behavior for collective behavior. In particular the (i) would in
> addition to saved instvar slots also save the need to keep all those
> ugly caches of all-entities-of-one-kind in the model).
so what can we do if we are normal people to help. I'm not sure that
I can help on this one.
I discussed with Toon recently, he might gonna implement most of the
meta-programming when adapting the code-generation for Famix 3.
> - Write method comments
> - New exception dialog that shows a form for bug-repot and "send to
> moose-dev" button which will take report, attached stack trace and
> other interesting info and send it to this list.
> - Have some Javadoc like comment tool
for doing what? Collecting the comments?
Yes, and publish them as HTML or Latex for API documentation, as
Lukas does for Pier et al.
> - CodeFoo.Task
What is it?
> - Write package comments
> - Switch from Meta to Fame (the new Famix 3.0 Meta on which I started
> working on today's 15 hour odyssee through France, Belgium and
> Germany) (Fame stands for FAmix MEtamodel)
Why do you change Meta? to FAME?
Dasselbe in Grün, Fame is Meta's new name.
> - Sketch some rough UML of moose main class structure
> - FM3.MultivalueLink for many-to-many relationships
> - Write tutorials for basic plugin-developer tasks
I would love to proofread that and do them. But I have a problem to
write one for now because moose changes too mcuh for me.
I can write some for Fame and other kernel-related tasks.
@Doru, could you do tutorials for UI-related tasks? I think you now
best which is part of Moose's public interface and which is private
> - Proper test setup
> - (currently they are too long, and their fixture too complexe to be
> a help. When broken the single point of failure is not evident)
> - (as a first step, this can mean as little as making two test
> suites, one with the small and okay tests, and one with the ugly
> - (I expect that each ugly tests could be splitted in at least two
> dozen nice tests each)
I'm not sure since I certainly wrote a lot of ugly tests that I can
cut them into meaningful
Smaller test fixtures are most critical, I'd say.
> - Write class comments
> - Tagging of Moose's public interface with a pragma and setup a way
> to check at runtime if plugins violate this constraint
> - Propose nice coding conventions and useful best practices for Moose
> - Enforce them
> That is all I remember now. For priorities, all of that is low to
> very low on my list except for supporting the transition from F2.2
> to F3
I will check moose and see what I can do.