tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TCL manual pages - how are they reviewed ?

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

I think this is not the only page with this problem. If memory serves,
Torsten had highlighted this issue as something to be addressed as part of
TIP 700 work (or thereafter).

 

/Ashok

 

From: Karl Koehler via Tcl-Core <tcl...@li...> 
Sent: Friday, February 7, 2025 12:15 AM
To: tcl...@li...
Subject: [TCLCORE] TCL manual pages - how are they reviewed ?

 

Hi,

 

I was looking up something for TCL 9.0, I am experiencing differences in the
'clock' command between TCL 9.0 and TCL 8.6 and was wondering if that's just
me ?

So I went to the authoritative website:

https://www.tcl-lang.org/man/tcl9.0/TclCmd/clock.html

Note ! The URL specifies this is for TCL 9.0 !

But in the text:

 

SYNOPSIS

package require Tcl 8.5-

clock add timeVal ?count unit...? ?-option value?

 

This indicates that the documentation has not been reviewed since TCL 8.5 .

Is this even the right list for this kind of gripes  ( I didn't seem to see
anything that fits better ) ?

 

Thanks,

-          Karl

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

>From: Jan Nijtmans <jan...@gm...> 
>Indeed!   Implementation is fixed now, and some testcases added. Thanks!
 
Thanks. I didn't see a test case for "     " though it appears to work fine. Might be a good idea to add that as it was the original failure mode.

>I now changed the implementation such that the function panic's when objPtr = NULL.

+1

>Any more remarks?

Any comments on the suggestion to implement Tcl_IsEmpty via a "isEmpty" method to Tcl_ObjType? The motive is the same as in the TIP - avoid string generation - except it would help types defined in extensions and not just Tcl core types. For example, my tarray extension is intended to internally store large structures (not necessarily lists). It would be nice if comparisons to "" did not generate a string of a few megabytes. Any views on that? (Not that this is a knock against the TIP as it stands)

/Ashok

Re: [TCLCORE] Three small tools for Tcl extension writers

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

Harald,

Rather than cloning the repository, you are better off downloading the release archive.

Cloning the repository and using that as your extension repository will make your extension repository a fork of the template repository which is probably not what you want.

/Ashok 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Friday, February 7, 2025 11:02 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Three small tools for Tcl extension writers

Great work, Ashok.
Sounds like a time warp in future.

May I
- clone the repository and create the (new) sample extension from it?

Thanks again,
Harald


Am 07.02.2025 um 18:19 schrieb apnmbx-public--- via Tcl-Core:
> Announcing some potentially useful tools for extension writers.
> 
> *tcl-extension-template*
> 
> Generate a skeleton of a Tcl extension, including directory structure, 
> autoconf and nmake based files, init function and header, build-config 
> command, and Github action workflows.
> 
> Docs: https://github.com/apnadkarni/tcl-extension-template/blob/main/ 
> README.md <https://github.com/apnadkarni/tcl-extension-template/blob/ 
> main/README.md>
> 
> Download: https://github.com/apnadkarni/tcl-extension-template/releases 
> <https://github.com/apnadkarni/tcl-extension-template/releases>
> 
> The workflows in the above template can be used independently as well 
> and make use of the following Github actions which may also be used 
> independently.
> 
> *tcl-setup*
> 
> Github action to set up a TEA environment for building against a 
> specific Tcl release or commit tag.
> 
> Docs: https://github.com/apnadkarni/tcl-setup/blob/main/README.md 
> <https://github.com/apnadkarni/tcl-setup/blob/main/README.md>
> 
> *tcl-build-extension*
> 
> Github action to build a Tcl extension.
> 
> Docs: https://github.com/apnadkarni/tcl-build-extension/blob/main/ 
> README.md <https://github.com/apnadkarni/tcl-build-extension/blob/main/ 
> README.md>
> 
> /Ashok

[TCLCORE] *[cC]lientData*

[B H. <bra...@gm...>]

Can anybody explain why the "extra" clientData fields for any command seem to be filled w the Tcl_Command address rather than being NULL?

ref: https://core.tcl-lang.org/tcl/file?name=generic/tclBasic.c&ci=tip&ln=2949

cheers,
-bch

Re: [TCLCORE] Three small tools for Tcl extension writers

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

Great work, Ashok.
Sounds like a time warp in future.

May I
- clone the repository and create the (new) sample extension from it?

Thanks again,
Harald


