tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] tkblt

[Brian G. <bri...@ea...>]

> On Sep 3, 2025, at 04:29, Harald Oehlmann <har...@el...> wrote:
> 
> Am 03.09.2025 um 01:16 schrieb Brian Griffin:
>> Hi folks!
>> 
>> I have a copy of Tkblt ported to Tcl9. It is based on the code from 
>> William Joye (here: https://github.com/wjoye/tkblt <https://github.com/ 
>> wjoye/tkblt>).
>> I don't know how to contact him.  The most recent update to the repo is 
>> 3 years old, and it's only an update of tclconfig.
>> 
>> I'm thinking I should fork it over the tcltk-depot.
>> 
>> All suggestions welcome!
>> 
>> Thanks,
>> -Brian
> Brian, all,
> I have asked the Astronomics folks.
> They have a great application, partly already ported to TCL 9 which 
> contains BLT and tktable with own patches:
> 
> https://github.com/SAOImageDS9/SAOImageDS9/tree/master/tkblt
> 
> This was, up to now, apparently funded by US. This may stop.
> 
> The main person is William Joye. It is not clear, if his own copies on:
> https://github.com/wjoye
> are identical to the project work.
> 
> It would be great to:
> - find any gems there
> - do the work together

Hi Harald!  Thanks for the info and pointers! 
I am aware of these sites. My local work is based on the wjoye repo. I discovered the DS9 repo later. This is why I'm seeking a contact. 
I will reach out to WJ. I just want a home base where I can push updates and bug fixes that will be accepted. 

I really appreciate your efforts and quick response!

Thanks,
-Brian

> 
> I have given the private E-Mail of William to Brian.
> I hope, Brian may contact him. Massachuchets is more in his region.
> 
> Take care,
> Harald
> <OpenPGP_signature.asc>_______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP Contribution Bug in Tcl 9.0.2

[Alexandru D. <ale...@me...>]

Hi,

In Tcl 9.0.2 there seem is a bug regarding "format" command.

I have this string formatting command:

format "%#9i" 123

With Tcl 8 I get "      123"

With Tcl 9 I get "    0d123"

The usage of the "#" flag comes from a more general procedure, that makes sure, that in case of "e" format (scientific notation) there is always a decimal point available.

In Tcl 8 "#" had no effect on "i" format.

In Tcl 9 it add "0d" to the result.

See also the online discussion on news.tota-refugium.de.

Thanks
Alexandru
________________________________
Alexandru Dadalau
Gesch?ftsf?hrer Entwicklung
Managing Director Development
phone: +49 711 9958 7001
mobile: +49 1522 4841115
fax: +49 711 9958 7199
[Facebook icon]<https://www.facebook.com/Meshparts-1816360291987562/> [Twitter icon] <https://www.twitter.com/Meshparts>  [Youtube icon] <https://www.youtube.com/channel/UCCL0r-Bl5GG_pem3o6XCxAA>  [LinkedIn icon] <https://www.linkedin.com/company/12805433/>  [Instagram icon] <https://www.instagram.com/meshparts/>
[Logo]<https://www.meshparts.de/>
Meshparts GmbH
Hedelfinger Str. 103
D-70327 Stuttgart
Gesch?ftsf?hrer: Alexandru Dadalau, Timo Ziegler
Amtsgericht Stuttgart / HRB 744694
USt.Id.Nr.: DE 289401711
www.meshparts.de<http://www.meshparts.de>
________________________________
Unsubscribe<https://www.meshparts.de/de/unsubscribe>

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[da S. P. J <pet...@fl...>]

As a point of data, there’s six places using Tcl_GetObjType in the Flightaware open source code. I haven’t investigated this further:



https://github.com/search?q=org%3Aflightaware+Tcl_GetObjType&type=code



From: Donald G Porter via Tcl-Core <tcl...@li...>
Date: Tuesday, September 2, 2025 at 14:17
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)
On 8/4/25 10: 16, Miguel Bañón wrote: > So, any reason for not adding Tcl_RegisterObjType(&tclIntType); to TclInitObjSubsystem? Yes. If that registration had continued in Tcl 9, then existing callers of Tcl_GetObjType("int") would be able


On 8/4/25 10:16, Miguel Bañón wrote:

> So, any reason for not adding Tcl_RegisterObjType(&tclIntType); to TclInitObjSubsystem?

Yes.



If that registration had continued in Tcl 9, then existing callers of Tcl_GetObjType("int")

would be able to retrieve the Tcl internal pointer &tclIntType and would continue using

it to peer into the internal representations of Tcl_Obj structs of that type in the false

belief that they knew what to do with the internals of a Tcl "int" value.



TIP 484 was adopted and it revised the internals of Tcl integer types.  Removing the

Tcl_ObjType registration was done intentionally so that all callers who can get into

trouble by these internal changes are confronted with the issue during their migration

from Tcl 8 to Tcl 9.



A new routine in Tcl 9, Tcl_GetNumberFromObj() [TIP 638] may be a good alternative to the

discouraged internals pokery.



This is just one concrete demonstration of one reason why Tcl_ObjType registration

is a poor design and anyone still making use of Tcl_GetObjType() should do what they

can to stop it.  If there's a sincere belief that this kind of internals violation is truly

necessary for something, we should bring that into the light and determine what good

supported and sensible alternatives can provide the functionality better.



--

| Don Porter            Applied and Computational Mathematics Division |

| don...@ni...             Information Technology Laboratory |

| https://urldefense.us/v2/url?u=http-3A__math.nist.gov_-7EDPorter_&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=AdcnALwIPB-yThikeOLnoQrBtcDdxuSqkwxPBDKt-Lf_okO7R8RvtOUl0EoKU2-L&s=nR_cxfY2IdsVTnV52_2uogv2qZT-TCUmSLlRz3oBcow&e=                                  NIST |

|______________________________________________________________________|







_______________________________________________

Tcl-Core mailing list

Tcl...@li...

https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=AdcnALwIPB-yThikeOLnoQrBtcDdxuSqkwxPBDKt-Lf_okO7R8RvtOUl0EoKU2-L&s=5GiDyOujYm1sXsuwRlhJDAXycpe8a1N6vzcrtcTw5O0&e=

Re: [TCLCORE] tkblt

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

Hi,

this sounds interesting! Does anyone know whether this tkblt uses Aqua or is still on X11/XQuartz just as the original BLT?

I tried to compile the SAOImageDS9 app on my arm64 Mac but the resulting binary denies running as macOS reports it being "damaged". Maybe due to missing Xquartz or other problems which I cannot find out about.

Cheers, Torsten


> Am 03.09.2025 um 13:29 schrieb Harald Oehlmann <Har...@El...>:
> 
> Signierter PGP-Teil
> Am 03.09.2025 um 01:16 schrieb Brian Griffin:
>> Hi folks!
>> I have a copy of Tkblt ported to Tcl9. It is based on the code from William Joye (here: https://github.com/wjoye/tkblt <https://github.com/ wjoye/tkblt>).
>> I don't know how to contact him.  The most recent update to the repo is 3 years old, and it's only an update of tclconfig.
>> I'm thinking I should fork it over the tcltk-depot.
>> All suggestions welcome!
>> Thanks,
>> -Brian
> Brian, all,
> I have asked the Astronomics folks.
> They have a great application, partly already ported to TCL 9 which contains BLT and tktable with own patches:
> 
> https://github.com/SAOImageDS9/SAOImageDS9/tree/master/tkblt
> 
> This was, up to now, apparently funded by US. This may stop.
> 
> The main person is William Joye. It is not clear, if his own copies on:
> https://github.com/wjoye
> are identical to the project work.
> 
> It would be great to:
> - find any gems there
> - do the work together
> 
> I have given the private E-Mail of William to Brian.
> I hope, Brian may contact him. Massachuchets is more in his region.
> 
> Take care,
> Harald
> 
> 

Re: [TCLCORE] tkblt

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

Am 03.09.2025 um 01:16 schrieb Brian Griffin:
> Hi folks!
> 
> I have a copy of Tkblt ported to Tcl9. It is based on the code from 
> William Joye (here: https://github.com/wjoye/tkblt <https://github.com/ 
> wjoye/tkblt>).
> I don't know how to contact him.  The most recent update to the repo is 
> 3 years old, and it's only an update of tclconfig.
> 
> I'm thinking I should fork it over the tcltk-depot.
> 
> All suggestions welcome!
> 
> Thanks,
> -Brian
Brian, all,
I have asked the Astronomics folks.
They have a great application, partly already ported to TCL 9 which 
contains BLT and tktable with own patches:

https://github.com/SAOImageDS9/SAOImageDS9/tree/master/tkblt

This was, up to now, apparently funded by US. This may stop.

The main person is William Joye. It is not clear, if his own copies on:
https://github.com/wjoye
are identical to the project work.

It would be great to:
- find any gems there
- do the work together

I have given the private E-Mail of William to Brian.
I hope, Brian may contact him. Massachuchets is more in his region.

Take care,
Harald

Re: [TCLCORE] To list or not to list [Was ...Tcl_RegisterObjType(&tclIntType)]

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

On 03/09/2025 11:34, Christian Werner wrote:
> I see now how you do it in DBus_VariantArg() where
> you inspect the type names of the typePtr in Tcl_Obj.

That is just a last resort in case the caller does not provide type 
information. It is very prone to producing wrong results. Which is why 
the documentation indicates that the "preferred way is for the argument 
to be a two-element list where the first element specifies the signature 
for the value and the second element is the actual value".

I suspect that on Tcl 9 the story in the documentation that the library 
will select a signature of "i" for integers is actually no longer true. 
I may have to revisit that code, or update the documentation. I always 
explicitly specify the type in my own code that uses the dbus library.


Schelte.

Re: [TCLCORE] Oracle data base drivers

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

I’d also like to share my good experience with TDBCJDBC:
https://github.com/ray2501/TDBCJDBC

Dependencies are:
    • Java runtime
    • tclJBlend 2.1.0 (https://androwish.org/home/dir?ci=tip&name=assets/tclJBlend2.1)

With this combination you can get virtually any database running with TDBC, just by using the appropriate JDBC driver. For JDBC there’s usually a connector available, even for very uncommon databases.

I’m using this setup successfully on a daily basis — for example also with MS SQL Server — and it’s a great complement to Oratcl/tdbc::oratcl.

> Am 03.09.2025 um 11:25 schrieb Alexander Schöpe <a.s...@gm...>:
> 
> I always thought Oracle wasn’t part of the TDBC baseline because, unlike the included databases (SQLite, MySQL/MariaDB, PostgreSQL), it’s a commercial product and not open source. On top of that, the Oracle client libraries are a hard dependency, which makes packaging and distribution trickier compared to the others.
> 
> That said, the combination of Oratcl and tdbc::oratcl works very well — I’m using it daily without issues.
> 
>> Am 01.09.2025 um 17:34 schrieb Donal Fellows <don...@ma...>:
>> 
>> It was probably not part of the TDBC baseline because it depended on having the Oracle client library present, which is very much a blocker for many users. I suppose trickery could be done with soft loading the shared library version, but that wasn't done (likely because of workload).
>> 
>> Sometimes the explanation is very simple. :-D
>> 
>> Donal.
>> 
>> -------- Original message --------
>> From: Harald Oehlmann <har...@el...> 
>> Date: 01/09/2025 16:28 (GMT+00:00) 
>> To: Tcl Core List <tcl...@li...> 
>> Subject: [TCLCORE] Oracle data base drivers 
>> 
>> - why is the tdbc driver not part of the tdbc distribution?
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

Re: [TCLCORE] To list or not to list [Was ...Tcl_RegisterObjType(&tclIntType)]

[Christian W. <Chr...@t-...>]

On 09/03/2025 10:07 AM, Schelte Bron wrote:

Howdy Schelte,

> There is a similar need in my dbus library and the rl_json library. In both cases this is solved by using a list, where the first element indicates the type and the second element is the actual value. There is just no reliable way to wrestle this information out of Tcl.
> …

thanks for the pointer. I see now how you do it in DBus_VariantArg() where
you inspect the type names of the typePtr in Tcl_Obj. A very similar task
needs be carried out in OPC/UA where a value has a so called value rank,
which determines, if the value is a scalar or an array or can be either.
Since one can construct arbitrarily nested complex weird types in OPC/UA,
the serializer might need this information to perform its job.

And that was the essence of my question. Is there a defined or specified or
commonly agreed way of determining a Tcl value being a list or something else?

Christian

Re: [TCLCORE] Oracle data base drivers

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

I always thought Oracle wasn’t part of the TDBC baseline because, unlike the included databases (SQLite, MySQL/MariaDB, PostgreSQL), it’s a commercial product and not open source. On top of that, the Oracle client libraries are a hard dependency, which makes packaging and distribution trickier compared to the others.

That said, the combination of Oratcl and tdbc::oratcl works very well — I’m using it daily without issues.

> Am 01.09.2025 um 17:34 schrieb Donal Fellows <don...@ma...>:
> 
> It was probably not part of the TDBC baseline because it depended on having the Oracle client library present, which is very much a blocker for many users. I suppose trickery could be done with soft loading the shared library version, but that wasn't done (likely because of workload).
> 
> Sometimes the explanation is very simple. :-D
> 
> Donal.
> 
> -------- Original message --------
> From: Harald Oehlmann <har...@el...> 
> Date: 01/09/2025 16:28 (GMT+00:00) 
> To: Tcl Core List <tcl...@li...> 
> Subject: [TCLCORE] Oracle data base drivers 
> 
> - why is the tdbc driver not part of the tdbc distribution?
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] tkblt

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

Am 03.09.2025 um 01:16 schrieb Brian Griffin:
> Hi folks!
> 
> I have a copy of Tkblt ported to Tcl9. It is based on the code from 
> William Joye (here: https://github.com/wjoye/tkblt <https://github.com/ 
> wjoye/tkblt>).
> I don't know how to contact him.  The most recent update to the repo is 
> 3 years old, and it's only an update of tclconfig.
> 
> I'm thinking I should fork it over the tcltk-depot.
> 
> All suggestions welcome!
> 
> Thanks,
> -Brian
> 
Great news !
He is from the Astrology society. I have contact to them via OleBole. I 
may ask Ole.

Take care,
Harald

Re: [TCLCORE] To list or not to list [Was ...Tcl_RegisterObjType(&tclIntType)]

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

Hello Christian,

There is a similar need in my dbus library and the rl_json library. In 
both cases this is solved by using a list, where the first element 
indicates the type and the second element is the actual value. There is 
just no reliable way to wrestle this information out of Tcl.

Another technique I've seen used elsewhere (I don't remember where) is 
to make tcloo classes for each type. So you could do things like:

Integer create v 42
List create l 42
String create s 42

Then by investigating the class of $v, $l or $s you can determine if the 
object is an integer, a list, or a string. Alternatively you could 
implement a type method in each class.


Schelte.


On 03/09/2025 09:47, Christian Werner wrote:
> So lemme try to explain my question using a snippet:
> 
> ---8><---
> 
> proc tlontl {x} {
>      puts [::tcl::unsupported::representation $x]
> }
> 
> proc vtlontl {v} {
>      upvar $v vv
>      tlontl $vv
> }
> 
> proc indir {} {
>      set v 42
>      tlontl $v        ;# 8.6 "value is a pure string..."
>      set v [list 42]
>      tlontl $v        ;# 8.6 "value is a list..."
> }
> 
> tlontl 42        ;# 8.6 "value is a pure string..."
> tlontl [list 42] ;# 8.6 "value is a list..."
> 
> set v 42
> tlontl $v        ;# 8.6 "value is a pure string..."
> vtlontl v        ;# 8.6 "value is a pure string..."
> set v [list 42]
> tlontl $v        ;# 8.6 "value is a list..."
> vtlontl v        ;# 8.6 "value is a list..."
> 
> indir
> 
> ---8><---
> 
> And still the fine question my C code wants to be answered:
> Is „something“ a list or not. Whether 'tis nobler in the
> mind to suffer the strings and chars of outrageous fortune,
> or to take a list against an array of troubles…
> 
> Christian

[TCLCORE] To list or not to list [Was ...Tcl_RegisterObjType(&tclIntType)]

[Christian W. <Chr...@t-...>]

So lemme try to explain my question using a snippet:

---8><---

proc tlontl {x} {
     puts [::tcl::unsupported::representation $x]
}

proc vtlontl {v} {
     upvar $v vv
     tlontl $vv
}

proc indir {} {
     set v 42
     tlontl $v        ;# 8.6 "value is a pure string..."
     set v [list 42]
     tlontl $v        ;# 8.6 "value is a list..."
}

tlontl 42        ;# 8.6 "value is a pure string..."
tlontl [list 42] ;# 8.6 "value is a list..."

set v 42
tlontl $v        ;# 8.6 "value is a pure string..."
vtlontl v        ;# 8.6 "value is a pure string..."
set v [list 42]
tlontl $v        ;# 8.6 "value is a list..."
vtlontl v        ;# 8.6 "value is a list..."

indir

---8><---

And still the fine question my C code wants to be answered:
Is „something“ a list or not. Whether 'tis nobler in the
mind to suffer the strings and chars of outrageous fortune,
or to take a list against an array of troubles…

Christian

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

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

Op wo 3 sep 2025 om 00:09 schreef Christian Werner:
> 1. the question in C world (extension): Tcl_Obj *o* is a list or not
> 2. this should report true or false without shimmering or side effects
> 3. what is the ifdef'ery for Tcl 8 versus 9 to answer this question
> 4. are there *similar* questions regarding other Tcl_Obj types?
> 5. where are the subtle pitfalls in various versions of Tcl?
> 6. is there some polyfill'ery to overcome various Tcl versions?

I don't have an answer to all those questions. Only for lists,
the behavior in Tcl 9 should be well-behaved (= no
unnecessary shimmering). Dicts and Lists still can be
shimmered into each other (ideas to improve that
are welcome)

> But finally to come back to my code in the topcua extension:
> The fine point is to distinguish between these two snippets
>
>    dosomething ... 42
>
> and
>
>    domsomething ... [list 42]
>
> and to have in both cases the means in C to see if the first
> thing is a scalar and the second a list. And this should be
> irrelevant of the Tcl version.

Well:
    % puts 42
    42
    % puts [list 42]
    42

No, those 2 cannot be distinguished. If your code
expects a scalar or a list of scalars, you can
distings them like:

Tcl_Size length;
if (Tcl_GetNumberFromObj(NULL, listObj ...)) {
    // It's a scalar.
} else if (Tcl_ListObjLength(NULL, listObj, &length) == TCL_OK) {
    // It can be handled as a list. Loop over the
    // elements, and handle each of them.
} else {
    // Not a list.
}

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

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

That's actually difficult here, because that specific example will compile to identical bytecode; the compiler for [list] notes that it has a list of literals and just builds a literal of the lot. Which quite possibly gets merged with the '42' literal because that's how literals work.

That's compounded by the fact that it's unsafe to look at the type identity (or its name) because those are subject to change. For example, 9.0 introduces [lseq], which has its own result type despite that working a lot like a list. We've also varied a lot in how we represent integers over the years.

Tcl isn't designed for variability of operation by type, which means you're stuck with an impedance mismatch. (It is instead excellent a variability by argument count. Not that that helps you here.)

Donal.

-------- Original message --------
From: Christian Werner <Chr...@t-...>
Date: 02/09/2025 23:10 (GMT+00:00)
To: Jan Nijtmans <jan...@gm...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)


But finally to come back to my code in the topcua extension:
The fine point is to distinguish between these two snippets

   dosomething ... 42

and

   domsomething ... [list 42]

and to have in both cases the means in C to see if the first
thing is a scalar and the second a list. And this should be
irrelevant of the Tcl version.

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[Brian G. <bri...@ea...>]

> On Sep 2, 2025, at 22:32, Christian Werner <Chr...@t-...> wrote:
> 
> On 09/03/2025 02:46 AM, Brian Griffin wrote:
> 
>> …
>> I’m curious what the C code is going to do with this knowledge?
>> 
>> Is it going to ask for a string?
>> Is it going to ask for a number?
>> Does the algorithm change based on the “type”?
>> Is the intention to avoid shimmering,
>> or is there a different motive?
> 
> The snippets (I think two places) shall decide on how to serialize „something”.
> And only want to know if „something“ is a list, which stands for an array, or not,
> representing a scalar value. Of course shall this question in no way modify the
> „something“. Yes, a scalar is different to an array with size one.
> 
> Thats all,
> Christian

Ah, yes, except, “Everything is a string.”

-Brian 

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[Christian W. <Chr...@t-...>]

On 09/03/2025 02:46 AM, Brian Griffin wrote:

> …
> I’m curious what the C code is going to do with this knowledge?
>
> Is it going to ask for a string?
> Is it going to ask for a number?
> Does the algorithm change based on the “type”?
> Is the intention to avoid shimmering,
> or is there a different motive?

The snippets (I think two places) shall decide on how to serialize „something”.
And only want to know if „something“ is a list, which stands for an array, or not,
representing a scalar value. Of course shall this question in no way modify the
„something“. Yes, a scalar is different to an array with size one.

Thats all,
Christian

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[Brian G. <bri...@ea...>]

> On Sep 2, 2025, at 15:10, Christian Werner <Chr...@t-...> wrote:
> 
> On 09/02/2025 11:34 PM, Jan Nijtmans wrote:
>> Op di 2 sep 2025 om 23:06 schreef Christian Werner:
>>> would you like to provide a similar snippet for dicts and possibly
>>> other candidates, too?
>> 
>> Dicts are lists with an even number of arguments, that's all
>> we can say.
>> 
>>> The fine point was to know in advance, if the Tcl_Obj is a list or not.
>> But the nice Tcl_ListObjLength() call will make a scalar into a list,
>> isn't it? And answer the question with TCL_OK. So the scalar will be
>> suddenly a list. So the question is shadowed by shimmering somehow.
>> 
>> Tcl 9.0 doesn't shimmer to a list any more, when you use
>> Tcl_ListObjLength() and the Tcl_Obj has another (scalar)
>> type already. That's the point. Scalars won't be converted
>> to a list any more.
>> 
>> In Tcl 8.6, yes this kind of shimmering occurs, unfortunately.
>> So only use this for Tcl 9.0+.
> 
> OK, intriguing indeed, one learns a new detail each day.
> 
> Now let us find exactly out, what needs to be clearly *documented* somehow:
> 
> 1. the question in C world (extension): Tcl_Obj *o* is a list or not
> 2. this should report true or false without shimmering or side effects
> 3. what is the ifdef'ery for Tcl 8 versus 9 to answer this question
> 4. are there *similar* questions regarding other Tcl_Obj types?
> 5. where are the subtle pitfalls in various versions of Tcl?
> 6. is there some polyfill'ery to overcome various Tcl versions?
> 
> But finally to come back to my code in the topcua extension:
> The fine point is to distinguish between these two snippets
> 
>  dosomething ... 42
> 
> and
> 
>  domsomething ... [list 42]
> 
> and to have in both cases the means in C to see if the first
> thing is a scalar and the second a list. And this should be
> irrelevant of the Tcl version.

I’m curious what the C code is going to do with this knowledge?

Is it going to ask for a string?
Is it going to ask for a number?
Does the algorithm change based on the “type”?
Is the intention to avoid shimmering, 
or is there a different motive?

-Brian 

> 
> Hope this example helps to understand my pressure,
> Christian
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

[TCLCORE] tkblt

[Brian G. <bri...@ea...>]

Hi folks!

I have a copy of Tkblt ported to Tcl9. It is based on the code from William Joye (here: https://github.com/wjoye/tkblt).
I don't know how to contact him.  The most recent update to the repo is 3 years old, and it's only an update of tclconfig.

I'm thinking I should fork it over the tcltk-depot.

All suggestions welcome!

Thanks,
-Brian

Re: [TCLCORE] Verge of Merge Warning

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

Sorry about that.  I think I got it right this time.

- Marc

On Tue, Sep 2, 2025 at 6:56 PM Erik Leunissen <el...@xs...> wrote:

> On 9/3/25 00:26 , Marc Culler wrote:
>
> Thanks Erik.  That is a typo.
>
>
> Hi Marc,
>
> After commit #0d3f0cf313, the tests 12.2 and 8.17 still never execute.
> I think that the typo was "fixed" in the opposite direction.
>
> See also the file constraints.tcl for the definition of test constraint
> notAqua.
>
> Regards,
> Erik.
> --
>
>
> - Marc
>
> On Tue, Sep 2, 2025 at 4:51 PM Erik Leunissen <el...@xs...> wrote:
>
>> On 9/2/25 23:11, Marc Culler wrote:
>> > This is a warning that I am on the verge of merging the mac_send branch
>> into main.
>> >
>>
>> Hi Marc,
>>
>> I had a look at the changes in the test file send.test, and noticed that
>> some of the
>> tests that originally carried the test constraint "notAqua", now have a
>> constraint
>> "nonAqua". Note the one letter difference.
>>
>> Because the constraint "nonAqua" is nowhere defined, these tests are
>> never executed.
>>
>> Is this on purpose or just a typo?
>>
>> Regards,
>> Erik.
>> --
>>
>>

Re: [TCLCORE] Verge of Merge Warning

[Erik L. <el...@xs...>]

On 9/3/25 00:26 , Marc Culler wrote:

> Thanks Erik.  That is a typo.

Hi Marc,

After commit #0d3f0cf313, the tests 12.2 and 8.17 still never execute.
I think that the typo was "fixed" in the opposite direction.

See also the file constraints.tcl for the definition of test constraint 
notAqua.

Regards,
Erik.
--

>
> - Marc
>
> On Tue, Sep 2, 2025 at 4:51 PM Erik Leunissen <el...@xs...> wrote:
>
>     On 9/2/25 23:11, Marc Culler wrote:
>     > This is a warning that I am on the verge of merging the mac_send
>     branch into main.
>     >
>
>     Hi Marc,
>
>     I had a look at the changes in the test file send.test, and
>     noticed that some of the
>     tests that originally carried the test constraint "notAqua", now
>     have a constraint
>     "nonAqua". Note the one letter difference.
>
>     Because the constraint "nonAqua" is nowhere defined, these tests
>     are never executed.
>
>     Is this on purpose or just a typo?
>
>     Regards,
>     Erik.
>     --
>

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[Christian W. <Chr...@t-...>]

On 09/02/2025 11:34 PM, Jan Nijtmans wrote:
> Op di 2 sep 2025 om 23:06 schreef Christian Werner:
>> would you like to provide a similar snippet for dicts and possibly
>> other candidates, too?
>
> Dicts are lists with an even number of arguments, that's all
> we can say.
>
>> The fine point was to know in advance, if the Tcl_Obj is a list or not.
> But the nice Tcl_ListObjLength() call will make a scalar into a list,
> isn't it? And answer the question with TCL_OK. So the scalar will be
> suddenly a list. So the question is shadowed by shimmering somehow.
>
> Tcl 9.0 doesn't shimmer to a list any more, when you use
> Tcl_ListObjLength() and the Tcl_Obj has another (scalar)
> type already. That's the point. Scalars won't be converted
> to a list any more.
>
> In Tcl 8.6, yes this kind of shimmering occurs, unfortunately.
> So only use this for Tcl 9.0+.

OK, intriguing indeed, one learns a new detail each day.

Now let us find exactly out, what needs to be clearly *documented* somehow:

1. the question in C world (extension): Tcl_Obj *o* is a list or not
2. this should report true or false without shimmering or side effects
3. what is the ifdef'ery for Tcl 8 versus 9 to answer this question
4. are there *similar* questions regarding other Tcl_Obj types?
5. where are the subtle pitfalls in various versions of Tcl?
6. is there some polyfill'ery to overcome various Tcl versions?

But finally to come back to my code in the topcua extension:
The fine point is to distinguish between these two snippets

   dosomething ... 42

and

   domsomething ... [list 42]

and to have in both cases the means in C to see if the first
thing is a scalar and the second a list. And this should be
irrelevant of the Tcl version.

Hope this example helps to understand my pressure,
Christian

Re: [TCLCORE] Verge of Merge Warning

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

Thanks, Jan.

- Marc

On Tue, Sep 2, 2025 at 4:29 PM Jan Nijtmans <jan...@gm...> wrote:

> Op di 2 sep 2025 om 23:12 schreef Marc Culler <cul...@gm...>:
> >
> > This is a warning that I am on the verge of merging the mac_send branch
> into main.
>
> No objection at all, on the contrary!   I think it's excellent what
> you are doing!
>
> Regards,
>     Jan Nijtmans
>

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

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

Op di 2 sep 2025 om 23:06 schreef Christian Werner:
> would you like to provide a similar snippet for dicts and possibly
> other candidates, too?

Dicts are lists with an even number of arguments, that's all
we can say.

> The fine point was to know in advance, if the Tcl_Obj is a list or not.
But the nice Tcl_ListObjLength() call will make a scalar into a list,
isn't it? And answer the question with TCL_OK. So the scalar will be
suddenly a list. So the question is shadowed by shimmering somehow.

Tcl 9.0 doesn't shimmer to a list any more, when you use
Tcl_ListObjLength() and the Tcl_Obj has another (scalar)
type already. That's the point. Scalars won't be converted
to a list any more.

In Tcl 8.6, yes this kind of shimmering occurs, unfortunately.
So only use this for Tcl 9.0+.

Hope this helps,
        Jan Nijtmans

Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)

