HDTenEightyP/NetNews huggingface dataset:
From: mgmam@uxa.ecn.bgu.edu (Mark A. Morrell)
Subject: Re: Linking JPI M2 to MicroSoft C .OBJ
Organization: Educational Computing Network
Date: Mon, 16 Nov 1992 17:25:49 GMT

In article <18376.2B02109B@puddle.fidonet.org> John.Mcmonagle@f590.n139.z1.fidonet.org (John Mcmonagle) writes:
>
> MAM> I'm trying to link JPI Modula-2 to an object file which was written with
> MAM> Microsoft C.  I don't have the source to the object file, or anything
> MAM> useful except the names of the procedures included.  I've tried wading
> MAM> throught the JPI documentation to try to find which pragmas I need in
> MAM> order to make the link work, but I haven't quite been able to do it.  I
> MAM> was hoping someone out on the nets would be able to help me out.
>
>The following is from a definition  module that interfaces to a MSC
>library in the large model.
>
>(*# module(implementation=>off, init_code=>off)                 *) 
>
>DEFINITION MODULE MW;
>
>
>(*# data(near_ptr => off),
>    call(o_a_copy => off, o_a_size => off, c_conv => on, near_call => off,
>    reg_saved => (si, di, ds, st1, st2), reg_param => ()),
>    name(prefix => c)
>  *)
>
>Hope this helps. 
>I'm not really that much of an expert at those pragmas. 
>One other thing that could cause problems is  the TopSpeed linker may
>not like some things in msc obj's, but at least Sean Wilson at the
>Clarion US office has ways to fix most possible problems. Clarion US

Thanks for the help on this, but I already got that stuff out of the
developers guide.

I found that the real problem was that even with this stuff, the linker
wasn't linking in the object code.  I had to add the line:

#pragma link(clogin.obj)

to the project file in order to make the linker use the object file.  I
would have thought that having the definition file with the 
implementation=>off (just like you have above) would have done it, but
you have to TELL it to link the obj.  BTW, all of what you have above 
is also correct.  Thanks for the effort...
-- 
--------------------------------------------------------------------
Mark A. Morrell     Disclaimer:  _I_ probably don't even believe it.
Literary Reference:  The introduction to Cervantes' Don Quixote.

Newsgroups: comp.lang.modula2
From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
Subject: Re: Oberon-2 discussion continues
Organization: University of Ulm, SAI
Date: Mon, 23 Nov 92 06:55:13 GMT

In article <37695@uflorida.cis.ufl.edu>, bmr@buoy.cis.ufl.edu (Benedict Rafanello) writes:
> |> >>>  e) DEFINITION & IMPLEMENTATION merged.
> 
> |>  >>This was a really bad move.  Now you can't define the interface separately
> |>  >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
> |>  >>of Wirth's work.  Even if you accept that merging the def and imp is good,
> |>  >>interface details like READONLY really deserve their own keywords.
> 
> |>  No, this is a good move.  The maintenance of only 1 file is a big
> |>  win.  If you are concerned about the definition being published with
> |>  the source, don't worry.  There is a `Browser' module which will
> |>  output a definition for a compiled module.  You can then ship the
> |>  defintion (sans comments, unless you provide them) with your object
> |>  modules.
> 
> If both the interface and the implementation are in one file, how do you
> tell when only the implementation was changed?  This is very important for
> large projects.  Some of the projects that I have been involved with contain
> more than a million lines of code.  These projects (done in Ada) would take
> several DAYS just to compile.  If the interface to a package was changed,
> we would have to go through that horrendous compile cycle whereas if just
> the implementation was changed, we only needed to relink.  How does Oberon
> handle this?
> 
> Ben

The Zurich Oberon compiler generates symbol files (interface definitions
for the compiler itself) like Modula-2 compilers for definition modules.
On compilation of a module, you may choose whether to recreate a
symbol file or not. If you don't recreate the symbol file but the
compiler detects differences between the new module and the old symbol
file, you get some nice error messages.

