- Moose-dev - INF Mailman

Re: [Pharo-project] Glamour theme now loads in Pharo1.2

by Tudor Girba

Thanks, Fernando! Doru On 28 Oct 2010, at 15:28, Fernando Olivero wrote: > Name: Glamour-Morphic-Theme-FernandoOlivero.22 > Author: FernandoOlivero > Time: 28 October 2010, 3:26:49 pm > UUID: fa2bf315-5143-4e38-8e1d-6563510b1169 > Ancestors: Glamour-Morphic-Theme-tg.21 > > Ported the style to Pharo1.2. > Dropped the usage of MenuIcons, because this class was deprecated, now each theme defines its own Icons class. > See GLMUIThemeIcons. -- www.tudorgirba.com "What we can governs what we wish."

14 years, 8 months

2
2
0 0

Re: a question with glamour

by Esteban Lorenzano

Ok... I'll try to explain my scenario, I think I must be something wrong: 1) I'm embedding a browser in my own window (I'm not opening them using #openOn:). btw, this leads to an override in GLMMorphicPaneRenderer>>#render: to check if window is nil) 2) Outside the glamour browser, in another place of the window, I have a bunch of buttons. 3) that buttons should be enabled/disabled depending some of the selections of the browser I hope this made my needs clearer... and of course, if I'm using glamour in a wrong way, please let me know. Cheers, Esteban

14 years, 8 months

4
6
0 0

Glamour doesn't load in Pharo 1.1.1

by Lukas Renggli

I have problems building a Glamour image from the Metacello Configuration. Looks like something is wrong with Mondrian: "Name not found: Mondrian" http://hudson.lukas-renggli.ch/job/Glamour/181/console Lukas -- Lukas Renggli www.lukas-renggli.ch

14 years, 8 months

2
1
0 0

Re: PackageOrganizerCache

by Stéphane Ducasse

On Oct 27, 2010, at 4:27 PM, 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. Yes > - 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 ? yes > - 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 ? Checking extension of a package and package of a class. Stef

14 years, 8 months

1
0
0 0

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

14 years, 8 months

1
0
0 0

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 ?

14 years, 8 months

2
1
0 0

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

14 years, 8 months

5
5
0 0

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

14 years, 8 months

2
3
0 0

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

14 years, 8 months

1
0
0 0

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

14 years, 8 months

4
3
0 0

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

14 years, 8 months

4
5
0 0

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

14 years, 8 months

1
0
0 0

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

14 years, 8 months

2
1
0 0

Re: could we have a fly by help with the syntax in the query pane?

by Stéphane Ducasse

yes under the list of items On Oct 26, 2010, at 9:19 AM, Tudor Girba wrote: > You mean in the MooseFinder? > > Doru > > > On 25 Oct 2010, at 14:49, Stéphane Ducasse wrote: > >> cyrille >> >> this would good to have a flybyhelp in the query pane. >> >> Stef >> _______________________________________________ >> 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." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 8 months

2
1
0 0

Re: a question with glamour

by Stéphane Ducasse

On Oct 25, 2010, at 12:45 PM, Esteban Lorenzano wrote: > Hi, > I'm making my "first steps" with glamour and I have a question (a couple of then, actually). Excellent. I want to start too. > > 1) I what to hear some events, like for example when something changes in a list > 2) I what to pre-select some item in a list > > How I can do this? > > Thanks, > Esteban > _______________________________________________ > 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

could we have a fly by help with the syntax in the query pane?

by Stéphane Ducasse

cyrille this would good to have a flybyhelp in the query pane. Stef

14 years, 8 months

2
1
0 0

Re: a question with glamour

by Esteban Lorenzano

Hi, I'm still lost here :( What I want is to listen the GLMTreeMorphSelectionChanged event, and I can't find a way to do it... and the example is a little bit confusing for me :(. Cheers, Esteban

14 years, 8 months

2
1
0 0

a question with glamour

by Esteban Lorenzano

Hi, I'm making my "first steps" with glamour and I have a question (a couple of then, actually). 1) I what to hear some events, like for example when something changes in a list 2) I what to pre-select some item in a list How I can do this? Thanks, Esteban

14 years, 8 months

2
1
0 0

Re: PackageCacheTest failing

by Simon Denier

On 24 oct. 2010, at 10:26, Tudor Girba wrote: > Hi, > > It looks like we have one failing test. > > This is due to the fact that somehow we have a new Collections package in our image, and because of that counting the amount of packages in the cache fails. This is: > a PackageInfo(Collections-CharacterMap) > > In a previous image, we did not have that even though the base image is just the same. Does anyone know where this comes from? Apparently, this is a dependency coming from XMLSupport. CharacterMap is referenced in class-side initializer. The package dependency was a bit difficult to track down, it is actually a monticello required package of XML-Parser. I guess we should just update the test (although I would like the dependency to CharacterMap to appear in the Configuration, rather than as a required package) Name: XML-Parser-JAAyer.97 Author: JAAyer Time: 23 October 2010, 12:38:30 pm UUID: 9b2bd823-569f-447a-a7bc-a8c9fd474f5f Ancestors: XML-Parser-JAAyer.96 Dependencies: Collections-CharacterMap-JAAyer.1 * #qualifiedName is deprecated; #name suffices. * Refactored XMLNodeTest and XMLNestedStreamReader * CharacterMap is now bundled separately. -- Simon

14 years, 8 months

2
1
0 0

PackageCacheTest failing

by Tudor Girba

Hi, It looks like we have one failing test. This is due to the fact that somehow we have a new Collections package in our image, and because of that counting the amount of packages in the cache fails. This is: a PackageInfo(Collections-CharacterMap) In a previous image, we did not have that even though the base image is just the same. Does anyone know where this comes from? Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

14 years, 8 months

1
0
0 0

Reporting system

by Cyrille Delaunay

Hello, The reporting system based on arki, on which I work, start to be 'usable'. Some goals was to: - implement a first set of concerns to be able to make a first try with pharo as model ( http://code.google.com/p/moose-technology/wiki/PharoHealthSystem) - have an interface allowing to easily build, modify, save, display reports (an extended arki browser). - be able to export a report as MSE, then be able import a mse file. For now all of that seem to work not so bad :) but I'm sure there is a lot of thing to change, improve that I have not yet (or maybe no longer) in mind. If you want to have a look you can evaluate this script in a fresh moose image: Gofer new squeaksource: 'MooseDemoReport'; package: 'System-Benchmarking'; load. Gofer new squeaksource: 'MooseDemoReport'; package: 'MooseComputedConcerns'; load. Then you can simply right click on a model in the moosePanel, 'open arki reporter', and follow instructions. Any comment about: how it could better, what you would like to be able to do, things that seems to be wrong or not well implemented are welcome. The name of the repository is clearly bad, and I have also to change the name of of the package. An idea for the package name is: Menssana, (shortcut for "Mens sana in corpore sano"). If you have any suggestion, I would be really happy. A think with which I have some difficulties, is to see the 'borders' between this package and the arki package. We have an arki package providing the basic structure to build reports and this new package mainly making extensions to the arki package. So I don't know if some things should be merged, and what should be merged? Then I think I could start to set up automatic jobs with hudson that archive (at least for now) the mse exported files of a 'PharoHealthReport'. Then see how we manage to deal with the 'evolution' aspect

14 years, 8 months

3
3
0 0

smalldude tests

by Tudor Girba

Hi Cyrille, Your modifications to SmallDude look nice, but they make the tests fail because probably some entities are not initialized with the mooseModel. Please take a look, because right now the Moose build is yellow. Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

14 years, 8 months

1
1
0 0

Re: [Fame] MooseEntity >>handleFameProperty:value:

by Simon Denier

On 21 oct. 2010, at 17:34, Cyrille Delaunay wrote: > > > 2010/10/21 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hello, > > Currently, i'm looking a bit at the way moose export and import entities using Fame descriptions. > handleFameProperty:value: is a method used by fame when we try to set a value to an attribute not described in the current metaModel used to import. By default It does nothing and just inform by writing in the Transcript. > > A thing that I understand (or at least that I think I understand :)) is that the method handleFameProperty:value: is overriden by MooseEntity for this reason: > If an attribute is not described in the metaModel, this is certainly a property from the cache and therefore we should store this value in the cache of the element. This is what the method handleFameProperty:value: does in MooseEntity. > > I was wondering if it would be a good idea to look before if a mutator selector does not exist for the property name and only after that store in the cache. Usually when you use the classic exporter from moose, you can not be in this case, because the metamodel use to export is exactly the same than the one to import. It could be. This is what Fame does anyway for regular property. > In my case,I generate my own metaModel to export (subclassing PragmaProcessor) and export some property that are not described with Fame pragmas (what did usually the classic exporter). Those properties will therefore be lost. > Maybe the idea is also that if you export with a specific metaModel, you should import with this same specific metaModel ? > > In fact I guess this is the best solution :) I am able to re-compute the meta-model, give it to the fame importer and it seems to work well. > At least you are aware of my thoughts of the day :) Yes that's certainly the way to go. I want to be able to quickly specify a metamodel to reuse Fame facilities like import-export. Then let Fame handles all the process. We will se tomorrow for the thing with pragma :) -- Simon

14 years, 8 months

1
0
0 0

[Fame] MooseEntity >>handleFameProperty:value:

by Cyrille Delaunay

Hello, Currently, i'm looking a bit at the way moose export and import entities using Fame descriptions. handleFameProperty:value: is a method used by fame when we try to set a value to an attribute not described in the current metaModel used to import. By default It does nothing and just inform by writing in the Transcript. A thing that I understand (or at least that I think I understand :)) is that the method handleFameProperty:value: is overriden by MooseEntity for this reason: If an attribute is not described in the metaModel, this is certainly a property from the cache and therefore we should store this value in the cache of the element. This is what the method handleFameProperty:value: does in MooseEntity. I was wondering if it would be a good idea to look before if a mutator selector does not exist for the property name and only after that store in the cache. Usually when you use the classic exporter from moose, you can not be in this case, because the metamodel use to export is exactly the same than the one to import. In my case,I generate my own metaModel to export (subclassing PragmaProcessor) and export some property that are not described with Fame pragmas (what did usually the classic exporter). Those properties will therefore be lost. Maybe the idea is also that if you export with a specific metaModel, you should import with this same specific metaModel ?

14 years, 8 months

1
1
0 0

Diver: Dynamic Interactive Views For Reverse Engineering

by Alexandre Bergel

Related to Moose somehow... http://diver.sourceforge.net/ Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 8 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