tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Any objections to change "clock format -now" to "clock format now" ?

[Harald O. <har...@el...>]

TCL 8.6 clock format and friends have a clock seconds argument.
The value for clock second for the current time may be returned by 
[clock seconds].

To format the current day/time, the following command may be used:

% clock format [clock seconds] -format "%Y-%m-%d"
2024-07-31

TIP 688 addes the following shortcut for this for TCL8.7+:

% clock format -now -format "%Y-%m-%d"
2024-07-31

With ticket https://core.tcl-lang.org/tcl/info/cd257619
the following form was added:

% clock format now -format "%Y-%m-%d"
2024-07-31

The rationales for this:
- It is not a positional parameter (what "-" suggests). It is a special 
value for a parameter.
- 2 other commands use "now" in 8.6, none "-now" (free format date scan, 
Tk event generate)

The value "-now" still works, but is undocumented and not tested.

This change was added as an amendment to TIP 688:

https://core.tcl-lang.org/tips/doc/trunk/tip/688.md

I invite anybody to speak up now in case of objections.

Thanks to Sergey, Ashok and Schelte to make this happen!

Take care,
Harald

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

[<apn...@ya...>]

Tested 9.0b3rc1 with following platforms and configs:

Windows x64, Visual Studio 2022, shared-zipfs, static-zipfs, shared-nozipfs, static-nozipfs
Windows x64, MingW64 gcc 8, shared-zipfs, static-zipfs
Fedora 40, gcc 14, shared-zipfs, static-zipfs, shared-nozipfs, static-nozipfs
Ubuntu 20.04, gcc 9.4, shared-zipfs

No TBDC extension tested except sqlite3. Tk only tested in Windows.

TL;DR - no new failures, ok for beta3.

Failures:
On Fedora, gcc 14, zlib-8.{8,16} fail as in rc0. Not seen on Windows or Ubuntu. Ticket logged

Other usual failures (clipboard, chmod on Windows) can be ignored.

/Ashok

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Tuesday, July 30, 2024 11:09 PM
To: tcl...@li...
Subject: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate


Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0b3/

are RC1 candidate source code distribution pre-releases of Tcl 9.0b3 and Tk 9.0b3.

This is the second of a sequence of candidate releases leading to the release of
Tcl/Tk 9.0b3.  Testing of builds and operations on multiple platforms is invited.  Open
tickets on any problems discovered, or raise the issue in a reply to this message.
The aim is to clean up the problems that are easily discovered so that a broader
audience receiving the Tcl/Tk 9.0b3 release can focus attention on deeper issues
needing beta testing to discover.

The Thread package included with Tcl 9.0b3 is version Thread 3.0b4, and includes
bug fixes compared to prior bundled releases.  All other bundled packages included
with Tcl 9.0b3 are releases that have already been included in some prior Tcl release.

Unless an unexpected severe problem is found with these release artifacts, expect
them to become the Tcl/Tk 9.0b3 releases on or around July 31, 2024.

Beta releases of Tcl/Tk 9.0 have been a great success at achieving a growing circle
of testing of the broad universe of Tcl/Tk programs.  Each one has brought up bugs
and issues to be resolved, improving the quality of Tcl/Tk 9.0. Spread the word.

Thank you for your contributions and assistance.

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



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

[Csaba N. <csa...@t-...>]

Done, see commit [df9f759b].

Best regards,

Csaba


Am 31.07.24 um 08:54 schrieb Jan Nijtmans:
> Op zo 28 jul 2024 14:53 schreef Paul Obermeier:
> 
>     Affected extensions are:
>     Tk/library/print.tcl
> 
> ....
> 
> Can someone, please, remove the redundant
> "-encoding binary" in print.tcl from Tk?
> 
> Thanks!
>        Jan Nijtmans
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

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

Op zo 28 jul 2024 14:53 schreef Paul Obermeier:

> Affected extensions are:
> Tk/library/print.tcl
>
....

Can someone, please, remove the redundant
"-encoding binary" in print.tcl from Tk?

Thanks!
      Jan Nijtmans

>

Re: [TCLCORE] Question about Tcl 9 dependencies

[Torsten B. <be...@ty...>]

Hi,

thanks for looking into the tickets!

Not totally sure if this helps but TIP 430 says:
Tcl will now attempt to find a zip encoder in the environment. If a TIP #430 savvy tclsh is discovered, that shell will be used. Failing that, the system will search for an executable named zip. Failing that, tcl will build it's own zip encoder.

When it cannot locate a zip encoded in the environment, Tcl will now build a copy of the minizip program, whose source is currently distributed in /compat/zlib/contrib/minizip. The tcl.m4macro now detects if the compiler used can produce native native executables, and in cases where it cannot, will search for a C compiler that can, an substitute that value into the Makefile as HOST_CC. The C compiler will generate a native executable minizip which will be compiled in the same directory as tcl, and be used for all archive creation.

This sounds to me as if zlib is not a hard dependency but I haven't checked the implementation for whether it actually follows that specification.

Regards, Torsten


> Am 30.07.2024 um 17:53 schrieb apnmbx-public--- via Tcl-Core <tcl...@li...>:
> 
> Starting to look into Torsten’s tickets re. zipfs and documentation, the first question I ran into was whether availability of zlib is mandatory for Tcl. It is auto-detected by the configure script but the build fails if it is not available. Fixing the build results in a Tcl initialization failure (tcl_library_init not found).
>  
> So my questions
>  
> Is zlib a hard dependency for Tcl 9 (actually 8.7 as well) ? I don’t know if that was the intent of TIP 430.
> If yes, shouldn’t the configure itself fail?
> If no, some work will be required I presume to get the initialization working without zipfs. (May or may not be trivial, have not checked). In that case, is it something that can be postponed to 9.1 (i.e. 9.0 will require zlib)
>  
> /Ashok
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...>
> https://lists.sourceforge.net/lists/listinfo/tcl-core <https://lists.sourceforge.net/lists/listinfo/tcl-core>

Re: [TCLCORE] New Logo ?

[Simon G. <si...@wh...>]

I don't know if this thread is a serious push for a new logo or not, but
if it is we need to be mindful of the company TCL <www.tcl.com> which
probably has trademarks we could infringe.

Simon


On 22/07/2024 16:39, Colin Macleod via Tcl-Core wrote:
>
> Dear All,
>
> I'm wondering if it might be worth updating the Tcl logo for version
> 9.  The current feather logo is rather obscure, being based on Tcl
> sounding like "tickle", and may give the impression that it's not
> suitable for serious work.  Also it's very similar to the feather logo
> used by Apache.
>
> I've put together a couple of suggestion, trying to emphasise the
> Tools aspect of the Tool Command Language:
>
>  1. Spelling out Tcl9 with svg images of tools (all public domain)
>  2. Tcl9 as a geometrical animated GIF
>
>     This was generated by a TclMagick script, I've put the code at
>     https://cmacleod.me.uk/tcl/logo/
>
> Colin.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] New Logo - Final attempt

[Dipl. I. S. G. B. <se...@us...>]

 

Attached is also my attempt... Inspired by C++ and bash logos...
(if source needed to play with it, I can provide .xcf-file for GIMP or
.psd-file for Photoshop) 

		64 X ... (256X)
		128 X ... (256X288)
		384 X ... (1822 X 2051)

Regards, 
Serg. 

[TCLCORE] Tcl/Tk 9.0b3 Release Candidate

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

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0b3/

are RC1 candidate source code distribution pre-releases of Tcl 9.0b3 and Tk 9.0b3.

This is the second of a sequence of candidate releases leading to the release of
Tcl/Tk 9.0b3.  Testing of builds and operations on multiple platforms is invited.  Open
tickets on any problems discovered, or raise the issue in a reply to this message.
The aim is to clean up the problems that are easily discovered so that a broader
audience receiving the Tcl/Tk 9.0b3 release can focus attention on deeper issues
needing beta testing to discover.

The Thread package included with Tcl 9.0b3 is version Thread 3.0b4, and includes
bug fixes compared to prior bundled releases.  All other bundled packages included
with Tcl 9.0b3 are releases that have already been included in some prior Tcl release.

Unless an unexpected severe problem is found with these release artifacts, expect
them to become the Tcl/Tk 9.0b3 releases on or around July 31, 2024.

Beta releases of Tcl/Tk 9.0 have been a great success at achieving a growing circle
of testing of the broad universe of Tcl/Tk programs.  Each one has brought up bugs
and issues to be resolved, improving the quality of Tcl/Tk 9.0. Spread the word.

Thank you for your contributions and assistance.

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

Re: [TCLCORE] New Logo - Final attempt

[Colin M. <col...@ya...>]

Hello again,

A wiki page <https://wiki.tcl-lang.org/page/A+logo+for+Tcl+9> was 
created for this subject, and looking at the suggestions there prompted 
me to make one more try.  I switched to SVG format, which is compact, 
editable and flexible.  I tried to make something simple and 
distinctive, incorporating both the theme of tools and the traditional 
feather:

It has been suggested that anything based on the letters t-c-l could 
lead to an objection from the TCL consumer electronics company.  My 
feeling is that anything which does not say t-c-l in some form will not 
be recognisable, so I think we should take that risk.

Colin.

Re: [TCLCORE] Question about Tcl 9 dependencies

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

I'd be happy with zlib being a hard dependency, especially now that we need it also for our zipfs support. There's a contrib version of zlib in the code, so configure ought to fall back to that if it can't find a suitable system one to use (or if the user prefers it that way).

Donal.

From: apnmbx-public--- via Tcl-Core <tcl...@li...>
Sent: Tuesday, July 30, 2024 4:53 PM
To: tcl...@li...
Subject: [TCLCORE] Question about Tcl 9 dependencies

Starting to look into Torsten's tickets re. zipfs and documentation, the first question I ran into was whether availability of zlib is mandatory for Tcl. It is auto-detected by the configure script but the build fails if it is not available. Fixing the build results in a Tcl initialization failure (tcl_library_init not found).

So my questions


  1.  Is zlib a hard dependency for Tcl 9 (actually 8.7 as well) ? I don't know if that was the intent of TIP 430.
  2.  If yes, shouldn't the configure itself fail?
  3.  If no, some work will be required I presume to get the initialization working without zipfs. (May or may not be trivial, have not checked). In that case, is it something that can be postponed to 9.1 (i.e. 9.0 will require zlib)

/Ashok

[TCLCORE] Question about Tcl 9 dependencies

[<apn...@ya...>]

Starting to look into Torsten's tickets re. zipfs and documentation, the
first question I ran into was whether availability of zlib is mandatory for
Tcl. It is auto-detected by the configure script but the build fails if it
is not available. Fixing the build results in a Tcl initialization failure
(tcl_library_init not found).

 

So my questions

 

1.	Is zlib a hard dependency for Tcl 9 (actually 8.7 as well) ? I don't
know if that was the intent of TIP 430.
2.	If yes, shouldn't the configure itself fail?
3.	If no, some work will be required I presume to get the
initialization working without zipfs. (May or may not be trivial, have not
checked). In that case, is it something that can be postponed to 9.1 (i.e.
9.0 will require zlib)

 

/Ashok

Re: [TCLCORE] Documenting (and using) the new [zipfs] command

[Torsten B. <be...@ty...>]

Hi,

I have now made a few ticket on these issues. Let's continue there.


https://core.tcl-lang.org/tcl/tktview/b9f3ff8fe69cae04239a2de23601d51b289dad06

https://core.tcl-lang.org/tcl/tktview/7db9574a06b1994c5b3f8cdf13e6ffcbea072d4b

https://core.tcl-lang.org/tcl/tktview/75291b89b3d039ae0a804da61e0c3ed68320e371


I cannot reproduce issue number 8) now. This was then probably an error on my side.

Cheers, Torsten



> Am 25.07.2024 um 01:02 schrieb Torsten Berg <be...@ty...>:
> 
> Hi Harald,
> 
> good point about the safe interps or embedded ones. I can see that at least some commands are not available in safe interps. But the package seems to be loaded nonetheless. I'll have to investigate further but my best bet now is to just document the zipfs subcommands not available either in interp(n) or/and in zipfs(n). A short analysis also reveals that zipfs.c in a comment states 4 subcommands not available (mkimg, mkzip, lmkimg, lmkzip) in safe interps while in fact tclBasic.c also takes away mkkey, mount, mount_data and unmount.
> 
> Further, looking at the implementation in zipfs.c, all helper commands and variables are created in the ::tcl::zipfs namespace, the ensemble command is created in the global namspace and the package is provided as tcl::zipfs. So the documentation is right but maybe you are also right that it should actually be provided as ::tcl::zipfs instead.
> 
> 
> By the way, when the fact that the namespace path is absolute (i.e. begins with ::) is important, then a change in process(n) and prefix(n) is also needed as the announce the name of the command as tcl::process and tcl::prefix but the synopsis states ::tcl::process and ::tcl::prefix.
> 
> Cheers, Torsten
> 
> 
>> Am 24.07.2024 um 11:08 schrieb Harald Oehlmann <har...@el...>:
>> 
>> Signierter PGP-Teil
>> Am 23.07.2024 um 00:22 schrieb Torsten Berg:
>> 
>> Hi Torsten,
>> great test and analysis. So many questions. Around 15 tickets may be good for all this....
>> 
>> May I give opinions on some points:
>> 
>>> 1)
>>> The manual page indicates that you need
>>> 
>>>     package require tcl::zipfs ?1.0?
>>> 
>>> in order to use zipfs. This does not seem true with Tcl9.0b3 where I can just run the last example of the manual page without that line. Is this line obsolete?
>> 
>> I think, it is common to have a line like this.
>> If, by chance, it is already loaded by other means, then you have it for sure. It might be like msgcat, what is always loaded by tk.
>> If tclsh loads it by default, this may be mentioned. Nevertheless, embeded interpeters may not do so. Also, save interpreters may not.
>> More questions than answers, sorry.
>> 
>> For 9.0, I would love to see "::" in front of "tcl":
>> 
>> package require ::tcl::zipfs ?2.0?
>> 
>> I hope, others will comment on all points.
>> 
>> Harald
>> 
>> 
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

AppExitHandler in threadPoolCmd attempts to release the pool while
unloading. When a TpoolWorker exits, it attempts to Tcl_DeleteInterp at
line 1274, which ends up calling TclpThreadGetGlobalTSD but tsdGlobal.key
is NULL by that time as described in my original message.

In the given example, one can "::tpool::release $pool" and wait/sleep for a
while for all TpoolWorker to exit and there would be no issue.

But, still, I think freeing the TSD before unloading extensions seems to be
in the wrong place. I leave that to those who know the code better to
figure out if any change is required here.

Please note that without "clock format", I could not get it to fail but
that's most likely because "clock format" just references some Tcl_Obj.

I hope it helps.

Kind regards,
Neophytos

PS. Please note that, I realized later, that the example did not have to be
so convoluted. A simple "::tpool::post $pool [list sayhi]" in test.tcl and
a "clock format 1722260433" in somefile.tcl (without requiring the Thread
package again) still fails.

On Mon, Jul 29, 2024 at 9:51 AM Neophytos Demetriou <neo...@gm...>
wrote:

> The following consistently fails with Thread package 3.0b2 on linux using
> tcl 9.0b2 when you run "tclsh9.0 test.tcl"
>
> == test.tcl ==
> package require Thread
> set pool [::tpool::create -minworkers 1 -maxworkers 4 -idletime 5 -initcmd
> [list source somefile.tcl]]
> ::tpool::post -detached -nowait $pool [list sayhi]
> after 10000 [list set v 1]
> vwait v
>
> == somefile.tcl ==
> package require Thread
> proc sayhi {} {
>     set fmt {[%d/%b/%Y:%H:%M:%S %z]}
>     puts str=[clock format 1722260433 -format $fmt]
> }
>
> == Here is the message from the AddressSanitizer ==
>
> /home/phi/build-projects/tcl9.0b2/unix/tclUnixThrd.c:915:12: runtime
> error: load of null pointer of type 'pthread_key_t'
> AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==71907==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
> (pc 0x7f27d6a09c7f bp 0x7f27cc225910 sp 0x7f27cc2258f0 T1)
> ==71907==The signal is caused by a READ memory access.
> ==71907==Hint: address points to the zero page.
> AddressSanitizer:DEADLYSIGNAL
> AddressSanitizer: nested bug in the same thread, aborting.
>
> == Here is how I compiled tcl 9.0b2 ==
>
> CFLAGS="-fsanitize=address -fsanitize=undefined -DPURIFY"
> LDFLAGS="-fsanitize=address -fsanitize=undefined" ./configure
> --enable-symbols=all
>
>
> On Mon, Jul 29, 2024 at 7:57 AM Neophytos Demetriou <neo...@gm...>
> wrote:
>
>> hmm, I disabled all above extensions and it still occurs, which reminded
>> me I also use Thread package 3.0b2 and some preliminary investigation seems
>> to show that it only happens when Thread package is loaded (3.0b2)
>>
>> more tomorrow and again sorry for wasting your time
>>
>> - Neophytos
>>
>>
>> On Mon, Jul 29, 2024 at 7:22 AM Neophytos Demetriou <neo...@gm...>
>> wrote:
>>
>>> Hi Sergey,
>>>
>>> Thanks for your message. Answers below.
>>>
>>> did you test it before or after [96910cd8822ffb8f]
>>>> <https://core.tcl-lang.org/tcl/info/96910cd8822ffb8f>? Just to ensure
>>>> it is still acute...
>>>>
>>>
>>> It was with tcl 9.0b2, so before that change.
>>>
>>>
>>>> The whole "unload" thing was initially introduced by Nathan in
>>>> [3b0e92b198b86975]
>>>> <https://core.tcl-lang.org/tcl/info/3b0e92b198b86975>, however it
>>>> seemed to have some issues (like [34870ab5756911d1]
>>>> <https://core.tcl-lang.org/tcl/info/34870ab5756911d1> or
>>>> [ae09f6b190ceec31]
>>>> <https://core.tcl-lang.org/tcl/info/ae09f6b190ceec31>), which I tried
>>>> to fix in the last time as good as I was able to do that.
>>>>
>>>
>>> I cannot tell if it is relevant or not. It does not look like it.
>>>
>>>
>>>> Which versions (and platforms) are affected or do you mean exactly
>>>> here? Is it stock tcl or some application of you, that uses Tcl as a
>>>> subsystem (in particular, it is Tcl_Main* or your own main)?
>>>>
>>>
>>> It was a tcl file that loaded twebserver in the main thread and
>>> twebserver, tjson and thtml in the spawn twebserver threads. All of these
>>> extensions were using Tcl_CreateThreadExitHandler in their initialization
>>> function. They did not have to but I did not notice that was the case
>>> before this issue. Changing them all to use CreateExitHandler seems to have
>>> resolved the issue.
>>>
>>> I will investigate further tomorrow and report back but my guess is that
>>> there is a TCL_TSD_INIT used somewhere when the thread exit handler runs
>>> that causes this issue during unload.
>>>
>>> Regards,
>>> Neophytos
>>>
>>> PS. My apologies but I have to run right now. I will check further
>>> tomorrow and report back.
>>>
>>> Regards,
>>>> Sergey.
>>>>
>>>> 29.07.2024 10:29, Neophytos Demetriou wrote:
>>>>
>>>> Hi,
>>>>
>>>> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn
>>>> calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
>>>> TclFinalizeThreadStorage.
>>>>
>>>> Then, when it afterwards tries to unload extensions, it attempts to use
>>>> the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
>>>> AddressSanitizer complains about a NULL pthread key.
>>>>
>>>> I was not able to track where the TSD is used during unloading or if
>>>> this is an issue with the extensions being used and whether they have to
>>>> unload in a specific way. As a consequence I stopped using the PURIFY flag
>>>> but if anyone has any suggestions, please let us know.
>>>>
>>>> Kind regards,
>>>> Neophytos
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>>

Re: [TCLCORE] namespace resolution of srcCmd in "interp alias"

[Dipl. I. S. G. B. <se...@us...>]

 

_[interp alias]_ creates an alias which never considers current
namespace during the creation of alias "command". 

It is just alias for given interpreter _srcPath_ to some command in the
another interpreter _targetPath_.
Even if the srcPath identifies current interpreter (e. g. is empty),
it'll never consider namespace of some frame of this interpreter by the
creation. 

Thereby, as documentation says, _srcCmd_ gives the name of a new
command, which will be created in the source interpreter (specified with
_srcPath_). It would be very strange if that would consider some frame. 

With other words, the nature of the _[interp alias]_ command is rather
frame-less. 

However, playing with _[interp]_ a bit, I must admit I see small
inconsistency now between _[interp alias]_ and _[interp eval]_: 

% namespace eval ns { interp eval {} namespace current }
::ns
% namespace eval ns { interp eval {} { proc xxx {} {} } }; info command
ns::x*
::ns::xxx

because _[interp eval], _in opposite to _[interp alias]_, seems to
consider current frame (and so create command in current namespace)...
what is a bit confusing after all (I'd rather expect that both works
more similar). 

Anyway I'd like to make both consistent to each others (just so or so it
is backwards incompatible change and would have large consequences at
script level, so definitely needs a TIP). 
-------------------------

By the way (if we speaking about frames by some commands), I never
missed the NS in the form by _[interp alias]_, but always missed it by
lambdas without given namespace for _apply_ command (where by default I
would always prefer the current namespace to global namespace): 

% namespace eval ns { apply {{} { puts "lambda in [namespace current]"
}} }
lambda in ::
% namespace eval ns { apply [list {} { puts "lambda in [namespace
current]" } [namespace current]] }
lambda in ::ns

Just because it always expects a _[list ...]_ form (so in opposite to
braced form can be never a literal), as well as not always simply
possible if the lambda shall work across namespaces (same code used in
several namespaces), without "tricks" by manipulating the list, e. g.
with linsert, lreplace or lset, like that: 

% namespace eval ns { apply [linsert {{} { puts "lambda in [namespace
current]" }} end [namespace current]] }

lambda in ::ns

what looks ugly, slow and would always expect a modification on the
lambda object. 

In my opinion this is much worse situation than with _[interp alias]_.
And I'd rather "fix" this one firstly. 

Regards,
Sergey.

29.07.2024 15:25, Gustaf Neumann (sslmail) wrote: 

> Dear all, 
> 
> I was recently caught by a mistake which is not easy to spot. In the following script, 
> - the namespace resolution of the unqualified name "NAME1" when creating a proc leads to "[namespace current]::NAME1", while 
> - the namespace resolution of the unqualified name "NAME2" when creating an alias leads to "::NAME2". 
> 
> The following snippet creates via interp alias the cmd ::log 
> 
>> namespace eval ::ns1 { 
>> proc log args {puts stderr "LOG called"} 
>> } 
>> namespace eval ::ns1::sub { 
>> 
>> proc foo {} { 
>> 
>> log foo 
>> 
>> } 
>> 
>> interp alias {} log {} ::ns1::log 
>> 
>> }
> 
> while the following leads to the result i was expecting. Same results on Tcl8 and Tcl9 
> 
> All the best 
> -g 
> 
>> namespace eval ::ns1 { 
>> proc log args {puts stderr "LOG called"} 
>> } 
>> namespace eval ::ns1::sub { 
>> proc foo {} { 
>> log foo 
>> } 
>> interp alias {} [namespace current]::log {} ::ns1::log 
>> }
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

The following consistently fails with Thread package 3.0b2 on linux using
tcl 9.0b2 when you run "tclsh9.0 test.tcl"

== test.tcl ==
package require Thread
set pool [::tpool::create -minworkers 1 -maxworkers 4 -idletime 5 -initcmd
[list source somefile.tcl]]
::tpool::post -detached -nowait $pool [list sayhi]
after 10000 [list set v 1]
vwait v

== somefile.tcl ==
package require Thread
proc sayhi {} {
    set fmt {[%d/%b/%Y:%H:%M:%S %z]}
    puts str=[clock format 1722260433 -format $fmt]
}

== Here is the message from the AddressSanitizer ==

/home/phi/build-projects/tcl9.0b2/unix/tclUnixThrd.c:915:12: runtime error:
load of null pointer of type 'pthread_key_t'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==71907==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f27d6a09c7f bp 0x7f27cc225910 sp 0x7f27cc2258f0 T1)
==71907==The signal is caused by a READ memory access.
==71907==Hint: address points to the zero page.
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer: nested bug in the same thread, aborting.

== Here is how I compiled tcl 9.0b2 ==

CFLAGS="-fsanitize=address -fsanitize=undefined -DPURIFY"
LDFLAGS="-fsanitize=address -fsanitize=undefined" ./configure
--enable-symbols=all


On Mon, Jul 29, 2024 at 7:57 AM Neophytos Demetriou <neo...@gm...>
wrote:

> hmm, I disabled all above extensions and it still occurs, which reminded
> me I also use Thread package 3.0b2 and some preliminary investigation seems
> to show that it only happens when Thread package is loaded (3.0b2)
>
> more tomorrow and again sorry for wasting your time
>
> - Neophytos
>
>
> On Mon, Jul 29, 2024 at 7:22 AM Neophytos Demetriou <neo...@gm...>
> wrote:
>
>> Hi Sergey,
>>
>> Thanks for your message. Answers below.
>>
>> did you test it before or after [96910cd8822ffb8f]
>>> <https://core.tcl-lang.org/tcl/info/96910cd8822ffb8f>? Just to ensure
>>> it is still acute...
>>>
>>
>> It was with tcl 9.0b2, so before that change.
>>
>>
>>> The whole "unload" thing was initially introduced by Nathan in
>>> [3b0e92b198b86975] <https://core.tcl-lang.org/tcl/info/3b0e92b198b86975>,
>>> however it seemed to have some issues (like [34870ab5756911d1]
>>> <https://core.tcl-lang.org/tcl/info/34870ab5756911d1> or
>>> [ae09f6b190ceec31] <https://core.tcl-lang.org/tcl/info/ae09f6b190ceec31>),
>>> which I tried to fix in the last time as good as I was able to do that.
>>>
>>
>> I cannot tell if it is relevant or not. It does not look like it.
>>
>>
>>> Which versions (and platforms) are affected or do you mean exactly here?
>>> Is it stock tcl or some application of you, that uses Tcl as a subsystem
>>> (in particular, it is Tcl_Main* or your own main)?
>>>
>>
>> It was a tcl file that loaded twebserver in the main thread and
>> twebserver, tjson and thtml in the spawn twebserver threads. All of these
>> extensions were using Tcl_CreateThreadExitHandler in their initialization
>> function. They did not have to but I did not notice that was the case
>> before this issue. Changing them all to use CreateExitHandler seems to have
>> resolved the issue.
>>
>> I will investigate further tomorrow and report back but my guess is that
>> there is a TCL_TSD_INIT used somewhere when the thread exit handler runs
>> that causes this issue during unload.
>>
>> Regards,
>> Neophytos
>>
>> PS. My apologies but I have to run right now. I will check further
>> tomorrow and report back.
>>
>> Regards,
>>> Sergey.
>>>
>>> 29.07.2024 10:29, Neophytos Demetriou wrote:
>>>
>>> Hi,
>>>
>>> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn
>>> calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
>>> TclFinalizeThreadStorage.
>>>
>>> Then, when it afterwards tries to unload extensions, it attempts to use
>>> the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
>>> AddressSanitizer complains about a NULL pthread key.
>>>
>>> I was not able to track where the TSD is used during unloading or if
>>> this is an issue with the extensions being used and whether they have to
>>> unload in a specific way. As a consequence I stopped using the PURIFY flag
>>> but if anyone has any suggestions, please let us know.
>>>
>>> Kind regards,
>>> Neophytos
>>>
>>> _______________________________________________
>>> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>>>

[TCLCORE] namespace resolution of srcCmd in "interp alias"

[Gustaf N. (sslmail) <ne...@wu...>]

Dear all,

I was recently caught by a mistake which is not easy to spot. In the following script,
- the namespace resolution of the unqualified name “NAME1” when creating a proc leads to "[namespace current]::NAME1", while
- the namespace resolution of the unqualified name “NAME2” when creating an alias leads to “::NAME2”.

The following snippet creates via interp alias the cmd ::log

namespace eval ::ns1 {
    proc log args {puts stderr "LOG called"}
}
namespace eval ::ns1::sub {
    proc foo {} {
        log foo
    }
    interp alias {} log {} ::ns1::log
}

while the following leads to the result i was expecting. Same results on Tcl8 and Tcl9

All the best 
-g


namespace eval ::ns1 {
    proc log args {puts stderr "LOG called"}
}
namespace eval ::ns1::sub {
    proc foo {} {
        log foo
    }
    interp alias {} [namespace current]::log {} ::ns1::log
}

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

hmm, I disabled all above extensions and it still occurs, which reminded me
I also use Thread package 3.0b2 and some preliminary investigation seems to
show that it only happens when Thread package is loaded (3.0b2)

more tomorrow and again sorry for wasting your time

- Neophytos


On Mon, Jul 29, 2024 at 7:22 AM Neophytos Demetriou <neo...@gm...>
wrote:

> Hi Sergey,
>
> Thanks for your message. Answers below.
>
> did you test it before or after [96910cd8822ffb8f]
>> <https://core.tcl-lang.org/tcl/info/96910cd8822ffb8f>? Just to ensure it
>> is still acute...
>>
>
> It was with tcl 9.0b2, so before that change.
>
>
>> The whole "unload" thing was initially introduced by Nathan in
>> [3b0e92b198b86975] <https://core.tcl-lang.org/tcl/info/3b0e92b198b86975>,
>> however it seemed to have some issues (like [34870ab5756911d1]
>> <https://core.tcl-lang.org/tcl/info/34870ab5756911d1> or
>> [ae09f6b190ceec31] <https://core.tcl-lang.org/tcl/info/ae09f6b190ceec31>),
>> which I tried to fix in the last time as good as I was able to do that.
>>
>
> I cannot tell if it is relevant or not. It does not look like it.
>
>
>> Which versions (and platforms) are affected or do you mean exactly here?
>> Is it stock tcl or some application of you, that uses Tcl as a subsystem
>> (in particular, it is Tcl_Main* or your own main)?
>>
>
> It was a tcl file that loaded twebserver in the main thread and
> twebserver, tjson and thtml in the spawn twebserver threads. All of these
> extensions were using Tcl_CreateThreadExitHandler in their initialization
> function. They did not have to but I did not notice that was the case
> before this issue. Changing them all to use CreateExitHandler seems to have
> resolved the issue.
>
> I will investigate further tomorrow and report back but my guess is that
> there is a TCL_TSD_INIT used somewhere when the thread exit handler runs
> that causes this issue during unload.
>
> Regards,
> Neophytos
>
> PS. My apologies but I have to run right now. I will check further
> tomorrow and report back.
>
> Regards,
>> Sergey.
>>
>> 29.07.2024 10:29, Neophytos Demetriou wrote:
>>
>> Hi,
>>
>> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn
>> calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
>> TclFinalizeThreadStorage.
>>
>> Then, when it afterwards tries to unload extensions, it attempts to use
>> the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
>> AddressSanitizer complains about a NULL pthread key.
>>
>> I was not able to track where the TSD is used during unloading or if this
>> is an issue with the extensions being used and whether they have to unload
>> in a specific way. As a consequence I stopped using the PURIFY flag but if
>> anyone has any suggestions, please let us know.
>>
>> Kind regards,
>> Neophytos
>>
>> _______________________________________________
>> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

Hi Sergey,

Thanks for your message. Answers below.

did you test it before or after [96910cd8822ffb8f]
> <https://core.tcl-lang.org/tcl/info/96910cd8822ffb8f>? Just to ensure it
> is still acute...
>

It was with tcl 9.0b2, so before that change.


> The whole "unload" thing was initially introduced by Nathan in
> [3b0e92b198b86975] <https://core.tcl-lang.org/tcl/info/3b0e92b198b86975>,
> however it seemed to have some issues (like [34870ab5756911d1]
> <https://core.tcl-lang.org/tcl/info/34870ab5756911d1> or
> [ae09f6b190ceec31] <https://core.tcl-lang.org/tcl/info/ae09f6b190ceec31>),
> which I tried to fix in the last time as good as I was able to do that.
>

I cannot tell if it is relevant or not. It does not look like it.


> Which versions (and platforms) are affected or do you mean exactly here?
> Is it stock tcl or some application of you, that uses Tcl as a subsystem
> (in particular, it is Tcl_Main* or your own main)?
>

It was a tcl file that loaded twebserver in the main thread and twebserver,
tjson and thtml in the spawn twebserver threads. All of these extensions
were using Tcl_CreateThreadExitHandler in their initialization function.
They did not have to but I did not notice that was the case before this
issue. Changing them all to use CreateExitHandler seems to have resolved
the issue.

I will investigate further tomorrow and report back but my guess is that
there is a TCL_TSD_INIT used somewhere when the thread exit handler runs
that causes this issue during unload.

Regards,
Neophytos

PS. My apologies but I have to run right now. I will check further tomorrow
and report back.

Regards,
> Sergey.
>
> 29.07.2024 10:29, Neophytos Demetriou wrote:
>
> Hi,
>
> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn
> calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
> TclFinalizeThreadStorage.
>
> Then, when it afterwards tries to unload extensions, it attempts to use
> the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
> AddressSanitizer complains about a NULL pthread key.
>
> I was not able to track where the TSD is used during unloading or if this
> is an issue with the extensions being used and whether they have to unload
> in a specific way. As a consequence I stopped using the PURIFY flag but if
> anyone has any suggestions, please let us know.
>
> Kind regards,
> Neophytos
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

[Stefan S. <ste...@wu...>]

> PS: i had a little struggle from my test scripts, since there is no tag “core-9-0-b3”, but “-b1” and “-b2”.
>  From a branch, the download of a tar file works differently than from a tag (using ...?uuid=TAG)

This is because these are RCs of the a future b3 release, if I am not 
mistaken? (There is a "core-9-0-b3-rc" branch, for now.)

Best, Stefan

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Dipl. I. S. G. B. <se...@us...>]

 

Hi, 

did you test it before or after [96910cd8822ffb8f] [2]? Just to ensure
it is still acute... 

The whole "unload" thing was initially introduced by Nathan in
[3b0e92b198b86975] [3], however it seemed to have some issues (like
[34870ab5756911d1] [4] or [ae09f6b190ceec31] [5]), which I tried to fix
in the last time as good as I was able to do that. 

Regarding the complain in AddressSanitizer: at first glance, I don't see
where this unload facility may be affected by finalization, because the
whole stuff seems to be interpreter related, but
TclFinalizeThreadStorage (as well as Tcl_Finalize) must be invoked
firstly if all interpreters become deleted. 

Also it is questionable that unload shall be invoked after
TclFinalizeFilesystem (which takes place before
TclFinalizeSynchronization and TclFinalizeThreadStorage), because the
library may be from VFS, so something seems to be totally wrong there. 

So maybe it is not this stuff and was even longer there. 

Which versions (and platforms) are affected or do you mean exactly here?
Is it stock tcl or some application of you, that uses Tcl as a subsystem
(in particular, it is Tcl_Main* or your own main)? 

Regards,
Sergey. 

29.07.2024 10:29, Neophytos Demetriou wrote: 

> Hi, 
> 
> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via TclFinalizeThreadStorage. 
> 
> Then, when it afterwards tries to unload extensions, it attempts to use the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the AddressSanitizer complains about a NULL pthread key. 
> 
> I was not able to track where the TSD is used during unloading or if this is an issue with the extensions being used and whether they have to unload in a specific way. As a consequence I stopped using the PURIFY flag but if anyone has any suggestions, please let us know. 
> 
> Kind regards, 
> Neophytos 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tcl/info/96910cd8822ffb8f
[3] https://core.tcl-lang.org/tcl/info/3b0e92b198b86975
[4] https://core.tcl-lang.org/tcl/info/34870ab5756911d1
[5] https://core.tcl-lang.org/tcl/info/ae09f6b190ceec31

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

[Gustaf N. (sslmail) <ne...@wu...>]

Tests with NaviServer trunk: compilation and regression test ok
Tests with nsf:  compilation and regression test ok

Everything is fine, good work!
-g

PS: i had a little struggle from my test scripts, since there is no tag “core-9-0-b3”, but “-b1” and “-b2”.
From a branch, the download of a tar file works differently than from a tag (using ...?uuid=TAG)


> On 25.07.2024, at 20:46, Donald G Porter via Tcl-Core <tcl...@li...> wrote:
> 
> 
> Now available at
> 
> https://sourceforge.net/projects/tcl/files/Tcl/9.0b3/
> 
> are RC0 candidate source code distribution pre-releases of Tcl 9.0b3 and Tk 9.0b3.
> 
> This is the first of a sequence of candidate releases leading to the release of
> Tcl/Tk 9.0b3.  Testing of builds and operations on multiple platforms is invited.  Open
> tickets on any problems discovered, or raise the issue in a reply to this message.
> The aim is to clean up the problems that are easily discovered so that a broader
> audience receiving the Tcl/Tk 9.0b3 release can focus attention on deeper issues
> needing beta testing to discover.
> 
> The Thread package included with Tcl 9.0b3 is version Thread 3.0b4, and includes
> bug fixes compared to prior bundled releases.  All other bundled packages included
> with Tcl 9.0b3 are releases that have already been included in some prior Tcl release.
> 
> Documentation is not yet included while some failures of `make html` are resolved.
> 
> Beta releases of Tcl/Tk 9.0 have been a great success at achieving a growing circle
> of testing of the broad universe of Tcl/Tk programs.  Each one has brought up bugs
> and issues to be resolved, improving the quality of Tcl/Tk 9.0. Spread the word.
> 
> Thank you for your contributions and assistance.
> 
> -- 
> 
> | Don Porter            Applied and Computational Mathematics Division |
> | don...@ni...             Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/                                  NIST |
> |______________________________________________________________________|
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

Not 100% sure but this seems to be an issue with the extensions as they
were using CreateThreadExitHandler instead of CreateExitHandler.

Sorry for wasting your time.

- Neophytos

On Mon, Jul 29, 2024 at 4:29 AM Neophytos Demetriou <neo...@gm...>
wrote:

> Hi,
>
> When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn
> calls TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
> TclFinalizeThreadStorage.
>
> Then, when it afterwards tries to unload extensions, it attempts to use
> the TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
> AddressSanitizer complains about a NULL pthread key.
>
> I was not able to track where the TSD is used during unloading or if this
> is an issue with the extensions being used and whether they have to unload
> in a specific way. As a consequence I stopped using the PURIFY flag but if
> anyone has any suggestions, please let us know.
>
> Kind regards,
> Neophytos
>

[TCLCORE] PURIFY and unloading extensions issue (?)

[Neophytos D. <neo...@gm...>]

Hi,

When the PURIFY flag is used Tcl_Exit calls Tcl_Finalize that in turn calls
TclFinalizeSynchronization, which sets tsdGlobal.key to NULL via
TclFinalizeThreadStorage.

Then, when it afterwards tries to unload extensions, it attempts to use the
TSD (thread-specific data) again and because tsdGlobal.key is NULL, the
AddressSanitizer complains about a NULL pthread key.

I was not able to track where the TSD is used during unloading or if this
is an issue with the extensions being used and whether they have to unload
in a specific way. As a consequence I stopped using the PURIFY flag but if
anyone has any suggestions, please let us know.

Kind regards,
Neophytos

Re: [TCLCORE] Tcl/Tk 9.0b3 Release Candidate

[Paul O. <pa...@po...>]

Builds fine on my BAWT build environments using Windows, Linux, Mac, Raspi.

A note to extension developers:
With Tcl 9.0.b3 the fconfigure option "-encoding binary" is no longer supported and throws an error.
Affected extensions are:
Tk/library/print.tcl
critcl
ooxml
tcllib (several modules)
tclssg
Tkhtml
tklib/ico

This new behaviour is also not yet listed at
https://core.tcl-lang.org/tcl/wiki?name=Migrating%20scripts%20to%20Tcl%209

Regards,
Paul

Am 25.07.2024 um 20:46 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.0b3/
>
> are RC0 candidate source code distribution pre-releases of Tcl 9.0b3 and Tk 9.0b3.
>
> This is the first of a sequence of candidate releases leading to the release of
> Tcl/Tk 9.0b3.  Testing of builds and operations on multiple platforms is invited.  Open
> tickets on any problems discovered, or raise the issue in a reply to this message.
> The aim is to clean up the problems that are easily discovered so that a broader
> audience receiving the Tcl/Tk 9.0b3 release can focus attention on deeper issues
> needing beta testing to discover.
>
> The Thread package included with Tcl 9.0b3 is version Thread 3.0b4, and includes
> bug fixes compared to prior bundled releases.  All other bundled packages included
> with Tcl 9.0b3 are releases that have already been included in some prior Tcl release.
>
> Documentation is not yet included while some failures of `make html` are resolved.
>
> Beta releases of Tcl/Tk 9.0 have been a great success at achieving a growing circle
> of testing of the broad universe of Tcl/Tk programs.  Each one has brought up bugs
> and issues to be resolved, improving the quality of Tcl/Tk 9.0. Spread the word.
>
> Thank you for your contributions and assistance.
>

Re: [TCLCORE] clock command - "now" vs "-now"

[Schelte B. <tc...@tc...>]

Hello Harold,

Thanks for pointing me at the ticket. I was not aware of its existence.

But note that I did not mention clock scan at all. Simply based on what 
it means in the clock format command, "now" makes much more sense than 
"-now".

I also don't agree that two different commands couldn't use the same 
word for slightly different things. After all both lindex and string 
index accept the value "end". One for addressing a list element and the 
other for a character.

In the ticket I see that "-now" can also be used as the value for the 
"-base" option. In that usage it's even stranger to use a (quasi) option 
as the value for another option.

I will update the ticket with my point of view.


Thanks,
Schelte.


On 27/07/2024 14:40, Harald Oehlmann wrote:
> Schelte, Ashok,
> 
> I think, we are on the wrong track. There are two forms of "now", one 
> for free form scan ("now"), one for "[clock seconds]" replacement ("-now").
> 
> They should be different. Due to that, Sergey has chosen "-now" and 
> "now" (what was already there).
> 
> At least, that is the way I understand the post by Sergey to the ticket:
> https://core.tcl-lang.org/tcl/info/cd25761979da7be2
> 
> Take care,
> Harald
> 
> 
> Am 26.07.2024 um 22:38 schrieb Schelte Bron:
>> I totally agree. The value "-now" looks like it's an option, but it's 
>> clearly not. You can't use [clock format -format %T -now]. Being a 
>> value rather than an option, it would then have to be interpreted as 
>> "negative now". But that doesn't make any sense.
>>
>> What the value is supposed to be is shorthand for [clock seconds], 
>> similar to how "end" is shorthand for [expr {[string length $str] - 
>> 1}] in [string index $str end]. In that case we don't use "-end". 
>> Equally, it shouldn't be "-now" for clock format.
>>
>> Maybe at some point in the future, it may even be deemed useful to 
>> allow simple arithmetic on the value, just like with end. For example 
>> to easily create an expires header:
>>
>> set expires [clock format now+3600 -format $datefmt -timezone UTC]
>>
>> Having to write that as "-now+3600" would be even more confusing than 
>> just "-now" already is.
>>
>> I'm not saying that allowing simple arithmetic on "now" is worth the 
>> trouble, but who knows what the future may bring? There is no reason 
>> to make that possibility more awkward than it has to be.
>>
>> I can imagine that not a lot of thought has gone into naming the 
>> shorthand value, as it was introduced as part of a much larger rewrite 
>> of the implementation of the clock command. It was just a quick and 
>> simple "nice to have" addition. But please, let's get this corrected 
>> before it starts to be used in so many scripts that we're stuck with 
>> it until Tcl 10.
>>
>>
>> Schelte.
>>
>>
>> On 24/07/2024 10:04, apnmbx-public--- via Tcl-Core wrote:
>>> % clock scan now
>>>
>>> 1721803544
>>>
>>> % clock format now
>>>
>>> bad seconds "now": must be -now or integer
>>>
>>> % clock format -now
>>>
>>> Wed Jul 24 12:16:03 IST 2024
>>>
>>> The above seems incongruous to me, why -now for format and “now” for 
>>> scan?
>>>
>>> Afaict, “-now” is really a value, not an option. And unlike options, 
>>> it cannot appear at arbitrary points in the command, only in place of 
>>> the time value.
>>>
>>> Is there a rationale for the difference? If no, is it too late to 
>>> change for 9.0? If too late for compatibility reasons, can clock 
>>> format and clock add treat “now” and “-now” as synonyms with latter 
>>> deprecated? (With a TIP of course)
>>>
>>> /Ashok
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core