tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

[Andreas K. <and...@gm...>]

> TIP 705

VOTE:	YES

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

Op do 9 jan 2025 om 01:55 schreef Kevin Walzer <kw...@co...>:

> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>

My vote: YES

Regards,
     Jan Nijtmans

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

Am 09.01.2025 um 01:55 schrieb Kevin Walzer:
> Hi all,
> 
> Sorry this got away from me - the holidays and some other projects took
> priority.
> 
> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
> 
> My vote: YES.
My vote: Yes.

Thanks for all,
Harald

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

TIP #705: YES

Le 09/01/2025 à 01:55, Kevin Walzer a écrit :
> Hi all,
>
> Sorry this got away from me - the holidays and some other projects took
> priority.
>
> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>
> My vote: YES.
>
> Thanks,
>
> Kevin
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

TIP 705: Yes

- Marc

On Wed, Jan 8, 2025 at 6:55 PM Kevin Walzer <kw...@co...> wrote:

> Hi all,
>
> Sorry this got away from me - the holidays and some other projects took
> priority.
>
> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>
> My vote: YES.
>
> Thanks,
>
> Kevin
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

[Steve L. <st...@di...>]

TIP 705: YES
On 9 Jan 2025 at 8:56 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> Hi all,
>
> Sorry this got away from me - the holidays and some other projects took
> priority.
>
> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>
> My vote: YES.
>
> Thanks,
>
> Kevin

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

TIP 705: Yes

 

From: Kevin Walzer <kw...@co...> 
Sent: Thursday, January 9, 2025 6:25 AM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] CFV - TIP 705: Affirm Tcl License

 



Hi all,

Sorry this got away from me - the holidays and some other projects took 
priority.

This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.

My vote: YES.

Thanks,

Kevin

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

TIP 705

My vote: YES

-Brian Griffin

On Jan 8, 2025, at 16:55, Kevin Walzer <kw...@co...> wrote:


Hi all,

Sorry this got away from me - the holidays and some other projects took
priority.

This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.

My vote: YES.

Thanks,

Kevin

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

[TCLCORE] CFV - TIP 705: Affirm Tcl License

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/7L5MWjszRWDjt2mYYBjBlWWa7kWKMf0hwEXe-0EUK-b8PErfR1FahEEMtS9NPmVLCE7yqmDo6q-MLNv9N4fUgiD3emf_Scy0XDflL-0uNZiRflK5SD0aiWOnqqC-S9XwCI4AhQW-MO3lmVKchD0HWCfzqF43z-Y-9lTcHsPMi4n6mXsRoHGO5MO_KejXQNpVLCDvpdS3uNxrMpdVkbymuLrN4xD5' /></div>Hi all,<br/><br/>Sorry this got away from me - the holidays and some other projects took <br/>priority.<br/><br/>This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.<br/><br/>My vote: YES.<br/><br/>Thanks,<br/><br/>Kevin<br/><br/>

[TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

This is a CFV warning for TIP #699:
    MPL Licence for MemoryModule
    <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>

This is - most likely - the last TIP targeting 8.6 as well.
MemoryModule is already used in androwish (more precisely,
in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is
still based on 8.6.
The TIP implementation is based on 9.0, but
backporting to 8.7 and 8.6 is trivial. Since this is an
opt-in feature, default Tcl builds are not affected.

The vote process for TIP #705: "Affirm Tcl License" will
(most likely) start soon as well. This TIP can be
seen as an example how to request inclusion
of differently-licensed code in a repository supplied
by the Tcl consortium (anything ending with tcl-lang.org).
@Nathan Coulter <com...@po...> If you have any
spelling/wording
suggestions, please supply them now, not after
the voting finishes!

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans

[TCLCORE] Report of the Tk telco on 2025-01-07

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

Dear Tk team,

thanks for the 5 people showing up at the tk meeting.

Here are the results:

1) Tcl/Tk_InitStubs()

Jan gave insights:

The "Version" argument (like "8.5.6-9") gives the compatible Tcl or Tk 
API of the extension.
It does not say "I am compiled for 8.6".
A compiled 8.x dll will only work for 8.x and not with 9.x due to:
- different dll naming: the text "tcl9" is part of the dll name.
- different stubs magic numbers, which will avoid to load a 8.6 compiled 
dll to 9.0.

Note 1: Only the 32 bit magic is identical, as it is theoretically 
possible to build an extension loadable in 8.6 and 9.0. This is an 
expert case and not recommended. For example, a Tcl_Obj comming from an 
extension containing a TCL_UCHAR value with 16 bit will not be processed 
by TCL 9, where only 32 bits are supported.
Nevertheless, there are many functions for TCL_UCHAR, which exist in 
TCL9 for 16 and 32 bits.

Note 2: if the macro "TCL_VERSION" is used as version argument, an 8.6 
compiled dll will not load any more to 8.5, even if the api would be 
compatible. Due to that, this is not recommended.

The "strict" flag is not seen as useful. Its range changed (8.6 to 9.0) 
from 0/!=0 to 0/1 (e.g. -1 is not allowed in TCL9 as true value).
The reason is, that the version of the used tcl.h file is passed using 
the higher bits of this input field using a macro.
The first use is to improve the error message if the stubs magic does 
not match. Now, it gives the compiled version, which is incompatible to 
the interpreter version.

In Tcl9, the command Tcl_InitStubs takes 4 arguments. The 4th is 
provided by a macro and is the stubs magic number.
The reason for this is to use the same command, if the magic number may 
change for Tcl 10.
Currently, the magic for 8.x is hard coded and always known.
The magic for Tcl9 is contained in tcl.h and passed as 4th argument to 
Tcl_InitStubs.
If the magic changes for Tcl 10, only tcl.h must be changed and no code.

2) build-info in the sample extension

The build-info is currently given in the sample extension.
This is seen as a template and extension writers may typically copy this 
and modify it, e.g. remove unwanted features.
Only a very limited number of tags is standardized.
The rest is for the extension writer.

It is not seen as possible, that the build info may be included in tcl.h.
But it may be put in an extra source file of the sample extension. This 
avoids the destruction of the readability of the source file, as a lot 
of #ifdef are not seen as very readable.

3) revised text widget
The revised text widget extension is seen as great due to its high 
performance. It is now used for some month with high satisfaction

4) Proposed Tk changes:
- image transparency performance bug
- image rotation (TIP 705)
- image scaling with non-integer factors
- add image format list command, eventually with capabilities like writing
- remove indexed display support, as nowadays, we always have 24 bit 
non-indexed displays
- make image command usable without tk

5) Licences
TIP 705 is ready for a vote. Kevin Waltzer may advance it.
This is seen as crucial.

6) further meetings

Jan is not available for the next bi-weekly TCL meeting on the 20th of 
January, as he has a conflicting bi-weekly meeting.
It was decided to have another meeting the 27th of January 2025.

Here is the overview:
2025-01-20 12:00 UTC: TCL meeting -> roadmap discussion with Don
2025-01-27 12:00 UTC: TCL meeting with Jan
2025-02-04 18:00 UTC Tk monthly meeting

Thank you all,
Harald

Re: [TCLCORE] About TCL_STUB_MAGIC values

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

Jan,

 

Thanks for the clarification.

 

Not directly related, but I’m completely mystified by your statement “extensions built for Tcl 8.6 (Using Tcl_InitStubs(interp, "8.6-")...) will run fine on Tcl 9.0, even without re-compilation” but that’s probably best deferred to the next online meet.

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Tuesday, January 7, 2025 5:37 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] About TCL_STUB_MAGIC values

 

Op di 7 jan 2025 om 12:40 schreef Ashok:

In response to a question on the chat, I’m a bit confused by the TCL_STUB_MAGIC values in tcl.h. The comment there states the value distinguishes older (pre-9) version of Tcl. However, it seems to me for 32-bit versions the values are the same for both Tcl 8 and 9 (0x..CB+sizeof(void*) ==0x..CF. 

 

So, which of the following is true?

 

* My math is horribly wrong; always a possibility

Not true. 

* The comment is wrong

True, but .... better not change it (see below).

* There is a bug in the defined values

Not true 

 

On platforms where sizeof(int) == sizeof(long) == sizeof(ptrdiff_t),

changing int -> Tcl_Size doesn't actually change anything. On such

platforms, extensions built for Tcl 8.6 (Using Tcl_InitStubs(interp, "8.6-")

...) will run fine on Tcl 9.0, even without re-compilation, unless .... a

deprecated function is used. For most common extensions

(like tdbc::*, Itcl, sqlite3) it just works fine.

 

I think this is a useful 'undocumented feature'. Because of the (unlikely)

'unless' above, and because such platforms are dying anyway, not

something we should promote. But for people who know what

they are doing, why not!

 

Hope this helps,

       Jan Nijtmans

 

Re: [TCLCORE] About TCL_STUB_MAGIC values

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

Op di 7 jan 2025 om 12:40 schreef Ashok:

> In response to a question on the chat, I’m a bit confused by the
> TCL_STUB_MAGIC values in tcl.h. The comment there states the value
> distinguishes older (pre-9) version of Tcl. However, it seems to me for
> 32-bit versions the values are the same for both Tcl 8 and 9
> (0x..CB+sizeof(void*) ==0x..CF.
>
>
>
> So, which of the following is true?
>
>
>
>    - My math is horribly wrong; always a possibility
>
> Not true.

>
>    - The comment is wrong
>
> True, but .... better not change it (see below).

>
>    - There is a bug in the defined values
>
> Not true

On platforms where sizeof(int) == sizeof(long) == sizeof(ptrdiff_t),
changing int -> Tcl_Size doesn't actually change anything. On such
platforms, extensions built for Tcl 8.6 (Using Tcl_InitStubs(interp, "8.6-")
...) will run fine on Tcl 9.0, even without re-compilation, unless .... a
deprecated function is used. For most common extensions
(like tdbc::*, Itcl, sqlite3) it just works fine.

I think this is a useful 'undocumented feature'. Because of the (unlikely)
'unless' above, and because such platforms are dying anyway, not
something we should promote. But for people who know what
they are doing, why not!

Hope this helps,
       Jan Nijtmans

[TCLCORE] About TCL_STUB_MAGIC values

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

In response to a question on the chat, I'm a bit confused by the
TCL_STUB_MAGIC values in tcl.h. The comment there states the value
distinguishes older (pre-9) version of Tcl. However, it seems to me for
32-bit versions the values are the same for both Tcl 8 and 9
(0x..CB+sizeof(void*) ==0x..CF. 

 

So, which of the following is true?

 

*	My math is horribly wrong; always a possibility
*	The comment is wrong
*	There is a bug in the defined values

 

(The original issue being looked at was the report of Nim language bindings
not being able to load Tcl.

Re: [TCLCORE] Backporting to Tk core-8-6-branch

[elns <el...@xs...>]

Hi Francois and Steve,

What Francois writes, also expresses my personal view.

Therefore I'm going to target Tk 9 and not bother with older branches.

Thanks for your responses,
Erik.
--


On 1/6/25 15:33, Steve Landers wrote:
> I fully support your opinion Francois
> 
> -- Steve
> On 6 Jan 2025 at 10:24 PM +0800, François Vogel <fvo...@fr...>, wrote:
>> Hi all,
>>
>> I wouldn't bother backporting your work to maintenance branches such as core-8-6-branch. I simply 
>> do not see the need. Your work aims at facilitating maintenance of Tk in the long term, let's 
>> concentrate on trunk (Tk 9).
>>
>> Others may have different opinions?
>>
>> Regards,
>> François
>>
>> -------- Message d'origine --------
>> De : elns <el...@xs...>
>> Date : 06/01/2025 15:01 (GMT+01:00)
>> À : tcl...@li...
>> Objet : [TCLCORE] Backporting to Tk core-8-6-branch
>>
>> On 11/25/24 10:03, Steve Landers wrote:
>> >
>> > I would encourage you to work in a branch off the trunk/main (i.e. in Tk9) and take care to remain
>> > cross-platform. If need be your work can be back-ported later.
>>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Is it possible to decide on any back-porting already now?
>>
>> Reason:
>>
>> While working in branch tk_collect_test_utils, I came across this proc in file winDialog.test:
>>
>> proc vista? {{prevista 0} {postvista 1}} {
>>     lassign [split $::tcl_platform(osVersion) .] major
>>     return [expr {$major >= 6 ? $postvista : $prevista}]
>> }
>>
>> Since TIP #592, support for Vista and older has been discontinued. Therefore, this proc will always
>> return its second argument or its default 1, except for the core-8-6-branch, which still supports
>> windows versions older than Vista.
>>
>> If we know already now that back-porting my work in branch tk_collect_test_utils to core-8-6-branch
>> is not going to happen, I could simplify the code for Tk tests significantly. It would also mean
>> that we can't back-port the work to branch 8.6 anymore.
>>
>> If back-porting to 8.6 is preferred, or if we can't decide already now, then I'll leave this code in
>> place.
>>
>> Thanks in advance for your views on this matter,
>> Erik.
>> --
>>
>>
>>  Other than that, I’ll defer to
>> > Francois on the details of the test suite changes themselves.
>> >
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

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

Vadim,

 

If you have not done so already, perusing the Tcl 9 porting guide at https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9 <https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9&p> &p might be helpful.

 

/Ashok

 

From: Vadim V Konovalov <vad...@ga...> 
Sent: Tuesday, January 7, 2025 1:43 AM
To: Vadim V Konovalov <vad...@ga...>; 'apn...@ya...' <apn...@ya...>; 'Jan Nijtmans' <jan...@gm...>
Cc: 'Tcl Core List' <tcl...@li...>
Subject: RE: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

All in all, everything is now ok with perl Tcl module, I’ve released an update supporting Tcl9

 

However after the 

#include <tcl.h>

 

I needed to add the lines

#if TCL_MAJOR_VERSION < 9

    typedef int Tcl_Size;

#endif /* TCL_MAJOR_VERSION */

 

otherwise I get compilation error in my Cygwin tcl, which happens to be 8.6.12.

 

Is this normal, or there better approach?

 

Thanks in advance,

Vadim

 

From: Vadim V Konovalov via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > 
Sent: Monday, January 6, 2025 8:08 PM
To: 'apn...@ya...' <apn...@ya... <mailto:apn...@ya...> >; 'Jan Nijtmans' <jan...@gm... <mailto:jan...@gm...> >
Cc: 'Tcl Core List' <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Makes sense

Thanks!

 

From: apn...@ya... <mailto:apn...@ya...>  <apn...@ya... <mailto:apn...@ya...> > On Behalf Of apn...@ya... <mailto:apn...@ya...> 
Sent: Monday, January 6, 2025 5:50 AM
To: Коновалов Вадим Владимирович <vad...@ga... <mailto:vad...@ga...> >; 'Jan Nijtmans' <jan...@gm... <mailto:jan...@gm...> >
Cc: 'Tcl Core List' <tcl...@li... <mailto:tcl...@li...> >
Subject: RE: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Adding to what Brian said, your int declaration in lieu of Tcl_Size likely result in objv being smashed by being overwritten by the len output from Tcl_GetStringFromObj.

 

With regards to your ListRepElements reference, it is not returning a pointer to local storage on the stack. The internal list rep copy on the stack holds a *pointer* to ckalloc’ed storage and that pointer to heap storage is what is being returned.

 

/Ashok

 

From: Vadim V Konovalov via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > 
Sent: Monday, January 6, 2025 1:28 AM
To: 'Jan Nijtmans' <jan...@gm... <mailto:jan...@gm...> >
Cc: Tcl Core List <tcl...@li... <mailto:tcl...@li...> >; Ashok Nadkarni <apn...@ya... <mailto:apn...@ya...> >
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Will that change fix the segmentation fault?

 

 

From: Jan Nijtmans <jan...@gm... <mailto:jan...@gm...> > 
Sent: Sunday, January 5, 2025 9:53 PM
To: Коновалов Вадим Владимирович <vad...@ga... <mailto:vad...@ga...> >
Cc: Ashok Nadkarni <apn...@ya... <mailto:apn...@ya...> >; Kevin Walzer <kw...@co... <mailto:kw...@co...> >; Marc Culler <cul...@gm... <mailto:cul...@gm...> >; Tcl Core List <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Op zo 5 jan 2025 om 18:44 schreef Vadim V Konovalov via:

Here is small program to reproduce:

...                                                                                                                                       

    int objc, len;                                                                                                                                                                      

 

In Tcl 9, this line should be:

          Tcl_Size objc, len;

Also, for printing pointers, please use "%p" instead of "%016X". The

compiler should give a warning for this!

 

I don't think this is the cause of your error, but better rule

this out first.

 

Regards,

      Jan Nijtmans

 

 

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

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

Op ma 6 jan 2025 om 21:13 schreef Vadim V Konovalov <
vad...@ga...>:

> All in all, everything is now ok with perl Tcl module, I’ve released an
> update supporting Tcl9
>
>
>
> However after the
>
> #include <tcl.h>
>
>
>
> I needed to add the lines
>
> #if TCL_MAJOR_VERSION < 9
>
>     typedef int Tcl_Size;
>
> #endif /* TCL_MAJOR_VERSION */
>
>
>
> otherwise I get compilation error in my Cygwin tcl, which happens to be
> 8.6.12.
>
>
>
> Is this normal, or there better approach?
>

That is normal.

Hope this helps,
  Jan Nijtmans

[TCLCORE] Tk meeting on 2025-01-07 18:00 UTC to 19:00 UTC

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

Dear Tk group,

a happy new year to you all !

The next monthly Tk meeting is planned in around 20 hours:
7th of January 2025 at 18:00 UTC (1 hour)

Don will probably not be present

I am not aware of any hot topics.
I see Kevin working on the extended input - great !
And Eric on the test unification.
Also, Francois long-lasting work on less test constraints was merged.
So, the agenda is mostly open discussion.

Nevertheless, here are some possible points:
- Markdown documentation status (Torsten)
- Next development release plan
- Tk_InitStubs

Below are IMHO some relevant remarks from the last TCL telco on 2024-12-23.

Remark, that the German speaking meeting will directly follow.

This telco is open for everyone, not only core team members.

See you in 20 hours,
Harald

---

1) Version field of Tcl_InitStubs(i,"8.6-9",0)
The migration hints recommend: "Tcl_InitStubs(i,"8.6-9",0)".
The proposal is to better use: "Tcl_InitStubs(i,TCL_VERSION,0)".
If a library is compiled for 9, it will probably crash, when loaded into 
8.6 due to missing stubs entries.
There was work by Jan (not present in the call) to make a library work 
for 8.7 and 9, so "Tcl_InitStubs(i,"8.7-9",0)" might be senseful. 
Currently, 8.7 is not planned for release and a library author may 
require a lot of background information, what 9 feature is emulated in 8.7.
So, the TCL_VERSION argument is seen as mostly appropriate.

In addition, the macro magic in Tcl 9 about Tcl_InitStubs is seen as 
critical:
- the parameter "exact" is abused to encode TCL_VERSION
- there is a 4th magic parameter not exposed
It would be preferable, to have a new call:
Tcl_InitStubsEx(i,v,e,TCL_VERSION,MAGIC_PARAMETER)
instead of the macro magic.
In addition, a macro magic is added to Tcl_InitStubs, which replaces 
Tcl_InitStubs by something like Tcl_PackagePresent("TCL",Version), if 
USE_TCL_STUBS is not defined. That is great, but not tipped and not 
understandable for the user, as the command name is not correct.
So, also this may be included in a new command with a different name.

Don pointed to his historic ticket, probably outdated now:
https://core.tcl-lang.org/tcl/tktview/3588687fffffffffffff

2) Further releases
There was a brainstorming discussion how to proceed.
In the next meeting, a plan should be done and be published about 
tentative release dates for the next versions.
The loose idea is to have two release waves per year.
The dates to define:
- 9.1a0 release
- 9.1b0 release
- 9.1.0 release
- 9.0.x maintenance period
- 8.6.x maintenance period

3) Next telcos
7th of January 2025: Tk meeting at 18:00 UTC (Don probably not present)
20th of January 2025: biweekly TCL/Tk at 12:00 UTC

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

[Vadim V K. <vad...@ga...>]

All in all, everything is now ok with perl Tcl module, I’ve released an update supporting Tcl9

However after the
#include <tcl.h>

I needed to add the lines
#if TCL_MAJOR_VERSION < 9
    typedef int Tcl_Size;
#endif /* TCL_MAJOR_VERSION */

otherwise I get compilation error in my Cygwin tcl, which happens to be 8.6.12.

Is this normal, or there better approach?

Thanks in advance,
Vadim

From: Vadim V Konovalov via Tcl-Core <tcl...@li...>
Sent: Monday, January 6, 2025 8:08 PM
To: 'apn...@ya...' <apn...@ya...>; 'Jan Nijtmans' <jan...@gm...>
Cc: 'Tcl Core List' <tcl...@li...>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Makes sense
Thanks!

From: apn...@ya...<mailto:apn...@ya...> <apn...@ya...<mailto:apn...@ya...>> On Behalf Of apn...@ya...<mailto:apn...@ya...>
Sent: Monday, January 6, 2025 5:50 AM
To: Коновалов Вадим Владимирович <vad...@ga...<mailto:vad...@ga...>>; 'Jan Nijtmans' <jan...@gm...<mailto:jan...@gm...>>
Cc: 'Tcl Core List' <tcl...@li...<mailto:tcl...@li...>>
Subject: RE: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Adding to what Brian said, your int declaration in lieu of Tcl_Size likely result in objv being smashed by being overwritten by the len output from Tcl_GetStringFromObj.

With regards to your ListRepElements reference, it is not returning a pointer to local storage on the stack. The internal list rep copy on the stack holds a *pointer* to ckalloc’ed storage and that pointer to heap storage is what is being returned.

/Ashok

From: Vadim V Konovalov via Tcl-Core <tcl...@li...<mailto:tcl...@li...>>
Sent: Monday, January 6, 2025 1:28 AM
To: 'Jan Nijtmans' <jan...@gm...<mailto:jan...@gm...>>
Cc: Tcl Core List <tcl...@li...<mailto:tcl...@li...>>; Ashok Nadkarni <apn...@ya...<mailto:apn...@ya...>>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Will that change fix the segmentation fault?


From: Jan Nijtmans <jan...@gm...<mailto:jan...@gm...>>
Sent: Sunday, January 5, 2025 9:53 PM
To: Коновалов Вадим Владимирович <vad...@ga...<mailto:vad...@ga...>>
Cc: Ashok Nadkarni <apn...@ya...<mailto:apn...@ya...>>; Kevin Walzer <kw...@co...<mailto:kw...@co...>>; Marc Culler <cul...@gm...<mailto:cul...@gm...>>; Tcl Core List <tcl...@li...<mailto:tcl...@li...>>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Op zo 5 jan 2025 om 18:44 schreef Vadim V Konovalov via:
Here is small program to reproduce:
...
    int objc, len;

In Tcl 9, this line should be:
          Tcl_Size objc, len;
Also, for printing pointers, please use "%p" instead of "%016X". The
compiler should give a warning for this!

I don't think this is the cause of your error, but better rule
this out first.

Regards,
      Jan Nijtmans

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

[Vadim V K. <vad...@ga...>]

Makes sense
Thanks!

From: apn...@ya... <apn...@ya...> On Behalf Of apn...@ya...
Sent: Monday, January 6, 2025 5:50 AM
To: Коновалов Вадим Владимирович <vad...@ga...>; 'Jan Nijtmans' <jan...@gm...>
Cc: 'Tcl Core List' <tcl...@li...>
Subject: RE: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Adding to what Brian said, your int declaration in lieu of Tcl_Size likely result in objv being smashed by being overwritten by the len output from Tcl_GetStringFromObj.

With regards to your ListRepElements reference, it is not returning a pointer to local storage on the stack. The internal list rep copy on the stack holds a *pointer* to ckalloc’ed storage and that pointer to heap storage is what is being returned.

/Ashok

From: Vadim V Konovalov via Tcl-Core <tcl...@li...<mailto:tcl...@li...>>
Sent: Monday, January 6, 2025 1:28 AM
To: 'Jan Nijtmans' <jan...@gm...<mailto:jan...@gm...>>
Cc: Tcl Core List <tcl...@li...<mailto:tcl...@li...>>; Ashok Nadkarni <apn...@ya...<mailto:apn...@ya...>>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Will that change fix the segmentation fault?


From: Jan Nijtmans <jan...@gm...<mailto:jan...@gm...>>
Sent: Sunday, January 5, 2025 9:53 PM
To: Коновалов Вадим Владимирович <vad...@ga...<mailto:vad...@ga...>>
Cc: Ashok Nadkarni <apn...@ya...<mailto:apn...@ya...>>; Kevin Walzer <kw...@co...<mailto:kw...@co...>>; Marc Culler <cul...@gm...<mailto:cul...@gm...>>; Tcl Core List <tcl...@li...<mailto:tcl...@li...>>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

Op zo 5 jan 2025 om 18:44 schreef Vadim V Konovalov via:
Here is small program to reproduce:
...
    int objc, len;

In Tcl 9, this line should be:
          Tcl_Size objc, len;
Also, for printing pointers, please use "%p" instead of "%016X". The
compiler should give a warning for this!

I don't think this is the cause of your error, but better rule
this out first.

Regards,
      Jan Nijtmans

Re: [TCLCORE] Backporting to Tk core-8-6-branch

[Steve L. <st...@di...>]

I fully support your opinion Francois

-- Steve
On 6 Jan 2025 at 10:24 PM +0800, François Vogel <fvo...@fr...>, wrote:
> Hi all,
>
> I wouldn't bother backporting your work to maintenance branches such as core-8-6-branch. I simply do not see the need. Your work aims at facilitating maintenance of Tk in the long term, let's concentrate on trunk (Tk 9).
>
> Others may have different opinions?
>
> Regards,
> François
>
> -------- Message d'origine --------
> De : elns <el...@xs...>
> Date : 06/01/2025 15:01 (GMT+01:00)
> À : tcl...@li...
> Objet : [TCLCORE] Backporting to Tk core-8-6-branch
>
> On 11/25/24 10:03, Steve Landers wrote:
> >
> > I would encourage you to work in a branch off the trunk/main (i.e. in Tk9) and take care to remain
> > cross-platform. If need be your work can be back-ported later.
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Is it possible to decide on any back-porting already now?
>
> Reason:
>
> While working in branch tk_collect_test_utils, I came across this proc in file winDialog.test:
>
> proc vista? {{prevista 0} {postvista 1}} {
>     lassign [split $::tcl_platform(osVersion) .] major
>     return [expr {$major >= 6 ? $postvista : $prevista}]
> }
>
> Since TIP #592, support for Vista and older has been discontinued. Therefore, this proc will always
> return its second argument or its default 1, except for the core-8-6-branch, which still supports
> windows versions older than Vista.
>
> If we know already now that back-porting my work in branch tk_collect_test_utils to core-8-6-branch
> is not going to happen, I could simplify the code for Tk tests significantly. It would also mean
> that we can't back-port the work to branch 8.6 anymore.
>
> If back-porting to 8.6 is preferred, or if we can't decide already now, then I'll leave this code in
> place.
>
> Thanks in advance for your views on this matter,
> Erik.
> --
>
>
>  Other than that, I’ll defer to
> > Francois on the details of the test suite changes themselves.
> >
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Backporting to Tk core-8-6-branch

[François V. <fvo...@fr...>]

Hi all,I wouldn't bother backporting your work to maintenance branches such as core-8-6-branch. I simply do not see the need. Your work aims at facilitating maintenance of Tk in the long term, let's concentrate on trunk (Tk 9).Others may have different opinions?Regards,François 
-------- Message d'origine --------De : elns <el...@xs...> Date : 06/01/2025  15:01  (GMT+01:00) À : tcl...@li... Objet : [TCLCORE] Backporting to Tk core-8-6-branch On 11/25/24 10:03, Steve Landers wrote:> > I would encourage you to work in a branch off the trunk/main (i.e. in Tk9) and take care to remain > cross-platform. If need be your work can be back-ported later.                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Is it possible to decide on any back-porting already now?Reason:While working in branch tk_collect_test_utils, I came across this proc in file winDialog.test:	proc vista? {{prevista 0} {postvista 1}} {	    lassign [split $::tcl_platform(osVersion) .] major	    return [expr {$major >= 6 ? $postvista : $prevista}]	}Since TIP #592, support for Vista and older has been discontinued. Therefore, this proc will always return its second argument or its default 1, except for the core-8-6-branch, which still supports windows versions older than Vista.If we know already now that back-porting my work in branch tk_collect_test_utils to core-8-6-branch is not going to happen, I could simplify the code for Tk tests significantly. It would also mean that we can't back-port the work to branch 8.6 anymore.If back-porting to 8.6 is preferred, or if we can't decide already now, then I'll leave this code in place.Thanks in advance for your views on this matter,Erik.--  Other than that, I’ll defer to> Francois on the details of the test suite changes themselves.> _______________________________________________Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Backporting to Tk core-8-6-branch

[elns <el...@xs...>]

On 11/25/24 10:03, Steve Landers wrote:
> 
> I would encourage you to work in a branch off the trunk/main (i.e. in Tk9) and take care to remain 
> cross-platform. If need be your work can be back-ported later. 
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is it possible to decide on any back-porting already now?

Reason:

While working in branch tk_collect_test_utils, I came across this proc in file winDialog.test:

	proc vista? {{prevista 0} {postvista 1}} {
	    lassign [split $::tcl_platform(osVersion) .] major
	    return [expr {$major >= 6 ? $postvista : $prevista}]
	}

Since TIP #592, support for Vista and older has been discontinued. Therefore, this proc will always 
return its second argument or its default 1, except for the core-8-6-branch, which still supports 
windows versions older than Vista.

If we know already now that back-porting my work in branch tk_collect_test_utils to core-8-6-branch 
is not going to happen, I could simplify the code for Tk tests significantly. It would also mean 
that we can't back-port the work to branch 8.6 anymore.

If back-porting to 8.6 is preferred, or if we can't decide already now, then I'll leave this code in 
place.

Thanks in advance for your views on this matter,
Erik.
--


  Other than that, I’ll defer to
> Francois on the details of the test suite changes themselves.
> 

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

[Vadim V K. <vad...@ga...>]

Indeed
Thanks a lot!

I was ignoring the warning because I got used to the fact that 'lont int' and 'int' are mostly the same, but obviously I was wrong :)

vad@orangepi3b:~/perl-dev/tcl.pm$ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Tcl.bs blib/arch/auto/Tcl/Tcl.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/call.t ............. Failed 7/15 subtests 
t/constants.t ........ ok   
t/createcmd.t ........ ok   
t/disposal-subs-a.t .. skipped: because: not installed use Devel::Refcount qw( refcount )
t/disposal-subs-b.t .. ok   
t/disposal-subs-c.t .. ok   
t/disposal-subs-d.t .. ok   
t/disposal-subs-e.t .. ok   
t/disposal-subs-f.t .. ok   
t/disposal-subs.t .... 1/2 [[::perl::Eval ::perl::CODE(0xaaab07005c80); ]]
t/disposal-subs.t .... ok   
t/eval.t ............. ok   
t/export_to_tcl.t .... ok   
t/info.t ............. ok   
t/memleak-a.t ........ skipped: because: not installed use Devel::Refcount qw( refcount )
t/result.t ........... Failed 4/7 subtests 
t/set-callback.t ..... ok   
t/subclass.t ......... ok   
t/svfromtclobj.t ..... ok   
t/trace.t ............ ok   
t/unicode.t .......... ok   
t/var.t .............. ok   
t/var2.t ............. ok   
 
Test Summary Report
-------------------
t/call.t           (Wstat: 11 (Signal: SEGV) Tests: 8 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 15 tests but ran 8.
t/info.t           (Wstat: 0 Tests: 6 Failed: 0)
  TODO passed:   2
t/result.t         (Wstat: 11 (Signal: SEGV) Tests: 3 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 7 tests but ran 3.
Files=22, Tests=100, 18 wallclock secs ( 0.33 usr  0.14 sys +  6.17 cusr  0.78 csys =  7.42 CPU)
Result: FAIL
Failed 2/22 test programs. 0/100 subtests failed.
make: *** [Makefile:1028: test_dynamic] Error 255
Press any key to continue...

Mostly everything is working, so I'll update the perl module soon.

Best rehards,
Vadim

-----Original Message-----
From: Brian Griffin <bri...@ea...> 
Sent: Monday, January 6, 2025 1:15 AM
To: Коновалов Вадим Владимирович <vad...@ga...>
Cc: Jan Nijtmans <jan...@gm...>; Tcl Core List <tcl...@li...>; Ashok Nadkarni <apn...@ya...>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

It certainly solves to seg fault for me when I try it. It also eliminates all the compilation warnings.

Without the changes, I'm seeing these warnings:

get_elements_bug.c:15:44: warning: incompatible pointer types passing 'int *' to parameter of type 'Tcl_Size *' (aka 'long *') [-Wincompatible-pointer-types]
   15 |   char *str = Tcl_GetStringFromObj(objPtr, &len);
      |                                            ^~~~
/Users/briang42/tcl_core/usr_mac_special/include/tclDecls.h:1754:15: note: passing argument to parameter 'lengthPtr' here
 1754 |                                 Tcl_Size *lengthPtr);
      |                                           ^
get_elements_bug.c:19:46: warning: incompatible pointer types passing 'int *' to parameter of type 'Tcl_Size *' (aka 'long *') [-Wincompatible-pointer-types]
   19 |   if (Tcl_ListObjGetElements(interp, objPtr, &objc, &objv) != TCL_OK) {
      |                                              ^~~~~
/Users/briang42/tcl_core/usr_mac_special/include/tclDecls.h:1787:33: note: passing argument to parameter 'objcPtr' here
 1787 |                                 Tcl_Obj *listPtr, Tcl_Size *objcPtr,
      |                                                             ^
get_elements_bug.c:24:39: warning: format specifies type 'unsigned int' but the argument has type 'Tcl_Obj **' (aka 'struct Tcl_Obj **') [-Wformat]
   24 |   printf("objc=%d, objv=%016X\n",objc,objv);
      |                         ~~~~~         ^~~~
get_elements_bug.c:25:28: warning: format specifies type 'unsigned int' but the argument has type 'Tcl_Obj *' (aka 'struct Tcl_Obj *') [-Wformat]
   25 |   printf("objv[0]=%016X\n",objv[0]);
      |                   ~~~~~    ^~~~~~~
4 warnings generated.

With the corrections I get this result:

got string result 'fefe'
objc=1, objv=0x1308a0b78
objv[0]=0x120039020
objv[0] = 'fefe'
all done

Note: I extended the test case to go further.

YMMV.

-Brian

> On Jan 5, 2025, at 11:57, Vadim V Konovalov via Tcl-Core <tcl...@li...> wrote:
> 
> Will that change fix the segmentation fault?
>   From: Jan Nijtmans <jan...@gm...>
> Sent: Sunday, January 5, 2025 9:53 PM
> To: Коновалов Вадим Владимирович <vad...@ga...>
> Cc: Ashok Nadkarni <apn...@ya...>; Kevin Walzer 
> <kw...@co...>; Marc Culler <cul...@gm...>; Tcl Core List 
> <tcl...@li...>
> Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module  
> Op zo 5 jan 2025 om 18:44 schreef Vadim V Konovalov via:
> Here is small program to reproduce:
> ...                                                                                                                                           int objc,len;                                                                                                                                                                       In Tcl 9, this line should be:
>           Tcl_Size objc, len;
> Also, for printing pointers, please use "%p" instead of "%016X". The 
> compiler should give a warning for this!
>  I don't think this is the cause of your error, but better rule this 
> out first.
>  Regards,
>       Jan Nijtmans
>   _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

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

Adding to what Brian said, your int declaration in lieu of Tcl_Size likely result in objv being smashed by being overwritten by the len output from Tcl_GetStringFromObj.

 

With regards to your ListRepElements reference, it is not returning a pointer to local storage on the stack. The internal list rep copy on the stack holds a *pointer* to ckalloc’ed storage and that pointer to heap storage is what is being returned.

 

/Ashok

 

From: Vadim V Konovalov via Tcl-Core <tcl...@li...> 
Sent: Monday, January 6, 2025 1:28 AM
To: 'Jan Nijtmans' <jan...@gm...>
Cc: Tcl Core List <tcl...@li...>; Ashok Nadkarni <apn...@ya...>
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Will that change fix the segmentation fault?

 

 

From: Jan Nijtmans <jan...@gm... <mailto:jan...@gm...> > 
Sent: Sunday, January 5, 2025 9:53 PM
To: Коновалов Вадим Владимирович <vad...@ga... <mailto:vad...@ga...> >
Cc: Ashok Nadkarni <apn...@ya... <mailto:apn...@ya...> >; Kevin Walzer <kw...@co... <mailto:kw...@co...> >; Marc Culler <cul...@gm... <mailto:cul...@gm...> >; Tcl Core List <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] problems with Tcl/Tk 9.0 in the Perl Tcl module

 

Op zo 5 jan 2025 om 18:44 schreef Vadim V Konovalov via:

Here is small program to reproduce:

...                                                                                                                                       

    int objc, len;                                                                                                                                                                      

 

In Tcl 9, this line should be:

          Tcl_Size objc, len;

Also, for printing pointers, please use "%p" instead of "%016X". The

compiler should give a warning for this!

 

I don't think this is the cause of your error, but better rule

this out first.

 

Regards,

      Jan Nijtmans