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

Re: [MACTCL] Carbon Dater Report on Tcl/Tk

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

Guys,

It was definitely more than a three week job.  I have been hacking on 
this for most of this year, with some help.  We are almost done with 
something folks can start hacking on to clean up the remaining bugs.  I 
just have to find a week to fix up the core event handling - we used 
kind of a skanky hack to reuse the Unix Tcl code for Tk, and that is 
proving unsustainable.

The one thing that I did different from your suggestion was that I did 
not just Carbonize MacTk, I forked the tree, and are doing a MacOS X 
only port.  I decided to do this before I started (after a lengthy 
discussion on this list).  I want to be free to take advantage of 
whatever cool stuff there is on MacOS X.  One instance of this, which I 
have not done yet, but is in the plans, is to replace the QuickDraw 
drawing with Quartz.  The Quartz drawing model is much more flexible, 
and also more like the X11 and Windows models.  We can kill off a whole 
bunch of drawing bugs in the Canvas with this...  And as time goes on, 
there will be more & more stuff in this category...

I don't know yet just when I can release something, but it should be 
soon now.

Thanks for your patience.

Jim


On Monday, August 20, 2001, at 02:27 AM, Jack Jansen wrote:

> I think "a few weekends" is probably overly optimistic for carbonizing 
> tcl/tk,
> but it shouldn't be too difficult.
>
> Just in case you're going to do this I'll give you some advice based on 
> my
> experience carbonizing MacPython, feel free to ask for more info.
>
> - portable software (like tcl or python) is a lot easier to carbonize 
> than
> average software, because the dependencies tend to be localized.
>
> - don't start with the easy bits, but start with looking at potential
> showstoppers. For MacPython this was the underlying GUSI I/O system, 
> which
> used all asynchronous calls in a way that wasn't supported on Carbon. I 
> had to
> wait for someone to port GUSI (at least partially) before I was able to
> proceed. Oh yes: the showstoppers will probably be in third-party 
> libraries:-(
> Although in the case of tcl I think MoreFiles is the only one used, and 
> that
> is available carbonized.
>
> - Follow the order in Apple's Carbon Porting Guide. Especially the 
> accessor
> stuff should be done early and globally (I didn't:-) as that keeps your
> program working under classic but allows you to do the bulk of the work
> (getting rid of lomem access and direct window/dialog/etc structure 
> access).
> --
> Jack Jansen             | ++++ stop the execution of Mumia 
> Abu-Jamal ++++
> Jac...@or... | ++++ if you agree copy these lines to your 
> sig ++++
> www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-
> l/sigaction.htm
>
>
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> http://lists.sourceforge.net/lists/listinfo/tcl-mac

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb

Re: [MACTCL] package require Tclapplescript problems...

[Jon G. <jg...@hi...>]

At 6:10 PM +0100 8/20/01, Andrew Wilson wrote:

>The application calls AppleScript to get the MSIE webbrowser to
>open a URL.  I get the following error returned from a catch:
>
>     couldn't load file "Macintosh HD:System Folder:Extensions:Tool
>Command Language:Tclapplescript1.1.shlib": MSL RuntimePPC.DLL

% info patchlevel
8.3.3
% package require Tclapplescript
1.1
% AppleScript info contexts
global

Seems to work fine. Could you tell us more about what's in that catch?

Where did you get your 8.3.3 distribution? When did you get it? There 
were some crufty ones released before final.

>I'm new to Mac stuff. So I don't know how to read this.  Is it
>telling me that the runtimeppc stuff couldn't do its work, or is
>the shlib complaining that it can't find the runtimeppc stuff?

The Code Fragment Manager (in the OS) is telling you it had trouble 
loading a shared library. "MSL RuntimePPC.DLL" is probably not useful 
information in my experience.

-- 

   Jonathan E. Guyer
   <http://www.his.com/jguyer/>

[MACTCL] package require Tclapplescript problems...

[Andrew W. <an...@aa...>]

Hi,

I've got a 3 day old iBook running MacOS 9.1.  I installed the
8.3.3 Macos version of tcl/tk and built an application by dropping
a .tcl file onto the Drag and Drop Tclets gizmo.

The application calls AppleScript to get the MSIE webbrowser to
open a URL.  I get the following error returned from a catch:

    couldn't load file "Macintosh HD:System Folder:Extensions:Tool Command Language:Tclapplescript1.1.shlib": MSL RuntimePPC.DLL

I'm new to Mac stuff. So I don't know how to read this.  Is it
telling me that the runtimeppc stuff couldn't do its work, or is
the shlib complaining that it can't find the runtimeppc stuff?

Whatever the problem is (I'd love to know), the current minimal
runtime installation of tcltk is not sufficient to support TCL
AppleScript commands on a vanilla MacOS 9.1 installation.  My guess
is that, at least, a novice user would have to find and install
the runtimeppc stuff as well.

So, anyway, I tried a normal install of the *developers* version
of the 8.3.3 dist, then went back and clicked on 'custom install'
and checked the RuntimePPC box and clicked on [install] once again.
I then restarted the box.  Subsequently the same error as detailed
above was produced.

Anyone know the score?

Oh, the app I'm working with is tkMOO-light:

    http://www.awns.com/tkMOO-light/

Cheers,
Ay.

an...@aw...
Cell: 07889 61 61 44                 Voice/Fax: +44 (0) 1865 513 091  

RE: [MACTCL] tk_getSaveFile + tk_chooseDirectory

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

At 17:47 -0700 on 20/8/01, Mads Linden wrote:

>  >>whenever i call one of the two, and hit the "new folder" button, state of
>>>the dialog becomes disabled and
>>>i am in a deadlock!!!!
>
>>the implementation of these dialogs depends on your OS version, what
>>are you using?
>
>9.1, but i am bad with mac, i will check up on that "nav services" you were
>talking about

in 9.1, nav services ("Navigation Services") is included by default, 
you won't find it anywhere, it is contained in the System file.

I remembered in the meantime that the 'Default Folder' extension 
allows me to turn of nav services temporarily; the 'New folder' 
button in Tk still works for me in the old style dialogs.

It could be that your problem is due to extensions you might have 
installed that modify the save dialog (a la 'default folder' which 
works though), does the problem disappear when you boot with 
extensions off? otherwise I'm at a loss, maybe you can try on a 
different box?

>  >>very bad bug, are you guys having this too???
>
>>This works fine for me when using navigation services, I currently
>>don't have a system available that doesn't have them (anything after
>>the free 7.5.5 should have nav services)
>
>>>i am on 8.3.3
>>>ps. again, if any has any info on maxosx+wish please post it
>
>>standard unix tk works fine with rootless XFree86, tkaqua is in the
>  >works... no release date available
>
>is there any binaries anywhere for this?

http://mrcla.com/XonX/

http://sourceforge.net/projects/xonx/

fink allows you to install tcl & tk (as well as X): 
http://sourceforge.net/projects/fink
http://fink.sourceforge.net/pdb/package.php/tcltk

or you can easily build Tk from sources. For recent 
instructions&patch for Tcl see 
http://www.maths.mq.edu.au/~steffen/tclk/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/>

Re: [MACTCL] Carbon Dater Report on Tcl/Tk

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

At 0:26 -0400 on 18/8/01, Roger & Michelle Scheen wrote:

>Has anyone seriously looked at carbonizing wish?  I presume there's 
>some way you could link in the Tcl 8.3 dynamic lib that's already a 
>part of MacOS X.

Carbonizing Tk is in the works, I can't say much more for reasons 
that I can't go into publicly; no release date is available at this 
time.

AquaTk will indeed link to the native MachO Tcl, that's the source of 
a number of highly nontrivial problems btw, the event loop 
interaction is completely different from MacTcl, look in the wiki for 
infos on Tcl event loop and win2k embedding for some hints on the 
kind of problems involved.

you have to realize that unix tcl is very different from mac tcl in 
places, this introduces interesting problems e.g. where Tk source 
uses Carbon for file access and Tcl source uses POSIX api's for the 
same files...

>   Just out of curiosity, I ran Carbon Dater on Wish, and this is the 
>high-level summary (best viewed with courier font):
>
>Test	                       Number
>  Analysis of Imports:
>Supported API                   242
>Supported with Modifications    5
>Supported But Not Recommended   22
>Unsupported API                 50
>
>To me, that doesn't sound too bad--the vast majority (75.9%) of the 
>calls are supported, and at most less than 25% will need 
>modification.

the problem is first of all that 25% of all api calls is a LOT... 
furthermore the 25% only counts what API routines are ever called, 
not the number of actual calls made to these routines, it could very 
well be that 80% of all API calls have to be changed. Carbon Dater is 
not a terribly useful tool (and it's old, the latest version 1.3 was 
released in Jan 2000, Carbon has changed a LOT since then), trying to 
compile Tk with TARGET_API_MAC_CARBON turned on would give you a 
better idea about the number of problems involved.

Tk mac code is sometimes crufty to say the least and rather old in a 
lot of places; classic macos code needs to use modern APIs to 
carbonize well, older code really should be modernized first before 
carbonizing...
also a lot of the Tk widget/menu code plays interesting tricks e.g. 
with control drawing in offscreen bitmaps etc. that are difficult to 
reproduce with the new carbon control/menu managers (think e.g. 
throbbing buttons)

Carbonizing non-trivial code like Tk that interacts with a large part 
of the system and its various API layers is really a lot harder than 
Apple makes it sound in some early docs; note that over 50% of OS 
sessions at this year's WWDC were on Carbon and new&modified APIs 
introduced with it, so carbonizing is very far from the simple API 
search and replace one might suspect when reading the Carbon Dater 
report.

>   The carbon dater report goes into details of what calls to swap 
>for what.  To me, it sounds like a project that could I could do in 
>a few weekends by myself (less with help).  Is there something I'm 
>missing here?  Perhaps carbon dater didn't pick up dynamically 
>loaded Tk library?

IIRC carbon dater doesn't look at included libraries like Tcl.shlb or 
Tk.shlb, if you run it on those, the picture may be different...

>  If not, it looks like nearly cake to convert Wish to carbon.  If 
>anyone is interested in the details, I can post the Carbon Dater 
>report on my web site.

a lot of people want Tk on Aqua, so if it were that easy it would be here...

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] tk_getSaveFile + tk_chooseDirectory

[Mads L. <ma...@el...>]

>>whenever i call one of the two, and hit the "new folder" button, state of
>>the dialog becomes disabled and
>>i am in a deadlock!!!!

>the implementation of these dialogs depends on your OS version, what
>are you using?

9.1, but i am bad with mac, i will check up on that "nav services" you were
talking about

>>very bad bug, are you guys having this too???

>This works fine for me when using navigation services, I currently
>don't have a system available that doesn't have them (anything after
>the free 7.5.5 should have nav services)

>>i am on 8.3.3
>>ps. again, if any has any info on maxosx+wish please post it

>standard unix tk works fine with rootless XFree86, tkaqua is in the
>works... no release date available

is there any binaries anywhere for this?

Regards

Mads

[MACTCL] Re: Visual TCL on a Mac?

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

At 8:52 +0200 on 20/8/01, Mats Bengtsson wrote:

>  When I drop a tcl script on the "Drag & Drop Tclets" it just says:
>It is swedish meaning that the program (application) tcl8.4 cannot be found.
>Note that I only have 8.3.3. Daniel?

there was a bug in an mac-beta version of 8.3.3, where the cfrg name 
of Tcl8.3.shlb was set to 'Tcl8.4', it sounds like you have this 
version installed (check the library name in the 'cfrg' resource of 
Tcl8.3.shlb)

you should upgrade to the latest 8.3.3 installer on sourceforge.

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] tk_getSaveFile + tk_chooseDirectory

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

At 12:48 -0700 on 20/8/01, Mads Linden wrote:

>whenever i call one of the two, and hit the "new folder" button, state of
>the dialog becomes disabled and
>i am in a deadlock!!!!

the implementation of these dialogs depends on your OS version, what 
are you using?

>very bad bug, are you guys having this too???

This works fine for me when using navigation services, I currently 
don't have a system available that doesn't have them (anything after 
the free 7.5.5 should have nav services)

>i am on 8.3.3
>
>ps. again, if any has any info on maxosx+wish please post it

standard unix tk works fine with rootless XFree86, tkaqua is in the 
works... no release date available

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] tk_getSaveFile + tk_chooseDirectory

[Mads L. <ma...@el...>]

whenever i call one of the two, and hit the "new folder" button, state of
the dialog becomes disabled and
i am in a deadlock!!!!

very bad bug, are you guys having this too???

i am on 8.3.3

ps. again, if any has any info on maxosx+wish please post it

Regards

Mads

Re: [MACTCL] Carbon Dater Report on Tcl/Tk

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

I think "a few weekends" is probably overly optimistic for carbonizing tcl/tk, 
but it shouldn't be too difficult.

Just in case you're going to do this I'll give you some advice based on my 
experience carbonizing MacPython, feel free to ask for more info.

- portable software (like tcl or python) is a lot easier to carbonize than 
average software, because the dependencies tend to be localized.

- don't start with the easy bits, but start with looking at potential 
showstoppers. For MacPython this was the underlying GUSI I/O system, which 
used all asynchronous calls in a way that wasn't supported on Carbon. I had to 
wait for someone to port GUSI (at least partially) before I was able to 
proceed. Oh yes: the showstoppers will probably be in third-party libraries:-( 
Although in the case of tcl I think MoreFiles is the only one used, and that 
is available carbonized.

- Follow the order in Apple's Carbon Porting Guide. Especially the accessor 
stuff should be done early and globally (I didn't:-) as that keeps your 
program working under classic but allows you to do the bulk of the work 
(getting rid of lomem access and direct window/dialog/etc structure access).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jac...@or... | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 

[MACTCL] Re: Visual TCL on a Mac?

[Mats B. <mat...@fo...>]

> In article <1f6...@po...>, David
> Emerson <da...@ch...> wrote:
> 
> > "Bruce Van Horn" <bv...@sw...> wrote in message
> > news:<200...@ad...>...
> > > Has anyone gotten Visual Tcl running on a Mac?  I got tcl/tk working but
> > > there is no installer for Visual Tcl for the Mac.  So I just copied the
> > > folders from my Linux box. Its all written in tcl so it should work, but
> > > the Mac tells me it can't open the file.
> > > 
> > > Any help would be great!  Thx...
> > 
> > This is just a guess but from memory the big diff when accessing files
> > cross platform in tcl is the char used to split folders ... e.g. the \
> > used in win tcl isnt the seperation char used on the mac ... so maybe
> > you gotta go change all the \'s to whatever char the mac uses. N.B. if
> > that was the case i guess you could swap all the seperation chars for
> > one veriable which is set by an if statement at the begining of the
> > app ....
> 
> I just checked, nothing of the sort is necessary, just get 
> http://prdownloads.sourceforge.net/vtcl/vtcl-1.5.2.tar.gz
> unpack, drag 'vtclmac' onto 'Drag & Drop Tclets' and save as e.g.
> 'vtcl' into the same folder and you're done.

 When I drop a tcl script on the "Drag & Drop Tclets" it just says:
It is swedish meaning that the program (application) tcl8.4 cannot be found.
Note that I only have 8.3.3. Daniel?

Mats

[MACTCL] Carbon Dater Report on Tcl/Tk

[Roger & M. S. <sc...@ma...>]

Has anyone seriously looked at carbonizing wish?  I presume there's some 
way you could link in the Tcl 8.3 dynamic lib that's already a part of 
MacOS X.  Just out of curiosity, I ran Carbon Dater on Wish, and this is 
the high-level summary (best viewed with courier font):

Test	                       Number
  Analysis of Imports:
Supported API                   242
Supported with Modifications    5
Supported But Not Recommended   22
Unsupported API                 50

To me, that doesn't sound too bad--the vast majority (75.9%) of the 
calls are supported, and at most less than 25% will need modification.  
The carbon dater report goes into details of what calls to swap for 
what.  To me, it sounds like a project that could I could do in a few 
weekends by myself (less with help).  Is there something I'm missing 
here?  Perhaps carbon dater didn't pick up dynamically loaded Tk 
library?  If not, it looks like nearly cake to convert Wish to carbon.  
If anyone is interested in the details, I can post the Carbon Dater 
report on my web site.


Roger Scheen

Re: [MACTCL] How to install iwidgets

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

At 23:01 -0500 on 15/8/01, Andrew Robinson wrote:

>I'm trying to install itcl, itk and iwidgets on my Mac. I downloaded
>"Mac Itcl3.1 for 8.3.2p1". The directory hints at how to install the
>files. I put Itcl3.1.shlb and Itk3.1.shlb in the Build folder in the
>"Tcl/Tk Folder 8.3.3" folder and linked them in the "Tool Command
>Language" folder. I copied the "iwidgets3.0.0" folder into the "Tcl/Tk
>Folder 8.3.3" folder and also created an alias in the "Tool Command
>Language" folder. (Got all that?)  The commands "package require Itcl"
>and "package require Itk" work. When I try the command "package require
>Iwidgets", I get "can't find package Iwidgets". What don't I know?

you need to put the "iwidgets3.0.0" folder itself into "Tool Command 
Language", an alias to it doesn't work. (a folder called 
"iwidgets3.0.0" containing aliases to the contents of your 
"iwidgets3.0.0" in "Tcl/Tk Folder 8.3.3" works too)

this is due to the fact that Tcl 8.3.3 doesn't find pkgIndex.tcl 
files inside aliased folders in the auto_path. This is fixed in the 
latest tcl 8.4 with my mac patches on SF applied.

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] How to install iwidgets

[Andrew R. <awr...@ho...>]

I'm trying to install itcl, itk and iwidgets on my Mac. I downloaded
"Mac Itcl3.1 for 8.3.2p1". The directory hints at how to install the
files. I put Itcl3.1.shlb and Itk3.1.shlb in the Build folder in the
"Tcl/Tk Folder 8.3.3" folder and linked them in the "Tool Command
Language" folder. I copied the "iwidgets3.0.0" folder into the "Tcl/Tk
Folder 8.3.3" folder and also created an alias in the "Tool Command
Language" folder. (Got all that?)  The commands "package require Itcl"
and "package require Itk" work. When I try the command "package require
Iwidgets", I get "can't find package Iwidgets". What don't I know?

Thanks!

Andrew Robinson

[MACTCL] Popup Boxes on MacTclTk

[Ryan C. <sc...@ho...>]

I have a procedure that implements a popup box using a =
overrideredirected toplevel.

The item it is attached to is bound to kill it upon leaving or motion =
(<Leave> or <Motion>), and to restart the timer for the popup after =
motion is complete or upon enter (<Motion> or <Enter>).

My problem is that the bound item (an image on a canvas) is getting a =
<Leave> event when the popup comes up (which causes the popup to close), =
then an Enter when the popup closes (which restarts the popup).  This is =
sending my popup box into a loop of <Leave><Enter><Leave><Enter><...>

Any ideas here?  Different implementation of popup?  Other events to =
bind to? =20

Thanks for your help.

For those that have helped me so far:  Thank you!  Except for this popup =
issue, and the one I mentioned in a previous message about 'post', which =
is minor and not really reproducible consistently, I am finished with =
the port.

Ryan P. Casey

[MACTCL] Re: Visual TCL on a Mac?

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

[[ This message was both posted and mailed: see
   the "To," "Cc," and "Newsgroups" headers for details. ]]

In article <1f6...@po...>, David
Emerson <da...@ch...> wrote:

> "Bruce Van Horn" <bv...@sw...> wrote in message
> news:<200...@ad...>...
> > Has anyone gotten Visual Tcl running on a Mac?  I got tcl/tk working but
> > there is no installer for Visual Tcl for the Mac.  So I just copied the
> > folders from my Linux box. Its all written in tcl so it should work, but
> > the Mac tells me it can't open the file.
> > 
> > Any help would be great!  Thx...
> 
> This is just a guess but from memory the big diff when accessing files
> cross platform in tcl is the char used to split folders ... e.g. the \
> used in win tcl isnt the seperation char used on the mac ... so maybe
> you gotta go change all the \'s to whatever char the mac uses. N.B. if
> that was the case i guess you could swap all the seperation chars for
> one veriable which is set by an if statement at the begining of the
> app ....

I just checked, nothing of the sort is necessary, just get 
http://prdownloads.sourceforge.net/vtcl/vtcl-1.5.2.tar.gz
unpack, drag 'vtclmac' onto 'Drag & Drop Tclets' and save as e.g.
'vtcl' into the same folder and you're done.

vtcl works beautifully on the mac, including the incrtk and tktable
support btw

Cheers,

Daniel

Re: [MACTCL] Drag & Drop Tclets / MacOS X

[Ryan C. <sc...@ho...>]

Hmmm...I'm not finding a command 'post' that I could disable...I am using a
menu attached to a menubutton.

Maybe I am missing something.  Right now these are being built in the
toplevel itself.  Is there a way to instead build these menus in the Mac
menu bar?

Also, what do I need to do to get Mac to take control of the location of my
toplevel...I can't move it.

Ryan

----- Original Message -----
From: "Robert Karen" <ro...@na...>
To: "Ryan Casey" <sc...@ho...>
Sent: Friday, August 10, 2001 11:12 AM
Subject: Re: [MACTCL] Drag & Drop Tclets / MacOS X


> I'm not a c programmer (on mac) but for what it's worth, I had
> lots of problem with the post menu command in tk on OS8, until I
> disabled it. One involved an error message that said something
> like 'window .xyz.menu already posted...' It may not be an OS9
> porting issue.
>
> RK
>
> Ryan Casey wrote:
> >
> > My problems were the libraries.  Apparently there was an entry made to
the
> > default search path in OS9 when Tcl/Tk was installed, that caused the
> > libraries to be found by the DnD Tclet (that's my guess anyway).  Once I
> > moved those shared libraries to the same directory as my executable,
> > everything comes up.  I still have one problem occurring though.
> >
> > Issue: Menu post
> >   I keep getting a 'Cannot call post menu while already posting menu.'
> >
> >   I get this with one command in my client-server app that is run from a
> > menu item.  I also can reproduce it in standalone if I click the menus
fast.
> > Any ideas what I need to be sure is done before the post is tried?  i.e.
> > What might I need to destroy?
> >
> > Thanks for your help, Rob and Jim.  This port has gone really well
because
> > of you guys.
> >
> > Ryan
> > ----- Original Message -----
> > From: "Jim Ingham" <ji...@ap...>
> > To: "Ryan Casey" <sc...@ho...>
> > Cc: <tc...@li...>
> > Sent: Thursday, August 09, 2001 5:03 PM
> > Subject: Re: [MACTCL] Drag & Drop Tclets / MacOS X
> >
> > > Ryan,
> > >
> > > The D&D Tclets are actually pretty simple little beasts.  They are
just
> > > a copy of the Wish shell app with the script put into a TEXT resource
> > > with the appropriate name (tclshrc).  So there is not much that can go
> > > wrong here...
> > >
> > > Did the Tclet try to launch as a X app, or did it run in classic?
Also,
> > > make sure it didn't manage to lose its TEXT resources.  Have a look at
> > > it in ResEdit to make sure it is still there...
> > >
> > > Maybe it's not finding the Tcl & Tk shared libraries?  But if Wish can
> > > find them, your Tclet should be able to as well.
> > >
> > > Jim
> > >
> > > On Thursday, August 9, 2001, at 01:54 PM, Ryan Casey wrote:
> > >
> > > > Should tcl executables created by 'Drag & Drop Tclets' on OS9 work
under
> > > > Classic on OSX?
> > > >
> > > > I have the following situation:
> > > >   I made a DnD Tclet from a script using the above program.
> > > >   I tried to start this under OSX, it hangs the box.  Sometimes, it
> > > > loads
> > > > the icon in the tray, then gets rid of it and recovers.
> > > >
> > > >   I tried loading Wish, then sourcing the script.
> > > >   This worked as expected.  Wish comes up in Classic mode, and I
start
> > > > my
> > > > script.
> > > >
> > > >   The DnD Tclet is reported under Info as being a Classic App.
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks!
> > > >
> > > > Ryan
> > > >
> > > > _______________________________________________
> > > > Tcl-mac mailing list
> > > > Tc...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/tcl-mac
> > >
> > > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
> > > Jim Ingham
> > > ji...@ap...
> > > Developer Tools - gdb
> > >
> > >
> >
> > _______________________________________________
> > Tcl-mac mailing list
> > Tc...@li...
> > http://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Drag & Drop Tclets / MacOS X

[Ryan C. <sc...@ho...>]

My problems were the libraries.  Apparently there was an entry made to the
default search path in OS9 when Tcl/Tk was installed, that caused the
libraries to be found by the DnD Tclet (that's my guess anyway).  Once I
moved those shared libraries to the same directory as my executable,
everything comes up.  I still have one problem occurring though.

Issue: Menu post
  I keep getting a 'Cannot call post menu while already posting menu.'

  I get this with one command in my client-server app that is run from a
menu item.  I also can reproduce it in standalone if I click the menus fast.
Any ideas what I need to be sure is done before the post is tried?  i.e.
What might I need to destroy?

Thanks for your help, Rob and Jim.  This port has gone really well because
of you guys.

Ryan
----- Original Message -----
From: "Jim Ingham" <ji...@ap...>
To: "Ryan Casey" <sc...@ho...>
Cc: <tc...@li...>
Sent: Thursday, August 09, 2001 5:03 PM
Subject: Re: [MACTCL] Drag & Drop Tclets / MacOS X


> Ryan,
>
> The D&D Tclets are actually pretty simple little beasts.  They are just
> a copy of the Wish shell app with the script put into a TEXT resource
> with the appropriate name (tclshrc).  So there is not much that can go
> wrong here...
>
> Did the Tclet try to launch as a X app, or did it run in classic?  Also,
> make sure it didn't manage to lose its TEXT resources.  Have a look at
> it in ResEdit to make sure it is still there...
>
> Maybe it's not finding the Tcl & Tk shared libraries?  But if Wish can
> find them, your Tclet should be able to as well.
>
> Jim
>
> On Thursday, August 9, 2001, at 01:54 PM, Ryan Casey wrote:
>
> > Should tcl executables created by 'Drag & Drop Tclets' on OS9 work under
> > Classic on OSX?
> >
> > I have the following situation:
> >   I made a DnD Tclet from a script using the above program.
> >   I tried to start this under OSX, it hangs the box.  Sometimes, it
> > loads
> > the icon in the tray, then gets rid of it and recovers.
> >
> >   I tried loading Wish, then sourcing the script.
> >   This worked as expected.  Wish comes up in Classic mode, and I start
> > my
> > script.
> >
> >   The DnD Tclet is reported under Info as being a Classic App.
> >
> > Any ideas?
> >
> > Thanks!
> >
> > Ryan
> >
> > _______________________________________________
> > Tcl-mac mailing list
> > Tc...@li...
> > http://lists.sourceforge.net/lists/listinfo/tcl-mac
>
> _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
> Jim Ingham
> ji...@ap...
> Developer Tools - gdb
>
>

Re: [MACTCL] Drag & Drop Tclets / MacOS X

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

Ryan,

The D&D Tclets are actually pretty simple little beasts.  They are just 
a copy of the Wish shell app with the script put into a TEXT resource 
with the appropriate name (tclshrc).  So there is not much that can go 
wrong here...

Did the Tclet try to launch as a X app, or did it run in classic?  Also, 
make sure it didn't manage to lose its TEXT resources.  Have a look at 
it in ResEdit to make sure it is still there...

Maybe it's not finding the Tcl & Tk shared libraries?  But if Wish can 
find them, your Tclet should be able to as well.

Jim

On Thursday, August 9, 2001, at 01:54 PM, Ryan Casey wrote:

> Should tcl executables created by 'Drag & Drop Tclets' on OS9 work under
> Classic on OSX?
>
> I have the following situation:
>   I made a DnD Tclet from a script using the above program.
>   I tried to start this under OSX, it hangs the box.  Sometimes, it 
> loads
> the icon in the tray, then gets rid of it and recovers.
>
>   I tried loading Wish, then sourcing the script.
>   This worked as expected.  Wish comes up in Classic mode, and I start 
> my
> script.
>
>   The DnD Tclet is reported under Info as being a Classic App.
>
> Any ideas?
>
> Thanks!
>
> Ryan
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> http://lists.sourceforge.net/lists/listinfo/tcl-mac

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb

[MACTCL] Drag & Drop Tclets / MacOS X

[Ryan C. <sc...@ho...>]

Should tcl executables created by 'Drag & Drop Tclets' on OS9 work under
Classic on OSX?

I have the following situation:
  I made a DnD Tclet from a script using the above program.
  I tried to start this under OSX, it hangs the box.  Sometimes, it loads
the icon in the tray, then gets rid of it and recovers.

  I tried loading Wish, then sourcing the script.
  This worked as expected.  Wish comes up in Classic mode, and I start my
script.

  The DnD Tclet is reported under Info as being a Classic App.

Any ideas?

Thanks!

Ryan

[MACTCL] MacOsX

[Mads L. <ma...@el...>]

Does anyone here have some clue about the status of tcl/"TK" for os x

Regards

Mads

[MACTCL] Apple tools

[Rob B. <rb...@qu...>]

For Ryan and others:

http://developer.apple.com/

http://developer.apple.com/tools/

http://developer.apple.com/tools/debuggers/MacsBug/


--
Rob Barris       Quicksilver Software Inc.      rb...@qu...

Re: [MACTCL] Problems porting program to Mac -- thoughts?

[Rob B. <rb...@qu...>]

At 3:20 PM -0400 8/3/01, Ryan Casey wrote:
>> At 2:18 PM -0400 8/3/01, Ryan Casey wrote:
>
><snip>
>
>> >Does Mac Classic have virtual (disk cache) memory at all?  Should I just
>> >give up and work on the OSX port (especially with OS10.1 coming out
>soon)?
>>
>>    Yes - open up the memory control panel, enable virtual memory, set it
>as
>> high as you like and reboot.  However all this is doing, is setting the
>> size of the single address space which all apps share on OS9 or earlier.
>> OS9 and earlier still have partitions and you would have to change that as
>> well.
>
>*sigh*  Apparently I missed that section.  I did see the part about how much
>physical RAM I had, but not the spinbox below...
>
>Anyway, it was 32 and I upped it to 100.  I rebooted, and set my app to use
>1000 (default) to 100000 (preferred) memory.  I was then able to load 3 sets
>of 61 images...more than should be needed.  Now, after I check tbcload to be
>sure it works, I should be able to release a Mac 9 version, and move on to
>finishing Solaris and OSX.  Thank you!

Excellent - simple memory hog problem and not something more subtle or evil...


>>    Another thing to do is make sure you have MacsBug installed, then you
>> can do a "stdlog" command which will dump a fairly detailed machine state
>> to a log file at the time of failure.  This includes a stack crawl and
>heap
>> dump which can be inspected after the fact.  The 'hc' command can be
>> invoked to check heap integrity periodically also.
>
>For future reference, are these free?  Do you have a location for them?  I
>am really not a Mac person, I just managed to get one next to me to look at
>this, since people have been clamoring for a Mac port for a while.

Yeah, MacsBug is free off the Apple site.  I'll mail you a URL after lunch..


--
Rob Barris       Quicksilver Software Inc.      rb...@qu...

Re: [MACTCL] Problems porting program to Mac -- thoughts?

[Ryan C. <sc...@ho...>]

> At 2:18 PM -0400 8/3/01, Ryan Casey wrote:

<snip>

> >Does Mac Classic have virtual (disk cache) memory at all?  Should I just
> >give up and work on the OSX port (especially with OS10.1 coming out
soon)?
>
>    Yes - open up the memory control panel, enable virtual memory, set it
as
> high as you like and reboot.  However all this is doing, is setting the
> size of the single address space which all apps share on OS9 or earlier.
> OS9 and earlier still have partitions and you would have to change that as
> well.

*sigh*  Apparently I missed that section.  I did see the part about how much
physical RAM I had, but not the spinbox below...

Anyway, it was 32 and I upped it to 100.  I rebooted, and set my app to use
1000 (default) to 100000 (preferred) memory.  I was then able to load 3 sets
of 61 images...more than should be needed.  Now, after I check tbcload to be
sure it works, I should be able to release a Mac 9 version, and move on to
finishing Solaris and OSX.  Thank you!

>    Another thing to do is make sure you have MacsBug installed, then you
> can do a "stdlog" command which will dump a fairly detailed machine state
> to a log file at the time of failure.  This includes a stack crawl and
heap
> dump which can be inspected after the fact.  The 'hc' command can be
> invoked to check heap integrity periodically also.

For future reference, are these free?  Do you have a location for them?  I
am really not a Mac person, I just managed to get one next to me to look at
this, since people have been clamoring for a Mac port for a while.

Ryan

Re: [MACTCL] Problems porting program to Mac -- thoughts?

[Rob B. <rb...@qu...>]

At 2:18 PM -0400 8/3/01, Ryan Casey wrote:
>> >    Posted to c.l.t and tcl-mac mailing  list.   Wish 8.3.3 on MacOS 9.0
>> >(ppc).   I am starting to port my program to Mac.   After finding how to
>> >make an executable and adding some mac-specific stuff to my  OS-specific
>> >sections, it seems to work ok (it at least loads :) ).   I am having the
>> >following problems:   My program revolves around up to about 120 (maybe a
>> >bit more) photo images being moved around three canvases.  Sometimes I
>can
>> >load up to about 30, but more than that always seems to crash Wish.
>> >bgerror does not catch it, and sometimes an 'Error 25' is  displayed.
>>
>>
>> Welcome to classic MacOS ( < OS X ) :p
>
>Thanks :-\
>
>> ID 25 means QuickDraw, the graphics layer in the OS, could not get RAM to
>> satisfy a need that was graphics related.  QD is written in a very
>> "optimistic" style which means, there's not much in the way of error
>> reporting.
>
>Ah, glad somebody knows.  Thanks for the quick answer!
>
>> I will go out on a limb and guess that the "partition size" or "memory
>> allocation" for your Tcl app (or Tcl shell that in turn runs your code) is
>> not high enough for its needs.  Which jibes with the problem description.
>
>> The way you would increase the amount of RAM available to Wish:
>> a. select the Wish executable icon
>> b. hit Get Info in the FInder (command-I)
>> c. click on the popup and change to "memory"
>> d. adjust to suit.
>
>Worked great, except apparently my Mac doesn't have enough memory :-)
>
>>    I would recommend ZoneRanger as an excellent tool for watching the
>> shell's real memory usage within its heap in real time. You can download
>it
>> here: http://www.metrowerks.com/tools/software/zoneranger/
>
>This got up to 24MB memory on my app before it crashed and the zone was
>destroyed.
>
>I can't see how it could be using that much memory...each of these images is
>~3k in size.  The Tk control structures, etc, would take more room, but that
>much???  It gets nowhere near this size on PC or Unix.
>
>Does Mac Classic have virtual (disk cache) memory at all?  Should I just
>give up and work on the OSX port (especially with OS10.1 coming out soon)?




   Yes - open up the memory control panel, enable virtual memory, set it as
high as you like and reboot.  However all this is doing, is setting the
size of the single address space which all apps share on OS9 or earlier.
OS9 and earlier still have partitions and you would have to change that as
well.
   Technically an OS9 app *can* ask the OS for memory outside of its fixed
pool, but I doubt that Tcl's shell makes use of these calls.  For example
the Metrowerks compiler

   I agree, if you are manipulating 3KB images, to use that much memory is
quite a feat.  Are there a lot of intermediate stages involved, maybe some
buffers are not being released or something.

   I should add, there are some cases where QD will crash if it is fed some
bad data (like a corrupt PICT format file).

   ** There's also the possibility that the heap is not out of space at all
- it just got corrupted by way of a bug in the Tcl runtime or other code.
Then QD comes along and tries to do a memory allocation and fails because
of that - it's the victim, not the villain.  Anything that could possibly
overwrite the end of an array runs the risk of corrupting the heap and
bringing this on.

   Another thing to do is make sure you have MacsBug installed, then you
can do a "stdlog" command which will dump a fairly detailed machine state
to a log file at the time of failure.  This includes a stack crawl and heap
dump which can be inspected after the fact.  The 'hc' command can be
invoked to check heap integrity periodically also.


--
Rob Barris       Quicksilver Software Inc.      rb...@qu...