I hope I'm not out of line for posting this, but I think that the Windows heisenbug should be fixed for the next release. It's been encountered in at least 3 projects, as far as I'm aware.

http://d.puremagic.com/issues/show_bug.cgi?id=6308

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net

I think it's about time for another release, but I'd like to give Lars Kyllingstad a little more time to get his pull request in for his recently accepted improvements to std.path.

On 8/13/2011 3:40 PM, Walter Bright wrote:
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

I've been thinking it's about time also, but the number of regression bugs that are still open from the past couple weeks is disconcerting.  There's 11 from July alone.  As long as regressions remain unfixed (though it's not unreasonable to guess that at least some of those might well not actually be regressions but long standing bugs), the quality isn't strictly improving.

I'm not discounting the many regressions that have been fixed (and another big thanks for those that are providing those fixes), but regressions are the kind of thing that any is too many.

My 2 cents,
Brad

I agree with Vladimir and David, and I'll also add that I think it's very important to have #6452 ("RDMD shouldn't put the compiler in the rsp file") in the next release, too. Without it, RDMD is broken for projects big enough to have a cmd line longer than about 1k, which a number of people have already run into (easy to hit if you're project's base dir has a long path).

Fortunately, there's already *two* pull requests for this:

https://github.com/D-Programming-Language/tools/pull/3 https://github.com/D-Programming-Language/tools/pull/8


I'd also really like to see my pull request for "#6102: [RDMD] Changing a string import file doesn't trigger a rebuild" included (although I admit the other RDMD issue is a little more important. But this one can be really confusing when the user hits it):

https://github.com/D-Programming-Language/tools/pull/6

Hi,

I recently updated to the latest revision from github and tried to compile my main project visuald with it. Here are some complications that have hit me:

1. My Windows SDK conversion tool converts C macros to templates, e.g.

#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))

is converted to

auto MAKEINTRESOURCEW(ARG)(ARG i)() { return ( cast(LPWSTR)( cast(ULONG_PTR)( cast(WORD)(i)))); }

This no longer works for CTFE, because casts to pointers are no longer allowed. Making the argument a template parameter still works, though:

auto MAKEINTRESOURCEW(int i)() { return ( cast(LPWSTR)( cast(ULONG_PTR)( cast(WORD)(i)))); }

Also, casting to a pointer is still allowed when initializing a global variable at compile time.

Is this by design or a regression?

2. std.regexp is deprecated now, which is good, because there is no reason to have two different implementations of regular expressions. Unfortunately, std.regex seems to have some problems with rather simple regular expressions like r"^(.*)\(([0-9]+)\):(.*)$" that is supposed to match error messages like "file.d(37): huhu". std.regexp worked for this expression.

Dmitry Olshansky's new std.regex also works, but it does not compile with warnings enabled (even not with -wi) ( http://d.puremagic.com/issues/show_bug.cgi?id=6518 ).

Maybe it would be better to wait with deprecating std.regexp until there is a working alternative.

3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).

I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.

Otherwise, it seems the generated executable works fine.

Rainer

On 20.08.2011 12:39, Rainer Schuetze wrote:
> Hi,
>
> I recently updated to the latest revision from github and tried to compile my main project visuald with it. Here are some complications that have hit me:
>
> 1. My Windows SDK conversion tool converts C macros to templates, e.g.
>
> #define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
>
> is converted to
>
> auto MAKEINTRESOURCEW(ARG)(ARG i)() { return ( cast(LPWSTR)( cast(ULONG_PTR)( cast(WORD)(i)))); }
>
> This no longer works for CTFE, because casts to pointers are no longer allowed. Making the argument a template parameter still works, though:
>
> auto MAKEINTRESOURCEW(int i)() { return ( cast(LPWSTR)( cast(ULONG_PTR)( cast(WORD)(i)))); }
>
> Also, casting to a pointer is still allowed when initializing a global variable at compile time.
>
> Is this by design or a regression?
>
> 2. std.regexp is deprecated now, which is good, because there is no reason to have two different implementations of regular expressions. Unfortunately, std.regex seems to have some problems with rather simple regular expressions like r"^(.*)\(([0-9]+)\):(.*)$" that is supposed to match error messages like "file.d(37): huhu". std.regexp worked for this expression.
>
That's most likely my fault, since there is a special casing for .* in std.regex which very well might be at fault here. Honestly, at a certain point I just gave up on trying to fix current std.regex, apparently a bit early. A quick test on this  would be r"^([\x00-\x80]*)\(([0-9]+)\):([\x00-\x80]*)$".


> Dmitry Olshansky's new std.regex also works, but it does not compile with warnings enabled (even not with -wi) ( http://d.puremagic.com/issues/show_bug.cgi?id=6518 ).
>
Btw I thought -wi is supposed to just list it as  warning. The embarrassing part comes from the fact that I actually picked up this foreach trick from original std.regex.

> Maybe it would be better to wait with deprecating std.regexp until there is a working alternative.
>
Given this fresh bug in std.regex I'd naturally agree.

> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
>
> I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.
>
Recalling last discussion on this, the users have to solve this on their own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.

> Otherwise, it seems the generated executable works fine.
>
> Rainer
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta


-- 
Dmitry Olshansky

From: "Dmitry Olshansky" <dmitry.olsh at gmail.com>
> On 20.08.2011 12:39, Rainer Schuetze wrote:
>> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
>>
>> I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.
>>
> Recalling last discussion on this, the users have to solve this on their own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.
> 

There's a simple alias trick that works very well for that sort of thing:

------------------------
module m1;
void a() {};
void b() {};
------------------------
module m2;
void b() {};
void c() {};
------------------------
module main;
import m1
import m2;

// Nifty trick: Pull m1's b() into local scope,
// effectively"prioritizing" it.
private alias m1.b b;

void main() {
    b(); // Works: Calls m1.b()
}
------------------------

On 21.08.2011 2:10, Nick Sabalausky wrote:
> From: "Dmitry Olshansky" <dmitry.olsh at gmail.com>
>> On 20.08.2011 12:39, Rainer Schuetze wrote:
>>> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
>>>
>>> I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.
>>>
>> Recalling last discussion on this, the users have to solve this on their own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.
>>
>
> There's a simple alias trick that works very well for that sort of thing:
>
> ------------------------
> module m1;
> void a() {};
> void b() {};
> ------------------------
> module m2;
> void b() {};
> void c() {};
> ------------------------
> module main;
> import m1
> import m2;
>
> // Nifty trick: Pull m1's b() into local scope,
> // effectively"prioritizing" it.
> private alias m1.b b;
>
> void main() {
>    b(); // Works: Calls m1.b()
> }
> ------------------------
>
Nice, I haven't thought of simple alias.
D is such a big handy toolbox, I can't hope to pull out of it  a proper
screwdriver all the time :)

-- 
Dmitry Olshansky

On 8/21/11, Nick Sabalausky <bus_dmdbeta at semitwist.com> wrote:
> // Nifty trick: Pull m1's b() into local scope,
> // effectively"prioritizing" it.
> private alias m1.b b;

I do this all the time since I'm getting symbol clashes between libraries every day, unfortunately. I never thought about the private vs public thing though, this completely slipped my mind.