tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Another path to case-tolerant package names

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

Larry W. Virden wrote:

> The one group this change would impact negatively are those who, like
> those who commented during the TIP discussion, have code which
> unfortunately use the same name and different case (such as tcltest
> and tclTest, etc.) for different functionality.

As one of those affected, I should clarify our situation:
it's *not* the case that we have two distinct packages
named "Foo" and "foo" in use in a single application,
or even "Foo" and "foo" used in different applications.
Conflicts like that are easily avoidable -- if we're using
(or even just know about) a package named "foo", then don't
name a new package "Foo"; that's only sensible.

Rather, the issue is this: we develop a local package named
"Foo", and then months or years later a package named "foo"
shows up in tcllib.  (In fact for a while I was using Titlecase
for local package names precisely because I knew it would be
safe from tcllib namespace encroachment.)

(Also FWIW: case-insensitive package names would not bite us
very hard wrt tcllib nowadays, as I no longer install it anywhere
_in toto_;  only a handful of selected tcllib modules get deployed
locally.)


--Joe English

  jen...@fl...

Re: [TCLCORE] Tk_MainEx: extreme archeology

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

Alexandre Ferrieux wrote:
> However, nothing prevents the existence of wishlike apps which do use
> Tk Stubs, provided they call Tk_InitStubs early enough that the
> tkStub->tk_MainEx be valid.

Thanks to both you and Jan for the replies.

It seems that the current state of things permits for a program like
this:

#undef USE_TCL_STUBS
#include "tcl.h"
#define USE_TK_STUBS
#include "tk.h"

int appInitProc(Tcl_Interp *interp) {
     return TCL_OK;
}

int main(int argc, char **argv) {
     Tcl_Interp *interp = Tcl_CreateInterp();

     if (Tcl_Init(interp) == TCL_ERROR) {
         Tcl_Panic("borked Tcl install!");
     }
     if (Tk_InitStubs(interp, TK_VERSION, 0) == NULL) {
         Tcl_Panic("Cannot find Tk!");
     }
     Tk_MainEx(argc, argv, appInitProc, interp);
}

And build an executable from it like so:

$ gcc demo.c -L... -l tcl8.5 -l tkstub8.5

And end up with essentially a "wish" program, but not tied
to a particular libtk.  Able to make use of whatever libtk.so
gets [load]ed by [package require Tk] in the local install.

The "wish" program we distribute with Tk doesn't do this.
Are there any known programs that make use of this capability?

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

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

Hi,
> Is "Option #2a" implementable, and will we need one or two dashes
> per (forwarding) handler?
>   
The most likely implementation is a check that varslist must be {} if 
body is "-".
e.g.  try { ... } on break {} - on continue {em opts} { ...handler for 
break and continue, gets em+opts... }

I could allow varslist to be {} or "-" in such a case -- it's prettier, 
but "-" is in fact a valid varslist (assigns the result to the local 
variable "-").
e.g. try { ... } on break - - on continue {em opts} { ...handler for 
break and continue, gets em+opts... }

> PS: I'm nevertheless looking forward for an optional "as" clause
>   in hopefully not-too-far future.
>   
I'm hoping to put the Tcl implementation into tcllib (possible in the 
control package), giving [try] functionality to Tcl 8.5.  This will then 
be an appropriate place to experiment with new features (like 'as').  
 From there I imagine they may be TIPped into the core.

Regards,
Twylite

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

[Andreas L. <av...@lo...>]

On Fri, Dec 12, 2008 at 03:39:07PM +0200, Twylite wrote:
> Hi,
> >That one isn't strong in my mind.  Did I miss other arguments?
> [ list of (some more and some less-but-still) valid arguments
>   acknowledged ]

Ok, I now understand also the advantages of per-handler variables.
Thanks a lot.

Is "Option #2a" implementable, and will we need one or two dashes
per (forwarding) handler?

PS: I'm nevertheless looking forward for an optional "as" clause
  in hopefully not-too-far future.

[TCLCORE] TIP#322 Accepted

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

TIP#322 on the NRE API has now been Accepted 5/0/0

  For: MS, KBK, JE, JN, AK
  Against: none
  Present: none

Donal.

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

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

Hi,
> That one isn't strong in my mind.  Did I miss other arguments?
>   
1. There were a number of "complaints" (both here and off-list) that the 
'as' clause was ugly to format.  I'm inclined to agree and it was one of 
the reasons I resisted 'as' in the first place.  I believe that code 
readability is an important feature, and consistency (of syntax & of 
layout) aids readability.

2. Locality: associating the variable with the handler gives more 
immediate knowledge of what the variable names are, and allows the 
variable names to be contextually appropriate.
Example:  try { open "somefile.txt" r } on ok {f} { puts $f "hello" } 
trap {} {errmsg} { log "Failed: $errmsg" }

3. Easier to reuse handlers: if the vars are associated with the handler 
it becomes easier to reuse handlers either by storing the handlers as a 
string or by cut/paste/adapt.  In my experience a huge amount of error 
handling code is cut/paste/adapt, and a major source of errors for 
junior coders is bad variable names in error handlers (whether from cut 
& paste or simple mistyping; compiled environments pick this up, Tcl 
doesn't until you hit an error or test every error path via fault 
injection), so avoiding or reducing such errors is a major win.

4. Familiarity: it's what other languages do.

5. It's the safer approach.  It is possible to add 'as' later, but it is 
not possible to add per-handler variables later.  If we do add 'as' and 
the per-handler variables are mostly unused it becomes a syntactic quirk 
that we can & will live with.

Comparing to the points you made, the choice of which is "better" is 
determined largely by what importance/weight you assign to various 
features and "misfeatures".

> (It would really surprise me, if implementation effort wasn't
> rather an argument *for* the "as ..."-clause instead of against,
> but I may of course be wrong there)
>   
It's kindof neither here nor there.  The (pure Tcl) implementation is 
different but no more or less complex - it's a matter of putting the 
varslist parsing + upvar + assignment inside or outside a loop.

>> There's also [catch] ...)
>>     
> Oh really? I thought that was being replaced...  (just kidding :-)
>   
<[catch]> Rumors of my demise have been greatly exaggeraaughhhh---

Regards,
Twylite

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

[Andreas L. <av...@lo...>]

On Fri, Dec 12, 2008 at 11:08:30AM +0200, Twylite wrote:
> The counterpoints have already been presented.  I think there are strong 
> arguments both ways,

I'm definitely biased, but the only argument for handler-specific
variables, that I found in the discussion was that all the other 
languages (especially Java) have per-handler variables.

That one isn't strong in my mind.  Did I miss other arguments?

(It would really surprise me, if implementation effort wasn't
rather an argument *for* the "as ..."-clause instead of against,
but I may of course be wrong there)


> >Option #Omega:  reinstate the "as"-clause.
> try -mode tip329 ...
> try -mode option1 ...
> try -mode omega ...
> C'mon, you know you want to ... ;>

Nice revanche for my previous personal mix-up, (for
which I apologized recently).

I'm not the options-fancier. No, I honestly would not
advocate any such options (not even with better names)

> (Aside: we can still add the "as" clause later, if desired.
I'd indeed desire that, on position 2 (right after #1: "also
drop the per-handler variable lists").   Leaving it as in the
TIP would be position 3, and no-"try"-at-all somewhere near
1000 followed only by -option'ed versions of "try".

> There's also [catch] ...)
Oh really? I thought that was being replaced...  (just kidding :-)

Re: [TCLCORE] Another path to case-tolerant package names

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

2008/12/12 Larry W. Virden <lv...@gm...>:
> The one group this change would impact negatively are those who, like
> those who commented during the TIP discussion, have code which
> unfortunately use the same name and different case (such as tcltest
> and tclTest, etc.) for different functionality.

The intent of the current discussion is to come up with
a solution which doesn't have this disadvantage. Let's
see how it goes, but it looks like going in the
right direction.

Regards,
        Jan Nijtmans

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

[Andreas L. <av...@lo...>]

On Fri, Dec 12, 2008 at 01:07:34PM +0100, Andreas Leitgeb wrote:
> > (Aside: we can still add the "as" clause later, if desired.
> I'd indeed desire that, on position 2 (right after #1: "also
> drop the per-handler variable lists").   Leaving it as in the
> TIP would be position 3, and no-"try"-at-all somewhere near
> 1000 followed only by -option'ed versions of "try".

Small correction:  position 3 is  TIP with option #2a,
(which is either  "trap FOO - - BAR {x y} { body }" or
"trap FOO - BAR {x y} { body }" i.e. one dash replacing
both variable list and body together unless it was much
more complicated to implement.)

Current TIP is, as you wrote yourself, "unworkable".

Re: [TCLCORE] Another path to case-tolerant package names

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

2008/12/12 Daniel A. Steffen <da...@us...>:
> No, if you want to stay backwards compatible, there is no way around a
> second hash table IMO, otherwise you cannot avoid key collision of
> ordinary entries (e.g. key "tk" for package "tk") with phony entries
> (e.g. case-folded key "tk" for package "Tk")

Yes, you are right. And performance is no issue here, because
the fallback search is only done if the first one failed.

> This scheme would seem to provide most of the benefits of TIP339 while
> being fully backwards compatible w.r.t existing successful [package
> require]s in the presence of case conflicting package names.

Right!

> Of course existing _failing_ [package require]s might become
> successful under this, which could be an issue for some code, but that
> should still be a much lesser incompatibility than existing successful
> [package require]s possibly loading a different package than
> intended...

I Guess I'm getting enthousiastic about this idea. The only thing
that needs to be verified if Tcl modules still work: Will
a "package require foobar" find the file FooBar-1.0.0.tm?

Regards,
        Jan Nijtmans

Re: [TCLCORE] Another path to case-tolerant package names

[Daniel A. S. <da...@us...>]

On Fri, Dec 12, 2008 at 09:45, Jan Nijtmans <jan...@gm...> wrote:

> Maybe even simpler than a second table is just
> a flag in each entry, indicating whether the entry
> is phony or not, or better an entry indicating the
> 'companion entry'.

No, if you want to stay backwards compatible, there is no way around a
second hash table IMO, otherwise you cannot avoid key collision of
ordinary entries (e.g. key "tk" for package "tk") with phony entries
(e.g. case-folded key "tk" for package "Tk")

Concretely, the idea discussed with Don on the chat this morning was
the following:

- in Tcl_PkgProvide() add an entry keyed by the case-folded name of
the provided package to a new fallback table (in addition to the
existing insertion of the package into iPtr->packageTable).
- amend PkgRequireCore() to check this fallback table with the
case-folded name iff the ordinary package lookup has failed (including
the [package unknown] invocation & subsequent recheck).
- amend the [package unknown] handler contract (and the existing core
handlers) to include a search for any case-variant of the asked-for
package name iff the search for the exact asked-for name has failed.
- after all calls to Tcl_FindHashEntry(&iPtr->packageTable,...) in
tclPkg.c (except for PKG_NAMES),  lookup the case-folded name in the
fallback table iff the packageTable lookup has failed.

On a install with no case conflicts in package names, this would
result in a [package require] that is completely case-insensitive
w.r.t package names.
With packages present whose name only differs by case however,
[package require]s of their exact names would continue to get the
right package, i.e. have the same result as it does currently (and
[package require] of non-existent case variants would get the last
[package provide]d one).

This scheme would seem to provide most of the benefits of TIP339 while
being fully backwards compatible w.r.t existing successful [package
require]s in the presence of case conflicting package names.

Of course existing _failing_ [package require]s might become
successful under this, which could be an issue for some code, but that
should still be a much lesser incompatibility than existing successful
[package require]s possibly loading a different package than
intended...

Cheers,

Daniel

Re: [TCLCORE] Another path to case-tolerant package names

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

The one group this change would impact negatively are those who, like
those who commented during the TIP discussion, have code which
unfortunately use the same name and different case (such as tcltest
and tclTest, etc.) for different functionality.

Which would be best - a way for such developers to be able to force
their naming preference or need, or a way for Tcl to raise an error
when encountering an attempt to define such a situation?

-- 
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden http://www.purl.org/net/lvirden/
http://www.xanga.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

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

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

Hi,
>> - removed the 'as {resultsVar optionsVar}' clause and introduced 
>> per-handler variable assignment
>>     
> An unfortunate decision that was rushed into the TIP just before voting.
> Three reasons against it:
>   
I was expecting this reply ;)

The counterpoints have already been presented.  I think there are strong 
arguments both ways, and I don't think either approach is a clear 
winner.   Per-handler variables was part of my original plan for the 
TIP; fall-through bodies wasn't.  Had the TCT not put their feature 
freeze at the crunch point of my two biggest projects I may have got the 
handling of "-" correct in the TIP ;)

> Option #2a:  make "-" be recognized in place of the variable list.
>   
Yes, definitely worth considering.  I think that Option #1 (use FOO's 
variable list and BAR's body) is unworkable.  Option #2 (BAR's list & 
body) leaves an unused variable list attached to FOO, which is just 
weird.  Either FOO's variable list must go away (require "-" if the body 
is "-") or both FOO and BAR's variables must be set (I don't know if 
this is somehow more useful).
> If a corrigendum was still possible, I'd prefer:
>
> Option #Omega:  reinstate the "as"-clause.
>   
try -mode tip329 ...
try -mode option1 ...
try -mode omega ...

C'mon, you know you want to ... ;>

(Aside: we can still add the "as" clause later, if desired.  It would be 
an optional clause between the try body and the first handler, and would 
not replace per-handler variable lists, but be set in addition to any 
variables in those lists.  There's also [catch] ...)

Twylite

Re: [TCLCORE] Another path to case-tolerant package names

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

2008/12/12  <dg...@ni...>:
>     # Tricky case.  $name has not been provided,
>     # but some case variant might have been, in
>     # some way that avoided contact with the
>     # [package ifneeded] wrapping trickery.  So
>     # search for such a thing...

This should not be possible: Doing this in C means
that there is no way to circumvent it: Any package
providing "FooBar" should immediately provide
"foobar" as phony entry as well.

Such kind of search is asking for trouble :-/

> Drop into C and the addition of a second table isn't
> hard.  It was even part of the TIP 339 Implementaion,
Maybe even simpler than a second table is just
a flag in each entry, indicating whether the entry
is phony or not, or better an entry indicating the
'companion entry'. Then we can, in case of an
'unload' always remove both the real and the
phony entry.

Bringing an 'unload' into account as well, that
might make things more tricky.......

Regards,
         Jan Nijtmans

Regards,
          Jan Nijtmans

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

[Andreas L. <av...@lo...>]

Twylite <tw...@cr...> wrote:
> - removed the 'as {resultsVar optionsVar}' clause and introduced 
> per-handler variable assignment

An unfortunate decision that was rushed into the TIP just before voting.
Three reasons against it:
  - Tcl's variables outlive their specific handler block. They even
       outlive the whole try-construct. As such they are not at all
       comparable to e.g. Java's try/catch where these variables 
       only exist inside their respective handler.
  - Originally (with "as ..."), these variables would have been also
       available in the finally block.  Now, they are available
       depending on whether and which other handler fired, and can
       never be relied on.
  - The (only now showing up) problem with "-".

Joe English <jen...@fl...> wrote:
> > Option #1: set the FOO case variables only; making sure the body works
> > correctly is the developer's problem
> Option #1 is what the TIP specifies should happen.

> > Option #2: set the BAR case variables only; the fact that the FOO
> > variables are left unset is a quirk of using the "-" syntax
Option #2a:  make "-" be recognized in place of the variable list.

> I for one would not object to a corrigendum specifying
> option #2, but for now it's probably best to make the
> implementation match the specification.

If a corrigendum was still possible, I'd prefer:

Option #Omega:  reinstate the "as"-clause.

I wonder, who of the voters had their vote depending on the
way of variable handling.

Re: [TCLCORE] Another path to case-tolerant package names

[<dg...@ni...>]

Quoting dg...@ni...:
> As I've sketched this, there's one troubling implication,
> and that is there is one group who are measurably
> worse off, and that is the authors of packages who
> have chosen all lowercase names. ...

Daniel Steffen has pointed out to me in the chat the
source of my difficulty.  By stubbornly trying to
solve this in Tcl only, I'm limited to the storage
present in the current [package] implementation,
which is a single table.  My so-called "real" and
"phony" entries are forced into one table which
causes the collisions and confusions I note above.

Drop into C and the addition of a second table isn't
hard.  It was even part of the TIP 339 Implementaion,
if I followed that right.  Doing so can keep the
existing table functioning undisturbed.

DGP

Re: [TCLCORE] Another path to case-tolerant package names

[<dg...@ni...>]

  ...Revise [package ifneeded] so that...
>> Any package that doesn't have an all lowercase name will
>> automatically make itself available in both original
>> and all lowercase naming variants.

A few loose ends...

This scheme also requires a change in the [package unknown]
contract.  This is common to every scheme with aims similar
to TIP 339, because the handler has to conform to the new
expectation that it will seek out [package ifneeded] evaluations
from all case variants before giving up and permitting [package
require] to report "not found".  There's no case tolerance scheme
that can escape that.  (Well, none other than calling the
[package unknown] handler 2**[string length $name] times with
all the case variants!)

The other hole I can see in what I sketched is the mode where
[package require] succeeds because the requirement is met by an
already loaded package.  I *think* that omission is what you're
getting at below.  Or maybe the combination of these two matters?

Quoting "Andreas Kupries" <and...@ac...>:
> The only packages not handled by the above are those going through the C
> interface, i.e. Tcl_PkgRequire() and variants, to register themselves.

...but unless I'm missing something, this has nothing at all
to do with C interface vs. Tcl interface.

> These can be handled however as well, by redirecting the
> '::tcl::package::require' implementation.

Following your lead, try this:

proc ::tcl::package::Require {name args} {
     set lcname [string tolower $name]

     # Required name not all lower case.
     # No collision with phony entries possible.
     # Use the normal subcommand.
     if {$lcname ne $name} {
         return [require $name {*}$args]
     }

     if {[package provide $name] ne {}} {
         # Requested package is already provided.
         # Whether that's real or phony, the
         # normal subcommand can handle it right
         return [require $name {*}$args]
     }

     # Tricky case.  $name has not been provided,
     # but some case variant might have been, in
     # some way that avoided contact with the
     # [package ifneeded] wrapping trickery.  So
     # search for such a thing...
     foreach n [lsearch -all -inline -nocase [package names] $name] {
         set v [package provide $n]
         if {$v ne {}]} {
             # Fill in the missing phony entry
             package provide $name $v
             break
         }
     }

     # Any missing match is now filled in, so
     # the normal subcommand is now ok to call,
     # and permit it to probe [package ifneeded]
     # entries and invoke [package unknown] handlers.
     return [require $name {*}$args]
}

