- Moose-dev - INF Mailman

by Mircea Lungu

Hi Moosers! It our pleasure to announce (with a one week delay) that the 4th edition of FAMOOSr is over, and that it was a success. We had a dozen participants attending. Several had no a priori knowledge about the moose platform but were eager to learn. The talks stirred discussions and the bazaar session became a demos and discussions session (this is not that surprising: the time we had was too short for coding). The two blitz demos of Doru (on Glamour) and Andrei (on the Glamour/Seaside integration) were very liked. Until the next time, Happy research to each one of you :) Simon and Mircea.

14 years, 9 months

2
1
0 0

GT Tools

by Alexandre Bergel

Hi Doru, I tried your GTTools. I like GTCodeBrowser. What is missing is the update mechanism. Is it supported by Glamour? Is this easy to implement? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 9 months

2
2
0 0

Namespaces and childScopes for java code ???

by Nicolas Anquetil

I am writing a Java to MSE exporter called VerveineJ. (I was supposed to announce it at some point but I keep waiting for a reasonably stable version) But let's go to the point. For Java packages I am creating FAMIX Namespaces Now I discovered the notion of childScopes and two questions arose: - should VerveineJ create a "childScope link" between two java Packages (i.e. FAMIX Namespace) that are included one in the other (e.g.: "org.eclipse.help" and "org.eclipse.help.internal" and "org.eclipse.help.internal.browser") - if the answer is yes to the 1st question, then should VerveineJ create new FAMIX Namespaces at the "intersection" of two other namespaces. For example, for "org.eclipse.core.internal.plugins" and "org.eclipse.core.runtime", one could create "org.eclipse.core" as a parent scope of both... Eclipse, which is my reference here, does not consider hierarchy of packages. Even if, on the disk, one package is implemented as a subdirectory of another one, in the Package Explorer, they are listed as two separate ones. Any opinion? nicolas -- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod

14 years, 9 months

3
2
0 0

another moose

by Mariano Martinez Peck

http://search.cpan.org/~drolsky/Moose-1.14/lib/Moose.pm

14 years, 9 months

4
4
0 0

[Glamour] transmit from several origins using 'transformed:'

by Cyrille Delaunay

Hello, I wonder if it is possible to have a browser that tansmit from several origins, that means having a source code like that: browser transmit from: #row1; from: #row2; to row: #row3; andShow: ...... and in the same time to transform one of the output. So having something like: browser transmit from: #row1; from: #row2; transformed: [ ... ]; to row: #row3; andShow: ...... If it is possible, what should be put in the transform block? because we have several outputs, so how do we deal with them and what should be returned in the block ?

14 years, 9 months

2
2
0 0

Re: Urget question about CodeCity

by Simon Denier

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

14 years, 9 months

1
0
0 0

Urget question about CodeCity

by Mariano Martinez Peck

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

14 years, 9 months

3
5
0 0

News on Mondrian

by Alexandre Bergel

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

14 years, 9 months

2
1
0 0

Re: Moose on pharo 1.2

by Stéphane Ducasse

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

14 years, 9 months

2
1
0 0

Re: Moose on pharo 1.2

by Simon Denier

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

14 years, 9 months

4
4
0 0

moose 4.1

by Tudor Girba

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

14 years, 9 months

4
5
0 0

Re: Moose on pharo 1.2

by Stéphane Ducasse

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

14 years, 9 months

2
1
0 0

Re: Glamour and Magritte validation

by François Tanguy

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

14 years, 9 months

2
1
0 0

Re: Moose on pharo 1.2

by Stéphane Ducasse

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

14 years, 9 months

1
0
0 0

Moose on pharo 1.2

by Laval Jannik

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

14 years, 9 months

5
7
0 0

Re: Moose on pharo 1.2

by Stéphane Ducasse

On Sep 21, 2010, at 9:43 PM, Laval Jannik wrote: > > On Sep 20, 2010, at 18:52 , Simon Denier wrote: > >> >> On 20 sept. 2010, at 17:14, Laval Jannik wrote: >> >>> Hi guys, >>> >>> It is not so easy to load Moose on Pharo1.2 :) >>> There are two deprecated call during the loading. This is due to FileSystem, we cannot change the source code on the repository. >> >> What's the licence? Can we copy the package in Moose repo until fixes are integrated? MIT and I hope that colin will change it slightly and that we can integrate it in Pharo. > > I don't know, it is on wiresong. > >> >>> ==== >>> >>> For now our fixes are on files attached to the mail. >>> Cheers, >>> Jannik >>> >>> <Mondrian-jl.581.mcz><Moose-MonticelloImporter-jl.12.mcz><ShoutWorkspace.1-jl.7.mcz><Glamour-Morphic-Renderer-jl.6.mcz> >> >> >> Do the fixes break in Pharo 1.1? Could we integrate them and still run in 1.1? > > Only Mondrian seems to be broken with my changes. > So tomorrow, I will commit the rest. > > Cheers, > Jannik > >> >> >>> >>> On Sep 20, 2010, at 16:43 , Laval Jannik wrote: >>> >>>> ===== >>>> >>>> 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 ? >> >> >> Check the status of 1.2 dev. If there is a good enough stable version, we can move. Until that, I would prefer to stay with 1.1 right now, just to enjoy a nice stable fast environment for a while, and also so that we can still integrate fixes in 1.1, benefiting to the users who can't/won't move to 1.2 right now. >> >> Actually the best plan is to check whether we could maintain the compability for a while. >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 9 months

1
0
0 0

MAVector

by Alexandre Bergel

Hi! I analyzed a bit the presence and usage of abstract methods in Moose. MAVector>>initializeSize: is abstract. MOClusteringVector is a subclass of MAVector. MOClusteringVector does not override initializeSize: and is not subclassed. MOClusteringVector is therefore abstract without subclasses. Something has to be fixed somehow. I found a similar situation in Mondrian, and I fixed it. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 9 months

1
0
0 0

cog or no cog?

by Tudor Girba

Hi, Just out of curiosity, is anyone still working with a non-cog vm? I am asking because I was thinking of releasing 4.1 one click with a Cog VM. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

14 years, 9 months

5
4
0 0

Glamour and Magritte validation

by François Tanguy

Hi, I have built a Glamour browser that uses magritte descriptions. The underlying data model is very simple. There are only integers to be displayed. When I click the save button, I get some validation errors stating that the input entered in the text field is invalid. If I deal with strings that is ok. So I think that the input is not converted into integer and therefore magritte does not like it because an integer is expected but a string is provided. Anybody already tried this use case ? Francois

14 years, 9 months

2
1
0 0

About a real solution for analysing Pharo in Moose

by Stéphane Ducasse

Hi guys I think that we should leverage the pharo infrastructure to be able analyze pharo unstable. We should make sure that we can - load code in a separate system dictionary - perform analysis of code in that separate namespace this way we can use Moose 4.1 in pharo 1.1 to load pharo 1.2 unstable. It will be shaky the first time but it should work. wat do you think? Stef

14 years, 9 months

4
4
0 0

Using MouseEnter events from a Mondrian presentation in Glamour

by Simon Denier

I'm wondering how to use MouseEnter events from Mondrian (when I just move the mouse over an element) in a Glamour presentation. I am not sure how to use it actually. There is an example in MoosePanel when the mouse overs a class in system complexity, class name is displayed in the status bar. It seems like I could perhaps read from the #status port? My idea is that I would like to be able to update a presentation in another pane when I just hover over an element. For example, I could use it to display the source code in a separate pane when discovering a mondrian presentation. I don't like to have too much popup with source code (it hides the visualization), and the benefit to have it in a separate pane is that you always now where to look. (rambling from esug) -- Simon

14 years, 9 months

4
5
0 0

+ and - buttons in the easel

by Alexandre Bergel

Hi! The color of the background of the + and - buttons is different than the color of the window when the window is not selected. http://code.google.com/p/moose-technology/issues/detail?id=457 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 9 months

3
4
0 0

MooseCustomTask and Glamour rendering

by Simon Denier

Hi It seems I have some problems to mix progress bars (using MooseCustomTask) and Glamour browser (it's related to Arki more precisely). I mean, I select some items in a browser, which then compute lazily their state. Some long computations are done in a Moose custom task to give feedback. But it gives errors or incorrect results in Glamour/Arki when it is done this way, generally because some data are incomplete when the browser is rendering the widget. I'm puzzled by how this happens, because it seems it should be managed by the UI thread. Any hacker willing to take a look at Esug? -- Simon

14 years, 9 months

2
2
0 0

Glamour: removed windowFor:

by Veronica Isabel Uquillas Gomez

Hi Doru, Can't find this method that Torch is using? Is there any reason for the removal? Veronica

14 years, 9 months

1
1
0 0

Moose release 4.1

by Laval Jannik

I am preparing release 4.1. I have a small failure due to XMLParserTest>>testDecodingCharacters --- Jannik Laval

14 years, 9 months

5
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev