www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Setting up dmd properly

reply Jason Jeffory <JasonJeffory doodle.com> writes:
Dmd's setup construction is a bit weird and has some difficult 
issue tracking.

How about if dmd supported, if it already doesn't, some ways to 
help the user check the configuration of dmd. It would be quick 
and easy to implement.

e.g.,

dmd -showinfo

Target Arch: x86
Libraries: C:\Mylib;C:\Another\Lib\Somewhere
Modules: C:\MyModules;
Version: 2.062
etc...

This way, issues between 64 and 32 paths can easily be seen... 
figuring out exactly what sc.ini is doing is easier, etc...

We know it is accurate because it would come from the compiler 
itself. No guessing.

Probably a dmd app could be created that does this instead? 
Basically I've ran into issues before setting up D because of 
path issues(again, the sc.ini file is pretty crappy... littered 
with duplicate symbols and different paths with "hacks" for 
different compilers and all that(it's just not sain)). It tends 
to make me hesitant dealing with dmd in some cases. Something 
that should take a min to do can take hours trying to track down 
some weird issue simply because of a typo... and there's no way 
to know exactly what the compiler is "seeing"... I really hope 
something like this already exists.
Jan 10 2016
next sibling parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 01:22:28 UTC, Jason Jeffory wrote:
 Dmd's setup construction is a bit weird and has some difficult 
 issue tracking.

 How about if dmd supported, if it already doesn't, some ways to 
 help the user check the configuration of dmd. It would be quick 
 and easy to implement.

 e.g.,

 dmd -showinfo

 Target Arch: x86
 Libraries: C:\Mylib;C:\Another\Lib\Somewhere
 Modules: C:\MyModules;
 Version: 2.062
 etc...

 This way, issues between 64 and 32 paths can easily be seen... 
 figuring out exactly what sc.ini is doing is easier, etc...

 We know it is accurate because it would come from the compiler 
 itself. No guessing.

 Probably a dmd app could be created that does this instead? 
 Basically I've ran into issues before setting up D because of 
 path issues(again, the sc.ini file is pretty crappy... littered 
 with duplicate symbols and different paths with "hacks" for 
 different compilers and all that(it's just not sain)). It tends 
 to make me hesitant dealing with dmd in some cases. Something 
 that should take a min to do can take hours trying to track 
 down some weird issue simply because of a typo... and there's 
 no way to know exactly what the compiler is "seeing"... I 
 really hope something like this already exists.
Also, any linked in libraries could report there format and such. I've had problems figuring out certain coeff libs issues and all that. Knowing exactly what's going on is a good thing, right?!?!?
Jan 10 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 01:24:44 UTC, Jason Jeffory wrote:
 On Monday, 11 January 2016 at 01:22:28 UTC, Jason Jeffory wrote:
 Dmd's setup construction is a bit weird and has some difficult 
 issue tracking.

 How about if dmd supported, if it already doesn't, some ways 
 to help the user check the configuration of dmd. It would be 
 quick and easy to implement.

 e.g.,

 dmd -showinfo

 Target Arch: x86
 Libraries: C:\Mylib;C:\Another\Lib\Somewhere
 Modules: C:\MyModules;
 Version: 2.062
 etc...

 This way, issues between 64 and 32 paths can easily be seen... 
 figuring out exactly what sc.ini is doing is easier, etc...

 We know it is accurate because it would come from the compiler 
 itself. No guessing.

 Probably a dmd app could be created that does this instead? 
 Basically I've ran into issues before setting up D because of 
 path issues(again, the sc.ini file is pretty crappy... 
 littered with duplicate symbols and different paths with 
 "hacks" for different compilers and all that(it's just not 
 sain)). It tends to make me hesitant dealing with dmd in some 
 cases. Something that should take a min to do can take hours 
 trying to track down some weird issue simply because of a 
 typo... and there's no way to know exactly what the compiler 
 is "seeing"... I really hope something like this already 
 exists.
Also, any linked in libraries could report there format and such. I've had problems figuring out certain coeff libs issues and all that. Knowing exactly what's going on is a good thing, right?!?!?
and how does one link in compiled static libraries into a dub project? I tried adding stuff like "lflags" : ["+C:\\MyLibs\\"], with the .lib file in it, but that doesn't work. (I'd expect to have to supply the file name somewhere, at least) Thanks.
Jan 10 2016
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2016-01-11 01:47:54 +0000, Jason Jeffory said:

 and how does one link in compiled static libraries into a dub project?
 
 I tried adding stuff like
 
 "lflags" : ["+C:\\MyLibs\\"],
 
 with the .lib file in it, but that doesn't work. (I'd expect to have to 
 supply the file name somewhere, at least)
 
 Thanks.
I agree with all your other points. Telling explicit what's going on would help a lot in daily business. Not only for D but all compiler stuff. But it seems to be tradition to not do this. Anyway, regarding the static libs. I used this on a Win64 project and it works: "lflags" : [ "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib", "D:\\develop\\cairo\\libpng\\libpng.lib", "gdi32.lib" ], -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Jan 10 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 05:46:11 UTC, Robert M. Münch wrote:
 On 2016-01-11 01:47:54 +0000, Jason Jeffory said:

 and how does one link in compiled static libraries into a dub 
 project?
 
 I tried adding stuff like
 
 "lflags" : ["+C:\\MyLibs\\"],
 
 with the .lib file in it, but that doesn't work. (I'd expect 
 to have to supply the file name somewhere, at least)
 
 Thanks.
I agree with all your other points. Telling explicit what's going on would help a lot in daily business. Not only for D but all compiler stuff. But it seems to be tradition to not do this. Anyway, regarding the static libs. I used this on a Win64 project and it works: "lflags" : [ "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib", "D:\\develop\\cairo\\libpng\\libpng.lib", "gdi32.lib" ],
Thanks, that works but 1. *not a valid lib file* (glfw3.lib) ;/ Ok, 2. What about 64? Does one have to maintain two branches for that? I don't understand why the trend is not to be verbose but to hide details ;/ It's simply the wrong way. 1. Trying windows link instead, remember having problems like this in the past with optlink. "LINK : fatal error LNK1104: cannot open file '_CMDLINE'" ;/ tried converting with coffimplib, not an import library. Another rabbit hole to go down ;/ (Why do programmers make programmers life hell?) After trying other various things that didn't work, I'm done for today... too frustrating. Hopefully I'll come back tomorrow with a nice surprise.
Jan 11 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 11 January 2016 at 16:27:54 UTC, Jason Jeffory wrote:

 Anyway, regarding the static libs. I used this on a Win64 
 project and it works:

        "lflags" : [
          
 "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib",
          "D:\\develop\\cairo\\libpng\\libpng.lib",
          "gdi32.lib"
        ],
Thanks, that works but
lflags is probably not the best way to do it. The "libs" field is better. This will guarantee that the library is passed in a compiler-appropriate manner across platforms. lflags is compiler-specific.
 1. *not a valid lib file* (glfw3.lib) ;/ Ok,
It's likely a COFF vs OMF issue.
 2. What about 64? Does one have to maintain two branches for 
 that?
No. You might keep the libraries in separate directories or use a naming convention (like appending -32 or -64 on the library names) to distinguish them. Using DUB, you could then add something like the following: "libs-windows-dmd-x86": ["myWinLib-32"], "libs-windows-dmd-x86_64": ["myWinLib-64"] Drop the "windows" bit for cross-platform stuff. Of course, this is dependent upon you passing -ax86_64 to DUB when you want to compile for 64-bit
 1. Trying windows link instead, remember having problems like 
 this in the past with optlink.

 "LINK : fatal error LNK1104: cannot open file '_CMDLINE'"

 ;/

 tried converting with coffimplib, not an import library. 
 Another rabbit hole to go down ;/ (Why do programmers make 
 programmers life hell?)
coffimplib [1] is for converting import libraries, not static libraries. You can also use implib (part of the basic utilities package [2]) to generate an import library if you have a DLL. You should use coff2omf [3] to convert static libraries and object files. You can avoid all of these headaches by using dynamic bindings like those at DerelictOrg [4] if they are available for the libraries you use. Then the compile-time dependency on the C library goes away and all you need is the DLL at runtime. [1] http://www.digitalmars.com/ctg/coffimplib.html [2] http://www.digitalmars.com/download/freecompiler.html [3] http://www.digitalmars.com/ctg/coff2omf.html [4] https://github.com/DerelictOrg
Jan 11 2016
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2016-01-12 04:15:36 +0000, Mike Parker said:

 You can avoid all of these headaches by using dynamic bindings like 
 those at DerelictOrg [4] if they are available for the libraries you 
 use. Then the compile-time dependency on the C library goes away and 
 all you need is the DLL at runtime.
I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. How simple would it be to just have one self-contained executable? And all the Docker hype is doing / simulating this with a sledgehammer. I prefer to link everything static, and it saved us and our clients hours of headache. Drivespace is no limiting factor anymore, but time and customer satisfaction is always. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Jan 12 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch 
wrote:

 I have seen countless problems because apps are using dynamic 
 linking and whole IT environements getting into DLL hell. IMO 
 one of the worst ideas these days.
I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell.
Jan 12 2016
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 12:32:11 UTC, Mike Parker wrote:
 On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch 
 wrote:

 I have seen countless problems because apps are using dynamic 
 linking and whole IT environements getting into DLL hell. IMO 
 one of the worst ideas these days.
I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell.
To clarify, static bindings can be used when linking both statically and dynamically. Dynamic bindings have no link-time dependency at all and are used to load a dynamic library manually at runtime.
Jan 12 2016
prev sibling parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch 
wrote:
 On 2016-01-12 04:15:36 +0000, Mike Parker said:

 You can avoid all of these headaches by using dynamic bindings 
 like those at DerelictOrg [4] if they are available for the 
 libraries you use. Then the compile-time dependency on the C 
 library goes away and all you need is the DLL at runtime.
I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. How simple would it be to just have one self-contained executable? And all the Docker hype is doing / simulating this with a sledgehammer. I prefer to link everything static, and it saved us and our clients hours of headache. Drivespace is no limiting factor anymore, but time and customer satisfaction is always.
It seems the whole state of affairs in programming is "Lets do the most minimal work to get X to work in environment Y. To hell with everything else!". The programmers tend to do the most minimal work to code stuff that they can get away with. This isn't 1984 but coding quality has no increased much since then. No programmer, in this day and age, should have to spend more than a few minutes getting anything to the point of actual programming. Programmers can code smarter, faster, and better, yet when it comes to the tooling, they tend to suck balls. Visual studio style is about the minimum one should except. I've virtually had no problems with it. MS did good job of modernizing the toolchain... Most people that code on linux think that it should be "hard" and gui's suck, that programming is suppose to be a hazing ritual. They setup their system to work for them, and it works... anyone with problems must be ignorant and not "pro programmers". It's kinda this elitist attitude. They spend more time solving 1%'er problems than creating tools that *just* work for 99% of the people. When problems occur it is never their fault but the fault of the ignorant cave man trying to become an godly programmer. Just search "openGL dmd"(28k) and about 80% of the results are people having problems with getting openGL working with D. "openGL dmd error" has 1M results, thats nearly 30 times the results. Of course, these don't mean much, but does give the trend. That's just for openGL. D has a long way to go to make it competitive... as long as the tooling sucks and there are problems with stupid issues such as coff vs omf, installation issues, ide issues, etc... it won't get off the ground. The D "core" seems to be mainly interested in fixing and enhancing very niche issues in D instead of working on making it a viable and usable candidate for the masses. They think by taking a Ferrari and doing all the pin stripes and detail work and add a specialized turbo charger is going to make it more appealing... yet they never put gas in it so that the customer can actually test drive it. There is a benefit of having D work well... the benefit is that there is a larger user database = more man-hours to help D evolve. The reason why MS and VS is better is because a noob like myself can install it and hit the gas pedal and go. It looks good, it's fast, it's not the Ferrari... it's like a Mazda. But it runs! No frustration figuring out why the damn thing won't start. I want to drive! Not fucking around for days trying to figure out why the thing won't start. It's not my job to fill it up with gas, that's the dealers responsibility. Anyways, sorry for the rant... not like things will change. D does fill a niche, and it shows ;/ Just wish I could drive the Ferrari! I know it's awesome! but the Mazda is more affordable(Man hours wise) and gets me to where I want to go without hassle. (I should have said dragster instead of Ferrari... something that is super fast but my blow up and kill you... anyways, you get the point!)
Jan 12 2016
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Tuesday, 12 January 2016 at 19:38:32 UTC, Jason Jeffory wrote:
 It seems the whole state of affairs in programming is "Lets do 
 the most minimal work to get X to work in environment Y. To 
 hell with everything else!". The programmers tend to do the 
 most minimal work to code stuff that they can get away with.
Since people aren't being paid to do this, and it's not enjoyable for many to make things universally easy across different environments once someone has solved their own problem, you can hardly object to the behaviour - particularly because different people are good at different things, and the guy who creates a project may not be the same guy needed to make it easy to use. Then it's more a question of treating it as a challenge to be solved. It's quite amazing how much a relatively small number of people has accomplished, and it's something of a hazard of open-source that instead of gratitude people receive far more criticism and complaint. (They say a 2:1 balance of positive:negative comments is needed for a healthy relationship). So it's an engineering or institutional challenge - how does one achieve this as a community?
 This isn't 1984 but coding quality has no increased much since 
 then.
A little hyperbolic? ;) We do seem to have higher quality problems today, but do you recall what code from the 80s was like?
 I've virtually had no problems with it. MS did good job of 
 modernizing the toolchain... Most people that code on linux 
 think that it should be "hard" and gui's suck, that programming 
 is suppose to be a hazing ritual. They setup their system to 
 work for them, and it works... anyone with problems must be 
 ignorant and not "pro programmers". It's kinda this elitist 
 attitude. They spend more time solving 1%'er problems than 
 creating tools that *just* work for 99% of the people. When 
 problems occur it is never their fault but the fault of the 
 ignorant cave man trying to become an godly programmer.
