Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

moose & the dark theme
by Tudor Girba 08 May '17

08 May '17

Hi, As you could see, in Pharo we turned the Dark Theme on by default. The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons: - they were conceived on a white canvas - the colors are hardcoded Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo. What do you think? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

8 28

Problem during export of MSE (SourceAnchor duplicated)
by Cyril Ferlicot D. 05 May '17

05 May '17

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

1 0

[ann] gt4gemstone
by Tudor Girba 03 May '17

03 May '17

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.com www.feenk.com "There are no old things, there are only old ways of looking at them."

2 3

RTCalendarBuilder
by Markus Böhm 02 May '17

02 May '17

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

3 6

slow CI
by Pavel Krivanek 24 Apr '17

24 Apr '17

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

1 0

GSOC Mentors - We need you.
by Serge Stinckwich 22 Apr '17

22 Apr '17

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/

1 0

DeepTraverser in very old version
by Pavel Krivanek 22 Apr '17

22 Apr '17

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

3 4

Removing elements from GroupStorage
by Cyrille Delaunay 19 Apr '17

19 Apr '17

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

1 0

Improvement of the MSE export time
by Cyril Ferlicot D. 19 Apr '17

19 Apr '17

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

2 4

Moose with patterns4.jar (Tsantalis)
by Cris Fuhrman 15 Apr '17

15 Apr '17

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

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev