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

Re: [MACTCL] Itcl on MacOSX

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

On 2/14/02 4:56 PM, "Daniel Lopez" <da...@ra...> wrote:

> 
>> Daniel,
>> 
>> Two things here.  First, ot doesn't look like you are including the Tcl
>> library in your link line for tk.  But that doesn't much matter, the port of
> 
> Do you know why Tk is not picking it up?

Nope, sorry.  Haven't tried this.

> 
> 8.3.3 had no trouble looking in ../tcl8.3.3 to find it.
> In 8.3.4, it does not find tcl even if I have it in .. or pass ithe
> --with-tcl option it does not pickit it up
> I tried also adding a -ltcl8.3 by hand and I get the same error
> 
>> Tk to Mac OS X postdates 8.3.4, and in fact hasn't been checked onto the
>> HEAD of the 8.4 branch.  You want to check out the macosx-8-4-branch branch
>> of the tcl & tk sources if you want Tk for Mac OS X.  The other option is to
>> get Xfree, and use that to compile with Tk.
> 
> Xfree is ok. I am not that concerned about the look and feel as it is to get
> it to work.

I talked to a couple of folks who use this.  With the 8.3.4 sources
configure/make worked pretty straightforwardly...  You might check out the
Fink distro (http://fink.sourceforge.net)  - they have Tcl/Tk for Xfree,
with lots of other goodies.  They don't seem to have Itcl, but I bet getting
Tcl/Tk/Xfree on your system is going to be the hard part...

> 
> I will give it a try with the macosx-8-4-branch, will it work with latest
> Itcl?

You will have to monkey a bit to get it built, but it should work.

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

Re: [MACTCL] Itcl on MacOSX

[Daniel L. <da...@ra...>]

> Daniel,
> 
> Two things here.  First, ot doesn't look like you are including the Tcl
> library in your link line for tk.  But that doesn't much matter, the port of

Do you know why Tk is not picking it up? 
 
 8.3.3 had no trouble looking in ../tcl8.3.3 to find it.
 In 8.3.4, it does not find tcl even if I have it in .. or pass ithe
 --with-tcl option it does not pickit it up 
 I tried also adding a -ltcl8.3 by hand and I get the same error

> Tk to Mac OS X postdates 8.3.4, and in fact hasn't been checked onto the
> HEAD of the 8.4 branch.  You want to check out the macosx-8-4-branch branch
> of the tcl & tk sources if you want Tk for Mac OS X.  The other option is to
> get Xfree, and use that to compile with Tk.

Xfree is ok. I am not that concerned about the look and feel as it is to get
it to work.

I will give it a try with the macosx-8-4-branch, will it work with latest Itcl?

Best regards

Daniel

Re: [MACTCL] Itcl on MacOSX

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

Daniel,

Two things here.  First, ot doesn't look like you are including the Tcl
library in your link line for tk.  But that doesn't much matter, the port of
Tk to Mac OS X postdates 8.3.4, and in fact hasn't been checked onto the
HEAD of the 8.4 branch.  You want to check out the macosx-8-4-branch branch
of the tcl & tk sources if you want Tk for Mac OS X.  The other option is to
get Xfree, and use that to compile with Tk.

Jim

>> you should use 8.3.4 or the 8.4 cvs HEAD which have fixes that should
>> take care of both the build problem and the dyld problem (8.3.3 was
>> using an older dyld api to load tcl extension that were linked as
>> dyld bundles not shared libraries).
>> 
>> see also http://www.maths.mq.edu.au/~steffen/tcltk/darwin.html
> 
> I tried with 8.3.4
> Tcl compiles right away, with Tk I get now the following error.
> I think it is looking for the Tcl libraries but cannot find them.
> I have tried to tweak the Makefile but with no luck, any ideas?
> 
> Thanks
> 
> Daniel
> 
> [localhost:~/test/tk8.3.4/unix] daniel% make
> rm -f libtk8.3.dylib
> cc -dynamiclib -prebind  -o libtk8.3.dylib tk3d.o tkArgv.o tkAtom.o tkBind.o
> tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o
> tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
> tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o
> tkPack.o tkPlace.o tkSelect.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o
> tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o
> tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o
> tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o
> tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o
> tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o
> tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o tkScrollbar.o tkCanvas.o
> tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o
> tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o
> tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o
> tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
> tkTextWind.o  -L/Users/daniel/install/lib
> ld: warning prebinding disabled because of undefined symbols
> ld: Undefined symbols:
> _Tcl_DeleteHashEntry
> _Tcl_Free
> _Tcl_GetIndexFromObj
> _Tcl_GetString
> _Tcl_InitHashTable
> _Tcl_ListObjAppendElement
> [...]
> _Tcl_UniCharIsAlpha
> _Tcl_UtfToLower
> _XRectInRegion
> _Tcl_UtfPrev
> /usr/bin/libtool: internal link edit command failed
> make: *** [libtk8.3.dylib] Error 1
> [localhost:~/test/tk8.3.4/unix] daniel%
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

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

Re: [MACTCL] Itcl on MacOSX

[Daniel L. <da...@ra...>]

> you should use 8.3.4 or the 8.4 cvs HEAD which have fixes that should 
> take care of both the build problem and the dyld problem (8.3.3 was 
> using an older dyld api to load tcl extension that were linked as 
> dyld bundles not shared libraries).
> 
> see also http://www.maths.mq.edu.au/~steffen/tcltk/darwin.html

I tried with 8.3.4
Tcl compiles right away, with Tk I get now the following error.
I think it is looking for the Tcl libraries but cannot find them.
I have tried to tweak the Makefile but with no luck, any ideas?

Thanks

Daniel

[localhost:~/test/tk8.3.4/unix] daniel% make
rm -f libtk8.3.dylib
cc -dynamiclib -prebind  -o libtk8.3.dylib tk3d.o tkArgv.o tkAtom.o tkBind.o
tkBitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o
tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o
tkPack.o tkPlace.o tkSelect.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o
tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o
tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o
tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o
tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o
tkStubInit.o tkStubLib.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o
tkMenubutton.o tkMenuDraw.o tkMessage.o tkScale.o tkScrollbar.o tkCanvas.o
tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o
tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o
tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o
tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
tkTextWind.o  -L/Users/daniel/install/lib
ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_Tcl_DeleteHashEntry
_Tcl_Free
_Tcl_GetIndexFromObj
_Tcl_GetString
_Tcl_InitHashTable
_Tcl_ListObjAppendElement
[...]
_Tcl_UniCharIsAlpha
_Tcl_UtfToLower
_XRectInRegion
_Tcl_UtfPrev
/usr/bin/libtool: internal link edit command failed
make: *** [libtk8.3.dylib] Error 1
[localhost:~/test/tk8.3.4/unix] daniel%

Re: [MACTCL] Itcl on MacOSX

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

you should use 8.3.4 or the 8.4 cvs HEAD which have fixes that should 
take care of both the build problem and the dyld problem (8.3.3 was 
using an older dyld api to load tcl extension that were linked as 
dyld bundles not shared libraries).

see also http://www.maths.mq.edu.au/~steffen/tcltk/darwin.html

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/>

[MACTCL] Itcl on MacOSX

[Daniel L. <da...@ra...>]

I am trying to port a ITcl based program to OSX. I have no previous
experience with this OS, I would appreciate some help.

I have compiled tcl8.3.3 and tk8.3.3 with no problems.
(./configure --prefix=/home/daniel/test; make; make install)
I try to compile itcl, get some errors, manually finish the compilation (for
details, see below) and do a make install. However, when I do a 

package require Itcl 

it dies with the following error:
dyld: inappropriate Mach-O file

It seems the shared library is not good, but I do not know how to
troubleshoot this. Any hints? Alternatively, is there somewhere I can get a
precompiled Tcl/Tk/Itcl suite?

Thanks

Daniel

The following is the detailed trail:

[localhost:~/test/itcl3.2.1/itcl] daniel% make
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itclStubInit.c -o itclStubInit.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itcl_bicmds.c
-o itcl_bicmds.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itcl_class.c
-o itcl_class.o
./generic/itcl_class.c: In function Itcl_CreateClass':
./generic/itcl_class.c:216: warning: passing arg 2 of pointer to function
from incompatible pointer type
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itcl_cmds.c
-o itcl_cmds.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_ensemble.c -o itcl_ensemble.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_linkage.c -o itcl_linkage.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_methods.c -o itcl_methods.o
./generic/itcl_methods.c: In function Itcl_GetMemberFuncUsage':
./generic/itcl_methods.c:1370: warning: passing arg 2 of pointer to function
discards qualifiers from pointer target type
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_migrate.c -o itcl_migrate.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_objects.c -o itcl_objects.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo
./generic/itcl_obsolete.c -o itcl_obsolete.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itcl_parse.c
-o itcl_parse.o
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itcl_util.c
-o itcl_util.o
rm -f libitcl3.2.dylib
cc -dynamiclib  -compatibility_version 8 -current_version 3.2 -install_name
/ -o libitcl3.2.dylib  itclStubInit.o itcl_bicmds.o itcl_class.o itcl_cmds.o
itcl_ensemble.o itcl_linkage.o itcl_methods.o itcl_migrate.o itcl_objects.o
itcl_obsolete.o itcl_parse.o itcl_util.o  -L/Users/daniel/test/tcl8.3.3/unix
-ltclstub8.3
ld: archive: /Users/daniel/test/tcl8.3.3/unix/libtclstub8.3.a has no table
of contents, add one with ranlib(1) (can't load from it)
/usr/bin/libtool: internal link edit command failed


[localhost:~/test/itcl3.2.1/itcl] daniel% ranlib /Users/daniel/test/tcl8.3.3/unix/libtclstub8.3.a
[localhost:~/test/itcl3.2.1/itcl] daniel% make
rm -f libitcl3.2.dylib
cc -dynamiclib  -compatibility_version 8 -current_version 3.2 -install_name
/ -o libitcl3.2.dylib  itclStubInit.o itcl_bicmds.o itcl_class.o itcl_cmds.o
itcl_ensemble.o itcl_linkage.o itcl_methods.o itcl_migrate.o itcl_objects.o
itcl_obsolete.o itcl_parse.o itcl_util.o  -L/Users/daniel/test/tcl8.3.3/unix
-ltclstub8.3
: libitcl3.2.dylib
cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1
-DITCL_LIBRARY=\"/home/daniel/test/install/lib/itcl3.2\"
-I/Users/daniel/test/tcl8.3.3/generic -I/Users/daniel/test/tcl8.3.3/unix
-I"./generic" -I"./unix"    -O3  -fno-common -c echo ./generic/itclStubLib.c
-o itclStubLib.o
rm -f libitclstub3.2.a
ar cr libitclstub3.2.a itclStubLib.o
: libitclstub3.2.a
[localhost:~/test/itcl3.2.1/itcl] daniel% make install
/bin/sh ./../config/mkinstalldirs  /home/daniel/test/install/lib
/bin/sh ./../config/mkinstalldirs  /home/daniel/test/install/bin
/bin/sh ./../config/mkinstalldirs  /home/daniel/test/install/lib/itcl3.2
/bin/sh ./../config/mkinstalldirs  /home/daniel/test/install/lib/itcl3.2
 /home/daniel/test/install/bin/tclsh8.3 ./../config/installFile.tcl -c
libitcl3.2.dylib /home/daniel/test/install/lib/libitcl3.2.dylib
 /home/daniel/test/install/bin/tclsh8.3 ./../config/installFile.tcl -c
libitclstub3.2.a /home/daniel/test/install/lib/libitclstub3.2.a
 : /home/daniel/test/install/lib/libitcl3.2.dylib
  : /home/daniel/test/install/lib/libitclstub3.2.a
  /home/daniel/test/install/bin/tclsh8.3 echo ./../config/installFile.tcl -c
-m 644 pkgIndex.tcl /home/daniel/test/install/lib/itcl3.2
/bin/sh ./../config/mkinstalldirs /home/daniel/test/install/include
Installing header files in /home/daniel/test/install/include
Installing ./generic/itcl.h
Installing ./generic/itclDecls.h
Installing ./generic/itclInt.h
Installing ./generic/itclIntDecls.h
Installing library files in /home/daniel/test/install/lib/itcl3.2
Installing ./library/itcl.tcl
/bin/sh ./../config/mkinstalldirs /home/daniel/test/install/man/mann
Installing man pages in /home/daniel/test/install/man
Installing ./doc/body.n
Installing ./doc/class.n
Installing ./doc/code.n
Installing ./doc/configbody.n
Installing ./doc/delete.n
Installing ./doc/ensemble.n
Installing ./doc/find.n
Installing ./doc/itcl.n
Installing ./doc/itcl_class.n
Installing ./doc/itcl_info.n
Installing ./doc/itclvars.n
Installing ./doc/local.n
Installing ./doc/scope.n
[localhost:~/test/itcl3.2.1/itcl] daniel%
/home/daniel/test/install/bin/tclsh8.3
% package require Itcl
dyld: inappropriate Mach-O file

[MACTCL] Pack forget problem

[<Ge...@Or...>]

I have an app I'm developing for a client under MacOS 9.1.*.
I mean I'm developing it under Unix for target environment MacOS. 

There's a "pack forget <widget>" problem, whereas the
named widget hierarchy is not fully unmapped. And when
focus (click) is brought to the desktop, the rest of the
supposedly forgotten widget is crudely displayed over
the newly packed one. 

The two widget hierarchies, .f and .s (both of which are
frames holding other widgets) will pack and forget fine
under Solaris, fail under MacOS. The test meant starting
wish, sourcing the main file, clicking on a button to
get to the second screen (pack forget .f worked once before
packing the second screen .s, but switching back by forgetting
.s and packing .f again yields the bizarre behavior). 

With the second screen sitting there, I manually issue a
forget for .s and a pack for .f. No problem doing this
under Unix, back and forth even between the two (repeatedly
forgetting one and packing the other). But disaster under MacOS. 

I point this out to say it seems like a true bug of some
sort and not a problem with the application. 

I tried a simple test with two labels .f, .s under MacOS.
They pack and forget fine. 

So it's something more involved. 

I couldn't find any listed bugs that would involve this.
It's the latest (8.3.4?) ActiveState release. 

Before I ask for a volunteer to check out my source,
any ideas or suggestions?

Re: [MACTCL] Loops in ArrangePacking

[James B. <jk...@mr...>]

In poor style I'll follow up on my own message...

iwidgets/tabnotebook.itk sets the default padx and pady to be 4. Older Tk
releases didn't have a -padx option on frames, but I think this must have been 
added in 8.4.

Hence the frame (iwidgets "hull") gets padx 4 and pady 4, which implies that
the size of the canvas embedded within it is not the same. This causes a loop
due to the rather strange _resize function:

# -------------------------------------------------------------
# PRIVATE METHOD: _resize
#
# This method added by csmith, 5/1/01, to fix a bug with the
# geometry of the tabnotebook.  The hull component's geometry
# was not being updated properly on <Configure> events.
# -------------------------------------------------------------
body iwidgets::Tabnotebook::_resize {newWidth_ newHeight_} {
  _canvasReconfigure $newWidth_ $newHeight_
  update idletasks
  component hull configure -width $newWidth_ -height $newHeight_
}

The solution is obvious - just configure the hull to be -padx 0 -pady 0.
This still looks like a dangerous approach.

Anyway, this is clearly a iwidgets bug, but what's got me wondering now is
whether this happens on Unix. I've never noticed it before, but I'm not
running with 8.4 yet on unix so I that would avoid the issue.

Sorry to cause any alarm :) I'll submit this as an iwidgets bug.

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/

[MACTCL] Loops in ArrangePacking

[James B. <jk...@mr...>]

I'm not sure if this is a Tk or Itk bug. I'll put some more analysis into it
to see if I can figure it out some more. (Hence this isn't in sourceforge
bugs yet.)

I seem able to get nested loops within the ArrangePacking (and other)
functions when trying to create a window. Eg:

iwidgets::tabnotebook .nb
pack .nb

Using grid instead has the same problems. This causes a recursive loop which
quickly crashes the interpreter due to insufficient stack space.

...
#1921 0x00b7adf0 in ArrangePacking (clientData=0xa8dec0) at
../generic/tkPack.c:817
#1922 0x0039ef34 in TclServiceIdle () at
/Users/jkb/tcl/macosx/../unix/../generic/tclTimer.c:692
#1923 0x00386db0 in Tcl_DoOneEvent (flags=34) at
/Users/jkb/tcl/macosx/../unix/../generic/tclNotify.c:936
#1924 0x00b2e150 in Tk_UpdateObjCmd (clientData=0xb3230, interp=0x8cfe0,
objc=2, objv=0x8dd18) at ../generic/tkCmds.c:950
#1925 0x0034e648 in TclExecuteByteCode (interp=0x8cfe0, codePtr=0xaa4ec0) at
/Users/jkb/tcl/macosx/../unix/../generic/tclExecute.c:869
#1926 0x0031ed0c in Tcl_EvalObjEx (interp=0x8cfe0, objPtr=0xa3f7e8, flags=0)
at /Users/jkb/tcl/macosx/../unix/../generic/tclBasic.c:2951
#1927 0x009c8bc8 in Itcl_EvalMemberCode ()
#1928 0x009c9920 in Itcl_ExecMethod ()
#1929 0x009d3130 in Itcl_EvalArgs ()
#1930 0x009cc168 in Itcl_HandleInstance ()
#1931 0x0034e648 in TclExecuteByteCode (interp=0x8cfe0, codePtr=0xa923b0) at
/Users/jkb/tcl/macosx/../unix/../generic/tclExecute.c:869
#1932 0x0031ed0c in Tcl_EvalObjEx (interp=0x8cfe0, objPtr=0x967d8, flags=0) at 
/Users/jkb/tcl/macosx/../unix/../generic/tclBasic.c:2951
#1933 0x003852d8 in NamespaceInscopeCmd (dummy=0x0, interp=0x8cfe0, objc=4,
objv=0xbfffd77c) at /Users/jkb/tcl/macosx/../unix/../generic/tclNamesp.c:3356
#1934 0x0038426c in Tcl_NamespaceObjCmd (clientData=0x0, interp=0x8cfe0,
objc=4, objv=0xbfffd77c) at
/Users/jkb/tcl/macosx/../unix/../generic/tclNamesp.c:2525
#1935 0x0038a610 in EvalObjv (interp=0x8cfe0, objc=4, objv=0xbfffd77c,
command=0xbfffd930 "namespace inscope ::iwidgets::Tabnotebook {::.nb _resize
292 142}", length=65, flags=0) at
/Users/jkb/tcl/macosx/../unix/../generic/tclParse.c:932
#1936 0x0038b13c in Tcl_EvalEx (interp=0x8cfe0, script=0xbfffd930 "namespace
inscope ::iwidgets::Tabnotebook {::.nb _resize 292 142}", numBytes=65,
flags=0) at /Users/jkb/tcl/macosx/../unix/../generic/tclParse.c:1450
#1937 0x0038b5c0 in Tcl_Eval (interp=0x8cfe0, string=0xbfffd930 "namespace
inscope ::iwidgets::Tabnotebook {::.nb _resize 292 142}") at
/Users/jkb/tcl/macosx/../unix/../generic/tclParse.c:1605
#1938 0x00321094 in Tcl_GlobalEval (interp=0x8cfe0, command=0xbfffd930
"namespace inscope ::iwidgets::Tabnotebook {::.nb _resize 292 142}") at
/Users/jkb/tcl/macosx/../unix/../generic/tclBasic.c:4367
#1939 0x00afd298 in Tk_BindEvent (bindingTable=0x2b2670, eventPtr=0xbfffdcb8,
tkwin=0xa480f0, numObjects=0, objectPtr=0xbfffdb8c) at
../generic/tkBind.c:1780
#1940 0x00b2cea4 in TkBindEventProc (winPtr=0xa480f0, eventPtr=0xbfffdcb8) at
../generic/tkCmds.c:287
#1941 0x00b3d84c in Tk_HandleEvent (eventPtr=0xbfffdcb8) at
../generic/tkEvent.c:864
#1942 0x00baa440 in TkDoConfigureNotify (winPtr=0xa480f0) at
../generic/tkWindow.c:2125
#1943 0x00ba9db8 in Tk_MoveResizeWindow (tkwin=0xa480f0, x=4, y=4, width=292,
height=142) at ../generic/tkWindow.c:1821
#1944 0x00b7adf0 in ArrangePacking (clientData=0xa8dec0) at
../generic/tkPack.c:817
#1945 0x0039ef34 in TclServiceIdle () at
/Users/jkb/tcl/macosx/../unix/../generic/tclTimer.c:692

