> I carried out those mods and built; it worked as required
> with no doc tools available.
Cool!
> | Also, you committed directly to ghc-6-2-branch, which is
> something we
> | don't normally do. "Standard Practice" is to commit to the HEAD and
> | then merge to the branch (or put a note in the log message
> and I'll do
> | the merge).
>
> Again I've committed the change you suggested against your
> stated preference
> as I had no way of testing and possibly further modifying the
> HEAD etc etc
> before you close 6.2.1 on Monday - it also means the change
> gets tested on
> the normal build systems over the weekend. Hope you'll forgive the
> indiscretion on that basis - I'll try and be a better citizen
> in future!
Not a problem - sometimes it is indeed easier to commit to the branch
first, especially if you don't have a handy HEAD build to test on first.
The rule isn't set in stone, it just makes things a bit easier when it
comes to merging: merging only has to be done in one direction, and
there's only a single line of development to follow in the logs.
> TEST STUFF ON WINDOWS
>
> As you're about to close for 6.2.1 I thought I'd run the
> regression tests in
> my stable test build today as well - the log should make it onto this
> mailing list.
>
> The network stuff has troubles - net002 in particular just hangs
> indefinitely (overnight in fact, until I kill explicitly)
I doubt that this is a new bug in 6.2.1. If you've got time to
investigate that would be great, but I won't hold up 6.2.1 for it.
> and further along
> the line there are a number of ghc compiler crashes which are
> unfortunately
> not reflected as such in the test log posted - I keep having
> to tell XP not
> to notify Microsoft when the crash requestor comes up.
This is worrying. I guess I'll need to get a Win32 build here and try
to reproduce. Is it the compiler crashing, or the test? I noticed you
managed to do a full 3-stage bootstrap, so things can't be completely
broken.
> The overall test system doesn't really work on Windows (as
> I'm sure you're
> aware) due to improper handling of CR/LF line endings and improperly
> interpreted exit values.
Actually I'm not sure that anyone has run the test suite in its current
incarnation on Win32. There will undoubtedly be a number of things to
fix up. If I get time I'll try to look into it.
> In other words, most of the failures are not really failures at all.
>
> Unfortunately I'm not best descibed as "Mr Perl" and the
> preliminary mods
> I've made in my local HEAD source tree (ie not yet checked
> in) have only
> slightly dented the false negatives on Windows.
>
> I do think this an area which urgently needs attention from
> some expert
> Windows Perl hacker though, as clearly there are undetected
> problems on
> Windows (at least on my particular computer).
BTW the test suite driver is in Python, not Perl ;-P
> Similar comments apply to fixing the the nofib tests which are equally
> important in my opinion (although if memory serves there are
> no crashes there).
nofib *should* be ok - are you getting failures there?
Cheers,
Simon
_______________________________________________
Cvs-fptools mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-fptools
