HDTenEightyP/NetNews huggingface dataset:
From: brucej@verdix.com (Bruce Jones)
Newsgroups: comp.lang.ada
Subject: Re: Play 20K expressions again, Sam
Date: 8 Sep 92 22:02:32 GMT
Article-I.D.: verdix.9194
Reply-To: brucej@verdix.com (Bruce Jones)
Organization: Verdix Western Operations; Aloha, OR

In article <dnsurber.715958256@node_26400> dnsurber@lescsse.jsc.nasa.gov (Douglas N. Surber) writes:
>Actually no.  The Verdix compiler is written in C, not that silly Ada thing. :).

Well, our new optimizer is written in Ada.  It turns out that Ada is a
great language for writing large programs, the new code is very readable
and maintainable.

Boy were we surprised!  :)

	-- brucej
Newsgroups: comp.lang.ada
From: obry@flash.bellcore.com (Pascal Obry)
Subject: Meridian Ada compiler
Organization: /u/obry/.organization
Distribution: comp.lang.ada
Date: 11 Sep 92 11:01:19



Hello,

I would like to know a good contact to get an Meridian Ada compiler
for PC in France. In others words, what is the distributor for Meridian in
this country.

Any informations will be appreciate.

Thanks,
Pascal.
--

-------------------------------------------------------------------------------
--  Pascal OBRY								     --
--  Room 2D-337				e_mail : obry@bellcore.com  	     --
--  Bellcore								     --
--  445 South Street			voice : 1 - 201 829 4039	     --
--  Post Office Box 1910						     --
--  Morristown, New Jersey 07962-1910					     --
-------------------------------------------------------------------------------

  `` inheritance is surely a good answer, but who knows the question ? ''

Newsgroups: comp.lang.ada
From: dnsurber@lescsse.jsc.nasa.gov (Douglas N. Surber)
Subject: Re: Play 20K expressions again, Sam
Organization: Lockheed Engineering and Sciences
Date:  8 Sep 92 13:17:36 GMT

In <199209080707.AA06873@cnam.cnam.fr> bortz@CNAM.CNAM.FR writes:

>In article <9192@verdix.verdix.com>, brucej@verdix.com (Bruce Jones) writes:
>... 
>> This is to announce to our patient customers that the "damn Verdix bug"
>> has been fixed.  The limit of "20K expressions" (actually "22000 `logical
>> registers') has been changed to a limit of 0x40000000.  A nice round number,
>                                             ^^^^^^^^^^
>                                             You mean 16#40000000# ?

Actually no.  The Verdix compiler is written in C, not that silly Ada thing. :).

Douglas Surber
Lockheed
Houston, TX
From: beidler@guinness.cs.uofs.edu (Jack Beidler)
Newsgroups: comp.lang.ada
Subject: Re: Generics?
Date: 14 Sep 92 15:00:11 GMT
Organization: Department of Computing Sciences

In article <tp923021.715953043@jarrah>, tp923021@jarrah.canberra.edu.au (Ben Elliston) writes:
|> Thanks to those regarding my problem with the case statement .. all
|> fixed now .. and much appreciated!
|> 
|> I've since moved onto making an array a generic type (such as this):
|> 
|> GENERIC
|> Type Index IS (<>);
|> 
|> [..]
|> 
|> Type Stack_Array IS Array(Index) of Character;
|> 
|> Type Stack_Type IS RECORD
|>   Data_Store: Stack_Array;
|>   Pointer: Natural;
|> END RECORD;
|> 

Something still  seems to be missing -- given the two other follow
ups to this article, I guess that I'm not the only one.  Let me add
my two cents.  My package spec. for this package is:

generic

   type Object_Type is private ; -- only one generic instantiation parm.

package Stack_Pt_Pt is

   Type Stack_Type (Max_Size : positive := 32) is private ;

     . . .
   -- Push, Pop, and other specs. here

private

   type Stack_Array_Type is array (positive range <>) of Object_Type ;

   type Stack_Type (Max_Size : positive := 32) is
      record
	 Top    : natural := 0 ;
	 Actual : Stack_Array_Type (1 .. Max_Size) ;
      end record ;

end Stack_Pt_Pt ;

By having Stack_Type declared with a discriminant, the client has
control over determining the max. size of each stack.

My convention for component package names is:

     Component_Xxx_Yyy

where "Component" is the component supportted by the package, 
"Xxx" is "Pt" or "Lpt" to indicate the type of instantiation 
parameter being supportted, and "Yyy" is either "Pt", "Lpt", 
or "En" to indicate the component visibility as either private,
limited private, or totally encapsulated (One copy) by the package.
-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+
From: michael.hagerty@nitelog.net.netcom.com (Michael Hagerty) 
Newsgroups: comp.lang.ada
Subject: Ada's (in)visibility in the engineering community
Date: 13 Sep 92 16:45:00 GMT
Distribution: world
Organization: Nitelog BBS - Monterey, CA - 408-655-1096
Reply-To: michael.hagerty@nitelog.net.netcom.com (Michael Hagerty) 



Michael Feldman writes:

MF. To me, this is yet another indicator of the Ada community's utter failure
MF. to foster Ada's penetration into fields where its use would be quite
MF. appropriate. The compiler prices shown in Rich Pattis' post yesterday
MF. are only one aspect of this shameful arrogance and myopia.
MF.
MF. Anyone who thinks that Ada is being held back chiefly by not supporting
MF. multiple inheritance is barking up the wrong tree. The problem is not Ada.
MF. The problem is us, folks.

Oh, I agree...  The problem is not the language.  I do note with amazement,
more than a year after the date beyond which all programming within DOD was
to be done in Ada, that the services have done less than one would expect
to embrace the mandate.  The question was raised at Tri-Ada, "Should the
mandate be rescinded?"  My answer is that the services have chosen to do
pretty much as they choose, with or without the mandate.

It is difficult to imagine what would cause the services to wholeheartedly
adopt Ada, short of its use being an element of command inspection, with
loss of funding/termination of programs as the stick.  There isn't much in
the way of a perceived carrot...  Dropping the mandate certainly will not
improve Ada's usage and keeping a paper tiger doesn't appear to work
either.

Suggestions, anyone?  Regards, Mikey
---
 . JABBER v1.2 #42 . A big enough hammer fixes anything
From: bwallet@apssgi.nswc.navy.mil (Brad Wallet)
Newsgroups: comp.lang.ada
Subject: pragma INLINE
Date: 10 Sep 92 15:43:42 GMT
Organization: Strike Warfare Department, Naval Surface Warfare Center

Can pragma INLINE be used with a function created by pragma INTERFACE to
C code?

-------------------------------------------------
Brad Wallet                 Mathematician
bwallet@relay.nswc.navy.mil Naval Surface Warfare Center
(703)663-4950               (AVN)249-4950
DSMAC - "Tomahawk's Eyes"
"I can neither confirm nor deny that these opinions
are entirely my own and may or may not reflect those
of the US Navy."
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: Ada for Small Processors
Date: 8 Sep 92 17:14:03 GMT
Organization: The Mitre Corp., Bedford, MA.

In article <spray.715537475@convex.convex.com> spray@convex.com (Rob Spray) writes:

   > A project I am familiar with got a waiver to write a few hundred
   > line C program for an Intel 8031.

   Was this an Air Force program? If so, what you got was almost
certainly an exception not a waiver, but that's a different issue.

   > Given the limited address space and register set of some of 
   > these processors, a validated compiler that supports all
   > the intricasies of generics and tasking would be very hard
   > to produce on such a processor.

   Once upon a time, an attempt to validate an Ada compiler for an
8031 which did not support floating point operations or Text_IO might
would have been considered heretical.  However, I think that today
such a validation might be looked at with more favor.   (Certainly
insufficient memory to load Text_IO should make a valid AI-325 case,
etc.)

    But in reality, no one is really pushing for the use of Ada on
