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

Re: [MACTCL] Looking for current version of 68k MacOS 7.5.5 TclKit

[Daniel A. S. <st...@ic...>]

At 7:47 -0500 on 4/1/02, Larry W. Virden wrote:

>Question: In the shared build, is it then possible to load dynamic
>libraries?

yes that works fine, but as I said it's not possible to load dynamic 
libraries from a scripted document without some work to deal with 
resource forks.

>Also, and this is hopefully not too off topic, where does someone
>with their first (albeit antique) powermac and no money begin
>building a Mac that can compile Tcl/Tk, etc.?

the biggest problem re. now money is probably that building on the 
mac currently needs Metrowerks CodeWarrior Pro6. You might be able to 
get this cheaply from someone who has upgraded to Pro7 (or by getting 
academic pricing like myself)

otherwise I don't know of anything that would prevent you from 
building Tcl/Tk on an old powermac, except that it will be slow (on 
my imac DV 450 Mhz building the full distro takes ~30 mins)

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Looking for current version of 68k MacOS 7.5.5 TclKit

[Larry W. V. <lv...@ca...>]

Wonderful!  Knowing JCW and Vince, I don't expect it to take long to see
these changes merged back into the source.  

Question: In the shared build, is it then possible to load dynamic 
libraries?

Also, and this is hopefully not too off topic, where does someone
with their first (albeit antique) powermac and no money begin
building a Mac that can compile Tcl/Tk, etc.? 
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [MACTCL] Looking for current version of 68k MacOS 7.5.5 TclKit

[Daniel A. S. <st...@ic...>]

Larry, Jean-Claude,

I spent some time on tclkit-mac over the break, and thanks to JC's 
excellent work it wasn't that hard to get the current tclkit HEAD to 
build with the tcl/tk HEAD. (I checked in some changes to tcl & tk in 
the process)

the results are at http://www.maths.mq.edu.au/~steffen/tcltk/tclkit/

both a static and a shared build are available, these are FAT builds, 
i.e. containing both 68k and PPC code. I've just tested them 
successfully on a 68k mac with OS 7.5.5 (w/ appearance mgr installed).

the static build is smaller and doesn't need CFM68k but cannot load 
dynamic libraries on ppc or 68k.

also available at the above url are the patches to metakit & tclkit, 
changed projects in xml form, and the new files for tclkit/mac needed 
to get all this to work. (all text files are latin1 encoded w/ unix 
line-endings, and need conversion to macroman before using on a mac, 
but are good to be checked into cvs from a unix box as is)

(Vince, some small changes to your vfs code were necessary, c.f. 
http://www.maths.mq.edu.au/~steffen/tcltk/tclkit/tclkit/tclkit-mac.patch 
; this confirms that the new 8.4 vfs code works indeed fine on the 
mac as well and is really _very_ nice!)

I don't think packaging mac dynamic libraries in a scripted document 
will work currently as they need information from their resource 
forks to be loadable, but that could potentially be handled using the 
[resource] command.
All other functionality is there, which makes single file tk apps on 
the mac possible! very nice indeed...

both sdx and wikit work fine on the mac as well btw.

Cheers,

Daniel

At 2:58 -0500 on 20/12/01, Larry W. Virden wrote:

>I don't know if people are aware of TclKit, but it is a single
>executable file containing all parts of Tcl, Tk, and a number of other
>useful binary and tcl script extensions.  It is a wonderful tool for
>distributing applications - using tclkit and a tool called sdx, you can
>take a multifile mixed mode application (combining binaries, scripts, etc.)
>and distribute two files - the Tclkit 'runtime' and the application in
>what is known as 'scripted document' format.
>
>Anyways, http://purl.org/tcl/wiki/tclkit leads to pointers to an older version
>for the PowerMac , but I've not found anything relatively new and for the
>older Macs (of which I have about 4 or 5 sitting around the house).
>
>If anyone has such a creature they are willing to share, please let me know.
>And if not, but you would be interested in having/creating such a thing,
>I'd like to see if we can sweet talk someone on the group into creating
>such a thing for us.

-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Carbon port

[Mats B. <ma...@pr...>]

Ashley Ward wrote:
> 
> I don't know if this will help, but SourceForge have Mac OS X 10.1 machines
> (two, last time I looked) on the 'Net that you can use to compile things on.
> 
>   http://sourceforge.net/forum/forum.php?forum_id=113664
> 
> I'm guessing that you probably couldn't run Project Builder remotely (this
> isn't X windows), but you should definitely be able to telnet to one of the
> machines and use the command line cc etc.
> 

This sounds very complicated, but it would be cool to make it work.
Thanks anyway.

> Your project will need to have an open source license however...
> 

BSD, no problem there.

Mats

Re: [MACTCL] Carbon port

[Ashley W. <ash...@nt...>]

on 3/1/02 8:08 am, Mats Bengtsson at ma...@pr... wrote:
> Carbon porting QuickTimeTcl
> 
> I'm attempting to make a Carbon port of QuickTimeTcl without a
> machine that can run MacOS X. I have MacOS 8.6, CarbonLib 1.4,
> Tcl/Tk 8.3.4, and CW 6.2.

Hi Mats...

I don't know if this will help, but SourceForge have Mac OS X 10.1 machines
(two, last time I looked) on the 'Net that you can use to compile things on.

  http://sourceforge.net/forum/forum.php?forum_id=113664

I'm guessing that you probably couldn't run Project Builder remotely (this
isn't X windows), but you should definitely be able to telnet to one of the
machines and use the command line cc etc.

Your project will need to have an open source license however...

Ash.

-- 
          Ashley Ward - Graduate Teaching Assistant - PhD student
     as...@dc... - http://www.dcs.warwick.ac.uk/~ashley/
Room 3.16, Department of Computer Science, University of Warwick, Coventry

[MACTCL] Carbon port

[Mats B. <ma...@pr...>]

Carbon porting QuickTimeTcl

I'm attempting to make a Carbon port of QuickTimeTcl without a
machine that can run MacOS X. I have MacOS 8.6, CarbonLib 1.4,
Tcl/Tk 8.3.4, and CW 6.2.

First I thought that it would be possible to run without a hook
into the main App's event loop using Carbon timers to serv
movies and grabber, but for a controller I need mouse events
etc. which requires that I get Mac events from the main
or window event loop.

Anyway, I've fixed all compile errors from the QuickTimeTcl code,
linking to CarbonLib instead of InterfaceLib,
but obviosly there are some errors coming from Tcl/Tk 8.3.4.
My question is, how to proceed? With Daniels 8.4.a? version
or perhaps with the macosx branch?

Best Wishes,   Mats

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Jim I. <ji...@ap...>]

On 1/2/02 4:32 PM, "Jim Ingham" <ji...@ap...> wrote:

> On the Tk side, you need to make sure you rerun configure, as well as the
> build stage

Oops, of course I meant Tcl here...

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Jim I. <ji...@ap...>]

On 1/2/02 12:35 PM, "Ashley Ward" <as...@dc...> wrote:

> on 31/12/01 8:14 PM, Jim Ingham at ji...@ap... wrote:
>>> on 25/12/01 7:04 pm, Tony Lownds at to...@me... wrote:
>>>> At 7:24 PM +0000 12/21/01, Ashley Ward wrote:
>>>>> When I run my application, I now get a partially-drawn interface wind=
ow,
>>>>> but
>>>>> then it hangs.  I can use gdb to generate a backtrace:
>>>>> [...]
>>>>> I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  =
I've
>>>>> had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and=
 have
>>>>> copied a few likely-looking things into my Tcl_AppInit() and main(). =
 In
>>>>> particular, I've added TkMacOSXInitAppleEvents(interp); and
>>>>> TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to ha=
ve
>>>>> any
>>>>> effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which=
 then
>>>>> causes a similar but deeper hang earlier on (not in the call to
>>>>> Tk_MacOSXSetupTkNotifier()).
>>>>=20
>>>> I think you are not doing the call to Tk_MacOSXSetupTkNotifier early
>>>> enough. Call it before ALL other Tcl_* or Tk_* functions.
>>>>=20
>>>> -Tony
>>>=20
>>> [...]
>>> started it from.  When I click in the app's window to bring it to the f=
ront
>>> in an attempt to use it, I get this message from tkMacOSXMouseEvent.c:2=
41
>>> (the function TkMacOSXProcessMouseEvent) on stderr:
>>>=20
>>> SetFrontProcess failed,-600
>>> [...]
>>> Any ideas why SetFrontProcess would fail in this way?
>>>=20
>>> Also I can't seem to compile Tcl or Tk from the code I obtained from CV=
S.
>>> I'm using Project Builder, with the Wish.pbproj.  Trying to compile the
>>> TkLibrary target gives me an error when linking: "Undefined symbols:
>>> _Tcl_MacOSXOpenBundleResources".  Apologies -- it's probably a newbie
>>> mistake with Project Builder.  If anyone could point out where I've gon=
e
>>> wrong, I'd appreciate it as building Tk myself might help in debugging =
my
>>> app.
>>>=20
>> How recently have you updated your Tcl/Tk sources?  I made some changes
>> (moving the routine you aren't finding from Tk to Tcl, where it more
>> properly belongs).  But I forgot to check in one of the subdirectories, =
so
>> the Makefiles didn't get updated.  You need to update all the Tcl & Tk
>> trees,=20
>=20
> I've just cd'd into my tk and tcl directories and done a 'cvs update', bu=
t
> CVS didn't seem to do anything (it just said "Updating" on every director=
y
> name).
>=20
> I did "update to latest version" in Project Builder, and compiled TkLibra=
ry
> again, but still got the error:
>=20
> ld: Undefined symbols:
> _Tcl_MacOSXOpenBundleResources
>=20
>> and, since there were changes to configure & Makefile.in, you need to
>> rerun configure and rebuild.
>=20
> I did 'clean active target' in Project Builder before compiling.
>=20
> Hmmm... "rerun configure and rebuild"... is it possible to compile it
> without using Project Builder now?  I remember reading a post from Jim th=
at
> said the UNIX makefiles hadn't been done.

Tk doesn't use Make & Configure, but Tcl does.  What happened was that some
routine was moved from Tk to Tcl, so you will need to rebuild both Tcl & Tk=
.
On the Tk side, you need to make sure you rerun configure, as well as the
build stage.  The Tcl Projects are a bit hacked up, and the clean doesn't
really work, so you have to do this by hand.  If you have the time, the
simplest way is probably just blowing away your object directory, and then
rerunning the Tcl mega-build target.

>=20
>> Sorry for the trouble.
>=20
> No problem -- think we're getting there :)
>=20
>> There is a patch in the Tk sourceforge Patch Manager to move the
>> SetupTkNotifier, and a bunch of other miscellaneous junk, into the TkpIn=
it
>> routine so that you don=B9t have to do anything but call Tk_Init, and you =
will
>> be done.  I need to clean it up (the style is not kosher, the contents a=
re
>> great), and check it in.  I am still on vacation, but I will get to this
>> this weekend...
>=20
> That sounds good.  Don't work too hard, though :)

Somebody else did most of the work on this one.  But thanks...

>=20
>> I need to chase down the SetFrontProcess thing.  This call usually succe=
eds,
>> but there is some glitch that causes it to occasionally fail.  It doesn'=
t
>> seem to be harmful, however, so I haven't looked into it further.
>=20
> It always fails with my app.  And as it fails, I can't give the app focus
> and so I can't interact with it.  A fairly major problem :(

I will see if I can think of some good diagnostics for you to insert...

>=20
> Thanks for the reply.
>=20

No problem...

Jim
--=20
++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Ashley W. <as...@dc...>]

on 31/12/01 8:14 PM, Jim Ingham at ji...@ap... wrote:
>> on 25/12/01 7:04 pm, Tony Lownds at to...@me... wrote:
>>> At 7:24 PM +0000 12/21/01, Ashley Ward wrote:
>>>> When I run my application, I now get a partially-drawn interface windo=
w,
>>>> but
>>>> then it hangs.  I can use gdb to generate a backtrace:
>>>> [...]
>>>> I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  I=
've
>>>> had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and =
have
>>>> copied a few likely-looking things into my Tcl_AppInit() and main().  =
In
>>>> particular, I've added TkMacOSXInitAppleEvents(interp); and
>>>> TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to hav=
e any
>>>> effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which =
then
>>>> causes a similar but deeper hang earlier on (not in the call to
>>>> Tk_MacOSXSetupTkNotifier()).
>>>=20
>>> I think you are not doing the call to Tk_MacOSXSetupTkNotifier early
>>> enough. Call it before ALL other Tcl_* or Tk_* functions.
>>>=20
>>> -Tony
>>=20
>> [...]
>> started it from.  When I click in the app's window to bring it to the fr=
ont
>> in an attempt to use it, I get this message from tkMacOSXMouseEvent.c:24=
1
>> (the function TkMacOSXProcessMouseEvent) on stderr:
>>=20
>> SetFrontProcess failed,-600
>> [...]
>> Any ideas why SetFrontProcess would fail in this way?
>>=20
>> Also I can't seem to compile Tcl or Tk from the code I obtained from CVS=
.
>> I'm using Project Builder, with the Wish.pbproj.  Trying to compile the
>> TkLibrary target gives me an error when linking: "Undefined symbols:
>> _Tcl_MacOSXOpenBundleResources".  Apologies -- it's probably a newbie
>> mistake with Project Builder.  If anyone could point out where I've gone
>> wrong, I'd appreciate it as building Tk myself might help in debugging m=
y
>> app.
>>=20
> How recently have you updated your Tcl/Tk sources?  I made some changes
> (moving the routine you aren't finding from Tk to Tcl, where it more
> properly belongs).  But I forgot to check in one of the subdirectories, s=
o
> the Makefiles didn't get updated.  You need to update all the Tcl & Tk
> trees,=20

