www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are the worst parts of D?

reply "Tofu Ninja" <emmons0 purdue.edu> writes:
There was a recent video[1] by Jonathan Blow about what he would 
want in a programming language designed specifically for game 
development. Go, Rust, and D were mentioned and his reason for 
not wanting to use D is is that it is "too much like C++" 
although he does not really go into it much and it was a very 
small part of the video it still brings up some questions.

What I am curious is what are the worst parts of D? What sort of 
things would be done differently if we could start over or if we 
were designing a D3? I am not asking to try and bash D but 
because it is helpful to know what's bad as well as good.

I will start off...
GC by default is a big sore point that everyone brings up
"is" expressions are pretty wonky
Libraries could definitely be split up better

What do you think are the worst parts of D?

[1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
Sep 20 2014
next sibling parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap. 5. Too much focus on retaining C semantics (go does a bit better) 6. Inconsistencies and hacks (too many low hanging fruits) 7. More hacks are being added rather than removing existing ones. 8. Not enough performance oriented process. 9. It's mysteriously addictive and annoying at the same time. 10. It's contagious and now I'm in bed with a cold.
Sep 20 2014
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim 
Grostad wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap.
Not really a problem with the language. Just problems.
 5. Too much focus on retaining C semantics (go does a bit 
 better)

 6. Inconsistencies and hacks (too many low hanging fruits)

 7. More hacks are being added rather than removing existing 
 ones.
Definitely can agree, I think it has to do with the sentiment that it is "too much like C++"
 8. Not enough performance oriented process.
Not sure what you are saying, are you saying there is not a big enough focus on performance?
 9. It's mysteriously addictive and annoying at the same time.
Is that a problem?
 10. It's contagious and now I'm in bed with a cold.
:<
Sep 20 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote:
 Not really a problem with the language. Just problems.
It is kind of interlinked in a world that keeps moving forward. I found myself agreeing (or at least empathising) with a lot of what Jonathan Blow said. Of course, since his presentation was laid-back the people on reddit kind of attacked him and who knows, maybe he lost inspiration. He did at least respond on twitter. And his language project probably depends on his next game Witness (which sounds cool) to succeed. Anyway, I think he got the right take on it, reach out to other devs in his own sector and ask them about their practice, then tailor a language with little syntactical overhead for that use scenario. Of course, it won't fly if he doesn't manage to attract people who are more into the semantics of computer languages, but I root for him anyway. I like his attitude. On a related note I also read somewhere that Carmack is looking at GC for the gameplay data. Basically only a heap scanning, but compacting GC, that can run per frame. Seems the game logic usually fits in 5MB, so it might work.
 Definitely can agree, I think it has to do with the sentiment 
 that it is "too much like C++"
Yes, I think Jonathan got that part right. I guess also that any kind of "unique traits" that feels like "inventions" will be eagerly picked up and hold up as good ideas by enthusiasts. Even if they are just special cases of more general constructs or variations of existing concepts posing under a new name. Perhaps an important aspect of the sociology of computer languages. (Lispers tend to be terribly proud of their language of choice :)
 8. Not enough performance oriented process.
Not sure what you are saying, are you saying there is not a big enough focus on performance?
I think there is too much focus on features both in language and library. I'd personally prefer smaller and more benchmark focused. It is better to be very good at something limited, IMO. I also think that the big win in the coming years come for the language that most successfully can make elegant low overhead access to SIMD instructions without having to resort to intrinsics. I have no idea what the syntax would be, but that seems to be the most promising area of language design in terms of performance IMO.
Sep 20 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Jonathan Blow has expressed himself about D before…

http://www.kotaku.com.au/2012/05/most-popular-video-games-are-dumb-can-we-stop-apologising-for-them-now/

It could be incidental, of course.
Sep 20 2014
prev sibling parent reply "AsmMan" <jckj33 gmail.com> writes:
On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote:
 On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim 
 Grostad wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap.
Not really a problem with the language. Just problems.
 5. Too much focus on retaining C semantics (go does a bit 
 better)

 6. Inconsistencies and hacks (too many low hanging fruits)

 7. More hacks are being added rather than removing existing 
 ones.
Definitely can agree, I think it has to do with the sentiment that it is "too much like C++"
It's really needed to keep C++-compatible as possible otherwise too few people are going to use it. If C++ wasn't C-compatible do you think it would be a successfully language it is today? I don't think so.
Sep 22 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 22 Sep 2014 14:28:47 +0000
AsmMan via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 It's really needed to keep C++-compatible as possible otherwise=20
 too few people are going to use it. If C++ wasn't C-compatible do=20
 you think it would be a successfully language it is today? I=20
 don't think so.
D is not c++-compatible anyway. and talking about compatibility: it's what made c++ such a monster. if someone wants c++ he knows where to download c++ compiler. the last thing D should look at is c++.
Sep 22 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/22/14, 1:44 PM, ketmar via Digitalmars-d wrote:
 On Mon, 22 Sep 2014 14:28:47 +0000
 AsmMan via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 It's really needed to keep C++-compatible as possible otherwise
 too few people are going to use it. If C++ wasn't C-compatible do
 you think it would be a successfully language it is today? I
 don't think so.
D is not c++-compatible anyway.
D is ABI- and mangling-compatible with C++.
 and talking about compatibility: it's
 what made c++ such a monster. if someone wants c++ he knows where to
 download c++ compiler.

 the last thing D should look at is c++.
Well what can I say? I'm glad you're not making the decisions. Andrei
Sep 22 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 22 Sep 2014 16:14:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 D is not c++-compatible anyway.
D is ABI- and mangling-compatible with C++.
but we were talking about syntactic compatibility.
 Well what can I say? I'm glad you're not making the decisions.
i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++.
Sep 22 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 September 2014 at 01:39:00 UTC, ketmar via
Digitalmars-d wrote:
 On Mon, 22 Sep 2014 16:14:28 -0700
 Andrei Alexandrescu via Digitalmars-d 
 <digitalmars-d puremagic.com>
 wrote:

 D is not c++-compatible anyway.
D is ABI- and mangling-compatible with C++.
but we were talking about syntactic compatibility.
 Well what can I say? I'm glad you're not making the decisions.
i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++.
If you hate C++, you shouldn't have too much trouble to understand that offering a way out for people using C++ is key.
Sep 22 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 01:45:31 +0000
deadalnix via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 If you hate C++, you shouldn't have too much trouble to
 understand that offering a way out for people using C++ is key.
but there is! D is perfectly able to replace c++. ah, i know, there is alot of legacy c++ code and people can't just rewrite it in D. so... so bad for that people then.
Sep 22 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 23, 2014 at 04:38:51AM +0300, ketmar via Digitalmars-d wrote:
 On Mon, 22 Sep 2014 16:14:28 -0700
 Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
 wrote:
 
 D is not c++-compatible anyway.
D is ABI- and mangling-compatible with C++.
but we were talking about syntactic compatibility.
 Well what can I say? I'm glad you're not making the decisions.
i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++.
For a moment, I read that as you'll destroy any traces of C++, so the first thing that would go is the DMD source code. :-P T -- Shin: (n.) A device for finding furniture in the dark.
Sep 22 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 22 Sep 2014 19:16:27 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 For a moment, I read that as you'll destroy any traces of C++, so the
 first thing that would go is the DMD source code. :-P
but we have magicport! well, almost... i'll postpone c++ destruction until magicport will be complete and working. ;-)
Sep 22 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
The lack of clear direction or communication thereof.  A 
continual adding of new stuff to try and appease the theoretical 
masses who will certainly come flocking to D if implemented, and 
a lack of attention paid to tightening up what we've already got 
and deprecating old stuff that no one wants any more.  And 
inconsistency in how things work in the language.  Oh, and 
function attributes.  I'm sure someone likes them, but I'm 
drowning in pure system const immutable  nogc  illegitemate  wtf 
hell.
Sep 23 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.
* C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. Andrei
Sep 23 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei 
Alexandrescu wrote:
 On 9/23/14, 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.
* C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude.
Well yeah, but that's just the current clear direction. Who knows what it will be next week.
Sep 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 9:06 AM, Sean Kelly wrote:
 On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei Alexandrescu wrote:
 On 9/23/14, 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.
* C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude.
Well yeah, but that's just the current clear direction. Who knows what it will be next week.
It's been this for a good while, and it will probably be until done. -- Andrei
Sep 23 2014
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 23 September 2014 at 16:19:31 UTC, Andrei 
Alexandrescu wrote:
 On 9/23/14, 9:06 AM, Sean Kelly wrote:
 On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei 
 Alexandrescu wrote:
 On 9/23/14, 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.
* C++ compatibility Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude.
Well yeah, but that's just the current clear direction. Who knows what it will be next week.
It's been this for a good while, and it will probably be until done. -- Andrei
Here at work I'm toying with C++ compatibility right now: If it's viable, I would like to use D instead of C++ for a cloud tool that must link with C++ computer vision libraries... Right now it sounds promising, so this feature could really be very interesting, not only to facilitate the integration with existing in-house codebase, but also for brand new projects. I'm starting to think that there will be a lot of buzz and fuss about D as soon as good bindings to popular C++ libs will appear in the wild... --- /Paolo
Sep 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 9:40 AM, Paolo Invernizzi wrote:
 I'm starting to think that there will be a lot of buzz and fuss about D
 as soon as good bindings to popular C++ libs will appear in the wild...
Yah, and core.stdcpp will be quite the surprise. -- Andrei
Sep 23 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 23 September 2014 at 16:50:26 UTC, Andrei 
Alexandrescu wrote:
 On 9/23/14, 9:40 AM, Paolo Invernizzi wrote:
 I'm starting to think that there will be a lot of buzz and 
 fuss about D
 as soon as good bindings to popular C++ libs will appear in 
 the wild...
Yah, and core.stdcpp will be quite the surprise. -- Andrei
Really?? Wow. Awesome! Atila
Sep 23 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 23/09/14 18:19, Andrei Alexandrescu wrote:

 It's been this for a good while, and it will probably be until done. --
 Andrei
So why isn't there a publicly available road map? Note, this one [1] doesn't mention C++ nor the GC. [1] http://wiki.dlang.org/Agenda -- /Jacob Carlborg
Sep 23 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 11:13 PM, Jacob Carlborg wrote:
 On 23/09/14 18:19, Andrei Alexandrescu wrote:

 It's been this for a good while, and it will probably be until done. --
 Andrei
So why isn't there a publicly available road map? Note, this one [1] doesn't mention C++ nor the GC. [1] http://wiki.dlang.org/Agenda
Could you please update it? C++ and GC. C++ and GC. Thanks. -- Andrei
Sep 23 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 * C++ compatibility
 * Everything GC-related

 Probably a distant third is improving build tooling. But those 
 two are more important that everything else by an order of 
 magnitude.
In parallel there are other things like ddmd, checked ints in core library, perhaps to finish shared libs, to test the patch from Kenji that fixes the module system, and more. Bye, bearophile
Sep 23 2014
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
 […] and a lack of attention paid to tightening up what we've 
 already got and deprecating old stuff that no one wants any 
 more.
This. The hypocritical fear of making breaking changes (the fact that not all of them are bad has been brought up over and over again by some of the corporate users) is crippling us, making D a much more cluttered language than necessary. Seriously, once somebody comes up with an automatic fixup tool, there is hardly any generic argument left against language changes. Sure, there will always be some cases where manual intervention is still required, such as with string mixins. But unless we have lost hope that the D community is still to grow significantly, I don't see why the burden of proof should automatically lie on the side of those in favor of cleaning up cruft and semantical quirks. Most D code is still to be written. David
Sep 23 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 18:32:39 +0000
David Nadlinger via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Seriously, once somebody comes up with an automatic fixup tool,=20
i bet nobody will. for many various reasons.
Sep 23 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 11:32 AM, David Nadlinger wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
 […] and a lack of attention paid to tightening up what we've already
 got and deprecating old stuff that no one wants any more.
This. The hypocritical fear of making breaking changes (the fact that not all of them are bad has been brought up over and over again by some of the corporate users) is crippling us, making D a much more cluttered language than necessary. Seriously, once somebody comes up with an automatic fixup tool, there is hardly any generic argument left against language changes. Sure, there will always be some cases where manual intervention is still required, such as with string mixins. But unless we have lost hope that the D community is still to grow significantly, I don't see why the burden of proof should automatically lie on the side of those in favor of cleaning up cruft and semantical quirks. Most D code is still to be written.
Well put. Again, the two things we need to work on are C++ compatibility and the GC. -- Andrei
Sep 23 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei 
Alexandrescu wrote:
 Well put. Again, the two things we need to work on are C++ 
 compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Sep 23 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 12:01 PM, Sean Kelly wrote:
 On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
 Well put. Again, the two things we need to work on are C++
 compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Some. A lot more needs to. -- Andrei
Sep 23 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/09/2014 20:05, Andrei Alexandrescu wrote:
 On 9/23/14, 12:01 PM, Sean Kelly wrote:
 On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
 Well put. Again, the two things we need to work on are C++
 compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Some. A lot more needs to. -- Andrei
The resurrection of head-const? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 30 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via Digitalmars-d wrote:
 On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Is that even addressable?? D const is fundamentally different from C++ const. Short of introducing logical const into D, I don't see how we could bridge the gap. T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Sep 23 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via 
 Digitalmars-d wrote:
 On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei 
 Alexandrescu wrote:
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Is that even addressable?? D const is fundamentally different from C++ const. Short of introducing logical const into D, I don't see how we could bridge the gap.
I haven't really thought about it, but something could probably be made to work with type wrappers that do implicit casting plus just pretending that const is the same like we do with our C interfaces. I'm also wondering how we'd handle something like: struct S { virtual int foo() {...} }; std::map<int,S> m; We'd have to make S a value type in D, so struct, but D struct does't allow virtual functions. Maybe something weird with in-place construction of classes? I suspect the more we look into C++ compatibility the more problems we'll find, and actually interfacing with most C++ code worth using will result in terrifying D code. But I hope I'm wrong since C++ support is apparently now where all of our effort is being devoted (mark me down as being completely uninterested in this feature despite using C/C++ at work).
Sep 23 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 23, 2014 at 07:50:38PM +0000, Sean Kelly via Digitalmars-d wrote:
 On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via Digitalmars-d
 wrote:
On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via Digitalmars-d
wrote:
[...]
Has much thought gone into how we'll address C++ const?
Is that even addressable?? D const is fundamentally different from C++ const. Short of introducing logical const into D, I don't see how we could bridge the gap.
I haven't really thought about it, but something could probably be made to work with type wrappers that do implicit casting plus just pretending that const is the same like we do with our C interfaces. I'm also wondering how we'd handle something like: struct S { virtual int foo() {...} }; std::map<int,S> m; We'd have to make S a value type in D, so struct, but D struct does't allow virtual functions. Maybe something weird with in-place construction of classes?
Or turn them into function pointers / member delegates? But that doesn't work well with ABI compatibility.
 I suspect the more we look into C++ compatibility the more problems
 we'll find,
SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries.
 and actually interfacing with most C++ code worth using will result in
 terrifying D code.  But I hope I'm wrong since C++ support is
 apparently now where all of our effort is being devoted (mark me down
 as being completely uninterested in this feature despite using C/C++
 at work).
Yeah, I can't say I'm exactly thrilled about being able to call C++ code from D. I suppose it's a nice-to-have, but I'm not sure how well that's gonna work in practice, given the fundamental differences between D and C++. But be that as it may, if we're serious about cross-linguistic ABI compatibility, then we better start with a solid design of how exactly said interfacing is going to happen in a way that fits in well with how D works. Cowboying our way through piecemeal (i.e., ad hoc addition of compatibilities like adding C++ class support, then C++ templates, then SFINAE in extern(c++), then ...) isn't going to cut it. We might end up reinventing C++, even more poorly than C++ already is. T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Sep 23 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
 SFINAE is another dark corner of disaster waiting to happen, 
 once we
 decide to implement C++ template compatibility. As well as 
 Koenig
 lookup, which will become indispensible if D code is to 
 actually use
 non-trivial C++ libraries.
We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back.
Sep 23 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 4:25 PM, deadalnix wrote:
 On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via
 Digitalmars-d wrote:
 SFINAE is another dark corner of disaster waiting to happen, once we
 decide to implement C++ template compatibility. As well as Koenig
 lookup, which will become indispensible if D code is to actually use
 non-trivial C++ libraries.
We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back.
Yah, that's exactly it. Syntax and semantics stay D; the functions called may be C++. -- Andrei
Sep 23 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 23, 2014 at 11:25:52PM +0000, deadalnix via Digitalmars-d wrote:
 On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via
 Digitalmars-d wrote:
SFINAE is another dark corner of disaster waiting to happen, once we
decide to implement C++ template compatibility. As well as Koenig
lookup, which will become indispensible if D code is to actually use
non-trivial C++ libraries.
We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back.
You *will* need SFINAE if you expect to interface C++ template libraries with D. Imagine that an existing codebase is using some C++ template library that depends on SFINAE. You'd like to start migrating to D, so you start writing new code in D. Eventually you need to make use of the C++ template library in order to interface with the C++ parts of the code, so you write a .di that declares template functions in an extern(c++) block. It works... some of the time. Other times you start getting weird errors or the wrong functions get called, because the C++ template library was written with SFINAE in mind, but D doesn't have that. So at the end of the day, it's a gigantic mess, and you go crawling back to C++. Unless, of course, we draw the line at templates and say that we won't support template compatibility with C++ (and I'd fully support that decision!). But that means we throw all C++ template libraries out the window, and any C++ codebase that makes heavy use of a template library will have to be rewritten from scratch in D. As for Koenig lookup, you might run into problems if you declare C++ wrappers for D functions in the C++ part of the codebase, and suddenly the wrong D functions are getting called due to Koenig lookup in C++ which wasn't considered when the D part of the code was written. T -- Без труда не выловишь и рыбку из пруда.
Sep 23 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 5:06 PM, H. S. Teoh via Digitalmars-d wrote:
 You *will* need SFINAE if you expect to interface C++ template libraries
 with D.
Nope. -- Andrei
Sep 23 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 24 September 2014 at 00:08:19 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 You *will* need SFINAE if you expect to interface C++ template 
 libraries
 with D. Imagine that an existing codebase is using some C++ 
 template
 library that depends on SFINAE. You'd like to start migrating 
 to D, so
 you start writing new code in D. Eventually you need to make 
 use of the
 C++ template library in order to interface with the C++ parts 
 of the
 code, so you write a .di that declares template functions in an
 extern(c++) block. It works...  some of the time. Other times 
 you start
 getting weird errors or the wrong functions get called, because 
 the C++
 template library was written with SFINAE in mind, but D doesn't 
 have
 that. So at the end of the day, it's a gigantic mess, and you go
 crawling back to C++.
I think you can support a large part of C++ template without SFINAE. It is not that common and only matter for the binding if it changes the interface or the layout of something. If one want to map these, it can be done with some static if magic. But I'm fairly confident that it won't even be necessary is most situations.
Sep 23 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 September 2014 at 00:08:19 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 You *will* need SFINAE if you expect to interface C++ template 
 libraries
 with D. Imagine that an existing codebase is using some C++ 
 template
 library that depends on SFINAE. You'd like to start migrating 
 to D, so
 you start writing new code in D. Eventually you need to make 
 use of the
 C++ template library in order to interface with the C++ parts 
 of the
 code, so you write a .di that declares template functions in an
 extern(c++) block. It works...  some of the time. Other times 
 you start
 getting weird errors or the wrong functions get called, because 
 the C++
 template library was written with SFINAE in mind, but D doesn't 
 have
 that. So at the end of the day, it's a gigantic mess, and you go
 crawling back to C++.

 Unless, of course, we draw the line at templates and say that 
 we won't
 support template compatibility with C++ (and I'd fully support 
 that
 decision!). But that means we throw all C++ template libraries 
 out the
 window, and any C++ codebase that makes heavy use of a template 
 library
 will have to be rewritten from scratch in D.
I'm not a C++ guru, but it looks like SFINAE exists for simplicity, so that templates can be matched without template constraints and reflection. This looks equivalent to D template constraints. If template doesn't work for some parameters, just filter them out.
Sep 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 6:06 AM, Kagamin wrote:
 I'm not a C++ guru, but it looks like SFINAE exists for simplicity, so
 that templates can be matched without template constraints and
 reflection. This looks equivalent to D template constraints. If template
 doesn't work for some parameters, just filter them out.
That's right. The enable_if etc. stuff is still part of the type (and therefore the mangling), but the selection itself can be trivially done on the D side with template constraints. No worries, we know how to do it. -- Andrei
Sep 24 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 23/09/14 20:32, David Nadlinger wrote:

 Seriously, once somebody comes up with an automatic fixup tool, there is
 hardly any generic argument left against language changes.
Brain has already said that such a tool is fairly easy to create in many cases. Also that he is willing do to so if it will be used. But so far neither Andrei or Walter have shown any signs of willing to break code that can be fixed with a tool like this. I can understand that Brian doesn't want to create such a tool if it's not going to be used. -- /Jacob Carlborg
Sep 23 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 11:16 PM, Jacob Carlborg wrote:
 On 23/09/14 20:32, David Nadlinger wrote:

 Seriously, once somebody comes up with an automatic fixup tool, there is
 hardly any generic argument left against language changes.
Brain has already said that such a tool is fairly easy to create in many cases. Also that he is willing do to so if it will be used. But so far neither Andrei or Walter have shown any signs of willing to break code that can be fixed with a tool like this. I can understand that Brian doesn't want to create such a tool if it's not going to be used.
Some breakage will going to happen even though we're increasingly conservative. So yes, having a tool is nice. Andrei
Sep 23 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 14:29:05 +0000
Sean Kelly via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 function attributes.  I'm sure someone likes them, but I'm=20
 drowning in pure system const immutable  nogc  illegitemate  wtf=20
 hell.
and 'const' is such overpowered that it's barely usable on methods and struct/class fields.
Sep 23 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.  A continual adding of
new
 stuff to try and appease the theoretical masses who will certainly come
flocking
 to D if implemented, and a lack of attention paid to tightening up what we've
 already got and deprecating old stuff that no one wants any more.
I find this hard to reconcile with what the changelog says.
 And inconsistency in how things work in the language.  Oh, and function
attributes.
 I'm sure someone likes them, but I'm drowning in pure system const immutable
  nogc  illegitemate  wtf hell.
Fortunately, those attributes are inferred for template functions. I did try to extend that to auto functions, but got a lot of resistance.
Sep 23 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright 
wrote:
 On 9/23/2014 7:29 AM, Sean Kelly wrote:
 The lack of clear direction or communication thereof.  A 
 continual adding of new
 stuff to try and appease the theoretical masses who will 
 certainly come flocking
 to D if implemented, and a lack of attention paid to 
 tightening up what we've
 already got and deprecating old stuff that no one wants any 
 more.
I find this hard to reconcile with what the changelog says.
There's clearly been a lot of attention paid to bug fixes. But for the rest... I feel like the overall direction is towards whatever is currently thought to gain the most new users. The thing is that D has already *got* me. What I want is for the language I've already got to be polished until I can use it in a freaking space telescope. I'm sick of "yes but" languages. Every time I hit an obstacle in D I think "oh great, D is way behind other languages in all these ways and D itself is broken to boot. Why am I using this again?" And it could be a tiny thing. It doesn't matter. Every little issue like that is magnified a thousandfold because D is already such a hard sell. So in that respect I understand the push for C++ support because that's the speed bump that Andrei has hit. But here's the thing... by pursuing this we're effectively focusing all of our efforts *on another language*. And we're doing so when D itself still needs a lot of work. Maybe not in any truly immense ways, but as I said before, those tiny things can seem huge when you're already struggling to justify just using the language at all. Maybe all this will pull together into a cohesive whole, but so far it feels kind of disconnected. So that's part of what I meant by "tightening up."
 And inconsistency in how things work in the language.  Oh, and 
 function attributes.
 I'm sure someone likes them, but I'm drowning in pure system 
 const immutable
  nogc  illegitemate  wtf hell.
Fortunately, those attributes are inferred for template functions. I did try to extend that to auto functions, but got a lot of resistance.
Yes, the inference is very nice. And I do see the use for each attribute. It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise. It's information for the compiler, not me as a user. I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely.
Sep 23 2014
next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9/23/2014 9:46 PM, Sean Kelly via Digitalmars-d wrote:
 There's clearly been a lot of attention paid to bug fixes.  But for the
 rest... I feel like the overall direction is towards whatever is
 currently thought to gain the most new users.  The thing is that D has
 already *got* me.  What I want is for the language I've already got to
 be polished until I can use it in a freaking space telescope.  I'm sick
 of "yes but" languages. Every time I hit an obstacle in D I think "oh
 great, D is way behind other languages in all these ways and D itself is
 broken to boot.  Why am I using this again?"  And it could be a tiny
 thing.  It doesn't matter.  Every little issue like that is magnified a
 thousandfold because D is already such a hard sell.
I agree with Sean quite a bit here. Let's turn the camera around and look at it from a different angle. I'm hard pressed to find a new feature from the last few years that's actually thoroughly complete. And by complete I mean that druntime and phobos use it everywhere it should be used. Shared libraries? nope. Any of the new attributes? nope. 64 bit support? nope. const? shared? cleaning up object? .. nope. And that's not even getting into the big gaps that exist. I understand quite thoroughly why c++ support is a big win, or will be, but the Oh Shiny focus is pretty discouraging for me as well. This isn't meant to say the c++ work shouldn't be done, but to point out that the shifting focus is a real problem.
Sep 23 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 24/09/14 06:59, Brad Roberts via Digitalmars-d wrote:

 I agree with Sean quite a bit here.

 Let's turn the camera around and look at it from a different angle.  I'm
 hard pressed to find a new feature from the last few years that's
 actually thoroughly complete.  And by complete I mean that druntime and
 phobos use it everywhere it should be used.

 Shared libraries?  nope.
 Any of the new attributes?  nope.
 64 bit support?  nope.
 const?
 shared?
 cleaning up object?

 .. nope.

 And that's not even getting into the big gaps that exist.
I completely agree. Lets focus on the D users we actually have, not some imaginary C++ users that will come running as soon as there is enough C++ support. -- /Jacob Carlborg
Sep 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 11:22 PM, Jacob Carlborg wrote:
 On 24/09/14 06:59, Brad Roberts via Digitalmars-d wrote:

 I agree with Sean quite a bit here.

 Let's turn the camera around and look at it from a different angle.  I'm
 hard pressed to find a new feature from the last few years that's
 actually thoroughly complete.  And by complete I mean that druntime and
 phobos use it everywhere it should be used.

 Shared libraries?  nope.
 Any of the new attributes?  nope.
 64 bit support?  nope.
 const?
 shared?
 cleaning up object?

 .. nope.

 And that's not even getting into the big gaps that exist.
I completely agree. Lets focus on the D users we actually have, not some imaginary C++ users that will come running as soon as there is enough C++ support.
Those are very real. I know this for a fact. -- Andrei
Sep 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 23:24:21 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I completely agree. Lets focus on the D users we actually have, not
 some imaginary C++ users that will come running as soon as there is
 enough C++ support.
Those are very real. I know this for a fact. -- Andrei
all three of them.
Sep 24 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 24 September 2014 at 07:41:48 UTC, ketmar via 
Digitalmars-d wrote:
 all three of them.
You forget that D is now actively used at Facebook, and better C++ interop would allow them to slowly phase out more and more C++ code. The more Facebook uses D, the more support it will provide. Not to mention the social capital that D would gain from the fact that it's heavily used and supported at Facebook. It's not even really a question of whether C++ support should be worked on or not, in my opinion.
Sep 24 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 07:59:40 +0000
Meta via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You forget that D is now actively used at Facebook
no, i'm not. i just can't see why facebook priorities should be D priorities. facebook needs c++ interop? ok, they can hire alot of programmers to write this. *not* Walter and Andrei. and not dragging that into primary targets for D.
 not even really a question of whether C++ support should be=20
 worked on or not, in my opinion.
i'm not against c++ interop, i'm just against making it high-priority task. it's not something that we *must* have, it's just a "good-to-have feature", nothing more.
Sep 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 1:08 AM, ketmar via Digitalmars-d wrote:
 On Wed, 24 Sep 2014 07:59:40 +0000
 Meta via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You forget that D is now actively used at Facebook
no, i'm not. i just can't see why facebook priorities should be D priorities. facebook needs c++ interop? ok, they can hire alot of programmers to write this. *not* Walter and Andrei. and not dragging that into primary targets for D.
Your guidance of my career is uncalled for.
 not even really a question of whether C++ support should be
 worked on or not, in my opinion.
i'm not against c++ interop, i'm just against making it high-priority task. it's not something that we *must* have, it's just a "good-to-have feature", nothing more.
This is Walter's and my vision. He is working on C++ interop, and I am working on C++ interop. To the extent possible we hope the larger community will share this vision and help us to implement it. Andrei
Sep 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 07:44:38 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 Your guidance of my career is uncalled for.
excuse me, i'm not trying to tell you what to do. neither i was trying to say that you are forced to work on the features you don't want. same for Walter. it was a bad example and i missed the thing i wanted to highlight.
 This is Walter's and my vision. He is working on C++ interop, and I
 am working on C++ interop. To the extent possible we hope the larger=20
 community will share this vision and help us to implement it.
from my side i'm trying to at least not hijacking technical threads (sorry if i sent some of my rants to some of them, it's by accident). this is the maximum of my possible help in this area.
Sep 24 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 24 September 2014 at 07:41:48 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 23 Sep 2014 23:24:21 -0700
 Andrei Alexandrescu via Digitalmars-d 
 <digitalmars-d puremagic.com>
 wrote:

 I completely agree. Lets focus on the D users we actually 
 have, not
 some imaginary C++ users that will come running as soon as 
 there is
 enough C++ support.
Those are very real. I know this for a fact. -- Andrei
all three of them.
I don't understand how it isn't obvious how important C++ interop would be in getting new users to switch. I especially don't understand it since it's been mentioned several times so far how important C interop was for C++'s adoption. I write unit tests at work for C code in C++. Because I can. To this day, C++ is getting used because it's C-compatible. Atila
Sep 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 09:33:30 +0000
Atila Neves via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I don't understand how it isn't obvious how important C++ interop=20
 would be in getting new users to switch.
'cause it's not.
 I especially don't=20
 understand it since it's been mentioned several times so far how=20
 important C interop was for C++'s adoption.
you are wrong. C++ is *almost* compatible with C *on* *the* *source* *code* *level*. D is not and will not. this is two completely unrelated things. it doesn't matter how hard D will try to interop with C++, D will never be able to compile C++ code. yet C++ *is* able to compile C code. do you see any difference here?
Sep 24 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 04:46:00AM +0000, Sean Kelly via Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright wrote:
On 9/23/2014 7:29 AM, Sean Kelly wrote:
[...]
 There's clearly been a lot of attention paid to bug fixes.  But for
 the rest... I feel like the overall direction is towards whatever is
 currently thought to gain the most new users.  The thing is that D has
 already *got* me.  What I want is for the language I've already got to
 be polished until I can use it in a freaking space telescope.  I'm
 sick of "yes but" languages.  Every time I hit an obstacle in D I
 think "oh great, D is way behind other languages in all these ways and
 D itself is broken to boot.  Why am I using this again?"  And it could
 be a tiny thing.  It doesn't matter.  Every little issue like that is
 magnified a thousandfold because D is already such a hard sell.
Yeah, I wish that at least *some* attention would be paid to refining existing features so that problematic corner cases could be ironed out. Like identifier lookup rules for local imports. And what to do about dtors. And so many little niggling details that seem minor, but added together, can form a pretty big mountain of frustration sometimes. [...]
And inconsistency in how things work in the language.  Oh, and
function attributes.  I'm sure someone likes them, but I'm drowning
in pure system const immutable  nogc  illegitemate  wtf hell.
Fortunately, those attributes are inferred for template functions. I did try to extend that to auto functions, but got a lot of resistance.
I support attribute inference for auto functions. The more inference, the better, I say. That's the only way attributes will become practically useful.
 Yes, the inference is very nice.  And I do see the use for each
 attribute.  It's just... when I look at a function and there's a line
 of attributes before the function declaration that have nothing to do
 with what the function actually does but rather with how it's
 implemented, it's just syntactic noise.  It's information for the
 compiler, not me as a user.  I hope we'll eventually get to the point
 where everything is inferred and the attributes disappear entirely.
I haven't actually tried this yet, but I'm been toying with the idea of writing *all* functions as template functions (except where impossible, like virtual functions), even if they would take only zero compile-time arguments. This way, I reap the benefits of attribute inference, *and* I also get automatic culling of unused functions from the executable ('cos they wouldn't be instantiated in the first place). T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
Sep 23 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
 Yeah, I wish that at least *some* attention would be paid to refining
 existing features so that problematic corner cases could be ironed out.
It's kinda maddening to hear statements like that. Just in 2.066: 103 compiler regressions fixed 235 compiler bugs fixed 39 language enhancements 12 phobos regressions fixed 110 phobos bugs fixed 41 phobos enhancements 9 druntime regressions fixed 17 druntime bugs fixed 9 druntime enhancements https://dlang.org/changelog.html#list2066
 Like identifier lookup rules for local imports.
Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else?
 And what to do about
 dtors. And so many little niggling details that seem minor, but added
 together, can form a pretty big mountain of frustration sometimes.
So help out!
 I haven't actually tried this yet, but I'm been toying with the idea of
 writing *all* functions as template functions (except where impossible,
 like virtual functions), even if they would take only zero compile-time
 arguments. This way, I reap the benefits of attribute inference, *and* I
 also get automatic culling of unused functions from the executable ('cos
 they wouldn't be instantiated in the first place).
Yup, give it a try.
Sep 23 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 10:37 PM, Walter Bright wrote:
 On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
 Yeah, I wish that at least *some* attention would be paid to refining
 existing features so that problematic corner cases could be ironed out.
So help out!
I note that you've had many contributions accepted, this is great: https://github.com/D-Programming-Language/dmd/pulls?q=is%3Apr+is%3Aclosed+author%3Aquickfur https://github.com/D-Programming-Language/phobos/pulls?q=is%3Apr+author%3Aquickfur So please work on the refinements you wish for!
Sep 23 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 24/09/14 07:37, Walter Bright wrote:

 So help out!
You always say we should help out instead of complaining. But where are all the users that want C++ support. Let them implement it instead and lets us focus on actual D users we have now. -- /Jacob Carlborg
Sep 23 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 11:20 PM, Jacob Carlborg wrote:
 On 24/09/14 07:37, Walter Bright wrote:

 So help out!
You always say we should help out instead of complaining. But where are all the users that want C++ support. Let them implement it instead and lets us focus on actual D users we have now.
This thinking is provincial and damaging. We need to focus on both retaining our current users as well as in getting to the next level of magnitude. And for that we need C++ compatibility and improving everything about the GC story. -- Andrei
Sep 23 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 11:20 PM, Jacob Carlborg wrote:
 On 24/09/14 07:37, Walter Bright wrote:
 So help out!
You always say we should help out instead of complaining.
That's right. Complaining does nothing.
 But where are all the users that want C++ support. Let them implement it
instead and lets us focus on
 actual D users we have now.
I was there at the C++ revolution (and it was a revolution) almost at the beginning. And in fact, a reasonable case could be made that I caused the success of C++ by providing an inexpensive C++ compiler on the most popular (by far) platform at the right moment. What sold C++ was you could "ease" on into it because it would compile your existing C code. Later on, other C++ compilers came out. I'd talk to my sales staff at Zortech, asking them how they sold Zortech C++. What was the line that sold the customer. They told me "Zortech C++ is the only C++ compiler that can generate 16 bit Windows code. End of story. Sold!" I.e. none of the features of ZTC++ mattered, except one killer feature that nobody else had, and that nobody else even had a story for. Now, consider interfacing with existing C++ code. Which top 10 Tiobe languages can? C: no Java: no Objective C: sort of http://philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects C++: yes C#: no Basic: no PHP: no Python: no Javascript: no Transact-SQL: no and: Go: no Rust: no The ones marked "no" have no plan, no story, no nothing. This means if we have some level of C++ interop, we have a killer feature. If users have a "must have" C++ library, they can hook up to it. Can they use other languages? Nope. They have to wrap it with a C interface, or give up. Wrapping with a C interface tends to fall apart when any C++ templates are involved. C++ libraries are currently a language "lock in" to C++. There are no options. I've often heard from people that they'd like to try D, but it's pointless because they are not going to rewrite their C++ libraries. Case in point: last fall Adam Wilson started on Aurora, a C++ Cinder clone. I had thought he could simply wrap to the C++ library. No way. It was just unworkable, and Cinder was too big to rewrite. Aurora was abandoned. If we could have interfaced to it, things would have been much different. This story is not unusual. That said, C++ interop is never going to be easy for users. We're just trying to make it possible for a savvy and determined user. And he'll have to be flexible on both the C++ side and the D side.
Sep 23 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 23:54:32 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This means if we have some level of C++ interop, we have a killer
 feature.
and if we have OCR in phobos we have a killer feature. hey, i know two users that will switch to D if D will have good OCR in standard library! yet i know noone who will switch to D if D will get good c++ interop. note that i have many friends who are programmers and almost none of them interested in OCR. what i want to say is that c++ interop topic is overhyped. but lets just check it: start a little survey with one question: "how many people you know that will surely switch to D if it will get great c++ interop?" i for myself already know the results of such survey.
Sep 24 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 24 September 2014 at 06:54:38 UTC, Walter Bright 
wrote:
 On 9/23/2014 11:20 PM, Jacob Carlborg wrote:
 On 24/09/14 07:37, Walter Bright wrote:
 So help out!
You always say we should help out instead of complaining.
That's right. Complaining does nothing.
 But where are all the users that want C++ support. Let them 
 implement it instead and lets us focus on
 actual D users we have now.
I was there at the C++ revolution (and it was a revolution) almost at the beginning. And in fact, a reasonable case could be made that I caused the success of C++ by providing an inexpensive C++ compiler on the most popular (by far) platform at the right moment. What sold C++ was you could "ease" on into it because it would compile your existing C code. Later on, other C++ compilers came out. I'd talk to my sales staff at Zortech, asking them how they sold Zortech C++. What was the line that sold the customer. They told me "Zortech C++ is the only C++ compiler that can generate 16 bit Windows code. End of story. Sold!" I.e. none of the features of ZTC++ mattered, except one killer feature that nobody else had, and that nobody else even had a story for. Now, consider interfacing with existing C++ code. Which top 10 Tiobe languages can? C: no Java: no Objective C: sort of http://philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects C++: yes C#: no Basic: no PHP: no Python: no Javascript: no Transact-SQL: no and: Go: no Rust: no The ones marked "no" have no plan, no story, no nothing. This means if we have some level of C++ interop, we have a killer feature. If users have a "must have" C++ library, they can hook up to it. Can they use other languages? Nope. They have to wrap it with a C interface, or give up. Wrapping with a C interface tends to fall apart when any C++ templates are involved. C++ libraries are currently a language "lock in" to C++. There are no options. I've often heard from people that they'd like to try D, but it's pointless because they are not going to rewrite their C++ libraries. Case in point: last fall Adam Wilson started on Aurora, a C++ Cinder clone. I had thought he could simply wrap to the C++ library. No way. It was just unworkable, and Cinder was too big to rewrite. Aurora was abandoned. If we could have interfaced to it, things would have been much different. This story is not unusual. That said, C++ interop is never going to be easy for users. We're just trying to make it possible for a savvy and determined user. And he'll have to be flexible on both the C++ side and the D side.
C#: half-yes, when on Windows and C++ is exposed via COM or WinRT. In any case I agree with you. C++ got successful thanks to your work and other vendors that were bundling it with their C compilers. If C++ was a separate product that companies had to buy extra on top of their C compilers, it would have failed. -- Paulo
Sep 24 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 24 September 2014 at 06:54:38 UTC, Walter Bright 
wrote:
 If users have a "must have" C++ library, they can hook up to 
 it. Can they use other languages? Nope. They have to wrap it 
 with a C interface, or give up. Wrapping with a C interface 
 tends to fall apart when any C++ templates are involved.
That's exactly the case for the company I work for. --- /Paolo
Sep 24 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 9/24/14, 3:20 AM, Jacob Carlborg wrote:
 On 24/09/14 07:37, Walter Bright wrote:

 So help out!
You always say we should help out instead of complaining. But where are all the users that want C++ support. Let them implement it instead and lets us focus on actual D users we have now.
Maybe Facebook needs D to interface with C++?
Sep 25 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-25 21:02, Ary Borenszweig wrote:

 Maybe Facebook needs D to interface with C++?
But I only see Andrei working on that. Don't know how much coding he does in practice for C++ compatibility. -- /Jacob Carlborg
Sep 25 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 23, 2014 at 10:37:59PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed
out.
It's kinda maddening to hear statements like that. Just in 2.066: 103 compiler regressions fixed 235 compiler bugs fixed 39 language enhancements 12 phobos regressions fixed 110 phobos bugs fixed 41 phobos enhancements 9 druntime regressions fixed 17 druntime bugs fixed 9 druntime enhancements https://dlang.org/changelog.html#list2066
Like identifier lookup rules for local imports.
Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else?
No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on. Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code.
And what to do about dtors. And so many little niggling details that
seem minor, but added together, can form a pretty big mountain of
frustration sometimes.
So help out!
I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. The situation with Phobos has improved dramatically, thanks to a well-timed rant some months ago, which triggered a coordinated effort of aggressive merging, pinging, reviewing, etc. -- we've managed to cut the Phobos PR queue from around 90+ to around 29 as of last night (from 4+ pages on github to only barely 2 pages). For that, I applaud my fellow Phobos reviewers, and I hope the trend will continue until the Phobos PR queue is firmly back at 1 page (<=25 open PRs). Unfortunately, the problem persists in druntime, dlang.org, and dmd. It feels like there's a forest fire raging and only a handful of firefighters, and now we want to add more fires (new development directions) without adding more people. What about reviewing and merging / rejecting the 100+ PRs in the dmd queue, most of which contain fixes and language improvements that people have been waiting for, for a long time, before we think about new directions? Some PRs appear to fix bugs opened *years* ago, and yet nothing is done about them. Some PRs are at an impasse due to decisions that need to be made, yet nobody is making said decisions or even discussing them, and the PRs just continue to rot there. There are already a *ton* of new features / fixes / language improvements that are waiting to be decided upon (and, given the size of the dmd PR queue, I submit this is no exaggeration), and yet we are indifferent and instead look away to new directions. Many of us are indeed ready to help, but it would *really* be nice if our help is received more readily, or, at the very least, *some* indication is shown that more effort will be put into reviewing said help before more energy is expended in new directions. The dramatic shortening of the Phobos PR queue over the last 2-3 months proves that this is not only possible, but also beneficial (more fixes are making it into Phobos than ever before) and improves morale (people are more likely to contribute if they don't have to wait 3 weeks before getting any feedback for their contribution) -- if we would only put our efforts into it. So here's to hoping that the other PR queues will shorten quickly in the near future. ;-) And mind you, the lengths of the PR queues are only the tip of the iceberg of stuff we ought to finish doing before embarking on the next new direction. There are a ton of old bugs that need attention, and a ton of language features that need improvement / refinement. We could at least pay those *some* heed even if we absolutely have to start something new right now at this moment. It would be a great tragedy if D goes down in history as the project that had so many great ideas, none of them carried out to completion. T -- Debian GNU/Linux: Cray on your desktop.
Sep 24 2014
next sibling parent "bachmeier" <no spam.com> writes:
On Wednesday, 24 September 2014 at 18:46:29 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Tue, Sep 23, 2014 at 10:37:59PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
Yeah, I wish that at least *some* attention would be paid to 
refining
existing features so that problematic corner cases could be 
ironed
out.
It's kinda maddening to hear statements like that. Just in 2.066: 103 compiler regressions fixed 235 compiler bugs fixed 39 language enhancements 12 phobos regressions fixed 110 phobos bugs fixed 41 phobos enhancements 9 druntime regressions fixed 17 druntime bugs fixed 9 druntime enhancements https://dlang.org/changelog.html#list2066
Like identifier lookup rules for local imports.
Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else?
No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on. Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code.
And what to do about dtors. And so many little niggling 
details that
seem minor, but added together, can form a pretty big 
mountain of
frustration sometimes.
So help out!
I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. The situation with Phobos has improved dramatically, thanks to a well-timed rant some months ago, which triggered a coordinated effort of aggressive merging, pinging, reviewing, etc. -- we've managed to cut the Phobos PR queue from around 90+ to around 29 as of last night (from 4+ pages on github to only barely 2 pages). For that, I applaud my fellow Phobos reviewers, and I hope the trend will continue until the Phobos PR queue is firmly back at 1 page (<=25 open PRs). Unfortunately, the problem persists in druntime, dlang.org, and dmd. It feels like there's a forest fire raging and only a handful of firefighters, and now we want to add more fires (new development directions) without adding more people. What about reviewing and merging / rejecting the 100+ PRs in the dmd queue, most of which contain fixes and language improvements that people have been waiting for, for a long time, before we think about new directions? Some PRs appear to fix bugs opened *years* ago, and yet nothing is done about them. Some PRs are at an impasse due to decisions that need to be made, yet nobody is making said decisions or even discussing them, and the PRs just continue to rot there. There are already a *ton* of new features / fixes / language improvements that are waiting to be decided upon (and, given the size of the dmd PR queue, I submit this is no exaggeration), and yet we are indifferent and instead look away to new directions. Many of us are indeed ready to help, but it would *really* be nice if our help is received more readily, or, at the very least, *some* indication is shown that more effort will be put into reviewing said help before more energy is expended in new directions. The dramatic shortening of the Phobos PR queue over the last 2-3 months proves that this is not only possible, but also beneficial (more fixes are making it into Phobos than ever before) and improves morale (people are more likely to contribute if they don't have to wait 3 weeks before getting any feedback for their contribution) -- if we would only put our efforts into it. So here's to hoping that the other PR queues will shorten quickly in the near future. ;-) And mind you, the lengths of the PR queues are only the tip of the iceberg of stuff we ought to finish doing before embarking on the next new direction. There are a ton of old bugs that need attention, and a ton of language features that need improvement / refinement. We could at least pay those *some* heed even if we absolutely have to start something new right now at this moment. It would be a great tragedy if D goes down in history as the project that had so many great ideas, none of them carried out to completion. T
Being an outsider, I haven't wanted to jump into this discussion, but can't hold back after reading your post. The things you're talking about here are what was going through my mind a few days ago when Andrei said the only thing that has value is C++ compatibility. That doesn't make sense to me when you've just released a compiler with a bunch of regressions and there are all these other issues. I'm happy that someone is working on valuable new long-term projects, but I don't see how anyone could describe the things you've listed as being unworthy of attention.
Sep 24 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1573.1411584389.5783.digitalmars-d puremagic.com...

 I am, as you yourself point out later. But it's frustrating when pull
 requests sit in the queue for weeks (sometimes months, or, in the case
 of dmd pulls, *years*) without any indication of whether it's on the
 right track, and dismaying when your PR is just one of, oh, 100+ others
 that also all need attention, many of which are just languishing there
 for lack of attention even though there is nothing obviously blocking
 them, except perhaps the reviewers' / committers' time / interest.
This is a misleading description of the situation with dmd pull requests. There are lots of open pull requests, but the number has stayed fairly stable at ~100 for a long time. This means they are getting merged or closed at the same rate they are created. Some of them have certainly been forgotten by reviewers (sorry) but most of them need work, or implement controversial or questionable features. The situation is harder (IMO) than with phobos because changes usually touch multiple systems in the compiler, even if the diff only touches a single file. Things could always be better (can we clone Walter and Kenji yet?) but the thing holding back issue XYZ is almost always the people who care about XYZ haven't fixed it yet, and the people who are fixing things don't care about XYZ. This includes not only making patches, but convincing others it's something worth caring about. Everybody has a different set of priorities they want everybody else to share.
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 08:20:32AM +1000, Daniel Murphy via Digitalmars-d wrote:
 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.1573.1411584389.5783.digitalmars-d puremagic.com...
 
I am, as you yourself point out later. But it's frustrating when pull
requests sit in the queue for weeks (sometimes months, or, in the
case of dmd pulls, *years*) without any indication of whether it's on
the right track, and dismaying when your PR is just one of, oh, 100+
others that also all need attention, many of which are just
languishing there for lack of attention even though there is nothing
obviously blocking them, except perhaps the reviewers' / committers'
time / interest.
This is a misleading description of the situation with dmd pull requests. There are lots of open pull requests, but the number has stayed fairly stable at ~100 for a long time. This means they are getting merged or closed at the same rate they are created. Some of them have certainly been forgotten by reviewers (sorry) but most of them need work, or implement controversial or questionable features.
IMNSHO, any PR that haven't been touched in more than, say, 1-2 months, should just be outright closed. If/when the people involved have time to work on it again, it can be reopened. If a feature is questionable or controversial, shouldn't it be discussed on the forum and then a decision made? Ignoring controversial PRs isn't getting us anywhere. At the very least, if we can't decide, the PR should be closed (the submitter can just reopen it later once he manages to convince people that it's worthwhile -- that's what git branches are for). [...]
 Things could always be better (can we clone Walter and Kenji yet?)
Yeah, if we could clone Kenji, it would speed things up dramatically. :-)
 but the thing holding back issue XYZ is almost always the people who
 care about XYZ haven't fixed it yet, and the people who are fixing
 things don't care about XYZ.  This includes not only making patches,
 but convincing others it's something worth caring about.  Everybody
 has a different set of priorities they want everybody else to share.
I wish people would just make a decision about PRs, even if it's just to close it with "sorry this is not worth the time", than to silently ignore it and hope it would somehow go away on its own. T -- Always remember that you are unique. Just like everybody else. -- despair.com
Sep 24 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1605.1411597973.5783.digitalmars-d puremagic.com...

 IMNSHO, any PR that haven't been touched in more than, say, 1-2 months,
 should just be outright closed. If/when the people involved have time to
 work on it again, it can be reopened. If a feature is questionable or
 controversial, shouldn't it be discussed on the forum and then a
 decision made? Ignoring controversial PRs isn't getting us anywhere. At
 the very least, if we can't decide, the PR should be closed (the
 submitter can just reopen it later once he manages to convince people
 that it's worthwhile -- that's what git branches are for).
If they're abandoned. Closing pull requests because Walter hasn't made a decision yet would be a terrible policy. Many forum discussions produce only "i want this" responses and provide no useful review on the design or implementation.
 I wish people would just make a decision about PRs, even if it's just to
 close it with "sorry this is not worth the time", than to silently
 ignore it and hope it would somehow go away on its own.
I'd want that too, if those were the only two options.
Sep 24 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 11:44 AM, H. S. Teoh via Digitalmars-d wrote:
 No, I just named it as a representative case of many such wrinkles
 within existing language features. The fact of the matter is, wherever
 you turn, there's always something else that hasn't been fully ironed
 out yet. Features that interact with each other in unexpected ways.
 Corner cases that weren't considered / are hard to fix due to the nature
 of the features involved. Fixes that require a decision -- which are
 often neglected because there are too many other things being worked on.
I don't know of any language that is "fully ironed out". There's no such thing. I can give you a list of such things with C. Furthermore, if your car is missing wheels, spending all your time getting the paint job perfect isn't getting the car into usable condition. Corner cases are, by definition, in the corners, not the center of the road. Corner cases need to be addressed, but they are not in the way of getting s**t done, and getting s**t is the primary purpose of a programming language. I know I tend to focus on issues that block people from getting useful work done. Those aren't the corner cases. For example, the local import thing that suddenly became critical - it is not critical. (We still need to address it.) If it is causing you problems, you can: 1. not use local imports, put them in the global scope 2. stick with short local names - if a module is exporting a symbol named 'i', whoever wrote that module needs to receive a strongly worded letter (!). It's still good that the import issue is brought up, and we need to make it work better. But it is not critical, and does not prevent people from getting work done. The C++ interop, on the other hand, DOES block people from getting work done.
 Sometimes I wish there were less features in D, but far more refined.
 I'd rather go without the myriad of awesome features in D if I can only
 have a small set of features that have been fully worked out such that
 there are no nasty corner cases, deep-seated compiler bugs, or
 surprising gotchas that lurk around the corner as soon as you start
 writing non-trivial code.
A language that doesn't do much of anything is fairly easy to get right - and the very first thing users will do is propose extensions. May I say that "awesome features" are proposed here EVERY SINGLE DAY, they label the features as absolutely critical, usually by the people who argue the next day that D overreaches, or sometimes even in the same post.
 I am, as you yourself point out later. But it's frustrating when pull
 requests sit in the queue for weeks (sometimes months, or, in the case
 of dmd pulls, *years*) without any indication of whether it's on the
 right track, and dismaying when your PR is just one of, oh, 100+ others
 that also all need attention, many of which are just languishing there
 for lack of attention even though there is nothing obviously blocking
 them, except perhaps the reviewers' / committers' time / interest.
For some perspective, there are currently 98 open PRs for dmd, and more importantly, 3,925 closed ones. There are 39 resolved ones for every unresolved one. Furthermore, many of my own PRs have sat there for years. std.halffloat, anyone? I find it frustrating, too.
 We could at least pay those *some* heed
We are not sitting around doing nothing.
Sep 24 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 21:59:53 -0700
Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I understand quite thoroughly why c++ support is a big win
i believe it's not. so-called "enterprise" will not choose D for many reasons, and "c++ interop" is on the bottom of the list. seasoned c++ developer will not migrate to D for many reasons (or he already did that, but then he is not c++ developer anymore), and "c++ interop" is not on the top of the list, not even near the top. all that gory efforts aimed to "c++ interop" will bring three and a half more users. there will be NO massive migration due to "better c++ interop". yet this feature is on the top of the list now. i'm sad. seems that i (we?) have no choice except to wait until people will get enough of c++ games and will became focused on D again. porting and merging CDGC is much better target which help people already using D, but... but imaginary "future adopters" seems to be the highest priority. too bad that they will never arrive.
Sep 23 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 23 Sep 2014 21:59:53 -0700
 Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 I understand quite thoroughly why c++ support is a big win
i believe it's not. so-called "enterprise" will not choose D for many reasons, and "c++ interop" is on the bottom of the list. seasoned c++ developer will not migrate to D for many reasons (or he already did that, but then he is not c++ developer anymore), and "c++ interop" is not on the top of the list, not even near the top. all that gory efforts aimed to "c++ interop" will bring three and a half more users. there will be NO massive migration due to "better c++ interop". yet this feature is on the top of the list now. i'm sad. seems that i (we?) have no choice except to wait until people will get enough of c++ games and will became focused on D again. porting and merging CDGC is much better target which help people already using D, but... but imaginary "future adopters" seems to be the highest priority. too bad that they will never arrive.
Why does anyone have to *wait* for anything? I'm not seeing the blocking issues regarding attempts to fix the language. People are making PRs, people are discussing and testing ideas, and there appear to be enough people to tackle several problems at once (typedefs, C++ interop, GC/RC issues, weirdness with ref and auto, import symbol shadowing, etc.) Maybe things aren't moving as swiftly as we would like in the areas which are most impactful *to us* but that is the nature of free software. Has it ever been any other way than that the things which get the most attention are the things which the individual contributors are the most passionate about (whether their passion is justified or not?)
Sep 23 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 06:07:54 +0000
Cliff via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Why does anyone have to *wait* for anything?
'cause compiler and libs are complex beasts. there are people that have the necessary knowledge and they can write things faster (and better). i'm sure that if Walter or Andrei made official claim "we want CDGC in DMD as official GC", that people will start some serious hacking. there is alot more motivation to hack on something if people know that their work is much wanted in mainline DMD. CDGC is not worse that current GC for windows and MUCH better for *nix. it's a clear and instant win. c++ interop is... well, questionable. note that "GC is top priority" is not the same as "poring CDGC is top priority". the first is "ok, let's think about it" and the second is "ok, we know what to do".
Sep 24 2014
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 seasoned c++ developer will not migrate to D for many reasons 
 (or he
 already did that, but then he is not c++ developer anymore), 
 and "c++
 interop" is not on the top of the list, not even near the top.
This isn't true. I'm a C++ developer who migrated to D. I'm still (also) a C++ developer. And a D developer. And a Python developer. And... If I had C++ interop _today_ I'd convert some of our unit testing utils for Google Test that we use at work to D. Today. Atila
Sep 24 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 07:56:58 +0000
Atila Neves via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This isn't true. I'm a C++ developer who migrated to D. I'm still=20
 (also) a C++ developer. And a D developer. And a Python=20
 developer. And...
so you aren't migrated. using D for some throwaway utils and so on is not "migrating". "migrating" is "most of codebase in D".
Sep 24 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 24 September 2014 at 08:04:18 UTC, ketmar via 
Digitalmars-d wrote:
 On Wed, 24 Sep 2014 07:56:58 +0000
 Atila Neves via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 This isn't true. I'm a C++ developer who migrated to D. I'm 
 still (also) a C++ developer. And a D developer. And a Python 
 developer. And...
so you aren't migrated. using D for some throwaway utils and so on is not "migrating". "migrating" is "most of codebase in D".
Most of us cannot afford to be a "Technology X" developer. Every project, every client is a complete new world. -- Paulo
Sep 24 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 09:15:27 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Most of us cannot afford to be a "Technology X" developer.
 Every project, every client is a complete new world.
yeah. and so there is *no* *reason* to stress c++ interop, heh. 'cause "client dictates language" anyway. i like it.
Sep 24 2014
parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 24 September 2014 at 09:57:06 UTC, ketmar via 
Digitalmars-d wrote:
 On Wed, 24 Sep 2014 09:15:27 +0000
 Paulo  Pinto via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Most of us cannot afford to be a "Technology X" developer.
 Every project, every client is a complete new world.
yeah. and so there is *no* *reason* to stress c++ interop, heh. 'cause "client dictates language" anyway. i like it.
I do understand your concerns and I once mentioned in a thread that companies who use D should not dictate the way D evolves, instead it should remain community driven. Say for example D were used on web servers and a huge amount of effort was directed towards turning D into a web server language, while other important features/improvements were neglected, that'd be bad. However, in the case of C++ I must say that it is important. One of the reasons I opted for D was (and still is) its seamless C-integration. It allowed me to use so much existing code in C, libraries I would and could never have rewritten myself in D. There are loads of C(++) libraries out there you might want to or have to use for a particular project. When I started using D the Unicode module lacked certain features I needed. I just used an existing C library and could go on with the real program in D. Hadn't this been possible, the project in D would have died right then and there. Now D itself has the features I needed back then, but the C library was essential to bridge the gap. I think a lot of C++ programmers would do the same. Start a new project in D resting assured they can still use their carefully built code bases in C++. So I think interop with C++ is important. And don't forget that the reality is that most people interested in (yet reluctant about) D are C++ programmers, at least that's the impression I get here.
Sep 24 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via
Digitalmars-d wrote:
 On Tue, 23 Sep 2014 21:59:53 -0700
 Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 I understand quite thoroughly why c++ support is a big win
i believe it's not. so-called "enterprise" will not choose D for many reasons, and "c++ interop" is on the bottom of the list. seasoned c++ developer will not migrate to D for many reasons (or he already did that, but then he is not c++ developer anymore), and "c++ interop" is not on the top of the list, not even near the top. all that gory efforts aimed to "c++ interop" will bring three and a half more users. there will be NO massive migration due to "better c++ interop". yet this feature is on the top of the list now. i'm sad. seems that i (we?) have no choice except to wait until people will get enough of c++ games and will became focused on D again. porting and merging CDGC is much better target which help people already using D, but... but imaginary "future adopters" seems to be the highest priority. too bad that they will never arrive.
With the current move of having of more support for native code as part of the standard toolchains for Java (SubstrateVM, Sumatra, Valhalla, Panama) and .NET compilers (MDIL, .NET Native, RyuJIT all using the Visual C++ backend). The beloved enterprise has lots of reasons to stay with the current tooling when seeking performance. -- Paulo
Sep 24 2014
prev sibling parent reply "ponce" <contact gamesfrommars.fr> writes:
On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 23 Sep 2014 21:59:53 -0700
 Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 I understand quite thoroughly why c++ support is a big win
i believe it's not.
Every C++ shop I've been has one or several C++ codebase that just can't just be rewritten while the customers patiently wait. To thrive in the enterprise D must wait for a greenfield project with zero pre-existing source files (ie. rare), be a small project, or be able to interact with the legacy codebase. I think Andrei accurately identified C++ interop as the top-goal.
Sep 24 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 09:28:25 +0000
ponce via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 To thrive in the enterprise D must wait for a greenfield project=20
 with zero pre-existing source files (ie. rare), be a small=20
 project, or be able to interact with the legacy codebase.
=20
 I think Andrei accurately identified C++ interop as the top-goal.
no sane management (and insane too, even more) will resist to adding new language to codebase without really strong arguments. especially not hyped language. managers knows about java, they heard about c++ and they don't care what that "D" is. no c++ interop can change this. so: c++ interop will help D adoption in enterprise =3D=3D false. this thing alone moves c++ interop to the bottom of the list.
Sep 24 2014
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 24 September 2014 at 10:02:20 UTC, ketmar via 
Digitalmars-d wrote:
 On Wed, 24 Sep 2014 09:28:25 +0000
 no sane management (and insane too, even more) will resist to 
 adding
 new language to codebase without really strong arguments.
This is starting to be a little offensive... --- /Paolo
Sep 24 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 13:16:23 +0000
Paolo Invernizzi via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This is starting to be a little offensive...
sorry, i don't meant to. excuse me if i'm getting rude and iffensive.
Sep 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 2:14 PM, ketmar via Digitalmars-d wrote:
 On Wed, 24 Sep 2014 13:16:23 +0000
 Paolo Invernizzi via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This is starting to be a little offensive...
sorry, i don't meant to. excuse me if i'm getting rude and iffensive.
Much appreciated. -- Andrei
Sep 24 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/23/14, 9:46 PM, Sean Kelly wrote:
 So in that respect I understand the push for C++ support because that's
 the speed bump that Andrei has hit.  But here's the thing... by pursuing
 this we're effectively focusing all of our efforts *on another
 language*.  And we're doing so when D itself still needs a lot of work.
 Maybe not in any truly immense ways, but as I said before, those tiny
 things can seem huge when you're already struggling to justify just
 using the language at all. Maybe all this will pull together into a
 cohesive whole, but so far it feels kind of disconnected.  So that's
 part of what I meant by "tightening up."
You need a spoon of rennet to turn a bucket of milk into a bucket of yogurt. No matter how much milk you add, that won't help. You want to add milk. I know we must add rennet. -- Andrei
Sep 23 2014
prev sibling parent "Thomas Mader" <thomas.mader gmail.com> writes:
On Wednesday, 24 September 2014 at 04:46:01 UTC, Sean Kelly wrote:
 Yes, the inference is very nice.  And I do see the use for each 
 attribute.  It's just... when I look at a function and there's 
 a line of attributes before the function declaration that have 
 nothing to do with what the function actually does but rather 
 with how it's implemented, it's just syntactic noise.  It's 
 information for the compiler, not me as a user.  I hope we'll 
 eventually get to the point where everything is inferred and 
 the attributes disappear entirely.
What is the problem with complete automatic inference? Wouldn't it be possible to deduce the flags in the bottom up direction of a function call hierarchy? I guess it is possible for the compiler to see the right choice of flags for a function, which doesn't call other functions. E.g. make it safe if possible, nogc if possible and so on. Then it should process function after function until all functions are done. Thomas
Sep 23 2014
prev sibling parent reply "eles" <eles215 gzk.dot> writes:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:

 lack of attention paid to tightening up what we've already got 
 and deprecating old stuff that no one wants any more.  And 
 inconsistency in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
Sep 25 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
BTW, am I the only one whose eyes/ears are suffering when reading this: std.algrithm "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. " Why not, for God's sake, stripFront and stripBack? In std.string too. What about the R2L languages?
Sep 25 2014
next sibling parent "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 21:10:51 UTC, eles wrote:
 On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
 wrote:
BTW, am I the only one whose eyes/ears are suffering when reading this: std.algrithm "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. " Why not, for God's sake, stripFront and stripBack? In std.string too. What about the R2L languages?
OTOH, there is bringToFront() Really...
Sep 25 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
eles:

 "he stripLeft function will strip the front of the range, the 
 stripRight function will strip the back of the range, while the 
 strip function will strip both the front and back of the range. 
 "

 Why not, for God's sake, stripFront and stripBack?
Perhaps those names come from extending the names of "lstrip" and "rsplit" of Python string functions. Bye, bearophile
Sep 25 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 21:22:38 UTC, bearophile wrote:
 eles:

 "he stripLeft function will strip the front of the range, the 
 stripRight function will strip the back of the range, while 
 the strip function will strip both the front and back of the 
 range. "

 Why not, for God's sake, stripFront and stripBack?
Perhaps those names come from extending the names of "lstrip" and "rsplit" of Python string functions. Bye, bearophile
I find it too inconsitent. I doubt even Python programmers migrating to D love that... And, just: std.uni->std.unicode And I cannot believe that the language-defined complex types are still there (since the D1 days...). Either in the library, either in the language, but, please, pick *one* kind.
Sep 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 21:37:17 +0000
eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I find it too inconsitent. I doubt even Python programmers=20
 migrating to D love that...
=20
 And, just: std.uni->std.unicode
=20
 And I cannot believe that the language-defined complex types are=20
 still there (since the D1 days...). Either in the library, either=20
 in the language, but, please, pick *one* kind.
it's too late to change it. at least that's what i've been told. imaginary future users will be scared.
Sep 25 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 2:10 PM, eles wrote:
 On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
BTW, am I the only one whose eyes/ears are suffering when reading this: std.algrithm "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. " Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
Sep 25 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 2:10 PM, eles wrote:
 Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
Psh, they should be called stripHead and stripFoot. Or alternately, unHat and unShoe.
Sep 25 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly wrote:
 On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
 Alexandrescu wrote:
 On 9/25/14, 2:10 PM, eles wrote:
 Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
Psh, they should be called stripHead and stripFoot. Or alternately, unHat and unShoe.
stripLady and stripGentleman?...
Sep 25 2014
parent "Cliff" <cliff.s.hudson gmail.com> writes:
On Thursday, 25 September 2014 at 23:04:55 UTC, eles wrote:
 On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly 
 wrote:
 On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
 Alexandrescu wrote:
 On 9/25/14, 2:10 PM, eles wrote:
 Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
Psh, they should be called stripHead and stripFoot. Or alternately, unHat and unShoe.
stripLady and stripGentleman?...
Ah, now this thread is going to interesting places! :P
Sep 25 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 10:56:55PM +0000, Sean Kelly via Digitalmars-d wrote:
 On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
On 9/25/14, 2:10 PM, eles wrote:
Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
Psh, they should be called stripHead and stripFoot. Or alternately, unHat and unShoe.
Nah, they should be behead() and amputate(). T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
Sep 25 2014
parent "Mike James" <foo bar.com> writes:
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote in 
message news:mailman.1690.1411686833.5783.digitalmars-d puremagic.com...
 On Thu, Sep 25, 2014 at 10:56:55PM +0000, Sean Kelly via Digitalmars-d 
 wrote:
..
 Nah, they should be behead() and amputate().
Then the language would have to be called jihaDi...
Sep 26 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 16:11:57 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 Nah, they should be behead() and amputate().
i like it! this makes language much more expressive.
Sep 25 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 2:10 PM, eles wrote:
 On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
 wrote:
BTW, am I the only one whose eyes/ears are suffering when reading this: std.algrithm "he stripLeft function will strip the front of the range, the stripRight function will strip the back of the range, while the strip function will strip both the front and back of the range. " Why not, for God's sake, stripFront and stripBack?
Because they are called stripLeft and stripRight. -- Andrei
One day you will need to call this guy here: http://dconf.org/2014/talks/meyers.html He will say: "I told you so. At DConf."
Sep 25 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 2:03 PM, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:

 lack of attention paid to tightening up what we've already got and
 deprecating old stuff that no one wants any more.  And inconsistency
 in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
Sep 25 2014
next sibling parent "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 2:03 PM, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
 wrote:

 lack of attention paid to tightening up what we've already 
 got and
 deprecating old stuff that no one wants any more.  And 
 inconsistency
 in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
Those *all* languages, at least some of them, have good excuses (C++'s roots in C and the great advantage that is able to compile C code too, to some extent - history is on his side) and powerful driving factors (the whole might of Oracle and Microsoft). And, most of all, they already have a fair share of the market. And they served a lot of users quite well and those users aren't ready to drop them quite easily for what happens to be the cool kid of the day in the programming language world. D has to provide quality in order to compensate for the( lack of the)se factors.
Sep 25 2014
prev sibling next sibling parent "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 2:03 PM, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
 wrote:

 lack of attention paid to tightening up what we've already 
 got and
 deprecating old stuff that no one wants any more.  And 
 inconsistency
 in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
BTW, I already have somebody who's sharing my feelings, not looking further.
Sep 25 2014
prev sibling next sibling parent "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 2:03 PM, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
 wrote:

 lack of attention paid to tightening up what we've already 
 got and
 deprecating old stuff that no one wants any more.  And 
 inconsistency
 in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
The serious question is at what cost does this un-sharing come. The cost of the always-niche (aka "nice try") language?
Sep 25 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/25/14, 2:03 PM, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:

lack of attention paid to tightening up what we've already got and
deprecating old stuff that no one wants any more.  And inconsistency
in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
I've been thinking that it might do us some good if we aren't as paranoid about breaking old code, as long as (1) it's to fix a language design flaw, (2) it exposes potentially (or outright) buggy user code, (3) users are warned well ahead of time, followed by a full deprecation cycle, and (4) optionally, there's a tool, either fully or partially automated, that can upgrade old codebases. I mean, enterprises use deprecation cycles with their products all the time, and we don't hear of customers quitting just because of that. Some of the more vocal customers will voice their unhappiness, but as long as you're willing to work with them and allow them sufficient time to migrate over nicely and phase out the old stuff, they're generally accepting of the process. We've already had offers from D-based organizations asking to please break their code(!) for the sake of fixing language design flaws -- this is already far more than what most enterprise customers are generally willing to put up with, IME. Yet we're doing far less than what enterprises do in order to keep their product up-to-date. We may need to use very long deprecation cycles to keep everyone happy (on the order of 2-3 years perhaps), but doing nothing will only result in absolutely zero improvement even after 10 years. T -- Кто везде - тот нигде.
Sep 25 2014
parent Shammah Chancellor <email domain.com> writes:
On 2014-09-25 23:23:06 +0000, H. S. Teoh via Digitalmars-d said:

 On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via 
 Digitalmars-d wrote:
 On 9/25/14, 2:03 PM, eles wrote:
 On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
 
 lack of attention paid to tightening up what we've already got and
 deprecating old stuff that no one wants any more.  And inconsistency
 in how things work in the language.
The feeling that I have is that if D2 does not get a serious cleanup at this stage, then D3 must follow quickly (and such move will be unstoppable), otherwise people will fall back to D1 or C++next.
I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
I mean, enterprises use deprecation cycles with their products all the time, and we don't hear of customers quitting just because of that. Some of the more vocal customers will voice their unhappiness, but as long as you're willing to work with them and allow them sufficient time to migrate over nicely and phase out the old stuff, they're generally accepting of the process.
Unless you're Oracle -- in which case you end up with a horrible amalgamation of poorly thought out features. Features which work in such narrow cases that they're mostly useless. -S
Oct 04 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 15:48:11 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I'm not sharing that feeling at all. From that perspective all
 languages are in need of a "serious cleanup". -- Andrei
and they *are*. yet many languages can't be fixed due to huge amount of written code and user resistance. D is in winning position here: "most of D code yet to be written", yeah. and D users (even corporate users) are very welcome of breaking changes -- if they will make D more consistent and clean. the situation is... weird now. users: "it's ok, we WANT that breaking changes!" language developers: "no, you don't. it's too late."
Sep 25 2014
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/09/2014 12:39 a.m., Tofu Ninja wrote:
 GC by default is a big sore point that everyone brings up
I like having a GC by default. But we really need to think of it as a last resort sort of thing.
 "is" expressions are pretty wonky
Ehh yeah, D3 we could I spose.
 Libraries could definitely be split up better
We can still fix that in D2. Just as a note, we do want AST macros for D3. Which will be awesome! Stuff like linq from c# could be done as a library.
Sep 20 2014
parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 13:31:06 UTC, Rikki Cattermole 
wrote:
 Just as a note, we do want AST macros for D3. Which will be 
 awesome!
What kind of macros? Generic AST macros probably make source to source translation just as difficult as string mixins, don't they? Some simple term-rewriting is probably cleaner?
Sep 20 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/09/2014 1:46 a.m., Ola Fosheim Grostad wrote:
 On Saturday, 20 September 2014 at 13:31:06 UTC, Rikki Cattermole wrote:
 Just as a note, we do want AST macros for D3. Which will be awesome!
What kind of macros? Generic AST macros probably make source to source translation just as difficult as string mixins, don't they? Some simple term-rewriting is probably cleaner?
Maybe idk. I haven't investigated this sort of technology. I only know whats being planned for.
Sep 20 2014
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Oh another bad part of D is the attribute names with some being positive(pure) and some being negative( nogc) and some of them not having an on them.
Sep 20 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/20/14, 7:42 AM, Tofu Ninja wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Oh another bad part of D is the attribute names with some being positive(pure) and some being negative( nogc) and some of them not having an on them.
If that's among the worst, yay :o). My pet peeves about D gravitate around the lack of a clear approach to escape analysis and the sometimes confusing interaction of qualifiers with constructors. For escape analysis, I think the limited form present inside constructors (that enforces forwarded this() calls to execute exactly once) is plenty fine and should be applied in other places as well. For qualifiers, I think we need an overhaul of the interaction of qualifiers with copy construction. Andrei
Sep 20 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 20 September 2014 at 16:54:08 UTC, Andrei 
Alexandrescu wrote:
 On 9/20/14, 7:42 AM, Tofu Ninja wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
Oh another bad part of D is the attribute names with some being positive(pure) and some being negative( nogc) and some of them not having an on them.
If that's among the worst, yay :o). My pet peeves about D gravitate around the lack of a clear approach to escape analysis and the sometimes confusing interaction of qualifiers with constructors. For escape analysis, I think the limited form present inside constructors (that enforces forwarded this() calls to execute exactly once) is plenty fine and should be applied in other places as well.
I think correct escape analysis + safe + scope == win. BTW, remember all those people that bitch about rvalue to "const ref". D could be a language that provides rvalue to scope ref. 100% safe and practical. How awesome would that be?
Sep 20 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 20 Sep 2014 14:42:47 +0000
Tofu Ninja via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Oh another bad part of D is the attribute names with some being=20
 positive(pure) and some being negative( nogc) and some of them=20
 not having an   on them.
and no way to revert 'final' in classes, for example. or 'static'. i mean that i want something like this: class A { final: void foo () { ... } virtual: void bar () { ... } static: void heh () { ... } // and there is no way to declare non-static fields anymore... } yes, i know that i can use `final {}`, but it looking ugly. and i prefer to declare fields at the end of class declaration. annoying.
Sep 20 2014
prev sibling next sibling parent "K.K." <trampzy yahoo.com> writes:
I watched Jonathan's talk last night, it was really good. I
really like the idea that he wants to make a community designed,
platform independent, game specific language. It's too bad he
doesn't really want to give D more of chance but for what he's
looking for, it'd really need to be designed from the ground up,
as he was saying. Also being that he's slowly rejecting C++, then
I can see D not making sense since D's slogan is pretty much "A
better C++!"; which is accurate but may not be the best marketing
scheme. Also D is a general purpose language, so I guess it
really wouldn't fit his bill.
Though he mentioned Go and Rust a lot, personally I wouldn't
really back those languages either, at least not for games. Rust
maybe if it ever hits version 1.0 I'll take another look at it.
I'm definitely all for the setup he was describing though: all
you need is an IDE/text editor and the compiler. I feel like D
definitely has the potential to be able to meet that setup
someday; I'm just not sure if that setup would be a screw over or
not to people of other fields. The platform independent thing
would be a HUGE plus! Something D isn't too, too far from, but
definitely not there at least of yet.

Overall I'd say D has some significant issues:

- The documentation is awful. If there's a problem you don't know
the answer to, the only three real options are pray that the docs
are correct/up to date, go ask someone who possibly does know, or
magic.

- Bugs. D is like Costco, expect for bugs, and all the bugs are
free.

- More of a suggestion than a problem: Someone needs to do an
O'reilly book series for D; but only after the first two problems
I listed are at least suppressed a bit.

- Very few native D libraries, and also for C/other libraries
almost all D bindings are maintained by usually only one person.
Usually very skilled people, but the work load for library
development and maintenance would probably thrive best with more
people doing more. (The community is probably just too small at
the moment)


....I'm sure there was more, but it's just not coming to me at
the moment.
   I'm definitely interested in Jon's theoretical language but I
don't think it's gonna take away from D for me.

Overall though, I absolutely love D! There's just ALOT of work to
be done. :)
Sep 20 2014
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
This compiles. https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
Sep 20 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Sep 20, 2014 at 10:53:04PM +0000, Brian Schott via Digitalmars-d wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
This compiles. https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
+1, lolz. Oh wait, you forgot is(...) syntax (and their various inconsistent semantics)! Plz add. ;-) T -- IBM = I'll Buy Microsoft!
Sep 20 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 20 September 2014 at 23:01:40 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Oh wait, you forgot is(...) syntax (and their various 
 inconsistent semantics)! Plz add. ;-)
I used to hate is()... but then I spent the time to understand it to write about it in my book and now it doesn't bother me anymore. It is a bit weird looking, but there's a perfectly understandable pattern and logic to it; it makes sense once you get it. The two alias syntaxes don't but me either, the old one was fine, the new one is cool too. I'd be annoyed if the old one disappeared cuz of compatibility tho. That said, I want the C style array declaration to die die die, that's just evil. But the old style alias is ok.
 string results[](T) = "I have no idea what I'm doing";
I agree that's just weird though, someone pointed that out to me on IRC and I was even like wtf. I had thought I've seen it all until then.
Sep 20 2014
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe 
wrote:
 string results[](T) = "I have no idea what I'm doing";
I agree that's just weird though, someone pointed that out to me on IRC and I was even like wtf. I had thought I've seen it all until then.
I literally don't even know what to expect this to do.
Sep 20 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Tofu Ninja"  wrote in message news:nwjquvwnetifhydfabhg forum.dlang.org...

 On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe wrote:
 string results[](T) = "I have no idea what I'm doing";
I agree that's just weird though, someone pointed that out to me on IRC and I was even like wtf. I had thought I've seen it all until then.
I literally don't even know what to expect this to do.
template results(T) { string[] results = "I have no idea what I'm doing"; } Which won't instantiate because string doesn't convert to string[]. A fun mix of C-style array syntax, shortened template declaration syntax and a semantic error.
Sep 21 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/21/2014 09:05 AM, Daniel Murphy wrote:
 "Tofu Ninja"  wrote in message news:nwjquvwnetifhydfabhg forum.dlang.org...

 On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe wrote:
 string results[](T) = "I have no idea what I'm doing";
I agree that's just weird though, someone pointed that out to me on
IRC > and I was even like wtf. I had thought I've seen it all until then. I literally don't even know what to expect this to do.
template results(T) { string[] results = "I have no idea what I'm doing"; } Which won't instantiate because string doesn't convert to string[]. A fun mix of C-style array syntax, shortened template declaration syntax and a semantic error.
When was int x(T)=2; introduced? Also, C-style array syntax would actually be string results(T)[] = "";.
Sep 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Timon Gehr"  wrote in message news:lvmh5b$eo9$1 digitalmars.com... 

 When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think.
 Also, C-style array syntax would actually be string results(T)[] = "";.
Nah, array type suffix goes before the template argument list.
Sep 22 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/22/2014 03:26 PM, Daniel Murphy wrote:
 "Timon Gehr"  wrote in message news:lvmh5b$eo9$1 digitalmars.com...
 When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think. ...
Is this documented?
 Also, C-style array syntax would actually be string results(T)[] = "";.
Nah, array type suffix goes before the template argument list.
It is results!T[2], not results[2]!T.
Sep 22 2014
prev sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe 
wrote:
 I agree that's just weird though, someone pointed that out to 
 me on IRC and I was even like wtf. I had thought I've seen it 
 all until then.
The people who write books and autocompletion engines look at things the compiler accepts and say "WTF!?". I think that's the worst thing you can say about D.
Sep 20 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 20 September 2014 at 22:53:05 UTC, Brian Schott 
wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
This compiles. https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
I laughed extremely hard at this, wow. Yeah that definitely highlight A LOT of problems.
Sep 20 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2014 3:53 PM, Brian Schott wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
This compiles. https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
https://github.com/D-Programming-Language/dmd/pull/4021 produces: test.d(7): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax test.d(8): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax test.d(11): Warning: instead of C-style 'T id[exp]' syntax, use D-style 'T[exp] id' syntax test.d(15): Warning: instead of C-style 'T id[type]' syntax, use D-style 'T[type]' id syntax test.d(57): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax test.d(94): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax test.d(103): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax I.e. resolves 7 of them. :-)
Sep 23 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright 
wrote:
 https://github.com/D-Programming-Language/dmd/pull/4021
I'm pleasantly surprised that the decision has been made to fix that. I thought we'd be stuck with them forever.
Sep 23 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright 
wrote:
 https://github.com/D-Programming-Language/dmd/pull/4021
That can be a good case to start with dfix. Its first task can be rewrite of C-style declarations to D-style.
Sep 24 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 24 September 2014 at 11:20:24 UTC, Kagamin wrote:
 On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright 
 wrote:
 https://github.com/D-Programming-Language/dmd/pull/4021
That can be a good case to start with dfix. Its first task can be rewrite of C-style declarations to D-style.
+1
Sep 24 2014
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=--- I filed over half of those...
Sep 20 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=--- I filed over half of those...
I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice "hey, your PR broke this and that project" would surely be helpful to detect the breakages early on.
Sep 21 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 21, 2014 at 08:49:38AM +0000, via Digitalmars-d wrote:
 On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=--- I filed over half of those...
I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice "hey, your PR broke this and that project" would surely be helpful to detect the breakages early on.
This has been suggested before. The problem is resources. If you're willing to donate equipment for running these tests, it would be greatly appreciated, I believe. For my part, I regularly try compiling my own projects with git HEAD, and filing any regressions I find. T -- Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say "Gosh!" / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker
Sep 21 2014
next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
On Sunday, 21 September 2014 at 22:17:59 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Sun, Sep 21, 2014 at 08:49:38AM +0000, via Digitalmars-d 
 wrote:
 On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir 
 Panteleev wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
wrote:
What do you think are the worst parts of D?
The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=--- I filed over half of those...
I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice "hey, your PR broke this and that project" would surely be helpful to detect the breakages early on.
This has been suggested before. The problem is resources. If you're willing to donate equipment for running these tests, it would be greatly appreciated, I believe. For my part, I regularly try compiling my own projects with git HEAD, and filing any regressions I find. T
What is needed?
Sep 22 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2014 10:16 AM, luminousone wrote:
 What is needed?
The people who maintain large projects need to try them out with the beta compilers and file any regressions.
Sep 23 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright 
wrote:
 On 9/22/2014 10:16 AM, luminousone wrote:
 What is needed?
The people who maintain large projects need to try them out with the beta compilers and file any regressions.
Question: What's the point of testing betas if the release will occur even with known regressions? Blocking a pull being merged would be much more efficient than dealing with a pull merged long ago that by release time is difficult to revert.
Sep 23 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 9:12 PM, Vladimir Panteleev wrote:
 On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote:
 On 9/22/2014 10:16 AM, luminousone wrote:
 What is needed?
The people who maintain large projects need to try them out with the beta compilers and file any regressions.
Question: What's the point of testing betas if the release will occur even with known regressions?
Framing the question that way implies that all regressions are equally deleterious. But this isn't true at all - some regressions are disastrous, some are just minor nits. Delaying the release has its costs, too, as it may fix a number of serious problems. It's a balancing act. We shouldn't hamstring our ability to do what is best by conforming to arbitrary rules whether they are right or wrong for the circumstances.
 Blocking a pull being merged would be much more efficient
 than dealing with a pull merged long ago that by release time is difficult to
 revert.
Sure. I would block pulls that produce known regressions. The earlier regressions are known the better. But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program.
Sep 23 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 24/09/14 06:31, Walter Bright wrote:

 But it is a bit unreasonable to expect
 large project maintainers to rebuild and check for bugs every day. It's
 why we have a beta test program.
The solution is to make it automatic. -- /Jacob Carlborg
Sep 23 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
 On 24/09/14 06:31, Walter Bright wrote:

 But it is a bit unreasonable to expect
 large project maintainers to rebuild and check for bugs every day. It's
 why we have a beta test program.
The solution is to make it automatic.
There's no such thing as automatic testing of someone's moving target large project with another moving compiler target. Heck, the dmd release package build scripts break every single release cycle.
Sep 23 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
wrote:
 On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
 On 24/09/14 06:31, Walter Bright wrote:

 But it is a bit unreasonable to expect
 large project maintainers to rebuild and check for bugs every 
 day. It's
 why we have a beta test program.
The solution is to make it automatic.
There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.
It doesn't exist because no one has created it yet :)
 Heck, the dmd release package build scripts break every single 
 release cycle.
Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable.
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
 On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
 wrote:
 On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
 On 24/09/14 06:31, Walter Bright wrote:

 But it is a bit unreasonable to expect
 large project maintainers to rebuild and check for bugs every day. It's
 why we have a beta test program.
The solution is to make it automatic.
There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.
It doesn't exist because no one has created it yet :)
I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on.
 Heck, the dmd release package build scripts break every single release cycle.
Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable.
Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.)
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
wrote:
On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
On 24/09/14 06:31, Walter Bright wrote:

But it is a bit unreasonable to expect large project maintainers
to rebuild and check for bugs every day. It's why we have a beta
test program.
The solution is to make it automatic.
There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.
It doesn't exist because no one has created it yet :)
I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on.
Most (all?) of these issues are solved by using a modern build system. (No, make is not a modern build system.)
Heck, the dmd release package build scripts break every single
release cycle.
Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable.
Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.)
That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle. T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Sep 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d
wrote:
 On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
 On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
 wrote:
 On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
 On 24/09/14 06:31, Walter Bright wrote:

 But it is a bit unreasonable to expect large project maintainers
 to rebuild and check for bugs every day. It's why we have a beta
 test program.
The solution is to make it automatic.
There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.
It doesn't exist because no one has created it yet :)
I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on.
Most (all?) of these issues are solved by using a modern build system. (No, make is not a modern build system.)
 Heck, the dmd release package build scripts break every single
 release cycle.
Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable.
Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.)
That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle.
We of course agree on all these good things but it's all vacuous unless somebody champions it. Andrei
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 12:30:23PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
Building of the compiler/library itself is stable because the
autotester won't pass it if they won't build. That isn't the problem
- the problem is the package scripts fail. (This is why I want the
package building to be part of the autotester.)
That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle.
We of course agree on all these good things but it's all vacuous unless somebody champions it.
[...] Wasn't Nick Sabalausky working on an automated (or automatable) packaging script some time ago? Whatever happened with that? T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall
Sep 24 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 September 2014 at 19:38:44 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Wasn't Nick Sabalausky working on an automated (or automatable)
 packaging script some time ago? Whatever happened with that?
I think that's the one that keeps breaking. https://github.com/D-Programming-Language/installer/tree/master/create_dmd_release
Sep 24 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-24 12:16, Walter Bright wrote:

 I've never heard of a non-trivial project that didn't have constant
 breakage of its build system. All kinds of reasons - add a file, forget
 to add it to the manifest. Change the file contents, neglect to update
 dependencies. Add new dependencies on some script, script fails to run
 on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong. -- /Jacob Carlborg
Sep 24 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg
wrote:
 On 2014-09-24 12:16, Walter Bright wrote:

 I've never heard of a non-trivial project that didn't have 
 constant
 breakage of its build system. All kinds of reasons - add a 
 file, forget
 to add it to the manifest. Change the file contents, neglect 
 to update
 dependencies. Add new dependencies on some script, script 
 fails to run
 on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong.
People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems. Unfortunately, build engineering is effectively a specialty of its own when you step outside the most trivial of systems. It's really no surprise how few people can get it right - most people can't even agree on what a build system is supposed to do...
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 07:36:05PM +0000, Cliff via Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg
 wrote:
On 2014-09-24 12:16, Walter Bright wrote:

I've never heard of a non-trivial project that didn't have constant
breakage of its build system. All kinds of reasons - add a file,
forget to add it to the manifest. Change the file contents, neglect
to update dependencies. Add new dependencies on some script, script
fails to run on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong.
People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems.
That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think "make" whenever they hear "build system". Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.)
 Unfortunately, build engineering is effectively a specialty of its own
 when you step outside the most trivial of systems.  It's really no
 surprise how few people can get it right - most people can't even
 agree on what a build system is supposed to do...
It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T -- Political correctness: socially-sanctioned hypocrisy.
Sep 24 2014
next sibling parent "Cliff" <cliff.s.hudson gmail.com> writes:
On Wednesday, 24 September 2014 at 20:12:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 07:36:05PM +0000, Cliff via 
 Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg
 wrote:
On 2014-09-24 12:16, Walter Bright wrote:

I've never heard of a non-trivial project that didn't have 
constant
breakage of its build system. All kinds of reasons - add a 
file,
forget to add it to the manifest. Change the file contents, 
neglect
to update dependencies. Add new dependencies on some script, 
script
fails to run on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong.
People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems.
That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think "make" whenever they hear "build system". Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.)
 Unfortunately, build engineering is effectively a specialty of 
 its own
 when you step outside the most trivial of systems.  It's 
 really no
 surprise how few people can get it right - most people can't 
 even
 agree on what a build system is supposed to do...
It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T
Yes, Google in fact implemented must of this for their internal build systems, I am led to believe. I have myself written such a system before. In fact, the first project I have been working on in D is exactly this, using OS call interception for validating/discovering dependencies, building execution graphs, etc. I haven't seen TUP before, thanks for pointing it out.
Sep 24 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
 That's unfortunate indeed. I wish I could inspire them as to how cool a
 properly-done build system can be.
[snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has "won" over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei
Sep 24 2014
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 24 September 2014 at 21:12:15 UTC, Andrei 
Alexandrescu wrote:
 On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
 That's unfortunate indeed. I wish I could inspire them as to 
 how cool a
 properly-done build system can be.
[snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has "won" over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei
It depends on who you ask, I guess. I don't know what the definition of "has won" here is. make is certainly widespread, but so is C, Java and Javascript and I don't have much respect for those. I wouldn't use make again unless external forces made me. For one, it's slower than some of the alternatives, which admittedly only matters for larger builds (i.e. somebody's personal project on Github isn't ever going to see the difference, but a company project will). I'm saying this because I'm actively working on changing my company's existing build systems and did a migration from autotools to CMake in the past. I also looked at what was available for C/C++ recently and concluded it was better to go with the devil I know, namely CMake. From what I know, premake is pretty good (but I haven't used it) and tup looks good for arbritary rules (and large projects), but the ease of using CMake (despite its ridiculously bad scripting language) beats it. For me anyway. BTW, I totally agree with 2) above. Build systems are sort of simple but not really and frequently (always?) balloon out of proportion. As alluded to above, I've been that czar. If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. Make? I'd be just as likely to pick ant. Which I wouldn't. Atila P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. P.S.S autotools is the worse GNU project I know of
Sep 24 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 3:18 PM, Atila Neves wrote:
 On Wednesday, 24 September 2014 at 21:12:15 UTC, Andrei Alexandrescu wrote:
 On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
 That's unfortunate indeed. I wish I could inspire them as to how cool a
 properly-done build system can be.
[snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has "won" over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei
It depends on who you ask, I guess. I don't know what the definition of "has won" here is.
Simple: ask 10 random engineers "we need a build system". There's no dominant answer. Well except maybe for make :o). Case in point: we have two at Facebook, both created in house. But even that's beside the point. The plea here implies D devs are enamored with make and won't change their ways. Not at all! If there were a better thing with a strong champion, yay to that. But we can't be volunteered to use the build system that somebody else likes. Andrei
Sep 24 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d wrote:
[...]
 If I were to write a build system today that had to spell out all of
 its commands, I'd go with tup or Ninja. That CMake has support for
 Ninja is the icing on the cake for me. I wrote a Ninja build system
 generator the other day, that thing is awesome.
[...]
 P.S. I've thought of writing a build system in D, for which the
 configuration language would be D. I still might. Right now, dub is
 serving my needs.
I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. For this, I find that SCon's architecture of fully-customizable plugins may work best: ship the system with prebaked rules for common tasks like compiling C/C++/D/Java/etc programs, packaging into tarballs / zips, etc., and expose a consistent API for users to make their own rules where applicable. If the scripting language is D, that opens up a whole new realm of possibilities like using introspection to auto-derive build dependencies, which would be so cool it'd freeze the sun. Now throw in things like built-in parallelization ala SCons (I'm not sure if tup does that too, I suspect it does), 100%-reproducible builds, auto-packaging, etc., and we might have a contender for Andrei's "winner" build system.
 P.S.S autotools is the worse GNU project I know of
+100! It's a system of hacks built upon patches to broken systems built upon other hacks, a veritable metropolis of cards that will entirely collapse at the slightest missing toothpick in your shell environment / directory structure / stray object files or makefiles leftover from previous builds, thanks to 'make'. It's pretty marvelous for what it does -- autoconfigure complex system-dependent parameters for every existing flavor of Unix that you've never heard of -- when it works, that is. When it doesn't, you're in for days -- no, weeks -- no, months, of hair-pulling frustration trying to figure out where in the metropolis of cards the missing toothpick went. The error messages help -- in the same way stray hair or disturbed sand helps in a crime investigation -- if you know how to interpret them. Which ordinary people don't. T -- Philosophy: how to make a career out of daydreaming.
Sep 24 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via 
 Digitalmars-d wrote:
 [...]
 If I were to write a build system today that had to spell out 
 all of
 its commands, I'd go with tup or Ninja. That CMake has support 
 for
 Ninja is the icing on the cake for me. I wrote a Ninja build 
 system
 generator the other day, that thing is awesome.
[...]
 P.S. I've thought of writing a build system in D, for which the
 configuration language would be D. I still might. Right now, 
 dub is
 serving my needs.
I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. For this, I find that SCon's architecture of fully-customizable plugins may work best: ship the system with prebaked rules for common tasks like compiling C/C++/D/Java/etc programs, packaging into tarballs / zips, etc., and expose a consistent API for users to make their own rules where applicable. If the scripting language is D, that opens up a whole new realm of possibilities like using introspection to auto-derive build dependencies, which would be so cool it'd freeze the sun. Now throw in things like built-in parallelization ala SCons (I'm not sure if tup does that too, I suspect it does), 100%-reproducible builds, auto-packaging, etc., and we might have a contender for Andrei's "winner" build system.
 P.S.S autotools is the worse GNU project I know of
+100! It's a system of hacks built upon patches to broken systems built upon other hacks, a veritable metropolis of cards that will entirely collapse at the slightest missing toothpick in your shell environment / directory structure / stray object files or makefiles leftover from previous builds, thanks to 'make'. It's pretty marvelous for what it does -- autoconfigure complex system-dependent parameters for every existing flavor of Unix that you've never heard of -- when it works, that is. When it doesn't, you're in for days -- no, weeks -- no, months, of hair-pulling frustration trying to figure out where in the metropolis of cards the missing toothpick went. The error messages help -- in the same way stray hair or disturbed sand helps in a crime investigation -- if you know how to interpret them. Which ordinary people don't. T
If you have a passion and interest in this space and would like to collaborate, I would be thrilled. We can also split this discussion off of this thread since it is not D specific.
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
 Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via Digitalmars-d
wrote:
[...]
If I were to write a build system today that had to spell out all of
its commands, I'd go with tup or Ninja. That CMake has support for
Ninja is the icing on the cake for me. I wrote a Ninja build system
generator the other day, that thing is awesome.
[...]
P.S. I've thought of writing a build system in D, for which the
configuration language would be D. I still might. Right now, dub is
serving my needs.
I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.
[...]
 If you have a passion and interest in this space and would like to
 collaborate, I would be thrilled.  We can also split this discussion
 off of this thread since it is not D specific.
I'm interested. What about Atila? T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Sep 24 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via 
 Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
 Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via 
Digitalmars-d
wrote:
[...]
If I were to write a build system today that had to spell 
out all of
its commands, I'd go with tup or Ninja. That CMake has 
support for
Ninja is the icing on the cake for me. I wrote a Ninja build 
system
generator the other day, that thing is awesome.
[...]
P.S. I've thought of writing a build system in D, for which 
the
configuration language would be D. I still might. Right now, 
dub is
serving my needs.
I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.
[...]
 If you have a passion and interest in this space and would 
 like to
 collaborate, I would be thrilled.  We can also split this 
 discussion
 off of this thread since it is not D specific.
I'm interested. What about Atila? T
Yes, whoever has a passionate interest in this space and (of course) an interest in D. Probably the best thing to do is take this to another forum - I don't want to further pollute this thread. Please g-mail to: cliff s hudson. (I'm assuming you are a human and can figure out the appropriate dotted address from the preceding :) )
Sep 24 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 24 Sep 2014 23:56:24 +0000
schrieb "Cliff" <cliff.s.hudson gmail.com>:

 On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via 
 Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via 
 Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
 Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via 
Digitalmars-d
wrote:
[...]
If I were to write a build system today that had to spell 
out all of
its commands, I'd go with tup or Ninja. That CMake has 
support for
Ninja is the icing on the cake for me. I wrote a Ninja build 
system
generator the other day, that thing is awesome.
[...]
P.S. I've thought of writing a build system in D, for which 
the
configuration language would be D. I still might. Right now, 
dub is
serving my needs.
I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts.
[...]
 If you have a passion and interest in this space and would 
 like to
 collaborate, I would be thrilled.  We can also split this 
 discussion
 off of this thread since it is not D specific.
I'm interested. What about Atila? T
Yes, whoever has a passionate interest in this space and (of course) an interest in D. Probably the best thing to do is take this to another forum - I don't want to further pollute this thread. Please g-mail to: cliff s hudson. (I'm assuming you are a human and can figure out the appropriate dotted address from the preceding :) )
You do know that your email is in plain text in the news message header? :p -- Marco
Sep 26 2014
parent "Cliff" <cliff.s.hudson gmail.com> writes:
On Friday, 26 September 2014 at 07:56:57 UTC, Marco Leise wrote:
 Am Wed, 24 Sep 2014 23:56:24 +0000

 You do know that your email is in plain text in the news
 message header? :p
Actually I did not, as I am not presently using a newsreader to access the forums, just the web page. I keep forgetting to install a proper reader :) Thanks!
Sep 26 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 [...]
 If you have a passion and interest in this space and would 
 like to
 collaborate, I would be thrilled.  We can also split this 
 discussion
 off of this thread since it is not D specific.
I'm interested. What about Atila?
Definitely interested. BTW, I agree with everything you said about what would be desireable from a build system. Basically we had pretty much the same idea. :) Atila
Sep 25 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 September 2014 at 07:28:10 UTC, Atila Neves wrote:
 [...]
 If you have a passion and interest in this space and would 
 like to
 collaborate, I would be thrilled.  We can also split this 
 discussion
 off of this thread since it is not D specific.
I'm interested. What about Atila?
Definitely interested. BTW, I agree with everything you said about what would be desireable from a build system. Basically we had pretty much the same idea. :)
Glad to hear you guys are going to take a pass at this. :) You might want to check out ekam, a since-abandoned build tool that sounded similar, started by one of the guys behind Protocol Buffers: http://kentonsprojects.blogspot.in/search/label/ekam Maybe he had some ideas you'd want to steal.
Sep 25 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
 I've been thinking of that too! I have in mind a hybrid between tup and
 SCons, integrating the best ideas of both and discarding the bad parts.

 For example, SCons is notoriously bad at scalability: the need to scan
 huge directory structures of large projects when all you want is to
 rebuild a tiny subdirectory, is disappointing. This part should be
 replaced by Tup-style OS file change notifications.

 However, Tup requires arcane shell commands to get anything done --
 that's good if you're a Bash guru, but most people are not.
Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using "a properly-done" build system with these amazing qualities? To quote:
 I wish I could inspire them as to how cool a
 properly-done build system can be. Automatic parallel building, for
 example. Fully-reproducible, incremental builds (never ever do `make
 clean` again). Automatic build + packaging in a single command.
 Incrementally *updating* packaging in a single command. Automatic
 dependency discovery. And lots more. A lot of this technology actually
 already exists. The problem is that still too many people think "make"
 whenever they hear "build system".  Make is but a poor, antiquated
 caricature of what modern build systems can do. Worse is that most
 people are resistant to replacing make because of inertia. (Not
 realizing that by not throwing out make, they're subjecting themselves
 to a lifetime of unending, unnecessary suffering.)
So should we take it that actually that system does not exist but you want to create it? Andrei
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 04:16:20PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
I've been thinking of that too! I have in mind a hybrid between tup
and SCons, integrating the best ideas of both and discarding the bad
parts.

For example, SCons is notoriously bad at scalability: the need to
scan huge directory structures of large projects when all you want is
to rebuild a tiny subdirectory, is disappointing. This part should be
replaced by Tup-style OS file change notifications.

However, Tup requires arcane shell commands to get anything done --
that's good if you're a Bash guru, but most people are not.
Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using "a properly-done" build system with these amazing qualities? To quote:
I wish I could inspire them as to how cool a properly-done build
system can be. Automatic parallel building, for example.
Fully-reproducible, incremental builds (never ever do `make clean`
again). Automatic build + packaging in a single command.
Incrementally *updating* packaging in a single command. Automatic
dependency discovery. And lots more. A lot of this technology
actually already exists. The problem is that still too many people
think "make" whenever they hear "build system".  Make is but a poor,
antiquated caricature of what modern build systems can do. Worse is
that most people are resistant to replacing make because of inertia.
(Not realizing that by not throwing out make, they're subjecting
themselves to a lifetime of unending, unnecessary suffering.)
So should we take it that actually that system does not exist but you want to create it?
[...] You're misrepresenting my position. *In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Your argument reduces to declining to replace a decrepit car that breaks down every other day with a new one, just because the new car isn't a flawlessly perfect epitome of engineering yet and still needs a little maintenance every half a year. T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Sep 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
 You're misrepresenting my position.*In spite of their current flaws*,
 modern build systems like SCons and Tup already far exceed make in their
 basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
You're misrepresenting my position.*In spite of their current flaws*,
modern build systems like SCons and Tup already far exceed make in
their basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Well, Cliff & I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Sep 24 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
 You're misrepresenting my position.*In spite of their current flaws*,
 modern build systems like SCons and Tup already far exceed make in
 their basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Well, Cliff & I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects.
Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful. Andrei
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
You're misrepresenting my position.*In spite of their current
flaws*, modern build systems like SCons and Tup already far exceed
make in their basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Well, Cliff & I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects.
Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful.
[...] Clearly, the more automatic dependency management can be, the better. In an ideal world, one should be able to say, "here is my source tree, and here's the file that contains main()", and the build tool should automatically figure out all the dependencies as well as how to compile the sources into the final executable. In pseudocode, all one needs to write should in theory be simply: Program("mySuperApp", "src/main.d"); and everything else will be automatically figured out. But of course, this is currently not yet fully practical. So some amount of manual dependency specification will be needed. But the idea is to keep those minimal. T -- This is a tpyo.
Sep 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 9:15 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
 You're misrepresenting my position.*In spite of their current
 flaws*, modern build systems like SCons and Tup already far exceed
 make in their basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Well, Cliff & I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects.
Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful.
[...] Clearly, the more automatic dependency management can be, the better. In an ideal world, one should be able to say, "here is my source tree, and here's the file that contains main()", and the build tool should automatically figure out all the dependencies as well as how to compile the sources into the final executable. In pseudocode, all one needs to write should in theory be simply: Program("mySuperApp", "src/main.d"); and everything else will be automatically figured out. But of course, this is currently not yet fully practical. So some amount of manual dependency specification will be needed. But the idea is to keep those minimal.
Actually you can't do this for D properly without enlisting the help of the compiler. Scoped import is a very interesting conditional dependency (it is realized only if the template is instantiated). Also, lazy opening of imports is almost guaranteed to have a huge good impact on build times. Your reply confirms my worst fear: you're looking at yet another general build system, of which there are plenty of carcasses rotting in the drought left and right of highway 101. The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. Andrei
Sep 24 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 9:26 PM, Andrei Alexandrescu wrote:
 The build system that will be successful for D will cooperate with the
compiler,
 which will give it fine-grained dependency information. Haskell does the same
 with good results.
There's far more to a build system than generating executables. And there's more to generating executables than D source files (there may be C files in there, and C++ files, YACC files, and random other files). Heck, dmd uses C code to generated more .c source files. I've seen more than one fabulous build system that couldn't cope with that. Make is the C++ of build systems. It may be ugly, but you can get it to work.
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 09:44:26PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/24/2014 9:26 PM, Andrei Alexandrescu wrote:
The build system that will be successful for D will cooperate with
the compiler, which will give it fine-grained dependency information.
Haskell does the same with good results.
I didn't specify *how* the build system would implement automatic dependency now, did I? :-) Nowhere did I say that the build system will (re)invent its own way of deriving source file dependencies. FYI, Tup is able to tell exactly what file(s) are read by the compiler in compiling a particular program (or source file) automatically, thus its dependency graph is actually accurate, unlike some build systems that depend on source-level scanning, which would lead to the problems you describe with conditional local imports.
 There's far more to a build system than generating executables. And
 there's more to generating executables than D source files (there may
 be C files in there, and C++ files, YACC files, and random other
 files).
 
 Heck, dmd uses C code to generated more .c source files. I've seen
 more than one fabulous build system that couldn't cope with that.
Which build system would that be? I'll be sure to avoid it. :-P I've written SCons scripts that correctly handles automated handling of auto-generated source files. For example, a lex/flex source file gets compiled to a .c source file which in turn compiles to the object file that then gets linked with the executable. Heck, I have a working SCons script that handles the generation of animations from individual image frames which are in turn generated by invocations of povray on scene files programmatically generated by a program that reads script input and polytope definitions in a DSL and computes each scene file. The image generation includes scripted trimming and transparency adjustments of each individual frame, specified *in the build spec* via imagemagick, and the entire process from end to end is fully automatically parallelized by SCons, which is able to correctly sequence each step in a website project that has numerous such generation tasks, interleaving multiple generation procedures as CPUs become free without any breakage in dependencies. This process even optionally includes a final deployment step which copies the generated files into a web directory, and it is able to detect steps for which the products haven't changed from the last run and elide redundant copying of the unchanged files to the web directory, thus preserving last-updated timestamps on the target files. So before you bash modern build systems in favor of make, do take some time to educate yourself about what they're actually capable of. :-) You'll be a lot more convincing then.
 Make is the C++ of build systems. It may be ugly, but you can get it
 to work.
If you like building real airplanes out of Lego pieces, be my guest. Me, I prefer using more suitable tools. :-P T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
 If you like building real airplanes out of Lego pieces, be my guest. Me,
 I prefer using more suitable tools. :-P
I spend very little time fussing with make. Making it work better (even to 0 cost) will add pretty much nothing to my productivity.
Sep 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
If you like building real airplanes out of Lego pieces, be my guest.
Me, I prefer using more suitable tools. :-P
I spend very little time fussing with make. Making it work better (even to 0 cost) will add pretty much nothing to my productivity.
Oh? Let's see. One time, while git bisecting to track down a dmd regression, I was running into all sorts of strange inconsistent behaviour from dmd. After about a good 15-30 mins' worth of frustration, I tracked down the source of the problem to make not cleaning up previous .o files, and thus producing a corrupted dmd which contained a mixture of who knows what versions of each .o left behind from previous git bisect steps. So I realized that I had to do a make clean every time to ensure I'm actually getting the dmd I think I'm getting. Welp, that just invalidated my entire git bisect session so far. So git bisect reset and start over. Had dmd used a reliable build system, I wouldn't have wasted that time, plus I'd have the benefit of incremental builds instead of the extra time spent running make clean, and *then* rebuilding everything from scratch. Yup, it wouldn't *add* to my productivity, but it certainly *would* cut down on my *unproductivity*! Now, dmd's makefile is very much on the 'simple' end of the scale, which I'm sure you'll agree if you've seen the kind of makefiles I have to deal with at work. Being simple means it also doesn't expose many of make's myriad problems. I've had to endure through builds that take 30 minutes to complete for a 1-line code change (and apparently I'm already counted lucky -- I hear of projects whose builds could span hours or even *days* if you're unlucky enough to have to build on a low-end machine), only to find that the final image was corrupted because somewhere in that dense forest of poorly-hackneyed makefiles in the source tree somebody had forgotten to cleanup a stray .so file, which is introducing the wrong versions of the wrong symbols to the wrong places, causing executables to go haywire when deployed. Not to mention that some smart people in the team have decided that needing to 'make clean' every single time following an svn update is "normal" practice, thus every makefile in their subdirectory is completely broken, non-parallizable, and extremely fragile. Hooray for the countless afternoons I spent fixing D bugs instead of doing paid work -- because I've to do yet another `make clean; make` just to be sure any subsequent bugs I find are actual bugs, and not inconsistent builds caused by our beloved make. You guys should be thankful, as otherwise I would've been too productive to have time to fix D bugs. :-P And let's not forget the lovely caching of dependency files from gcc that our makefiles attempt to leverage in order to have more accurate dependency information -- information which is mostly worthless because you have to make clean; make after making major changes anyway -- one time I didn't due to time pressure, and was rewarded with another heisenbug caused by stale .dep files causing some source changes to not be reflected in the build. Oh yeah, spent another day or two trying to figure that one out. Oh, and did I mention the impossibility of parallelizing our builds because of certain aforementioned people who think `make clean; make` is "normal workflow"? I'd hazard to guess I could take a year off work from all the accumulated unproductive times waiting for countless serial builds to complete, where parallelized builds would've saved at least half that time, more on modern PCs. Reluctance to get rid of make is kinda like reluctance to use smart pointers / GC because you enjoy manipulating raw pointers in high-level application code. You can certainly do many things with raw pointers, and do it very efficiently 'cos you've already memorized the various arcane hacks needed to make things work over the years -- recite them in your sleep even. It's certainly more productive than spending downtime learning how to use smart pointers or, God forbid, the GC -- after you discount all the time and effort expended in tracking down null pointer segfaults, dangling pointer problems, memory corruption issues, missing sizeof's in malloc calls, and off-by-1 array bugs, that is. To each his own, I say. :-P T -- People tell me that I'm skeptical, but I don't believe them.
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 11:05 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d
wrote:
 On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
 If you like building real airplanes out of Lego pieces, be my guest.
 Me, I prefer using more suitable tools. :-P
I spend very little time fussing with make. Making it work better (even to 0 cost) will add pretty much nothing to my productivity.
Oh? Let's see. One time, while git bisecting to track down a dmd regression, I was running into all sorts of strange inconsistent behaviour from dmd. After about a good 15-30 mins' worth of frustration, I tracked down the source of the problem to make not cleaning up previous .o files, and thus producing a corrupted dmd which contained a mixture of who knows what versions of each .o left behind from previous git bisect steps. So I realized that I had to do a make clean every time to ensure I'm actually getting the dmd I think I'm getting. Welp, that just invalidated my entire git bisect session so far. So git bisect reset and start over. Had dmd used a reliable build system, I wouldn't have wasted that time, plus I'd have the benefit of incremental builds instead of the extra time spent running make clean, and *then* rebuilding everything from scratch. Yup, it wouldn't *add* to my productivity, but it certainly *would* cut down on my *unproductivity*! Now, dmd's makefile is very much on the 'simple' end of the scale, which I'm sure you'll agree if you've seen the kind of makefiles I have to deal with at work. Being simple means it also doesn't expose many of make's myriad problems. I've had to endure through builds that take 30 minutes to complete for a 1-line code change (and apparently I'm already counted lucky -- I hear of projects whose builds could span hours or even *days* if you're unlucky enough to have to build on a low-end machine), only to find that the final image was corrupted because somewhere in that dense forest of poorly-hackneyed makefiles in the source tree somebody had forgotten to cleanup a stray .so file, which is introducing the wrong versions of the wrong symbols to the wrong places, causing executables to go haywire when deployed. Not to mention that some smart people in the team have decided that needing to 'make clean' every single time following an svn update is "normal" practice, thus every makefile in their subdirectory is completely broken, non-parallizable, and extremely fragile. Hooray for the countless afternoons I spent fixing D bugs instead of doing paid work -- because I've to do yet another `make clean; make` just to be sure any subsequent bugs I find are actual bugs, and not inconsistent builds caused by our beloved make. You guys should be thankful, as otherwise I would've been too productive to have time to fix D bugs. :-P And let's not forget the lovely caching of dependency files from gcc that our makefiles attempt to leverage in order to have more accurate dependency information -- information which is mostly worthless because you have to make clean; make after making major changes anyway -- one time I didn't due to time pressure, and was rewarded with another heisenbug caused by stale .dep files causing some source changes to not be reflected in the build. Oh yeah, spent another day or two trying to figure that one out. Oh, and did I mention the impossibility of parallelizing our builds because of certain aforementioned people who think `make clean; make` is "normal workflow"? I'd hazard to guess I could take a year off work from all the accumulated unproductive times waiting for countless serial builds to complete, where parallelized builds would've saved at least half that time, more on modern PCs. Reluctance to get rid of make is kinda like reluctance to use smart pointers / GC because you enjoy manipulating raw pointers in high-level application code. You can certainly do many things with raw pointers, and do it very efficiently 'cos you've already memorized the various arcane hacks needed to make things work over the years -- recite them in your sleep even. It's certainly more productive than spending downtime learning how to use smart pointers or, God forbid, the GC -- after you discount all the time and effort expended in tracking down null pointer segfaults, dangling pointer problems, memory corruption issues, missing sizeof's in malloc calls, and off-by-1 array bugs, that is. To each his own, I say. :-P
You noted my preference for simple makefiles (even if they tend to get verbose). I've been using make for 30 years now, and rarely have problems with it. Of course, I also eschew using every last feature of make, which too many people feel compelled to do. So no, my makefiles don't consist of "arcane hacks". They're straightforward and rather boring. And I use make -j on posix for parallel builds, it works fine on dmd.
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 11:14:30PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 You noted my preference for simple makefiles (even if they tend to get
 verbose). I've been using make for 30 years now, and rarely have
 problems with it. Of course, I also eschew using every last feature of
 make, which too many people feel compelled to do. So no, my makefiles
 don't consist of "arcane hacks". They're straightforward and rather
 boring.
 
 And I use make -j on posix for parallel builds, it works fine on dmd.
Well, I *am* grateful that building dmd is as simple as identifying which makefile to use for your platform, and make away. And the fact that building dmd with -j works. Sadly, 95% of non-trivial make-based projects out there require all manner of arcane hacks that break across platforms, requiring patch upon patches (*ahem*autotools*cough*) ostensibly to work, but in practice ends up breaking anyway and you're left with a huge mess to debug. And -j generally doesn't work. :-/ (It either crashes with obscure non-reproducible compile errors caused by race conditions, or gives you a binary that may or may not represent the source code. Sigh.) In fact, one thing that impressed me immensely is the fact that building the dmd toolchain is as simple as it is. I know of no other compiler project that is comparable. Building gcc, for example, is a wondrous thing to behold -- when it works. When it doesn't (which is anytime you dare do the slightest thing not according to the meticulous build instructions)... it's nightmarish. But even then, I *did* run into the problem of non-reproducible builds with dmd. So there's still a blemish there. :-P Makes me want to alias `make` to `make clean; make` just for this alone... Oh wait, I've already done that -- I have a script for pulling git HEAD from github and rebuilding dmd, druntime, phobos, and it *does* run make clean before rebuilding everything! Sigh. The only redeeming thing is that dmd/druntime/phobos builds at lightning speed (relative to, say, the gcc toolchain), so this isn't *too* intolerable a cost. But still. It's one of my pet peeves about make... T -- Many open minds should be closed for repairs. -- K5 user
Sep 24 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:

 In fact, one thing that impressed me immensely is the fact that building
 the dmd toolchain is as simple as it is. I know of no other compiler
 project that is comparable. Building gcc, for example, is a wondrous
 thing to behold -- when it works. When it doesn't (which is anytime you
 dare do the slightest thing not according to the meticulous build
 instructions)... it's nightmarish.
Yeah, I agree. It's a nice property of DMD.
 But even then, I *did* run into the problem of non-reproducible builds
 with dmd. So there's still a blemish there. :-P  Makes me want to alias
 `make` to `make clean; make` just for this alone
I don't think the "clean" action can be completely excluded. I recently tried to build a project, without running "clean", and got some unexpected errors. Then I remembered I had just installed a new version of the compiler. -- /Jacob Carlborg
Sep 25 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
[...]
But even then, I *did* run into the problem of non-reproducible
builds with dmd. So there's still a blemish there. :-P  Makes me want
to alias `make` to `make clean; make` just for this alone
I don't think the "clean" action can be completely excluded. I recently tried to build a project, without running "clean", and got some unexpected errors. Then I remembered I had just installed a new version of the compiler.
[...] That's the hallmark of make-based projects. SCons projects, OTOH, almost never needs to do that (except if you totally screwed up your SCons scripts). The super-complicated SCons script that I described in another post? I don't even remember that last *year* when I had to do the equivalent of a clean. I've been updating, branching, merging the workspace for years now, and it Just Builds -- correctly at that. T -- Famous last words: I *think* this will work...
Sep 25 2014
next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 25 September 2014 at 14:25:25 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via 
 Digitalmars-d wrote:
 On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
[...]
But even then, I *did* run into the problem of 
non-reproducible
builds with dmd. So there's still a blemish there. :-P  Makes 
me want
to alias `make` to `make clean; make` just for this alone
I don't think the "clean" action can be completely excluded. I recently tried to build a project, without running "clean", and got some unexpected errors. Then I remembered I had just installed a new version of the compiler.
[...] That's the hallmark of make-based projects. SCons projects, OTOH, almost never needs to do that (except if you totally screwed up your SCons scripts). The super-complicated SCons script that I described in another post? I don't even remember that last *year* when I had to do the equivalent of a clean. I've been updating, branching, merging the workspace for years now, and it Just Builds -- correctly at that.
+1. I remember the days where I dealt with hand-written makefiles and running "make clean" just to be sure. I don't miss them. If you ever _need_ to type "make clean" then the build system is broken. Simple as. It's analogous to deleting the object file to make sure the compiler does its job properly. Atila
Sep 25 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:

 That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've updated the compiler? -- /Jacob Carlborg
Sep 25 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
wrote:
 On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:

 That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've updated the compiler?
The compiler is an input to the build rule. Consider the rule: build: $(CC) my.c -o my.o what are the dependencies for the rule "build"? my.c obviously. Anything the compiler accesses during the compilation of my.c. And *the compiler itself*, referenced here as $(CC). From a dependency management standpoint, executables are not special except as running them leads to the discovery of more dependencies than may be statically specified.
Sep 25 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 10:47 AM, Cliff wrote:
 On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
 wrote:
 On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:

 That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've updated the compiler?
The compiler is an input to the build rule. Consider the rule: build: $(CC) my.c -o my.o what are the dependencies for the rule "build"? my.c obviously. Anything the compiler accesses during the compilation of my.c. And *the compiler itself*, referenced here as $(CC). From a dependency management standpoint, executables are not special except as running them leads to the discovery of more dependencies than may be statically specified.
Yah, it only gets odder from there. E.g. all stuff being build must also list the rule file itself as a dependency. FWIW I've seen implications that a better build tool would improve the lot of dlang contributors. My response to that would be: I agree that Phobos' posix.mak (https://github.com/D-Programming-Language/phobos/blob/master/posix.mak) is a tad baroque and uses a couple of the more obscure features of make. I also consider a few changes to it could have been effected simpler and better. However, as far as I can tell it's not a large issue for dlang contributors, and to the extent it is, it's not because of make's faults. Andrei
Sep 25 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 07:42:08PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
 
That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've updated the compiler?
[...] The compiler and compile flags are inputs to the build rules in SCons. In my SCons projects, when I change compile flags (possibly for a subset of source files), it correctly figures out which subset (or the entire set) of files needs to be recompiled with the new flags. Make fails, and you end up with an inconsistent executable. In my SCons projects, when I upgrade the compiler, it recompiles everything with the new compiler. Make doesn't detect a difference, and if you make a change and recompile, suddenly you got an executable 80% compiled with the old compiler and 20% compiled with the new compiler. Most of the time it doesn't make a difference... but when it does, have fun figuring out where the problem lies. (Or just make clean; make yet again... the equivalent of which is basically what SCons would have done 5 hours ago.) In my SCons projects, when I upgrade the system C libraries, it recompiles everything that depends on the updated header files *and* library files. In make, it often fails to detect that the .so's have changed, so it fails to relink your program. Result: your executable behaves strangely at runtime due to wrong .so being linked, but the problem vanishes once you do a make clean; make. Basically, when you use make, you have to constantly do make clean; make just to be sure everything is consistent. In SCons, the build system does it for you -- and usually more efficiently than make clean; make because it knows exactly what needs recompilation and what doesn't. In my SCons projects, when I checkout a different version of the sources to examine some old code and then switch back to the latest workspace, SCons detects that file contents haven't changed since the last build, so it doesn't rebuild anything. In make, it thinks the entire workspace has changed, and you have to wait another half hour while it rebuilds everything. It doesn't even detect that all intermediate products like .o's are identical to the last time, so it will painstakingly relink everything again. SCons will detect when a .o file hasn't changed from the last build (e.g., you only changed a comment in the source file), and it won't bother relinking your binaries or trigger any of the downstream dependencies' rebuilds. Make-heads find the idea of the compiler being part of the input to a build rule "strange"; to me, it's common sense. What's strange is the fact that make doesn't (and can't) guarantee anything about the build -- you don't know for sure whether an incremental build gives you the same executable as a build from a clean workspace. You don't know if recompiling after checking out a previous release of your code will actually give you the same binaries that you shipped 2 months ago. You don't know if the latest build linked with the latest system libraries. You don't know if the linked libraries are consistent with each other. You basically have no assurance of *anything*, except if you make clean; make. But wait a minute, I thought the whole point of make is incremental building. If you have to make clean; make *every* *single* *time*, that completely defeats the purpose, and you might as well just put your compile commands in a bash script instead, and run that to rebuild everything from scratch every time. Yeah it's slow, but at least you know for sure your executables are always what you think they are! (And in practice, the bash script might actually be faster -- I lost track of how much time I wasted trying to debug something, only to go back and make clean; make and discover that the bug vanished. Had I used the shell script every single time, I could've saved how many hours spent tracking down these heisenbugs.) T -- Gone Chopin. Bach in a minuet.
Sep 25 2014
next sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
 You don't know if
 recompiling after checking out a previous release of your code 
 will
 actually give you the same binaries that you shipped 2 months 
 ago.
To be clear, even if nothing changed, re-running the build may produce different output. This is actually a really hard problem - some build tools actually use entropy when producing their outputs, and as a result running the exact same tool with the same parameters in the same [apparent] environment will produce a subtly different output. This may be intended (address randomization) or semi-unintentional (generating a unique GUID inside a PDB so the debugger can validate the symbols match the binaries.) Virtually no build system in use can guarantee the above in all cases, so you end up making trade-offs - and if you don't really understand those tradeoffs, you won't trust your build system. What else may mess up the perfection of repeatability of your builds? Environment variables, the registry (on Windows), any source of entropy (the PRNG, the system clock/counters, any network access), etc. Build engineers themselves don't trust the build tooling because for as long as we have had the tooling, no one has invested enough into knowing what is trustworthy or how to make it that way. It's like always coding without a typesafe language, but which "gets the job done." Until you've spent some time in the typesafe environment, maybe you can't realize the benefit. You'll say "well, now I have to type a bunch more crap, and in most cases it wouldn't have helped me anyway" right up until you are sitting there at 3AM the night before shipping the product trying to track down why your Javascript program - I mean build process - isn't doing what you thought it did. Just because you CAN build a massive software system in Javascript doesn't mean the language is per-se good - it may just mean you are sufficient motivated to suffer through the pain. I'd rather make the whole experience *enjoyable* (hello TypeScript?) Different people will make different tradeoffs, and I am not here to tell Andrei or Walter that they *need* a new build system for D to get their work done - they don't right now. I'm more interested in figuring out how to provide a platform to realize the benefits for build like we have for our modern languages, and then leveraging that in new ways (like better sharing between the compiler, debugger, IDEs, test and packaging.)
Sep 25 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 07:19:14PM +0000, Cliff via Digitalmars-d wrote:
 On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
 Digitalmars-d wrote:
You don't know if recompiling after checking out a previous release
of your code will actually give you the same binaries that you
shipped 2 months ago.
To be clear, even if nothing changed, re-running the build may produce different output. This is actually a really hard problem - some build tools actually use entropy when producing their outputs, and as a result running the exact same tool with the same parameters in the same [apparent] environment will produce a subtly different output. This may be intended (address randomization) or semi-unintentional (generating a unique GUID inside a PDB so the debugger can validate the symbols match the binaries.) Virtually no build system in use can guarantee the above in all cases, so you end up making trade-offs - and if you don't really understand those tradeoffs, you won't trust your build system.
Good point.
 What else may mess up the perfection of repeatability of your
 builds?  Environment variables, the registry (on Windows), any
 source of entropy (the PRNG, the system clock/counters, any
 network access), etc.
Well, obviously if your build process involves input from output, then it's impossible to have 100% repeatable builds. But at least we can do it (and arguably *should* do it) when there are no outside outputs. I actually have some experience in this area, because part of the website project I described in another post involves running gnuplot to plot statistics of a certain file by connecting to an SVN repository and parsing its history log. Since the SVN repo is not part of the website repo, obviously the build of a previous revision of the website will never be 100% repeatable -- it will always generate the plot for the latest history rather than what it would've looked like at the time of the previous revision. But for the most part, this doesn't matter. I *did* find that imagemagick was messing up my SCons scripts because it would always insert timestamped metadata into the generated image files, which caused SCons to always see the files as changed and trigger redundant rebuilds. This is also an example of where sometimes you do need to override the build system's default mechanisms to tell it to chill out and not rebuild that target every time. I believe SCons lets you do this, though I solved the problem another way -- by passing options to imagemagick to suppress said metadata. Nevertheless, I'd say that overall, builds should be reproducible by default, and the user should tell the build system when it doesn't have to be -- rather than the other way round. Just like D's motto of safety first, unsafe if you ask for it. [...]
 Different people will make different tradeoffs, and I am not here
 to tell Andrei or Walter that they *need* a new build system for
 D to get their work done - they don't right now.  I'm more
 interested in figuring out how to provide a platform to realize
 the benefits for build like we have for our modern languages, and
 then leveraging that in new ways (like better sharing between the
 compiler, debugger, IDEs, test and packaging.)
Agreed. I'm not saying we *must* replace the makefiles in dmd / druntime / phobos... I'm speaking more categorically, that build systems in general have advanced beyond the days of make, and it's high time people started learning about them. While you *could* write an entire application in assembly language (I did), times have moved on, and we now have far more suitable tools for the job. T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
Sep 25 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-25 20:49, H. S. Teoh via Digitalmars-d wrote:

 The compiler and compile flags are inputs to the build rules in SCons.

 In my SCons projects, when I change compile flags (possibly for a subset
 of source files), it correctly figures out which subset (or the entire
 set) of files needs to be recompiled with the new flags. Make fails, and
 you end up with an inconsistent executable.

 In my SCons projects, when I upgrade the compiler, it recompiles
 everything with the new compiler. Make doesn't detect a difference, and
 if you make a change and recompile, suddenly you got an executable 80%
 compiled with the old compiler and 20% compiled with the new compiler.
 Most of the time it doesn't make a difference... but when it does, have
 fun figuring out where the problem lies. (Or just make clean; make yet
 again... the equivalent of which is basically what SCons would have done
 5 hours ago.)

 In my SCons projects, when I upgrade the system C libraries, it
 recompiles everything that depends on the updated header files *and*
 library files. In make, it often fails to detect that the .so's have
 changed, so it fails to relink your program. Result: your executable
 behaves strangely at runtime due to wrong .so being linked, but the
 problem vanishes once you do a make clean; make.
I see, thanks for the explanation. -- /Jacob Carlborg
Sep 25 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/25/2014 02:49 PM, H. S. Teoh via Digitalmars-d wrote:
 Make-heads find the idea of the compiler being part of the input to a
 build rule "strange"; to me, it's common sense.
Yes. This is exactly why (unless it's been reverted or regressed? I only mention that because I haven't looked lately) RDMD counts the compiler itself as a dependency. Because: $ dvm use 2.065.0 $ rdmd stuff.d [compiles] $ dvm use 2.066.0 $ rdmd stuff.d [silently *doesn't* recompile?!? Why is *that* useful?] Is *not* remotely useful behavior, basically makes no sense at all, *and* gives the programmer bad information. ("Oh, it compiles fine on this new version? Great! I'm done here! Wait, why are other people reporting compile errors on the new compiler? It worked for me.")
Oct 09 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 23:14:30 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 And I use make -j on posix for parallel builds, it works fine on dmd.
me too. paired with `git clean -dxf` to get "clean of the cleanest possible" fileset. it's good that dmd build times are so low. ;-)
Sep 24 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 21:44:26 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Make is the C++ of build systems. It may be ugly, but you can get it
 to work.
'make' reminds me assembler language: it's possible to do alot of cool things with 'make', but it's compilcated and tedious process. ah, and it's not the fastest kid on the block, so you'll not gain any speed using 'make'. ;-)
Sep 24 2014
prev sibling parent reply "Cliff" <cliff.s.hudson gmail.com> writes:
 Actually you can't do this for D properly without enlisting the 
 help of the compiler. Scoped import is a very interesting 
 conditional dependency (it is realized only if the template is 
 instantiated).

 Also, lazy opening of imports is almost guaranteed to have a 
 huge good impact on build times.

 Your reply confirms my worst fear: you're looking at yet 
 another general build system, of which there are plenty of 
 carcasses rotting in the drought left and right of highway 101.
This is one of my biggest frustrations with existing "build systems" - which really are nothing more than glorified "make"s with some extra syntax and - for the really advanced ones - ways to help you correctly specify your makefiles by flagging errors or missing dependencies.
 The build system that will be successful for D will cooperate 
 with the compiler, which will give it fine-grained dependency 
 information. Haskell does the same with good results.


 Andrei
The compiler has a ton of precise information useful for build tools, IDEs and other kinds of analysis tools (to this day, it still bugs the crap out of me that Visual Studio has effectively *two* compilers, one for intellisense and one for the command-line and they do not share the same build environment or share the work they do!) Build is more than just producing a binary - it incorporates validation through testing, packaging for distribution, deployment and even versioning. I'd like to unlock the data in our tools and find ways to leverage it to improve automation and the whole developer workflow. Those ideas and principles go beyond D and the compiler of course, but we do have a nice opportunity here because we can work closely with the compiler authors, rather than having to rely *entirely* on OS-level process introspection through e.g. detours (which is still valuable from a pure dependency discovery process of course.) If we came out of this project with "tup-for-D" I'd consider that an abject failure.
Sep 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 10:14 PM, Cliff wrote:
 This is one of my biggest frustrations with existing "build systems" -
 which really are nothing more than glorified "make"s with some extra
 syntax and - for the really advanced ones - ways to help you correctly
 specify your makefiles by flagging errors or missing dependencies.
It's nice you two are enthusiastic about improving that space. Also, it's a good example of how open source development works. I can't tell you what to do, you guys get to work on whatever strikes your fancy. Have fun! -- Andrei
Sep 24 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 21:15:59 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 needs to write should in theory be simply:
=20
 	Program("mySuperApp", "src/main.d");
=20
 and everything else will be automatically figured out.
ah, that's exactly why i migrated to jam! i got bored of manual dependency control, and jam file scanning works reasonably well (for c and c++, i'm yet to finish D scanner -- it should understand what package.d is). now i'm just writing something like Main myproggy : main.d module0.d module1.d ; and that's all. or even Main myproggy : [ Glob . : *.d : names-only ] ; and for projects which contains some subdirs, libs and so on it's still easy. i never tried jam on really huge projects, but i can't see why it shouldn't be good, as it supports subdirs without recursion and so on. jam is still heavy file-based and using only timestamps, but it's only 'cause i'm still not motivaded enough (read: timestamps works for me). p.s. i'm talking about my own fork of 'jam' here. it's slightly advanced over original jam. p.p.s. i patched gdc to emit all libraries mentioned in `pragma(lib, ...)` and my jam understands how to extract and use this information.
Sep 24 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:

 Well, Cliff & I (and whoever's interested) will see what we can do about
 that. Perhaps in the not-so-distant future we may have a D build tool
 that can serve as the go-to build tool for D projects.
What problems do you see with Dub? -- /Jacob Carlborg
Sep 25 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 09:04:43 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 What problems do you see with Dub?
i, for myself, see a great problem with Dub: it's not a universal build tool. some of my internal D projects, for example, builds C libraries from source (and some of that libraries using yacc, for example, and others some other generator tools, which are build and execed in the process of building the library), then runs some kind of external generators (can't do this with D CTFE, 'cause compiler eats all of my RAM and then fails), then builds D sources, then links it all together. it's complicated as it is, and Dub is not well-suited for such use cases.
Sep 25 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 25 September 2014 at 07:04:43 UTC, Jacob Carlborg 
wrote:
 On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:

 Well, Cliff & I (and whoever's interested) will see what we 
 can do about
 that. Perhaps in the not-so-distant future we may have a D 
 build tool
 that can serve as the go-to build tool for D projects.
What problems do you see with Dub?
Here's one: having to manually generate the custom main file for unittest builds. There's no current way (or at least there wasn't when I brought it up in the dub forum) to tell it to autogenerate a D file from a dub package and list it as a dependency of the unittest build. This is trivial in CMake. Instead I have to remember to run my dtest program every time I create a new file with unit tests when it should be done for me. Atila
Sep 25 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file for
 unittest builds. There's no current way (or at least there wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D file from
 a dub package and list it as a dependency of the unittest build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function. -- /Jacob Carlborg
Sep 25 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file 
 for
 unittest builds. There's no current way (or at least there 
 wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D 
 file from
 a dub package and list it as a dependency of the unittest 
 build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.
Andrei spoke about an idiom that they constantly use at Facebok, because there aparrently nobody runs *main and unittests*. So they keep a special empty main for the -unittest version. If tha time to clean up D has come, maybe it is the time to make that idiom the default behaviour of the flag. He posted that thing somewhere in the forum, but cannot find it right now. Real usage is good for learning.
Sep 25 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
 On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
 wrote:
 On 25/09/14 09:38, Atila Neves wrote:
 Andrei spoke about an idiom that they constantly use at 
 Facebok, because there aparrently nobody runs *main and 
 unittests*. So they keep a special empty main for the -unittest 
 version.
This idiom here: http://forum.dlang.org/post/ljr5n7$1leb$1 digitalmars.com "Last but not least, virtually nobody I know runs unittests and then main. This is quickly becoming an idiom: version(unittest) void main() {} else void main() { ... } I think it's time to change that. We could do it the non-backward-compatible way by redefining -unittest to instruct the compiler to not run main. Or we could define another flag such as -unittest-only and then deprecate the existing one. "
Sep 25 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 08:40:50PM +0000, eles via Digitalmars-d wrote:
 On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
On 25/09/14 09:38, Atila Neves wrote:
Andrei spoke about an idiom that they constantly use at Facebok,
because there aparrently nobody runs *main and unittests*. So they
keep a special empty main for the -unittest version.
This idiom here: http://forum.dlang.org/post/ljr5n7$1leb$1 digitalmars.com "Last but not least, virtually nobody I know runs unittests and then main. This is quickly becoming an idiom: version(unittest) void main() {} else void main() { ... } I think it's time to change that. We could do it the non-backward-compatible way by redefining -unittest to instruct the compiler to not run main. Or we could define another flag such as -unittest-only and then deprecate the existing one.
Please don't deprecate the current -unittest. I regularly find it very useful when in the code-compile-test cycle. I'm OK with introducing -unittest-only for people who want it, but I still like using the current -unittest. T -- Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
Sep 25 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file 
 for
 unittest builds. There's no current way (or at least there 
 wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D 
 file from
 a dub package and list it as a dependency of the unittest 
 build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.
I don't want an empty main function. I want the main function and the file it's in to be generated by the build system. Atila
Sep 25 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 10:26 AM, Atila Neves wrote:
 On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file for
 unittest builds. There's no current way (or at least there wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D file from
 a dub package and list it as a dependency of the unittest build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.
I don't want an empty main function. I want the main function and the file it's in to be generated by the build system.
Why would be the focus on the mechanism instead of the needed outcome? -- Andrei
Sep 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 10:45 AM, Andrei Alexandrescu wrote:
 On 9/25/14, 10:26 AM, Atila Neves wrote:
 On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file for
 unittest builds. There's no current way (or at least there wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D file from
 a dub package and list it as a dependency of the unittest build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.
I don't want an empty main function. I want the main function and the file it's in to be generated by the build system.
Why would be the focus on the mechanism instead of the needed outcome? -- Andrei
I've found: -main -unittest -cov to be terribly convenient when developing modules. Should have added -main much sooner.
Sep 25 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 12:51:45PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 I've found:
 
    -main -unittest -cov
 
 to be terribly convenient when developing modules. Should have added
 -main much sooner.
Yeah, I do that all the time nowadays when locally testing Phobos fixes. In the past I'd have to write yet another empty main() in yet another temporary source file, just to be able to avoid having to wait for the entire Phobos testsuite to run after a 1-line code change. T -- "How are you doing?" "Doing what?"
Sep 25 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 25 September 2014 at 17:45:56 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 10:26 AM, Atila Neves wrote:
 On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
 wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file 
 for
 unittest builds. There's no current way (or at least there 
 wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a 
 D file from
 a dub package and list it as a dependency of the unittest 
 build.
Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.
I don't want an empty main function. I want the main function and the file it's in to be generated by the build system.
Why would be the focus on the mechanism instead of the needed outcome? -- Andrei
Because I don't use unittest blocks, I use my own library. The one thing it can't use the compiler for is discover what files are in a directory, so I need to generate the main function that calls into unit-threaded with a list of compile-time strings. What I need/want is that every time I add a new source file to the project, it gets auto-generated automatically and is a dependency of the unittest build in dub. Atila
Sep 25 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-26 08:51, Atila Neves wrote:

 Because I don't use unittest blocks, I use my own library. The one thing
 it can't use the compiler for is discover what files are in a directory,
 so I need to generate the main function that calls into unit-threaded
 with a list of compile-time strings. What I need/want is that every time
 I add a new source file to the project, it gets auto-generated
 automatically and is a dependency of the unittest build in dub.
Yeah, this sucks. That's way this is needed: https://github.com/D-Programming-Language/dmd/pull/2271 -- /Jacob Carlborg
Sep 26 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-25 19:26, Atila Neves wrote:

 I don't want an empty main function. I want the main function and the
 file it's in to be generated by the build system.
What do you want the main function to contain? -- /Jacob Carlborg
Sep 25 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file for
 unittest builds. There's no current way (or at least there wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D file from
 a dub package and list it as a dependency of the unittest build.
BTW, I would say that's a minor issue, far from begin enough to create a completely new build system. -- /Jacob Carlborg
Sep 25 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 25 September 2014 at 13:51:17 UTC, Jacob Carlborg 
wrote:
 On 25/09/14 09:38, Atila Neves wrote:

 Here's one: having to manually generate the custom main file 
 for
 unittest builds. There's no current way (or at least there 
 wasn't when I
 brought it up in the dub forum) to tell it to autogenerate a D 
 file from
 a dub package and list it as a dependency of the unittest 
 build.
BTW, I would say that's a minor issue, far from begin enough to create a completely new build system.
I agree. That's why I haven't written a build system yet. However, larger projects need this kind of thing. If I were working on a team of 20+ devs writing D, I'd eventually need it. I'd consider SCons, CMake, etc. but I'd still need dub for package management. Atila
Sep 25 2014
prev sibling parent Shammah Chancellor <email domain.com> writes:
On 2014-09-25 01:54:26 +0000, H. S. Teoh via Digitalmars-d said:

 On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via 
 Digitalmars-d wrote:
 On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
 You're misrepresenting my position.*In spite of their current flaws*,
 modern build systems like SCons and Tup already far exceed make in
 their basic capabilities and reliability.
Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be the change you want to see in dlang's build system" :o). -- Andrei
Well, Cliff & I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. T
Please submit PRs for dub, instead of creating a new project. Dub is a nice way of managing library packages already. I'd rather not use two different tools.
Oct 04 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via 
 Digitalmars-d wrote:
 [...]
 Now throw in things like built-in parallelization ala SCons 
 (I'm not
 sure if tup does that too, I suspect it does), 
 100%-reproducible builds,
 auto-packaging, etc., and we might have a contender for Andrei's
 "winner" build system.
Tup does parallels builds: in the company we were using scons, now cmake, tup and, well, dub. Plus an internal one... *sigh*... --- /Paolo
Sep 25 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Sep-2014 01:12, Andrei Alexandrescu пишет:
 On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
 That's unfortunate indeed. I wish I could inspire them as to how cool a
 properly-done build system can be.
[snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has "won" over make;
Pretty much any of them is better, and will easily handle the size of phobos/druntime/dmd projects.
 oh there's plenty of them, but each has
 its own quirks that makes it tenuous to use;
Somehow must indicate that make doesn't have them (and in incredible capacity)? Most of my Scons scripts are under 10 lines, in fact 2-3 LOCs. I had an "insanely" complicated one could handle 2 platforms, 3 emulators and a few custom build steps (including signing binaries), cleaning, tracking dependencies with minimal rebuilds. For instance, binary need not to be signed again if it's bit for bit the same. All of the above was done in about 50 lines, never braking as the project progressed, I think it changed only 2-3 times over a year. I was never able to make a good makefile that wouldn't shit on me in some way, like not properly cleaning something or handling errors . I'm not even talking about the 10+ LOCs for anything barely useful.
 (2) any build system for a
 project of nontrivial size needs a person/team minding it - never saw
 such a thing as it's just all automated and it works;
The question is amount of work, size of file and frequency of changes. For instance, Scons easily allows not to change a makefile on every single added module, I can't say if make could pull it off.
 (3) especially if
 the build system is not that familiar, the role of the build czar is all
 the more important.
Somebody (Russel?) was working on D Scons support, how about start to capitalize on this work? I'd gladly try to make a scons script for phobos/druntime if there is even a tiny chance of apporval.
 So the reality is quite a bit more complicated than the shiny city on a
 hill you describe.
Most people using make/autotools say build systems are hard, it need not to be true but I'm obviously biased. -- Dmitry Olshansky
Sep 25 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 09:18:26PM +0400, Dmitry Olshansky via Digitalmars-d
wrote:
[...]
 I had an "insanely" complicated one could handle 2 platforms, 3
 emulators and a few custom build steps (including signing binaries),
 cleaning, tracking dependencies with minimal rebuilds. For instance,
 binary need not to be signed again if it's bit for bit the same.
 All of the above was done in about 50 lines, never braking as the
 project progressed, I think it changed only 2-3 times over a year.

 I was never able to make a good makefile that wouldn't shit on me in
 some way, like not properly cleaning something or handling errors .
 I'm not even talking about the 10+ LOCs for anything barely useful.
+1. Jives with my experience with SCons as well.
 25-Sep-2014 01:12, Andrei Alexandrescu пишет:
(2) any build system for a project of nontrivial size needs a
person/team minding it - never saw such a thing as it's just all
automated and it works;
The question is amount of work, size of file and frequency of changes. For instance, Scons easily allows not to change a makefile on every single added module, I can't say if make could pull it off.
It can. Except that you can expect things will go horribly wrong if you so much as breathe in the wrong direction. And when you're dealing with a multi-person project (i.e., 99% of non-trivial software projects), expect that people will do stupid things that either breaks the makefile, or they will make breaking changes to the makefile that will screw everything up for everyone else.
(3) especially if the build system is not that familiar, the role of
the build czar is all the more important.
Somebody (Russel?) was working on D Scons support, how about start to capitalize on this work? I'd gladly try to make a scons script for phobos/druntime if there is even a tiny chance of apporval.
D support has been merged into mainline SCons, thanks to Russel's efforts. I've been using his D module for a while now, and find it generally very C/C++-like, which is perfect for projects that need heavy interfacing between C/C++ and D. For D-only projects, it's a bit klunky because it defaults to separate compilation, whereas dmd tends to work better with whole-program compilation (or at least per-module rather than per-source-file compilation). SCons does hit performance barriers when you get into very large projects (on the magnitude of Mozilla Firefox, or the GTK desktop suite, for example), but for something the size of dmd/druntime/phobos, you won't notice the difference at all. In fact, you'd save a lot of time by not needing to make clean; make every single time you do anything non-trivial.
So the reality is quite a bit more complicated than the shiny city on
a hill you describe.
Most people using make/autotools say build systems are hard, it need not to be true but I'm obviously biased.
[...] I'm biased too, but I'm inclined to think that those people say it's hard because it *is* hard when the best you got is make and autotools. :-P T -- Leather is waterproof. Ever see a cow with an umbrella?
Sep 25 2014
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 24 September 2014 at 20:12:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
 On Wed, Sep 24, 2014 at 07:36:05PM +0000, Cliff via 
 Digitalmars-d wrote:
 On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg
 wrote:
On 2014-09-24 12:16, Walter Bright wrote:

I've never heard of a non-trivial project that didn't have 
constant
breakage of its build system. All kinds of reasons - add a 
file,
forget to add it to the manifest. Change the file contents, 
neglect
to update dependencies. Add new dependencies on some script, 
script
fails to run on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong.
People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems.
That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think "make" whenever they hear "build system". Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.)
 Unfortunately, build engineering is effectively a specialty of 
 its own
 when you step outside the most trivial of systems.  It's 
 really no
 surprise how few people can get it right - most people can't 
 even
 agree on what a build system is supposed to do...
It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T
Couldn't have said it better myself. Atila
Sep 24 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 13:10:46 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 The problem is that still too many people think "make"
 whenever they hear "build system".  Make is but a poor, antiquated
 caricature of what modern build systems can do. Worse is that most
 people are resistant to replacing make because of inertia. (Not
 realizing that by not throwing out make, they're subjecting themselves
 to a lifetime of unending, unnecessary suffering.)
+many. 'make' is a PITA even for small personal projects. i myself using heavily modified jam as build system. it's not shiny good too, but it is at least usable without much suffering and small enough to be managed by one man.
Sep 24 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 12:26 PM, Jacob Carlborg wrote:
 On 2014-09-24 12:16, Walter Bright wrote:

 I've never heard of a non-trivial project that didn't have constant
 breakage of its build system. All kinds of reasons - add a file, forget
 to add it to the manifest. Change the file contents, neglect to update
 dependencies. Add new dependencies on some script, script fails to run
 on one configuration. And on and on.
Again, if changing the file contents breaks the build system you're doing it very, very wrong.
What matters is if the autotester imports X's large project, then it must somehow import whatever X's build system is, for better or worse. And I guarantee it will break constantly. Analogously, you and I know how to write code correctly (as does everyone else). But I guarantee that you and I are mistaken about that, and we don't write perfect code, and it breaks. Just like the build systems.
Sep 24 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-24 08:57, Walter Bright wrote:

 Heck, the dmd release package build scripts break every single release
 cycle.
The it's obviously doing something wrong. -- /Jacob Carlborg
Sep 24 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 11:42 AM, Jacob Carlborg wrote:
 On 2014-09-24 08:57, Walter Bright wrote:

 Heck, the dmd release package build scripts break every single release
 cycle.
The it's obviously doing something wrong.
See my reply to Vladimir.
Sep 24 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2014 3:16 PM, H. S. Teoh via Digitalmars-d wrote:
 On Sun, Sep 21, 2014 at 08:49:38AM +0000, via Digitalmars-d wrote:
 On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=--- I filed over half of those...
I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice "hey, your PR broke this and that project" would surely be helpful to detect the breakages early on.
This has been suggested before. The problem is resources. If you're willing to donate equipment for running these tests, it would be greatly appreciated, I believe.
No, that's not the problem. The problem is what to do when the "larger project" fails. Currently, it is the submitter's job to adjust the test suite, fix phobos code, whatever is necessary to get the suite running again. Sometimes, in the more convoluted Phobos code, this can be a real challenge. Now replace that with somewhere in a large project, which our poor submitter knows absolutely nothing about, it fails. You're asking him to go in, understand this large project, determine if it's a problem with his submission or a problem with the large project, and fix it. At some level, then WE become the maintainers of that large project. This is completely unworkable.
Sep 23 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright 
wrote:
 This is completely unworkable.
Mister, please stop hurting the pool straw man. Let me quote the relevant part:
 They don't necessarily need to be blocking, just a notice 
 "hey, your PR broke this and that project" would surely be 
 helpful to detect the breakages early on.
I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone.
Sep 23 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 9:08 PM, Vladimir Panteleev wrote:
 On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote:
 This is completely unworkable.
Mister, please stop hurting the pool straw man. Let me quote the relevant part:
 They don't necessarily need to be blocking, just a notice "hey, your PR
 broke this and that project" would surely be helpful to detect the breakages
 early on.
I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone.
Who is going to maintain the autotester version of these projects? What I'd like to see is the autotester regularly build release packages out of HEAD. Then, large project maintainers can create their own scripts to download the latest compiler and attempt to build their project.
Sep 23 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 September 2014 at 04:36:33 UTC, Walter Bright 
wrote:
 On 9/23/2014 9:08 PM, Vladimir Panteleev wrote:
 On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright 
 wrote:
 This is completely unworkable.
Mister, please stop hurting the pool straw man. Let me quote the relevant part:
 They don't necessarily need to be blocking, just a notice 
 "hey, your PR
 broke this and that project" would surely be helpful to 
 detect the breakages
 early on.
I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone.
Who is going to maintain the autotester version of these projects? What I'd like to see is the autotester regularly build release packages out of HEAD. Then, large project maintainers can create their own scripts to download the latest compiler and attempt to build their project.
We've been talking about this since last year's DConf. I don't know if it's ever going to happen, but now there is Digger, which solves most of the same problem. Nevertheless, this is not enough. It must be automatic - it must verify the state of things daily, without human intervention. It's unreasonable (borderline absurd, even) to expect that every large project maintainer to manually verify if their project still works every day. It doesn't need to run on the same hardware as the autotester. It can run on the project maintainers' servers or home computers. But it must be easy to set up, and it should notify both the project owners and the pull request authors.
Sep 24 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 3:00 AM, Vladimir Panteleev wrote:
 Nevertheless, this is not enough. It must be automatic - it must verify the
 state of things daily, without human intervention. It's unreasonable
(borderline
 absurd, even) to expect that every large project maintainer to manually verify
 if their project still works every day.

 It doesn't need to run on the same hardware as the autotester. It can run on
the
 project maintainers' servers or home computers. But it must be easy to set up,
 and it should notify both the project owners and the pull request authors.
If it is something opted in or out by the project maintainers, and is not part of the autotester, and runs on the project maintainer's system, I'm for it.
Sep 24 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 24/09/14 05:59, Walter Bright wrote:

 No, that's not the problem. The problem is what to do when the "larger
 project" fails.

 Currently, it is the submitter's job to adjust the test suite, fix
 phobos code, whatever is necessary to get the suite running again.
 Sometimes, in the more convoluted Phobos code, this can be a real
 challenge.

 Now replace that with somewhere in a large project, which our poor
 submitter knows absolutely nothing about, it fails. You're asking him to
 go in, understand this large project, determine if it's a problem with
 his submission or a problem with the large project, and fix it.
If it worked before and now it doesn't, then it sounds like a regression to me.
 At some level, then WE become the maintainers of that large project.

 This is completely unworkable.
The author of the library could at least get a notification. -- /Jacob Carlborg
Sep 23 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 11:27 PM, Jacob Carlborg wrote:
 If it worked before and now it doesn't, then it sounds like a regression to me.
It could be an "accepts invalid" bug was fixed. It could be that we wanted to make a breaking change. It could be that it never actually worked, it just silently failed. I can say from experience that when you're presented with an unfamiliar tangle of template code (why do people write that stuff :-) ) it ain't at all easy discerning what kind of issue it actually is.
Sep 24 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 There was a recent video[1] by Jonathan Blow about what he 
 would want in a programming language designed specifically for 
 game development. Go, Rust, and D were mentioned and his reason 
 for not wanting to use D is is that it is "too much like C++" 
 although he does not really go into it much and it was a very 
 small part of the video it still brings up some questions.

 What I am curious is what are the worst parts of D? What sort 
 of things would be done differently if we could start over or 
 if we were designing a D3? I am not asking to try and bash D 
 but because it is helpful to know what's bad as well as good.

 I will start off...
 GC by default is a big sore point that everyone brings up
 "is" expressions are pretty wonky
 Libraries could definitely be split up better

 What do you think are the worst parts of D?

 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
1. Accidental complexity. 2. Introducing hacks to solve issues instead of going for a clean solution, because it reduce complexity in the short run (and create 1. on the long run).
Sep 20 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Proper D code is supposed to have lots of attributes (pure const nothrow nogc) that brings little and makes it look bad.
Sep 21 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/21/14, 1:27 AM, ponce wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Proper D code is supposed to have lots of attributes (pure const nothrow nogc) that brings little and makes it look bad.
No because deduction. -- Andrei
Sep 21 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 September 2014 15:54, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/21/14, 1:27 AM, ponce wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Proper D code is supposed to have lots of attributes (pure const nothrow nogc) that brings little and makes it look bad.
No because deduction. -- Andrei
Agreed. The time when you want to explicitly use these attributes is if you want to enforce nogc, pure ... As it turns out, it is a good idea to enforce these from the start, rather than after you've written your program. Iain
Sep 22 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 21, 2014 at 08:27:56AM +0000, ponce via Digitalmars-d wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
Proper D code is supposed to have lots of attributes (pure const nothrow nogc) that brings little and makes it look bad.
To be fair, though, hindsight is always 20/20. Had we known earlier that we would have these attributes, they would've been default to begin with, and you'd have to explicitly ask for impure / mutable / throwing / withgc. But on the positive side, the compiler will automatically infer attributes for template functions, and lately I've been tempted to write templated functions by default just to get the attribute inference bonus, even if it's just translating fun(a,b,c) to fun()(a,b,c). The caller site never has to change, and the function is never instantiated more than once -- and you get the added bonus that if the function is never actually called, then it doesn't even appear in the executable. Attribute inference is the way to go, IMO. Research has shown that people generally don't bother with writing properly-attributed declarations -- it's too tedious and easily overlooked. Having "nicer" attributes be the default helps somewhat, but attribute inference is ultimately what might actually stand a chance of solving this problem. T -- "Holy war is an oxymoron." -- Lazarus Long
Sep 21 2014
parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Sunday, 21 September 2014 at 22:41:04 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 with, and you'd have to explicitly ask for impure / mutable
"Impure" should be on parameters so you can do dataflow in the presence of FFI. So you basically need better mechanisms. But then you have to analyze the needs first (e.g. the desirable semantics that currently are avoided) All of then. Adding one hack after the other is not the best approach.
Sep 21 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 21, 2014 at 10:57:34PM +0000, Ola Fosheim Grostad via Digitalmars-d
wrote:
 On Sunday, 21 September 2014 at 22:41:04 UTC, H. S. Teoh via Digitalmars-d
 wrote:
with, and you'd have to explicitly ask for impure / mutable
"Impure" should be on parameters so you can do dataflow in the presence of FFI. So you basically need better mechanisms. But then you have to analyze the needs first (e.g. the desirable semantics that currently are avoided) All of then. Adding one hack after the other is not the best approach.
[...] Eventually the real solution is automatic inference, with the user using explicit attributes at the top-level where they are desired, and the compiler will take care of the rest. T -- Creativity is not an excuse for sloppiness.
Sep 21 2014
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Sunday, 21 September 2014 at 23:04:22 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Eventually the real solution is automatic inference, with the 
 user
 using explicit attributes at the top-level where they are 
 desired, and
 the compiler will take care of the rest.
Yes, but you need a model of the semantics you are looking for.
Sep 21 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
The worst part is programmers unable to express their ideas in written form.
Sep 21 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 There was a recent video[1] by Jonathan Blow about what he 
 would want in a programming language designed specifically for 
 game development. Go, Rust, and D were mentioned and his reason 
 for not wanting to use D is is that it is "too much like C++" 
 although he does not really go into it much and it was a very 
 small part of the video it still brings up some questions.

 What I am curious is what are the worst parts of D? What sort 
 of things would be done differently if we could start over or 
 if we were designing a D3? I am not asking to try and bash D 
 but because it is helpful to know what's bad as well as good.

 I will start off...
 GC by default is a big sore point that everyone brings up
 "is" expressions are pretty wonky
 Libraries could definitely be split up better

 What do you think are the worst parts of D?

 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
There are so many it is hard to chose worst offenders.
Sep 21 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 There was a recent video[1] by Jonathan Blow about what he would want in a
 programming language designed specifically for game development. Go, Rust,
 and D were mentioned and his reason for not wanting to use D is is that it
 is "too much like C++" although he does not really go into it much and it
 was a very small part of the video it still brings up some questions.

 What I am curious is what are the worst parts of D? What sort of things
 would be done differently if we could start over or if we were designing a
 D3? I am not asking to try and bash D but because it is helpful to know
 what's bad as well as good.

 I will start off...
 GC by default is a big sore point that everyone brings up
 "is" expressions are pretty wonky
 Libraries could definitely be split up better

 What do you think are the worst parts of D?

 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
Personally, after years of use, my focus on things that really annoy me has shifted away from problems with the language, and firmly towards basic practicality and productivity concerns. I'm for addressing things that bother the hell out of me every single day. I should by all reason be more productive in D, but after 6 years of experience, I find I definitely remain less productive, thanks mostly to tooling and infrastructure. 1. Constant rejection of improvements because "OMG breaking change!". Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes. 2. Tooling is still insufficient. I use Visual Studio, and while VisualD is good, it's not great. Like almost all tooling projects, there is only one contributor, and I think this trend presents huge friction to adoption. Tooling is always factored outside of the D community and their perceived realm of responsibility. I'd like to see tooling taken into the core community and issues/bugs treated just as seriously as issues in the compiler/language itself. 3. Debugging is barely ever considered important. I'd love to see a concerted focus on making the debug experience excellent. Iain had a go at GDB, I understand there is great improvement there. Sadly, we recently lost the developer of Mago (a Windows debugger). There's lots of work we could do here, and I think it's of gigantic impact. 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years later, I still can't pass an rvalue->ref (been discussed endlessly), create a ref local, and the separation from the type system makes it a nightmare in generic code. This was a nuisance for me on day-1, and has been grinding me down endlessly for years. It has now far eclipsed my grudges with the GC/RC, or literally anything else about the language on account of frequency of occurrence; almost daily.
Sep 23 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
 1. Constant rejection of improvements because "OMG breaking change!".
 Meanwhile, D has been breaking my code on practically every release
 for years. I don't get this, reject changes that are deliberately
 breaking changes which would make significant improvements, but allow
 breaking changes anyway because they are bug fixes? If the release
 breaks code, then accept that fact and make some real proper breaking
 changes that make D substantially better! It is my opinion that D
 adopters don't adopt D because it's perfect just how it is and they
 don't want it to improve with time, they adopt D *because they want it
 to improve with time*! That implies an acceptance (even a welcoming)
 of breaking changes.
What change in particular?
 2. Tooling is still insufficient. I use Visual Studio, and while
 VisualD is good, it's not great. Like almost all tooling projects,
 there is only one contributor, and I think this trend presents huge
 friction to adoption. Tooling is always factored outside of the D
 community and their perceived realm of responsibility. I'd like to see
 tooling taken into the core community and issues/bugs treated just as
 seriously as issues in the compiler/language itself.

 3. Debugging is barely ever considered important. I'd love to see a
 concerted focus on making the debug experience excellent. Iain had a
 go at GDB, I understand there is great improvement there. Sadly, we
 recently lost the developer of Mago (a Windows debugger). There's lots
 of work we could do here, and I think it's of gigantic impact.
There are 23 issues tagged with 'symdeb': https://issues.dlang.org/buglist.cgi?keywords=symdeb&list_id=109316&resolution=--- If there are more untagged ones, please tag them.
 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years
 later, I still can't pass an rvalue->ref (been discussed endlessly),
 create a ref local, and the separation from the type system makes it a
 nightmare in generic code. This was a nuisance for me on day-1, and
 has been grinding me down endlessly for years. It has now far eclipsed
 my grudges with the GC/RC, or literally anything else about the
 language on account of frequency of occurrence; almost daily.
I have to ask why all your code revolves about this one thing?
Sep 24 2014
next sibling parent reply "Don" <x nospam.com> writes:
On Wednesday, 24 September 2014 at 07:43:49 UTC, Walter Bright 
wrote:
 On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
 1. Constant rejection of improvements because "OMG breaking 
 change!".
 Meanwhile, D has been breaking my code on practically every 
 release
 for years. I don't get this, reject changes that are 
 deliberately
 breaking changes which would make significant improvements, 
 but allow
 breaking changes anyway because they are bug fixes? If the 
 release
 breaks code, then accept that fact and make some real proper 
 breaking
 changes that make D substantially better! It is my opinion 
 that D
 adopters don't adopt D because it's perfect just how it is and 
 they
 don't want it to improve with time, they adopt D *because they 
 want it
 to improve with time*! That implies an acceptance (even a 
 welcoming)
 of breaking changes.
I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today. Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can. For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? As I said earlier in the year, one of the biggest ever breaking changes was the fix for array stomping, but it wasn't even recognized as a breaking change! Breaking changes happen all the time, and the ones that break noisily are really not a problem. "Most D code is yet to be written."
 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"! The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia. We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes. Break our code TODAY. "Most D code is yet to be written."
Sep 24 2014
next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 24 September 2014 at 14:56:11 UTC, Don wrote:
 I agree completely. I would say that the #1 problem in D is the 
 paranoid fear of breaking backwards compatibility. I said that 
 in my 2013 talk. It is still true today.

 Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old 
 design bugs while we still can.

 For example: We agreed *years* ago to remove the NCEG 
 operators. Why haven't they been removed yet?
Yep. So long as the messaging is clear surrounding breaking changes I'm all for it. In favor of it in fact, if it makes the language better in the long term. Dealing with breakages between compiler releases simply isn't a problem if the issues are known beforehand, particularly if the old compiler can build the new style code. D isn't unique in this respect anyway. The C++ compiler our build team uses at work is sufficiently old that it can't compile certain parts of Boost, for example. We've been pushing to get a newer compiler in place, and that comes hand in hand with code changes. But we *want* the breaking change because it actually solves problems we have with the current compiler iteration. Similarly, I want breaking changes in D if they solve problems I have with the way things currently work. I kind of feel like D is stuck in prototype mode. As in, you demo a prototype, people like what they see and say "ship it", and rather than take the time to make the real thing you *do* ship it and then immediately start working on new features, forever sticking yourself with all the warts you'd glossed over during the demo. In this case we were prototyping new features to ourselves, but the same idea applies.
Sep 24 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 24 September 2014 at 14:56:11 UTC, Don wrote:
 I agree completely. I would say that the #1 problem in D is the 
 paranoid fear of breaking backwards compatibility. I said that 
 in my 2013 talk. It is still true today.

 Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old 
 design bugs while we still can.

 For example: We agreed *years* ago to remove the NCEG 
 operators. Why haven't they been removed yet?

 As I said earlier in the year, one of the biggest ever breaking 
 changes was the fix for array stomping, but it wasn't even 
 recognized as a breaking change!
 Breaking changes happen all the time, and the ones that break 
 noisily are really not a problem.

 "Most D code is yet to be written."

 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"! The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia. We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes. Break our code TODAY. "Most D code is yet to be written."
As the CTO of a company having the main selling products "powered by D", I totally agree with Don: break our code TODAY. We are aiding ALS impaired people to have a better life with D products, so I can tell that we definitely care about SW quality... But a planned breaking change, that improves the language overall, will always be welcomed here in SR Labs. --- /Paolo
Sep 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Don:

 I agree completely. I would say that the #1 problem in D is the 
 paranoid fear of breaking backwards compatibility. I said that 
 in my 2013 talk. It is still true today.

 Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old 
 design bugs while we still can.
I keep a large amount of working D2 code, mostly for scientific-like usages (plus other code outside work, like almost one thousand of Rosettacode programs, a lot of lines of very carefully written good code). Most of such code is divided in many small programs. I have plenty of unittests and I also use contract programming. A planned breaking change, if it gives clear and nice error messages, allows me to fix the whole code base in a limited amount of time (1 hour, or 2 hours or a little more), and often it's an easy work that I can do late in the day when I am too tired to do more intelligent work anyway. Compared to the work to understand the problems, invent the problems, invent the solutions, and write working code, the amount of brain time & work to keep code updated is not significant for me. So I suggest to deprecate the built-in sort, deprecate other things that are waiting for it since some time, do the other language updates that you think are good. Bye, bearophile
Sep 24 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 14:56:10 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "Most D code is yet to be written."
and it will be wrtitten in a language with heavy legacy. it's the same thing as with c++ interop: pleasing imaginary future users at the expense for current users. even small changes that either breaks something or even adds a more sane/more consistent way to do some small thing without breaking the old way have virtually no chances to get into mainline. see, for example, function attributes. neither patch that allows to use ' ' in front of "pure" and "nothrow" nor patch that allows to omit " " for " safe", " trusted" and so on was "blessed". they were destroyed almost immediately: "it's not hard to type that ' '", "there is nothing wrong in such inconsistent syntax", "newcomers will be confused by having two syntaxes" (as if they are not confused now, failing to understand why some of the attributes requires " ", and some can't be used with " "!). or 'const' function attribute, which, i believe, should be forbidden as prefix attribute. i.e. 'const A foo ()' should be compilation error. or having no way to cancel "final:" and "static:" (this annoys me virtually each time i'm writing some complex structs/classes). and so on. i'd say "change this while we can!" but no, imaginary future users will be dissatisfied.
Sep 24 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Wednesday, 24 September 2014 at 21:53:34 UTC, ketmar via 
Digitalmars-d wrote:
 On Wed, 24 Sep 2014 14:56:10 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 almost immediately: "it's not hard to type that ' '",
Actually, on the French keyboard, it is. The '\' too.
Sep 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 21:59:08 +0000
eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 almost immediately: "it's not hard to type that ' '",
Actually, on the French keyboard, it is. The '\' too.
and i'm for adding more " "... sorry to all French people. ;-)
Sep 24 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 September 2014 00:56, Don via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 24 September 2014 at 07:43:49 UTC, Walter Bright wrote:
 On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
 1. Constant rejection of improvements because "OMG breaking change!".
 Meanwhile, D has been breaking my code on practically every release
 for years. I don't get this, reject changes that are deliberately
 breaking changes which would make significant improvements, but allow
 breaking changes anyway because they are bug fixes? If the release
 breaks code, then accept that fact and make some real proper breaking
 changes that make D substantially better! It is my opinion that D
 adopters don't adopt D because it's perfect just how it is and they
 don't want it to improve with time, they adopt D *because they want it
 to improve with time*! That implies an acceptance (even a welcoming)
 of breaking changes.
I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today. Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can. For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? As I said earlier in the year, one of the biggest ever breaking changes was the fix for array stomping, but it wasn't even recognized as a breaking change! Breaking changes happen all the time, and the ones that break noisily are really not a problem. "Most D code is yet to be written."
 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"! The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia. We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes. Break our code TODAY. "Most D code is yet to be written."
Oh good, I'm glad you're reading! :) This was our unanimous feeling at Remedy too. I think all D users want to see the language become clean, tidy and uniform.
Sep 24 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 7:56 AM, Don wrote:
 For example: We agreed *years* ago to remove the NCEG operators. Why haven't
 they been removed yet?
They do generate a warning if compiled with -w.
 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"!
It would be helpful having a list of what breaking changes you had in mind.
Sep 24 2014
next sibling parent reply "Don" <x nospam.com> writes:
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright 
wrote:
 On 9/24/2014 7:56 AM, Don wrote:
 For example: We agreed *years* ago to remove the NCEG 
 operators. Why haven't
 they been removed yet?
They do generate a warning if compiled with -w.
They should be gone completely. So should built-in sort. I think there's something important that you haven't grasped yet. It was something I didn't really appreciate before working here. ** Keeping deprecated features alive is expensive. ** As long as deprecated features still exist, they impose a cost. Not just on the language maintainers, but also on the users. On anyone writing a language parser - so for example on text editors. On anyone training new employees. And there's a little cognitive burden on all language users.
 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"!
It would be helpful having a list of what breaking changes you had in mind.
C-style declarations. Builtin sort and reverse. NCEG operators. Built-in complex types. float.min. property. Basically, anything where it has been decided that it should be removed. Some of these things have been hanging around for six years. I'd also like to see us getting rid of those warts like assert(float.nan) being true. And adding a in front of pure, nothrow. Ask yourself, if D had no users other than you, so that you break *anything*, what would you remove? Make a wishlist, and then find out what's possible. Remember, when you did that before, we successfully got rid of 'bit', and there was practically no complaint. Any breaking change where it fails to compile, and where there's an essentially mechanical solution, are really not a problem. Subtle changes in semantics are the ones that are disastrous. We want to pay the one-off cost of fixing our code, so that we can get the long term return-on-investment of a cleaner language.
Sep 25 2014
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 25 Sep 2014 11:08:23 +0000
schrieb "Don" <x nospam.com>:

 They should be gone completely. So should built-in sort.
 I think there's something important that you haven't grasped yet. 
 It was something I didn't really appreciate before working here.
 
   ** Keeping deprecated features alive is expensive. **
 
 As long as deprecated features still exist, they impose a cost. 
 Not just on the language maintainers, but also on the users. On 
 anyone writing a language parser - so for example on text 
 editors. On anyone training new employees.
This reminds me of a conversation on stackoverflow: http://stackoverflow.com/a/25864699
 However, note that the built-in .sort property/function is on its way
 to being deprecated. Please use std.algorithm.sort instead, which
 shouldn't have this issue.
 I was aiming for std.algorithm.sort, I didn't realize there is a
 built-in one...
Sep 25 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 4:08 AM, Don wrote:
 C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
 complex types. float.min.  property.
That's a good list I agree with. FWIW I'm glad no random name changes. I've recently used Rust a bit and the curse of D users as of 6-7 years ago reached me: most code I download online doesn't compile for obscure reasons, it's nigh impossible to figure out what the fix is from the compiler error message, searching online finds outdated documentation that tells me the code should work, and often it's random name changes (from_iterator to from_iter and such, or names are moved from one namespace to another). For the stuff we eliminate we should provide good error messages that recommend the respective idiomatic solutions. Andrei
Sep 25 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 6:49 AM, Andrei Alexandrescu wrote:
 FWIW I'm glad no random name changes. I've
 recently used Rust a bit and the curse of D users as of 6-7 years ago reached
 me: most code I download online doesn't compile for obscure reasons, it's nigh
 impossible to figure out what the fix is from the compiler error message,
 searching online finds outdated documentation that tells me the code should
 work, and often it's random name changes (from_iterator to from_iter and such,
 or names are moved from one namespace to another).
The name changes cause much disruption and are ultimately pointless changes.
 For the stuff we eliminate we should provide good error messages that recommend
 the respective idiomatic solutions.
That's normal practice already.
Sep 25 2014
prev sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei 
Alexandrescu wrote:
 I've recently used Rust a bit and the curse of D users as of 
 6-7 years ago reached me: most code I download online doesn't 
 compile for obscure reasons, it's nigh impossible to figure out 
 what the fix is from the compiler error message, searching 
 online finds outdated documentation that tells me the code 
 should work, and often it's random name changes (from_iterator 
 to from_iter and such, or names are moved from one namespace to 
 another).
That's more than a bit unfair. Rust's developers have made it abundantly clear that things will keep changing until version 1.0. If you want to play with some Rust that's guaranteed to work, go to http://www.rust-ci.org and find a bit code that interests you which isn't failing, and then download the nightly. The docs on the Rust home page are either for a fixed version (0.11.0) or the nightly. Let's wait for a bit of time after 1.0 is out before you critique the annoying changes; they deliberately are developing in the open to get community input and avoid getting stuck with too many mistakes (though it looks like they are stuck with C++ template syntax, ugh!). So far, I haven't found it too hard to update code, and they've been good at marking breaking changes as breaking changes, which can be searched for with git. In the case of D, the main D2 book was published 4 years ago and that should correspond to Rust 1.0 or even later, since D already had a D1 to shake out the mistakes and bad namings. That's gone perfectly, with no code breakage between releases during those four years, right?
Sep 25 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 4:07 PM, Brian Rogoff wrote:
 On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei Alexandrescu wrote:
 I've recently used Rust a bit and the curse of D users as of 6-7 years
 ago reached me: most code I download online doesn't compile for
 obscure reasons, it's nigh impossible to figure out what the fix is
 from the compiler error message, searching online finds outdated
 documentation that tells me the code should work, and often it's
 random name changes (from_iterator to from_iter and such, or names are
 moved from one namespace to another).
That's more than a bit unfair.
This is not about fairness. -- Andrei
Sep 25 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 4:08 AM, Don wrote:
 [...]
I agree with Andrei, it's a good list. I'll move these issues to the next step in the removal process.
 I'd also like to see us getting rid of those warts like assert(float.nan) being
 true.
See discussion: https://issues.dlang.org/show_bug.cgi?id=13489
 Ask yourself, if D had no users other than you, so that you break *anything*,
 what would you remove? Make a wishlist, and then find out what's possible.
 Remember, when you did that before, we successfully got rid of 'bit', and there
 was practically no complaint.
Top of my list would be the auto-decoding behavior of std.array.front() on character arrays. Every time I'm faced with that I want to throw a chair through the window. Probably second would be having const and purity by default.
Sep 25 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/25/2014 4:08 AM, Don wrote:
[...]
Ask yourself, if D had no users other than you, so that you break
*anything*, what would you remove? Make a wishlist, and then find out
what's possible.  Remember, when you did that before, we successfully
got rid of 'bit', and there was practically no complaint.
Top of my list would be the auto-decoding behavior of std.array.front() on character arrays. Every time I'm faced with that I want to throw a chair through the window.
LOL... now I'm genuinely curious what's Andrei's comment on this. :-P Last I heard, Andrei was against removing autodecoding.
 Probably second would be having const and purity by default.
Some of this could be mitigated if we expanded the sphere of attribute inference. I know people hated the idea of auto == infer attributes, but I personally support it. Perhaps an alternate route to that is to introduce a auto (or whatever you wanna call it, infer, or whatever) and promote its use in D code, then slowly phase out functions not marked with infer. After a certain point, infer will become the default, and explicit infer's will become no-op, and then subsequently dropped. This is very ugly, though. I much prefer extending auto to mean infer. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
Sep 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d
wrote:
 On 9/25/2014 4:08 AM, Don wrote:
[...]
 Ask yourself, if D had no users other than you, so that you break
 *anything*, what would you remove? Make a wishlist, and then find out
 what's possible.  Remember, when you did that before, we successfully
 got rid of 'bit', and there was practically no complaint.
Top of my list would be the auto-decoding behavior of std.array.front() on character arrays. Every time I'm faced with that I want to throw a chair through the window.
LOL... now I'm genuinely curious what's Andrei's comment on this. :-P Last I heard, Andrei was against removing autodecoding.
I have yet to completely convince Andrei that autodecoding is a bad idea :-(
Sep 25 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright 
wrote:
 On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 On 9/25/2014 4:08 AM, Don wrote:
[...]
 Ask yourself, if D had no users other than you, so that you 
 break
 *anything*, what would you remove? Make a wishlist, and then 
 find out
 what's possible.  Remember, when you did that before, we 
 successfully
 got rid of 'bit', and there was practically no complaint.
Top of my list would be the auto-decoding behavior of std.array.front() on character arrays. Every time I'm faced with that I want to throw a chair through the window.
LOL... now I'm genuinely curious what's Andrei's comment on this. :-P Last I heard, Andrei was against removing autodecoding.
I have yet to completely convince Andrei that autodecoding is a bad idea :-(
I think it should just refuse to work on char[], wchar[] and dchar[]. Instead, byCodeUnit, byCodePoint (which already exist) would be required. This way, users would need to make a conscious decision, and there would be no surprises and no negative performance impact.
Sep 25 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 09:19:29PM +0000, via Digitalmars-d wrote:
 On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright wrote:
[...]
I have yet to completely convince Andrei that autodecoding is a bad
idea :-(
It certainly represents a runtime overhead, which may be non-negligible depending on your particular use case, and despite oft stated benefits of being Unicode-aware by default (well, not 100%), I think the cost of maintaining special-casing for narrow strings is starting to show up in the uglification of Phobos range-based code. Ranges were supposed to help with writing cleaner, more generic code, but I've been observing a trend of special-casing in order to reduce the autodecoding overhead in string handling, which somewhat reduces the cleanness of otherwise fully-generic code. This complexity has led to string-related bugs, and definitely has a cost on the readability (and, consequently, maintainability) of Phobos code. Special cases hurt generic code. It's not just about performance.
 I think it should just refuse to work on char[], wchar[] and dchar[].
 Instead, byCodeUnit, byCodePoint (which already exist) would be
 required.  This way, users would need to make a conscious decision,
 and there would be no surprises and no negative performance impact.
Not a bad idea. If we do it right, we could (mostly) avoid user outrage. E.g., start with a "soft deprecation" (a compile-time message, but not an actual warning, to the effect that byCodeUnit / byCodePoint should be used with strings from now on), then a warning, then an actual deprecation, then remove autodecoding code from Phobos algorithms (leaving only byCodePoint for those who still want autodecoding). T -- Two wrongs don't make a right; but three rights do make a left...
Sep 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 2:47 PM, H. S. Teoh via Digitalmars-d wrote:
 Not a bad idea. If we do it right, we could (mostly) avoid user outrage.
 E.g., start with a "soft deprecation" (a compile-time message, but not
 an actual warning, to the effect that byCodeUnit / byCodePoint should be
 used with strings from now on), then a warning, then an actual
 deprecation, then remove autodecoding code from Phobos algorithms
 (leaving only byCodePoint for those who still want autodecoding).
Consider this PR: https://github.com/D-Programming-Language/phobos/pull/2423 which is blocked because several people do not agree with using byCodeunit.
Sep 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 8:11 PM, Walter Bright wrote:
 Consider this PR:

 https://github.com/D-Programming-Language/phobos/pull/2423

 which is blocked because several people do not agree with using byCodeunit.
I should add that this impasse has COMPLETELY stalled changes to Phobos to remove dependency on the GC.
Sep 25 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 8:17 PM, Walter Bright wrote:
 On 9/25/2014 8:11 PM, Walter Bright wrote:
 Consider this PR:

 https://github.com/D-Programming-Language/phobos/pull/2423

 which is blocked because several people do not agree with using
 byCodeunit.
I should add that this impasse has COMPLETELY stalled changes to Phobos to remove dependency on the GC.
I think the way to break that stalemate is to add RC strings and reference counted exceptions. -- Andrei
Sep 25 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 08:44:23PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 9/25/14, 8:17 PM, Walter Bright wrote:
On 9/25/2014 8:11 PM, Walter Bright wrote:
Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using
byCodeunit.
I should add that this impasse has COMPLETELY stalled changes to Phobos to remove dependency on the GC.
I think the way to break that stalemate is to add RC strings and reference counted exceptions. -- Andrei
But it does nothing to bring us closer to a decision about the autodecoding issue. T -- Heads I win, tails you lose.
Sep 25 2014
prev sibling parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 03:44:23 UTC, Andrei Alexandrescu 
wrote:
 I think the way to break that stalemate is to add RC strings 
 and reference counted exceptions. -- Andrei
I dont want gc, exceptions or rc strings. You really need to make sure rc is optional throughout. RC inc/dec abort read-transactions. That's a bad long term strategy.
Sep 25 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m02lt5$2hg4$1 digitalmars.com...

 I should add that this impasse has COMPLETELY stalled changes to Phobos to 
 remove dependency on the GC.
Maybe it would be more successful if it didn't try to do both at once.
Sep 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 9:12 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m02lt5$2hg4$1 digitalmars.com...

 I should add that this impasse has COMPLETELY stalled changes to Phobos to
 remove dependency on the GC.
Maybe it would be more successful if it didn't try to do both at once.
What would the 3rd version of setExtension be named, then?
Sep 25 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m02qcm$2mmn$1 digitalmars.com...

 On 9/25/2014 9:12 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m02lt5$2hg4$1 digitalmars.com...

 I should add that this impasse has COMPLETELY stalled changes to Phobos
to
 remove dependency on the GC.
Maybe it would be more successful if it didn't try to do both at once.
What would the 3rd version of setExtension be named, then?
setExtension. Making up new clever names for functions that do the same thing with different types is a burden for the users.
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 9:38 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m02qcm$2mmn$1 digitalmars.com...
 What would the 3rd version of setExtension be named, then?
setExtension. Making up new clever names for functions that do the same thing with different types is a burden for the users.
The behavior would be different, although the types are the same.
Sep 26 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 09:34:30PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/25/2014 9:12 PM, Daniel Murphy wrote:
"Walter Bright"  wrote in message news:m02lt5$2hg4$1 digitalmars.com...

I should add that this impasse has COMPLETELY stalled changes to
Phobos to remove dependency on the GC.
Maybe it would be more successful if it didn't try to do both at once.
What would the 3rd version of setExtension be named, then?
I think that PR, and the others slated to follow it, should just merge with autodecoding in conformance to the rest of Phobos right now, independently of however the decision on the autodecoding issue will turn out. If we do decide eventually to get rid of autodecoding, we're gonna have to rewrite much of Phobos anyway, so it's not as though merging PRs now is going to make it significantly worse. I don't see why the entire burden of deciding upon autodecoding should rest upon a PR that merely introduces a new string function. T -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn
Sep 25 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 25, 2014 at 08:11:02PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/25/2014 2:47 PM, H. S. Teoh via Digitalmars-d wrote:
Not a bad idea. If we do it right, we could (mostly) avoid user
outrage.  E.g., start with a "soft deprecation" (a compile-time
message, but not an actual warning, to the effect that byCodeUnit /
byCodePoint should be used with strings from now on), then a warning,
then an actual deprecation, then remove autodecoding code from Phobos
algorithms (leaving only byCodePoint for those who still want
autodecoding).
Consider this PR: https://github.com/D-Programming-Language/phobos/pull/2423 which is blocked because several people do not agree with using byCodeunit.
Actually, several committers have already agreed that this particular PR shouldn't be blocked pending the decision whether to autodecode or not. What's actually blocking it right now, is that it calls stripExtension, which only works with arrays, not general ranges. (Speaking of which, thanks for reminding me that I need to work on that. :-P) T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 9:04 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 25, 2014 at 08:11:02PM -0700, Walter Bright via Digitalmars-d
wrote:
 Consider this PR:

 https://github.com/D-Programming-Language/phobos/pull/2423

 which is blocked because several people do not agree with using
 byCodeunit.
Actually, several committers have already agreed that this particular PR shouldn't be blocked pending the decision whether to autodecode or not. What's actually blocking it right now, is that it calls stripExtension, which only works with arrays, not general ranges. (Speaking of which, thanks for reminding me that I need to work on that. :-P)
It's blocked because of the autodecode issue. Don't want to need a THIRD setExtension algorithm because this one isn't done correctly.
Sep 25 2014
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 It's not just about performance.
Something I recently realized: because of auto-decoding, std.algorithm.find("foo", 'o') cannot be implemented using memchr. I think this points to a huge design fail, performance-wise. There are also subtle correctness problems: haystack[0..haystack.countUntil(needle)] is wrong, even if it works right on ASCII input. For once I agree with Walter Bright - regarding the chair throwing :)
Sep 25 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 04:05:18AM +0000, Vladimir Panteleev via Digitalmars-d
wrote:
 On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via Digitalmars-d
 wrote:
It's not just about performance.
Something I recently realized: because of auto-decoding, std.algorithm.find("foo", 'o') cannot be implemented using memchr. I think this points to a huge design fail, performance-wise.
Well, if you really want to talk performance, we've already failed. Any string operation that starts from a narrow string and ends with a narrow string (of the same width) will incur the overhead of decoding / reencoding *every single character*, even if it's mostly redundant. What bugs me even more is the fact that every single Phobos algorithm that might conceivably deal with characters has to be special-cased for narrow string in order to be performant. That's a mighty high price to pay for what's a relatively small benefit -- note that autodecoding does *not* guarantee Unicode correctness, even if, according to the argument of some, it helps. So we're paying a high price in terms of performance and code maintainability in Phobos, for the dubious benefit of only partial Unicode conformance.
 There are also subtle correctness problems:
 haystack[0..haystack.countUntil(needle)] is wrong, even if it works
 right on ASCII input.
 
 For once I agree with Walter Bright - regarding the chair throwing :)
Not to mention that autodecoding *still* doesn't fix the following problem: assert("á".canFind("á")); // fails (Note: you may need to save this message verbatim and edit it into a D source file to see this effect; cut-n-paste on some systems may erase the effect.) And the only way to fix this would be so prohibitively expensive, I don't think even Andrei would agree to it. :-P So basically, we're paying (1) lower performance, (2) non-random access for strings, (3) subtle distinction between index and count and other such gotchas, and (4) tons of special-cased Phobos code with the associated maintenance costs, all for incomplete Unicode correctness. Doesn't seem like the benefit measures up to the cost. :-( T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Sep 25 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 So basically, we're paying (1) lower performance, (2)  
 non-random access
 for strings, (3) subtle distinction between index and count and 
 other
 such gotchas, and (4) tons of special-cased Phobos code with the
 associated maintenance costs, all for incomplete Unicode 
 correctness.
 Doesn't seem like the benefit measures up to the cost. :-(
Yep. When I use algorithms on strings in D, I always cast them to ubyte[]. Which is a poor solution.
Sep 26 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Sean Kelly:

 When I use algorithms on strings in D, I always cast them to 
 ubyte[].  Which is a poor solution.
In Phobos we have "representation", and "assumeUTF" that are better than naked casts. I use them only sparingly (and I avoid cast), despite I use strings often. Bye, bearophile
Sep 26 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 6:55 AM, Sean Kelly wrote:
 On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via Digitalmars-d
wrote:
 So basically, we're paying (1) lower performance, (2) non-random access
 for strings, (3) subtle distinction between index and count and other
 such gotchas, and (4) tons of special-cased Phobos code with the
 associated maintenance costs, all for incomplete Unicode correctness.
 Doesn't seem like the benefit measures up to the cost. :-(
Yep. When I use algorithms on strings in D, I always cast them to ubyte[]. Which is a poor solution.
Now you can use the adapters .byCodeUnit or .byChar instead.
Sep 26 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:
 On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
 Digitalmars-d wrote:
 It's not just about performance.
Something I recently realized: because of auto-decoding, std.algorithm.find("foo", 'o') cannot be implemented using memchr.
Why not? -- Andrei
Sep 25 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 26 September 2014 at 05:02:08 UTC, Andrei Alexandrescu 
wrote:
 On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:
 On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
 Digitalmars-d wrote:
 It's not just about performance.
Something I recently realized: because of auto-decoding, std.algorithm.find("foo", 'o') cannot be implemented using memchr.
Why not? -- Andrei
Sorry, got mixed up. countUntil can't, find can (but because one's counting code points, they can't be implemented on top of each other, even for arrays).
Sep 25 2014
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 25 Sep 2014 21:19:29 +0000
schrieb "Marc Sch=C3=BCtz" <schuetzm gmx.net>:

 I think it should just refuse to work on char[], wchar[] and=20
 dchar[]. Instead, byCodeUnit, byCodePoint (which already exist)=20
 would be required. This way, users would need to make a conscious=20
 decision, and there would be no surprises and no negative=20
 performance impact.
Hey, that was what I proposed for Rust over a year ago: https://github.com/rust-lang/rust/issues/7043#issuecomment-19187984 --=20 Marco
Oct 04 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 25/09/14 13:08, Don wrote:

 C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
 complex types. float.min.  property.
Let me add: base class protection. It's deprecated but not completely removed. I have never seen base class protection being used in practice. -- /Jacob Carlborg
Sep 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 4:08 AM, Don wrote:
 I'd also like to see us getting rid of those warts like assert(float.nan) being
 true.
https://issues.dlang.org/show_bug.cgi?id=13489 It has some serious issues with it - I suspect it'll cause uglier problems than it fixes.
 And adding a   in front of pure, nothrow.
https://issues.dlang.org/show_bug.cgi?id=13388 It has generated considerable discussion.
Oct 08 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 9 October 2014 at 00:30:53 UTC, Walter Bright wrote:
 On 9/25/2014 4:08 AM, Don wrote:

 And adding a   in front of pure, nothrow.
https://issues.dlang.org/show_bug.cgi?id=13388 It has generated considerable discussion.
Please break the language, now. --- /Paolo
Oct 08 2014
prev sibling parent "ixid" <nuaccount gmail.com> writes:
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright 
wrote:
 On 9/24/2014 7:56 AM, Don wrote:
 For example: We agreed *years* ago to remove the NCEG 
 operators. Why haven't
 they been removed yet?
They do generate a warning if compiled with -w.
 What change in particular?
I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"!
It would be helpful having a list of what breaking changes you had in mind.
Perhaps it would be a good idea to have a themed update? Currently you and Andrei are busy with the C++ changes, when that is settling down maybe the community could focus on a cleaning house update. With clear update themes (which does not preclude the usual mixture of things also going on) people can air issues and get it ye or nay'd clearly. Combining the previously discussed auto-update code tool with a set of breaking changes would make sense.
Oct 06 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 September 2014 17:43, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
 1. Constant rejection of improvements because "OMG breaking change!".
 Meanwhile, D has been breaking my code on practically every release
 for years. I don't get this, reject changes that are deliberately
 breaking changes which would make significant improvements, but allow
 breaking changes anyway because they are bug fixes? If the release
 breaks code, then accept that fact and make some real proper breaking
 changes that make D substantially better! It is my opinion that D
 adopters don't adopt D because it's perfect just how it is and they
 don't want it to improve with time, they adopt D *because they want it
 to improve with time*! That implies an acceptance (even a welcoming)
 of breaking changes.
What change in particular?
The instances this has been used as a defence are innumerable. Perhaps the one that's closest to me was that time when I spent months arguing final-by-default, won unanimous support of the community, you approved it, patch written, LGTM, merged, then Andrei appeared with "When did this happen? I never would have agreed to this! Revert it immediately!" (which apparently he has the authority to do, but that's a separate matter). He later said that "if it were that way from the start, I agree it should have been that way". It was reverted because breaking change, despite that it was an established fact that with virtual-by-default, any effort to optimise a library is also a breaking change and a major version increment. Most D code is yet to be written. We reject a single breaking change now, and by doing so, commit to endless breaking changes in the future. Of course, there are many more. Things like C-style arrays should be removed, property looks like it will never be finished/fixed. I expect changes to 'ref' will probably receive this same defence. I'm sure everybody here can add extensively to this list. Phobos is full of things that should be tidied up.
 2. Tooling is still insufficient. I use Visual Studio, and while
 VisualD is good, it's not great. Like almost all tooling projects,
 there is only one contributor, and I think this trend presents huge
 friction to adoption. Tooling is always factored outside of the D
 community and their perceived realm of responsibility. I'd like to see
 tooling taken into the core community and issues/bugs treated just as
 seriously as issues in the compiler/language itself.

 3. Debugging is barely ever considered important. I'd love to see a
 concerted focus on making the debug experience excellent. Iain had a
 go at GDB, I understand there is great improvement there. Sadly, we
 recently lost the developer of Mago (a Windows debugger). There's lots
 of work we could do here, and I think it's of gigantic impact.
There are 23 issues tagged with 'symdeb': https://issues.dlang.org/buglist.cgi?keywords=symdeb&list_id=109316&resolution=--- If there are more untagged ones, please tag them.
The fact there's only 23 doesn't really mean anything, they're all major usability problems. I feel like I'm back in the early 90's when trying to iterate on my D code. These issues have proven to be the most likely to send my professional friends/colleagues running upon initial contact with D. Here's some more: https://issues.dlang.org/show_bug.cgi?id=12899 https://issues.dlang.org/show_bug.cgi?id=13198 https://issues.dlang.org/show_bug.cgi?id=13213 https://issues.dlang.org/show_bug.cgi?id=13227 https://issues.dlang.org/show_bug.cgi?id=13243 https://issues.dlang.org/show_bug.cgi?id=11541 https://issues.dlang.org/show_bug.cgi?id=11549 https://issues.dlang.org/show_bug.cgi?id=11902 **** MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12163 **** MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12244 **** MASSIVE NUISANCE The last 3 make debugging of anything but the simplest D code practically impossible/pointless. Aside from that though, this somewhat leads back to my second point, which is that symdeb issues in the compiler aren't enough. It needs to be taken wholistically. Cooperation between the compiler and tooling devs need to be actively engaged to fix many of these issues.
 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years
 later, I still can't pass an rvalue->ref (been discussed endlessly),
 create a ref local, and the separation from the type system makes it a
 nightmare in generic code. This was a nuisance for me on day-1, and
 has been grinding me down endlessly for years. It has now far eclipsed
 my grudges with the GC/RC, or literally anything else about the
 language on account of frequency of occurrence; almost daily.
I have to ask why all your code revolves about this one thing?
I suspect it's because I rely on far more C++ interop than the average D user. I have half a decade of solid experience with D<->C++ interop, perhaps more than anyone else here? It's not 'all my code', but a sufficient quantity that it pops up and bites me almost every day, particularly when I try and write any meta.
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 2:44 PM, Manu via Digitalmars-d wrote:
 The fact there's only 23 doesn't really mean anything, they're all
 major usability problems.
 I feel like I'm back in the early 90's when trying to iterate on my D code.
 These issues have proven to be the most likely to send my professional
 friends/colleagues running upon initial contact with D.

 Here's some more:

 https://issues.dlang.org/show_bug.cgi?id=12899
 https://issues.dlang.org/show_bug.cgi?id=13198
 https://issues.dlang.org/show_bug.cgi?id=13213
 https://issues.dlang.org/show_bug.cgi?id=13227
 https://issues.dlang.org/show_bug.cgi?id=13243
 https://issues.dlang.org/show_bug.cgi?id=11541
 https://issues.dlang.org/show_bug.cgi?id=11549
 https://issues.dlang.org/show_bug.cgi?id=11902 **** MASSIVE NUISANCE
 https://issues.dlang.org/show_bug.cgi?id=12163 **** MASSIVE NUISANCE
 https://issues.dlang.org/show_bug.cgi?id=12244 **** MASSIVE NUISANCE
Thanks for tagging them.
 The last 3 make debugging of anything but the simplest D code
 practically impossible/pointless.


 Aside from that though, this somewhat leads back to my second point,
 which is that symdeb issues in the compiler aren't enough. It needs to
 be taken wholistically.
 Cooperation between the compiler and tooling devs need to be actively
 engaged to fix many of these issues.
I'm sorry, but this is awfully vague and contains nothing actionable.
 I suspect it's because I rely on far more C++ interop than the average
 D user. I have half a decade of solid experience with D<->C++ interop,
 perhaps more than anyone else here?
 It's not 'all my code', but a sufficient quantity that it pops up and
 bites me almost every day, particularly when I try and write any meta.
I still don't understand what use case is it that pops up every day. What are you trying to do? Why doesn't auto ref work?
Sep 24 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 September 2014 11:01, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/24/2014 2:44 PM, Manu via Digitalmars-d wrote:
 The fact there's only 23 doesn't really mean anything, they're all
 major usability problems.
 I feel like I'm back in the early 90's when trying to iterate on my D
 code.
 These issues have proven to be the most likely to send my professional
 friends/colleagues running upon initial contact with D.

 Here's some more:

 https://issues.dlang.org/show_bug.cgi?id=12899
 https://issues.dlang.org/show_bug.cgi?id=13198
 https://issues.dlang.org/show_bug.cgi?id=13213
 https://issues.dlang.org/show_bug.cgi?id=13227
 https://issues.dlang.org/show_bug.cgi?id=13243
 https://issues.dlang.org/show_bug.cgi?id=11541
 https://issues.dlang.org/show_bug.cgi?id=11549
 https://issues.dlang.org/show_bug.cgi?id=11902 **** MASSIVE NUISANCE
 https://issues.dlang.org/show_bug.cgi?id=12163 **** MASSIVE NUISANCE
 https://issues.dlang.org/show_bug.cgi?id=12244 **** MASSIVE NUISANCE
Thanks for tagging them.
 The last 3 make debugging of anything but the simplest D code
 practically impossible/pointless.


 Aside from that though, this somewhat leads back to my second point,
 which is that symdeb issues in the compiler aren't enough. It needs to
 be taken wholistically.
 Cooperation between the compiler and tooling devs need to be actively
 engaged to fix many of these issues.
I'm sorry, but this is awfully vague and contains nothing actionable.
The action I'd love to see would be "Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished" ;) I recognise that is probably unrealistic, because it seems so few people even use symbolic debuggers at all, that we have very few people interested in working on it. I don't really have a practical solution, but the post topic is 'the worst parts of D', and for me, this definitely rates very high :) An excellent action would be to implement proper scoping in the debuginfo, that would fix cursor movement while stepping, differently scoped local's with the same names causing havoc. And also classes not working. Those are some big tickets from the language side responsible for the most trouble.
 I suspect it's because I rely on far more C++ interop than the average
 D user. I have half a decade of solid experience with D<->C++ interop,
 perhaps more than anyone else here?
 It's not 'all my code', but a sufficient quantity that it pops up and
 bites me almost every day, particularly when I try and write any meta.
I still don't understand what use case is it that pops up every day. What are you trying to do? Why doesn't auto ref work?
auto ref makes a reference out of int and float. There are all manner of primitive types and very small structs that shouldn't be ref, and auto ref can't possibly know. auto ref has never to date produced the semantics that I have wanted. If ref is part of the type, it flows through templates neatly, it is also possible to use app-specific logic to decide if something should be ref or not, and then give that argument without static if and duplication of entire functions, or text mixin.
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote:
 I'm sorry, but this is awfully vague and contains nothing actionable.
The action I'd love to see would be "Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished" ;)
I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them. Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-)
 I recognise that is probably unrealistic, because it seems so few
 people even use symbolic debuggers at all, that we have very few
 people interested in working on it.
You kinda put your finger on what the real issue is. Note that I find gdb well nigh unusable even for C++ code, so to me an unusable debugger is pretty normal and I don't think much about it. :-) It doesn't impair my debugging sessions much. I've also found that the more high level abstractions are used, the less useful a symbolic debugger is. Symbolic debuggers are only good for pedestrian, low level code that ironically is also what other methods are very good at, too.
 I don't really have a practical solution, but the post topic is 'the
 worst parts of D', and for me, this definitely rates very high :)
No prob. The initiating post was an invitation to a wine festival, and that's what we have :-)
 I still don't understand what use case is it that pops up every day. What
 are you trying to do? Why doesn't auto ref work?
auto ref makes a reference out of int and float. There are all manner of primitive types and very small structs that shouldn't be ref,
Why not? What does it harm? And with inlining, pointless refs should be optimized away.
 and auto ref can't possibly know.
Can't know what?
 auto ref has never to date produced the semantics that I have wanted.
Please be more specific about what and why.
 If ref is part of the type, it flows through templates neatly, it is
 also possible to use app-specific logic to decide if something should
 be ref or not, and then give that argument without static if and
 duplication of entire functions, or text mixin.
It seems you are very focused on very low level details. Not knowing specifically what and why you're focused on ref/value, I suggest the possibility of taking a larger view, focus more on algorithms, and rely on the inliner more. Take a look at the asm code generated now and then and see if your worries are justified.
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 08:55:23PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote:
I'm sorry, but this is awfully vague and contains nothing
actionable.
The action I'd love to see would be "Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished" ;)
I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them. Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-)
Yeah, this is characteristic of free software. If this were proprietary software like what I write at work, the PTBs would just set down items X, Y, Z as their mandate, and everyone would have to work on it, like it or not. With free software, however, if something isn't getting done, you just gotta get your hands dirty and do it yourself. Surprisingly, many times what comes out can be superior to the cruft churned out by "enterprise" programmers who were forced to write something they didn't really want to. [...]
 Note that I find gdb well nigh unusable even for C++ code, so to me an
 unusable debugger is pretty normal and I don't think much about it.
 :-) It doesn't impair my debugging sessions much.
printf debugging FTW! :-P
 I've also found that the more high level abstractions are used, the
 less useful a symbolic debugger is. Symbolic debuggers are only good
 for pedestrian, low level code that ironically is also what other
 methods are very good at, too.
[...] I don't agree with that. I think symbolic debuggers should be improved so that they *can* become useful with high level abstractions. For example, if debuggers could be made to understand templates and compile-time constants, they could become much more useful than they are today in debugging high-level code. For example, the idea of stepping through lines of code (i.e. individual statements) is a convenient simplification, but really, in modern programming languages there are multiple levels of semantics that could have a meaningful concept of "stepping forward/backward". You could step through individual expressions or subexpressions, step over function calls whose return values are passed to an enclosing function call, or step through individual arithmetic operations in a subexpression. Each of these levels of stepping could be useful in certain contexts, depending on what kind of bug you're trying to track down. Sometimes having statements as the stepping unit is too coarse-grained for certain debugging operations. Sometimes they are too fine-grained for high levels of abstractions. Ideally, there should be a way for the debugger to dissect your code into its constituent parts, at various levels of expression, for example: statement: [main.d:123] auto x = f(x,y/2,z) + z*2; ==> variable allocation: [hoisted to beginning of function] ==> evaluate expression: f(x,y/2,z) + z*2 ==> evaluate expression: f(x,y/2,z) ==> evaluate expression: x ==> load x ==> evaluate expression: y/2 ==> load y: [already in register eax] ==> load 2: [part of operation: /] ==> arithmetic operation: / ==> evaluate expression: z ==> function call: f ==> evaluate expression: z*2 ==> load z: [already in register ebx] ==> load 2: [optimized away] ==> arithmetic operation: / [optimized to z<<1] ==> evaluate sum ==> expression result: [in register edx] ==> assign expression to x ==> store x The user can choose which level of detail to zoom into, and the debugger would allow stepping through each operation at the selected level of detail (provided it hasn't been optimized away -- if it did, ideally the debugger would tell you what the optimized equivalent is). T -- Public parking: euphemism for paid parking. -- Flora
Sep 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
 printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation.
 I don't agree with that. I think symbolic debuggers should be improved
 so that they *can* become useful with high level abstractions. For
 example, if debuggers could be made to understand templates and
 compile-time constants, they could become much more useful than they are
 today in debugging high-level code.
The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code.
Sep 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 24, 2014 at 10:30:49PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation.
gdb does allow calling your program's functions out-of-band in 'print'. I've used that before when debugging C++, which is a pain when lots of templates are involved (almost every source line is demangled into an unreadable glob of <> gibberish 15 lines long). Wrote a pretty-printing free function in my program, and used `print pretty_print(my_obj)` from gdb. Worked wonders! Having said that, though, I'm still very much a printf/writeln-debugging person. It also has the benefit of working in adverse environments like embedded devices where the runtime environment doesn't let you run gdb.
I don't agree with that. I think symbolic debuggers should be
improved so that they *can* become useful with high level
abstractions. For example, if debuggers could be made to understand
templates and compile-time constants, they could become much more
useful than they are today in debugging high-level code.
The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code.
When all else fails, I just disassemble the code and trace it along side-by-side with the source code. Not only it's a good exercise in keeping my assembly skills sharp, you also get to see all kinds of tricks that optimizers nowadays can do in action. Code hoisting, rearranging, register assignments to eliminate subsequent loads, vectorizing, etc.. Fun stuff. Not to mention the thrill when you finally identify the cause of the segfault by successfully mapping that specific instruction to a specific construct in the source code -- not a small achievement in this day and age of optimizing compilers and pipelining, microcode CPUs! Nevertheless, I think there is still room for debuggers to improve. Recently, for example, I learned that gdb has acquired the ability to step through a program backwards. Just missed the point in your program where the problem first happened? No problem, just step backwards until you get back to that point! Neat stuff. (How this is implemented is left as an exercise for the reader. :-P) T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Sep 24 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2014 07:22, H. S. Teoh via Digitalmars-d wrote:
 Nevertheless, I think there is still room for debuggers to improve.
 Recently, for example, I learned that gdb has acquired the ability to
 step through a program backwards. Just missed the point in your program
 where the problem first happened? No problem, just step backwards until
 you get back to that point! Neat stuff. (How this is implemented is left
 as an exercise for the reader. :-P)
IIRC, that was only implemented for a few architectures, and none of them where the PC architectures. (Rather it was used a lot for embedded targets architectures, for which GDB is used a lot as well) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Oct 02 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 23:22:56 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 gdb does allow calling your program's functions out-of-band in
 'print'.
it's handy. what else handy is "quake-like" embedded console. i'm using that in my c software alot (i can connect to some port using telnet, inspect and change vars, call functions, etc). and when i decided to go with D, the first thing i tried to write was my "command console" subsystem. and it was a great pleasure with all that compile-time introspection, i must say. some annoyances here and there, but it's nothing compared to huge pile of error-prone C macro magic.
Sep 25 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 24 Sep 2014 22:30:49 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 There's more than that, but yeah. Most of my types I'll write a
 "pretty printer" for, and use that. No conceivable debugger can guess
 how I want to view my data.
You can call functions with GDB, but I guess you haven't used GDB much. Breakpoint 1, D main () at main.d:5 (gdb) print a $1 = (ABCD &) 0x7ffff7ebfff0: {<Object> = {__vptr = 0x4b8c60 <main.ABCD.vtbl$>, __monitor = 0x0}, <No data fields>} (gdb) print a.toString() $2 = "Hello World!"
Sep 25 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 07:30, Walter Bright wrote:

 There's more than that, but yeah. Most of my types I'll write a "pretty
 printer" for, and use that. No conceivable debugger can guess how I want
 to view my data.
With LLDB you can implement your own custom formatters [1]. For example, in Xcode, Apple have added for Objective-C a formatter for NSImage. Within Xcode you can hover a variable of the type NSImage and it will show a small window with the image rendered. Perhaps it's time to look at some modern alternatives and not be stuck with GDB ;) [1] http://lldb.llvm.org/varformats.html -- /Jacob Carlborg
Sep 25 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 25 September 2014 at 13:31:24 UTC, Jacob Carlborg 
wrote:
 Perhaps it's time to look at some modern alternatives and not 
 be stuck with GDB ;)
I might look at the "modern alternative" once it supports debugging 64-bit executables. :/ -Wyatt
Sep 25 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-25 16:01, Wyatt wrote:

 I might look at the "modern alternative" once it supports debugging
 64-bit executables. :/
LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of these platforms [1]. Are you looking for Windows support? [1] http://lldb.llvm.org/ -- /Jacob Carlborg
Sep 25 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 25 September 2014 at 17:44:49 UTC, Jacob Carlborg 
wrote:
 LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of 
 these platforms [1].
It mentioned only 32-bit ELF on the "About" page. Since that matches with what was previously the case in terms of debugging support, I didn't bother to read into it further. How strange that this incredibly important detail isn't top, front, and centre.
 Are you looking for Windows support?
If I had the extreme misfortune of working on Windows, I'd just use the Visual Studio debugger. As much as I hate to admit it, it's the best-in-class. -Wyatt
Sep 26 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-26 14:14, Wyatt wrote:

 It mentioned only 32-bit ELF on the "About" page.
I don't know which "About" page you're reading. The one I'm reading [1] doesn't mention ELF at all. [1] http://lldb.llvm.org/index.html -- /Jacob Carlborg
Sep 26 2014
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.09.2014 07:30, schrieb Walter Bright:
 On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
 printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation.
In Visual Studio I can define formatters for data structures. Most of the STL containers are already configured out of the box. Additionally, I don't know another IDE that matches Visual Studio debugging capabilities for multi-core and graphics programming. And C++ debugger is still catching with what .NET debugger can do for multi-core programming. -- Paulo
Sep 25 2014
prev sibling parent "Bigsandwich" <bigsandwich gmail.com> writes:
Reading this thread makes me a little sad, because all of the 
wish list stuff seems to be about features that VS already has, 
and the I use every day :(

 For example, the idea of stepping through lines of code (i.e. 
 individual
 statements) is a convenient simplification, but really, in 
 modern
 programming languages there are multiple levels of semantics 
 that could
 have a meaningful concept of "stepping forward/backward".
Only for C#, I would love to see this for native code: http://msdn.microsoft.com/en-us/library/h5e30exc%28v=vs.100%29.aspx On Thursday, 25 September 2014 at 05:30:56 UTC, Walter Bright wrote:
 On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
 printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation.
autoexp.dat can do this in the debugger: http://msdn.microsoft.com/en-us/library/zf0e8s14.aspx
 I don't agree with that. I think symbolic debuggers should be 
 improved
 so that they *can* become useful with high level abstractions. 
 For
 example, if debuggers could be made to understand templates and
 compile-time constants, they could become much more useful 
 than they are
 today in debugging high-level code.
The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code.
http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/
Sep 26 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright 
wrote:
 No prob. The initiating post was an invitation to a wine 
 festival, and that's what we have :-)
:D
Sep 25 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
 I make similar statements all the time. It doesn't result in 
 action on anyone's part. I don't tell people what to do - they 
 work on aspects of D that interest them.

 Even people who ask me what to work on never follow my 
 suggestions. They work on whatever floats their boat. It's my 
 biggest challenge working on free software :-)
One recurring theme appears to be people waiting on you to decide on whether an idea is agreeable in principle before implementing it. It would help if you put up a list on the wiki of such features, either that you want or that you agree with others would be good to have, ie some sort of feature wish list that's pre-approved by you and Andrei. D enthusiasts shouldn't have to wade through a bunch of forum postings and reddit comments to find out that C++ and gc are the current priorities. When this was pointed out to Andrei, he asked that someone else put it on the wiki, and I see that someone just added it to the agenda for 2.067. I'm sorry but it's ridiculous for you two co-BDFLs not to put these new priorities or pre-approved features (perhaps even a list of features you'd automatically reject) in a list on the wiki and maintain it yourselves. It's the least you can do considering the veto power you have. Of course, such lists don't imply a hierarchy where you tell everyone what to do, as the D community is always free to ignore your agenda. ;) But it would enable clear and concise communication, which is lacking now, and I suspect many would take your approval as a signal for what to work on next. For a concrete example, some in this thread have mentioned cleaning up the language, presumably enabled by a dfix tool so users can have their source automatically updated. But even Jacob seemed to think you two were against dfix, in the quote below: On Wednesday, 24 September 2014 at 06:16:07 UTC, Jacob Carlborg wrote:
 On 23/09/14 20:32, David Nadlinger wrote:

 Seriously, once somebody comes up with an automatic fixup 
 tool, there is
 hardly any generic argument left against language changes.
Brain has already said that such a tool is fairly easy to create in many cases. Also that he is willing do to so if it will be used. But so far neither Andrei or Walter have shown any signs of willing to break code that can be fixed with a tool like this. I can understand that Brian doesn't want to create such a tool if it's not going to be used.
Andrei has voiced some support for a tool like this, though in exactly what context is unclear. I believe you once said it'd be unworkable, then when Brian showed you an example using libdparse, you took that back but did not say you wanted to start cleaning up D using such a dfix tool. Go has been doing this for years using gofix and many of us have expressed a desire for such language cleanup using automated source conversion: http://blog.golang.org/introducing-gofix I can understand why nobody builds a dfix tool if it's not going to be used officially to clean up the language. If you said you'd go for it, I imagine Brian would build such a tool and find stuff to fix. Of course, sometimes people look to you two too much to decide. I don't see why Vladimir can't build the autotester setup he wants for third-party D projects and continuously run any third-party projects he wants (all of code.dlang.org?) against dmd/druntime/phobos from git for himself. If others like it, they will start using it for their own projects. The only reason to integrate it with the dmd autotester is to notify authors of their pull requests that broke third-party code, but that can wait till such a third-party autotester has been proven for the third-party authors first. To sum up, you can't tell people what to do in the D community, but you can provide more clear direction on what the priorities are and which future paths have the green light, especially since you and Andrei are the gatekeepers for what gets into dmd.
Sep 25 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 25 September 2014 at 11:30:52 UTC, Joakim wrote:
 On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
 wrote:
 I make similar statements all the time. It doesn't result in 
 action on anyone's part. I don't tell people what to do - they 
 work on aspects of D that interest them.

 Even people who ask me what to work on never follow my 
 suggestions. They work on whatever floats their boat. It's my 
 biggest challenge working on free software :-)
One recurring theme appears to be people waiting on you to decide on whether an idea is agreeable in principle before implementing it. It would help if you put up a list on the wiki of such features, either that you want or that you agree with others would be good to have, ie some sort of feature wish list that's pre-approved by you and Andrei.
There is at least this bugzilla tag: https://issues.dlang.org/buglist.cgi?keywords=preapproved&list_id=110116 ...But its an awful short list! Clear direction has been a common request for a while. In the vein of what you're talking about, though, this seems a good place to leverage our existing infrastructure with Bugzilla. Open tracker bugs that cover these areas and add any issues related to them as dependencies. Looks something like this: https://bugs.gentoo.org/show_bug.cgi?id=484436 -Wyatt
Sep 25 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 5:41 AM, Wyatt wrote:
 On Thursday, 25 September 2014 at 11:30:52 UTC, Joakim wrote:
 On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
 wrote:
 I make similar statements all the time. It doesn't result in action
 on anyone's part. I don't tell people what to do - they work on
 aspects of D that interest them.

 Even people who ask me what to work on never follow my suggestions.
 They work on whatever floats their boat. It's my biggest challenge
 working on free software :-)
One recurring theme appears to be people waiting on you to decide on whether an idea is agreeable in principle before implementing it. It would help if you put up a list on the wiki of such features, either that you want or that you agree with others would be good to have, ie some sort of feature wish list that's pre-approved by you and Andrei.
There is at least this bugzilla tag: https://issues.dlang.org/buglist.cgi?keywords=preapproved&list_id=110116 ....But its an awful short list! Clear direction has been a common request for a while.
I'll make a pass, also please post here specific issues you need to be looked at. Andrei
Sep 25 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 4:30 AM, Joakim wrote:
 I'm sorry but it's ridiculous for you two co-BDFLs not to put
 these new priorities or pre-approved features (perhaps even a
 list of features you'd automatically reject) in a list on the
 wiki and maintain it yourselves.  It's the least you can do
 considering the veto power you have.
That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.) Andrei
Sep 25 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 4:30 AM, Joakim wrote:
 I'm sorry but it's ridiculous for you two co-BDFLs not to put
 these new priorities or pre-approved features (perhaps even a
 list of features you'd automatically reject) in a list on the
 wiki and maintain it yourselves.  It's the least you can do
 considering the veto power you have.
That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.)
That's not enough. While it's nice that a "preapproved" tag is being used on bugzilla, most of those issues are too low-level and an obscure bugzilla tag hardly fits the bill, particularly when most D users have never seen the D bugzilla let alone use it. It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan. I gave a specific example with dfix, yet to get an answer on that. Brian may have marked his DIP 65 as rejected a couple months back, but that still doesn't answer the broader question of using a dfix tool for other cleanup. You have talked about making D development more professional. It's not very professional not to have some sort of public plan of where you want the language to go. All I'm asking for is a public list of preapproved and maybe rejected features that the two of you maintain. Dfix might be on the preapproved list, ARC might be on the rejected. ;) You could also outline broad priorities like C++ support or GC improvement on such a webpage.
Sep 26 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 10:22:49AM +0000, Joakim via Digitalmars-d wrote:
 On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei Alexandrescu wrote:
On 9/25/14, 4:30 AM, Joakim wrote:
I'm sorry but it's ridiculous for you two co-BDFLs not to put
these new priorities or pre-approved features (perhaps even a
list of features you'd automatically reject) in a list on the
wiki and maintain it yourselves.  It's the least you can do
considering the veto power you have.
That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.)
That's not enough. While it's nice that a "preapproved" tag is being used on bugzilla, most of those issues are too low-level and an obscure bugzilla tag hardly fits the bill, particularly when most D users have never seen the D bugzilla let alone use it. It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan.
I'm thinking either a wiki page, or a dedicated webpage on dlang.org, that contains a link to a prebaked bugzilla query that returns all preapproved issues. Or perhaps just add that to http://dlang.org/bugstats.php .
 I gave a specific example with dfix, yet to get an answer on that.
 Brian may have marked his DIP 65 as rejected a couple months back, but
 that still doesn't answer the broader question of using a dfix tool
 for other cleanup.
[...] I'm thinking we, the community, should just go ahead with writing a dfix utility, promote it, and use it. Once it becomes a de facto standard, it will be much easier to convince the BDFLs to "officially" adopt it. ;-) T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
Sep 26 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2014 04:55, Walter Bright wrote:
 I've also found that the more high level abstractions are used, the less
 useful a symbolic debugger is. Symbolic debuggers are only good for
 pedestrian, low level code that ironically is also what other methods
 are very good at, too.
Err... are you talking in the context of D, or programming in general? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Oct 02 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 02 Oct 2014 13:18:43 +0100
Bruno Medeiros via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Err... are you talking in the context of D, or programming in general?
i'm not using interactive debuggers for 10+ years. the only use of GDB for me is doing post-mortem inspection. i found that logging and integrated control console lets me debug my code faster than any interactive debug session can. besides, i found that i spent alot of time doing "next, next, next, run-to-bp, next, next" in interactive debugger instead of sitting down and think a little. ;-)
Oct 02 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 October 2014 at 12:59:37 UTC, ketmar via 
Digitalmars-d wrote:
 i'm not using interactive debuggers for 10+ years. the only use 
 of GDB
 for me is doing post-mortem inspection. i found that logging and
 integrated control console lets me debug my code faster than any
 interactive debug session can.
CLI based debugging in gdb is painful. Whether logging or using a debugger is faster really depends IMO. I think regular tracing/logging is easier when you debug recursive stuff like parser or regexp engines, but a debugger is easier when you have NULL dereferencing issues, when you are getting wrong values in complex calculations or when loops don't terminate when they are supposed to.
Oct 02 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 02 Oct 2014 15:11:37 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 CLI based debugging in gdb is painful.
i used alot of frontends too. martian ddd, then kde's frontend, then tried cgdb. and some other i can't even remember. it's not about bad interface. ;-)
 but a debugger is easier when you have NULL dereferencing issues
this is segfault and coredump. and then... yes, i'm loading that coredump in gdb and doint bt and various prints if necessary.
 when you are getting wrong values in complex calculations
logging can help here too. if we have valid input and garbage output... well, we know where bug is. plus validation of all data, asserts and so on. that's why i love D with it's static asserts, in, out, and invariants. and integrated unittests. sure, i'm not a guru and just talking about personal expirience here. i found myself much more productive after throwing interacteve debuggers out of the window. ;-)
Oct 02 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 October 2014 at 15:29:17 UTC, ketmar via 
Digitalmars-d wrote:
 sure, i'm not a guru and just talking about personal expirience 
 here. i
 found myself much more productive after throwing interacteve 
 debuggers
 out of the window. ;-)
Debugging preferences are very personal, I would think so. :-) The first time I used an interactive source level debugger was in the late 80s using Turbo Pascal, I thought it was magically great, like a revelation! My reference was writing assembly and using a monitor/disassembler to debug… Source level debugging was quite a step up! But I agree that debuggers can be annoying, reconfiguring them is often more troublesome than just adding some printf() hacks. I find them indispensable when I am really stuck though: "duh, I have spent 15 minutes on this, time to fire up the debugger". In environments like javascript/python I often can find the problem just as fast by just using the interactive console if the code is written in a functional style. The more global state you have and the less functional your style is, the more useful a debugger becomes IMO.
Oct 02 2014
next sibling parent reply "po" <yes no.com> writes:
 But I agree that debuggers can be annoying, reconfiguring them 
 is often more troublesome than just adding some printf() hacks. 
 I find them indispensable when I am really stuck though: "duh, 
 I have spent 15 minutes on this, time to fire up the debugger".
Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it up like its still 1980.
Oct 02 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 02 Oct 2014 16:22:38 +0000
po via Digitalmars-d <digitalmars-d puremagic.com> wrote:

   Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it=20
 up like its still 1980.
did you updated your antivirus today?
Oct 02 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 October 2014 at 16:22:39 UTC, po wrote:
  Hehhe reconfigure a debugger. Lolz. Poor linux people. Living 
 it up like its still 1980.
:-) Well, gdb is not my favourite, but it works well on C code. I think this holds for all kinds of debuggers (including VS and XCode)… In all debuggers you have to configure which expressions to watch, how to format them if they are complex and where the breakpoints go. Printf logging with conditionals, asserts and recursive test-functions can often be just as easy as a debugger, if not easier, when working on complex algorithms/messy state machines/deep data structures/data with custom indirection (using ints, rather than pointers).
Oct 02 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 02 Oct 2014 16:13:31 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 In environments like javascript/python I often can find the=20
 problem just as fast by just using the interactive console if the=20
 code is written in a functional style.
actually, i'm cheating here, 'cause most of my reasonably complex software has well-hidden interactive console inside, so i can connect to it to inspect the internal state and execute some (sometimes alot ;-) of internal commands. and i must say that integrating such console in C projects was tiresome. with D i can do it almost automatically, skipping annoying "variable registration" and wrappers for functions. the first thing i wrote in D was "console module" -- just to test if all that "CTFE, and traits, and metaprogramming" promises are real. and then i became immediately hooked to D. ;-)
Oct 02 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 October 2014 at 16:26:15 UTC, ketmar via 
Digitalmars-d wrote:
 and i must say that integrating such
 console in C projects was tiresome. with D i can do it almost
 automatically, skipping annoying "variable registration" and 
 wrappers for functions.

 the first thing i wrote in D was "console module" -- just to 
 test if
 all that "CTFE, and traits, and metaprogramming" promises are 
 real. and
 then i became immediately hooked to D. ;-)
That's pretty cool, so you basically use the reflection capabilities of D to "generate" your own custom CLI to the application? I had not thought of that before. Interesting idea!
Oct 02 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 02 Oct 2014 16:45:21 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That's pretty cool, so you basically use the reflection=20
 capabilities of D to "generate" your own custom CLI to the=20
 application?
yes. some naming conventions and one mixin -- and all interesting variables and functions from the given module are automatically registered in command console. so i can inspect and change variables and fields, call free functions and class/struct member functions, even write simple scripts. it's really handy. and i connect to this console using telnet (if telnet support is activated). this also allows some forms of unified "automated testing" even for GUI apps, all without building special "debug versions", i.e. on production code.
Oct 02 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 October 2014 at 17:02:35 UTC, ketmar via 
Digitalmars-d wrote:
 yes. some naming conventions and one mixin -- and all 
 interesting
 variables and functions from the given module are automatically
 registered in command console. so i can inspect and change 
 variables
 and fields, call free functions and class/struct member 
 functions, even
 write simple scripts. it's really handy. and i connect to this 
 console
 using telnet (if telnet support is activated).
Sounds like a great topic for a blog post! If this is easy to do then this is very useful when writing game servers or servers that retain state in general. Please share when you are ready, I am gonna leach off yer code… ;-)
Oct 03 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 03 Oct 2014 08:30:10 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Please share when you are ready, I am gonna leach off yer code=E2=80=A6=20
 ;-)
sure, i'm planning to open it as PD/WTFPL as soon as i'll settle some issues. there is nothing really spectacular here, i must say, just tedious wrapper generators and parsers. yet it can save some time for other people. ;-) for now you can take the ancient version and use it as a base for your own: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d (don't mind the license, consider is PD/WTFPL) it supports UDA annotations for getting help ('cmd ?'), variables and free functions. and please don't blame me, that was the first 'serious' code i did in D, learning D as i writting the module. ;-)
Oct 03 2014
prev sibling next sibling parent =?windows-1252?Q?Martin_Dra=9Aar?= via Digitalmars-d writes:
Dne 2.10.2014 v 19:02 ketmar via Digitalmars-d napsal(a):
 On Thu, 02 Oct 2014 16:45:21 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:
=20
 That's pretty cool, so you basically use the reflection=20
 capabilities of D to "generate" your own custom CLI to the=20
 application?
yes. some naming conventions and one mixin -- and all interesting variables and functions from the given module are automatically registered in command console. so i can inspect and change variables and fields, call free functions and class/struct member functions, even=
 write simple scripts. it's really handy. and i connect to this console
 using telnet (if telnet support is activated).
=20
 this also allows some forms of unified "automated testing" even for GUI=
 apps, all without building special "debug versions", i.e. on production=
 code.
=20
That is mighty interesting. Would you be willing to share some code? Right now, I am teaching my students about debugging in C/C++ and I want to give them some perspective from other languages and environments. Thanks. Martin
Oct 03 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 03 Oct 2014 10:00:07 +0200
Martin Dra=C5=A1ar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That is mighty interesting. Would you be willing to share some code?
alas, only very old and rudimentary module is available. basically, it's the core of the full-featured console, but... only the core, and not very well written. i'm planning to opensource fully working thingy with bells and whistles eventually, but can't do it right now. :-( anyway, here it is: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d please note that this is not very well tested. i'm keeping it just for nostalgic reasons. ah, and you can ignore the license. consider that code as public domain/WTFPL. there is no struct/class support there, only variables and free functions. yet free functions supports various types of arguments and understands default agrument values.
Oct 03 2014
parent Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Friday, 3 October 2014 at 14:42:23 UTC, ketmar wrote:
 anyway, here it is: 
 http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d

 please note that this is not very well tested. i'm keeping it 
 just for nostalgic reasons.

 ah, and you can ignore the license. consider that code as 
 public domain/WTFPL.

 there is no struct/class support there, only variables and free 
 functions. yet free functions supports various types of 
 arguments and understands default agrument values.
Hi Ketmar. I hope you're well. Would you be able to share this again as not in repo now ? I think I moved computer and lost the previous download. No problem if you prefer not to, but I very much liked your idea and would like to take a quick look again to see what the main things to think about are (will write from scratch though). Thanks. Laeeth.
Mar 17
prev sibling next sibling parent =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d writes:
Dne 3.10.2014 v 16:42 ketmar via Digitalmars-d napsal(a):
 alas, only very old and rudimentary module is available. basically,
 it's the core of the full-featured console, but... only the core, and
 not very well written. i'm planning to opensource fully working thingy
 with bells and whistles eventually, but can't do it right now. :-(
=20
 anyway, here it is:
 http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d
=20
 please note that this is not very well tested. i'm keeping it just for
 nostalgic reasons.
=20
 ah, and you can ignore the license. consider that code as public
 domain/WTFPL.
=20
 there is no struct/class support there, only variables and free
 functions. yet free functions supports various types of arguments and
 understands default agrument values.
Thanks a lot. I just briefly gone through the code and I have a question about the console use: That code is able to register functions and variables with some annotations and execute them by string commands. How do you generally use it for debugging purposes? That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands? Also, how do you make your console work in multithreaded programs? Thanks, Martin
Oct 06 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 10:22:01 +0200
Martin Dra=C5=A1ar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

as i said this is the very first version of cmdcon, not the one i'm
using now. i'm not able to publish the current version yet.

 That is, how do you use this console interactively?
 In your previous mail you wrote that you use a telnet.
 Do you have another mixin that at some specific point inserts a code
 that pauses the execution of surrounding code and starts listening
 for telnet commands?
it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later.
 Also, how do you make your console work in multithreaded programs?
you should register only shared and global vars (and i'm really missing __trait(isGShared) here!), there is no sense to register thread locals in multithreaded program. but you can register free functions and execute 'em. that free functions should take care of threading. really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-)
Oct 06 2014
prev sibling next sibling parent =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d writes:
Dne 6.10.2014 v 12:15 ketmar via Digitalmars-d napsal(a):
 On Mon, 06 Oct 2014 10:22:01 +0200
 Martin Dra=C5=A1ar via Digitalmars-d <digitalmars-d puremagic.com> wrot=
e:
=20
 as i said this is the very first version of cmdcon, not the one i'm
 using now. i'm not able to publish the current version yet.
=20
 That is, how do you use this console interactively?
 In your previous mail you wrote that you use a telnet.
 Do you have another mixin that at some specific point inserts a code
 that pauses the execution of surrounding code and starts listening
 for telnet commands?
it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later. =20
 Also, how do you make your console work in multithreaded programs?
you should register only shared and global vars (and i'm really missing=
 __trait(isGShared) here!), there is no sense to register thread locals
 in multithreaded program.
=20
 but you can register free functions and execute 'em. that free
 functions should take care of threading.
=20
 really, i have to revisit that code and write some samples. i'll try to=
 do that soon. and maybe i'll update public versino of cmdcon a little
 too. ;-)
=20
Ok, thanks for your answers. If you get your code to publishable state, I am sure a lot of people will be interested. Cheers, Martin
Oct 06 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 13:34:23 +0200
Martin Dra=C5=A1ar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Ok, thanks for your answers. If you get your code to publishable
 state, I am sure a lot of people will be interested.
as i can't publish my current version of cmdcon, i decided to write another one from scratch. it contains alot less of mixin() codegens, can do everything cmdcon.d can do and has structs/classes already working. this is the excerpt from testing code: import cong; // our console module ConName("intVar00") ConHelp("simple int variable") ConDescription("this is just an int variable.\nordinary one, nothing special.") __gshared int v0 =3D 42; __gshared string v1 =3D "hi!"; class A { int i =3D 42; string s =3D "hello"; this () {} this (string v) { s =3D v; } int bar () { writeln("BAR: s=3D", s); return 666; } void foo (float[] ff) {} } __gshared A a; // yes, this can be null void foo (int n, string s=3D"hi", double d=3D0.666) { writefln("n=3D%s; s=3D[%s]; d=3D%s", n, s, d); } struct S { int i =3D 666; string s =3D "bye"; int sbar () { writeln("SBAR: s=3D", s); return 666; } void sfoo (float[] ff) {} } __gshared S s; S s1; void main (string[] args) { writeln("known commands:"); foreach (auto n; conGetKnownNames()) writeln(" ", n); writeln("---"); a =3D new A(); conExecute("a bar"); // virtual method call for object instance a.s =3D "first change"; conExecute("a bar"); a =3D new A("second change"); conExecute("a bar"); // virtual method call for ANOTHER object instance foreach (auto arg; args[1..$]) { try { writeln("# ", arg); conExecute(arg); } catch (Exception e) { writeln("***ERROR: ", e.msg); } } } mixin(ConRegisterAll); // register 'em all! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D known commands: intVar00 a foo v1 s --- (autoregistration rocks!) some sample commands and results: # intVar00 intVar00 42 (Int) # foo 42 n=3D42; s=3D[hi]; d=3D0.666 # a i a.i 42 (Int) # a bar BAR: s=3Dsecond change # s sbar SBAR: s=3Dbye by default `mixin(ConRegisterAll);` tries to register all suitable public symbols. one can use ConIgnore UDA to ignore symbol and some other UDAs to change name, add help and so on. alas, there is no way to get Ddoc info in compile-time (what a pity!). you can't register pointer objects (i.e. `__gshared int *a` will not pass). it's doable (class fields are such objects internally), but i just don't need this. i also found some bugs in compilers (both dmd and gdc), but aren't ready to dustmite and report 'em yet. GDC just segfaults now, but DMD works. there is also bug in CDGC, which took me a whole day of useless code motion (i forgot that i'm using DMD built with CDGC ;-). so the base mechanics is in place, i need to debug some things and write simple sample with eventloop and telnet. new code includes only WTFPL'ed parts, so it probably will be WTFPLed too. hope to finish this until weekend.
Oct 13 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 October 2014 at 21:09:29 UTC, ketmar via 
Digitalmars-d wrote:
 as i can't publish my current version of cmdcon, i decided to 
 write another one from scratch.
Cool, looks like a fun module to play with! :-)
Oct 13 2014
prev sibling next sibling parent =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d writes:
Dne 13.10.2014 v 23:09 ketmar via Digitalmars-d napsal(a):
 as i can't publish my current version of cmdcon, i decided to write
 another one from scratch. it contains alot less of mixin() codegens,
 can do everything cmdcon.d can do and has structs/classes already
 working. this is the excerpt from testing code:
Nice! That's what I call a can-do attitude :) I just happen to have a nice place in code where it can get used. I'm looking forward for playing with it. Martin
Oct 13 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
as i see that some peopele are eager to play with cmdcon-ng, i setup a
git repo with it: http://repo.or.cz/w/cong.d.git

lay your hands while it hot!

the code is little messy (there are some napoleonian plans which aren't
made into it), but it should work. at least with unittests and sample.

enjoy, and happy hacking!
Oct 13 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 14 Oct 2014 00:09:17 +0300
ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

let's stop hijacking this thread. here is The Official Thread for
cmdcon-ng:
http://forum.dlang.org/thread/mailman.772.1413240502.9932.digitalmars-d pur=
emagic.com
Oct 13 2014
prev sibling parent reply "user" <user xxx.com> writes:
On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
Digitalmars-d wrote:
 On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 There was a recent video[1] by Jonathan Blow about what he 
 would want in a
 programming language designed specifically for game 
 development. Go, Rust,
 and D were mentioned and his reason for not wanting to use D 
 is is that it
 is "too much like C++" although he does not really go into it 
 much and it
 was a very small part of the video it still brings up some 
 questions.

 What I am curious is what are the worst parts of D? What sort 
 of things
 would be done differently if we could start over or if we were 
 designing a
 D3? I am not asking to try and bash D but because it is 
 helpful to know
 what's bad as well as good.

 I will start off...
 GC by default is a big sore point that everyone brings up
 "is" expressions are pretty wonky
 Libraries could definitely be split up better

 What do you think are the worst parts of D?

 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
Personally, after years of use, my focus on things that really annoy me has shifted away from problems with the language, and firmly towards basic practicality and productivity concerns. I'm for addressing things that bother the hell out of me every single day. I should by all reason be more productive in D, but after 6 years of experience, I find I definitely remain less productive, thanks mostly to tooling and infrastructure. 1. Constant rejection of improvements because "OMG breaking change!". Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes. 2. Tooling is still insufficient. I use Visual Studio, and while VisualD is good, it's not great. Like almost all tooling projects, there is only one contributor, and I think this trend presents huge friction to adoption. Tooling is always factored outside of the D community and their perceived realm of responsibility. I'd like to see tooling taken into the core community and issues/bugs treated just as seriously as issues in the compiler/language itself. 3. Debugging is barely ever considered important. I'd love to see a concerted focus on making the debug experience excellent. Iain had a go at GDB, I understand there is great improvement there. Sadly, we recently lost the developer of Mago (a Windows debugger). There's lots of work we could do here, and I think it's of gigantic impact. 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years later, I still can't pass an rvalue->ref (been discussed endlessly), create a ref local, and the separation from the type system makes it a nightmare in generic code. This was a nuisance for me on day-1, and has been grinding me down endlessly for years. It has now far eclipsed my grudges with the GC/RC, or literally anything else about the language on account of frequency of occurrence; almost daily.
i couldn't agree more. i would like to add, that coming from D1's clean and nice syntax - D2 becomes a syntactic monster, that is highly irritating and hard to get used to. its littered with like a scripting language. that really sucks!
Sep 24 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 08:53:50 +0000
user via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 its littered with  
 like a scripting language. that really sucks!
do you like the fact that you can't have variable named "body"? do you want to have more such forbidden names?
Sep 24 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
On Wednesday, 24 September 2014 at 08:53:51 UTC, user wrote:
 On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
 Digitalmars-d wrote:
 On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 i couldn't agree more. i would like to add, that coming from 
 D1's
 clean and nice syntax - D2 becomes a syntactic monster
You are a bit right, it is about on the edge and dragging all those undecisions with it only makes things worse. People usually say that complexity is not that bad, because you only use what you know (but what about maintenance?). Still, people criticize C++ for being too complex. http://abstrusegoose.com/strips/ars_longa_vita_brevis.PNG 80 percents of C++ programmers know only 20% of the language. However, not *the same* 20% percents...
Sep 24 2014
prev sibling next sibling parent reply "Iain Buclaw" <ibuclaw gdcproject.org> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
Anything in the spec that depends on you having an x86 CPU, or being tied to a specific platform. 1) D Inline Assembler. - First because suddenly to have a conformant compiler you need to implement an entire assembler, rather than doing the sensible thing and just offloading it to GAS or some other tool that can assemble the code for you. - Second because it creates so many holes, like invalidates nothrow checks, allows jumps to skip over initialisations, etc. 2) __simd - The gentlemans equivalent of asm { di 0xF30F58, v1, v2; } 3) va_argsave_t implementation - The brainchild of "let's get it working, then pretty" when it came to porting DMD to 64bit. Everyone else managed to support 64bit va_list just fine for years without it. 4) Array operations only work if evaluation order is done from right to left. - Contradictory to the rest of the language which promotes left to right evaluation. 5) CTFE'd Intrinsics - First, there's a disparity between what is a compiler intrinsic and what is a ctfe intrinsic. Eg: tan() - Second, there is no use-case for being able to run at compile-time what is essentially a specialist x87 opcode. 6) Shared library support - Still no documentation after 2 or more years of requesting it. 7) Interfacing with C++ - A new set of features that is danger of falling into the same "let's get it working" pit. First warning sign was C++ template mangling, then DMD gave up on mangling D 'long' in any predictable way. It's all been downhill from there.
Sep 25 2014
next sibling parent "Iain Buclaw" <ibuclaw gdcproject.org> writes:
On Thursday, 25 September 2014 at 07:34:11 UTC, Iain Buclaw wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:
 What do you think are the worst parts of D?
Anything in the spec that depends on you having an x86 CPU, or being tied to a specific platform.
Special extra 8) Real - What a pain.
Sep 25 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Iain Buclaw"  wrote in message news:dqgkcmdmxekzqpvfbcim forum.dlang.org...

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
 What do you think are the worst parts of D?
 1) D Inline Assembler.
Relying on the system assembler sucks too.
 7) Interfacing with C++
 - A new set of features that is danger of falling into the same "let's get 
 it working" pit.  First warning sign was C++ template mangling, then DMD 
 gave up on mangling D 'long' in any predictable way.  It's all been 
 downhill from there.
C++ template mangling is fine. 'long' mangling is messy, but it's better than what was there before.
 8) Real
 - What a pain.
Oh yeah. D's one variable-sized type.
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 9:26 PM, Daniel Murphy wrote:
 Oh yeah.  D's one variable-sized type.
Pointers too!
Sep 26 2014
prev sibling next sibling parent Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 09/20/2014 05:39 AM, Tofu Ninja via Digitalmars-d wrote:
 There was a recent video[1] by Jonathan Blow about what he would want 
 in a programming language designed specifically for game development. 
 Go, Rust, and D were mentioned and his reason for not wanting to use D 
 is is that it is "too much like C++" although he does not really go 
 into it much and it was a very small part of the video it still brings 
 up some questions.

 What I am curious is what are the worst parts of D? What sort of 
 things would be done differently if we could start over or if we were 
 designing a D3? I am not asking to try and bash D but because it is 
 helpful to know what's bad as well as good.

 I will start off...
 GC by default is a big sore point that everyone brings up
 "is" expressions are pretty wonky
 Libraries could definitely be split up better

 What do you think are the worst parts of D?

 [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
The worst part of D is the limited libraries. This often causes me to choose Python instead, I'm sure it often causes others to choose Java or C++ or ... Mind you, many of the libraries "sort of" exist, but they don't work well. This is a pity, because if there were, say, a decent wrapper for SQLite then there would be many more uses. (Yes, I know that the C interface code is included...that's why I picked that particular example.) OTOH, it's not clear how to solve this, outside of convincing more people to spend time wrapping libraries. But I'm not the right person, because my prior attempts have ended up being half-hearted failure....also I don't really like the D template syntax. (For that matter I'm dubious about the entire "template" approach, though many people clearly find it reasonable.)
Oct 04 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
I am in the mood to complain today so this feels like a good 
moment to post a bit more extended reply here.

There are three big issues that harm D development most in my 
opinion:

1) lack of "vision"

TDPL was an absolutely awesome book because it expained "why?" as 
opposed to "how?". Such insight into language authors rationale 
is incredibly helpful for long-term contribution. Unfortunately, 
it didn't cover all parts of the language and many new things has 
been added since it was out.

Right now I have no idea where the development is headed and what 
to expect from next few releases. I am not speaking about 
wiki.dlang.org/Agenda but about bigger picture. Unexpected focus 
on C++ support, thread about killing auto-decoding, recent ref 
counting proposal - all this stuff comes from language authors 
but does not feel like a strategic additions. It feels like yet 
another random contribution, no different from contribution/idea 
of any other D user.

Anarchy-driven development is pretty cool thing in general but 
only if there is a base, a long-term vision all other 
contributions are built upon. And I think it is primary 
responsibility of language authors to define such as clear as 
possible. It is very difficult task but it simply can't be 
delegated.

2) reliable release base

I think this is most important part of open-source infrastructure 
needed to attract more contributions and something that also 
belongs to the "core team". I understand why Walter was so eager 
to delegate is but right now the truth is that once Andrew has to 
temporarily leave all release process has immediately stalled. 
And finding replacement is not easy - this task is inherently 
ungrateful as it implies spending time and resources on stuff you 
personally don't need at all.

Same applies to versioning - it got considerably better with 
introduction of minor version but it is still far from reasonable 
SemVer and cherry-picking approach still feels like madness.

And current situation where dissapearance of one person has 
completely blocked and releases simply tells everyone "D is still 
terribly immature".

3) lack of field testing

Too many new features get added simply because they look 
theoretically sound. I think it is quite telling that most robust 
parts of D are the ones that got designed based on mistake 
experience of other languages (primarily C++) and most 
innovations tend to fall into collection of hacks stockpiled 
together (something same C++ is infamous for).

I am disturbed when Andrei comes with proposal that possibly 
affects whole damn Phobos (memeory management flags) and asks to 
trust his experience and authority on topic while rejecting 
patterns that are confirmed to be working well in real production 
projects. Don't get me wrong, I don't doubt Andrei authority on 
memory management topic (it is miles ahead of mine at the very 
least) but I simply don't believe any living person in this world 
can design such big change from scratch without some extended 
feedback from real deployed projects.

This is closely related to SemVer topic. I'd love to see D3. And 
D4 soon after. And probably new prime version increase every year 
or two. This allows to tinker with really big changes without 
being concerned about how it will affect your code in next 
release.

Don has been mentioning that Sociomantic is all for breaking the 
code for the greater good and I fully agree with him. But 
introducing such surprise solutions creates a huge risk of either 
sticking with imperfect design and patching it (what we have now) 
or changing same stuff back and forth every basic release (and 
_that_ is bad).
Oct 05 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/5/14, 7:55 AM, Dicebot wrote:
 1) lack of "vision"
The vision is to expand user base and make a compelling case for using D alongside existing code bases. There are two important aspects to that: interoperability with C++, and using D without a garbage collector.
 Right now I have no idea where the development is headed and what to
 expect from next few releases. I am not speaking about
 wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++
 support, thread about killing auto-decoding, recent ref counting
 proposal - all this stuff comes from language authors but does not feel
 like a strategic additions.
1. C++ support is good for attracting companies featuring large C++ codebases to get into D for new code without disruptions. 2. Auto-decoding is blown out of proportion and a distraction at this time. 3. Ref counting is necessary again for encouraging adoption. We've framed GC as an user education matter for years. We might have even been right for the most part, but it doesn't matter. Fact is that a large potential user base will simply not consider a GC language.
 It feels like yet another random
 contribution, no different from contribution/idea of any other D user.

 Anarchy-driven development is pretty cool thing in general but only if
 there is a base, a long-term vision all other contributions are built
 upon. And I think it is primary responsibility of language authors to
 define such as clear as possible. It is very difficult task but it
 simply can't be delegated.
I'm all about vision. I do agree we've been less so in the past.
 2) reliable release base

 I think this is most important part of open-source infrastructure needed
 to attract more contributions and something that also belongs to the
 "core team". I understand why Walter was so eager to delegate is but
 right now the truth is that once Andrew has to temporarily leave all
 release process has immediately stalled. And finding replacement is not
 easy - this task is inherently ungrateful as it implies spending time
 and resources on stuff you personally don't need at all.
We now have Martin Nowak as the point of contact.
 3) lack of field testing

 Too many new features get added simply because they look theoretically
 sound.
What would those be?
 I think it is quite telling that most robust parts of D are the
 ones that got designed based on mistake experience of other languages
 (primarily C++) and most innovations tend to fall into collection of
 hacks stockpiled together (something same C++ is infamous for).

 I am disturbed when Andrei comes with proposal that possibly affects
 whole damn Phobos (memeory management flags) and asks to trust his
 experience and authority on topic while rejecting patterns that are
 confirmed to be working well in real production projects.
Policy-based design is more than one decade old, and older under other guises. Reference counting is many decades old. Both have been humongous success stories for C++. No need to trust me or anyone, but at some point decisions will be made. Most decisions don't make everybody happy. To influence them it suffices to argue your case properly. I hope you don't have the feeling appeal to authority is used to counter real arguments. I _do_ trust my authority over someone else's, especially when I'm on hook for the decision made. I won't ever say "this is a disaster, but we did it because a guy on the forum said it'll work".
 Don't get me
 wrong, I don't doubt Andrei authority on memory management topic (it is
 miles ahead of mine at the very least) but I simply don't believe any
 living person in this world can design such big change from scratch
 without some extended feedback from real deployed projects.
Feedback is great, thanks. But we can't test everything before actually doing anything. I know how PBD works and I know how RC works, both from having hacked with them for years. I know where this will go, and it's somewhere good.
 This is closely related to SemVer topic. I'd love to see D3. And D4 soon
 after. And probably new prime version increase every year or two. This
 allows to tinker with really big changes without being concerned about
 how it will affect your code in next release.
Sorry, I'm not on board with this. I believe it does nothing than balkanize the community, and there's plenty of evidence from other languages (Perl, Python). Microsoft could afford to do it with C# only because they have lock-in with their user base, monopoly on tooling, and a simple transition story ("give us more money").
 Don has been mentioning that Sociomantic is all for breaking the code
 for the greater good and I fully agree with him. But introducing such
 surprise solutions creates a huge risk of either sticking with imperfect
 design and patching it (what we have now) or changing same stuff back
 and forth every basic release (and _that_ is bad).
I don't see what is surprising about my vision. It's simple and clear. C++ and GC. C++ and GC. Andrei
Oct 05 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu 
wrote:
 On 10/5/14, 7:55 AM, Dicebot wrote:
 1) lack of "vision"
The vision is to expand user base and make a compelling case for using D alongside existing code bases. There are two important aspects to that: interoperability with C++, and using D without a garbage collector.
 Right now I have no idea where the development is headed and 
 what to
 expect from next few releases. I am not speaking about
 wiki.dlang.org/Agenda but about bigger picture. Unexpected 
 focus on C++
 support, thread about killing auto-decoding, recent ref 
 counting
 proposal - all this stuff comes from language authors but does 
 not feel
 like a strategic additions.
1. C++ support is good for attracting companies featuring large C++ codebases to get into D for new code without disruptions. 2. Auto-decoding is blown out of proportion and a distraction at this time. 3. Ref counting is necessary again for encouraging adoption. We've framed GC as an user education matter for years. We might have even been right for the most part, but it doesn't matter. Fact is that a large potential user base will simply not consider a GC language.
No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. Right now your rationales get lost in forum discussion threads and it is hard to understand what really is Next Big Thing and what is just forum argument blown out of proportion. There was a go at properties, at eliminating destructors, at rvalue references and whatever else I have forgotten by now. It all pretty much ended with "do nothing" outcome for one reason or the other. The fact that you don't seem to have a consensus with Walter on some topic (auto-decoding, yeah) doesn't help either. Language marketing is not about posting links on reddit, it is a very hard work of communicating your vision so that it is clear even to random by-passer.
 2) reliable release base

 I think this is most important part of open-source 
 infrastructure needed
 to attract more contributions and something that also belongs 
 to the
 "core team". I understand why Walter was so eager to delegate 
 is but
 right now the truth is that once Andrew has to temporarily 
 leave all
 release process has immediately stalled. And finding 
 replacement is not
 easy - this task is inherently ungrateful as it implies 
 spending time
 and resources on stuff you personally don't need at all.
We now have Martin Nowak as the point of contact.
And what if he gets busy too? :)
 3) lack of field testing

 Too many new features get added simply because they look 
 theoretically
 sound.
What would those be?
Consider something like `inout`. It is a very look feature to address an issue specific to D and it looked perfectly reasonable when it was introduces. And right now there are some fishy hacks about it even in Phobos (like forced inout delegates in traits) that did come from originally unexpected usage cases. It is quite likely that re-designing it from scratch based on existing field experience would have yielded better results.
 Policy-based design is more than one decade old, and older 
 under other guises. Reference counting is many decades old. 
 Both have been humongous success stories for C++.
Probably I have missed the point where new proposal was added but original one was not using true policy-based design but set of enum flags instead (no way to use user-defined policy). Reference counting experience I am aware of shows that it is both successful in some cases and unapplicable for the others. But I don't know of any field experience that shows that chosing between RC and GC as a policy is a good/sufficient tool to minimize garbage creation in libraries - real issue we need to solve that original proposal does not mention at all.
 No need to trust me or anyone, but at some point decisions will 
 be made. Most decisions don't make everybody happy. To 
 influence them it suffices to argue your case properly. I hope 
 you don't have the feeling appeal to authority is used to 
 counter real arguments. I _do_ trust my authority over someone 
 else's, especially when I'm on hook for the decision made. I 
 won't ever say "this is a disaster, but we did it because a guy 
 on the forum said it'll work".
I don't want to waste your time arguing about irrelevant things simply because I have misinterprete how proposed solution fits the big picture. It is still unclear why proposed scheme is incompatible with tweaking Phobos utilities into input/output ranges. I am stipid and I am asking for detailed explanations before any arguments can be made :) And not just explanations for me but stuff anyone interested can find quickly.
 This is closely related to SemVer topic. I'd love to see D3. 
 And D4 soon
 after. And probably new prime version increase every year or 
 two. This
 allows to tinker with really big changes without being 
 concerned about
 how it will affect your code in next release.
Sorry, I'm not on board with this. I believe it does nothing than balkanize the community, and there's plenty of evidence from other languages (Perl, Python). Microsoft could afford to do it with C# only because they have lock-in with their user base, monopoly on tooling, and a simple transition story ("give us more money").
You risk balkanization by keeping the things as they are. We do have talks at work sometimes that simply forking the language may be a more practical approach than pushing necessary breaking changes upstream by the time D2 port is complete. Those are just talks of course and until porting is done it is all just speculations but it does indicate certain level of unhappinness.
 Don has been mentioning that Sociomantic is all for breaking 
 the code
 for the greater good and I fully agree with him. But 
 introducing such
 surprise solutions creates a huge risk of either sticking with 
 imperfect
 design and patching it (what we have now) or changing same 
 stuff back
 and forth every basic release (and _that_ is bad).
I don't see what is surprising about my vision. It's simple and clear. C++ and GC. C++ and GC.
It came as surpise. It is unclear how long will it stay. It is unclear what exactly is the goal. Have you ever considered starting a blog about your vision of D development to communicate it better to wider audience? :)
Oct 05 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something that anyone coming to dlang.org page or GitHub repo 
 sees. Something that is explained in a bit more details, 
 possibly with code examples. I know I am asking much but seeing 
 quick reference for "imagine this stuff is implemented, this is 
 how your program code will be affected and this is why it is a 
 good thing" could have been huge deal.
Something like this would be nice: http://golang.org/s/go14gc
Oct 05 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something that anyone coming to dlang.org page or GitHub repo 
 sees. Something that is explained in a bit more details, 
 possibly with code examples. I know I am asking much but 
 seeing quick reference for "imagine this stuff is implemented, 
 this is how your program code will be affected and this is why 
 it is a good thing" could have been huge deal.
Something like this would be nice: http://golang.org/s/go14gc
(sorry, replying to this answer because is shorter) Would a strategy where pointers are by default unique, and only become shared, weak and naked if explicitely declared as such?
Oct 05 2014
parent "eles" <eles215 gzk.dot> writes:
On Sunday, 5 October 2014 at 22:11:38 UTC, eles wrote:
 On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 
 wrote:
 On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something that anyone coming to dlang.org page or GitHub repo 
 sees. Something that is explained in a bit more details, 
 possibly with code examples. I know I am asking much but 
 seeing quick reference for "imagine this stuff is 
 implemented, this is how your program code will be affected 
 and this is why it is a good thing" could have been huge deal.
Something like this would be nice: http://golang.org/s/go14gc
(sorry, replying to this answer because is shorter) Would a strategy where pointers are by default unique, and only become shared, weak and naked if explicitely declared as such?
of course, would it be viable?
Oct 05 2014
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something that anyone coming to dlang.org page or GitHub repo 
 sees. Something that is explained in a bit more details, 
 possibly with code examples. I know I am asking much but seeing 
 quick reference for "imagine this stuff is implemented, this is 
 how your program code will be affected and this is why it is a 
 good thing" could have been huge deal.
 Right now your rationales get lost in forum discussion threads
Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds. Judging by the recent thread where someone (Ola?) asked what "C++ support" actually means and received precisely zero useful guidance, no one else does either. (This isn't to say I don't think it's important, but the scope of what you're doing right now and how it materially helps end users isn't really clear.)
 There was a go at properties
SALT. -Wyatt
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 5:42 AM, Wyatt wrote:
 On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean something
 that anyone coming to dlang.org page or GitHub repo sees. Something
 that is explained in a bit more details, possibly with code examples.
 I know I am asking much but seeing quick reference for "imagine this
 stuff is implemented, this is how your program code will be affected
 and this is why it is a good thing" could have been huge deal.
 Right now your rationales get lost in forum discussion threads
Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds.
I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei
Oct 06 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 5:42 AM, Wyatt wrote:
 On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something
 that anyone coming to dlang.org page or GitHub repo sees. 
 Something
 that is explained in a bit more details, possibly with code 
 examples.
 I know I am asking much but seeing quick reference for 
 "imagine this
 stuff is implemented, this is how your program code will be 
 affected
 and this is why it is a good thing" could have been huge deal.
 Right now your rationales get lost in forum discussion threads
Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds.
I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei
Sure, the newsgroup is a great place to discuss the minutiae of specific features and figure out how they might be implemented and what design tradeoffs need to be made. I think we've shown we can disagree about the colour of any bikeshed of any shape and construction at this point! But in what venue do you feel comfortable holding the easily-accessible public record of your intent for C++ support so anyone wondering about this new mantra can get the summary of what it means for them _as an end user_ without scouring the NG and partially-piecing-it-together-but-not-really from a dozen disparate posts? To be succinct: how about an article? We're not asking for a discussion in this case so much as some frank sharing. D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? What kinds of things will this allow that were impossible before? How, specifically, do you envision that to look? Can you give example code that you would expect to work when it's "done"? What are the drawbacks you believe forward engineers will have to watch out for? It's okay to not have all the answers and explain that there are parts that may not make it because of various reasons. I somewhat feel that you're approaching this situation as if it that were all quite obvious. Maybe it is to you? I don't know. But I do know I'm not alone in the dark here. Please bring a lamp. -Wyatt
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 7:36 AM, Wyatt wrote:
 To be succinct: how about an article?
An article would be great once we have done something we can show.
 We're not asking for a discussion in this case so much as some frank
 sharing.
Is there anything dishonest about sharing intent about the D programming language in the public forum of the D programming language?
 D is going to have C++ support.  That's cool and compelling as
 a bare statement, but in what manner?
We don't know yet, we're designing it - to wit, we're looking for help regarding exception interoperability.
 What kinds of things will this
 allow that were impossible before?
The exact list is in the air. We're looking e.g. for the best policy on exceptions. Possible vs. impossible is btw a matter of scale, for example wrapping everything you need from C++ in C functions is possible in the small but impossible at scale.
 How, specifically, do you envision
 that to look?
What is "that"?
 Can you give example code that you would expect to work
 when it's "done"?
This was discussed already: we should be able to pass an std::vector<int> by reference/pointer from C++ into D and use it within D directly, with no intervening marshaling.
 What are the drawbacks you believe forward engineers
 will have to watch out for?
What's a forward engineer?
 It's okay to not have all the answers and
 explain that there are parts that may not make it because of various
 reasons.

 I somewhat feel that you're approaching this situation as if it that
 were all quite obvious.  Maybe it is to you?  I don't know. But I do
 know I'm not alone in the dark here.  Please bring a lamp.
It seems this is a simple misunderstanding. You're looking for a virtually finished product (article documenting how it works; analysis; design; projected impact) whereas we're very much at the beginning of all that. What's clear to me is we need better interop with C++, so I've put that up for discussion as soon as reasonable. You're asking for things that are months into the future. Andrei
Oct 06 2014
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 6 October 2014 at 15:05:31 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 7:36 AM, Wyatt wrote:
 D is going to have C++ support.  That's cool and compelling as
 a bare statement, but in what manner?
We don't know yet, we're designing it
 The exact list is in the air. We're looking e.g. for the best 
 policy on exceptions. Possible vs. impossible is btw a matter 
 of scale, for example wrapping everything you need from C++ in 
 C functions is possible in the small but impossible at scale.
Ah, I see what happened now! The way you've been pushing it, I was given to believe you had something resembling a "grand vision" of how you wanted "C++ interoperability" to work with some proposed syntax and semantics. If not something so grandiose, at least a pool of ideas written down? Or even just a mental list of things you think are important to cover? Regardless, these things ARE important to communicate clearly.
 This was discussed already: we should be able to pass an 
 std::vector<int> by reference/pointer from C++ into D and use 
 it within D directly, with no intervening marshaling.
Awesome, this is a start.
 It seems this is a simple misunderstanding. You're looking for 
 a virtually finished product
It really is a misunderstanding. Heck, I think it still is one because all we're really looking for is some inkling of what's on your agenda at a granularity finer than "C++ and GC". If nothing else, a list like that gets people thinking about a feature ahead of the dedicated thread to discuss it. -Wyatt PS: Come to think of it, I may have been expecting a DIP?
Oct 06 2014
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 5:42 AM, Wyatt wrote:
 On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
 No need to explain it here. When I speak about vision I mean 
 something
 that anyone coming to dlang.org page or GitHub repo sees. 
 Something
 that is explained in a bit more details, possibly with code 
 examples.
 I know I am asking much but seeing quick reference for 
 "imagine this
 stuff is implemented, this is how your program code will be 
 affected
 and this is why it is a good thing" could have been huge deal.
 Right now your rationales get lost in forum discussion threads
Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds.
I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei
Answer: On Friday, 26 September 2014 at 10:22:50 UTC, Joakim wrote:
 It needs to be a page on the wiki or the main site, which you 
 or any user can link to anytime people want to know the plan.

 some sort of public plan of where you want the language to go.  
 All I'm asking for is a public list of preapproved and maybe 
 rejected features that the two of you maintain.  Dfix might be 
 on the preapproved list, ARC might be on the rejected. ;) You 
 could also outline broad priorities like C++ support or GC 
 improvement on such a webpage.
You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle). Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction. Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up. It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit.
Oct 06 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 8:08 AM, Joakim wrote:
 You and Walter do a good job of answering questions on Reddit and
 there's certainly a lot of discussion on the forum where the two of you
 chip in, but what's missing is a high-level overview of the co-BDFLs'
 priorities for where the language is going, including a list of features
 you'd like to see added, ie that are pre-approved (that doesn't mean
 _any_ implementation would be approved, only that feature in principle).
Aye, something like that might be helpful. I'll keep it in mind.
 Most users or wannabe contributors aren't going to go deep-diving
 through the forums for such direction.
I'm not so sure that's a problem. It takes some connection to the language milieu before making a major contribution of the kind to be on a "vision" list. And once that connection is present, it's rather clear what the issues are. That's the case for any language.
 Manu and others recently wrote
 that the traffic on the forum has gone up, making it tougher for them to
 keep up.
Yah, there's been some growing pains. Traffic is on the rise and unfortunately the signal to noise ratio isn't. Converting the existing passion and sentiment into workable items is a present challenge I'm thinking of ways to approach.
 It would help if the two co-BFDLs did a better job
 articulating and communicating their vision in a public place, like a
 page on the wiki or dlang.org website, rather than buried in the
 haystack of the forums or reddit.
That's sensible. Andrei
Oct 06 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/5/14, 9:14 AM, Dicebot wrote:
 On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote:
 1. C++ support is good for attracting companies featuring large C++
 codebases to get into D for new code without disruptions.

 2. Auto-decoding is blown out of proportion and a distraction at this
 time.

 3. Ref counting is necessary again for encouraging adoption. We've
 framed GC as an user education matter for years. We might have even
 been right for the most part, but it doesn't matter. Fact is that a
 large potential user base will simply not consider a GC language.
No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal.
I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release?
 Right now your rationales get lost in forum discussion threads and it is
 hard to understand what really is Next Big Thing and what is just forum
 argument blown out of proportion. There was a go at properties, at
 eliminating destructors, at rvalue references and whatever else I have
 forgotten by now. It all pretty much ended with "do nothing" outcome for
 one reason or the other.
Let's see. We have properties, which indeed need some work done but don't seem to prevent people from getting work done. The discussion on eliminating destructors concluded with "we don't want to do that for good reasons". For binding rvalues Walter has a tentative design that's due for an RFC soon.
 The fact that you don't seem to have a consensus with Walter on some
 topic (auto-decoding, yeah) doesn't help either. Language marketing is
 not about posting links on reddit, it is a very hard work of
 communicating your vision so that it is clear even to random by-passer.
I think one good thing we can do is approach things in private before discussing them publicly.
 2) reliable release base

 I think this is most important part of open-source infrastructure needed
 to attract more contributions and something that also belongs to the
 "core team". I understand why Walter was so eager to delegate is but
 right now the truth is that once Andrew has to temporarily leave all
 release process has immediately stalled. And finding replacement is not
 easy - this task is inherently ungrateful as it implies spending time
 and resources on stuff you personally don't need at all.
We now have Martin Nowak as the point of contact.
And what if he gets busy too? :)
Maybe you'll volunteer.
 3) lack of field testing

 Too many new features get added simply because they look theoretically
 sound.
What would those be?
Consider something like `inout`. It is a very look feature to address an issue specific to D and it looked perfectly reasonable when it was introduces. And right now there are some fishy hacks about it even in Phobos (like forced inout delegates in traits) that did come from originally unexpected usage cases. It is quite likely that re-designing it from scratch based on existing field experience would have yielded better results.
No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers.
 Policy-based design is more than one decade old, and older under other
 guises. Reference counting is many decades old. Both have been
 humongous success stories for C++.
Probably I have missed the point where new proposal was added but original one was not using true policy-based design but set of enum flags instead (no way to use user-defined policy).
Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment.
 Reference counting
 experience I am aware of shows that it is both successful in some cases
 and unapplicable for the others. But I don't know of any field
 experience that shows that chosing between RC and GC as a policy is a
 good/sufficient tool to minimize garbage creation in libraries - real
 issue we need to solve that original proposal does not mention at all.
That's totally fine. A good design can always add a few innovation on top of known territory. In fact we've done some experimenting at Facebook with fully collected PHP (currently it's reference counted). RC is well understood as an alternative/complement of tracing. Anyhow, discussion is what the Request For Comments is good for. But please let's focus on actionable stuff. I can't act on vague doubts.
 No need to trust me or anyone, but at some point decisions will be
 made. Most decisions don't make everybody happy. To influence them it
 suffices to argue your case properly. I hope you don't have the
 feeling appeal to authority is used to counter real arguments. I _do_
 trust my authority over someone else's, especially when I'm on hook
 for the decision made. I won't ever say "this is a disaster, but we
 did it because a guy on the forum said it'll work".
I don't want to waste your time arguing about irrelevant things simply because I have misinterprete how proposed solution fits the big picture. It is still unclear why proposed scheme is incompatible with tweaking Phobos utilities into input/output ranges. I am stipid and I am asking for detailed explanations before any arguments can be made :) And not just explanations for me but stuff anyone interested can find quickly.
Again: I don't have a complete design, that's why I'm asking for comments in the Request For Comments threads. Would you rather have me come up alone with a complete design and then show it to the community as a fait accompli? What part of "let's do this together" I need to clarify?
 This is closely related to SemVer topic. I'd love to see D3. And D4 soon
 after. And probably new prime version increase every year or two. This
 allows to tinker with really big changes without being concerned about
 how it will affect your code in next release.
Sorry, I'm not on board with this. I believe it does nothing than balkanize the community, and there's plenty of evidence from other languages (Perl, Python). Microsoft could afford to do it with C# only because they have lock-in with their user base, monopoly on tooling, and a simple transition story ("give us more money").
You risk balkanization by keeping the things as they are. We do have talks at work sometimes that simply forking the language may be a more practical approach than pushing necessary breaking changes upstream by the time D2 port is complete. Those are just talks of course and until porting is done it is all just speculations but it does indicate certain level of unhappinness.
It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward.
 Don has been mentioning that Sociomantic is all for breaking the code
 for the greater good and I fully agree with him. But introducing such
 surprise solutions creates a huge risk of either sticking with imperfect
 design and patching it (what we have now) or changing same stuff back
 and forth every basic release (and _that_ is bad).
I don't see what is surprising about my vision. It's simple and clear. C++ and GC. C++ and GC.
It came as surpise. It is unclear how long will it stay. It is unclear what exactly is the goal. Have you ever considered starting a blog about your vision of D development to communicate it better to wider audience? :)
Yah, apparently there's no shortage of ideas of things I should work on. Perhaps I should do the same. Dicebot, I think you should work on making exceptions refcounted :o). Andrei
Oct 06 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu 
wrote:
 I'm confused. Why would anyone who just comes to dlang.org see 
 unformed ideas and incomplete designs? Wouldn't newcomers be 
 more attracted by e.g. stuff coming in the next release?
Because he is interested in language development direction but does not want to actively participate? It can be someone with bad early D experience wondering if anything has changed in last year. Or it can be developer from some company using D wanting to get quick overview what to expect from the language for the next year or so. For example I don't have time to follow Rust mail lists or GitHub commits but I do read blog posts of its developers regularly (including speculative ones) to see where it is heading. It is both interesting and educating and helps to spread the image among wider audience as well.
 The fact that you don't seem to have a consensus with Walter 
 on some
 topic (auto-decoding, yeah) doesn't help either. Language 
 marketing is
 not about posting links on reddit, it is a very hard work of
 communicating your vision so that it is clear even to random 
 by-passer.
I think one good thing we can do is approach things in private before discussing them publicly.
Agreed. I don't propose to stop paying attention to forums or drop all discussions but to put a bit more efforts into popularizing resulting decisions and plans. So that someone can safely ignore some of discussions without fearing that it will surprisingly appear in next release catching one off guard.
 We now have Martin Nowak as the point of contact.
And what if he gets busy too? :)
Maybe you'll volunteer.
I have already considered that and can be pretty sure this won't ever happen (at least not while this implies paying to Apple a single cent) Let's get it straight - I don't care much about D success in general. It is a nice language to use here and there, I got an awesome job because of it but this is pretty much all the scope. There is no way I will ever work on something that is not needed to me only because it is important for language success in general. This is pretty much the difference between language author / core developer and random contributor and why handling releases is safer in the hands of former.
 No doubt its design could be done better. But inout was not 
 motivated theoretically. It came from the practical need of not 
 duplicating code over qualifiers.
I don't mean feature itself was "theoretical". I mean that it was implemented and released before it got at least some practical usage in live projects with relevant feedback and thus have missed some corner cases.
 Sean proposed that. In fact that's a very good success story of 
 sharing stuff for discussion sooner rather than later: he 
 answered a Request For Comments with a great comment.
Well when I have initially asked the same question (why not user-controllable policies?) you straight out rejected it. I must be very bad at wording questions :(
 Again: I don't have a complete design, that's why I'm asking 
 for comments in the Request For Comments threads. Would you 
 rather have me come up alone with a complete design and then 
 show it to the community as a fait accompli? What part of 
 "let's do this together" I need to clarify?
"let's do this together" implies agreeing on some base to further work on. When I come and see that proposed solution does not address a problem I have at all I can't do anything but ask "how is this supposed to address my problem?" because that is _your_ proposal and I am not gifted with telepathy. Especially because you have stated that previous proposal (range-fication) which did fix the issue _for me_ is not on the table anymore.
 You risk balkanization by keeping the things as they are. We 
 do have
 talks at work sometimes that simply forking the language may 
 be a more
 practical approach than pushing necessary breaking changes 
 upstream by
 the time D2 port is complete. Those are just talks of course 
 and until
 porting is done it is all just speculations but it does 
 indicate certain
 level of unhappinness.
It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
 Have you ever considered starting a blog about your vision of D
 development to communicate it better to wider audience? :)
Yah, apparently there's no shortage of ideas of things I should work on. Perhaps I should do the same. Dicebot, I think you should work on making exceptions refcounted :o).
As soon as it becomes a priority issue for me or Sociomantic (likely latter as I don't do much private D stuff anymore). However your attempt to be sarcastic here does indicate that you have totally missed the point I was stressing in original comment. Writing a blog post once in a few months is hardly an effort comparable to reimplementing exceptions management but is much more important long term because no one but you can do it. In this sense, yes, it is much more pragmatical to wait for someone like me to work on reference counted exceptions and for you to focus on communication instead. Worst thing that can happen is that nothing gets done which is still better than something unexpected and disruptive getting done.
Oct 06 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via Digitalmars-d wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
[...]
It would be terrific if Sociomantic would improve its communication
with the community about their experience with D and their needs
going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. T -- Too many people have open minds but closed eyes.
Oct 06 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Or, if you'll allow me to paraphrase it, pay the one-time cost 
 of broken
 code now, rather than incur the ongoing cost of needing to 
 continually
 workaround language issues.
Don in this very thread. Multiple times.
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 12:00 PM, Dicebot wrote:
 On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d
 wrote:
 Or, if you'll allow me to paraphrase it, pay the one-time cost of broken
 code now, rather than incur the ongoing cost of needing to continually
 workaround language issues.
Don in this very thread. Multiple times.
He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei
Oct 06 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Monday, 6 October 2014 at 19:08:24 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 12:00 PM, Dicebot wrote:
 On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via 
 Digitalmars-d
 wrote:
 Or, if you'll allow me to paraphrase it, pay the one-time 
 cost of broken
 code now, rather than incur the ongoing cost of needing to 
 continually
 workaround language issues.
Don in this very thread. Multiple times.
He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei
And here we go again for the multiple alias this: I'm pleased to have seen that it will be merged sooner than later. Just to clarify, taking as an example our company: - TDPL is a very good training book for C++/Java minions, and turns them in, well, not-so-good-but-not-so-terrible D programmers. It solve the "boss" perplexity about "there's basically no markets for D language programmers: how can we hire them in the future?". For the chronicle, the next lecture is the EXCELLENT "D Templates: a tutorial", of Philippe Sigaud, an invaluable resource (thank Philippe for that!). - TDPL is exactly what Dicebot wrote: a plan! Having to bet on something, a CTO like me *likes* to bet on a good plan (like the A-Team!) - Being a good plan, and an ambitious one, as a company we scrutiny the efforts devoted to complete it, and that set the bar for future evaluation of the reliability of _future_ plans and proposal. As an example, the *not resolution* of the shared qualifier mess, has a costs in term of how reliable we judge other proposed improvements (I know, that may be not fare, but that's it). I'm not telling that the language must be crystallised, and I also understand that as times goes by, other priorities and good ideas may come up. As a company, we don't mind if we are discussing about ARC, GC, or C++ interop, but we care about the efforts and time placed on the _taken_ decision, especially for the _past_ plans, and we judge that care as strictly correlated to language maturity for business adoption. Just my 2c... again, no pun intended! ;-P --- /Paolo
Oct 06 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via Digitalmars-d wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
[...]
 It would be terrific if Sociomantic would improve its communication
 with the community about their experience with D and their needs
 going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later.
More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
Oct 06 2014
next sibling parent reply "Don" <x nospam.com> writes:
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via 
 Digitalmars-d wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei 
 Alexandrescu wrote:
[...]
 It would be terrific if Sociomantic would improve its 
 communication
 with the community about their experience with D and their 
 needs
 going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later.
More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins.
Oct 08 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 08/10/2014 9:20 pm, "Don via Digitalmars-d" <digitalmars-d puremagic.com>
wrote:
 On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via Digitalmars-d
wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
[...]
 It would be terrific if Sociomantic would improve its communication
 with the community about their experience with D and their needs
 going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later.
More particulars would be definitely welcome. I should add that
Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
 Exactly. C++ support is of no interest at all, and GC is something we
contribute to, rather than something we expect from the community.
 Interestingly we don't even care much about libraries, we've done
everything ourselves.
 So what do we care about? Mainly, we care about improving the core
product.
 In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished.
 At Sociomantic, we've been successful in our industry using only the
features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us!
 With something like C++ support, it's only going to win companies over
when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now.
 And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level.
 As I said in my Dconf 2013 talk -- I advocate a focus on Return On
Investment.
 I'd love to see us chasing the easy wins.
As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. C++ might have helped us years ago, but I already solved those issues creatively. Debugging can't be solved without tooling and compiler support.
Oct 08 2014
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via 
Digitalmars-d wrote:
 On 08/10/2014 9:20 pm, "Don via Digitalmars-d"
 So what do we care about? Mainly, we care about improving the 
 core
product.
 In general I think that in D we have always suffered from 
 spreading
ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished.
 And personally, I doubt that many companies would use D, even 
 if with
perfect C++ interop, if the toolchain stayed at the current level. As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority.
While it would be great if there were a company devoted to such D tooling, it doesn't exist right now. It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects. If anybody in the community cared as much about these features as you, they'd have done it already. I suggest you two open bugzilla issues for all these specific bugs or enhancements and put up bounties for their development. If you're not willing to do that, expecting the community to do work for you for free is just whining that is easily ignored.
Oct 08 2014
next sibling parent reply "Jonathan" <jadit2 gmail.com> writes:
My small list of D critiques/wishes from a pragmatic stance:

1) Replace the Stop the World GC
2) It would be great if dmd could provide a code-hinting 
facility, instead of relying on DCD which continually breaks for 
me. It would open more doors for editors to support better code 
completion.
3) Taking a hint from the early success of Flash, add Derelict3 
(or some basic OpenGL library) directly into Phobos. Despite some 
of the negatives (slower update cycle versus external lib), it 
would greatly add to D's attractiveness for new developers. I 
nearly left D after having a host issues putting Derelict3 into 
my project. If I had this issue, we may be missing out from 
attracting newbies looking to do gfx related work.

I'm sure this has been talked about, but I'll bring it up anyway:
To focus our efforts, consider switching to ldc. Is it worth 
people's time to continue to optimize DMD when we can accelerate 
our own efforts by relying on an existing compiler? As some have 
pointed out, our community is spread thin over so many efforts... 
perhaps there are ways to consolidate that.

Just my 2cents from a D hobbyist..
Oct 08 2014
next sibling parent Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, Oct 8, 2014 at 12:00 PM, Jonathan via Digitalmars-d <
digitalmars-d puremagic.com> wrote:
...

 3) Taking a hint from the early success of Flash, add Derelict3 (or some
 basic OpenGL library) directly into Phobos. Despite some of the negatives
 (slower update cycle versus external lib), it would greatly add to D's
 attractiveness for new developers. I nearly left D after having a host
 issues putting Derelict3 into my project. If I had this issue, we may be
 missing out from attracting newbies looking to do gfx related work.
Personally I take the opposite view - I'd much prefer a strong and easily consumed third-party library ecosystem than to shove everything into Phobos. Dub is a wonderful thing for D, and needs to be so good that people use it by default.
Oct 08 2014
prev sibling parent "K.K." <trampzy yahoo.com> writes:
On Wednesday, 8 October 2014 at 19:00:44 UTC, Jonathan wrote:
 3) Taking a hint from the early success of Flash, add Derelict3 
 (or some basic OpenGL library) directly into Phobos. Despite 
 some of the negatives (slower update cycle versus external 
 lib), it would greatly add to D's attractiveness for new 
 developers. I nearly left D after having a host issues putting 
 Derelict3 into my project. If I had this issue, we may be 
 missing out from attracting newbies looking to do gfx related 
 work.
This reminds of an idea I've been pondering over for a while now. What if there was a language, that came with a standard toolkit for the more fun stuff such as OpenGL (There could be one already and I just don't know of it). But if we take that idea and try to apply it to D, we sortof get Deimos. Problem is Deimos, is pretty disjointed and is only updated every now and then, so then as an alternative I suppose there is Derelict. However, Derelict is maintained primarily by one person it seems (he does a great job though!), but Derelict isn't a standard feature (I know Deimos isn't either) and I *personally* don't care much for it's heavy leaning on dub. +Derelict isn't always a walk in the park to get running The alternative I'm suggesting, not by any means a top priority, is give Deimos a makeover (Derelict could possibly be a big part of this) and turn it into a semi-standard feature. So you can import phobos modules to do the stuff phobos normally does, but if you feel like making a quick tool or two, you can import deimos to get Tcl/tk like you would in python, or call OpenGl, or whatever other tool you need (doesn't have to be a graphics thing). Then at compile time the compiler could just copy or build the required dll's\so's & object files into the specified directory, or whatever works best. On Wednesday, 8 October 2014 at 19:47:05 UTC, Jeremy Powers via Digitalmars-d wrote:
 Personally I take the opposite view - I'd much prefer a strong 
 and easily
 consumed third-party library ecosystem than to shove everything 
 into
 Phobos.  Dub is a wonderful thing for D, and needs to be so 
 good that
 people use it by default.
Not to initiate my biweekly "not a fan of dub" conversation, but just wanna say real quick: Not everyone really likes to use dub. The only thing I like about it, is using it as the build script for a library to get the .lib files and whatnot. Though I don't feel like it really adds a drastic improvement over a .d build script. However, I don't work on any open source libraries, but maybe if I did, I'd like it better then..? Not something I would have an answer to right now, soo... yea:P ---- Aside from what I mentioned above, I'm not sure where I'd like D to be at next to be perfectly honest. Stuff like no GC or C++ integration sound cool, but for me personally they just seem like 'neat' feature, not something that I feel like would change my current workflow for better or worse. Refinement of what's already in place sounds the best if anything. So those are just some passing thoughts of a stranger.. carry on, this thread has been very interesting so far ;P
Oct 11 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 09/10/2014 2:40 am, "Joakim via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via Digitalmars-d
wrote:
 On 08/10/2014 9:20 pm, "Don via Digitalmars-d"
 So what do we care about? Mainly, we care about improving the core
product.
 In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished.
 And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level. As someone who previously represented a business interest, I couldn't
agree
 more.
 Aside from my random frustrated outbursts on a very small set of language
 issues, the main thing I've been banging on from day 1 is the tooling.
Much
 has improved, but it's still a long way from 'good'.

 Debugging, ldc (for windows), and editor integrations (auto complete,
 navigation, refactoring tools) are my impersonal (and hopefully
 non-controversial) short list. They trump everything else I've ever
 complained about.
 The debugging experience is the worst of any language I've used since the
 90's, and I would make that top priority.
While it would be great if there were a company devoted to such D
tooling, it doesn't exist right now. It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects. If anybody in the community cared as much about these features as you, they'd have done it already.
 I suggest you two open bugzilla issues for all these specific bugs or
enhancements and put up bounties for their development. If you're not willing to do that, expecting the community to do work for you for free is just whining that is easily ignored. We're just talking about what we think would best drive adoption. Businesses aren't likely to adopt a language with the understanding that they need to write it's tooling. Debugging, code competition and refactoring are all expert tasks that probably require compiler involvement. I know it's easy to say that businesses with budget should contribute more. But it's a tough proposition. Businesses will look to change language if it saves them time and money. If it's going to cost them money, and the state of tooling is likely to cost them time, then it's not a strong proposition. It's a chicken and egg problem. I'm sure business will be happy to contribute financially when it's a risk free investment; ie, when it's demonstrated that that stuff works for them.
Oct 08 2014
prev sibling parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
 While it would be great if there were a company devoted to such D tooling,
 it doesn't exist right now.  It is completely unrealistic to expect a D
 community of unpaid volunteers to work on these features for your paid
 projects.  If anybody in the community cared as much about these features as
 you, they'd have done it already.
It might be unfair but it is still a massive problem. The tooling compared to what I have with say C++ and Qt is not a fun experience. The language is nicer but the difference in tooling is making the difference seem a lot smaller than it should be.
Oct 09 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 09:37:29 UTC, Danni Coy via 
Digitalmars-d wrote:
 It might be unfair but it is still a massive problem. The 
 tooling
 compared to what I have with say C++ and Qt is not a fun 
 experience.
 The language is nicer but the difference in tooling is making 
 the
 difference seem a lot smaller than it should be.
This tooling does not exist in C++ magically. It exists there because many people were willing to work on it and much more were willing to pay for it. So unless you personally are ready to do one of those things those expectations will never come true.
Oct 09 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 Debugging, ldc (for windows), and editor integrations (auto 
 complete,
 navigation, refactoring tools) are my impersonal (and hopefully
 non-controversial) short list. They trump everything else I've
I don't know how well DCD works with other editors, but in Emacs at least (when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies.
 The debugging experience is the worst of any language I've used 
 since the
 90's, and I would make that top priority.
Debugging can definitely be improved on. Even with Iain's fork of gdb I end up using writeln instead because it's frequently easier. Atila
Oct 09 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 09/10/2014 10:15 pm, "Atila Neves via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 Debugging, ldc (for windows), and editor integrations (auto complete,
 navigation, refactoring tools) are my impersonal (and hopefully
 non-controversial) short list. They trump everything else I've
I don't know how well DCD works with other editors, but in Emacs at least
(when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies. I haven't found a way to make use of dub yet; all my projects involve other languages too. Also, I'm a primary windows user, so I haven't tried DCD to any great length. Alexander's auto complete is getting better, but it still gets easily confused, and the refactor and navigation tools are still basically missing. I feel like it would all be much easier if dmd was a lib that tooling could make use of. It seems like a lot of redundant effort to rewrite the language parser over and over when dmd already does it perfectly... Dan Murphy seemed to think ddmd would have some focus on usage as a lib?
 The debugging experience is the worst of any language I've used since the
 90's, and I would make that top priority.
Debugging can definitely be improved on. Even with Iain's fork of gdb I
end up using writeln instead because it's frequently easier. Iain's work doesn't help on windows sadly. But I think the biggest problem is the local scope doesn't seem to be properly expressed in the debug info. It's a compiler problem more than a back end problem. The step cursor is all over the shop, and local variables alias each other and confuse the debugger lots. Also I can't inspect the contents of classes.
Oct 09 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu via Digitalmars-d" <digitalmars-d puremagic.com> wrote in message 
news:mailman.559.1412859804.9932.digitalmars-d puremagic.com...

 Dan Murphy seemed to think ddmd would have some focus on usage as a lib?
Yes, but it's a long way off.
Oct 09 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 08/10/2014 11:55 pm, "Manu" <turkeyman gmail.com> wrote:
 On 08/10/2014 9:20 pm, "Don via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via Digitalmars-d
wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
[...]
 It would be terrific if Sociomantic would improve its communication
 with the community about their experience with D and their needs
 going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what
can
 be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break
our
 code *now*, if it helps to fix language design issues, rather than
 later.
More particulars would be definitely welcome. I should add that
Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
 Exactly. C++ support is of no interest at all, and GC is something we
contribute to, rather than something we expect from the community.
 Interestingly we don't even care much about libraries, we've done
everything ourselves.
 So what do we care about? Mainly, we care about improving the core
product.
 In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished.
 At Sociomantic, we've been successful in our industry using only the
features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us!
 With something like C++ support, it's only going to win companies over
when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now.
 And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level.
 As I said in my Dconf 2013 talk -- I advocate a focus on Return On
Investment.
 I'd love to see us chasing the easy wins.
As someone who previously represented a business interest, I couldn't
agree more.
 Aside from my random frustrated outbursts on a very small set of language
issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'.
 Debugging, ldc (for windows), and editor integrations (auto complete,
navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about.
 The debugging experience is the worst of any language I've used since the
90's, and I would make that top priority.
 C++ might have helped us years ago, but I already solved those issues
creatively. Debugging can't be solved without tooling and compiler support. Just to clarify, I'm all for nogc work; that is very important to us and I appreciate the work, but I support that I wouldn't rate it top priority. C++ is no significant value to me personally, or professionally. Game studios don't use much C++, and like I said, we already worked around those edges. I can't speak for remedy now, but I'm confident that they will *need* ldc working before the game ships. DMD codegen is just not good enough, particularly relating to float; it uses the x87! O_O
Oct 08 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/8/2014 4:17 AM, Don wrote:
 As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment.
 I'd love to see us chasing the easy wins.
I love the easy wins, too. It'd be great if you'd start a thread about "Top 10 Easy Wins" from yours and Sociomantic's perspective. Note that I've done some work on the deprecations you've mentioned before.
Oct 08 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 October 2014 at 20:07:09 UTC, Walter Bright wrote:
 On 10/8/2014 4:17 AM, Don wrote:
 As I said in my Dconf 2013 talk -- I advocate a focus on 
 Return On Investment.
 I'd love to see us chasing the easy wins.
I love the easy wins, too. It'd be great if you'd start a thread about "Top 10 Easy Wins" from yours and Sociomantic's perspective. Note that I've done some work on the deprecations you've mentioned before.
That can possibly be done though it will take some efforts to formalize issues from the casual chat rants. More important issue is - what will happen next? I am pretty sure many of those easy wins are not easy at all in a sense that breaking changes are needed.
Oct 09 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/9/2014 7:15 AM, Dicebot wrote:
 That can possibly be done though it will take some efforts to formalize issues
 from the casual chat rants. More important issue is - what will happen next? I
 am pretty sure many of those easy wins are not easy at all in a sense that
 breaking changes are needed.
That's why I'd like to know what Don has in mind.
Oct 09 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/8/14, 4:17 AM, Don wrote:
 On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
 More particulars would be definitely welcome. I should add that
 Sociomantic has an interesting position: it's a 100% D shop so
 interoperability is not a concern for them, and they did their own GC
 so GC-related improvements are unlikely to make a large difference for
 them. So "C++ and GC" is likely not to be high priority for them. --
 Andrei
Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community.
That's awesome, thanks!
 Interestingly we don't even care much about libraries, we've done
 everything ourselves.

 So what do we care about? Mainly, we care about improving the core product.

 In general I think that in D we have always suffered from spreading
 ourselves too thin. We've always had a bunch of cool new features that
 don't actually work properly. Always, the focus shifts to something
 else, before the previous feature was finished.

 At Sociomantic, we've been successful in our industry using only the
 features of D1. We're restricted to using D's features from 2007!!
 Feature-wise, practically nothing from the last seven years has helped us!

 With something like C++ support, it's only going to win companies over
 when it is essentially complete. That means that working on it is a huge
 investment that doesn't start to pay for itself for a very long time. So
 although it's a great goal, with a huge potential payoff, I don't think
 that it should be consuming a whole lot of energy right now.

 And personally, I doubt that many companies would use D, even if with
 perfect C++ interop, if the toolchain stayed at the current level.
That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is "special".
 As I said in my Dconf 2013 talk -- I advocate a focus on Return On
 Investment.
 I'd love to see us chasing the easy wins.
That's of course good, but the reality is we're in a complicated trade-off space with "important", "urgent", "easy to do", "return on investment", "resource allocation" as axes. An example of the latter - ideally we'd put Walter on the more difficult tasks and others on the easy wins. Walter working on improving documentation might not be the best use of his time, although better documentation is an easy win. Andrei
Oct 08 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 8 October 2014 at 20:35:05 UTC, Andrei Alexandrescu 
wrote:
 On 10/8/14, 4:17 AM, Don wrote:
 On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
 wrote:

 And personally, I doubt that many companies would use D, even 
 if with
 perfect C++ interop, if the toolchain stayed at the current 
 level.
That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is "special".
Well, when IMHO, when discussing 'strategies', pretty everything it's a speculation... C++ interlope can also be attrattive when you need to start a new project, a you need C++ libs. But, the point it's that, again, IMHO, you tend to conflate Facebook need with D need (I know I'll receive pain back for this ;-). Sociomantic is not so special at all, about not having a previous C++ codebase: I personally know plenty of cases like that. But if D don't stop thinking about "new feature" and never terminate the previous plans, well, my speculations is that I donno about future adopters, but for sure it's scouring actual adopters; and the for sure it's based on what we feel here in SR Labs company.
 That's of course good, but the reality is we're in a 
 complicated trade-off space with "important", "urgent", "easy 
 to do", "return on investment", "resource allocation" as axes. 
 An example of the latter - ideally we'd put Walter on the more 
 difficult tasks and others on the easy wins. Walter working on 
 improving documentation might not be the best use of his time, 
 although better documentation is an easy win.
Well, I've read your and Walter comment on the multiple alias this PR, so good: but the point that it was the community that pushed both of you on that track, it's systematic about an attitude. And now, shields up, Ms Sulu! -- /Paolo
Oct 08 2014
prev sibling parent "yawniek" <dlang srtnwz.com> writes:
 Exactly. C++ support is of no interest at all, and GC is 
 something we contribute to, rather than something we expect 
 from the community.
 Interestingly we don't even care much about libraries, we've 
 done everything ourselves.

 So what do we care about? Mainly, we care about improving the 
 core product.

 In general I think that in D we have always suffered from 
 spreading ourselves too thin. We've always had a bunch of cool 
 new features that don't actually work properly. Always, the 
 focus shifts to something else, before the previous feature was 
 finished.

 At Sociomantic, we've been successful in our industry using 
 only the features of D1. We're restricted to using D's features 
 from 2007!! Feature-wise, practically nothing from the last 
 seven years has helped us!

 With something like C++ support, it's only going to win 
 companies over when it is essentially complete. That means that 
 working on it is a huge investment that doesn't start to pay 
 for itself for a very long time. So although it's a great goal, 
 with a huge potential payoff, I don't think that it should be 
 consuming a whole lot of energy right now.

 And personally, I doubt that many companies would use D, even 
 if with perfect C++ interop, if the toolchain stayed at the 
 current level.

 As I said in my Dconf 2013 talk -- I advocate a focus on Return 
 On Investment.
 I'd love to see us chasing the easy wins.
disclaimer: i am rather new to D and thus have a bit of a distant view. i think the above touches an important point. One thing GO does right is that they focused on feature rich stdlib/library ecosystem even though the language was very young. i'm coming from Ruby/Python and the reason i use those languages is that they have two things: a) they are fun to use (as andrei said in the floss interview: the creators had "taste"). b) huge set of libs that help me to get stuff done. now i think a) is fine, but with b) i am not sure if the strategy to get full C/C++ interop will not take too long and scare those people off that are not coming from C/C++. i think D is a fantastic tool to write expressive, fast and readable code. I don't need much more language features (again, look at GO...) but a solid foundation of libs to gain "competitive advantage" in my daily work.
Oct 11 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via 
 Digitalmars-d wrote:
 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei 
 Alexandrescu wrote:
[...]
 It would be terrific if Sociomantic would improve its 
 communication
 with the community about their experience with D and their 
 needs
 going forward.
How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear.
I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later.
More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
Yes and this is exactly why I am that concerned about recent memory management policy thread. Don has already stated it in his talks but I will repeat important points: 1) We don't try to avoid GC in any way 2) However it is critical for performance to avoid creating garbage in a form of new GC roots 3) Worst part of Phobos is not GC allocations but specifically lot of temporarily garbage allocations This is a very simple issue that will prevent us from using and contributing to majority of Phobos even when D2 port is finished. Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. This is especially dissapointing because it was a first time when declared big effort seemed to help our needs but it got abandoned after very first attempts.
Oct 09 2014
next sibling parent reply "ixid" <adamsibson hotmail.com> writes:
Dicebot wrote:

 Switch to input/output ranges as API fundamentals was supposed 
 to fix it. Custom management policies as you propose won't fix 
 it at all because garbage will still be there, simply managed 
 in a different way.
Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't.
Oct 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
 Dicebot wrote:

 Switch to input/output ranges as API fundamentals was supposed 
 to fix it. Custom management policies as you propose won't fix 
 it at all because garbage will still be there, simply managed 
 in a different way.
Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't.
Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us). Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing.
Oct 09 2014
parent reply "ixid" <adamsibson hotmail.com> writes:
On Thursday, 9 October 2014 at 14:47:00 UTC, Dicebot wrote:
 On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
 Dicebot wrote:

 Switch to input/output ranges as API fundamentals was 
 supposed to fix it. Custom management policies as you propose 
 won't fix it at all because garbage will still be there, 
 simply managed in a different way.
Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't.
Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us). Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing.
Multiple approaches to how library functions can handle memory.
Oct 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
 Multiple approaches to how library functions can handle memory.
As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.
Oct 09 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
"Dicebot" <public dicebot.lv> wrote:
 On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
 Multiple approaches to how library functions can handle memory.
As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.
To clarify: calling GC.free does remove the root, correct?
Oct 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu 
wrote:
 "Dicebot" <public dicebot.lv> wrote:
 On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
 Multiple approaches to how library functions can handle 
 memory.
As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.
To clarify: calling GC.free does remove the root, correct?
Not before it creates one. When I mean "avoid creating new GC roots" I mean "no GC activity at all other than extending existing chunks"
Oct 09 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/9/14, 9:00 AM, Dicebot wrote:
 On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu wrote:
 "Dicebot" <public dicebot.lv> wrote:
 On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
 Multiple approaches to how library functions can handle memory.
As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.
To clarify: calling GC.free does remove the root, correct?
Not before it creates one. When I mean "avoid creating new GC roots" I mean "no GC activity at all other than extending existing chunks"
That's interesting. So GC.malloc followed by GC.free does actually affect things negatively? Also let's note that extending existing chunks may result in new allocations. Andrei
Oct 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu 
wrote:
 To clarify: calling GC.free does remove the root, correct?
Not before it creates one. When I mean "avoid creating new GC roots" I mean "no GC activity at all other than extending existing chunks"
That's interesting. So GC.malloc followed by GC.free does actually affect things negatively?
Yes and quite notably so as GC.malloc can potentially trigger collection. With concurrent GC collection is not a disaster but it still affects the latency and should be avoided.
 Also let's note that extending existing chunks may result in 
 new allocations.
Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup. Don has mentioned this as one of important points during his DConf 2014 talk but it probably didn't catch as much attention as it should.
Oct 09 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote:
 On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei 
 Alexandrescu wrote:
 To clarify: calling GC.free does remove the root, correct?
Not before it creates one. When I mean "avoid creating new GC roots" I mean "no GC activity at all other than extending existing chunks"
That's interesting. So GC.malloc followed by GC.free does actually affect things negatively?
Yes and quite notably so as GC.malloc can potentially trigger collection. With concurrent GC collection is not a disaster but it still affects the latency and should be avoided.
Is it just the potentially triggered collection, or is the actual allocation+deallocation too expensive? Because the effects of the former can of course be reduced greatly by tweaking the GC to not collect every time the heap needs to grow, at the cost of slightly more memory consumption. If it's the latter, that would indicate that maybe a different allocator with less overhead needs to be used.
 Also let's note that extending existing chunks may result in 
 new allocations.
Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup.
Hmm... but shouldn't this just as well apply to the temporary allocations? After some warming up phase, the available space on the heap should be large enough that all further temporary allocations can be satisfied without growing the heap.
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote:
 On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote:
 On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei 
 Alexandrescu wrote:
I think the worst of D is summarized quite well by the following: http://forum.dlang.org/post/m15i9c$51b$1 digitalmars.com http://forum.dlang.org/post/54374DE0.6040405 digitalmars.com And that is: the focus is no longer to do the right things about D, but to make D do the right thing for some shadowy customers that don't even care enough to come here and grumble. Let's put D2 in maintenance mode and take on D3 with this nice motto, taken from here: http://forum.dlang.org/post/3af85684-7728-4165-acf9-520a240f65e0 me.com "why didn't work like that from the beginning?"
Oct 10 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote:
 Yes and quite notably so as GC.malloc can potentially trigger 
 collection. With concurrent GC collection is not a disaster 
 but it still affects the latency and should be avoided.
Is it just the potentially triggered collection, or is the actual allocation+deallocation too expensive?
collection - for sure. allocation+deallocation - maybe, I have never measured it. It is surely slower than not allocating at all though.
 Because the effects of the former can of course be reduced 
 greatly by tweaking the GC to not collect every time the heap 
 needs to grow, at the cost of slightly more memory consumption.
This is likely to work better but still will be slower than our current approach because of tracking many small objects. Though of course it is just speculation until RC stuff is implemented for experiments.
 Also let's note that extending existing chunks may result in 
 new allocations.
Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup.
Hmm... but shouldn't this just as well apply to the temporary allocations? After some warming up phase, the available space on the heap should be large enough that all further temporary allocations can be satisfied without growing the heap.
I am not speaking about O(1) internal heap increases but O(1) GC.malloc calls Typical pattern is to encapsulate "temporary" buffer with the algorithm in a single class object and never release it, reusing with new incoming requests (wiping the buffer data each time). Such buffer quickly gets to the point where it is large enough to contain all algorithm temporaries for a single request and never touches GC from there. In a well-written program which follows such pattern there are close to zero temporaries and GC only manages more persistent entities like cache elements.
Oct 10 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 11 October 2014 at 03:39:10 UTC, Dicebot wrote:
 I am not speaking about O(1) internal heap increases but O(1) 
 GC.malloc calls
 Typical pattern is to encapsulate "temporary" buffer with the 
 algorithm in a single class object and never release it, 
 reusing with new incoming requests (wiping the buffer data each 
 time). Such buffer quickly gets to the point where it is large 
 enough to contain all algorithm temporaries for a single 
 request and never touches GC from there.

 In a well-written program which follows such pattern there are 
 close to zero temporaries and GC only manages more persistent 
 entities like cache elements.
I understand that. My argument is that the same should apply to the entire heap: After you've allocated and released a certain amount of objects via GC.malloc() and GC.free(), the heap will have grown to a size large enough that any subsequent allocations of temporary objects can be satisfied from the existing heap without triggering a collection, so that only the overhead of actual allocation and freeing should be relevant.
Oct 11 2014
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 09:26:28 UTC, Marc Schütz wrote:
 I understand that. My argument is that the same should apply to 
 the entire heap: After you've allocated and released a certain 
 amount of objects via GC.malloc() and GC.free(), the heap will 
 have grown to a size large enough that any subsequent 
 allocations of temporary objects can be satisfied from the 
 existing heap without triggering a collection, so that only the 
 overhead of actual allocation and freeing should be relevant.
But it still requires GC to check its pool state upon each request and make relevant adjustments for malloc/free combo. For something like a hundred of temporary allocations per request it accumulates into notable time (and milliseconds matter). In absence of collection it is cheap enough to not care about single malloc call on its own but still not cheap enough to ignore costs of many calls. You have interested me in doing some related benchmarks though.
Oct 11 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/9/14, 7:09 AM, Dicebot wrote:
 Yes and this is exactly why I am that concerned about recent memory
 management policy thread. Don has already stated it in his talks but I
 will repeat important points:

 1) We don't try to avoid GC in any way
 2) However it is critical for performance to avoid creating garbage in a
 form of new GC roots
 3) Worst part of Phobos is not GC allocations but specifically lot of
 temporarily garbage allocations
What would be a few good examples of (3)? Thanks.
 This is a very simple issue that will prevent us from using and
 contributing to majority of Phobos even when D2 port is finished.

 Switch to input/output ranges as API fundamentals was supposed to fix
 it.
Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely. Walter and I have only recently achieved clarity on this.
 Custom management policies as you propose won't fix it at all
 because garbage will still be there, simply managed in a different way.
I'm not sure I understand this.
 This is especially dissapointing because it was a first time when
 declared big effort seemed to help our needs but it got abandoned after
 very first attempts.
It hasn't gotten abandoned; it's on the back burner. Lazification is a good thing to do, but won't get us closer to taking the garbage out. Andrei
Oct 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu 
wrote:
 On 10/9/14, 7:09 AM, Dicebot wrote:
 Yes and this is exactly why I am that concerned about recent 
 memory
 management policy thread. Don has already stated it in his 
 talks but I
 will repeat important points:

 1) We don't try to avoid GC in any way
 2) However it is critical for performance to avoid creating 
 garbage in a
 form of new GC roots
 3) Worst part of Phobos is not GC allocations but specifically 
 lot of
 temporarily garbage allocations
What would be a few good examples of (3)? Thanks.
Infamous setExtensions (https://github.com/D-Programming-Language/phobos/blob/master/std/path.d#L843) immediately comes to mind. Usage of concatenation operators there allocates a new GC root for a new string.
 This is a very simple issue that will prevent us from using and
 contributing to majority of Phobos even when D2 port is 
 finished.

 Switch to input/output ranges as API fundamentals was supposed 
 to fix
 it.
Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely.
Are you trying to tell me programs I work with do not exist? :) Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Usage of input ranges is less important but it fits existing Phobos style better. We also don't usually reclaim resources. Out application usually work by growing constant amount of buffers to the point where they can handle routine workload and staying there will almost 0 GC activity. I don't understand statement about storing the ranges. The way I have it in mind ranges are tool for algorithm composition. Once you want to store it as a struct field you force range evaluation via output range and store resulting allocated buffer. In user code.
 Custom management policies as you propose won't fix it at all
 because garbage will still be there, simply managed in a 
 different way.
I'm not sure I understand this.
Typical pattern from existing D1 code: // bad auto foo(char[] arg) { return arg ~ "aaa"; } vs // good auto foo(char[] arg, ref char[] result) { result.length = arg.length +3; // won't allocate if already has capacity result[0 .. arg.length] = arg[]; result[arg.length .. arg.length + 3] = "aaa"[]; } It doesn't matter if first snippet allocates GC root or ref-counted root. We need the version that does not allocate new root at all (second snippet).
Oct 09 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Oct 2014 15:57:15 +0000
schrieb "Dicebot" <public dicebot.lv>:

 Unfortunately it doesn't. RC does. Lazy computation relies on 
 escaping ranges all over the place (i.e. as fields inside 
 structs implementing the lazy computation). If there's no way 
 to track those many tidbits, resources cannot be reclaimed 
 timely.  
Are you trying to tell me programs I work with do not exist? :) Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Usage of input ranges is less important but it fits existing Phobos style better. We also don't usually reclaim resources. Out application usually work by growing constant amount of buffers to the point where they can handle routine workload and staying there will almost 0 GC activity. I don't understand statement about storing the ranges. The way I have it in mind ranges are tool for algorithm composition. Once you want to store it as a struct field you force range evaluation via output range and store resulting allocated buffer. In user code.
I think Andrei means at some point you have to 'store the range' or create an (often dynamic) array from the range and then you still need some sort of memory management. Ultimately you still need some sort of memory management there and RC will be nice for that if you don't want to use the GC. You can also store the range to a stack buffer or use manual memory management. But ranges alone do not solve this problem and forcing everyone to do manual memory management is not a good replacement for GC, so we need the discussed RC scheme. At least this is how I understood Andrei's point.
Oct 09 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/9/14, 9:27 AM, Johannes Pfau wrote:
 Am Thu, 09 Oct 2014 15:57:15 +0000
 schrieb "Dicebot" <public dicebot.lv>:

 Unfortunately it doesn't. RC does. Lazy computation relies on
 escaping ranges all over the place (i.e. as fields inside
 structs implementing the lazy computation). If there's no way
 to track those many tidbits, resources cannot be reclaimed
 timely.
Are you trying to tell me programs I work with do not exist? :) Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Usage of input ranges is less important but it fits existing Phobos style better. We also don't usually reclaim resources. Out application usually work by growing constant amount of buffers to the point where they can handle routine workload and staying there will almost 0 GC activity. I don't understand statement about storing the ranges. The way I have it in mind ranges are tool for algorithm composition. Once you want to store it as a struct field you force range evaluation via output range and store resulting allocated buffer. In user code.
I think Andrei means at some point you have to 'store the range' or create an (often dynamic) array from the range and then you still need some sort of memory management. Ultimately you still need some sort of memory management there and RC will be nice for that if you don't want to use the GC. You can also store the range to a stack buffer or use manual memory management. But ranges alone do not solve this problem and forcing everyone to do manual memory management is not a good replacement for GC, so we need the discussed RC scheme. At least this is how I understood Andrei's point.
Yes, that's accurate. Thanks! -- Andrei
Oct 09 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/9/14, 8:57 AM, Dicebot wrote:
 On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu wrote:
 Unfortunately it doesn't. RC does. Lazy computation relies on escaping
 ranges all over the place (i.e. as fields inside structs implementing
 the lazy computation). If there's no way to track those many tidbits,
 resources cannot be reclaimed timely.
Are you trying to tell me programs I work with do not exist? :)
In all likelihood it's a small misunderstanding.
 Usage of output range is simply a generalization of out array parameter
 used in both Tango and our code. It is _already_ proved to work for our
 cases.
Got it. Output ranges work great with unstructured/linear outputs - preallocate an array, fill it with stuff, all's nice save for the occasional reallocation when things don't fit etc. With structured outputs there are a lot more issues to address: one can think of a JSONObject as an output range with put() but that's only moving the real issues around. How would the JSONObject allocate memory internally, give it out to its own users, and dispose of it timely, all in good safety? That's why JSON tokenization is relatively easy to do lazily/with output ranges, but full-blown parsing becomes a different proposition. Andrei
Oct 09 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 16:41:22 UTC, Andrei Alexandrescu 
wrote:
 Usage of output range is simply a generalization of out array 
 parameter
 used in both Tango and our code. It is _already_ proved to 
 work for our
 cases.
Got it. Output ranges work great with unstructured/linear outputs - preallocate an array, fill it with stuff, all's nice save for the occasional reallocation when things don't fit etc. With structured outputs there are a lot more issues to address: one can think of a JSONObject as an output range with put() but that's only moving the real issues around. How would the JSONObject allocate memory internally, give it out to its own users, and dispose of it timely, all in good safety? That's why JSON tokenization is relatively easy to do lazily/with output ranges, but full-blown parsing becomes a different proposition.
This reminds me of our custom binary serialization utilities, intentionally designed in a way that deserialization can happen in-place using same contiguous data buffer as serialized chunk. It essentially stores all indirections in the same buffer one after other. Implementation is far from being trivial and adds certain usage restrictions but it allows for the same extremely performant linear buffer approach even with non-linear data structures. In general I am not trying to argue that range-based approach is a silver bullet though. It isn't and stuff like ref counting will be necessary at least in some domains. What I am arguing is that it won't solve _our_ issues with Phobos (contrary to previous range-based proposal) and this is the reason for being dissapointed. Twice as so because you suggested to close PR that turns setExtension into range because of your new proposal (which implies that efforts can't co-exist)
Oct 09 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 09/10/14 18:41, Andrei Alexandrescu wrote:

 With structured outputs there are a lot more issues to address: one can
 think of a JSONObject as an output range with put() but that's only
 moving the real issues around. How would the JSONObject allocate memory
 internally, give it out to its own users, and dispose of it timely, all
 in good safety?
The XML DOM module in Tango uses, if I recall correctly, a free list internally for the nodes. It will reuse the nodes, if you want to keep some information you need to copy it yourself. -- /Jacob Carlborg
Oct 09 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2014 11:13 AM, Dicebot wrote:
 Especially because
 you have stated that previous proposal (range-fication) which did fix the issue
 _for me_ is not on the table anymore.
I think it's more stalled because of the setExtension controversy.
 How about someone starts paying attention to what Don posts? That could be an
 incredible start.
I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented.
Oct 08 2014
parent "Don" <x nospam.com> writes:
On Wednesday, 8 October 2014 at 21:07:24 UTC, Walter Bright wrote:
 On 10/6/2014 11:13 AM, Dicebot wrote:
 Especially because
 you have stated that previous proposal (range-fication) which 
 did fix the issue
 _for me_ is not on the table anymore.
I think it's more stalled because of the setExtension controversy.
 How about someone starts paying attention to what Don posts? 
 That could be an
 incredible start.
I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented.
Wow, thanks, Walter! I'm wrong pretty regularly, though. A reasonable rule of thumb is to ask Daniel Murphy, aka yebblies. If he disagrees with me, and I can't change his mind within 30 minutes, you can be certain that I'm wrong. <g>
Oct 09 2014
prev sibling next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

 Right now I have no idea where the development is headed and 
 what to expect from next few releases. I am not speaking about 
 wiki.dlang.org/Agenda but about bigger picture. Unexpected 
 focus on C++ support, thread about killing auto-decoding, 
 recent ref counting proposal
Just to add more salt: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx Raymond Chen: " When you ask somebody what garbage collection is, the answer you get is probably going to be something along the lines of "Garbage collection is when the operating environment automatically reclaims memory that is no longer being used by the program. It does this by tracing memory starting from roots to identify which objects are accessible." This description confuses the mechanism with the goal. It's like saying the job of a firefighter is "driving a red truck and spraying water." That's a description of what a firefighter does, but it misses the point of the job (namely, putting out fires and, more generally, fire safety). Garbage collection is simulating a computer with an infinite amount of memory. The rest is mechanism. And naturally, the mechanism is "reclaiming memory that the program wouldn't notice went missing." It's one giant application of the as-if rule." Interesting, in the comments, the distinction that is made between finalizers and destructors, even if they happen to have the same syntax, for example in C# and C++. For example here: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776 I feel difficult to swallow the fact that D classes do not lend themselves to RAII. While I could accept the memory management could be left outside RAII, running destructors (or disposers) deterministically is a must. I particularily find bad that D recommends using structs to free resources because the destructor of those is run automatically. Just look at this example: http://dlang.org/cpptod.html#raii struct File { Handle h; ~this() { h.release(); } } void test() { if (...) { auto f = File(); ... } // f.~this() gets run at closing brace, even if // scope was exited via a thrown exception } Even if C++ structs are almost the same as classes, the logical solit between the two is: structs are DATA, classes are BEHAVIOR. I will not get my head around the fact that I will *recommend* putting methods in a struct.
Oct 05 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

 Right now I have no idea where the development is headed and what to
 expect from next few releases. I am not speaking about
 wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on
 C++ support, thread about killing auto-decoding, recent ref counting
 proposal
Just to add more salt: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx Raymond Chen: " When you ask somebody what garbage collection is, the answer you get is probably going to be something along the lines of "Garbage collection is when the operating environment automatically reclaims memory that is no longer being used by the program. It does this by tracing memory starting from roots to identify which objects are accessible." This description confuses the mechanism with the goal. It's like saying the job of a firefighter is "driving a red truck and spraying water." That's a description of what a firefighter does, but it misses the point of the job (namely, putting out fires and, more generally, fire safety). Garbage collection is simulating a computer with an infinite amount of memory. The rest is mechanism. And naturally, the mechanism is "reclaiming memory that the program wouldn't notice went missing." It's one giant application of the as-if rule." Interesting, in the comments, the distinction that is made between finalizers and destructors, even if they happen to have the same syntax, for example in C# and C++. For example here: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776 I feel difficult to swallow the fact that D classes do not lend themselves to RAII. While I could accept the memory management could be left outside RAII, running destructors (or disposers) deterministically is a must. I particularily find bad that D recommends using structs to free resources because the destructor of those is run automatically. Just look at this example: http://dlang.org/cpptod.html#raii struct File { Handle h; ~this() { h.release(); } } void test() { if (...) { auto f = File(); ... } // f.~this() gets run at closing brace, even if // scope was exited via a thrown exception } Even if C++ structs are almost the same as classes, the logical solit between the two is: structs are DATA, classes are BEHAVIOR. I will not get my head around the fact that I will *recommend* putting methods in a struct.
The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei
Oct 05 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 The main distinction between structs and classes in D is the 
 former are monomorphic value types and the later are 
 polymorphic reference types. -- Andrei
Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as "invalid". Later access to it shall triger an exception: "invalidObject". Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes?
Oct 05 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
 wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 The main distinction between structs and classes in D is the 
 former are monomorphic value types and the later are 
 polymorphic reference types. -- Andrei
Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as "invalid". Later access to it shall triger an exception: "invalidObject". Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes?
Form that page again: "I have found (dislcaimer: this is my experience, your mileage will vary) that because 90% of the time you don't need to worry about releasing a resource in C#, it is easy to forget to do a "using" the remaining 10%. In C++ you always need to worry about it, which makes it real easy to remember that when obtaining a resource make sure you have taken care of its release as well. (In essence, make sure it is stored in something whose destructor will free it). I have found this pattern a lot harder to follow in C# than in C++. Having said all that, there is a lot to like about .NET and C# as well. I just personally find that the whole "garbage collector saves you" aspect that is pitched in every intro to the language I have encountered more of a trap than a salvation."
Oct 05 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:
 On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
 wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
I like the safety that a GC guarantees, but is a too big price to be paid for that...
Oct 05 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
 On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:
 On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei 
 Alexandrescu wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
I like the safety that a GC guarantees, but is a too big price to be paid for that...
Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal.
Oct 06 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.10.2014 10:12, schrieb eles:
 On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
 On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:
 On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
I like the safety that a GC guarantees, but is a too big price to be paid for that...
Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal.
This abomination tends to be written by developers that don't care to learn how to use properly their tools. It is quite easy to just use "using" on every IDisposable resource. As for setting something to null just to let the GC know about it, a sign of premature optimization and a sign of not neither knowing how a GC works nor how to use a memory profiler. -- Paulo
Oct 06 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
 I like the safety that a GC guarantees, but is a too big price 
 to
 be paid for that...
What if you only had precise GC on class objects and nothing else? That believe could be done in a performant manner.
Oct 06 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/5/14, 11:23 PM, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 The main distinction between structs and classes in D is the former
 are monomorphic value types and the later are polymorphic reference
 types. -- Andrei
Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called.
It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++.
 There is a delete that triggers that or a smart pointer. I don't care if
 the delete or the destructor really frees the memory, but I would like
 it to get called, to release other resources that the object might have
 locked and to mark the object as "invalid". Later access to it shall
 triger an exception: "invalidObject".

 Call it dispose if you like, because delete is too much like freeing
 memory.

 Is there an intermediate type between structs and classes?
The intermediate type between struct and class is struct. Andrei
Oct 06 2014
parent "eles" <eles eles.com> writes:
On Monday, 6 October 2014 at 13:42:35 UTC, Andrei Alexandrescu 
wrote:
 On 10/5/14, 11:23 PM, eles wrote:
 On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
 wrote:
 On 10/5/14, 3:08 PM, eles wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 It doesn't because they need to be allocated dynamically. 
 That's why there's a need for the likes of unique_ptr and 
 shared_ptr in C++.
Yes, or that delete. And AFAIS not only C++ needs unique_ptr and shared_ptr, this ARC thing is the same in D.
 The intermediate type between struct and class is struct.
D with classes, anyone?
Oct 06 2014
prev sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 TDPL was an absolutely awesome book because it expained "why?" 
 as opposed to "how?". Such insight into language authors 
 rationale is incredibly helpful for long-term contribution. 
 Unfortunately, it didn't cover all parts of the language and 
 many new things has been added since it was out.
I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998
 Right now I have no idea where the development is headed and 
 what to expect from next few releases. I am not speaking about 
 wiki.dlang.org/Agenda but about bigger picture. Unexpected 
 focus on C++ support, thread about killing auto-decoding, 
 recent ref counting proposal - all this stuff comes from 
 language authors but does not feel like a strategic additions. 
 It feels like yet another random contribution, no different 
 from contribution/idea of any other D user.
+1 on all.
 I am disturbed when Andrei comes with proposal that possibly 
 affects whole damn Phobos (memeory management flags) and asks 
 to trust his experience and authority on topic while rejecting 
 patterns that are confirmed to be working well in real 
 production projects. Don't get me wrong, I don't doubt Andrei 
 authority on memory management topic (it is miles ahead of mine 
 at the very least) but I simply don't believe any living person 
 in this world can design such big change from scratch without 
 some extended feedback from real deployed projects.
+1000 --- /Paolo
Oct 06 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 07:44:56 +0000
Paolo Invernizzi via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I would also add that it's scaring not having seen a single=20
 comment of Andrej here:
 https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens.
Oct 06 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via 
Digitalmars-d wrote:
 On Mon, 06 Oct 2014 07:44:56 +0000
 Paolo Invernizzi via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 I would also add that it's scaring not having seen a single 
 comment of Andrej here:
 https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens.
That's a bit unfair of you.
Oct 06 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 12:48:28 +0000
Meta via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via=20
 Digitalmars-d wrote:
 On Mon, 06 Oct 2014 07:44:56 +0000
 Paolo Invernizzi via Digitalmars-d=20
 <digitalmars-d puremagic.com> wrote:

 I would also add that it's scaring not having seen a single=20
 comment of Andrej here:
 https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D=20 users will not run away, they are used to be second-class citizens.
=20 That's a bit unfair of you.
that's what i see. even when people praying for breaking their code to fix some quirks in language, the answer is "NO". why no? 'cause some hermit living in far outlands may wrote some code years ago and that code will break and hermit will be unhappy. unhappiness of active users doesn't matter. and about writing autofixing tool... silence is the answer. "so will you accept that changes if we'll write dfix tool to automatically fixing source code?" silence. "play your little games, we don't care, as we don't plan to change that anyway, regardless of the tool availability". Walter once said that he is against "dfix", and nothing was changed since. "ah, maybe, we aren't interested..." there is little motivation of doing work on "dfix" if it's not endorsed by leading language developers. and now for multiple "alias this"... as you can see this will not help c++ interop, and it will not help gc, so it can lay rotting on github. not a word, not even "will not accept this" or "it's interesting, please keep it up-to-date while you can, we are little busy right now, but will look at it later". second-class citizens will not run away.
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:
 and now for multiple "alias this"... as you can see this will not help
 c++ interop, and it will not help gc, so it can lay rotting on github.
 not a word, not even "will not accept this" or "it's interesting, please
 keep it up-to-date while you can, we are little busy right now, but
 will look at it later". second-class citizens will not run away.
We will accept multiple "alias this". -- Andrei
Oct 06 2014
parent reply "eles" <eles eles.com> writes:
On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:
 We will accept multiple "alias this". -- Andrei
============================================================= IgorStepanov commented 6 days ago Please, someone, add label "Needs Approval" to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks.  yebblies added Enhancement Needs Approval labels 6 days ago ============================================================= Please grand approval there.
Oct 06 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 9:14 AM, eles wrote:
 On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:
 We will accept multiple "alias this". -- Andrei
============================================================= IgorStepanov commented 6 days ago Please, someone, add label "Needs Approval" to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks.  yebblies added Enhancement Needs Approval labels 6 days ago ============================================================= Please grand approval there.
Will do, thanks. -- Andrei
Oct 06 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 TDPL was an absolutely awesome book because it expained "why?" as
 opposed to "how?". Such insight into language authors rationale is
 incredibly helpful for long-term contribution. Unfortunately, it
 didn't cover all parts of the language and many new things has been
 added since it was out.
I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998
I did comment in this group. -- Andrei
Oct 06 2014
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 TDPL was an absolutely awesome book because it expained 
 "why?" as
 opposed to "how?". Such insight into language authors 
 rationale is
 incredibly helpful for long-term contribution. Unfortunately, 
 it
 didn't cover all parts of the language and many new things 
 has been
 added since it was out.
I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998
I did comment in this group. -- Andrei
I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltmmvo forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com --- /Paolo
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
 On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 TDPL was an absolutely awesome book because it expained "why?" as
 opposed to "how?". Such insight into language authors rationale is
 incredibly helpful for long-term contribution. Unfortunately, it
 didn't cover all parts of the language and many new things has been
 added since it was out.
I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998
I did comment in this group. -- Andrei
I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltmmvo forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com
I understand the necessity for further scrutiny of that work. Even before that I owe Sönke Ludwig a review for std.data.json. There's a large list of things I need to do at work, mostly D-related, not all of which I am not at liberty to make public. On top of that I have of course other obligations to tend to. To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). Andrei
Oct 06 2014
parent reply "eles" <eles eles.com> writes:
On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
 On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
 wrote:
 On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

 To interpret my lack of time politically is really amusing. You 
 guys have too much time on your hands :o).
At least give such an explanation from time to time. Silence is the worst.
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 9:16 AM, eles wrote:
 On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
 On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:
 On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

 To interpret my lack of time politically is really amusing. You guys
 have too much time on your hands :o).
At least give such an explanation from time to time. Silence is the worst.
Wait, are we too active in the forums or too silent? -- Andrei
Oct 06 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Oct 06, 2014 at 09:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 10/6/14, 9:16 AM, eles wrote:
On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

To interpret my lack of time politically is really amusing. You guys
have too much time on your hands :o).
At least give such an explanation from time to time. Silence is the worst.
Wait, are we too active in the forums or too silent? -- Andrei
It would be *very* nice if once in a while (say once a week, or once a month) you and/or Walter can do a little write-up about the current status of things. Say a list of top 5 projects currently being worked on, a list of the top 5 current priorities, a short blurb about "progress this past week/month" (which could be as simple as "we've been swamped with fixing regressions, haven't been able to work on anything else", or "Facebook has me on a short leash, I haven't been able to work on D", etc.). This should be in its own thread, titled something like "Weekly [or monthly] status update", not buried underneath mountains of posts in one of our infamous interminable threads about some controversial topic, like to autodecode or not to autodecode. Of course, who am I to tell you what to do... but IMO a periodical high-level status update like the above would go a *long* way in dispelling complaints of "lack of direction" or "unclear/unknown priorities". It doesn't have to be long, either. Even a 1 page (OK, OK, *half* a page), bullet-point post is good enough. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Oct 06 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 9:58 AM, H. S. Teoh via Digitalmars-d wrote:
 It would be*very*  nice if once in a while (say once a week, or once a
 month) you and/or Walter can do a little write-up about the current
 status of things. Say a list of top 5 projects currently being worked
 on, a list of the top 5 current priorities, a short blurb about
 "progress this past week/month" (which could be as simple as "we've been
 swamped with fixing regressions, haven't been able to work on anything
 else", or "Facebook has me on a short leash, I haven't been able to work
 on D", etc.). This should be in its own thread, titled something like
 "Weekly [or monthly] status update", not buried underneath mountains of
 posts in one of our infamous interminable threads about some
 controversial topic, like to autodecode or not to autodecode.

 Of course, who am I to tell you what to do... but IMO a periodical
 high-level status update like the above would go a*long*  way in
 dispelling complaints of "lack of direction" or "unclear/unknown
 priorities". It doesn't have to be long, either. Even a 1 page (OK, OK,
 *half*  a page), bullet-point post is good enough.
That's a really nice idea. -- Andrei
Oct 06 2014
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
wrote:
 On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
 On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
 I did comment in this group. -- Andrei
========================================== IgorStepanov commented 17 days ago Ping =========================================== quickfur commented 14 days ago Wow. I have been waiting for this feature for a long time! Can't wait to see this merged. Ping WalterBright ? ========================================== IgorStepanov commented 13 days ago andralex Ping. Please comment the tests and conflict resolving semantic. =========================================== IgorStepanov commented 8 days ago andralex ping ==========================================
Oct 06 2014
prev sibling next sibling parent reply "Nicolas F." <ddev fratti.ch> writes:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:

 What do you think are the worst parts of D?
The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment. That being said, the second worst part of D for me is the current state of documentation, which is something that is often mentioned. I'd be happy to take part in a "docs initiative" where some of us sit together and talk about how we can improve the documentation of the language, collect input from outside, and then implement the changes that are found to be necessary. This would make it easier for people who don't wish to set up the entire build environment for the documentation on their side to participate in documentation adjustments by giving feedback, while a somewhat dedicated group of people then focus on making decisions reality.
Oct 06 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 6 October 2014 at 15:13:59 UTC, Nicolas F. wrote:
 On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
 wrote:

 What do you think are the worst parts of D?
The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment.
Heh, I think such self-criticism by the community is great, for example, I loved that I recently stumbled across this page on the wiki: http://wiki.dlang.org/Language_issues How many other languages can boast such a page of problems on their own wiki? :) Thanks to Vlad and Mike for writing it. People in this thread are emotional because they care: I don't think it's gone overboard given the real concerns they're stating. When the D community starts hiding its problems and stops critiquing its own efforts, sometimes passionately if that's what you truly feel, is when it starts going downhill.
Oct 06 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 15:22:17 +0000
Joakim via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 People in this thread are emotional because they care
yes. i don't think that anybody (including me ;-) wants to directly insult someone here. D is good, that's why "not-so-good" features are so annoying that we are writing such emotional postings.
Oct 06 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/6/14, 8:35 AM, ketmar via Digitalmars-d wrote:
 On Mon, 06 Oct 2014 15:22:17 +0000
 Joakim via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 People in this thread are emotional because they care
yes. i don't think that anybody (including me ;-) wants to directly insult someone here.
I appeal to you and others to keep language and attitude in check. We all are well intended here, all we need to do is convert heat into work, which should be possible per the first and second principle of thermodynamics. All we need is some cooling :o). Andrei
Oct 06 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 06 Oct 2014 08:39:54 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I appeal to you and others to keep language and attitude in check.
i'm doing my best, rewriting my posts at least three times before sending. i bet noone wants to read the first variants. ;-) but this thread is a good place to show some emotions. i believe that we need such "emotional ranting" threads, so people can scream here and then calm down. sure it's very flammable; we must keep fire extinguishers at hand. ;-)
Oct 06 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Tofu Ninja:

 What do you think are the worst parts of D?
There are several problems in D/Phobos, but I think the biggest one is the development process, that is currently toxic: http://forum.dlang.org/thread/54374DE0.6040405 digitalmars.com In my opinion an Open Source language with such development problem goes nowhere, so I think this needs to be improved. There are several possible ways to improve this situation, but perhaps the may one that can work is: Walter has to delegate another slice of its authority to the community of core dmd developers. This will cause some problems, perhaps an increase in confusion and pull reversions, Walter may lose a bit of his grasp of the dmd codebase (but this can be avoided if he reads the pull requests code), but I think overall the advantages in the long term are going to be bigger than the disadvantages. Regarding the product (and not the process), the design of a principled, sound, and flexible memory ownership system is an important part of D design to work on in the following months. It's going to add some complexity to D, but this is not the kind of complexity that kills a language, because if it's well designed it's going to give easy to read compile-time errors, it's not going to limit too much the variety of things that are currently allowed in D, and it's going to statically remove a significant amount of run-time bugs that are currently easy to do in D. The complexity that causes problems is not the one that requires you to understand a part of a well designed type system: it's the pile of arbitrary special cases and special cases of special cases you see in C++. D considers safety and correctness very important points of its design, and I agree with the importance of such points. Bye, bearophile
Oct 10 2014