small processors.  If the processor, and the code, are really small,
then hardware availability down the road is a much more important
issue than software maintenance costs.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
From: jefu@akbar.nmt.edu (Jeff Putnam)
Newsgroups: comp.lang.tcl
Subject: distributing computation
Date: 12 Sep 92 00:15:50 GMT
Article-I.D.: nmt.1992Sep12.001550.14255
Organization: New Mexico Institute of Mining & Technology


I need to run a program with a number of different parameters
to gather data - tens to hundreds of runs at hours/run.  I'd
like to distribute this on our local network of workstations
by making a list of all the commands to run, then having some
sort of program send out a set of parameters to each workstation
as it becomes idle from the last.  I think I saw something recently
where someone said that they had that kind of a program in
tcl (which is probably a good language to do it in).  Does
anyone have any pointers to such a beast?

thanks

--
jefu <=> Jeff Putnam - New Mexico Tech <=> jefu@nmt.edu 
"Overturn the dominant paradigm"
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: wish -- command line editing
Organization: NeoSoft Communications Services
Date: Sun, 13 Sep 1992 15:50:38 GMT

In article <1992Sep8.181845.24105@walter.bellcore.com> bytor@grumpy.bellcore.com (Ross Huitt) writes:
>...I can't figure out how to get readline
>working seamlessly with Tk. Since the Tk file handler mechanism
>ends up buffering stdin a line at a time, I can't get the readline
>library to read stdin interactively. There's probably something
>I can do with FNDELAY to resolve the problem...

If you have Extended Tcl linked in, try "fcntl stdin NOBUF 1".  

-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
You will now awaken feeling relaxed and refreshed, remembering everything 
you've read except the details of the Omega contingency plan.
From: bame@hpfcbig.SDE.HP.COM (Paul Bame)
Date: Thu, 3 Sep 1992 22:04:54 GMT
Subject: Re: wish -- command line editing
Organization: HP SESD, Fort Collins, CO
Newsgroups: comp.lang.tcl

In comp.lang.tcl, smoot@gumby.cs.Berkeley.EDU (Stephen [Steve] R Smoot) writes:

> Has anyone looked (or completed!) at adding tcsh-like command line 
> editing to wish?

> -s

In the unlikely event you are running HP-UX, you can use the ied(1)
command which gives any arbitrary program ksh(1)-style command editing
and history.
Newsgroups: comp.lang.tcl
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: comp.lang.tcl Frequently Asked Questions (1/3)
Followup-To: comp.lang.tcl
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 8 Sep 1992 14:57:30 GMT


*** old.tcl-faq.p01	Mon Jul  6 12:29:06 1992
--- tcl-faq.p01	Wed Sep  2 14:26:23 1992
***************
*** 2,8 ****
Path: lvirden
  From: lvirden@cas.org (Larry W. Virden)
  Subject: comp.lang.tcl Frequently Asked Questions (1/3)
! 	 (Last updated: July 6, 1992)
  Followup-To: comp.lang.tcl
  Summary: A regular posting of the comp.lang.tcl Frequently Asked Questions 
  	(FAQ) and their answers.  This is the first of three parts.
--- 2,8 ----
Path: lvirden
  From: lvirden@cas.org (Larry W. Virden)
  Subject: comp.lang.tcl Frequently Asked Questions (1/3)
! 	 (Last updated: August 24, 1992)
  Followup-To: comp.lang.tcl
  Summary: A regular posting of the comp.lang.tcl Frequently Asked Questions 
  	(FAQ) and their answers.  This is the first of three parts.
***************
*** 14,21 ****
  Approved: news-answers-request@MIT.Edu
  
  Archive-name: tcl-faq/part1
! Version: 2.2
! Last-modified: July 6, 1992
  
  
  Index of questions:
--- 14,21 ----
  Approved: news-answers-request@MIT.Edu
  
  Archive-name: tcl-faq/part1
! Version: 2.3
! Last-modified: August 24, 1992
  
  
  Index of questions:
***************
*** 43,49 ****
  Subject: -1- What is Tcl?  Tk?  Extended Tcl?  How does Tcl compare
  		against language XXX?
  
! 	Tcl (version 6.3) stands for ``tool command language'' and is
  pronounced ``tickle.'' It is actually two things: a language and a
  library.  First, Tcl is a simple textual language, intended primarily
  for issuing commands to interactive programs such as text editors,
--- 43,49 ----
  Subject: -1- What is Tcl?  Tk?  Extended Tcl?  How does Tcl compare
  		against language XXX?
  
! 	Tcl (version 6.4) stands for ``tool command language'' and is
  pronounced ``tickle.'' It is actually two things: a language and a
  library.  First, Tcl is a simple textual language, intended primarily
  for issuing commands to interactive programs such as text editors,
***************
*** 81,93 ****
  forth.  The common Tcl language framework makes it easier for
  applications to communicate with one another.
  
! 	Tk 2.0 - an extension to Tcl which provides the programmer with
  an interface to the X11 windowing system.  Note that many users will
  encounter Tk via the ``wish'' command.  Wish is a simple windowing
  shell which permits the user to write Tcl applications in a prototyping
  environment.
  
! 	Extended Tcl (tclX) 6.2B - This extended set of commands are
  provided by NeoSoft, and provide additional Unix system interfaces to
  the Tcl programmer.  Many users will encounter Tcl via the ``tcl''
  command - an interactive Tcl command interpreter.
--- 81,93 ----
  forth.  The common Tcl language framework makes it easier for
  applications to communicate with one another.
  
! 	Tk 2.3 - an extension to Tcl which provides the programmer with
  an interface to the X11 windowing system.  Note that many users will
  encounter Tk via the ``wish'' command.  Wish is a simple windowing
  shell which permits the user to write Tcl applications in a prototyping
  environment.
  
! 	Extended Tcl (tclX) 6.4B - This extended set of commands are
  provided by NeoSoft, and provide additional Unix system interfaces to
  the Tcl programmer.  Many users will encounter Tcl via the ``tcl''
  command - an interactive Tcl command interpreter.
*** old.tcl-faq.p02	Thu Aug  6 07:07:33 1992
--- tcl-faq.p02	Thu Sep  3 07:35:22 1992
***************
*** 2,8 ****
Path: lvirden
  From: lvirden@cas.org (Larry W. Virden)
  Subject: comp.lang.tcl Frequently Asked Questions (2/3)
! 	 (Last updated: July 6, 1992)
  Followup-To: comp.lang.tcl
  Summary: A regular posting of the comp.lang.tcl Frequently Asked Questions 
  	(FAQ) and their answers.  This is the first of three parts.
--- 2,8 ----
Path: lvirden
  From: lvirden@cas.org (Larry W. Virden)
  Subject: comp.lang.tcl Frequently Asked Questions (3/3)
! 	 (Last updated: July 9, 1992)
  Followup-To: comp.lang.tcl
  Summary: A regular posting of the comp.lang.tcl Frequently Asked Questions 
  	(FAQ) and their answers.  This is the first of three parts.
--- 2,8 ----
From: mchen@groucho.cs.psu.edu (Michael Chen)
Subject: Re: Variable Substitution: Help.
Date: Wed, 9 Sep 1992 07:15:40 GMT

   One of the ways I got around this was to use double-quotes instead of curly
braces.  It looks really ugly, because you end up saying "foo \[whatever\]" and
get caught up in the backslash thing.
   The easiest way to do this by far is to use the format command to build a
