On Dec 22, 2009, at 4:34 AM, Julian Fitzell wrote:

> On Mon, Dec 21, 2009 at 4:15 PM, Adrian Kuhn <[email protected]> wrote:
>> Julian Fitzell <jfitz...@...> writes:
>> 
>>> Well, the second may require working *with* SUnit maintainers on other
>>> platforms. :)
>> 
>> Where can I find their names?
> 
> Dunno... guess this is a start: http://sunit.sourceforge.net/people.htm

I would not go down this road :)

Just define a new one that is compatible.


> 
>>> I guess I don't know exactly what you define as
>>> "internal representation" but from Seaside's point of view it is
>>> absolutely essential that unit tests be runnable the same way on all
>>> platforms - it's the cornerstone of portability.
>> 
>> Good point. Added as a requirement: current test should remain runnable, and
>>  it should be possible to limit oneself to a set features that runs on all
>>  platforms.
>> 
>> One problem I see with legacy tests though is that TestCase serves currently
>>  two purposes: a the superclass of all classes that contain tests, and as the
>>  implementation of the internal logic that runs the tests. I don't how common
>>  it is to override internal methods of test case in subclass (as eg #runCase
>>  etc). In Seaside, eg, are you doing this?
> 
> It seems we do not, though we do override #performTest in two cases.
> Both are cases where we need to wrap the execution in an exception
> handler.
> 
>>> Although now I've said it, why not just start from scratch? There's
>>> not a lot of code there... implement something that works the way you
>>> want, build it using Grease/Slime so we can port it easily to
>>> everywhere else, and that's something Seaside could use (assuming it
>>> was compellingly better). And suddenly we'd have a test framework that
>>> *did* run everywhere with a common code base.
>> 
>> Compelling, but can this be done without being a cross-platform expert? I
>>  recall the pain of getting Fame to run in both VW and Squeak, eventually I
>>  gave up. Cross-platform integration server, anyone?
>> 
>> What is Grease/Slime?
> 
> I don't know - we've become pseudo-experts for Seaside but it doesn't
> seem to be that tough in our case - just a matter of avoiding lots of
> things that aren't compatible.
> 
> Grease is the light-weight compatibility layer we have ended up
> developing out of the Seaside project. I also used it to port Magritte
> and Pier to VA Smalltalk and Colin and I are now beginning to use it
> for MC2.
> 
> Slime is a set of lint rules - currently some of them are
> Seaside-specific but others are essentially a counterpart to Grease -
> detecting things that you cannot do if you want your code to be
> portable.
> 
> The hope is that others can leverage the experience we've developed
> and our porters' efforts getting Grease running on their platforms. I
> still need to finish a write-up on what Grease is and post it
> somewhere - on my todo list for the holidays.
> 
> Julian
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to