kirchner@informatik.uni-kl.de (Reinhard Kirchner) (04/22/91)
For those, who are interested using the new programming language PASCAL-XSC, here a short abstract about the language features: PASCAL-XSC is a powerful and easy to handle programming language particularly suited for scientific and numerical applications. The key elements of this language, which contains standard PASCAL, are generalized functions, a general operator concept, overloading of procedure and function names and operator symbols, dynamic arrays, modules and a dot product expression handler delivering results of maximum accuracy. In PASCAL-XSC, program packages have been developed for many standard problems of numerics. The computer verifies the existence and uniqueness of the solution within tight computed bounds. The whole PASCAL-XSC system runs under C and is therefore highly portable. It is available for virtually all computer systems. The system is available as a ShareWare product from the newsgroup comp.binaries.ibm.pc and running under Microsoft C 6.0. Michael Neaga email: AE18@DKAUNI2.BITNET
w8sdz@rigel.acs.oakland.edu (Keith Petersen) (04/22/91)
kirchner@informatik.uni-kl.de (Reinhard Kirchner) writes: >PASCAL-XSC system runs under C and is therefore highly portable. It is >available for virtually all computer systems. > >The system is available as a ShareWare product from the newsgroup >comp.binaries.ibm.pc and running under Microsoft C 6.0. Does this mean that Microsoft C 6.0 is required in order to compile programs generated by PASCAL-XSC, or does it mean that you used Microsoft C 6.0 to create the MS-DOS version of this compiler? The description in the cbip posting lead me to believe I would have to purchase Microsoft C 6.0 in order to use your package. By the way, this package is 380K smaller in ZIP format. When are we going to quit wasting network bandwidth and user download time with ZOOs? Keith -- Keith Petersen Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
ralphs@seattleu.edu (Ralph Sims) (04/22/91)
w8sdz@rigel.acs.oakland.edu (Keith Petersen) writes: > By the way, this package is 380K smaller in ZIP format. When are we > going to quit wasting network bandwidth and user download time with ZOOs? Let's do it. There's an un-zip for *nix, which could probably be ported to other platforms (maybe even VMS). I'd be more inclined to stay with ZOO, if the compression on the pending release approaches ZIP. Rhaul? -- halcyon!ralphs@seattleu.edu The 23:00 News and Mail Service - +1 206 292 9048 - Seattle, WA USA +++ A Waffle Iron, Model 1.64 +++
shaunc@gold.gvg.tek.com (Shaun Case) (04/23/91)
In article <6058@vela.acs.oakland.edu> w8sdz@wsmr-simtel20.army.mil writes: > >By the way, this package is 380K smaller in ZIP format. When are we >going to quit wasting network bandwidth and user download time with ZOOs? > Ole! I agree. After a nice lengthy download and decode session, I have to sit here and wait for my PC to convert everything from zoo to zip. It's a real drag.
mcastle@mcs213c.cs.umr.edu (Mike Castle {Nexus}) (04/26/91)
In article <6058@vela.acs.oakland.edu> w8sdz@wsmr-simtel20.army.mil writes: > >By the way, this package is 380K smaller in ZIP format. When are we >going to quit wasting network bandwidth and user download time with ZOOs? > >Keith >-- >Keith Petersen >Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] >Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu >Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND Uh, oh! I can see an archiver religion war coming up!! ZOO vs ZIP vs LHA. *sigh* Well, I missed the last one (I assume there was one before, from one article I read by Bill back when I first started reading news last semester), so I guess this will be an experience. Let's try to keep this civilised though, okay folks? If I wanted fanatical ravings, I'd read alt.computer.religion. ;-> I suppose we should list all the good and bad points of all the popular formats. ZOO: Good points: 1) Our infamous leader (that's Bill) has a bunch of useful scripts that speed up checking all this stuff and it would be time consuming to change (and from Bill's recent posts, he's pretty busy as it is). 2) Ported to unix, I believe (ppl can extract doc files and such too make sure it's a package they want before downloading over modems). 3) It's free!! (always a plus) 4) It has a 'test archive integrity feature' that saves a lot of trouble. No having to delete a bunch of files extracted from an archive so broken as to be useless, and FIZZ exists as well. 5) Archiver/extracter in one program. Bad points: 1) Compression is not all that great. (Has Rahul considered working on this?) 2) *personal point* I find it a bit cumbersome to use, but that may just be a lack of familiarity more than anything. ARC: Good points: 1) Better compression (I suppose someone will have to look up or post comparisons for all these). 2) Several archivers/extracters (Sea/PKWare/PD). 3) Ported to unix. (I believe the version on unix is PD, at least I assume so since the source is available. Has anyone compiled this version for DOS??) 4) Archive testing feature. Bad points: 1) Format is copyrighted by Sea isn't it?? What kind of problems does this cause for pd stuff?? (Sea sued PKWare, but PKWare was making money off of it. Who they gonna sue for a pd implementation??) 2) Costs money for the most part. 3) Separate archiver/extracter (at least the PKWare versions I've seen. Never played with any of the others, so don't know). ZIP: Good points: 1) Great compression. 2) Very popular. 3) Authentic verification (sp???) feature (though I've yet to figure out how to implement this. Registered versions only??) 4) Integrity checking feature. 5) Extracter ported to unix (though I've heard of at least one case where it's failed (old version maybe?)). 6) PD extracters available. 7) PKZIPFIX for fixing broken archives (not free how ever). 8) Utilizes 386 instructions if applicable. Bad points: 1) Shareware (though people are working on pd versions). 2) Requires separate archiver/extracters. 3) Uses LZW compression which copyrights may or may not eventually cause everyone a lot of stupid headaches. LHA(RC): Good points: 1) Better compression than zip. (Speed is not a question here, we're talking about sending across the world, not extraction at the end user level). 2) Public domain (all references to pd stuff includes 'freeware'. I'm only taking into consideration cost for the end user, not making sure they give credit where credit is due), but I'm not sure about the new LHA version. 3) Integrity checking feature. 4) Ported to unix. (At least I believe it has. At anyrate, source is available). Bad points: 1) Chokes on broken archives (at least the one I had. Supposed to be a separate utility for fixing them, but never tried it). 2) Have heard that chokes on long names in archives generated on unix machines (have also heard that another dos implementation (not the official release) handles this. Again, not personally verified). 3) *personal point* clumsy command line switches (again most likely stupid user error here :-). ARJ: *personal favorite for reasons other than being considered here* Good points: 1) Compression comparable to or better than LHZ files. 2) Public domain (though donations are appreciated). 3) Integrity checking feature. 4) Extracter code available (though haven't tried it on a unix machine yet). 5) Expected to be ported to unix (this may be vaporware though... we'll see). Bad points: 1) Not well known (very new). 2) Going throught a LOT of upgrades in a very short time. Compatibility problems possible?? 3) Clumsy command line switches (very similiar to LHA(RC), but still not used to them). TAR/COMPRESS: Good points: 1) Fairly decent compression. 2) Ported to DOS (originally done on unix). Bad points: 1) No partial extraction/decompression (all others have partial extraction, so can check doc files. tar -T option doesn't count, still have to uncompress the whole package). 2) No integrity checking feature. 3) A lot of dumb extractors for tar (DJTARX which comes with DJ's port of GCC handles mapping of files well, but never tried on a non-386 so I don't know if it can be run on anything less than that). In looking back over this, I realize that I've been somewhat in consistent in what I listed as points of interest. I suppose the following are what should be considered at important: 1) Compression: We are talking about bandwith here. Keith said 380K was saved as a zip file. Out of how much?? (I didn't get the package, and I don't remember it from the original posting). Is the compression savings really worth the trouble of making the change?? Remember, that's a fairly large installed user-base out there that will have to be reeducated on using a new archiver/extractor. 2) Integrity: How robust is the method? No sense using it if any number of the posts become corrupt. 3) Ease of use: Most of these are fairly easy to use. The only one not is the 2 step process of tar/compress. 4) Portability: This might be an important issue for people who have to download these over a 2400 baud modem. It's nicer to be able to check the documentation thoroughly to make sure it's a package you want before you download. Enough rambling. I guess we'll see what comes of this. My personal vote would be to use LHA(RC) or ARJ for 2 main reasons: Compression and price. #DISCLAIMER: The above is subject to possible mis-information. It is based on what I have heard and what I have read on the network. No attempts were made to mislead anyone, but errors are possible. This is also a fair amount of opinion in there, and it should just be taken with a grain of salt. Regards, Mike -- Mike Castle (Nexus) s087891@umrvma.umr.edu or mcastle@mcs213k.cs.umr.edu Feel lonely? Want someone to send you e-mail? Just post to *.test with a Reply-To: field, and watch your mailbox explode!!