Tcl 9 functions using Tcl_Size

[Paul Obermeier]

See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize

That page lists the functions, which use Tcl_Size either as return value or as parameter type.
It may help C/C++ extension developers to port their code to Tcl 9.

Regards,
Paul

[Ralf Fassel]

* Paul Obermeier <ober...@poSoft.de>

How does the compiler 'know' whether Tcl_Size is a defined type?
It would be nice if the above page either contained directly or via link
the preferred way to use Tcl_Size in code which should compile on both
tcl 8.[67] and tcl 9.x.

R'

[Paul Obermeier]

I currently use the following approach to make my extensions compile with 8.6, 8.7 and 9.0:

Change all appropriate variables or return values from int to Tcl_Size
and add the following typedef in an extension header file:

#if TCL_MAJOR_VERSION < 9
typedef int Tcl_Size;
#endif

And as an optional short-cut for often used statements:
#define TCL_NULL (Tcl_Size *)NULL

Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);

If anybody has a better solution, feel free to speak up.

Paul

[Harald Oehlmann]

To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
typedef int Tcl_Size;
so, one may always use TCL_SIZE as data type.

Nevertheless, the explanation by Paul is valuable.

TCL 8.7 will go one step further and also name the parameters TCL_SIZE
instead int:
See here:
https://core.tcl-lang.org/tcl/info/74d5501caf2f690a

Take care,
Harald

[Harald Oehlmann]

See here for the future TCL.h content:

https://core.tcl-lang.org/tcl/file?name=generic/tcl.h&ci=tip&ln=418-426

[Ralf Fassel]

* Harald Oehlmann <wort...@yahoo.com>

| > Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
| >> * Paul Obermeier <ober...@poSoft.de>
| >> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
| >>>
| >> | That page lists the functions, which use Tcl_Size either as return
| >> | value or as parameter type.  It may help C/C++ extension developers to
| >> | port their code to Tcl 9.
| >>
| >> How does the compiler 'know' whether Tcl_Size is a defined type?
| >> It would be nice if the above page either contained directly or via link
| >> the preferred way to use Tcl_Size in code which should compile on both
| >> tcl 8.[67] and tcl 9.x.
| >>

--<snip-snip>--

| To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
| typedef int Tcl_Size;
| so, one may always use TCL_SIZE as data type.

That's good news. I'd rather have something in tcl.h than every
developer rolling their own logic.

R'

[Paul Obermeier]

That's fine and easy, if you want to support 9.0, 8.7 and 8.6.14 only.

But what about supporting older 8.6.X or even 8.5.X versions?
Then you have to add a more complex macro statement to either define the missing typedef
and to avoid warnings regarding duplicate typedefs.

Something like this:

#if TCL_MAJOR_VERSION == 8
#if TCL_MINOR_VERSION < 6 || ( TCL_MINOR_VERSION == 6 && TCL_PATCH_VERSION < 14 )
typedef int Tcl_Size;
#endif
#endif

I do not know of a mechanism in C/C++ to detect already defined typedefs,
similar to #ifdef.

Paul

[Schelte]

On 23/08/2023 20:18, Paul Obermeier wrote:
> I do not know of a mechanism in C/C++ to detect already defined typedefs,
> similar to #ifdef.

I observed that TCL_SIZE_MAX is introduced along with Tcl_Size, so for
my dbus extension is was thinking of doing:

#ifndef TCL_SIZE_MAX
typedef int Tcl_Size;
#endif


Schelte.

[Rolf Ade]

Paul Obermeier <ober...@poSoft.de> writes:
> I currently use the following approach to make my extensions compile with 8.6, 8.7 and 9.0:
>

> [good advice]

>
> And as an optional short-cut for often used statements:
> #define TCL_NULL (Tcl_Size *)NULL
>
> Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);
>
> If anybody has a better solution, feel free to speak up.

For this one: remove the compatibility macros and this one is gone ...

rolf

[Paul Obermeier]

This approach seems better than looking at the Tcl version numbers.
What about introducing a separate macro in tcl.h?, ex.
#define HAVE_TCL_SIZE

Paul

[Aldo Buratti]

Can you suggest me a link for downloading TCL9.0 binaries ? github ?
Thank you

[Harald Oehlmann]

Dear Aldo,
thanks, that you want to test TCL9, currently in Beta 1 rc0.

Currently, we are in build testing, so it is supposed, that you build on
your own from the source.