[Christian W. <Chr...@t-...>]

On 09/02/2025 11:17 PM, Christian Werner wrote:
> On 09/02/2025 11:06 PM, Christian Werner wrote:
>> On 09/02/2025 10:44 PM, Jan Nijtmans wrote:
>>
>> Jan, fine, thanks,
>>
>>> Tcl_Size length;
>>> if (Tcl_ListObjLength(NULL, listObj, &length) == TCL_OK) {
>>>     if (length > 1) {
>>>          // Sure, this can be handled as a list
>>>     } else {
>>>          // Either a single element, or a one-element list,
>>>          // Tcl cannot distinguish between that.
>>>     }
>>> } else {
>>>     // Not a list
>>> }
>>
>> would you like to provide a similar snippet for dicts and possibly
>> other candidates, too?
>>
>> And what about to *document* this *prominently* for all those
>> noobs like me, that we shall be never, ever, ever, ever, refer
>> to the holy Tcl_ObjType.
>
> And what lets me now be somehow clueless: Why then is Tcl_GetObjType()
> a public procedure? Is it nowadays deprecated?

Finally, my conclusion is, that your snippet will not resolve the quest.
The fine point was to know in advance, if the Tcl_Obj is a list or not.
But the nice Tcl_ListObjLength() call will make a scalar into a list,
isn't it? And answer the question with TCL_OK. So the scalar will be
suddenly a list. So the question is shadowed by shimmering somehow.

Am I wrong?
Christian

Re: [TCLCORE] Verge of Merge Warning

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

Op di 2 sep 2025 om 23:12 schreef Marc Culler <cul...@gm...>:
>
> This is a warning that I am on the verge of merging the mac_send branch into main.

No objection at all, on the contrary!   I think it's excellent what
you are doing!

Regards,
    Jan Nijtmans