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

   From: "Ger Hobbelt" <[email protected]>

   The hard answer:

   <discarded an explanation that won't hit the neurocortex anyhow.
   Here's hoping...>

   Take a look at OpenSSL one day when you feel like it and check out
   their e_os.h + e_os2.h. Just page through it. That's portable code for
   you. And _then_ go look at one of their hash routines, say, SHA-1, and
   have a look at _that_. Then track down the macros, calls, types, etc.
   in there and their relationship with e_os/e_os2. OpenSSL is used the
   world all over by a great majority of users/developers. _Someone_ must
   have had the same thoughts as you by now, once they've seen this. Then
   why is it still like this after so many years?

   And, no, it's not like that because it's about crypto and
   everycryptobody is raving mad and paranoid to boot and we're not
   _doing_ crypto anyhow. Did I ever mention 'long' or 'int' (or several
   others) being non-portable for specific purposes, like, say, where
   bit-specific operations are performed? Say, a hash calculation?
   Changing the bitwidth of the int/long/what-have-you, will CHANGE the
   behaviour of such an implementation, causing wrap-arounds and overruns
   (which are some of the KEY ingredients for calculating hashes in
   practice: statistical tests WILL produce different results on the
   topic of spread, avalanche, etc. when the bit-width changes, e.g. when
   you stick to int/long. At the very least, the generated hash values
   will not match across systems. And that also means the
   collision-avoidance bahaviour may subtly change. Which starts to count
   once you're going for microgroom on any of the production classifiers
   in there. A thought to ponder?

SSL has the issue that it is blatantly security software, and
as such must go way way out of the way to avoid exploits; much of
*that* is going way out of the way to NOT depend on anything else
that might be subverted.

   Then there's all the mmap()/madvice()/msync()/etc. stuff but I'll save
   that for a later day.

   And besides, it's not like you haven't .configure'd this stuff already
   before. It's just that ./configure is new to your workflow, but the
   code is already sprinkled with platform (hardware/OS/CPU) dependent
   #ifdef checks to Make It Work for several other folks out there. So
   far, so good.

It's not new to the workflow; I use ./configure for a lot of stuff
_from the user end_.  

   You're looking for portability across the board without the
   configuration hassle? One Code To Fit Them All? When you listen to the
   rep sheet presented by the Java folks, you'll GO for the machine
   virtualization thing like you're Born Again, Haleluja! And they'll
   tell you it'll be even faster execution times than compiled languages
   like C/C++ and the numbers will speak for them. Too bad, but there's
   still a little dark evil something waiting for you then. It's got
   patience, my dear. Because this globe is crawling with interns -
   interns of all ages. Interns who never were taught or simply did not
   attend lessons (even when physically present) because girls, parties
   and people in general are _much_ more interesting, don't you agree?
   ;-)

Um, NO.  I was around for the first breathings of Java, and I 
rejected it from my life for architectural reasons (specifically
that the single-inheritance model was _broken_ (you had no flavors
or multiple inheritance) and would mean that
code duplication - cut and paste - was _required_ for productive use,
and thence that multipath bugs (find a bug in one cut and paste, 
miss the 19 other copies) would come to dominate debugging.

Sure enough, ten years later, I'm dating a rather cute programmer
who is constantly _ranting_ about how Java has become a "Write once,
debug everywhere" language.  I know that they've got yet another
misfeature that goes halfway - something like a contract, but
again, it requires separate bodies of code for what should be
the same darn function.  

That's why Java is in my "no fly" zone.  It's got a bite-yer-ass
curve that hits when you have enough classes that it's worthwhile
to code share between classes, and it's high enough in line count
that you've already committed to use Java.

Lua, on the other hand, looks damn fine.


   I'm quite sure you cringe at all this, but this is why people run to
   virtualized languages like Java and C#, because there's just too few
   out there willing to learn how to cope with writing portable C/C++ and
   too many finding out they got stuff that doesn't port to their own
   system. So it's both push and pull towards virtualization. Which
   really is a VERY old concept, only this time around the hardware is
   fast enough not to cause 'virtual' to be a nuisance from the start.

The Java byte code is not the problem.  It's the Java semantics of
single inheritance.  I asked Gosling about this personally and his
response was that "Most programmers are not smart enough to handle
multiple inheritance."

My response:  "If they are not smart enough to handle multiple 
inheritance, they are not smart enough to be programmers.  Let them
do tech support on point-of-sale cash registers."

   Anyway, I can go on for ages about this, but I get (and have been)
   paid serious bucks because people needed cross-portable software
   machinery and I've seen enough people who've written code all their
   (long) life, but never produced one bit that was portable beyond the
   OS/etc. combo they'd started developing on. I didn't get paid because
   I make it sound so complex, but because others proved they simply were
   incapable of doing it. Sometimes, they get to the 90% mark and then
   hit the brick wall. Hard. If you want a setup that's prepared for the
   95 or 99% mark, you need to do something special: that is: realize up
   front what can happen to you when you drop your stuff in uncharted
   territory. Keep _that_ thought when you're going for portability. This
   one's for free.

I know.  :-)

   Summarizing: I don't want you to worry or bother with the portability
   stuff, because it requires a different mindset and it's not helpful in
   any way to what _I_ need most: your extensive expertise with CRM114
   and the knack to find and create stuff (classifiers, etc.) that works
   beautifully on the weirdest data inputs. All I'm asking is that you
   just copy&paste like you always do and if you wonder about another
   HAVE_XXX macro in there: those can be tracked down and analyzed
   easily, one by one. Why have them in there? Same as why you now have
   #ifdef WIN32 in several places. Because it works for you without,
   doesn't for others. Just a different way, which has better potential
   to hit the 99% mark up there that #ifdef/#else/#endif DIY like it is
   today. Nothing wrong with it, I'm just pushing the envelope and that's
   when it starts to ache.

The problem I have is that when there's more than about 10% 
funky macro stuff in a line of code, then I stop being able to see
the flow of the code.  The code becomes effectively opaque to 
me and I _can't_ debug it or extend it.


   And if the ./configure stuff doesn't work for someone, there's enough
   expertise on this ML to fix that. And when that _still_ doesn't work
   for them, there's the config_BillY.h + makefile for them too. Only
   _they_ might have to change their platform where they run crm114 on to
   something else.

Yeah.  Damn.  I hate it when that happens - and it does happen
in reverse.  F'rinstance, the 32/64 bit stuff - I *can't* debug 
or test the fix on a 64-bit-only segfault because I don't have 
a 64-bit machine.

That's why I want to switch over ASAP to portable sized type 
declarations, so that problem starts to go away.


   >
   >
   >
   >    >   crm114_sysincludes.h -- here's where all the voodoo magic is:
   >    > additional autodetecting and mix&merge with config_BillY.h driver
   >
   >  Driver?  I don't know of any driver.

   Sorry, my wording for stuff like this. crm114_sysincludes.h carries
   the brunt of the portability stuff. It's generic, so it needs some
   instructions what to do right now and what not to. That's what the
   config.h (in case of ./configure) / config_BillY.h (yours WTHOUT the
   ./configure) / config_Win32.h (because that platform does not do
   ./configure) is for: it 'drives' the decisions in sysincludes: headers
   to load, functions to define, types to map, etc..
   's all.

OK then, but how about then calling it "config_baseline_linux32.h" instead
of "config_BillY.h"?  That way, it's more obvious when you can
just use that file (and, even better, when you _can't_!)

Similarly, a "config_baseline_linux64.h" , a "config_baseline_windows32.h"
and so on can also exist, and might be darn useful as starting points
to sort out problems.

     - 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