www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.67 release

reply "Walter" <walter digitalmars.com> writes:
Many minor bugs fixed.

http://www.digitalmars.com/d/changelog.html
Jun 17 2003
next sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
Walter! I hate to point out the obvious, but the change log has not been
updated!

"Walter" <walter digitalmars.com> wrote in message
news:bcou88$2qq9$1 digitaldaemon.com...

 Many minor bugs fixed.

 http://www.digitalmars.com/d/changelog.html
Jun 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
Fixed. -Walter

"Andrew Edwards" <edwardsac spamfreeusa.com> wrote in message
news:bcp5ul$kn$1 digitaldaemon.com...

 Walter! I hate to point out the obvious, but the change log has not been
 updated!

 "Walter" <walter digitalmars.com> wrote in message
 news:bcou88$2qq9$1 digitaldaemon.com...

 Many minor bugs fixed.

 http://www.digitalmars.com/d/changelog.html
Jun 18 2003
parent reply Derek Parnell <derek.parnell no.spam> writes:
On Wed, 18 Jun 2003 10:06:53 -0700 (06/19/03 03:06:53)
, Walter <walter digitalmars.com> wrote:


 Fixed. -Walter

 "Andrew Edwards" <edwardsac spamfreeusa.com> wrote in message
 news:bcp5ul$kn$1 digitaldaemon.com...

 Walter! I hate to point out the obvious, but the change log has not been
 updated!

 "Walter" <walter digitalmars.com> wrote in message
 news:bcou88$2qq9$1 digitaldaemon.com...

 Many minor bugs fixed.

 http://www.digitalmars.com/d/changelog.html






Walter,
the changelog hasn't been updated. All it says is "Fixed some bugs"  ;-)

-- 
Derek
Jun 18 2003
next sibling parent "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Derek Parnell" <derek.parnell no.spam> wrote in message
news:oprqzlsoo959ej19 news.digitalmars.com...

 Walter,
 the changelog hasn't been updated. All it says is "Fixed some bugs"  ;-)


Very funny!
Jun 18 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Derek Parnell" <derek.parnell no.spam> wrote in message
news:oprqzlsoo959ej19 news.digitalmars.com...

 the changelog hasn't been updated. All it says is "Fixed some bugs"  ;-)


That's all that changed <g>. Seriously, though, each person who reported a
bug that was fixed was sent an email confirming the fix, as is my usual
practice.
Jun 18 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:

 
 "Derek Parnell" <derek.parnell no.spam> wrote in message
 news:oprqzlsoo959ej19 news.digitalmars.com...

 the changelog hasn't been updated. All it says is "Fixed some bugs"  ;-)


 
 That's all that changed <g>. Seriously, though, each person who reported a
 bug that was fixed was sent an email confirming the fix, as is my usual
 practice.


Not exactly true. Never got an e-mail about the float-sort-bug I reported
although I saw that it was fixed in the Phobos source.

I would prefer a public bug database. 

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Jun 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EF15AD8.23A8B778 chello.at...

 Walter wrote:

 "Derek Parnell" <derek.parnell no.spam> wrote in message
 news:oprqzlsoo959ej19 news.digitalmars.com...

 the changelog hasn't been updated. All it says is "Fixed some bugs"






;-)

 That's all that changed <g>. Seriously, though, each person who reported




a

 bug that was fixed was sent an email confirming the fix, as is my usual
 practice.


 Not exactly true. Never got an e-mail about the float-sort-bug I reported
 although I saw that it was fixed in the Phobos source.


It had been reported several times :-( I apologize for not remembering to
email you about it, too.


 I would prefer a public bug database.


So would I, and once upon a time, I did that. Shortly afterwards, a lazy
writer wrote a review of it in a magazine that simply published the bug list
verbatim and used that as the basis for his negative review. It didn't
matter that by the time the article came out, those bugs had long been
fixed. So I'm a little reluctant to do that again.

However, most bug reports are posted here in the Digital Mars newsgroups,
and remain here.
Jun 19 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:

 I would prefer a public bug database.


 
 So would I, and once upon a time, I did that. Shortly afterwards, a lazy
 writer wrote a review of it in a magazine that simply published the bug list
 verbatim and used that as the basis for his negative review. It didn't
 matter that by the time the article came out, those bugs had long been
 fixed. So I'm a little reluctant to do that again.


I can understand that.

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)

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Jun 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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>.
Jun 19 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
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
Jun 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jun 20 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
 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.
Jun 20 2003
parent "Walter" <walter digitalmars.com> writes:
"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.
Jun 20 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Jun 19 2003
parent "Walter" <walter digitalmars.com> writes:
"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.
Jun 20 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Jun 25 2003
next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
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
Jun 25 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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.
Jun 25 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
    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.
Jul 05 2003
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Burton Radons wrote:


    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.


Sorry, the "B.Z" is not needed.  It triggers fine using any user-defined 
type.
Jul 05 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
Thanks, I'll take care of it. BTW, could you please post bug reports with
their own title? This will make it a bit easier for me to manage them.
Thanks, -Walter

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:be75ri$2brj$1 digitaldaemon.com...

     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.
Jul 07 2003
prev sibling parent Farmer <itsFarmer. freenet.de> writes:
Some bugs of dmd 0.67 (Windows version).

begin 644 crash.d



M(&D]9G5N02 I+FUE;6)E<CL +R\ 26YT97)N86P 97)R;W(Z("XN7'IT8UQC


M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O

M<CL-"GT-" T*<W1A=&EC(&-O;G-T(%-T<G5C=$$ <W1R=6-T03U[(&UE;6)E

M8W1!/6([("`O+R!W;W)K<RP =&AO=6=H(%-T<G5C=$$ :7, 8V]N<W0-"GT-


M95-T<G5C=`T*>PT*("` :6YT(&UE;6)E<CL-"GT-"B\O('-T871I8R!3;VUE
M4W1R=6-T('-O;653=')U8W0]>R!M:7-S<&5L;&5D365M8F5R.C< ?3L +R\ 

M871I8R!3;VUE4W1R=6-T('-O;653=')U8W0]>R!M96UB97(Z-R!].R`O+W=O


M*0T*>PT*("` 8V]N<W0 :6YT(&YO=$EN:71I86QI>F5D.PT*("` +R]C;VYS
M="!I;G0 :3UN;W1);FET:6%L:7IE9#L +R\ 1$U$(&-R87-H97,-"GT-" T*



M;G-T(&EN="H :3TF;&]C86P[("\O26YT97)N86P 97)R;W(Z("XN7'IT8UQC


`
end
Jul 06 2003