Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

pudge
  (email not shown publicly)
http://pudge.net/
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Monday November 25, 2002
10:58 AM

Mac Stuff Progress

[ #9136 ]

After taking a short break since the release of Mac::Carbon 0.01, I am this week going to try to work toward finishing up MacPerl 5.6.1r2. All the bugs for this release have been fixed, I just need to clean up things, commit them, sync up changes with various perforce branches and module distributions, prepare some docs, etc. Then I'll release Mac::Carbon 0.02 and begin work on Mac::AppleEvents.

It's sortof a pain sometimes to deal with the MacPerl sources, because I have the source in CVS, and across three branches in perforce (maint-5.6/macperl, maint-5.8/macperl, macperl). I've not touched them in awhile, so I will need to sync them with what is current in maint-5.6/perl, maint-5.8/perl, and perl. I really only have one change to the perl core, a couple of lines for signals in util.c.

Last time I left a bunch of docs and sample code out of the MacPerl distribution, and I need to add them back in.

I've made a few changes to a few module distributions that are separate (like Mac::Glue), plus Mac::Carbon, so I need to sync those up and release them.

Mac::AppleEvents doesn't look too hard, just a lot of work going over what is still good or not in the API, and making changes to a few changed portions of the API (hopefully, this won't be too difficult, but some of the API has subtly changed, in part because direct memory access is now a no-no, and in part because some of the API used to be in a separate third-party library and Apple changed it when they swallowed it up).

I also need to come up with the AE idle procedure, which I have no real idea how to do. ;-) MacPerl's SubLaunch.c has SubLaunchIdle(), which uses a global called gMacPerl_HandleEvent. Now, SubLaunchIdle() and gMacPerl_HandleEvent are only used in Mac::AppleEvents (outside of the application, which is not being used here), so I can probably make it "global" to AppleEvents.xs, if I even need it; it looks to me like gMacPerl_HandleEvent itself is only used by the app, so I can modify SubLaunchIdle() to work without it (the procedure first checks to see if there is a MacPerl event, and if not, it checks to see if there is an Apple event waiting). OK, fine. Looks pretty straightforward (especially compared to the API changes).

I am still not sure how well AEs will work, coming from perl instead of an application. In a week or three, I imagine I'll find out. :-) I suppose if the AppleScript code works, and it does, then there shouldn't be a problem. I am optimistic that I will have something working before the end of December. Look for it in Mac::Carbon 0.03!

Now Playing: My Ship - Miles Davis (Love Songs)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.