Moose-dev October 2010

moose-dev@list.inf.unibe.ch

24 participants
90 discussions

Re: DSMCell>>configurationForNamespace
by Simon Denier 12 Oct '10

12 Oct '10

Hi Alex Most tools expect things to be something more than some empty entities. You just have to follow tool assumptions sometimes. For DSM, I already posted a fix for the test: model := MooseModel new. model add: (FAMIXNamespace new name: 'name1'); add: (FAMIXNamespace new name: 'name2'); add: (FAMIXNamespace new name: 'name3'). allActionMorphs := self allActionMorphsIn: model allNamespaces mooseMenu. For FamixMethod, #allPackages can not be computed because no package are defined in the stub model. So just add one. > The following raises an error. Is this intended? > > | group fClass | > fClass := FAMIXClass new. > group := FAMIXMethodGroup new. > group > add: (FAMIXMethod new name: 'name1'; parentType: fClass); > add: (FAMIXMethod new name: 'name2'; parentType: fClass); > add: (FAMIXMethod new name: 'name3'; parentType: fClass). > group allPackages > > allPackages cannot be computed. On 12 oct. 2010, at 20:04, Alexandre Bergel wrote: > Hi! > > Is it okay to assume that some FAMIX object may leave outside a model? > There is the following method: > > DSMCell>>configurationForNamespace > > self accesses: (self from mooseModel sourceLanguage = #Smalltalk > ifTrue: [ self from outgoingReferencesTo: self to ] > ifFalse: > [ (self from outgoingReferencesTo: self to) union: (self from accessTo: self to) ]). > ... > ^ self dependencies > > > What do you think about adding: > self mooseModel ifNil: [ ^ self dependencies ] > > It would make the DSM more robust. > I tried to open a DSM on a namespace group defined as: > > group := FAMIXNamespaceGroup new. > group > add: (FAMIXNamespace new name: 'name1'); > add: (FAMIXNamespace new name: 'name2'); > add: (FAMIXNamespace new name: 'name3'). > > It raises an error. > > 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

2 1

feedback
by Alexandre Bergel 12 Oct '10

12 Oct '10

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 5

Re: About Famix-Core-GuillermoSchwarz.123
by Simon Denier 12 Oct '10

12 Oct '10

If you are working with Alex, I suggest that he shows you the basic tricks when working with Monticello. On 11 oct. 2010, at 18:43, Guillermo Schwarz wrote: > Hi Simon, > > Thanks for pointing this out. I understand most distributed version > control engines were all done in parallel, I'm still getting used to > Mercurial so whenever I find a difference I need to write it down > somewhere in order to remember. > > I'm glad that you replied. I think my commit is incomplete, but I didn't > know how to verify that. For some reason the Kernel project showed an > asterisk in Monticello, so I guessed that I modified something in the > Kernel project. It allowed me to check it in until the last moment when > it said "you are not authorized". Following GitHub rules it could allow > me fork the kernel project (clone) or allow me to send an email to the > Kernel project developers with my change (as suggested in the Cathedral > and the Bazaar). I don't know which would be best, but I guess "both" > would be the best answer. Did you read the stuff about Monticello in Pharo by Example? http://pharobyexample.org/ It might help you to get started. If you think you have changed something in Kernel, check "Changes" to see if it's really yours (sometimes a package such as Kernel appears dirty because of some automatic process) If you do have changes related to your fix in Kernel, then there is a good probability that such changes should be declared as class extensions from your package, not inside Kernel. Check again the Monticello section for how to do that. In most cases, you don't hack core packages such as Kernel unless you found a bug (then you should submit an issue to the Pharo project). You extend core packages with class extensions. > > The comment that you mentioned that I wrote is about how do I know the > history in Monticello? For example in Mercurial all the changes are > local and then you merge the changes locally by pulling from the remote > repository. While Mercurial is not ideal in the sense that having so > much dependencies can get confusing, the advantage is that when the > central repository goes down, you can easily setup a new repository > using a 3 day old copy and ask all committers to point to the new > central repository and reapply all their commits. It is so easy because > Mercurial calculates on the fly what it needs to push. > > Monticello on the other hand seems to allow to commit on a change by > change basis to wherever I want: A local file, any remote repository, > etc. And it is up to me to figure out (and remember) where I stored > what. I would be really hard for me to remind any of that. Yep that's the weak point in Monticello. Although normally, all your history should be in your local cache. So you can always copy from your local cache to another repo. Now it's a question of process. If possible, always commit to the same repository (like on squeaksource). If you are offline and commit only locally, then Gofer can help you to synchronize your local cache with your distant repo. The very basic things to understand with Monticello - a Monticello package is self-contained: you can always load it anywhere - however if you need to merge something, you need all packages in the ancestry so that Monticello can compute the differences with the common ancestor. > Since I was uploading 2 packages, what I would like is to have a package > dependency manager like Maven. Does that already exist or I would need > to recreate that from scratch? If your dependencies are basic and within the same repository, you can use the "required package" feature of Monticello. Otherwise, you will have to use Metacello. > > Regarding how to verify the commit I did, I would expect that there > would be a build machine. Since there seems to be no build machine, the > process recommended in Pharo by Example is to download the code from > Squeak Source into a clean image. Do I need to recreate the project in > Monticello and then download the code? Not sure I understand what you mean. There is an integration server for Moose. Now if your project is not part of Moose default, you have to check by yourself that it loads ok in a new image. http://hudson.moosetechnology.org/ > > Cheers, > Guillermo. > > On Mon, 2010-10-11 at 14:32 +0200, Simon Denier wrote: >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simplex Veri Sigillum > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

2 1

Re: About Famix-Core-GuillermoSchwarz.123
by Stéphane Ducasse 12 Oct '10

12 Oct '10

On Oct 12, 2010, at 6:09 PM, Nicolas Anquetil wrote: > I thought that 'merge' looks at conflicts and warns you if there are some and 'load' just load without warnings, no? sure merge does that. load just load a new version without taking care of the old one. erase and load > > Don't know about update > > nicolas > > On Tue, Oct 12, 2010 at 4:11 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > On 12 oct. 2010, at 15:26, Guillermo Schwarz wrote: > >> HI again Simon, >> >> I looked at Gofer and certainly it looks like hg command line. Thanks! >> >> There is commit, update and push, but no pull? The docs in the page are a little bit like "Microsoft help" ;-) > > > I think that fetch = pull. Lukas could answer precisely. > > I am not sure about the difference between load and update and merge. > > >> >> load Load the specified packages. >> update Update the specified packages. >> merge Merge the specified packages into their working copies. >> localChanges Answer the changes between the base version and the working copy. >> browseLocalChanges Browse the changes between the base version and the working copy. >> remoteChanges Answer the changes between the working copy and the remote changes. >> browseRemoteChanges Browse the changes between the working copy and the remote changes. >> cleanup Cleans the specified packages. >> commit Commit the modified specified packages. >> commit: Commit the modified specified packages with the given commit message. >> revert Revert the specified packages to the currently loaded version. >> recompile Recompile the specified packages. >> reinitialize Call the class side initializers on the specified packages. >> unload Unload the specified packages. >> fetch Download versions from remote repositories into the local cache. >> push Upload local versions from local cache into remote repositories. >> >> I will take a closer look later. >> >> Cheers, >> Guillermo. >> >> On Mon, Oct 11, 2010 at 9:32 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> _______________________________________________ >> 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 > > > > > -- > Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

Re: About Famix-Core-GuillermoSchwarz.123
by Simon Denier 12 Oct '10

12 Oct '10

On 12 oct. 2010, at 15:26, Guillermo Schwarz wrote: > HI again Simon, > > I looked at Gofer and certainly it looks like hg command line. Thanks! > > There is commit, update and push, but no pull? The docs in the page are a little bit like "Microsoft help" ;-) I think that fetch = pull. Lukas could answer precisely. I am not sure about the difference between load and update and merge. > > load Load the specified packages. > update Update the specified packages. > merge Merge the specified packages into their working copies. > localChanges Answer the changes between the base version and the working copy. > browseLocalChanges Browse the changes between the base version and the working copy. > remoteChanges Answer the changes between the working copy and the remote changes. > browseRemoteChanges Browse the changes between the working copy and the remote changes. > cleanup Cleans the specified packages. > commit Commit the modified specified packages. > commit: Commit the modified specified packages with the given commit message. > revert Revert the specified packages to the currently loaded version. > recompile Recompile the specified packages. > reinitialize Call the class side initializers on the specified packages. > unload Unload the specified packages. > fetch Download versions from remote repositories into the local cache. > push Upload local versions from local cache into remote repositories. > > I will take a closer look later. > > Cheers, > Guillermo. > > On Mon, Oct 11, 2010 at 9:32 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Hi Guillermo > > I saw your commit and especially your comment > > "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." > > The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) > - the save command in MC always creates a new version of your package in the repository you selected > - saving a version on a remote repository also saves a local copy > - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser > > Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. > See http://www.lukas-renggli.ch/blog/gofer > > > BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

2 1

Re: feedback
by Simon Denier 12 Oct '10

12 Oct '10

On 12 oct. 2010, at 08:41, Tudor Girba wrote: > Hi Alex, > > These tests have the following problem: sometimes the UI spawns modal dialogues (like in the DSM) and this basically prevents automatic regression testing. > > Of course, we should not have modal dialogues, but just to make sure, could you extend the tests to take something like this into account? Otherwise, I would have to remove them for now. I tried to do something like [....] valueSuppressingAllMessages but it does not seem to work with the modal dialog. Maybe there is a different message for that? > > Cheers, > Doru > > > On 6 Oct 2010, at 23:36, Alexandre Bergel wrote: > >> I just added a class MooseFinderTest in 'Moose-Tests-Core' >> This class can be moved into a 'Moose-Tests-Finder' I guess. I just did not want to mess up the configuration. >> The test is yellow. >> >> Alexandre >> >> >> On 6 Oct 2010, at 12: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. >>> >>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > > "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

1 0

About Famix-Core-GuillermoSchwarz.123
by Simon Denier 12 Oct '10

12 Oct '10

Hi Guillermo I saw your commit and especially your comment "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) - the save command in MC always creates a new version of your package in the repository you selected - saving a version on a remote repository also saves a local copy - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. See http://www.lukas-renggli.ch/blog/gofer BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables -- Simon

4 7

FAMIX-C vs CAnalyzer?
by Alexandre Bergel 12 Oct '10

12 Oct '10

Hi! What is FAMIX-C? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Re: About Famix-Core-GuillermoSchwarz.123
by Simon Denier 11 Oct '10

11 Oct '10

On 11 oct. 2010, at 15:23, Alexandre Bergel wrote: > Hi Guillermo, > > I checked version the 123 of Famix-Core. Why have you added the comment in the method? > > FAMIXUnknownVariable>>container > self flag: #useless. "seems like this attribute is never set" > ^ container > > FAMIXUnknownVariable defines container:, which has many senders Hi Alex I think you took a look at a larger change, not the one from Guillermo. What you see is a change which has been deleted for Moose 4.1. The comment is meant to say this attribute is always nil and hence useless as the importer does not care about setting a container for unknown variables. And since nobody ever complained about a container set to nil, I assume nobody needs container on FamixUnknownVariable. We can always add it later. > > Cheers, > Alexandre > > > On 11 Oct 2010, at 09:32, Simon Denier wrote: > >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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 -- Simon

2 1

pharo sprint / moose dojo - october 23-24, bern
by Tudor Girba 11 Oct '10

11 Oct '10

Hi, We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): http://www.moosetechnology.org/events/2010-10-22-dojo For planning purposes, please let me know if you will attend. Cheers, Doru p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) http://choose.s-i.ch/events/forum2010 -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

2 3

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2010