Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I cannot reproduce this. I took a PharoDev 1.1.1 and executed: Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. Opening the System Settings browser works just fine. Cheers, Doru On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > Hi, > I'm loading Glamour into a PharoDev 1.1.1 > > Gofer project repository: 'http://www.squeaksource.com/Glamour'; > load: 'Glamour' version: '2.0-beta.7'. > > and then try to open the settings browser... it raises a DNU > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

14 years, 7 months

Re: equality of famix references

by Simon Denier

On 8 oct. 2010, at 15:05, Alexandre Bergel wrote: > Hi! > > The following returns false. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | m c| > m := FAMIXMethod new. > c := FAMIXClass new. > > (FAMIXReference new source: m; target: c) = (FAMIXReference new source: m; target: c) > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Is it a bug or a feature? > > As Guillermo pointed out, this is an odd behavior. One FamixReference represents one reference from within a method to a class, and there can be multiple such references from a single method to the same class. So, this is expected. That said, there is no way right now to create two FamixReferences to represent the same entity in code, but does it make sense? > > 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

equality of famix references

by Alexandre Bergel

Hi! The following returns false. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | m c| m := FAMIXMethod new. c := FAMIXClass new. (FAMIXReference new source: m; target: c) = (FAMIXReference new source: m; target: c) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Is it a bug or a feature? As Guillermo pointed out, this is an odd behavior. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 7 months

issue with DSM

by Alexandre Bergel

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. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 7 months

Re: feedback

by Simon Denier

On 6 oct. 2010, at 18:52, Tudor Girba wrote: > Great idea! > > The problems were due to loose ends of the refactoring of MA* to Mal*. I ran the Code Critics and I fixed these problems, but indeed it would be really great to have this as a generic test. Thanks Doru and Alex. Indeed, some loose ends because I debugged the process on Moose-Algos-Graph. Obviously the debug was not good enough. > > Cheers, > Doru > > > On 6 Oct 2010, at 18:44, Alexandre Bergel wrote: > >> Today I will write some tests that ensure all the visualization accessible from the menu does not raise an error. >> >> Alexandre >> >> >> On 6 Oct 2010, at 12:38, Alexandre Bergel wrote: >> >>> Hi! >>> >>> In order to prepare a lecture on Moose, I am going over different tools available in the distribution. Most of them run quite well. However, I bumped into a number of problems. >>> >>> MATarjan is absent from the last moose hudson image. This makes the "Cycle Table" menu item (from all model package) break. >>> >>> LayerTable also breaks. MAGraphStructure is absent. >>> >>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

14 years, 7 months

[SmallDude] the mooseModel is never set to a DudeSourceCodeFragment

by Cyrille Delaunay

When we compute dudeDuplications from a MooseModel, the mooseModel variable of the DudeSourceCodeFragments generated is never initialized with this MooseModel. When you send 'mooseModel' to any DudeSourceCodeFragment of the model, it resturns nil I guess any MooseEntity should store the mooseModel from which it was generated ? I opened an issue: http://code.google.com/p/moose-technology/issues/detail?id=462

14 years, 7 months

Class renaming in Moose Algos Graph

by Simon Denier

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

14 years, 7 months

Re: Pbm with Torch

by Stéphane Ducasse

veronica why don;t you add the deja package in your configuration? Stef On Oct 1, 2010, at 4:38 PM, Veronica Isabel Uquillas Gomez wrote: > Simon, > > It should work for Pharo dev 1.1 > > I also recommend you to load the DejaVu fonts (as I use different font sizes that are not available in the default Bitmap fonts) > > Cheers, > Veronica > > > On 30 Sep 2010, at 14:39, Simon Denier wrote: > >> Hi Veronica >> >> Today when I tried to launch Torch on package, I got a DNU on RBSemanticAnnotator>>start:class: >> >> In a Pharo 1.1 >> >> How should I update RB? >> >> -- >> 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

14 years, 7 months

Pbm with Torch

by Simon Denier

Hi Veronica Today when I tried to launch Torch on package, I got a DNU on RBSemanticAnnotator>>start:class: In a Pharo 1.1 How should I update RB? -- Simon

14 years, 7 months

Re: Class renaming in Moose Algos Graph

by Simon Denier

On 29 sept. 2010, at 09:08, Stéphane Ducasse wrote: > simon can you open bug entry for pharo? What issue should I report? The fact that Monticello is not aware/notified of the impact of class/trait renaming on external clients? > > 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 > > > _______________________________________________ > 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