Oh are you talking about a kind of binary search for the bug? That works pretty well (for bugs that aren't intermittent) but that still requires you to re-run the program log(n) times from the beginning. At least this one only requires you to re-run it log(n) times from the last checkpoint. From that point of view, it doesn't sound very revolutionary.
The real revolutionary part is if it's somuch faster than re-running the program from the start that you can forget about the binary search and just effectively run the program backward until you see exactly where the bug happened. They claim that this is the case.
Sorry, I didn't mean to attack you. To say that you don't encounter hard bugs was not meant as a personal insult. But what is there to say? If most of your bugs have an execution history that is captured on the call stack, then most of your bugs are pretty simple.
For instance, all it takes is for an object to get corrupted by one function, then that function returns, and now your call stack can't tell you where the corruption occurred.
There are many types of calculations out there (think The Game of Life or other CAs) that by their nature cannot be reversed, so all of those states would have to be stored or it would be mathematically impossible to calculate the reverse steps.
They take periodic system checkpoints and then work forward to the instruction preceeding the one you started from. There's no reason the Game of Life wouldn't be amenable to this.
Why yes, it IS a giant waste of space to represent an 8-bit value in a 16-bit quantity. But someone thought it was a good idea to leave out unsigned.
Are you talking about Java? I think JVMs allocate 32 bits for all fields (even a boolean) anyway, so there is no difference between byte and short (unless you're talking about arrays).
It's a vicious cycle. JVM developers say "nobody uses bytes or shorts anyway so we're not going to put a lot of effort into object layout optimizations that don't buy us anything". Then Java developers say "changing this int into a short doesn't make the object any smaller, so I might as well use the int for everything and not worry about overflow".
Others have said why comments are important, so I'll just say this: if someone says "you can tell a great deal about the maturity of a programmer by the quantity, and quality, of comments" and you reply "nah, I don't think they're that important", what do you think that says about you?
I have a rule of thumb I use... For someone new to a project, it takes them about as long to get comfortable with existing code as it would have taken them to rewrite it. It has been remarkably accurate so far.
You are absolutely right. Use Wikipedia as a starting point for some hints, but if it's important, confirm everything you read there with reliable sources.
Incidentally... I work on a product where we use the same codebase on everything from handhelds to big servers, and I think it's a great idea. It forces us to keep things lean and mean.
I have yet to see any programming language that can capture design concepts. Eiffel is probably closest. For every other programming language, the design would have to go into comments.
Re:They don't understand licensing though
on
OGRE 1.0 Released
·
· Score: 1
Slashdot Mirror
Since it got all that market share in the last 12 months, smartass.
What if that GPL/BSD project is a replacement for Perforce?
Above post is a joke. Think about it.
The real revolutionary part is if it's somuch faster than re-running the program from the start that you can forget about the binary search and just effectively run the program backward until you see exactly where the bug happened. They claim that this is the case.
For instance, all it takes is for an object to get corrupted by one function, then that function returns, and now your call stack can't tell you where the corruption occurred.
Irony.
Then you haven't done any really challenging debugging yet.
Suits to coders: stop whining and work harder.
What are you talking about? That's not what the article says at all.
For the millionth time... Code, no matter how clearly written, can only tell you what it does. Comments tell you why.
It's a vicious cycle. JVM developers say "nobody uses bytes or shorts anyway so we're not going to put a lot of effort into object layout optimizations that don't buy us anything". Then Java developers say "changing this int into a short doesn't make the object any smaller, so I might as well use the int for everything and not worry about overflow".
Maybe embedded JVMs are different, I don't know.
Others have said why comments are important, so I'll just say this: if someone says "you can tell a great deal about the maturity of a programmer by the quantity, and quality, of comments" and you reply "nah, I don't think they're that important", what do you think that says about you?
I have a rule of thumb I use... For someone new to a project, it takes them about as long to get comfortable with existing code as it would have taken them to rewrite it. It has been remarkably accurate so far.
You are absolutely right. Use Wikipedia as a starting point for some hints, but if it's important, confirm everything you read there with reliable sources.
Incidentally... I work on a product where we use the same codebase on everything from handhelds to big servers, and I think it's a great idea. It forces us to keep things lean and mean.
Yep, you're right. I didn't grasp the context of Scarblac's comment before I replied to it.
It says "Please Login".
You seem to have missed the whole point of this accomplishment.
This one is presumably a real trailer.
In English, both "minimums" and "minima" are acceptable.
I have yet to see any programming language that can capture design concepts. Eiffel is probably closest. For every other programming language, the design would have to go into comments.
"failing to neglect"?
"Official definition of the meter"