On 01.09.2013 20:19, Iain Buclaw wrote:
> On 1 September 2013 19:01, Peter Alexander <peter.alexander.au@gmail.com> wrote:
>> Thank you for sharing this experience Manu, I had no idea there were so many
>> issues with D on windows. I primarily use OSX without problems, but have
>> also used it on windows for small projects, but I haven't experienced the
>> issues you describe.
>>
>> Can I just say to some of the others in this thread: comments along the
>> lines of "use vim" or "use a free os" are not helpful. These are legitimate
>> users and their issues are legitimate also, whether you agree with their
>> choice of environment or not.
>
> They were also my silly answers, and I say them because I spent a week
> sharing a room with Manu.  (So he should by now know when I am talking
> seriously. :o)
>
> I also voice them because "everyone should be forced to develop in an
> IDE" is not a helpful either (and so, I make my point in this way by
> countering with the extreme opposite).  It's all about freedom of
> choice, and if you impose restrictions on people (removing makefiles)
> because another option provides convenience (IDEs) regardless of the
> freedom to use that tool, well, err... yeah...

Some IDEs (such as Eclipse CDT) work at "layer above" the makefiles, so it's not that they can't coexist.

On 01/09/13 21:14, Andrej Mitrovic wrote:
> The stackoverflow approach of listing similarly named topics *as
> you're writing the topic name* is a good way for someone to find a
> topic that may had already been discussed. It would be great if we had
> this in bugzilla.

Actually, I wasn't thinking of the "Is this your bug?" question (which is very useful in itself).  I was thinking of the "Apport retracing service" in Launchpad which will automatically go through the detailed crash data uploaded and detect and mark duplicates this way.

On 01/09/13 19:19, Iain Buclaw wrote:
> Well my perspective doesn't help that whenever I think of IDE, the
> image of clippy comes into my head.
>
> http://vigor.sourceforge.net/screenshots/fullscreen.png

This is the way I'll always think of Clippy :-)

http://annoyingorange.wikia.com/wiki/File:Clippy-suicide.jpg

On 9/1/2013 11:01 AM, Peter Alexander wrote:
> Thank you for sharing this experience Manu, I had no idea there were so many
> issues with D on windows. I primarily use OSX without problems, but have also
> used it on windows for small projects, but I haven't experienced the issues you
> describe.
>
> Can I just say to some of the others in this thread: comments along the lines of
> "use vim" or "use a free os" are not helpful. These are legitimate users and
> their issues are legitimate also, whether you agree with their choice of
> environment or not.

Yes, I agree.

On Sun, 1 Sep 2013 23:28:50 +1000
Manu <turkeyman@gmail.com> wrote:

> On 1 September 2013 18:05, Daniel Cousens <daniel210x@gmail.com> wrote:
> >
> > That and its interface is so tedious, I have no idea how to check if it has already been reported...
> >
> 
> No, me either. Absolutely no idea.

TBH, I don't understand the above. There's an obvious search box right at the top of every page, right next to a link to advanced search. What else besides search *could* be used to check if an issue's already reported?

On Sun, 01 Sep 2013 12:06:56 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-01 09:55, Walter Bright wrote:
> 
> > All open issues (the latest are at the end):
> >
> > http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
> 
> I doesn't look like the latest are at the end. It seems to be sorted by status, not date.
> 

???

So click on the "ID" header to sort chronologically.

On Mon, 2 Sep 2013 02:37:09 +1000
Manu <turkeyman@gmail.com> wrote:

> On 2 September 2013 01:02, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >
> > Trying upgrading Windows.  https://www.fsf.org/windows8
> 
> 
> Sadly, I already use Windows 8... *shudder* >_<
> 

How do you get anything done?  ;)

> >
> > An IDE is not a feature of a language.  Unless you are a RAD language that removes the ability of developers to write a single line of code (and do it awfully).
> >
> 
> It certainly is in the case of C#. I think it's also central to C#'s
> success. People got in, and feel productive within seconds of firing
> it up. I've never had such a great language adoption experience. I
> clicked create project, and started writing code.
> The IDE is super helpful, and you can basically code by using the '.'
> key and consequent auto-completion popups as a documentation
> replacement.
> 

FWIW: I was a big fan of C# initially, but somewhere around VS 2005 it became so sluggish/bloated that it quickly negated any time savings. Couldn't get things done because it was like driving down the freeway at 15MPH.



> 
> Do. But the website is slow, and you probably haven't tried to use the
> internet in Australia recently.
> Also, our new government intends to set Australia's internet back
> about 10 years:
> http://www.youtube.com/watch?v=b-6E5yX1E0U
> http://www.youtube.com/watch?v=tpN7VCzDTdg
> http://www.youtube.com/watch?v=zyY-xI6zgfk
> 
> Quality leadership to be sure...
> Note: I can only watch these in 320p after about 20-30 seconds buffer
> time ;)
> 

Genuine question, not sarcasm: Have they decided to stop engaging in thinly-veiled censorship yet? Or at least admit that they censor? ("Oh no, we're not censoring! We're merely 'denying classification' on things that are outlawed without government classification!")


> > That does seem more of the point of D interface files (.di).
> >
> 
> I'm amazed at the resistance to this (a few no's, any yes's at all?). Do people here actually write D code, or rather, non-trivial D code? O_o Perhaps the dev's here use relatively few, or very simple classes? Seriously, how do you quickly read and understand the API through the noise?

Proper API documentation.

> I really can't get my head around it... Why wouldn't you want
> to be able to read a convenient summary of what a class is and does?

We do. That's why we have documentation and the -D flag.

> And why would you want to indent every line of function code by a few tabs?
> 

This isn't Python, nobody *has* to indent it.

> Can anyone offer me ANY benefits? It legitimately blows my mind... O_O
> 

To each his own, I guess. I was genuinely surprised a year or so ago when I first discovered there were people who actually liked trying to keep two separate copies of member signatures in sync.

On Sun, Sep 01, 2013 at 11:26:20PM +1000, Manu wrote:
> On 1 September 2013 18:00, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> > On 8/31/2013 9:36 PM, Manu wrote:
> >
> >> I'm really don't like bugzilla as an end-user, but I'm not performing searching actions.  As a reporter, I find it's needless friction between me and reporting bugs, and I consequently report perhaps half as many bugs as I would otherwise, because I need to open a slow website, and login with yet another account...
> >>
> >
> > Bugzilla sets a cookie on your machine so you don't have to repeatedly log in. I log in once every few months when something happens to my browser that deleted the cookies.
> >
> > If you have cookies disabled, of course you'll have to log in every time.  But that's the same with github, too.
> >
> 
> I don't have cookies disabled, but it doesn't seem to work for me... I have to login every few minutes.  It auto-logs-me-out every few minutes... if I leave it open in the background while I'm working so I can easily reach for it, I find it asks me to log in again basically every time.

Strange, I haven't had to login to the D bugzilla for months now. I did have to login a few times to get the cookie onto different browser installations I have (and after browser upgrades), but besides that, I'm just on all the time.


[...]
> I don't want my topic to get lost in this though, the first few items in my weekend report are the big tickets as I see it; installation, IDE, and debugging.

Well, I'm not an IDE person, so I have nothing to say on that front.

But I will say that debugging can and must be improved. Currently, about the only thing usable for dmd -g is to get a stacktrace of a program crash. Nothing else seems to be properly supported (I use gdb). Stepping through statements and setting breakpoints more-or-less works, but I can't get at most variables (keeps complains about being unable to reference 'this' or something similar), sometimes variable values are outright wrong or completely unrelated to the actual value, sometimes variables shown right on the source line being debugged don't exist in the debugger ('no such symbol'). Unable to look into nested structs without hitting odd behaviour. Doesn't understand D naming conventions (or does so poorly).

Basically, I've given up trying to use gdb on D programs except when I need to find out where a crash is happening. Using writeln debugging is far more productive, sadly to say. I can imagine this state of affairs is quite disappointing to many potential D adopters.


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On Sunday, September 01, 2013 17:14:01 H. S. Teoh wrote:
> Well, I'm not an IDE person, so I have nothing to say on that front.
> 
> But I will say that debugging can and must be improved. Currently, about the only thing usable for dmd -g is to get a stacktrace of a program crash. Nothing else seems to be properly supported (I use gdb). Stepping through statements and setting breakpoints more-or-less works, but I can't get at most variables (keeps complains about being unable to reference 'this' or something similar), sometimes variable values are outright wrong or completely unrelated to the actual value, sometimes variables shown right on the source line being debugged don't exist in the debugger ('no such symbol'). Unable to look into nested structs without hitting odd behaviour. Doesn't understand D naming conventions (or does so poorly).
> 
> Basically, I've given up trying to use gdb on D programs except when I need to find out where a crash is happening. Using writeln debugging is far more productive, sadly to say. I can imagine this state of affairs is quite disappointing to many potential D adopters.

This more or less mirrors my sentiments. I use (g)vim pretty much exclusively, so I don't really care about IDEs aside from how they help the community at large (your typical IDE's editing capabilites are so much of a joke compared to those of vim, that using an IDE really makes no sense for editing - for me at least).

However, I would definitely like improved debugger support. I almost always end up using writeln debugging except when I need to track down a segfault. Of course, gdb support for _C++_ sucks in my experience. It can't understand basic stuff like operator overloading. So, I wouldn't expect much from D support either - though it would be really nice if gdb could at least understand D strings. I certainly wouldn't be opposed to someone writing a solid debugger which was D-centric, as it would really improve debugging, but I'm not holding my hopes up at this point. That's a major undertaking.

- Jonathan M Davis

On 9/1/2013 5:14 PM, H. S. Teoh wrote:
> But I will say that debugging can and must be improved. Currently, about
> the only thing usable for dmd -g is to get a stacktrace of a program
> crash. Nothing else seems to be properly supported (I use gdb). Stepping
> through statements and setting breakpoints more-or-less works, but I
> can't get at most variables (keeps complains about being unable to
> reference 'this' or something similar), sometimes variable values are
> outright wrong or completely unrelated to the actual value, sometimes
> variables shown right on the source line being debugged don't exist in
> the debugger ('no such symbol'). Unable to look into nested structs
> without hitting odd behaviour. Doesn't understand D naming conventions
> (or does so poorly).

I've tried to figure this out many times, and have found the Dwarf format to be completely impenetrable. As far as I can tell, dmd generates correct Dwarf symbolic debug info according to the Dwarf spec.

gdb relies on very undocumented idiosyncratic combinations of things to work. It appears to be wrapped tightly around exactly what gcc generates.

I suppose the only way to figure it out is to read the gdb source code. Sigh.

BTW,

    dumpobj -p

on linux will pretty-print the Dwarf symbolic debug info. If anyone wants to take a stab at it, please do so!