Bug: Sansa e200V2 simulator ALT+F4 fails

[AlexP]

As a clue, check the manual before asking questions.

I checked the only manual I've found for the simulator, and it didn't answer. Perhaps because, as you say, it is only in the wiki (http://www.rockbox.org/wiki/UiSimulator), hence unofficial.

The sim for the most part works the same as Rockbox on a device, and so the manual for the most part applies to both.

if you're filing a bug report it should be against the most recent version possible.

I think you're mistaken. There is no such project requirement - see http://www.rockbox.org/wiki/FlySprayHowto .

And I am glad there is not - such a requirement would unduly hamper reporting.

There should be such a requirement there, it is commonly asked for - it wastes a huge amount of time investigating bug reports for bugs that have already been fixed.

[Llorean]

I was expecting a version number specific to the simulator, but if it is the same as Rockbox for device, fine.

It is. The simulators are build from the exact same source. A simulator for a target will only behave the same as the target if they have the exact same revision number, which tells they were built from the same revision of the code.

As a clue, check the manual before asking questions.

I checked the only manual I've found for the simulator, and it didn't answer. Perhaps because, as you say, it is only in the wiki (http://www.rockbox.org/wiki/UiSimulator), hence unofficial.

There is no separate manual for the simulator. Outside of the controls, everything within the simulator for a specific target should work as Rockbox does on that player, thus the player manual is what should be referenced for the simulator in almost all cases.

if you're filing a bug report it should be against the most recent version possible.

I think you're mistaken. There is no such project requirement - see http://www.rockbox.org/wiki/FlySprayHowto .

And I am glad there is not - such a requirement would unduly hamper reporting.

I note you're once more referencing the wiki. And suggesting I said it was required - "should be" is different from "must be" hence the difference in meaning of the words. Whether or not it's a requirement though, it makes sense that a several month old version that is 1000 revisions behind current SVN is out of date and missing many things.

It's not a requirement, but it's heavily suggested that reports be made against the most current revision possible (you'll notice that word choice was important too). This means, for example, that we expect you at least to make an attempt to not have reported against heavily outdated code. Reporting against completely random versions just fills the tracker with reports on things already fixed (because searching the tracker isn't enough - there isn't always a bug report for something) or on features that simply don't work the same way any more.

If you don't feel up to compiling the latest code, you can report bugs against a release version. But since the simulator is for development (either development of the manual, development of Rockbox, or development of WPSes) it's not unreasonable to expect people working with it to be using the most recent build (as there is no other truly relevant build of the sim than the most recent one for any of these purposes).

[chrisjj]

It's not a requirement

Thanks for the clarification.

but it's heavily suggested that reports be made against the most current revision possible

If that's true, don't you think it very odd there is not remotely any such mention in the FlySprayHowto ??

Reporting against completely random versions just fills the tracker with reports on things already fixed ).

Agreed. That's why I didn't.

If you don't feel up to compiling the latest code, you can report bugs against a release version.

Great. Now where does one find that version's simulator built for Windows? Thanks.

[Llorean]

If that's true, don't you think it very ofdd there is not remotely any such mention in the FlySprayHowto ??

It's a wiki page. Possibly some irate user who disagrees with it removed it? Possibly nobody thought to add it because "bug reports shouldn't be against outdated versions" seems the most blatantly obvious thing that nobody thought it needed to be explicit. Especially considering the version dropdown in Flyspray only allows you specific choices, and it's a clue when your version isn't one of those choices that it's the wrong one (something you ignored and just lied about there).

Great. Now where does one find that version's simulator built for Windows? Thanks.

One compiles it, as I said.

[AlexP]

but it's heavily suggested that reports be made against the most current revision possible

If that's true, don't you think it very ofdd there is not remotely any such mention in the FlySprayHowto ??

It is mentioned now.

[[Saint]]

IIUC there is only a *very* small change between 3.5 and 3.5.1 to cover an issue that (AFAIK) not everyone was experiencing anyway.

3.5 Simulator builds are available here

But, if one wants a build that is *absolutely* current SVN, then Llorean is indeed quite correct, you will need to compile it yourself.


[St.]

[Llorean]

Simulator builds based off the latest release version are still simply outdated simulator builds.

There is no released sim.

Basically, bug reports should be against one of two things - a binary we release or currently provide (such as bootloaders or rbutils or the most recent actual Rockbox releases), or the current state of SVN. At the moment, we don't provide simulator binaries, so the bug reports should be against the current code state. If simulator binaries start being provided, that situation may change.

That's basically my point - if you make a bug report against anything but that, it's almost certainly going to get a response "can you reproduce it with the current code" so you should just start from current anyway.

In this case, the problem isn't something that's likely to have been fixed because it's not something anyone's tried to address, but the issue is that reports should always try to meet those conditions because most times they're going to have to anyway.

There's still a question as to whether the current state will even be considered a bug - at the moment it certainly does what the programmers expected it to do, which would qualify relatively clearly as "not a bug" and since there's no documentation for or released sim, nothing is actually working incorrectly. It could easily be closed by a dev as "this is how it's expected to work, file a patch if you want to change it."


The 3.5 simulator is basically useful for building 3.5 compatible WPSes, and for checking things in the 3.5 manual (where they're applicable to a simulator).

[chrisjj]

Basically, bug reports should be against one of two things - a binary we release or currently provide (such as bootloaders or rbutils or the most recent actual Rockbox releases), or the current state of SVN.

How about making that official (somehow)?

At the moment, we don't provide simulator binaries

You don't. Others do.

That's basically my point - if you make a bug report against anything but that, it's almost certainly going to get a response "can you reproduce it with the current code"

I think you are mistaken. My reports have not.

There's still a question as to whether the current state will even be considered a bug - at the moment it certainly does what the programmers expected it to do, which would qualify relatively clearly as "not a bug"

That would be really stupid, because it would make it impossible for useful reporting to be made by anyone not having knowledge of what the programmer intended.

and since there's no documentation for or released sim

You just said the baseline reference was programmer intent. Now you're saying it is documentation??

Anyway you're mistaken. Sim has documentation: http://www.rockbox.org/wiki/UiSimulator .

[Llorean]

Again, the WIKI is not official documentation. You've been told this a few times, but continue to refer to is as something having documentation.

Someone other than Rockbox providing builds does not matter. There's hundreds of unsupported builds out there that we don't accept bug reports on, whether they're modified code or unmodified.


The manual documents programmer intent. If something matches the manual, it's working as intended. If something does not match the manual, it's not. If it crashes, corrupts data, or otherwise harms data or prevents itself from being used, it's not working as intended.

If you think it should to X but have no official documentation to back up that it should do X, then you should ask a developer of that part of it "is this how it's supposed to work" before deciding that your assumption about how it's supposed to work is right, and file a bug.

[chrisjj]

Again, the WIKI is not official documentation.

I didn't say it was.

Someone other than Rockbox providing builds does not matter.

"Other than Rockbox". What are you talking about?

The manual documents programmer intent.

Except where it doesn't - such as here.

you should ask a developer of that part of it "is this how it's supposed to work" before deciding that your assumption about how it's supposed to work is right, and file a bug.

I have made no assumption. The simulator has keys for Power and Close marked on the UI. That's self-documentation. These keys don't work.

[bluebrother]

At the moment, we don't provide simulator binaries

You don't. Others do.

This doesn't make use support binaries provided by others. This is open source, anyone can provide binaries on his own (given that he compiles with the license). However, as we have no control about such binaries why should we even want to support those? Most open source projects only provide source code, and don't support binaries at all.

The manual documents programmer intent.

Except where it doesn't - such as here.

I'm not sure if you're still discussing this stupid Alt-F4 thing but if you do please point me to where the manual tells that Alt-F4 quits the simulator. Besides, the simulator is basically a development tool and not an application we provide.

[chrisjj]

However, as we have no control about such binaries why should we even want to support those?

I don't see anyone suggesting you'd want to support binaries. Or for that matter you'd want to support the simulator at all. But since Rockbox Flyspray has a category for Simulator, I presume it is because the project wants to hear about simulator bugs that are found. If not, please do tell me what you think it is for.

I'm not sure if you're still discussing this stupid Alt-F4 thing but if you do please point me to where the manual tells that Alt-F4 quits the simulator.

Nowhere I can see. However, given that the manual is unofficial, what do you care?

[bluebrother]

However, as we have no control about such binaries why should we even want to support those?

I don't see anyone suggesting you'd want to support binaries. Or for that matter you'd want to support the simulator at all. But since Rockbox Flyspray has a category for Simulator, I presume it is because the project wants to hear about simulator bugs that are found. If not, please do tell me what you think it is for.

If there is a developer tool does it make sense to track issues with that tool even if it's not an end user tool or not?

I'm not sure if you're still discussing this stupid Alt-F4 thing but if you do please point me to where the manual tells that Alt-F4 quits the simulator.

Nowhere I can see. However, given that the manual is unofficial, what do you care?

The Rockbox manual is the official manual, and officially maintained and supported. Who said that the manual is unofficial?

[chrisjj]

If there is a developer tool does it make sense to track issues with that tool even if it's not an end user tool or not?

In my experience issues in any currently-used tool are worth tracking.

The Rockbox manual is the official manual, and officially maintained and supported. Who said that the manual is unofficial?

The Simulator manual (such as exists) is in the Wiki, and it has been said here that the wiki is unofficial.

[AlexP]

The Simulator manual (such as exists) is in the Wiki, and it has been said here that the wiki is unofficial.

There is only one manual - the manual.  Anything in the wiki isn't it.