========================================================================= INFO-ATARI16 Digest Thu, 7 Dec 89 Volume 89 : Issue 768 Today's Topics: Absoft Fortran Drachen and Mah-Jong GNU C Floating Point Math Modula-2 Algebra System Prodigy run under Spectre GCR? RatTrap? Shareware Mac STacey Still searching... The Relevance of the PD FORM docs to the PD distribution of FORM ---------------------------------------------------------------------- Date: 7 Dec 89 11:49:24 GMT From: helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!news@ucsd.edu (News System Account) Subject: Absoft Fortran Message-ID: <1440@blackbird.afit.af.mil> In article <891207024528.958022@DMZRZU71-UNI-MAINZ--GERMANY> Ritzert@DMZRZU71.BITNET writes: > There is a serious bug >in the compiler (version 2.3): > >If You want to use a common block only in some subroutines You have to >declare it in Your main program. Otherwise You will get unpredictable >results. This is the only Fortran compiler I have used which behaves >this way (and I have been writing Fortran programs on many systems). > >Michael Ritzert >mjr@dmzrzu71.bitnet This is not a bug. The FORTRAN standard does not require that a common block that is first initialized in a subroutine be saved after the subroutine is exited; although, most FORTRAN implementations do save it. (Sorry, I can't quote the Standard but you can see, for instance, Michael Metcalf's Effective Fortran 77, page 83.) If you would like to keep the common block around and don't want to clutter up the main program by declaring it there use the save command: subroutine foo(args) real args,stuff common/bar/stuff SAVE /bar/ . . . This should work (at least it does in compiler version 2.2). (It sure is nice to finally see some discussion on a real programming language in this newsgroup :-) David E. Bell dbell@galaxy-43.UUCP dbell@afit-ab.arpa ------------------------------ Date: 7 Dec 89 07:28:37 GMT From: cca.ucsf.edu!wet!logic@cgl.ucsf.edu (Henry Kwan) Subject: Drachen and Mah-Jong Message-ID: <842@wet.UUCP> In article <891205001533507.GXJT@RAI.CC.FSU.EDU> BAILEYS@FSU.BITNET (NOLES #1) writes: > >Well, Shanghai and Drachen both use the same game space and rules, so they >are identical simulations of something, but I don't think it is really >Maj-Jong. I believe 'real' Maj-Jong has more tiles, but I am not sure. >Being a big Shanghai/Drachen player, I would certainly like to know for sure, >so are there any Maj-Jong players out there? Fill us in!! > Shanghai is to Mai Jong is what Old Maid is to Poker. Or in other words, it's totally different except for the fact that they both use the same images on the tiles. -- Henry Kwan | AppleLink: D0690 FWB, Inc. | CompuServe: 71320,1034 2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov San Francisco, CA 94109 | UUCP: ?claris,hoptoad,lamc,ucsfcca?!wet!logic ------------------------------ Date: 6 Dec 89 21:11:25 GMT From: fox!portal!atari!apratt@apple.com (Allan Pratt) Subject: GNU C Floating Point Math Message-ID: <1863@atari.UUCP> esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) writes: I just downloaded the copy of GNU C from terminator, oh, two weeks >ago, the same time I downloaded the pml package. Maybe I should try >drgsun. Bammi recently put GCC 1.36 on his server -- say "gcc -v" to find out what version you're using. >At any rate Megamax C blew GNU C away in speed and executable size >(GNU C took twice as long, and the executables were around twice as >large). The only problem with it is that it doesn't have stdlib >functions, although without those I can still improvise. When you say "executable size" do you mean the size of the PRG file? That's not a good indication. There can be any amount of information in the PRG file besides the program: symbol tables, debugging information, etc. If you use -g on the GCC command line, that's your answer: it generates LOTS of info for the symbolic debugger GDB (and UN*X's dbx). The right way to find out executable size is to dump the program's header and look at the size fields. The dump will look like this: 60 1a tt tt tt tt dd dd dd dd bb bb bb bb ... 601a is a magic number. tttttttt is the text (program) size in bytes. dddddddd is the data segment size in bytes. bbbbbbbb is BSS. Compare the SUM of text + data, because GCC might be putting strings in the text segment, while Megamax might put them in the data segment. Also make sure they're both talking about the same things: use -mshort for your comparison (even if the program doesn't work that way) if Megamax has 16-bit INTs. Of course, MegaMax C has *8* bit shorts, and some required keyword concerning modules or overlays or something, so I have no respect for it at all... ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ------------------------------ Date: 7 Dec 89 08:16:14 GMT From: psuvm!jjl101@psuvax1.cs.psu.edu (J.J. Lehett) Subject: Modula-2 Algebra System Message-ID: <89341.031614JJL101@PSUVM.BITNET> Just wondering, before I take the time to download this file, can someone out there post a generalization of just what the Modula-2 Algebra system does? Thanks in advance! ------- ******************************************************************** * J.J. * JJL101@psuvm.bitnet * * * Penn State Center for Academic Computing * * John Lehett * Computational Mathematics * ******************************************************************** ------------------------------ Date: 7 Dec 89 08:32:48 GMT From: fox!portal!cup.portal.com!Bob_BobR_Retelle@apple.com Subject: Prodigy run under Spectre GCR? Message-ID: <24790@cup.portal.com> HOward C. Johnson asked if anyone had gotten the Prodigy software for the Mac to run under Spectre emulation... A friend of mine investigated this very question, and found that the Prodigy software, which ran perfectly on a real Mac, wouldn't run on his Spectre. I don't know exactly what the problem was, but my friend was quite disappointed. We've both used the IBM version of Prodigy under the pc-ditto emulator, and while it runs, it's far too slow to be useful.. we'd looked forward to the Mac version since Spectre runs Mac software at full speed (or better). Unfortunately, it seems destined not to be... BobR ------------------------------ Date: 7 Dec 89 08:05:55 GMT From: eru!luth!sunic!tut!ra!uwasa.fi!hv@bloom-beacon.mit.edu (Harri Valkama LAKE) Subject: RatTrap? Message-ID: <1989Dec7.080555.3093@uwasa.fi> Do anyone know where I can ftp a PD program called rattrap, which should allow me to use menus like in the Mac (ie. so that they don't drop so easily). If not ftp perhaps someone can mail it to me. -- Harri Valkama (hv@uwasa.fi) anon. ftp site (128.214.12.3) ------------------------------ Date: 7 Dec 89 07:48:44 GMT From: fox!portal!cup.portal.com!Bob_BobR_Retelle@apple.com Subject: Shareware Mac Message-ID: <24788@cup.portal.com> Pit Capitain, the author of the ALADIN Mac emulator has replied to a lot of the questions and comments about his offer to release the ALADIN emulator as shareware... One thing I've been wondering about though, is how exactly was the ALADIN implemented..? Obviously it's a disk based, software emulator.. but, how was the problem of needing Mac ROMs addressed..? Was a cartridge similar to the Magic Sac offered to hold the ROMs..? Were you required to figure out something on your own to hold the ROMs..? What exactly was a running configuration of ALADIN like..? BobR ------------------------------ Date: 7 Dec 89 08:37:19 GMT From: fox!portal!cup.portal.com!Bob_BobR_Retelle@apple.com Subject: STacey Message-ID: <24791@cup.portal.com> Good news....! The STacey has passed its FCC type acceptance testing as of today... according to Atari, it should be in the stores in 30 days or less. BobR ------------------------------ Date: 6 Dec 89 21:58:51 GMT From: fox!portal!atari!kbad@apple.com (Ken Badertscher) Subject: Still searching... Message-ID: <1864@atari.UUCP> bds@lzaz.ATT.COM (Buce Szablak) writes: | > It is important to make sure that professional programmers know how to | > program the computers, not end users. | Sorry, you are way off base here. Most PD software comes from end-users [...] I'm not way off base. I may be wrong in your case, and in fact I may be wrong in the case of every person who reads comp.sys.atari.st! But active members of online communities aren not by any means representative samples of ST owners. If the online community were more ubiquitous, I would grant that your experiences were representative, but it isn't, so I can't. My opinion is based on my experience working in a computer store, working with user groups, supporting development tools, and talking with Atari's user group and developer support people. Users, by and large, want to use their computers. As far as supporting hobbyist programmers, I take a pragmatic stance. How much PD software comes from where is not directly important to a computer maker. It is certainly indirectly important, because a wide variety of PD tools make a computer a lot more attractive to the informed buyer. But a wide variety of professional products make a computer more attractive to the market at large. A lot of people buy the computer that runs the software that they want to run. That is why it is vital for computer makers to have a broad commercial software base for their machines. In order for that to happen, strong support for the companies that produce that software must exist. A side effect of having strong support for professional programmers is that end users get supported as well. More books get written by the professionals, making more information available to the hobbyist than the computer maker can hope to provide. A broader base of technically competent people exist to answer the questions of hobbyist programmers. All these programmers will be happy because they can get their questions answered and they can solve their problems without having to stumble around in the dark too much. | BESIDES, aren't I (an end-user who uses | his ST to write programs for enjoyment) a valued customer???? | Aren't my CUSTOMER needs important??? Your attitude really bothers me. Every customer is a valued customer. You are an espeically valued customer, because you take the time to give feedback on how you think Atari is doing. I'm sorry that my attitude bothers you, but I think that it's a practical one. I hope that I've clarified where I'm coming from. Please note: the opinions expressed in this article are mine and mine alone. Atari has its own. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 7 Dec 89 09:12:03 GMT From: eru!luth!sunic!mcsun!hp4nl!nikhefh!t68@bloom-beacon.mit.edu (Jos Vermaseren) Subject: The Relevance of the PD FORM docs to the PD distribution of FORM Message-ID: <581@nikhefh.nikhef.nl> Concerning the remark about `missing features' in FORM. The manual of FORM describes the entire FORM 1.0. The remark about the missing features concerns future development. A symbolic manipulation program is never realy finished. You have to stop somewhere and say: 'this is version 1.0'. Then in later versions there will be more features. The program as it is distributed is fully self sufficient and can be used for a very large number of problems. Suggestions for more features will be very welcome. Jos Vermaseren ------------------------------ End of INFO-ATARI16 Digest V89 Issue #768 *****************************************