[M3devel] Do I remember well...

Tue Feb 26 19:35:33 CET 2008

Hey I accidentally mostly confirmed this. I changed the backend to just "touch" and it too is slow.
Now, granted, vfork in Cygwin is the same as fork, and does a big memory copy, so it could be that running anything in Cygwin is slow. But I could compare to other platforms..or just try removing it.

Removing this is easy, at least for PTHREADS, right?
And "user threads", can, at worst, do the sleep in their specific code?

I think it might be good to run cm3cg and maybe as only once per directory besides, with all the files at once, or at least a few at time, or with a response file.

Thanks,
 - Jay

> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> ><html>> ><head>> ><style>> >.hmmessage P> >{> >margin:0px;> >padding:0px> >}> >body.hmmessage> >{> >FONT-SIZE: 10pt;> >FONT-FAMILY:Tahoma> >}> ></style>> ></head>> ><body class=3D'hmmessage'>Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.<BR>> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.<BR>> > <BR>> >However..I still believe the implementation is the interface.<BR>> >I don't see how Modula-3 fixes that.<BR>> > <BR>> >> If you use the garbage collector alluded to by Knuth, timing changes<B=> >R>> in your program CANNOT cause it to run out of memory.<BR><BR>> >I didn't mean to necessarily link these things together.<BR>> >Let's say garbage is collected immedately upon it being created.<BR>> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.<BR>> > <BR>> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.<BR>> > <BR>> > > If you use the Extended Static Checker (coded by some of the sam=> >e people <BR> > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown <BR><BR>> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).<BR>> > <BR>> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.<BR>> > <BR>> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)<BR>> > <BR>> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.<BR>> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.<BR>> > <BR>> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.<BR>> > <BR>> >Ok, I'm repeating myself now, sorry.<BR>> > <BR>> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.<BR>> > <BR>> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.<BR>> > <BR>> >Gotta go,<BR>> > - Jay<BR><BR><BR>> >> ><HR id=3DstopSpelling>> ><BR>> >> To: jayk123 at hotmail.com<BR>> CC: m3devel at elegosoft.com<BR>> Subj=> >ect: Re: [M3devel] Do I remember well... <BR>> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800<BR>> From: mika at async.caltech.edu<BR>> <BR>> Jay,<BR>=> >> <BR>> Sometimes I wonder if you have never read the Green Book!!!<B=> >R>> <BR>> The very first section of the Modula-3 definition, Section => >2.1 of<BR>> the Green Book, talks about the distinction between "checked=> > runtime<BR>> errors" and "unchecked runtime errors" and ends with the s=> >entence<BR>> "Unchecked runtime errors can occur only in unsafe modules.=> >"<BR>> <BR>> If I may make one of those philosophical diversions that=> > so often<BR>> lead to Language Wars (but in this case isn't intended to=> >), you<BR>> mentioned something a while back along the lines of (I am no=> >t quoting<BR>> you verbatim) "every line of code is part of an applicati=> >on's<BR>> interface, because it can cause...a change in memory usage or => >expose<BR>> a previously unknown race condition"..<BR>> <BR>> The => >whole point of Modula-3 is that Modula-3 is part of a family<BR>> of too=> >ls, a way of thinking, even, under which this isn't true.<BR>> <BR>> => >If you use the garbage collector alluded to by Knuth, timing changes<BR>&gt=> >; in your program CANNOT cause it to run out of memory.<BR>> <BR>> If=> > you use the Extended Static Checker (coded by some of the same people<BR>&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> ><BR>> race conditions because there ARE no race conditions in your progr=> >am!<BR>> <BR>> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the<BR>> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that<BR>> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked<BR>> runtime errors!<BR>> <BR>> Now it is tr=> >ue that we live in an imperfect world, and that neither<BR>> any mortal => >nor any product of any mortal is perfect, but the WHOLE<BR>> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of<BR>> perfection!!!! All=> > of its users are longing to one day be programming<BR>> in the Elysian => >Fields where there are no race conditions, heap<BR>> overflows due to la=> >zy garbage collectors, nor any unchecked runtime<BR>> errors. Will we ev=> >er get there? I don't know. But for me at<BR>> least, one of the reasons=> > I use Modula-3 is because it tries, and<BR>> I can see how one might fi=> >ll in the gaps and get it all the way.<BR>> I know of no other programmi=> >ng environment that comes to within<BR>> several orders of magnitude of => >Modula-3's performance and satisfies<BR>> the same properties.<BR>> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> ><BR>> Implementations generally don't, as far as I know.<BR>> <BR>&gt=> >; The specification is really only fifty pages long...<BR>> <BR>> Mik=> >a<BR>> <BR>> Jay wrote:<BR>> >This sounds very much how Windows=> > has been but finally changed. <BR>> > <BR>> > It used to be in=> > C++ you could do: <BR>> > <BR>> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */ <BR>> > else ca=> >tch (...) { printf("caught exception\n"); } <BR>> > <BR>> > now=> > you can't. <BR>> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions". <BR>> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software. <BR>&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.<BR>> > They can be raised by code via RaiseExc=> >eption though.<BR>> > <BR>> > There is a similar syntax for cat=> >ching them -- __try / __except. <BR>> > <BR>> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?<BR>> &gt=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:<BR>> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare. <BR>> > (Even if C++ exceptions are implement=> >ed via RaiseException.) <BR>> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix) <BR>> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat<BR>> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" <BR=> >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.<BR>> > <BR>> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas<BR>&gt=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.<BR>> > <BR>> >What about integer overflow? => >I wonder. :)<BR>> > <BR>> > - Jay <BR><BR><br /><hr />Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => ><a href=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmail=> >textlink_jan' target=3D'_new'>Play now!</a></body>> ></html>=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_--
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080226/14ae1674/attachment-0002.html>