tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Adam W. <awi...@ma...>]

On Wed, 2008-10-15 at 12:43 -0700, Adam Williamson wrote:

> I'd be able to manage on this front. Hopefully :) ATM I'm leaning
> towards kicking to 8.6 now, but I will do a quick survey of our major
> Tcl apps to make sure they have a port available already, or coming
> soon.

Well, the Mandriva Tcl 8.6 migration is now basically complete.

I left out a few packages that were Giant Balls Of Pain, but I ported
~100 packages to Tcl 8.6 and the new Fedora-based location policy (which
is very smart, kudos to whoever came up with it).

99% of the issues I encountered were uses of interp->result, most of
which I fixed properly, some of which I kludged around with the
#define , because - not being a coder - I don't always know exactly how
to use Tcl_SetResult when tcl->result is being *set* rather than *read*
(I'm not sure whether to use TCL_STATIC, TCL_DYNAMIC or TCL_VOLATILE in
each case).

But yep, it's all done, and just about everything works. Including the
big stuff like amsn. Heck, I even made ical work, I'm pretty sure we're
the only distro in the world with a working ical package now. =) So
migration to Tcl 8.6 is definitely possible for adventurous
distributions at this point. Wonder if whoever the Fedora maintainer is
wants to take the plunge. :)

I've mostly filed reports and contributed patches upstream, but of
course, upstream for many old Tcl apps is pretty much dead now. So
anyone interested can always pull the patches and quick fixes from
Mandriva SVN - http://svn.mandriva.com/ . The builds for Cooker can be
found at
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/(packagename) .
-- 
adamw

[TCLCORE] Status of votes in progress ...

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

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


Deadl. = End of voting period, all in December.
TIP	 = Tip number, and short hand for the title.
Voters = Who has voted what so far (+YES, -NO)

TIP             Deadl.  Voters

340 const qual  ?       -jenglish? +jan?

234 zlib        8       +dkf +jan +ak +tclguy +msofer +kbk
244 png         8       +dkf +jan +ak +tclguy +msofer +kbk

324 tk_font     9       +dkf
332 1/2 close   9       +dkf +ak
341 dict filter 9       +dkf +ak

329 try/catch   10      +dkf +jenglish
339 pkg names   10      +ak +tclguy -jenglish
343 %b format   10      +dkf +ak
322 nre api     10/12   +msofer +kbk +jenglish

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

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

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

Andreas Kupries wrote:
> Let us see who screams.
> Calling the vote on
> 	TIP #339:	Case-Insensitive Package Names


TIP#339: NO.

This is a tough call, but in the end my feeling is that
the problems this TIP would solve are outweighed by
the problems that it would introduce.  So NO.


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIP #322: Publish the NRE API

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

> At the request of Miguel Sofer, who lacks the time at the
> moment to administer the vote, I'm calling the vote on
>
> TIP #322: Publish the NRE API

TIP#322: YES.

(That's a YES with reservations: I think the signature of
Tcl_NRAddCallback() with its four ClientData parameters is
screwy and wrong, but that's not a big enough objection
to vote against the TIP.  Other than that it looks sound.)


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIP #322: Publish the NRE API

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

Kenny, Kevin B (GE, Research) wrote:
> At the request of Miguel Sofer, who lacks the time at the 
> moment to administer the vote, I'm calling the vote on 
>  
> TIP #322: Publish the NRE API

TIP#322: Yes

Re: [TCLCORE] CFV: TIP #322: Publish the NRE API

[miguel s. <mig...@gm...>]

Kenny, Kevin B (GE, Research) wrote:
> Oops - missed stating the deadline for the vote: 2008-12-12 12:00:00Z 
> At the request of Miguel Sofer, who lacks the time at the moment to
> administer the vote, I'm calling the vote on 
>  
> TIP #322: Publish the NRE API

My vote:

TIP #322: YES

Miguel


> I'm the wrong person to address any debate; this isn't my proposal. I
> will volunteer to assist with writing the man page and making the
> necessary changes to the Stubs tables if the vote passes.

So will I ;)

Re: [TCLCORE] CFV: TIP #322: Publish the NRE API

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

Oops - missed stating the deadline for the vote: 2008-12-12 12:00:00Z 

-----Original Message-----
From: Kenny, Kevin B (GE, Research) 
Sent: Friday, December 05, 2008 11:24 AM
To: 'tcl...@li...'
Subject: CFV: TIP #322: Publish the NRE API

At the request of Miguel Sofer, who lacks the time at the moment to
administer the vote, I'm calling the vote on 
 
TIP #322: Publish the NRE API

I'm the wrong person to address any debate; this isn't my proposal. I
will volunteer to assist with writing the man page and making the
necessary changes to the Stubs tables if the vote passes.

My vote:

TIP #322: YES

--
73 de ke9tv/2, Kevin

[TCLCORE] CFV: TIP #322: Publish the NRE API

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

At the request of Miguel Sofer, who lacks the time at the 
moment to administer the vote, I'm calling the vote on 
 
TIP #322: Publish the NRE API

I'm the wrong person to address any debate; this isn't
my proposal. I will volunteer to assist with writing the
man page and making the necessary changes to the Stubs tables
if the vote passes.

My vote:

TIP #322: YES

-- 
73 de ke9tv/2, Kevin

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

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

Andreas Kupries wrote:
> Let us see who screams.
> 
> Calling the vote on 
> 
> 	TIP #339:	Case-Insensitive Package Names
> 
> One week voting period, close at 12:00 GMT on 9 December.
> 
> My vote:
> 	TIP#339	YES

TIP#339: YES

In the long term view, where I hope Tcl modules become more common and 
we still have to deal with case insensitive OSes, this just makes sense.

Jeff

Re: [TCLCORE] TIP #329 [try] updated

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

"Donal K. Fellows" <don...@ma...> wrote:
> I can *deny* this. :-) Apart from everything else, it is significantly
> more awkward to implement since you'd have to push a special catch
> context just when doing the listRangeImm. And anyway...

I now feel guilty for having stepped this loose :-)
Would it be feasible to sanity-check the errorCode
just once (and independent of actual handlers), and
in the BAD-case replace it with something else?

Another ugly workaround could be to make the match check like
this:   Canonify the pattern (i.e. lrange 0 end) and see if it's
entirely equal to the errorCode or if "$canonifiedpattern *"
glob-matches the errorCode.   Wow, did I just suggest to use
glob on a list??? *gasp*  It's ok, it's a fundamentally different
thing.  I believe that for two canonical lists, this type of check
is equivalent to a sublist check (they differ only for bad lists).
If I'm wrong here, then forget this second paragraph altogether.

> The errorcode is documented to be a list on the [return] manpage and has
> been for many years, though according to DGP it is a bug that this is
> not currently enforced. Probably because nobody tried to do it.

intercepting bad errorCodes at the respective commands is surely not
safe enough.   Assuming that [try] makes use of the [catch]-infra-
structure, catch would be the appropriate place to spot bad errorCodes
and perhaps repair them like regexp {\S+} ...

I am quite sure that bad errorCodes shall never circumvent the finally
block.

Re: [TCLCORE] TIP #329 [try] updated

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

Twylite wrote:
> Right - can you please flex your admin muscles and clarify that in the 
> TIP.  It's not merely that "trap can't process it", it is that a 
> TCL_ERROR with "-errorcode not a list" is an exception that will be 
> raised if a trap handler is checked.

I'll think about how to implement the correction.

> Also please clarify for my understanding (and to answer Joe's 
> question/statement) whether "finally" will run if this happens (your 
> answer implies not: if you don't have a special catch context for 
> listRangeImm then you can't stop the exception from propagating so that 
> you can do the finally, depending on how the entire function is being 
> written).