Do you think that's actually representative of the attitudes of people here? I haven't seen that. But work won't get done without a plan and without someone to actually do it and one can't force people to do things they don't want to do. A big problem is people don't know what to work on, and maybe some kind of systematic approach to identify problem needs would help.
 Just search "openGL dmd"(28k) and about 80% of the results are 
 people having problems with getting openGL working with D. 
 "openGL dmd error" has 1M results, thats nearly 30 times the 
 results.
It would be a good idea to systematize this and produce a web report so one can see in a more structured way where the biggest difficulties are. I have been talking to Adam a bit about ways we could do this using forum history. I agree with your observation that there is much friction in the way of a new user learning D and that many simply won't persevere long enough. That's nonetheless a better problem to have than having an intrinsically inferior product - one just needs to establish a process, and to have some way of organizing efforts to address these difficulties (which may include funding to a certain extent). I think it's a necessary part of the way D has developed that people have focused on the language and core library first - it's not so long that it has been stable and ready to use and over time better tooling will unfold. (Constructive criticism and ideas may help this process).
 D has a long way to go to make it competitive... as long as the 
 tooling sucks and there are problems with stupid issues such as 
 coff vs omf, installation issues, ide issues, etc... it won't 
 get off the ground.
Depends what the competition is ;) Coff vs OMF will disappear in time as people move to 64 bit. Installation questions seem to be improving. IDE support keeps getting better. For many uses, these things are a one-off price for adopting D. Whether it's feasible to pay that depends on what you are doing and the people you are working with.
 The D "core" seems to be mainly interested in fixing and 
 enhancing very niche issues in D instead of working on making 
 it a viable and usable candidate for the masses.
But it is in the nature of things that disruptive technologies start off as inferior in certain respects and it's only with time that they can be a superior competitor across the board to the dominant technologies. See Clayton Christensen's work "The Innovator's Dilemma". It is what it is, and one can't wave a magic wand to force people to work for free on shiny tools to make it easy. If that's what one wants, then one can do one's small part to encourage this to happen - work on that oneself and contribute it, file bugzilla issues, fund the D foundation (once it is ready). But simply complaining won't change anything. BTW I hardly think that memory allocation, containers, documentation, and web site (recent areas of focus by leadership) are niche issues.
 Anyways, sorry for the rant... not like things will change. D 
 does fill a niche, and it shows ;/ Just wish I could drive the 
 Ferrari! I know it's awesome! but the Mazda is more 
 affordable(Man hours wise) and gets me to where I want to go 
 without hassle.
Maybe you're right and it's not ready for you for now (although this might change). It's easy to overestimate what's possible in a short period of time and underestimate over a longer period. The web site and documentation are very much better today than when I first looked at D maybe 1.5-2 years back.
Jan 12 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 12 January 2016 at 20:38:50 UTC, Laeeth Isharc wrote:
 On Tuesday, 12 January 2016 at 19:38:32 UTC, Jason Jeffory 
 wrote:
 It seems the whole state of affairs in programming is "Lets do 
 the most minimal work to get X to work in environment Y. To 
 hell with everything else!". The programmers tend to do the 
 most minimal work to code stuff that they can get away with.
Since people aren't being paid to do this, and it's not enjoyable for many to make things universally easy across different environments once someone has solved their own problem, you can hardly object to the behaviour - particularly because different people are good at different things, and the guy who creates a project may not be the same guy needed to make it easy to use. Then it's more a question of treating it as a challenge to be solved. It's quite amazing how much a relatively small number of people has accomplished, and it's something of a hazard of open-source that instead of gratitude people receive far more criticism and complaint. (They say a 2:1 balance of positive:negative comments is needed for a healthy relationship). So it's an engineering or institutional challenge - how does one achieve this as a community?
 This isn't 1984 but coding quality has no increased much since 
 then.
A little hyperbolic? ;) We do seem to have higher quality problems today, but do you recall what code from the 80s was like?
 I've virtually had no problems with it. MS did good job of 
 modernizing the toolchain... Most people that code on linux 
 think that it should be "hard" and gui's suck, that 
 programming is suppose to be a hazing ritual. They setup their 
 system to work for them, and it works... anyone with problems 
 must be ignorant and not "pro programmers". It's kinda this 
 elitist attitude. They spend more time solving 1%'er problems 
 than creating tools that *just* work for 99% of the people. 
 When problems occur it is never their fault but the fault of 
 the ignorant cave man trying to become an godly programmer.
Do you think that's actually representative of the attitudes of people here? I haven't seen that. But work won't get done without a plan and without someone to actually do it and one can't force people to do things they don't want to do. A big problem is people don't know what to work on, and maybe some kind of systematic approach to identify problem needs would help.
 Just search "openGL dmd"(28k) and about 80% of the results are 
 people having problems with getting openGL working with D. 
 "openGL dmd error" has 1M results, thats nearly 30 times the 
 results.
It would be a good idea to systematize this and produce a web report so one can see in a more structured way where the biggest difficulties are. I have been talking to Adam a bit about ways we could do this using forum history. I agree with your observation that there is much friction in the way of a new user learning D and that many simply won't persevere long enough. That's nonetheless a better problem to have than having an intrinsically inferior product - one just needs to establish a process, and to have some way of organizing efforts to address these difficulties (which may include funding to a certain extent). I think it's a necessary part of the way D has developed that people have focused on the language and core library first - it's not so long that it has been stable and ready to use and over time better tooling will unfold. (Constructive criticism and ideas may help this process).
 D has a long way to go to make it competitive... as long as 
 the tooling sucks and there are problems with stupid issues 
 such as coff vs omf, installation issues, ide issues, etc... 
 it won't get off the ground.
Depends what the competition is ;) Coff vs OMF will disappear in time as people move to 64 bit. Installation questions seem to be improving. IDE support keeps getting better. For many uses, these things are a one-off price for adopting D. Whether it's feasible to pay that depends on what you are doing and the people you are working with.
 The D "core" seems to be mainly interested in fixing and 
 enhancing very niche issues in D instead of working on making 
 it a viable and usable candidate for the masses.
But it is in the nature of things that disruptive technologies start off as inferior in certain respects and it's only with time that they can be a superior competitor across the board to the dominant technologies. See Clayton Christensen's work "The Innovator's Dilemma". It is what it is, and one can't wave a magic wand to force people to work for free on shiny tools to make it easy. If that's what one wants, then one can do one's small part to encourage this to happen - work on that oneself and contribute it, file bugzilla issues, fund the D foundation (once it is ready). But simply complaining won't change anything. BTW I hardly think that memory allocation, containers, documentation, and web site (recent areas of focus by leadership) are niche issues.
No, but what's the point if there is not a proper supported tool chain to make most advantage of this stuff. It's like putting the horse before the cart(or, more sensical, having the cart pull the horse). The "leadership" focuses on what they believe is the best stuff, but they are not in a position to know what the best stuff is precisely because they are the leaders. They must ask the people they are doing this all for. If Walter, for example, want's his baby to grow up to fill an important part of human history(if not, then why all the work?), it seems wise that he make it the easiest to use. Easier = more people use it = more useful to people = bigger = longer = better. By niche, I mean simply compared to the overall D developmental issues. Web site design may not be totally niche, but solving some rare dmd internal compiler problems are. Also, D can't compete with the web server community so it is also niche in that regard. (until you make D easy to use, whats the point of creating cool stuff for it... no one will use it if they can't get there easily)
 Anyways, sorry for the rant... not like things will change. D 
 does fill a niche, and it shows ;/ Just wish I could drive the 
 Ferrari! I know it's awesome! but the Mazda is more 
 affordable(Man hours wise) and gets me to where I want to go 
 without hassle.
Maybe you're right and it's not ready for you for now (although this might change). It's easy to overestimate what's possible in a short period of time and underestimate over a longer period. The web site and documentation are very much better today than when I first looked at D maybe 1.5-2 years back.
I don't disagree with anything you have said. The problem is mainly an "attitude". It's the same attitude that people make about life "I'll die, go to heaven, so whats the point of "fixing" stuff here, now?". But that attitude is what make it bad in the first place. Letting things "ride" because it's the easier thing to do but just perpetuates the problem which grows. D, obviously, has done some great things. But there seems to be a huge lack of focus on the important things that will make it better. It's quite simple, the 100 or so people working actively on D's growth can't do much of anything compared to 1M people working on it. Hence, it would seem best to figure out how to get the 1M people working on it quick as possible. As the 100 people toil away at solving these "niche" problems, they are not working on making D "affordable" to everyone. They are not multiplying their effort. They have a 1:1 leverage ration instead of 100:1. D should be much larger than it is. How long as it been out? There is a dysfunctional issue with D. Look how fast go and rust took off? There are reasons for that. Mainly because they created an easier to use and more functional toolset. Kids that are getting into programming that have issues with X will drop X in blink of an eye and move on to Y. If Y is easy and works and does what they want, then they will stick with Y. At some point they've invested in Y and continue to use it. D has the issue that it is not easy to use beyond basic trivial non-dependent coding. Hence when these kids try to do real world stuff(openGL, audio, GUI's) and run into 1984 problems, they move on to something easier. D has so much resistance that it has to overcome this if it cares to be a dominant player. Focusing on the wrong stuff is wrong. D does that a lot IMO... or at least neglects the right stuff(easy of use is a huge factor, and partly D has this in a fundamental way, but not in a "everyday real world use" way). My main issue with D is not so much what it does, but that I feel it is not covering enough ground on certain areas that I feel my investment in it will not return anything. I could spend 10 years becoming a D pro and if D goes fades away, then what would it all have been for? Each person that makes such a choice of using D will have to ask themselves that question. Some obviously are ok with investing in it, *many* are not(the masses). That concerns me, because the D "leadership" doesn't seem to think it matters. What D needs is a marketing genius that can make D in to something viable.
Jan 12 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
(I should mention that I am exaggerating a bit, and some of the 
complaints about D are actually more directed to the programming 
community in general. D has the same fundamental issues though 
and it is just a matter of scale. Programming is way more fun 
when you are actually programming and getting the job done rather 
than fighting things that should work but don't. As programmers, 
we get used to that crap.. specially those that programmed in the 
70's and 80's... but it doesn't mean it's ok. Specially when we 
know how to fix it. I really like the D language but the D tool 
chain should be more user friendly to work with on every level.)
Jan 12 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 21:08:30 UTC, Jason Jeffory wrote:
 (I should mention that I am exaggerating a bit, and some of the 
 complaints about D are actually more directed to the 
 programming community in general. D has the same fundamental 
 issues though and it is just a matter of scale. Programming is 
 way more fun when you are actually programming and getting the 
 job done rather than fighting things that should work but 
 don't. As programmers, we get used to that crap.. specially 
 those that programmed in the 70's and 80's... but it doesn't 
 mean it's ok. Specially when we know how to fix it. I really 
 like the D language but the D tool chain should be more user 
 friendly to work with on every level.)