Clearly there's going to be one (or possibly two) rounds of resizing and
shuffling while the widgets are initially packed, but why does this recurse
forever?

I've seen the same action with one of own own C-coded widgets and a
scrollbar. Removing the scrollbar cured the loop, as did leaving the scrollbar 
but setting its borderwidth to 1.

I'll try and reconstruct a case using pure tcl/tk...

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/

Re: [MACTCL] latest build

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

Okay, folks...  Try this again.  It seems to have worked this time - 
there are bits there, and they download for me.

I spent yesterday merging in the TOT sources, but this binary is the 
snapshot BEFORE the merge.  I want to test the merged code a bit more 
before inflicting on the general public.  BUT, if anyone out there wants 
to check out the top of the macosx-8-4-branch and build it and play with 
it, that would be very helpful.

Jim

On Friday, February 1, 2002, at 02:21  PM, Jim Ingham wrote:

> Done, I made a new "release" in the SourceForge parlance.  I called it 
> (for lack of a better name) 8.4a4-2...  Anyway, it is what shows up in 
> the file releases page on the Tcl SourceForge page.
>
> Jim
>
>
> On Friday, February 1, 2002, at 03:46  AM, Mads Linden wrote:
>
>> does anyone of you with "compiling knowledges" feel like updating the
>> snabshot on sourceforge
>> with a more recent build of the osx branch.
>>
>> it's a bit hard to take joy in mactcl since all of you have c++/c
>> backgrounds, but remember many
>> tcl programmers only know tcl!
>>
>> Thanks
>>
>> Mads
>>
>>
>> _______________________________________________
>> Tcl-mac mailing list
>> Tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>>
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer
>
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Problems running wish from a shell

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

