Computers: December 2002 Archives

OK, so Apple did get the PowerBook in time to fix it, and I got it back today; the web site said on Friday it had been received late on Friday and that was the last word, and the web site is down until Jan 2, as all their systems are being upgraded.

So the note inside said they fixed the problem, replacing the logic board (I am now on this computer's third logic board, though I think this replacement was likely unnecessary ... read on).

I try to boot the computer on the battery. Once again, it failed. Sigh. They simply did not fix the problem they caused the last time. If you recall, I sent in the computer to get the optical drive fixed, and it came back not powering with the battery. They apparently didn't even TEST to see if the problem THEY CAUSED was fixed this time around. So I get the computer back from its second "repair" with the exact same symptom as before. It boggles the mind. "Computer won't work with battery" apparently means "just replace the logic board, don't bother trying to use the computer with the battery."

And because their systems are being upgraded, I probably won't get a box to ship the computer back for several days.

The only good thing about the state of the computer is that it appears to work fine if no battery is installed, so I can at least work on setting the computer up (I am reinstalling everything, including fink, perl, etc.).

Now Playing: Closer To You - The Wallflowers (Red Letter Days)

Apple's box should have arrived Christmas Eve, but didn't arrive until Boxing Day. So Apple received it Friday, but not until very late, and apparently didn't touch it. Hopefully they fix and ship it today, and I get it tomorrow.

Now Playing: How Good It Can Get - The Wallflowers (Red Letter Days)

My PowerBook had a problem recently. It would not eject optical discs. I wouldn't blame Apple for this, as it could have been damage I caused (I have no idea how, but there was a slight dent in the case near the drive, so ...). So I send it in for repairs on Thursday. Apple covers it all under warranty, replaces drive, half the case, and a cable. Repairs and ships on Friday. I get it back this morning, Monday. Great!

But um ... now it won't use the battery. Having the battery in the computer while powered with the AC can cause the computer to freeze. Pressing on the battery compartment causes the AC adapter's light (which tells if there is power, and if the battery is charging) to flicker. Smells like a bad connection. I open it up and the two screws holding the connector to the battery are not tightened. Tightening them makes the flicker go away, but despite resetting the Power Manager, I still can't power up using the battery.

Back to Apple tomorrow. If I am lucky, they fix it and return it on Thursday, and I get it back Friday. With no new or old problems. :-)

He is back for a three-episode stint of a new show that finishes up tonight on Comedy Central, after The Daily Show. It's the best part of his short-lived show from earlier this year on NBC: a diverse bunch of comics sitting around making fun of various religions, ethnicities, etc. ... you know, the stuff we are afraid to laugh at, but IMO (and theirs) should be laughing at a lot more. Very good stuff. I hope they pick it up for a regular show following TDS every night.

U.S. President George Bush is a Christian. Artist Moby is a Christian. Iraq Deputy Prime Minister Tariq Aziz is a Christian.

At least one of them is lying. ;-)

I installed perl 5.8 on my Mac OS X 10.2 server box. Installed it into /usr/local/. Worked great, except I get annoying errors from cc about changing the library path order, and I have issues with XS (I included /Library/Perl in my path); I needed to make sure those XS modules were not loaded by accident while installing the others (for awhile I temporarily moved /Library/Perl while running perl -MCPAN -eshell to install other stuff).

Mac::Carbon 0.03 is on the CPAN (er, on its way there, anyway) and SourceForge.net.

      http://sf.net/projects/macperl/
      http://www.cpan.org/authors/id/C/CN/CNANDOR/

It fixes the bugs with AEDesc, POD, xsubpp, building on Mac OS X 10.1/gcc2/etc. A binary distribution for perl 5.6 is available from SourceForge.net. Thanks to all who have helped, and please submit bugs to SourceForge.net if you have any to report.

This is the last release for a little while; I am going to focus on fixing some of the outstanding bugs listed in the documentation. Patches welcome. Enjoy!

Now Playing: Run - Brett Williams & In Reach (Power & Promise)

Thanks to brian d foy, I've got a Makefile workaround to use the included xsubpp for Mac::Carbon instead of the system one (MacPerl and Mac::Carbon use nonstandard XS macros and a nonstandard xsubpp). So I won't need to include the .c files anymore; they will be automatically generated properly.

Since that was working, I went ahead and did the second phase, which is autogenerating .pod files (because there is POD in the .xs, as MacPerl/Shuck uses the nonstandard =include directive so the extensions can have some sense of literate programming, keeping the documentation with the .xs functions). So now the documentation is (more or less) correct.