We'll make sure that 'finally' always runs. It's not a handler, and the
'finally' semantics are important. More of a concern is what happens
when you hit a resource limit or the interpreter is unwound or deleted
but there the issue is that the interpreter is just unable to execute
commands; a finally clause could run, but would have to do nothing that
involves commands... ;-)

> Side question: if you're working in C code there is no "catch context" 
> -- you just get a non-zero return value.  I had imagined the bytecode 
> would be similar? 

The bytecode engine is rather more complex than that. IIRC, each
instruction is in the context of an error handler; the default one just
makes the current "script evaluation" exit, but [catch] (and [try]) puts
a different one in place around its protected code. (Or maybe there's no
handler by default, but that's dealt with the same as if there was a
default handler that does what I described. Whatever.)

What that means is that if you have a fairly complex structural piece of
Tcl inside a [catch], Tcl can handle any errors inside it very quickly.
Or it could except for generation of errorinfo traces. The break and
continue exceptions are handled through a very similar (but slightly
more optimized) mechanism.

Donal.

Re: [TCLCORE] TIP #329 [try] updated

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

Twylite wrote:
>> Side question: if you're working in C code there is no "catch context" 
>> -- you just get a non-zero return value.  I had imagined the bytecode 
>> would be similar? 
>>   
> Never mind.   But there need to be bigger health warnings on 
> tclExecute.c and tclCompile.c.

I don't think they make letters that large except in books by Douglas
Adams...

> Of course this is easier said than done.  Everything calls down to "void 
> Tcl_SetObjErrorCode(Tcl_Interp *interp, Tcl_Obj *errorObjPtr)" which 
> makes for one convenient place to fix the problem, but the function is 
> published in the stubs table and returns (void) ... which makes it 
> tricky to fix.

While I know how to fix such things through stub-table rearrangement
(and I've done such in parts of Tk) they're pretty ugly to do. What we
*can* do is make sure that Tcl code doesn't mess this up through
[error], [return] (and [throw]). I don't think anyone is actually
generating bad error codes anyway; at the C level, the convenient API
produces proper lists.

> One could fix TclProcessReturn() to check valuePtr just before calling 
> Tcl_SetObjErrorCode (context below) ...
[...]
> ... which would at least make this safe at a script level, so that only 
> C code calling Tcl_SetObjErrorCode directly can mess things up.

Things are fairly messy in this area.

Donal.

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

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

lm...@bi... (Larry McVoy) writes:

> On Wed, Dec 03, 2008 at 03:27:28PM -0800, Andreas Kupries wrote:
> > Let us see who screams.
> > 
> > Calling the vote on 
> > 
> > 	TIP #339:	Case-Insensitive Package Names
> > 
> > One week voting period, close at 12:00 GMT on 9 December.
> > 
> > My vote:
> > 	TIP#339	YES
> 
> Not that my opinion matters, but count me in the YES camp.

Mine doesn't either.  Although I will not suffer from the package
name collisions this may cause, I am sensitive to the claims raised
here that such cases do exist.  What does has caught me often is the
current case-sensitive matching when the capitalization of package
names follows no rules.  (I remember there being rules for core vs
non-core packages, but I don't see them being followed.)

However, I would be quite happy with a change to the error message,
suggesting a corresponding existing package

can't find package Blt (perhaps you meant BLT)

What I don't know is if dynamic error messages break any contract;
maybe constant strings are needed for translators and parsers.


I was pleasantly surprised tonight when "mount" suggested I meant
to type iso9660 when I typed iso9669.

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

Re: [TCLCORE] TIP #329 [try] updated

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

> Side question: if you're working in C code there is no "catch context" 
> -- you just get a non-zero return value.  I had imagined the bytecode 
> would be similar? 
>   
Never mind.   But there need to be bigger health warnings on 
tclExecute.c and tclCompile.c.
> I think this bug needs to be fixed then.  There's a good chance that 
> nobody has tried to do this because there is little use of errorcode.  
> As its use increases we're going to encounter problems.
>   
Of course this is easier said than done.  Everything calls down to "void 
Tcl_SetObjErrorCode(Tcl_Interp *interp, Tcl_Obj *errorObjPtr)" which 
makes for one convenient place to fix the problem, but the function is 
published in the stubs table and returns (void) ... which makes it 
tricky to fix.

One could fix TclProcessReturn() to check valuePtr just before calling 
Tcl_SetObjErrorCode (context below) ...
    if (valuePtr != NULL) {
        Tcl_SetObjErrorCode(interp, valuePtr);
    }
... which would at least make this safe at a script level, so that only 
C code calling Tcl_SetObjErrorCode directly can mess things up.

Regards,
Twylite

Re: [TCLCORE] TIP #329 [try] updated

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

Hi,
>> I _think_ that's what Donal's rewrite is saying, but I'm not certain?
>> DKF - can you confirm this?
>>     
> I can *deny* this. :-) Apart from everything else, it is significantly
> more awkward to implement since you'd have to push a special catch
> context just when doing the listRangeImm. And anyway...
>   
Right - can you please flex your admin muscles and clarify that in the 
TIP.  It's not merely that "trap can't process it", it is that a 
TCL_ERROR with "-errorcode not a list" is an exception that will be 
raised if a trap handler is checked.

Also please clarify for my understanding (and to answer Joe's 
question/statement) whether "finally" will run if this happens (your 
answer implies not: if you don't have a special catch context for 
listRangeImm then you can't stop the exception from propagating so that 
you can do the finally, depending on how the entire function is being 
written).

Side question: if you're working in C code there is no "catch context" 
-- you just get a non-zero return value.  I had imagined the bytecode 
would be similar? 
> The errorcode is documented to be a list on the [return] manpage and has
> been for many years, though according to DGP it is a bug that this is
> not currently enforced. Probably because nobody tried to do it.
>   
I think this bug needs to be fixed then.  There's a good chance that 
nobody has tried to do this because there is little use of errorcode.  
As its use increases we're going to encounter problems.

Regards,
Twylite

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

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

Adrian Robert wrote:
> I'm still uneasy about the prefixing for the command, though I hope  
> this can be decided independently of the voting on the TIP.  The main  
> proposals have been:
> 
> (1) tk_chooseFont [original]
> (2) ::tk::chooseFont [June-November]
> (3) tk chooseFont [current]

My advice? Stop vacillating. Go with the current proposal. Not because
it is inherently vastly superior, but because *nothing* is vastly
superior here and the current proposal is, well, current. :-)

Donal.

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

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

Twylite wrote:
> Just wondering how "rare" these incidents of case conflict will be ... I 
> have at least two in my libraries source tree, possibly more in my 
> applications.

I don't know, but I'd tend towards sub-packages or *Impl packages in my
own code. Case tricks have always made me a bit uneasy, and life is much
easier on Win if you don't play them. (OTOH, I have to ask what locale
the case-insensitivity is going to be applied in... :-))

Donal.

Re: [TCLCORE] TIP #329 [try] updated

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

Twylite wrote:
> Two ways of handling this:
> (1) If errorcode is not a list, then trap handlers must determine that 
> there is no match, and let the error fall through to the next handlers 
> and be processed or propagated as normal.  I _think_ that's what Donal's 
> rewrite is saying, but I'm not certain?
> DKF - can you confirm this?

I can *deny* this. :-) Apart from everything else, it is significantly
more awkward to implement since you'd have to push a special catch
context just when doing the listRangeImm. And anyway...

> (2) Update the implementations of error & return so that a non-list 
> error code raises an appropriate error at that point, rather than 
> allowing arbitrary strings that can blow up the [try] later.

The errorcode is documented to be a list on the [return] manpage and has
been for many years, though according to DGP it is a bug that this is
not currently enforced. Probably because nobody tried to do it.

Donal.

Re: [TCLCORE] TIP #329 [try] updated

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

