tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] TLS 1.4 - anyone have build / test problems?

[Jeffrey H. <jef...@aj...>]

Has anyone else had the opportunity to build and test the current CVS
of TLS 1.4?  Larry is reporting some test problems using OpenSSL 0.9.5a
on Solaris 2.6 with Tcl 8.3.2.  I need to have other positive or
negative results confirmation before I go public with 1.4.

BTW, Larry, could you run that again with:
	make test TESTFLAGS="-verbose bps"
so I know exactly which test bombed on you.

Thanks,

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: TLS 1.4 release imminent - sanity check

[Mac C. <ma...@sw...>]

Jeffrey Hobbs wrote:
> 
> I'm preparing to make a 1.4 release of TLS.  One big change is that
> TLS will no longer compile against Tcl 8.0-8.1.  I've added the
> following to the README.txt:
> 
8<------------------------------snip-------------------------------->8
> 
> I've dist'ed the current CVS, so you can grab the current sources by
> checking out the 'tls' module from the head.  If there aren't any
> problems reported soon, I'll be tagging this tls-1-4 and making a
> release.

Will a TLS 1.4 distribution be made available via the dev.scriptics.com
software library, i.e. outside of CVS?  Not everyone uses CVS or can't
use CVS due to firewall restrictions (as is my case).  It would be
appreciated!

> I was considering making some binary distributions using openssl, but
> apparently that would have restrictions because we compile a version
> that has patented stuff that couldn't be redistributed...  Oh well, I
> hear that after Sep. 20th things will loosen up on that front.

Yes, the patent for RSA will expire at that point.  The patents for
RC5 and IDEA will still be in effect.  A binary distribution of OpenSSL
that is patent-free can be created by running the configuration script:

  ./config no-rc5 no-idea

This, of course is only true after September 20, 2000.  Prior to that
date, that exercise is best left up to the interested user.

> Jeffrey Hobbs                     Tcl Ambassador
> ho...@Aj...          Ajuba Solutions (née Scriptics)

Thanks for the update,
 
Mac Cody

PS - Please note that my email address is now ma...@sw...

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: TLS 1.4 release imminent - sanity check

[Jeffrey H. <jef...@aj...>]

> From: mc...@mt...
	...
> Jeffrey Hobbs wrote:
> > 
> > I'm preparing to make a 1.4 release of TLS.  One big change is that
> > TLS will no longer compile against Tcl 8.0-8.1.  I've added the
	...
> Will a TLS 1.4 distribution be made available via the dev.scriptics.com
> software library, i.e. outside of CVS?  Not everyone uses CVS or can't
	...

Yes, a proper .tar.gz archive will be made available on the Scriptics
FTP site.  I was thinking of creating the URL:
	ftp://ftp.scriptics.com/pub/tcl/encryption/tls/tls1.4.tar.gz

Perhaps just "crypt" instead of "encryption"?  We're hoping to start
a proper archive of extensions, so something that would useful for
other extensions would be nice.  Of course, it would be nice to have
it web-driven, which might make the FTP url meaningless.

	...
> Yes, the patent for RSA will expire at that point.  The patents for
> RC5 and IDEA will still be in effect.  A binary distribution of OpenSSL
> that is patent-free can be created by running the configuration script:
> 
>   ./config no-rc5 no-idea
> 
> This, of course is only true after September 20, 2000.  Prior to that
> date, that exercise is best left up to the interested user.

Yeah, I think it would be nice to have a binary for major platforms,
but an openssl without RSA at this point would be rather useless...

Jeff

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] TLS 1.4 release imminent - sanity check

[Jeffrey H. <jef...@aj...>]

I'm preparing to make a 1.4 release of TLS.  One big change is that
TLS will no longer compile against Tcl 8.0-8.1.  I've added the
following to the README.txt:

  The TLS 1.4 release requires Tcl 8.2.0+, with 8.3.2+ preferred.  The
  stacked channel implementation in Tcl was originally introduced in 8.2.0
  (previously the Trf patch) and rewritten for 8.3.2+ due to inherent
  limitations in the earlier implementation.  TLS 1.4 should compile with
  any stubs-capable Tcl interpreter, but will require 8.2+ when loaded.
  There are known limitations in the 8.2.0-8.3.1 stacked channel
  implementation, so it is encouraged that people use TLS 1.4+ with an
  8.3.2+ Tcl interpreter.

