Please use the mailing-list
On Tue, Nov 11, 2008 at 11:04 PM, Keith Hodges <keith_hodges@yahoo.co.uk
wrote: SSpec doesnt follow that convention, but uses method category 'specs'. So in SUnit-improved it has a more flexible approach in order to accomodate SSpec and not to have to follow this convention, it allows you to define toDo* bug* , method categories, flagged methods, pragmas or whatever else you choose.
All good solutions⦠actually I agree that relying on the method name is somewhat of a hack.
well it depends. Roel told me that annotation in Java for tests at the end of the day are a hell. Imagine that we would like to remove from our analysis unit tests when you do not need a class, you do not have method patterns, and the annotations are not that well defined.
Neither am I. I would like "universes" to die off. The reason being the overly controlled closed nature of the master database, and the
What bothers me most is that it's centralized.
The problem is that as a user I want something that is working and not a shitty place like squeakmap where nearly nothing work
The ethos behind Sake/Packages is that it is the package USERS that determine what works in what context. Developers often don't test their packages in all contexts, but users may do.
Sure but I think that this is also wrong. I got so tired of squeakmap package quality that I stop to use it. And I imagine lot of people did the same
It is a space in which the collective knowledge of what works where is collated by the community. Both the Users "universes" and the developers SetUp packages can be used to get the best of both worlds.
Exactly. Developers can propose their part of the collective knowledge (precise, minimal, low-level dependancies between individual MC branches). Then the community can build higher-level packages or whole integrated distributions, either by using what the developers provide, or by doing the integration tests independantly and providing a different set of dependencies. For instance, I expect developers would not mention versions at all, except for planned incompatibilities. Distributions would freeze whole sets of versions together because they are known to work.
determine success. For instance, I think SourceTalk and Bob should be linked or even integrated someday, so that getting automatic builds for a new project is near-instant Just need to add MC2 support to, Installer.
For the fastest loading experience, try MC1.6!
I also have a plan for binary loading for both MC1 and 2.
I meant instant in cognitive time :D I want only one bookmark, one account, be able to link build numbers to bug reports and unit tests versions all in one place.
By the way, I'm trying stuff with Packages now, and I'm realizing I need a way to depend on rules from another class. Concretely, the Pier-Model task in PierSetup should depend on Magritte-Model in MagritteSetup. The situation is kind of similar to makefiles and recursive makefiles⦠it works but sub-makes don't have access to the state of the parent make process. Is there a way to merge or union several SakeTasks ?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet