Hi I would like to give a try to do something else than latex. Is there a list of bugs that I can work on? Adrian you mentioned __state__ to finish and I know that Task was left not totally finished. Could you put your todo with the probability that you will work on them? Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> The tracker seems to be down, I can not acces the list. > I will ask marcus how to fix this, as he uses the same for > reflectivity. > > There are tons of small issues that I do not remember par coeur. > But I will try to collect some major issues I remember in a follow up > mail. - __state__ is the main abandoned construction site (the idea there is to considerable recue the memory footprint of moose and trade-off performance in the same time. I stopped mid way, when all my suggestion to use meta-programming got rejected as I dont think we can reduce the memory-footprint with Java-like code as it is now.

I was mainly thinking of (i) collective instance variables for the model backlink,

(ii) dynamic instance variables (ie wide classes) for all none FAMIX.Core properties and metrics, adn (iii) collective behavior for collective behavior. In particular the (i) would in addition to saved instvar slots also save the need to keep all those ugly caches of all-entities-of-one-kind in the model).

- Write method comments - New exception dialog that shows a form for bug-repot and "send to moose-dev" button which will take report, attached stack trace and other interesting info and send it to this list. - Have some Javadoc like comment tool

- CodeFoo.Task

- Write package comments - Switch from Meta to Fame (the new Famix 3.0 Meta on which I started working on today's 15 hour odyssee through France, Belgium and Germany) (Fame stands for FAmix MEtamodel)

- Sketch some rough UML of moose main class structure - FM3.MultivalueLink for many-to-many relationships - Write tutorials for basic plugin-developer tasks

- Proper test setup - (currently they are too long, and their fixture too complexe to be a help. When broken the single point of failure is not evident) - (as a first step, this can mean as little as making two test suites, one with the small and okay tests, and one with the ugly tests) - (I expect that each ugly tests could be splitted in at least two dozen nice tests each)

- Write class comments - Tagging of Moose's public interface with a pragma and setup a way to check at runtime if plugins violate this constraint - Propose nice coding conventions and useful best practices for Moose - Enforce them That is all I remember now. For priorities, all of that is low to very low on my list except for supporting the transition from F2.2 to F3 AA

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 20 Nov 2007, at 15:52 , Stéphane Ducasse wrote: >> - __state__ is the main abandoned construction site (the idea there >> is to considerable recue the memory footprint of moose and trade-off >> performance in the same time. I stopped mid way, when all my >> suggestion to use meta-programming got rejected as I dont think we >> can reduce the memory-footprint with Java-like code as it is now. > > I do not understand what is Java-like code? Non-meta-programming-using-code :) sorry for the pun. > >> I was mainly thinking of (i) collective instance variables for the >> model backlink, > > Sorry I do not know what is a collective instance variable Take a group of instances, change them to same anonymous subclass and attach a class var to that subclass. The plan is to use this for entity's model backlink. > >> (ii) dynamic instance variables (ie wide classes) for >> all none FAMIX.Core properties and metrics, adn (iii) collective >> behavior for collective behavior. In particular the (i) would in >> addition to saved instvar slots also save the need to keep all those >> ugly caches of all-entities-of-one-kind in the model). > > so what can we do if we are normal people to help. I'm not sure that > I can help on this one. I discussed with Toon recently, he might gonna implement most of the meta-programming when adapting the code-generation for Famix 3. >> - Write method comments >> >> - New exception dialog that shows a form for bug-repot and "send to >> moose-dev" button which will take report, attached stack trace and >> other interesting info and send it to this list. >> >> - Have some Javadoc like comment tool > > for doing what? Collecting the comments? Yes, and publish them as HTML or Latex for API documentation, as Lukas does for Pier et al.

>> >> - CodeFoo.Task > > What is it? > >> - Write package comments >> >> - Switch from Meta to Fame (the new Famix 3.0 Meta on which I >> started >> working on today's 15 hour odyssee through France, Belgium and >> Germany) (Fame stands for FAmix MEtamodel) > > Why do you change Meta? to FAME? Dasselbe in Grün, Fame is Meta's new name. >> - Sketch some rough UML of moose main class structure >> >> - FM3.MultivalueLink for many-to-many relationships >> >> - Write tutorials for basic plugin-developer tasks > > I would love to proofread that and do them. But I have a problem to > write one for now because moose changes too mcuh for me. I can write some for Fame and other kernel-related tasks. @Doru, could you do tutorials for UI-related tasks? I think you now best which is part of Moose's public interface and which is private stuff.

> >> - Proper test setup >> - (currently they are too long, and their fixture too complexe >> to be >> a help. When broken the single point of failure is not evident) >> - (as a first step, this can mean as little as making two test >> suites, one with the small and okay tests, and one with the ugly >> tests) >> - (I expect that each ugly tests could be splitted in at least two >> dozen nice tests each) > > I'm not sure since I certainly wrote a lot of ugly tests that I can > cut them into meaningful Smaller test fixtures are most critical, I'd say. > >> - Write class comments >> >> - Tagging of Moose's public interface with a pragma and setup a way >> to check at runtime if plugins violate this constraint >> >> - Propose nice coding conventions and useful best practices for >> Moose >> >> - Enforce them >> >> That is all I remember now. For priorities, all of that is low to >> very low on my list except for supporting the transition from F2.2 >> to F3 >> >> AA > > I will check moose and see what I can do. > > Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I know, and I dont agree :) My proposals would make Moose easier to understand and easier to maintain, even for the so-called base programmers. In addition, there would be less code, less memory footprint and thus more performance.

AA On 21 Nov 2007, at 14:03 , Stéphane Ducasse wrote: > for me that was expert in another life on meta programming, I like to > keep meta programming > for the meta stuff. If at the end of the day you implement something > really cool but which alienates > the base programmers then you are wrong. > My fear is that once there too much magic in moose nobody will ever > dare to change it. > At this point of the story what will happen is that certainly someone > will just fork and rewrite something > that he can understand. So expect for really crucial I would > recommend against using reflection in the domain > code. > > Stef > > On 20 nov. 07, at 16:30, Adrian Kuhn wrote: > >> On 20 Nov 2007, at 15:52 , Stéphane Ducasse wrote: >> >>>> - __state__ is the main abandoned construction site (the idea >>>> there >>>> is to considerable recue the memory footprint of moose and trade- >>>> off >>>> performance in the same time. I stopped mid way, when all my >>>> suggestion to use meta-programming got rejected as I dont think we >>>> can reduce the memory-footprint with Java-like code as it is now. >>> >>> I do not understand what is Java-like code? >> >> Non-meta-programming-using-code :) sorry for the pun. >> >>> >>>> I was mainly thinking of (i) collective instance variables for the >>>> model backlink, >>> >>> Sorry I do not know what is a collective instance variable >> >> Take a group of instances, change them to same anonymous subclass >> and >> attach a class var to that subclass. The plan is to use this for >> entity's model backlink. >> >>> >>>> (ii) dynamic instance variables (ie wide classes) for >>>> all none FAMIX.Core properties and metrics, adn (iii) collective >>>> behavior for collective behavior. In particular the (i) would in >>>> addition to saved instvar slots also save the need to keep all >>>> those >>>> ugly caches of all-entities-of-one-kind in the model). >>> >>> so what can we do if we are normal people to help. I'm not sure >>> that >>> I can help on this one. >> >> I discussed with Toon recently, he might gonna implement most of the >> meta-programming when adapting the code-generation for Famix 3. >> >>>> - Write method comments >>>> >>>> - New exception dialog that shows a form for bug-repot and >>>> "send to >>>> moose-dev" button which will take report, attached stack trace and >>>> other interesting info and send it to this list. >>>> >>>> - Have some Javadoc like comment tool >>> >>> for doing what? Collecting the comments? >> >> Yes, and publish them as HTML or Latex for API documentation, as >> Lukas does for Pier et al. > > I think that a good tutorial is much better because the approach of > comment > always start and never finished. > >> >>>> >>>> - CodeFoo.Task >>> >>> What is it? >>> >>>> - Write package comments >>>> >>>> - Switch from Meta to Fame (the new Famix 3.0 Meta on which I >>>> started >>>> working on today's 15 hour odyssee through France, Belgium and >>>> Germany) (Fame stands for FAmix MEtamodel) >>> >>> Why do you change Meta? to FAME? >> >> Dasselbe in Grün, Fame is Meta's new name. >> >>>> - Sketch some rough UML of moose main class structure >>>> >>>> - FM3.MultivalueLink for many-to-many relationships >>>> >>>> - Write tutorials for basic plugin-developer tasks >>> >>> I would love to proofread that and do them. But I have a problem to >>> write one for now because moose changes too mcuh for me. >> >> I can write some for Fame and other kernel-related tasks. >> @Doru, could you do tutorials for UI-related tasks? I think you now >> best which is part of Moose's public interface and which is private >> stuff. > > I can read beta tests that >> >>> >>>> - Proper test setup >>>> - (currently they are too long, and their fixture too complexe >>>> to be >>>> a help. When broken the single point of failure is not evident) >>>> - (as a first step, this can mean as little as making two test >>>> suites, one with the small and okay tests, and one with the ugly >>>> tests) >>>> - (I expect that each ugly tests could be splitted in at least >>>> two >>>> dozen nice tests each) >>> >>> I'm not sure since I certainly wrote a lot of ugly tests that I can >>> cut them into meaningful >> >> Smaller test fixtures are most critical, I'd say. >> >>> >>>> - Write class comments >>>> >>>> - Tagging of Moose's public interface with a pragma and setup a >>>> way >>>> to check at runtime if plugins violate this constraint >>>> >>>> - Propose nice coding conventions and useful best practices for >>>> Moose >>>> >>>> - Enforce them >>>> >>>> That is all I remember now. For priorities, all of that is low to >>>> very low on my list except for supporting the transition from F2.2 >>>> to F3 >>>> >>>> AA >>> >>> I will check moose and see what I can do. >>> >>> Stef >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

From: Adrian Kuhn <akuhn(a)gmx.ch&gt; To: Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch&gt; Subject: [Moose-dev] Re: Could I get a list of bugs to smash in moose? Date: Wed, 21 Nov 2007 23:39:13 +0100 >> My proposals would make Moose easier to understand and easier to >> maintain, even for the so-called base programmers. In addition, there >> would be less code, less memory footprint and thus more performance. > > Sure by breaking all the navigation and other tools. > I did some simple DNU tricks with roel and we got burnt by them after > a while because the senders and implementers did not work anymore. > So the "easier" is still to be proven. This is why with Moose I > always tried not to put my language research in. There is no DNU in what I propose. I sent out a long mail explaining everything some time ago, I will try again Instead of E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject you as base programmer will write E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject

and the wide classes implementation does all the magic for you. The same for the collective state, instead of E2 >> parent ^parent E2 >> parent: anObject parent := anObject you as base programmer will write E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject and the collective state implementation will again do all the magic for you. This is certainly no more complex than writing something like E3 >> attr ^dict at: #attr ifAbsentr: [ nil ] E3 >> attr: anObject ^dict at: #attr put: anObject and let the Dictionary implementation do all the magic for you. In all three cases, E3 as well as E2 and E1, all refactorings, renamings, all senders of, implementers of and whatever you might dream of your business code will still work. It will be the only change to any client code in Moose or any plugin (assumed you did you homework, using e isKindOf: E and not e class == E for type checking). All instances of E3, E2 and E1 are inspectable, the code of all three classes, E3, E2 and E1 is browseable, storeable, refactorable, understandable, maintainable etc pp. > When I see how difficult is to support something as simple as > traits at the level of the ide. I think that the Smalltalk image > style is either getting in my way or proving me that beauty and > small means something and that the IDE is just a mirror of it. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>> My proposals would make Moose easier to understand and easier to >> maintain, even for the so-called base programmers. In addition, >> there >> would be less code, less memory footprint and thus more performance. > > Sure by breaking all the navigation and other tools. > I did some simple DNU tricks with roel and we got burnt by them after > a while because the senders and implementers did not work anymore. > So the "easier" is still to be proven. This is why with Moose I > always tried not to put my language research in. There is no DNU in what I propose. I sent out a long mail explaining everything some time ago, I will try again Instead of E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject you as base programmer will write E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject and the wide classes implementation does all the magic for you. The same for the collective state, instead of E2 >> parent ^parent E2 >> parent: anObject parent := anObject you as base programmer will write E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject and the collective state implementation will again do all the magic for you. This is certainly no more complex than writing something like E3 >> attr ^dict at: #attr ifAbsentr: [ nil ] E3 >> attr: anObject ^dict at: #attr put: anObject and let the Dictionary implementation do all the magic for you. In all three cases, E3 as well as E2 and E1, all refactorings, renamings, all senders of, implementers of and whatever you might dream of your business code will still work.

It will be the only change to any client code in Moose or any plugin (assumed you did you homework, using e isKindOf: E and not e class == E for type checking). All instances of E3, E2 and E1 are inspectable, the code of all three classes, E3, E2 and E1 is browseable, storeable, refactorable, understandable, maintainable etc pp. > When I see how difficult is to support something as simple as > traits at the level of the ide. I think that the Smalltalk image > style is either getting in my way or proving me that beauty and > small means something and that the IDE is just a mirror of it. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Adrian I think also that wideclasses have an impact on the classBuilder so it would be nice to have a separate packages dealing with such issue. After a while I would be interested to port it to squeak. But first I guess that we want to be convinced for the idea. I was not thinking about wideclass because you change the class of the object in the background. I would prefer a class that has hasTable ivs in addition to named one. It would be completementary with VariableSubclass Stef On 22 nov. 07, at 13:45, Stéphane Ducasse wrote: > I was thinking over lunch about the following: > > - do an implementation of "variableHashTableSubclass" so that any > instance of such a class > can get attribute > - make sure that the tools are working especially senders, > implementers, reference > - give a try. > > On 21 nov. 07, at 23:39, Adrian Kuhn wrote: > >>>> My proposals would make Moose easier to understand and easier to >>>> maintain, even for the so-called base programmers. In addition, >>>> there >>>> would be less code, less memory footprint and thus more >>>> performance. >>> >>> Sure by breaking all the navigation and other tools. >>> I did some simple DNU tricks with roel and we got burnt by them >>> after >>> a while because the senders and implementers did not work anymore. >>> So the "easier" is still to be proven. This is why with Moose I >>> always tried not to put my language research in. >> >> There is no DNU in what I propose. I sent out a long mail explaining >> everything some time ago, I will try again >> >> Instead of >> >> E1 >> attr >> ^ attr >> E1 >> attr: anObject >> ^ attr := anObject >> >> you as base programmer will write >> >> E1 >> attr >> ^self wideVarAt: #attr ifAbsentr: [ nil ] >> E1 >> attr: anObject >> self wideVarAt: #attr put: anObject >> >> and the wide classes implementation does all the magic for you. >> >> The same for the collective state, instead of >> >> E2 >> parent >> ^parent >> E2 >> parent: anObject >> parent := anObject >> >> you as base programmer will write >> >> E2 >> parent >> ^self groupVarAt: #parent ifAbsentr: [ nil ] >> E2 >> parent: anObject >> ^self groupVarAt: #parent put: anObject >> >> and the collective state implementation will again do all the magic >> for you. >> >> This is certainly no more complex than writing something like >> >> E3 >> attr >> ^dict at: #attr ifAbsentr: [ nil ] >> E3 >> attr: anObject >> ^dict at: #attr put: anObject >> >> and let the Dictionary implementation do all the magic for you. >> >> In all three cases, E3 as well as E2 and E1, all refactorings, >> renamings, all senders of, implementers of and whatever you might >> dream of your business code will still work. > > In squeak typically > > self dictAt: #hkjhkj > > was not showing the method when you queried for the references to > #hkjhkj > so I let imagine the pain to change that kind of code. > >> It will be the only >> change to any client code in Moose or any plugin (assumed you did >> you >> homework, using e isKindOf: E and not e class == E for type >> checking). All instances of E3, E2 and E1 are inspectable, the code >> of all three classes, E3, E2 and E1 is browseable, storeable, >> refactorable, understandable, maintainable etc pp. >> >> >> >>> When I see how difficult is to support something as simple as >>> traits at the level of the ide. I think that the Smalltalk image >>> style is either getting in my way or proving me that beauty and >>> small means something and that the IDE is just a mirror of it. >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

But I'm really not convinced by wideclasses, because you will have to define several classes and migrate on the fly instances between them.

Instead of E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject

you as base programmer will write E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject

The same for the collective state, instead of E2 >> parent ^parent E2 >> parent: anObject parent := anObject

you as base programmer will write E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject

Since I just started to work with Moose, here are my few comments. > Instead of > > E1 >> attr > ^ attr > E1 >> attr: anObject > ^ attr := anObject I understand the two methods above. > you as base programmer will write > > E1 >> attr > ^self wideVarAt: #attr ifAbsentr: [ nil ] > E1 >> attr: anObject > self wideVarAt: #attr put: anObject I do not understand them. I guess that wide classes is somehow related to collective behavior? > The same for the collective state, instead of > > E2 >> parent > ^parent > E2 >> parent: anObject > parent := anObject Those two methods are easy to understand. > you as base programmer will write > > E2 >> parent > ^self groupVarAt: #parent ifAbsentr: [ nil ] > E2 >> parent: anObject > ^self groupVarAt: #parent put: anObject I do not understand them. I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing. my 2 pesos 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

I believe that here there are two points under discussion, each with 2 subpoints: A1) the reasons for wide classes A2) the solutions for wide classes B1) the reasons for collective behavior

B2) the solutions for collective behavior I propose to talk about each of these two points individually, because they are not the same to me.

why F would be only 80 bytes? you have superclass, subclass, format, methodDict + methods inside (it does not have to have a metaclass) but may be you need it. On 22 nov. 07, at 23:13, Adrian Kuhn wrote: > > On 22 Nov 2007, at 22:39 , Tudor Girba wrote: > >> I believe that here there are two points under discussion, each with >> 2 subpoints: >> A1) the reasons for wide classes >> A2) the solutions for wide classes >> >> B1) the reasons for collective behavior > > To save memory. > > Each moose element has a back pointer to its model. This is 4 byte > per element, ie 4 MB per 1 Mio elements. Which are realistic maybe > even low numbers when analysing histories or traces. With collective > behavior the memory footprint is (4 + F) * M * T, where F is the size > of an anonymous class, M is the number of models and T is the number > of element types used per model. Given that F is about 80 byte > (including object headers and metaclasses etc pp) and T maybe about > 25, that is 2 KB = 0.002 MB per Model. > >> B2) the solutions for collective behavior >> >> I propose to talk about each of these two points individually, >> because they are not the same to me. >> > _______________________________________________ > 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

Hi, I believe that here there are two points under discussion, each with 2 subpoints: A1) the reasons for wide classes A2) the solutions for wide classes B1) the reasons for collective behavior B2) the solutions for collective behavior I propose to talk about each of these two points individually, because they are not the same to me. Doru On Nov 22, 2007, at 8:37 PM, Orla Greevy wrote: > Hi, > > I have not looked at Moose for a couple of months and I have to say I > agree that from the examples here the new moose will be more > difficult > to understand. > I think we should maybe take the time to provide everyone with the > background and motivation behind the latest changes so that everyone > feels comfortable about contributing to moose. > It would be very sad if it turns into a geek only system. > > My 1$ :-) > > Orla > > On Nov 22, 2007, at 3:07 PM, Bergel, Alexandre wrote: > >> Since I just started to work with Moose, here are my few comments. >> >>> Instead of >>> >>> E1 >> attr >>> ^ attr >>> E1 >> attr: anObject >>> ^ attr := anObject >> >> I understand the two methods above. >> >>> you as base programmer will write >>> >>> E1 >> attr >>> ^self wideVarAt: #attr ifAbsentr: [ nil ] >>> E1 >> attr: anObject >>> self wideVarAt: #attr put: anObject >> >> I do not understand them. I guess that wide classes is somehow >> related to collective behavior? >> >>> The same for the collective state, instead of >>> >>> E2 >> parent >>> ^parent >>> E2 >> parent: anObject >>> parent := anObject >> >> Those two methods are easy to understand. >> >>> you as base programmer will write >>> >>> E2 >> parent >>> ^self groupVarAt: #parent ifAbsentr: [ nil ] >>> E2 >> parent: anObject >>> ^self groupVarAt: #parent put: anObject >> >> I do not understand them. >> >> I am now diving into moose. Adding more comments on classes and >> methods will probably help more newcomers than adding wide classes/ >> collective behavior. I am maybe wrong, but this is the problem I am >> now facing. >> >> my 2 pesos >> >> 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 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "The coherence of a trip is given by the clearness of the goal." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev