tcl-core — Tcl Core Team discussions about Tcl development

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

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

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

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?

[TCLCORE] Verge of Merge Warning

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

This is a warning that I am on the verge of merging the mac_send branch
into main.

The branch re-implements the *send* command on macOS to allow sending to an
interpreter running in a different process from the sender.  The receiving
process is required to be owned by the same user as the sending process and
to be running on the same system.

Some key points:
* The code has been reviewed by Kevin Walzer and Steve Landers.
* I am not writing a TIP on the grounds that this is not adding any new
features; it is only implementing documented features which never got
written in the macOS port.  (I more or less followed the plan outlined in
the comments of the old tkMacOSXSend.c file.)
* The implementation uses Tk's existing mechanism for receiving DoScript
AppleEvents to do  the IPC.
* The CI tests pass.  Unfortunately I had to leave the nonPortable
constraint in place for three tests which pass reliably on my computers,
because sending the DoScript AppleEvent times out on the CI runner.

- Marc

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

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

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.

Thank you.
Christian

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

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

Op di 2 sep 2025 om 22:18 schreef Christian Werner:
> So Don, would you like to provide me some alternative in one of my
> extensions, where it is crucial to know if a Tcl_Obj is a list (or not)
> for further processing.

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
}

Hope this helps,
      Jan Nijtmans

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

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

On 09/02/2025 09:16 PM, Donald G Porter via Tcl-Core wrote:

> ...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.

So Don, would you like to provide me some alternative in one of my
extensions, where it is crucial to know if a Tcl_Obj is a list (or not)
for further processing.

Please review (search for "listObjType")
  
   https://androwish.org/home/file?name=jni/topcua/topcua.c&ci=tip

and please suggest a better alternative.

Thank you very much in advance,
Christian