"DFL won't compile"

It doesn't matter if the fix is trivial, easy, whatever. It does not compile, therefore D sux.

-------- Original Message --------
Subject: Re: Incomprehensible compiler errors
Date: Tue, 31 Jul 2012 00:54:58 +0200
From: Stuart <stugol@gmx.com>
Organization: Digital Mars
Newsgroups: digitalmars.D
References: <souztdpadfefltnvckcg@forum.dlang.org> <jv6v0j$1c4g$1@digitalmars.com>

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.


_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

I just tried the latest compiler for my project. In my own code I had to change some code from deprecation.

As for DFL, it looks to all be due to bug fixes (haven't resolved the issues so more may be hidden). In the past it has broken from const changes.

form.d(493): Error: function
dfl.application.Application.addMessageFilter (IMessageFiltermf) is not
callable using argument types (const(FormMessageFilter))
form.d(2569): Error: function
dfl.application.Application.removeMessageFilter (IMessageFilter mf) is
not callable using argument types (const(FormMessageFilter))

Hmm, const variable can't be passed as non-const? Pretty sure that should not have worked to begin with.

drawing.d(3630): Error: enum member DISPLAY not represented in final switch
splitter.d(264): Error: enum member NONE not represented in final switch
splitter.d(264): Error: enum member FILL not represented in final switch

Final switch not containing enum value? hmm, pretty sure that should have been an error already.

So aside from not fixing bugs, it seems this was unavoidable. And note in the email there was another complaint hidden there.

"Absolutely everything needs to be compiled before you can use it"

The linker will fail to link with the DFL libraries generated with dmd 2.059. So this would be a dmd thing, and I thought expected to some degree (isn't this true with GCC on some version bumps?).

On Mon, Jul 30, 2012 at 4:35 PM, Walter Bright <walter@digitalmars.com> wrote:
> "DFL won't compile"
>
> It doesn't matter if the fix is trivial, easy, whatever. It does not compile, therefore D sux.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos