November 16, 2012
On Friday, 16 November 2012 at 00:20:00 UTC, Adam D. Ruppe wrote:
> On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote:
>> As to the module bug, I refer you to this error I just received after trying to use D again after a long absence:
>>
>> "Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ	d:\Documents\Programming\WindowsApp1\WindowsApp1\"
>
> That means the your custom module wasn't given on the final command line.

I'm using VisualD. I don't have a final command line.

> The easiest way to build a D program is to put all your files on the command line at once:
>
> dmd main.d helper.d infinity/standard/api/windows.d [etc etc etc]

See above.

(Yes, I know there will be a command line somewhere, but it's nothing to do with me)

The point is, it says that kind of crap all the time. Even when it doesn't, if I take the MODULE statement out, it comes back. The module keyword is supposed to be optional.
November 16, 2012
On Friday, 16 November 2012 at 00:29:24 UTC, David Nadlinger wrote:
> On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote:
>> Are these bugs likely to be addressed, or am I likely to be told to fuck off again?
>
> Ah, now things become clearer. The issue here is that what you are describing is not an actual bug, but the consequence of you not specifying one of the source files you imported as part of the compiler command (use rdmd if you don't want to deal with such things). Granted, the diagnostics for it are terrible, you just get to see the raw linker error message.

No, this happens if I omit the optional MODULE statement at the top of the file as well. And, as I recall, at other times.

> In general, things such as this would be a great first problem to attack for somebody interesting in compiler development.

How fascinating. Got anyone particular in mind?
November 16, 2012
On Friday, 16 November 2012 at 00:39:48 UTC, bearophile wrote:
> Stugol:
>>
>> Huh? This usually happens if I omit the module statement at the top of EVERY DAMN FILE (why???) but in this case I haven't omitted it, yet I'm still getting the error.
>> ...
>> What the HELL is this "ModuleInfo", why is it necessary, why is it always missing when a "module" statement is not present, and why is it missing NOW?
>
> Even if the bugs actually exist, and aren't problems in what you are doing, posts that contain similar aggressiveness are less likely to be answered nicely. If you want nice answers, be first of all gentle yourself.

I believe this post occurred *after* I had already been met with
hostility.

November 16, 2012
On 11/15/2012 4:11 PM, Stugol wrote:
> am I likely to be told to fuck off again?

I haven't seen Bernard lately, so probably not. Bernard was certainly out of line with that remark, but we try not to censor people here. Peoples' comments are their own responsibility.
November 16, 2012
On Friday, 16 November 2012 at 00:55:36 UTC, Stugol wrote:
> The point is, it says that kind of crap all the time. Even when it doesn't, if I take the MODULE statement out, it comes back. The module keyword is supposed to be optional.

Oh, I see what's going on now.

The module thing is only optional in simple cases, where the name has no dots and matches the filename.

If you are using packages, the module line is required to get that full name registered in the file.
November 16, 2012
> I believe this post occurred *after* I had already been met with
> hostility.

That post was actually the very first post in the thread.
November 16, 2012
On Friday, 16 November 2012 at 01:14:18 UTC, Adam D. Ruppe wrote:
>
> The module thing is only optional in simple cases, where the name has no dots and matches the filename.
>
> If you are using packages, the module line is required to get that full name registered in the file.

Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation.

Yes, I read the documentation. All of it. Did I mention I really liked the language?
November 16, 2012
On Friday, 16 November 2012 at 02:00:05 UTC, Stugol wrote:
> Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation.

It might not be clear, but it is there:

http://dlang.org/module.html
"The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name."

The parenthesis is important in this case - once the name is stripped of path, it only leaves a simple name, no more package info.
November 16, 2012
On Friday, 16 November 2012 at 02:22:32 UTC, Adam D. Ruppe wrote:
> On Friday, 16 November 2012 at 02:00:05 UTC, Stugol wrote:
>> Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation.
>
> It might not be clear, but it is there:
>
> http://dlang.org/module.html
> "The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name."
>
> The parenthesis is important in this case - once the name is stripped of path, it only leaves a simple name, no more package info.

I'm not quite sure what purpose the MODULE keyword serves in any case. I have a file "Include.D\Infinity\Standard\Mixins\Event.d", but if I give it a module name of "infinity.standard.event" it doesn't work. I have to include the ".mixins" part. So what's the point?

Also, I'm having difficulty specifying a default specialisation for a template class:

   class Event(TEventArgs : EventArgs = EventArgs) {
   }

Usage:

   Event!() e1;     // Works
   Event e2;        // Won't compile

How can I have "Event" be an alias for "Event!EventArgs"?
November 16, 2012
On Fri, 16 Nov 2012 01:11:18 +0100
"Stugol" <stugol@gmx.com> wrote:

> On Thursday, 15 November 2012 at 23:56:49 UTC, David Nadlinger wrote:
> > On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote:
> >> However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon.
> >
> > Please provide links to that statements and the respective Bugzilla issues. Otherwise, this is a quite … unsubstantial claim.
> >
> > David
> 
> I didn't use BugZilla, I posted on the forum. It was a few months ago. Feel free to search the forums for my name if you care. There aren't many threads with my name.
> 
> As to the module bug, I refer you to this error I just received after trying to use D again after a long absence:
> 
> "Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\"
> 
> I reported the above bug in this thread months ago: http://www.google.com/url?sa=t&rct=j&q=stugol&source=web&cd=1&cad=rja&ved=0CC8QFjAA&url=http%3A%2F%2Fwww.digitalmars.com%2Fd%2Farchives%2Fdigitalmars%2FD%2FIncomprehensible_compiler_errors_173731.html&ei=Z4OlUKqOO6Oi0QWir4DAAg&usg=AFQjCNFlgFDSwgjBEWUA1SbimjMK6kNwFg
> 
> Nothing has been done: the bug still exists. Coincidentally, this was the same thread I was told to fuck off in.
> 
> Are these bugs likely to be addressed, or am I likely to be told to fuck off again?


You came in abusive right from the first post in the thread, continued making snide and contentious remarks even while *most* people were being polite (even *before* anyone got harsh with you), and you're continuing the abusiveness in parts of this thread, too. Maybe "fuck off" is overly harsh, but you certainly shouldn't be surprised that someone said it considering your consistently poor tone. What might be surprising though is that some of us are still willing to try to help.

Additionally, issues *are* being fixed all the time. If your particular ones haven't been among them yet, well, "them's the breaks". I have issues I've been patiently waiting for, too. So do other people. But being demanding certainly isn't going to get your issues addressed first. It's just going to piss people off and make them want to either ignore you or tell you to fuck off.

As for your specific issue, there's a few different factors:

1. Like other have already said, all the files need to be sent to DMD together (possibly by using RDMD) or, if not that, then at least their objects all need to be sent to the linker together. I realize you're using VisualD and therefore have reason to expect it to be taken care of automatically, but since something obviously might be going awry in that regard, you'll need to take it up with the VisualD developer. If you're nice to him, he might even be glad to help out.

2. If there is indeed an actual bug in the compiler or linker (instead of either VisualD or your project's VisualD settings), and you want it addressed promptly (keeping in mind this is a non-commercial venture and you're not paying anyone for support, so therefore there are NO timeframe guarantees), then it will help greatly if you provide a test case (and file it in the bug tracker: http://d.puremagic.com/issues/ ) which fully demonstrates the problem *without* having any reliance on any tool other than the compiler/linker itself. Yes, this means dealing with the command line.

3. The linker's error message needs to be better (as many people have already agreed with you on). The linker itself is written in highly-optimized assembly (and is in the process of being - very meticulously - converted to C for easier maintenance, as a stepping stone to it eventually moving to D), so changes to it *will be* slow. What *can* be done though, is to pipe its output through a D demangler, and in fact I think someone's already made such a tool. If you're not willing to use a direct command line to do that, then you can put in a request (not a demand) with the VisualD dev to have such functionality incorporated into VisualD. Or, although this may be a stretch, you could even offer to help incorporate the change to VisualD yourself.

4. I'm not sure I even see a specific problem in that thread that hasn't been addressed. First of all, it looks like your DFL problem was solved by including DFL in your VisualD project's dependencies. Secondly, I'm not getting your error when I try this:

http://forum.dlang.org/thread/souztdpadfefltnvckcg@forum.dlang.org?page=2#post-djjkyaqnwlsquticjfmw:40forum.dlang.org

Both of those files compile fine for me with DMD 2.060, and if I toss in a "void main() {}" I even get a working executable.