tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: Zlib and PNG

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

> No 8.6 Tcl should ship without zlib support built in.

Amen.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] CFV: Zlib and PNG

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

Donal K. Fellows wrote:
> As has been thoroughly threatened, here's the Call For Votes on getting
> zlib support for Tcl (yay compression!) and PNG support for Tk (yay
> modern icons!) Votes should be sent to tcl-core by midday GMT next
> Monday (i.e. [clock format 1228737600]).
> 
>    TIP#234: Add Support For Zlib Compression
>    TIP#244: PNG Photo Image Support for Tk
> 
> My votes:
>    TIP#234: YES
>    TIP#244: YES
> 
> I have one subsidiary question in relation to Zlib support which, I
> think, does not cause major problems if dealt with *now* but which would
> be awkward to tackle down the road.
> 
>    Should the prefix for the C API be "Zlib_" or "Tcl_Zlib" or what?

TIP#234: YES
TIP#244: YES

It should be Tcl_Zlib and it should _not_ be a separate package or in 
any way optional.  No 8.6 Tcl should ship without zlib support built in.

Jeff

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

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

Thanks Joe,
> Also also: re: "trap" clauses doing a glob match or
> a list prefix match: either way sounds OK to me.
> I have a slight preference for list prefix match,
> but glob matching is also OK.
So far the opinion seems to be that a list prefix is too limited, and a 
list pattern match (per element glob) is too difficult and has no 
existing reference.

List prefixes are limited because they don't allow an errorcode to 
represent multiple dimensions. e.g. A media streaming error could be 
both an AudioException and an IOException, and different users of your 
media library may want to treat the error in different ways (a stream 
ripper is more concerned with IOExceptions, whereas a music player is 
probably more concerned with all types of AudioException (io, encoding, 
etc) ).  A list prefix matcher could cope with Java's single inheritance 
model, but not with the exception support available to (say) C++.
> we don't ever want to see
>
>     [try { ... } trap -match regexp "..." { ... }]
>   
No, no we don't ;)

The intended manner for extending [try] is by adding new handler 
keywords (if the existing ones are not handling the required use cases).

For example if  there was a move in future to a -errorobj in the options 
dict, then [try] could be extended to do ancestor matching on the 
-errorobj by introducing an "isa" keyword, e.g. try { ... } isa 
IoException { ... }.

Regards,
Twylite

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

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

Also also: re: "trap" clauses doing a glob match or
a list prefix match: either way sounds OK to me.
I have a slight preference for list prefix match,
but glob matching is also OK.  The critical thing
is to pick *one* kind of matching and stick with it:
we don't ever want to see

    [try { ... } trap -match regexp "..." { ... }]


... and lastly, on the "what color is the bikeshed" question:
The names "on" and "trap" are the ones I like best
of all the ones proposed.  Please keep.


--JE

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

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

Twylite wrote:
> I am starting to use this version of [try] in a product that will have a
> beta release & customer demo in about two days.  This is giving me a
> better feel for how [try] will behave in real work ;)  I should have
> time tomorrow to experiment with both approaches (as vs per-handler) and
> see what feels best (I can also run it past some junior developers and
> see how they respond to the syntax - it's usually a good indicator of
> complexity).

Good plan.


> Anyone else have strong feelings about this (either way)?

Two more points: (1) Just about every other language with
a try/catch/finally statement [*] binds variables as part
of the handler clause; and (2) personal experience:
with the "as" form, I can never figure out a good place
to put braces and linebreaks :-)


> > Also: in section "Handlers", subsection "Notes & clarifications",
> > bullet point 4:
> > |    If any exception is replaced (by an exception in a handler body or in
> > |    the finally body) then the new exception shall introduce a field into
> > |    its options dict that contains all details of the original exception.
> > This needs clarification.  (Is it even necessary?)
> >
> In short: exception chaining.  If an exception is thrown in an exception
> handler or finally clause, the original exception (the "root cause")
> should not be lost.  This is critical for debugging problems in live
> systems, and very useful in development as well.

That's fine, but it still needs clarification:
what is the name of the entry that gets added to
the options dictionary, and what does it contain?


--JE

  [*] Examples: Java, C#, C++, Ada, Erlang, ML, ...

Re: [TCLCORE] CFV: Zlib and PNG

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

