Computers: September 2003 Archives
I am a subscriber to DirecTV NFL Sunday Ticket, so I get lots of football every week. Because I have a TiVo, I also -- supposedly -- get highlights delivered to my TiVo every Monday. But so far, nothing.
They call me today and tell me I need to make sure I have channels 581 and 582 on the TiVo set as "Channels You Receive", because that is where the highlights get sent. This is probably something they should tell you when you sign up.
They call me today and tell me I need to make sure I have channels 581 and 582 on the TiVo set as "Channels You Receive", because that is where the highlights get sent. This is probably something they should tell you when you sign up.
John Gruber wrote a Select Word script for BBEdit. Here's a Mac::Glue version.
However, when you are taking a property of a property, you can't just do prop(foo => bar), because then Mac::Glue thinks foo is a class and bar is its value.
Suggestions on how to fix this syntax, as always, are welcome. :-)
Anyway, another little oddity -- not a big problem, but something to get used to -- is that where the AppleScript version says "last word whose ...", the Mac::Glue version more closely models what is actually happening, which is "last word of (words whose ...)".
Updating the above script to John's final version is an exercise left to the reader.
use Mac::Glue ':glue';This script is pretty straightforward, apart from the odd "property => of => property" syntax. It's my most hated thing about the Mac::Glue syntax. In obj(), you normally have key/value pairs for class/value. With prop(), it's the same, except that there is a property first (prop(foo) it is just a shortcut for obj(property => foo)).
$b = new Mac::Glue 'BBEdit';
$w = $b->obj(window => 1);
$o = $w->prop(offset => of => 'selection')->get;
$w->obj(word => gLast, words => whose(offset => l_e => $o))->select;
However, when you are taking a property of a property, you can't just do prop(foo => bar), because then Mac::Glue thinks foo is a class and bar is its value.
Suggestions on how to fix this syntax, as always, are welcome.
Anyway, another little oddity -- not a big problem, but something to get used to -- is that where the AppleScript version says "last word whose
Updating the above script to John's final version is an exercise left to the reader.
This wasted a significant amount of my time today:
I fixed by adding a label FOO: in front of the while loop, and putting a goto FOO below it. Good enough for me.
$SIG{CHLD} = sub { 1 };Now, one would think that the while loop should just merrily continue along from child to child, but instead -- apparently because of a problem in IO::Socket itself, resulting from the new safe signals in perl 5.8.0 -- the SIGCHLD is improperly interpreted as a SIGALRM and the while loop ends.
my $sock = new IO::Socket::INET (
LocalPort => 2305,
Type => SOCK_STREAM,
Proto => 'tcp',
Reuse => 1,
Listen => 10,
) or die "Could not start server: $!.\n";
while (my $child = $sock->accept) {
next if fork;
exit;
}
print "huh?";
I fixed by adding a label FOO: in front of the while loop, and putting a goto FOO below it. Good enough for me.
I noted previously that building perl on a dual G4/1.25 GHz / 1GB RAM was fast. Well, doing it on a dual G5/2.0 GHz / 2GB RAM is a lot faster. I set the processor peformance to "Highest" or whatever, from the default of automatic, because I am greedy. Building perl 5.8.0.
Configure -des, G4:
Mmmmm, speedilicious.
Configure -des, G4:
real 1m3.518sConfigure -des, G5:
user 0m19.540s
sys 0m38.910s
real 0m38.829smake -j3, G4:
user 0m15.650s
sys 0m20.830s
real 5m24.854smake -j3, G5:
user 5m11.600s
sys 1m17.350s
real 2m13.563smake -j3 test, G4:
user 3m29.540s
sys 0m48.700s
real 7m35.339smake -j3 test, G5:
user 3m18.180s
sys 1m2.870s
real 6m48.294sFrom beginning to end, the G4 did it all in 14:04. The G5 did it in 9:41. Taking away the tests, and it is more like 6:28 to 3:53.
user 4m9.670s
sys 0m36.290s
Mmmmm, speedilicious.
Riley, at not-yet-18-months-old, said "frell" for the first time. I am so proud.
And no, she didn't get it from me, or the TV. Thanks, mommy! :-)
And no, she didn't get it from me, or the TV. Thanks, mommy! :-)
#!/usr/local/bin/perlI stick this in ~/Library/Scripts and access it from the Script menu. Setting the number of rows makes the window taller, and setting the position puts the window in the top left (else it might end up anywhere on the screen).
use Mac::Glue;
my $term = new Mac::Glue 'Terminal';
$term->activate;
$term->do_script(wi th_command => 'top -u');
my $win = $term->obj(window => 1);
$win->prop('number_of_rows')->set(to => 50);
$win->prop('position')->set(to => [0, 25]);
Sure, I can just open a terminal window manually and type `top -u`, but that seems so silly when I can just do this!
Some years ago, Matthias Neeracher (MacPerl, GUSI, etc.) wrote a little client-server app for Mac OS called Cenotaph. The client ceno, written in perl, would act as an editor, except instead of opening the file for modification locally, it would open it and send its contents to the server, running Cenotaph (written in C++).
Cenotaph wrote out a temporary file and told BBEdit (or whatever your EDITOR was) to open it up. When you closed it, Cenotaph would send the file's new contents back to the client, which would save it (optionally with a backup).
Sure, there are a ton of ways to do this, but they usually involve the local machine to open a connection to the remote machine and find the file desired, whereas with this method, I can just edit the file I am looking at in the shell at the moment, without jumping through such hoops. Also, I edit files on machines that do not accept incoming connections, and this deals with that problem quite easily.
I have been wanting this on Mac OS X, so I finally ported the server to perl, and it works dandily. If you are interested, let me know here ... if anyone cares I'll put the source up once I finish cleaning it up.
[Heh, while I was trying to post this entry, it was failing because my user cookie in the cookies file was expired ... D'oh! Good thing I can modify the expire date by hand.]
Cenotaph wrote out a temporary file and told BBEdit (or whatever your EDITOR was) to open it up. When you closed it, Cenotaph would send the file's new contents back to the client, which would save it (optionally with a backup).
Sure, there are a ton of ways to do this, but they usually involve the local machine to open a connection to the remote machine and find the file desired, whereas with this method, I can just edit the file I am looking at in the shell at the moment, without jumping through such hoops. Also, I edit files on machines that do not accept incoming connections, and this deals with that problem quite easily.
I have been wanting this on Mac OS X, so I finally ported the server to perl, and it works dandily. If you are interested, let me know here ... if anyone cares I'll put the source up once I finish cleaning it up.
[Heh, while I was trying to post this entry, it was failing because my user cookie in the cookies file was expired ... D'oh! Good thing I can modify the expire date by hand.]
I've decided to use my Slashdot journal [ RSS ] for my political rantings. Update your RSS readers and friends lists ... now! ;-)
perl -MMac::Glue -e 'Mac::Glue->new("iTunes")->add(shift)->convert' mysong.aiffNote that add() adds the file and returns a reference to it, and then you call convert() on the song.
Now Playing: Phish - Trenchtown Rock (Bob Marley cover)
Do we really need email anymore? If we don't solve the spam problem soon, maybe killing email is the best solution. Most of the people I email, I can talk to on IRC/iChat/web discussions/RSS feeds/whatever.
About 5% of the email I get is NOT junk. Why bother anymore? I used to think of different ways to fix SMTP and the infrastructure, but maybe it's time to just stop using it. Remember when you thought you couldn't live without Usenet?
About 5% of the email I get is NOT junk. Why bother anymore? I used to think of different ways to fix SMTP and the infrastructure, but maybe it's time to just stop using it. Remember when you thought you couldn't live without Usenet?
John Gruber writes about the benefits of writing open source software, in the context of lack of participating in the porting of OpenOffice.org to the Mac.
I think John is overemphasizing the part about getting paid for work. A lot of people put a lot of free time into open source software (including me :-). But the problem is that people do NOT normally put a lot of free time into anything that does not give them direct benefit.
Whether it is serving in the Peace Corps, porting perl to the Mac, or working on Wall Street, people do things that satisfy some fairly direct desire or need. I desire to have certain tools on the Mac, and I get a good feeling from helping others, so I write open source tools for the Mac. Then there's Slash, which I use, and which helps others, but which doesn't help me or give me a good enough feeling that I would work on it much if I didn't get paid to.
But what benefit do I get from working on OO.org? Maybe it does help others, but mostly people who are willing to pay for software anyway (i.e., businesses). It's not something I will use myself much, if at all. I simply have no incentive, and I am not alone. The fact that few people are working on it is strong evidence that few developers feel they would benefit directly, significantly, from OO.org for the Mac.
Some might say there's a long-term incentive of saving the Mac platform from the closing of Office, which is going to kill off the Mac eventually. Even if I believed that, so what? If it's true, then the future of many companies are relying on it, and they will put out the money to get it done.
That's how this stuff works. If things really are needed, they will get done. If things aren't getting done, chances are they aren't really needed.
(BTW, the name of the program is not OpenOffice, it is OpenOffice.org. It's stupid, but there it is. )
I think John is overemphasizing the part about getting paid for work. A lot of people put a lot of free time into open source software (including me :-). But the problem is that people do NOT normally put a lot of free time into anything that does not give them direct benefit.
Whether it is serving in the Peace Corps, porting perl to the Mac, or working on Wall Street, people do things that satisfy some fairly direct desire or need. I desire to have certain tools on the Mac, and I get a good feeling from helping others, so I write open source tools for the Mac. Then there's Slash, which I use, and which helps others, but which doesn't help me or give me a good enough feeling that I would work on it much if I didn't get paid to.
But what benefit do I get from working on OO.org? Maybe it does help others, but mostly people who are willing to pay for software anyway (i.e., businesses). It's not something I will use myself much, if at all. I simply have no incentive, and I am not alone. The fact that few people are working on it is strong evidence that few developers feel they would benefit directly, significantly, from OO.org for the Mac.
Some might say there's a long-term incentive of saving the Mac platform from the closing of Office, which is going to kill off the Mac eventually. Even if I believed that, so what? If it's true, then the future of many companies are relying on it, and they will put out the money to get it done.
That's how this stuff works. If things really are needed, they will get done. If things aren't getting done, chances are they aren't really needed.
(BTW, the name of the program is not OpenOffice, it is OpenOffice.org. It's stupid, but there it is. )
Now Playing: Tears Of God - Los Lobos (Just Another Band East LA 1)
Mac-Glue-1.13 has been released. Download it from the CPAN or SF.net.
(Note: it may take time for the release to propagate to the various download mirrors.)
Changes:
(Note: it may take time for the release to propagate to the various download mirrors.)
Changes:
* v1.13, September 2, 2003Posted using release by brian d foy.
Removed Memoize. The speed gains were exceptionally modest, and some
bugs popped up resulting from adding it. It could be added back at
some point, but it would need to be done more carefully, and right
now the benefits don't justify the cost in time to get it done properly.
Cleanup/bug fixes for Mac::AETE::App in finding/opening applications
and fetching the application names.
Added a VERSION key to the glues (the version of the application),
and a version() method.
Added -c flag to gluemac to check to see if application version matches
the versions stored in the installed glues ($glue->version eq
$glue->{VERSION}).
Added -r flag to gluemac to re-create installed application glues
(with -c, only re-creates those with differing versions). It's
recommended that users run gluemac -r to update glues with new
VERSION key and fixed APPNAME key.
"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."
