tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: Procedure/Namespace Behaviour

[Donald G P. <dg...@ca...>]

Donal Fellows:
> > Is there any good reason for the behaviour of test proc-3.4 in the
> > test suite?  (I include it here for quick reference.)

Dan Kuchler:
> I thought this was asked and answered in the
> comp.lang.tcl thread:
> 
> http://x70.deja.com/threadmsg_ct.xp?AN=658562039.1&mhitnum=0

Well, I was the main defender of the status quo in that thread, and
after reading Paul Welton's followup, I'm having second thoughts
about the design myself.  I'd like to echo Donal's request:

>> If there is a good reason for the existing behaviour, I'd love to know
>> it.

If the designers who chose this behavior are on this list, could they
explain this choice, please.

It seems that only the author of the body of a command (whether a
[proc] or a Tcl_CmdProc), knows what assumptions that body makes
about the namespace context in which it is evaluated.

If the [rename] of a command into a new namespace means the body of that
command will be evaluated in the context of the new namespace, then the
code which does the [rename] has the responsibility of discovering
and satisfying the assumptions about namespace context the implementation
of that command makes.  That means you can only [rename] a command whose
internals you know intimately.  That's not reasonable.

An alternative is that all commands should have their bodies written so
that they don't care in which namespace context they are evaluated, just
in case someone [rename]s them into another context.  Requiring that
level of defensive programming is not reasonable either.

Certainly there's no problem with command named [::B::foo] evaluating in
the namespace context ::A, since that's what [namespace import] does.

Donal went on:
>> If not, I think it ought to be changed so that procedures always
>> execute in the namespace where their command existed initially, i.e.
>> [rename] doesn't modify the context that a procedure executes in.

Of course, in order to follow this advice, we need to show not only
that the current behavior is a bad design, but also that no one's
code is depending on that bad design.  Or is this proposal for Tcl 9?

DGP

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

[TCLCORE] The patch

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

Shoot...

-- 
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] Problem with a patch

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

Well,

I didn't see a reply on clt (well, not one that helped me, anyway). So here
is the current state of my patch for \_. Can anyone tell me why

regexp \_ 12\_3

works but not

regexp {\_} 12\_3

? If you can point me in the correct direction, I'll try to do the legwork
myself. I'd like to have this and the translations working correctly for a2.
When is that going to come out?

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: Hintermayer's string allocation patch

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

Gerhard notes that the speed improvements are due to the use of realloc in
place of alloc/free when doing appends.  You can see this is the case in
by the benchmarks I include below.  Also, you can see that (as John
suspected), the new algorithm has slightly worse performance than the old
algorithm (compare the 8.4a2b and 8.4a2c columns below).  However, the
combination of the new algorithm and the use of realloc is still far
better than the original algorithm in terms of performance, and the new
algorithm will actually allow the allocation of all available memory.
So this patch is a combination performance/memory efficiency patch, which
alters the tradeoff point.  I believe that the new behavior is quite good,
and that the modification should be allowed to stand.

John: with respect to memory running out, yes, all machines that Tcl runs
on will likely have virtual memory.  There is no argument that once you
start allocating large blocks of virtual memory, your application will
become basically useless.  This does not alter the fact that with the
original algorithm, you could not allocate, in a single Tcl obj, the
entirety of available memory, unless you were very very lucky and
happened to start with an object that was 
(totalMemorySize/2)-(aFewBytes*2) and you appended aFewBytes.  Also, when
you had a very large data object, you also would likely have a very large
chunk of essentially wasted memory.  This patch enables you to more easily
use more available memory, and wastes far less memory.

As for your suggestion about keeping chains of buffers, I refer you to the
discussion "Maximum variable length in TCL" from comp.lang.tcl, in which
your suggestion and others were discussed:

http://x73.deja.com/viewthread.xp?AN=654172043&search=thread&svcclass=dnyr&ST=PS&CONTEXT=967672551.1167392795&HIT_CONTEXT=967672551.1167392795&HIT_NUM=0&recnum=%3c3...@aj...%3e%231/1&group=comp.lang.tcl&frpage=viewthread.xp&back=clarinet

More extensive performance numbers follow.  I encourage you all, when
looking at these, to not just consider the raw performance issue, but also
the memory usage issue.  It is a _real_ problem that you cannot have very
large data strings in Tcl, and I think the solution we have found here
addresses that issue quite well, while retaining good (better than the
original stuff) performance.

Legend:
   3: 8.4a1
   2: 8.4a2a - unpatched 8.4a2
   2: 8.4a2b - 8.4a2, uses realloc in place of alloc/free
   1: 8.4a2c - patched 8.4a2 (uses new algorithm)

Linux:
000 VERSIONS:                   1:8.4a2c 2:8.4a2b 3:8.4a2a 4:8.4a1
001 STR append                        49       51       55      58
002 STR append (1KB + 1KB)            42       42       44      40
003 STR append (10KB + 1KB)          130      131      125     125
004 STR append (1MB + 2b * 1000)   13273    12972    21243   20550
005 STR append (1MB + 1KB)          8269     7783    15821   15842
006 STR append (1MB + 3KB * 1000)  38944    32576    56587   56818
007 STR append (1MB + 1KB * 20)     8564     8127    16043   16054
END VERSIONS:                   1:8.4a2b 2:8.4a2a 3:8.4a2a 4:8.4a1


Solaris:
000 VERSIONS:                     1:8.4a2c 3:8.4a2a
001 STR append                         168      163
002 STR append (1KB + 1KB)             127      121
003 STR append (10KB + 1KB)            254      268
004 STR append (1MB + 2b * 1000)     27986    28396
005 STR append (1MB + 1KB)            8794    17680
006 STR append (1MB + 3KB * 1000)    55493    77144
007 STR append (1MB + 1KB * 20)       9755    18049
END VERSIONS:                     1:8.4a2c 3:8.4a2a

   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: Procedure/Namespace Behaviour

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

>>>Donald G Porter said:

 > Certainly there's no problem with command named [::B::foo] evaluating in
 > the namespace context ::A, since that's what [namespace import] does.

Nope - I don't think so.  namespace import creates a short alias for the 
command,
it certainly does not affect the namespace scope in which it executes.
But, I happen to know that the original implementation of rename didn't
think hard about namespaces and so you got the behavior you request -
the namespace scope was not changed by the rename. 

By the way, isn't the big picture here that we need an

onexit callback

command so that Tcl-level applications can take action on exit?

 > Donal went on:
 > >> If not, I think it ought to be changed so that procedures always
 > >> execute in the namespace where their command existed initially, i.e.
 > >> [rename] doesn't modify the context that a procedure executes in.
 > 
 > Of course, in order to follow this advice, we need to show not only
 > that the current behavior is a bad design, but also that no one's
 > code is depending on that bad design.  Or is this proposal for Tcl 9?

My recollection is that we had a number of interesting discussions about how
namespaces should work in the pleasant vacuum of Sun Labs.  Now that we (also)
have experience using them, we could reconsider semantics that are not quite
right.  My particular pet peeve is the fact that 

namespace eval foo {
     set i 10
}
will either modify the global i or foo::i depending on if foo::i already 
exists.

--	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] Re: Tcl/TK on Win2000 works for me

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

> From: Brent Welch [mailto:we...@aj...]
	...
> The point of this message is to squash rumors about Windows 2000 
> compatibility.

Most everything works on Win2K that I know of.  We have found at least
two very minor irregularities that have already been patched (that
appear to be problems in Win2K that we have to work around, not with
what Tcl was doing).  Others may arise...

> Win64 is another issue, as that platform isn't final yet, but (Jeff, correct 
> me)
> my impression was that we had already gotten Tcl 8.3 to work on that
> platform, too.

I have built it, but I do know of many problems there.  Also, this
is just for Tcl.  Tk is still a ways off - we have to account for the
change to a P64 model in the Windows code.

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] Procedure/Namespace Behaviour

[Donal K. F. <fel...@cs...>]

Is there any good reason for the behaviour of test proc-3.4 in the
test suite?  (I include it here for quick reference.)

  test proc-3.4 {TclObjInterpProc, procs execute in the namespace in which they were defined unless renamed into new namespace} {
      catch {eval namespace delete [namespace children :: test_ns_*]}
      catch {rename p ""}
      namespace eval test_ns_1::baz {
          proc p {} {return "p in [namespace current]"}
          rename ::test_ns_1::baz::p ::p
          list [p] [namespace which p]
      }
  } {{p in ::} ::p}

The problem with this comes when you are working with various systems
(in pure Tcl) each of which wants to overload the [exit] command to
give them a chance to clean things up nicely; if there is only ever
going to be a single procedure installed over [exit] then there is no
problem as you can simply rename the old exit into a private namespace
out of the way and create the new version, which knows the private
name and calls it at the end of its execution, in its place.  However,
while this technique is effective for a single such replacement, it
fails horribly when several software modules want to do the same
thing, since the second module to install itself moves the first
module's exit handler into a different namespace, which can change the
behaviour of the system in difficult to predict ways (e.g. if the
second system has a [close] command defined in it...)

