Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: link of Moose Suite 4.2 nightly build

by Simon Denier

On 20 oct. 2010, at 21:43, Alexandre Bergel wrote: > Hi! > > The link is down: > http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… > > This is the one accessible from http://www.moosetechnology.org/download/4.2 Indeed, this is fixed. The new link is http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… -- Simon

14 years, 6 months

link of Moose Suite 4.2 nightly build

by Alexandre Bergel

Hi! The link is down: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… This is the one accessible from http://www.moosetechnology.org/download/4.2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 6 months

Re: systemComplexity on model imported from mse does not work

by Simon Denier

On 19 oct. 2010, at 14:11, Simon Denier wrote: > OK I can reproduce now :) > > Well two things: you are doing it wrong ;) but you found a bug :D (or actually, multiple) > > the 'importFromMse' in the contextual menu imports the model from mse into the currently selected model. In this case, you are importing Merlin into the existing Merlin model, which duplicates everything. Perhaps the name of this action is not explicit enough? > > Anyway, the bug is elsewhere: > - when computing FamixMethod>>numberOfLinesOfCode in Smalltalk, the name of the method is given to the calculator, which retrieves the compiledmethod given the name in the method dictionary > - problem is that the method dictionary expects a symbol as a key > - now a 'fresh' model from the Smalltalk importer does set a symbol for a FamixMethod name > - but the MSE importer sets a string instead, hence the error when you try to compute number of lines of code on mse-imported famix method > > But why is there no error when I or Doru creates a moose model from the drop-down menu? > - because the newly created model is not set as #isSmalltalk (because moosemodel attributes are not saved in the mse file, argh) > - then numberOfLinesOfCode does not try to retrieve the compiledmethod and instead try to rely on sourceanchor -> and in the end it returns 0 (hence the white classes Doru noticed). > Solutions? I think there are multiple things to fix. - As Doru says, we could tag such properties as LOC and Cyclo as Fame attributes, this way models are portable - change the importer to set a string to be consistent, and the calculator to use #asSymbol? - what about exporting MooseModel attributes? #isSmalltalkModel > > > On 19 oct. 2010, at 12:57, Cyrille Delaunay wrote: > >> Ok, I know what is different :) >> Here is how I import from mse (I'm sure this is not a good way to do it, but this is at least possible in the menu:)) : >> In the moosePanel: >> => I right-click on the model I just exported >> => select 'import/export' >> => click on 'import from mse' and select merlin.mse >> => close the moosePanel and re-open it. >> => the name of your model is now 'merlin', and the error happen on this model. >> >> Indeed, when I import from mse using the tool bar at the top of the moosePanel, it generate a new model, and all work fine with it. >> >> 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> >> Hi, >> >> On 19 Oct 2010, at 12:26, Simon Denier wrote: >> >> > >> > On 19 oct. 2010, at 11:48, Cyrille Delaunay wrote: >> > >> >> You can try with the moose-suite provided here: http://www.moosetechnology.org/download. >> >> I build a model from Merlin. Then export and import it. Normaly you should not be able to open a SystemComplexity view. >> > >> > I can't reproduce the problem with a latest dev. >> >> I did exactly this and it works fine: >> - import the package named Merlin >> - export the model into merlin.mse >> - import the model from merlin.mse >> - spawn System Complexity on both all famixclasses, and on allmodelclasses and everything works fine, except that there is no color. >> >> >> >> >> Should the property be annoted with 'fame' pragmas, or is it better to modify the exporter to take into account the current used pragmas (<property:longName:description:>) ? >> > >> > >> > Problem is, before exporting the metric, you have to compute the value, and then it takes a lot of time and the mse file gets quite big. Metrics used to be included in older mse, but we exclude them since most of the time we can compute them again. Note that infusion does export some metrics. >> > >> > Now what we need is a way to select what we want to export in the mse. I think that an incremental metamodel builder is the way to go. I don't want metrics to be included in the default metamodel, there are too many of them. >> >> I would say that the metrics that we want to have exported should be explicitly annotated with Fame descriptions. This would be useful for things like lines of code or cyclomatic complexity, which are primitive metrics that cannot be computed out of the model alone. >> >> Cheers, >> Doru >> >> >> >> >> >> >> >> >> >> 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> >> >> Hi Cyrille, >> >> >> >> I cannot reproduce that. Could you send a small sample MSE, or at least point to which model you try? >> >> >> >> In any case, the exporter does not export the properties that are just marked with <property:longName:description:> pragmas, although it would be nice if it would do so. >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >> On 19 Oct 2010, at 10:49, Cyrille Delaunay wrote: >> >> >> >> > Hello, >> >> > >> >> > I have a smalltalk moose-model, for which I can display SystemComplexity. All work fine. Then I export it as MSE and then import it from the MSE file. When I try to reopen System-complexity all seem to be broken (I have a red square). >> >> > Does that means that the model is not well exported ? Maybe some required properties are not described by correct FAame-Pragmas, and are therefore not exported ? >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> >> >> _______________________________________________ >> >> 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 >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> 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 > > > -- Simon

14 years, 7 months

Re: systemComplexity on model imported from mse does not work

by Simon Denier

OK I can reproduce now :) Well two things: you are doing it wrong ;) but you found a bug :D (or actually, multiple) the 'importFromMse' in the contextual menu imports the model from mse into the currently selected model. In this case, you are importing Merlin into the existing Merlin model, which duplicates everything. Perhaps the name of this action is not explicit enough? Anyway, the bug is elsewhere: - when computing FamixMethod>>numberOfLinesOfCode in Smalltalk, the name of the method is given to the calculator, which retrieves the compiledmethod given the name in the method dictionary - problem is that the method dictionary expects a symbol as a key - now a 'fresh' model from the Smalltalk importer does set a symbol for a FamixMethod name - but the MSE importer sets a string instead, hence the error when you try to compute number of lines of code on mse-imported famix method But why is there no error when I or Doru creates a moose model from the drop-down menu? - because the newly created model is not set as #isSmalltalk (because moosemodel attributes are not saved in the mse file, argh) - then numberOfLinesOfCode does not try to retrieve the compiledmethod and instead try to rely on sourceanchor -> and in the end it returns 0 (hence the white classes Doru noticed). On 19 oct. 2010, at 12:57, Cyrille Delaunay wrote: > Ok, I know what is different :) > Here is how I import from mse (I'm sure this is not a good way to do it, but this is at least possible in the menu:)) : > In the moosePanel: > => I right-click on the model I just exported > => select 'import/export' > => click on 'import from mse' and select merlin.mse > => close the moosePanel and re-open it. > => the name of your model is now 'merlin', and the error happen on this model. > > Indeed, when I import from mse using the tool bar at the top of the moosePanel, it generate a new model, and all work fine with it. > > 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> > Hi, > > On 19 Oct 2010, at 12:26, Simon Denier wrote: > > > > > On 19 oct. 2010, at 11:48, Cyrille Delaunay wrote: > > > >> You can try with the moose-suite provided here: http://www.moosetechnology.org/download. > >> I build a model from Merlin. Then export and import it. Normaly you should not be able to open a SystemComplexity view. > > > > I can't reproduce the problem with a latest dev. > > I did exactly this and it works fine: > - import the package named Merlin > - export the model into merlin.mse > - import the model from merlin.mse > - spawn System Complexity on both all famixclasses, and on allmodelclasses and everything works fine, except that there is no color. > > >> > >> Should the property be annoted with 'fame' pragmas, or is it better to modify the exporter to take into account the current used pragmas (<property:longName:description:>) ? > > > > > > Problem is, before exporting the metric, you have to compute the value, and then it takes a lot of time and the mse file gets quite big. Metrics used to be included in older mse, but we exclude them since most of the time we can compute them again. Note that infusion does export some metrics. > > > > Now what we need is a way to select what we want to export in the mse. I think that an incremental metamodel builder is the way to go. I don't want metrics to be included in the default metamodel, there are too many of them. > > I would say that the metrics that we want to have exported should be explicitly annotated with Fame descriptions. This would be useful for things like lines of code or cyclomatic complexity, which are primitive metrics that cannot be computed out of the model alone. > > Cheers, > Doru > > > > > >> > >> > >> 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> > >> Hi Cyrille, > >> > >> I cannot reproduce that. Could you send a small sample MSE, or at least point to which model you try? > >> > >> In any case, the exporter does not export the properties that are just marked with <property:longName:description:> pragmas, although it would be nice if it would do so. > >> > >> Cheers, > >> Doru > >> > >> > >> On 19 Oct 2010, at 10:49, Cyrille Delaunay wrote: > >> > >> > Hello, > >> > > >> > I have a smalltalk moose-model, for which I can display SystemComplexity. All work fine. Then I export it as MSE and then import it from the MSE file. When I try to reopen System-complexity all seem to be broken (I have a red square). > >> > Does that means that the model is not well exported ? Maybe some required properties are not described by correct FAame-Pragmas, and are therefore not exported ? > >> > > >> > _______________________________________________ > >> > 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 > >> > >> _______________________________________________ > >> 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 > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > 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

14 years, 7 months

Re: systemComplexity on model imported from mse does not work

by Simon Denier

On 19 oct. 2010, at 11:48, Cyrille Delaunay wrote: > You can try with the moose-suite provided here: http://www.moosetechnology.org/download. > I build a model from Merlin. Then export and import it. Normaly you should not be able to open a SystemComplexity view. I can't reproduce the problem with a latest dev. > > Should the property be annoted with 'fame' pragmas, or is it better to modify the exporter to take into account the current used pragmas (<property:longName:description:>) ? Problem is, before exporting the metric, you have to compute the value, and then it takes a lot of time and the mse file gets quite big. Metrics used to be included in older mse, but we exclude them since most of the time we can compute them again. Note that infusion does export some metrics. Now what we need is a way to select what we want to export in the mse. I think that an incremental metamodel builder is the way to go. I don't want metrics to be included in the default metamodel, there are too many of them. > > > 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> > Hi Cyrille, > > I cannot reproduce that. Could you send a small sample MSE, or at least point to which model you try? > > In any case, the exporter does not export the properties that are just marked with <property:longName:description:> pragmas, although it would be nice if it would do so. > > Cheers, > Doru > > > On 19 Oct 2010, at 10:49, Cyrille Delaunay wrote: > > > Hello, > > > > I have a smalltalk moose-model, for which I can display SystemComplexity. All work fine. Then I export it as MSE and then import it from the MSE file. When I try to reopen System-complexity all seem to be broken (I have a red square). > > Does that means that the model is not well exported ? Maybe some required properties are not described by correct FAame-Pragmas, and are therefore not exported ? > > > > _______________________________________________ > > 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 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

14 years, 7 months

Re: systemComplexity on model imported from mse does not work

by Simon Denier

On 19 oct. 2010, at 11:48, Cyrille Delaunay wrote: > You can try with the moose-suite provided here: http://www.moosetechnology.org/download. > I build a model from Merlin. Then export and import it. Normaly you should not be able to open a SystemComplexity view. and i can't reproduce with moose-suite. Are you talking about the default MSE exporter? Or something else? > > Should the property be annoted with 'fame' pragmas, or is it better to modify the exporter to take into account the current used pragmas (<property:longName:description:>) ? > > > 2010/10/19 Tudor Girba <tudor.girba(a)gmail.com> > Hi Cyrille, > > I cannot reproduce that. Could you send a small sample MSE, or at least point to which model you try? > > In any case, the exporter does not export the properties that are just marked with <property:longName:description:> pragmas, although it would be nice if it would do so. > > Cheers, > Doru > > > On 19 Oct 2010, at 10:49, Cyrille Delaunay wrote: > > > Hello, > > > > I have a smalltalk moose-model, for which I can display SystemComplexity. All work fine. Then I export it as MSE and then import it from the MSE file. When I try to reopen System-complexity all seem to be broken (I have a red square). > > Does that means that the model is not well exported ? Maybe some required properties are not described by correct FAame-Pragmas, and are therefore not exported ? > > > > _______________________________________________ > > 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 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

