HDTenEightyP/NetNews huggingface dataset:
From: gardner_c@apollo.hp.com (Cal Gardner)
Subject: Re: Double length integer arithmetic
Date: Wed, 16 Dec 1992 07:22:49 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1992Dec13.015133.18469@afterlife.ncsc.mil> dpmccul@afterlife.ncsc.mil (Dean McCullough) writes:
>>The IBM 704-709 series, which were the machines for which Fortran was written;
>
>That is a strange statement, since I used Fortran on both the IBM 650
>and the IBM 1620.  Both of these machines predated the IBM 704.

No way, Jose!!  The 1620 comes well after the 704. No Fortran on the
                old 650.  The 650 had its own Fortransit - Fortran
                like but not Fortran.  BTW - the 1620 did all of its
                arithmetic via table-lookup.  The multiplication and
                addition tables had to be loaded into the machine.
                Memory to memory operations and the mode was decimal.

Cal gardner_c@apollo.hp.com
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.misc
Subject: Re: who should specify languages?
Date: 12 Dec 1992 00:15:01 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

jlg@cochiti.lanl.gov (J. Giles) writes:
: A few *simple* languages would be a much better programming environment 
: than one complicated language.  And, programming should consist of writing
: the algorithms and data structures appropriate to the problem at hand,
: and then picking whichever language(s) are available and most appropriate
: for the chosen structures.

Yes.  Now, here's a complaint dressed as a question.  

Why do language designers never consider the interface to another language
worthy of the slightest standardization?  

The implementation will of course be dependent on specific languages and
compilers, but still there is enough commonality between langauges to allow
a basic level of interaction.

It's as if they consider the language to live in a pure world of its own,
uncontaminated by influences from the real world.

For example.  Why doesn't the ANSI C committees define "official" interfaces
to FORTRAN (and Fortran) and vice versa?  Neither is about to disappear next
week.  For other less common languages, this is even MORE important as
you're likely to find library components and other necessary tools in
languages other than your primary one.

: -- 
: J. Giles

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.lang.misc,comp.arch
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Double length integer arithmetic
Organization: Purdue University Statistics Department
Date: Sat, 12 Dec 1992 13:01:40 GMT

In article <8311@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <Bz1rFw.9s1@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> >                                                     The hardware has
> > deteriorated, except for speed, for the number theorist; when Lehmer
> > wrote his criticism, virtually all computers had double-length integer
> > arithmetic.
>You asserted that before, and I asked you to name a few computers from the
>beginning of Fortran that had those capabilities.  I never saw a response.
>Can you respond now?

The IBM 704-709 series, which were the machines for which Fortran was written;
The Univac 1100 series; the CDC 1604 and 3600; and at least the great bulk of
the von Neumann type machines.  I am  not too familiar with the some of the
earlier machines, but the more-or-less standard hardware of that time had an
accumulator and a multiplier/quotient register; the actual additions were
done in the accumulator, and on multiplication the least significant part
was shifted into the MQ register, with the most significant part in the
accumulator, and on division, with the double-length dividend in the A/MQ
registers, the remainder was left in the accumulator as the quotient was
produced in the MQ register.	
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.lang.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: who should specify languages?
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 18 Dec 1992 15:15:00 GMT

paj@uk.co.gec-mrc (Paul Johnson) writes:

>In article <1gbau5INN53d@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>
>>Why do language designers never consider the interface to another language
>>worthy of the slightest standardization?  
>
>Eiffel has a standard interface defined through the "external"
>keyword.  The interface between objects and C is well defined in
>"Eiffel: The Language".

Ada and C++ also have standard interfaces to foreign languages.

>Not all language designers are dumb.

Indeed.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.misc
From: wbg@festival.ed.ac.uk (W Geake)
Newsgroups: comp.lang.misc
Subject: Accurate Timing in Visual Basic
Summary: Anyone know how to get accurately timed events in VB?
Keywords: Visual Basic, Timing
Date: 15 Dec 92 14:47:30 GMT

