On 1/6/2012 11:37 AM, Trass3r wrote:
> Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright <newshound2@digitalmars.com>:
>> Long term, I hope to get a better solution, but this is where we're at at the
>> moment.
>
> What's the current state of the plan?
> Can we hope for a switch to COFF?

My plan is to make the linker understand coff and so be able to pull in objects in any format. But that's a ways off.

On Saturday, 7 January 2012 at 00:37:18 UTC, F i L wrote:
> Trass3r wrote:
>> DDT is also shaping up nicely.
>
> Haven't tried it yet. Does it have context sensitive code-completion?

Yep. But of course no semantic analysis.
http://code.google.com/a/eclipselabs.org/p/ddt/wiki/Features

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.144.1325892989.16222.digitalmars-d@puremagic.com...
>
> Most windows programmers will simply not consider the language until it is well supported in Visual Studio
>

Yea, and that's very unfortunate. I used to be a huge fan of visual studio for years (from around MSVC 5 through the first or second VS.NET), but now that I've tasted the alternatives, I find the build/project management to be a little too "magical" and proprietary (or at least too incompatible and inbred), and the UI to be too bloated. I think a lot of the people who are unwilling to try anything but a heavyweight IDE are being unfair to themselves and their projects by keeping themselves blinded. (Obviously, if they've done both ways and still prefer big IDE's, that's different.)

And the thing is too, with popular overrated langauges like C++ or Java, you *need* a fancy IDE to get anywhere and still maintain sanity. But what many of those people don't get, is that with better languages, you *don't* actually *need* all that other stuff. Sure, it can still be a nice bonus, but it's *not* a necessity like with the popular "puzzle" languages they're used to. It's like canned vegetables: You've gotta drench that shit in salt, sauces, spices, and all sorts of stuff just to make it go down. But with food that's quality in the first place, it doesn't matter: You can either dress it up or leave it as-is; either way it still works fine...no...*better* than starting with an inferior base.

"Alex Rønne Petersen" <xtzgzorex@gmail.com> wrote in message news:je7v2g$22qv$1@digitalmars.com...
>
> There is the free objconv tool: http://www.agner.org/optimize/
>

Awesome! I'll definitely have to try that next time I need to use a C lib.

2012/1/7 Nick Sabalausky <a@a.a>:
> news:mailman.144.1325892989.16222.digitalmars-d@puremagic.com...
> Yea, and that's very unfortunate. I used to be a huge fan of visual studio
> for years (from around MSVC 5 through the first or second VS.NET), but now
> that I've tasted the alternatives, I find the build/project management to be
> a little too "magical" and proprietary (or at least too incompatible and
> inbred), and the UI to be too bloated. I think a lot of the people who are
> unwilling to try anything but a heavyweight IDE are being unfair to
> themselves and their projects by keeping themselves blinded. (Obviously, if
> they've done both ways and still prefer big IDE's, that's different.)
>
> And the thing is too, with popular overrated langauges like C++ or Java, you *need* a fancy IDE to get anywhere and still maintain sanity. But what many of those people don't get, is that with better languages, you *don't* actually *need* all that other stuff. Sure, it can still be a nice bonus, but it's *not* a necessity like with the popular "puzzle" languages they're used to. It's like canned vegetables: You've gotta drench that shit in salt, sauces, spices, and all sorts of stuff just to make it go down. But with food that's quality in the first place, it doesn't matter: You can either dress it up or leave it as-is; either way it still works fine...no...*better* than starting with an inferior base.

I agree to some extent. Visual studio has a very convenient integrated
debugging environment, and good extensibility.
Yet, I've choosen to sacrifice it for better efficiency/portability of GCC...

The ability to automatize work by writing an extension in VB/C# in 5 minutes in kinda good, but inability to efficiently use assembler, for example, negates this benefit, IMHO.

On 06.01.2012 21:02, Adam Wilson wrote:
>
> COFF is an absolute requirements when working on Windows, yet DMD doesn't
> support it. Everything, every programming interface, every application
> running on x64 Windows is built with COFF, the default output of every
> other compiler on Windows is COFF, everyone else programming on Windows is
> expecting COFF.
> Windows represents the largest OS install base in the world; and yet,
> Windows based D programmers are told that they have to dig up extremely
> esoteric tools from the darkest, smelliest, most cobwebbed corners of the
> Internet, just to be able to interact with the the rest of the Windows
> world.
>
> This situation is simply unacceptable.

It's not that bad.  Most libraries can be compiled to DLL files, in fact that's often the default.  DMD/Optlink can use DLL files created by other tool chains just fine. If an import library in the correct format is not available, just use implib or coffimplib to create one.  No problem.

Some of the D bindings for C libraries include build scripts for building the library with DMC, to allow for static linking with D programs.  Most don't, but you can still get by just fine with the DLL build of the library.

On Fri, 06 Jan 2012 23:31:52 -0800, torhu <no@spam.invalid> wrote:

> On 06.01.2012 21:02, Adam Wilson wrote:
>>
>> COFF is an absolute requirements when working on Windows, yet DMD doesn't
>> support it. Everything, every programming interface, every application
>> running on x64 Windows is built with COFF, the default output of every
>> other compiler on Windows is COFF, everyone else programming on Windows is
>> expecting COFF.
>> Windows represents the largest OS install base in the world; and yet,
>> Windows based D programmers are told that they have to dig up extremely
>> esoteric tools from the darkest, smelliest, most cobwebbed corners of the
>> Internet, just to be able to interact with the the rest of the Windows
>> world.
>>
>> This situation is simply unacceptable.
>
> It's not that bad.  Most libraries can be compiled to DLL files, in fact that's often the default.  DMD/Optlink can use DLL files created by other tool chains just fine. If an import library in the correct format is not available, just use implib or coffimplib to create one.  No problem.

First of all, what if I want to use a DLL lib file that was created by DMD in VC++? Oh right, can't do that either. I know there are converter tools available, but all of them are closed source, and what if the creator decides one day that he is done? I'm stuck with no source and potential bugs.
Second, as a professional, the idea that somehow the advice to download Esoteric Tool X from Shady FTP Server Y is acceptable is completely beyond me. No professional compiler implementation would DARE give that advice to it's clients, they'd laugh and find another compiler that did what they want. The concept of kludging together a build toolchain is uniquely open source. DMD will never get buy-in from large groups of professionals without natively supporting the things those professionals expect.

Let me state that again for clarity. If DMD does not natively support the standard outputs that professionals have come to expect and demand, then DMD will forever remain a hobby toy.

Professionals don't have time to kludge together a [fragile] build toolchain and support it, they have work to do. Given the choice for a large project right now, i'd have to say VC++ wins on Windows every time, it's got COFF, excellent tooling and libraries, and x64 support; but mostly, it works with everything Windows. DMD does not. Until DMD does, professionals cannot seriously consider DMD.

> Some of the D bindings for C libraries include build scripts for building the library with DMC, to allow for static linking with D programs.  Most don't, but you can still get by just fine with the DLL build of the library.


-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Personally I would say that I am only able to not
use an IDE on hobby and very small scale projects.

On my line of work, where most projects are scattered around
the globe, with millions of lines and modules, the code navigation
tools that IDEs provide are priceless.

Now I am back to .NET after a few years doing mostly JVM stuff, and
I do conceed that many tools I take for granted on Java IDEs, even
for C/C++ development, are just missing in Visual Studio. It baffles
me that people find normal to buy Respher or VisualAssist for funcionality that other IDEs have since years.

Still, if you are doing Windows desktop applications, Visual Studio is
the only game in town. I don't want to write by hand framework boilerplate code that can be easily generated by Visual Studio.

And the debugger is quite nice as well.

--
Paulo

Am 07.01.2012 07:40, schrieb Nick Sabalausky:
> "Manu"<turkeyman@gmail.com>  wrote in message
> news:mailman.144.1325892989.16222.digitalmars-d@puremagic.com...
>>
>> Most windows programmers will simply not consider the
>> language until it is well supported in Visual Studio
>>
>
> Yea, and that's very unfortunate. I used to be a huge fan of visual studio
> for years (from around MSVC 5 through the first or second VS.NET), but now
> that I've tasted the alternatives, I find the build/project management to be
> a little too "magical" and proprietary (or at least too incompatible and
> inbred), and the UI to be too bloated. I think a lot of the people who are
> unwilling to try anything but a heavyweight IDE are being unfair to
> themselves and their projects by keeping themselves blinded. (Obviously, if
> they've done both ways and still prefer big IDE's, that's different.)
>
> And the thing is too, with popular overrated langauges like C++ or Java, you
> *need* a fancy IDE to get anywhere and still maintain sanity. But what many
> of those people don't get, is that with better languages, you *don't*
> actually *need* all that other stuff. Sure, it can still be a nice bonus,
> but it's *not* a necessity like with the popular "puzzle" languages they're
> used to. It's like canned vegetables: You've gotta drench that shit in salt,
> sauces, spices, and all sorts of stuff just to make it go down. But with
> food that's quality in the first place, it doesn't matter: You can either
> dress it up or leave it as-is; either way it still works
> fine...no...*better* than starting with an inferior base.
>
>

On 06.01.2012 21:02, Adam Wilson wrote:
> On Fri, 06 Jan 2012 10:27:58 -0800, Manu <turkeyman@gmail.com> wrote:
>
>> Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
>> support/produce VS compatible libs.
>> I should have realised this sooner, noting the cv debuginfo.
>>
>> So like... WTF?
>>
>> How am I supposed to use DMD in Windows in anything other than trivial,
>> self-contained programs?
>> VisualC is the de facto standard in Windows. All libs are COFF, and
>> (unless
>> I'm working with GCC) everything I want to link to is produced from VC.
>>
>> Let's also mention the debug info... Virtually every 3rd party tool
>> assumes
>> and/or works best with PDB debug info. Being required to run cv2pdb is
>> pretty lame.
>>
>> So... why no support for COFF libs, and PDB debug info?
>> Surely at least a compiler option would do the business if there is some
>> kinky attachment to CV and OMF :/
>>
>> I was hoping to start a project using D as a front end language
>> interacting
>> with my C/C++ engine lib... but I can't.
>> ... and now that I think if it... how do ANY programs built with DMD
>> actually work? .. How does it link to system32.lib, user32.lib, etc?
>
> DMD on Linux gets ELF with x64 support.
> DMD on OSX gets Mach-O with x64 support.
> DMD on Windows gets ... OMF with no x64 support.
>
> COFF is an absolute requirements when working on Windows, yet DMD
> doesn't support it. Everything, every programming interface, every
> application running on x64 Windows is built with COFF, the default
> output of every other compiler on Windows is COFF, everyone else
> programming on Windows is expecting COFF.
> Windows represents the largest OS install base in the world; and yet,
> Windows based D programmers are told that they have to dig up extremely
> esoteric tools from the darkest, smelliest, most cobwebbed corners of
> the Internet, just to be able to interact with the the rest of the
> Windows world.
>
> This situation is simply unacceptable.
>
> Everything else on Windows is COFF, if DMD ever wants to be accepted as
> a mainstream Windows development tool, it simply *MUST* support COFF.
> And no amount of wishing will ever change this. Without COFF, D will
> ALWAYS be hamstrung on Windows, even if OMF ever got x64 support. Every
> other platform that DMD supports got their native object formats. It is
> now time to get the native Windows format in D.
>
> All DMD needs to do is output the COFF files, any number of linkers
> available on Windows can handle it from there. It doesn't have to
> replace OMF and it doesn't even have to be the default option, but it
> absolutely MUST be AN option.
>

From everything I've seen, COFF seems to be very closely related to ELF. A large part of it is identical.
In the old DDL project on dsource, a lot of work was done in deciphering the formats. COFF is a lot better documented than Mach-O.

IMHO we should be looking at adding COFF output to the compiler, not to the linker.

On 7 January 2012 08:40, Nick Sabalausky <a@a.a> wrote:

> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.144.1325892989.16222.digitalmars-d@puremagic.com...
> >
> > Most windows programmers will simply not consider the language until it is well supported in Visual Studio
> >
>
> Yea, and that's very unfortunate. I used to be a huge fan of visual studio
> for years (from around MSVC 5 through the first or second VS.NET), but now
> that I've tasted the alternatives, I find the build/project management to
> be
> a little too "magical" and proprietary (or at least too incompatible and
> inbred), and the UI to be too bloated. I think a lot of the people who are
> unwilling to try anything but a heavyweight IDE are being unfair to
> themselves and their projects by keeping themselves blinded. (Obviously, if
> they've done both ways and still prefer big IDE's, that's different.)
>

Your personal opinion of people who use and/or prefer visual studio is irrelevant. Most windows devs use it, and love it. It's very important.

I for one am primarily a cross platform dev, NOT a windows/x86 dev, and I
still use and prefer VisualStudio.
I have worked extensively on these platforms: Dreamcast, PS2, XBox,
Gamecube, PS3, XBox360, Wii, PSP, NDS, iPhone, Android, Windows, and
Linux... plus some others on occasion in the last 10 years. I rarely work
on x86 platforms...
Unsurprisingly, almost every platform from that list above has reasonabe VS
integration. Console SDK's are almost all exclusively VS based (this might
be why most game devs use VS... perhaps a chicken/egg problem here, but
nobody's complaining about it. Only when the VS integration is
mediocre/half arsed to people complain...) .. Some older consoles tended to
tie themselves to CodeWarrior, but thankfully, that dwindled, and the same
platforms eventually adopted a VS integration due to demand. I've never
heard of anyone who PREFERS CodeWarrior.

What would you propose I try to convince me that VS is shit and unproductive?

I do use build tools, like premake, which are able to produce VS projects
(and makefiles, etc, for non-windows platforms/toolchains and useful for
automated scripts)...
If you're going to talk about bloated heavy-weight IDE's, have you every
tried using Eclipse? What a joke! How is it that so many years of OSS dev
and Google backing it can produce such a bloated, crap, slow, inconsistent,
unfocused/unintegrated tool?!
How about XCode? I don't understand how anyone gets any work done with
XCode, it is just soooo crap.

So what are the alternatives? An endless mountain of annoying shell based build systems? I use them when I need to, I like premake at the moment, and have used others previously. It's an important part of the toolchain, but it generally results in a VS project for actually doing productive work... So there you go, another opinion for you, yet I believe mine is shared by no small number of professional windows based devs ;)

And the thing is too, with popular overrated langauges like C++ or Java, you
> *need* a fancy IDE to get anywhere and still maintain sanity. But what many
> of those people don't get, is that with better languages, you *don't*
> actually *need* all that other stuff. Sure, it can still be a nice bonus,
> but it's *not* a necessity like with the popular "puzzle" languages they're
> used to. It's like canned vegetables: You've gotta drench that shit in
> salt,
> sauces, spices, and all sorts of stuff just to make it go down. But with
> food that's quality in the first place, it doesn't matter: You can either
> dress it up or leave it as-is; either way it still works
> fine...no...*better* than starting with an inferior base.
>

Overrated? I don't think calling industry standards overrated is a
reasonable claim. they're industry standards because everyone uses them...
and everyone uses them because they are industry standards.
I've used C/C++ professionally my whole career with some C# taking over for
tools recently. I hate C++! (that's why I'm here!).. I don't hype it up
like it's awesome, but I use it because it's industry standard, there is no
viable alternative, and even if there were, it would NEED integration with
all my tools before I could use it professionally in a full production
environment.

I don't NEED an IDE to work with those languages specifically, I *prefer* an IDE to DO WORK FASTER... I prefer an IDE even when I'm writing python for instance, and it annoys me that there's no IDE/debugger for embedded LUA.

If by 'better' languages, you mean D, then I completely disagree. D *NEEDS*
an IDE, just like all the rest... and in my opinion, even more so... here
are some reasons I find it so annoying there isn't a quality VS integration
for D (yet):
  ** auto is used liberally in D... I should be able to hover over any
variable and have a tool tip inform me what it actually is (this makes it
more important that D has an IDE than even C/C++)
  ** I don't have years of experience with the libraries, I SHOULD be able
to press '.' and have a list of everything the library can do appear
instantly without wasting my time trawling through the docs.
  * I shouldn't have to guess or try and remember the name of some member
or method... I should be able to type the first 1-2 letters, and have the
rest of the word will appear instantly.
  * If I don't know what a type is, or want to know about it in more
detail, I should be able to press F1 and see documentation about the
class/function/whatever instantly.
  * I'm new to the syntax, and it's terribly nice when a little red
underline appears beneath a syntax error I've just created.
  * As projects grow, things like auto-refactor save sooo much time.
Extremely difficult to implement reliably for C/C++, but should work
perfectly in D...

C# for instance, is becoming very popular. The reason for this is that it's
just sooooo fucking productive, and that's not thanks to the language its
self... any C# user will agree that at least 50% of C#'s special power is
actually it's VS integration.
The first time I used C# (knowing absolutely nothing about the language), I
opened VS, and started typing... thanks to the integration, the language
was self-documenting and self-evident. I felt immediately productive in a
language I hadn't even read a word about, and after a little more
experience, I love its efficiency for writing the kind of code it's great
at, and I always feel amazingly productive. The experience is not limited,
or even thanks to the language, it's the whole package.

The C# experience gave me a new expectation from any new language... I shouldn't need to KNOW a language, or basically anything about it to start using it immediately. The IDE (auto-popup-documentation, code completion, info tooltips, etc) is what gives me that experience. Assuming the rest of the language and libraries are designed intuitively, it works.

The reason it matters so much to me...
I suspect I could actually propose using D in the office for small tasks,
tools, etc... everyone hates C++, it wouldn't be hard to convince them to
give it a try.
That said, If D doesn't have an IDE, or more specifically, VS integration,
it's off the table. Period. In a multi-user project, where all users expect
VS integration, I can't do without it.
If it can manage to make a splash with newcomers like C# does, people will
be really impressed, and they'll keep coming back.