tcl-core — Tcl Core Team discussions about Tcl development

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

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

2008/12/16 Jan Nijtmans <nij...@us...>:
> The only problem there is left, is that autoMkindex.test crashes, I'm
> still trying to debug that (if someone has a good debugger, I appreciate
> help in tracing this down, somewhere still is a bug).

Found the bug: forgot to check pkgPtr->version != NULL before
trying to ckfree() it....

Uploaded a new patch to:
https://sourceforge.net/tracker2/?func=detail&aid=2432057&group_id=10894&atid=310894
which passes all tests, including a few added ones.

Any feedback is welcome. Is this a valid alternative to TIP #339?

Regards,
      Jan Nijtmans

[TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

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

In 7 places in the core I find calls like:
     (void) Tcl_GetStringResult(interp)
but interp->result is not used afterwards. I'm
refering to tclBasic.c (6) and tclHistory.c (1).

Shouldn't these calls have been removed as part
of the TIP #330 implementation? If extensions
are not allowed any more to access interp->result
directly, then those calss serve no purpose other than
slowing down Tcl. It might break extensions which still
use interp->result, but due to TIP #330, that's exactly
what users of Tcl 8.6 should expect.

Regards,
         Jan Nijtmans

[TCLCORE] [Fwd: TCL CORE TEAM ANNOUNCES: Daniel Steffen named to Tcl Core Team.]

[Kevin K. <kk...@ny...>]

A second attempt at sending this message; the first has not
shown up in over four hours, and I suspect that it went astray.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] [Fwd: TCL CORE TEAM ANNOUNCES: Harrison, Hipp, Ingham, Welch leave Tcl Core Team]

[Kevin K. <kk...@ny...>]

A second attempt at sending this message; the first has not
shown up in over four hours, and I suspect that it went astray.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] TCL CORE TEAM ANNOUNCES: John Ousterhout retires from Tcl Core Team

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

TCL CORE TEAM
SPECIAL RESOLUTION 2008-3

WHEREAS, John K. Ousterhout advises the Tcl Core Team that, in his
opinion, he has not made a significant contribution to Tcl in the last
five years; and further

WHEREAS, Dr. Ousterhout further advises the team that he is confident
that Tcl and the Tk toolkit are in good hands with the current Tcl
Core Team; and further

WHEREAS, Dr. Ousterhout further advises the team that he wishes to be
accounted a Tcl Core Team member emeritus; and further

WHEREAS, it is impossible to give an adequate account of
Dr. Ousterhout's accomplishments as the true "father of Tcl/Tk:" from
overseeing its initial construction in the laboratories at Berkeley,
through overseeing its publicity and recruiting community development,
through its period of commercial development at Sun, Scriptics, and
Ajuba, into the community-maintained system that it is today:
activities for which he richly deserved the ACM Software System Award
that the Association for Computing Machinery granted him in 1997, his
induction as a Fellow of the Association for Computing Machinery in
1994, and his membership in the National Academy of Engineering; and
further

WHEREAS, Dr. Ousterhout is mentioned by name in the fundamental
documents (TIP #0 and TIP #2) defining the Tcl Core Team, and accorded
especial privileges as "Benevolent Dictator" with the ability to
resolve any deadlocks by executive fiat; and further

WHEREAS, the "Benevolent Dictator Clause" has been long regarded by
the Tcl Core Team as an important "safety valve" in its process; and
further

WHEREAS, Dr. Ousterhout's departure will necessitate reonsideration of
that element of the Tcl Core Team's charter;

NOW THEREFORE be it

RESOLVED, that the Tcl Core Team accepts with the profoundest regret
the resignation of Dr. John K. Ousterhout from its ranks, and offers
him heartfelt thanks and admiration for his many years of tireless
service; and be it further

RESOLVED, that Dr. John K. Ousterhout shall be designated

FOUNDER AND MEMBER EMERITUS OF THE TCL CORE TEAM

a title that can be rightfully applied only to him; and further be it

RESOLVED, that the Tcl Core Team do at once commit to a Committee of
the Whole to propose appropriate Amendments to its Constitution and
By-Laws (as set forth in Tcl Improvement Proposals #0 and #2), and
that said Committee of the Whole shall rise and report at such time as
it shall find convenient, but in any event no later than 31 January
2009.

DONE, this fifteenth day of December, 2008

For the Tcl Core Team

Mo DeJong
Joe English
Donal K. Fellows
Jeffrey Hobbs
George A. Howlett
Kevin B. Kenny
Andreas Kupries
Karl Lehenbauer
Jan Nijtmans
John K. Ousterhout, founder and member emeritus
Donald G. Porter
Miguel Sofer
Daniel A. Steffen

[TCLCORE] TCL CORE TEAM ANNOUNCES: Daniel Steffen named to Tcl Core Team.

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

TCL CORE TEAM
Special Resolution 2008-1

WHEREAS, Daniel K. Steffen has been a Tcl maintainer since February of
2003 (and a valued contributor to Tcl development prior to that date);
and further

WHEREAS, Daniel has during that time been among the most active of the
maintainers, tirelessly contributing the unsung work that keeps the
MacOSX version of Tcl going; and further

WHEREAS, the Tcl Core Team recognizes an urgent need for more MacOSX
expertise among its membership; and further

WHEREAS, during his time as a maintainer, Daniel has exhibited
exemplary diligence, technical maturity and judgment; and further

WHEREAS, during his time as a maintainer, Daniel has demonstrated
exemplary teamwork and forged strong relationships with the Tcl Core
Team members; and further

WHEREAS, it is the unanimous sense of the Tcl Core Team that its
deliberations would be enhanced if Daniel were to be included as a member,

NOW THEREFORE, be it

RESOLVED, that Daniel Steffen be invited to join the Tcl Core Team as
a voting member, with all the rights, privileges and duties
appertaining to that position.

DONE, this fifteenth day of December, 2008

For the Tcl Core Team:

Mo DeJong
Joe English
Donal K. Fellows
Mark Harrison
D. Richard Hipp
Jeffrey Hobbs
George A. Howlett
Jim Ingham
Kevin B. Kenny
Andreas Kupries
Karl Lehenbauer
Jan Nijtmans
John K. Ousterhout
Donald G. Porter
Miguel Sofer
Brent Welch

Re: [TCLCORE] canvas 'postscript' command

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

Donal K. Fellows wrote:
> At a guess, this either was part of Tk 4.0 (as far back as I can
> remember there font name tricks being about) or came in with the new
> font system (don't remember when that happened). If memory serves, it is
> needed because font family names can be specified at the script level as
> all lower-case (common with names from XLFDs).
> 
> I'm hesitant to change this code, not because I think what it does is
> right, but rather because I don't have any feeling at all for who and
> what would be affected. Forcing people to use a workaround who
> previously did not need to... that's a good way to get people to accuse
> you of breaking things unnecessarily.

Arguably we missed the boat earlier, but I've long thought that
we *should* have repaired the default font mapping when we upgraded
the [$canvas postscript] command to do %%IncludeResource.
Unfortunately, we didn't get the latter quite right, which is why
font mapping is still needed - or so it appears.  If I recall
correctly, if I have a font in my catalog named,
"Caslon Nº 224 MT" (as in fact I do)... what do I do?

Tk unquestionably does not get this right, but my native system's
word processor somehow manages to find CaslonTwoTwentyFour or
whatever the PS font name is, and get the resources straight.
That's arguably the layer we should be attacking first. If
we can get that, we solve the problem for Windows, MacOSX
and X11+Xft, leaving X11 without Xft the only odd man out.
I'd love to have the "workaround" for the "bug" introduced by not
screwing up the case in the font name be, "oh, just leave out the
-fontmap, the system can figure things out correctly without it."

So, in short, Donal has the right of it (don't break things
gratuitously), but Jan and Alex have a deeper underlying
rightness (it's mostly ok to break things that are already broken
if you can fix them in the process). It's an odd system that
actually still requires font mapping... except that most
PostScript-generating Tk programs do, because we get things
horribly wrong without it.

While we're on this topic, I've another question in my ignorance.
Is there an external way to resolve the %%IncludeResource directives
so that I can embed fonts when it's lawful to do so? It would
be really nice to be able to carry my PostScript over to a
different system and have fonts like Nimbus or Andale Mono
come with it.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] TCL CORE TEAM ANNOUNCES: Harrison, Hopp, Ingham, Welch leave Tcl Core Team

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

TCL CORE TEAM
Special Resolution 2008-2

WHEREAS, Tcl Core Team members Mark Harrison, D. Richard Hipp, Jim
Ingham, and Brent Welch have advised the Tcl Core Team that they no
longer have the time to remain significantly active in the development
of Tcl, and further

WHEREAS, the said Tcl Core team members have advised the Tcl Core
Team that their inactivity implies that they are no longer
sufficiently well informed to cast prudent votes regarding the future
deelopment of Tcl, and further

WHEREAS, former Tcl Core Team member Michael McLennan tendered a
resignation for similar reasons in 2004, and further

WHEREAS, these five Tcl Core Team members have contributed significant
guidance and technical expertise to the Tcl community during their
tenure as Tcl Core Team members, and further

WHEREAS, these five Tcl Core Team members continue to enjoy the
respect and admiration of the Tcl Core Team

NOW THEREFORE, be it

RESOLVED, that Mark Harrison, D. Richard Hipp, Jim Ingham,
Michael McLennan and Brent Welch are designated nonvoting

TCL CORE TEAM MEMBERS EMERITI

and are accorded the thanks of the Tcl Core Team and the Tcl
community and wished all success in their future endeavours.

DONE, this fifteenth day of December, 2008.

For the Tcl Core Team:

Mo DeJong
Joe English
Donal K. Fellows
Mark Harrison, member emeritus
D. Richard Hipp, member emeritus
Jeffrey Hobbs
George A. Howlett
Jim Ingham, member emeritus
Kevin B. Kenny
Andreas Kupries
Karl Lehenbauer
Jan Nijtmans
John K. Ousterhout
Donald G. Porter
Miguel Sofer
Daniel A. Steffen
Brent Welch, member emeritus

[TCLCORE] [Fwd: TCL CORE TEAM ANNOUNCES: John Ousterhout retires from Tcl Core Team]

[Kevin K. <kk...@ny...>]

Trying again, since the last post has been astray for nearly five hours.

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

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

2008/12/12 Jan Nijtmans <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")

I am stubborn enough to experiment with a solution that doesn't need
a second hash table. The collision is prevented by removing the phony
entries as soon as a real entry for the same package name is
encountered. Apart from that, I tried to be as close as possible
to the ideas discussed in this thread.

The resulting patch is available at:
https://sourceforge.net/tracker2/?func=detail&aid=2432057&group_id=10894&atid=310894
but I'll outline the idea here.

The idea is, not trying to make package handling case-insensitive, but
in stead only handle the situation that someone provides a package
"FooBar" and we want to make it available under the name "foobar"
as well. So, "foobar" is a phony package. We do that by changing
"package require FooBar" such that it automatically provides "foobar"
as wel, if it was not provided before. In addition, providing a new
real "foobar" package, where a phony "foobar" was already provided,
no longer is an error, it just ignores the phony package.

The "ifneeded" is changed to work as if
    package ifneeded FooBar $version somescript
automatically does:
    package ifneeded foobar $version [list package require -exact
FooBar $version]
as well. The extra "package provide" (as in Don's original idea) is not
neccesary, because that is handled by the "package provide" which
is already in the loaded package. The nice thing here is that from the
ifneeded script we can immediately see if the package is phony or
not. For phony packages the ifneeded script is always a 5-element
list in which the 4th element is the name of the real package!
That's transparent!

The implementation starts with extending the Package structure with a flag
"real", and extend the FindPackage with an extra "Package **phony" argument.
Every time an entry is created in the hashtable for "FooBar", another
entry "foobar"
is created as well. If the package name is lowercase, FindPackage functions
as before, otherwise the additional phony package is returned as well as
the real package. This function is used in a lot of other places.

Then the changes to "package ifneeded" and "package provide" are rather
streight-forward. The only possible incompatibility is that extra phony
package names can magically apprear and disappear: every time a
real package name might conflict with a phony package, the situation
is handled as if the phony package simply doesn't exist.

The only problem there is left, is that autoMkindex.test crashes, I'm
still trying to debug that (if someone has a good debugger, I appreciate
help in tracing this down, somewhere still is a bug). All other
tests pass, even some additional ones that I wrote (but didn't
include in this patch, I should have done that......).

It's late now, so my apologies if this mail is a little condensed....

Regards,
     Jan Nijtmans

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

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

> ... ascii85 which
> isn't done but should be soon as its becoming used in more protocols now.

Interesting. Can you give us references to protocols doing so ?

In that context I should also note that the encoding used by
tclcompiler/tbcload is a (slightly) modified ascii85.

IIRC a \0 in the input is replaced by a 'z' instead of the regular coding,
and some output characters are remapped to avoid Tcl's special characters
( ", {, }, [, ], $, \ ): (string map {" v $ w [ x ] | \ y} (I have not made
sure of the proper Tcl quoting here)).


> The fix for just ignoring whitespace looks ok to me. I dont remember if
> there was a particular reason for ignoring any invalid characters and in
> the absence of specific tests or comments aboout the issue we may assume
> it is an accident. Ignoring whitespace is definately required.


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

Re: [TCLCORE] TCL CORE TEAM ANNOUNCES: Harrison, *HIPP*, Ingham, Welch leave Tcl Core Team

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

Kevin Kenny wrote:
 > [an announcement with a poorly proofread subject line]

I offer Dr. Hipp my sincere apologies for mistyping his surname.

-- 
73 de ke9tv/2, Kevin

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

[Pat T. <pat...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Firstly - I do this stuff in my spare time. That would be time that I'm
not involved with family or work - so if it takes a couple of days to
get a response that doesnt mean I never answer your mails.

I did the uuencoding purely to facilitate the tcllib implementation
which handles the outer wrapping "begin ... end" and the line length
stuff separately from the encoding of the data. So its been done as a
straight C replacement for the inner part of tcllibs implementation. If
everyone wants to complain about it we can just throw it away entirely -
the only important encodings are base64 and hex and maybe ascii85 which
isn't done but should be soon as its becoming used in more protocols now.

The fix for just ignoring whitespace looks ok to me. I dont remember if
there was a particular reason for ignoring any invalid characters and in
the absence of specific tests or comments aboout the issue we may assume
it is an accident. Ignoring whitespace is definately required.

Pat Thoyts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSUbJ0GB90JXwhOSJAQLnDwP/Ys3fHqLxIeOO51Tmwhlv7CQhc2WNtu+C
jZ9ryoOgxuRQwFyn8+5aMY6EYX7tEJCxP8pSnQbBHSV6hWA097wz/aNyqaM/2i5D
5r3fK/mqhDl9XOE1zxXWaN1fawrIZpq2IdNgTpxUtGFKxwtGVEGz3AndokMA+3Mm
hByV4bLTg8U=
=S+rd
-----END PGP SIGNATURE-----

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

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

After a chat with Kevin I committed a middle ground which only allows
for whitespace in non-strict mode. And fixes the bug by the way.

-Alex


On Mon, Dec 15, 2008 at 4:28 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
> In the absence of any response to this, I am preparing to commit the
> removal of non-strict decoding. Unless somebody objects and argues ;-)
>
> -Alex
>
> On Sat, Dec 13, 2008 at 7:59 PM, Alexandre Ferrieux
> <ale...@gm...> wrote:
>> 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] Rationale for non-strict [binary decode]

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

In the absence of any response to this, I am preparing to commit the
removal of non-strict decoding. Unless somebody objects and argues ;-)

-Alex

On Sat, Dec 13, 2008 at 7:59 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
> 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] canvas 'postscript' : solved

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

Donal K. Fellows wrote:
> 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.

A big thank-you for such rapid help.
Using the -fontmap option has fixed it.

On to the next problem, which I'll put to comp.lang.tcl as suggested.

Cheers,
Terry

Re: [TCLCORE] canvas 'postscript' command

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

Alexandre Ferrieux wrote:
> It sounds valid. My only worry is that this strange lowercasing has
> been in place since the beginning (see comments by 1.1 rjohnson).
> Any idea why ?

At a guess, this either was part of Tk 4.0 (as far back as I can
remember there font name tricks being about) or came in with the new
font system (don't remember when that happened). If memory serves, it is
needed because font family names can be specified at the script level as
all lower-case (common with names from XLFDs).

I'm hesitant to change this code, not because I think what it does is
right, but rather because I don't have any feeling at all for who and
what would be affected. Forcing people to use a workaround who
previously did not need to... that's a good way to get people to accuse
you of breaking things unnecessarily.

Donal.

Re: [TCLCORE] canvas 'postscript' command

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

On Sun, Dec 14, 2008 at 10:17 PM, Jan Nijtmans <jan...@gm...> wrote:
>
> I know that comp.lang.tcl is more appropriate for this question,
> but in this case it's really strange behavior. I would propose
> removing lines 1703 and 1704 from tkFont.c, provided no-one
> comes up with an example where this causes problems. And
> even if it causes a problem in some situation, that can be
> solved with the -fontmap option. Food for more thought.

It sounds valid. My only worry is that this strange lowercasing has
been in place since the beginning (see comments by 1.1 rjohnson).
Any idea why ?

-Alex

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

[Fredderic <mag...@gm...>]

On Fri, 12 Dec 2008 15:39:07 +0200, 
Twylite <tw...@cr...> wrote:

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

That's why one of my earlier renditions had a -withvars type option
BEFORE the main body.  I only revised that to going with the "as"
keyword because people didn't like that option.

You could perhaps borrow a reference to [proc], and format [try] like
this:
    try as {?resVar ?optVar??} {
      ...script...
    } ?handlers ...?
although it _really_ doesn't work with issue #2 below...
I'd quite happily use it.


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

The first part of this point is just pathetic.  The second part,
contextually appropriate naming, has _some_ merit.  Although simply
chosing generic names in the first place like we've always had to do
with [catch] is still better.  If you're really desperate, either [upvar
0] the names within the handler body, or wrap it with [apply] (isn't
there an [invoke] command in the works, also...?  That could well be
applicable here also).


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

That's what [proc] and [apply] are for.  If you implement [try] in the
slightly backwards fashion I described above, then a simple [interp
alias] lets you pre-package standard variable names.

    interp alias {} try-standard {} try as {retvar optvar}

    try-standard {
      ...script...
    } ...handlers...


This reminds me of the handler-in-a-variable idea...
    try {script} $::HANDLER ...

That particular idea trashes the crap out of reason #1 in this list, if
the handler body is included in the variable, how the heck do you
format a bunch of handlers like that cleanly?!?

And while you're at it, if you can't even "adapt" the variable names,
how do you make sure there's no variable name collisions against the
enclosing scope?  That looks like an absolute hornets-nest of trouble
to me.  Better to discourage that and encourage wrapping the handlers
in [proc] or [apply].  Constructing a builder for that wouldn't be hard
at all:

    proc try-handler {args} {
      if { [llength $args] <= 2 } {
        error "wrong # args: should be \"... {retvar optvar} script\""
      }
      set var [lrange $args 0 end-2]
      lappend var [lrange $args end-1 end]
    }


If you wanted to, though, that could be a candidate for a new verb:
    apply $::HANDLER
a list of everything that would normally be there, except that the last
one is a lambda given two arguments.  It'd mash any hope of
compilation, but then I suspect that whole handler-in-a-variable idea
already does that anyhow.

You could conceivably go one step further and have a secondary script
block which is evaluated after the one in the hander package.  The case
of an empty secondary script would rather neatly bridge it to another
line, helping with the uglyness factor.

I wonder what the chances of getting a {@} syntax that causes a
compile-time substitution...  Whatever it preceeds would be evaluated,
substituted, and then compiled in as though it was already there,
fixing whatever value it returned at that time.  Could get a little
strange if the value changes between when the script was specified, and
when it gets compiled, but it'd be useful when used with care.
(Probably about as much chance as {n} as an [lindex ... $n]
alternative...)


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

Who gives a crap, honestly.  Using that as an argument is almost as
pathetic as "oh darnit, I went and forgot what the variable names were".


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

It IS possible if you have the per-handler variables as an option, as I
pointed out ages ago also:  -vars {retvar optvar}

I know you aren't a fan of options, but there's room for them here.
I'd agree with you if the next word after the options could be the name
of a variable.  But when it's a script, and usually a hard-coded one at
that, plus a statement line that's typically going to be fairly short,
it just doesn't make sense to go to such extents simply to avoid them.
The ONLY case where the sentinel option will be needed, is if the
script is supplied by variable and might possibly be a bizarrly named
command taking no arguments.  And in such cases, all reasons against
having a sentinel option really don't matter a whole lot any more.

Basically, with the -vars option, it goes like this; if the "as" verb
is present, use it.  If the -vars option is present, use it also (just
as we would be for the per-handler variables at present).

Heck, you could even have two versions of the -vars option; one which
defines the variables if this exact handler matches, before it gets to
the handler body (and regardless of whether there actually is a body
for this handler or not).  The other effectively pre-pends assigning
the variables, onto the start of the handler body (if combined with the
"-" fall-through body, it would presumably do the assignment then jump
on down to the next body, potentially leaving a whole series of
variables holding the values).

And for those concerned about getting this into production as quickly
as possible, add the "as" verb and handling for the "--" sentinel
option.  The rest can be implemented later, in particular, once you've
figured out just what to do with the per-handler vars, they can be
patched into the current CVS version as options, and brought through in
the next release as an alternative.


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

I believe ages ago I said that's how I expected it'd all work out...


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

Personally, I still reckon attaching the handlers to the end of [catch]
is a perfectly sane option.  But then you know, I'm starting to get the
impression that I'm a little unusual around these parts.


On Fri, 12 Dec 2008 09:39:54 -0800, 
Joe English <jen...@fl...> wrote:

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

How about resp and opts.  I've been using them (well, resp, at least)
with [catch] statements for about as long as I've known been using the
[catch] statement.  In your example, $xxx is the result of evaluating
the main script, whatever that may be.  It's really not that
complicated...

And with both an optional "as" verb, and the per-handler vars (be it a
mandatory argument or a -vars option), then you really can have your
cake and eat it too.


-- 
Fredderic

Before you criticize someone walk a mile in their shoes.
That way, when you criticize them you're a mile away and
you have their shoes.

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 11 days,  8:40)

Re: [TCLCORE] canvas 'postscript' command

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

2008/12/14 Alexandre Ferrieux <ale...@gm...>:
> Why ? The example given was FreeSans -> Freesans; so if we first
> retokenize "FreeSans" as "Free Sans" it does the job.

Currently, three things are done:
1) capitalize first character of each word
2) lowercase all other characters of each word
3) remove spaces

Operation 2) is the one causing trouble. I would suggest leaving out this,
just keeping things as equal as current as possible.
This means that
   "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie"
will change to:
   "Foo Bar BooBoo tWiNkIe" -> "FooBarBooBooTWiNkIe"
That's still a valid Postscript name.

At the time, postscript was invent, truetype didn't exist any more.
Nowadays, ttf fonts can used by both screens and printers, so
any valid ttf font name which can also be a valid postscript font
name (== first character capital, containing no spaces) should
be unchanged. I don't know any problems that would create.

Anyway, it is useful to create a (Tktoolkit) bug report for this,
now that TrueType fonts are more common we can expect
such kind of question more often.

I know that comp.lang.tcl is more appropriate for this question,
but in this case it's really strange behavior. I would propose
removing lines 1703 and 1704 from tkFont.c, provided no-one
comes up with an example where this causes problems. And
even if it causes a problem in some situation, that can be
solved with the -fontmap option. Food for more thought.

Regards,
         Jan Nijtmans

Re: [TCLCORE] canvas 'postscript' command

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

On Sun, Dec 14, 2008 at 12:51 PM, Donal K. Fellows
<don...@ma...> wrote:
>
>> What about special-casing the Sans, Serif and SansSerif suffixes ?
>
> I don't think there's a way to do it nicely. Your suggestion wouldn't
> make things work any better on this system for example.

Why ? The example given was FreeSans -> Freesans; so if we first
retokenize "FreeSans" as "Free Sans" it does the job.

-Alex

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

[Fredderic <mag...@gm...>]

On Fri, 12 Dec 2008 02:08:40 +0200, 
Twylite <tw...@cr...> wrote:

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

Simplest solution: revert the decision about 'as {resultsVar
optionsVar}' in the first place.  Per-handler variables are redundant
and add unnecessary complexity.  Just set them once, they'll be
available to all handler bodies, and the rest of the script from this
point onwards, as anyone would expect.  Simple, no surprised, no corner
cases, and insanely efficient, plus forward-compatible if we ever get
more useful handler matching.


-- 
Fredderic

The cost of living is going up
and the chance of living is going down.
		-- Flip Wilson

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 11 days,  4:16)

Re: [TCLCORE] canvas 'postscript' command

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

Alexandre Ferrieux wrote:
> On Sun, Dec 14, 2008 at 10:05 AM, Donal K. Fellows
> <don...@ma...> wrote:
>>   "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie"
>>
>> That's correct more often than not, but is imperfect.
> 
> What about special-casing the Sans, Serif and SansSerif suffixes ?

I don't think there's a way to do it nicely. Your suggestion wouldn't
make things work any better on this system for example. Maybe if we had
some way to put fallback code in the postscript prolog we could do
better, but I'm not feeling very up to hacking PS at the moment.

Being able to write fractional point sizes would be a reasonable update
though. I think you'd be able to do that with a change to a single file
too...

Donal.

Re: [TCLCORE] canvas 'postscript' command

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

On Sun, Dec 14, 2008 at 10:05 AM, Donal K. Fellows
<don...@ma...> wrote:
>
>   "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie"
>
> That's correct more often than not, but is imperfect.

What about special-casing the Sans, Serif and SansSerif suffixes ?

-Alex

Re: [TCLCORE] canvas 'postscript' command

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

Jan Nijtmans wrote:
> 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.......

Postscript font names have to be PS symbols, so no spaces (and a lot of
other restrictions too). The font guesser title-cases each word — you
were probably testing with single-word font names — in the font name and
concatenates them:

   "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie"

That's correct more often than not, but is imperfect.

Donal.