It's not in trunk yet, but we want to get it in as soon as possible. It's not trivial, but not terribly difficult either - someone just has to take the time to do it. Unfortunately getting 3.5 out in time was a much higher priority, we just couldn't block on x64.
If you're interested, a tracking bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=489146
Please file bugs if you find the JIT crashing or halting, it's very important to understand and correct these cases. Put "TM: " in the subject for faster triaging:)
Keep in mind, TraceMonkey fixes bake on a separate repository first. Syncs back to trunk are only happening once a week or so.
If you read the article, you'd see he addresses that sort of comment. There's two issues:
1) There's a lot of pressure to get a security patch out as soon as possible; 2) It's impossible to test every single case (the breaking case was a shell extension for a printer that wasn't even being manufactured anymore)
As Raymond likes to say, "you can't have everything."
Supporting pirated game copies is a violation of the SDK license Valve gives us. At best, it's simply unprofessional to cater to people who haven't paid for the game and expect equal support on outdated/cracked versions.
Who knows where the credit card numbers came from, really. There's no evidence that the ones they got were from Steam purchases (I think?). But I wouldn't be surprised anyway. Valve's security is notoriously bad, and they require the last four digits of your credit card number in order to recover lost Steam accounts, so they're at least storing a portion of it.
That said, this hack looked like it was done by a no-steam group, and I honestly have no respect for them. It's fine if you want to run old Valve games without Steam (it's pretty horrible software), but I totally disagree with outright pirating their games. These guys go a step further and brag about it. Our HL community has a very anti-"no steam" policy; you simply won't get support if you're running it.
I don't see what those syntax rules have to do with them being fundamentally the same with regard to memory organization. Your details aren't relevant to the point being made.
If you want to teach basic C (such as function calling, variables, and basic expressions), probably any "Learn C in X days" book will do the job. But at that rate, there's not much point in learning C over a simpler language, like Java. Teaching memory organization is essential to anything beyond trivial C, so for high school students, teaching a language that stresses the higher level concepts first may be wiser.
Many books don't do hardware / memory fundamentals right, if at all, and that might be a problem for finding good reference material. I find that everyone I teach C to runs into the same problems, which are usually either poorly explained or just don't "click" until after a while:
1. The fact that an array, a pointer (of any level), and an address are fundamentally the same. I.e. not seeing that there's no conversion needed from "type[]" to "type *" 2. The fact that the '*' character is syntactically confusing: in a type declaration it defines a pointer, in an expression it deferences one. Mistake example: const char *ptr; *ptr = "String"; 3. The fact that a C-style string is an array of characters. 4. The fact that declaring a pointer does not "create" memory - it creates a variable which holds a (potentially uninitialized) address to memory. Mistake example: const char *ptr; strcpy(ptr, "This will probably crash.");
As for books, unfortunately I don't know of any off the top of my head. Finding one that clearly explains those issues would be my best choice (Randall Hyde's "Write Great Code" is excellent but is about assembly, not C, unfortunately). Good luck, teaching C can be hard, but leads to a far greater understanding of how computers work. You may end up choosing an easier language.
Err... that's a bit too wordy for kids, who probably wouldn't be reading about copyright law in that detail anyway. Also, I cannot help but notice that there are no A's or B's.
Maybe it should have a section on how they can pirate stuff, that'd be more useful.
Are you an HL2 mod developer? If so, link to your HL2 mod.
I am one (our project burned out for a while), and I'm far more satisfied with the HL1 modding environment. I don't feel like repeating all of the reasons why, but amongst the developers I know, it's a well shared sentiment. Valve is nowhere near as friendly to developers anymore, especially to us open source ones.
The HL2SDK is astoundingly disorganized, barely compiles properly on GCC, is poorly supported, not ported to AMD64, and known serious bugs have gone unfixed for over a year.
Look at the game stats. The most popular third party Source mod is a tinker toy called "Garry's Mod". The next highest used Source mod has users that can be counted in one server screen. Not only is independent modding for HL2 a failure, but Valve is directly impeding it.
It's funny, after reading his write-up, I realized I'd never even seen Go menu before.
Sure enough, it's there, and I never knew it. That's probably a good hint that I don't need a "Go Menu," as it looks pretty useless.
I think he's right about "Find" as well. Although the bottom quick-find is very cool, there's no short-cut (or even this feature at all) for an advanced find dialogue.
It's also odd he mentioned that Firefox should retain the last URL when opening a new window - this is perhaps the IE feature I hate the most, with a passion. Often I'm simply viewing a large site and want to spawn a clean window (since there are no tabs) - it has to reload the whole thing over again.
I'm sure there are people here who automatically assume an IE developer has no place telling Firefox suggestions, but I think some of these are good.
Indeed, you are correct, my understanding of placement delete was not quite right:) thanks for clearing that up.
By "implementation dependent", I meant the binary ABI behind it. You can't cast a member function pointr to a void pointer, you must double cast it to a pointer to a pointer and then back to get at its memory. I imagine this is because every compiler implements it differently.
Nope. Remember, typeof would be like sizeof... compile time, not runtime, where you know the type of your class anyway. It would be an operator that returns a typecast to the type of the expression, essentially.
Where it's useful is different than what you're talking about (finding the type of a runtime class with typeid). In complicated macro or templating situations you sometimes need to know the type of an expression without it being explicitly declared. We came across this a few months ago, but I've forgotten the exact situation:( something with calling arbitrary virtual functions through an instance pointer in a template (yuck).
I program in C++ from dawn to dusk, and a few things really irk me about it:
1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.
2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?
3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What.
4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.
I'm sure there are other language constructs that have annoyed me, and if you don't read my mind and fix them, Bjarne, I will kick you in the pants!
FYI, You'll see it's not out of context at all if a)You're an HL2 developer and b)You read the entire discussion.
The API was: a)Exported, otherwise we couldn't have used it b)Used, every mod plugin was using it c)Documented, in cl_dll\menu.cpp
And the actual issue at hand was that Valve was not providing adequate API to do the task, while claiming to the public that they were.
That particular debate incited hundreds of messages on HL2 boards. It enraged so many developers, players, and server administrators, all at once, that Valve was forced to reverse the decision. They don't admit they're wrong tot often, so the reversal was a footnote in an e-mail: "we won't change this for now". So, in the end, they decided to do nothing rather than fix the root of the problem.
You're right, the previously beta VAC2 is now default in server startup. I missed that in the last Steam update - probably because they've been promising it "soon" since CS:S debuted.
However, I don't think this invalidates my claim at all. Want more facts? Valve has had a noted history of taking forever to finish any product. When it does come out, after months of "real soon now", it's a shoddy, incomplete implementation that is patched heavily for months over Steam.
Case in point: Condition Zero. It was promised for years as the single player sequel to Counter-Strike. Finally, instead of a whole new set of weapons and maps, we got new player skins and useless single player "missions" with the same old de_dust and friends. An update this paltry should have been CS 1.7, but Valve sold the game at $39.95 in stores.
Tack on HL2 (remember the delays?), both VAC versions, Steam itself, and DoD:S, Valve does not have an impressive delivery history.
You hit the nail on the head. Commercial games are usually far more functional and better looking, simply because they have to be to stay competetive. And if you develop on a commercial game, you automatically have a userbase of potentially tens of thousands of users.
Not to say OSS is bad (my mods are open source), but I don't think there is an F/OSS engine or game that can compare with the top FPSes on the market.
It's not in trunk yet, but we want to get it in as soon as possible. It's not trivial, but not terribly difficult either - someone just has to take the time to do it. Unfortunately getting 3.5 out in time was a much higher priority, we just couldn't block on x64. If you're interested, a tracking bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=489146
+1, This article is silly. You can find that file in every Valve Linux dedicated server (HL1, various HL2 versions, etc).
v8-richards failure was fixed recently: https://bugzilla.mozilla.org/show_bug.cgi?id=456384
Please file bugs if you find the JIT crashing or halting, it's very important to understand and correct these cases. Put "TM: " in the subject for faster triaging :)
Keep in mind, TraceMonkey fixes bake on a separate repository first. Syncs back to trunk are only happening once a week or so.
If you read the article, you'd see he addresses that sort of comment. There's two issues:
1) There's a lot of pressure to get a security patch out as soon as possible;
2) It's impossible to test every single case (the breaking case was a shell extension for a printer that wasn't even being manufactured anymore)
As Raymond likes to say, "you can't have everything."
Supporting pirated game copies is a violation of the SDK license Valve gives us. At best, it's simply unprofessional to cater to people who haven't paid for the game and expect equal support on outdated/cracked versions.
Who knows where the credit card numbers came from, really. There's no evidence that the ones they got were from Steam purchases (I think?). But I wouldn't be surprised anyway. Valve's security is notoriously bad, and they require the last four digits of your credit card number in order to recover lost Steam accounts, so they're at least storing a portion of it.
That said, this hack looked like it was done by a no-steam group, and I honestly have no respect for them. It's fine if you want to run old Valve games without Steam (it's pretty horrible software), but I totally disagree with outright pirating their games. These guys go a step further and brag about it. Our HL community has a very anti-"no steam" policy; you simply won't get support if you're running it.
I believe the term you're looking for is Valve Time.
I don't see what those syntax rules have to do with them being fundamentally the same with regard to memory organization. Your details aren't relevant to the point being made.
If you want to teach basic C (such as function calling, variables, and basic expressions), probably any "Learn C in X days" book will do the job. But at that rate, there's not much point in learning C over a simpler language, like Java. Teaching memory organization is essential to anything beyond trivial C, so for high school students, teaching a language that stresses the higher level concepts first may be wiser.
Many books don't do hardware / memory fundamentals right, if at all, and that might be a problem for finding good reference material. I find that everyone I teach C to runs into the same problems, which are usually either poorly explained or just don't "click" until after a while:
1. The fact that an array, a pointer (of any level), and an address are fundamentally the same. I.e. not seeing that there's no conversion needed from "type[]" to "type *"
2. The fact that the '*' character is syntactically confusing: in a type declaration it defines a pointer, in an expression it deferences one. Mistake example: const char *ptr; *ptr = "String";
3. The fact that a C-style string is an array of characters.
4. The fact that declaring a pointer does not "create" memory - it creates a variable which holds a (potentially uninitialized) address to memory. Mistake example: const char *ptr; strcpy(ptr, "This will probably crash.");
As for books, unfortunately I don't know of any off the top of my head. Finding one that clearly explains those issues would be my best choice (Randall Hyde's "Write Great Code" is excellent but is about assembly, not C, unfortunately). Good luck, teaching C can be hard, but leads to a far greater understanding of how computers work. You may end up choosing an easier language.
ABC's of copyright
Err... that's a bit too wordy for kids, who probably wouldn't be reading about copyright law in that detail anyway. Also, I cannot help but notice that there are no A's or B's.
Maybe it should have a section on how they can pirate stuff, that'd be more useful.
Are you an HL2 mod developer? If so, link to your HL2 mod.
I am one (our project burned out for a while), and I'm far more satisfied with the HL1 modding environment. I don't feel like repeating all of the reasons why, but amongst the developers I know, it's a well shared sentiment. Valve is nowhere near as friendly to developers anymore, especially to us open source ones.
The HL2SDK is astoundingly disorganized, barely compiles properly on GCC, is poorly supported, not ported to AMD64, and known serious bugs have gone unfixed for over a year.
Look at the game stats. The most popular third party Source mod is a tinker toy called "Garry's Mod". The next highest used Source mod has users that can be counted in one server screen. Not only is independent modding for HL2 a failure, but Valve is directly impeding it.
I wonder if Microsoft will be able to pay this...
That's like saying a text editor shouldn't need to do anything but edit text ;]
They're making an application to suit as many people as possible. If it doesn't suit you, don't use it.
It's funny, after reading his write-up, I realized I'd never even seen Go menu before.
Sure enough, it's there, and I never knew it. That's probably a good hint that I don't need a "Go Menu," as it looks pretty useless.
I think he's right about "Find" as well. Although the bottom quick-find is very cool, there's no short-cut (or even this feature at all) for an advanced find dialogue.
It's also odd he mentioned that Firefox should retain the last URL when opening a new window - this is perhaps the IE feature I hate the most, with a passion. Often I'm simply viewing a large site and want to spawn a clean window (since there are no tabs) - it has to reload the whole thing over again.
I'm sure there are people here who automatically assume an IE developer has no place telling Firefox suggestions, but I think some of these are good.
The development aspect, not so much, as Microsoft puts a LOT of effort into backward compatibility.
But when it comes to giving users directions on how to get around the OS, yes.
Since we don't really know exactly what aspects will be removed from lower-versions in the final release, it's hard to say anyway.
my browser only supports analog downloads.
NETCRAFT CONFIRMS IT.
Slashdot is dying.
(sorry)
Indeed, you are correct, my understanding of placement delete was not quite right :) thanks for clearing that up.
By "implementation dependent", I meant the binary ABI behind it. You can't cast a member function pointr to a void pointer, you must double cast it to a pointer to a pointer and then back to get at its memory. I imagine this is because every compiler implements it differently.
No, we were implementing virtual function hooking through a delegate implementation.
You can read about it ("SourceHook") on the developer's blog: click here
Nope. Remember, typeof would be like sizeof... compile time, not runtime, where you know the type of your class anyway. It would be an operator that returns a typecast to the type of the expression, essentially.
:( something with calling arbitrary virtual functions through an instance pointer in a template (yuck).
Where it's useful is different than what you're talking about (finding the type of a runtime class with typeid). In complicated macro or templating situations you sometimes need to know the type of an expression without it being explicitly declared. We came across this a few months ago, but I've forgotten the exact situation
I program in C++ from dawn to dusk, and a few things really irk me about it:
1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.
2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?
3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What.
4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.
I'm sure there are other language constructs that have annoyed me, and if you don't read my mind and fix them, Bjarne, I will kick you in the pants!
FYI, You'll see it's not out of context at all if a)You're an HL2 developer and b)You read the entire discussion.
a th/screens.html?page=7
;]
The API was:
a)Exported, otherwise we couldn't have used it
b)Used, every mod plugin was using it
c)Documented, in cl_dll\menu.cpp
And the actual issue at hand was that Valve was not providing adequate API to do the task, while claiming to the public that they were.
That particular debate incited hundreds of messages on HL2 boards. It enraged so many developers, players, and server administrators, all at once, that Valve was forced to reverse the decision. They don't admit they're wrong tot often, so the reversal was a footnote in an e-mail: "we won't change this for now". So, in the end, they decided to do nothing rather than fix the root of the problem.
The screenshot in question was this one:
http://www.gamespot.com/pc/action/halflife2afterm
I said "one" because when I saw it, it was the only one on the Steam page
Thanks for playing Internet.
You're right, the previously beta VAC2 is now default in server startup. I missed that in the last Steam update - probably because they've been promising it "soon" since CS:S debuted.
However, I don't think this invalidates my claim at all. Want more facts? Valve has had a noted history of taking forever to finish any product. When it does come out, after months of "real soon now", it's a shoddy, incomplete implementation that is patched heavily for months over Steam.
Case in point: Condition Zero. It was promised for years as the single player sequel to Counter-Strike. Finally, instead of a whole new set of weapons and maps, we got new player skins and useless single player "missions" with the same old de_dust and friends. An update this paltry should have been CS 1.7, but Valve sold the game at $39.95 in stores.
Tack on HL2 (remember the delays?), both VAC versions, Steam itself, and DoD:S, Valve does not have an impressive delivery history.
You hit the nail on the head. Commercial games are usually far more functional and better looking, simply because they have to be to stay competetive. And if you develop on a commercial game, you automatically have a userbase of potentially tens of thousands of users.
Not to say OSS is bad (my mods are open source), but I don't think there is an F/OSS engine or game that can compare with the top FPSes on the market.
--bail