string holding the code you want executed.  Then, just use eval (or uplevel) to
do it.
--
_____________________________________________________________________________
| Michael Chen			| From the depths of our most lucid horrors |
|				| spring our fond hopes and pure desires... |
| mchen@groucho.cs.psu.edu	| except what comes from HELL! :-) 7/23/92  |
\_______________________________\___________________________________________|
From: todd@palomar.tivoli.com
Newsgroups: comp.lang.tcl
Subject: tcl vs. scheme
Date: 14 Sep 92 00:57:25 GMT
Distribution: comp
Organization: TIVOLI Systems, Inc.


I need help in evaluating the use of Tcl as an embedded languge for 
writing user interfaces.  Tcl seems like an obvious choice since it
designed for such purposes, but I lean more toward the use of Scheme
implementations like Elk, siod, or others.  Scheme seems like a much
more powerful (although bigger) environement.

What do all of you ticklers think about this?  Has anybody got
experience with both?

Thanks
--

Todd
-- 
Todd Smith                                     TIVOLI Systems, Inc.
todd@tivoli.com                                6034 West Courtyard Dr.
                                               Suite 210
(512) 794-9070 [794-0623 fax]                  Austin, TX   78730
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: variable argument procedures.
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 07 Sep 1992 17:18:29 GMT

In article <Btx6Fw.Fs3@cs.psu.edu> mchen@groucho.cs.psu.edu (Michael Chen) writes:
>   Sure... try proc foo {args} { puts stdout $args }.
>   Basically, whenever you put args in the parameter list, it takes the values
>in that position in beyond, makes them into a list, and sticks it in args.

...and to amplify this a bit, required arguments can still be specified
explicitly, as in:

proc fprintf {fileHandle args} { ... }

In the above case, an argument for fileHandle must be present, then
zero or more additional arguments come in as a list through "args".
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
You will now awaken feeling relaxed and refreshed, remembering everything 
you've read except the details of the Omega contingency plan.
Xref: sparky comp.lang.tcl:1352 alt.hypertext:756
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.lang.tcl,alt.hypertext
Subject: Re: TkWWW Version 0.3: Anyone Using It?
Date: 14 Sep 92 05:44:08 GMT
Organization: /etc/organization


In article <Bu27Ly.Kvn@phage.cshl.org> boutell@cshl.org (Tom Boutell)
writes:
>
> P.S. Anyone heard from Tim Biehl of the Web lately?

If you mean Tim Berners-Lee, he was here at MIT for a few weeks this
summer.  I haven't heard much since then.

-- 
 \   Charles Hannum, mycroft@ai.mit.edu
 /\  White heterosexual atheist male (WHAM) pride!
Newsgroups: comp.lang.tcl
From: scott@sctc.com (Scott Hammond)
Subject: proc getopt for tcl/expect?
Organization: SCTC
Date: Fri, 11 Sep 1992 16:15:11 GMT

Is there a getopt to simplify parsing command line arguments to my
expect scripts? 

--
Scott Hammond
scott@sctc.com
From: ouster@sprite.Berkeley.EDU (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Re: Bug in menus of radio buttons
Date: 9 Sep 1992 17:02:31 GMT
Organization: U.C. Berkeley Sprite Project
Distribution: world
NNTP-Posting-Host: tyranny.berkeley.edu

In article <9209081508.AA22137@caligula.ansa.co.uk>, eo@ansa.co.uk (Ed Oskiewicz) writes:
|> 
|> The little program below exercises a bug in tk menus.
|> 
|> What I'm trying to do is have two menus each with identical contents which are
|> to operate independantly. I have made each entry a radio button (because it
|> seemed like a good idea at the time) as I wanted to remind the user what the
|> current selection was.
|> 
|> The bug is that you have two menus with identical contents then they behave as
|> though you had two menu buttons onto the same menu.
|> 
|> To see this run the script below, it will produce a pair of menu buttons each
|> of which lists all objects in your current directory.
|> 
|> if you select an entry in one button it changes the text in the menu button
|> and highlights the entry selected. Now if you select the other button you find
|> it's menu has the PREVIOUS SELECTION already highlighted. If you make a new
|> selection and switch back to the first button then it shows your new selection
|> already highlighted. I.e. the two buttons behave as though they are sharing a
|> menu when I would expect each menu to operate independently.
|> 
|> The behaviour I would expect is manifested if I make the menu entries
|> textually different, to see this go to the for loop and comment out the first
|> AddDMenuItem and enable the second - note I've added a space before each
|> directory name.
|> 

The problem is that the radio button entries in the two menus both use the
default value for the controlling variable.  This is actually a useful feature,
not a bug.  Whether 2 radio buttons are in the same group or different groups
has nothing to do with whether they're in the same menu (e.g. you can have
a radio button that's outside a menu but is in the same mutual-exclusion
group as a button in a menu).  This is controlled by the "-variable" option
to radio button widgets and/or radio button menu entries.  If you use different
"-variable" options for the entries in the two menus then the problem will
go away.  For example, I fixed your code by changing the two procedures below:

