On 10 June 2010 16:28, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> Whoa... it's not important to know what version of dmd a user was running when encountering a bug? ?I think it's critically important!
>
> If someone submits a bug, and says "D2", and it's something that's already been fixed, you don't think it's worth knowing the version they used? ?The next question is, "hm... I thought we fixed that, what version are you using?" ?Lot's of time gets wasted when the version isn't specified.

That's untrue, for three reasons.
Firstly, and most importantly, the version information is indicated by
the date the bug was filed; people are almost always using the latest
version. Very occasionally, someone is using a very old version. (For
sure, they are not using a future version!)
Secondly, you cannot trust the version information. It is very often
incorrect. I've seen many regressions where the bug wasn't introduced
until one or two versions after the specified version. And that's the
only time when version information could potentially be useful.
Thirdly, if a bug has gone away, I always try to track down in which
release it was fixed, anyway. With a binary chop, you don't have to
test many releases to find it.

But by contrast, it's really dreadful that you cannot search for D1-only bugs! This is a really important feature which is missing.

(BTW, the keywords could be a lot better, too. ice-on-valid-code and
ice-on-invalid-code should be merged. Because invalid code is valid
inside is(typeof()) expressions!).

On 10 June 2010 09:07, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> hi,
>
> there seems to be a regression regarding compile time evaluation of startsWith:
>
> import std.string;
>
> const bool ok = startsWith("ab", 'a');
> const bool fails = startsWith("ab", "a");
>
> produces
> c:\l\dmd2\windows\bin\..\..\src\phobos\std\functional.d(176): Error: static
> assert ?"Bad binary function q{a == b}. You need to use a valid D expression
> using symbols a of type dchar and b of type string."
> c:\l\dmd2\windows\bin\..\..\src\phobos\std\functional.d(179):
> ?instantiated from here: Body!(dchar,string)
> c:\l\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1981):
> ?instantiated from here: result!(dchar,string)
>
> This worked for me in 2.046.

This seems to be a Phobos regression, not a compiler regression. I slightly reduced this to:

import std.algorithm : startsWith;

const bool fails = startsWith("ab", "a");

Copying the 2.047 implementation of startsWith into 2.046 std.algorithm, generates the same error as DMD 2.047.

On 10 June 2010 17:14, Don Clugston <dclugston at googlemail.com> wrote:
> On 10 June 2010 09:07, Rainer Schuetze <r.sagitario at gmx.de> wrote:
>> hi,
>>
>> there seems to be a regression regarding compile time evaluation of startsWith:
>>
>> import std.string;
>>
>> const bool ok = startsWith("ab", 'a');
>> const bool fails = startsWith("ab", "a");
>>
>> produces
>> c:\l\dmd2\windows\bin\..\..\src\phobos\std\functional.d(176): Error: static
>> assert ?"Bad binary function q{a == b}. You need to use a valid D expression
>> using symbols a of type dchar and b of type string."
>> c:\l\dmd2\windows\bin\..\..\src\phobos\std\functional.d(179):
>> ?instantiated from here: Body!(dchar,string)
>> c:\l\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1981):
>> ?instantiated from here: result!(dchar,string)
>>
>> This worked for me in 2.046.
>
> This seems to be a Phobos regression, not a compiler regression. I slightly reduced this to:
>
> import std.algorithm : startsWith;
>
> const bool fails = startsWith("ab", "a");
>
> Copying the 2.047 implementation of startsWith into 2.046 std.algorithm, generates the same error as DMD 2.047.

And to clarify -- the reason is that the specialisation of startsWith for ranges of characters, was removed from std.algorithm.

Apologies. svn up should fix it, and bring some more goodies too :o).

Andrei

On 06/10/2010 10:14 AM, Don Clugston wrote:
> const bool fails = startsWith("ab", "a");

On 06/10/2010 10:17 AM, Don Clugston wrote:
> And to clarify -- the reason is that the specialisation of startsWith for ranges of characters, was removed from std.algorithm.

Actually it was the return type which I made uint. Now I fixed things by making the return type bool if you're only looking for one item.

What I did remove was startFirst mixing ranges and individual characters:

startsWith("abc", 'a', "ab")

does not work. The previous implementation accepted the call but it was buggy. I don't know how to make it work reasonably.


Andrei

----- Original Message ----
> From: Don Clugston <dclugston at googlemail.com>

> That's untrue, for three reasons. Firstly, and most importantly, the version information is indicated by the date the bug was filed; people are almost always using the latest version.

The date filed is not nearly as useful as the version.  Quick, compile the code with dmd circa 5/24!  Your assumption is very wrong, people don't use the latest version often because a) it's easier not to update your code whenever a new version comes out that doesn't interest them (new features don't affect them, or bugs fixed don't affect them) or b) the newest version has some other bug that makes it unable to compile/use their code.

By your reasoning, why do we have version numbers at all?

> (For sure, they are not using a future version!)

Yeah, getting rid of "future" would be fine with me (as long as W. maintains the list properly!)

> Secondly, you cannot
> trust the version information. It is very often
> incorrect.

Of course, you cannot really "trust" anything you don't try yourself.  That doesn't mean it's never true.  Even if it isn't, you test the version they say reproduces the bug, and if it's not true you close the bug.  This is much easier than guessing what the user was doing.  Responding with "you gave me wrong information" is a lot easier than "I did an exhaustive search on all D2 compilers, and it seems none of them have this problem."

> I've seen many
> regressions where the bug wasn't introduced
> until one or two versions after
> the specified version.

Maybe because the list isn't properly maintained? ;)

> And that's the
> only time when version information
> could potentially be useful.

I'd say no, it's always good to compare apples to apples.  Testing the version being used by the user is step one, testing the latest version to see if it's fixed is step 2.

> But by contrast, it's
> really dreadful that you cannot search for
> D1-only bugs! This is a really
> important feature which is missing.

So you're saying, it's easier to do a binary search for the correct version the user might have been using via compiling their code with various D compilers, vs. selecting the range of D1 versions in the bugzilla search form when doing a bug search?  I disagree.

-Steve

Don Clugston wrote:
>
> I wish we'd get rid of them entirely. They don't add any value at all. The only thing that's relevant is D1 only, D2 only, D1+D2.
>
> 

I added those.

Sorry, but it still doesn't work. The error occurs when the expression is evaluated at compile time, so the code added to the unittest does not cover the issue.

Rainer

Andrei Alexandrescu wrote:
> Apologies. svn up should fix it, and bring some more goodies too :o).
>
> Andrei
>
> On 06/10/2010 10:14 AM, Don Clugston wrote:
>> const bool fails = startsWith("ab", "a");
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

line 1332 looks wrong:

    enforce(fprintf(.stdout.p.handle, "%*s\n",

should be

    enforce(fprintf(.stdout.p.handle, "%.*s\n",

and since this has come up, what I absolutely hate about the "%.*s" syntax is that the C standard requires that the length be an int, while size_t is almost always used to represent buffer size.  In a 64-bit app a cast to int is necessary to avoid weird results.  So 1333 should be:

    cast(int) args[0].length, args[0].ptr) >= 0);

On Jun 10, 2010, at 5:45 AM, Richard Webb wrote:

> 
> Using 2.047 on Windows 2008, i see the code
> 
> 	char[3] tmp = ['a', 'b', 'c'];
> 	writeln(tmp);
> 
> print abc<randombytes> (in debug builds at least).
> 
> possibly because the change in http://www.dsource.org/projects/phobos/changeset/1611 doesn't handle non-null terminated character arrays?
> 
> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Thanks. It may take a while before I can tend to this. Could someone else look at it?

Andrei

On 06/10/2010 12:53 PM, Rainer Schuetze wrote:
> Sorry, but it still doesn't work. The error occurs when the expression is evaluated at compile time, so the code added to the unittest does not cover the issue.
>
> Rainer
>
> Andrei Alexandrescu wrote:
>> Apologies. svn up should fix it, and bring some more goodies too :o).
>>
>> Andrei
>>
>> On 06/10/2010 10:14 AM, Don Clugston wrote:
>>> const bool fails = startsWith("ab", "a");
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta