tcl-mac — Q&A for Tcl on the Macintosh platform

[MACTCL] Tcl/Tk

[Bohumil F. <b.f...@gm...>]

Is Tcl/Tk dead on Mac OS ?

Re: [MACTCL] Crash when using two consecutive mainloops

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

The TCLCORE mailing list at Tcl...@li... with subscription and archive at https://sourceforge.net/projects/tcl/lists/tcl-core is probably the best

-- Steve
On 13 Aug 2023 at 5:04 AM +0800, Aivar Annamaa <aiv...@gm...>, wrote:
> Thank you!
>
> It's good to know the background of this issue. I decided to implement a work-around instead of waiting for the fix to be accepted and released.
>
> > the tcl-mac list is far less popular than it once was, and I would not recommend using it due to the likelihood of posts going unnoticed.
>
> What would you recommend instead?
>
> Best regards,
> Aivar
>
>
>
>
>
> > On Sat, Aug 12, 2023 at 11:34 AM <chr...@gm...> wrote:
> > > On 8/12/23 at 2:23 AM, Aivar Annamaa wrote:
> > >
> > > > Hi!
> > > >
> > > > My Tkinter application (using Tk 8.6.13) uses two independent windows
> > > > during first run -- if it sees the configuration file is missing, it first
> > > > presents a small window (an instance of tkinter.Tk) for collecting a couple
> > > > of user preferences, then closes it and only then presents the main window
> > > > (another tkinter.Tk).
> > > >
> > > > In Linux and Windows this works nicely, but in macOS (e.g. Intel Catalina
> > > > or Arm Ventura), when two windows are used like this, the process crashes
> > > > with segmentation fault when the user opens a menu or invokes a file dialog
> > > > in the main window. Here is the Python fault report:
> > > > https://pastebin.com/pjiCVamm and this is macOS report:
> > > > https://pastebin.com/isaNMb5V
> > > >
> > > > I've considered restarting the process after creating the configuration
> > > > file (thus using single mainloop per process), but it would be an extra
> > > > hassle.
> > > >
> > > > Any ideas how to overcome problem this without changing the overall
> > > > approach? I tried assigning different window classes for each window but it
> > > > didn't help.
> > > >
> > > > Best regards,
> > > > Aivar
> > >
> > >
> > >
> > > Hello Aivar,
> > >
> > > This crash has been reported previously, including by many Tkinter users. I posted an explanation of this crash and a proposed fix for it at
> > > https://core.tcl-lang.org/tk/info/ef5d3e29a4
> > > however it has yet to be reviewed by the Tk Aqua developers.
> > >
> > > Although some users have reported workarounds for this issue, I am not certain how reliable they actually are, or whether they apply to your use case. However, what I do know is that this issue can only occur once the first created root/main window, i.e. the first tkinter.Tk() instance, is destroyed. So the workaround I might suggest is to create only one tkinter.Tk() instance, and then use it to create additional Toplevels as needed, rather than creating new tkinter.Tk() instances.
> > >
> > > Also, as I have said to others who posted here, the tcl-mac list is far less popular than it once was, and I would not recommend using it due to the likelihood of posts going unnoticed.
> > >
> > >
> > > Hope this helps,
> > >
> > > Christopher A. Chavez
> > >
> > >
> > > _______________________________________________
> > > Tcl-mac mailing list
> > > tc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-mac
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Crash when using two consecutive mainloops

[Aivar A. <aiv...@gm...>]

Thank you!

It's good to know the background of this issue. I decided to implement a
work-around instead of waiting for the fix to be accepted and released.

the tcl-mac list is far less popular than it once was, and I would not
> recommend using it due to the likelihood of posts going unnoticed.


What would you recommend instead?

Best regards,
Aivar





On Sat, Aug 12, 2023 at 11:34 AM <chr...@gm...> wrote:

> On 8/12/23 at 2:23 AM, Aivar Annamaa wrote:
>
> > Hi!
> >
> > My Tkinter application (using Tk 8.6.13) uses two independent windows
> > during first run -- if it sees the configuration file is missing, it
> first
> > presents a small window (an instance of tkinter.Tk) for collecting a
> couple
> > of user preferences, then closes it and only then presents the main
> window
> > (another tkinter.Tk).
> >
> > In Linux and Windows this works nicely, but in macOS (e.g. Intel Catalina
> > or Arm Ventura), when two windows are used like this, the process crashes
> > with segmentation fault when the user opens a menu or invokes a file
> dialog
> > in the main window. Here is the Python fault report:
> > https://pastebin.com/pjiCVamm and this is macOS report:
> > https://pastebin.com/isaNMb5V
> >
> > I've considered restarting the process after creating the configuration
> > file (thus using single mainloop per process), but it would be an extra
> > hassle.
> >
> > Any ideas how to overcome problem this without changing the overall
> > approach? I tried assigning different window classes for each window but
> it
> > didn't help.
> >
> > Best regards,
> > Aivar
>
>
>
> Hello Aivar,
>
> This crash has been reported previously, including by many Tkinter users.
> I posted an explanation of this crash and a proposed fix for it at
> https://core.tcl-lang.org/tk/info/ef5d3e29a4
> however it has yet to be reviewed by the Tk Aqua developers.
>
> Although some users have reported workarounds for this issue, I am not
> certain how reliable they actually are, or whether they apply to your use
> case. However, what I do know is that this issue can only occur once the
> first created root/main window, i.e. the first tkinter.Tk() instance, is
> destroyed. So the workaround I might suggest is to create only one
> tkinter.Tk() instance, and then use it to create additional Toplevels as
> needed, rather than creating new tkinter.Tk() instances.
>
> Also, as I have said to others who posted here, the tcl-mac list is far
> less popular than it once was, and I would not recommend using it due to
> the likelihood of posts going unnoticed.
>
>
> Hope this helps,
>
> Christopher A. Chavez
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Crash when using two consecutive mainloops

[<chr...@gm...>]

On 8/12/23 at 2:23 AM, Aivar Annamaa wrote:

> Hi!
>
> My Tkinter application (using Tk 8.6.13) uses two independent windows
> during first run -- if it sees the configuration file is missing, it first
> presents a small window (an instance of tkinter.Tk) for collecting a couple
> of user preferences, then closes it and only then presents the main window
> (another tkinter.Tk).
>
> In Linux and Windows this works nicely, but in macOS (e.g. Intel Catalina
> or Arm Ventura), when two windows are used like this, the process crashes
> with segmentation fault when the user opens a menu or invokes a file dialog
> in the main window. Here is the Python fault report:
> https://pastebin.com/pjiCVamm and this is macOS report:
> https://pastebin.com/isaNMb5V
>
> I've considered restarting the process after creating the configuration
> file (thus using single mainloop per process), but it would be an extra
> hassle.
>
> Any ideas how to overcome problem this without changing the overall
> approach? I tried assigning different window classes for each window but it
> didn't help.
>
> Best regards,
> Aivar



Hello Aivar,

This crash has been reported previously, including by many Tkinter users. I posted an explanation of this crash and a proposed fix for it at
https://core.tcl-lang.org/tk/info/ef5d3e29a4
however it has yet to be reviewed by the Tk Aqua developers.

Although some users have reported workarounds for this issue, I am not certain how reliable they actually are, or whether they apply to your use case. However, what I do know is that this issue can only occur once the first created root/main window, i.e. the first tkinter.Tk() instance, is destroyed. So the workaround I might suggest is to create only one tkinter.Tk() instance, and then use it to create additional Toplevels as needed, rather than creating new tkinter.Tk() instances.

Also, as I have said to others who posted here, the tcl-mac list is far less popular than it once was, and I would not recommend using it due to the likelihood of posts going unnoticed.


Hope this helps,

Christopher A. Chavez

[MACTCL] Crash when using two consecutive mainloops

[Aivar A. <aiv...@gm...>]

Hi!

My Tkinter application (using Tk 8.6.13) uses two independent windows
during first run -- if it sees the configuration file is missing, it first
presents a small window (an instance of tkinter.Tk) for collecting a couple
of user preferences, then closes it and only then presents the main window
(another tkinter.Tk).

In Linux and Windows this works nicely, but in macOS (e.g. Intel Catalina
or Arm Ventura), when two windows are used like this, the process crashes
with segmentation fault when the user opens a menu or invokes a file dialog
in the main window. Here is the Python fault report:
https://pastebin.com/pjiCVamm and this is macOS report:
https://pastebin.com/isaNMb5V

I've considered restarting the process after creating the configuration
file (thus using single mainloop per process), but it would be an extra
hassle.

Any ideas how to overcome problem this without changing the overall
approach? I tried assigning different window classes for each window but it
didn't help.

Best regards,
Aivar

[MACTCL] Wish 8.7.a5 Console Behavior

[Kevan H. <ha...@op...>]

Greetings from Boston,

If there is a better place to ask this question, I am happy to ask elsewhere. But I don't know of a better place.

I just compiled TclTk 8.7.a5, producing an embedded Wish shell. It runs and opens a console. The "console" command is defined and working. But if I include any script Wish.app/Contents/Resources/Scripts/AppMain.tcl, even an empty script, Wish runs the script, refuses to open the console, and the console command is not defined. In all previous versions of TclTk, including 8.7.a3, the console command will be defined for AppMain.tcl.

I see a file:

Wish.app/Contents/Frameworks/Tk.framework/Resources/Scripts/console.tcl

But this won't run:

(Scripts) 7 % source console.tcl
invalid command name "consoleinterp"

How can I keep the console command for use in AppMain.tcl?

Best Wishes, Kevan

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

Re: [MACTCL] building universal tkImg-1.4.13

[Uwe K. <Uwe...@gm...>]

Hello Bernd, Christopher,
thank you very much for your feedback! I managed to build successfully for the x86_64 architecture.

I still did not manage building for the arm64 architecture. There are two roadblocks (I use macOS 13 Ventura Beta 5) which may both be related to the configure script not resolving the target platform correctly.

The target on Intel Mac is "x86_64-apple-darwin19.6.0“ —> works
The target on my M1 Mac is "arm64-apple-darwin22.0.0“ —> does not work —> „windows"

- my guess is the configure script cannot determine the system platform for "arm64-apple-darwin22.0.0“ and assumes „windows“ and therefore enables „-static-libgcc“ CFLAGS. This is not supported by clang and produces a fatal error. I worked araound that by commenting out the respective line in tcl.m4

- next thing is I run into arm neon errors at the link stage of libpng: (undefined symbols _png_do_expand_palette_rgb8_neon, etc…). I browsed throug the bug reports and found that in the past Linux users had reported the same issue.

@Christopher: is that fixed in the SVN revision 569 that you mentioned to me and how can I download that?

I noticed that in the various config.guess there is no mention of "arm" in the „Darwin“ section:

    *:Darwin:*:*)
	UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
	eval "$set_cc_for_build"
	if test "$UNAME_PROCESSOR" = unknown ; then
	    UNAME_PROCESSOR=powerpc
	fi
	if test "`echo "$UNAME_RELEASE" | sed -e 's/\..*//'`" -le 10 ; then
	    if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
		if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
		       (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
		       grep IS_64BIT_ARCH >/dev/null
		then
		    case $UNAME_PROCESSOR in
			i386) UNAME_PROCESSOR=x86_64 ;;
			powerpc) UNAME_PROCESSOR=powerpc64 ;;
		    esac
		fi
		# On 10.4-10.6 one might compile for PowerPC via gcc -arch ppc
		if (echo '#ifdef __POWERPC__'; echo IS_PPC; echo '#endif') | \
		       (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
		       grep IS_PPC >/dev/null
		then
		    UNAME_PROCESSOR=powerpc
		fi
	    fi
	elif test "$UNAME_PROCESSOR" = i386 ; then
	    # Avoid executing cc on OS X 10.9, as it ships with a stub
	    # that puts up a graphical alert prompting to install
	    # developer tools.  Any system running Mac OS X 10.7 or
	    # later (Darwin 11 and later) is required to have a 64-bit
	    # processor. This is not true of the ARM version of Darwin
	    # that Apple uses in portable devices.
	    UNAME_PROCESSOR=x86_64
	fi
	echo "$UNAME_PROCESSOR"-apple-darwin"$UNAME_RELEASE"
	exit ;;


I do not really understand what is going on in these scripts but I am happy to try out your suggestions and keep you informed.

best regards,
Uwe Kirschner



> On 22. Aug 2022, at 12:42, Christopher Chavez <chr...@gm...> wrote:
> 
> Sent: Friday, August 12, 2022 at 8:20 AM
> From: "Uwe Kirschner"
>> Hello Andreas,
>> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
>>  
>> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
>>  
>> 
>> In file included from tifftcl.c:29:
>> In file included from ./tifftcl.h:50:
>> In file included from ./tifftclDecls.h:37:
>> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
>> ./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
>> #include "tiffconf.h"
>>          ^~~~~~~~~~~~
>>  
>> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
>> 
>> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>>  
>> 
>> checking for tclsh... tclsh86.exe
>> checking for wish... wish86.exe
>>  
>>  
>> In the "tkImg-1.4.13“ directory I run:
>>  autoconf
>> ./genConfigureScripts.sh
>> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
>> make
>>  
>> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
>>  
>>  
>>  
>> Can you please have a look at the log-files and tell me what is going wrong?
>>  
>> Best regards,
>> Uwe
> 
> 
> Hello Uwe,
> 
> As I say to others who post here, the tcl-mac list is not as popular as it once was, and I would not recommend using it due to the likelihood of posts going unnoticed. Also, I am not aware of Andreas having worked on tkimg in quite some time; Jan Nijtmans and Paul Obermeier have been the ones maintaining it for several years.
> 
> I am not familiar with Universal builds and do not have access to an Apple Silicon Mac. However I am able to build Tcl/Tk (core-8-6-branch) and tkimg (SVN revision 569, which recently fixed building libpng on arm64) without issue on macOS 10.15 Catalina using Xcode 12.4 command line tools and the macOS 11 Big Sur SDK:
> 
> CC='xcrun --sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -r clang' \
> CFLAGS='-arch x86_64 -arch arm64' \
> ./configure …
> 
> From looking at your config.log, I do believe something is going wrong during `checking platform`:
> 
> configure:3395: checking platform
> configure:3413: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -arch x86_64 -arch arm64  conftest.c >&5
> ./configure: line 1503: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang: No such file or directory
> …
> configure:3424: checking for cygpath
> configure:3452: result: echo
> configure:3464: result: windows
> 
> I am not certain, but I believe the problem is that this step is hardcoded to use TCL_CC, and I suspect that TCL_CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang is being picked up from your tclConfig.sh. You may try overriding it as a workaround, e.g. `TCL_CC=/usr/bin/clang ./configure …`. I do not know if that is enough to allow the build to succeed for you, but if it does, then it indicates a likely issue in tclconfig rather than a Universal build issue in tkimg (I have opened a ticket in case it is the former: https://core.tcl-lang.org/tclconfig/info/c03b9df15f )
> 
> 
> Hope this helps,
> Christopher A. Chavez

Re: [MACTCL] building universal tkImg-1.4.13

[Christopher C. <chr...@gm...>]

Sent: Friday, August 12, 2022 at 8:20 AM
From: "Uwe Kirschner"
> Hello Andreas,
> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
> 
> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
> 
> 
> In file included from tifftcl.c:29:
> In file included from ./tifftcl.h:50:
> In file included from ./tifftclDecls.h:37:
> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
> ./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
> #include "tiffconf.h"
>          ^~~~~~~~~~~~
> 
> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
> 
> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>  
> 
> checking for tclsh... tclsh86.exe
> checking for wish... wish86.exe
> 
> 
> In the "tkImg-1.4.13“ directory I run:
>  autoconf
> ./genConfigureScripts.sh
> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
> make
> 
> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
> 
> 
> 
> Can you please have a look at the log-files and tell me what is going wrong?
> 
> Best regards,
> Uwe


Hello Uwe,

As I say to others who post here, the tcl-mac list is not as popular as it once was, and I would not recommend using it due to the likelihood of posts going unnoticed. Also, I am not aware of Andreas having worked on tkimg in quite some time; Jan Nijtmans and Paul Obermeier have been the ones maintaining it for several years.

I am not familiar with Universal builds and do not have access to an Apple Silicon Mac. However I am able to build Tcl/Tk (core-8-6-branch) and tkimg (SVN revision 569, which recently fixed building libpng on arm64) without issue on macOS 10.15 Catalina using Xcode 12.4 command line tools and the macOS 11 Big Sur SDK:

CC='xcrun --sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -r clang' \
CFLAGS='-arch x86_64 -arch arm64' \
./configure …

>From looking at your config.log, I do believe something is going wrong during `checking platform`:

configure:3395: checking platform
configure:3413: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -arch x86_64 -arch arm64  conftest.c >&5
./configure: line 1503: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang: No such file or directory
…
configure:3424: checking for cygpath
configure:3452: result: echo
configure:3464: result: windows

I am not certain, but I believe the problem is that this step is hardcoded to use TCL_CC, and I suspect that TCL_CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang is being picked up from your tclConfig.sh. You may try overriding it as a workaround, e.g. `TCL_CC=/usr/bin/clang ./configure …`. I do not know if that is enough to allow the build to succeed for you, but if it does, then it indicates a likely issue in tclconfig rather than a Universal build issue in tkimg (I have opened a ticket in case it is the former: https://core.tcl-lang.org/tclconfig/info/c03b9df15f )


Hope this helps,
Christopher A. Chavez

Re: [MACTCL] building universal tkImg-1.4.13

[Obermeier-Tcl3D <obe...@tc...>]

Hi Uwe,

I'm one of the tkImg developers.
Building tkImg on Intel Macs works fine for me using my BAWT framework (www.bawt.tcl3d.org).
tkImg currently does not build on ARM Macs, but a friend of mine is currently working on that issue, as I do not have access to an ARM Mac.
So stay tuned.

Regards,
Paul

Am 12.08.2022 um 15:20 schrieb Uwe Kirschner:
> Hello Andreas,
> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.
>
> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.
>
> In file included from tifftcl.c:29:
> In file included from ./tifftcl.h:50:
> In file included from ./tifftclDecls.h:37:
> In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
> *./../compat/libtiff/libtiff/tiff.h:28:10: **fatal error: **'tiffconf.h' file not found*
> #include "tiffconf.h"
> *         ^~~~~~~~~~~~*
>
> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?
>
> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.
>
> checking for tclsh... tclsh86.exe
> checking for wish... wish86.exe
>
>
> In the "tkImg-1.4.13“ directory I run:
>  autoconf
> ./genConfigureScripts.sh
> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
> make
>
> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did alipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…
>
>
>
> Can you please have a look at the log-files and tell me what is going wrong?
>
> Best regards,
> Uwe
>
>
>
>
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] building universal tkImg-1.4.13

[Uwe K. <Uwe...@gm...>]

Hello Andreas,
I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13.

I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution.

In file included from tifftcl.c:29:
In file included from ./tifftcl.h:50:
In file included from ./tifftclDecls.h:37:
In file included from ./../compat/libtiff/libtiff/tiffio.h:31:
./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found
#include "tiffconf.h"
         ^~~~~~~~~~~~

Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13?

On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized.

checking for tclsh... tclsh86.exe
checking for wish... wish86.exe


In the "tkImg-1.4.13“ directory I run:
 autoconf
./genConfigureScripts.sh
./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“
make

…but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive…



Can you please have a look at the log-files and tell me what is going wrong?

Best regards,
Uwe

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

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

On 2/25/22 12:44 PM, Kevan Hashemi wrote:
> Dear Chavez,
>
>> PS: this mailing list is not as popular as it once was. I would 
>> personally not recommend using it due to the likelihood of posts 
>> being ignored.
>
> Where else can one report MacOS Tcl issues?
>
> Best Wishes, Kevan
>
You can open a ticket at the core Tcl/Tk development site. Here is the 
site for Tk:

https://core.tcl-lang.org/tk/timeline?y=ci

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

[Kevan H. <ha...@op...>]

Dear Chavez,

> PS: this mailing list is not as popular as it once was. I would personally not recommend using it due to the likelihood of posts being ignored.

Where else can one report MacOS Tcl issues?

Best Wishes, Kevan

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

[Aivar A. <aiv...@gm...>]

A similar issue was discussed at https://bugs.python.org/issue43511 and
https://core.tcl-lang.org/tk/tktview/f642d7c0f4

Best regards
Aivar

On Fri, Feb 25, 2022 at 10:11 AM Christopher Chavez <chr...@gm...>
wrote:

> Sent: Wednesday, January 26, 2022 at 8:19 AM
> From: "Andy Colebourne"
>
> > Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are
> now very slow to update.
>
> > Is this fixed in the core branch and, if so, how do I download that?
> >
> > Thanks,
> >
> > Andy
>
>
> Hi Andy,
>
> As another Tk Aqua user, I want to say that your issue has not been fixed
> on a development branch, but I do not have enough information to say with
> certainty. There have not been issues strongly resembling yours reported—at
> least on the issue tracker (https://core.tcl-lang.org/tk/ticket)—and so
> it is likely not understood well enough for Tk Aqua developers to act on.
> It would greatly help if you could provide example code exhibiting the
> issue.
>
>
> Christopher A. Chavez
>
>
> PS: this mailing list is not as popular as it once was. I would personally
> not recommend using it due to the likelihood of posts being ignored.
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] very slow widget config/update problem with tk 8.6.12

[Christopher C. <chr...@gm...>]

Sent: Wednesday, January 26, 2022 at 8:19 AM
From: "Andy Colebourne"

> Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are now very slow to update.

> Is this fixed in the core branch and, if so, how do I download that?
> 
> Thanks,
> 
> Andy


Hi Andy,

As another Tk Aqua user, I want to say that your issue has not been fixed on a development branch, but I do not have enough information to say with certainty. There have not been issues strongly resembling yours reported—at least on the issue tracker (https://core.tcl-lang.org/tk/ticket)—and so it is likely not understood well enough for Tk Aqua developers to act on. It would greatly help if you could provide example code exhibiting the issue.


Christopher A. Chavez


PS: this mailing list is not as popular as it once was. I would personally not recommend using it due to the likelihood of posts being ignored.

[MACTCL] very slow widget config/update problem with tk 8.6.12

[Andy C. <an...@ac...>]

Moving from 8.6.10 to 8.6.12 and discovered that my folding widgets are now
very slow to update.

 

Illustrated here:

 

http://inivis.com/external/foldingprob.mov

 

The UI on the right (fuzzy low-res) is compiled with 8.6.10 - speed is fine.
The UI on the left is 8.6.12 - very slow to update.

 

Is this fixed in the core branch and, if so, how do I download that?

 

Thanks,

 

Andy

 

Re: [MACTCL] Opening app by double-clicking or dragging file

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

On 10/27/21 8:18 AM, Jasper Taylor wrote:
> Thanks Kevin, have updated to latest core-8-6-branch and all is working!
> —Jasper
>
Great, glad it helped!

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Thanks Kevin, have updated to latest core-8-6-branch and all is working! 
	—Jasper

> On 27 Oct 2021, at 12:12, Kevin Walzer <kw...@co...> wrote:
> 
> Hi Jasper,
> 
> On 10/27/21 6:15 AM, Jasper Taylor wrote:
>> Hi MacTclers,
>> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
>> 
>> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
>> 
>> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
>> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
>> Any help very much appreciated!
>> 	—Jasper
> 
> This bug was reported on the list last spring, and I committed a fix in 830e5b70 - it probably hasn't made it into a new Tcl/Tk release yet. Can you try building the tip of core-8-6-branch? It should address the issue. 
> 
> Thanks,
> 
> Kevin  
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com <http://www.codebykevin.com/>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

I’m sorry everyone, this was a red herring. All this change seems to have done is stop the app getting tried at all, resulting in an older version of the app being tried instead, which has the original Info.plist. The only reason I can think of why the older version works OK is that it is built for x86-64 while the newer one is combined x86-64 and arm64. Also the older one uses TclTk 8.6.10 whereas the newer one is TclTk 8.6.11. My machine is arm64. Well, nothing on the Mac is ever easy…
	—Jasper

> On 27 Oct 2021, at 12:17, Jasper Taylor <ja...@si...> wrote:
> 
> Have fixed this by including these lines in the Info.plist under CFBundleDocumentTypes:
> 
>                         <key>LSHandlerRank</key>
>                         <string>Owner</string>
>                         <key>LSItemContentTypes</key>
>                         <array>
>                           <string>public.data</string>
>                         </array>
> 
>> On 27 Oct 2021, at 11:15, Jasper Taylor <ja...@si... <mailto:ja...@si...>> wrote:
>> 
>> Hi MacTclers,
>> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
>> 
>> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
>> 
>> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
>> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
>> Any help very much appreciated!
>> 	—Jasper
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li... <mailto:tc...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Re: [MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Have fixed this by including these lines in the Info.plist under CFBundleDocumentTypes:

                        <key>LSHandlerRank</key>
                        <string>Owner</string>
                        <key>LSItemContentTypes</key>
                        <array>
                          <string>public.data</string>
                        </array>

> On 27 Oct 2021, at 11:15, Jasper Taylor <ja...@si...> wrote:
> 
> Hi MacTclers,
> I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:
> 
> The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.
> 
> The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
> I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
> Any help very much appreciated!
> 	—Jasper
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Opening app by double-clicking or dragging file

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

Hi Jasper,

On 10/27/21 6:15 AM, Jasper Taylor wrote:
> Hi MacTclers,
> I have a long standing problem that if I double click a file that is 
> handled by my app, or if I drag it to the app’s icon, I get an error 
> message like this:
>
> *The document “posning.sml” could not be opened. Simile cannot open 
> files in the “com.Simulistics.sml” format.*
> *
> *
> The app then opens without opening the document. However, if I do the 
> same thing when the app is already running, the app’s 
> tk::mac::OpenDocument procedure is called and the document opens. I 
> also have tk::mac::OpenApplication and tk::mac::ReopenApplication 
> defined, but neither are called in the first case.
> I enabled the ‘com.apple.security.authorization.apple-events’ key when 
> signing the code, but this does not seem to change anything.
> Any help very much appreciated!
> —Jasper


This bug was reported on the list last spring, and I committed a fix in 
830e5b70 - it probably hasn't made it into a new Tcl/Tk release yet. Can 
you try building the tip of core-8-6-branch? It should address the issue.

Thanks,

Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] Opening app by double-clicking or dragging file

[Jasper T. <ja...@si...>]

Hi MacTclers,
I have a long standing problem that if I double click a file that is handled by my app, or if I drag it to the app’s icon, I get an error message like this:

The document “posning.sml” could not be opened. Simile cannot open files in the “com.Simulistics.sml” format.

The app then opens without opening the document. However, if I do the same thing when the app is already running, the app’s tk::mac::OpenDocument procedure is called and the document opens. I also have tk::mac::OpenApplication and tk::mac::ReopenApplication defined, but neither are called in the first case.
I enabled the ‘com.apple.security.authorization.apple-events’ key when signing the code, but this does not seem to change anything.
Any help very much appreciated!
	—Jasper

Re: [MACTCL] Apple M1 Build

[Kevan H. <ha...@op...>]

Jasper and Nocolas: thank you, that's great news. Best Wishes, Kevan

On 10/21/21 10:46 AM, nicolas bats wrote:
> Yes
> And with mac_styles_87 branch,  CPU usage of my app is reduced about 20% compared to Intel CPU.
> 
> ++
> 
> Le jeu. 21 oct. 2021 à 16:38, Jasper Taylor <ja...@si... <mailto:ja...@si...>> a écrit :
> 
>     Yes I have
> 
>           --Jasper
> 
>     On 21/10/2021 14:45, Kevan Hashemi wrote:
>      > Dear Tcl-Mac,
>      >
>      > Has anyone built TclTk for Apple M1 yet?
>      >
>      > Best, Kevan
>      >
> 
> 
>     _______________________________________________
>     Tcl-mac mailing list
>     tc...@li... <mailto:tc...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tcl-mac <https://lists.sourceforge.net/lists/listinfo/tcl-mac>
> 
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com

Re: [MACTCL] Apple M1 Build

[nicolas b. <sl1...@gm...>]

Yes
And with mac_styles_87 branch,  CPU usage of my app is reduced about 20%
compared to Intel CPU.

++

Le jeu. 21 oct. 2021 à 16:38, Jasper Taylor <ja...@si...> a
écrit :

> Yes I have
>
>      --Jasper
>
> On 21/10/2021 14:45, Kevan Hashemi wrote:
> > Dear Tcl-Mac,
> >
> > Has anyone built TclTk for Apple M1 yet?
> >
> > Best, Kevan
> >
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Apple M1 Build

[Jasper T. <ja...@si...>]

Yes I have

     --Jasper

On 21/10/2021 14:45, Kevan Hashemi wrote:
> Dear Tcl-Mac,
>
> Has anyone built TclTk for Apple M1 yet?
>
> Best, Kevan
>

[MACTCL] Apple M1 Build

[Kevan H. <ha...@op...>]

Dear Tcl-Mac,

Has anyone built TclTk for Apple M1 yet?

Best, Kevan

-- 
Kevan Hashemi, President
Open Source Instruments Inc.
www.opensourceinstruments.com