- Moose-dev - INF Mailman

Re: [Metacello] Transitive closure on groups

by Dale Henrichs

Simon, Another alternative would be to import the tests that you're interested in into ConfigurationOfMoose: spec project: 'MooseAlgos Tests' copyFrom: 'MooseAlgos for Moose' with: [ spec loads: 'Tests' ]. This is similar to what you are doing with option two, with the twist that you only need ConfigurationOfMoose loaded to be able to access tests... Dale ----- "Simon Denier" <simon.denier(a)inria.fr> wrote: | Hi there | | Now with a few weeks of running, I have settled about a new use case | | for the test server. | | This is issue 226 in the bug tracker of Moose. | | Basically we now have multiple ConfigurationOf... to manage our | projects, and 'Tests' groups within those projects to identify | packages for testing. | | Right now my test server only loads ConfigurationOfMoose, triggering | | the loading of all other Configuration. | | ...but... | | It only retrieves the Tests group of ConfigurationOfMoose, which means | | that tests defined in other configurations are not run. Now of course, | | I want to run those too. | | I can think of two solutions: | 1) either Metacello makes the transivite closure on groups, which | means it merges groups from different projects bearing the same name. | 2) either I explicitly declare in my test server all configurations | for which I want to run the tests. | TestProject withAll: {ConfigurationOfMondrian. ConfigurationOfGlamour. | | ConfigurationOfMoose} | | The first solution is more elegant, but keeping in line with my idea | | that test requirements should be explicit, I think I will go with the | | second. The idea is that you should state which projects you want to | | test, and you dont want to run tests for all projects/configurations | | you depend on. | | Now, what do you think? | | -- | Simon

15 years, 7 months

2
1
0 0

New version of some packages:

by Alexandre Bergel

Famix-Core-Alexandre_Bergel.99 - recategorization of class methods -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Famix-File-Alexandre_Bergel.19 FAMIXFile depends on Filesystem now. This version contains a number of small refactoring and convenient methods -=-=-=-=-=-=-=-=-=-=-=-= Moose-Core-Alexandre_Bergel.176 Remove from hardcoded class reference -=-=-=-=-=-=-=-=-=-=-=-= Moose-GenericImporter-Alexandre_Bergel.31 The importer depends on Filesystem -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 7 months

1
0
0 0

problem porting package blueprint to pharo

by Stéphane Ducasse

Hi we started to port package blueprint to pharo and apparently there is no ScatterPlotLayout in Mondrian in Pharo Is there a reason? What is the interface conformance between VW and pharo Mondrian? Stef

15 years, 7 months

3
6
0 0

Two bugs

by Simon Denier

Hi there - First, when I use the import wizard, by default the 'merge classes and metaclasses' box is ticked but the importer does not perform merge. You have to click once again on the checkbox (in which case it remains 'ticked', which is another indication that the default state of the checkbox is wrong) - in the latest release, the Moose Finder is broken. When I click on a group in the pane, nothing happens. -- Simon

15 years, 7 months

3
6
0 0

Re: [Pharo-project] PackageInfo>>classes does not distinguish traits from classes (issue?)

by Simon Denier

On 24 nov. 2009, at 18:17, Stéphane Ducasse wrote: > What is strange adrian is that before we did not encounter this > problem in moose. > May be something changes and we did not notice it. Keeping in line with the saying "to clean up your own back yard", I think it's more related to a change in the Moose importer, especially dealing with the package cache. I changed some parts of the package importer in September (but it does not look to change this aspect to me). Now my memory is a bit fuzzy, so I cant track down at which point the last Pharo import worked (this summer?) Sorry, it's a bit off topic for the Pharo ML :) > > Stef > On Nov 23, 2009, at 10:31 PM, Adrian Lienhard wrote: > >> Hi Simon, >> >> There is no such method. But it would be easy to add (just send >> "aPackage classes select: #isTrait"). The reason for returning traits >> with the classes is that clients of PackageInfo typically expect >> "compilation units", i.e., a collection including traits. The naming, >> of course, is not optimal, and should be fixed in the long run. The >> problem is to do so without breaking the clients of PackagInfo. >> >> Cheers, >> Adrian >> >> On Nov 23, 2009, at 16:28 , Simon Denier wrote: >> >>> Hi there >>> >>> When I run PackageInfo>>classes, I get both classes and traits >>> defined >>> in the package. So I can understand the need for a method retrieving >>> all 'compilation units' (or behaviors) from a package, but is >>> there no >>> method to just retrieve the regular classes? Especially since >>> there is >>> a #externalTraits method. >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

