#142818 - abszero - Sat Oct 13, 2007 10:56 pm
It seems like it would be helpful to have a stickied list of known issues in r20 for quick reference. All those things that one might assume would work but don't.
I'd start such a thread myself but it probably makes more sense for a mod to create/maintain it since I won't necessarily be around to update the first post with new gotchas all the time. Maybe a wiki or something would be a better solution for continuous updating but I don't have any experience in setting those up...
Anyways, a few off the top of my head are:
-rename (stdio.h) doesn't work
-time (time.h) doesn't work
-IPC->time is not updated with the current time by the default ARM7 code
-fseek (stdio.h) can and occasionally does call _FAT_seek_r (from libfat's fatfile.c) with an unchecked null pointer, resulting in crashes/exceptions
#142831 - Peter - Sun Oct 14, 2007 8:53 am
| abszero wrote: |
| It seems like it would be helpful to have a stickied list of known issues in r20 for quick reference. All those things that one might assume would work but don't. |
It make sense to post bugs into the devkitPro bug-tracker, wouldn't it?
devkitPro Bug Tracker
devkitPro Feature Requests
_________________
Kind Regards,
Peter
#142832 - NeX - Sun Oct 14, 2007 10:20 am
That sentence didn't make sense. :D
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.
#142841 - tepples - Sun Oct 14, 2007 1:21 pm
| Peter wrote: |
| abszero wrote: | | It seems like it would be helpful to have a stickied list of known issues in r20 for quick reference. |
It make sense to post bugs into the devkitPro bug-tracker, wouldn't it?
devkitPro Bug Tracker
devkitPro Feature Requests |
I thought discussing the bugs here before asking the developers would have benefit for much the same reason that projects such as Mozilla Firefox have "release notes" at the same time that they have public bug trackers:
- One could read a list of the most commonly encountered unexpected behaviors in one place, especially such behaviors that turn out to be intended.
- We wouldn't waste the developers' time with duplicate defect reports.
Here are some gotchas that I have found or read about: - In the libnds version released alongside r20, VRAM_B_MAIN_SPRITE places bank B at 0x06420000, not 0x06400000 as in older versions. This could cause sprites to disappear. (Intended.)
- The IPC structure in libnds tends to change right around the time devkitARM gets an update. If you use a custom ARM7 code, and you find that a libnds update breaks your program, then copy and paste your custom code into the ARM7 code from the combined template.
- The devoptab allows no way for a read-write file system such as libfat to report back the amount of free space for additional files. (Fix rumored for r21.)
- GCC depends on file system semantics of Windows XP and older operating systems to find its worker programs. Windows Vista changed file system semantics in the interest of security. Using devkitARM r20 under Windows Vista needs a path workaround. (Fix rumored for r21, which may break this workaround.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142843 - Mighty Max - Sun Oct 14, 2007 2:58 pm
| tepples wrote: |
- One could read a list of the most commonly encountered unexpected behaviors in one place, especially such behaviors that turn out to be intended.
- We wouldn't waste the developers' time with duplicate defect reports.
|
This is exactly what a bugtracker is supposed to do.
Channeling bugreports. It does not make much sense to decentralize this channeling again, as this is making the bugtracker moo: "What this bug is not known? But i reported this on forum.noonecares.com!"
For multiples there are means on both sides in a bugtracker: Merging/Closing duplicates for the devs and "Search bugs" for the reporters.
_________________
GBAMP Multiboot
#142845 - tepples - Sun Oct 14, 2007 3:17 pm
| Mighty Max wrote: |
| But i reported this on forum.noonecares.com! |
The idea is that someone who reads both forum.noonecares.com and the project's official issue tracker would see that the issue report concerns an actual defect[1], not a PICNIC, and suggest that the reporter elevate it to the developers. I see this idiom between mozillaZine forums and bugzilla.mozilla.org sometimes.
| Mighty Max wrote: |
| For multiples there are means on both sides in a bugtracker: Merging/Closing duplicates for the devs and "Search bugs" for the reporters. |
True, but search isn't perfect. A lot of issue trackers come initially set to "Search only open issues", which does not return any results for issues that are fixed in CVS but not in released binaries ("RESOLVED FIXED" in Bugzilla), or for issues that are closed as intended behavior ("RESOLVED INVALID" in Bugzilla). It might be that the devkitPro developers don't mind duplicates reported by the "unwashed masses" who can't figure out the intricacies of a particular issue tracker's search feature, but is this the case?
A couple issues I posted in various projects' SourceForge.net issue trackers got shot down. Some projects don't specify whether standards conformance issues are treated as defects or as missing features: "You should have posted this in Feature Requests." Sometimes the reporter can't figure out a rationale for maintainers' priority decisions: "If you wanted this feature to be in the top 1,000 priorities, you should have implemented it yourself and posted your code in Patches." Even with sample code that demonstrates the algorithms that would be used, the integration burden falls on the person who discovered the issue: "Your demonstration is not acceptable. You should have implemented it yourself in the domain-specific language I prefer and provided a patch that applies cleanly against CVS".
This may warrant a topic for discussing the subtleties of search in SourceForge.net issue trackers.
[1] To me, a "bug" is Beedrill, not Missingno. A "bug" is an arthropod. A software defect is a software defect.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142898 - abszero - Sun Oct 14, 2007 10:07 pm
| Peter wrote: |
| abszero wrote: | | It seems like it would be helpful to have a stickied list of known issues in r20 for quick reference. All those things that one might assume would work but don't. |
It make sense to post bugs into the devkitPro bug-tracker, wouldn't it?
devkitPro Bug Tracker
devkitPro Feature Requests |
Yeah, I had thought that too, but as it stands there seem to be only six relatively obscure bugs listed in the tracker, which suggests to me that either a) the tracker isn't being actively used for these types of things b) I don't know how to read the tracker properly, neither of which made it a very tempting option to me :P.
And moreover, in my somewhat limited experience, trackers tend to be filled with lots of little obscure bugs, whereas I intended this list to be more common things that an average developer will probably run into, sorta like tepples mentioned.
Well, I need to run for now but I'll update the top post later with tepples' issues and with workarounds to the ones I listed originally. I can probably even add links to the original thread discussions for those too.
#142901 - Dood77 - Sun Oct 14, 2007 10:14 pm
I don't have much if any knowledge about bug-tracking and such, but maybe this forum would be more useful than the standard online bug-tracker because it offers the possibility of discussion, it being in a forum format.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.
Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC
#142913 - wintermute - Mon Oct 15, 2007 12:52 am
The six bugs you mention are the ones that remain open. There are several more bugs which have been fixed and closed.
The active maintainers tend not to read every thread on this or any other forum.
Where bugs are submitted with a proper test case they tend to be dealt with fairly quickly. If a proven fix is submitted that time will be even shorter.
| Quote: |
Anyways, a few off the top of my head are:
-rename (stdio.h) doesn't work
-time (time.h) doesn't work
-IPC->time is not updated with the current time by the default ARM7 code
-fseek (stdio.h) can and occasionally does call _FAT_seek_r (from libfat's fatfile.c) with an unchecked null pointer, resulting in crashes/exceptions
|
None of the elements in the IPC struct should be depended on by user code. Once I find a good way of removing the struct entirely it will vanish but until then the struct can and will be subject to change.
Currently, as far as I can test the others have all been fixed in R21. I still have a final test run to do of the main toolchain then check the examples against CVS libnds before a final release.
| Quote: |
GCC depends on file system semantics of Windows XP and older operating systems to find its worker programs. Windows Vista changed file system semantics in the interest of security. Using devkitARM r20 under Windows Vista needs a path workaround. (Fix rumored for r21, which may break this workaround.)
|
Incorrect.
Vista changed the default behaviour of certain filesytem related functions in the name of security. The path "workaround" that is being suggested is not applicable to any future updates of devkitARM and will, in all probability , break the toolchain.
note: The "fix" will probably break the toolchain. The order of that statement is important.
More generally, I have to say this thread is unlikely to be useful. The bug tracker is the best way to have problems looked at and fixed. Threads like this tend to hang around long past their sell by date & cause more issues than they solve.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#142920 - tepples - Mon Oct 15, 2007 2:45 am
| wintermute wrote: |
| tepples wrote: | | Windows Vista changed file system semantics in the interest of security. |
Incorrect.
Vista changed the default behaviour of certain filesytem related functions in the name of security. |
I don't understand how this differs from what I wrote.
| Quote: |
| More generally, I have to say this thread is unlikely to be useful. The bug tracker is the best way to have problems looked at and fixed. |
In theory, you'd be right. But do you have any search tips for novices to SourceForge.net's bug tracker? The default behaviors of most bug trackers' built-in search differ from the default behaviors of Google, Yahoo!, and Windows Live search, and these differences confuse some novices.
Would a topic like this be useful if each entry were to link to an artifact on SF.net?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142926 - wintermute - Mon Oct 15, 2007 6:02 am
| tepples wrote: |
| wintermute wrote: | | tepples wrote: | | Windows Vista changed file system semantics in the interest of security. |
Incorrect.
Vista changed the default behaviour of certain filesytem related functions in the name of security. |
I don't understand how this differs from what I wrote.
|
Your statement seemed to imply that the filesystem itself has changed in some way and that GCC was dependent on features of the old system. In actual fact Vista now fails if previously "don't care" bits are set in file attributes for particular functions.
You also missed the important part of my correction in your quote. The alleged "workaround" is nothing more than an ill advised hack which will cause issues.
| Quote: |
| Quote: | | More generally, I have to say this thread is unlikely to be useful. The bug tracker is the best way to have problems looked at and fixed. |
In theory, you'd be right. But do you have any search tips for novices to SourceForge.net's bug tracker? The default behaviors of most bug trackers' built-in search differ from the default behaviors of Google, Yahoo!, and Windows Live search, and these differences confuse some novices.
|
I'm really rather confused by this. If a bug is reported in the tracker it gets looked at and fixed if possible. I don't really see what search has to do with anything - duplicate reports can be closed & redirected, it's not a huge issue.
| Quote: |
Would a topic like this be useful if each entry were to link to an artifact on SF.net? |
Not really, no.
The purpose of a bugtracker is to give the maintainers a document of an issue. Once the issue is cleared it's not generally that relevant to anyone not maintaining toolchain code.
Ultimately my point was that issues which get reported via the mailing lists or trackers will get dealt with much sooner than anything posted on a forum.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
Last edited by wintermute on Mon Oct 15, 2007 6:17 am; edited 1 time in total
#142928 - keldon - Mon Oct 15, 2007 6:16 am
I was under the impression that the thread was about the noted issues and not bug tracking them. Of course these issues can be listed on the release notes.
#142930 - wintermute - Mon Oct 15, 2007 6:22 am
Yet the noted issues were in fact bugs & should have been reported in the bugtracker.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#142934 - keldon - Mon Oct 15, 2007 9:05 am
Ah, maybe people need to be encouraged to make more bug reports and not assume that a bug is something to "live with".
#142935 - Dwedit - Mon Oct 15, 2007 9:16 am
The devkitpro.org web site is worse than useless. From all the information posted there, I would not even know that the source code to libnds even existed.
Devkitpro.org really really needs to liberally add links to the sourceforge site in places wherever it's appropriate. For example, from the "Download" page, I should be able to get to the browsable CVS tree.
Bold White text placed next to nonbold white text does not look like links. Finding the hidden white links is like playing "Where's Waldo". Fix the damn CSS.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#142951 - keldon - Mon Oct 15, 2007 1:10 pm
Actually that website is a little 'naughty', but having said that until you mentioned it the CSS never flagged any warning signs! My usability nag for the website has been (to the best of my memory) resolved.