- Moose-dev - INF Mailman

wizard for VerveineJ

by Cyrille Delaunay

see: http://code.google.com/p/moose-technology/issues/detail?id=483&q=verveinej%…

14 years, 7 months

1
0
0 0

jniport / javaconnect and verveinej

by Tudor Girba

Hi Cyrille, Would you have a bit of time to try to connect to verveinej using jniport or javaconnect? It would be an interesting experience for us, especially that you would have access to the java code now. Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

14 years, 8 months

2
6
0 0

Follow-up on Menssana project

by Simon Denier

Hi Here are some news on the Menssana project, which is being built up by Cyrille and me. Remember the goal is to provide high level reports of Smalltalk systems health, using Pharo tools and Moose tools. We have made progress on different points, and we now start to have the full workflow from the source code in Pharo 1.2 to a report browser served by Seaside. Here is how it works: 1) hudson jobs retrieve and update a Pharo 1.2 Core image, also load Moose 2) hudson jobs compute reports on 1.2 and export results as mse files, which are then archived 3) Seaside server offers to browse archived results through a Glamour browser If you want to get a feeling, you can get a working demo with a few steps (and some time) a) Fetch the latest moose+seaside image: http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/lastSucces… b) Run script in a workspace Gofer new squeaksource: 'PharoBenchmarks'; package: 'System-Benchmarking'; load. Gofer new squeaksource: 'Arki'; package: 'Arki-Menssana'; package: 'Arki-MenssanaBrowser'; load c) Start the Seaside server WAKom startOn: 8080. d) Run the script |report| "this part is normally done by Hudson" report := MooseReports createReportFrom: #pharoHealthReport on: MooseReports createModelForPharoKernel. REPConcernBrowserWithActions new browser registerInSeasideOn: report root e) Fire up a browser with the url http://localhost:8080/glamour/pluggable In this demo report results are computed on the fly while you browse the report. So browsing some items may take some times at first as they are lazily computed. -- Simon

14 years, 8 months

2
2
0 0

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

by Stéphane Ducasse

yes I never know what I can type in there. On Oct 26, 2010, at 2:06 PM, Cyrille Delaunay wrote: > What is a fly by help? a popup window describing how it should be used ? > > 2010/10/26 Stéphane Ducasse <stephane.ducasse(a)inria.fr> > 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 > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 8 months

3
3
0 0

Re: Glamour

by Stéphane Ducasse

no ooooooooooooo Don't limit yourself show us your errors your errors are coool Glamour API should be better :) Stef On Nov 4, 2010, at 12:50 PM, Benjamin wrote: > Ouups :s > > > I'll try to open my both eyes before sending a mail now :) > > > Thank you > > Ben > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 8 months

3
4
0 0

Re: Glamour

by Stéphane Ducasse

On Nov 4, 2010, at 2:43 PM, Hannes Hirzel wrote: > Actually the Glamour API could be considered to be an internal DSL to > describe browsers. I assume that a forth and five iteration are > necessary to make it more user friendly. That is the reason why I did > not pursue Glamour this May. I thought instead of going for Glamour I > can just go through the effort of learning the ToolBuilder builder DSL > -- which in the end is not more difficult either. but glamour is not comparable with toolbuilder. Now do you have all the polymorph widgets described as toolbuilder spec? Because this is the problem. > A note aside: Maybe I push the idea of DSL too much here. The question > is: where do we talk about an API and where does the DSL idea start? > > However --- though there are alot examples -- even more example will > help and I recently enjoyed trying out some of them in the > Moose-Glamour-Image. > > --Hannes > > On 11/4/10, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> no ooooooooooooo >> >> Don't limit yourself show us your errors >> >> >> your errors are coool >> >> Glamour API should be better :) >> >> Stef >> >> On Nov 4, 2010, at 12:50 PM, Benjamin wrote: >> >>> Ouups :s >>> >>> >>> I'll try to open my both eyes before sending a mail now :) >>> >>> >>> Thank you >>> >>> Ben >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > 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: Glamour

