You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(20) |
Mar
(29) |
Apr
(10) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(59) |
Sep
(19) |
Oct
(55) |
Nov
(22) |
Dec
(40) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(71) |
Mar
(179) |
Apr
(41) |
May
(26) |
Jun
(52) |
Jul
(62) |
Aug
(19) |
Sep
(87) |
Oct
(188) |
Nov
(95) |
Dec
(30) |
| 2003 |
Jan
(83) |
Feb
(119) |
Mar
(174) |
Apr
(77) |
May
(85) |
Jun
(52) |
Jul
(67) |
Aug
(121) |
Sep
(147) |
Oct
(96) |
Nov
(89) |
Dec
(144) |
| 2004 |
Jan
(92) |
Feb
(172) |
Mar
(205) |
Apr
(201) |
May
(105) |
Jun
(42) |
Jul
(94) |
Aug
(109) |
Sep
(81) |
Oct
(59) |
Nov
(84) |
Dec
(68) |
| 2005 |
Jan
(56) |
Feb
(57) |
Mar
(183) |
Apr
(139) |
May
(131) |
Jun
(178) |
Jul
(62) |
Aug
(42) |
Sep
(95) |
Oct
(47) |
Nov
(73) |
Dec
(47) |
| 2006 |
Jan
(66) |
Feb
(31) |
Mar
(51) |
Apr
(20) |
May
(49) |
Jun
(26) |
Jul
(23) |
Aug
(65) |
Sep
(67) |
Oct
(26) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(16) |
May
(33) |
Jun
(48) |
Jul
(34) |
Aug
(7) |
Sep
(9) |
Oct
(55) |
Nov
(44) |
Dec
(73) |
| 2008 |
Jan
(37) |
Feb
(97) |
Mar
(44) |
Apr
(33) |
May
(79) |
Jun
(11) |
Jul
(66) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(12) |
Dec
(19) |
| 2009 |
Jan
(12) |
Feb
(13) |
Mar
(19) |
Apr
(30) |
May
(59) |
Jun
(22) |
Jul
(11) |
Aug
(59) |
Sep
(82) |
Oct
(25) |
Nov
(51) |
Dec
(27) |
| 2010 |
Jan
(27) |
Feb
(8) |
Mar
(29) |
Apr
(9) |
May
(39) |
Jun
(6) |
Jul
(8) |
Aug
(22) |
Sep
(33) |
Oct
(8) |
Nov
(35) |
Dec
(9) |
| 2011 |
Jan
(62) |
Feb
(19) |
Mar
(31) |
Apr
(19) |
May
(1) |
Jun
(1) |
Jul
(17) |
Aug
(10) |
Sep
(14) |
Oct
(11) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(11) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(22) |
Aug
(22) |
Sep
(30) |
Oct
(23) |
Nov
(19) |
Dec
|
| 2013 |
Jan
(6) |
Feb
(1) |
Mar
(10) |
Apr
(7) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(9) |
Oct
(14) |
Nov
(9) |
Dec
(5) |
| 2014 |
Jan
(13) |
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
(20) |
Aug
(6) |
Sep
(26) |
Oct
(25) |
Nov
(20) |
Dec
(41) |
| 2015 |
Jan
(9) |
Feb
(35) |
Mar
(9) |
Apr
(28) |
May
(20) |
Jun
(3) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
(3) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(12) |
Jun
(35) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
| 2017 |
Jan
(28) |
Feb
(14) |
Mar
(4) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(8) |
| 2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(4) |
Apr
(21) |
May
(8) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
(10) |
Nov
|
Dec
|
| 2022 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
|
From: Bohumil F. <b.f...@gm...> - 2024-01-27 15:46:31
|
Is Tcl/Tk dead on Mac OS ? |
|
From: Steve L. <st...@di...> - 2023-08-14 00:17:14
|
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 |
|
From: Aivar A. <aiv...@gm...> - 2023-08-12 21:04:04
|
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 > |
|
From: <chr...@gm...> - 2023-08-12 08:33:39
|
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 |
|
From: Aivar A. <aiv...@gm...> - 2023-08-12 07:23:55
|
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 |
|
From: Kevan H. <ha...@op...> - 2023-08-05 01:41:17
|
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 |
|
From: Uwe K. <Uwe...@gm...> - 2022-08-23 12:07:28
|
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
|
|
From: Christopher C. <chr...@gm...> - 2022-08-22 10:55:54
|
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 |
|
From: Obermeier-Tcl3D <obe...@tc...> - 2022-08-21 15:18:54
|
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 |
|
From: Uwe K. <Uwe...@gm...> - 2022-08-12 13:20:21
|
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
|
|
From: Kevin W. <kw...@co...> - 2022-02-25 20:24:44
|
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 |
|
From: Kevan H. <ha...@op...> - 2022-02-25 18:07:15
|
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 |
|
From: Aivar A. <aiv...@gm...> - 2022-02-25 12:53:15
|
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 > |
|
From: Christopher C. <chr...@gm...> - 2022-02-25 08:11:05
|
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. |
|
From: Andy C. <an...@ac...> - 2022-01-26 15:15:20
|
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 |
|
From: Kevin W. <kw...@co...> - 2021-10-27 12:49:37
|
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 |
|
From: Jasper T. <ja...@si...> - 2021-10-27 12:19:06
|
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 |
|
From: Jasper T. <ja...@si...> - 2021-10-27 11:36:08
|
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 > |
|
From: Jasper T. <ja...@si...> - 2021-10-27 11:34:31
|
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
|
|
From: Kevin W. <kw...@co...> - 2021-10-27 11:31:21
|
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 |
|
From: Jasper T. <ja...@si...> - 2021-10-27 10:16:09
|
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 |
|
From: Kevan H. <ha...@op...> - 2021-10-22 12:16:07
|
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 |
|
From: nicolas b. <sl1...@gm...> - 2021-10-21 14:46:50
|
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 > |
|
From: Jasper T. <ja...@si...> - 2021-10-21 14:37:36
|
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 > |
|
From: Kevan H. <ha...@op...> - 2021-10-21 14:00:24
|
Dear Tcl-Mac, Has anyone built TclTk for Apple M1 yet? Best, Kevan -- Kevan Hashemi, President Open Source Instruments Inc. www.opensourceinstruments.com |