But the sourceforge project also gives you compiled binaries.

Look here and find a workflow, which succeeded and is for your platform.

https://github.com/tcltk/tcl/actions

- Choose the workflow
- Scroll down to show the Artefacts. Those are build versions.

Take care,
Harald

[Christian Gollwitzer]

Am 22.11.23 um 17:19 schrieb Harald Oehlmann:

> Look here and find a workflow, which succeeded and is for your platform.
>
> https://github.com/tcltk/tcl/actions
>
> - Choose the workflow
> - Scroll down to show the Artefacts. Those are build versions.

Additionally, you must be logged in to github in order to access this
page. If you aren't logged in, you'll see nothing.

Christian

[et99]

And, if I hadn't seen the above "scroll down" I wouldn't have found it either. In FF, with the mouse pointer in the blue area where it lists the 3 systems, the mousewheel won't scroll and so I never found the artifacts section until I stumbled onto that gotcha lol :)

Eventually, I downloaded a 9.0 windows wish, and it just crashed silently - a system monitor showed that a program werfault.exe was run as it's child process (description: windows problem reporting); however, an 8.7a6 would run.

A linux 9.0 wish did run, but I wanted to test some thread stuff and it doesn't have the thread package built in. I tried pointing auto_path to the directory where an installed 8.6.9 libthread2.8.4.so lives but it said it couldn't find the package, and when I tried to just load it, it said:

$ rlwrap ./wish9.0a4_snapshot
% load /home/et/test/libthread2.8.4.so
interpreter uses an incompatible stubs mechanism

So, while useful to try some new built in stuff, like lseq, it's not of much help to me.

[Aldo Buratti]

Im' logged in GitHub.
I can see a lot of actions with 0 artifacts, and the this one
https://github.com/tcltk/tcl/actions/runs/6940949916
with 3 artifacts.
.. downloaded the Linux artifact .. it just contains the "tcl_library" directory. Where are the binaries ?
I'm new with these actions/build on GitHub, but I cann find anything useful, or maybe I'm doing a wrong search ..
Can you give me a more precise link to these Linux builds ?

[Ashok]

On 11/23/2023 5:21 AM, Aldo Buratti wrote:
> Can you give me a more precise link to these Linux builds ?

Can you try the ones at
https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/

I've verified windows and linux but do not have a mac to verify macos.

Not "official" beta rc's but very close.

These are single file executables, so no extensions etc.

Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)

/Ashok

[Harald Oehlmann]

Thank you, Ashok.

May I reference this page and your action on:

https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items

Take care,
Harald

[Aldo Buratti]

Thank you Ashok.
Just one question: is there a way to extract the stub-files "libtclstub.a" , "litbkstub.a" from these Linux single-executables ?
Alternatively, could you upload them on sourceforge ?

[Harald Oehlmann]

The exe is a zip file. Rename it to ".zip" and use your favorite tool to
explore...

Take care,
Harald

[et99]

Thanks so much Ashok, I got one of your wish90prebeta's for windows and it is working great for me on win10.

BTW, 7-zip.exe can directly read the .exe and found tcl_library and tk_library.

I was able to get BWidgets to load after fixing a few [Package require Tk 8.1.1] cases; changed it to 8.1.1- which allowed for the major version above 8.

However, I couldn't get BLT to load. It said it couldn't find Blt_Init, although I do see it in the BLT24.dll file. I'm guessing that 9 has changed something with C extensions.

I'm looking forward to a wonderful xmas present with the Thread extension in an upcoming release :)

Thanks again for the great work you do!

[Harald Oehlmann]

Hi ET!

I will fix BWidget soon, probably today with a new release.
You may get packages fixed for TCL 9 from Pauls work.
Klick on the package name in the table to download.

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

There is also a patched BWidget there I will just import, probobly..

Take care,
Harald

[Ashok]

On 11/23/2023 3:44 PM, Aldo Buratti wrote:
> Just one question: is there a way to extract the stub-files "libtclstub.a" , "litbkstub.a" from these Linux single-executables ?
> Alternatively, could you upload them on sourceforge ?

Hmm, the SFE's do not seem to contain the stub libraries and the github
artifacts (where the Linux builds came from) don't either. So also the
include directories.

Seems like something that needs to be enhanced as other extension
writers may also want to develop against the SFE version of Tcl. I'll
log a RFE ticket for this.

/Ashok