Please use the mailing-list
On Tue, Nov 11, 2008 at 11:04 PM, Keith Hodges <[EMAIL PROTECTED]
> 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
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