If there is a good reason for the existing behaviour, I'd love to know
it.  If not, I think it ought to be changed so that procedures always
execute in the namespace where their command existed initially, i.e.
[rename] doesn't modify the context that a procedure executes in.

Ideas?  Brickbats?

Donal.
-- 
Donal K. Fellows, Department of Computer Science, University of Manchester, UK.
(work) fel...@cs...     Tel: +44-161-275-6137  (preferred email addr.)
(home) do...@ug...  Tel: +44-1274-401017   Mobile: +44-7957-298955
http://www.cs.man.ac.uk/~fellowsd/  (Don't quote my .sig; I've seen it before!)

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

[TCLCORE] Tcl/TK on Win2000 works for me

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

>>>Donald G Porter said:

 > OK, according to win/README.binary, Windows 2K has been supported
 > since the Tcl/Tk 8.3b2 release, so I stand corrected.  If Tcl or
 > Tk is not working properly on Windows 2K, I would consider that a
 > bug, and a certain bug fix would be in order in a patch release.

I can vouch for basic correctness in Tcl/TK 8.3.2, TclPro 1.4, and TclHttpd 
under
Windows 2000.  I haven't tried hard to find core dumps, but it seems to
work the same as my Windows NT box.  This is in contrast, for example, to
the 8.1.1 release that had completely broken server sockets on one of the
NT service packs (4, I think).

The point of this message is to squash rumors about Windows 2000 compatibility.
I'm not saying there are no bugs specific to Windows 2000, I'm just saying
that I don't know of any and we should speak carefully to avoid casting
the wrong impression.

Win64 is another issue, as that platform isn't final yet, but (Jeff, correct 
me)
my impression was that we had already gotten Tcl 8.3 to work on that
platform, too.
 
--	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.

Thread Tutorials

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

--------

http://www-4.ibm.com/software/developer/library/posix1.html
http://www-4.ibm.com/software/developer/library/posix2.html

Something we may want to link to from the tcl thread documentation.
It mentions Tcl too, in the resource section. Pthreads-Tcl actually.
We should tell the author about the thread-safety we have since 8.3.

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

[TCLCORE] Re: Procedure/Namespace Behaviour

[Dan K. <ku...@aj...>]

> Is there any good reason for the behaviour of test proc-3.4 in the
> test suite?  (I include it here for quick reference.)

Yes. To guarantee that a proc renamed into a different
namespace executes in that new namespace.

I thought this was asked and answered in the
comp.lang.tcl thread:

http://x70.deja.com/threadmsg_ct.xp?AN=658562039.1&mhitnum=0

I think that the current behavior is the
expected and desired behavior.

--Dan

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

[TCLCORE] Re: Hintermayer's string allocation patch

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

This proposed change makes me nervous, because it results in
O(N**2) behavior for a long series of appends.  Suppose you add
a large number of additional blocks of data, each 3*TCL_GROWTH_MIN_ALLOC
bytes long, to an existing large string.  Each append will cause
the string to be reallocated and the entire existing contents to be
copied.  This should produce very slow behavior when the string is
large.  The reason for doubling the string size each time it's
reallocated is that it guarantees that on average each byte is only
copied about twice, no matter how large the string grows.

I'm confused by the performance measurements; either there's something
I don't understand, or the new approach should work badly in the
case of large strings being appended to gradually.  Also, I don't see
why appends to short strings should improve in performance with the
new algorithm; has something else changed in the new version besides
what's described in your message?

Lastly, I don't understand the comment about memory running out;
virtually all machines where Tcl runs have virtual memory, no?  This means
you can exceed the physical memory size in your allocations.  By the time
you get near to exceeding the swapping space you have already started
thrashing so badly that the system is unusable anyway.

I think there may be a much better way to fix this problem.  Why not
take advantage of the Tcl object system?  When appending to a string
object, don't keep reallocating a single large buffer.  Instead, create
a chain of fixed-size buffers as a special internal representation.
When the value is referenced as a string, then you can convert it into
a single large buffer.  This approach should be much faster in the
common case where a string is appended to frequently without ever
being referenced.  It may be slightly slower if appends and references
are intermixed, but I bet it won't be much slower even in this extreme
case.

-John-

At 06:41 PM 8/29/2000 -0700, Eric Melski wrote:

>(apologies for the verbosity of this message)
>
>Gerhard Hintermayer sent me a patch to adjust the way that the Tcl core
>allocates memory for strings when growing them (via an append, for
>example).  Formerly, the growth algorithm was:
>
>         newsize = 2 * (oldsize + appendsize)
>
>Now, the growth algorithm is:
>
>         if (oldsize + appendsize >= TCL_GROWTH_LARGE_STRING)
>             newsize = oldsize + (2 * appendsize) +  TCL_GROWTH_MIN_ALLOC
>         else 
>             newsize = 2 * (oldsize + appendsize)
>         endif
>
>TCL_GROWTH_LARGE_STRING defaults to 1 megabyte; TCL_GROWTH_MIN_ALLOC
>defaults to 1 kilobyte, and is included to efficiently handle repeated
>small appends to a large string.
>
>The primary goal of this change was to increase the amount of memory that
>Tcl could allocate.  With the original algorithm, if you had a string that
>was about 1/2 of available memory, you could not add to it anymore,
>because it would try to allocate more than all of the available memory.
>With the new algorithm, you can effectively allocate all of available
>memory (depending on how you are growing the string -- once you get close
>to the maximum, you will have to append progressively smaller amounts, but
>you should be able to expand to fill all memory, if neccessary).
>
>However, a nice side benefit of the new algorithm is that it boosts core
>performance, across the board.  You can run the Tcl benchmark suite to see
>all the improvements; I have included just the [append] benchmarks here as
>these show the improvements most dramatically, I believe:
>
>000 VERSIONS:                    1:8.4a2 2:8.4a1
>001 STR append                        49      65
>002 STR append (1KB + 1KB)            42      45
>003 STR append (10KB + 1KB)          130     132
>004 STR append (1MB + 2b * 1000)   13163   21765
>005 STR append (1MB + 1KB)          7977   16320
>006 STR append (1MB + 1KB * 20)     8258   16497
>007 STR append (1MB + 1MB * 3)     33898   40935
>008 STR append (1MB + 1MB * 5)     41330   81164
>END VERSIONS:                    1:8.4a2 2:8.4a1
>
>Here, 8.4a2 includes the patch; 8.4a1 has the original behavior.  Nice
>work, Gerhard!
>
>    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.

________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
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: Staged commits ([TCT] Welcome...)

[Donald G P. <dg...@ca...>]

> > It is important that the decision to commit or not to commit 
> > each patch is ultimately left to one person, and we don't 
> > burden every commit with some kind of voting procedure. 
> 
> This is sometimes the case, but in gdb & gcc at least, there are
> often patches that cross functional areas, in which case you have to
> get several people to agree.  But this is the correct thing, in fact,
> because it assures that the people who really know each area are
> looking at the impact of the fix.

That makes perfect sense.  There is "voting" in the sense that all
maintainers influenced by a patch must agree in order for the patch
to be applied.  It also fixes responsibility when something gets
broken.

I'm for it; how to we crystallize this into a formal TCT proposal?

DGP

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

[TCLCORE] Hintermayer's string allocation patch

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

(apologies for the verbosity of this message)

Gerhard Hintermayer sent me a patch to adjust the way that the Tcl core
allocates memory for strings when growing them (via an append, for
example).  Formerly, the growth algorithm was:

	newsize = 2 * (oldsize + appendsize)

Now, the growth algorithm is:

	if (oldsize + appendsize >= TCL_GROWTH_LARGE_STRING)
	    newsize = oldsize + (2 * appendsize) +  TCL_GROWTH_MIN_ALLOC
	else 
	    newsize = 2 * (oldsize + appendsize)
	endif

TCL_GROWTH_LARGE_STRING defaults to 1 megabyte; TCL_GROWTH_MIN_ALLOC
defaults to 1 kilobyte, and is included to efficiently handle repeated
small appends to a large string.

The primary goal of this change was to increase the amount of memory that
Tcl could allocate.  With the original algorithm, if you had a string that
was about 1/2 of available memory, you could not add to it anymore,
because it would try to allocate more than all of the available memory.
With the new algorithm, you can effectively allocate all of available
memory (depending on how you are growing the string -- once you get close
to the maximum, you will have to append progressively smaller amounts, but
you should be able to expand to fill all memory, if neccessary).

However, a nice side benefit of the new algorithm is that it boosts core
performance, across the board.  You can run the Tcl benchmark suite to see
all the improvements; I have included just the [append] benchmarks here as
these show the improvements most dramatically, I believe:

