On 21.08.2011 11:20, Rainer Schuetze wrote:
> On 20.08.2011 11:40, Dmitry Olshansky wrote:
>> 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:
>>>
>>> [...]
>>> 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]*)$".
>>
>
> Thanks for confirming. Your workaround works for this regular expression. But I also have a user input field that can be a regular expression, where ".*" would be nice to work out of the box. I could replace it with the range as a workaround, though.

Since it's the second time this special casing is failing I think it would better to get rid of it entirely, the release is just around the corner and surely it shouldn't the review of gsoc project. I'll do a pull request then.

Greetings

I know it might be a bit pre-mature, but I want to find if it might be possible to include this enhancement (thanks to Kenji Hara) into D.  I am working on a DSEL based on D and I find such a feature could help a lot with domain specific languages.

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

Regards
- Puneet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110821/e6c20764/attachment.html>

On 21 aug 2011, at 02:04, Jonathan M Davis wrote:

> On Saturday, August 20, 2011 18:10:01 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()
>> }
>> ------------------------
> 
> In theory, that's a great solution, but it doesn't work right now:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=6013
> 
> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta


Hasn't this issue already been reported? I've had this issue for several years, if I recall correctly.

-- 
/Jacob Carlborg

On 21 aug 2011, at 03:02, Andrew Wiley wrote:

> On Sat, Aug 20, 2011 at 5:02 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote: On Saturday, August 20, 2011 10:39:22 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.
> 
> All calls to functions in std.ctype should be replaced either with functions in std.ascii or functions std.uni. Functions with the identical names do the same thing except that those in std.uni operate on unicode, and those in std.ascii only operate on ascii (they still work with unicode characters; they just ignore them). If you need to use both std.ascii and std.uni, then you need to fully qualify them - e.g. std.ascii.isUpper or std.uni.isAlpha - or you need to create aliases for them.
> 
> On a somewhat related note, I wonder if this pull request could get reviewed in the near future (and hopefully a fix could make it into the next version):
> https://github.com/D-Programming-Language/dmd/pull/190
> (Fixes selective and renamed imports without having to touch overload resolution in the way discussed via email.)
> 
> This is probably the single most painful bug in DMD.
> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta


It would be great if this pull request could be accepted.

-- 
/Jacob Carlborg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110821/65eb0541/attachment-0001.html>

On Sunday 21 August 2011 10:36 Jonathan M Davis wrote:
> But it's worse that it creating a public alias. A don't believe that a public alias will conflict with what it's an alias for. However, selective imports currently create whole new symbols, so they _do_ conflict. Hopefully, the issue gets fixed soon.

Selective imports just generate alias declarations, so there's really no behavior difference between the two. And alias declarations don't even store the scope's protection, so protection attributes have no effect on them.

You'll get the same error message as in
http://d.puremagic.com/issues/show_bug.cgi?id=5161
if you used a static import and manually aliased b.B to B.

On 08/21/2011 03:05 AM, d coder wrote:
> Greetings
>
> I know it might be a bit pre-mature, but I want to find if it might be possible to include this enhancement (thanks to Kenji Hara) into D.  I am working on a DSEL based on D and I find such a feature could help a lot with domain specific languages.
>

I think it's safe to say that this will not make it into the next beta :o) Your question is more likely to get attention as it's own thread.

As to your question; Last I checked there was a vapor-ware macro feature on the future directions list that I think would cover your use case, and then some.

> http://d.puremagic.com/issues/show_bug.cgi?id=6207
>
> Regards
> - Puneet
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110821/6df126f6/attachment.html>

On 20 August 2011 10:39, Rainer Schuetze <r.sagitario at gmx.de> 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?

It was by design. The casting to pointer when initializing globals is
precisely because of these Windows casts.
Previously, the MAKEINTRESOURCEW function seemed to work but didn't do
what you'd expect. In many cases, instead of a constant, you were
getting a runtime function call to the  MAKEINTRESOURCEW function...
But I've just created a pull request
(https://github.com/D-Programming-Language/dmd/pull/326) which (among
other things) will allow your function to work in CTFE.

On 23.08.2011 00:21, Don Clugston wrote:
> On 20 August 2011 10:39, Rainer Schuetze<r.sagitario at gmx.de>  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?
> It was by design. The casting to pointer when initializing globals is
> precisely because of these Windows casts.
> Previously, the MAKEINTRESOURCEW function seemed to work but didn't do
> what you'd expect. In many cases, instead of a constant, you were
> getting a runtime function call to the  MAKEINTRESOURCEW function...
> But I've just created a pull request
> (https://github.com/D-Programming-Language/dmd/pull/326) which (among
> other things) will allow your function to work in CTFE.
>

Thanks for the quick fix, that brought it back to life.

MAKEINTRESOURCE is used at compile time in the windows headers, e.g.

const RT_CURSOR =           MAKEINTRESOURCE(1);

while I've been using it at runtime in my code, so it's good I don't have to make two different versions of the function.

(Thanks also to Walter for merging it in so fast, I was already wondering how I could get that pull request into my local repo).

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

Well, there seemed to be some limited consensus 2 weeks ago that it might be time for a beta, then the period of extended brokenness.  Now that we're back in a happy state, shall we?

Anyone have a 'really must be fixed before the next release' list?

As always, mine consists of the open regression bugs, but since I'm not personally investing in fixing any of them, it's poor form to gripe too much about them.

On 9/1/2011 12:37 AM, Brad Roberts wrote:
> Well, there seemed to be some limited consensus 2 weeks ago that it might be time for a beta, then the period of extended brokenness.  Now that we're back in a happy state, shall we?
>
> Anyone have a 'really must be fixed before the next release' list?

More like a 'really should be merged before next release list' since the fixes already exist in Github and have been sitting there for a long time with few comments and no action.  The std.range one is some features I really miss in Phobos and the std.parallelism one is such a massive under-the-hood improvement that it's a no-brainer:

https://github.com/D-Programming-Language/phobos/pull/219

https://github.com/D-Programming-Language/phobos/pull/217