Am 07.02.2025 um 18:19 schrieb apnmbx-public--- via Tcl-Core:
> Announcing some potentially useful tools for extension writers.
> 
> *tcl-extension-template*
> 
> Generate a skeleton of a Tcl extension, including directory structure, 
> autoconf and nmake based files, init function and header, build-config 
> command, and Github action workflows.
> 
> Docs: https://github.com/apnadkarni/tcl-extension-template/blob/main/ 
> README.md <https://github.com/apnadkarni/tcl-extension-template/blob/ 
> main/README.md>
> 
> Download: https://github.com/apnadkarni/tcl-extension-template/releases 
> <https://github.com/apnadkarni/tcl-extension-template/releases>
> 
> The workflows in the above template can be used independently as well 
> and make use of the following Github actions which may also be used 
> independently.
> 
> *tcl-setup*
> 
> Github action to set up a TEA environment for building against a 
> specific Tcl release or commit tag.
> 
> Docs: https://github.com/apnadkarni/tcl-setup/blob/main/README.md 
> <https://github.com/apnadkarni/tcl-setup/blob/main/README.md>
> 
> *tcl-build-extension*
> 
> Github action to build a Tcl extension.
> 
> Docs: https://github.com/apnadkarni/tcl-build-extension/blob/main/ 
> README.md <https://github.com/apnadkarni/tcl-build-extension/blob/main/ 
> README.md>
> 
> /Ashok

[TCLCORE] Three small tools for Tcl extension writers

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

Announcing some potentially useful tools for extension writers.

 

tcl-extension-template

 

Generate a skeleton of a Tcl extension, including directory structure,
autoconf and nmake based files, init function and header, build-config
command, and Github action workflows.

 

Docs:
https://github.com/apnadkarni/tcl-extension-template/blob/main/README.md

Download: https://github.com/apnadkarni/tcl-extension-template/releases

 

The workflows in the above template can be used independently as well and
make use of the following Github actions which may also be used
independently.

 

tcl-setup

 

Github action to set up a TEA environment for building against a specific
Tcl release or commit tag.

Docs: https://github.com/apnadkarni/tcl-setup/blob/main/README.md

 

tcl-build-extension

 

Github action to build a Tcl extension.

Docs: https://github.com/apnadkarni/tcl-build-extension/blob/main/README.md

 

/Ashok

 

 

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

Op do 6 feb 2025 om 19:04 schreef Ashok:

> First, reviewing the implementation, I think it is broken in how it tests
> for lengths of lists and dictionaries, in particular the case where
> objPtr->bytes is a sequence of spaces that has been shimmered to a dict or
> list.
>

Indeed!   Implementation is fixed now, and some testcases added. Thanks!


> I do not think it is good practice to have functions named as booleans
> (IsXXX) to return tristate values.
>

I now changed the implementation such that the function panic's when objPtr
= NULL.

Any more remarks?

Regards,
       Jan Nijtmans

Re: [TCLCORE] TCL manual pages - how are they reviewed ?

[Dipl. I. S. G. B. <se...@us...>]

 

It's not entirely true - clock command got several changes at user
level, see the TIPs 688 [1] and 690 [2]. 

Regarding the documentation: it also got a lot of changes (clock format
now, -validate option etc), see: 

fossil diff --from core-8-6-branch --to main doc/clock.n 

(no idea whether or how it is possible via fossil-UI). 

Regards,
Serg. 

07.02.2025 00:41, Brian Griffin wrote: 

> The clock command hasn't changed from a usage perspective, hence the 8.5- specification. 
> 
> -Brian
 

Links:
------
[1] https://core.tcl-lang.org/tips/doc/trunk/tip/688.md
[2] https://core.tcl-lang.org/tips/doc/trunk/tip/690.md

Re: [TCLCORE] TCL manual pages - how are they reviewed ?

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

The value "8.5-" indicates that the code herein will work with any version >= 8.5
If a package/code is compatible without any changes, then this technique can be used instead of having to release a new version simply to change the package require statement.

The clock command hasn't changed from a usage perspective, hence the 8.5- specification.

-Brian

On Feb 6, 2025, at 10:44, Karl Koehler via Tcl-Core <tcl...@li...> wrote:

Hi,

I was looking up something for TCL 9.0, I am experiencing differences in the ‘clock’ command between TCL 9.0 and TCL 8.6 and was wondering if that’s just me ?
So I went to the authoritative website:
https://www.tcl-lang.org/man/tcl9.0/TclCmd/clock.html
Note ! The URL specifies this is for TCL 9.0 !
But in the text:

SYNOPSIS
package require Tcl 8.5-

clock add timeVal ?count unit...? ?-option value?

This indicates that the documentation has not been reviewed since TCL 8.5 …
Is this even the right list for this kind of gripes  ( I didn’t seem to see anything that fits better ) ?

Thanks,

  *   Karl

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

Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

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

