Re: GerH source distro at hebbut.net: HOW TO compile/compare/merge for Bill et al

   system under 'make check' and/or 'make megatest', so the tests can, as
   one desires, be run separately too.
   Meanwhile, using that approach, there's no maintainance hazard with
   'lots of little files': I have a set of .input files replacing those
   EOF<<< shell redirects because I need hem for Win32 *anyhow*, but
   those files don't require maintainance at all as these are FIXED input
   references. You haven't changed any of those lines in megatest
   anywhere in the last couple of years, so I can safely say they're
   stable as granite rock and I expect them to remain so.

They are stable for the older classifiers; they are most certainly
NOT stable for the newer ones.  Ex: the NN files got changed
about two weeks ago.

   New tests may use the same input files, though I'd prefer each test to
   have their own input file, just so one can 'mess' with them when
   testing for something specific.

   Documentation should not be used as test input reference material as
   documentation will change over time - hopefully :-) - , while test
   results should be as stable as humanly possible. Hence also my move to
   feed the classifiers a '.input' copy of the current files: I've found
   that off-by-one and other 'minor differences' in output don't improve
   confidence in the results out here, not to put too fine a point on it.
   And some of those 'tolerable differences' have unearthed code bugs
   that disturbed me.

OK, that's a good point.

   >  I am also unconvinced that there is very much savings in the idea of
   >  leaving out some classifiers.  The binaries just aren't that big
   >  (about 32Kbytes each) and unless you're building a VERY small embedded
   >  system, you're just buying yourself a world of untestable hurt by
   >  taking things out.

   I've found that some folks don't like to have 'experimental' stuff
   lurking in their production software. I can argue for it on technical
   grounds for years on end; the bottom line is that it's an emotional
   choice. It's got 'experimental' in it? They don't like it. They get
   the GUARANTEE there's only 'stable, proven technology' in there?
   They'll breathe again and be happy. They'll love 'ya.

   The CRM_WITHOUT_<CLASSIFIER> #defines give everyone that choice to
   feel good about it. Personally, I'd rather run it with everything on
   there and I don't mind a dead weight classifier, but it's not the way
   it works out there in the lands that I have visited.

That's a good point too.  

It just feels to me like it's building a version of GCC without
the "divide" function; you've now got a language that does not
meet the minimum specifications in the manual.

   I hope I'm not bothering you with all this.

Not at all.  Understanding is dawning within me.

    - Bill Yerazunis

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace