On 13-01-06 9:45 PM, Jonathan M Davis wrote:
> On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote:
>> Is this something that the most influential people in the D project want
>> to fix?
>
> What exactly do you want fixed?

Really, I would like to be able to start using D at work. And be in a position to be able to convince people to use it.

> Sure, it would be great if we could know when
> certain things are going to be implemented or fixed, but without people to work
> on them, we can't know when that's going to happen. A lack of time and of
> manpower are frequently the problem here. And if you want a particular problem
> fixed, someone else wants another one fixed. Frequently, both could be
> considered high priority, and the developers only have so much time. Also,
> it's frequently the case that specific people are needed to fix specific issues -
> especially if we don't have new people stepping up to the plate and learning
> how to do stuff - creating an even greater bottleneck.
>
> Maybe we could get some sort of consensus on what the biggest issues are and
> try and get people to focus on those, but frequently, what we really need is
> for someone to step up and spend the time necessary to fix the issue. When that
> happens, stuff gets done. When it doesn't, it doesn't really matter what the
> biggest issues are, because there's a lack of manpower to fix them. And
> frequently, each major issue requires a different set of expertise, making it
> hard to for someone or even a small group of someones to work on all of the
> major issues. And we only have a small group of someones.
>
> So, if you have any suggestions on how to improve the process or otherwise
> help us get stuff done, great. If you think that there's something that we can
> do to better encourage participation, we're all ears. For instance, the
> release process is currently being adjusted precisely because people thought
> that it was a major issue and have spent the time to work out what should be
> done about it. But to a great extent, I don't think we necessarily know what
> needs to be changed or how it should be changed. Good ideas are required, and
> we're tight enough on time and manpower as it is just trying to get done
> everything that we know needs to get done.
>
> Almost always, the key is for someone who's passionate about something to get
> involved and make sure that it gets done.
>

And I understand and agree on all of the above points.  I am trying to see what I could do.  Yes, I can start going through the list of tickets, try to compile some info, and eventually even become one more developer.  At the moment I was trying to learn more on the development process to get ideas on how (or whether it is possible) to improve the predictability aspect I would need to convince people at work on the usefulness of D.


For the moment, I will continue to read the lists, the Bugzilla tickets (and propose better titles via comments if I see opportunities to do so), learn how you use DDoc for the documentation, find out what is supported by the community and its leader (which I assume is Walter) and hopefully I can help a little somehow.



> - Jonathan M Davis
>


-- 
/Pierre Rouleau

On 13-01-06 9:35 PM, Jonathan M Davis wrote:
> On Sunday, January 06, 2013 21:15:43 Pierre Rouleau wrote:
>> So, given that enhancements are identified in Bugzilla, is there a
>> review process?  Are ticket priorities and vote used?  Who decides what
>> is the priority of an enhancement?   Who assigns them?
>
> There's pretty much never any assigning of issues in D's developement.
> Developers work on whatever they feel like working on. An enhancement request
> gets implemented, because someone decided to put the time in to implement it.
> If it's controversial, then it'll generally get discussed in the newsgroup,
> though some of that is likely to take place in the bug report itself or in a
> pull request if the developer implements it without discussing it first. Large
> language changes always get major discussions, but we also don't get a lot of
> those at this point. It's mostly little stuff.
>
>> Also, given that view on the development of D, what is the position on
>> the evolution of the language in context with backward compatibility and
>> stability?
>
> We're trying to reach the point where you can count on your code compiling for
> years without changing it. We're getting there, but it doens't always happen.
> Even fixing bugs breaks code when code relies on buggy behavior. There's also
> still some API changes in Phobos which breaks stuff, but we've been cutting
> back on those and trying to avoid them, so they happen much less now then they
> used to. The recent change to make deprecated warn instead of giving an error
> should help with that.
>
>> How can an organization of D users that are not also D
>> developers can plan a project and use D for it?
>>
>> Do you consider D stable enough for outside users/organizations to start
>> using it in their own projects?
>
> It's stable enough as long as you're continually working on your code. If you
> let it sit for a long period of time, you're likely to need the same compiler
> and library version that you used when you last worked on it. Breakages are
> _far_ fewer than they used to be, but they still happen. I'd expect that
> anyone using D seriously for professional development would stick to one
> version of the compiler for a while and then upgrade it when they have time to
> update their code (which they may not need to do, but it's still not quite to
> the point that there isn't at least a decent chance that a few lines of code
> will have to be changed).
>
> API breakage does occur sometimes, but we're making an effort to keep that to a
> minumum, and we'd like to get rid of it completely. But regardless, I believe
> that most breakages at this point are due to bug fixes, so when we'll reach the
> point that you can really expect your code to continue to compile for years on
> newer compilers without trouble, I don't know. That may depend primarily on
> the bugs that we have left and how well regressions get caught. The work
> that's currently being done on formalizing and ironing out the release process
> should help with that though.
>
> - Jonathan M Davis
>
Thank you for the info!

-- 
/Pierre Rouleau

On 13-01-06 9:41 PM, Walter Bright wrote:
> On 1/6/2013 6:15 PM, Pierre Rouleau wrote:
>> So, given that enhancements are identified in Bugzilla, is there a review
>> process?  Are ticket priorities and vote used?  Who decides what is
>> the priority
>> of an enhancement?   Who assigns them?
>
> Pretty much anyone who wants to take one of them on does so and when
> done, issues a pull request for it. At that point, there's a general
> discussion of it and a decision is reached, usually by consensus.
>
>
>> Also, given that view on the development of D, what is the position on
>> the
>> evolution of the language in context with backward compatibility and
>> stability?   How can an organization of D users that are not also D
>> developers
>> can plan a project and use D for it?
>>
>> Do you consider D stable enough for outside users/organizations to
>> start using
>> it in their own projects?
>
> Yes, and it is used heavily for commercial purposes by at least a couple
> companies.
>
> Like any other language, if you insist on using the latest feature and
> pushing it to the limit, you are more likely to run into problems than
> if you are a bit more modest in your use of it.
>
Understood, that's pretty much always the case for any programming language.  Now, for someone from the outside, how would someone know what are the latest features?

Would it be possible to identify the version number where a particular feature has been introduced in the Language Reference?  If not, since this is DDoc based, is it possible for someone to go back in the github repo file history to identify what was added in the Language Reference files between release to releases and document this somehow?

> That said, we make a large effort to fix all regressions upon each
> release, and I push hard to avoid making breaking changes to the
> language unless it is really unavoidable.
>

And I can imagine it's a lot of work...


-- 
/Pierre Rouleau

On 1/6/2013 7:30 PM, Pierre Rouleau wrote:
> Understood, that's pretty much always the case for any programming language.
> Now, for someone from the outside, how would someone know what are the latest
> features?

In the changelog, click on New/Changed Features.

> Would it be possible to identify the version number where a particular feature
> has been introduced in the Language Reference?  If not, since this is DDoc
> based, is it possible for someone to go back in the github repo file history to
> identify what was added in the Language Reference files between release to
> releases and document this somehow?

If you can't find it in the changelog under New/Changed Features, you can look in github for it which has a complete history.

On 2013-01-07 00:19, Walter Bright wrote:

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

I know you have. The problem is that there might be necessary to do some changes to the compiler. That doesn't mean there is a bug.

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

Yeah, I know. I'm not complaining.

> The OS X TLS implementation is all done in druntime.

Not 100%. I'm thinking of the __tls_get_addr function which the compiler calls:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549

That function needs to know which image the given address belongs to. I think that the compiler needs to supply that, in addition to the address, but I'm not sure. If it does it requires a change in the compiler.

I can add this to bugzilla.

> Nevertheless, this does not impact Linux nor FreeBSD.

Mac OS X is my main platform. It's natural that I try to get it to work there first.

-- 
/Jacob Carlborg

On Sun, 6 Jan 2013 11:42:53 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> Like browsers, for instance. When Microsoft had their browser merely uninstallable...

Erm... s/uninstallable/non-uninstallable/ (unless I'm remembering
wrong)

On 2013-01-07 01:25, Walter Bright wrote:

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

Martin Nowak has already started on this, it seems he know what he's doing:

https://github.com/dawgfoto/druntime/tree/SharedRuntime

-- 
/Jacob Carlborg

On 2013-01-07 00:14, Walter Bright wrote:

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

I didn't know you had stopped working on the runtime.

-- 
/Jacob Carlborg

On 1/6/2013 11:51 PM, Jacob Carlborg wrote:
> On 2013-01-07 00:19, Walter Bright wrote:
>
>> 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.
>
> I know you have. The problem is that there might be necessary to do some changes
> to the compiler. That doesn't mean there is a bug.

I'm sorry, but I can't do anything with that statement.


>> The OS X TLS implementation is all done in druntime.
>
> Not 100%. I'm thinking of the __tls_get_addr function which the compiler calls:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549

Yes, it defers it all to druntime by calling a druntime function.


> That function needs to know which image the given address belongs to. I think
> that the compiler needs to supply that, in addition to the address, but I'm not
> sure. If it does it requires a change in the compiler.
>
> I can add this to bugzilla.

Please nail down what is necessary first. (BTW, I don't know how the compiler can tell what image an address comes from. Remember, shared libraries are loaded at runtime, not compile time.)


>> Nevertheless, this does not impact Linux nor FreeBSD.
>
> Mac OS X is my main platform. It's natural that I try to get it to work there
> first.

No prob. I'll be happy to make compiler mods as necessary, once the exact problems are identified.

On 1/6/2013 11:57 PM, Jacob Carlborg wrote:
> On 2013-01-07 01:25, Walter Bright wrote:
>
>> Sean would be the main one, but really anyone who is willing to get down
>> and dirty with threads and such can do it.
>
> Martin Nowak has already started on this, it seems he know what he's doing:
>
> https://github.com/dawgfoto/druntime/tree/SharedRuntime
>

That's good to hear.