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

[MACTCL] Xcode 4.3 and Tcl/Tk

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

Hi all,

Apple released Xcode 4.3 this week, and the new version has some 
significant differences over previous iterations of the IDE. Xcode no 
longer installs in /Developer, but is instead a single app bundle that 
installs in /Applications. Additionally, Xcode no longer installs 
numerous command-line tools such as llvm, clang, gcc, etc. These can 
either be installed from Xcode 4.3's preferences menu, or as a separate 
download from Apple's developer site.

The reason I'm mentioning this is that I ran into significant issues 
trying to patch and build a new version of Tk with Xcode 4.3. (I'm not 
alone in this respect. Many open-source projects, such as MacPorts, 
Fink, and Homebrew are also finding a lot of their packages are breaking 
because of the changes in Xcode.) Tk couldn't find standard headers like 
stdio.h, let alone the Cocoa and Carbon headers it depends on for the 
Aqua version.

After a lot of Googling, trial and error, I got a new build of Tcl and 
Tk to work. Here's what I did:

1. Before installing Xcode 4.3 from the Mac App Store, I removed all 
previous installations of Xcode using the uninstall script that is found 
in /Developer. (Xcode 4.3 also allows you to do this.) I did this to 
avoid path conflicts.

2. Installed Xcode 4.3 and the command-line tools.

3. Ran this command: sudo xcode-select -switch 
/Applications/Xcode.app/Contents/Developer/. This command points system 
resources to the correct header paths, command-line tools, etc. if you 
have the full Xcode installation.

After this, I had to rebuild Tcl and Tk from scratch, and everything ran 
smoothly.

Apple also has made the command-line tools available as a download that 
does not require the full Xcode installation. I haven't tested this 
setup, so I can't speak to how it works with open-source software; my 
guess is that the xcode-select command would need to be run, possibly to 
point to a different location. The list archives and bug trackers of 
MacPorts, Fink, and Homebrew are full of discussion about this over the 
past several days, and it's not fully clear to me how they are resolving 
the issue or what setup they are recommending for end users.

This release of Xcode was a bit bumpy for open-source projects, and I 
hope this basic discussion of what worked for me will be helpful to others.

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

Re: [MACTCL] Display refresh / painting in Tk-Cocoa

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

On 2/20/12 12:31 PM, Zbigniew Diaczyszyn wrote:
> Am 13.02.2012 20:20, schrieb Adrian Robert:
>> Hi,
>>
>> I've been trying to port an application to Tk Cocoa and one of the
>> differences I've been running into is display refresh.  I don't know
>> if there is just one problem or multiple problems, but it seems like
>> updates from the Tk side are prioritized lower than in Carbon.
>> Observations on 10.6 (all differences from Mac/Carbon, Windows, and
>> X):
>
> I have ported my application to MacOSX Tk 8.5.11 and try to synchronize
> the Tk event loop and Cocoa's event loop by inserting often an "update
> idletasks" before using critical GUI commands like menu, grab, focus, wm
> iconify and so on. Sometimes the "grab" command has to be omitted at all.
>

These types of workarounds are the most effective way to deal with the 
event loop issue--it may require some trial and error.

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

Re: [MACTCL] Display refresh / painting in Tk-Cocoa

[Zbigniew D. <z....@gm...>]

Am 13.02.2012 20:20, schrieb Adrian Robert:
> Hi,
>
> I've been trying to port an application to Tk Cocoa and one of the
> differences I've been running into is display refresh.  I don't know
> if there is just one problem or multiple problems, but it seems like
> updates from the Tk side are prioritized lower than in Carbon.
> Observations on 10.6 (all differences from Mac/Carbon, Windows, and
> X):

I have ported my application to MacOSX Tk 8.5.11 and try to synchronize 
the Tk event loop and Cocoa's event loop by inserting often an "update 
idletasks" before using critical GUI commands like menu, grab, focus, wm 
iconify and so on. Sometimes the "grab" command has to be omitted at all.

Re: [MACTCL] Display refresh / painting in Tk-Cocoa

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

