tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Questions regarding: Do not use widget names for script names

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

Hi Donal,
thanks for the message.
That sounds all very complicated.
Wouldn't it possible:
- to use a default class name (like TkMain) ?
- Modify the class name by an explicit option (like wish.exe 
-toplevelclassname myname). We already have options support and the 
current mechanism ignores it. So (wish.exe -- scale) still sees "scale" 
as class name.
I see no way out.
Or we disable this on MS-Windows (as it is a Linux feature where we have 
those resource data bases) and the Linux folks may continue the error 
dance... I understand, that it is a neat feature, that automatically, a 
resource data base key is chosen in dependency of the script name. But 
that is not, what is implemented. It just takes an arbitrary argument 
and uses it as toplevel class name (as key for the resource data base).

But, in my case, it is not a script name. A script name is passed by the 
"-f" option and should always be. In my case, it is arguments passed to 
the args array, which may be arbitrary.

Anyway, the train to change this for 9.0 has left a year ago. It may 
happen in the future. Tk needs so much love...

Thanks for all,
Harald

Am 08.08.2024 um 10:40 schrieb Donal Fellows:
> Trouble is, it's a consequence of quite a few other things. In particular, the default name of the main widget and the main widget class are derived from the name of the script (because they've got to be *something* non-empty and there isn't a better choice; the names can't contain ".") and that has many downstream consequences, especially in bindings and option handling, where matching the class of a standard widget can be "fun". I've no idea what a better default for name and class name would be.
> 
> The best option as a user is to set the name and class by setting options in argv prior to creating the main widget, which is by genuine arguments when using wish. The arguments are parsed when creating the main widget prior to making the X11 Widget instance, so you don't have time to do much script trickery (unless you do [package require Tk] in tclsh). Indeed, it's probably a good idea to do that for every toplevel widget (or frame that can become a toplevel). It's irritating that you can only do this on widget creation, but that's one of the times when this information is needed most acutely; I don't see that changing. Note that whatever we do to alter the behaviour of Tk, I think I'll still recommend this.
> 
> The best option for Tk 9.0 would probably be to alter the widget class names, likely to prefix them with "Tk"... except that this is really quite likely to have impacts on more complex scripts (and I've no idea how to handle Ttk there, as the style mechanism also tangles into this). I guess that 9.0 would be the time to do this, but it's going to be annoying to users and isn't strictly necessary. We can simply let the current situation continue.
> 
> It's not as bad as using 'open' as the name of a photo image (a fairly likely choice if you've not much experience) as that causes really very noticeable weird breakage. Explicitly naming photo images is an attractive nuisance if you ask me...
> 
> Donal.
> 
>> -----Original Message-----
>> From: Harald Oehlmann <har...@el...>
>> Sent: Tuesday, August 6, 2024 7:20 AM
>> To: tcl...@li...
>> Subject: Re: [TCLCORE] Questions regarding: Do not use widget names for
>> script names
>>
>> Am 05.08.2024 um 23:30 schrieb Paul Obermeier:
>>> A question to the Tcl core team.
>>>
>>> Are there plans for Tcl9 to remove the (unexpected) behaviour, that
>>> script file names are not allowed to have the names of widgets, as
>>> described ex. here:
>>> https://stackoverflow.com/questions/37087930/error-unknown-option-
>> stat
>>> e-occurs-when-running-a-script-named-button-tcl
>>>
>>> Although an experienced Tcl'er I recently stumbled across that problem
>>> when writing a simple test script and it took me some time to remember
>>> that behaviour.
>>> It does not seem to be mentioned in the official documentation.
>>>
>>> Paul
>>
>> +1
>>
>> I took months to find those errors. My use case was "wish.exe scale" and the
>> Tk class was overwritten and some widgets did not work any more.
>>
>> Well
>>
>> + 1000
>>
>> to get rid of this.
>>
>> Thanks,
>> Harald

Re: [TCLCORE] Questions regarding: Do not use widget names for script names

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

Trouble is, it's a consequence of quite a few other things. In particular, the default name of the main widget and the main widget class are derived from the name of the script (because they've got to be *something* non-empty and there isn't a better choice; the names can't contain ".") and that has many downstream consequences, especially in bindings and option handling, where matching the class of a standard widget can be "fun". I've no idea what a better default for name and class name would be.

The best option as a user is to set the name and class by setting options in argv prior to creating the main widget, which is by genuine arguments when using wish. The arguments are parsed when creating the main widget prior to making the X11 Widget instance, so you don't have time to do much script trickery (unless you do [package require Tk] in tclsh). Indeed, it's probably a good idea to do that for every toplevel widget (or frame that can become a toplevel). It's irritating that you can only do this on widget creation, but that's one of the times when this information is needed most acutely; I don't see that changing. Note that whatever we do to alter the behaviour of Tk, I think I'll still recommend this.

The best option for Tk 9.0 would probably be to alter the widget class names, likely to prefix them with "Tk"... except that this is really quite likely to have impacts on more complex scripts (and I've no idea how to handle Ttk there, as the style mechanism also tangles into this). I guess that 9.0 would be the time to do this, but it's going to be annoying to users and isn't strictly necessary. We can simply let the current situation continue.

It's not as bad as using 'open' as the name of a photo image (a fairly likely choice if you've not much experience) as that causes really very noticeable weird breakage. Explicitly naming photo images is an attractive nuisance if you ask me...

Donal.

> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Tuesday, August 6, 2024 7:20 AM
> To: tcl...@li...
> Subject: Re: [TCLCORE] Questions regarding: Do not use widget names for
> script names
> 
> Am 05.08.2024 um 23:30 schrieb Paul Obermeier:
> > A question to the Tcl core team.
> >
> > Are there plans for Tcl9 to remove the (unexpected) behaviour, that
> > script file names are not allowed to have the names of widgets, as
> > described ex. here:
> > https://stackoverflow.com/questions/37087930/error-unknown-option-
> stat
> > e-occurs-when-running-a-script-named-button-tcl
> >
> > Although an experienced Tcl'er I recently stumbled across that problem
> > when writing a simple test script and it took me some time to remember
> > that behaviour.
> > It does not seem to be mentioned in the official documentation.
> >
> > Paul
> 
> +1
> 
> I took months to find those errors. My use case was "wish.exe scale" and the
> Tk class was overwritten and some widgets did not work any more.
> 
> Well
> 
> + 1000
> 
> to get rid of this.
> 
> Thanks,
> Harald

Re: [TCLCORE] Questions regarding: Do not use widget names for script names

[Keith N. <k.j...@us...>]

Hello All,

The problem could be fixed by making sure that the bindtag for toplevel
"." of a script always has a dot and suffix, e.g. for script "scale"
use "Scale.tcl" instead of "Scale".  Would this change cause problems
anywhere else?

In the unlikely event that the external xrdb on X11 has entries for a
specific script "foo", these will likely have been placed there by the
user him/herself, so it is not onerous to expect the user to adapt the
xrdb for the new definitions.

If such a change is supported I suppose it would need a TIP.

Keith.


On Mon, 2024-08-05 at 23:30 +0200, Paul Obermeier wrote:
> A question to the Tcl core team.
> 
> Are there plans for Tcl9 to remove the (unexpected) behaviour, that
> script file names are not allowed to have the names of widgets,
> as described ex. here: 
> https://stackoverflow.com/questions/37087930/error-unknown-option-state-occurs-when-running-a-script-named-button-tcl
> 
> Although an experienced Tcl'er I recently stumbled across that
> problem when writing a simple test script
> and it took me some time to remember that behaviour.
> It does not seem to be mentioned in the official documentation.
> 
> Paul
> 
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Questions regarding: Do not use widget names for script names

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

Am 05.08.2024 um 23:30 schrieb Paul Obermeier:
> A question to the Tcl core team.
> 
> Are there plans for Tcl9 to remove the (unexpected) behaviour, that 
> script file names are not allowed to have the names of widgets,
> as described ex. here: 
> https://stackoverflow.com/questions/37087930/error-unknown-option-state-occurs-when-running-a-script-named-button-tcl
> 
> Although an experienced Tcl'er I recently stumbled across that problem 
> when writing a simple test script
> and it took me some time to remember that behaviour.
> It does not seem to be mentioned in the official documentation.
> 
> Paul

+1

I took months to find those errors. My use case was
"wish.exe scale" and the Tk class was overwritten and some widgets did 
not work any more.

Well

+ 1000

to get rid of this.

Thanks,
Harald

[TCLCORE] Questions regarding: Do not use widget names for script names

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

A question to the Tcl core team.

Are there plans for Tcl9 to remove the (unexpected) behaviour, that script file names are not allowed to have the names of widgets,
as described ex. here: https://stackoverflow.com/questions/37087930/error-unknown-option-state-occurs-when-running-a-script-named-button-tcl

Although an experienced Tcl'er I recently stumbled across that problem when writing a simple test script
and it took me some time to remember that behaviour.
It does not seem to be mentioned in the official documentation.

Paul

Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

[Pietro C. <ga...@ga...>]

On Aug 05 2024, 08:19 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
>Thanks Pietro, that helped. Appears as though FreeBSD ICU follows same
>function naming as Windows, not Linux.
>
>Fixed and tested on FreeBSD 14. Please try branch apn-icu-freebsd and let me
>know if it works for you.


$ env LD_LIBRARY_PATH=(pwd) TCL_LIBRARY=../library ./tcltest ../tests/icu.test
icu.test:       Total   7       Passed  7       Skipped 0       Failed  0

Thanks!

>
>/Ashok
>
>-----Original Message-----
>From: Pietro Cerutti <ga...@ga...>
>Sent: Monday, August 5, 2024 1:27 AM
>To: apn...@ya...
>Cc: 'Tcl List Core' <tcl...@li...>
>Subject: Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED
>
>On Aug 03 2024, 16:42 +0000, apnmbx-public--- via Tcl-Core
><tcl...@li...> wrote:
>>Pietro,
>
>Hi Ashok,
>
>>You can ignore the ICU test failure messages. The missing functions
>>would only be invoked if the tcl::unsupported::icu command was invoked.
>>Note the *unsupported* namespace.
>
>Thanks.
>
>>Since ICU is shipped in different packaging (shared lib) configurations
>>on different platforms, could you tell me what ICU related shared
>>libraries are present in freebsd and also dump the exported functions
>>from each? That would be very helpful.
>
>The attached file is the output of
>$ readelf -Ws --syms /usr/local/lib/libicu*.74.2 | grep -v _Z | grep -v UND
>
>Please let me know if that's what you need.
>
>Cheers,
>
>-- 
>Pietro Cerutti
>I have pledged to give 10% of income to effective charities
>and invite you to join me - https://givingwhatwecan.org
>
>
>
>_______________________________________________
>Tcl-Core mailing list
>Tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

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

Thanks Pietro, that helped. Appears as though FreeBSD ICU follows same
function naming as Windows, not Linux.

Fixed and tested on FreeBSD 14. Please try branch apn-icu-freebsd and let me
know if it works for you.

/Ashok

-----Original Message-----
From: Pietro Cerutti <ga...@ga...> 
Sent: Monday, August 5, 2024 1:27 AM
To: apn...@ya...
Cc: 'Tcl List Core' <tcl...@li...>
Subject: Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

On Aug 03 2024, 16:42 +0000, apnmbx-public--- via Tcl-Core
<tcl...@li...> wrote:
>Pietro,

Hi Ashok,

>You can ignore the ICU test failure messages. The missing functions 
>would only be invoked if the tcl::unsupported::icu command was invoked.  
>Note the *unsupported* namespace.

Thanks.

>Since ICU is shipped in different packaging (shared lib) configurations 
>on different platforms, could you tell me what ICU related shared 
>libraries are present in freebsd and also dump the exported functions 
>from each? That would be very helpful.

The attached file is the output of
$ readelf -Ws --syms /usr/local/lib/libicu*.74.2 | grep -v _Z | grep -v UND

Please let me know if that's what you need.

Cheers,

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

[Pietro C. <ga...@ga...>]

On Aug 03 2024, 16:42 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
>Pietro,

Hi Ashok,

>You can ignore the ICU test failure messages. The missing functions 
>would only be invoked if the tcl::unsupported::icu command was invoked.  
>Note the *unsupported* namespace.

Thanks.

>Since ICU is shipped in different packaging (shared lib) configurations 
>on different platforms, could you tell me what ICU related shared 
>libraries are present in freebsd and also dump the exported functions 
>from each? That would be very helpful.

The attached file is the output of
$ readelf -Ws --syms /usr/local/lib/libicu*.74.2 | grep -v _Z | grep -v UND

Please let me know if that's what you need.

Cheers,

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] New Logo ?

[Arjen M. <Arj...@de...>]

Hi everyone,

Just a completely inconsequential contribution to this discussion: I was reminded of the wonderful Wiki page by Kevin Kenny, https://wiki.tcl-lang.org/page/Drawing+with+epicycles+and+the+Fourier+transform, where the text "Tcl Tk" and a feather are drawn using a technique that originated with Ptolemy ...

Regards,

Arjen

-----Original Message-----
From: Patrick May <dus...@gm...>
Sent: Tuesday, July 23, 2024 1:52 PM
To: tcl...@li...
Subject: Re: [TCLCORE] New Logo ?

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Hello,

As a user of tcl/tk I thought I'd just share my thoughts on this - I personally really like the current logo, it has nostalgic 90s charm, and the concept behind it is quite endearing and fun - a quality I appreciate since the tech world can often be pretty cold, hard, and serious.
Nostalgia for the 90s and styles of the 90s also seems to be getting more popular with young people these days.

IMO the use of a feather as a project logo, even if referring to a pun on the name of the project, doesn't necessarily give me the impression that the project isn't completely serious.

Not to knock your draft logos, they look very cool and actually have some 90s charm of their own too, especially the animated logo.

- PM

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://cmac/
> leod.me.uk%2Ftcl%2Flogo%2F&data=05%7C02%7Carjen.markus%40deltares.nl%7
> C648878d507834195b0ce08dcab0df259%7C15f3fe0ed7124981bc7cfe949af215bb%7
> C0%7C0%7C638573323597081228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=X%
> 2F7MaQs9QoKexMrrNS0%2FFBqBQgImP5pnRL5yfbq9svU%3D&reserved=0
>
> Colin.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://list/
> s.sourceforge.net%2Flists%2Flistinfo%2Ftcl-core&data=05%7C02%7Carjen.m
> arkus%40deltares.nl%7C648878d507834195b0ce08dcab0df259%7C15f3fe0ed7124
> 981bc7cfe949af215bb%7C0%7C0%7C638573323597091593%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C0%7C%7C%7C&sdata=8n3yG0GU412lPYfd9xATgmKRojq7WPoXT2VroIT7tK0%3D&rese
> rved=0


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] mk4 with tcl9

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

Hi Simon,

I do not know, if somebody has ported mk4 to Tcl9.
If you want to do it yourself, take a look at https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9
especially the section "Changes in C".

Regards,
Paul

Am 03.08.2024 um 11:20 schrieb Simon Geard:
>
> Has anyone tried building this? I've just tried and failed:
>
> g++ -c -g -O2  -fPIC -DUSE_TCL_STUBS -I./../include -I/usr/local/include/generic -I/usr/local/include ../tcl/mk4tcl.cpp
> ../tcl/mk4tcl.cpp:409:3:error: invalid conversion from ‘int (*)(ClientData, Tcl_Interp*)’ {aka ‘int (*)(void*, Tcl_Interp*)’} to ‘void*’ [-fpermissive]
>  409 | mkClose,  /* Close channel, clean instance data      */
>      | ^~~~~~~
>      | |
>      | int (*)(ClientData, Tcl_Interp*) {aka int (*)(void*, Tcl_Interp*)}
> ../tcl/mk4tcl.cpp:In function ‘int SetAsObj(Tcl_Interp*, const c4_RowRef&, const c4_Property&, Tcl_Obj*)’:
> ../tcl/mk4tcl.cpp:490:54:error: cannot convert ‘int*’ to ‘Tcl_Size*’ {aka ‘long int*’} in argument passing
>  490 |         const char *ptr = Tcl_GetStringFromObj(obj_, &len);
>      | ^~~~
>      | |
>      | int*
> In file included from /usr/local/include/tcl.h:2435,
>                 from ../tcl/mk4tcl.h:9,
>                 from ../tcl/mk4tcl.cpp:5:
> ../tcl/mk4tcl.cpp:498:60:error: cannot convert ‘int*’ to ‘Tcl_Size*’ {aka ‘long int*’} in argument passing
>  498 |         const t4_byte *ptr = Tcl_GetByteArrayFromObj(obj_, &len);
>      | ^
>      | |
>      | int*
> ../tcl/mk4tcl.cpp:In function ‘const c4_Property& AsProperty(Tcl_Obj*, const c4_View&)’:
> ../tcl/mk4tcl.cpp:1044:49:error: cannot convert ‘int*’ to ‘Tcl_Size*’ {aka ‘long int*’} in argument passing
> 1044 |     char *string = Tcl_GetStringFromObj(objPtr, &length);
>      | ^~~~~~~
>      | |
>      | int*
> ../tcl/mk4tcl.cpp:In function ‘int SetCursorFromAny(Tcl_Interp*, Tcl_Obj*)’:
> ../tcl/mk4tcl.cpp:1157:44:warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 1157 |     objPtr->internalRep.twoPtrValue.ptr1 = (void*)i;
>
> as a sample. No doubt it needs to be updated but I don't want to spend time on it when it's already been done. Or maybe the world has moved on and there's something similar I could use instead?
>
> Thanks
>
> Simon
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

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

Pietro,

You can ignore the ICU test failure messages. The missing functions would
only be invoked if the tcl::unsupported::icu command was invoked. Note the
*unsupported* namespace.

I should put the tests under some constraint but I would like to know of
errors as the icu command is also used by the migration package to warn of
encoding errors.

Since ICU is shipped in different packaging (shared lib) configurations on
different platforms, could you tell me what ICU related shared libraries are
present in freebsd and also dump the exported functions from each? That
would be very helpful.

/Ashok

-----Original Message-----
From: Pietro Cerutti <ga...@ga...> 


Hi,

I was on vacation and wasn't able to test the RCs and report the results 
on FreeBSD, as I usually do.

Anyway, all fine except for ICU: all ICU-related tests fail with

     Could not get aliases for <any codepage>: ICU function not available

I printf-debugged tclIcu.c to the point where it successfulluy loads 
libicuuc.so.74 and libicui18n.so.74, but I haven't put too much effort 
into understanding the code from there on.

Should I? Is there anythin in Tcl9 depending on ICU?

Thanks!

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] New Logo ?

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

Update 2, the logo version to add to the Tcl tools directory should have 
text "Tcl-lang" or "tcl-lang", not "Tcl/Tk".  (It annoys me that 
tcl-lang expands to a repetition of "language", but that's what we have 
for the website now, so it makes sense to be consistent.)

Colin.