I think there's another side of this in that what is an issue for one person isn't necessarily an issue for another. For example, your difficulties with static linking... you aren't the first person to have this problem, but I personally never have. It all seems quite straight forward to me. I was annoyed by the COFF/OMF issue when I first started using D, sure, and that's what prompted me to start Derelict), but it's never been a problem that prevented me from building my D projects. The way to solve this particular sort of problem is to have more documentation, or tutorials, but that requires someone with the time and motivation to write it. People who aren't having that problem are going to be motivated to direct their time and energy elsewhere. So I don't see this as an issue of "getting used to" a bad situation, just one of varying opinions about what part of the situation is bad. I'm going to make an effort toward improving the situation with my learningd.org site. Linking with C libraries would be a good topic for a tutorial to go there. There is also some movement behind the scenes right now to create a comprehensive web site for teaching all things D, but it's going to be after the next DConf before any concrete effort is made in that direction. As for the toolchain... Until there is a dedicated team with a clear goal-oriented task list and the management necessary to keep development focused on those tasks, then development will go in the direction that the core contributors feel they need to direct their efforts. Anyone can champion a new cause in D's development, and several have over the years. That's what has driven the project forward. There have been many, many, many discussions over the years about how unfriendly D is to new users, or how difficult it is to get up and running with this or that aspect of the toolchain. Most of them have resulted in improvements. As a long time D user, I can tell you that you kids have it much better than we did back in the day. So things will get easier with time. Pre-D experience is what determines the degree of difficulty in getting started with D right now. For example, programmers who are comfortable with the command line, particularly when using C or C++, tend to have few difficulties with the toolchain. I'm hoping that the recent creation of the D Foundation will create opportunities to make it easier for /anyone/ to hit the ground running with D.
Jan 12 2016
parent Jason Jeffory <JasonJeffory doodle.com> writes:
On Wednesday, 13 January 2016 at 01:40:59 UTC, Mike Parker wrote:
 On Tuesday, 12 January 2016 at 21:08:30 UTC, Jason Jeffory 
 wrote:
 (I should mention that I am exaggerating a bit, and some of 
 the complaints about D are actually more directed to the 
 programming community in general. D has the same fundamental 
 issues though and it is just a matter of scale. Programming is 
 way more fun when you are actually programming and getting the 
 job done rather than fighting things that should work but 
 don't. As programmers, we get used to that crap.. specially 
 those that programmed in the 70's and 80's... but it doesn't 
 mean it's ok. Specially when we know how to fix it. I really 
 like the D language but the D tool chain should be more user 
 friendly to work with on every level.)
