tcl-core — Tcl Core Team discussions about Tcl development

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

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

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

Re: [TCLCORE] TclOO Properties C API, request for help/use cases/ideas

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

Dear Donal,
thank you for the great work, I appreciate !
Rene is still for 2 weeks on holiday. You may get an answer in the 2nd 
week of August.
Of cause, any other is invited to comment.

Thanks again,
Harald

Am 27.07.2024 um 12:58 schrieb Donal Fellows:
> I’ve been considering adding a C API for TclOO properties. The issue is 
> I’m trying to imagine what such an API might be.
> 
> Clearly, there’s going to be something to register a property against a 
> class or object (called something akin to Tcl_RegisterProperty) and some 
> functions to do various lookups (especially of the current lists of 
> properties supported directly on a class or property, and of the full 
> list of properties supported by an instance including via inheritance). 
> But what else? Well, I’ll be able to provide an API for making 
> implementations, but that will be very specific to Tcl-ish style 
> properties so I’m not sure of the utility; Tk-like properties will need 
> something different. Indeed, that’s why properties are not a base 
> feature of oo::object; the details vary too much. I’m tempted to leave 
> the full property manufacturing code as Tcl-internal (and exposed to 
> scripts of course).
> 
> My point is I really need some help here to describe what sort of things 
> that are needed by other models of what properties should be. I’m happy 
> for base TclOO to provide support for discovery mechanisms; they’re the 
> expensive part if done any other way. But I need to know what I’m 
> missing. If I knew, it wouldn’t be missing!
> 
> Donal.

Re: [TCLCORE] ttrek repositories are now open to the public

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

Hi Neophytos,

Thank you for explaining the rationale of ttrek - I wish you success in
developing it.  I understand your arguments, and I have found in my own work
that it is often difficult to decide whether to patch an existing tool or
start from scratch.

> My answer is that this is happenning and i will stop at nothing to deliver
> because i want to use these extensions myself. If others find them
> interesting it is a plus.

I understand this too because it is what motivates my own Tcl work.

Best wishes,

Keith.


------ Original Message ------
Received: Sat, 27 Jul 2024 08:30:01 AM BST
From: Neophytos Demetriou <neo...@gm...>
To: KEITH NASH <k.j...@us...>Cc: Tcl Core List
<tcl...@li...>
Subject: Re: [TCLCORE] ttrek repositories are now open to the public

> I think BAWT and Paul are great. So if it covers your needs, by all means
> use it. That said, there are two key words in your message that I would
> like to elaborate on: *some* and *easier*. While it is true that BAWT
> accomplishes some of what ttrek does, it does not have dependency
> resolution using a SAT solver, it also does not have USE flags, and the
> fact that soecification files are code in tcl instead of a declaratice json
> file, it is a disadvantage in my book.
> 
> I dont think it is easier to extend BAWT than build a new system. Their
> design, philosophy, and architecture is different.
> 
> As a general comment, I have built over 15 tcl extensions in the last year.
> With the exception of some bright minds in the community (thank you Ashok)
> i have been hearing the same argument a lot. In particular, tcllib does s3
> so aws-sdk-tcl is obsolete regardless of the fact that it  also has support
> for dynamodb, lambda, sqs, kms, iam, and ssm support.
> 
> I am on my phone so it is hard to enumerate all the things that were
> communicated one way or another over the last year, in some cases possibly
> from fake accounts. I would have liked to touch the subject of inclusivity
> in open source but maybe in another thread.
> 
> My answer is that this is happenning and i will stop at nothing to deliver
> because i want to use these extensions myself. If others find them
> interesting it is a plus.
> 
> On Sat, Jul 27, 2024, 02:32 KEITH NASH <k.j...@us...> wrote:
> 
> > Hi Neophytos,
> >
> > The BAWT system written by Paul Obermeier appears to do some of what
ttrek
> > is
> > trying to do.  In particular its repository has a large number of package
> > sources and cross-platform build scripts that handle the dependencies and
> > quirks of each package.  BAWT is written in Tcl, which is helpful because
> > it
> > means that any Tcl developer can adapt the code for their own purposes.
> >
> > https://www.tcl3d.org/bawt/index.html
> >
> > If BAWT lacks some of the features desired for ttrek, it might be easier
to
> > add the missing features to BAWT, rather than build a new system from
> > scratch.
> >
> > Best wishes,
> >
> > Keith Nash.
> >
> >
> > ------ Original Message ------
> > Received: Tue, 23 Jul 2024 06:03:17 PM BST
> > From: Neophytos Demetriou <neo...@gm...>
> > To: Tcl Core List <tcl...@li...>
> > Subject: [TCLCORE] ttrek repositories are now open to the public
> >
> > > ttrek is an ongoing effort to develop a package manager for TCL
> > extensions
> > > and TCL itself.
> > >
> > > ttrek client: https://github.com/jerily/ttrek
> > > registry and website: https://github.com/jerily/ttrek.sh
> > >
> > > Note that these projects are still under active development. We are
> > opening
> > > up their git repositories today (2024-07-23) under a permissive license
> > > (MIT) for two reasons: (a) so that people can follow our progress, and
> > (b)
> > > to give a chance to whoever wants to build a better registry or website
> > to
> > > be able to do it.
> > >
> > > Our own registry and website will be published to a domain once it is
> > good
> > > and ready.
> > >
> > > Take care,
> > > Neophytos
> > >
> >
> > >
> >
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> > >
> >
> >
> >
> 

Re: [TCLCORE] New Logo - Final attempt

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

Hi all, here is one last offering from me:

If anybody likes it, feel free to use it, if not, don't. The components 
could be used separately, in particular the Tcl block section on its own 
would make a square icon that would work at small sizes, I think.

The TclMagick code to generate this is at 
https://cmacleod.me.uk/tcl/logo/ so anyone who feels like it can modify 
colours, scaling, whatever.  I am willing to make modifications myself 
if anyone should request this.  Apart from that, I'm going to get back 
to my other projects now :-)

Colin.

[TCLCORE] TclOO Properties C API, request for help/use cases/ideas

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

I've been considering adding a C API for TclOO properties. The issue is I'm trying to imagine what such an API might be.

Clearly, there's going to be something to register a property against a class or object (called something akin to Tcl_RegisterProperty) and some functions to do various lookups (especially of the current lists of properties supported directly on a class or property, and of the full list of properties supported by an instance including via inheritance). But what else? Well, I'll be able to provide an API for making implementations, but that will be very specific to Tcl-ish style properties so I'm not sure of the utility; Tk-like properties will need something different. Indeed, that's why properties are not a base feature of oo::object; the details vary too much. I'm tempted to leave the full property manufacturing code as Tcl-internal (and exposed to scripts of course).

My point is I really need some help here to describe what sort of things that are needed by other models of what properties should be. I'm happy for base TclOO to provide support for discovery mechanisms; they're the expensive part if done any other way. But I need to know what I'm missing. If I knew, it wouldn't be missing!

Donal.

Re: [TCLCORE] ttrek repositories are now open to the public

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

I think BAWT and Paul are great. So if it covers your needs, by all means
use it. That said, there are two key words in your message that I would
like to elaborate on: *some* and *easier*. While it is true that BAWT
accomplishes some of what ttrek does, it does not have dependency
resolution using a SAT solver, it also does not have USE flags, and the
fact that soecification files are code in tcl instead of a declaratice json
file, it is a disadvantage in my book.

I dont think it is easier to extend BAWT than build a new system. Their
design, philosophy, and architecture is different.

As a general comment, I have built over 15 tcl extensions in the last year.
With the exception of some bright minds in the community (thank you Ashok)
i have been hearing the same argument a lot. In particular, tcllib does s3
so aws-sdk-tcl is obsolete regardless of the fact that it  also has support
for dynamodb, lambda, sqs, kms, iam, and ssm support.

I am on my phone so it is hard to enumerate all the things that were
communicated one way or another over the last year, in some cases possibly
from fake accounts. I would have liked to touch the subject of inclusivity
in open source but maybe in another thread.

My answer is that this is happenning and i will stop at nothing to deliver
because i want to use these extensions myself. If others find them
interesting it is a plus.

On Sat, Jul 27, 2024, 02:32 KEITH NASH <k.j...@us...> wrote:

> Hi Neophytos,
>
> The BAWT system written by Paul Obermeier appears to do some of what ttrek
> is
> trying to do.  In particular its repository has a large number of package
> sources and cross-platform build scripts that handle the dependencies and
> quirks of each package.  BAWT is written in Tcl, which is helpful because
> it
> means that any Tcl developer can adapt the code for their own purposes.
>
> https://www.tcl3d.org/bawt/index.html
>
> If BAWT lacks some of the features desired for ttrek, it might be easier to
> add the missing features to BAWT, rather than build a new system from
> scratch.
>
> Best wishes,
>
> Keith Nash.
>
>
> ------ Original Message ------
> Received: Tue, 23 Jul 2024 06:03:17 PM BST
> From: Neophytos Demetriou <neo...@gm...>
> To: Tcl Core List <tcl...@li...>
> Subject: [TCLCORE] ttrek repositories are now open to the public
>
> > ttrek is an ongoing effort to develop a package manager for TCL
> extensions
> > and TCL itself.
> >
> > ttrek client: https://github.com/jerily/ttrek
> > registry and website: https://github.com/jerily/ttrek.sh
> >
> > Note that these projects are still under active development. We are
> opening
> > up their git repositories today (2024-07-23) under a permissive license
> > (MIT) for two reasons: (a) so that people can follow our progress, and
> (b)
> > to give a chance to whoever wants to build a better registry or website
> to
> > be able to do it.
> >
> > Our own registry and website will be published to a domain once it is
> good
> > and ready.
> >
> > Take care,
> > Neophytos
> >
>
> >
>
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
>
>
>

Re: [TCLCORE] ttrek repositories are now open to the public

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

Hi Neophytos,

The BAWT system written by Paul Obermeier appears to do some of what ttrek is
trying to do.  In particular its repository has a large number of package
sources and cross-platform build scripts that handle the dependencies and
quirks of each package.  BAWT is written in Tcl, which is helpful because it
means that any Tcl developer can adapt the code for their own purposes.

https://www.tcl3d.org/bawt/index.html

If BAWT lacks some of the features desired for ttrek, it might be easier to
add the missing features to BAWT, rather than build a new system from
scratch.

Best wishes,

Keith Nash.


------ Original Message ------
Received: Tue, 23 Jul 2024 06:03:17 PM BST
From: Neophytos Demetriou <neo...@gm...>
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] ttrek repositories are now open to the public

> ttrek is an ongoing effort to develop a package manager for TCL extensions
> and TCL itself.
> 
> ttrek client: https://github.com/jerily/ttrek
> registry and website: https://github.com/jerily/ttrek.sh
> 
> Note that these projects are still under active development. We are opening
> up their git repositories today (2024-07-23) under a permissive license
> (MIT) for two reasons: (a) so that people can follow our progress, and (b)
> to give a chance to whoever wants to build a better registry or website to
> be able to do it.
> 
> Our own registry and website will be published to a domain once it is good
> and ready.
> 
> Take care,
> Neophytos
> 

> 

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

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

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

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

Re: [TCLCORE] [External] Re: New Logo ?

[Kevin K. <kev...@gm...>]

It was a visual pun, intentionally with both meanings.  (The
quill-for-scripting, and the 'tee-see-ell' pronunciation, were perhaps more
'professional', but Tcl'ers are a quirky bunch.)

On Fri, Jul 26, 2024 at 11:03 AM Da Silva, Peter J Collins <
pet...@fl...> wrote:

> I don’t see any reason to get rid of the feather.
>
> I always assumed the feather was a quill, and carried a connotation of
> “scribe” because it was a “scripting” language. The “tickle”/”feather”
> association is utterly new to me, I don’t think I have encountered it
> before and I have been using TCL since the earliest days.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>


-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] New Logo ?

[Christian G. <aur...@gm...>]

Am 26.07.24 um 10:30 schrieb Alexander Schöpe via Tcl-Core:
> My Perspective:
>
> Tcl has been intricately linked with the concept of the “feather” for decades.
> Take a look at the icons used by social media platforms or IT companies; their design philosophy is to “keep it simple” with minimalistic designs.
>
> I have been using Jan Kovarik’s Glyphicons for many years.
>  From my experience, when approaching Jan with the request to use the feather icon for the open-source project Tcl/Tk, I’ve found him to be very flexible.

I really like the feather from this icon set. If we were to keep the
feather, I'd like to see this in the new logo. Maybe we could pay Jan
Kovarik to set it in context, i.e. create a "full version" with "TCL"
and/or "TK" printed together with the icon, and maybe also suggest a
nice color. Monochrome is good because it fits everywhere, but I think
there should be a colour version as well (not a vibrant colour, though)
- something like white on dark red or dark blue on white....

Then we would have a set of icons in different sizes, just the feather,
feather + TK/Tcl, feather + printed text "Tool command language".



             Christian

Re: [TCLCORE] 9.0b3rc0 test results / bugs

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

Op vr 26 jul 2024 11:22 schreef Francois Vogel <fvo...@fr...>:

> This is reported for each and every release candidate. It's the
> following ticket:
>
> https://core.tcl-lang.org/tk/tktview/ee397e0a55
>
> Jan has set it to Pending+Fixed but it isn't fixed as you noticed once
> more, and I'm wondering it's pending what.
>


It's proposed fix is in the "bug-ee397e0a55" branch, but it appears to be
incomplete.

Hope this helps
      Jan Nijtmans

Re: [TCLCORE] 9.0b3rc0 test results / bugs

[Francois V. <fvo...@fr...>]

There are two different topics.

What Ashok fixed is a crash on exit. Nice and fine.

What I wanted to answer to is the "Tk – shows usual “Clipboard busy 
errors”." mention that starts Ashok's message. Not fixed for anybody.

Regards,

Francois

Le 26/07/2024 à 19:26, Harald Oehlmann a écrit :
> Francois,
> thank for bringing this into our attention and sorry for the annoying 
> situation. The ticket you mentioned is indeed fixed for me (but not 
> for Ashok).
>
> But this ticket is new and Ashok fixed it with light speed. Please 
> look to the description here:
> https://core.tcl-lang.org/tk/info/d233f01e2a8b3b68
> including the IMHO great fix.
>
> Thanks for all your work !
> Harald
>
>
> Am 26.07.2024 um 19:22 schrieb Francois Vogel:
>> This is reported for each and every release candidate. It's the 
>> following ticket:
>>
>> https://core.tcl-lang.org/tk/tktview/ee397e0a55
>>
>> Jan has set it to Pending+Fixed but it isn't fixed as you noticed 
>> once more, and I'm wondering it's pending what.
>>
>> Since we stepped on each other's toes with Jan on this ticket (see 
>> discussion there), I have abandoned solving this almost one year ago.
>>
>> Regards,
>>
>> Francois
>>
>> Le 26/07/2024 à 15:53, Harald Oehlmann a écrit :
>>> Ashok,
>>> great tests, I appreciate !
>>>
>>> Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core:
>>>> Tk – shows usual “Clipboard busy errors”.
>>>>
>>>> More important, tktest90 crashes on exit (I think). Narrowed it 
>>>> down to winClipboard.test (or at least this file by itself triggers 
>>>> the crash unlike other test files). Anyone testing will likely need 
>>>> to enable the JIT debugger on Windows else you will not notice the 
>>>> crash as it happens while exiting. Alternatively, check the Windows 
>>>> Application log where the crash is reported. My VS Studio debugger 
>>>> reports it cannot determine crash location because the unhandled 
>>>> exception is .NET 4.0 and the debugger only supports 2.0. I don't 
>>>> even know where .NET enters the picture (does Tk use any UI 
>>>> features from .NET) ?
>>>
>>> I suppose, another application written in .NET4 running on your 
>>> computer and holding the clipboard is crashing due to the Tk 
>>> clipboard requests.
>>>
>>> Clipboard is a shared resource and specially terminal programs 
>>> (UltraVNC, Windows Remote Desktop or any virtualisation software may 
>>> mess this up). Also, I have seen that in Windows 11, there is an 
>>> extension to get an extended cliboard with a history list.
>>>
>>> I can reproduce the "usual Clipboard busy errors" with UltraVNC.
>>> It you have "Windows Remote Desktop" active, there is an option when 
>>> setting it up: press Options on the first connection screen, then 
>>> choose "local resources", then Keyboard. Choose "on this computer" 
>>> there. Also uncheck the clipboard checkbox.
>>>
>>> Just arbitrary guesses and eventually only noise but anyway,
>>> Harald
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] 9.0b3rc0 test results / bugs

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

Francois,
thank for bringing this into our attention and sorry for the annoying 
situation. The ticket you mentioned is indeed fixed for me (but not for 
Ashok).

But this ticket is new and Ashok fixed it with light speed. Please look 
to the description here:
https://core.tcl-lang.org/tk/info/d233f01e2a8b3b68
including the IMHO great fix.

Thanks for all your work !
Harald


Am 26.07.2024 um 19:22 schrieb Francois Vogel:
> This is reported for each and every release candidate. It's the 
> following ticket:
> 
> https://core.tcl-lang.org/tk/tktview/ee397e0a55
> 
> Jan has set it to Pending+Fixed but it isn't fixed as you noticed once 
> more, and I'm wondering it's pending what.
> 
> Since we stepped on each other's toes with Jan on this ticket (see 
> discussion there), I have abandoned solving this almost one year ago.
> 
> Regards,
> 
> Francois
> 
> Le 26/07/2024 à 15:53, Harald Oehlmann a écrit :
>> Ashok,
>> great tests, I appreciate !
>>
>> Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core:
>>> Tk – shows usual “Clipboard busy errors”.
>>>
>>> More important, tktest90 crashes on exit (I think). Narrowed it down 
>>> to winClipboard.test (or at least this file by itself triggers the 
>>> crash unlike other test files). Anyone testing will likely need to 
>>> enable the JIT debugger on Windows else you will not notice the crash 
>>> as it happens while exiting. Alternatively, check the Windows 
>>> Application log where the crash is reported. My VS Studio debugger 
>>> reports it cannot determine crash location because the unhandled 
>>> exception is .NET 4.0 and the debugger only supports 2.0. I don't 
>>> even know where .NET enters the picture (does Tk use any UI features 
>>> from .NET) ?
>>
>> I suppose, another application written in .NET4 running on your 
>> computer and holding the clipboard is crashing due to the Tk clipboard 
>> requests.
>>
>> Clipboard is a shared resource and specially terminal programs 
>> (UltraVNC, Windows Remote Desktop or any virtualisation software may 
>> mess this up). Also, I have seen that in Windows 11, there is an 
>> extension to get an extended cliboard with a history list.
>>
>> I can reproduce the "usual Clipboard busy errors" with UltraVNC.
>> It you have "Windows Remote Desktop" active, there is an option when 
>> setting it up: press Options on the first connection screen, then 
>> choose "local resources", then Keyboard. Choose "on this computer" 
>> there. Also uncheck the clipboard checkbox.
>>
>> Just arbitrary guesses and eventually only noise but anyway,
>> Harald

Re: [TCLCORE] 9.0b3rc0 test results / bugs

[Francois V. <fvo...@fr...>]

This is reported for each and every release candidate. It's the 
following ticket:

https://core.tcl-lang.org/tk/tktview/ee397e0a55

Jan has set it to Pending+Fixed but it isn't fixed as you noticed once 
more, and I'm wondering it's pending what.

Since we stepped on each other's toes with Jan on this ticket (see 
discussion there), I have abandoned solving this almost one year ago.

Regards,

Francois

Le 26/07/2024 à 15:53, Harald Oehlmann a écrit :
> Ashok,
> great tests, I appreciate !
>
> Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core:
>> Tk – shows usual “Clipboard busy errors”.
>>
>> More important, tktest90 crashes on exit (I think). Narrowed it down 
>> to winClipboard.test (or at least this file by itself triggers the 
>> crash unlike other test files). Anyone testing will likely need to 
>> enable the JIT debugger on Windows else you will not notice the crash 
>> as it happens while exiting. Alternatively, check the Windows 
>> Application log where the crash is reported. My VS Studio debugger 
>> reports it cannot determine crash location because the unhandled 
>> exception is .NET 4.0 and the debugger only supports 2.0. I don't 
>> even know where .NET enters the picture (does Tk use any UI features 
>> from .NET) ?
>
> I suppose, another application written in .NET4 running on your 
> computer and holding the clipboard is crashing due to the Tk clipboard 
> requests.
>
> Clipboard is a shared resource and specially terminal programs 
> (UltraVNC, Windows Remote Desktop or any virtualisation software may 
> mess this up). Also, I have seen that in Windows 11, there is an 
> extension to get an extended cliboard with a history list.
>
> I can reproduce the "usual Clipboard busy errors" with UltraVNC.
> It you have "Windows Remote Desktop" active, there is an option when 
> setting it up: press Options on the first connection screen, then 
> choose "local resources", then Keyboard. Choose "on this computer" 
> there. Also uncheck the clipboard checkbox.
>
> Just arbitrary guesses and eventually only noise but anyway,
> Harald
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] 9.0b3rc0 test results / bugs

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

Add volatile just before the identifier, right? That seems to have fixed the warnings.

 

From: Gustaf Neumann (sslmail) <ne...@wu...> 
Sent: Friday, July 26, 2024 8:22 PM
To: apn...@ya...
Subject: Re: [TCLCORE] 9.0b3rc0 test results / bugs

 

Hi Ashok, Can you try to add "volatile”  in front of these two declarations?





 

Additionally during compile the following warning is seen:

 

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function ‘TclpCreateProcess’:

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable ‘dsArray’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]

  431 |     Tcl_DString *dsArray;

      |                  ^~~~~~~

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable ‘newArgv’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]

  432 |     char **newArgv;

      |            ^~~~~~~

 

No idea why the errors show on Stefan’s box but not my WSL. Perhaps gcc version.

 

/Ashok

 

Re: [TCLCORE] [External] Re: New Logo ?

[Da S. P. J C. <pet...@fl...>]

I don’t see any reason to get rid of the feather.

I always assumed the feather was a quill, and carried a connotation of “scribe” because it was a “scripting” language. The “tickle”/”feather” association is utterly new to me, I don’t think I have encountered it before and I have been using TCL since the earliest days.

Re: [TCLCORE] 9.0b3rc0 test results / bugs

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

Logged ticket and proposed fix for the tktest/wish crash on exit. 

https://core.tcl-lang.org/tk/tktview/d233f01e2a

 

Someone please review.

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Friday, July 26, 2024 7:08 PM
To: tcl...@li...
Subject: [TCLCORE] 9.0b3rc0 test results / bugs

 

Summary: ignoring usual test noise (file perms on Windows, tdbc drivers) the
following failures seen.

 

- tktest90 crash on exit on Windows 10 x64 (Visual Studio 2022 17.9)

- 2 zlib failures on Linux and a scary compile warning

 

 

Windows

 

Tcl and package tests pass except for lack of tdbc drivers

 

Tk - shows usual "Clipboard busy errors".

 

More important, tktest90 crashes on exit (I think). Narrowed it down to
winClipboard.test (or at least this file by itself triggers the crash unlike
other test files). Anyone testing will likely need to enable the JIT
debugger on Windows else you will not notice the crash as it happens while
exiting. Alternatively, check the Windows Application log where the crash is
reported. My VS Studio debugger reports it cannot determine crash location
because the unhandled exception is .NET 4.0 and the debugger only supports
2.0. I don't even know where .NET enters the picture (does Tk use any UI
features from .NET) ?

 

Linux (Tcl only, do not have a X server)

 

On my WSL installation, all tests pass. 

 

On Stefan's system, 2 zlib failures seen along with a compiler warning.

 

My WSL: Linux IO 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29
23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

 

Stefan's system: Linux tcltk.wu.ac.at 6.9.9-200.fc40.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Jul 11 19:29:01 UTC 2024 x86_64 GNU/Linux

 

==== zlib-8.8 transformation and fconfigure FAILED

==== Contents of test case:

 

    zlib push compress $outSide -dictionary $spdyDict

    fconfigure $outSide -blocking 1 -translation binary -buffering none

    fconfigure $inSide -blocking 1 -translation binary

    puts -nonewline $outSide $spdyHeaders

    chan pop $outSide

    chan close $outSide

    set compressed [read $inSide]

    catch {zlib decompress $compressed} err opt

    list [string length [zlib compress $spdyHeaders]]  [string length
$compressed]  $err [dict get $opt -errorcode] [zlib adler32 $spdyDict]

 

---- Result was:

261 227 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010

---- Result should have been (exact matching):

260 222 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010

==== zlib-8.8 FAILED

 

 

 

==== zlib-8.16 Bug 3603553: buffer transfer with large writes FAILED

==== Contents of test case:

 

    set f [open $file wb]

    fconfigure $f -buffering none

    zlib push gzip $f

    puts -nonewline $f $largeData

    close $f

    file size $file

 

---- Result was:

54408

---- Result should have been (exact matching):

57647

==== zlib-8.16 FAILED

 

Additionally during compile the following warning is seen:

 

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function 'TclpCreateProcess':

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable
'dsArray' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]

  431 |     Tcl_DString *dsArray;

      |                  ^~~~~~~

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable
'newArgv' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]

  432 |     char **newArgv;

      |            ^~~~~~~

 

No idea why the errors show on Stefan's box but not my WSL. Perhaps gcc
version.

 

/Ashok

Re: [TCLCORE] 9.0b3rc0 test results / bugs

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

Ashok,
great tests, I appreciate !

Am 26.07.2024 um 15:38 schrieb apnmbx-public--- via Tcl-Core:
> Tk – shows usual “Clipboard busy errors”.
> 
> More important, tktest90 crashes on exit (I think). Narrowed it down to 
> winClipboard.test (or at least this file by itself triggers the crash 
> unlike other test files). Anyone testing will likely need to enable the 
> JIT debugger on Windows else you will not notice the crash as it happens 
> while exiting. Alternatively, check the Windows Application log where 
> the crash is reported. My VS Studio debugger reports it cannot determine 
> crash location because the unhandled exception is .NET 4.0 and the 
> debugger only supports 2.0. I don't even know where .NET enters the 
> picture (does Tk use any UI features from .NET) ?

I suppose, another application written in .NET4 running on your computer 
and holding the clipboard is crashing due to the Tk clipboard requests.

Clipboard is a shared resource and specially terminal programs 
(UltraVNC, Windows Remote Desktop or any virtualisation software may 
mess this up). Also, I have seen that in Windows 11, there is an 
extension to get an extended cliboard with a history list.

I can reproduce the "usual Clipboard busy errors" with UltraVNC.
It you have "Windows Remote Desktop" active, there is an option when 
setting it up: press Options on the first connection screen, then choose 
"local resources", then Keyboard. Choose "on this computer" there. Also 
uncheck the clipboard checkbox.

Just arbitrary guesses and eventually only noise but anyway,
Harald

[TCLCORE] 9.0b3rc0 test results / bugs

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

Summary: ignoring usual test noise (file perms on Windows, tdbc drivers) the
following failures seen.

 

- tktest90 crash on exit on Windows 10 x64 (Visual Studio 2022 17.9)

- 2 zlib failures on Linux and a scary compile warning

 

 

Windows

 

Tcl and package tests pass except for lack of tdbc drivers

 

Tk - shows usual "Clipboard busy errors".

 

More important, tktest90 crashes on exit (I think). Narrowed it down to
winClipboard.test (or at least this file by itself triggers the crash unlike
other test files). Anyone testing will likely need to enable the JIT
debugger on Windows else you will not notice the crash as it happens while
exiting. Alternatively, check the Windows Application log where the crash is
reported. My VS Studio debugger reports it cannot determine crash location
because the unhandled exception is .NET 4.0 and the debugger only supports
2.0. I don't even know where .NET enters the picture (does Tk use any UI
features from .NET) ?

 

Linux (Tcl only, do not have a X server)

 

On my WSL installation, all tests pass. 

 

On Stefan's system, 2 zlib failures seen along with a compiler warning.

 

My WSL: Linux IO 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29
23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

 

Stefan's system: Linux tcltk.wu.ac.at 6.9.9-200.fc40.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Jul 11 19:29:01 UTC 2024 x86_64 GNU/Linux

 

==== zlib-8.8 transformation and fconfigure FAILED

==== Contents of test case:

 

    zlib push compress $outSide -dictionary $spdyDict

    fconfigure $outSide -blocking 1 -translation binary -buffering none

    fconfigure $inSide -blocking 1 -translation binary

    puts -nonewline $outSide $spdyHeaders

    chan pop $outSide

    chan close $outSide

    set compressed [read $inSide]

    catch {zlib decompress $compressed} err opt

    list [string length [zlib compress $spdyHeaders]]  [string length
$compressed]  $err [dict get $opt -errorcode] [zlib adler32 $spdyDict]

 

---- Result was:

261 227 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010

---- Result should have been (exact matching):

260 222 {need dictionary} {TCL ZLIB NEED_DICT 2381337010} 2381337010

==== zlib-8.8 FAILED

 

 

 

==== zlib-8.16 Bug 3603553: buffer transfer with large writes FAILED

==== Contents of test case:

 

    set f [open $file wb]

    fconfigure $f -buffering none

    zlib push gzip $f

    puts -nonewline $f $largeData

    close $f

    file size $file

 

---- Result was:

54408

---- Result should have been (exact matching):

57647

==== zlib-8.16 FAILED

 

Additionally during compile the following warning is seen:

 

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c: In function 'TclpCreateProcess':

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:431:18: warning: variable
'dsArray' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]

  431 |     Tcl_DString *dsArray;

      |                  ^~~~~~~

/home/apn/src/tcl9.0b3/unix/tclUnixPipe.c:432:12: warning: variable
'newArgv' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]

  432 |     char **newArgv;

      |            ^~~~~~~

 

No idea why the errors show on Stefan's box but not my WSL. Perhaps gcc
version.

 

/Ashok

Re: [TCLCORE] New Logo ?

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

Note that this is virtually identical to 
https://commons.wikimedia.org/wiki/File:Tcl.svg which is described as an 
"SVG remake" and is licensed for free use with attribution.

Colin.

On 26/07/2024 10:19, Reinhard Max wrote:
> Am 26.07.2024 09:06, schrieb elns:
>
>> (Beware that I'm not meaning to advocate this feather logo.)
>
> It is the one I personally like most among the feather logos for Tcl 
> I've seen so far.
>
>> This feather logo lived a somewhat sorry life. It appears that the
>> original art work got lost at some stage. Also, the logo remained
>> relatively inconspicuous, which I find somewhat remarkable given that
>> it was the first feather logo in a vector format AFAIK.
>
> Well, that logo is probably ActiveState's property and couldn't be 
> used by the Tcl community unless they allow it or hand it over. AS 
> doesn't seem to use it themselves anymore.
>
> They now have a logo for ActiveTcl that looks very different, but FWIW 
> it still sticks to the feather idea:
> https://cdn.activestate.com/wp-content/uploads/2023/11/Tcl-Different.png
>
> Let's ask Jeff if he still has connections to his former employer and 
> could ask if they might be willing to allow the usage of the old 
> ActiveTcl logo for the Tcl/Tk core, maybe with different colors to 
> have a clear distinction.
>
> cu
> Reinhard
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] New Logo ?

[Reinhard M. <rei...@m4...>]

Am 26.07.2024 09:06, schrieb elns:

> (Beware that I'm not meaning to advocate this feather logo.)

It is the one I personally like most among the feather logos for Tcl 
I've seen so far.

> This feather logo lived a somewhat sorry life. It appears that the
> original art work got lost at some stage. Also, the logo remained
> relatively inconspicuous, which I find somewhat remarkable given that
> it was the first feather logo in a vector format AFAIK.

Well, that logo is probably ActiveState's property and couldn't be used 
by the Tcl community unless they allow it or hand it over. AS doesn't 
seem to use it themselves anymore.

They now have a logo for ActiveTcl that looks very different, but FWIW 
it still sticks to the feather idea:
https://cdn.activestate.com/wp-content/uploads/2023/11/Tcl-Different.png

Let's ask Jeff if he still has connections to his former employer and 
could ask if they might be willing to allow the usage of the old 
ActiveTcl logo for the Tcl/Tk core, maybe with different colors to have 
a clear distinction.

cu
Reinhard

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

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

Am 26.07.2024 um 10:34 schrieb Harald Oehlmann:
> 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.
> 
> Hi Donald,
> thank you, great work !
> 
> The 9.0.0b3rc0 is all clean for me on nmake x86 target with MS-VS2015 on 
> a 64 bit Windows computer: compile, test, installation.
> 
> There are the following issues in the man pages I will try to address 
> directly with commits to the main branch:
> 
> ...............clock: process-text: uncaught backslash: If 
> <i>boolean</i> is true (default), <b>clock scan</b> will raise an error
> if the input contains invalid values, e.g. day of month greater than
> number of days in the month. If specified as false, the command makes
> an adjustment to bring values within acceptable range. See
> \fBSCANNING TIMES\fT for details.
> 
> -> /fT instead /fR
> 
> SetOptions: process-text: uncaught backslash
> 
> Great work !
> 
> Thank you for all,
> Harald

I am sorry, I have overseen, that you have already fixed the doc issues. 
Sorry for the double-fix.
Harald

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

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

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.

Hi Donald,
thank you, great work !

The 9.0.0b3rc0 is all clean for me on nmake x86 target with MS-VS2015 on 
a 64 bit Windows computer: compile, test, installation.

There are the following issues in the man pages I will try to address 
directly with commits to the main branch:

...............clock: process-text: uncaught backslash: If 
<i>boolean</i> is true (default), <b>clock scan</b> will raise an error
if the input contains invalid values, e.g. day of month greater than
number of days in the month. If specified as false, the command makes
an adjustment to bring values within acceptable range. See
\fBSCANNING TIMES\fT for details.

-> /fT instead /fR

SetOptions: process-text: uncaught backslash

Great work !

Thank you for all,
Harald

Re: [TCLCORE] New Logo ?

[Alexander S. <a.s...@gm...>]

My Perspective:

Tcl has been intricately linked with the concept of the “feather” for decades.
Take a look at the icons used by social media platforms or IT companies; their design philosophy is to “keep it simple” with minimalistic designs.

I have been using Jan Kovarik’s Glyphicons for many years.
From my experience, when approaching Jan with the request to use the feather icon for the open-source project Tcl/Tk, I’ve found him to be very flexible.

Jan Kovarik of Glyphicons has designed a series of modern icons, which were extensively used in the Twitter Bootstrap project.
About his icons, he says: “GLYPHICONS® are precisely prepared monochromatic icons and symbols, created with an emphasis on simplicity and easy orientation.”

Remarkably, the feather icon from Glyphicons, in SVG format, is just 721 bytes in size.

Furthermore, animated images are considered quite outdated, having fallen out of favor since 2010.

-alex


https://glyphicons.com/sets/basic/
https://glyphicons.com/tools/social/

Re: [TCLCORE] New Logo ?

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

Thanks Erik, that's interesting.

On 26/07/2024 08:06, elns wrote:
> On 7/25/24 22:45, Colin Macleod via Tcl-Core wrote:
>> Another day, another amateur logo design from me:
>>
>> Not animated (so far).  I'm trying to suggest construction from 
>> simple components, and perhaps that building applications with Tcl is 
>> childs play :-) .  The "9" is the feather image from 
>> https://commons.wikimedia.org/wiki/File:Tcl.svg with some TclMagick 
>> transformations applied.
>>
>
> (Beware that I'm not meaning to advocate this feather logo.)
>
> This feather logo lived a somewhat sorry life. It appears that the 
> original art work got lost at some stage. Also, the logo remained 
> relatively inconspicuous, which I find somewhat remarkable given that 
> it was the first feather logo in a vector format AFAIK.
>
> I happen to have the original adobe art work for this logo (at least 
> part of it), which was handed to me by Jeff Hobbs way back in 2006.
>
> I don't know anything about the process by which this logo was 
> ordered, created, accepted and lost again (by ActiveTcl?). I just know 
> that Jeff took some trouble to find/recover these files and emailed 
> them to me when I showed interest.
>
> So, just for sake of doing justice to the origin / history, I repost 
> the files that Jeff sent to me.
>
> Regards,
> Erik.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core