Jan wrote: One thing Ashok pointed out is that memorymodule wouldn't

work with WINE. Actually, I tried it (on Ubuntu 24.) and all

testcases work except one

 

As a point of clarification, having never used WINE I specifically *quoted* Christian’s WINE-related comment based on his initial tests as documented in his post in the ticket.

 

Jan wrote: My current approach is to prove all of Ashok's arguments to

be false, one by one. That will take time, but that's what it is.

 

I appreciate and empathise that proving software does not have a bug is impossible. However, there is a level of confidence that arises from the number and nature of tests that have been done. I will point out that you insisted, and I quote, I did additional testing with TLS (thread-local storage). That worked too. Forcing me to illustrate with the simplest of TLS test cases that it in fact did not work. I appreciate additional effort has been made in this area with disabling memory loading of TLS dependent DLL’s, exception testing etc. Maybe it is stable now, I have not reviewed and do not have the time to construct further tests.

 

Since the matter is dragging on, I’ll summarize the crux of the matter. 

 

My concern is implementing undocumented Windows behaviors carries inherent risk because the implementation may not handle all cases correctly, and even if it did, Windows could change it in any release breaking existing applications that made use of TIP 709. I am also conservative in that anything that carries risk should be outweighed by its benefits. I do not believe that is the case here.

 

Your response is that you believe the issues I raised have been, or are being, fixed and testing of a bunch of Tcl extensions points to that. Second, even if there are some features missing or buggy, none of those are used by Tcl extensions and therefore possible implementation shortcomings do not matter for Tcl applications. Further, the chances of Windows breaking TIP 709 applications by changing the loader implementation in a manner that affects Tcl extensions are vanishingly small.

 

Fair enough. I see it as we have different philosophies and degrees of conservatism in software practice.

 

If you and Christian are confident, you really do not have to wait to convince me, I’m just one opinion.

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Thursday, February 6, 2025 4:15 PM
To: Harald Oehlmann <har...@el...>
Cc: Steve Landers <st...@di...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

 

Op wo 5 feb 2025 om 10:37 schreef Harald Oehlmann:

I am not in favour, that the feature is optionally compiled in.
If it is in, it should be in any suitable Windows build of TCL.

 

I would be OK with enabling it always. If a "-windowsignoretls"

option is necessary to get this TIP passed, that would be

a pity: A new option which should be on always. Remember:

the first Tcl extension for which TIP #709 doesn't work

still has to be found. (It didn't work for TLS, but that's solved

now)

 

My current approach is to prove all of Ashok's arguments to

be false, one by one. That will take time, but that's what it is.

 

One thing Ashok pointed out is that memorymodule wouldn't

work with WINE. Actually, I tried it (on Ubuntu 24.) and all

testcases work except one:

 

==========================================================

$ make test-tcl TESTFLAGS="-file memorymodule.test"

....
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available.
Test files run in separate interpreters
Running tests that match:  *
Skipping test files that match:  l.*.test
Only running test files that match:  memorymodule.test
Tests began at Thu Feb 06 11:24:39 +0100 2025
memorymodule.test
==== memorymodule-2.2 nexted exception FAILED
==== Contents of test case:
    NestedException
---- Result was:
0
---- Result should have been (exact matching):
1
==== memorymodule-2.2 FAILED
Tests ended at Thu Feb 06 11:24:39 +0100 2025
all.tcl:        Total   9       Passed  8       Skipped 0       Failed  1

===================================================

 

Then I tried the same without the --enable-memorymodule option.

Guess what: the memorymodule-2.2 testcase failed as well.

 

Conclusion:  Exception throwing/catching doesn't work well

with WINE, but without memorymodule it doesn't work well

either. Conclusion: this is a bug in WINE, not in memorymodule.

 

Hope this helps,

          Jan Nijtmans

 

[TCLCORE] TCL manual pages - how are they reviewed ?

[Karl K. <ka...@ac...>]

Hi,

I was looking up something for TCL 9.0, I am experiencing differences in the 'clock' command between TCL 9.0 and TCL 8.6 and was wondering if that's just me ?
So I went to the authoritative website:
https://www.tcl-lang.org/man/tcl9.0/TclCmd/clock.html
Note ! The URL specifies this is for TCL 9.0 !
But in the text:

SYNOPSIS
package require Tcl 8.5-

clock add timeVal ?count unit...? ?-option value?

This indicates that the documentation has not been reviewed since TCL 8.5 ...
Is this even the right list for this kind of gripes  ( I didn't seem to see anything that fits better ) ?

Thanks,

  *   Karl

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

I agree with Ashok’s comments. If the function is to return multiple values (more than two), then the function name needs to reflect that.

Ex: Tcl_GetObjEmptyState()

Not that I think such a function is necessary. :)

-Brian
(from mobile device)

On Feb 6, 2025, at 10:05, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:


I think this would be a useful addition, but I have some questions and suggestions.

First, reviewing the implementation, I think it is broken in how it tests for lengths of lists and dictionaries, in particular the case where objPtr->bytes is a sequence of spaces that has been shimmered to a dict or list.

For example (using the tcltest testisempty command in the apn-tip-711 branch),

% set x "      "

% testisempty $x
0
% dict size $x
0
% testisempty $x
1
% string length $x
6

Ditto for lists.

A design related comment - make Tcl_IsEmpty a part of the Tcl_ObjType (like abstract lists). That immediately makes available the same quick check and avoidance of shimmering for new Tcl_Obj types defined within extensions. It is the same exact reason for having the LengthProc method in Tcl_ObjType.

Second, with respect to the API, I have two comments that pertain to style. May be considered bike-shedding by some but naming and principle of least surprise is important.

I do not think it is good practice to have functions named as booleans (IsXXX) to return tristate values. For anyone considering this a trivial matter, take a look at the SSL paper on certificate validation by Georgiev et al. It is the most natural thing for programmers to write

if (IsXXX(...))...

when they should really be checking three values. I don't remember the details but if a validation API returned 1 for valid, 0 for invalid and -1 for server unreachable you can see the trouble it leads to. IsEmpty is not validating certs but returning three values from a function with that name is not a good idea. Names are important.

Further, it would suffice to return 0, non-zero and mandate that objPtr be non-NULL. Your response to Sergey that it is an external function is not particularly convincing as the vast majority of public Tcl API's require passed Tcl_Obj* be non-NULL.

One final comment. I understand this is the comment stage, not ready for vote so test cases are not present and still to be written. Just as a point to note though, the Tcl core does not exercise the function at all since (a) the call is generally not used in favor of existing checks as Sergey alluded, (b) In the cases where it is used (AppendObjToObj), string rep is generated anyways so the return value is immaterial (only an optimization, not a functional bug, thus not detected). So having those test cases becomes more critical before a CFV.

/Ashok


From: Jan Nijtmans <jan...@gm...>
Sent: Thursday, February 6, 2025 7:33 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

This is a CFV warning for TIP #711:
    New function: Tcl_IsEmpty()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/711.md>

This is the first TIP targeting 9.1, a useful
simple one to make a start.

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

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

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

I think this would be a useful addition, but I have some questions and suggestions.

 

First, reviewing the implementation, I think it is broken in how it tests for lengths of lists and dictionaries, in particular the case where objPtr->bytes is a sequence of spaces that has been shimmered to a dict or list.

 

For example (using the tcltest testisempty command in the apn-tip-711 branch),

 

% set x "      "

 

% testisempty $x

0

% dict size $x

0

% testisempty $x

1

% string length $x

6

 

Ditto for lists.

 

A design related comment - make Tcl_IsEmpty a part of the Tcl_ObjType (like abstract lists). That immediately makes available the same quick check and avoidance of shimmering for new Tcl_Obj types defined within extensions. It is the same exact reason for having the LengthProc method in Tcl_ObjType.

 

Second, with respect to the API, I have two comments that pertain to style. May be considered bike-shedding by some but naming and principle of least surprise is important.

 

I do not think it is good practice to have functions named as booleans (IsXXX) to return tristate values. For anyone considering this a trivial matter, take a look at the SSL paper on certificate validation by Georgiev et al. It is the most natural thing for programmers to write

 

if (IsXXX(...))...

 

when they should really be checking three values. I don't remember the details but if a validation API returned 1 for valid, 0 for invalid and -1 for server unreachable you can see the trouble it leads to. IsEmpty is not validating certs but returning three values from a function with that name is not a good idea. Names are important.

 

Further, it would suffice to return 0, non-zero and mandate that objPtr be non-NULL. Your response to Sergey that it is an external function is not particularly convincing as the vast majority of public Tcl API's require passed Tcl_Obj* be non-NULL.

 

One final comment. I understand this is the comment stage, not ready for vote so test cases are not present and still to be written. Just as a point to note though, the Tcl core does not exercise the function at all since (a) the call is generally not used in favor of existing checks as Sergey alluded, (b) In the cases where it is used (AppendObjToObj), string rep is generated anyways so the return value is immaterial (only an optimization, not a functional bug, thus not detected). So having those test cases becomes more critical before a CFV.

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Thursday, February 6, 2025 7:33 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

 

This is a CFV warning for TIP #711:
    New function: Tcl_IsEmpty()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/711.md>

This is the first TIP targeting 9.1, a useful

simple one to make a start.


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

 

Re: [TCLCORE] perl tcl/tk status

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

Vladim,
conratulations !
In this community, we have:
- Announcements on clt
- the wiki
- the core list.
If you author a text, I may take care on this.
Take care,
Harald


Am 06.02.2025 um 17:26 schrieb Vadim V Konovalov via Tcl-Core:
> TL;DR
> 
> Perl module for tcl/tk 9 works good,
> Except when trying to use it for the BAWT - in this case some trick is required, but no problem when packaging perl+tcl/tk.
> 
> All in all, the status is: DONE [x], in case this should be mentioned somehow somewhere
> 
> -----Original Message-----
> From: Vadim V Konovalov via Tcl-Core <tcl...@li...>
> Sent: Sunday, January 26, 2025 9:28 PM
> To: 'Tcl Core List' <tcl...@li...>
> Subject: [TCLCORE] perl tcl/tk status
> 
> Hi,
> 
> Now I can confirm that current version of Perl/Tcl module (module itself is named Tcl) is actually ok in its current version 1.50, plus I've just released a bit cleaned-up version 1.51, but 1.50 also ok.
> 
> I tried on debian and all tests are good, except some minor failure:
> t/text.t ........ version conflict for package "Tk": have 9.0.0, need 8.4 at /home/vad/.cpan/build/Tcl-Tk-1.29-0/blib/lib/Tcl/Tk.pm line 942.
> (I will look into this problem later, the failing code is a fallback when tcl/tk setup does not have widget::scrolledwindow package, so Perl/Tcl-Tk provides the missing scrollw.tcl file)
> 
> The difficulty I am still having is with windows usage against BAWT build of Tcl:
> 
> perl -Mblib -MTcl -we "my $i = new Tcl;$i->Init;$i->Eval('puts $auto_path;package require tk;pack [button .b];tk_messageBox -title 123')"
> //zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl C:/vad/perl-dev/strawberry-perl-5.38.0.1-64bit-portable/perl/lib
> can't find package tk at -e line 1.
> 
> So here 'tk' package failed to be located.
> 
> Then I add the tk path to the auto_path list, and the problem goes away:
> 
> perl -Mblib -MTcl -we "my $i = new Tcl;$i->Init;$i->Eval('lappend auto_path C:/vad/apps/Tcl-bawt-bi-901-64/lib;puts $auto_path;package require tk;pack [button .b];tk_messageBox -title 123')"
> //zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl C:/vad/perl-dev/strawberry-perl-5.38.0.1-64bit-portable/perl/lib C:/vad/apps/Tcl-bawt-bi-901-64/lib
> 
> (I see message box and empty button here)
> 
> Should I need to add more initialization steps here?
> To say, I can't find the init.tcl file in BAWT directory.
> 
> Thanks in advance,
> Vadim
> 
> _______________________________________________
> 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


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 NAUMBURG - Germany
Phone: +49 3445 781120
Direct: +49 3445 781127
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal

Re: [TCLCORE] perl tcl/tk status

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

TL;DR

Perl module for tcl/tk 9 works good,
Except when trying to use it for the BAWT - in this case some trick is required, but no problem when packaging perl+tcl/tk.

All in all, the status is: DONE [x], in case this should be mentioned somehow somewhere

-----Original Message-----
From: Vadim V Konovalov via Tcl-Core <tcl...@li...> 
Sent: Sunday, January 26, 2025 9:28 PM
To: 'Tcl Core List' <tcl...@li...>
Subject: [TCLCORE] perl tcl/tk status

Hi,

Now I can confirm that current version of Perl/Tcl module (module itself is named Tcl) is actually ok in its current version 1.50, plus I've just released a bit cleaned-up version 1.51, but 1.50 also ok.

I tried on debian and all tests are good, except some minor failure:
t/text.t ........ version conflict for package "Tk": have 9.0.0, need 8.4 at /home/vad/.cpan/build/Tcl-Tk-1.29-0/blib/lib/Tcl/Tk.pm line 942.
(I will look into this problem later, the failing code is a fallback when tcl/tk setup does not have widget::scrolledwindow package, so Perl/Tcl-Tk provides the missing scrollw.tcl file)

The difficulty I am still having is with windows usage against BAWT build of Tcl:

perl -Mblib -MTcl -we "my $i = new Tcl;$i->Init;$i->Eval('puts $auto_path;package require tk;pack [button .b];tk_messageBox -title 123')"
//zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl C:/vad/perl-dev/strawberry-perl-5.38.0.1-64bit-portable/perl/lib
can't find package tk at -e line 1.

So here 'tk' package failed to be located.

Then I add the tk path to the auto_path list, and the problem goes away:

perl -Mblib -MTcl -we "my $i = new Tcl;$i->Init;$i->Eval('lappend auto_path C:/vad/apps/Tcl-bawt-bi-901-64/lib;puts $auto_path;package require tk;pack [button .b];tk_messageBox -title 123')"
//zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl C:/vad/perl-dev/strawberry-perl-5.38.0.1-64bit-portable/perl/lib C:/vad/apps/Tcl-bawt-bi-901-64/lib

(I see message box and empty button here)

Should I need to add more initialization steps here?
To say, I can't find the init.tcl file in BAWT directory.

Thanks in advance,
Vadim

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

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

Op do 6 feb 2025 om 16:59 schreef Dipl. Ing. Sergey G. Brester:

> But then why not normalize TclCheckEmptyString in the same way (or then
> just invoke it or combine both somehow)?
>

I think that all places where TclCheckEmptyString() is used now
could be improved by using Tcl_IsEmpty() instead. But that
can be done later.

Regards,
      Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

[Dipl. I. S. G. B. <se...@us...>]

 

Comments embedded 

06.02.2025 16:12, Jan Nijtmans wrote: 

> Op do 6 feb 2025 om 15:39 schreef Dipl. Ing. Sergey G. Brester: 
> 
>> case with -1 for NULL is over-complication, IMHO, and if expected (and not considered by Tcl_IsEmpty), 
>> can be simply done with (obj ? Tcl_IsEmpty(obj) : -1)...
> 
> Since Tcl_IsEmpty() is a public function, it should never crash.

Ok, are we in paranoia mode now?
99% of public core functions will segfault, since they never checked
objPtr for NULL before.
For instance Tcl_GetString and co.
But if you rather by "Tcl_Is*" functions, there are also Tcl_IsShared
etc. 

> Overally, I think this is useful (otherwise I woudn't propose it).

It is not about usability, it is more about consistence and performance
in regular case. 
Again, almost all public functions never did it before. 

> ...
> 
>> there are more cases (types) inside Tcl_IsEmpty what are never empty - e. g. a not empty list or series, but also numeric types are never empty (will never generate "" as string representation).
>> Tcl already has such checks (e. g. in TclCheckEmptyString, however in my fork it has many cases).
> 
> That's already handled: Numeric types have a "length" proc which always 
> return 1, so Tcl_IsEmpty() will handle "int", "bignum" ... as well without 
> generating a string-rep. Even Tk's "pixel" type implelements a "length" 
> proc, so Tcl_IsEmpty() can handle it as well without generating 
> a string rep :-)

But then why not normalize TclCheckEmptyString in the same way (or then
just invoke it or combine both somehow)? 

Hope this helps, 

Sergey. 

 

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

Op do 6 feb 2025 om 15:39 schreef Dipl. Ing. Sergey G. Brester:

>
>    1. case with -1 for NULL is over-complication, IMHO, and if expected
>    (and not considered by Tcl_IsEmpty),
>    can be simply done with (obj ? Tcl_IsEmpty(obj) : -1)...
>
> Since Tcl_IsEmpty() is a public function, it should never crash.
Especially in Tk, NULL
is a special case in option handling, which is equivalent to "". Also, -1 is
a general error-return value, which shows exactly what's happening.

     If you want NULL to behave the same as false, you can write:
            if (Tcl_IsEmpty(obj) > 0) ...
Overally, I think this is useful (otherwise I woudn't propose it).

>
>    1. please don't use it internally as in [0eaaef49d8b34adf]
>    <https://core.tcl-lang.org/tcl/vinfo/0eaaef49d8b34adf> for example in
>    generic/tclStringObj.c:1393
>    (where it is already known that object is bytearray), or in
>    generic/tclList.c:2027 (where the type doesn't matter), so why it shall be
>    again checked in Tcl_IsEmpty (or vice versa hereafter if not-empty)?
>    IMHO, it belongs only to pieces where object type is still unknown (or
>    in generic case) and it must be compared with "" without to generate string
>    representation, isn't it?
>    Otherwise, if compiler cannot optimize it internally as inline by
>    linkage, it'd be too much overhead.
>
> Agreed. This can be seen as a "eat your own dogfood", meant as proof that
the
function works and does what it's expected to do. If the TIP is accepted, I
will
remove it from where it doesn't make sense.


>
>    1. there are more cases (types) inside Tcl_IsEmpty what are never
>    empty - e. g. a not empty list or series, but also numeric types are never
>    empty (will never generate "" as string representation).
>    Tcl already has such checks (e. g. in TclCheckEmptyString, however in
>    my fork it has many cases).
>
>
That's already handled: Numeric types have a "length" proc which always
return 1, so Tcl_IsEmpty() will handle "int", "bignum" ... as well without
generating a string-rep. Even Tk's "pixel" type implelements a "length"
proc, so Tcl_IsEmpty() can handle it as well without generating
a string rep :-)  Only "dict" has no "length" proc, therefore it had
to be handled especially.

Hope this helps,
         Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

[Dipl. I. S. G. B. <se...@us...>]

 

Hi Jan,

although the function makes sense, but... 

	* case with -1 for NULL is over-complication, IMHO, and if expected
(and not considered by Tcl_IsEmpty), 
can be simply done with (obj ? Tcl_IsEmpty(obj) : -1)... 
	* please don't use it internally as in [0eaaef49d8b34adf] [3] for
example in generic/tclStringObj.c:1393
(where it is already known that object is bytearray), or in
generic/tclList.c:2027 (where the type doesn't matter), so why it shall
be again checked in Tcl_IsEmpty (or vice versa hereafter if not-empty)?
IMHO, it belongs only to pieces where object type is still unknown (or
in generic case) and it must be compared with "" without to generate
string representation, isn't it?
Otherwise, if compiler cannot optimize it internally as inline by
linkage, it'd be too much overhead. 
	* there are more cases (types) inside Tcl_IsEmpty what are never empty
- e. g. a not empty list or series, but also numeric types are never
empty (will never generate "" as string representation).
Tcl already has such checks (e. g. in TclCheckEmptyString, however in my
fork it has many cases). 

Regards,
Serg. 

06.02.2025 15:02, Jan Nijtmans wrote: 

> This is a CFV warning for TIP #711:
> New function: Tcl_IsEmpty()
> <https://core.tcl-lang.org/tips/doc/trunk/tip/711.md [2]>
> 
> This is the first TIP targeting 9.1, a useful 
> simple one to make a start. 
> 
> 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 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tips/doc/trunk/tip/711.md
[3] https://core.tcl-lang.org/tcl/vinfo/0eaaef49d8b34adf

[TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

This is a CFV warning for TIP #711:
    New function: Tcl_IsEmpty()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/711.md>

This is the first TIP targeting 9.1, a useful
simple one to make a start.

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

Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

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

Op wo 5 feb 2025 om 10:37 schreef Harald Oehlmann:

> I am not in favour, that the feature is optionally compiled in.
> If it is in, it should be in any suitable Windows build of TCL.
>

I would be OK with enabling it always. If a "-windowsignoretls"
option is necessary to get this TIP passed, that would be
a pity: A new option which should be on always. Remember:
the first Tcl extension for which TIP #709 doesn't work
still has to be found. (It didn't work for TLS, but that's solved
now)

My current approach is to prove all of Ashok's arguments to
be false, one by one. That will take time, but that's what it is.

One thing Ashok pointed out is that memorymodule wouldn't
work with WINE. Actually, I tried it (on Ubuntu 24.) and all
testcases work except one:

==========================================================
$ make test-tcl TESTFLAGS="-file memorymodule.test"
....
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and
serial are not available.
Test files run in separate interpreters
Running tests that match:  *
Skipping test files that match:  l.*.test
Only running test files that match:  memorymodule.test
Tests began at Thu Feb 06 11:24:39 +0100 2025
memorymodule.test
==== memorymodule-2.2 nexted exception FAILED
==== Contents of test case:
    NestedException
---- Result was:
0
---- Result should have been (exact matching):
1
==== memorymodule-2.2 FAILED
Tests ended at Thu Feb 06 11:24:39 +0100 2025
all.tcl:        Total   9       Passed  8       Skipped 0       Failed  1
===================================================

Then I tried the same without the --enable-memorymodule option.
Guess what: the memorymodule-2.2 testcase failed as well.

Conclusion:  Exception throwing/catching doesn't work well
with WINE, but without memorymodule it doesn't work well
either. Conclusion: this is a bug in WINE, not in memorymodule.

Hope this helps,
          Jan Nijtmans

[TCLCORE] Report of monthly Tk telco

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

Dear Tk team,

the monthly Tk telco took place yesterday and only one participant did 
not participate at the biweekly TCL telcos.
Unfortunately, the Jitsi performance was poor for me.
The following German meeting did not happen due to a lack of participants.

The discussion was purely informal.
The ttk::panedwindow sash was seen as improvement.
It was reported, that on Mac, the Sash is sometimes very hard to grap. I 
suppose, the fix size in pixels made the (invisible) sash very small on 
high resolution MACs. Also, the sash size scaling will improve this.

Ways to get the new text widget accessible for novice users were discussed.
- in Tk core with different name
- as bundled packages (Tk has no bundled packages)
No conclusion was found.
The code was seen as very complex and not understandable.
The current text widget is easier to understand.

Upcoming telcos:

I am proposing not to call for a Tk meeting in March due to lack of 
participation.

The next biweekly TCL telco will be 10th of February 12:00 UTC.
Note, that I will not attend and Jan will open the session.

Thank you all and take care,
Harald

Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

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

Am 04.02.2025 um 16:07 schrieb Jan Nijtmans:
> Op di 4 feb 2025 om 03:10 schreef Steve Landers 
> <st...@di... <mailto:st...@di...>>:
> 
>     Re macOS ... dynamic loading out of a VFS has always been a feature
>     on macOS - at least back to the early days of Starkits.  I would be
>     *extremely* disappointed to find out it is now an “opt in” feature
>     and can see no downside to keeping it as the default on macOS.
> 
> 
> Indeed, that's the point. If the "load -memory" option is a no-op for 
> macOS and UNIX (which is
> should be, since this is meant for Windows only), it will only add to 
> the confusion.
> 
> Remember that we already have 3 options to switch off memorymodule:
> 1) Don't use --enable-memorymodule, which is the default anyway. The
>      current proposal is opt-in, so it won't affect anyone unless 
> explicitly turned on.
> 2) Use statical linking (which is preferred anyway, but not always possible)
> 3) Add a __declspec(thread) variable to the dll code invovled. This also 
> has the
>      effect that the memorymodule loading will fail and the fallback 
> activated.
> 
> Having already 3 ways to switch the behavior, a 4th one (either -memory
> or -nomemory) doesn't have additional benefits. It's not worth it. I don't
> think its additional value will convince Ashok.
> 
> I now added testcases to the TIP #709 implementation for more elaborate
> exception handling: We now throw an exception from a different dll
> than catching it. MemoryModule handles it well.
> 
> Regards,
>           Jan Nijtmans
> 

Hi Jan, Hi TCL team,

I just want to point out, that I would prefer, if a *novice* user would 
choose memory load on the Windows platform on the script level in an 
opt-in way.
E.g.:
load -windowsmemoryload mydll.dll
and, if the user choses it, it would happen or it errors out.

I am not in favour, that the feature is optionally compiled in.
If it is in, it should be in any suitable Windows build of TCL.

I am not so much in favour of the automatic __declspec(thread) 
detection. Maybe, I want to use a part of the DLL, which is not 
concerned? I don't know, if this is realistic. We would need an 
additional "-windowsignoretls" flag.

Thank you and take care,
Harald

Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

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

Op di 4 feb 2025 om 03:10 schreef Steve Landers <st...@di...>:

> Re macOS ... dynamic loading out of a VFS has always been a feature on
> macOS - at least back to the early days of Starkits.  I would be
> *extremely* disappointed to find out it is now an “opt in” feature and can
> see no downside to keeping it as the default on macOS.
>

Indeed, that's the point. If the "load -memory" option is a no-op for macOS
and UNIX (which is
should be, since this is meant for Windows only), it will only add to the
confusion.

Remember that we already have 3 options to switch off memorymodule:
1) Don't use --enable-memorymodule, which is the default anyway. The
    current proposal is opt-in, so it won't affect anyone unless
explicitly turned on.
2) Use statical linking (which is preferred anyway, but not always possible)
3) Add a __declspec(thread) variable to the dll code invovled. This also
has the
    effect that the memorymodule loading will fail and the fallback
activated.

Having already 3 ways to switch the behavior, a 4th one (either -memory
or -nomemory) doesn't have additional benefits. It's not worth it. I don't
think its additional value will convince Ashok.

I now added testcases to the TIP #709 implementation for more elaborate
exception handling: We now throw an exception from a different dll
than catching it. MemoryModule handles it well.

Regards,
         Jan Nijtmans

[TCLCORE] Typo in tcllib 2 httpd

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

Typo in tcllib 2 httpd / nexttool.tcl should be nettool.tcl

tclsh
% package require httpd
4.3.6
% set srv [httpd::server new]
couldn't read file "/opt/tcl/8.6/lib/tcllib2.0/nettool/nexttool.tcl": no such file or directory
%

alex@as23mbp:~> l /opt/tcl/8.6/lib/tcllib2.0/nettool
total 120
-rw-r--r--@ 1 root  wheel   288B 31 Jan  2024 pkgIndex.tcl
-rw-r--r--@ 1 root  wheel    52K 31 Jan  2024 nettool.tcl

Alex