tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] canvas 'postscript' command

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

T. Horsnell wrote:
> Hi, I'm new to tcl, so apologies if this is an inappropriate list
> to ask for help.
> I have tcl/tk 8.5.2 on Fedora 9, and hav a curious problem using the
> 'postscript' command on a canvas.

Perhaps the newsgroup comp.lang.tcl would have been more appropriate,
since there are more eyes watching it.

> I have a line like:
>    .c create text 200 200 -text "Hello World" -font {FreeSans 50}
> in my tcltk script file, and the text displays with the correct font.
> 
> If I dump the cancas window to a file with a line like:
>    .c postscript -x 0 -y 0 -height $h -width $w -pagewidth 8.0i \
>         -pageheight 11.0i -pagex 4.0i -pagey 5.5i -pageanchor c \
>         -file junk2.ps
> The postscript file ends up with a line like
>    /Freesans findfont 50 scalefont ISOEncode setfont
> 
> The FreeSans from the script has been changed to Freesans in the
> postscript file and Ghostscript cant then find the font.
> 
> Short of editing all my (ttf) font files is there a fix for this?

By default, Tk's got a fairly hokey bit of font guessing code for
converting things to postscript; it's necessary to do this because
printers often have much smaller sets of fonts installed (more than just
"Times", "Helvetica" and "Courier", but not much more). As I said, the
code is hokey and is defeated by the way "FreeSans" has a significant
inner capital letter; its default of "title-case each word and
concatenate them" didn't work this time.

But there is a way round.

If you specify the -fontmap option to the postscript subcommand/method,
then you take complete control over how the font is converted since the
option lets you give your own mapping directly (well, as a name to an
array that contains the mapping). Mind you, I've not experimented with
the option a lot myself so some experimentation to get good results
might be needed. Still, at a guess this might work...

    set theFont "FreeSans 50"
    set mapAry($theFont) $theFont
    .c postscript -fontmap mapAry ...all the other options

Of course, it should also be possible to use traces on the array to get
things working even better. Note also that postscript font names don't
have spaces in (since they're PS symbols).

More details, such as they are, are at:
   http://www.tcl.tk/man/tcl8.5/TkCmd/canvas.htm#M63
The Tcler's wiki is currently very sparse on this topic. I'll add a bit
more, but you're encouraged to contribute as well.
   http://wiki.tcl.tk/

As an aside for tinkering with this stuff, I found the following useful
for shortening the interactive try-a-change-and-test cycle...

    less <<[.c postscript -fontmap mapAry]

Donal.

Re: [TCLCORE] canvas 'postscript' command

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

At first sight, this sounds like a bug. I don't know if it is worth to
fix it, because there is a workaround, but it is useful to file
a bug report anyway. Then maybe more people can comment
on it, you can follow the eventual fix, and more people can
put comments there.

2008/12/13 T. Horsnell <ts...@mr...>:
> The FreeSans from the script has been changed to Freesans in the
> postscript file and Ghostscript cant then find the font.

The .c postscript command has an option -fontmap. According to
the manual (see below), Tk's guessing only works for well-known
fonts. Currently (at least since Tk 8.1), Tk capitalizes the first
character and changes all others to lowercase in this case. Your
problem might be a good excuse to change that behavior. Maybe
others can provide more ideas? Anyone else has an idea what's
the reason to change all other characters to lowercase? It's
easy to change that in the core, but I don't know what other
effects that would have.......

Regards,
            Jan Nijtmans

=================================================
-fontmap varName
VarName must be the name of an array variable that specifies a font
mapping to use in
the Postscript. Each element of varName must consist of a Tcl list
with two elements,
which are the name and point size of a Postscript font. When
outputting Postscript
commands for a particular font, Tk checks to see if varName contains
an element with
the same name as the font. If there is such an element, then the font
information
contained in that element is used in the Postscript. Otherwise Tk
attempts to guess
what Postscript font to use. Tk's guesses generally only work for
well-known fonts
such as Times and Helvetica and Courier, and only if the X font name
does not omit
any dashes up through the point size. For example,
-*-Courier-Bold-R-Normal--*-120-*
will work but *Courier-Bold-R-Normal*120* will not; Tk needs the
dashes to parse the font name).

[TCLCORE] Rationale for non-strict [binary decode]

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

Hi,

While looking at
http://sourceforge.net/tracker/index.php?func=detail&aid=2380293&group_id=10894&atid=110894
I discovered that [binary decode], for all three supported encodings
(hex, base64 and uuencode), had a "-strict" option, meaning the
default was non-strict: characters outside the expected range are just
ignored.

Question: what is the rationale for such "robustness" ?
Is there a known perturbation process that is modelled this way, which
would insert exclusively out-of-range chars ?

Otherwise, it seems _very_ dangerous to ignore such errors (an
insertion/deletion in any of the three schemes, especially the two
6bit-based, has catastrophic long-range effects).
Moreover, in situations where such a "controlled perturbation" is
expected, it is trivial for the programmer to apply a [regsub] first,
to filter out the offending characters.

What about removing the non-strict pathway entirely ?

-Alex

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

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

Joe English <jen...@fl...> wrote:
> Andreas Leitgeb wrote:
> > 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.
> Specific example:

Twylite already answered my question, and he also gave better reasons
than that one, so I declared my defeat on this topic already. ;-)

> At point (3), you know that $xxx and $opts are set to _something_,
> but you don't know what.  You usually don't care, either.

Without the intention to reopen the discussion, with per handler
variable lists, not only do I not know what a variable really 
contains (error-message or return-value), but also don't know
which variables were actually set in the try.

PS: I'd have called the variable "retval" or just "rv" instead of 
  "xxx"   and would probably do so if an "as ..." clause is ever
  added as optional clause, later.

PPS: most of the cases, I'd place the "on ok"-body right into the
  try-body, so the different interpretation of the variable would
  not be a problem most of the times.

[TCLCORE] canvas 'postscript' command

[T. H. <ts...@mr...>]

Hi, I'm new to tcl, so apologies if this is an inappropriate list
to ask for help.
I have tcl/tk 8.5.2 on Fedora 9, and hav a curious problem using the
'postscript' command on a canvas.

I have a line like:

.c create text 200 200 -text "Hello World" -font {FreeSans 50}

in my tcltk script file, and the text displays with the correct font.

If I dump the cancas window to a file with a line like:

.c postscript -x 0 -y 0 -height $h -width $w -pagewidth 8.0i -pageheight 11.0i -pagex 4.0i -pagey 
5.5i -pageanchor c -file junk2.ps

The postscript file ends up with a line like

/Freesans findfont 50 scalefont ISOEncode setfont


The FreeSans from the script has been changed to Freesans in the
postscript file and Ghostscript cant then find the font.

Short of editing all my (ttf) font files is there a fix for this?


Cheers,
Terry

Re: [TCLCORE] Tk_MainEx: extreme archeology

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

Donald G Porter wrote:
> $ gcc demo.c -L... -l tcl8.5 -l tkstub8.5

Due to the changes surrounding tclStubsPtr in 8.6, the corresponding
build line:

$ gcc demo.c -L... -l tcl8.6 -l tkstub8.6
.../libtkstub8.6.a(tkStubLib.o): In function `Tk_InitStubs':
tkStubLib.c:(.text+0x16): undefined reference to `tclStubsPtr'
tkStubLib.c:(.text+0xfb): undefined reference to `tclStubsPtr'
tkStubLib.c:(.text+0x136): undefined reference to `tclStubsPtr'
tkStubLib.c:(.text+0x174): undefined reference to `tclStubsPtr'
collect2: ld returned 1 exit status

Following revised copy works for all branches:

#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!");
     }
#undef Tcl_InitStubs
     if (Tcl_InitStubs(interp, TCL_VERSION, 1) == NULL) {
         Tcl_Panic("Cannot init Tcl stubs!");
     }
     if (Tk_InitStubs(interp, TK_VERSION, 0) == NULL) {
         Tcl_Panic("Cannot find Tk!");
     }
     Tk_MainEx(argc, argv, appInitProc, interp);
}


The #undef in the middle is less than pretty, and Daniel
Steffen and I have been chatting about how that might be
improved.  May have developments on that during the beta
cycle.

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

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

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

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

Daniel, Don, can you both please have a look at the TIP 339 reference
implementation (339-ri) and check how much of the code implements the
behaviour you are specifying below, and for the parts which don't how
difficult to a change would be ?


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

Yes, that is done in 339-ri

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

Ok, this is not done that way in 339-ri IIRC. That is where the -strict
option came in selecting the match behaviour.

This part would have to change per your spec.


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

This should be in the 339-ri as well ... Actually, not quite. The only
handler which needed a change was for Tcl Modules, and it now considers the
existence of 'Foo' and 'fOO' files as problem, claiming package not found.
Changing that should be not too difficult. Look at the 'FileExists' code, it
has to be expanded to simply track all possible matches instead of aborting
when multiple appear.

The handler for regular packages needed no change because it always does a
full scan of all pkgIndex.tcl files, thus pulling  in all case-variants of
whatever automatically as part of its search for everything.


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

I believe that needs changing in 3390ri as well.


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

good.

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

sounds a bit like dwimmery, however also as explainable, therefore
acceptable to me.

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

sounds good.

Again, are you willing to look over the 339-ri and see what would need
modification ?

All the stuff for -strict would have to be removed, but the data structures
seem to be (partially) salvage-able.

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

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

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

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

Yes. The reference implementation used a second hashtable.

The original table kept all the exact package names as keys.

The second table contained the case-folded form as keys.

Both tables shared the 'struct Package' however.

All packages with the same case-folded form are linked together, the first
in the list is the one used where the TIP specified 'first registered' ...


Note that using a pure-Tcl solution _does not_ prevent us from using a
second table. We can have one, it would just be an array variable.

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

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

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

Andreas Leitgeb wrote:
> 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?

Specific example:

	try {
	    open $filename r
	} on ok {fp} {
	    # ...
	} on error {msg opts} {
	    # ...
	}

(Which was one of the motivating use cases for dispatching
based on return code in the first place.)

With try/as, this would be:

	try {
	    open $filename r
	} as {xxx opts} on ok {
	    # (1) here $xxx is a file channel.
	} on error {
	    # (2) here $xxx is an error message.
	}
	# (3)

For the sake of clarity, I'd want to use different variable
names in the two handler clauses -- "fp" for the case where
the result is a file channel, "msg" for the case where it's
an error message.  (I can't think of a good variable name to
use in the "as" clause.)

At point (3), you know that $xxx and $opts are set to _something_,
but you don't know what.  You usually don't care, either.


--Joe English

  jen...@fl...

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