We have benchmarks for Fuel and MSE. However, I was just trying to run the benchs with MSE (to compare to Fuel) but I run into the attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix it, I can finish the benchmark.
Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev mseMoose.txt (40K) Download Attachment |
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <[hidden email]> wrote:
I have just discovered that Famix-Core-NicolasAnquetil.201 fixes that...
Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Mariano Martinez Peck
> We have benchmarks for Fuel and MSE. However, I was just trying to run > the benchs with MSE (to compare to Fuel) but I run into the attached > problem. > It seems related to FAMIX, but I have no idea. If someone can fix it, > I can finish the benchmark. > Mariano, When did you try this? What version of Moose. I spent sometime yesterday and the day before working on scoping in MooseChef. How did you get this error? I would think it could only appear if you issue some MooseChef query ... nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Mariano Martinez Peck
On 27/07/12 16:22, Mariano Martinez
Peck wrote:
:-) OK That was the idea of my previous email :-) you are too fast for me nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Mariano Martinez Peck
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <[hidden email]> wrote:
So the benchmarks for The model network and morphic are:
Model name: Morphic Model size: 110798 MSE export: 219031 ms MSE import: 25331 ms MSE file size: 13135561 bytes FL export: 8492 ms
FL import: 5118 ms FL file size: 4805120 bytes Fuel export is a 4% of MSE export. Fuel import is a 20% of MSE import Fuel file size is a 36% of MSE file size
------- Model name: Network Model size: 26949 MSE export: 49283 ms MSE import: 4889 ms MSE file size: 3144945 bytes
FL export: 1788 ms FL import: 1049 ms FL file size: 1219372 bytes Fuel export is a 4% of MSE export. Fuel import is a 21% of MSE import
Fuel file size is a 38% of MSE file size So the difference between both models are quite proporcional :) Cheers,
Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Nicolas Anquetil
On Fri, Jul 27, 2012 at 4:31 PM, Nicolas Anquetil <[hidden email]> wrote:
Or maybe you were to fast for me since you already fixed it :) Thanks Nicolas.
Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Nicolas Anquetil
On Jul 24, 2012, at 3:45 PM, Nicolas Anquetil wrote: > - images are dependent on the smalltalk code. > In three years these images will be completly outdated and one will need to reload all of pharo and moose to be able to use them which will probably take much more than 5 minutes. Sounds like a job for Jenkins. Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Andrea Caracciolo
>>
> > A separate MSE file or the same where the famix model is in ? I think that if we do not want to have a FAMIX entity and do not have to change the importer/exporter to write an header containing the meta data we will have to get it in another file. > i tried to write down a list of all the meta-data needed: > - project name > - project version > - verveineJ version (i would use the SVN revision number) > > is it enough ? No Did you look at the famix 2.1 document > should we include the FAMIX version ? - project name - location of the original files: URI? - version of the project - language - version of the original language: Java but which one - description - author: email - extractor: Moose42 on Pharo1.4 - date - mse file name (if this is external > I didn't include the supported moose version, because i don't think it's relevant and i don't see how this information should be interpreted. Why? If I extract a model using Moose does it make sense not to be able to reload it because the model change. Try to come up with a meta data that is not just for Java because soon there is scala, java, cobol and many more out there. > > > The rest of the data should be the following: > - MSE of FAMIX model > - source code > > If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. > Is it possible to build such a model having an MSE file for each version as input ? yes > How much effort is needed to fix the bugs and make it work ? Jannik? But normally it should work. Now I do not know if orion covers all the famix entities but extending it should not be a problem, What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion > How do you look for changes between subsequent versions ? Do you diff the source code of the analyzed code entities ? > > Would it make sense to distribute also a FUEL file containing the famix model ? yes but in that case you should also have in the meta data - fuel version > Would it make loading faster ? Apparently you did not check Fuel :) You can reload Pharo completely in 10-15 seconds with Fuel. > >> >> Jannik >> >>> >>>> It could contains all the informations that we discussed here. >>>> >>>> Jannik >>>> >>>> >>>> >>>>> Andrea >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> --- >>>> Jannik Laval >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
>>
>> >> If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. >> Is it possible to build such a model having an MSE file for each version as input ? > > yes >> How much effort is needed to fix the bugs and make it work ? > > Jannik? But normally it should work. Iep, it should work. I used the pragma for importing elements in MSE. But I never tried it. > Now I do not know if orion covers all the famix entities but extending it should not be a problem, It is easy and fast to extend FAMIX entities. Jannik > What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Mircea Filip Lungu-2
On Jul 27, 2012, at 2:00 PM, Mircea Filip Lungu <[hidden email]> wrote:
Ok, lets begin to work :) You can probably begin to use it and give me bugs you find. Cheers, Jannik
--- Jannik Laval _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Mariano Martinez Peck
Hi Mariano,
Could you please share the scripts you used for the benchmark? I attach here the one I use. Cheers, Doru On Fri, Jul 27, 2012 at 4:39 PM, Mariano Martinez Peck <[hidden email]> wrote: > > > On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck > <[hidden email]> wrote: >>> >>> >>> >>> Would it make sense to distribute also a FUEL file containing the famix >>> model ? >>> Would it make loading faster ? >>> >> >> We have benchmarks for Fuel and MSE. However, I was just trying to run the >> benchs with MSE (to compare to Fuel) but I run into the attached problem. >> It seems related to FAMIX, but I have no idea. If someone can fix it, I >> can finish the benchmark. >> > > So the benchmarks for The model network and morphic are: > > Model name: Morphic > Model size: 110798 > > MSE export: 219031 ms > MSE import: 25331 ms > MSE file size: 13135561 bytes > > FL export: 8492 ms > FL import: 5118 ms > FL file size: 4805120 bytes > > Fuel export is a 4% of MSE export. > Fuel import is a 20% of MSE import > Fuel file size is a 36% of MSE file size > > ------- > > Model name: Network > Model size: 26949 > > MSE export: 49283 ms > MSE import: 4889 ms > MSE file size: 3144945 bytes > > FL export: 1788 ms > FL import: 1049 ms > FL file size: 1219372 bytes > > Fuel export is a 4% of MSE export. > Fuel import is a 21% of MSE import > Fuel file size is a 38% of MSE file size > > So the difference between both models are quite proporcional :) > > Cheers, > > >> >> >> >>> >>> > >>> > Jannik >>> > >>> >> >>> >>> It could contains all the informations that we discussed here. >>> >>> >>> >>> Jannik >>> >>> >>> >>> >>> >>> >>> >>>> Andrea >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Moose-dev mailing list >>> >>>> [hidden email] >>> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> --- >>> >>> Jannik Laval >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Moose-dev mailing list >>> >>> [hidden email] >>> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >>> >> >>> >> _______________________________________________ >>> >> Moose-dev mailing list >>> >> [hidden email] >>> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > >>> > --- >>> > Jannik Laval >>> > >>> > >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > [hidden email] >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev mse-vs-fuel.txt (1K) Download Attachment |
On Mon, Jul 30, 2012 at 10:30 AM, Tudor Girba <[hidden email]> wrote: Hi Mariano, Sure. From Fuel ss3 repo, you need to install the packages: FuelBenchmarks, FuelFameExtensionBenchmarks and FuelMooseExtensionBenchmarks. Then, open a Transcript and then you can execute:
FLMooseBenchmarks new runWithModelInstalledWith: [ MooseScripts createModelForMorphic ] name: 'Morphic' benchSelectors: #(runFLWith:) FLMooseBenchmarks new runWithModelInstalledWith: [ MooseScripts createModelForMorphic ] name: 'Morphic' benchSelectors: #(runMSEWith:)
And of course, you can change the Morphic to something else if you want. Let me know if that works. Cheers, I attach here the one I use. Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by jannik laval
I downloaded the latest version from OrionDev and i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of the same project.
The following code does simply create 2 versions, the second of which contains all the entities coming from famixModel2 and a reference to all the entities contained in model1. model1 := OrionConverter convertFrom: famixModel1. model2 := OrionConverter convertFrom: famixModel2. system originalModel: model1. model1 orionSystem: system. model2 withParent: model1. I would like to know if there is a method which allows to add a new version and also makes a diff between the entities being added and the entities contained in the parent version. The diff should be made between entities sharing the same mooseName and should be done on the basis of the contained code (if existing). Thanks :) On Jul 28, 2012, at 10:17 PM, jannik.laval wrote: >>> >>> >>> If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. >>> Is it possible to build such a model having an MSE file for each version as input ? >> >> yes >>> How much effort is needed to fix the bugs and make it work ? >> >> Jannik? But normally it should work. > > Iep, it should work. > I used the pragma for importing elements in MSE. > But I never tried it. > >> Now I do not know if orion covers all the famix entities but extending it should not be a problem, > > It is easy and fast to extend FAMIX entities. > > Jannik > >> What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion >> > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Dear Andrea,
I am happy that you try to use Orion. The primary goal of Orion was to try modifications on a model and keep changes. The meta-model allows clearly to save history, but the infrastructure needs some work. For now, a diff is not implemented. We have to think about this feature. I have no idea how to do that, because some problems appear when merging or forking. Jannik On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <[hidden email]> wrote: > I downloaded the latest version from OrionDev and i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of the same project. > > The following code does simply create 2 versions, the second of which contains all the entities coming from famixModel2 and a reference to all the entities contained in model1. > > model1 := OrionConverter convertFrom: famixModel1. > model2 := OrionConverter convertFrom: famixModel2. > system originalModel: model1. > model1 orionSystem: system. > model2 withParent: model1. > > I would like to know if there is a method which allows to add a new version and also makes a diff between the entities being added and the entities contained in the parent version. > The diff should be made between entities sharing the same mooseName and should be done on the basis of the contained code (if existing). > > Thanks :) > > On Jul 28, 2012, at 10:17 PM, jannik.laval wrote: > >>>> >>>> >>>> If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. >>>> Is it possible to build such a model having an MSE file for each version as input ? >>> >>> yes >>>> How much effort is needed to fix the bugs and make it work ? >>> >>> Jannik? But normally it should work. >> >> Iep, it should work. >> I used the pragma for importing elements in MSE. >> But I never tried it. >> >>> Now I do not know if orion covers all the famix entities but extending it should not be a problem, >> >> It is easy and fast to extend FAMIX entities. >> >> Jannik >> >>> What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion >>> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Jannik Laval _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi Jannik,
Are you saying that this feature can't be added because some already implemented actions are not always working as expected ? Did i understand correctly ? Do you think you can fix it ? Do you need help with it ? I attached a small code snippet which might help developing a possible solution… Andrea On Jul 30, 2012, at 9:32 PM, jannik.laval wrote: > Dear Andrea, > > I am happy that you try to use Orion. > The primary goal of Orion was to try modifications on a model and keep changes. > > The meta-model allows clearly to save history, but the infrastructure needs some work. > For now, a diff is not implemented. We have to think about this feature. I have no idea how to do that, because some problems appear when merging or forking. > > Jannik > > > On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <[hidden email]> wrote: > >> I downloaded the latest version from OrionDev and i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of the same project. >> >> The following code does simply create 2 versions, the second of which contains all the entities coming from famixModel2 and a reference to all the entities contained in model1. >> >> model1 := OrionConverter convertFrom: famixModel1. >> model2 := OrionConverter convertFrom: famixModel2. >> system originalModel: model1. >> model1 orionSystem: system. >> model2 withParent: model1. >> >> I would like to know if there is a method which allows to add a new version and also makes a diff between the entities being added and the entities contained in the parent version. >> The diff should be made between entities sharing the same mooseName and should be done on the basis of the contained code (if existing). >> >> Thanks :) >> >> On Jul 28, 2012, at 10:17 PM, jannik.laval wrote: >> >>>>> >>>>> >>>>> If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. >>>>> Is it possible to build such a model having an MSE file for each version as input ? >>>> >>>> yes >>>>> How much effort is needed to fix the bugs and make it work ? >>>> >>>> Jannik? But normally it should work. >>> >>> Iep, it should work. >>> I used the pragma for importing elements in MSE. >>> But I never tried it. >>> >>>> Now I do not know if orion covers all the famix entities but extending it should not be a problem, >>> >>> It is easy and fast to extend FAMIX entities. >>> >>> Jannik >>> >>>> What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev orion.txt (1K) Download Attachment |
Hi Andrea,
On Jul 31, 2012, at 3:11 PM, Andrea Caracciolo <[hidden email]> wrote: > Hi Jannik, > > Are you saying that this feature can't be added because some already implemented actions are not always working as expected ? Did i understand correctly ? The feature can be added, but is not :) > Do you think you can fix it ? > Do you need help with it ? > > I attached a small code snippet which might help developing a possible solution… > > <orion.txt> It seems to be a good first approach, but I think that loading all the 2nd model to remove it after is not efficient. A solution could be to read the mse file and create only the necessary entities using orion methods. I will try to do something during August. If you need it, you can also propose source code, and I can review it. Cheers, Jannik > > Andrea > > > On Jul 30, 2012, at 9:32 PM, jannik.laval wrote: > >> Dear Andrea, >> >> I am happy that you try to use Orion. >> The primary goal of Orion was to try modifications on a model and keep changes. >> >> The meta-model allows clearly to save history, but the infrastructure needs some work. >> For now, a diff is not implemented. We have to think about this feature. I have no idea how to do that, because some problems appear when merging or forking. >> >> Jannik >> >> >> On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <[hidden email]> wrote: >> >>> I downloaded the latest version from OrionDev and i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of the same project. >>> >>> The following code does simply create 2 versions, the second of which contains all the entities coming from famixModel2 and a reference to all the entities contained in model1. >>> >>> model1 := OrionConverter convertFrom: famixModel1. >>> model2 := OrionConverter convertFrom: famixModel2. >>> system originalModel: model1. >>> model1 orionSystem: system. >>> model2 withParent: model1. >>> >>> I would like to know if there is a method which allows to add a new version and also makes a diff between the entities being added and the entities contained in the parent version. >>> The diff should be made between entities sharing the same mooseName and should be done on the basis of the contained code (if existing). >>> >>> Thanks :) >>> >>> On Jul 28, 2012, at 10:17 PM, jannik.laval wrote: >>> >>>>>> >>>>>> >>>>>> If there are multiple versions of a project, it would be also interesting to distribute an Orion model of all the versions. >>>>>> Is it possible to build such a model having an MSE file for each version as input ? >>>>> >>>>> yes >>>>>> How much effort is needed to fix the bugs and make it work ? >>>>> >>>>> Jannik? But normally it should work. >>>> >>>> Iep, it should work. >>>> I used the pragma for importing elements in MSE. >>>> But I never tried it. >>>> >>>>> Now I do not know if orion covers all the famix entities but extending it should not be a problem, >>>> >>>> It is easy and fast to extend FAMIX entities. >>>> >>>> Jannik >>>> >>>>> What would be good is that orion gets the trick that andy and veronica implemented in their implementation of Orion >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Jannik Laval _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On Aug 2, 2012, at 9:25 PM, jannik.laval wrote:
Indeed it's not very efficient. It takes around 10 min to compare 2 small sized models (5mb MSE each).
I'm looking forward to use it. Please keep me informed. I will send you some code in case i start working on it. Cheers, Andrea _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi Andrea,
I retrieved your mail and tried to find a solution. I clearly not found anyone. In fact, in Orion, the idea is to have a link between each version at entity level. It means that a class that has been renamed know its previous version with its previous name.
In 2 different mse files, there is no link between these entities. We have to postulate that an entity from the second version is linked to an entity of the first version. For that, we need to use heuristics... which is not deterministic.
So, I found 2 possible ways: - we match the name of the entities. If they match, there is a link. But, all rename of entities would provide inconsistencies in the understanding of the model.
- we don't match anything and only remove changed entities to add the updated one, without link between them. I am not sure about an easy way to develop this feature. But someone has probably an idea...
Cheers, Jannik 2012/8/3 Andrea Caracciolo <[hidden email]>
~~Dr. Jannik Laval~~ _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 29/11/12 09:11, jannik laval wrote:
> Hi Andrea, > > I retrieved your mail and tried to find a solution. > I clearly not found anyone. > > In fact, in Orion, the idea is to have a link between each version at > entity level. It means that a class that has been renamed know its > previous version with its previous name. > In 2 different mse files, there is no link between these entities. We > have to postulate that an entity from the second version is linked to > an entity of the first version. For that, we need to use heuristics... > which is not deterministic. > > So, I found 2 possible ways: > - we match the name of the entities. If they match, there is a link. > But, all rename of entities would provide inconsistencies in the > understanding of the model. > - we don't match anything and only remove changed entities to add the > updated one, without link between them. > > I am not sure about an easy way to develop this feature. But someone > has probably an idea... > > Cheers, > Jannik Hi, First there is no absolute solution, unless you watch all user actions to see that this method was renamed that name. So the idea is to be as close as possible to the perfect solution. I developped something related in VerveineJ Because it allows incremental parsing, it needs to check every "new" entity to see if it does not already exist (created in a previous parse of the system). The heuristics used are based on containers. Basically, the algorithm is: If two entites have the same name and their respective owner are "equal" hten they are "equal". The algorithm goes recursively up the owner relationship until there is no owner (for example, Java package "java"). We can discuss this more in depth if you want, or you can have a look at the code (methods matchAndMapXXX in JavaDictionnary.java) nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |