Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Start a nNew thread

glamour drop down is available
by Stéphane Ducasse 26 May '10

26 May '10

hi guys please push veronica to release the cool glamour drop-down she did for glamour :) Stef

3 2

moosejee should use the new opax
by Tudor Girba 23 May '10

23 May '10

Hi Fabrizio, Opax is now integrated in the XMLSupport repository. So, I removed the explicit Opax dependency from the ConfigurationOfMooseJEE because you will get it anyway with XMLSupport. Please let me know if you get problems. Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

1 0

preparing the 4.0 release
by Tudor Girba 21 May '10

21 May '10

Hi, It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0. I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check). Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

5 20

reporting with arki
by Tudor Girba 21 May '10

21 May '10

Hi, I made available a small model and interface based on Glamour for building reports. A report has an index on the left hand side and a browser to the right. The index is a tree of concerns, where each concern has a way to compute the result, an associated browser and a status value (to red, green or neutral). You can see a description and an example here: http://www.themoosebook.org/book/internals/arki http://www.themoosebook.org/book/internals/arki/simple-report I added it to the ConfigurationOfMoose. Cheers, Doru -- www.tudorgirba.com "Value is always contextual."

1 0

Problem and solution for DistributionMaps in Pharo 1.1 [WAS] Fwd: problem with CompiledMethod equality
by Mariano Martinez Peck 20 May '10

20 May '10

Hi guys. In that thread in the mailing lists, you can see the problem I had in Pharo 1.1 as keys of a Dictionary answers a Set. I used CompiledMethod as properties, and the equality of CompiledMethod answers true for methods even with different selectors. So I my case I have problems because elementsAndPropertyValue keys answer me less thing that I put. The solution, was to change elementsAndPropertyValue to a IdentityDictionary instead of Dictionary. So, I have to subclass DistributionMap, and override initializeInstanceVariables so that: initializeInstanceVariables partsAndElements := Dictionary new. elementsAndPropertyValue := IdentityDictionary new. colorMap := Dictionary new. colors := Color strongColors Do you think this is good ? do you have a better solution ? Thanks! Mariano ---------- Forwarded message ---------- From: Mariano Martinez Peck <marianopeck(a)gmail.com> Date: Tue, May 18, 2010 at 3:35 PM Subject: problem with CompiledMethod equality To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not. For example, evaluate: (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true If you look at CompiledMethod = aCompiledMethod "Answer whether the receiver implements the same code as aCompiledMethod." | numLits | self == aCompiledMethod ifTrue: [ ^ true ]. self class = aCompiledMethod class ifFalse: [ ^ false ]. self size = aCompiledMethod size ifFalse: [ ^ false ]. self header = aCompiledMethod header ifFalse: [ ^ false ]. self initialPC to: self endPC do: [ :i | (self at: i) = (aCompiledMethod at: i) ifFalse: [ ^ false ] ]. (self sameLiteralsAs: aCompiledMethod) ifFalse: [ ^ false ]. self halt. ^ true It is returning in the last ^ true. What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals: self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)} aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)} So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true. So...any hints? is this the expected behavior ? or it is a bug ? Thanks Mariano

2 2

Welcome to Rafael Coman
by mircea.lungu＠usi.ch 19 May '10

19 May '10

Hi guys, I would like to welcome Rafael Coman, who is a bachelor student from University Aurel Vlaicu in Arad working on his bechelor thesis. He will be working in the next month towards adding support for dead code detection in Moose and Softwarenaut. Cheers, Mircea.

4 5

Glamour dependency
by Veronica Isabel Uquillas Gomez 19 May '10

19 May '10

Hi Tudor, I was loading Glamour in a new core image (1.1) and I got this message: ---------------- This package depends on the following classes: PluggableShoutMorph You must resolve these dependencies before you will be able to load these definitions: GLMPluggableShoutMorph GLMPluggableShoutMorph>>announcer GLMPluggableShoutMorph>>selectFrom:to: ----------------- The shout package is missing in the configuration of glamour. regards, Veronica

5 8

Re: [Pharo-project] TORCH: supporting source-code change integration
by Tudor Girba 19 May '10

19 May '10

Hi Veronica, A bit of feedback: - After loading Torch, the package contextual menu seems to crash the Monticello Browser - You extend isSuper in RBProgramNode and RBVariableNode, which generates an override conflict with methods in Moose-Core. - The Glamour tags look different, so I guess you also have some Glamour overrides. That should not happen :). Maybe you have some suggestions for improvement, or maybe you just need the border for the [i] icon? Cheers, Doru On 18 May 2010, at 15:16, Veronica Isabel Uquillas Gomez wrote: > Hi Tudor, > > thank you :D > > sure!!! > > cheers, > Veronica > > > On 18 May 2010, at 11:39, Tudor Girba wrote: > >> Hi Veronica, >> >> It is pretty impressive :). >> >> Would it be Ok if I added this on the Moose page? >> >> Cheers, >> Doru >> >> >> On 18 May 2010, at 11:21, Stéphane Ducasse wrote: >> >>> Thanks veronica. >>> lukas said that he was impressed this is a complement :) >>> >>> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: >>> >>>> Dear all, >>>> >>>> I would like to announce Torch, a tool for supporting source-code >>>> change integration. For now, it offers visualizations of the >>>> changes and enhanced change lists. >>>> Torch can be accessed through Monticello (in the main MC browser, >>>> in the repository browser or in the history browser). Selecting a >>>> version or slice, you can view the changes with Torch using the >>>> contextual menu. >>>> Once you open the Torch dashboard, you can access the enhanced >>>> change list or a detailed visualization via the contextual menu >>>> as well. >>>> >>>> Torch is available on SqueakSource, the repository is named >>>> Torch, and you need to load the ConfigurationOfTorch package. >>>> It runs in a dev or core image. >>>> >>>> For a dev image. >>>> - ConfigurationOfTorch loadVersion10 >>>> >>>> For a core image. >>>> 1) Set fonts - described in the attached file. >>>> 2) ConfigurationOfTorch loadDefault >>>> >>>> I would appreciate comments and feedback! >>>> >>>> Best Regards, >>>> Verónica Uquillas Gómez >>>> Vrije University Brussel - SOFT Lab >>>> University of Lille - RMOD Team >>>> >>>> <torchFontsScript.st> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

3 2

MoosePanel - ImportFromSmalltalkImage Icon
by Cyrille Delaunay 18 May '10

18 May '10

Hello, Stephane would really like to change the 'Mickey mouse' icon used to import from smalltalk image. I'm looking for new icons here: http://www.famfamfam.com/lab/icons. I don't know what could be used as icon, in a sensefull way ? I was thinking about a kind of 'add-package' icon, to build a model by selecting packages from the image. What do you think ?

4 4

lost smalltalk importer version
by Tudor Girba 18 May '10

18 May '10

Hi Jannik and Simon, Moose-SmalltalkImporter-jannik_laval.89 is not merged in the main branch. If I try to merge, it produces a conflict with the changes from Moose-SmalltalkImporter-simondenier.89. Could you please take a look? Also, it looks like no test was provided :). Could you please add one, because this is a critical part. Cheers, Doru -- www.tudorgirba.com "Live like you mean it."

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev