tcl-core — Tcl Core Team discussions about Tcl development

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

Re: Translation status

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

In Ôñé, 20 Éïýí 2000, lau...@uf... wrote:
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?

Well, I prefer to have them whean all done, as I have also the dnd extension to
finish :-)

George

Re: Translation status

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

Seems my mail crossed with the information about the deadline.
I revoke my preference for a single gob and go with the notion
of doing it piecemal.

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

Re: Translation status

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

lau...@uf... wrote:
> 
> Hi,
> 
> I'm still moving along with the translation. It's taking more time than I
> expected because there are some not immediately obvious situations that come
> up. I've done most of the translations for the dialogs, and now I'm going
> through the test suites (since they now fail if your native language isn't
> English). There will also need to be a test that changes locales and
> re-executes some of the tests scripts with a different locale. Something
> like
> 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }
> 
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?
> 

Given the tight deadline, I'd prefer to start ASAP.

Juan Carlos---

Translation strings

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

Hi,

Here are the translation strings. The patches were made with CVS diff around
3:05 PM EDT. Applying them to a recent Tk tree should get you started. 

- Untar msgs.tar.gz in <tksrcdir>/library/

- to do the translations, make a copy of msgs/en.msg to msgs/es.msg (for
  Spanish)
  
- All you need to do is take each string and add the translation right
  beside it. I've put all the strings on one line (no \ for continuation)
  because it makes it easier to sort the files.
  
- The only tests that work are msgbox and choosedir. Running them should
  yield no errors.
  
- There are problems with buttons that have long names. The names are
  truncated on screen. I haven't yet figured out how to fix this. Eric, did
  you receive my note about min/max and tcllib?

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

- To test, remember to set env(LANG) to the appropriate value before running
  the test.

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: Translation strings

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

On Tue, 20 Jun 2000 lau...@uf... wrote:

> - There are problems with buttons that have long names. The names are
>   truncated on screen. I haven't yet figured out how to fix this. Eric, did
>   you receive my note about min/max and tcllib?

I did; after some consideration, I think that it's best if the core itself
is not dependant on tcllib.  The core should be completely independant.

- eric

Re: Translation status

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

On 20 Jun, Juan Carlos Gil Montoro wrote:
> Given the tight deadline, I'd prefer to start ASAP.
> 

I'll try to have something available tomorrow morning.

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: Translation status

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

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

Seems my mail crossed with the information about the deadline.
I revoke my preference for a single gob and go with the notion
of doing it piecemal.

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

Re: Translation status

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

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

> Hi,
 
> I'm still moving along with the translation. It's taking more time
> than I expected because there are some not immediately obvious
> situations that come up. I've done most of the translations for the
> dialogs, and now I'm going through the test suites (since they now
> fail if your native language isn't English). There will also need to
> be a test that changes locales and re-executes some of the tests
> scripts with a different locale. Something like
 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }

Or maybe something in the main wrapper calling the whole testsuite.

 
> The question I have for all of you: do you wish to have the
> translation strings when I've completed everything (which could take
> at least a week), or would you rather receive what I've done so far
> and receive more updates every few days?

I have no preference ... Hm, upon more cogitation I do have a slight
preference for the all at once approach. That makes it easier for me
to do it all at once too. Else I would collect the samples and then
go to work after I got them all.
 
> As for the core team, what's the freeze date on this?

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

Re: Translation status

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

This work is scheduled for 8.4a2, which is tentatively scheduled for
release July 12.  Thanks for your efforts, everybody, and keep it up!

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

On Tue, 20 Jun 2000 lau...@uf... wrote:

> Hi,
> 
> I'm still moving along with the translation. It's taking more time than I
> expected because there are some not immediately obvious situations that come
> up. I've done most of the translations for the dialogs, and now I'm going
> through the test suites (since they now fail if your native language isn't
> English). There will also need to be a test that changes locales and
> re-executes some of the tests scripts with a different locale. Something
> like 
> 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }
> 
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?
> 
> As for the core team, what's the freeze date on this?
>