tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

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

On 11 Sep, Keiichi Takahashi wrote:
> In some short test pieces, some of troubles are found. Main trouble is related to
> text width of the widgets.
> 

Ok, I think I know what the problem is. To calculate the width of a widget,
I use the ::msgcat::mcmax function. The problem is that for a string like
OK, I user "OK" to calculate the width. My assumption was that the length of
"OK" and "O\_K" should be the same, since the \_ is pretty much like a
diacritic (I hope it's the right term). Evidently, that's not the case for
languages such as Japanese. ... Ok, I just patched the msgcat.tcl file and
these are the results I get:

# ja
::msgcat::mcmax OK
::msgcat::mcmax O\_K
% 2
% 5
% 

# en
::msgcat::mcmax OK
::msgcat::mcmax O\_K
% 2
% 2

The patch is attached and it should fix your problems.

Keep those problem reports coming!

L

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

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

[TCLCORE] if tests for "true" and "false"

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

Good morning.

How would folks feel about the following patch? It adds
two additional test for the strings "true" and "false"
in an if command. This is a feature that was recently
added to Jacl, and it seems to be something that
was not tested by the regular Tcl test suite.

Mo DeJong
Red Hat Inc


Index: ChangeLog
===================================================================
RCS file: /home/cvs/external/tcl/ChangeLog,v
retrieving revision 1.309
diff -u -r1.309 ChangeLog
--- ChangeLog	2000/09/08 04:00:08	1.309
+++ ChangeLog	2000/09/12 05:43:31
@@ -1,3 +1,8 @@
+2000-09-11  Mo DeJong  <md...@re...>
+
+	* tests/if.test: Added additional test that check
+	for boolean true and false in an if statement.
+
 2000-09-07  David Gravereaux <dav...@aj...>
 
 	* win/.cvsignore: changed the glob patterns a bit to exclude VC++
Index: tests/if.test
===================================================================
RCS file: /home/cvs/external/tcl/tests/if.test,v
retrieving revision 1.5
diff -u -r1.5 if.test
--- if.test	2000/04/10 17:19:00	1.5
+++ if.test	2000/09/12 05:43:32
@@ -1075,18 +1075,25 @@
         [unset iftracevar iftracecounter]
 } {1 {syntax error in expression "1 oops 10 + 20"} 0 {} {}}
 
+test if-11.1 {true and false} {
+    set bool true
+    set result 0
+    if {1 && $bool} {
+        set result 1
+    }
+    set result
+} {1}
+
+test if-11.2 {true and false} {
+    set bool false
+    set result 0
+    if {1 && $bool} {
+        set result 1
+    }
+    set result
+} {0}
+
 # cleanup
 ::tcltest::cleanupTests
 return

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

[TCLCORE] Re: Tk 8.3.2 tar file is hosed!

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

On Mon, 11 Sep 2000, David Gravereaux wrote:

> Mo DeJong <md...@cy...> wrote:
> 
> >Have you guys been having problems with your web server
> >recently?
> 
> YES!  Friday we were hosed by some script kiddies running random DoS attacks.
> Did you download it then?

Humm, are you sure you cleaned everything up?
Perhaps they broke in a left some modified
binaries sitting around.

I just downloaded the file today, it is working now
but it was broken earlier. I guess you can forget
about this if nobody else reports problems.

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: Tk 8.3.2 tar file is hosed!

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

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

>Have you guys been having problems with your web server
>recently?

YES!  Friday we were hosed by some script kiddies running random DoS attacks.
Did you download it then?
--
  David Gravereaux <dav...@aj...>      Yet Another Tcl Guy
  Sustaining Engineer (Tech Support)                  Ajuba Solutions
  (650) 230-4079

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

[TCLCORE] Re: [trace execute] for [onexit callback]

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

Vince,

> I had some spare time over the weekend, so I implemented 4 new options
> to 'trace add/remove command', in addition to the rename/delete options
> which are already in Tcl 8.4a2.

Nice work on your continuing efforts to improve [trace].

Please take a look at the patch in TR # 6174

	http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=6174

and incorporate its strategy of replacing ckfree() with Tcl_EventuallyFree(),
etc. into your expansions of [trace].

[trace] has a segfault problem, and your expansions will expand that
problem unless you amend them in this way.  See TR #6172 for a demonstration
of the segfault.

