tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE]

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

Testing the list server "Re: [TCLCORE]" sprocket (attempt #2).

- eric


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

[TCLCORE]

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

Testing the list server "Re: [TCLCORE]" sprocket.

- eric

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

[TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

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

Jim Ingham said:
 > Gcc,
 > (starting with the egcs fork) put a lot of effort into setting up a 
steering
 > committee that contained both developers and users, and was not 
dominated by
 > any one interest.  Then they maintain a parallel, technical review 
structure
 > that maintains code quality through a system of area maintainers and 
careful
 > submission & review practices to assure that (a) submitted code is in 
line
 > both with the gcc design principles, and future goals and (b) the 
knowledge
 > of same are transmitted from one generation of gcc hackers to the next.
 > They have also documented these practices clearly, with Hack rules and 
well
 > defined maintainers lists, and supported them with a nice CVS 
repository,
 > and mailing lists for patches and general discussion...

Are these documents readily available somewhere?  It seems like they'd 
make for interesting reading as we try to set up similar structures for 
Tcl development.

--Scott


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

[TCLCORE] Re: [TCLCORE] Words to consider...

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

Also sprach Jeffrey Hobbs:

> I found this on Slashdot (The Cathedral and The Bizarre), which
> is based on this article:
> http://www.macopinion.com/columns/macskeptic/00/07/07/index.html
> 
> The whole thing is well worth reading, but I'm excerpting some juicy
> bits to ponder:
> 

There are two points here that I want to address.  One is the bit about
incompatible changes in Perl4->5.  That was a big change in the language,
they were adding a lot more structure, and if it was necessary to break a
few older scripts, then maybe that was not such a bad thing.  Perl kind of
sabotages itself in this regard, because it allows so many ways of
expressing the same thing that I imagine it is pretty hard to change things,
and support ALL possible ways to write Perl code.  The Perl code that I
wrote for NASA went from 4->5 no problem, however, so...  I don't think that
this is a relevant argument for or against OpenSource in the long run...

However, the more important point is that there you can't just open the
doors to all comers, and allow coherent software to come out of it.  But
this is not a new observation, and there are successful long-term software
projects that have found ways around this.  Gcc is one example, and recently
gdb is another.  Both are starting from fairly crusty inherited source
bases, with long histories and LOTS of users from all walks of life.  Gcc,
(starting with the egcs fork) put a lot of effort into setting up a steering
committee that contained both developers and users, and was not dominated by
any one interest.  Then they maintain a parallel, technical review structure
that maintains code quality through a system of area maintainers and careful
submission & review practices to assure that (a) submitted code is in line
both with the gcc design principles, and future goals and (b) the knowledge
of same are transmitted from one generation of gcc hackers to the next.
They have also documented these practices clearly, with Hack rules and well
defined maintainers lists, and supported them with a nice CVS repository,
and mailing lists for patches and general discussion...

Sorry to go on so long, but the main point is that there are good models for
doing open source development that don't fall into the trap of having the
maintainers try to do too much, and thus always fall behind community
expectations, and not take full advantage of the community; and a too open
system that makes the software inconsistent and ugly...

Jim


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

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

[TCLCORE] Words to consider...

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

I found this on Slashdot (The Cathedral and The Bizarre), which
is based on this article:
	http://www.macopinion.com/columns/macskeptic/00/07/07/index.html

The whole thing is well worth reading, but I'm excerpting some juicy
bits to ponder:

....
Programmers - at least the kind who are likely to get
involved in OpenSource project - are a notoriously independent lot.
They love to do their own thing and always think they have a better
way to do things.

Normally, this is an advantage because, with filtering and discipline,
this is from whence the fountain of creativity which drives this
industry comes. Unchecked and unfiltered, though, and you have
unbridled chaos. As a result, you have no less than six different
desktop systems and two different configuration systems and tools
whose command line options change not only from system flavour -
but from revision to revision. Perl is the best example of this - when
they went to version five, they changed the language syntax in a way
which broke existing code. Perl itself is a testimony to the
OpenSource mindset - it's a gruesome mishmash of inconsistent
syntax and function calls - definitely a product designed by
committee - but one wherein each member clearly wasn't listening to
anyone else.

Raymond touts the stability of Linux as proof of the OpenSource
concept, but that's a bit misleading. The core of Linux was written
by one person - Linus Torvalds. Moreover, there is a small group
who shepherds the contributions to the kernel to keep it stable and
clean. In other words, there's a priesthood at the top of the bazaar.
If you check into each successful OpenSource project, you see the
same thing: a small group of referees who filter the input and weed
out the bad ideas. The bazaar has cops. The chaos is contained.
....
....
People jump on the bandwagon and promote the software, and the
crowd grows and grows - often way out of proportion to the quality
of the solution. Perl, again, is an excellent example of this. It's really
a terrible language - badly.. ok... not designed, clumsy and
arbitrary. But it works - is better than shell scripting, and more
powerful than awk... and it was the first serious attempt at such a
language. So it went platinum with a bullet.
....
....
Ironically, when commercial developers release applications which
are clearly not 100%, we accuse them of forcing the customer to be
beta testers, but in a sense, OpenSource assumes you're not only
going to be a tester; you're going to be a programmer and fix the
bug!
....

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: Translations strings in CVS

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

In Ðåì, 06 Éïýë 2000, lau...@uf... wrote:
> On  6 Jul, Giorgos Petasis wrote:
> > Hi Laurent,
> > 
> > I have done the greek translation and I have attached the file.
> > The file is encoded in utf-8 encoding, as you suggested.
> > 
> > On equestion remains though: Have you patched message catalogs
> > to read things in utf-8 encoding by default?
> > Because this file if simply sourced won't work.
> > Have i done anything wrong?
> > 
> 
> I don't know. Like I said before, I've never touched anythig other than ISO
> 8859-1 (latin 1). Can you resend the file zippped (or gzipped, whatever) and
> copy tc...@aj...? My MUA seems to think it's a text file but
> that may mess things up when I save.
> 
> I'll try to test the loading and stuff later.

Ok, I have gzipped the file and attached it to this mail.
The message file is in utf-8 encoding.

My opinion is that the whole message catalog
facility has to store its messages only in this format. I see no point in
doing a simple source of the file that contains the messages and leave
the code inside this file to do the necessary conversions.
Instead if we decide that files are sourced with a default encoding (a feature which
I think will be in next release, source -encoding), then there will be no need for
conversions. In order to use the message catalog as is right now, I have to place
a "encoding convertfrom iso8859-7..." in front of every (!) string.
And I am not sure if this would not depend on the system encoding...

George

[TCLCORE] Patch for TR#5973 checked in.

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

I just checked in my patches for TR#5973, so someone
can close it now.

While you are in there, could you also close the
following Tcl/Java bug reports, these are not
bugs.

TR#3675
TR#3664
TR#3438
TR#5973
TR#663
TR#651
TR#650
TR#579

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] trace command patch

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

Vince Darley submitted a patch for 8.4 to provide [trace command]
capabilities.  Before I go ahead and merge it, I wanted to get one last
review of the API by everybody here.  I've CC'd Vince so he stays in the
loop on this, and can maybe answer some questions if we have any.

The specific problem we wanted to solve was this:  when creating
megawidgets, it's common practice to do the following:

frame .f
rename .f .f:real
interp alias {} .f {} MegawidgetProc .f

But now, if the user does:

rename .f {}

to delete the megawidget, it will destroy the command, but not actually
clean up the megawidget, as it would if it were a "real" widget.  So we
wanted to be able to trace command deletion.  While we were at it, we
figured, let's trace command renaming, and command execution too, what the
heck, right?

Vince put together a nice patch to do just this, and to clean up the
[trace] syntax as well.  It updates trace with the following syntax:

trace {add|remove|list} {variable|command|execution} ops ...

while retaining [trace variable], etc, for backwards compatibility.  

Variable traces support read, write, and unset operations; command traces
support rename and delete operations; execution traces are used to trace
command execution, and have several additional options:

trace add execution name ops ?-minlevel m -maxlevel n -truncate t -depth d?

The full patch is at

ftp://ftp.ucsd.edu/pub/alpha/tcl/tracecommand.patch.gz

If you are so inclined, please take a look at it and give us some
comments.  I think the patch looks very good; I've tested it out and it
works as advertised, has tests, and doc's.  My only concern is with the
syntax of the execution traces.  I think that "execution" should just be
another operation for command traces, rather than an entirely separate set
of traces.  My guess is that Vince split it out because of the need for
the extra options.  But I don't feel strongly that it should be changed.
Does anybody else have any comments on this, or on any other parts of the
patch?

   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] Fwd: Re: Translations strings in CVS

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

FYI

------ Forwarded message ------
      From: Juan Carlos Gil Montoro <jc...@gm...>
   Subject: Re: Translations strings in CVS
      Date: Thu, 06 Jul 2000 16:40:42 +0200
        To: lau...@uf...
        Cc: Juan Carlos Gil Montoro <jg...@gm...>

lau...@uf... wrote:
> 
> On  3 Jul, Juan Carlos Gil Montoro wrote:
> > Laurent,
> >
> > Why the spanish file is not included in that tarball ?
> >
> > Am I supposed to extract it from the CVS ?, I don't have CVS access ...
> >
> 
> Yes, you do. I'm sorry. I'll repost the messages to everyone.
> 


(I've been on leave for some days)

Ok. Please find enclosed the revision spanish message file.

Juan Carlos---

[TCLCORE] Re: Small patch, big gain ??

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

Thanks for your encouragement, I'll keep trying and report any
significant progress I might get. 

I'm trying to apply some of the ideas described in the docs "around"
gforth <http://www.complang.tuwien.ac.at/projects/forth.html>. In
their terminology:  

Dr. Lewis reported in his 1996 paper that he compared "switch
threading" (current implementation) to (I think) "call threading" (a
table of function pointers); I am trying to build an efficient
implementation of "direct token threading" (a table of pointers for
gotos, not calls).  

This should be much faster than call threading, as it avoids the whole
function call circus. However, it _cannot_ be done in ANSI C, it
requires the GNU "Labels as Values" extension (for all I know, other
compilers may have similar extensions ?).

A much bigger project I may tackle in the future is to try another
threading model that avoids bytecodes (faster but larger ...),
essentially compiling into some specially adapted variant of
forth. This does require a modification of the compiler too; I'll need
more stimulants before I even _read_ those files, let alone modify
them ...

Regards

Miguel Sofer

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

[TCLCORE] Re: [TCLCORE] Welcome!

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

On Wed, 5 Jul 2000, Eric Melski wrote:

> Welcome to the tc...@aj... mailing list.  This list is for
> people who have CVS write access to the Tcl core repository.

Hey, now that I am on "the list", perhaps it would be a good time
to ask why there are no ./configure scripts in the Tcl/Tk CVS?   
At first, it seems like a good idea to leave them out (saves  
time because you don't need to deal with auto-generated files
in the CVS). That seems like a good idea, but what ends up
happening is that people try to grab the CVS version and
then they complain because they can not just run it, they
need to go install the autotools first. It gets even worse
when folks that do not know what they are doing try to
generate a ./configure. It seems easy, but someone will
find a way to screw it up and then they will complain some
more.

That whole mess could be avoided if the generated ./configure
files are put into the CVS.

While I am at it, why are there two different sets of build
scripts? One for Unix and one for Windows just means that
your need to do everything twice. If the build systems
were merged into a common build system, life would be
a heck of a lot easier. It would not be easy, it would
take a lot of work but it is doable for 8.4. After
8.3.2 is out of the door, we could start to address this
problem. I also think it would make things a lot easier
if we used all the autotools not just autoconf. Both
automake and libtool have some really nice features.
It would be a step backwards at first because Tcl already
works on some systems that libtool does not. In the
long run, I think it would be better to just let libtool
deal with all the ugliness if creating shared libraries
on lots of different systems.

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: [TCLCORE] RE: About mingw support in Tcl/Tk

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

On Wed, 5 Jul 2000, Jeffrey Hobbs wrote:

> noted that the CVS dev branch is in a constant state of flux, we
> always try and make sure that things are checked back in before they
> are fully tested.

I think Jeff means:

"We always try and make sure that things are fully tested before they are
checked back in."

   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] FW: Managing patches and stuff with CVS

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

This was sent to just me, but I thought it worth sharing with
everybody.  I'm trying to think about how these points can be
best integrated into the CVS management policy pages...  :^)

I'll have to find a good substitute for the Canolli.

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

-----Original Message-----
From: Henry Cox [mailto:hen...@Si...]
Sent: Saturday, July 01, 2000 1:03 PM
To: jef...@aj...
Subject: Re: Managing patches and stuff with CVS


In one company in which I used to work, revision control
was a serious issue.

1) thou shalt not check in code which breaks the build
  [...on the main development platform(s) at least -
  the average developer can't possibly build on all
  machines].
   - corollory:  he who breaks the build did a Very Silly
     Thing, (which is usually easy to correct), and thu
     owes the entire team a Canoli (there was a good
     Italian bakery down the block.

2) thou shalt not break the check-in tests.
  - corollory: he who breaks the check-in tests did a
    Very Very Silly Thing (which is often difficult to
    diagnose and fix), and thus owes the entire team
    lunch.

It is harder to work this out, with distributed teams,
but the upshot (from a management/project lead perspective
is that people become more careful about breaking stuff.
This is good, by itself.  When someone does something
silly, the team then gets together to eat something
(which can be good for team building) - which also
gives the opportunity to discuss what went wrong, and
how to fix it.

My experience is that new guys break things once or twice,
learn a lesson, and don't do it again.  They then watch
the senior guys _very_ carefully - because they want to
catch them out.  (In some cases, it is a good idea to
take cash from your budget and give it to a senior
guy, asking him to (quietly) break something.  Then
the junior guys can find it, and not feel too bad.)

Sounds silly, doesn't it?  Surprising how well it
works, though.  (I imported it into several companies.)

				Henry

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

[TCLCORE] RE: About mingw support in Tcl/Tk

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

OK, you've got write access.  core-8-3-1-branch is where 8.3.2 is
going, but don't commit there just yet.  Work on the mainline (which
will be 8.4a2, to be released after 8.3.2.  The mainline is also
really a dev branch right now.  Go ahead and make the commits there
directly, since they should be innocuous.  Of course, always test
on as many platforms as possible before commiting.  Although Duffin
noted that the CVS dev branch is in a constant state of flux, we
always try and make sure that things are checked back in before they
are fully tested.

For the moment, the plan is that if people want to work on new
features that need CVS history, but may break things while in
development, a development branch would be made for that feature,
which would be brought back into the mainline when it was finished.

Also, the idea for two-response OK and one-response VETO is in line
with what we were planning.  I noticed that you sent in a patch that
basically was just compiler warning fixes (casts, decl cleanup).
For these things, it should not be necessary to wait for approval.
There are some casting cases where that might not be the case (like
with ANSI casts, or when one needs to be careful because different
OSes have different prototypes).  Use your discretion in what can
"just be commited" because we don't want to clog the process with
menial things needing approval.  And if something happens, that's
why we have revision control.

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

> -----Original Message-----
> From: Mo DeJong [mailto:md...@cy...]
> Sent: Wednesday, July 05, 2000 4:23 PM
> To: Jeffrey Hobbs
> Cc: tc...@sc...
> Subject: RE: About mingw support in Tcl/Tk
> 
> 
> On Wed, 5 Jul 2000, Jeffrey Hobbs wrote:
> 
> > Mo,
> > 
> > I agree that back-porting whatever build changes are necessary to
> > 8.3.2 is a good idea.  The 8.3.2 release is tentatively set for
> > July 27th.  It would be good if all the changes could be made and
> > verified against 8.4a1 in the interim and then back-ported, so we
> > don't break the 8.3.1 branch at any time.
> 
> Great. I can get started this week, I am sure I can be done by friday.
> There are still some problems that need to be fixed in Tcl 8.4,
> but once that is done we will be good to go (the problems are
> in the tclConfig.sh script for windows).
> 
> > To this effect, it's probably easiest to give you write access to
> > the core, if you want it.  You'd have to resist the urge to
> > reshape the core willy-nilly into Jacl.  :^)
> 
> You mean I can't add that path to parse [] as a literal string? Dang :)
> 
> > Seriously though,
> > we'd open it up for you to make config changes, but please restrain
> > from making feature changes or finicky bug fixes without talking
> > with us (tclcore) first.  Hmmm, I think we'll have to make a real
> > mailing list out of this soon for all with core write access to
> > make sure people don't step on each others toes.
> 
> The way it is typically done is that each patch needs to be
> posted to a mailing list and then oked by two of the maintainers,
> before it can be checked in. That way everyone on the list
> (I assume this will be the tc...@sc... list) will
> be able to see what is going on. The other rule is that if
> someone objects to a change then it can not be checked in
> until the objection is removed.
> 
> > If you want access, tell me and I can brief you on the current
> > setup and the best plan of attack.
> 
> Sounds good, just switch my user over so that I can write
> to the tcl and tk modules and I will be all set. Of course,
> you will need to sign me up for the core list otherwise I
> will not know if you have oked my patches.
> 
> 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: [TCLCORE] Welcome!

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

Wasting no time, mo submits a patch for approval.

Mo DeJong
Red Hat Inc

Index: ChangeLog
===================================================================
RCS file: /cvsroot/tk/ChangeLog,v
retrieving revision 1.167
diff -u -r1.167 ChangeLog
--- ChangeLog	2000/06/30 20:33:44	1.167
+++ ChangeLog	2000/07/06 01:03:27
@@ -1,3 +1,19 @@
+2000-07-05  Mo DeJong  <md...@re...>
+
+	* generic/tkFileFilter.c (AddClause): Cast to match function prototype.
+	* win/stubs.c (_XInitImageFuncPtrs): Add return value for function.
+	* win/tkWinButton.c (buttonStyles, ButtonBindProc, ComputeStyle):
+	Remove unused declarations.
+	* win/tkWinColor.c (GetColorByName, GetColorByValue): Remove unused
+	function declarations.
+	* win/tkWinDialog.c (TrySetDirectory): Remove unused function declaration.
+	* win/tkWinEmbed.c (TkWinEmbeddedEventProc): Cast to match 
function prototype.
+	* win/tkWinMenu.c (winMenuMutex, MenuExitProc): Remove unused declaration.
+	* win/tkWinWindow.c (StackWindow): Remove unused declaration.
+	* win/tkWinWm.c (ConfigureEvent): Remove unused declaration.
+	* win/tkWinX.c (winXMutex): Remove unused declaration.
+	* xlib/ximage.c (XCreateBitmapFromData): Cast to match function prototype.
+
 2000-06-30  Eric Melski  <er...@sc...>
 
 	* doc/keysyms.n:
Index: generic/tkFileFilter.c
===================================================================
RCS file: /cvsroot/tk/generic/tkFileFilter.c,v
retrieving revision 1.3
diff -u -r1.3 tkFileFilter.c
--- tkFileFilter.c	1999/04/16 01:51:13	1.3
+++ tkFileFilter.c	2000/07/06 00:59:40
@@ -270,7 +270,7 @@
 		/*
 		 * Prepend a "*" to patterns that do not have a leading "*"
 		 */
-		globPtr->pattern = (char*)ckalloc(len+1);
+		globPtr->pattern = (char*)ckalloc((unsigned int) len+1);
 		globPtr->pattern[0] = '*';
 		strcpy(globPtr->pattern+1, globList[i]);
 	    }
@@ -289,11 +289,11 @@
 		    strcpy(globPtr->pattern, "*.");
 		}
 		else {
-		    globPtr->pattern = (char*)ckalloc(len);
+		    globPtr->pattern = (char*)ckalloc((unsigned int) len);
 		    strcpy(globPtr->pattern, globList[i]);
 		}
 	    } else {
-		globPtr->pattern = (char*)ckalloc(len);
+		globPtr->pattern = (char*)ckalloc((unsigned int) len);
 		strcpy(globPtr->pattern, globList[i]);
 	    }
Index: win/stubs.c
===================================================================
RCS file: /cvsroot/tk/win/stubs.c,v
retrieving revision 1.2
diff -u -r1.2 stubs.c
--- stubs.c	1999/06/16 20:11:30	1.2
+++ stubs.c	2000/07/06 00:59:42
@@ -4,7 +4,7 @@
  * Undocumented Xlib internal function
  */
 
-_XInitImageFuncPtrs(XImage *image)
+int _XInitImageFuncPtrs(XImage *image)
 {
     return 0;
 }
Index: win/tkWinButton.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinButton.c,v
retrieving revision 1.9
diff -u -r1.9 tkWinButton.c
--- tkWinButton.c	2000/05/17 21:17:22	1.9
+++ tkWinButton.c	2000/07/06 00:59:42
@@ -25,10 +25,6 @@
 #define CHECK_STYLE (BS_OWNERDRAW | BS_CHECKBOX | WS_CHILD | WS_VISIBLE 
| WS_CLIPSIBLINGS)
 #define RADIO_STYLE (BS_OWNERDRAW | BS_RADIOBUTTON | WS_CHILD | 
WS_VISIBLE | WS_CLIPSIBLINGS)
 
-static DWORD buttonStyles[] = {
-    LABEL_STYLE, PUSH_STYLE, CHECK_STYLE, RADIO_STYLE
-};
-
 /*
  * Declaration of Windows specific button structure.
  */
@@ -83,13 +79,8 @@
 /*
  * Declarations for functions defined in this file.
  */
-
-static int		ButtonBindProc _ANSI_ARGS_((ClientData clientData,
-			    Tcl_Interp *interp, XEvent *eventPtr,
-			    Tk_Window tkwin, KeySym keySym));
 static LRESULT CALLBACK	ButtonProc _ANSI_ARGS_((HWND hwnd, UINT message,
 			    WPARAM wParam, LPARAM lParam));
-static DWORD		ComputeStyle _ANSI_ARGS_((WinButton* butPtr));
 static Window		CreateProc _ANSI_ARGS_((Tk_Window tkwin,
 			    Window parent, ClientData instanceData));
 static void		InitBoxes _ANSI_ARGS_((void));
Index: win/tkWinColor.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinColor.c,v
retrieving revision 1.5
diff -u -r1.5 tkWinColor.c
--- tkWinColor.c	2000/04/17 06:26:09	1.5
+++ tkWinColor.c	2000/07/06 00:59:42
@@ -80,8 +80,6 @@
 
 static int	FindSystemColor _ANSI_ARGS_((const char *name,
 		    XColor *colorPtr, int *indexPtr));