I think there's another side of this in that what is an issue for one person isn't necessarily an issue for another. For example, your difficulties with static linking... you aren't the first person to have this problem, but I personally never have. It all seems quite straight forward to me. I was annoyed by the COFF/OMF issue when I first started using D, sure, and that's what prompted me to start Derelict), but it's never been a problem that prevented me from building my D projects. The way to solve this particular sort of problem is to have more documentation, or tutorials, but that requires someone with the time and motivation to write it. People who aren't having that problem are going to be motivated to direct their time and energy elsewhere. So I don't see this as an issue of "getting used to" a bad situation, just one of varying opinions about what part of the situation is bad. I'm going to make an effort toward improving the situation with my learningd.org site. Linking with C libraries would be a good topic for a tutorial to go there. There is also some movement behind the scenes right now to create a comprehensive web site for teaching all things D, but it's going to be after the next DConf before any concrete effort is made in that direction. As for the toolchain... Until there is a dedicated team with a clear goal-oriented task list and the management necessary to keep development focused on those tasks, then development will go in the direction that the core contributors feel they need to direct their efforts. Anyone can champion a new cause in D's development, and several have over the years. That's what has driven the project forward. There have been many, many, many discussions over the years about how unfriendly D is to new users, or how difficult it is to get up and running with this or that aspect of the toolchain. Most of them have resulted in improvements. As a long time D user, I can tell you that you kids have it much better than we did back in the day. So things will get easier with time. Pre-D experience is what determines the degree of difficulty in getting started with D right now. For example, programmers who are comfortable with the command line, particularly when using C or C++, tend to have few difficulties with the toolchain. I'm hoping that the recent creation of the D Foundation will create opportunities to make it easier for /anyone/ to hit the ground running with D.
Yes, but the world consists of many differnet programmers, and due the the interaction of different things, which is exponential, it is too complex to solve each persons problems on a one by one basis. What works for you works for you because you are you... not because you are me(not trying to make a Beatles song here). e.g., if write your total system configuration in a list, and I write mine, then just about every element in the list interacts with every other element and creates new dependency problems. The amount of potential issues it the powerset of all the items. e.g., ubuntu 14.3, dmd 2.062, glad opengl, etc... windows, dmd 2.061, derelict opengl, etc... Each item in your list has to interact with each other, and in each case it may or may not work well for you. But my list is totally different and you can't say "It works for me"... because it doesn't help me in any way. dmd 2.061 may have a bug in the windows version and the derelict version that is not exhibited by the linux case. Because the problem is so complex, the only way to make it work is that the elements themselves have to work well individually(basically because we can't code for every combination). This is why we have to break complex systems down into simple well understood parts. But information is the here. One has to have some way to "measure" progress(ask Andrei, he said that in his performance lecture). If a tool doesn't give results that can be compared, we can't see how we are solve the problem and it usually requires guess, looking up stuff online for similar problems/solutions, and usually a lot of wasted time. So, the solution to all this is not solving the problems after they exist but trying to prevent them in the first place... and there is one and only one way to do this, and that's to write better tools(because after the tools, is were the problems come in from). e.g., imagine compilers were perfect, no bugs... then we wouldn't have problems with them, no patches would be required(e.g., so essentially no github), etc.. But we don't work towards writing perfect tools, we work towards writing perfect fixes for the tools. Again, the horse before the cart. I do realize it is necessary, and some people are working in the absolute right direction. Most, it's just the vague general direction with a lot of circling around, getting lost, etc. My main "gripe", if you will, is simply that the tools are really really import, and that programmers in general tend to forget just how important. Mainly because they deal with it on a daily basis, and many times they've forgotten how much of their own lives have been wasted on needlessly solving problems that shouldn't have existed in the first place. Imagine if you were given all the time back that you spend wasted on chasing rabbits that didn't exist? (someone wrote code that didn't do what it was suppose to, etc.) It would probably add up to more than a year(if you've been programming a long time). That is significant! This is my impression of the D "leadership": Lets fix bugs and squabble over who's write about semantic interpretation of certain language constructs(e.g., extern(c++, ns)). Lets find out who's right and who's wrong and lets may sure no one admits they are wrong or accepts a compromise! This creates "unhappiness" on both sides. 1. If Manu had his wish, he could test out the feature and determine if it worked for him. 2. If Walter had his, he could feel good about not introducing something that caused a lot of headaches. This is not the solution to things. This creates division and separation from actually solving the real problem. The solution is "Lets figure out how to do both". That way, if Walter is wrong, he can be proven wrong and if Manu is wrong, he will be proven wrong(through real world practical problems). How much time is wasted on such arguments instead of just figuring out how to satisfies all parties? I personally believe it can be done if everyone works towards that goal. (maybe there will have be some compromise in technical issues, but not in goal) Again, I'm inflating a lot of stuff and I think, for the most part, DMD does a good job. It works well across the board in general. Specific stuff though it seems to fail at in more cases than it should, for some reason. It's more of a mentality that is wide spread across people and programmers in general. It usually leads to an unfocused and unproductive mess in the long term. I'd hate to see that happen to D because I feel it is, perhaps, the best language out there. It's elegant to some degree, it's powerful, it has meta programming constructs that just make sense, the people behind it seem intelligent and have a strong desire to see it succeed... But it has a long was to go... and that can't happen without more support. Gui's, graphics, sound, database, etc must be well done and supported innately by D if it wants to be top dog. Water the flower well and it grows into a beautiful thing. Neglect and ignore it and it will wilt and die. Same for children, programming languages, families, species, etc. D's too good to let it fade off into the bowls of mankind.
Jan 12 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-11 02:22, Jason Jeffory wrote:
 Dmd's setup construction is a bit weird and has some difficult issue
 tracking.

 How about if dmd supported, if it already doesn't, some ways to help the
 user check the configuration of dmd. It would be quick and easy to
 implement.

 e.g.,

 dmd -showinfo

 Target Arch: x86
 Libraries: C:\Mylib;C:\Another\Lib\Somewhere
 Modules: C:\MyModules;
 Version: 2.062
 etc...
You can get some more information by compiling with the "-v" flag. In the top it will print the config used, i.e. the path to sc.ini the compiler found. At the bottom it will print the command it uses for linking. -- /Jacob Carlborg
Jan 12 2016