> As has been thoroughly threatened, here's the Call For Votes on getting
> zlib support for Tcl (yay compression!) and PNG support for Tk (yay
> modern icons!) Votes should be sent to tcl-core by midday GMT next
> Monday (i.e. [clock format 1228737600]).
>
>    TIP#234: Add Support For Zlib Compression
>    TIP#244: PNG Photo Image Support for Tk

TIP#234: YES
TIP#244: YES

I prefer the prefix 'Tcl_Zlib' for the C API. Regardless of whether built as
part of the core, or as separate dll. IMHO switching the prefix around for
that is complexity without need.

On the issue of 'package require zlib' ...  If separate definitely needed.
If baked into the core we should IMHO still support the require, just make
the index script a null-op, i.e. empty. That way scripts can always do
'package require zlib' without having to think about whether the commands
are baked in the core or come from an/the extension.

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

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

[Daniel A. S. <da...@us...>]

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
http://sourceforge.net/support/tracker.php?aid=1477426
http://github.com/das/tcltk/commits/fontchooser

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...> **

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

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

Neil Madden wrote:
> Thanks for this. I think it looks good -- covers the basic cases and 
> isn't too complicated. I still have some reservations about 
> glob-matching as the only option, but it'll do.

You and me both ;)

In all seriousness, I've already encountered some situations that lead 
me to believe there will be teething problems, and some careful thinking 
about what conventions to adopt for -errorcode.

Case in point: we have an API for accessing a hardware coprocessor 
(let's call the API "ABC").  The coprocessor returns numeric error 
results in the range 1 to 99.  So we defined the -errorcode to be [list 
ABC $errnum], e.g. "ABC 4".
A little while later we realised that error 4 is quite special -- it is 
allowed to return an extended error information field (the coprocessor 
had to maintain the use of error 4 for backwards compatibility, but 
there were times when knowing the exact cause was important).  So we 
extended the -errorcode in this case to [list ABC $errnum $extra], e.g. 
"ABC 4 F".
So two hours in this is the position: Any "trap {ABC 4}" no longer 
works.  Changing this to "trap {ABC 4*}" won't work either because it 
will also trap errors in the range 40-49.  Using "trap {ABC 4 *}" will 
work, but would be incompatible with the older version of the API - 
that's not a problem right now because we can do a simple find & 
replace, but if you're intending to maintain the API over a long period 
of time it would be an issue.

A glob against errorcode doesn't work like an OO is-a relationship.  You 
can't arbitrarily subclass the error and maintain compatibility unless 
you plan for it.  That means that you must always have a "*" in the 
glob; most likely you'll be doing a prefix match.  It also means that 
your errorcode must end with a delimiter (like a space) so that you can 
distinguish between classes and subclasses of error (so that "ABC 4 *" 
can only be a subclass of "ABC 4", and not confused with "ABC 42").

My 2c.
Twylite

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

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

Hi,
> Please reconsider the "as" clause.  It is better to
> specify the variables to be bound at each handler as was
> done in the previous version of the TIP.
>   
I am starting to use this version of [try] in a product that will have a 
beta release & customer demo in about two days.  This is giving me a 
better feel for how [try] will behave in real work ;)  I should have 
time tomorrow to experiment with both approaches (as vs per-handler) and 
see what feels best (I can also run it past some junior developers and 
see how they respond to the syntax - it's usually a good indicator of 
complexity).

Anyone else have strong feelings about this (either way)?

> Also: in section "Handlers", subsection "Notes & clarifications",
> bullet point 4:
>
> |    If any exception is replaced (by an exception in a handler body or in
> |    the finally body) then the new exception shall introduce a field into
> |    its options dict that contains all details of the original exception.
>
>
> This needs clarification.  (Is it even necessary?)
>   
In short: exception chaining.  If an exception is thrown in an exception 
handler or finally clause, the original exception (the "root cause") 
should not be lost.  This is critical for debugging problems in live 
systems, and very useful in development as well. 

I'll point out Java's chain exception facility 
(http://java.sun.com/j2se/1.4.2/docs/guide/lang/chained-exceptions.html) 
that was introduced in Java 1.4 after experiences with previous 
versions.  Many developers saw the need to chain exceptions and 
developed their own schemes to do so, leading to a situation where high 
level code could not adequately introspect exceptions, thus complicating 
logging, debugging, etc.  The facility Java provides is still inadequate 
though -- many developers use boilerplate code or AOP to put their catch 
handler itself into a try/catch that automates exception chaining so 
that unintended exceptions in the handler don't obscure the original 
cause of the problem.

Note that Java has supported fillInStackTrace() since 1.1 (IIRC), which 
is roughly equivalent to Tcl's return/error with errorInfo, and which 
was not adequate for the needs of Java developers.  Tcl is not Java, but 
it would be rather brash to dismiss the experiences of that community.

Regards,
Twylite

[TCLCORE] commands returning static data (was Re: CVF#340 )...

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

Kevin Kenny wrote:
> Most calls to Tcl_SetResult with constant strings are
> error messages for which nobody cares about performance.
> For the ones that aren't ...

More on this theme at http://wiki.tcl.tk/12584 .

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

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

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

Twylite wrote:
>
> I've updated TIP #329 (http://tip.tcl.tk/329) and provided a reference
> implementation in Tcl.  If you have any last-minute show-stoppers please
> yell, otherwise I think the TIP is ready for a vote, if someone is
> willing to sponsor it.

Thank you; this looks just about right.

Please reconsider the "as" clause.  It is better to
specify the variables to be bound at each handler as was
done in the previous version of the TIP.

The original rationale for introducing 'as' is uncompelling.
The meaning of the return value (and whether it's even needed)
depends on which handler clause triggered.  Compare:

	try {
	    open $filename
	} as {XXX opts} on ok {
	    # (1)
	} trap {POSIX ENOENT *} {
	    # (2a)
	} on error {
	    # (2b)
	}
	# (3)

If control reaches (1), $XXX holds an open file channel.
If control reaches (2a) or (2b),  it holds an error message.
At (3), all you know is that XXX is set -- but
not what it means.

This is better written as:

	try {
	    open $filename
	} on {ok fp} {
	    # ... write to $fp
	} trap {{POSIX ENOENT *}} {
	    # ... handle "file not found" condition.
	} on {error msg} {
	    # ... report uncaught error $msg
	}

Also: in section "Handlers", subsection "Notes & clarifications",
bullet point 4:

|    If any exception is replaced (by an exception in a handler body or in
|    the finally body) then the new exception shall introduce a field into
|    its options dict that contains all details of the original exception.


This needs clarification.  (Is it even necessary?)


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: Zlib and PNG

[Michael K. <mi...@mu...>]

On Mon, 1 Dec 2008, Jan Nijtmans wrote:

> For PNG, this is so fundamental that a [package require]
> should not be necessary. If we are on a system without zlib,
> it is sufficient to handle only uncompressed PNG files. The
> availability of zlib could be a compile-time check or a run-time
> check (I would prefer the latter)

There are no "uncompressed" PNG files.  While the PNG format contains a 
byte indicating the compression method, only one method (deflate) is 
defined by the standard.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

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

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

Hi,

On 1 Dec 2008, at 11:49, Twylite wrote:
> Hi everyone,
>
> I've updated TIP #329 (http://tip.tcl.tk/329) and provided a reference
> implementation in Tcl.  If you have any last-minute show-stoppers  
> please
> yell, otherwise I think the TIP is ready for a vote, if someone is
> willing to sponsor it.

Thanks for this. I think it looks good -- covers the basic cases and  
isn't too complicated. I still have some reservations about glob- 
matching as the only option, but it'll do.

-- 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] CFV: Zlib and PNG

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

2008/12/1 Donal K. Fellows <don...@ma...>:
> Donal K. Fellows wrote:
>> I have one subsidiary question in relation to Zlib support which, I
>> think, does not cause major problems if dealt with *now* but which would
>> be awkward to tackle down the road.
>>
>>    Should the prefix for the C API be "Zlib_" or "Tcl_Zlib" or what?
>>
>> I note that *I* have no particular preference on this point. I just
>> don't want to have to change things since that would suck.
>
> I should also have asked whether we want to require scripts to contain
> [package require zlib], or whether we can just have it as an implicit
> part of Tcl 8.6. I'm agnostic on this topic too.

Those two questions are connected: If zlib is compiled in as part
of Tcl, the prefix should be Tcl_, if it is included as a separate
(dll|so), then it shoud be Zlib_.

My preference would be to keep the prefix Zlib_, require the
[package require zlib] and build it as a separate dll
(e.g. tclzlib123.dll on Windows), just as the dde
package is done now.

I even wonder whether we really should provide a compatibility
zlib library. It is much simpler just to disable the Zlib build when
zlib is not available. It means that only uncompressed PNG
can be handled, but I cannot imagine any system which
supports system PNG images without having zlib. For Windows,
just put the standard InfoZip provided zlib.dll in the C:\Tcl\bin
directory, for anybody's use.

For PNG, this is so fundamental that a [package require]
should not be necessary. If we are on a system without zlib,
it is sufficient to handle only uncompressed PNG files. The
availability of zlib could be a compile-time check or a run-time
check (I would prefer the latter)

Anyway, here are my votes:
  TIP#234: YES
  TIP#244: YES

(The above remarks are only implementation details, it doesn't
really affect my vote)

Regards,
         Jan Nijtmans

Re: [TCLCORE] CFV: Zlib and PNG

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

Donal K. Fellows wrote:
> I have one subsidiary question in relation to Zlib support which, I
> think, does not cause major problems if dealt with *now* but which would
> be awkward to tackle down the road.
> 
>    Should the prefix for the C API be "Zlib_" or "Tcl_Zlib" or what?
> 
> I note that *I* have no particular preference on this point. I just
> don't want to have to change things since that would suck.

I should also have asked whether we want to require scripts to contain
[package require zlib], or whether we can just have it as an implicit
part of Tcl 8.6. I'm agnostic on this topic too.

Donal.

[TCLCORE] CFV: Zlib and PNG

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

As has been thoroughly threatened, here's the Call For Votes on getting
zlib support for Tcl (yay compression!) and PNG support for Tk (yay
modern icons!) Votes should be sent to tcl-core by midday GMT next
Monday (i.e. [clock format 1228737600]).

   TIP#234: Add Support For Zlib Compression
   TIP#244: PNG Photo Image Support for Tk

My votes:
   TIP#234: YES
   TIP#244: YES

I have one subsidiary question in relation to Zlib support which, I
think, does not cause major problems if dealt with *now* but which would
be awkward to tackle down the road.

   Should the prefix for the C API be "Zlib_" or "Tcl_Zlib" or what?

I note that *I* have no particular preference on this point. I just
don't want to have to change things since that would suck.

Donal.

[TCLCORE] TIP #329 [try] updated

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

Hi everyone,

I've updated TIP #329 (http://tip.tcl.tk/329) and provided a reference 
implementation in Tcl.  If you have any last-minute show-stoppers please 
yell, otherwise I think the TIP is ready for a vote, if someone is 
willing to sponsor it.

Regards,
Twylite

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

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

FWIW, I believe I understand why the round trip through a
fixed-distance unit (here millimeters) was done.
The reason is that a screen distance like "2i" means a different
number of pixels on two windows belonging to screens of different
resolutions.
So it is in theory possible that the cached, pixel-converted value of
this distance be unduly used as is on another screen.

However, once this (extremely improbable) situation has been spotted,
it is fairly trivial to avoid it, by invalidating the internal rep
when a change of pixelPtr->tkwin is detected. That's the purpose of
the just-committed update.

-Alex

>
>        * generic/tkCanvUtil.c  Millimeter patch. Fixes [1813597,2218964]
>        * generic/tkInt.h               by eliminating the functional redundancy
>        * generic/tkObj.c       and unnecessary loss of precision of the
>        * generic/tkText.c      {pixel,mm}ObjType tandem.
>
> So, millimeters as an objtype can start decaying. Will be gone in 1e31
> years, like protons.
>
> Help appreciated for backports.
>
> -Alex
>

Re: [TCLCORE] CFV on small high-prio TIPs

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

Donal K. Fellows wrote:
> This is a Call For Votes on the following "small and practical" TIPs
> that I identified from my message earlier this week. (The other ones are
> in the process of being baked more.)
> 
>   TIP #171: Change Default <MouseWheel> Bindings Behavior
>   TIP #197: Text Widget Persistant Cursor
>   TIP #210: Add 'tempname' Subcommand to 'file'
>   TIP #238: Fire Event when Widget Created
>   TIP #284: New 'invoke' and 'namespace invoke' Commands
>   TIP #306: Auto-Naming Widgets
>   TIP #307: Make TclTransferResult() Public
>   TIP #335: An API for Detecting Active Interpreters
>   TIP #336: Supported Access To interp->errorline
>   TIP #337: Make TclBackgroundException() Public
>   TIP #338: Embedder Access to Startup Scripts of *_Main()

Well, at least some of these seem to have passed... :-)

#171: DKF, JN, (DGP), (MS), JH, KBK
#197: DKF, JN, (DGP), (MS), JH, KBK
#210: DKF, JN, JE, !DGP, MS, JH, KBK
#238: DKF, JN, (DGP), MS, !JH, !KBK
#284: DKF, JN, !JE, !DGP, MS, (JH), (KBK)
#306: !DKF, !JN, !JE, (DGP), MS, !JH, !KBK
#307: DKF, JN, JE, DGP, MS, JH, KBK
#335: DKF, JN, JE, DGP, MS, JH, KBK
#336: DKF, JN, JE, DGP, MS, JH, KBK
#337: DKF, JN, JE, DGP, MS, JH, KBK
#338: DKF, JN, JE, DGP, MS, JH, KBK

(To read the above, know that a YES is just the initials, a NO is 
preceded by a ! and a PRESENT is surrounded by parens.)

Passed unanimously with 7/0/0 each:
   #307, #335, #336, #337, #338

Passed with only abstentions, 4/0/2:
   #171, #197

Passed with one against, 6/1/0 (assuming I've represented DGP's vote right):
   #210

Rejected, with recommendation that be left Draft:
   #238 (3/2/1)
   #284 (3/2/2)

Thoroughly rejected, 1/5/1:
   #306 (breaks much code, encourages memory leaks, trivial to replace
        with scripted version)

Thanks everyone for voting!

Donal.

Re: [TCLCORE] CVF#340 ...

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

Andreas Leitgeb wrote:
> Just wondering: the previous distinction between STATIC and
> VOLATILE is now obviously dropped. Does that mean that now
> all strings are treated as TCL_VOLATILE (and copied)?

Jan Nijtmans has already pointed out that the effect of
today's Tcl_SetResult is the same for Tcl_Static (the string
gets copied the first time that the interpreter result is
used as a Tcl_Obj) and worse for TCL_VOLATILE (there are
two copies, once to the string result, and then again to
the object result). But let me point out that there is a
way at the cost of a little bit of complexity to avoid
the string copy altogether.

Most calls to Tcl_SetResult with constant strings are
error messages for which nobody cares about performance.
For the ones that aren't (in my extensions, they tend
to be the constants "0" and "1", enumerated keywords,
one or two other things), I maintain a literal table
(simply a Tcl_Obj**) that is accessible from the ClientData
of the command. In the _Init entry point of the extensions,
I make the Tcl_NewStringObj calls that create the literals,
store them in the literal table and increment their
refcounts. Then these Tcl_Obj pointers are simply available
to Tcl_SetObjResult.

Declaration:

enum literals {
     LIT_ZERO = 0,
     LIT_ONE,
     LIT_RED,
     LIT_GREEN,
     LIT_BLUE,
     LIT_COUNT
};
static const char *const LitValues [] = {
     "0", "1", "red", "green", "blue"
};
typedef struct LiteralPool {
     int refCount;
     Tcl_Obj* literals[LIT_COUNT];
} LiteralPool;

Initialization:

int i;
LiteralPool* poolPtr;
poolPtr = ckalloc(sizeof(LiteralPool));
poolPtr->refCount = 0;
for (i = 0; i < LIT_COUNT; ++i) {
     poolPtr->literals[i] = Tcl_NewStringObj(LitValues[i], -1);
     Tcl_IncrRefCount(poolPtr->literals[i]);
}
Tcl_CreateObjCommand(interp, "mycommand", Mycommand_ObjCmd,
                      (ClientData) poolPtr, Mycommand_DeleteProc);
++poolPtr->refCount;

Usage:

LiteralPool* poolPtr = (LiteralPool*) clientData;
Tcl_SetObjResult(interp, poolPtr->literals[LIT_ZERO];

Cleanup:

void
Mycommand_DeleteProc(ClientData clientData) {
     LiteralPool* poolPtr = (LiteralPool*) clientData;
     int i;
     if ((--poolPtr->refCount) == 0) {
         for (i = 0; i < LIT_COUNT; ++i) {
             Tcl_DecrRefCount(poolPtr->literals[i]);
         }
         ckfree(poolPtr);
     }
}

Most of the time, this tweak doesn't amount to anything from
the performance standpoint. But I do have a few places where
things return large lists of enumerated constants, or want to
maintain expensive internal representations (regexps, bytecodes,
etc.). For these applications, this trick is just the thing.

-- 
73 de ke9tv/2, Kevin

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

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

Pat Thoyts wrote:
> This kind of error seems to crop up regularly. How about everyone stops
> being clever and just writes in the date so that people can just read
> it. Use of seconds to describe a date in messages designed to be read by
> humans is dumb.

FWIW, I (almost) always cut-n-paste a [clock format] that's giving the
time I want when I test it out.

Donal.

Re: [TCLCORE] CVF#340 ...

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

2008/11/28 Andreas Leitgeb <av...@lo...>:
> Just wondering: the previous distinction between STATIC and
> VOLATILE is now obviously dropped. Does that mean that now
> all strings are treated as TCL_VOLATILE (and copied)?

Yes, but that's actually an improvement. Previously,
TCL_STATIC prevented a copy, but actually later a copy
would be made almost always anyway as soon as the
interpreter result is used  in further processing. Using
TCL_VOLATILE means that at the Tcl_SetResult call
a copy is made, and later - when the interpreter result
is used in further processing - it will be converted to
a Tcl_Obj, so copied again.

In short: Tcl_SetStringResult gains the same efficiency
for TCL_VOLATILE than it already had for TCL_STATIC.
The intermediate copy to interp->result is no longer
neccessary, it is copied directly to interp->objResult.

> And another one:
> < How about everyone stops being clever and just writes in the
> < date so that people can just read it.
> I guess the motivation was to post the timestamp in utc and
> make it trivial for anyone to convert it to each's local time.
Yes, I guess that's the motivation. Anyone can simply copy
the "clock seconds 12345678" part in a Tcl interpreter and
gets the time in its own timezone.

Regards,
        Jan Nijtmans

Re: [TCLCORE] CVF#340 ...

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

Joe English <jen...@fl...> wrote:
> Tcl_SetResult(interp, s, TCL_STATIC|TCL_VOLATILE);
> can generally be shortened to Tcl_SetStringResult(interp, s);
> without further thought.

Just wondering: the previous distinction between STATIC and
VOLATILE is now obviously dropped. Does that mean that now
all strings are treated as TCL_VOLATILE (and copied)?

And by the way:
< Subject: Re: [TCLCORE] a meta-TIP for "NOT YET"-votes ?
<< What would it take to add a "NOT YET" officially, to
<< remove the need for this phrase?  just curious :-)
My intention was not a reformation of the voting-system,
but a suggestion to remove the seemingly existing need for
verbal boilerplates. A "NOT YET, else(otherwise) NO" carries
the same information and requires less boilerplate typing. 

And another one:
< How about everyone stops being clever and just writes in the
< date so that people can just read it.
I guess the motivation was to post the timestamp in utc and
make it trivial for anyone to convert it to each's local time.

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

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

Jan Nijtmans:
>> This clock format does not match the specified date. Of
>> course I meant:
>>
>>     Friday dec 5th, 12:00 GMT (i.e. [clock format 1228478400]).

Pat Thoyts:
> This kind of error seems to crop up regularly. How about everyone stops
> being clever and just writes in the date so that people can just read
> it. Use of seconds to describe a date in messages designed to be read by
> humans is dumb.

Note that in this particular case, it was the human-readable form
that was incorrect. I'm not sure what conclusion is to be drawn.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] Re: CFV TIP #340

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

2008/11/27 Jan Nijtmans <nij...@us...>:
> I will create a new patch this weekend.

The revised patch is available now, at:
<https://sourceforge.net/tracker/index.php?func=detail&aid=2315890&group_id=10894&atid=310894>

The CFV is open for voting again.
My vote follows:
  revised TIP #340: YES

The TIP text is not updated yet, but I hope that will happen soon. From
the previous mails, it should be clear what's the point.

One remark about the patch: The compatibility macro in the
TCL_NO_DEPRECATED section was put there to allow Tcl
and Tk to compile without warnings for now. I'm not sure it
is a good idea to keep it there, but that's an implementation
detail so it can be decided later. It is not meant as an excuse
not to replace the remaining Tcl_SetResult calls in the core.

I am a beleaver in the "eat your own dogfood" principle: If
we deprecate a function, it should be removed from the
core (except from the implementation and a legacy
test case!). I'm still planning to do that, but it would be
too big to put in the patch.

Regards,
           Jan Nijtmans