I refactored the Makefile.PLs to share a common.pl file, because there's just too much now. Most of the Makefile.PLs are reduced to:

use File::Spec::Functions;
use strict;
do(catfile(updir(), 'common.pl'));
domakefile();

And, I made a few changes to get it to compile under gcc2 (for Mac OS X 10.2, anyway). Hopefully it will work for 10.1.x users, too. Thanks to Ken Williams and Paul McCann for pointing that out.

I am going to sit on this a few days and release it as 0.03 next week. It'd be nice to get that "GUSI" bug fixed in the meantime. We'll see.

Now Playing: St. John - Aerosmith (Permanent Vacation)

Not necessarily in order.

• Fix my GUSI emulation bugs so FSSpecs can be created without file existing
• Release 0.03
• Better test suite (esp. Files, MoreFiles, AppleEvents, OSA)
• Work on new system for releasing modules (not necessary, but would be nice :)
• Release ported Mac::OSA::Simple
• Release ported Mac::AppleEvents::Simple; this may require some work to get remote Apple events working (they currently don't, I think the way to do this changed in Mac OS X, and this may come later ... remote events are not as critical at the moment)
• Port and release Mac::Apps::Launch; launching and quitting applications (and finding them!) has changed in various ways, may also require changes to Mac::Processes
• Port and release Mac::Glue (not a lot to do once all the other pieces are ported!)

Last night I said all this may take a month. That's the optimistic side. It's possible, if all the bugs are fixed easily (ha!) and I can quickly figure out the best way to do the apps launching (ha! ha!). But really, it'd be nice to get all this done by February.

Now Playing: Burning Down - King's X (Gretchen Goes To Nebraska)

My office closes for the week of Christmas, so I will mostly be offline at that time. I am taking the opportunity to send my PowerBook G4 in for repairs, next week. I won't be doing much development while it's away. Mmmm, vacation. Hopefully I get it back on Dec. 30 or before, just in time to start working again.

Now Playing: Over My Head - King's X (Gretchen Goes To Nebraska)

In this comment, I got modded down for Troll/Flamebait for accurately pointing out that the idea that Mac OS X is "crash-free" is a fallacy. Note that Mac OS X is not, has never been, and will never be, crash-free. I like Mac OS X, but I won't drink the Kool-Aid. Thanks.

On the macosx@perl mailing list, it was asked how to quit an app. Many people suggested AppleScript. But, as I am fond of saying, I hate AppleScript. So:

#!/usr/bin/perl -w
use POSIX 'SIGTERM';
use Mac::Processes;
while (my($psn, $psi) = each %Process) {
    next unless $psi->processName eq 'Mozilla';
    kill SIGTERM, GetProcessPID($psn);
    last;
}

Now Playing: What A Wonderful World - Russ Taff (A Christmas Song)

My TiVo is no more. It is now DIRECTV Digital Video Recording Service. Now I don't get TiVo Central, I get DirecTV Central. I still get TiVolution magazine, but when I hit "0" in the DirecTV Central screen, I don't get the TiVo animation thing anymore.

Sad.

With Mac::OSA, you can get the source of the compiled OSA script (such as AppleScript) that you are working with (unless it was saved without the source).

my $desc = OSAGetSource($component, $scriptid, typeChar);
my $source = $desc->get;

But even on Mac OS X, it is returned with Mac newlines, CR, instead of Unix newlines, LF. Even if the input source was with Unix newlines.

I was having problems with AEDescs because I was putting data into Handle using strlen() to get the size. strlen() just figures out the length of a C string, up to the first null. I wanted to use the length from AEGetDescDataSize() or GetPtrSize(). But I didn't.

Mac::OSA::Simple works pretty well, though I need to release a new version to support Mac OS X. I can do stuff like:

use Mac::OSA::Simple;
my $play  = compile_applescript('tell app "iTunes" to play');
my $pause = compile_applescript('tell app "iTunes" to pause');
 
sub play  { $play->execute  }
sub pause { $pause->execute }

Calling play() and pause() are much much faster than calling DoAppleScript($script) over and over again, because the compilation phase of the AppleScript is time-consuming. This kind of thing should work fine now, but return values are broken (the way AEPrint() returns data has changed, and I was using that instead of $desc->get), as is saving a script to disk (e.g., $pause->save($filename); my $script = load_osa_script($filename, 1);; this is related to the problem of my current FSSpec routines requiring files to exist, which needs to be fixed).

So I won't be releasing the new Mac::OSA::Simple too soon; I want to first see about addressing my issues with the FSSpec routines, and I need to revamp how I release modules (bug reporting, CVS, releases on CPAN and SourceForge.net, etc.).

Mac::Carbon 0.02 is released. Most notable changes are the inclusion of Mac::AppleEvents and Mac::OSA, the Pick/Answer/Ask functions added to the MacPerl package, and the GetProcessPID and GetProcessForPID functions added to Mac::Processes. Check out the SF.net site for the source and a binary installer (for if you have a Mac OS X previous to 10.2, or don't have the Developer Tools installed), and read the release notes.

I'll be giving a demo of this stuff tomorrow at the Boston.pm meeting.

I am going to be demo'ing Mac::Carbon at the Boston.pm meeting tomorrow night, at the offices of boston.com at 7:30 p.m.

Now Playing: You Will Go Free - Tonio K. (Romeo Unchained)

Today I committed a bunch of changes (for the future) to SOAP on Slash, in the SOAP plugin. It's an architecture for more easily adding SOAP methods to Slash plugins. You just enter the class name and method in a database table, make the method available in a module (or somesuch) of that classname, and there you go. It handles access control (seclev and subscriber_only, for sites that support subscribers) and provides access to the Slash formkeys mechanism (which, while extraordinary convoluted, works fairly well and is useful).

Eventually I'll port the Journal SOAP stuff over. Everything about the API should stay the same except for the proxy (soap.pl instead of journal.pl), though we can probably hack it to make it work with either one, for awhile anyway.

So I am envisioning a superhero that has the power to do virtually anything, as long as it's really stupid. For example, a guy is drowning in a pool, so he says, "I'll increase the temperature of the water until it turns to gas form!" Or a large meteor is going to destroy the Earth, so he says, "I'll block its path with the Moon!" Out-of-the-frying-pan-into-the-fire sort of stuff.

Call him Frying Pan Man? The reference is both too obvious and not obvious enough, at the same time. Some people will get it and think it it stupid, some will not understand it at all. References don't make good superhero names, I think.

Matthias tracked down a colleague who gave him a code snippet that worked for me. I don't know why the other didn't -- supposedly, it should have -- but this works, so I'm happy. Instead of AESend() it uses AESendMessage() (which doesn't use an idle proc), and it puts an attribute in the Apple event that says what port the process can receive messages on. So now I have perl on Mac OS X sending *and* receiving raw Apple events.

I don't have Apple events to remote machines working. I am not entirely sure why. I do know I have problems with it in Script Editor too, so it might not even be a problem with the Perl code at all. I think it might be, though: I can't find typeTargetID (which is the address type I use in Mac OS to send remote calls) anywhere in any of the headers. I think the method to do this has changed; maybe remote events use SOAP, maybe something else? I'll investigate later.

I also have a problem that is killing me with creating AEDescs. I have this code:

Ptr  theData;
Size theLength;
Handle data;  // contains "hi"
OSType type;  // contains "TEXT"
 
AEFail(AECreateDesc(type, *data, GetHandleSize(data), &RETVAL));
 
// test this, see what we have
theLength = AEGetDescDataSize(&RETVAL);
theData = malloc(theLength);
if (theData != NULL) {
    AEFail(AEGetDescData(&RETVAL, theData, theLength));
    printf("%d:%s:%d\n", theLength, theData, strlen(theData));
}

Now, *data contains "hi" and GetHandleSize(data) is 2. theLength is 2. But after AEGetDescData(), theData contains "hi5{" and strlen(theData) is 4. No matter what I do, if the string is 2 bytes, "5{" is tacked onto the end. If it is 3, "{" is tacked on. If the data is 1 or more than 3 bytes, it comes out fine. It's freaking me out.

So, I have bunches of little bugs like this. The GUSI* routines are working pretty well, but totally bail if the target file does not exist, which is a very wrong thing to do. It might take total reengineering. Yuck.

The AEBuild error code for $@ is acting up a little; for some reason it is displaying an error when there should be none. But I am resisting the temptation to look into it now, and instead am just noting it, as I am taking the weekend off.

I also need to work on Mac::AppleEvents::Simple some, though it seems to be fine except for the remote calls. So far. I'm sure I'll find more. Mac::Apps::Launch and Mac::Processes need an overhaul for launching processes on Mac OS X. The old calls I use sorta work, but not really, and they are slow.

I hope to release Mac::Carbon 0.02 next week, and then continue to iron out these other bugs and things for a Mac::Carbon 0.03 next year, along with updates to Mac::Apps::Launch and Mac::AppleEvents::Simple (sold separately). Then, when I am satisfied it is working reasonably well, I'll do Mac::Glue.

One of the porting problems I ran into was that vAEBuild and friends now have an optional second parameter (put in between the first and formerly second parameter) for syntax errors in the format string. I've decided (for now) to plop that extra information into $@. This sort of thing can really come in handy when trying to write those AEGizmos strings.

use Mac::AppleEvents;
use Mac::Errors;
$e = AEBuildAppleEvent(qw(aevt odoc sign MACS), -1, 0, "asdasd");
print "$Mac::Errors::MacError: $@" if $!;
__END__
 
AEBuildDesc and friends detected a syntax error: Missing ":" after keyword in record at character 6

And:

use Mac::AppleEvents;
use Mac::Errors;
$e = AEBuildAppleEvent(qw(aevt odoc sign MACS), -1, 0,
    q"'----':obj { want:type(cobj), from:null(), form:enum(name), seld:TEXT(@)",
    "Orr:"
);
print "$Mac::Errors::MacError: $@" if $!;
__END__
 
AEBuildDesc and friends detected a syntax error: Expected "," or "}" at character 72

Now Playing: I'm Forgettable - Brak (Brak Presents The Brak Album)

Last night's problem was solved by adding "-lstdc++" to the linker flags. Thanks, Matthias!

So today, I get it working, and I try a simple script:

use Mac::AppleEvents;
$evt = AEBuildAppleEvent(qw(misc actv sign MACS), -1, 0, "");
AESend($evt, kAENoReply);

And sure enough, it activates the Finder. This is the equivalent of the AppleScript:

tell app "Finder" to activate

Sweet. I've even tried some more complex things, opening a directory in the Finder, using the Mac::AppleEvents::Simple frontend:

use Mac::AppleEvents::Simple ':all';
 
$evt = build_event(qw(aevt odoc MACS),
    q{'----':obj { want:type(cobj), from:null(), form:enum(name), seld:TEXT(@)}}
    "Orr:Users:pudge:"  # yes, AEGizmos requires HFS paths
);
$evt->send_event(kAENoReply);

Or, using aliases:

use Mac::AppleEvents::Simple ':all';
use Mac::Files;
 
$evt = build_event(qw(aevt odoc MACS), q{'----':alis(@@)}, NewAlias("/Users/pudge/")); $evt->send_event(kAENoReply)'

All looks good so far. But, you may ask, why kAENoReply? Sure, I don't need the reply, but why bother not waiting, as per the default? There's the big remaining problem: I can't receive a reply. I have an idle proc that appears to be working -- as is needed to receive a reply -- but it's not getting the event back. I was afraid of this. In Mac OS, you need to set a flag that says your application can receive high-level events (such as Apple events). But how to do this for perl? No idea. Working on a solution, but in the meantime, polishing and playing.

I also still need to port the AESubDescs (for subdescriptors) and AEStreams (an OO interface to handling Apple event data) stuff, but they are rarely used, and are a lower priority than just getting this to work. I'll be more than happy to add them back in later, if I can.

Now Playing: Found a Home - Jon Gibson (Forever Friends)

MacPerl 5.6.1r2 is now available on SourceForge.net, and is making its rounds on the CPAN. Several major bugs were squashed, along with a slew of minor ones, and Shuck now has a section menu and can print. Just run the Web Installer again to update to the latest version, or download a new installer. See the release notes and change log for more information.

I've got most of it ported, though I've not done any testing yet. I am running into some undefined symbol errors:

$ perl -Iblib/arch -Iblib/lib -MMac::AppleEvents -e1
dyld: perl Undefined symbols:
__ZdlPv
__Znwm
___gxx_personality_v0

They are apparently related to C++ (AppleEvents.xs links to PerlAEUtils.cp) and gcc and linking. I just don't really have a clue as to how to deal with it.

MacPerl 5.6.1r2 has been released. Details are on SourceForge.net. I'll post it on use.perl.org tomorrow, once CPAN has had a chance to catch up.

Now Playing: Art Carney's Dream - The Swirling Eddies (Zoom Daddy)

The new miniseries on SciFi from Steven Spielberg, Taken, begins tonight and continues every weeknight for two weeks, two hours a night. That's 20 hours. I am not a superviewer! Uncle!