Sure, I'll just... wait, modal dialog... I'll just send... damn, another modal dialog... send him an email... doh! modal dialog again... an email asking... hold on, another one... asking... damn, again... model dialog... modal dialog... LET ME... modal dialog... OUT OF... modal dialog... YOUR MODAL... modal dialog... INTERFACE!...
Another nice feature would be low power FM transmit so that you could easily use your portable player to feed into your car stereo.
The Neuros has this, and it works fairly well. Currently, it can only broadcast as low as 91.1, which may be a problem if you live in an area with crowded airwaves. I think the new version, due sometime this year, is supposed to be able to transmit at lower frequencies.
Oh, and it'll record off FM as well, as already posted.
The Neuros flat-out kicks ass. It's not the smallest device around, but it wins on everything else.
Shift is the modifier for "close current window behind me". So Shift-double-click and Shift-Alt-down open the selected folder and close the current window, and Shift-Alt-up opens the parent folder and closes the current window.
First, thank you for taking the time to make your program more accessible. Color-blindness is one of the most common accessibility issues, but it's very easy to overlook. Here's some suggestions:
* Don't rely on color alone. If you can provide indications other than color, and use color only as a supplement, it will make your program more accessible not only to color-blind people, but also to people with other visual impairments as well.
* Don't hard-code your colors. It requires very little programmer effort to store color values in a config file somewhere. This way, even if you screw up, users can still make the software usable for themselves.
* Actually check your colors. I don't know of any software to make your desktop run in a "color-blind mode" (though I'd love to see such software). But there are tools you can use to check screenshots and such. Vischeck is a great site that has software to simulate different types of color-blindness on images and web pages. You don't have to download anything. You can just upload an image to Vischeck, and it will transform it and give it back to you.
I'll be damned. You're right. I'm using Gnome 2.3 and Evolution 1.4. I just set gtk_key_theme to Emacs, and it didn't work. Not only did it not work in the composer area (which I believe is a gtkhtml3 widget), but it didn't work in the text fields either, which really surprised me. This seemed bug-worthy, so I searched. Here you go:
http://bugzilla.ximian.com/show_bug.cgi?id=41187
All GTK2 applications should be able to handle multibyte characters. I just tried writing an email with some mathematical symbols, and they seemed to display fine. Have you tried Evolution 1.4?
I don't know what sort of stuff different distros will have installed by default. However, Gnome in general seems to be coming along very nicely with accessibiity. It was even given a Hellen Keller award last year. You should check out the Gnome Accessibility Page and Gnopernicus.
A lot of technologies are thought up in sci-fi way before we ever get around to making them. I mean, they might be thought up wrong, but they're thought up. So I'm trying to figure out the earliest that this sort of idea appeared in sci-fi. A few people have mentioned the Matrix, but that's not exactly body-powered devices. The earliest I can think of is from a series called The Dungeon, edited by Farmer. And according to that, we should have all had a Baalbec A-9 last year. That's from 1988. Does anybody have anything earlier?
They didn't exactly hold this conference with the primary intention of showing these problems to slashdot. These are problems that (nearly) all mathematicians agree are important to solve. And there are plenty of good mathematicians who aren't the ones offering up the cash.
Anyway, what makes you so sure that "None of you could solve these things..."? Plenty of mathematicians read slashdot.
I have never heard of graphing calculators used in elementary schools. Yes, I certainly agree that students should learn how to do something before they can use their calculators. I'm a math student, and I pull out my TI-92 whenever I please, particularly when I have to do any calculus. It's not that I can't do it, it's just that I did all of that years ago, and I jolly well don't feel like doing heinous computations.
BTW, I might also mention that the way you stated math is taught is missing the final step. First, you learn the hard way. Then, you learn the shortcuts. That's where engineers and most scientists cut out. The mathematicians and some of the physicists stay on to learn the theory underneath it all, where calculators are often virtually useless.
Hence my preference for the TI-92. (Well, the keyboard and a lot of other things, like havind a CAS.) Does anybody know if there's anything similar to this for the 92?
Actually, in the GNOME software map (under Miscellaneous) there's a piece of software called Finder, which is just the Mac menu bar for GNOME. I've played with it before, and it seemed rather functional. Of course, not being a Mac user, I don't know how it shapes up to the Mac bar.
Linux has nfs support built in at the kernel level. I'm no expert, but I think the kernel-level support has more to do with the ability to mount nfs shares into the filesystem than exporting them. As for httpd, I'm fairly certain I read somewhere that the 2.4 kernel will have an experimental httpd daemon that runs as a kernel module and is only able to serve static pages.
Yes, technically the b does belong on the left. But a lot of people (including myself) type almost correctly. I usually hit the b and the 6 with whatever index finger is least busy, or something like that. Why not stick a b and a 6 on both sides? It's simply not worth the effort to correct myself when I already type 120 wpm.
I've used the Trackman at work for about a month now, and I couldn't be happier with it. I think the real key to a good trackball is that it's thumb-operated. It seems to me that finger-operated trackballs don't save you as much hand movement. Either way, though, trackballs will save strain on your arm and space on your desk. The only thing I ever use a regular mouse for anymore is Quake.
This is my last post on this topic, as the thread has strayed far enough off of the topic as it is. If you wish to carry it any further, you may email me.
Thank you for successfully proving my point. My intentions were merely to show how very little one can actually learn from the O'Reilly books. Though they are great sources for learning the basic syntactical structures of the language, there are far, far too many topics which they simply do not cover.
I can't be the first arrogant, obnoxious, stubborn little bastard you've run across. And I probably won't be the last. Actually, you strike me as rather the stubborn type. I mean, surely, you didn't learn everything you know simply from using other people's solutions. Re-inventing the wheel is the best way to understand it.
Nearly everything I know, I've learned from you. You've shown that that is insufficient. So tell me, where does one go from here?
And my interests aren't in chugging out code day after day. That's not very much fun. In fact, programming's not much fun and all if you don't learn something new every day. (Maybe that's just the mathematician in me.) So if I have a problem with my code, I learn from it. As for right now, I've just printed out the source of CGI.pm, and I intend to read it over the weekend.
You the programmer do not control the form. Actually, the web developers are about five feet away from me, so I know exactly what the forms look like. No, wait. Actually, most of my CGI scripts create the form themselves. I do control the form.
OK, a few of these are valid points. Most of them totally miss the point of what this snippet is.
You have a bug in your split.... This code is not all-purpose. It is about the simplest parsing I would put in the beginning of one program. If I know the form's going to hand me something funky, I'll handle it. Since I write the code for the form, I can do that.
Are you aware that the CGI spec from W3C deprecate the use of & and insists on semicolon? No, I didn't. I'll check into that. And I'm sure I can handle it.
Your code can only handle trivial forms... Yes, I know. As I said, this is a simple example of what I would put at the beginning of a program. This is not all-purpose. There's no reason to parse stuff that I know won't happen for a particular program.
You didn't test for whether you had a GET or a POST request. You'll notice that I read both the STDIN and QUERY_STRING. I put the STDIN (from a POST) into %{$form->[0]}, and the QUERY_STRING (from a GET) into %{$form->[1]}. This way, I have whatever came across either stored right there, and I can allow a particular script to take either REQUEST_METHOD, and act accordingly for each.
You have duplicate code. Yes, I know. I've written it before without duplicate code, using some fancy anonymous subroutines (I love those things), but I didn't feel like it for this example. This was a simple example.
You didn't guard against a denial-of-service attack through too much data... Again, a simple parser for a form I know will be simple. I'd write something better if I had something bigger.
You never declared any of your variables. My snippet isn't being used by anybody else. No, it is not use strict clean. But my programs don't use strict. I'm just way too fond of symbolic references.
Your use of magic number, 0 and 1, is confusing. Maybe to som. As I said, this isn't supposed to be used by anybody but me. Actually, I intentionally obfuscate my code sometimes to make sure the amateurs in the office don't screw with my code.
You have duplicate code. Why yes, I see the problem. Except that the performance loss won't be noticed when all of this has to be served through some schmuck's 56k dialup.
All in all, some very nice points. A few things I wasn't aware of. A few things I was. And so, now that the entire office has laughed at me for having my code picked apart by Tom Christiansen (OK, yes, I laughed at me too), I'll apologize for doubting you could do it. But I don't apologize for expecting you to impart that knowledge on the rest of us in your books. If there were some useful reference material out there, perhaps I would be doing it better.
For radio buttons, I wouldn't do anything different. (Why would I?) For select boxes that allow multiple selections, I'd know the key that it's coming in as, and push values into an array for that key.
As for file uploads, I'll be quite honest. I haven't taken the time to learn the hairy details of MIME yet (actually, I'm reading up on that right now), so I use cgi-lib.pl. But this isn't really CGI specifications. It's MIME.
I pretty much start everything from there, depending on what sort of HTML I want to cut out or put in. Of course, this would have to change if I had a select box that allowed multiple choices, or if I had a file upload or other multi-part form data. But since I write the snippet for the app, I know what the form is giving me. And I don't cut & paste. My indentation is wildly different, but every time I previewed on Slashdot, it stripped the 's out.
As I said, I write CGI programs all day long. That's how I make a living. And I've never had a problem with this.
And since you're advocating we not show poeple how to do something because it might be "complicated", do you suppose we ought just to close the source of Linux?
Slashdot Mirror
Sure, I'll just ... wait, modal dialog ... I'll just send ... damn, another modal dialog ... send him an email ... doh! modal dialog again ... an email asking ... hold on, another one ... asking ... damn, again ... model dialog ... modal dialog ... LET ME ... modal dialog ... OUT OF ... modal dialog ... YOUR MODAL ... modal dialog ... INTERFACE! ...
No thanks.
The Gnome project has absolutely nothing to do with this site or the prizes. The whole site was done by Eugenia and Co.
Another nice feature would be low power FM transmit so that you could easily use your portable player to feed into your car stereo.
The Neuros has this, and it works fairly well. Currently, it can only broadcast as low as 91.1, which may be a problem if you live in an area with crowded airwaves. I think the new version, due sometime this year, is supposed to be able to transmit at lower frequencies.
Oh, and it'll record off FM as well, as already posted.
The Neuros flat-out kicks ass. It's not the smallest device around, but it wins on everything else.
Shift is the modifier for "close current window behind me". So Shift-double-click and Shift-Alt-down open the selected folder and close the current window, and Shift-Alt-up opens the parent folder and closes the current window.
"to produce text" isn't a prepositional phrase. It's an infinitive clause.
First, thank you for taking the time to make your program more accessible. Color-blindness is one of the most common accessibility issues, but it's very easy to overlook. Here's some suggestions:
* Don't rely on color alone. If you can provide indications other than color, and use color only as a supplement, it will make your program more accessible not only to color-blind people, but also to people with other visual impairments as well.
* Don't hard-code your colors. It requires very little programmer effort to store color values in a config file somewhere. This way, even if you screw up, users can still make the software usable for themselves.
* Actually check your colors. I don't know of any software to make your desktop run in a "color-blind mode" (though I'd love to see such software). But there are tools you can use to check screenshots and such. Vischeck is a great site that has software to simulate different types of color-blindness on images and web pages. You don't have to download anything. You can just upload an image to Vischeck, and it will transform it and give it back to you.
I'll be damned. You're right. I'm using Gnome 2.3 and Evolution 1.4. I just set gtk_key_theme to Emacs, and it didn't work. Not only did it not work in the composer area (which I believe is a gtkhtml3 widget), but it didn't work in the text fields either, which really surprised me. This seemed bug-worthy, so I searched. Here you go: http://bugzilla.ximian.com/show_bug.cgi?id=41187
You can have Emacs-style keybindings in all of your GTK2 apps. Set the GConf key /desktop/gnome/interface/gtk_key_theme to Emacs.
All GTK2 applications should be able to handle multibyte characters. I just tried writing an email with some mathematical symbols, and they seemed to display fine. Have you tried Evolution 1.4?
I don't know what sort of stuff different distros will have installed by default. However, Gnome in general seems to be coming along very nicely with accessibiity. It was even given a Hellen Keller award last year. You should check out the Gnome Accessibility Page and Gnopernicus.
Who needs Jobi-Wan? We've got ESR.
A lot of technologies are thought up in sci-fi way before we ever get around to making them. I mean, they might be thought up wrong, but they're thought up. So I'm trying to figure out the earliest that this sort of idea appeared in sci-fi. A few people have mentioned the Matrix, but that's not exactly body-powered devices. The earliest I can think of is from a series called The Dungeon, edited by Farmer. And according to that, we should have all had a Baalbec A-9 last year. That's from 1988. Does anybody have anything earlier?
They didn't exactly hold this conference with the primary intention of showing these problems to slashdot. These are problems that (nearly) all mathematicians agree are important to solve. And there are plenty of good mathematicians who aren't the ones offering up the cash.
Anyway, what makes you so sure that "None of you could solve these things..."? Plenty of mathematicians read slashdot.
C:\DOS\CRASH>
I have never heard of graphing calculators used in elementary schools. Yes, I certainly agree that students should learn how to do something before they can use their calculators. I'm a math student, and I pull out my TI-92 whenever I please, particularly when I have to do any calculus. It's not that I can't do it, it's just that I did all of that years ago, and I jolly well don't feel like doing heinous computations.
BTW, I might also mention that the way you stated math is taught is missing the final step. First, you learn the hard way. Then, you learn the shortcuts. That's where engineers and most scientists cut out. The mathematicians and some of the physicists stay on to learn the theory underneath it all, where calculators are often virtually useless.
C:\DOS\CRASH>
Hence my preference for the TI-92. (Well, the keyboard and a lot of other things, like havind a CAS.) Does anybody know if there's anything similar to this for the 92?
C:\DOS\CRASH>
Actually, in the GNOME software map (under Miscellaneous) there's a piece of software called Finder, which is just the Mac menu bar for GNOME. I've played with it before, and it seemed rather functional. Of course, not being a Mac user, I don't know how it shapes up to the Mac bar.
C:\DOS\CRASH>
Linux has nfs support built in at the kernel level. I'm no expert, but I think the kernel-level support has more to do with the ability to mount nfs shares into the filesystem than exporting them. As for httpd, I'm fairly certain I read somewhere that the 2.4 kernel will have an experimental httpd daemon that runs as a kernel module and is only able to serve static pages.
C:\DOS\CRASH>
Yes, technically the b does belong on the left. But a lot of people (including myself) type almost correctly. I usually hit the b and the 6 with whatever index finger is least busy, or something like that. Why not stick a b and a 6 on both sides? It's simply not worth the effort to correct myself when I already type 120 wpm.
I've used the Trackman at work for about a month now, and I couldn't be happier with it. I think the real key to a good trackball is that it's thumb-operated. It seems to me that finger-operated trackballs don't save you as much hand movement. Either way, though, trackballs will save strain on your arm and space on your desk. The only thing I ever use a regular mouse for anymore is Quake.
This is my last post on this topic, as the thread has strayed far enough off of the topic as it is. If you wish to carry it any further, you may email me.
Thank you for successfully proving my point. My intentions were merely to show how very little one can actually learn from the O'Reilly books. Though they are great sources for learning the basic syntactical structures of the language, there are far, far too many topics which they simply do not cover.
I can't be the first arrogant, obnoxious, stubborn little bastard you've run across. And I probably won't be the last. Actually, you strike me as rather the stubborn type. I mean, surely, you didn't learn everything you know simply from using other people's solutions. Re-inventing the wheel is the best way to understand it.
Nearly everything I know, I've learned from you. You've shown that that is insufficient. So tell me, where does one go from here?
And my interests aren't in chugging out code day after day. That's not very much fun. In fact, programming's not much fun and all if you don't learn something new every day. (Maybe that's just the mathematician in me.) So if I have a problem with my code, I learn from it. As for right now, I've just printed out the source of CGI.pm, and I intend to read it over the weekend.
You the programmer do not control the form.
Actually, the web developers are about five feet away from me, so I know exactly what the forms look like. No, wait. Actually, most of my CGI scripts create the form themselves. I do control the form.
OK, a few of these are valid points. Most of them totally miss the point of what this snippet is.
You have a bug in your split....
This code is not all-purpose. It is about the simplest parsing I would put in the beginning of one program. If I know the form's going to hand me something funky, I'll handle it. Since I write the code for the form, I can do that.
Are you aware that the CGI spec from W3C deprecate the use of & and insists on semicolon?
No, I didn't. I'll check into that. And I'm sure I can handle it.
Your code can only handle trivial forms...
Yes, I know. As I said, this is a simple example of what I would put at the beginning of a program. This is not all-purpose. There's no reason to parse stuff that I know won't happen for a particular program.
You didn't test for whether you had a GET or a POST request.
You'll notice that I read both the STDIN and QUERY_STRING. I put the STDIN (from a POST) into %{$form->[0]}, and the QUERY_STRING (from a GET) into %{$form->[1]}. This way, I have whatever came across either stored right there, and I can allow a particular script to take either REQUEST_METHOD, and act accordingly for each.
You have duplicate code.
Yes, I know. I've written it before without duplicate code, using some fancy anonymous subroutines (I love those things), but I didn't feel like it for this example. This was a simple example.
You didn't guard against a denial-of-service attack through too much data...
Again, a simple parser for a form I know will be simple. I'd write something better if I had something bigger.
You never declared any of your variables.
My snippet isn't being used by anybody else. No, it is not use strict clean. But my programs don't use strict. I'm just way too fond of symbolic references.
Your use of magic number, 0 and 1, is confusing.
Maybe to som. As I said, this isn't supposed to be used by anybody but me. Actually, I intentionally obfuscate my code sometimes to make sure the amateurs in the office don't screw with my code.
You have duplicate code.
Why yes, I see the problem. Except that the performance loss won't be noticed when all of this has to be served through some schmuck's 56k dialup.
All in all, some very nice points. A few things I wasn't aware of. A few things I was. And so, now that the entire office has laughed at me for having my code picked apart by Tom Christiansen (OK, yes, I laughed at me too), I'll apologize for doubting you could do it. But I don't apologize for expecting you to impart that knowledge on the rest of us in your books. If there were some useful reference material out there, perhaps I would be doing it better.
For radio buttons, I wouldn't do anything different. (Why would I?) For select boxes that allow multiple selections, I'd know the key that it's coming in as, and push values into an array for that key.
As for file uploads, I'll be quite honest. I haven't taken the time to learn the hairy details of MIME yet (actually, I'm reading up on that right now), so I use cgi-lib.pl. But this isn't really CGI specifications. It's MIME.
read(STDIN, $bfr, $ENV{'CONTENT_LENGTH'}); /; /;
foreach (split(/&/,$bfr)) {
$kv = [split(/=/,$_)];
foreach (0...1) {
$kv->[$_] =~ tr/+/
$kv->[$_] =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg;
}
$form->[0]{$kv->[0]} = $kv->[1];
}
foreach (split(/&/,$ENV{'QUERY_STRING'}) {
$kv = [split(/=/,$_)];
foreach (0...1) {
$kv->[$_] =~ tr/+/
$kv->[$_] =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg;
}
$form->[1]{$kv->[0]} = $kv->[1];
}
I pretty much start everything from there, depending on what sort of HTML I want to cut out or put in. Of course, this would have to change if I had a select box that allowed multiple choices, or if I had a file upload or other multi-part form data. But since I write the snippet for the app, I know what the form is giving me. And I don't cut & paste. My indentation is wildly different, but every time I previewed on Slashdot, it stripped the 's out.
As I said, I write CGI programs all day long. That's how I make a living. And I've never had a problem with this.
And since you're advocating we not show poeple how to do something because it might be "complicated", do you suppose we ought just to close the source of Linux?