Menu
▾
▴
tcl-mac — Q&A for Tcl on the Macintosh platform
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
|
|
From: Obermeier-Tcl3D <obe...@tc...> - 2024-09-14 17:08:02
|
Hi Richard,
the warnings you get are OK.
I also get the 2 failing tests, but these are only because the Tk error message has changed slightly ("type" was removed):
---- Result was:
1 {bad relief "1.5": must be flat, groove, raised, ridge, solid, or sunken}
---- Result should have been (exact matching):
1 {bad relief type "1.5": must be flat, groove, raised, ridge, solid, or sunken}
Running the demos works on my MacBook Air (M2, latest Sonoma).
Have you tried running some of the demos directly, ex. "tclsh debug.tcl"?
Best regards,
Paul
Am 12.09.2024 um 23:56 schrieb Friedman, Richard A.:
>
> Dear Paul,
>
> Thank you for the flag. It helped matters, but there still seem to be some problems. I do not know if you can help with this considering that Tktable is no longer supported, but here is the info in case you can help.
>
> ```
>
> sudo CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure
>
> .
>
> .
>
> .
>
> config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
>
> .
>
> .
>
> .
>
> *./generic/tkTable.c:164:52: warning: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]*
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> .
>
> .
>
> .
>
> *./generic/tkTableCellSort.c:73:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]*
>
> TableSortCompareProc(first, second)
>
> *^*
>
> .
>
> .
>
> .
>
> *./generic/tkTableCmds.c:186:14: warning: cast to smaller integer type 'int' from 'void *' [-Wvoid-pointer-to-int-cast]*
>
> posn = ((int) Tcl_GetHashKey(hashTablePtr, entryPtr)) + offset;
>
> *^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
>
> .
>
> .
>
> .
>
> *./generic/tkTableUtil.c:73:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]*
>
> TableOptionBdSet(clientData, interp, tkwin, value, widgRec, offset)
>
> ```
>
> No errors. Just warnings
>
> ```
>
> raf4$ make test
>
> .
>
> .
>
> .
>
> ==== table-1.92 configuration options, -relief FAILED
>
> ==== Contents of test case:
>
> list [catch {.t configure $name [lindex $test 3]} msg] $msg
>
> ---- Result was:
>
> 1 {bad relief "1.5": must be flat, groove, raised, ridge, solid, or sunken}
>
> ---- Result should have been (exact matching):
>
> .
>
> .
>
> .Tests ended at Thu Sep 12 17:35:57 EDT 2024
>
> all.tcl: Total 225 Passed 223 Skipped 0 Failed 2
>
> $make demo
>
> TCL_LIBRARY=`echo /private/tmp/tcl-tk-20240229-4610-gcj7fw/tcl8.6.14/library` TK_LIBRARY=`echo /private/tmp/tcl-tk--tk-20240229-4610-xewyz9/tk8.6.14/library` DYLD_LIBRARY_PATH=".:/usr/local/lib:/usr/local/lib:" PATH=".:/usr/local/lib:/usr/local/lib:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/gfortran/bin:/Applications/samtools-1.17/bin:/Applications:/Users/raf4/opt/anaconda3/bin:/Users/raf4/opt/anaconda3/condabin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/bowtie/bowtie2-2.5.1-macos-x86_64:/Applications/bismark/Bismark-0.24.1:/opt/local/bin/bedtools:/usr/local/bin/R:/opt/local/bin:/opt/local/libexec/meme-5.5.5:." TCLLIBPATH="." /usr/local/bin/wish8.6 `echo ./demos/debug.tcl` | cat
>
> Tktable v2.11 loaded
>
> Table is .t with array t
>
> ```
>
> Seems to have worked fine and produced a table, but I also got a popup that said “wish 8.6 quit unexpectedly”
>
> ```
>
> #make install
>
> ```
>
> No error messages.
>
> I would apprciate any suggestions.
>
> Thanks and best wishes,
>
> Rich
>
> *From: *Obermeier-Tcl3D <obe...@tc...>
> *Date: *Wednesday, September 11, 2024 at 6:44 PM
> *To: *tc...@li... <tc...@li...>
> *Subject: *Re: [MACTCL] [EXTERNAL] Re: Problem compiling TkTable on Mac OS 14.6.1 Sonoma
>
>
>
>
> You don't often get email from obe...@tc.... Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> Sorry Richard.
>
> Forgot to mention, that you have to lower the strictness of gcc.
> Since gcc 14 several issues, which have been just warnings before, are now errors.
>
> You can work around the strictness by specifying the following options when running configure:
>
> CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure ...
>
> Regards,
> Paul
>
> Am 11.09.2024 um 20:32 schrieb Friedman, Richard A.:
>
> Dear Paul,
>
> I downloaded Tktable 2.11 and still got the same error message when I used make
>
> ```
>
> (base) icrc8cc-n004:Tktable-2.11 raf4$ make
>
> sed -e '/^\#/d' -e '/^$/d' -e 's/\\/\\\\/g' -e 's/\"/\\"/g' -e 's/^/"/' -e 's/$/\\n"/' < `echo library/tkTable.tcl` > 'tkTable.tcl.h' || { rm -f tkTable.tcl.h; exit 1; }
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.11\" -DPACKAGE_STRING=\"Tktable\ 2.11\" -DPACKAGE_BUGREPORT=\"\" -DBUILD_Tktable=/\*\*/ -DMAC_OSX_TK=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.11\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> *./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]*
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> ```
>
> I have not used table list. I am not a Tcl programmer. I am installing Tktable because an R program, affylmGUI requires it to run on a Mac. The program has worked very with previous versions of R and Mac OS, bit is running into trouble here.
>
> I would appreciate any further suggestions.
>
> Thanks and best wishes,
>
> Rich
>
> *From: *Obermeier-Tcl3D <obe...@tc...> <mailto:obe...@tc...>
> *Date: *Tuesday, September 10, 2024 at 7:22 PM
> *To: *tc...@li... <tc...@li...> <mailto:tc...@li...>
> *Subject: *[EXTERNAL] Re: [MACTCL] Problem compiling TkTable on Mac OS 14.6.1 Sonoma
>
>
>
>
> You don't often get email from obe...@tc.... Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> Dear Richard,
>
> please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages
> It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/
> Please note, that Tktable is not supported or developed anymore.
>
> Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)?
> I switched all previous usages of Tktable to tablelist.
>
> Regards,
> Paul
>
> Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.:
>
> Dear List,
>
> I need TkTable working to run the R program, affylmGUI.
>
> I am trying to compile it under Mac OS 14.16.1.
>
> I have Tcl8.6.14 installed in /usr/local/bin/ .
>
> I installed Tcl8.6.14 with homebrew.
>
> Here is my attempt at compiling Tktable
>
> ```
>
> $ pwd
>
> /usr/local/lib/Tktable2.10
>
> $ sudo make
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> .
>
> .
>
> ,
>
> $ sudo make install
>
> Password:
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> .
>
> .
>
> .
>
> ```
>
> Note the error message.
>
> I have been able to install TkTable in previous versions of Mac OS.
>
> Please advise.
>
> Thank you,
>
> Richard Friedman
>
> Bioinformatics Core
>
> Herbert Irving Comprehensive Cancer Center
>
> Columbia University Irving Medical Center
>
>
>
> _______________________________________________
>
> 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
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Friedman, R. A. <ra...@cu...> - 2024-09-13 02:12:18
|
Dear Paul, Thank you for the From: Obermeier-Tcl3D <obe...@tc...> Date: Wednesday, September 11, 2024 at 6:44 PM To: tc...@li... <tc...@li...> Subject: Re: [MACTCL] [EXTERNAL] Re: Problem compiling TkTable on Mac OS 14.6.1 Sonoma You don't often get email from obe...@tc.... Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Sorry Richard. Forgot to mention, that you have to lower the strictness of gcc. Since gcc 14 several issues, which have been just warnings before, are now errors. You can work around the strictness by specifying the following options when running configure: CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure ... Regards, Paul Am 11.09.2024 um 20:32 schrieb Friedman, Richard A.: Dear Paul, I downloaded Tktable 2.11 and still got the same error message when I used make ``` (base) icrc8cc-n004:Tktable-2.11 raf4$ make sed -e '/^\#/d' -e '/^$/d' -e 's/\\/\\\\/g' -e 's/\"/\\"/g' -e 's/^/"/' -e 's/$/\\n"/' < `echo library/tkTable.tcl` > 'tkTable.tcl.h' || { rm -f tkTable.tcl.h; exit 1; } gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.11\" -DPACKAGE_STRING=\"Tktable\ 2.11\" -DPACKAGE_BUGREPORT=\"\" -DBUILD_Tktable=/\*\*/ -DMAC_OSX_TK=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.11\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types] static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet, ``` I have not used table list. I am not a Tcl programmer. I am installing Tktable because an R program, affylmGUI requires it to run on a Mac. The program has worked very with previous versions of R and Mac OS, bit is running into trouble here. I would appreciate any further suggestions. Thanks and best wishes, Rich From: Obermeier-Tcl3D <obe...@tc...><mailto:obe...@tc...> Date: Tuesday, September 10, 2024 at 7:22 PM To: tc...@li...<mailto:tc...@li...> <tc...@li...><mailto:tc...@li...> Subject: [EXTERNAL] Re: [MACTCL] Problem compiling TkTable on Mac OS 14.6.1 Sonoma You don't often get email from obe...@tc...<mailto:obe...@tc...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Dear Richard, please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/ Please note, that Tktable is not supported or developed anymore. Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)? I switched all previous usages of Tktable to tablelist. Regards, Paul Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.: Dear List, I need TkTable working to run the R program, affylmGUI. I am trying to compile it under Mac OS 14.16.1. I have Tcl8.6.14 installed in /usr/local/bin/ . I installed Tcl8.6.14 with homebrew. Here is my attempt at compiling Tktable ``` $ pwd /usr/local/lib/Tktable2.10 $ sudo make gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types] static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet, . . , $ sudo make install Password: gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types] static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet, . . . ``` Note the error message. I have been able to install TkTable in previous versions of Mac OS. Please advise. Thank you, Richard Friedman Bioinformatics Core Herbert Irving Comprehensive Cancer Center Columbia University Irving Medical Center _______________________________________________ Tcl-mac mailing list tc...@li...<mailto:tc...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-mac _______________________________________________ Tcl-mac mailing list tc...@li...<mailto:tc...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Friedman, R. A. <ra...@cu...> - 2024-09-12 22:11:08
|
Dear Paul,
Thank you for the flag. It helped matters, but there still seem to be some problems. I do not know if you can help with this considering that Tktable is no longer supported, but here is the info in case you can help.
```
sudo CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure
.
.
.
config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
.
.
.
./generic/tkTable.c:164:52: warning: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
.
./generic/tkTableCellSort.c:73:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
TableSortCompareProc(first, second)
^
.
.
.
./generic/tkTableCmds.c:186:14: warning: cast to smaller integer type 'int' from 'void *' [-Wvoid-pointer-to-int-cast]
posn = ((int) Tcl_GetHashKey(hashTablePtr, entryPtr)) + offset;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.
.
.
./generic/tkTableUtil.c:73:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
TableOptionBdSet(clientData, interp, tkwin, value, widgRec, offset)
```
No errors. Just warnings
```
raf4$ make test
.
.
.
==== table-1.92 configuration options, -relief FAILED
==== Contents of test case:
list [catch {.t configure $name [lindex $test 3]} msg] $msg
---- Result was:
1 {bad relief "1.5": must be flat, groove, raised, ridge, solid, or sunken}
---- Result should have been (exact matching):
.
.
. Tests ended at Thu Sep 12 17:35:57 EDT 2024
all.tcl: Total 225 Passed 223 Skipped 0 Failed 2
$make demo
TCL_LIBRARY=`echo /private/tmp/tcl-tk-20240229-4610-gcj7fw/tcl8.6.14/library` TK_LIBRARY=`echo /private/tmp/tcl-tk--tk-20240229-4610-xewyz9/tk8.6.14/library` DYLD_LIBRARY_PATH=".:/usr/local/lib:/usr/local/lib:" PATH=".:/usr/local/lib:/usr/local/lib:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/gfortran/bin:/Applications/samtools-1.17/bin:/Applications:/Users/raf4/opt/anaconda3/bin:/Users/raf4/opt/anaconda3/condabin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/bowtie/bowtie2-2.5.1-macos-x86_64:/Applications/bismark/Bismark-0.24.1:/opt/local/bin/bedtools:/usr/local/bin/R:/opt/local/bin:/opt/local/libexec/meme-5.5.5:." TCLLIBPATH="." /usr/local/bin/wish8.6 `echo ./demos/debug.tcl` | cat
Tktable v2.11 loaded
Table is .t with array t
```
Seems to have worked fine and produced a table, but I also got a popup that said “wish 8.6 quit unexpectedly”
```
#make install
```
No error messages.
I would apprciate any suggestions.
Thanks and best wishes,
Rich
From: Obermeier-Tcl3D <obe...@tc...>
Date: Wednesday, September 11, 2024 at 6:44 PM
To: tc...@li... <tc...@li...>
Subject: Re: [MACTCL] [EXTERNAL] Re: Problem compiling TkTable on Mac OS 14.6.1 Sonoma
You don't often get email from obe...@tc.... Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Sorry Richard.
Forgot to mention, that you have to lower the strictness of gcc.
Since gcc 14 several issues, which have been just warnings before, are now errors.
You can work around the strictness by specifying the following options when running configure:
CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure ...
Regards,
Paul
Am 11.09.2024 um 20:32 schrieb Friedman, Richard A.:
Dear Paul,
I downloaded Tktable 2.11 and still got the same error message when I used make
```
(base) icrc8cc-n004:Tktable-2.11 raf4$ make
sed -e '/^\#/d' -e '/^$/d' -e 's/\\/\\\\/g' -e 's/\"/\\"/g' -e 's/^/"/' -e 's/$/\\n"/' < `echo library/tkTable.tcl` > 'tkTable.tcl.h' || { rm -f tkTable.tcl.h; exit 1; }
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.11\" -DPACKAGE_STRING=\"Tktable\ 2.11\" -DPACKAGE_BUGREPORT=\"\" -DBUILD_Tktable=/\*\*/ -DMAC_OSX_TK=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.11\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
```
I have not used table list. I am not a Tcl programmer. I am installing Tktable because an R program, affylmGUI requires it to run on a Mac. The program has worked very with previous versions of R and Mac OS, bit is running into trouble here.
I would appreciate any further suggestions.
Thanks and best wishes,
Rich
From: Obermeier-Tcl3D <obe...@tc...><mailto:obe...@tc...>
Date: Tuesday, September 10, 2024 at 7:22 PM
To: tc...@li...<mailto:tc...@li...> <tc...@li...><mailto:tc...@li...>
Subject: [EXTERNAL] Re: [MACTCL] Problem compiling TkTable on Mac OS 14.6.1 Sonoma
You don't often get email from obe...@tc...<mailto:obe...@tc...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Dear Richard,
please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages
It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/
Please note, that Tktable is not supported or developed anymore.
Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)?
I switched all previous usages of Tktable to tablelist.
Regards,
Paul
Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.:
Dear List,
I need TkTable working to run the R program, affylmGUI.
I am trying to compile it under Mac OS 14.16.1.
I have Tcl8.6.14 installed in /usr/local/bin/ .
I installed Tcl8.6.14 with homebrew.
Here is my attempt at compiling Tktable
```
$ pwd
/usr/local/lib/Tktable2.10
$ sudo make
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
,
$ sudo make install
Password:
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
.
```
Note the error message.
I have been able to install TkTable in previous versions of Mac OS.
Please advise.
Thank you,
Richard Friedman
Bioinformatics Core
Herbert Irving Comprehensive Cancer Center
Columbia University Irving Medical Center
_______________________________________________
Tcl-mac mailing list
tc...@li...<mailto:tc...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-mac
_______________________________________________
Tcl-mac mailing list
tc...@li...<mailto:tc...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Obermeier-Tcl3D <obe...@tc...> - 2024-09-11 22:43:44
|
Sorry Richard.
Forgot to mention, that you have to lower the strictness of gcc.
Since gcc 14 several issues, which have been just warnings before, are now errors.
You can work around the strictness by specifying the following options when running configure:
CFLAGS='-fpermissive -Wno-error=incompatible-function-pointer-types' configure ...
Regards,
Paul
Am 11.09.2024 um 20:32 schrieb Friedman, Richard A.:
>
> Dear Paul,
>
> I downloaded Tktable 2.11 and still got the same error message when I used make
>
> ```
>
> (base) icrc8cc-n004:Tktable-2.11 raf4$ make
>
> sed -e '/^\#/d' -e '/^$/d' -e 's/\\/\\\\/g' -e 's/\"/\\"/g' -e 's/^/"/' -e 's/$/\\n"/' < `echo library/tkTable.tcl` > 'tkTable.tcl.h' || { rm -f tkTable.tcl.h; exit 1; }
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.11\" -DPACKAGE_STRING=\"Tktable\ 2.11\" -DPACKAGE_BUGREPORT=\"\" -DBUILD_Tktable=/\*\*/ -DMAC_OSX_TK=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.11\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> *./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]*
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> ```
>
> I have not used table list. I am not a Tcl programmer. I am installing Tktable because an R program, affylmGUI requires it to run on a Mac. The program has worked very with previous versions of R and Mac OS, bit is running into trouble here.
>
> I would appreciate any further suggestions.
>
> Thanks and best wishes,
>
> Rich
>
> *From: *Obermeier-Tcl3D <obe...@tc...>
> *Date: *Tuesday, September 10, 2024 at 7:22 PM
> *To: *tc...@li... <tc...@li...>
> *Subject: *[EXTERNAL] Re: [MACTCL] Problem compiling TkTable on Mac OS 14.6.1 Sonoma
>
>
>
>
> You don't often get email from obe...@tc.... Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> Dear Richard,
>
> please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages
> It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/
> Please note, that Tktable is not supported or developed anymore.
>
> Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)?
> I switched all previous usages of Tktable to tablelist.
>
> Regards,
> Paul
>
> Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.:
>
> Dear List,
>
> I need TkTable working to run the R program, affylmGUI.
>
> I am trying to compile it under Mac OS 14.16.1.
>
> I have Tcl8.6.14 installed in /usr/local/bin/ .
>
> I installed Tcl8.6.14 with homebrew.
>
> Here is my attempt at compiling Tktable
>
> ```
>
> $ pwd
>
> /usr/local/lib/Tktable2.10
>
> $ sudo make
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> .
>
> .
>
> ,
>
> $ sudo make install
>
> Password:
>
> gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
>
> ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
>
> static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
>
> .
>
> .
>
> .
>
> ```
>
> Note the error message.
>
> I have been able to install TkTable in previous versions of Mac OS.
>
> Please advise.
>
> Thank you,
>
> Richard Friedman
>
> Bioinformatics Core
>
> Herbert Irving Comprehensive Cancer Center
>
> Columbia University Irving Medical Center
>
>
>
>
> _______________________________________________
>
> 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: Friedman, R. A. <ra...@cu...> - 2024-09-11 21:06:10
|
Dear Paul,
I downloaded Tktable 2.11 and still got the same error message when I used make
```
(base) icrc8cc-n004:Tktable-2.11 raf4$ make
sed -e '/^\#/d' -e '/^$/d' -e 's/\\/\\\\/g' -e 's/\"/\\"/g' -e 's/^/"/' -e 's/$/\\n"/' < `echo library/tkTable.tcl` > 'tkTable.tcl.h' || { rm -f tkTable.tcl.h; exit 1; }
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.11\" -DPACKAGE_STRING=\"Tktable\ 2.11\" -DPACKAGE_BUGREPORT=\"\" -DBUILD_Tktable=/\*\*/ -DMAC_OSX_TK=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.11\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
```
I have not used table list. I am not a Tcl programmer. I am installing Tktable because an R program, affylmGUI requires it to run on a Mac. The program has worked very with previous versions of R and Mac OS, bit is running into trouble here.
I would appreciate any further suggestions.
Thanks and best wishes,
Rich
From: Obermeier-Tcl3D <obe...@tc...>
Date: Tuesday, September 10, 2024 at 7:22 PM
To: tc...@li... <tc...@li...>
Subject: [EXTERNAL] Re: [MACTCL] Problem compiling TkTable on Mac OS 14.6.1 Sonoma
You don't often get email from obe...@tc.... Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Dear Richard,
please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages
It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/
Please note, that Tktable is not supported or developed anymore.
Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)?
I switched all previous usages of Tktable to tablelist.
Regards,
Paul
Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.:
Dear List,
I need TkTable working to run the R program, affylmGUI.
I am trying to compile it under Mac OS 14.16.1.
I have Tcl8.6.14 installed in /usr/local/bin/ .
I installed Tcl8.6.14 with homebrew.
Here is my attempt at compiling Tktable
```
$ pwd
/usr/local/lib/Tktable2.10
$ sudo make
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
,
$ sudo make install
Password:
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
.
```
Note the error message.
I have been able to install TkTable in previous versions of Mac OS.
Please advise.
Thank you,
Richard Friedman
Bioinformatics Core
Herbert Irving Comprehensive Cancer Center
Columbia University Irving Medical Center
_______________________________________________
Tcl-mac mailing list
tc...@li...<mailto:tc...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Obermeier-Tcl3D <obe...@tc...> - 2024-09-10 23:21:47
|
Dear Richard, please try my Tktable 2.11 version, which can be found at https://www.tcl3d.org/bawt/download.html#packages It is a slightly modified (Mac related) version of Tktable as supplied at https://chiselapp.com/user/pooryorick/repository/tktable/ Please note, that Tktable is not supported or developed anymore. Do you know package tablelist (https://wiki.tcl-lang.org/page/tablelist)? I switched all previous usages of Tktable to tablelist. Regards, Paul Am 10.09.2024 um 21:48 schrieb Friedman, Richard A.: > > Dear List, > > I need TkTable working to run the R program, affylmGUI. > > I am trying to compile it under Mac OS 14.16.1. > > I have Tcl8.6.14 installed in /usr/local/bin/ . > > I installed Tcl8.6.14 with homebrew. > > Here is my attempt at compiling Tktable > > ``` > > $ pwd > > /usr/local/lib/Tktable2.10 > > $ sudo make > > gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o > > ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types] > > static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet, > > . > > . > > , > > $ sudo make install > > Password: > > gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o > > ./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types] > > static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet, > > . > > . > > . > > ``` > > Note the error message. > > I have been able to install TkTable in previous versions of Mac OS. > > Please advise. > > Thank you, > > Richard Friedman > > Bioinformatics Core > > Herbert Irving Comprehensive Cancer Center > > Columbia University Irving Medical Center > > > > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Friedman, R. A. <ra...@cu...> - 2024-09-10 21:20:47
|
Dear List,
I need TkTable working to run the R program, affylmGUI.
I am trying to compile it under Mac OS 14.16.1.
I have Tcl8.6.14 installed in /usr/local/bin/ .
I installed Tcl8.6.14 with homebrew.
Here is my attempt at compiling Tktable
```
$ pwd
/usr/local/lib/Tktable2.10
$ sudo make
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
,
$ sudo make install
Password:
gcc -DPACKAGE_NAME=\"Tktable\" -DPACKAGE_TARNAME=\"tktable\" -DPACKAGE_VERSION=\"2.10\" -DPACKAGE_STRING=\"Tktable\ 2.10\" -DPACKAGE_BUGREPORT=\"\" -DMAC_OSX_TK=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -DTBL_COMMAND=\"table\" -DTBL_RUNTIME=\"tkTable.tcl\" -DTBL_RUNTIME_DIR=\"/usr/local/Cellar/tcl-tk/8.6.14/lib/Tktable2.10\" -I. -I"./generic" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -I"/usr/local/Cellar/tcl-tk/8.6.14/include/tcl-tk" -pipe -Os -Wall -Wno-implicit-int -fno-common -c `echo ./generic/tkTable.c` -o tkTable.o
./generic/tkTable.c:164:52: error: incompatible function pointer types initializing 'Tk_OptionPrintProc *' (aka 'const char *(*)(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') with an expression of type 'char *(ClientData, Tk_Window, char *, int, Tcl_FreeProc **)' (aka 'char *(void *, struct Tk_Window_ *, char *, int, void (**)(char *))') [-Wincompatible-function-pointer-types]
static Tk_CustomOption drawOpt = { Cmd_OptionSet, Cmd_OptionGet,
.
.
.
```
Note the error message.
I have been able to install TkTable in previous versions of Mac OS.
Please advise.
Thank you,
Richard Friedman
Bioinformatics Core
Herbert Irving Comprehensive Cancer Center
Columbia University Irving Medical Center
|
|
From: Marc C. <mar...@gm...> - 2024-07-04 12:55:34
|
I think you are proposing to implement every widget as a subview of the contentView, since a CALayer can only be attached to an NSView. Apple says in their documentation that performance is bad if a contentView has too many subviews. Tk windows can contain a huge number of widgets, especially when an extension like tablelist is used. So using a subview for every widget is a bad idea. (Feel free to try it, if you think Apple is wrong.) On the other hand, one would not expect to have huge numbers of OpenGL or Metal widgets in a window. Such a widget could be implemented as a subview which is managed by a Tk widget. That is what is done it Togl and TkGL. - Marc On Thu, Jul 4, 2024 at 3:39 AM Uwe Kirschner <Uwe...@gm...> wrote: > Hello Marc, > why not have one CALayer per widget? > > That way one could easily implement OpenGL and Metal widgets > (CAOpenGLLayer, and CAMetalLayer) > > In the one CALayer-per-toplevel scenario an OpenGL or Metal widget would > need to first render to texture, then copy the texture to a rectangle in > the toplevel's CGImage, and finally the toplevel's CALayer would have the > system composit the CGImage onscreen. That seems wasteful in a situation > where speed matters most... > > I work with a UIKit implementation for macOS called Chameleon which uses > CALayer to implement UIView on AppKit (this was long before Apple started > Catalyst). It works great and UIView can be thought of as the equivalent to > a tk widget. That's why I believe one CALayer per tk widget is the way to > go... > > Also, this would open the route to tcl/tk on iPadOS and visionOS (if the > new tk drops HIToolbox). > > > best regards, > Uwe > > > On 3. Jul 2024, at 18:12, Marc Culler <mar...@gm...> wrote: > > > Tk Timeline watchers may have noticed a long chain of commits to the > cgimage_with_crossing branch over the last month. This announcement is to > explain what has been going on there. In brief, that branch contains a > major change to how drawing works in the macOS port of Tk. This change > makes drawing in the macOS port work in a way which is much closer to how > it works in the other platforms, and much closer to what the generic Tk > code expects. The result is better performance and increased stability. > > The work is based on an idea of Christopher Chavez's. He realized that > Apple's Appkit design allowed for an alternative drawing strategy, and > wrote a proof-of-concept implementation. I had created a branch containing > his implementation a couple of years ago. Recently I merged that branch > with Tk 9 and then spent a few weeks ironing out wrinkles. Nicolas Bats, > Torsten Berg, Steve Landers, and Kevin Walzer kindly offered to help me by > testing the new implementation on their apps, some of which provide very > challenging environments for Tk. The result of this work is in the > cgimage-with-crossing branch. (The branch also includes a fix for ticket > [22349fc78a] which is about <Enter> and <Leave> events - hence the > reference to crossing in the branch tag.) > > The five of us are confident that this is a significant improvement. Some > highlights are: > * Better performance - CPU-intensive apps use about 20% fewer CPU > cycles > * Better conformance - Most runs of the regression test suite on macOS > 14 show no failures. This is not close to being the case for the trunk > branch. > * Fewer graphical artifacts (and work continues on those that remain.) > * Fewer crashes (none that we know of at the moment.) > > Given that the branch has been tested on large and complex apps - all of > which are working well - this is a major step forwards and we’d like to see > it tested more widely. To that end, although we are late in the release > cycle we are comfortable recommending that this be merged into trunk and > made part of beta3. That’s the only way we can guarantee wider testing. Of > course, if any issues crop up they will be addressed in a timely manner. > If you are a macOS tkchat user please download and try > https://www.codebykevin.com/TkChat_Setup_1.5.2.dmg If you want to try > the new macOS Tk with your own code and are comfortable building it > yourself please checkout and build the Tk cgimage_with_crossing branch > > The rest of this message gives some more details about the changes. > > The main difference is that the new drawing strategy does away with the > asynchronous drawing via the drawRect method. A macOS app which uses > drawRect is supposed to do all of its drawing within the drawRect method, > which can only be called by the NSApplication object. The app can request > that drawRect be called by setting the viewNeedsDisplay flag, but can not > call drawRect. The original design of the macOS Aqua port only partially > complied with this strategy. In fact it was possible to obtain a valid > graphics context for drawing to the backing layer of a window's contentView > even outside of the drawRect method. The original port would do this, e.g. > in a widget display proc which is being run as an idle task. But it would > also draw in the drawRect method by first generating expose events for all > widgets that need updates, then processing those expose events to create > idle tasks, then processing all of those idle tasks immediately. > > Obviously this scheme was not what Tk expected. Nor was it what Apple > expected. And Apple put an abrupqt end to half of it with the release of > macOS Mojave, which made it impossible to obtain a valid graphics context > outside of the drawRect method. When Tk was first built on Mojave, it > produced nothing but totally black windows. Eventually this was worked > around by arranging that any drawing operation which failed due to an > invalid graphics context would be rescheduled and also to modify drawRect > to make it (attempt to) run all of those rescheduled idle tasks. > > With the new macOS code it is once again true that Tk always has a valid > graphics context available and hence can draw at any time. It draws into a > CGBitmapImageContext which serves as the backing store for a Tk Window. > Instead of calling drawRect, it is configured with Apple's other option > which is to call updateLayer instead. In the new setup updateLayer > installs the CGImage as the CALayer of the ContentView of the NSWindow > which hosts the Tk toplevel, causing the contents of the image to appear in > the window. It also creates a new CGImage containing a copy of the window > in which subsequent drawing operations take place. This allows drawing > operations to take place at the expected time and in the expected order. > That makes for better stability and less unpredictability. In addition, it > removes the overhead that arises from attempting a drawing operation, > having it fail due to an invalid graphics context, rescheduling and > rerunning the operation. This accounts for the reduced CPU usage. > > - Marc > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > > |
|
From: Uwe K. <Uwe...@gm...> - 2024-07-04 08:39:45
|
Hello Marc, why not have one CALayer per widget? That way one could easily implement OpenGL and Metal widgets (CAOpenGLLayer, and CAMetalLayer) In the one CALayer-per-toplevel scenario an OpenGL or Metal widget would need to first render to texture, then copy the texture to a rectangle in the toplevel's CGImage, and finally the toplevel's CALayer would have the system composit the CGImage onscreen. That seems wasteful in a situation where speed matters most... I work with a UIKit implementation for macOS called Chameleon which uses CALayer to implement UIView on AppKit (this was long before Apple started Catalyst). It works great and UIView can be thought of as the equivalent to a tk widget. That's why I believe one CALayer per tk widget is the way to go... Also, this would open the route to tcl/tk on iPadOS and visionOS (if the new tk drops HIToolbox). best regards, Uwe > On 3. Jul 2024, at 18:12, Marc Culler <mar...@gm...> wrote: > > > Tk Timeline watchers may have noticed a long chain of commits to the cgimage_with_crossing branch over the last month. This announcement is to explain what has been going on there. In brief, that branch contains a major change to how drawing works in the macOS port of Tk. This change makes drawing in the macOS port work in a way which is much closer to how it works in the other platforms, and much closer to what the generic Tk code expects. The result is better performance and increased stability. > > The work is based on an idea of Christopher Chavez's. He realized that Apple's Appkit design allowed for an alternative drawing strategy, and wrote a proof-of-concept implementation. I had created a branch containing his implementation a couple of years ago. Recently I merged that branch with Tk 9 and then spent a few weeks ironing out wrinkles. Nicolas Bats, Torsten Berg, Steve Landers, and Kevin Walzer kindly offered to help me by testing the new implementation on their apps, some of which provide very challenging environments for Tk. The result of this work is in the cgimage-with-crossing branch. (The branch also includes a fix for ticket [22349fc78a] which is about <Enter> and <Leave> events - hence the reference to crossing in the branch tag.) > > The five of us are confident that this is a significant improvement. Some highlights are: > * Better performance - CPU-intensive apps use about 20% fewer CPU cycles > * Better conformance - Most runs of the regression test suite on macOS 14 show no failures. This is not close to being the case for the trunk branch. > * Fewer graphical artifacts (and work continues on those that remain.) > * Fewer crashes (none that we know of at the moment.) > > Given that the branch has been tested on large and complex apps - all of which are working well - this is a major step forwards and we’d like to see it tested more widely. To that end, although we are late in the release cycle we are comfortable recommending that this be merged into trunk and made part of beta3. That’s the only way we can guarantee wider testing. Of course, if any issues crop up they will be addressed in a timely manner. If you are a macOS tkchat user please download and try https://www.codebykevin.com/TkChat_Setup_1.5.2.dmg If you want to try the new macOS Tk with your own code and are comfortable building it yourself please checkout and build the Tk cgimage_with_crossing branch > > The rest of this message gives some more details about the changes. > > The main difference is that the new drawing strategy does away with the asynchronous drawing via the drawRect method. A macOS app which uses drawRect is supposed to do all of its drawing within the drawRect method, which can only be called by the NSApplication object. The app can request that drawRect be called by setting the viewNeedsDisplay flag, but can not call drawRect. The original design of the macOS Aqua port only partially complied with this strategy. In fact it was possible to obtain a valid graphics context for drawing to the backing layer of a window's contentView even outside of the drawRect method. The original port would do this, e.g. in a widget display proc which is being run as an idle task. But it would also draw in the drawRect method by first generating expose events for all widgets that need updates, then processing those expose events to create idle tasks, then processing all of those idle tasks immediately. > > Obviously this scheme was not what Tk expected. Nor was it what Apple expected. And Apple put an abrupqt end to half of it with the release of macOS Mojave, which made it impossible to obtain a valid graphics context outside of the drawRect method. When Tk was first built on Mojave, it produced nothing but totally black windows. Eventually this was worked around by arranging that any drawing operation which failed due to an invalid graphics context would be rescheduled and also to modify drawRect to make it (attempt to) run all of those rescheduled idle tasks. > > With the new macOS code it is once again true that Tk always has a valid graphics context available and hence can draw at any time. It draws into a CGBitmapImageContext which serves as the backing store for a Tk Window. Instead of calling drawRect, it is configured with Apple's other option which is to call updateLayer instead. In the new setup updateLayer installs the CGImage as the CALayer of the ContentView of the NSWindow which hosts the Tk toplevel, causing the contents of the image to appear in the window. It also creates a new CGImage containing a copy of the window in which subsequent drawing operations take place. This allows drawing operations to take place at the expected time and in the expected order. That makes for better stability and less unpredictability. In addition, it removes the overhead that arises from attempting a drawing operation, having it fail due to an invalid graphics context, rescheduling and rerunning the operation. This accounts for the reduced CPU usage. > > - Marc > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Marc C. <mar...@gm...> - 2024-07-03 16:12:33
|
Tk Timeline watchers may have noticed a long chain of commits to the
cgimage_with_crossing branch over the last month. This announcement is to
explain what has been going on there. In brief, that branch contains a
major change to how drawing works in the macOS port of Tk. This change
makes drawing in the macOS port work in a way which is much closer to how
it works in the other platforms, and much closer to what the generic Tk
code expects. The result is better performance and increased stability.
The work is based on an idea of Christopher Chavez's. He realized that
Apple's Appkit design allowed for an alternative drawing strategy, and
wrote a proof-of-concept implementation. I had created a branch containing
his implementation a couple of years ago. Recently I merged that branch
with Tk 9 and then spent a few weeks ironing out wrinkles. Nicolas Bats,
Torsten Berg, Steve Landers, and Kevin Walzer kindly offered to help me by
testing the new implementation on their apps, some of which provide very
challenging environments for Tk. The result of this work is in the
cgimage-with-crossing branch. (The branch also includes a fix for ticket
[22349fc78a] which is about <Enter> and <Leave> events - hence the
reference to crossing in the branch tag.)
The five of us are confident that this is a significant improvement. Some
highlights are:
* Better performance - CPU-intensive apps use about 20% fewer CPU cycles
* Better conformance - Most runs of the regression test suite on macOS
14 show no failures. This is not close to being the case for the trunk
branch.
* Fewer graphical artifacts (and work continues on those that remain.)
* Fewer crashes (none that we know of at the moment.)
Given that the branch has been tested on large and complex apps - all of
which are working well - this is a major step forwards and we’d like to see
it tested more widely. To that end, although we are late in the release
cycle we are comfortable recommending that this be merged into trunk and
made part of beta3. That’s the only way we can guarantee wider testing. Of
course, if any issues crop up they will be addressed in a timely manner.
If you are a macOS tkchat user please download and try
https://www.codebykevin.com/TkChat_Setup_1.5.2.dmg If you want to try the
new macOS Tk with your own code and are comfortable building it yourself
please checkout and build the Tk cgimage_with_crossing branch
The rest of this message gives some more details about the changes.
The main difference is that the new drawing strategy does away with the
asynchronous drawing via the drawRect method. A macOS app which uses
drawRect is supposed to do all of its drawing within the drawRect method,
which can only be called by the NSApplication object. The app can request
that drawRect be called by setting the viewNeedsDisplay flag, but can not
call drawRect. The original design of the macOS Aqua port only partially
complied with this strategy. In fact it was possible to obtain a valid
graphics context for drawing to the backing layer of a window's contentView
even outside of the drawRect method. The original port would do this, e.g.
in a widget display proc which is being run as an idle task. But it would
also draw in the drawRect method by first generating expose events for all
widgets that need updates, then processing those expose events to create
idle tasks, then processing all of those idle tasks immediately.
Obviously this scheme was not what Tk expected. Nor was it what Apple
expected. And Apple put an abrupqt end to half of it with the release of
macOS Mojave, which made it impossible to obtain a valid graphics context
outside of the drawRect method. When Tk was first built on Mojave, it
produced nothing but totally black windows. Eventually this was worked
around by arranging that any drawing operation which failed due to an
invalid graphics context would be rescheduled and also to modify drawRect
to make it (attempt to) run all of those rescheduled idle tasks.
With the new macOS code it is once again true that Tk always has a valid
graphics context available and hence can draw at any time. It draws into a
CGBitmapImageContext which serves as the backing store for a Tk Window.
Instead of calling drawRect, it is configured with Apple's other option
which is to call updateLayer instead. In the new setup updateLayer
installs the CGImage as the CALayer of the ContentView of the NSWindow
which hosts the Tk toplevel, causing the contents of the image to appear in
the window. It also creates a new CGImage containing a copy of the window
in which subsequent drawing operations take place. This allows drawing
operations to take place at the expected time and in the expected order.
That makes for better stability and less unpredictability. In addition, it
removes the overhead that arises from attempting a drawing operation,
having it fail due to an invalid graphics context, rescheduling and
rerunning the operation. This accounts for the reduced CPU usage.
- Marc
|
|
From: Bohumil F. <b.f...@gm...> - 2024-01-29 08:58:09
|
Thanks, I'll check it out! Boda On Mon, Jan 29, 2024 at 12:32 AM Steve Landers <st...@di...> wrote: > Not at all, it is actively maintained and enhanced and with the upcoming > Tcl/Tk 9.0 release it is possible to make apps with a native look and feel > that will also run on other platforms with minimal changes. > > You can find details in this TCLCORE post > https://sourceforge.net/p/tcl/mailman/tcl-core/thread/03d59800-87e9-acdf-f954-ceed30ba0801%40nist.gov/#msg58721527 > > -- Steve > On 29 Jan 2024 at 8:15 AM +0800, Bohumil Franek <b.f...@gm...>, > wrote: > > Is Tcl/Tk dead on Mac OS ? > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > > |
|
From: Steve L. <st...@di...> - 2024-01-29 00:32:58
|
Not at all, it is actively maintained and enhanced and with the upcoming Tcl/Tk 9.0 release it is possible to make apps with a native look and feel that will also run on other platforms with minimal changes. You can find details in this TCLCORE post https://sourceforge.net/p/tcl/mailman/tcl-core/thread/03d59800-87e9-acdf-f954-ceed30ba0801%40nist.gov/#msg58721527 -- Steve On 29 Jan 2024 at 8:15 AM +0800, Bohumil Franek <b.f...@gm...>, wrote: > Is Tcl/Tk dead on Mac OS ? > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
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 > |
9 messages has been excluded from this view by a project administrator.