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