On 1 September 2013 20:08, Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-01 10:00, Walter Bright wrote:
>
>  If you have cookies disabled, of course you'll have to log in every
>> time. But that's the same with github, too.
>>
>
> Github also uses cookies, or something. I rarely have to log in at Github.


It uses OpenAuth doesn't it?
It seems I'm always logged in to Github like magic! :)

On 1 September 2013 22:01, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 01-Sep-2013 06:57, Andrej Mitrovic пишет:
>
>> On 9/1/13, Manu <turkeyman@gmail.com> wrote:
>> auto idx = array.countUntil(item);
>> if (idx != -1)
>>      array = array.remove(idx);
>>
>
> We just need better documentation/examples..
> E.g. this works fine:
>
>     int[] arr = [1, 2, 3, 1, 4 ];
>     arr = remove!(x => x == 1)(arr);
>     assert(arr == [2, 3, 4]);
>
> And one can even ask it to do unstable removal which is faster.


I'd agree that's fairly acceptable. It's just not obvious/intuitive. My bad, I should be more familiar with phobos than I am...

On 1 September 2013 03:05, Manu <turkeyman@gmail.com> 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?
>

First impressions are important.  And I've found that whenever I talk about D, people are generally wow'd at some of the design choices of the language vs Java, C++.  But I do stress that focus is really the only area that we are lacking in to get us across the chasm in terms of adoption.


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

Trying upgrading Windows.  https://www.fsf.org/windows8


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

Central to the community projects?
Absolutely yes.

Hosted in same location as DMD?
That's their choice if they want to do that.

Deprecate DMD Makefile?
I'd rather give both options, rather than force someone to go one way
or the other.

Force everyone to use IDE's?
VIM is an IDE. :o)


> IDE integration absolutely needs to be considered a first class feature of D.

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


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

That is their choice to make.

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

Why not VIM?

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

If you are referring to DMD as the whole application, that's their choice, but a library/plugin is not very useful for invoking directly. ;-)

If you are referring to the D Front-End implementation, I will request
for you to stop calling it DMD, and will also suggest a different
approach.
The components of the D Front-End are intended to be shared at the
source level, rather than being a library that gets built, installed,
and linked against. Thus, there is no distribution tarball; the idea
is to copy files from D Front-End into your own source tree.

This is something that I am working towards alongside DMD and LDC devs. So that we end up with a shared front-end between our compiler backends.  For IDE integration, they could in theory do the exact same.  Take the D Front-End and implement their backend against an IDE.


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

WAT.


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

This is why GDC rox.


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

Use the web?


> Bugs:
> 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 if that should work / don't see the advantage over just using a void*.


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

Shame on you.


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

That does seem more of the point of D interface files (.di).


> </endrant>

Twisted firestarter. :o)


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 1 September 2013 23:18, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/1/13, Manu <turkeyman@gmail.com> wrote:
> > ** If you want to link against any other libraries.
>
> Only if you want to do it statically, but you don't need to mess with COFF for DLLs, most of these libs you've listed can build either statically or as a DLL.
>

You mean dynamically loading DLL's, and finding/hooking up the symbols manually?

On 9/1/13, Manu <turkeyman@gmail.com> wrote:
> > Most of who? The D devs? You all reject auto-complete and debuggers? How do you get any work done?
>
> Well, we do get things done:
>
> http://www.ohloh.net/p/dmd/commits/summary http://www.ohloh.net/p/libphobos/commits/summary


I was joking.

On 9/1/13, Manu <turkeyman@gmail.com> wrote:
> >>>    - Deprecate DMD makefiles. Seriously! Insist that contributors use
> the
> >>> IDE bindings to work on DMD.
> >>
> >> Not gonna happen.
> >>
> >
> > Reconsider.
>
> 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.
>

It's basically a hack though. It interferes with the dependency chain, and
rebuild efficiency. Has some other weird side-effects too.
But even it it did to that, the experience that they would be confronted
with is broken auto-completion, and debugging issues.
It's pretty shit that it stands to end-users to report bugs of this kind,
when the devs working with this code every single day could catch
loads/most of the common ones themselves just by working in the end-user
environment for a while.

On 9/1/13, Manu <turkeyman@gmail.com> wrote:
> >> Slowing us down won't help anyone.
> >
> > I'd argue that it would; inflicting the pain of trying to be a
> productive D
> > user on the developers will certainly highlight the importance of the issue.
>
> It would only make people leave the community, just like Tomasz Stachowiak (h3r3tic) left, and now I've learned Michel Fortin is also not using D anymore.
>

I think this argues my point for me...
This stuff should be top priority!

Anyway it's not like we're not aware of the issues, these things are
> brought up in the newsgroups every other day. But the only way to fix the situation is: file bugs, contribute with pull requests.
>

Or enforce that the devs actually experience the end-user experience. Then
they'll know what the problems actually are, have a realistic perspective
of their productivity impact, and might take them more seriously.
I think it would have a tendency to change the perceived priority.

On 9/1/13, Manu <turkeyman@gmail.com> 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,
>
> See I don't understand this. You want everyone to work on the things you're most interested in (IDEs), but you can't bother reporting bugs.
>

I'm just saying it how it is, or at least, how it was perceived in this
instance by a room full of new D users, all professionals, mostly senior or
lead programmers with some sway in their companies.
None of the others could be bothered creating yet-another-webpage-account
to log bugs they encountered. I suggested they do so a few times. I was
promptly ignored.
It's just that manually logging in to non-ajax websites is so last decade.
People are growing very weary of creating and managing accounts on every
website they visit.

I definitely feel this is a worthwhile weekend's experience to share. Take it or leave it.

> Are you saying I should have told everyone to set up their machines before
> > coming?
>
> Well look, you've obviously used D in a 64bit environment (so you've had to set this up yourself at least once), so I don't understand how you've managed to lose 6 hours on it. :)
>

Actually, previous times I've used it, it did 'just work'. This time it didn't. I was surprised (and a tad embarrassed).

About 6 hours was lost trying to work out what the problems were, then configuring it on everyones machines, then making sure everyone had Visual-D, link issues against the libs we were using, some issues with the particular version of the MS CRT that DMD seemed to really want to link and external libs wanting a different CRT (I couldn't find how to configure it for other CRT's), then Mono-D on the non-windows machines, then OSX issues; GDC was the first compiler that user found, Mono-D had problems, eventually gave up and switched to DMD... trying to convince people that it would be better in the long run ;)

It's definitely not a 1-click install and get to work.

On 2 September 2013 01:02, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 1 September 2013 03:05, Manu <turkeyman@gmail.com> 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?
> >
>
> First impressions are important.  And I've found that whenever I talk about D, people are generally wow'd at some of the design choices of the language vs Java, C++.  But I do stress that focus is really the only area that we are lacking in to get us across the chasm in terms of adoption.
>
>
> >
> > 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.
> >
>
> Trying upgrading Windows.  https://www.fsf.org/windows8


Sadly, I already use Windows 8... *shudder* >_<

>
> > 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.
> >
>
> Central to the community projects?
> Absolutely yes.
>
> Hosted in same location as DMD?
> That's their choice if they want to do that.
>
> Deprecate DMD Makefile?
> I'd rather give both options, rather than force someone to go one way
> or the other.
>
> Force everyone to use IDE's?
> VIM is an IDE. :o)
>
>
> > IDE integration absolutely needs to be considered a first class feature
> of
> > D.
>
> 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.

> 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.
> >
>
> That is their choice to make.
>

Sure, that's why it's a 'suggestion' :)

> 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.
> >
>
> Why not VIM?
>

Ummm, because I'm not a masochist? :)
But each to their own. No reason VIM shouldn't have a nice integration
too...

> 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.
>
> If you are referring to DMD as the whole application, that's their choice, but a library/plugin is not very useful for invoking directly. ;-)
>
> If you are referring to the D Front-End implementation, I will request
> for you to stop calling it DMD, and will also suggest a different
> approach.
> The components of the D Front-End are intended to be shared at the
> source level, rather than being a library that gets built, installed,
> and linked against. Thus, there is no distribution tarball; the idea
> is to copy files from D Front-End into your own source tree.
>
> This is something that I am working towards alongside DMD and LDC devs. So that we end up with a shared front-end between our compiler backends.  For IDE integration, they could in theory do the exact same.  Take the D Front-End and implement their backend against an IDE.
>

Yeah that, and I know you guys are on it, and that's awesome. I was just
stressing the importance of the project.
Also perhaps the focus on an API for use by tools and IDE integration might
be helpful, but I don't know the code and what it offers.

I was really just referencing the countless prior conversations on the topic. When it's working, I suspect it'll help the IDE situation immensely.

>From conversations at dconf, I'm lead to believe one of the most important
elements that the d front end can offer is that it can still perform useful
analysis on partially compiled code, and on code that can't actually
compile due to errors (I think Don said CTFE depends on this ability a lot
too). Even in that case, the parts of the code that the compiler is able to
understand could still be offered for auto-completion purposes and all that
good stuff.
I'm sure it's very hard to reproduce that functionality in custom-written
semantic analysers, and it's critical to auto-complete analysis, in that
when you're in the process of typing code (when you use auto-complete),
it's rarely in a state that it can successfully compile ;)

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

The D frontend, whatever... it should be recycled to do the work, since it's already the best at it. I'm just repeating myself...

>
> > 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.
> >
> >
>
> This is why GDC rox.
>

O_o ... GDC produces DWARF info, which isn't so useful in windows.
We used to roll with dwarf->pdb conversion, but I think there's quite a
loss in translation, and it didn't work too well.

> 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.
> >
> >
>
> Use the web?
>

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
;)

> Bugs:
> > 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 if that should work / don't see the advantage over just using a void*.
>

struct Mesh;
struct Material;

Mesh* mesh;
Material* material;

material = mesh; // ?

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

>_<

> 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.
> >
> >
>
> 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?
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?
And why would you want to indent every line of function code by a few tabs?

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

On 9/1/2013 6:26 AM, Manu wrote:
> 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.

Sounds like a cookie problem. Maybe you have some sort of private browsing mode turned on?


> I also find the layout unappealing, and I find Github issues easier to
> navigate... but I'm not the one that has to use it daily, so I'm not really
> bothered by that.
> The part that irks me most is that I have to have
> yet-another-account-on-the-internet... Does bugzilla support OpenAuth?

Separate accounts do serve a legitimate purpose. If one of those accounts gets compromised, it doesn't ruin all your online accounts. This isn't a big problem for me, since cookies work on my browser :-)


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

One thing that can help with that is to have started new threads with each separate topic, with a meta comment as intro. It's one reason why I have multiple replies to your post.

On 9/1/2013 6:34 AM, Daniel Murphy wrote:
> "Manu" <turkeyman@gmail.com> wrote in message
>> I just report it anyway, and in the case of duplicates, someone that knows
>> what they're doing usually seems to clean it up >_< .. (Sorry!)
>>
>
> Please keep doing this.  It really isn't a big deal to clean up the
> duplicates.

I agree. And frankly, I have no idea how any automated system could remove duplicates. It often is hardly obvious that two bug reports are duplicates.

On 1 September 2013 17:37, Manu <turkeyman@gmail.com> wrote:
> On 2 September 2013 01:02, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>> On 1 September 2013 03:05, Manu <turkeyman@gmail.com> wrote:
>> > IDE integration absolutely needs to be considered a first class feature
>> > of
>> > D.
>>
>> 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.
>

Yeah... I'm still not buying it. :o)


>> > 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.
>> >
>>
>> Why not VIM?
>
>
> Ummm, because I'm not a masochist? :)
> But each to their own. No reason VIM shouldn't have a nice integration
> too...
>

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


>> > 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.
>> >
>>
>> WAT.
>
>
> The D frontend, whatever... it should be recycled to do the work, since it's already the best at it. I'm just repeating myself...
>

Ah, I just didn't understand what you were referring to first time round (the "as a service" was confusing also. :o)

I assume you mean using *enter IDE name here* to run syntax checks on your code as you type to highlight errors before you build using the compiler proper?


>> >
>> > 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.
>> >
>> >
>>
>> This is why GDC rox.
>
>
> O_o ... GDC produces DWARF info, which isn't so useful in windows.
> We used to roll with dwarf->pdb conversion, but I think there's quite a loss
> in translation, and it didn't work too well.
>

This is why using a free system rox.


>> > Bugs:
>> > 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 if that should work / don't see the advantage over just using a void*.
>
>
> struct Mesh;
> struct Material;
>
> Mesh* mesh;
> Material* material;
>
> material = mesh; // ?
>

The only used case I can think is in C++ bindings where you don't want to define the contents, but want to have the correct mangling (this I've had a partial need for in a project I'm working on behind the scenes that will come out at around the 2.064 release :-)

The language implementation would have to be changed to not produce TypeInfo for opaque types, but this might be undesirable in restrictions to the use of such types, but I guess you are asking for it if you want it.


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

Yes... though not outside the boundaries of implementing languages / interpreters / bytecode compilers. ;-)


> Perhaps the dev's here use relatively few, or very simple classes?

K.I.S.S.


> Seriously, how do you quickly read and understand the API through the noise?

Depends how well the author was at documenting his API.


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

Document the class as you write it.


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

I use GNU style myself...  (that probably *does* make me a masochist).

http://en.wikipedia.org/wiki/Indent_style#GNU_style


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 9/1/2013 6:35 AM, Andrej Mitrovic wrote:
> On 9/1/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> On 9/1/13, 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
>
> One other important thing to mention, you can use a desktop version of
> bugzilla lite which can download all bugs and let you browse bugs
> offline:
>
> http://almworks.com/deskzilla/overview.html
>
> It has no limitations for open-source projects.
>

I know Don swears by deskzilla.

On Sunday, 1 September 2013 at 16:37:19 UTC, Manu wrote:
> Can anyone offer me ANY benefits? It legitimately blows my mind... O_O

You don't need to keep declarations in sync, and you don't need to track down implementations.