[comp.lang.pascal] Info about the new programming language PASCAL-XSC

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!!