tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Creative Tcl ChangeLog entries.

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

I don't mean to complain, but I have noticed some
"creative" entries showing up in Tcl and Tk
Changelogs.

Most ChangeLogs entries follow this format:

        * unix/Makefile.in:
        * win/Makefile.in: makefile cleanup

But there also seem to be some "creative" ones:

        * win/{Makefile.in,configure.in,tkConfig.sh.in}: 
        Cleanup of defines in tkConfig.sh

This conflicts with the GNU coding standards.

http://www.gnu.org/prep/standards.html

Could we please stick to the GNU standards? It really
does make you life easier later one. For instance,
I might grep the ChangeLog for "win/Makefile.in",
that would not match win/{Makefile.in,...

thanks
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: Notes about Perl6 ideas - good to read

[Karl L. <ka...@Ne...>]

Brent Welch wrote:

> I'm probably and old man here, but I think we can revitalize Tcl without
> breaking backwards compatibility.  In fact, enough incompatibility could
> really hurt us.  We've finally got a stable C API through stubs - it seems
> a shame to make gratuitous changes to "clean things up".

I agree with this 100%.

> Now, I'm all for things like Feather and factoring the core so it can
> be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
> some features, then they should be able to use Tcl 9 without major pain.
> I'd probably also live with a binary-incompatibilty but source-compatibilty
> approach, which is probably necessary if we muck with the Tcl_Obj and
> Tcl_ObjType structures.

I think factoring the core is interesting and has some cool aspects, and if
someone does it and does a good job, let's embrace it.  I don't think it will
yield very many new Tcl design wins.

I think it would be a big deal to have a build system that cranks out binary
releases of a mega-Tcl with lots of extensions across many platforms.  There was
some discussion of this recently in the newsgroup.  Any thoughts or ideas?

Karl


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

[TCLCORE] Patch submittal for generic/tclExecute.c

[<mi...@ut...>]

Enclosed please find a patch file you might consider. It is a diff file
to
generic/tclExecute.c of tcl8.4a1; if I should rather send the complete
file,
please let me know. Remark that the file header (with CVS reference,
etc)
was NOT modified as it should ...

It modifies the file tclExecute.c (mainly the function
TclExecuteByteCode)
in the following manner:

A - Replaces the manner of addressing the Tcl stack; the programs do not

       use an index into an array but a pointer to the top item in the
stack. Hence
       the "idiom"  stackPtr[stackTop] is replaced by *stackTopPtr.

        This saves indexing into an array at every stack access, and
requires one
        fewer register variable - no need to keep stackPtr handy. On the
other hand,
        it costs an addition every time the stack is cached or decached
- because
        the environment keeps an index into the stack, and not the
address of the top
        item. It gives a modest speed increase (maybe 10% in the
bytecode-intensive
        parts of tclbench)

       The modifications are mainly in the macros DECACHE_STACK_INFO,
        CACHE_STACK_INFO, PUSH_OBJECT(objPtr) and POP_OBJECT.
        Declarations in several functions where changed, as well as
isolated
        instances of direct access to the stack (mainly in
TclExecuteByteCode,
        I can't remember if somewhere else also ...)


B - It does a general variable cleanup in TclExecuteByteCode. All
auxiliary variables
       are now constrained to blocks enclosing the different bytecode
instructions, except
        for those which really need to have function scope.

        Eliminates the variables opnd, pcAdjustment, valuePtr,
value2Ptr, objPtr, bytes,
        length and i from the function declaration.

        This "elimination of global variables" has probably no effect on
performance; I think
         however it will be of value to maintainers as it simplifies the
analysis of instructions.


Your comments are of course welcome.  Cheers

Miguel Sofer

Re: [TCLCORE] Re: Notes about Perl6 ideas - good to read

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

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

> Also sprach Jeffrey Hobbs:
 
>> ...  Sure, Tcl is great as it is, but for a lot of people its only
>> great when they have itcl, blt, tix, patches for better C++
>> compatibility, more data structures, etc etc.  Fewer and fewer are
>> truly satisfied with what the "core" provides.

> This is just slightly off the point, but I don't understand this
> last couple of sentences.  It seems like you are implying that the
> fact that the core of Tcl, by itself, is an incomplete solution for
> most complicated tasks is a bad thing.  Is that right?
 
> I thought the aim was to get more stuff out of the core (making it
> thereby even LESS satisfactory by itself) and then making the
> process of acquiring & deploying extensions so easy that you would
> never hesitate to do so...  That is still our goal, right?

I can't speak for the others, but for me this is one of the goals to
pursue and quite high on the priority list.


> As for introducing backwards incompatibilities, I agree with Brent a
> bit that we should not break Tcl compatibility unless there is some
> really compelling need.  I don't see any evils of the Tcl language
> that we are likely to cure in a good way (as opposed to, for
> instance, introducing some other comment syntax that breaks the
> current Tcl mold), that would require backwards incompatilibilities
> at the syntax level.  But in any case, this should be approached
> with some caution.

As can be seen in the discussion on c.l.t about {}$ and {}[ by Paul
Duffin.  I certainly like the basic idea behind that but the chosen
syntax was something which felt like syntactic salt to me (in opposition
to the syntactic sugar Richard Suchenwirth is so fond of).

> It would, on the other hand, be nice to rearrange some of the
> commands to be a little more coherent.  It would be good to gather
> all the list commands together,

Part of that is already done through the 'listx' command.

> and maybe even make the open & socket commands return objects, so we
> can get rid of this horrible mess of fconfigure, fblocked, eof...
> But I don't think that any of the subsystems are so badly designed
> right now that we couldn't provide wrappers for the old syntax...
 
> As for C level changes, this should really be a community vote type
> thing.  We need to balance the desire to clean up & make more
> powerful the new internals that were introduced in 8.0 & friends,
> with the need to carry along most of the major extensions.  So
> before we start wholesale changes like this, we should have a
> discussion of the merits, and make sure we have easy transition
> paths for all the many bits of C code out there...
 

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

[TCLCORE] Re: Notes about Perl6 ideas - good to read

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

I should have noted this before, but my initial post was just a
copy of the one I made on the newsgroup (in response to Laird,
subject: Content of the Perl6 talk), since many that are on the
CC list may not get the opportunity to read everything on the
newsgroup regularly.

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

> -----Original Message-----
> From: John Ousterhout [mailto:ou...@aj...]
> Subject: [TCLCORE] Re: Notes about Perl6 ideas - good to read
> 
> 
> May I suggest that we should move most of these discussions to
> comp.lang.tcl?  If we want to eliminate the appearance of a group
> of Tcl "insiders", it would be better to make these discussions
> as public as possible.
> 
> -John-

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

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[John O. <ou...@aj...>]

May I suggest that we should move most of these discussions to
comp.lang.tcl?  If we want to eliminate the appearance of a group
of Tcl "insiders", it would be better to make these discussions
as public as possible.

-John-

At 11:09 AM 7/28/2000 -0700, Mo DeJong wrote:
>On Fri, 28 Jul 2000, Jim Ingham wrote:
>
> > I thought the aim was to get more stuff out of the core (making it thereby
> > even LESS satisfactory by itself) and then making the process of acquiring &
> > deploying extensions so easy that you would never hesitate to do so...  That
> > is still our goal, right?
>
>I hope that is still the goal. We do need to do some work to make
>it easier to build and add new extensions, but I think we have the
>right goal.
>
> > As for introducing backwards incompatibilities, I agree with Brent a bit
> > that we should not break Tcl compatibility unless there is some really
> > compelling need.  I don't see any evils of the Tcl language that we are
> > likely to cure in a good way (as opposed to, for instance, introducing some
> > other comment syntax that breaks the current Tcl mold), that would require
> > backwards incompatilibilities at the syntax level.  But in any case, this
> > should be approached with some caution.
>
>I don't think we need any syntax changes. I do think that a "no commands
>must ever change" mentality will end up making things a lot harder
>in the long run. Honestly, if you need to run some 10 year old code,
>why can't you use an old version of Tcl? Why can't you do a bit of
>porting to get it working with Tcl 9.0?
>
> > It would, on the other hand, be nice to rearrange some of the commands to be
> > a little more coherent.  It would be good to gather all the list commands
> > together, and maybe even make the open & socket commands return objects, so
> > we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
> > don't think that any of the subsystems are so badly designed right now that
> > we couldn't provide wrappers for the old syntax...
>
>I would suggest that folks check out my EasySocket API, is it a
>lot easier to use than the plain socket interface.
>
>Mo DeJong
>Red Hat Inc 

________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
(Scriptics has changed its name...)        http://www.ajubasolutions.com

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

[TCLCORE] Re: Notes about Perl6 ideas - good to read

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

On Fri, 28 Jul 2000, Jim Ingham wrote:

> I thought the aim was to get more stuff out of the core (making it thereby
> even LESS satisfactory by itself) and then making the process of acquiring &
> deploying extensions so easy that you would never hesitate to do so...  That
> is still our goal, right?

I hope that is still the goal. We do need to do some work to make
it easier to build and add new extensions, but I think we have the
right goal.

> As for introducing backwards incompatibilities, I agree with Brent a bit
> that we should not break Tcl compatibility unless there is some really
> compelling need.  I don't see any evils of the Tcl language that we are
> likely to cure in a good way (as opposed to, for instance, introducing some
> other comment syntax that breaks the current Tcl mold), that would require
> backwards incompatilibilities at the syntax level.  But in any case, this
> should be approached with some caution.

I don't think we need any syntax changes. I do think that a "no commands
must ever change" mentality will end up making things a lot harder
in the long run. Honestly, if you need to run some 10 year old code,
why can't you use an old version of Tcl? Why can't you do a bit of
porting to get it working with Tcl 9.0?

> It would, on the other hand, be nice to rearrange some of the commands to be
> a little more coherent.  It would be good to gather all the list commands
> together, and maybe even make the open & socket commands return objects, so
> we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
> don't think that any of the subsystems are so badly designed right now that
> we couldn't provide wrappers for the old syntax...

I would suggest that folks check out my EasySocket API, is it a
lot easier to use than the plain socket interface.

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: Notes about Perl6 ideas - good to read

[Jim I. <ji...@ap...>]

Also sprach Jeffrey Hobbs:

>                           ...  Sure, Tcl is great as it is, but for a lot
> of people its only great when they have itcl, blt, tix, patches for better
> C++ compatibility, more data structures, etc etc.  Fewer and fewer are
> truly satisfied with what the "core" provides.

This is just slightly off the point, but I don't understand this last couple
of sentences.  It seems like you are implying that the fact that the core of
Tcl, by itself, is an incomplete solution for most complicated tasks is a
bad thing.  Is that right?

I thought the aim was to get more stuff out of the core (making it thereby
even LESS satisfactory by itself) and then making the process of acquiring &
deploying extensions so easy that you would never hesitate to do so...  That
is still our goal, right?

As for introducing backwards incompatibilities, I agree with Brent a bit
that we should not break Tcl compatibility unless there is some really
compelling need.  I don't see any evils of the Tcl language that we are
likely to cure in a good way (as opposed to, for instance, introducing some
other comment syntax that breaks the current Tcl mold), that would require
backwards incompatilibilities at the syntax level.  But in any case, this
should be approached with some caution.

It would, on the other hand, be nice to rearrange some of the commands to be
a little more coherent.  It would be good to gather all the list commands
together, and maybe even make the open & socket commands return objects, so
we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
don't think that any of the subsystems are so badly designed right now that
we couldn't provide wrappers for the old syntax...

As for C level changes, this should really be a community vote type thing.
We need to balance the desire to clean up & make more powerful the new
internals that were introduced in 8.0 & friends, with the need to carry
along most of the major extensions.  So before we start wholesale changes
like this, we should have a discussion of the merits, and make sure we have
easy transition paths for all the many bits of C code out there...

Jim
-- 
Jim Ingham                                 ji...@ap...
Apple Computer

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

[TCLCORE] Re: Notes about Perl6 ideas - good to read

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

I should note that it's not just Perl6, but the next major rev of Python
that has clearly announced that it will sacrifice some aspect of backwards
compatability (although they aren't as far along in public planning yet).

Is it major pain when just a translation script is needed?  I think that
Tcl is already a better language in that we could likely provide a Tcl
level compatability mode that's like the translation on the fly.  Thus
the request for 'package require Tcl 8' in Tcl9 would shift around the
necessary bits to make it look like Tcl8.  The user wouldn't gain whatever
advantages Tcl9 has, but things would still work.  I think we could
achieve that with 99% compatability at the Tcl level.

Tcl at the C level would be trickier, as we'd want to reconsider some of
the designs of basic public structures (like Tcl_Obj, and finally getting
the Var structures public).  Sure, Tcl is great as it is, but for a lot
of people its only great when they have itcl, blt, tix, patches for better
C++ compatibility, more data structures, etc etc.  Fewer and fewer are
truly satisfied with what the "core" provides.

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

> -----Original Message-----
> From: Brent Welch [mailto:we...@aj...]
	...
> I'm probably and old man here, but I think we can revitalize Tcl without
> breaking backwards compatibility.  In fact, enough incompatibility could
> really hurt us.  We've finally got a stable C API through stubs - it seems
> a shame to make gratuitous changes to "clean things up".
>
> Now, I'm all for things like Feather and factoring the core so it can
> be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
> some features, then they should be able to use Tcl 9 without major pain.
> I'd probably also live with a binary-incompatibilty but source-compatibilty
> approach, which is probably necessary if we muck with the Tcl_Obj and
> Tcl_ObjType structures.

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

[TCLCORE] Re: Notes about Perl6 ideas - good to read

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

I'm probably and old man here, but I think we can revitalize Tcl without
breaking backwards compatibility.  In fact, enough incompatibility could
really hurt us.  We've finally got a stable C API through stubs - it seems
a shame to make gratuitous changes to "clean things up".

Now, I'm all for things like Feather and factoring the core so it can
be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
some features, then they should be able to use Tcl 9 without major pain.
I'd probably also live with a binary-incompatibilty but source-compatibilty
approach, which is probably necessary if we muck with the Tcl_Obj and
Tcl_ObjType structures.

>>>"Jeffrey Hobbs" said:
 > A Ruby user's perspective on the announced plans:
 > 	http://deja.com/=dnc/getdoc.xp?AN=651665267
 > 
 > And a more Perl-oriented technical perspective:
 > 	http://www.perl.com/pub/2000/07/perl6.html
 > 
 > These are good notes about planning for a major revision upgrade, most
 > notably that Perl6 plans to break compatability with Perl5, maintaining
 > upwards compatability only via a translation script (that won't guarantee
 > 100% compatability).
 > 
 > Perhaps before we start to worry too much about the nearer term but not
 > ambitious 8.4, whoever becomes the future Tcl Core Team should focus on
 > Tcl9 and a plan to truly revitalize Tcl.
 > 
 > 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.
 > 

--	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] Notes about Perl6 ideas - good to read

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

A Ruby user's perspective on the announced plans:
	http://deja.com/=dnc/getdoc.xp?AN=651665267

And a more Perl-oriented technical perspective:
	http://www.perl.com/pub/2000/07/perl6.html

These are good notes about planning for a major revision upgrade, most
notably that Perl6 plans to break compatability with Perl5, maintaining
upwards compatability only via a translation script (that won't guarantee
100% compatability).

Perhaps before we start to worry too much about the nearer term but not
ambitious 8.4, whoever becomes the future Tcl Core Team should focus on
Tcl9 and a plan to truly revitalize Tcl.

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] Checkin of cygwin/mingwin build on core-8-3-1-branch

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

I checked in the merge of all the mingw related build changes
from 8.4 to core-8-3-1-branch. I tested the build using the mingw
cross compiler under Linux. It should work, but it is possible
that something in the VC++ side of the house broke. Don't say
I did not warn you.

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: 8.3.2 almost finished - expect an 8.3.3

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

> FYI,
 
> 8.3.2 has some more testing to be done, and then some backporting of
> items that went into the main branch (8.4).  It should be out by
> mid-August.
 
> In working with 8.3.2, we realized that there will be a need for and
> 8.3.3 to work on limitations inherent in the Windows OS and how we
> manage sockets with Tcl.  Currently we can only service 64
> simultaneous socket requests because that's what the Windows select
> can manage per thread.

What an OS :(. Now there was that slip of paper ... Ah, here.

~~~~~~~~~~~~~~~~~~
Windows 95: n.
	32-bit extensions and a graphical shell for a 16-bit patch to
	an 8-bit operating system originally coded for a 4-bit
	microprocessor, written by a 2-bit company that can't stand
	for 1 bit of competition.
~~~~~~~~~~~~~~~~~~

> The solution will be to spin a thread per socket instead (as
> lightweight as possible).

Questions coming to my mind:

	Would it be much more complex to spin new threads only as the
	limit on the previous ones is reached, i.e. only every 64
	sockets ?

	Or would that complexity outweigh the benefits we can get from
	having less threads around ?

	I'm worried that we will run into some limit on the number of
	threads supported by Win* instead.


> At the same time we have to solve the problem with the memory leak
> in using Windows threads when the C runtime is accessed (leading to
> things like the 4K mem leak per exec call on Windows).
 
> We already have some thoughts, but it will take some time to get the
> solution right.  We want to get the 8.3.2 changes out because it
> will be important for everybody to have a real distributed version
> of Tcl with the corrected stacked channel code, among other changes
> that will be in 8.3.2.  No release date for 8.3.3 at this time.

-- 
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: Porting 8-3-1-branch IO changes to 8-4

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

> OK, so the major IO rewrite for 8.3.2 is mostly finished (the new
> interfaces need to be doc'ed).  Now we have to deal with moving
> those code changes up into the mainline (8.4).
 
> One of the conflicts is that generic declarations were added to both
> 8.3 (Tcl_Channel* funcs) and 8.4 (funcs for sharing channels among
> threads, some UniChar and HashTable funcs).  Since the 8.4 only saw
> one alpha, the 8.3 entries will have precedence and keep their
> numbers.  I'll renumber the 8.4 entries.  This means that extensions
> compiled against 8.4a1 stubs may have incompatabilities and should
> be recompiled with 8.4a2 if they use the new stub calls.

The only extension I currently know of using the new calls is
'Thread'.


> Of course, we managed to focus new development in both branches on
> the IO layer (8.4 getting work in the sharing of channels between
> threads).  Since 8.3 is by far the larger of the rewrites, I'd like
> to basically move the IO changes complete up from 8.3 and then
> regraft the 8.4 changes onto the new system.
 
> Anyone forsee further complications with this, or has comments, or
> would like to help?

I see no big complications with that. ... Ok, the changes I did are in

	2000-05-03-20-24.diff.gz 

of my cvs snapshots. There are some other changes in as well (joinable
threads), but it should be possible to trim it down to contain just
the changes to the IO-system. We'll have to see how many chunks are
still applicable. File attached.

~~~~~~~~~~~~~~~

Excerpt of ChangeLog of the lastest 8.3.2-io-rewrite.

* tests/all.tcl: corrected additional sets by Kupries for testing.

I'm chagrined. My apologies for that oversight.

I truly wish there was some way to set such things separately during
development without having to modify the distributed files
themselves. => Some idea for Jennifer Hom and her planned changes to
tcltest.


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

Re: [TCLCORE] 8.3.2 almost finished - expect an 8.3.3

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

--------; charset=us-ascii
> FYI,
 
> 8.3.2 has some more testing to be done, and then some backporting of
> items that went into the main branch (8.4).  It should be out by
> mid-August.
 
> In working with 8.3.2, we realized that there will be a need for and
> 8.3.3 to work on limitations inherent in the Windows OS and how we
> manage sockets with Tcl.  Currently we can only service 64
> simultaneous socket requests because that's what the Windows select
> can manage per thread.

What an OS :(. Now there was that slip of paper ... Ah, here.

~~~~~~~~~~~~~~~~~~
Windows 95: n.
	32-bit extensions and a graphical shell for a 16-bit patch to
	an 8-bit operating system originally coded for a 4-bit
	microprocessor, written by a 2-bit company that can't stand
	for 1 bit of competition.
~~~~~~~~~~~~~~~~~~

> The solution will be to spin a thread per socket instead (as
> lightweight as possible).

Questions coming to my mind:

	Would it be much more complex to spin new threads only as the
	limit on the previous ones is reached, i.e. only every 64
	sockets ?

	Or would that complexity outweigh the benefits we can get from
	having less threads around ?

	I'm worried that we will run into some limit on the number of
	threads supported by Win* instead.


> At the same time we have to solve the problem with the memory leak
> in using Windows threads when the C runtime is accessed (leading to
> things like the 4K mem leak per exec call on Windows).
 
> We already have some thoughts, but it will take some time to get the
> solution right.  We want to get the 8.3.2 changes out because it
> will be important for everybody to have a real distributed version
> of Tcl with the corrected stacked channel code, among other changes
> that will be in 8.3.2.  No release date for 8.3.3 at this time.

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

Re: [TCLCORE] Porting 8-3-1-branch IO changes to 8-4

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

> OK, so the major IO rewrite for 8.3.2 is mostly finished (the new
> interfaces need to be doc'ed).  Now we have to deal with moving
> those code changes up into the mainline (8.4).
 
> One of the conflicts is that generic declarations were added to both
> 8.3 (Tcl_Channel* funcs) and 8.4 (funcs for sharing channels among
> threads, some UniChar and HashTable funcs).  Since the 8.4 only saw
> one alpha, the 8.3 entries will have precedence and keep their
> numbers.  I'll renumber the 8.4 entries.  This means that extensions
> compiled against 8.4a1 stubs may have incompatabilities and should
> be recompiled with 8.4a2 if they use the new stub calls.

The only extension I currently know of using the new calls is
'Thread'.


> Of course, we managed to focus new development in both branches on
> the IO layer (8.4 getting work in the sharing of channels between
> threads).  Since 8.3 is by far the larger of the rewrites, I'd like
> to basically move the IO changes complete up from 8.3 and then
> regraft the 8.4 changes onto the new system.
 
> Anyone forsee further complications with this, or has comments, or
> would like to help?

I see no big complications with that. ... Ok, the changes I did are in

	2000-05-03-20-24.diff.gz 

of my cvs snapshots. There are some other changes in as well (joinable
threads), but it should be possible to trim it down to contain just
the changes to the IO-system. We'll have to see how many chunks are
still applicable. File attached.

~~~~~~~~~~~~~~~

Excerpt of ChangeLog of the lastest 8.3.2-io-rewrite.

* tests/all.tcl: corrected additional sets by Kupries for testing.

I'm chagrined. My apologies for that oversight.

I truly wish there was some way to set such things separately during
development without having to modify the distributed files
themselves. => Some idea for Jennifer Hom and her planned changes to
tcltest.


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

[TCLCORE] 8.3.2 almost finished - expect an 8.3.3

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

FYI,

8.3.2 has some more testing to be done, and then some backporting
of items that went into the main branch (8.4).  It should be out
by mid-August.

In working with 8.3.2, we realized that there will be a need for
and 8.3.3 to work on limitations inherent in the Windows OS and
how we manage sockets with Tcl.  Currently we can only service 64
simultaneous socket requests because that's what the Windows
select can manage per thread.  The solution will be to spin a
thread per socket instead (as lightweight as possible).  At the
same time we have to solve the problem with the memory leak in
using Windows threads when the C runtime is accessed (leading to
things like the 4K mem leak per exec call on Windows).

We already have some thoughts, but it will take some time to get
the solution right.  We want to get the 8.3.2 changes out because
it will be important for everybody to have a real distributed
version of Tcl with the corrected stacked channel code, among
other changes that will be in 8.3.2.  No release date for 8.3.3
at this time.

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] Porting 8-3-1-branch IO changes to 8-4

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

OK, so the major IO rewrite for 8.3.2 is mostly finished (the new interfaces
need to be doc'ed).  Now we have to deal with moving those code changes up
into the mainline (8.4).

One of the conflicts is that generic declarations were added to both 8.3
(Tcl_Channel* funcs) and 8.4 (funcs for sharing channels among threads,
some UniChar and HashTable funcs).  Since the 8.4 only saw one alpha, the
8.3 entries will have precedence and keep their numbers.  I'll renumber
the 8.4 entries.  This means that extensions compiled against 8.4a1 stubs
may have incompatabilities and should be recompiled with 8.4a2 if they
use the new stub calls.

Of course, we managed to focus new development in both branches on the
IO layer (8.4 getting work in the sharing of channels between threads).
Since 8.3 is by far the larger of the rewrites, I'd like to basically
move the IO changes complete up from 8.3 and then regraft the 8.4 changes
onto the new system.

Anyone forsee further complications with this, or has comments, or
would like to help?

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] *-io-rewrite branches merged in

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

After finally coming to a point a very high (but not complete)
satisfaction with the Tcl IO channel / TLS rewrite, I have merged
the branches I was working on back in.  For Tcl, this means that
people shouldn't work with the core-8-3-1-io-rewrite branch anymore,
just core-8-3-1-branch or the mainline.  Note that the mainline
is Tcl 8.4, and I have not yet up-ported the IO rewrite code.

For Tls, this means use the mainline (cvs up -A, or checkout fresh),
please don't use tls-1-3-io-rewrite anymore.

Following these changes, Tcl is at 8.3.2 and TLS is at 1.4.

For those testing this, I also have numerous simple but severe
stress-testing scripts (note that there are also lots of tests
to go with the new code).  I'm going to figure out where to add
the stress testing scripts as examples into the CVS of Tls.

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: modifying generic/tclExecute.c

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

On Tue, 25 Jul 2000, <Miguel Sofer wrote:

> Point (a) implies inlining some code which is in other files
> (tclVar.c, tclBasic.c, maybe tclCompile.c). I have been "copying and
> pasting" in my preliminary tests, but realise that this is not very
> good - difficult maintenance, even if well documented. For instance,
> any change in the Var type may have severe implications in the
> executor, the decoupling is lost ...
> 
> A solution might be to put some of that code in macros in a common
> header file. I kind of liked the idea of touching a single file
> (actually, a single function!); this option would imply modifying also
> the other files ... and maybe making life difficult for their
> maintainers/updaters. I'd rather not ...

I'm generally opposed to using macros for anything but fairly small (less
than about 4 lines of code) functions.  I think overuse of macros can lead
to badly structured code.  Perhaps there are a few small, critical
sections of code that would benefit from this, however.  I'd like to see
what code you are specifically considering modifying this way.

This sort of leads into a related issue with TclExecuteByteCode, which is
that there is substantial duplication of functionality between
TclExecuteByteCode/Tcl_*CompCmd and the various Tcl_*ObjCmd
implementations.  I don't know of a good solution to this, but it would
surely make Tcl easier to maintain (not that it is really that bad right
now) if we could consolidate that code.

I'd like to get some other peoples brains working on this problem; maybe
we can come up with something reasonable for 9.0.

   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] modifying generic/tclExecute.c

[<Miguel S. <mi...@ut...>]

I am testing a few optimisations of TclExecuteByteCode, with
initially promising results.

It consists mainly of
(a) avoiding calls outside of TclExecuteByteCode and reducing the
    amount of recursive calls
(b) using (if available) the gcc "Labels as Values" extension,
    making a single indirect jump to the new opcode instead of a jump 
    back to "for (;;)" and then switch (an indirect jump as compiled by
    gcc) 
(c) a few other smaller things 

Point (a) implies inlining some code which is in other files
(tclVar.c, tclBasic.c, maybe tclCompile.c). I have been "copying and
pasting" in my preliminary tests, but realise that this is not very
good - difficult maintenance, even if well documented. For instance,
any change in the Var type may have severe implications in the
executor, the decoupling is lost ...

A solution might be to put some of that code in macros in a common
header file. I kind of liked the idea of touching a single file
(actually, a single function!); this option would imply modifying also
the other files ... and maybe making life difficult for their
maintainers/updaters. I'd rather not ...

I appreciate any suggestions you might have on this point.

Thanks

Miguel Sofer

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

[TCLCORE] Tcl bugfixes to backport for 8.3.2

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

Here's my list of fixes to backport for 8.3.2.  Unlike the Tk fixes, most
of these are not as interesting (doc fixes, etc).  There's a couple of
good ones in there, though (build cleanup, clock bugs, http bugs).

- eric

	* doc/memory.n: Man page for Tcl "memory" command, which is
	created when TCL_MEM_DEBUG is defined at compile time.

	* doc/TCL_MEM_DEBUG.3: Man page with overall information about
	TCL_MEM_DEBUG usage.

	* doc/DumpActiveMemory.3: Man page for Tcl_DumpActiveMemory,
	Tcl_InitMemory, and Tcl_ValidateAllMemory [Bug: 1816, 1835].

	* generic/tclCkalloc.c: Fixed some function headers.

	* unix/mkLinks: Regen'd with new mkLinks.tcl.

	* unix/mkLinks.tcl: Fixed indentation, made link setup more
	intelligent (only do one existance test per man page, instead of
	one per function).

	* doc/library.n: Fixed .SH NAME macro to include each function
	documented on the page, so that mkLinks will know about the
	functions listed there, and so that the Windows help file index
	will get set up correctly [Bug: 1898, 5273].

	* doc/library.n: Added entries for auto_qualify and auto_import
	[Bug: 1271].

	* doc/Init.3: Manual entry for Tcl_Init [Bug: 1820].

	* doc/expr.n: Added documentation for each of the math library
	functions that expr supports [Bug: 1054].

	* unix/Makefile.in: add tclsh.ico and tcl.spec to dist target

	* generic/tclPosixStr.c (Tcl_SignalMsg): clarified #defines for
	Linux on Sparc to compile correctly. [Bug: 5364]

	* library/history.tcl: Corrected an off-by-one error in HistIndex,
	which was causing [history redo] to start its search at the wrong
	event index. [Bug: 1269].

	* library/init.tcl (auto_import): added check to see if a valid
	pattern was coming in, to avoid simple error cases [Bug: 3326]

	* doc/regsub.n: correct regsub docs [Bug: 5346]

	* win/{tcl.m4,Makefile.in,configure.in}: added support for mingw
	compile env and cross-compiling. [Bug: 5499]

	* generic/tclClock.c (FormatClock): correct code to handle locale
	specific return values from strftime, if any. [Bug: 3345]

	* unix/tclUnixInit.c (TclpSetInitialEncodings): attempt to
	correct setlocale calls for XIM support and locale issues.
	[BUG: 5422 3345 4236 2522 2521]

	* tests/clock.test: Added test for "2 days 2 hours ago" style
	specifications.

	* generic/tclDate.c: Regenerated from tclGetDate.y.

	* generic/tclGetDate.y: Tweaked grammar to properly handle the
	"ago" keyword when it follows multiple relative unit specifiers,
	as in "2 days 2 hours ago".  [Bug: 5497].

	* doc/scan.n: 
	* doc/array.n: minor doc fixes [Bug: 5396]

	* generic/tclEnv.c: cast cleanup [Bug: 5624]
	* win/tclWinConsole.c: cast and header cleanup [Bug: 5625]
	* win/tclWinSerial.c: cast cleanup [Bug: 5626]
	* win/tclWinFCmd.c: cast cleanup [Bug: 5627]

	* tests/http.test
	* doc/http.n
	* library/http2.3/http.tcl: Fixed bug 5741, where unsuccessful
	geturl calls sometimes leaked memory and resources (sockets).  
	Also, switched around some of the logic so that http::wait never 
	throws an exception.  This is because in an asynchronous geturl, 
	the command callback will probably end up doing all the error 
	handling anyway, and in an asynchronous situation, the user
	expects to check the state when the transaction completes, as
	opposed to being thrown an exception.	For the http package, this
	menas the user can check http::status for "error" and http::error
	for the error message after doing the http::wait.

	* generic/tclIndexObj.c (Tcl_GetIndexFromObjStruct): Corrected
	caching of the index ptr to account for offsets != sizeof(char *).
	[Bug: 5153]

	* win/tcl.m4:
	* win/configure.in:
	* win/Makefile.in: Applied patch from [RFE: 5844], to extend
	support for mingw compile environment on Windows.

	* win/tclWinDde.c:
	* win/tclWinInit.c:
	* win/tclWinNotify.c:
	* win/tclWinPipe.c:
	* win/tclWinReg.c:
	* win/tclWinThrd.c: Applied patch from [Bug: 5794], to fix
	compiler warnings when using mingw on Windows.

	* doc/RegExp.3: Replaced instances of "Tcl_GetRegExpInfo" with
	"Tcl_RegExpGetInfo", the correct name of the function [Bug: 5901].

	* library/opt0.4/optparse.tcl: Applied patch from [Bug: 5922],
	which corrected an incorrect use of [string match].

	* unix/tclConfig.sh.in:
	* win/tclConfig.sh.in: Applied patch from [Bug: 5921], which
	corrects a typo in the comments in these files.

	* doc/package.n: Corrected information about [package forget]
	arguments [Bug: 5418].

	* tests/stringObj.test: Tweaked tests to avoid hardcoded
	high-ASCII characters (which will fail in multibyte locales);
	instead used \uXXXX syntax. [Bug: 3842].




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

[TCLCORE] tk bugfixes to backport to 8.3.2

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

I suggest that the following Tk bugfixes be backported from the mainline
to 8.3.2.  Many of them fix (potential) core dump issues; others (like the
redefine of the GIF87a/GIF89a strings) just fix bug that have a high
annoyance factor.

- eric

	* generic/tkText.c (TextSearchCmd): Added a test for a NULL
	segment pointer when doing backwards searches for "" on an empty
	text widget. [Bug: 6007].

	* generic/tkCursor.c: Added initialization for nextPtr field of
	TkCursor, patch from Nijtmans/Howlett.

	* generic/tkMenu.c (DeleteMenuCloneEntries): Applied fix from
	[Bug: 5275], which corrected a segfault-causing indexing problem
	when deleting entries from torn-off menus.

	* generic/tkImgGIF.c: Changed defines for GIF87a/GIF89a to be
	static char arrays with integer initialization, to address EBCIDIC
	vs. ASCII encoding issues and to handle compilers that don't deal
	with "\xAB" syntax for specifying hex values in strings.

	* generic/tkPlace.c (Tk_PlaceCmd): reworked place master/slave
	table init'n to prevent seg fault when using place on multiple
	displays.

	* canvas.test: added test for 5783.
	* generic/tkCanvPoly.c (DisplayPolygon): added checks for the
	polygon fillGC not being empty to prevent segfault. [Bug: 5783]

	* win/tkWinMenu.c (ReconfigureWindowsMenu): Added code to add the
	MF_SEPARATOR bit for SEPARATOR_ENTRY menu items.  This causes
	separator entries on the system menu to be drawn correctly [Bug:
	5451].

	* win/tkWinWm.c (RaiseWinWhenIdle): added TK_DONT_DESTROY_WINDOW
	to flag check to prevent timing related core dump. [Bug: 5438]

	* tests/menu.test:
	* generic/tk3d.c:
	* generic/tkColor.c:
	* generic/tkCursor.c: corrected handling of 3DBorder, Cursor and
	Color objects on multiple screens. [Bug: 5454]

	* win/tkWinMenu.c (GetMenuSeparatorGeometry): Tweaked height
	requested for separator bars to be (linespace - (2*descent))
	instead of just (linespace); this makes the separator occupy a
	more correct amount of vertical space. [Bug: 5303].

	* library/focus.tcl: fixed calling of takeFocus proc [Bug: 5372]

	* generic/tkButton.c: Added -activeforeground, -activebackground
	for labels, for the -state option.

	* doc/label.n: Added documentation for -state option,
	-activeforeground, -activebackground.


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

[TCLCORE] Re: trace command patch

[Vince D. <vin...@bi...>]

> Variable traces support read, write, and unset operations; 
> command traces
> support rename and delete operations; execution traces are 
> used to trace
> command execution, and have several additional options:
> 
> trace add execution name ops ?-minlevel m -maxlevel n 
> -truncate t -depth d?
> 
> The full patch is at
> 
> ftp://ftp.ucsd.edu/pub/alpha/tcl/tracecommand.patch.gz
> 
> If you are so inclined, please take a look at it and give us some
> comments.  I think the patch looks very good; I've tested it 
> out and it
> works as advertised, has tests, and doc's.  My only concern 
> is with the
> syntax of the execution traces.  I think that "execution" 
> should just be
> another operation for command traces, rather than an entirely 
> separate set
> of traces.  My guess is that Vince split it out because of 
> the need for
> the extra options.  But I don't feel strongly that it should 
> be changed.
> Does anybody else have any comments on this, or on any other 
> parts of the
> patch?

Indeed, I split it out because 'execution' and 'command' traces are
semantically very different.  'command' traces simply notify you when a
command is renamed/deleted, whereas 'execution' traces give you ongoing
information about what is happening while a command is being executed.  The
only commonality between the two is that both take a 'name' parameter which
is a valid command in the current interpreter.  Beyond that the ops and
options allowed are completely incompatible between execution/command. 

I'd be happy to help clarify this issue, or anything else with the patch.

Please note that trace.n needs some work.  My nroff skills were not up to
the job (the information is all there, I believe, but not the formatting).
I'd be more than happy to look over a redone trace.n to make sure all the
docs are correct and/or clarify any remaining issues.

cheers,

Vince.

[TCLCORE] RE: [TCLCORE] Re: 64 bit numbers

[Don B. <do...@pi...>]

I guess I misunderstood what the intent of the roadmap
was, but I'm not sure I agree with you here. Let me 
explain my reasoning.

I am running tcl on a 64-bit platform that uses 32-bit
addressing (64-bit addresses are quite large after
all). This isn't that uncommon, there's lots of Unix
systems running with 32-bit addressing that have 64-bit
integer instructions available. The Pentium on which
Windows is based has some 64-bit integer abilities.

I need to have 64-bit integer arithmetic available
in expr & format for interoperability with external
tools that use 64-bit results. In my case its part
of a network testing environment where 64-bit counters
are used, and I need to do rate calculations. I can
do this using mpexpr, but its quite slow, and I can't
get the performance I need. I think there are a few
packages that could use this, scotty & tclblend are 2 
that spring to mind.

Also, it would be nice if a script could be portable
between systems with 64-bit and 32-bit capabilities
without having to worry about the precision of
an integer.

What I would like to do is take on the work to
formalise the use of integer types in Tcl to a new
typedef, so that the size of the integer does not
change based on the host platform it is compiled for.
This means that I have to fix the places that 'int'
is used, 'long' is used, unsafe casts are made, implement
a 64-bit safe strtoul, strtol, format, etc.
The two obvious approachs are binary-compatible (keep
int & long as the current platform size, add a new
set of 64-bit functions), or binary-incompatible
(force the 'int' to 32-bit, the 'long' to 64-bit or
somesuch). The pro & cons for each are fairly
obvious: binary-incompatible -> need to recompile extension,
but all extensions can get 64-bit without code change,
binary-compatible -> more work, extensions need
code changes to use, but don't have to be recompiled.

So far the votes seem to indicate the binary 
compatible approach is prefered.

Checking Tcl user-group history, the 64-bit integer
capability is asked about fairly often.

Being 64-bit addressing safe is also a valuable thing 
to have, unfortunately its not an area I have the equipment
to contribute in.

-----Original Message-----
From: Eric Melski [mailto:er...@aj...]
Sent: July 23, 2000 2:47 PM
To: Don Bowman
Cc: tc...@po...
Subject: [TCLCORE] Re: 64 bit numbers on IA32



I don't think it's necessary or advisable to make Tcl support 64-bit
integers on a 32-bit platform.  It seems like the amount of effort and the
degree to which backwards compatibility would be affected does not justify
the benefits.  If you need 64-bit integers, you should move (or are
probably already running on) a 64-bit platform.  Our focus for extending
64-bit support in Tcl should be on making sure that Tcl works properly on
64-bit platforms.  This means that code that uses integers as pointers,
for example, has to be corrected to use real pointers (since pointers on a
64-bit platform are 64-bit, while integers are likely 32-bit).  Similarly,
code that uses integers for file offsets should use size_t instead, for
the same reasons.  This is really what the intention of the "improve
64-bit support" line-item on the 8.4 roadmap was referring to, I believe.

   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.

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