Basically a meteor (or space shuttle) compresses the air in front of it, which causes it to get extremely hot (think bicycle pump). The space shuttle tiles are not as strong as you might think. The heat comes from the compressed super-hot air in front of the object. This is what causes the surface of a meteor to melt.
You really should comment every line of assembly, even when you just increment a register
Rather than doing that, you should increment a block of assembly code. You almost have logical blocks of code that do something. Instead of commenting one instruction at a time, you should be commenting a block of code. Commenting it one line at a time is tedious as well, and doesn't really provide that much information:
1H LDAA =$10;Load the AR with $10
DECA;Decrement the AR
BNE 1B;If the AR is not zero, branch back
versus
1H LDAA =$10;Initialize our counter (in the
DECA;AR) with the value $10. W estart
BNE 1B;the loop, decrementing the;value in the AR until it;reaches 0.
The second version is much better than the first. And also, saying "increment the AR" to an "INCA" instruction is not that helpful. Why am I incrementing it? What happens when I increment it? Too often I've seen useless comments like that.
a) What you're doing. b) Why you're doing it. c) How you're doing it.
I took three assembly programming classes in College. The last one was on the 68k, where we wrote an embedded OS.
Assembly code isn't all that intuitive, and writing comments is especially important. Our professor allocated 20% of our grade on each lab to comments. In addition to accurately describing what we were doing, he checked our grammar. One thing he always stressed is that too many engineers these days don't know how to write comments. Grammar is important in getting the message across unambiguously.
In general, if a person can read your comment and then figure out how to translate what you said into code, then your comment is pretty good. It should give an idea of what you're trying to do, why you're doing it, and how you're doing it.
One of my professor's grad students translated a program from MACRO32 into C++, and all without even knowing MACRO32. He looked through the comments to figure out what they were doing. They were so specific that he could easily translate blocks of code over to C++.
Comments are very important - and I should definitely comment MY code. I can't remember the number of times I've come back to code that I've written and thought "WTF am I doing here? WTF was I smoking when I wrote this?!"
I tend to be paranoid, which is why I stick with serving XHTML as application/xhtml+xml. I'm well aware that you can server XHTML as text/xhtml and it can render fine - but I am still of the impression that it opens up a lot of pitfalls.
I didn't mean to imply that you personally don't know what you are doing, and that is why it's a bad practice.
My argument is based on the fact that you see so many poorly written pages, and that it would probably serve those people better if they know what they were doing - and that's I think setting the write content-type matters. Because you can do many things wrong when you serve XHTML as text/html, and then these mistakes will come to haunt you when you serve it as application/xhtml+xml.
I also know that XHTML doesn't turn into Tag Soup, but the browser tends to read it as such, when it really doesn't have to. And since, Tag Soup is given such a wide latitude, errors can creep in that normally wouldn't be rendered if it was served up as application/xhtml+xml. Why parse XHTML with the Tag Soup parse instead of the XML parser?
I guess we are both misreading the arguments here. I do not mean that:
a) The XHTML becomes invalid when served up as text/html b) The XHTML is "bad" or "changed" or turns into Tag Soup. c) The XHTML is worse than XHTML served up as application/xhtml+xml
but what I do mean is that
a) The XHTML will probably be parsed by the Tag Soup parser instead of the XML parser. b) Since Tag Soup is allowed a wider latitude, you may have malformed code that still renders. c) Serving XHTML as text/html is risky - but provided you know the risks, there is no reason not to do it, however, I personally like to play it safe. d) Since it's XHTML, why not just serve it as application/xhtml+xml (in supporting browsers)?
Anyway, I'm glad I'm having a fruitful discussion on this.:)
Also, take a look here for some information on sending IE into quirks mode. I was mistaken though, it is the DOCTYPE that sends the browser into quirks mode, not the content-type.
According to W3C specifications, sending XHTML 1.1 strict as text/html is invalid. Sending XHTML 1.0 strict as text/html would make the browser read it as tag soup, which is not what you want to do:
"How XHTML affects tag soup
XHTML is a reformulation of the HTML language based on XML. The XML Specification clearly defines what a conforming user agent (such as a web browser) must do when malformed code is encountered. Thus, a browser interpreting a Web page as XHTML will refuse to display the page if it encounters a well-formedness error, ensuring that future XHTML will not be tag soup.
However, XHTML 1.0 states that XHTML may be interpreted by current Web browsers as HTML if it follows a set of compatibility guidelines defined in Appendix C of the XHTML 1.0 Recommendation. At this time, the popular web browser Internet Explorer is unable to interpret XHTML documents as XML, and thus most current XHTML pages are served to browsers as HTML, using the MIME type of "text/html".
Because XHTML 1.0 served to browsers as HTML is parsed as if it were badly-formed HTML, XHTML 1.0 is affected by tag soup in the same way as HTML.
Future versions of XHTML after version 1.0 do not allow the XHTML to be served to browsers as HTML. If implemented according to the recommendation, this should prevent the problem of tag soup once XHTML served as XHTML is supported by all major browsers."
I am not saying that serving up the content as text/html changes it from XHTML to HTML, but it will affect the rendering of the page - and it may not work the way you expect it to. That is why it is a bad practice. The W3C recommends that you serve XHTML documents as they are supposed to be served up: application/xml+xhtml.
Here is also a page that talks about why serving XHTML as text/html is considered harmful.
I'm also not saying that you can't serve up XHTML as text/html, just that it's probably not a good idea, and that it could cause problems later.
Thanks for the explanation of invalid vs. malformed.
Mozilla lets you use innerHTML in an XHTML document, so long as it's served as text/html. And ignore the temptation to look trendy by saying it's not "real" XHTML. It's Mozilla's choice to treat it as HTML and not XHTML; it's fully conformant to spec. to serve (some) XHTML documents as text/html and interpret (some) text/html documents as XHTML. XHTML served as text/html is just as real and valid as any other type of XHTML.
I would tend to disagree. While it may work, it's not a good practice. XHTML is not HTML. I don't see how you can say that you can serve XHTML up as text/html, when XHTML is clearly XML and not the same as HTML. The reason it is not a good practice is because if you send an XHTML document as text/html, the browser interprets it as HTML and not XHTML. I'm not trying to look trendy by saying it's not "real" XHTML, but it isn't. I know that you can insert HTML into an XHTML document using innerHTML - but, if you serve it up as application/xml+xhtml (which is how XHTML should be served, because it isn't the same as text/html), then Firefox won't allow you to do it. Furthermore, serving up XHTML documents as text/html puts the browser into quirks mode, and treats it as tag soup and NOT XHTML.
No, that's malformed XHTML. That's a different thing to invalid XHTML. Invalid XHTML can display just fine in Mozilla, even when you serve it as application/xhtml+xml.
Well, what I meant was malformed then. I am not sure what the difference is between invalid and malformed - do you mean unsupported tags?
There's nothing about innerHTML that makes it incompatible with XHTML. Sure, you can call it with text that would produce malformed XHTML, but the browser can just throw an exception in those cases.
Which is why I said that your solution is fine - I would ideally like something like that instead of having to parse the XML and insert it into the DOM tree, and catch the exception. innerHTML isn't part of the W3C spec either, which is also a problem.
You can try the following, it will work well:
function insertXHTML(myXHTML, myObject) {
var parser = new DOMParser();
var XMLdoc = parser.parseFromString("<div xmlns = \"http://www.w3.org/1999/xhtml\">" + comment + "</div>", "application/xhtml+xml");
I think you missed out a bit of your sample code, but in any case, are you aware of DOM3LS? You can do XML serialisation with that.
I haven't looked at that, it does sound pretty interesting. Also, you can use XSLT to translate server-side data into XML/XHTML and then insert that into the DOM - pretty useful.
I know that firefox won't allow you to add innerHTML to an XHTML document.
O'm not sure I follow. Without "innerHTML", I can't add badly formed xhtml into my document? That's funny, I do it all the time.
Sure, you CAN insert bad XHTML into a document, but then the entire document will not be valid XHTML. I'm sure you know that if you try to load up an invalid XHTML document in Firefox (that is, if you have set the content-type and DTD correctly) it will show up as a parse error. I'm not sure what else you use to try and insert XHTML/HTML into an existing document. You could use the createElementNS function, but that will create valid XHTML as well. innerHTML is not the way to go for XHTML because XHTML is not HTML and you simply don't want to easily insert something that will break the page.
Your solution is possible if there a behind the scenes check for valid XHTML. So for example:
try {
obj.innerXML = str; }
catch(Exception e)//not sure if this is valid exception handling in JS, but you get the idea. {
alert("invalid XHTML"); }
In my solution, you use the XMLParse object. You provide it some XHTML to parse and it will let you know if it is valid or invalid XHTML. And using the importNode function, you don't have to recursively create the DOM tree.
Righto. Also, the W3C doesn't support the innerHTML property.
innerHTML is the wrong way to go, especially in XHTML documents. That's because you can potentially insert badly formed XHTML into the document.
There is, however, a way to do it. I figured it out while trying to make my site XHTML valid. I've written about it on my website. Please note that the site is currently down (problems with my ISP) but it should be back up soon today. Basically it involves parsing the code with the XML parser, and then importing the node into the DOM. My initial solution involved walking the parsed tree (which was a little more involved and longer/complicated). However, you can use the importNode function instead and just import the entire parsed DOM tree into the main document's tree. It works pretty well and ensures that the inserted code is valid XHTML.
I know that it's the "in" thing to bash Microsoft and sometimes Intel.
It's easy to say they are strong-arming and that they are being anti-competitive.
AMD has a history of filling suits against intel. They did it in Japan, and they did it in Europe
The issue here is not whether AMD's processors are "better". I see a lot of arguments like "Man my AMD si teh rox0rz and it runs so much cooler (in all senses) than Intel!" - so WHAT? What does it have to do with this issue at all?
AMD has historically been unable to meet demand. If you were a PC company would you go with a supplier that doesn't meet demand, or one that does?
AMD is a profitable company - and they directly compete with Intel. This IS competition, there is a winner and there is a loser. Someone is always going to be on top. There is a fine-line between losing a competition and being forced out of it.
Intel returns X dollars in advertising money (advertising that will be used for Intel as well - like the Intel inside logo) to customers who make kits with Intel products - that's an incentive - that's not strong-arming, that's good marketing. There isn't anything stopping AMD from doing the same.
I know it's the tradition here to root for the (perceived) underdog and that I'm probably going to burn Karma for this, but this are my 2c's.
Yep. And the reason that they don't get brain damaged is because their neurons aren't dying. And their neurons aren't dying because they're not metabolizing, and thus needing oxygen. The brain is in hibernation, just like the rest of the body.
So is there a temperature limit for metabolizing?
Cell death is of two kinds - apoptosis or necrosis. Apoptosis is programmed cell death (when the lysosomes break), whereas necrosis is due to cell damage - and in this case, lack of oxygen. Cells that die due to necrosis show a lower level of ATP - so it makes sense that the cell was trying to metabolize the remaining oxygen and ran out.
From here, you can see that the increase in Ca2+ ions leads to chain of events that eventually leads to necrosis. Ca2+ ions over a certain threshold inhibits the energy and respiratory processes. I guess the question is, what is stopping the neuron from trying to metabolize?
What I'm assuming is that it takes longer for the blood in the body to cool down, during which time the neurons can continue metabolizing. But when the temperature is suddenly lowered to 7C, metabolysis stops? But we couldn't just quickly lower the temperature of the body to 7C because it would take > 5 min for the blood to cool.
I'll bite, but just because it will be informative for those who don't know.
FreeBSD does have a system. Hard-Drives are/dev/adX (X being an number). There are slices (partitions) on each drive, so you can have/dev/adXsY (Y being a number). Slices are like Microsoft-style (FAT/NTFS) partitions. In addition to the slices, you have a partitions within that slice, so/dev/adXsYZ (Z being a lowercase letter).
There is a convention to the letters:
a = root b = swap c = whole disk d = obselete whole disk e-h = everything else
So, ad0s1a is the root partition on disk 1, slice 1. It's not "unstandardized". Other devices have their own conventions too. It's not that hard. Anyone with a little bit of intelligence can make sense of it.
Explanation of what "funky" means... The wave-functions of the particles start collapsing, essentially describing one giant particle. You are unable to distinguish one particle from the other, since they have the same wave-function - they collapse into the lowest possible quantum state.
I thought gasesous superfluids (Bose-Einstein Condensate) had already been created in 1995:
Bose-Einstein condensate is a gaseous superfluid phase formed by atoms cooled to temperatures very near to absolute zero. The first such condensate was produced by Eric Cornell and Carl Wieman in 1995 at the University of Colorado at Boulder, using a gas of rubidium atoms cooled to 170 nanokelvins (nK). Under such conditions, a large fraction of the atoms collapse into the lowest quantum state, producing a superfluid.
I guess you can owe that to some people being completely perplexed. This article doesn't talk about:
a) Linux
b) Microsoft
c) Google
d) Evil Patents
e) MPAA/RIAA other evil organizations
f) Something else that's geeky
So they really don't know how to contribute... I mean...
In Soviet Russia, IC invents Jack Kilby err... no wait..
In Korea only old people invent IC's... er no...
This is FUD by microsoft! Because without IC's there would be no Microsoft!! Er no...
This hows HOW MUCH LINUX r0x0rz!!11! Because without IC's there would be no linux!! Uh no...
AHHH!!! I CAN'T TAKE IT ANYMORE!
**CORE DUMPED***
One of the very few men, in all of mankind's history who's influence is everywhere. Without him, our world would have been a lot different. God rest his soul. And lest I offend the athiests;), may his recycled remains find use in some noble purpose.
It is amazing how such a small invention has given rise to what we see today.
Even some open source software runs so poorly on BSD that it's not worth using -- like MySQL
Not worth using? I've been using FreeBSD with Apache, MySQL and PHP on my webserver without any problems.
At a job I held in college, I set up a network with FreeBSD and a database-driver website that used PHP+MySQL. This website received significant amount of traffic and ran without any problems.
*Some* software may run poorly, but MySQL is not one of them. It may not run as well on *BSD as on Linux, but it does run (and runs pretty well on some *BSD's).
I've only been using FreeBSD since '02. But I've grown to like it very much and I exclusively use it for server-side webdevelopment.
I had an internship during my junior and senior years of college where they wanted me to maintain a series of webpages that ran in Coldfusion. I got them to change it around to PHP.
The only thing that bugs me about PHP is the exception handling, but I hear that it's getting better. PHP does things far better than Coldfusion (yuck), and it's easier than doing [Perl] CGI (IMHO - although I love perl). The popularity, I think, is due to ease with which one can pick it up, and also its similarity to other languages like C and Perl. And then there's the fact that it can interact with a wide variety of databases.
The LAMP solution works really well, although I use FAMP (FreeBSD, Apache, MySQL, PHP), which works equally well.
I have to agree with the parent. Calculators are useful, but they can quite easily also turn into a crutch.
I studied in the Indian CBSE and AISSE system of education. We weren't allowed any calculators at all, for any subject. We had to use Log (logarithm) tables. Essentially we would convert any problem into base 10 log and then solve it from there. It was supposed to be "easier" because multiplication and division change into addition and subtraction. Exponentiation just becomes division.
Sure, I hated it at the time. It was a total bitch to do anything, but as a result, I got really good at my arithmetic. Even today I can remember the log base 10 values for 2, 3, 4, and 5....3010,.4771,.6020,.6989... and no, I didn't look those up in a calculator:).
Even in university, I had friends who had the TI-92 which could do symbolic integration. I had a lowly Casio model. I didn't mind, because I understood calculus and did everything by hand.
Basically, learning to do things by hand is a good skill to have. So you don't rely on a calculator where things happen "magically". Of course, when there's a time crunch, a powerful calculator helps, but it's still nice to know how things work under the hood.
Dr. Crusher: Jean-Luc, Wesley has a tumor. Capt. Picard: A tumor? Wesley? Well Doctor, I suppose you have to operate. *Flash of Light, Q appears* Q: Bonjour Mon Capitain! Capt. Picard: Q! Is this your doing? Are you the one that gave Wesley canceh? Q: Cancer! You humans are sooo arrogant! Why, haven't you ever thought of what cancer could be? It could be a new life form - look at the way it GROWS! Capt. Picard: You have a point Q... Dr. Crusher, we can't operate. We have to let the boy die. Ask Geordi and Data to figure out a way to communicate with this new life form.
Slashdot Mirror
If you alt-tab out of it, it becomes your desktop with other windows on top of it. Except you can't see your desktop icons...
It isn't friction. It's called "Ram Pressure".
Basically a meteor (or space shuttle) compresses the air in front of it, which causes it to get extremely hot (think bicycle pump). The space shuttle tiles are not as strong as you might think. The heat comes from the compressed super-hot air in front of the object. This is what causes the surface of a meteor to melt.
You're right on the money :)
I was lucky enough to be in the last class that Pheanis ever taught at ASU. CSE 521 during the spring of '04 - it was also my last semester at ASU.
CSE 225, 421, and 521 have been the most valuable classes that I've ever taken in college.
The word of the day is pedantic.
Thank you.
You really should comment every line of assembly, even when you just increment a register
;Load the AR with $10 ;Decrement the AR ;If the AR is not zero, branch back
;Initialize our counter (in the ;AR) with the value $10. W estart ;the loop, decrementing the ;value in the AR until it ;reaches 0.
Rather than doing that, you should increment a block of assembly code. You almost have logical blocks of code that do something. Instead of commenting one instruction at a time, you should be commenting a block of code. Commenting it one line at a time is tedious as well, and doesn't really provide that much information:
1H LDAA =$10
DECA
BNE 1B
versus
1H LDAA =$10
DECA
BNE 1B
The second version is much better than the first. And also, saying "increment the AR" to an "INCA" instruction is not that helpful. Why am I incrementing it? What happens when I increment it? Too often I've seen useless comments like that.
Good comments should explain these areas:
a) What you're doing.
b) Why you're doing it.
c) How you're doing it.
I took three assembly programming classes in College. The last one was on the 68k, where we wrote an embedded OS.
Assembly code isn't all that intuitive, and writing comments is especially important. Our professor allocated 20% of our grade on each lab to comments. In addition to accurately describing what we were doing, he checked our grammar. One thing he always stressed is that too many engineers these days don't know how to write comments. Grammar is important in getting the message across unambiguously.
In general, if a person can read your comment and then figure out how to translate what you said into code, then your comment is pretty good. It should give an idea of what you're trying to do, why you're doing it, and how you're doing it.
One of my professor's grad students translated a program from MACRO32 into C++, and all without even knowing MACRO32. He looked through the comments to figure out what they were doing. They were so specific that he could easily translate blocks of code over to C++.
Comments are very important - and I should definitely comment MY code. I can't remember the number of times I've come back to code that I've written and thought "WTF am I doing here? WTF was I smoking when I wrote this?!"
Ok, that makes it a bit clearer.
:)
I tend to be paranoid, which is why I stick with serving XHTML as application/xhtml+xml. I'm well aware that you can server XHTML as text/xhtml and it can render fine - but I am still of the impression that it opens up a lot of pitfalls.
I didn't mean to imply that you personally don't know what you are doing, and that is why it's a bad practice.
My argument is based on the fact that you see so many poorly written pages, and that it would probably serve those people better if they know what they were doing - and that's I think setting the write content-type matters. Because you can do many things wrong when you serve XHTML as text/html, and then these mistakes will come to haunt you when you serve it as application/xhtml+xml.
I also know that XHTML doesn't turn into Tag Soup, but the browser tends to read it as such, when it really doesn't have to. And since, Tag Soup is given such a wide latitude, errors can creep in that normally wouldn't be rendered if it was served up as application/xhtml+xml. Why parse XHTML with the Tag Soup parse instead of the XML parser?
I guess we are both misreading the arguments here. I do not mean that:
a) The XHTML becomes invalid when served up as text/html
b) The XHTML is "bad" or "changed" or turns into Tag Soup.
c) The XHTML is worse than XHTML served up as application/xhtml+xml
but what I do mean is that
a) The XHTML will probably be parsed by the Tag Soup parser instead of the XML parser.
b) Since Tag Soup is allowed a wider latitude, you may have malformed code that still renders.
c) Serving XHTML as text/html is risky - but provided you know the risks, there is no reason not to do it, however, I personally like to play it safe.
d) Since it's XHTML, why not just serve it as application/xhtml+xml (in supporting browsers)?
Anyway, I'm glad I'm having a fruitful discussion on this.
Take a look here.
Also, take a look here for some information on sending IE into quirks mode. I was mistaken though, it is the DOCTYPE that sends the browser into quirks mode, not the content-type.
According to W3C specifications, sending XHTML 1.1 strict as text/html is invalid. Sending XHTML 1.0 strict as text/html would make the browser read it as tag soup, which is not what you want to do:
"How XHTML affects tag soup
XHTML is a reformulation of the HTML language based on XML. The XML Specification clearly defines what a conforming user agent (such as a web browser) must do when malformed code is encountered. Thus, a browser interpreting a Web page as XHTML will refuse to display the page if it encounters a well-formedness error, ensuring that future XHTML will not be tag soup.
However, XHTML 1.0 states that XHTML may be interpreted by current Web browsers as HTML if it follows a set of compatibility guidelines defined in Appendix C of the XHTML 1.0 Recommendation. At this time, the popular web browser Internet Explorer is unable to interpret XHTML documents as XML, and thus most current XHTML pages are served to browsers as HTML, using the MIME type of "text/html".
Because XHTML 1.0 served to browsers as HTML is parsed as if it were badly-formed HTML, XHTML 1.0 is affected by tag soup in the same way as HTML.
Future versions of XHTML after version 1.0 do not allow the XHTML to be served to browsers as HTML. If implemented according to the recommendation, this should prevent the problem of tag soup once XHTML served as XHTML is supported by all major browsers."
Source
I am not saying that serving up the content as text/html changes it from XHTML to HTML, but it will affect the rendering of the page - and it may not work the way you expect it to. That is why it is a bad practice. The W3C recommends that you serve XHTML documents as they are supposed to be served up: application/xml+xhtml.
Here is also a page that talks about why serving XHTML as text/html is considered harmful.
I'm also not saying that you can't serve up XHTML as text/html, just that it's probably not a good idea, and that it could cause problems later.
Thanks for the explanation of invalid vs. malformed.
Mozilla lets you use innerHTML in an XHTML document, so long as it's served as text/html. And ignore the temptation to look trendy by saying it's not "real" XHTML. It's Mozilla's choice to treat it as HTML and not XHTML; it's fully conformant to spec. to serve (some) XHTML documents as text/html and interpret (some) text/html documents as XHTML. XHTML served as text/html is just as real and valid as any other type of XHTML.
l dNodes[i], true));
I would tend to disagree. While it may work, it's not a good practice. XHTML is not HTML. I don't see how you can say that you can serve XHTML up as text/html, when XHTML is clearly XML and not the same as HTML. The reason it is not a good practice is because if you send an XHTML document as text/html, the browser interprets it as HTML and not XHTML. I'm not trying to look trendy by saying it's not "real" XHTML, but it isn't. I know that you can insert HTML into an XHTML document using innerHTML - but, if you serve it up as application/xml+xhtml (which is how XHTML should be served, because it isn't the same as text/html), then Firefox won't allow you to do it. Furthermore, serving up XHTML documents as text/html puts the browser into quirks mode, and treats it as tag soup and NOT XHTML.
No, that's malformed XHTML. That's a different thing to invalid XHTML. Invalid XHTML can display just fine in Mozilla, even when you serve it as application/xhtml+xml.
Well, what I meant was malformed then. I am not sure what the difference is between invalid and malformed - do you mean unsupported tags?
There's nothing about innerHTML that makes it incompatible with XHTML. Sure, you can call it with text that would produce malformed XHTML, but the browser can just throw an exception in those cases.
Which is why I said that your solution is fine - I would ideally like something like that instead of having to parse the XML and insert it into the DOM tree, and catch the exception. innerHTML isn't part of the W3C spec either, which is also a problem.
You can try the following, it will work well:
function insertXHTML(myXHTML, myObject)
{
var parser = new DOMParser();
var XMLdoc = parser.parseFromString("<div xmlns = \"http://www.w3.org/1999/xhtml\">" + comment + "</div>", "application/xhtml+xml");
var root = XMLdoc.documentElement;
for(i = 0; i < root.childNodes.length; i++)
{
myObject.appendChild(document.importNode(root.chi
}
}
I think you missed out a bit of your sample code, but in any case, are you aware of DOM3LS? You can do XML serialisation with that.
I haven't looked at that, it does sound pretty interesting. Also, you can use XSLT to translate server-side data into XML/XHTML and then insert that into the DOM - pretty useful.
I know that firefox won't allow you to add innerHTML to an XHTML document.
//not sure if this is valid exception handling in JS, but you get the idea.
O'm not sure I follow. Without "innerHTML", I can't add badly formed xhtml into my document? That's funny, I do it all the time.
Sure, you CAN insert bad XHTML into a document, but then the entire document will not be valid XHTML. I'm sure you know that if you try to load up an invalid XHTML document in Firefox (that is, if you have set the content-type and DTD correctly) it will show up as a parse error. I'm not sure what else you use to try and insert XHTML/HTML into an existing document. You could use the createElementNS function, but that will create valid XHTML as well. innerHTML is not the way to go for XHTML because XHTML is not HTML and you simply don't want to easily insert something that will break the page.
Your solution is possible if there a behind the scenes check for valid XHTML. So for example:
try
{
obj.innerXML = str;
}
catch(Exception e)
{
alert("invalid XHTML");
}
In my solution, you use the XMLParse object. You provide it some XHTML to parse and it will let you know if it is valid or invalid XHTML. And using the importNode function, you don't have to recursively create the DOM tree.
Righto. Also, the W3C doesn't support the innerHTML property.
innerHTML is the wrong way to go, especially in XHTML documents. That's because you can potentially insert badly formed XHTML into the document.
There is, however, a way to do it. I figured it out while trying to make my site XHTML valid. I've written about it on my website. Please note that the site is currently down (problems with my ISP) but it should be back up soon today. Basically it involves parsing the code with the XML parser, and then importing the node into the DOM. My initial solution involved walking the parsed tree (which was a little more involved and longer/complicated). However, you can use the importNode function instead and just import the entire parsed DOM tree into the main document's tree. It works pretty well and ensures that the inserted code is valid XHTML.
I know that it's the "in" thing to bash Microsoft and sometimes Intel.
It's easy to say they are strong-arming and that they are being anti-competitive.
AMD has a history of filling suits against intel. They did it in Japan, and they did it in Europe
The issue here is not whether AMD's processors are "better". I see a lot of arguments like "Man my AMD si teh rox0rz and it runs so much cooler (in all senses) than Intel!" - so WHAT? What does it have to do with this issue at all?
AMD has historically been unable to meet demand. If you were a PC company would you go with a supplier that doesn't meet demand, or one that does?
AMD is a profitable company - and they directly compete with Intel. This IS competition, there is a winner and there is a loser. Someone is always going to be on top. There is a fine-line between losing a competition and being forced out of it.
Intel returns X dollars in advertising money (advertising that will be used for Intel as well - like the Intel inside logo) to customers who make kits with Intel products - that's an incentive - that's not strong-arming, that's good marketing. There isn't anything stopping AMD from doing the same.
I know it's the tradition here to root for the (perceived) underdog and that I'm probably going to burn Karma for this, but this are my 2c's.
Yep. And the reason that they don't get brain damaged is because their neurons aren't dying. And their neurons aren't dying because they're not metabolizing, and thus needing oxygen. The brain is in hibernation, just like the rest of the body.
So is there a temperature limit for metabolizing?
Cell death is of two kinds - apoptosis or necrosis. Apoptosis is programmed cell death (when the lysosomes break), whereas necrosis is due to cell damage - and in this case, lack of oxygen. Cells that die due to necrosis show a lower level of ATP - so it makes sense that the cell was trying to metabolize the remaining oxygen and ran out.
From here, you can see that the increase in Ca2+ ions leads to chain of events that eventually leads to necrosis. Ca2+ ions over a certain threshold inhibits the energy and respiratory processes. I guess the question is, what is stopping the neuron from trying to metabolize?
What I'm assuming is that it takes longer for the blood in the body to cool down, during which time the neurons can continue metabolizing. But when the temperature is suddenly lowered to 7C, metabolysis stops? But we couldn't just quickly lower the temperature of the body to 7C because it would take > 5 min for the blood to cool.
I'll bite, but just because it will be informative for those who don't know.
/dev/adX (X being an number). There are slices (partitions) on each drive, so you can have /dev/adXsY (Y being a number). Slices are like Microsoft-style (FAT/NTFS) partitions. In addition to the slices, you have a partitions within that slice, so /dev/adXsYZ (Z being a lowercase letter).
FreeBSD does have a system. Hard-Drives are
There is a convention to the letters:
a = root
b = swap
c = whole disk
d = obselete whole disk
e-h = everything else
So, ad0s1a is the root partition on disk 1, slice 1. It's not "unstandardized". Other devices have their own conventions too. It's not that hard. Anyone with a little bit of intelligence can make sense of it.
Explanation of what "funky" means... The wave-functions of the particles start collapsing, essentially describing one giant particle. You are unable to distinguish one particle from the other, since they have the same wave-function - they collapse into the lowest possible quantum state.
I thought gasesous superfluids (Bose-Einstein Condensate) had already been created in 1995:
Bose-Einstein condensate is a gaseous superfluid phase formed by atoms cooled to temperatures very near to absolute zero. The first such condensate was produced by Eric Cornell and Carl Wieman in 1995 at the University of Colorado at Boulder, using a gas of rubidium atoms cooled to 170 nanokelvins (nK). Under such conditions, a large fraction of the atoms collapse into the lowest quantum state, producing a superfluid.
Wikipedia article
Is there anything else that the Homeowners can do? Any form of appeals or anything?
IANAL, and I don't know the system of appeals in the US Justice system really well - can anyone here explain?
Is there anything they can do, or are they SOL? Anyway that in the future they can bring this up for review by the Supreme Court again?
I guess you can owe that to some people being completely perplexed. This article doesn't talk about: a) Linux b) Microsoft c) Google d) Evil Patents e) MPAA/RIAA other evil organizations f) Something else that's geeky So they really don't know how to contribute... I mean... In Soviet Russia, IC invents Jack Kilby err... no wait.. In Korea only old people invent IC's... er no... This is FUD by microsoft! Because without IC's there would be no Microsoft!! Er no... This hows HOW MUCH LINUX r0x0rz!!11! Because without IC's there would be no linux!! Uh no... AHHH!!! I CAN'T TAKE IT ANYMORE! **CORE DUMPED***
One of the very few men, in all of mankind's history who's influence is everywhere. Without him, our world would have been a lot different. God rest his soul. And lest I offend the athiests ;), may his recycled remains find use in some noble purpose.
It is amazing how such a small invention has given rise to what we see today.
Even some open source software runs so poorly on BSD that it's not worth using -- like MySQL
Not worth using? I've been using FreeBSD with Apache, MySQL and PHP on my webserver without any problems.
At a job I held in college, I set up a network with FreeBSD and a database-driver website that used PHP+MySQL. This website received significant amount of traffic and ran without any problems.
*Some* software may run poorly, but MySQL is not one of them. It may not run as well on *BSD as on Linux, but it does run (and runs pretty well on some *BSD's).
Check this out.
It all comes down to what you want... if you want a good server, then maybe you want FreeBSD.
But in general, I agree with your point - Linux is much more widely used and hence has better support as a general purpose OS.
Congratulations to the PHP team!
I've only been using FreeBSD since '02. But I've grown to like it very much and I exclusively use it for server-side webdevelopment.
I had an internship during my junior and senior years of college where they wanted me to maintain a series of webpages that ran in Coldfusion. I got them to change it around to PHP.
The only thing that bugs me about PHP is the exception handling, but I hear that it's getting better. PHP does things far better than Coldfusion (yuck), and it's easier than doing [Perl] CGI (IMHO - although I love perl). The popularity, I think, is due to ease with which one can pick it up, and also its similarity to other languages like C and Perl. And then there's the fact that it can interact with a wide variety of databases.
The LAMP solution works really well, although I use FAMP (FreeBSD, Apache, MySQL, PHP), which works equally well.
I meant "exponentiation becomes multiplication".
I have to agree with the parent. Calculators are useful, but they can quite easily also turn into a crutch.
.3010, .4771, .6020, .6989... and no, I didn't look those up in a calculator :).
I studied in the Indian CBSE and AISSE system of education. We weren't allowed any calculators at all, for any subject. We had to use Log (logarithm) tables. Essentially we would convert any problem into base 10 log and then solve it from there. It was supposed to be "easier" because multiplication and division change into addition and subtraction. Exponentiation just becomes division.
Sure, I hated it at the time. It was a total bitch to do anything, but as a result, I got really good at my arithmetic. Even today I can remember the log base 10 values for 2, 3, 4, and 5...
Even in university, I had friends who had the TI-92 which could do symbolic integration. I had a lowly Casio model. I didn't mind, because I understood calculus and did everything by hand.
Basically, learning to do things by hand is a good skill to have. So you don't rely on a calculator where things happen "magically". Of course, when there's a time crunch, a powerful calculator helps, but it's still nice to know how things work under the hood.
hey anybady got teh torrent for this plz i relly need it thx!11! *ducks ;)
Ahhh I can see it now... a new Star Trek Episode.
Dr. Crusher: Jean-Luc, Wesley has a tumor.
Capt. Picard: A tumor? Wesley? Well Doctor, I suppose you have to operate.
*Flash of Light, Q appears*
Q: Bonjour Mon Capitain!
Capt. Picard: Q! Is this your doing? Are you the one that gave Wesley canceh?
Q: Cancer! You humans are sooo arrogant! Why, haven't you ever thought of what cancer could be? It could be a new life form - look at the way it GROWS!
Capt. Picard: You have a point Q... Dr. Crusher, we can't operate. We have to let the boy die. Ask Geordi and Data to figure out a way to communicate with this new life form.
I think you just described Battlestar Galactica...