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

On Sun, Mar 30, 2008 at 4:59 PM, Steve <[email protected]> wrote:
>  Okay. Here some other stuff I have with GerH sources from hebbut.net.

Okay, up front: thanks a lot for testing all this stuff.

Of course, you've tested some things I haven't in a while. :-(


>
>  When trying to use GNU regex I get the following error:
[...]

I haven't checked GNU/PCRE/POSIX the last, er, many, releases. Last
status known there: crufty.

Which seems to match today's results.

Of course, the lame excuse I can come up with now is hat CRM114 in its
original form is also ONLY supported in combination with TRE, but that
doesn't mean this should at least compile and _try_ to do something
useful.
(Or I should get rid of it entirely and yell & scream my head off when
I can't track down TRE anywhere.)

Anyway, good to know what the output _is_, so I know what to fix.


>  Compiling with verbose output and warnings I get the following issues:
>  [....]

the configure script does its stinking best to turn on all the
warnings the compiler's got (though I didn't turn on --pedantic there,
which might get you another load of warnings; however, it's got some
'issues' on my 64-bit box. :-S

I could go for specifically killing the signed/unsigned warnings, as
typecasting each of those lines won't make the code any more readable,
while it's quite okay: some routines use 'unsigned char' entities to
make sure characters are NOT sign extended to int/int32 while
calculating hashes, for instance, while the remainder of the code
works on your average vanilla 'char' and is completely happy about it.
In other words: 'signed/unsigned' warnings are expected and fine.

Unused vars can be cleaned up, though some of those are used when
specific compile-time options are toggled; that doesn't say these
warnings should be there, just that the coder(s) [like me ;-) ] were
too lazy to put the same toggles around the variable declarations too.



>  crm_test_hashes.c:818: warning: pointer targets in passing argument 1 of 'hashfunc' differ in signedness

Here's a prime example of such signed/unsigned hopping around;
additional note for this source file in particular: it's completely
EXPERIMENTAL and is used by me to test and otherwise mess around with
various hash functions; using different hash functions can sometimes
significantly improve the CSS file usage (reduced number of
collisions). Unfortunately, creating something that hashes very well
yet is fast, is a VERY hard thing to do. :-(

And the hashes have to be identical for a fixed input on any
32/64/N-bit system: I'm driving CRM114 towards cross-platform CSS
interoperability, at least to the level where the machines sharing a
CSS database have identical Endianess and IEEE float layout, while
they MAY differ in basic machine word size.

Why?

Because I want CRM114 to reach a quality level where it can be used in
a distributed, yet disparate, environment. With a bit of care, it can.

Think [web] server park doing load-distributed filtering: there's
various brands of hardware out there that distribute TCP
sessions/requests based on per node load monitoring, very handy if
you've got a mix of old[er] and new boxes in your network-linked
distributed setup. As long as it's all Little Endian (or Big Endian if
you have dough ;-) ) and at least 32-bit word size (no i80286's
anymore ;-) ) and understands, say, a IEEE float, it (the box) can be
used for CRM114 based classifying.
The idea is that one (or a few) machines are dedicated for 'learn'ing
stuff, then share the results (network mount or periodic binary rsync
copy) with the other nodes in the network: that would mean one node
can 'manage' (write) the CSS files and many nodes can use those files
as is.
Vanilla BillY crm114 doesn't permit this type of usage: a 'long', nor
an 'int', is portable across different native word-sized machines, so
no sharing among 32- and 64-bit OS's there at _least_. Expensive
server parks (think banking institutions and the like) don't bother,
they just make sure the park is loaded with [close to] identical
boxes, but if you want a server park El Cheapo, you don't want to
write off your 32-bit machines while you carry in the new 64-bit ones.


Anyway... we were talking about the the errors and warnings...



>  crm_test_hashes.c:2011: warning: this decimal constant is unsigned only in ISO C90

Intersting warning, haven't seen that one on any of mine, but luck has
it's in the hash algo test app code only. Nevertheless, I'll take a
look at this, because this is interesting. Must've been something I'd
missed. PArt of that code is ripped from OpenSSL, so you didn't
compile OpenSSL from CVS recently by any chance?


>  That's all :) Most are anyway just warnings. Would however be nice to not see them at all.

I'll see what I can do. ;-)


>  Another issue I have is, that I can not compile CRM114 with "--enable-static". It just does not work. I don't know why.

Same issue here, also with vanilla BillY makefile. It's on the 'WTF'
to be checked out list, but hasn't got a high prio yet.

All in all, I'd say it's not a platinum performance, but at least
manages to produce something useful. Still loads of work to do there,
though. Portability doesn't come cheap. ;-)


And once again, I _really_ appreciate the amount of time you put into
testing this stuff, because I absolutely _need_ others to test this
for me; I find I'm sometimes way too lucky skipping over my own goofs.



Ah, now if anyone would ever care to write a really nice (read:
thorough) set of automated build [tests] and run tests for crm114, I'd
be _so_ happy. 'make check' (contrasting 'make megatest') has only got
my attention since build 1960, and then it's still an extremely
fragile and geriatric piece of work.
On the other hand, 'make distcheck' has been in use for a long time,
but surely is _not_ enough to catch those .input files missing and
other distro mistakes like it should, at least not in its current
form.


Steve, thanks a lot for sticking with this. I hope you'll help me
again by testing some releases to come.

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