I've added runtime checking of the channel version (thanks for the
code tips Andreas) to allow it to run in any 8.2.0+ Tcl interpreter.
I didn't try to support 8.0-8.1 because we know those have the same
limitations in the stacked channel implementation.  If people are
comfortable with using those, then TLS 1.3 has all the same
functionality.  TLS 1.4 is really meant for use with 8.3.2+, but
I added in 8.2.0-8.3.1 because you could make the runtime changes
work, and this allows people to compile with 8.2+ and have it work
with any 8.2+ interpreter (the test suites will crash if you use a
pre-8.3.2 interp though).  I've tested the last bits on Solaris and
NT with 8.2.0 and 8.3.2.

I've dist'ed the current CVS, so you can grab the current sources by
checking out the 'tls' module from the head.  If there aren't any
problems reported soon, I'll be tagging this tls-1-4 and making a
release.

I was considering making some binary distributions using openssl, but
apparently that would have restrictions because we compile a version
that has patented stuff that couldn't be redistributed...  Oh well, I
hear that after Sep. 20th things will loosen up on that front.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Does the Thread package work in Tcl 8.4?

[David G. <dav...@aj...>]

Mo DeJong <md...@cy...> wrote:

>Am I just missing something here? How can I detect
>if Tcl 8.3 was compiled with the --enable-thread
>option?
>
>Mo DeJong
>Red Hat Inc

I would love to see tclThreadTest.c yanked from the core ASAP and replaced with
the thread extension.  That old cruft has to go.

Mo, you can find thread 2.0 on the external cvs.  Just checkout module 'thread'.
--
  David Gravereaux <dav...@aj...>      Yet Another Tcl Guy
  Sustaining Engineer (Tech Support)                  Ajuba Solutions
  (650) 230-4079

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Does the Thread package work in Tcl 8.4?

[Mo D. <md...@cy...>]

I am reading these docs about "Thread 2.0".

http://dev.scriptics.com/doc/howto/thread_model.html

That seems to imply I should be able to do a
"package require Tcl 2.0", but when I do that
I get this error:

% package require Thread 2.0
version conflict for package "Thread": have 1.0, need 2.0

( I am running this with "make runtest" by the way )


The only place this seems to be defined is in tclThreadTest.c:

int
TclThread_Init(interp)
    Tcl_Interp *interp; /* The current Tcl interpreter */
{
    
    Tcl_CreateObjCommand(interp,"testthread", Tcl_ThreadObjCmd, 
	    (ClientData)NULL ,NULL);
    if (Tcl_PkgProvide(interp, "Thread", "1.0" ) != TCL_OK) {
	return TCL_ERROR;
    }
    return TCL_OK;
}


When I run this in "normal" tclsh, I get this error:

% package require Thread
can't find package Thread

Am I just missing something here? How can I detect
if Tcl 8.3 was compiled with the --enable-thread
option?

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Translation + I10N

[Jan N. <j.n...@ch...>]

ldu...@sp... wrote:
> One issue is what to do if -underline and \_ are used simultaneously.

I think it would be OK to produce an error-message in this case. Use
of "-underline" should be deprecated in 8.4 anyway.

Regards,
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Translation + I10N

[<ldu...@sp...>]

Hi,

As you may have noticed, I've been pretty quiet of late. A combination
of vacations and extra work at the office is to blame. I've been
monitoring clt enough to see that noone seems to ave tried to attack the
-underline and the associated binding problem.

I think I'll try Jan's proposition (use \_) to begin. It requires a
small change to Tcl and another change to the way Tk displays text in
the buttons and stuff. I can try to figure out where that piece of code
is, but if one of you can point me to the proper location (I don't know
the Tk code that well yet) it could save me some time. Maybe not, who
knows.

Using this approach, I could always extend msgcat to know what the
binding for a string should be. Somthing like

set key [::msgcat::bindkey $string]
bind <Alt-$key> ....

proc ::msgcat::bindkey {string} {
  set idx [string first "\_" $string]
  if {$idx > 0} {
    return [string index $string [expr {$idx-1}]]
  }
}

or something. 

One issue is what to do if -underline and \_ are used simultaneously.

L

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Something is very wrong in Tcl_InitHashTable.

[Eric M. <er...@aj...>]

Whoops, I forgot to append my simple test:

-----------------------------------------

#include <tcl.h>
static Tcl_HashTable table;

int Test_Init(interp)
    Tcl_Interp *interp;
{
    Tcl_PkgProvide(interp, "test", "0.1");
    Tcl_InitHashTable(&table, TCL_STRING_KEYS);
    return TCL_OK;
}
    
-----------------------------------------

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Something is very wrong in Tcl_InitHashTable.

[Eric M. <er...@aj...>]

On Wed, 9 Aug 2000, Mo DeJong wrote:

> There seems to be a core dumping bug in Tcl_InitHashTable that
> it only appears in 8.4. I can run the exact same code
> in Tcl 8.3 with no problems.

Mo -

I'm unable to reproduce this on my system.  I tried it with TkGS, and with
a simple test case (included below), and I saw no core dump in either
case.  I'm using a fresh checkout of Tcl/Tk 8.4 and TkGS from CVS, on a
RedHat 6.0 system.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Trf 2.1 release /pre1, request for feedback

[Andreas K. <a.k...@we...>]

I have placed a pre-release of the upcoming Trf 2.1 at

	http://www.purl.org/NET/akupries/noway/trf2.1.tar.bz2
and	http://www.purl.org/NET/akupries/noway/trf2.1.tar.gz

This release adapts Trf to the rewritten functionality of stacked
channels of Tcl 8.3.2. Actually a binary compiled against any version
of the core from 8.1 upward (having stubs) should work with any other
stubbed core regardless of version and switching its behaviour at
runtime as necessary [*].

I tried the above with 8.1.1, 8.2.3 and 8.3.2., compilation is ok and
testsuite passed for any combination. Additionally I compiled and
tested with 8.0.5. too, again ok.

Nevertheless I would like to get some more feedback for different
machines and OS's before doing the official release (I personally am
restricted to a Linux 2.0.29 Intel system).


~~~
[*] See generic/transformInt.h and generic/registry.c for the required
    voodoo.

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] ANNOUNCE: Tcl/Tk 8.3.2 Release

[Jeffrey H. <jef...@aj...>]

Tcl/Tk 8.3.2 Release Announcement
August 9, 2000

We are pleased to announce the 8.3.2 releases of the Tcl scripting
language and the Tk toolkit.  This is the second patch release of
Tcl/Tk 8.3. More details can be found below.  We'd like to thank all
those that submit bugs and patches as they are the primary source of
information for us to identify problems in the core.

Where to get the new releases:
------------------------------

Tcl/Tk 8.3.2 are freely available in open source from the
Ajuba Solutions web site at

        http://dev.scriptics.com/software/tcltk/8.3.html

This web page also contains additional information about the
releases, including new features and notes about installing and
compiling the releases.

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

        http://dev.scriptics.com/

This site contains a variety of information about Tcl/Tk in general,
the core Tcl and Tk distributions, the TclPro tool suite, and much more.

Thank you for your contributions:
---------------------------------
As usual, this release includes contributions from the Tcl community.
We have a page honoring these contributions at:

        http://dev.scriptics.com/software/tcltk/contributors.html

Summary of Changes since Tcl/Tk 8.3.1:
--------------------------------------

The following were the main changes in Tcl/Tk 8.3.2.  A complete list can
be found in the changes file at the root of the source tree.  The more
complete ChangeLog is also included with each release.  This is a patch
release, so it primarily included bug fixes and corrections to erratic
behavior.  Below are only the most notable changes.

1. Corrected resource cleanup in http error cases, and improved handling of
   error cases in http.

2. Complete rewrite of the Tcl IO channel subsystem to correct problems
   (hangs, core dumps) with the initial stacked channel implementation.
   The new system has many more tests for robustness and scalability.
   There are new C APIs (see Tcl_CreateChannel), but only stacked channel
   drivers are affected (ie: TLS, Trf, iogt).  New releases of stacked
   channel drivers should follow this release.
	**** POTENTIAL INCOMPATABILITY ****

3. Improved build support for gcc for Windows (Tcl and Tk).

4. Corrected setlocale calls for XIM support and locale issues during
   initialization.

5. Corrected code to handle locale specific return values from strftime.

6. Fixed clock grammar to properly handle the "ago" keyword when it follows
   multiple relative unit specifiers, as in "2 days 2 hours ago".

7. Numerous doc fixes to correct SEE ALSO and NAME sections.

8. New man pages for memory.n, TCL_MEM_DEBUG.3, Init.3 and
   DumpActiveMemory.3.

9. Changed Windows [wm deiconify] from using idle callback to calling
   restack and focus code immediately.

10. Fixed Windows menu code for correct drawing of separator menu entries,
    disabled menu entries and the height for separator bars.

11. Fixed calling of takeFocus proc with arg bearing functions.

12. For text widgets, added a test for a NULL segment pointer when doing
    backwards searches for "", correct searching over elided chars, and
    corrected search combining -regexp and -nocase.

13. Corrected code for using [place], cursors, colors and 3D borders on
    multiple screens simultaneously.

-- 
   Jeffrey Hobbs                     Tcl Ambassador
   hobbs at ajubasolutions.com       Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Trf 2.1 release /pre1, request for feedback

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

I have placed a pre-release of the upcoming Trf 2.1 at

	http://www.purl.org/NET/akupries/noway/trf2.1.tar.bz2
and	http://www.purl.org/NET/akupries/noway/trf2.1.tar.gz

This release adapts Trf to the rewritten functionality of stacked
channels of Tcl 8.3.2. Actually a binary compiled against any version
of the core from 8.1 upward (having stubs) should work with any other
stubbed core regardless of version and switching its behaviour at
runtime as necessary [*].

I tried the above with 8.1.1, 8.2.3 and 8.3.2., compilation is ok and
testsuite passed for any combination. Additionally I compiled and
tested with 8.0.5. too, again ok.

Nevertheless I would like to get some more feedback for different
machines and OS's before doing the official release (I personally am
restricted to a Linux 2.0.29 Intel system).


~~~
[*] See generic/transformInt.h and generic/registry.c for the required
    voodoo.

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[TCLCORE] Re: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Mo D. <md...@cy...>]

On Wed, 9 Aug 2000, Brent Welch wrote:

> I'd be extremely cautious about changing the way TCL_DBGX works -
> it's pretty delicate.  I am continually building both debug and non-debug
> versions of Tcl and loads of extensions for TclPro, and never have a problem.
> I suspect it may be in the way tkgs tries to use the macros more than
> the way Tcl defines them.  

I still say this whole DBGX thing is a mess but I guess we will have
to deal with it in 8.4. Jeff is correct, this should not hold up
the release, one can always compile without --enable-debug :)

By the way, here is what shows up in the tkConfig.sh file:

# The name of the Tk stub library (.a):
TK_STUB_LIB_FILE='libtkstub8.3g.a'

# -l flag to pass to the linker to pick up the Tk stub library
TK_STUB_LIB_FLAG='-ltkstub8.3g'

# String to pass to linker to pick up the Tk stub library from its
# build directory.
TK_BUILD_STUB_LIB_SPEC='-L/home/mo/project/build/tk_83 -ltkstub8.3g'


Note the lack of ${TCL_DBGX}.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Tcl/Tk 8.3.2 is FINAL - going out today

[Jeffrey H. <jef...@aj...>]

After looking into the issues, the confusion about whether the use
of TCL_DBGX is correctly created or not is not going to delay the
8.3.2 release.  I ran a test build of Tcl, Tk and TLS (as a sample
outside extension) and all worked fine with the use of --enable-symbols.

There may be improvements that we can still make, but I'm very
hesitant to touch such a sensitive spot so soon before a release.

Andreas also had another note about enhancing the docs, but that is
just as easy to go into 8.3.3/8.4 as a doc enhancement.

We should have the release out later today, barring any further
trouble reports.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Brent W. <we...@aj...>]

I'd be extremely cautious about changing the way TCL_DBGX works -
it's pretty delicate.  I am continually building both debug and non-debug
versions of Tcl and loads of extensions for TclPro, and never have a problem.
I suspect it may be in the way tkgs tries to use the macros more than
the way Tcl defines them.  

If the tclConfig.sh contains
TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'

then you need to have TCL_DBGX be set to "g" to pick up the right library.
It would be best to understand why you've built a tclstub8.3g.a but
are using a tclConfig.sh that doesn't define TCL_DBGX to be "g".
On possibility is that you've done multiple compiles of tcl, both with
and without debugging symbols.  Watch out here because the last compile
will install something into the installed lib directory 
(win32-ix86/lib/tclConfig.sh)
but for most reliable results you'll want the tclConfig.sh from
the Tcl build directory that matches the configuration you want.

In otherwords, for my TclPro builds, I'm always doing
--with-tcl=<the build directory>
and never letting this default to the installed lib directory.


Also, you suggest evaling the reference to TCL_DBGX in the Tcl configure,
but the whole point of quoting it is that you can tweak the TCL_DBGX setting
much later when you compile your extention to select exactly what you want.
Perhaps you just need to hammer in the value you want for TCL_DBGX
in the tkgs configure, and then do the eval on it.  This'll let you
select an arbitrary combination of debugging/non-debugging Tcl libraries
and debugging/non-debugging tkgs libraries.

Please - let's not change this right now for 8.3.2

>>>Mo DeJong said:
 > On Tue, 8 Aug 2000, Mo DeJong wrote:
 > 
 > > On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:
 > > 
 > > > The code in the core-8-3-1-branch (readying for 8.3.2) should be
 > > > considered final.  Eric and I will be putting the code through
 > > > its drills on Tuesday, with the hope that we'll have a Wednesday
 > > > release of Tcl/Tk 8.3.2.
 > > > 
 > > > A few files related to release work (tcl.wse.in and such) may be
 > > > edited, as will 'changes' for the release notes, but aside from
 > > > that I expect everything is ready to go.
 > > > 
 > > > If anyone spots any serious problems with the current state of
 > > > core-8-3-1-branch (for tcl or tk), raise the red flag before
 > > > Wednesday morning.
 > > 
 > > 
 > > Well, this really is down to the wire, but...
 > > 
 > > There is a problem with the tclConfig.sh file generated by
 > > Tcl 8.3.2.
 > > 
 > > (from tclConfig.sh)
 > > 
 > > # -l flag to pass to the linker to pick up the Tcl stub library
 > > TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'
 > > 
 > > (from tkConfig.sh)
 > > TK_STUB_LIB_FLAG='-ltkstub8.3g'
 > > 
 > > This means that if you compile with debug symbols enabled,
 > > an extension that tries to link to Tcl's stub libs will
 > > generate an error like so:
 > > 
 > > gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
 > > tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
 > > drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
 > > -L/home/mo/project/build/tcl_83 -ltclstub8.3 
 > > -L/home/mo/project/build/tk_83 -ltkstub8.3g
 > > /usr/bin/ld: cannot find -ltclstub8.3
 > > collect2: ld returned 1 exit status
 > 
 > 
 > Looks like I was a bit too quick with that patch.
 > This one should really fix the problem.
 > 
 > Index: configure.in
 > ===================================================================
 > RCS file: /home/cvs/external/tcl/unix/configure.in,v
 > retrieving revision 1.57.2.1
 > diff -u -r1.57.2.1 configure.in
 > --- configure.in        2000/07/27 01:39:22     1.57.2.1
 > +++ configure.in        2000/08/09 06:57:10
 > @@ -527,12 +527,12 @@
 >  
 >  MAKE_STUB_LIB="ar cr \${STUB_LIB_FILE} \${STUB_LIB_OBJS}"
 >  
 > -TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
 > +eval TCL_STUB_LIB_FILE=\"${STUB_LIB_FILE}\"
 >  
 >  if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
 > -    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
 > +    eval TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 >  else
 > -    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}
     "
 > +    eval TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_D
     BGX}
 > "
 >  fi
 >  
 >  TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"
 > 
 > 
 > Mo DeJong
 > Red Hat Inc
 > 
 > --
 > The TclCore mailing list is sponsored by Ajuba Solutions
 > To unsubscribe:  email tcl...@aj... with the 
 >                  word UNSUBSCRIBE as the subject.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Something is very wrong in Tcl_InitHashTable.

[Mo D. <md...@cy...>]

There seems to be a core dumping bug in Tcl_InitHashTable that
it only appears in 8.4. I can run the exact same code
in Tcl 8.3 with no problems.

Here is the bit that crashes:

static Tcl_HashTable driverTable;

int TkGSInitDriverTable() {
  Tcl_InitHashTable(&driverTable, TCL_STRING_KEYS);
}

This is from the tkgs module, you can check it out
of the Net CVS using the module name "tkgs".


GDB prints a backtrace like this from the crash:

#0  0x401ab967 in TclDatedef () from 
/usr/local/project/install/Tcl/lib/libtcl8.4g.so
#1  0x403a1e1b in TkGSInitDriverTable () at 
/home/mo/project/tkgs/src/generic/tkgsDriver.c:14


I think this was caused by Paul's recent Hashtable
changes.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: stacked channel docs

[Andreas K. <a.k...@we...>]

> I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
> Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
> concerned might want to check them out just in case I sound off-my-rocker.
> They are in the core-8-3-1-branch, not yet in the HEAD.

I think the section about the HandlerProc should mention that the return
value is the mask minus all the events processed by the transformation itself.

The rest looks good.

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Mo D. <md...@cy...>]

On Tue, 8 Aug 2000, Mo DeJong wrote:

> On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:
> 
> > The code in the core-8-3-1-branch (readying for 8.3.2) should be
> > considered final.  Eric and I will be putting the code through
> > its drills on Tuesday, with the hope that we'll have a Wednesday
> > release of Tcl/Tk 8.3.2.
> > 
> > A few files related to release work (tcl.wse.in and such) may be
> > edited, as will 'changes' for the release notes, but aside from
> > that I expect everything is ready to go.
> > 
> > If anyone spots any serious problems with the current state of
> > core-8-3-1-branch (for tcl or tk), raise the red flag before
> > Wednesday morning.
> 
> 
> Well, this really is down to the wire, but...
> 
> There is a problem with the tclConfig.sh file generated by
> Tcl 8.3.2.
> 
> (from tclConfig.sh)
> 
> # -l flag to pass to the linker to pick up the Tcl stub library
> TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'
> 
> (from tkConfig.sh)
> TK_STUB_LIB_FLAG='-ltkstub8.3g'
> 
> This means that if you compile with debug symbols enabled,
> an extension that tries to link to Tcl's stub libs will
> generate an error like so:
> 
> gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
> tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
> drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
> -L/home/mo/project/build/tcl_83 -ltclstub8.3 
> -L/home/mo/project/build/tk_83 -ltkstub8.3g
> /usr/bin/ld: cannot find -ltclstub8.3
> collect2: ld returned 1 exit status


Looks like I was a bit too quick with that patch.
This one should really fix the problem.

Index: configure.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/configure.in,v
retrieving revision 1.57.2.1
diff -u -r1.57.2.1 configure.in
--- configure.in        2000/07/27 01:39:22     1.57.2.1
+++ configure.in        2000/08/09 06:57:10
@@ -527,12 +527,12 @@
 
 MAKE_STUB_LIB="ar cr \${STUB_LIB_FILE} \${STUB_LIB_OBJS}"
 
-TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
+eval TCL_STUB_LIB_FILE=\"${STUB_LIB_FILE}\"
 
 if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
-    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
+    eval TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 else
-    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
+    eval TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_DBGX}
"
 fi
 
 TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"


Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Mo D. <md...@cy...>]

On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:

> The code in the core-8-3-1-branch (readying for 8.3.2) should be
> considered final.  Eric and I will be putting the code through
> its drills on Tuesday, with the hope that we'll have a Wednesday
> release of Tcl/Tk 8.3.2.
> 
> A few files related to release work (tcl.wse.in and such) may be
> edited, as will 'changes' for the release notes, but aside from
> that I expect everything is ready to go.
> 
> If anyone spots any serious problems with the current state of
> core-8-3-1-branch (for tcl or tk), raise the red flag before
> Wednesday morning.


Well, this really is down to the wire, but...

There is a problem with the tclConfig.sh file generated by
Tcl 8.3.2.

(from tclConfig.sh)

# -l flag to pass to the linker to pick up the Tcl stub library
TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'

(from tkConfig.sh)
TK_STUB_LIB_FLAG='-ltkstub8.3g'

This means that if you compile with debug symbols enabled,
an extension that tries to link to Tcl's stub libs will
generate an error like so:

gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
-L/home/mo/project/build/tcl_83 -ltclstub8.3 
-L/home/mo/project/build/tk_83 -ltkstub8.3g
/usr/bin/ld: cannot find -ltclstub8.3
collect2: ld returned 1 exit status

(Note how the g is not added in the Tcl case)

% ls /home/mo/project/build/tcl_83/libtclstub8.3g.a 
/home/mo/project/build/tcl_83/libtclstub8.3g.a

( This same problem shows up in 8.4 CVS by the way ).

So the question is, do we really want to use \${TCL_DBGX}
in configure.in?

if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
else
    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
fi


Note how Tk's configure.in uses an eval, which would
do the same thing (without escaping the $).

if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
    eval TK_STUB_LIB_FLAG="-ltkstub${TK_VERSION}\${TK_DBGX}"
else
    eval TK_STUB_LIB_FLAG="-ltkstub`echo ${TK_VERSION} | tr -d .`\${TK_DBGX}"
fi


After making this change, I was able to compile and run tkgs with Tcl 8.3.

Index: configure.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/configure.in,v
retrieving revision 1.57.2.1
diff -u -r1.57.2.1 configure.in
--- configure.in        2000/07/27 01:39:22     1.57.2.1
+++ configure.in        2000/08/09 04:58:13
@@ -530,9 +530,9 @@
 TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
 
 if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
-    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
+    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 else
-    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
+    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_DBGX}"
 fi
 
 TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: stacked channel docs

[Andreas K. <a.k...@we...>]

--------
> I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
> Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
> concerned might want to check them out just in case I sound off-my-rocker.
> They are in the core-8-3-1-branch, not yet in the HEAD.

I think the section about the HandlerProc should mention that the return
value is the mask minus all the events processed by the transformation itself.

The rest looks good.

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[TCLCORE] Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Jeffrey H. <jef...@aj...>]

The code in the core-8-3-1-branch (readying for 8.3.2) should be
considered final.  Eric and I will be putting the code through
its drills on Tuesday, with the hope that we'll have a Wednesday
release of Tcl/Tk 8.3.2.

A few files related to release work (tcl.wse.in and such) may be
edited, as will 'changes' for the release notes, but aside from
that I expect everything is ready to go.

If anyone spots any serious problems with the current state of
core-8-3-1-branch (for tcl or tk), raise the red flag before
Wednesday morning.

Thanks,

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] stacked channel docs

[Jeffrey H. <jef...@aj...>]

I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
concerned might want to check them out just in case I sound off-my-rocker.
They are in the core-8-3-1-branch, not yet in the HEAD.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Labeled frames (fwd)

[Eric M. <er...@aj...>]

Comments?

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

---------- Forwarded message ----------
Date: Fri, 28 Jul 2000 10:37:18 +0200 (MET DST)
From: Peter Spjuth <d1...@dt...>
To: Eric Melski <er...@aj...>
Subject: Re: Labeled frames (fwd)

> For
> example, instead of introducing 4 new fields for internal borderwidth, why
> not just two, overrideInternalBorderWidth and
> overrideInternalBorderWidthSide?  The first indicates an overriding value
> for the internal borderwidth, the second indicates to which side that
> value applies.  Only if the second is set to some meaningful value (ie,
> top, bottom, left, or right) is it used; otherwise, everything behaves
> exactly as before.

Yes, that is also possible, and I've thought some about that solution.
Here are my views of it compared to the solution in my patch:

1. A benefit is that it saves memory since only two fields are added to the
   TkWindow struct. 
2. It is still not backwards compatible and writing a geometry manager that
   is both 8.3 and 8.4 compatible would still be about as tricky.
   I can't see any difference between them in this aspect, but if I miss
   something, please let me know.
3. It is more complex and a bit harder to use for the geometry managers.
   To look up the left side width you'd need something like 
   field1 + (field2 == LEFT ? field3 : 0)
   instead of just looking up the left field.
4. It is less general, e.g. it does not allow for adding -padx/y options.
   That I like a general solution should be rather clear by now, but
   specifically I would find -padx/y very useful.

2. is the most important point, but since I can't see any difference there
I let the others decide. I think 1. is too small a benefit to justify 3. and 
4., so I still prefer mine.

Hmm, I'll try to put some of my thoughts about 2. into ascii.

For an extension implementing a geometry manager (which I think is the main
thing that are interested in this) I get the following relationship 
between versions:

One field for each side solution:

Ext  Core  
8.4  8.4 : Works easily.
8.4  8.3 : The extension needs to detect 8.3 and use the deprecated field.
8.3  8.4 : Works, as long as new frame stuff is not used.

Two new fields solution:

Ext  Core  
8.4  8.4 : Works easily, though not as easy as the other.
8.4  8.3 : The extension needs to detect 8.3 and not use the new fields.
8.3  8.4 : Works, as long as new frame stuff is not used.

So, you can see why I don't see much difference there.

I hope the above makes some sense, otherwise ask.

And I agree that this needs more discussion.
 
/Peter

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Documentation

[Larry W. V. <lv...@ca...>]

The only reason I suggested POD is because that is here now - the
XML has been something discussed for what, almost 2 years now.  A number
of people have put effort into it.  Perhaps it is just too large a task
to take on. 

-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.