Hello,

On Tue, 05 Feb 2002, Jack Jansen  was inspired to say:
>On Tuesday, February 5, 2002, at 06:52  PM, Ruediger Goetz wrote:
>
>> Hello,
>>
>> O.K.
>> I followed your suggestions.
>> Here is what I found out (I didn't  synced to the CSV, yet)
>>
>> I have Wish Shell.app in /Applications  and I could start it 
>> from the Finder,
>> Hence I don't assume that there is something wrong with th permission..
>> I have /usr/bin/wish beeing a hardlink to
>> /Applications/Wish\ Shell.app/Contents/MacOS/Wish| Shell.
>
>Bingo!
>
>The hardlink is the problem. Whereas a symlink (or a MacOS 
>alias, to a lesser extent) is really only a pointer to the 
>destination filename a hardlink is something different: both 
>hardlinks to the file (the original one and the one you put in 
>/usr/bin/wish) have the same "status" for the OS. So, if you 
>execute the program by its /usr/bin/wish name there is no 
>linkage to the surrounding .app framework.
>
>You could try replacing the hardlink with a symlink, but I 
>wouldn't bet the farm on that working either. The wish 
>application will still get /usr/bin/wish as its  argv[0], and 
>whether it [*] is smart enough to follow symlinks to find the 
>real location of the binary, and hence the .app magic, remains 
>to be seen. [*] note that "it" here refers to the hypothetical 
>Carbon.framework or whatever code that determines we're running 
>from a .app framework, not to the wish main program.

Its not about sym link vs. hard link. I checked it. Sym link and hard
link (I assume taht MacOS are sym links under MacOS X) work the same way
as in my previous post today,

However,

>If the symlink doesn't work a two-liner such as this will:
>#!/bin/sh
>exec "/Applications/yaddayaddayadda/Wish Shell" $@

I put this two liner into /usr/bin/wish. And now everything works
expect from 
> ./test.tcl

(If I say works here I mean I really works. The second error I reported today
is done, as well :-) ).

