tcl-core — Tcl Core Team discussions about Tcl development

[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.
> 
  fr.msg has a split line for the message starting in line 19,
  is that intended ?

Juan Carlos---

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

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

> 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

[TCLCORE] Re: PROPOSAL: Exporting Photo Image Transparency Hook

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

> From: Donal K. Fellows [mailto:fel...@cs...]
	...
> I propose that the patch referred to in in bug-database ticket 5947 be
> applied to Tk (or at least an equivalent version updated to the
> current CVS version, obviously!)

When making proposals, I think we need to be sure to clarify that
it is just that, and format the proposal in a manner that is easy
to read and break down, just as announcements should clearly state
the "who, what, where and why".

There are the standard formats like RFCs, as well as Python's
Enhancement Proposals (PEPs):
	http://python.sourceforge.net/peps/

We have the ability to store RFE's now in the bug db, but we don't
enforce any formatting.  A PEP starts standard with the following
info:
	ID, Title, Version, Owner, Version-of-core, Status, Type, Created

The rest depends on the status and type.

This proposal would look something like (note also change in Subject):

===================
ID:		5947
Title:		Export Photo Image Transparency Hook
Version:	1.0
Owner:		Donal Fellows <fel...@cs...>
Tcl-Version:	8.4a2 (Tk)
Status:	Proposed (??) patch-ready
Type:		Core Patch
Created:	5-Sept-00

Summary:
> To summarise, it gives access (via tkInt.h/stubs) to the transparency
> data contained within photo images, which is currently stored in a
> private field of a structure that is only defined within a single file
> (generic/tkImgPhoto.c FYI) which will make writing code that uses that
> sort of thing possible (most notably, it will make doing interesting
> things with shaped windows much easier, as is particularly useful with
> tkdnd <URL: http://www.deja.com/getdoc.xp?AN=666304100 >.)  It also
> should not break any existing code at all.

Patch:
> The relevant details of the behaviour of the patch are visible at:
>   http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=5947

Notes:
> I accept that a more complete interface to the transparency data would
> be nice, but let's do one thing at a time...  :^)
======================

As pertinent comments come through, the proposal would get updated
(and the version incr'd) by the owner.

BTW, I think the image mechanism could use several more hooks, but I
give a YES to this one.

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] Exporting Photo Image Transparency

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

I propose that the patch referred to in in bug-database ticket 5947 be
applied to Tk (or at least an equivalent version updated to the
current CVS version, obviously!)

The relevant details of the behaviour of the patch are visible at:
  http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=5947

To summarise, it gives access (via tkInt.h/stubs) to the transparency
data contained within photo images, which is currently stored in a
private field of a structure that is only defined within a single file
(generic/tkImgPhoto.c FYI) which will make writing code that uses that
sort of thing possible (most notably, it will make doing interesting
things with shaped windows much easier, as is particularly useful with
tkdnd <URL: http://www.deja.com/getdoc.xp?AN=666304100 >.)  It also
should not break any existing code at all.

I accept that a more complete interface to the transparency data would
be nice, but let's do one thing at a time...  :^)

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

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

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.
> >
>   fr.msg has a split line for the message starting in line 19,
>   is that intended ?
> 
> Juan Carlos---

Nope. Vi strikes again. Here is the corrected version.

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!

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

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

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.

Yesterday I told you to use MSGEdit to modify the catalog entries. I have to
step back from that statement a bit. The patch I'm giving you provides a new
escape sequence to do underlining: \_. This sequence isn't recognised by
MSGEdit so reading and writing the files doesn't quite give the right
results. But, MSGEdit is really nice for determining which strings haven't
been translated yet. When you bring up the MSGEdit window, anything in
yellow means that the string is the same as the English one. That can help
you see what you may have failed to translate.

I am sending a copy of this message to the author of MSGEdit to see if he
will patch it to support the \_ construct. I think that even if it's not a
patch that is currently not part of the core, it shouldn't hurt anything
since \_ isn't a supported escape sequence.

In this message, you have a patch to apply to tcl and one to apply to tk. I
supposes that you are using the latest cvs sources (well, this morning's
sources at any rate). I'm also sending the catalog files as a zipped file so
you can do the transalations without patch the Tcl sources.

The patches contain new tests for regexp and button. The regexp test will
fail because I haven't figured out where to patch the core to get the
behaviour I want. Hopefully by the end of the week I'll have fixed this.

If you want to contribute more tests and if you want to add documentation
for this, I definitely will not hate you for it. :-)

If you have problems with the patch or the translation, don't hesitate to
contact me.

Have fun!

L


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

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

[TCLCORE] Re: Test Results (-underline patch v. 0.2 [tcl gateway])

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

Hi, Laurent,

> > I've tested new underline sequence with the patch you sent and also modified it
> > according to Scott's comment..
>
> What do you mean "modified"?

Sorry for confusion.
I modified in generic/tkButton.c after patched the file you gave.
This is accoding to the mail from Scott:
-------
> This code seems to be confused.  You should replace the code above with:
>
> Tcl_IncrRefCount(valuePtr);
> Tcl_DecrRefCount(butPtr->textPtr);
> butPtr->textPtr = valuePtr;
> ButtonComputeUnderline(butPtr);
-------



> Wonderful!
>
> FYI, I've started modifying the message file to use this. I'm also removing
> all -underline stuff in the dialogs. If Real Work doesn't get in the way, it
> should all be ready tomorrow. I'm still having a problem with using {\_} in a
> regexp but I'm hoping that can be fixed soon.
>

Let me confirm that this patch affect only on Button's underline sequense. Is this
true?
It would be great if underline on entry of Menu and Menubutton bahave same as
Button's. Currently they don't work.

Keiichi

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

[TCLCORE] Re: TCT behavior (was: Using our time well)

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

George Howlett <gah@blueberry> wrote:
>Eric Melski wrote:
[about Gerhard]

I talked to Gerhard, he didn't realize he was getting "real time"
discussions.  I told him we were a bunch of beginners at this
TCT thing... he's cool now.

Mark.

PS George, fix your return address...

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

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

Paul Welton:
>>> Because if I am intercepting a procedure in a namespace that I am not
>>> responsible for, I cannot choose a name with total confidence that it
>>> will not collide with an existing name or one that may be used in future.

Brent Welch wrote:
>> [info command] will help you pick a name that does not collide.

Paul "I've got 90 columns" Welton:
> It helps in the sense that you can choose a name that is not in use at
> the time, but another file may be sourced later which may attempt a
> declaration that collides with the name you picked.

Also, the [info command] suggestion forces one to make dynamic selection of
the new command name.  Many programmers will be much more comfortable using
a particular name they choose, in the namespace they control, not one they
have to generate at run time.

> I suggested a "renameAuto" procedure in my posting of 25th August,

That also implies dynamic selection of the new command name, although some
of the headaches get taken care of by some library code.

However, all that complexity can be avoided if Tcl just provides a
[rename] with closure semantics.  That's clearly the better solution.

> How about "rename -keepscope" for the closure semantics?

Now you're on the right track.  Extending a broken command with
a switch to make it work properly seems ugly to me, though.  
(How do you rename a command named "-keepscope", etc....)

Although I can't think of a legitimate use for [rename]'s current
behavior, it's been behaving that way since Tcl 8.0p0, so it's
probably a bad idea to change it now, even if we can't get anyone
to step forward and claim the change would break their code.

Note also that the Tcl 9 wish list at the Tclers' Wiki observes
that the use of [rename] to delete a command ([rename foo ""])
is quite non-intuitive.  It also prevents the renaming of a command
to have the new name "".

Since [rename] has multiple problems, I propose leaving it alone to
keep existing scripts working, and offering a new command to replace
its functionality in a saner way:

	::tcl::command delete $cmd
		deletes the command named $cmd from the current interp

	::tcl::command rename $oldName $newName
		renames command named $oldName to have name $newName
		with proper closure semantics.

Both of those subcommands would interpret all command names relative
to the current namespace.

The more important change to make is in the educational materials
which describe how to replace an existing command with your own
implementation.  Make sure they use the new command properly and explain
why using [rename] is a bad idea in the age of namespaces.

DGP

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

[TCLCORE] Just a test

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

This is just a test: did you guys receive any of my emails today and last
week? You usually answer within a few hours but so far I've heard deafening
(sp?) silence. I was wondering if my MUA was to blame.

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

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

(As a meta-point, I can't find Paul's August 18 posting in deja.com, and I'm
afraid I don't have much time to keep current.  If folks cite the group,
please do it like Eric did and include the Deja article number so we can
easily find it.  Eric - is there an easy way to get such citations?)

It appears you can implement rename with closure semantics for Tcl procs,
but not for C commands.  This is my code, and Paul's version is probably
very similar:

proc renameClosure {old new} {

    if {[catch {info body $old} body]} {
        # C command, or byte-code compiled command
        return -code error "$old has no procedure body"
    }

    set old [uplevel 1 [list namespace origin $old]]
    set oldNamespace [namespace qualifiers $old]
    rename $old $new
    set new [uplevel 1 [list namespace origin $new]]
    set newNamespace [namespace qualifiers $new]
    if {[string equal $oldNamespace $newNamespace]} {
        return ""
    }
    set arglist {}
    foreach a [info args $new] {
        if {[info default $new $a value]} {
            lappend arglist [list $a $value]
        } else {
            lappend arglist $a
        }   
    }

    proc $new $arglist [list \
        namespace inscope $oldNamespace $body \
    ]
}

I'm making a posting to c.l.t. to see if anyone out there has usefully
exploited the current semantics of Tcl rename.

>>>Paul Welton said:

 > > I think this last point touches on the reasons for the current semantics.
 > > You are unlikely to change the definition of the procedure, but there is
 > > a ordering problem between the rename and when you bytecode compile the co
     mmand.
 > > If you do the rename before the procedure has been executed, then Tcl
 > > would end up compiling in the context of the new namespace.  However, if
 > > the procedure was executed once first, it would have been compiled in
 > > the context of the original namespace.
 > 
 > This did not happen with Donal Fellow's original example in his posting of 1
     5th August
 > - ::A::foo was executed in ::A, and therefore presumably byte-compiled, but 
     when moved
 > to ::B it picked up the ::B variable.

Right - because Tcl is in fact throwing away the byte-codes and recompiling.
I was speaking in the context of the original namespace implementation when
we were learning how things worked...  Originally it didn't throw away the
byte-codes so the problem I describe was real.

 > > So, you have to do something
 > > special or you get different results depending on if the procedure
 > > had been compiled already or not.  I think the easy solution was to
 > > toss the bytecodes at the time of rename, so Tcl would "naturally"
 > > compile the procedure in the context of the new namespace.
 > 
 > In my posting of 15th August I suggested redeclaring the procedure in anothe
     r namespace
 > but wrap it using "namespace code" for execution in the original namespace. 
     I had
 > expected objections to be raised that "namespace code" has limitations so th
     at it is
 > not a general solution, but no comments have been made. If it does work gene
     rally, then
 > an implementation would be to make rename between namespaces add this extra 
     step. Still
 > have the problem of 'C' procedures and built-ins though.
 > 
 > > So now I'm in a quandry.
 > 
 > How about "rename -keepscope" for the closure semantics?
 > 
 > 

--	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] Missing patch!

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

Whatever happened to my validRegion request?

  http://www.deja.com/getdoc.xp?AN=639183238

I submitted it using the bugDB form, but it never seemed to make it
into the database itself!  It would be very nice if the patch
mentioned:

  http://www.cs.man.ac.uk/~fellowsd/tcl/validRegion.patch

could be applied so I can definitely promise support for extracting
window shapes from photo images as described in

  http://www.cs.man.ac.uk/~fellowsd/tcl/shapeidx.html#latest

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: 8.4a2 release date (WAS Test Results (-underline patch v. 0.2 [tcl gateway]))

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

As stated before, the a2 ship date is imminent (this week hopefully,
next week at the latest).  There will be further alphas, so it is not
a rush to get all the translation stuff done now.  The main intent for
a2 is to bring the IO channel code in sync with 8.3.2.

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

> -----Original Message-----
> From: Laurent Duperval [mailto:lau...@ne...]
	...
> Can someone tell me what the expected shipping date for a2 is? And can you
> also say what happens if all the translation stuff isn't complete by that
> date?

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

[TCLCORE] Re: Test Results (-underline patch v. 0.2 [tcl gateway])

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

On  5 Sep, Keiichi Takahashi wrote:
> Let me confirm that this patch affect only on Button's underline sequense. Is this
> true?
> It would be great if underline on entry of Menu and Menubutton bahave same as
> Button's. Currently they don't work.
> 

Hmmm... Peer review is a Good Thing. I thought the same code was used for
menu labels, menu buttons, buttons, radio buttons and labels. I actually
didn't check to make sure the other types of buttons worked. I'll try to
check all that tonight. If it isn't working across the board, then it's a
bug and I have to fix it. 

Whether I fix this bug or not, I will still try to send the message catalogs
out by tomorrow afternoon. I'll explain what the changes are and what you
have to look for when doing the translations. I encourage you to get the
latest version of MSGEdit to help you do the UTF/Unicode/ascii encodings
properly. I don't havea URL handy but a message was posted to this effect
not too long ago on compl.lang.tcl.

I already noticed that in the initial round of translation, some strings
were not modified (File, Edit, Cut, Close, etc.).

Can someone tell me what the expected shipping date for a2 is? And can you
also say what happens if all the translation stuff isn't complete by that
date?

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] Fwd: Tk localisation to Polish

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

Hello,

Can Bartek Ziolkowski be added to the list of contributors for transaltions,
please?

Thanks,

L

------ Forwarded message ------
      From: "Bartek Ziolkowski" <bar...@ve...>
   Subject: Tk localisation to Polish
      Date: Mon, 4 Sep 2000 13:40:18 +0200
        To: <lau...@Ne...>

Hi,

I've just read on the Tcl'ers Wiki page (btw. what the heck does "Wiki" mean?)
about localisation of Tk widgets. I thougth I could translate them to Polish.
Could You send me info on how to do it?

Best regards,
/---------------------------------------------------------/
  Bartlomiej Ziolkowski
  Software Engineer @ VMF R&D Team
  Vertel Poland
  mail: bar...@ve...
  phone: +48.61.86.49.444
/---------------------------------------------------------/


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

[TCLCORE] Re: An article about the Cygnus tree

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

Jeff,

On Tuesday, September 5, 2000, at 10:23 AM, Jeffrey Hobbs wrote:

> This is an interesting thread that came through Slashdot about the way 
> that the Cygnus CVS tree works.  What started off as another CVS repo 
> for Cygnus has become the dependent build tree for gcc.  This is an 
> interesting read because as we focus on how we would build a Tcl SDK, 
> we want to make sure to avoid the politics and pitfalls that hit the 
> Cygnus gcc guys.  One basic thing being that Tcl should always be able 
> to work independent of the Tcl SDK (and its build framework). 
>  

The main point of an article that Michael Sokolov sent out (ftp://ivan.Harhan.ORG/pub/embedded/cygnus-tree-intro) on as a part of this thread was that the lack of a coherent unified tree was a real pain in the neck for most GNU tools developers.  So while I agree with your last statement, this quite nice article from the discussion you are citing has kind of the opposite thrust (which I ALSO agree with :-) namely that we should work to provide a coherent toplevel configure/make  for Tcl/Tk/Itcl/BLT/TclX/... that works like the Cygnus tree does for the Gnu tools.  This makes the whole suite SO much easier to manage, and avoids duplication of work in the least interesting & most tedious parts of any software project, the build & install machinery...  It can also (through the use of a unified configure cache) make the configure part of the whole tree MUCH faster.  Then if we are clever about writing a good modules file, extracting bits of the tree, and for instance making sure th!
at things don't get too tightly bound, will be easy as well.

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] An article about the Cygnus tree

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

This is an interesting thread that came through Slashdot about the way
that the Cygnus CVS tree works.  What started off as another CVS repo
for Cygnus has become the dependent build tree for gcc.  This is an
interesting read because as we focus on how we would build a Tcl SDK,
we want to make sure to avoid the politics and pitfalls that hit the
Cygnus gcc guys.  One basic thing being that Tcl should always be able
to work independent of the Tcl SDK (and its build framework).

  http://gcc.gnu.org/ml/gcc/2000-09/msg00035.html

-- 
   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: Why Python moved to SourceForge ([Fwd: What is tcltk.com?])

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

This is from a python person in the know, in response to a request
to know why Python moved to SF, and how it worked out for them.

Well, this is pretty clear.  Remember that Python only really uses
SF for CVS stuff (as I noted before).  Now we see the impetus
behind that decision.  We are fortunate not to have this problem
with the Dev Xchange CVS repository.

-------- Original Message --------
Subject: Re: What is tcltk.com?
Date: 01 Sep 2000 22:01:00 -0400
From: Andrew Kuchling <aku...@me...>
Newsgroups: comp.lang.tcl
	...

Bob Techentin <tec...@ma...> writes:
> Sooooo, is this "dazzling acceleration" due to the fact that Python
> finally has publicly accessible CVS?  (I don't even know if it was more
> closed before SourceForge!)  Or has the simple fact that SourceForge is
> "_the_ place to hang out" attracted a new multitude of contributors? 

Read-only access to the CVS tree was previously available, so people
could track development, but due to firewall issues no one outside
CNRI could actually make checkins.  This meant that any patch had to
wait until one of the 5 people with write access could check it in,
and obviously that was a bottleneck.

I don't think any new contributors showed up because of the
SourceForge move; most of the people with write access have been
developers for a while and are familiar names.  I doubt someone could
get CVS write access unless they'd been hanging around c.l.python for
a while and demonstrated sufficient skill and interest.

> there.  (Ooooh, and I *love* that open source euphemism: "dazzling
> acceleration"!)

Well, honestly it *has* been impressive.  For example, one day Peter
Schneider-Kamp took it into his head to convert the C source to ANSI
C, dropping K&R compatibility; after getting approval on the
python-dev list, he launched into a flurry of checkins that lasted
about a week, and the job was done.  If there were only the 5 people
with access, probably that task would have been viewed as "nice, but
not worth the time and effort needed" and it wouldn't have gotten
done.  

--amk

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

[TCLCORE] Re: Test Results (-underline patch v. 0.2 [tcl gateway])

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

Keiichi Takahashi wrote:
> 
> Hello Laurent,
> 
> I've tested new underline sequence with the patch you sent and also modified it
> according to Scott's comment..

What do you mean "modified"?

> This underline sequence is working successfully on the following environment:
> 
> RedHat Linux 6.2 (R2) Japanese Edition (ja_JP.ujis)
> 
> Some results can be seen in attached pictures. This looks promised to realize
> true international message catalogs. Thanks.
> 

Wonderful!

FYI, I've started modifying the message file to use this. I'm also removing
all -underline stuff in the dialogs. If Real Work doesn't get in the way, it
should all be ready tomorrow. I'm still having a problem with using {\_} in a
regexp but I'm hoping that can be fixed soon.

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: TCT behavior (was: Using our time well)

[George H. <ga...@bl...>]

In message <Pin...@po...>, 
Eric Melski writes:

 : Personally, I think the behavior of the core team in reaction to the
 : string growth patch was shameful.  There were plenty of people criticizing
 : the patch (and by extension, the submitter of the patch) and precious
 : little encouragement from the core team.  *Even if* you don't personally
 : agree with a patch, it behooves you to be polite, courteous, and
 : encouraging to the submitter, lest you turn that person away from
 : submitting ever again.  I am horribly disappointed in the Tcl Core Team
 : and their behavior over the last several days.
 : 
 : What follows is a message I received from Gerhard regarding the discussion
 : on this patch; I encourage all the members of the Tcl Core Team to read it
 : carefully and take his words to heart.  You are fortunate that he is so
 : resilient; I strongly believe that many people would have simply given up
 : on Tcl after such a negative experience.

I personally can do without the lecture.  I did not see anything in
the "string reallocation" discussion (however long) that was
discourteous or impolite.  

But I hope that the we don't restrict our discussions to TCT members.
I would want every opportunity to hear the various technical arguments
and defend my patch against them.  It may be both frustrating and
tiring, but it's far better than a "The core team has decided not to
adopt your patch at this time" form letter.

--gah

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

[Paul W. <pau...@sy...>]

Brent Welch wrote:

>  > >
>  > > I can do all this now in the same namespace.  Why a different
>  > > namespace?
>  > >
>  > > --gah
>  >
>  > Because if I am intercepting a procedure in a namespace that I am not responsible
>  > for, I cannot choose a name with total confidence that it will
>  > not collide with an existing name or one that may be used in future. Of course if
>  > you choose an identifier including your own name and social
>  > security number then you are reasonably safe, but I would not like to see the
>  > style guide advising this :)
>
> [info command] will help you pick a name that does not collide.

It helps in the sense that you can choose a name that is not in use at the time, but
another file may be sourced later which may attempt a declaration that collides with
the name you picked. I suggested a "renameAuto" procedure in my posting of 25th August,
but feel that this still leaves a nagging doubt, because it is not easy to verify
whether the wrapping will cause collisions. At the very least, the style guide should
recommend that the patterns used for automatic names be avoided in regular naming. In
incr-Tcl, the name chosen for an object named with #auto is constructed by gracefully
steping over existing names whether they were derived manually or automatically.
However, if you ask for a explicit name that has already been taken by the automatic
naming mechanism then this is an error. I suspect that a typical incr-Tcl application
will use #auto almost exclusively, so that such collisions are rare. This is not the
case with procedure names, so automatic names would have to be differentiated by more
than the equivalent of adding an incrementing decimal number to the class name -
perhaps my facetious comment above is not so far off!

> I think this last point touches on the reasons for the current semantics.
> You are unlikely to change the definition of the procedure, but there is
> a ordering problem between the rename and when you bytecode compile the command.
> If you do the rename before the procedure has been executed, then Tcl
> would end up compiling in the context of the new namespace.  However, if
> the procedure was executed once first, it would have been compiled in
> the context of the original namespace.

This did not happen with Donal Fellow's original example in his posting of 15th August
- ::A::foo was executed in ::A, and therefore presumably byte-compiled, but when moved
to ::B it picked up the ::B variable.

> So, you have to do something
> special or you get different results depending on if the procedure
> had been compiled already or not.  I think the easy solution was to
> toss the bytecodes at the time of rename, so Tcl would "naturally"
> compile the procedure in the context of the new namespace.

In my posting of 15th August I suggested redeclaring the procedure in another namespace
but wrap it using "namespace code" for execution in the original namespace. I had
expected objections to be raised that "namespace code" has limitations so that it is
not a general solution, but no comments have been made. If it does work generally, then
an implementation would be to make rename between namespaces add this extra step. Still
have the problem of 'C' procedures and built-ins though.

> So now I'm in a quandry.

How about "rename -keepscope" for the closure semantics?


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

[TCLCORE] Re: TCT behavior

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

Eric Melski <er...@aj...> wrote:

> There were plenty of people criticizing
> the patch (and by extension, the submitter of the patch)

The "by extension" part is incorrect.  You have to learn
to be able to distinguish between the author and the work.
You might be interested to read Gerald Weinberg's
"Psychology of Computer Programming" for more on this.
It is somewhat of an antique (published 1970?) , but the
"egoless programming" part stands the test of time.

(And TCT members, it has a section on "how to critique" which
might be useful for future reference...)

But now I understand why you seemed so upset about the
tcllib critique.  Don't worry, it wasn't you I was criticizing
at the time.  It's just that there's a better way to do it.

BTW, I've had 3 books reviewed by sadistic, heartless bastards
(some of them members of this very TCT!), so I'm fully sympathetic
with the feeling of having one's heart ripped out and stomped flat.

Cheers,
Mark.

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

[TCLCORE] Re: TCT behavior

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

On Mon, 4 Sep 2000, Mark Harrison wrote:

> Eric Melski <er...@aj...> wrote:
> 
> > There were plenty of people criticizing
> > the patch (and by extension, the submitter of the patch)
> 
> The "by extension" part is incorrect.  You have to learn
> to be able to distinguish between the author and the work.

Mark --

I understand the distinction.  The important thing is that Gerhard did
not, and likely most people who contribute will not.  You should all
strive to be exceedingly kind to the people who submit work to the Tcl
core.

   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: Test Results (-underline patch v. 0.2 [tcl gateway])

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

Hello Laurent,

I've tested new underline sequence with the patch you sent and also modified it
according to Scott's comment..
This underline sequence is working successfully on the following environment:

RedHat Linux 6.2 (R2) Japanese Edition (ja_JP.ujis)

Some results can be seen in attached pictures. This looks promised to realize
true international message catalogs. Thanks.

Keiichi

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

[TCLCORE] TCT behavior (was: Using our time well)

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

Personally, I think the behavior of the core team in reaction to the
string growth patch was shameful.  There were plenty of people criticizing
the patch (and by extension, the submitter of the patch) and precious
little encouragement from the core team.  *Even if* you don't personally
agree with a patch, it behooves you to be polite, courteous, and
encouraging to the submitter, lest you turn that person away from
submitting ever again.  I am horribly disappointed in the Tcl Core Team
and their behavior over the last several days.

What follows is a message I received from Gerhard regarding the discussion
on this patch; I encourage all the members of the Tcl Core Team to read it
carefully and take his words to heart.  You are fortunate that he is so
resilient; I strongly believe that many people would have simply given up
on Tcl after such a negative experience.

   Eric "Not a member of the TCT" Melski  The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


---------- Forwarded message ----------
Date: Fri, 01 Sep 2000 23:57:50 +0200
From: Gerhard Hintermayer <g.h...@in...>
To: Eric Melski <er...@aj...>
Subject: [Fwd: [TCLCORE] Re: Hintermayer's string allocation patch]

Here you are.
Well, after a day the disappointment is not that much any more, bu still
some bad taste is left. The response I got from you was, "hey great,
we've got both speed improvement on the one hand and the capability of
handling very large strings on the other hand", but most of the other
emails I got said "hey, why the hell did you do _that_, you could have
done it much better, like this or this ..". The frustrating thing was,
that the core team did'nt have a common opinion, I got lot's of emails,
a lot of people didn't realize the changes the patch does, instead of
looking at the code, actually I would not have been that much
disapointed if I got one single reply that said - "your patch goes into
the right direction, but could you try some modifications", I would'nt
have been disappointed at all, but getting a lot of rants saying
"removing the doubling algorithm is a bad thing" and "who needs a string
that big" made me feel sad. Instead of telling me "thanks, you made a
step into the right direction, we will do the finetuning" a lot of
people from the core told me, that the patch was a bad thing, well
actually all except you.
My conclusion to this - hopefully soon ending - discussion is: If
somebody supply's a patch, the core team should start an internal
discussion, maybe ask some question to the supplier of the patch to
clarify some questions and then come to a _single_ conclusion - take the
patch or drop it.
But after all I still like "tuning" the core and of course using Tcl.

Gerhard

-- 
Gerhard Hintermayer
http://www.inode.at/g.hintermayer



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