Let me know if you have any questions about #6174.

DGP

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

[TCLCORE] Re: Tk 8.3.2 tar file is hosed!

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

On Mon, 11 Sep 2000, Dan Kuchler wrote:

> 
> > I just tried to download the Tk tar.gz file for
> > 8.3.2. It is broken, the file was downloaded correctly.
> 
> Mo,
>   Can you expand on this problem a little more?
> I just ftp'd it (from ftp.scriptics.com) and ran
> the 'tar -tzvf' command you mentioned without any
> problem.
> 
> I downloaded it via a command line ftp client.
> Did you pull it from the web (I don't think that
> should make a difference..)

I clicked on the download link from the website.

http://dev.scriptics.com/download/tcl/tcl8_3/tk8.3.2.tar.gz

Saved it as:

/tmp/tk8.3.2.tar.gz

tar -tzvf /tmp/tk8.3.2.tar.gz

> Have you tried it from multiple machines with
> the same problem?

I tried it because someone else said they got the error.

Humm.

I just downloaded it again to double check, and this time
it did not bomb out.

That is really odd. I know I downloaded it two times before
and it was broken then.

Have you guys been having problems with your web server
recently?

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: No bug... BUG ?: memory leak using TclPro141 under NT 4.0

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

This is a bit of a standard gotcha, and I think that it should be
fixed.  The 'console' in the Windows/Mac implementation is *always*
there by default - whether you see it or not (as evidenced by the
fact that 'console show' is a great trick that people like to get
an eval console on other systems).

'puts' will put data into the console.  This has nothing to do with
Itcl (that's all a red herring).  Someone reported a similar "mem
leak" in tkcon, so I added a default saved line limit (like xterm
and all the rest have).  This doesn't help much if your data lines
are zigKB long, but it works for things like below.  The same could
be done for the console.

Even better would be to have that console just not exist when the
user is not running interactively, except via a package.  Something
like 'package require console'.  Then you could fix it up and add
more features, and even make it available on Unix.

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

> -----Original Message-----
> From: David Gravereaux [mailto:dav...@aj...]

> Subject: (fwd) [Fwd: BUG ?: memory leak using TclPro141 under NT 4.0]
> (fwd)
>
>
> I changed the code a bit to be the following:
>
> ------------------------
> package require Itcl
>
> itcl::class Ca {
>   public method Poll {}
> }
>
> itcl::body Ca::Poll { } {
>   puts "Inside Ca::Poll"
>   after 50 "$this Poll\;puts \"******** Poll called**************\""
> }
>
> Ca ObjA
> ObjA Poll
>
> if {[regexp {^(.*)tclsh} [info nameofexecutable]]} {
>   puts "spawning event loop"
>   vwait forever
> } else {
>   wm withdraw .
> }
>
> ------------------------
>
> running it under tclsh83, I observed no memory growth.
> running it under wish83, I did observe a large amount of growth.
>
> Changing the commandline to pipe output to the console, avoiding the console
> widget, I observed no memory growth:
> C:\Program Files\Tcl\bin> wish84.exe pollTest.tcl | cat32.exe
>
> So I'll assume, the console widget is growing it's storage to accommodate all
> the output.  I don't really see a bug with this.  I couldn't check with wish83
> piped due to a bug in win2k, that's checked for in 8.4.
> --
>   David Gravereaux <dav...@aj...>      Yet Another Tcl Guy
>   Sustaining Engineer (Tech Support)                  Ajuba Solutions
>   (650) 230-4079
>

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

[TCLCORE] Tk 8.3.2 tar file is hosed!

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

I just tried to download the Tk tar.gz file for
8.3.2. It is broken, the file was downloaded correctly.

% tar -tzvf tk8.3.2.tar.gz
...
-rw-rw-r-- hobbs/users   65874 2000-04-24 18:03:06 
./tk8.3.2/generic/tkCanvPs.c
-rw-rw-r-- hobbs/users   45688 1999-12-21 15:55:10 
./tk8.3.2/generic/tkCanvText.c
-rw-rw-r-- hobbs/users   39016 1999-12-16 13:57:35 
./tk8.3.2/generic/tkCanvUtil.c
tar: Skipping to next header

gzip: stdin: invalid compressed data--crc error
tar: 461 garbage bytes ignored at end of archive
tar: Child returned status 1
tar: Error exit delayed from previous errors

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] No 64-socket limitation on Windows

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

For any that were involved with the discussion of whether Tcl could
theoretically have a 64-socket listening capacity limit, this appears
to not affect Tcl because we use a slightly different API.  This was
from the URL:

http://www.cyberport.com/~tangent/programming/winsock/advanced.html#maxsockets

IOW, no worries, I've created 120 simultaneous active sockets with
no problems.  Strike one off the todo list.

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: message catalogs and Tcl/Tk patch for underlining

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

Hello Laurent,

The first attached file, ja.msg.gz is the Japanese translation for message
catalogs.

In some short test pieces, some of troubles are found. Main trouble is related to
text width of the widgets.

In tk_chooseColor, it does not work well. test05a.gif is the error message and
test05b.gif is the widget after skipping error. test05c.gif is the normal widget
of tk_chooseColor with Tcl/Tk8.3.2.

Testing environment is:
RedHat Linux 6.2 Japanese Edition

I think it necessary to test on MS Windows 98 and 2000. I will check on them
later. Thanks.

Keiichi

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

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

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

On 11 Sep, Keiichi Takahashi wrote:
> Hello Laurent,
> 
> The first attached file, ja.msg.gz is the Japanese translation for message
> catalogs.
> 

Thanks.

> In some short test pieces, some of troubles are found. Main trouble is related to
> text width of the widgets.
> 

The buttons, right? I see that the button in tk_messageBox isn't wide
enough. A quick glance through the code doesn't point to the problem. I'll
have a longer look tonight.

> In tk_chooseColor, it does not work well. test05a.gif is the error message and
> test05b.gif is the widget after skipping error. test05c.gif is the normal widget
> of tk_chooseColor with Tcl/Tk8.3.2.
> 

