March 02, 2012
On 2012-03-02 08:47, Marco Leise wrote:
> Am 01.03.2012, 21:26 Uhr, schrieb Jacob Carlborg <doob@me.com>:
>
>> On 2012-03-01 15:40, Marco Leise wrote:
>>> Since everyone loves polls, and the question comes up now and then: What
>>> is your main development platform for D ?
>>>
>>> http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494
>>
>> Why bundle Linux and FreeBSD in one option?
>
> I considered the two 'similar enough' from a point of view of
> architecture and organization to merge them (aka Unix-like). I admit,
> that I never used FreeBSD though.
> Anyway the numbers nicely show, that neither Windows nor
> Linux(-compatible) are underrepresented in the D community. My personal
> opinion is that the number of Windows users is actually low, considering
> its market share and other surveys like this:
> http://redmonk.com/sogrady/2010/10/27/developer-os-preferences/

It depends on how you see it. Both FreeBSD and Mac OS X are built on a BSD foundation but Linux is not. On the other hand FreeBSD and Linux uses ELF binaries but Mac OS X use Mach-O.

-- 
/Jacob Carlborg
March 02, 2012
On Thu, 01 Mar 2012 15:40:38 +0100, Marco Leise <Marco.Leise@gmx.de> wrote:

> Since everyone loves polls, and the question comes up now and then: What is your main development platform for D ?
>
> http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494

Where's Emacs?
March 02, 2012
On 2 March 2012 11:09, Brad Roberts <braddr@puremagic.com> wrote:

> On 3/2/2012 12:25 AM, Manu wrote:
> > But we knew that already, because most of the D devs are linux guys, and
> D does not present a good experience to Windows
> > users. I can personally point to numerous friends/colleagues who tried
> out D and turned away within a few hours because
> > the Windows experience was so weak.
> > Windows support should be prioritized BECAUSE Windows numbers are low,
> not because there's perceived to be no demand on
> > that platform.
>
> I'm fairly your assertion is incorrect, if by "d devs" you mean the guys
> that are building dmd/druntime/phobos.  I think
> we actually have more contributors that are windows based than linux
> based.  At a minimum the numbers are well balanced,
> not wildly lopsided towards linux.
>
> No one has ever claimed that there's no demand for windows support.
>  What's been asserted is that it's easier to support
> linux/bsd/osx.  And indeed that was backed up by how much time was spent
> on the platform specific parts vs the generic
> parts while implementing 64 bit support.  Windows will get 64 bit support
> at some point.  That's not even a question.
> What is a question is when, and there isn't a good answer for that right
> now.
>
> There's a clear need to focus/prioritize limited resources.  It's not a
> hard choice to decide to defer spending many
> months working on win64 and other platform specific support issues when
> there's still language level issues that cross
> every platform.  That said, as always, if someone wants to scratch that
> itch and contribute to improving the windows
> specific parts, help will be welcomed with open arms and lots of
> encouragement.
>

I wonder what the loss in potential contributors adds up to from those that
turn away on account of incomplete windows support?
Is it possible that loss of potential manpower is significant enough to
justify the time spent?

Also, does it represent a loss to D in terms of marketing? Some genuinely interested parties who turn away because they couldn't begin working with the language effectively may then relay that negative experience to other potential developers (I've witnessed this, and had to argue myself that D is not actually shit, it's just an unfinished implementation).

Personally, I just want to be able to link like a normal windows developer.
My code is C/C++, built with VC, and I want to link my D app against those
libs using the VC linker, and debug with Visual Studio. This is the
workflow I think the vast majority of Windows devs will expect, and it
sounds simple enough. This is the only thing standing between me using D
for any major projects, and just experimenting with the language for
evaluation, or just academic interest.
64bit is far less important to me personally, VisualC linker compatibility
is the big one. I just want to link against my C code without jumping
through lots of hoops.


March 02, 2012
On Fri, Mar 02, 2012 at 11:37:26AM +0100, Martin Nowak wrote:
> On Thu, 01 Mar 2012 15:40:38 +0100, Marco Leise <Marco.Leise@gmx.de> wrote:
> 
> >Since everyone loves polls, and the question comes up now and then: What is your main development platform for D ?
> >
> >http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494
> 
> Where's Emacs?

I thought EmacsOS died off in the last ice age? Do you mean to tell me it has living descendants today?!

;-)


T

-- 
He who laughs last thinks slowest.
March 02, 2012
On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
> Personally, I just want to be able to link like a normal windows developer.
> My code is C/C++, built with VC, and I want to link my D app against those
> libs using the VC linker, and debug with Visual Studio. This is the
> workflow I think the vast majority of Windows devs will expect, and it
> sounds simple enough. This is the only thing standing between me using D
> for any major projects, and just experimenting with the language for
> evaluation, or just academic interest.
> 64bit is far less important to me personally, VisualC linker compatibility
> is the big one. I just want to link against my C code without jumping
> through lots of hoops.

No one thinks that's a bad idea. The trouble is the amount of developers that actually understand the backend enough to implement another object format (which is what's needed to support the VisualC linker) is very small.

What's needed is someone to take the time to learn it then do it. Someone motivated, and smart. Not unlike yourself! :P

March 03, 2012
On 2 March 2012 23:16, Bernard Helyer <b.helyer@gmail.com> wrote:

> On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
>
>> Personally, I just want to be able to link like a normal windows
>> developer.
>> My code is C/C++, built with VC, and I want to link my D app against those
>> libs using the VC linker, and debug with Visual Studio. This is the
>> workflow I think the vast majority of Windows devs will expect, and it
>> sounds simple enough. This is the only thing standing between me using D
>> for any major projects, and just experimenting with the language for
>> evaluation, or just academic interest.
>> 64bit is far less important to me personally, VisualC linker compatibility
>> is the big one. I just want to link against my C code without jumping
>> through lots of hoops.
>>
>
> No one thinks that's a bad idea. The trouble is the amount of developers that actually understand the backend enough to implement another object format (which is what's needed to support the VisualC linker) is very small.
>
> What's needed is someone to take the time to learn it then do it. Someone motivated, and smart. Not unlike yourself! :P
>

Haha, ohhh, I see what you did there.
Well played...


March 03, 2012
"Bernard Helyer" <b.helyer@gmail.com> wrote in message news:nlzougvwvlvnmjbufwgi@forum.dlang.org...
>
> No one thinks that's a bad idea. The trouble is the amount of developers that actually understand the backend enough to implement another object format (which is what's needed to support the VisualC linker) is very small.
>
> What's needed is someone to take the time to learn it then do it. Someone motivated, and smart. Not unlike yourself! :P
>

The problem isn't really the backend - there are currently _three_ full object file generators in dmd and it should be possible to use the same interfaces these do without caring what most of the backend is really doing.

Generating Microsoft coff objects means deciphering the spec to see what everything should look like, generating every kind of entry with msvc to see what it _actually_ does, then translating all the record/fixup/section types from omf to the coff equivalents.  With this (and maybe updates to the runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on windows.

To get from there to 64bit, you need the following:
- 64 bit coff (I think these are closely related)
- 64 bit c runtime (just use microsofts?)
- 64 bit d runtime (eh, io with a different runtime, etc)
- 64 bit codegen (hopefully not much more than some calling convention
stuff)
- 64 bit linker (Again, just use ms?)

Just generating coff is a pretty big step, it requires learning how object formats work (I don't think many people already have the depth of understanding required), how coff works and how dmd generates object files (which probably means understanding omf/elf/mach).

The only person I can think of who would even know how long it would take to learn all this is Walter, and considering that he's hasn't done it already, I'd guess it's quite a huge task.

Walter, how big is it really?  Small enough to be done as, say, a gsoc project?  Would you be interested in mentoring such a project?


March 03, 2012

On 3/3/2012 12:44 PM, Daniel Murphy wrote:
> "Bernard Helyer"<b.helyer@gmail.com>  wrote in message
> news:nlzougvwvlvnmjbufwgi@forum.dlang.org...
>>
>> No one thinks that's a bad idea. The trouble is the amount of developers
>> that actually understand the backend enough to implement another object
>> format (which is what's needed to support the VisualC linker) is very
>> small.
>>
>> What's needed is someone to take the time to learn it then do it. Someone
>> motivated, and smart. Not unlike yourself! :P
>>
>
> The problem isn't really the backend - there are currently _three_ full
> object file generators in dmd and it should be possible to use the same
> interfaces these do without caring what most of the backend is really doing.
>

A good step forward would be a better separation of the object file format from the target OS and the host OS. Removing that preprocessor hell is needed anyway if you want to switch between object file formats by a command line switch.
In addition, it would be pretty nice if you could at least compile with predefined version OSX, even if you are working on Windows.

> Generating Microsoft coff objects means deciphering the spec to see what
> everything should look like, generating every kind of entry with msvc to see
> what it _actually_ does, then translating all the record/fixup/section types
> from omf to the coff equivalents.  With this (and maybe updates to the
> runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on
> windows.

Don't forget debug info: as far as I can tell, the Microsoft linker accepts codeview debug info in the object file, you don't have to write pdb files. From my experience with cv2pdb, the debug records are a straight forward extension of the debug info currently written by dmd.
March 03, 2012
"Rainer Schuetze" <r.sagitario@gmx.de> wrote in message news:jit3hk$tgb$1@digitalmars.com...
>
> A good step forward would be a better separation of the object file format
> from the target OS and the host OS. Removing that preprocessor hell is
> needed anyway if you want to switch between object file formats by a
> command line switch.
> In addition, it would be pretty nice if you could at least compile with
> predefined version OSX, even if you are working on Windows.
>

Yeah, this would be nice.

>> Generating Microsoft coff objects means deciphering the spec to see what
>> everything should look like, generating every kind of entry with msvc to
>> see
>> what it _actually_ does, then translating all the record/fixup/section
>> types
>> from omf to the coff equivalents.  With this (and maybe updates to the
>> runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on
>> windows.
>
> Don't forget debug info: as far as I can tell, the Microsoft linker accepts codeview debug info in the object file, you don't have to write pdb files. From my experience with cv2pdb, the debug records are a straight forward extension of the debug info currently written by dmd.

(I did forget it) But that's great!  Not having to add a new debug info format can only be a good thing.


March 07, 2012
On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
> Personally, I just want to be able to link like a normal windows developer.
> My code is C/C++, built with VC, and I want to link my D app against those
> libs using the VC linker, and debug with Visual Studio. This is the
> workflow I think the vast majority of Windows devs will expect, and it
> sounds simple enough. This is the only thing standing between me using D
> for any major projects, and just experimenting with the language for
> evaluation, or just academic interest.
> 64bit is far less important to me personally, VisualC linker compatibility
> is the big one. I just want to link against my C code without jumping
> through lots of hoops.

That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently.

I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users.