tcl-core

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

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

The final set of votes that I'm calling; we're about out of time and I'm
definitely out of effort! :-)

  TIP#329: Try/Catch/Finally syntax
  TIP#343: A Binary Specifier for [format/scan]

Votes to this list by Wed Dec 10 12:00:00 GMT 2008 which is [clock
format 1228910400]. My votes follow:

  TIP#329: YES (finally!)
  TIP#343: YES (seems perfectly formed to me)

Note that I look forward to a vote on #162 soon as I think it is a
feature that we ought to get into 8.6, but I won't run it. I've done my
dues...

Donal.

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

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

> The final set of votes that I'm calling; we're about out of time and I'm
> definitely out of effort! :-)
 
>   TIP#329: Try/Catch/Finally syntax
>   TIP#343: A Binary Specifier for [format/scan]

At this moment
	TIP#329:	PRESENT
	Have to read the TIP first, now that the heat of discussion has subsided.

	TIP#343:	YES
	Agreeing with Donal. This is low-hanging fruit and sensible.

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

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

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

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

2008/12/3 Donal K. Fellows <don...@ma...>:
> The final set of votes that I'm calling; we're about out of time and I'm
> definitely out of effort! :-)
>
>  TIP#329: Try/Catch/Finally syntax
>  TIP#343: A Binary Specifier for [format/scan]

My votes:

TIP#329: YES
TIP#343: YES

I wonder if support for "0o" (octal) is missing in some places in the
core as well. I think everywhere that "0b" is accepted, "0o" should
be accepted as well.

Some more:

TIP #322: YES (see additinal remark below)
TIP #324: YES
TIP #332: YES
TIP #341: YES

In TIP #322, I initially was mislead by the the signatures for
Tcl_NRCallObjProc and Tcl_NRCmdSwap but in tcl.decls
they are correct: "Tcl_Obj const *objv[]" should
have been "Tcl_Obj *const objv[]".

Further on, I agree with Joe about the Tcl_NRAddCallback
signature: it is overkill to have 4 clientData arguments,
one would be sufficient. For use inside the core,
there still is an internal variant with 4 arguments, so this
change is easy: Just make Tcl NRAddCallback call
TclNRAddCallback, but with NULL as the last 3 arguments.
I considered giving Tcl_NRAddCallback a variable number of
arguments, but I think that would needlessly complicate things.

Regards,
        Jan Nijtmans

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

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

Jan Nijtmans wrote:
> Further on, I agree with Joe about the Tcl_NRAddCallback
> signature: it is overkill to have 4 clientData arguments,
> one would be sufficient. For use inside the core,
> there still is an internal variant with 4 arguments, so this
> change is easy: Just make Tcl NRAddCallback call
> TclNRAddCallback, but with NULL as the last 3 arguments.
> I considered giving Tcl_NRAddCallback a variable number of
> arguments, but I think that would needlessly complicate things.

I've written a few of the actual uses of that API, and can supply a bit
of grist to this mill. It is most certainly useful to be able to pass
more than one machine-word to the callback, and 4 covers a vast majority
of cases: keeping down the number of times you have to allocate memory
on the critical path is also a good idea.

IIRC, the number 4 was chosen because that was what it was convenient to
provide in the backing structure while retaining a fast allocator. Or
something like that.

Donal.

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

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

Donal K. Fellows wrote:
> Jan Nijtmans wrote:
>> Further on, I agree with Joe about the Tcl_NRAddCallback
>> signature: it is overkill to have 4 clientData arguments,
>> one would be sufficient. For use inside the core,
>> there still is an internal variant with 4 arguments, so this
>> change is easy: Just make Tcl NRAddCallback call
>> TclNRAddCallback, but with NULL as the last 3 arguments.
>> I considered giving Tcl_NRAddCallback a variable number of
>> arguments, but I think that would needlessly complicate things.
> 
> I've written a few of the actual uses of that API, and can supply a bit
> of grist to this mill. It is most certainly useful to be able to pass
> more than one machine-word to the callback, and 4 covers a vast majority
> of cases: keeping down the number of times you have to allocate memory
> on the critical path is also a good idea.
> 
> IIRC, the number 4 was chosen because that was what it was convenient to
> provide in the backing structure while retaining a fast allocator. Or
> something like that.

Then why doesn't it receive some objv/objc API?