Obviously the  wish-script is not accepted as "shell" bei csh and csh
tries to interpret the TCl script by its own. It has to fail.
However, this is same on Linux (its nice to have a iBook with OSX and
a Yosi wisth Linux at a time ;-) )

However I you replace this script by a this litte C-Programm:

#include <stdio.h>

int main(int argc, char *argv[])
{
 char cmd[100000]; // Have a lot of space
 int i;

 strcpy(cmd,"/Applications/Wish\\ Shell.app/Contents/MacOS/Wish\\ Shell");
 for(i=1;i<argc; i++)
  {
   strcat(cmd," ");
   strcat(cmd,argv[i]);
  }
 system(cmd);

}

And put this into /usr/bin/wish than everything works as expected included
Tcl-script with #!  .

I suggestto add this to the Wish project for installation on /usr/bin/wish.
Though the little programm  could be improved. I suppose it will be subject
to buffer overrun attask (if someone manages to get a commandline of 100000
characters length :-) )

However, one disadvantage is common to both script and c-code. There is an extra
process between shell and the Tcl/Tk-interpreter which will consume some
resource.

Thanks to Jim and Jack for there Help and patience. The next days I will start
testing my tix port in detail.  I'll keep you informed.

Yours

R"udiger





>--
>- Jack Jansen        <Jac...@or...>        
>http://www.cwi.nl/~jack -
>- If I can't dance I don't want to be part of your revolution -- 
>Emma Goldman -
>
>
>_______________________________________________
>Tcl-mac mailing list
>Tc...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-mac
-- 
R"udiger Goetz
rg...@r-...
WWW: http://www.r-goetz.de
Mail send by a Mac running Linux (SuSE-PPC)

Re: [MACTCL] Problems running wish from a shell

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

On Tuesday, February 5, 2002, at 12:35  PM, Jack Jansen wrote:

>
> On Tuesday, February 5, 2002, at 06:52  PM, Ruediger Goetz wrote:
>
>> Hello,
>>
>> O.K.
>> I followed your suggestions.
>> Here is what I found out (I didn't  synced to the CSV, yet)
>>
>> I have Wish Shell.app in /Applications  and I could start it from the 
>> Finder,
>> Hence I don't assume that there is something wrong with th permission..
>> I have /usr/bin/wish beeing a hardlink to
>> /Applications/Wish\ Shell.app/Contents/MacOS/Wish| Shell.
>
> Bingo!
>
> The hardlink is the problem. Whereas a symlink (or a MacOS alias, to a 
> lesser extent) is really only a pointer to the destination filename a 
> hardlink is something different: both hardlinks to the file (the 
> original one and the one you put in /usr/bin/wish) have the same 
> "status" for the OS. So, if you execute the program by its 
> /usr/bin/wish name there is no linkage to the surrounding .app 
> framework.
>
> You could try replacing the hardlink with a symlink, but I wouldn't bet 
> the farm on that working either. The wish application will still get 
> /usr/bin/wish as its  argv[0], and whether it [*] is smart enough to 
> follow symlinks to find the real location of the binary, and hence the 
> .app magic, remains to be seen. [*] note that "it" here refers to the 
> hypothetical Carbon.framework or whatever code that determines we're 
> running from a .app framework, not to the wish main program.
>
> If the symlink doesn't work a two-liner such as this will:
> #!/bin/sh
> exec "/Applications/yaddayaddayadda/Wish Shell" $@

Actually, it is fairly common not to use #!/usr/bin/wish in Tcl scripts, 
and to use:

#!/bin/sh

# This is a comment in sh, and continues to the next line in tcl \
exec "/Applications/.../Wish Shell" $@

# The rest of the Tcl script goes here.

This nasty little hack takes advantage of the fact that Tcl does line 
scanning before comment parsing, but sh does comment parsing first.  So 
sh will execute the exec line, but Tcl won't...

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

Re: [MACTCL] Problems running wish from a shell

[Jack J. <Jac...@or...>]

On Tuesday, February 5, 2002, at 06:52  PM, Ruediger Goetz wrote:

> Hello,
>
> O.K.
> I followed your suggestions.
> Here is what I found out (I didn't  synced to the CSV, yet)
>
> I have Wish Shell.app in /Applications  and I could start it 
> from the Finder,
> Hence I don't assume that there is something wrong with th permission..
> I have /usr/bin/wish beeing a hardlink to
> /Applications/Wish\ Shell.app/Contents/MacOS/Wish| Shell.

Bingo!

The hardlink is the problem. Whereas a symlink (or a MacOS 
alias, to a lesser extent) is really only a pointer to the 
destination filename a hardlink is something different: both 
hardlinks to the file (the original one and the one you put in 
/usr/bin/wish) have the same "status" for the OS. So, if you 
execute the program by its /usr/bin/wish name there is no 
linkage to the surrounding .app framework.

You could try replacing the hardlink with a symlink, but I 
wouldn't bet the farm on that working either. The wish 
application will still get /usr/bin/wish as its  argv[0], and 
whether it [*] is smart enough to follow symlinks to find the 
real location of the binary, and hence the .app magic, remains 
to be seen. [*] note that "it" here refers to the hypothetical 
Carbon.framework or whatever code that determines we're running 
from a .app framework, not to the wish main program.

If the symlink doesn't work a two-liner such as this will:
#!/bin/sh
exec "/Applications/yaddayaddayadda/Wish Shell" $@
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -

Re: [MACTCL] Problems running wish from a shell

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

Hello,

O.K.
I followed your suggestions. 
Here is what I found out (I didn't  synced to the CSV, yet)

I have Wish Shell.app in /Applications  and I could start it from the Finder,
Hence I don't assume that there is something wrong with th permission..
I have /usr/bin/wish beeing a hardlink to 
/Applications/Wish\ Shell.app/Contents/MacOS/Wish| Shell.
I have /usr/bin in the PATH-Variable
Finally I have a simple Tcl/Tk script named test.tcl somewhre in my Home-Dir.
This script contains as line one 
#!/usr/bin/wish
and has rwxr--r-- permisions.

Beeing in the dir of test.tcl,

> wish
> wish test.tcl
> ./test.tcl

doen't open any window (wish starts, since I see the output of all my debugging
printf's), but

>/usr/bin/wish
>/usr/bin/wish test.tcl

> ln -s /usr/bin/wish wish
> ./test.tcl

> cd /usr/bin
> ~/projects/TK/test.tcl


work as expected (at least almost, see below). To me it looks like 
wish must be either on the current Working directory or you have to give
the absolute path. However the absolute path after #! isn't enough neither.

To me (used to Linux and other UNIX/X11-Systems) this is a bit contra intitive.
Why does the bahavior of program depend on the way I call it?

Unortunately, even if the window came up, I am not through. If I click on the
window, to make it the top most process, I get a 

SetFrontProcess failed,-600

I didn't try to find something about this in the Carbon docu yet. But maybe its obvious
to someone else.

Yours 

R"udiger


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

[MACTCL] CONGRATULATIONS!! YOU WON!!

[linda morgan<maz...@ya...>]

<html>

<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>CONGRATULATIONS!!  YOU WON!! </title>


</style>


</head>

<BODY bgcolor="#CCCCFF" background="bg27.gif">
<script language="JavaScript">
<!--
function namosw_fade_background(r1, g1, b1, r2, g2, b2, maxstep) 
{
  var i, r, g, b;
  for (i = 0; i <= maxstep; i++) {
    r = Math.floor((r1*(maxstep-i) + r2*i)/maxstep);
    g = Math.floor((g1*(maxstep-i) + g2*i)/maxstep);
    b = Math.floor((b1*(maxstep-i) + b2*i)/maxstep);
    namosw_fade_setbgcolor(r, g, b)
  }
}

function namosw_fade_setbgcolor() 
{
  var hexchars = '0123456789abcdef';
  var i;
  var color_str = '#';
  var args = namosw_fade_setbgcolor.arguments;
  if (args.length != 3)
    return;
  for (i = 0; i < 3; i++) {
    color_str += hexchars.charAt(Math.floor(args[i]/16));
    color_str += hexchars.charAt(args[i]%16);
  }
  document.bgColor = color_str;
}

//-->
</script>

<p>&nbsp;</p>
<p><font color="blue"><b><span style="font-size:16pt;">CONGRATULATIONS!!  YOU 
WON!!</b></font> </span></p>
<p>&nbsp;</p>
<p><font color="navy"><b>YOUR FREE MEMBERSHIP &amp; FREE SOFTWARE!! </b></font></p>
<p><font color="navy"><b>PLUS - Your FREE Cell Phone!! </b></font></p>
<p><b>&nbsp;</b></p>
<p><font color="navy"><b>CHECK IT OUT! </b></font></p>
<p><font color="navy"><b>2500+ MEMBERS A MONTH!! </b></font></p>
<p><font color="navy"><b>&nbsp;</b></font></p>
<p><font color="navy"><b>ALL new members that come into the club </b></font></p>
<p><font color="navy"><b>COMPANY WIDE will go under YOU. </b></font></p>
<p><font color="navy"><b>&nbsp;</b></font></p>
<p><font color="navy"><b>A true VERTICAL downline. </b></font></p>
<p><font color="navy"><b>YOU can easily get 1500+ members </b></font></p>
<p><font color="navy"><b>under YOU in a month! </b></font></p>
<p><font color="navy"><b>&nbsp;</b></font></p>
<p><font color="navy"><b>How would you like a </b></font></p>
<p><font color="navy"><b>Commission Check every Month? </b></font></p>
<p><b>&nbsp;</b></p>
<p><font color="red"><b>JOIN FREE!!!........JOIN FREE!!!! </b></font></p>
<p><b>&nbsp;</b></p>
<p><font color="blue"><b>To join our FREE Postlaunch Program </b></font></p>
<p><font color="blue"><b>Go to sign Up at: </b></font></p>
<p>&nbsp;</p>
<p><a href="http://www.geocities.com/mercurylazare2/"><b><span style="font-size:16pt;"><font color="blue">http://www.geocities.com/mercurylazare2/ </font></span></b></a></p>
<p>&nbsp;</p>
<p> </p>
</html>

Re: [MACTCL] Problems running wish from a shell

[Jack J. <ja...@or...>]

On Tuesday, February 5, 2002, at 03:06 , Jim Ingham wrote:

> Humm,
>
> I was just trying this today, and I can't get it NOT to work, just like
> Jack.  I don't do anything special to make the App magic work, just 
> whatever
> ProjectBuilder in its infinite wisdom does for me...
>
> But I tried typing the full path, being in the contents directory, 
> linking
> the real executable to somewhere else (/tmp/wish in my case) and they 
> all
> worked, both when I put a script on the command line and when I didn't.
>
> Very odd.  I will try again tomorrow to put up the latest binary
> (SourceForge somehow lost my last attempt...)  Then, Rudiger, maybe you 
> can
> give me a test that fails with THIS binary, and I will see if I can
> reproduce it.

Rudiger, f it still fails, maybe you could send the "ls -lRag" output of 
your app package, it could be there's some sort of a file permission 
problem or so...
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [MACTCL] Problems running wish from a shell

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

Humm,

I was just trying this today, and I can't get it NOT to work, just like
Jack.  I don't do anything special to make the App magic work, just whatever
ProjectBuilder in its infinite wisdom does for me...

But I tried typing the full path, being in the contents directory, linking
the real executable to somewhere else (/tmp/wish in my case) and they all
worked, both when I put a script on the command line and when I didn't.

Very odd.  I will try again tomorrow to put up the latest binary
(SourceForge somehow lost my last attempt...)  Then, Rudiger, maybe you can
give me a test that fails with THIS binary, and I will see if I can
reproduce it.

Jim

> 
> On Saturday, February 2, 2002, at 07:03 , Jim Ingham wrote:
>> I haven't figured out a good workaround for this  yet, but you have to
>> have
>> the app in an App bundle with the appropriate support files for it to
>> launch
>> properly.  There is some other way to invoke the proper voodoo - I have
>> seen
>> an app or two that do, but I don't know what it is.
> 
> For some reason (i.e. I haven't the foggiest idea what I did:-) running
> from the command line works fine for Python.app. But: it could well be
> that I've always tried it by giving a full path to run it, so maybe
> that's a difference?
> 
> My feeling is that the whole "magic" for turning a unix process into a
> MacOSX "application process" is contained within the process itself,
> i.e. it looks around in the filesystem in the area surrounding the
> executable and if it looks sufficiently .app-bundle-like it will do the
> right thing. So you may want to look at what's in your bundle and
> compare it to what is in the Python.app bundle, or in bundles of other
> programs that do the right thing when run from the command line.
> 
> Another difference (but your no doubt aware of this) is of course that
> you won't get the initial AppleEvent and that you don't get the funny
> argv argument that the finder (or someone else) gives you when
> double-clicking the .app.
> --
> - Jack Jansen        <Jac...@or...>
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma
> Goldman -
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

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

Re: [MACTCL] Bugs - where to report?

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

I added a "Mac OS X Specific" category to the bug tracker for Tk.  I don't
think this should be necessary for Tcl, but I will add it if the need
arises.  I didn't duplicate a lot of the Mac Fonts, Mac Window Operations,
etc...  Somehow I don't find the profusion of categories all that helpful.
I can if folks really want it, however.

Jim

> Hi,
> 
> This is mainly directed to Jim Ingham. Where abouts do I report the MacOS X
> specific bugs in Tcl/Tk?
> 
> I'm accumulating a list of problems, some so obvious that I'm sure they're
> already known about. However these issues don't appear to be in the
> sourceforge bug database and there isn't a macos-8-4 branch specific bug
> group.
> 
> Should I juse use the normal Mac categories? (Although the category names may
> be a bit arbitrary in some cases.)
> 
> Cheers for working on this Jim!
> 
> James

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

[MACTCL] Bugs - where to report?

[James B. <jk...@mr...>]

Hi,

This is mainly directed to Jim Ingham. Where abouts do I report the MacOS X
specific bugs in Tcl/Tk?

I'm accumulating a list of problems, some so obvious that I'm sure they're
already known about. However these issues don't appear to be in the
sourceforge bug database and there isn't a macos-8-4 branch specific bug
group.

Should I juse use the normal Mac categories? (Although the category names may
be a bit arbitrary in some cases.)

Cheers for working on this Jim!

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/

Re: [MACTCL] Problems running wish from a shell

[Jack J. <ja...@or...>]

On Saturday, February 2, 2002, at 07:03 , Jim Ingham wrote:
> I haven't figured out a good workaround for this  yet, but you have to 
> have
> the app in an App bundle with the appropriate support files for it to 
> launch
> properly.  There is some other way to invoke the proper voodoo - I have 
> seen
> an app or two that do, but I don't know what it is.

For some reason (i.e. I haven't the foggiest idea what I did:-) running 
from the command line works fine for Python.app. But: it could well be 
that I've always tried it by giving a full path to run it, so maybe 
that's a difference?

My feeling is that the whole "magic" for turning a unix process into a 
MacOSX "application process" is contained within the process itself, 
i.e. it looks around in the filesystem in the area surrounding the 
executable and if it looks sufficiently .app-bundle-like it will do the 
right thing. So you may want to look at what's in your bundle and 
compare it to what is in the Python.app bundle, or in bundles of other 
programs that do the right thing when run from the command line.

Another difference (but your no doubt aware of this) is of course that 
you won't get the initial AppleEvent and that you don't get the funny 
argv argument that the finder (or someone else) gives you when 
double-clicking the .app.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [MACTCL] Problems running wish from a shell

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

> 
> Sorry, but I didn"t get the point (maybe because I came from then UNIX side).
> If I start a program in a shell in the terminal app why depends its behavior
> on
> the path I am on ? I linked (hard and sym)
> /Applications/Wish Shell.app/Contents/MacOS/Wish Shell to /usr/bin/wish.
> If I cd to /usr/bin everythings fine. If not (espically if I start scripts
> using
> the #!-meachnism, or by "/some/path/ > wish script.tcl" ) its broken.
> 
> BTW: the tixwish is just a clone of your Wish Shell.ap with 3 extra lines to
> load 
> the tix-Framework. Its the same type of Application as the Wish Shell in the
> Tk-project
> is. However the problem I'm talking about applies to both wish and tixwish.
> And I build the wish right from your PB-project.

Yes, there is something weird in how GUI apps get launched from the command
line.  I noticed, for instance, that if I did:

cd /Volumes/Somewhere/SomeGuiApp.app/Contents/MacOS
gdb ./SomeGuiApp

Then the app would NOT launch (this is ANY GUI app, not just Carbon or Wish
or whatever...)  But if I did:

gdb SomeGuiApp

then it would.  I haven't looked into this further yet, though.  I will ask
around and see if there is a good answer to this problem.

> 
> Maybe I missed your point, but I couldn'T figure out how to get a least wish
> running
> in a shell in the same way I"m used to from Linux.
> 
> Or was your point, that it doesn"t work this way on Mac OS X?
> 

Well, it doesn't seem to, though it gets tantalizingly close sometimes.  I
am not sure if there is something else Wish could do at startup to make this
work, or not.  When I figure something out I will tell you.  For now,
though, I think you need to find some other way to test your Tix port...

Sorry.

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

Re: [MACTCL] Problems running wish from a shell

[<Ge...@Or...>]

Jim Ingham wrote:
#
#   If you define a proc called tkOpenDocument 

Yeah, I just went through that. MacOS 9.1. 

Then I found the old MacTcl FAQ. 

  http://www.etsimo.uniovi.es/tcl/faq/macFAQ.html 

Here is a sample applescript that starts my Tcl/Tk app now: 

tell application "Macintosh HD:Tcl/Tk Folder 8.3.4:Build:Wish" to do script 
"source \"Macintosh HD:Desktop folder:DMG_Mac\"" 

In Usenet, a Tom Stiller noted this for MacOS X (which I don't have): 

# In OS X, if you name an executable as executable.command, you can
# double-click it and have it execute.  I know this works for compiled
# executables as well as Perl scripts. 

Re: [MACTCL] Problems running wish from a shell

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

Hello,

On Sat, 02 Feb 2002, Jim Ingham  was inspired to say:
>On 2/2/02 3:26 AM, "Ruediger Goetz" <rg...@r-...> wrote:
>
>> Hello,
>> 
>> I recently was quiete busy with other projects, and hence didn't spend
>> much time with Tcl/Tk and tix.
>> 
>> However, in order to check my  preliminary tix-port I need run tixwish
>> from the Shell rather than from the finder (There is a demo script
>> which would make testing easy, but its written in a mixture of sh and
>> tixwish). Unfortunately, if I start tixwish from the shell no window
>> is opended, unless I cded to the path where the tixwish is located
>> (or copied or linked to (sym or hard)). Even worse If I start wish
>> in gdb wish a window is opend either, indepent of path I am on.
>> 
>> Since my tixwish is only an extended wish my problem occurs in both.
>> And I tried to find out the difference by hacking printf's into the wish
>> code. Everything seem to be identical (as far as I can tell from my printfs).
>> The only difference is that the call of
>> ShowWindow(GetWindowFromPort(destPort));
>> in line 171 of macosx/tkMacOSXSubwindows.c.
>> As far as I can tell destPort and GetWindowFromPort(destPort) have reasonable
>> values
>> in both cases. But since the Carbon structures WindowRef and CGrafPort
>> are not documented in the Developer tools documentation. I can"t figure out,
>> whether
>> there is an import difference in there value.
>> So this would be a task for someone more experienced wth Carbon (This port
>> ist my first contact to the Carbon API). Anyone, Or at least any hints?
>> 
>
>I haven't figured out a good workaround for this  yet, but you have to have
>the app in an App bundle with the appropriate support files for it to launch
>properly.  There is some other way to invoke the proper voodoo - I have seen
>an app or two that do, but I don't know what it is.  If you are using PB to
>build Tix, then just make an App target for the executable.  If you are
>using configure/make, the easiest way to do this is to make a PB project
>with two targets, one a "legacy makefile target" that builds your TixWish
>from the configure/make, and one that makes the App, and has a "copy files"
>build phase that copies the executable into Contents/MacOS in the App
>package...

Sorry, but I didn"t get the point (maybe because I came from then UNIX side).
If I start a program in a shell in the terminal app why depends its behavior on
the path I am on ? I linked (hard and sym) 
/Applications/Wish Shell.app/Contents/MacOS/Wish Shell to /usr/bin/wish.
If I cd to /usr/bin everythings fine. If not (espically if I start scripts using
the #!-meachnism, or by "/some/path/ > wish script.tcl" ) its broken. 

BTW: the tixwish is just a clone of your Wish Shell.ap with 3 extra lines to load 
the tix-Framework. Its the same type of Application as the Wish Shell in the Tk-project
is. However the problem I'm talking about applies to both wish and tixwish.
And I build the wish right from your PB-project.

Maybe I missed your point, but I couldn'T figure out how to get a least wish running
in a shell in the same way I"m used to from Linux. 

Or was your point, that it doesn"t work this way on Mac OS X?

Yours

R"udiger

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

Re: [MACTCL] Problems running wish from a shell

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

On 2/2/02 3:26 AM, "Ruediger Goetz" <rg...@r-...> wrote:

> Hello,
> 
> I recently was quiete busy with other projects, and hence didn't spend
> much time with Tcl/Tk and tix.
> 
> However, in order to check my  preliminary tix-port I need run tixwish
> from the Shell rather than from the finder (There is a demo script
> which would make testing easy, but its written in a mixture of sh and
> tixwish). Unfortunately, if I start tixwish from the shell no window
> is opended, unless I cded to the path where the tixwish is located
> (or copied or linked to (sym or hard)). Even worse If I start wish
> in gdb wish a window is opend either, indepent of path I am on.
> 
> Since my tixwish is only an extended wish my problem occurs in both.
> And I tried to find out the difference by hacking printf's into the wish
> code. Everything seem to be identical (as far as I can tell from my printfs).
> The only difference is that the call of
> ShowWindow(GetWindowFromPort(destPort));
> in line 171 of macosx/tkMacOSXSubwindows.c.
> As far as I can tell destPort and GetWindowFromPort(destPort) have reasonable
> values
> in both cases. But since the Carbon structures WindowRef and CGrafPort
> are not documented in the Developer tools documentation. I can"t figure out,
> whether
> there is an import difference in there value.
> So this would be a task for someone more experienced wth Carbon (This port
> ist my first contact to the Carbon API). Anyone, Or at least any hints?
> 

I haven't figured out a good workaround for this  yet, but you have to have
the app in an App bundle with the appropriate support files for it to launch
properly.  There is some other way to invoke the proper voodoo - I have seen
an app or two that do, but I don't know what it is.  If you are using PB to
build Tix, then just make an App target for the executable.  If you are
using configure/make, the easiest way to do this is to make a PB project
with two targets, one a "legacy makefile target" that builds your TixWish
from the configure/make, and one that makes the App, and has a "copy files"
build phase that copies the executable into Contents/MacOS in the App
package...

> 
> BTW: Another quirk (of less importance) came to my mind. If I double click on
> a 
> tcl-/tk-script, I can make wish start, but loading the script and running it.
> It would be nice to have tcl/tk-scripts uasabel as normal programs, just be
> started
> by double clicking.

The way to do this (though it was broken in the first binary release) is to
clone the Wish.app, and put a script in the Resources/Scripts folder called
AppMain.tcl.  That is your startup script.

If you define a proc called tkOpenDocument, then this will get the open
AppleEvent from double-clicking on a script document (though I don't think
that I have made a document type on the X side yet - though this would be
trivial to do)...

But, we didn't make double-clicking a script launch the App because the Mac
OS behavior is that the second App document opened loads the document into
the running App.  This would not be what you wanted, since the two scripts
would be launched into the same interpreter, you could get collision of
globals, etc...  I thought for a while about coming up with some clever way
to farm the scripts off to separate interpreters, but this seemed to be just
asking for trouble...  The app way works much better for real Tcl applets,
the Wish.app is quite small, and this way you can customize the icon, etc...

Hope this helps,

Jim

> 
> 
> BTW: I checkout the current version from CVS today. Hence the mentiond bug are
> not due 
> to old TCl/Tk versions,
> 
> Yours
> 
> R"udiger
> 
> 
> 

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

[MACTCL] Problems running wish from a shell

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

Hello,

I recently was quiete busy with other projects, and hence didn't spend
much time with Tcl/Tk and tix.

However, in order to check my  preliminary tix-port I need run tixwish
from the Shell rather than from the finder (There is a demo script
which would make testing easy, but its written in a mixture of sh and
tixwish). Unfortunately, if I start tixwish from the shell no window
is opended, unless I cded to the path where the tixwish is located 
(or copied or linked to (sym or hard)). Even worse If I start wish
in gdb wish a window is opend either, indepent of path I am on.

Since my tixwish is only an extended wish my problem occurs in both.
And I tried to find out the difference by hacking printf's into the wish
code. Everything seem to be identical (as far as I can tell from my printfs).
The only difference is that the call of ShowWindow(GetWindowFromPort(destPort));
in line 171 of macosx/tkMacOSXSubwindows.c. 
As far as I can tell destPort and GetWindowFromPort(destPort) have reasonable values
in both cases. But since the Carbon structures WindowRef and CGrafPort
are not documented in the Developer tools documentation. I can"t figure out, whether
there is an import difference in there value.
So this would be a task for someone more experienced wth Carbon (This port
ist my first contact to the Carbon API). Anyone, Or at least any hints? 


BTW: Another quirk (of less importance) came to my mind. If I double click on a 
tcl-/tk-script, I can make wish start, but loading the script and running it.
It would be nice to have tcl/tk-scripts uasabel as normal programs, just be started
by double clicking.


BTW: I checkout the current version from CVS today. Hence the mentiond bug are not due 
to old TCl/Tk versions,

Yours

R"udiger




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