Hi,
In the latest Moose when I export a model with source anchors they are
not exported right. If I have a class referencing the sourceAnchor, the
source anchor is exported one time as an element and one time as an
attribute of the class instead of using a ref.
To explicit the problem:
testSourcesAnchorsAreNotDuplicatedAfterExport
| model package tempFile importedModel |
model := MooseModel new name: 'Model'.
package := FAMIXPackage new
name: 'Package';
mooseModel: model;
yourself.
FAMIXClass new
name: 'Class';
container: package;
sourceAnchor:
(FAMIXSourceTextAnchor new
source: 'some text';
mooseModel: model;
yourself);
mooseModel: model.
tempFile := (FileSystem memory / 'export-test.mse') ensureCreateFile.
model exportToMSEStream: tempFile writeStream.
importedModel := MooseModel new importFromMSEStream: tempFile readStream.
self assert: importedModel size equals: model size
This test was added to Moose yesterday.
The change of behavior was introduced with the <container> pragma.
In the method FMRepositoryVisitor>>exportProperty:withAll:, the
sourceAnchor property is now detected as a composite and the branch used
to export the property is values do: [ :each | self exportElement: each
]. Before the introduction of the <container> pragma, the property was
not a composite and the branch executed was:
values do: [ :each |
(self isPrimitiveTypeOrObject: each)
ifTrue: [
printer referenceName: each name ]
ifFalse: [
printer referenceNumber: (self indexOf: each) ]]
I don't know the "composite" and "container" system of FAME enough to
know how to correct this problem now.
If someone knows the importer/exporter I would appreciate help with this
one.
https://github.com/moosetechnology/Moose/issues/1198
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
feenk.com is proud to announce gt4gemstone, a version of the Glamorous Toolkit aimed at supporting remote development with GemStone/S from Pharo. gt4gemstone is released as an open-source project under the MIT license and was built primarily by Andrei Chis with some marginal contributions from me.
The project is hosted at:
https://github.com/feenkcom/gt4gemstone
The toolkit currently offers several features:
• Remote Playground
• Remote Inspector with extensions that can be coded exactly like the ones in Pharo
• Remote Debugger with mixed stacks (Pharo and GemStone)
• Basic Remote Code Browser
• Remote Session Handler
• Integration with Roassal
• A Glamour-specific proxy model for efficient serialization of Glamour presentations
• A basic proxy model for working with any remote objects from GemStone
One particular aspect that we focused on is performance. So much so, that at one point inspecting objects in gt4gemstone was faster than doing them locally. In the meantime, the GT inspector from Pharo also received an upgrade.
But, perhaps the most exciting thing about this project is that most extensions of the inspector can be expressed exactly in the same way both in Pharo and in GemStone, and this makes the scenario of building in Pharo and deploying in GemStone even more appealing.
The official announcement with some extra details can be found here:
http://www.humane-assessment.com/blog/introducing-gt4gemstone/
Cheers,
Tudor
--
www.tudorgirba.comwww.feenk.com
"There are no old things, there are only old ways of looking at them."
May I ask:
Roassal and Pharo are really fantastic. I’m trying to get a grip on it and
use it. What makes me think:
In the introduction of the superb “Agile Visualization” book it is stated,
that the Roassal OO approach allows for visualizations that are “easily
extensible”. I guess compared to hand-crafted, imperative visualizations.
Let’s take an example: RTCalendarBuilder
I noticed that present visualization of week days start with Sunday as
first day of week. E.g. in Europe/Germany weeks start on Monday (according
ISO8601). We are visually so used to it, that other schemes make us think
(not intuitive).
How could I modify this?
P.S.: Especially in calendrical visualizations there will be many (local)
variations. So maybe it’s a good example to understand how to easily extend
Roassal in above and similar topics as an interested user.
BR Mike
Hi,
we have currently troubles with the slow CI, probably related to the Inria
network issues. The last Moose job took 42 min (I had to extend the time
limit)
-- Pavel
Dear mentors,
we are currently reviewing all the students proposals. Please join the
#gsoc-planning on Discord for giving your insights about the students.
The deadline for the final selection will be Monday 24th 6pm CEST.
As a reminder, we have 5 slots given by Google this year.
Regards,
--
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Hi,
in the latest Moose build the DeepTraverser package is in very old version
(DeepTraverser-StefanReichhart.10) but the recent one in
-StefanReichhart.39.
It looks like someone started to want stable version of the DeepTraverser
configuration instead of the development one. Does anyone know something
about that?
Cheers,
-- Pavel
Hello Moose-dev,
We recently had to work around the method
MooseGroupRuntimeStorage>>remove:ifAbsent:
And found its intention somehow not clear.
We understand that entities are stored into 3 different type of collection:
- elements
- byType
- byName
When we remove an element from the group storage, we want to remove the
element from each of the 3 collections.
A tricky case is for byName dictionary:
in some cases, an element may not have been registered to the byName
dictionary because it does not have a unique moose name (see methods #
*updateCacheFor: *#*hasUniqueMooseNameInModel*)
The current implementation of #remove:ifAbsent: does not really consider
this specific case.
As soon as an element is not found in the byName dictionary, the exception
block is executed.
More generally, we could have expected a distinction between
- inconsistent absence of an element in one of the collection. This would
raise an error.
- consistent absence of an element in all the collection. This would
execute the exception block.
With this consideration, the method could be something like:
*remove: anElement ifAbsent: exceptionBlock *
| key group |
elements remove: anElement ifAbsent: [ ^exceptionBlock value ].
key := anElement class.
group := byType
at: key
ifAbsent: [ OrderedCollection new ].
group
remove: anElement
ifAbsent: [ *self error: 'Internal storage inconsistency'* ].
anElement *hasUniqueMooseNameInModel* ifTrue:
[ "In theory, objects are registered under their mooseName,
however some objects are still registered by their name
if #resetMooseName was not used when needed"
key :=anElement mooseName asSymbol.
byName at: key ifAbsent: [ self resetMooseNameFor: anElement ].
byName
removeKey: key
ifAbsent: [ *self error: 'Internal storage inconsistency'* ] ].
^anElement
What do you think ?
--
Cyrille Delaunay
Hi everyone!
I find the MSE export time far too long in Pharo. I dug up a little in
the export algo and found two problems. The first one is easy to
improve. The second one less.
First problem: FMRepository>>elements.
This method transform an IdentitySet to an Array with the #asArray
method. This takes ~40% of the export time in a small model (5Mo of Java
sources).
This #elements method is called by the method #includes: of FMRepository
and FMMetaRepository. I propose to change those #includes: methods to
use the variable `elements` instead of the getter. It should not change
anything since the result of an #includes: on an Array and an
IdentitySet should be the same.
Second problem: the progress bar
Usually a progress bar is used via an iteration on a collection and it
update the bar each 200ms. During the export it is not done that way and
the bar is managed "manually" because we do not have one iteration. I
think it is done far more time than each 200ms and at the end ~15-20% of
the export time is spent in the progress bar update. This is far too much.
For now, I don't know how to improve this part without changing the
actual behavior of the export. If I have time I'll try to improve this
part of the export too.
Have a good day.
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
In the context of my software design course, a student did a small project
to combine Moose and the Java design pattern detection tool (patterns4.jar)
from professor Tsantalis at Concordia university. The code and more
detailed explanation is on GitHub at https://github.com/tebo93/PatternParser
I offered as an optional lab exercise in my course to experiment with
Pharo/Moose and there were a small number of students fervently interested.
Here's a semi-accurate explanation of the workflow in a UML Activity
Diagram, using PlantUML:
[image: Inline image 1]
Link to PlantText.com for this image
<https://www.planttext.com/?text=HO-z3e9048JxVOeD5JOKnWeQ_4qq44reQ2msS2W8T-J…>
Cheers,
C. Fuhrman
Hi,
I have a small GTInspector extension that shows me a tree-like structure of a graph. As the data underneath are graphs, the tree itself is infinite (because there are loops).
That by itself works fine (because only roots are expanded), however when I am filtering the elements (in raw pane), GTInspector gets stuck in infinite GLMTreeMorphNodeModel>>pathIn: loop.
I've made couple of classes to reproduce the behavior - see attached file.
There are two types of nodes: one contains children (items), and the other can contain references to other elements.
The extension is written in LLCompositeElement>>gtInspectorTreeIn:
To reproduce:
1. import attached package
2. execute the following
```
'<a>
<b ref c />
<c ref b />
</a>'.
a := LLCompositeElement named: 'a'.
b := LLReferenceElement named: 'b'.
c := LLReferenceElement named: 'c'.
a items: { b . c }.
b references: { c }.
c references: { b }.
a inspect.
```
3. the Tree view works fine (I see some visual glitching of arrows, but that doesn't matter)
4. switch to Raw view
5. (any of these will trigger the behaivor)
5.a. click on "items" instance variable, or
5.b. "do it and go" any expression (e.g. 1+1)
6. now you are in infinite pathIn: loop
Sometimes I've experienced that breaking the loop (meta+.), closing the debugger and redoing the expression worked... but I don't have any details about that.
Thanks!
Peter