I've just cd'd into my tk and tcl directories and done a 'cvs update', but
CVS didn't seem to do anything (it just said "Updating" on every directory
name).

I did "update to latest version" in Project Builder, and compiled TkLibrary
again, but still got the error:

ld: Undefined symbols:
_Tcl_MacOSXOpenBundleResources

>and, since there were changes to configure & Makefile.in, you need to
> rerun configure and rebuild.

I did 'clean active target' in Project Builder before compiling.

Hmmm... "rerun configure and rebuild"... is it possible to compile it
without using Project Builder now?  I remember reading a post from Jim that
said the UNIX makefiles hadn't been done.

> Sorry for the trouble.

No problem -- think we're getting there :)

> There is a patch in the Tk sourceforge Patch Manager to move the
> SetupTkNotifier, and a bunch of other miscellaneous junk, into the TkpIni=
t
> routine so that you don=B9t have to do anything but call Tk_Init, and you w=
ill
> be done.  I need to clean it up (the style is not kosher, the contents ar=
e
> great), and check it in.  I am still on vacation, but I will get to this
> this weekend...

That sounds good.  Don't work too hard, though :)

> I need to chase down the SetFrontProcess thing.  This call usually succee=
ds,
> but there is some glitch that causes it to occasionally fail.  It doesn't
> seem to be harmful, however, so I haven't looked into it further.

It always fails with my app.  And as it fails, I can't give the app focus
and so I can't interact with it.  A fairly major problem :(

Thanks for the reply.

> Jim

Ash.

--=20
          Ashley Ward - Graduate Teaching Assistant - PhD student
     as...@dc... - http://www.dcs.warwick.ac.uk/~ashley/
Room 3.16, Department of Computer Science, University of Warwick, Coventry

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Jim I. <ji...@ap...>]

Ashley,

How recently have you updated your Tcl/Tk sources?  I made some changes
(moving the routine you aren't finding from Tk to Tcl, where it more
properly belongs).  But I forgot to check in one of the subdirectories, so
the Makefiles didn't get updated.  You need to update all the Tcl & Tk
trees, and, since there were changes to configure & Makefile.in, you need t=
o
rerun configure and rebuild.

Sorry for the trouble.

There is a patch in the Tk sourceforge Patch Manager to move the
SetupTkNotifier, and a bunch of other miscellaneous junk, into the TkpInit
routine so that you don=B9t have to do anything but call Tk_Init, and you wil=
l
be done.  I need to clean it up (the style is not kosher, the contents are
great), and check it in.  I am still on vacation, but I will get to this
this weekend...

I need to chase down the SetFrontProcess thing.  This call usually succeeds=
,
but there is some glitch that causes it to occasionally fail.  It doesn't
seem to be harmful, however, so I haven't looked into it further.

Jim

> on 25/12/01 7:04 pm, Tony Lownds at to...@me... wrote:
>> At 7:24 PM +0000 12/21/01, Ashley Ward wrote:
>>> When I run my application, I now get a partially-drawn interface window=
, but
>>> then it hangs.  I can use gdb to generate a backtrace:
>>> [...]
>>> I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  I'=
ve
>>> had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and h=
ave
>>> copied a few likely-looking things into my Tcl_AppInit() and main().  I=
n
>>> particular, I've added TkMacOSXInitAppleEvents(interp); and
>>> TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to have=
 any
>>> effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which t=
hen
>>> causes a similar but deeper hang earlier on (not in the call to
>>> Tk_MacOSXSetupTkNotifier()).
>>=20
>> I think you are not doing the call to Tk_MacOSXSetupTkNotifier early
>> enough. Call it before ALL other Tcl_* or Tk_* functions.
>>=20
>> -Tony
>=20
> Ah -- yes, thanks Tony.  I thought I'd put this call early on in main(), =
but
> not early enough.
>=20
> My app now starts up with what seems to be a partially-drawn interface
> window, as before.  The app's window is behind the Terminal window which =
I
> started it from.  When I click in the app's window to bring it to the fro=
nt
> in an attempt to use it, I get this message from tkMacOSXMouseEvent.c:241
> (the function TkMacOSXProcessMouseEvent) on stderr:
>=20
> SetFrontProcess failed,-600
>=20
> I found some documentation in Project Builder (the Process Manager docs)
> about this Carbon call, and apparently -600 means procNotFound: "Unknown
> drag reference", so I'm guessing that perhaps the PSN is invalid?  The PS=
N
> used is obtained from a call to GetCurrentProcess a few lines before.  Th=
e
> return code from GetCurrentProcess isn't checked, but I've called it
> manually with gdb and it seems to return 0.
>=20
> Any ideas why SetFrontProcess would fail in this way?
>=20
> Also I can't seem to compile Tcl or Tk from the code I obtained from CVS.
> I'm using Project Builder, with the Wish.pbproj.  Trying to compile the
> TkLibrary target gives me an error when linking: "Undefined symbols:
> _Tcl_MacOSXOpenBundleResources".  Apologies -- it's probably a newbie
> mistake with Project Builder.  If anyone could point out where I've gone
> wrong, I'd appreciate it as building Tk myself might help in debugging my
> app.
>=20
> Many thanks for the help.
>=20
> Ash.

--=20
++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Ashley W. <ash...@nt...>]

on 25/12/01 7:04 pm, Tony Lownds at to...@me... wrote:
> At 7:24 PM +0000 12/21/01, Ashley Ward wrote:
>> When I run my application, I now get a partially-drawn interface window, but
>> then it hangs.  I can use gdb to generate a backtrace:
>> [...]
>> I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  I've
>> had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and have
>> copied a few likely-looking things into my Tcl_AppInit() and main().  In
>> particular, I've added TkMacOSXInitAppleEvents(interp); and
>> TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to have any
>> effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which then
>> causes a similar but deeper hang earlier on (not in the call to
>> Tk_MacOSXSetupTkNotifier()).
>
> I think you are not doing the call to Tk_MacOSXSetupTkNotifier early
> enough. Call it before ALL other Tcl_* or Tk_* functions.
> 
> -Tony

Ah -- yes, thanks Tony.  I thought I'd put this call early on in main(), but
not early enough.

My app now starts up with what seems to be a partially-drawn interface
window, as before.  The app's window is behind the Terminal window which I
started it from.  When I click in the app's window to bring it to the front
in an attempt to use it, I get this message from tkMacOSXMouseEvent.c:241
(the function TkMacOSXProcessMouseEvent) on stderr:

SetFrontProcess failed,-600

I found some documentation in Project Builder (the Process Manager docs)
about this Carbon call, and apparently -600 means procNotFound: "Unknown
drag reference", so I'm guessing that perhaps the PSN is invalid?  The PSN
used is obtained from a call to GetCurrentProcess a few lines before.  The
return code from GetCurrentProcess isn't checked, but I've called it
manually with gdb and it seems to return 0.

