tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: [TCT] Welcome...

[D. R. H. <dr...@hw...>]

Jim Ingham wrote:
>
> I think that patches should in general be staged, 
> and posted publically before they are committed.
> I also think that we need to set up some light-
> weight peer review scheme as well.
>
> Here is the way that it works for gdb & gcc, and 
> I think this is a pretty good method 
>
> [...]

This all sounds good to me.  This is similar to
things I've done in the past that worked, and it
appears also to work for gcc/gdb.

Are there any counter-proposals?

To implement Jim's scheme, somebody with the right
privileges needs to take the following actions:

  1.  Create a c.l.t.patches newgroup OR a tclpatches
      mailing list OR a tcl patches database

  2.  Break the source tree into functional areas
      and assign a maintainer to each area.

  3.  Set up CVS so that maintainers can checkin
      at any time and that others can checkin
      with an appropriate approval cookie from the
      maintainer.

  4.  Figure out how to run CVS over SSH without
      also given people a login and set up the
      CVS server accordingly.

  5.  Collect SSH keys from the maintainers, etc.

  6.  Document the above so that people can use
      the system.

Clearly, it would be much easier for me to just
send the patches to Jeff than to worry through all
of the above.  But perhaps it is worth the trouble
to walk through the above, just to get things moving.

Assuming we move forward with this (a big
assumption, I know) who will do all of the above
for us?  My guess is that the set of people with
the right privileges is limited to Jeff and Brent.
Unless we move the source tree out to SourceForge
or something.

Thoughts?  Volunteers?

If we decide to do something like this, I'll help
help with the documentation in item (6).
-- 
D. Richard Hipp -- dr...@hw... -- http://www.hwaci.com/drh/

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

[TCLCORE] Re: Fwd: [TCT] Welcome...

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

Jeffrey,

Here is a copy of this message that I sent to the TCT mailing list.  It is better in this forum, I think.

I really think that having a staged checkin process like the one I describe for gdb & gcc is a good idea, mostly because it makes it much easier for everybody in the community to know what is going on - CVS mail is a pain, since you then have to go dig out the changes, and it is too easy to let stuff just fly past unnoticed.  We have done this for gcc & gdb for a while, and it does not seem an onerous burden.

Jim

Begin forwarded message:

> From: Jim Ingham <ji...@ap...> 
> Date: Mon, 28 Aug 2000 15:14:50 -0700 
> To: "D. Richard Hipp" <dr...@hw...> 
> Cc: TCT Mailing List <tc...@aj...> 
> Subject: Re: [TCT] Re: Welcome... 
> X-Mailer: Apple Mail (2.333) 
>  
>  
> Hi, Richard... 
>  
> I think that patches should in general be staged, and posted publically before they are 
> committed.  I also think that we need to set up some light-weight peer review scheme as 
> well. 
>  
> Here is the way that it works for gdb & gcc, and I think this is a pretty good method 
>  
> 1)  ALL patches should first be sent to some patches address (either 
> comp.lang.tcl.patches, or c.l.t with some special tag for patches, or to the bug 
> database - we have to decide which is easiest).  This provides easy archiving, and raises 
> visibility for all changes.  It also puts patches from the Core team and external 
> contributors on an equal footing, which is a salutary thing. 
>  
> 2) The sources are broken up into functional areas, and each functional area has a 
> maintainer & a backup maintainer(s).   These are listed in a MAINTAINERS file in the 
> sources.   
>  
> 3) The maintainer can check in changes to his or her area at the same time as posting the 
> patches notice. 
>  
> 4) Other people can be granted "checkin after approval" privileges - presumably all the 
> TCT will all have this privilege, but it can be extended to people who have expertise in 
> more limited areas, for their area.  These people can check in the code once they have been 
> given the OK.   
>  
> It is the duty of the maintainers to be timely in their replies, and that is also why it is a 
> good idea to have a backup. 
>  
> 5) It is also the responsibility of the maintainer to check in the patches from other 
> people (without checkin after approval privileges). 
>  
> 6) As to mechanics, it is probably easiest to use SSH to obtain write access.  CVS works 
> pretty well with SSH, and it is easy to mail the CVS maintainer your SSH key.  Kerboros 
> would be another alternative, but I think that it is harder to set up.  Anyway, we use SSH at 
> Cygnus for the sourceware repositories, and it was quite easy to setup and administer. 
>  
> Jim 
>  
>  
> On Monday, August 28, 2000, at 01:40 PM, D. Richard Hipp wrote: 
>  
> > I am deeply honored to be a part of the Tcl Core team  
> > and I look forward to contributing to this effort in   
> > the weeks and months ahead.  
> >   
> > For now:  
> >   
> > I have in hand a patch to Tk8.4 that fixes a X11  
> > "BadMatch" error.  It used to be that I would send  
> > such patches to Jeff and they would get into the   
> > next release.  But I'm thinking it sure would be   
> > a lot easier (for me and Jeff both) to just do a  
> > "cvs commit"....  
> >   
> > What are the procedures for writing to the CVS  
> > repository?  How are updates coordinated to prevent  
> > someone from committing an unstable change right   
> > before an important release, for example?  Is there  
> > any kind of peer review of changes?  How to we get  
> > turned on for write access to the CVS repository?  
> >   
> > Are these reasonable questions, or am I way ahead of  
> > myself?  
> > --   
> > D. Richard Hipp -- dr...@hw... -- http://www.hwaci.com/drh/  
> >   
> > --  
> > This is the Tcl Core Team (TCT) mailing list.  
> > To subscribe:    send mail to tct...@aj... with the   
> >                  word SUBSCRIBE as the subject.  
> > To unsubscribe:  send mail to tct...@aj... with the   
> >                  word UNSUBSCRIBE as the subject.  
> > To send to the list, send email to 'tc...@aj...'.   
> > Currently there is no publically viewable list archive.  
> >   
> > Note: an @scriptics.com email will work also, and we plan to move  
> > this to @tcltk.org as quickly as possible.  
> >   
> >   
>  
> -- 
> Jim Ingham                                   ji...@ap... 
> Developer Tools - gdb 
> Apple Computer 

--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

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

[TCLCORE] Re: CVS write access

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

BTW, to follow up my own post, we have some of this info already on
the dev site at:
  http://dev.scriptics.com/software/tcltk/contributing.tml#goodpatch

Also, we have used the tclcore mailing list before as a forum for
peer review (as Laurent is doing now with the i18n underlining patch).
This is good for smaller patches, when people are just getting used
to the C APIs, etc.

For larger projects, the goal would be to have each project work
on its own branch (like I recently did with tcl-8-3-1-io-rewrite),
and that person would do all the work, only commiting when they
are finished and fully satisfied with the code (and docs and tests).

When you want someone to test that, they only need to move over
to your branch and check things out.  Also, it's a one-liner to
diff between branches (although that can be a large diff...).

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

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

[TCLCORE] CVS write access

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

I've moved this question to the tclcore list as it applies for
all people with CVS write access.

> From: drh [mailto:drh]On Behalf Of D. Richard Hipp
	...
> I have in hand a patch to Tk8.4 that fixes a X11
> "BadMatch" error.  It used to be that I would send
> such patches to Jeff and they would get into the 
> next release.  But I'm thinking it sure would be 
> a lot easier (for me and Jeff both) to just do a
> "cvs commit"....

All TCT members are allowed direct write access to the core, but
we need to all agree on the basic rules of code cleanliness and
good docs and tests (as Jim mentioned before).  It's been
suggested that any TCT member can recommend others to have write
access to work on particular projects, and that that TCT member
would be responsible for making sure the project doesn't break
things (hopefully the other person takes care of this themselves).

> What are the procedures for writing to the CVS
> repository?  How are updates coordinated to prevent
> someone from committing an unstable change right 
> before an important release, for example?  Is there
> any kind of peer review of changes?  How to we get
> turned on for write access to the CVS repository?

All changes should be thoroughly tested before being commited.
We understand that some people only have one Unix or Windows
flavor to test on.  We hope to get a nightly build set up that
does the full builds and tests (we have that already) and then
points fingers at the last who commited changes when something
breaks (we don't have that yet).

The concept of peer review is interesting.  Hopefully anyone
putting code back will have read and stick to the Tcl Engineering
Style Guide (basically tells all the C style that is used in
the current code - we have emacs lisp code to assist in sticking
to this), as well as the Tcl Style Guide for Tcl code and how
to write test suites.

John Ousterhout recommended that as we start up, each TCT member
could work on a project that was destined for the next release.
We could then all do a mass peer review and make comments.  I'm
not sure how necessary this is, how comfortable everyone is with
this, or if people even feel they have the time to do that.

In general, you can be sure that peer review of a sort occurs
because every other developer will see the check-ins.  I guess
the most important point then is to make sure that everyone knows
how to use ChangeLogs properly so we can just track things just
in case something happens.  After all, this is an open project,
and if the build doesn't work for a couple of nights, the world
will not come to an end.

However, we do want to stick to the high standards set by those
who came before (starting with JohnO).  That's made it very easy
for people like myself to step in and learn to work on the core
without wondering what the heck the other guy was thinking when
they wrote some code.  We don't want to come to the point that
Perl has - having to rewrite Perl6 from "scratch" because the
internals are in such a bad shape.

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

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

[TCLCORE] Re: -underline patch v. 0.2 [tcl gateway]

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

On 28 Aug, Scott Stanton wrote:
> This code seems to be confused.  You should replace the code above with:
> 

Ugh! THere was a conflict with tkButton.c an I thought I'd fixed it
properly.

> Again, the reference counting is off here.  You should say:
> 

Thanks for pointing it out. Does it show that I've never touched the C API?
:-)