In order to run an analogue to digital convertor module from a serial
port, I want to send a byte from the port every 10 ms.  This sets the
sampling rate, so the accuracy of the interval is very important.  The
VB Programmer's Guide mentions BUILT IN POTENTIAL FOR ERROR in timer controls, a great
euphemism if ever I heard one.  Can I get good precision from VB, or do
I need to work in C (please not!) or C++(worse still) or write a VxD
(I'd rather sell life insurance)?

All ideas gratefully received: unlimited fame more or less guaranteed
for useful ones.  Thanks in advance, O Wise Ones.

Bill Geake, University of Edinburgh, Scotland.
Internet:  wbg@ee.ed.ac.uk  or W.Geake@festival.ed.ac.uk
Newsgroups: comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Accurate Timing in Visual Basic
Keywords: Visual Basic, Timing
Organization: Xenix Support, FICC
Date: Wed, 16 Dec 1992 23:56:34 GMT

In article <29569@castle.ed.ac.uk> wbg@festival.ed.ac.uk (W Geake) writes:
> In order to run an analogue to digital convertor module from a serial
> port, I want to send a byte from the port every 10 ms.  This sets the
> sampling rate, so the accuracy of the interval is very important.

If you want to do something every 10 ms, on an IBM clone, you have to:

	1. Write a device driver to do the work on a timer interrupt.
	2. Deal with the standard timer interrupt, which runs at 18.2 Hz.
	   a. Make it run faster and then emulate the standard speed
	      for the rest of the system
	   b. Install a secondary clock for the device driver.
	   c. Use a video card that lets you work off the vertical
	      blank interrupt and runs at 100 frames per second.

Needless to say, you can't do this in Visual Basic, and doing it in
C or C++ is going to require a lot of effort coercing the compiler
to do the interrupt routine. I think you've got some assembler ahead
of you.

> (I'd rather sell life insurance)?

I used to sell encyclopedias door to door, when I was at school. Is
that anything like it?
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Safety. Was: Re: Pointers
Organization: Purdue University Statistics Department
Date: Wed, 16 Dec 1992 17:39:40 GMT

In article <1992Dec16.164821.19079@walter.bellcore.com> dnew@thumper.bellcore.com (Darren New) writes:

			.................

>> 	use_double(c,d)

>> where, for example, c and d would be 32-bit objects and double is 64-bit.

>This is a trivial modification, using a union with two 32-bit objects
>overlapping one 64-bit object.

>However, C cannot choose different functions based on that their value
>is returned as.  What should it do if you say

>process(use_double(c,d))

>and you haven't declared what types "process" uses returns.  It's a tiny
>amount of work to use different functions depending on what you want to
>pass and what you want back, compared to actually getting it to work.

My idea about "use" is much simpler.  The expression use_double(...), as
I intend it, means that the bit pattern, or concatenated bit pattern, 
described in the parentheses is to be now used as a double number in
any application.  Therefore, in   process(use_double(...)), process just
assumes that what is presented to it is a double, just as the cast to
double declares that the result is double.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.lang.icon
From: konhks@eua.ericsson.se (Hakan Soderstrom)
Subject: Re:  Bus Error
Reply-To: konhks@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Fri, 18 Dec 1992 08:49:21 GMT

Thanks to Bill Griswold for mentioning some of the mechanisms that may
cause a bus error.

My problem occurs in a program segment where coexpressions are used
heavily.  (I don't have the Icon program library at hand, but it is the
procedures, by Ralph Griswold I seem to remember, that convert any data
structure to a string, and back again.) The problem appears when the
volume and 'knottiness' of the data structure increases, so I'd rather
not post a sample. In addition, I have a vague impression that in a
previous experiment some other memory related environment variable
made the bus error go away.

I have become accustomed to Icon as extremely reliable. Still, it is
known that stack overflow can go undetected.  So I tend to believe that
in this case heavily recursive use of coexpressions cause the stack to
grow into some other memory region.  This is the kind of situation
where there is no a priori upper bound on neither the number of active
coexpressions nor the depth of recursion.

I will re-implement this (small) part of the application.

-- Finally, a re-statement of the problem for those who wonder (and for
Richard Goerwitz :-)

I have an Icon program which I run under SunOS 4.1.1 on SPARC 1+
hardware. I run Icon 8.7 created by gcc 2.1 with -O turned on.  This
program has been known to terminate with bus error for some input
data.  It behaved the same under Icon 8.6 as under 8.7.

The problem went away when I increased STRSIZE. So my question was, is
it a known problem that too small a STRSIZE may go undetected and cause
a bus error under Unix?

------------------------------------------
Hakan Soderstrom (contractor)

Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: Iconc problem
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Wed, 16 Dec 1992 05:42:11 GMT

omalley@ics.uci.edu writes:
>  I have a fairly large icon program that is showing some strange
>behavior. The program always works under the interpreter, but it
>doesn't under the compiler.

About half the time I use the compiler, programs bomb.  It's a neat
system, but it's just not maintained the way the interpreter is, and
it's still somewhat experimental.  The interpreter is really our
mainstay (sorta like for LISP and PROLOG programmers).

Try compiling your program with various Icon optimizations turned
off.  Check the iconc man page on how to do this.  When you figure
out what causes the problem, mail in a bug report to the Icon Pro-
ject (the usual - a test program that shows where the misbehavior
occurs, and a list of your platform and Icon implementation fea-
tures, along with a brief list of what you did when you built Icon
[i.e. did you use the standard configs, a prepacked binary, etc.?]).

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
Newsgroups: comp.lang.icon
Date: 15 Dec 92 10:44:24 GMT
From: R J Hare <ercn72@festival.ed.ac.uk>
Subject: Problem with XIcon syntax.


I have a minor problem with XIcon syntax - can anyone help?

I wish to execute a loop, the culmination of which is the drawing of a single
point in the XWindow. I wish to be able to terminate execution of the loop and
move to the next phase of the program at any point (ie: with the picture
incomplete) by pressing a button on my mouse. I reackon the code should look
something like this:

procedure main()
  .
every i:=1 to n
do {if XEvent(window)==&lpress then break # force a break if lb is pressed
      .
    loop code culminating in
    XDrawPoint(window,x,y)}}
  .
remainder of code
  .
end

This seems to get in some sort of hung-up situation - I see no points being
drawn in my window and pressing the left mouse button doesn't seem to exit
from the loop either.

The following code works, but doesn't seem so intuitive:

every i:=1 to n
do {if (events:=XPending(window) & *events > 0)      # force a
    then if XEvents(window)==&lpress                 # break if left
    then break                                       # button pressed
      .
    loop code culminating in
    XDrawPoint(window,x,y)}}
  .
