It's not that bizarre... Wine is not an emulator (so no performance penalty of that sort), and MSVC++ produces better-optimized code than g++. It also produces about 40% smaller code, last I checked....
> To the best of my knowledge, Firefox typically does not leak memory,
You want to be a little careful here. Which Firefox? Stuart's post is talking about current trunk. Firefox 2, on the other hand, has a number of known memory leaks...
Let's see... OS/2 and HP-UX come to mind, at least if you cared about performance and the like.
And if we're talking about templates, GCC's support was pretty bad too, at the time. In fact, it wasn't until the switch to GCC 3.x that life got a little better on that front. egcs 2.95 was a bit of a mess in all sorts of ways.
No one's arguing the guidelines don't need revising. They do. But when they were written they made perfect sense. You have to keep in mind that they're almost 10 years old now. C++ compilers were _really_ bad back then. Heck, some of them were still based on cfront!
> It's the response I have seen every single time the > situation is discussed by anyone in the Firefox camp.
The problem is that 99.9% of the people who are both "discussing" and obviously "in the Firefox camp" are fanboys who have no idea what they're talking about. The actual Firefox developers are greatly outnumbered by the fanboys and don't often come across as being "in the Firefox camp" because the things they say are much more reasonable and more critical of Firefox.
> And by "people like me", you mean people who use Firefox religiously > and have been a major Mozilla supporter
No, by "people like you" I mean people who are frustrated with the memory usage issue and with the falsehoods being perpetuated by said fanboys (that's any reasonable person so far) but who don't realize that the nonsense these fanboys spout has little to do with the thinking of any actual Firefox developers.
> It seems like this is also a typical response to any criticisms
You mean pointing out that the people you have a problem with are not the people you're criticizing? Is that an unreasonable response?
> must be an ignorant IE-lover trying to stir shit.
I don't believe I ever mentioned IE, nor called you ignorant. I'm sorry if you perceived my comments this way; they were certainly not intended to say anything like this.
I fully sympathize with your feelings about the memory issue, and I really wish a number of people who don't know what they're talking about and try to whitewash things instead of confronting problems head-on would just shut up and go away. Sadly, there are a lot of them out there, and they're very vocal.
> There have been plenty of such articles and discussions right here on Slashdot
Yes, I know. I have yet to see an actual Firefox developer evidence the "Leaks? What leaks?" attitude in any of them. I _have_ seen that attitude a lot from people who apparently have never bothered to either look at the code or look at the Firefox tinderbox tree (which has had a leak test running for years), or just read David Baron's blog.
What excuse, exactly? Being unable to reproduce a leak makes it hard to fix. Saying "I leak, but I won't tell you anything about how you could start looking for my leak" doesn't help get the leak fixed.
None of this is _good_. It's just a statement of fact.
There is sloppy coding in some parts of the codebase (some of which are not actually used in Firefox, though; parts of the addressbook code in mailnews come to mind). The reference-counting system used in Gecko will leak in the presence of reference cycles (mitigated in 1.9 with the cycle collector). The reference-counting system and the GC-based JS engine don't play that nice together in some ways (again mitigated by the cycle collector; planned to be fixed in Gecko 2.0 by moving to a GC-based setup for the C++ as well). Extensions have been known to do silly things like holding onto all Window objects ever loaded in the browser (which of course prevents them from being GCed).
Some things you missed are memory fragmentation, plug-in leaks (only really solvable by putting plug-ins out-of-process), and unbounded growth of caches (there isn't much of this, but for completeness sake).
You read somewhat wrong... General use of templates was disallowed, but templated smart pointers for reference counting have been in use in Gecko for quite a long time. The class was carefully written and tested to work on all the compilers being targeted at the time (a lot of which had crappy template support).
I'm not sure why it's "heinous" advice to say "avoid writing code that won't compile and will have to be backed out"...
Sorry, I call bullshit. The only time I've seen that "response" was on Ben Goodger's blog, numerous comments by ignorant fanboys, and a lot of copy/pastes by people like you. I have yet to see anyone familiar with Firefox internals make this (patently false) claim. Of course part of the problem with the Web is that most people can't tell apart a random blogger who doesn't even use Firefox, a Firefox fanboi, and a Gecko developer, even if they were to try. And they don't try.
The claim I _have_ seen made is that leak bugs would be easier to fix if people actually provided some idea of how to reproduce the leak (e.g. which sites they visited in the process of leaking). At some point David Baron wrote an extension that allowed collecting such data automatically, and the results from this led directly to a number of leaks being fixed in Gecko 1.9.
The other issue Gecko 1.8 had is that it had several leak scenarios that particularly hit AJAXy apps. With the growth in the number of such apps, the leaks became more serious. Gecko 1.9 fixes those issues.
> I'd like to hear about the 'pre-dated standards' you speak of.
CSS2.1 (which changes a number of things from CSS2) comes to mind... Some of the DOM specs post-date IE6 (certainly all of DOM3, and possibly some parts of DOM2, as I recall).
Heck, there are parts of CSS2.1 that aren't implemented correctly in Gecko yet, because they were implemented per CSS2 and haven't been rewritten to the CSS2.1 changes yet. So I can very much sympathize with IE here.
> "Every HTML document must have a TITLE element in the HEAD section."
That's correct. The and _tags_ are optional. The HEAD _section_ is not. Where it starts and stops is determined by the and tags if present, and otherwise by the other tags in the document. For example, parsing:
Foo
Text
gives the same exact results as parsing
Title
Text
per the HTML 4.01 spec, since is only allowed inside HEAD and
is not allowed inside HEAD but _is_ allowed inside BODY, and both and are optional.
The unfortunate part of not using and understanding arithmetic (because the calculator can do it) is that you don't understand little things like long division. This isn't hypothetical; I've encountered people in college who couldn't really do long division.
Problems start when you have to take college-level math classes (tend to be required for graduation). The Euclidean algorithm? Have to do division with remainder. Limits of polynomial functions? Have to do long division of polynomials. Integration of rational functions? Long division of polynomials with remainder.
Now of course one can build all this into the calculator. But this is just one elementary school arithmetic algorithm we're talking about here....
In the end, you need to be able to do arithmetic unaided, simply because you might well need to do it on objects your calculator doesn't understand.
The versioning scheme was set up when it was not clear whether the next release would be 3.x or 2.5.x. That's the first 0.
The second zero is insurance against having to ship a security fix that breaks extension compatibility somehow. If that happens (and it's something everyone works hard to avoid), that number would get incremented.
> I have several hundred browser-independent canvas test cases, so I guess I should see if they > could be incorporated into Mozilla somehow
That would be awesome. If you end up filing a bug on getting this done, please cc bzbarsky at mit dot edu and I'll help make sure we get them hooked up.
> And when you stopped reading, you should have continued
That's not the initial response, now is it?
> there you have "helpful" suggestions like
You mean comment 30?
The commenter in question is not a Mozilla developer. He's not Mozilla Corporation QA. I'm not sure why you're taking "Mozilla" to task for something someone not particularly affiliated with Mozilla said in a comment in the bug database. A bug database in which anyone can create an account and then say things.
If you want the actual "Mozilla" response after the point where I stopped reading, you want:
Comments 34, 38, 39, 40, 44, 46: QA. Comments 41, 43: The guy in charge of the security releases.
Where, exactly? Reading the link you posted I see:
1) Original report 2) 5 comments confirming that it's a problem 3) 1 comment indicating which change caused the problem 4) 1 comment indicating what should be done to fix the problem 5) 1 comment combined with flag changes to make sure there is a regression test in the future 6) 1 comment asking an earlier commenter for the URL to the site they said was broken, to
make sure that it actually gets fixed. 7) 3 comments that say that it's a problem and where 8) A regression test being posted 9) The regression test being checked in 10) Some bugs being marked duplicate 11) The fix being checked in
All that happened over the course of 18 hours. I stopped reading there, since the rest doesn't particularly matter, as far as I can tell.
You must have meant std::wstring. But in Gecko code in particular you would not in fact "normally" use std::anything. That might change, but as of the time the current portable code guidelines for Gecko were written, that sort of thing wasn't portable reliably enough.
Uh... What's the problem with compiling it? Apart from needing a compat autoconf version (which is always installed anyway) and a number of -devel packages (not really surprising, now is it?), it's a single make command...
> It's not that hard to fix, they should simply drop the current code and use WebKit instead.
It's been considered. That would be a much larger undertaking than you think, though.
> Netscape did not open-source the thing because it was so very good
Sure. Of course the "thing" Netscape open-sourced wasn't Gecko. Gecko was written after people looked at the thing Netscape open-sourced and decided that it sucked.
Slashdot Mirror
It's not that bizarre... Wine is not an emulator (so no performance penalty of that sort), and MSVC++ produces better-optimized code than g++. It also produces about 40% smaller code, last I checked....
> To the best of my knowledge, Firefox typically does not leak memory,
You want to be a little careful here. Which Firefox? Stuart's post is talking about current trunk. Firefox 2, on the other hand, has a number of known memory leaks...
At the time when the guidelines were created?
Let's see... OS/2 and HP-UX come to mind, at least if you cared about performance and the like.
And if we're talking about templates, GCC's support was pretty bad too, at the time. In fact, it wasn't until the switch to GCC 3.x that life got a little better on that front. egcs 2.95 was a bit of a mess in all sorts of ways.
No one's arguing the guidelines don't need revising. They do. But when they were written they made perfect sense. You have to keep in mind that they're almost 10 years old now. C++ compilers were _really_ bad back then. Heck, some of them were still based on cfront!
> It's the response I have seen every single time the
> situation is discussed by anyone in the Firefox camp.
The problem is that 99.9% of the people who are both "discussing" and obviously "in the Firefox camp" are fanboys who have no idea what they're talking about. The actual Firefox developers are greatly outnumbered by the fanboys and don't often come across as being "in the Firefox camp" because the things they say are much more reasonable and more critical of Firefox.
> And by "people like me", you mean people who use Firefox religiously
> and have been a major Mozilla supporter
No, by "people like you" I mean people who are frustrated with the memory usage issue and with the falsehoods being perpetuated by said fanboys (that's any reasonable person so far) but who don't realize that the nonsense these fanboys spout has little to do with the thinking of any actual Firefox developers.
> It seems like this is also a typical response to any criticisms
You mean pointing out that the people you have a problem with are not the people you're criticizing? Is that an unreasonable response?
> must be an ignorant IE-lover trying to stir shit.
I don't believe I ever mentioned IE, nor called you ignorant. I'm sorry if you perceived my comments this way; they were certainly not intended to say anything like this.
I fully sympathize with your feelings about the memory issue, and I really wish a number of people who don't know what they're talking about and try to whitewash things instead of confronting problems head-on would just shut up and go away. Sadly, there are a lot of them out there, and they're very vocal.
> There have been plenty of such articles and discussions right here on Slashdot
Yes, I know. I have yet to see an actual Firefox developer evidence the "Leaks? What leaks?" attitude in any of them. I _have_ seen that attitude a lot from people who apparently have never bothered to either look at the code or look at the Firefox tinderbox tree (which has had a leak test running for years), or just read David Baron's blog.
What that suggests to me is that they're visiting a class of pages that typical Firefox developers don't visit much....
Note that several such classes of pages were identified and fixed in the 1.9 cycle, as I said elsewhere in this thread.
What excuse, exactly? Being unable to reproduce a leak makes it hard to fix. Saying "I leak, but I won't tell you anything about how you could start looking for my leak" doesn't help get the leak fixed.
None of this is _good_. It's just a statement of fact.
A brief answer is "yes".
There is sloppy coding in some parts of the codebase (some of which are not actually used in Firefox, though; parts of the addressbook code in mailnews come to mind). The reference-counting system used in Gecko will leak in the presence of reference cycles (mitigated in 1.9 with the cycle collector). The reference-counting system and the GC-based JS engine don't play that nice together in some ways (again mitigated by the cycle collector; planned to be fixed in Gecko 2.0 by moving to a GC-based setup for the C++ as well). Extensions have been known to do silly things like holding onto all Window objects ever loaded in the browser (which of course prevents them from being GCed).
Some things you missed are memory fragmentation, plug-in leaks (only really solvable by putting plug-ins out-of-process), and unbounded growth of caches (there isn't much of this, but for completeness sake).
You read somewhat wrong... General use of templates was disallowed, but templated smart pointers for reference counting have been in use in Gecko for quite a long time. The class was carefully written and tested to work on all the compilers being targeted at the time (a lot of which had crappy template support).
I'm not sure why it's "heinous" advice to say "avoid writing code that won't compile and will have to be backed out"...
Sorry, I call bullshit. The only time I've seen that "response" was on Ben Goodger's blog, numerous comments by ignorant fanboys, and a lot of copy/pastes by people like you. I have yet to see anyone familiar with Firefox internals make this (patently false) claim. Of course part of the problem with the Web is that most people can't tell apart a random blogger who doesn't even use Firefox, a Firefox fanboi, and a Gecko developer, even if they were to try. And they don't try.
;)
The claim I _have_ seen made is that leak bugs would be easier to fix if people actually provided some idea of how to reproduce the leak (e.g. which sites they visited in the process of leaking). At some point David Baron wrote an extension that allowed collecting such data automatically, and the results from this led directly to a number of leaks being fixed in Gecko 1.9.
The other issue Gecko 1.8 had is that it had several leak scenarios that particularly hit AJAXy apps. With the growth in the number of such apps, the leaks became more serious. Gecko 1.9 fixes those issues.
Try the beta. You might like it.
There was a bug on the server running the test (returning a page with a 200 success code instead of 404 error). It has been fixed since.
> I'd like to hear about the 'pre-dated standards' you speak of.
CSS2.1 (which changes a number of things from CSS2) comes to mind... Some of the DOM specs post-date IE6 (certainly all of DOM3, and possibly some parts of DOM2, as I recall).
Heck, there are parts of CSS2.1 that aren't implemented correctly in Gecko yet, because they were implemented per CSS2 and haven't been rewritten to the CSS2.1 changes yet. So I can very much sympathize with IE here.
Uh... Those examples should have been:
<title>Title</title>
<p>Text</p>
and
<html>
<head><title>Title</title></head>
<body><p>Text</p></body>
</html>
Sadly, the "Plain Old Text" mode seems to be broken....
That's correct. The and _tags_ are optional. The HEAD _section_ is not. Where it starts and stops is determined by the and tags if present, and otherwise by the other tags in the document. For example, parsing:
Foo
Text
gives the same exact results as parsing
Title
Text
per the HTML 4.01 spec, since is only allowed inside HEAD and
is not allowed inside HEAD but _is_ allowed inside BODY, and both and are optional.
Welcome to the world of SGML and DTDs!
> There are major sites on the web which lack even proper HTML/HEAD/BODY tags.
All three of those tags are optional in an HTML 4.01 document (see the DTD for HTML 4.01).
Just in the 70s?
The unfortunate part of not using and understanding arithmetic (because the calculator can do it) is that you don't understand little things like long division. This isn't hypothetical; I've encountered people in college who couldn't really do long division.
Problems start when you have to take college-level math classes (tend to be required for graduation). The Euclidean algorithm? Have to do division with remainder. Limits of polynomial functions? Have to do long division of polynomials. Integration of rational functions? Long division of polynomials with remainder.
Now of course one can build all this into the calculator. But this is just one elementary school arithmetic algorithm we're talking about here....
In the end, you need to be able to do arithmetic unaided, simply because you might well need to do it on objects your calculator doesn't understand.
> and then the next planned release is 3.x
The versioning scheme was set up when it was not clear whether the next release would be 3.x or 2.5.x. That's the first 0.
The second zero is insurance against having to ship a security fix that breaks extension compatibility somehow. If that happens (and it's something everyone works hard to avoid), that number would get incremented.
> I have several hundred browser-independent canvas test cases, so I guess I should see if they > could be incorporated into Mozilla somehow
That would be awesome. If you end up filing a bug on getting this done, please cc bzbarsky at mit dot edu and I'll help make sure we get them hooked up.
> And when you stopped reading, you should have continued
That's not the initial response, now is it?
> there you have "helpful" suggestions like
You mean comment 30?
The commenter in question is not a Mozilla developer. He's not Mozilla Corporation QA. I'm not sure why you're taking "Mozilla" to task for something someone not particularly affiliated with Mozilla said in a comment in the bug database. A bug database in which anyone can create an account and then say things.
If you want the actual "Mozilla" response after the point where I stopped reading, you want:
Comments 34, 38, 39, 40, 44, 46: QA.
Comments 41, 43: The guy in charge of the security releases.
Of course the bug was in Gecko, so it affects Seamonkey too.
> The "shoot the messanger" attitude exhibited
Where, exactly? Reading the link you posted I see:
1) Original report
2) 5 comments confirming that it's a problem
3) 1 comment indicating which change caused the problem
4) 1 comment indicating what should be done to fix the problem
5) 1 comment combined with flag changes to make sure there is a regression test in the future
6) 1 comment asking an earlier commenter for the URL to the site they said was broken, to
make sure that it actually gets fixed.
7) 3 comments that say that it's a problem and where
8) A regression test being posted
9) The regression test being checked in
10) Some bugs being marked duplicate
11) The fix being checked in
All that happened over the course of 18 hours. I stopped reading there, since the rest doesn't particularly matter, as far as I can tell.
Where's the problem exactly?
You must have meant std::wstring. But in Gecko code in particular you would not in fact "normally" use std::anything. That might change, but as of the time the current portable code guidelines for Gecko were written, that sort of thing wasn't portable reliably enough.
Uh... What's the problem with compiling it? Apart from needing a compat autoconf version (which is always installed anyway) and a number of -devel packages (not really surprising, now is it?), it's a single make command...
> It's not that hard to fix, they should simply drop the current code and use WebKit instead.
It's been considered. That would be a much larger undertaking than you think, though.
> Netscape did not open-source the thing because it was so very good
Sure. Of course the "thing" Netscape open-sourced wasn't Gecko. Gecko was written after people looked at the thing Netscape open-sourced and decided that it sucked.
> otherwise how would the single page/10 min usage be less than the 12pp/5 min test?
;)
Is the single page one of the pages loaded in the 12-page test? The article doesn't say.
This article is a great example of how to write up your experimental results without allowing anyone to ever verify them, in fact.
> Point me to the "borked pages" code, and I'll be damn happy to remove it
> if it will give a huge performance boost
http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/CNavDTD.cpp
http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp