tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: Fwd: -underline patch [tcl gateway]

[Scott S. <st...@aj...>]

Laurent Duperval said:

 > As promised, here is the patch for adding the \_ sequence to Tcl and 
doing
 > the underlining in Tk.

This is a great idea!  It's taking advantage of some features in Unicode 
to finesse the whole underline issue.  The concept is quite elegant, 
really.  I do have a few comments about the implementation though:

- If you are adding \_ to the Tcl backslash parser, you need to do the 
same thing for the regexp backslash parser.

- Rather than putting a constant like 0x332 directly in the code, it might 
be better to add a #define for TCL_COMBINING_LOW_LINE (the official 
Unicode character name).

- Don't assume that the \_ character actually takes 2 bytes.  This is only 
true if the string is in canonical UTF form.  It's actually possible to 
represent a \_ with 3 or more bytes in a non-canonical form.  Always use 
the Tcl UTF functions to compute character offsets.

- Your algorithm ends up scanning the string twice.  It would be faster to 
skip the call to Tcl_UtfFindFirst() and just do character by character 
comparisons.

- If you remove the \_ from the original text string, then a cget -text 
won't return the correct value.  You need to make a separate copy of the 
string for rendering purposes.

- If you were going to update the string in place, you should call 
Tcl_SetObjLength to set the new length.


For illustrative purposes, here is a revised ButtonComputeUnderline 
function.  It hasn't been tested (and so is probably wrong in some 
places), and it assumes the addition of a butPtr->textDisplayPtr field to 
hold the display string.  It does demonstrate the correct way to process 
the UTF data, though.  Note the use of Tcl_GetStringFromObj to get the 
length in bytes in addition to the string pointer.

/*
 *----------------------------------------------------------------------
 *
 * ButtonComputeUnderline --
 *
 *	This procedure calculates the position of the character to underline
 *	by examining the string and looking for the Unicode combining
 *      underline character.
 *
 * Results:
 *	None.
 *
 * Side effects:
 *	The value of butPtr->underline is changed to reflect the position
 *	of the combining underline character.  The \_ is removed from the
 *      the string and the new value is stored in butPtr->textDisplayPtr.
 *
 *----------------------------------------------------------------------
 */

static void
ButtonComputeUnderline (butPtr)
    TkButton *butPtr;   /* The button pointer */
{
    int length;
    char *s, *first, *buf;
    int tail, index, offset;
    Tcl_UniChar ch;

    /*
     * If the string contains the Unicode combining underline character,
     * reset the -underline switch to the preceding character position
     * and remove it from the string.  A leading underline turns off
     * underlining by setting -underline to -1.
     */
    
    s = Tcl_GetStringFromObj(butPtr->textPtr, &length);
    first = s;
    index = -1;
    while (*first != NULL) {
        offset = Tcl_UtfToUniChar(first, &ch);
        tail = first + offset;
        if (ch == TCL_COMBINING_LOW_LINE) {
            /*
             * Copy the text string without the \_ into the display string.
             */

	    Tcl_SetObjLength(butPtr->textDisplayPtr, length-offset);
	    buf = Tcl_GetString(butPtr->textDisplayPtr);
	    memcpy(buf, s, first-s);
	    memcpy(buf+(first-s), tail, length - (tail - s));

            butPtr->underline = index;
            break;
        }
        first = tail;
        index++;
    }
}

--Scott


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

[TCLCORE] Fwd: -underline patch [tcl gateway]

[Laurent D. <lau...@ne...>]

For those who don't read clt on a regular basis, here is a patch for
underlining which allows one to underline a character without needing to
know it's numeric position in the string. To use it, apply the patch and try
something  like this:

    button .b -text "ab\_c" ; # underlines b, -underline set to 1
    .b configure -text "\_abc"; # No underline, -underline set to -1
    .b configure -textvariable foo
    set foo "123\_"; # Underlines 3
    set foo "123 \_456"; # Underlines " "
 
This should help Keiichi Takahashi and George Petasis underline the proper
characters in their respective fonts. Let me know what the bugs are. If
possible, send your comments on clt so other people can reply as well. I
don't know anything about Unicode and its pitfalls so any big problem I
won't be able to solve without external help.

L

------ Forwarded message ------
      From: Laurent Duperval <lau...@Ne...>
   Subject: -underline patch [tcl gateway]
      Date: Tue, 22 Aug 2000 07:52:33 -0400 (EDT)
        To: lau...@Ne...
  Reply-To: ldu...@sp...
Newsgroups: comp.lang.tcl

As promised, here is the patch for adding the \_ sequence to Tcl and doing
the underlining in Tk.

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@ne...           Penguin Power!

[TCLCORE] Re: Unicode and Utf in Tcl

[Laurent D. <lau...@ne...>]

