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
13 years, 10 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
13 years, 10 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
13 years, 10 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
13 years, 10 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
13 years, 10 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
13 years, 10 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
13 years, 10 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."
13 years, 10 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
13 years, 10 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
13 years, 10 months
