www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A simple question

reply "Stugol" <stugol gmx.com> writes:
When I post on these forums to ask for new features (e.g. 
iterators), you say that you won't be adding any new features at 
the moment, and that you are instead concentrating on making the 
language stable and usable.

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.

So what the fuck's the point? D is a great language, and I really 
want to use it, but it doesn't work. And when I post here about 
its flaws and limitations, I get flamed.
Nov 15 2012
next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote:

 When I post on these forums to ask for new features (e.g. 
 iterators), you say that you won't be adding any new features 
 at the moment, and that you are instead concentrating on making 
 the language stable and usable.

 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.

 So what the fuck's the point? D is a great language, and I 
 really want to use it, but it doesn't work. And when I post 
 here about its flaws and limitations, I get flamed.


This forum isn't a bug tracking system. It is for discussion, in 
relation to bugs that means identifying it it really is a bug and 
deciding on the priority of that bug over other goals. To say 
that being told you won't see it any times soon is "flaming" is 
exaggeration.

If you have a real example of flames then please do bring that 
forward, but there isn't much the community will be able to do 
about it.

There is a lot of issues in D, selection isn't always objective 
and direction isn't well documented at this point. Many times it 
can seem a voice isn't being heard and suddenly its taken care of.

Really you just need to convince one person it is of priority, 
that person will need the skill/initiative to implement it and 
submit the changes, and maybe that person is yourself. Luckily 
that list of people is growing and not shrinking.
Nov 15 2012
parent "Stugol" <stugol gmx.com> writes:
On Thursday, 15 November 2012 at 22:43:22 UTC, Jesse Phillips 
wrote:

 To say that being told you won't see it any times soon is 
 "flaming" is exaggeration.

 If you have a real example of flames then please do bring that 
 forward, but there isn't much the community will be able to do 
 about it.


I was told to "fuck off" and to "stop wasting everyone's time" 
when I was just trying to discuss bugs in the language. If that's 
not a flame, I don't know what is.


 There is a lot of issues in D, selection isn't always objective 
 and direction isn't well documented at this point. Many times 
 it can seem a voice isn't being heard and suddenly its taken 
 care of.

 Really you just need to convince one person it is of priority, 
 that person will need the skill/initiative to implement it and 
 submit the changes, and maybe that person is yourself. Luckily 
 that list of people is growing and not shrinking.


Well, last I heard, the two bugs I just mentioned weren't going 
to be fixed. So wtf?
Nov 15 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Nov 15 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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.


To clarify: My intent is not to be picky, but you make it sound 
like a legitimate bug report was dismissed without giving any 
reasons for that. I find it hard to imagine that this would be 
the case.

David
Nov 15 2012
prev sibling parent reply "Stugol" <stugol gmx.com> writes:
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?
Nov 15 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.

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]

And it should then spit out a working executable without much 
hassle. Any libraries you use should be on that command line too, 
add the .libs as well as your .ds.
Nov 15 2012
parent reply "Stugol" <stugol gmx.com> writes:
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.
Nov 15 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Nov 15 2012
parent reply "Stugol" <stugol gmx.com> writes:
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?
Nov 15 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Nov 15 2012
parent reply "Stugol" <stugol gmx.com> writes:
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"?
Nov 15 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 16 Nov 2012 03:55:53 +0100
"Stugol" <stugol gmx.com> wrote:


 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?
 


It sounds like you're using something that does automatic dependency
tracking, like RDMD (maybe VisualD uses RDMD behind the scenes?) The
only way those *can* work is of the filename/path matches (othewrwise,
if it needs to find a module named "foo.bar.bat", it has no way to know
where to find it if it's not in something named "foo/bar/bat.d").

In order to have module/package names that differ from the file/path
names, the only way for that to work is if you pass those files in
explicitly. Otherwise the compiler or build system would have to read
every file on your computer hoping to find one that included the text
"module foo.bar.bat;". Naturally, that wouldn't be a good idea ;)

Since it can be a pain to track all of your files manually, most people
just follow the "module/package name == file/path name" convention so
they can use an auto-dependency tool like RDMD.



 Also, I'm having difficulty specifying a default specialisation 
 for a template class:
 
     class Event(TEventArgs : EventArgs = EventArgs) {
     }


That would probably normally be:

    class Event(TEventArgs = EventArgs) {
    }

Unless you really are requiring that TEventArgs must be either
EventArgs or something derived from EventArgs. (Maybe you are?)


 
 Usage:
 
     Event!() e1;     // Works
     Event e2;        // Won't compile
 
 How can I have "Event" be an alias for "Event!EventArgs"?


I think function templates are the only kind that can be instantiated
without the "!()" part. So "Event" just refers to the template itself,
not the class inside it.

You may be able to do this:

    alias Event!() Event;

But I don't know if that would result in a naming conflict.
Nov 15 2012
parent "Stugol" <stugol gmx.com> writes:
On Friday, 16 November 2012 at 03:24:28 UTC, Nick Sabalausky 
wrote:

 Unless you really are requiring that TEventArgs must be either
 EventArgs or something derived from EventArgs. (Maybe you are?)


I am.


 You may be able to do this:

     alias Event!() Event;

 But I don't know if that would result in a naming conflict.


It does.
Nov 15 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote:

 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?


I haven't used VisualD but I suspect it is assuming filenames 
based on import declarations.

You don't have to do it this way though. If all the modules are 
passed on the one command, with a manual listing, the filename 
doesn't matter. It only uses the module line then. That's useful 
for times when your folder structure doesn't exactly match.


Let me give you an example. For one of my work projects, we 
compile it differently for different clients. What I do is have a 
bunch of different configuration/customization files:

custom_acme.d
custom_bugs.d
custom_daffy.d

Each of these has the same module line:

module myproduct.configuration;
/* then various config variables and little customizations are 
next */


Then the main app never knows about the different clients. It 
just does

import myproduct.configuration;

and it all just works. Now, if I want to build the one for Acme, 
I do: dmd myapp.d custom_acme.d, and it is good.

If I want to make the one for Bugs, I just do: dmd myapp.d 
custom_bugs.d and have their version.

If they buy a source license, I can send just their file without 
changing anything else and without exposing any of the other 
client's custom code.



It's something you might never need, but is really nice to have 
when it does come up.


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


Yea... even with default args, you still have to use the !() to 
tell it that you actually want the template instantiated.

One option would be to do something like this:

class EventBase(int a = 0) {
}

alias EventBase!(0) Event;

void main() {
         EventBase!() e1;
         Event e2;
}


The alias line can include template arguments and then will work. 
But it needs to have a different name than the class itself so 
the names don't conflict.


I don't think there's any other way... either has to be Event!() 
like you had, or use the alias like I did here.
Nov 15 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote:


 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"?


I encountered this same "wtf???" today. Apparently, even with a 
default type specified, you still have to put in a !(). I don't 
know what the reasoning was behind making this seeming redundancy 
a requirement, and it partially defeats the purpose of the 
default. IN my case I wanted the default type to be selected when 
left unspecified, but also to get rid of the !() requirement for 
a more natural appearance. I was planning on asking about this in 
the forums later.

In any case, a simple work-a-round solution is to create an 
alias, for example:

alias Event!() Event_t;
// you may substitute "Event_t" with whatever type name you want

Event_t e2;        // Will compile!

BTW, I come from a C++ background, and I found that certain parts 
of D were more difficult to learn perhaps because of my C++ 
background. I think this may be because I expected things like 
modules to work like .h files, but they don't, or I expected copy 
and move semantics to work the same way in D but they don't, or I 
expected structs and classes to be similar to what C++ provides, 
but they are in fact very different in terms of how they operate. 
The GC is another matter to get used to. The worse of it is a 
lack of detailed documentation. The very best thing you can do, 
is get a copy of "The D Programming Language", there's also an 
on-line tutorial e-book, translated from Turkish into English 
over here http://ddili.org/ders/d.en/index.html but it is not yet 
fully translated.

Good luck, and have some patience, you'll need it.

--rt
Nov 15 2012
prev sibling parent reply "Rob T" <rob ucora.com> writes:
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote:


 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"?


I encountered this same "wtf???" today. Apparently, even with a 
default type specified, you still have to put in a !(). I don't 
know what the reasoning was behind making this seeming redundancy 
a requirement, and it partially defeats the purpose of the 
default. IN my case I wanted the default type to be selected when 
left unspecified, but also to get rid of the !() requirement for 
a more natural appearance. I was planning on asking about this in 
the forums later.

In any case, a simple work-a-round solution is to create an 
alias, for example:

alias Event!() Event_t;
// you may substitute "Event_t" with whatever type name you want

Event_t e2;        // Will compile!

BTW, I come from a C++ background, and I found that certain parts 
of D were more difficult to learn perhaps because of my C++ 
background. I think this may be because I expected things like 
modules to work like .h files, but they don't, or I expected copy 
and move semantics to work the same way in D but they don't, or I 
expected structs and classes to be similar to what C++ provides, 
but they are in fact very different in terms of how they operate. 
The GC is another matter to get used to. The worse of it is a 
lack of detailed documentation. The very best thing you can do, 
is get a copy of "The D Programming Language", there's also an 
on-line tutorial e-book, translated from Turkish into English 
over here http://ddili.org/ders/d.en/index.html but it is not yet 
fully translated.

Good luck, and have some patience, you'll need it.

--rt
Nov 15 2012
parent reply "Stugol" <stugol gmx.com> writes:
On Friday, 16 November 2012 at 03:32:06 UTC, Rob T wrote:

 I encountered this same "wtf???" today. Apparently, even with a 
 default type specified, you still have to put in a !(). I don't 
 know what the reasoning was behind making this seeming 
 redundancy a requirement, and it partially defeats the purpose 
 of the default. IN my case I wanted the default type to be 
 selected when left unspecified, but also to get rid of the !() 
 requirement for a more natural appearance. I was planning on 
 asking about this in the forums later.


I agree.


 In any case, a simple work-a-round solution is to create an 
 alias, for example:

 alias Event!() Event_t;
 // you may substitute "Event_t" with whatever type name you want

 Event_t e2;        // Will compile!


Yeah but that kinda blows, doesn't it?


 best thing you can do, is get a copy of "The D Programming 
 Language"

 Good luck, and have some patience, you'll need it.


Already got it somewhere, I think. And thanks.
Nov 15 2012
parent reply "Rob T" <rob ucora.com> writes:
On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:

 Event_t e2;        // Will compile!


 Yeah but that kinda blows, doesn't it?


I found it surprising or unintuitive that the !() is required, 
and I do want to know what is the reasoning behind it, but it's 
not that big of a deal because the power that "alias" gives you 
is amazing, and makes a problem like this go away once you start 
using it correctly. Also don't loose sight of the fact that D has 
a whole lot more that is good than is bad. I find the better a 
language is I actually get more picky about things that I don't 
like. A garbage language is, well garbage, so I tend to care much 
less if it sucks. So to see me complain, is actually a good 
thing, it means I like it and want to see if get better.

--rt
Nov 15 2012
next sibling parent reply "jerro" <a a.com> writes:
 I found it surprising or unintuitive that the !() is required, 
 and I do want to know what is the reasoning behind it


I don't know whether the language could be changed to support 
code like:

struct Foo(){}
Foo foo;

but doing that certainly would introduce some ambiguities. For 
example, consider this line:

alias Foo Bar;

Should Bar be a template or an instance of a template here?
Nov 15 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 16 November 2012 at 04:26:31 UTC, jerro wrote:

 I found it surprising or unintuitive that the !() is required, 
 and I do want to know what is the reasoning behind it


 I don't know whether the language could be changed to support 
 code like:

 struct Foo(){}
 Foo foo;

 but doing that certainly would introduce some ambiguities. For 
 example, consider this line:

 alias Foo Bar;

 Should Bar be a template or an instance of a template here?


OK, now it makes sense, I figured there had to be a reason for 
the !(). Thanks for letting me know.

--rt
Nov 15 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-16 05:26, jerro wrote:


 I don't know whether the language could be changed to support code like:

 struct Foo(){}
 Foo foo;

 but doing that certainly would introduce some ambiguities. For example,
 consider this line:

 alias Foo Bar;

 Should Bar be a template or an instance of a template here?


Any place where a template and an instantiation is allowed it will 
default to a template. The user would then need to explicitly add !() to 
indicate an instantiation. In all other places, it will be an instantiation.

I think in most cases using just a template is not allowed.

-- 
/Jacob Carlborg
Nov 15 2012
prev sibling parent reply Don Clugston <dac nospam.com> writes:
On 16/11/12 05:15, Rob T wrote:

 On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:

 Event_t e2;        // Will compile!


 Yeah but that kinda blows, doesn't it?


 I found it surprising or unintuitive that the !() is required, and I do
 want to know what is the reasoning behind it,


One of the oldest open enhancement requests is on this topic:

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

I don't what the reason is. It'd be interesting to revive the patch 
there, and see if it passes the compiler test suite.
Nov 16 2012
next sibling parent kenji hara <k.hara.pg gmail.com> writes:
Now I'm working that.

Kenji Hara

2012/11/16 Don Clugston <dac nospam.com>


 On 16/11/12 05:15, Rob T wrote:


 On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:


 Event_t e2;        // Will compile!


 Yeah but that kinda blows, doesn't it?


 I found it surprising or unintuitive that the !() is required, and I do
 want to know what is the reasoning behind it,


 One of the oldest open enhancement requests is on this topic:

 http://d.puremagic.com/issues/**show_bug.cgi?id=1012<http://d.puremagic.com/issues/show_bug.cgi?id=1012>

 I don't what the reason is. It'd be interesting to revive the patch there,
 and see if it passes the compiler test suite.





 Nov 16 2012



prev sibling next sibling parent  kenji hara <k.hara.pg gmail.com>  writes:


Done.
https://github.com/D-Programming-Language/dmd/pull/1295

Kenji Hara

2012/11/16 kenji hara <k.hara.pg gmail.com>


 Now I'm working that.

 Kenji Hara

 2012/11/16 Don Clugston <dac nospam.com>


 One of the oldest open enhancement requests is on this topic:

 http://d.puremagic.com/issues/**show_bug.cgi?id=1012<http://d.puremagic.com/issues/show_bug.cgi?id=1012>

 I don't what the reason is. It'd be interesting to revive the patch
 there, and see if it passes the compiler test suite.







 Nov 16 2012



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 11/16/12, kenji hara <k.hara.pg gmail.com> wrote:

 Done.
 https://github.com/D-Programming-Language/dmd/pull/1295


Have you seen this comment:

On 11/16/12, jerro <a a.com> wrote:

 doing that certainly would introduce some ambiguities. For
 example, consider this line:

 alias Foo Bar;

 Should Bar be a template or an instance of a template here?





 Nov 16 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-16 11:16, Andrej Mitrovic wrote:


 Have you seen this comment:

 On 11/16/12, jerro <a a.com> wrote:

 doing that certainly would introduce some ambiguities. For
 example, consider this line:

 alias Foo Bar;

 Should Bar be a template or an instance of a template here?




And my reply to that comment:

Any place where a template and an instantiation is allowed it will 
default to a template. The user would then need to explicitly add !() to 
indicate an instantiation. In all other places, it will be an instantiation.

I think in most cases using just a template is not allowed.

-- 
/Jacob Carlborg



 Nov 16 2012



prev sibling  parent  "Jesse Phillips" <jessekphillips+D gmail.com>  writes:


On Friday, 16 November 2012 at 00:55:36 UTC, Stugol wrote:

 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.


So I'm going to have to claim this isn't a bug. And I know very 
little about how to address this issue with VisualD. For this 
reason I can't just give you an answer and instead I'll have to 
explain what you are being told so that you can find the missing 
piece. And as I don't know your experience it may sound as though 
I'm talking down to you.

While this may seem a nitpick it is an important distinction. 
This is not a compiler error, it is from the linker. This means 
your program has has compiled successfully.

The role of the linker is to find the machine code that can 
execute function calls you have made.

 From your link I see that your are using DFL, This is generally 
built into a library and then the linker is told to grab it. And 
I believe you'll need to tell it to build a windows executable: 
/exet:nt/su:windows:4.0

http://wiki.dprogramming.com/Dfl/SetupInstructions

Onto the optional module statement. It is optional, but the name 
is derived from the directory and file structure at the place of 
compilation. So if VisualD does some incremental compilation from 
within a folder then the module will not be named what you are 
looking it up as. If this is the case then maybe the VisualD 
project has a bug here. I'm more incline to believe that you've 
attempted a combination of parts and just don't know how they fit 
together.

The only way to improve on this situation is to write a tutorial 
on how to fit x, y and z together and make a whole. Generally 
this would come from the one trying to fit these pieces together 
as everyone has their own desired combinations. You may convince 
someone to give it a try, but you'll make it much more likely 
with a reduced case that demonstrates the problem, Run is not an 
entry into a program. I have had my share of difficult/impossible 
reductions, but I can't imagine you're very far with having run 
into this problem.



 Nov 15 2012



prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at>  writes:


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.

It has been agreed on that usability issues such as this are 
important, particularly because they mostly affect newcomers and 
might scare them away. The issue just is that nobody has found 
the time to work on this yet – the main compiler devs 
intuitively tend to focus on the »meaty« issues which actually 
cause the language to behave incorrectly for _all_ users. Also, 
if you are used to working on compilers, error messages such as 
the one you posted are naturally easy to understand, which might 
lead to some perception bias regarding usability.

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

David



 Nov 15 2012



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Friday, 16 November 2012 at 00:29:24 UTC, David Nadlinger 
wrote:

 Granted, the diagnostics for it are terrible, you just get to 
 see the raw linker error message.


This is potentially very easy to fix...

$ cat demangle.d
import core.demangle;
import std.stdio;
import std.regex;

string dem(Captures!(char[], uint) m) {
         return demangle(m.hit).idup;
}

void main(string[] args) {
         if(args.length > 1) {
                 foreach(arg; args[1..$])
                         writeln(demangle(arg));
                 return;
         }

         foreach(line; stdin.byLine) {
                 writeln(line.replace!dem(regex("_D[a-zA-Z0-9_]+", 
"g")));
         }
}

$ cat /home/me/demangle_gcc


exec gcc $* 2>&1 | /home/me/demangle

$ export CC=/home/me/demangle_gcc

$ dmd test2.d
test2.o: In function `_Dmain':
test2.d:(.text._Dmain+0x34): undefined reference to 
`_D9something1A7__ClassZ'
test2.d:(.text._Dmain+0x41): undefined reference to `something.A 
something.A.__ctor(int)'
collect2: ld returned 1 exit status


A little more readable than 
`_D9something1A6__ctorMFiZC9something1A'!


core.demangle apparently has some bugs, but these simple little 
scripts help to beautify the linker output without actually 
changing anything.

On Windows, the environment variable LINKCMD is used instead of 
CC. Other than that and other little details, I'm sure the same 
approach would work.


Now, append "CC=/home/me/demangle_gcc" to your dmd.conf... and 
there's now no need to set the environment variable in your shell.


So if we made those demangle scripts and put them in the zip with 
dmd, then changed dmd.conf to use the helper script 
(CC=% P%demangle_gcc on linux, LINKCMD=demangle_link.bat on 
windows).... and there you go, demangled linker output.

A fancier script could detect things like ModuleInfo and give a 
helpful hint afterwards.



 Nov 15 2012



prev sibling  parent  "Stugol" <stugol gmx.com>  writes:


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?



 Nov 15 2012



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Nov 15 2012



  parent  "Bernard Helyer" <b.helyer gmail.com>  writes:


On Friday, 16 November 2012 at 01:00:58 UTC, Walter Bright wrote:

 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.


I'm still about.


 Bernard was certainly out of line with that remark


Absolutely. I let the NG get under my skin too much. I'm trying to
be a reformed man!



 Nov 18 2012



prev sibling  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


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=20
 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=20
 fixed (e.g. the defective MODULE keyword, or the linker not=20
 supporting spaces in paths), you say that's not going to=20
 happen anytime soon.


 Please provide links to that statements and the respective=20
 Bugzilla issues. Otherwise, this is a quite =E2=80=A6 unsubstantial=20
 claim.

 David


=20
 I didn't use BugZilla, I posted on the forum. It was a few months=20
 ago. Feel free to search the forums for my name if you care.=20
 There aren't many threads with my name.
=20
 As to the module bug, I refer you to this error I just received=20
 after trying to use D again after a long absence:
=20
 "Error 42: Symbol Undefined=20
 _D8infinity8standard3api7windows12__ModuleInfoZ
 d:\Documents\Programming\WindowsApp1\WindowsApp1\"
=20
 I reported the above bug in this thread months ago:=20
 http://www.google.com/url?sa=3Dt&rct=3Dj&q=3Dstugol&source=3Dweb&cd=3D1&c=


ad=3Drja&ved=3D0CC8QFjAA&url=3Dhttp%3A%2F%2Fwww.digitalmars.com%2Fd%2Farchi=
ves%2Fdigitalmars%2FD%2FIncomprehensible_compiler_errors_173731.html&ei=3DZ=
4OlUKqOO6Oi0QWir4DAAg&usg=3DAFQjCNFlgFDSwgjBEWUA1SbimjMK6kNwFg

=20
 Nothing has been done: the bug still exists. Coincidentally, this=20
 was the same thread I was told to fuck off in.
=20
 Are these bugs likely to be addressed, or am I likely to be told=20
 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=3D2=
#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.



 Nov 15 2012



  parent  Rainer Schuetze <r.sagitario gmx.de>  writes:


On 11/16/2012 4:08 AM, Nick Sabalausky wrote:

 On Fri, 16 Nov 2012 01:11:18 +0100
 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.


Even though the discussion seems to have cooled down, I'd like to 
clarify a number of speculations:

Visual D compiles the files that are added to the project, not anything 
imported as rdmd does (I think this does not scale for larger projects 
where you better use libraries for sub-projects).

Visual D does not use incremental builds because this causes linker 
problems due to missing symbols. Judging from single file compilation it 
won't even reduce build times because import dependencies cause almost 
everything is compiled or at least semantically analyzed anyways (though 
this might be with my projects only).

As of 0.3.34 Visual D demangles the linker output (if not explicitely 
disabled in the options).



 Nov 17 2012



prev sibling  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Stugol:


 And when I post here about its flaws and limitations, I get 
 flamed.


 From your post you link below:


 I'm trying to write an actual program in D, but no matter what 
 I do I get stupid errors that mean nothing to me. (Reminds me 
 of C++)
 ...
 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.

Bye,
bearophile



 Nov 15 2012



  parent reply "Stugol" <stugol gmx.com>  writes:


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.



 Nov 15 2012



  parent  "jerro" <a a.com>  writes:


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


That post was actually the very first post in the thread.



 Nov 15 2012