On 12/11/11 1:05 PM, Jesse Phillips wrote:
> I wish to add a little of why Mehrdad's complaints are very important. I
> think the delay is a good, over releasing 2.058 two days later.
>
> Most in the community have chosen what they will use of D, they know of
> some issues (no multiple alias this), or don't know how best to use
> something (concurrency).
>
> In our marketing for the language we express how great such-and-such is,
> but know that problems will be found by those that use it. We could not
> mention concurrency and how immutable/const plays its rule, but we need
> to answer what is different from D1 and how the future of computing will
> be easier in D.
Agreed.
> Interestingly Mehrdad has chosen something which does basically nothing,
> the const system. Const isn't important at _all_, except that it is a
> pillar for our functional concurrent purity. We claim a language that
> makes an immutable and mutable world coexist. Yet the implementation
> doesn't back that up.
>
> So why should we probably finish fixing up const, over say the multiple
> alias this, @safe, or no GC use? Because it is what will be touched by
> new users the most. You tell people how great mixing immutable and
> mutable is, they're going to give it a try. You pull users over from C++
> or other languages with non-transitive const, they are going to use
> const as they do in that language without reading about how D does it.
> These people aren't going to be using const correctly in D, they
> couldn't possibly know how to. When they complain, we explain what is
> wrong and how they should be using it, but when they do start using it
> correctly (because they won't listen to our "don't use const yet"
> message) they will still fail to get it right because implementation
> doesn't support it.
>
> We need to be able to prove transitive const is easy to work with and
> worth it. Transitive const is hard to see how it works, but no GC and
> explaining multiple alias this is simple to understand. And @safe D is
> not what brings people to D.
Actually my experience is that new users try very early advanced
examples all over the map. Some indeed try const. Some others try
interfaces with contract. Some others try concurrency. Some others try
dimensional analysis. And so on - these examples are drawn only from
vague recent memories.
It took me a while to figure the psychology. I think what happens is
that someone trying a new language tends to explore "deltas". Nobody is
interested in stuff that works the same or similarly in D vs. other
languages. Nobody's like, "hello world works - I'm sold!" Most often
someone would see an interesting sample and go like, "Hmm, intriguing. I
wonder how my idea of tweaking /that/ might work."
In brief, similar to my long experience with C++ "if it compiles,
somebody will have tried it", my experience with being a sort of a PR
representative for D suggests that "if it makes sense, a n00b will try
it and expect it to work". Catering to such a demand is quite difficult
because you need to cover all cases properly, and fail meaningfully
(i.e. early and with a good diagnostic) if the demand is unreasonable.
(In the category of failing with a good diagnostic - the issue of
restricted templates comes to mind. If a call doesn't satisfy any
restricted template, the compiler should specify which part of the
complex Boolean expression failed, a la:
test.d(24): Error: reduce(x) failed to match any function
test.d(24): Remark: Candidate std.result failed because
isInputRange!(typeof(x)) is false
test.d(24): Remark: isInputRange!(typeof(x)) is false because x.front
does not exist
)
> There was a concentration on TDPL bugs before the book came out, lets
> bring that back and get them done for 2.058:
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr
>
>
> What do you say team?
We have indeed identified TDPL alignment an important strategic
objective. There are more (and more important) bugs than those you
linked, but I haven't found the time yet to make a pass through them.
Andrei

Le 11/12/2011 19:50, Alvaro a écrit :
> But I think it would be too complicated to turn all D's arrays, objects,
> etc. into a system like this.
Nor would it be a good idea imho. I would limit the (templated) ref
counting in the std lib to "basic" objects such as numbers (BigInt,
complex, etc), date/time objects dchars and strings and that's it.

On 12/11/2011 05:50 PM, Bane wrote:
> so Wrote:
>
>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto<pjmlp@progtools.org>
>> wrote:
>>
>>> Really?
>>>
>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>
>>> Do you know that many games in iPhone are done in Unity, which
>>> makes use of C#/Boo/Javascript compiled to native code?
>>
>> I don't understand sorry, are you arguing against the argument i made on
>> GCs failure on some specific areas?
>
> Come on kidz, GC does good on some tasks that are not performance critical, it fails on other tasks that are. That is why D has assembler option - for parts you need to be done ultra fast. Same should apply for optional GC. And everyone gets candy :)
GC does not impair performance if done right. The problem is responsiveness.

