tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #340: Const Qualification of Tcl_SetResult's Argument and -Wwrite-strings

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

"Jan Nijtmans" <nij...@us...> wrote:
> The patch for TIP #340 is available now, and the description of the
> TIP is updated:
>     http://sourceforge.net/tracker/index.php?func=detail&aid=2315890&group_id=10894&atid=310894

I think a mention of Tcl_SetObjResult (or other alternatives) should
be added to the Deprecation-block. One could argue that the referral
to the TIP covers it, but I still think it would be a good thing to
have that piece of information immediately at hand without having to
look up the TIP.

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

[Andreas K. <aku...@sh...>]

> >> For non-interactive use the same would fail, but the error message
> >> could be extended with a hint about availiable near-matches:
> >>
> >> can't find package tk (perhaps you meant Tk)
 
> That's not the way the [package require] implementation makes use of
> the [package unknown] handler.
 
> As written, [package require tk $requirement] will pass along
> arguments "tk" and $requirement (if any) to the [package unknown]
> handler.  The contract is that the [package unknown] handler should
> find packages that match what it was told to look for.  If it wants,
> it can look for other things too and the default one does, but that
> has not been required.

Yes. And a big thank you for reminding me of this, as I am currently
not adressing this in the TIP at all, and will have to.

> So, either we would need to change the contract so that [package
> unknown] handlers are expected to search for matching packages of
> all cases variations, causing some existing [package unknown]
> handlers to become "broken" according to the new standard,

I believe I am prefering this over the proposal below.

> or [package require] would need to iterate over all the case
> variations and call the [package unknown] handler again and again
> until at least something satisfying the requirement appeared, or
> possibly until all cases were covered.

Eh ... n characters, two cases => 2^n possibilities. No. Not liking
this at all.


Changing the contract ... The standard unknown handler needs no
changes, as it inserts everything it finds into the database. The TM
handler on the other hand will need modifications, as glob is
case-sensitive. Well, maybe not on Windows.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

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

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

>> For non-interactive use the same would fail, but the error message
>> could be extended with a hint about availiable near-matches:
>>
>> can't find package tk (perhaps you meant Tk)

That's not the way the [package require] implementation
makes use of the [package unknown] handler.

As written, [package require tk $requirement] will pass
along arguments "tk" and $requirement (if any) to the
[package unknown] handler.  The contract is that the
[package unknown] handler should find packages that
match what it was told to look for.  If it wants, it can
look for other things too and the default one does, but
that has not been required.

So, either we would need to change the contract so that
[package unknown] handlers are expected to search
for matching packages of all cases variations, causing
some existing [package unknown] handlers to become
"broken" according to the new standard, or [package require]
would need to iterate over all the case variations and
call the [package unknown] handler again and again until
at least something satisfying the requirement appeared, or
possibly until all cases were covered.

DGP

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

[Michael S. <sc...@un...>]

Am 18.11.2008 um 19:57 schrieb Donald Arseneau:

> Koen Danckaert <ko...@re...> writes:
>
>> Isn't it so that this "burden" for the user only (or mainly) exists  
>> in interactive mode?
>
> Hey!  I like this thought!  Just like the interactive unknown handler,
> it could kick in only after the exact package is not found.  It could
> also output a helpful notice like
>
> can't find package Bwidget, but BWidget loaded instead
>
> For non-interactive use the same would fail, but the error message
> could be extended with a hint about availiable near-matches:
>
> can't find package tk (perhaps you meant Tk)

And packagers like SUSE, debian or others could provide an customized  
option to
e.g. check the rpm/deb/teapot repositories for that package.

Michael

Re: [TCLCORE] TIP #340: Const Qualification of Tcl_SetResult's Argument and -Wwrite-strings

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

The patch for TIP #340 is available now, and the description of the
TIP is updated:

    http://sourceforge.net/tracker/index.php?func=detail&aid=2315890&group_id=10894&atid=310894

It contains a solution now for the 'const problem': deprecate Tcl_SetResult for
other values than TCL_STATIC and TCL_VOLATILE. This is a reachable goal, much
more than deprecate all uses of Tcl_SetResult. Actually, I already eliminated
all 'unsafe' Tcl_SetResult calls in Tcl and Tk (except for two in tclTest.c, but
those are meant to test the Tcl_SetResult function by itself).

So, fire away with all remarks, especially about the suggested documentation
change in doc/SetResult.3

Regards,
          Jan Nijtmans

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

[<lm...@bi...>]

On Wed, Nov 19, 2008 at 11:24:26AM -0800, Joe English wrote:
> 
> Neil Madden wrote:
> > Donal K. Fellows wrote:
> > > Neil Madden wrote:
> > >> I'd leave out entirely the glob-matching on errorCode, and let
> > >> people do
> > >> this with [switch] if they want it:
> > > No. That's advocating a lack of vision. If we make it *easy* to trap
> > > specific errors by errcode, people will do so. People don't now
> > > because
> > > it is too hard.
> >
> > I just don't see any evidence for this statement (the use-cases will
> > follow if we just implement this!).
> 
> There has been a longstanding desire that people [*] make
> better use of -errorcode, but there's a vicious cycle:
> nobody bothers to use meaningful -errorcodes because nobody
> bothers to check -errorcode because there's no convenient
> way to do so.

Yeah, heaven forbid that there be a concept of NULL in tcl that could be
trivially used to indicate EOF/ERROR/whatever.  Much better to introduce
language constructs (that will probably get used about as much as -errorcode).
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Neil Madden wrote:
> Donal K. Fellows wrote:
> > Neil Madden wrote:
> >> I'd leave out entirely the glob-matching on errorCode, and let
> >> people do
> >> this with [switch] if they want it:
> > No. That's advocating a lack of vision. If we make it *easy* to trap
> > specific errors by errcode, people will do so. People don't now
> > because
> > it is too hard.
>
> I just don't see any evidence for this statement (the use-cases will
> follow if we just implement this!).

There has been a longstanding desire that people [*] make
better use of -errorcode, but there's a vicious cycle:
nobody bothers to use meaningful -errorcodes because nobody
bothers to check -errorcode because there's no convenient
way to do so.

try/onerror would at least break that part of the cycle.

(FWIW, I don't think try/onerror will be immediately useful either,
and am not sure that it will _ever_ be useful -- perhaps meaningful
-errorcodes wouldn't be that helpful even if we did have them --
but it's worth a try.)


--Joe English


[*] and by "people" I mean "including core maintainers",
and by "including core maintainers" I mean "especially".

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Donal K. Fellows wrote:
> Twylite wrote:
> > [...]
> > As currently specified you would use "onerror {glob ?emvar? ?optsvar?}",
> > but if you omit emvar/optsvar then you have no access to this
> > information within that handler.
> Sounds acceptable to me. If people want the info, they'll capture it.
> OTOH, they might be quite happy without. [...]

> The only real question is whether
> the msgvar and optvar should be that way round. Pass on that! :-)

Yes, they are in the right order.

[ ... ]

> >>> A modification I find particularly interesting is an alternative
> >>> approach to finally.
> >> I don't like that nearly as much, FWIW.
> > I'd be interested in reasons/insight?
>
> It doesn't feel right. Yeah, I know that's not the strongest of points,
> but I think it's probably based on the fact that most users^Wprogrammers
> are *very* confused by the whole idea of out-of-order execution. They
> find [after] and [fileevent] difficult. [bind] too. :-\

I don't like the alternative approach much either,
simply because it smells too much like innovation.

try/finally as currently proposed is well-established
in other languages and is known to work well.  The
alternative approach certainly sounds interesting
and is probably worth pursuing, but *not for this TIP*.

I want to see this in 8.6.  Now is not the time to
invent brand new untested control flow constructs.


--Joe English

[TCLCORE] TIP#239 Try/Catch/Finally syntax [WAS Re: Tcl-Core Digest, Vol 30, Issue 10]

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

Twylite wrote:
> >> >    TIP #329	Try/Catch/Finally syntax
> > I'd really like to see this in 8.6.  However, I also think
> > it's essential that try/catch be able to dispatch based on
> > the return code, not just $::errorCode, which the current
> > specification does not provide for.  Please fix!
> >
> Although I haven't updated the spec, the current proposal is:
>   try {
>     #code
>   } then {
>     #success continuation
>   } onerror {glob emvar optsvar} {
>     #handle errors based on errorCode
>   } except {spec emvar optsvar} {
>     #handle errors based on any matching information in optsvar
>   } finally {
>     #always execute this as the last action before leaving the try command
>   }
>
> The "except" clause will handle exceptions (non-zero Tcl return code) as
> opposed to errors (Tcl return code TCL_ERROR with dispatch based on
> errorCode).  Not certain on what the "spec" in the except clause is
> going to look like though.  Suggestions welcome (via e-mail or to
> http://wiki.tcl.tk/21608).


I would suggest:

	try {
	    ...
	} onerror {pattern ?resultVar ?optionsVar??} {
	    #
	    # return code was TCL_ERROR, errorCode matches $pattern
	    #
	} handle {code ?resultVar ?optionsVar??} {
	    #
	    # return code was $code.
	    #
	} finally {
	    ...
	}

where "code" is one of ok/error/return/break/continue
or an integer literal, a la [return -code].

If a "then" clause is desired, then

    try { # script... } then { # success continuation.. }

would be a synonym for

    try { # script... } handle ok { # success continuation ... }

although I suspect a more common usage pattern would look like:

	try {
	    open $filename "w"
	} handle {ok fp} {
	    try {
	    	# ... write to $fp
	    } finally {
		close $fp
	    }
	} onerror {{POSIX EACCESS *}} {
	    # ...
	} handle {error msg} {
	    report "Unrecognized error: $msg"
	}

> I still have concerns about this though:
> - The construct is getting pretty bulky - is it really adding power &
> simplicity as it is intended to do?

Yes.  Dispatching based on the return code is essential
for creating user-defined control structures.

> [...]
> A modification I find particularly interesting is an alternative
> approach to finally.  The current approach - while typical for try/catch
> syntax - is often a source of subtle bugs.  It is common for a finally
> to have to check each resource before cleaning it up (and equally common
> for checks to be missed or assumptions made ... e.g. if { $somevar ne {}
> } { # cleanup } but an exception was thrown before somevar was set.
>
> A nested try/then/finally may go some way to address this situation, [...]

I believe so.  Nested try/finally clauses -- one for each
resource that needs to be cleaned up -- all wrapped in
an outer try/catch for error recovery would cover
all the exception handling needs I can think of.

--Joe English

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

[Neil M. <ne...@Cs...>]

On 19 Nov 2008, at 16:38, Donal K. Fellows wrote:

> Neil Madden wrote:
>> Firstly, "onerror" and "except" seem like bad names to me.  
>> "except" in
>> particular would imply that the following error case *isn't*  
>> handled (as
>> in "catch everything *except* for these..."), which is just  
>> confusing. I also have some problems with the usage. I'd prefer to  
>> see something like:
>
> I'm going to disagree with you...
>
>>      } else {
>>         ...
>>      } catch error {vars...} {
>>         ...
>>      } catch continue {...} {
>>         ...
>>      } catch -1200 {...} {
>>         ...
>
> Those 'catch' clauses cause me problems. You seem to me to be  
> wanting to
> make a single clause for catching all errors, but to me one of the  
> main
> points about [try] is that it gets away from that. It's a main point
> because it makes a real difference for elevating code above the  
> level of
> the current [catch] capabilities. Right now, doing code to handle
> different errors with [catch] is fairly ugly (though easier than  
> before
> TIP#90) and your proposal doesn't help that much. Twylite's  
> proposal is
> more workable, as it matches errors against the errorcode and  
> everything
> else against the result code (I suppose we could allow a * for  
> anything
> in the spec part of the 'except' matcher, but it's not clear to me why
> you'd want to).

Show me the use-cases! Handling different error-cases with [catch] is  
not that ugly now:

     catch { $script } msg opts
     switch -glob [dict get $opts -errorcode] {
         ... { ... }
         ... { ... }
         default { return -options $opts $msg }
     }

People don't do it because it just isn't very useful. Errors in Tcl  
tend to be real errors -- other than logging them, there is often not  
much to do. Tcl's introspection, use of general control exceptions  
like [continue]/[break], and custom control structures/HOFs etc make  
this kind of exception-based case analysis much less necessary. I may  
well be wrong about this, but I'd prefer to see some concrete use-cases.

>
>> (I'm happy to use "on" or "handle" instead of "catch").
>
> That's more of a bikeshed issue.
>
>> Certainly, I think dispatch based on the return code/exception type
>> should be at least as easy as based on errorCode -- I can think of  
>> lots
>> of examples of Tcl code that does this, but almost none that actually
>> looks at errorCode. You might think that is unfortunate, and that it
>> would be better if more people made use of errorCode, but that's  
>> the way
>> it is.
>
> That's why 'onerror' and 'except' clauses are both needed. (The names
> could be better, but arguing syntax when the semantics still need  
> fixing
> is wasteful.)
>
>> Support for existing, widely-used idioms, should be as much, if
>> not more, important than promoting lesser-used alternatives. In fact,
>> I'd leave out entirely the glob-matching on errorCode, and let  
>> people do
>> this with [switch] if they want it:
>
> No. That's advocating a lack of vision. If we make it *easy* to trap
> specific errors by errcode, people will do so. People don't now  
> because
> it is too hard.

I just don't see any evidence for this statement (the use-cases will  
follow if we just implement this!).

>
>> To me, this strikes a good balance between flexibility and  
>> simplicity.
>> In particular, it leaves pattern matching to existing commands  
>> [switch],
>> [regexp] and so on. So, for instance we won't down the line have  
>> people
>> asking for catch -regexp or catch -nocase and so on (which would  
>> almost
>> certainly happen if errorCode usage does take on).
>
> What is proposed can still permit such things with an enclosed  
> [switch]
> as they can still match all errorcodes with *, but it should encourage
> people to make better use of what we've got.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Neil Madden wrote:
> Firstly, "onerror" and "except" seem like bad names to me. "except" in
> particular would imply that the following error case *isn't* handled (as
> in "catch everything *except* for these..."), which is just confusing. I 
> also have some problems with the usage. I'd prefer to see something like:

I'm going to disagree with you...

>      } else {
>         ...
>      } catch error {vars...} {
>         ...
>      } catch continue {...} {
>         ...
>      } catch -1200 {...} {
>         ...

Those 'catch' clauses cause me problems. You seem to me to be wanting to
make a single clause for catching all errors, but to me one of the main
points about [try] is that it gets away from that. It's a main point
because it makes a real difference for elevating code above the level of
the current [catch] capabilities. Right now, doing code to handle
different errors with [catch] is fairly ugly (though easier than before
TIP#90) and your proposal doesn't help that much. Twylite's proposal is
more workable, as it matches errors against the errorcode and everything
else against the result code (I suppose we could allow a * for anything
in the spec part of the 'except' matcher, but it's not clear to me why
you'd want to).

> (I'm happy to use "on" or "handle" instead of "catch").

That's more of a bikeshed issue.

> Certainly, I think dispatch based on the return code/exception type
> should be at least as easy as based on errorCode -- I can think of lots
> of examples of Tcl code that does this, but almost none that actually
> looks at errorCode. You might think that is unfortunate, and that it
> would be better if more people made use of errorCode, but that's the way
> it is.

That's why 'onerror' and 'except' clauses are both needed. (The names
could be better, but arguing syntax when the semantics still need fixing
is wasteful.)

> Support for existing, widely-used idioms, should be as much, if
> not more, important than promoting lesser-used alternatives. In fact,
> I'd leave out entirely the glob-matching on errorCode, and let people do
> this with [switch] if they want it:

No. That's advocating a lack of vision. If we make it *easy* to trap
specific errors by errcode, people will do so. People don't now because
it is too hard.

> To me, this strikes a good balance between flexibility and simplicity.
> In particular, it leaves pattern matching to existing commands [switch],
> [regexp] and so on. So, for instance we won't down the line have people
> asking for catch -regexp or catch -nocase and so on (which would almost
> certainly happen if errorCode usage does take on).

What is proposed can still permit such things with an enclosed [switch]
as they can still match all errorcodes with *, but it should encourage
people to make better use of what we've got.

Donal.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

[Neil M. <ne...@Cs...>]

Twylite wrote:
> Hi,
>>>>    TIP #329	Try/Catch/Finally syntax
>>>     
>> I'd really like to see this in 8.6.  However, I also think
>> it's essential that try/catch be able to dispatch based on
>> the return code, not just $::errorCode, which the current
>> specification does not provide for.  Please fix!
>>   
> Although I haven't updated the spec, the current proposal is:
>   try {
>     #code
>   } then {
>     #success continuation
>   } onerror {glob emvar optsvar} {
>     #handle errors based on errorCode
>   } except {spec emvar optsvar} {
>     #handle errors based on any matching information in optsvar
>   } finally {
>     #always execute this as the last action before leaving the try command
>   }

Firstly, "onerror" and "except" seem like bad names to me. "except" in
particular would imply that the following error case *isn't* handled (as
in "catch everything *except* for these..."), which is just confusing. I 
also have some problems with the usage. I'd prefer to see something like:

     try {
        ...
     } then {
        ...
     } else {
        ...
     } catch error {vars...} {
        ...
     } catch continue {...} {
        ...
     } catch -1200 {...} {
        ...
     } finally {
        ...
     }

(I'm happy to use "on" or "handle" instead of "catch").

The syntax of the catch part would be: catch "?exception-type? vars
script", where exception-type is a non-empty *list* of "error", 
"continue", "break", "return", "ok", or numeric return codes. It 
defaults to "error". The vars part is just "msgVar ?optsVar?". You must 
specify the vars even if not used (e.g. catch continue {} { .. }) to 
avoid ambiguity (an alternative would be to make the vars optional and 
the exception type mandatory). Note that in this scheme "then" is just 
sugar for "catch ok". "else" is a catch-all, and is invoked if no other 
catch block matches the return code.

Certainly, I think dispatch based on the return code/exception type
should be at least as easy as based on errorCode -- I can think of lots
of examples of Tcl code that does this, but almost none that actually
looks at errorCode. You might think that is unfortunate, and that it
would be better if more people made use of errorCode, but that's the way
it is. Support for existing, widely-used idioms, should be as much, if
not more, important than promoting lesser-used alternatives. In fact,
I'd leave out entirely the glob-matching on errorCode, and let people do
this with [switch] if they want it:

     try {
        ...
     } catch error {msg opts} {
        switch -glob [dict get $opts -errorcode] {
            {FOO *} { ... }
            default { ... }
        }
     } finally { ... }

To me, this strikes a good balance between flexibility and simplicity.
In particular, it leaves pattern matching to existing commands [switch],
[regexp] and so on. So, for instance we won't down the line have people
asking for catch -regexp or catch -nocase and so on (which would almost
certainly happen if errorCode usage does take on).

Off the top of my head, the following is a sketch implementation (only 
partially tested):

proc try {script args} {
     set finally [from args finally ""]
     set else [from args else ""]
     set then [from args then ""]
     set handlers [dict create 0 [list _ $then]]
     foreach h [lsplit $args "catch"] {
         if {[llength $h] ni {2 3}} { error "wrong # args: $h" }
         if {[llength $h] == 2} { set h [linsert $h 0 error] }
         lassign $h types vars body
         foreach type $types {
             dict set handlers [returncode $type] [list $vars $body]
         }
     }
     set rc [catch { uplevel 1 $script } msg opts]
     if {[dict exists $handlers $rc]} {
         lassign [dict get $handlers $rc] vars body
         lassign $vars msgVar optsVar
         upvar 1 $msgVar cmsg $optsVar copts
         set cmsg $msg; set copts $opts
         catch { uplevel 1 $body } msg opts
     } elseif {$else ne ""} {
         if {[catch { uplevel 1 $else } emsg eopts]} {
             set msg $emsg; set opts $eopts
         }
     }
     uplevel 1 $finally
     dict incr opts -level
     return -options $opts $msg
}

(Utility procs at end of this message [*]).

This allows use-cases like:

# Ensure that a channel is closed after use:
# using fd [open $myfile] { puts [read $myfile] }
proc using {varName chan body} {
     upvar 1 $varName var
     set var $chan
     try { uplevel 1 $body } finally { close $chan }
}
proc readfile file { using c [open $file] { return [read $c] } }
# Sugar for db transactions
proc transaction {db body} {
     $db start transaction
     try {
         uplevel 1 $body
     } catch {ok continue return} {msg opts} {
         $db commit
         return -options $opts $msg
     } else {
         $db abort
     }
}
# Version of [dict with] that only updates the dict on success
proc atomic-with {dictVar body} {
     upvar 1 $dictVar dict
     set env $dict
     try { dict with env $body } then { set dict $env }
}
# Mutex locking
proc lock {mutex script} {
     thread::mutex lock $mutex
     try { uplevel 1 $script } finally { thread::mutex unlock $mutex }
}
# Loop through each line of a file
proc foreach-line {lineVar file body} {
     upvar 1 $lineVar line
     using chan [open $file] {
         while {[gets $chan line] >= 0} {
             try { uplevel 1 $body } catch msg { puts "ERROR: $msg" }
         }
     }
}

Note that these do the Right Thing with regard to most exceptions. In 
particular, note that [try] is transparent wrt exceptions it doesn't 
catch -- i.e. [try { $script }] is equivalent to $script. For example, 
the foreach-line proc only catches errors, so break/continue are 
propagated as normal:

  foreach-line line foo.txt {
      if {[incr i] % 2 == 0} { continue }
      puts $line
  }

To me, these are the compelling use-cases for a try construct. errorCode 
matching seems less generally useful.

----
[*] Utility procs:

proc from {listVar option {default ""}} {
     upvar 1 $listVar list
     set idx [lsearch -exact $list $option]
     if {$idx >= 0} {
         set default [lindex $list [expr {$idx+1}]]
         set list [lreplace $list $idx [incr idx]]
     }
     return $default
}
proc lsplit {xs delim} {
     set ys [list]
     set y [list]
     foreach x [lappend xs $delim] {
         if {$x eq $delim} {
             if {[llength $y]} { lappend ys $y; set y [list] }
         } else { lappend y $x }
     }
     return $ys
}
proc returncode code {
     if {[string is integer -strict $code]} { return $code }
     return [lsearch -exact {ok error return break continue} $code]
}


-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

[Hemang L. <hl...@ci...>]

Koen Danckaert wrote:
> Andreas Kupries wrote:
>   
>>  TIP #339: CASE-INSENSITIVE PACKAGE NAMES 
>>     
>
>   
>>  The package management facilities of Tcl are an area where the user of 
>>  packages is currently burdened with more ... than is convenient or 
>>  easy. A big problem is that Tcl compares package names 
>>  case-sensitively. This means that /Expect/ and /expect/ are two 
>>  different things to Tcl. In the real world however having two packages 
>>  using the same name but different capitalization is extremely rare. 
>>     
>
> Isn't it so that this "burden" for the user only (or mainly) exists in interactive mode?
>   
No, that's not the only/primary reason.

Many of our users are not tcl-savvy and they often show preference to 
use other lauguages such as perl, python, java, etc. So, in an effort to 
make it easier for our users (every little bit counts), our developers 
started introducing hacks in pkgIndex.tcl file to support both styles of 
package names such as Foo and foo. Users no longer had to worry about 
the exact case of the package name to use when writing scripts.

This approached has worked well for us until we started looking at Tcl 
Modules and teapot system for package delivery. We now have to start 
building two TM files for each new package release. Moreover, TIP189 has 
clearly stated that two packages with different cases are not allowed:

------ Quote from http://www.tcl.tk/cgi-bin/tct/tip/189.html, section 
"Provide and Index scripts"

/Note/ that we are here creating a connection between package names and 
paths. Tcl is case-sensitive when it comes to comparing package names, 
but there are filesystems which are not, like NTFS. Luckily these 
filesystems do store the case of the name, despite not using the 
information when comparing.

Given the above we allow the names for packages in Tcl modules to have 
mixed-case, but also require that there are no collisions when comparing 
names in a case-insensitive manner. In other words, if a package 'Foo' 
is deployed in the form of a Tcl Module, packages like 'foo', 'fOo', 
etc. are not allowed anymore.
-----

Others have also expressed interest in this feature in the past:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/1192d84e4957e0ae/0d81653d0080142e?lnk=gst&q=package+case+insensitive#0d81653d0080142e

I believe that this tip makes it easier for everyone to use during 
coding, interactive use or teapot use. One downside is that there may be 
few packages out there (3 for Joe, 1 for our group) which collide with  
case sensitive package names found in tcllib and those package names may 
have to be changed.

Thanks,
Hemang.

Re: [TCLCORE] TIP Roundup

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

Joe English wrote:
> Donal K. Fellows wrote:
> 
>> I've got a list of all the open TIPs that can target 8.6 still here.
>> [...]
>> High Priority and demanding of real effort:
>>    TIP #180	Add a Megawidget Support Core Package
> 
> Same as before: publish this as an extension first, let it
> cook for a while as people use it, and if it ends up being
> useful *then* decide whether to integrate it into the core.

I'm talking to Damon about this out-of-band. (Timezone differences slow
communication a bit, but I think we're making good progress. There's a
fair chance that it will end up as a pure Tcl package.)

> Remember TIP#48!

And the Alamo too!

>>    TIP #197	Text Widget Persistant Cursor
> 
> I still don't understand the motivation behind this one.

On Win and OSX, the cursor doesn't show when the focus isn't in the text
widget. This is correct *most* of the time, but not always. For example,
when you're using a full text editor, it can be very useful to see where
you are working even when the focus is elsewhere. I'm not quite sure
whether there's enough control over the look of the non-focus cursor,
but that's a separate thing.

>>    TIP #210	Add 'tempname' Subcommand to 'file'
> 
> Same as before: change the order of the arguments from
> 
> 	file tempfile ?template? ?namevar?
> to
> 	file tempfile ?namevar? ?template?
> 
> and it's good to go.  As currently specified, it forces callers
> to supply a template if they want to get the filename back.
> One of the main points of the TIP is for Tcl to take care
> of all the hairy platform-specific details of where temp files
> should go; the propsed interface defeats that.

Sounds good to me.

Donal.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Twylite wrote:
> OTOH I've had a stab at writing the synopsis line for the man page, and 
> the bulkiness/complexity is not funny.

Can't be helped. It's not as bad as [lsearch] or [canvas]...

> As currently specified you would use "onerror {glob ?emvar? ?optsvar?}", 
> but if you omit emvar/optsvar then you have no access to this 
> information within that handler.

Sounds acceptable to me. If people want the info, they'll capture it.
OTOH, they might be quite happy without. (For example, if trapping a
particular POSIX error from [open].) The only real question is whether
the msgvar and optvar should be that way round. Pass on that! :-)

>>> - Often information about an error is implied in the result (as in 
>>> Tcl_SetResult) rather than an errorCode -- can except (or some other 
>>> clause) adequately handle this case?
>> Wrong question. The right question is "should it handle the case?" and I
>> think the answer is "no". Let's clean up the problems with critical info
>> not going into the errorcode instead (and I know that might take a bit).
> The problem with that approach is that it forces a workaround (via 
> 'catch' or an 'except' handler) when integrating with legacy 
> code/components that are naughty.

Can't be helped. If one bends over backwards too far, one falls over and
fail to achieve one's goals. I think this is one of those times...

>>> A modification I find particularly interesting is an alternative 
>>> approach to finally.
>> I don't like that nearly as much, FWIW.
> I'd be interested in reasons/insight?

It doesn't feel right. Yeah, I know that's not the strongest of points,
but I think it's probably based on the fact that most users^Wprogrammers
are *very* confused by the whole idea of out-of-order execution. They
find [after] and [fileevent] difficult. [bind] too. :-\

Donal.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Hi,
>> I still have concerns about this though:
>> - The construct is getting pretty bulky - is it really adding power & 
>> simplicity as it is intended to do?
> Why are you using all of it at once? That's its most bulky case. (It's
> also something that's quite a PITA to write with just [catch], speaking
> as someone who's done that in the past...)
Fair point.  In most cases only a subset of the full functionality will 
be used.
OTOH I've had a stab at writing the synopsis line for the man page, and 
the bulkiness/complexity is not funny.

>> - The "except" clause needs to be flexible enough to handle the 
>> expected common use cases, but not so flexible/complex that it's 
>> easier to just use catch.  There is little clarity on what the 
>> "common use cases" are.
> So long as we can do multiple 'onerror' clauses and can omit the capture
> variables, we'll be OK. (The errorinfo and errorcode can be picked out
> of the options.) For the 'except' clause, it's probably only necessary
As currently specified you would use "onerror {glob ?emvar? ?optsvar?}", 
but if you omit emvar/optsvar then you have no access to this 
information within that handler.
> The other thing is that the various trap clauses should be arbitrarily 
> reorderable.
They are.  The syntax is "try /script/ ?handler? ?handler ...? ?finally 
body?" where handler is one of:
  then body
  onerror {glob ?emvar? ?optsvar?} body
  except {spec ?emvar? ?optsvar?} body
There can only be one 'then' handler.  Handlers are searched in order 
(left-to-right) until a matching one is found, and that one is 
executed.  Following handler executing the finally body (if any) is 
executed.  The 'finally' clause can be placed in any position where a 
handler is valid/expected (it doesn't have to be at the end).
>> - Often information about an error is implied in the result (as in 
>> Tcl_SetResult) rather than an errorCode -- can except (or some other 
>> clause) adequately handle this case?
> Wrong question. The right question is "should it handle the case?" and I
> think the answer is "no". Let's clean up the problems with critical info
> not going into the errorcode instead (and I know that might take a bit).
The problem with that approach is that it forces a workaround (via 
'catch' or an 'except' handler) when integrating with legacy 
code/components that are naughty.
>> A modification I find particularly interesting is an alternative 
>> approach to finally.
> I don't like that nearly as much, FWIW.
I'd be interested in reasons/insight?

Regards,
Twylite

Re: [TCLCORE] TIP Roundup (162)

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

David Gravereaux wrote:
> 1) real async multi-protocol (IP/dns,IPX/SAP,IrDA/IAS,AppleTalk,etc..)
> name resolver with support for all three types: static, dynamic and
> persistent resolution systems.

I think that's going far more complex. Just TCP over IP/IPv6 with
standard name resolution (async if you can manage it) would be good.
Yes, it's a limited ambition. It's also much easier to get it all
specced up and voted through by Don Porter's deadline. :-)

Remember, the broad strategy is to keep Tcl 8.6 on track for a Spring
2009 final release. We took far too long with both 8.4 and 8.5...

> Maybe fix Tcl_PosixError(), or the error message calls around it, so it
> can support the errors found in netdb.h so we can get back meaningful
> error messages that can distinguish HOST_NOT_FOUND from TRY_AGAIN
> instead of the current meaningless EINVAL.

That I approve of; isn't it TIP#281 (another of the high prio ones)?

> 2) A plugin system for extensions to insert new protocols at run-time or
> internally when compiled in.
> 
> 3) Allow for calls such as the following:
>    socket 3ffe:b80:185d:1::29 ftp
>    socket -protocol spx FEDCBA98.1A2B3C5D7E9F 0453
> 
> When the IPX/SPX module has been installed -^

These things are probably complex enough that they need to be postponed
until 8.7. Let's not hold up the release while waiting for perfection.

> 4) Maybe update the windows channel driver code to use WSAEventSelect()
> with job pooling and get away from the ancient Win 3.1 holdover of
> WSAAsyncSelect()

Is that something that wouldn't appear at the script or API level? If
so, it's pure implementation and doesn't need to be run past the TIP
process. (I forget what our minimum version is, but it's sure quite a
lot later than Win3.1! :-D)

Donal.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Twylite wrote:
> I still have concerns about this though:
> - The construct is getting pretty bulky - is it really adding power & 
> simplicity as it is intended to do?

Why are you using all of it at once? That's its most bulky case. (It's
also something that's quite a PITA to write with just [catch], speaking
as someone who's done that in the past...)

> - The "except" clause needs to be flexible enough to handle the expected 
> common use cases, but not so flexible/complex that it's easier to just 
> use catch.  There is little clarity on what the "common use cases" are.

So long as we can do multiple 'onerror' clauses and can omit the capture
variables, we'll be OK. (The errorinfo and errorcode can be picked out
of the options.) For the 'except' clause, it's probably only necessary
to be able to match the 'code' itself (and optionally capture message
and options, of course) while allowing the normal aliases for 0-4 (i.e. 
ok, error, return, break, continue).

It's possibly a good idea to forbid the trapping of 'ok' and 'error' 
using the 'except' clause; they have their own syntax.

The other thing is that the various trap clauses should be arbitrarily 
reorderable.

> - Often information about an error is implied in the result (as in 
> Tcl_SetResult) rather than an errorCode -- can except (or some other 
> clause) adequately handle this case?

Wrong question. The right question is "should it handle the case?" and I
think the answer is "no". Let's clean up the problems with critical info
not going into the errorcode instead (and I know that might take a bit).

> A modification I find particularly interesting is an alternative 
> approach to finally.
[...]
> Simple example of alternate finally syntax:
> try {
>   set f [open "myfile.txt" r]
>   finally [list close $f] ;# or finally { close $f } since it executes 
> in the context of the block
>   # ...
> }

I don't like that nearly as much, FWIW.

Donal.

Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Hi,
>> >    TIP #329	Try/Catch/Finally syntax
>>     
>
> I'd really like to see this in 8.6.  However, I also think
> it's essential that try/catch be able to dispatch based on
> the return code, not just $::errorCode, which the current
> specification does not provide for.  Please fix!
>   
Although I haven't updated the spec, the current proposal is:
  try {
    #code
  } then {
    #success continuation
  } onerror {glob emvar optsvar} {
    #handle errors based on errorCode
  } except {spec emvar optsvar} {
    #handle errors based on any matching information in optsvar
  } finally {
    #always execute this as the last action before leaving the try command
  }

The "except" clause will handle exceptions (non-zero Tcl return code) as 
opposed to errors (Tcl return code TCL_ERROR with dispatch based on 
errorCode).  Not certain on what the "spec" in the except clause is 
going to look like though.  Suggestions welcome (via e-mail or to 
http://wiki.tcl.tk/21608).

I still have concerns about this though:
- The construct is getting pretty bulky - is it really adding power & 
simplicity as it is intended to do?
- The "except" clause needs to be flexible enough to handle the expected 
common use cases, but not so flexible/complex that it's easier to just 
use catch.  There is little clarity on what the "common use cases" are.
- Often information about an error is implied in the result (as in 
Tcl_SetResult) rather than an errorCode -- can except (or some other 
clause) adequately handle this case?

I'm still investigating the syntax in other languages to what we can 
cherrypick ;)

A modification I find particularly interesting is an alternative 
approach to finally.  The current approach - while typical for try/catch 
syntax - is often a source of subtle bugs.  It is common for a finally 
to have to check each resource before cleaning it up (and equally common 
for checks to be missed or assumptions made ... e.g. if { $somevar ne {} 
} { # cleanup } but an exception was thrown before somevar was set. 

A nested try/then/finally may go some way to address this situation, but 
there are more interesting approaches, e.g. a "finally /script/" command 
that can be placed anywhere in a block of code, and queues script for 
execution at the end of the block of code.  This approach is cleaner (no 
"finally" clause adding bulk to the try/catch syntax), and resource 
allocation and cleanup concerns can be located together in the source 
code (locality is a good thing).  Error/exception handling is also 
simplified as each finally script runs independently (exception 
information is chained) - so if part of your 'finally' fails, other 
parts will still run without having explicit exception handling in a 
'finally' clause.

Simple example of alternate finally syntax:
try {
  set f [open "myfile.txt" r]
  finally [list close $f] ;# or finally { close $f } since it executes 
in the context of the block
  # ...
}

Anyway ... there is still work to be done ;/

Regards,
Twylite

Re: [TCLCORE] TIP #340: Const Qualification of Tcl_SetResult's Argument and -Wwrite-strings

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

2008/11/17 Donald G Porter <dg...@ni...>:
> There's another in tkOldConfig.c.  And one in tkMacOSXWm.c.
> And tkUnixWm.c.  And tkWinWm.c

and one in tkUnixSend.c.  That's 5 out of the total 258
Tcl_SetResult calls in Tk. And 2 out of 129 Tcl_SetResult
calls in Tcl (not counting the 2 in tclTest.c, because those
are meant to test the Tcl_SetResult function).

All of them are converted to use Tcl_SetResult(......, TCL_VOLATILE) now.

Regards,
          Jan Nijtmans

Re: [TCLCORE] TIP Roundup (162)

[David G. <dav...@po...>]

Donal K. Fellows wrote:

>    TIP #162	IPv6 Sockets for Tcl

Years back, I added IPv6 capability to a socket channel driver
extension.  I thought about that one quite a lot about 3 years ago.  The
big problem with adding v6 regards name resolution fundamentals.  TCP/IP
isn't the only networking layer there is, and it wouldn't be prudent to
restrict the generic layer to IP naming concepts alone.

It'll take me a bit to get up to speed again, but I can head this one.

1) real async multi-protocol (IP/dns,IPX/SAP,IrDA/IAS,AppleTalk,etc..)
name resolver with support for all three types: static, dynamic and
persistent resolution systems.

Maybe fix Tcl_PosixError(), or the error message calls around it, so it
can support the errors found in netdb.h so we can get back meaningful
error messages that can distinguish HOST_NOT_FOUND from TRY_AGAIN
instead of the current meaningless EINVAL.

2) A plugin system for extensions to insert new protocols at run-time or
internally when compiled in.

3) Allow for calls such as the following:
   socket 3ffe:b80:185d:1::29 ftp
   socket -protocol spx FEDCBA98.1A2B3C5D7E9F 0453

When the IPX/SPX module has been installed -^

4) Maybe update the windows channel driver code to use WSAEventSelect()
with job pooling and get away from the ancient Win 3.1 holdover of
WSAAsyncSelect()

Re: [TCLCORE] TIP Roundup

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

Arnulf Wiedemann wrote:
> Am Dienstag, 18. November 2008 17:31:28 schrieb Donal K. Fellows:
>>    TIP #333	New Variable and Namespace Resolving Interface
>>
> I would volunteer to make a prototype implementation in the core for that one 
> (for 8.7), but would need at least some help/suggestions from Miguel or 
> others?, as I am not sure about some of the consequences/sideeffects the 
> implementation would have.

That's why it's not on the top-priority list. Being a little bit brutal,
we want to push to get in what we can, but we have to focus to get done
what we can. I think your TIP needs a bit more work than that to work
out what the consequences are (if you can get someone to do it, great,
but I'm putting my effort elsewhere). As DGP said, there's not that long
left until we feature-freeze 8.6...

Donal.

Re: [TCLCORE] TIP Roundup

[Arnulf W. <ar...@wi...>]

Am Dienstag, 18. November 2008 17:31:28 schrieb Donal K. Fellows:
>    TIP #333	New Variable and Namespace Resolving Interface
>
I would volunteer to make a prototype implementation in the core for that one 
(for 8.7), but would need at least some help/suggestions from Miguel or 
others?, as I am not sure about some of the consequences/sideeffects the 
implementation would have.

Arnulf (apw)

Re: [TCLCORE] TIP Roundup (Tk #180/#319)

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

Jeff Hobbs wrote:
[Re #180 and #319]
> I think these TIPs are tied.  The core ttk widgets should operate in 
> their ideal state, without "bogus" options.  There should be a layer on 
> top for compat should users want that.  Ideally this would be done with 
> a megawidget support layer in the core.  You can do it now with 
> snidgets, but something tcloo-based would be ideal (eating our own dogfood).

I've already done some simple megawidgets with TclOO; it wasn't hard.
See http://wiki.tcl.tk/21103 for my experiments in the area (it
demonstrates the creation of both new options and new methods, and does
so both on top of plain Tk widgets and Ttk widgets).

FWIW, I think the aspects of #180 that are good are that it talks about
providing common support for handling options. That's the sort of thing
that a core class ought to give you (and which I didn't work hard on in
my experimenting).

Donal.

Re: [TCLCORE] TIP Roundup (Tk #180/#319)

[Brett S. <bre...@ya...>]

> 
> Joe English wrote:
> > Donal K. Fellows wrote:
> >
> >> I've got a list of all the open TIPs that can target 8.6 still here.
> >> [...]
> >> High Priority and demanding of real effort:
> >>    TIP #180    Add a Megawidget Support Core Package
> >
> > Same as before: publish this as an extension first, let it
> > cook for a while as people use it, and if it ends up being
> > useful *then* decide whether to integrate it into the core.
> > Remember TIP#48!
>     ...
> >>    TIP #319    Implement Backwards Compatibility for ttk Themed Widgets
> >>         in tk Widgets
> >
> > And everybody gets a pony!
> >
> > But seriously: I tried to make this work.  It didn't.
> > The AMSN folks tried a different approach with Chameleon,
> > and got farther than I did; suggest people look there.
> > The approach suggested by the TIP sounds completely unworkable
> > to me.
> 
> I think these TIPs are tied.  The core ttk widgets should operate in
> their ideal state, without "bogus" options.  There should be a layer on
> top for compat should users want that.  Ideally this would be done with
> a megawidget support layer in the core.  You can do it now with
> snidgets, but something tcloo-based would be ideal (eating our own dogfood).
> 


FWIW, I like this approach...



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core