HDTenEightyP/NetNews huggingface dataset:
From: dlc@ddsdx2.jhuapl.edu (Dave Collard x7468)
Subject: Re: pragma INTERFACE to MTH$RANDOM in DEC ADA?
Organization: Johns Hopkins University
Distribution: usa
Date: Wed, 2 Sep 92 12:29:28 GMT

In <ELLIOTTM.92Sep2032817@beach.csulb.edu> elliottm@beach.csulb.edu (Mike Elliott) writes:

>I've gotten stuck trying to interface to the VMS math library routine
>MTH$RANDOM, which takes the address of an integer seed as its argument, and
>returns a FLOAT.  Ada rightly complains if I declare my routine as a function
>taking an in out INTEGER parameter, but my other attempts to trick DEC ADA into
>iterfacing to this routine have also failed.  They include

>   1) declaring the function to take a parameter of type access INTEGER, which
>      points to an actual intger which can be changed (the INTEGER pointed to
>      remains immutable),

>   2) declaring the function to take a parameter of type SYSTEM'ADDRESS, and
>      passing it the address of some integer (the INTEGER at said address
>      remains stubbornly unchanged).

>I'm sure there's some way to do this, but my only two DEC ADA manuals shed no
>light on how.  They do illustrate how to interface to routines like MTH$SQRT,
>which rightly take a parameter of type in FLOAT, and these attempts have been
>successful. 
>-- 

--    MTH$RANDOM
--    
--    Random-Number Generator, Uniformly Distributed
--    
--    The Random-Number Generator, Uniformly Distributed
--    routine is a general random-number generator. 
--    
 
    procedure RANDOM (
	RESULT		: out FLOAT;					-- return value
	SEED		: in out UNSIGNED_LONGWORD);
 
    pragma INTERFACE (EXTERNAL, RANDOM);
 
    pragma IMPORT_VALUED_PROCEDURE (RANDOM, "mth$random",
	(FLOAT, UNSIGNED_LONGWORD),
	(VALUE, REFERENCE));

this is the interface supplied by DEC.  What version of Ada are you using?
They supply an interface to everything in the math lib, just 

with MTH;

look in ADA$PREDEFINED:MTH_.ADC for the spec.  If you don't have this
then you are working with a pretty old version of DEC Ada. If you can't 
find this, then email me.


--Thor
collard@capsrv.jhuapl.edu
dlc@ddsdx2.jhuapl.edu
Newsgroups: comp.lang.ada
From: vera@fanaraaken.Stanford.EDU (James S. Vera)
Subject: Re: Need new idea to get around sunada 1.0 [Verdix] error
Organization: Program Analysis and Verification Group, Stanford University
Date: 27 Aug 92 07:07:05 GMT

tap@src.honeywell.com (Thomas A Peterson) writes:

>I am using ayacc to develop a parser and have ran into a problem with
>the Sun Ada 1.0 compiler returning an internal assertion error.

>socrates: ada -O0 parser.a
>internal: assertion error at file lreg.c, line 174
>cg_ret: 1
>socrates:

>Parser.a contains a large case statement that is apparently larger
>than what the compiler can handle. I have talked to a Verdix employee
>about the problem and he told me to break up the case statement into
>smaller case statements but this has not helped.

Ack!  The old Verdix bug.  Our group first complained about that bug
half a DECADE ago.  Bug progress has been made.  Instead of barfing up
with an assertion error, Verdix is instead (in some future, unnammed
release) going to issue a standard error message.  Big improvement.

The problem is not the case statement, per se.  Instead the problem is
that Verdix has a hard limit on the number of expressions which can
occur in a subprogram.  The limit is something like 20,000
expressions.

To get around this bug, you need to break the offending subprogram
into multiple subprograms.  This, of course, is a pain in the but when
the subprogram is generated automagicly but gee, you don't expect your
Ada compiler to compile valid Ada code, do you?

I've pointed out this Verdix debility to the AYACC folk and they said
they'll look into it.  I'd put money on it that the AYACC folk code
around Veridex's bug before Veridex fixes it.

James S. Vera      |         Internet           |Standard Disclaimers
Stanford University|   vera@anna.stanford.edu   |Blah Blah Blah Blah
+1.415.723.1089    |    FAX +1.415.725.7398     |
From: gjp@sei.cmu.edu (George Pandelios)
Subject: 2nd Call for Papers:  SEI Conference on Software Risk
Keywords: Software Technical Risk
Organization: The Software Engineering Institute
Date: Tue, 1 Sep 1992 15:06:19 GMT





			       CALL FOR PARTICIPATION		

				2nd SEI Conference on
			            Software Risk

			Considerations for Managers & Practitioners


The Second SEI Conference on Issues in Software Risk will be held in
Pittsburgh in March 2-4 of 1993.  The conference brings together software
managers, practitioners, and educators to discuss software technical risk.  
The conference will include plenary sessions, formal invited and contributed
presentations, panel discussions, and informal birds-of-a-feather
meetings.  Vendor exhibits will also be offered.

What is Software Technical Risk?
==============================================

This conference concerns itself with technical risks that threaten successful
software product development.  It is not concerned with the most prevalent
symptoms, cost and schedule overruns, but attempts to deal with underlying
causes and mitigation strategies.  Similarly, the conference does not focus
on safety risks when using systems containing software.  

Participant Information
=======================

Individuals or teams interested in making a 45 minute presentation (including
questions and discussions) must submit a 2000 or 3000 word abstract and a 
brief biography to the general chair, George Pandelios.  Preference will be
given to submissions that demonstrate results of the application of risk
management in software development projects.


Submission Deadlines
====================

Extended abstracts are due no later than October 31, 1992.  Accepted
presenters will be notified by November 13, 1992.

Send abstracts to:

George Pandelios
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA  15213-3890
Phone:  (412) 268-7186
Fax:  (412) 268-5758
Internet:  gjp@sei.cmu.edu
From: shirish@mozart.colostate.edu (seetharam shirish)
Newsgroups: comp.lang.ada
Subject: Problems with the Ada grammar from primost.cs.wisc.edu
Keywords: acvc, lexer and parser
Date: 31 Aug 92 17:42:35 GMT
Organization: Colorado State University

Hi Everyone,
        I compiled the Ada grammar that I ftp'ed from primost.cs.wisc.edu
        and ran the "atests" from the compiler validation suite. To my
        surprise, I found that some of the test cases failed. Specifically,
        identifiers declarations with names "PACK" and "RE" seemed to
        be causing the errors. Any suggestions/comments?
        Please Email to the address below.
        Thanks in advance,
        shirish



-- 
/////////////////////////////////////////////////////////////////////////
/	shirish seetharam		|				/
/	Colorado State Univ.		|				/
/	shirish@mozart.cs.colostate.edu	|				/
/////////////////////////////////////////////////////////////////////////
From: byrley@NTSC-RD.NAVY.MIL ("Paul Byrley")
Newsgroups: comp.lang.ada
Subject: Play 20K expressions again, Sam
Date: 28 Aug 92 16:29:00 GMT
Organization: The Internet

I was willing to be prejudiced again against "those academics" when
I first read about the supposed bug in a compiler that balked at 20k
expressions.  After reading Sam Harbaugh's good natured
commentary, I rethought my position and decided to just comment.

About 1985, I asked the net at SIMTEL20 what to do about
contractually limiting the size of Ada packages. We had been using
FORTRAN and MIL-STD-1679 or 1644 where the limit was 200 LOC
for a sub-program (1679 and 1644 predated Ada by 5 to 10 years). 
 I thought 200 LOC was excessive for good life cycle support