On 12/11/2011 06:49 PM, Paulo Pinto wrote:
> Am 11.12.2011 17:40, schrieb so:
>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
>> wrote:
>>
>>> Really?
>>>
>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>
>>> Do you know that many games in iPhone are done in Unity, which
>>> makes use of C#/Boo/Javascript compiled to native code?
>>
>> I don't understand sorry, are you arguing against the argument i made on
>> GCs failure on some specific areas?
>
> Yes I am, since I know many areas where GC enabled languages have been
> replacing non-GC languages for better or worse.
>
> But then again, I am only a lurker here, so take my arguments with a
> grain of salt.
>
> As a non user of D, I cannot really say much.
GC does not scale if an application has to be responsive. In all other
cases it is a valid choice.

On 12/11/2011 05:35 PM, Paulo Pinto wrote:
> Am 11.12.2011 17:12, schrieb Bane:
>> Paulo Pinto Wrote:
>> But in systems world there will always be significant number of people
>> with doubt in any GC implementation, or just with a desire to do their
>> own memory management. I think that group of people is important and
>> we should do what we can to attract them to D.
>>
>
> Those people will eventually become irrelevant.
>
> As I mentioned in a previous email, if I want to use a language without
> GC for systems programming I already have C, C++, Delphi, you name it.
> Why pick D then?
>
Because GC is by far not the only thing that matters.

On 12/11/2011 10:12 PM, Timon Gehr wrote:
> On 12/11/2011 06:49 PM, Paulo Pinto wrote:
>> Am 11.12.2011 17:40, schrieb so:
>>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
>>> wrote:
>>>
>>>> Really?
>>>>
>>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>>
>>>> Do you know that many games in iPhone are done in Unity, which
>>>> makes use of C#/Boo/Javascript compiled to native code?
>>>
>>> I don't understand sorry, are you arguing against the argument i made on
>>> GCs failure on some specific areas?
>>
>> Yes I am, since I know many areas where GC enabled languages have been
>> replacing non-GC languages for better or worse.
>>
>> But then again, I am only a lurker here, so take my arguments with a
>> grain of salt.
>>
>> As a non user of D, I cannot really say much.
>
> GC does not scale if an application has to be responsive. In all other
> cases it is a valid choice.
(if you have enough spare memory)

On 11 December 2011 20:34, Paulo Pinto <pjmlp@progtools.org> wrote:
> Am 11.12.2011 19:18, schrieb Manu:
>
>> On 11 December 2011 15:15, maarten van damme <maartenvd1994@gmail.com
>> <mailto:maartenvd1994@gmail.**com <maartenvd1994@gmail.com>>> wrote:
>>
>>
>> 2011/12/11 Paulo Pinto <pjmlp@progtools.org
>> <mailto:pjmlp@progtools.org>>
>>
>>
>> Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
>>
>> On 12/10/11 2:22 PM, maarten van damme wrote:
>>
>> Just for fun I
>> wanted to create a program as little as possible,
>> compiled without
>> garbage collector/phobos/... and it turned out that
>> compiling without
>> garbage collector is pretty much impossible (memory
>> leaks all around the
>> place in druntime). dynamic linking for the d standard
>> library would be
>> a great new option for a dmd release in the future :).
>>
>>
>> Using D without GC is an interesting direction, and dynamic
>> linking
>> should be available relatively soon.
>>
>>
>> Andrei
>>
>>
>> As a long time beliver in systems programming languages with GC
>> support
>> (Modula-3, Oberon, Sing#, ...), I think allowing this in D is
>> the wrong direction.
>>
>> Sure provinding APIs to control GC behavior makes sense, but not
>> turn it
>> off, we already have enough languages to do systems programming
>> without GC.
>>
>>
>> I was only trying it "for the fun of it", not to be used seriously.
>> D should always have it's GC support built-in and have some
>> functions to control it's behaviour (core.memory). But I think that
>> D, beeing a systems programming language, should also be able to be
>> used without GC. I don't mean phobos to be writtin without a GC in
>> mind but druntime should be compilable with something like a -nogc
>> flag that make it usable without GC.
>>
>> There are a lot of users out there who think that a GC produces
>> terribly slow programs, big hangs while collecting,... (thank java
>> for that. Right now the java GC has been improved and it's extremely
>> good but the memory stays :p)
>> Letting them know that D can be run without GC can be a good point.
>> If they don't like it, they can turn it off.
>>
>>
>> That's got nothing to do with it. People who seriously NEED to be able
>> to use the language without the GC enabled are probably working on small
>> embedded systems with extremely limited resources. It's also possible
>> that various different resource types need to be allocated/located in
>> different places.
>> Also, In many cases, you need to able to have confidence in strict
>> deterministic allocation patterns. You can't do that with a GC enabled.
>> I'm all about having a GC in D, obviously, but I certainly couldn't
>> consider the language for universal adoption in many of my projects
>> without the option to control/disable it at times.
>> If I can't write some small programs with the GC completely disabled,
>> then I basically can't work on microprocessors. It's fair to give up the
>> standard library when working in this environment, but druntine, the
>> fundamental library, probably still needs to work. Infact, I'd
>> personally like it if it was designed in such a way that it never used
>> the GC under any circumstances. No library FORCED on me should restrict
>> my usage of the language in such a way.
>>
>
> In my experience programming embedded systems in highly constrained
> environments usually means assembly or at most a C compiler using lots
> of compiler specific extensions for the target environment.
>
> I fail to see how D without GC could be a better tool in such enviroments.
>
The best current example I can think of is PS3, there are 2 separate
architectures in use in that machine, PPC, and SPU, the PPC has 2 separate
heaps, and each SPU has its own 256k micro-heap.
The PPC side would probably use GC in the main heap, and manually manage
resources in the secondary video heap. Each SPU however is a self contained
processor with 256k of memory.
Not only is there no room to waste, but the PROGRAM needs to fit in there
too. Interaction between the main program and the SPU micro-programs is FAR
more painless if they share the same language. With the source code being
shared, it's very easy to copy memory between the processors which directly
share the structure definitions.
Obviously, any code running on the SPU may not use the GC... Period. The
program code its self must also be as small as possible, no space to
wastefully link pointless libraries.
It's hard to say a PS3 isn't a fair target platform for a language like D.
It's not going away either.
This is just one example, almost every games console works like this:
* PS2 had 4 coprocessors, each with their own micro-memory, one of which
would certainly share source code with the main app (even back then, this
approach was the norm).
* PSP only has 32mb of ram, explicit management is mandatory on systems
with such small memory.
* Wii has an ARM coprocessor with a tiny memory bank, it also has
bugger-all main memory (24mb), so you probably want to explicitly manage
memory a lot more.
* Nintendo DS has a secondary small coprocessor.
* Larrabee architecture, CELL architecture, or anything like these it will
require running code with explicit management of micro-heaps.
Signal processing, DSP's, etc, usually coprocessors, these aren't tiny
slave chips with microprograms written in assembly anymore, they are
powerful sophisticated coprocessors, with full floating point (usually SIMD
arithmetic, PLEASE PLEASE ADD A 128bit SIMD TYPE) support, would benefit
from D and its libraries, but still have bugger all memory and require
strict control over it.
It's nice to write the master program and the coprocessor programs in the
same language. At very least for the ability to directly share data structs.
I hope I have made an indisputable a case for this. It's come up here a lot
of times, and it's pretty annoying when everyone suggests the reasons for
wanting it are nothing more that maximising performance. I'd suggest that
in 95% of cases, performance has *nothing* to do with it.

On Sun, 11 Dec 2011 14:08:15 -0600, Andrei Alexandrescu wrote:
> Actually my experience is that new users try very early advanced
> examples all over the map. Some indeed try const. Some others try
> interfaces with contract. Some others try concurrency. Some others try
> dimensional analysis. And so on - these examples are drawn only from
> vague recent memories.
I guess what gets me on const is that everyone thinks they know how to
use it. It is one item where it isn't used because we say, "hey D has
transitive const it is great!" The user is interested in just using D and
if from C++ are in the habit of putting const everywhere.
So in essence it is one of the "not being interested as 'I've seen it
before.'" And then the ultimate response we have to give is, "No, no, D
is different, it is broken."
Concurrency, well there isn't a preconception on how D does it. And
immutable is part of it, and const is part of that.
Interface contracts was definitely good.
>> There was a concentration on TDPL bugs before the book came out, lets
>> bring that back and get them done for 2.058:
>> http://d.puremagic.com/issues/buglist.cgi?
query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr>>
>>
>> What do you say team?
>
> We have indeed identified TDPL alignment an important strategic
> objective. There are more (and more important) bugs than those you
> linked, but I haven't found the time yet to make a pass through them.
I just search on bugs with tdpl in the subject (important convention). I
don't want fixing other bugs to stop, but to have another concentrated
effort on one thing, for the next week/two might be a good choice.

On Sunday, December 11, 2011 16:10:47 Dejan Lekic wrote:
> > I confess that I don't see the point in delaying the current
> > release for this. It's nearly ready. It seems to me that it
>
> Compiler and runtime-library projects should never release
> "nearly ready" versions. Some higher level library projects may
> have that luxury, but compiler/run-time library, never! It should
> be released when it IS ready. Not earlier.
>
> Problem with D and Phobos is that there is no clear roadmap (or
> at least I am not aware of its existence). So please tell me how
> you guys know if dmd+phobos is ready to be released or not when
> there was no plan on what this release is all about (apart from
> the list of issues on bugzilla)???
1. It's "nearly" ready, not ready, so it hasn't been put out the door yet.
2. What does ready mean anyway? In this case, it means that enough time has
passed since the last release that it makes sense to make another release and
no major regressions have been introduced (and preferably no regressions at
all).
If you're looking for the compiler's released to be delayed until it works
perfectly, it'll never be released. Not only does every compiler on the planet
have bugs in it, but in order to find most bugs, people need to use the
compiler in all of the diverse situations that compilers get used in.
dmd has been steadily improving - and at a very high rate as well. Delaying
this release for a few days to try and fix a few specific bugs doesn't really
hurt, since there's no hard release schedule, but it's also a bit odd, since
we've already gone through the necessary beta testing and were about to put it
out the door. But for better or worse, Andrei and Walter decided to delay the
release to deal with some of the bugs which Mehrdad was complaining about
rather than just fixing them for 2.058. Delaying the release means that more
buigs will be fixed in the next release, but it also means that those using the
official releases (as opposed to the latest on github) have to wait that much
longer for all of the fixes that have already been implemented for the next
release. So, it's not clear which is better.
As for a roadmap, what would you want on it? For the most part, D isn't
getting new features at this point. A few features aren't fully implemented
yet, but aside from that it's all bug fixing. And those tend to get fixed when
they get fixed. Having a roadmap for that sort of thing is difficult. At best,
Walter could indicate what was being focused on. And with so many of the fixes
now coming from the community, it becomes that much more difficult to have any
kind of roadmap about what's going to be fixed next.
The one thing that I can think of which probably should be done would be to
have a clearer plan about when releases are targeted for rather than Walter
just deciding at some point that enough time has passed since the previous
release to have another one (generally 1 - 2 months). But I don't know what he
could really be putting on a roadmap, since it's all bug fixing now and not new
feature development.
- Jonathan M Davis

On Sunday, December 11, 2011 21:50:02 Jesse Phillips wrote:
> On Sun, 11 Dec 2011 14:08:15 -0600, Andrei Alexandrescu wrote:
> > Actually my experience is that new users try very early advanced
> > examples all over the map. Some indeed try const. Some others try
> > interfaces with contract. Some others try concurrency. Some others try
> > dimensional analysis. And so on - these examples are drawn only from
> > vague recent memories.
>
> I guess what gets me on const is that everyone thinks they know how to
> use it. It is one item where it isn't used because we say, "hey D has
> transitive const it is great!" The user is interested in just using D and
> if from C++ are in the habit of putting const everywhere.
>
> So in essence it is one of the "not being interested as 'I've seen it
> before.'" And then the ultimate response we have to give is, "No, no, D
> is different, it is broken."
>
> Concurrency, well there isn't a preconception on how D does it. And
> immutable is part of it, and const is part of that.
>
> Interface contracts was definitely good.
>
> >> There was a concentration on TDPL bugs before the book came out, lets
> >> bring that back and get them done for 2.058:
> >> http://d.puremagic.com/issues/buglist.cgi?
>
> query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug
> _status=REOPENED&short_desc_type=allwordssubstr
> >> What do you say team?
> >
> > We have indeed identified TDPL alignment an important strategic
> > objective. There are more (and more important) bugs than those you
> > linked, but I haven't found the time yet to make a pass through them.
>
> I just search on bugs with tdpl in the subject (important convention). I
> don't want fixing other bugs to stop, but to have another concentrated
> effort on one thing, for the next week/two might be a good choice.
And if we're going to really try and get the const issues sorted out, Walter
really should look at Michel Fortin's changes which replace Rebindable.
And we definitely need to sort out what we want to be doing with const-
correctness and object. Kenji did some pull requests related to that, but
there were some issues, and I'm not quite sure where that all stands at the
moment. It _is_ a major element in fixing const though.
- Jonathan M Davis