From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Real-time dyn allctn (was: Ada vs C++ vs Java) Date: 1999/01/29 Message-ID: <78simc$7u3$1@plug.news.pipex.net>#1/1 X-Deja-AN: 438354419 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77mu1h$n6m$1@galaxy.mchh.siemens.de> <77no7p$d65$1@nnrp1.dejanews.com> <78i6m3$505$4@plug.news.pipex.net> <78im07$86a$1@nnrp1.dejanews.com> <78lv2n$dpl$2@plug.news.pipex.net> <78on0o$9rb$1@nnrp1.dejanews.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java Date: 1999-01-29T00:00:00+00:00 List-Id: dmitrik@my-dejanews.com wrote in message <78on0o$9rb$1@nnrp1.dejanews.com>... [printer example] |Definitely not hard enough. How about "Stack Overflow", "Out of memory" or |"Page too Complex" printed nicely on top of otherwise blank page coming ouf of |certain well-known brand of laser printer? Or a suggestion to install more |memory in User Manual? They've got a big reset button on the front panel after |all. You know the one! Yes, it did indeed print a page with "Out of Memory" at the top. It _then_ proceeded to print what it could on the _next_ page or even _several_ pages (typically all garbled rubbish). Calculated to annoy the poor user. This is why subsequent models had: (a) more memory in the base configuration to start with; (b) serious compression algorithms. But what other choice did we have? [mapping program example] |Was it really *hard real-time* app? |As I understand in situations like this you've got only 3 choices: |a) Stick another (64) megabytes and hope it won't blow up. We were working on diabolically underpowered machines. Megabytes? We were glad to get a few more KB. |b) Handle stack overflow "gracefully" with a message "Unable to process all |your data. Some enemy missiles will not be intercepted". Read it and weep (well, I do). This is _exactly_ what it had to do. |c) Statically *prove* your recursion is limited and enough stack space is |available under any circumstances. The map data was fixed, so we could run it through and simply measure maximum stack depth. But then guess what? They changed the map data. But it still worked. |What choice did you make BTW? In the end, we never had to: the entire project was cancelled (just as it got to the 1Bn pound mark). ------------------------------------------- Nick Roberts ------------------------------------------- PS: none of this really happened, and I was never there. Okay?