Re: New WGET and mainline version up: crm114-20080326-BlameSentansoken --> 64-bit SuSe 10.2 output

On Tue, Apr 1, 2008 at 2:49 PM, Bill Y <[email protected]> wrote:
>  Grumble.... what's most annoying is that I can't really even begin
[...]
>  Even if all it does is to let us run cleanly on Linux on 32 bit OR 64

Once you go that way, at least the segfault risk is far lower. I
haven't looked at why vanilla CRM segfaults, all I can say is GerH
doesn't. Which doesn't say it's the Golden Egg, because NN sure is
slow as a slug on that one.



>  So, I will propose the followimg macros (names carefully chosen to be
>  at least moderately easy to type and easy to do a global replace which
>  gets us most of the way there).   what should the following macros really
>  be?

Bill, I'll second Paolo and Jaakko in this: please use those int32_t,
etc. things they listed. The trick is that from a portability
perspective, I can always make a nonconforming machine believe it's
got uint32_t, etc. too, at least once it's through the
crm114_sysincludes.h+config.*.h and into the CRM code.


One note where I deviate from Paolo/Jaakko:

the hashes - and EVERYTHING that is a derived hash and expected to
behave somewhat like one, like the 'features' - should have their own
type.
GerH has it already:

   crmhash_t

Why? Because then I can quickly change hash bitwidth: when we decide
to support CSS files beyond 2GB, say, ones up to 2T for those special
festive occassions, you can go into sysincludes and change in ONE
place only:

typedef uint32_t crmhash_t;

to

typdef uint64_t  crmhash_t;

, then recompile and all of a sudden you've got a full-fledged 64-bit
hash-based CRM running, allowing 2T CSS files for specials research,
etc.

(Of course, then there's the 'wide' file I/O system support
requirement for mmap() et al and the need for a good, new 64-bit
stnnhash(), but that's all just local stuff and very doable; all that
REALLY MATTERS is that ALL the classifiers have been upgraded all at
once with nil changes to their algorithm codebase. With a few lines of
code you've arrived into the year of the Fruitbat. [Pratchett] ;-)

For special research purposes one might also go the other way: reduced
CSS at uint16_t hashes, but that's not portable to some heavy duty
systems ([older] Crays come to mind) if you're really picky.)


Oh, you may wish to stick with float for IEEE 32-bit floating point.
Any system that doesn't support that is a porting 'issue' anyhow, so
we can always
  #define float
for those boys. (example: VMS/VAX has several floating point formats
on offer, none of which is entirely IEEE 32-bit float like you know
it, but VAX/VMS would be a very interesting exercise anyway, thanks to
the different way paths are written there: they can and will use []
brackets! :-)  Yay! imagine output on a VAX:  :-))

  output [[reaper_cache.known_good]blurb;5]   /howdy there! You feelin' well?/

Anybody got one around for trying a CRM port, btw? Would love to see
it run on some old iron. :-P    [1]



Meanwhile, if I can get you off that 'long' addiction, I'll burn a
candle for any Diety that says he or she's been involved in this. ;-)
FYI: long == int on Win32 at least and on many others too. And for
what it's worth: you're not readily portable to anything that has int
@ 16-bits anyhow so no worries: such systems generally don't have
'long long' (which your code needs), at least none of them that I know
of. Besides, mmap() and others are severely lacking on such boxes too,
so ...






-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt


[1] "Yes, we here at the Museum Of Bloody Expensive Equipment From
Your Ganddaddies Heyday are quite modern in our ways too: all our mail
is filtered using a CRM114 thingamajig running on this trusty old
cluster of VAX/VMS boxes - note the beautiful BlinkenLichten at the
left, by the way - while the tape units you see buzzing over there are
used for what we lovingly refer to as the "Reaver Cache". Extremely
fast and very aerodynamic too if you're into that sort of thing. ...
Yes, ma'am, good question! It serves two purposes: this way we can
show some of our proud heritage still at work, which is much more
interesting than some mothballed exhibit if you ask me, and besides,
we've found it cuts dramatically in our mail server hardware and
license costs up on the top floor. Mr. Gates won't like it but the
board is alight with glee because we're getting fanmail and everybody
who's anybody in Twurp's Peerage now wants an email account with us,
just so they can say they've been VAXed, while we've also been able to
cut back on security in no small way as the risk of copper theft has
become very low: our copper is extremely hot to the touch."

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