tcl-core — Tcl Core Team discussions about Tcl development

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

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