Re: status of fileevent support? (for use with Tcl::pTk)

[Christopher Chavez]

(Continuing discussion from https://github.com/gisle/tcl.pm/issues/14 
 here per Vadim's suggestion)

> chrstphrchvz  commented Jul 11, 2018, 3:06 
> PM CDT:
>> I came across an issue using fileevent from Tcl::pTk on macOS, which I've 
>> documented here: https://rt.cpan.org/Ticket/Display.html?id=125662 
>> 
>> I noticed there's comments in Tcl::pTk's fileevent 
>> 
>>  suggesting it be rewritten, since it has known shortcomings (e.g. only 
>> supporting 'readable', relies on polling interval). Another suggestion it 
>> makes is for Tcl.pm to support CreateFileHandler.
>> 
>> But do Tcl::Tk and/or Tkx already allow using fileevent 'as-is' through 
>> Tcl.pm? (I haven't yet successfully tried; is there a readily available 
>> example somewhere?) If that's the case, then I'm wondering if it's a matter 
>> of making Tcl::pTk recognize fileevent as something it should just pass 
>> through to Tcl.pm if it's syntax is sufficiently compatible with Perl/Tk's.
>> 
> 
vadrer  commented Jul 12, 2018, 2:46 AM CDT:
> I haven't tried tcl/tk's fileevent, and actually I have no much plans on 
> doing so.
> The reason is that I mostly use tcl/tk for GUI, and perl for IO;
> 
> however it is possible to use tcl/tk's fileevent, but in this case we should 
> expect for it to perform said IO.
> problem with Tcl::pTk could be that it should "join" perl IO and tcl/tk IO; 
> which is not very easy, plus I do not foresee much benefits from doing so.
> 

For the program I'm working on (cf. https://github.com/hotwolf/HSW12/issues/16 
) the existing fileevent is for 
reading a serial port. It already uses separate read and write filehandles; it 
might be sufficient to use Tcl syntax to open a read handle for the device and 
make a fileevent for it (from Tcl rather than Perl), while continuing to use a 
Perl write filehandle in UI event callbacks.

For other uses, I'm not quite sure what the best approach will be. It doesn't 
seem possible to use some modern module like IO::Async in the same thread with 
e.g. Tcl::pTk due to separate event loops. If combining the file handles is 
best, that seems like something needing to be done from C/XS (not pure Perl or 
Tcl), which is what using Tcl_CreateFileHandler would entail.

Git repository for Tcl::pTk

[Christopher Chavez]

