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

Re: [MACTCL] Popup Boxes on MacTclTk

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

Daniel,

On Tuesday, August 28, 2001, at 05:07  PM, Daniel A. Steffen wrote:

> Jim,
>
> At 9:35 -0700 on 28/8/01, Jim Ingham wrote:
>> I don't think you want to make the overrideredirect windows float, 
>> since overrideredirect  only changes look, not behavior on X11 and 
>> Windows, but floating windows have different behavior (for instance 
>> they vanish when the Application is backgrounded, and they don't 
>> receive keystrokes).
>
> well on unix overrideredirect changes behaviour as a consequence of the 
> fact that the window is no longer a normal window, i.e. the window 
> manager ignores it for the purposes of <enter>/<leave>  and focus 
> detection, doesn't decorate it etc. There seems to be no way to get 
> exactly that behaviour in the current (pre Carbon) MacOS Window Manager.

Yeah, but Tk handles most enter/leave tracking and focus change on its 
own, and doesn't rely on the window managers for most of this stuff, so 
I am not sure how much difference this would make.  In my experience 
with X11 Tk widget behavior doesn't much change when in an 
overrideredirect window.  It might cause problems to change this.

>
>
> as I said I don't think making overrideredirect windows float is really 
> a good solution, but in some sense it is as bad as the current 
> behaviour, with the looks now wrong but more correct behaviour...


Not sure.  Have to check a few X11 Tk apps that use overrideredirect 
windows for something substantial.

>
>
> maybe a better solution would be to modify GeneratePollingEvents() to 
> not only ignore floating windows in front of the current window but 
> also windows with the override_redirect flag set. Possibly this could 
> also be achieved by changing TkpIsWindowFloating() to check for 
> override_redirect. Maybe this is worth a try?
> (unix TkpChangeFocus() seems to do something similar to cope with 
> certain X window managers, i.e. it ignores windows with 
> override_redirect set)
>
>> The better solution here is to add the kHelpWindowClass window type to 
>> the list of types in unsupported1.  This is available only in 
>> carbonlib 1.1, but that is fairly common, and not hard to install on 
>> older (8.5 era) machines. This gives you the correct help tag look 
>> (which is more than just overrideredirect.)
>
> the problem is that you can't use carbon features selectively, if you 
> want to use any carbon feature such as the kHelpWindowClass you have to 
> go carbon all the way, which we can't really do with classic Tk...

This isn't true in this case.  TkMacHaveAppearance returns the 
Appearance version, so when you got a request for a help window passed 
into unsupported1 you would pass kHelpWindowClass to the CreateWindow 
cal if the Appearance version is > 1.1, and one of the floating windows 
members of the enum otherwise.  It is not even a different API, it is 
just some number passed to the Window Manager API's.

>
> Do you know how OS9 popup balloons get the window manger to essentially 
> ignore them?  popup balloons would seem to have features equivalent to 
> what we would like for overrideredirect... I suspect this  was done by 
> hacking a custom case into OS window layering code though.

I haven't had time to poke around in the Classic Window Manager code at 
all, so no, I don't know how it works.

>
>
> In any case for the purpose of Tk popup balloons, the 'unsupported1 
> style  floating sideTitlebar' solution works well enough for me, the 
> looks aren't so bad (see attached), so this is not really an urgent 
> problem.
>

Yeah, but on systems that support it, the real help tag window is lots 
nicer.  I will send you the patches I made for the X version if you want 
when I get in to work tomorrow, and if somebody feels like 
conditionalizing it for different Appearance versions, they are 
welcome...

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

Re: [MACTCL] memory & sockets

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

At 19:16 +0200 on 27/8/01, Mats Bengtsson wrote:

>While we are discussing memory stuffs here:
>In my QuickTime package I use NewGWorld() as follows:
>
>	err =3D NewGWorld( &newGWorldPtr, 32, &aRect, NULL, NULL, 0 );
>	if (err !=3D noErr) {
>		err =3D NewGWorld( &newGWorldPtr, 32, &aRect, NULL, 
>NULL, useTempMem );
>	}
>     if (err !=3D noErr) {
>	    panic( "Out of memory: NewGWorld failed" );
>	}
>
>Should I use useTempMem as the first option?


tclMacAlloc.c tries to make sure that there is at least TOOLBOX_SPACE 
(currently 512K) of heap space free, it would be good if your code 
could take similar precautions e.g. by implementing a similar 
strategy to what is done in tclMacAlloc.c (allocate and lock a 
purgeable handle of e.g. size 512K, then try to allocate memory the 
way you do already, then unlock the handle, next time around check if 
the handle has been purged, if yes reallocate it)

>Also, I use NewHandle to store compressed images which may take a lot
>of memory. Should I use NewHandleSys to take memory from the system heap
>instead? I'd like to make precaution from being stabbed in my back with
>memory problems.

You can do something similar to the above with NewHandle and 
TempNewHandle (NEVER use NewHandleSys, it has been deprecated for a 
long time and is dangerous) or if you don't need relocatable memory, 
just use Tcl's ckalloc and let it handle all this for you.

>
>Socket code:
>
>It is sad that the socket code is in such a terrible condition,
>so I had a look at tclMackSock.c... I wouldn't touch it with my
>bare hands, it looks very messy (probably due to the MacTCP APIs).
>So I looked at the OpenTransport docs (1.3), and it seemed fairly
>straightforward until I reached page 150 or so, where it says something
>about "deferred interrupt time" where you can't even allocate memory...
>At that point I stopped reading. :-(

:-) same problem here

>Next, looked at the Unix channel code in tclUnixChan.c where the
>tcp channel driver take up about half of that file (1000 lines readable cod=
e).
>I got the GUSI stuff from SourceForge and found out that also MacPerl
>(and MacPython) uses GUSI.
>
>Wouldn't it be an idee to just get the unix channel driver code from
>tclUnixChan.c, link it with GUSI, and make it into an extension,
>just for testing? Are there any problems with this?

I don't know about the extension approach, but it should certainly be 
possible to try to replace the mac socket code in e.g. target 
ppc=A5TestLibrary of TclLibraries.=B9 by the unix code and GUSI and see 
if it compiles and if sockets work in 'TclTest (PPC)'. Maybe you can 
give it a try?

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] Re: XML Crash kit

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

At 14:36 +0200 on 28/8/01, Mats Bengtsson wrote:
>Made a fresh download from SourceForge, trashed the old
>"Tool Command Folder", backed up Tcl/Tk 8.3.3 Folder,
>installed, placed the TclXML folder into the new "Tool Command Folder",
>launched wish, sourced the attached tcl script,
>picked the attached xml file, File/Quit and crash.
>Attached is the StdLog file. Hope this helps.
>Tomorrow I will try to reproduce it on my job machine MacOS 9.1.
>I have MacOS 8.6.

Mats,

your problem has nothing to do with TclXML but rather with the use of 
"puts stderr" in your TestingXML.tcl script. There are problems with 
stderr and the Wish console that I have been struggling with myself 
here for a project, at the moment I have only managed to workaround 
them by writing to stdout instead (e.g. remove all occurrences of 
stderr in your script and the crash goes away... or run the script in 
Tclsh, without the tk_getOpenFile of course)

The problem is related to the fact that two channels (stdout & 
stderr) are associated with the Tk console window on MacOS and that 
at exit destruction of the first channel (stdout) leads to disposal 
of the console window and structures, destruction of the second 
channel (stderr) then tries to flush the channel if it was ever used 
by trying to output an empty string, but the console window is 
already gone at that point, thus leading to a crash (actually the 
autoloader tries to reload the console but autoloading is disabled at 
that point and bad things happen all over...)
Fixing this involves diving deeper into Tcl channel code than I have 
time for at this point, it probably is a problem that was introduced 
relatively recently, i.e. the 8.2-8.3 timeframe (I see it on 8.3.2), 
maybe somebody with easy access to 8.0.5 could check there?

BTW, there is a more recent version of tclxml than what you sent me 
available on sourceforge (tclxml-2.1theta)

Also, for future reference, when tracking down bugs in Tcl/Tk it is 
always more useful to do it in TkTest (or TclTest) as these 
executables have debugging symbols enabled and optimization turned 
off. The StdLog you sent me isn't very useful as it is lacking most 
symbol names, an equivalent one from TkTest would have pinpointed the 
problem much more closely.

To make a long story short, avoid the use of stderr in MacTk for now...

Thanks for the great bug report, it was easy to track down the source 
of the problem with what you sent me.
Maybe you could enter a minimal case of use of stderr causing a crash 
into the sourceforge bug manager? that would really be a helpful 
reminder that this bug needs to be addressed. It will also make more 
people aware of the problem, esp. those more familiar with the 
intricacies of tcl channel code than myself.

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] Popup Boxes on MacTclTk

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

Jim,

At 9:35 -0700 on 28/8/01, Jim Ingham wrote:
>I don't think you want to make the overrideredirect windows float, 
>since overrideredirect  only changes look, not behavior on X11 and 
>Windows, but floating windows have different behavior (for instance 
>they vanish when the Application is backgrounded, and they don't 
>receive keystrokes).

well on unix overrideredirect changes behaviour as a consequence of 
the fact that the window is no longer a normal window, i.e. the 
window manager ignores it for the purposes of <enter>/<leave>  and 
focus detection, doesn't decorate it etc. There seems to be no way to 
get exactly that behaviour in the current (pre Carbon) MacOS Window 
Manager.

as I said I don't think making overrideredirect windows float is 
really a good solution, but in some sense it is as bad as the current 
behaviour, with the looks now wrong but more correct behaviour...

maybe a better solution would be to modify GeneratePollingEvents() to 
not only ignore floating windows in front of the current window but 
also windows with the override_redirect flag set. Possibly this could 
also be achieved by changing TkpIsWindowFloating() to check for 
override_redirect. Maybe this is worth a try?
(unix TkpChangeFocus() seems to do something similar to cope with 
certain X window managers, i.e. it ignores windows with 
override_redirect set)

>The better solution here is to add the kHelpWindowClass window type 
>to the list of types in unsupported1.  This is available only in 
>carbonlib 1.1, but that is fairly common, and not hard to install on 
>older (8.5 era) machines. This gives you the correct help tag look 
>(which is more than just overrideredirect.)

the problem is that you can't use carbon features selectively, if you 
want to use any carbon feature such as the kHelpWindowClass you have 
to go carbon all the way, which we can't really do with classic Tk...
Do you know how OS9 popup balloons get the window manger to 
essentially ignore them?  popup balloons would seem to have features 
equivalent to what we would like for overrideredirect... I suspect 
this  was done by hacking a custom case into OS window layering code 
though.

In any case for the purpose of Tk popup balloons, the 'unsupported1 
style  floating sideTitlebar' solution works well enough for me, the 
looks aren't so bad (see attached), so this is not really an urgent 
problem.

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] Popup Boxes on MacTclTk

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

Daniel,

I don't think you want to make the overrideredirect windows float, since 
overrideredirect  only changes look, not behavior on X11 and Windows, 
but floating windows have different behavior (for instance they vanish 
when the Application is backgrounded, and they don't receive keystrokes).

The better solution here is to add the kHelpWindowClass window type to 
the list of types in unsupported1.  This is available only in carbonlib 
1.1, but that is fairly common, and not hard to install on older (8.5 
era) machines. This gives you the correct help tag look (which is more 
than just overrideredirect.)

Jim


On Tuesday, August 28, 2001, at 01:49  AM, Daniel A. Steffen wrote:

> The only minor problem with this solution is that with the current OS9 
> window manager, there is no way to get rid of the floating window 
> decoration (titlebar, frame) on the balloon window (CarbonLib 1.1 and 
> OSX now have a help window style that is undecorated). Using the 
> sideTitlebar helps a bit in that the titlebar should be small for most 
> help balloons.
>
> The real fix would be to change Mac Tk's 'wm overrideredirect' to make 
> windows float, but because of the change in visual appearance I'm 
> hesitant to make that change in the distribution, what do people think? 
> (currently 'wm overrideredirect' changes the window style to plainDBox)
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Popup Boxes on MacTclTk

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

At 18:49 +1000 on 28/8/01, Daniel A. Steffen wrote:

>There is no need to test for '$tcl_platform(platform) == 
>"macintosh"' as the unsupported1 is just a noop on other platforms.

this turns out to be wrong... sorry

you need to surround the unsupported1 line by a 
$tcl_platform(platform) == "macintosh" like so:

if {$tcl_platform(platform) == "macintosh"} {
   unsupported1 style $the_balloon floating sideTitlebar
}

I've just added all this to the wiki as well: 
http://www.mini.net/cgi-bin/wikit/534.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] Popup Boxes on MacTclTk

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

Ryan,

sorry for the delay in answering, I only just discovered the solution 
to this problem myself...

At 14:22 -0400 on 15/8/01, Ryan Casey wrote:

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

I just had to solve this problem myself for a tk mac port here that uses the

#	Simple Balloon Help Package by
#	Robin Becker	ro...@je...
#	Stewart Inglis	si...@lu... Fri Apr  4 08:57:43 1997
#	This is version 0.1

indeed the 'bind $w <Any-Leave> "balloonHelp_kill $w 1 %W$b"' in this 
package would trigger on the mac as soon as the balloon window came 
to the front, thus leading to exactly the 
<Leave><Enter><Leave><Enter>... cycle you are seeing.

The easiest and most useable workaround is to make the balloon 
windows float, as MacTk's GeneratePollingEvents() ignores floating 
windows for the purposes of determining the front window, so 
displaying a floating window doesn't cause a <Leave> event to be sent.

this can be achieved via the mac-only unsupported1 tk command after 
calling 'wm overrideredirect $the_balloon 1' on you balloon window, 
e.g. as follows:

unsupported1 style $the_balloon floating sideTitlebar

(BTW, for this to work, appearance mgr needs to be present, but that 
shouldn't be a problem for all except very old macs, otherwise you 
can try using the older 'unsupported1 style $the_balloon 
floatSideProc' although I had problems with it)

There is no need to test for '$tcl_platform(platform) == "macintosh"' 
as the unsupported1 is just a noop on other platforms.

The only minor problem with this solution is that with the current 
OS9 window manager, there is no way to get rid of the floating window 
decoration (titlebar, frame) on the balloon window (CarbonLib 1.1 and 
OSX now have a help window style that is undecorated). Using the 
sideTitlebar helps a bit in that the titlebar should be small for 
most help balloons.

The real fix would be to change Mac Tk's 'wm overrideredirect' to 
make windows float, but because of the change in visual appearance 
I'm hesitant to make that change in the distribution, what do people 
think? (currently 'wm overrideredirect' changes the window style to 
plainDBox)

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] reinstalling after crashes...

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

Daniel,

On Sunday, August 26, 2001, at 09:41  PM, Daniel A. Steffen wrote:

> At 12:05 +0200 on 25/8/01, Mats Bengtsson wrote:
>
>> I know several applications using the GUSI (at SourceForge) MacPython,
>> and several more, and that seems to work ok. GUSI is like POSIX sockets
>> on the mac using OT under the hood. Couldn't it be possible to just
>> replace the mac specific socket code with the unix one, and use GUSI
>> for all socket stuff? After all, the unix socket code is very well 
>> tested.
>> Anyone knows something more about GUSI?
>
> I know GUSI quite well, I have worked with it in the past, but not on 
> MacTcl.
>
> AFAIK the socket code in MacTcl predates GUSI, which is why it wasn't 
> used :-)
>

Actually, Ray used GUSI for a while, but that was in its first 
incarnation - on top of MacTCP, IIRC - and going through the Tcl layer, 
through the GUSI layer, to the flakey Mac layer, was very unstable, so 
he hand-rolled the current code on top of MacTCP.

>
> Using GUSI in MacTcl would indeed essentially mean ripping all the 
> existing socket code out and replacing it with the UNIX codebase 
> adapted for GUSI. Gluing  UNIX code into the Mac codebase for e.g. 
> channels may prove more challenging than you might think, it certainly 
> would not just be a drop in deal...
>
> While this may very well be possible, it would be no small job, I 
> certainly don't have time for it myself.
>

Yeah, I looked at this a while ago, and I decided I didn't have the time 
for it either.  My guess is it would probably be just as easy to rewrite 
the MacTCP code using OT, but I can't say for sure.

>
> However, I'm happy to help somebody else getting started to look into 
> this.

Yes, this would be great.  It is also a pretty fun little lab for 
someone who wants to play around with socket programming a bit.

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

[MACTCL] memory & sockets

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

While we are discussing memory stuffs here: 
In my QuickTime package I use NewGWorld() as follows:

	err = NewGWorld( &newGWorldPtr, 32, &aRect, NULL, NULL, 0 );
	if (err != noErr) {
		err = NewGWorld( &newGWorldPtr, 32, &aRect, NULL, NULL, useTempMem );
	}
    if (err != noErr) {
	    panic( "Out of memory: NewGWorld failed" );
	}

Should I use useTempMem as the first option?
Also, I use NewHandle to store compressed images which may take a lot
of memory. Should I use NewHandleSys to take memory from the system heap
instead? I'd like to make precaution from being stabbed in my back with
memory problems.


Socket code:

It is sad that the socket code is in such a terrible condition,
so I had a look at tclMackSock.c... I wouldn't touch it with my
bare hands, it looks very messy (probably due to the MacTCP APIs).
So I looked at the OpenTransport docs (1.3), and it seemed fairly
straightforward until I reached page 150 or so, where it says something
about "deferred interrupt time" where you can't even allocate memory...
At that point I stopped reading. :-(

Next, looked at the Unix channel code in tclUnixChan.c where the
tcp channel driver take up about half of that file (1000 lines readable code).
I got the GUSI stuff from SourceForge and found out that also MacPerl
(and MacPython) uses GUSI.

Wouldn't it be an idee to just get the unix channel driver code from
tclUnixChan.c, link it with GUSI, and make it into an extension,
just for testing? Are there any problems with this?
Question from an ignorant.
It makes 1000 lines instead of 2700 lines of unreadable code.

Mats

Re: [MACTCL] reinstalling after crashes...

[Bo R. <bo...@el...>]

Mats Bengtsson wrote:

> "Daniel A. Steffen" wrote:
> >
> > At 10:29 +0100 on 24/8/01, Andrew Wilson wrote:
> >
> > >You're not going to like this...
> >
> > no indeed not...
> > the socket code has gotten worse over time while the source hasn't
> > changed, we think it is due to the fact that it still uses mactcp
> > emulation code in opentransport and that that part of OT has
> > deteriorated because nobody much uses it anymore.
> >
> > I don't plan to look too hard at that code however, it's just too old
> > and messy, OSX would have become prevalent before I finished updating
> > this code to OS9 standards...
> >
> > maybe somebody more interested in networking and more familiar with
> > OpenTransport could take a look?
> >
>
> I know several applications using the GUSI (at SourceForge) MacPython,
> and several more, and that seems to work ok. GUSI is like POSIX sockets
> on the mac using OT under the hood. Couldn't it be possible to just
> replace the mac specific socket code with the unix one, and use GUSI
> for all socket stuff? After all, the unix socket code is very well tested.
> Anyone knows something more about GUSI?

I can only say that we are currently using GUSI 2.18 in our application to be

able to use the POSIX sockets and pthreads on Mac. It wasn't a big thing
porting
our PC POSIX version of our extension to the GUSI code, and everything seems
to
work really nice so far. We haven't completed the testing, but so far so good
:-).
The only thing we have seen so far is that the socket timeout is a little
different
from the normal POSIX version.

Bo

Re: [MACTCL] reinstalling after crashes...

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

At 12:05 +0200 on 25/8/01, Mats Bengtsson wrote:

>I know several applications using the GUSI (at SourceForge) MacPython,
>and several more, and that seems to work ok. GUSI is like POSIX sockets
>on the mac using OT under the hood. Couldn't it be possible to just
>replace the mac specific socket code with the unix one, and use GUSI
>for all socket stuff? After all, the unix socket code is very well tested.
>Anyone knows something more about GUSI?

I know GUSI quite well, I have worked with it in the past, but not on MacTcl.

AFAIK the socket code in MacTcl predates GUSI, which is why it wasn't used :-)

Using GUSI in MacTcl would indeed essentially mean ripping all the 
existing socket code out and replacing it with the UNIX codebase 
adapted for GUSI. Gluing  UNIX code into the Mac codebase for e.g. 
channels may prove more challenging than you might think, it 
certainly would not just be a drop in deal...

While this may very well be possible, it would be no small job, I 
certainly don't have time for it myself.

However, I'm happy to help somebody else getting started to look into this.

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] poup cascade crashes

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

At 12:06 +0200 on 25/8/01, Mats Bengtsson wrote:

>Mads Linden wrote:
>>
>>  i get "mac crashes" when using heavyli casceded popups in my app on the mac
>>
>>  please run the example i have made since i am in big trouble here, hit the
>>  "hit me" rapidly over and over, and select some sub items of the cascades.
>>
>>  sometimes it crashes after 5 hits, other times 20 aprox. hits
>>
>>  would love to know if i am the only one having these problems.
>  >

While I can reproduce Mads' menu problem, I can't reproduce your xml 
problem Mats, your script on a small xml file here works fine in 
8.3.3 and the latest 8.4. (using tclxml-2.1theta)

maybe you can send me your xml file?

>Same problem here. It's a memory manager problem.
>In MacsBug I get:
>	BowelsOfTheMemoryMgr
>	"Unable to acces that address"

The menu problem is different from the old memory deallocation bug, 
it may even be a macos bug, I can also reproduce it whatever the 
memory allocation of Wish, so it's more complicated.

I will look into it but am very busy at the moment, so it may taek a few days.

>However, I can reproduce it TclXML by parsing a simple document,
>se below, and then Quit from wish's menu..

I don't see this, this sounds like a bug I fixed for 8.3.3 when I 
rewrote the memory allocation and deallocation routines. Are you sure 
you have the latest 8.3.3 installed? (increasing wish's memory 
allocation should fix your bug)

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] poup cascade crashes

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

Mads Linden wrote:
> 
> i get "mac crashes" when using heavyli casceded popups in my app on the mac
> 
> please run the example i have made since i am in big trouble here, hit the
> "hit me" rapidly over and over, and select some sub items of the cascades.
> 
> sometimes it crashes after 5 hits, other times 20 aprox. hits
> 
> would love to know if i am the only one having these problems.
> 

Same problem here. It's a memory manager problem.
In MacsBug I get:
	BowelsOfTheMemoryMgr
	"Unable to acces that address"

However, I can reproduce it TclXML by parsing a simple document,
se below, and then Quit from wish's menu.. 
This is what MacsBug says (can send the StdLog on request).
I've got a faint memory that it worked in the test version I got
from Daniel. Perhaps someone could verify that. If anyone wants
to reproduce it I can help, just let me know.

/Mats

 Return addresses on the stack
  Stack Addr  Frame Addr   ISA   Caller
   0834740C                PPC   19F5A9C4 __UseResFile+000A0
   08347408                68K   18A082C2 Tcl_AppendObjToObj+00162
   083473C8                PPC   18A196DC TclExecuteByteCode+00858
   08347348    08347340    PPC   18A0ED50 Tcl_FindCommand+0012C
   08347328    08347320    PPC   189F16E0 Tcl_Alloc+00018
   0834731A                PPC   0007FFFC
   083472E8    083472E0    PPC   189F2538 Tcl_AppendToObj+0020C
   083472A8    083472A0    PPC   18A0ED50 Tcl_FindCommand+0012C
   0834729A                PPC   0007FFFC
   083470FA                68K   0108FFFE
   083470C8                PPC   002F437C EmToNatEndMoveParams+00014
   083470B8                68K   18A082C2 Tcl_AppendObjToObj+00162
   083470A8    083470A0    PPC   18A2AE70 TclObjInterpProc+000C4
   08347078    08347070    PPC   189F24CC Tcl_AppendToObj+001A0
   08347058    08347050    PPC   189F3008 Tcl_DStringFree+000C0

____________script__________________


# Testing XML parsing
package require xml

proc HandleStart {name attlist} {
    if {[llength $attlist] > 0} {
	puts stderr "Element start ==> $name has attributes $attlist"
    } else {
	puts stderr "Element start ==> $name"
    }
}
proc HandleEnd {name} {
    puts stderr "Element end ==> $name"
}
proc HandleText {data} {
    puts stderr "Character data ==> $data"
}

set myParser [xml::parser]
$myParser configure -elementstartcommand HandleStart  \
  -ignorewhitespace 1   \
  -elementendcommand HandleEnd -characterdatacommand HandleText

set fileName [tk_getOpenFile]
set fd [open $fileName]
set xmldata [read $fd]
$myParser parse $xmldata

Re: [MACTCL] reinstalling after crashes...

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

"Daniel A. Steffen" wrote:
> 
> At 10:29 +0100 on 24/8/01, Andrew Wilson wrote:
> 
> >You're not going to like this...
> 
> no indeed not...
> the socket code has gotten worse over time while the source hasn't
> changed, we think it is due to the fact that it still uses mactcp
> emulation code in opentransport and that that part of OT has
> deteriorated because nobody much uses it anymore.
> 
> I don't plan to look too hard at that code however, it's just too old
> and messy, OSX would have become prevalent before I finished updating
> this code to OS9 standards...
> 
> maybe somebody more interested in networking and more familiar with
> OpenTransport could take a look?
> 

I know several applications using the GUSI (at SourceForge) MacPython,
and several more, and that seems to work ok. GUSI is like POSIX sockets
on the mac using OT under the hood. Couldn't it be possible to just
replace the mac specific socket code with the unix one, and use GUSI
for all socket stuff? After all, the unix socket code is very well tested.
Anyone knows something more about GUSI?

Mats

Re: [MACTCL] reinstalling after crashes...

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

At 10:29 +0100 on 24/8/01, Andrew Wilson wrote:

>You're not going to like this...

no indeed not...
the socket code has gotten worse over time while the source hasn't 
changed, we think it is due to the fact that it still uses mactcp 
emulation code in opentransport and that that part of OT has 
deteriorated because nobody much uses it anymore.

I don't plan to look too hard at that code however, it's just too old 
and messy, OSX would have become prevalent before I finished updating 
this code to OS9 standards...

maybe somebody more interested in networking and more familiar with 
OpenTransport could take a look?

>--- cut here ---
>set conn [socket "www.yahoo.com" 80]
>--- cut here ---
>



>--- cut here ---
>wm protocol . WM_DELETE_WINDOW shutdown
>
>set conn [socket "www.yahoo.com" 80]
>
>proc shutdown {} {
>     global conn
>     close $conn
>     after 500
>     destroy .
>}
>--- cut here ---

this is good info, thanks a lot. I mostly uses Tcl sockets 
communication on LAN's myself, so the timeout issue hasn't come up

Until somebody fixes this, it will just have to be a thing to be 
careful about for mac tcl users...

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] poup cascade crashes

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

i get "mac crashes" when using heavyli casceded popups in my app on the mac

please run the example i have made since i am in big trouble here, hit the
"hit me" rapidly over and over, and select some sub items of the cascades.

sometimes it crashes after 5 hits, other times 20 aprox. hits

would love to know if i am the only one having these problems.

HELP!!!!!!

# START

proc cascadebug {} {

	set m .mb.menu
	menubutton .mb -menu .mb.menu
	menu .mb.menu -bd 0 -tearoff 0


	set time 0.0
	set count 0
	set limit 24.0
	set limit2 24.1

	while {$time < $limit} {
		set tmp ""
		set time2 0.0

		# make the main time cascade
		$m add cascade -label "$time" -menu ${m}.sub${count}
		set tmp_m [menu ${m}.sub${count} -tearoff 0]

		while {$time2 < $limit2} {
			if {$time2 > $time} {
				$tmp_m add command -label "$time2" -command "after 40 {puts {hello
$time2}}"
			}
			set time2 [expr $time2+0.25]

		}

		set time [expr $time+0.5]
		incr count
	}

	grab set .mb.menu
	update

	tk_popup .mb.menu [winfo pointerx .] [winfo pointery .]

	update

	grab release .mb.menu
	destroy .mb .mb.menu

}


console show
update

label .hej -text "hit me"
pack .hej
bind .hej <Button-1> {cascadebug}


# STOP

Re: [MACTCL] reinstalling after crashes... (fwd)

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

[wups, I forgot to cc the list]

Hi Daniel,

Daniel A. Steffen:
> >while testing some tcl/tk applications I sometimes run into a bug
> >that is big enough to crash MacOS 9x - typically the window manager
> >locks up, clicking on icons doesn't work, that sort of thing.
> >Force Quit isn't enough to free up the system so eventually I have
> >to reset the machine.
> 
> that's a pretty bad bug that shouldn't happen, I haven't seen 
> anything of the sort using Mac Tcl/Tk with a variety of software, if 
> you can give more explicit details about your crashes, I would be 
> interested to see if I can reproduce them.

You're not going to like this...

--- cut here ---
set conn [socket "www.yahoo.com" 80]
--- cut here ---

Run the script on MacOS 9.x and use the left-hand button in the
wish window to perform the quit.

I'm on the end of a modem in the UK and yahoo.com is > 200ms away,
ping-time.  It's not just Yahoo, and it's not just webservers;
pretty much any distant host/port will cause this problem.
Interestingly the same problem doesn't occur when the host/port is
on my local network, ping times < 1.5 ms.

The essence of the bug is that calling 'destroy .' before the
connection-closure has had time to register with the OS, seems to
lock the machine.

Here's a more elaborate script that gives some clues:

--- cut here ---
wm protocol . WM_DELETE_WINDOW shutdown

set conn [socket "www.yahoo.com" 80]

proc shutdown {} {
    global conn
    close $conn
    after 500
    destroy .
}
--- cut here ---

Changing the 500ms delay to something like 1000ms will cure the
bug.  The connection 'has time' to close.

So, this bug seems to come about for clients that are a long way
from the server.  Another way to provoke a crash, perhaps indicating
the same bug is:

o	turn your modem on
o	run example 1
o	turn your modem off (if your modem isn't connected directly
	to the Mac then turning it off won't signal a disconnection.
	my modem is connected to the firewall machine, not the
	iBook)
o	now try to quit the script

This method doesn't always cause the crash however.

In this case the iBook seems to see a server that has suddenly
stopped responding, 'perhaps the network is congested'.  Perhaps
the OS is looking for confirmation from the host that it's
disconnecting.

	I dunno enough about TCP/IP to know what kind of low-level
	handshaking is going on between MacOS and the remote server.
	But it sure looks like MacOS is looking for some external
	confirmation that the connection has been dropped before
	clearing up.

> >Sometimes, after such a reset, an existing application built by
> >the 'Drag & Drop Tclets' app will stop working.  eg, when running
> >8.3.3 I'll sometimes see a dialog box saying that the application
> >couldn't be run because tcl8.3 couldn't be found.  I check the file
> >system and all the folders and libraries are in the usual place,
> >nothing obviously missing.
> 
> I have seen this behaviour occasionally myself, it is due to a MacOS 
> bug. There is a much easier fix, just move your 'Tool Command 
> Language' folder out of your Extensions folder e.g. onto the desktop 
> and then drop it right back into Extensions... that fixes things for 
> me. (I think the bug is due to code fragment manager caches to shared 
> libraries getting corrupted when aliases to shared libraries on 
> volumes other than the startup volume are involved, so another 
> possible workaround is to copy the actual libraries into 'Tool 
> Command Language', replacing the aliases. I have also noticed a 
> dependency on File Sharing, when it is enabled the problem seems to 
> occur more often)

Handy to know ;)

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

Cheers,
Ay.

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

Re: [MACTCL] reinstalling after crashes...

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

Andrew,

At 8:48 +0100 on 24/8/01, Andrew Wilson wrote:

>while testing some tcl/tk applications I sometimes run into a bug
>that is big enough to crash MacOS 9x - typically the window manager
>locks up, clicking on icons doesn't work, that sort of thing.
>Force Quit isn't enough to free up the system so eventually I have
>to reset the machine.

that's a pretty bad bug that shouldn't happen, I haven't seen 
anything of the sort using Mac Tcl/Tk with a variety of software, if 
you can give more explicit details about your crashes, I would be 
interested to see if I can reproduce them.

>Sometimes, after such a reset, an existing application built by
>the 'Drag & Drop Tclets' app will stop working.  eg, when running
>8.3.3 I'll sometimes see a dialog box saying that the application
>couldn't be run because tcl8.3 couldn't be found.  I check the file
>system and all the folders and libraries are in the usual place,
>nothing obviously missing.

I have seen this behaviour occasionally myself, it is due to a MacOS 
bug. There is a much easier fix, just move your 'Tool Command 
Language' folder out of your Extensions folder e.g. onto the desktop 
and then drop it right back into Extensions... that fixes things for 
me. (I think the bug is due to code fragment manager caches to shared 
libraries getting corrupted when aliases to shared libraries on 
volumes other than the startup volume are involved, so another 
possible workaround is to copy the actual libraries into 'Tool 
Command Language', replacing the aliases. I have also noticed a 
dependency on File Sharing, when it is enabled the problem seems to 
occur more often)

>I've found that uninstalling the 8.3.3 distribution and then
>re-installing it solves the problem.  After re-installing, the
>existing application built by the 'Drag & Drop Tclets' app will
>work again.  So, ok, sometimes re-installing helps.
>
>About uninstalling...  I'm new to Macintosh so I didn't know about
>the implicit Restart required when uninstalling software.  The VISE
>uninstaller doesn't actually delete files, instead it moves them
>into invisible folders and signals the OS that it should *really*
>delete the folder the next time the machine boots up.  The VISE
>uninstaller doesn't say "you must restart to make these changes
>take effect", but it would be helpful if it did.  I found that
>nievely uninstalling and then immediately installing tcl8.3.3 (no
>reset) wasn't enough to fix the "tcl8.3 couldn't be found" error-dialog
>problem.

you don't necessarily need to use the uninstaller to uninstall 
Tcl/Tk, you can just drag your Tcl/Tk folder and the 'Tool Command 
Language' Folder to the Trash and empty, no restart should be 
necessary. I didn't realize the VISE installer had this limitation, 
alas the uninstaller part of VISE isn't configurable, so I can't 
really do anything about that for the next release...

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] reinstalling after crashes...

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

Hi,

while testing some tcl/tk applications I sometimes run into a bug
that is big enough to crash MacOS 9x - typically the window manager
locks up, clicking on icons doesn't work, that sort of thing.
Force Quit isn't enough to free up the system so eventually I have
to reset the machine.