(assuming 50% comments and 64 lines per line printer page you got
6 pages of code plus a page or two of declaratives).  We had just
started talking about the Hrair limit then, thanks to Grady Booch (and,
I think, some rabbit in Watership Downs) and six pages of listings was
too much for my brain to encompass.  I felt sure, however, that the
200 LOC limit we used for FORTRAN subroutines wouldn't translate
into a valid Ada limit.  Anyhow, when I asked the net, I got back
about eight comments, all saying "no LOC limits for Ada packages". 
I believe that Grady Booch and Ed Berard were among the
commenters and that was support enough for me.  

Since then, our agency has used the no LOC limit approach on
probably 50 procurements for real time training systems, ranging in
size from 5000 LOC to 800K LOC of Ada.  I think only one vendor
has violated what, as near as I can tell, is industry agreement on good
practice on package size.  Most packages seem to be from 100 to
500 LOC, and almost never over 1000 LOC.  The one "violator of
good practice" insisted on delivering a 10K LOC package.  It worked,
but is going to be more expensive for all us taxpayers to support for
the next 10 to 15 years.  

My opinion is that if a person is hanging together large amounts of
code and will support it himself forever (promises not to quit or die
before his employer ceases to need the software), then 20K
expressions is ok. (Does one expression = one LOC or are we talking
one expression = LOC/4 to LOC/8?)  If a taxpayer (even a federal
research grant comes from taxpayers) is going to have to pay extra for
the indulgence of a 20K expression programmer, then I thank Verdix
for their choice. Actually I wish it were lower.  I remember, years ago,
learning that the reason my latest FORTRAN "gem" was not compiling
was that I had overrun the compiler tables- that program was about
1000 LOC and I was briefly indignant also.  Yeah Sam, that was half
a box of cards, red ones and blue ones and even green ones, with a
diagonal magic marker across the top so you could maybe recover
when someone dropped them.

Regards to all, even the long package advocates.

Paul Byrley
From: adams@pooh.sdd.trw.com (allen Adams)
Newsgroups: comp.lang.ada
Subject: FAQ: Ada ftp sites
Summary: Where are there Ada ftp sites
Keywords: Ada
Date: 27 Aug 92 16:01:32 GMT
Distribution: usa
Organization: TRW Inc., Redondo Beach, CA

Could some one point me in the direction of where there are Ada reusable 
software available through ftp sites.

Thanks in advance,

Allen Adams
Newsgroups: comp.lang.ada
From: allison@convex.com (Brian Allison)
Subject: Re: Looking for Parallel Ada Compilers
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Thu, 03 Sep 1992 14:52:48 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1992Sep2.131144.36039@uservx.plk.af.mil> zetocha@uservx.plk.af.mil writes:
>
>    I am working on developing a parallelized R&D environment for 
>parallel processing computers, and I'm trying to determine what 
>parallelizing Ada compilers are on the market.

The Convex Ada compiler supports automatic loop-level as well as Ada task-
level parallelism on all Convex platforms, and has done so since 1988.  Convex
platforms currently support up to 8 CPU's each.

-- 
Brian Allison			"If pro and con are opposites, is
CONVEX Computer Corp.		 Congress the opposite of progress?"
Richardson, TX					- Richard Lederer
Newsgroups: comp.lang.ada
From: ae@sei.cmu.edu (Arthur Evans)
Subject: translate Ada to C
Fcc: inbox
Organization: Software Engineering Institute
Date: Mon, 31 Aug 1992 21:46:06 GMT

A client with some algorithms expressed in Ada wants to translate them
to C.  Has anyone information about any automation that will help in
this process?  COTS solutions are preferred; anything is of interest.

Reply to me; I'll summarize to the net.

COTS = Commercial Off-The-Shelf.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu
Newsgroups: comp.lang.ada
From: kst@telesoft.com (Keith Thompson @pulsar)
Subject: Re: ADA question
Organization: TeleSoft, San Diego, CA, USA
Date: Sun, 30 Aug 1992 08:16:48 GMT