remainder of code
  .
end

Should the first form of the code work, or what?

Thanks.

Roger Hare.

Newsgroups: comp.lang.icon
Date: 17 Dec 92 10:36:21 GMT
From: R J Hare <ercn72@festival.ed.ac.uk>
Subject: Bus Error

I have just encountered the bus error reported here yesterday, for the first
time. I have increased my STRSIZE to 100000, but he error still occurs. I
would like to ask what size the original poster increased STRSIZE to?

Apologies for posting this question here, but someones mailer somewhere is
mangling my reply when I try to reply direct to the original poster.

Thanks.

Roger Hare.

Newsgroups: comp.lang.icon
Date: Thu, 17 Dec 92 09:30:10 -0800
From: wgg@cs.UCSD.EDU (William Griswold)
Subject: Re:  Bus Error

You never know if you've hit "the" bus error.  There are probably several
latent bugs that could cause a bus error.  Increasing the STRSIZE may not
help you.  A potential cause of a bus error is exhausting the stack (too
many recursive calls), which can overflow into another memory region.
You might try increasing your default stack size (I believe there is one
default for &main, and another for all other coexpressions; if you are
using coexpressions heavily, consider increasing the default stack size
for coexpressions).

					Bill Griswold

Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: Bus error termination
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Tue, 15 Dec 1992 17:52:10 GMT

konhks@eua.ericsson.se writes:

>A month ago or so I reported that an Icon program terminated with bus error.
>I was then advised of the existence of version 8.7 of Icon and promptly
>installed it. The problem did not go away.