by Stéphane Ducasse

I like your spirit :) and this is great to see your questions. Stef On Nov 3, 2010, at 1:04 PM, Benjamin wrote: > hello, there still are things I do not understand in your examples, and I hope you could help me because I really want to understand how Glamour works ^^ > > When you write : > > t1 transmit to: #three; > from: #one -> #selectionPath; > > what happen ? > > Because I have looked for implementors of selectionPath, put a self halt in each of them, run your browser, but no halt has been thrown, so I'm confused (again). > > Moreover, I now know how to show a list, and how to pass the selected items from the list to another column/row, but I wonder how to use the selected item as a parameter for a method and how to get the answer of this method back to be used in another part. > > > I keep hope to understand how it works ^^ > > > > Benjamin > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 8 months

3
4
0 0

Re: PackageOrganizerCache

by Stéphane Ducasse

On Oct 27, 2010, at 4:48 PM, Simon Denier wrote: > > 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... So far this is not done in RPackage because the event were not there. But now they are available so we should check that. I will check and discuss that with cyrille because this will help us. > 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). I do not know. So long that I looked at Rpackage. > Anyway, it's a problem specific to the Smalltalk importer, not to Moose or Famix in general. > > -- > Simon > > > > > _______________________________________________ > 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: [Pharo-project] Proposal: adding 261 named colors

by Alexandre Bergel

Hi! The last version of Mondrian contains the class XKCDColor produced by Johan Fabry. You can try (also accessible from the example menu in a MOEasel/examples/colors: | cols | cols := (XKCDColor colormap keys collect: [:cnam | XKCDColor named: cnam]) sortedAs: #hue. view shape rectangle withoutBorder. view nodes: cols forEach: [:col | view shape rectangle fillColor: col; width: 65; height: 25. view node: col. view shape label text: col name. view node: col. view verticalLineLayout]. view gridLayout gapSize: 0 Cheers, Alexandre On 3 Nov 2010, at 11:07, Johan Fabry wrote: > Hi Doru, Alex, > > I dont know how this is advancing for Pharo, apparently it is not considered a priority (which I understand of course). So in the mean time you could consider adding it to Mondrian/Moose, as Doru said. The .st file is in attachment, a Mondrian script to produce a reasonably sorted overview of the colors is below. Maybe you will want to do some cleaning/censoring of color names. I personally think that there is no harm here but I have been known to be liberal sometimes :-) > > |cols| > cols := SortedCollection new sortBlock: [:c1 :c2 | (c1 hue) > (c2 hue) ]. > cols addAll: (XKCDColor colormap keys collect: [:cnam | XKCDColor named: cnam]). > view shape rectangle withoutBorder. > view nodes: cols > forEach: [:col | view shape rectangle fillColor: col; width: 65; height: 25. view node: col. view shape: (MORectangleShape new text: col name; withoutBorder). view node: col. view verticalLineLayout]. > view gridLayout gapSize: 0 > > <XKCDColor.st> > > On 24 Oct 2010, at 04:12, Tudor Girba wrote: > >> Hi Johan, >> >> I would definitely be interested in getting this as an external library around Mondrian and Moose. >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 8 months

1
0
0 0

Larger fonts in DistributionMaps

by Mariano Martinez Peck

Hi. I need to have larger fonts for the legends of a DistributionMap. For example, in the attached screenshot I would like to use bigger fonts for the properties and for the packages names. Is that possible? I surf a little the code but I didn't find anything. Thanks in advance, Mariano

14 years, 8 months

1
1
0 0

Re: Glamour

by Stéphane Ducasse

On Nov 3, 2010, at 10:17 AM, Tudor Girba wrote: > Hi Stef, > > Thanks for pushing this. > > I definitely understand these issues, and a solution will follow in the near future. It is just a matter of effort, and until now the main goal was to get things going at the model level. This is now working quite well, so now it's time to focus on the rendering and on the API. good to hear that. > The only thing is that the API will only grow from people using it. With Mondrian, we could do it by having it used by a small amount of people. Glamour is a more complicated engine, and getting the right API right is not as straightforward. What you have right now is already the third version. I imagine > The rest of the comments are inlined. > >> I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools >> with glamour. Alain told me that he will have a look too. >> >> Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves >> and that was frustrating: mismatch of block arguments or something like that. > > This was a mismatch of the returned type. Still the point is how can we make sure that we can debug it because the model is aligned with our mental model. > >> This is this aspect of glamour that I would like to see lowered. >> You see even reading your answer and looking at the code I do not get it. :( >> >> then some questions: >> >> why children: [:item :x :level | >>>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >> >> could not be >> >> child: childObject level: level.... > > Basically, for every item, we want to know how to build the children collection. When you need to reason about multiple things, you need to pass them as a parameter in the block. > > Perhaps we can have something like: > > children: aBlock > children: aBlock atLevel: anInteger > children: aBlock atLevelHigherThan: anInteger Yes >> I have no idea what is x. > > in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object. This is an hidden assumption and without an example I would have no idea that I should pass 3 arg block. Blocks used at their limits are evil since they do not have names. >> So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. >> So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having >> less scripting and more programming api would help). > > The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days. Good. I'm eager to see that. Now consider that your focus should not be on scripting (you have that API) but on how to build classes and use the power of classes to achieve build the same browsers.

14 years, 8 months

3
4
0 0

VerveineJ enhancements

by anquetil.nicolas＠gmail.com

Hi, just to announce that following Doru's suggestions I added/changed some features to VerveineJ: - primitive types are exported as Famix PrimitiveType - interfaces are exported as Famix Class with the isInterface flag set to true - entities outside the parsed source code (libraries, etc.) are flagged as stubs (except the PrimaryTypes which are outside the parsed code anyway) - opened some issues (see below) in the google-code page for verveine (should create a Component-Verveine to simplify entering issues) Yet to be done: - create a Famix Interface entity: requires changing the meta model so I will wait a bit for that - compute and export some metrics (probably the next one on my list) - in FileAnchors store the relative path to the code instead of fullpath - export exceptions - export annotations - set next/previous for the associations nicolas -- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod

14 years, 8 months

2
1
0 0

Re: Glamour

by Stéphane Ducasse

doru I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools with glamour. Alain told me that he will have a look too. Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves and that was frustrating: mismatch of block arguments or something like that. This is this aspect of glamour that I would like to see lowered. You see even reading your answer and looking at the code I do not get it. :( then some questions: why children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. could not be child: childObject level: level.... I have no idea what is x. So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having less scripting and more programming api would help). I understand that right now you want to script your browser in a workspace. But when the script gets bigger and gets hosted in a class then not using method is frustrating. so having an API for scripting is one point but it would be good to have the counterpart when we code class because at the end we will code classes. Stef > Hi Benjamin, > > First of all, welcome :). > > Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference. > > Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes. > > Cheers, > Doru > > > On 2 Nov 2010, at 19:12, Benjamin wrote: > >> Hi everybody, >> >> I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all >> >> >> Here is my code : >> >> recentSetBrowser >> | browser | >> >> browser := GLMTabulator new. >> browser column: #one. >> browser showOn: #one; using: [ >> browser tree >> title: 'Tree'; >> children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [item size ]]]. >> ^browser >> >> Here is the example : >> >> treeWithChildrenByLevel >> |browser | >> >> browser := GLMTabulator new. >> browser column: #one; column: [:c | c row: #two; row: #three]. >> browser showOn: #one; using: [ >> browser tree >> title: 'Tree'; >> children: [:item :x :level | >> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. >> browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. >> browser showOn: #three; from: #one->#selectionPath; using: [ >> browser text title: 'Selection path preview']. >> ^ browser >> >> When I run >> GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') >> the debugger answer : >> 'MessageNotUnderstood: SmallInteger>>collect:' ... >> >> If someone can help me :) >> >> >> >> >> >> Benjamin Van Ryseghem >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > 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

Glamour

by Benjamin

Hi everybody, I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all Here is my code : recentSetBrowser | browser | browser := GLMTabulator new. browser column: #one. browser showOn: #one; using: [ browser tree title: 'Tree'; children: [:item :x :level | level > 1 ifTrue: [#()] ifFalse: [item size ]]]. ^browser Here is the example : treeWithChildrenByLevel |browser | browser := GLMTabulator new. browser column: #one; column: [:c | c row: #two; row: #three]. browser showOn: #one; using: [ browser tree title: 'Tree'; children: [:item :x :level | level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]]. browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ]. browser showOn: #three; from: #one->#selectionPath; using: [ browser text title: 'Selection path preview']. ^ browser When I run GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau') the debugger answer : 'MessageNotUnderstood: SmallInteger>>collect:' ... If someone can help me :) Benjamin Van Ryseghem

14 years, 8 months

2
3
0 0

disappearing menu

by Fabrizio Perin

Hi, i have a problem with the moose panel: when i load my stuff (MooseJEE) i have a group of database tables which has defined on top 2 visualizations. When i load a model form a MSE file, the first time that i click on that entity it is actually recognized has a TableGroup (see figure 1). When i click a second time on it it not consider anymore a TableGroup but just a MooseGroup, consequently i loose all the information specifically related with the table group (see figure 2). I define my group like this: mooseModel>>>allTables <navigation: 'All Data Base Tables'> | group | group := self allWithType: MJFAMIXTable ofGroupClass: MJFAMIXTablesGroup. group description: 'All Data Base Tables'. ^group SessionBeans group has the same definition but it works all the time. Any ideas on which could be the problem? Cheers, Fabrizio

14 years, 8 months

2
5
0 0

Re: Class renaming in Moose Algos Graph

by Stéphane Ducasse

We do not want that. Stef > Ok, this an old thread, but I found that this idea was already implemented in Pharo: > > http://www.youtube.com/watch?v=n4I7fSVNX2A > > In order to use it you need to execute: > > MCHttpRepository > location: 'http://www.squeaksource.com/Environments' > user: '' > > password: '' > > I tested it and it works. It only applies to classes that you explicitly define in a package and you need to use a new system browser that is package aware. > > What do you think about using this on Moose instead of having class prefixes? > > Cheers, > Guillermo. > > On Tue, Sep 28, 2010 at 9:16 AM, Guillermo Schwarz <guillermo.schwarz(a)gmail.com> wrote: > Hi Guys, > > Why don't you do something more focused on the long term and don't you change the Smalltalk compiler with namespaces? > > I don't think it should be that hard since each class already belongs to a category. Each category could instead be a dictionary from where the compiler could find classes that are mentioned in the class source. > > This has worked wonders in Java (classes inside packages). This way classes' names can be repeated ad eternum without generating collisions or otherwise polluting excessively the name space. > > So for example: > > FAMIXAssociation subclass: #FAMIXInvocation > instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' > classVariableNames: '' > poolDictionaries: '' > category: 'Famix-Core' > > Would be instead: > > Association subclass: #Invocation > instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' > classVariableNames: '' > poolDictionaries: '' > category: #FamixCore > > Then the category would be an index in the SystemDictionary: > > SystemDictionary at: #FamixCore put: Category new. > > (SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this should be done automatically by the subclass: method above" > > (SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that are referenced by classes belonging to category #FamixCore" > > What do you think? > > Cheers, > Guillermo. > > Message: 1 > Date: Mon, 27 Sep 2010 22:00:33 +0200 > From: Tudor Girba <tudor.girba(a)gmail.com> > Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph > To: Moose-related development <moose-dev(a)iam.unibe.ch> > Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hi Simon, > > These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change. > > Cheers, > Doru > > > On 27 Sep 2010, at 19:42, Simon Denier wrote: > > > > > On 27 sept. 2010, at 18:17, Lukas Renggli wrote: > > > >> Please note that the MA* (with an uppercase $A) prefix is already > >> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I > >> remember correctly they renamed their classes at some point a long > >> time ago to avoid the conflict with Magritte. > > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > _______________________________________________ > 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

Re: Class renaming in Moose Algos Graph

by Guillermo Schwarz

Hi Guys, Why don't you do something more focused on the long term and don't you change the Smalltalk compiler with namespaces? I don't think it should be that hard since each class already belongs to a category. Each category could instead be a dictionary from where the compiler could find classes that are mentioned in the class source. This has worked wonders in Java (classes inside packages). This way classes' names can be repeated ad eternum without generating collisions or otherwise polluting excessively the name space. So for example: FAMIXAssociation subclass: #FAMIXInvocation instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' Would be instead: Association subclass: #Invocation instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' classVariableNames: '' poolDictionaries: '' category: #FamixCore Then the category would be an index in the SystemDictionary: SystemDictionary at: #FamixCore put: Category new. (SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this should be done automatically by the subclass: method above" (SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that are referenced by classes belonging to category #FamixCore" What do you think? Cheers, Guillermo. Message: 1 Date: Mon, 27 Sep 2010 22:00:33 +0200 From: Tudor Girba <tudor.girba(a)gmail.com> Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph To: Moose-related development <moose-dev(a)iam.unibe.ch> Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com> Content-Type: text/plain; charset=us-ascii Hi Simon, These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change. Cheers, Doru On 27 Sep 2010, at 19:42, Simon Denier wrote: > > On 27 sept. 2010, at 18:17, Lukas Renggli wrote: > >> Please note that the MA* (with an uppercase $A) prefix is already >> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I >> remember correctly they renamed their classes at some point a long >> time ago to avoid the conflict with Magritte. >

14 years, 8 months

2
2
0 0

Re: [Pharo-project] Fwd: about OPAX

by Stéphane Ducasse

Thanks!!! On Oct 31, 2010, at 8:06 PM, Tudor Girba wrote: > Done. > > Doru > > On 31 Oct 2010, at 12:17, Stéphane Ducasse wrote: > >> Hi doru >> >> could you take 15 min and add comments to the OPAX classes? >> in XMLSupport. There is not a line of comments, so I know that this is your private code that got there but still. >> >> Stef >> >> >> >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >

14 years, 8 months

1
0
0 0

Re: [Pharo-project] Fwd: about OPAX

by Tudor Girba

Done. Doru On 31 Oct 2010, at 12:17, Stéphane Ducasse wrote: > Hi doru > > could you take 15 min and add comments to the OPAX classes? > in XMLSupport. There is not a line of comments, so I know that this is your private code that got there but still. > > Stef > > > > -- www.tudorgirba.com "Don't give to get. Just give."

14 years, 8 months

1
0
0 0

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

by Stéphane Ducasse

On Oct 30, 2010, at 9:23 PM, Tudor Girba wrote: > Hi Stef, > > Thanks for looking into this. I think these kind of discussions are important. yes this is why I send it. I will try to allocate some time to play with glamour. I was looking at GMSTBrowser or something like that too but just browsing > > The goal of this notation was to keep the language as simple as possible, but in this case it would indeed be better to have a different selector for the composite. > > I do not like rowNamed: / columnNamed: because they are just too long. I will introduce a compositeRow: and compositeColumn: for the composite ones, and keep row: / column: for the single ones. As a transitory phase, we will still be able to send a block to row:/column: for a while. ok Everything that make glamour spec more smalltalkish and less block oriented is good to me. :) > > Cheers, > Doru > > > On 30 Oct 2010, at 18:06, stephane ducasse wrote: > >> 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 >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > _______________________________________________ > 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

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

2
1
0 0

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

1
0
0 0

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

1
0
0 0

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

4
5
0 0

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

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev