HDTenEightyP/NetNews huggingface dataset:
dov
Newsgroups: comp.lang.tcl
Subject: On my wishlist: tk-"wafe"
From: dov@menora.weizmann.ac.il (Dov Grobgeld)
Date: Fri, 11 Sep 1992 07:54:50 GMT
Organization: Weizmann Institute of Science, Computation Center.
X-Newsreader: Tin 1.1 PL4

It's easy to wish (sic.) so that's what I'm doing. I'd like to see
an interface to tk working as wafe does to the Athena Widgets. I.e.
two processes speaking with each other through STDIN and STDOUT.

Such a combination is much more flexible than wish with TCL alone,
as you write the code in any language of your choice. Just look at
the wealth of programs that Gustaf Neumann included with wafe
written in Perl. With TK you are restricted to either writing in
TCL or C.

Someone recently asked for a Perl-version of TK in the comp.lang.perl
newsgroup, but I'm a bit more modest. I'll be happy enough if there
is an easy way to communicate between Perl and TK in TCL.

--
                                                        ___   ___
                                                      /  o  \   o \
Dov Grobgeld                                         ( o  o  ) o   |
The Weizmann Institute of Science, Israel             \  o  /o  o /
"Where the tree of wisdom carries oranges"              | |   | |
                                                       _| |_ _| |_
From: cid@wupost.wustl.edu (Central Inst for the Deaf)
Newsgroups: comp.lang.tcl
Subject: Event Handling in Tcl/Tk
Date: 14 Sep 1992 23:36:30 -0500
Organization: Washington University in Saint Louis, MO
NNTP-Posting-Host: wugate.wustl.edu


I am at the point where I need to start doing some event handling.
As I read through the man pages for Tk, I find myself wishing there
was an example somewhere.

So.  Any TK event handling experts out there?

Please post to this newsgroup, as I am using a friend's acct.

bill
Newsgroups: comp.lang.tcl,news.answers
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: wish -- command line editing
Organization: Bellcore
Date: Tue, 8 Sep 92 18:18:45 GMT

I've been using the GNU readline library for my core Tcl shells.
It works just fine. However, 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, but I've had other
priorities...

Ross Huitt
bytor@ctt.bellcore.com
From: stolcke@ICSI.Berkeley.EDU (Andreas Stolcke)
Newsgroups: comp.lang.tcl
Subject: Re: wish -- command line editing
Date: 5 Sep 1992 06:06:43 GMT
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Reply-To: stolcke@icsi.Berkeley.EDU (Andreas Stolcke)
NNTP-Posting-Host: icsib30.icsi.berkeley.edu

In article <55220005@hpfcbig.SDE.HP.COM> bame@hpfcbig.SDE.HP.COM (Paul Bame) writes:
: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.

Two free program for that purpose are ile and fep.  Check archie for
ftp locations.

-- 
Andreas Stolcke					stolcke@icsi.berkeley.edu
International Computer Science Institute	stolcke@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704	(510) 642-4274 ext. 126
Newsgroups: comp.lang.tcl
From: scott@sctc.com (Scott Hammond)
Subject: varargs problem in Tcl_AppendResult()?
Organization: SCTC
Distribution: na
Date: Mon, 14 Sep 1992 02:19:44 GMT

Re: tcl6.4 on Sun4 (SunOS 4.1.2) built with 'cc'

Using a simple loop that reads single lines from the user and passes
them to the same interp via Tcl_Eval(), I entered the following:

	? proc testhis {} { uplevel 1; set x 5 }
	result: ''
	? testhis
	err result: 'wrong # args: should be "'
	wrong # args: should be "
	    while executing
	"uplevel 1"
	    (procedure "testhis" line 1)
	    invoked from within
	"testhis"


result is the value of interp->result.  err result is
the same after error detected, followed by information
from Tcl_GetVar() on errorInfo.

My concern is that the error message is truncated, which
means the varargs stuff in Tcl_AppendResult() isn't working.
On brief inspection it looks ok to me and appears to match
the description on the SunOS man page.  I also get this if
I feed it to tclTest.

