HDTenEightyP/NetNews huggingface dataset:
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: 7.0 - Just say no!
Followup-To: comp.lang.tcl
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Wed, 4 Nov 1992 22:54:33 GMT

Adrian Ho last spring contributed some code which enabled us to do dynamic
loading of C libraries, so that one interpreter could have tcl, tk, extended,
etc and a script would only need to load those portions that it needed.
This seems like it would be a step ahead in terms of keeping the size
proportional to the needs.
-- 
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
Newsgroups: comp.lang.tcl
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Re: standard output from wish
Date: Tue, 10 Nov 1992 18:58:46 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

In article <1992Nov10.171427.6285@cs.cornell.edu>, davis@cs.cornell.edu (Jim Davis) writes:
|> if ($#argv > 5) then
|>   echo "usage: `basename $0`  FILE [-switch baz] "
|>   exit 1
|> endif
|> What's the Tcl/wish equivalent?

Unfortunately, wish hides what would be argv[0] from you, so I don't
know any nifty way to get your script name other than hardcoding it.

Granting that, you could do

   set programName {foo}
   if {[set argc [llength $argv]] > 5} {
       puts stderr [format {usage: %s FILE [-switch baz]} $programName]
       exit 1
   }
   puts stdout "argv is ($argv), argc is $argc"
   exit 0

If you're using wish built with extended tcl, programName will be set for
you, I believe.

-- 
: 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: davis@cs.cornell.edu (Jim Davis)
Subject: standard output from wish
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 10 Nov 1992 17:14:27 GMT


Mandatory apology:  I have searched the Tcl FAQ and all back articles
before sending these questions.

I want to write some simple, window oriented commands in wish (Tcl).
I would like these commands to parse command line arguments, to print
reasonable error messages if the arguments are wrong, and to be able
to produce output on standard output as a result.  But I can't
find a way to do it.

I tried calling echo but it produces no output.  (If I start wish with
no args, and call echo, I *do* see the output; but if I have a shell
script with wish as the interpreter, I *don't* see the output; I can
also do

exec echo "bunch of words" > /dev/console

but I don't want the output to go to the console, I want it to
go to the place where the user invoked the program.

If I were programming in csh, I would have written something like

if ($#argv > 5) then
  echo "usage: `basename $0`  FILE [-switch baz] "
  exit 1
endif

What's the Tcl/wish equivalent?

I can use error, but it produces a lot of output including a trace of
the internal location within the script; this does not belong in the
error message.

In the more general case, I'd like to be able to send stuff to std
output so that I can do other things from the shell with the results
of my Tcl program.

best wishes
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Newsgroups: comp.lang.tcl
Subject: Setting icon for tk app (or, how do I configure `.' ?)
Date: 9 Nov 92 17:18:57 GMT
Reply-To: jay@vnet.ibm.com
Organization: IBM Rochester, MN
Disclaimer: This posting represents the poster's views, not necessarily those of IBM

I'd like to allow users to specify their own icon for a tk app that I've
written.  However, this is an app that they are likely to have multiple
instances of, and each new instance gets a different number tacked on.

For example, right now they might be using

Mwm*myapp*iconImage: some_image

which works fine for the first instance.  If they fire up another one,
though, its name becomes ``myapp #2''.  I'd guess that the proper way to
do this would be to set a class for my app, but I can't use the -class
option of the toplevel command on `.', which I am assuming _is_ a toplevel?

When I try `. configure -class Myapp', I get ``invalid command name "."''

Thanks for any suggestions.
-- 
: 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: welch@parc.xerox.com (Brent Welch)
Subject: Re: new user questions
Organization: Xerox PARC
Date: 10 Nov 92 17:23:18 GMT

Remember to use square brackets to achieve command substitution

set line [ gets $in ]

set eof [ eof $in ]

There is also a split:

set fields [ split $stuffWithColons : ]
--

	Brent Welch
From: raines@bohr.physics.upenn.edu (Paul Raines)
Newsgroups: comp.lang.tcl
Subject: what is "expect"
Date: 5 Nov 92 16:21:09 GMT

What is "expect" that is supposed to packaged with tcl.
I don't recall anything being said about it in the installation
notes.

-- 
Paul Raines	raines@purcell.physics.upenn.edu	215-898-8832
Dept. of Physics
University of Pennsylvania
Newsgroups: comp.lang.tcl
From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: Re: tk on 386 or 486 under X and Linux?
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Date: Thu, 12 Nov 92 20:52:17 GMT

Yes, it's real easy. Just follow the instructions.


-- 
Tommy.Thorn@daimi.aau.dk | If you use a PC consider upgrading to a real OS.
Join the League for Pro- | Linux is Posix (Unix). It has GCC,Emacs,X11,TCP,NFS,
gramming Freedom, LPF    | Doc,Interviews,Prolog...(you name it) and it's free!
Newsgroups: comp.lang.tcl
From: tdoan@bnr.ca (Tuan Doan)
Subject: Running Shell commands
Keywords: Shell, Pipe, TCL/TK, exec, eval
Organization: Bell-Northern Research, Richardson, Tx.
Date: Fri, 06 Nov 1992 21:07:18 GMT

   I apologize for my unclear question regarding how to execute shell commands
inside TCL/TK.  What I need to do is execute the following shell commands.

   pr -h '[$uid] $file1' $file1 | ipr -D"pageduplex off"

$uid and $file1 are TCL/TK variables.  The argument to -D in the 'ipr' command
must be in quotes.  Notice that the argument to -h in the 'pr' command
contained brackets.  The above commands work fine under ksh, but I could not
convert it to work under TCL/TK.                                     

Thanks,

 __  __/  /   /   __  /    |   /    Tuan T. Doan
    /    /   /   /   /   / |  /     Advance Signalling Design
   /    /   /   __  /   /  | /      2201 Lakeside Blvd.  P.O. Box 833871
__/  ______/ __/ __/ __/  __/       Richardson, TX 75083-3871
                                    Phone: 6-444-4575/214-684-4575
Internet:  tdoan@bnr.ca             Fax:   6-444-3716/214-684-3716
      or   tdoan@x400gate.bnr.ca    
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Dumping/Restoring Interpreter Memory
Organization: NeoSoft Communications Services -- (713) 684-5900
Distribution: usa
Date: Thu, 12 Nov 1992 06:54:30 GMT
Keywords: dump restore tcl interpreter

In article <1992Nov11.163524.12633@stortek.com> v043332@gandalf.stortek.com (Keith Amann) writes:
>I have noted that the tclTest program has a function call to
>Tcl_DumpActiveMemory, but can't seem to locate this function (John, is this
>not included in the regular distribution?).  I believe that this is part of
>what I am looking for, and I could probably derive the "restore" given this
>piece of it.
>Any helpful hints or suggestions would be greatly appreciated.  Also, I would
>prefer something that DOES NOT utilize Extended TCL (no offense intended, I
>just happen to like to stick to the original).

No offense taken, but pity you feel that way about Extended Tcl -- files, 
arrays and, yes, this Tcl_DumpActiveMemory function you are interested in 
originated there.

Unfortunately for your purposes, Tcl_DumpActiveMemory is part of the
memory tracking package that, when compiled in, can detect corruption
problems, usually identifying the filenames and line numbers that
malloc'ed the areas that became corrupted.  Also stuff like freeing
twice, freeing things that weren't allocated, and such, are detected.

Tcl_DumpActiveMemory can be called at the end of a session and, if there 
are any mallocs that did not have corresponding frees, the filenames, line 
numbers and sizes of the mallocs are printed -- very, very useful for
finding memory leaks.

As for your plan of traversing the interpreter and grabbing off all of
the memory, well, it looks possible, but possibly quite difficult.  
Although of course being able to save and restore state on an interpreter-
by-interpreter basis would be better, something easier to try might be the 
trick where you force a coredump after loading everything and patch up the 
image to make it executable again.  Perl has a similar capability -- you 
might have a look at how they did.

With X-windows, though, you'd have to save off before you started much
in the way of X initialization -- surely you'd have to save sometime
before starting to communicate with the server.  Consider open files
and data stashed away by other functions behind your back by the C
library as well.
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
"It took no computation to dance to the rock 'n roll station."
-- VU
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.lang.tcl
Subject: Re: expect kudos and a comment
Date: 7 Nov 92 19:58:31 GMT
Organization: National Institute of Standards and Technology
In-reply-to: chip@chinacat.unicom.com's message of 6 Nov 92 06:48:02 GMT

In article <1992Nov06.064802.3584@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes:
   I did run into one problem during this work.  Expect does not lend
   itself to toolbox coding.  For example, my clock resync thing runs
   as:

	   expect /etc/local/nisttime.exp | TZ=GMT0 adjclock

   The difficulty is that expect wants to do its logging to stdout, which
   precludes its use in a pipeline.  I did a quick hack to the "log_file"
   command to recognize the keyword "stderr".  My "nisttime.exp" script
   starts with:

	   log_user 0
	   log_file -a stderr

   The hack probably should have been to the "log_user" command, but it
   was easy to tweak "log_file".  The main ugliness to this hack is that
   anything output with a "send_error" command is printed twice.  I'd
   like to suggest that if there is ever an update to expect, some
   mechanism to allow user logging to stderr instead of stdout would be
   very useful -- indeed necessary if you want to use expect in a pipeline.

You don't really want to send the whole log to stderr, right?  If you just
want to log the output to a file but send something else to stdout, do:

	log_user 0
	log_file -a ....
	puts stdout ....

Don
Newsgroups: comp.lang.tcl
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Re:  new user questions
Date: Wed, 11 Nov 1992 20:38:14 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

In article <1992Nov11.180209.1032@twg.com>, "David Herron" <david@twg.com> writes:
|> > Q. 2
|> > How do I turn off the icon button for child windows ( or I guess more
|> > apropriately, how I create a window without the toplevel command )
|> 
|> In Xt based toolkits (or in Motif anyway) different `shell' widgets
|> are used for different purposes.  Motif has a DialogShell widget
|> which doesn't put out an icon and negotiates a different set of
|> window border doo-dads.  (No iconize, etc)

Basically, you need to set the ``shell'' widget so that it mimics the
behavior of Motif's dialog shell.  Under the configuration I have under
Mwm, dialog shells don't have an iconify or maximize button, and when
you iconify the toplevel, the dialogs go with it.

To emulate this under tk, you can do
	
	toplevel .dshell
	wm group .dshell .
	wm transient .dshell .

|> It appears that Tk 3.0 won't have this fixed either since the dialogs
|> in `Perspecta Presents!' have a complete set of window border doo-dads.
|> On the other hand they've incorporated some of that since using the window
|> manager to close windows doesn't kill the process.

The wmprotocols code would probably be necessary for this (ie., to trap the
wm close/kill selection), unless of course they wrote their own.

-- 
: 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: laik@cory.Berkeley.EDU (Kevin Lai)
Subject: Re: Tcl-on-the-Mac mailing list?
Organization: University of California, at Berkeley
Date: Fri, 13 Nov 1992 20:48:16 GMT

I would also be interested what happened to the Tcl-on-the-Mac mailing list.
I recently ported Tcl 6.4 to Think C 5.0.3 using the port of Tcl 6.1
on barkley, but I have gotten no farther than #ifdef-ing out most
file and process related stuff.

Kevin Lai
From: jhh@sprite.berkeley.edu (John H. Hartman)
Newsgroups: comp.lang.tcl
Subject: mx/tx 2.5 available
Followup-To: comp.lang.tcl
Date: 11 Nov 1992 20:23:31 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: loiter.berkeley.edu


I've put together a version of mx and tx that uses the standard X
selection mechanism, rather than the current home-grown variety.
The sources are available on sprite.berkeley.edu in mx-2.5.tar.Z.
A patch file is in mx-2.5.patch.Z. There are a few caveats:

1) mx and tx still use an old version of tcl (5.0 or so) and do
not use tk.  The version of tcl you need is included in the
distribution. Get a copy of Brent Welch's "mxedit" if you want a
version of mx that uses tk.

2) I didn't include support for the incremental mode of selection
transfer.  As a result mx and tx 2.5 will only handle selections
up to 256KB in size.  You can increase this if you want. Modify
the TK_SEL_BYTES_AT_ONCE variable in the file sx/tkSelect.c.

3) The old selection mechanism is not supported at all, so you
can't cut and paste between the new version of these programs and
older versions.

Let me know if you have any problems.

John
-----------------------------------------------------------------------
John H. Hartman
Graduate Student, UCB Sprite project
jhh@sprite.berkeley.edu
Newsgroups: comp.lang.tcl
From: netmgr@convex.csc.FI (Pekka Kytolaakso)
Subject: Re: simple Tk MH interface
Organization: Centre for Scientific Computing, Finland (CSC)
Date: Tue, 10 Nov 92 16:19:35 GMT

In <6749@dove.nist.gov> bagwill@swe.ncsl.nist.gov (Bob Bagwill) writes:
>I'm working on a simple Tk MH interface since it seems no one else seems
>to have written one.
>I have some questions:
>1) should I post the code to this newsgroup?
>2) or to one of the source groups
>3) or just submit it to the archive?
>If I post it to this newsgroup:
>4) do people want to see a very primitive version, so they can critique it, or
>5) wait for a gooder fuller-featured version?
>Bob Bagwill

Please submit a primitive version. I'd like to look at modifying it to
understand MIME using mhn. This would also include simple modifications
to make send use mimencode and 'context-type:text/plain;charset=iso-8859-1'.

Pekka Kyt|laakso
--
---------------------------------------------------------------
netmgr@csc.fi            Centre for Scientific Computing
Pekka.Kytolaakso@csc.fi  PL 40   SF-02101 Espoo FINLAND
Phone: +358 0 4571       Telefax: + 358 0 4572302
From: gah@att.com (George A. Howlett)
Newsgroups: comp.lang.tcl
Subject: Re: Creating and Import file from an xygraph plot
Date: 12 Nov 92 21:45:23 GMT
Reply-To: george.howlett@att.com
Organization: AT&T Bell Laboratories
X-Newsreader: TIN [version 1.1 PL6]

Carol Thielman (thielman@calspan.com) wrote:
:       I am attempting to create a file depicting the information in
:       a xygraph plot.  This file can be in one of two formats 
:       1) postscript with a preview immage or 2) raster format.  I
:       have looked at the output from the postscript function in xygraph
:       and it does not contain a preview image.  Has anyone done this or
:       have any ideas about the easiest way to create these files?
: 

You could create a file containing the X window dump of the xygraph window 
with following proc.  It uses the "xwd" program.  You simply give it
the pathname of the xygraph widget and the name of the file store the
window dump.

From there you can use xv, xwd2ps, or the pbmplus utilities to translate
the xwd format to whatever format you choose (i.e. PostScript).

I don't know whether this solves your problem. 

--gah

##############################################################
#
# CreateWindowDump --
#  
#	Dump the contents of the named window into a given
#	file.  The procedure requires the use of the xwd
#	program which comes with standard MIT X distribution.
#
# 	w        - Pathname of widget window to dump
# 	fileName - Name of file to create (will automatically 
#       	      get .xwd extension)
# 
# Note: Xwd does not explicitly set an exit code, so you need to
#	catch to results of the exec
#
proc CreateWindowDump { w fileName } {
    set winId [winfo id $w]
    set cmd "exec xwd -id $winId -out $fileName.xwd"
    catch $cmd msg
}
Newsgroups: comp.lang.tcl
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Re: Setting icon for tk app (or, how do I configure `.' ?)
Date: Tue, 10 Nov 1992 18:45:12 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

In article <1992Nov10.163611.15168@cas.org>, lwv26@cas.org (Larry W. Virden) writes:
|> Are you asking how to get the icon name to be the same in every instance?
|> Or are you wanting each instance to have it's own icon image...

I'm asking how to get the icon to be the same in every instance.  However,
it must be a _user specified_ icon.  I can easily do

	wm iconname . @some_image

to set it the same for each instance; however, I want the user to be able
to set it rather than the app itself.

-- 
: jay          jay@vnet.ibm.com    My opinions and ideas, not my employer's.
: shmdgljd@rchland.vnet.ibm.com    (c) Copyright 1992.  All rights reserved.
From: bjv@shasta.tivoli.com (Brian Vetter)
Newsgroups: comp.lang.tcl
Subject: Re: lvarpop bug
Date: 10 Nov 92 23:54:23 GMT
Organization: TIVOLI Systems

|> In article <1992Nov3.162737.27869@bnr.ca> colton@bnr.ca (Kevin Colton) writes:
>I think the following is a bug with lvarpop:
>  set x "a \"b\" c"
>  lvarpop x
>  a
>  echo $x
>  b c
>  lvarpop x
>  b
>The literal quotes are stripped off ...

I suspect that what you want back is "b" and not b
So try the following:

set x {a \"b\" c}

Brian Vetter
bjv@tivoli.com
Xref: sparky comp.lang.tcl:1820 comp.lang.perl:6966
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.tcl,comp.lang.perl
Subject: Re: Closures, Object-Oriented Equivalence, New version of Perl and TCL
Date: 12 Nov 92 18:11:50 GMT
Followup-To: comp.lang.tcl
Organization: Department of Computer Science, University of Manchester
In-reply-to: thayer@cs.columbia.edu's message of 11 Nov 92 05:21:57 GMT

In article <9211110521.AA01343@cs.columbia.edu> thayer@cs.columbia.edu (Charles Thayer) writes:
   Scheme is good language for writing other programming systems such
   as Prolog, LOOP, Ski, expert shells.  [I don't know anything about
   LOOP or Ski, but Stephen Bevan wrote these in scheme.]

Just to clarify the above: LOOP is a _very_ simple language and all I
did was write a denotational definition of it in Scheme.  The
implementation language (Scheme) was not relevant, I could use almost
any language to perform an excercise like this.  Similarly "Ski" is
really an evaluator for SKI combinators which I think most would agree
is a trivial thing to implement.

With regard to extending languages to create new languages: I still
most languages in the area are playing a catch up game to Lisp/Scheme.
Note I'm not claiming Lisp/Scheme are perfect, only that of the
languages I've looked at (TCL and Perl to name but two) none did
anything better and they did plenty of things worse.  Big IMHO there
of course.

bevan
From: chip@chinacat.unicom.com (Chip Rosenthal)
Newsgroups: comp.lang.tcl
Subject: expect kudos and a comment
Date: 6 Nov 92 06:48:02 GMT
Article-I.D.: chinacat.1992Nov06.064802.3584
Organization: Unicom Systems Development, Austin, TX

I'm posting rather than mailing because "expect" is way kool, and it
deserves some public adulations.  You're out there Don, aren't you?

I cranked up expect many months ago, but put it to real use only in
the past few weeks.  My first application was a script to call up NIST
with "cu", acquire a timestamp, and emit an HHMMSS string into another
program which gracefully slews the system clock into synchronization.
The second application was automating a multi-hour procedure under a
dorky 4GL menued-to-the-max system.

I did run into one problem during this work.  Expect does not lend
itself to toolbox coding.  For example, my clock resync thing runs
as:

	expect /etc/local/nisttime.exp | TZ=GMT0 adjclock

The difficulty is that expect wants to do its logging to stdout, which
precludes its use in a pipeline.  I did a quick hack to the "log_file"
command to recognize the keyword "stderr".  My "nisttime.exp" script
starts with:

	log_user 0
	log_file -a stderr

The hack probably should have been to the "log_user" command, but it
was easy to tweak "log_file".  The main ugliness to this hack is that
anything output with a "send_error" command is printed twice.  I'd
like to suggest that if there is ever an update to expect, some
mechanism to allow user logging to stderr instead of stdout would be
very useful -- indeed necessary if you want to use expect in a pipeline.

-- 
Chip Rosenthal  512-482-8260 | I got the blues so bad one time
Unicom Systems Development   | it put my face in a permanent frown.
<chip@chinacat.Unicom.COM>   |   - Taj Mahal
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Running Shell commands
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Sun, 8 Nov 1992 16:57:44 GMT
Keywords: Shell, Pipe, TCL/TK, exec, eval

In article <1992Nov06.210718.14408@bnr.ca> tdoan@bnr.ca (Tuan Doan) writes:
>   pr -h '[$uid] $file1' $file1 | ipr -D"pageduplex off"

    exec pr -h '\[$uid\] $file1' $file1 | ipr -D\"pageduplex off\"

Usually, though, I think "format" is a lot easier to understand.

    set string [format {exec pr -h '[%s] %s' %s | ipr -D"pageduplex off"} $uid $file1 $file1
    eval $string

Any extra overhead caused by using format is clearly dwarfed by the
i/o setup, fork, exec and wait done by "exec".

If you have Extended Tcl, I'd suggest "system" instead of "exec" when
you don't need the output of the exec'ed program returned as a string,
plus "system" takes the command list as a single argument rather than multiple
arguments, which would have obviated the need to put the "exec" in the
format string and "eval" to evaluate it.

-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
"It took no computation to dance to the rock 'n roll station."
-- VU
From: thayer@cs.columbia.edu (Charles Thayer)
Newsgroups: comp.lang.tcl
Subject: Re: Tcl with emacs or epoch
Date: 11 Nov 92 04:12:08 GMT
Article-I.D.: cs.BxJAC9.6rs
Organization: Columbia University Department of Computer Science

You can talk between tcl or tk or wafe or perl or emacs.  Use sockets or
pipes.

For tcl use tcpConnect or pipes.
For perl use sockets or pipes.
For emacs use the process functions.

Heck you could even used named pipes and just files.

/charles

-- 
==============================================================================
Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
Newsgroups: comp.lang.tcl