On 03/08/2024 14:56, Colin Macleod via Tcl-Core wrote:
>
> Update, only now I saw that the Tcl source directory "tools" includes:
>
>   * feather.bmp - a very small diagonal blue feather
>   * tclsh.svg - the later-style feather in blue
>
> They are not mentioned in the README for that directory; 
> unix/Makefile.in has code to copy them as part of the "dist" target, 
> but I don't find any other reference to them.
>
> Also Tk in the library/demos/images directory has
>
>   * tcllogo.gif - a small copy of the original feather logo (not used
>     anywhere)
>   * Tk_feather.png - a different, diagonal blue feather image (used in
>     the demo code)
>   * Tcl.svg - the later-style feather in beige (used in the demo code)
>
> So I would propose to add my toolbox logo to the Tcl tools directory also.
>
> Colin.
>
> On 03/08/2024 13:04, Colin Macleod via Tcl-Core wrote:
>>
>> Dear All,
>>
>> The Tk source includes a directory library/images which contains the 
>> original feather tcl/tk and tcl-powered logos in various GIF sizes, 
>> plus Adobe Illustrator source files for them.
>>
>> I propose to add the toolbox design below to this directory. It is in 
>> SVG format which is compact, editable and can be displayed at 
>> different sizes.  I think the criterion for doing this should not be 
>> whether it is the best logo that could ever be produced, given 
>> unlimited time and resources, but just whether adding it is better or 
>> worse than not adding it.
>>
>> I have kept the text as "Tcl/Tk" but if this is felt to be a legal 
>> risk I could change it to "tcl/tk".  I could also add a "Tcl-powered" 
>> version.
>>
>> Would a TIP be required to proceed with this?
>>
>> Colin.
>>
>> On 01/08/2024 19:30, Colin Macleod via Tcl-Core wrote:
>>>
>>> Yes, this risk has been pointed out.  Using "TCL" in caps is 
>>> definitely out.  Using "Tcl/Tk" should be relatively safe, though 
>>> keeping even this in lower case as "tcl/tk" has been suggested.
>>>
>>> Here is my latest effort, based on a toolbox-themed proposal from 
>>> Saito on the wiki, but recreating it in SVG form and adding a rather 
>>> playful simplified feather, while also keeping the original 
>>> blue-feather-on-red colours:
>>>
>>> Best regards,
>>> Colin.
>>>
>>>
>>> On 30/07/2024 21:57, Simon Geard wrote:
>>>>
>>>> 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
>>>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] New Logo ?

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

Update, only now I saw that the Tcl source directory "tools" includes:

  * feather.bmp - a very small diagonal blue feather
  * tclsh.svg - the later-style feather in blue

They are not mentioned in the README for that directory; 
unix/Makefile.in has code to copy them as part of the "dist" target, but 
I don't find any other reference to them.

Also Tk in the library/demos/images directory has

  * tcllogo.gif - a small copy of the original feather logo (not used
    anywhere)
  * Tk_feather.png - a different, diagonal blue feather image (used in
    the demo code)
  * Tcl.svg - the later-style feather in beige (used in the demo code)

So I would propose to add my toolbox logo to the Tcl tools directory also.

Colin.

On 03/08/2024 13:04, Colin Macleod via Tcl-Core wrote:
>
> Dear All,
>
> The Tk source includes a directory library/images which contains the 
> original feather tcl/tk and tcl-powered logos in various GIF sizes, 
> plus Adobe Illustrator source files for them.
>
> I propose to add the toolbox design below to this directory. It is in 
> SVG format which is compact, editable and can be displayed at 
> different sizes.  I think the criterion for doing this should not be 
> whether it is the best logo that could ever be produced, given 
> unlimited time and resources, but just whether adding it is better or 
> worse than not adding it.
>
> I have kept the text as "Tcl/Tk" but if this is felt to be a legal 
> risk I could change it to "tcl/tk".  I could also add a "Tcl-powered" 
> version.
>
> Would a TIP be required to proceed with this?
>
> Colin.
>
> On 01/08/2024 19:30, Colin Macleod via Tcl-Core wrote:
>>
>> Yes, this risk has been pointed out.  Using "TCL" in caps is 
>> definitely out.  Using "Tcl/Tk" should be relatively safe, though 
>> keeping even this in lower case as "tcl/tk" has been suggested.
>>
>> Here is my latest effort, based on a toolbox-themed proposal from 
>> Saito on the wiki, but recreating it in SVG form and adding a rather 
>> playful simplified feather, while also keeping the original 
>> blue-feather-on-red colours:
>>
>> Best regards,
>> Colin.
>>
>>
>> On 30/07/2024 21:57, Simon Geard wrote:
>>>
>>> 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
>>>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl / Tk 9.0b3 RELEASED

[Pietro C. <ga...@ga...>]

On Jul 31 2024, 19:03 +0000, Donald G Porter via Tcl-Core <tcl...@li...> wrote:
>Tcl/Tk 9.0b3 Release Announcement
>July 31, 2024
>
>The Tcl Core Team is pleased to announce the 9.0b3 releases of the Tcl
>dynamic language and the Tk graphical interface package.  These are the
>third beta releases of Tcl 9.0 and Tk 9.0.  More details can be found below.

Hi,

I was on vacation and wasn't able to test the RCs and report the results 
on FreeBSD, as I usually do.

Anyway, all fine except for ICU: all ICU-related tests fail with

     Could not get aliases for <any codepage>: ICU function not available

I printf-debugged tclIcu.c to the point where it successfulluy loads 
libicuuc.so.74 and libicui18n.so.74, but I haven't put too much effort 
into understanding the code from there on.

Should I? Is there anythin in Tcl9 depending on ICU?

Thanks!

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] New Logo ?

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

Dear All,

The Tk source includes a directory library/images which contains the 
original feather tcl/tk and tcl-powered logos in various GIF sizes, plus 
Adobe Illustrator source files for them.

I propose to add the toolbox design below to this directory.  It is in 
SVG format which is compact, editable and can be displayed at different 
sizes.  I think the criterion for doing this should not be whether it is 
the best logo that could ever be produced, given unlimited time and 
resources, but just whether adding it is better or worse than not adding it.

I have kept the text as "Tcl/Tk" but if this is felt to be a legal risk 
I could change it to "tcl/tk".  I could also add a "Tcl-powered" version.

Would a TIP be required to proceed with this?

Colin.

On 01/08/2024 19:30, Colin Macleod via Tcl-Core wrote:
>
> Yes, this risk has been pointed out.  Using "TCL" in caps is 
> definitely out.  Using "Tcl/Tk" should be relatively safe, though 
> keeping even this in lower case as "tcl/tk" has been suggested.
>
> Here is my latest effort, based on a toolbox-themed proposal from 
> Saito on the wiki, but recreating it in SVG form and adding a rather 
> playful simplified feather, while also keeping the original 
> blue-feather-on-red colours:
>
> Best regards,
> Colin.
>
>
> On 30/07/2024 21:57, Simon Geard wrote:
>>
>> 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
>>

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

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

 

Nice idea, and I had the same at some point, just it'd imply that [clock
format] without any option would not provide the syntax anymore, but
return current time with default locale and format instead: 

 % clock format
- WRONG # ARGS: SHOULD BE "CLOCK FORMAT CLOCKVAL|NOW ?-FORMAT STRING?
?-GMT BOOLEAN? ?-LOCALE LOCALE? ?-TIMEZONE ZONE?"
+ SAT AUG 03 13:20:52 +0200 2024

That's why I decided not to do that at the time (at least till tcl'd get
command help/syntax/whatever to provide short description for the
command syntax).

Regards,
Serg. 

02.08.2024 04:05, Marc Culler wrote: 

> If it were up to me I would make the time value argument to the clock format command be optional with the default value being the current time in seconds. That would mean that the shortcut command would be: 
> % clock format -format "%Y-%m-%d" 
> which is a shorter shortcut than either the one using "now" or the one using "-now". If it had been up to me long ago I would probably have replaced "-format" by "-pattern", given that the subcommand is named "format". 
> 
> But I am not objecting to using "now". 
> 
> - Marc 
> 
> On Wed, Jul 31, 2024 at 11:32 AM Harald Oehlmann <har...@el...> wrote: 
> 
>> 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 [1]
>> 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 [2]
>> 
>> I invite anybody to speak up now in case of objections.
>> 
>> Thanks to Sergey, Ashok and Schelte to make this happen!
>> 
>> Take care,
>> Harald
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core [3]
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [3]
 

Links:
------
[1] https://core.tcl-lang.org/tcl/info/cd257619
[2] https://core.tcl-lang.org/tips/doc/trunk/tip/688.md
[3] https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] mk4 with tcl9

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

Has anyone tried building this? I've just tried and failed:

g++ -c -g -O2  -fPIC -DUSE_TCL_STUBS -I./../include
-I/usr/local/include/generic -I/usr/local/include ../tcl/mk4tcl.cpp
../tcl/mk4tcl.cpp:409:3:error: invalid conversion from ‘int
(*)(ClientData, Tcl_Interp*)’ {aka ‘int (*)(void*, Tcl_Interp*)’} to
‘void*’ [-fpermissive]
  409 | mkClose,  /* Close channel, clean instance data      */
      | ^~~~~~~
      | |
      | int (*)(ClientData, Tcl_Interp*) {aka int (*)(void*, Tcl_Interp*)}
../tcl/mk4tcl.cpp:In function ‘int SetAsObj(Tcl_Interp*, const
c4_RowRef&, const c4_Property&, Tcl_Obj*)’:
../tcl/mk4tcl.cpp:490:54:error: cannot convert ‘int*’ to ‘Tcl_Size*’
{aka ‘long int*’} in argument passing
  490 |         const char *ptr = Tcl_GetStringFromObj(obj_, &len);
      | ^~~~
      | |
      | int*
In file included from /usr/local/include/tcl.h:2435,
                 from ../tcl/mk4tcl.h:9,
                 from ../tcl/mk4tcl.cpp:5:
../tcl/mk4tcl.cpp:498:60:error: cannot convert ‘int*’ to ‘Tcl_Size*’
{aka ‘long int*’} in argument passing
  498 |         const t4_byte *ptr = Tcl_GetByteArrayFromObj(obj_, &len);
      | ^
      | |
      | int*
../tcl/mk4tcl.cpp:In function ‘const c4_Property& AsProperty(Tcl_Obj*,
const c4_View&)’:
../tcl/mk4tcl.cpp:1044:49:error: cannot convert ‘int*’ to ‘Tcl_Size*’
{aka ‘long int*’} in argument passing
1044 |     char *string = Tcl_GetStringFromObj(objPtr, &length);
      | ^~~~~~~
      | |
      | int*
../tcl/mk4tcl.cpp:In function ‘int SetCursorFromAny(Tcl_Interp*,
Tcl_Obj*)’:
../tcl/mk4tcl.cpp:1157:44:warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
1157 |     objPtr->internalRep.twoPtrValue.ptr1 = (void*)i;

as a sample. No doubt it needs to be updated but I don't want to spend
time on it when it's already been done. Or maybe the world has moved on
and there's something similar I could use instead?

Thanks

Simon

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

[Marc C. <cul...@gm...>]

If it were up to me I would make the time value argument to the clock
format command be optional with the default value being the current time in
seconds.  That would mean that the shortcut command would be:
% clock format -format "%Y-%m-%d"
which is a shorter shortcut than either the one using "now" or the one
using "-now".  If it had been up to me long ago I would probably have
replaced "-format" by "-pattern", given that the subcommand is named
"format".

But I am not objecting to using "now".

- Marc

On Wed, Jul 31, 2024 at 11:32 AM Harald Oehlmann <
har...@el...> wrote:

> 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
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] New Logo ?

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

Yes, this risk has been pointed out.  Using "TCL" in caps is definitely 
out.  Using "Tcl/Tk" should be relatively safe, though keeping even this 
in lower case as "tcl/tk" has been suggested.

Here is my latest effort, based on a toolbox-themed proposal from Saito 
on the wiki, but recreating it in SVG form and adding a rather playful 
simplified feather, while also keeping the original blue-feather-on-red 
colours:

Best regards,
Colin.


On 30/07/2024 21:57, Simon Geard wrote:
>
> 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
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Tcl / Tk 9.0b3 RELEASED

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

Tcl/Tk 9.0b3 Release Announcement
July 31, 2024

The Tcl Core Team is pleased to announce the 9.0b3 releases of the Tcl
dynamic language and the Tk graphical interface package.  These are the
third beta releases of Tcl 9.0 and Tk 9.0.  More details can be found below.

We would like to express our gratitude to all those who submit bug
reports and patches.  This information is invaluable in enabling us
to identify and eliminate problems in the core. Such reports can be
submitted here.

     https://core.tcl-lang.org/tcl/ticket
     https://core.tcl-lang.org/tk/ticket

We ask that you log in (anonymous if you wish) to create tickets.
This deters abuse of the ticketing system:

     https://core.tcl-lang.org/tcl/login
     https://core.tcl-lang.org/tcl/login

Where to get the new releases:
------------------------------

Tcl/Tk 9.0b3 sources are freely available as open source from the Tcl
SourceForge project's file distribution area:

         https://sourceforge.net/projects/tcl/files/

This distribution is source code only.  We keep links to some third
parties offering pre-built binaries for various systems here:

     https://www.tcl-lang.org/software/tcltk/bindist.html

General Summary
---------------

These are new major versions of both Tcl and Tk.  There are new features
to be enjoyed.  There are incompatibilities to be considered.  The list
of both is long and detailed and not fully included here.  We believe many
scripts written for Tcl 8 will run unchanged in Tcl 9.  We believe many more
can be modified in small and simple ways to produce a new script that runs
in both Tcl 8 and Tcl 9.  We expect that extensions and applications using
the public C APIs of Tcl and Tk will involve more effort, but that it is
still within reasonable reach to produce source code supporting both Tcl 8
and Tcl 9 while both releases remain in widespread use.

These are beta releases.  The developers believe the new feature set is
complete enough and the code quality is high enough that it is time for
a larger audience of Tcl/Tk users to give them a try and report back
to the developers what difficulties need resolution before stable
releases of Tcl/Tk 9.0.0.

The experiences of Tcl/Tk 8 users adapting their code to the beta releases
of Tcl/Tk 9 will shape the final interfaces of Tcl/Tk 9.0.0, and will
determine the need for possible Tcl/Tk 8.7 releases that might supply
additional lifecycle and migration support.

It is not recommended to deploy these beta releases directly to mission
critical use without significant testing and review.

Tcl Changes Summary
-------------------

The source code for Tcl is managed by fossil.  Tcl developers coordinate all
changes to the Tcl source code at

 > [Tcl Source Code](https://core.tcl-lang.org/tcl/timeline)

Release Tcl 9.0b3 arises from the check-in with tag core-9-0-b3.

Highlighted differences between Tcl 9.0 and Tcl 8.6 are summarized below,
with focus on changes important to programmers using the Tcl library and
writing Tcl scripts.

## 64-bit capacity: Data values larger than 2Gb

## Internationalization of text
  - Full Unicode range of codepoints
  - New encodings: utf-16/utf-32/ucs-2(le|be), CESU-8, etc.
  - `encoding` options -profile, -failindex manage encoding of I/O.
  - `msgcat` supports custom locale search list
  - `source` defaults to -encoding utf-8

## Zip filesystems and attached archives.

## Unix notifiers available using epoll() or kqueue()
  - relieves limits on file descriptors imposed by legacy select()

## Notable incompatibilities
  - Unqualified varnames resolved in current namespace, not global.
  - No --disable-threads build option.  Always thread-enabled.
  - I/O malencoding default response: raise error (-profile strict)
  - Windows platform needs Windows 7 or Windows Server 2008 R2 or later
  - Ended interpretation of ~ as home directory in pathnames
  - Removed the "identity" encoding.
  - Removed the encoding alias "binary" to "iso8859-1".
  - $::tcl_precision no longer controls string generation of doubles
  - Removed Tcl 7 legacies: [case], [puts] [read] variant syntaxes
  - Removed subcommands [trace variable|vdelete|vinfo]
  - No -eofchar option for channels anymore for writing.
  - On Windows 10+ (Version 1903 or higher), system encoding is always utf-8.
  - Removed command ::tcl::unsupported::inject.

## Incompatibilities in C public interface
  - Many arguments expanded type from int to Tcl_Size
  - Ended support for Tcl_ChannelTypeVersion less than 5
  - Introduced versioning of the Tcl_ObjType struct
  - Removed macros CONST*: Tcl 9 support means dropping Tcl 8.3 support
  - Removed routines:
 >    Tcl_Backslash(), Tcl_*VA(), Tcl_*MathFunc*(), Tcl_MakeSafe(),
 >    Tcl_(Save|Restore|Discard|Free)Result(), Tcl_EvalTokens(),
 >    Tcl_(Get|Set)DefaultEncodingDir(),
 >    Tcl_UniCharN(case)cmp(), Tcl_UniCharCaseMatch()

## New commands
  - `array default`, `array for`
  - `chan isbinary`
  - `coroinject`, `coroprobe`
  - `clock add weekdays`
  - `const`, `info const*`
  - `dict getwithdefault`
  - `file tempdir`, `file home`, `file tildeexpand`
  - `info commandtype`
  - `ledit`
  - `lpop`
  - `lremove`
  - `lseq`
  - `package files`
  - `string insert`, `string is dict`
  - `tcl::process`
  - `*::build-info`
  - `readFile`, `writeFile`, `foreachLine`

## New command options
  - `regsub ... -command ...`
  - `lsearch ... -stride ...`
  - `clock scan ... -validate ...`
  - `socket ... -nodelay ... -keepalive ...`
  - `vwait` controlled by several new options

## Numbers
  - 0NNN format is no longer octal interpretation. Use 0oNNN.
  - 0dNNNN format to compel decimal interpretation.
  - NN_NNN_NNN, underscores in numbers for optional readability
  - Functions: isinf() isnan() isnormal() issubnormal() isunordered()
  - `fpclassify`
  - Function int() no longer truncates to word size

## tcl::oo facilities
  - private variable and methods
  - `method -export`, `method -unexport`

Tk Changes Summary
-------------------

The source code for Tk is managed by fossil.  Tk developers coordinate all
changes to the Tk source code at

 > [Tk Source Code](https://core.tcl-lang.org/tk/)

Release Tk 9.0b3 arises from the check-in with tag core-9-0-b3.

Highlighted differences between Tk 9.0 and Tk 8.6 are summarized below,
with focus on changes important to programmers using the Tk library and
writing Tcl scripts containing Tk commands.

## Many improvements to use of platform features and conventions.
  - Built-in widgets and themes are scaling-aware.
  - Improved support of two-finger gestures, where available
  - The `tk windowingsystem` "aqua" needs macOS 10.10 or later

## New commands and options
  - `tk sysnotify`: access to the OS notifications system
  - `tk systray`: access to the OS tray facility
  - `tk print`: access to the OS printing facility

## Widget options
  - New `ttk::progressbar` option: **-text**
  - `$frame ... -backgroundimage $img -tile $bool`
  - `$menu id`, `$menu add|insert ... ?$id? ...`
  - `$image get ... -withalpha ...`
  - All indices now accept the forms **end**, **end-int**, **int+|-int**

## Improved widget appearance
  - `ttk::notebook` with nondefault tab positions

## Images
  - Partial SVG support
  - Read/write access to photo image metadata

Tcl Improvement Proposals (TIPs)
--------------------------------

Each new user-visible feature in Tcl or Tk should find its origins in
a Tcl Improvement Proposal (TIP).  TIPs are published, edited, considered
and voted in public, and should contain valuable information about how
a feature came to be the way it is.  See the full collection here:

     https://tip.tcl-lang.org/

Additional support resources
----------------------------

See the following links for an accumulation of migration advice:

https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9
https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9

There has been much progress already porting many known applications,
extensions, and packages in the Tcl world to compatibility with Tcl/Tk 9:

https://wiki.tcl-lang.org/page/Apps+confirmed+to+work+with+Tcl+9
https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

         https://www.tcl-lang.org/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager

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

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

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

Am 30.07.2024 um 19:39 schrieb Donald G Porter via Tcl-Core:
> 
> 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.

Thanks, great !
All ok from my side with:
MS-VC2015 x86 on 64bit Windows

% clock format now -format %Y
2024

Thank you for all,
Harald

[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

>