On 2/13/12 2:20 PM, Adrian Robert wrote:
> Hi,
>
> I've been trying to port an application to Tk Cocoa and one of the differences I've been running into is display refresh.  I don't know if there is just one problem or multiple problems, but it seems like updates from the Tk side are prioritized lower than in Carbon.  Observations on 10.6 (all differences from Mac/Carbon, Windows, and X):
>
> 1) if you make changes to a canvas widget, and then take it offscreen, the changes are not visible the next time you bring it onscreen (instead they come after a short delay)
>
> 2) when extending the size of a window by PACKing something onto the bottom, the sequence happens thusly: a) the window size is extended; b) the entire contents of the window are redrawn starting from the new bottom; c) the height information for the contents of the new piece start getting paid attention to, which causes a second redraw of the contents back in the original position
>
> 3) the bug here (http://sourceforge.net/tracker/?func=detail&aid=3166688&group_id=12997&atid=112997), where using pack / pack forget to switch a tabbed display fails to refresh in timely fashion
>
>
> Before I dive into the event loop and display refresh code in Tk Cocoa (and who knows if I'll come out), has anyone else taken a look at this and/or have any insights or suggestions to offer from other experience with refresh/event loop in Cocoa or Tk?
>
>
> thanks,
> Adrian
>
Hi Adrian,

You have hit upon one of the knottiest issues with Tk-Cocoa--its event 
loop is noticably slower than Carbon's in some respects. If you check 
the list archives and the bug reports at SF, you'll see various reports, 
investigations (many by me), and discussions.

Bottom line, this is extremely complex to address and I've found it 
frankly beyond my skill. Integrating Tk and Cocoa's event loops seems to 
be a much more complicated process than Carbon's; that is what Daniel 
Steffen has indicated. Its sheer complexity may make the integration 
more fragile and bugs harder to address.

I'd welcome your input if you have time to take a look. I've found the 
internals of the event loop so hairy that I've not been able to make any 
headway, and have more or less punted in case someone else wants to take 
a stab at it.

Thanks,
Kevin

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

[MACTCL] Display refresh / painting in Tk-Cocoa

[Adrian R. <adr...@gm...>]

Hi,

I've been trying to port an application to Tk Cocoa and one of the differences I've been running into is display refresh.  I don't know if there is just one problem or multiple problems, but it seems like updates from the Tk side are prioritized lower than in Carbon.  Observations on 10.6 (all differences from Mac/Carbon, Windows, and X):

1) if you make changes to a canvas widget, and then take it offscreen, the changes are not visible the next time you bring it onscreen (instead they come after a short delay)

2) when extending the size of a window by PACKing something onto the bottom, the sequence happens thusly: a) the window size is extended; b) the entire contents of the window are redrawn starting from the new bottom; c) the height information for the contents of the new piece start getting paid attention to, which causes a second redraw of the contents back in the original position