> You 
> should also verify that there's no way to get to the display code with a 
> null textDisplayPtr.
>

Like Jeff says, I'll run the complete test suite to make sure.

L

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

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


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

[TCLCORE] Re: -underline patch v. 0.2 [tcl gateway]

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

Make sure that you always also run the full test suite over the code
when changing these things.  Even when it seems unrelated, just make
sure to run the full test suite before any check-ins.  I made what I
thought was a refcount fix to the button code like Scott mentions
below, which turned out to be incorrect.  This didn't turn up in
button.test (which is the only one I ran stupidly enough).  It turned
up in canvImg.test.

I didn't take the time to research why what I did was wrong, but
obviously it was more correct than the crash I got afterwards...

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

> -----Original Message-----
> From: Scott Stanton [mailto:st...@aj...]
> Sent: Monday, August 28, 2000 10:25 AM
> To: Laurent Duperval
> Cc: tc...@aj...; jc...@gm...; a.k...@we...;
> pe...@ii...; j.n...@ch...; bi...@ny...
> Subject: [TCLCORE] Re: -underline patch v. 0.2 [tcl gateway]
> 
> 
> 
> Laurent Duperval said:
> 
>  > +     /*
>  > +      * Incr valuePtr before Decr, in case they point to the same 
> object.
>  > +      * We could also do some short-circuiting in that case, but it
>  > +      * shouldn't happen in practice.
>  > +      */
>  > +     Tcl_IncrRefCount(valuePtr);
>  > +     butPtr->textPtr = valuePtr;
>  > +     /* Tcl_IncrRefCount(butPtr->textPtr); */
>  > + 	ButtonComputeUnderline(butPtr);
>  >       Tcl_DecrRefCount(butPtr->textPtr);
>  >       butPtr->textPtr = valuePtr;
>  >       Tcl_IncrRefCount(butPtr->textPtr);
> 
> This code seems to be confused.  You should replace the code above with:
> 
> Tcl_IncrRefCount(valuePtr);
> Tcl_DecrRefCount(butPtr->textPtr);
> butPtr->textPtr = valuePtr;
> ButtonComputeUnderline(butPtr);
> 
> 
> 
>  > + 	/* 
>  > + 	 * At this point, we have a correct value for -text. Copy that value 
> in
>  > to
>  > + 	 * the display pointer. Should the previous value be discarded? 
> Hmmmm..
>  > .
>  > + 	 */
>  > + 	butPtr->textDisplayPtr = Tcl_DuplicateObj(butPtr->textPtr);
> 
> Again, the reference counting is off here.  You should say:
> 
>     Tcl_Obj *newTextPtr;
> 
>     newTextPtr = Tcl_DuplicateObj(butPtr->textPtr);
>     Tcl_IncrRefCount(newTextPtr);
>     if (butPtr->textDisplayPtr) {
> 	Tcl_DecrRefCount(butPtr->textDisplayPtr);
>     }
>     butPtr->textDisplayPtr = newTextPtr;
> 
> This will ensure that the old display string (if one exists) is released.  
> Also, you need to add code to ButtonCreate to initialize the butPtr->
> textDisplayPtr to NULL when the button structure is first created.  You 
> should also verify that there's no way to get to the display code with a 
> null textDisplayPtr.
> 
> --Scott
> 
> 
> --
> The TclCore mailing list is sponsored by Ajuba Solutions
> To unsubscribe:  email tcl...@aj... with the 
>                  word UNSUBSCRIBE as the subject.
> 

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

[TCLCORE] Re: -underline patch v. 0.2 [tcl gateway]

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

Laurent Duperval said:

 > +     /*
 > +      * Incr valuePtr before Decr, in case they point to the same 
object.
 > +      * We could also do some short-circuiting in that case, but it
 > +      * shouldn't happen in practice.
 > +      */
 > +     Tcl_IncrRefCount(valuePtr);
 > +     butPtr->textPtr = valuePtr;
 > +     /* Tcl_IncrRefCount(butPtr->textPtr); */
 > + 	ButtonComputeUnderline(butPtr);
 >       Tcl_DecrRefCount(butPtr->textPtr);
 >       butPtr->textPtr = valuePtr;
 >       Tcl_IncrRefCount(butPtr->textPtr);

This code seems to be confused.  You should replace the code above with:

Tcl_IncrRefCount(valuePtr);
Tcl_DecrRefCount(butPtr->textPtr);
butPtr->textPtr = valuePtr;
ButtonComputeUnderline(butPtr);



 > + 	/* 
 > + 	 * At this point, we have a correct value for -text. Copy that value 
in
 > to
 > + 	 * the display pointer. Should the previous value be discarded? 
Hmmmm..
 > .
 > + 	 */
 > + 	butPtr->textDisplayPtr = Tcl_DuplicateObj(butPtr->textPtr);

Again, the reference counting is off here.  You should say:

    Tcl_Obj *newTextPtr;

    newTextPtr = Tcl_DuplicateObj(butPtr->textPtr);
    Tcl_IncrRefCount(newTextPtr);
    if (butPtr->textDisplayPtr) {
	Tcl_DecrRefCount(butPtr->textDisplayPtr);
    }
    butPtr->textDisplayPtr = newTextPtr;

This will ensure that the old display string (if one exists) is released.  
Also, you need to add code to ButtonCreate to initialize the butPtr->
textDisplayPtr to NULL when the button structure is first created.  You 
should also verify that there's no way to get to the display code with a 
null textDisplayPtr.

--Scott


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

[TCLCORE] -underline patch v. 0.2 [tcl gateway]

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

Hi,

Here is another patch for the -underline stuff which addresses some of the
issues that Scott has raised with my first patch.

On 22 Aug, Scott Stanton wrote:
> - If you are adding \_ to the Tcl backslash parser, you need to do the 
> same thing for the regexp backslash parser.
> 

Not implemented yet.

> - Rather than putting a constant like 0x332 directly in the code, it might 
> be better to add a #define for TCL_COMBINING_LOW_LINE (the official 
> Unicode character name).
> 

Done.

> - Don't assume that the \_ character actually takes 2 bytes.  This is only 
> true if the string is in canonical UTF form.  It's actually possible to 
> represent a \_ with 3 or more bytes in a non-canonical form.  Always use 
> the Tcl UTF functions to compute character offsets.
> 

Done.

> - Your algorithm ends up scanning the string twice.  It would be faster to 
> skip the call to Tcl_UtfFindFirst() and just do character by character 
> comparisons.
> 

Kinda done. I still have to set up a display string object. I do it with
Tcl_DuplicateObj but I'm pretty sure there's a better way to do it. I
haven't had enough time to think things through properly.

> - If you remove the \_ from the original text string, then a cget -text 
> won't return the correct value.  You need to make a separate copy of the 
> string for rendering purposes.
> 

Done.

> - If you were going to update the string in place, you should call 
> Tcl_SetObjLength to set the new length.
> 

Done. It should work with Win and Mac too.

I figure I'd release this interim patch to get more feedback. a2 is pretty
late and I somehow have the nagging feeling that the incompleteness of the
I18N stuff isn't helping.

I'd like to have feedback on the general ideas in the patcch, specially from
people like George Petasis and Keiichi Takahashi who use fonts that are
outside of ISO Latin 1. If people like the idea and if the implementation
doesn't suck too bad, there are a few more things to do:

- Patch the regexp stuff
- Translate all the msgcat strings to use the \_ mechanism
- Document the changes in the man page
- Fix the key bindings in the dialogs. I was thinking of using the new
  functionality to do something like:

set bindchar [string index [.button cget -text] [.button cget -underline]]
bind <Alt-$bindchar> {.....}

If anyone is willing to help out with some of this, I'd appreciate it.
Otherwise, I'll do it as time permits. I'm not sure how soon we need all
this.

L

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

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

[TCLCORE] Re: --enable-gcc is dead!

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

On Fri, 25 Aug 2000, Brent Welch wrote:

> Urk - I think the correct change to make is to add --disable-gcc,

Then why not add a --enable-cc and --disable-cc. You would also
need a --enable-cl and --disable-cl by that logic.

> or alter the --enable-gcc rule to honor the CC variable.

I did that already. It was a reasonable solution for 8.3, but
for 8.4 there is no reason to keep --enable-gcc in the code.

> It seems easy
> to come up with a solution that handles both without breaking all the
> CONFIG
> scripts that I have.  I'm sure we are not the only company with build 
> environments
> that have --enable-gcc embedded somewhere.  Why break it?

Your scripts probably wont break. If you passed --enable-gcc
before, it will just get silently ignored and gcc will be
picked as the default if it can be found on the path.

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: --enable-gcc is dead!

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

Urk - I think the correct change to make is to add --disable-gcc,
or alter the --enable-gcc rule to honor the CC variable.  It seems easy
to come up with a solution that handles both without breaking all the
CONFIG
scripts that I have.  I'm sure we are not the only company with build 
environments
that have --enable-gcc embedded somewhere.  Why break it?

>>>Mo DeJong said:
 > There has been a lot of talk lately about the --enable-gcc option.
 > 
 > Some people loved it, some folks hated it. Well, for those
 > of you that hated it, you can rejoice as I just did a commit
 > of a patch that removes all trace of the --enable-gcc flag!
 > 
 > If you loved --enable-gcc, feel free to flame me :)
 > I hope this did not break anyones build, but this
 > was a big change so I might have broken something.
 > 
 > The new rule is to set the CC env var to tell configure
 > what compiler you want to use.
 > (actually this is the old rule, Tcl just did not follow it).
 > 
 > 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.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


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

[TCLCORE] "tclcore" mailing list expanded to include all Tcl Core Team members

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

I have extended the tc...@aj... mailing list to include
all members of the new Tcl Core Team.  These people are:

Jeffrey Hobbs			John Ousterhout
Michael McLennan		Jim Ingham
Donal Fellows			Richard Hipp
Mark Harrison			Jan Nijtmans
Brent Welch			Andreas Kupries
George Howlett		Don Porter
Mo DeJong			Karl Lehenbauer

This mail list is different from the "tct" list in that it is open
for anyone in the community to post to (it is in fact the address
that we encourage those willing to help to send mail to).  It is also
open and archived for the entire community to see:

	http://dev.scriptics.com/lists/tclcore/

The list does have moderated subscription though, as it is intended
to be used mostly for active core developer communication. In addition,
the following people have some level of write access to the core and
are on this list:

Eric Melski			Scott Stanton
Dan Kuchler			David Gravereaux
Joe English			Don Bowman
Andre Poenitz

This list is intended to grow to include anyone with write access to
the Tcl core.  This list is not meant to preclude the creation or
use of mailing lists for primary extensions (for example, there is
already an it...@sc... list).  The list also has the @scriptics.com
alias, for those wanting to make sure their filters get everything.

Again, this list is open for all to read and post to, but not join.
The tct list is intended for the private discussion of the Tcl Core
Team, when they deem it necessary.

Thanks,

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: --enable-gcc is dead!

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

Well this seems to work fine on some standard system setups,
and the old way wasn't so screwy that this should break any
"standard" or well-maintained systems (keep your fingers
crossed).  We'll just have to make sure that this is noted in
the release notes for 8.4a2.

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

> -----Original Message-----
> From: Mo DeJong [mailto:md...@cy...]

> ... I just did a commit
> of a patch that removes all trace of the --enable-gcc flag!
> 
> If you loved --enable-gcc, feel free to flame me :)
> I hope this did not break anyones build, but this
> was a big change so I might have broken something.
> 
> The new rule is to set the CC env var to tell configure
> what compiler you want to use.
> (actually this is the old rule, Tcl just did not follow it).

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

[TCLCORE] Re: --enable-gcc is dead!

[Joe E. <jen...@fl...>]

Larry W. Virden <lv...@ca...> wrote:

> 	If you need a directory, indicate by example where in the tree you
> 		want.  Sometimes extentions want the top of the source tree,
> 		sometimes they want the top of an installation directory
> 		(which may NOT be the top of the Tcl installation directory!),
> 		and sometimes they want some subdirectory in one of these.

To that I would add:  If the user specifies --with-foo=/where/ever/,
and the configure script doesn't find what it's looking for there,
please issue an error message and quit immediately instead of
continuing to look in the default places.

--Joe English

  jen...@fl...

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

[TCLCORE] Re: --enable-gcc is dead!

[Larry W. V. <lv...@ca...>]

> (actually this is the old rule, Tcl just did not follow it).

Weird - I always seemed to get what I wanted out of any configure by
setting the CC variable (and the CCC variable when setting the C++ compiler).

A few notes for configure writers :
	If you activate an enable flag, PLEASE activate a disable flag!
		That was my only gripe about the enable-gcc flag.

	If you activate other specialty flags, indicate clearly in the help
		whether the flag is a boolean (with the option to indicate
		the negative as well) or indicate what specifically the flag
		is wanting indicated *by example* .  I've seen --help
		output which sometimes wants you to specify --with-stuff
		as a boolean, sometimes with an add-on value --with-other=stuff.

	If you need a directory, indicate by example where in the tree you
		want.  Sometimes extentions want the top of the source tree,
		sometimes they want the top of an installation directory
		(which may NOT be the top of the Tcl installation directory!),
		and sometimes they want some subdirectory in one of these.

	If your extension is installing binary components, be sure to check
		the exec-prefix for configure for the path where the user
		wants binaries installed.

	If your extension is purely tcl, give the user the option of installing
		a symlink or provide a shell wrapper that points to the real
		source directory.  That provides an easier way to move between
		releases...
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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

[TCLCORE] --enable-gcc is dead!

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

There has been a lot of talk lately about the --enable-gcc option.

Some people loved it, some folks hated it. Well, for those
of you that hated it, you can rejoice as I just did a commit
of a patch that removes all trace of the --enable-gcc flag!

If you loved --enable-gcc, feel free to flame me :)
I hope this did not break anyones build, but this
was a big change so I might have broken something.

The new rule is to set the CC env var to tell configure
what compiler you want to use.
(actually this is the old rule, Tcl just did not follow it).

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] TLS 1.4 tagged and ready

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

I've tagged the TLS cvs sources at tls-1-4 and created a distribution
for tls1.4.  There is also a new 'make dist' to ease this process in
the future.  The distribution is a subset of the CVS files, not including
the old tests directory.

Once I touch bases with Brent to find the right place on the ftp site,
we'll put it out and make an announcement.

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: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

[John H. <jo...@dc...>]

Jeffrey Hobbs writes:
|To be more specific, in TkWmRestackWmToplevel, we do an
|XReconfigureWMWindow, and then we wait for a ConfigureNotify event
|back.  This has a 2 second timeout, which is exactly what users
|see on wm's that don't serve one up.

Exactly which version of sawfish does this happen with? Since 0.30.1
sawfish ensures that it generates a single synthetic ConfigureNotify
event for every ConfigureRequest. I've appended the relevant log entry,

	John



2000-07-12  John Harper  <jo...@dc...>

        * events.c (configure_request): ensure that one (and only one)
        synthetic ConfigureNotify event is sent to the window after the
        configure request has been handled (even if the window's state
        doesn't change at all)

        [ this fixes the bug where menus in java/swing apps appear too
        high until the window has been moved ]

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

[TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

[John H. <jo...@dc...>]

Jeffrey Hobbs writes:
|There used to be the same problem in E, which was fixed in 0.16
|(I think between 0.15 and 0.16).  See the notes at:
|  http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=3777&mode=full

This is something different, the comments in this bug report are about
enlightenment doing unexpected window reparenting, sawfish doesn't do
this (it doesn't use a pseudo root, and it only reparents each client
window once)

	John

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

[TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

[Jonas L. <jo...@in...>]

And jef...@aj... spoke unto the world. And said:
> There used to be the same problem in E, which was fixed in 0.16
> (I think between 0.15 and 0.16).  See the notes at:
>    http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=3777&mode=full

> The author of E knew what the change required was, so you may
> want to ask him.  I suspect that a lot of shared code was used at
> some point that introduced these bugs in the gnome wm clients.
> In any case, there is a solution for them.

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

> From: Laurent Duperval [mailto:lau...@ne...]
>> On 22 Aug, John Harper wrote:
>> > Laurent Duperval writes:
>> > |$ wish
>> > |% raise .
>> > |% raise .
>> > |
>> > |The first raise command should work fine. The second one takes a 
>> few seconds
>> > |to show up. In discussing the bug, there is an explanation of what is
>> > |happening behind the scnes. Maybe someone here can take a look to see if
>> > |this can be fixed in sawfish.
>> > 
>> > using the above code, I can't see any bug, can you be more specific
>> > about how to reproduce the problem?
>> > 
>> 
>> Hmmmm.... It's possible that it's a GNOME problem:
>> 
>> ...

Sorry, but I don't get it. You report on a supposed bug without any
consistent way of reproducing it. The "wish; raise .; raise ." sequence
doesn't behave in any way strange. From the discussion at the Scriptics
web site it seems the problem lies with some suspiciously simplistic
algorithm in TkWmRestackToplevel. I doubt this has anything at all to do
with sawfish.

/J
________________________________________________________________________
Jonas Linde  init ab  jo...@in...  www.init.se/~jonas/  +46-707-492496

GE/IT$ d-() s++: a C++(++++)$ UBVL++(++++)$ P++ L+++>$ E++ W++(-) N+ o--
K+ !w(+) O M@ V PS+ PE++(-) Y+ PGP+>++ t 5 X R-@ tv- b++ DI D++ G++ e+++
h---- r+++ y++++ UF+

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

[TCLCORE] Updated test results for TLS pre-1.4

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

I just cleaned everything out and retested TLS pre-1.4 with RSA bsafe
and OpenSSL 0.9.5a.  Everything is happy on Solaris, but tlsIO-8.1
breaks consistently on Windows.  This is the test for -async handling
in the socket call.

It's slightly modified from the original socket-8.1, in order for
TLS handshaking to occur in-process.  Those changes are necessary
and reasonable, but I'm not sure if I've gone and made it platform-
dependent because Windows non-blocking would work differently.  Any
ideas?  The actual test failing is:

==== tlsIO-8.1 testing -async flag on sockets FAILED
==== Contents of test case:

    # NOTE: This test may fail on some Solaris 2.4 systems.
    # See notes in Tcl's socket.test.
    set s [tls::socket  -certfile $serverCert -cafile $caCert -keyfile
$serverKey  -server accept 8830]
    proc accept {s a p} {
        global x
        # when doing an in-process client/server test, both sides need
        # to be non-blocking for the TLS handshake.  Also make sure
        # to return the channel to line buffering mode.
        fconfigure $s -blocking 0 -buffering line
        puts $s bye
        close $s
        set x done
    }
    set s1 [tls::socket  -certfile $clientCert -cafile $caCert -keyfile
$clientKey  -async [info hostname] 8830]
    # when doing an in-process client/server test, both sides need
    # to be non-blocking for the TLS handshake  Also make sure to
    # return the channel to line buffering mode (TLS sets it to 'none').
    fconfigure $s1 -blocking 0 -buffering line
    vwait x
    # TLS handshaking needs one byte from the client...
    puts $s1 a
    # need update to complete TLS handshake in-process
    update
    set z [gets $s1]
    close $s
    close $s1
    set z

---- Result was:

---- Result should have been:
bye
==== tlsIO-8.1 FAILED

If I change the "close $s" in the [accept] proc to "after 1000 close $s",
it works OK on Solaris and Windows.  The original test didn't need that.

Comments?

BTW, our cipher tests for OpenSSL still fail with more ciphers returned
(like EXP1024*).  Do we really care about that cipher list?

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] A new platform for Tcl!

[David G. <dav...@aj...>]

Edevaldo,

I'm excited about this and thought I'd forward it to the tclcore list for their
consideration and ideas.
--
  David Gravereaux <dav...@aj...>      Yet Another Tcl Guy
  Sustaining Engineer (Tech Support)                  Ajuba Solutions
  (650) 230-4079

[TCLCORE] Re: Fwd: -underline patch [tcl gateway]

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

On 22 Aug, Scott Stanton wrote:
> 
> This is a great idea!  It's taking advantage of some features in Unicode 
> to finesse the whole underline issue.  The concept is quite elegant, 
> really.  I do have a few comments about the implementation though:
> 

Thanks to Jan for the idea. I didn't even know such a character existed.

> - If you are adding \_ to the Tcl backslash parser, you need to do the 
> same thing for the regexp backslash parser.
> 

Ok, I'll look at it as soon as I have the time. Maybe even tonight.

> - Rather than putting a constant like 0x332 directly in the code, it might 
> be better to add a #define for TCL_COMBINING_LOW_LINE (the official 
> Unicode character name).
> 

Ok. Does this go in tcl.h? I guess, if it's needed by Tk.

> - Don't assume that the \_ character actually takes 2 bytes.  This is only 
> true if the string is in canonical UTF form.  It's actually possible to 
> represent a \_ with 3 or more bytes in a non-canonical form.  Always use 
> the Tcl UTF functions to compute character offsets.
> 

Ok. I'll revise that.

> - Your algorithm ends up scanning the string twice.  It would be faster to 
> skip the call to Tcl_UtfFindFirst() and just do character by character 
> comparisons.
> 

Hmmm... Ok. I have to go thru the string anyway.

> - If you remove the \_ from the original text string, then a cget -text 
> won't return the correct value.  You need to make a separate copy of the 
> string for rendering purposes.
> 

Well, the whole idea of removing the string was so I wouldn't have to keep a
separate copy around. I didn't want to modify the structure of tkButton and
gobble up even more memory. As I said in the Enhancement request on clt, I
didn't really like it. ... So maybe I'll add another attribute to tkButton
which will be non-null only if the string contains a \_ in it. That way, you
only use up 4 bytes to store the pointer but nothing else if you're not using
the facility. This will change the way ConfigureButton() works.

> - If you were going to update the string in place, you should call 
> Tcl_SetObjLength to set the new length.
> 

Ok, didn't know thatg.

> 
> For illustrative purposes, here is a revised ButtonComputeUnderline 
> function.  It hasn't been tested (and so is probably wrong in some 
> places), and it assumes the addition of a butPtr->textDisplayPtr field to 
> hold the display string.  It does demonstrate the correct way to process 
> the UTF data, though.  Note the use of Tcl_GetStringFromObj to get the 
> length in bytes in addition to the string pointer.
> 

