www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: The proper case for D.

reply Frank Rundell <frru btinternet.com> writes:
superdan Wrote:

 Steve Teale Wrote:
 
 Can this group come up with a proper, sober (OK, I'm not)

den pretty please explain why anyone should give a flyin' fuck fer yer drunken rant.

And your response is why D is never going to be more than a beta compiler and interesting discussion piece between a small number of programmers. If it wants to compete with the 'big boys' it needs an IDE, a GUI library that can compile and work, a debugger that understands D, a proper linker, packaged releases for linux, an installer for Windows, etc. D2 is in danger of becoming a camel i.e. a horse designed by a committee... Frank.
Jun 20 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Frank Rundell wrote:

 superdan Wrote:
 
 Steve Teale Wrote:
 
 Can this group come up with a proper, sober (OK, I'm not)

den pretty please explain why anyone should give a flyin' fuck fer yer drunken rant.

And your response is why D is never going to be more than a beta compiler and interesting discussion piece between a small number of programmers. If it wants to compete with the 'big boys' it needs an IDE, a GUI library that can compile and work, a debugger that understands D, a proper linker, packaged releases for linux, an installer for Windows, etc. D2 is in danger of becoming a camel i.e. a horse designed by a committee... Frank.

? As far as I know, the 'committee' consists of a gang of three, with Walter firmly at the driving seat, all working very hard to flesh out a language, create an innovative library and quality compiler. All the tools and libraries you mention are being created. In addition there's also LDC which is shaping up nicely. Not to say everything is already here, but that is a question of time and manpower, not direction. What's up with all the negativity lately? Impatience?
Jun 20 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:

...
 What's up with all the negativity lately? Impatience?

Or is everybody drunk, am I missing a party?
Jun 20 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
 D2 is in danger of becoming a camel i.e. a horse designed by a
 committee...

 Frank.

? As far as I know, the 'committee' consists of a gang of three, with Walter firmly at the driving seat, all working very hard to flesh out a language, create an innovative library and quality compiler. All the tools and libraries you mention are being created. In addition there's also LDC which is shaping up nicely. Not to say everything is already here, but that is a question of time and manpower, not direction. What's up with all the negativity lately? Impatience?

Some people think D2 tries too much, and neglects the really important things at the same time. For example, D2 tries to solve the concurrency issue (which is a hot topic which makes D look good at sites like stackoverflow), while still relying on a 20 years old linker written in assembler.
Jun 20 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
grauzone wrote:

 D2 is in danger of becoming a camel i.e. a horse designed by a
 committee...

 Frank.

? As far as I know, the 'committee' consists of a gang of three, with Walter firmly at the driving seat, all working very hard to flesh out a language, create an innovative library and quality compiler. All the tools and libraries you mention are being created. In addition there's also LDC which is shaping up nicely. Not to say everything is already here, but that is a question of time and manpower, not direction. What's up with all the negativity lately? Impatience?

Some people think D2 tries too much, and neglects the really important things at the same time. For example, D2 tries to solve the concurrency issue (which is a hot topic which makes D look good at sites like stackoverflow), while still relying on a 20 years old linker written in assembler.

So the better direction according to some is to stagnate language design for D2 so Walter Bright can reinvent the linker? So that years later when asked why D didn't do more for concurrency when it was needed, you'd have to reply: "well there wasn't any time to deal with such trivial issues, the language designer had to work on the toolchain."
Jun 20 2009
next sibling parent reply grauzone <none example.net> writes:
 So the better direction according to some is to stagnate language design for 
 D2 so Walter Bright can reinvent the linker? So that years later when asked 

No, but to use a real linker instead of that piece of crap.
 why D didn't do more for concurrency when it was needed, you'd have to 
 reply: "well there wasn't any time to deal with such trivial issues, the 
 language designer had to work on the toolchain."

Eh, you seriously think D2 would still be in use at that time? We will have D325858 which broke backwards compatibility for the 325858th time. This issue (multithreading) seriously could wait a bit longer. The most hilarious thing is that multithreading support in Phobos was incredibly buggy, and even today, basic multithreading primitives like condition variables are lacking from Phobos. Oh yeah, we got builtin mutexes so that we can say "D supports multithreading on the language level". Funny.
Jun 20 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
grauzone wrote:
 So the better direction according to some is to stagnate language 
 design for D2 so Walter Bright can reinvent the linker? So that years 
 later when asked 

No, but to use a real linker instead of that piece of crap.

With objconv, it might be possible to use a different linker on Windows. I'm considering doing so since Optlink won't work with the debug build of one of my libraries (it's 22MB), and it doesn't seem to discard any unreferenced library symbols, so the release build of my code is ~9.5MB, while it should be ~4.
Jun 20 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 I'm considering doing so since Optlink won't work with the debug build 
 of one of my libraries (it's 22MB),

Is this reported in bugzilla?
 and it doesn't seem to discard any 
 unreferenced library symbols, so the release build of my code is ~9.5MB, 
 while it should be ~4.

Optlink does not discard unreference symbols, it just doesn't pull them in from the library. If it did always pull in everything from the library, then the minimum D executable size will be the size of Phobos. Since that isn't happening, something else is happening with your code. I bet that those unreferenced symbols *are* being referenced. You can determine this by using the librarian to remove those 'unreferenced' symbols from Phobos, and then link, and see if there are any unresolved symbol error messages.
Jun 20 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Sat, Jun 20, 2009 at 11:35 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Robert Fraser wrote:
 I'm considering doing so since Optlink won't work with the debug build of
 one of my libraries (it's 22MB),


http://d.puremagic.com/issues/show_bug.cgi?id=424 He's not the only one. Ask me, Tom S., eldar..

1. Robert doesn't say if that is the issue or not. 2. The last comment in the bug report is a request for a reproducible test case. I need one.
Jun 20 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Sun, Jun 21, 2009 at 1:27 AM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 2. The last comment in the bug report is a request for a reproducible test
 case. I need one.

I've just posted one.

Thank you.
Jun 21 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 Optlink does not discard unreference symbols, it just doesn't pull them 
 in from the library. If it did always pull in everything from the 
 library, then the minimum D executable size will be the size of Phobos.
 
 Since that isn't happening, something else is happening with your code. 
 I bet that those unreferenced symbols *are* being referenced. You can 
 determine this by using the librarian to remove those 'unreferenced' 
 symbols from Phobos, and then link, and see if there are any unresolved 
 symbol error messages.

Hmmm... well, I built a 3rd-party library (Platinum UPnP + Neptune) into two static libraries (with VS). I then wrote a C wrapper function around one, just to test out the functionality I needed (a fraction of what was available). Originally, I wanted to statically link it with my D project so I ran objconv on the libs (COFF -> OMF). I created a test D app that was basically just: extern(C) int cMain(); int main(char[][] args) { return cMain(); } ... And linked it to the OMF version of the library. Worked fine, but the result was ~12MB, which is about 200k larger than the two libraries. I'm now using VC++ to build it into a DLL that exposes the function. 802kb for a debug DLL, 280k for a release. The same thing is happening with my other library (ffmpeg -- libavcodec, libavformat, libavutil and swscale), which I built as static libraries with MinGW gcc and converted again with objconv. In this case, I'm too lazy to create a DLL to wrap only the functions I want, though I may end up doing just that once my project gets closer to usable.
Jun 21 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 Hmmm... well, I built a 3rd-party library (Platinum UPnP + Neptune) into 
 two static libraries (with VS). I then wrote a C wrapper function around 
 one, just to test out the functionality I needed (a fraction of what was 
 available). Originally, I wanted to statically link it with my D project 
 so I ran objconv on the libs (COFF -> OMF). I created a test D app that 
 was basically just:
 
 extern(C) int cMain();
 int main(char[][] args) { return cMain(); }
 
 ... And linked it to the OMF version of the library. Worked fine, but 
 the result was ~12MB, which is about 200k larger than the two libraries. 
 I'm now using VC++ to build it into a DLL that exposes the function. 
 802kb for a debug DLL, 280k for a release.
 
 The same thing is happening with my other library (ffmpeg -- libavcodec, 
 libavformat, libavutil and swscale), which I built as static libraries 
 with MinGW gcc and converted again with objconv. In this case, I'm too 
 lazy to create a DLL to wrap only the functions I want, though I may end 
 up doing just that once my project gets closer to usable.

It may be a problem with objconv where it puts everything into one obj file.
Jun 21 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 Robert Fraser wrote:
 Hmmm... well, I built a 3rd-party library (Platinum UPnP + Neptune) 
 into two static libraries (with VS). I then wrote a C wrapper function 
 around one, just to test out the functionality I needed (a fraction of 
 what was available). Originally, I wanted to statically link it with 
 my D project so I ran objconv on the libs (COFF -> OMF). I created a 
 test D app that was basically just:

 extern(C) int cMain();
 int main(char[][] args) { return cMain(); }

 ... And linked it to the OMF version of the library. Worked fine, but 
 the result was ~12MB, which is about 200k larger than the two 
 libraries. I'm now using VC++ to build it into a DLL that exposes the 
 function. 802kb for a debug DLL, 280k for a release.

 The same thing is happening with my other library (ffmpeg -- 
 libavcodec, libavformat, libavutil and swscale), which I built as 
 static libraries with MinGW gcc and converted again with objconv. In 
 this case, I'm too lazy to create a DLL to wrap only the functions I 
 want, though I may end up doing just that once my project gets closer 
 to usable.

It may be a problem with objconv where it puts everything into one obj file.

Update on this -- I built it as a DLL in VS, exposing only the functions I need. The DLL is just under 5MB in release mode, and it took my main program down to 823k. Your explanation sounds likely, however it seems VS is discriminating on the per-symbol level...? I'm going to need to make sure runtime CPU detection was still built in, though; VS may have been too smart for its own good.
Jun 21 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 Your explanation sounds likely, however it seems VS is discriminating on 
 the per-symbol level...?

Let's say the C++ source file looks like: ---------------------------- int foo() { ... } int bar() { ... } ---------------------------- it is compiled and put into a library. Your program references foo(). Pulling in the object module from the library that contains foo() also pulls in bar(), because bar() is in the same object module. If bar() references a bunch of other stuff, that gets pulled in, too. VS may contain some scheme to split a source file into multiple object modules which prevents this. Note that dmd will split a single source file into multiple object modules when you compile with -lib.
Jun 21 2009
parent reply robert fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:

 Robert Fraser wrote:
 Your explanation sounds likely, however it seems VS is discriminating on 
 the per-symbol level...?

Let's say the C++ source file looks like: ---------------------------- int foo() { ... } int bar() { ... } ---------------------------- it is compiled and put into a library. Your program references foo(). Pulling in the object module from the library that contains foo() also pulls in bar(), because bar() is in the same object module. If bar() references a bunch of other stuff, that gets pulled in, too. VS may contain some scheme to split a source file into multiple object modules which prevents this. Note that dmd will split a single source file into multiple object modules when you compile with -lib.

Ah, thanks for the explanation. I didn't understand it pulled in whole object files at once, though given that libraries are just archives of object files, I should have assumed.
Jun 21 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
robert fraser wrote:
 Ah, thanks for the explanation. I didn't understand it pulled in
 whole object files at once, though given that libraries are just
 archives of object files, I should have assumed.

The linker can eliminate some unused COMDATs from the object file, but in general this isn't very effective because most of the semantic information is gone. That's what makes the -lib switch so nifty, it does the splitting up with full knowledge of the semantic info, so it does a proper job of it.
Jun 21 2009
prev sibling parent BCS <none anon.com> writes:
Hello Robert,

 The same thing is happening with my other library (ffmpeg --
 libavcodec, libavformat, libavutil and swscale), which I built as
 static libraries with MinGW gcc and converted again with objconv. In
 this case, I'm too lazy to create a DLL to wrap only the functions I
 want, though I may end up doing just that once my project gets closer
 to usable.
 

what is needed is a reference graph tool and .exe inspector tool.
Jun 21 2009
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
grauzone wrote:

 So the better direction according to some is to stagnate language design
 for D2 so Walter Bright can reinvent the linker? So that years later when
 asked

No, but to use a real linker instead of that piece of crap.

And this real linker is going to magically appear from nowhere?
 why D didn't do more for concurrency when it was needed, you'd have to
 reply: "well there wasn't any time to deal with such trivial issues, the
 language designer had to work on the toolchain."

Eh, you seriously think D2 would still be in use at that time? We will have D325858 which broke backwards compatibility for the 325858th time. This issue (multithreading) seriously could wait a bit longer. The most hilarious thing is that multithreading support in Phobos was incredibly buggy, and even today, basic multithreading primitives like condition variables are lacking from Phobos. Oh yeah, we got builtin mutexes so that we can say "D supports multithreading on the language level". Funny.

D1 is stable and actively supported. Tango has the functionality. LDC has the linker and work is being done that other OS. Now, what is problem? Really I don't understand. But ok, if you don't think of multithreading to be a big deal and find existing solutions perfectly adequate, generic programming a niche functionality and functional programming overrated, then the whole D2 deal certainly looks like a wasted effort better spend on writing a linker.
Jun 20 2009
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
 What's up with all the negativity lately? Impatience?

Some people think D2 tries too much, and neglects the really important things at the same time. For example, D2 tries to solve the concurrency issue (which is a hot topic which makes D look good at sites like stackoverflow), while still relying on a 20 years old linker written in assembler.

So the better direction according to some is to stagnate language design for D2 so Walter Bright can reinvent the linker? So that years later when asked why D didn't do more for concurrency when it was needed, you'd have to reply: "well there wasn't any time to deal with such trivial issues, the language designer had to work on the toolchain."

can you do a new linker? I can't. There must be someone out there who can - please, please.
Jun 21 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Steve Teale wrote:
 What's up with all the negativity lately? Impatience?




 things at the same time. For example, D2 tries to solve the concurren=



 issue (which is a hot topic which makes D look good at sites like
 stackoverflow), while still relying on a 20 years old linker written =



 assembler.



 D2 so Walter Bright can reinvent the linker? So that years later when =


 why D didn't do more for concurrency when it was needed, you'd have to=


 reply: "well there wasn't any time to deal with such trivial issues, t=


 language designer had to work on the toolchain."

can you do a new linker? I can't. There must be someone out there who c=

=20
=20

Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jun 21 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from grauzone (none example.net)'s article
 D2 is in danger of becoming a camel i.e. a horse designed by a
 committee...

 Frank.

? As far as I know, the 'committee' consists of a gang of three, with Walter firmly at the driving seat, all working very hard to flesh out a language, create an innovative library and quality compiler. All the tools and libraries you mention are being created. In addition there's also LDC which is shaping up nicely. Not to say everything is already here, but that is a question of time and manpower, not direction. What's up with all the negativity lately? Impatience?

things at the same time. For example, D2 tries to solve the concurrency issue (which is a hot topic which makes D look good at sites like stackoverflow), while still relying on a 20 years old linker written in assembler.

But linkers are an implementation detail, threading is really central to what you'd call "the language". To me the most important thing for Walter is to get a stable, well-thought out spec and a "good enough" reference/proof of concept implementation of that spec out the door. This means implementing all features that are going to be implemented and fixing real showstopper bugs that severely affect the usability of these features ASAP. For most people, while having a less than ideal toolchain is annoying, having a moving target is completely useless. Furthermore, if D didn't bother with new features and was just a slightly better C++/Java, the switching costs wouldn't be justified. Another thing to take into account is that mistakes in the spec (and to some extent the reference implementation is a de facto spec) are a lot more permanent than bad toolchain implementaitons. Creating a real top-of-the-line toolchain is something that can be done after the spec is finalized and the features implemented without breaking anything. This includes improving the linker, fixing bugs that don't fundamentally affect the usability of language features, improving performance, etc. It is also something that can be (and is being) done by the community, i.e. people other than Walter.
Jun 20 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Jun 20, 2009 at 11:35 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Robert Fraser wrote:
 I'm considering doing so since Optlink won't work with the debug build of
 one of my libraries (it's 22MB),

Is this reported in bugzilla?

http://d.puremagic.com/issues/show_bug.cgi?id=424 He's not the only one. Ask me, Tom S., eldar..
Jun 20 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Jun 21, 2009 at 1:27 AM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 On Sat, Jun 20, 2009 at 11:35 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Robert Fraser wrote:
 I'm considering doing so since Optlink won't work with the debug build
 of
 one of my libraries (it's 22MB),

Is this reported in bugzilla?

http://d.puremagic.com/issues/show_bug.cgi?id=3D424 He's not the only one. =A0Ask me, Tom S., eldar..

1. Robert doesn't say if that is the issue or not.

Fair enough, though I'm just speaking from experience here. Large objects =3D lots of fixups =3D dead OPTLINK.
 2. The last comment in the bug report is a request for a reproducible tes=

 case. I need one.

I've just posted one.
Jun 20 2009