On 21 Aug, Scott Stanton wrote:
> I don't know of a good document that summarizes Tcl's character set 
> handling features.  However, I should be able to answer your specific 
> questions.  Tcl uses UTF8 internally as the standard string 
> representation.  It also supports two other internal representation types: 
> Unicode and binary.  The only interfaces that expect anything other than 
> UTF8 are those specific to the Unicode or binary types.  The internal 
> implementation of the regular expression engine also expects to operate on 
> Unicode strings.  Other than that everything operates in terms of null 
> terminated UTF8 strings.  Tcl does support ASCII because ASCII is a strict 
> subset of UTF8.  When it doesn't support directly any longer is ISO8859-1 
> (Latin 1).  The upper 128 characters now result in two byte UTF8 
> sequences.  You need to perform an encoding conversion before passing 
> Latin 1 strings into Tcl.
> 

Hmmm... that's what I thought... Hmm, I was getting behaviour that I wasn't
expecting while implementing my -text and -underline patch. I thought I
wasn't working with it properly but now it looks like it's a coding error on
my part. I'll investigate further.

Thanks,

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@ne...           Penguin Power!




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

[TCLCORE] makefile.vc rewrite time. where do we go from here?

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

After learning all the tricks TclPro does to make wacky flavors of shells, I
decided to get Tcl's makefile.vc to be more friendly and act sort of like a
combination './configure [options]; make' by taking ALL the previously hand
edited options and putting them on the commandline.  So I can now invoke it
like this:

 nmake -nologo -f makefile.vc STATIC_BUILD=1 NODEBUG=0 TCL_THREADS=1
TCL_MEM_DEBUG=1 ...

I have it mostly working, but there's a few problems with win/tclAppInit.c .  I
want to drop this into Tcl_AppInit:

#ifdef STATIC_BUILD
#ifdef USE_REG_EXT
    if (Registry_Init(interp) == TCL_ERROR) {
	return TCL_ERROR;
    }
    Tcl_StaticPackage(interp, "registry", Registry_Init,
            Registry_Init);
#endif
#ifdef USE_DDE_EXT
    if (Dde_Init(interp) == TCL_ERROR) {
	return TCL_ERROR;
    }
    Tcl_StaticPackage(interp, "dde", Dde_Init, Dde_Init);
#endif
#if defined(USE_THREAD_EXT) && defined(TCL_THREADS)
    if (Thread_Init(interp) == TCL_ERROR) {
	return TCL_ERROR;
    }
    Tcl_StaticPackage(interp, "Thread", Thread_Init, Thread_Init);
#endif
#endif /* STATIC_BUILD */

But I don't know if I should.  Are the core extensions {dde,reg,thread} moving
to a different location in the source tree?  Should we stick these hooks in the
core's win/tclAppInit.c anyways?  Without this patch, I can't make a fully
complete static shell from the codebase as is.

If we are to move the location of the core's extensions, where should they go?

   tcl
    |
    + -- coreX.X.X  <- name depends on CVS tag or release or whatever
    |      |
    |      + -- compat
    |      + -- doc
    |      + -- generic
    |      + -- library
    |      + -- mac
    |      + -- test
    |      + -- tools
    |      + -- unix
    |      + -- win
    |
    + -- <pick_a_name>
           |
           + -- thread
           |     + -- generic
           |     + -- doc
           |     + -- test
           |     + -- unix
           |     + -- win
           |
           + -- dde
           |     + -- win
           |
           + -- reg
                 + -- win

How's that?
--
  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]

[Cristiano B. <c.b...@li...>]

Dear Sirs,

I would like to use the new tk 4.2 widgets,
but, since they will not be avaible till next year,
I would like to find the tk extension library that is closer
to the 4.2 version. Is there any ?

Thanks a lot in advance.
Best Regards

Cristiano Bernini
---------------------------------------
Cristiano Bernini [cbe...@io...]
ION Trading Systems srl
Piazza Facchini 10, 56125 Pisa (Italy)
Tel. (+39) 050 916323 [Fax: 050 500697]
---------------------------------------

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

[TCLCORE] Unicode and Utf in Tcl

[Laurent D. <lau...@ne...>]

Hi,

I'm asking here because I'm having a little trouble sending to clt. *Sigh*,
I'll have to start working on that NNTP gatherer thingie...

Is there a document that summarises the interactions between Unicode, UTF8
and ASCII in Tcl? Specifically, when do I know that I'm dealing with a UTF
string and when am I dealing with a Unicode string? I think we don't do
ASCII anymore, right?

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@ne...           Penguin Power!



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

[TCLCORE] Re: Unicode and Utf in Tcl

[Scott S. <st...@aj...>]

Laurent Duperval said:
 > Hmmm... that's what I thought... Hmm, I was getting behaviour that I 
wasn't
 > expecting while implementing my -text and -underline patch. I thought I
 > wasn't working with it properly but now it looks like it's a coding 
error on
 > my part. I'll investigate further.

One thing to watch out for is that Tcl is liberal in what it will accept 
as input.  In UTF-8 all characters > 127 are part of a multi-byte 
sequence.  They begin with a lead byte and are followed by one or more 
trail bytes.  There is a specific bit pattern used to indicate whether a 
byte is a lead or trail byte.  If you pass Latin-1 (or any other format) 
to Tcl, it will try to interpret it as UTF8.  ASCII characters retain 
their meaning in UTF8.  One of two things will happen to non-ASCII 
characters.  If they happen to form a valid lead/trail byte sequence, then 
multiple characters in the original string will collapse into a single 
UTF8 character.  If they don't form a valid UTF sequence, then Tcl 
interprets them as single Latin-1 characters.   So, if you pass latin-1 
text into Tcl, you may think you've done an encoding conversion when you 
haven't because Tcl is accepting the malformed data and doing its best to 
handle it.

This was done for backwards compatibility reasons, but in retrospect I 
think it was a mistake.  It tends to mask errors because most Latin-1 
strings don't form valid UTF8 sequences.  The cases where multiple bytes 
happen to collapse to a single character are less common and may not show 
up during initial testing.  The simplest way to check to see if you've 
done the encoding conversion correctly is to compare "string length" and 
"string bytelength" for a string that is known to contain characters > 
127.  They two lengths returned should be different in this case.  If they 
are the same, then you are dealing with invalid UTF data.

--Scott


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

[TCLCORE] Re: Unicode and Utf in Tcl

[Scott S. <st...@aj...>]

Laurent Duperval said:
 > Is there a document that summarises the interactions between Unicode, 
UTF8
 > and ASCII in Tcl? Specifically, when do I know that I'm dealing with a 
UTF
 > string and when am I dealing with a Unicode string? I think we don't do
 > ASCII anymore, right?

I don't know of a good document that summarizes Tcl's character set 
handling features.  However, I should be able to answer your specific 
questions.  Tcl uses UTF8 internally as the standard string 
representation.  It also supports two other internal representation types: 
Unicode and binary.  The only interfaces that expect anything other than 
UTF8 are those specific to the Unicode or binary types.  The internal 
implementation of the regular expression engine also expects to operate on 
Unicode strings.  Other than that everything operates in terms of null 
terminated UTF8 strings.  Tcl does support ASCII because ASCII is a strict 
subset of UTF8.  When it doesn't support directly any longer is ISO8859-1 
(Latin 1).  The upper 128 characters now result in two byte UTF8 
sequences.  You need to perform an encoding conversion before passing 
Latin 1 strings into Tcl.

--Scott


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

[TCLCORE] I18N back on track (I hope...)

[Laurent D. <lau...@ne...>]

Hi,

I've managed to make some time to get the I18N stuff back on my plate. I've
decided on the following approach:

- Apply Jan's patch to tclUtf.c. This adds a new escape sequence (\_) for
  the special character 0x332. In Unicode, it's supposed to mean "underline
  the previous character".
  
- In the ConfigureButton function, check for the presence of the 0x332
  character in the textPtr string (my understanding of the code is that if
  -textvariable is set, the textPtr value is changed accordingly). If it's
  found, locate its position in the string. Then, set the -underline value
  to the position of the 0x332 char in the string. IOW, no matter what value
  you put in -underline, it will be overwritten if you have a \_ in your
  string.

  Move the string appearing after the 0x332 over the location of the 0x332.
  IOW, remove the \_ from the string. THe way I figure it, once the
  character is underlined, you should no longer need the underline escape
  sequence. This will allow all the rest of Tk's code to work the same way
  it does now. Otherwise, if the 0x332 needs to remain in the string, more
  of the core code needs to be changed. I figure, since this is new stuff
  being added and noone is yet using the \_ sequence, it shouldn't hurt
  anyone's code.

If anyone thinks this is all a bad idea, please say so now before I do too
much work on it. :-)

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@ne...           Penguin Power!



--
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 Thu, 17 Aug 2000, Mo DeJong wrote:

> Boy, that is really strange. I just tried it and now I am unable
> to reproduce the problem. I fear this is some strange thing that
> depends on the system clock. Were any system clock related
> changes made in 8.4?

None that I'm aware of.  It seems more likely to me that you had a stale
build accidentally.  If you can reproduce the problem again, let us know;
otherwise, I'll consider this issue closed.

   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.

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

On Thu, 10 Aug 2000, Eric Melski wrote:

> 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.

Boy, that is really strange. I just tried it and now I am unable
to reproduce the problem. I fear this is some strange thing that
depends on the system clock. Were any system clock related
changes made in 8.4?

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] 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.