Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

The kind of stuff I do not like with glamour

by stephane ducasse

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

14 years, 6 months

Re: The kind of stuff I do not like with glamour

by Stéphane Ducasse

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?

14 years, 6 months

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

by Stéphane Ducasse

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

14 years, 6 months

VerveineJ and InFusion

by anquetil.nicolas＠gmail.com

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

14 years, 6 months

method parentPackage

by Cyrille Delaunay

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 ?

14 years, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev