HDTenEightyP/NetNews huggingface dataset:
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Installation/Distribution Problems
Organization: Bellcore
Date: Tue, 21 Jul 92 15:02:27 GMT

I've not had problems with installations but I have had problems with distribution.
It is really not practical for me to require that users of my prototypes install
the full Tk/Tcl/... configuration just to run my software. So, I ship binaries.
This leads to problems in that they likely don't have Tcl/Tk installed so the script
libraries aren't present. So, I ship the binaries along. Of course, I can't have
them worry about them putting the scripts in the same place I installed mine. My solution
to this particular solution, although temporary, is a step in the right direction.
I have essentially extended the init command in main.c for Tk to check for environment
variables if the script directories don't exist. If the environment variables don't
exist, it defaults to the current directory. (I'll probably add the ability to check for
other common locations for the script libraries. )  It is not unreasonable to have
users of my software specify some extra environment variables before running it, so this
is proving to be a very viable solution.

One request to John O.:  _Please_ make the Tcl Library a variable (maybe $tcl_library)
in the next release. Keep [info library] around for compatibility but have it just return
$tcl_library. I _hate_ having to replace the info command just to reset the tcl library
location.

My new init_cmd[] for wish is attached below. Enjoy.

char initCmd[] = "\
set tcl_library [info library]; \
if ![file isdirectory $tcl_library] { \
        if [info exists env(TCL_LIBRARY)] { set tcl_library $env(TCL_LIBRARY) \
        } else { \
        set tcl_library [pwd]; \
        }; \
        rename info old.info.proc; \
        proc info {args} { \
                global tcl_library; \
                if [llength $args]==1&&![string compare library [lindex $args 0]] { \
                        return $tcl_library; \
                } else { \
                        return [eval \"old.info.proc $args\"] \
                } \
        } \
}; \
if ![file isdirectory $tk_library] { \
        if [info exists env(TK_LIBRARY)] { set tk_library $env(TK_LIBRARY); \
        } else { \
        set tk_library [pwd] \
        } \
}; \
source $tk_library/wish.tcl \
";


Ross Huitt
bytor@ctt.bellcore.com
From: przemek@rrdstrad.nist.gov (Przemek Klosowski)
Newsgroups: comp.lang.tcl
Subject: Tcl interaction in my own window
Date: 21 Jul 92 16:07:18 GMT
Organization: U. of Maryland/NIST


Hello, fellow Tcl/Tk users,

I submitted this query once before, but I did not see it in the newsgroup,
so I assume that it was lost, and resubmit it now. Sorry if you do see it
second time around.

I am writing a Tcl application that will have a Tcl interaction
window. I could have followed Wish's example by keeping the
interaction in the original shell/xterm window, but instead I chose
to open a a separate toplevel widget containing a scrolled text window
and an entry window. The carriage return in the "entry' widget is
bound to

proc interactive.command { wframe } {
	set command [$wframe.entry get]
	$wframe.l.list insert end "$command =>"
	$wframe.l.list insert end [eval $command]
}

so, as you can see, both the command and its result get inserted in
the scrolled window. Now, the problem is that the errors are still
printed to the shell window.  Is there a way of intercepting Tcl error
messages/printouts to put them, let say, in a separate message window?

In general, do people have comments on this whole setup? I welcome
both followup posts and e-mail; if there's enough e-mail I will
summarize.
	

	
--
			przemek klosowski (przemek@rrdstrad.nist.gov)
			Reactor Division (bldg. 235), E111
			National Institute of Standards and Technology
			Gaithersburg, MD 20899,      USA

			(301) 975 6249
Newsgroups: comp.lang.tcl
From: garfield@cs.tu-berlin.de (Sven Delmas)
Subject: Re: tkText help?
Organization: Techn. Univ. Berlin (Germany)
Date: Thu, 23 Jul 1992 12:42:18 GMT

Hi,

> I've installed the tkText widget 2.0 in TK 2.1. I'm using xf to 
> configure a GUI with text editing widget and scrollbars.  I source the
> code that xf generates, and then do the work I want to do to
> fill the text widget, etc.
>
> I populate the widget by doing an insert at 0 with the contents of a file.
> (This particular file has 7 lines). When I do so, the text widget executes 
> its "yscrollcommand" with invalid arguments (note that lastUnit is greater 
> than firstUnit):
> 
>    illegal lastUnit 6
>	while executing
>	".frame.scrollbar1 set 7 0 7 6"
> 
> I get this error message only once, and after that scrolling works just
> fine.
> 
> Any ideas for why this is happening, and how to fix it?
What I currently do is just a work around. I call the scrollcommand
not directly. Instead I call this little procedure:

# Arguments: xfW - the widget
#            xfCmd - the set command
#            xfA-D - the parameters
proc XFSmlScrollSet {xfW xfCmd xfA xfB xfC xfD} {
  if {$xfC < $xfD} {
    $xfW $xfCmd $xfA $xfB $xfC $xfD
  } {
    $xfW $xfCmd $xfA $xfB $xfD $xfC
  }
}

The scrollcommand look this way:

-yscrollcommand "XFSmlScrollSet $xfW.$xfName.vscroll set"

This doues not solve the problem, but you get rid of this error
message. The error only occurs if the scrollbar is not needed (the
text has fewer lines than the text widget can display).

Greeting, Sven Delmas
--
----
  Sven Delmas (Techn. Univ. Berlin)
    garfield@cs.tu-berlin.de
----
  For every problem there is a solution which is simple, clean and wrong.
                                                  Henry Louis Mencken
From: adrianho@barkley.berkeley.edu (Adrian J Ho)
Newsgroups: comp.lang.tcl
Subject: Re: bug in expr?
Date: 22 Jul 92 04:09:54
Organization: University of California, Berkeley
NNTP-Posting-Host: barkley.berkeley.edu
In-reply-to: kennykb@dssv01.crd.ge.com's message of 21 Jul 92 21:54:15 GMT

In article <1992Jul21.215415.23716@crd.ge.com> kennykb@dssv01.crd.ge.com (Kevin B. Kenny) writes:
>Can someone explain the following?  More to the point, can someone fix it?
>wish: set x [expr 400000.0+500000.0]
>900000
>wish: set y [expr $x*$x]
>-1748818944
>The square of 900000.0 oughtn't to be a large negative number.

EXPLANATION: In the Expressions subsection of the Tcl(3) man page:

	[...] Where possible, operands are interpreted as integer
values. [...] If an operand does not have one of the integer formats
given above, then it is treated as a floating point number if that is
possible. [...] If no numeric interpretation is possible, then an
operand is left as a string (and only a limited set of operators may
be applied to it.

The first expression sets x to 900000 (not 900000.0), which is
subsequently treated as an *integer* in the second expression.  This
is because the conversion of a floating-point number back to a string
is done as follows:

sprintf(valuePtr->pv.buffer, "%g", valuePtr->doubleValue);
                              ^^
This strips all trailing zeros, and the decimal point if the previous
operation leaves nothing behind it.

FIX: (1) set y [expr $x.0*$x.0] (kludge)
     (2) Change %g above to %e or %f.  Disadvantage: Some numbers will
         look ugly (eg. 900000.0 is returned as 900000.000000).  Apply
         the following patch (change %e to %f if that's your liking):

*** tclExpr.c~  Mon Mar 23 09:54:06 1992
--- tclExpr.c   Wed Jul 22 04:03:17 1992
***************
*** 1124,1130 ****
      if (valuePtr->type == TYPE_INT) {
        sprintf(valuePtr->pv.buffer, "%ld", valuePtr->intValue);
      } else if (valuePtr->type == TYPE_DOUBLE) {
!       sprintf(valuePtr->pv.buffer, "%g", valuePtr->doubleValue);
      }
      valuePtr->type = TYPE_STRING;
  }
--- 1124,1130 ----
      if (valuePtr->type == TYPE_INT) {
        sprintf(valuePtr->pv.buffer, "%ld", valuePtr->intValue);
      } else if (valuePtr->type == TYPE_DOUBLE) {
!       sprintf(valuePtr->pv.buffer, "%e", valuePtr->doubleValue);
      }
      valuePtr->type = TYPE_STRING;
  }

Any comments, John?
--
-----------------------------------------------------------------------------
Adrian Ho, He With The Embarrassingly *Dead* Passion ** Phone: (510) 642-5563
System Manager, CFD Lab, ME Dept, UC Berkeley * adrianho@barkley.berkeley.edu
Maintainer, Tcl/Tk Contrib Archive ---- barkley.berkeley.edu [128.32.142.237]
  Send all Tcl/Tk Archive-related stuff to tcl-archive@barkley.berkeley.edu
From: lim@rani.chem.yale.edu (Dongchul Lim)
Newsgroups: comp.lang.tcl
Subject: Re: tk_butDown and tk_butUp
Date: 27 Jul 92 17:23:33 GMT
Organization: Yale University
X-Newsreader: Tin 1.1 PL4

lim@doctor.chem.yale.edu (Dongchul Lim) writes:
: I compiled tcl6.3 and tk2.1 on our SGI4D running IRIX 4.0.1.
: Then I tested 'wish' with demo programs.
: Whenever I tried to click on a button, I got the following
: error message:
: tkerror failed to handle background error.
:     Original error: invalid command name "tk_butDown"
:     Error in tkerror: invalid command name "tkerror"
: 
: Does this mean 'tk_butDown' command desn't exist?
: Or have I done something wrong with compilation?
: -dcl
: 
: --

I'm posting this for the people who might have the same
probelm.
Thanks to people who replied. Most of them pointed out that
library directory might have not been installed properly.
In fact, there's nothing wrong with library path. When I
compiled tcl and tk, I redefined TCL_LIBRARY and TK_LIBRARY
(something like /usr/people/lim/lib) in Makefiles, because
I don't have a root access so I can't install them in
/usr/local/lib. Later I put all *.tcl, libtcl.a and libtk.a
in the library directory (as defined by TK_LIBRARY and TCL_
LIBRARY). Now 'wish -f demo.tk' will work fine? Not on my
system (SGI IRIX 4.0.1). Problem was that some tcl scripts
(in my case, button.tcl) were not loaded automatically.
As Justin Seiferth indicated, after I concatenated button.tcl
to tk.tcl, problem was solved.
-dcl
From: adrianho@barkley.berkeley.edu (Adrian J Ho)
Newsgroups: comp.lang.tcl
Subject: Re: How do I imbed tcl in an application
Date: 28 Jul 92 09:07:58
Organization: University of California, Berkeley
	<ADRIANHO.92Jul27175403@barkley.berkeley.edu>
	<1992Jul28.114518.12123@rchland.ibm.com>
NNTP-Posting-Host: barkley.berkeley.edu
In-reply-to: shmdgljd@rchland.vnet.ibm.com's message of 28 Jul 92 11:45:18 GMT

In article <1992Jul28.114518.12123@rchland.ibm.com> shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall) writes:
>How do I provide access to structures more complex than just strings?

I was going to suggest arrays (vanilla Tcl) or keyed lists (Extended
Tcl), but it sounds like...

>typedef struct {
>    char *name;
>    int  rank;
>    int  ssn;
>} Soldier;
>Soldier grunt;

...you want to preserve the struct in *this* form so that your
internal code can mess around with it too.

>Now, is there any way I can pass ``grunt'' to a tcl proc and have it be
>able to access grunt.name or grunt.rank ?

As you mentioned, you could add a tcl command whose sole purpose is to
provide a Tcl interface to the appropriate fields, doing any necessary
string conversions along the way.  Of course, this tends to blow up in
your face if you have more than one struct type...

A good compromise (if you have Extended Tcl) is to use keyed lists.
Support C functions to access and manipulate keyed lists are included,
so you don't have to parse the keyed list yourself to extract the
appropriate fields.  You'll have to remember the field types to do
back conversions to numeric data, of course, but you'd have to do
that anyways...
--
-----------------------------------------------------------------------------
Adrian Ho, He With The Embarrassingly *Dead* Passion ** Phone: (510) 642-5563
System Manager, CFD Lab, ME Dept, UC Berkeley * adrianho@barkley.berkeley.edu
Maintainer, Tcl/Tk Contrib Archive ---- barkley.berkeley.edu [128.32.142.237]
  Send all Tcl/Tk Archive-related stuff to tcl-archive@barkley.berkeley.edu
From: adrianho@barkley.berkeley.edu (Adrian J Ho)
Newsgroups: comp.lang.tcl
Subject: Re: uplevel/upvar and trace
Date: 22 Jul 92 16:44:52
Organization: University of California, Berkeley
Distribution: usa
NNTP-Posting-Host: barkley.berkeley.edu
In-reply-to: cgp@Arco.COM's message of Wed, 22 Jul 1992 20:34:40 GMT

In article <1992Jul22.203440.15926@Arco.COM> cgp@Arco.COM (Chris Phillips  (214) 754-6419) writes:
>However, the following extensions to arrays doesn't work
>for the upvar version:
>	   proc a1 {n i op} {
>		   set z [uplevel set [set n]($i)]
>		   puts stdout $z
>	   }
>	   proc a2 {n i op} {
>		   upvar [set n]($i) z
>		   puts stdout $z
>	   }
>Why?

From the upvar command documentation in the Tcl man page:

upvar ?level? otherVar myVar ?otherVar myVar ...?
  [...] Neither otherVar or myVar may refer to an element of an array.

which is what you're actually doing in a2.  The following will work:

	   proc a2 {n i op} {
		   upvar [set n] z
		   puts stdout $z($i)
	   }

tcl>trace var b(1) w a2
tcl>set b(1) 2
2
tcl>
--
-----------------------------------------------------------------------------
Adrian Ho, He With The Embarrassingly *Dead* Passion ** Phone: (510) 642-5563
System Manager, CFD Lab, ME Dept, UC Berkeley * adrianho@barkley.berkeley.edu
Maintainer, Tcl/Tk Contrib Archive ---- barkley.berkeley.edu [128.32.142.237]
  Send all Tcl/Tk Archive-related stuff to tcl-archive@barkley.berkeley.edu
Newsgroups: comp.lang.tcl
From: lim@doctor.chem.yale.edu (Dongchul Lim)
Subject: Re: tk_butDown and tk_butUp
Organization: Yale University
X-Newsreader: Tin 1.1 PL4
Date: Mon, 27 Jul 1992 17:35:12 GMT

lim@doctor.chem.yale.edu (Dongchul Lim) writes:
: I compiled tcl6.3 and tk2.1 on our SGI4D running IRIX 4.0.1.
: Then I tested 'wish' with demo programs.
: Whenever I tried to click on a button, I got the following
: error message:
: tkerror failed to handle background error.
:     Original error: invalid command name "tk_butDown"
:     Error in tkerror: invalid command name "tkerror"
: 
: Does this mean 'tk_butDown' command desn't exist?
: Or have I done something wrong with compilation?
: -dcl

I'm posting this for the people who might have the same
probelm.
Thanks to people who replied. Most of them pointed out that
library directory might have not been installed properly.
In fact, there's nothing wrong with library path. When I
compiled tcl and tk, I redefined TCL_LIBRARY and TK_LIBRARY
(something like /usr/people/lim/lib) in Makefiles, because
I don't have a root access so I can't install them in
/usr/local/lib. Later I put all *.tcl, libtcl.a and libtk.a
in the library directory (as defined by TK_LIBRARY and TCL_
LIBRARY). Now 'wish -f demo.tk' will work fine? Not on my
system (SGI IRIX 4.0.1). Problem was that some tcl scripts
(in my case, button.tcl) were not loaded automatically.
As Justin Seiferth indicated, after I concatenated button.tcl
to tk.tcl, problem was solved.
-dcl

Newsgroups: comp.lang.tcl
From: jiangwu@sickdog.CS.Berkeley.EDU (Jiang Wu)
Subject: Bugs in Canvas Rect/Oval item
Organization: University of California, Berkeley
Date: Thu, 30 Jul 1992 21:15:31 GMT


While developing an application using tk2.1, I found a bug in canvas
rectangle/oval item.  I have a rectangle item that is being moved around in
the screen by dragging it with the mouse.  I use canvas command "move tagOrId
xAmount yAmount" to shift the rectangle around.  Everything is fine until I
do a "xview" or "yview" on the canvas to shift origin of the canvas to
none (0, 0).  Then, the rectangle does not redraw correctly after "move"
command.  I think this only happens to rectangle/oval items.  Other canvas
items behave correctly to the "move" command after "xview"/"yview" is
applied to the canvas.

Type in the following commands in wish to see this bug:

    wish: canvas .c -scrollincrement 1 -background white
    wish: place .c -in .
    wish:
    wish: .c addtag a withtag [.c create rectangle 0 0 20 20 -fill red]
    wish: .c addtag a withtag [.c create oval 0 30 20 50 -fill yellow]
    wish: 
    wish: # Everything works when you do move here
    wish: .c move a 10 0
    wish: .c move 1 10 0
    wish: .c move 2 10 0
    wish: 
    wish: # Now we do a xview on the canvas
    wish: .c xview 10
    wish: 
    wish: # Then we do move, only half of the rectangle/oval are showing now
    wish: .c move a 20 0
    wish: 
    wish: # Let's move the origin of the canvas back to (0, 0)
    wish: .c xview 0
    wish: 
    wish: # Everything is o.k. again.
    wish: .c move a 30 10


Comments?

-- Jiang Wu
   jiangwu@postgres.berkeley.edu
Newsgroups: comp.lang.tcl
From: bill@snoopy (Bill Poitras)
Subject: Re: bug in expr?
Reply-To: bill@msi.com
Organization: Molecular Simulations, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Wed, 22 Jul 1992 00:04:00 GMT

kennykb@dssv01.crd.ge.com (Kevin B. Kenny) writes:
: 
: Can someone explain the following?  More to the point, can someone fix it?
: 
: wish: set x [expr 400000.0+500000.0]
: 900000
: wish: set y [expr $x*$x]
: -1748818944
: 
: The square of 900000.0 oughtn't to be a large negative number.

What should it be?  Overflow?  It helps to specify what you want.  In tcl
as it is, creating a result larger than 2^32 is undefined.  What do you
want it defined as?

--
+-----------------+-------------------------------+-------------------------+
| Bill Poitras    | Molecular Simulations Inc.    | Tel (408)522-9229       |
| (bill)          | Sunnyvale, CA USA             |                         | 
|                 | FAX (408)732-0831             | bill@msi.com            |
+-----------------+-------------------------------+-------------------------+

Newsgroups: comp.lang.tcl
From: bachww@rtsg.mot.com (Bud Bach)
Subject: Extended on the NeXT
Reply-To: bachww@rtsg.mot.com
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Wed, 29 Jul 1992 17:18:52 GMT

Has anyone built Extended Tcl 6.2B on the NeXT?  This is one of my
first attempts at getting something built on the NeXT and I cold use
some help.  Right now I am trying to figure out what to do about a
missing header file <values.h>.  Any ideas?  -- Bud

-- 
Bud Bach - Consultant				c/o Motorola
708 632-3449					Cellular Infrastructure Group
bachww@rtsg.mot.com or				1501 W. Shure Drive, MS-1235
..!uunet!motcid!bachww				Arlington Heights, IL  60004
Newsgroups: comp.lang.tcl
From: gwlester@cpu.com (Gerald W. Lester)
Subject: Re: How do I imbed tcl in an application
Organization: Computerized Processes Unlimited, Metairie, LA, (504)-889-2784
Date: Wed, 29 Jul 1992 22:25:57 GMT
Reply-To: gwlester@cpu.com

In article <156g6sINNnp2@agate.berkeley.edu>, ouster@sprite.Berkeley.EDU (John Ousterhout) writes:
>...
>Second, Larry Virden asked about the extension at the level of sub-commands:
>
>    Something that I have been wondering about along these lines is based on
>    John's two initial papers.  They described the tcl/tk environment in 
>    such a way that it seemed that a user would be able to write their own
>    extended sub-options for tcl commands and then the application would
>    read these extentions / parameters , etc and allow the user customizations.
>    
>    Did I get the wrong idea?  Is there a way for me to add new commands to
>    a tcl/tk application automatically, or does each application need to add
>    code to handle this possibility?  If so, where does that fit into the
>    previously described skeleton that you folks are talking about?
>
>You can add commands, but you can't add subcommands to existing commands.
>For example, if you wanted to add a "remove" option to the string command,
>so that you could say "string remove <string> <letter>" to remove all
>instances of <letter> from <string>, you'd have to modify the C code that
>implements "string".

John,

	You could also rename string to something else (eg string_org) than add
a proc called string that sees if the "command" is an extended command (like
"remove" in your example above), if so it would process it, otherwise it would
do an uplevel on "string_orig $args".  I know it is "cheating", but it works.

gwl

Newsgroups: comp.lang.tcl
From: gwlester@cpu.com (Gerald W. Lester)
Subject: Re: BEEP?
Organization: Computerized Processes Unlimited, Metairie, LA, (504)-889-2784
Date: Mon, 27 Jul 1992 14:25:47 GMT
Reply-To: gwlester@cpu.com

In article <681@ceylon.gte.com>, mw06@newshost.gte.com (Mark Weissman) writes:
>Is there any way in tk/wish to make the display showing the 
>tk windows beep?

No,

	It is a easy addition, I'm sending John my patch.  if you are
interested send me e-mail and I'll either post the patch or mail it to you.
From: petert@logitek.co.uk (Peter Telford)
Newsgroups: comp.lang.tcl
Subject: Latest version of Tk.
Keywords: tk, version
Date: 22 Jul 92 12:21:45 GMT
Organization: Logitek Plc.

Does anyone know of a mail server that I can get the latest version of
Tk from?  Unfortunately I do not have ftp access to the internet.

regards 
Peter Telford.


-- 
"====================================================================="
" Peter Telford.        " Sex is like snow... You never know how many "
" Logitek Group Support." inches you're going to get or how long it   "
" Ltss Ltd.             " will last.                                  "
" England.              "                                             "
"===================< Normal Disclaimers >============================"
From: kennykb@dssv01.crd.ge.com (Kevin B. Kenny)
Newsgroups: comp.lang.tcl
Subject: Re: bug in expr?
Date: 22 Jul 92 21:58:00 GMT
Reply-To: kennykb@crd.ge.com
Organization: GE R&D, Information Architectures & Management Program


In article <1992Jul22.163913.27329@cbnewsm.cb.att.com>, gah@grenache (George A.
Howlett) writes:
|> I think the point that Kevin is making is that if you started out
|> with floating point values, you should get a floating point result.
|> The implicit demotion of the sum of two floating point numbers into
|> a integer result is unexpected.  It's fairly easy to detect here,
|> but insidiously hard to track in more complex usages. 

Yes indeed.  That was the point.  Sorry I hadn't made myself clearer
-- I'd just been at my terminal for several hours tracking down a
particularly insidious bug that resulted from the implicit demotion.

The %#g idea is a good one -- I'd forgotten about the `#' flag, also!
(time to dust off Harbison and Steele...).  The OFMT variable might be
even better.  John, do you have any comments?

|> I can repost this patch if anyone's interested.

Thanks, George -- I appear to have missed it.

|> BTW: If you are using the patch to add math library functions,
|>      you could have explicitly promoted x using the "float()"
|>      function.

Gosh, it's time to take another look at *that* patch, too.  I've been
mening to install it.  John, can we get that one into the standard
product?  It's needed.

73 de ke9tv/2, Kevin          There isn't any .signature virus, is there?
Newsgroups: comp.lang.tcl
From: johng@cimage.com (John Gourlay)
Subject: Re: Tcl in Microsoft Windows
Organization: Cimage Corp, Ann Arbor, MI
X-Newsreader: Tin 1.1 PL4
Date: Tue, 28 Jul 92 15:05:55 GMT

The answer seems to be that there are DOS ports but no Windows port.
A Windows port would be different even omitting Tk because of standard
library differences.  Areas that I'm aware of are in memory
management, file I/O (no stdin, stdout, or stderr), and floating
point.

The DOS ports are available from barkley.berkeley.edu, Austin Code Works,
and cajal.uoregon.edu.

johng@cimage.com (John Gourlay) writes:
: Has anyone made Tcl work in in Microsoft Windows or in DOS?
: 
: John Gourlay
: johng@cimage.com