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

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

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

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

 

Illustrated here:

 

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

 

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

 

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

 

Thanks,

 

Andy

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Jasper,

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


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

Thanks,

Kevin

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

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

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

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

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

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

Re: [MACTCL] Apple M1 Build

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

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

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

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

Re: [MACTCL] Apple M1 Build

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

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

++

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

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

Re: [MACTCL] Apple M1 Build

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

Yes I have

     --Jasper

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

[MACTCL] Apple M1 Build

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

Dear Tcl-Mac,

Has anyone built TclTk for Apple M1 yet?

Best, Kevan

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

[MACTCL] Announcement & Call for Speakers (The SQLite & Tcl Conf 2021)

[<con...@tc...>]

Hello tcl-mac, fyi ...

# The SQLite & Tcl Conference

__Wednesday, November 17, 2021__

The 2nd annual SQLite & Tcl virtual conference will be held on Wednesday, November 17.
The virtual event will feature a combination of curated talks and work in progress talks (WIPs).

[Registration is open](https://www.eventbrite.com/e/the-sqlite-tcl-conference-st-2021-registration-168185004877)!

Please visit the [SQLite & TCL conference](https://conf.tcl-lang.org/) home page to stay informed.

# Call for Speakers

We've made it easier to contribute by asking for shorter, less formal
talks rather than requiring formal papers.

  - Have you done interesting work that you would like to share?

  - How about a cool idea that's not yet baked or just in the
    prototype stage but seems like something others would be
    interested in? We are particularly interested in new ideas, to
    hear about novel solutions to problems you've faced, or to see
    your work in progress.

## To submit your talk:

Please visit the [call for speakers page](https://conf.tcl-lang.org/callforspeakers/)
for instructions.

As a token of our appreciation, each speaker will be gifted with a
video conferencing light kit to use while presenting.

The call for speakers for S&T 2021 ends on __October 4, 2021 at 11:59 PM CT__.

__Important dates:__

  - October 4 - Call for speakers for S&T 2021 ends at 11:59 PM CT

  - October 8 - We will start notifying speakers with their status of
    their submission and scheduled talk.

  - October 18 - Agenda for S&T 2021 Announced

  - November 17 - S&T 2021 held digitally online  

Re: [MACTCL] Supporting Command-click on window title

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

Thanks a lot!

I got it working with .wm_attributes("-titlepath",
stringContainingTheAbsolutePathOfTheDocument)
Passing empty string as the second argument turned the feature off.

I had to do it after setting iconbitmap, otherwise the icon file became the
titlepath.

Best regards,
Aivar


Furthermore, I think there should be something more -- I need to somehow
specify the path of the current document. I can't see how Tk could infer it.

On Tue, Jun 8, 2021 at 3:26 PM Kevin Walzer <kw...@co...> wrote:

> On 6/8/21 2:33 AM, Aivar Annamaa wrote:
> > Hi!
> >
> > In many macOS apps, when you Command-click on window's title, macOS
> > will show a menu describing the location of the currently open
> > document (see
> >
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
> > <
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
> >).
> >
> > Is it possible to control this in a Tk app? My Tkinter app currently
> > does show this menu, but it is always describing the location of the
> > application's icon file (set with root window's iconbitmap method).
> >
> > If there are no direct means for this in Tk, perhaps you know the name
> > of the corresponding method in Cocoa? Maybe it's possible to call it
> > via Python's ctypes.
> >
> > Best regards,
> > Aivar
>
> In Tcl, the command is [wm attributes $w -titlepath true]. In
> Python/Tkinter, it's something like w.wm_attributes("titlepath",
> "true"), where $w or w is the window name/object. (My Python is a bit
> rusty, but give this a try.)
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Supporting Command-click on window title

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

On 6/8/21 2:33 AM, Aivar Annamaa wrote:
> Hi!
>
> In many macOS apps, when you Command-click on window's title, macOS 
> will show a menu describing the location of the currently open 
> document (see 
> https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/ 
> <https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/>).
>
> Is it possible to control this in a Tk app? My Tkinter app currently 
> does show this menu, but it is always describing the location of the 
> application's icon file (set with root window's iconbitmap method).
>
> If there are no direct means for this in Tk, perhaps you know the name 
> of the corresponding method in Cocoa? Maybe it's possible to call it 
> via Python's ctypes.
>
> Best regards,
> Aivar

In Tcl, the command is [wm attributes $w -titlepath true]. In 
Python/Tkinter, it's something like w.wm_attributes("titlepath", 
"true"), where $w or w is the window name/object. (My Python is a bit 
rusty, but give this a try.)

--Kevin

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

[MACTCL] Supporting Command-click on window title

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

Hi!

In many macOS apps, when you Command-click on window's title, macOS will
show a menu describing the location of the currently open document (see
https://oneminutemacman.com/command-click-a-windows-title-to-show-the-documents-location/
).

Is it possible to control this in a Tk app? My Tkinter app currently does
show this menu, but it is always describing the location of the
application's icon file (set with root window's iconbitmap method).

If there are no direct means for this in Tk, perhaps you know the name of
the corresponding method in Cocoa? Maybe it's possible to call it via
Python's ctypes.

Best regards,
Aivar

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Dear Christopher,

> The patchlevel of macOS 10.15’s Tcl/Tk is 8.5.9. 

You are quite right: I have 8.5.18 installed by Home Brew.

> I would think SIP (System Integrity Protection) would try very hard to keep you from deleting the system Tcl/Tk, so I would not recommend trying to.

I can delete the Home Brew installation, although that will break a few things like ffmpeg and python.

So far as I understand it, the TclTk embedded build, invoked by the commands below, is independent of any installed TclTk.

make -C tcl/macosx embedded
make -C tk/macosx embedded

Is anyone able to complete the embedded build of 8.7 on MacOS 10.15 or 11.1? I can on MacOS 10.12, but not on 10.15.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Dear Mansour,

Thank you for your attention.

> Can you share the output of:
> 
>      export CC="$(xcrun --find clang)"
>      $CC --version

kevan@KSH5 ~ % export CC="$(xcrun --find clang)"
kevan@KSH5 ~ % $CC --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

>      xcodebuild -showsdks

kevan@KSH5 ~ % xcodebuild -showsdks
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory
'/Library/Developer/CommandLineTools' is a command line tools instance

As you can see, I don't have Xcode installed. I don't believe I have it installed on my older machine either, but I will check.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

> I guess I'll try removing MacOS's pre-installed 8.5.18 and see if that helps.

I don’t have any specific advice on what to try, however:

• The patchlevel of macOS 10.15’s Tcl/Tk is 8.5.9. If you observe a patchlevel of 8.5.18 then that seems like a separate installation.
• I would think SIP (System Integrity Protection) would try very hard to keep you from deleting the system Tcl/Tk, so I would not recommend trying to.

Christopher A. Chavez

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

[Mansour M. <man...@gm...>]

On Thu, May 20, 2021 at 11:21 AM Kevan Hashemi <ha...@br...> wrote:
>
> Greetings from Boston,
>
> I removed all traces of GCC and developer tools from my MacOS10.15.7 machine, including Home Brew versions. I re-installed Command Line Tools. I try to build Tcl 8.6.11 with:
>
> export CFLAGS="-arch x86_64"
> make -C tcl/macosx
>
> It fails during the link with undefined symbols. Link error is below. Uwe Kirschner and I were asking for help with this same problem a couple of months ago. If I move to a machine running MacOS 10.12.6, I can compile any version of TclTk I like. But I can compile none of them on my 10.15.7 machine. Is anyone else able to compile TclTk on MacOS 10.15?
>
> Best, Kevan
>
> Undefined symbols for architecture x86_64:
>    "_TclOOInitializeStubs", referenced from:
>        _Initialize in itclBase.o
>    "_Tcl_InitStubs", referenced from:
>        _Initialize in itclBase.o
>    "_tclIntStubsPtr", referenced from:
>        _Itcl_NRRunCallbacks in itcl2TclOO.o
>        _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
>        _ItclGetInstanceVar in itclObject.o
>        _ItclSetInstanceVar in itclObject.o
>        __Tcl_GetOriginalCommand in itclTclIntStubsFcn.o
>        __Tcl_CreateProc in itclTclIntStubsFcn.o
>        __Tcl_GetObjInterpProc in itclTclIntStubsFcn.o
>        ...
>    "_tclOOIntStubsPtr", referenced from:
>        _Itcl_PublicObjectCmd in itcl2TclOO.o
>        _Itcl_NewProcClassMethod in itcl2TclOO.o
>        _Itcl_NewProcMethod in itcl2TclOO.o
>        _Itcl_NewForwardClassMethod in itcl2TclOO.o
>    "_tclOOStubsPtr", referenced from:
>        _RootCallProc in itclBase.o
>        _Initialize in itclBase.o
>        _ItclExtendedConfigure in itclBuiltin.o
>        _ItclExtendedCget in itclBuiltin.o
>        _ItclUnknownGuts in itclBuiltin.o
>        _Itcl_BiInstallComponentCmd in itclBuiltin.o
>        _Itcl_BiMyMethodCmd in itclBuiltin.o
>        ...
>    "_tclStubsPtr", referenced from:
>        _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
>        _Itcl_InvokeEnsembleMethod in itcl2TclOO.o
>        _EnsembleErrorProc in itcl2TclOO.o
>        _FreeProcedureMethod in itcl2TclOO.o
>        _Itcl_PublicObjectCmd in itcl2TclOO.o
>        _Itcl_SelfCmd in itcl2TclOO.o
>        _Itcl_TclOOObjectName in itcl2TclOO.o
>        ...
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[4]: *** [libitcl4.2.1.dylib] Error 1
> make[3]: *** [packages] Error 2
> make[2]: *** [build-tcl] Error 2
> make[1]: *** [tcl] Error 2
> make: *** [develop] Error 2

What version of clang?

Can you share the output of:

    export CC="$(xcrun --find clang)"
    $CC --version

and also:

    xcodebuild -showsdks

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Dear Nicolas,

Thank you for your attention.

> on macOS11.3 I successfully build Tcl/Tk (the core-8-branch for Tcl and
> Trunk for Tk)

It sounds like I will have to update to 11.3.

> sudo make install

I'm not trying to install TclTk in the operating system. I am building locally. The build fails at link time. Now, perhaps the build is mistakenly trying to link to installed versions of TclTk, which do indeed exist in MacOS 10.15, it has TclTk 8.5.18 loaded by default.  When I build with "make embedded", the link fails just as for "make".

I guess I'll try removing MacOS's pre-installed 8.5.18 and see if that helps.

Best, kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Hi,
on macOS11.3 I successfully build Tcl/Tk (the core-8-branch for Tcl and
Trunk for Tk)
so it's TclTk 8.7
my build command is (for both):

*export*
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

*export* CC=/usr/bin/clang

make -C macosx deploy  CFLAGS="-O2 -mmacosx-version-min=10.15"

sudo make install


the tricky part is that you'll need to have tclsh8.7 in /usr/lib or
/usr/local/lib and not tclsh8.6 nor tclsh8.5


so here, I'm looking for everything that is tclsh8.x, remove them,

then build Tcl, then build Tk


hope it helps.

++

nicolas

Le jeu. 20 mai 2021 à 17:21, Kevan Hashemi <ha...@br...> a écrit :

> Greetings from Boston,
>
> I removed all traces of GCC and developer tools from my MacOS10.15.7
> machine, including Home Brew versions. I re-installed Command Line Tools. I
> try to build Tcl 8.6.11 with:
>
> export CFLAGS="-arch x86_64"
> make -C tcl/macosx
>
> It fails during the link with undefined symbols. Link error is below. Uwe
> Kirschner and I were asking for help with this same problem a couple of
> months ago. If I move to a machine running MacOS 10.12.6, I can compile any
> version of TclTk I like. But I can compile none of them on my 10.15.7
> machine. Is anyone else able to compile TclTk on MacOS 10.15?
>
> Best, Kevan
>
> Undefined symbols for architecture x86_64:
>    "_TclOOInitializeStubs", referenced from:
>        _Initialize in itclBase.o
>    "_Tcl_InitStubs", referenced from:
>        _Initialize in itclBase.o
>    "_tclIntStubsPtr", referenced from:
>        _Itcl_NRRunCallbacks in itcl2TclOO.o
>        _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
>        _ItclGetInstanceVar in itclObject.o
>        _ItclSetInstanceVar in itclObject.o
>        __Tcl_GetOriginalCommand in itclTclIntStubsFcn.o
>        __Tcl_CreateProc in itclTclIntStubsFcn.o
>        __Tcl_GetObjInterpProc in itclTclIntStubsFcn.o
>        ...
>    "_tclOOIntStubsPtr", referenced from:
>        _Itcl_PublicObjectCmd in itcl2TclOO.o
>        _Itcl_NewProcClassMethod in itcl2TclOO.o
>        _Itcl_NewProcMethod in itcl2TclOO.o
>        _Itcl_NewForwardClassMethod in itcl2TclOO.o
>    "_tclOOStubsPtr", referenced from:
>        _RootCallProc in itclBase.o
>        _Initialize in itclBase.o
>        _ItclExtendedConfigure in itclBuiltin.o
>        _ItclExtendedCget in itclBuiltin.o
>        _ItclUnknownGuts in itclBuiltin.o
>        _Itcl_BiInstallComponentCmd in itclBuiltin.o
>        _Itcl_BiMyMethodCmd in itclBuiltin.o
>        ...
>    "_tclStubsPtr", referenced from:
>        _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
>        _Itcl_InvokeEnsembleMethod in itcl2TclOO.o
>        _EnsembleErrorProc in itcl2TclOO.o
>        _FreeProcedureMethod in itcl2TclOO.o
>        _Itcl_PublicObjectCmd in itcl2TclOO.o
>        _Itcl_SelfCmd in itcl2TclOO.o
>        _Itcl_TclOOObjectName in itcl2TclOO.o
>        ...
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[4]: *** [libitcl4.2.1.dylib] Error 1
> make[3]: *** [packages] Error 2
> make[2]: *** [build-tcl] Error 2
> make[1]: *** [tcl] Error 2
> make: *** [develop] Error 2
>
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