15 years, 7 months

1
0
0 0

Updates of Configurations*

by Simon Denier

Hi there Today I made multiple updates to the dependencies between various projects of Moose. The primary purpose was to make Mondrian stand alone and not dependent on some other projects of Moose (namely MooseAlgos). I also took this opportunity to start working on issue 149 with the MooseAlgos project So now there is a ConfigurationOfMooseAlgos and all Moose-Algos subprojects (like Graph, LinearAlgebra...) get their own package in this project. Project like DSM and Moose now depend on ConfigurationOfMooseAlgos There is a new package Moose-MondrianPaintings for bigger applications of Mondrian (like DependencyTable) I suggest that you start from a fresh image with the latest ConfigurationOfMoose, so that you dont get messed up between the old/ new packages -- Simon

15 years, 7 months

3
2
0 0

CAnalyzer does not load?

by Stéphane Ducasse

Alex I cannot load CAnalyzer. self loadVersion: '1.2' -> error Did you test it after publishing? Stef

15 years, 7 months

2
2
0 0

4.0 beta 2

by Tudor Girba

Hi, A configuration with hardcoded versions for Moose 4.0 beta 2 is now available. You can get it by: Gofer new squeaksource: 'Moose'; addPackage: 'ConfigurationOfMoose'; load. ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta.2') load. For this, the other projects also have releases: Glamour, Mondrian, DSM, MooseAlgos and SmallDude. The versioning started from 2.0-beta.1 for these projects given that they are at their second incarnation (the first one being in VW). The one click package is available for download: http://moose.unibe.ch/download Let me know if you have comments. Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

15 years, 7 months

3
2
0 0

Fwd: SourceAnchor / browse Source

by Simon Denier

OK I'm tired. I send it to the wrong mailing list. Begin forwarded message: > From: Simon Denier <simon.denier(a)inria.fr> > Date: 23 novembre 2009 18:17:50 UTC-03:00 > To: notre liste <lsehub-staff(a)lists.gforge.inria.fr> > Cc: Simon Denier <simon.denier(a)inria.fr> > Subject: SourceAnchor / browse Source > > Hi there > > Does somebody manager to browse the source code of, let's say, a > Java project imported by infusion (for example). It does not work in > my image. I'm trying to figure out why. > > -- > Simon > > > -- Simon

15 years, 7 months

3
3
0 0

Dealing with traits in the Smalltalk importer

by Simon Denier

Hi there I started to work on issue 227 and it is quite simple but problematic. Basically when we send PackageInfo>>classes, it returns regular classes and traits. There is no way to ask directly for the regular classes. Now since traits are flattened in their user classes, there is no behavior lost if I ignore them in the importer (esp. since for now there is no representation of traits in Famix). With this in mind, I updated the Lan model to use a trait, with the goal to not change the properties of the model and the tests. But the tests break because the Lan package has one more 'class' which is the trait. Do I continue and update the tests to ignore the trait? -- Simon

15 years, 7 months

5
4
0 0

[Metacello] Transitive closure on groups

by Simon Denier

Hi there Now with a few weeks of running, I have settled about a new use case for the test server. This is issue 226 in the bug tracker of Moose. Basically we now have multiple ConfigurationOf... to manage our projects, and 'Tests' groups within those projects to identify packages for testing. Right now my test server only loads ConfigurationOfMoose, triggering the loading of all other Configuration. ...but... It only retrieves the Tests group of ConfigurationOfMoose, which means that tests defined in other configurations are not run. Now of course, I want to run those too. I can think of two solutions: 1) either Metacello makes the transivite closure on groups, which means it merges groups from different projects bearing the same name. 2) either I explicitly declare in my test server all configurations for which I want to run the tests. TestProject withAll: {ConfigurationOfMondrian. ConfigurationOfGlamour. ConfigurationOfMoose} The first solution is more elegant, but keeping in line with my idea that test requirements should be explicit, I think I will go with the second. The idea is that you should state which projects you want to test, and you dont want to run tests for all projects/configurations you depend on. Now, what do you think? -- Simon

15 years, 7 months

2
1
0 0

Fwd: The case of MondrianPaintings

by Simon Denier

Begin forwarded message: > From: Simon Denier <Simon.Denier(a)inria.fr> > Date: 20 novembre 2009 16:45:05 UTC-03:00 > To: Simon Denier <Simon.Denier(a)inria.fr> > Subject: Re: [Moose-dev] The case of MondrianPaintings > > > On 18 nov. 2009, at 12:39, Simon Denier wrote: > >> >> On 17 nov. 2009, at 12:15, Alexandre Bergel wrote: >> >>> Dear List, >>> >>> MondrianPaintings is a package belonging to the Mondrian >>> repository that contains few classes apparently to compute cycles, >>> render a distribution map, and render some views related to Flair. >> >> Problem is we never really discussed what this MondrianPaintings is >> about. I understand it as a bunch of applications based on >> Mondrian, more complex than basic stuff, and independent of Moose. >> But it still a bit in the gray. >> >>> >>> There is a number of problems with this package: >>> - It contains too few tests. Among the 9 test run, 4 raise an >>> error. Apparently CollectionExtensions is required, which belongs >>> to Moose. Mondrian cannot depends on Moose. Maybe >>> CollectionExtensions may be moved into a standalone package for >>> which both Mondrian and Moose can depend on. >> >>> - MOSmalltalkPaintings>>viewWAPackageHierarchy depends on >>> WAPackage which is not present in Mondrian and in a Dev image >> >> yes this is viz for seaside packages >> >>> >>> What should we do with this package? We could move it to Moose, >>> but identifying cycles is an interesting feature that go beyond >>> Moose. As far as a I can see, making CollectionExtensions an >>> independent package looks the best compromise. >> >> Actually this package does not contain any cycle identification >> algo (there are in MooseAlgos and DSM for now), it's just stand- >> alone visualizations in which you can put data. > > Fixed. I actually move the cycle tables and layer tables classes to > MooseAlgos. Please test. > >> >> I agree that CollectionExtensions should have its own project. >> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 >> >> -- >> Simon >> >> >> > > -- > Simon > > > -- Simon

15 years, 7 months

1
0
0 0

moose algos depends on mondrian

by Tudor Girba

Hi Simon, Why does MooseAlgos depend on Mondrian? Cheers, Doru -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

15 years, 7 months

2
1
0 0

broken ConfigurationOfMoose

by Tudor Girba

Hi Simon, The latest repackaging of MooseAlgos broke the dependencies in the configurations. I managed to solve most of them, but I am just missing the code for MOCycleTable which used to be in MondrianPaintings- DependencyTable, but it got removed. This is needed to load DSM. Indeed, it is great to clean the packaging, but I think the DependencyTable code got lost a bit. Or at least I could not find it :). So, for the moment, I removed the DSM as a dependency from the ConfigurationOfMoose, but as soon as we find the missing dependency, we add it back. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

15 years, 7 months

3
3
0 0

Smalltalk Importer and Traits

by Alexandre Bergel

Hi! Apparently traits are not properly handled by the moose smalltalk importer. I tried to import a project that contains traits and a message #superclass is sent to a trait, which raise an error. I use the Stepwise importer for this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 7 months

2
1
0 0

The case of MondrianPaintings

by Alexandre Bergel

Dear List, MondrianPaintings is a package belonging to the Mondrian repository that contains few classes apparently to compute cycles, render a distribution map, and render some views related to Flair. There is a number of problems with this package: - It contains too few tests. Among the 9 test run, 4 raise an error. Apparently CollectionExtensions is required, which belongs to Moose. Mondrian cannot depends on Moose. Maybe CollectionExtensions may be moved into a standalone package for which both Mondrian and Moose can depend on. - MOSmalltalkPaintings>>viewWAPackageHierarchy depends on WAPackage which is not present in Mondrian and in a Dev image What should we do with this package? We could move it to Moose, but identifying cycles is an interesting feature that go beyond Moose. As far as a I can see, making CollectionExtensions an independent package looks the best compromise. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 7 months

2
1
0 0

CodeCity 1.4 is out

by Richard Wettel

Dear all, I wanted to let you know that the version 1.4 of CodeCity (3D visualization of large evolving software systems, based on a city metaphor) is finally out: http://codecity.inf.usi.ch The new version is faster and more usable than the previous one also brings a number of interesting new features, one of which by popular request (namely exporting high-resolution screenshots of your code cities). As usual, I highly appreciate all your feedback. Kind regards, Richard Wettel

