Re: problem with trainin since upgrade to blamethesegfault

On Sun, Apr 13, 2008 at 3:47 PM, Bill Y <[email protected]> wrote:
>  Oh, this is worth it.
>
>  The reason to go fork rather than a single-threaded library call is
>  that there are probably variable name clashes between mailreaver and
>  mailtrainer (they started out from sorta the same code base, and
>  hence have overlapping variable names).
>
>  That's why it might be easier to actually get fork() working than
>  the other way 'round.

I can see where a fork() comes in handy, apart from the dinner table
set, don't get me wrong, but this sound like a bit of a kludge to
cover up a booboo (or what does your son call it now?)
Of course the 'alternative' would be to introduce scoped variables
(yeah), which will probably some mail* or other script in yet
unfathomable ways. (But that's me going nuts every time I dabble in
crm scripting and have to remember it's 'globals' all the way up.)

At the moment I'm a bit 'overfed' on crm114 and suffering from the flu
(very probably related) so I'm not editing any code these last few
days: anything I did got reviewed next day by yours truly and all I
could say was "what did I ever think I was doing there???". So I stick
to reading up and playing with my graphics tablet.






>  Every OS that supported multiprocessing I ever used has had a fork()
>  or equivalent (even OS/360; you sent card images to the internal
>  reader and they got put in the job queue.  Woe be the person who
>  submitted a job that submitted two copies of itself...)

he he he :-) 'rabbit scripts'. Fun to kill too. :-)


Cheers,

Ger


PS: Currently on the crm114 now-doing list in no particular order:

0- finish the test setup for mail*.crm scripts using real email - and
using or NOT using the reaver cache while still benefiting from The
Reaver; hang 'em in the GNU 'make check' chain or something too. CRM
Scripts done; need testing though and will probably exhibit some
glaring bugs right off the bat. Makefile + test setup are a mess
because I'm experimenting with selecting email for the test suite to
get some 'nice' results for verification.

1- add checking of some sort to a megatest derivative driven by GNU
'make check' so people can './configure && make && make check' and get
a nice report how bad their build screwed up - or not. In short: (a)
take out the 'Consult The Doctor' for megatest output + (b) add test
cases for every bug or wicked feature spotted in crm114 so when I
continue the compiler rewrite I can validate it's proper operation.
This is in the 'ponder' phase as I haven't yet found a set rig that
given me a good feeling; I want to match 'close-to-equal' stuff too
there.

2- VT redo to make it also suitable for my crazy schemes - which will
also get rid of the GROT GROT GROTs in there - == improved support for
custom 3D vector matrices (was 2D: only for stride==1, now can handle
arbitrary stride ... 'in theory' at least. Code @ 50% progress.

3- completely new async pipe I/O (with optional sync/wait) code for
Win32 syscall(): one code for both async and non-async and finally a
chance to get rid of the spurious I/O lockups when syscall()ed
applications take a while and/or show some 'remarkable' stdin/out/err
I/O behaviour. Code @ total disarray; some little usage detail is off
and my brain is too snotted up to see where the semicolon went wrong
in there.

4- Add fork()-alike feature into the mix; trouble there is that crm114
is relying on some bloody important globals and Win32 doesn't know a
fork() from a spoon(), natively speaking, so those !@#$%^ globals have
to be taken of in TLS-local storage or some other voodoo magic. Code @
0%. More a 'will do' than a 'doing' now.

5- adapt the crm script compiler to make it single pass: currently it
uses multiple passes, which are just ever so slightly unaware of each
other and differ only very little in their opinion on what proper
delimiting actually is. Fringe cases only, but nevertheless. GerH
builds now already are sometimes a bit stricter - or just 'otherwise'
- then vanilla crm114 when it comes to 'disputable crm114 code
constructs' which attempt to tease/abuse the JIT compiler, e.g.
multi-command lines with or without semicolons, code sprinkled with
#...\# comments in legal and illegal places, etc. At the very least
your error reports get screwed when you do stuff like this: no proper
filename mentioned when insert'ing code (mailreaver anyone?) and line
numbers WAY off due to LF-injection by the JIT compiler while NOT
tracking the original code location for error reporting.

6- R&D (performance: 1000+ chains in the linear probe hash tables are
bothering me; I think I can do better / code: long term target is
libcrm114: the globals are hurting me real bad, for one.)
Research papers collected; notes jotted down; brain alight with
'yeah!' but ze!ro! code. libcrm114 may end up to become a C++ job if
my latest brainfart is to be believed: unified classifier code and an
evil way to get rid of the C globals being globals. In flux. Very bad
idea to start coding now.


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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone