www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD - Windows

reply Manu <turkeyman gmail.com> writes:
--00235429dda45618f504b5e0357c
Content-Type: text/plain; charset=UTF-8

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?

--00235429dda45618f504b5e0357c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Okay, so I was trying to link to a C lib, and I realised... DMD doesn&#39;t=
 support/produce VS compatible libs.<div>I should have realised this sooner=
, noting the cv debuginfo.</div><div><br></div><div>So like... WTF?</div>
<div><br></div><div>How am I supposed to use DMD in Windows in anything oth=
er than trivial, self-contained programs?</div><div>VisualC is the de facto=
 standard in Windows.=C2=A0All libs are COFF, and (unless I&#39;m working w=
ith GCC) everything I want to link to is produced from VC.</div>
<div><br></div><div>Let&#39;s also mention the debug info...=C2=A0Virtually=
 every 3rd party tool assumes and/or works best with PDB debug info. Being =
required to run cv2pdb is pretty lame.</div><div><br></div><div>So... why n=
o support for COFF libs, and PDB debug info?</div>
<div>Surely at least a compiler option would do the business if there is so=
me kinky attachment to CV and OMF :/</div><div><br></div><div>I was hoping =
to start a project using D as a front end language interacting with my C/C+=
+ engine lib... but I can&#39;t.</div>
<div>... and now that I think if it... how do ANY programs built with DMD a=
ctually work? .. How does it link to system32.lib, user32.lib, etc?</div>

--00235429dda45618f504b5e0357c--
Jan 06 2012
next sibling parent reply Trass3r <un known.com> writes:
Am 06.01.2012, 19:27 Uhr, schrieb Manu <turkeyman gmail.com>:

 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?

Welcome to the jungle ^^ Your options are: 1) use dlls + implib, then you can work with MinGW or VisualC 2) use GDC, then you also get 64Bit: https://bitbucket.org/goshawk/gdc/downloads *) torture yourself by trying to link statically with objconv *) try UniLink
 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.

pdb is undocumented. Even cv2pdb is based more or less on reverse engineering.
 ... 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?

Those system libs are just import libraries for the respective DLLs, even in VS.
Jan 06 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Hi Manu,

nice to hear about your experience with C#.

I am a bit of half-insider in the game industry, being
a IGDA member for some years and also attended two
GDCE so far.

Several reasons have kept me from getting a job in the
industry, but I still follow what's happening quite closely.

 From what I know here in Europe, many studios have been slowly
migrating to C# for tools, and many that target mostly Windows
are also experimenting with it in their engines.

How does it look like from your side?

I think this is important to know, because in what concerns
game development, C# might eventually superseed C++, especially
with good quality AOT compilers. Not sure how good Mono's AOT
code quality is. From the public information C# is the default
language for the PlayStation VITA and the PlayStation Suite.

And game development is probably one of the few areas where D could get
an entry to.

--
Paulo


Am 07.01.2012 13:40, schrieb Manu:
 On 7 January 2012 08:40, Nick Sabalausky <a a.a> wrote:

     "Manu" <turkeyman gmail.com <mailto: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
     <http://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.

Jan 07 2012
prev sibling parent Jim Hewes <jimhewes gmail.com> writes:
On 1/7/2012 4:40 AM, Manu wrote:
 On 7 January 2012 08:40, Nick Sabalausky <a a.a> wrote:

 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):

My job is primarily C++ Windows programming and I use Visual Studio. I think I agree with everything you said. In my case, I think of development tools as consisting of three components: (1) the language (2) the library/libraries including GUI, and (3) development environment, which includes debugger, IDE, etc. So even if the language is wonderful by itself, it's still not everything, and the total package may be less attractive than some other. I casually follow D progress because, besides just looking like a fun language to use, it seems to have all the elements that make a good language. But as you say, some things outside the language aren't quite there. I use C# for small-to-medium, internal tools that have a GUI. It's great for that because of the IDE integration and also the .NET framework. The integration/intellisense is better for C# than C++. The biggest negative in the language is the lack of deterministic destruction, and that's one reason I'd favor D. (Also, having to get the .NET framework installed on users' systems is not so great, but not an issue just for internal tools. ) But the pros of IDE integration and .NET framework are greater to me than D language advantage. Visual D is helpful....but then there's the GUI library.... Not to get too far off topic, I'm the only one where I work who will use C#. I think some people simply hate Microsoft the company so much that they would not even fire up C# and try it once. They won't be caught liking it. And that's seems to be the case where I work as far as I can tell. Maybe D would be more well received than C# by such people if it integrated better with VS, I don't know. But there is always the issue with less widely used languages: if I write our company's main product in D, and if we then need to hire more people, I need to tell my boss we need to hire people that know D (or are at least willing and able pick it up) which are not as common. If anything at all goes wrong with D that wouldn't have gone wrong had we used C++, it's on me. No one ever got fired for buying IBM, lol. Sorry, I know we need to battle past that but I can't help mentioning it.
Jan 08 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.118.1325874486.16222.digitalmars-d puremagic.com...
 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?

Yea, OMF is actually #1 PITA on Windows right now, unfortunately. The problem: On windows, DMD uses the Optlink linker. Optlink only supports OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was written entirely in asm so changing it is difficult. But Walter has been, piece-by-piece, porting it to C (and then he'll port it to D). (This is issue also happens to be the main thing blocking 64-bit on Windows.) There are a few solutions right now (in no particular order): - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will result in an OMF lib file that can be used with DMD. - Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and COFF together just fine. I don't have a link offhand, and it's a little funky to learn how to use since the docs aren't very good, but I'm sure someone here will chime in (or you can search the archives, I know comeone posted a good introduction to it not too long ago). - Use the Digital Mars COFF2OMF tool to convert to lib to OMF. Unfortunately, the tool isn't free, but IIRC it's inexpensive. - Use LDC or GDC instead of DMD. I think those work with COFF. - If the library comes in a DLL version, you can download the free IMPLIB tool and use it to generate an OMF import library directly from the DLL (it'll still actually link to the DLL at runtime). - Search/Ask around: Someone may have already created an OMF version of the lib. The IMPLIB and COFF2OMF tools are here: http://www.digitalmars.com/download/freecompiler.html IMPLIB is in the free "Basic Utilities" package, and COFF2OMF is in the "Extended Utilities Package" If you feel this is all still a big pain in the ass: Don't worry, everyone here agrees with you, and the situation will not remain like this forever.
Jan 06 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message news:op.v7ofwpwh3ncmek enigma...
 The problem: On windows, DMD uses the Optlink linker. Optlink only 
 supports OMF right now (OMF used to be commonly used by Borland, IIRC). 
 Optlink was written entirely in asm so changing it is difficult. But 
 Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D).

I say get rid of that freakin' dinosaur. Pull requests are already piling up, we can't afford losing more time.

I can't say I disagree :/ (So who's up for adding COFF support to DMD?)
 (This is issue also happens to be the main thing blocking 64-bit on 
 Windows.)

Not quite true. You need 64Bit: object format, linker, librarian, debug info, compiler.

Well, ok, *one of* the main things ;)
 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That 
 will result in an OMF lib file that can be used with DMD.

Did you ever try that?? You can't even mention that, let alone recommend it.

Depends on the lib really. DMC is a perfectly capable compiler as far as I can tell. It's just that some projects have fairly complex buildscripts that are fairly hardwired for MSVC and/or GCC. Anything with a sane buildsystem should be fine (though how common that is in C/C++-world, I can't say...).
 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.

Doesn't matter. You already have to pay enough by having to deal with that OMF crap.

Regardless, it *is* an option, so I listed it. I leave it up to others to decide if it's right for them.
 If you feel this is all still a big pain in the ass: Don't worry, 
 everyone here agrees with you, and the situation will not remain like 
 this forever.

I'm sceptical.

Jan 06 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 06-01-2012 20:06, Nick Sabalausky wrote:
 "Manu"<turkeyman gmail.com>  wrote in message
 news:mailman.118.1325874486.16222.digitalmars-d puremagic.com...
 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?

Yea, OMF is actually #1 PITA on Windows right now, unfortunately. The problem: On windows, DMD uses the Optlink linker. Optlink only supports OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was written entirely in asm so changing it is difficult. But Walter has been, piece-by-piece, porting it to C (and then he'll port it to D). (This is issue also happens to be the main thing blocking 64-bit on Windows.) There are a few solutions right now (in no particular order): - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will result in an OMF lib file that can be used with DMD. - Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and COFF together just fine. I don't have a link offhand, and it's a little funky to learn how to use since the docs aren't very good, but I'm sure someone here will chime in (or you can search the archives, I know comeone posted a good introduction to it not too long ago). - Use the Digital Mars COFF2OMF tool to convert to lib to OMF. Unfortunately, the tool isn't free, but IIRC it's inexpensive.

There is the free objconv tool: http://www.agner.org/optimize/
 - Use LDC or GDC instead of DMD. I think those work with COFF.

 - If the library comes in a DLL version, you can download the free IMPLIB
 tool and use it to generate an OMF import library directly from the DLL
 (it'll still actually link to the DLL at runtime).

 - Search/Ask around: Someone may have already created an OMF version of the
 lib.

 The IMPLIB and COFF2OMF tools are here:
 http://www.digitalmars.com/download/freecompiler.html  IMPLIB is in the free
 "Basic Utilities" package, and COFF2OMF is in the "Extended Utilities
 Package"

 If you feel this is all still a big pain in the ass: Don't worry, everyone
 here agrees with you, and the situation will not remain like this forever.

-- - Alex
Jan 06 2012
parent "Nick Sabalausky" <a a.a> writes:
"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.
Jan 06 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 The problem: On windows, DMD uses the Optlink linker. Optlink only  
 supports OMF right now (OMF used to be commonly used by Borland, IIRC).  
 Optlink was written entirely in asm so changing it is difficult. But  
 Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D).

I say get rid of that freakin' dinosaur. Pull requests are already piling up, we can't afford losing more time.
 (This is issue also happens to be the main thing blocking 64-bit on  
 Windows.)

Not quite true. You need 64Bit: object format, linker, librarian, debug info, compiler.
 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That  
 will result in an OMF lib file that can be used with DMD.

Did you ever try that?? You can't even mention that, let alone recommend it.
 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.

Doesn't matter. You already have to pay enough by having to deal with that OMF crap.
 If you feel this is all still a big pain in the ass: Don't worry,  
 everyone here agrees with you, and the situation will not remain like  
 this forever.

I'm sceptical.
Jan 06 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf30051342d6938704b5e0f031
Content-Type: text/plain; charset=UTF-8

On 6 January 2012 21:06, Nick Sabalausky <a a.a> wrote:

 Yea, OMF is actually #1 PITA on Windows right now, unfortunately.

 The problem: On windows, DMD uses the Optlink linker. Optlink only supports
 OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was
 written entirely in asm so changing it is difficult. But Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D). (This is
 issue also happens to be the main thing blocking 64-bit on Windows.)

Lame. Surely Optlink is not the only linker in the world...? I'm also surprised that someone capable of writing a compiler and optimiser for a complex language isn't capable of writing a linker. The link must surely be the simplest+easiest of those 3 jobs...?
 There are a few solutions right now (in no particular order):

 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will
 result in an OMF lib file that can be used with DMD.

DMx has inferior code generation, not a chance :) .. And does DMC even support all the features of the language? SSE? No support in D, why would it work in DMC?
 - Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and
 COFF together just fine. I don't have a link offhand, and it's a little
 funky to learn how to use since the docs aren't very good, but I'm sure
 someone here will chime in (or you can search the archives, I know comeone
 posted a good introduction to it not too long ago).

Why not use this instead of Optlink if it works? I'll check it out... though VisualD doesn't support this.
 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.

Seriously... I just simply won't bother, and write my app in C instead ;)
 - Use LDC or GDC instead of DMD. I think those work with COFF.

VisualD doesn't support those compilers (yet). - If the library comes in a DLL version, you can download the free IMPLIB
 tool and use it to generate an OMF import library directly from the DLL
 (it'll still actually link to the DLL at runtime).

I could probably build my engine as a DLL... I've been planning to do this for a long time anyway. Maybe this is the extra bit of motivation I need to do it ;)
 The IMPLIB and COFF2OMF tools are here:
 http://www.digitalmars.com/download/freecompiler.html  IMPLIB is in the
 free
 "Basic Utilities" package, and COFF2OMF is in the "Extended Utilities
 Package"

 If you feel this is all still a big pain in the ass: Don't worry, everyone
 here agrees with you, and the situation will not remain like this forever.

Indeed. The main reason for my post is just to complain, and add my voice ;) I'd like to insist that this is basically unacceptable... it should be prioritised. --20cf30051342d6938704b5e0f031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 January 2012 21:06, Nick Sabalausky <span d= ir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d= iv class=3D"im"> Yea, OMF is actually #1 PITA on Windows right now, unfortunately.</div> <br> The problem: On windows, DMD uses the Optlink linker. Optlink only supports= <br> OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was<= br> written entirely in asm so changing it is difficult. But Walter has been,<b= r> piece-by-piece, porting it to C (and then he&#39;ll port it to D). (This is= <br> issue also happens to be the main thing blocking 64-bit on Windows.)<br></b= lockquote><div><br></div><div>Lame. Surely Optlink is not the only linker i= n the world...?</div><div>I&#39;m also surprised that someone capable of wr= iting a compiler and optimiser for a complex language isn&#39;t capable of = writing a linker. The link must surely be the simplest+easiest of those 3 j= obs...?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">There are a few solutions r= ight now (in no particular order):<br> <br> - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will= <br> result in an OMF lib file that can be used with DMD.<br></blockquote><div><= br></div><div>DMx has inferior code generation, not a chance :) .. And does= DMC even support all the features of the language? SSE? No support in D, w= hy would it work in DMC?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">- Link with Unilink instead= of DMD/Optlink. Unilink can link both OMF and<br> COFF together just fine. I don&#39;t have a link offhand, and it&#39;s a li= ttle<br> funky to learn how to use since the docs aren&#39;t very good, but I&#39;m = sure<br> someone here will chime in (or you can search the archives, I know comeone<= br> posted a good introduction to it not too long ago).<br></blockquote><div><b= r></div><div>Why not use this instead of Optlink if it works?</div><div>I&#= 39;ll check it out... though VisualD doesn&#39;t support this.</div><div> =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex">- Use the Digital Mars COFF2OMF = tool to convert to lib to OMF.<br> Unfortunately, the tool isn&#39;t free, but IIRC it&#39;s inexpensive.<br><= /blockquote><div><br></div><div>Seriously... I just simply won&#39;t bother= , and write my app in C instead ;)</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> - Use LDC or GDC instead of DMD. I think those work with COFF.<br></blockqu= ote><div><br></div><div>VisualD doesn&#39;t support those compilers (yet).<= /div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> - If the library comes in a DLL version, you can download the free IMPLIB<b= r> tool and use it to generate an OMF import library directly from the DLL<br> (it&#39;ll still actually link to the DLL at runtime).<br></blockquote><div=
<br></div><div>I could probably build my engine as a DLL... I&#39;ve been =

ra bit of motivation I need to do it ;)</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">The IMPLIB and COFF2OMF too= ls are here:<br> <a href=3D"http://www.digitalmars.com/download/freecompiler.html" target=3D= "_blank">http://www.digitalmars.com/download/freecompiler.html</a> =C2=A0IM= PLIB is in the free<br> &quot;Basic Utilities&quot; package, and COFF2OMF is in the &quot;Extended = Utilities<br> Package&quot;<br> <br> If you feel this is all still a big pain in the ass: Don&#39;t worry, every= one<br> here agrees with you, and the situation will not remain like this forever.<= br></blockquote><div><br></div><div>Indeed. The main reason for my post is = just to complain, and add my voice ;)</div><div>I&#39;d like to insist that= this is basically unacceptable... it should be prioritised.</div> </div> --20cf30051342d6938704b5e0f031--
Jan 06 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.126.1325877634.16222.digitalmars-d puremagic.com...
 Lame. Surely Optlink is not the only linker in the world...?
 I'm also surprised that someone capable of writing a compiler and 
 optimiser
 for a complex language isn't capable of writing a linker. The link must
 surely be the simplest+easiest of those 3 jobs...?

He (ie, Walter) *did* write Optlink, that's why DMD/Win uses it :/ (And OMF wasn't such a problem back when Optlink was written. AIUI, not being an expert in the matter myself, the decline of Borland seems to be one of the main reasons for OMF's demise.)
Why not use this instead of Optlink if it works?
I'll check it out... though VisualD doesn't support this.

 VisualD doesn't support those compilers (yet).

Yea, GDC and LDC were lagging pretty far behind until only fairly recently, and we didn't discover unilink until not real long ago either, so D many projects have been slow in supporting them. But yea, as a community we probably do need to make sure to start supporting them better.
 If you feel this is all still a big pain in the ass: Don't worry, 
 everyone
 here agrees with you, and the situation will not remain like this 
 forever.

Indeed. The main reason for my post is just to complain, and add my voice ;) I'd like to insist that this is basically unacceptable... it should be prioritised.

vote++
Jan 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 6 January 2012 at 19:20:35 UTC, Manu wrote:
 The link must
 surely be the simplest+easiest of those 3 jobs...?

The painful part is more getting dmd to output coff than writing a linker (can always use a third party linker anyway). Adding coff support is a bit of a mess and super tedious. I've been thinking porting the coff outputter from something like nasm might be a good strategy, but I haven't figured out how to start that yet.
Jan 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/6/2012 10:27 AM, Manu wrote:
 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?

With DMD comes the various *.lib files converted to OMF format. Converting them is pretty simple. Long term, I hope to get a better solution, but this is where we're at at the moment.
Jan 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 06 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-07 06:11, Walter Bright wrote:
 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.

Will dmd still produce OMF or will it be changed to produce COFF? -- /Jacob Carlborg
Jan 07 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-01-2012 19:43, Froglegs wrote:
 A great IDE is essential for D to really succeed.

 Visual D is a solid start but it isn't really usable for a large project
 yet.

 - The debugging experience is funky, it can't seem to see many variables
 - hovering over variables generally doesn't show anything useful
 - hitting . doesn't pop up possible members
 - very limited syntax highlighting

I strongly disagree. Visual D's syntax highlighting is currently the best available across all D editors, including Vim, Mono-D, Geany, KDevelop, etc.
 D might have simplified C++ syntax, but it is still quite complex, not
 having an IDE that supports the type of things that Visual Studio
 supports is just painful-- I doubt D has any chance in the game industry
 without much better VS support.

 Aside from C++ I also use Lua quite often and even in a light weight
 scripting language like Lua I much prefer an IDE(Decoda--Manu it works
 with embedded scripts btw).

-- - Alex
Jan 07 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.
Jan 07 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 08-01-2012 01:27, Walter Bright wrote:
 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.

Does the OMF format actually support 64-bit? If not, we're bound to need COFF eventually. -- - Alex
Jan 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 3:02 AM, Alex Rønne Petersen wrote:
 Does the OMF format actually support 64-bit?

Nope.
 If not, we're bound to need COFF eventually.

Probably. Or elf.
Jan 08 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-08 01:27, Walter Bright wrote:
 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.

I see, thanks for the explanation. -- /Jacob Carlborg
Jan 08 2012
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 8/01/12 2:14 PM, Trass3r wrote:
 Also the dmd code needs improvement. It should leverage C++11 features,
 become more modular and code quality needs to be improved. For example
 the typed Array was long overdue, yet people still use that crappy
 tdata() syntax instead of just []. The C++11 range based for loop would
 be a logical next step for that. Other things that come to my mind are
 replacing hard-coded values with proper constants, introducing smart
 pointers so at least some memory is released and better (documentation)
 comments.

It's still far too early to start using C++11 stuff because not all compilers support it. OSX still ships with g++ 4.2. Expecting people to install a new compiler just to compile the DMD code is a pointless barrier. Especially if the only reason for using C++11 is relatively minor syntactic changes. Smart pointers (especially shared_ptr) are not free. They will make DMD slower, compile more slowly, and bloat the syntax (T* vs. std::shared_ptr<T>). It is also a very large change to change most pointers to smart pointers. Any mistakes made in the transition will cause bugs. All this stuff you have proposed requires time. Time is precious. What do you propose should be delayed so that this work could be carried out?
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 7:06 AM, Trass3r wrote:
 IIRC Clang uses them all over the place and they did carefully design
everything
 for speed and memory efficiency.

Clang is a lot slower at compiling than dmc.
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 12:35 PM, Trass3r wrote:
 Clang is a lot slower at compiling than dmc.

With or without optimizations?

http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html
 Would be interesting to see detailed comparisons lexing/parsing/... like
 http://clang.llvm.org/performance.html

Being faster than gcc isn't a great trick.
Jan 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 2:58 PM, Trass3r wrote:
 I was curious why dmc is faster.

Many hours with the profiler!
Jan 08 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 6:14 AM, Trass3r wrote:
 e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes severe bugs
 with postblits/destructors and has been open for 4 months already without any
 comment from your side.

Don knows what he's doing, and it's waiting for fixes to his observations. Meanwhile, there are a ton of other pull requests that are ready to go that I've been pulling in steadily.
 We have to live with the fact that bugs are fixed
 somewhat randomly (i.e. the bugzilla voting system is completely ignored), but
 it isn't acceptable that we have to deal with bugs that have been fixed months
 ago but just not merged yet.

See my comment above.
 Bug 314 is a prime example for all of that (most
 voted bug for years, fixed in ldc long ago, pull request was open for ages).

That one has been pulled and merged.
 Also the dmd code needs improvement. It should leverage C++11 features, become
 more modular and code quality needs to be improved. For example the typed Array
 was long overdue, yet people still use that crappy tdata() syntax instead of
 just []. The C++11 range based for loop would be a logical next step for that.
 Other things that come to my mind are replacing hard-coded values with proper
 constants, introducing smart pointers so at least some memory is released and
 better (documentation) comments.

I'd like to use C++11 features in the dmd source, too. The downside is that all the C++ compilers on all the current and potential targets for D need to reliably support those C++11 features. Currently, this is not close to true, and likely won't be for some time. The minor benefit of those features is not worth arbitrarily shutting the door on some targets.
Jan 08 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 12:04 PM, q66 wrote:
 By the way, Walter, I'm fixing druntime and Phobos makefiles after the Shared
 ELF merge so they can be built as shared libs (I have them working both now, on
 my FreeBSD box). I just wanna ask you, I think it would be a good idea to
remove
 default phobos2 linkage from dmd and move that to dmd.conf instead, as the
 phobos2 linkage comes after dmd.conf linkages and druntime has to be linked
 after phobos (I'd like them as separate libs). Do you think I can do that, or
 any other idea?

Once Phobos works as a shared lib, I think we should switch to that as the default.
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 3:12 PM, Adam D. Ruppe wrote:
 On Sunday, 8 January 2012 at 22:52:17 UTC, Walter Bright wrote:
 Once Phobos works as a shared lib, I think we should switch to that as the
 default.

Please, no. That would mean standalone executables won't work by default.

People who distribute apps will be more sophisticated users, and will be able to set a flag to static link. I guarantee you that shared should be the default, as otherwise newbies will compile with D and: "Zo-mah-gawd, look at the size of those D executables! D sux!" Which happens now. Note that the default with gcc is to link with the shared C runtime, and it will be expected for dmd.
Jan 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:oftpypayqrnhjqkmwthk dfeed.kimsufi.thecybershadow.net...
 On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.

My problem with this is a shared lib actually *increases* the size. At best, it fools you by separating it out into two or three files instead of one. A better solution to the executable size problem is to actually make them smaller, like Andrei was doing a couple weeks ago. He made a huge difference just by changing a handful of lines to reduce unnecessary coupling in Phobos.
 Note that the default with gcc is to link with the shared C runtime, and 
 it will be expected for dmd.

The big difference there is people usually already have the C runtime and use it for many programs. They don't actually have to think about installing it. Imagine how many people, especially on Linux, will now start asking "I built a D program, but when I run it, it complains that it can't find libphobos2.so", or the already somewhat common version mismatches that happen when you update one but not the other. Would you rather have someone complaining about a 200 kb executable, on an executable that doesn't work right without end user action?

Absolutely agree 100%. Besides, "1MB Hello Word?!?" is just moronic whining. Christ, I'm on a 32-bit single-core with 2GB ram, I bitch about software bloat constantly, and yet even **I** don't give half a shit about it, and even I'm not *remotely* inconvenienced by trivial apps being a few hundred k, or even a few M, too large. WTF does it matter? Those people are just trying to find bullshit to moan about. Fix that and they'll find some reason to whine about underscores in numeric literals. Additionally, Phobos is different with every release. Are we seriously going to expect D users, and worse - the end-users of D-made software, to have their system cluttered with libphobos2-065.so, libphobos2-066.so, libphobos2-067.so, etc. Or are we going to pretend that issue doesn't exist and create our own little DDLL hell? (And on top of that: "Why do I have hundreds of megs worth of this damn libphobos?") Even if dynamic phobos does become default at some point, *at the very least*, it shouldn't be until Phobos stabalizes. Realistically, it shouldn't be until libphobos is stable *and* about as common as libc.
Jan 08 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 1:51 PM, Martin Nowak wrote:
 No EH, no static/TLS GC roots from shared libraries.

Also, calling the runtime helper functions, like ulong division, is broken for shared because it doesn't set EBX. (Or maybe that doesn't matter since those functions don't access static data? Not sure.)
Jan 08 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 12:31 PM, Trass3r wrote:
 I thought even dmc supports a few features.
 Which one doesn't implement C++11 at all?

Each compiler does a different set of C++11 features, and it changes regularly. It's just not a good idea now. The agony of #ifdef'ing around compiler problems is not going to make the code cleaner.
Jan 08 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 - Link with Unilink instead of DMD/Optlink.

I'll check it out... though VisualD doesn't support this.

Cause its status is.. nebulous. Closed-source, no homepage, just an ftp. You have no guarantee it doesn't get abandoned one day. Also what if there are blocking bugs and the author is away for some time?
 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


Exactly. That's what people will do/do/have already done.
 I could probably build my engine as a DLL... I've been planning to do  
 this for a long time anyway.
 Maybe this is the extra bit of motivation I need to do it ;)

Good practice anyway. Code should always be modular.
Jan 06 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
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?
Jan 06 2012
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 06 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam Wilson" <flyboynw gmail.com> wrote in message 
news:op.v7ohzbof707hn8 apollo.hra.local...
 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.

Just thinking: Since DigitalMars already has an OMF2COFF tool, would it really be all that hard for someone with access to and knowledge of the source (ie, Walter ;) ) to adapt it, or the knowledge within it, into a COFF output module for DMD? (Or has that been the plan all along?)
Jan 06 2012
prev sibling next sibling parent torhu <no spam.invalid> writes:
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.
Jan 06 2012
prev sibling parent Don <nospam nospam.com> writes:
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.
Jan 07 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Friday, 6 January 2012 at 20:03:01 UTC, 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.

I'm not a Windows user myself, but I completely agree. I'm writing a game engine and I'd like to do it in D at some point. However, I also have to support Windows and the other platforms (I develop on FreeBSD and support Windows,Linux,Mac,FreeBSD) and OMF is a blocker. I'm really glad DMD now supports ELF shared libs though. It basically solves one half of my problems.
Jan 06 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Trass3r wrote:
 2) use GDC, then you also get 64Bit:

wait... I was under the impression GDC and LDC can't build 64bit apps for Windows. Or are you talking about the compiler executing/linking in 64bit? Manu wrote:
 - Use LDC or GDC instead of DMD. I think those work with COFF.

VisualD doesn't support those compilers (yet).

I'm not sure if Mono-D supports GDC/LDC but, as a Visual Studios user myself, I recommend using Mono-D for D development on any platform (at this time at least) because of it's Code-completion and Renaming features. I've even converted the Obsidian syntax theme over if you're interested. Although Mono's syntax highlighting is inferior to VS in many ways (no operator or user types distinction) at least in v2.8.5. http://mono-d.sourceforge.net/
Jan 06 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Friday, 6 January 2012 at 20:45:11 UTC, F i L wrote:
 wait... I was under the impression GDC and LDC can't build 
 64bit apps for Windows.

I thought so. Haven't tried it though cause I'm on Linux now.
 I recommend using Mono-D for D development

DDT is also shaping up nicely.
Jan 06 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--bcaec51ba51f1d3d0f04b5e484e4
Content-Type: text/plain; charset=UTF-8

On 6 January 2012 22:45, F i L <witte2008 gmail.com> wrote:

 Manu wrote:

 - Use LDC or GDC instead of DMD. I think those work with COFF.

VisualD doesn't support those compilers (yet).

I'm not sure if Mono-D supports GDC/LDC but, as a Visual Studios user myself, I recommend using Mono-D for D development on any platform (at this time at least) because of it's Code-completion and Renaming features. I've even converted the Obsidian syntax theme over if you're interested. Although Mono's syntax highlighting is inferior to VS in many ways (no operator or user types distinction) at least in v2.8.5. http://mono-d.sourceforge.net/

Nice, is the author of this someone in this community? I wonder if they could contribute some of that effort towards VisualD... for some reason VisualD lacks heaps of these features. Monodevelop is surprisingly usable... although sadly, for me, my build system uses premake to generate VisualStudio projects (and makefiles/etc on other platforms). I hope VisualD is given a lot more love and made awesome. But this might be a nice option in the mean time... with manual project configuration. I think VisualD is extremely important. It's fundamental to mainstream adoption of D. Most windows programmers will simply not consider the language until it is well supported in Visual Studio (and that's a LOT of programmers, including basically the entire game dev community... [all console SDK's are Windows+VisualStudio based]) I certainly wouldn't be using D now if VisualD didn't exist... --bcaec51ba51f1d3d0f04b5e484e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 January 2012 22:45, F i L <span dir=3D"ltr"=
&lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</sp=

border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Manu wrote:</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> &gt; - Use LDC or GDC instead of DMD. I think those work with COFF.<br> &gt;<br> <br></div><div class=3D"im"> VisualD doesn&#39;t support those compilers (yet).<br> </div></blockquote> <br> I&#39;m not sure if Mono-D supports GDC/LDC but, as a Visual Studios user m= yself, I recommend using Mono-D for D development on any platform (at this = time at least) because of it&#39;s Code-completion and Renaming features. I= &#39;ve even converted the Obsidian syntax theme over if you&#39;re interes= ted. Although Mono&#39;s syntax highlighting is inferior to VS in many ways= (no operator or user types distinction) at least in v2.8.5.<br> <a href=3D"http://mono-d.sourceforge.net/" target=3D"_blank">http://mono-d.= sourceforge.net/</a></blockquote><div><br></div><div>Nice, is the author of= this someone in this community? I wonder if they could contribute some of = that effort towards VisualD... for some reason VisualD lacks heaps of these= features.</div> <div><br></div><div>Monodevelop is surprisingly usable... although sadly, f= or me, my build system uses premake to generate VisualStudio projects (and = makefiles/etc on other platforms).</div><div>I hope VisualD is given a lot = more love and made awesome. But this might be a nice option in the mean tim= e... with manual project configuration.</div> <div><br></div><div>I think VisualD is extremely important. It&#39;s fundam= ental to mainstream adoption of D. Most windows programmers will simply not= consider the language until it is well supported in Visual Studio (and tha= t&#39;s a LOT of programmers, including basically the entire game dev commu= nity... [all console SDK&#39;s are Windows+VisualStudio based])</div> <div><br></div><div>I certainly wouldn&#39;t be using D now if VisualD didn= &#39;t exist...</div></div> --bcaec51ba51f1d3d0f04b5e484e4--
Jan 06 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jan 06 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
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.

Jan 07 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Trass3r wrote:
 DDT is also shaping up nicely.

Haven't tried it yet. Does it have context sensitive code-completion? Honestly I would love to use Geany because it's so clean and light-weight, but it just doesn't support enough productivity features yet. Manu wrote:
 Monodevelop is surprisingly usable... although sadly, for me, 
 my build
 system uses premake to generate VisualStudio projects (and 
 makefiles/etc on
 other platforms).

MonoDevelop is compatible with VS2010 solution/project files. One of the best parts about MD is how seamlessly it works across all platforms. Really the best IDE on Linux and Mac IMO, but then again I haven't tried them all. Unfortunately Visual-D and Mono-D projects are incompatible. It would be great to see these two projects collaborate.
 ...including basically the entire game dev community... [all
 console SDK's are Windows+VisualStudio based])

 I certainly wouldn't be using D now if VisualD didn't exist...

Unity3D ships with MonoDevelop as it's primary code editor, and it's rather successful ;) I agree with what your saying here though. Power tools get the job done faster. After using proper code-completion and refactoring tools, it's hard to go back.
Jan 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c768f2639ead304b5e5ccf7
Content-Type: text/plain; charset=UTF-8

On 7 January 2012 02:37, F i L <witte2008 gmail.com> wrote:

 Manu wrote:

 Monodevelop is surprisingly usable... although sadly, for me, my build
 system uses premake to generate VisualStudio projects (and makefiles/etc
 on
 other platforms).

MonoDevelop is compatible with VS2010 solution/project files. One of the best parts about MD is how seamlessly it works across all platforms. Really the best IDE on Linux and Mac IMO, but then again I haven't tried them all. Unfortunately Visual-D and Mono-D projects are incompatible. It would be great to see these two projects collaborate.

Works with VS2010 projects? Bullllshiiii....! I had no idea. Finally! An IDE that's usable in Linux and OSX!! :) I'll have to seriously try this out.. I haven't used monodevelop for about a year. How does it do with C/C++ now? If monodevelop supports vs2010 projects, then it would be REALLY awesome of monodevelop and VisualD would agree to make their D project files compatible... --00248c768f2639ead304b5e5ccf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 02:37, F i L <span dir=3D"ltr"=
&lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</sp=

border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Manu wrote:</div><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Monodevelop is surprisingly usable... although sadly, for me, my build<br> system uses premake to generate VisualStudio projects (and makefiles/etc on= <br> other platforms).<br> </blockquote> <br></div> MonoDevelop is compatible with VS2010 solution/project files. One of the be= st parts about MD is how seamlessly it works across all platforms. Really t= he best IDE on Linux and Mac IMO, but then again I haven&#39;t tried them a= ll. Unfortunately Visual-D and Mono-D projects are incompatible. It would b= e great to see these two projects collaborate.<br> </blockquote><div><br></div><div>Works with VS2010 projects? Bullllshiiii..= ..! I had no idea.</div><div>Finally! An IDE that&#39;s usable in Linux and= OSX!! :)</div><div><br></div><div>I&#39;ll have to seriously try this out.= . I haven&#39;t used monodevelop for about a year. How does it do with C/C+= + now?</div> <div><br></div><div>If monodevelop supports vs2010 projects, then it would = be REALLY awesome of monodevelop and VisualD would agree to make their D pr= oject files compatible...</div></div> --00248c768f2639ead304b5e5ccf7--
Jan 06 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
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
Jan 06 2012
prev sibling next sibling parent Mail Mantis <mail.mantis.88 gmail.com> writes:
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.
Jan 06 2012
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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/
Jan 07 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--00235429dda4edd0af04b5ef77ad
Content-Type: text/plain; charset=UTF-8

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. --00235429dda4edd0af04b5ef77ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 08:40, Nick Sabalausky <span d= ir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d= iv class=3D"im"> &quot;Manu&quot; &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail= .com</a>&gt; wrote in message<br> </div>news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt;<br> &gt; Most windows programmers will simply not consider the<br> &gt; language until it is well supported in Visual Studio<br> &gt;<br> <br> </div>Yea, and that&#39;s very unfortunate. I used to be a huge fan of visu= al studio<br> for years (from around MSVC 5 through the first or second <a href=3D"http:/= /VS.NET" target=3D"_blank">VS.NET</a>), but now<br> that I&#39;ve tasted the alternatives, I find the build/project management = to be<br> a little too &quot;magical&quot; and proprietary (or at least too incompati= ble and<br> inbred), and the UI to be too bloated. I think a lot of the people who are<= br> unwilling to try anything but a heavyweight IDE are being unfair to<br> themselves and their projects by keeping themselves blinded. (Obviously, if= <br> they&#39;ve done both ways and still prefer big IDE&#39;s, that&#39;s diffe= rent.)<br></blockquote><div><br></div><div>Your personal opinion of people = who use and/or prefer visual studio is irrelevant. Most windows devs use it= , and love it. It&#39;s very important.</div> <div><br></div><div>I for one am primarily a cross platform dev, NOT a wind= ows/x86 dev, and I still use and prefer VisualStudio.</div><div>I have work= ed extensively on these platforms: Dreamcast, PS2, XBox, Gamecube, PS3, XBo= x360, Wii, PSP, NDS, iPhone, Android, Windows, and Linux... plus some other= s on occasion in the last 10 years. I rarely work on x86 platforms...</div> <div><div>Unsurprisingly, almost every platform from that list above has re= asonabe VS integration. Console SDK&#39;s are almost all exclusively VS bas= ed (this might be why most game devs use VS... perhaps a chicken/egg proble= m here, but nobody&#39;s complaining about it. Only when the VS integration= is mediocre/half arsed to people complain...) .. Some older consoles tende= d to tie themselves to CodeWarrior, but thankfully, that dwindled, and the = same platforms eventually adopted a VS integration due to demand. I&#39;ve = never heard of anyone who PREFERS CodeWarrior.</div> <br class=3D"Apple-interchange-newline"></div><div>What would you propose I= try to convince me that VS is shit and unproductive?</div><div><br></div><= div>I do use build tools, like premake, which are able to produce VS projec= ts (and makefiles, etc, for non-windows platforms/toolchains and useful for= automated scripts)...</div> <div>If you&#39;re going to talk about bloated heavy-weight IDE&#39;s, have= you every tried using Eclipse? What a joke! How is it that so many years o= f OSS dev and Google backing it can produce such a bloated, crap, slow, inc= onsistent, unfocused/unintegrated tool?!</div> <div>How about XCode? I don&#39;t understand how anyone gets any work done = with XCode, it is just soooo crap.</div><div><br></div><div>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 other= s previously. It&#39;s an important part of the toolchain, but it generally= results in a VS project for actually doing productive work...</div> <div>So there you go, another opinion for you, yet I believe mine is shared= by no small number of professional windows based devs ;)</div><div><br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> And the thing is too, with popular overrated langauges like C++ or Java, yo= u<br> *need* a fancy IDE to get anywhere and still maintain sanity. But what many= <br> of those people don&#39;t get, is that with better languages, you *don&#39;= t*<br> actually *need* all that other stuff. Sure, it can still be a nice bonus,<b= r> but it&#39;s *not* a necessity like with the popular &quot;puzzle&quot; lan= guages they&#39;re<br> used to. It&#39;s like canned vegetables: You&#39;ve gotta drench that shit= in salt,<br> sauces, spices, and all sorts of stuff just to make it go down. But with<br=

either<br> dress it up or leave it as-is; either way it still works<br> fine...no...*better* than starting with an inferior base.<br></blockquote><= div><br></div><div>Overrated? I don&#39;t think calling industry standards = overrated is a reasonable claim. they&#39;re industry standards because eve= ryone uses them... and everyone uses them because they are industry standar= ds.</div> <div>I&#39;ve used C/C++ professionally my whole career with some C# taking= over for tools recently. I hate C++! (that&#39;s why I&#39;m here!).. I do= n&#39;t hype it up like it&#39;s awesome, but I use it because it&#39;s ind= ustry standard, there is no viable alternative, and even if there were, it = would NEED integration with all my tools before I could use it professional= ly in a full production environment.</div> <div><br></div><div>I don&#39;t NEED an IDE to work with those languages sp= ecifically, I *prefer* an IDE to DO WORK FASTER... I prefer an IDE even whe= n I&#39;m writing python for instance, and it annoys me that there&#39;s no= IDE/debugger for embedded LUA.</div> <div><br></div><div>If by &#39;better&#39; languages, you mean D, then I co= mpletely disagree. D *NEEDS* an IDE, just like all the rest... and in my op= inion, even more so... here are some reasons I find it so annoying there is= n&#39;t a quality VS integration for D (yet):</div> <div>=C2=A0 ** auto is used liberally in D... I should be able to hover ove= r any variable and have a tool tip inform me what it actually is (this make= s it more important that D has an IDE than even C/C++)</div><div>=C2=A0 ** = I don&#39;t have years of experience with the libraries, I SHOULD be able t= o press &#39;.&#39; and have a list of everything the library can do appear= instantly without wasting my time trawling through the docs.</div> <div>=C2=A0 * I shouldn&#39;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, a= nd have the rest of the word will appear instantly.</div><div>=C2=A0 * If I= don&#39;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/w= hatever instantly.</div> <div>=C2=A0 * I&#39;m new to the syntax, and it&#39;s terribly nice when a = little red underline appears beneath a syntax error I&#39;ve just created.<= /div><div>=C2=A0 * As projects grow, things like auto-refactor save sooo mu= ch time. Extremely difficult to implement reliably for C/C++, but should wo= rk perfectly in D...</div> <div><br></div><div>C# for instance, is becoming very popular. The reason f= or this is that it&#39;s just sooooo fucking productive, and that&#39;s not= thanks to the language its self... any C# user will agree that at least 50= % of C#&#39;s special power is actually it&#39;s VS integration.</div> <div>The first time I used C# (knowing absolutely nothing about the languag= e), I opened VS, and started typing... thanks to the integration, the langu= age was self-documenting and self-evident. I felt immediately productive in= a language I hadn&#39;t even read a word about, and after a little more ex= perience, I love its efficiency for writing the kind of code it&#39;s great= at, and I always feel amazingly productive. The experience is not limited,= or even thanks to the language, it&#39;s the whole package.</div> <div><br></div><div>The C# experience gave me a new expectation from any ne= w language... I shouldn&#39;t need to KNOW a language, or basically anythin= g about it to start using it immediately. The IDE (auto-popup-documentation= , code completion, info tooltips, etc) is what gives me that experience. As= suming the rest of the language and libraries are designed intuitively, it = works.</div> <div><br></div><div>The reason it matters so much to me...</div><div>I susp= ect I could actually propose using D in the office for small tasks, tools, = etc... everyone hates C++, it wouldn&#39;t be hard to convince them to give= it a try.</div> <div>That said, If D doesn&#39;t have an IDE, or more specifically, VS inte= gration, it&#39;s off the table. Period. In a multi-user project, where all= users expect VS integration, I can&#39;t do without it.</div><div>If it ca= n manage to make a splash with newcomers like C# does, people will be reall= y impressed, and they&#39;ll keep coming back.</div> </div> --00235429dda4edd0af04b5ef77ad--
Jan 07 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.164.1325940038.16222.digitalmars-d puremagic.com...
 What would you propose I try to convince me that VS is shit and
 unproductive?

You're twisting my words around. That's not what I said.
 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?!

Honestly, I always found all of the VS.NETs after 2003 to be just as bloated as Eclipse. Although given a choice, I admit I'd still use it over Eclipse since I find Eclipse painfully Java-centric when using it for non-JVM languages.
 How about XCode? I don't understand how anyone gets any work done with
 XCode, it is just soooo crap.

I had some brief experience with...shoot, I forget what it was called, but it was the immediate predecessor to XCode, the one in 10.2. I think it was something generic-sounding like "Project Builder" or something. It got the job done, but yea, I was never a fan of it.
 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.

So...you agree that it's widespread...and you hate it...Ok, I give up: Exactly how is that *not* "overrated"?
 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...

I like all those features too. But I've learned that I like responsive editors and great langauges even *more*. Like I said, if you're familiar with both sides and still prefer big IDE's, fine. That's just personal taste, I've got no problems with that. But I tend to get the impression that there are a lot of "professionals" out there who would completely and immediately shun a language based *purely* on a lack of full integration with VS. Actually, I think you're one of the people who have pretty much told me exactly that, that there are many such professionals who would do that.
 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.

There was a time when I considered D and C# to be tied as my favorite languages (And yes, I was using VS.NET for all my C# work). Eventually, I became more and more frustrated by trying to work around C#'s limitations (Try making a basic, let alone realistically useful, set of generic functional tools! Without at least an IArithmetic, it's not realistically possible. Or do a simple reinterpret cast without diving into dark corners of the API.) It wasn't long before using C# felt like a full-time exercise in fighting the damn compiler. But at the same time, D just kept feeling more and more natural - even without a fancy IDE. So, based on personal experience, I tend to call "bullshit" on the idea that C#/VS.NET is highly productive for anything except GUI apps that only need the very basic UI controls and don't do a lot under the hood. And ok, maybe it's highly productive compared to C++, but that sure as hell isn't saying much. Honest to god, I'm *more* productive with D and Programmer's Notepad 2 than I ever was with C#/VS.NET. And much happier too (at least when I'm actually coding, anyway ;)) But I never would have discovered that if I had been an IDE-snob. Obviously you're not one, as you pointed out you've at least tried things the other way, too. But from what you describe, it appears that a lot of people in the industry *are* staunch IDE-snobs.
 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.

FWIW, I have always agreed that it's good for D to have good IDE integration because, like you've been saying, there are people who prefer it. And heck, once in a while I find it useful too, so I fire it up...wait a while...do what I need to do...slowly..., and then go back to my usual setup.
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f4b5ce01604b5ef806b
Content-Type: text/plain; charset=UTF-8

On 7 January 2012 10:40, Adam Wilson <flyboynw gmail.com> wrote:

 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.

Hear, hear! --20cf30363f4b5ce01604b5ef806b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 10:40, Adam Wilson <span dir= =3D"ltr">&lt;<a href=3D"mailto:flyboynw gmail.com">flyboynw gmail.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Fri, 06 Jan 2012 23:31:52 -0800, torhu &lt;no spam.inv= alid&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 06.01.2012 21:02, Adam Wilson wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> COFF is an absolute requirements when working on Windows, yet DMD doesn&#39= ;t<br> support it. Everything, every programming interface, every application<br> running on x64 Windows is built with COFF, the default output of every<br> other compiler on Windows is COFF, everyone else programming on Windows is<= br> expecting COFF.<br> Windows represents the largest OS install base in the world; and yet,<br> Windows based D programmers are told that they have to dig up extremely<br> esoteric tools from the darkest, smelliest, most cobwebbed corners of the<b= r> Internet, just to be able to interact with the the rest of the Windows<br> world.<br> <br> This situation is simply unacceptable.<br> </blockquote> <br> It&#39;s not that bad. =C2=A0Most libraries can be compiled to DLL files, i= n fact that&#39;s often the default. =C2=A0DMD/Optlink can use DLL files cr= eated by other tool chains just fine. If an import library in the correct f= ormat is not available, just use implib or coffimplib to create one. =C2=A0= No problem.<br> </blockquote> <br></div> First of all, what if I want to use a DLL lib file that was created by DMD = in VC++? Oh right, can&#39;t do that either. I know there are converter too= ls available, but all of them are closed source, and what if the creator de= cides one day that he is done? I&#39;m stuck with no source and potential b= ugs.<br> Second, as a professional, the idea that somehow the advice to download Eso= teric Tool X from Shady FTP Server Y is acceptable is completely beyond me.= No professional compiler implementation would DARE give that advice to it&= #39;s clients, they&#39;d laugh and find another compiler that did what the= y want. The concept of kludging together a build toolchain is uniquely open= source. DMD will never get buy-in from large groups of professionals witho= ut natively supporting the things those professionals expect.<br> <br> Let me state that again for clarity. If DMD does not natively support the s= tandard outputs that professionals have come to expect and demand, then DMD= will forever remain a hobby toy.<br> <br> Professionals don&#39;t have time to kludge together a [fragile] build tool= chain and support it, they have work to do. Given the choice for a large pr= oject right now, i&#39;d have to say VC++ wins on Windows every time, it&#3= 9;s got COFF, excellent tooling and libraries, and x64 support; but mostly,= it works with everything Windows. DMD does not. Until DMD does, profession= als cannot seriously consider DMD.</blockquote> <div><br></div><div>Hear, hear!</div></div> --20cf30363f4b5ce01604b5ef806b--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f4b7fecb404b5ef85cd
Content-Type: text/plain; charset=UTF-8

On 7 January 2012 11:37, Don <nospam nospam.com> wrote:

 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.

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.

Definitely. I'd be happy/prefer to use VisualC's linker if the D objects/libs were compatible. --20cf30363f4b7fecb404b5ef85cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 11:37, Don <span dir=3D"ltr">&= lt;<a href=3D"mailto:nospam nospam.com">nospam nospam.com</a>&gt;</span> wr= ote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 06.01.2012 21:02, Adam Wilson wrote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Fri, 06 Jan 2012 10:27:58 -0800, Manu &lt;<a href=3D"mailto:turkeyman gm= ail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Okay, so I was trying to link to a C lib, and I realised... DMD doesn&#39;t= <br> support/produce VS compatible libs.<br> I should have realised this sooner, noting the cv debuginfo.<br> <br> So like... WTF?<br> <br> How am I supposed to use DMD in Windows in anything other than trivial,<br> self-contained programs?<br> VisualC is the de facto standard in Windows. All libs are COFF, and<br> (unless<br> I&#39;m working with GCC) everything I want to link to is produced from VC.= <br> <br> Let&#39;s also mention the debug info... Virtually every 3rd party tool<br> assumes<br> and/or works best with PDB debug info. Being required to run cv2pdb is<br> pretty lame.<br> <br> So... why no support for COFF libs, and PDB debug info?<br> Surely at least a compiler option would do the business if there is some<br=

<br> I was hoping to start a project using D as a front end language<br> interacting<br> with my C/C++ engine lib... but I can&#39;t.<br> ... and now that I think if it... how do ANY programs built with DMD<br> actually work? .. How does it link to system32.lib, user32.lib, etc?<br> </blockquote> <br> DMD on Linux gets ELF with x64 support.<br> DMD on OSX gets Mach-O with x64 support.<br> DMD on Windows gets ... OMF with no x64 support.<br> <br> COFF is an absolute requirements when working on Windows, yet DMD<br> doesn&#39;t support it. Everything, every programming interface, every<br> application running on x64 Windows is built with COFF, the default<br> output of every other compiler on Windows is COFF, everyone else<br> programming on Windows is expecting COFF.<br> Windows represents the largest OS install base in the world; and yet,<br> Windows based D programmers are told that they have to dig up extremely<br> esoteric tools from the darkest, smelliest, most cobwebbed corners of<br> the Internet, just to be able to interact with the the rest of the<br> Windows world.<br> <br> This situation is simply unacceptable.<br> <br> Everything else on Windows is COFF, if DMD ever wants to be accepted as<br> a mainstream Windows development tool, it simply *MUST* support COFF.<br> And no amount of wishing will ever change this. Without COFF, D will<br> ALWAYS be hamstrung on Windows, even if OMF ever got x64 support. Every<br> other platform that DMD supports got their native object formats. It is<br> now time to get the native Windows format in D.<br> <br> All DMD needs to do is output the COFF files, any number of linkers<br> available on Windows can handle it from there. It doesn&#39;t have to<br> replace OMF and it doesn&#39;t even have to be the default option, but it<b= r> absolutely MUST be AN option.<br> <br> </blockquote> <br></div></div>
From everything I&#39;ve seen, COFF seems to be very closely related to ELF=

In the old DDL project on dsource, a lot of work was done in deciphering th= e formats. COFF is a lot better documented than Mach-O.<br> <br> IMHO we should be looking at adding COFF output to the compiler, not to the= linker.<br></blockquote><div><br></div><div>Definitely. I&#39;d be happy/p= refer to use VisualC&#39;s linker if the D objects/libs were compatible.</d= iv> </div> --20cf30363f4b7fecb404b5ef85cd--
Jan 07 2012
prev sibling next sibling parent "Froglegs" <lugtug gmail.com> writes:
  A great IDE is essential for D to really succeed.

  Visual D is a solid start but it isn't really usable for a large 
project yet.

-  The debugging experience is funky, it can't seem to see many 
variables
-  hovering over variables generally doesn't show anything useful
-  hitting . doesn't pop up possible members
-  very limited syntax highlighting

  D might have simplified C++ syntax, but it is still quite 
complex, not having an IDE that supports the type of things that 
Visual Studio supports is just painful-- I doubt D has any chance 
in the game industry without much better VS support.

Aside from C++ I also use Lua quite often and even in a light 
weight scripting language like Lua I much prefer an 
IDE(Decoda--Manu it works with embedded scripts btw).
Jan 07 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--0021cc022fb6a3cc0804b5f79c8e
Content-Type: text/plain; charset=UTF-8

Just for the record, my post was intentionally excessively inflammatory. I
do like a good IDE vs non-IDE debate! :P

On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:

 So...you agree that it's widespread...and you hate it...Ok, I give up:
 Exactly how is that *not* "overrated"?

In that, I don't think most people would rate it 10/10 :) I'll give it maybe... 7/10. I mean, it's pretty good. It's universally accepted, definitely stood the test of time, and produced much of the worlds best software. But it's old and outdated, refuses to respond to modern updates/requests in reasonable time, and a lot of modern features they EVENTUALLY put in there just don't address concerns that, at least my circle of developers, care about. Also they tend to just bloat the already bloated as hell standard library! ...and I think most people agree. So no, I don't think it's overrated, I think it's quite fairly rated :P But I tend to get the impression that
 there are a lot of "professionals" out there who would completely and
 immediately shun a language based *purely* on a lack of full integration
 with VS. Actually, I think you're one of the people who have pretty much
 told me exactly that, that there are many such professionals who would do
 that.

Yup, and I believe that's completely true :) I expect a huge surge of developers will appear the moment a quality VS integration exists. There was a time when I considered D and C# to be tied as my favorite
 languages (And yes, I was using VS.NET for all my C# work). Eventually, I
 became more and more frustrated by trying to work around C#'s limitations
 (Try making a basic, let alone realistically useful, set of generic
 functional tools! Without at least an IArithmetic, it's not realistically
 possible. Or do a simple reinterpret cast without diving into dark corners
 of the API.) It wasn't long before using C# felt like a full-time exercise
 in fighting the damn compiler. But at the same time, D just kept feeling
 more and more natural - even without a fancy IDE.

Well I'm certainly not sharing that feeling, at least not yet. I'd like to think it might get there though with some more time... So, based on personal experience, I tend to call "bullshit" on the idea that
 C#/VS.NET is highly productive for anything except GUI apps that only need
 the very basic UI controls and don't do a lot under the hood. And ok, maybe
 it's highly productive compared to C++, but that sure as hell isn't saying
 much.

I'm sure you've got more experience than me in this area.. All I've ever made with C# were some nice tools/GUI apps. The experience was always elegant and enjoyable. My only complaint is that I created them so much faster than I expected... then I was finished, and had to get back on to C/C++ work again :( Honest to god, I'm *more* productive with D and Programmer's Notepad 2 than
 I ever was with C#/VS.NET. And much happier too (at least when I'm
 actually
 coding, anyway ;)) But I never would have discovered that if I had been an
 IDE-snob. Obviously you're not one, as you pointed out you've at least
 tried
 things the other way, too. But from what you describe, it appears that a
 lot
 of people in the industry *are* staunch IDE-snobs.

Well you're obviously weird ;) Oh I'm definitely an IDE snob. I use all the other tools for cross platform dev, automation, homebrew hobby work, etc, but I can't stand editing code without a nice editor, the ability to hit ctrl-F7, and even debug, instantly and seamlessly. I go miles out of my way to integrate whatever toolchain I'm working with into VS as best I can. The difference between me and most others like me is, I go out of my way, whereas most other people, if said integration doesn't already exist, will just give up and move with something else. I will definitely admit though, VS2010 was a major step backwards.. Everything suddenly got all slow and buggy. Infact, I do feel it's been going backwards since VS6... Although I think 2005 was a good year :) 2010 is the best VS yet though when it comes to custom workflow integration, they are getting better at that, they're just ruining the rest of the actual IDE in the mean time! >_< --0021cc022fb6a3cc0804b5f79c8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">Just for the record, my post was intentionally e= xcessively=C2=A0inflammatory. I do like a good IDE vs non-IDE debate! :P</d= iv><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">On 7 Jan= uary 2012 22:22, Nick Sabalausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wro= te:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">So...you agree that it&#39= ;s widespread...and you hate it...Ok, I give up:</div> Exactly how is that *not* &quot;overrated&quot;?<br></blockquote><div><br><= /div><div>In that, I don&#39;t think most people would rate it 10/10 :)</di= v><div>I&#39;ll give it maybe... 7/10. I mean, it&#39;s pretty good. It&#39= ;s universally accepted, definitely stood the test of time, and produced mu= ch of the worlds best software.</div> <div>But it&#39;s old and outdated, refuses to respond to modern updates/re= quests in reasonable time, and a lot of modern features they EVENTUALLY put= in there just don&#39;t address concerns that, at least my circle of devel= opers, care about.</div> <div>Also they tend to just bloat the already bloated as hell standard libr= ary!</div><div><br></div><div>...and I think most people agree.=C2=A0So no,= I don&#39;t think it&#39;s overrated, I think it&#39;s quite fairly rated = :P</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">But I tend to get the impression that</div> there are a lot of &quot;professionals&quot; out there who would completely= and<br> immediately shun a language based *purely* on a lack of full integration<br=

h<br> told me exactly that, that there are many such professionals who would do<b= r> that.<br></blockquote><div><br></div><div>Yup, and I believe that&#39;s com= pletely true :)</div><div>I expect a huge surge of developers will appear t= he moment a quality VS integration exists.</div><div><br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"> <div class=3D"im">There was a time when I considered D and C# to be tied as= my favorite</div> languages (And yes, I was using <a href=3D"http://VS.NET" target=3D"_blank"=
VS.NET</a> for all my C# work). Eventually, I<br>

ns<br> (Try making a basic, let alone realistically useful, set of generic<br> functional tools! Without at least an IArithmetic, it&#39;s not realistical= ly<br> possible. Or do a simple reinterpret cast without diving into dark corners<= br> of the API.) It wasn&#39;t long before using C# felt like a full-time exerc= ise<br> in fighting the damn compiler. But at the same time, D just kept feeling<br=

</div><div>Well I&#39;m certainly not sharing that feeling, at least not ye= t. I&#39;d like to think it might get there though with some more time...</= div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">So, based on personal experie= nce, I tend to call &quot;bullshit&quot; on the idea that<br> C#/<a href=3D"http://VS.NET" target=3D"_blank">VS.NET</a> is highly product= ive for anything except GUI apps that only need<br> the very basic UI controls and don&#39;t do a lot under the hood. And ok, m= aybe<br> it&#39;s highly productive compared to C++, but that sure as hell isn&#39;t= saying<br> much.<br></blockquote><div><br></div><div>I&#39;m sure you&#39;ve got more = experience than me in this area.. All I&#39;ve ever made with C# were some = nice tools/GUI apps.</div><div>The experience was always elegant and enjoya= ble. My only complaint is that I created them so much faster than I expecte= d... then I was finished, and had to get back on to C/C++ work again :(</di= v> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">Honest to god, I&#39;m *more*= productive with D and Programmer&#39;s Notepad 2 than<br> I ever was with C#/<a href=3D"http://VS.NET" target=3D"_blank">VS.NET</a>. = And much happier too (at least when I&#39;m actually<br> coding, anyway ;)) But I never would have discovered that if I had been an<= br> IDE-snob. Obviously you&#39;re not one, as you pointed out you&#39;ve at le= ast tried<br> things the other way, too. But from what you describe, it appears that a lo= t<br> of people in the industry *are* staunch IDE-snobs.<br></blockquote><div><br=
</div><div>Well you&#39;re obviously weird ;)</div><div><br></div><div>Oh =

m dev, automation, homebrew hobby work, etc, but I can&#39;t stand editing = code without a nice editor, the ability to hit ctrl-F7, and even debug, ins= tantly and seamlessly.</div> <div>I go miles out of my way to integrate whatever toolchain I&#39;m worki= ng with into VS as best I can. The difference between me and most others li= ke me is, I go out of my way, whereas most other people, if said integratio= n doesn&#39;t already exist, will just give up and move with something else= .</div> <div><br></div><div>I will definitely admit though, VS2010 was a major step= backwards.. Everything suddenly got all slow and buggy.</div><div>Infact, = I do feel it&#39;s been going backwards since VS6... Although I think 2005 = was a good year :)</div> <div>2010 is the best VS yet though when it comes to custom workflow integr= ation, they are getting better at that, they&#39;re just ruining the rest o= f the actual IDE in the mean time! &gt;_&lt;</div></div> --0021cc022fb6a3cc0804b5f79c8e--
Jan 07 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.174.1325975010.16222.digitalmars-d puremagic.com...
 Just for the record, my post was intentionally excessively inflammatory. I
 do like a good IDE vs non-IDE debate! :P

Heh, fair enough. Hell, it's not as if I'm not known for being overly inflammatory...
 On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:

 So...you agree that it's widespread...and you hate it...Ok, I give up:
 Exactly how is that *not* "overrated"?

...and I think most people agree. So no, I don't think it's overrated, I think it's quite fairly rated :P

I see :) Guess I just chose the wrong word then ;)
 Yup, and I believe that's completely true :)
 I expect a huge surge of developers will appear the moment a quality VS
 integration exists.

Oh yea.
 I'm sure you've got more experience than me in this area.. All I've ever
 made with C# were some nice tools/GUI apps.
 The experience was always elegant and enjoyable. My only complaint is that
 I created them so much faster than I expected... then I was finished, and
 had to get back on to C/C++ work again :(

Yea, it *is* nicer than C/C++ as long as you don't need to go too low-level or too high-level. That's why I had gotten into it in the first place. Sort of a middle-ground between C/C++ and Java.
 Honest to god, I'm *more* productive with D and Programmer's Notepad 2 
 than
 I ever was with C#/VS.NET. And much happier too (at least when I'm
 actually
 coding, anyway ;)) But I never would have discovered that if I had been 
 an
 IDE-snob. Obviously you're not one, as you pointed out you've at least
 tried
 things the other way, too. But from what you describe, it appears that a
 lot
 of people in the industry *are* staunch IDE-snobs.

Well you're obviously weird ;)

Heh, I'm a weirdo in sooo many ways it's rediculous...
 Oh I'm definitely an IDE snob. I use all the other tools for cross 
 platform
 dev, automation, homebrew hobby work, etc, but I can't stand editing code
 without a nice editor, the ability to hit ctrl-F7, and even debug,
 instantly and seamlessly.
 I go miles out of my way to integrate whatever toolchain I'm working with
 into VS as best I can. The difference between me and most others like me
 is, I go out of my way, whereas most other people, if said integration
 doesn't already exist, will just give up and move with something else.

See, I used to do that [1]. But I guess instead of giving up and moving back to more established mainstream languages, I gave up and moved on to other editors and build methods. [1] Actually, when I was doing GBA homebrew I even made a GBA AppWizard for MSVC 6: http://www.semitwist.com/gbadev/ I tried to make a VS.NET version (back with the original VS.NET), but I found the whole process to be confusing as hell, and the docs didn't seem to be much help.
 I will definitely admit though, VS2010 was a major step backwards..
 Everything suddenly got all slow and buggy.
 Infact, I do feel it's been going backwards since VS6... Although I think
 2005 was a good year :)

Heh. Different experiences. I first noticed VS starting to get slow with 2003, but it wasn't enough to really turn me off yet, just annoy me (although the price tag every few years was getting to be a problem, especially since I wasn't much of a student anymore...Of course, this was before the Express editions). Then with 2005 I pretty much just gave up on VS for various reasons - speed, cost, lack of even basic D support, difficulty in extending it to do what I wanted, and just being a little bit too..."proprietary" and "inbred" are the only words I can think of for it, but "inbred" is more inflammatory than what I really mean and "proprietary" isn't exactly correct either...
 2010 is the best VS yet though when it comes to custom workflow
 integration, they are getting better at that, they're just ruining the 
 rest
 of the actual IDE in the mean time! >_<

Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51ba51fda7ed104b5f7aa86
Content-Type: text/plain; charset=UTF-8

On 7 January 2012 20:43, Froglegs <lugtug gmail.com> wrote:

 Aside from C++ I also use Lua quite often and even in a light weight
 scripting language like Lua I much prefer an IDE(Decoda--Manu it works with
 embedded scripts btw).

Cheers for the pro-tip! :) --bcaec51ba51fda7ed104b5f7aa86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 20:43, Froglegs <span dir=3D"l= tr">&lt;<a href=3D"mailto:lugtug gmail.com">lugtug gmail.com</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"> Aside from C++ I also use Lua quite often and even in a light weight script= ing language like Lua I much prefer an IDE(Decoda--Manu it works with embed= ded scripts btw).<br></blockquote><div><br></div><div>Cheers for the pro-ti= p! :)</div> </div> --bcaec51ba51fda7ed104b5f7aa86--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0021cc022fb6fef14204b60294cc
Content-Type: text/plain; charset=UTF-8

On 8 January 2012 02:27, Walter Bright <newshound2 digitalmars.com> wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.

I'd quite like to use the VisualC linker... so I hope this isn't a substitute for implementing COFF output to the compiler at some point. --0021cc022fb6fef14204b60294cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 02:27, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 1/7/2012 6:00 AM, Jacob Carlborg wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Will dmd still produce OMF or will it be changed to produce COFF?<br> </blockquote> <br></div> It will be irrelevant, as the linker will read whatever it puts out, and th= e linker will read COFF.<br> <br> There is no reason why a linker cannot transparently read many object and l= ibrary file formats. I even want the linker to be able to read a DLL and fi= gure out how to interface it without needing to build a corresponding impor= t library.<br> <br> There&#39;s quite a bit that can be done that was impractical for linkers o= f yore because of severe memory constraints.<br></blockquote><div><br></div=
<div>I&#39;d quite like to use the VisualC linker... so I hope this isn&#3=

.</div> </div> --0021cc022fb6fef14204b60294cc--
Jan 08 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:
 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce 
 COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.

Yet you are the only one who can maintain optlink, just as you are the only one who can process pull requests. The latter is much more important, especially since there already are stable alternative linkers with more features. e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes severe bugs with postblits/destructors and has been open for 4 months already without any comment from your side. We have to live with the fact that bugs are fixed somewhat randomly (i.e. the bugzilla voting system is completely ignored), but it isn't acceptable that we have to deal with bugs that have been fixed months ago but just not merged yet. Bug 314 is a prime example for all of that (most voted bug for years, fixed in ldc long ago, pull request was open for ages). Also the dmd code needs improvement. It should leverage C++11 features, become more modular and code quality needs to be improved. For example the typed Array was long overdue, yet people still use that crappy tdata() syntax instead of just []. The C++11 range based for loop would be a logical next step for that. Other things that come to my mind are replacing hard-coded values with proper constants, introducing smart pointers so at least some memory is released and better (documentation) comments.
Jan 08 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 14:39:59 UTC, Peter Alexander wrote:
 It's still far too early to start using C++11 stuff because not 
 all compilers support it. OSX still ships with g++ 4.2. 
 Expecting people to install a new compiler just to compile the 
 DMD code is a pointless barrier. Especially if the only reason 
 for using C++11 is relatively minor syntactic changes.

Usage can be restricted to those features that are well supported. Apple switched to Clang.
 Smart pointers (especially shared_ptr) are not free. They will 
 make DMD slower, compile more slowly, and bloat the syntax (T* 
 vs. std::shared_ptr<T>).

design everything for speed and memory efficiency.
 All this stuff you have proposed requires time. Time is 
 precious. What do you propose should be delayed so that this 
 work could be carried out?

I didn't say it has to happen today. But it should be a goal. Investing precious time in an old linker instead of just putting out COFF and using existing alternative ones isn't the right path.
Jan 08 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f4b03eacb04b609aba1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8 January 2012 21:49, Walter Bright <newshound2 digitalmars.com> wrote:

 On 1/8/2012 3:02 AM, Alex R=C3=B8nne Petersen wrote:

 If not, we're bound to need COFF eventually.

Probably. Or elf.

Elf? Don't be silly. Windows needs COFF. I should be able to use the visual studio linker. --20cf30363f4b03eacb04b609aba1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 21:49, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 1/8/2012 3:02 AM, Alex R=C3=B8nne Petersen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">If not, we&#39;re bound to need COFF eventua= lly.</blockquote></div><div class=3D"im"> <br></div> Probably. Or elf.<br></blockquote><div><br></div><div>Elf? Don&#39;t be sil= ly. Windows needs COFF. I should be able to use the visual studio linker.</= div></div> --20cf30363f4b03eacb04b609aba1--
Jan 08 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:
 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce 
 COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF. There is no reason why a linker cannot transparently read many object and library file formats. I even want the linker to be able to read a DLL and figure out how to interface it without needing to build a corresponding import library. There's quite a bit that can be done that was impractical for linkers of yore because of severe memory constraints.

It certainly won't be irrelevant, as people will want to produce libraries with dmd too, and other toolchains have to be able to read them.
Jan 08 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sat, 07 Jan 2012 23:23:16 +0100, Manu <turkeyman gmail.com> wrote:

 Just for the record, my post was intentionally excessively inflammatory.  
 I
 do like a good IDE vs non-IDE debate! :P

 On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:

Investing time to get familiar with emacs has been a huge win for me. D with posix+emacs+gdb is on par with C++ and very productive IMHO. martin
Jan 08 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
By the way, Walter, I'm fixing druntime and Phobos makefiles 
after the Shared ELF merge so they can be built as shared libs (I 
have them working both now, on my FreeBSD box). I just wanna ask 
you, I think it would be a good idea to remove default phobos2 
linkage from dmd and move that to dmd.conf instead, as the 
phobos2 linkage comes after dmd.conf linkages and druntime has to 
be linked after phobos (I'd like them as separate libs). Do you 
think I can do that, or any other idea?
Jan 08 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 08.01.2012, 20:59 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 On 1/8/2012 6:14 AM, Trass3r wrote:
 e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes  
 severe bugs
 with postblits/destructors and has been open for 4 months already  
 without any
 comment from your side.

Don knows what he's doing, and it's waiting for fixes to his observations.

You should have posted there that you are waiting for this. As I understand it Kenji has fixed some stuff that Don mentioned, but won't do anything about the points that are optimizations rather than fixes soon. So wouldn't it be better to pull now?
 I'd like to use C++11 features in the dmd source, too. The downside is  
 that all the C++ compilers on all the current and potential targets for  
 D need to reliably support those C++11 features. Currently, this is not  
 close to true, and likely won't be for some time.

I thought even dmc supports a few features. Which one doesn't implement C++11 at all?
Jan 08 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 Clang is a lot slower at compiling than dmc.

With or without optimizations? Would be interesting to see detailed comparisons lexing/parsing/... like http://clang.llvm.org/performance.html
Jan 08 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 08.01.2012, 20:58 Uhr, schrieb q66 <quaker66 gmail.com>:

 On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:
 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
 Will dmd still produce OMF or will it be changed to produce COFF?

It will be irrelevant, as the linker will read whatever it puts out, and the linker will read COFF.

libraries with dmd too, and other toolchains have to be able to read them.

Good point.
Jan 08 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:

 By the way, Walter, I'm fixing druntime and Phobos makefiles after the  
 Shared ELF merge so they can be built as shared libs (I have them  
 working both now, on my FreeBSD box). I just wanna ask you, I think it  
 would be a good idea to remove default phobos2 linkage from dmd and move  
 that to dmd.conf instead, as the phobos2 linkage comes after dmd.conf  
 linkages and druntime has to be linked after phobos (I'd like them as  
 separate libs). Do you think I can do that, or any other idea?

I hope you know that shared libraries still don't work. It needs runtime which is currently being merged. There are ShareRuntime branches for dmd/druntime/phobos https://github.com/dawgfoto and I'd be glad have a cleaner Makefile solution than mine.
Jan 08 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Sunday, 8 January 2012 at 21:10:21 UTC, Martin Nowak wrote:
 Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:

 By the way, Walter, I'm fixing druntime and Phobos makefiles 
 after the Shared ELF merge so they can be built as shared libs 
 (I have them working both now, on my FreeBSD box). I just 
 wanna ask you, I think it would be a good idea to remove 
 default phobos2 linkage from dmd and move that to dmd.conf 
 instead, as the phobos2 linkage comes after dmd.conf linkages 
 and druntime has to be linked after phobos (I'd like them as 
 separate libs). Do you think I can do that, or any other idea?

I hope you know that shared libraries still don't work. It needs runtime which is currently being merged. There are ShareRuntime branches for dmd/druntime/phobos https://github.com/dawgfoto and I'd be glad have a cleaner Makefile solution than mine.

don't work? I use git and they're working perfectly fine for me :)
Jan 08 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
Am 08.01.2012, 22:14 Uhr, schrieb q66 <quaker66 gmail.com>:

 On Sunday, 8 January 2012 at 21:10:21 UTC, Martin Nowak wrote:
 Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:

 By the way, Walter, I'm fixing druntime and Phobos makefiles after the  
 Shared ELF merge so they can be built as shared libs (I have them  
 working both now, on my FreeBSD box). I just wanna ask you, I think it  
 would be a good idea to remove default phobos2 linkage from dmd and  
 move that to dmd.conf instead, as the phobos2 linkage comes after  
 dmd.conf linkages and druntime has to be linked after phobos (I'd like  
 them as separate libs). Do you think I can do that, or any other idea?

I hope you know that shared libraries still don't work. It needs runtime which is currently being merged. There are ShareRuntime branches for dmd/druntime/phobos https://github.com/dawgfoto and I'd be glad have a cleaner Makefile solution than mine.

don't work? I use git and they're working perfectly fine for me :)

No EH, no static/TLS GC roots from shared libraries.
Jan 08 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 22:50:07 UTC, Walter Bright wrote:
 Would be interesting to see detailed comparisons 
 lexing/parsing/... like
 http://clang.llvm.org/performance.html

Being faster than gcc isn't a great trick.

I didn't claim the opposite. I was curious why dmc is faster.
Jan 08 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 8 January 2012 at 22:52:17 UTC, Walter Bright wrote:
 Once Phobos works as a shared lib, I think we should switch to 
 that as the default.

Please, no. That would mean standalone executables won't work by default.
Jan 08 2012
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
--f46d043c077e80fdcd04b60d7943
Content-Type: text/plain; charset=ISO-8859-1

 Not to get too far off topic, I'm the only one where I work who will use
 C#. I think some people simply hate Microsoft the company so much that they
 would not even fire up C# and try it once. They won't be caught liking it.
 And that's seems to be the case where I work as far as I can tell. Maybe D
 would be more well received than C# by such people if it integrated better
 with VS, I don't know. But there is always the issue with less widely used
 languages: if I write our company's main product in D, and if we then need
 to hire more people, I need to tell my boss we need to hire people that
 know D (or are at least willing and able pick it up) which are not as
 common. If anything at all goes wrong with D that wouldn't have gone wrong
 had we used C++, it's on me. No one ever got fired for buying IBM, lol.
 Sorry, I know we need to battle past that but I can't help mentioning it.

Not so much hate Microsoft as cautious of using platforms that contain a lot of Microsoft IP. The thing about Microsoft is that it isn't really one monolithic company and while the divisions of the company that do C# and .net are probably totally cool there are other parts of of the company who wouldn't hesitate to leverage that IP against anything they perceive to be a competitive threat. Even if they don't C# being a VM based language there is a lot of Oracle IP to deal with (Microsoft currently pay Oracle a metric f*cktonne of money per year to use that IP and I am not sure where alternate .Net implementations stand in this regards). See Microsoft v Google and Oracle v Google. This probably won't be an issue if you are heavily microsoft centric in what you are doing anyways just not sure how much I trust it as a cross platform solution in the long term. Ideally D would allow you to write code that is in the same ballpark performance wise as C/C++ but with much greater programmer productivity. I don't think it's quite there yet. I think that IDE intergration including V S is part of that, in fact I think it is something of a low hanging fruit. --f46d043c077e80fdcd04b60d7943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not to get too fa= r off topic, I&#39;m the only one where I work who will use C#. I think som= e people simply hate Microsoft the company so much that they would not even= fire up C# and try it once. They won&#39;t be caught liking it. And that&#= 39;s seems to be the case where I work as far as I can tell. Maybe D would = be more well received than C# by such people if it integrated better with V= S, I don&#39;t know. But there is always the issue with less widely used la= nguages: if I write our company&#39;s main product in D, and if we then nee= d to hire more people, I need to tell my boss we need to hire people that k= now D (or are at least willing and able pick it up) which are not as common= . If anything at all goes wrong with D that wouldn&#39;t have gone wrong ha= d we used C++, it&#39;s on me. No one ever got fired for buying IBM, lol. S= orry, I know we need to battle past that but I can&#39;t help mentioning it= .<br> </blockquote></div><br><div>Not so much hate Microsoft as cautious of using= platforms that contain a lot of Microsoft IP. The thing about Microsoft is= that it isn&#39;t really one monolithic company and while the divisions of= the company that do C# and .net are probably totally cool there are other = parts of of the company who wouldn&#39;t hesitate to leverage that IP again= st anything they=A0perceive=A0to be a competitive threat. Even if they don&= #39;t C# being a VM based language there is a lot of Oracle IP to deal with= (Microsoft currently pay Oracle a metric f*cktonne of money per year to us= e that IP and I am not sure where alternate .Net implementations stand in t= his regards). See Microsoft v Google and Oracle v Google. This probably won= &#39;t be an issue if you are heavily microsoft centric in what you are doi= ng anyways just not sure how much I trust it as a cross platform solution i= n the long term.</div> <div><br></div><div>Ideally D would allow you to write code that is in the = same ballpark performance wise as C/C++ but with much greater programmer pr= oductivity. I don&#39;t think it&#39;s quite there yet. I think that IDE in= tergration including V S is part of that, in fact I think it is something o= f a low hanging fruit.</div> --f46d043c077e80fdcd04b60d7943--
Jan 08 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.

My problem with this is a shared lib actually *increases* the size. At best, it fools you by separating it out into two or three files instead of one. A better solution to the executable size problem is to actually make them smaller, like Andrei was doing a couple weeks ago. He made a huge difference just by changing a handful of lines to reduce unnecessary coupling in Phobos.
 Note that the default with gcc is to link with the shared C 
 runtime, and it will be expected for dmd.

The big difference there is people usually already have the C runtime and use it for many programs. They don't actually have to think about installing it. Imagine how many people, especially on Linux, will now start asking "I built a D program, but when I run it, it complains that it can't find libphobos2.so", or the already somewhat common version mismatches that happen when you update one but not the other. Would you rather have someone complaining about a 200 kb executable, on an executable that doesn't work right without end user action?
Jan 08 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
Am 09.01.2012, 04:59 Uhr, schrieb Adam D. Ruppe  
<destructionator gmail.com>:

 On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.

My problem with this is a shared lib actually *increases* the size. At best, it fools you by separating it out into two or three files instead of one. A better solution to the executable size problem is to actually make them smaller, like Andrei was doing a couple weeks ago. He made a huge difference just by changing a handful of lines to reduce unnecessary coupling in Phobos.
 Note that the default with gcc is to link with the shared C runtime,  
 and it will be expected for dmd.

The big difference there is people usually already have the C runtime and use it for many programs. They don't actually have to think about installing it. Imagine how many people, especially on Linux, will now start asking "I built a D program, but when I run it, it complains that it can't find libphobos2.so", or the already somewhat common version mismatches that happen when you update one but not the other. Would you rather have someone complaining about a 200 kb executable, on an executable that doesn't work right without end user action?

We will have to install the libraries into a sensible place by default. Also multiple processes using the same shared library will benefit from memory savings.
Jan 08 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 9 January 2012 at 04:54:45 UTC, Martin Nowak wrote:
 We will have to install the libraries into a sensible place by 
 default.

Right now, you can just unzip it and go. Are we going to break that too?
 Also multiple processes using the same shared library will 
 benefit from memory savings.

We're talking maybe, MAYBE, one megabyte here.
Jan 08 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 Realistically, it shouldn't be until libphobos is stable *and* about as  
 common as libc.

Exactly. It doesn't make any sense as long as there's a new version every month. We should do something about dead code elimination though. -ffunction-sections -fdata-sections -L--gc-sections greatly reduces the size with gdc, but you can't expect users to always pass that.
Jan 09 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf302ef924031e9804b6184afd
Content-Type: text/plain; charset=UTF-8

On 9 January 2012 15:14, Trass3r <un known.com> wrote:

 Realistically, it shouldn't be until libphobos is stable *and* about as
 common as libc.

Exactly. It doesn't make any sense as long as there's a new version every month. We should do something about dead code elimination though. -ffunction-sections -fdata-sections -L--gc-sections greatly reduces the size with gdc, but you can't expect users to always pass that.

static this() seems to be a problem. Unless there's powerful whole-program-optimisation, how can it strip out any data that might be initialised/touched in static this()? Why wouldn't dead code be eliminated effectively already? --20cf302ef924031e9804b6184afd Content-Type: text/html; charset=UTF-8 <div class="gmail_quote">On 9 January 2012 15:14, Trass3r <span dir="ltr">&lt;<a href="mailto:un known.com">un known.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Realistically, it shouldn&#39;t be until libphobos is stable *and* about as common as libc.<br> </blockquote> <br></div> Exactly. It doesn&#39;t make any sense as long as there&#39;s a new version every month.<br> We should do something about dead code elimination though.<br> -ffunction-sections -fdata-sections -L--gc-sections greatly reduces the size with gdc, but you can&#39;t expect users to always pass that.<br> </blockquote></div><br><div>static this() seems to be a problem. Unless there&#39;s powerful whole-program-optimisation, how can it strip out any data that might be initialised/touched in static this()?</div><div><br></div> <div>Why wouldn&#39;t dead code be eliminated effectively already?</div> --20cf302ef924031e9804b6184afd--
Jan 09 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 static this() seems to be a problem. Unless there's powerful
 whole-program-optimisation, how can it strip out any data that might be
 initialised/touched in static this()?

 Why wouldn't dead code be eliminated effectively already?

the whole module is pulled in.
Jan 09 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c768f26ef66a404b61a5ed9
Content-Type: text/plain; charset=UTF-8

On 9 January 2012 15:27, Trass3r <un known.com> wrote:

 static this() seems to be a problem. Unless there's powerful
 whole-program-optimisation, how can it strip out any data that might be
 initialised/touched in static this()?


I'm sure it's possible, but it would need some pretty powerful global expression analysis. Ie, if data initialised in static this() is only touched in one function lets say, and that function is never referenced, then it should surely be able to safely eliminate that function and associated data? Why wouldn't dead code be eliminated effectively already?

the whole module is pulled in.

Why would it pull the whole module if only one function is used? And why can't a post-link strip process clean it up? --00248c768f26ef66a404b61a5ed9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 9 January 2012 15:27, Trass3r <span dir=3D"lt= r">&lt;<a href=3D"mailto:un known.com">un known.com</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> static this() seems to be a problem. Unless there&#39;s powerful<br> whole-program-optimisation, how can it strip out any data that might be<br> initialised/touched in static this()?<br> </blockquote></div> It probably can&#39;t.</blockquote><div><br></div><div>I&#39;m sure it&#39;= s possible, but it would need some pretty powerful global expression analys= is.</div><div>Ie, if data initialised in static this() is only touched in o= ne function lets say, and that function is never referenced, then it should= surely be able to safely eliminate that function and associated data?</div=

;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> Why wouldn&#39;t dead code be eliminated effectively already?<br> </blockquote></div> Cause 1 section is created for each module. So if you use just 1 function t= he whole module is pulled in.<br> </blockquote></div><br><div>Why would it pull the whole module if only one = function is used? And why can&#39;t a post-link strip process clean it up?<= /div> --00248c768f26ef66a404b61a5ed9--
Jan 09 2012
prev sibling parent "Trass3r" <un known.com> writes:
 I'm sure it's possible, but it would need some pretty powerful 
 global expression analysis.
 Ie, if data initialised in static this() is only touched in one 
 function
 lets say, and that function is never referenced, then it should 
 surely be
 able to safely eliminate that function and associated data?

You need LTO for that.
 Why would it pull the whole module if only one function is used?

 And why can't a post-link strip process clean it up?

Everything's already merged by then.
Jan 09 2012