Any ideas why SetFrontProcess would fail in this way?

Also I can't seem to compile Tcl or Tk from the code I obtained from CVS.
I'm using Project Builder, with the Wish.pbproj.  Trying to compile the
TkLibrary target gives me an error when linking: "Undefined symbols:
_Tcl_MacOSXOpenBundleResources".  Apologies -- it's probably a newbie
mistake with Project Builder.  If anyone could point out where I've gone
wrong, I'd appreciate it as building Tk myself might help in debugging my
app.

Many thanks for the help.

Ash.

-- 
          Ashley Ward - Graduate Teaching Assistant - PhD student
     as...@dc... - http://www.dcs.warwick.ac.uk/~ashley/
Room 3.16, Department of Computer Science, University of Warwick, Coventry

Re: [MACTCL] Mac OS X: help with C app which uses Tk?

[Tony L. <to...@me...>]

I think you are not doing the call to Tk_MacOSXSetupTkNotifier early 
enough. Call it before ALL other Tcl_* or Tk_* functions.

-Tony

At 7:24 PM +0000 12/21/01, Ashley Ward wrote:
>Hi...
>
>I wonder if someone could help me.
>
>I maintain our research group's software, which is written mainly in C
>(about 40k LOC) and makes use of Tcl and Tk.  The source is generically
>called Eden, but there are three possible targets, named ttyeden
>(command-line interaction), tkeden (interaction through a GUI built with Tk)
>and dtkeden (as tkeden but with distributed communication/computation
>features).
>
>Eden was originally developed on SunOS, then Solaris... and now it has been
>ported to Linux and Windows (using cygwin).  I rewrote the original iMake
>based stuff using autoconf to assist with this.  I tried a while back to
>port it to Mac OS 9 using CodeWarrior, but it all proved a little tricky.
>Now I have Mac OS X, I'm trying again.
>
>I've happily built ttyeden using my familiar autoconf-generated configure
>script and Makefiles in Terminal.app.  I'd prefer to use this setup (as I do
>on Windows with cygwin) rather than Project Builder as I hope it would then
>be easier to maintain this software across the several platforms.
>
>Last night I managed to build tkeden using Jim Ingham's native Tk port (I'd
>like to use this as opposed to using an X server, as I'd like to see the
>interface use Aqua buttons and so on).
>
>I installed the binaries from MacOSXTk8.4a4.tar.gz, and have a working
>Wish.app.  I can compile and link tkeden... I spent a while last night
>figuring out that the trick here was to link explicitly with
>/Library/Frameworks/Tcl.framework/Tcl and
>/Library/Frameworks/Tk.framework/Tk (-L..., -lTk etc doesn't seem to work).
>
>When I run my application, I now get a partially-drawn interface window, but
>then it hangs.  I can use gdb to generate a backtrace:
>
>^C
>Program received signal SIGINT, Interrupt.
>0x7003f4c8 in semaphore_wait_signal_trap ()
>(gdb) bt
>#0  0x7003f4c8 in semaphore_wait_signal_trap ()
>#1  0x7003f2c8 in _pthread_cond_wait ()
>#2  0x00436820 in Tcl_ConditionWait ()
>#3  0x004370cc in Tcl_WaitForEvent ()
>#4  0x00417ac4 in Tcl_DoOneEvent ()
>#5  0x0087af2c in Tk_MainLoop () at ../generic/tkEvent.c:1257
>#6  0x0000482c in main (argc=3, argv=0xbffff9b0) at main.c:1594
>#7  0x000022bc in _start ()
>#8  0x000020ec in start ()
>
>My application has happily done all its initialisation code and set up a
>Tcl_DoWhenIdle call back, which enables the app to get on with processing
>its run queue when the interface is in a sensible state.  The Tk_MainLoop
>call shown above is pretty much the last thing done in main().
>
>I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  I've
>had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and have
>copied a few likely-looking things into my Tcl_AppInit() and main().  In
>particular, I've added TkMacOSXInitAppleEvents(interp); and
>TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to have any
>effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which then
>causes a similar but deeper hang earlier on (not in the call to
>Tk_MacOSXSetupTkNotifier()).
>
>The initialisation code as it stands works on Solaris, Linux and cygwin.  I
>don't admit to understanding it fully though.
>
>Can anyone give me any hints, before I go to the next nasty stage of
>reducing the code to a test case?  Is there any documentation I should read
>in particular... I can't find any docs for TkMacOSXInitAppleEvents etc.
>This is my first real attempt at programming on the Mac, but I have
>experience on UNIX.
>
>I've just done Software Update to Mac OS X 10.1.2 but I don't have quite the
>most recent Developer Tools yet -- I have Project Builder 1.1 (v73.3), cc
>version 2.95.2 if that helps.  I'm using a new "white" iBook, 600MHz.
>
>The Eden source is up at <http://sf.net/projects/eden/>.  Our research home
>page is <http://www.dcs.warwick.ac.uk/modelling/>.
>
>Many thanks for any help.
>
>Ash.
>
>--
>           Ashley Ward - Graduate Teaching Assistant - PhD student
>      as...@dc... - http://www.dcs.warwick.ac.uk/~ashley/
>Room 3.16, Department of Computer Science, University of Warwick, Coventry
>
>
>_______________________________________________
>Tcl-mac mailing list
>Tc...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-mac


-- 

[MACTCL] Mac OS X: help with C app which uses Tk?

[Ashley W. <ash...@nt...>]

Hi...

I wonder if someone could help me.

I maintain our research group's software, which is written mainly in C
(about 40k LOC) and makes use of Tcl and Tk.  The source is generically
called Eden, but there are three possible targets, named ttyeden
(command-line interaction), tkeden (interaction through a GUI built with Tk)
and dtkeden (as tkeden but with distributed communication/computation
features).

Eden was originally developed on SunOS, then Solaris... and now it has been
ported to Linux and Windows (using cygwin).  I rewrote the original iMake
based stuff using autoconf to assist with this.  I tried a while back to
port it to Mac OS 9 using CodeWarrior, but it all proved a little tricky.
Now I have Mac OS X, I'm trying again.

I've happily built ttyeden using my familiar autoconf-generated configure
script and Makefiles in Terminal.app.  I'd prefer to use this setup (as I do
on Windows with cygwin) rather than Project Builder as I hope it would then
be easier to maintain this software across the several platforms.

Last night I managed to build tkeden using Jim Ingham's native Tk port (I'd
like to use this as opposed to using an X server, as I'd like to see the
interface use Aqua buttons and so on).