In article <8363@sirius.ucs.adelaide.edu.au> andrewd@cs.adelaide.edu.au (Andrew Dunstan) writes:
> [...]        To avoid the cost of copying, you could try this, although it
> won't necessarily work on all compilers:
> 
>  DECLARE
>     String_Const : CONSTANT String := My_String_Function;
>     String_Var : String (String_Const'RANGE) ;
>     for string_var use at string_const'address ;
>  BEGIN
>     Process (String_Var) ; -- parameter's mode: IN OUT
>  END ;
>  
> Now there is no copying, and no extra storage allocation. It's a bit gross,
> but it should work.

It may work in some implementations, but your program may break in odd
ways when you port it to another compiler, recompile with a new
optimization flag, or try compiling or executing it during the wrong
phase of the moon.  What you're trying to do here is create an overlay
between String_Const and String_Var.  LRM 13.5:8 says

	Address clauses should not be used to achieve overlays of
	objects or overlays of program units.  Nor should a given
	interrupt be linked to more than one entry.  Any program using
	address clauses to achieve such effects is erroneous.

"Erroneous" means that it violates the rules of the language, but an
implementation is not required to detect the violation either at
compilation time or at run time (though I know of at least one
implementation that issues a warning in this case).  The effect of
erroneous execution is unpredictable (LRM 1.6:7).

IMHO, it's not worth it to avoid the minor cost of a string copy.
The hours wasted by your successor ten years from now trying to figure out
why the program stopped working are more important than the microseconds
you'll save in execution time.  Besides, a sufficiently smart optimizing
compiler might eliminate the copy for you anyway (though I don't know
whether any current compilers do so).
-- 
Keith Thompson (The_Other_Keith)  kst@telesoft.com
TeleSoft, 5959 Cornerstone Court West, San Diego, CA, 92121-9891
"Listen to me, people!  We must stick them with quills -- it's the only way!"
From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: MI - clutching at straws
Reply-To: pk@rwthi3.informatik.rwth-aachen.de
Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
Date: Sun, 23 Aug 92 17:13:50 GMT

Some time ago, I started a thread in comp.lang.modula3 about the non/sense
of MI (Modula-3 has SI only). Although most responses were pretty anti-MI,
some examples were supplied for which no satisfying alternatives were given.
Since I am unsure yet whether I find MI neccessary, I try again here.

To begin with, I don't think that *if* MI is useful, this use will be constrained
to certain application areas. Just like SI, genericity and arrays, MI gives the
programmer the opportunity to express a data design decision in a specific
implementation language. So, either it is sensible as such or it is not.

Exactly for this reason I wonder why you exclude academic implementations from
your considerations. A whole lot of good software is written in universities,
for very different application areas. Even more, I believe that the percentage
of people who actually experienced MI is higher in the academic field.

Well, I am convinced that MI is not neccessary for combining orthogonal classes.
This is what records are for. But problems arise if several subclasses of a
common superclass are combined into a MI subclass with the superclass fields
shared.

Consider the following example: I start with an abstract data type for a graph.
Now I augment the basic type in several independant ways, let's say to make
attributed, node- and edge-labeled graphs. Finally, I would like to have
some special graphs, e.g. abstract syntax graphs or binary trees, which
combine one or more of the above extensions. How can I express this without
violating the abstractness of the involved data types? Maybe somebody's got
some clever answer. Otherwise, I will keep thinking that MI is sometimes
appropriate.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany

Newsgroups: comp.lang.ada
From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: ADA Max Array Size HELP!!!! REVISITED
Organization: George Washington University
Date: Wed, 26 Aug 1992 20:56:48 GMT

In article <1992Aug25.121312.1@vmsclst1.sc.csupomona.edu> mgeorgy@vmsclst1.sc.csupomona.edu writes:
>Well the programs kicks after compilation, linking, and running.  It looks like
>its about to go then kicks before the first statment in the program.  I have
>tried this on a VAX and a MAC with approx 20 megs of RAM 2 of which is soely
>dedicated to the programming environment...  Both times it kicks.  This is why
>I think it may be the amount of memory available to the program, because it
>crashs when it seems to be allocating that amount of memory!!!
>
I'd love to conjecture about the cause of your problem, but I really hope
you can give a more precise descroption of the behavior than "the program
kicked." Which compiler? Can you transcribe the message?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------
From: richard@borneo.gmd.de (Richard Czech)
Newsgroups: comp.lang.tcl
Subject: Re: exec output file format (can't say exec foo > stdout)
Date: 27 Aug 92 10:48:16 GMT
Reply-To: richard@borneo.gmd.de
Organization: GMD, German National Research Center for Computer Science

In article <1992Aug26.211548.22311@osf.org>, pnh@pmin24.osf.org (Peter Harbo)
writes:
|> I recently wanted to use the exec command to send the output of a UNIX
|> command
|> directly to standard output rather than returned as a TCL result like so
|> 
|> 	exec date > stdout
|> 
|> using the "stdout" filename.  Unfortunately exec does not work like "puts"
|> which calls TclGetOpenFile() to translate "stdout" to a file descriptor,
|> instead it apparently calls Tcl_CreatePipeline() to open the file following
|> '>' via open(), ergo no translation.

Try this:

	puts stdout [exec date]

----------------------------------------------------------------------
        Richard Czech                        e-mail:      czech@gmd.de
         GMD-I5-FIT
        P.O.Box 13 16                        phone: (+49) 2241 14 2039
D-5205 St. Augustin 1, Germany               fax:   (+49) 2241 14 2342
----------------------------------------------------------------------
Newsgroups: comp.lang.tcl
From: pnh@pmin24.osf.org (Peter Harbo)
Subject: variable argument procedures.
Organization: Open Software Foundation
X-Newsreader: Tin 1.1 PL4
Date: Tue, 1 Sep 1992 21:36:54 GMT

TCL procedures can be defined such that they take a variable number of
arguments when they are defined in C code.

Is there a way to do this when you define a TCL procedure in TCL?  
Without simply making the argument a list?


Newsgroups: comp.lang.tcl
From: bj@zephir.uucp (Beat Jucker)
Subject: TK2.3: Segmentation fault (coredump)...
Organization: JSW-Engineering, CH 3626 Huenibach, Switzerland
Date: Sun, 30 Aug 1992 22:18:38 GMT

I have an application which creates/destroys different windows. With
TK2.1 I never got any coredumps. As soon as I have upgraded to TK2.3
sometimes when a window destroys itself (e.g. a quit-button executes
the command "destroy top-window-name") I get 

	Segmentation fault (coredump)

I traced the core file and found the problem in the module TkWmDeadWindow:

	if (wmPtr->deleteCmd) {
            ckfree((char *) wmPtr->deleteCmd);
        } 

I'm neither a X11 nor a TK guru! I have commented out this three lines
and I didn't got any more coredumps...! The application is now running 
without any problems. Does anyone have an idea? 
(before I forget: it's a RS/6000 AIX 3.1) 

Thanks, Beat

-- 
--------------------------------------------------------------------------
Beat Jucker, JSW-Engineering, Anlikerweg 5, CH-3626 Huenibach, Switzerland
   Tel:(+41)33 434868  UUCP:uunet!chsun!zephir!bj  Email:bj@zephir.uucp
From: rayaprol@kasi.pilgrim.umass.edu (Venu S. Rayaprolu)
Newsgroups: comp.lang.tcl
Subject: Re: Compiling tcl 6.3 with gcc 2.2.2
Date: 28 Aug 92 18:00:28 GMT
Reply-To: rayaprol@kasi.pilgrim.umass.edu
Followup-To: comp.lang.tcl
Organization: University of Massachusetts at Amherst

In article <WARSAW.92Aug28105321@anthem.nlm.nih.gov>, warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
|> 
|> I had to make a minor change to tclUnix.h from 6.3 to get tcl to
|> compile properly under gcc 2.2.2 on a SS2, SunOS 4.1.1.  Without the
|> patch, gcc complains:
|> 
|> gcc -fno-builtin -g -I. -DTCL_LIBRARY=\"/vol/newirx/lib/tcl\"  -target sun4 -c  tclExpr.c
|> In file included from tclExpr.c:33:
|> tclUnix.h:302: conflicting types for `open'
|> tclUnix.h:302: A parameter list with an ellipsis can't match
|> tclUnix.h:302: an empty parameter name list declaration.
|> /usr/include/sys/fcntlcom.h:149: previous declaration of `open'
|> *** Error code 1
|> make: Fatal error: Command failed for target `tclExpr.o'
|> 
	DECStation 5000/200, Ultrix 4.2A, gcc-2.2.2.

	similar error occurred in tkConfig.h where 'open' was declared
	with an ellipsis in tk2.3 distribution.
|> 
|> tclTest seemed to approve.
|> 
|> -Barry

Venu
--
You want religion. I got religion.
	-- Larry Wall in article <1992Aug27.180029.19638@netlabs.com>
	titled (Re: coding style (was Re: Perl language formatting conventions?))
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: comp.lang.tcl
Subject: Re: #!wish -f doesn't work
Date: 3 Sep 92 14:01:33 GMT
Organization: University of Michigan, CITI

In article <1992Aug31.170411.26036@sierra.com> jpalmer@sierra.com (Jeb Palmer) writes:
>I recently made the move to Tk, but I have a problem.  The "#!wish -f"
>syntax to invoke wish as interpreter in my tcl scripts doesn't work.
>Here is what I know-
>
>1. "#!wish -f" returns <scriptname>:Command not found

The #! construct is interpreted by the kernel, not the shell, so it
doesn't know about your PATH.

>2. "#!<full pathname to wish> -f returns:Permission denied

For very historical reasons (that is, somebody made a wrong decision
years ago and bow we;re stick :-) ) the string is limited to 32 bytes.



(Sarr Blumson)
Newsgroups: comp.lang.tcl
From: welch@parc.xerox.com (Brent Welch)
Subject: Re: Request: Anybody have a tk-based "Tcl Listener" implemented?
Organization: Xerox PARC
Distribution: comp
Date: 29 Aug 92 23:51:09 GMT

The mxedit editor uses an entry widget as a TCL command interpreter.
Here is the main procedure that passes the contents of the
entry widget the Tcl_Eval:


# mxDoCmd --
#	Execute the commands issued to the command entry
#	This is ordinarily bound to hitting <Return> in the command entry

proc mxDoCmd { } {
    # focus is a flag that indicates which other widget should get
    # focus after the command is executed
    global focus
    # command is a frame widget holding a label and an entry
    global command

    set cmd [$command.entry get]
    if {[llength $cmd] != 0} {
	case [lindex $cmd 0] in {
	    {echo feedback mxFeedback} {
		# Echo inputs
		mxFeedback "$cmd"
	    } help {
		# Display help information
		mxopen [info library]/mxedit.tutorial
	    } default {
		# Pass on the command to Tcl
		if [catch {uplevel #0 $cmd} msg] {
		    mxFeedback "Cmd failed: $msg"
		} else {
		    # This displays the result in another entry widget
		    if {[string compare "$msg" ""] != 0} {
			mxFeedback $msg
		    } else {
			mxFeedback "ok"
		    }
		}
	    }
	}
    }
    # Let a command do its own focus if it wants,
    # otherwise return the focus to the editting window
    if {[string compare $focus "default"] == 0} {
	mxeditFocus
    }
    set focus default
}


--

	Brent Welch
Newsgroups: comp.lang.tcl