proc AddDMenuItem {m l} {
  $m.m add radio -label $l -command "Label \"First Folder \" $m $l" \
	  -variable m1
}

proc AddCMenuItem {m l} {
  $m.m add radio -label $l -command "Label \"Second Folder \" $m $l" \
	  -variable m2
}
From: eo@ansa.co.uk (Ed Oskiewicz)
Newsgroups: comp.lang.tcl
Subject: Bug in menus of radio buttons
Date: 8 Sep 92 15:08:14 GMT


The little program below exercises a bug in tk menus.

What I'm trying to do is have two menus each with identical contents which are
to operate independantly. I have made each entry a radio button (because it
seemed like a good idea at the time) as I wanted to remind the user what the
current selection was.

The bug is that you have two menus with identical contents then they behave as
though you had two menu buttons onto the same menu.

To see this run the script below, it will produce a pair of menu buttons each
of which lists all objects in your current directory.

if you select an entry in one button it changes the text in the menu button
and highlights the entry selected. Now if you select the other button you find
it's menu has the PREVIOUS SELECTION already highlighted. If you make a new
selection and switch back to the first button then it shows your new selection
already highlighted. I.e. the two buttons behave as though they are sharing a
menu when I would expect each menu to operate independently.

The behaviour I would expect is manifested if I make the menu entries
textually different, to see this go to the for loop and comment out the first
AddDMenuItem and enable the second - note I've added a space before each
directory name.

N.B. this has been abstracted from a larger script with unwanted detail
excised  hence the apparent verbosity.

Can anyone shed some light on this behaviour?

------ cut here --------
#!/usr/local/wish -f

frame .f1	-relief raised
frame .f2	-relief raised

pack append .	.f1 {top expand fill} .f2 {top expand fill}

proc AddMB {f} {
  menubutton $f.fm -menu $f.fm.m -borderwidth 2 -relief raised
  menu $f.fm.m
  pack append $f $f.fm {left fill expand}
}

proc Label {s m l} {
  $m configure -text "$s: $l"
}

proc AddDMenuItem {m l} {
  $m.m add radio -label $l -command "Label \"First Folder \" $m $l"
}

proc AddCMenuItem {m l} {
  $m.m add radio -label $l -command "Label \"Second Folder \" $m $l"
}

# Create the menu buttons, and provide initial labels
AddMB .f1
AddMB .f2

Label "1st button" .f1.fm "<none>"
Label "2nd button" .f2.fm "<none>"
# I would expect each radio button menu to operate separately, but they don't
# The commented out line gives the behaviour I would expect

foreach i [exec ls -1] {
  AddDMenuItem .f1.fm $i
#  AddDMenuItem .f1.fm " $i"
  AddCMenuItem .f2.fm $i
}
------ cut here --------
Cheers,

Ed Oskiewicz

email:	eo@ansa.co.uk (mcsun!uknet!ansa!eo)	ANSA,
tel:	+44 223 323 010				Poseidon House,
fax:	+44 223 359 779				Castle Park,
						Cambridge CB3 0RD, UK
Newsgroups: comp.lang.tcl