On 1/6/2013 3:56 AM, Jacob Carlborg wrote:
> I completely agree. We _need_ dynamic libraries. But the problem is that someone
> just have to do it and Walter doesn't seem to be in a rush to implement it.

It's actually completely implemented in the compiler. I've spend considerable effort making -fPIC work, which is surprisingly complicated.

Where it is not implemented is in druntime. The folks who work on druntime are the ones that need convincing.

On 1/6/2013 4:20 AM, Russel Winder wrote:
> For the Go folks, it is all about issues with garbage collection and
> thread management,

It is for D as well (along with TLS). Unfortunately, the druntime implementation of these is complex, and I do not understand it.

On 1/6/2013 4:32 AM, Jacob Carlborg wrote:
> I have tried myself a couple of times but there has always been some issue with
> the compiler that needs to be fixed or implemented.

I have fixed every single PIC implementation compiler problem that has been brought to my attention. If there are others, I am not aware of them. Please let me know the bugzilla issue numbers for any I have missed.

> For example, on Mac OS X where DMD implements its own
> TLS the compiler will most likely need to change somewhat.

DMD implements its own TLS on OS X because the OS X C compiler says "not implemented" when you try to create TLS variables. I had no other option.

The OS X TLS implementation is all done in druntime.

Nevertheless, this does not impact Linux nor FreeBSD.

On 1/6/2013 7:20 AM, Pierre Rouleau wrote:
> Is there a file somewhere that lists all requested features, under development
> features?  Or the various mailing lists the only source of information?


http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

On Sunday, January 06, 2013 15:15:23 Walter Bright wrote:
> On 1/6/2013 4:20 AM, Russel Winder wrote:
> > For the Go folks, it is all about issues with garbage collection and thread management,
> 
> It is for D as well (along with TLS). Unfortunately, the druntime implementation of these is complex, and I do not understand it.

Does this mean that we need Sean Kelly to do it? If so, we're in trouble, because he seems to be _very_ busy these days and is generally uninvolved. I don't know if anyone else knows the code well enough to attempt it. Hopefully, someone does or is willing to learn and has the time to do so.

- Jonathan M Davis

On 13-01-06 6:21 PM, Walter Bright wrote:
> On 1/6/2013 7:20 AM, Pierre Rouleau wrote:
>> Is there a file somewhere that lists all requested features, under
>> development
>> features?  Or the various mailing lists the only source of information?
>
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>
Thanks Walter.

If this list already contains all (does it?) of what is currently identified then is there some criteria one can use to try to infer what will be implemented in the next release? Or is it just "first come first served" where the solved enhancements automatically get pulled inside the release?

Is this process documented somewhere?

-- 
/Pierre Rouleau

On Sunday, January 06, 2013 18:49:18 Pierre Rouleau wrote:
> On 13-01-06 6:21 PM, Walter Bright wrote:
> > On 1/6/2013 7:20 AM, Pierre Rouleau wrote:
> >> Is there a file somewhere that lists all requested features, under
> >> development
> >> features?  Or the various mailing lists the only source of information?
> > 
> > http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severi ty=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
> Thanks Walter.
> 
> If this list already contains all (does it?) of what is currently identified then is there some criteria one can use to try to infer what will be implemented in the next release? Or is it just "first come first served" where the solved enhancements automatically get pulled inside the release?
> 
> Is this process documented somewhere?

It's generally whatever people happen to implement. Walter may or may not have his own personal plan as to what he works on, but there is no overall plan whatsoever for what's going to be implemented for the next release (or any release). It's entirely a matter of what the various volunteers happen to create pull requests for and manage to get merged in. They may or may not even do anything related to existing enhancement requests. If you're looking for anything even vaguely resembling a roadmap, you're out of luck. At best, you can get a list of some of the stuff that people would _like_ to have done (like the list of currently open enhancement requests). And that may or may not have all that strong a relation with what _will_ be done at any point in the future (either because no one gets around to them or because they end up being rejected).

We should probably have a list of of major issues that still need to be tackled, but we don't really have even that (other than seeing what's in bugzilla). The closest would be this page on the old wiki, but it's not exactly definitive or necessarily up-to-date:

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

- Jonathan M Davis

On 1/6/2013 3:47 PM, Jonathan M Davis wrote:
> Does this mean that we need Sean Kelly to do it? If so, we're in trouble,
> because he seems to be _very_ busy these days and is generally uninvolved. I
> don't know if anyone else knows the code well enough to attempt it. Hopefully,
> someone does or is willing to learn and has the time to do so.

Sean would be the main one, but really anyone who is willing to get down and dirty with threads and such can do it.

On 1/6/2013 3:49 PM, Pierre Rouleau wrote:
> If this list already contains all (does it?) of what is currently identified
> then is there some criteria one can use to try to infer what will be implemented
> in the next release? Or is it just "first come first served" where the solved
> enhancements automatically get pulled inside the release?

The thing is, roadmaps are a lot like planning for a war. The moment the first shot is fired, all the plans go out the window. What we need to get done next is a constantly evolving situation, based on:

1. some crisis may occur

2. some opportunity may present itself

3. the language market may change its perception of what is important

4. a member of the community may promote themselves to be a champion of some particular issue, and work to get it implemented

5. our understanding of what is important and what isn't constantly evolves

6. there's constant evolution of what exactly is best practice and the best way to realize that

Probably pretty high on the list would be solving the rvalue reference problem.

Pierre Rouleau, el  6 de January a las 12:56 me escribiste:
> >Yeah, that's another issue too. Having mutating "release notes" is awful and a PR disaster. Users only see the changelog once, assuming is immutable, because one thinks that releases are immutable and complete (those are very fundamental properties of a release, otherwise is a preview or a snapshot).
> >
> >That's another thing that I think is important to address eventually.
> 
> Currently, from the outside, I get the impression that the D language is a great language but a language for its developers only.

I think to develop in D, you eventually have to be involved at some point with the development of D itself.

This is something that's slowly changing, but very very slowly.

> Although it might be OK while the language is in its infancy, I would hope that D(2) would come out of that state now that several books exist, that the standard library seems in pretty good shape, that several other libraries, frameworks and tools exist.   To me, what seems missing is some wrapper around all of this that would make D(2) much more attractive for organizations like the one I work for. I am personally very interested in D(2) and have already done discussions inside my work place, but without that sort of visible infrastructure I doubt I would be able to convince anyone to adopt D(2) for any product-based development (and even for some internal tools).

I agree completely, I think this is just a management problem, and until the management realizes how important this is (having a plan, a proper release process, minor version releases, etc.), only "Kamikaze" companies will be able to adopt D.

> So, again, this is why I was asking whether you guys thought it would be a good idea for me to start a discussion somewhere in one of the D mailing lists, to gather the list of new features planned for the future (unless something like that already exists, but I did not find it) and get something going to create a running list.

There is this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap

But AFAIK is not official at all, Walter never really looked at it, is just investigation work done by the community and some guys with a lot of patience to have to encourage some planning.

AFAIK there is nothing like a clear milestone about where D is supposed to go in the next release, something a lot of D developers (as in compiler developers) have been asking for for a long time.

The latests clear example on how D is still SDD (Surprise Driven Development) is how UDA where included in the last release.

I really hope at some point this will be addressed, and I think other areas of the development process have been improved enough to think this is a good moment to do so, but first management (OK, I will say it: Walter) have to be convinced (or pushed) to do so. Maybe it will take 2 or 3 years.

Just as a history reminder, I wrote a rant a little more than 3 years ago about things in the development process that needed to be addressed. Now a lot of these issues have been addressed (or at least partially): http://www.llucax.com.ar/blog/blog/post/6cac01e1

So I think there is definitely room for hope, but don't expect this to happen soon.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Es más probable que el tomate sea perita, a que la pera tomatito.
	-- Peperino Pómoro