Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: Urget question about CodeCity
by Simon Denier 23 Sep '10

23 Sep '10

On 23 sept. 2010, at 12:25, Mariano Martinez Peck wrote: > > > On Thu, Sep 23, 2010 at 11:07 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > hi > > - because the mapping color <-> range does not match your expectations (like red would be highest, blue would be lowest) > > I guess because of this one. For example, take a look to the screenshot I attached. If I want to search the most instantiated classes, I should serach colors like Brown or Pink. But they are not easily shown....and of course, I have lot of colors...then I can to go with my "eye" looking carefully each package and looking for those colors. > > This is why I thoguht that CodeCity would be cool, in the sense that for this case it would be easier since the property would represent the height of a building...and it is easier to notice heigh than a color. > > I am trying now LinearDistributionMap and I think it can help :) > OK then you can set the mapping you want by sending #propertyColorMap: aDictionary to the distribution map. Easy to do. You could also define your own ordering, but this would require a bit more work I think (LinearDistributionMap does that) Finally, don't forget you can change 2D width/height before using the 3D :) Of course, this requires testing a bit with different layouts then (MOMinimumGridLayout is interesting when shapes have different sizes, it tries to group shapes so that lost space is minimized) -- Simon

1 0

Urget question about CodeCity
by Mariano Martinez Peck 23 Sep '10

23 Sep '10

Hi Folks...Sorry for the "urgen" but I got an idea for my paper with deadline tomorro hahahahah I was using DistributionMaps where the containers were packages for example, elements classes, and properties the amount of instances. For example, see the attached screenshot. Now....it is difficult to find the classes with most instances since I need to search for an specific color. I thoguht that having someting like CodeCity can be interesting. I would like: - EAch building (square) is a container -> package - Each little squeare (that has heigh) is a element -> class - The heigh is a property, in this case, the amount of instances for example. Then I can easily see packages/classes with several intances easily (the highest ones). So...is that possible? how easier? :) Right now I was doing my DM something like this: I checked for *City* class in Moose 4.1 but I didn't find anything :( The only thing I found was this link: http://www.moosetechnology.org/tools/vw/codecity Thanks for any help Mariano

3 5

News on Mondrian
by Alexandre Bergel 23 Sep '10

23 Sep '10

Hi! I am please to announce that Mondrian now includes an help and tutorial. These are accessible from the Easel menu and the World menu (help item). You can load Mondrian with: Gofer new squeaksource: 'Mondrian'; package: 'ConfigurationOfMondrian'; load. (Smalltalk at: #ConfigurationOfMondrian) perform: #loadDefault. I would be please to hear feedback on them. The PharoByExampleV2 chapter on Mondrian will be based on the tutorial. I am currently working on a Tutorial->Latex importer. What I did in the plane on the way back form esug. 582: No leaf class is abstract. Move down some methods from MOShape to MONodeShape 581: Help and tutorial finished. Added some new test and renamed a few things 580: easel examples are better commented and more descriptive 579: Added submenu in Easel help 578: MOAnnouncer>>forward: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Re: Moose on pharo 1.2
by Stéphane Ducasse 23 Sep '10

23 Sep '10

this is ok for me :) Stef On Sep 23, 2010, at 9:05 AM, Tudor Girba wrote: > The main reason for getting the Moose dev version on top of the latest Pharo dev version is because this is the simplest way to utilize the limited resources in the Smalltalk community. It is the same reason why I argue for Moose users to always use the latest Moose dev. Of course, it can be painful at times, but if you get enough users that feel the pain and that are willing to work with you, the core tends to become and stay stable. > > Cheers, > Doru > > > On 22 Sep 2010, at 16:31, Mariano Martinez Peck wrote: > >> >> >> On Wed, Sep 22, 2010 at 3:34 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: >> >> On 22 sept. 2010, at 15:20, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Sep 20, 2010 at 4:50 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >>> We have to make sure that Pharo 1.2 is working well. Yesterday, I couldn't inspect a value from the debugger because of an error raised with some mapping with closure. This is annoying. >>> >>> But 1.2 CAN be annoying. And it CAN be even unstable. That's why its label says "unstable". >>> You cannot make progress without breaking things. >>> >>> I see you guys (Moose) doing a lot of effort for Pharo 1.2....why you need so much that ? Maybe you should wait a little until Pharo 1.2 gets code freeze and releases a first beta or RC. >> >> >> As far as I'm concerned, I didn't even try to load Moose in Pharo 1.2 :) >> I just let other people debug the process for now... >> >> That's why I was asking whether 1.2 fixes could break a 1.1 image. If yes, it's already done and we can move on while retaining a stable dev environment. >> >> The only reason I found is what Stef said...if you want to help Pharo, report issues and fix them, then this is useful. >> >> >> >> Actually, we had another motivation to load Moose in 1.2 which was building Hudson reports, but we will probably try a different way now, using Metacello and Monticello importer. >> >> >> However, I do not think it is useful for a Hudson report. What is the sense of reporting if Moose breaks on PharoCore 1.2 if PharoCore1.2 can be broken even itself ?. >> >> Again, from my point of view, if you DO spend time trying to use Moose in Pharo 1.2, then create issues in Pharo and try to fix them. Otherwise, just wait until it is stable. >> >> >> >> >>> >>> Cheers >>> >>> Mariano >>> >>> >>> >>> Alexandre >>> >>> >>> >>> On 20 Sep 2010, at 10:43, Laval Jannik wrote: >>> >>>> I just tried to load Moose on pharo1.2 >>>> >>>> I only do this script (loading OB is not needed I think): >>>> >>>> ===== >>>> Gofer new >>>> squeaksource: 'rb'; >>>> package: 'AST-Core'; >>>> package: 'Refactoring-Core'; >>>> package: 'Refactoring-Critics'; >>>> package: 'Refactoring-Environment'; >>>> package: 'Refactoring-Spelling'; >>>> package: 'Refactoring-Changes'; >>>> load. >>>> >>>> Gofer new >>>> squeaksource: 'shout'; >>>> version: 'Shout-cyrille_delaunay.87'; >>>> package: 'ShoutWorkspace.1'; >>>> package: 'ShoutTests'; >>>> load. >>>> >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfOmniBrowser'; >>>> load. >>>> ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.1.5') load. >>>> >>>> Gofer new >>>> squeaksource: 'Moose'; >>>> package: 'ConfigurationOfMoose'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. >>>> ===== >>>> >>>> With Cyrille, we fix a part of error tests. Now, I'm not sure that it can work on Pharo1.1. >>>> So we do not save our work on moose repository. >>>> >>>> What do we do for next steps ? >>>> Do we change our Pharo system and go to 1.2 or working on 1.1 ? >>>> >>>> Cheers, >>>> --- >>>> Jannik Laval >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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 > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

2 1

Re: Moose on pharo 1.2
by Simon Denier 23 Sep '10

23 Sep '10

On 22 sept. 2010, at 15:20, Mariano Martinez Peck wrote: > > > On Mon, Sep 20, 2010 at 4:50 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > We have to make sure that Pharo 1.2 is working well. Yesterday, I couldn't inspect a value from the debugger because of an error raised with some mapping with closure. This is annoying. > > But 1.2 CAN be annoying. And it CAN be even unstable. That's why its label says "unstable". > You cannot make progress without breaking things. > > I see you guys (Moose) doing a lot of effort for Pharo 1.2....why you need so much that ? Maybe you should wait a little until Pharo 1.2 gets code freeze and releases a first beta or RC. As far as I'm concerned, I didn't even try to load Moose in Pharo 1.2 :) I just let other people debug the process for now... That's why I was asking whether 1.2 fixes could break a 1.1 image. If yes, it's already done and we can move on while retaining a stable dev environment. Actually, we had another motivation to load Moose in 1.2 which was building Hudson reports, but we will probably try a different way now, using Metacello and Monticello importer. > > Cheers > > Mariano > > > > Alexandre > > > > On 20 Sep 2010, at 10:43, Laval Jannik wrote: > > > I just tried to load Moose on pharo1.2 > > > > I only do this script (loading OB is not needed I think): > > > > ===== > > Gofer new > > squeaksource: 'rb'; > > package: 'AST-Core'; > > package: 'Refactoring-Core'; > > package: 'Refactoring-Critics'; > > package: 'Refactoring-Environment'; > > package: 'Refactoring-Spelling'; > > package: 'Refactoring-Changes'; > > load. > > > > Gofer new > > squeaksource: 'shout'; > > version: 'Shout-cyrille_delaunay.87'; > > package: 'ShoutWorkspace.1'; > > package: 'ShoutTests'; > > load. > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfOmniBrowser'; > > load. > > ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.1.5') load. > > > > Gofer new > > squeaksource: 'Moose'; > > package: 'ConfigurationOfMoose'; > > load. > > (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. > > ===== > > > > With Cyrille, we fix a part of error tests. Now, I'm not sure that it can work on Pharo1.1. > > So we do not save our work on moose repository. > > > > What do we do for next steps ? > > Do we change our Pharo system and go to 1.2 or working on 1.1 ? > > > > Cheers, > > --- > > Jannik Laval > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 -- Simon

4 4

moose 4.1
by Tudor Girba 23 Sep '10

23 Sep '10

Hello, We are happy to announce the Moose Suite version 4.1: http://moosetechnology.org/download What's new: • Significant speed improvements of Mondrian and Glamour • Improved Mondrian drawing of complex shapes • Improved Glamour engine to handle cyclic updates • New user interface look an feel • Improved set of Glamour widgets • Re-packaging to strengthen the naming convention • Re-organization of the code to break unwanted dependencies • Cleaning of FAMIX • New extensible design of the Moose Finder • New PetitParser-based parsers for MSE, Java, and MANIFEST.MF files • New browser for meta-models described in MSE files • Based on Pharo 1.1 A complete list of issues fixed in this release can be found at:http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fix… An incomplete set of future actions: • Better browsers for various analyses use cases • Improved FAMIX query API (MooseChic) • Improved Glamour widgets • EyeSee engine for drawing charts • AST for Java Have fun, The Moose Team

4 5

Re: Moose on pharo 1.2
by Stéphane Ducasse 23 Sep '10

23 Sep '10

On Sep 22, 2010, at 7:24 PM, Colin Putney wrote: > On Wed, Sep 22, 2010 at 2:51 AM, Stéphane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > >> MIT and I hope that colin will change it slightly and that we can integrate it in Pharo. > > Right, it's MIT-licensed, and I'm quite happy to have it integrated in > Pharo. I'm currently implementing some of the changes we discussed at > the conference, and I'll make sure the next release works on Pharo. excellent! I would love to have that in 1.2 so that we can start integrating it fully in 1.3 Jannik it would be a good nice little article for linux mag and book chapter There is the blog of lukas already and once colin will repackage and rename (FSPath :D) we can start writing a nice documentation :). Stef

2 1

Re: Glamour and Magritte validation
by François Tanguy 23 Sep '10

23 Sep '10

Hi, I have a class Exercice holding 3 instance variables where I store integers. Magritte descriptions are like follows: descriptionNumberOfRepetitions ^ MANumberDescription new accessor: #numberOfRepetitions; label: 'Number of repetitions'; priority: 100; yourself And the Glamour piece of code using Magritte description. (browser transmit) from: #activities; to: #details; andShow: [ :a | a magritte title: 'Details'; description: #description]. The values are correctly displayed but when changing them, the validation fails. See the screenshot. Regards, Francois

2 1

Re: Moose on pharo 1.2
by Stéphane Ducasse 22 Sep '10

22 Sep '10

Yes Now moose people can also consider the list of pending issues and help. There are some important fixes that nobody even packaged so that we can have a look at them. Stef On Sep 22, 2010, at 3:11 PM, Alexandre Bergel wrote: > We have to make sure that Pharo 1.2 is working well. Yesterday, I couldn't inspect a value from the debugger because of an error raised with some mapping with closure. This is annoying. > > Alexandre > > > > On 20 Sep 2010, at 10:43, Laval Jannik wrote: > >> I just tried to load Moose on pharo1.2 >> >> I only do this script (loading OB is not needed I think): >> >> ===== >> Gofer new >> squeaksource: 'rb'; >> package: 'AST-Core'; >> package: 'Refactoring-Core'; >> package: 'Refactoring-Critics'; >> package: 'Refactoring-Environment'; >> package: 'Refactoring-Spelling'; >> package: 'Refactoring-Changes'; >> load. >> >> Gofer new >> squeaksource: 'shout'; >> version: 'Shout-cyrille_delaunay.87'; >> package: 'ShoutWorkspace.1'; >> package: 'ShoutTests'; >> load. >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfOmniBrowser'; >> load. >> ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.1.5') load. >> >> Gofer new >> squeaksource: 'Moose'; >> package: 'ConfigurationOfMoose'; >> load. >> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. >> ===== >> >> With Cyrille, we fix a part of error tests. Now, I'm not sure that it can work on Pharo1.1. >> So we do not save our work on moose repository. >> >> What do we do for next steps ? >> Do we change our Pharo system and go to 1.2 or working on 1.1 ? >> >> Cheers, >> --- >> Jannik Laval >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

Moose on pharo 1.2
by Laval Jannik 22 Sep '10

22 Sep '10

I just tried to load Moose on pharo1.2 I only do this script (loading OB is not needed I think): ===== Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; package: 'Refactoring-Spelling'; package: 'Refactoring-Changes'; load. Gofer new squeaksource: 'shout'; version: 'Shout-cyrille_delaunay.87'; package: 'ShoutWorkspace.1'; package: 'ShoutTests'; load. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.1.5') load. Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. ===== With Cyrille, we fix a part of error tests. Now, I'm not sure that it can work on Pharo1.1. So we do not save our work on moose repository. What do we do for next steps ? Do we change our Pharo system and go to 1.2 or working on 1.1 ? Cheers, --- Jannik Laval

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev