www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Had another 48hr game jam this weekend...

reply Manu <turkeyman gmail.com> writes:
--e89a8fb1fdee6d80e304e548e4a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We have to get the user experience and first impressions under control...

I'd really love to to see a general roadmap and list of priorities. Even if
goals are high-level, they might help direct focus?

So I had another game-jam this weekend with a bunch of friends who are all
industry professionals.
The point of a 48 hour game jam is to prioritise productivity and
creativity.
Choosing a language like D here makes sense from a productivity point of
view... that is, if it 'JUST WORKS'=E2=84=A2.

There were 7 programmers, they were all using D for the first time (except
me).

Most running windows, one on OSX, one on Linux.
We ran into the same problems old that have been giving me the shits as
long as I've been using D.

Configuring compilers:

Naturally, this is primarily a problem with the windows experience, but
it's so frustrating that it is STILL a problem... how many years later?
People don't want to 'do work' to install a piece of software. Rather, they
expect it to 'just work'. We lost about 6 hours trying to get everyone's
machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! I just kept
promising people that it would save time overall... which I wish were true.

The only compiler you can realistically use productively in windows is
DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the stars aligned
such that it would actually compile and find the linker+libs.

Walter: DMD needs to internally detect installations of various versions of
VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
installer needs to amend sc.ini. Either way, leaving it to a user to fiddle
with an ini file just isn't acceptable. We had to google solutions to this
problem, and even then, we had trouble with the paths we added to sc.ini;
are spaces acceptable? Do they have quites around them?...
I might also suggest that Microsoft supplied (ie, 'standard'), libraries
should be automatically detected and path entries added in there too:
  C:\Program Files (x86)\Microsoft SDKs\...
  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and each of us had
to configure them ourselves.


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work with a
makefile. Everybody else wanted a comfortable IDE solution (and the linux
user would prefer it too).

!!!!!!!!!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a massive point
of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how
absolutely important this is.
!!!!!!!!!

I have come to the conclusion that treating IDE integration as ancillary
projects maintained by usually just one single member of the community has
absolutely failed.
I suggest:
 * These should be made central D community projects.
 * I think they should be hosted in the same github organisation as DMD.
 *** As many contributors as possible should be encouraged to work with
them every day.
   - Deprecate DMD makefiles. Seriously! Insist that contributors use the
IDE bindings to work on DMD.
   - The fact that you all laughed at the prior point suggests clearly why
it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user experience.
 * They should receive bugs in the main github bug-tracker, so EVERY D
contributor can see them, and how many there are.

IDE integration absolutely needs to be considered a first class feature of
D.
I also suggest that the IDE integration downloads should be hosted on the
dlang download page so they are obvious and available to everyone without
having to go looking, and also as a statement that they are actually
endorsed by the dlanguage authorities. As an end-user, you're not left
guessing which ones are good/bad/out of date/actually work/etc.

Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
only realistic choices available. The OSX user would have preferred an
XCode integration.

Overwhelmingly, the biggest complaint was a lack of symbolic information to
assist with auto-completion. Visual-D tries valiantly, but it falls quite
short of the mark.
This goes back to the threads where the IDE guys are writing their own
parsers, when really, DMD should be able to be built as a lib, with an API
designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and syntax
highlighting purposes should be a service offered and maintained by DMD.
That way it will evolve with the language, and anyone can use it without
reinventing the wheel.


Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to get OSX
working); there are lots of problems with the debugging experience under
visual studio...
I haven't logged bugs yet, but I intend to.
There were many instances of people wasting their time chasing bugs in
random places when it was simply a case of the debugger lying about the
value of variables to them, and many more cases where the debugger simply
refused to produce values for some variables at all.
This is an unacceptable waste of programmers time, and again, really burned
us in a 48hour context.


Documentation:

Okay for the most part, but some windows dev's want a CHM that looks like
the typical Microsoft doc's people are used to. Those that aren't familiar
with the CHM viewer; it's just HTML but with a nice index + layout tree.


Containers:

The question came up multiple times; "I don't think this should be an
array... what containers can I use, and where are they?"...
Also, nobody could work out how to remove an arbitrary item from an array,
or an item from an AA by reference/value (only by key).

This code:
  foreach(i, item; array)
    if(item =3D=3D itemToRemove)
      array =3D array[0..i] ~ array[i+1..$];
Got a rather 'negative' reaction from the audience to put it lightly...


Bugs:
Yes, we hit DMD bugs, like the one with opaque structs which required
extensive work-arounds.
  struct MyStruct;
  MyStruct*[] =3D new MyStruct*[n];

We also ran into some completely nonsense error messages, but I forgot to
log them, since we were working against the clock.


One more thing:
I'll just pick one language complaint from the weekend.
It is how quickly classes became disorganised and difficult to navigate
(like Java and C#).
We all wanted to ability to define class member functions outside the class
definition:
  class MyClass
  {
    void method();
  }

  void MyClass.method()
  {
    //...
  }

It definitely cost us time simply trying to understand the class layout
visually (ie, when IDE support is barely available).
You don't need to see the function bodies in the class definition, you want
to quickly see what a class has and does.


Conclusion:
I think this 48 hour jam approach is a good test for the language and it's
infrastructure. I encourage everybody to try it (ideally with a clean slate
computer).
The lesson is that we need to make this process smooth, since it mirrors
the first-experience of everybody new to D.
It also highlights and magnifies time-wasters that are equally unacceptable
in a commercial environment.

I don't think I made any converts this weekend wrt the above issues
encountered. I might have even just proved to them that they should indeed
stick with C# (the IDE's work!)... :(

Please, we need a road-map, we need to prioritise these most basic aspects
of the experience, and we need to do it soon.
I might re-iterate my feeling that external IDE integration projects should
be claimed by the community officially, and user experience + debugging
issues should be first-class issues in the main d language bug-tracker so
everybody can see them, and everybody is aware of the stats.
Also, the DMD front-end should be a lib offering auto-completion and syntax
hilighting data to clients.

I'm doing some more work on premake (a nice light buildsystem that
generated makefiles and project files for popular IDE's) to tightly
incorporate D into the various IDE's it supports.

</endrant>

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

<div dir=3D"ltr"><div>We have to get the user experience and first impressi=
ons under control...</div><div><br></div><div>I&#39;d really love to to see=
 a general roadmap and list of priorities. Even if goals are high-level, th=
ey might help direct focus?</div>
<div><br></div>So I had another game-jam this weekend with a bunch of frien=
ds who are all industry professionals.<div>The point of a 48 hour game jam =
is to prioritise productivity and creativity.</div><div>Choosing a language=
 like D here makes sense from a productivity point of view... that is, if i=
t &#39;JUST WORKS&#39;=E2=84=A2.<br>
</div><div><div><br></div><div>There were 7 programmers, they were all usin=
g D for the first time (except me).</div><div><br></div><div>Most running w=
indows, one on OSX, one on Linux.</div><div>We ran into the same problems o=
ld that have been giving me the shits as long as I&#39;ve been using D.</di=
v>
<div><br></div><div><div>Configuring compilers:</div><div><br></div><div>Na=
turally, this is primarily a problem with the windows experience, but it&#3=
9;s so frustrating that it is STILL a problem... how many years later?</div=

are. Rather, they expect it to &#39;just work&#39;. We lost about 6 hours t= rying to get everyone&#39;s machines working properly.</div><div>In the con= text of a 48 hour game jam, that&#39;s a terrible sign! I just kept promisi= ng people that it would save time overall... which I wish were true.<br> </div><div><br></div><div>The only compiler you can realistically use produ= ctively in windows is DMD-Win64, and that doesn&#39;t work out of the box.<= /div><div>We needed to mess with sc.ini for quite some time to get the star= s aligned such that it would actually compile and find the linker+libs.</di= v> <div><br></div><div>Walter: DMD needs to internally detect installations of= various versions of VisualStudio, and either &#39;just work&#39;, or amend= sc.ini on its own. Or the installer needs to amend sc.ini. Either way, lea= ving it to a user to fiddle with an ini file just isn&#39;t acceptable. We = had to google solutions to this problem, and even then, we had trouble with= the paths we added to sc.ini; are spaces acceptable? Do they have quites a= round them?...</div> <div>I might also suggest that Microsoft supplied (ie, &#39;standard&#39;),= libraries should be automatically detected and path entries added in there= too:</div><div>=C2=A0 C:\Program Files (x86)\Microsoft SDKs\...<br></div><= div> =C2=A0 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...<br></di= v><div>These are on basically every windows developers machine, and each of= us had to configure them ourselves.<br></div><div><br></div></div><div><br=

isingly, the Linux user was the only person happy work with a makefile. Eve= rybody else wanted a comfortable IDE solution (and the linux user would pre= fer it too).</div> <div><br></div><div>!!!!!!!!!<br></div><div>This has to be given first-clas= s attention!</div><div>I am completely and utterly sick of this problem. Do= n made a massive point of it in his DConf talk, and I want to re-re-re-re-r= e-re-re-stress how absolutely important this is.</div> <div>!!!!!!!!!</div><div><br></div><div>I have come to the conclusion that = treating IDE integration as ancillary projects maintained by usually just o= ne single member of the community has absolutely failed.</div><div>I sugges= t:</div> <div>=C2=A0* These should be made central D community projects.</div><div>= =C2=A0* I think they should be hosted in the same github organisation as DM= D.</div><div>=C2=A0*** As many contributors as possible should be encourage= d to work with them every day.</div> </div><div>=C2=A0 =C2=A0- Deprecate DMD makefiles. Seriously! Insist that c= ontributors use the IDE bindings to work on DMD.</div><div>=C2=A0 =C2=A0- T= he fact that you all laughed at the prior point suggests clearly why it nee= ds to be done. It will cease to be a problem when all the druntime/phobos c= ontributors are suffering the end-user experience.</div> <div>=C2=A0* They should receive bugs in the main github bug-tracker, so EV= ERY D contributor can see them, and how many there are.<br></div><div><br><= /div><div>IDE integration absolutely needs to be considered a first class f= eature of D.</div> <div>I also suggest that the IDE integration downloads should be hosted on = the dlang download page so they are obvious and available to everyone witho= ut having to go looking, and also as a statement that they are actually end= orsed by the dlanguage authorities. As an end-user, you&#39;re not left gue= ssing which ones are good/bad/out of date/actually work/etc.</div> <div><br></div><div>Obviously, we settled on Visual-D (Windows) and Mono-D = (OSX/Linux); the only realistic choices available. The OSX user would have = preferred an XCode integration.</div><div><br></div><div>Overwhelmingly, th= e biggest complaint was a lack of symbolic information to assist with auto-= completion. Visual-D tries valiantly, but it falls quite short of the mark.= </div> <div>This goes back to the threads where the IDE guys are writing their own= parsers, when really, DMD should be able to be built as a lib, with an API= designed for using DMD as a lib/plugin.</div><div>I think continuous code = compilation for auto-completion and syntax highlighting purposes should be = a service offered and maintained by DMD. That way it will evolve with the l= anguage, and anyone can use it without reinventing the wheel.</div> <div><br></div><div><br></div><div>Debugging:</div><div><br></div><div>Poor= debugging experience wastes your time every 5 minutes.</div><div>I can onl= y speak for the Windows experience (since we failed to get OSX working); th= ere are lots of problems with the debugging experience under visual studio.= ..</div> <div>I haven&#39;t logged bugs yet, but I intend to.</div><div>There were m= any instances of people wasting their time chasing bugs in random places wh= en it was simply a case of the debugger lying about the value of variables = to them, and many more cases where the debugger simply refused to produce v= alues for some variables at all.</div> <div>This is an unacceptable waste of programmers time, and again, really b= urned us in a 48hour context.</div><div><br></div><div><br></div><div>Docum= entation:</div><div><br></div><div>Okay for the most part, but some windows= dev&#39;s want a CHM that looks like the typical Microsoft doc&#39;s peopl= e are used to. Those that aren&#39;t familiar with the CHM viewer; it&#39;s= just HTML but with a nice index + layout tree.</div> <div><br></div><div><br></div><div>Containers:</div><div><br></div><div>The= question came up multiple times; &quot;I don&#39;t think this should be an= array... what containers can I use, and where are they?&quot;...</div> <div>Also, nobody could work out how to remove an arbitrary item from an ar= ray, or an item from an AA by reference/value (only by key).</div><div><br>= </div><div>This code:</div><div>=C2=A0 foreach(i, item; array)</div><div>= =C2=A0 =C2=A0 if(item =3D=3D itemToRemove)</div> <div>=C2=A0 =C2=A0 =C2=A0 array =3D array[0..i] ~ array[i+1..$];</div><div>= Got a rather &#39;negative&#39; reaction from the audience to put it lightl= y...</div><div><br></div><div><br></div><div>Bugs:</div><div>Yes, we hit DM= D bugs, like the one with opaque structs which required extensive work-arou= nds.</div> <div>=C2=A0 struct MyStruct;</div><div>=C2=A0 MyStruct*[] =3D new MyStruct*= [n];</div><div><br></div><div>We also ran into some completely nonsense err= or messages, but I forgot to log them, since we were working against the cl= ock.</div> <div><br></div><div><br></div><div>One more thing:</div><div>I&#39;ll just = pick one language complaint from the weekend.</div><div>It is how quickly c= lasses became disorganised and difficult to navigate (like Java and C#).</d= iv> <div>We all wanted to ability to define class member functions outside the = class definition:</div><div>=C2=A0 class MyClass</div><div>=C2=A0 {</div><d= iv>=C2=A0 =C2=A0 void method();</div><div>=C2=A0 }</div><div><br></div><div=
=C2=A0 void MyClass.method()</div>

r></div><div>It definitely cost us time simply trying to understand the cla= ss layout visually (ie, when IDE support is barely available).</div><div>Yo= u don&#39;t need to see the function bodies in the class definition, you wa= nt to quickly see what a class has and does.</div> <div><br></div><div><br></div><div>Conclusion:<br></div><div>I think this 4= 8 hour jam approach is a good test for the language and it&#39;s infrastruc= ture. I encourage everybody to try it (ideally with a clean slate computer)= .</div> <div>The lesson is that we need to make this process smooth, since it mirro= rs the first-experience of everybody new to D.</div><div>It also highlights= and magnifies time-wasters that are equally unacceptable in a commercial e= nvironment.</div> <div><br></div><div>I don&#39;t think I made any converts this weekend wrt = the above issues encountered. I might have even just proved to them that th= ey should indeed stick with C# (the IDE&#39;s work!)... :(</div><div><br> </div><div>Please, we need a road-map, we need to prioritise these most bas= ic aspects of the experience, and we need to do it soon.</div><div>I might = re-iterate my feeling that external IDE integration projects should be clai= med by the community officially, and user experience + debugging issues sho= uld be first-class issues in the main d language bug-tracker so everybody c= an see them, and everybody is aware of the stats.</div> <div>Also, the DMD front-end should be a lib offering auto-completion and s= yntax hilighting data to clients.</div><div><br></div><div>I&#39;m doing so= me more work on premake (a nice light buildsystem that generated makefiles = and project files for popular IDE&#39;s) to tightly incorporate D into the = various IDE&#39;s it supports.</div> <div><br></div><div>&lt;/endrant&gt;</div></div> --e89a8fb1fdee6d80e304e548e4a4--
Aug 31 2013
next sibling parent "Trent" <anon nope.avi> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 We have to get the user experience and first impressions under 
 control...

 I'd really love to to see a general roadmap and list of 
 priorities. Even if
 goals are high-level, they might help direct focus?

 So I had another game-jam this weekend with a bunch of friends 
 who are all
 industry professionals.
 The point of a 48 hour game jam is to prioritise productivity 
 and
 creativity.
 Choosing a language like D here makes sense from a productivity 
 point of
 view... that is, if it 'JUST WORKS'™.

 There were 7 programmers, they were all using D for the first 
 time (except
 me).

 Most running windows, one on OSX, one on Linux.
 We ran into the same problems old that have been giving me the 
 shits as
 long as I've been using D.

 Configuring compilers:

 Naturally, this is primarily a problem with the windows 
 experience, but
 it's so frustrating that it is STILL a problem... how many 
 years later?
 People don't want to 'do work' to install a piece of software. 
 Rather, they
 expect it to 'just work'. We lost about 6 hours trying to get 
 everyone's
 machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! I 
 just kept
 promising people that it would save time overall... which I 
 wish were true.

 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the 
 stars aligned
 such that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various 
 versions of
 VisualStudio, and either 'just work', or amend sc.ini on its 
 own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a 
 user to fiddle
 with an ini file just isn't acceptable. We had to google 
 solutions to this
 problem, and even then, we had trouble with the paths we added 
 to sc.ini;
 are spaces acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), 
 libraries
 should be automatically detected and path entries added in 
 there too:
   C:\Program Files (x86)\Microsoft SDKs\...
   C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and 
 each of us had
 to configure them ourselves.


 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work 
 with a
 makefile. Everybody else wanted a comfortable IDE solution (and 
 the linux
 user would prefer it too).

 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a 
 massive point
 of it in his DConf talk, and I want to 
 re-re-re-re-re-re-re-stress how
 absolutely important this is.
 !!!!!!!!!

 I have come to the conclusion that treating IDE integration as 
 ancillary
 projects maintained by usually just one single member of the 
 community has
 absolutely failed.
 I suggest:
  * These should be made central D community projects.
  * I think they should be hosted in the same github 
 organisation as DMD.
  *** As many contributors as possible should be encouraged to 
 work with
 them every day.
    - Deprecate DMD makefiles. Seriously! Insist that 
 contributors use the
 IDE bindings to work on DMD.
    - The fact that you all laughed at the prior point suggests 
 clearly why
 it needs to be done. It will cease to be a problem when all the
 druntime/phobos contributors are suffering the end-user 
 experience.
  * They should receive bugs in the main github bug-tracker, so 
 EVERY D
 contributor can see them, and how many there are.

 IDE integration absolutely needs to be considered a first class 
 feature of
 D.
 I also suggest that the IDE integration downloads should be 
 hosted on the
 dlang download page so they are obvious and available to 
 everyone without
 having to go looking, and also as a statement that they are 
 actually
 endorsed by the dlanguage authorities. As an end-user, you're 
 not left
 guessing which ones are good/bad/out of date/actually work/etc.

 Obviously, we settled on Visual-D (Windows) and Mono-D 
 (OSX/Linux); the
 only realistic choices available. The OSX user would have 
 preferred an
 XCode integration.

 Overwhelmingly, the biggest complaint was a lack of symbolic 
 information to
 assist with auto-completion. Visual-D tries valiantly, but it 
 falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.
 I think continuous code compilation for auto-completion and 
 syntax
 highlighting purposes should be a service offered and 
 maintained by DMD.
 That way it will evolve with the language, and anyone can use 
 it without
 reinventing the wheel.


 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to 
 get OSX
 working); there are lots of problems with the debugging 
 experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing 
 bugs in
 random places when it was simply a case of the debugger lying 
 about the
 value of variables to them, and many more cases where the 
 debugger simply
 refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, 
 really burned
 us in a 48hour context.


 Documentation:

 Okay for the most part, but some windows dev's want a CHM that 
 looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.


 Containers:

 The question came up multiple times; "I don't think this should 
 be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
   foreach(i, item; array)
     if(item == itemToRemove)
       array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...


 Bugs:
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

 We also ran into some completely nonsense error messages, but I 
 forgot to
 log them, since we were working against the clock.


 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.


 Conclusion:
 I think this 48 hour jam approach is a good test for the 
 language and it's
 infrastructure. I encourage everybody to try it (ideally with a 
 clean slate
 computer).
 The lesson is that we need to make this process smooth, since 
 it mirrors
 the first-experience of everybody new to D.
 It also highlights and magnifies time-wasters that are equally 
 unacceptable
 in a commercial environment.

 I don't think I made any converts this weekend wrt the above 
 issues
 encountered. I might have even just proved to them that they 
 should indeed
 stick with C# (the IDE's work!)... :(

 Please, we need a road-map, we need to prioritise these most 
 basic aspects
 of the experience, and we need to do it soon.
 I might re-iterate my feeling that external IDE integration 
 projects should
 be claimed by the community officially, and user experience + 
 debugging
 issues should be first-class issues in the main d language 
 bug-tracker so
 everybody can see them, and everybody is aware of the stats.
 Also, the DMD front-end should be a lib offering 
 auto-completion and syntax
 hilighting data to clients.

 I'm doing some more work on premake (a nice light buildsystem 
 that
 generated makefiles and project files for popular IDE's) to 
 tightly
 incorporate D into the various IDE's it supports.

 </endrant>

I've hinted a few times here and on Reddit that I've been working on revamping/redoing CMake support for D. This project would have gone public almost a month ago if it weren't for the situation on Windows, but as it stands, I would only make it easier for new users to hit a brick wall when they try to do D development on Windows. I don't think that's very beneficial. To add to Manu's gripes: OMF vs COFF / optlink is ridiculous One of CMake's appeals is that it can check the system for needed libraries, and aid in linking to them. DMD32's need for OMF libraries throws an uncomfortable wrench into the situation, which I have yet to resolve to my satisfaction. VisualD generation was fairly straightforward. VS generation for mixed C/D projects is not something I'm even sure I can do (on Win32/DMD, that is), since to get VS to use a different C compiler (dmc), I need to make a VS config that defers to a makefile config. I'm not sure that CMake is set up to support this. I'm still working on it during my (ever-shrinking) free time, but it's pretty slow going.
Aug 31 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 We have to get the user experience and first impressions under 
 control...

 I'd really love to to see a general roadmap and list of 
 priorities. Even if
 goals are high-level, they might help direct focus?

 So I had another game-jam this weekend with a bunch of friends 
 who are all
 industry professionals.
 The point of a 48 hour game jam is to prioritise productivity 
 and
 creativity.
 Choosing a language like D here makes sense from a productivity 
 point of
 view... that is, if it 'JUST WORKS'™.

 There were 7 programmers, they were all using D for the first 
 time (except
 me).

 Most running windows, one on OSX, one on Linux.
 We ran into the same problems old that have been giving me the 
 shits as
 long as I've been using D.

 Configuring compilers:

 Naturally, this is primarily a problem with the windows 
 experience, but
 it's so frustrating that it is STILL a problem... how many 
 years later?
 People don't want to 'do work' to install a piece of software. 
 Rather, they
 expect it to 'just work'. We lost about 6 hours trying to get 
 everyone's
 machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! I 
 just kept
 promising people that it would save time overall... which I 
 wish were true.

 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the 
 stars aligned
 such that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various 
 versions of
 VisualStudio, and either 'just work', or amend sc.ini on its 
 own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a 
 user to fiddle
 with an ini file just isn't acceptable. We had to google 
 solutions to this
 problem, and even then, we had trouble with the paths we added 
 to sc.ini;
 are spaces acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), 
 libraries
 should be automatically detected and path entries added in 
 there too:
   C:\Program Files (x86)\Microsoft SDKs\...
   C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and 
 each of us had
 to configure them ourselves.


 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work 
 with a
 makefile. Everybody else wanted a comfortable IDE solution (and 
 the linux
 user would prefer it too).

 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a 
 massive point
 of it in his DConf talk, and I want to 
 re-re-re-re-re-re-re-stress how
 absolutely important this is.
 !!!!!!!!!

 I have come to the conclusion that treating IDE integration as 
 ancillary
 projects maintained by usually just one single member of the 
 community has
 absolutely failed.
 I suggest:
  * These should be made central D community projects.
  * I think they should be hosted in the same github 
 organisation as DMD.
  *** As many contributors as possible should be encouraged to 
 work with
 them every day.
    - Deprecate DMD makefiles. Seriously! Insist that 
 contributors use the
 IDE bindings to work on DMD.
    - The fact that you all laughed at the prior point suggests 
 clearly why
 it needs to be done. It will cease to be a problem when all the
 druntime/phobos contributors are suffering the end-user 
 experience.
  * They should receive bugs in the main github bug-tracker, so 
 EVERY D
 contributor can see them, and how many there are.

 IDE integration absolutely needs to be considered a first class 
 feature of
 D.
 I also suggest that the IDE integration downloads should be 
 hosted on the
 dlang download page so they are obvious and available to 
 everyone without
 having to go looking, and also as a statement that they are 
 actually
 endorsed by the dlanguage authorities. As an end-user, you're 
 not left
 guessing which ones are good/bad/out of date/actually work/etc.

 Obviously, we settled on Visual-D (Windows) and Mono-D 
 (OSX/Linux); the
 only realistic choices available. The OSX user would have 
 preferred an
 XCode integration.

 Overwhelmingly, the biggest complaint was a lack of symbolic 
 information to
 assist with auto-completion. Visual-D tries valiantly, but it 
 falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.
 I think continuous code compilation for auto-completion and 
 syntax
 highlighting purposes should be a service offered and 
 maintained by DMD.
 That way it will evolve with the language, and anyone can use 
 it without
 reinventing the wheel.


 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to 
 get OSX
 working); there are lots of problems with the debugging 
 experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing 
 bugs in
 random places when it was simply a case of the debugger lying 
 about the
 value of variables to them, and many more cases where the 
 debugger simply
 refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, 
 really burned
 us in a 48hour context.


 Documentation:

 Okay for the most part, but some windows dev's want a CHM that 
 looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.


 Containers:

 The question came up multiple times; "I don't think this should 
 be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
   foreach(i, item; array)
     if(item == itemToRemove)
       array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...


 Bugs:
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

 We also ran into some completely nonsense error messages, but I 
 forgot to
 log them, since we were working against the clock.


 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.


 Conclusion:
 I think this 48 hour jam approach is a good test for the 
 language and it's
 infrastructure. I encourage everybody to try it (ideally with a 
 clean slate
 computer).
 The lesson is that we need to make this process smooth, since 
 it mirrors
 the first-experience of everybody new to D.
 It also highlights and magnifies time-wasters that are equally 
 unacceptable
 in a commercial environment.

 I don't think I made any converts this weekend wrt the above 
 issues
 encountered. I might have even just proved to them that they 
 should indeed
 stick with C# (the IDE's work!)... :(

 Please, we need a road-map, we need to prioritise these most 
 basic aspects
 of the experience, and we need to do it soon.
 I might re-iterate my feeling that external IDE integration 
 projects should
 be claimed by the community officially, and user experience + 
 debugging
 issues should be first-class issues in the main d language 
 bug-tracker so
 everybody can see them, and everybody is aware of the stats.
 Also, the DMD front-end should be a lib offering 
 auto-completion and syntax
 hilighting data to clients.

 I'm doing some more work on premake (a nice light buildsystem 
 that
 generated makefiles and project files for popular IDE's) to 
 tightly
 incorporate D into the various IDE's it supports.

 </endrant>

Aug 31 2013
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-09-01 02:05:39 +0000, Manu <turkeyman gmail.com> said:

 I might re-iterate my feeling that external IDE integration projects should
 be claimed by the community officially

In my opinion the community is just too short on man-hours. I did integrate D with Xcode at one point (no autocompletion though) and created an all-in-one installer for the compiler and the Xcode plugin. It just worked. I don't maintain it anymore and Xcode 4 broke it. It's open source so anyone in the community could have taken it further, but so far this hasn't happened. I'm not using D anymore. I realized that with the time required to maintain the toolset (including installer and Xcode plugin) plus the time it'd take to make the language suitable to my needs (Objective-C integration, perhaps ARM support for iOS), all that by itself would probably be more than one full-time job. As all this meta-work would seriously get in the way of my actual work, I let it go. I'm not regretting that move. So I'm no longer using D, but I'm still hanging around here from time to time because there's always something interesting to read. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Aug 31 2013
prev sibling next sibling parent "Froglegs" <lugtug yahoo.com> writes:
  Yes IDE should be built with the language :)

D has bad IDE support that is why I read about D but don't 
actually use it...
Aug 31 2013
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
Sorry about the nonsensical reply, the web interface was acting 
up... this is the intended reply.

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.

Why didn't you go with DMD-Win32? Because of OMF? implib and/or objconv is a hassle but probably less of a hassle than using the nascent DMD-Win64.
 Overwhelmingly, the biggest complaint was a lack of symbolic 
 information to
 assist with auto-completion. Visual-D tries valiantly, but it 
 falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.

Although I'm not convinced auto-completion is a vital feature (Microsoft's C++ IntelliSense is shit too), I agree that any time spent on custom parsers and best-effort semantic analysis is a complete waste of time. The only semantic analysis engine that is going to be sufficiently good for D is one from a compiler front-end. Apart from DMD, it's worth taking a look at SDC for this.
 some windows dev's want a CHM that looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.

dmd2\windows\bin\d.chm
 The question came up multiple times; "I don't think this should 
 be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
   foreach(i, item; array)
     if(item == itemToRemove)
       array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...

`std.algorithm.remove` provides both stable (preserves order, shuffles entire array down) and unstable (swaps with last element and shrinks by one) removal. However, Phobos does not make a habit of providing helpers for strictly O(n) algorithms, so the O(n) nature has to be made explicit by first getting the index with `std.algorithm.countUntil`. Removing a pair from an AA by value is also an exercise in linear search, and as such will not get a deceptive helper function. However, once range interfaces for AAs mature, such an algorithm can be composed trivially.
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?
Aug 31 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 05:53, Jakob Ovrum wrote:

 Although I'm not convinced auto-completion is a vital feature
 (Microsoft's C++ IntelliSense is shit too)

That doesn't mean there aren't any IDE's out there with good support for autocompletion. The one in Eclipse for Java is fantastic. The one in Xcode 4+ for C/C++ and Objective-C/C++ is really good. I'm also quite amazed by JetBrains, they're spitting out IDE's like mad, with full language support for many types of languages. Even those that are usually very difficult, like dynamically typed languages. They fully support Ruby on Rails.
 I'm not sure this is a bug. How do you default initialize an array of
 structs you don't know the .init values of?

You're forced to explicitly initialize it. -- /Jacob Carlborg
Sep 01 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 12:43, deadalnix wrote:

 My understanding is that it uses libclang.

Yes, and it can see through macros, templates and everything. -- /Jacob Carlborg
Sep 01 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 12:21, Jakob Ovrum wrote:

 What do you mean? Please show some code how a declared but not defined
 struct can be initialized in any way, shape or form.

int[] a; // default initialized int[] b = [3, 4, 5]; // explicitly initialized -- /Jacob Carlborg
Sep 01 2013
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Sunday, 1 September 2013 at 03:17:29 UTC, Trent wrote:
 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 We have to get the user experience and first impressions under 
 control...

 I'd really love to to see a general roadmap and list of 
 priorities. Even if
 goals are high-level, they might help direct focus?

 So I had another game-jam this weekend with a bunch of friends 
 who are all
 industry professionals.
 The point of a 48 hour game jam is to prioritise productivity 
 and
 creativity.
 Choosing a language like D here makes sense from a 
 productivity point of
 view... that is, if it 'JUST WORKS'™.

 There were 7 programmers, they were all using D for the first 
 time (except
 me).

 Most running windows, one on OSX, one on Linux.
 We ran into the same problems old that have been giving me the 
 shits as
 long as I've been using D.

 Configuring compilers:

 Naturally, this is primarily a problem with the windows 
 experience, but
 it's so frustrating that it is STILL a problem... how many 
 years later?
 People don't want to 'do work' to install a piece of software. 
 Rather, they
 expect it to 'just work'. We lost about 6 hours trying to get 
 everyone's
 machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! 
 I just kept
 promising people that it would save time overall... which I 
 wish were true.

 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the 
 stars aligned
 such that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of 
 various versions of
 VisualStudio, and either 'just work', or amend sc.ini on its 
 own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a 
 user to fiddle
 with an ini file just isn't acceptable. We had to google 
 solutions to this
 problem, and even then, we had trouble with the paths we added 
 to sc.ini;
 are spaces acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), 
 libraries
 should be automatically detected and path entries added in 
 there too:
  C:\Program Files (x86)\Microsoft SDKs\...
  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and 
 each of us had
 to configure them ourselves.


 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work 
 with a
 makefile. Everybody else wanted a comfortable IDE solution 
 (and the linux
 user would prefer it too).

 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a 
 massive point
 of it in his DConf talk, and I want to 
 re-re-re-re-re-re-re-stress how
 absolutely important this is.
 !!!!!!!!!

 I have come to the conclusion that treating IDE integration as 
 ancillary
 projects maintained by usually just one single member of the 
 community has
 absolutely failed.
 I suggest:
 * These should be made central D community projects.
 * I think they should be hosted in the same github 
 organisation as DMD.
 *** As many contributors as possible should be encouraged to 
 work with
 them every day.
   - Deprecate DMD makefiles. Seriously! Insist that 
 contributors use the
 IDE bindings to work on DMD.
   - The fact that you all laughed at the prior point suggests 
 clearly why
 it needs to be done. It will cease to be a problem when all the
 druntime/phobos contributors are suffering the end-user 
 experience.
 * They should receive bugs in the main github bug-tracker, so 
 EVERY D
 contributor can see them, and how many there are.

 IDE integration absolutely needs to be considered a first 
 class feature of
 D.
 I also suggest that the IDE integration downloads should be 
 hosted on the
 dlang download page so they are obvious and available to 
 everyone without
 having to go looking, and also as a statement that they are 
 actually
 endorsed by the dlanguage authorities. As an end-user, you're 
 not left
 guessing which ones are good/bad/out of date/actually work/etc.

 Obviously, we settled on Visual-D (Windows) and Mono-D 
 (OSX/Linux); the
 only realistic choices available. The OSX user would have 
 preferred an
 XCode integration.

 Overwhelmingly, the biggest complaint was a lack of symbolic 
 information to
 assist with auto-completion. Visual-D tries valiantly, but it 
 falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.
 I think continuous code compilation for auto-completion and 
 syntax
 highlighting purposes should be a service offered and 
 maintained by DMD.
 That way it will evolve with the language, and anyone can use 
 it without
 reinventing the wheel.


 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed 
 to get OSX
 working); there are lots of problems with the debugging 
 experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing 
 bugs in
 random places when it was simply a case of the debugger lying 
 about the
 value of variables to them, and many more cases where the 
 debugger simply
 refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, 
 really burned
 us in a 48hour context.


 Documentation:

 Okay for the most part, but some windows dev's want a CHM that 
 looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.


 Containers:

 The question came up multiple times; "I don't think this 
 should be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
  foreach(i, item; array)
    if(item == itemToRemove)
      array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...


 Bugs:
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
  struct MyStruct;
  MyStruct*[] = new MyStruct*[n];

 We also ran into some completely nonsense error messages, but 
 I forgot to
 log them, since we were working against the clock.


 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
  class MyClass
  {
    void method();
  }

  void MyClass.method()
  {
    //...
  }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.


 Conclusion:
 I think this 48 hour jam approach is a good test for the 
 language and it's
 infrastructure. I encourage everybody to try it (ideally with 
 a clean slate
 computer).
 The lesson is that we need to make this process smooth, since 
 it mirrors
 the first-experience of everybody new to D.
 It also highlights and magnifies time-wasters that are equally 
 unacceptable
 in a commercial environment.

 I don't think I made any converts this weekend wrt the above 
 issues
 encountered. I might have even just proved to them that they 
 should indeed
 stick with C# (the IDE's work!)... :(

 Please, we need a road-map, we need to prioritise these most 
 basic aspects
 of the experience, and we need to do it soon.
 I might re-iterate my feeling that external IDE integration 
 projects should
 be claimed by the community officially, and user experience + 
 debugging
 issues should be first-class issues in the main d language 
 bug-tracker so
 everybody can see them, and everybody is aware of the stats.
 Also, the DMD front-end should be a lib offering 
 auto-completion and syntax
 hilighting data to clients.

 I'm doing some more work on premake (a nice light buildsystem 
 that
 generated makefiles and project files for popular IDE's) to 
 tightly
 incorporate D into the various IDE's it supports.

 </endrant>

I've hinted a few times here and on Reddit that I've been working on revamping/redoing CMake support for D. This project would have gone public almost a month ago if it weren't for the situation on Windows, but as it stands, I would only make it easier for new users to hit a brick wall when they try to do D development on Windows. I don't think that's very beneficial. To add to Manu's gripes: OMF vs COFF / optlink is ridiculous One of CMake's appeals is that it can check the system for needed libraries, and aid in linking to them. DMD32's need for OMF libraries throws an uncomfortable wrench into the situation, which I have yet to resolve to my satisfaction. VisualD generation was fairly straightforward. VS generation for mixed C/D projects is not something I'm even sure I can do (on Win32/DMD, that is), since to get VS to use a different C compiler (dmc), I need to make a VS config that defers to a makefile config. I'm not sure that CMake is set up to support this. I'm still working on it during my (ever-shrinking) free time, but it's pretty slow going.

I also would love to see Microsoft's linker support for Win32 added. Although not as a replacement for Optlink. More as an option that can be enabled. So maybe at the same time a rethink of PE-COFF support should be in order? We could also fix the paths issue at the same time. About the whole IDE thing my target for DOOGLE[1] is to eventually be able to build an IDE out of it. Possibly even a full windowing environment. Because honestly we need one fully written in D (IDE). [1] https://github.com/rikkimax/DOOGLE
Aug 31 2013
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the 
 stars aligned
 such that it would actually compile and find the linker+libs.

I also spent a decent bit of effort getting Win64 to work, and I agree that this is something that DMD should attempt to bundle. It may not need to go as far as downloading VC express for you, but it should allow integration of an existing install during installation (and ideally post-installation as well). This is a pretty big deal IMO. When I was a newbie, issues with COFF vs OMF, coffimplib confusion, etc, were almost deal-breakers to me. I just couldn't get things easily working, and I'm sure many others see it the same way. Having Win64 gives us a chance to fix that, but it *has* to be integrated into the installer. The compiler should ideally detect that the VS linker / libraries are missing when you use -m64, and tell you how to download VS Express as well as directing you to a batch file bundled with DMD to update sc.ini. Going a step further, it'd be even nicer if -m64 was default but that's not feasible with external dependencies. However when it detects a library in an invalid format, it should inform you about the existence of coffimplib and a download link, as well as how this is necessary only when compiling 32-bit executables. I don't think that the core contributors realize how incredibly frustrating these issues are to beginners, and thus feel as if it's not something that needs to be solved.
 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work 
 with a
 makefile. Everybody else wanted a comfortable IDE solution (and 
 the linux
 user would prefer it too).

 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a 
 massive point
 of it in his DConf talk, and I want to 
 re-re-re-re-re-re-re-stress how
 absolutely important this is.
 !!!!!!!!!

I have to say, I don't see why you find this to be such a large issue. DMD is unique in the sense that it's the only thing I've ever been able to compile on Windows without running into many issues. So long as you have DMC installed, it just works. I've never had any makefile related issues on any platform. This is a big deal, as DMD evolves so rapidly that users should be able to get the git version with minimal effort, without having to download an IDE for it.
 Overwhelmingly, the biggest complaint was a lack of symbolic 
 information to
 assist with auto-completion. Visual-D tries valiantly, but it 
 falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.
 I think continuous code compilation for auto-completion and 
 syntax
 highlighting purposes should be a service offered and 
 maintained by DMD.
 That way it will evolve with the language, and anyone can use 
 it without
 reinventing the wheel.

While yes, it would be wonderful if we could get DMD to do this (again, I don't think a lot of the core contributors realize just how incredibly important IDEs and perfect auto-completion are), it doesn't seem to be something likely in the short-term. That being said, I've actually found Mono-D to be excellent recently. It doesn't handle things like CTFE properly and other similar issues, but for my purposes it's worked rather well (that being said, I avoid mixins for the most part, largely due to this). Despite all this, I'm actually quite happy with Mono-D lately. One thing I've toyed with is the idea of using reflection for getting auto-complete information. I made a runtime reflection module (has a fair few issues still), and I wonder if it would be possible to use something similar for this purpose. Most modules could be cached, allowing us to build only the module you're altering. On top of that, some real-time parsing could be done for code modified since the last recompile (really it would need to primarily handle scanning for methods and variables). History completion from the current file, such as what editors like Sublime Text do, could perhaps be integrated to completely eliminate the issue of not being able to find a symbol in your auto-complete list. That would likely only kick in when it finds no results for anything else. Plus since you're recompiling frequently in the background, you would get early notifications of errors/warnings like you would in C#/Java. Ultimately though, I'm not sure if this would be updated fast enough (depends how long compiles take) to be feasible.
 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to 
 get OSX
 working); there are lots of problems with the debugging 
 experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing 
 bugs in
 random places when it was simply a case of the debugger lying 
 about the
 value of variables to them, and many more cases where the 
 debugger simply
 refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, 
 really burned
 us in a 48hour context.

Agreed, debugging is currently lacking thoroughly. Using Linux, Mono-D's works okay but it still jumps around a lot (even in debug mode) and hovering over variables isn't great yet. I really miss the Immediate Window from C# / Visual Studio, and it would be nice to have that. This is something that runtime reflection could handle.
 Containers:

 The question came up multiple times; "I don't think this should 
 be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
   foreach(i, item; array)
     if(item == itemToRemove)
       array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...

Completely agreed. Containers are another huge problem which needs to be solved as soon as possible, yet is constantly getting pushed back. The idea that a language like D doesn't even have anything but the most basic containers in it's standard library is laughable. I shudder to think at how many different implementations exist of common containers right now in user code.
 Bugs:
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

 We also ran into some completely nonsense error messages, but I 
 forgot to
 log them, since we were working against the clock.

I used to hit compiler bugs very frequently, yet this is something that D has improved incredibly on. It's wonderful to not have to worry with every compile if there will be bugs. It's also wonderful to not have to worry about changing your code with every single compiler release. D has made *huge* headway in these two issues. Sure, there are still many bugs, but they're becoming less frequent for me and I find that workarounds are easier than before.
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?
Aug 31 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 9:15 PM, Manu wrote:
 Well you can look at Remedy's experience. I've also sparked interest in staff
 from a few other companies when talking to developers.
 It'll never fly though if when they go to try it out, they're met with the kind
 of experience I had on the weekend.
 Don't underestimate how much people hate C++ these days.

Your work is really valuable to D. Please make sure all the problems you encountered wind up as bugzilla entries!
Sep 01 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 20:36, SomeDude wrote:

 Well, the fact is, AFAIK, it's never been an issue for C# and Java
 programmers. In fact, it' the first time I hear about people complaining
 on this one. Maybe because of the generalized usage of IDEs, I guess.

As far as I know C/C++ and Objective-C/C++ are the only languages that can do this.
 I think at this point, what D needs is a bit of commercial support from
 a company like JetBrains or some equivalent.

I'm wondering what tools or tricks they have up there selves to be able to produce so many IDE's for so many different languages. Hey, in RubyMine they basically add a new language with every new version of the IDE: * Ruby on Rails * Haml * HTML * CSS * Sass * CoffeeScript * JavaScript And so on. -- /Jacob Carlborg
Sep 02 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 21:44, Brian Schott wrote:

 It's a bit of a chicken-and-egg problem. I'd like to do this, but there
 would have to be several companies already using D professionally for it
 to be a viable business model. And for a company to invest in D, they'd
 probably want the tooling to already exist.

I would like that as well. But I feel the same things. Are there any customers? -- /Jacob Carlborg
Sep 02 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-02 19:54, Dicebot wrote:

 There is crucial difference between having a company providing
 commercial services for D users (good) and having anything
 closed/commercial in reference implementation (bad). Former is simply
 matching the demand from certain market segment. Latter is screwing the
 life for everyone else. There is hardly anything common here.

Yes, I agree. I think the tools, or most of the tools, need to be free. Then they need to make money on other things as support, education or similar. -- /Jacob Carlborg
Sep 02 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/03/2013 06:33 PM, Joakim wrote:
 Thinking something is obvious so doesn't need to be demonstrated is
 another common traits amongst zealots.

Sure, but I did provide demonstration, that thread.

That thread seems to demonstrate a failure of communication.
 The OSS zealots
 repeatedly make arguments that are wrong, irrelevant, and worst, just
 completely out of left field.  This is a common pathology when you have
 decided on your conclusion and are arguing backwards from it: your
 arguments don't make any sense and come out of left field.

 They have decided that open source is good and closed source is bad,
 just like the global warming zealots, and will make silly arguments to
 try and justify that, even to someone like me who is trying to carve out
 a place for open source.  You may agree with their conclusion and
 therefore defend their arguments, but any impartial observer wouldn't.

"Any" impartial observer would notice the personal attacks, even if that observer was completely ignorant of the discussion topic. "Any" impartial observer would interpret those as lack of a well-reasoned argument and decide to spend his time impartially observing something more interesting.
Sep 03 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/04/2013 11:26 AM, Joakim wrote:
 On Tuesday, 3 September 2013 at 21:34:42 UTC, Timon Gehr wrote:
 On 09/03/2013 06:33 PM, Joakim wrote:
 Sure, but I did provide demonstration, that thread.

That thread seems to demonstrate a failure of communication.

By whom? [...]

When communication fails, there is usually not a single side responsible for it. (Unless one side is trolling. Trolls are typically anonymous.)
 They have decided that open source is good and closed source is bad,
 just like the global warming zealots, and will make silly arguments to
 try and justify that, even to someone like me who is trying to carve out
 a place for open source.  You may agree with their conclusion and
 therefore defend their arguments, but any impartial observer wouldn't.

"Any" impartial observer would notice the personal attacks, even if that observer was completely ignorant of the discussion topic. "Any" impartial observer would interpret those as lack of a well-reasoned argument and decide to spend his time impartially observing something more interesting.

I call it like I see it.

Great.
 An impartial observer can determine if what
 you call "personal attacks," more like labeling of the usually silly or
 wrong tenor of their arguments
 and what kind of person generally makes such dumb arguments, are accurate.

How? Accuracy of conclusions of fallacious reasoning is mostly incidental. Consider googling "ad hominem", "association fallacy" and "fallacy of irrelevance".
 If you want to take a long thread full of arguments about the topic
 and pick out a little name-calling
 and then run away, clearly the argument is lost on you.

Frankly, I'm unimpressed. It's you who picked out the name-calling instead of arguments when summarizing the past discussion. In case any valuable arguments were part of that discussion then I'd advise to pick out those instead and put them in a coherent form.
 On Wednesday, 4 September 2013 at 00:25:30 UTC, deadalnix wrote:
 On Tuesday, 3 September 2013 at 16:33:55 UTC, Joakim wrote:
 Sure, but I did provide demonstration, that thread.  The OSS zealots
 repeatedly make arguments that are wrong, irrelevant, and worst, just
 completely out of left field.  This is a common pathology when you
 have decided on your conclusion and are arguing backwards from it:
 your arguments don't make any sense and come out of left field.

 They have decided that open source is good and closed source is bad,
 just like the global warming zealots, and will make silly arguments
 to try and justify that, even to someone like me who is trying to
 carve out a place for open source.  You may agree with their
 conclusion and therefore defend their arguments, but any impartial
 observer wouldn't.

You seem confused by the difference between saying something and providing conclusive evidence.

That thread _is_ conclusive evidence. If you think otherwise, you are deeply confused.

(Please do not mess up the threading.) Well, if this kind of simply-minded pseudo-reasoning is to find resonance, it has to be targeted at a less critical audience.
Sep 04 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/04/2013 08:00 PM, Joakim wrote:
 On Wednesday, 4 September 2013 at 13:23:19 UTC, Timon Gehr wrote:
 On 09/04/2013 11:26 AM, Joakim wrote:
 On Tuesday, 3 September 2013 at 21:34:42 UTC, Timon Gehr wrote:
 On 09/03/2013 06:33 PM, Joakim wrote:
 Sure, but I did provide demonstration, that thread.

That thread seems to demonstrate a failure of communication.

By whom? [...]

When communication fails, there is usually not a single side responsible for it. (Unless one side is trolling. Trolls are typically anonymous.)

Except that trolling has nothing to do with communication failure

Good trolling is often _indistinguishable_ from communication failure.
 ...

 "Any" impartial observer would notice the personal attacks, even if
 that observer was completely ignorant of the discussion topic. "Any"
 impartial observer would interpret those as lack of a well-reasoned
 argument and decide to spend his time impartially observing something
 more interesting.

I call it like I see it.

Great.

Except that you then criticize me

I don't criticize people, I question arguments. If you think these two things should be conflated, I beg you to reconsider.
 for "personal attacks" and name-calling, [...]
 ...

There are multiple possibilities to replace the above statement in a way I would disapprove of, eg: - "I call it like I don't see it." - "I state inevitable fact."
 An impartial observer can determine if what
 you call "personal attacks," more like labeling of the usually silly or
 wrong tenor of their arguments
 and what kind of person generally makes such dumb arguments, are
 accurate.

How? Accuracy of conclusions of fallacious reasoning is mostly incidental. Consider googling "ad hominem", "association fallacy" and "fallacy of irrelevance".

[...] what "incidental" means. :)

It means: "Occurring by chance in connection with something else." A possible reason informal reasoning makes use of heuristics is that they often work by chance in some evolutionary relevant contexts.
 [...]they make several statements that are just factually
 wrong, [...]

IIRC you more or less successfully debunk some factually wrong statements. Not all of them were actually made, though.
 If you [...] don't [...] know the facts, there can be no discussion,

One of the points of a discussion is to exchange facts and to widen one's understanding of different viewpoints.
 which is why I bailed on that thread.
 ...

There are less intrusive ways of doing that.
 If you want to take a long thread full of arguments about the topic
 and pick out a little name-calling
 and then run away, clearly the argument is lost on you.

Frankly, I'm unimpressed. It's you who picked out the name-calling instead of arguments when summarizing the past discussion. In case any valuable arguments were part of that discussion then I'd advise to pick out those instead and put them in a coherent form.

I called them what they are,

As I see it it is irrelevant in a discussion how anyone may classify anyone else taking part in that discussion. It is often even irrelevant who those people are. I'm just saying that if the goal is to make one's reasoning and opinions available to a potential reader, making it inconvenient to read and seemingly irrelevant is not the way to go.
 [...] which isn't really name-calling
 but an accurate description,

:o)
 and noted one of their main [...] arguments,
  so I did both.

No point can be made by noting that one hasn't made a specific fallacious argument or by noting that somebody has defended another point poorly.
 [...]
 On Wednesday, 4 September 2013 at 00:25:30 UTC, deadalnix wrote:
 You seem confused by the difference between saying something and
 providing conclusive evidence.

That thread _is_ conclusive evidence. [...]

(Please do not mess up the threading.)

 Well, if this kind of simply-minded pseudo-reasoning is to find
 resonance, it has to be targeted at a less critical audience.

Except there was little reasoning in my above two sentences, only two statements about the other thread.

Exactly. (Or rather, one statement about the other thread and one irrelevant statement about a community member.) So a point of contention appears to be that some assume that evidence should be given in the form of reasoning or at least be accompanied by reasoning, whereas others don't?
 [...] I'll leave this "meta-discussion" here, as you two are clearly
 incapable of dealing with

Typically the ones incapable of dealing with something leave.
 my actual arguments.

What actual arguments are there? ("Go look for them yourself." is not a valid answer.)
Sep 04 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 22:27, Nick Sabalausky wrote:

 I spent several years using C/C++ exclusively (and was happy with it
 at the time) and I still don't understand what's "readable" about having
 a class's members separate from the class itself. It's also a non-DRY
 maintenance PITA and one of the biggest reasons I left C/C++.

You cannot even copy-paste the signature. In C++ default values for parameters can only be at one place. -- /Jacob Carlborg
Sep 02 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2013 7:05 PM, Manu wrote:
 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the stars aligned such
 that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various versions of
 VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a user to fiddle
with
 an ini file just isn't acceptable. We had to google solutions to this problem,
 and even then, we had trouble with the paths we added to sc.ini; are spaces
 acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), libraries should
 be automatically detected and path entries added in there too:
    C:\Program Files (x86)\Microsoft SDKs\...
    C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and each of us had to
 configure them ourselves.

The default sc.ini contains: ----------------------------- [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib";\dm\lib DFLAGS="-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe VCINSTALLDIR=%VCINSTALLDIR% WindowsSdkDir=%WindowsSdkDir% ---------------------------------- When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work". What went wrong, specifically?
Sep 01 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Sep-2013 11:42, Walter Bright пишет:
 On 8/31/2013 7:05 PM, Manu wrote:

 The default sc.ini contains:
 -----------------------------
 [Version]
 version=7.51 Build 020

 [Environment]
 LIB="% P%\..\lib";\dm\lib
 DFLAGS="-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import"
 LINKCMD=% P%\link.exe
 LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe
 VCINSTALLDIR=%VCINSTALLDIR%
 WindowsSdkDir=%WindowsSdkDir%
 ----------------------------------

 When I installed VC 2010, it set the environment variables VCINSTALLDIR
 and WindowsSdkDir. Then, the default sc.ini should "just work".

 What went wrong, specifically?

This is hopeless. It should try to detect many versions. As different versions have different folder structures. To get it to work with say VS11 I had to kill VCINSTALLDIR & WindowsSDKDir and set LIB/LINKCMD paths by hand in Environement64. Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with VC11/WinSDK8. -- Dmitry Olshansky
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:
 To get it to work with say VS11 I had to kill VCINSTALLDIR & WindowsSDKDir and
 set LIB/LINKCMD paths by hand in Environement64.
 Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
 VC11/WinSDK8.

What environment variables did VS11 set?
Sep 01 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Sep-2013 21:24, Walter Bright пишет:
 On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:
 To get it to work with say VS11 I had to kill VCINSTALLDIR &
 WindowsSDKDir and
 set LIB/LINKCMD paths by hand in Environement64.
 Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
 VC11/WinSDK8.

What environment variables did VS11 set?

The only one I see is VS110COMNTOOLS that was defined to C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\ What currently works for me is: [Environment64] PATH=C:\"Program Files (x86)"\"Microsoft Visual Studio 11.0"\Common7\IDE;%PATH% LIB=C:\"Program Files (x86)"\"Windows Kits"\8.0\Lib\win8\um\x64;C:\"Program Files (x86)"\"Microsoft Visual Studio 11.0"\VC\lib\amd64;"% P%\..\lib" WindowsSdkDir= LINKCMD64=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\link.exe There are 2 distinct things - libraries are ound in Platform SDK (or rather WindowsSDK these days) and version 8 differs from 7. You can download and install it (any version) - it's a free download. Compiler/linkers are installed to VisualStudio and are dealt with separately. I still have this error when trying to comompile with debug info: LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck installation of this product No idea whose fault is it (DMD vs MS linker vs something in my paths/env). + I have to redefine everything in order to compile phobos/druntime as these are hardcoded to VS10 (again !) thus I don't usually test/build x64 Phobos. It's far less hassle for me to keep around x64 Linux virtual box for testing. -- Dmitry Olshansky
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
 The only one I see is
 VS110COMNTOOLS

Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.
 that was defined to
 C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\

 What currently works for me is:
 [Environment64]
 PATH=C:\"Program Files (x86)"\"Microsoft Visual Studio 11.0"\Common7\IDE;%PATH%
 LIB=C:\"Program Files (x86)"\"Windows Kits"\8.0\Lib\win8\um\x64;C:\"Program
 Files (x86)"\"Microsoft Visual Studio 11.0"\VC\lib\amd64;"% P%\..\lib"
 WindowsSdkDir=
 LINKCMD64=C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\amd64\link.exe

I'm quite sure that VS20?? sets an environment variable for "Windows Kits" somewhere.
 There are 2 distinct things - libraries are ound in Platform SDK (or rather
 WindowsSDK these days) and version 8 differs from 7. You can download and
 install it (any version) - it's a free download.
 Compiler/linkers are installed to VisualStudio and are dealt with separately.

 I still have this error when trying to comompile with debug info:

 LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
installation
 of this product

 No idea whose fault is it (DMD vs MS linker vs something in my paths/env).

DMD does not load any DLLs.
 + I have to redefine everything in order to compile phobos/druntime as these
are
 hardcoded to VS10 (again !) thus I don't usually test/build x64 Phobos. It's
far
 less hassle for me to keep around x64 Linux virtual box for testing.

When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak. -------------- # Makefile to build D runtime library phobos.lib for Win32 # Designed to work with \dm\bin\make.exe DIR=\dmd2 #DMD=$(DIR)\windows\bin\dmd DMD=..\dmd #DOC=..\..\html\d\phobos DOC=..\doc\phobos STDDOC=std.ddoc DRUNTIME=..\druntime MODEL=32 MACS=DMD=$(DMD) DOC=$(DOC) STDDOC=$(STDDOC) DIR=$(DIR) DRUNTIME=$(DRUNTIME) targets : make -fwin$(MODEL).mak $(MACS) test : make -fwin$(MODEL).mak $(MACS) test unittest : make -fwin$(MODEL).mak $(MACS) unittest cov : make -fwin$(MODEL).mak $(MACS) cov clean : make -fwin$(MODEL).mak $(MACS) clean html : make -fwin$(MODEL).mak $(MACS) html cleanhtml: make -fwin$(MODEL).mak $(MACS) cleanhtml zip : make -fwin$(MODEL).mak $(MACS) zip install : make -fwin$(MODEL).mak $(MACS) install cov : make -fwin$(MODEL).mak $(MACS) cov time : make -fwin$(MODEL).mak $(MACS) clean timer make -fwin$(MODEL).mak $(MACS)
Sep 01 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Sep-2013 22:44, Walter Bright пишет:
 On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
 The only one I see is
 VS110COMNTOOLS

Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.

Ah, that command prompt... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\ WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\ However the said windows kit folder has tree like this: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,amd64} That 'win8\um' sub-folder is what must be throwing it off. It's nothing like that in Win7 SDK.
 There are 2 distinct things - libraries are ound in Platform SDK (or
 rather
 WindowsSDK these days) and version 8 differs from 7. You can download and
 install it (any version) - it's a free download.
 Compiler/linkers are installed to VisualStudio and are dealt with
 separately.

 I still have this error when trying to comompile with debug info:

 LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
 installation
 of this product

 No idea whose fault is it (DMD vs MS linker vs something in my
 paths/env).

DMD does not load any DLLs.

Okay, then it could very well be just me messing with paths/env. OT: MS x64 compiler too could be had for free (it come with SDK I installed not VS express)
 + I have to redefine everything in order to compile phobos/druntime as
 these are
 hardcoded to VS10 (again !) thus I don't usually test/build x64
 Phobos. It's far
 less hassle for me to keep around x64 Linux virtual box for testing.

When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak. -------------- # Makefile to build D runtime library phobos.lib for Win32 # Designed to work with \dm\bin\make.exe

Thanks! I could borrow that. With that said I don't quite like Makefiles at all. -- Dmitry Olshansky
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 11:58 AM, Dmitry Olshansky wrote:
 01-Sep-2013 22:44, Walter Bright пишет:
 On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
 The only one I see is
 VS110COMNTOOLS

Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.

Ah, that command prompt... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\ WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\ However the said windows kit folder has tree like this: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,amd64} That 'win8\um' sub-folder is what must be throwing it off. It's nothing like that in Win7 SDK.
 There are 2 distinct things - libraries are ound in Platform SDK (or
 rather
 WindowsSDK these days) and version 8 differs from 7. You can download and
 install it (any version) - it's a free download.
 Compiler/linkers are installed to VisualStudio and are dealt with
 separately.

 I still have this error when trying to comompile with debug info:

 LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
 installation
 of this product

 No idea whose fault is it (DMD vs MS linker vs something in my
 paths/env).

DMD does not load any DLLs.

Okay, then it could very well be just me messing with paths/env. OT: MS x64 compiler too could be had for free (it come with SDK I installed not VS express)
 + I have to redefine everything in order to compile phobos/druntime as
 these are
 hardcoded to VS10 (again !) thus I don't usually test/build x64
 Phobos. It's far
 less hassle for me to keep around x64 Linux virtual box for testing.

When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak. -------------- # Makefile to build D runtime library phobos.lib for Win32 # Designed to work with \dm\bin\make.exe

Thanks! I could borrow that. With that said I don't quite like Makefiles at all.

I think the most practical thing at the moment is to: 1. put comments in sc.ini explaining it better 2. replace the hardcoded tails that link.c appends to the sc.ini values with new settings in sc.ini 3. provide commented-out example settings for each variant of VS as we discover what they should be
Sep 01 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:
 I know you seem to hate automation (because it sometimes fails), but
 having each individual person waste hours on initial setup is much
 worse than having a script which can potentially fail. At least the
 script can be fixed once the bug is reported, and it can be tested.

Back in the bad old Datalight C days, I relied on the Microsoft linker which came on the DOS system disks. Unfortunately, Microsoft constantly changed it, even with the same version of DOS. Worse, numerous other Microsoft products came with yet other versions of LINK.EXE. All those linkers behaved differently. It was a frackin' nightmare to support customers with them. I used to have floppy disks packed full of just different versions of LINK.EXE. This drove me to get our own linker (BLINK.EXE). While it wasn't perfect, either, at least I could actually fix problems with it rather than throwing up my hands in rage being unable to control the situation. There's no way we can automate VC 2014 so its unpredictable configuration will work. All we can do is react after the fact. I don't hate automation. sc.ini works out of the box with the default install of VS 2010. What I need from you guys and your different VS installs is, for each one, a bug report with what is necessary to get it installed. Then we can add it to the modern version of my floppy disk "linker collection".
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:
 On 9/1/13, Brad Anderson <eco gnuk.net> wrote:
 What I need from you guys and your different VS installs is,
 for each one, a bug report with what is necessary to get it
 installed. Then we can add it to the modern version of my
 floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)

Pull requests are, of course, welcome.
Sep 01 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 6:41 PM, Brad Anderson wrote:
 On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright wrote:
 Pull requests are, of course, welcome.

https://github.com/D-Programming-Language/installer/pull/22

It's just like ordering pizza!!! Brad, you Da Man!
Sep 01 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 10:01 PM, Manu wrote:
 How about the DirectX SDK?
 http://www.microsoft.com/en-us/download/details.aspx?id=6812
 It's super standard aswell for anyone working on multimedia software.
 It has an environment variable on my machine: DXSDK_DIR = C:\Program Files
 (x86)\Microsoft DirectX SDK (June 2010)\

How about: LIBPATH64=%VCINSTALLDIR%lib\amd64;%WindowsSdkDir%lib\x64;%DXSDK_DIR% in your sc.ini?
Sep 01 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 12:21 PM, Walter Bright wrote:
 2. replace the hardcoded tails that link.c appends to the sc.ini values with
new
 settings in sc.ini

https://github.com/D-Programming-Language/dmd/pull/2509
Sep 01 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 2:46 AM, Simen Kjaeraas wrote:
 Like Dmitry said, it might work for 2010, but it certainly does not 'just
 work' for 2012 and 2013. I've probably spent twelve hours setting up DMD
 Win64 on my two confusers.

I need specifics. Again, what environment variables are setup by these other VS's? What did you put in your sc.ini? I don't have multiple VS installs.
Sep 01 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 6:19 AM, Manu wrote:
 Hmmm, I found details on the net that recommended adding an [Environment64]
 section, which we did.

 I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on my system :/ ..
 that said, VC obviously works on my machine.

Sorry if I am being repetitive here, but what environment variables is VS setting on your machine?
 It also seems potentially problematic that a variable would define a single
 install directory, since it's pretty common that programmers have multiple
 versions of VS on their machines.
 I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.

Yes, so what environment variables should sc.ini use to determine which one the user wants to use for dmd?
 I was also thinking it might be a mistake to keep phobos64.lib in the same
 folder as the 32bit omf libs. If paths are wrong, the link errors will only be
 understood by a programmer who understands compilers and lib/object formats in
 depth.
 Perhaps you should put them in a parallel lib64 directory, and hook that up in
 [Environment64] (I did that on my machine while trying to isolate problems and
 wort out where paths were coming from)?

Please, I need specifics.
 I reckon you should look into hooking up DirectX SDK patahing by default too
 since it's so common for basically any multimedia app.

I have no idea what you mean by this?
Sep 01 2013
parent Mike Parker <aldacron gmail.com> writes:
On 9/2/2013 11:54 AM, Manu wrote:
 DirectX, Microsoft's multimedia API?
 http://www.microsoft.com/en-us/download/details.aspx?id=6812
 It installs bunches of libs in their own directory, I think you should
 include them in sc.ini by default.

 DirectX does appear to have an environment variable on my machine:
    DXSDK_DIR = C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\

 So if you map: %DXSDK_DIR%Lib\x64 that will make the libs available.

MS has stopped making new versions of the DirectX SDK. Everything now ships as part of the Windows SDK. See http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx
Sep 02 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
As a followup,

When I installed VS2010, it created a shortcut on my desktop labelled "Visual 
Studio x64 Win64 ...". Clicking on that opened a command line window.

In that window, I could compile and run VC programs from the command prompt 
using CL, LINK, etc.

In that window, if I typed:

SET

at the prompt, it showed the environment variables set, which included:

VCINSTALLDIR - where VC was installed
WindowsSdkDir - where the SDK was installed

This is all dmd needs in order to use VS2010.

However, I didn't want to have to click on that shortcut just to use -m64, so I 
merely copied the values VCINSTALLDIR and WindowsSdkDir into my own personal 
sc.ini, and then dmd -m64 worked fine.
Sep 01 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 12:28 PM, Brad Anderson wrote:
 I can make the installer detect which versions of Visual Studio are installed
 and the path they are installed.  Would I rather I have the installer modify
the
 installed sc.ini or set an environment variable?

dmd is specifically made to not rely on us setting any environment or system registry variables. So modifying sc.ini is the only solution.
Sep 01 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 01 Sep 2013 06:45:48 +0200
"Kapps" <opantm2+spam gmail.com> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

I see it as the job of doc generators.
Sep 01 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 01.09.2013 04:05, schrieb Manu:
 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a massive
 point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
 how absolutely important this is.
 !!!!!!!!!

I have to fully agree here.
 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to get OSX
 working); there are lots of problems with the debugging experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing bugs in
 random places when it was simply a case of the debugger lying about the
 value of variables to them, and many more cases where the debugger
 simply refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, really
 burned us in a 48hour context.

Actually there is only one little patch needed to make debugging work nicely with the visual studio c++ debugger. It replaces all '.' chars with ' ' in type names inside the debug information. There was a pull request from Rainer Schuetze once, but it got rejected by Walter. https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f938a2ee3a2d6be124 Also if you are using Visual Studio 2012, you need to change the debugging engine because the new one can't deal with D code that has C++ debugging info. For that go to Options -> Debugging -> Edit and Continue -> Enable Edit and Continue (this will make Visual Studio 2012 use the old debugging engine). Then everything will work nicely. The only real issue is, that the debugger can't identify which class is behind a given interface. Also you should try using mago, it can be enabled inside the visualD debugging options of your project. It even features D expression evaluation, but it only works for 32-bit (but requires not cv2pdb conversion).
 Containers:

 The question came up multiple times; "I don't think this should be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item from an
 array, or an item from an AA by reference/value (only by key).

 This code:
    foreach(i, item; array)
      if(item == itemToRemove)
        array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it lightly...

Oh containers, I would love to have some. Like every one else using D I've written my own by now.
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to navigate
 (like Java and C#).
 We all wanted to ability to define class member functions outside the
 class definition:
    class MyClass
    {
      void method();
    }

    void MyClass.method()
    {
      //...
    }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want to quickly see what a class has and does.

You should really use VisualD's ability to parse the AST .json files dmd generates while compiling. Using this feature you get a really awesome class view and even "Go to defintion" works.
 Conclusion:
 I think this 48 hour jam approach is a good test for the language and
 it's infrastructure. I encourage everybody to try it (ideally with a
 clean slate computer).
 The lesson is that we need to make this process smooth, since it mirrors
 the first-experience of everybody new to D.
 It also highlights and magnifies time-wasters that are equally
 unacceptable in a commercial environment.

 I don't think I made any converts this weekend wrt the above issues
 encountered. I might have even just proved to them that they should
 indeed stick with C# (the IDE's work!)... :(

 Please, we need a road-map, we need to prioritise these most basic
 aspects of the experience, and we need to do it soon.
 I might re-iterate my feeling that external IDE integration projects
 should be claimed by the community officially, and user experience +
 debugging issues should be first-class issues in the main d language
 bug-tracker so everybody can see them, and everybody is aware of the stats.
 Also, the DMD front-end should be a lib offering auto-completion and
 syntax hilighting data to clients.

 I'm doing some more work on premake (a nice light buildsystem that
 generated makefiles and project files for popular IDE's) to tightly
 incorporate D into the various IDE's it supports.

 </endrant>

Other then that I have to fully agree with all the points you listed. Kind Regards Benjamin Thaut
Sep 01 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 1:06 AM, Benjamin Thaut wrote:
 Also if you are using Visual Studio 2012, you need to change the debugging
 engine because the new one can't deal with D code that has C++ debugging info.

This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.
Sep 01 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 01.09.2013 10:49, schrieb Walter Bright:
 On 9/1/2013 1:06 AM, Benjamin Thaut wrote:
 Also if you are using Visual Studio 2012, you need to change the
 debugging
 engine because the new one can't deal with D code that has C++
 debugging info.

This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.

Still the visual studio debugger has the best debugging experience you can currently get for D.
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 7:02 AM, Manu wrote:
 I know Walter does care about the DMD-Win64 debuginfo quality, but I don't
think
 the debuginfo output is capable of addressing all the problems alone.

I (and others like Rainer who help a lot with Win64 support) also cannot do a thing without targeted bugzilla reports.
Sep 01 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-02 05:02, Manu wrote:

 I'll continue to log bugs as I find them, I didn't this weekend because
 when finding a bug, I then need to spend the time to boil down a minimal
 repro case, and we were working against the clock >_<

A minimal test case can be created later. -- /Jacob Carlborg
Sep 02 2013
prev sibling next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 01.09.2013 15:55, schrieb Manu:
 Mago is only Win32, and DMD is only Win64... I've tried encouraging the
 Mago guy to support Win64, but it doesn't seem to be a highly active
 project recently. I think this is another case of a 1-man project that
 represents a fairly critical part of the ecosystem.

You may be pleased to hear the mago is currently getting 64-bit and pdb support. Its activly beeing worked on, check the svn repository on dsource.org.
 Sometimes...
 Have you worked with it on a daily basis? It just doesn't work all the
 time. Also, in my experience the auto-complete suggestions are often
 either incomplete, or list heaps of completely unrelated stuff.
 I'm not saying it's bad, it's better than nothing and I really
 appreciate the project (I've said before, if it weren't for Rainer's
 effort, I simply wouldn't use D), but it certainly needs more work,
 especially if I'm going to have any traction selling it to others with
 no vested interest in the language.

I'm not talking about the auto-complete. I talk about the class view. It only works on the .json output of the compiler. If you regularly recompile (which is not an issue with D because it's basically free) you have a nice and clean overview of all your modules, classes and structs. And you can even search that class view to find stuff. It also helps somewhat with auto-completion and "goto definition". Yes I use it on a daily basis, and yes I know that it's not perfect. You should also go into Options -> Text Editors -> D -> Intelli Sense and play around with the options there to see what works best for you.
 But this project approached it from a different angle, ie, a total
 replacement for C++ which does have a rich toolset available. I want to
 use D in this context in the future, and if that were the commitment we
 were considering at Remedy, there's no way we would have gone for it.

Yeah I gave a talk about D at Havok recently too and basically got the same response. D simply doesn't have enough tools / momentum to be a option. I use D as a C++ replacement though, and going back to C++ annoys me more and more every day. Better tools are nice, but I'm really missing some features D has when coding C++.
Sep 01 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 6:55 AM, Manu wrote:
 Sometimes...
 Have you worked with it on a daily basis? It just doesn't work all the time.
 Also, in my experience the auto-complete suggestions are often either
 incomplete, or list heaps of completely unrelated stuff.
 I'm not saying it's bad, it's better than nothing and I really appreciate the
 project (I've said before, if it weren't for Rainer's effort, I simply wouldn't
 use D), but it certainly needs more work, especially if I'm going to have any
 traction selling it to others with no vested interest in the language.

I really appreciate your efforts here. What Rainer needs is, I assume, the same things I need. Very specific lists of what went wrong.
Sep 01 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 01 Sep 2013 09:42:37 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 8/31/2013 7:05 PM, Manu wrote:
 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the stars  
 aligned such
 that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various  
 versions of
 VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a user to  
 fiddle with
 an ini file just isn't acceptable. We had to google solutions to this  
 problem,
 and even then, we had trouble with the paths we added to sc.ini; are  
 spaces
 acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'),  
 libraries should
 be automatically detected and path entries added in there too:
    C:\Program Files (x86)\Microsoft SDKs\...
    C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and each of us  
 had to
 configure them ourselves.

The default sc.ini contains: ----------------------------- [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib";\dm\lib DFLAGS="-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe VCINSTALLDIR=%VCINSTALLDIR% WindowsSdkDir=%WindowsSdkDir% ---------------------------------- When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work". What went wrong, specifically?

Like Dmitry said, it might work for 2010, but it certainly does not 'just work' for 2012 and 2013. I've probably spent twelve hours setting up DMD Win64 on my two confusers. -- Simen
Sep 01 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 Configuring compilers:

 Naturally, this is primarily a problem with the windows 
 experience, but
 it's so frustrating that it is STILL a problem... how many 
 years later?

My first setup took me days :D Somehow it improved. It still sucks.
 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work 
 with a
 makefile. Everybody else wanted a comfortable IDE solution (and 
 the linux
 user would prefer it too).

I came to the same conclusion, and that is why SDC is relying on libd. Our tooling sucks hard.
 Obviously, we settled on Visual-D (Windows) and Mono-D 
 (OSX/Linux); the
 only realistic choices available. The OSX user would have 
 preferred an
 XCode integration.

I don't know any dev that is happy of XCode, even OSX lovers. I mean, how good is a editor that propose you to export functions to iTune (I should try it one day, I really wonder what it does), but not finding declaration in its contextual menu ?
 This goes back to the threads where the IDE guys are writing 
 their own
 parsers, when really, DMD should be able to be built as a lib, 
 with an API
 designed for using DMD as a lib/plugin.

Considering DMD never deallocate anything, expect to restart your IDE every hour or so.
 Debugging:

Ho god ! The demangler do not demangle most things. Hello stack trace of incomprehensible symbol. If gdb is able to give me file/line, druntime is completely unable to do so, so you have to use external tooling to get back this info. The best of the best being too long mangling being truncated in the output. Backtrace is the bare minimum to dubug and it isn't working.
 Documentation:

 Okay for the most part, but some windows dev's want a CHM that 
 looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.

I don't understand that. I never understand anything at MS documentation because of its look and feel (the content is usually pretty good). I guess it is matter of taste/habit.
 Containers:

 The question came up multiple times; "I don't think this should 
 be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item 
 from an array,
 or an item from an AA by reference/value (only by key).

 This code:
   foreach(i, item; array)
     if(item == itemToRemove)
       array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it 
 lightly...

Me miss 1 piece in the language to make that work properly (and another one to make that more effiscient). Namely covariance on template instances and allocators. I've been raising the first one as it is also a problem for SDC. People raised it to implement AA as lib, and it is a recurring discussion around dcollection.
 Bugs:
 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

 We also ran into some completely nonsense error messages, but I 
 forgot to
 log them, since we were working against the clock.


 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).

Arguably, this is because of lack of IDE support and because C++ screwed you up :D I recognize the feature as good to have, but definitively not as big as an issue as the one mentioned above. If the problem mentioned before are solved, then this one won't be a big issue.
 I'm doing some more work on premake (a nice light buildsystem 
 that
 generated makefiles and project files for popular IDE's) to 
 tightly
 incorporate D into the various IDE's it supports.

That look a good project !
Sep 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 2:50 AM, deadalnix wrote:
 Considering DMD never deallocate anything, expect to restart your IDE every
hour
 or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.
 Debugging:


Bugzilla entry, please. There are many members in the D community who poke around looking for low hanging fruit in bugzilla that they can fix. They'll never know about the issues you're having that they can fix if they aren't in bugzilla.
Sep 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 19:54, Walter Bright wrote:
 On 9/1/2013 2:50 AM, deadalnix wrote:
 Considering DMD never deallocate anything, expect to restart your IDE
 every hour
 or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.

That was in reply to if DMD was built as a library and included in the IDE. Then there wouldn't be a process to end. -- /Jacob Carlborg
Sep 02 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/2/2013 1:11 AM, Jacob Carlborg wrote:
 That was in reply to if DMD was built as a library and included in the IDE.
Then
 there wouldn't be a process to end.

Ah, I see. But that does bring up the possibility of running dmd front end as a separate process, and then using interprocess communication with it? Isn't Google's Chrome browser built that way?
Sep 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-03 01:28, Walter Bright wrote:

 Ah, I see.

 But that does bring up the possibility of running dmd front end as a
 separate process, and then using interprocess communication with it?

 Isn't Google's Chrome browser built that way?

It will still eat a lot of memory, the way DMD currently handling memory. The process would be constantly running next to the IDE. -- /Jacob Carlborg
Sep 03 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 04:05, Manu wrote:

 Naturally, this is primarily a problem with the windows experience, but
 it's so frustrating that it is STILL a problem... how many years later?
 People don't want to 'do work' to install a piece of software. Rather,
 they expect it to 'just work'. We lost about 6 hours trying to get
 everyone's machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! I just
 kept promising people that it would save time overall... which I wish
 were true.

Was this only on Windows or were there problems on Linux/Mac OS X as well?
 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work with a
 makefile. Everybody else wanted a comfortable IDE solution (and the
 linux user would prefer it too).

I can understand that.
 IDE integration absolutely needs to be considered a first class feature
 of D.
 I also suggest that the IDE integration downloads should be hosted on
 the dlang download page so they are obvious and available to everyone
 without having to go looking, and also as a statement that they are
 actually endorsed by the dlanguage authorities. As an end-user, you're
 not left guessing which ones are good/bad/out of date/actually work/etc.

I completely agree.
 Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
 only realistic choices available.

There's also DDT with Eclipse. It supports auto completion, go to definition, has an outline view and so on.
 The OSX user would have preferred an  XCode integration.

This one is a bit problematic since Xcode doesn't officially supports plugins. But it's still possible, as been shown by Michel Fortin with his D for Xcode plugin.
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to navigate
 (like Java and C#).
 We all wanted to ability to define class member functions outside the
 class definition:
    class MyClass
    {
      void method();
    }

    void MyClass.method()
    {
      //...
    }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want to quickly see what a class has and does.

Sounds like you want an outline view in the IDE. This is supported by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline view. -- /Jacob Carlborg
Sep 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 16:32, Manu wrote:

 Well we never got OSX working (under mono-d), although this was mainly
 due to supporting apple infrastructure in the end. I think we wrangled
 the toolchain in the end, but never got everything linking; C++
 dependencies got complicated.
 We eventually gave up, just wasting too much time, and he went off and
 did the music/sounds for the game...

Gave up? Why not just use DMD directly from the zip on the command line and use TextMate or Sublime. TextMate 2 supports in app download of new languages and Sublime comes with support for D out of the box. Even though it's not perfect it has to be better than giving up.
 If you'd like to help me finish that OSX work we started together last
 year, that'd be really great for next time! :)

Well, I'm quite busy with my own projects. But I could perhaps give you a hand if you need. Although I don't want to do all the work as last time.
 No, actually, as much as I keep banging on the IDE thing, in this case I
 absolutely don't want help from the IDE, I just want to look at my page
 of text, and be able to read a useful summary.
 Can you give me any good reasons why fully defined functions polluting
 the readability of a class definition could possibly be a good thing?
 I just don't get it... why would you ever want to break up the nice
 summary of what a class has&does, and why would you want to indent all
 of your functions an extra few tab levels by default?

To keep everything in one place. Why would you want to duplicate the method signatures? I hate the header/source synchronization in the C family of languages. Especially in C++ where the signatures cannot even be exactly the same between the header and source file. I'm thinking of default values, for example.
 As a programmer, I spend a lot more time reading code than
 documentation, and much of that time is spent reading it in foreign
 places like github commit logs (limited horizontal space), diff/merge
 windows (hard to distinguish class API changes vs function body changes
 at a glance, since they're interleaved), even chat clients and
 communication tools. The IDE can't assist in any of these contexts. If
 you have to have an IDE to read your code, then something is really wrong.

That I agree with.
 ...also, that implies you have good IDE integration, which is the a
 central part of my entire rant! ;)
 This argument is invalid until we have that, and at this point, it seems
 much more likely we may be able to define methods outside the class
 scope than have awesome IDE's.

-- /Jacob Carlborg
Sep 01 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-02 05:51, Manu wrote:

 I dunno. People just don't do that.
 It's perceived that typing commands in the command line is a completely
 unrealistic workflow for most people that doesn't love linux.
 He would have also had to have written himself a makefile, and none of
 us know how to write a makefile. I generate makefiles with other tools,
 but there are no good makegen tools that support D and C projects
 together, and even if there were, you'd just be writing a makegen script
 instead, which we still didn't know how to write...
 We also really didn't have time to stuff around with it. He just went
 and recorded audio instead.

I would have used a shell script but I get your point.
 Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC... :/

Hehe. You do already support iOS, how was that added?
 Good IDE's have awesome refactor tools, where you change a signature,
 and it will change it at all places that it is referenced.

Then your back to need of an IDE to use the language. -- /Jacob Carlborg
Sep 02 2013
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 9/2/2013 12:51 PM, Manu wrote:

 I dunno. People just don't do that.
 It's perceived that typing commands in the command line is a completely
 unrealistic workflow for most people that doesn't love linux.
 He would have also had to have written himself a makefile, and none of
 us know how to write a makefile. I generate makefiles with other tools,
 but there are no good makegen tools that support D and C projects
 together, and even if there were, you'd just be writing a makegen script
 instead, which we still didn't know how to write...
 We also really didn't have time to stuff around with it. He just went
 and recorded audio instead.

Screw makefiles. dub[1] is the way to go. Dead easy to configure [2] and dead easy to use. A default debug build on the command line is "dub build", or even just "dub". [1] http://code.dlang.org/packages/dub [2] http://code.dlang.org/package-format
Sep 02 2013
prev sibling next sibling parent "ponce" <contact spam.org> writes:
While I consider going to a contest with tools you don't know yet 
a very risky move, I can only empathize with some of the points 
expressed by Manu.

 We needed to mess with sc.ini for quite some time to get the 
 stars aligned
 such that it would actually compile and find the linker+libs.

Same problem here, I used DMD-Win64 only once since I don't remember the steps to get it to work (I think it involved changing some .lib and path in sc.ini).
 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to 
 get OSX
 working); there are lots of problems with the debugging 
 experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing 
 bugs in
 random places when it was simply a case of the debugger lying 
 about the
 value of variables to them, and many more cases where the 
 debugger simply
 refused to produce values for some variables at all.

This happened to me several times, so that I end up relying on writefln-debugging again. The fact that an IDE plugin exist at all is a huge acceptance factor in the workplace.
Sep 01 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 1 September 2013 at 09:46:08 UTC, Jacob Carlborg wrote:
 That doesn't mean there aren't any IDE's out there with good 
 support for autocompletion. The one in Eclipse for Java is 
 fantastic. The one in Xcode 4+ for C/C++ and Objective-C/C++ is 
 really good.

Java is not a good comparison because it does not have any compile-time metaprogramming features to speak of. I've never used Xcode but how does it fare when faced with C++ template metaprogramming?
 You're forced to explicitly initialize it.

What do you mean? Please show some code how a declared but not defined struct can be initialized in any way, shape or form.
Sep 01 2013
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.

Uggh! I absolutely do not agree with this. You should rely on documentation or an IDE class overview for these things *not* alter the language. In lieu of IDE support just use ddoc comments for methods and properties and compile the documentation for each build.
Sep 01 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 16:36, Manu wrote:

 Give me one advantage to defining methods inline? I only see
 disadvantages. Lots of them.

Give me one advantage to repeat the method signature. -- /Jacob Carlborg
Sep 01 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 01 Sep 2013 05:53:29 +0200, Jakob Ovrum <jakobovrum gmail.com>  
wrote:

 Yes, we hit DMD bugs, like the one with opaque structs which required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?

An array of struct *pointers*. Fill it with nulls, I'd say. -- Simen
Sep 01 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 ...
 </endrant>


Thought number one after reading "This is why I absolutely hate programming for Windows!" :) Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway, key problem (as far as I can see) here is that few of D developers have both experience and personal interest in any IDE/Windows focus as well as related tool stack. D has some nice flavor of anarchy - both like it and consider it a problem.
Sep 01 2013
parent reply Mike Parker <aldacron gmail.com> writes:
On 9/1/2013 7:40 PM, Dicebot wrote:
 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 ...
 </endrant>


Thought number one after reading "This is why I absolutely hate programming for Windows!" :) Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway, key problem (as far as I can see) here is that few of D developers have both experience and personal interest in any IDE/Windows focus as well as related tool stack. D has some nice flavor of anarchy - both like it and consider it a problem.

I have a batch file tied to a command prompt shortcut that always sets the D environment when I launch it. Updating DMD is a matter of deleting the old directory and unzipping the zip file. Editing is a matter of launching Sublime Text 2. Compiling is alt-tabbing to the command prompt and typing "dub build". It's a painless process and I never have any trouble. Of course, I don't try to use the MS tools, or build DMD myself. That way lies pain.
Sep 01 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 13:44, Mike Parker wrote:

 I have a batch file tied to a command prompt shortcut that always sets
 the D environment when I launch it. Updating DMD is a matter of deleting
 the old directory and unzipping the zip file.

Or just use DVM: https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Sep 01 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 17:17, Manu wrote:

 I think infrastructure solutions like this are probably fine, but
 they're worthless unless they're installed by default as part of the
 standard DMD installer.
 If it's robust, convince Walter to include it in the standard installer
 package?

I might look in to that when it's time to update to D2. But the point of DVM is to use it instead of an installer. -- /Jacob Carlborg
Sep 01 2013
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 9/2/2013 8:59 AM, Brad Anderson wrote:
 For a few releases now the D installer for Windows has created a start
 menu shortcut that launches cmd.exe with dmd et al. added to the PATH.
 It also adds to the PATH during installation if you let it.

Good news. Does it allow multiple versions of DMD to be installed simultaneously?
Sep 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-02 10:30, Mike Parker wrote:

 Good news. Does it allow multiple versions of DMD to be installed
 simultaneously?

DVM already handles this. Although it doesn't handle Windows 64bit. -- /Jacob Carlborg
Sep 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 1 September 2013 at 10:21:18 UTC, Jakob Ovrum wrote:
 On Sunday, 1 September 2013 at 09:46:08 UTC, Jacob Carlborg 
 wrote:
 That doesn't mean there aren't any IDE's out there with good 
 support for autocompletion. The one in Eclipse for Java is 
 fantastic. The one in Xcode 4+ for C/C++ and Objective-C/C++ 
 is really good.

Java is not a good comparison because it does not have any compile-time metaprogramming features to speak of. I've never used Xcode but how does it fare when faced with C++ template metaprogramming?

My understanding is that it uses libclang.
Sep 01 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 1 September 2013 at 10:39:15 UTC, Simen Kjaeraas wrote:
 On Sun, 01 Sep 2013 05:53:29 +0200, Jakob Ovrum 
 <jakobovrum gmail.com> wrote:

 Yes, we hit DMD bugs, like the one with opaque structs which 
 required
 extensive work-arounds.
  struct MyStruct;
  MyStruct*[] = new MyStruct*[n];

I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?

An array of struct *pointers*. Fill it with nulls, I'd say.

I assumed that's the "work-around" he referred to. After testing I realize not even the pointers work. Yeah, that's clearly a bug.
Sep 01 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Manu:

 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.

Having the pieces of a class spread is not something I'd like. So before changing this a discussion is needed. Bye, bearophile
Sep 01 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/1/13, Michel Fortin <michel.fortin michelf.ca> wrote:
 So I'm no longer using D, but I'm still hanging around here from time
 to time because there's always something interesting to read.

That's a shame. But yeah, people should use what makes them productive and what brings food on the table, I can't judge you with that decision. The newsgroup is pretty entertaining to stay around though. :p
Sep 01 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/1/13, Jakob Ovrum <jakobovrum gmail.com> wrote:
 I'm not sure this is a bug. How do you default initialize an
 array of structs you don't know the .init values of?

Note that this is an array of /pointers/ to opaque structs, so it's valid code.
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e01537e42f700cd04e5524e7d
Content-Type: text/plain; charset=UTF-8

Hmmm, I found details on the net that recommended adding an [Environment64]
section, which we did.

I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on my system
:/ .. that said, VC obviously works on my machine.
It also seems potentially problematic that a variable would define a single
install directory, since it's pretty common that programmers have multiple
versions of VS on their machines.
I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.

I was also thinking it might be a mistake to keep phobos64.lib in the same
folder as the 32bit omf libs. If paths are wrong, the link errors will only
be understood by a programmer who understands compilers and lib/object
formats in depth.
Perhaps you should put them in a parallel lib64 directory, and hook that up
in [Environment64] (I did that on my machine while trying to isolate
problems and wort out where paths were coming from)?

I reckon you should look into hooking up DirectX SDK patahing by default
too since it's so common for basically any multimedia app.


On 1 September 2013 17:42, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/31/2013 7:05 PM, Manu wrote:

 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the stars
 aligned such
 that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various versions
 of
 VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a user to
 fiddle with
 an ini file just isn't acceptable. We had to google solutions to this
 problem,
 and even then, we had trouble with the paths we added to sc.ini; are
 spaces
 acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), libraries
 should
 be automatically detected and path entries added in there too:
    C:\Program Files (x86)\Microsoft SDKs\...
    C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and each of us
 had to
 configure them ourselves.

The default sc.ini contains: ----------------------------- [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib";\dm\lib DFLAGS="-I% P%\..\..\src\**phobos" "-I% P%\..\..\src\druntime\**import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\**amd64\link.exe VCINSTALLDIR=%VCINSTALLDIR% WindowsSdkDir=%WindowsSdkDir% ------------------------------**---- When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work". What went wrong, specifically?

--089e01537e42f700cd04e5524e7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hmmm, I found details on the net that recommended adding a= n [Environment64] section, which we did.<div><br><div>I don&#39;t seem to h= ave <span style=3D"font-family:arial,sans-serif;font-size:13px">VCINSTALLDI= R or=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px= ">WindowsSdkDir=C2=A0</span><span style=3D"font-family:arial,sans-serif;fon= t-size:13px">variables on my system :/ .. that said, VC obviously works on = my machine.</span></div> </div><div><font face=3D"arial, sans-serif">It also seems potentially probl= ematic that a variable would define a single install directory, since it&#3= 9;s pretty common that programmers have multiple versions of VS on their ma= chines.</font></div> <div><font face=3D"arial, sans-serif">I have VS2010 and VS2012 on my machin= e. Simon had VS2012 and VS2013.</font></div><div><font face=3D"arial, sans-= serif"><br></font></div><div><font face=3D"arial, sans-serif">I was also th= inking it might be a mistake to keep phobos64.lib in the same folder as the= 32bit omf libs. If paths are wrong, the link errors will only be understoo= d by a programmer who understands compilers and lib/object formats in depth= .</font></div> <div><font face=3D"arial, sans-serif">Perhaps you should put them in a para= llel lib64 directory, and hook that up in [Environment64] (I did that on my= machine while trying to isolate problems and wort out where paths were com= ing from)?</font></div> <div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a= rial, sans-serif">I reckon you should look into hooking up DirectX SDK pata= hing by default too since it&#39;s so common for basically any multimedia a= pp.</font></div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 1 Se= ptember 2013 17:42, Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:n= ewshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com</a>= &gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 8/31/2013 7:05 PM, Manu= wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> The only compiler you can realistically use productively in windows is<br> DMD-Win64, and that doesn&#39;t work out of the box.<br> We needed to mess with sc.ini for quite some time to get the stars aligned = such<br> that it would actually compile and find the linker+libs.<br> <br></div><div class=3D"im"> Walter: DMD needs to internally detect installations of various versions of= <br></div><div class=3D"im"> VisualStudio, and either &#39;just work&#39;, or amend sc.ini on its own. O= r the<br> installer needs to amend sc.ini. Either way, leaving it to a user to fiddle= with<br> an ini file just isn&#39;t acceptable. We had to google solutions to this p= roblem,<br> and even then, we had trouble with the paths we added to sc.ini; are spaces= <br> acceptable? Do they have quites around them?...<br> I might also suggest that Microsoft supplied (ie, &#39;standard&#39;), libr= aries should<br> be automatically detected and path entries added in there too:<br> =C2=A0 =C2=A0C:\Program Files (x86)\Microsoft SDKs\...<br> =C2=A0 =C2=A0C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...<b= r> These are on basically every windows developers machine, and each of us had= to<br> configure them ourselves.<br> </div></blockquote> <br> The default sc.ini contains:<br> -----------------------------<br> [Version]<br> version=3D7.51 Build 020<br> <br> [Environment]<br> LIB=3D&quot;% P%\..\lib&quot;;\dm\lib<br> DFLAGS=3D&quot;-I% P%\..\..\src\<u></u>phobos&quot; &quot;-I% P%\..\..\src\= druntime\<u></u>import&quot;<br> LINKCMD=3D% P%\link.exe<br> LINKCMD64=3D%VCINSTALLDIR%bin\<u></u>amd64\link.exe<br> VCINSTALLDIR=3D%VCINSTALLDIR%<br> WindowsSdkDir=3D%WindowsSdkDir%<br> ------------------------------<u></u>----<br> <br> When I installed VC 2010, it set the environment variables VCINSTALLDIR and= WindowsSdkDir. Then, the default sc.ini should &quot;just work&quot;.<br> <br> What went wrong, specifically?<br> <br> </blockquote></div><br></div> --089e01537e42f700cd04e5524e7d--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2e81c477b9f04e55252d5
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 17:46, Nick Sabalausky <
SeeWebsiteToContactMe semitwist.com> wrote:

 On Sun, 01 Sep 2013 06:45:48 +0200
 "Kapps" <opantm2+spam gmail.com> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class
 definition, you want
 to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

I see it as the job of doc generators.

Why complicate the issue? What's wrong with readable code? --001a11c2e81c477b9f04e55252d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 17:46, Nick Sabalausky <span dir=3D"lt= r">&lt;<a href=3D"mailto:SeeWebsiteToContactMe semitwist.com" target=3D"_bl= ank">SeeWebsiteToContactMe semitwist.com</a>&gt;</span> wrote:<br><div clas= s=3D"gmail_extra"> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"=
On Sun, 01 Sep 2013 06:45:48 +0200<br>

pam gmail.com</a>&gt; wrote:<br> <br> &gt; On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:<br> </div><div class=3D"im">&gt; &gt; One more thing:<br> &gt; &gt; I&#39;ll just pick one language complaint from the weekend.<br> &gt; &gt; It is how quickly classes became disorganised and difficult to<br=

&gt; &gt; (like Java and C#).<br> &gt; &gt; We all wanted to ability to define class member functions<br> &gt; &gt; outside the class<br> &gt; &gt; definition:<br> &gt; &gt; =C2=A0 class MyClass<br> &gt; &gt; =C2=A0 {<br> &gt; &gt; =C2=A0 =C2=A0 void method();<br> &gt; &gt; =C2=A0 }<br> &gt; &gt;<br> &gt; &gt; =C2=A0 void MyClass.method()<br> &gt; &gt; =C2=A0 {<br> &gt; &gt; =C2=A0 =C2=A0 //...<br> &gt; &gt; =C2=A0 }<br> &gt; &gt;<br> &gt; &gt; It definitely cost us time simply trying to understand the<br> &gt; &gt; class layout<br> &gt; &gt; visually (ie, when IDE support is barely available).<br> &gt; &gt; You don&#39;t need to see the function bodies in the class<br> &gt; &gt; definition, you want<br> &gt; &gt; to quickly see what a class has and does.<br> &gt;<br> &gt; This isn&#39;t something I&#39;ve found to be an issue personally, but= I<br> &gt; suppose it&#39;s a matter of what you&#39;re used to. Since I&#39;m us= ed to<br> &gt; C#, I haven&#39;t had problems with this. I&#39;ve always felt that th= is<br> &gt; was the IDE&#39;s job, personally. That being said, perhaps .di files<= br> &gt; could help with this?<br> <br> </div>I see it as the job of doc generators.<br></blockquote><div><br></div=
<div>Why complicate the issue? What&#39;s wrong with readable code?</div><=

--001a11c2e81c477b9f04e55252d5--
Sep 01 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 1 September 2013 at 13:21:20 UTC, Jacob Carlborg wrote:
 int[] a; // default initialized
 int[] b = [3, 4, 5]; // explicitly initialized

This has nothing to do with the problem.
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8f50378e1dd6b204e552cfe9
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 18:06, Benjamin Thaut <code benjamin-thaut.de> wrote:

 Am 01.09.2013 04:05, schrieb Manu:


 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a massive
 point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
 how absolutely important this is.
 !!!!!!!!!

I have to fully agree here.
 Debugging:

 Poor debugging experience wastes your time every 5 minutes.
 I can only speak for the Windows experience (since we failed to get OSX
 working); there are lots of problems with the debugging experience under
 visual studio...
 I haven't logged bugs yet, but I intend to.
 There were many instances of people wasting their time chasing bugs in
 random places when it was simply a case of the debugger lying about the
 value of variables to them, and many more cases where the debugger
 simply refused to produce values for some variables at all.
 This is an unacceptable waste of programmers time, and again, really
 burned us in a 48hour context.

nicely with the visual studio c++ debugger. It replaces all '.' chars with ' ' in type names inside the debug information. There was a pull request from Rainer Schuetze once, but it got rejected by Walter. https://github.com/Ingrater/**dmd/commit/**522f6dbeb93944ebfebde6f938a2ee* *3a2d6be124<https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f938a2ee3a2d6be124> Also if you are using Visual Studio 2012, you need to change the debugging engine because the new one can't deal with D code that has C++ debugging info. For that go to Options -> Debugging -> Edit and Continue -> Enable Edit and Continue (this will make Visual Studio 2012 use the old debugging engine).

I use 2010, but Simon was using 2012, maybe that was the source of his problems. He certainly seemed to have a lot more problems than me. Then everything will work nicely. The only real issue is, that the debugger
 can't identify which class is behind a given interface.

 Also you should try using mago, it can be enabled inside the visualD
 debugging options of your project. It even features D expression
 evaluation, but it only works for 32-bit (but requires not cv2pdb
 conversion).

Mago is only Win32, and DMD is only Win64... I've tried encouraging the Mago guy to support Win64, but it doesn't seem to be a highly active project recently. I think this is another case of a 1-man project that represents a fairly critical part of the ecosystem. Containers:
 The question came up multiple times; "I don't think this should be an
 array... what containers can I use, and where are they?"...
 Also, nobody could work out how to remove an arbitrary item from an
 array, or an item from an AA by reference/value (only by key).

 This code:
    foreach(i, item; array)
      if(item == itemToRemove)
        array = array[0..i] ~ array[i+1..$];
 Got a rather 'negative' reaction from the audience to put it lightly...

written my own by now.

It turns out that it's not actually so easy to just 'knock up' a set of robust containers that work well across all of D's features. Templates, and various typing complexities always seem to complicate the issue. In my experience, I knock something together, and it appears to work in the simple case... but then down the line, something a little more niche hits it, and I realise it's not a trivial tweak to fix it. Often a more substantial rethink may be required. One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to navigate
 (like Java and C#).
 We all wanted to ability to define class member functions outside the
 class definition:
    class MyClass
    {
      void method();
    }

    void MyClass.method()
    {
      //...
    }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want to quickly see what a class has and does.

generates while compiling. Using this feature you get a really awesome class view and even "Go to defintion" works.

Sometimes... Have you worked with it on a daily basis? It just doesn't work all the time. Also, in my experience the auto-complete suggestions are often either incomplete, or list heaps of completely unrelated stuff. I'm not saying it's bad, it's better than nothing and I really appreciate the project (I've said before, if it weren't for Rainer's effort, I simply wouldn't use D), but it certainly needs more work, especially if I'm going to have any traction selling it to others with no vested interest in the language. The situation at Remedy was different, it was an easier sell. Since we implemented D as an extension language, the productivity comparison was to scripting languages like lua which also have no tight integration or debugging support in Visual Studio. Visual-D was certainly an improvement over other scripting solutions, and I think I made that case at DConf. But this project approached it from a different angle, ie, a total replacement for C++ which does have a rich toolset available. I want to use D in this context in the future, and if that were the commitment we were considering at Remedy, there's no way we would have gone for it. My hope from the Remedy experience was to prove that it works in a commercial environment. I went out on a REALLY massive limb there, and as far as I can tell, it's well received (although it took the better part of a year longer to get there than I promised). I'd love to see it take the next step one day, ie, into the main code-base... but the tools need to be rock solid before that can ever happen. Conclusion:
 I think this 48 hour jam approach is a good test for the language and
 it's infrastructure. I encourage everybody to try it (ideally with a
 clean slate computer).
 The lesson is that we need to make this process smooth, since it mirrors
 the first-experience of everybody new to D.
 It also highlights and magnifies time-wasters that are equally
 unacceptable in a commercial environment.

 I don't think I made any converts this weekend wrt the above issues
 encountered. I might have even just proved to them that they should
 indeed stick with C# (the IDE's work!)... :(

 Please, we need a road-map, we need to prioritise these most basic
 aspects of the experience, and we need to do it soon.
 I might re-iterate my feeling that external IDE integration projects
 should be claimed by the community officially, and user experience +
 debugging issues should be first-class issues in the main d language
 bug-tracker so everybody can see them, and everybody is aware of the
 stats.
 Also, the DMD front-end should be a lib offering auto-completion and
 syntax hilighting data to clients.

 I'm doing some more work on premake (a nice light buildsystem that
 generated makefiles and project files for popular IDE's) to tightly
 incorporate D into the various IDE's it supports.

 </endrant>

Other then that I have to fully agree with all the points you listed. Kind Regards Benjamin Thaut

--e89a8f50378e1dd6b204e552cfe9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 18:06, Benjamin Thaut <span dir=3D"ltr= ">&lt;<a href=3D"mailto:code benjamin-thaut.de" target=3D"_blank">code benj= amin-thaut.de</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas= s=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Am 01.09.2013 04:05, schrieb Manu:<div class= =3D"im"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> !!!!!!!!!<br> This has to be given first-class attention!<br> I am completely and utterly sick of this problem. Don made a massive<br> point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress<br=

!!!!!!!!!<br> </blockquote> <br></div> I have to fully agree here.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Debugging:<br> <br> Poor debugging experience wastes your time every 5 minutes.<br> I can only speak for the Windows experience (since we failed to get OSX<br> working); there are lots of problems with the debugging experience under<br=

I haven&#39;t logged bugs yet, but I intend to.<br> There were many instances of people wasting their time chasing bugs in<br> random places when it was simply a case of the debugger lying about the<br> value of variables to them, and many more cases where the debugger<br> simply refused to produce values for some variables at all.<br> This is an unacceptable waste of programmers time, and again, really<br> burned us in a 48hour context.<br> <br> </blockquote> <br></div> Actually there is only one little patch needed to make debugging work nicel= y with the visual studio c++ debugger. It replaces all &#39;.&#39; chars wi= th &#39; &#39; in type names inside the debug information. There was a pull= request from Rainer Schuetze once, but it got rejected by Walter.<br> <br> <a href=3D"https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f93= 8a2ee3a2d6be124" target=3D"_blank">https://github.com/Ingrater/<u></u>dmd/c= ommit/<u></u>522f6dbeb93944ebfebde6f938a2ee<u></u>3a2d6be124</a><br> <br> Also if you are using Visual Studio 2012, you need to change the debugging = engine because the new one can&#39;t deal with D code that has C++ debuggin= g info. For that go to Options -&gt; Debugging -&gt; Edit and Continue -&gt= ; Enable Edit and Continue (this will make Visual Studio 2012 use the old d= ebugging engine).<br> </blockquote><div><br></div><div>I use 2010, but Simon was using 2012, mayb= e that was the source of his problems. He certainly seemed to have a lot mo= re problems than me.</div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then everything will work nicely. The only real issue is, that the debugger= can&#39;t identify which class is behind a given interface.<br> <br> Also you should try using mago, it can be enabled inside the visualD debugg= ing options of your project. It even features D expression evaluation, but = it only works for 32-bit (but requires not cv2pdb conversion).</blockquote> <div><br></div><div>Mago is only Win32, and DMD is only Win64... I&#39;ve t= ried encouraging the Mago guy to support Win64, but it doesn&#39;t seem to = be a highly active project recently. I think this is another case of a 1-ma= n project that represents a fairly critical part of the ecosystem.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"= im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> Containers:<br> <br> The question came up multiple times; &quot;I don&#39;t think this should be= an<br> array... what containers can I use, and where are they?&quot;...<br> Also, nobody could work out how to remove an arbitrary item from an<br> array, or an item from an AA by reference/value (only by key).<br> <br> This code:<br> =C2=A0 =C2=A0foreach(i, item; array)<br> =C2=A0 =C2=A0 =C2=A0if(item =3D=3D itemToRemove)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0array =3D array[0..i] ~ array[i+1..$];<br> Got a rather &#39;negative&#39; reaction from the audience to put it lightl= y...<br> <br> </blockquote> <br></div> Oh containers, I would love to have some. Like every one else using D I&#39= ;ve written my own by now.</blockquote><div><br></div><div>It turns out tha= t it&#39;s not actually so easy to just &#39;knock up&#39; a set of robust = containers that work well across all of D&#39;s features.</div> <div>Templates, and various typing complexities always seem to complicate t= he issue.</div><div>In my experience, I knock something together, and it ap= pears to work in the simple case... but then down the line, something a lit= tle more niche hits it, and I realise it&#39;s not a trivial tweak to fix i= t. Often a more substantial rethink may be required.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> One more thing:<br> I&#39;ll just pick one language complaint from the weekend.<br> It is how quickly classes became disorganised and difficult to navigate<br> (like Java and C#).<br> We all wanted to ability to define class member functions outside the<br> class definition:<br> =C2=A0 =C2=A0class MyClass<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0void method();<br> =C2=A0 =C2=A0}<br> <br> =C2=A0 =C2=A0void MyClass.method()<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0//...<br> =C2=A0 =C2=A0}<br> <br> It definitely cost us time simply trying to understand the class layout<br> visually (ie, when IDE support is barely available).<br> You don&#39;t need to see the function bodies in the class definition, you<= br> want to quickly see what a class has and does.<br> <br> </blockquote> <br></div> You should really use VisualD&#39;s ability to parse the AST .json files dm= d generates while compiling. Using this feature you get a really awesome cl= ass view and even &quot;Go to defintion&quot; works.<br></blockquote><div> <br></div><div>Sometimes...</div><div>Have you worked with it on a daily ba= sis? It just doesn&#39;t work all the time. Also, in my experience the auto= -complete suggestions are often either incomplete, or list heaps of complet= ely unrelated stuff.</div> <div>I&#39;m not saying it&#39;s bad, it&#39;s better than nothing and I re= ally appreciate the project (I&#39;ve said before, if it weren&#39;t for Ra= iner&#39;s effort, I simply wouldn&#39;t use D), but it certainly needs mor= e work, especially if I&#39;m going to have any traction selling it to othe= rs with no vested interest in the language.</div> <div><br></div><div>The situation at Remedy was different, it was an easier= sell. Since we implemented D as an extension language, the productivity co= mparison was to scripting languages like lua which also have no tight integ= ration or debugging support in Visual Studio. Visual-D was certainly an imp= rovement over other scripting solutions, and I think I made that case at DC= onf.</div> <div>But this project approached it from a different angle, ie, a total rep= lacement for C++ which does have a rich toolset available. I want to use D = in this context in the future, and if that were the commitment we were cons= idering at Remedy, there&#39;s no way we would have gone for it.</div> <div><br></div><div>My hope from the Remedy experience was to prove that it= works in a commercial environment.</div><div>I went out on a REALLY massiv= e limb there, and as far as I can tell, it&#39;s well received (although it= took the better part of a year longer to get there than I promised).</div> <div>I&#39;d love to see it take the next step one day, ie, into the main c= ode-base... but the tools need to be rock solid before that can ever happen= .</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> Conclusion:<br> I think this 48 hour jam approach is a good test for the language and<br> it&#39;s infrastructure. I encourage everybody to try it (ideally with a<br=

The lesson is that we need to make this process smooth, since it mirrors<br=

It also highlights and magnifies time-wasters that are equally<br> unacceptable in a commercial environment.<br> <br> I don&#39;t think I made any converts this weekend wrt the above issues<br> encountered. I might have even just proved to them that they should<br> indeed stick with C# (the IDE&#39;s work!)... :(<br> <br> Please, we need a road-map, we need to prioritise these most basic<br> aspects of the experience, and we need to do it soon.<br> I might re-iterate my feeling that external IDE integration projects<br> should be claimed by the community officially, and user experience +<br> debugging issues should be first-class issues in the main d language<br> bug-tracker so everybody can see them, and everybody is aware of the stats.= <br> Also, the DMD front-end should be a lib offering auto-completion and<br> syntax hilighting data to clients.<br> <br> I&#39;m doing some more work on premake (a nice light buildsystem that<br> generated makefiles and project files for popular IDE&#39;s) to tightly<br> incorporate D into the various IDE&#39;s it supports.<br> <br> &lt;/endrant&gt;<br> </div></blockquote> <br> Other then that I have to fully agree with all the points you listed.<br> <br> Kind Regards<span class=3D"HOEnZb"><font color=3D"#888888"><br> Benjamin Thaut<br> <br> </font></span></blockquote></div><br></div></div> --e89a8f50378e1dd6b204e552cfe9--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde6b01eb804e552d797
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 18:49, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 1:06 AM, Benjamin Thaut wrote:

 Also if you are using Visual Studio 2012, you need to change the debugging
 engine because the new one can't deal with D code that has C++ debugging
 info.

This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.

And I don't blame you, but sadly, to achieve success in the Windows environment, I'm absolutely convinced it must work seamlessly with the de facto standard MS infrastructure. --e89a8fb1fde6b01eb804e552d797 Content-Type: text/html; charset=UTF-8 <div dir="ltr">On 1 September 2013 18:49, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com" target="_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/1/2013 1:06 AM, Benjamin Thaut wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Also if you are using Visual Studio 2012, you need to change the debugging<br> engine because the new one can&#39;t deal with D code that has C++ debugging info.<br> </blockquote> <br></div> This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.<br> </blockquote></div><br></div><div class="gmail_extra">And I don&#39;t blame you, but sadly, to achieve success in the Windows environment, I&#39;m absolutely convinced it must work seamlessly with the de facto standard MS infrastructure.</div> </div> --e89a8fb1fde6b01eb804e552d797--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11333dc89ca53e04e552e8d7
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 18:51, Benjamin Thaut <code benjamin-thaut.de> wrote:

 Am 01.09.2013 10:49, schrieb Walter Bright:

  On 9/1/2013 1:06 AM, Benjamin Thaut wrote:
 Also if you are using Visual Studio 2012, you need to change the
 debugging
 engine because the new one can't deal with D code that has C++
 debugging info.

This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.

Still the visual studio debugger has the best debugging experience you can currently get for D.

True, which is perhaps a little bit tragic. It's a good start, but lots of things just don't work right yet. May I re-iterate my point about the community claiming and supporting the IDE and debugger integration as a first class language feature with bugs in the main tracker... I know Walter does care about the DMD-Win64 debuginfo quality, but I don't think the debuginfo output is capable of addressing all the problems alone. --001a11333dc89ca53e04e552e8d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 18:51, Benjamin Thaut <span dir=3D"ltr= ">&lt;<a href=3D"mailto:code benjamin-thaut.de" target=3D"_blank">code benj= amin-thaut.de</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas= s=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Am 01.09.2013 10:49, schrieb Walter Bright:<= div><div class=3D"h5"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 9/1/2013 1:06 AM, Benjamin Thaut wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Also if you are using Visual Studio 2012, you need to change the<br> debugging<br> engine because the new one can&#39;t deal with D code that has C++<br> debugging info.<br> </blockquote> <br> This endless merry-go-round of MSC breaking the tools constantly is why<br> I went with my own toolset years ago.<br> </blockquote> <br></div></div> Still the visual studio debugger has the best debugging experience you can = currently get for D.<br> </blockquote></div><br></div><div class=3D"gmail_extra">True, which is perh= aps a little bit tragic. It&#39;s a good start, but lots of things just don= &#39;t work right yet.</div><div class=3D"gmail_extra">May I re-iterate my = point about the community claiming and supporting the IDE and debugger inte= gration as a first class language feature with bugs in the main tracker...<= /div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I know Walt= er does care about the DMD-Win64 debuginfo quality, but I don&#39;t think t= he debuginfo output is capable of addressing all the problems alone.</div><= /div> --001a11333dc89ca53e04e552e8d7--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e01537e42b0f14404e553106c
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 13:53, Jakob Ovrum <jakobovrum gmail.com> wrote:

 Sorry about the nonsensical reply, the web interface was acting up... this
 is the intended reply.


 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:

 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.

Why didn't you go with DMD-Win32? Because of OMF? implib and/or objconv is a hassle but probably less of a hassle than using the nascent DMD-Win64.

Ummm... just no. I'm just not even gonna touch that. It just feels 'fake', and I have no confidence in it at all. Maybe I'm being difficult, but I just want to work in the same world as all the other existing code on my ecosystem. I'm not making major concessions like that for the niche language when everything else is already working well. If that suggestion works flawlessly, then DMD-Win32 should be enhanced to embed those tools, and convert COFF libs to OMF automatically at link time. Overwhelmingly, the biggest complaint was a lack of symbolic information to
 assist with auto-completion. Visual-D tries valiantly, but it falls quite
 short of the mark.
 This goes back to the threads where the IDE guys are writing their own
 parsers, when really, DMD should be able to be built as a lib, with an API
 designed for using DMD as a lib/plugin.

Although I'm not convinced auto-completion is a vital feature (Microsoft's C++ IntelliSense is shit too), I agree that any time spent on custom parsers and best-effort semantic analysis is a complete waste of time. The only semantic analysis engine that is going to be sufficiently good for D is one from a compiler front-end. Apart from DMD, it's worth taking a look at SDC for this.

Microsoft's C# intellisense is absolutely spectacular, and there's no reason D couldn't be just as good. I think the deficiencies in the C++ experience come from the language it's self. C++ offers the opportunity for too many ambiguities. The preprocessor has gotta hinder the intellisense engine for one. some windows dev's want a CHM that looks like
 the typical Microsoft doc's people are used to. Those that aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + layout tree.

dmd2\windows\bin\d.chm

Noted. I suggest the installer put a link in the start menu :) Yes, we hit DMD bugs, like the one with opaque structs which required
 extensive work-arounds.
   struct MyStruct;
   MyStruct*[] = new MyStruct*[n];

I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?

It's an array of pointers. Pointers always .init to null...? --089e01537e42b0f14404e553106c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 13:53, Jakob Ovrum <span dir=3D"ltr">&= lt;<a href=3D"mailto:jakobovrum gmail.com" target=3D"_blank">jakobovrum gma= il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm= ail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex">Sorry about the nonsensical reply, the web interface was a= cting up... this is the intended reply.<div class=3D"im"> <br> <br> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b= order-left-style:solid;padding-left:1ex"> The only compiler you can realistically use productively in windows is<br> DMD-Win64, and that doesn&#39;t work out of the box.<br> </blockquote> <br></div> Why didn&#39;t you go with DMD-Win32? Because of OMF? implib and/or objconv= is a hassle but probably less of a hassle than using the nascent DMD-Win64= .</blockquote><div><br></div><div>Ummm... just no. I&#39;m just not even go= nna touch that. It just feels &#39;fake&#39;, and I have no confidence in i= t at all.</div> <div>Maybe I&#39;m being difficult, but I just want to work in the same wor= ld as all the other existing code on my ecosystem.</div><div>I&#39;m not ma= king major concessions like that for the niche language when everything els= e is already working well.</div> <div><br></div><div>If that suggestion works flawlessly, then DMD-Win32 sho= uld be enhanced to embed those tools, and convert COFF libs to OMF automati= cally at link time.</div><div><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg= b(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Overwhelmingly, the biggest complaint was a lack of symbolic information to= <br> assist with auto-completion. Visual-D tries valiantly, but it falls quite<b= r> short of the mark.<br> This goes back to the threads where the IDE guys are writing their own<br> parsers, when really, DMD should be able to be built as a lib, with an API<= br> designed for using DMD as a lib/plugin.<br> </blockquote> <br></div> Although I&#39;m not convinced auto-completion is a vital feature (Microsof= t&#39;s C++ IntelliSense is shit too), I agree that any time spent on custo= m parsers and best-effort semantic analysis is a complete waste of time. Th= e only semantic analysis engine that is going to be sufficiently good for D= is one from a compiler front-end. Apart from DMD, it&#39;s worth taking a = look at SDC for this.</blockquote> <div><br></div><div>Microsoft&#39;s C# intellisense is absolutely spectacul= ar, and there&#39;s no reason D couldn&#39;t be just as good. I think the d= eficiencies in the C++ experience come from the language it&#39;s self. C++= offers the opportunity for too many ambiguities. The preprocessor has gott= a hinder the intellisense engine for one.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> some windows dev&#39;s want a CHM that looks like<br> the typical Microsoft doc&#39;s people are used to. Those that aren&#39;t f= amiliar<br> with the CHM viewer; it&#39;s just HTML but with a nice index + layout tree= .<br> </blockquote> <br></div> dmd2\windows\bin\d.chm</blockquote><div><br></div><div>Noted. I suggest the= installer put a link in the start menu :)</div><div><br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1= px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:= 1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Yes, we hit DMD bugs, like the one with opaque structs which required<br> extensive work-arounds.<br> =C2=A0 struct MyStruct;<br> =C2=A0 MyStruct*[] =3D new MyStruct*[n];<br> </blockquote> <br></div> I&#39;m not sure this is a bug. How do you default initialize an array of s= tructs you don&#39;t know the .init values of?<br> </blockquote></div><div class=3D"gmail_extra"><br></div>It&#39;s an array o= f pointers. Pointers always .init to null...?</div></div> --089e01537e42b0f14404e553106c--
Sep 01 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Sunday, 1 September 2013 at 03:40:44 UTC, Michel Fortin wrote:
 On 2013-09-01 02:05:39 +0000, Manu <turkeyman gmail.com> said:

 I'm not using D anymore. I realized that with the time required 
 to maintain the toolset (including installer and Xcode plugin) 
 plus the time it'd take to make the language suitable to my 
 needs (Objective-C integration, perhaps ARM support for iOS), 
 all that by itself would probably be more than one full-time 
 job. As all this meta-work would seriously get in the way of my 
 actual work, I let it go. I'm not regretting that move.

 So I'm no longer using D, but I'm still hanging around here 
 from time to time because there's always something interesting 
 to read.

That's a pity, but I can understand: actually I'm relaying in calling Objective-C runtime functionality directly, having wrapped the *very-minimum* Cocoa things that I need for our projects... But the reality is that it's simply not feasible to use D for OSX applications apart from sticking with the posix/bsd face of the system, so one of the big three OS is out. I would also add that actually I'm not able to debug on OSX, and that's simply something that it's a show stopper for my colleague: the best results are coming from lldb, with decent stack trace and, alas I can also set breakpoints, but I'm not able to print any local at all. In all the tree platform, at least the debugger, as set of patch, as documentation in the main site (not in the wiki!), as support in the backend, should be the priority number one, in my opinion. - Paolo Invernizzi
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde6f7cc8d04e55351af
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 19:57, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 04:05, Manu wrote:

  Naturally, this is primarily a problem with the windows experience, but
 it's so frustrating that it is STILL a problem... how many years later?
 People don't want to 'do work' to install a piece of software. Rather,
 they expect it to 'just work'. We lost about 6 hours trying to get
 everyone's machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! I just
 kept promising people that it would save time overall... which I wish
 were true.

Was this only on Windows or were there problems on Linux/Mac OS X as well?

Well we never got OSX working (under mono-d), although this was mainly due to supporting apple infrastructure in the end. I think we wrangled the toolchain in the end, but never got everything linking; C++ dependencies got complicated. We eventually gave up, just wasting too much time, and he went off and did the music/sounds for the game... If you'd like to help me finish that OSX work we started together last year, that'd be really great for next time! :) Getting a workable environment:
 Unsurprisingly, the Linux user was the only person happy work with a
 makefile. Everybody else wanted a comfortable IDE solution (and the
 linux user would prefer it too).

I can understand that. IDE integration absolutely needs to be considered a first class feature
 of D.
 I also suggest that the IDE integration downloads should be hosted on
 the dlang download page so they are obvious and available to everyone
 without having to go looking, and also as a statement that they are
 actually endorsed by the dlanguage authorities. As an end-user, you're
 not left guessing which ones are good/bad/out of date/actually work/etc.

I completely agree. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
 only realistic choices available.

There's also DDT with Eclipse. It supports auto completion, go to definition, has an outline view and so on.

I've never met a C++ developer that likes Eclipse ;) But I should probably check it out. The OSX user would have preferred an XCode integration.

This one is a bit problematic since Xcode doesn't officially supports plugins. But it's still possible, as been shown by Michel Fortin with his D for Xcode plugin. One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to navigate
 (like Java and C#).
 We all wanted to ability to define class member functions outside the
 class definition:
    class MyClass
    {
      void method();
    }

    void MyClass.method()
    {
      //...
    }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want to quickly see what a class has and does.

Sounds like you want an outline view in the IDE. This is supported by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline view.

No, actually, as much as I keep banging on the IDE thing, in this case I absolutely don't want help from the IDE, I just want to look at my page of text, and be able to read a useful summary. Can you give me any good reasons why fully defined functions polluting the readability of a class definition could possibly be a good thing? I just don't get it... why would you ever want to break up the nice summary of what a class has&does, and why would you want to indent all of your functions an extra few tab levels by default? As a programmer, I spend a lot more time reading code than documentation, and much of that time is spent reading it in foreign places like github commit logs (limited horizontal space), diff/merge windows (hard to distinguish class API changes vs function body changes at a glance, since they're interleaved), even chat clients and communication tools. The IDE can't assist in any of these contexts. If you have to have an IDE to read your code, then something is really wrong. ...also, that implies you have good IDE integration, which is the a central part of my entire rant! ;) This argument is invalid until we have that, and at this point, it seems much more likely we may be able to define methods outside the class scope than have awesome IDE's. --e89a8fb1fde6f7cc8d04e55351af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 19:57, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On 2013-09-01 04:05, Manu wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> Naturally, this is primarily a problem with the windows experience, but<br> it&#39;s so frustrating that it is STILL a problem... how many years later?= <br></div><div class=3D"im"> People don&#39;t want to &#39;do work&#39; to install a piece of software. = Rather,<br> they expect it to &#39;just work&#39;. We lost about 6 hours trying to get<= br> everyone&#39;s machines working properly.<br> In the context of a 48 hour game jam, that&#39;s a terrible sign! I just<br=

were true.<br> </div></blockquote> <br> Was this only on Windows or were there problems on Linux/Mac OS X as well?<= /blockquote><div><br></div><div>Well we never got OSX working (under mono-d= ), although this was mainly due to supporting apple infrastructure in the e= nd. I think we wrangled the toolchain in the end, but never got everything = linking; C++ dependencies got complicated.</div> <div>We eventually gave up, just wasting too much time, and he went off and= did the music/sounds for the game...</div><div><br></div><div>If you&#39;d= like to help me finish that OSX work we started together last year, that&#= 39;d be really great for next time! :)</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Getting a workable environment:<br> <br> Unsurprisingly, the Linux user was the only person happy work with a<br> makefile. Everybody else wanted a comfortable IDE solution (and the<br> linux user would prefer it too).<br> </blockquote> <br></div> I can understand that.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> IDE integration absolutely needs to be considered a first class feature<br> of D.<br> I also suggest that the IDE integration downloads should be hosted on<br> the dlang download page so they are obvious and available to everyone<br> without having to go looking, and also as a statement that they are<br> actually endorsed by the dlanguage authorities. As an end-user, you&#39;re<= br> not left guessing which ones are good/bad/out of date/actually work/etc.<br=

<br></div> I completely agree.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the<br> only realistic choices available.<br> </blockquote> <br></div> There&#39;s also DDT with Eclipse. It supports auto completion, go to defin= ition, has an outline view and so on.</blockquote><div><br></div><div>I&#39= ;ve never met a C++ developer that likes Eclipse ;)</div><div>But I should = probably check it out.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The OSX user would have preferred an =C2=A0XCode integration.<br> </blockquote> <br></div> This one is a bit problematic since Xcode doesn&#39;t officially supports p= lugins. But it&#39;s still possible, as been shown by Michel Fortin with hi= s D for Xcode plugin.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> One more thing:<br> I&#39;ll just pick one language complaint from the weekend.<br> It is how quickly classes became disorganised and difficult to navigate<br> (like Java and C#).<br> We all wanted to ability to define class member functions outside the<br> class definition:<br> =C2=A0 =C2=A0class MyClass<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0void method();<br> =C2=A0 =C2=A0}<br> <br> =C2=A0 =C2=A0void MyClass.method()<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0//...<br> =C2=A0 =C2=A0}<br> <br> It definitely cost us time simply trying to understand the class layout<br> visually (ie, when IDE support is barely available).<br></div><div class=3D= "im"> You don&#39;t need to see the function bodies in the class definition, you<= br> want to quickly see what a class has and does.<br> </div></blockquote> <br> Sounds like you want an outline view in the IDE. This is supported by DDT i= n Eclipse. Even TextMate on Mac OS X has a form of outline view.</blockquot= e><div><br></div><div>No, actually, as much as I keep banging on the IDE th= ing, in this case I absolutely don&#39;t want help from the IDE, I just wan= t to look at my page of text, and be able to read a useful summary.</div> <div>Can you give me any good reasons why fully defined functions polluting= the readability of a class definition could possibly be a good thing?<br><= /div><div>I just don&#39;t get it... why would you ever want to break up th= e nice summary of what a class has&amp;does, and why would you want to inde= nt all of your functions an extra few tab levels by default?</div> <div><br></div><div>As a programmer, I spend a lot more time reading code t= han documentation, and much of that time is spent reading it in foreign pla= ces like github commit logs (limited horizontal space), diff/merge windows = (hard to distinguish class API changes vs function body changes at a glance= , since they&#39;re interleaved), even chat clients and communication tools= . The IDE can&#39;t assist in any of these contexts. If you have to have an= IDE to read your code, then something is really wrong.</div> <div><br></div><div>...also, that implies you have good IDE integration, wh= ich is the a central part of my entire rant! ;)<br></div><div>This argument= is invalid until we have that, and at this point, it seems much more likel= y we may be able to define methods outside the class scope than have awesom= e IDE&#39;s.</div> </div></div></div> --e89a8fb1fde6f7cc8d04e55351af--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde66f846604e55363d9
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 20:22, Gary Willoughby <dev nomad.so> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:

 We all wanted to ability to define class member functions outside the
 class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want
 to quickly see what a class has and does.

Uggh! I absolutely do not agree with this. You should rely on documentation or an IDE class overview for these things *not* alter the language. In lieu of IDE support just use ddoc comments for methods and properties and compile the documentation for each build.

I think that's unrealistic. People need to read the code in a variety of places. Github commit logs (limited horizontal space), diff/merge clients, office communication/chat tools. If the code depends on an IDE to be readable, then that's gotta be considered an epic fail! Give me one advantage to defining methods inline? I only see disadvantages. Lots of them. --e89a8fb1fde66f846604e55363d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 20:22, Gary Willoughby <span dir=3D"lt= r">&lt;<a href=3D"mailto:dev nomad.so" target=3D"_blank">dev nomad.so</a>&g= t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <div class=3D"im">On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:<= br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We all wanted to ability to define class member functions outside the class= <br> definition:<br> =C2=A0 class MyClass<br> =C2=A0 {<br> =C2=A0 =C2=A0 void method();<br> =C2=A0 }<br> <br> =C2=A0 void MyClass.method()<br> =C2=A0 {<br> =C2=A0 =C2=A0 //...<br> =C2=A0 }<br> <br> It definitely cost us time simply trying to understand the class layout<br> visually (ie, when IDE support is barely available).<br> You don&#39;t need to see the function bodies in the class definition, you = want<br> to quickly see what a class has and does.<br> </blockquote> <br></div> Uggh! I absolutely do not agree with this. You should rely on documentation= or an IDE class overview for these things *not* alter the language. In lie= u of IDE support just use ddoc comments for methods and properties and comp= ile the documentation for each build.<br> </blockquote><div><br></div><div>I think that&#39;s unrealistic. People nee= d to read the code in a variety of places. Github commit logs (limited hori= zontal space), diff/merge clients, office communication/chat tools.</div> <div>If the code depends on an IDE to be readable, then that&#39;s gotta be= considered an epic fail!</div><div><br></div><div>Give me one advantage to= defining methods inline? I only see disadvantages. Lots of them.</div> </div></div></div> --e89a8fb1fde66f846604e55363d9--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b33d54852548704e5536cba
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 20:40, Dicebot <public dicebot.lv> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:

 ...

 </endrant>


programming for Windows!" :) Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway, key problem (as far as I can see) here is that few of D developers have both experience and personal interest in any IDE/Windows focus as well as related tool stack. D has some nice flavor of anarchy - both like it and consider it a problem.

Plenty of the key contributors are Windows users, including Walter I believe. My suggestion is to encourage dev's to use the same tools the end users are using, and declare them first-class language features. I reckon it'll improve quick-smart under that environment. --047d7b33d54852548704e5536cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 20:40, Dicebot <span dir=3D"ltr">&lt;<= a href=3D"mailto:public dicebot.lv" target=3D"_blank">public dicebot.lv</a>= &gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

<div class=3D"im">On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:<= br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> ...<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> &lt;/endrant&gt;<br> </blockquote></blockquote> <br> Thought number one after reading &quot;This is why I absolutely hate progra= mming for Windows!&quot; :) Was pretty happy with vim, grep, gdb and makefi= les on Linux. Anyway, key problem (as far as I can see) here is that few of= D developers have both experience and personal interest in any IDE/Windows= focus as well as related tool stack. D has some nice flavor of anarchy - b= oth like it and consider it a problem.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Plenty of the key c= ontributors are Windows users, including Walter I believe.</div><div class= =3D"gmail_extra">My suggestion is to encourage dev&#39;s to use the same to= ols the end users are using, and declare them first-class language features= . I reckon it&#39;ll improve quick-smart under that environment.</div> </div> --047d7b33d54852548704e5536cba--
Sep 01 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 September 2013 at 14:39:37 UTC, Manu wrote:
 Plenty of the key contributors are Windows users, including 
 Walter I
 believe.

Yes but I'd be surprised to learn that their daily D application domain is as IDE-demanding as your game dev experience.
 My suggestion is to encourage dev's to use the same tools the 
 end users are
 using, and declare them first-class language features. I reckon 
 it'll
 improve quick-smart under that environment.

I simply don't see this working with current D development model. After all, open-source is not about simply working for free - it is about working for yourself and then sharing it. But there needs to be some _personal_ interest in implementing something, end users are just side effect. Well, of course I can't say anything about D dev motivation but I simply can't imagine people spending that much time on something they don't need, are not interested in and gain nothing from. If anything, that indicates that there needs to be more game dev guys among the core devs.
Sep 01 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-09-01 13:29:21 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-09-01 15:18, Andrej Mitrovic wrote:
 
 How is deprecating makefiles easier than making whatever IDE that
 you're using just call a 'make' command when you click a button? Even
 VS comes with nmake and friends.

Like the Xcode project does. It calls "make" when building but contains a separate dummy target to allow autocompletion and similar features to work. For some reason those features don't work for make targets.

That's because the Xcode indexer indexes files it knows are included in a target, and Xcode doesn't parse makefiles and thus can't know which files it'll compile (not that it could do so reliably anyway). With another target were all the c/cpp files are marked as being part of it, the indexer does its job. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Sep 01 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 16:59, Michel Fortin wrote:

 That's because the Xcode indexer indexes files it knows are included in
 a target, and Xcode doesn't parse makefiles and thus can't know which
 files it'll compile (not that it could do so reliably anyway). With
 another target were all the c/cpp files are marked as being part of it,
 the indexer does its job.

It's make sense but it's not very convenient. -- /Jacob Carlborg
Sep 01 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 1 September 2013 at 14:14:05 UTC, Manu wrote:
 Microsoft's C# intellisense is absolutely spectacular, and 
 there's no
 reason D couldn't be just as good.

There's one very good reason: templates. It makes it substantially more complicated. Further, the C# compiler was designed with Visual Studio integration in mind from the beginning, while DMD is an evolution of DMC++.
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde6cb6f7304e553f5b0
Content-Type: text/plain; charset=UTF-8

On 1 September 2013 23:24, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 13:44, Mike Parker wrote:

  I have a batch file tied to a command prompt shortcut that always sets
 the D environment when I launch it. Updating DMD is a matter of deleting
 the old directory and unzipping the zip file.

Or just use DVM: https://github.com/jacob-**carlborg/dvm<https://github.com/jacob-carlborg/dvm>

I think infrastructure solutions like this are probably fine, but they're worthless unless they're installed by default as part of the standard DMD installer. If it's robust, convince Walter to include it in the standard installer package? --e89a8fb1fde6cb6f7304e553f5b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 1 September 2013 23:24, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On 2013-09-01 13:44, Mike Parker wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I have a batch file tied to a command prompt shortcut that always sets<br> the D environment when I launch it. Updating DMD is a matter of deleting<br=

</blockquote> <br></div> Or just use DVM:<br> <br> <a href=3D"https://github.com/jacob-carlborg/dvm" target=3D"_blank">https:/= /github.com/jacob-<u></u>carlborg/dvm</a></blockquote><div><br></div><div>I= think infrastructure solutions like this are probably fine, but they&#39;r= e worthless unless they&#39;re installed by default as part of the standard= DMD installer.</div> <div>If it&#39;s robust, convince Walter to include it in the standard inst= aller package?</div></div></div></div> --e89a8fb1fde6cb6f7304e553f5b0--
Sep 01 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Sep-2013 06:05, Manu пишет:
 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the stars
 aligned such that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various versions
 of VisualStudio, and either 'just work', or amend sc.ini on its own. Or
 the installer needs to amend sc.ini. Either way, leaving it to a user to
 fiddle with an ini file just isn't acceptable. We had to google
 solutions to this problem, and even then, we had trouble with the paths
 we added to sc.ini; are spaces acceptable? Do they have quites around
 them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), libraries
 should be automatically detected and path entries added in there too:
    C:\Program Files (x86)\Microsoft SDKs\...
    C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and each of us
 had to configure them ourselves.

Just find a way so that it isn't hardcoded (which Walter inevitably seems to end up with).
 Getting a workable environment:

 Unsurprisingly, the Linux user was the only person happy work with a
 makefile. Everybody else wanted a comfortable IDE solution (and the
 linux user would prefer it too).

 !!!!!!!!!
 This has to be given first-class attention!
 I am completely and utterly sick of this problem. Don made a massive
 point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
 how absolutely important this is.
 !!!!!!!!!

+1 Strangely I went from VisualD to Sublime Text and never look back - it's far simpler (the overhead of having project/configuration etc. per short snippet of code I need to try), and STABILITY issues are well, need to be addressed.
 I have come to the conclusion that treating IDE integration as ancillary
 projects maintained by usually just one single member of the community
 has absolutely failed.
 I suggest:
   * These should be made central D community projects.
   * I think they should be hosted in the same github organisation as DMD.

Maybe. Though this move alone hardly buys anything unlike e.g. being prominently featured on dlang.org download page that would rise the number of users and bugs reported though (that you propose though).
   *** As many contributors as possible should be encouraged to work with
 them every day.

So true. But in case of say VisualD there simply not enough of folks with right kind of expertise - that are familiar with VisualStudio SDK + the number of arcane steps to build/integrate it AND have time/inclination to work on it. Ditto with other IDEs, it's a lot of upfront work to learn the infrastructure + as anything interactive there is no easy test suite to check your tweaks/hacks.
     - Deprecate DMD makefiles. Seriously! Insist that contributors use
 the IDE bindings to work on DMD.

While I understand the sentiment it is not a good idea. Makefiles are crap but some modern build tool would do just fine (certainly not specific per IDE project). _Having_ to use some IDE just hurts automation and adds dependency AND rises the barrier of entry (we'd lose all the editor + cmd line guys, and hell they are too amazing to lose). Not only that but toolchains and core libraries are all about batch processing and easily reproducible test runs - nothing like an interactive app. Hence the large difference in mindset w.r.t. say debugging, as batch tools are far more amendable to printf/assert style of debugging (more specifically postmortem style, including analyzing core dumps/stack traces). Unless there is some organized effort behind "interactive D" things will keep moving slowly. -- Dmitry Olshansky
Sep 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 18:24, Dmitry Olshansky wrote:

 So true. But in case of say VisualD there simply not enough of folks
 with right kind of expertise - that are familiar with VisualStudio SDK +
 the number of arcane steps to build/integrate it AND have
 time/inclination to work on it.
 Ditto with other IDEs, it's a lot of upfront work to learn the
 infrastructure + as anything interactive there is no easy test suite to
 check your tweaks/hacks.

And Xcode which doesn't even officially supports plugins. -- /Jacob Carlborg
Sep 01 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-09-01 19:25:10 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-09-01 18:24, Dmitry Olshansky wrote:
 
 So true. But in case of say VisualD there simply not enough of folks
 with right kind of expertise - that are familiar with VisualStudio SDK +
 the number of arcane steps to build/integrate it AND have
 time/inclination to work on it.
 Ditto with other IDEs, it's a lot of upfront work to learn the
 infrastructure + as anything interactive there is no easy test suite to
 check your tweaks/hacks.

And Xcode which doesn't even officially supports plugins.

But reverse-engineering Objective-C classes knowing only the name of classes and their methods is so much fun! How can people not be interested in running Xcode inside the debugger to follow what calls what? Then all you have to do is inject some code at the right place to subvert the IDE into compiling your D code, tracking D module dependencies, and suggesting completions as you type. Piece of cake! -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Sep 01 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 2:04 PM, Michel Fortin wrote:
 Piece of cake!

I agree!
Sep 01 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 23:04, Michel Fortin wrote:

 But reverse-engineering Objective-C classes knowing only the name of
 classes and their methods is so much fun! How can people not be
 interested in running Xcode inside the debugger to follow what calls
 what? Then all you have to do is inject some code at the right place to
 subvert the IDE into compiling your D code, tracking D module
 dependencies, and suggesting completions as you type. Piece of cake!

Hehe :) -- /Jacob Carlborg
Sep 02 2013
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/31/2013 07:05 PM, Manu wrote:

 IDE integration absolutely needs to be considered a first class 

 D.

This is probably a repeat but Brian Schott has just announced DCD: http://forum.dlang.org/post/hrbzrholeoyyriumddjd forum.dlang.org Ali
Sep 01 2013
prev sibling next sibling parent "Volcz" <volcz kth.se> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 </endrant>

Completely agree with Manu! I work in the Java + telecom world of programming and recently graduated, so that's the majority of my experience. From what I've seen and experienced is that most today programmers can't live without an IDE and a rock solid tool chain. I've seen many solutions posted in this thread to parts of the problems, eg auto complete, debugging etc. The thing with an IDE is that it has "JUST WORK" it should work with all the different components seamlessly. The question I would like to ask is how can WE as a COMMUNITY improve this situation? Official IDE support? Official "IDE components"? Roadmap? Other languages like Java have corporate backing. What difference makes this? Why doesn't we have a roadmap? How does other open source communities work and what can we learn from them? Sorry for the un-structure of my post.
Sep 01 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 1 September 2013 at 14:32:18 UTC, Manu wrote:
 On 1 September 2013 19:57, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 04:05, Manu wrote:

I've never met a C++ developer that likes Eclipse ;) But I should probably check it out.

Well, I'm mostly a C guy, but I prefer working in Eclipse over others (C::B, Anjuta etc.) For this reason, I look forward to DDT. However, for the time being, what keeps me far from DDT is the very reason that I embraced Eclipse/CDT for: the debugger. DDT lacks it.
Sep 01 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 1 September 2013 at 13:20:50 UTC, Manu wrote:
 Why complicate the issue? What's wrong with readable code?

Well, the fact is, AFAIK, it's never been an issue for C# and Java programmers. In fact, it' the first time I hear about people complaining on this one. Maybe because of the generalized usage of IDEs, I guess. I do agree that IDEs DO matter. It really does make a monumental difference. Without them, Java and C# programming would be a chore. But with them, you are often more productive than in Python (opinion based on my own professionnal experience). The problem is, maintaining one or several IDE plugins is going to be nearly a full-time job, even if the compiler is a library. Or you need a very motivated person like Iain Buclain to keep updating the tools. I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market.
Sep 01 2013
prev sibling next sibling parent Arjan <arjan ask.me> writes:
On Sun, 01 Sep 2013 19:14:11 +0200, eles <eles eles.com> wrote:

 On Sunday, 1 September 2013 at 14:32:18 UTC, Manu wrote:
 On 1 September 2013 19:57, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 04:05, Manu wrote:

I've never met a C++ developer that likes Eclipse ;) But I should probably check it out.

Well, I'm mostly a C guy, but I prefer working in Eclipse over others (C::B, Anjuta etc.) For this reason, I look forward to DDT. However, for the time being, what keeps me far from DDT is the very reason that I embraced Eclipse/CDT for: the debugger. DDT lacks it.

I too use Eclipse+CDT (and other plugins like linuxtools, pyDEV)for C/C++ on Linux/BSD. Eclipse is also the "de facto" standard for C/C++ in the embedded world. See for example www.yoctoproject.org. Also android development toolkit (ADT) is eclipse based. See http://developer.android.com/sdk/index.html. Eclipse+CDT has improved a _lot_ over the last 5/6 years. It has become my 'IDE' of choice for C/C++ development over C::B, codelite, anjuta, KDevelop, VIM etc on Linux/BSD. On windows I still prefer MSVS for C++ which is still way ahead of eclipse+CDT, but the gap is closing... In my experience good tools (especially debugger!) and integration with MSVS/Eclipse/Xcode are mandatory to gain broader adaption. Most of my co-workers can't even get anything done without a IDE!
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 07:42:47 UTC, Walter Bright wrote:
 On 8/31/2013 7:05 PM, Manu wrote:
 The only compiler you can realistically use productively in 
 windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the 
 stars aligned such
 that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of 
 various versions of
 VisualStudio, and either 'just work', or amend sc.ini on its 
 own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a 
 user to fiddle with
 an ini file just isn't acceptable. We had to google solutions 
 to this problem,
 and even then, we had trouble with the paths we added to 
 sc.ini; are spaces
 acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), 
 libraries should
 be automatically detected and path entries added in there too:
   C:\Program Files (x86)\Microsoft SDKs\...
   C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and 
 each of us had to
 configure them ourselves.

The default sc.ini contains: ----------------------------- [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib";\dm\lib DFLAGS="-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe VCINSTALLDIR=%VCINSTALLDIR% WindowsSdkDir=%WindowsSdkDir% ---------------------------------- When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work". What went wrong, specifically?

I can make the installer detect which versions of Visual Studio are installed and the path they are installed. Would I rather I have the installer modify the installed sc.ini or set an environment variable?
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 19:29:00 UTC, Brad Anderson wrote:
 I can make the installer detect which versions of Visual Studio 
 are installed and the path they are installed.  Would I rather 
 I have the installer modify the installed sc.ini or set an 
 environment variable?

I meant "Would you rather I..."
Sep 01 2013
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 Documentation:

 Okay for the most part, but some windows dev's want a CHM that 
 looks like
 the typical Microsoft doc's people are used to. Those that 
 aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + 
 layout tree.

What can be improved in the CHM that's currently bundled with DMD?
Sep 01 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2013 9:11 PM, Manu wrote:
 If I were gonna be picky, the index seems incomplete. Open it up, click the
 'index' tab, and type tostringz... it's not there.
 I think it's also very unnatural for a chm to have the module's functions all
on
 the one page. Can they be broken up into separate articles?

Of course. The generation of chm is all in the git repository - anyone can fix it if they've a mind to!
Sep 02 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/1/13, Walter Bright <newshound2 digitalmars.com> wrote:
 3. provide commented-out example settings for each variant of VS as we
 discover
 what they should be

Imagine if after installing Windows 7 you were provided with a boot.ini file which didn't work, but hey, it had commented out examples on how to make the system properly boot. You weren't even give info on which partition the system installed, the manual says "Check your hard drive vendor instructions". This isn't a 1-click install, and it's still a usability issue. I know you seem to hate automation (because it sometimes fails), but having each individual person waste hours on initial setup is much worse than having a script which can potentially fail. At least the script can be fixed once the bug is reported, and it can be tested.
Sep 01 2013
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote:
 I think at this point, what D needs is a bit of commercial 
 support from a company like JetBrains or some equivalent. Maybe 
 there is now an opportunity for founding such a company, one 
 that would specialize in building professional tools around the 
 D language. I believe the language and the compilers are stable 
 enough to grow a serious business around them. If we compare to 
 what the state of C++ compilers was before 2000, I believe we 
 are much better off. And that was just over a decade ago. Who 
 knows what the state of D will be in 5 years ? So yes, there is 
 a case to be made for growing a company around pro D tools, and 
 the first company that does it will grab the whole market.

It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist.
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 14:14:05 UTC, Manu wrote:
 On 1 September 2013 13:53, Jakob Ovrum <jakobovrum gmail.com> 
 wrote:
 dmd2\windows\bin\d.chm

Noted. I suggest the installer put a link in the start menu :)

https://github.com/D-Programming-Language/installer/pull/21
Sep 01 2013
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 1 September 2013 at 14:37:13 UTC, Manu wrote:
 On 1 September 2013 20:22, Gary Willoughby <dev nomad.so> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:

 We all wanted to ability to define class member functions 
 outside the
 class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you
 want
 to quickly see what a class has and does.

Uggh! I absolutely do not agree with this. You should rely on documentation or an IDE class overview for these things *not* alter the language. In lieu of IDE support just use ddoc comments for methods and properties and compile the documentation for each build.

I think that's unrealistic. People need to read the code in a variety of places. Github commit logs (limited horizontal space), diff/merge clients, office communication/chat tools. If the code depends on an IDE to be readable, then that's gotta be considered an epic fail! Give me one advantage to defining methods inline? I only see disadvantages. Lots of them.

That's because you're suggesting that if we can't get an immediate overview of class code then it's unreadable which is complete nonsense. Classes do sometimes grow and become large and getting an overview is hard but that doesn't mean the code is unreadable or of low quality. In fact if the developers have bothered to write the associated ddoc comments while developing the code, creating overviews is as trivial as adding -D to the compile command. An overview of the class's interface should be the job of the documentation or a nice tool such as DDOC, an IDE class overview (there are many), class diagrams, ctags, etc... IMHO it's total folly to further complicate the language to provide you with something that already exists and i think this particular point is just because of your personal preference on how code should be structured which is obviously drawn from C++.
Sep 01 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 1 Sep 2013 23:20:37 +1000
Manu <turkeyman gmail.com> wrote:

 On 1 September 2013 17:46, Nick Sabalausky <
 SeeWebsiteToContactMe semitwist.com> wrote:
 
 On Sun, 01 Sep 2013 06:45:48 +0200
 "Kapps" <opantm2+spam gmail.com> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class
 definition, you want
 to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

I see it as the job of doc generators.

Why complicate the issue? What's wrong with readable code?

I spent several years using C/C++ exclusively (and was happy with it at the time) and I still don't understand what's "readable" about having a class's members separate from the class itself. It's also a non-DRY maintenance PITA and one of the biggest reasons I left C/C++. I don't like complicating things, and I like readable code. That's why I find C++-style class definitions intolerable. And what's so complicated about tossing in those two little characters: -D
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 20:00:19 UTC, Walter Bright wrote:
 On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:
 I know you seem to hate automation (because it sometimes 
 fails), but
 having each individual person waste hours on initial setup is 
 much
 worse than having a script which can potentially fail. At 
 least the
 script can be fixed once the bug is reported, and it can be 
 tested.

Back in the bad old Datalight C days, I relied on the Microsoft linker which came on the DOS system disks. Unfortunately, Microsoft constantly changed it, even with the same version of DOS. Worse, numerous other Microsoft products came with yet other versions of LINK.EXE. All those linkers behaved differently. It was a frackin' nightmare to support customers with them. I used to have floppy disks packed full of just different versions of LINK.EXE. This drove me to get our own linker (BLINK.EXE). While it wasn't perfect, either, at least I could actually fix problems with it rather than throwing up my hands in rage being unable to control the situation. There's no way we can automate VC 2014 so its unpredictable configuration will work. All we can do is react after the fact. I don't hate automation. sc.ini works out of the box with the default install of VS 2010. What I need from you guys and your different VS installs is, for each one, a bug report with what is necessary to get it installed. Then we can add it to the modern version of my floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005. Even if they make a release that the D installer doesn't properly detect fixing that is a 5 minute job by one person (probably me) versus requiring every user to spend a half hour or more (6 hours in Manu's experience) trying to figure out how to get 64 bit working.
Sep 01 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/1/13, Brad Anderson <eco gnuk.net> wrote:
 What I need from you guys and your different VS installs is,
 for each one, a bug report with what is necessary to get it
 installed. Then we can add it to the modern version of my
 floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 21:10:23 UTC, Walter Bright wrote:
 On 9/1/2013 12:28 PM, Brad Anderson wrote:
 I can make the installer detect which versions of Visual 
 Studio are installed
 and the path they are installed.  Would I rather I have the 
 installer modify the
 installed sc.ini or set an environment variable?

dmd is specifically made to not rely on us setting any environment or system registry variables. So modifying sc.ini is the only solution.

Sounds good. I'll get started.
Sep 01 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
Manu

(answering the OP)

Stupid me, I just adressed similar issues in 
http://forum.dlang.org/thread/jlssvljpdgxlubdajwyy forum.dlang.org 
("End user experience with D") because first I thought this here 
was about game development (which I don't care about).

Short version: I agree with Manu. Completely. Strongly.

One warning tough: We should differentiate between "essential" 
and "nice but not urgent". For a simple reason: Feasibility.

Sure, .chm help would be nice for Windows users but frankly, good 
doc at all are more important; if it's, say, HTML that's good 
enough for a start.

As for an IDE we should definitely favour something cross 
platform (and non-java!!!) rather than caring about peculiarities 
of Windows, OSX, lx/kde, etc. Those can be done later. Really 
important is to have a base asap.

The killer: Debugging.

GDB is bare minimum and seeing adresses of structures rather than 
the members and their values is basically worthless.

When trying a new language I usually do a small project: 
"osnsort", i.e. a utility that takes (usually via a pipe from 'du 
-h') lines with OS style numbers (like "4,3M" for 4,4MB filesize) 
and then sorts those lie properly (unlike sort which lousily 
fails).
While D nicely showed some of its strengths and the coding was 
really enjoyable and the docs good enough for someone with a C 
background) I soon found myself inserting lots of "debug" 
statements as a "more elegant" version of the old "#ifdef DEBUG 
printf(...) #endif". *** YUCK!!! ***

Putting it bluntly: D is so great, so powerful, so nice language 
that it's worth a lot of efforts. With any other language I would 
have turned away and taken it to be a hobby thingy.

So, we must not please everyone and take care of their OS issues 
right now, but we definitely need some kind of, if somewhat 
crude, working base in terms of debugger support, IDE and docs.

A+ -R
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 11:43:53 UTC, Mike Parker wrote:
 I have a batch file tied to a command prompt shortcut that 
 always sets the D environment when I launch it. Updating DMD is 
 a matter of deleting the old directory and unzipping the zip 
 file. Editing is a matter of launching Sublime Text 2. 
 Compiling is alt-tabbing to the command prompt and typing "dub 
 build". It's a painless process and I never have any trouble. 
 Of course, I don't try to use the MS tools, or build DMD 
 myself. That way lies pain.

For a few releases now the D installer for Windows has created a start menu shortcut that launches cmd.exe with dmd et al. added to the PATH. It also adds to the PATH during installation if you let it.
Sep 01 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
=============== INTERRUPT ================

Can we, please, just for a moment leave details aside?



Dear Walter Bright

There are currently 3 threads addressing more or less the same 
issue: user experience.

You have, no doubt, created a wonderful, great and promising 
language. That's why we're here.

Yet we have heard from users who left. Not because D isn't good 
enough - actually it's so good that some at stay loosely 
connected and read and write here - but because in order to be 
useful and to grow and spread all over the universe, the power, 
the beauty and the elegance of a language must be found in 
practically interaction, too. In other words: user experience.

It seems in that context there are mainly 3 points coming up:

- IDE
- Docs
- Debugging

And I'd like to add a 4th: C library bindings.

Obviously neither you nor any 3 or 5 of us can possibly make 
*every*one happy. Equally obviously, making too many not happy 
leads to potential D users leaving the language.

Shouldn't we find some reasonable common grounds? Shouldn't we at 
least discuss and create a rough ToDo route with some priorities?

There are, for instance, tools out there that allow to create 
various common formats for documentation, incl. HTML and .chm.
Shouldn't we make an effort to identify and agree (or, if 
necessary, a dictum by you and/or Andrei) on some cross platform 
tool for documentation so as to be able to create all needed 
formats from one set of docs?

Thanks for D and - please - let us do the next step now. Let us 
not debate over Eclipse vs. Vim but agree that at least 1 cross 
platform IDE must be supported along with at least 1 cross 
platform Editor. Let us not only address language issues and 
problems with a narrow view but let us at the same time keep our 
mind open for the larger picture.

And let us agree that a not yet perfect language along with well 
useable and realiably working tools is worth at least as much as 
an ever more refined language with lousy, alpha, broken old, or 
simply not reasonably useable tools.
The same goes for the tools. Let us have 1 set of cross platform 
tools, even primitive ones but realiable and reliably working 
ones rather than striving to have a variety tools for each and 
every OS and whim addressing every minute detail coming up.

Let's build a base - and then conquer the world.
Sep 01 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 02, 2013 at 12:32:06AM +1000, Manu wrote:
 On 1 September 2013 19:57, Jacob Carlborg <doob me.com> wrote:

 Sounds like you want an outline view in the IDE. This is supported
 by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline
 view.

No, actually, as much as I keep banging on the IDE thing, in this case I absolutely don't want help from the IDE, I just want to look at my page of text, and be able to read a useful summary. Can you give me any good reasons why fully defined functions polluting the readability of a class definition could possibly be a good thing? I just don't get it... why would you ever want to break up the nice summary of what a class has&does, and why would you want to indent all of your functions an extra few tab levels by default?

If I wanted to to that, I'd setup folding in vim to fold function bodies. There's nothing inherently wrong with fully-defined functions inside their class -- Java does it, and I don't hear Java programmers complain about that.
 As a programmer, I spend a lot more time reading code than
 documentation, and much of that time is spent reading it in foreign
 places like github commit logs (limited horizontal space), diff/merge
 windows (hard to distinguish class API changes vs function body
 changes at a glance, since they're interleaved), even chat clients and
 communication tools. The IDE can't assist in any of these contexts. If
 you have to have an IDE to read your code, then something is really
 wrong.

 ...also, that implies you have good IDE integration, which is the a
 central part of my entire rant! ;)
 This argument is invalid until we have that, and at this point, it
 seems much more likely we may be able to define methods outside the
 class scope than have awesome IDE's.

I dunno, this sounds to me like maybe your class design needs to get looked at. :) I usually try to structure my code such that class methods are relatively short and self-contained, and I don't end up with classes with 50 methods each 10 pages long. T -- Customer support: the art of getting your clients to pay for your own incompetence.
Sep 01 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Sep 01, 2013 at 12:40:00PM +0200, Dicebot wrote:
 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
...
</endrant>


Thought number one after reading "This is why I absolutely hate programming for Windows!" :)

+1. :)
 Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway,
 key problem (as far as I can see) here is that few of D developers
 have both experience and personal interest in any IDE/Windows focus as
 well as related tool stack. D has some nice flavor of anarchy - both
 like it and consider it a problem.

The thing is, we keep hearing complaints about how D IDE integration is bad, etc., but it seems like not many people are willing to do something about it. What we need is somebody who is (1) dedicated to D, (2) dedicated to making IDE integration for D work nicely, (3) produce lots of code to make it work. Forcing people to change the way to work on D just so you can have IDE integration probably won't have much of an effect. For instance, I wouldn't touch an IDE with a 10-foot pole. Will I still contribute to D? Sure. Will I do something about IDE integration because everyone complains about it? Unlikely. Will I be glad if somebody steps up and say, here's what I've been doing to make D IDE integration better? I'd fully support it. The question is whether there is such a somebody. :) T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright wrote:
 On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:
 On 9/1/13, Brad Anderson <eco gnuk.net> wrote:
 What I need from you guys and your different VS installs is,
 for each one, a bug report with what is necessary to get it
 installed. Then we can add it to the modern version of my
 floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)

Pull requests are, of course, welcome.

https://github.com/D-Programming-Language/installer/pull/22 It can detect (through registry keys) the paths of Visual C++ 10, 11, and 12 (2010, 2012, and 2013) and Windows SDK 7.0A, 7.1A, 8.0, and 8.1. It modifies the sc.ini installed from the zip file by substituting the defaults with the detected paths (which makes it important I have accurately reflected what the sc.ini defaults will be). I only have VC 10 to test with myself (and lack the disk space to have concurrent installations of all 3). I installed the Windows SDK 7.0A (comes with VC 10), 8.0, and 8.1 though I couldn't actually use 8.0 and 8.1 successfully because of the path tail issue Dmitry pointed out (and you opened a pull request to fix). The combination of VC 10 and SDK 8.1 did not work (link errors) but VC 10 with 7.0A worked perfectly. I imagine you need to pair the SDK with the version of VC that was released around the same time.
Sep 01 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 September 2013 at 01:41:51 UTC, Brad Anderson wrote:
 On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright 
 wrote:
 On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:
 On 9/1/13, Brad Anderson <eco gnuk.net> wrote:
 What I need from you guys and your different VS installs is,
 for each one, a bug report with what is necessary to get it
 installed. Then we can add it to the modern version of my
 floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)

Pull requests are, of course, welcome.

https://github.com/D-Programming-Language/installer/pull/22 It can detect (through registry keys) the paths of Visual C++ 10, 11, and 12 (2010, 2012, and 2013) and Windows SDK 7.0A, 7.1A, 8.0, and 8.1. It modifies the sc.ini installed from the zip file by substituting the defaults with the detected paths (which makes it important I have accurately reflected what the sc.ini defaults will be). I only have VC 10 to test with myself (and lack the disk space to have concurrent installations of all 3). I installed the Windows SDK 7.0A (comes with VC 10), 8.0, and 8.1 though I couldn't actually use 8.0 and 8.1 successfully because of the path tail issue Dmitry pointed out (and you opened a pull request to fix). The combination of VC 10 and SDK 8.1 did not work (link errors) but VC 10 with 7.0A worked perfectly. I imagine you need to pair the SDK with the version of VC that was released around the same time.

Err, ignore the last sentence. I forgot that it was probably the path tail issue I was hitting.
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde63f69ed04e55d8725
Content-Type: text/plain; charset=UTF-8

There are only 2 visual studio related environment variables on my machine:

VS100COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\Tools\
VS110COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\Tools\

But in general, I reckon it's probably bad practise to rely on environment
variables in Windows. They're usually a complete mess, and hard to manage.


On 2 September 2013 03:24, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:

 To get it to work with say VS11 I had to kill VCINSTALLDIR &
 WindowsSDKDir and
 set LIB/LINKCMD paths by hand in Environement64.
 Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
 VC11/WinSDK8.

What environment variables did VS11 set?

--e89a8fb1fde63f69ed04e55d8725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">There are only 2 visual studio related environment variabl= es on my machine:<div><br></div><div>VS100COMNTOOLS =3D=C2=A0C:\Program Fil= es (x86)\Microsoft Visual Studio 10.0\Common7\Tools\<br></div><div>VS110COM= NTOOLS =3D=C2=A0C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7= \Tools\</div> <div><br></div><div>But in general, I reckon it&#39;s probably bad practise= to rely on environment variables in Windows. They&#39;re usually a complet= e mess, and hard to manage.</div></div><div class=3D"gmail_extra"><br><br> <div class=3D"gmail_quote">On 2 September 2013 03:24, Walter Bright <span d= ir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_bla= nk">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"im">On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> To get it to work with say VS11 I had to kill VCINSTALLDIR &amp; WindowsSDK= Dir and<br> set LIB/LINKCMD paths by hand in Environement64.<br> Whatever magic setup code there is for VS10/WinSDK7 it doesn&#39;t work wit= h<br> VC11/WinSDK8.<br> </blockquote> <br></div> What environment variables did VS11 set?<br> <br> </blockquote></div><br></div> --e89a8fb1fde63f69ed04e55d8725--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde6cda5bc04e55d9056
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 03:30, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 2:46 AM, Simen Kjaeraas wrote:

 Like Dmitry said, it might work for 2010, but it certainly does not 'just
 work' for 2012 and 2013. I've probably spent twelve hours setting up DMD
 Win64 on my two confusers.

I need specifics. Again, what environment variables are setup by these other VS's? What did you put in your sc.ini? I don't have multiple VS installs.

My sc.ini looks like this, I also broke dmd2/windows/lib into lib and lib64: [Version] version=7.51 Build 020 [Environment64] LIB="c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64";"c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64";"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64";"% P%\..\lib64" DFLAGS=-m64 "-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe [Environment] LIB="% P%\..\lib";\dm\lib VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ DFLAGS=-m64 "-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A --e89a8fb1fde6cda5bc04e55d9056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 03:30, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im">On 9/1/2013 2:46 AM, Simen Kjaeraas wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Like Dmitry said, it might work for 2010, but it certainly does not &#39;ju= st<br> work&#39; for 2012 and 2013. I&#39;ve probably spent twelve hours setting u= p DMD<br> Win64 on my two confusers.<br> </blockquote> <br></div> I need specifics.<br> <br> Again, what environment variables are setup by these other VS&#39;s? What d= id you put in your sc.ini?<br> <br> I don&#39;t have multiple VS installs.<br></blockquote><div><br></div><div>= My sc.ini looks like this, I also broke dmd2/windows/lib into lib and lib64= :</div><div><br></div><div>[Version]</div><div>version=3D7.51 Build 020</di= v> <div><br></div><div>[Environment64]</div><div>LIB=3D&quot;c:\Program Files = (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64&quot;;&quot;c:\Program File= s (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64&quot;;&quot;C:\Program Files (= x86)\Microsoft DirectX SDK (June 2010)\Lib\x64&quot;;&quot;% P%\..\lib64&qu= ot;=C2=A0</div> <div>DFLAGS=3D-m64 &quot;-I% P%\..\..\src\phobos&quot; &quot;-I% P%\..\..\s= rc\druntime\import&quot;</div><div>LINKCMD64=3D%VCINSTALLDIR%bin\amd64\link= .exe</div><div><br></div><div>[Environment]</div><div>LIB=3D&quot;% P%\..\l= ib&quot;;\dm\lib</div> <div>VCINSTALLDIR=3DC:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\= </div><div>DFLAGS=3D-m64 &quot;-I% P%\..\..\src\phobos&quot; &quot;-I% P%\.= .\..\src\druntime\import&quot;</div><div>LINKCMD=3D% P%\link.exe</div><div>= LINKCMD64=3D%VCINSTALLDIR%bin\amd64\link.exe</div> <div>WindowsSdkDir=3DC:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A</d= iv><div>=C2=A0</div></div></div></div> --e89a8fb1fde6cda5bc04e55d9056--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b4724f66bf53804e55db214
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 03:38, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 6:19 AM, Manu wrote:

 Hmmm, I found details on the net that recommended adding an
 [Environment64]
 section, which we did.

 I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on my system
 :/ ..
 that said, VC obviously works on my machine.

Sorry if I am being repetitive here, but what environment variables is VS setting on your machine?

I don't have any that look meaningful, other than the TOOLS ones in my prior reply. It also seems potentially problematic that a variable would define a single
 install directory, since it's pretty common that programmers have multiple
 versions of VS on their machines.
 I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.

Yes, so what environment variables should sc.ini use to determine which one the user wants to use for dmd?

I think it should search through program files on installation. User might have non-standard installation path name. But I also think the paths should be supplied by Visual-D when running inside VisualStudio, since it's running within the version of VS that you actually want to use, so it can set the appropriate paths for that version (I've raised this with Rainer). I was also thinking it might be a mistake to keep phobos64.lib in the same
 folder as the 32bit omf libs. If paths are wrong, the link errors will
 only be
 understood by a programmer who understands compilers and lib/object
 formats in
 depth.
 Perhaps you should put them in a parallel lib64 directory, and hook that
 up in
 [Environment64] (I did that on my machine while trying to isolate
 problems and
 wort out where paths were coming from)?

Please, I need specifics.

Put phobos64.lib and friends in lib64/, beside lib/ I reckon you should look into hooking up DirectX SDK patahing by default
 too
 since it's so common for basically any multimedia app.

I have no idea what you mean by this?

DirectX, Microsoft's multimedia API? http://www.microsoft.com/en-us/download/details.aspx?id=6812 It installs bunches of libs in their own directory, I think you should include them in sc.ini by default. DirectX does appear to have an environment variable on my machine: DXSDK_DIR = C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\ So if you map: %DXSDK_DIR%Lib\x64 that will make the libs available. --047d7b4724f66bf53804e55db214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 03:38, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im">On 9/1/2013 6:19 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Hmmm, I found details on the net that recommended adding an [Environment64]= <br> section, which we did.<br> <br> I don&#39;t seem to have VCINSTALLDIR or WindowsSdkDir variables on my syst= em :/ ..<br> that said, VC obviously works on my machine.<br> </blockquote> <br></div> Sorry if I am being repetitive here, but what environment variables is VS s= etting on your machine?</blockquote><div><br></div><div>I don&#39;t have an= y that look meaningful, other than the TOOLS ones in my prior reply.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> It also seems potentially problematic that a variable would define a single= <br> install directory, since it&#39;s pretty common that programmers have multi= ple<br> versions of VS on their machines.<br> I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.<br> </blockquote> <br></div> Yes, so what environment variables should sc.ini use to determine which one= the user wants to use for dmd?</blockquote><div><br></div><div>I think it = should search through program files on installation. User might have non-st= andard installation path name.</div> <div>But I also think the paths should be supplied by Visual-D when running= inside VisualStudio, since it&#39;s running within the version of VS that = you actually want to use, so it can set the appropriate paths for that vers= ion (I&#39;ve raised this with Rainer).</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I was also thinking it might be a mistake to keep phobos64.lib in the same<= br> folder as the 32bit omf libs. If paths are wrong, the link errors will only= be<br> understood by a programmer who understands compilers and lib/object formats= in<br> depth.<br> Perhaps you should put them in a parallel lib64 directory, and hook that up= in<br> [Environment64] (I did that on my machine while trying to isolate problems = and<br> wort out where paths were coming from)?<br> </blockquote> <br></div> Please, I need specifics.</blockquote><div><br></div><div>Put phobos64.lib = and friends in lib64/, beside lib/</div><div><br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde= r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I reckon you should look into hooking up DirectX SDK patahing by default to= o<br> since it&#39;s so common for basically any multimedia app.<br> </blockquote> <br></div> I have no idea what you mean by this?<br> </blockquote></div><br></div><div class=3D"gmail_extra">DirectX, Microsoft&= #39;s multimedia API?</div><div class=3D"gmail_extra"><a href=3D"http://www= .microsoft.com/en-us/download/details.aspx?id=3D6812">http://www.microsoft.= com/en-us/download/details.aspx?id=3D6812</a></div> <div class=3D"gmail_extra">It installs bunches of libs in their own directo= ry, I think you should include them in sc.ini by default.</div><div class= =3D"gmail_extra"><br></div><div class=3D"gmail_extra">DirectX does appear t= o have an environment variable on my machine:</div> <div class=3D"gmail_extra">=C2=A0 DXSDK_DIR =3D=C2=A0C:\Program Files (x86)= \Microsoft DirectX SDK (June 2010)\</div><div class=3D"gmail_extra"><br></d= iv><div class=3D"gmail_extra">So if you map: %DXSDK_DIR%Lib\x64 that will m= ake the libs available.</div> </div> --047d7b4724f66bf53804e55db214--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde6c9e5dd04e55dbbc5
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 03:43, Walter Bright <newshound2 digitalmars.com> wrote:

 As a followup,

 When I installed VS2010, it created a shortcut on my desktop labelled
 "Visual Studio x64 Win64 ...". Clicking on that opened a command line
 window.

 In that window, I could compile and run VC programs from the command
 prompt using CL, LINK, etc.

 In that window, if I typed:

 SET

 at the prompt, it showed the environment variables set, which included:

 VCINSTALLDIR - where VC was installed
 WindowsSdkDir - where the SDK was installed

 This is all dmd needs in order to use VS2010.

 However, I didn't want to have to click on that shortcut just to use -m64,
 so I merely copied the values VCINSTALLDIR and WindowsSdkDir into my own
 personal sc.ini, and then dmd -m64 worked fine.

Ah yes, that batch file... that explains it. Maybe what you can do is scan the users Program Files for the batch file, and then pull those lines from it? (A bit hackey...) --e89a8fb1fde6c9e5dd04e55dbbc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 03:43, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">As a followup,<br> <br> When I installed VS2010, it created a shortcut on my desktop labelled &quot= ;Visual Studio x64 Win64 ...&quot;. Clicking on that opened a command line = window.<br> <br> In that window, I could compile and run VC programs from the command prompt= using CL, LINK, etc.<br> <br> In that window, if I typed:<br> <br> SET<br> <br> at the prompt, it showed the environment variables set, which included:<br> <br> VCINSTALLDIR - where VC was installed<br> WindowsSdkDir - where the SDK was installed<br> <br> This is all dmd needs in order to use VS2010.<br> <br> However, I didn&#39;t want to have to click on that shortcut just to use -m= 64, so I merely copied the values VCINSTALLDIR and WindowsSdkDir into my ow= n personal sc.ini, and then dmd -m64 worked fine.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Ah yes, that batch = file... that explains it.</div><div class=3D"gmail_extra">Maybe what you ca= n do is scan the users Program Files for the batch file, and then pull thos= e lines from it? (A bit hackey...)<br> </div></div> --e89a8fb1fde6c9e5dd04e55dbbc5--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a1133458e98b6a904e55dce13
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 03:46, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 7:02 AM, Manu wrote:

 I know Walter does care about the DMD-Win64 debuginfo quality, but I
 don't think
 the debuginfo output is capable of addressing all the problems alone.

I (and others like Rainer who help a lot with Win64 support) also cannot do a thing without targeted bugzilla reports.

How do you feel about using the DMD-Win64 + Visual-D suite as a dev environment when working on druntime+phobos for a while? Try debugging some issues using the VS debugger... I've suggested that devs need to understand the end-user experience. I think you'd reveal a lot of the really trivial issues (that are non-trivial in aggregate) very quickly. I'll continue to log bugs as I find them, I didn't this weekend because when finding a bug, I then need to spend the time to boil down a minimal repro case, and we were working against the clock >_< --001a1133458e98b6a904e55dce13 Content-Type: text/html; charset=UTF-8 <div dir="ltr">On 2 September 2013 03:46, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com" target="_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/1/2013 7:02 AM, Manu wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I know Walter does care about the DMD-Win64 debuginfo quality, but I don&#39;t think<br> the debuginfo output is capable of addressing all the problems alone.<br> </blockquote> <br></div> I (and others like Rainer who help a lot with Win64 support) also cannot do a thing without targeted bugzilla reports.<br> </blockquote></div><br></div><div class="gmail_extra">How do you feel about using the DMD-Win64 + Visual-D suite as a dev environment when working on druntime+phobos for a while? Try debugging some issues using the VS debugger...</div> <div class="gmail_extra">I&#39;ve suggested that devs need to understand the end-user experience. I think you&#39;d reveal a lot of the really trivial issues (that are non-trivial in aggregate) very quickly.</div><div class="gmail_extra"> <br></div><div class="gmail_extra">I&#39;ll continue to log bugs as I find them, I didn&#39;t this weekend because when finding a bug, I then need to spend the time to boil down a minimal repro case, and we were working against the clock &gt;_&lt;</div> </div> --001a1133458e98b6a904e55dce13--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e01538594d581af04e55de0bf
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 03:48, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 6:55 AM, Manu wrote:

 Sometimes...
 Have you worked with it on a daily basis? It just doesn't work all the
 time.
 Also, in my experience the auto-complete suggestions are often either
 incomplete, or list heaps of completely unrelated stuff.
 I'm not saying it's bad, it's better than nothing and I really appreciate
 the
 project (I've said before, if it weren't for Rainer's effort, I simply
 wouldn't
 use D), but it certainly needs more work, especially if I'm going to have
 any
 traction selling it to others with no vested interest in the language.

I really appreciate your efforts here. What Rainer needs is, I assume, the same things I need. Very specific lists of what went wrong.

Yup, but there's so many bugs in his bug tracker. It seems clear to me he needs help. I talked with him a lot at DConf. As I understand it, most of the problems are because both his and Alexander Bothe's semantic analyser's just aren't as good as the D front end. This comes back to my point about it being a separate satelite project. I wonder if it might help with visibility of these problems if it were included in the central github organisation, and bugs present in the main bug tracker that everyone can see and looks at regularly. --089e01538594d581af04e55de0bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 03:48, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 9/1/2013 6:55 AM, Manu = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sometimes...<br> Have you worked with it on a daily basis? It just doesn&#39;t work all the = time.<br> Also, in my experience the auto-complete suggestions are often either<br> incomplete, or list heaps of completely unrelated stuff.<br> I&#39;m not saying it&#39;s bad, it&#39;s better than nothing and I really = appreciate the<br> project (I&#39;ve said before, if it weren&#39;t for Rainer&#39;s effort, I= simply wouldn&#39;t<br> use D), but it certainly needs more work, especially if I&#39;m going to ha= ve any<br> traction selling it to others with no vested interest in the language.<br> </blockquote> <br></div> I really appreciate your efforts here.<br> <br> What Rainer needs is, I assume, the same things I need. Very specific lists= of what went wrong.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Yup, but there&#39;= s so many bugs in his bug tracker. It seems clear to me he needs help.</div=
<div class=3D"gmail_extra">I talked with him a lot at DConf. As I understa=

semantic analyser&#39;s just aren&#39;t as good as the D front end.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This comes = back to my point about it being a separate satelite project. I wonder if it= might help with visibility of these problems if it were included in the ce= ntral github organisation, and bugs present in the main bug tracker that ev= eryone can see and looks at regularly.</div> </div> --089e01538594d581af04e55de0bf--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fdee72482a04e55e7d37
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 05:20, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 16:32, Manu wrote:

  Well we never got OSX working (under mono-d), although this was mainly
 due to supporting apple infrastructure in the end. I think we wrangled
 the toolchain in the end, but never got everything linking; C++
 dependencies got complicated.
 We eventually gave up, just wasting too much time, and he went off and
 did the music/sounds for the game...

Gave up? Why not just use DMD directly from the zip on the command line and use TextMate or Sublime. TextMate 2 supports in app download of new languages and Sublime comes with support for D out of the box. Even though it's not perfect it has to be better than giving up.

I dunno. People just don't do that. It's perceived that typing commands in the command line is a completely unrealistic workflow for most people that doesn't love linux. He would have also had to have written himself a makefile, and none of us know how to write a makefile. I generate makefiles with other tools, but there are no good makegen tools that support D and C projects together, and even if there were, you'd just be writing a makegen script instead, which we still didn't know how to write... We also really didn't have time to stuff around with it. He just went and recorded audio instead. Side note; I'm working on support in premake for parallel C and D project generation for popular IDE's and makefiles. But it's not there yet. If you'd like to help me finish that OSX work we started together last
 year, that'd be really great for next time! :)

Well, I'm quite busy with my own projects. But I could perhaps give you a hand if you need. Although I don't want to do all the work as last time.

Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC... :/ No, actually, as much as I keep banging on the IDE thing, in this case I
 absolutely don't want help from the IDE, I just want to look at my page
 of text, and be able to read a useful summary.
 Can you give me any good reasons why fully defined functions polluting
 the readability of a class definition could possibly be a good thing?
 I just don't get it... why would you ever want to break up the nice
 summary of what a class has&does, and why would you want to indent all
 of your functions an extra few tab levels by default?

To keep everything in one place. Why would you want to duplicate the method signatures? I hate the header/source synchronization in the C family of languages. Especially in C++ where the signatures cannot even be exactly the same between the header and source file. I'm thinking of default values, for example.

I'm not suggesting it be in a separate file, Just below the class definition somewhere. The IDE actually can help here. If it detects you've modified a function signature, and it's defined lower in the file, it can fairly easily change it for you there too. As a programmer, I spend a lot more time reading code than
 documentation, and much of that time is spent reading it in foreign
 places like github commit logs (limited horizontal space), diff/merge
 windows (hard to distinguish class API changes vs function body changes
 at a glance, since they're interleaved), even chat clients and
 communication tools. The IDE can't assist in any of these contexts. If
 you have to have an IDE to read your code, then something is really wrong.

That I agree with.

So the conclusion is to put the IDE's assistance burden on the authoring side, not the reading side. Ie, when you change a function signature, IDE can update the definition's signature too. Good IDE's have awesome refactor tools, where you change a signature, and it will change it at all places that it is referenced. --e89a8fb1fdee72482a04e55e7d37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:20, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= -width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi= ng-left:1ex"> On 2013-09-01 16:32, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Well we never got OSX working (under mono-d), although this was mainly<br> due to supporting apple infrastructure in the end. I think we wrangled<br> the toolchain in the end, but never got everything linking; C++<br> dependencies got complicated.<br> We eventually gave up, just wasting too much time, and he went off and<br> did the music/sounds for the game...<br> </blockquote> <br> Gave up? Why not just use DMD directly from the zip on the command line and= use TextMate or Sublime. TextMate 2 supports in app download of new langua= ges and Sublime comes with support for D out of the box. Even though it&#39= ;s not perfect it has to be better than giving up.<br> </blockquote><div><br></div><div>I dunno. People just don&#39;t do that.</d= iv><div>It&#39;s perceived that typing commands in the command line is a co= mpletely unrealistic workflow for most people that doesn&#39;t love linux.<= /div> <div>He would have also had to have written himself a makefile, and none of= us know how to write a makefile. I generate makefiles with other tools, bu= t there are no good makegen tools that support D and C projects together, a= nd even if there were, you&#39;d just be writing a makegen script instead, = which we still didn&#39;t know how to write...</div> <div><div>We also really didn&#39;t have time to stuff around with it. He j= ust went and recorded audio instead.</div></div><div><br></div><div>Side no= te; I&#39;m working on=C2=A0support in premake for parallel C and D project= generation for popular IDE&#39;s and makefiles. But it&#39;s not there yet= .</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> If you&#39;d like to help me finish that OSX work we started together last<= br> year, that&#39;d be really great for next time! :)<br> </blockquote> <br> Well, I&#39;m quite busy with my own projects. But I could perhaps give you= a hand if you need. Although I don&#39;t want to do all the work as last t= ime.<br></blockquote><div><br></div><div>Fair enough. Well I don&#39;t have= a Mac, and I don&#39;t know Cocoa, or ObjC... :/</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> No, actually, as much as I keep banging on the IDE thing, in this case I<br=

<br> of text, and be able to read a useful summary.<br> Can you give me any good reasons why fully defined functions polluting<br> the readability of a class definition could possibly be a good thing?<br> I just don&#39;t get it... why would you ever want to break up the nice<br> summary of what a class has&amp;does, and why would you want to indent all<= br> of your functions an extra few tab levels by default?<br> </blockquote> <br> To keep everything in one place. Why would you want to duplicate the method= signatures? I hate the header/source synchronization in the C family of la= nguages. Especially in C++ where the signatures cannot even be exactly the = same between the header and source file. I&#39;m thinking of default values= , for example.<br> </blockquote><div><br></div><div>I&#39;m not suggesting it be in a separate= file, Just below the class definition somewhere.</div><div>The IDE actuall= y can help here. If it detects you&#39;ve modified a function signature, an= d it&#39;s defined lower in the file, it can fairly easily change it for yo= u there too.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> As a programmer, I spend a lot more time reading code than<br> documentation, and much of that time is spent reading it in foreign<br> places like github commit logs (limited horizontal space), diff/merge<br> windows (hard to distinguish class API changes vs function body changes<br> at a glance, since they&#39;re interleaved), even chat clients and<br> communication tools. The IDE can&#39;t assist in any of these contexts. If<= br> you have to have an IDE to read your code, then something is really wrong.<= br> </blockquote> <br> That I agree with.<br></blockquote><div><br></div><div>So the conclusion is= to put the IDE&#39;s assistance burden on the authoring side, not the read= ing side.</div><div>Ie, when you change a function signature, IDE can updat= e the definition&#39;s signature too.</div> <div><br></div><div>Good IDE&#39;s have awesome refactor tools, where you c= hange a signature, and it will change it at all places that it is reference= d.</div></div></div></div> --e89a8fb1fdee72482a04e55e7d37--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8f50378ea69da504e55e923c
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 05:21, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 16:36, Manu wrote:

  Give me one advantage to defining methods inline? I only see
 disadvantages. Lots of them.

Give me one advantage to repeat the method signature.

I've listed them, but again: * You can read the class declaration; what it has, and does, at a glance. * Function's don't have a few extra tab's of white space by default. This means you can more easily understand the flow of code within your class. * Your code uses less horizontal space. * I find it easier to review commit's in diff's, since I can clearly see separation between API changes, and function implementation changes. I find it much easier to detect the difference between 0, 1 and 2 tabs deep, than 2, 3 and 4 tab's deep. I believe there's an exponential falloff to your precision wrt estimating tab depth the deeper it gets. This makes the code less easy to follow; "Am in inside a loop, an if block, or a local function? What depth is the outer scope of the function anyway?" while skimming through code. --e89a8f50378ea69da504e55e923c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:21, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> On 2013-09-01 16:36, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Give me one advantage to defining methods inline? I only see<br> disadvantages. Lots of them.<br> </blockquote> <br> Give me one advantage to repeat the method signature.</blockquote><div><br>= </div><div>I&#39;ve listed them, but again:</div><div>=C2=A0* You can read = the class declaration; what it has, and does, at a glance.</div><div>=C2=A0= * Function&#39;s don&#39;t have a few extra tab&#39;s of white space by def= ault. This means you can more easily understand the flow of code within you= r class.</div> <div>=C2=A0* Your code uses less horizontal space.</div><div>=C2=A0* I find= it easier to review commit&#39;s in diff&#39;s, since I can clearly see se= paration between API changes, and function implementation changes.</div><di= v><br> </div><div>I find it much easier to detect the difference between 0, 1 and = 2 tabs deep, than 2, 3 and 4 tab&#39;s deep.</div><div>I believe there&#39;= s an exponential falloff to your precision wrt estimating tab depth the dee= per it gets. This makes the code less easy to follow; &quot;Am in inside a = loop, an if block, or a local function? What depth is the outer scope of th= e function anyway?&quot; while skimming through code.</div> </div></div></div> --e89a8f50378ea69da504e55e923c--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde679c24d04e55e99c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2 September 2013 05:21, Walter Bright <newshound2 digitalmars.com> wrote=
:

 On 9/1/2013 11:58 AM, Dmitry Olshansky wrote:

 01-Sep-2013 22:44, Walter Bright =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:

 The only one I see is
 VS110COMNTOOLS

Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.

Ah, that command prompt... VCINSTALLDIR=3DC:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\ WindowsSdkDir=3DC:\Program Files (x86)\Windows Kits\8.0\ However the said windows kit folder has tree like this: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,**amd64} That 'win8\um' sub-folder is what must be throwing it off. It's nothing like that in Win7 SDK. There are 2 distinct things - libraries are ound in Platform SDK (or
 rather
 WindowsSDK these days) and version 8 differs from 7. You can download
 and
 install it (any version) - it's a free download.
 Compiler/linkers are installed to VisualStudio and are dealt with
 separately.

 I still have this error when trying to comompile with debug info:

 LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
 installation
 of this product

 No idea whose fault is it (DMD vs MS linker vs something in my
 paths/env).

DMD does not load any DLLs.

Okay, then it could very well be just me messing with paths/env. OT: MS x64 compiler too could be had for free (it come with SDK I installed not VS express) + I have to redefine everything in order to compile phobos/druntime as
 these are
 hardcoded to VS10 (again !) thus I don't usually test/build x64
 Phobos. It's far
 less hassle for me to keep around x64 Linux virtual box for testing.

When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak. -------------- # Makefile to build D runtime library phobos.lib for Win32 # Designed to work with \dm\bin\make.exe

Thanks! I could borrow that. With that said I don't quite like Makefiles at all.

1. put comments in sc.ini explaining it better 2. replace the hardcoded tails that link.c appends to the sc.ini values with new settings in sc.ini 3. provide commented-out example settings for each variant of VS as we discover what they should be

And if we still rely on sc.ini to get it right: 4. As the final step of the DMD installer, open sc.ini in notepad for the user's approval. --e89a8fb1fde679c24d04e55e99c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:21, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 9= /1/2013 11:58 AM, Dmitry Olshansky wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 01-Sep-2013 22:44, Walter Bright =D0=BF=D0=B8=D1=88=D0=B5=D1=82:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The only one I see is<br> VS110COMNTOOLS<br> </blockquote> <br> Very strange. When I click on the shortcut &quot;Visual Studio x64 Win64...= &quot;<br> to open a command prompt, it sets a veritable blizzard of environment<br> variables.<br> </blockquote> <br> Ah, that command prompt...<br> VCINSTALLDIR=3DC:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\<br> WindowsSdkDir=3DC:\Program Files (x86)\Windows Kits\8.0\<br> <br> However the said windows kit folder has tree like this:<br> C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,<u></u>amd64}<= br> <br> That &#39;win8\um&#39; sub-folder is what must be throwing it off. It&#39;s= nothing like<br> that in Win7 SDK.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> There are 2 distinct things - libraries are ound in Platform SDK (or<br> rather<br> WindowsSDK these days) and version 8 differs from 7. You can download and<b= r> install it (any version) - it&#39;s a free download.<br> Compiler/linkers are installed to VisualStudio and are dealt with<br> separately.<br> <br> I still have this error when trying to comompile with debug info:<br> <br> LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck<br> installation<br> of this product<br> <br> No idea whose fault is it (DMD vs MS linker vs something in my<br> paths/env).<br> </blockquote> <br> DMD does not load any DLLs.<br> </blockquote> <br> Okay, then it could very well be just me messing with paths/env.<br> <br> OT: MS x64 compiler too could be had for free (it come with SDK I installed= not<br> VS express)<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + I have to redefine everything in order to compile phobos/druntime as<br> these are<br> hardcoded to VS10 (again !) thus I don&#39;t usually test/build x64<br> Phobos. It&#39;s far<br> less hassle for me to keep around x64 Linux virtual box for testing.<br> </blockquote> <br> When I compile phobos, for example, I use the following makefile (named<br> &quot;makefile&quot;). It is very handy for resetting the environment varia= bles<br> used by win32.mak.<br> <br> --------------<br> # Makefile to build D runtime library phobos.lib for Win32<br> # Designed to work with \dm\bin\make.exe<br> </blockquote> <br> Thanks! I could borrow that.<br> With that said I don&#39;t quite like Makefiles at all.<br> <br> </blockquote> <br></div></div> I think the most practical thing at the moment is to:<br> <br> 1. put comments in sc.ini explaining it better<br> 2. replace the hardcoded tails that link.c appends to the sc.ini values wit= h new settings in sc.ini<br> 3. provide commented-out example settings for each variant of VS as we disc= over what they should be<br></blockquote><div><br></div><div>And if we stil= l rely on sc.ini to get it right:</div><div>4. As the final step of the DMD= installer, open sc.ini in notepad for the user&#39;s approval.</div> </div></div></div> --e89a8fb1fde679c24d04e55e99c8--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2e73e32113b04e55eac86
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 05:28, Brad Anderson <eco gnuk.net> wrote:

 On Sunday, 1 September 2013 at 07:42:47 UTC, Walter Bright wrote:

 On 8/31/2013 7:05 PM, Manu wrote:

 The only compiler you can realistically use productively in windows is
 DMD-Win64, and that doesn't work out of the box.
 We needed to mess with sc.ini for quite some time to get the stars
 aligned such
 that it would actually compile and find the linker+libs.

 Walter: DMD needs to internally detect installations of various versions
 of
 VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
 installer needs to amend sc.ini. Either way, leaving it to a user to
 fiddle with
 an ini file just isn't acceptable. We had to google solutions to this
 problem,
 and even then, we had trouble with the paths we added to sc.ini; are
 spaces
 acceptable? Do they have quites around them?...
 I might also suggest that Microsoft supplied (ie, 'standard'), libraries
 should
 be automatically detected and path entries added in there too:
   C:\Program Files (x86)\Microsoft SDKs\...
   C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
 These are on basically every windows developers machine, and each of us
 had to
 configure them ourselves.

The default sc.ini contains: ----------------------------- [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib";\dm\lib DFLAGS="-I% P%\..\..\src\**phobos" "-I% P%\..\..\src\druntime\**import" LINKCMD=% P%\link.exe LINKCMD64=%VCINSTALLDIR%bin\**amd64\link.exe VCINSTALLDIR=%VCINSTALLDIR% WindowsSdkDir=%WindowsSdkDir% ------------------------------**---- When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work". What went wrong, specifically?

I can make the installer detect which versions of Visual Studio are installed and the path they are installed. Would I rather I have the installer modify the installed sc.ini or set an environment variable?

Avoid environment variables in windows, if you ask me. They are a mess, and they are hard to manage through the stupid UI hidden in system settings->advanced->advanced->environment variables. I think most windows users would consider sc.ini much simpler, but the most important thing is that they need to know it's there, and that it's critical that it's correct. Another idea is to enhance DMD's error messages to warns about correct paths in sc.ini when it either fails to find link.exe, or encounters an OMF library (the two tell-tale errors that sc.ini is wrong). --001a11c2e73e32113b04e55eac86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:28, Brad Anderson <span dir=3D"ltr"=
&lt;<a href=3D"mailto:eco gnuk.net" target=3D"_blank">eco gnuk.net</a>&gt;=

ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> On Sunday, 1 September 2013 at 07:42:47 UTC, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 8/31/2013 7:05 PM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The only compiler you can realistically use productively in windows is<br> DMD-Win64, and that doesn&#39;t work out of the box.<br> We needed to mess with sc.ini for quite some time to get the stars aligned = such<br> that it would actually compile and find the linker+libs.<br> <br> Walter: DMD needs to internally detect installations of various versions of= <br> VisualStudio, and either &#39;just work&#39;, or amend sc.ini on its own. O= r the<br> installer needs to amend sc.ini. Either way, leaving it to a user to fiddle= with<br> an ini file just isn&#39;t acceptable. We had to google solutions to this p= roblem,<br> and even then, we had trouble with the paths we added to sc.ini; are spaces= <br> acceptable? Do they have quites around them?...<br> I might also suggest that Microsoft supplied (ie, &#39;standard&#39;), libr= aries should<br> be automatically detected and path entries added in there too:<br> =C2=A0 C:\Program Files (x86)\Microsoft SDKs\...<br> =C2=A0 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...<br> These are on basically every windows developers machine, and each of us had= to<br> configure them ourselves.<br> </blockquote> <br> The default sc.ini contains:<br> -----------------------------<br> [Version]<br> version=3D7.51 Build 020<br> <br> [Environment]<br> LIB=3D&quot;% P%\..\lib&quot;;\dm\lib<br> DFLAGS=3D&quot;-I% P%\..\..\src\<u></u>phobos&quot; &quot;-I% P%\..\..\src\= druntime\<u></u>import&quot;<br> LINKCMD=3D% P%\link.exe<br> LINKCMD64=3D%VCINSTALLDIR%bin\<u></u>amd64\link.exe<br> VCINSTALLDIR=3D%VCINSTALLDIR%<br> WindowsSdkDir=3D%WindowsSdkDir%<br> ------------------------------<u></u>----<br> <br> When I installed VC 2010, it set the environment variables VCINSTALLDIR and= WindowsSdkDir. Then, the default sc.ini should &quot;just work&quot;.<br> <br> What went wrong, specifically?<br> </blockquote> <br> I can make the installer detect which versions of Visual Studio are install= ed and the path they are installed. =C2=A0Would I rather I have the install= er modify the installed sc.ini or set an environment variable?<br> </blockquote></div><br></div><div class=3D"gmail_extra">Avoid environment v= ariables in windows, if you ask me. They are a mess, and they are hard to m= anage through the stupid UI hidden in system settings-&gt;advanced-&gt;adva= nced-&gt;environment variables.</div> <div class=3D"gmail_extra">I think most windows users would consider sc.ini= much simpler, but the most important thing is that they need to know it&#3= 9;s there, and that it&#39;s critical that it&#39;s correct.</div><div clas= s=3D"gmail_extra"> <br></div><div class=3D"gmail_extra">Another idea is to enhance DMD&#39;s e= rror messages to warns about correct paths in sc.ini when it either fails t= o find link.exe, or encounters an OMF library (the two tell-tale errors tha= t sc.ini is wrong).</div> </div> --001a11c2e73e32113b04e55eac86--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c33676ee248f04e55ec4dd
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 05:35, Vladimir Panteleev
<vladimir thecybershadow.net>wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:

 Documentation:

 Okay for the most part, but some windows dev's want a CHM that looks like
 the typical Microsoft doc's people are used to. Those that aren't familiar
 with the CHM viewer; it's just HTML but with a nice index + layout tree.

What can be improved in the CHM that's currently bundled with DMD?

It can have a link inserted in the start menu. I don't usually go looking for doc's in bin/... If I were gonna be picky, the index seems incomplete. Open it up, click the 'index' tab, and type tostringz... it's not there. I think it's also very unnatural for a chm to have the module's functions all on the one page. Can they be broken up into separate articles? But it's fine. The the main problem I had with it, is that I had no idea it existed. I didn't look in bin/. --001a11c33676ee248f04e55ec4dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:35, Vladimir Panteleev <span dir=3D= "ltr">&lt;<a href=3D"mailto:vladimir thecybershadow.net" target=3D"_blank">= vladimir thecybershadow.net</a>&gt;</span> wrote:<br><div class=3D"gmail_ex= tra"><div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Sunday, 1 September 2013 at 02:05:51 UTC,= Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Documentation:<br> <br> Okay for the most part, but some windows dev&#39;s want a CHM that looks li= ke<br> the typical Microsoft doc&#39;s people are used to. Those that aren&#39;t f= amiliar<br> with the CHM viewer; it&#39;s just HTML but with a nice index + layout tree= .<br> </blockquote> <br> What can be improved in the CHM that&#39;s currently bundled with DMD?<br> </blockquote></div><br></div><div class=3D"gmail_extra">It can have a link = inserted in the start menu. I don&#39;t usually go looking for doc&#39;s in= bin/...</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr= a"> If I were gonna be picky, the index seems incomplete. Open it up, click the= &#39;index&#39; tab, and type tostringz... it&#39;s not there.</div><div c= lass=3D"gmail_extra">I think it&#39;s also very unnatural for a chm to have= the module&#39;s functions all on the one page. Can they be broken up into= separate articles?</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But it&#39;= s fine. The the main problem I had with it, is that I had no idea it existe= d. I didn&#39;t look in bin/.</div></div> --001a11c33676ee248f04e55ec4dd--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fde662e66604e55ed2e2
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 05:44, Brian Schott <briancschott gmail.com> wrote:

 On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote:

 I think at this point, what D needs is a bit of commercial support from a
 company like JetBrains or some equivalent. Maybe there is now an
 opportunity for founding such a company, one that would specialize in
 building professional tools around the D language. I believe the language
 and the compilers are stable enough to grow a serious business around them.
 If we compare to what the state of C++ compilers was before 2000, I believe
 we are much better off. And that was just over a decade ago. Who knows what
 the state of D will be in 5 years ? So yes, there is a case to be made for
 growing a company around pro D tools, and the first company that does it
 will grab the whole market.

It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist.

Well you can look at Remedy's experience. I've also sparked interest in staff from a few other companies when talking to developers. It'll never fly though if when they go to try it out, they're met with the kind of experience I had on the weekend. Don't underestimate how much people hate C++ these days. --e89a8fb1fde662e66604e55ed2e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 05:44, Brian Schott <span dir=3D"ltr">= &lt;<a href=3D"mailto:briancschott gmail.com" target=3D"_blank">briancschot= t gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class= =3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Sunday, 1 September 2013 at 18:36:39 UTC,= SomeDude wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I think at this point, what D needs is a bit of commercial support from a c= ompany like JetBrains or some equivalent. Maybe there is now an opportunity= for founding such a company, one that would specialize in building profess= ional tools around the D language. I believe the language and the compilers= are stable enough to grow a serious business around them. If we compare to= what the state of C++ compilers was before 2000, I believe we are much bet= ter off. And that was just over a decade ago. Who knows what the state of D= will be in 5 years ? So yes, there is a case to be made for growing a comp= any around pro D tools, and the first company that does it will grab the wh= ole market.<br> </blockquote> <br> It&#39;s a bit of a chicken-and-egg problem. I&#39;d like to do this, but t= here would have to be several companies already using D professionally for = it to be a viable business model. And for a company to invest in D, they&#3= 9;d probably want the tooling to already exist.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Well you can look a= t Remedy&#39;s experience. I&#39;ve also sparked interest in staff from a f= ew other companies when talking to developers.</div><div class=3D"gmail_ext= ra"> It&#39;ll never fly though if when they go to try it out, they&#39;re met w= ith the kind of experience I had on the weekend.<br></div><div class=3D"gma= il_extra">Don&#39;t underestimate how much people hate C++ these days.</div=

--e89a8fb1fde662e66604e55ed2e2--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c1d6f6b3b3dd04e55ee030
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 06:00, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:

 I know you seem to hate automation (because it sometimes fails), but
 having each individual person waste hours on initial setup is much
 worse than having a script which can potentially fail. At least the
 script can be fixed once the bug is reported, and it can be tested.

Back in the bad old Datalight C days, I relied on the Microsoft linker which came on the DOS system disks. Unfortunately, Microsoft constantly changed it, even with the same version of DOS. Worse, numerous other Microsoft products came with yet other versions of LINK.EXE. All those linkers behaved differently. It was a frackin' nightmare to support customers with them. I used to have floppy disks packed full of just different versions of LINK.EXE. This drove me to get our own linker (BLINK.EXE). While it wasn't perfect, either, at least I could actually fix problems with it rather than throwing up my hands in rage being unable to control the situation. There's no way we can automate VC 2014 so its unpredictable configuration will work. All we can do is react after the fact.

MS always release preview versions to toolchain/workflow vendors though. You just need to register interest to get access afaik. I don't hate automation. sc.ini works out of the box with the default
 install of VS 2010.

I don't think my 2010 install is non-standard in any way... What I need from you guys and your different VS installs is, for each one,
 a bug report with what is necessary to get it installed. Then we can add it
 to the modern version of my floppy disk "linker collection".

I posted my sc.ini in a prior post. I'll try and get Simon's from him, since he was on 2012. --001a11c1d6f6b3b3dd04e55ee030 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 06:00, Walter Bright <span dir=3D"ltr"=
&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newsho=

iv class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 9/1/2013 12:38 PM, Andr= ej Mitrovic wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I know you seem to hate automation (because it sometimes fails), but<br> having each individual person waste hours on initial setup is much<br> worse than having a script which can potentially fail. At least the<br> script can be fixed once the bug is reported, and it can be tested.<br> </blockquote> <br></div> Back in the bad old Datalight C days, I relied on the Microsoft linker whic= h came on the DOS system disks. Unfortunately, Microsoft constantly changed= it, even with the same version of DOS. Worse, numerous other Microsoft pro= ducts came with yet other versions of LINK.EXE.<br> <br> All those linkers behaved differently.<br> <br> It was a frackin&#39; nightmare to support customers with them. I used to h= ave floppy disks packed full of just different versions of LINK.EXE.<br> <br> This drove me to get our own linker (BLINK.EXE). While it wasn&#39;t perfec= t, either, at least I could actually fix problems with it rather than throw= ing up my hands in rage being unable to control the situation.<br> <br> There&#39;s no way we can automate VC 2014 so its unpredictable configurati= on will work. All we can do is react after the fact.<br></blockquote><div><= br></div><div>MS always release preview versions to toolchain/workflow vend= ors though. You just need to register interest to get access afaik.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> I don&#39;t hate automation. sc.ini works out of the box with the default i= nstall of VS 2010.<br></blockquote><div><br></div><div>I don&#39;t think my= 2010 install is non-standard in any way...</div><div><br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> What I need from you guys and your different VS installs is, for each one, = a bug report with what is necessary to get it installed. Then we can add it= to the modern version of my floppy disk &quot;linker collection&quot;.<br> </blockquote></div><br></div><div class=3D"gmail_extra">I posted my sc.ini = in a prior post. I&#39;ll try and get Simon&#39;s from him, since he was on= 2012.</div></div> --001a11c1d6f6b3b3dd04e55ee030--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2e81cfaed6404e55f76c6
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 11:41, Brad Anderson <eco gnuk.net> wrote:

 On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright wrote:

 On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:

 On 9/1/13, Brad Anderson <eco gnuk.net> wrote:

 What I need from you guys and your different VS installs is,
 for each one, a bug report with what is necessary to get it
 installed. Then we can add it to the modern version of my
 floppy disk "linker collection".

This can be automated easily enough. The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice). It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)


https://github.com/D-**Programming-Language/**installer/pull/22<https://github.com/D-Programming-Language/installer/pull/22> It can detect (through registry keys) the paths of Visual C++ 10, 11, and 12 (2010, 2012, and 2013) and Windows SDK 7.0A, 7.1A, 8.0, and 8.1. It modifies the sc.ini installed from the zip file by substituting the defaults with the detected paths (which makes it important I have accurately reflected what the sc.ini defaults will be). I only have VC 10 to test with myself (and lack the disk space to have concurrent installations of all 3). I installed the Windows SDK 7.0A (comes with VC 10), 8.0, and 8.1 though I couldn't actually use 8.0 and 8.1 successfully because of the path tail issue Dmitry pointed out (and you opened a pull request to fix). The combination of VC 10 and SDK 8.1 did not work (link errors) but VC 10 with 7.0A worked perfectly. I imagine you need to pair the SDK with the version of VC that was released around the same time.

Huzzah! Give the man a beer! :) How about the DirectX SDK? http://www.microsoft.com/en-us/download/details.aspx?id=6812 It's super standard aswell for anyone working on multimedia software. It has an environment variable on my machine: DXSDK_DIR = C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\ --001a11c2e81cfaed6404e55f76c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 11:41, Brad Anderson <span dir=3D"ltr"=
&lt;<a href=3D"mailto:eco gnuk.net" target=3D"_blank">eco gnuk.net</a>&gt;=

ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex"> <div class=3D""><div class=3D"h5">On Sunday, 1 September 2013 at 21:08:24 U= TC, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On 9/1/13, Brad Anderson &lt;<a href=3D"mailto:eco gnuk.net" target=3D"_bla= nk">eco gnuk.net</a>&gt; wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex"> What I need from you guys and your different VS installs is,<br> for each one, a bug report with what is necessary to get it<br> installed. Then we can add it to the modern version of my<br> floppy disk &quot;linker collection&quot;.<br> </blockquote> <br> This can be automated easily enough. =C2=A0The installer can detect<br> what versions of VS are installed and either set an environment<br> variable or modify sc.ini (your choice). =C2=A0It could probably be<br> made forward compatible since Microsoft has been using basically<br> the same paths and registry keys for every new release since at<br> least VS 2005.<br> </blockquote> <br> Yes, and VS comes out what, maybe once a year? This is possible to<br> implement and maintain. If it weren&#39;t, then installing VS plugins<br> would be impossible, but as far as I know it mostly works out of the<br> box (hell, VisualD does it, so why can&#39;t we do something as simple as<b= r> detect VS paths?)<br> <br> </blockquote> <br> Pull requests are, of course, welcome.<br> </blockquote> <br> </div></div><a href=3D"https://github.com/D-Programming-Language/installer/= pull/22" target=3D"_blank">https://github.com/D-<u></u>Programming-Language= /<u></u>installer/pull/22</a><br> <br> It can detect (through registry keys) the paths of Visual C++ 10, 11, and 1= 2 (2010, 2012, and 2013) and Windows SDK 7.0A, 7.1A, 8.0, and 8.1. =C2=A0It= modifies the sc.ini installed from the zip file by substituting the defaul= ts with the detected paths (which makes it important I have accurately refl= ected what the sc.ini defaults will be).<br> <br> I only have VC 10 to test with myself (and lack the disk space to have conc= urrent installations of all 3). =C2=A0I installed the Windows SDK 7.0A (com= es with VC 10), 8.0, and 8.1 though I couldn&#39;t actually use 8.0 and 8.1= successfully because of the path tail issue Dmitry pointed out (and you op= ened a pull request to fix).<br> <br> The combination of VC 10 and SDK 8.1 did not work (link errors) but VC 10 w= ith 7.0A worked perfectly. =C2=A0I imagine you need to pair the SDK with th= e version of VC that was released around the same time.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Huzzah! Give the ma= n a beer! :)</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= extra">How about the DirectX SDK?=C2=A0<a href=3D"http://www.microsoft.com/= en-us/download/details.aspx?id=3D6812">http://www.microsoft.com/en-us/downl= oad/details.aspx?id=3D6812</a></div> <div class=3D"gmail_extra">It&#39;s super standard aswell for anyone workin= g on multimedia software.</div><div class=3D"gmail_extra">It has an environ= ment variable on my machine: DXSDK_DIR =3D=C2=A0C:\Program Files (x86)\Micr= osoft DirectX SDK (June 2010)\</div> </div> --001a11c2e81cfaed6404e55f76c6--
Sep 01 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8fb1fdeed1caa804e565b291
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 16:05, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/1/2013 10:01 PM, Manu wrote:

 How about the DirectX SDK?
 http://www.microsoft.com/en-**us/download/details.aspx?id=**6812<http://www.microsoft.com/en-us/download/details.aspx?id=6812>
 It's super standard aswell for anyone working on multimedia software.
 It has an environment variable on my machine: DXSDK_DIR = C:\Program Files
 (x86)\Microsoft DirectX SDK (June 2010)\

How about: LIBPATH64=%VCINSTALLDIR%lib\**amd64;%WindowsSdkDir%lib\x64;%**DXSDK_DIR% in your sc.ini?

Yeah, that's what I did. I'm just suggesting it should be detected and added by the installer. --e89a8fb1fdeed1caa804e565b291 Content-Type: text/html; charset=UTF-8 <div dir="ltr">On 2 September 2013 16:05, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com" target="_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/1/2013 10:01 PM, Manu wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> How about the DirectX SDK?<br> <a href="http://www.microsoft.com/en-us/download/details.aspx?id=6812" target="_blank">http://www.microsoft.com/en-<u></u>us/download/details.aspx?id=<u></u>6812</a><br> It&#39;s super standard aswell for anyone working on multimedia software.<br> It has an environment variable on my machine: DXSDK_DIR = C:\Program Files<br> (x86)\Microsoft DirectX SDK (June 2010)\<br> </blockquote> <br></div> How about:<br> <br> LIBPATH64=%VCINSTALLDIR%lib\<u></u>amd64;%WindowsSdkDir%lib\x64;%<u></u>DXSDK_DIR%<br> <br> in your sc.ini?<br> </blockquote></div><br></div><div class="gmail_extra">Yeah, that&#39;s what I did. I&#39;m just suggesting it should be detected and added by the installer.</div></div> --e89a8fb1fdeed1caa804e565b291--
Sep 02 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 September 2013 at 03:51:54 UTC, Manu wrote:
 On 2 September 2013 05:20, Jacob Carlborg <doob me.com> wrote:
 Gave up? Why not just use DMD directly from the zip on the 
 command line
 and use TextMate or Sublime. TextMate 2 supports in app 
 download of new
 languages and Sublime comes with support for D out of the box. 
 Even though
 it's not perfect it has to be better than giving up.

I dunno. People just don't do that. It's perceived that typing commands in the command line is a completely unrealistic workflow for most people that doesn't love linux.

It is more of a cultural issue than real tool stack issue. Yes, I am perfectly aware that Microsoft has succeeded in creating incredibly closed and tool-oriented programming environment and also succeeded to create lot of programmers that accept it as the only possible way to do things. I am perfectly aware that game dev industry is completely Microsoft-centric and is forced to accept such rules of the game. But do you seriously expect anyone with no personal business interest to work on brining more of such crap into something that is not broken? You would have had my sympathy but demand "Let's force everyone to use IDE" is just insane. All this thread would have made some sense if some enterprise D entity has existed but it simply does not work that way right now. And, to be honest, I am glad about it.
Sep 02 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 01 Sep 2013 16:32:06 +0200, Manu <turkeyman gmail.com> wrote:

 No, actually, as much as I keep banging on the IDE thing, in this case I
 absolutely don't want help from the IDE, I just want to look at my page  
 of
 text, and be able to read a useful summary.
 Can you give me any good reasons why fully defined functions polluting  
 the
 readability of a class definition could possibly be a good thing?
 I just don't get it... why would you ever want to break up the nice  
 summary
 of what a class has&does, and why would you want to indent all of your
 functions an extra few tab levels by default?

Here's something D lets you do today: class Foo { // Definition: // Forbles the grabblies. void bar(); // Implementation: void bar() { myGrabblies.forble(); } } It does not get rid of the tabs, and has no checking that all functions are present in the definition (the compiler gets confused if only the definition is there), but it does give a nice list at the top. If you want the definition in a different file, and no class Foo { in the implementation file, you can do this: // foo.d class Foo { // Forbles the grabblies. void bar(); import("foo_imp.d"); } ---------------------------- //foo_imp.d: bar() { myGrabblies.forble(); } That gives no inline indication of which class the functions belong to, though. Also, no global functions in foo_imp.d. Now, neither of these solutions are perfect, but they might be good enough. I'd also like to see implementation separate from definition, but I feel dmd -H could do that job nicely by including comments, or possibly by dmd -D with the correct ddoc template. -- Simen
Sep 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b47249c80a62304e5667702
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 18:14, Mike Parker <aldacron gmail.com> wrote:

 On 9/2/2013 11:54 AM, Manu wrote:

 DirectX, Microsoft's multimedia API?
 http://www.microsoft.com/en-**us/download/details.aspx?id=**6812<http://www.microsoft.com/en-us/download/details.aspx?id=6812>
 It installs bunches of libs in their own directory, I think you should
 include them in sc.ini by default.

 DirectX does appear to have an environment variable on my machine:

    DXSDK_DIR = C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\

 So if you map: %DXSDK_DIR%Lib\x64 that will make the libs available.

MS has stopped making new versions of the DirectX SDK. Everything now ships as part of the Windows SDK. See http://msdn.microsoft.com/en-**us/library/windows/desktop/** ee663275(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx>

Yeah, but DMD is tested against VS2010, and many users of VS2010 still exist (like me, and all but one of my friends on the weekend). Which means the DXSDK package is still totally relevant. --047d7b47249c80a62304e5667702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 18:14, Mike Parker <span dir=3D"ltr">&= lt;<a href=3D"mailto:aldacron gmail.com" target=3D"_blank">aldacron gmail.c= om</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_= quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 9/2/2013 11:54 AM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <br> DirectX, Microsoft&#39;s multimedia API?<br> <a href=3D"http://www.microsoft.com/en-us/download/details.aspx?id=3D6812" = target=3D"_blank">http://www.microsoft.com/en-<u></u>us/download/details.as= px?id=3D<u></u>6812</a><br> It installs bunches of libs in their own directory, I think you should<br> include them in sc.ini by default.<br> <br></div> DirectX does appear to have an environment variable on my machine:<div clas= s=3D"im"><br> =C2=A0 =C2=A0DXSDK_DIR =3D C:\Program Files (x86)\Microsoft DirectX SDK (Ju= ne 2010)\<br> <br></div><div class=3D"im"> So if you map: %DXSDK_DIR%Lib\x64 that will make the libs available.<br> </div></blockquote> <br> MS has stopped making new versions of the DirectX SDK. Everything now ships= as part of the Windows SDK.<br> <br> See <a href=3D"http://msdn.microsoft.com/en-us/library/windows/desktop/ee66= 3275(v=3Dvs.85).aspx" target=3D"_blank">http://msdn.microsoft.com/en-<u></u=
us/library/windows/desktop/<u></u>ee663275(v=3Dvs.85).aspx</a><br>

sted against VS2010, and many users of VS2010 still exist (like me, and all= but one of my friends on the weekend). Which means the DXSDK package is st= ill totally relevant.</div> </div> --047d7b47249c80a62304e5667702--
Sep 02 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 September 2013 at 12:54:41 UTC, Simen Kjaeraas wrote:
 If you want the definition in a different file, and no class 
 Foo { in the
 implementation file, you can do this:

 // foo.d
 class Foo {
     // Forbles the grabblies.
     void bar();

     import("foo_imp.d");
 }
 ----------------------------
 //foo_imp.d:

 bar() {
     myGrabblies.forble();
 }

 That gives no inline indication of which class the functions 
 belong to,
 though. Also, no global functions in foo_imp.d.

That is pretty fun trick but it is so preprocessor-flavored! :( Also it is likely to confuse lot of semantic analysis tool. Still may be a viable hack.
Sep 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c33676f954f704e56682e3
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 18:25, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-02 05:51, Manu wrote:

  I dunno. People just don't do that.
 It's perceived that typing commands in the command line is a completely
 unrealistic workflow for most people that doesn't love linux.
 He would have also had to have written himself a makefile, and none of
 us know how to write a makefile. I generate makefiles with other tools,
 but there are no good makegen tools that support D and C projects
 together, and even if there were, you'd just be writing a makegen script
 instead, which we still didn't know how to write...
 We also really didn't have time to stuff around with it. He just went
 and recorded audio instead.

I would have used a shell script but I get your point. Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC...
 :/

Hehe. You do already support iOS, how was that added?

Some time back when I did have a Mac, and I lifted the boot code from a sample app, and then the rest of the code just fell into place because it's super system-agnostic. Good IDE's have awesome refactor tools, where you change a signature,
 and it will change it at all places that it is referenced.

Then your back to need of an IDE to use the language.

Yeah, except this seems like a more sensible application of an IDE helper to me, and it's not required by any means for the language to be useful. Since the code can be read in any number of locations, and expecting the IDE to assist you with making the code readable makes no sense. Rather, move the 'burden' to the authoring stage, and the IDE can equally help there, but the advantage is readability anywhere without IDE support. --001a11c33676f954f704e56682e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 18:25, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On 2013-09-02 05:51, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I dunno. People just don&#39;t do that.<br> It&#39;s perceived that typing commands in the command line is a completely= <br> unrealistic workflow for most people that doesn&#39;t love linux.<br> He would have also had to have written himself a makefile, and none of<br> us know how to write a makefile. I generate makefiles with other tools,<br> but there are no good makegen tools that support D and C projects<br> together, and even if there were, you&#39;d just be writing a makegen scrip= t<br> instead, which we still didn&#39;t know how to write...<br> We also really didn&#39;t have time to stuff around with it. He just went<b= r> and recorded audio instead.<br> </blockquote> <br></div> I would have used a shell script but I get your point.<div class=3D"im"><br=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Fair enough. Well I don&#39;t have a Mac, and I don&#39;t know Cocoa, or Ob= jC... :/<br> </blockquote> <br></div> Hehe. You do already support iOS, how was that added?</blockquote><div><br>= </div><div>Some time back when I did have a Mac, and I lifted the boot code= from a sample app, and then the rest of the code just fell into place beca= use it&#39;s super system-agnostic.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Good IDE&#39;s have awesome refactor tools, where you change a signature,<b= r> and it will change it at all places that it is referenced.<br> </blockquote> <br></div> Then your back to need of an IDE to use the language.</blockquote><div><br>= </div><div>Yeah, except this seems like a more sensible application of an I= DE helper to me, and it&#39;s not required by any means for the language to= be useful.</div> <div>Since the code can be read in any number of locations, and expecting t= he IDE to assist you with making the code readable makes no sense.</div><di= v>Rather, move the &#39;burden&#39; to the authoring stage, and the IDE can= equally help there, but the advantage is readability anywhere without IDE = support.</div> </div></div></div> --001a11c33676f954f704e56682e3--
Sep 02 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/09/13 14:51, Dicebot wrote:
 But do you seriously expect anyone with no personal business interest to work
on
 brining more of such crap into something that is not broken? You would have had
 my sympathy but demand "Let's force everyone to use IDE" is just insane. All
 this thread would have made some sense if some enterprise D entity has existed
 but it simply does not work that way right now. And, to be honest, I am glad
 about it.

Personally I find, observing a number of different open source projects, that a very typical problem is a kind of "selection bias" among contributors that leads them to significantly under-appreciate the usability problems of their software. It goes something like this: anyone who has spent any length of time using that software (which of course includes most contributors) either had a workflow and toolchain that the software matched with, or they have been able to adapt their workflow and toolchain to enable them to use the software. Usually they have managed to find ways of coping and working around any other usability issues that arise. And that situation then compounds itself over time because new users come and either adapt in the same way that existing contributors have, or they leave. So, you wind up with a body of contributors who often have much in common in terms of their setup, their perception of the priorities, and in their ability to handle the software. And that in turn can be very dangerous, because you get people who simply don't understand (or have any way to experience) problems that are brought to them by new users or by others. And of course there are always greater problems than usability, so those problems are the ones that get focused on, with the developers all the while bemoaning the lack of manpower and wondering why it is so difficult to attract and hold on to contributors. The only way that I can see to avoid that trap is to have a strong focus on usability as part of your development process, to make sure that developers have good connections with a diverse range of potential users and their experiences, and (where possible) for developers to dedicate part of their time to actually trying to undergo that experience themselves. The TL;DR of what I'm saying here is: while it's certainly crazy to force D contributors to use IDEs, there's a great deal of value in making sure that a good number of contributors regularly get IDE experience, and regularly try out "fresh start" installs of D in IDE and non-IDE environments, because that way you have a sense of how easy or painful it is for new users to get things installed and just get hacking.
Sep 02 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 September 2013 at 13:36:12 UTC, Joseph Rushton 
Wakeling wrote:
 Personally I find, observing a number of different open source 
 projects, that a very typical problem is a kind of "selection 
 bias" among contributors that leads them to significantly 
 under-appreciate the usability problems of their software.

 <snip>

There is a notable difference between making contribution easier and improving user experience. One thing that is often misunderstood about open-source driving power is that it is in fact very egoistic. You do stuff that is useful to you and share it with others because it costs you nothing and benefits in the long run. But key target user tends to be developer itself, not some kind of "end" user. Of course there is some place for idealistic motivation but in my opinion this is most important part in open-source success.
Sep 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8f50378e5bf6b804e566fb87
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 22:51, Dicebot <public dicebot.lv> wrote:

 On Monday, 2 September 2013 at 03:51:54 UTC, Manu wrote:

 On 2 September 2013 05:20, Jacob Carlborg <doob me.com> wrote:

 Gave up? Why not just use DMD directly from the zip on the command line
 and use TextMate or Sublime. TextMate 2 supports in app download of new
 languages and Sublime comes with support for D out of the box. Even
 though
 it's not perfect it has to be better than giving up.

It's perceived that typing commands in the command line is a completely unrealistic workflow for most people that doesn't love linux.

It is more of a cultural issue than real tool stack issue. Yes, I am perfectly aware that Microsoft has succeeded in creating incredibly closed and tool-oriented programming environment and also succeeded to create lot of programmers that accept it as the only possible way to do things. I am perfectly aware that game dev industry is completely Microsoft-centric and is forced to accept such rules of the game. But do you seriously expect anyone with no personal business interest to work on brining more of such crap into something that is not broken? You would have had my sympathy but demand "Let's force everyone to use IDE" is just insane. All this thread would have made some sense if some enterprise D entity has existed but it simply does not work that way right now. And, to be honest, I am glad about it.

Okay, I clearly made my claim too strongly, but I still think it would be valuable for basically everyone to try it out every now and then, and understand the experience on offer. Sure, each to their own thing... I just wanted to stress that a higher consideration to the end-user experience wouldn't go astray. --e89a8f50378e5bf6b804e566fb87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 22:51, Dicebot <span dir=3D"ltr">&lt;<= a href=3D"mailto:public dicebot.lv" target=3D"_blank">public dicebot.lv</a>= &gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

On Monday, 2 September 2013 at 03:51:54 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 2 September 2013 05:20, Jacob Carlborg &lt;<a href=3D"mailto:doob me.com= " target=3D"_blank">doob me.com</a>&gt; wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Gave up? Why not just use DMD directly from the zip on the command line<br> and use TextMate or Sublime. TextMate 2 supports in app download of new<br> languages and Sublime comes with support for D out of the box. Even though<= br> it&#39;s not perfect it has to be better than giving up.<br> <br> </blockquote> <br> I dunno. People just don&#39;t do that.<br> It&#39;s perceived that typing commands in the command line is a completely= <br> unrealistic workflow for most people that doesn&#39;t love linux.<br> </blockquote> <br> It is more of a cultural issue than real tool stack issue. Yes, I am perfec= tly aware that Microsoft has succeeded in creating incredibly closed and to= ol-oriented programming environment and also succeeded to create lot of pro= grammers that accept it as the only possible way to do things. I am perfect= ly aware that game dev industry is completely Microsoft-centric and is forc= ed to accept such rules of the game.<br> <br> But do you seriously expect anyone with no personal business interest to wo= rk on brining more of such crap into something that is not broken? You woul= d have had my sympathy but demand &quot;Let&#39;s force everyone to use IDE= &quot; is just insane. All this thread would have made some sense if some e= nterprise D entity has existed but it simply does not work that way right n= ow. And, to be honest, I am glad about it.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Okay, I clearly mad= e my claim too strongly, but I still think it would be valuable for basical= ly everyone to try it out every now and then, and understand the experience= on offer.</div> <div class=3D"gmail_extra">Sure, each to their own thing... I just wanted t= o stress that a higher consideration to the end-user experience wouldn&#39;= t go astray.<br></div></div> --e89a8f50378e5bf6b804e566fb87--
Sep 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b41ccf8a94ea004e5671f70
Content-Type: text/plain; charset=UTF-8

On 2 September 2013 23:36, Joseph Rushton Wakeling <
joseph.wakeling webdrake.net> wrote:

 On 02/09/13 14:51, Dicebot wrote:

 But do you seriously expect anyone with no personal business interest to
 work on
 brining more of such crap into something that is not broken? You would
 have had
 my sympathy but demand "Let's force everyone to use IDE" is just insane.
 All
 this thread would have made some sense if some enterprise D entity has
 existed
 but it simply does not work that way right now. And, to be honest, I am
 glad
 about it.

Personally I find, observing a number of different open source projects, that a very typical problem is a kind of "selection bias" among contributors that leads them to significantly under-appreciate the usability problems of their software. It goes something like this: anyone who has spent any length of time using that software (which of course includes most contributors) either had a workflow and toolchain that the software matched with, or they have been able to adapt their workflow and toolchain to enable them to use the software. Usually they have managed to find ways of coping and working around any other usability issues that arise. And that situation then compounds itself over time because new users come and either adapt in the same way that existing contributors have, or they leave. So, you wind up with a body of contributors who often have much in common in terms of their setup, their perception of the priorities, and in their ability to handle the software. And that in turn can be very dangerous, because you get people who simply don't understand (or have any way to experience) problems that are brought to them by new users or by others. And of course there are always greater problems than usability, so those problems are the ones that get focused on, with the developers all the while bemoaning the lack of manpower and wondering why it is so difficult to attract and hold on to contributors.

I think this is a very interesting point. The only way that I can see to avoid that trap is to have a strong focus on
 usability as part of your development process, to make sure that developers
 have good connections with a diverse range of potential users and their
 experiences, and (where possible) for developers to dedicate part of their
 time to actually trying to undergo that experience themselves.

 The TL;DR of what I'm saying here is: while it's certainly crazy to force
 D contributors to use IDEs, there's a great deal of value in making sure
 that a good number of contributors regularly get IDE experience, and
 regularly try out "fresh start" installs of D in IDE and non-IDE
 environments, because that way you have a sense of how easy or painful it
 is for new users to get things installed and just get hacking.

Thank you. --047d7b41ccf8a94ea004e5671f70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 2 September 2013 23:36, Joseph Rushton Wakeling <span d= ir=3D"ltr">&lt;<a href=3D"mailto:joseph.wakeling webdrake.net" target=3D"_b= lank">joseph.wakeling webdrake.net</a>&gt;</span> wrote:<br><div class=3D"g= mail_extra"> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"=
On 02/09/13 14:51, Dicebot wrote:<br>

x #ccc solid;padding-left:1ex"> But do you seriously expect anyone with no personal business interest to wo= rk on<br> brining more of such crap into something that is not broken? You would have= had<br> my sympathy but demand &quot;Let&#39;s force everyone to use IDE&quot; is j= ust insane. All<br> this thread would have made some sense if some enterprise D entity has exis= ted<br> but it simply does not work that way right now. And, to be honest, I am gla= d<br> about it.<br> </blockquote> <br></div> Personally I find, observing a number of different open source projects, th= at a very typical problem is a kind of &quot;selection bias&quot; among con= tributors that leads them to significantly under-appreciate the usability p= roblems of their software.<br> <br> It goes something like this: anyone who has spent any length of time using = that software (which of course includes most contributors) either had a wor= kflow and toolchain that the software matched with, or they have been able = to adapt their workflow and toolchain to enable them to use the software. = =C2=A0Usually they have managed to find ways of coping and working around a= ny other usability issues that arise. =C2=A0And that situation then compoun= ds itself over time because new users come and either adapt in the same way= that existing contributors have, or they leave.<br> <br> So, you wind up with a body of contributors who often have much in common i= n terms of their setup, their perception of the priorities, and in their ab= ility to handle the software. =C2=A0And that in turn can be very dangerous,= because you get people who simply don&#39;t understand (or have any way to= experience) problems that are brought to them by new users or by others.<b= r> <br> And of course there are always greater problems than usability, so those pr= oblems are the ones that get focused on, with the developers all the while = bemoaning the lack of manpower and wondering why it is so difficult to attr= act and hold on to contributors.<br> </blockquote><div><br></div><div>I think this is a very interesting point.<= /div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> The only way that I can see to avoid that trap is to have a strong focus on= usability as part of your development process, to make sure that developer= s have good connections with a diverse range of potential users and their e= xperiences, and (where possible) for developers to dedicate part of their t= ime to actually trying to undergo that experience themselves.<br> <br> The TL;DR of what I&#39;m saying here is: while it&#39;s certainly crazy to= force D contributors to use IDEs, there&#39;s a great deal of value in mak= ing sure that a good number of contributors regularly get IDE experience, a= nd regularly try out &quot;fresh start&quot; installs of D in IDE and non-I= DE environments, because that way you have a sense of how easy or painful i= t is for new users to get things installed and just get hacking.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Thank you.</div></d= iv> --047d7b41ccf8a94ea004e5671f70--
Sep 02 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
 On 2013-09-01 19:54, Walter Bright wrote:
On 9/1/2013 2:50 AM, deadalnix wrote:
Considering DMD never deallocate anything, expect to restart your
IDE every hour or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.

That was in reply to if DMD was built as a library and included in the IDE. Then there wouldn't be a process to end.

module libDmd; auto parseDCode(string code) { pid_t pid; if ((pid=fork())==0) { dmdMain(...); exit(0); } else { auto status = waitpid(pid); return getReturnValue(...); } throw Exception("fork error"); } Though, granted, this may cause unacceptable performance hits. :-P T -- The best way to destroy a cause is to defend it poorly.
Sep 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 September 2013 at 15:06:40 UTC, H. S. Teoh wrote:
 On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
 On 2013-09-01 19:54, Walter Bright wrote:
On 9/1/2013 2:50 AM, deadalnix wrote:
Considering DMD never deallocate anything, expect to restart 
your
IDE every hour or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.

That was in reply to if DMD was built as a library and included in the IDE. Then there wouldn't be a process to end.

module libDmd; auto parseDCode(string code) { pid_t pid; if ((pid=fork())==0) { dmdMain(...); exit(0); } else { auto status = waitpid(pid); return getReturnValue(...); } throw Exception("fork error"); } Though, granted, this may cause unacceptable performance hits. :-P T

dude, libd is conceived in with that in mind, and I'm craving for help. I'm putting quite a lot of effort into it, but D is big, and any help would be welcome.
Sep 02 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
While there has been a lot of back and forth with Manu in this 
thread, I think it's best to look at his game jam experience as a 
kind of stress test for D installation and usage, ie informative 
but extreme.  Game development, especially in a rush and with 
everything being installed automatically for the user, is not a 
use case that is well-plumbed in D right now.  It would be nice 
if debugging properly worked, but given the complexity involved 
that Walter mentioned, it's understandable that it doesn't.

Speaking of debuggers, there was a BSD-licensed debugger written 
in D around 2009, likely D1.  It was abandoned by the author, who 
told me he got busy with work, but Martin Nowak resurrected it 
for some time a couple years back:

https://github.com/dawgfoto/ngdb

Perhaps it can be resurrected as a debugger for D, since it is 
written in D.

On Monday, 2 September 2013 at 07:42:52 UTC, Jacob Carlborg wrote:
 On 2013-09-01 21:44, Brian Schott wrote:

 It's a bit of a chicken-and-egg problem. I'd like to do this, 
 but there
 would have to be several companies already using D 
 professionally for it
 to be a viable business model. And for a company to invest in 
 D, they'd
 probably want the tooling to already exist.

I would like that as well. But I feel the same things. Are there any customers?

lot of these problems, which are about fit and finish, that many others have noted open source projects are notoriously bad at. I suggested a licensing model for how D could provide commercial support in a different thread: http://forum.dlang.org/thread/kq9r7t$nu$1 digitalmars.com#post-sglcqsiphpntcdlhvwvn:40forum.dlang.org The usual open source zealots argued with me, suggesting that any closed source reference implementation would be unwelcome, even if always accompanied by an open source implementation that's available for free. I won't get into the even sillier arguments used, ;) perhaps such people wouldn't mind as long it wasn't Walter and dmd, ie the reference implementation, that went closed/paid, ie if Brian or someone else did it. As for needing "several companies already using D professionally for it to be a viable business model," most companies don't start that way. You find a few users willing to pay for fit and finish or optimizations and you grow it from part-time work to as far as the business will go. I certainly hope someone is willing to do that.
Sep 02 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 ...

There is crucial difference between having a company providing commercial services for D users (good) and having anything closed/commercial in reference implementation (bad). Former is simply matching the demand from certain market segment. Latter is screwing the life for everyone else. There is hardly anything common here.
Sep 02 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 September 2013 at 08:30:26 UTC, Mike Parker wrote:
 On 9/2/2013 8:59 AM, Brad Anderson wrote:
 For a few releases now the D installer for Windows has created 
 a start
 menu shortcut that launches cmd.exe with dmd et al. added to 
 the PATH.
 It also adds to the PATH during installation if you let it.

Good news. Does it allow multiple versions of DMD to be installed simultaneously?

The system PATH modification would conflict of course but you could use the start menu shortcuts that set the PATH just fine.
Sep 02 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 September 2013 at 16:16:48 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 15:06:40 UTC, H. S. Teoh wrote:
 On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
 On 2013-09-01 19:54, Walter Bright wrote:
On 9/1/2013 2:50 AM, deadalnix wrote:
Considering DMD never deallocate anything, expect to 
restart your
IDE every hour or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.

That was in reply to if DMD was built as a library and included in the IDE. Then there wouldn't be a process to end.

module libDmd; auto parseDCode(string code) { pid_t pid; if ((pid=fork())==0) { dmdMain(...); exit(0); } else { auto status = waitpid(pid); return getReturnValue(...); } throw Exception("fork error"); } Though, granted, this may cause unacceptable performance hits. :-P T

dude, libd is conceived in with that in mind, and I'm craving for help. I'm putting quite a lot of effort into it, but D is big, and any help would be welcome.

I've never heard of libd? Is it the library-fication of SDC? I assume this is it? https://github.com/deadalnix/libd
Sep 02 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 1 September 2013 at 19:44:11 UTC, Brian Schott wrote:
 On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote:
 I think at this point, what D needs is a bit of commercial 
 support from a company like JetBrains or some equivalent. 
 Maybe there is now an opportunity for founding such a company, 
 one that would specialize in building professional tools 
 around the D language. I believe the language and the 
 compilers are stable enough to grow a serious business around 
 them. If we compare to what the state of C++ compilers was 
 before 2000, I believe we are much better off. And that was 
 just over a decade ago. Who knows what the state of D will be 
 in 5 years ? So yes, there is a case to be made for growing a 
 company around pro D tools, and the first company that does it 
 will grab the whole market.

It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist.

Your concern is legitimate of course, but there has been historically many cases where small companies have created a market in IT. There is clearly a demand for D tooling even if it's not huge right now, so I believe the risk is not as great as you think. Of course one needs some good skills to be able to come up with usable tools. But when nearly every D newcomer's first question is "where are the tools ?", there is a market for that.
Sep 02 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 2 September 2013 at 17:54:01 UTC, Dicebot wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 ...

There is crucial difference between having a company providing commercial services for D users (good) and having anything closed/commercial in reference implementation (bad). Former is simply matching the demand from certain market segment. Latter is screwing the life for everyone else. There is hardly anything common here.

Wait, I do not advocate building a closed source or non free reference implementation of the compiler or of the standard library. Those need to stay open source of course. But there are plenty of pro quality tools that are sorely missing right now: - an IDE that works with any of the 3 existing compilers - an integrated debugger - a graphical memory usage viewer/analyzer - a visual profiler - an integrated package manager - maybe a GUI library Etc. The existence of such tools would be a very big incentive for companies to try D seriously.
Sep 02 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
I think dicebot has hit a point there. It's true, much if not 
most of OS software is a (hopefully) somewhat niced up version of 
what was written to scratch a personal itch.

But I'm quite confident that this is not true for a project like 
D. I mean, just to come up with a solid and well thought 
description of the itch (like "C++ is a mess and a PITA") that 
can serve as guiding line when conceiving a language is a major 
undertaking. One possibly may come up with some script thingy 
just to scratch an itch; to conceive, design and implement 
something like D, however, was and is a very major undertaking, 
1000s and 1000s of hours, aso.

Wouldn't one like then that others see, too, what one has 
understood 10 years ago and tried to make better? Wouldn't one 
then want to make it really easy to test drive the language, see 
it's power (on cpus rather than web sites)?

My driver for complaining about D is *that it's so great* - but 
quite low on the useability side. If D weren't that great I'd 
simply have turned away.

I get Walter Brights point that he can't (and doesn't want to) be 
in charge of everything and the kitchen sink. The debugger issue 
though *does* concern dmd itself and not having a realiably 
working debugger with full (usual) functionality *is* a major 
show-stopper.
I mean, come on, how reasonable and consistent is it to leave the 
C/C++ mess and to then spread debug writelns all over the place?!

For the rest, I agree, it might be hard to see for emacs/vim 
crowd and the like. Yes, they are right, there is life without 
nice colors and mousing around development.
Let us not forget: To be somehow useable for insiders is only a 
first step. To really gain traction a second step must be taken: 
To be reasonably well useable according to what is common today. 
Which, I think, translates at least to: vim or emacs modes plus 
some decent cross platform editor like Scite and a"thin IDE" like 
geany. From there on it's a matter of taste and religion and - 
that's an important point! - having a comfortable base useability 
through the chain we can afford to say "You want X? Go and code 
it. The tools needed are there.".

A+ -R
Sep 02 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 1 Sep 2013 17:46:15 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Sun, Sep 01, 2013 at 12:40:00PM +0200, Dicebot wrote:
 Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway,
 key problem (as far as I can see) here is that few of D developers
 have both experience and personal interest in any IDE/Windows focus
 as well as related tool stack. D has some nice flavor of anarchy -
 both like it and consider it a problem.

The thing is, we keep hearing complaints about how D IDE integration is bad, etc., but it seems like not many people are willing to do something about it. What we need is somebody who is (1) dedicated to D, (2) dedicated to making IDE integration for D work nicely, (3) produce lots of code to make it work. Forcing people to change the way to work on D just so you can have IDE integration probably won't have much of an effect. For instance, I wouldn't touch an IDE with a 10-foot pole. Will I still contribute to D? Sure. Will I do something about IDE integration because everyone complains about it? Unlikely. Will I be glad if somebody steps up and say, here's what I've been doing to make D IDE integration better? I'd fully support it. The question is whether there is such a somebody. :)

Yea, that's what I've noticed too, and I've been kinda biting my tongue on it since this thread started. For all the people who complain about their unhappyness with D's IDEs, it's telling how few of them find it important enough to actually *work* on instead of merely complain. I found some RDMD issues that were blocking me, so I fixed them. I wanted Windows support for DVM, so I added it. I found the zip-creating process to be problematic, so I'm doing something about it (even though it turned out to be bigger than I'd anticipated). Not to say that IDE stuff isn't a much bigger job than those, but come on, we've got what, one person on Visual-D, one on Mono-D, and one who *used* to do XCode-D but gave up because (and I sympathize) he seemed to be the only one who cared enough to tackle it? Surly *something* could be contributed if it really is as big of a problem as people say (and I'm not doubting that it is). Sure there's the matter of "I just don't have time", but frankly *none* of us do. I know I sure as hell don't and yet I *make* the time anyway because it's an important and worthwhile investment for me. And look at Andrei - he's been was one of the top contributors and leaders and he did so even while he was working on a PhD *in addition* to a full time job and a new family. "Don't have time" doesn't count because its true for all of us. It just makes IDE users sound like spoiled "gimme gimme gimme", and I'm certainly not going to claim they are, but I just want to point out that's the impression that tends to come across. There's plenty of other areas D's needed improvement, and those people who actually cared have stepped up to the plate - so why aren't (for the most part) those who want IDE improvements? (Naturally I greatly applaud the efforts of the few IDE leaders we do have and have had in the past.)
Sep 02 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 01 Sep 2013 19:01:20 +0200
"Volcz" <volcz kth.se> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 </endrant>

Completely agree with Manu! I work in the Java + telecom world of programming and recently graduated, so that's the majority of my experience. From what I've seen and experienced is that most today programmers can't live without an IDE and a rock solid tool chain. I've seen many solutions posted in this thread to parts of the problems, eg auto complete, debugging etc. The thing with an IDE is that it has "JUST WORK" it should work with all the different components seamlessly. The question I would like to ask is how can WE as a COMMUNITY improve this situation? Official IDE support? Official "IDE components"? Roadmap? Other languages like Java have corporate backing. What difference makes this? Why doesn't we have a roadmap? How does other open source communities work and what can we learn from them? Sorry for the un-structure of my post.

To be honest, I never found Eclipse to "just work", especially with anything other than Java. Actually, for anything but Java I always found it to be an unusable nightmare (But good for Java even if less than perfect). Just FWIW.
Sep 02 2013
prev sibling next sibling parent "growler" <growlercab gmail.com> writes:
On Tuesday, 3 September 2013 at 02:06:55 UTC, Nick Sabalausky 
wrote:
 On Sun, 01 Sep 2013 19:01:20 +0200
 "Volcz" <volcz kth.se> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 </endrant>

Completely agree with Manu! I work in the Java + telecom world of programming and recently graduated, so that's the majority of my experience. From what I've seen and experienced is that most today programmers can't live without an IDE and a rock solid tool chain. I've seen many solutions posted in this thread to parts of the problems, eg auto complete, debugging etc. The thing with an IDE is that it has "JUST WORK" it should work with all the different components seamlessly. The question I would like to ask is how can WE as a COMMUNITY improve this situation? Official IDE support? Official "IDE components"? Roadmap? Other languages like Java have corporate backing. What difference makes this? Why doesn't we have a roadmap? How does other open source communities work and what can we learn from them? Sorry for the un-structure of my post.

To be honest, I never found Eclipse to "just work", especially with anything other than Java. Actually, for anything but Java I always found it to be an unusable nightmare (But good for Java even if less than perfect). Just FWIW.

+1 The Eclipse!1Gigabyte.editor is pure bloatware. I don't use GUIs, except for debugging, but if D does get an official GUI please don't let it be Eclipse. http://www.ihateeclipse.com/
Sep 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 September 2013 at 18:12:54 UTC, Brad Anderson wrote:
 I've never heard of libd?  Is it the library-fication of SDC?  
 I assume this is it? https://github.com/deadalnix/libd

Yep, SDC has been splitted in 3 : SDC itself, libd (parsing/semantic analysis) and libd-llvm (codegen, JIT).
Sep 02 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 Debugging:

Well, yes, for premium debugging support, you should probably use C#. Did C++ get to that level, I wonder?
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to 
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions 
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand the 
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class 
 definition, you want
 to quickly see what a class has and does.

Does C# solves this problem for you? This is what the members combobox is for, I guess: a clear list of members.
 I might have even just proved to them that they should indeed
 stick with C# (the IDE's work!)... :(

On Sunday, 1 September 2013 at 13:19:54 UTC, Manu wrote:
 Hmmm, I found details on the net that recommended adding an 
 [Environment64]
 section, which we did.

 I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on 
 my system
 :/ .. that said, VC obviously works on my machine.
 It also seems potentially problematic that a variable would 
 define a single
 install directory, since it's pretty common that programmers 
 have multiple
 versions of VS on their machines.

VS provides shortcuts to the environment setup scripts in the start menu, which sets up the environment variables. That's how it works for C, and it works the same for everything, which uses C.
Sep 03 2013
prev sibling next sibling parent Arjan <arjan ask.me> writes:
On Tue, 03 Sep 2013 04:06:53 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 On Sun, 01 Sep 2013 19:01:20 +0200
 "Volcz" <volcz kth.se> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 </endrant>

Completely agree with Manu! I work in the Java + telecom world of programming and recently graduated, so that's the majority of my experience. From what I've seen and experienced is that most today programmers can't live without an IDE and a rock solid tool chain.


Unfortunately that is my experience as well, even for senior developers. The ones that are able to get things done without an IDE are most often the 'geeks' 'aces' 'pro's', people with passion for the language/platform. When D wants to gain broader adoption (beyond the geek/ace/pro) an IDE like experience is indispensable and good debugging facilities is absolute mandatory!
 To be honest, I never found Eclipse to "just work"

Well w.r.t the CDT / linuxtools / pyDEV I can only say it has improved a _lot_ over the last years. In fact it has become my IDE of choice for C/C++/pyhon development on Linux/BSD.
Sep 03 2013
prev sibling next sibling parent "Don" <x nospam.com> writes:
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 We have to get the user experience and first impressions under 
 control...

I've created a bug report for the easiest of your requests: http://d.puremagic.com/issues/show_bug.cgi?id=10954 We need to do everything we can to make it more attractive to work on the IDE projects. This seems like an easy first step to start raising the profile.
Sep 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting that 
 any closed source reference implementation would be unwelcome, 
 even if always accompanied by an open source implementation 
 that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.
Sep 03 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 3 September 2013 at 13:25:44 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting that 
 any closed source reference implementation would be unwelcome, 
 even if always accompanied by an open source implementation 
 that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.

I suggest you read the thread if you need a reason, it's pretty obvious.
Sep 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 3 September 2013 at 15:34:31 UTC, Joakim wrote:
 On Tuesday, 3 September 2013 at 13:25:44 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting that 
 any closed source reference implementation would be 
 unwelcome, even if always accompanied by an open source 
 implementation that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.

I suggest you read the thread if you need a reason, it's pretty obvious.

Won't help, he is a zealot too.
Sep 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 September 2013 at 15:34:31 UTC, Joakim wrote:
 On Tuesday, 3 September 2013 at 13:25:44 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting that 
 any closed source reference implementation would be 
 unwelcome, even if always accompanied by an open source 
 implementation that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.

I suggest you read the thread if you need a reason, it's pretty obvious.

Thinking something is obvious so doesn't need to be demonstrated is another common traits amongst zealots.
Sep 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 September 2013 at 15:36:52 UTC, Dicebot wrote:
 On Tuesday, 3 September 2013 at 15:34:31 UTC, Joakim wrote:
 On Tuesday, 3 September 2013 at 13:25:44 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting 
 that any closed source reference implementation would be 
 unwelcome, even if always accompanied by an open source 
 implementation that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.

I suggest you read the thread if you need a reason, it's pretty obvious.

Won't help, he is a zealot too.

My life for Aïur !
Sep 03 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 3 September 2013 at 15:45:48 UTC, deadalnix wrote:
 On Tuesday, 3 September 2013 at 15:34:31 UTC, Joakim wrote:
 On Tuesday, 3 September 2013 at 13:25:44 UTC, deadalnix wrote:
 On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
 The usual open source zealots argued with me, suggesting 
 that any closed source reference implementation would be 
 unwelcome, even if always accompanied by an open source 
 implementation that's available for free.

Asserting people are zealot without actually providing any reason why make you sound like a zealot.

I suggest you read the thread if you need a reason, it's pretty obvious.

Thinking something is obvious so doesn't need to be demonstrated is another common traits amongst zealots.

Sure, but I did provide demonstration, that thread. The OSS zealots repeatedly make arguments that are wrong, irrelevant, and worst, just completely out of left field. This is a common pathology when you have decided on your conclusion and are arguing backwards from it: your arguments don't make any sense and come out of left field. They have decided that open source is good and closed source is bad, just like the global warming zealots, and will make silly arguments to try and justify that, even to someone like me who is trying to carve out a place for open source. You may agree with their conclusion and therefore defend their arguments, but any impartial observer wouldn't.
Sep 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 3 September 2013 at 15:46:16 UTC, deadalnix wrote:
 My life for Aïur !

En Taro Tassadar
Sep 03 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 2 September 2013 at 23:28:58 UTC, Walter Bright wrote:
 On 9/2/2013 1:11 AM, Jacob Carlborg wrote:
 That was in reply to if DMD was built as a library and 
 included in the IDE. Then
 there wouldn't be a process to end.

Ah, I see. But that does bring up the possibility of running dmd front end as a separate process, and then using interprocess communication with it? Isn't Google's Chrome browser built that way?

Yes, they sandbox a WebKit renderer and v8 javascript compiler for each browser tab in a different process, for both security and stability reasons, ie a crashed tab doesn't bring down the whole browser. The main browser process handles all networking and feeds the downloaded HTML/CSS/javascript to each of the renderer processes, which return a bitmap for the tab. It's not a strict rule, because if you have several tabs loaded with the same domain, they will sometimes share a renderer process. You can read more about it here: http://www.chromium.org/developers/design-documents/multi-process-architecture
Sep 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 September 2013 at 16:33:55 UTC, Joakim wrote:
 Sure, but I did provide demonstration, that thread.  The OSS 
 zealots repeatedly make arguments that are wrong, irrelevant, 
 and worst, just completely out of left field.  This is a common 
 pathology when you have decided on your conclusion and are 
 arguing backwards from it: your arguments don't make any sense 
 and come out of left field.

 They have decided that open source is good and closed source is 
 bad, just like the global warming zealots, and will make silly 
 arguments to try and justify that, even to someone like me who 
 is trying to carve out a place for open source.  You may agree 
 with their conclusion and therefore defend their arguments, but 
 any impartial observer wouldn't.

You seem confused by the difference between saying something and providing conclusive evidence.
Sep 03 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 3 September 2013 at 21:34:42 UTC, Timon Gehr wrote:
 On 09/03/2013 06:33 PM, Joakim wrote:
 Sure, but I did provide demonstration, that thread.

That thread seems to demonstrate a failure of communication.

By whom? It's pretty obviously the zealots.
 They have decided that open source is good and closed source 
 is bad,
 just like the global warming zealots, and will make silly 
 arguments to
 try and justify that, even to someone like me who is trying to 
 carve out
 a place for open source.  You may agree with their conclusion 
 and
 therefore defend their arguments, but any impartial observer 
 wouldn't.

"Any" impartial observer would notice the personal attacks, even if that observer was completely ignorant of the discussion topic. "Any" impartial observer would interpret those as lack of a well-reasoned argument and decide to spend his time impartially observing something more interesting.

I call it like I see it. An impartial observer can determine if what you call "personal attacks," more like labeling of the usually silly or wrong tenor of their arguments and what kind of person generally makes such dumb arguments, are accurate. If you want to take a long thread full of arguments about the topic and pick out a little name-calling and then run away, clearly the argument is lost on you. On Wednesday, 4 September 2013 at 00:25:30 UTC, deadalnix wrote:
 On Tuesday, 3 September 2013 at 16:33:55 UTC, Joakim wrote:
 Sure, but I did provide demonstration, that thread.  The OSS 
 zealots repeatedly make arguments that are wrong, irrelevant, 
 and worst, just completely out of left field.  This is a 
 common pathology when you have decided on your conclusion and 
 are arguing backwards from it: your arguments don't make any 
 sense and come out of left field.

 They have decided that open source is good and closed source 
 is bad, just like the global warming zealots, and will make 
 silly arguments to try and justify that, even to someone like 
 me who is trying to carve out a place for open source.  You 
 may agree with their conclusion and therefore defend their 
 arguments, but any impartial observer wouldn't.

You seem confused by the difference between saying something and providing conclusive evidence.

That thread _is_ conclusive evidence. If you think otherwise, you are deeply confused.
Sep 04 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Wednesday, 4 September 2013 at 13:23:19 UTC, Timon Gehr wrote:
 On 09/04/2013 11:26 AM, Joakim wrote:
 On Tuesday, 3 September 2013 at 21:34:42 UTC, Timon Gehr wrote:
 On 09/03/2013 06:33 PM, Joakim wrote:
 Sure, but I did provide demonstration, that thread.

That thread seems to demonstrate a failure of communication.

By whom? [...]

When communication fails, there is usually not a single side responsible for it. (Unless one side is trolling. Trolls are typically anonymous.)

Except that trolling has nothing to do with communication failure and one would think those zealots are the ones trolling, despite using what are presumably their real names, because of how dumb their arguments are.
 "Any" impartial observer would notice the personal attacks, 
 even if
 that observer was completely ignorant of the discussion 
 topic. "Any"
 impartial observer would interpret those as lack of a 
 well-reasoned
 argument and decide to spend his time impartially observing 
 something
 more interesting.

I call it like I see it.

Great.

Except that you then criticize me for "personal attacks" and name-calling, make up your mind.
 An impartial observer can determine if what
 you call "personal attacks," more like labeling of the usually 
 silly or
 wrong tenor of their arguments
 and what kind of person generally makes such dumb arguments, 
 are accurate.

How? Accuracy of conclusions of fallacious reasoning is mostly incidental. Consider googling "ad hominem", "association fallacy" and "fallacy of irrelevance".

I don't think you know what "incidental" means. :) In any case, if you can't see that they make several statements that are just factually wrong, I don't know what to tell you. If you are so ignorant that you don't even know the facts, there can be no discussion, which is why I bailed on that thread.
 If you want to take a long thread full of arguments about the 
 topic
 and pick out a little name-calling
 and then run away, clearly the argument is lost on you.

Frankly, I'm unimpressed. It's you who picked out the name-calling instead of arguments when summarizing the past discussion. In case any valuable arguments were part of that discussion then I'd advise to pick out those instead and put them in a coherent form.

I called them what they are, zealots, which isn't really name-calling but an accurate description, and noted one of their main dumb arguments, so I did both. I'm not going to summarize that thread for you: either read it or don't. I could care less either way, because you seem to make almost as many mistakes as them.
 On Wednesday, 4 September 2013 at 00:25:30 UTC, deadalnix 
 wrote:
 You seem confused by the difference between saying something 
 and
 providing conclusive evidence.

That thread _is_ conclusive evidence. If you think otherwise, you are deeply confused.

(Please do not mess up the threading.)

Responses to the two of you are best lumped together. I don't like it when people like you spam threads with multiple separate short responses to every other response in the thread. This is better.
 Well, if this kind of simply-minded pseudo-reasoning is to find 
 resonance, it has to be targeted at a less critical audience.

Except there was little reasoning in my above two sentences, only two statements about the other thread. The "critical audience" is not the problem, as you haven't been able to muster a "critical" response to any actual arguments in that thread. All you two do is make a bunch of dumb twits about the tone or character of the other thread, so I'll leave this "meta-discussion" here, as you two are clearly incapable of dealing with my actual arguments.
Sep 04 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 4 September 2013 at 18:00:21 UTC, Joakim wrote:
 Well, if this kind of simply-minded pseudo-reasoning is to 
 find resonance, it has to be targeted at a less critical 
 audience.

Except there was little reasoning in my above two sentences, only two statements about the other thread.

That, my friend, is called autodestruction. Now I'll have to invoke Poe's law and get out that thread.
Sep 04 2013
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
--047d7b2e4d7c13976104e5a26a1b
Content-Type: text/plain; charset=ISO-8859-1

The linux user ended up heading the art team so we didn't test on that
environment.
Ideally the Linux user would like D support in KDevelop. Monodevelop is
acceptable but a bit clunky.



On Sun, Sep 1, 2013 at 7:57 PM, Jacob Carlborg <doob me.com> wrote:

 On 2013-09-01 04:05, Manu wrote:

  Naturally, this is primarily a problem with the windows experience, but
 it's so frustrating that it is STILL a problem... how many years later?
 People don't want to 'do work' to install a piece of software. Rather,
 they expect it to 'just work'. We lost about 6 hours trying to get
 everyone's machines working properly.
 In the context of a 48 hour game jam, that's a terrible sign! I just
 kept promising people that it would save time overall... which I wish
 were true.

Was this only on Windows or were there problems on Linux/Mac OS X as well? Getting a workable environment:
 Unsurprisingly, the Linux user was the only person happy work with a
 makefile. Everybody else wanted a comfortable IDE solution (and the
 linux user would prefer it too).

I can understand that. IDE integration absolutely needs to be considered a first class feature
 of D.
 I also suggest that the IDE integration downloads should be hosted on
 the dlang download page so they are obvious and available to everyone
 without having to go looking, and also as a statement that they are
 actually endorsed by the dlanguage authorities. As an end-user, you're
 not left guessing which ones are good/bad/out of date/actually work/etc.

I completely agree. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
 only realistic choices available.

There's also DDT with Eclipse. It supports auto completion, go to definition, has an outline view and so on. The OSX user would have preferred an XCode integration.

This one is a bit problematic since Xcode doesn't officially supports plugins. But it's still possible, as been shown by Michel Fortin with his D for Xcode plugin. One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and difficult to navigate
 (like Java and C#).
 We all wanted to ability to define class member functions outside the
 class definition:
    class MyClass
    {
      void method();
    }

    void MyClass.method()
    {
      //...
    }

 It definitely cost us time simply trying to understand the class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class definition, you
 want to quickly see what a class has and does.

Sounds like you want an outline view in the IDE. This is supported by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline view. -- /Jacob Carlborg

--047d7b2e4d7c13976104e5a26a1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The linux user ended up heading the art team so we didn&#3= 9;t test on that environment.<br>Ideally the Linux user would like D suppor= t in KDevelop. Monodevelop is acceptable but a bit clunky.<div><br></div></= div> <div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Sep 1= , 2013 at 7:57 PM, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:d= oob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"> <div class=3D"im">On 2013-09-01 04:05, Manu wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> Naturally, this is primarily a problem with the windows experience, but<br> it&#39;s so frustrating that it is STILL a problem... how many years later?= <br></div><div class=3D"im"> People don&#39;t want to &#39;do work&#39; to install a piece of software. = Rather,<br> they expect it to &#39;just work&#39;. We lost about 6 hours trying to get<= br> everyone&#39;s machines working properly.<br> In the context of a 48 hour game jam, that&#39;s a terrible sign! I just<br=

were true.<br> </div></blockquote> <br> Was this only on Windows or were there problems on Linux/Mac OS X as well?<= div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Getting a workable environment:<br> <br> Unsurprisingly, the Linux user was the only person happy work with a<br> makefile. Everybody else wanted a comfortable IDE solution (and the<br> linux user would prefer it too).<br> </blockquote> <br></div> I can understand that.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> IDE integration absolutely needs to be considered a first class feature<br> of D.<br> I also suggest that the IDE integration downloads should be hosted on<br> the dlang download page so they are obvious and available to everyone<br> without having to go looking, and also as a statement that they are<br> actually endorsed by the dlanguage authorities. As an end-user, you&#39;re<= br> not left guessing which ones are good/bad/out of date/actually work/etc.<br=

<br></div> I completely agree.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the<br> only realistic choices available.<br> </blockquote> <br></div> There&#39;s also DDT with Eclipse. It supports auto completion, go to defin= ition, has an outline view and so on.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The OSX user would have preferred an =A0XCode integration.<br> </blockquote> <br></div> This one is a bit problematic since Xcode doesn&#39;t officially supports p= lugins. But it&#39;s still possible, as been shown by Michel Fortin with hi= s D for Xcode plugin.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> One more thing:<br> I&#39;ll just pick one language complaint from the weekend.<br> It is how quickly classes became disorganised and difficult to navigate<br> (like Java and C#).<br> We all wanted to ability to define class member functions outside the<br> class definition:<br> =A0 =A0class MyClass<br> =A0 =A0{<br> =A0 =A0 =A0void method();<br> =A0 =A0}<br> <br> =A0 =A0void MyClass.method()<br> =A0 =A0{<br> =A0 =A0 =A0//...<br> =A0 =A0}<br> <br> It definitely cost us time simply trying to understand the class layout<br> visually (ie, when IDE support is barely available).<br></div><div class=3D= "im"> You don&#39;t need to see the function bodies in the class definition, you<= br> want to quickly see what a class has and does.<br> </div></blockquote> <br> Sounds like you want an outline view in the IDE. This is supported by DDT i= n Eclipse. Even TextMate on Mac OS X has a form of outline view.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br></div> --047d7b2e4d7c13976104e5a26a1b--
Sep 05 2013
prev sibling next sibling parent "Sumit Raja" <sumitraja gmail.com> writes:
 Screw makefiles. dub[1] is the way to go. Dead easy to 
 configure [2] and dead easy to use. A default debug build on 
 the command line is "dub build", or even just "dub".

 [1] http://code.dlang.org/packages/dub
 [2] http://code.dlang.org/package-format

dub + Geany is my combination of choice. Great for cross platform - I'm using the same source tree to build across Windows, Linux and FreeBSD.
Sep 05 2013
prev sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Sunday, 1 September 2013 at 20:27:22 UTC, Nick Sabalausky 
wrote:
 On Sun, 1 Sep 2013 23:20:37 +1000
 Manu <turkeyman gmail.com> wrote:

 On 1 September 2013 17:46, Nick Sabalausky <
 SeeWebsiteToContactMe semitwist.com> wrote:
 
 On Sun, 01 Sep 2013 06:45:48 +0200
 "Kapps" <opantm2+spam gmail.com> wrote:

 On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
 One more thing:
 I'll just pick one language complaint from the weekend.
 It is how quickly classes became disorganised and 
 difficult to
 navigate
 (like Java and C#).
 We all wanted to ability to define class member functions
 outside the class
 definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

 It definitely cost us time simply trying to understand 
 the
 class layout
 visually (ie, when IDE support is barely available).
 You don't need to see the function bodies in the class
 definition, you want
 to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

I see it as the job of doc generators.

Why complicate the issue? What's wrong with readable code?

I spent several years using C/C++ exclusively (and was happy with it at the time) and I still don't understand what's "readable" about having a class's members separate from the class itself. It's also a non-DRY maintenance PITA and one of the biggest reasons I left C/C++. I don't like complicating things, and I like readable code. That's why I find C++-style class definitions intolerable.

I also hate them. It is always a pain to get back to C and C++ land with double header and implementation files, specially after being spoiled with languages that have proper module support.
Sep 06 2013