14 years, 7 months

systemComplexity on model imported from mse does not work

by Cyrille Delaunay

Hello, I have a smalltalk moose-model, for which I can display SystemComplexity. All work fine. Then I export it as MSE and then import it from the MSE file. When I try to reopen System-complexity all seem to be broken (I have a red square). Does that means that the model is not well exported ? Maybe some required properties are not described by correct FAame-Pragmas, and are therefore not exported ?

14 years, 7 months

loading Moose?

by Alexandre Bergel

Hi! I tried a Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. in Pharo 1.1 and the last Pharo 1.2 Core. I got errors. In Pharo 1.2 I get: What is the image used for the hudson build? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 7 months

Re: only loading Glamour

by Stéphane Ducasse

On Oct 16, 2010, at 11:56 AM, Tudor Girba wrote: > Hi Veronica, > > Sorry for the late reply. > > I am not sure I understand why you could not load Grease / Magritte in a Core or Dev image. Are we talking about Pharo 1.1 or Pharo 1.2? this is not about not been able to load magritte this is a about getting the minimum loaded and do not get seaside and all the rest Even magritte > > In any case, I have now moved Mondrian/Magritte specific code into separate packages, created the following groups: > - Core > - Morphic > - Tests > - Extras (with Magritte and Mondrian) > - ExtrasTests > > For your purpose, you should just load Core, Morphic and possibly Tests. I believe this should be good enough. Could you give it a try? > > Cheers, > Doru > > > On 7 Oct 2010, at 14:23, Veronica Isabel Uquillas Gomez wrote: > >> Hi Doru, >> >> In the configuration of Torch I set to only load the Glamour groups of needed packages (Core, Extras, Tests) to avoid loading Magritte, Grease and their required packages. >> Maybe you remember but i discussed with you about that in the last Pharo sprint in Brussels. I really need some light configuration of Torch specially for the Pharo-core image. >> >> Currently I have a problem because Glamour-Morphic-Renderer needs Magritte, and Magritte needs Grease... I noticed that because I couldn't load Torch in core neither in dev. >> I fixed temporarily in dev to load all again, but not in core. >> >> Is there a way I can load Glamour without those dependencies?... If not I should set which Glamour packages I need in my own configuration without depending of the Configuration of Glamour. >> >> Best regards, >> Veronica >> >> >> >> >> _______________________________________________ >> 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

14 years, 7 months

Re: issue with DSM

by Simon Denier

On 6 oct. 2010, at 23:28, Alexandre Bergel wrote: > Hi! > > I bumped into this: > -=-=-=-=-=-=-=-=-= > DSMCell>>configurationForNamespace > > self accesses: (self from mooseModel sourceLanguage = #Smalltalk > ... > -=-=-=-=-=-=-=-=-= > > 'self from mooseModel' may return nil. > > This happens when I open a DSM on the following object: > group := FAMIXNamespaceGroup new. > group > add: (FAMIXNamespace new name: 'name1'); > add: (FAMIXNamespace new name: 'name2'); > add: (FAMIXNamespace new name: 'name3'). > > DSM is apparently making an assumptions on the object it gets. Well, all tools make such assumptions, especially that they have some non-empty models. The problem here is that we expect to have a moosemodel. I changed the test to create a moosemodel instead of a group. Next failure comes from the DistributionMap wizard: same thing, it assumes that the model is not "empty" as it is above so it works fine in real cases. #possibleElementSelectors returns an empty collection in this case. Cyrille, could you just add check for non-empty collection? > > 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 -- Simon

14 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev