Andrei asked me to post about XMLParser's GT enhancements.
Syntax highlighting has been extended to element, attribute, and declaration names. The colors are customizable and initially come from your Shout theme.
When inspecting a DOM node, the "Source" tab now supports dynamic editing of the DOM node's XML source code. The edited source can be accepted to change the node and optionally saved to a file. Not every node can be edited (for example, internal subset declarations).
The "Remove" action deletes a node from its DOM tree. Not every node can be removed (for example, root nodes).
If the XPath library is installed, the "XPath" tab can be used to evaluate XPath expressions with the inspected DOM node as the context node. The XPath syntax highlighting colors are also customizable and initially come from your shout theme.
Hi,
I am happy to announce that O’Reilly has published my Steering Agile Architecture video training:
http://www.humane-assessment.com/blog/steering-agile-architecture-video-tra…
This video is based on my work on humane assessment, and it features Moose prominently. It also shows Pharo, GT and Roassal (in the last part).
The video is indeed paid and it is mainly targeted to people that have a Safari Books Online subscription. But, the interesting thing about it is that it opens Pharo and Moose to a new kind of an audience, O’Reilly being the most prominent publishing company in the software area.
Agile architecture is considered a prominent topic but the literature (until now) was rather loose at how to make it really work in practice. This course offers both a concrete approach based on humane assessment. As you might know, humane assessment centers around the idea of building tools cheaply as a way to figure the system out, and this is right now pretty much only practicable in Moose and Pharo.
One thing that I ask people when I go to conferences, the last one being the Software Architecture Conference organized by O’Reilly, is if they like working with legacy systems. They actively dislike it. Then I show them demos of how it can be like and then I ask them if they think these demos are cool. And I never encountered one that did not find it cool. So, in a way, we can now be quite confident in saying that we work on the single platform that makes working with an existing system cool. Not a small feat.
So, if you do get the chance to look at these things, you might also get a concrete inspiration of how to leverage Pharo skills within companies that do not yet work with Pharo.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Presenting is storytelling."
Hi!
There is a tab called ‘Problems’ when inspecting an example. Any idea why?
Inspecting this GTExampleError says something like: MessageNotUnderstood: RTExampleSelection>>methodResolver
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
May I ask: I’m trying to understand how to use RTCalendarBuilder in own,
adapted calendar visualization, I read the chapter about builders in the
book and started to look at:
exampleMonth
| b |
b := RTCalendarBuilder new.
b dates: (Month current to: Month current next).
b build.
^ b view
Is the month layout finally implemented in RTSVGPath in monthShapePath?
How could one change month visualization and:
- start weeks on Monday instead of Sunday
- change color of day figure or background color based on criteria (e.g.
weekend …)
Only meant as example. Would I need to change SVGPaths or are there higher
level methods?
BR Mike
Hello Moosers,
At synectique, we subclassed some FAMIX classes in order to provide our own
specific behavior and to modelize some language specifities.
In this context, we are facing cases where several properties in the FAMIX
hierarchy point to the same opposite.
Fame complains about that, and raises an error when exporting the mse.
Sometimes, this kind of error helps us to highlight inconsistencies in the
implementation of our meta model,
but some other times, we would like to be more tolerant, and allow a
property to define several "type" classes,
which has for consequence that each of these "type" classes will define the
same opposite.
This cases mainly occur when working around famix single inheritance limits.
A workaround I have thought about is that when defining such a duplicate
opposite,
we could inform fame that we don't want this definition to raise a
validation error.
For example, adding a pragma such as <alternateOpposite>, that would be
considered by the fame pragma processor when validating the model.
Does this behavior has any interest for moose in general ?
Would you have other suggestions ?
Should we keep this new behavior in our own Pragma processor class ?
If yes, may I factorize the references to MoosePragmaProcessor in the code
of moose ?
--
Cyrille Delaunay
Hi all,
Moose crashes when selecting an example from the Roassal examples browser
(I tried several examples and it always crashes). This happens in the
latest Moose 6.1 development image (dump file here
<https://dl.dropboxusercontent.com/u/80292510/crash.dmp>).
Then, when installing Moose in a clean Pharo5 image the following warning
pops up:
[image: Inline images 1]
I selected "Proceed" to continue the installation, but a second warning
appears after some seconds:
[image: Inline images 2]
Finally, Moose is installed and Roassal examples seem to work fine.
Best regards,
Leonel Merino
PhD student
University of Bern
+41 78 405 43 38
merino(a)inf.unibe.ch
Hi!
We are doing a survey about Roassal. Giving about 2 minutes of your time to fill the survey can have a tremendous impact on it.
https://goo.gl/forms/zEt7VdkLSYvBG6jf2
Help us improving Roassal :-)
The Object Profile team
Hi,
I need to move an application build in Pharo 4 using Moose Chef to Pharo
5 and Moose Query.
I would like to know if there is documentation about Moose Chef and
Moose Query somewhere?
I wanted to check the moose book but I can only find the new one with an
empty query section.
Is the old moose book still somewhere?
Thank you in advance.
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
With Cyril, we discovered that MooseEntity >> children behavior is not as expected. It collects all the items defined in the meta meta model: not only the children but the parents too...
childrenEntities should be used instead and consequently TMetaLevelDependency should be defined on MooseEntity.
Moreover, #children is also defined on the subclasses of FAMIXScopingEntity as a "Polymorphic accessor to children of this scope in a hierarchical structure (package->subpackages, scope->subscopes)".
Cyril and I suggest to deprecate these 3 methods (in FAMIXScopingEntity, FAMIXNamespace, FAMIXPackage) to "childrenOfMyKind", and to change in FAMIXPackage, isKindOf: in allWithSubTypeOf:.
Cyril will do the changes next week.
Cheers,
Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
Hello Moose !
With the current memory limit of Pharo,
and the size of the generated moose models being potentially huge,
maybe some of you already though about (or even experimented) persistence
solutions with query mechanisms that would instantiate famix objects only
“on demand”,
in order to only have part of a model in memory when working on a specific
area.
If so, I would be really interested to hear about (or play with) it :)
At first look, I see that there is a MooseGroupStorage class.
This kind of object answers to some usual collection messages (add, remove,
select, detect, .. ).
I guess that when we perform queries over a moose model,
when we add or remove entity objects,
we end up using this protocol.
So, if I wanted to implement a database persistence solution for moose,
my first feeling would be to implement a specific kind of
“MooseGroupStorage”,
and to plug there a communication layer with a database.
Does it make sense ?
I have not played with moose since a long time
(but I am back to play with it a lot more :))
and my vision on things may be naive.
So do not hesitate to tell me if what I am saying sounds crazy,
and to push me back on the right path !
Does anyone already thought about solutions to deal with memory limits when
generating big moose models ?
--
Cyrille Delaunay