Sometimes, after such a reset, an existing application built by
the 'Drag & Drop Tclets' app will stop working.  eg, when running
8.3.3 I'll sometimes see a dialog box saying that the application
couldn't be run because tcl8.3 couldn't be found.  I check the file
system and all the folders and libraries are in the usual place,
nothing obviously missing.

I've found that uninstalling the 8.3.3 distribution and then
re-installing it solves the problem.  After re-installing, the
existing application built by the 'Drag & Drop Tclets' app will
work again.  So, ok, sometimes re-installing helps.

About uninstalling...  I'm new to Macintosh so I didn't know about
the implicit Restart required when uninstalling software.  The VISE
uninstaller doesn't actually delete files, instead it moves them
into invisible folders and signals the OS that it should *really*
delete the folder the next time the machine boots up.  The VISE
uninstaller doesn't say "you must restart to make these changes
take effect", but it would be helpful if it did.  I found that
nievely uninstalling and then immediately installing tcl8.3.3 (no
reset) wasn't enough to fix the "tcl8.3 couldn't be found" error-dialog
problem.

I hope this helps someone ;)

Cheers,
Ay.

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

Re: [MACTCL] iwidgets - can not find Itk ...

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

Jon Guyer wrote:
> 
> At 10:18 PM -0500 8/22/01, Andrew Robinson wrote:
> 
> >I wish I could remember who explained this to me to give proper attribution.
> 
> Almost surely Daniel Steffen.
> 

Indeed. Thanks!

Andrew Robinson

Re: [MACTCL] iwidgets - can not find Itk ...

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

At 10:18 PM -0500 8/22/01, Andrew Robinson wrote:

>I wish I could remember who explained this to me to give proper attribution.

Almost surely Daniel Steffen.

-- 

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

Re: [MACTCL] iwidgets - can not find Itk ...

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

Dave, I asked this very question last week ;). The way I installed the
[incr tcl] package originally, I placed the iwidgets3.0.0 folder in the
Tcl/TK 8.3.3 Folder folder and created an alias to it in the Tool
Command Language folder. It was explained to me that I needed to put a
copy of the iwidgets3.0.0 folder in the Tool Command Language folder
instead of the alias. That worked for me. I wish I could remember who
explained this to me to give proper attribution.

Andrew Robinson

David Robinson wrote:
> 
> I am currently running Tcl/Tk 8.3.3 on a Mac and have downloaded Itcl
> and placed the various components in the locations suggested in the
> directory.  However, the following command seems to have difficulty
> (when executed under Wish):
> 
> package require Iwidgets 3.0
> can't find package Itk 3.1
> 
> I am new to Itcl so it is quite possible I have misplaced or forgotten
> something.  Any suggestions?
> 
> Dave Robinson
> dr...@sa...

[MACTCL] iwidgets - can not find Itk ...

[David R. <dr...@sa...>]

I am currently running Tcl/Tk 8.3.3 on a Mac and have downloaded Itcl
and placed the various components in the locations suggested in the
directory.  However, the following command seems to have difficulty
(when executed under Wish):

package require Iwidgets 3.0
can't find package Itk 3.1

I am new to Itcl so it is quite possible I have misplaced or forgotten
something.  Any suggestions?




Dave Robinson
dr...@sa...

[MACTCL] Tclapplescript (working now)...

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

Hi Jon and Daniel,
 
I opened wish under the 'Tcl/Tk Folder 8.3.3' and the 'package
require Tclapplescript' returned 1.0, not the expected 1.1.  
 
Yesterday I'd installed the 8.3.0 dist (which called itself 8.3.1
when you check the info for the files), I guess that I didn't
uninstall that version properly and some of the files hung around
to cause problems later.
 
I ran uninstall on the 8.3.3 installer and then reinstalled, the 
'package require' then returned 1.1, problem solved.

I had installed the 8.3.3 from 
    
    http://prdownloads.sourceforge.net/tcl/TclTk_8.3.3_RuntimeInstall.bin

I guess the moral is for me to scrub the system clean before
installing a new version ;)
 
Sorry for the false alarm, but MacOS is new to me so I felt a little
clueless. 

Cheers,
Ay.

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

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

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

At 18:10 +0100 on 20/8/01, Andrew Wilson wrote:

>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

have you installed an older version of TclTk on that box before? 
check the version number of the droplet produced by 'Drag & Drop 
Tclets', this needs to be the same as the one of 'Wish 8.3.3', if 
this is not the case, use the 'Select Wish Stub' menu command in 
'Drag & Drop Tclets' to select 'Wish 8.3.3'

another test is to open Wish and type the commands from Jon's mail, 
if this works there is a problem with your script

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

the library MSL RuntimePPC.DLL is part of the 'Wish 8.3.3' 
application, which probably means you're running your script inside 
something else

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

there is no difference between those install options with regards to 
installed runtime libs, so it's normal that this doesn't help.

be sure to get
http://prdownloads.sourceforge.net/tcl/TclTk_8.3.3_RuntimeInstall.bin

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