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
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
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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
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
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
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