Anyone run into this?
From: welch@parc.xerox.com (Brent Welch)
Newsgroups: comp.lang.tcl
Subject: mxedit.tar.1.2.1.Z
Keywords: Fixes to mxedit 1.2 distribution
Date: 12 Sep 92 17:33:40 GMT
Organization: Xerox PARC

There were a couple of botches in the mxedit.tar.1.2.Z file.
I've fixed these up and reposted
mxedit.tar.1.2.1.Z
to parcftp.xerox.com:pub/mxedit
and barkley.berkeley.edu:tcl/extensions

--

	Brent Welch
From: larry@tweety.cs.berkeley.edu (Larry Rowe)
Newsgroups: comp.lang.tcl
Subject: Looking for beta testers for a commercial product built using tcl/tk
Date: 11 Sep 1992 14:53:02 GMT
Organization: U.C. Berkeley EECS Dept.
Distribution: world
Reply-To: larry@cs.Berkeley.EDU
NNTP-Posting-Host: tweety.cs.berkeley.edu

The subject just about says it all.  The company has a presentation package
written for Unix workstations (SPARC, RS6K, HP, and DEC) that needs to be
tested.  If you're interested in helping, send email.
	Larry
Newsgroups: comp.lang.tcl
From: jamensky@bnr.ca (Mark Jamensky)
Subject: Re: Going Busy in Tk
Reply-To: jamensky@bnr.ca (Mark Jamensky)
Organization: Bell-Northern Research Ltd.
Date: Fri, 11 Sep 1992 13:09:35 GMT

  I obtained the "busy" script to change my cursor to a watch.  I modified it
such that all widgets have their cursor changed to a watch whether they had a
a cursor associated with them or not.  My problem is that when I change the
cursor for a frame (using ".frame config -cursor watch") with several widgets in
it, Tk seems to be doing a resize or refresh and thus my whole window seems to
redraw itself.  Is there a way to stop this refresh or is it inherent in the frames.

-- 
Mark Jamensky   jamensky@bnr.ca   Bell-Northern Research   Ottawa

Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: Inefficient string handling
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Fri, 11 Sep 1992 21:30:21 GMT

In article <1992Sep10.205122.25788@walter.bellcore.com> Nathaniel Borenstein 
<nsb@thumper.bellcore.com> writes that wraplines, below, is slow.

>proc wraplines {txt} {
>    set ans ""
>    set index 0
>    set column 0
>    set len [string length $txt]
>    for {} {$index < $len} {incr index} {
>        set thischar [string index $txt $index] 
>        append ans $thischar
>        incr column
>        if {$thischar  == "\n"}  {set column 0}
>        if {$thischar  == " " && $column > 70}  {set column 80}
>        if {$column > 79} {
>            append ans "\n"
>            set column 0
>        }
>    }
>    return $ans
>}

Tcl can get really slow if you do a lot of stuff character-at-a-time like
this.

As for improvements, note that no matter what, your program does nothing to
the first seventy characters of each line except copy them across.

So this suggests an approach where you start your index at 70 and walk it
'til you find you blank (or not), then do an
    append ans "[string range $lo $hi]\n"
when you know exactly what you want.

That alone should speed your routine by more than two orders of magnitude.

If you can cook up a regular expression that does what you want, "regsub"
might be worth looking into.

Oh, and you could use Extended Tcl's "loop" command, instead of "for", to
eke out a bit more performance still, as loop will avoid at least one "eval"
and one "expr" call per time through the loop.
-- 
-- 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: Nathaniel Borenstein <nsb@thumper.bellcore.com>
Subject: Inefficient string handling
Organization: Bellcore
Date: Thu, 10 Sep 92 20:51:22 GMT

I recently had to write a Tcl procedure that took an arbitrary length
string and made sure it was broken down into terminal-oriented line
lengths.  The procedure I wrote turned out to be so mind-bogglingly slow
that I ended up rewriting it in C and installing it via
Tcl_CreateCommand.  However, I can't help thinking there MUST be a
faster way to do this in tcl itself, and that there's a corner of the
language I haven't learned about yet.  Can anyone tell me what I did
wrong?   The C version of this is lightning fast, of course, but the Tcl
version is real molasses.  Is there some perfect-for-the-purpose Tcl
primitive of which I am unaware?

There's one obvious speedup I haven't done, which would be to append the
text in chunks rather than a character at a time, but I'm wondering if
there's just a whole better way to do this...  Any suggestions would be
appreciated.  -- Nathaniel

proc wraplines {txt} {
    set ans ""
    set index 0
    set column 0
    set len [string length $txt]
    for {} {$index < $len} {incr index} {
        set thischar [string index $txt $index] 
        append ans $thischar
        incr column
        if {$thischar  == "\n"}  {set column 0}
        if {$thischar  == " " && $column > 70}  {set column 80}
        if {$column > 79} {
            append ans "\n"
            set column 0
        }
    }
    return $ans
}
From: welch@parc.xerox.com (Brent Welch)
Newsgroups: comp.lang.tcl
Subject: tkReregisterWindow.c
Summary: This procedure changes the name of a registered app.
Keywords: New TK procedure
Date: 12 Sep 92 17:19:59 GMT
Organization: Xerox PARC

I've added this procedure to my TK library.  I use it to change the
name of a registered application as used in the send command.
In my case, when an editor window switches files, I want to change
the interpreters name, too.  This procedure rightfully belongs
in tkWindow.c, and it duplicates some code in there to choose alternate
names, so perhaps John will want to fold it in.

/*
 * tkReregisterWindow.c
 *	I've added the folowing procedure to tkWindow.c
 */
#include "tk.h"
#include "tkInt.h"


/*
 *----------------------------------------------------------------------
 *
 * Tk_ReregisterWindow --
 *
 *	Re-register the interpreter for an application under a new name..
 *
 * Results:
 *	TCL_OK or TCL_ERROR.  If TCL_ERROR is returned,
 *	an error message will be left in interp->result.
 *
 * Side effects:
 *	"interp" is registered for "send" commands
 *	under "baseName".  BaseName may be extended with an instance
 *	number in the form "#2" if necessary to make it globally
 *	unique.  The TCL send command is bound to the interpreter.
 *
 *----------------------------------------------------------------------
 */

int
Tk_ReregisterWindow(interp, tkwin, baseName)
    Tcl_Interp *interp;		/* Interpreter associated with window */
    Tk_Window tkwin;		/* Main window to re-register */
    char *baseName;		/* Base name for application;  usually of the
				 * form "prog instance". */
{
    TkWindow *winPtr = (TkWindow *) tkwin;
    int result;
    char newName[110];
    /*
     * Deleting the "send" command has the side-effect of unregistering
     * the interpreter.
     */
    Tcl_DeleteCommand(interp, "send");
    /*
     * Register the interpreter.
     */
    strcpy(newName, baseName);
    result = Tk_RegisterInterp(interp, newName, tkwin);
    if (result != TCL_OK) {
	int i;

	for (i = 2; ; i++) {
	    sprintf(newName, "%.100s #%d", baseName, i);
	    Tcl_SetResult(interp, (char *) NULL, TCL_STATIC);
	    result = Tk_RegisterInterp(interp, newName, tkwin);
	    if (result == TCL_OK) {
		break;
	    }
	    if (i >= 100) {
		Tcl_SetResult(interp,
			"couldn't generate unique name to register application",
			TCL_STATIC);
		return TCL_ERROR;
	    }
	}
    }
    winPtr->nameUid = Tk_GetUid(newName);
    return TCL_OK;
}

--

	Brent Welch
From: welch@parc.xerox.com (Brent Welch)
Newsgroups: comp.lang.tcl
Subject: mxedit 1.2
Summary: Posted version 1.2 of mxedit
Keywords: TCL editor mx
Date: 11 Sep 92 14:42:58 GMT
Article-I.D.: corvina.welch.716170558
Organization: Xerox PARC


I've posted a new version of the mxedit editor to
barkley.Berkeley.EDU:tcl/extensions/mxedit.tar.1.2.Z
parcftp.xerox.com:pub/mxedit/mxedit.tar.1.2.Z

mxedit is two things, an editable-text TK widget and an editor composed
around that widget.  It features an indefinite undo/redo log,
menus, shift-drag text scrolling, multiple views on a file,
session smarts to avoid conflicting edit sessions, and more.

Here are a summary of the things added for version 1.2:

This cleans up some lint and other objections raised by gcc.
Thanks for all the feedback on this.

The editor scripts are now organized in their own directory,
plus the standard TCL auto_load capabilities are used instead
of sourcing all of the scripts at startup.

The handling of the per-user .mxedit file is a little different.
See the sample.mxedit file for details.

A directory browser is available under the File menu.
Thanks go to David S. Herron <david@davids.mmdf.com>

Power-scrolling has been augmented so that if you shift-drag the mouse
out of the window you get a continuous scroll a la the Mac.

The X cutbuffer is supported for better cut/paste interoperability.

There are bindings for Sun4 keyboards that bind things like "Cut" and "Paste"

The emacs-like bindings are a bit better (but I could use more feedback)

The editor keeps track of different editing sessions and attempts
to avoid conflicting editing sessions.  When you start up an mxedit
process it checks the registered set of mxedit applications.  If it
finds a different mxedit process that is editing the same file it
will send the other process a command to display itself, and then
terminate (or go on to the next file).  This does not yet work
between machines, but it does work among different screens controlled
by the same server if you patch tkSend.c and replace all occurences of
DefaultRootWindow(dispPtr->display)
with
RootWindow(dispPtr->display, 0)
This patch ensures a single InterpRegistry property on screen 0 and allows
send to work between screens.

A simple database of editting sessions is maintained in
a dbm file, ~/.mxdb.{pag,dir}.  The contents of this database
are displayed by selecting the "Show session database" entry
under the Help menu.
An adjuct program, dbmDump, is used to print out the contents
of the per-user (~/.mxdb) or per-system registry of edit sessions.


--

	Brent Welch
Newsgroups: comp.lang.tcl
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Headless lines
Organization: Bellcore
Date: Sat, 12 Sep 92 18:46:33 GMT

I have a problem that didn't go away with the last upgrade. When ever I move a line, the heads (if there
are any) are left laying around on the canvas in the original position. Very disconcerting. Is there
a fix for this floating around anywhere?

Ross Huitt
bytor@ctt.bellcore.com

Newsgroups: comp.lang.tcl
From: selway@quark.uk.cray.com (Paul D Selway)
Subject: expect/tcl for MACs
Keywords: tcl expect MACs
Organization: Cray Research (UK) Ltd
Date: 14 Sep 92 08:42:27 CDT

Hi,

	Has anyone ported expect/tcl to a MAC?

regards

	Paul

Newsgroups: comp.lang.tcl
From: "David Herron" <david@twg.com>
Subject: Re: scrollbar styles
Sensitivity: Personal
Encoding:  18 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Thu, 10 Sep 1992 17:16:56 GMT

> Maybe it's just familiarity from longer use, but I find the Athena
> behaviour more convenient and richer than the up and down arrows
> at each end of the Tk scrollbars.

It probably is just familiarity from long term use.  I remember being confused
for a long time with Athena scrollbars since there is effectivly zero
visual indication of what can be done with them.

At least the Motif/TK scrollbars have an obvious way of indicating a way
to scroll the scrollbar.

BTW, Motif scrollbars also use the middle button to set the scrollbar to
an arbitrary point while TK does not.  For long lists (I have one list
which is >1500 entries long) it is faster to go directly to a particular
place in the list than it is to page or drag through the list to find 
the place.



<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- "ISO is really just another politically correct one-world fantasy
<-  of the U.N." -- Gordon McLachlan (LAN Computing, Aug 1992, p. 37)
From: rtor@ansa.co.uk (Owen Rees)
Newsgroups: comp.lang.tcl
Subject: Re: Inefficient string handling
Date: 14 Sep 92 14:38:57 GMT


walter!news@uunet.uu.net (Nathaniel Borenstein) writes:
> I recently had to write a Tcl procedure that took an arbitrary length
> string and made sure it was broken down into terminal-oriented line
> lengths.  The procedure I wrote turned out to be so mind-bogglingly slow
> that I ended up rewriting it in C and installing it via
> Tcl_CreateCommand.  However, I can't help thinking there MUST be a
> faster way to do this in tcl itself ...

Here is a faster way to do line wrapping. The results are not exactly
the same - this will split at the last space before 80 rather than the
first after 70 and it doesn't leave the trailing spaces on the split
lines.

proc wrap {txt} {
    set ans ""
    set index 0
    set len [string length $txt]
    while { $index < $len } {
        set line [string range $txt $index [expr $index+79]]
        if {[set split [string first "\n" $line]] == -1} {
            if {[set split [string last " " $line]] == -1} {
		set split 79
		incr index -1
	    }
	}
	append ans "[string range $line 0 [expr $split-1]]\n"
        incr index [expr $split+1]
    }
    return $ans
}

This uses the string searching commands to find where to make the next
split and then appends the whole chunk in one go. You have to copy the
next chunk each time because the search commands don't take a starting
index parameter (i.e. you can't search for the last space before the
80th character, only the last space in the string.)

Owen.

     /\/\	Owen Rees <rtor@ansa.co.uk>
    / /  \	APM, Poseidon House
   / / /\ \	Castle Park, Cambridge
  / / /\ \ \	CB3 0RD, UK
 / /_/__\ \ \	Phone:	+ 44 223 323010
/__________\_\	Fax:	+ 44 223 359779
  A  N  S  A
Newsgroups: comp.lang.tcl
From: garfield@cs.tu-berlin.de (Sven Delmas)
Subject: TkPixmap 1.1 released
Organization: Techn. Univ. Berlin (Germany)
Date: Tue, 8 Sep 1992 15:37:24 GMT

Hi,

I have just uploaded TkPixmap 1.1 to:
        barkley.berkeley.edu and
        coma.cs.tu-berlin.de
it should be available soon (right now it is in ./incoming :-).

This package contains a patch for tk 2.3, that makes it possible to
use color pixmaps as button labels (labels, button, checkbutton,
menubutton and radiobutton), and as canvas items (tag type bitmap).

Here some parts of the README:

this is the README for TkPixmap. This patch allows you to
use standard (monochrome) bitmaps AND (color) pixmaps in the
Xpm 3 format.

You can use the color pixmaps in buttons, menus and everywhere
where the -bitmap option is used. The changes to Tk 2.3 are on
a very low level, so that every program (widget) that uses the
standard Tk routines to handle the -bitmap resource can now use
bitmaps AND pixmaps. On the other hand the changes are
relatively small, and should not affect your daily work with Tk.
I make no guarantee that this patch works, but it works for me,
so it should work for you :-).

Requirements:
-------------
	- the Tk/Tcl package version 2.3.

	- the Xpm 3.0b package from GROUPE BULL
	  (BULL Research FRANCE -- Koala Project).
          The library is available at:
            avahi.inria.fr (138.96.24.30), or
            export.lcs.mit.edu

Availability:
-------------
TkPixmap is available via anonymous ftp at:
	coma.cs.tu-berlin.de: pub/tcl/TkPixmap1.1.tar.Z or
                              pub/tcl/TkPixmap.tar.Z (always the last release)
	barkley.berkeley.edu: tcl/code/TkPixmap1.1.tar.Z

Feedback (Author):
------------------
Sven Delmas
TU Berlin, Germany
garfield@cs.tu-berlin.de
--
----
  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: cid@wupost.wustl.edu (Central Inst for the Deaf)
Newsgroups: comp.lang.tcl
Subject: Variable Substitution: Help.
Date: 8 Sep 1992 22:25:00 -0500
Organization: Washington University in Saint Louis, MO
NNTP-Posting-Host: wugate.wustl.edu


Hi.

I'm having a problem getting variable substitution to work with
$w inside of command substitution brackets.
I want to have multiple instances of a dialog box, and need to pass
them unique names. However, the interpreter appears to take the
$w inside the brackets literally in the code below. 
Any help solving this problem would be appreciated.

thanks

djMeyer				"Way!" - Waynes World
djm@cidmv1.wustl.edu


  # build widget .frame5.button34
  button $w.frame5.button34 \
    -command {CTIrotate z [$w.frame5.entry33 get]} \
    -text {+}
From: B249236@vmtecqro.qro.itesm.mx (Elite of the NetWork)
Newsgroups: comp.lang.pascal
Subject: TVGraph compilation problems
Date: 8 Sep 92 21:29:05 GMT
Organization: Instituto Tecnologico de Monterrey, Campus Queretaro

Maybe this is a FAQ, but here it go:
I recently got TVGraph from wuarchive from the /tvision directory, but
when I tried to compile it under Turbo Pascal 6.0.  I get a error msg
from a undefined var or type.   Also the stxy.tpu file doesnt work under
Turbo Pascal 6.0
 
  Anyone knows where I can get a fix for tvgraph or a new version?
 
 
                                       Thanks in advance
Newsgroups: comp.lang.pascal
From: tech@crash.cts.com (Don Bontemps)
Subject: I need to direct screen output to printer.
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 10 Sep 92 01:44:25 PDT

Hello fellow pascal programmers.  My girlfriend is learning Turbo Pascal 6.0 in
college and she needs a way to send the screen output to the printer so her
teacher can see her program run.  I hear there is a program that other students
use to acomplish this.  Could someone please E-mail me the program or direct me
to where I may obtain it from.  Thanks (in advance)!
From: exuptr@exu.ericsson.se (exuptr@exu.ericsson.se)
Newsgroups: comp.lang.pascal
Subject: Re: OOps!  (was Re: Executable)
Date: 11 Sep 92 20:37:57 GMT
Organization: Ericsson Network Systems, Inc.

In article <10343@vice.ICO.TEK.COM> bobb@vice.ICO.TEK.COM (Robert Beauchaine) writes:
>From: bobb@vice.ICO.TEK.COM (Robert Beauchaine)
>Subject: Re: OOps!  (was Re: Executable)
>Date: 11 Sep 92 05:59:25 GMT

>In article <exuptr.474.716143462@exu.ericsson.se> exuptr@exu.ericsson.se (exuptr@exu.ericsson.se) writes:
>>>>Why not attach them to the .EXE?  It makes life a lot simpler for the user.
>>
>>Sure, if the person that asked the question knows how to do that.
>>

>  And if he didn't, he should spend some time RTFM'ng, where the
>  topic is covered well enough for the most unsophisticated user.
>  Or is that now Duncan's responsibility also?

This is totally irrelevant.  If you read the origional message you'd
understand how far in the trees you are.

Someone asked about whether or not they could just distribute the 
<program>.EXE file for their application, or did they need other
files.

I commented to point out that he would need to send the .OVL files
if he did create any.  Sure he could bind them to the exe also, but if
he didn't, then he didn't, and he needs to send the overlay files.

Sheesh!
 ----------------------------------------------------------------------------
    "This must be Thursday.  I never could get the hang of Thursdays"
                                                       - Douglas Adams
  - Patrick Taylor                                       (Arthur Dent)
    Ericsson Network Systems
    exuptr@exu.ericsson.se                       "Don't let the .se fool you"
    or exuptr@ZGNews.Lonestar.Org, exu.exuptr@memo.ericsson.se
Newsgroups: comp.lang.pascal