Hi everyone.
I wander if there is any place I can read about the philosophy about how Moose is linked with a source code. I know that there are source anchors, and sourced entities. But as far as I can see, my entities do not have any anchors.
Right now I’m thinking that it would be cool to be able to browse a source code of any sourced entity that you have, but I’m not sure how this can be implemented.
Cheers,
Uko
Hi Folks,
I have been working on a tool to transform Rascal M3 models to Moose models. Although the work is far from complete, I presented the progress so far in the Software Composition seminar. The slides (with notes) are here:
http://www.slideshare.net/onierstrasz/m3-for-moose
The Rascal guys are planning to have lots of importers for different languages, so a fast path for M3 models into Moose would be very useful …
Thanks to Doru and Fabrizio for suggesting this path. (Before I tried to generate MSE from M3 within Rascal, but that was very painful and fragile.)
Cheers,
Oscar
PS: Does anyone know how to display presenter notes with slideshare presentations? Their web site says it works, but I can’t figure it out. (I converted my Keynote slides to PPT precisely so this would work, but it doesn’t.)
Hello,
I am looking for the alternatives to the MSE format for model persistency.
The current problems I see with MSE:
- It is all or nothing approach (hence loading takes time)
- need to add entities to model to be able to store them on the disk and
this approach does not work well when you want to persist duplication
information, caches and annotations.
There was a Fuel-based solution and I am wondering if it can be helpful.
While looking for persistency solutions for Pharo, I came across several
solutions like Voyage/Mongo, GLORP, StandStoneBD, and Magma.
http://www.seaside.st/documentation/persistence
Did anyone try any of these tools in the context Moose? I would do a pilot
(saving n retrieving a test model, playing with caches and properties) with
Voyage/Mongo to understand the impact of their usage.
Usman
Hi,
To smoothen the difference between builders and view, I added the following
method:
RTView>>view
"This method is meant to be used polymorphically with builders.
Thus, regardless of whether we get a raw view or a builder, we
can uniformly obtain the view"
^ self
This is particularly useful in situations like:
self act: [ :roassal | RTZoomOutMove on: roassal view view ]
icon: GLMUIThemeExtraIcons glamorousZoomOut
entitled: 'Zoom out'
Here roassal is either a view or a builder.
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Dear All,
Faviola is an astronomer specialist on molecular clouds (you know, the things were stars get born). Faviola is doing a postdoc with us. We have worked on AstroCloud, a tool on top of Roassal to visualise pictures of the Universe. It is still very early work, but this is truly exciting.
Some pictures of future stars are posted here:
https://www.facebook.com/ObjectProfile/posts/617975611622373
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Does anyone know if we have a working SVN client in Pharo?
I would need to be able to query a SVN repo to retrieve information from it.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Apparently HashTable package does not load correctly in recent Pharo
3, because of the introduction of the EyeInspector hierarchy.
HashTable define a HashTableInspector that was a subclass of
DictionaryInspector (now EyeDictionryInspector).
Should I define an issue for Moose 5.0 ?
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/