On 30-Jul-12 22:43, Stuart wrote:
> I notice nobody so far seems to have any idea why I'm getting these errors.
Everybody knows it's a linker error.
Your particular message means you have link-in module dfl.internal.winapi.
e.g. by passing all files to dmd:
dmd you_module.d dfl\internal\winapi.d
Why would you use internal module of library is beyond me but regardless, a better way would be (if DFL is compiled to dfl.lib file):
dmd your_module.d dfl.lib
--
Dmitry Olshansky

On 30-Jul-12 23:45, Stuart wrote:
> On Monday, 30 July 2012 at 19:03:13 UTC, Dmitry Olshansky wrote:
>> Why would you use internal module of library is beyond me
>> Perhaps because nobody saw fit to define IsWindow() in module
> "core.sys.windows.windows"?
Yeah, it's woefully lacking. There is Win32 bindings project that covers all of WinAPI/DirectX/etc. (not sure about modern extensions as in Win7/8 but far better then built-in).
>> dmd your_module.d dfl.lib
>> No, that doesn't help. Because I'm getting this same shit when I import
> my OWN .d files:
It doesn't matter whose these file are. You need all of them passed to compiler (then it will link them together) or split them in packs and compile to libraries and then pass to linker.
D compiler doesn't link in dependencies automatically the reason for this was "too much magic" and "hard to override" (e.g. what if it picks
up wrong libraries and/or files?).
So for humans the way to go is to use rdmd tool that deduces all dependencies if you pass it one main file.
This will compile all files and execute you app (it also rebuilds only if files change):
rdmd mymain.d
or to only build app (not execute):
rdmd --build-only mymain.d
--
Dmitry Olshansky

On Monday, 30 July 2012 at 20:04:25 UTC, Dmitry Olshansky wrote:
> On 30-Jul-12 23:45, Stuart wrote:
>> No, that doesn't help. Because I'm getting this same shit when I import
>> my OWN .d files:
>> It doesn't matter whose these file are. You need all of them passed to compiler (then it will link them together) or split them in packs and compile to libraries and then pass to linker.
>> D compiler doesn't link in dependencies automatically the reason for this was "too much magic" and "hard to override"
Well I'm using VisualD, and have both projects in my solution. Is there some option I ought to be setting? I can't go running arbitrary commandlines all over the shop.

On Monday, 30 July 2012 at 20:08:34 UTC, Stuart wrote:
> Well I'm using VisualD, and have both projects in my solution. Is there some option I ought to be setting? I can't go running arbitrary commandlines all over the shop.
Nvm, I got it. "Project Dependencies" dialog.

On 7/30/2012 9:31 AM, Stuart wrote:
> 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++)
>> Error 42: Symbol Undefined
> _D8infinity8standard7runtime4IApp4IApp11__InterfaceZ
This means module infinity, and standard.runtime.Iapp ...
> 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.
It's likely that you aren't presenting the compiled version of inifinity.obj to the linker.
> Also, I get the following error:
>> Error 42: Symbol Undefined
> _D3dfl8internal6winapi12__ModuleInfoZ>> The code producing this second error is:
>> int Run() {
> import core.sys.windows.windows;
> import dfl.internal.winapi;
> MSG msg;
> while (GetMessageA(&msg, null, 0, 0)) {
> TranslateMessage(&msg);
> DispatchMessageA(&msg);
> if (msg.hwnd && !IsWindow(msg.hwnd)) break;
> }
> return 0;
> }
>> 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?
A ModuleInfo is generated for each compiled module and inserted into its corresponding .obj file. If the linker cannot find it, then it is likely that you need to specify that .obj on the link command.

On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote:
>> A ModuleInfo is generated for each compiled module and inserted into its corresponding .obj file. If the linker cannot find it, then it is likely that you need to specify that .obj on the link command.
Ah, it would seem that my problem is with DFL not compiling. Look guys, I'm about ready to give up here. I like the idea of D, but it's like using fucking Linux: Absolutely everything needs to be compiled before you can use it; and nothing will compile because you need to do fifty other goddamn things that aren't mentioned in the readme, so you have to post on dozens of sodding forums for a week hoping someone throws you a bone.
All I want is to be able to write a GUI application using phrases like "button1.dock = Fill". Is that so much to ask? Apparently it is.
DFL won't compile. D-IDE doesn't work at all. VisualD crashes all the time. The Eclipse IDE plugin doesn't work either. None of the IDEs have any kind of reliable intellisense. The optional "module" keywords aren't optional. The whole fucking thing's a shambles, just like everything else designed for Linux.
It's really getting on my tits. Even using MFC is easier than this.

Stuart:
> I'm about ready to give up here. I like the idea of D, but it's like using fucking Linux:
I understand. The troubles you find are present in widely used languages. D is a young language and it's not widespread, so you are going to find even more problems.
> All I want is to be able to write a GUI application using phrases like "button1.dock = Fill". Is that so much to ask? Apparently it is.
Take a look at the Rebol language. Unlike D it imposes you big limits, but it's a language designed for the programmer, and not for the machine:
http://rebol.com/
Bye,
bearophile

On 7/30/12 6:54 PM, Stuart wrote:
> Ah, it would seem that my problem is with DFL not compiling. Look guys,
> I'm about ready to give up here. I like the idea of D, but it's like
> using fucking Linux: Absolutely everything needs to be compiled before
> you can use it; and nothing will compile because you need to do fifty
> other goddamn things that aren't mentioned in the readme, so you have to
> post on dozens of sodding forums for a week hoping someone throws you a
> bone.
I empathize. The one thing that may be different is that the forums at forum.dlang.org tend to be a bit more responsive and to the point.
> All I want is to be able to write a GUI application using phrases like
> "button1.dock = Fill". Is that so much to ask? Apparently it is.
>> DFL won't compile. D-IDE doesn't work at all. VisualD crashes all the
> time. The Eclipse IDE plugin doesn't work either. None of the IDEs have
> any kind of reliable intellisense. The optional "module" keywords aren't
> optional. The whole fucking thing's a shambles, just like everything
> else designed for Linux.
>> It's really getting on my tits. Even using MFC is easier than this.
The irony there is that dmd has started as a Windows program.
Andrei

On Monday, 30 July 2012 at 23:07:35 UTC, bearophile wrote:
> Stuart:
>>> I'm about ready to give up here. I like the idea of D, but it's like using fucking Linux:
>> I understand. The troubles you find are present in widely used languages. D is a young language and it's not widespread, so you are going to find even more problems.
The problem isn't that it's a young language; the problem is that it follows the Linux ideology - which, in a nutshell, is "make the user compile every damn thing, and make the user type everything longhand in emacs".
It's not D itself I have a problem with. It's the complete lack of reliable tools for it. No IDE. No GUI designer. No nothing. Coding a real application in D is like using Cobra, or Nemerle - in short, frustrating and slow.
>> All I want is to be able to write a GUI application using phrases like "button1.dock = Fill". Is that so much to ask? Apparently it is.
>> Take a look at the Rebol language.
I took a quick look. It didn't look like anything suitable for creating native GUI applications. It looked totally insane.