[MACTCL] Still Cannot Build TclTk on MacOS10.15

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

Greetings from Boston,

I removed all traces of GCC and developer tools from my MacOS10.15.7 machine, including Home Brew versions. I re-installed Command Line Tools. I try to build Tcl 8.6.11 with:

export CFLAGS="-arch x86_64"
make -C tcl/macosx

It fails during the link with undefined symbols. Link error is below. Uwe Kirschner and I were asking for help with this same problem a couple of months ago. If I move to a machine running MacOS 10.12.6, I can compile any version of TclTk I like. But I can compile none of them on my 10.15.7 machine. Is anyone else able to compile TclTk on MacOS 10.15?

Best, Kevan

Undefined symbols for architecture x86_64:
   "_TclOOInitializeStubs", referenced from:
       _Initialize in itclBase.o
   "_Tcl_InitStubs", referenced from:
       _Initialize in itclBase.o
   "_tclIntStubsPtr", referenced from:
       _Itcl_NRRunCallbacks in itcl2TclOO.o
       _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
       _ItclGetInstanceVar in itclObject.o
       _ItclSetInstanceVar in itclObject.o
       __Tcl_GetOriginalCommand in itclTclIntStubsFcn.o
       __Tcl_CreateProc in itclTclIntStubsFcn.o
       __Tcl_GetObjInterpProc in itclTclIntStubsFcn.o
       ...
   "_tclOOIntStubsPtr", referenced from:
       _Itcl_PublicObjectCmd in itcl2TclOO.o
       _Itcl_NewProcClassMethod in itcl2TclOO.o
       _Itcl_NewProcMethod in itcl2TclOO.o
       _Itcl_NewForwardClassMethod in itcl2TclOO.o
   "_tclOOStubsPtr", referenced from:
       _RootCallProc in itclBase.o
       _Initialize in itclBase.o
       _ItclExtendedConfigure in itclBuiltin.o
       _ItclExtendedCget in itclBuiltin.o
       _ItclUnknownGuts in itclBuiltin.o
       _Itcl_BiInstallComponentCmd in itclBuiltin.o
       _Itcl_BiMyMethodCmd in itclBuiltin.o
       ...
   "_tclStubsPtr", referenced from:
       _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
       _Itcl_InvokeEnsembleMethod in itcl2TclOO.o
       _EnsembleErrorProc in itcl2TclOO.o
       _FreeProcedureMethod in itcl2TclOO.o
       _Itcl_PublicObjectCmd in itcl2TclOO.o
       _Itcl_SelfCmd in itcl2TclOO.o
       _Itcl_TclOOObjectName in itcl2TclOO.o
       ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [libitcl4.2.1.dylib] Error 1
make[3]: *** [packages] Error 2
make[2]: *** [build-tcl] Error 2
make[1]: *** [tcl] Error 2
make: *** [develop] Error 2

  
-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] [TCLCORE] Commit 9fda84d2

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

Sent: Monday, May 03, 2021 at 5:14 PM
From: "Marc Culler" <mar...@gm...>

> Hi Jan,
 
> I disagree with your change in 9fda84d2, where you remove the first two parameters of TkpPutRGBAImage.  The reason that you give is that those parameters are not used on macOS.  But that is a bad reason, since those parameters would be used on other platforms, notably X11.
 
> The whole point was to have a function with the exact same signature as TkPutImage.  It is meant to replace TkPutImage for platforms which are able to use native code (and hence the graphics card) to do Porter-Duff source-over blending.  tkImgPhInstance can do that blending without using the graphics card if necessary, but now it will call TkpPutRGBAImage on platforms that provide it.  I had in mind that the function should be exported as a stub, and that is another reason why the signature should be the same for all platforms.
 

While it makes sense to me for TkpPutRGBAImage() to be a replacement for TkPutImage(), I do think it is okay to remove the *colors/ncolors parameters for TkpPutRGBAImage(); I don’t think they would be used on any platform. For TkPutImage(), they are only used on Windows (and only for one call in TkImgDitherInstance()), and actually appear to be unused on X11 (see tkUnixPort.h). I also think it would be reasonable for TkpPutRGBAImage() to only accept non-palette 32-bpp ZPixmaps, and not have to handle anything that TkPutImage() can do.

Christopher A. Chavez

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

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

Dear Marc,

> As I said, the LC_ID_DYLIB path is not used for loading any shared 
> libraries...

I understand, and thank you for explaining.

> While the loader ignores LC_ID_DYLIB, the linker uses it.

Indeed, so changing the LC_ID_DYLIB from one version of Tcl to the next creates problems for people linking to the library. And when the Tk library does not follow the same change, this creates further confusion. But I see that these problems are easily overcome.

> What I think is the correct approach is to have the LC_ID_DYLIB path
> be @rpath/Tcl.

I agree, and with your macher utility, I am able to do this. Thank you.

I gave 8.7a3 a thorough TCPIP and image-display work-out today and it was fast and stable, so I am delighted.

Best Wishes, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Marc C. <mar...@gm...>]

As I said, the LC_ID_DYLIB path is not used for loading any shared
libraries.  So it is completely irrelevant to the process by which " the
embedded Wish is supposed to call its own frameworks".  While the loader
ignores LC_ID_DYLIB, the linker uses it.  When you link against the Tcl
library the linker writes the LC_ID_DYLIB that it finds for Tcl into the
resulting Mach-O file as its LC_LOAD_DYLIB path.  So it is true that if you
linked your X.dylib against
/Library/Frameworks/Tcl.Framework/Versions/8.7/Tcl and if the LC_ID_DYLIB
of that Tcl was set
to @loader_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl then your
X.dylib would be embeddable in an application that contained a Tcl
framework.  But that is not the only possible situation where one might
want to link against  /Library/Frameworks/Tcl.Framework/Versions/8.7/Tcl.
It is also true that if your embedded Tcl library had its LC_ID_DYLIB path
set to @executable_path/../Frameworks then you could link the Wish
executable against that embedded library and get a Wish that worked.  But
you could not link X.dylib against that embedded library and get an X.dylib
that worked, because it needs a relative path that starts with @loader_path.

What I think is the correct approach is to have the LC_ID_DYLIB path be
@rpath/Tcl.  That would work in all situations, but it would require that
you pay attention and make sure that you set the correct RPATH for the
binary that you are linking.  In particular, if you are linking an
executable then the RPATH would need to start with @executable_path and if
you were linking X.dylib then it would need to start with @loader_path.

- Marc

It is used when you link against the library and it becomes the LC

On Mon, Apr 12, 2021 at 1:23 PM Kevan Hashemi <ha...@br...> wrote:

> Dear Marc,
>
> > Do you have permission to write to the file?
>
> Good call. With "sudo" I can re-write the ID of the Tcl library.
>
> > Then you need to change the LC_LOAD_DYLIB for X.dylib to be a correct
> path to the Tcl library
>
> Yes, I'm doing that in my Makefile and it works fine.
>
> > Because Tcl is normally installed in /Library/Frameworks/Tcl.framework
> and
> > Tk is normally installed in /Library/Frameworks/Tk.framework.  So it is
> > appropriate for them to have absolute LC_ID_DYLIB paths.
>
> Okay. But the Tk library has a relative path, and every previous version
> of the Tcl and Tk have had relative paths, and the Wish embedded executable
> should not call the frameworks installed in /Library because the embedded
> Wish is supposed to call its own frameworks, which requires a relative
> path. Therefore, I claim that the /Library version of LD_ID_DYLIB for the
> Tcl framework in the embedded version of Wish is an error.
>
> Cheers, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>