I don't know about a bug database, but listing the bugs you fixed would be helpful to all of us because the reporter isn't the only one who gets strife from them.  For example, I didn't get any notification that the nested functions in methods bug has been fixed (I reported it first, but it looks like you lost it), but I see that it has been.  Being notified of this a few days ago in the changelog would've allowed me to upgrade and start testing the feature to make sure it really is fixed.

Walter wrote:
> 
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EF1A2BB.3D24BF41@chello.at...
> > Perhaps it would make sense to create a semi-public bug database for the people you trust. (or give access to those that have reported at least N+ bugs)
> 
> There are the bugs reported on the newsgroups. Anyone can see them if they want to, they just aren't in a format that is easilly cut & pasted into an article <g>.

No bug "database" means that users have to report bugs multiple times.
No bug "database" means that users don't know when new testing makes sense.

It's a question of protection versus efficiency. The optimum solution would be to have both.

One solution would be to
 - have a Bugs page in the wiki, subpages if necessary
 - access is possible only to users that have logged in
 - login data is only given to power users (by you)

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bcu85n$1l47$1@digitaldaemon.com...
> I don't know about a bug database, but listing the bugs you fixed would be helpful to all of us because the reporter isn't the only one who gets strife from them.  For example, I didn't get any notification that the nested functions in methods bug has been fixed (I reported it first, but it looks like you lost it), but I see that it has been.  Being notified of this a few days ago in the changelog would've allowed me to upgrade and start testing the feature to make sure it really is fixed.

You're right, I should do a better job with that.

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EF2A539.584DF151@chello.at...
> One solution would be to
>  - have a Bugs page in the wiki, subpages if necessary
>  - access is possible only to users that have logged in
>  - login data is only given to power users (by you)

What I currently do is everything that looks like a bug gets moved to my 'bugs' email folder. As I resolve them, they get deleted and a reply sent to the author of that email (frequently the replies fail as people understandably fake the reply address because of spam scrapers). Essentially, I'm using Outlook Express as my "bug database".

There are currently maybe 100 entries in it. Many duplicates, many things that are not bugs, many ideas for new features, etc. Some were sent as private email, most were posted at one time on the D newsgroup, where they still are. There are a couple from you in there, and a number from Burton.

> Author: "Walter" <walter@digitalmars.com>
> 
> What I currently do is everything that looks like a bug gets moved to my 'bugs' email folder. As I resolve them, they get deleted and a reply sent to the author of that email (frequently the replies fail as people understandably fake

A quick-and-dirty fix would be to CC them to this mailing list.

Maybe better would be to actually write them to the Changes web page. (The lazy editors can't complain about fixed bugs!)

> the reply address because of spam scrapers).  Essentially, I'm using Outlook Express as my "bug database".

I won't comment on that, but my fingers sure are itching.

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bcvrno$2ah$1@digitaldaemon.com...
> Maybe better would be to actually write them to the Changes web page. (The lazy editors can't complain about fixed bugs!)

That'd probably be best. I got lazy last time :-(

> > the reply address because of spam scrapers).  Essentially, I'm using Outlook Express as my "bug database".
> I won't comment on that, but my fingers sure are itching.

<g> What can I say, it works, and it's very simple.

I've used several professional bug database programs in the past. All of them seemed to take far more time trying to administer the system and keep it up and running than they ever saved. Since I receive bug reports via email and the newsgroups, it is utterly trivial to just click & drag them to the 'bugs' folder. Opening the folder, I know what all the outstanding issues are at a glance.

Something I've been meaning to call for awhile: to fix the delegate and function syntax.  Right now there's two separate syntaxes in use:

   void delegate () foo;

   foo = delegate void () { };

I can accept the need to change the order for inline functions (although I'd rather have a truncated syntax, like that in CECIL), but I want delegate declarations to have the same syntax.  So:

   delegate void () foo;

   foo = delegate void () { };

I don't like the situation, because it makes chaining confusing again. However, I prioritise a consistent syntax much higher than that. Alternatively, we could go with:

   void delegate () foo;

   foo = (void delegate ()) { };

Which I would like the best.  Finally, I think that struct initialisers should use [] like arrays:

   bar baz = [ x, y, z ];

Because there's much more in common between structs and arrays than there is between structs and block statements.  It would also remove the special syntactual handling of delegate in inline functions and would pave the road for:

   void delegate () foo;

   foo = { };

Also, and again, having two separate function pointer syntaxes is not acceptable.

Burton Radons wrote:
> 
> Something I've been meaning to call for awhile: to fix the delegate and function syntax.  Right now there's two separate syntaxes in use:
> 
>     void delegate () foo;
> 
>     foo = delegate void () { };
> 

I stumbled over that too, and I agree that this is non-intuitive.

> I can accept the need to change the order for inline functions (although I'd rather have a truncated syntax, like that in CECIL), but I want delegate declarations to have the same syntax.  So:
> 
>     delegate void () foo;
> 
>     foo = delegate void () { };
> 
> I don't like the situation, because it makes chaining confusing again. However, I prioritise a consistent syntax much higher than that. Alternatively, we could go with:
> 
>     void delegate () foo;
> 
>     foo = (void delegate ()) { };
> 
> Which I would like the best.

Currently I don't have a preference for one. Either is good to me.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bdci25$2csm$1@digitaldaemon.com...
> Something I've been meaning to call for awhile: to fix the delegate and function syntax.  Right now there's two separate syntaxes in use:
>
>     void delegate () foo;
>
>     foo = delegate void () { };

It's a good point, but I think that once delegates and function pointers are merged into a common syntax, this should mostly go away.

> I can accept the need to change the order for inline functions (although I'd rather have a truncated syntax, like that in CECIL), but I want delegate declarations to have the same syntax.  So:
>
>     delegate void () foo;
>
>     foo = delegate void () { };
>
> I don't like the situation, because it makes chaining confusing again. However, I prioritise a consistent syntax much higher than that. Alternatively, we could go with:
>
>     void delegate () foo;
>
>     foo = (void delegate ()) { };
>
> Which I would like the best.  Finally, I think that struct initialisers should use [] like arrays:
>
>     bar baz = [ x, y, z ];
>
> Because there's much more in common between structs and arrays than there is between structs and block statements.

I've been thinking of adding in array and struct literals, and how this might be done.

>  It would also remove the
> special syntactual handling of delegate in inline functions and would
> pave the road for:
>
>     void delegate () foo;
>
>     foo = { };
>
> Also, and again, having two separate function pointer syntaxes is not acceptable.

   void foo ()
   {
      B.Z bar (inout int p)
      {
      }
   }

Compiling this with "dmd f.d" using DMD 0.67 says:

   f.d(3): found 'bar' when expecting ';'
   f.d(3): expression expected, not 'inout'
   f.d(3): found 'int' when expecting ')'
   f.d(3): found 'p' when expecting ';'
   f.d(3): found ')' instead of statement
   f.d(7): found 'EOF' instead of statement
   f.d(7): found 'EOF' instead of statement
   f.d(7): found 'EOF' instead of statement
   f.d(7): found 'EOF' instead of statement
   f.d(7): found 'EOF' instead of statement
   f.d(7): found 'EOF' instead of statement

The "inout", the "B.Z" form, and the nested function status are all needed.  It's clearly a statement misidentification.