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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: Erik Magnuson Subject: Re: ada and robots Date: 1997/06/13 Message-ID: #1/1 X-Deja-AN: 248143340 Sender: erik@sulu.fl.ensco.com X-Nntp-Posting-Host: 204.240.41.183 References: <97060510114032@psavax.pwfl.com> <339E143A.349D@dynamite.com.au> <5nnso2$246h$1@prime.imagin.net> Organization: ENSCO, INC. Newsgroups: comp.lang.ada Date: 1997-06-13T00:00:00+00:00 List-Id: smize@news.imagin.net (Samuel Mize) writes: > We can't tar ALL C coders as careless hackers. You know you've been using Unix too long when you parse this as: $ tar cvf careless_hackers.tar *.c_coders OBAda: I have some (small) sympathy with Joe Gwinn's position that some combinations of Ada83 compilers may have produced very different results. Imagine that you used a generic-sharing compiler orginally for a memory limited system, and then tried to port that code to a similar target that used expansion instead. Or tasking that mapped tasks to OS processes vs. run-time scheduling (and you want to do blocking IO in the tasks.) One of the phrases I remember least fondly when trying to explain why some particular code was ill suited to a particular embedded compiler/runtime/target. "But it runs just fine on our Vax using DEC Ada!" -- Erik