william.full.moon at gmail.com
Wed Jul 25 06:45:27 EDT 2007
Good morning/ Good evening/ Good night.
From: Jonathan Buch [mailto:john at oxyliquit.de]
Sent: Wednesday, 25 July 2007 18:19
w> I have a comment on these recurrent "test" errors and "regression"
j> I really like your idea, but there is a _big_ hinderance for me
j> there. :) Time. Even the current startup is sub-optimal,
j> with tests there'd have to be a 'do test' switch which enables
j> testing for those who do want to run those.
Yes -- I appreciate this.
The suggestion is more of a "challenge" to find an solution that is:
-- Effective, and
On real operating systems (and probably Windows now) one might fork() a
self-test routine in parallel. That would not impact the mainline
I am I saying that's a solution? Not really. I want to illustrate that
Are ways to make it happen, by being ambitions.
j> Nitro/Og tests take around 15 minutes for me to run,
j> I'd be crazy to enable this.
Yes, that too. Why not consider some old-fashioned technology.
When teletypes were unreliable, we needed to check the data.
Here's an option.
j> IMO there isn't so much duplication going on in the
j> tests as simply 'usage' of facilities (at least in Og).
While that may or may not be the case -- Industry ready code finds
regression error all the time until someone takes action to stop it.
A simple idea is to "check" the code when it is patched.
I see an example from darcs in another post.
I was also wondering if a "check-sum" might be used to identify changed
So far a simple expression of the notion has defeated me. ;)
As I say a challenge for the masses ::: Set forth (oops Ruby) and multiply.
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 23-Jul-2007
More information about the Nitro-general