Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

The kind of stuff I do not like with glamour
by stephane ducasse 30 Oct '10

30 Oct '10

I was sending this email to doru but I forward it to moose-dev since other people use it and I would like to get more feedback on glamour. browser row: [ :r | r column: #namespaces; column: #classes; column: #methods ]; row: #details. I do not like that row: is used to declare columns and at the same time with a name to the row: why this is not rowNamed: #details then why browser row: (Column with: {#namespaces classes methods) Stef

2 1

Re: The kind of stuff I do not like with glamour
by Stéphane Ducasse 30 Oct '10

30 Oct '10

then browser transmit to: #namespaces; andShow: [ :a | a tree display: [ :model | model allNamespaces select: [ :each | each isRoot ] ]; children: [ :namespace | namespace childScopes ]; format: [ :namespace | namespace stubFormattedName ] ]. why format: is not named formatItem: if this is what is does? How as a reader should I know that format is sent to an item?

1 0

Re: [Pharo-project] Glamour theme now loads in Pharo1.2
by Stéphane Ducasse 29 Oct '10

29 Oct '10

Me too. Now it is much nicer. Sred > No problem! I really like the Glamour theme . > > I think i've messed up the window buttons mouse over form. If someone > can take a look at it. Something to do with the watery theme anwsering > the multistate button for maximize, minimize and close. > > Fernando > > On Fri, Oct 29, 2010 at 10:43 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> 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." >> >> >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

VerveineJ and InFusion
by anquetil.nicolas＠gmail.com 29 Oct '10

29 Oct '10

Hi, 1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know what went wrong the other time 2- I am attaching a zip file with the infusion and verveine generated mse files for the LanModel project (sources available with verveine.extractor.java). I hope this is not contrary to the rules of the list, the file is only 6K. There are differences, you can look at it and decide for yourselves which one you prefer. And if something strikes you as clearly wrong in Verveine, it can be changed to fit the expected behaviour. For example verveine creates Namespaces with their full java name: moose.lan.server, which can admittedly be less elegant when you nest them: moose :: moose.lan :: moose.lan.server infusion creates a more concise: moose :: lan :: server yet the name of the inner Namespace becomes "server", which does not seem to fit exactly the eclipse understanding of packages where packages are not nested ... (I know, Eclipse is not Java) I ran infusion and verveine on Eclipse v.3.1. It took about 3 min. for infusion and 1min for verveine which is not very significant given that you are suppose to do it only once. From my part, it could take one hour and I would not be too much worried (even if < 5 min is much better). And of course, infusion does much more things than verveine: it's a graphical tool, that computes metrics and does a bunch of other things. Verveine sole purpose is to generate MSE from java source. Actually I prefer the batch oriented philosophy of verveine that allows to call it in srcipt, and let Moose do all the fancy stuff. It used to be called the Unix philosophy: small tools that are good at what they do but don't try to do everything. (Does it makes me an old geek ?) I might be wrong, but infusion seems to accept only one root directory for the java project. This can be an issue. For example if you consider Eclipse that has code for Linux, Mac and windows, you may want to analyse only one of the versions to avoid duplicate classes (3 implementations of the Button class). VerveineJ allows to do this by specifying the source path (it is based on a "compiler" so it has all these options) That's about what I could see in the 10 minutes I devoted to it. nicolas -- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod

4 5

method parentPackage
by Cyrille Delaunay 29 Oct '10

29 Oct '10

Hello, Just a small question:) If a method is an extension from an external package, the attribute 'parentPackage' of the famixMethod should refer to: => the package of the class in which the method is defined? or => the external package extending this method ?

2 1

Re: [Pharo-project] Glamour theme now loads in Pharo1.2
by Tudor Girba 29 Oct '10

29 Oct '10

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

2 2

Re: a question with glamour
by Esteban Lorenzano 29 Oct '10

29 Oct '10

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

4 6

Glamour doesn't load in Pharo 1.1.1
by Lukas Renggli 27 Oct '10

27 Oct '10

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

2 1

Re: PackageOrganizerCache
by Stéphane Ducasse 27 Oct '10

27 Oct '10

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

1 0

Re: PackageOrganizerCache
by Simon Denier 27 Oct '10

27 Oct '10

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev