Set simulation time dialog crash

[DAllen]

If you accelerate the time to much then try to rest it, it can crash. My guess is when set time dialog box loads it?€™s trying to fill the controls with the simulation time, but its to far out of bounds, and causes a crash.

Not sure how this happens but the crash occurs when the date in the upper right hand corner has negative numbers in it???

[t00fri]

If you accelerate the time too much then try to rest it, it can crash. My guess is when set time dialog box loads it?€™s trying to fill the controls with the simulation time, but its to far out of bounds, and causes a crash.

Not sure how this happens but the crash occurs when the date in the upper right hand corner has negative numbers in it???

Celestia assumes users to apply a certain amount of common sense when playing with the controls

Bye Fridger

[selden]

Even so, a program shouldn't crash because of user "error". Date wrap-around probably would be more reasonable (and may be what's having problems).

[DAllen]

Common sense is for suckers. I should be a professional beta tester, if theirs away to make a program crash I can find it.

[t00fri]

Common sense is for suckers. I should be a professional beta tester, if theirs away to make a program crash I can find it.

Selden,

could you please explain to me what a "sucker" is? I am interested, since I do usually make use of my common sense . In a wider sense, I am even paid for applying my common sense...

Is a sucker less of an offense than a loser?

Incidentally, I claim I can crash any of the standard commercial programs with stupid control action via buffer overflows. Like Photoshop (proven) or Word and
...

As a theoretical physicist, I would say that people who
increase the time or acceleration to values where even children of average intelligence would claim breakdown of knowledge, just deserve the crash they are provoking

Bye Fridger

[selden]

Fridger,

Indeed, in this context the word is not appropriate.

DAllen, please edit your message to avoid its use. (If you don't I'll have to delete the posting.)

On this forum, we do not appreciate people making fun of or putting down others, even when it's not intended seriously.

[chris]

DAllen, please edit your message to avoid its use. (If you don't I'll have to delete the posting.)

On this forum, we do not appreciate people making fun of or putting down others, even when it's not intended seriously.

I honestly don't think any offense was intended. But whatever . . . we really should do something about time overflow in Celestia. It shouldn't be that easy to crash the program.

--Chris

[selden]

Chris,

I'm sure the insult wasn't intended seriously, but it's easy to offend people unintentionally and unnecessarily.

[Clorox]

My computer doesn't crash, just Iapetus gets ejected from orbit.

[Cham]

Celestia MUST be "idiot safe". I'm using Celestia in the classroom, with 40 students playing with it and making all sorts of stupid mistakes, which can't be prevented nor predicted. After only few weeks of use, I already saw LOTS of amazingly stupid things from them. The program was installed on 24 old PCs and was overcharged with tons of addons.

One of those mistakes the students are doing ALL the time, is to run time at a very fast rate until they get in year 502456 (random date) !

Sorry Fridger, there is NO common sense in the real world, and Celestia must prevent nonsense to crash it.

[Joe]

Celestia assumes users to apply a certain amount of common sense when playing with the controls

Fridger

I feel you are a bit over defensive about 'bugs' . What common sense a user can apply to avoid them?
If someone tumbles on something that is allegedly a bug and reports it, it should be welcomed, investigated and eliminated to make Celestia better and robust, that is one of the points of OpenSource, it is?

Bugs, real or not, cannot be ignored or denied without looking into the code. Some bugs reported long time ago in this forum are still there like:

http://www.shatters.net/forum/viewtopic.php?t=9865

where it is a fatal bug. Luckly it is not sitting in a main running pass, otherwise it will cause a dead loop. As a common programming practice, one should not do a comparison between two double or float values like this

Code: Select all

if (getVelocity() != targetVelocity)

[osx-vip]

If you accelerate the time to much then try to rest it, it can crash. My guess is when set time dialog box loads it?€™s trying to fill the controls with the simulation time, but its to far out of bounds, and causes a crash.

Not sure how this happens but the crash occurs when the date in the upper right hand corner has negative numbers in it???

Beside me such problem!
_____________________________________________________________

[LordFerret]

... make a program crash I can find it.

Used to be my job.


I'm not quite understanding the action here. You have time greatly accelerated, and while still accelerated you're trying to reset date/time?

I'm running v1.4.1, and I frequently upon finding binary systems speed up time to observe their motion. Quite often I've run the date/time range out to immense stretches, but I've never created a crash doing so... then again, before setting date/time back to "now", I set Celestia back to "normal". If that helps any.

[Malenfant]

Like Joe said, a bug is a bug - assuming that users will use a program in a vaguely-defined "common sense" way is no excuse for leaving it there.

And more often than not, a likelihood that a bug will show up has nothing to do with the assumed intelligence of the users. It doesn't matter who reports it or how it's found or how obvious or hidden it is, the bug still needs to be dealt with.

Meanwhile I think if we are going to be forced to refrain from harmless colloquialisms for fear of offending some hypersensitive reader then things are getting a bit ridiculous. This is the internet, you need a much thicker skin than that to survive here, and we shouldn't have to walk on eggshells to write posts.

[hank]

Like Joe said, a bug is a bug...

Sure. But there are bugs and there are bugs. Not all bugs have equal importance. Developer resources are limited, so bug fixes must be prioritized. Bugs that aren't likely to occcur in normal use are generally less urgent than those that are.

Meanwhile I think if we are going to be forced to refrain from harmless colloquialisms for fear of offending some hypersensitive reader then things are getting a bit ridiculous. This is the internet, you need a much thicker skin than that to survive here, and we shouldn't have to walk on eggshells to write posts.

I agree with you on that.

- Hank

[BrainDead]

Is a sucker less of an offense than a loser?

As a theoretical physicist, I would say that people who
increase the time or acceleration to values where even children of average intelligence would claim breakdown of knowledge, just deserve the crash they are provoking

I LOVE ya Doc...

Please keep your insights coming. So refreshing to hear an honest opinion
in an otherwise political universe.

[Malenfant]

Is a sucker less of an offense than a loser?

As a theoretical physicist, I would say that people who
increase the time or acceleration to values where even children of average intelligence would claim breakdown of knowledge, just deserve the crash they are provoking

I LOVE ya Doc...

Please keep your insights coming. So refreshing to hear an honest opinion
in an otherwise political universe.

I don't think that sort of thing should be encouraged at all.

Fact is, someone reported a valid bug - the program shouldn't be crashing when set to fast speed. Maybe it's not an "important" bug (though even Chris said that something should be done about it), but making snarky remarks at people who report them isn't remotely constructive, and just implies that developers aren't taking bug reports as seriously as they should. And if people who are using this program are going to get sanctimonious responses like that (from anybody), then they're not exactly going to be encouraged to report any more.

[t00fri]

While I always appreciate Malenfant's "corrective actions" , my above remark actually had a (semi-)serious content. Certainly more serious than what Malenfants critique implied.

The above bug, in fact, is known to me since > 3 years and I bet to a number of other devs, too... So why is it still there??

In case of Celestia we often have to cope with 2 formally unrelated aspects when attempting to block-off such kinds of "bugs".

i) astrophysics/cosmology: That's the hard part in the present case! Obviously there should be a sensible limit for the acceleration, which is particularly hard to implement into Celestia as it is at present. The reason is that Celestia's underlying framework is (still) unable to cope with cosmological time and space scales!

Obviously the values that were used to provoke the crash were VERY deep in the cosmological regime

ii) coding: that's trivial, just limit the max value by something that still does not yet produce the crash (the origin of which is quite obvious).

+++++++++++++++++++++++
The catch is that merely implementing the fix according to ii), the overall situation in a sense agravates!
+++++++++++++++++++++++

People without much science background can now dial such non-sensical acceleration without experiencing a crash, which until the fix acted at least as kind of an "emergency break", indicating drastically (crash) that people are moving in a physically nonsensical regime...

I hope that my explanation illustrates that my above remark involved quite a bit more previous reflection about this long familiar problem, than suggested by Malenfant's reply...

[Malenfant]

So this has actually been fixed in the latest code now?

[Christophe]

So this has actually been fixed in the latest code now?

Yes! Well, at least it doesn't crash anymore. What is displayed however remains bogus.