On 2/9/12, Walter Bright <walter at digitalmars.com> wrote:
> It's in the makefile now, but I guess I need to generate it!

My bad, I've assumed chmgen is distributed with DMD but it's in the dpl.org repository.

Anyway, I get these errors first:
chmgen.d(355): Error: std.ascii.newline at
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\ascii.d(44) conflicts
with std.string.newline at
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\string.d(184)
chmgen.d(371): Error: std.ascii.newline at
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\ascii.d(44) conflicts
with std.string.newline at
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\string.d(184)

Once I fix them to std.ascii.newline, I get a few runtime errors:
HHC5013: Error: URL reference in the TOC cannot be resolved:
"chm\download.html".
HHC5013: Error: URL reference in the TOC cannot be resolved: "chm\sitemap.html".
HHC5013: Error: URL reference in the TOC cannot be resolved:
"chm\phobos\index.html".
HHC5013: Error: URL reference in the TOC cannot be resolved:
"chm\32-64-portability.html".

The library reference isn't properly generated (it's missing). Also, I can't seem to change the font size. I've edited the ebook.css file and set all font sizes to 10px and courier new, but it doesn't change anything. I'll stick with the old generator from http://thecybershadow.net/d/docs/ for now.

> I'm also getting an error in cgcs.c line 354 on a "piece" of code that previously errored on line 162/cgcs.c (the fixed bug 6177). I will run dustmite on it and see where it comes from. Not sure if the two are related to the same root cause or if this is a regresseion.
>
The reduced case is:

---
struct S {
   float x;
   ~this() {}
}

void fun(T...)() { T x; }
void gun() { fun!S(); }
---

It looks similar but is no regression. Posted a bug report: http://d.puremagic.com/issues/show_bug.cgi?id=7474

Am 09.02.2012 17:29, schrieb Walter Bright:
>
>
> On 2/9/2012 6:24 AM, S?nke Ludwig wrote:
>> Artificial example (I have a different use case, but the pronciple is
>> similar):
>>
>> interface ILinkedListItem {
>>    LinkedListItem next();
>>    void next(LinkedListItem v);
>> }
>>
>> LinkedList objectStore;
>>
>> class C : protected ILinkedListItem {
>>    this()
>>    {
>>      objectStore.add(this);
>>    }
>>
>>    protected LinkedListItem next() {...}
>>    protected void next(LinkedListItem v) {...}
>> }
>>
>> So the intent is that you don't have access to these methods from the outside, but that C can still implement the interface to pass it only to certain receivers (the objectStore list in this case).
>>
>
> Wouldn't making ILinkedListItem private do the same thing?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
If it's in the same module, yes. But the more interesting case would be if the interface is in its own module (in my case it's even a different library).

Am 09.02.2012 17:27, schrieb Walter Bright:
>
>
> On 2/9/2012 1:48 AM, S?nke Ludwig wrote:
>>
>> Another thing is that while private selective imports are not public anymore, private renamed imports now conflict in other modules in this scenario:
>> ---
>> module a;
>> import std = b;
>> module b;
>> import a;
>> void f(){ std.stdio.writefln("X"); } // Error: std at  conflicts with
>> std at a.d(2)
>> ---
>
> I think it should conflict - can't have std as both an alias and a package.
Sorry, the example was incomplete and maybe a bit misleading:
---
module a;
private import std = b;
---
---
module b;
private import std.stdio;
void f(){ std.stdio.writefln("X"); } // conflict
---
So here the "b" import and its alias "std" in a is, or should be, private, as well as the std.stdio import in module b. I don't see why two private import statements should influence each other in an ideal world.

>
>>
>> I'm also getting an error in cgcs.c line 354 on a "piece" of code that previously errored on line 162/cgcs.c (the fixed bug 6177). I will run dustmite on it and see where it comes from. Not sure if the two are related to the same root cause or if this is a regresseion.
>>
>
Turns out it is no regression (occurs at least in 2.057). http://d.puremagic.com/issues/show_bug.cgi?id=7474

From: "Walter Bright" <walter at digitalmars.com>
> http://ftp.digitalmars.com/dmd2beta.zip

(This didn't seem to go though the first time...)

I've got some sort of weird problem with a certain usage of the "templateImpl!().result" idiom. Working on a test case...

>>> I'm also getting an error in cgcs.c line 354 on a "piece" of code that previously errored on line 162/cgcs.c (the fixed bug 6177). I will run dustmite on it and see where it comes from. Not sure if the two are related to the same root cause or if this is a regresseion.
>>>
>>
> Turns out it is no regression (occurs at least in 2.057). http://d.puremagic.com/issues/show_bug.cgi?id=7474

Yes, it's been ICEing since 2.053. Prior to that it was generating wrong code. Definitely not a regression.

From: "Nick Sabalausky" <bus_dmdbeta at semitwist.com>
> From: "Walter Bright" <walter at digitalmars.com>
>> http://ftp.digitalmars.com/dmd2beta.zip
> 
> (This didn't seem to go though the first time...)
> 
> I've got some sort of weird problem with a certain usage of the "templateImpl!().result" idiom. Working on a test case...
> 

http://d.puremagic.com/issues/show_bug.cgi?id=7475 Regression(2.058 beta): Template member erroneously inaccessible

On Thu, 09 Feb 2012 20:37:36 +0100, S?nke Ludwig <ludwig at informatik.uni-luebeck.de> wrote:

> Am 09.02.2012 17:27, schrieb Walter Bright:
>>
>>
>> On 2/9/2012 1:48 AM, S?nke Ludwig wrote:
>>>
>>> Another thing is that while private selective imports are not public anymore, private renamed imports now conflict in other modules in this scenario:
>>> ---
>>> module a;
>>> import std = b;
>>> module b;
>>> import a;
>>> void f(){ std.stdio.writefln("X"); } // Error: std at  conflicts with
>>> std at a.d(2)
>>> ---
>>
>> I think it should conflict - can't have std as both an alias and a package.
> Sorry, the example was incomplete and maybe a bit misleading:
> ---
> module a;
> private import std = b;
> ---
> ---
> module b;
> private import std.stdio;
> void f(){ std.stdio.writefln("X"); } // conflict
> ---

Private in it's current form doesn't controls access not visibility.

But then module b introduces "std" into it's own scope. If we'd follow the
usual
rule of symbol lookup, then there shouldn't be any conflict.

On 2/9/2012 11:37 AM, S?nke Ludwig wrote:
>
> ---
> module a;
> private import std = b;
> ---
> ---
> module b;
> private import std.stdio;
> void f(){ std.stdio.writefln("X"); } // conflict
> ---
> So here the "b" import and its alias "std" in a is, or should be, private, as well as the std.stdio import in module b. I don't see why two private import statements should influence each other in an ideal world.
>

The example doesn't make sense. Where is module a imported by module b?

On Thu, 09 Feb 2012 21:35:36 +0100, Walter Bright <walter at digitalmars.com> wrote:

> module b;
> private import std.stdio;
> void f(){ std.stdio.writefln("X"); } // conflict

The example is wrong, the bug is real.
I'll have a look at it.

The only thing I'd still like to see in the beta is the follow up to the
recent rename import fix, so that the whole module business can settle
finally.
https://github.com/D-Programming-Language/dmd/pull/674