tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Verge of Merge Warning

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

In all of these things, you start by doing the bits you can see how to do. I suggest writing some "happy path" tests first to check for a lack of surprises for users using things simply and as they are intended to be used. Then check for syntax errors in the command(s) and other basic bits, and then try to characterise known bugs or places you suspect tricky callbacks might cause trouble. The very energetic can try to get code coverage up... but that's generally quite hard to do, especially full path coverage, and I don't know of good tooling for that in either Tcl or C.

Donal.

-------- Original message --------
From: Erik Leunissen via Tcl-Core <tcl...@li...>
Date: 04/09/2025 08:19 (GMT+00:00)
To: Marc Culler <cul...@gm...>, Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Verge of Merge Warning

What concerns me is that someone has to be responsible for:
* deciding what tests are appropriate/necessary to test the functionality of the
   mac_send branch in general. That is, regardless of any existing tests (flawed or
   not). IMO that includes a test for the bug in ticket #ff2ca8b34c .
* create new tests and modify existing ones, and exercise them specifically on macOS
* making the necessary changes to the test suite in fossil

I'm not in a position to do that [*].

    (I understand very well that it's sometimes difficult to see through the
     workings/purpose of existing tests. I experience that regularly. Maybe
     others can help?)

My contribution:
* I can provide straightforward versions for the tests winfo-5.4 and winfo-5.5.
* In ticket #ff2ca8b34c, I already supplied a test script that exercises the
   bug reported there. That script can be used as a basis for a test.

If you take the lead (insofar as you have opportunity of course), I'm happy to
proceed and provide you with the straightforward versions of tests winfo-5.4 and
winfo-5.5.

Do you think that we could proceed in a useful way along these lines?

Erik.
--
[*] I'm not familiar with the code in branch mac_send, and no dev environment
     (yet) for macOS, I can run stand-alone scripts on macOS for Tk8.6.16)

      B.t.w. sorry for screwing up your last name below. I just found out that that's
      the result of an overly ambitious spell-checker :-(

Re: [TCLCORE] Verge of Merge Warning

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

On 9/3/25 22:01, Marc Culler wrote:
> Do you know what those tests would look like if they were done in a straightforward way? (I often 
> have trouble guessing what our tests are attempting to test and usually don't find any comments to 
> help me out.) If you do have a candidates for better version of those tests we could just use them 
> in place of the current ones,
> 

Hi Marc,

What concerns me is that someone has to be responsible for:
* deciding what tests are appropriate/necessary to test the functionality of the
   mac_send branch in general. That is, regardless of any existing tests (flawed or
   not). IMO that includes a test for the bug in ticket #ff2ca8b34c .
* create new tests and modify existing ones, and exercise them specifically on macOS
* making the necessary changes to the test suite in fossil

I'm not in a position to do that [*].

    (I understand very well that it's sometimes difficult to see through the
     workings/purpose of existing tests. I experience that regularly. Maybe
     others can help?)

My contribution:
* I can provide straightforward versions for the tests winfo-5.4 and winfo-5.5.
* In ticket #ff2ca8b34c, I already supplied a test script that exercises the
   bug reported there. That script can be used as a basis for a test.

If you take the lead (insofar as you have opportunity of course), I'm happy to
proceed and provide you with the straightforward versions of tests winfo-5.4 and
winfo-5.5.

Do you think that we could proceed in a useful way along these lines?

Erik.
--
[*] I'm not familiar with the code in branch mac_send, and no dev environment
     (yet) for macOS, I can run stand-alone scripts on macOS for Tk8.6.16)

      B.t.w. sorry for screwing up your last name below. I just found out that that's
      the result of an overly ambitious spell-checker :-(

> - Marc
> 
> On Wed, Sep 3, 2025, 12:53 PM Erik Leunissen <el...@xs... <mailto:el...@xs...>> wrote:
> 
>     On 9/2/25 23:11, Marc Ruller wrote:
> 
>      > Some key points:
>      >
>      > * The CI tests pass. ...
> 
> 
>     Hi Marc,
> 
>     The tests currently held by the Tk test suite (and hence what's being
>     exercised by Github CI), do not expose macOS specific misbehaviour such
>     as reported in ticket:
> 
>     https://core.tcl-lang.org/tk/tktview/ff2ca8b34c <https://core.tcl-lang.org/tk/tktview/ff2ca8b34c>
> 
>     What's worse: the Tk test suite holds some tests that seem to have their
>     implementation tweaked to not being bothered by that misbehaviour, being
>     tests winfo-5.4 and winfo-5.5.
> 
>     So, my question is: how do you intend to let the Tk test suite determine
>     that the behaviour of branch mac_send is correct?
> 
>     Regards
>     Erik.
>     --
> 

Re: [TCLCORE] tkblt

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

> On Sep 3, 2025, at 16:49, Emiliano <emi...@gm...> wrote:
> 
> On Tue, 2 Sep 2025 23:16:52 +0000
> Brian Griffin <bri...@ea...> wrote:
> 
>> 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!
> 
> Just a heads up about the name: the original copyright reads
> 
> *   4) Products derived from this software may not be called "BLT" nor may
> *      "BLT" appear in their names without specific prior written
> *      permission from the author.
> 
> Does the author of the fork have such permission?
> 
> Regards
> 
> --
> Emiliano

Thanks Emiliano, I will look into this for sure!

-Brian 

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

Re: [TCLCORE] tkblt

[George Y. <geo...@gm...>]

Hello, sorry for the cutting into conversation, but Emiliano already has a
tcl9 fork of Rbc project, that does many things blt does. Maybe it is worth
to put efforts in that fork?

Regards, George

On Thu, 4 Sept 2025, 00:48 Emiliano, <emi...@gm...> wrote:

> On Tue, 2 Sep 2025 23:16:52 +0000
> Brian Griffin <bri...@ea...> wrote:
>
> > 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!
>
> Just a heads up about the name: the original copyright reads
>
>  *   4) Products derived from this software may not be called "BLT" nor may
>  *      "BLT" appear in their names without specific prior written
>  *      permission from the author.
>
> Does the author of the fork have such permission?
>
> Regards
>
> --
> Emiliano
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] tkblt

[Emiliano <emi...@gm...>]

On Tue, 2 Sep 2025 23:16:52 +0000
Brian Griffin <bri...@ea...> wrote:

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

Just a heads up about the name: the original copyright reads

 *   4) Products derived from this software may not be called "BLT" nor may
 *      "BLT" appear in their names without specific prior written
 *      permission from the author.

Does the author of the fork have such permission?

Regards

-- 
Emiliano

Re: [TCLCORE] Verge of Merge Warning

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

Do you know what those tests would look like if they were done in a
straightforward way? (I often have trouble guessing what our tests are
attempting to test and usually don't find any comments to help me out.) If
you do have a candidates for better version of those tests we could just
use them in place of the current ones,

- Marc

On Wed, Sep 3, 2025, 12:53 PM Erik Leunissen <el...@xs...> wrote:

> On 9/2/25 23:11, Marc Ruller wrote:
>
> > Some key points:
> >
> > * The CI tests pass. ...
>
>
> Hi Marc,
>
> The tests currently held by the Tk test suite (and hence what's being
> exercised by Github CI), do not expose macOS specific misbehaviour such
> as reported in ticket:
>
>      https://core.tcl-lang.org/tk/tktview/ff2ca8b34c
>
> What's worse: the Tk test suite holds some tests that seem to have their
> implementation tweaked to not being bothered by that misbehaviour, being
> tests winfo-5.4 and winfo-5.5.
>
> So, my question is: how do you intend to let the Tk test suite determine
> that the behaviour of branch mac_send is correct?
>
> Regards
> Erik.
> --
>
>

Re: [TCLCORE] Verge of Merge Warning

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

On 9/2/25 23:11, Marc Ruller wrote:

> Some key points:
> 
> * The CI tests pass. ...


Hi Marc,

The tests currently held by the Tk test suite (and hence what's being
exercised by Github CI), do not expose macOS specific misbehaviour such
as reported in ticket:

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

What's worse: the Tk test suite holds some tests that seem to have their
implementation tweaked to not being bothered by that misbehaviour, being
tests winfo-5.4 and winfo-5.5.

So, my question is: how do you intend to let the Tk test suite determine
that the behaviour of branch mac_send is correct?

Regards
Erik.
--

Re: [TCLCORE] tkblt

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

"Damaged" usually means that the signature is invalid or missing. One way
to trash the signature is to append a zipped file.

- Marc

On Wed, Sep 3, 2025, 8:53 AM Torsten Berg <be...@ty...> wrote:

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

Re: [TCLCORE] TIP Contribution Bug in Tcl 9.0.2

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

Op wo 3 sep 2025 om 17:25 schreef Alexandru Dadalau:

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

That's a feature, not a bug.  Just leave out the '#' and it will work
the same in 8.6 as in 9.0

Hope this helps,
     Jan Nijtmans

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

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

Sergey – one of these is in tclclockmod:

https://github.com/sebres/tclclockmod/blob/master/generic/tclClockMod.c#L50

From: da Silva, Peter J <pet...@fl...>
Date: Wednesday, September 3, 2025 at 09:01
To: Donald G Porter <don...@ni...>, tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [EXTERNAL] Tcl_RegisterObjType(&tclIntType)
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


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<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Dorg-253Aflightaware-2BTcl-5FGetObjType-26type-3Dcode&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=jpJCSXHyIMfLFfXJQo7uXRF7GbZdYPiKppFzpdZeeJZe0e1L224zPYtz7dFW0Blz&s=szTnZy62gkuZhrRNEhUWVaXXet7FWXh_VJXgTSkoxHg&e=>

Re: [TCLCORE] tkblt

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

Hi Torsten,

I don't know the answer directly, but I have built tkblt on my mac, and there is a crash in one of the tests.  I haven't yet dug into it to determine the problem, but a brief glance seems to indicate possible X11 related call. (Note: these tests all pass on linux)

-Brian

> On Sep 3, 2025, at 06:40, Torsten Berg <be...@ty...> wrote:
> 
> 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
>> 
>> 
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

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.