15 years, 7 months

2
1
0 0

bug Glamour

by Cyrille Delaunay

Hi, When I try to open a moose finder I get an error because in: GLMMorphicRenderer >> treeMorphFor:and: the class 'LazyMorphTreeMorph' is used but doesn't exist.

15 years, 7 months

3
4
0 0

glamour developments

by Tudor Girba

Hi, A couple of things happened in Glamour during the past few days: - The GLMTableLayoutBrowser was renamed to GLMTabulator. I refactored the code I knew of and we have a deprecated clause in the GLMTableLayoutBrowser>>new. - The tree is now rendered lazily thanks to the work of Alain - The tree supports search and multiple selection, - We have a table widget. At the moment you have to statically define the columns, but it's a start. - Presentations can now have a say to validate a value that we try to set in a port (this was started by Philipp and Jorge). This is an important step to properly support the update. More will come on this front. - You can now deselect in a list or a tree and this sets the selection to nil. This is a rather small detail, but it is quite important for usability. - We now have a couple of tests for the Morphic interface. It still does not work properly, but I think this is an important track. Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

15 years, 7 months

2
1
0 0

glamour screenshot

by Tudor Girba

Hi, If you want to take a screenshot with your browser, here is a nice way of doing it: | browser window | browser := YOURBROWSER. browser act: [window exportAsPNG] entitled: 'Screenshot'. window := browser openOn: ... This will place a "Screenshot" menu item in the window and if you click on it it will export the current window morph as PNG. Doru -- www.tudorgirba.com "Beauty is where we see it."

15 years, 7 months

1
0
0 0

glamour and moose finder update

by Tudor Girba

Hi, You might notice that in the rendering of MooseFinder is slightly different. In particular, you will only get a limited amount of items displayed in the group view. This is due to a change in Glamour: we now use only the MorphTreeMorph widget to render both lists and trees. If you encounter issues, please report them. Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

15 years, 7 months

3
7
0 0

Problem with metacello update

by Simon Denier

I am not really sure what the problem is but, when I perform a ConfigurationOfMoose updateDefault, not all packages get updated. Especially Momo does not seem to be updated (it's not the first time I noticed that). Another problem is that ConfigurationOfMoose updateDefault update itself but not the other configurations (like Glamour), so we need to think about that to get the process right. -- Simon

15 years, 7 months

2
1
0 0

inFusion out of memory

by Laval Jannik

Hi Doru, I tried to use inFusion to import Eclipse source. After 24 hours processing, it return an error: "Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space". Argh, the project is too big. But is it possible that the tool display this message before process ? Is it possible also to add a progress bar ? Because for now, it is not possible to know what infusion is doing during the process. Cheers --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

15 years, 7 months

4
7
0 0

Re: FAME new changes broke moose

by Tudor Girba

Thanks. Of course, an MIT would have been probably more straightforward especially for the integration in Pharo, but I guess it should do for now. Cheers, Doru On 11 Nov 2009, at 10:57, Adrian Kuhn wrote: > Fixed, picked the WTFPL license. > > --AA > > On Nov 10, 2009, at 23:10 , Tudor Girba wrote: > >> Hi Adrian, >> >> It looks like the latest versions of Fame depend on PhExample. >> Unfortunately, PhExample is not released under a MIT/BSD-compatible >> license. >> >> Is there a mistake somewhere, or should Moose go with a fork of Fame? >> >> Cheers, >> Doru >> >> >> On 10 Nov 2009, at 22:43, stephane ducasse wrote: >> >>> Hi >>> >>> Apparently changes in Fame broke moose. >>> >>> processCompiledMethod: aMethod >>> | pragma prop | >>>>>> aMethod should be isCompiledMethod. >>> pragma := Pragma >>> inMethod: aMethod >>> >>> So what do we do? >>> >>> Stef >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

15 years, 7 months

4
8
0 0

Re: mondrian problem

by Alexandre Bergel

Hi Doru, I fixed the problem. This cause of this bug is that the bitmap cache was created while the node was not fully displayed on the screen! Cheers, Alexandre On 11 Nov 2009, at 05:45, Tudor Girba wrote: > Hi Alex, > > Do you think you could have a bit of time to take a look at this > problem: > http://code.google.com/p/moose-technology/issues/detail?id=205 > > ? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 7 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