First of all, I'm sure the OOo developers would LOVE to follow the Word format correctly. That is, if it were a standard format, which it isn't, or if it were documented at all, which it isn't.
Secondly, let's assume just for the sake of argument that you had full access to all required documentation, had direct access to the internal MS code that reads/writes the files, and access to the developers who designed the file spec in the first place. Given that, you should be able to create a pretty good import/export tool, no?
So Microsoft shouldn't have any problems with their own format, right? After all, it can't be that tricky, and they DO have all of the advantages listed above.
Ah, but have you ever tried to import older Word documents into the most recent version of Word? Or even worse, to try to save a newer Word file in an older file format? It doesn't usually crash, but the translation makes OOo's Word export look pretty good.
Now, I realize that I haven't directly answered your question. All that the above is trying to do is convey the underlying complexity of the problem, and the fact that MS itself can't even get it right.
To address the specific issue of broken compatability: Given that MS makes a great deal (most?) of its money from lock-in to its proprietary formats, I would say that they have a vested interest in protecting their monopoly, no?
Of course it isn't proveable (think anti-trust ramifications here), but would it not be convenient, given this vast complexity of code, if some change just so happened to break compatability with a competitor?
Especially when you realize that when MS-Word imports older documents (even from previous versions of MS-Word), they get run through an intermediate converter that changes them to RTF, and then the RTF is imported.
You wouldn't expect the Word 97 -> RTF converter to need to change with each new release of Office, would you?
No, of course not. Not unless they were fixing a bug. And for a company where interoperability itself is a bug...
Re:A lot of stuff in Gtk is replacing Gnome widget
on
GTK 2.6.0 Released
·
· Score: 2, Informative
Actually, Gtk# originally started as a managed wrapper just for GTK+ (hence the name), but has since grown to include the rest of the Gnome libraries (gnomeui, pango, etc) as well.
The fact that they haven't changed the name is misleading, but all the base GNOME libraries are available.
FC2 contained a number of open-source Java packages that can run with gcc-java.
These packages included (as an example): ant, tomcat and many of the Jakarta-commons libraries. As these do not require AWT or Swing to run, they will run fine with gcc-java.
I miss having those libraries as part of the distribution, but in this case I think it may have been a wise choice. The gcc-java setup is immature, the jikes compiler isn't up to snuff. Maybe RH decided that it was better to ship nothing at all than to ship substandard packages.
No offense to the gcc-java or jikes fellows.
Re:Why I think Kerry is a worse choice than Bush
on
Pre-Election Discussion
·
· Score: 2, Insightful
How is it that a comment where somebody expresses several positions, backed up by relevent examples, not modded up at all?
And this comment, which instead of real content carries just a snide remark, gets modded "5, Insightful"?
I don't care which side you believe in, this thread (and its modding) is an example of blind partisanship. The only reason this post was modded 'insightful' is because most of us happen to agree with the author. But try to compare this post and its parent without letting petty political bigotry interfere, and it is abundantly clear that the parent post, even if we disagree, is more insightful than this. And we wonder why the level of political debate in this country has dwindled from the 'Federalist Papers' down to the 'sound bite'. Those involved should be ashamed of themselves!
The last link there deals with actions the United States took during the cold war to help overturn the democratically elected government of Iran and reinstate the Shah.
Although not necessarily a fan of the Bush administration, I think that in fairness it should be noted that just a couple of days ago in his address to the UN, President Bush acknowledged this mistake and said it was the wrong.
"... For too long, many nations, including my own, tolerated, even excused, oppression in the Middle East in the name of stability. Oppression became common, but stability never arrived. We must take a different approach."
I've been asked to give hour-long presentations to groups of 12 & 13-year olds, so I've asked myself the same question.
I ended up coming up with this basic outline:
1. The processor. At the core, a computer is very simple. It can:
* add two numbers, subtract two numbers,
* write a number down and read it back in,
* a couple more similarly simple things.
2. History. The first computers in the 1940's and 50's filled large rooms, used rotating steel drums to write numbers on and read them from, and could only communicate by punching holes in pieces of paper.
3. Nowadays the ideas are basically the same, but we use tiny chips to write numbers on, and can communicate with the computer using a keyboard, mouse and monitor.
4. At this point my presentation would give some brief examples in pseudo-assembly of how to program a computer-- basically how to script the adds, subtracts, and so forth. But in 10 minutes you probably wouldn't have time for that.
Much has been said about how this article makes claims and backs them up with nothing. So I decided to run some benchmarks of my own. Tested on both uniprocessor and SMP, with a bunch of different code paths, using the very latest JVM.
I tested the assertion that synchronization isn't all that slow. First, I started by writing a simple test that goes into a loop and does enough work to not be optimized away by the compiler, but no more. This test showed synchronization to be about 200 times slower on SMP and between 50-100 times slower on uniprocessor.
But, as the author states in the article, that's a contrived benchmark, so I won't bore you with the details. He claims that synchronization only adds constant-time overhead to a function, so that in any 'real world' function that does 'real work' the performance difference will be small.
Fine, I'm willing to consider that. So I rewrote the test so that each method invocation allocated a 1024-byte buffer, wrote data to the buffer one byte at a time, allocates a new String, parses the byte-buffer to Unicode, and calculates the hashCode of the resulting String. That's heavier than most of the methods I write day-to-day, so let's see how bad the synchronization overhead is?
On a dual-processor PIII-1266Mhz with 1G RAM and the latest (1.4.1_02) JVM with default settings:
10,000 iterations nonsynchronized: 0.67 seconds
10,000 iterations synchronized: 1.47 seconds
So even in functions that perform 'real work', synchronization REALLY IS expensive. More than the rest of the method, which is a fair amount.
Where does this guy get off claiming that slow synchronization is an Urban Myth when anybody with a decent grasp of the language and willing to invest a few hours running tests can prove him wrong?
Source code for the test can be found at: http://www.lewisworld.org/~mark/Test.java
They list the required browsers at the bottom of the FAQ as Netscape Navigator 4.7x and up on the Mac or Netscape Navigator 5.x on Windows.
I'd be curious to know exactly how many users of Netscape Navigator 5.x there actually are in the world, since they never released one.
Slashdot Mirror
First of all, I'm sure the OOo developers would LOVE to follow the Word format correctly. That is, if it were a standard format, which it isn't, or if it were documented at all, which it isn't.
...
Secondly, let's assume just for the sake of argument that you had full access to all required documentation, had direct access to the internal MS code that reads/writes the files, and access to the developers who designed the file spec in the first place. Given that, you should be able to create a pretty good import/export tool, no?
So Microsoft shouldn't have any problems with their own format, right? After all, it can't be that tricky, and they DO have all of the advantages listed above.
Ah, but have you ever tried to import older Word documents into the most recent version of Word? Or even worse, to try to save a newer Word file in an older file format? It doesn't usually crash, but the translation makes OOo's Word export look pretty good.
Now, I realize that I haven't directly answered your question. All that the above is trying to do is convey the underlying complexity of the problem, and the fact that MS itself can't even get it right.
To address the specific issue of broken compatability: Given that MS makes a great deal (most?) of its money from lock-in to its proprietary formats, I would say that they have a vested interest in protecting their monopoly, no?
Of course it isn't proveable (think anti-trust ramifications here), but would it not be convenient, given this vast complexity of code, if some change just so happened to break compatability with a competitor?
Especially when you realize that when MS-Word imports older documents (even from previous versions of MS-Word), they get run through an intermediate converter that changes them to RTF, and then the RTF is imported.
You wouldn't expect the Word 97 -> RTF converter to need to change with each new release of Office, would you?
No, of course not. Not unless they were fixing a bug. And for a company where interoperability itself is a bug
Actually, Gtk# originally started as a managed wrapper just for GTK+ (hence the name), but has since grown to include the rest of the Gnome libraries (gnomeui, pango, etc) as well.
The fact that they haven't changed the name is misleading, but all the base GNOME libraries are available.
Maybe I didn't fully understand your question, so please correct me if I am mistaken.
But what about popular C/C++ IDE's as KDevelop and Anjuta? Are those not the sort of tools you're looking for?
FC2 contained a number of open-source Java packages that can run with gcc-java.
These packages included (as an example): ant, tomcat and many of the Jakarta-commons libraries. As these do not require AWT or Swing to run, they will run fine with gcc-java.
I miss having those libraries as part of the distribution, but in this case I think it may have been a wise choice. The gcc-java setup is immature, the jikes compiler isn't up to snuff. Maybe RH decided that it was better to ship nothing at all than to ship substandard packages.
No offense to the gcc-java or jikes fellows.
How is it that a comment where somebody expresses several positions, backed up by relevent examples, not modded up at all?
And this comment, which instead of real content carries just a snide remark, gets modded "5, Insightful"?
I don't care which side you believe in, this thread (and its modding) is an example of blind partisanship. The only reason this post was modded 'insightful' is because most of us happen to agree with the author. But try to compare this post and its parent without letting petty political bigotry interfere, and it is abundantly clear that the parent post, even if we disagree, is more insightful than this. And we wonder why the level of political debate in this country has dwindled from the 'Federalist Papers' down to the 'sound bite'. Those involved should be ashamed of themselves!
The last link there deals with actions the United States took during the cold war to help overturn the democratically elected government of Iran and reinstate the Shah.
Although not necessarily a fan of the Bush administration, I think that in fairness it should be noted that just a couple of days ago in his address to the UN, President Bush acknowledged this mistake and said it was the wrong.
Complete text of the address is here.
The relevent quote:
I've been asked to give hour-long presentations to groups of 12 & 13-year olds, so I've asked myself the same question.
I ended up coming up with this basic outline:
1. The processor. At the core, a computer is very simple. It can:
* add two numbers, subtract two numbers,
* write a number down and read it back in,
* a couple more similarly simple things.
2. History. The first computers in the 1940's and 50's filled large rooms, used rotating steel drums to write numbers on and read them from, and could only communicate by punching holes in pieces of paper.
3. Nowadays the ideas are basically the same, but we use tiny chips to write numbers on, and can communicate with the computer using a keyboard, mouse and monitor.
4. At this point my presentation would give some brief examples in pseudo-assembly of how to program a computer-- basically how to script the adds, subtracts, and so forth. But in 10 minutes you probably wouldn't have time for that.
-- Mark
Much has been said about how this article makes claims and backs them up with nothing. So I decided to run some benchmarks of my own. Tested on both uniprocessor and SMP, with a bunch of different code paths, using the very latest JVM.
I tested the assertion that synchronization isn't all that slow. First, I started by writing a simple test that goes into a loop and does enough work to not be optimized away by the compiler, but no more. This test showed synchronization to be about 200 times slower on SMP and between 50-100 times slower on uniprocessor.
But, as the author states in the article, that's a contrived benchmark, so I won't bore you with the details. He claims that synchronization only adds constant-time overhead to a function, so that in any 'real world' function that does 'real work' the performance difference will be small.
Fine, I'm willing to consider that. So I rewrote the test so that each method invocation allocated a 1024-byte buffer, wrote data to the buffer one byte at a time, allocates a new String, parses the byte-buffer to Unicode, and calculates the hashCode of the resulting String. That's heavier than most of the methods I write day-to-day, so let's see how bad the synchronization overhead is?
On a dual-processor PIII-1266Mhz with 1G RAM and the latest (1.4.1_02) JVM with default settings:
10,000 iterations nonsynchronized:
0.67 seconds
10,000 iterations synchronized:
1.47 seconds
So even in functions that perform 'real work', synchronization REALLY IS expensive. More than the rest of the method, which is a fair amount.
Where does this guy get off claiming that slow synchronization is an Urban Myth when anybody with a decent grasp of the language and willing to invest a few hours running tests can prove him wrong?
Source code for the test can be found at:
http://www.lewisworld.org/~mark/Test.java
They list the required browsers at the bottom of the FAQ as Netscape Navigator 4.7x and up on the Mac or Netscape Navigator 5.x on Windows. I'd be curious to know exactly how many users of Netscape Navigator 5.x there actually are in the world, since they never released one.