I don't remember exactly what you said in your previous message, but generally
it's easier for the rest of us to help if you list your platform, compiler,
optimization level, and the features you enabled when you created Icon.  In
addition a small sample program to illustrate the problem would be useful.
Does the bus error happen any time Icon is fired up?  Did you try compiling
Icon with optimizations turned off?

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
From: omalley@porte-de-st-ouen.ICS.UCI.EDU (Owen O'Malley)
Subject: Iconc problem
Newsgroups: comp.lang.icon
Reply-To: omalley@ics.uci.edu
Date: 15 Dec 92 18:17:59 GMT

  I have a fairly large icon program that is showing some strange
behavior. The program always works under the interpreter, but it
doesn't under the compiler. In particular, in most test cases execute
correctly (even under the compiler) but on some large testcases a few
of the strings get corrupted. More specifically, the output files have
a few lines of \0's (ie. the nul character) which most of the system
utilities die on. It looks to me like a memory corruption problem. Are
static areas used by the compiler that might be running out of room? I
would appreciate any help, since the large test cases are exactly when
I would like to use the compiled version.

  Thanks,
    Owen O'Malley

Department of ICS  | omalley@ics.uci.edu             (ARPA)
UC Irvine          | {ucbvax|sdcsvax}!ucivax!omalley (UUCP)
Irvine, CA 92717   | oomalley@uci                    (BITNET)

Newsgroups: comp.lang.icon
From: konhks@eua.ericsson.se (Hakan Soderstrom)
Subject: Bus error termination
Reply-To: konhks@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Tue, 15 Dec 1992 11:06:51 GMT

A month ago or so I reported that an Icon program terminated with bus error.
I was then advised of the existence of version 8.7 of Icon and promptly
installed it. The problem did not go away.

I found, however, that the problem vanished if I made STRSIZE large enough.
Is this a known problem: that a too small STRSIZE can go undetected and
cause a bus error?

---
------------------------------------------
Hakan Soderstrom (contractor)
From: langalf@cup.portal.com (Larry A Schrupp)
Newsgroups: comp.lang.icon,
Subject: Wanted:  SNOBOL4 SIL macros for 68000 processor
Date: Sun, 13 Dec 92 23:46:26 PST
Organization: The Portal System (TM)
Distribution: usa

I wish to implement SNOBOL4 on two 68000 based computers (An Amiga 2000, and
a VMEbus 68040 running UniFLEX).

I have Version 3.11 source for the SIL (Macro Implementation of SNOBOL4),
as well as the IBM 360 version of the macros and system subroutines.  Does
anyone have a 68000 implementation of the macros and subroutines (for any
system) they would be willing to share?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Larry A. Schrupp            langalf@cup.portal.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Fri, 18 Dec 1992 01:47:29 EST
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Spelt logical operators
Comments: To: REXXLIST@uga.cc.uga.edu
              Dec 18, 92 1:24 am

In this line, I might add that even words can have different meanings.
The word "mod" doesn't have the same mathematical meaning in
different languages (human ones, I mean)...

So rather than see many versions of REXX, I'd rather see few of
them, and *doggone* well thought-through!  Let's not make the
mistake of speed being more important than quality...  :-)

Regards.
$$/
From: imc@comlab.ox.ac.uk (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: Introduction to REXX
Keywords: rexx help
Date: 13 Dec 92 13:46:36 GMT
Distribution: comp.lang.rexx
Organization: Oxford University Computing Laboratory
X-Local-Date: Sunday, 13th December 1992 at 1:46pm GMT
Originator: imc@msc7.comlab

In article <4306@novavax.UUCP>, rydenb@novavax.UUCP (Beth A. Ryden) wrote:
>Can someone recommend some hardcopy text or even
>ftpsite where I can get some documentation to REXX?
>            I have REXX (Regina) on this machine, and
>I would like to learn to use it.

By the time I get to type this reply, a thousand people have probably
already suggested "The REXX Language - a practical approach to programming"
by M. F. Cowlishaw (Englewood Cliffs 1985).

I might also mention that REXX/imc comes with a complete online reference
and semi-tutorial (available from rexx.uwaterloo.ca).

imc

Ian Collier
Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 18 Dec 1992 11:08:38 PST
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: REXX under MS-DOS
              18 Dec 1992 10:55:58 GMT from <CHBRIN5@NYX.UNI-KONSTANZ.DE>

REXX under DOS:


Personal REXX for DOS is available from Quercus Systems, Box 2157,
Saratoga CA 95070 for $125 or so.


Personal REXX also runs under OS/2 (for complete compatibility).  There
is also a WinREXX from the same vendor.   Dave

Dave Gomberg    GOMBERG@UCSFVM  Internet node UCSFVM.UCSF.EDU     fax-> 7797
Seven Gateview Court, San Francisco CA 94116-1941      voice-> (415)731-7793
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: comp.lang.rexx
Date:         Thu, 17 Dec 1992 12:33:09 PRT
From:         "Carlos A. C. Sousa" <MCARLOSS@PTEARN.BITNET>

Hello thanks to Guenter for your answer to my question
maybe my mail to rexxlist it wasn't so clear
but what i pretending wasn't really that...
what i pretend is:
to do a pull to read the imput from the keyboard
and i don't want that imput appears on the screen.
can you help me?
thanks.

p.s. I tryed to write directly to you but the mails were
delivery back to me.
Keep in touch, sincerely,


   ______                                ______
  /    ___    ___    /   ___   ___      /   ___        ___    ___
 /    /  /   /__/   /   /  /  /__       \  /  /  /  / /__    /  /
(___ (__(_  (   \  (__ (__/   __/     ___/(__/  (__/  __/   (__(_

Bitnet Address       : MCARLOSS@PTEARN
Internet Address     : MCARLOSS@PTEARN.FC.UL.PT
Vax Internet address : MCARLOSS@FCVAX1.FC.UL.PT

Math Student at Classical University of Lisbon
Science College