From: Jerry v. D. <jv...@at...> - 2002-12-12 01:00:19
|
> https://sourceforge.net/projects/mingw/ " If one of the developers > doesn't know how to do it it's reasonable to think that quite a few > users doesn't either. Sigh. Of course *I* know this. But: a) there is no pointer on how to report bugs on mingw.org b) the bug reporting page on SF *requires* someone to have an SF account to report a bug, although this is not a SF requirement. (maybe it is to discourage a lot of beginner type of 'bug' reports, but is is also a *huge* block. In practice I only get bug reports on GNAT on Ada mailing lists, comp.lang.ada and direct email.) For Ada I think a) and b) either need to be resolved, or the but reporting has to be moved a another more accesible forum like GNATLIST. -- Jerry van Dijk | email: jd...@ac... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Jerry v. D. <jv...@at...> - 2002-12-12 23:28:12
|
> Yes and it's the bottom of every page as well as an entry in the FAQ > "How can I report bugs?". I guess that answer means nothing will get changed. Not a problem, I will ask ask people to report any bugs on GNATLIST and enter them myself on SF after checking them. GNATLIST (http://www.mysunrise.ch/users/gdm/gnatlist.htm) is a mailing list explicitly setup to support non-ACT ports of GNAT. Just about everyone who uses a non-ACT GNAT (DOS, Windows, Linux, OS/2, BSD and such) will already be getting it. And it has an archive. -- Jerry van Dijk | email: jd...@ac... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Danny S. <dan...@cl...> - 2002-12-13 00:29:09
|
----- Original Message ----- From: "Jerry van Dijk" <jv...@at...> To: <min...@li...> Sent: Thursday, 12 December 2002 20:00 Subject: RE: [MinGW-dvlpr] How can users report bugs > > Yes and it's the bottom of every page as well as an entry in the FAQ > > "How can I report bugs?". > > I guess that answer means nothing will get changed. > There is mechanism within gcc itself to modify the stderr error message on ICE so that bugs are reported to appropriate forum. In fact, using this mechanism is _strongly_ recommended for "special" builds (like "mingw-special"). Maybe the Gnat 'bug-boxes' can also be modified. Implementing these will mean, however, that many non-target-specific bugs will get reported to to mingw rather than to gcc. I agree with Jerry that the instructions for reporting bugs/patches should be more obvious. After all, the virtue and strength of open-source software is in the cultivation of the "I've found a bug and here is the fix" attitude. maybe just make the small print bigger. (As the Tom Waits song says "The large print giveth, but the small print taketh away") danny |
From: Jerry v. D. <jv...@at...> - 2002-12-13 02:34:05
|
> Maybe the Gnat 'bug-boxes' can also be modified. > > Implementing these will mean, however, that many non-target-specific > bugs will get reported to to mingw rather than to gcc. They could be changed, for mingw only. Problem is, the 3.3 Ada bugs that turned up so far are not of the ICE type, also none of them show up on the ACVC tests: 1. Bug in Ada.Calendar package -> acknowledged by ACT, Bosch promised fix. (Test code available) <Nicolas Brunot> 2. Using pragma Linker_Options with non-library argument (e.g. setting stack size) fails. Also reported with GNATS and to ACT (Test code available) <Nicolas Brunot> 3. Interfacing to C++ fails (ACT changed implementation in 3.2) (under discussion with ACT's Cyrille Comar) (Test code available) <Jerry/Danny> 4. Tagged-type specific storage pools fail using mingw 3.3 (Simon Wright is trying to narrow problem down, it seems not a problem on a pure gcc build) <Simon Wright> 5. Inaccurate ftp results when interface to C/Fortran. (Steve Sangwine is trying to narrow problem down, potentially very serious) <Steve Sangwine> After testing with 3.14p on Debian and 3.15a1 on Windows only (4) and (5) seem 3.3 mingw specific. I will enter them as bugs as soon as I have received and verified the test programs. Once I have some more bugs I want to create a test directory with testprograms and script somewhere for easy [regression] testing. Note that after inquiring on comp.lang.ada I received 9 replies saying there were no problems with the experimental 3.3 release... I hope I do not come across as too standard and quality orientated, but it IS an Ada programmers trait... :-) -- Jerry van Dijk | email: jd...@ac... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Paul G. <pga...@at...> - 2002-12-14 01:13:03
|
Think I can safely say that we all appreciate your orientation and way of doing things, Jerry. For my part, as someone who has, for the last 30 years or so, done QA, Software Engineering, debugging and bug hunting, both here (The US) and in The Netherlands, I can say I really appreciate your contributions and how you bring them to the table. Paul G. > > Maybe the Gnat 'bug-boxes' can also be modified. > > > > Implementing these will mean, however, that many non-target-specific > > bugs will get reported to to mingw rather than to gcc. > > They could be changed, for mingw only. > > Problem is, the 3.3 Ada bugs that turned up so far are not of the ICE > type, also none of them show up on the ACVC tests: > > 1. Bug in Ada.Calendar package -> acknowledged by ACT, Bosch promised > fix. > (Test code available) > <Nicolas Brunot> > > 2. Using pragma Linker_Options with non-library argument (e.g. setting > stack size) fails. Also reported with GNATS and to ACT > (Test code available) > <Nicolas Brunot> > > 3. Interfacing to C++ fails (ACT changed implementation in 3.2) > (under discussion with ACT's Cyrille Comar) > (Test code available) > <Jerry/Danny> > > 4. Tagged-type specific storage pools fail using mingw 3.3 > (Simon Wright is trying to narrow problem down, it seems > not a problem on a pure gcc build) > <Simon Wright> > > 5. Inaccurate ftp results when interface to C/Fortran. > (Steve Sangwine is trying to narrow problem down, potentially > very serious) > <Steve Sangwine> > > After testing with 3.14p on Debian and 3.15a1 on Windows only (4) and > (5) seem 3.3 mingw specific. I will enter them as bugs as soon as I > have received and verified the test programs. Once I have some more > bugs I want to create a test directory with testprograms and script > somewhere for easy [regression] testing. > > Note that after inquiring on comp.lang.ada I received 9 replies saying > there were no problems with the experimental 3.3 release... > > I hope I do not come across as too standard and quality orientated, > but it IS an Ada programmers trait... :-) > > -- Jerry van Dijk | email: jd...@ac... > -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ MinGW-dvlpr mailing > list Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Paul G. <pga...@at...> - 2002-12-17 01:46:58
|
> > Sigh. Of course *I* know this. But: > > > > a) there is no pointer on how to report bugs on mingw.org > > b) the bug reporting page on SF *requires* someone to have > > an SF account to report a bug, although this is not a > > SF requirement. (maybe it is to discourage a lot of beginner > > type of 'bug' reports, but is is also a *huge* block. In practice > > I only get bug reports on GNAT on Ada mailing lists, comp.lang.ada > > and direct email.) > > > Okay gcc -v --help prints this at the end of its output: > > For bug reporting instructions, please see: > <URL:http://www.gnu.org/software/gcc/bugs.html> > > This can be changed, and in fact mingw is supposed to > (from gcc/version.c): > > /* This is the location of the online document giving instructions for > reporting bugs. If you distribute a modified version of GCC, > please change this to refer to a document giving instructions for > reporting bugs to you, not us. (You are of course welcome to > forward us bugs reported to you, if you determine that they are > not bugs in your modifications.) */ > > const char bug_report_url[] = > "<URL:http://www.gnu.org/software/gcc/bugs.html>"; > > I'm not sure but that string might also get put into info files. > > Should we modify this built-in bug report url for mingw-gcc(3.3) to the > SF page, or to a friendlier page at mingw.org that links to gcc, > binutils, etc, as well as the SF page? This, at least to me, is a much more complex question than it initially appears to be. I will attempt to stay focussed on the question itself. Personally I am inclined to believe that the friendlier page is the better way to go for a couple of reasons: a) It keeps Mingw forefront when it comes to reporting a mingw-gcc related bug b) It gives a reference, in the case it is not a mingw-gcc specific bug, for the user to submit the bug to the gcc url: http://www.gnu.org/software/gcc/bugs.html. My suggestion would be, in its simplest form, to determine the "specific", and output the appropriate place to report the bug based on the "specific" behavior of the bug in question. I think it is important to keep the two gcc's (Mingw-gcc and Gnu-gcc) synchronized for as long as it is at all possible to do so. My biggest question: How can it be initially determined whether the bug is in fact Mingw- gcc specific (eg. Mingw runtime interface) or Gnu-gcc specific? If I can answer that question, then I can say which would be the more appropriate URL reference to use. Here is one possible solution/suggestion (please ignore if it has already been, in the community of Mingw developers, adequately addressed): Track all the mingw-gcc specific changes (ie. those that make mingw-gcc different than gnu-gcc). What that "tracking" might look like (please ignore if this has already been, in the community of Mingw developers, adequately addressed): Being able to quickly check/detect (cvs changelog perhaps?) what has been specifically modified to support the mingw runtime (within Gnu-gcc which allows Mingw-gcc to exist as different (diffs?) than Gnu-gcc) and can be seen in the latest Mingw-gcc source code release, but may not be apparent or even existent (in terms of diffs) within Gnu-gcc source code release. (I know that there are some things in the Mingw-gcc(3.3) version that do not exist in the Gnu-gcc(3.3) version -- I am still not exactly sure how to reference those things. For ease of communication, I typically consider those differences between Mingw- gcc(3.3) as extensions to Gnu-Gcc(3.3) specifically implemented and tailored to work with the Mingw runtime.). The actual source code variances between the two gccs (Mingw-gcc and Gnu-gcc) may be deduced. I am assuming that Gnu-gcc and Mingw-gcc are on a kind of "continuum" with Gnu-gcc at one end of that "continuum" and Mingw-gcc at the other end of that "continuum". As to how to implement such a thing at the source code level? Not sure. Even so, here is one suggestion -- it assumes that the internal gcc exception/bug detection sequence has been executed: Run a diff (cron?) between all of Gnu-gcc specific source code and Mingw-gcc specific source code on a periodic basis (to be determined by those who are or will be modifyiing/developing the Mingw variation of Gcc) based on the gcc detected bug. Ultimately, what you would have is the following algorithm: mingw-gcc-diffs = diffs between Gnu-Gcc-latest-release and Mingw-gcc-latest-release Gnu-gcc-diffs = (Gnu-gcc-latest-diffs) Gnu-gcc-latest = (Gnu-gcc-latest-stable-release) (pseudo-code:) Check submitted bug-report against mingw-gcc-diffs; if bug report not handled/covered/previously-assigned within mingw-gcc-diffs, then check to see if bug report is handled/covered/previously-assigned within the gnu-gcc-diffs; .. if bug report not handled/covered/previously-applied within gnu-gcc-diffs, then apply/assign/send bug-report/bug to Gnu-gcc-latest; .. else apply/assign/send bug-report/bug to Mingw-gcc;; (end pseudo-code) The above is intended to indicate "how" and "what" should be provided whenever the "built-in bug report exception" is actually executed by the Mingw variation of Gcc. I really have no idea, at least not right now (this moment), as to "how the above pseudo- code might be implemented at the source code level of the Gcc being used (as part of distro/install) for Mingw" or "What the scope of such an implementation might include". Even so, it does seem to be a logical way/method to implement (which url should be noted) in terms of "how to approach modification of the automated bug-report facility". Danny wrote: > Should we modify this built-in bug report url for mingw-gcc(3.3) to the > SF page, or to a friendlier page at mingw.org that links to gcc, > binutils, etc, as well as the SF page? What about a special page (perhaps a .cgi or .php page?) which can determine (for the end-user wanting to report the bug) where the end-user should actually report/submit the bug? If that were implemented, then the URL output (from gcc) would always direct the end- user to that particular web page (mingwbugs.sf.net?). The web page itself would/could manage the rest. Paul G. |
From: Danny S. <dan...@cl...> - 2002-12-16 23:51:21
|
> Sigh. Of course *I* know this. But: > > a) there is no pointer on how to report bugs on mingw.org > b) the bug reporting page on SF *requires* someone to have > an SF account to report a bug, although this is not a > SF requirement. (maybe it is to discourage a lot of beginner > type of 'bug' reports, but is is also a *huge* block. In practice > I only get bug reports on GNAT on Ada mailing lists, comp.lang.ada > and direct email.) Okay gcc -v --help prints this at the end of its output: For bug reporting instructions, please see: <URL:http://www.gnu.org/software/gcc/bugs.html> This can be changed, and in fact mingw is supposed to (from gcc/version.c): /* This is the location of the online document giving instructions for reporting bugs. If you distribute a modified version of GCC, please change this to refer to a document giving instructions for reporting bugs to you, not us. (You are of course welcome to forward us bugs reported to you, if you determine that they are not bugs in your modifications.) */ const char bug_report_url[] = "<URL:http://www.gnu.org/software/gcc/bugs.html>"; I'm not sure but that string might also get put into info files. Should we modify this built-in bug report url for mingw-gcc(3.3) to the SF page, or to a friendlier page at mingw.org that links to gcc, binutils, etc, as well as the SF page? Danny |
From: Earnie B. <ear...@ya...> - 2002-12-17 01:10:22
|
Danny Smith wrote: > > const char bug_report_url[] = > "<URL:http://www.gnu.org/software/gcc/bugs.html>"; > > I'm not sure but that string might also get put into info files. > > Should we modify this built-in bug report url for mingw-gcc(3.3) to the > SF page, or to a friendlier page at mingw.org that links to gcc, > binutils, etc, as well as the SF page? > Yes, I prefer something on www.mingw.org. Perhaps bugs.shtml? Now who's going to write it? Perhaps me or some volunteer? Just assume it should be http://www.mingw.org/bugs.shtml. Earnie. |