[package present] needs the same thing.

As I've sketched this, there's one troubling implication,
and that is there is one group who are measurably
worse off, and that is the authors of packages who
have chosen all lowercase names.  Up to now, they've
been in the same situation as any package author.  They
need their users to require them by exactly the
correct name, and have to worry about collision with
another author who chose precisely the same name.

After this revision, the packages with all lowercase
names now have to worry about colliding with the
whole case-insensitive set of matching package names,
a bigger potential for collision.  ("trofs" has to
worry about collision with "Trofs")  In contrast,
everyone else is likely better off, with users
now able to require them in all lowercase form,
so long as their name is unique in that broader
collection ("Itcl" gets all those users who can
only spell "itcl"), but even if there is a collision
preventing that, at least they are no worse off and
the precisely correct requires from before continue
to work.

So the incentives push package authors mildly *away*
from using all lowercase names, while encouraging
[package require] callers to make use of all lowercase
names.  I think since the number of package users should
be much larger than package providers, it makes most
sense to give the typing convenience to them.  The other
impact is to encourage all package authors to aim for
names that are globally unique even without case to
distinguish.  And that's a helpful preparation step
for conversion to Tcl Modules.

DGP

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

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

Twylite wrote:

> Outstanding issues:
> - In the case of a fallthrough body "-", to which variable(s) should the
> outcome of the try body be assigned?
> e.g.  try { throw FOO bar } trap FOO {em1 opts1} - trap BAR {em2 opts2}
> { puts body }
> It seems logical that the variables for the BAR case may be expected by
> the BAR body and should be set; but what about those for the FOO case?
>
> Option #1: set the FOO case variables only; making sure the body works
> correctly is the developer's problem

Option #1 is what the TIP specifies should happen.

> Option #2: set the BAR case variables only; the fact that the FOO
> variables are left unset is a quirk of using the "-" syntax

This would also be sensible, and possibly more useful,
but it's not what the TIP says.

> Option #3: set the FOO and BAR variables; possibly more consistent from
> the developer's perspective, but adds complexity to any implementation
> that is aiming for performance
> Option #4: sets the FOO and BAR variables as well as those of any other
> fallthrough cases in between, also at a cost in complexity/performance terms

The last two options don't strike me as either sensible or useful.

> The current implementation provides Option #2, but this is strictly a
> side-effect of the implementation and easily changed to #1 or #4 (#3 is
> a bit of a pain).

#1 is what the TIP says.  #2 would also be reasonable
(and, now that I think about it, probably a better choice).

I for one would not object to a corrigendum specifying
option #2, but for now it's probably best to make the
implementation match the specification.


--Joe English

  jen...@fl...

Re: [TCLCORE] Another path to case-tolerant package names

[<dg...@ni...>]

Quoting "Jan Nijtmans" <jan...@gm...>:
> - What if ... [there is a "real" package with an
     all lowercase name that gets its slots in the
     package database polluted by the entries for
     the phony package added just for this caseless
     finding trickery?]

>   Solution: before doing the second "package ifneeded", check if
>   there already is one. If so, don't overwrite the previous.

That's pointed in the right direction.  I believe the true
solution is not quite that simple, but certainly doable.
(You want the entries for real packages to win over the phony
entries, and "first claim wins" won't accomplish that.)

> I don't think that using an ensemble for this is even neccessary.

No, not necessary.  We could just modify the C implementation
of [package ifneeded] to the new spec directly.

The advantage of the ensemble approach is that it "exposes
the wires" to script level, so then things are more easily
switchable back to the old way, or to other ways.  A useful
capability when we're rushing a design and there's at least
some reason to doubt we've settled on the unquestionably
best solution.

DGP

Re: [TCLCORE] Another path to case-tolerant package names

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

2008/12/11  <dg...@ni...>:
> I'm about 30 messages buried in e-mail so forgive
> me if someone else has already come forward with
> the same solution.
No, I didn't see this solution before.

Sounds good, only one remark:

- What if there are two packages e.g. "tcltest" and "tcltest", where
  the lower-case package is found first. Then what happens is:
         package ifneeded tcltest script1
         package ifneeded Tcltest script2
         package ifneeded tcltest script2\npackage provide tcltest ....
  So, the lower-case "package ifneeded" for Tcltest overwrites the
  original "package ifneeded" for "tcltest", so "tcltest" can never be
  loaded any more.
  Solution: before doing the second "package ifneeded", check if
  there already is one. If so, don't overwrite the previous.
The nice thing is that this works for C packages and for Modules
as well: the script that does the "package ifneeded" determines
the casing of the Module filename, nothing changes there.
That's very nice.

I don't think that using an ensemble for this is even neccessary.
This is worth investigating further.

Regards,
        Jan Nijtmans

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

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

Okay, I found some time to work on the reference implementation.

Changes:
- 'throw' has behavior consistent with 'error'.  The 'interp alias' 
approach that was suggested behaves weirdly if you don't get the 
arguments right, so the implementation is proc-based.
- removed the 'as {resultsVar optionsVar}' clause and introduced 
per-handler variable assignment
- improved error messages
- improved behavior of '-during'
- added tests (there are just under 100 tests covering most aspects of 
the functionality; more to come)

Outstanding issues:
- In the case of a fallthrough body "-", to which variable(s) should the 
outcome of the try body be assigned?
e.g.  try { throw FOO bar } trap FOO {em1 opts1} - trap BAR {em2 opts2} 
{ puts body }
It seems logical that the variables for the BAR case may be expected by 
the BAR body and should be set; but what about those for the FOO case?
Option #1: set the FOO case variables only; making sure the body works 
correctly is the developer's problem
Option #2: set the BAR case variables only; the fact that the FOO 
variables are left unset is a quirk of using the "-" syntax
Option #3: set the FOO and BAR variables; possibly more consistent from 
the developer's perspective, but adds complexity to any implementation 
that is aiming for performance
Option #4: sets the FOO and BAR variables as well as those of any other 
fallthrough cases in between, also at a cost in complexity/performance terms
The current implementation provides Option #2, but this is strictly a 
side-effect of the implementation and easily changed to #1 or #4 (#3 is 
a bit of a pain).
- Some corner cases around when "-during" should or should not be added 
to the options dict.

Updated version available at http://www.crypt.co.za/pub/try-2.tcl .

Regards,
Twylite

Re: [TCLCORE] Another path to case-tolerant package names

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

> I'm about 30 messages buried in e-mail so forgive
> me if

> someone else has already come forward with
> the same solution.

No, you are the first.

> First, make [package] as it is now into an ensemble
> in the conventional way, redirecting subcommands
> to the corresponding [tcl::package::*] command.
> ([package provide] -> [tcl::package::provide]).

> Next define this proc:

> proc ::tcl::package::Ifneeded {name v script} {
>
>      # omit redirect of the "no script argument" case

>      # do what we do now
>      ifneeded $name $v $script
>
>      # For all lowercase package names, we're done
>      set lcname [string tolower $name]
>      if {$name eq $lcname} {return}

>      # package names with more "interesting" case get
>      # entered into the database a second time in
>      # all lowercase form, using chaining to pull in
>      # the real package name:

>      set lcscript [list package require $name $v-$v]
>      append lcscript \n[list package provide $lcname $v]
>      ifneeded $lcname $v $lcscript
> }

> Then change the ensemble redirection so that
> [package ifneeded] routes to [::tcl::package::Ifneeded].

> Now no changes need to be made to any existing package.
> Any package that doesn't have an all lowercase name will
> automatically make itself available in both original
> and all lowercase naming variants.

Correct.

The only packages not handled by the above are those going through the C
interface, i.e. Tcl_PkgRequire() and variants, to register themselves.

These can be handled however as well, by redirecting the
'::tcl::package::require' implementation.

If a name is not found by the original 'require' use names' to look for
camel-case variations of the  name. If there is one add the necessary bridge
and redo the 'require'. We could restrict our search to be done only if the
required name is all-lower case. I.e. using the CamelCase name asks for
strict compliance.

proc ::tcl::package::Require {name args} {

	if {![catch {
		require $name {*}$args
	} res opts]} {
		return $res
	}

	# name was camel-case, we are strict, rethrow the error
	set lcname [string tolower $name]
      if {$name ne $lcname} {return ... $res ... $opts}

	# name was all-lowercase, look for camel-case variations, take first (or
error if ambigous?)
	foreach p [names] {
		if {[string tolower $p] ne $name} continue

		# ... create and enter bridge ...

		# redo query
		return [require $name {*}$args
	}

	# nothing found, rethrow error
	return ... $res ... $opts
}


> Doing this with ensemble redirections means the ability
> to completely restore the legacy mode is possible.  We
> can ponder whether a command to set "compat mode" for that
> is worthwhile, but with less urgency since even if we don't
> do it we leave the tools in place at script level for
> those users who must have it to make it so for themselves.
>
> No begging and pleading and hoping for package authors
> to get their act together (a proven losing strategy), and
> at the same time, no destructive refusal to use the names
> those authors have asked to use.  Simply the addition of
> a bridge.


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

[TCLCORE] Another path to case-tolerant package names

[<dg...@ni...>]

I'm about 30 messages buried in e-mail so forgive
me if someone else has already come forward with
the same solution.

First, make [package] as it is now into an ensemble
in the conventional way, redirecting subcommands
to the corresponding [tcl::package::*] command.
([package provide] -> [tcl::package::provide]).

Next define this proc:

proc ::tcl::package::Ifneeded {name v script} {

     # omit redirect of the "no script argument" case

     # do what we do now
     ifneeded $name $v $script

     # For all lowercase package names, we're done
     set lcname [string tolower $name]
     if {$name eq $lcname} {return}

     # package names with more "interesting" case get
     # entered into the database a second time in
     # all lowercase form, using chaining to pull in
     # the real package name:

     set lcscript [list package require $name $v-$v]
     append lcscript \n[list package provide $lcname $v]
     ifneeded $lcname $v $lcscript
}

Then change the ensemble redirection so that
[package ifneeded] routes to [::tcl::package::Ifneeded].

Now no changes need to be made to any existing package.
Any package that doesn't have an all lowercase name will
automatically make itself available in both original
and all lowercase naming variants.

Doing this with ensemble redirections means the ability
to completely restore the legacy mode is possible.  We
can ponder whether a command to set "compat mode" for that
is worthwhile, but with less urgency since even if we don't
do it we leave the tools in place at script level for
those users who must have it to make it so for themselves.

No begging and pleading and hoping for package authors
to get their act together (a proven losing strategy), and
at the same time, no destructive refusal to use the names
those authors have asked to use.  Simply the addition of
a bridge.

DGP

Re: [TCLCORE] End of Votes

[<dg...@ni...>]

Quoting "Jan Nijtmans" <jan...@gm...>:
> Something can be done about it: I think it would be good that the TCT
> starts recommending all lower-case package names.

Thanks for raising this a second time.  Sometimes it takes
a few encounters to see the value of an idea.  I think this
is basically the right idea...

> Here is a patch doing this for Tk (unix and win).

...the good news is there's a much simpler way to accomplish
it that will involve only changes to Tcl itself.  I'll post
the sketch of that in a separate message with a new subject.

DGP

Re: [TCLCORE] Tk_MainEx: extreme archeology

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

On Thu, Dec 11, 2008 at 12:21 PM, Jan Nijtmans <jan...@gm...> wrote:
>
> This way wish is just a
> small application, linked with two libraries
> (libtcl and libtk), calling one Tcl function
> in libtcl (Tcl_CreateInterp), and another
> function in libtk (Tk_MainEx) to handle
> everything that needs to be done as
> part of the initialization. All remaining
> thing are done through the stub mechanism.

BTW, on a Win32 (mingw) build of wish at least, TK_USE_STUB is not
used. So only the Tcl stub table (to which Tk_MainEx doesn't belong)
is meaningful in this description.

However, nothing prevents the existence of wishlike apps which do use
Tk Stubs, provided they call Tk_InitStubs early enough that the
tkStub->tk_MainEx be valid.

-Alex