-static int	GetColorByName _ANSI_ARGS_((char *name, XColor *color));
-static int	GetColorByValue _ANSI_ARGS_((char *value, XColor *color));
 
 /*
  *----------------------------------------------------------------------
Index: win/tkWinDialog.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinDialog.c,v
retrieving revision 1.12
diff -u -r1.12 tkWinDialog.c
--- tkWinDialog.c	2000/06/15 16:01:04	1.12
+++ tkWinDialog.c	2000/07/06 00:59:42
@@ -123,7 +123,6 @@
 static UINT APIENTRY	OFNHookProcW(HWND hdlg, UINT uMsg, WPARAM wParam, 
 			    LPARAM lParam);
 static void		SetTkDialog(ClientData clientData);
-static int		TrySetDirectory(HWND hwnd, const TCHAR *dir);
 
 /*
  *-------------------------------------------------------------------------
Index: win/tkWinEmbed.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinEmbed.c,v
retrieving revision 1.3
diff -u -r1.3 tkWinEmbed.c
--- tkWinEmbed.c	1999/04/16 01:51:51	1.3
+++ tkWinEmbed.c	2000/07/06 00:59:42
@@ -397,7 +397,7 @@
 
 	break;
       case TK_GEOMETRYREQ:
-	EmbedGeometryRequest(containerPtr, wParam, lParam);
+	EmbedGeometryRequest(containerPtr, (int) wParam, lParam);
 	break;
     }
     return 1;
Index: win/tkWinMenu.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinMenu.c,v
retrieving revision 1.10
diff -u -r1.10 tkWinMenu.c
--- tkWinMenu.c	2000/05/16 17:57:32	1.10
+++ tkWinMenu.c	2000/07/06 00:59:42
@@ -82,8 +82,6 @@
 static Tcl_DString menuFontDString;
 				/* A buffer to store the default menu font
 				 * string. */
-TCL_DECLARE_MUTEX(winMenuMutex)
-
 /*
  * Forward declarations for procedures defined later in this file:
  */
@@ -149,7 +147,6 @@
 			    int *heightPtr));
 static int		GetNewID _ANSI_ARGS_((TkMenuEntry *mePtr,
 			    int *menuIDPtr));
-static void		MenuExitProc _ANSI_ARGS_((ClientData clientData));
 static int		MenuKeyBindProc _ANSI_ARGS_((
 			    ClientData clientData, 
 			    Tcl_Interp *interp, XEvent *eventPtr,
Index: win/tkWinWindow.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinWindow.c,v
retrieving revision 1.5
diff -u -r1.5 tkWinWindow.c
--- tkWinWindow.c	1999/04/16 01:51:54	1.5
+++ tkWinWindow.c	2000/07/06 00:59:42
@@ -27,8 +27,6 @@
 
 static void		NotifyVisibility _ANSI_ARGS_((XEvent *eventPtr,
 			    TkWindow *winPtr));
-static void 		StackWindow _ANSI_ARGS_((Window w, Window sibling,
-			    int stack_mode));
 
 /*
  *----------------------------------------------------------------------
Index: win/tkWinWm.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinWm.c,v
retrieving revision 1.25
diff -u -r1.25 tkWinWm.c
--- tkWinWm.c	2000/05/16 00:00:29	1.25
+++ tkWinWm.c	2000/07/06 00:59:43
@@ -276,8 +276,6 @@
 
 static int		ActivateWindow _ANSI_ARGS_((Tcl_Event *evPtr,
 			    int flags));
-static void		ConfigureEvent _ANSI_ARGS_((TkWindow *winPtr,
-			    XConfigureEvent *eventPtr));
 static void		ConfigureTopLevel _ANSI_ARGS_((WINDOWPOS *pos));
 static void		GenerateConfigureNotify _ANSI_ARGS_((
 			    TkWindow *winPtr));
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinX.c,v
retrieving revision 1.10
diff -u -r1.10 tkWinX.c
--- tkWinX.c	2000/04/19 01:06:51	1.10
+++ tkWinX.c	2000/07/06 00:59:43
@@ -31,8 +31,6 @@
 static WNDCLASS childClass;	    /* Window class for child windows. */
 static int tkPlatformId;	    /* version of Windows platform */
 
-TCL_DECLARE_MUTEX(winXMutex)
-
 /*
  * Thread local storage.  Notice that now each thread must have its
  * own TkDisplay structure, since this structure contains most of
Index: xlib/ximage.c
===================================================================
RCS file: /cvsroot/tk/xlib/ximage.c,v
retrieving revision 1.3
diff -u -r1.3 ximage.c
--- ximage.c	1998/09/14 18:24:03	1.3
+++ ximage.c	2000/07/06 00:59:43
@@ -47,7 +47,7 @@
     GC gc;
     Pixmap pix;
 
-    pix = Tk_GetPixmap(display, d, width, height, 1);
+    pix = Tk_GetPixmap(display, d, (int) width, (int) height, 1);
     gc = XCreateGC(display, pix, 0, NULL);
     if (gc == NULL) {
 	return None;

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

[TCLCORE] Welcome!

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

Welcome to the tc...@aj... mailing list.  This list is for
people who have CVS write access to the Tcl core repository.  All messages
to this list should have the text "[TCLCORE]" at the start of the subject
line, for easy filtering.  Jeff says, "We're cementing the policies now,"
(with regard to feature changes, etc) and, "Eric is going to get around to
publishing those sometime."  Welcome to the new world order.

   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.

Re: Translation messages file

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

On  4 Jul, Keiichi Takahashi wrote:
> Hi,
> 
> Thank you for your kind information, Laurent.
> 
> Fortunately I've already obtained updated source from CVS repository when I
> received your previous message, and checked it works. But as I mentioned before,
> the issue of 'underline' is serious in order to add the file of Japanese message
> in lib/tk8.4/msgs.
> 
> For message of Japanese version, I think it better to wait until '&' can be used
> to indicate underlined character.
> 
> Or, is this already available?
> 

No it isn't available yet. I've started working on it but I'm segfaulting
all over the place. And it's a bit more involved than I originally expected.

For those who weren't involved in the discussions, the -underline option
causes problems when you change languages; key bindings become a problem
also. A few solutions have been put forward for both of these problems and
I'm looking at the best way to implement it. 

Mr. Takahashi has proposed using the "&" character to mark the location of
the character to underline and to use -underline & as a special case to
locate it. There have been other proposals (which I would need to dig up in
my voluminous email) but this one seems to be the better one IMO. But it
requires modifying the core structure of the Button widget. There's also a
display issue because the "&" needs to disappear from the string, etc.

How this relates to the binding issue is that the underlined character is
the one that should be used in the key binding for the dialog being used.
There have been some discussions on how to best do the binding. Eric
proposed expanding msgcat to handle the keybindings. I'm lukewarm to the
idea. I wanted to "translate" the key bindings from one language to next by
using special names for the key bindings. Something like:

bind [::msgcat::mc "chooseDirOpenDirectoryKey"] {...}

Eric doesn't like the idea.

.
.
.

Maybe something like

set string [$widget cget -text]
set char [indexOfUnderlineInWidget $string]
bind <Alt-$char> {....}

is another viable alternative. IOW, the binding key to use is returned by
the widget which has the underlined character.

If anyone has any other comments, suggestions, let'em rip. Remember that
it's a holiday in the US so we shouldn't expect anything from the TCT before
tomorrow.

L

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

Translations strings in CVS

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

Hi all,

The translations strings have all been added to CVS by Eric Melski. If you
haven't done so already, you can check out that Tcl and the Tk tree (the
msgcat package has been modified in Tcl). For those of you who have already
translated strings, there is only one minor addition: "Select Multiple
Files". 

You will also notice the the format of the strings has changed. They've been
generated with the msgedit package, which saves strings in UTF-8 (or
whatever) format. I dont think you absolutely need to use it, but it
generates more portable strings. You can find msgedit at

http://www.tu-harburg.de/~skfcz/msgedit.tar.gz

There is a bug with the program, though: some of the strings contain "\n"'s
and msgedit saves these strings as "\\n". The saved files will need to be
edited to correct this problem.

You can send the translated strings directly to me or to tclcore (cc me if
you do).

The next step is to fix the -underline options and the key bindings. A
number of suggestions have been made (with a preference, it seems, for using
the magic & character) but nothing has been implemented yet.

L

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

Re: MSGedit fixes [was: Translation strings]

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

lau...@uf... said:

 > > I don't think
 > > there is any value, in fact negative value, in translating things
 > > like error messages.  This was discussed on the newsgroup before
 > > with the same resulting opinion.
 > > 
 > 
 > Hmmm... I don't remember this discussion. I don't think it's too late to
 > backtrack the error messages changes. I'm not sure it has no value, 
though.
 > I know that I've had system setups where part of the interface is 
English
 > and the rest is French. There is a "surprising" disconnect when you're
 > constantly working in French and all of a sudden an English message 
pops up.
 > It's even worse when part of the message is in English and the rest is 
in
 > French. It's not crucial or anything but it does give one a "weird" 
feeling.
 > I'm not sure how to describe it.

I believe the original motivation was that error messages are essentially 
part of the API of a command and changing them would cause programs to 
break.  Ideally, the errorCode would have the machine readable error state 
and the message would only be used to display to a user (and therefore 
should be localized).  Unfortunately most commands don't set the errorCode 
to anything useful so this isn't really an option right now.

Maybe we should consider improving the errorCode information with an eye 
toward localizing the messages later.

--Scott

Re: MSGedit fixes [was: Translation strings]

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

On 23 Jun, Jeffrey Hobbs wrote:
> This of course is restricted to just the end-user-visible strings,
> and not any error messages and the like, correct?

No. The error messages have been translated otherwise the test suite fails.

> I don't think
> there is any value, in fact negative value, in translating things
> like error messages.  This was discussed on the newsgroup before
> with the same resulting opinion.
> 

Hmmm... I don't remember this discussion. I don't think it's too late to
backtrack the error messages changes. I'm not sure it has no value, though.
I know that I've had system setups where part of the interface is English
and the rest is French. There is a "surprising" disconnect when you're
constantly working in French and all of a sudden an English message pops up.
It's even worse when part of the message is in English and the rest is in
French. It's not crucial or anything but it does give one a "weird" feeling.
I'm not sure how to describe it.

L

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

RE: MSGedit fixes [was: Translation strings]

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

This of course is restricted to just the end-user-visible strings,
and not any error messages and the like, correct?  I don't think
there is any value, in fact negative value, in translating things
like error messages.  This was discussed on the newsgroup before
with the same resulting opinion.

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

> -----Original Message-----
> From: lau...@uf... [mailto:lau...@uf...]
	...
> will need to start looking at translating the C strings in Tcl and Tk.

Re: MSGedit fixes [was: Translation strings]

[Carsten Z. <ze...@tu...>]

I incoporated Jan's patches into MSGedit, an actual version is available
from 

http://www.tu-harburg.de/~skfcz/msgedit.tar.gz

The editor uses now the msgcat package provided with tcl, not the
included version from tcl8.1.

I've not look so far into the newer version of msgcat with substitution,
perhaps there will be some mistakes. And perhaps I should write some
doc  ...

By the way, anybody already found for german translation ?

Bye, Carsten

-- 
Dipl. Ing. Carsten Zerbst         |   See the results of the
                                  |   1. European Tcl User Meeting !
ze...@tu...              |  
http://www.tu-harburg.de/~skfcz   |   http://www.tu-harburg.de/skf/tcltk

Re: MSGedit fixes [was: Translation strings]

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

On 23 Jun, Carsten Zerbst wrote:
> By the way, anybody already found for german translation ?
> 

Andreas Kupries has provided me with the translations. He also found a few
bugs which I've corrected. So far I've checked that the fr, en and de
translations work properly with the test suites. I now have to do the es
ones. Once I've done that, I think that for the July 12 release of 8.4a2,
things should be complete as far as translations go.

Next week I'll try to fix the underlining problems and maybe the keybinding
problems. If I'm lucky, all will be completed for July 12. After that, we
will need to start looking at translating the C strings in Tcl and Tk.
That's a *much* larger job (which I may not take on). I know there are
facilities for this already. I know about gettext from GNU but that can't be
used in Tcl. A BSD-licensed technolgy will need to be used. If any of you
know of some clean solutions that exist already, which could be integrated
in the core, let me know so I can at least take a look.

L

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

Re: MSGedit fixes [was: Translation strings]

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

On 22 Jun, Jan Nijtmans wrote:
> lau...@uf... wrote:
>> - I don't do fonts. If you need something other than iso-latin-1, you need
>>   to figure out how to insert it into the translation scheme. Make it know
>>   immediately if you plan to work on this so that other users can
>>   synchronise their work with yours.
> 
> The solution to this problem is to use the "\uXXXX" format in the msgcat
> files for characters outside the ASCII range. This has the additional
> advantage that the msg files still contain only ASCII characters, so they
> work with whatever channel encoding is used when reading the msgfile.
> 
> Here is a patch for Carsten Zerbst's MSGedit with the changes I made.
> Are there already any Japanese, Korean or Chinese contributors who could
> possibly benefit from this?
> 

Thanks for the patch. No one has volunteered for any of the Far East (or
even Middle East) translations.

L

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

MSGedit fixes [was: Translation strings]

[Jan N. <j.n...@ch...>]

lau...@uf... wrote:
> - I don't do fonts. If you need something other than iso-latin-1, you need
>   to figure out how to insert it into the translation scheme. Make it know
>   immediately if you plan to work on this so that other users can
>   synchronise their work with yours.

The solution to this problem is to use the "\uXXXX" format in the msgcat
files for characters outside the ASCII range. This has the additional
advantage that the msg files still contain only ASCII characters, so they
work with whatever channel encoding is used when reading the msgfile.

Here is a patch for Carsten Zerbst's MSGedit with the changes I made.
Are there already any Japanese, Korean or Chinese contributors who could
possibly benefit from this?

Regards,
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/