[Date Index] [Thread Index] [Author Index]

Re: Maintaining a Mathematica bug list

• To: mathgroup at smc.vnet.net
• Subject: [mg97579] Re: Maintaining a Mathematica bug list
• From: "Dr. David Kirkby" <david.kirkby at onetel.net>
• Date: Mon, 16 Mar 2009 04:23:03 -0500 (EST)
• References: <14874019.1237075110231.JavaMail.root@m02> <gpil89$56l$1@smc.vnet.net>

David Park wrote:
> I think this is the case of the perfect being the enemy of the useful. It is
> not so important that every single bug be in a maintained bug list for
> users. It is more important that major new bugs that affect a large number
> of users be on a list. I could see a useful bug list being less than a few
> dozen items. If some relatively savvy Mathematica user wanted to maintain
> such a list they might publish it on MathGroup once a week, say. They might
> pick up the bugs from MathGroup, or once they became known, users might send
> bugs to them directly. But if it is something obscure and difficult to
> verify the list maintainer shouldn't be expected to spend a lot of time
> checking it, or put it on the list. Sometimes he might just say that
> so-and-so reported trouble with such-and-such a function. Sometimes WRI
> might even send him bugs, or comment or correct the list.
> 
> A short list of high impact bugs would be useful. 

Agreed David

However, these high impact bugs are likely to be well publicised 
already. A Google search will probably find many of these. College 
lecturers are likely to know of them. I would expect them to be on the 
WRI support pages too.

> A long exhaustive list
> with deep analysis and verification would be too much work.

It's clear that any attempt to thoroughly analyse a long list of obscure 
bugs would need a lot of time dedicated by experts, and nobody other 
than WRI are going to be able to do that. I think it is equally obvious 
that WRI are not likely to make such a list public.

However, there would in my opinion be a use for a collection of 
'reported/unverified bugs'. User 'A' just lists what they thinks is a 
bug, and user 'B' can believe or disbelieve as they see fit. User 'C' 
could add a comment like "this is a usage error, you should use Sin[x] 
not sin(x)" or similar. With a bit of luck, someone from WRI might 
comment, but it could not be expected.

I've stuck a few Solaris-specific Mathematica bugs I've come across over 
the years at

http://www.g8wrb.org/mathematica/

Ignoring the first few, which are only telling you what is already in 
the documentation, I believe 5 of those:

1) Mathematica 5.x using excessive CPU time on Solaris 10.
2) Mathematica uses excessive CPU time on multi-processor machines
3) Mathematica 6.0.1 or 6.0.2 has some characters unreadable
4) Mathematica fails to determine the number of CPUs correctly on SPARC
5) Mathematica crashes on Solaris x86 with an Intel CPU

are listed with sufficient detail to enable someone to decide if they 
believe them or not. The 3rd of these affects Linux too, the 5th is not 
a bug, but a workaround of how to get Mathematica working on a Solaris 
x86 system with an Intel CPU, rather than the supported AMD CPU. (I find 
it amazing Wolfram support AMD CPUs but not Intel, especially as I have 
made them aware how to solve the Intel issue).

In my opinion, bug reports in that form are useful. The problem is that 
to make best use, they would need being in a searchable database. This 
would probably be software like Bugzilla with a mySQL backend.

I think it is fair to say a typical Mathematica user is likely to be of 
above average intelligence, so hopefully would be able to write a bug 
report in a reasonably useful manner.

You also need to consider that students working on college licenses 
don't (officially at least) have direct access to WRI support, but need 
to go via a university contact. Home use licenses in the US will have 
limited technical support (no option for premier service). A searchable 
public list might be particularly useful to that group.

If anyone did set up a decent bug database, they would need to consider 
security and spam issues.

* You can be sure someone is going to post an attachment which is a PHP 
script which attempts to hack your web server.
* Someone might post spam.
* Someone will try to upload a root-kit (or whatever the Windows 
equivalent is).
* A hacker will attempt to exploit security issues in the bug database 
software (Bugzilla or similar). So effort would be needed to keep that 
up to date.
* Someone will attempt to exploit bugs in web server software (Apache etc)
* Someone will attempt to upload porn.
* Someone will attempt to upload viruses.

I think setting up the database and subsequent security maintenance 
would be the time-consuming things - not verifying the bugs, which I 
believe would be impractical and unnecessary.

One final issue, WRI might object to a public bug list. I personally 
don't feel they should, but they might do, claiming it is hurting their 
product to have reports of bugs that are not bugs, but user errors. They 
could threaten legal action if someone did not take it down. I *very* 
doubt that would happen, as I suspect it would do them more harm than 
good and give their competitors something to shout about, but it just 
possibly could happen.


Dave