CAUCE is the Coalition Against Unsolicited Commercial Email. A few years ago, when they just formed, they recommended using devnull@cauce.org as a "black hole" address that would not result in superfluous bounces. I've been using it ever since in USENET postings.
A while back it was a common task for CS instructors to assign students to make their own HTML rendering engine. I wrote one myself just to see if it could be done. Not a beginner task, but still something well within the capabilities of any recent CS college graduate (if they actually taught you anything).
I never tried to write an HTML rendering engine, but I'd imagine that the hard part would be to write the "quirks mode" rendering that is necessary to display the countless millions of invalid HTML pages on the web. I don't think that would be part of the CS instructors assignment.
So to to use examples that are a little more realistic -
In Perl ($a == 5) becomes ((int)$a == 5) in PHP.
And ($s eq 'name') becomes ((string)$s == 'name').
After brooding over this a little longer, I think it should actuallly be this:
In Perl ($a == 5) becomes ((int)$a === 5) in PHP.
In Perl ($s eq 'name') becomes ((string) $a === 'name').
The typecasting would make no difference to the 'loose' == operator, but it does make a difference to the 'strict' === operator.
With perl you can still do 3 == "3" to do a numerical comparison, or 3 eq "3" to do a string comparison. In PHP, 3 == "3" would always match, not matter which comparison it decided to use, and 3 === "3" would never match because they're not the same type.
You're right. But you can get the same behaviour out of PHP with a little more verbosity: Perl's 3 == "3" (numerical comparison) would be 3 == (int) "3" in PHP (cast string "3" to integer before comparing); Perl's 3 eq "3" (string comparison) would be (string) 3 == "3" (cast integer 3 to string "3" before comparing).
can't see why you think PHP's all-associative arrays are so great. To me it sounds like another attempt to simplify without thinking of the consequences and instead making the result complex and ambiguous. What happens when you mix up normal indexed array operations (e.g $a[1] = 20) with associative operations (e.g $a['george'] = 5) ?
$a[1] = 20; $a['george'] = 5; print_r($a);
This is what happens:
Array ( [1] => 20 [george] => 5 )
Just as you would expect. Not complex or ambiguous, in my opinion.
A prime example is the way that Perl has seperate numrical and string comparitors (==/!= and eq/ne) whereas PHP has only the one (==). This recently came up in the story about the Perl periodic table of elements and I even gave my own answer on this problem. Just to rehash: Perl and PHP are loosely-typed languages so the programmer really needs to tell the interpreter how to compare the mixed numerical/string "scalar" type that both Perl and PHP use. But PHP tries to simplify at the expense of introducing ambiguity.
PHP has == and != for simple comparison, and === and !== for enforcing that the comparants (is that a word?) are also of the same type.
But since everything is open source, it should be possible to apply any OpenBSD security patches to 1.3.31 or later, and offer that one (in ports/packages) as 1.3.31 (+ patches), right?
I don't think this will be a real problem. If Apache is no longer allowed in the OpenBSD base system it can simply be moved to ports/packages, and it will be just a pkg_add away - just as is now the case with Apache 2.0.
Kind of reminds me of back when I still played the piano. Then, I would practice a piece so much that, after a while, I found it easiest to play with my eyes closed and let my mind just cruise along. The bad thing was, that if something startled or interupted me, I often couldn't remember where in the song I was.
Something similar happened to me when I was distracted by something when I was about to type in my PIN code to pay in the supermarket. Suddenly I couldn't remember my PIN anymore (that is to say, I still knew what the digits were and what the main pattern was, but I forgot which digit went where). And I had been using that PIN for something like ten years. A very strange experience.
Of course, it could also be asked why should the authors participate in this process if they don't make any profits?
Generally, academic writers don't make any profit. Their reward is the recognition of being published by a big-name scientific publishing house. The only one who makes a monetary profit is the publisher.
However, before that, all I had was an old 21" 4:3 tube that had never heard of NTSC. Yet I could easily play R1/NTSC DVDs - without conversions.
How? Component signal format. The TV also accepted RGB (In the US, YPbPr is more common). PAL and NTSC color codings are both ways to transmit color information. If I use RGB, the information is in "raw" format that the TV understands anyway.
Thank you very much. I was convinced that I could watch NTSC DVD's only in black and white on my TV. I was even contemplating buying a new TV. I switched the DVD output to RGB, as you advised, and my NTSC DVD's now play in glorious colour. Thanks again!
And kut is Dutch for cunt. And it jumps out even more because the syllable "kut" is stressed in the word Orkut.
JP
Re:Apple is not unique in this problem.
on
iPod Mini Design Flaw?
·
· Score: 2, Informative
My first-generation 10GB iPod also doesn't have this problem. However, the headphone connection of the Apple remote control I bought for it later does.
and for which I can't recall the name for the life of me... It was a Mac program, and had a logo of a sort of mythology figure with a muscular arm bent upward... GRAH!
For those who still bravely (foolishly) venture onto usenet, it would be nice to replace kill files with something Bayesian. There may be such a reader already but I haven't seen it (nevermind something cross-platform, which is a must for me).
There is one newsreader I know of which uses Bayesian filtering for articles in its latest version, but it's Mac only: MT-NewsWatcher.
Span's are not needed when the correct tags are used.
This assumes that there are correct tags for everything in HTML, but I don't think that's true. For example: a typographical convention that is used sometimes is to use italic for pieces of text in a foreign language. Which HTML tag should that be? Not <em>. <span class="foreign_language"> or something like that seems the only way, if you don't want to use <i>.
Unfortunately, we moved into the days of 'huge annoying animated advertisement that cannot be skipped' (unless by disabling the Flash plugin). Not really an improvement in my opinion.
JP
Re:Why are highly rated comments always sarcastic?
on
Junkie Loves His Spam
·
· Score: 1
That said, my first reaction, is one I always have: why when an interesting topic comes up: why do I find only sarcastic/hopefully humorous comments get through my level 4 filter? Still waiting for an answer on that.
I don't have an answer for you, but I can tell you this: since I score all 'Funny' mods at -6, reading Slashdot has become much more enjoyable.
I had the same problem with my handwriting being illegible, a couple of years ago. I felt that just trying to write slower wasn't the solution. I did something more radical: I switched handwriting styles. I found a great little book called Naar beter handschrift ("To better handwriting") from 1956. This book teaches you to write in a script that is closely based on 14th-century Italian writing, the so-called "Humanistic cursive". (See here for an example of original humanistic cursive.)
Unlike our modern cursive handwriting, where you are supposed to write all the letter connected to each other (there is some kind of law "thou shalt not take the pen off the paper while writing", which is good for speed but not for legibility), you only connect letters when it makes sense in the humanistic cursive, and you are allowed to take the pen off the paper to draw better shapes for your letters. Example: the lower case r in modern cursive (at least the way that I learned it, in The Netherlands) is rather ugly, it's essentially an r written backwards (so that you won't have to take the pen off the paper while writing it). In the humanistic cursive, the lower case r looks much like a lower case printing letter r because you don't have to forcibly connect it to other letters. And it's much more readable that way.
Slashdot Mirror
CAUCE is the Coalition Against Unsolicited Commercial Email. A few years ago, when they just formed, they recommended using devnull@cauce.org as a "black hole" address that would not result in superfluous bounces. I've been using it ever since in USENET postings.
JP
A while back it was a common task for CS instructors to assign students to make their own HTML rendering engine. I wrote one myself just to see if it could be done. Not a beginner task, but still something well within the capabilities of any recent CS college graduate (if they actually taught you anything).
I never tried to write an HTML rendering engine, but I'd imagine that the hard part would be to write the "quirks mode" rendering that is necessary to display the countless millions of invalid HTML pages on the web. I don't think that would be part of the CS instructors assignment.
JP
So to to use examples that are a little more realistic -
In Perl ($a == 5) becomes ((int)$a == 5) in PHP.
And ($s eq 'name') becomes ((string)$s == 'name').
After brooding over this a little longer, I think it should actuallly be this:
In Perl ($a == 5) becomes ((int)$a === 5) in PHP.
In Perl ($s eq 'name') becomes ((string) $a === 'name').
The typecasting would make no difference to the 'loose' == operator, but it does make a difference to the 'strict' === operator.
JP
With perl you can still do 3 == "3" to do a numerical comparison, or 3 eq "3" to do a string comparison. In PHP, 3 == "3" would always match, not matter which comparison it decided to use, and 3 === "3" would never match because they're not the same type.
You're right. But you can get the same behaviour out of PHP with a little more verbosity: Perl's 3 == "3" (numerical comparison) would be 3 == (int) "3" in PHP (cast string "3" to integer before comparing); Perl's 3 eq "3" (string comparison) would be (string) 3 == "3" (cast integer 3 to string "3" before comparing).
JP
can't see why you think PHP's all-associative arrays are so great. To me it sounds like another attempt to simplify without thinking of the consequences and instead making the result complex and ambiguous. What happens when you mix up normal indexed array operations (e.g $a[1] = 20) with associative operations (e.g $a['george'] = 5) ?
This is what happens:
Just as you would expect. Not complex or ambiguous, in my opinion.
JP
A prime example is the way that Perl has seperate numrical and string comparitors (==/!= and eq/ne) whereas PHP has only the one (==). This recently came up in the story about the Perl periodic table of elements and I even gave my own answer on this problem. Just to rehash: Perl and PHP are loosely-typed languages so the programmer really needs to tell the interpreter how to compare the mixed numerical/string "scalar" type that both Perl and PHP use. But PHP tries to simplify at the expense of introducing ambiguity.
PHP has == and != for simple comparison, and === and !== for enforcing that the comparants (is that a word?) are also of the same type.
See http://nl3.php.net/manual/en/language.operators.co mparison.php.
JP
But since everything is open source, it should be possible to apply any OpenBSD security patches to 1.3.31 or later, and offer that one (in ports/packages) as 1.3.31 (+ patches), right?
JP
I don't think this will be a real problem. If Apache is no longer allowed in the OpenBSD base system it can simply be moved to ports/packages, and it will be just a pkg_add away - just as is now the case with Apache 2.0.
JP
I think the general consesus was that this won't do a thing to help stop counterfitting.
Not too surprising, since the general consensus on /. seems to be that nothing will ever do a thing to stop anything.
JP
Kind of reminds me of back when I still played the piano. Then, I would practice a piece so much that, after a while, I found it easiest to play with my eyes closed and let my mind just cruise along. The bad thing was, that if something startled or interupted me, I often couldn't remember where in the song I was.
Something similar happened to me when I was distracted by something when I was about to type in my PIN code to pay in the supermarket. Suddenly I couldn't remember my PIN anymore (that is to say, I still knew what the digits were and what the main pattern was, but I forgot which digit went where). And I had been using that PIN for something like ten years. A very strange experience.
JP
ssh/sftp clients for Classic Mac OS:
MacSSH and MacSFTP.
JP
Of course, it could also be asked why should the authors participate in this process if they don't make any profits?
Generally, academic writers don't make any profit. Their reward is the recognition of being published by a big-name scientific publishing house. The only one who makes a monetary profit is the publisher.
JP
However, before that, all I had was an old 21" 4:3 tube that had never heard of NTSC. Yet I could easily play R1/NTSC DVDs - without conversions. How? Component signal format. The TV also accepted RGB (In the US, YPbPr is more common). PAL and NTSC color codings are both ways to transmit color information. If I use RGB, the information is in "raw" format that the TV understands anyway.
Thank you very much. I was convinced that I could watch NTSC DVD's only in black and white on my TV. I was even contemplating buying a new TV. I switched the DVD output to RGB, as you advised, and my NTSC DVD's now play in glorious colour. Thanks again!
JP
Maybe he means that it should be $array['key'] (quoted key) instead of $array[key] (unquoted key)?
JP
Oops, sorry. I just realized I was mistaken about which syllable is stressed. The "Or" is actually stressed.
JP
And kut is Dutch for cunt. And it jumps out even more because the syllable "kut" is stressed in the word Orkut.
JP
My first-generation 10GB iPod also doesn't have this problem. However, the headphone connection of the Apple remote control I bought for it later does.
JP
and for which I can't recall the name for the life of me... It was a Mac program, and had a logo of a sort of mythology figure with a muscular arm bent upward... GRAH!
Wasn't that Nisus Writer?
I preferred WriteNow myself, back in the day.
JP
FAQ: Styling using the lang attribute
Very interesting! Thanks for the link.
JP
For those who still bravely (foolishly) venture onto usenet, it would be nice to replace kill files with something Bayesian. There may be such a reader already but I haven't seen it (nevermind something cross-platform, which is a must for me).
There is one newsreader I know of which uses Bayesian filtering for articles in its latest version, but it's Mac only: MT-NewsWatcher.
JP
Span's are not needed when the correct tags are used.
This assumes that there are correct tags for everything in HTML, but I don't think that's true. For example: a typographical convention that is used sometimes is to use italic for pieces of text in a foreign language. Which HTML tag should that be? Not <em>. <span class="foreign_language"> or something like that seems the only way, if you don't want to use <i>.
JP
We've moved on from the days of 'skip intro.'
Unfortunately, we moved into the days of 'huge annoying animated advertisement that cannot be skipped' (unless by disabling the Flash plugin). Not really an improvement in my opinion.
JP
That said, my first reaction, is one I always have: why when an interesting topic comes up: why do I find only sarcastic/hopefully humorous comments get through my level 4 filter? Still waiting for an answer on that.
I don't have an answer for you, but I can tell you this: since I score all 'Funny' mods at -6, reading Slashdot has become much more enjoyable.
JP
Honestly, I wouldn't want to run a site like Slashdot on MySQL, but for smaller projects it seems useful.
Slashdot runs on MySQL.
See InnoDB: User Stories, second item on the page.JP
I had the same problem with my handwriting being illegible, a couple of years ago. I felt that just trying to write slower wasn't the solution. I did something more radical: I switched handwriting styles. I found a great little book called Naar beter handschrift ("To better handwriting") from 1956. This book teaches you to write in a script that is closely based on 14th-century Italian writing, the so-called "Humanistic cursive". (See here for an example of original humanistic cursive.)
Unlike our modern cursive handwriting, where you are supposed to write all the letter connected to each other (there is some kind of law "thou shalt not take the pen off the paper while writing", which is good for speed but not for legibility), you only connect letters when it makes sense in the humanistic cursive, and you are allowed to take the pen off the paper to draw better shapes for your letters. Example: the lower case r in modern cursive (at least the way that I learned it, in The Netherlands) is rather ugly, it's essentially an r written backwards (so that you won't have to take the pen off the paper while writing it). In the humanistic cursive, the lower case r looks much like a lower case printing letter r because you don't have to forcibly connect it to other letters. And it's much more readable that way.
JP