I installed the binaries from MacOSXTk8.4a4.tar.gz, and have a working
Wish.app.  I can compile and link tkeden... I spent a while last night
figuring out that the trick here was to link explicitly with
/Library/Frameworks/Tcl.framework/Tcl and
/Library/Frameworks/Tk.framework/Tk (-L..., -lTk etc doesn't seem to work).

When I run my application, I now get a partially-drawn interface window, but
then it hangs.  I can use gdb to generate a backtrace:

^C
Program received signal SIGINT, Interrupt.
0x7003f4c8 in semaphore_wait_signal_trap ()
(gdb) bt
#0  0x7003f4c8 in semaphore_wait_signal_trap ()
#1  0x7003f2c8 in _pthread_cond_wait ()
#2  0x00436820 in Tcl_ConditionWait ()
#3  0x004370cc in Tcl_WaitForEvent ()
#4  0x00417ac4 in Tcl_DoOneEvent ()
#5  0x0087af2c in Tk_MainLoop () at ../generic/tkEvent.c:1257
#6  0x0000482c in main (argc=3, argv=0xbffff9b0) at main.c:1594
#7  0x000022bc in _start ()
#8  0x000020ec in start ()

My application has happily done all its initialisation code and set up a
Tcl_DoWhenIdle call back, which enables the app to get on with processing
its run queue when the interface is in a sensible state.  The Tk_MainLoop
call shown above is pretty much the last thing done in main().

I suspect that perhaps I'm getting the Tcl/Tk initialisation wrong.  I've
had a look at tkMacOSXAppInit.c from the macosx-8-4-branch on CVS and have
copied a few likely-looking things into my Tcl_AppInit() and main().  In
particular, I've added TkMacOSXInitAppleEvents(interp); and
TkMacOSXInitMenus(interp); to Tcl_AppInit() (which doesn't seem to have any
effect) and tried adding Tk_MacOSXSetupTkNotifier(); to main(), which then
causes a similar but deeper hang earlier on (not in the call to
Tk_MacOSXSetupTkNotifier()).

The initialisation code as it stands works on Solaris, Linux and cygwin.  I
don't admit to understanding it fully though.

Can anyone give me any hints, before I go to the next nasty stage of
reducing the code to a test case?  Is there any documentation I should read
in particular... I can't find any docs for TkMacOSXInitAppleEvents etc.
This is my first real attempt at programming on the Mac, but I have
experience on UNIX.

I've just done Software Update to Mac OS X 10.1.2 but I don't have quite the
most recent Developer Tools yet -- I have Project Builder 1.1 (v73.3), cc
version 2.95.2 if that helps.  I'm using a new "white" iBook, 600MHz.

The Eden source is up at <http://sf.net/projects/eden/>.  Our research home
page is <http://www.dcs.warwick.ac.uk/modelling/>.

Many thanks for any help.

Ash.

-- 
          Ashley Ward - Graduate Teaching Assistant - PhD student
     as...@dc... - http://www.dcs.warwick.ac.uk/~ashley/
Room 3.16, Department of Computer Science, University of Warwick, Coventry

[MACTCL] Looking for current version of 68k MacOS 7.5.5 TclKit

[Larry W. V. <lv...@ca...>]

I don't know if people are aware of TclKit, but it is a single
executable file containing all parts of Tcl, Tk, and a number of other
useful binary and tcl script extensions.  It is a wonderful tool for
distributing applications - using tclkit and a tool called sdx, you can
take a multifile mixed mode application (combining binaries, scripts, etc.)
and distribute two files - the Tclkit 'runtime' and the application in
what is known as 'scripted document' format.

Anyways, http://purl.org/tcl/wiki/tclkit leads to pointers to an older version
for the PowerMac , but I've not found anything relatively new and for the
older Macs (of which I have about 4 or 5 sitting around the house).

If anyone has such a creature they are willing to share, please let me know.
And if not, but you would be interested in having/creating such a thing,
I'd like to see if we can sweet talk someone on the group into creating
such a thing for us.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [MACTCL] Bug in tk_getSaveFile on OSX

[Jim I. <ji...@ap...>]

Yeah, the Carbon calls - like the Nav Services calls we use here - don't 
take Unix paths.  There is a pretty simple converter API, I just need to 
preprocess the initialdir...

Jim

On Sunday, December 16, 2001, at 06:28  PM, Tony Lownds wrote:

> tk_getSaveFile doesn't accept unix-style pathnames.
>
> () 5 % tk_getSaveFile -initialdir /
> bad directory "/"
> () 6 % tk_getSaveFile -initialdir :         -- works fine
> () 7 % tk_getSaveFile                       -- works fine
>
> Note that the 'pwd' and 'file join' commands both use /
>
> () 11 % pwd
> /
>
> () 12 % file exists /
> 1
>
> -Tony
> --
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

[MACTCL] Bug in tk_getSaveFile on OSX

[Tony L. <to...@me...>]

tk_getSaveFile doesn't accept unix-style pathnames.

() 5 % tk_getSaveFile -initialdir /
bad directory "/"
() 6 % tk_getSaveFile -initialdir :         -- works fine
() 7 % tk_getSaveFile                       -- works fine

Note that the 'pwd' and 'file join' commands both use /

() 11 % pwd
/

() 12 % file exists /
1

-Tony
-- 

Re: [MACTCL] Error compiling TCL for MacOS X

[Jim I. <ji...@ap...>]

On 12/12/01 2:38 PM, "Ruediger Goetz" <rg...@r-...> wrote:

> Hello,
>=20
>=20
>=20
> <snip>
>>>=20
>>> Unfortunately, it doens't say 'Build Succeeded', but 'Building Make ...=
(1
>>> error, 1 warning)' (I skiped the
>>> warning.
>>>=20
>>> And hence it doesn't install anything. And if I compile Tk. it complain=
s in
>>> the end about=20
>>> 'can't locate framework for -framework Tcl'. It looks to me that someth=
ing
>>> went wrong, somehow.
>>>=20
>>>=20
>>> Yours=20
>>>=20
>>> R=FCdiger Goetz
>>>=20
>>>=20
>>> -=20
>>> R"udiger Goetz
>>> rg...@r-...
>>> WWW: http://www.r-goetz.de
>>> Mail send by a Mac running Linux (SuSE-PPC)
>>>=20
>>> _______________________________________________
>>> Tcl-mac mailing list
>>> Tc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>>>=20
>>=20
>> Which target did you build?  You need to build the "Tcl From Scratch" ta=
rget
>> to get the framework (or build all the other targets in sequence.)
>>=20
>> Jim
>> --=20
>> ++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
>> Jim Ingham                              ji...@ap...
>> Developer Tools - gdb
>=20
> Thats waht I did
>=20
> Yours
>=20
> R"udiger Goetz
>=20

When you look at the build logs (you have to set building logs to "Detailed=
"
in PB for this to be really useful) do you see lots of messages about stuff
like the .tcl files getting copied into the final product?

The Project Builder build targets don't actually install anything, they jus=
t
assemble the framework in whatever you have told PB to use for its Products
folder. Depending on whether you have chosen a separate build folder in the
PB Building Preferences or not, the results will either be in the Products
folder you have selected, or in a "build" folder under the macosx folder of
Tcl & Tk if you have not selected one.

The most convenient way to build Tcl/Tk is to set a common Build products
folder in the PB Building Preferences.  Then both the Tcl & Tk frameworks
will be put in the same folder, and when you run the Wish Shell under the
debugger, PB will set DYLD_FRAMEWORK_PATH correctly so that both frameworks
will be found. =20

Then when you make a Tix project, you can build it in the same way, and
everything will be happy.

Jim
--=20
++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Error compiling TCL for MacOS X

[Ruediger G. <rg...@r-...>]

Hello,



<snip>
>> 
>> Unfortunately, it doens't say 'Build Succeeded', but 'Building Make ...(1
>> error, 1 warning)' (I skiped the
>> warning.
>> 
>> And hence it doesn't install anything. And if I compile Tk. it complains in
>> the end about 
>> 'can't locate framework for -framework Tcl'. It looks to me that something
>> went wrong, somehow.
>> 
>> 
>> Yours 
>> 
>> Rüdiger Goetz
>> 
>> 
>> - 
>> R"udiger Goetz
>> rg...@r-...
>> WWW: http://www.r-goetz.de
>> Mail send by a Mac running Linux (SuSE-PPC)
>> 
>> _______________________________________________
>> Tcl-mac mailing list
>> Tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>> 
>
>Which target did you build?  You need to build the "Tcl From Scratch" target
>to get the framework (or build all the other targets in sequence.)
>
>Jim
>-- 
>++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
>Jim Ingham                              ji...@ap...
>Developer Tools - gdb

Thats waht I did

Yours

R"udiger Goetz


-- 
R"udiger Goetz
rg...@r-...
WWW: http://www.r-goetz.de
Mail send by a Mac running Linux (SuSE-PPC)

Re: [MACTCL] Error compiling TCL for MacOS X

[Jim I. <ji...@ap...>]

On 12/12/01 2:05 PM, "Ruediger Goetz" <rg...@r-...> wrote:

> Hello,
>=20
> On Wed, 12 Dec 2001, Jim Ingham  was inspired to say:
>> On 12/12/01 12:58 PM, "Ruediger Goetz" <rg...@r-...> wrote:
>>=20
>>> Hello,
>>>=20
>>> I just draw the source from the cvs (macos-x-branch) and tried to compi=
le
>>> (in order to get everything ready for tix). Unfortinately I run into th=
e
>>> folloeing
>>> error:
>>>=20
>>> In file included from   .....TK/tcl/macosx/../unix/../unix/tclUnixInit.=
c
>>> In file included from
>>> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundat=
ion.h
>>>    warning: passing arg 1 of 'CFSwitch16' with diffrent width due to
>>> prototype
>>>=20
>>> Though its called 'warning' its handled as an error by the Project Buil=
der.
>>>=20
>>> Any ideas what went wrong?
>>> It just my first experience with the Project Builder (I used code on Li=
nux
>>> with Makefile, but like to get tix running natively on OS X as mentiond
>>> earlier)
>>>=20
>>> Yours
>>>=20
>>> R"udiger Goetz
>>>=20
>>> --
>>> R"udiger Goetz
>>> rg...@r-...
>>> WWW: http://www.r-goetz.de
>>> Mail send by a Mac running Linux (SuSE-PPC)
>>>=20
>>> _______________________________________________
>>> Tcl-mac mailing list
>>> Tc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>>>=20
>>=20
>> Rudiger,
>>=20
>> This is a Project Builder bug.  When it runs gcc from a regular PB proje=
ct,
>> it passes some funny options to gcc to help it to parse the gcc output. =
 But
>> when it runs a "Legacy Makefile" target (which is what the Tcl project i=
s)
>> it doesn't have this help, and sometimes mis-parses the output, and thin=
ks
>> that warnings are errors.  Note, however, that the status bar says:
>>=20
>> Build Succeeded (5 errors)
>>=20
>> So it sort of knows what happened.  I reported this to the PB folks, and
>> they will fix it at some point (though it is probably not their first
>> priority...) =20
>>=20
>> I should also go clean up the warnings, I need to do a general warning
>> cleanup, there aren't many in Tcl, but there are way too many in Tk.  Bu=
t I
>> haven't gotten to this yet.
>>=20
>> Anyway, your build of Tcl is fine.
>>=20
>=20
> Unfortunately, it doens't say 'Build Succeeded', but 'Building Make ...(1
> error, 1 warning)' (I skiped the
> warning.
>=20
> And hence it doesn't install anything. And if I compile Tk. it complains =
in
> the end about=20
> 'can't locate framework for -framework Tcl'. It looks to me that somethin=
g
> went wrong, somehow.
>=20
>=20
> Yours=20
>=20
> R=FCdiger Goetz
>=20
>=20
> -=20
> R"udiger Goetz
> rg...@r-...
> WWW: http://www.r-goetz.de
> Mail send by a Mac running Linux (SuSE-PPC)
>=20
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>=20

Which target did you build?  You need to build the "Tcl From Scratch" targe=
t
to get the framework (or build all the other targets in sequence.)

Jim
--=20
++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Error compiling TCL for MacOS X

[Ruediger G. <rg...@r-...>]

Hello,

On Wed, 12 Dec 2001, Jim Ingham  was inspired to say:
>On 12/12/01 12:58 PM, "Ruediger Goetz" <rg...@r-...> wrote:
>
>> Hello,
>> 
>> I just draw the source from the cvs (macos-x-branch) and tried to compile
>> (in order to get everything ready for tix). Unfortinately I run into the
>> folloeing
>> error:
>> 
>> In file included from   .....TK/tcl/macosx/../unix/../unix/tclUnixInit.c
>> In file included from
>> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h
>>    warning: passing arg 1 of 'CFSwitch16' with diffrent width due to prototype
>> 
>> Though its called 'warning' its handled as an error by the Project Builder.
>> 
>> Any ideas what went wrong?
>> It just my first experience with the Project Builder (I used code on Linux
>> with Makefile, but like to get tix running natively on OS X as mentiond
>> earlier)
>> 
>> Yours
>> 
>> R"udiger Goetz
>> 
>> --
>> R"udiger Goetz
>> rg...@r-...
>> WWW: http://www.r-goetz.de
>> Mail send by a Mac running Linux (SuSE-PPC)
>> 
>> _______________________________________________
>> Tcl-mac mailing list
>> Tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>> 
>
>Rudiger,
>
>This is a Project Builder bug.  When it runs gcc from a regular PB project,
>it passes some funny options to gcc to help it to parse the gcc output.  But
>when it runs a "Legacy Makefile" target (which is what the Tcl project is)
>it doesn't have this help, and sometimes mis-parses the output, and thinks
>that warnings are errors.  Note, however, that the status bar says:
>
>Build Succeeded (5 errors)
>
>So it sort of knows what happened.  I reported this to the PB folks, and
>they will fix it at some point (though it is probably not their first
>priority...)  
>
>I should also go clean up the warnings, I need to do a general warning
>cleanup, there aren't many in Tcl, but there are way too many in Tk.  But I
>haven't gotten to this yet.
>
>Anyway, your build of Tcl is fine.
>

Unfortunately, it doens't say 'Build Succeeded', but 'Building Make ...(1 error, 1 warning)' (I skiped the
warning.

And hence it doesn't install anything. And if I compile Tk. it complains in the end about 
'can't locate framework for -framework Tcl'. It looks to me that something went wrong, somehow.


Yours 

Rüdiger Goetz


- 
R"udiger Goetz
rg...@r-...
WWW: http://www.r-goetz.de
Mail send by a Mac running Linux (SuSE-PPC)

Re: [MACTCL] Error compiling TCL for MacOS X

[Jim I. <ji...@ap...>]

On 12/12/01 12:58 PM, "Ruediger Goetz" <rg...@r-...> wrote:

> Hello,
> 
> I just draw the source from the cvs (macos-x-branch) and tried to compile
> (in order to get everything ready for tix). Unfortinately I run into the
> folloeing
> error:
> 
> In file included from   .....TK/tcl/macosx/../unix/../unix/tclUnixInit.c
> In file included from
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h
>    warning: passing arg 1 of 'CFSwitch16' with diffrent width due to prototype
> 
> Though its called 'warning' its handled as an error by the Project Builder.
> 
> Any ideas what went wrong?
> It just my first experience with the Project Builder (I used code on Linux
> with Makefile, but like to get tix running natively on OS X as mentiond
> earlier)
> 
> Yours
> 
> R"udiger Goetz
> 
> --
> R"udiger Goetz
> rg...@r-...
> WWW: http://www.r-goetz.de
> Mail send by a Mac running Linux (SuSE-PPC)
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Rudiger,

This is a Project Builder bug.  When it runs gcc from a regular PB project,
it passes some funny options to gcc to help it to parse the gcc output.  But
when it runs a "Legacy Makefile" target (which is what the Tcl project is)
it doesn't have this help, and sometimes mis-parses the output, and thinks
that warnings are errors.  Note, however, that the status bar says:

Build Succeeded (5 errors)

So it sort of knows what happened.  I reported this to the PB folks, and
they will fix it at some point (though it is probably not their first
priority...)  

I should also go clean up the warnings, I need to do a general warning
cleanup, there aren't many in Tcl, but there are way too many in Tk.  But I
haven't gotten to this yet.

Anyway, your build of Tcl is fine.

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] Error compiling TCL for MacOS X

[Ruediger G. <rg...@r-...>]

Hello,

I just draw the source from the cvs (macos-x-branch) and tried to compile
(in order to get everything ready for tix). Unfortinately I run into the folloeing
error:

In file included from   .....TK/tcl/macosx/../unix/../unix/tclUnixInit.c
  In file included from  /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h       
     warning: passing arg 1 of 'CFSwitch16' with diffrent width due to prototype

Though its called 'warning' its handled as an error by the Project Builder.

Any ideas what went wrong?
It just my first experience with the Project Builder (I used code on Linux
with Makefile, but like to get tix running natively on OS X as mentiond earlier)

Yours

R"udiger Goetz

--
R"udiger Goetz
rg...@r-...
WWW: http://www.r-goetz.de
Mail send by a Mac running Linux (SuSE-PPC)

Re: [MACTCL] under OSX, including tests of widget demo

[Jim I. <ji...@ap...>]

On 12/12/01 9:22 AM, "Franc Brglez" <br...@cb...> wrote:

> Jim,
> 
> Last month you kindly instructed us how to install latest version of tk
> under OSX. It turned out that our tcltk application (already crossplatform,
> including under macOS9.2) is too complex for a quick fix under OSX -- it
> requires augmenting the "standard mac OS9.x" distribution with packages
> such as latest tcllib, tclxml, BWidget, TclSOAP, TclDOM. Some missing
> features are also listed under our "widget test" below.
> 
> Soon afterwards, I left for Europe with the Titanium, resigned to demo
> under OS9.2 -- only to find out in the last moment that Titanimum would
> synchronize with the projector under OSX only -- so while I could still
> project PowerPoint under OSX, I could not do the same for the tcltk
> application.
> 
> We are trying to figure out what chances we have for a "quick"
> cross-plaform tcltk port to OSX. We have a number of concerns:
> 
> (1) the structure of current tcltk-installed directory has no resemblance
> to 9.2 and earlier generation. Even the nominal "widget test" directory
> appears to be missing. The 9.2 structure makes the "nominal mac
> distribution" easier to augment with missing parts from a standard linux
> distribution. How are we to proceed with augmenting the "standard OSX
> distribution".

The widget test is still there.  For instance, just start up the Wish
Shell.app, and do:

source [file join $tk_library demos widget]

What used to be in the Tool Command Language folder on Classic MacOS is now
in the Resources/Scripts folder in each of the frameworks.

> 
> (2) can we hope for a quick fix to the current version of wish-OSX, so that
> the entire widget directory works as in the earlier versions .... I have
> results from my tests below -- it appears that fixing the "stdout" channel
> problem would fix a number of related problems ..... this is my entire
> problem list:
> 
>  labels #8
>      no images are displayed
> 

This is probably just because you aren't setting up the paths for the widget
demo correctly.  If you use the one that is part of the Tk framework, as
shown above, I bet this will work fine.


>  menus #2 (menu buttons)
>  bgerror failed to handle background error.
>      Original error: can not find channel named "stdout"
>      Error in bgerror: invalid command name "sting"
> 
>  misc #2, #3 (both grab commands)
>  bgerror failed to handle background error.
>      Original error: can not find channel named "stdout"
>      Error in bgerror: invalid command name "sting"
> 

This was a bug that is fixed in the current sources in the macosx-8-4-branch
version of Tk.  It is pretty easy to build this, there are instructions in
the announcement I sent with the first binary.

> Any comments and suggestions on these experiences would be most appreciated.
> 

For other packages, you have two problems, building the ones that need
building, and getting Tcl to find them...  Building the Tcl only ones that
you mentioned is not too hard, it is easier if you build Tcl, and then point
the new packages at the tclConfig.sh in the framework.  Most of the
extension configury prefers the build version of Tcl to the installed, and
will find all the things they need.

On getting Tcl to find them.  I need to work out how I want to seed the
tcl_pkgPath, and the auto_path, for Tcl on MacOS X.  I was struggling just
to get it to find the Framework versions of packages at first.  This works
now, and so the next step is to seed the pkg path both with the typical
Unix'y places to find stuff, and somewhere in ~/Library, /Library, and
/System/Library.  For now, you can just seed it  yourself with wherever you
are putting stuff.  One thing that would work for a stand-alone app is to
put tcllib, etc in the Resources/Scripts folder of your App package.  This
gets added to the auto_path by default, so packages here should get found
automatically...

Hope this helps,

Jim

> MANY THANKS -- Franc Brglez
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] under OSX, including tests of widget demo

[Franc B. <br...@cb...>]

Jim,

Last month you kindly instructed us how to install latest version of tk
under OSX. It turned out that our tcltk application (already crossplatform,
including under macOS9.2) is too complex for a quick fix under OSX -- it
requires augmenting the "standard mac OS9.x" distribution with packages
such as latest tcllib, tclxml, BWidget, TclSOAP, TclDOM. Some missing
features are also listed under our "widget test" below.

Soon afterwards, I left for Europe with the Titanium, resigned to demo
under OS9.2 -- only to find out in the last moment that Titanimum would
synchronize with the projector under OSX only -- so while I could still
project PowerPoint under OSX, I could not do the same for the tcltk
application.

We are trying to figure out what chances we have for a "quick"
cross-plaform tcltk port to OSX. We have a number of concerns:

(1) the structure of current tcltk-installed directory has no resemblance
to 9.2 and earlier generation. Even the nominal "widget test" directory
appears to be missing. The 9.2 structure makes the "nominal mac
distribution" easier to augment with missing parts from a standard linux
distribution. How are we to proceed with augmenting the "standard OSX
distribution".

(2) can we hope for a quick fix to the current version of wish-OSX, so that
the entire widget directory works as in the earlier versions .... I have
results from my tests below -- it appears that fixing the "stdout" channel
problem would fix a number of related problems ..... this is my entire
problem list:

   labels #8
       no images are displayed

   menus #2 (menu buttons)
   bgerror failed to handle background error.
       Original error: can not find channel named "stdout"
       Error in bgerror: invalid command name "sting"

   misc #2, #3 (both grab commands)
   bgerror failed to handle background error.
       Original error: can not find channel named "stdout"
       Error in bgerror: invalid command name "sting"

Any comments and suggestions on these experiences would be most appreciated.

MANY THANKS -- Franc Brglez

RE: [MACTCL] Re: TkPutImage crash on very wide images

[Schollnick, B. <Ben...@us...>]

Now, please keep in mind, I haven't gone through the MacPython
source code, but I've seen the identical symptoms...

Here's my summary:

	Is there any reason that Tkinter (Tkinter.Tk()) Initialization
	might fail, if it already exists?

	i.e.

		Test = Tkinter.Tk()
		Test2 = Tkinter.Tk()

	What was happening was that I initialized Tk, and then
	I didn't pass the Root to the Wizard GUI package... Which
	then initialized it again...

	But, as I am apt to do, this does not cause an issue on the
	PC Python (Cpython)....

	I already posted a inquiry on the mac-tcl list,
	but will follow that up....

	But, I assume this is a Tcl core issue?  And what version of
	Tcl did Python v2.11 ship with?

Right from the source...(From the MacTCL list):

> From: Jim Ingham [mailto:ji...@ap...]
> Sent: Wednesday, November 07, 2001 2:39 PM
> To: Schollnick, Benjamin
> Cc: 'tc...@li...'
> Subject: Re: [MACTCL] RE: Problems with Mac TCL?
>
>
> Benjamin,
>
> First off, Tcl/Tk is not designed to allow you to load two independent
> copies of Tk into an application.  There is global state in the
> libraries that will cause conflicts.  So you have to make sure that you
> unload the first copy completely before you try to load the second
> copy.  You can create two tcl interpreters, both running Tk, but the way
> you are supposed to do that is to create one interpreter, and then load
> Tk into the second interpreter by running "package require Tk" in the
> second interpreter.  This is, for example, how the console window in
> MacTk works.  But we never intended you to be able to actually load the
> Tk library twice.
>
> Theoretically, you could load Tk, then unload it. However, I never
> worked very hard to make sure that you could unload Tcl/Tk from an app,
> and then reload it again cleanly.  There are finalization routines for
> all the subsystems, but I would have no problem believing they don't
> clean up everything.  The only things I really cared about was
> non-shared state, and resources that the system would not reap when the
> process exited.  You could probably fix this - since the mechanism to
> handle finalization is present.

What I suspect is happening is, since the IDE never unloads, the TK/Tcl
library's are still initialized.... The second time you run the program,
the library attempts to initialize, can't grab/generate the "Window ID#256" 
and fails.... 

(This is the assumption)  The IDE imports the library's into it's own
name space, since in Classic there no way to make a "truly" separate
process.... (In Mac OS X, probably that would spawn another process.)

Sorry if I was not clear enough, previously....

I still think this is a problem, especially since the PC (aka Cpython)
version doesn't have this problem.... But when I (briefly) examined
Tkinter.py
I didn't see anyway to work around this issue, without causing significant
code issues between the PC & Mac versions of python....

			- Benjamin

-----Original Message-----
From: Jim Ingham [mailto:ji...@ap...]
Sent: Monday, December 10, 2001 1:23 PM
To: Daniel A. Steffen
Cc: tc...@li...; sca...@la...
Subject: [MACTCL] Re: TkPutImage crash on very wide images


Daniel,

On Sunday, December 9, 2001, at 11:31  PM, Daniel A. Steffen wrote:

> Dear All,
>
> tkMacDraw.c's TkPutImage crashes in CopyBits when using very wide 
> images.
>
> I have a case here where a Tk app (which is working fine on unix & win) 
> uses an image 4846 pixels wide (and 32 bits deep), which results in a 
> bytes_per_line value of 0x4BB8. However, according to IM, PixMap's 
> maximal value for rowBytes is 0x3FFF (c.f. [1]) and indeed CopyBits 
> crashes on the PixMap constructed by TkPutImage with
> 	pixmap.rowBytes = image->bytes_per_line | 0x8000;
> (rowBytes is a short whose high 2 bits are used as QD flags, thus the 
> 0x3FFF limit)
>
> In practical terms this means that Tk will crash when using any 32bit 
> image wider than 4095 pixels.
>
> Not sure what the best solution is here, I've now added a panic before 
> the CopyBits to at least exit gracefully, a better solution would be to 
> split the image into blocks that are maximally 0x4000 bytes wide and do 
> CopyBits on each block... The question is how common is the use of 
> images this wide, is it worth putting in time to get this to work?
>

This depends on how much free time you have.  Not many screens can 
display an image this big, so I wouldn't imagine this is all that common.

> BTW, this problem almost certainly also exist on TkAqua, as TkPutImage 
> is essentially unchanged in tkMacOSXDraw.c (and Carbon CopyBits still 
> uses Bit 15 as a flag)
>

Yes, but I would solve this problem on X not by breaking the image up, 
as you would have to on 9, but by replacing CopyBits with a CoreGraphics 
problem at some point, since that would also open the possibility of 
compositing with alpha channels as well.  So I don't think this is a 
motivation to do this work on 9 (of course, who knows when I will get 
around to this...)

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer


_______________________________________________
Tcl-mac mailing list
Tc...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-mac