Moose-dev May 2017

moose-dev@list.inf.unibe.ch

14 participants
15 discussions

[ann] bloc & cairo+morphic
by Tudor Girba 10 May '17

10 May '17

Hi, We are happy to announce that based on the work of Glenn, Alex extended Bloc (Sparta) to work directly in the Morphic world using Cairo as a backend. Cairo is less powerful than Moz2D (see the screenshot below for an example), but the implementation addresses a concern that the community raised regarding a perceived increased liability due to the dependency to Moz2D. Essentially this means that Bloc can be treated as another graphical library that can coexist with Morphic without requiring any external VM plugin. I would also like to point out that adding a new backend and host was possible because of the many iterations (including throwing away whole implementations) that Alex and Glenn went through. I think they did an amazing job. You can find a bit more details about Bloc here: http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/ Another issue raised regarding Bloc was that of the engineering effort required to make it a reality. That is why I would also like to announce that Alex joined feenk.com where he is primarily working on the graphical stack for Pharo. Cheers, Doru -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

9 10

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2017