In short, North American plugs are "shortable" because they don't NEED to be that safe. A short, sharp shock won't hurt you much.
Try repeating that little experience with an available conduction path across your chest. I don't think you'll agree that "110 volts really doesn't do much to you." The reason most shocks are not that big of a deal is that the path of conduction is usually just across a finger or hand, since the line and neutral conductors on the plug are right next to each other. However, if you should ever be so unlucky as to have one hand in contact with line voltage and the other at ground potential, you will create a nice path right across your chest and heart. It can take as little as 20-50 milliamps of current to interrupt normal heart function. This is the reason for the old saying "always keep one hand in your pocket" when fiddling with possible high voltages, to minimize the chances of completing a circuit through your torso.
Another thing that saves people is the fact that the resistance of the skin is usually quite high. However, if the area is especially sweaty, or if a puncture or penetrating wound is involved, the resistance can be much less. This greatly increases your chances of being hurt.
It looks like we'll see the winners when the conference occurs, Oct 4. There is a list of the names and languages used of the entries here. Here's my simple histogram of the popularity of languages:
162 total entries.
Java 24
C++ 17
C 15
Perl 10
Python 10
ocaml 6
Haskell 5
Common Lisp 4
Python 2.2 4
OCaml 3
Objective Caml 3
Mercury 2
Ocaml 2
Ocaml (3.04) 2
PLT Scheme 2
Ruby 2
Scheme 2
java 2
perl 2
ANSI-C 1
Ada 1
C++ (with boost) 1
C++ STL 1
C++, InteLib Lisp 1
C++/C 1
C, pure C 1
C, raw C 1
Cobol 4ever! (hehe, no... it's C, which I bet you don't think is much better) 1
Delphi (Object Pascal) 1
Delphi (Object Pascal), IDE Kylix 1
Dylan 1
Erlang 1
Forth 1
Gwydion Dylan 1
Haskell (with GHC extensions) 1
Haskell and C 1
Haskell with GHC extensions 1
Haskell, C 1
Haskell, C++ 1
Icon 1
Java (1.4.0) 1
Java 1.4 1
Mercury (with some C, see README) 1
Microsoft Visual C++ 1
O'Caml 1
OCaml 3 1
Objective-Caml 1
Prolog 1
Python, requires python 2 1
Python, with a bit of C 1
Python2.2 1
Rice PLT v202 1
Ruby, C 1
SML 1
Scheme (MzScheme 202) 1
Scheme (and a bit of C for an X11 interface) 1
Vanilla C (plus my personal toolbox) 1
Vanilla C (with my personal toolbox) 1
VisualAge Smalltalk 1
c++ 1
erlang 1
ocaml 3.06 1
pure python 1
python 1
(That was supposed to be a formatted table but the stupid lameness filter won't allow it.) I didn't bother to differentiate between e.g. "ocaml" and "ocaml 3.06" and "OCamel" in that list, but it's pretty clear that the most popular languages were Java, C, and C++... no surprise there.
And now I must include something to get past the slashdot lameness filter to compensate for all those spaces.
It appears that you have little experience working with Windows. If this is the case, then I suggest you start out with a simple file transform application. Read an encoded AVI, write the decoded AVI out in a RAW format. This will give you the ability to view the output of your codec in a media player without having to delve too much into COM objects and all the other Windows programming stuff.
If you really want to write a codec, you don't necessarily have to use the VFW calls. The audio and video codec management under VFW is old stuff, from the 16 bit Win 3.1 days. It's supported through wrappers in DirectX/DirectShow. What you might want to do instead is create a DirectShow filter, specifically a Transform Filter. If you are not familiar with the DirectShow architecture, you will want to read up on this first. Once you are familiar with the terminology (graphs, filters, pins, etc.) then write a transform filter. You can derive it from a base class supplied in the SDK and this will take care of making a DLL that knows how to register itself, etc. The section Writing Transform Filters has all the details in a step-by-step list, including build directions. This page is found through the path MSDN Home > MSDN Library > DirectX > DirectShow > Using DirectShow > Writing DirectShow Filters. From the linked page:
This section describes how to write a transform filter, defined as a filter that has exactly one input pin and one output pin. To illustrate the steps, this section describes a hypothetical transform filter that outputs run-length encoded (RLE) video. It does not describe the RLE-encoding algorithm itself, only the tasks that are specific to DirectShow.
There is an excellent web site called Dmitry's Design Lab that shows you how all the standard elements of design (color, shape, texture, etc.) apply to web sites. He is also one of the authors of the book HTML Unleashed, if you've ever read that. Personally I find it quite fascinating site because I'm usually up to speed on the technical details but when it comes to the actual concepts of design I start venturing away from my areas of knowledge. Anyway, the article on fonts is a great read. It goes over a lot of the history behind fonts, and explains some of the terminology.
I disagree. I think hundreds of people making up amateur fonts is exactly what we need. After a while, a few of these people will get really good at it, and then we'll have the latter half. Meanwhile, and more importantly, a font design sub-culture will have been established.
I think this is already the case. Go do a google search on "free fonts" or somesuch. There are plenty of sites that have hundreds of freeware or shareware fonts. The problem? Most of them are crap, and 99.9% of them are decorative. A lot of them would be great for making a graphic banner, flyer heading, etc. But I have seen very few of these that I would use for body layout of a serious document. Most of them are just way too foofy, and/or look like crap at less than 12 or 14 point. I didn't check but I don't think many of them (if any) were hinted, which is pretty essential for a screen font that's used as a primary typeface. And in the days of Windows 3.1 or 95, it was very common for some of these free fonts to lock up your computer if you actually tried to use them...I guess the file format wasn't in spec (or it didn't adhere to windows' quirks.) But it was a real joke, pull up the font list in an application and you'd get a freeze or BSOD when it tried to access the bad font.
And about Comic Sans: a couple of years ago I bought a book on techniques for using a scanner. The entire book (it was about a half inch thick) was laid out in Comic Sans. It was a self-published affair, originally based on the content of this guy's web site (which was also all Comic Sans.) I got used to it and didn't really mind that much, but I can understand how some people would get sick of looking at that typeface.
Its one of the few shows that I don't understand why it is NOT 'embraced' by slashdot, yet Buffy is.
How do you come to that conclusion? I get the impression that most slashbots are huge Futurama fans.
Oh, and in case there's any doubt as to whether CmdrTaco / jamie / the-slascode-team are fans, have a look at the http headers of this site some time...
I wonder if Declan would ever protect a source. Would he refuse a request from police? Would he refuse a subpoena? Would he go to prison to protect a source?
I doubt it. Why? Because he's a coward.
Uhh, he did refuse a subpoena when he was called to testify in the Jim Bell case a year ago or so. They wanted him to verify statements that Bell had made to him in his coverage of the story, but he refused because it would give too much leeway to potentially enter things into the record that were spoken to him in confidence. A direct quote:
"I talk to a lot of people who don't trust the government, and I don't want my sources to wonder who I'm working for -- Wired News or the government."
How 'boutcha get a clue before calling people cowards, mm'kay?
Somehow I think we'll be seeing those HTML 3.2 DTD's for quite some time to come, if the past is any indication of how fast real world stuff tracks the standards...
Slashdot Mirror
In short, North American plugs are "shortable" because they don't NEED to be that safe. A short, sharp shock won't hurt you much.
Try repeating that little experience with an available conduction path across your chest. I don't think you'll agree that "110 volts really doesn't do much to you." The reason most shocks are not that big of a deal is that the path of conduction is usually just across a finger or hand, since the line and neutral conductors on the plug are right next to each other. However, if you should ever be so unlucky as to have one hand in contact with line voltage and the other at ground potential, you will create a nice path right across your chest and heart. It can take as little as 20-50 milliamps of current to interrupt normal heart function. This is the reason for the old saying "always keep one hand in your pocket" when fiddling with possible high voltages, to minimize the chances of completing a circuit through your torso.
Another thing that saves people is the fact that the resistance of the skin is usually quite high. However, if the area is especially sweaty, or if a puncture or penetrating wound is involved, the resistance can be much less. This greatly increases your chances of being hurt.
Well, it came up in this thread about four months ago. It was suggested in the "Most Beautiful Experiments in Physics" story.
If you really want to write a codec, you don't necessarily have to use the VFW calls. The audio and video codec management under VFW is old stuff, from the 16 bit Win 3.1 days. It's supported through wrappers in DirectX/DirectShow. What you might want to do instead is create a DirectShow filter, specifically a Transform Filter. If you are not familiar with the DirectShow architecture, you will want to read up on this first. Once you are familiar with the terminology (graphs, filters, pins, etc.) then write a transform filter. You can derive it from a base class supplied in the SDK and this will take care of making a DLL that knows how to register itself, etc. The section Writing Transform Filters has all the details in a step-by-step list, including build directions. This page is found through the path MSDN Home > MSDN Library > DirectX > DirectShow > Using DirectShow > Writing DirectShow Filters. From the linked page:
There is an excellent web site called Dmitry's Design Lab that shows you how all the standard elements of design (color, shape, texture, etc.) apply to web sites. He is also one of the authors of the book HTML Unleashed, if you've ever read that. Personally I find it quite fascinating site because I'm usually up to speed on the technical details but when it comes to the actual concepts of design I start venturing away from my areas of knowledge. Anyway, the article on fonts is a great read. It goes over a lot of the history behind fonts, and explains some of the terminology.
I disagree. I think hundreds of people making up amateur fonts is exactly what we need. After a while, a few of these people will get really good at it, and then we'll have the latter half. Meanwhile, and more importantly, a font design sub-culture will have been established.
I think this is already the case. Go do a google search on "free fonts" or somesuch. There are plenty of sites that have hundreds of freeware or shareware fonts. The problem? Most of them are crap, and 99.9% of them are decorative. A lot of them would be great for making a graphic banner, flyer heading, etc. But I have seen very few of these that I would use for body layout of a serious document. Most of them are just way too foofy, and/or look like crap at less than 12 or 14 point. I didn't check but I don't think many of them (if any) were hinted, which is pretty essential for a screen font that's used as a primary typeface. And in the days of Windows 3.1 or 95, it was very common for some of these free fonts to lock up your computer if you actually tried to use them...I guess the file format wasn't in spec (or it didn't adhere to windows' quirks.) But it was a real joke, pull up the font list in an application and you'd get a freeze or BSOD when it tried to access the bad font.
And about Comic Sans: a couple of years ago I bought a book on techniques for using a scanner. The entire book (it was about a half inch thick) was laid out in Comic Sans. It was a self-published affair, originally based on the content of this guy's web site (which was also all Comic Sans.) I got used to it and didn't really mind that much, but I can understand how some people would get sick of looking at that typeface.
As for coverage, Tom devoted a whole page to it -- what more do you want?
...which amounts to, what, about three sentences worth of text these days?
"Click here for page 32 of 112"
Its one of the few shows that I don't understand why it is NOT 'embraced' by slashdot, yet Buffy is.
How do you come to that conclusion? I get the impression that most slashbots are huge Futurama fans.
Oh, and in case there's any doubt as to whether CmdrTaco / jamie / the-slascode-team are fans, have a look at the http headers of this site some time...
I doubt it. Why? Because he's a coward.
Uhh, he did refuse a subpoena when he was called to testify in the Jim Bell case a year ago or so. They wanted him to verify statements that Bell had made to him in his coverage of the story, but he refused because it would give too much leeway to potentially enter things into the record that were spoken to him in confidence. A direct quote:
How 'boutcha get a clue before calling people cowards, mm'kay?
Somehow I think we'll be seeing those HTML 3.2 DTD's for quite some time to come, if the past is any indication of how fast real world stuff tracks the standards...