tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: VOTE: maintainers and patches

[John O. <ou...@aj...>]

I have modified the TCT FAQ to incorporate the information from the
recently-approved maintainer proposal:

http://dev.scriptics.com/community/coreteam/faq.html

This required a fair amount of reworking of the FAQ.  Hopefully I
haven't changed any of the basic ideas, but if you see anything that
doesn't look like what you remember approving, please let me know.

-John-
________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
http://www.ajubasolutions.com

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

[TCLCORE] Re: VOTE: maintainers and patches

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

Andreas Kupries wrote:
> >
> > If I have erroneously reported your vote, please respond ASAP.
> 
> I have DRH as Strict = Yes, Relaxed = Prefer in my notes [x].
> Attached the mail I base this upon. He posted to TCT, not tclcore.
> Just for completeness.
> 
>         ** This does not change the outcome of the vote. **
> 

This is correct.  I would have spoken up, but as you observe,
there is no change in the outcome.

Sorry about the list mixup...
-- 
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: VOTE: maintainers and patches

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

> The voting period for the maintainers and patches proposal is now over.
> Here are the results:
> 
> Strict proposal:
>      Prefer - 3 (Nijtmans, Ousterhout, Hobbs)
>      Yes -    9 (Kupries, Welch, Ingham, McLennan, Porter, DeJong,
>                  Harrison, Fellow, Howlett)
>      No -     0
> 
> Relaxed proposal:
>      Prefer - 1 (Kupries)
>      Yes -    4 (Ousterhout, Nijtmans, Fellows, Hobbs)
>      No -     7 (Ingham, McLennan, Porter, DeJong, Harrison, Howlett, Welch)
> 
> If I have erroneously reported your vote, please respond ASAP.

I have DRH as Strict = Yes, Relaxed = Prefer in my notes [x].
Attached the mail I base this upon. He posted to TCT, not tclcore.
Just for completeness.

	** This does not change the outcome of the vote. **

[cc'd to Richard for verification]

> Otherwise the strict proposal is the clear winner and the relaxed
> proposal is rejected.  I will start integrating the strict proposal
> into the FAQ.

[x]

VOTE	Maintainers & Patches		{John Ousterhout}
			Strict	Relax	(Reasons for -, short)
---------------------------------------------------------------------------
Michael McLennan	+	-	(Maintainers out of loop for Relaxed)
Jeffrey Hobbs		++	+
Donal Fellows		+	+
Mark Harrison		+	-	(Refers to Jim & Don)
Brent Welch		+	-
George A. Howlett	+	-
Mo DeJong		+	-	(Experience from past projects)
John Ousterhout		++	+
Jim Ingham		+	-	(Not enough discussion pro/contra Relaxed)
D. Richard Hipp		+	++
Jan Nijtmans		++	+
Andreas Kupries		+	++
Don Porter		+	-	(Relaxed possible per CVS branches in individual cases)
Karl Lehenbauer		/	/
---------------------------------------------------------------------------
			++3+10/1 ++2+4-7/1
			Strict is accepted.


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

[TCLCORE] Re: VOTE: maintainers and patches

[John O. <ou...@aj...>]

Oops, my mistake.  Somehow I missed Richard's message, which I
see now in my mailbox.  Sorry about that...

-John-

At 09:55 PM 10/5/2000 +0200, Andreas Kupries wrote:

> > The voting period for the maintainers and patches proposal is now over.
> > Here are the results:
> > 
> > Strict proposal:
> >      Prefer - 3 (Nijtmans, Ousterhout, Hobbs)
> >      Yes -    9 (Kupries, Welch, Ingham, McLennan, Porter, DeJong,
> >                  Harrison, Fellow, Howlett)
> >      No -     0
> > 
> > Relaxed proposal:
> >      Prefer - 1 (Kupries)
> >      Yes -    4 (Ousterhout, Nijtmans, Fellows, Hobbs)
> >      No -     7 (Ingham, McLennan, Porter, DeJong, Harrison, Howlett, Welch)
> > 
> > If I have erroneously reported your vote, please respond ASAP.
>
>I have DRH as Strict = Yes, Relaxed = Prefer in my notes [x].
>Attached the mail I base this upon. He posted to TCT, not tclcore.
>Just for completeness.
>
>         ** This does not change the outcome of the vote. **
>
>[cc'd to Richard for verification]
>
> > Otherwise the strict proposal is the clear winner and the relaxed
> > proposal is rejected.  I will start integrating the strict proposal
> > into the FAQ.
>
>[x]
>
>VOTE    Maintainers & Patches           {John Ousterhout}
>                         Strict  Relax   (Reasons for -, short)
>---------------------------------------------------------------------------
>Michael McLennan        +       -       (Maintainers out of loop for Relaxed)
>Jeffrey Hobbs           ++      +
>Donal Fellows           +       +
>Mark Harrison           +       -       (Refers to Jim & Don)
>Brent Welch             +       -
>George A. Howlett       +       -
>Mo DeJong               +       -       (Experience from past projects)
>John Ousterhout         ++      +
>Jim Ingham              +       -       (Not enough discussion pro/contra Relaxed)
>D. Richard Hipp         +       ++
>Jan Nijtmans            ++      +
>Andreas Kupries         +       ++
>Don Porter              +       -       (Relaxed possible per CVS branches in individual cases)
>Karl Lehenbauer         /       /
>---------------------------------------------------------------------------
>                         ++3+10/1 ++2+4-7/1
>                         Strict is accepted.
>
>
>-- 
>So long,
>         Andreas Kupries <a.k...@we...>
>                         <http://www.purl.org/NET/akupries/>
>-------------------------------------------------------------------------------
>
>MIME-Version: 1.0
>Return-Path: bluepeak.westend.com!popeye
>Return-Path: <po...@bl...>
>Received: from popeye.bluepeak.westend.com by bluepeak  with smtp
>         (Smail3.2 #1) id m13g9AT-00027DC; Mon, 2 Oct 2000 19:14:21 +0200 (MEST)
>Received: from genesis for a.kupries
>  with Cubic Circle's cucipop (v1.10 1996/09/06) Mon Oct  2 19:09:43 2000
>Received: from pop.ajubasolutions.com (earth.ajubasolutions.com [206.14.70.4])
>         by genesis.westend.com (8.8.6/8.8.6) with ESMTP id SAA16695
>         for <a.k...@we...>; Mon, 2 Oct 2000 18:48:21 +0200 (MET DST)
>Received: (from list@localhost)
>         by pop.ajubasolutions.com (Pro-8.9.3/8.9.3) id JAA09991;
>         Mon, 2 Oct 2000 09:49:09 -0700 (PDT)
>X-From_: tct...@aj...  Mon Oct  2 18:48:23 2000
>Resent-Date: Mon, 2 Oct 2000 09:49:08 -0700 (PDT)
>Sender: dr...@aj...
>Message-ID: <39D...@hw...>
>Date: Mon, 02 Oct 2000 12:46:43 -0400
>From: "D. Richard Hipp" <dr...@hw...>
>Organization: Hwaci
>X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15 i686)
>X-Accept-Language: en
>To: tc...@aj...
>References: <4.2...@ma...>
>Resent-Message-ID: <"n2naXD.A.3bC.EyL25"@pop>
>Resent-From: tc...@aj...
>X-Mailing-List: <tc...@aj...> archive/latest/189
>X-Loop: tc...@aj...
>Precedence: list
>Resent-Sender: tct...@aj...
>Subject: [TCT] VOTE: maintainers and patches
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain;
>               charset="us-ascii"

________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
http://www.ajubasolutions.com

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

Re: [TCLCORE] Re: VOTE: maintainers and patches

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

> The voting period for the maintainers and patches proposal is now over.
> Here are the results:
> 
> Strict proposal:
>      Prefer - 3 (Nijtmans, Ousterhout, Hobbs)
>      Yes -    9 (Kupries, Welch, Ingham, McLennan, Porter, DeJong,
>                  Harrison, Fellow, Howlett)
>      No -     0
> 
> Relaxed proposal:
>      Prefer - 1 (Kupries)
>      Yes -    4 (Ousterhout, Nijtmans, Fellows, Hobbs)
>      No -     7 (Ingham, McLennan, Porter, DeJong, Harrison, Howlett, Welch)
> 
> If I have erroneously reported your vote, please respond ASAP.

I have DRH as Strict = Yes, Relaxed = Prefer in my notes [x].
Attached the mail I base this upon. He posted to TCT, not tclcore.
Just for completeness.

	** This does not change the outcome of the vote. **

[cc'd to Richard for verification]

> Otherwise the strict proposal is the clear winner and the relaxed
> proposal is rejected.  I will start integrating the strict proposal
> into the FAQ.

[x]

VOTE	Maintainers & Patches		{John Ousterhout}
			Strict	Relax	(Reasons for -, short)
---------------------------------------------------------------------------
Michael McLennan	+	-	(Maintainers out of loop for Relaxed)
Jeffrey Hobbs		++	+
Donal Fellows		+	+
Mark Harrison		+	-	(Refers to Jim & Don)
Brent Welch		+	-
George A. Howlett	+	-
Mo DeJong		+	-	(Experience from past projects)
John Ousterhout		++	+
Jim Ingham		+	-	(Not enough discussion pro/contra Relaxed)
D. Richard Hipp		+	++
Jan Nijtmans		++	+
Andreas Kupries		+	++
Don Porter		+	-	(Relaxed possible per CVS branches in individual cases)
Karl Lehenbauer		/	/
---------------------------------------------------------------------------
			++3+10/1 ++2+4-7/1
			Strict is accepted.


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

[TCLCORE] TclDOM bug report

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

Sorry for posting this to an inappropriate list,
but I can't figure out where to send it; the Ajuba
bug report form doesn't have an entry for the TclDOM
package, and I'm not sure who to contact.

In the Tcl-DOM package (C version) dom::{document|element}
getElementsByTagName is documented as returning a list,
but as implemented returns a list variable.  (Steve Ball's
original implementation returns a list).

Further, according to the comments in the code, the
list variable is intended to be "live" in that it
is automagically updated whenever the tree changes.
This does not in fact happen -- instead the variable
is only updated if 'getElementsByTagName' is called
a second time with the same arguments.

Proposed fix: change the code to match the documentation
and Steve's pure-Tcl DOM implementation.  This will not match
the W3C DOM spec, but GetElementsByTagName and the other "live list"
APIs are deprecated in DOM level 2 anyway in favor of
the Traversal interface.

I can provide a patch, but who should I send it to?
I could also go ahead and commit the changes, but fear
running afoul of the new TCT policies :-)  I don't know
who has administrative jurisdiction over this module...

Thanks,


--Joe English

  jen...@fl...

[ Cc: ste...@zv... ]

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

[TCLCORE] unsigned integers in TCL

[Ernesto B. <eb...@pe...>]

Hi!

I would be able to work with unsigned integers (IP adresses) on TCL,
using the expr or other functions on it. Currently this doesn't work, 
if my integer is larger than an signed integer, it gets negative:

  ernst@milka:/u/ernst > tclsh8.2
  % expr 3585808128 + 1
  -709159167

Will this be enhanced in TCL 8.4?  Would be great! :)

I now have to use the float to make calculations, and then split on 
the "." and lindex 0, because:

  % expr 3585808128.0 + 1
  3585808129.0
  % expr round(3585808129.0)
  integer value too large to represent

So I have to do this ugly hack:

  % expr 3585808128.0 + 1
  3585808129.0
  % lindex [split 3585808129.0 "."] 0
  3585808129


(Maybe there is another (better) way?).

--

PEM InterComputing GmbH
Ein Unternehmen der ISION Internet AG
Ernesto Baschny (EB2351-RIPE)
Programmierer
Vaihingerstraße 55
D-70567 Stuttgart

Phone: +49 711 1618-380
Fax:   +49 711 1618-333

eMail: eb...@pe...
Web: www.pemic.de

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

[TCLCORE] Re: unsigned integers in TCL

[Donal K. F. <fel...@cs...>]

Ernesto Baschny <eb...@pe...>
> I would be able to work with unsigned integers (IP adresses) on TCL,
> using the expr or other functions on it. Currently this doesn't work, 
> if my integer is larger than an signed integer, it gets negative:
> 
>   ernst@milka:/u/ernst > tclsh8.2
>   % expr 3585808128 + 1
>   -709159167
> 
> Will this be enhanced in TCL 8.4?  Would be great! :)
> 
> I now have to use the float to make calculations, and then split on 
> the "." and lindex 0, because:
[...]
> (Maybe there is another (better) way?).

This is not really the right place to raise such questions.  The one
question that is fairly appropriate (will this behaviour be changed in
8.4) is answered with "probably not" since it would break software
expecting the current signed behaviour.  It does depend on whether
someone comes forward with a reasonable suggestion for what the
behaviour should be (and this list is a good place to suggest it) and
volunteers to implement it.  (Hey!  We're busy people too...)

I'll continue the discussion in private email.

Donal.
-- 
Donal K. Fellows, Department of Computer Science, University of Manchester, UK.
(work) fel...@cs...     Tel: +44-161-275-6137  (preferred email addr.)
(home) do...@ug...  Tel: +44-1274-401017   Mobile: +44-7957-298955
http://www.cs.man.ac.uk/~fellowsd/  (Don't quote my .sig; I've seen it before!)

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

[TCLCORE] Re: VOTE: maintainers and patches

[John O. <ou...@aj...>]

The voting period for the maintainers and patches proposal is now over.
Here are the results:

Strict proposal:
     Prefer - 3 (Nijtmans, Ousterhout, Hobbs)
     Yes -    9 (Kupries, Welch, Ingham, McLennan, Porter, DeJong,
                 Harrison, Fellow, Howlett)
     No -     0

Relaxed proposal:
     Prefer - 1 (Kupries)
     Yes -    4 (Ousterhout, Nijtmans, Fellows, Hobbs)
     No -     7 (Ingham, McLennan, Porter, DeJong, Harrison, Howlett, Welch)

If I have erroneously reported your vote, please respond ASAP.
Otherwise the strict proposal is the clear winner and the relaxed
proposal is rejected.  I will start integrating the strict proposal
into the FAQ.

-John-
________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
http://www.ajubasolutions.com

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

[TCLCORE] Re: VOTE: maintainers and patches

[Mark H. <ma...@us...>]

Strict: Yes
Relaxed: No

Following the reasoning of Jim and Don, I think it will be more easy
to evolve the stricter process rather than the relaxed process.

Mark.

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

[TCLCORE] Re: VOTE: maintainers and patches

[Donal K. F. <fel...@cs...>]

John Ousterhout <ou...@aj...>
>      http://dev.scriptics.com/community/coreteam/maintainer.html 
>      http://dev.scriptics.com/community/coreteam/maintainer2.html

Strict: Yes
Relaxed: Yes

I'm really not too bothered at the moment which one we choose,
particularly since I believe that what we will actually do is look at
this again at some point in the future and then codify what existing
practises actually are.  We don't need to be perfect; good will do.

Donal.
-- 
Donal K. Fellows, Department of Computer Science, University of Manchester, UK.
(work) fel...@cs...     Tel: +44-161-275-6137  (preferred email addr.)
(home) do...@ug...  Tel: +44-1274-401017   Mobile: +44-7957-298955
http://www.cs.man.ac.uk/~fellowsd/  (Don't quote my .sig; I've seen it before!)

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

[TCLCORE] What happened to http://tcl.sourceforge.net/ ?

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

I was surprised to notice that Mark changed the homepage for
http://tcl.sourceforge.net/.  Did I miss some decision to change that
page?  I see that he just brought up the vote about other SourceForge
proposals, but I don't remeber anything about changing the homepage.

The page I put up was a temporary one that should eventually have been
replaced, but I would have expected a TCT discussion to precede any change.
I think this brings up more interesting questions on how we really expect
to use SourceForge, which should precede or coincide with any proposals,
and should definitely precede changes to the homepage.  If there is anyone
else on TCT interested in discussing what should be on the SourceForge Web
page, let me know so we can form a working group to figure out the right
final solution.  The previous facade was created based on the principle
that anyone coming to the Tcl project at SourceForge should be directed to
the current Tcl Dev Xchange resource site, especial during this interim
period when we lack a working infrastructure.  I see that the facade still
exists here:
	http://tcl.sourceforge.net/ajuba.html

Renaming it to 'ajuba' is a little misleading because I took care to scrub
all references to Ajuba News and Ajuba products from that page.

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: VOTE: maintainers and patches

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

>      http://dev.scriptics.com/community/coreteam/maintainer.html 
>      http://dev.scriptics.com/community/coreteam/maintainer2.html
> 
> Please respond to the group with your votes in the following form:
 
Strict: Prefer
Relaxed: Yes

I prefer the Strict version because if we expect Maintainers to have
responsibility beyond patches (caring for bugs and the like), then
it would be somewhat unfair to expect that when anyone with write
access can touch their code.  However, applying the "reasonable
person principle" should allow us to work in Relaxed mode as well.

Jeff

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

[TCLCORE] Re: VOTE: maintainers and patches

[George H. <ga...@bl...>]

Your message dated: Mon, 02 Oct 2000 09:14:09 PDT
> It's time to vote on the maintainers/patches proposal that we have
> been discussing for the last week.  ...

Strict: Yes
Relaxed: No

--gah

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

[TCLCORE] Re: VOTE: maintainers and patches

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

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


[Same as Jim. I.e. posted this to tct before.]

Strict: Yes
Relaxed: Prefer

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



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBOdpa75/nJG9pmFelAQEkkwP9H0MqKJ5y8YvUuYZe/umvYkClr764+gHo
cW8frC3QHD5yDFmmv+uoSK0heogFshaLpYK6EdJRI0achFEfBb0ZwVjxi2eXE2l3
Eg2kEnwCXeQ+xLmoCgIKErM0o7GHXdS2ZHbrEG4ZQb1P1FTRr85NHFYOkCLmJG6M
8BP+S5So5FU=
=ly1H
-----END PGP SIGNATURE-----

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

[TCLCORE] Re: VOTE: maintainers and patches

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

Strict: Prefer
Relaxed: Yes

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

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

[TCLCORE] Re: C9X, strtod(), hex floating literals

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

lv...@ca... wrote:
> 
> According to Don Porter <dg...@ca...>:
> 
> :strtod() is buggy.  I recommend that Tcl's configure script also test
> :for the presence of a C9X strtod(), and replace it with the compat/strtod.c
> :version as well.
> 
> It sure is a shame to put yet another road block in the way of international
> standards by replacing standard C behavior with a subset of that behavior.
> 
> Wouldn't we rather see the compat/strtod.c upgraded to take the new format,
> instead of telling people though they can use such numbers with perl, python,
> etc. they are not permitted to use them with tcl?

Actually, Tcl behaves right now the same as Perl, and perhaps the same
as Python (don't have it on all systems to check).

Linux 6.x Perl 5.005_03 gives:

zamora [~] 7 % perl -e '$a = "0x1.8p0"; $a++; print "$a\n";'
2.5

Solaris 5.7 Perl 5.005_03 gives:

jupiter [~] 333 % perl -e '$a = "0x1.8p0"; $a++; print "$a\n";'
1

And it's even worse depending on how you operate on $a for perl due
to the way it more leniently tries to interpret data sometimes.

I do think we should strive for consistency, either by preventing
this ISO (not POSIX) extension from being recognized in Tcl, or by
accepting it everywhere.

We may want to lean toward extending it though, as we also have had
numerous requests to support formats like 0d09 (dec) 0b011101 (bin),
as some other languages support.

-- 
   Jeffrey Hobbs                     The Tcl Guy
   hobbs at ajubasolutions.com       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: VOTE: maintainers and patches

[Donald G P. <dg...@ca...>]

Strict: Yes
Relaxed: No

With CVS branches we can layer "Relaxed" style development areas on
top of the "Strict" official branches.  It would be very difficult to
carve out a "Strict" environment out of the "Relaxed" style.  Eventually
Strict control is necessary to actually make a release.

Maintainers are burdened with the responsibility of delivering their
sections of code ready for release.  They need the corresponding
authority to be able to make that happen.

The Strict proposal also maximizes pre-commit review and minimizes
post-commit second-guessing, so that users tracking the CVS HEAD can
be more confident they are tracking features which will appear in a
future release, not just some trials and errors.

Strict isn't perfect, but it can evolve into workable procedures.

DGP

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

Re: [TCLCORE] VOTE: maintainers and patches

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

--------

[Same as Jim. I.e. posted this to tct before.]

Strict: Yes
Relaxed: Prefer

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

[TCLCORE] Re: Proposal: maintainers and patches mailing list

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

After reading over the discussion and looking at my own
personal interaction with successful open source projects,
I am going to have to vote yes on the strict proposal and
no on the non-strict one.

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: VOTE: maintainers and patches

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

John,

Oops, I voted on the wrong mailing list...  I am not trying to get double-counted, but just to get all these votes in the same place...

Strict: Yes
Relaxed: No

I am not sure that we have really discussed a lot of the complications that will be involved in the Relaxed proposal.  There are many practical details that it leaves unaddressed.  When it is chosen, IMHO, will be the time to figure out how to actually make it work, I can't say anything in a few short words to that end...

Jim 

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

[TCLCORE] Re: VOTE: maintainers and patches

[John O. <ou...@aj...>]

At 09:14 AM 10/2/2000 -0700, John Ousterhout wrote:
>It's time to vote on the maintainers/patches proposal that we have
>been discussing for the last week...

In my message announcing the vote I forgot to specify when the polls
close.  Votes must be sent by the end of the day tomorrow (Wednesday),
October 4, in order to be counted.

So far only a few of you have voted; the rest of you, get to it!

-John-
________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
http://www.ajubasolutions.com

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

[TCLCORE] Re: VOTE: maintainers and patches

[Michael J M. <mm...@ca...>]

Your message dated: Mon, 02 Oct 2000 09:14:09 PDT
> It's time to vote on the maintainers/patches proposal that we have
> been discussing for the last week.  ...

Strict: Yes
Relaxed: No

The "Relaxed" proposal cuts maintainers out of the loop, encouraging
them to be lazy or to drop out entirely.  If we're going to have
maintainers, they must have authority and responsibility.

--Michael
. . . . . . . . . . . . . . . . .                  ---_-----------
                                . . . . . . . . . | c a d e n c e |
      Michael McLennan          .                  ---------------
      mm...@ca...           .      Cadence Design Systems, Inc.
      phone: 610-398-6348       .      7535 Windsor Dr. Suite A-200
        fax: 610-530-7985       .      Allentown, PA  18195

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

[TCLCORE] Re: C9X, strtod(), hex floating literals

[Don P. <dg...@ca...>]

According to Don Porter <dg...@ca...>:
>: I recommend that Tcl's configure script also test
>: for the presence of a C9X strtod(), and replace it with the
>: compat/strtod.c version as well.

<lv...@ca...> wrote:
> It sure is a shame to put yet another road block in the way of international
> standards by replacing standard C behavior with a subset of that behavior.

I'm afraid I don't see the force of your argument.  Certainly the
developers of C libraries should implement C libraries that conform
to the international standards for C libraries.  What does that 
(necessarily) have to do with what interface current and future
releases of Tcl should support?

> Wouldn't we rather see the compat/strtod.c upgraded to take the new format,
> instead of telling people though they can use such numbers with perl, python,
> etc. they are not permitted to use them with tcl?

That's certainly another way we can go.  What's not acceptable is the
status quo where [string is double] and [expr] disagree about what is
a valid floating point number, and where an [lsort] can change the
result of a comparison:

	% set a 1.5
	1.5
	% set b 0x1.8p0
	0x1.8p0
	% expr {$a == $b}
	0
	% lsort -real [list $a $b]
	1.5 0x1.8p0
	% expr {$a == $b}
	1
	% expr {$a + 0}
	1.5
	% expr {$b + 0}
	can't use non-numeric string as operand of "+"
	% string is double $a
	1
	% string is double $b
	1

Besides, if we decide that Tcl should recognize hexadecimal floating
constants, that should be a conscious, explicit, and documented
decision about the Tcl interface, and it should be implemented
cross-platform.  It should not be an accidental consequence of what
C library Tcl happened to be compiled with.

Also, unlike C libraries, Tcl libraries have version numbers which
are accessible to their callers, and conventions about what version
numbers can include incompatible changes.  If we decide that Tcl
should support hexadecimal floating constants, that support ought
to take effect with a new major release of Tcl.

Currently [expr] documents its recognition of floating-point
values:

       ...Floating-point numbers
       may be specified in any of the ways accepted by  an  ANSI-
       compliant  C compiler (except that the f, F, l, and L suf­
       fixes will not be permitted in most  installations).   For
       example,  all  of  the  following are valid floating-point
       numbers:  2.1, 3., 6e4, 7.91e+16. ...

Note "ANSI-compliant", not "ISO C9X-compliant".  That is in fact 
what [expr] does.  [lsort -real], [string is double], etc. are
inconsistent with that.  I think that's a bug.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

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

[TCLCORE] Re: RFC: Tk extension to listbox

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

	...
> In this case, I favor George's, not because of any 
> inherent problems with TkTable, but because George's links in with 
> his Tree widget, and a nice Tree-driven table widget is something 
> that Tk really needs...

For a multi-column listbox, I favor neither (although the BLT
hiertable is closer functionally), for one simple reason: they lack
the necessary correct LaF on any platform.  For Windows you can see
why they are off (although tktable has such a plethora of options
to support it, getting the look and feel shouldn't be so tedious).
You can argue that anything is correct on Unix, but we're seeing an
outpouring of community opinion that Gtk is the right LaF to follow.
It's hard to disagree with this, considering all the major companies
that want to standardize on it as the next common unix desktop
toolkit (dropping Motif finally).  I plead ignorance on the Mac.

It's been great to have the extensive collection of widgets available,
but when we consider putting it in the core (and having something
like the mclistbox is without a doubt important to most Tk users),
we have to make sure it comes out of the box like they "expect" it.

George's hiertable is probably a good place to start.  Then you want
to look at the native widgets and see how close we are to *exactly*
duplicating them, and what the code looks like to get there.  Trust
me, people will complain when the tree dotted line spacing is just
one or two pixels off from that in Explorer, or the image/text spacing
is too much.  Look at the discussions about buttons right now on the
newsgroup (a default Tk button on Windows is not exactly the same size
as native).

A tree and table would also be good widgets to have (note that tree
is on the 8.4 list), but we needn't make the tree and mclistbox the
same widget if it compromises ease of use or LaF.  However, if it
doesn't, that's a win for developer and user.

Jeff

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