Hi,
> Donal K. Fellows wrote:
>   
>> Andreas Leitgeb wrote:
>>     
>>> A few minor questions about implementation (I'm just curious):
>>>   How does the byte-coded "lrange" thing deal with bad lists
>>>     (i.e. something like "{fsg fds}dsfa {" ) ?  The  TIP specifies
>>>     that no errors be thrown for non-list errorCodes or patterns.
>>>       
>> Ooops, missed that. I'll change that when I call the vote because it's
>> not a good decision. The list interpretation of error codes has been
>> assumed for well over a decade, so a non-list error code is an error itself.
>>     
>
> If you rephrase it, please ensure that the new text
> continues to specify that in the following:
>
> 	} on error {msg opts} {
> 	    # (2)
> 	} finally {
> 	    # (3)
> 	}
>
> clauses (2) and (3) are executed.
>   
Thanks Joe - I didn't get a chance to response to Donal yesterday. 
What I said (or intended to say) in the TIP was that the [try] itself 
must not die horrible if it encounters an errorcode that is not a list.  
This would imo be a bug in [try] unless error/return/throw force their 
errorcode argument to be a list (which they don't).  And it would be a 
Bad Thing because then someone doing something stupid lower down the 
stack can blow up your anti-blowup control structure.

Two ways of handling this:
(1) If errorcode is not a list, then trap handlers must determine that 
there is no match, and let the error fall through to the next handlers 
and be processed or propagated as normal.  I _think_ that's what Donal's 
rewrite is saying, but I'm not certain?
DKF - can you confirm this?

(2) Update the implementations of error & return so that a non-list 
error code raises an appropriate error at that point, rather than 
allowing arbitrary strings that can blow up the [try] later.

Regards,
Trevor

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

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

Just wondering how "rare" these incidents of case conflict will be ... I 
have at least two in my libraries source tree, possibly more in my 
applications.

Regards,
Twylite


Andreas Kupries wrote:
> Let us see who screams.
>
> Calling the vote on 
>
> 	TIP #339:	Case-Insensitive Package Names
>
> One week voting period, close at 12:00 GMT on 9 December.
>
> My vote:
> 	TIP#339	YES
>
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
>  
>
> -------------------------------------------------------------------------
> 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
>
>
>   

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

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

On Wed, Dec 03, 2008 at 03:27:28PM -0800, Andreas Kupries wrote:
> Let us see who screams.
> 
> Calling the vote on 
> 
> 	TIP #339:	Case-Insensitive Package Names
> 
> One week voting period, close at 12:00 GMT on 9 December.
> 
> My vote:
> 	TIP#339	YES

Not that my opinion matters, but count me in the YES camp.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

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

Let us see who screams.

Calling the vote on 

	TIP #339:	Case-Insensitive Package Names

One week voting period, close at 12:00 GMT on 9 December.

My vote:
	TIP#339	YES

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

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Adrian R. <adr...@gm...>]

On Dec 1, 2008, at 2:10 PM, Daniel A. Steffen wrote:

> On Tue, Nov 25, 2008 at 09:06, Daniel A. Steffen <da...@us... 
> > wrote:
> On 24/11/2008, at 20:53, Adrian Robert wrote:
> Unless someone thinks further work is warranted, could this be  
> called for vote now?
>
> please wait for another week to call for a vote on this, that is  
> still inside the Dec 10 timeframe by a week and will give me some  
> more time to work on this and edit the TIP.
>
> I have now updated the TIP and the implementation, and it is now  
> ready to be CFV as far as I am concerned. Pat has also indicated  
> that his is happy with the proposed specification.
>
> http://tip.tcl.tk/324

I'm still uneasy about the prefixing for the command, though I hope  
this can be decided independently of the voting on the TIP.  The main  
proposals have been:

(1) tk_chooseFont [original]
(2) ::tk::chooseFont [June-November]
(3) tk chooseFont [current]

(1) is consistent with other temporary dialogs (tk_getOpenFile,  
tk_messageBox, tk_chooseColor, etc.) in its naming style, however the  
font chooser dialog operates differently in that it may be non-modal  
on Mac OS X and perhaps other platforms.

Therefore (2) was proposed, however it would introduce a practice of  
dividing the tk core cross-platform commands into multiple  
namespaces.  This seems too drastic a move to deal with the  
inconsistency in (1).

Perhaps partly in reaction to this, (3) was brought into the most  
recent version of the TIP.  However the 'tk' command is described in  
its man page as "Manipulate Tk internal state". The other subcommands  
under it include "appname", "scaling", and "useinputmethods".  Putting  
up a dialog to choose a font would be an odd man out here.

(1) is the best choice.  Not just for the shortcomings of (2) and (3),  
but also because the diversity of commands under the tk_ prefix is in  
fact already greater than what would be added by bringing in  
chooseFont.  There are tk_focusNext, tk_setPalette, tk_textPaste, even  
tk_bisque.  Moreover, the most similar dialog Tk currently supports is  
tk_chooseColor.  The font chooser is non-modal on Mac OS X, however to  
be equally platform compliant tk_chooseColor should be this way as  
well, and may eventually be changed to such.  Regardless, prefixing/ 
naming these commands differently will adversely affect the clarity of  
the tk core command set.

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

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

2008/11/27 Joe English <jen...@fl...>:
>
> Jan Nijtmans wrote:
>>
>> [ Revised specification for TIP#340, of which I approve ]
>

First remark: This looks like a YES, but still
isn't. I'm wondering why still no other votes then
mine came out. Was it because the TIP was still
not updated to include the results of the agreement?
If that's the case, I have good news: the TIP
text is updated now!

Second remark: I agree with all of Joe's remarks
below. Especially the last remark is important.
Although the risk is not zero, it is small enough
in my opinion to justify a YES. My "who cares!"
remark was intended to trigger everyone's
attention, not to make people afraid of voting. :-)
Joe was the only one who reacted, and he
reacted exactly the way I hoped for.....

> Just a few notes:
>
>> It will still be a lot of
>> work to check all Tcl_SetResult() calls, because
>> a simple change to Tcl_SetStringResult() is not
>> always the best solution. (I hope that Joe will
>> help me with this.....)
>
> To clarify: this is not a mechanical change, but
> the whole point of enabling additional compiler warnings --
> to improve the code -- involves a certain degree of code
> review in the first place.
>
> Tcl_SetResult(interp, s, TCL_STATIC|TCL_VOLATILE);
> can generally be shortened to Tcl_SetStringResult(interp, s);
> without further thought.
>
> In the case of Tcl_SetResult(interp, (char*)s, TCL_STATIC|TCL_VOLATILE);
> where "s" is a const char *, you can also remove the cast-away-const cast.
>
> Calls that use TCL_DYNAMIC or a general freeProc need to be
> examined on a case-by-case basis.
>
> Also: this is not a forced change; it requires no changes
> to extensions or (strictly speaking) even to the core itself.
> The idea is to provide a convenient, const-correct alternative
> to Tcl_SetResult() for the benefit of code that wishes to become
> const- and -Wwrite-strings safe.
>
>
>> The disadvantage is that it might break extensions
>> compiled against Tcl 8.6 which still use interp->result,
>> but since TIP #330 is accepted, who cares!
>
> To clarify: such extensions are already broken and
> have been in danger of the brokenness being exposed
> at any time anyway.  Extensions that look directly
> at interp->result may be affected simply because there
> will be even fewer places in the core that set interp->result;
> this sort of thing has been going on since Tcl 8.0,
> so there's nothing new here.

Regards,
         Jan Nijtmans

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

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

Donal K. Fellows wrote:

>   TIP#329: Try/Catch/Finally syntax

TIP#329 r1.7: YES (enthusiastically)

I'd like to thank Twylite for shepherding this one
through the TIP process.  The discussion looked like
it was going to go completely off the rails, but
in the end the process worked: the final version
is a *good* spec.  Between the conflicting requirements
of functionality on the one hand and simplicity on
the other, it hits a local optimum.


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

TIP#343: PRESENT.

--Joe English

  jen...@fl...