Moose-dev November 2009

moose-dev@list.inf.unibe.ch

16 participants
46 discussions

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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."

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2009