tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] End of Votes

[Jan N. <jan...@gm...>]

2008/12/11 Jeff Hobbs <je...@ac...>:
> And I'm annoyed again after finding another uselessly cased package.
> What moron named a package TclOO?  Ugh?!  Something will need to be done
> about this, and it will be done in ActiveTcl if not the core.

Something can be done about it: I think it would be good that the TCT
starts recommending all lower-case package names. That means that
TclOO should become tcloo (or maybe simply just "oo"), Tcl
should become tcl and Tk should become tk. Providing
compatibility is easy. (For TclOO it is not really an issue,
but because it is available as a separate package
as well, I would do it anyway.)

How about a mini-TIP, which simply proposes to recommend (but not
require) all-lowercase package names. Then the core should do the
same, just do "package provide"  twice, once with the original name,
once with the all-lowercase name. It's zero risk, and still allows
us to come with a better solution in Tcl 8.7.

Here is a patch doing this for Tk (unix and win). I think it
requires a mini-TIP, but I would be in favour of that.

Regards,
        Jan Nijtmans

Re: [TCLCORE] End of Votes

[Jeff H. <je...@ac...>]

On 12/10/08 5:18 AM, Donal K. Fellows wrote:
> #339: Case-Insensitive Package Names
>    Rejected 2/4/0
>    For: AK, JH
>    Against: JE, JN, KBK, DGP
>    Present: none
>    RejectionReason: Breakage for existing code too great.

And I'm annoyed again after finding another uselessly cased package. 
What moron named a package TclOO?  Ugh?!  Something will need to be done 
about this, and it will be done in ActiveTcl if not the core.

Jeff

Re: [TCLCORE] Tk_MainEx: extreme archeology

[Alexandre F. <ale...@gm...>]

On Wed, Dec 10, 2008 at 6:08 PM, Donald G Porter <dg...@ni...> wrote:
>
> Is there anyone who can advise me on the intended purpose of the
> routine Tk_MainEx() ?  In particular, why it is in the public stubs
> table?  What callers are expected to call it through the table?
> Do such callers exist?
>
> The routine was added in Revision 1.3 of tkMain.c with log message:
>
> revision 1.3
> date: 1999/03/10 07:04:42;  author: stanton;  state: Exp;  lines: +34 -4
> integrated stubs into 8.0 main branch
>
> Some understanding of this may be relevant to my getting thread
> safety issues right in the TIP 338 implementation.


Looking at the comment in the 'changes' file:

 3/10/99 (new feature) Tk now uses the new stub library feature in Tcl.
 The Tk library now contains no direct references to any symbols in
 Tcl.  In addition, there is a new Tk_MainEx() function that takes an
 interpreter as an argument.  See the Tcl documentation for more
 information about the stubs mechanism. (redman)

it looks like there was no intention of special handling; Tk_MainEx
got stubbed just like dozens of others.
Now since it is stubbed, it becomes a macro via tkDecls.h. So any
caller (like a wish-like app) including the proper headers must be
calling it through the stub mechanism. Even those just calling Tk_Main
which is itself a macro calling Tk_MainEx.

I feel like I'm stating the obvious. What am I missing in your question ?

-Alex

[TCLCORE] Tk_MainEx: extreme archeology

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

Is there anyone who can advise me on the intended purpose of the
routine Tk_MainEx() ?  In particular, why it is in the public stubs
table?  What callers are expected to call it through the table?
Do such callers exist?

The routine was added in Revision 1.3 of tkMain.c with log message:

revision 1.3
date: 1999/03/10 07:04:42;  author: stanton;  state: Exp;  lines: +34 -4
integrated stubs into 8.0 main branch

Some understanding of this may be relevant to my getting thread
safety issues right in the TIP 338 implementation.

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

[TCLCORE] End of Votes

[Donal K. F. <don...@ma...>]

The following TIP CFVs have now closed:

#329: Try/Catch/Finally syntax
  Accepted 3/0/1
  For: DKF, JE, JN
  Against: none
  Present: KBK

#339: Case-Insensitive Package Names
  Rejected 2/4/0
  For: AK, JH
  Against: JE, JN, KBK, DGP
  Present: none
  RejectionReason: Breakage for existing code too great.

#343: A Binary Specifier for [format/scan]
  Accepted 4/1/0
  For: DKF, AK, JN, KBK
  Against: DGP
  Present: none
  Notes: Must only proceed with %b specifier, and not changes to other
         parts of [format] and [scan].

Thanks to everyone who voted. (I'm sorry I didn't vote on #339, but it
would have been a PRESENT...)

Dona.

Re: [TCLCORE] TIP#339: Case-Insensitive Package Names

[Andreas K. <and...@ac...>]

> dg...@us... wrote:
> > For the C API?  Just leave it alone.  Require C
> > programmers to get their package name arguments right.
>
> Ok, it was late.
>
> A good portion of the existing use of the [package] mechanism is done
> exclusively through the C API, so my proposal to attack this (almost)
> entirely at the level of ensemble redirections cannot work.

Actually, at second thought I believe you are selling us short here. The
introspection we have through 'package {names,versions,ifneeded}' means that
we can get all the information about the packages registered through the
C-level in our redirected ensemble/wrapper. Just later, instead of through
direct interception.

So, I believe that your initial idea of using a wrapper can be salvaged. It
does, of course, complexify the wrapper, to have to query the original
command/database to be sure that we know everything. Even if we are not
(willing to) doing that we can use such a wrapper to at least experiment
with various possibilities using tcl-only packages. But if we are willing to
do that the whole experiment can be made a package as well. Allowing many
more to play with it.

In hindsight I should have thought about command wrapping. I did not, went
straight to C-level implementation of the TIP.


> If
> the [package] mechanism is to switch between case-sensitive and
> case-insensitive modes, that ability to switch has to be built into
> the Tcl_Pkg*() routines themselves.  I'm sure Andreas figured that
> out long ago.



> Assuming such a mode switching ability, a remaining question is how
> mode selection is controlled.  I see two big options.  The first is
> to have each caller choose the mode, and extend the interfaces where
> needed to give the callers this ability (what TIP 339 proposes).

> The other option is what I hinted at in my previous message.  Let the
> name matching mode be a per-interp property of the [package] system
> with another subcommand/C routine to set and query the mode setting
> (following the [package prefer] model).

Or, if that is relevant only at the Tcl level, using an extended wrapper as
I describe above to implement the switching, be it per-command or -interp.
I.e, as you said yesterday late

	| For the C API?  Just leave it alone.  Require C
	| programmers to get their package name arguments right.
	| We make them tend to ugly details like encodings.  They
	| can handle case.

Actually, loading the wrapper, a plain 'package require
package::match::nocase' could be the switch. Then you automatically get your
prefered default of 'case-sensitive', as that is the regular behaviour.

> The other question in designing a multi-mode name matcher is to choose
> what the default mode should be.  Either the default could be case
> sensitive to keep closer compat with previous releases, or the default
> could be switched to case-insensitive and force those needing compat
> to explicitly ask for it.

Agreed.

> So that leads to 6 options:
>
> 1) Change nothing.  All matching remains case sensitive.
> 2) Add caller-controlled mode.  Default case insensitive. (TIP 339)
> 3) Add caller-controlled mode.  Default case sensitive.
> 4) Add global mode setting.  Default case insensitive.
> 5) Add global mode setting.  Default case sensitive.
> 6) No mode selection.  Change everything to case insensitive matching.

> My current preference order among these design options is:
>
> 5) Add global mode setting.  Default case sensitive.
> 4) Add global mode setting.  Default case insensitive.
> 6) No mode selection.  Change everything to case insensitive matching.
> 1) Change nothing.  All matching remains case sensitive.
> 3) Add caller-controlled mode.  Default case sensitive.
> 2) Add caller-controlled mode.  Default case insensitive. (TIP 339)
>
> Yes, TIP 339 is actually my least favorite.  More to the point, I
> like it less than the "do nothing" option, so my vote...
>
> TIP 339: NO
>
> It's possible I'm overlooking something and my preferences could
> change in the light of some use cases or migration plans I don't
> currently appreciate, but that's my take on things as I understand
> the proposal and its rationale.

