We think we've found it... It looks like it's a timing problem with events, the application launch event is where runtimes are supposed to be started, but it never arrives. I can cause the problem by judicious use of breakpoints under 9 or X now, and its clearly machine speed related (the faster the machine, the more likely it will exhibit the problem). Its not clear who's eating the missing event... I suspect GUSI is catching it somewhere. After the app is started I can send it an odoc event and since the open event handler also checks whether a runtime script is present, the runtime app will actually start then.
I'm going to poke around at reorganizing where the event handlers are installed to see if I can find who is eating the event. If that doesn't work I may try generating a fake event to start the runtime after the globals are set up. Alex -- Alex Harper [EMAIL PROTECTED] Configuration Manager [EMAIL PROTECTED] "Use whatever you think of first" -- Larry Wall > -----Original Message----- > From: M. Christian Hanson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 2:03 PM > To: Bart Lateur; [EMAIL PROTECTED] > Subject: Re: [MacPerl] MacPerl 5.6.1r1 runtimes under MacOS X? > > > I think Bart is close. > > On 5.2.0r4 under OS X.1 this fall I had problems with droplets > instead of running they would just open up for editing in MacPerl > without every launching as their own app. Under OS 9 they worked > fine. And on my new machine I got in decemeber it worked fine. > > I have noticed a 'feature' of OS X is that when you click on a .smi > (self-mounting disk image) file in OS X is sends an open event with > the file to Disk Copy. (which is of type 'APPL' and would launch and > mount itself under os 9) So OS X doesn't always just launch Classic > Apps, sometimes it decides it better treat them like a document (this > is a assumption). > > Try (and I know this is strange) rebuilding the desktop db (I think > there is a place in the Classic Pref Pane to do that from). > > Anyhow good luck with the debug, but I think the OS may be > the culprit. > > At 10:50 AM +0100 3/20/02, Bart Lateur wrote: > >On Tue, 19 Mar 2002 21:25:22 -0600, Alex Harper wrote: > > > >>For our users we build MacPerl runtime versions of some > scripts. MacPerl > >>5.2.0r4 had no problem running those Runtimes under Classic > on MacOS X. > >>Runtimes built under 5.6.1r1 launch the interpreter but do > not start the > >>script stored in the "!" TEXT resource. Those same runtimes > operate just > >>fine when the machine is booted to MacOS 9 from the same > System Folder > >>used for Classic. > >> > >>Here's what I've found so far: > >>- Not all MacOS 10.1.3 machines exhibit the behavior (my personal > >>machine works fine) > >>- The script content/libraries needed has no effect. Hello > World fails, > >>for example. > >>- MacsBugs breaks in Get1NamedResource show that the runtime is the > >>current res file, and that the resource is loaded. > >>- The machines in question have no other verion of MacPerl, no prior > >>MacPerl preferences, etc. > >> > >>Before I launch into a debug build of MacPerl (or a massive > rollback of > >>our runtime applications) has anyone encountered this > problem before? If > >>not, any tips where to start looking in the code? > > > >My gut feeling tells me this must be an AppleEvent related problem. I > >think it goes wrong at the place where the droplet tells its built-in > >MacPerl to "run this script". > > > >Does Applescript work properly on these machines? > > > >-- > > Bart. > > > -- > -mch > >
