Computers: August 2001 Archives
When last we left, I was concerned about error reporting in MacPerl. I still thought and think that MPW formatting should be the default, but what about all those broken tests? What if someone wants Unix-style errors?
So I wrote a function to allow specifying the behavior. MacPerl::ErrorFormat lets you choose the format style, with a 0 for Unix or 1 for MPW. Default is 1. Sounds reasonable. And you can optionally call a pragma (for now called "mpwerr"), like so:
I think I might change the name to MacPerl::err or something.
Syntax checks for now will *always* have a "#" in front of them, no matter what happens with ErrorFormat.
I might not get the release out tonight. Oh well, who would mess with it this weekend anyway? :-)
So I wrote a function to allow specifying the behavior. MacPerl::ErrorFormat lets you choose the format style, with a 0 for Unix or 1 for MPW. Default is 1. Sounds reasonable. And you can optionally call a pragma (for now called "mpwerr"), like so:
perl -Mmpwerr=unix -e 'die "foo"'and you get Unix-style errors. The pragma has kindof a weird problem though; I wanted people to be able to call it on the command line as above. The problem is the command line is called before xs_init(), which is where the MacPerl package is loaded in and bootstrapped. Nuts. So we put off execution until CHECK, which seems to work fine, but it means the pragma can only be called once, which I think is fine. If you want to go back and forth in your program, use the function itself instead of the pragma.
I think I might change the name to MacPerl::err or something.
Syntax checks for now will *always* have a "#" in front of them, no matter what happens with ErrorFormat.
I might not get the release out tonight. Oh well, who would mess with it this weekend anyway?
Thanks to Thomas Wegner, a lot more is working now in MacPerl 5.6.1. File::Temp is happy, even File::DosGlob, and File::Spec::Mac is happier.
File::Spec::Mac still has some work left in it, which I am going to mail p5p about.
So currently, all tests pass on MacPerl, except: tests that require fork; some known breakage in sprintf with our version of sfio; system() not returning a usable value; and sysopen not giving a warning on writes to a readonly file.
Except that now Matthias has ressurrected old MacPerl behavior, in part, of formatting error messages, so that on writes to a socket (Apple event, filehandle, whatever) a message is formatted to look like an MPW-style error message. This causes significant problems for about five different tests. Yay. I am not sure what to do about it. I am thinking that I might want to make some sort of switch or global or pragma for disabling the MPW formatting.
For now, I am just running the tests with the formatting off; that way, at least I can verify the tests do pass.
There are two camps that want the MPW formatting: MPW users :-) and BBEdit users. The problem of BBEdit is not one of Bare Bones code; they already have code to parse Unix perl error messages, as they use it in Mac OS X. But there are a lot of users out there using old versions of BBEdit, so they can't retrofit very easily.
Just a late-night random thought: perhaps they could come up with a patch to old versions of BBEdit for MacPerl support? It would basically check the MacPerl version, and use a different parsing code for 5.6.1 and greater. We could even distribute links to the updaters with MacPerl.
File::Spec::Mac still has some work left in it, which I am going to mail p5p about.
So currently, all tests pass on MacPerl, except: tests that require fork; some known breakage in sprintf with our version of sfio; system() not returning a usable value; and sysopen not giving a warning on writes to a readonly file.
Except that now Matthias has ressurrected old MacPerl behavior, in part, of formatting error messages, so that on writes to a socket (Apple event, filehandle, whatever) a message is formatted to look like an MPW-style error message. This causes significant problems for about five different tests. Yay. I am not sure what to do about it. I am thinking that I might want to make some sort of switch or global or pragma for disabling the MPW formatting.
For now, I am just running the tests with the formatting off; that way, at least I can verify the tests do pass.
There are two camps that want the MPW formatting: MPW users :-) and BBEdit users. The problem of BBEdit is not one of Bare Bones code; they already have code to parse Unix perl error messages, as they use it in Mac OS X. But there are a lot of users out there using old versions of BBEdit, so they can't retrofit very easily.
Just a late-night random thought: perhaps they could come up with a patch to old versions of BBEdit for MacPerl support? It would basically check the MacPerl version, and use a different parsing code for 5.6.1 and greater. We could even distribute links to the updaters with MacPerl.
In Slash 2, we changed the "rootdir" variable from "http://slashdot.org" to "//slashdot.org". This variable is appended to the front of links on the site. We still wanted to have the hostname in the paths, and we also wanted to have it work with HTTPS (we have plans to perhaps allow some access to Slashdot over HTTPS; this syntax provides for URIs relative to the protocol).
Yes, we could eschew having the hostname, so rootdir could just be "". Or we could forgo HTTPS, and use the "http://slashdot.org". But we wanted it this way, because it gives us everything we want.
So what's the problem? A lot of people don't realize this syntax is perfectly legal under RFC 2396 (see Appendix C.1). Or they just don't care if it is legal, but just get mad because on some clients it is broken. Well, in most clients it works (Netscape, Mozilla, IE, Opera, iCab, lynx, links, Konqueror [2.0 and up]; one is pressed to think of those that don't work, but there are some). For those that don't, those clients are *broken*.
So we get (som of them nasty) messages from people about how this is a bug in Slash and how we shouldn't use malformed URLs. It isn't, and we're not. Your client is broken. Fix it. Someone said w3m doesn't handle the links properly. I wouldn't know; I couldn't get it to compile on Red Hat last I tried. :-/
We could change to a different link syntax so it works on all clients. But again, we want it this way. And further, Slashdot is a very popular site, and hopefully clients will be forced to be compliant because of that.
If not, well, sucks to be them. :-)
Yes, we could eschew having the hostname, so rootdir could just be "". Or we could forgo HTTPS, and use the "http://slashdot.org". But we wanted it this way, because it gives us everything we want.
So what's the problem? A lot of people don't realize this syntax is perfectly legal under RFC 2396 (see Appendix C.1). Or they just don't care if it is legal, but just get mad because on some clients it is broken. Well, in most clients it works (Netscape, Mozilla, IE, Opera, iCab, lynx, links, Konqueror [2.0 and up]; one is pressed to think of those that don't work, but there are some). For those that don't, those clients are *broken*.
So we get (som of them nasty) messages from people about how this is a bug in Slash and how we shouldn't use malformed URLs. It isn't, and we're not. Your client is broken. Fix it. Someone said w3m doesn't handle the links properly. I wouldn't know; I couldn't get it to compile on Red Hat last I tried. :-/
We could change to a different link syntax so it works on all clients. But again, we want it this way. And further, Slashdot is a very popular site, and hopefully clients will be forced to be compliant because of that.
If not, well, sucks to be them. :-)
Matthias (Murr) found another bug in xsubpp (a change in behavior since he last worked on it) that broke some of his changes to it, and changed xsubpp accordingly. I did a test build today, and ran some tests.
Mac::Windows worked. Good so far, so I move along. Mac::OSA works. Mac::Components works. Mac::Processes crashes (well, the app quits). OK, keep going. Mac::AppleEvents works. Mac::Glue breaks. Hrm.
Some prototype errors, fix the code. Can't open files. Hrm. Rebuild the glues with the new DB_File. Aha! Mac::Glue works! Except for when it needs to launch an app with Mac::Processes.
So now the big test: Chaser. Kevin Reid's game. Fails. Hrm. Two prototype warnings, I will ignore. Can't open a file. "@{[cwd()]}:Chaser Resources". cwd() now returns paths with trailing ":". Remove the ":". It works! YAY!
Thanks, Murr.
I am still on vacation from MacPerl, but I will aim to get another alpha out within a week and a half, with a beta following perhaps a few weeks later. Still a few things left before beta.
Still waiting on MindVision for an installer license. :-/
Mac::Windows worked. Good so far, so I move along. Mac::OSA works. Mac::Components works. Mac::Processes crashes (well, the app quits). OK, keep going. Mac::AppleEvents works. Mac::Glue breaks. Hrm.
Some prototype errors, fix the code. Can't open files. Hrm. Rebuild the glues with the new DB_File. Aha! Mac::Glue works! Except for when it needs to launch an app with Mac::Processes.
So now the big test: Chaser. Kevin Reid's game. Fails. Hrm. Two prototype warnings, I will ignore. Can't open a file. "@{[cwd()]}:Chaser Resources". cwd() now returns paths with trailing ":". Remove the ":". It works! YAY!
Thanks, Murr.
I am still on vacation from MacPerl, but I will aim to get another alpha out within a week and a half, with a beta following perhaps a few weeks later. Still a few things left before beta.
Still waiting on MindVision for an installer license. :-/
I finished up a site redesign of the MacPerl dev site today, while watching the Red Sox third straight win over the Rangers (assuming they don't choke the game away in the ninth).
I am working at 6:30 on a Friday. TPJ article is in, Slashdot beta is live, and I am coding away.
I just used "&&=" for the first time in real code. I hadn't planned on it, but there it was.
my($cfg1, $cfg2, $VirtualUser) = @_;
$VirtualUser &&= getCurrentVirtualUser();