Re: PackageOrganizerCache
by Simon Denier
On 27 oct. 2010, at 16:27, Cyrille Delaunay wrote:
> Hello,
>
> I'm currently looking at the use of the PackageOrganizerCache in Moose.
> There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage.
> So before doing anything, I would like to know more about the use of PackageOrganizerCache:
> - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system.
> - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ?
> - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ?
Basically, yes, yes, and yes.
The current package system (PackageOrganizer + PackageInfo) is reeeally slow for some tasks, like computing package of methods (to detect class extensions), and it really brought down the Smalltalk importer to its knee on even not so large models. The big problem now is linking the package organizer to system events, so that it updates itself whenever a package is added, renamed, removed, changed... This was not done with PackageOrganizerCache because it's a bit difficult and because it was just a workaround at the time. Now RPackage should replace the current organizer and has to take care of such events. It also appear that RPackage initializes itself faster than PackageOrganizerCache (probably because it's more clever in its usage of PackageInfo API).
Anyway, it's a problem specific to the Smalltalk importer, not to Moose or Famix in general.
--
Simon
12 years, 11 months
PackageOrganizerCache
by Cyrille Delaunay
Hello,
I'm currently looking at the use of the PackageOrganizerCache in Moose.
There was some work in pharo about a new, more performant, better-structured
(I think it's the idea ? :)) 'Package system' called RPackage.
So before doing anything, I would like to know more about the use of
PackageOrganizerCache:
- Why do we use a cache ? I guess this is because accessing directly parent
packages of specific classes or methods was to slow using the current
package system.
- If this is the good answer :), why was it too long? could another package
system (RPackage) solve this problem and avoid us to use a cache ?
- For which kind of task is used the packageCache in Moose? I saw that it
was used at the import of smalltalk code, to link classes and method to
their parent package, is that all ?
12 years, 11 months
Re: VerveineJ v. 1.0 released
by Stéphane Ducasse
On Oct 26, 2010, at 7:33 PM, Johan Fabry wrote:
>
> That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
>
> I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
> and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
>
> On 26 Oct 2010, at 13:40, Nicolas Anquetil wrote:
>
>> Hi all,
>>
>> We have been mentionning it in past emails on the list, but we are
>> pleased to announce officially the first release of VerveineJ : a Java
>> to MSE exporter.
>>
>> You can get it from https://gforge.inria.fr/projects/verveinej/
>>
>> Anonymous checkout is possible with the command:
>>
>> svn checkout svn://scm.gforge.inria.fr/svn/verveinej/verveine.extractor.java
>>
>> VerveineJ is based on the Eclipse JDT parser (JDT = Java Development
>> Toolkit) and binding resolver.
>> However, you don't need to install eclipse to run it, the necessary
>> libraries are included.
>>
>> VerveineJ can be ran more or less as a java compiler, you specify the
>> source path, the class path, possibly the java version (1.2, 1.3, ...)
>> etc.
>> and it should create an "output.mse" file with all your entities and
>> their relationship (inheritances, accesses, references, and
>> invocations).
>>
>> A shell script "verveine.sh" should help the new comers to execute
>> their first export:
>>
>> $ verveinej <some-Java-sourcedir>
>>
>>
>> VerveineJ has already been used to create an MSE model of Eclipse (v.
>> 3.1): >346000 FAMIX.Entities ; >7800 classes, >53500 methods, >147000
>> invocation, etc.
>>
>>
>> And of course it is free software, so you can get your hands dirty and
>> hack it to do what you need. It is as simple as visiting an AST (i.e.
>> Abstract Syntax Tree, of course!).
>>
>> nicolas
>>
>> PS: If I can find the time to get CDT (Eclipse C/C++ Development
>> Toolkit) to work in batch mode, a VerveineC is planned in the
>> not-too-distant-I-hope future.
>> Help welcome :-)
>>
>> --
>> 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
>
> --
> Johan Fabry
> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12 years, 11 months
parser for beginning of a line
by Tudor Girba
Hi,
I have a case of a language that uses a line based syntax.
Here is an example:
'
label1 => any kind of
text on many lines
label2 => more text on
many
lines
label3 => more text'
This should get 3 key-value pairs.
My current solution goes like this:
key := #newline asParser , ('=>' asParser / #newline asParser) negate star , '=>' asParser.
p := (key trimBlanks, key negate star flatten) star.
However, this is quite ugly. One idea to make it simpler would be to have a parser for the beginning of the line. What do you think?
Cheers,
Doru
--
www.tudorgirba.com
"When people care, great things can happen."
12 years, 11 months
Re: VerveineJ v. 1.0 released
by Simon Denier
That's good news! We should put something on the website + a page with the doc
On 26 oct. 2010, at 18:41, Nicolas Anquetil wrote:
> Hi all,
>
> We have been mentionning it in past emails on the list, but we are
> pleased to announce officially the first release of VerveineJ : a Java
> to MSE exporter.
>
> You can get it from https://gforge.inria.fr/projects/verveinej/
>
> Anonymous checkout is possible with the command:
>
> svn checkout svn://scm.gforge.inria.fr/svn/verveinej/verveine.extractor.java
>
> VerveineJ is based on the Eclipse JDT parser (JDT = Java Development
> Toolkit) and binding resolver.
> However, you don't need to install eclipse to run it, the necessary
> libraries are included.
>
> VerveineJ can be ran more or less as a java compiler, you specify the
> source path, the class path, possibly the java version (1.2, 1.3, ...)
> etc.
> and it should create an "output.mse" file with all your entities and
> their relationship (inheritances, accesses, references, and
> invocations).
>
> A shell script "verveine.sh" should help the new comers to execute
> their first export:
>
> $ verveinej <some-Java-sourcedir>
>
>
> VerveineJ has already been used to create an MSE model of Eclipse (v.
> 3.1): >346000 FAMIX.Entities ; >7800 classes, >53500 methods, >147000
> invocation, etc.
>
>
> And of course it is free software, so you can get your hands dirty and
> hack it to do what you need. It is as simple as visiting an AST (i.e.
> Abstract Syntax Tree, of course!).
>
> nicolas
>
> PS: If I can find the time to get CDT (Eclipse C/C++ Development
> Toolkit) to work in batch mode, a VerveineC is planned in the
> not-too-distant-I-hope future.
> Help welcome :-)
>
> --
> 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
--
Simon
12 years, 11 months
VerveineJ v. 1.0 released
by Nicolas Anquetil
Hi all,
We have been mentionning it in past emails on the list, but we are
pleased to announce officially the first release of VerveineJ : a Java
to MSE exporter.
You can get it from https://gforge.inria.fr/projects/verveinej/
Anonymous checkout is possible with the command:
svn checkout svn://scm.gforge.inria.fr/svn/verveinej/verveine.extractor.java
VerveineJ is based on the Eclipse JDT parser (JDT = Java Development
Toolkit) and binding resolver.
However, you don't need to install eclipse to run it, the necessary
libraries are included.
VerveineJ can be ran more or less as a java compiler, you specify the
source path, the class path, possibly the java version (1.2, 1.3, ...)
etc.
and it should create an "output.mse" file with all your entities and
their relationship (inheritances, accesses, references, and
invocations).
A shell script "verveine.sh" should help the new comers to execute
their first export:
$ verveinej <some-Java-sourcedir>
VerveineJ has already been used to create an MSE model of Eclipse (v.
3.1): >346000 FAMIX.Entities ; >7800 classes, >53500 methods, >147000
invocation, etc.
And of course it is free software, so you can get your hands dirty and
hack it to do what you need. It is as simple as visiting an AST (i.e.
Abstract Syntax Tree, of course!).
nicolas
PS: If I can find the time to get CDT (Eclipse C/C++ Development
Toolkit) to work in batch mode, a VerveineC is planned in the
not-too-distant-I-hope future.
Help welcome :-)
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
12 years, 11 months
Glamour on seaside includes Mondrian?
by Johan Fabry
Hi all,
quick question: the support for Glamour browsers on Seaside, does it include support for Mondrian (rendering as svg) and all the interaction features that Mondrian has? It would be cool if it did, I could have AspectMaps as a web app ...
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
12 years, 11 months
Re: VerveineJ v. 1.0 released
by Stéphane Ducasse
Thanks Nicolas!!!!!
And this is MIT licensed I imagine (now since you work for the university we should check
how we can this cleans).
Stef
> Hi all,
>
> We have been mentionning it in past emails on the list, but we are
> pleased to announce officially the first release of VerveineJ : a Java
> to MSE exporter.
>
> You can get it from https://gforge.inria.fr/projects/verveinej/
>
> Anonymous checkout is possible with the command:
>
> svn checkout svn://scm.gforge.inria.fr/svn/verveinej/verveine.extractor.java
>
> VerveineJ is based on the Eclipse JDT parser (JDT = Java Development
> Toolkit) and binding resolver.
> However, you don't need to install eclipse to run it, the necessary
> libraries are included.
>
> VerveineJ can be ran more or less as a java compiler, you specify the
> source path, the class path, possibly the java version (1.2, 1.3, ...)
> etc.
> and it should create an "output.mse" file with all your entities and
> their relationship (inheritances, accesses, references, and
> invocations).
>
> A shell script "verveine.sh" should help the new comers to execute
> their first export:
>
> $ verveinej <some-Java-sourcedir>
>
>
> VerveineJ has already been used to create an MSE model of Eclipse (v.
> 3.1): >346000 FAMIX.Entities ; >7800 classes, >53500 methods, >147000
> invocation, etc.
>
>
> And of course it is free software, so you can get your hands dirty and
> hack it to do what you need. It is as simple as visiting an AST (i.e.
> Abstract Syntax Tree, of course!).
>
> nicolas
>
> PS: If I can find the time to get CDT (Eclipse C/C++ Development
> Toolkit) to work in batch mode, a VerveineC is planned in the
> not-too-distant-I-hope future.
> Help welcome :-)
>
> --
> 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
12 years, 11 months
questions about FAMIXAnnotations
by Fabrizio Perin
Hi all,
i was looking at the model and i was wondering why the method annotationInstaces is defined into FAMIXEntity. I think that it should be defined into FAMIXSourcedEntity otherwise i can ask to a FAMIXAnnotationInstance which are its annotationInstances that is kind o weird because as far as i know you cannot annotate an annotation or can you do that?
Moreover in which sense annotationInstances is derived? I mean if i have an entity how can i calculate the annotaton instances without accessing the model directly?
Cheers,
Fabrizio
12 years, 11 months