This, of course, makes compiling more difficult: usually you are trying
to compile without generating new symbol files. Only in case of error
messages, to try to recompile it with the \s flag.

Until now, I haven't detected any sufficient support for something like
make on UNIX-Systems, so it's a non-trivial task to compile greater
stuff under the Oberon-System. Please tell me if this has been changed
in the latest versions or if there is some work on this in progress.

Nevertheless, I still prefer the idea that I have a source file with
a time stamp which represents the interface. That's good for my makefiles
and my personal overview. A separately formatted and hand-written
definition module is a document which cannot be replaced by the
browser tool of the Zurich Oberon system.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
Newsgroups: comp.lang.modula2
From: templ@inf.ethz.ch (Josef Templ)
Subject: Re: Oberon vs Modula-2
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sun, 22 Nov 1992 12:54:24 GMT

> MODULE t03;
>    TYPE c = RECORD a, b: INTEGER END;
>    PROCEDURE e;
>       TYPE b = POINTER TO c;
>          c = ARRAY 3 OF CHAR;
>       VAR p: b;
>    BEGIN (* e *)
>       p^[1] := "x";
>    END e;
> END t03.

S. Bevan writes
> I'd call that more than an ambiguity.  My _interpretation_ of the
> rules (and the one I implemented) was that the above program was
> invalid, but that if you switched the order of "b" and "c" it would be
> valid.  Is the above (jt) interpretation going to be made official at
> some point? 

IMHO, our interpretations are exactly the same.
It is the interpretation that evolves naturally from "single pass compilation".
Unfortunately, the current report allows a different interpretation
because it does not restrict the forward declaration rule to
forward declarations. In this sense, the report is ambigous.
It does not specify which c is to be taken as the pointer base type.
If you switch b and c, there is no ambiguity even in the current report.

- Josef Templ
the usual disclaimer applies
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2 (Re: mail delivery error)
Date: 18 Nov 92 19:58:12 GMT
	<1992Nov11.102409.12183@jyu.fi>
	<1992Nov13.100154.6167@informatik.uni-ulm.de>
Organization: Department of Computer Science, University of Manchester
In-reply-to: borchert@titania.mathematik.uni-ulm.de's message of 13 Nov 92 10:01:54 GMT

In article <1992Nov13.100154.6167@informatik.uni-ulm.de> borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:

   Don't forget that Oberon still needs less than 20 pages of language
   description.

Maybe be so, but it doesn't include a formal definition of the context
constraints (static semantics if you will) nor the dynamic semantics.
You may think it doesn't require either, however I've personally
struggled to make sense of the typing rules in the appendix (some of
which IMHO are redundant!) in an implementaion of a Oberon-2 front
end.  I found myself having to write bits of code and try them out
using the ETH compiler to see what (if any) errors it produced.

bevan
Newsgroups: comp.lang.modula2
From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
Subject: Re: Oberon vs Modula-2
Organization: University of Ulm, SAI
Date: Thu, 19 Nov 92 08:14:13 GMT

