www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The proper case for D.

reply Steve Teale <steve.teale britseyeview.com> writes:
Can this group come up with a proper, sober (OK, I'm not), case for D.

This would clearly have to steer clear of the standard libraries, I can't see
how any outside observer is going to be impressed by the fact that we have two.

And D is a computer programming language. So we should deal with it as that
first.

Andrei's article had a lot of good points primarily revolving around the need
to concentrate on concurrency, but I suspect that we should probably stress the
basics.

When Bjarne Stroustrup was originally promoting C++, he made a strong point
that you could at least consider it to be a 'better C'. This point, it seemed
to me, was lost on many. Now we are looking for radical arguments as to why D
is a cool language. Maybe we should remember the basics, and concentrate less
on the vapor.

Bearophile made a counter-argument. But this also did not stress our basic
weaknesses. Most of us are using DMD, which on Windows uses a 20 year old
linker, and utilizes an antique object file format. Under Linux, it can't
produce the position-independent code that's required to create reliable shared
libraries.

Unless you use alpha-level code, you can't load arbitrary D modules at run-time.

There isn't a decent debugger for either Windows or Linux. There may never be
one if the potential authors see the constant focus on meta-programming - that
must make life hell for them.

I'm not advocating a return to D1, but I do want to see closure on D2, and an
ascent from the constant alpha state. Then after that, I'd like to see a more
formal system of RFCs for library proposals, and a recognized pattern for
voting on them so that anyone who kept up-to-date with the process would not be
surprised by what suddenly appeared in Phobos, or perhaps it should be the D
Standard Library (DSL).

When all that had happened I could forget computer programming and get on with
my woodwork relatively secure in the knowledge that I had chosen to support a
winner, and the Walter's efforts were not in vain.
Jun 19 2009
next sibling parent reply superdan <super dan.org> writes:
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.
Jun 19 2009
next sibling parent reply grauzone <none example.net> 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.


You just gave a flying fuck.
Jun 19 2009
parent superdan <super dan.org> writes:
grauzone 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.


 
 You just gave a flying fuck.


negative. i stopped readin' after da first line. dat counts at most for a
crawlin' fuck.
Jun 19 2009
prev sibling parent reply Steve Teale <steve.teale britseyeview.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.


Love you man. You're on the spot! I have no excuse.
Jun 21 2009
parent reply superdan <super dan.org> writes:
Steve Teale 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.


 
 Love you man. You're on the spot! I have no excuse.


not shure u r bein' sarcastic but i'm a gonna take dat at face value. akshully
steve u got an excuse. u and i r part of a larger social phenom. i saw many
times in da group: sum'thin' good happens with d. then da group reacts
negatively with da speed o' light. its like physix: ackshon and reackshon.

walt adds features. den we bitch fuck them features, he has 3000 bugs up his
ass. walt fixes bugs. den we bitch that not'n' new is cummin' down da pike.
andre asks about ranges. we get motherfuckin' bikeshed fight. andre implements
them ranges. we bitch about namez syntax and all shit up to the motherfuckin'
wazoo. of course if we dun understand ranges dats his fault too.

been busy   work past week but saw good things. andreis book is on amazon so
ppl know it's cummin'. then da case fer d comes out. loved it. even better
reddit loves it. momentum iz there.

den wat do we do. bearophile writes other side of the coin. what in the name of
fuck is his problem. backstabbin' mo'fucker are da nicest words that cum 2 mind
after racking 'n' waterboarding my brain. EXIT_SUCCESS up yer ass. den cums da
proper case fer d. only good thing is sean's cumback o' da year. thanx sean.
den cherry on da cake. finally grauzone. where therez any negative shit about d
u bet grauzone is on it like flies on shit. so we get this piece of brain
vomit. leave them threadz alone. focus all on rewritin' da windows linker. what
an assfucked strategy dat iz. i bet soon ppl will say yeah d is a shitty
language but hey it got a great linker. what da fuck.

anyway steve. my point is we r part of some weird twilite zone. if d ever
becumz successful theres gonna be murder in dis group.
Jun 21 2009
parent reply Pete O'dowd <respw1008 romulus.co.uk> writes:
superdan Wrote:


 Steve Teale 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.


 
 Love you man. You're on the spot! I have no excuse.


 
 not shure u r bein' sarcastic but i'm a gonna take dat at face value. akshully
steve u got an excuse. u and i r part of a larger social phenom. i saw many
times in da group: sum'thin' good happens with d. then da group reacts
negatively with da speed o' light. its like physix: ackshon and reackshon.
 
 walt adds features. den we bitch fuck them features, he has 3000 bugs up his
ass. walt fixes bugs. den we bitch that not'n' new is cummin' down da pike.
andre asks about ranges. we get motherfuckin' bikeshed fight. andre implements
them ranges. we bitch about namez syntax and all shit up to the motherfuckin'
wazoo. of course if we dun understand ranges dats his fault too.
 
 been busy   work past week but saw good things. andreis book is on amazon so
ppl know it's cummin'. then da case fer d comes out. loved it. even better
reddit loves it. momentum iz there.
 
 den wat do we do. bearophile writes other side of the coin. what in the name
of fuck is his problem. backstabbin' mo'fucker are da nicest words that cum 2
mind after racking 'n' waterboarding my brain. EXIT_SUCCESS up yer ass. den
cums da proper case fer d. only good thing is sean's cumback o' da year. thanx
sean. den cherry on da cake. finally grauzone. where therez any negative shit
about d u bet grauzone is on it like flies on shit. so we get this piece of
brain vomit. leave them threadz alone. focus all on rewritin' da windows
linker. what an assfucked strategy dat iz. i bet soon ppl will say yeah d is a
shitty language but hey it got a great linker. what da fuck.
 
 anyway steve. my point is we r part of some weird twilite zone. if d ever
becumz successful theres gonna be murder in dis group.


Wow - Boyz n da Hood... Are you writing with a full keyboard?

P.O.
Jun 21 2009
parent superdan <super dan.org> writes:
Pete Odowd Wrote:


 superdan Wrote:
 

 Steve Teale 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.


 
 Love you man. You're on the spot! I have no excuse.


 
 not shure u r bein' sarcastic but i'm a gonna take dat at face value. akshully
steve u got an excuse. u and i r part of a larger social phenom. i saw many
times in da group: sum'thin' good happens with d. then da group reacts
negatively with da speed o' light. its like physix: ackshon and reackshon.
 
 walt adds features. den we bitch fuck them features, he has 3000 bugs up his
ass. walt fixes bugs. den we bitch that not'n' new is cummin' down da pike.
andre asks about ranges. we get motherfuckin' bikeshed fight. andre implements
them ranges. we bitch about namez syntax and all shit up to the motherfuckin'
wazoo. of course if we dun understand ranges dats his fault too.
 
 been busy   work past week but saw good things. andreis book is on amazon so
ppl know it's cummin'. then da case fer d comes out. loved it. even better
reddit loves it. momentum iz there.
 
 den wat do we do. bearophile writes other side of the coin. what in the name
of fuck is his problem. backstabbin' mo'fucker are da nicest words that cum 2
mind after racking 'n' waterboarding my brain. EXIT_SUCCESS up yer ass. den
cums da proper case fer d. only good thing is sean's cumback o' da year. thanx
sean. den cherry on da cake. finally grauzone. where therez any negative shit
about d u bet grauzone is on it like flies on shit. so we get this piece of
brain vomit. leave them threadz alone. focus all on rewritin' da windows
linker. what an assfucked strategy dat iz. i bet soon ppl will say yeah d is a
shitty language but hey it got a great linker. what da fuck.
 
 anyway steve. my point is we r part of some weird twilite zone. if d ever
becumz successful theres gonna be murder in dis group.


 
 Wow - Boyz n da Hood... Are you writing with a full keyboard?
 
 P.O.


menace ii society akshully. heh.
Jun 22 2009
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Fri, Jun 19, 2009 at 03:00:17PM -0400, Steve Teale wrote:

 Can this group come up with a proper, sober (OK, I'm not), case for D.


It is a better C; D is what C++ wishes it was.

My biggest love of D is two words: nested functions. I tend to write it
as if it was just C with the suck yanked out.

D2 is a better D1; you can write it in a similar way, but get even more
help from the compiler to catch errors.

D is the safe AND convenient language.


 There isn't a decent debugger for either Windows or Linux. 


I find gdb works well enough for me on linux. I use the -gc "pretend to
be C" option. But I rarely really need the debugger, thanks to the compiler.

-- 
Adam D. Ruppe
http://arsdnet.net
Jun 19 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Adam D. Ruppe Wrote:


 On Fri, Jun 19, 2009 at 03:00:17PM -0400, Steve Teale wrote:

 Can this group come up with a proper, sober (OK, I'm not), case for D.


 
 It is a better C; D is what C++ wishes it was.
 
 My biggest love of D is two words: nested functions. I tend to write it
 as if it was just C with the suck yanked out.
 
 D2 is a better D1; you can write it in a similar way, but get even more
 help from the compiler to catch errors.
 
 D is the safe AND convenient language.
 

 There isn't a decent debugger for either Windows or Linux. 


 
 I find gdb works well enough for me on linux. I use the -gc "pretend to
 be C" option. But I rarely really need the debugger, thanks to the compiler.
 
 -- 
 Adam D. Ruppe
 http://arsdnet.net


Yes, you're right about not needing a debugger. Walter's compilers have always
given you a good idea of where you should look. But there are lots of potential
users who do not know how to debug without an IDE debugger. After all, the
seat-of-the-pants way is quite hard work.
Jun 21 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Steve,


 When Bjarne Stroustrup was originally promoting C++, he made a strong
 point that you could at least consider it to be a 'better C'. This
 point, it seemed to me, was lost on many. Now we are looking for
 radical arguments as to why D is a cool language. Maybe we should
 remember the basics, and concentrate less on the vapor.


"D is a low level language that can masquerade as a high level language" 
It has the low level stuff but if you just choose not to use them it looks 
and to a great extent acts like a high level one.


 Bearophile made a counter-argument. But this also did not stress our
 basic weaknesses. Most of us are using DMD, which on Windows uses a 20
 year old linker, and utilizes an antique object file format.


DMD now has 3 (or is it 4) different object file outputters. it shouldn't 
be hard from somone who knows somthing about a better format to be able to 
figure out how to patch one in and send Walter a patch.


 or perhaps it should be the D Standard Library (DSL).


No, DSL is already used. DSR? D standard runtime?
Jun 19 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Uppercase.  Calling it 'd' lacks a certain punch.
Jun 19 2009
next sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Fri, 19 Jun 2009 22:53:54 +0200 schreef Sean Kelly  
<sean invisibleduck.org>:


 Uppercase.


Thats awesome, made me chuckle. :-)



  Calling it 'd' lacks a certain punch.
Jun 19 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Jun 19, 2009 at 4:53 PM, Sean Kelly<sean invisibleduck.org> wrote:

 Uppercase. =A0Calling it 'd' lacks a certain punch.


"The groan heard 'round the world"
Jun 19 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Sean Kelly wrote:

 Uppercase.  Calling it 'd' lacks a certain punch.


You know, that's exactly what I assumed the post was going to be about
when I saw the title...

:D
Jun 20 2009
prev sibling next sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
Many will argue that D has lots of features found in many other 
languages but I think that it was born from and is still chosen for need 
for the need to run high performance code on the bare metal without 
using C++ so try this:

1. Find code written in C++.
2. Attempt to re write it as D.

This 2 step should expose the cases not to use D.
Jun 19 2009
prev sibling next sibling parent hasen <hasan.aljudy gmail.com> writes:
Steve Teale wrote:

 Can this group come up with a proper, sober (OK, I'm not), case for D.
 
 This would clearly have to steer clear of the standard libraries, I can't see
how any outside observer is going to be impressed by the fact that we have two.
 
 And D is a computer programming language. So we should deal with it as that
first.
 
 Andrei's article had a lot of good points primarily revolving around the need
to concentrate on concurrency, but I suspect that we should probably stress the
basics.
 
 When Bjarne Stroustrup was originally promoting C++, he made a strong point
that you could at least consider it to be a 'better C'. This point, it seemed
to me, was lost on many. Now we are looking for radical arguments as to why D
is a cool language. Maybe we should remember the basics, and concentrate less
on the vapor.
 
 Bearophile made a counter-argument. But this also did not stress our basic
weaknesses. Most of us are using DMD, which on Windows uses a 20 year old
linker, and utilizes an antique object file format. Under Linux, it can't
produce the position-independent code that's required to create reliable shared
libraries.
 
 Unless you use alpha-level code, you can't load arbitrary D modules at
run-time.
 
 There isn't a decent debugger for either Windows or Linux. There may never be
one if the potential authors see the constant focus on meta-programming - that
must make life hell for them.
 
 I'm not advocating a return to D1, but I do want to see closure on D2, and an
ascent from the constant alpha state. Then after that, I'd like to see a more
formal system of RFCs for library proposals, and a recognized pattern for
voting on them so that anyone who kept up-to-date with the process would not be
surprised by what suddenly appeared in Phobos, or perhaps it should be the D
Standard Library (DSL).
 
 When all that had happened I could forget computer programming and get on with
my woodwork relatively secure in the knowledge that I had chosen to support a
winner, and the Walter's efforts were not in vain.
 
 


I think the proper case for D has to be in the form of (several) 
real-world applications/system-utilities that people outside this 
newsgroup will *want* to use, not because they're written in D, but 
because these programs actually do something useful that a lot of people 
would really want.

Games are certainly a good use case for D, but developing a good game 
takes a long time and in the end it won't compete with any of the 
available commercial games.

There are (surprisingly) many small utilities that do something very 
simple, yet they're very useful and are used by a lots of people,

Just to name a few ...

- Launchy
- safarp (simple and fast add/remove programs)
- Sumatra PDF viewer
- WinDjView
- Fotografix (extremely tiny image editor, 
http://lmadhavan.com/software/fotografix/ )
- Rapid Environment Editor
- WinDirStat
- Unlocker

These are very useful "system" (kinda?) utilities ,IMO there's lots of 
room for programs in this category to be written in D, either programs 
that are not written yet, or written but have sub-optimal performance. 
(for instance, launchy can be slow sometimes).

Of course, the end users of such utilities might not care much about 
what language they're written in; but that's exactly the point.
Jun 20 2009
prev sibling next sibling parent 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 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 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
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),


 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..


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 reply 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=


t

 case. I need one.


I've just posted 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."
 


You are of course completely correct in this, but the question is,
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:
Steve Teale wrote:

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


 Some people think D2 tries too much, and neglects the really importan=






t

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






cy

 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 desi=




gn for=20

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




asked=20

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




=20

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




he=20

 language designer had to work on the toolchain."


 You are of course completely correct in this, but the question is,
 can you do a new linker? I can't. There must be someone out there who c=


an - please, please.

=20
=20


http://www.gnu.org/software/binutils/ ?

		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?


 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.


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 Bruno Deligny <bruno.deligny gmail.com> writes:
Steve Teale a écrit :

 Can this group come up with a proper, sober (OK, I'm not), case for D.
 
 This would clearly have to steer clear of the standard libraries, I can't see
how any outside observer is going to be impressed by the fact that we have two.
 
 And D is a computer programming language. So we should deal with it as that
first.
 
 Andrei's article had a lot of good points primarily revolving around the need
to concentrate on concurrency, but I suspect that we should probably stress the
basics.
 
 When Bjarne Stroustrup was originally promoting C++, he made a strong point
that you could at least consider it to be a 'better C'. This point, it seemed
to me, was lost on many. Now we are looking for radical arguments as to why D
is a cool language. Maybe we should remember the basics, and concentrate less
on the vapor.
 
 Bearophile made a counter-argument. But this also did not stress our basic
weaknesses. Most of us are using DMD, which on Windows uses a 20 year old
linker, and utilizes an antique object file format. Under Linux, it can't
produce the position-independent code that's required to create reliable shared
libraries.
 
 Unless you use alpha-level code, you can't load arbitrary D modules at
run-time.
 
 There isn't a decent debugger for either Windows or Linux. There may never be
one if the potential authors see the constant focus on meta-programming - that
must make life hell for them.
 
 I'm not advocating a return to D1, but I do want to see closure on D2, and an
ascent from the constant alpha state. Then after that, I'd like to see a more
formal system of RFCs for library proposals, and a recognized pattern for
voting on them so that anyone who kept up-to-date with the process would not be
surprised by what suddenly appeared in Phobos, or perhaps it should be the D
Standard Library (DSL).
 
 When all that had happened I could forget computer programming and get on with
my woodwork relatively secure in the knowledge that I had chosen to support a
winner, and the Walter's efforts were not in vain.
 
 


I totally agree!
Everybody i know that tried D have the same problems, so they all stick 
with C++.

The D language is amazing but the tools are awful. There is tools but 
nothing works together out of the box! The user experience of D is very bad!


formats, IDE, debugger...) and all that with one click installers for 
all platforms. We don't need to reinvent the wheel, just create a 
synergy between projects!

Walter, if you don't want to be the production manager that will put all 
theses pieces together, you should stick to the language development and 
hire somebody to handle the development environment!
Jun 20 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 Most of us are using DMD, which on Windows uses a
 20 year old linker, and utilizes an antique object file format.


Knowing the guts of object file formats, the MachO format (used on the 
Mac) is by far the worst of the three (OMF, MachO, ELF).


 Under
 Linux, it can't produce the position-independent code that's required
 to create reliable shared libraries.


Use the -fPIC switch, which has been there for years.
Jun 20 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Walter Bright Wrote:


 Steve Teale wrote:

 Most of us are using DMD, which on Windows uses a
 20 year old linker, and utilizes an antique object file format.


 
 Knowing the guts of object file formats, the MachO format (used on the 
 Mac) is by far the worst of the three (OMF, MachO, ELF).
 

 Under
 Linux, it can't produce the position-independent code that's required
 to create reliable shared libraries.


 
 Use the -fPIC switch, which has been there for years.


OK Walter, I'd have to go back again and cover that, but at the time I had
problems.

Steve
Jun 21 2009