HDTenEightyP/NetNews huggingface dataset:
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Planning for Tcl 7.0
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Fri, 09 Oct 1992 05:20:38 GMT

In article <1b216tINNf26@agate.berkeley.edu> smoot@gumby.cs.Berkeley.EDU (Stephen R Smoot) writes:
>In article <1avu22INN5ao@agate.berkeley.edu>, ouster@sprite.Berkeley.EDU (John Ousterhout) writes:
>> 1. Eliminate the "|" option in the "open" command.  Instead, add a
>> "popen" command that does the same thing. Rationale: in the current
>> implementation you can't open a file whose name begins with "|".
>> Also, I think the "popen" command would be more logical.

>I like the syntax.  And I like fewer commands.
>I'd prefer a option to open to say "no, exactly what I give you"
>instead of a new command.

Yeah, I'd like any change with this to maintain backwards compatibility.
Maybe a "p" option, like 'open "ps ax" rp'...

>Other suggestion:
>A better way to pass in the name of an array, and reference its elements
>from the procedure (the best I can do for this seeems a real hack!).

What's wrong with "upvar"?

proc list_array_elements {arrayName} {
    upvar $arrayName myArray
    foreach element [array names myArray] {
	puts stdout "$element $myArray($element)"
    }
}
-- 
-- 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.
Newsgroups: comp.lang.tcl
From: scott@sctc.com (Scott Hammond)
Subject: syntax(?) error in simple wish script
Organization: SCTC
Date: Tue, 13 Oct 1992 18:55:40 GMT

{tk 2.3, tcl6.4, SunOs4.1.2}
The following script generates an error.  I don't understand what's
wrong, and what is 'arm line 5'?.

	#!wish -f
	set xxx 2
	set i 0
	set a {-p a }

	    case [ lindex $a $i ] in {
		{ -p } {
			if { [expr $i+1] < $xxx } {
			    incr i;
			}
			{
			 puts stderr "missing"
			}
		}
	    }
	wm withdraw .

The error is:

	invalid command name "
			 puts stderr "missing"
			"
	    while executing
	"error "invalid command name \"$name\"""
	    (procedure "unknown" line 38)
	    invoked from within
	"{
			 puts stderr "missing"
			}"
	    (" -p " arm line 5)
	    invoked from within
	"case [ lindex $a $i ] in {
		{ -p } {
			if { [expr $i+1] < $xxx } {
			    incr i;
			}
			{
			 puts stderr "missing"
			}
		}
	    }"
	    (file "nb" line 7)
	    invoked from within
	"source nb"

Newsgroups: comp.lang.tcl
From: chare@unilabs.uucp (Chris Hare)
Subject: Documentation on Tk and Tcl
Summary: Is there any how-to or tutorial manuals?
Keywords: tk tcl man tutorial how-to
Organization: UniLabs Research Group
Date: Fri, 9 Oct 1992 10:43:06 GMT

Hi folks:

I'm a little new (ha!) to Tcl and Tk.  Besides the man pages and the usenix
papers, are there any "books" on tcl in general, i.e. programming or
tutorial style books, and how about one on Tk?  I'm giving some thought to
building a couple of things which my staff needs in Tk, but I need some
more "know-how" first.

Thanks - you can post or e-mail replies.

Regards.


-- 
????                --- It Always works for me! ---                           
Chris Hare, UNIX Scientist                  Preferred : chare@unilabs.uucp
Just a mild-mannered consultant by day ....
Newsgroups: comp.lang.tcl
From: boyes@bnr.ca (Greg Boyes)
Subject: Re: Planning for Tcl 7.0
Organization: BNR Europe Ltd, Maidenhead, UK
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 09 Oct 1992 19:30:36 GMT

Request for incompatible change
-------------------------------

  How about in-line comments, even when using line-continuation
  to continue the command and its parameters?

  In our applications, we've implemented this within our stdin 
  handler, so the comments are gone before Tcl ever sees them.

  But... for comments in source'd files, we've ended up 
  re-implementing Tcl_EvalFile() to handle in-line comments,
  before handing over to Tcl_Eval().

  End result: inconsistent with the rest of the world.
Newsgroups: comp.lang.tcl
From: "David Herron" <david@twg.com>
Subject: Re: Is there a tcl interface to Motif, even commercial? 
Sensitivity: Personal
Encoding:  51 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Fri, 9 Oct 1992 22:47:06 GMT

>	1) Add the tk extensions to tcl in to your applications
>	2) Set the Motif look and feel flag to 1.  (Hitn: it has motif in the
>	   name)

Er..  As some of the bugs in our MR database point out, tk is *not* Motif.
(I used tk/tcl to write an installation program awhile back..)  Even tk2.3
is quite a ways different than Motif.

IMHO tk is good enough for most/lots of purposes.  But sometimes exact Motif
compliance is *important*.


The possibilities I know of:

WaFE has most of the stuff necessary to interface with Motif.  It includes
some files which give templates to all/most of the Xlib/Xt/Xaw procedures,
along with Perl scripts to process those into .c files which define matching
functions to TCL.  I don't like various details in WaFE, but it's close.

DETAILS: They strip off the prefix which identifies which module a command
is originating in.. for instance, XtDestroyWidget() becomes destroyWidget.
This makes it harder to learn because the names are gratutituously different.
There is also the danger of name collisions if some procedures are the
same name sans prefix.  There are actually a couple such name collisions
between the Athena and Motif text widgets.  This is available from somewhere
in Germany.. ask Archie for a better pointer ;-).

The marketing glossy for `ezX' (an X/Motif Interface Builder which runs
on Vax/Sun/DEC-RISC/RS6K/386 Unix/SGI) includes a paragraph saying:

	{\bold Any interpreted language} can be used to control
	the behavior of windows and widgets.  Common languages such
	as Tcl, BASIC or PROLOG can be used or a custom language
	defined and integrated by the end user.

Anybody know what they mean here?  They're at: Sunrise Software International,
phone: (401) 847-7868, fax: (401) 847-7879.  I have no experience with
them other than talking to a sales person on the floor at XHibition & getting
confused.

Finally there is `ril'.  It is Wcl which is wrapped up so it can be
called from Tcl scripts.  It was very clear that the interface could
be built this way, but I saw nothing which would allow Wcl & Tcl to
communicate with one another.  That is, how would you have a piece
of Tcl manipulate the values in a listbox, for instance?  It's available
from export.lcs.mit.edu in `contrib'.

> P.S. - The VMS sources are *not* at berkeley.

BTW, just 'cause the guys at DEC doesn't mean he works on VMS.  I hear
they have one or two other OS's they sell ;-).

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
From: ellson@ontap.att.com (54312 - John C Ellson)
Newsgroups: comp.lang.tcl
Subject: Re: How resizing listbox ? (& Re: text resizing bug)
Date: 15 Oct 92 23:16:39 GMT
Article-I.D.: cbnewsk.1992Oct15.231639.28511
Reply-To: ellson@ontap.att.com
Organization: AT&T
Originator: ellson@ontap

From article <1992Oct15.170629.7188@newsgate.sps.mot.com>, by mathys@utopia.sps.mot.com (Yves Mathys):
> I have *not* been able to resize listbox, althouth its parent's window
> was correctly resizing. 
> Any ideas? Do I need a special option on listbox or pack? 

Well this really confused me, because I was getting resizable listbox
widgets but strange resizing on text widgets.

The trick seems to be to use wm min/maxsize - in a uniform manner (which
I was not doing).  Here is a resizable listbox:

	#!/usr/local/bin/wish -f
	wm minsize . 20 20
	wm maxsize . 1152 900
	pack append . [listbox .l -borderwidth 2 -relief raised] {expand fill}

Doing the same with the text widget brings its resizing under control too.
So I guess the bug that I was seeing (resizing to the full olvwm size) is 
just in the default behavior of text.  

I withdraw the bug report.

John.Ellson@att.com
Newsgroups: comp.lang.tcl
From: farrar@adaclabs.com (Stephen Daedalus)
Subject: Help with font size
Organization: The Eye of the Pyramid, Inc.
Date: Wed, 14 Oct 1992 23:48:20 GMT

Is there anyway to get the grid x and y size in pixels?  I would like to 
use the placer to specify row and column locations, where the row height
is the y size (in pixels) of the default font for either the window or the
parent window, and the column width is the x size (in pixels) of the default
font.  Something like
place .foo.button -in .foo -x [expr 5*[.foo getfontx]] -y [expr 5*[.foo getfonty]]
That will place button at position row 5 column 5 within .foo

Can you help?  Thanks.
---
Richard Farrar		These views are my own, not my company's or country's.
ADAC Laboratories	"A man without hand is not a man."
farrar@adaclabs.com		- George Costanza, Seinfeld
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.lang.tcl
Subject: Re: Help w/ controlling 2 processes
Date: 14 Oct 92 21:12:33 GMT
Organization: National Institute of Standards and Technology

In article <1992Oct8.063851.2488@ads.com> pdel@ADS.COM (Peter Delevoryas) writes:
>Hi, I've got a dump program I am trying to automate with expect.
>
>It requires two processes, one called backup and the other called
>butc. Anyone using AFS will recognize it as the included dump utility.
>
>Here's what I have so far:
. . .
>set spawn_id $id1
>send [ exec cat afs_dump ] ;# this sends the dump info
> interact +		    # if I don't put this in, backup quits
>
>set spawn_id $id2
>expect "Hit return when done*" # The 'butc' prints this to screen after
>send "\r" ;		       # 'backup' has processed the dump info
>interact + 			# I don't know if I need this. Maybe not.

>Well, that's it. It doesn't quite work yet. I don't think the "\r" at
>the end is getting to butc. It does send the dump info to backup,
>though.

The 'interact's don't make any sense to me, except perhaps as a way of
flushing the buffers.

I recommend putting an 'expect' after each 'send' to verify that the
command you sent worked - or at least was received.  You don't need an
'expect' immediately after each 'send' but you need at it some point.

Since you don't have an expect after either final send to each process,
there is no reason for your script to wait for the commands to work
before killing them.

>Basically I want to avoid starting up 2 windows with backup in one
>and butc in the other; I just want to start the script and have it
>spawn the two processes and then send strings to each one. I have the
>manual and read about multiple processes, but I still need a little
>help understanding what's happening.

Check out the chess example in Expect's directory of example scripts.
It connects two chess programs together and massages the output of
each so that they are acceptable as input.

If you have any more questions, feel free to mail directly to me.

Don
Newsgroups: comp.lang.tcl
From: ellson@ontap.att.com (54312 - John C Ellson)
Subject: Re: Real time graphs.
Reply-To: ellson@ontap.att.com
Organization: AT&T
Distribution: usa
Date: Thu, 15 Oct 1992 23:22:48 GMT
Originator: ellson@ontap

This should be trivially easy using graph-1.0.tar.Z from
barkley.berkeley.edu.  This package includes barcharts, xygraphs and
hypertext documents.  The demo hypertext document already includes a 
live barchart.

From article <1992Oct15.191454.7892@ncsa.uiuc.edu>, by vijay@ncsa.uiuc.edu (Vijay Rangarajan):
> Is it possible to use tcl/tk to graph data, which is written into a log
> file at constant intervals ? The log file will be updated every 5 minutes
> and I was wondering if it would be possible to use tcl/tk to feed the data 
> to a graphing program (like xgraph, gnuplot, etc.) ?
> 
> Among the suggestions I got in trying to get real time graphs was to use
> tcl/tk to feed data into a graphing package, using 'expect'.
> 
> I would appreciate input from tcl/tk users, some sample code would really
> be of great help.
> 
> Thanks,
> Vijay.
Newsgroups: comp.lang.tcl
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: Planning for Tcl 7.0
Followup-To: comp.lang.tcl
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Mon, 12 Oct 1992 10:58:12 GMT

>I'd also like to see explicit access to filehandlers in official TCL.
> An adoption of tclRawTcp would do it.

I am not familar with this package yet.  Does this imply that filehandlers
would only be available on machines with TCP?  I personally would love
to see general purpose features stay away from requiring packages that
are generally optional.  For instance, I would love to see a send command
which perhaps allowed the user to configure any one of several possible
ways of implementing.  If the system is configured to handle TCP, then
use that.  If not, then if it has shared memory, or msg queues, etc. use
that.  If none of these, then config would indicate that feature would not
be available.  This should allow folk to easily add new ways of supporting
features such as that on versions of machines like Mac, Amiga, etc. 
which do not necessarily have Ether support.
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
From: ouster@cs.Berkeley.EDU (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Draft of Part I of Tcl/Tk book
Date: 9 Oct 1992 17:23:40 GMT
Organization: U.C. Berkeley Sprite Project
Distribution: world
NNTP-Posting-Host: tyranny.berkeley.edu


As some of you know, I'm working on an introductory book for Tcl and Tk.
It will be published by Addison-Wesley, hopefully in 1993.  I've worked
out an arrangement with them whereby I can make pieces of the book
available to the Tcl community in draft form to help meet the need for
a gentle introduction to Tcl and Tk in the interim until the full book
appears.  I've finished a first rough draft of Part I of the book, which
is on writing scripts in the Tcl language, and I've left compressed
Postscript for it in the Tcl distribution area on sprite.berkeley.edu
in the file "book.p1.ps.Z".  The file is about 130 pages long.

You're welcome to make copies of this for yourself, but any mass duplication
of the draft (or duplication for profit) requires advance permission from
Addison-Wesley.

This is just a first draft so I'm very interested in getting any comments
you might have.  Send them to me at "ouster@cs.berkeley.edu" and I'll try
to incorporate them into the final published version.
Newsgroups: comp.lang.tcl
From: scott@sctc.com (Scott Hammond)
Subject: Re: syntax(?) error in simple wish script
Organization: SCTC
Date: Wed, 14 Oct 1992 00:44:51 GMT

shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall) writes:

>I think the curly braces are forcing tcl to interpet the entire thing
>between them as a command name; no command by that name, hence the error.

You're comment made me suddenly see what's wrong.

	if { expression } {
	}
	{
	}

is not the same as:

	if { expression } {
	} {
	}

What I thought was an else clause was not really an else clause.
Newsgroups: comp.lang.tcl
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: tk send to another display ?
Date: Mon, 12 Oct 1992 21:13:57 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

Well here's a real bonehead question for you.  Does send work across
displays?  The man page could perhaps be a bit clearer on this:

	<send> _interp_ _cmd_ ?_arg_ _arg_ ...? 

	_Interp_ must be the name of an interpreter registered on
	the display associated with the interpreter in which the
	                                ^^^^^^^^^^^
	command is invoked;

Does the second interpreter refer to the interpreter which is executing
the send command, or the interpreter where the sent command _cmd_ will be
executed?  I'd just try it out, but I haven't got another display handy.

-- 
: jay          jay@vnet.ibm.com    My opinions and ideas, not my employer's.
: shmdgljd@rchland.vnet.ibm.com    (c) Copyright 1992.  All rights reserved.
Newsgroups: comp.lang.tcl
From: joe@athena.mit.edu (Joseph C Wang)
Newsgroups: comp.lang.tcl
Subject: Re: Several questions about Tcl/Tk
Date: 8 Oct 92 02:26:29 GMT
Organization: Massachusetts Institute of Technology

In article <1992Oct7.174129.7021@twg.com> david@twg.com (David Herron) writes:
>This is something to be very careful of because of the obvious trojan 
>horse problem.  

I was wondering what to do about this problem myself, with regard to
tkWWW.  What I'm doing to deal with the problem is to disable renames
completely and query the user with a dialog box whenever the program
starts a process.  

But I still get nervous thinking about the obvious security risks in
tkWWW.

>The language used for this case should not provide access
>to external files/processes and various other things which I have not 
>studied on yet (to a great extent).

One problem with that is that providing access to external files and
processes is very, very useful.  Too useful in fact to for me to
consider it eliminating completely.

>Speculation: A good way to start is with the existing TCL 6.4 and strip 
>out all its File & Process operators.  Then figure out what things you
>need for screen display and pull in no more than those from `tk'.

It would be a good idea to make TCL/Tk more modular and to have it
load in, only the parts that it needs.  For example, keyed lists would
be very useful for modularizing tkWWW, but I'd rather not load all of
the NeoSoft extensions (especially since the file handling
capabilities of extended tcl would make the security problems with
tkWWW even worse than they are).
Newsgroups: comp.lang.tcl
From: schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: Planning for Tcl 7.0
	<PIERSON.92Oct8132015@kukri.mps.mlo.dec.com>
Date: Thu, 8 Oct 1992 20:22:20 GMT

   For the record, the other reason was unmeasured concern about the
   performance of Tcl lists.  It wouldn't have caused a change by itself
   unless backed up by measurements.

Well, we recently recoded a chunk of stuff in C for performance
reasons.  "lists" in tcl are actually strings, so some list operations
are slower than you'd expect, and if you perform them often lot it
adds up.  Another problem was that the overhead of control structures
in tcl was very high.  Looping over the elements of a list or an array
of any significant size was very slow in tcl.
From: awu@cisco.com (Andrew Wu)
Newsgroups: comp.lang.tcl
Subject: Is the comment illegal or the Tcl bug?
Date: 14 Oct 1992 01:58:29 GMT
Organization: cisco Systems, Incorporated
Distribution: world
NNTP-Posting-Host: regal.cisco.com


The following Tcl script dosen't work because of the comment "#comments"
in the case statment.

#!/awu/bin/expect -f

set a 1
case $a {
 #comments
 {1} {
   puts stdout "a=1"
  }

  default {
   puts stdout "a<>1"
   }
 }




Is this a Tcl bug or my misunderstanding?

If it's my mis-understanding, which version of Tcl ManPage says the usage
of this comment is illegal?

Thank,

-andrew
Newsgroups: comp.lang.tcl
From: lwv26@cas.org (Larry W. Virden)
Subject: Unified diff of the comp.lang.tcl FAQ postings
Followup-To: comp.lang.tcl
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Thu, 8 Oct 1992 11:19:35 GMT


Yet again I am experimenting with format.  This month, I am using the
Unified Diff format as requested by one of the group's members.  Hopefully
things won't be too confusing.

Note that I would appreciate volenteers, submissions, etc. for the FAQ.
I would even MORE appreciate one of you taking on the yeoman's task of
writing a full blown tutorial for tcl, extended tcl and wish <grin>.


--- old.tcl-faq.p01	Tue Sep  8 10:52:48 1992
+++ tcl-faq.p01	Thu Oct  8 07:01:30 1992
@@ -2,7 +2,7 @@
Path: lvirden
 From: lvirden@cas.org (Larry W. Virden)
 Subject: comp.lang.tcl Frequently Asked Questions (1/3)
-	 (Last updated: August 24, 1992)
+	 (Last updated: October 8, 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,12 +14,13 @@
 Approved: news-answers-request@MIT.Edu
 
 Archive-name: tcl-faq/part1
-Version: 2.3
-Last-modified: August 24, 1992
+Version: 2.4
+Last-modified: October 8, 1992
 
 
 Index of questions:
 
+0. Origin of the comp.lang.tcl FAQ information.
 1. What is Tcl?	 Tk?  Extended Tcl?  How does Tcl compare against language 
 	XXX?
 2. Do these packages run on my machine?
@@ -40,6 +41,21 @@
 End of FAQ Index
 
 ------------------------------
+Subject: -0- Origin of the comp.lang.tcl FAQ information.
+
+The information in this set of FAQs comes from 3 sources.  The primary
+source of information is the group itself - I spent (much too much) time
+each month culling through what I feel are some of the best answers,
+gathering up new information on ports, etc. and adding it here.  I also
+gather together new application information and add it as best I can.
+The next most predominant source of information comes from the authors
+of the various software packages.  Finally, a small amount comes from
+my personal experiences.
+
+I am always on the search for folk to assist in the maintenance of these
+FAQs.  In fact, if you feel that you would like to coordinate this 
+effort, PLEASE let me know!
+
 Subject: -1- What is Tcl?  Tk?  Extended Tcl?  How does Tcl compare
 		against language XXX?
 
@@ -112,7 +128,8 @@
 
 	Contact W. Ross Brown <ross@bnr.ca> for the current status of
 the Tcl MacOS port.  Ross has a mailing list for discussion on that
-topic.
+topic.  Also, "Eric W. Sink" <e-sink@uiuc.edu> is working on a port
+which includes some tclX extentions as well as some Mac-specific extensions.
 
 c. MS-DOS
 
@@ -236,6 +253,16 @@
 Systems, Vol. 4, No. 2, University of California Press Journals, 1991.
 (A comprehensive paper of example scripts.  This paper is
 pub/expect/scripts.ps.Z on ftp.cme.nist.gov.)
+
+C. A FrameMaker MIF file containing a Quick Reference guide to Tcl is
+available as barkley.berkeley.edu:/tcl/docs/QuickRef.tar.Z.  Thanks to
+"Jeff Tranter" <Jeff.Tranter@software.mitel.com> for contributing it.
+
+D. PostScript versions of the man pages were provided by 
+"Adrian Ho" <adrianho@barkley.berkeley.edu>.  These are available on
+barkley.berkeley.edu:/tcl/docs/tcl6.3.manps.tar.Z
+barkley.berkeley.edu:/tcl/docs/tclX6.2b.manps.tar.Z
+barkley.berkeley.edu:/tcl/docs/tk2.1.manps.tar.Z
 
 Additional bibliographic references still sought.
 
--- old.tcl-faq.p02	Tue Sep  8 10:52:52 1992
+++ tcl-faq.p02	Thu Oct  8 07:01:20 1992
@@ -2,10 +2,10 @@