Thanks, I'll study it and I'll try to send a revised patch by week's end but I
make no promises.

L

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

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



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

[TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

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

On 22 Aug, John Harper wrote:
> Laurent Duperval writes:
> |$ wish
> |% raise .
> |% raise .
> |
> |The first raise command should work fine. The second one takes a few seconds
> |to show up. In discussing the bug, there is an explanation of what is
> |happening behind the scnes. Maybe someone here can take a look to see if
> |this can be fixed in sawfish.
> 
> using the above code, I can't see any bug, can you be more specific
> about how to reproduce the problem?
> 

Hmmmm.... It's possible that it's a GNOME problem:

# WindowMaker
% time {raise .}
11710 microseconds per iteration
% time {raise .}
10322 microseconds per iteration
% time {raise .}
10483 microseconds per iteration
% time {raise .}
11137 microseconds per iteration
% time {raise .}
10497 microseconds per iteration

# fvwm2
% time {raise .}
2320 microseconds per iteration
% time {raise .}
312 microseconds per iteration
% time {raise .}
318 microseconds per iteration
% time {raise .}
315 microseconds per iteration

# E
% time {raise .}
6839 microseconds per iteration
% time {raise .}
6707 microseconds per iteration
% time {raise .}
6883 microseconds per iteration

#TWM Under GNOME
% time {raise .}
2755 microseconds per iteration
% time {raise .}
3904 microseconds per iteration
% time {raise .}
2661 microseconds per iteration
% time {raise .}
3822 microseconds per iteration

# ICE Under GNOME
% time {raise .}
16696 microseconds per iteration
% time {raise .}
2011383 microseconds per iteration
% time {raise .}
2006532 microseconds per iteration

# sawfish under GNOME

% time {raise .}
12362 microseconds per iteration
% time {raise .}
2010147 microseconds per iteration
% time {raise .}
2008609 microseconds per iteration
% time {raise .}
2011134 microseconds per iteration

E under GNOME shows the same type of behaviour as ICE: when the window is
first raised, it takes no time. But if it is raised and you try to raise it
again, it takes about 2 seconds.

I haven't been able to test sawfish without running GNOME and I haven't been
able to test any window manager under KDE.

L

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

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



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

[TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

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

To be more specific, in TkWmRestackWmToplevel, we do an
XReconfigureWMWindow, and then we wait for a ConfigureNotify event
back.  This has a 2 second timeout, which is exactly what users
see on wm's that don't serve one up.

I believe this is a wm bug because it works on almost all other
wms.  The problem was encountered in E as well, and the author
there also agreed and made the fix in E.

I can send you the relevant code that we specifically call.

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

> -----Original Message-----
> From: Jonas Linde [mailto:jo...@in...]
	...
> And jef...@aj... spoke unto the world. And said:
> > There used to be the same problem in E, which was fixed in 0.16
> > (I think between 0.15 and 0.16).  See the notes at:
> >    http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=3777&mode=full
>
> > The author of E knew what the change required was, so you may
> > want to ask him.  I suspect that a lot of shared code was used at
> > some point that introduced these bugs in the gnome wm clients.
> > In any case, there is a solution for them.
	...
> Sorry, but I don't get it. You report on a supposed bug without any
> consistent way of reproducing it. The "wish; raise .; raise ." sequence
> doesn't behave in any way strange. From the discussion at the Scriptics
> web site it seems the problem lies with some suspiciously simplistic
> algorithm in TkWmRestackToplevel. I doubt this has anything at all to do
> with sawfish.

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

[TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU Hogging...

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

There used to be the same problem in E, which was fixed in 0.16
(I think between 0.15 and 0.16).  See the notes at:
   http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=3777&mode=full

The author of E knew what the change required was, so you may
want to ask him.  I suspect that a lot of shared code was used at
some point that introduced these bugs in the gnome wm clients.
In any case, there is a solution for them.

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

> -----Original Message-----
> From: Laurent Duperval [mailto:lau...@ne...]
> Sent: Tuesday, August 22, 2000 11:49 AM
> To: sa...@aa...
> Cc: Tcl Core List
> Subject: [TCLCORE] Re: [Sawmill] Bug report: Fwd: Entry Widget and CPU
> Hogging...
> 
> 
> On 22 Aug, John Harper wrote:
> > Laurent Duperval writes:
> > |$ wish
> > |% raise .
> > |% raise .
> > |
> > |The first raise command should work fine. The second one takes a 
> few seconds
> > |to show up. In discussing the bug, there is an explanation of what is
> > |happening behind the scnes. Maybe someone here can take a look to see if
> > |this can be fixed in sawfish.
> > 
> > using the above code, I can't see any bug, can you be more specific
> > about how to reproduce the problem?
> > 
> 
> Hmmmm.... It's possible that it's a GNOME problem:
> 
> # WindowMaker
> % time {raise .}
> 11710 microseconds per iteration
> % time {raise .}
> 10322 microseconds per iteration
> % time {raise .}
> 10483 microseconds per iteration
> % time {raise .}
> 11137 microseconds per iteration
> % time {raise .}
> 10497 microseconds per iteration
> 
> # fvwm2
> % time {raise .}
> 2320 microseconds per iteration
> % time {raise .}
> 312 microseconds per iteration
> % time {raise .}
> 318 microseconds per iteration
> % time {raise .}
> 315 microseconds per iteration
> 
> # E
> % time {raise .}
> 6839 microseconds per iteration
> % time {raise .}
> 6707 microseconds per iteration
> % time {raise .}
> 6883 microseconds per iteration
> 
> #TWM Under GNOME
> % time {raise .}
> 2755 microseconds per iteration
> % time {raise .}
> 3904 microseconds per iteration
> % time {raise .}
> 2661 microseconds per iteration
> % time {raise .}
> 3822 microseconds per iteration
> 
> # ICE Under GNOME
> % time {raise .}
> 16696 microseconds per iteration
> % time {raise .}
> 2011383 microseconds per iteration
> % time {raise .}
> 2006532 microseconds per iteration
> 
> # sawfish under GNOME
> 
> % time {raise .}
> 12362 microseconds per iteration
> % time {raise .}
> 2010147 microseconds per iteration
> % time {raise .}
> 2008609 microseconds per iteration
> % time {raise .}
> 2011134 microseconds per iteration
> 
> E under GNOME shows the same type of behaviour as ICE: when the window is
> first raised, it takes no time. But if it is raised and you try to raise it
> again, it takes about 2 seconds.
> 
> I haven't been able to test sawfish without running GNOME and I haven't been
> able to test any window manager under KDE.
> 
> L

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