3) the bug here (http://sourceforge.net/tracker/?func=detail&aid=3166688&group_id=12997&atid=112997), where using pack / pack forget to switch a tabbed display fails to refresh in timely fashion


Before I dive into the event loop and display refresh code in Tk Cocoa (and who knows if I'll come out), has anyone else taken a look at this and/or have any insights or suggestions to offer from other experience with refresh/event loop in Cocoa or Tk?


thanks,
Adrian

Re: [MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

[Hans-Christoph S. <ha...@at...>]

On Feb 5, 2012, at 5:54 PM, Kevin Walzer wrote:

> On 2/5/12 12:56 PM, Hans-Christoph Steiner wrote:
>> I guess I need to work on the transition to Tk/Cocoa:)
> 
> You won't regret it. :-) I'd love to play with a stable Cocoa build of PD.

Yeah, I think its a big improvement, but Pd is an old Tcl app, started in '94, so moving it forward always comes with little pains ;)

.hc


----------------------------------------------------------------------------

I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers.      - General Smedley Butler

Re: [MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

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

On 2/5/12 12:56 PM, Hans-Christoph Steiner wrote:
> I guess I need to work on the transition to Tk/Cocoa:)

You won't regret it. :-) I'd love to play with a stable Cocoa build of PD.

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

Re: [MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

[Hans-Christoph S. <ha...@at...>]

On Feb 5, 2012, at 9:27 AM, Kevin Walzer wrote:

> On 2/4/12 11:58 PM, Hans-Christoph Steiner wrote:
>>  /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4"
> 
> Could this be the issue--support for 10.4? 10.5 is the minimum supported 
> OS for 64-bit Tk-Cocoa. Try adjusting these flags.

I figured it out.  The included Tcl.framework is built as 32-bit, which this 64-bit plugin then tries to use at runtime.  Normally in this app, it works find to have a 32-bit Tcl/Tk while the core of the app is 64-bit because they talk via a network socket. For this particular plugin, the 64-bit binary side needs to use the Tcl.framework, and the included one is only 32-bit.

I guess I need to work on the transition to Tk/Cocoa :)

.hc


----------------------------------------------------------------------------

"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."        -John Gilmore

Re: [MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

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

On 2/4/12 11:58 PM, Hans-Christoph Steiner wrote:
>   /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4"

Could this be the issue--support for 10.4? 10.5 is the minimum supported 
OS for 64-bit Tk-Cocoa. Try adjusting these flags.

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

Re: [MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

[Hans-Christoph S. <ha...@at...>]

On Jan 30, 2012, at 3:01 PM, Michael Schlenker wrote:

> 
> Am 30.01.2012 um 05:14 schrieb Hans-Christoph Steiner:
> 
>> 
>> We have an odd error in our app Pd-extended.  Its a media programming environment that we recently added the ability to write objects in Tcl.  This is done using swig to wrap the Pd C API for Tcl.  That's working great, but we have this odd error:
>> 
>> On 32-bit builds, everything works fine, they are currently built on 10.5.8 and seem to run fine on 10.5 - 10.7.  For the 64-bit builds, when the 'tclpd' library is loaded, it throws this error:
>> 
>> Symbol not found: _TclFreeObj
>> 
>> The 64-bit builds are built on 10.6.8 and I'm running it on 10.6.8.  Both of these apps are using a custom build of plain vanilla Tcl/Tk 8.5.10.
> 
> TclFreeObj() should be an internal symbol from the name, which is only exposed due to the Tcl_DecRefCount macro, but is actually defined in the Stubs Table slot 30, so it should be visible for a stubs enabled build at least.
> 
> Are you using stubs or linking directly?
> 
> Michael

I don't quite understand the question.  So tclpd.pd_darwin is a bundle/plugin that is linking to the Tcl framework using "-framework Tcl"  That Tcl 8.5.10 framework is built using:

export CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 \
 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4"
make -C tcl/${BUILD_DIR} deploy

That Tcl.framework is installed into /Library/Frameworks.

.hc


----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

[MACTCL] Symbol not found: _TclFreeObj on 64-bit builds

[Hans-Christoph S. <ha...@at...>]

We have an odd error in our app Pd-extended.  Its a media programming environment that we recently added the ability to write objects in Tcl.  This is done using swig to wrap the Pd C API for Tcl.  That's working great, but we have this odd error:

On 32-bit builds, everything works fine, they are currently built on 10.5.8 and seem to run fine on 10.5 - 10.7.  For the 64-bit builds, when the 'tclpd' library is loaded, it throws this error:

Symbol not found: _TclFreeObj

The 64-bit builds are built on 10.6.8 and I'm running it on 10.6.8.  Both of these apps are using a custom build of plain vanilla Tcl/Tk 8.5.10.

.hc

----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

Re: [MACTCL] kCGErrorIllegalArgument: CGSRegisterCursorWithImages

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

On 10/25/11 9:56 AM, xi0n0ix wrote:
>
> Hello,
>
> I am contributing to an application being developed which is being
> re-written from tk/tcl ->  tk/cocoa.
>
> I am receiving this error:
>
>   kCGErrorIllegalArgument: CGSRegisterCursorWithImages: Invalid hot spot
>   (outside of size)
>
> I am wondering if this error is familiar to anyone or if I can be pointed in
> the right direction. Google reveals next to nothing for this error.
>
> Thanks
> x

Does this error cause a problem with your script, or is it just logged 
in the console? If it's just logged in the console, it is probably 
harmless.

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

[MACTCL] kCGErrorIllegalArgument: CGSRegisterCursorWithImages

[xi0n0ix <xi...@ya...>]

Hello,

I am contributing to an application being developed which is being
re-written from tk/tcl -> tk/cocoa.

I am receiving this error:

 kCGErrorIllegalArgument: CGSRegisterCursorWithImages: Invalid hot spot
 (outside of size)

I am wondering if this error is familiar to anyone or if I can be pointed in
the right direction. Google reveals next to nothing for this error.

Thanks
x
-- 
View this message in context: http://old.nabble.com/kCGErrorIllegalArgument%3A-CGSRegisterCursorWithImages-tp32717573p32717573.html
Sent from the tcl-mac mailing list archive at Nabble.com.

[MACTCL] Growl and Tcl

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

Hi all,

I'm posting this here because a few of the list members make use of the 
Growl notification system (http://growl.info) in their apps.

Growl has just released a new version that makes significant changes in 
its API--these changes are for compatibility with Mac App Store 
requirements and also to put the system on firmer developmental footing 
moving forward. Unfortunately, these changes also break many of the 
third-party language bindings for Growl.

I've been informally maintaining two separate Tcl-Growl integration 
packages--one, macgrowl, is of my own creation and is a Tcl wrapper for 
Growl's AppleScript interface. The other, tclgrowl, was a "native" 
Objective-C library developed by the Growl team itself but was largely 
abandoned (I cobbled a TEA-compliant package out of it and host it at my 
SVN repo at SF). Neither package works with the new version of Growl.

Since many of my commercial Tcl/Tk apps support Growl, I'm going to be 
putting together some sort of new package for Growl integration with 
Tcl, but I haven't yet decided how to proceed. Growl's "native" 
notification system uses a new network protocol that is completely 
incompatible with the old system. Its new AppleScript API requires fewer 
changes, but may not play nice with Apple's new "sandboxing" 
requirements in Lion and the Mac App Store.

I don't yet have a timeline for implementing a new Growl package; it 
partly depends on how much work will be involved. I've asked the Growl 
team for some guidance on this. In the meantime, once I do have 
something ready, it will be released open-source somewhere, and I'll 
post an announcement here.

Thanks,
Kevin

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

Re: [MACTCL] snackAmp for OS X

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

On 10/17/11 10:12 AM, Kevin Walzer wrote:
> On 10/17/11 4:13 AM, Kristoffer Lawson wrote:
>>
>> On 17 Oct 2011, at 03:51, Kevin Walzer wrote:
>>
>>> I've scratched a long-standing personal itch by porting snackAmp to OS
>>> X. SnackAmp is a multi-platform music player with normal music player
>>> abilities, multi-user support, integrated web server, and a powerful
>>> AutoPlaylist feature.
>>
>> Nice! Is Snack itself maintained? A while back I tried to get it running on OS X, but would always get a Bus error. I'm guessing that isn't the case for you :-)
>>
>
> Tom put out a new release of Snack last year, but I think it was just
> slapping a "final" release tag on the beta that had been posted on the
> website for years before that. As far as active development, no, I don't
> think there's much going on with it.
>
> --Kevin
>

Whoops, I see you meant the Snack sound library and not snackAmp.

No, Snack hasn't been updated in five or six years. It builds, but it 
doesn't run as well on OS X as on Windows. I saw a posting on the Core 
Audio mailing list that said it makes use of ancient and deprecated Core 
Audio functions, but no one has responded to queries/bug reports about it.

--Kevin

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

Re: [MACTCL] snackAmp for OS X

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

On 10/17/11 4:13 AM, Kristoffer Lawson wrote:
>
> On 17 Oct 2011, at 03:51, Kevin Walzer wrote:
>
>> I've scratched a long-standing personal itch by porting snackAmp to OS
>> X. SnackAmp is a multi-platform music player with normal music player
>> abilities, multi-user support, integrated web server, and a powerful
>> AutoPlaylist feature.
>
> Nice! Is Snack itself maintained? A while back I tried to get it running on OS X, but would always get a Bus error. I'm guessing that isn't the case for you :-)
>

Tom put out a new release of Snack last year, but I think it was just 
slapping a "final" release tag on the beta that had been posted on the 
website for years before that. As far as active development, no, I don't 
think there's much going on with it.

--Kevin

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

Re: [MACTCL] snackAmp for OS X

[Kristoffer L. <se...@ho...>]

On 17 Oct 2011, at 03:51, Kevin Walzer wrote:

> I've scratched a long-standing personal itch by porting snackAmp to OS 
> X. SnackAmp is a multi-platform music player with normal music player 
> abilities, multi-user support, integrated web server, and a powerful 
> AutoPlaylist feature.

Nice! Is Snack itself maintained? A while back I tried to get it running on OS X, but would always get a Bus error. I'm guessing that isn't the case for you :-)

-- 
@Setok, +358-40-7312273
Co-Founder, HOLVI.com - Smart netbanking for group activities & creative projects
http://travellingsalesman.mobi - The world's most arctic startups

[MACTCL] snackAmp for OS X

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

Hi all,

I've scratched a long-standing personal itch by porting snackAmp to OS 
X. SnackAmp is a multi-platform music player with normal music player 
abilities, multi-user support, integrated web server, and a powerful 
AutoPlaylist feature.

snackAmp for OS X is based on the original snackAmp by Tom Wilkason at 
http://snackamp.sourceforge.net/. The Mac version incorporates some 
enhancements to make the program a good Mac OS X citizen. It requires 
Mac OS X 10.7 (Lion) to run.

snackAmp is licensed under the GPL. The snackAmp application is deployed 
as a standard Mac application bundle, and the source code is included in 
the bundle (snackAmp.app/MacOS/snackAmp.vfs).

Here's a link to the download page:

http://www.codebykevin.com/opensource/snackamp.html

Enjoy!

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

[MACTCL] snackAmp for OS X

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

Hi all,

I've scratched a long-standing personal itch by porting snackAmp to OS 
X. SnackAmp is a multi-platform music player with normal music player 
abilities, multi-user support, integrated web server, and a powerful 
AutoPlaylist feature.

snackAmp for OS X is based on the original snackAmp by Tom Wilkason at 
http://snackamp.sourceforge.net/. The Mac version incorporates some 
enhancements to make the program a good Mac OS X citizen. It requires 
Mac OS X 10.7 (Lion) to run.

snackAmp is licensed under the GPL. The snackAmp application is deployed 
as a standard Mac application bundle, and the source code is included in 
the bundle (snackAmp.app/MacOS/snackAmp.vfs).

Here's a link to the download page:

http://www.codebykevin.com/opensource/snackamp.html

Enjoy!

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

Re: [MACTCL] OS X Performance

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

Hi Steven,

Sorry, I must have missed your earlier e-mail; I don't remember seeing 
it. Let me address your concerns below.

On 10/10/11 5:15 PM, Steven wrote:
> I took my new intel macbook on holidays last week.
> OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.
>
> Can anyone summarise technically why Wish is so slow at redrawing on OSX?
>
> I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.
>
> Thanks for your work.
>
> Steven

This is a very general statement that is certainly not accurate in all 
respects. I occasionally see redraw issues with Wish-Cocoa, but not 
often. It's usually when we're dealing with instances of recent bugs 
logged at the tracker--things involving tk_wait, for instance--that 
involve low-level issues surrounding the integration between the Tk 
event loop and Cocoa. There are no easy fixes for these issues, as I've 
indicated on the mailing list.

Let me address the earlier comments as well:

>> Considering the amount and severity of bugs in tk-cocoa (re
>> the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
>> updates, multiple drawing of buttons" thread), i can't
>> imagine how you suggest using it for our project, which
>> handles huge databases and is a serious Chess database app -
>> generally rivalling commercial products.

The reason I suggest using it is that the Carbon branch of Tk is 
unmaintained and unsupported, and if you want 64-bit, unavailable. It's 
a judgment call and if you don't need 64-bit performance, by all means 
use the Carbon port.

>>
>> Reliability is everything in a database, and bugs in OSX
>> Tcl is definitely the issue for us. The 32 bit build we use
>> is the only one that works for us, after weeks and months of
>> trial and error, messing with SnowLeopard's Wish, and
>> learning how to build our own. Our app is very resource
>> intensive, and probably exposes lots of frailities in OSX
>> wish that are otherwise hard to pin-point.

Quite likely.

>>
>> (For example, on wish-8.5.7 it performs perfectly on Linux
>> and Windows, but using Snow-Leopards Wish-8.5.7, the program
>> crashes shortly after loading any moderate sized PGN file or
>> database. And exhibits *unusual* behaviour and coredumps
>> when using tk_dialog shortly before program exit. The
>> program can be linked against your systems Framework by
>> downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
>> ), and installing into /usr/local with "./configure
>> &&  make install&&  scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
>> small database containing 30,000 chess games. The maximum
>> database size is ~ 16 million.)

I did build the app and test it against the database you linked to, and 
didn't see any issues or crashes, but obviously YMMV. I'm also working 
on Lion, where the system Tk (Cocoa) is much more stable than the one 
bundled with Snow Leopard. (The Snow Leopard build was more a beta 
version, with lots of bugs fixed later, but Apple doesn't update Tk 
except at new versions of the OS.

>>
>> Anyway, i understand your desire to move people to Cocoa,
>> but considering the issues you have, which reflect our
>> frustrating testing .... we are definitely using Carbon. (
>> And I should mention my OSX packager feverently wanted to
>> use Cocoa, but gave in after much frustration).

As I said, you have very good reasons for staying with Carbon.


>>
>> I thought it was a known fact that Tk toplevels didn't have
>> click-through on OS X. (ie - when one ScidvsMac toplevel has
>> focus, clicking a button on another toplevel (say, the
>> game-list) doesn't actuate the button, but merely gives the
>> other toplevel focus.)

This may have been true in earlier versions of Tk, but not recently. I 
don't see this issue in my Cocoa build of the app.
>>
>> I don't suppose others can verify whether the App
>> ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
>> which should definitely link to our Tk Framework AFAIK,
>> "clicks through" (or not) for them.
>>
>> The App is an i386/PPC universal, (though PPC seems immune
>> to all of the serious bugs that we had, despite testing with
>> tcl-8.5.7 on the PPC box).

As you are probably aware, PPC is also obsolete, but if it works there, 
great!

--Kevin

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

Re: [MACTCL] OS X Performance

[Hans-Christoph S. <ha...@at...>]

Are you using the new Tk/Cocoa that is included with 10.6?  That is
supposed to be much faster.  For < 10.6, you can build it yourself, but
it is a separate branch, unless you are using Tcl/Tk 8.6

.hc

On Mon, 2011-10-10 at 14:15 -0700, Steven wrote:
> I took my new intel macbook on holidays last week.
> OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.
> 
> Can anyone summarise technically why Wish is so slow at redrawing on OSX?
> 
> I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.
> 
> Thanks for your work.
> 
> Steven
> 
> 
> --- On Fri, 9/9/11, Steven <ste...@ya...> wrote:
> 
> > From: Steven <ste...@ya...>
> > Subject: Re: [MACTCL] Have to click twice
> > To: kw...@co...
> > Cc: Tc...@li..., "Gilles PLUME" <pl...@ma...>
> > Received: Friday, 9 September, 2011, 4:27 PM
> > Thanks for the reply :)
> > 
> > Steven wrote:
> > 
> > > > With multi window apps, a friend has been
> > lamenting
> > > having to click twice when switching between windows
> > (ie -
> > > one click to get focus, another click to activate a
> > widget),
> > > which is unlike on Linux and Windows.
> > ...
> > > > Has anyone successfully tried this, or worked
> > around
> > > the "have to click twice" issue in some other way ?
> > Perhaps
> > > it's possible with an Operating System tweak, or even
> > a
> > > custom compilation of Tcl, which we already include
> > with our
> > > App (http://scidvspc.sf.net) because of problems with Snow
> > > Leopard's Wish 8.5.7.
> > 
> > Kevin wrote:
> > 
> > > I'm not sure I see the issues you are reporting. I
> > have
> > > downloaded your
> > > app and can click on a button in a background window
> > > ("click-through"
> > > behavior) just fine.
> > 
> > This is very suprising. On our systems, with numerous Tcl
> > builds  we haven't been able to do this. 
> > 
> > > In any event, the build of Tk you are using appears to
> > be
> > > obsolete--it's
> > > based on Carbon as far as I can tell. No bugs in that
> > > branch of Tk are
> > > being fixed at this point.
> > 
> > And this is also very suprising. While i'm mainly concerned
> > with finding a click-through solution, (as we now longer
> > have known bugs with our built-in framework), i have to
> > comment on this.
> > 
> > Considering the amount and severity of bugs in tk-cocoa (re
> > the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
> > updates, multiple drawing of buttons" thread), i can't
> > imagine how you suggest using it for our project, which
> > handles huge databases and is a serious Chess database app -
> > generally rivalling commercial products.
> > 
> > Reliability is everything in a database, and bugs in OSX
> > Tcl is definitely the issue for us. The 32 bit build we use
> > is the only one that works for us, after weeks and months of
> > trial and error, messing with SnowLeopard's Wish, and
> > learning how to build our own. Our app is very resource
> > intensive, and probably exposes lots of frailities in OSX
> > wish that are otherwise hard to pin-point.
> > 
> > (For example, on wish-8.5.7 it performs perfectly on Linux
> > and Windows, but using Snow-Leopards Wish-8.5.7, the program
> > crashes shortly after loading any moderate sized PGN file or
> > database. And exhibits *unusual* behaviour and coredumps
> > when using tk_dialog shortly before program exit. The
> > program can be linked against your systems Framework by
> > downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
> > ), and installing into /usr/local with "./configure
> > && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
> > small database containing 30,000 chess games. The maximum
> > database size is ~ 16 million.)
> > 
> > Anyway, i understand your desire to move people to Cocoa,
> > but considering the issues you have, which reflect our
> > frustrating testing .... we are definitely using Carbon. (
> > And I should mention my OSX packager feverently wanted to
> > use Cocoa, but gave in after much frustration).
> > 
> > We could suggest using Scid vs. Mac as a stress test for
> > Tcl/Tk. It does so admirably ;> But i've found debugging
> > it's coredumps very hard, though OS X *does* provide
> > detailed backtraces, and the OS has never crashed for either
> > of us i think.
> > 
> > ----------------------
> > 
> > Sorry to take up so much of your time, but back to our
> > small problem which hardly matters really ;>
> > 
> > I thought it was a known fact that Tk toplevels didn't have
> > click-through on OS X. (ie - when one ScidvsMac toplevel has
> > focus, clicking a button on another toplevel (say, the
> > game-list) doesn't actuate the button, but merely gives the
> > other toplevel focus.)
> > 
> > I don't suppose others can verify whether the App 
> > ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
> > which should definitely link to our Tk Framework AFAIK,
> > "clicks through" (or not) for them. 
> > 
> > The App is an i386/PPC universal, (though PPC seems immune
> > to all of the serious bugs that we had, despite testing with
> > tcl-8.5.7 on the PPC box).
> > 
> > cheers, Steven
> > 
> > ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines how
> > and why cloud
> > computing security and archiving is rapidly being adopted
> > across the IT 
> > space for its ease of implementation, lower cost, and
> > increased 
> > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> > _______________________________________________
> > Tcl-mac mailing list
> > tc...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-mac
> > 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] OS X Performance

[Steven <ste...@ya...>]

I took my new intel macbook on holidays last week.
OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.

Can anyone summarise technically why Wish is so slow at redrawing on OSX?

I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.

Thanks for your work.

Steven


--- On Fri, 9/9/11, Steven <ste...@ya...> wrote:

> From: Steven <ste...@ya...>
> Subject: Re: [MACTCL] Have to click twice
> To: kw...@co...
> Cc: Tc...@li..., "Gilles PLUME" <pl...@ma...>
> Received: Friday, 9 September, 2011, 4:27 PM
> Thanks for the reply :)
> 
> Steven wrote:
> 
> > > With multi window apps, a friend has been
> lamenting
> > having to click twice when switching between windows
> (ie -
> > one click to get focus, another click to activate a
> widget),
> > which is unlike on Linux and Windows.
> ...
> > > Has anyone successfully tried this, or worked
> around
> > the "have to click twice" issue in some other way ?
> Perhaps
> > it's possible with an Operating System tweak, or even
> a
> > custom compilation of Tcl, which we already include
> with our
> > App (http://scidvspc.sf.net) because of problems with Snow
> > Leopard's Wish 8.5.7.
> 
> Kevin wrote:
> 
> > I'm not sure I see the issues you are reporting. I
> have
> > downloaded your
> > app and can click on a button in a background window
> > ("click-through"
> > behavior) just fine.
> 
> This is very suprising. On our systems, with numerous Tcl
> builds  we haven't been able to do this. 
> 
> > In any event, the build of Tk you are using appears to
> be
> > obsolete--it's
> > based on Carbon as far as I can tell. No bugs in that
> > branch of Tk are
> > being fixed at this point.
> 
> And this is also very suprising. While i'm mainly concerned
> with finding a click-through solution, (as we now longer
> have known bugs with our built-in framework), i have to
> comment on this.
> 
> Considering the amount and severity of bugs in tk-cocoa (re
> the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
> updates, multiple drawing of buttons" thread), i can't
> imagine how you suggest using it for our project, which
> handles huge databases and is a serious Chess database app -
> generally rivalling commercial products.
> 
> Reliability is everything in a database, and bugs in OSX
> Tcl is definitely the issue for us. The 32 bit build we use
> is the only one that works for us, after weeks and months of
> trial and error, messing with SnowLeopard's Wish, and
> learning how to build our own. Our app is very resource
> intensive, and probably exposes lots of frailities in OSX
> wish that are otherwise hard to pin-point.
> 
> (For example, on wish-8.5.7 it performs perfectly on Linux
> and Windows, but using Snow-Leopards Wish-8.5.7, the program
> crashes shortly after loading any moderate sized PGN file or
> database. And exhibits *unusual* behaviour and coredumps
> when using tk_dialog shortly before program exit. The
> program can be linked against your systems Framework by
> downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
> ), and installing into /usr/local with "./configure
> && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
> small database containing 30,000 chess games. The maximum
> database size is ~ 16 million.)
> 
> Anyway, i understand your desire to move people to Cocoa,
> but considering the issues you have, which reflect our
> frustrating testing .... we are definitely using Carbon. (
> And I should mention my OSX packager feverently wanted to
> use Cocoa, but gave in after much frustration).
> 
> We could suggest using Scid vs. Mac as a stress test for
> Tcl/Tk. It does so admirably ;> But i've found debugging
> it's coredumps very hard, though OS X *does* provide
> detailed backtraces, and the OS has never crashed for either
> of us i think.
> 
> ----------------------
> 
> Sorry to take up so much of your time, but back to our
> small problem which hardly matters really ;>
> 
> I thought it was a known fact that Tk toplevels didn't have
> click-through on OS X. (ie - when one ScidvsMac toplevel has
> focus, clicking a button on another toplevel (say, the
> game-list) doesn't actuate the button, but merely gives the
> other toplevel focus.)
> 
> I don't suppose others can verify whether the App 
> ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
> which should definitely link to our Tk Framework AFAIK,
> "clicks through" (or not) for them. 
> 
> The App is an i386/PPC universal, (though PPC seems immune
> to all of the serious bugs that we had, despite testing with
> tcl-8.5.7 on the PPC box).
> 
> cheers, Steven
> 
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how
> and why cloud
> computing security and archiving is rapidly being adopted
> across the IT 
> space for its ease of implementation, lower cost, and
> increased 
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Re: [MACTCL] Universal Binary, Embedded 8.5.9 Wish possible?

[daneyul <da...@co...>]

Adrian R. kindly emailed me to point out the issue was my use of sudo
causing the flags not to be seen.  Doh--should have caught that myself!  Now
I have a nicely working Universal Binary Wish.

BTW, I looked into using starkits in the past, but compared to dropping
scripts (AppMain) and support files into a stand-alone Wish they added
complexity (albeit perhaps not huge) to set up and structure without any
advantages I could readily see.... but I may be missing some benefit.  I may
finally make the jump in the future, but now that I have stand-alone Wish
8.5.9 that will work on the OSX platforms I need, there's just not a
compelling reason right now.

Thanks!

-Daniel B.   




Gerald W. Lester-4 wrote:
> 
> Why not either use ActiveState's basekit or tclkit from 
> http://comments.gmane.org/gmane.comp.lang.tcl.starkit/3161
> 
> On 9/30/11 12:19 PM, daneyul wrote:
>> Hi,
>>
>> Having trouble creating a Universal Binary embedded build.  I've tried on
>> multiple Macs w/multiple versions of OSX (Leopard, Snow Leopard).
>> While it builds with no errors on Leopard, I get either an intel binary,
>> or
>> a ppc one, depending on my system.
>>
>> Below is an example of my environment on an intel OSX 10.5.8 (intel)
>> computer that stubbornly only will create an Intel Wish binary.
>>
>> Specs:
>> tcl/tk 8.5.9
>> Xcode 3.0
>> OSX 10.5.8
>> Intel Core 2 Duo
>>
>>
>> sh-3.2# pwd
>> /Users/danielb/desktop/tcl
>>
>> sh-3.2# ls
>> tcl8.5.9	tk8.5.9
>>
>> sh-3.2# ver="8.5.9"
>>
>> sh-3.2# export CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/
>> MacOSX10.4u.sdk -mmacosx-version-min=10.4"
>>
>> sh-3.2# sudo make -C tcl${ver}/macosx embedded
>>
>> sh-3.2# sudo make -C tk${ver}/macosx embedded
>>
>>
>>
>> Running up against a bit of a deadline in getting a viable stand-alone
>> build
>> that will operate on PPC and Intel environments.  If anyone has any ideas
>> as
>> to what I'm doing wrong--any suggestions at all--I would greatly
>> appreciate
>> it!
>>
>> Thanks!
>>
>> -Daniel B
>>
> 
> 
> -- 
> +------------------------------------------------------------------------+
> | Gerald W. Lester, President, KNG Consulting LLC                        |
> | Cell: +1.504.236.6657 | Email: Ger...@kn...        |
> +------------------------------------------------------------------------+
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 

-- 
View this message in context: http://old.nabble.com/Universal-Binary%2C-Embedded-8.5.9-Wish-possible--tp32570439p32570997.html
Sent from the tcl-mac mailing list archive at Nabble.com.

Re: [MACTCL] Universal Binary, Embedded 8.5.9 Wish possible?

[Gerald W. L. <Ger...@Kn...>]

Why not either use ActiveState's basekit or tclkit from 
http://comments.gmane.org/gmane.comp.lang.tcl.starkit/3161

On 9/30/11 12:19 PM, daneyul wrote:
> Hi,
>
> Having trouble creating a Universal Binary embedded build.  I've tried on
> multiple Macs w/multiple versions of OSX (Leopard, Snow Leopard).
> While it builds with no errors on Leopard, I get either an intel binary, or
> a ppc one, depending on my system.
>
> Below is an example of my environment on an intel OSX 10.5.8 (intel)
> computer that stubbornly only will create an Intel Wish binary.
>
> Specs:
> tcl/tk 8.5.9
> Xcode 3.0
> OSX 10.5.8
> Intel Core 2 Duo
>
>
> sh-3.2# pwd
> /Users/danielb/desktop/tcl
>
> sh-3.2# ls
> tcl8.5.9	tk8.5.9
>
> sh-3.2# ver="8.5.9"
>
> sh-3.2# export CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/
> MacOSX10.4u.sdk -mmacosx-version-min=10.4"
>
> sh-3.2# sudo make -C tcl${ver}/macosx embedded
>
> sh-3.2# sudo make -C tk${ver}/macosx embedded
>
>
>
> Running up against a bit of a deadline in getting a viable stand-alone build
> that will operate on PPC and Intel environments.  If anyone has any ideas as
> to what I'm doing wrong--any suggestions at all--I would greatly appreciate
> it!
>
> Thanks!
>
> -Daniel B
>


-- 
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC                        |
| Cell: +1.504.236.6657 | Email: Ger...@kn...        |
+------------------------------------------------------------------------+

[MACTCL] Universal Binary, Embedded 8.5.9 Wish possible?

[daneyul <da...@co...>]

Hi,

Having trouble creating a Universal Binary embedded build.  I've tried on
multiple Macs w/multiple versions of OSX (Leopard, Snow Leopard).
While it builds with no errors on Leopard, I get either an intel binary, or
a ppc one, depending on my system.

Below is an example of my environment on an intel OSX 10.5.8 (intel)
computer that stubbornly only will create an Intel Wish binary.

Specs:
tcl/tk 8.5.9
Xcode 3.0
OSX 10.5.8
Intel Core 2 Duo


sh-3.2# pwd
/Users/danielb/desktop/tcl

sh-3.2# ls
tcl8.5.9	tk8.5.9

sh-3.2# ver="8.5.9"

sh-3.2# export CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/
MacOSX10.4u.sdk -mmacosx-version-min=10.4"

sh-3.2# sudo make -C tcl${ver}/macosx embedded

sh-3.2# sudo make -C tk${ver}/macosx embedded



Running up against a bit of a deadline in getting a viable stand-alone build
that will operate on PPC and Intel environments.  If anyone has any ideas as
to what I'm doing wrong--any suggestions at all--I would greatly appreciate
it! 

Thanks!

-Daniel B

-- 
View this message in context: http://old.nabble.com/Universal-Binary%2C-Embedded-8.5.9-Wish-possible--tp32570439p32570439.html
Sent from the tcl-mac mailing list archive at Nabble.com.