1) It's Japanese on the panic message, not Chinese
2) When written, you just call it Chinese and not Mandarin Chinese; the distinctions "Mandarin" and "Cantonese" are primarily for spoken language, as the written languages are very nearly identical
3) I fail to see how it could be incomprehensible, seeing as it is pretty much obvious that there are different languages on the panic screen, and that it is giving you very clear instructions on what to do next: see one for yourself
Besides, Windows XP (and likely Vista too) ship in a default configuration where they do not show BSODs (at least, that was the way it was set up on my system, a consumer-level laptop). This means that all the user gets to see is the system *instantly restarting*, without any sort of warning whatsoever. It also means that they won't see a BSOD, but will be informed after startup that their system "recovered from a serious error" or something like that.
One argument for the OS X panic message is that it doesn't replace the entire screen, meaning that whatever you may have been working on is still potentially recoverable. With a full-screen BSOD, where technical details essentially fill the screen, this doesn't happen.
Yes, on OS X, you would use the NSPasteBoard class to interact with the system-wide clipboard. The only thing stopping Apple from implementing NSPasteBoard in the iPhone SDK appears to be the question of how to implement it best in the UI. The system of NSPasteBoard filters handles all the gritty details of converting data between different formats; a given pasteboard can hold data in a specific format (or even multiple formats at once), and the client can invoke a filter to read the data from the PB using any applicable filters. Honestly, everything is in place API-wise, it seems that Apple simply wants to work out the UI (there is, in fact, more than one way to do it, but it seems they are dragging their heels with this important feature!)
If you want to find out if you are blocked, try Special:Mytalk. This page will redirect to the talk page for whatever IP address you appear to be connecting from. If that page happens to have a message like this one on it, then you are being transparently routed by your ISP, and they are probably not sending X-Forwarded-For like they should.
This probably doesn't work for all values, but breaking ties by choosing the square farthest from the center substantially increases the effective range of the algorithm. I haven't yet found out how far it goes, but it seems to hold up all the way to 450x450.
TFA has basically stumbled upon Warnsdorff's algorithm. It's a great method, but it doesn't work for really large boards due to blind alleys. There's another method available which uses decomposition to achieve a linear running time(in # of squares), but which is quite a bit more complex to implement. There's a nice tweak to the algorithm which can get much farther than the unmodified original: in the event of a tie (where two candidates have the same number of open neighbours), break the tie by choosing the square farthest from the center. This substantially extends the maximum size of the board (to what, I don't know, because it's worked for everything up to around 450x450, which is past what was described by Arnd Roth).
Better yet, replace the whole thing with a generator expression wrapped in sum, thus removing map and the temporary array:
key=lambda c:sum((int(InRangeAndEmpty(c[0]+j[0], c[1]+j[1])) for j in jumps))
int(bool) turns True into 1 and False into 0, and is more readable than "and 1 or 0" (better yet, use the Python 2.5 conditional "1 if InRangeAndEmpty(...) else 0").
I rewrote the code using a stack, to see how far it could get. It does 162x162 in linear time (w.r.t. the number of squares) and then, at 163x163, it abruptly stops being fast, as it begins to perform heavy backtracking -- it fails to fill in a region near the top-right corner. Hence, the heuristic (as written) is not powerful enough for all grids.
Firefox+NoScript. Then mark Google Analytics as untrusted to avoid it from telling you it blocked GA. Same thing works for DoubleClick and other advertising/tracking sites.
Alternatively, you could add an/etc/hosts file to redirect GA somewhere harmless.
The tests were not carried out on the very newest software, which puts Firefox and Safari in particular at a significant disadvantage.
Firefox introduced TraceMonkey to 3.1, and beta builds of it are available. In pure JS testing, they completely destroy 3.0.4 in terms of speed. Safari introduced SquirrelFish, and then SquirrelFish Extreme which added JIT capability to Safari's JavaScript interpreter. It is available in the nightly WebKit builds. Furthermore, with Acid3, WebKit nightlies pass Acid3 with 100% and Firefox nightlies get around 93%. Chrome nightlies, having merged newer WebKit code, get 100% as well. A few months ago, I ran a test using the then-current nightlies, which I posted on my blog. One particularly good test site is Dromaeo, which TFA failed to mention. Dromaeo tests not only JavaScript, but JavaScript and DOM interaction, making it a good candidate for testing the performance of a real-world situation.
I haven't had problems like that. Maybe you should try a clean profile, and just import the Bookmarks (firefox.exe -profileManager, or use the link in the Start Menu)
3.0.4 on XP, 30+ tabs open (including GMail), 284MB used. I've about a dozen add-ons, including NoScript (currently permitting almost all the open sites), ABP, Firebug, YSlow, Greasemonkey,...
I restart Firefox about as often as I restart XP, which is not very often.
The new-style iMacs in one lab I worked in had burn-in from the login prompt, since apparently a bug in the lab's systemwide configuration prevented the displays from sleeping. LCDs aren't immune to this, but a little bit of proper care can prevent this in the first place.
Also, oddly enough, after the configuration was repaired, the burn-in slowly faded, so I suppose it wasn't permanent.
About a month ago I ran a set of benchmarks to test IE8, FF3.0, FF3.1, Opera, Chrome and Safari on a number of JS and DOM benchmarks. The results are a little outdated (both WebKit and FF3.1 have made big strides in performance in this month alone) but should stand to compare where IE8 is (not IE7). I'll give you a hint: not favorably.
The test and analysis is at my blog and the raw data is here.
There is a development build scoring 97/100 using patches that are now available on Bugzilla; AFAIK the 3 remaining problems are for missing SVG font support. See this comment for more information.
I have an HP dv6000 laptop with a nice big glossy screen, and three fluorescent bulbs (usually on, of course;) ) about a metre from my head. Under the wrong angle, the glare is awful, but with most viewing angles, I find the shiny plastic frame has more "glare" than the screen. In fact, I think I even prefer this to my old matte-screen Powerbook G4, which I used for many years. The brightness is one thing, and the fact that it doesn't look muted is a plus for me. I've also used color calibration on the screen so it looks right under my normal viewing angle, so I personally think glossy screens are fine for most normal work (of course, there are always the professionals who demand specific equipment because of what they are accustomed to, and there's nothing wrong with that)
When Goostman asked me where I was from, I replied "Mars", to which it said:
"By the way, do you know a terrible story about a chatterbot, that wanted to be a President? He spoke ugly, his phrases were lame and intelligence was artificial (he told only the things he was prompted to)... I should tell you a secret: he BECAME the Prez! Androids are among us already!!! "
At least it has a self-deprecating sense of canned humour...
If you want to see the "second version" in alpha, head on over to the Chromium builds page. They've been building nightlies since Chrome was announced.
Chrome's one performance distinction -- V8 -- is now being beaten out by WebKit's JavaScriptCore. In fact, there's apparently a movement on Chromium (Chrome dev builds) to merge JSC to Chrome. Firefox's TraceMonkey is still in development, but the speed gains it is posting already are significant.
I don't know about Opera, though its JS performance is pretty decent. That leaves IE, which, even in its eighth incarnation, is about two orders of magnitude slower than Firefox 3 on a number of web benchmarks.
Slashdot Mirror
1) It's Japanese on the panic message, not Chinese
2) When written, you just call it Chinese and not Mandarin Chinese; the distinctions "Mandarin" and "Cantonese" are primarily for spoken language, as the written languages are very nearly identical
3) I fail to see how it could be incomprehensible, seeing as it is pretty much obvious that there are different languages on the panic screen, and that it is giving you very clear instructions on what to do next: see one for yourself
Besides, Windows XP (and likely Vista too) ship in a default configuration where they do not show BSODs (at least, that was the way it was set up on my system, a consumer-level laptop). This means that all the user gets to see is the system *instantly restarting*, without any sort of warning whatsoever. It also means that they won't see a BSOD, but will be informed after startup that their system "recovered from a serious error" or something like that.
One argument for the OS X panic message is that it doesn't replace the entire screen, meaning that whatever you may have been working on is still potentially recoverable. With a full-screen BSOD, where technical details essentially fill the screen, this doesn't happen.
Yes, on OS X, you would use the NSPasteBoard class to interact with the system-wide clipboard. The only thing stopping Apple from implementing NSPasteBoard in the iPhone SDK appears to be the question of how to implement it best in the UI. The system of NSPasteBoard filters handles all the gritty details of converting data between different formats; a given pasteboard can hold data in a specific format (or even multiple formats at once), and the client can invoke a filter to read the data from the PB using any applicable filters. Honestly, everything is in place API-wise, it seems that Apple simply wants to work out the UI (there is, in fact, more than one way to do it, but it seems they are dragging their heels with this important feature!)
If you want to find out if you are blocked, try Special:Mytalk. This page will redirect to the talk page for whatever IP address you appear to be connecting from. If that page happens to have a message like this one on it, then you are being transparently routed by your ISP, and they are probably not sending X-Forwarded-For like they should.
They are free publicity, though, which may in turn lead to sales (especially with all these Amazon links popping up)
"Bush hid the facts" is the more popular version of this particular bug.
Since when was ROT-128 a popular encoding?
It still is. He's joking.
This probably doesn't work for all values, but breaking ties by choosing the square farthest from the center substantially increases the effective range of the algorithm. I haven't yet found out how far it goes, but it seems to hold up all the way to 450x450.
TFA has basically stumbled upon Warnsdorff's algorithm. It's a great method, but it doesn't work for really large boards due to blind alleys. There's another method available which uses decomposition to achieve a linear running time(in # of squares), but which is quite a bit more complex to implement. There's a nice tweak to the algorithm which can get much farther than the unmodified original: in the event of a tie (where two candidates have the same number of open neighbours), break the tie by choosing the square farthest from the center. This substantially extends the maximum size of the board (to what, I don't know, because it's worked for everything up to around 450x450, which is past what was described by Arnd Roth).
Better yet, replace the whole thing with a generator expression wrapped in sum, thus removing map and the temporary array:
key=lambda c:sum((int(InRangeAndEmpty(c[0]+j[0], c[1]+j[1])) for j in jumps))
int(bool) turns True into 1 and False into 0, and is more readable than "and 1 or 0" (better yet, use the Python 2.5 conditional "1 if InRangeAndEmpty(...) else 0").
I rewrote the code using a stack, to see how far it could get. It does 162x162 in linear time (w.r.t. the number of squares) and then, at 163x163, it abruptly stops being fast, as it begins to perform heavy backtracking -- it fails to fill in a region near the top-right corner. Hence, the heuristic (as written) is not powerful enough for all grids.
It does. Run it with a value of 163 or higher.
Firefox+NoScript. Then mark Google Analytics as untrusted to avoid it from telling you it blocked GA. Same thing works for DoubleClick and other advertising/tracking sites.
/etc/hosts file to redirect GA somewhere harmless.
Alternatively, you could add an
The tests were not carried out on the very newest software, which puts Firefox and Safari in particular at a significant disadvantage.
Firefox introduced TraceMonkey to 3.1, and beta builds of it are available. In pure JS testing, they completely destroy 3.0.4 in terms of speed.
Safari introduced SquirrelFish, and then SquirrelFish Extreme which added JIT capability to Safari's JavaScript interpreter. It is available in the nightly WebKit builds.
Furthermore, with Acid3, WebKit nightlies pass Acid3 with 100% and Firefox nightlies get around 93%. Chrome nightlies, having merged newer WebKit code, get 100% as well.
A few months ago, I ran a test using the then-current nightlies, which I posted on my blog. One particularly good test site is Dromaeo, which TFA failed to mention. Dromaeo tests not only JavaScript, but JavaScript and DOM interaction, making it a good candidate for testing the performance of a real-world situation.
I haven't had problems like that. Maybe you should try a clean profile, and just import the Bookmarks (firefox.exe -profileManager, or use the link in the Start Menu)
3.0.4 on XP, 30+ tabs open (including GMail), 284MB used. I've about a dozen add-ons, including NoScript (currently permitting almost all the open sites), ABP, Firebug, YSlow, Greasemonkey, ...
I restart Firefox about as often as I restart XP, which is not very often.
Bah, they go to the length of filming the trailer only to screw up Kirk's middle name? Sheesh.
That complaint aside, I think this stands a chance of being a decent movie, but the trailer doesn't make me feel any more confident in my stance...
The new-style iMacs in one lab I worked in had burn-in from the login prompt, since apparently a bug in the lab's systemwide configuration prevented the displays from sleeping. LCDs aren't immune to this, but a little bit of proper care can prevent this in the first place.
Also, oddly enough, after the configuration was repaired, the burn-in slowly faded, so I suppose it wasn't permanent.
Or just
:%!sort
to sort the entire file.
I think you mean "aesthetically", not "atheistically", unless your skin and/or theme is suddenly a religious preference.
About a month ago I ran a set of benchmarks to test IE8, FF3.0, FF3.1, Opera, Chrome and Safari on a number of JS and DOM benchmarks. The results are a little outdated (both WebKit and FF3.1 have made big strides in performance in this month alone) but should stand to compare where IE8 is (not IE7). I'll give you a hint: not favorably.
The test and analysis is at my blog and the raw data is here.
There is a development build scoring 97/100 using patches that are now available on Bugzilla; AFAIK the 3 remaining problems are for missing SVG font support. See this comment for more information.
I have an HP dv6000 laptop with a nice big glossy screen, and three fluorescent bulbs (usually on, of course ;) ) about a metre from my head. Under the wrong angle, the glare is awful, but with most viewing angles, I find the shiny plastic frame has more "glare" than the screen. In fact, I think I even prefer this to my old matte-screen Powerbook G4, which I used for many years. The brightness is one thing, and the fact that it doesn't look muted is a plus for me. I've also used color calibration on the screen so it looks right under my normal viewing angle, so I personally think glossy screens are fine for most normal work (of course, there are always the professionals who demand specific equipment because of what they are accustomed to, and there's nothing wrong with that)
When Goostman asked me where I was from, I replied "Mars", to which it said: "By the way, do you know a terrible story about a chatterbot, that wanted to be a President? He spoke ugly, his phrases were lame and intelligence was artificial (he told only the things he was prompted to)... I should tell you a secret: he BECAME the Prez! Androids are among us already!!! "
At least it has a self-deprecating sense of canned humour...
If you want to see the "second version" in alpha, head on over to the Chromium builds page. They've been building nightlies since Chrome was announced.
Chrome's one performance distinction -- V8 -- is now being beaten out by WebKit's JavaScriptCore. In fact, there's apparently a movement on Chromium (Chrome dev builds) to merge JSC to Chrome. Firefox's TraceMonkey is still in development, but the speed gains it is posting already are significant.
I don't know about Opera, though its JS performance is pretty decent. That leaves IE, which, even in its eighth incarnation, is about two orders of magnitude slower than Firefox 3 on a number of web benchmarks.