Glad you like it. I'm not sure where the idea leads, it was just a momentary spark floating through my head.

btw, I just handed in my dissertation last week, so right now I am working on packaging my application into a Configuration and then migrate from Moose 4.7 to Moose 4.8. This might take a bit of effort due to:
* being my first one
* some not-so-clean hacking on my part of components of dependee++ Configurations (Roassal included, I may try to get some stuff in)
* update to latest dependee Configurations
* depending on some components lacking a Configuration

btw, Do Versionner and Snapshotcello work on Pharo 1.4 ? I'm having some trouble with these (that I'll discuss later).
Maybe I'd be better to manually migrate to Moose 4.8 and then run those tools there.

cheers, Ben

++ yes I just made that word up. What is the proper alternative? (my mind has gone blank - post dissertation stress disorder I think)

Alexandre Bergel wrote:

Hi Ben,

You are raising an interesting point.
Having a wrapper for a collection would greatly simplify the construction of the Roassal API.
For example, we could then have:
	(ROElements forCollection: (1 to: 20)) addInteraction: RODraggable.

Currently we need to do:
	(ROElements forCollection: (1 to: 20)) do: [ :el | el addInteraction: RODraggable ].

Alexandre


On Aug 21, 2013, at 10:18 AM, Ben Coman <btc@openInWorld.com> wrote:

Alexandre Bergel wrote:

Slitting the collection seems to bring many problems. I have also share with you that splitting the collection is a good thing. But well.. if it implies a severe refactoring, it does not look that appealing to do it now.

Alexandre


On Jul 24, 2013, at 6:50 AM, 
mathieubmddehouck@mailoo.org
 wrote:

Hi


An idea to improve roassal scalability was to split the collection elements belonging to ROContainers and builder, into two different collections : edges and nodes.

It would permit not to unset shape after we add new edges or nodes, and it would save little time when asking for elementsNotEdges.

But after a little trial, it seems that it will ask a huge refactor of roassal to see a real gain in time, with just splitting the collection it gets worse.

For example, each time we need both nodes and edges in the same collection we have to concatenate the new collections and it's time consuming.

Hi Mathieu,  Just a random thought that pops into my head (and I don't know how practical it is....)
Rather than concatenate the nodes and edges collections, could you have a class ROElemementsAndEdgesCollection holding the two collections as their separate entities and to iterate as follows...

ROElemementsAndEdgesCollection >> do: aBlock
    nodes do: aBlock
    edges do: aBlock

cheers, Ben

Always working with Object withAllSubclasses as benchmark, we spend 28 second in copyReplaceFrom:to:with ( concatenation ).

And it brings us from 69 sec to 136 sec... A beautiful loss of 67 seconds...

 
The idea came when using rawEdgesFrom:to: was long, in fact it used to call elementsNotEdges for each iteration, then in our case a little more than 11000 times, and that was long, but now, as we don't call it so often it is quick enough.

 
That was maybe not that a good idea to split the collection.

Tell me what you think.

Regards

Mathieu

 
_______________________________________________
Moose-dev mailing list

Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev