- Moose-dev - INF Mailman

by Simon Denier

On 7 oct. 2010, at 16:29, Cyrille Delaunay wrote: > I don't understand where I should put this check ? Can you try again with the fix of Alex? You might run into the problem now (if not, please go beyond the first popups until you get a failed assertion, that's the DM wizard which is failing) > > 2010/10/7 Simon Denier <Simon.Denier(a)inria.fr> > > 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 > > > > > _______________________________________________ > 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, 8 months

2
1
0 0

Re: feedback

by Simon Denier

On 12 oct. 2010, at 20:06, Alexandre Bergel wrote: > Hi! > >> 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. > > Apparently catching Notification seems to be enough. The three tests defined in MooseFinderTest are now yellow and do not popup a modal window. > I am working on making the test green. It's not working on my computer. For example I got popup from DSM telling I have no cycle and also Distribution Map wizards. > > Alexandre > >> >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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, 8 months

3
3
0 0

Re: DSMCell>>configurationForNamespace

by Simon Denier

On 12 oct. 2010, at 20:40, Alexandre Bergel wrote: >> Most tools expect things to be something more than some empty entities. > > I know this. But I am just wondering whether this is really what we want. > >> 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. > > This looks odd to me. allPackages should return an empty collection, not raises an error. It is easy to make it work. Getting a good design a bit more tricky :-) Did you take a look at the error? It's "A set can not contain nil value" and we got nil because #parentPackage is not initialized Now the implementation of #allPackages is: FAMIXPackageGroup withAll: (self entities collectAsSet: [:m | m parentPackage]) I don't want to add a nil check in this method. On the contrary, if one day a nil appears in this place, I would like an error to pop up so that I can investigate why the model seems inconsistent. > > Alexandre > >> >> >> >>> 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 >> >> >> >> >> _______________________________________________ >> 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

14 years, 8 months

2
1
0 0

DSMCell>>configurationForNamespace

by Alexandre Bergel

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

14 years, 8 months

2
1
0 0

Re: DSMCell>>configurationForNamespace

by Simon Denier

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

14 years, 8 months

2
1
0 0

feedback

by Alexandre Bergel

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

14 years, 8 months

2
5
0 0

Re: About Famix-Core-GuillermoSchwarz.123

by Simon Denier

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

14 years, 8 months

2
1
0 0

Re: About Famix-Core-GuillermoSchwarz.123

by Stéphane Ducasse

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

14 years, 8 months

1
0
0 0

Re: About Famix-Core-GuillermoSchwarz.123

by Simon Denier

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

14 years, 8 months

2
1
0 0

Re: feedback

by Simon Denier

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

14 years, 8 months

1
0
0 0

About Famix-Core-GuillermoSchwarz.123

by Simon Denier

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

14 years, 8 months

4
7
0 0

FAMIX-C vs CAnalyzer?

by Alexandre Bergel

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

14 years, 8 months

3
2
0 0

Re: About Famix-Core-GuillermoSchwarz.123

by Simon Denier

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

14 years, 8 months

2
1
0 0

pharo sprint / moose dojo - october 23-24, bern

by Tudor Girba

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."

14 years, 8 months

2
3
0 0

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

by Tudor Girba

Hi, I am glad it works :). If you have further problems or questions about Glamour, it is better to address them on the moose-dev mailing list: https://www.iam.unibe.ch/mailman/listinfo/moose-dev moose-dev(a)iam.unibe.ch Cheers, Doru On 10 Oct 2010, at 14:56, Esteban Lorenzano wrote: > Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 > > > On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > >> 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 > > > > > _______________________________________________ > 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 "What is more important: To be happy, or to make happy?"

14 years, 9 months

1
0
0 0

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, 9 months

1
0
0 0

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, 9 months

3
2
0 0

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, 9 months

1
0
0 0

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, 9 months

1
0
0 0

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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

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, 9 months

4
3
0 0

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, 9 months

1
0
0 0

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, 9 months

3
4
0 0

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, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev