Hi doru
I have some scripts (available in the wonderful chapter on Gofer) to migrate code from ss and ss3 to SmalltalkHub.
Now the question is how do we organize moose?
I propose to create a team Moosers? and Moose as a project
Then what do we put underneath?
Fame as subproject?
Mondrian
Metanool
Stef
Hi guys
I finished to find a stupid bug today. Now the moose reloader works.
The idea is that you can freeze a complete Moose tools and be able to take a 1.4 image and reload all the packages
that were loaded when you snapshot it.
I could reload the latest version of Moose in a 1.4 image.
I published the result on ConfigurationOfMoose.
Gofer new
url: 'http://smalltalkhub.com/mc/StephaneDucasse/MooseReloader/main'
username: ''
password: '';
package: 'ReloaderForMoose';
load
Here is the comment of this class.
I'm a kind of saver/loader that knows how to save and load list of packages by recursively navigating metacello configurationOf. To work I need a metacello record and a place to save package version.
Here are examples to create a spec of packages to be saved.
===========================================
In an image containing the loaded configuration of the tools you want to version execute the following:
Reloader new
configurationRecordInput: (((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record) ;
repositoryClass: MooseConfigurationRepositoryForPharo14;
publishNewVersion
Reloader new
configurationRecordInput: (((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record) ;
repositoryClass: ConfigurationOfMoose;
publishNewVersion
It will produce a method called scriptXxx in the repositoryClass you specify.
Here is an example of such method.
script5
^ #(
#('ConfigurationOfFame-StephaneDucasse.6.mcz' 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' )
#('ConfigurationOfMooseAlgos-TudorGirba.28.mcz' 'http://www.squeaksource.com/MooseAlgos/' 'ConfigurationOfMooseAlgos' ) ......
)
You can then use this method as follows, for example in a ConfigurationOf you can
flatVersion47: spec
<version: '4.7-flat'>
spec for: #common do: [
self populateSpec: spec with: self script5 ]
Note that the populateSpec: with: is generated when necessary.
Reloading.
===================================
In another image you can reload the configuration in two different ways:
either by using metacello or by using the reloader.
Using metacello is simple if you created a method similar to
flatVersion47: spec
<version: '4.7-flat'>
spec for: #common do: [
self populateSpec: spec with: self script5 ]
just execute
(ConfigurationOfMoose project version: '4.7-flat') load
If you do not use a configurationOf you can simply invoke the method reload: with the number of the script
using the method
reload: aNumber
and it will load all the packages you previously specified.
reloadLatest
will load the latest script version
Typical use cases are:
------------------------------------
Reloader new
repositoryClass: MooseConfigurationRepositoryForPharo14;
reload: 2
Reloader new
repositoryClass: SynectiqueCaseOneConfigurationRepository;
publishNewVersion
Reloader new
repositoryClass: SynectiqueCaseOneConfigurationRepository;
loginSpecification: {{ '*squeaksource*' . 'sd' . 'xyxyx'} . { '*ss3*' . 'StephaneDucasse' . 'xxxx'} . { '*' . '' . ''}};
reload: 2
===================================================
Implementation Notes.
First version fully working on metacello records.
Let me know if it works for you.
Stef
Comment #2 on issue 865 by tu...(a)tudorgirba.com: Reloader should get the
list of packages to be loaded from the ConfigurationOfMoose
http://code.google.com/p/moose-technology/issues/detail?id=865
The problem is that we still cannot quite obtain the list of packages from
Metacello in proper order.
Status: New
Owner: ----
Labels: Type-Engineering Priority-Medium Maintainability Milestone-4.7
New issue 851 by tu...(a)tudorgirba.com: Create a stable version for Moose
and all its subparts
http://code.google.com/p/moose-technology/issues/detail?id=851
The configuration of Moose should be versionned, especially for a release.
We have to investigate if Reloader is good enough for 4.7.
Hi,
Thanks to the fix of Stef and the rapid Roassal fix of Alex, we now have a green build:
http://ci.moosetechnology.org/job/moose-latest-dev/
So, we are pretty much ready for the release.
Cheers,
Doru
--
www.tudorgirba.com
"If you can't say why something is relevant,
it probably isn't."
Just an idea floating through my head (its good to let them out before
they do too much damage in there) ...
It seems lots of research continues to goes into improving layouting
algorithms. I think Roassal could provide a good basis to visualize the
operation of a layout algorithm as an animation. This could be useful
to researchers as well as teaching demonstrations to students. The
benefit for Roassal of being 'the platform' for researchers to develop
and test their layout algorithms, would be ending up with all the latest
and greatest of these built-in.
Perhaps a student project...
One alternative could be a framework that manually inserted
#signalUpdate's at significant points of the algorithm.
Another could being extending the Smalltalk debugger to automatically
send #signalUpdate's with each step.
cheers -ben
Hello,
I had a "Not enough memory" problem in my Moose image so digging the error
(with Jean-Baptiste) reveals that when there is an error in a glamour
browser, roassal visualization does not unsubscribe events. In my case, it
retained the browser objects in the memory because these were pointed to by
the subscriptions and this the browser was not releasing my MooseModel.
To reproduce the problem, you can execute the script below. On the right
pane, right click on any node and then do, "select in tree". Close browser,
garbage collect, and then do: MOAnnouncer allInstances. There are few
instances related to MOAnnouncer that exist in the memory. Without the
error, these objects disappear.
Can you please have a look?
tx,
Usman
| browser items |
browser := GLMTabulator withStatusbar.
items := 50.
browser column: #one; column: #two.
browser transmit to: #one; andShow: [ :a |
(a tree)
title: 'Tree';
showOnly: 30;
display: [:each | 1 to: items];
children: [ :item :x :level | level > 1
ifTrue: [ #() ]
ifFalse: [ 1 to: item ]]].
browser transmit to: #two; from: #one; andShow: [ :a |
a mondrian
title: 'Numbers in Mondrian list';
painting: [:view :number |
view interaction item: 'Select in tree' action: [:each | ((browser
paneNamed: #one) port:#selection) value:41 ].
view interaction on: ROMouseEnter do: [ :n | ].
view shape rectangle size: 10.
view nodes: (Collection withAllSubclasses).
view edgesFrom: #superclass.
view treeLayout.
]
].
browser openOn: 1
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 903 by benjamin...(a)gmail.com: ROEdge without ROLine locks the
image
http://code.google.com/p/moose-technology/issues/detail?id=903
I have isolated the problem with the image locking up when ROEdge is used
without ROLine. I noticed that problem occurred also when using
ROAbstractLine instead of ROLine. So hacking breakpoints & logging into
the four methods of ROLine lead me to these being called on from ROEdge on
instance variable 'shape'. Looking at references of 'shape', I notice that
ROEdge adds three methods that RONullShape does not have. So the image can
be prevented from locking up with the following ugly hack...
ROEdge>>contains: aPoint
(shape isKindOf: RONullShape) ifTrue: [ ^false].
^ shape contains: aPoint for: self
ROEdge>>topLeft
(shape isKindOf: RONullShape) ifTrue: [ ^ 0@0 ].
^ (shape lineSegmentsFor: self) first
I'll leave it there for Alexandre to come up with a more appropriate fix.
cheers -ben
Ben Coman wrote:
> I can reproduce this on Windows 7 in Moose-4.7-beta from 2012-01-03
> (ConfigurationOfRoassal.A...B...752)
> With the ROLine commented as shown below the image locks. Alt-. fails to
> interrupt.
> With the ROLine uncommented it works fine.
> Forgetting ROLine is likely a common occurance for people new to Roassal,
> so
> this makes it a bit fragile.
> ---
> | view node1 node2 edge |
> view := ROView new.
> node1 := ROLabel elementOn: 'node1'.
> node2 := ROLabel elementOn: 'node2'.
> edge := (ROEdge from: node1 to: node2) "+ ROLine" .
> view add: node1; add: node2; add: edge.
> view open
> ---
> cheers -ben
> Alexandre Bergel wrote:
> > Hi Yuriy!
> >
> > I guess you meant "view add: edge; add: node1; add: node2." instead of
> using "rawView".
> > The script does not freeze the VM I use (Croquet Cog 4.0.2636 and the
> one contained in the Pharo 1.4 one click).
> > In fact, having an edge without line is perfectly okay. No error is
> raised and none should be raised. The line is simply invisible. Strange
> that you got this error.
> >
> > Anyone can reproduce this error?
> >
> > Cheers,
> > Alexandre
> >
> >
> > On Jan 25, 2013, at 10:37 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>
> wrote:
> >
> >
> >> Hi.
> >>
> >> When edges are initialized without lines, VM freezes.
> >>
> >> For instance when I run next code:
> >>
> >> | view node1 node2 edge |
> >> view := ROView new.
> >> node1 := ROLabel elementOn: 'node1'.
> >> node2 := ROLabel elementOn: 'node2'.
> >> node1 @ RODraggable.
> >> node2 @ RODraggable.
> >> edge := ROEdge from: node1 to: node2.
> >> rawView add: edge; add: node1; add: node2.
> >> ROHorizontalLineLayout on: (Array with: node1 with: node2).
> >> view open
> >>
> >>
> >> I know that you should do something like
> >>
> >> edge + (ROLine red).
> >>
> >> But Roasal shouldnt freeze the VM anyway :)
> >>
> >>
> >>
> >> --
> >> View this message in context:
> http://moose-dev.97923.n3.nabble.com/Roasal-freezing-VM-tp4025992.html
> >> Sent from the moose-dev mailing list archive at Nabble.com.
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >
> >
Hi.
When edges are initialized without lines, VM freezes.
For instance when I run next code:
| view node1 node2 edge |
view := ROView new.
node1 := ROLabel elementOn: 'node1'.
node2 := ROLabel elementOn: 'node2'.
node1 @ RODraggable.
node2 @ RODraggable.
edge := ROEdge from: node1 to: node2.
rawView add: edge; add: node1; add: node2.
ROHorizontalLineLayout on: (Array with: node1 with: node2).
view open
I know that you should do something like
edge + (ROLine red).
But Roasal shouldnt freeze the VM anyway :)
--
View this message in context: http://moose-dev.97923.n3.nabble.com/Roasal-freezing-VM-tp4025992.html
Sent from the moose-dev mailing list archive at Nabble.com.
Hi,
I am looking into testing the fix of Stef to go around the PharoTaskForces problem, but now I have another problem:
ConfigurationOfRoassal>>development is unloadable because version 1.266 needs to load RoassalMorphic-DR.108 which does not exist in the squeaksource repository.
Alex, can you look into this, please?
Cheers,
Doru
--
www.tudorgirba.com
"Presenting is storytelling."