In article <gpjqq!h+@aix01.rz.fht-mannheim.de>, mw%ki.fht-mannheim.de (Marc Wachowitz) writes:
> Andreas Borchert (borchert@titania.mathematik.uni-ulm.de) wrote
> in reply to Markku Sakkinen <sakkinen@jyu.fi>:
> : Agreed, programmers shouldn't be enforced to use VAR-parameters
> : for reasons of efficiency only. But, even with the semantics of
> : Oberon or Modula-2, it's not to difficult for the compiler to
> : detect that your 1000 x 1000 array isn't modified and, thus,
> : doesn't need to be copied.
> 
> That doesn't work as soon as your procedure is public and (directly or
> indirectly) calls some procedure not fully known to the compiler, since
> the original argument may be accessible and modified behind the back of the
> supposedly innocent routine. According to the current definition it only
> sees a copy made at the entry and therefore would not be influenced by the
> perfectly legal modification, but due to our smart optimizer ... :-(

Probably, you are speaking of a situation like the following:

   TYPE BigArray = ARRAY 1000, 1000 OF REAL;

   VAR
      bigarray: BigArray; (* global accessible *)

   PROCEDURE NastyProcedure;
      (* probably in another module, so we can't see it if
	 we are compiling InnocentProcedure
      *)
   BEGIN
      bigarray[0][0] := 1.0; (* modify bigarray somewhere *)
   END NastyProcedure;

   PROCEDURE InnocentProcedure(bigarray: BigArray);
      (* bigarray is not modified by InnocentProcedure itself *)
   BEGIN
      NastyProcedure;
   END InnocentProcedure;

   PROCEDURE CallingProcedure;
   BEGIN
      InnocentProcedure(bigarray);
   END CallingProcedure;

There may be different viewpoints on this problem: either large
parameters are copied by the calling procedure or by the called
procedure (the latter case reduces code size if the procedure
is at least called at one location which should be usually the case).

Generally, this kind of optimization is only possible if

(1)	we know the code of the called procedure (because it
	is part of the same module), or if
(2)	the code for copying large parameters is part of the
	called procedure.

AND

(3)	the called procedure does not modify the parameter itself
	or calls anything which may modify the parameter.
	This requires all procedures to be known which
	are called by InnocentProcedure or, if InnocentProcedure
	is not exported, we may conclude from the inaccessibility
	of all parameters (i.e. if only local parameters get
	passed to InnocentProcedure).


This, of course, means that there may be cases where we have to
copy the big array without real necessity. But there still remain
enough possibilities to apply this optimization technique.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
From: A7101DAA@HELIOS.EDVZ.UNIVIE.AC.AT
Newsgroups: comp.lang.modula2
Subject: High Precision Timer for Modula-2
Date: 18 Nov 92 18:25:15 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet
X-Unparsable-Date: Wed, 18 Nov 1992 19:09:27 MEZ

I am looking for a High Precision Timer Module in Modula-2, especially in
TopSpeed. It should be something like TPHRT3 for Turbo-Pascal 5.0 to 5.5.
It should use the 8253-chip on the PC to measure time
accurate to micro!!seconds.

Or does anyone know how not TopSpeed objects (.OBJ) (or .TPU's) can be linked
to TopSpeed? The TopSpeed Tech-Kit doesn't tell too much about it

   I hope someone else encountered this problem
               Sincerely
                                Peter Stadler
From: Rt.Pollock@f414.n229.z1.fidonet.org (Rt Pollock)
Newsgroups: comp.lang.modula2
Subject: Modula-3
Date: Tue, 17 Nov 92 19:01:01 PDT
Organization: FidoNet node 1:229/414 - ComPro Systems Node, Bowmanville ON

This enquiry is being made on behalf of a local friend who is 
looking for information regarding MODULA-3; indeed, until he had 
asked me about this, I wasn't even aware that Wirth had revamped the 
language. Between the two of us, we're completely at a loss over 3.
 
Are there any recommendations over 3's suppliers ? Where ? How much ?
What are the virtues of 3 over 2 ? 
 
Any help that can be rendered would be greatly appreciated.
 
By the way....are there any DEC Rainbow people out there ?
 
Semper Fi
RTP


--  
uucp: uunet!m2xenix!puddle!229!414!Rt.Pollock
Internet: Rt.Pollock@f414.n229.z1.fidonet.org
From: darrelld@SED.STEL.COM (Darrell Duane)
Newsgroups: comp.lang.modula2
Subject: subscribe
Date: 22 Nov 92 02:36:22 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet

please subscribe me to the modula2 list
darrell duane
darrelld@sed.stel.com
Newsgroups: comp.lang.modula2
From: tchannon@black.demon.co.uk (Tim Channon)
From: mw%ki.fht-mannheim.de (Marc Wachowitz)
Subject: Re: Oberon vs Modula-2
Date: Mon, 16 Nov 92 18:35:02 GMT
Organization: Fachhochschule fuer Technik Mannheim
X-Newsreader: TIN [version 1.1 PL6]

Andreas Borchert (borchert@titania.mathematik.uni-ulm.de) wrote
in reply to Markku Sakkinen <sakkinen@jyu.fi>:
: Agreed, programmers shouldn't be enforced to use VAR-parameters
: for reasons of efficiency only. But, even with the semantics of
: Oberon or Modula-2, it's not to difficult for the compiler to
: detect that your 1000 x 1000 array isn't modified and, thus,
: doesn't need to be copied.

That doesn't work as soon as your procedure is public and (directly or
indirectly) calls some procedure not fully known to the compiler, since
the original argument may be accessible and modified behind the back of the
supposedly innocent routine. According to the current definition it only
sees a copy made at the entry and therefore would not be influenced by the
perfectly legal modification, but due to our smart optimizer ... :-(

-------------------------------------------------------------------------------
 Marc Wachowitz, mw@ki.fht-mannheim.de   /  news zombie - reply by e-mail, too
  *  wonder everyday    *    nothing in particular    *    all is special  *
Newsgroups: comp.lang.modula2
From: templ@inf.ethz.ch (Josef Templ)
Subject: Re: Oberon vs Modula-2
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 23 Nov 1992 12:42:07 GMT

Andreas Borchert writes:
> I don't see any interpretation which allows the declaration "b = POINTER TO c"
> to be bound to the previously declared type "c". The amendments take
> precedence over the statements before (that follows clear from the text)
> and, consequently, I may declare the referenced type even if there
> exist the same identifier in the outer scope.

Intentionally, there is no difference in Oberon and Oberon-2 on this topic.
The formulations, however, vary slightly.
Taken literally, the Oberon-2 report is (IMHO) ambigous and the Oberon
report may be more than ambigous (i.e. wrong).
Considering the intention, both reports introduce a special rule for
pointer forward declarations. This rule should only be applied
if the pointer base type is not visible, i.e. if a forward reference
is made. There is no forward reference if the base type is already
declared. Consequently, the forward declaration rule cannot be applied.

But, wouldn't it be nice to resolve these ambiguities by removing
local types (and procedures and constants) from the language?

- Josef Templ
the usual disclaimer applies
From: dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd)
Newsgroups: comp.lang.fortran
Subject: Re: Jumping from nested subroutine to main directly?
Date: 21 Nov 92 15:13:26 GMT
Reply-To: dodd@roebling.poly.edu
Organization: Dept of Chemical Engineering, Polytechnic Univ, NY, USA
NNTP-Posting-Host: mycenae.cchem.berkeley.edu
In-reply-to: jchauvin@netcom.com's message of Sat, 21 Nov 1992 01:50:26 GMT


>>>>> "John" == John H. Chauvin <jchauvin@netcom.com> writes:

  John> Is it possible to transfer control from a nested subroutine directly to the 
  John> main routine without have to execute multiple returns from all the 
  John> subroutines in between?  I would like a way of exiting directly to the main 
  John> routine when a error is detected six or seven subroutines down.

I would be interested too.  I don't think that there is an easier way than
doing

     .
     .
     call a
     if (topmost) return
     .
     .

(where `topmost' is set to .true. within `a') for all subsequent calling
routines.

Larry
Newsgroups: comp.lang.fortran
From: rolfe@dsuvax.dsu.edu (Tim Rolfe)
Subject: Re: Print characters on one line without newline...???
Organization: Dakota State University
Date: Mon, 16 Nov 1992 20:16:14 GMT

a.cs.uiuc.edu denies any knowledge of ctaylor, and gets major indigestion
at the "sparc0b!ctaylor@cs.uiuc.edu" construction, so I guess I'll post my
suggestion here.  Bandwidth apologies, etc.

In comp.lang.fortran you write:

>         I'm writting this PrintX routine that is to print
>the letter X n times on one line without any spaces and
>newline.  My PrintX routine looks like this:

>      SUBROUTINE PrintX(XCOUNT)
>        INTEGER XCOUNT

>        INTEGER i

>        DO 10 i, XCOUNT
>          PRINT 20
>  10    CONTINUE
>  20    FORMAT(1X, 'X')

>        PRINT *
>        
>        RETURN
>        END

>correct: XXXXX...X
>incorrect: X
>           X
>           X
>           .
>           .
>           X


I am only familiar with FORTRAN-77; under that I don't think there's a
standard-conforming method to do EXACTLY what you're asking for.  Many
implementers, though, have the formatting character "$" in their superset
--- you may well want to check on the Fortran for your machine.

What's wrong, though, with building a character string and outputting THAT.
Even better for the specimen code, though, would be using an implied
DO-loop.

      SUBROUTINE PrintX(XCOUNT)
      INTEGER XCOUNT
      INTEGER i
      if (XCOUNT .gt. 0) then
         print 10, ('X', i = 1, XCOUNT)
      else
         print 10
      end if
   10 format (1x, 80a1)
* I don't know if you intended the extra line or not:
*?    print 10
      return
      end
-- 
                                              --- Tim Rolfe
                                           rolfe@dsuvax.dsu.edu
                                            ROLFE@SDNET.BITNET
From: mstemper@ems.cdc.com (Michael Stemper)
Newsgroups: comp.lang.fortran
Subject: Re: How does one return a logical value...???
Date: 18 Nov 92 19:17:20 GMT
Article-I.D.: nntp_ser.30476
Reply-To: mstemper@ems.cdc.com
Organization: Empros Systems International, a division of Ceridian

In article <BxwrJC.GME@cs.uiuc.edu>, ctaylor@cs.uiuc.edu (Conrad W Taylor) writes:

>         I have written a function which returns a logical
>value, CheckActivity(previous, ROWS, COLS), previous is an
>array.  I'm using it like this:
>
>        IF (CheckActivity(previous, ROWS, COLS) .EQ.  .TRUE.) THEN
>          uncontrol = uncontrol + 1
>        ENDIF
>
>My compiler says that I have mixed types when I use .TRUE.

Does this module contain a declaration:

      LOGICAL CheckActivity

If not, it thinks that CheckActivity is of type REAL, which would
certainly be mixed types.

One comment on style.

      .EQ.

is a logical operator that returns either .TRUE. or .FALSE.
For instance,

      (J .EQ. 3)

Is a logical expression. It has a value of either .TRUE. or .FALSE.
depending on the value of J.

The IF statement has the form

      IF (lexpr) THEN

Where lexpr is a logical expression. Since CheckActivity is a logical
function (or it will be after you declare it), you can simply say:

      IF ( CheckActivity(...) ) THEN

rather than:

      IF ( CheckActivity(...) .EQ. .TRUE. ) THEN

This latter usage is leagl but redundant, just like

      IF ( (J.EQ.3) .EQ. .TRUE. ) THEN

would be.
      

-- 
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mstemper@ems.cdc.com
From: mstemper@ems.cdc.com (Michael Stemper)
Newsgroups: comp.lang.fortran
Subject: Logical operators and operands
Date: 19 Nov 92 16:31:07 GMT
Reply-To: mstemper@ems.cdc.com
Organization: Empros Systems International, a division of Ceridian

In article <30476@nntp_server.ems.cdc.com>, mstemper@ems.cdc.com (I) wrote:
>
>      IF ( CheckActivity(...) .EQ. .TRUE. ) THEN
>
>              ... is leagl but redundant, 

Not only is it not leagl, it's not even legal!

As Richard Maine pointed out to me, .EQ. and .NE. do not accept
logical operands. The correct operators are: .EQV. and .NEQV.

#pragma opinions ON

This seems dumb! Why shouldn't the operators for equality and
inequality be the same, no matter what type of operands are
used? It seems to me that this is poor language design. Can
somebody come up with a plausible excuse for this? Is it:
 a) Tradition
 b) History
 c) Easier to optimize compilers
 d) Grandfathered in

#pragma opinions OFF

-- 
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mstemper@ems.cdc.com
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.fortran
Subject: Re: How does one return a logical value...???
Date: 20 Nov 92 21:19:11 GMT
Organization: CWI, Amsterdam

In article <BxzC1x.n0s@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
 > but now i was wondering why the writers of the standard 
 > defined these new operators, .EQV. and .NEQV.
 > to a first sight, it seems that overloading .EQ. and .NE. should be
 > possible: the compiler would select the operator by looking at the
 > operands.  Just as .GT. works for both integer and floats.
 > Yet, if they did it this way there is probably a good reason.
 > Does anybody know why?
 > 
Consider:
	A .EQ. B .EQV. C .GT. D
which as such can be written without parenthesis.
This might have been a consideration.  (In passing I
note that Algol 60 has also different equality operators
for Booleans and non-Booleans, and Jim, Algol 60 has
implication as operator.)
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: How does one return a logical value...???
Organization: Los Alamos National Laboratory
Date: Mon, 23 Nov 1992 19:16:51 GMT

In article <1992Nov20.210324.3906@draco.macsch.com>, dnl@convex.is.macsch.com (David Lombard) writes:
|> >[...]
|> 
|> The following statement is fairly clear:
|> 
|> 	IF( A.EQ.B .EQV. C.EQ.D ) ...
|> 
|> What would you do with this phantom?
|> 
|> 	IF( A.EQ.B .EQ. C.EQ.D ) ...

Well, of course you could have written it:

      IF((A.EQ.B) .EQ. (C.EQ.D)) ...

Frankly, I'd have put in the extra parenthesis even if you'd used
the .EQV. operator.  Outside the *basics*, precedence is not to be
relied upon (in some languages, people are advocating the elimination
of precedence even for the basics - add, vs. multiply for example).
A few extra parenthesis to reinforce your intent with lesser-used
operators seems sensible.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: How does one return a logical value...???
Date: 18 Nov 92 17:00:45 GMT
Organization: Cray Computer Corporation

In article <BxwrJC.GME@cs.uiuc.edu> ctaylor@cs.uiuc.edu (Conrad W Taylor) writes:
>
>         I have written a function which returns a logical
>value, CheckActivity(previous, ROWS, COLS), previous is an
>array.  I'm using it like this:
>
>        IF (CheckActivity(previous, ROWS, COLS) .EQ.  .TRUE.) THEN
>          uncontrol = uncontrol + 1
>        ENDIF
>
>My compiler says that I have mixed types when I use .TRUE. .

You need to declare the return type of checkactivity in the routine 
that calls it:
	logical checkactivity
Newsgroups: comp.lang.fortran
From: davem@ee.ubc.ca (david michelson)
Subject: Re: a question on ATAN function
Organization: University of BC, Electrical Engineering
Date: Tue, 24 Nov 1992 03:40:02 GMT

In article <By6v1E.LsB@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
>In article <dedmunds.722548228@sfu.ca>, dedmunds@selkirk.sfu.ca (Darran Edmundson) writes:
>|>I'd like to pose a neophyte question on using the arctan function to
>|>calculate the phase angle of a complex variable (i.e. \theta = atan(v/u)
>|>where u and v are the real and complex parts of my imaginary number
>|>respectively). 
>
>atan2, which takes u and v as two separate arguments, is what
>you want!

However, ATAN2(,) is undefined if both arguments are 0.0 so you'll
have to test for that and assign an arbitrary value if it occurs.
 
--
Dave Michelson
davem@ee.ubc.ca


Newsgroups: comp.lang.fortran