To make the latest source code slightly more accessible, and able to accept 
patches (pull requests) more easily, I have converted the SVN repository for 
Tcl::pTk on SourceForge (https://sourceforge.net/p/perl-tcl-ptk/code/) to a Git 
repository, and have published it to GitHub:

https://github.com/chrstphrchvz/perl-tcl-ptk

I’ll make sure it shows up on metaCPAN with the next release.

Christopher A. Chavez

Re: Tcl::pTk overwrite About [macOS]

[Christopher Chavez]

> On Aug 13, 2018, at 1:22 PM, welle Ozean via tcltk  wrote:
> 
> Hello,
> 
> I have a Tk application for macOS written with Tcl::pTk and packed as a 
> normal macOS bundle. In the macOS menu, under the name of the application 
> bundle there is a menu item called "About + Name of application". This is 
> created auotmatically and contains the Tcl version. In this About menu, I 
> would like to replace/integrate the default values with information about my 
> App. Is this possible? If yes, how? I couldn't find any information online.
> 
> Best,
> Welle

Hi Welle,

I have been curious about this feature myself, but I have yet to figure out how 
exactly to use it from Perl (whether through Tcl::pTk, Tkx, etc.). The Tcl/Tk 
widget demo is able to set its own About entry, so the capability in Tcl/Tk 
should be working and available for our use from Perl.

The main idea is to add an About entry to a special `apple` menu. For some 
background on this feature, there’s Tk’s documentation of using it: 
https://www.tcl.tk/man/tcl/TkCmd/menu.htm#M21 . Perl/Tk had adapted that 
verbiage in 
https://metacpan.org/pod/distribution/Tk/pod/Menu.pod#SPECIAL-MENUS-IN-MENUBARS 
but clearly that’s not been updated since Mac OS classic. TkDocs also explains 
how this feature works and how to use it from other languages besides Tk (Ruby, 
Perl using Tkx, and Python using Tkinter): 
https://tkdocs.com/tutorial/menus.html

However none of the Tkx examples had an effect when I tried it (they still had 
the default About dialog), whether from TkDocs’ example or the examples 
included with Tkx (tkx-ed and menu scripts). I was hoping to adapt the Tkx 
usage to Tcl::pTk syntax once I got it working.

Note that the windowingsystem should be checked prior to using the `apple` 
menu, i.e. placed in something like `if($widget->windowing system eq 'aqua') { 
… }`.

Re: Custom Widgets

[Christopher Chavez]

  
  
  

Hi Sandy,
I see you recently posted about this on PerlMonks: 
https://www.perlmonks.org/?node_id=1219968
As mentioned by https://www.perlmonks.org/?node_id=1220185 : if you intend to 
keep using the widgets from Perl, you might be able to use them with Tcl::pTk 
with little to no change, if you haven't already tried that. It tries to allow 
unmodified Perl/Tk programs and pure-perl custom widgets to work with Tcl/Tk. 
Otherwise, as others have said it is possible to use Tcl/Tk syntax from Tcl::Tk 
or Tkx.
I haven't found exactly what you might be looking for, but one source that 
might help with using Tcl/Tk syntax is TkDocs, but the way they do this from 
Perl is using Tkx, which many find a drastic change from Perl/Tk syntax. 
Tcl::Tk allows both Tcl/Tk syntax and some Perl/Tk syntax where possible, but 
is still a light wrapper like Tkx. Tcl::pTk tries to then cover any cases not 
covered by Tcl::Tk to allow running existing Perl/Tk programs. 
There's also this document with a few sections on the differences between 
Tcl/Tk and Perl/Tk: http://phaseit.net/claird/comp.lang.perl.tk/ptkFAQ.html

Hope this helps.



Christopher Chavez

  




On Sat, Aug 11, 2018 at 5:44 PM -0500, "Sandy L Bultena" 
 wrote:










Hi,
I am currently trying to port some of my old Perl/Tk programs to Tcl/Tk.  
I have many pure-perl custom widgets.  I am trying online to find a decent 
tutorial(s) on how to create custom widgets using perl Tcl/Tk.
Can you recommend anything?  Any examples? 
Thank you for your time.


Sandy

"If at first you don’t succeed, that’s one data point" 
-http://www.xkcd.com/1154/

partial photo/image tests without Img extension?

[Christopher Chavez]

I notice that both Tcl::Tk and Tcl::pTk have some tests that currently require 
the Img extension to handle image formats not included in Tcl/Tk. Would it be 
desirable to still test the formats that are available (gif; png on Tk 8.6), or 
is the test more about exercising the capabilities in Img? Is it even possible 
to plan a certain number of tests and then skip a subset of them?

This is low/“wishlist” priority; I ask only because at the moment MacPorts 
doesn’t have the Img extension.

Error running Makefile.PL on Windows

[Christopher Chavez]

I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and 
ActiveTcl 8.6.7.


*(Uses dmake and doesn't have gnu make. I'm not constrained to 
ActivePerl; I just didn't know about Strawberry until recently.)


I tried installing Tcl.pm 1.25 from cpanm as well as running the latest 
tcl.pm/Makefile.PL on git, but get errors:


> error starting tclsh: $?=-1; $!=Inappropriate I/O control operation
> error writing "stdout": broken pipe
> while executing
> "puts "tclsh=[info nameofexecutable]""
> (file "tclcfg.tcl" line 1)

I.e. from the first error it appears to be dying at line 115:

_die "error starting $tclsh: \$?=$?; \$!=$!\n" if $?!=0;

and the second error is just stderr from tclsh (complaining it couldn't 
write to stdout because Perl died)…



But running `tclsh tclcfg.tcl` both manually and from Perl seems to give 
the correct output. In fact if I comment out line 115 (`_die … if 
$?!=0`), then the tclsh output gets put in $tclcfg, and Makefile.PL 
seems to finish as expected.



I'm not sure what's wrong here. The only thing that seems strange to me 
is that $?=-1 for opening a command pipe on Windows (I can get $?=-1 for 
something like `open(my $fh, "echo hello |")`) but not on other OSes 
(e.g. macOS, where $?=0 when open() works). I have not found if/where 
this is explained in `perldoc open` or `perldoc perlipc`.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Error running Makefile.PL on Windows

[Christopher Chavez]

On 8/20/2018 2:36 PM, Konovalov, Vadim wrote:

I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and
ActiveTcl 8.6.7.

*(Uses dmake and doesn't have gnu make. I'm not constrained
to
ActivePerl; I just didn't know about Strawberry until recently.)


If you think that "dmake" is source of trouble, then we can add
workaround in Makefile.PL  to handle your case.

You can add a code that checks these vars $? and $! differently

fortunately, our Makefile.PL already has a stub to deal with dmake,
so you can benefit from it.

Fortunately I haven't encountered an issue with dmake specifically. I 
was checking to see if the past few commits of Tcl.pm would compile, and 
found the one from a few weeks ago when there were some suspicions over 
dmake causing compilation issues. The "dmake prohibited" message seemed 
to confuse ActivePerl for "modified" Strawberry Perl installation due to 
presence of dmake/lack of GNU make. But that message has since been 
reverted since the problem (if there is one) is believed to be elsewhere.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Escaping $tclsh in Makefile.PL

[Christopher Chavez]

In the Makefile.PL's for Tcl.pm, Tcl::Tk, and Tcl::pTk, the path to 
tclsh should probably be escaped somehow. That way, any characters like 
spaces get passed properly to the shell. I don't know what the best 
portable way to do this would be, nor whether surrounding it with double 
quotes (i.e. `"$tclsh" ...`) is sufficient.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Escaping $tclsh in Makefile.PL

[Christopher Chavez]

On 8/22/2018 6:21 AM, Konovalov, Vadim wrote:

I wonder if quotemeta enough??


I don't think that will work on Windows, because it escapes "too much" 
as it were. But double quotes might be enough: it will work with e.g.


"C:\New folder\..\ActiveTcl\bin\tclsh.exe"

but not

C\:\\New\ Folder\\\.\.\\ActiveTcl\\bin\\tclsh\.exe

(gives error "'C\:\\New\' is not recognized as an internal or external 
command, operable program or batch file.")


nor both (gives error "The filename, directory name, or volume label 
syntax is incorrect.").


For reference, the current error if there's a space: "'C:\New' is not 
recognized as an internal or external command, operable program or batch 
file."



I haven't thought of an issue with using quotemeta (presumably without 
double quotes) on UNIX though, since at least bash seems fine with 
things being \-escaped.



Still, I'm somewhat uneasy about putting this kind of logic, but it's 
probably better than leaving it how it currently is, and there's little 
else to do with using core Perl.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Separate lists for user and dev discussion; centralized forum; watching for questions?

[Christopher Chavez]

(See discussion on RT #125878: 
https://rt.cpan.org/Ticket/Display.html?id=125878 )

There’s been quite a bit of dev-related traffic on this list recently, although 
the total volume is still low (only a dozen or so threads from past couple 
years).

Would it be possible/ideal to separate user- and dev-related (and possibly 
bug-) discussions into another list?

Also, a user proposes a forum or other centralized way of discussing Perl/Tk 
alternatives, particularly Tcl::pTk on macOS aqua, since that seems to be what 
I and many of the other users of that module I’ve encountered are using it for. 
Any thoughts, or possible existing places to try?

Some users have posted questions on Perlmonks and StackOverflow over the past 
couple months, and just today did it occur to me to go look for them. Is there 
a better way besides reminding myself to check those on occasion?

Tcl::Tk for MacPorts

[Christopher Chavez]

  
  
  
  


  
  
  


Alongside existing ports in MacPorts for Tcl.pm, Tkx, and Tcl::pTk, I 
have added the a port for Tcl::Tk, p5-tcl-tk.

Christopher A. Chavez

  

Tcl::pTk: new co-maintainer, release 0.93, MacPorts

[Christopher Chavez]

Hi everyone,

I've recently been added as a co-maintainer to Tcl::pTk.
Thanks to John Cerney for helping me get started.

I'm particularly interested in its use with macOS aqua, since
it allows running Perl/Tk programs with native aqua UI and without 
needing XQuartz.


I released Tcl::pTk 0.93 to address a few issues which I and other users 
have reported so far. The more important usability changes are:

- focusFollowsMouse Perl/Tk syntax support (RT #125057)
- Adjust mousewheel scrolling units for macOS aqua (RT #125048)
- Use mouse buttons 4 and 5 for scrolling on X11 only (not aqua)
- Bind widgets' events for mouse buttons 2 and 3 correctly on aqua
  (since they are backwards from how X11 and Windows assign them;
  RT #125050, #125460)
- Prevent error when invoking Cut from F2 key (RT #125460)
- Allow '-forwards' for FindNext() direction, as documented
  by newer Perl/Tk (RT #125532)

I've also added a p5-tcl-ptk port to MacPorts. It doesn't yet provide 
complete functionality; at the moment, some of the ports for

Tk extensions (Tix and Tktable) only work with the X11 variant of
the Tk port.

Christopher A. Chavez

Re: Drop support for Tcl/Tk 8.4?

[Christopher Chavez]

> On Mar 27, 2019, at 3:29 AM, Christopher Chavez  wrote:
> 
> I am proposing to drop support for Tcl/Tk 8.4 from Tcl::pTk. 

Vadim, do either of Tcl.pm and Tcl::Tk intend to continue supporting Tcl/Tk < 
8.5 (if they currently do)?

Christopher A. Chavez

Re: Drop support for Tcl/Tk 8.4?

[Christopher Chavez]

On 3/27/2019 4:25 AM, Konovalov, Vadim wrote:
>> Vadim, do either of Tcl.pm and Tcl::Tk intend to continue
>> supporting Tcl/Tk < 8.5 (if they currently do)?
>
> They currently do support 8.4 and I am planning to continue support;
> Even 8.0 I supported
>
> Any signs that they don't?

Not to my knowledge.

One reason I ask though is in consideration of the possibility of
merging Tcl::pTk and Tcl::Tk, which I have not made progress on. Even if
I leave in compatibility with 8.4, I might only be willing to "actively
support" and test on 8.5 or later.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Drop support for Tcl/Tk 8.4?

[Christopher Chavez]

Hi all,

I am proposing to drop support for Tcl/Tk 8.4 from Tcl::pTk. This is mainly 
because:

  1. the developers of Tcl/Tk have no longer supported 8.4 for some time, and 
have encouraged anyone using it to upgrade;
  2. many binary Tcl/Tk distributions and OS package managers no longer provide 
8.4; and
  3. I personally have not tested Tcl::pTk on Tcl/Tk 8.4 for these reasons.

I have not thought of any immediate or significant benefits to the Tcl::pTk 
codebase other than being able to remove checks for whether Tcl/Tk 8.5+ is 
present before using features such as Tile/Ttk.

I will go ahead and bump the Tcl::pTk version to 1.00 if I drop Tcl/Tk 8.4.

I do not suspect that any of the active Tcl::pTk users I have heard from over 
the past several months are using Tcl/Tk 8.4, but please respond in case of 
objections to (or approval of :^) ) this proposal.

I currently do not have any plans to drop support for Tcl/Tk 8.5, since some 
platforms still ship with 8.5 (e.g. macOS).


Christopher A. Chavez

Re: Buttons with icons but without boxes on macOS and Tcl::pTk

[Christopher Chavez]

> On Feb 27, 2019, at 2:58 AM, welle Ozean via tcltk  wrote:
> 
> Hello,
> 
> using Tcl::pTk I want to move from the ttkButton to a plain clickable (png) 
> icon on gray background. I do not want the icon in a box, which is the 
> standard rendering of buttons, as far as I understand. This looks very odd 
> nowadays. At best, the icon should be accompanied by a test, as this 
> screenshot shows: https://ibb.co/dfYwKvM
> 
> On a mailing list I get the following Tcl/Tk answers:
> 
> 1) If you add -style Toolbutton to the ttk::button, the button will look flat 
> and modern. Adding "-compound top" will allow to specify both image and text.
> 
> 2)  set i1 [image create photo -file icon.png]
>  button .b -image $i1 -text Open -compound top -relief flat
>  pack .b
> Note that colors for the button widget and/or colors/transparency in 
> the png image will need to be adjusted so the icon and the button area 
> fit together seamlessly. 
> 
> No matter how many combinations I tried, I could not achieve my result (I 
> always had boxes around the icons, so that I think that Tcl::pTk does not 
> support much tweaking of the buttons. Has I guess this is the simplest way to 
> display icons on modern interfaces, maybe somebody here has already achieved 
> this result.
> 
> Welle


Hi Welle,

Are you trying this on Tk Aqua? If the ttk theme is set to the 'aqua' theme 
(the default), then it seems neither of those approaches yield box-less 
buttons. I suspect the repliers to your post on comp.lang.tcl were unaware of 
the behavior on aqua, since both approaches seem to work on Windows and 
X11—though on Windows the first approach (ttk Toolbutton) looks better because 
the buttons will actually highlight when hovered, while on X11 the second 
approach (flat regular button) looks better because it highlights without 
showing a raised border when hovered.

A workaround might be to use the first approach (the second approach seems 
unaffected) along with $mw->ttkSetTheme() to select a non-'aqua' ttk theme 
(such as the 'default' theme) for which the buttons render more properly, 
however this will affect *all* ttk widgets. Ideally a bug should be filed with 
Tcl/Tk requesting that Toolbuttons and flat-relief buttons be 
implemented/rendered properly on the 'aqua' theme.

The syntax for both approaches seems already supported in Tcl::pTk. For the 
first approach, use $mw->ttkButton(-style => 'Toolbutton', …). For the second 
approach, use $mw->Button(-relief => 'flat', …).

Hope this helps

Christopher Chavez

Tcl::pTk release 0.95; Help wanted for known issues

[Christopher Chavez]

Hi everyone,

I have uploaded Tcl::pTk 0.95. In addition to the notable changes below, it is 
mainly an accumulation of minor or non-functional changes.

Many test failures have been addressed, either by fixing bugs (usually in the 
tests themselves) or skipping/marking as TODO any tests with expected failures; 
see RT #119754, #125662, and #125908. An important note to CPAN Testers: 
UNKNOWN reports will no longer be generated if Tcl/Tk is not present when 
running Makefile.PL.

Other reported issues addressed in 0.95:
- Right-click causes selected text to be pasted on older Tk Aqua (RT #127120)
- `Can't locate object method "findINC" via package "Tk"` error (RT #127529)
- `Tcl procedure 'winfo' not found` error shown if "package require Tk" fails, 
e.g. Tk not installed (RT #127552)

There are still a quite few known issues; some are due to upstream issues in 
Tcl/Tk. In particular, I am stumped by two major usability issues on macOS 
Aqua: RT #125049 (unreadable menu items) and #125987 
("dictation"/speech-to-text not working as expected). I would greatly 
appreciate any advice or assistance in debugging these. See the bug tracker for 
more info: https://rt.cpan.org/Public/Dist/Display.html?Name=Tcl-pTk


Christopher A. Chavez

Re: [macOS] Tcl::pTk Drag

[Christopher Chavez]

(Trying to send this to the list again for reference and to see if I can send 
emails now. It didn’t go through the first time because GMX had been blocked by 
perl.org )

> On Sep 21, 2018, at 6:01 AM, welle Ozean via tcltk  > wrote:
> 
> Using Tcl::pTk I am trying to implement Drag on macOS without success. 
> According to its documentation, Tcl::pTk should support it. This is what I am 
> trying now (slightly adapted from my version for Windows and Perl/Tk):
> 
> $MyWidget->DropSite(-dropcommand => [\_drop, $tap], -droptypes => 
> (['Local', 'tkdnd']));
> 
> sub accept_drop {
> my ($tab) = @_;
> my $filePath;
>  eval {
>   if ($^O eq 'MSWin32') {
>   $filePath = $tab->SelectionGet(-selection => $selection,
> 'STRING');
>   }
>   else {
>   $filePath = $tab->SelectionGet(-selection => $selection,
> 'FILE_NAME');
>   }
>   }
> #DO THINGS with $filePath
> }
> 
> I have downloaded a binary of tkdnd (libtkdnd2.8.dylib). How do I let 
> Tcl::pTk know of this library? Or there is any way to implement it without 
> adding new libraries (I am using the Tcl shipped with macOS).
> 
> Thanks
> Welle

Hi Welle,

As Vadim stated, neither Tcl::pTk nor Tcl.pm do much to be aware of Tcl/Tk 
modules; Tcl::pTk currently only looks for a few that are required (Tklib, Tix, 
TkTable) or have Perl-wrapper syntax for (BLTNotebook). Ideally, tkdnd should 
be installed where `package require` is all that’s needed to use it; I don’t 
know my way around the other `package ifneeded` or other commands that might be 
needed if Tcl/Tk needs to manually be told where it is. There is at least one 
undocumented subroutine in Tcl::pTk that might be useful, 
`$MW->interp->pkg_require()`, however I do not know what its advantages or 
limitations are over just using `$MW->interp->Eval("package require tkdnd”)`. 
Though this step might be done automatically by Tcl::pTk depending on the 
syntax used.

Someone recently added tkdnd to MacPorts, so I might give it a try soon. I 
wonder if tkdnd support might be something to include in Tcl::pTk, similar to 
what’s done for TkTable and other Tk extensions.

Also, be aware that there have been some recent changes since tkdnd 2.8 was 
released which address issues on macOS; 
https://github.com/petasis/tkdnd/commits/master 


Christopher A. Chavez

Likely Tcl.pm issue on PerlMonks

[Christopher Chavez]

Just want to share a recent question I found on PerlMonks, in case anyone else 
wants to take a look or can help: https://www.perlmonks.org/?node_id=1233609

The user was initially trying to get Tkx working with DWIM Perl + ActiveTcl but 
the error looks like it might be coming from Tcl.pm — “failed dlopen(…)”.

Tcl::pTk release 1.00

[Christopher Chavez]

Hi all,

I have released Tcl::pTk 1.00.


One of the main changes is that I have attempted a two-line fix for RT
#125049 and #129505 to make menu entries legible on macOS Aqua when the
dark menu bar or dark mode is enabled. This change also affects the
appearance of derived widgets so that they are consistent with
non-derived widgets, especially when used with dark mode and the
upcoming Tk 8.6.10 release.

However, I am not certain that the approach I used doesn't introduce any
new issues, so any feedback on the approach I used is appreciated. So
far I do not observe any difference in appearance at all on Windows or
X11. The code originally responsible for the issue was borrowed from
Perl/Tk; and likewise I observe no differences under Perl/Tk if I apply
the same change.


Some other issues resolved:

 - Add missing Tile availability check to tileLabelFont.t (in case
anyone is still running Tk 8.4; RT #128813)
 - photo.t: proceed with remaining test cases after errors (RT #128803)
 - Print slightly more useful test reports by showing more of the tests
which are skipped completely along with reasons why.
 - Fix POD errors (`=cut` outside POD block) reported by CPANTS
(contribution from Mohammad S Anwar)


Christopher A. Chavez

Re: RE: High DPI on Windows with Tk

[Christopher Chavez]

On 6/23/19 at 2:07 AM, Konovalov, Vadim wrote:
> > > if ($^O eq 'MSWin32') {
> > >use Win32::API;
>
> Here should be 'require', not 'use'

Thanks for catching that, I have updated my post.

Tcl::pTk release 1.01

[Christopher Chavez]

On 6/18/19 at 10:08 PM, Christopher Chavez wrote:

> Hi all,
>
> I have released Tcl::pTk 1.00.
>
>
> One of the main changes is that I have attempted a two-line fix for RT
> #125049 and #129505 to make menu entries legible on macOS Aqua when the
> dark menu bar or dark mode is enabled. This change also affects the
> appearance of derived widgets so that they are consistent with
> non-derived widgets, especially when used with dark mode and the
> upcoming Tk 8.6.10 release.
>
> However, I am not certain that the approach I used doesn't introduce any
> new issues, so any feedback on the approach I used is appreciated. So
> far I do not observe any difference in appearance at all on Windows or
> X11. The code originally responsible for the issue was borrowed from
> Perl/Tk; and likewise I observe no differences under Perl/Tk if I apply
> the same change.


I have released Tcl::pTk 1.01 to fix similar issues in the DialogBox and 
Balloon widgets.


Christopher A. Chavez

High DPI on Windows with Tk

[Christopher Chavez]

Hi everyone,

I wanted to share a way for using high-DPI appearance on Windows that I found, 
in case anyone was interested. I have posted it to 
https://www.perlmonks.org/?node_id=11101747


Before calling MainWindow->new in Tk, use Win32::API to invoke 
SetProcessDPIAware():

if ($^O eq 'MSWin32') {
   use Win32::API;
   # See 
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdpiaware
   my $SetProcessDPIAware = Win32::API::More->new('User32', 'BOOL 
SetProcessDPIAware()');
   $SetProcessDPIAware->Call() or warn 'Failed to set process DPI awareness';
}


This isn't the approach Microsoft recommends (they suggest using an application 
manifest instead), but this seems to be an easy enough approach for standalone 
scripts.


Recent Tcl/Tk will enable high-DPI by default for scripts run using tclsh/wish, 
but not the Tcl C API. I'm not sure this behavior should be the default in 
Tcl::pTk, for compatibility (i.e. since Perl/Tk does not enable high-DPI) and 
because certain elements like images will not be resized automatically.

Maybe Tcl::Tk would be more in favor of having this behavior by default (for 
consistency with Tcl/Tk), but it might require XS or dependency on another 
module like Win32::API.


Christopher A. Chavez

Re: trouble installing Tkx

[Christopher Chavez]

On 11/20/2019 11:25 AM, Dave Howorth wrote:

There's a bug #115662 for Tkx on rt.cpan.org that was opened three
years ago with no response. I appended my log to it yesterday, since I
seem to be encountering the same problem with newer software (I'm on
openSUSE Leap 15.0)

https://rt.cpan.org/Public/Bug/Display.html?id=115662

I'd appreciate any suggestions. Let me know if you need any more
information.

Thanks and regards,
Dave Howorth



I have left a comment on that ticket as well as elsewhere on GitHub
where there is a related report and proposed fix.

In the meantime I suggest using cpanm --force to install Tkx. This will
ignore the single test failure that prevents installation. The failing
test is merely for intentionally generating an error message, which
still works but no longer produces the exact message that was hardcoded
into the test long ago.

Hope this helps

Christopher A. Chavez

Re: Call perl subroutine from $int->Eval

[Christopher Chavez]

Sent: Thursday, December 05, 2019 at 3:31 PM
From: "welle ozean via tcltk" 
To: tcltk@perl.org
Subject: Call perl subroutine from $int->Eval

> Is there a way to call a Perl subroutine from within the $int->Eval?



Yes, see https://metacpan.org/pod/Tcl#Accessing-Perl-from-within-Tcl

Tcl.pm creates a Tcl command `::perl::Eval` which accepts a string containing 
the Perl syntax to be evaluated.



Christopher A. Chavez

Re: Call perl subroutine from $int->Eval

[Christopher Chavez]

Sent: Friday, December 06, 2019 at 11:30 AM
From: "welle ozean" 
To: "Christopher Chavez" 
Subject: Re: Call perl subroutine from $int->Eval

> Thank you Christopher,

> this is very promising! But, I have no idea how to use it. Let's say I have 
> in my Perl code a subrutine called mySubrutine. How would I call it from 
> within the Eval Tcl code?

I would use something like:

$int->Eval(q/::perl::Eval {mySubroutine()} /)


I'm not an expert on how it works or if it has any significant limitations; it 
seems to work like Perl's built-in `eval` statement in the same scope as the 
`$int->Eval()`. I guess one thing to be careful of is which (if any) string 
delimiters/escaping are used both in Perl and Tcl especially whenever 
`$variables` need to be specified, so that they refer to a Tcl or Perl variable 
(or neither?). For example if using a Perl variable, doing

my $variable = ...;
$int->Eval(qq/::perl::Eval {mySubroutine($variable)} /);

might often behave the same as doing

my $variable = ...;
$int->Eval(q/::perl::Eval {mySubroutine($variable)} /);

but I would prefer the latter usage so that the value of `$variable` isn't 
translated (stringified) from Perl to Tcl and then back to Perl.


Christopher A. Chavez

Re: trouble installing Tkx

[Christopher Chavez]

On 11/23/2019 5:04 AM, Dave Howorth wrote:
> Many thanks. I don't suppose there's a reason your pull request
> hasn't been accepted yet.

The pull request belongs to someone else (Maximilian Lika). Tkx has been
dormant for several years, although it still works well with newer
upstream Tcl/Tk versions.

On 11/23/2019 2:01 PM, Konovalov, Vadim wrote:
> IMO taking ownership on the module is the way to go, if Gisle Aas
isn't arguing against this

In my quest for World Tk Wrapper Domination™, I actually have considered
requesting comaintainer rights for Tkx when I have better availability.
I haven't used Tkx for much other than comparison against Tcl::(p)Tk,
but I don't really have any objections to its syntax (especially with
the availability of a relatively modern tutorial on TkDocs.com), and I'd
be in favor of creating maintenance releases to reassure users it isn't
completely abandoned or broken.

Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 3/16/2020 3:48 AM, Christopher Chavez wrote:

The addresses involved are inside allocations from Tcl's thread block
cache, which I'm guessing could be heavily reused over the life of a Tcl
program (to minimize direct calls to malloc()). I'll ask Tcl developers,
but is anyone here aware of a way to disable this or make it
debugging-friendly to identify what the last user of the block is?


To partially answer my own question:
there are some compile-time techniques to try like -DPURIFY
https://wiki.tcl-lang.org/page/How+to+debug+memory+faults+in+Tcl+and+extensions

That page mentioned the Tcl exit command, which I've never used
from Perl. Adding it completely prevents the error:


use Tcl;
my $i = new Tcl;
$i->Init;
$i->Eval(<<'EOS');

package require Tk
package require Tktable
destroy .
exit

EOS


But should things like destroying the root window and Tcl exit really
be necessary to prevent errors during normal usage?

Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 3/16/2020 4:09 AM, Christopher Chavez wrote:

That page mentioned the Tcl exit command, which I've never used
from Perl. Adding it completely prevents the error:


     use Tcl;
     my $i = new Tcl;
     $i->Init;
     $i->Eval(<<'EOS');

     package require Tk
     package require Tktable
     destroy .
     exit

     EOS


But should things like destroying the root window and Tcl exit really
be necessary to prevent errors during normal usage?


Actually, doing $i->Eval('exit') makes the entire program exit
immediately without letting Perl continue execution or perform
its own exit, so maybe it's not a good idea to use it.

Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 3/7/2020 10:01 PM, Christopher Chavez wrote:

==17734==  Address 0x52012a0 is 8,400 bytes inside a block of size
16,384 alloc'd
==17734==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17734==    by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
==17734==    by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)

…

==17734==  Address 0x536add0 is 8,720 bytes inside a block of size
16,384 alloc'd
==17734==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==17734==    by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
==17734==    by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)
==17734==    by 0x5471A87: Tcl_Alloc (tclCkalloc.c:1059)



The addresses involved are inside allocations from Tcl's thread block
cache, which I'm guessing could be heavily reused over the life of a Tcl
program (to minimize direct calls to malloc()). I'll ask Tcl developers,
but is anyone here aware of a way to disable this or make it
debugging-friendly to identify what the last user of the block is?

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 4/7/2020 3:05 AM, Konovalov, Vadim wrote:

As a workaround, you can define this environment variable in Perl, then error 
goes away:

vad@bonita:~$ perl -MTcl -we '$ENV{FOO}="x";my $i=new Tcl;$i->Eval("set env(FOO) 
bar");print qq/ok\n/'
ok


I have not yet given this a try, but does this mean having to
first set the exact environment variable Tcl sets, or is it
that *any* environment variable needs to be set first from Perl?


Tcl uses "ckalloc" function to allocate strings for name of environment variable 
"FOO" (or a value?)
This 'ckalloc' is their helper function, which chains memory into link, so to 
free it after all.

IMO If they just use "malloc" the problem will go away.
I haven't verified this assumption, but 85%-sure of it 


Because I compiled with -DPURIFY I've already verified this won't
make a difference.

Without manually defining TCL_MEM_DEBUG, ckalloc() is Tcl_Alloc(),
and Tcl_Alloc() uses TclpAlloc() directly.
Defining PURIFY undefines USE_TCLALLOC, making TclpAlloc()
use malloc() directly.

This is evident in the valgrind stack trace I posted 2020-03-17.

Thanks
Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 3/25/2020 11:29 PM, S.J. Luo wrote:

Hi,

After further tracing around the sources, I think I've figure out the
root cause of the fault: Tcl interpreter (not Tcl.so, which is
compiled from Tcl.xs) has changed global environment variable of the
process while Perl is not aware of it.
In more detail:
1. Tcl allocated a chunk of memory space to store string 'FOO=bar'
while the code 'set env(FOO) bar' gets executed
2. Tcl modifies the global variable 'environ' (exported by glibc with
type: char**). Then it points to a pointer array with one element
points to the newly allocated string 'FOO=bar'.
3. On exiting of Perl, the destructor of the Tcl interpreter object
gets invoked. The memory chunk with string 'FOO=bar' gets freed by
Tcl. However, the global variable 'environ' still points to the same
location and is still has the element points to the address 'FOO=bar'.
4. Finally Perl thinks the strings pointed by 'environ' was allocated
by itself and calls free() on each element, where one points to string
'FOO=bar', who has already been freed...

To demo the Perl/Tcl behavior, execute

 perl -MTcl -e 'Tcl::new->Eval("set env(FOO) bar"); print
"FOO=$ENV{FOO}\n"; system("echo FOO=\$FOO");'

We get the following output before segmentation fault

 FOO=
 FOO=bar

Here Perl's $ENV{FOO} is still undefined while the true environment of
the process is practically affected because the child process inherits
'FOO=bar'.
Moreover, if we have $ENV{FOO}="bar1" after Eval("set env"), we
will get segmentation fault on it immediately, before exiting of Perl.

So far I am not able to come out a simple way to get it fixed. I think
either Tcl should not change the environment globally, or there should
be some way to inform Perl that environment variables has been
changed.

SJ



Thank you for investigating this in such great detail.


A Tcl::pTk user opened a ticket observing this issue in the
test suite: https://rt.cpan.org/Ticket/Display.html?id=132278

I had briefly looked online for previous reports of similar issues
for Tcl and Perl, and there were plenty of bug reports and improvements
submitted, often from 20+ years ago. I don't think I came across
this exact issue. But in some cases this kind of issue was deemed
expected behavior, so I wouldn't be surprised if raising this
specific issue with either Perl or Tcl today that they still consider
it to be neither new nor unexpected. For example, a program embedding
Tcl is supposed to do things like use/redefine Tcl_PutEnv()
(see https://www.tcl-lang.org/man/tcl8.6/TclLib/Environment.htm).
But this would appear to assume the program writer is/should be
in control of compiling and packaging everything in their program.
It is not possible to do this when intending for Tcl.pm reuse
existing Tcl or Perl installations, such as from package managers.
So maybe Tcl.pm will have to document this as a known issue.

Or, is there a workaround possible in the meantime?


Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 4/1/2020 7:19 AM, Konovalov, Vadim wrote:

A Tcl::pTk user opened
a ticket observing this issue in the
test suite:
https://rt.cpan.org/Ticket/Display.html?id=132278


Can you open the ticket on Tcl.pm, given that we see that it is
more relevant here?


I have moved the existing ticket to keep the reporter informed.
I meant to adjust the title as well but couldn't do so once it moved.



But this would appear to assume the program writer is/should be
in control of compiling and packaging everything in their program.
It is not possible to do this when intending for Tcl.pm reuse
existing Tcl or Perl installations, such as from package managers.


IMO linker will use your function, if you redefine it in your code > and will 
pass it sooner to linker.
So  you can "neutralize" freeing  environment variables in libtcl

IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's
environment call - what is it?
According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-functions
- this is my_setenv?


Interesting, this is something I'm not familiar with.

I have also neglected to consider if other Tcl wrappers (Python, Ruby)
are affected and whether they may have already solved the same problem.


I will work on the fix, when time permits


Thanks. Indeed there should be no rush to fix this. It is a benign issue
that might only pose a minor annoyance to users (e.g. "Your program
has crashed, report it?" nags from OS); unsaved data does not appear
to be in jeopardy because of it.


Christopher A. Chavez

Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

Here's an issue I've known about for several months but hadn't reported.
I'm curious if there are any ideas here for debugging or what the cause
might be (if obviously in Tcl.pm), or if I should go ahead and report it
to Debian package maintainers.

Christopher A. Chavez

-

Using Debian 10 buster amd64, and packages provided by Debian:

perl  5.28.1-6
tk8.6.9-2
tk-table  2.10-4 (borrowed from testing/bullseye; I can't find debug
symbols for 2.10-3)

plus Tcl.pm 1.27 (either Debian's libtcl-perl 1.27+ds-1, or from GitHub
master branch).

(I'm not sure which package might be responsible for this issue.
I believe I also observed this issue on a recent version of Ubuntu.)

Any normal usage of Tktable from Perl (e.g. with a wrapper like Tkx,
Tcl::Tk, or Tcl::pTk) will seem to work fine, but an error occurs when
the program is closed:

munmap_chunk(): invalid pointer
Aborted (core dumped)

This error does not occur when using Tktable directly from Tcl/Tk
(e.g. tclsh/wish), so I suspect the issue may be in Tcl.pm or Perl.

Example Perl script that exhibits the error:

use Tcl;
my $i = new Tcl;
$i->Init;
$i->Eval('package require Tk');
$i->Eval('package require Tktable');
$i->Eval('destroy .');

Valgrind indicates the error is due to an invalid free, but the exact
code responsible for the issue is unclear to me:

$ valgrind --num-callers=100 perl tktable-test.pl
==17734== Memcheck, a memory error detector
==17734== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17734== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==17734== Command: perl -Mblib tktable-test.pl
...
[omitting "Invalid read of size 1" error -- known behavior when Tk
is loaded, https://core.tcl-lang.org/tk/tktview?name=e42eef33ee ]
...
==17734== Invalid free() / delete / delete[] / realloc()
==17734==at 0x48369AB: free (vg_replace_malloc.c:530)
==17734==by 0x162304: perl_destruct (in /usr/bin/perl)
==17734==by 0x13C3DB: main (in /usr/bin/perl)
==17734==  Address 0x52012a0 is 8,400 bytes inside a block of size
16,384 alloc'd
==17734==at 0x483577F: malloc (vg_replace_malloc.c:299)
==17734==by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
==17734==by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)
==17734==by 0x5459272: newstate (regc_nfa.c:135)
==17734==by 0x54548B8: parseqatom (regcomp.c:1136)
==17734==by 0x5453FA3: parsebranch (regcomp.c:760)
==17734==by 0x5453DF2: parse (regcomp.c:689)
==17734==by 0x545365E: TclReComp (regcomp.c:382)
==17734==by 0x5542841: CompileRegexp (tclRegexp.c:934)
==17734==by 0x5542404: Tcl_GetRegExpFromObj (tclRegexp.c:593)
==17734==by 0x547FCF4: Tcl_RegexpObjCmd (tclCmdMZ.c:268)
==17734==by 0x5467FB6: TclNRRunCallbacks (tclBasic.c:4461)
==17734==by 0x54693AE: TclEvalEx (tclBasic.c:5330)
==17734==by 0x5468D12: Tcl_EvalEx (tclBasic.c:4995)
==17734==by 0x54078CB: XS_Tcl_Eval (Tcl.xs:1097)
==17734==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==17734==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==17734==by 0x166116: perl_run (in /usr/bin/perl)
==17734==by 0x13C401: main (in /usr/bin/perl)
==17734==
==17734== Invalid free() / delete / delete[] / realloc()
==17734==at 0x48369AB: free (vg_replace_malloc.c:530)
==17734==by 0x162322: perl_destruct (in /usr/bin/perl)
==17734==by 0x13C3DB: main (in /usr/bin/perl)
==17734==  Address 0x536add0 is 8,720 bytes inside a block of size
16,384 alloc'd
==17734==at 0x483577F: malloc (vg_replace_malloc.c:299)
==17734==by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
==17734==by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)
==17734==by 0x5471A87: Tcl_Alloc (tclCkalloc.c:1059)
==17734==by 0x5512900: AllocChannelBuffer (tclIO.c:2453)
==17734==by 0x5512900: GetInput (tclIO.c:6843)
==17734==by 0x5511B5C: DoReadChars (tclIO.c:5867)
==17734==by 0x5522605: TclNREvalFile (tclIOUtil.c:1920)
==17734==by 0x5480DE5: TclNRSourceObjCmd (tclCmdMZ.c:1013)
==17734==by 0x5467FB6: TclNRRunCallbacks (tclBasic.c:4461)
==17734==by 0x54693AE: TclEvalEx (tclBasic.c:5330)
==17734==by 0x5468D12: Tcl_EvalEx (tclBasic.c:4995)
==17734==by 0x54078CB: XS_Tcl_Eval (Tcl.xs:1097)
==17734==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==17734==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==17734==by 0x166116: perl_run (in /usr/bin/perl)
==17734==by 0x13C401: main (in /usr/bin/perl)

Re: Possible bug in Tcl.pm exposed by Tktable?

[Christopher Chavez]

On 3/16/2020 4:09 AM, Christopher Chavez wrote:

To partially answer my own question:
there are some compile-time techniques to try like -DPURIFY
https://wiki.tcl-lang.org/page/How+to+debug+memory+faults+in+Tcl+and+extensions

After build from upstream sources (Tcl/Tk core-8-6-branch and
TkTable 2.11 -- no Debian/Ubuntu Tcl/Tk packages) with -DPURIFY,
the error is revealed to be a double free. The addresses involved
correspond to strings allocated for environment variable(s)
set by Tktable (tkTableInitScript.h).

A simpler program without Tk or Tktable reveals the same issue:

use Tcl;

my $i = new Tcl;
$i->Init;
$i->Eval('set env(FOO) bar');


Command line output:

free(): double free detected in tcache 2
Aborted (core dumped)

Valgrind output:

==13666== Invalid free() / delete / delete[] / realloc()
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x162304: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666==  Address 0x5229a20 is 0 bytes inside a block of size 8 free'd
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x543EE86: TclpFree (tclAlloc.c:722)
==13666==by 0x5517935: TclFinalizeEnvironment (tclEnv.c:768)
==13666==by 0x5519268: Tcl_Finalize (tclEvent.c:1151)
==13666==by 0x485123D: XS_Tcl__Finalize (Tcl.xs:1449)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x15DF61: Perl_call_sv (in /usr/bin/perl)
==13666==by 0x160AC3: Perl_call_list (in /usr/bin/perl)
==13666==by 0x16235E: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666==  Block was alloc'd at
==13666==at 0x4837D7B: realloc (vg_replace_malloc.c:826)
==13666==by 0x543EEAA: TclpRealloc (tclAlloc.c:747)
==13666==by 0x5456E8D: Tcl_Realloc (tclCkalloc.c:1147)
==13666==by 0x55172A9: TclSetEnv (tclEnv.c:317)
==13666==by 0x5517688: EnvTraceProc (tclEnv.c:636)
==13666==by 0x55A0B69: TclCallVarTraces (tclTrace.c:2678)
==13666==by 0x55A0860: TclObjCallVarTraces (tclTrace.c:2564)
==13666==by 0x55AAFDB: TclPtrSetVarIdx (tclVar.c:2001)
==13666==by 0x55AA957: Tcl_ObjSetVar2 (tclVar.c:1770)
==13666==by 0x55AA609: Tcl_SetObjCmd (tclVar.c:1529)
==13666==by 0x544A42A: Dispatch (tclBasic.c:4456)
==13666==by 0x544A4B0: TclNRRunCallbacks (tclBasic.c:4492)
==13666==by 0x5449D83: Tcl_EvalObjv (tclBasic.c:4215)
==13666==by 0x544C1AB: TclEvalEx (tclBasic.c:5361)
==13666==by 0x544B571: Tcl_EvalEx (tclBasic.c:5026)
==13666==by 0x48525A8: XS_Tcl_Eval (Tcl.xs:1097)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x166116: perl_run (in /usr/bin/perl)
==13666==by 0x13C401: main (in /usr/bin/perl)
==13666==
==13666== Invalid free() / delete / delete[] / realloc()
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x162322: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666==  Address 0x5229810 is 0 bytes inside a block of size 376 free'd
==13666==at 0x48369AB: free (vg_replace_malloc.c:530)
==13666==by 0x543EE86: TclpFree (tclAlloc.c:722)
==13666==by 0x5517983: TclFinalizeEnvironment (tclEnv.c:776)
==13666==by 0x5519268: Tcl_Finalize (tclEvent.c:1151)
==13666==by 0x485123D: XS_Tcl__Finalize (Tcl.xs:1449)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x15DF61: Perl_call_sv (in /usr/bin/perl)
==13666==by 0x160AC3: Perl_call_list (in /usr/bin/perl)
==13666==by 0x16235E: perl_destruct (in /usr/bin/perl)
==13666==by 0x13C3DB: main (in /usr/bin/perl)
==13666==  Block was alloc'd at
==13666==at 0x483577F: malloc (vg_replace_malloc.c:299)
==13666==by 0x543EE6C: TclpAlloc (tclAlloc.c:699)
==13666==by 0x5456D99: Tcl_Alloc (tclCkalloc.c:1059)
==13666==by 0x5517074: TclSetEnv (tclEnv.c:263)
==13666==by 0x5517688: EnvTraceProc (tclEnv.c:636)
==13666==by 0x55A0B69: TclCallVarTraces (tclTrace.c:2678)
==13666==by 0x55A0860: TclObjCallVarTraces (tclTrace.c:2564)
==13666==by 0x55AAFDB: TclPtrSetVarIdx (tclVar.c:2001)
==13666==by 0x55AA957: Tcl_ObjSetVar2 (tclVar.c:1770)
==13666==by 0x55AA609: Tcl_SetObjCmd (tclVar.c:1529)
==13666==by 0x544A42A: Dispatch (tclBasic.c:4456)
==13666==by 0x544A4B0: TclNRRunCallbacks (tclBasic.c:4492)
==13666==by 0x5449D83: Tcl_EvalObjv (tclBasic.c:4215)
==13666==by 0x544C1AB: TclEvalEx (tclBasic.c:5361)
==13666==by 0x544B571: Tcl_EvalEx (tclBasic.c:5026)
==13666==by 0x48525A8: XS_Tcl_Eval (Tcl.xs:1097)
==13666==by 0x1F4360: Perl_pp_entersub (in /usr/bin/perl)
==13666==by 0x1EA685: Perl_runops_standard (in /usr/bin/perl)
==13666==by 0x166116: perl_run (in /usr/bin/perl)
=

Check Tcl/Tk using Tcl.pm from Makefile.PL?

[Christopher Chavez]

I often have multiple Tcl/Tk installations on a system for testing
purposes, and quite a few times I have accidentally specified --tclsh
for the wrong Tcl/Tk installation to Tcl::pTk, rather than whichever one
Tcl.pm is currently using.

I wonder if this could be prevented: when installing Tcl.pm dependents
(Tcl::pTk, Tcl::Tk, etc.), why not have them go through Tcl.pm to check
for Tcl/Tk versions and extensions, rather than relying on a
possibly-incorrect path to tclsh? Would it be okay for Tcl.pm dependents
to `require Tcl` from inside Makefile.PL (only when the --test-for-tk
check is requested), or is it considered universally "bad" for
Makefile.PL files to try using dependencies this way? Was there a reason
this approach was not used in the first place?


Christopher A. Chavez

Re: Trying to use Tk 8.6

[Christopher Chavez]

From: "Bill Costa"
> On MacOS 10.13.6 I have Perl 5.28 installed in /opt/local/ using
> MacPorts. This works well and no problems installing modules using
> `cpanm`. I installed ActiveState's v8.6 of Tcl which is saved to
> `/Library/Frameworks/Tcl.framework/Versions/8.6` and then installed
> Tkx. My problem is I don't know how to make Tkx use the v8.6 version
> of Tcl/Tk. Here is how I think I know that it is not.

> $ perl -MTkx -e 'print Tkx::info("patchlevel");'
> 8.5.9

> Any tips on how I can wire in the latest version of Tcl/Tk for Perl usage?


Please note that MacPorts does offer up-to-date versions of Tcl/Tk 8.6.11 and 
Tkx via the tcl, tk (+x11 and +quartz variants), and p5-tkx ports. Once 
installed, no other configuration should be necessary.

Christopher A. Chavez

Tkx 1.10, new maintainer

[Christopher Chavez]

Howdy,

I am now the maintainer of Tkx; it was put up for adoption a few months ago [1].
Thanks to PAUSE admins for their help.

I published Tkx 1.10, which will allow installation despite the known test 
failure [2].

I have set the repository and bugtracker to my fork [3].

[1] 
http://blogs.perl.org/users/neilb/2020/09/gisle-aass-cpan-distributions-are-available-for-adoption.html
[2] https://rt.cpan.org/Ticket/Display.html?id=115662
[3] https://github.com/chrstphrchvz/tkx

Christopher A. Chavez

Re: help Keyboard and Tk

[Christopher Chavez]

> All key good, but I have a problem with the key f10.
>
> I can see F10 in the consol, no problem.
> But in windows 10, f10 open the menu.


For a very long time, it has been conventional behavior for many programs on 
Windows (not just Tk) for F10 to “activate” the menu. Tk having this binding by 
default on Windows is likely for intentionally conforming to platform 
convention, so that Windows users find that pressing F10 behaves as they may 
expect it to.

Maybe someone else has a better answer about how to actually override this 
binding if desired, but I personally would avoid trying to bind to F10 on 
Windows.

Christopher A. Chavez