simon can you open bug entry for pharo?
Stef
>> Hi,
>>
>> I just tried creating a new image, but there is a problem with traits definition:
>> http://hudson.moosetechnology.org/job/moose-latest-dev/370/console
>>
>> Could you take a look?
>
>
> Re-argh, same problem, renaming a trait does not make a package dirty by default, and I didn't check for external users of traits (now I know how to do that :()
> Fixed in Famix-Extensions and DSM.
>
> Can you try again?
>
>
>>
>> Cheers,
>> Doru
>>
>>
>> On 28 Sep 2010, at 17:20, Simon Denier wrote:
>>
>>>
>>>
>>> It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow.
>>>
>>>
>>>
>>> On 28 sept. 2010, at 13:01, Simon Denier wrote:
>>>
>>>>
>>>> On 28 sept. 2010, at 09:11, Tudor Girba wrote:
>>>>
>>>>> Hi Simon,
>>>>>
>>>>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :).
>>>>
>>>>
>>>> Argh, never thought I could still be bitten by the non-dirty package bug in MC :(
>>>>
>>>> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes.
>>>>
>>>>
>>>> As for the prefix, I will take Mal, just because fireflies do not bite (...)
>>>>
>>>>
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> On 27 Sep 2010, at 22:00, Tudor Girba wrote:
>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>>>>>>
>>>>>>>
>>>>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>>>>>>>
>>>>>>>> Please note that the MA* (with an uppercase $A) prefix is already
>>>>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>>>>>>>> remember correctly they renamed their classes at some point a long
>>>>>>>> time ago to avoid the conflict with Magritte.
>>>>>>>
>>>>>>>
>>>>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
>>>>>>>
>>>>>>> but at least now there is some consistency in class names.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Lukas
>>>>>>>>
>>>>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>>>>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>>>>>>>>
>>>>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lukas Renggli
>>>>>>>> www.lukas-renggli.ch
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Not knowing how to do something is not an argument for how it cannot be done."
>>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Be rather willing to give than demanding to get."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 23 sept. 2010, at 10:30, Mariano Martinez Peck wrote:
> Hi Folks...Sorry for the "urgen" but I got an idea for my paper with deadline tomorro hahahahah
>
> I was using DistributionMaps where the containers were packages for example, elements classes, and properties the amount of instances. For example, see the attached screenshot.
>
> Now....it is difficult to find the classes with most instances since I need to search for an specific color.
I am not sure I understand what it is difficult:
- because the mapping color <-> range does not match your expectations (like red would be highest, blue would be lowest)
- or because you are looking for one class with the most instances
- or because you want to compare the real values, not ranges.
>
> I thoguht that having someting like CodeCity can be interesting. I would like:
>
> - EAch building (square) is a container -> package
> - Each little squeare (that has heigh) is a element -> class
> - The heigh is a property, in this case, the amount of instances for example.
>
> Then I can easily see packages/classes with several intances easily (the highest ones).
>
> So...is that possible? how easier? :)
>
> Right now I was doing my DM something like this:
>
> I checked for *City* class in Moose 4.1 but I didn't find anything :(
>
> The only thing I found was this link: http://www.moosetechnology.org/tools/vw/codecity
>
> Thanks for any help
>
> Mariano
> <amuntUsedInstances.png>_______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 28 sept. 2010, at 22:51, Tudor Girba wrote:
> Great, now it's all fine:
> http://hudson.moosetechnology.org/job/moose-latest-dev/
>
> I just had to fix a missing refactoring in Famix-Extensions.
Good, apparently I was a bit careless with the refactoring in Ma Graph (well the image hung up, I had to restart and probably forgot to commit)
>
> Cheers,
> Doru
>
>
> On 28 Sep 2010, at 21:46, Simon Denier wrote:
>
>>
>> On 28 sept. 2010, at 20:57, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> I just tried creating a new image, but there is a problem with traits definition:
>>> http://hudson.moosetechnology.org/job/moose-latest-dev/370/console
>>>
>>> Could you take a look?
>>
>>
>> Re-argh, same problem, renaming a trait does not make a package dirty by default, and I didn't check for external users of traits (now I know how to do that :()
>> Fixed in Famix-Extensions and DSM.
>>
>> Can you try again?
>>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 28 Sep 2010, at 17:20, Simon Denier wrote:
>>>
>>>>
>>>>
>>>> It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow.
>>>>
>>>>
>>>>
>>>> On 28 sept. 2010, at 13:01, Simon Denier wrote:
>>>>
>>>>>
>>>>> On 28 sept. 2010, at 09:11, Tudor Girba wrote:
>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :).
>>>>>
>>>>>
>>>>> Argh, never thought I could still be bitten by the non-dirty package bug in MC :(
>>>>>
>>>>> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes.
>>>>>
>>>>>
>>>>> As for the prefix, I will take Mal, just because fireflies do not bite (...)
>>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> On 27 Sep 2010, at 22:00, Tudor Girba wrote:
>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>>>>>>>>
>>>>>>>>> Please note that the MA* (with an uppercase $A) prefix is already
>>>>>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>>>>>>>>> remember correctly they renamed their classes at some point a long
>>>>>>>>> time ago to avoid the conflict with Magritte.
>>>>>>>>
>>>>>>>>
>>>>>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
>>>>>>>>
>>>>>>>> but at least now there is some consistency in class names.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Lukas
>>>>>>>>>
>>>>>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>>>>>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>>>>>>>>>
>>>>>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Simon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Lukas Renggli
>>>>>>>>> www.lukas-renggli.ch
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>> --
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "Not knowing how to do something is not an argument for how it cannot be done."
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Be rather willing to give than demanding to get."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Problem solving efficiency grows with the abstractness level of problem understanding."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 28 sept. 2010, at 20:57, Tudor Girba wrote:
> Hi,
>
> I just tried creating a new image, but there is a problem with traits definition:
> http://hudson.moosetechnology.org/job/moose-latest-dev/370/console
>
> Could you take a look?
Re-argh, same problem, renaming a trait does not make a package dirty by default, and I didn't check for external users of traits (now I know how to do that :()
Fixed in Famix-Extensions and DSM.
Can you try again?
>
> Cheers,
> Doru
>
>
> On 28 Sep 2010, at 17:20, Simon Denier wrote:
>
>>
>>
>> It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow.
>>
>>
>>
>> On 28 sept. 2010, at 13:01, Simon Denier wrote:
>>
>>>
>>> On 28 sept. 2010, at 09:11, Tudor Girba wrote:
>>>
>>>> Hi Simon,
>>>>
>>>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :).
>>>
>>>
>>> Argh, never thought I could still be bitten by the non-dirty package bug in MC :(
>>>
>>> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes.
>>>
>>>
>>> As for the prefix, I will take Mal, just because fireflies do not bite (...)
>>>
>>>
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 27 Sep 2010, at 22:00, Tudor Girba wrote:
>>>>
>>>>> Hi Simon,
>>>>>
>>>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>>>>>
>>>>>>
>>>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>>>>>>
>>>>>>> Please note that the MA* (with an uppercase $A) prefix is already
>>>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>>>>>>> remember correctly they renamed their classes at some point a long
>>>>>>> time ago to avoid the conflict with Magritte.
>>>>>>
>>>>>>
>>>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
>>>>>>
>>>>>> but at least now there is some consistency in class names.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Lukas
>>>>>>>
>>>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>>>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>>>>>>>
>>>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lukas Renggli
>>>>>>> www.lukas-renggli.ch
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Not knowing how to do something is not an argument for how it cannot be done."
>>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Be rather willing to give than demanding to get."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow.
On 28 sept. 2010, at 13:01, Simon Denier wrote:
>
> On 28 sept. 2010, at 09:11, Tudor Girba wrote:
>
>> Hi Simon,
>>
>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :).
>
>
> Argh, never thought I could still be bitten by the non-dirty package bug in MC :(
>
> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes.
>
>
> As for the prefix, I will take Mal, just because fireflies do not bite (...)
>
>
>>
>> Cheers,
>> Doru
>>
>>
>> On 27 Sep 2010, at 22:00, Tudor Girba wrote:
>>
>>> Hi Simon,
>>>
>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>>>
>>>>
>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>>>>
>>>>> Please note that the MA* (with an uppercase $A) prefix is already
>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>>>>> remember correctly they renamed their classes at some point a long
>>>>> time ago to avoid the conflict with Magritte.
>>>>
>>>>
>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
>>>>
>>>> but at least now there is some consistency in class names.
>>>>
>>>>
>>>>>
>>>>> Lukas
>>>>>
>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>>>>>
>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>>>>>
>>>>>>
>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>>>>>
>>>>>> --
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lukas Renggli
>>>>> www.lukas-renggli.ch
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Not knowing how to do something is not an argument for how it cannot be done."
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Be rather willing to give than demanding to get."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
--
Simon
On 28 sept. 2010, at 15:16, Guillermo Schwarz wrote:
> Hi Guys,
>
> Why don't you do something more focused on the long term and don't you change the Smalltalk compiler with namespaces?
As you said, it's something for long-term....
Meanwhile, I'm just putting some pressure on our daily tools (Moose + OR) and it's also good :)
>
> I don't think it should be that hard since each class already belongs to a category. Each category could instead be a dictionary from where the compiler could find classes that are mentioned in the class source.
>
> This has worked wonders in Java (classes inside packages). This way classes' names can be repeated ad eternum without generating collisions or otherwise polluting excessively the name space.
>
> So for example:
>
> FAMIXAssociation subclass: #FAMIXInvocation
> instanceVariableNames: 'sender receiver receiverSourceCode signature candidates'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Famix-Core'
>
> Would be instead:
>
> Association subclass: #Invocation
> instanceVariableNames: 'sender receiver receiverSourceCode signature candidates'
> classVariableNames: ''
> poolDictionaries: ''
> category: #FamixCore
>
> Then the category would be an index in the SystemDictionary:
>
> SystemDictionary at: #FamixCore put: Category new.
>
> (SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this should be done automatically by the subclass: method above"
>
> (SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that are referenced by classes belonging to category #FamixCore"
>
> What do you think?
>
> Cheers,
> Guillermo.
>
> Message: 1
> Date: Mon, 27 Sep 2010 22:00:33 +0200
> From: Tudor Girba <tudor.girba(a)gmail.com>
> Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Simon,
>
> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>
> Cheers,
> Doru
>
>
> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>
> >
> > On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
> >
> >> Please note that the MA* (with an uppercase $A) prefix is already
> >> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
> >> remember correctly they renamed their classes at some point a long
> >> time ago to avoid the conflict with Magritte.
> >
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hi,
I moved all code from Moose-MondrianScripts to Moose-
MondrianPaintings, and I removed the Moose-MondrianScripts from the
configuration.
I would like to work slowly on package restructuring. In the
following, I would like to rename the test packages:
Moose-LAN -> Moose-TestResources-LAN
Famix-LANTests -> Moose-Tests-SmalltalkImporter-LAN
MooseKGB-TestFamix3 -> Moose-Tests-KGB
Moose-KGB-* -> Moose-TestResources-KGB-*
Moose-SmalltalkImporterTests -> Moose-Tests-SmalltalkImporter
Moose-Test-PackageOne -> Moose-TestResources-Reference-PackageOne
Moose-Test-PackageTwo -> Moose-TestResources-Reference-PackageTwo
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
On 28 sept. 2010, at 13:05, Tudor Girba wrote:
>
>> As for the prefix, I will take Mal, just because fireflies do not bite (...)
>
> Great, although I am not sure I understand the word play :)
http://en.wikipedia.org/wiki/Malcolm_Reynolds
Hehe, I hope some people in the wave got it pretty easily :D
--
Simon
On 28 sept. 2010, at 09:11, Tudor Girba wrote:
> Hi Simon,
>
> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :).
Argh, never thought I could still be bitten by the non-dirty package bug in MC :(
So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes.
As for the prefix, I will take Mal, just because fireflies do not bite (...)
>
> Cheers,
> Doru
>
>
> On 27 Sep 2010, at 22:00, Tudor Girba wrote:
>
>> Hi Simon,
>>
>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>>
>> Cheers,
>> Doru
>>
>>
>> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>>
>>>
>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>>>
>>>> Please note that the MA* (with an uppercase $A) prefix is already
>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>>>> remember correctly they renamed their classes at some point a long
>>>> time ago to avoid the conflict with Magritte.
>>>
>>>
>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
>>>
>>> but at least now there is some consistency in class names.
>>>
>>>
>>>>
>>>> Lukas
>>>>
>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>>>>
>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>>>>
>>>>>
>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>>>>
>>>>> --
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lukas Renggli
>>>> www.lukas-renggli.ch
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Not knowing how to do something is not an argument for how it cannot be done."
>>
>
> --
> www.tudorgirba.com
>
> "Be rather willing to give than demanding to get."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
> Please note that the MA* (with an uppercase $A) prefix is already
> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
> remember correctly they renamed their classes at some point a long
> time ago to avoid the conflict with Magritte.
ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that...
but at least now there is some consistency in class names.
>
> Lukas
>
> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote:
>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...)
>>
>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references.
>>
>>
>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them.
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 27 sept. 2010, at 12:04, Tudor Girba wrote:
> If you use the GLMUITheme, you will see a nice down arrow.
Yes but :)
1) I don't like the Glamorous theme, sorry
2) and I still think it does not work, as the arrow is at the level of the window buttons, not at the toolbar level for actions - so it's not a place someone would go easily to look for actions.
>
> Doru
>
>
>
> On 27 Sep 2010, at 11:47, Simon Denier wrote:
>
>>
>> On 27 sept. 2010, at 11:21, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> Indeed, I forgot to announce that. The textual menu was moved in the window menu (the icon on the top right).
>>
>>
>> ah ok :)
>>
>> I never use that menu, and I'm not sure other people takes a look at it. Actually I have a different expectation for this bytton: its common behaviour on MacOs is to hide/show the toolbar. So is it a wise choice?
>>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 27 Sep 2010, at 11:01, Simon Denier wrote:
>>>
>>>>
>>>> With the latest update of Glamour, I don't have anymore the toolbar menu entitled '...' with the iconless actions. (in MoosePanel and the MetaBrowser)
>>>>
>>>> Sorry, I didn't have time to check deeper.
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "There are no old things, there are only old ways of looking at them."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hi,
We are happy to announce the first version of Glamour on Seaside. This work was carried out by Andrei Vasile Chis and was sponsored by ESUG. The project offers a Seaside-based rendering of Glamour browsers. In other words, once you have a browser in Glamour, you can now simply display it on the web.
You can obtain the code in two ways:
- Nightly built image:
http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/lastSucces…
- Metacello configuration loadable in Pharo 1.1 (not Core)
Gofer new
squeaksource: 'Glamour';
package: 'ConfigurationOfGlamourSeaside';
load.
(Smalltalk at: #ConfigurationOfGlamourSeaside) loadDefault.
A couple of examples are available on the Moose server:
http://online.moosetechnology.org/glamour/basicExamples (a number of example browsers)
http://online.moosetechnology.org/moose/metaBrowser (a browser for the meta-model of Moose)
Several developments are planned for the near future, so stay tuned for more news.
We would highly appreciate any kind of feedback.
Cheers,
Andrei and Doru
On 27 sept. 2010, at 11:21, Tudor Girba wrote:
> Hi,
>
> Indeed, I forgot to announce that. The textual menu was moved in the window menu (the icon on the top right).
ah ok :)
I never use that menu, and I'm not sure other people takes a look at it. Actually I have a different expectation for this bytton: its common behaviour on MacOs is to hide/show the toolbar. So is it a wise choice?
>
> Cheers,
> Doru
>
>
> On 27 Sep 2010, at 11:01, Simon Denier wrote:
>
>>
>> With the latest update of Glamour, I don't have anymore the toolbar menu entitled '...' with the iconless actions. (in MoosePanel and the MetaBrowser)
>>
>> Sorry, I didn't have time to check deeper.
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
With the latest update of Glamour, I don't have anymore the toolbar menu entitled '...' with the iconless actions. (in MoosePanel and the MetaBrowser)
Sorry, I didn't have time to check deeper.
--
Simon
I'm preparing the doc about metamodeling in Moose using Fame, but that's using the regular code browser en refactoring browser. Right now there are some consistency validation of metamodel described in Lint rules.
So there is place for a UI editor + validation.
On 25 sept. 2010, at 11:24, François Tanguy wrote:
> Hi,
>
> being a end user, I am bit confused with these 2 frameworks: Fame and Magritte.
> There are both meta-meta-models. So what make them different from a conceptual point of view ?
>
> For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte).
>
> Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description.
>
> Any info on this would be appreciated.
>
> Thanks.
>
> Francois
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Simon
Ok I see your point.
What would be nice is to see how you could have fame and the core of Magritte merged so that
we can use
Fame
and
Magritte could be build/described using Fame
this way we could use Fame serialization
for famix
but also magritte
So may be this is the time to have Magritte 3 based on pragmas and using Fame/magritte core as Magritte3 Core
Stef
>
> Le 25 sept. 2010 à 21:50, Stéphane Ducasse a écrit :
>
>>
>> On Sep 25, 2010, at 9:20 PM, François Tanguy wrote:
>>
>>> Would it be a good idea to have a bridge between the two ?
>>
>> I do not know what is your scenario?
>
> I would like to edit models in the web browser with seaside components generated with Magritte and save the models using Fame.
>
>>
>>> Like generating magritte descriptions from the Fame pragmas.
>>
>> do you have an example?
>> because you mean describing Magritte in fame?
>
> I am just wondering why I must use two languages to describe a metamodel with constraints.
> If I want to express a language structure I must use Fame (to have package, classes, properties).
> If I want to add constraints I must use Magritte.
> But when I define Magritte descriptions, I feel like I rewrite the same stuff I did in Fame (except for the validation part).
>
>>
>>> Then we could imagine to have a generic editor for a metamodel and serialization... (like in EMF)
>>
>> fame already support the functionality of EMF.
>> I think that Fame should stay a simple metametamodel.
>>
>
> Yes, but it is still missing editing tools compared to EMF, or am I wrong ?
>
>>
>>> I wrote a very basic piece of code that does the transformation from Fame to Magritte in some very specific use case and that is something that is definitely possible.
>>>
>>> What do you think ?
>>
>> I do not know. what is your need?
>
> I want to describe a language only one time and be able to use tools from Fame and Magritte.
> So with a minimal amount of work, I get serialization, edition, validation, code generation.
>
>>
>> Stef
>>
>>>
>>> Le 25 sept. 2010 à 11:49, Stéphane Ducasse a écrit :
>>>
>>>> here is my summary
>>>> fame is a minimal meta meta model ( 4 or 5 classes): we use it describe other model (such as Famix)
>>>> based on fame you can load and save model.
>>>>
>>>> Magritte is a meta data driven framework.
>>>> you describe specific entity and the tools interpret it.
>>>>
>>>> On Sep 25, 2010, at 11:24 AM, François Tanguy wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> being a end user, I am bit confused with these 2 frameworks: Fame and Magritte.
>>>>> There are both meta-meta-models. So what make them different from a conceptual point of view ?
>>>>>
>>>>> For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte).
>>>>>
>>>>> Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description.
>>>>>
>>>>> Any info on this would be appreciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Francois
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> Pharo-project(a)lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Sep 25, 2010, at 9:20 PM, François Tanguy wrote:
> Would it be a good idea to have a bridge between the two ?
I do not know what is your scenario?
> Like generating magritte descriptions from the Fame pragmas.
do you have an example?
because you mean describing Magritte in fame?
> Then we could imagine to have a generic editor for a metamodel and serialization... (like in EMF)
fame already support the functionality of EMF.
I think that Fame should stay a simple metametamodel.
> I wrote a very basic piece of code that does the transformation from Fame to Magritte in some very specific use case and that is something that is definitely possible.
>
> What do you think ?
I do not know. what is your need?
Stef
>
> Le 25 sept. 2010 à 11:49, Stéphane Ducasse a écrit :
>
>> here is my summary
>> fame is a minimal meta meta model ( 4 or 5 classes): we use it describe other model (such as Famix)
>> based on fame you can load and save model.
>>
>> Magritte is a meta data driven framework.
>> you describe specific entity and the tools interpret it.
>>
>> On Sep 25, 2010, at 11:24 AM, François Tanguy wrote:
>>
>>> Hi,
>>>
>>> being a end user, I am bit confused with these 2 frameworks: Fame and Magritte.
>>> There are both meta-meta-models. So what make them different from a conceptual point of view ?
>>>
>>> For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte).
>>>
>>> Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description.
>>>
>>> Any info on this would be appreciated.
>>>
>>> Thanks.
>>>
>>> Francois
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
here is my summary
fame is a minimal meta meta model ( 4 or 5 classes): we use it describe other model (such as Famix)
based on fame you can load and save model.
Magritte is a meta data driven framework.
you describe specific entity and the tools interpret it.
On Sep 25, 2010, at 11:24 AM, François Tanguy wrote:
> Hi,
>
> being a end user, I am bit confused with these 2 frameworks: Fame and Magritte.
> There are both meta-meta-models. So what make them different from a conceptual point of view ?
>
> For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte).
>
> Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description.
>
> Any info on this would be appreciated.
>
> Thanks.
>
> Francois
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 sept. 2010, at 23:19, Mariano Martinez Peck wrote:
> Hi Simon: print or inspect the result of something like this:
>
> (ConfigurationOfXXX project version: 'xxx') record loadDirective
>
> or if you use groups or packages in the load:
>
> ((ConfigurationOfXXX project version: 'xxx') record: 'Tests') loadDirective
>
> with that you can notice what you need
OK thanks Mariano, I thought there was such a mechanism but I was not sure. However I was not able to find the culprit. And now it loads fine with just the fix for PetitParser config?
>
> cheers
>
> ps: I learn about #record in our own Metacello talk at ESUG with Dale hahahhaha
Well I was taking pictures in Barcelona at the time, so I don't have a good excuse either :)
>
>
> On Fri, Sep 24, 2010 at 5:44 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote:
> OK, I just had this problem today, not previously during the week, and I can't find the source.
>
> When updating my Moose image I got:
>
> Loading default of ConfigurationOfMoose... <connection closed>
> Fetched -> Famix-ManifestMf-tg.6 --- http://www.squeaksource.com/Moose --- http://www.squeaksource.com/Moose
> Project: MooseAlgos for Moose default
> Project: PetitParser for Moose default
> Project: Glamour for Petit 2.0-beta.7
> Fetched -> Morphic-MorphTreeWidget-AlainPlantec.88 --- http://www.squeaksource.com/Momo10 ---
> (....)
>
>
> Two strange things going on:
> - PetitParser default requiring Glamour for Petit 2.0-beta.7 (probably a bug when the config was copied to the Moose repo for the 4.0 release. This is now fixed)
> - Morphic-MorphTreeWidget-AlainPlantec.88 got fetched, I have no idea how/which project required this package which dates back to january 2010 (it's not Glamour 2.0-beta.7)
>
>
> Can anyone reproduce this problem, starting from a 4.1 release then updating to default? Or starting fresh and loading default?
>
>
> Dale, I think I have another use case for the Metacello browser, it's being able to debug such a case, by simulating/resolving which versions of a package would actually be loaded, and which project requested this version (in case there are multiple projects also, whether there was a conflict).
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hi,
being a end user, I am bit confused with these 2 frameworks: Fame and Magritte.
There are both meta-meta-models. So what make them different from a conceptual point of view ?
For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte).
Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description.
Any info on this would be appreciated.
Thanks.
Francois
OK, I just had this problem today, not previously during the week, and I can't find the source.
When updating my Moose image I got:
Loading default of ConfigurationOfMoose... <connection closed>
Fetched -> Famix-ManifestMf-tg.6 --- http://www.squeaksource.com/Moose --- http://www.squeaksource.com/Moose
Project: MooseAlgos for Moose default
Project: PetitParser for Moose default
Project: Glamour for Petit 2.0-beta.7
Fetched -> Morphic-MorphTreeWidget-AlainPlantec.88 --- http://www.squeaksource.com/Momo10 ---
(....)
Two strange things going on:
- PetitParser default requiring Glamour for Petit 2.0-beta.7 (probably a bug when the config was copied to the Moose repo for the 4.0 release. This is now fixed)
- Morphic-MorphTreeWidget-AlainPlantec.88 got fetched, I have no idea how/which project required this package which dates back to january 2010 (it's not Glamour 2.0-beta.7)
Can anyone reproduce this problem, starting from a 4.1 release then updating to default? Or starting fresh and loading default?
Dale, I think I have another use case for the Metacello browser, it's being able to debug such a case, by simulating/resolving which versions of a package would actually be loaded, and which project requested this version (in case there are multiple projects also, whether there was a conflict).
--
Simon
Hi!
I very welcome contribution made on Mondrian. But please, enter your complete name when accepting methods and comming. For example, I have no idea who 'jl' is.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
jannik laval?
On Sep 24, 2010, at 6:17 PM, Alexandre Bergel wrote:
> Hi!
>
> I very welcome contribution made on Mondrian. But please, enter your complete name when accepting methods and comming. For example, I have no idea who 'jl' is.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