000 VERSIONS:                    1:8.4a2 2:8.4a1
001 STR append                        49      65
002 STR append (1KB + 1KB)            42      45
003 STR append (10KB + 1KB)          130     132
004 STR append (1MB + 2b * 1000)   13163   21765
005 STR append (1MB + 1KB)          7977   16320
006 STR append (1MB + 1KB * 20)     8258   16497
007 STR append (1MB + 1MB * 3)     33898   40935
008 STR append (1MB + 1MB * 5)     41330   81164
END VERSIONS:                    1:8.4a2 2:8.4a1

Here, 8.4a2 includes the patch; 8.4a1 has the original behavior.  Nice
work, Gerhard!

   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: 8.x tasks

[Donald G P. <dg...@ca...>]

>> Hmmm.  I'm not familiar with these issues, but the descriptions sound
>> like feature enhancements (porting to new platforms, performance
>> improvements) rather than bug fixes. 

> While not necessarily bug fixes, these all fall under patch release
> items.  "Platform ports" are definitely not feature enhancements.
> Making things correct for IA-64 OSes is just like getting it right
> for AIX or HP-UX. 

The key word is "new".  AIX and HP-UX have been supported by Tcl/Tk
for years.  Support for Windows 64 and Windows 2K is new, right?
The 8.3.2 download page only claims to support Windows 95/98/NT.

<does some checking in the CVS log...>

OK, according to win/README.binary, Windows 2K has been supported
since the Tcl/Tk 8.3b2 release, so I stand corrected.  If Tcl or
Tk is not working properly on Windows 2K, I would consider that a
bug, and a certain bug fix would be in order in a patch release.
An "iffy" bug fix should still go through an alpha/beta sequence.
***Don't break patch releases***.

> Hmmm... can't find
> it right now, but it's something like:
> 
> 	* Major releases allow some change to backwards compatability,
> 	major new features
> 	* Minor releases allow new features (features being things like
> 	extending command syntax), but should maintain compatability as
> 	much as possible
> 	* Patch releases should be restricted to very certain fixes,
> 	should not add new features, and shouldn't affect compatability
> 	unless absolutely required (as was done in 8.3.2 to the IO C API
> 	to correct previous problems).

Well, I've made it clear many times that I favor a more precise statement
of and a stricter following of version labeling rules than is paraphrased
above.

The important thing, though, is that "patch releases should be restricted
to very certain fixes".  Anytime I see a major rewrite of a whole section
of the Tcl core coming out in a patch release with no alpha/beta testing
I get scared.  If porting to a formerly unsupported platform requires that
kind of a rewrite, I'd rather see it take place in the alphas and betas of
8.4, rather than run the risk of breaking a patch release.

>> [ Who will maintain Tcl/Tk 8.3.x ? ]

> In all cases that person is me, and I'm aware of whatever might be
> needed. 

OK, it's Jeff, so whether or not TCT is responsible doesn't really
matter, because either way Jeff will be leading this effort, assisted
of course, by everyone interested in fixing bugs in Tcl/Tk 8.3.x.

DGP

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

[TCLCORE] Re: 8.x tasks

[Donald G P. <dg...@ca...>]

> Dang, you trumped me.  As I said, I know of several things that could
> go into an 8.3.3:
> 
> 	* Fix the Windows 64 open sockets limitation
> 	* Look into improving the flushing on Windows
> 	* Correct Itanium support for Win64 (already OK on Linux64,
> 	  I'm working on the rest now)
> 	* Backport some speed enhancement from 8.4
> 	* Improve performance for append in large string cases (>1M)
> 	  (we have a working patch that we are further verifying)
> 	* Do further verification of Tcl/Tk on Win2K

Hmmm.  I'm not familiar with these issues, but the descriptions sound
like feature enhancements (porting to new platforms, performance
improvements) rather than bug fixes.  Things that can wait for Tcl 8.4.

> > I know there's at least one core dump bug in Tcl 8.3.2 because I
> > submitted it less than a week ago.
> 
> Oh, how I wish for a bug db that didn't require a human to input the
> data... I can't find your bug report on the above.

See http://www.deja.com/=dnc/getdoc.xp?AN=662186271

It's not unique to Tcl 8.3.2.  It's a core dump problem as far
back as I can test... to Tcl 7.5.

> I don't think that the TCT should focus on any 8.3 patch releases.
> It should be looking forward, not backward.  There are no feature
> discussions to have for 8.3, only bug fixes.  That's not to say that
> members of the TCT can't participate - help's always welcome.

That's an interesting perspective.  Does that mean that TCT's job
is only to develop new software, and it's up to others to maintain
what they release?  Who are those others?  Do they know?

> At this point, I think the TCT has enough on its plate worrying about
> getting a web site established and an infrastructure in place.  By
> the time that's done, 8.4 will be looming a lot closer.

I'm not suggesting another Tcl 8.3 release next week.  But if we need
someone else to step forward to maintain Tcl 8.3.x, that should be
announced.  The bug reports for Tcl/Tk 8.3.2 should be forwarded to
someone who won't ignore them.

DGP

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

[TCLCORE] Re: Staged commits ([TCT] Welcome...)

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

Don,

On Tuesday, August 29, 2000, at 09:51 AM, Donald G Porter wrote:

> Jim Ingham wrote: 
> > > I think that patches should in general be staged,  
> > > and posted publically before they are committed. 
>  
> D. Richard Hipp: 
> > Are there any counter-proposals? 
>  
> Actually I like this proposal.  My only concern is whether it 
> might keep development too slow.  So long as there are enough 
> maintainers committing changes to the various functional areas 
> of the code, that should not be a problem. 

With a maintainer & a backup maintainer, this has not bee a problem in the gdb world, and the Tcl code is much more clearly written than gdb, with lots fewer implicit dependencies, so the job should be easier for Tcl than for gdb.

>  
> It is important that the decision to commit or not to commit 
> each patch is ultimately left to one person, and we don't 
> burden every commit with some kind of voting procedure.  Everyone 
> can look,  everyone can comment, one person decides. 

This is sometimes the case, but in gdb & gcc at least, there are often patches that cross functional areas, in which case you have to get several people to agree.  But this is the correct thing, in fact, because it assures that the people who really know each area are looking at the impact of the fix.

>  
> In case this system does slow things down too much, let's not 
> forget the option of a less-Cathedral, more-Bazaar development 
> model.  We have the code in CVS.  If a commit breaks something, 
> we can always pull it back out.  The code releases will be 
> in alpha/beta for some time yet, so we can even modify or yank out 
> new features that turn out in practice to be a bad idea.  Sometimes 
> bad ideas only make themselves apparent when you try to work with 
> the changed code, not in a theoretical pre-commit discussion.  
>  

I am nervous about this for two reasons, one that you might not figure out something had problems till fairly far on in the process, and then there are new dependencies that have crept in on the change, etc...

Also, and this is the more important reason to me, the maintainer role is a very nice setup to encourage education about the overall design, and the particular coding conventions for the given project.  This has worked really well for gdb, and I have often learned alot both in the process of submitting changes to the reviewers.  The everyone commits and you fight out what breaks doesn't really have good opportunities for fostering new contributors...

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

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

[TCLCORE] ANNOUNCE: TLS v1.4 SSL/TLS extension

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

WHAT:   TLS v1.4, a portable extension for SSL that provides the
	power of SSL to Tcl programs. This extension can be used
	to utilize SSL encryption on top of any valid Tcl Channel
	- not just sockets!

WHERE:  http://www.sensus.org/tcl/index.htm
	http://www.sensus.org/tcl/tls.htm (documentation)
        ftp://ftp.scriptics.com/pub/tcl/tls/

REQUIREMENTS:   Tcl/Tk8.2+, compiling is required
	Works on Windows and Unix.  May work on Mac is someone
	gets the project files setup.
	User must have OpenSSL (v0.9.5a+ recommended) or RSA bsafe
	SSL libraries.

UPDATES FROM 1.3:

	TLS 1.4 was written specifically to address changes to the
	functionality of the stacked channel implementation in Tcl
	8.3.2+.  It is recommended that users of TLS use an 8.3.2+
	version of Tcl with TLS.

	TLS 1.4 will work however in any stubs-enabled version of
	Tcl starting with 8.2.0 (when stacked channels were introduced
	to the core).  If you require TLS in an earlier version of
	Tcl, please get 1.3 and apply the necessary patches, as the
	versions are functionally equivalent.

	TLS 1.4 introduces a much more robust test suite, modified
	internals, and a few bug fixes.  Otherwise it provides the
	same feature set as 1.3.  The directory structure has changed
	as the compile structure now uses TEA (same Makefile for
	Windows and Unix).

CONTACT:
	General:	Matt Newman, matt at sensus.org
	v1.4 changes:	Jeffrey Hobbs, hobbs at ajubasolutions.com

-- 
   Jeffrey Hobbs                     The Tcl Guy
   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.

[TCLCORE] Re: 8.x tasks

[Dan K. <ku...@aj...>]

> Hmmm.  I'm not familiar with these issues, but the descriptions sound
> like feature enhancements (porting to new platforms, performance
> improvements) rather than bug fixes.  Things that can wait for Tcl 8.4.

> * Fix the Windows 64 open sockets limitation
> * Look into improving the flushing on Windows
> * Correct Itanium support for Win64 (already OK on Linux64,
>   I'm working on the rest now)
> * Backport some speed enhancement from 8.4
> * Improve performance for append in large string cases (>1M)
>   (we have a working patch that we are further verifying)
> * Do further verification of Tcl/Tk on Win2K

In reference to the 'append' patch for large string cases:

If the the memory allocation routines in tcl are flawed
(they over allocate when dealing with large ammounts of
memory) is fixing that a bug fix or an enhancement?

As for the Itanium support and Win2K verification, I think
that it is *very* important that there be a release quality
version of tcl available on these platforms when they come
out.  If any bugs are found in tcl 8.3.2 that make it unusable
on Win2K, it is still a bug against 8.3.2, not a 'feature
enhancement'.  If the TCT takes the stance that supporting
standard platforms (like Windows on Itanium and Win 2K) is
a feature enhancement that can wait 4, 6 or 8 months people
will look at Tcl as a 'toy' language that can't be relied
on for commercial development.  No one who is using tcl in
a commercial product wants to wait months before they
can add support to a platform that their customers might
already be starting to deploy (like Win2K).

--Dan

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

[TCLCORE] Re: 8.x tasks

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

> From: Donald G Porter [mailto:dg...@ca...]
	...
> > Dang, you trumped me.  As I said, I know of several things that could
> > go into an 8.3.3:
	... [list elided] ...

> Hmmm.  I'm not familiar with these issues, but the descriptions sound
> like feature enhancements (porting to new platforms, performance
> improvements) rather than bug fixes.  Things that can wait for Tcl 8.4.

While not necessarily bug fixes, these all fall under patch release
items.  "Platform ports" are definitely not feature enhancements.
Making things correct for IA-64 OSes is just like getting it right
for AIX or HP-UX.  Somewhere is a definition that we have gone by
on what sort of fix should go in what release.  Hmmm... can't find
it right now, but it's something like:

	* Major releases allow some change to backwards compatability,
	major new features
	* Minor releases allow new features (features being things like
	extending command syntax), but should maintain compatability as
	much as possible
	* Patch releases should be restricted to very certain fixes,
	should not add new features, and shouldn't affect compatability
	unless absolutely required (as was done in 8.3.2 to the IO C API
	to correct previous problems).

	...
> > I don't think that the TCT should focus on any 8.3 patch releases.
> > It should be looking forward, not backward.  There are no feature
> > discussions to have for 8.3, only bug fixes.  That's not to say that
> > members of the TCT can't participate - help's always welcome.
>
> That's an interesting perspective.  Does that mean that TCT's job
> is only to develop new software, and it's up to others to maintain
> what they release?  Who are those others?  Do they know?
>
> > At this point, I think the TCT has enough on its plate worrying about
> > getting a web site established and an infrastructure in place.  By
> > the time that's done, 8.4 will be looming a lot closer.
>
> I'm not suggesting another Tcl 8.3 release next week.  But if we need
> someone else to step forward to maintain Tcl 8.3.x, that should be
> announced.  The bug reports for Tcl/Tk 8.3.2 should be forwarded to
> someone who won't ignore them.

In all cases that person is me, and I'm aware of whatever might be
needed. The fact is that 8.3 really is just in maintainance mode right
now.  There isn't anything serious enough (as noted above) that demands
an 8.3.3 right now.  If such is needed, I'm prepared to make that effort.
Patch releases are much easier than minor version changes, which in turn
are significantly easier than a major version change.

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: Staged commits ([TCT] Welcome...)

[Donald G P. <dg...@ca...>]

Jim Ingham wrote:
> > I think that patches should in general be staged, 
> > and posted publically before they are committed.

D. Richard Hipp:
> Are there any counter-proposals?

Actually I like this proposal.  My only concern is whether it
might keep development too slow.  So long as there are enough
maintainers committing changes to the various functional areas
of the code, that should not be a problem.

It is important that the decision to commit or not to commit
each patch is ultimately left to one person, and we don't
burden every commit with some kind of voting procedure.  Everyone
can look,  everyone can comment, one person decides.

In case this system does slow things down too much, let's not
forget the option of a less-Cathedral, more-Bazaar development
model.  We have the code in CVS.  If a commit breaks something,
we can always pull it back out.  The code releases will be
in alpha/beta for some time yet, so we can even modify or yank out
new features that turn out in practice to be a bad idea.  Sometimes
bad ideas only make themselves apparent when you try to work with
the changed code, not in a theoretical pre-commit discussion. 

Don Porter
dg...@ca...

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

[TCLCORE] Create our own patches newsgroup?

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

What do people think of creating our own
	comp.lang.tcl.patches
newsgroup (as suggested by someone else here already)?

It would be nice if we could use that already to send all the
BUG/RFE input that comes for the database.  It would also get
stored elsewhere, but it would be nice to have a single newsgroup
to go to to see the list of recent patches/bug reports.  The
newsgroup could be moderated, with Follow-Up to comp.lang.tcl
(althought sometimes the follow-ups for bugs have solutions).

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] 8.x tasks

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

I've moved this discussion to "tclcore"...

> From: Donald G Porter [mailto:dg...@ca...]
	...
> > Anyway, can you justify an 8.3.3 release?
>
> Mostly, I was following the lead of Jeffrey Hobbs, as quoted in
> http://dev.scriptics.com/lists/tclcore/2000/07/msg00071.html

Dang, you trumped me.  As I said, I know of several things that could
go into an 8.3.3:

	* Fix the Windows 64 open sockets limitation
	* Look into improving the flushing on Windows
	* Correct Itanium support for Win64 (already OK on Linux64,
	  I'm working on the rest now)
	* Backport some speed enhancement from 8.4
	* Improve performance for append in large string cases (>1M)
	  (we have a working patch that we are further verifying)
	* Do further verification of Tcl/Tk on Win2K
	...

There are more I could list (I have an inbox full of 'em...).

> Other than that,  I don't think a "stable" release of Tcl/Tk 8.4
> will be ready for several months.  It's important that the latest
> stable Tcl/Tk be maintained.  If "not enough" (whatever that means)
> bugs get reported on Tcl 8.3.2, then maybe Tcl 8.3.3 won't be necessary.
> I know there's at least one core dump bug in Tcl 8.3.2 because I
> submitted it less than a week ago.

Oh, how I wish for a bug db that didn't require a human to input the
data... I can't find your bug report on the above.

It's true that 8.4 is unlikely to reach "stable" before Spring of next
year, but when looking at another release, it's more important to focus
on whether there are enough "goodies" to put in it before going ahead.

> Can we agree that *if* there is a Tcl/Tk 8.3.3 release, it is the
> responsibility of the TCT?  If so, then it is also TCT's responsibility
> to monitor incoming bug reports on Tcl 8.3.2 in order to make the
> judgment whether an 8.3.3 release is needed.

I don't think that the TCT should focus on any 8.3 patch releases.
It should be looking forward, not backward.  There are no feature
discussions to have for 8.3, only bug fixes.  That's not to say that
members of the TCT can't participate - help's always welcome.

At this point, I think the TCT has enough on its plate worrying about
getting a web site established and an infrastructure in place.  By
the time that's done, 8.4 will be looming a lot closer.

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] [TCLCORE]-db2tcl

[<ki...@ti...>]

hello all,
          I'm not sure this is the right mailing list where to post my
question, but I try.
I'm a Tcl/tk developer and I try to install db2tcl
extension on AIX without success. 
It compiles tclsh right but when I start tclsh it gives
me the error:
      Symbol isql_init in tclsh is not defined

Have You any idea what's the problem?

Thank you very much if you want to answer me.
regards,
                         Marco De Bon

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

[TCLCORE] Re: [TCLCORE]-db2tcl

[Dan K. <ku...@aj...>]

This is not the appropriate place for your
question.

Please post your question to the newsgroup
comp.lang.tcl

--Dan

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

[TCLCORE] Re: -underline patch v. 0.2 [tcl gateway]

[Keiichi T. <bi...@ny...>]

Hi,
Thank you for your kind information.

I am going to give you some feedbacks on this patch. But currently I have no time
to test. I will test this patch on Japanese environment, probably by the end of
this week and will send you my first report. Thanks.

Keiichi

Laurent Duperval wrote:

> I'd like to have feedback on the general ideas in the patcch, specially from
> people like George Petasis and Keiichi Takahashi who use fonts that are
> outside of ISO Latin 1. If people like the idea and if the implementation
> doesn't suck too bad, there are a few more things to do:

--
Keiichi Takahashi, bitWalk Co.,Ltd.
mailto:bi...@ny...
http://members.xoom.com/tcltk/index.html





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