New handheld every 6 months? There are just DS, DS Lite and DSi. Meanwhile, this is the fourth PSP, the three last ones all being released roughly a year apart. Not to mention AFAIK the DS's all share the same accessories (save for the DSi not having a GBA port), while the Go will require all-new accessories.
There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.
You should note, though, that one of the failures of YARV was because of code incompatibility (assuming String#[] returns an Integer, which changed in Ruby 1.9). This is an actual worry, because you have to port your code to 1.9 (unlike JRuby, which should be very close to a drop-in solution for 1.8). The other was excessive recursion, something pretty unlikely to find in a "real-world" app.
The JRuby errors were all implementation failures. Pretty minor ones which might be already fixed by now, but still actual mistakes on the JRuby part.
I don't like to make assumptions about others, but you seem to believe that the majority speaks exclusively English.
Yes but we are talking about a very, very slim minority here are we not? No offense intended but it seems like your whole point is hinging on the absolute minority of people out there. I can't think of any systems off hand that do this
According to Wikipedia, the circumflex accent is "used in written Croatian, Esperanto, French, Frisian, Norwegian, Romanian, Slovak, Vietnamese, Romanized Japanese, Romanized Persian, Welsh, Portuguese, Italian, Afrikaans, Turkish and other languages".
I don't know the keyboard layouts used by all of them, but I'd bet most (if not all) of them use a dead key for both the caret and the circumflex rather than including additional keys, and Portuguese and French have a reasonable number of speakers. Plus there are those who, despite not speaking one of these languages, still have dead keys (for example on US-International). What's the layout used by the people who speak Spanish in the US? If it's US-International, that should be a sizable part of the population even in an English-speaking country.
So spend the $5 and get a new keyboard?
Um, no, not always possible. I know this comment went more into my particular problems, but still I saw similar complaints on Reddit. I guess people in other countries also have the same issues of every now and then having to deal with other layouts.
It is, once you consider some people have dead keys. Typing "^^" can become wildly different depending on what OS you're using, and result in weird behavior. On some systems/applications, the two carets are printed at once and you're back to normal editing. On others, the first one is written, but the other remains in dead-key mode. I've seen systems where this would just print a single caret (possibly coupled with a beep). Then the only reliable way on those keyboard layouts to type that symbol is to press caret, space, caret, space -- four key presses (not counting any shifting you might need to get to the caret character) for an operation which might become very common.
Using '\' has the best parse-ability?
Well, an unambiguous, single-character token is often easier to parse than a double-character token which might conflict with a single-character one.
Plus they did not even evaluate '::'.
That's what they were originally using. The problem is that they already use it for static method invocation, so there would be problems when class names and namespaces clashed. And then for some reason they decided they wanted to allow that to happen, rather than (for example) not allowing classes to have the same name as namespaces and mitigating that by using different naming conventions for both.
But then again, the backslash isn't very easy to type either -- I'm daily switching between three different computers. On each one of them, the backslash key is in a different position. Seriously.
Definitely not. They've been talking about a free-gratis version, and there's chance they will open some of their standard library (possibly sharing part of it with Rubinius, since both have a similar goal of writing as much as possible directly in Ruby), but you shouldn't expect them opening their VM or OODB stuff anytime soon.
But well, if anything, they show how far open implementations of dynamic languages can get performance-wise. The current breed of languages has always lagged behind the old ones (like Lisp and Smalltalk), and this is great proof there's no technical reason for that.
Basically, GemStone, a company which has been working on large-scale object-oriented database systems and a Smalltalk implementation (GemStone/S) for decades, has decided to support Ruby on their infrastructure. Turns out Ruby is indeed quite similar to Smalltalk, and some microbenchmarks already show them as being 8~60x faster than MRI (the main Ruby 1.8 implementation). Should those numbers remain consistent, this will be an incredibly fast implementation of a popular scripting language, surpassing by Python, PHP, Lua, and other Ruby implementations in raw numbers.
This might be a massive push for Ruby/Rails on "enterprise" systems. And if they succeed, this could also be one interesting step reviving the popularity of OODBMSs.
Their measuring the popularity of language foo by "Programming foo" hits, with some special case modifications to deal with particular languages where that kind of query would be problematic.
I guess I found a name for my future language: "Help"
I'm sorry, I screwed up while modding your comment, and I'm commenting to clear it.
The new AJAX-y moderation system seriously needs an undo feature, a grace period to change your mind (before notifying the server), or at the very least some form of confirmation before submitting.
AFAIK, Tamarin was since the beginning scheduled for Gecko 2 (i.e., Firefox 4). So, don't worry, it's not like it didn't make for Fx3, it wasn't supposed to be on this week's beta at all.
Actually, it lies mostly in the languages. Rails makes heavy use of Ruby's metaprogramming abilities to perform magic, turning the whole thing into domain-specific languages.
And about scalability, I'm not sure if Rails is as much a problem as is Ruby. Still, people managed to build websites like Twitter and Yellow Pages on RoR, and afaik neither of them even resorted to JRuby, which on v1.0 already performs slightly better overall than Ruby 1.8 for Rails apps, and with the soon-to-be-released v1.1 shows considerable performance gains, beating even YARV (Ruby 1.9) on some specific tests.
Ah, what would be of Slashdot without car analogies:)
But as far as this analogy goes, you are describing what every car allows you to customize (i.e., these are the settings even Gnome and OS X allow you to change in their respective Preferences areas). KDE's extensive options (and tweaking apps for any environment) would be more about offering lots of unusual changes. Extending the analogy, overly long menus would be similar to giving the user an instrument panel that looks more like a huge cockpit, making even the most commonly used features hard to find and requiring a longer learning curve.
And even then some scripting is safe, some is not, so there are rules that the code has to implement
I use NoScript, so no Javascript in-use here 99% of the time, either...
That doesn't make the JavaScript engine disappear, and the DOM is still generated for every document. And you can't really strip those at all, since both are a core part of XUL. The point is, disabling JavaScript won't really reduce memory usage on Firefox, and probably on any other browser. I don't think Opera or any other browser will switch to some alternative renderer that does not use the DOM or the box model when you disable JavaScript or CSS.
like pop-up blockers, password managers, warnings on insecure pages,
A pop-up blocker is a passive device, simply refusing to execute certain code, it saves CPU time, not the other way around. Similar for pointless warnings about page contents.
And again, I have the password manager disabled, so it should not be using any resources.
There's certainly a bit more to a popup blocker than simply one conditional. Some context on the page must be stored to know when a popup is authorized or not (i.e., certain events give temporary permission for websites to open popups), but certainly it shouldn't really be a noticeable difference anyway. But if it does bother you I'm pretty sure those features are mostly JavaScript XUL bindings (if I recall, Fx2's password manager is written in C++, but Fx3's is written in JS) and should be fairly easy to remove. Easier than your promise of removing parts of the HTML parser.
While eventually these questions about "redundant" and "overrated" moderations get repeated, I personally am amazed at how people can't stop to think for a few seconds. I hope you get modded up (I don't have mod points), so maybe we don't get the same question asked over and over again for such a simple and obvious answer.
AKAImBatman, while I generally agree with what you said here, I must say AC is right when saying this specific discussion has nothing to do with rendering:
At the MIX conference, they ran a demo where a Silverlight chess app had an identical AI player routine
It's a chess AI! No rendering needs to be done. When there's some rendering to do, it's something very quick, with few animations and effects. (they wouldn't be able to make any fancy graphic effects just using the DOM anyway)
And about JavaScript vs CLR: I guess those figures are a bit exaggerated here. Ten thousand times slower? If those numbers are any accurate, I wonder what JS implementation they were using. But I don't expect Tamarin to get much faster either; JIT may work on Flash, but ActionScript uses static typing for that. I don't know how good is its (current) type inference system, but JavaScript will need to rely a lot on it for any truly significative gains on speed. (also, from my experience, Mozilla's DOM handling is much slower than IE's)
Inserting a footnote now requires a whole series of mouse clicks as far as I can tell.
References->Insert Footnote (the big icon in the second group)?
As for line numbers - It's still easy to insert line numbers. However, What I WROTE was try changing the STYLE (e.g., font) of the line numbers - try it, it ain't that easy.
I didn't even know line numbering was possible -- I've never used that before, nor felt a need for that feature. So, first I had to guess how I could enable them, and my first guess -- the Page Layout tab -- was fine.
Then I saw what you meant: there's no easy way to work on those numbers. But due to my knowledge of styles, I guessed there would be a style named "Line Number" -- and, again, I guessed it right. Maybe I was just lucky to find it in a few seconds; I guess an unexperienced user would never really find it -- but then again, I don't expect an unexperienced user (the kind that doesn't understand indenting, tabulations, margins, styles, etc.) to use automatic line numbers either.
But the way you say it, it seems on older versions it was easier. How would you change the style of line numbers on earlier versions?
Alt-E-U doesn't work reliably either.
YMMV, naturally, but I have no idea what you are talking about... it seems to me it works fine. But I never use that shortcut, nor do I know anyone who uses it when there's Ctrl-Z, so I can't really say.
Yes, there are new icons for undo and redo next to the Office button, if you notice them and realize what they are. There are an AWFUL lot of icons up there.
Huh? There's just three icons there by default: save, undo and redo/repeat. Any other icon has been placed by you (or by somebody else).
Wait, let me see if I've understood you correctly.
Clearly, you didn't.
Are you honestly claiming that the view menu was hard to spot?!?!
He never said that. He claimed that the View tab is, as you quoted, "easier to spot than the 'View' menu". It is in about the same place, except larger. Therefore, it is easier to spot.
You seem not to know the differences between keyboard layouts.
Yes, for Z it will specify that the key "Z" (in uppercase, since I do not have a lowercase "z" on my keyboard and, as I stated before, checking for caps/shift is keypress' job). But on my keyboard, if I press the Ç key, I'll naturally get a "ç", though the keycode for it is 59 (";" in US-International layout). Even on US-International you can see that keycode does not always map to actual character result: both ":" and ";" generate the keycode 59 (since they both are on the same key, while the ASCII value for ":" is 58). The keypress event, on the other hand, tells the character outcome of one or more keydown events.
And that's why I said on my original post that the best the vulnerability example could do on my keyboard was to catch "CÇ]boot.ini".
Slashdot Mirror
New handheld every 6 months? There are just DS, DS Lite and DSi. Meanwhile, this is the fourth PSP, the three last ones all being released roughly a year apart. Not to mention AFAIK the DS's all share the same accessories (save for the DSi not having a GBA port), while the Go will require all-new accessories.
http://olabini.com/blog/tag/gae/
In fact, you should thank ThoughtWorks guys for several of the recent blog posts on GAE involving JRuby, Groovy and also Clojure.
There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.
You should note, though, that one of the failures of YARV was because of code incompatibility (assuming String#[] returns an Integer, which changed in Ruby 1.9). This is an actual worry, because you have to port your code to 1.9 (unlike JRuby, which should be very close to a drop-in solution for 1.8). The other was excessive recursion, something pretty unlikely to find in a "real-world" app.
The JRuby errors were all implementation failures. Pretty minor ones which might be already fixed by now, but still actual mistakes on the JRuby part.
Yes but we are talking about a very, very slim minority here are we not? No offense intended but it seems like your whole point is hinging on the absolute minority of people out there. I can't think of any systems off hand that do this
According to Wikipedia, the circumflex accent is "used in written Croatian, Esperanto, French, Frisian, Norwegian, Romanian, Slovak, Vietnamese, Romanized Japanese, Romanized Persian, Welsh, Portuguese, Italian, Afrikaans, Turkish and other languages".
I don't know the keyboard layouts used by all of them, but I'd bet most (if not all) of them use a dead key for both the caret and the circumflex rather than including additional keys, and Portuguese and French have a reasonable number of speakers. Plus there are those who, despite not speaking one of these languages, still have dead keys (for example on US-International). What's the layout used by the people who speak Spanish in the US? If it's US-International, that should be a sizable part of the population even in an English-speaking country.
So spend the $5 and get a new keyboard?
Um, no, not always possible. I know this comment went more into my particular problems, but still I saw similar complaints on Reddit. I guess people in other countries also have the same issues of every now and then having to deal with other layouts.
'**' is easier to type than '^^'?
It is, once you consider some people have dead keys. Typing "^^" can become wildly different depending on what OS you're using, and result in weird behavior. On some systems/applications, the two carets are printed at once and you're back to normal editing. On others, the first one is written, but the other remains in dead-key mode. I've seen systems where this would just print a single caret (possibly coupled with a beep). Then the only reliable way on those keyboard layouts to type that symbol is to press caret, space, caret, space -- four key presses (not counting any shifting you might need to get to the caret character) for an operation which might become very common.
Using '\' has the best parse-ability?
Well, an unambiguous, single-character token is often easier to parse than a double-character token which might conflict with a single-character one.
Plus they did not even evaluate '::'.
That's what they were originally using. The problem is that they already use it for static method invocation, so there would be problems when class names and namespaces clashed. And then for some reason they decided they wanted to allow that to happen, rather than (for example) not allowing classes to have the same name as namespaces and mitigating that by using different naming conventions for both.
But then again, the backslash isn't very easy to type either -- I'm daily switching between three different computers. On each one of them, the backslash key is in a different position. Seriously.
and you can't tamper with those mail properties I suppose.
Thanks to IMAP support, nowadays you can upload any messages onto Gmail.
I'm a Picnic and I had a dream of becoming a major Linux coder, you insensitive clod!
Or is there something important missing on TortoiseHg?
Definitely not. They've been talking about a free-gratis version, and there's chance they will open some of their standard library (possibly sharing part of it with Rubinius, since both have a similar goal of writing as much as possible directly in Ruby), but you shouldn't expect them opening their VM or OODB stuff anytime soon.
But well, if anything, they show how far open implementations of dynamic languages can get performance-wise. The current breed of languages has always lagged behind the old ones (like Lisp and Smalltalk), and this is great proof there's no technical reason for that.
Indeed, incredibly poor summary.
Basically, GemStone, a company which has been working on large-scale object-oriented database systems and a Smalltalk implementation (GemStone/S) for decades, has decided to support Ruby on their infrastructure. Turns out Ruby is indeed quite similar to Smalltalk, and some microbenchmarks already show them as being 8~60x faster than MRI (the main Ruby 1.8 implementation). Should those numbers remain consistent, this will be an incredibly fast implementation of a popular scripting language, surpassing by Python, PHP, Lua, and other Ruby implementations in raw numbers.
This might be a massive push for Ruby/Rails on "enterprise" systems. And if they succeed, this could also be one interesting step reviving the popularity of OODBMSs.
I guess I found a name for my future language: "Help"
...ID is not for old people
The new AJAX-y moderation system seriously needs an undo feature, a grace period to change your mind (before notifying the server), or at the very least some form of confirmation before submitting.
AFAIK, Tamarin was since the beginning scheduled for Gecko 2 (i.e., Firefox 4). So, don't worry, it's not like it didn't make for Fx3, it wasn't supposed to be on this week's beta at all.
And about scalability, I'm not sure if Rails is as much a problem as is Ruby. Still, people managed to build websites like Twitter and Yellow Pages on RoR, and afaik neither of them even resorted to JRuby, which on v1.0 already performs slightly better overall than Ruby 1.8 for Rails apps, and with the soon-to-be-released v1.1 shows considerable performance gains, beating even YARV (Ruby 1.9) on some specific tests.
But as far as this analogy goes, you are describing what every car allows you to customize (i.e., these are the settings even Gnome and OS X allow you to change in their respective Preferences areas). KDE's extensive options (and tweaking apps for any environment) would be more about offering lots of unusual changes. Extending the analogy, overly long menus would be similar to giving the user an instrument panel that looks more like a huge cockpit, making even the most commonly used features hard to find and requiring a longer learning curve.
I use NoScript, so no Javascript in-use here 99% of the time, either...
That doesn't make the JavaScript engine disappear, and the DOM is still generated for every document. And you can't really strip those at all, since both are a core part of XUL. The point is, disabling JavaScript won't really reduce memory usage on Firefox, and probably on any other browser. I don't think Opera or any other browser will switch to some alternative renderer that does not use the DOM or the box model when you disable JavaScript or CSS.
A pop-up blocker is a passive device, simply refusing to execute certain code, it saves CPU time, not the other way around. Similar for pointless warnings about page contents.
And again, I have the password manager disabled, so it should not be using any resources.
There's certainly a bit more to a popup blocker than simply one conditional. Some context on the page must be stored to know when a popup is authorized or not (i.e., certain events give temporary permission for websites to open popups), but certainly it shouldn't really be a noticeable difference anyway. But if it does bother you I'm pretty sure those features are mostly JavaScript XUL bindings (if I recall, Fx2's password manager is written in C++, but Fx3's is written in JS) and should be fairly easy to remove. Easier than your promise of removing parts of the HTML parser.
While eventually these questions about "redundant" and "overrated" moderations get repeated, I personally am amazed at how people can't stop to think for a few seconds. I hope you get modded up (I don't have mod points), so maybe we don't get the same question asked over and over again for such a simple and obvious answer.
AKAImBatman, while I generally agree with what you said here, I must say AC is right when saying this specific discussion has nothing to do with rendering:
At the MIX conference, they ran a demo where a Silverlight chess app had an identical AI player routineIt's a chess AI! No rendering needs to be done. When there's some rendering to do, it's something very quick, with few animations and effects. (they wouldn't be able to make any fancy graphic effects just using the DOM anyway)
And about JavaScript vs CLR: I guess those figures are a bit exaggerated here. Ten thousand times slower? If those numbers are any accurate, I wonder what JS implementation they were using. But I don't expect Tamarin to get much faster either; JIT may work on Flash, but ActionScript uses static typing for that. I don't know how good is its (current) type inference system, but JavaScript will need to rely a lot on it for any truly significative gains on speed. (also, from my experience, Mozilla's DOM handling is much slower than IE's)
References->Insert Footnote (the big icon in the second group)?
As for line numbers - It's still easy to insert line numbers. However, What I WROTE was try changing the STYLE (e.g., font) of the line numbers - try it, it ain't that easy.I didn't even know line numbering was possible -- I've never used that before, nor felt a need for that feature. So, first I had to guess how I could enable them, and my first guess -- the Page Layout tab -- was fine.
Then I saw what you meant: there's no easy way to work on those numbers. But due to my knowledge of styles, I guessed there would be a style named "Line Number" -- and, again, I guessed it right. Maybe I was just lucky to find it in a few seconds; I guess an unexperienced user would never really find it -- but then again, I don't expect an unexperienced user (the kind that doesn't understand indenting, tabulations, margins, styles, etc.) to use automatic line numbers either.
But the way you say it, it seems on older versions it was easier. How would you change the style of line numbers on earlier versions?
Alt-E-U doesn't work reliably either.YMMV, naturally, but I have no idea what you are talking about... it seems to me it works fine. But I never use that shortcut, nor do I know anyone who uses it when there's Ctrl-Z, so I can't really say.
Yes, there are new icons for undo and redo next to the Office button, if you notice them and realize what they are. There are an AWFUL lot of icons up there.Huh? There's just three icons there by default: save, undo and redo/repeat. Any other icon has been placed by you (or by somebody else).
Clearly, you didn't.
Are you honestly claiming that the view menu was hard to spot?!?!He never said that. He claimed that the View tab is, as you quoted, "easier to spot than the 'View' menu". It is in about the same place, except larger. Therefore, it is easier to spot.
The summary should actually link to the main page, as there's no way back to it from that subpage.
I have to agree.
(writing a very short reply as an attempt to evade from this beast)
You seem not to know the differences between keyboard layouts.
Yes, for Z it will specify that the key "Z" (in uppercase, since I do not have a lowercase "z" on my keyboard and, as I stated before, checking for caps/shift is keypress' job). But on my keyboard, if I press the Ç key, I'll naturally get a "ç", though the keycode for it is 59 (";" in US-International layout). Even on US-International you can see that keycode does not always map to actual character result: both ":" and ";" generate the keycode 59 (since they both are on the same key, while the ASCII value for ":" is 58). The keypress event, on the other hand, tells the character outcome of one or more keydown events.
And that's why I said on my original post that the best the vulnerability example could do on my keyboard was to catch "CÇ]boot.ini".