May 09, 2012
On Wednesday, 9 May 2012 at 06:12:33 UTC, Paulo Pinto wrote:
> Hi,
>
> Dr. Dobbs has a nice editorial article about the rise of  new native languages and it mentions
> D.
>
> http://www.drdobbs.com/architecture-and-design/232901652?cid=DDJ_nl_upd_2012-05-08_h&elq=60a2e0ea244a4667b97377cecc50110f
>
> Unfortunely the editor also points out that D is not fully open source, without specifiying what
> exactly is not open source.
>
> I've already posted a comment about it, stating that there are open source implementations and the
> complete code is available in Github.
>
> Still not visible, maybe waiting approval.
>
> --
> Paulo

When I looked back at D around 2009-2010, the fact that the reference compiler wasn't fully open-sourced and the alternative weren't quite there yet and/or available on all platforms really turned me off on the langage, the other thing was the Tango/Phobos split.

Now, I'm glad the situation improved and that we've got DMD 32 and 64 bit on all platforms (except Windows), GDC is much more mature and the development is more open (Github ftw). But the fact that the reference compiler isn't fully open source still irks me. What if I want to submit a change or a fix to the langage that require to change the backend too ?

IMHO, DMD and LDC should merge but that's just me ;)


May 09, 2012
On Wednesday, 9 May 2012 at 19:58:14 UTC, Michaël Larouche wrote:
>  What if I want to submit a change or a fix to the langage that require to change the backend too ?

There's nothing stopping that right now!

The only thing the backend license really prohibits is
distributing it yourself.

Doing a personal fork, modifying it, and doing a pull
request or a patch back upstream happens in practice
somewhat normally.
May 09, 2012
On Wed, 9 May 2012, =?UTF-8?B?Ik1pY2hhw6ts?=.Larouche@MISSING_DOMAIN wrote:

> What if I want to submit a change or a fix to the
> langage that require to change the backend too ?

You do exactly what'd you do with any other github project.. fork, change, send pull request.

The backend of dmd receives changes on a not infrequent basis.  The license does not get in the way at all.

Later,
Brad
May 09, 2012
On 2012-05-09 21:43, deadalnix wrote:

>> How so?
>>
>
> We have a botleneck in accepting contributions.

* There's no road map
* No release schedule
* No overall goal

-- 
/Jacob Carlborg
May 09, 2012
On 09/05/12 19:24, David Nadlinger wrote:
> This would be great, but at least for LDC, the biggest problem at the moment in
> that regard is manpower –currently, most of us primarily work on it whenever it
> doesn't compile our own projects (and when specific bug reports come in,
> obviously). This works reasonably well, e.g. Alexey merged the 2.059 frontend
> more than 2 1/2 weeks ago, which is not terribly late (where is GDC right now,
> btw?), but could quite clearly be improved. At least personally, though, I'd
> currently find it hard to commit to releasing simultaneously with DMD, because
> it might entail doing larger amounts of merging/testing work on short notice as
> long as there isn't at least some kind of semi-formal release schedule for DMD.

I shall have to have a go at building LDC from source, I've been wanting to try out ldc2 for ages.

TBH I was not thinking so much of the LDC team having to do extra work, as the core DMD team doing more to ensure that the frontend updates work across all the different backends.  Tricky in the short term given the volume of work that still has to be done, possibly manageable in the longer term as the frontend stabilizes and the number of contributors increases.

The reason for proposing this is that currently if I wish to hack on Druntime or Phobos, I _have_ to use DMD.  True parity of the open-source compilers would be contributors being able to use their compiler of choice.  That should put all the "not OS" complaints to bed properly.
May 09, 2012
On Wednesday, May 09, 2012 22:00:45 Adam D. Ruppe wrote:
> On Wednesday, 9 May 2012 at 19:58:14 UTC, Michaël Larouche wrote:
> > What if I want to submit a change or a fix to the langage that
> > 
> > require to change the backend too ?
> 
> There's nothing stopping that right now!
> 
> The only thing the backend license really prohibits is distributing it yourself.
> 
> Doing a personal fork, modifying it, and doing a pull request or a patch back upstream happens in practice somewhat normally.

Yeah. The lack of open sourceness for the backend is pretty much complete FUD. No, you can't redstribute it yourself, but it's completely open for viewing, editing, and contributing. And since _other_ backends exist, even if dmd were to die tomorrow, it wouldn't make it so that D would die (as huge a blow as that would be). I wish that people would just stop bringing up the "fact" that dmd isn't open source. It just seeds confusion and doesn't help anyone.

- Jonathan M Davis
May 09, 2012
On Wednesday, May 09, 2012 22:37:09 Jacob Carlborg wrote:
> On 2012-05-09 21:43, deadalnix wrote:
> >> How so?
> > 
> > We have a botleneck in accepting contributions.
> 
> * There's no road map
> * No release schedule
> * No overall goal

While those may be negative, I don't see how their lack makes the project any less FOSS. The source is open for contributions, and the forums where its development is discussed are freely available for anyone to join.

- Jonathan M Davis
May 09, 2012
What about SNN.lib, which has no source code (even assembly code) available whatsoever?

It's currently impossible to make an executable with DMD that *ONLY* contains code you want to put in there. SNN.lib /has/ to be in there... and it's certainly not FOSS...
May 09, 2012
On 09/05/12 21:43, deadalnix wrote:
> Le 09/05/2012 21:19, Nick Sabalausky a écrit :
>> "deadalnix"<deadalnix@gmail.com> wrote in message
>> news:jodll6$14eu$1@digitalmars.com...
>>>
>>> I'd that the most important part of FOSS isn't the license but the
>>> process. And we are not here yet.
>>
>> How so?
>>
>
> We have a botleneck in accepting contributions.

To an extent that seems to parallel most projects with a small team of core developers -- if you don't have enough people with the right combination of expertise, understanding and time commitment, it's difficult to effectively cope with the volume of bug reports, feature requests and potential new contributors.

That said, I don't think you can entirely divorce contribution issues from the licence.  One of the things that allows FOSS projects to scale effectively is that they have multiple distribution channels and (often) multiple partially independent development teams.  E.g. if you take the Linux kernel, you have many different distros, many of which have internal kernel dev teams; you have multiple different ways to get a working copy of the kernel (the kernel.org website, your distro of choice, your Android mobile phone, your web host, your embedded device ...), all of which create corresponding points of entry for contribution.

That spread of 3rd-party distribution and modification _does_ rely on the licence, as those suppliers need to be able to freely work on the code without needing to go through a single upstream point of contribution, and they need to have certainty that the permission to do so is not conditional or potentially able to be rescinded.
May 09, 2012
On Wed, 09 May 2012 16:59:10 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> What about SNN.lib, which has no source code (even assembly code) available whatsoever?
>
> It's currently impossible to make an executable with DMD that *ONLY* contains code you want to put in there. SNN.lib /has/ to be in there... and it's certainly not FOSS...

So...  Use GDC instead?

-Steve