Ouch! There are missing "\" characters at the end of lines 281 and 284 of
library/clrpick.tcl. Looks like I never tested that piece of code, I
apologise. :-(

> I think it necessary to test on MS Windows 98 and 2000. I will check on them
> later. Thanks.
> 

Good idea. I don't have a proper Windows system to test on so if anyone else
can test on Windows and Mac, that would be great!

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: [trace execute] for [onexit callback]

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

At 03:06 AM 9/11/2000 -0700, Vince Darley wrote:
>I had some spare time over the weekend, so I implemented 4 new options to 'trace add/remove command', in addition to the rename/delete options which are already in Tcl 8.4a2.
>
>....
>
>There is no documentation or tests for the new code....
>
>Comments appreciated,

Thanks: it's always great for people to offer new Tcl features, and once
the Tcl Core Team is organized we hope to encourage this even more.
However, it's also really important that we do this in a way that
maintains the structure and stability of the Tcl code base.  Thus it is
very important that every new feature be accompanied by complete
documentation and tests (there is no one else to step in and do these
if you don't).

Perhaps you were just offering these patches as food for thought,
without intending that they would actually be entered into the Tcl
sources.  In that case, no documentation or tests are needed.  If, on
the other hand, you were hoping that your patches would be applied to
the Tcl source base, the documentation and tests are essential.  At this
point perhaps the best thing is to get comments, just in case it turns
out that the new features don't make sense.  If the team agrees that
they make sense, the next step would be for you to rework them to include
the documentation and test cases.  You'll also want to make sure that
your code conforms to the Tcl coding style; if you haven't already done
so, I'd strongly recommend that you read over the Tcl/Tk Engineering
Manual, which describes how to write tests, coding style guidelines,
etc.

-John-
________________________________________________________________________
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: [trace execute] for [onexit callback]

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

I had some spare time over the weekend, so I implemented 4 new options to 'trace add/remove command', in addition to the rename/delete options which are already in Tcl 8.4a2.

These new options are: before, after, preinside and postinside (the names for the last 2 are horrible, I agree!).

A patch is available at:

ftp://ftp.ucsd.edu/pub/alpha/tcl/tracecmdexec.diff.gz

Which should apply cleanly to the latest cvs pull.

There is no documentation or tests for the new code.  However all old tests pass, except for 6 in trace.test which fail because an error message has changed.

Here is an example:

administrator@TRAPPER //c/tclsource/tcl8.4cvs/win/Release
$ tclsh84
% proc onexit {script} { trace add command exit before "$script ; #" }
% onexit "puts hi"
% exit
hi

administrator@TRAPPER //c/tclsource/tcl8.4cvs/win/Release
$

The patch is reasonably complete: I've checked that stuff like deleting a trace or deleting a command while traces/commands are executing works ok.

Comments appreciated,

Vince.



--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.

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

[TCLCORE] Re: PROPOSAL (2nd) Limit memory doubling when appending to strings

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

This looks great to me.  My only concern is that it adds a lot of
new API functions to the core, but overall I think it's worth the
in addition.  Barring any objections, I think Eric should go ahead
and implement this.

-John-

At 11:58 AM 9/6/2000 -0700, Eric Melski wrote:

> > Solultion 3 - "Adaptive allocation" suggested by George
> > 
> > Retain the doubling algorithm until an attempt to allocate
> > memory fails.  When that occurs, reduce the growth by
> > halves until the allocation succeeds:
>
>I have an implementation of (basically) this adaptive allocation
>algorithm.  My implementation uses the following algorithm:
>
>attempt to allocate 2*(oldsize + appendsize)
>on failure, attempt to allocate oldsize + (2 * appendsize) + TCL_MIN_GROWTH
>on failure, panic
>
>This is based on some new allocation routines:
>
>Tcl_AttemptRealloc
>Tcl_AttemptAlloc
>Tcl_AttemptDbCkalloc
>Tcl_AttemptDbCkrealloc
>
>Each of these is identical in function to the Tcl function of the same
>name less the Attempt bit, except that the Tcl_Attempt* functions do _not_
>panic on failure to allocate memory.  In addition, I added the function
>
>Tcl_AttemptSetObjLength
>
>Which is functionally identical to Tcl_SetObjLength except that it uses
>the Tcl_Attempt* allocators, so it will not panic on failure.  It returns
>0 for failure, 1 for success.
>
>These functions are used together to implement the adaptive growth
>algorithm.  Note that the smaller growth allocation is not used until the
>doubling allocation has failed, so this modification will not affect any
>existing programs.  It strictly enhances the capabilities of Tcl to
>allow the use of more memory.  In addition, it does not cause any
>noticeable performance penalty; for the normal case (the double allocation
>is successful), it cause one additional integer comparison.  For the other
>case (the double allocation is not successful), the original Tcl interp
>would just panic, so we can't really compare performance there.
>
>On my system (448 MB of total memory, with X and a couple of applications 
>running, for a total of about 400 MB free according to 'top'), running the
>attached script "testGrowth.tcl", produces the following results with an
>unmodified Tcl:
>
>----
>total 10000000
>total 20000000
>.
>.
>.
>total 290000000
>total 300000000
>unable to realloc 620000001 bytes
>Abort
>----
>
>And with the new algorithm:
>
>----
>total 10000000
>total 20000000
>.
>.
>.
>total 390000000
>total 400000000
>unable to realloc 420001025 bytes
>Abort
>----
>
>With this new algorithm, I am able to use an additional 100 MB of the
>memory on my machine.
>
>Running the tclbench string append benchmarks produces the following
>results:
>
>8.4a1: 8.4a1 patched to use realloc as appropriate for appends
>8.4a2: Same as above, with fallback algorithm for failure on doubling alloc's
>
>000 VERSIONS:                     1:8.4a2 2:8.4a1
>001 STR append                         50      51
>002 STR append (1KB + 1KB)             41      43
>003 STR append (10KB + 1KB)           131     129
>004 STR append (1MB + 2b * 1000)    12563   12507
>005 STR append (1MB + 1KB)           7775    7752
>006 STR append (1MB + 1KB * 1000)   32360   32724
>007 STR append (1MB + 1KB * 20)      7981    8115
>008 STR append (1MB + 1MB * 3)      31842   32067
>END VERSIONS:                     1:8.4a2 2:8.4a1
>
>As you can see, the numbers are effectively equal; differences can be
>chalked up to system "noise".
>
>The patch is attached for your review, if you like.  It includes
>documentation for the new functions.
>
>Are there any objections to incorporating this modification into the core?
>
>    Eric Melski                            The Other Tcl Guy
>    ericm at ajubasolutions.com            Ajuba Solutions
>

________________________________________________________________________
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: RFC/PEP format

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

 
> Although I am not on the core team, I would like to propose to them
> that a RFC/PEP system be put in place soon to allow RFC/PEP type
> proposals and discussions to begin.
 
> I thought the core team was ready to start recieving these messages,
> but Mark Harrison said in the news group that you are not:

Unfortunately true.
 
> (snipped from comp.lang.tcl):
 
> To start recieving RFCs I don't think there is too
> much work that needs to be done.
 
> The process used by Perl and Python is almost identical.
> You can read about them at:
> 
> http://dev.perl.org/
> 
> and
> 
> http://python.sourceforge.net/peps/
> 
> (please note that the first link in the list of
> PEPs is the PEP that describes what a pep is and
> how it works)
> 
> I would also like to suggest some type of semi-regular
> status update from the development team/core team to
> the community to keep them up to date, similar to this
> one in python:
> 
> http://starship.python.net/crew/amk/python/dev/
> 
> I would be willing to do the work to get a web
> archiving system in place similar to the ones used
> for the PEP/RFC sites used by perl and python
> (both pages are pretty simple) if the core
> team is ready for this to be setup.


Something like in the attachement ?  (Both 'expand' and TclHttpd
should be able to use the code, despite it being originally written
for expand).

 
> It seems like this is needed in the near term
> so that the development for 8.4 can continue
> as there are several proposals that currently
> are ready to be discussed.

Correct. And others ready to be worked on (like the SDK/Sumo).


> Thanks,
>   --Dan

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

Re: [TCLCORE] RFC/PEP format

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

 
> Although I am not on the core team, I would like to propose to them
> that a RFC/PEP system be put in place soon to allow RFC/PEP type
> proposals and discussions to begin.
 
> I thought the core team was ready to start recieving these messages,
> but Mark Harrison said in the news group that you are not:

Unfortunately true.
 
> (snipped from comp.lang.tcl):
 
> To start recieving RFCs I don't think there is too
> much work that needs to be done.
 
> The process used by Perl and Python is almost identical.
> You can read about them at:
> 
> http://dev.perl.org/
> 
> and
> 
> http://python.sourceforge.net/peps/
> 
> (please note that the first link in the list of
> PEPs is the PEP that describes what a pep is and
> how it works)
> 
> I would also like to suggest some type of semi-regular
> status update from the development team/core team to
> the community to keep them up to date, similar to this
> one in python:
> 
> http://starship.python.net/crew/amk/python/dev/
> 
> I would be willing to do the work to get a web
> archiving system in place similar to the ones used
> for the PEP/RFC sites used by perl and python
> (both pages are pretty simple) if the core
> team is ready for this to be setup.


Something like in the attachement ?  (Both 'expand' and TclHttpd
should be able to use the code, despite it being originally written
for expand).

 
> It seems like this is needed in the near term
> so that the development for 8.4 can continue
> as there are several proposals that currently
> are ready to be discussed.

Correct. And others ready to be worked on (like the SDK/Sumo).


> Thanks,
>   --Dan

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

[TCLCORE] Re: [trace execute] for [onexit callback]

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

(sorry for the delay in replying: this email is not really read often; please reply to 'vi...@bi...').

On Thu, 31 Aug 2000 08:49:16   Eric Melski wrote:
>
>On Thu, 31 Aug 2000, Donald G Porter wrote:
>
>> From: Brent Welch <we...@aj...>
>> > 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?
>> 
>> Couldn't this just be an application of Vince Darley's proposed
>> [trace execute] command?
>
>This depends on which vision of [trace execution] you are referring to.
>With Vince's original patch, no; with the latest stuff he sent to me,
>maybe.  Vince can probably answer better than I.

Eric is right, you can't quite do this with my patch.  However, Eric's suggestions has to how to modify my patch to make it more 'Tcl-like' would allow this behaviour.  The only remaining issues are the precise implementation and whether it should go into the core, or whether the core should have just a minimal patch so that this behaviour could go into an extension.

Right now, I've written such a minimal patch (which Eric has), so that Tcl 8.4a2 has the internal APIs which would allow this.

Given that, we need a new trace-command to provide execution traces from Tcl, so that a Tcl callback is called under one or more of the following circumstances.  For clarity lets assume 'foo' is the procedure being traced:

My callback should execute:

(i) just before 'foo' is called.
(ii) just after 'foo' is called.
(iii) just before each command _inside_ foo is called.
(iv) just after each command _inside_ foo is called.

Various flags/options must be given to differentiate between these possibilities.

(i,ii) are useful for profiling, 'atexit' functionality etc.
(iii,iv) are useful for debugging purposes.

(i,iii) should have access to both the command name and the arguments it receives.
(ii,iv) should have access to the result of the command which just executed.

That is my vision for 'execution traces'.  Various frills can be added (such as only trace if current stack level is < N or > M, or only trace 'inside' if current relative depth is < N, etc).  For this kind of purpose it may therefore be useful if the callback also had access to the current stack depth.

Assuming all of the above is sensible, we need to work out the commands to add and remove such traces.

Eric (and others) have suggested adding this to 'trace add|remove command ...', so that instead of 'rename', 'delete' as the only options, we now have 'execution' as another option.  Now we need to decide how to allow the user to declare items (i)...(iv).  These could be more options:

trace add|remove command foo {rename delete execution postexecution internal postinternal} tcl_callback

or something like that.  This would seem to work, except there is then perhaps some confusion over what argument 'tcl_callback' should receive.  In the 'rename/delete' cases, the behaviour in Tcl 8.4a2 at present seems eminently sensible ('tcl_callback foo rename').  However, execution traces would require different information:

tcl_callback foo execution argument_list stack_level

tcl_callback foo postexecution result stack_level

tcl_callback foo internal argument_list stack_level

etc.

Perhaps: 'tcl_callback {foo argument_list} execution stack_level' would be better?

An alternative (which I initially preferred, but am now in two minds about) is to decide execution traces are quite different to command traces, and to add:

trace {add|remove} execution {before after interal postinternal} tcl_callback

any thoughts on this?  Another alternative is to add another syntax such as '%p %a %l' to allow the callback to have substituted in the procedure name, arguments and stack level, as it seems fit.  I don't like this approach at all, since it just adds yet another weird sub-syntax to Tcl.  

It seems there are two main questions:

(1) does this need to go in the core?
    No: do we need a patch to allow an extension to do this?
    Yes: go to question 2.

(2) should this be implemented as more options to the existing command traces, or as a new 'execution' trace type? 

Vince.





--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.

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

[TCLCORE] RFC/PEP format

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

Although I am not on the core team, I would like to
propose to them that a RFC/PEP system be put in place
soon to allow RFC/PEP type proposals and discussions
to begin.

I thought the core team was ready to start recieving
these messages, but Mark Harrison said in the news
group that you are not:

(snipped from comp.lang.tcl):

> > ku...@aj... (Dan Kuchler) wrote:
> >>Paul,
> >>  Could you write up a proposal (following the form suggested
> >>in the tclcore mailing list) for this thread for the
> >>TCT.
> 
> Yikes, please don't do that yet!
> 
> The tct is just now
> figuring out how it's operating, and we've already
> been hit by one premature submission that took away
> a lot of time and ended up confusing the original
> proposer half to death.

To start recieving RFCs I don't think there is too
much work that needs to be done.

The process used by Perl and Python is almost identical.
You can read about them at:

http://dev.perl.org/

and

http://python.sourceforge.net/peps/

(please note that the first link in the list of
PEPs is the PEP that describes what a pep is and
how it works)

I would also like to suggest some type of semi-regular
status update from the development team/core team to
the community to keep them up to date, similar to this
one in python:

http://starship.python.net/crew/amk/python/dev/

I would be willing to do the work to get a web
archiving system in place similar to the ones used
for the PEP/RFC sites used by perl and python
(both pages are pretty simple) if the core
team is ready for this to be setup.

It seems like this is needed in the near term
so that the development for 8.4 can continue
as there are several proposals that currently
are ready to be discussed.

Thanks,
  --Dan

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

[TCLCORE] Re: Why Python moved to SourceForge ([Fwd: What is tcltk.com?])

[Mark H. <ma...@us...>]

Jeffrey Hobbs <jef...@aj...> wrote:
> Well, this is pretty clear.  Remember that Python only really uses
> SF for CVS stuff (as I noted before).

Are you sure about this?  It seems they using several of the other
services as well.  Glancing around, I would say that the bug manager,
patch manager, and project manager seem to be well thought out
and quite useful.  Even their mailing lists are quite a step
up from what is available on the current dev site -- they allow
web or email based self- and group- administration, etc.

Additionally, following the form of the bug tracker and patch
manager might make it a bit easier to hash out the procedures
the TCT might use.

I'm still failing to understand this desire to do everything
ourselves with no outside assistance.  Perhaps somebody could
enlighten me?

At any rate, I encourage all TCT members to browse some of the
SF things and see what they think.

from http://sourceforge.net/projects/python/ :

Public Areas 
 Project Homepage
--------------------------------------------------------------------------------
 Bug Tracking ( 127 open bugs, 297 total ) 
--------------------------------------------------------------------------------
 Patch Manager ( 8 open patches, 350 total )
--------------------------------------------------------------------------------
 Project/Task Manager 
  - Python 2.0 
  - Python 1.6
--------------------------------------------------------------------------------
 CVS Repository ( 4014 commits, 227 adds ) 


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

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

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

Laurent Duperval <lau...@uf...>
> Giorgos Petasis wrote:
>> Updated catalog for the Greek language attached...
> Thanks!

I noted two embarrasing typos, with the A\_bort line for the "el"
catalog, and the E\_dit line in the same catalog; the language is set
to "fr" for one line and "en" for the other!  You'll probably want to
fix those...  :^)

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] Re: message catalogs and Tcl/Tk patch for underlining

[Giorgos P. <pe...@ii...>]

In Ôåô, 06 Óåð  2000, Laurent Duperval wrote:
> 
> Juan Carlos Gil Montoro wrote:
> > 
> > Laurent Duperval wrote:
> > >
> > > Hi all,
> > >
> > > As promised, here are the new message catalogs that need translating. The
> > > only catalogs which have the complete set are fr and en so you can take a
> > > look at those to see what's missing in you catalog.

Updated catalog for the Greek language attached...

George

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

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

Giorgos Petasis wrote:
> Updated catalog for the Greek language attached...
> 

Thanks!

L

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

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

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

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

[Juan C. G. M. <jc...@gm...>]

Laurent Duperval wrote:
> 
> Hi all,
> 
> As promised, here are the new message catalogs that need translating. The
> only catalogs which have the complete set are fr and en so you can take a
> look at those to see what's missing in you catalog.
> 

Please find attached the catalog for the spanish language, es.msg.

Regards,

Juan Carlos---

[TCLCORE] Re: message catalogs and Tcl/Tk patch for underlining

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

On  7 Sep, Juan Carlos Gil Montoro wrote:
> Laurent Duperval wrote:
>> 
>> Hi all,
>> 
>> As promised, here are the new message catalogs that need translating. The
>> only catalogs which have the complete set are fr and en so you can take a
>> look at those to see what's missing in you catalog.
>> 
> 
> Please find attached the catalog for the spanish language, es.msg.
> 

Cool, thanks!

L

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

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


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

[TCLCORE] Re: PROPOSAL (2nd) Limit memory doubling when appending to strings

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

Eric said:
***********************
> Solultion 3 - "Adaptive allocation" suggested by George
> 
> Retain the doubling algorithm until an attempt to allocate
> memory fails.  When that occurs, reduce the growth by
> halves until the allocation succeeds:

I have an implementation of (basically) this adaptive allocation
algorithm.  My implementation uses the following algorithm:

attempt to allocate 2*(oldsize + appendsize)
on failure, attempt to allocate oldsize + (2 * appendsize) + TCL_MIN_GROWTH
on failure, panic
***********************

Cool - thanks for the patch!  The bulk of it is the realloc and attempt
variations.  Your adaptive algorithm isn't quite as nifty as the one that
repeatedly halves the request space as mentioned in "Solution 3", but
I can also see the charm in making a single second attempt.  For folks
that glazed over the patch, the TCL_GROWTH_MIN_ALLOC constant is 1K.
This is there to give some extra room when small amounts are added to
a string.

--	Brent Welch	<we...@aj...>
	Scriptics has become "Ajuba Solutions"
	http://www.scriptics.com => 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.