tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: Translations strings in CVS

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

On 12 Jul, Giorgos Petasis wrote:
> Hi all,
> 
> I have found a typo in the greek translations.
> Attached you will find the updated file.
> 

Thanks.

> Also, in the version of tk I downloaded from cvs server 2 days ago,
> when an error occurs, the button labeled "Details >>" does not
> use the translated string. Is this now fixed?
> 

Hmm.... I thought that was fixed a long time ago. I'll look into it later
today.

> Well, to say the truth it is a surpise to see messages in your native language.
> I like it. And tk probably looks the LANG & LC_* vars under unix to automatically
> use the correct language! If only the system encoding was set automatically too :-)
> 

Yep. Once we get the -underline and key binding problem out of the way,
things should be real dandy.

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!


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

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

On 12 Jul, Giorgos Petasis wrote:
> Hi all,
> 
> I was checking the massages for the greek language and I think that there is
> a problem regarding the underlines & bindings.

It's not really a "problem", it's more of an "issue". It hasn't been
implemented correctly yet. There have been some discussions on how to best
address this but all the proposals to fix things have met with skepticism
from one person or another. There is a thread in clt on the underline
problem that is raging right now.

I must admit that as time passes by, I'm getting a little bit edgier about
this because, even though the translations work fine, the bindings and
underlines are so badly broken that the translations become a hindrance more
than anything else. It'll be fixed soon, though. We just have to come up
with a proper scheme to do things. I also have to dig up some conversations
I had on the subject with Eric Melski and Mr. Takahashi.

> Although the dialogs seem to work ok (at least the open/save that I tried),
> the underlines appear at odd places (even under spaces :-))

Yeah, sucks rocks, really.

> But this is not the problem: I was using tkcon and when issued a 
> tk command, the dialog appeared that said "this appears to be a tk command...".
> But the "Retry" button was now in greek. Tkcon, underlined the first character
> and while trying to impose a binding on the first letter (the greek p), an error
> occured: "bad event type or keysym "ð"".
> 

That may have something to do with the above. Is the keysym above the greek
"P"? My Greek is kinda rusty... :-)

> This may be a specific tkcon bug, but are we sure that there will be no problems 
> in the tk core? In the messages for various languages is not defined a location
> for placing underlines and using bindings. Tk seems to not support bindings for
> non latin-1 characters, so should we modify things to not assign bindings 
> under non english languages?
> 
> (Have I lost anything from previous discussions? :-))
> 

Probably a bit.

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!


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

[TCLCORE] Re: Greek message files & tkDND...

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

Hi all,

The last mail I sent you containing the Greek messages is working
fine under the tk version I downloaded yesterday from the cvs server.
The oriinal file, encoded in utf-8 does not. Please update your cvs server...

BTW, seems that there was an internal rearrangement in tkIconList widget
used internally by the open/save dialogs. Key navigation does not work any
more. I have also used the bug report system to submit it....

Now regarding the tkDND extension, the progress is as follows:

1) The unix side is working fine. There are still a problem regarding the drop
of multiple files from GNOME, where an additional " 0x00" is appended.
New features include the use of modifiers in bindings (an idea & implemetation
from Laurent Riesterer) like in tk (for example Control-Drag).
We haven't got the time to add code for enabling the drag source to specify 
cursor, and we left it for future work.

2) The windows side is updated, but there are still a few bugs. tkDND does not
cause wish to crash, but I expect some "advanced" features to misbehave.
Reading the specs of OLE dnd, seems that windows side will have
some limitations (notably the inability to use the "ask" and "private" actions).
Of course scripts that use these actions will still work (an error won't be raised)
but these actions would never be used for dnd under windows.
Both Laurent and I plan to rewrite the whole windows part, as the code is not
so well structured as is under unix (at least to my opinion :-)).
But we both are going to leave for vacations this week, and I think
that we have to make a release with the code we have, in order to catch
the 8.4a2 release at the end of the month.

You should expect the code by the end of this week.

Also, just curious, how do you plan to incorporate it into the tk core?
The code as is write now builds a loadable (stubs enabled under unix)
extension. Will it remain that way, or will be mixed with the tk core?

George

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

[TCLCORE] Re: RE: Translations strings in CVS

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

Mr. Hobbs,

I used the scripts from Jan Nijtmans to convert my messages from utf-8
to \u sequences. I attach the new file, please update the tk core...

George

[TCLCORE] Re: Translations strings in CVS

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

On 11 Jul, Giorgos Petasis wrote:
>> As for the Hellenic, I just want to check to make sure that got
>> imported correctly.  The best thing about using \u00xx is that
>> it can't get garbled in something that doesn't understand high
>> bit chars.
> This is logical, although I suspect that tcl can understand them :-)
> And for those who don't know how to create these \u sequences, is
> there a simple procedure in tcl in order to translate them?
> 

Did you try Jan's utility? Does that work? My understanding is that if you
save stuff in the Unicode format, you're no supposed to have all the
conversion problems that you find when using UTF-8. But then, I'm new at
this.

> Sorry for the incovinience,
> 

It's no problem. We'll eventually get all of this right but it might take a
misstep or two along the way.

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!


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

[TCLCORE] Re: RE: Translations strings in CVS

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

In Äåõ, 10 Éïýë 2000, Jeffrey Hobbs wrote:
> Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
I suppose I am the only one who used UTF-8 to encode the messages :-)
The file I sent was encoding using utf-8. I really cannot understand why to
use strange alternative ways in order to specify messages. My opinion is that
the message catalog should encode all its messages in utf-8 and use this encoding
when sourcing the files. Any way, I am willing to translate them into whatever
you want :-). 
Also, Laurent told me that he also had problems opening the files.
I attach the file again, this time is zipped with gzip.

> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
This is logical, although I suspect that tcl can understand them :-)
And for those who don't know how to create these \u sequences, is
there a simple procedure in tcl in order to translate them?

Sorry for the incovinience,

George

[TCLCORE] Re: Translations strings in CVS

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

 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


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

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

Re: Translations strings in CVS

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

Jeffrey Hobbs wrote:
> My thoughts... I think local languages should attempt to truly
> localize.  This may work best the way the Spanish msgs are done -
> (as well as French) in that \u00xx is used for high bit encodings.
> I think the German (and partly the Dutch) messages should use
> umlauted chars and the S-sharp where appropriate (or does MS avoid
> this as well?).
> 
> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
> 
> George - please verify (by checking the file back out of 8.4
> CVS and trying it) that this didn't get garbled.

I already noted this as well, and all I can say is that I fully
agree with you.

Attached is a small utility that can do the correction. Just try:
      msgcv el.msg cp1253
      msgcv ja.msg euc-jp
and the result is two new files "el.msg.out" and "ja.msg.out"
using the '\uXXXX' convention. It should be easy to apply
this to the message files in CVS now. For german, the umlaut-
correction should be done manually first. The Dutch translation
is already in the correct format ;-)

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

Re: RE: Translations strings in CVS

[<ldu...@uf...>]

> I was just reviewing the msg catalog translation strings, and I had
> some questions.
> 
> There seems to be different methods used for encoding the files.
> The Spanish msgs use the \u00xx for extended chars, whereas the
> German msgs avoid them by using the lower ascii expansion
> (&uumlaut; == ue).  Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
> 

I think it because not everyone used the same tools to create the
message catalogue. I used MSGEdit, I think a few others did too (most
likely, the ones that came out with \u00xx). Some used standard editors
which did the output however they felt was best.

> I know this was somewhat discussed, but it looks like no certain
> resolution was imposed.
> 

Uhm... imposed, no. Suggested, yes. I think George had said that the
files he had couldn't be read by the msgcat utility. So he did it how
best he could.

Jan sent us a note today saying he has a little utility that possibly
fixes the problem with George's file. If it does, George will hopefully
be able to send you another version of his translations.

L

Re: Translations strings in CVS

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

--------; charset=us-ascii
 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


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

RE: Translations strings in CVS

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

I was just reviewing the msg catalog translation strings, and I had
some questions.

There seems to be different methods used for encoding the files.
The Spanish msgs use the \u00xx for extended chars, whereas the
German msgs avoid them by using the lower ascii expansion
(&uumlaut; == ue).  Hellenic (el.msg) comes across in something
that I can't view correctly on Windows or Unix (I do have
bitstream cyberbit on Windows, but no specific Greek font).

I know this was somewhat discussed, but it looks like no certain
resolution was imposed.

My thoughts... I think local languages should attempt to truly
localize.  This may work best the way the Spanish msgs are done -
(as well as French) in that \u00xx is used for high bit encodings.
I think the German (and partly the Dutch) messages should use
umlauted chars and the S-sharp where appropriate (or does MS avoid
this as well?).

As for the Hellenic, I just want to check to make sure that got
imported correctly.  The best thing about using \u00xx is that
it can't get garbled in something that doesn't understand high
bit chars.

George - please verify (by checking the file back out of 8.4
CVS and trying it) that this didn't get garbled.

Thanks,

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

[TCLCORE] Re: FW: Q about managing open source development

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

I thought I should share this with everyone on the core list as
we start considering how to open this process up.

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

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 11:54 AM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development




  In message <NDB...@aj...>you
 write:
  > I got your name from Jim Ingham, who noted that you'd be a good person
  > to ask about experiences related to managing an open software development
  > effort (gcc).
As good as any I suppose :-)

  > I'm currently the lead maintainer and manager of Tcl/Tk,
  > but I've also been imbued with the responsibility by John Ousterhout
  > (the original author and CTO of Ajuba) to foster better community
  > involvement in the development.
Understood.

  > Tcl/Tk has always been open source and
  > invited people to hack on it, but in general the core parts have been
  > fairly strictly controlled over its lifetime (you could say it lies in
  > the Cathedral).  So my job is to move it more towards the Bazaar, while
  > trying to avoid the disadvantages of that development model.
Right.  That's the 'trick' of course -- to reap the benefits of a Bazaar
model without the code turning into a mess of spaghetti code.

  > The main ideas that have come up are opening direct CVS write access
  > to more people (it's already in public NetCVS), and creating a
  > steering committee.
Sound like the right steps.  The first (hopefully) leads to more active
participation from developers and a wider team of "core" contributors that
everyone trusts to do the right thing.

That's one of the key things you want to build up -- a larger group of
folks that you trust to do the right thing and to whom you can delegate
tasks (or better yet, they just pick them up because they need to be done).

That's also the first big pitfall -- get the wrong group of core folks and
you end up with a mess of code or personality conflicts that rip the project
apart (witness the *bsd* splinters over the years).

The other big pitfall is just learning to trust a wider range of folks and
even if you disagree with them sometimes to realize that if you can't design
and implement a better solution (usually due to time constraints), then
sometimes you have to let them go in a direction that maybe you wouldn't.

  > I noticed that the gcc steering committee was
  > formed of people "to represent the interests of [different] communities".
  > Did this prove to work well?  I am currently making the decision on
  > who should be considered for the steering committee (or on what basis).
This was both a practical and political move -- people have been more
comfortable knowing that it wasn't just Cygnus (or me) calling the shots.
It's been extremely valuable in dealing with RMS and some conspiracy theory
folks.

But is was also a very practical move -- in the past GCC had been controlled
by two people (RMS on the policial side, Kenner on the development side) and
experience had shown us that that model simply wasn't working and we had to
try something different.

So we contacted a group of folks, not necessarily all developers, that had
a long term interest in seeing GCC succeed and who were well respected
in different communities that used GCC.   The steering committee basically
deals with political issues, not technical ones (which we leave in the hands
of the developers, where it belongs).  We've been very happy with the results.

Overall, the biggest thing I've found is if you make the developers happy,
they'll want to contribute more time/energy.  That in turn allows the project
to grow.  If the developers are unhappy, then you have to find out why and
rectify the problem.

  > I'd appreciate it if you could share with me any insight on what to
  > watch out for, based on your experience, as I move forward with this.
  > Perhaps also what you would have done differently.
I (personally) would not have gotten buddy-buddy with RMS again, it's been
a major headache, but I was outvoted on that particular issue.  The lesson
is be very careful who you bring into the political decision process; people
who are not willing to compromise for the overall good of the project are
generally bad choices :-)

Good luck,
jeff


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

[TCLCORE] Re: QT Developer Interview

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

I got this off slashdot.  It's part 4 of an interview with one of
the Qt Toolkit developers.  I picked this part, because it is where
he discusses (just shortly), his experiences with distributed
development in the Qt project:
	http://www.beopen.com/features/interviews/wallison_part4.html

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: Final MSGedit fixes

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

lau...@uf... wrote:
> 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.

Here is, finally, the fix for the described problem. Just apply this
patch to the standard MSGedit distribution and everything should be O.K.

The cause of this problem was a wrong ordering of substitutions before
saving the string. The result was that in the case of '\n' the
backslash was doubled. Performing the double-backslash substitution
before the '\n'-substitution fixes everything.

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

[TCLCORE] Re: Final MSGedit fixes

[<ldu...@sp...>]

On  8 Jul, Jan Nijtmans wrote:
> Here is, finally, the fix for the described problem. Just apply this
> patch to the standard MSGedit distribution and everything should be O.K.
> 

I thank thee, sire. :-)

L



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

[TCLCORE] Re: Words to consider...

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

I'm sure this is irritating everybody else almost as much as it is me.
Sorry.

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

- eric

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

[TCLCORE] Re: Words to

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

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

- eric

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

[TCLCORE] Re: Words

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

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

- eric

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

[TCLCORE] Re: Words

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

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

- 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] Words to consider...

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

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

- eric

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

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

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

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

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

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

Also sprach Scott Stanton:

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

First off, you should have a look at gcc.gnu.org, which is the official
version of the old cygnus egcs site.  They have some nice stuff there.  The
Maintainers list and the hack rules are in the gcc sources.

Also, it might be good to contact the egcs folks - maybe Jeff Law would be a
good person to try, or Jim Wilson.  They are pretty dedicated to open source
development, and also have had a lot of experience both with the more closed
development of the old gcc, and with setting up a more open community in the
face of this other development model.  If you had some idea of what you
wanted to do, they would probably be willing to give you some good feedback
on it.  I know in particular that Jeff is not shy of expressing his
opinions, and he is a good guy to talk with.

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] Re: [TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

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

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

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