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

On Wed, Apr 2, 2008 at 4:26 PM, Bill Y <[email protected]> wrote:
>  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.

True, but I was referring to the way they handle cross-platform
portability. If you look at other packages which spread across
multiple platforms, for instance gcc, you'll find the same type of
solution to the portability problem. This particular area of 'issues'
has nothing (or very little) to do with algorithms applied within the
application itself, but all with the nitty gritty of run-time library
usage down in the gallows: are you sure function X is available over
yonder? Not 100%? Check for availability, warn developer yonder
[s]he's got to provide a replacement.
Total different ballgame from writing 'regular' applications which run
on a predefined platform.

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

I understand. The point I was trying to make is this: It's just like
with my car. I drive it, and despite my mech engineering background, I
only pop the hood for an oilcheck once in a century. Anything else, I
leave to my mechanic. Now _he_'s got quite different perspective on
cars, compared to the ones only driving them.

Same with the ./configure collective: very many people use it ('drive
the car'); only _this_ time _we_ are being the mechanics, because with
CRM114, you're the one checking the brakes, putting this thing on the
bridge, and running the diagnostics 'because there's this weird
screeching sound in there when I near 70 mph".
This time, you're not only 'user', but also the developer of
./configure-d stuff, because you're working on the software internals
and thus are confronted with the internals of ./configure et al.
And we all know what cars look like on the inside (under the hood and
the covers)...

>  Um, NO.  I was around for the first breathings of Java, and I

I find sarcarm is a very hard thing to pass along through the written
word. This seems to be another occasion where I failed. ;-)

But I'm with you all the way regarding the architecture.

>  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

I'm sure she's very cute. ;-))  I'll wait till she hits the wall on
that one. It's waiting for everyone, if they only go 'wide' (i.e.
platform coverage) enough. 99.9% of corporate development doesn't, so
that saves a lot of bacon.

>  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.

Second _that_!


>  Lua, on the other hand, looks damn fine.

It's under consideration. CRM is taking up too much time though ATM ;-)


>  The Java byte code is not the problem.  It's the Java semantics of

I know, it isn't. It's part of their solution for the 'portability
thing'. And in that regard, it's doing quite well: platform coverage
is much wider with it than without, if you don't ever think about the
context your software is going to run in. CS toddlers can have their
stuff running on more boxes than they ever could get it to run on
before. That's its 'worth'.

>  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."

Amen to that! <hops exitedly />

Pity though; if the world really worked like that, IMO over half of
the current IT population would have to cash in their pink slip at the
unemployment bureau.
Fortunately for them, we need so many IT gardeners, we've found we
cannot afford not to hire large quantities of people who don't know a
root from a branch. And that includes another realization:  there'll
be quite a few festering dungheaps out there. And given the limited
supply of cleaners, we either accept the stink and put on a breathing
mask, or pay them premium to clean it up. It's a judgment call there.


>  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.

I get it. (And realize I was once referred to by a friend as the
'Macro Man' ;-( Not good. <:evil:>)

So far, the little consolation I believe I can offer is that the only
'funky' macro stuff in there is in the [non]fatalerror[_ex]() code,
where a bit of macro-ism in the fake SRC_LOC() function is used to
dump all the source code location references into a variable argument
function - which may be a bit of showstopper for you.

The rest is just a bunch of yes/no decisions if and when to load a
particular header file can be #include'd because this system has it
available, followed by a bunch of checks for stuff that should
hopefully already have been provided by those headers and now what to
do it those buggers didn't. A look at crm114_sysincludes.h +
config.*.h might be enlighting in that regard. It's quantity mostly.


>  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.

If I have to sell you this: yes, it'll go away.
If you want the hard answer: yes, it'll be reduced _significantly_.


>  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.

Excellent idea. I'll do it.



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
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