Ok, time to think about this some more, in light of your and the other
comments and ideas.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP#329: Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> A niggly detail on this one.  The TIP
> describes [throw] as the same as [error]
> but with the argument order revised.
>
> However, the reference implementation
> doesn't quite match that description.
>   
Confirmed - this is an error in the implementation.
> interp alias {} throw {} return -level 0 -code error -errorcode
>   
Seems like the right thing to me.  Thanks - I'll update the implementation.

Regards,
Twylite

Re: [TCLCORE] TIP#329: Try/Catch/Finally syntax

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

dg...@us... wrote:
> ...In fact, I think
> it may be necessary to make that correction
> for simple test cases of [try {throw...}] to
> work as expected.  

Confirmed:

% try {throw FOO bar} trap FOO {puts zing!}
bar
% try {return -level 0 -code error -errorcode FOO bar} trap FOO {puts zing!}
zing!

Assuming the actual committed implementation will correct that
problem...

TIP 329: YES

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

Re: [TCLCORE] TIP#329: Try/Catch/Finally syntax

[<dg...@us...>]

A niggly detail on this one.  The TIP
describes [throw] as the same as [error]
but with the argument order revised.

However, the reference implementation
doesn't quite match that description.

In particular, the [error] command
always produces the TCL_ERROR return
code.  The implemented [throw] always
produces the TCL_RETURN return code.

I think I'd prefer what the TIP proposes
over what's implemented.  In fact, I think
it may be necessary to make that correction
for simple test cases of [try {throw...}] to
work as expected.  A simple way to
do that (without full syntax checking) is

interp alias {} throw {} return -level 0 -code error -errorcode

DGP

[TCLCORE] Update2: Status of votes in progress ...

[Andreas K. <and...@ac...>]

Update using the latest votes.
  
329 try/catch   10      +dkf +jenglish +jnijtmans /kbk
339 pkg names   10      +ak +tclguy -jenglish -jnijtmans -kbk -dgp
343 %b format   10      +dkf +ak +jnijtmans -dgp +kbk
322 nre api     12	+msofer +kbk +jenglish +jnijtmans

Voting ended for

324 tk_font     accepted	+dkf	/ak +jnijtmans +kbk
332 1/2 close   accepted	+dkf +ak +jnijtmans /kbk
341 dict filter accepted	+dkf +ak +jnijtmans +kbk
 
--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

[TCLCORE] TIP #339: Case-Insensitive Package Names

[Kevin K. <ke...@re...>]

A colleague has pointed out to me that packages named with only
case distinctions are actually common "in the wild," owing to
programmers who, for example, export the public API of a module
as a package named in one case, and the private API as a package
named in another.

Given this incompatibility, I wish to change my recorded vote:

TIP #339: NO. This is to be understood as a vote of "Not Yet" -
I still think that the interaction of Tcl Modules with case-
insensitive filesystems is awkward, and the case-sensitive
naming is a burden on the memory. But the actual, rather than
potential incompatibilities make a NO vote prudent at this time.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP#339: Case-Insensitive Package Names

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

dg...@us... wrote:
> For the C API?  Just leave it alone.  Require C
> programmers to get their package name arguments right.

Ok, it was late.

A good portion of the existing use of the [package] mechanism is done
exclusively through the C API, so my proposal to attack this (almost)
entirely at the level of ensemble redirections cannot work.  If
the [package] mechanism is to switch between case-sensitive and
case-insensitive modes, that ability to switch has to be built into
the Tcl_Pkg*() routines themselves.  I'm sure Andreas figured that
out long ago.

Assuming such a mode switching ability, a remaining question is how
mode selection is controlled.  I see two big options.  The first is
to have each caller choose the mode, and extend the interfaces where
needed to give the callers this ability (what TIP 339 proposes).

The other option is what I hinted at in my previous message.  Let the
name matching mode be a per-interp property of the [package] system
with another subcommand/C routine to set and query the mode setting
(following the [package prefer] model).

The other question in designing a multi-mode name matcher is to choose
what the default mode should be.  Either the default could be case
sensitive to keep closer compat with previous releases, or the default
could be switched to case-insensitive and force those needing compat
to explicitly ask for it.

So that leads to 6 options:

1) Change nothing.  All matching remains case sensitive.
2) Add caller-controlled mode.  Default case insensitive. (TIP 339)
3) Add caller-controlled mode.  Default case sensitive.
4) Add global mode setting.  Default case insensitive.
5) Add global mode setting.  Default case sensitive.
6) No mode selection.  Change everything to case insensitive matching.

My current preference order among these design options is:

5) Add global mode setting.  Default case sensitive.
4) Add global mode setting.  Default case insensitive.
6) No mode selection.  Change everything to case insensitive matching.
1) Change nothing.  All matching remains case sensitive.
3) Add caller-controlled mode.  Default case sensitive.
2) Add caller-controlled mode.  Default case insensitive. (TIP 339)

Yes, TIP 339 is actually my least favorite.  More to the point, I
like it less than the "do nothing" option, so my vote...

TIP 339: NO

It's possible I'm overlooking something and my preferences could
change in the light of some use cases or migration plans I don't
currently appreciate, but that's my take on things as I understand
the proposal and its rationale.

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

[TCLCORE] More accepted

[Donal K. F. <don...@ma...>]

The following TIPs are now accepted:

TIP#324: 3/0/1
   For: DKF, JN, KBK
   Against: none
   Present: AK
TIP#332: 3/0/1
   For: DKF, AK, JN
   Against: none
   Present: KBK
TIP#341: 4/0/0
   For: DKF, AK, JN, KBK
   Against: none
   Present: none

Thanks to all who voted for their diligence.

Donal.

Re: [TCLCORE] TIP#339: Case-Insensitive Package Names

[<dg...@us...>]

Finally got around to reading the proposal
to (partially) shift [package] to using case
insensitive names.  Gonna sleep on it before
commenting extensively.

Meanwhile, it might help me if there were
some example advice of how both application
authors who are using packages, and package
authors would be recommended to modify their
code to make best use of the proposed changed
commands.

For example, if I distribute a script for
users to run, but not in any kind of starkit,
just a plain script.  It relies on having its
required packages and Tcl installed, and I
know it works when deployed to common Tcl
environments (like an ActiveTcl install)
because I know those environments include
the packages I use and I've been careful to
get all the names of all the packages I use
fully case correct.

Now when my users start using Tcl 8.6, all
my [package require]'s will be converted to
case insensitive searches, which creates a 
risk that the wrong package will be found and
break my app.  The TIP offers a -strict option
I can use to protect my program from this
risk, but if I use that, I'm locked out of
continuing to support Tcl 8.5 or even Tcl 8.4
environments that may still be perfectly sufficient
for my program.

Am I missing something?  Is there some better
migration plan I'm not seeing?

One more fairly general question for tonight.
Was any consideration given to a more radical
idea of moving directly to fully case insensitive
package names.  No -strict offerings.  No storing
of the particular case passed to [package provide].
Just [string tolower] everything on the way in.
Let the (allegedly rare) conflicts cause their
breakage in a loud and unmistakable way right away.
Clean up the mess with some renamings, and move
on so that years from now there's no lingering
dealing with multiple modes governed by -strict.
If this was considered, why was it rejected?

Hmm... following that up a bit longer than I planned,
couldn't that be offered and complete compat for
the existing [package] also be maintained simply
by adding a new command that wraps
the existing [package] with added [string tolower]s?

In fact, convert the [::package] command into an
ensemble and then redirect the subcommands either
to their original existing implementation, or to a new
set that wraps all name arguments with the [string tolower]
command to convert each package name into the canonical
name in the nocase equivalence class of the original name.

Supply a convenience subcommand [package match] to 
perform the ensemble redirecting operation for us,
with [package match case] and [package match nocase]
as the two modes  giving the app control over
whether the interp will recognize case in package names
or not.  Make a default choice (I'd choose
[package match case] as the default myself, since
it better keeps our usual promises of incompatibilities
kept as small as we can reasonably manage).  The
rare resetting of the [package match] mode would
both redirect the ensemble *and* sweep through the
package database correcting it to the new assumptions
as best it can.  This might mean a restriction to one
way mode shifting (can make it less demanding, but not
more so), similar to the way [package prefer] can shift
from "stable" to "latest" but can't go back again.

For the C API?  Just leave it alone.  Require C
programmers to get their package name arguments right.
We make them tend to ugly details like encodings.  They
can handle case.

I suspect I'm missing some detail in the [package unknown]
interface that needs further tending to fully flesh out
this alternative, but TIP 339 as written is already 
proposing to incompatibly rewrite that.  Could be as simple
as passing the [package match] mode as an argument.

One (semi-wild?  (hey, it's late here)) thought on
future expansion:  case is not the only thing that
causes confusion in otherwise similar names.  The
package names "a" and "A" are similar, but so are
the names "a" and "Á".  Why not treat them the same
too?  I can imagine adding more keywords to [package match]
to modify the equivalence classes of strings that would
govern the reduction of the name arguments ultimately
passed to the existing [package] machinery.

With that I bid you zzz.

DGP

Re: [TCLCORE] Tcl Core Team membership...

[Mark H. <mh...@pi...>]

D. Richard Hipp wrote:
 > In as much as kbk has now cleverly made the transition sound more like
 > a title bump than a demotion, I hereby volunteer to join jingham in
 > moving from Mostly Harmless to Respected TCTer Emeritus.

Yes, me too.  We're fully transitioned to Python these days, and what 
Tcl we have is locked at 8.4.  Please allow a final YES vote for Daniel.

I would like to take the chance to thank John and everybody in
the Tcl world for such a great experience.  Some Tcl highlights
I will never forget:

- hearing John give his Tk talk at the Dallas Usenix, and being
   so impressed by both John and his software.

- Introducing Tcl at bit conservative places like NEC and
   Digital Switch and trying so hard to convince them that it was
   top-quality software even thought it was being given away
   for free by Berkeley hippies.

- The perfection of the two-language model for so many things I
   wanted to do.

- Working with all the great Bell Labs guys.

- Fulfilling a lifetime dream by working with Brian Kernighan on
   the Effective Tcl/Tk book with Michael, and having Kernighan
   tell me that it was one of the few books he kept physically
   within arm's reach.

- All the wonderful workshops.

- The Tcl War.  "This is The Law, and it is good."

- Building the China Internet infrastructure based on passing
   blocks of Tcl around to be eval'ed, and seeing that scale up
   to over 100M users.

- Joining Pixar and setting a record for fixing a priority 11
   bug on my second day by patching tclUnixPipe to use fork()
   instead of vfork(), and being forwarded every Tcl-related
   bug for several years.

Many Thanks again, Best Regards, and Best "Wish"es to you all!!
Mark

-- 
Mark Harrison
Pixar Animation Studios

Re: [TCLCORE] CFV: My final round for 8.6...

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
> Jan Nijtmans wrote:
>> Further on, I agree with Joe about the Tcl_NRAddCallback
>> signature: it is overkill to have 4 clientData arguments,
>> one would be sufficient. For use inside the core,
>> there still is an internal variant with 4 arguments, so this
>> change is easy: Just make Tcl NRAddCallback call
>> TclNRAddCallback, but with NULL as the last 3 arguments.
>> I considered giving Tcl_NRAddCallback a variable number of
>> arguments, but I think that would needlessly complicate things.
> 
> I've written a few of the actual uses of that API, and can supply a bit
> of grist to this mill. It is most certainly useful to be able to pass
> more than one machine-word to the callback, and 4 covers a vast majority
> of cases: keeping down the number of times you have to allocate memory
> on the critical path is also a good idea.
> 
> IIRC, the number 4 was chosen because that was what it was convenient to
> provide in the backing structure while retaining a fast allocator. Or
> something like that.

Then why doesn't it receive some objv/objc API?

Re: [TCLCORE] Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

[Jan N. <nij...@us...>]

2008/12/8 Joe English <jen...@fl...>:
> For what it's worth, I would vote YES on the following:
>
>
> | SPECIFICATION
> |
> | Add a new convenience routine to the public API:
> |
> |       void Tcl_SetStringResult(Tcl_Interp *interp, const char *result);
> |
> | which shall be equivalent to
> |
> |       Tcl_SetObjResult(interp, Tcl_NewStringObj(result, -1));
> |
> | The existing routine Tcl_SetResult() shall be formally deprecated.
> |
> | END SPECIFICATION.

Yes, that's it, only that I specified Tcl_SetStringResult() to be
a macro, doing exactly that. The reason is that I expect
Tcl_SetStringResult to be a popular function, and someone
accidently using it might find that extensions using it,
compiled against Tcl 8.6, will no longer run against Tcl 8.5.
I know that 'forward compatibility' is not promised, but for
a function that is expected to be 'popular' it is more likely
to become a problem that for a hardly used function.

> I don't think that's exactly right -- Jan and I have identified
> a path towards eliminating interp->result internal manipulations,
> and I don't think it needs to wait a complete release cycle (all
> of the changes are internal and could be done at any time).
> Tcl_SetStringResult() would help smooth the path is all.

Agreed. But it would have helped if other TCT members
joined the discussion.

The exact specification can be found as 340b.patch in
[Patch 2315890].

So, what to do now? How do others feel about it? Should
I delay the vote again? Is Tcl_SetStringResult as a macro
OK, or should we make it a function (accepting the
'forward incompatibility'). Or both: define the function, but
let it be a macro in Tcl 8.6.

I called the vote in order to be able to reach the 9 dec deadline.
Would that still be possible now?

Regards,
         Jan Nijtmans

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

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

Donald Arseneau wrote:
> And "0" is Tcl's prefix for indicating base-8 formatting.

Since Tcl 8.5.0, Tcl's preferred way to denote octal is
with the 0o prefix.

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

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[Alexandre F. <ale...@gm...>]

On Mon, Dec 8, 2008 at 6:22 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
>
> I would love to see you at peace with this instead of seeing it pass
> with the two-thirds part of TYANNOTT...

Patch updated, now exactly matching the TIP, no more, no less.

-Alex

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[Donald A. <as...@tr...>]

dg...@us... writes:

> ...introduces something completely new.  For
> this format specifier the %# means "use Tcl's
> prefix for indicating base-2 formatting" -- in
> this case the 0b.

That is not new, but the same as for %#x -> 0x.

> But then we look at:
> 
> % format %#o 14
> 016
> 
> (NOT 0o16 !)

And "0" is Tcl's prefix for indicating base-8 formatting.
Yes, that could (should) change as part of the program to 
eliminate the EVIL "0 prefix means octal". 

That doesn't mean %b should be held up.  I had it in my
head that %b was already accepted and was surprised when
it came up in the recent TIP!  Please don't wait longer.

> pointed out in Bug 2373594:
> 
> % scan 0b111 %i
> 0
> % scan 0o7 %i
> 0

Indeed bugs, but only conceptually related to this TIP,
unless they are the tip of an iceberg that sinks all the
radix internals.



-- 
Donald Arseneau                          as...@tr...

[TCLCORE] TIP#329 (try/catch) vote

[Andreas K. <and...@ac...>]

My vote
	TIP#329	PRESENT

Read the TIP and it feels good. Tried to read the discussion and got lost. I
am not sure enough of my feelings of goodness to say yes, and have to trust
the people which actually took part in the discussion here, i.e. not stand
in their way.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

[TCLCORE] TIP#322 (NRE API) vote

[Andreas K. <and...@ac...>]

My vote
	TIP#322	YES

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

[TCLCORE] Updated: Status of votes in progress ...

[Andreas K. <and...@ac...>]

> ... as far as I was able to determine from the recent flood of mails ...

Update using the latest votes.
 
> Voters = Who has voted what so far (+YES, -NO)
	/PRESENT
 
TIP             Deadl.  Voters
 
324 tk_font     9       +dkf	/ak +jnijtmans +kbk
332 1/2 close   9       +dkf +ak +jnijtmans /kbk
341 dict filter 9       +dkf +ak +jnijtmans +kbk
 
329 try/catch   10      +dkf +jenglish +jnijtmans /kbk
339 pkg names   10      +ak +tclguy -jenglish -jnijtmans +kbk
343 %b format   10      +dkf +ak +jnijtmans -dgp +kbk
322 nre api     10/12   +msofer +kbk +jenglish +jnijtmans

Voting ended for

340	const qual		rejected
234	zlib		accepted
244	png		accepted

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

Re: [TCLCORE] Yet more voting. (TIP 339 - Case-Insensitive Package Names)

[Jeff H. <je...@ac...>]

Jan Nijtmans wrote:
>  Andreas Kupries wrote:
>> Let us see who screams.
>> Calling the vote on
>>       TIP #339:       Case-Insensitive Package Names
> 
>  TIP#339: NO.
> 
> I hesitated much about this one, but finally  Jeff's remark
> about case insensitive OSes brought me to this. Most
> languages (e.g. java) have all lower-case package names.
> It just means that on a case-insensitive OS, a mismatch
> between file/directory-name and package name will not
> hurt, on other systems it will. Keeping the "be strict in what
> you generate and generous in what you accept" principle
> (in my interpretation) we should continue to accept
> Camel-case package names, but from now on only
> provide all-lower-case ones.
> 
> So, I suggest to make Tcl and Tk provide the "tcl" and "tk"
> packages as well as the "Tcl" and "Tk" packages, and
> - for Tk - make "package require tk" equivalent to
> "package require Tk". Just make all-lowercase package
> names the recommended way, but not enforce it. Then
> no current packages will break, still eventually every
> one can remember the concept. In time, the problem
> will fade away.

This seems like a flawed argument.  "I acknowledge the problem, but 
let's not force any fix, let's just recommend one, leaving the potential 
problems in the core and hope they fade away".  Eh?

Jeff

[TCLCORE] Ballot on pending TIPs

[Kenny, K. B (G. Research) <ke...@cr...>]

Thank you, Andreas for the summary.
 
TIP #324: YES.  
    We've needed a proper font selector for a long time.
    Now that the Windows-style (toplevel only) and the
    Mac-style (componentry) are both accounted for, this
    ought to go forward.
 
TIP #332: PRESENT
    I don't really feel comfortable evaluating this one.
    If Donal and Andreas are happy with it, I'll let others
    attack if they want.
 
TIP 341: YES
    Why not?
 
TIP 329: PRESENT
    I got lost in the discussion of this one long ago.
 
TIP 339: YES
    Tcl Modules in case-independent filesystems cause
    confusion. And I can never remember which package
    authors chose Titlecase or CamelCase for package
    names. If it causes some short-term breakage, so
    be it; the breakage is easy to fix.
 
TIP 343: YES
    Contrary to Don Porter's assertion, the TIP as stated
    makes %b work in a manner that is precisely analogous
    to %x. (It's not analogous to %o, but that inconsistency
    is something that we've inherited from our forbears.)
 
I've already registered YES votes on TIPs 234, 244 and 322.
 
-- 
73 de ke9tv/2, Kevin