Perfect,
Thanks a lot Vincent :-)
Abdelghani
> On 23 May 2017, at 12:00, moose-dev-request(a)list.inf.unibe.ch wrote:
>
> Date: Mon, 22 May 2017 13:57:53 +0200
> From: Blondeau Vincent <vincent.blondeau(a)worldline.com <mailto:vincent.blondeau@worldline.com>>
> To: Moose-related development <moose-dev(a)list.inf.unibe.ch <mailto:moose-dev@list.inf.unibe.ch>>
> Subject: [Moose-dev] Re: unitary tests with moose models
> Message-ID:
> <55CFA91A8C333946A29A0E4F07F847390110548DB294(a)FRSPX100.fr01.awl.atosorigin.net <mailto:55CFA91A8C333946A29A0E4F07F847390110548DB294@FRSPX100.fr01.awl.atosorigin.net>>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Abdel,
>
> You can take a look in the package: Moose-Tests-SmalltalkImporter-LAN
>
> The Smalltalk code to import some code from the image is :
>
> model := MooseModel new.
> MoosePharoImporterTask new
> importerClass: SmalltalkImporter;
> model: model;
> addFromPackageNamed: #'Moose-TestResources-LAN';
> run;
> yourself.
>
> For the tests, I advise you to put your code sample in a separated package.
>
> Cheers,
> Vincent
Hi all,
I need to test few things on famix entities so I need my tests to load some model.
For instance:
testSomething
aMooseModel := loadModelFrom: somePackage.
…
what is the easiest way to do so?
Thanks in advance
Abdelghani
Hi,
It seems that my initial message generated a misunderstanding.
My original blog post was meant to communicate two things:
1. That the known Bloc project has received a new feature that the community raised as a problem (i.e., host & backend).
2. Address the other concern that the community raised: how to sustain the Bloc development in terms of engineering effort. This is why we announced the financial support for the work of Alex that is valid from this point on.
The post was certainly not intended to overlook the people that contributed to the overall project. I apologize if it looked like this.
To clarify the historical perspective, we now added an explicit history page on the official project page:
https://github.com/pharo-graphics/Bloc/blob/master/HISTORY.md
I also changed the blog post to more clearly communicate the intent:
http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
I hope this addresses the concerns. I am really excited that Alain joined and that we can get even more traction around Bloc.
Cheers,
Doru
> On May 12, 2017, at 7:56 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
>
> BTW for an historical perspective
>
> RMoD me and igor were also involved far less than the effort of alain but as he mentioned it we collaborated on it. I spent time on documenting several versions and I stopped disgusted to see the total lack of attention for comments.
> Then Rmod paid nearly a year of effort on Athens, SDL20 support, a year on TxText. I find really strange that we are not even mentioned in any support.
>
> Stef
>
>
> On Thu, May 11, 2017 at 8:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> Doru can you change the humane assessment blog post?
>
>
> On Thu, May 11, 2017 at 8:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> Indeed, this is wonderful news that you will rejoin your baby project :).
>
> Cheers,
> Doru
>
>
> > On May 11, 2017, at 6:40 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
> >
> > Hi Alain!
> >
> > Thanks for the mail (even if the historial part has always been pretty clear to me).
> > We miss you! Be back soon!
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >> On May 11, 2017, at 12:36 PM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote:
> >>
> >>
> >> From: Alain Plantec <alain.plantec(a)yahoo.com>
> >> Subject: Re: [Pharo-users] [ann] bloc & cairo+morphic
> >> Date: May 11, 2017 at 12:36:36 PM GMT-3
> >> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
> >> Cc: Alain Plantec <alain.plantec(a)yahoo.com>, Moose-related development <moose-dev(a)list.inf.unibe.ch>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
> >>
> >>
> >> Hello Doru, all,
> >>
> >> I’m really happy to see Bloc progresses.
> >> Even I’m not active since more than one year, Bloc is still an important project for me.
> >>
> >> but let me complete this short historical presentation a little bit.
> >>
> >> Bloc is a project that I initiated in 2013 in collaboration with RMOD following experiments made around the ROME project.
> >> The idea was to completely revisit the 2D framework of Pharo to address Morphic limits.
> >> Following an invitation of the Software Composition Group (thanks to Oscar Nierstrasz and to Doru here),
> >> I presented the first version of Bloc at Bern (March, 2015), then Doru and Aliaksel joined the project.
> >> One year ago, during his PhD at Brest, Glenn Cavarle produced a new version of the Bloc infrastructure that is now the
> >> one used together with the layouting system that was implemented by Aliaksel.
> >>
> >> Please, do not use the humane assessment web site but the github project one instead.
> >>
> >> I will restart working on Bloc/Brick soon in the context of a project that we recently signed with the Thales company.
> >>
> >> Thanks,
> >> Cheers
> >>
> >> Alain
> >>
> >>
> >>> On 8 mai 2017, at 23:00, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> >>>
> >>> 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.
> >>>
> >>> <bloc-two-backends-morphic-host-figures.png>
> >>>
> >>> 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."
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)list.inf.unibe.ch
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Yesterday is a fact.
> Tomorrow is a possibility.
> Today is a challenge."
>
>
>
>
>
>
>
--
www.tudorgirba.comwww.feenk.com
"Presenting is storytelling."
Hi Alain!
Thanks for the mail (even if the historial part has always been pretty clear to me).
We miss you! Be back soon!
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On May 11, 2017, at 12:36 PM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote:
>
>
> From: Alain Plantec <alain.plantec(a)yahoo.com>
> Subject: Re: [Pharo-users] [ann] bloc & cairo+morphic
> Date: May 11, 2017 at 12:36:36 PM GMT-3
> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
> Cc: Alain Plantec <alain.plantec(a)yahoo.com>, Moose-related development <moose-dev(a)list.inf.unibe.ch>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
>
>
> Hello Doru, all,
>
> I’m really happy to see Bloc progresses.
> Even I’m not active since more than one year, Bloc is still an important project for me.
>
> but let me complete this short historical presentation a little bit.
>
> Bloc is a project that I initiated in 2013 in collaboration with RMOD following experiments made around the ROME project.
> The idea was to completely revisit the 2D framework of Pharo to address Morphic limits.
> Following an invitation of the Software Composition Group (thanks to Oscar Nierstrasz and to Doru here),
> I presented the first version of Bloc at Bern (March, 2015), then Doru and Aliaksel joined the project.
> One year ago, during his PhD at Brest, Glenn Cavarle produced a new version of the Bloc infrastructure that is now the
> one used together with the layouting system that was implemented by Aliaksel.
>
> Please, do not use the humane assessment web site but the github project one instead.
>
> I will restart working on Bloc/Brick soon in the context of a project that we recently signed with the Thales company.
>
> Thanks,
> Cheers
>
> Alain
>
>
>> On 8 mai 2017, at 23:00, Tudor Girba <tudor(a)tudorgirba.com> wrote:
>>
>> 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.
>>
>> <bloc-two-backends-morphic-host-figures.png>
>>
>> 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."
>>
>>
>>
>>
>
>
>
>
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.comwww.feenk.com
"To lead is not to demand things, it is to make them happen."
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.comwww.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
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
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.!!!"
