Mac Stuff Progress
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!
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)
"It is the common fate of the indolent to see their rights become a prey to the active. The condition upon which God hath given liberty to man is eternal vigilance; which condition if he break, servitude is at once the consequence of his crime and the punishment of his guilt."
Leave a comment