www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lack of open source shown as negative part of D on Dr. Dobbs

reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
May 08 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2012 11:12 PM, Paulo Pinto wrote:

 http://www.drdobbs.com/architecture-and-design/232901652?cid=DDJ_nl_upd_2012-05-08_h&elq=60a2e0ea244a4667b97377cecc50110f




http://www.reddit.com/r/programming/comments/te6xv/d_go_vala_and_rust_a_new_generation_of_native/
May 09 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 08:12, Paulo Pinto a crit :

 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


DMD's backend isn't open source.
May 09 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 9 May 2012 at 10:43:22 UTC, deadalnix wrote:

 Le 09/05/2012 08:12, Paulo Pinto a écrit :

 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


 DMD's backend isn't open source.


I know that, but DMD is only the reference compiler.

While this is an unfortunate situation, there are other D 
compilers available,
which are fully open source.

The most important parts of D are the libraries and the compiler 
frontend, and those are open source.
May 09 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 13:29, Paulo Pinto a écrit :

 On Wednesday, 9 May 2012 at 10:43:22 UTC, deadalnix wrote:

 Le 09/05/2012 08:12, Paulo Pinto a écrit :

 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


 DMD's backend isn't open source.


 I know that, but DMD is only the reference compiler.

 While this is an unfortunate situation, there are other D compilers
 available,
 which are fully open source.

 The most important parts of D are the libraries and the compiler
 frontend, and those are open source.


I'd that the most important part of FOSS isn't the license but the 
process. And we are not here yet.
May 09 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"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?
May 09 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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.
May 09 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 23:00:16 Joseph Rushton Wakeling wrote:

 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.


The only thing that isn't fully open source is the dmd backend, and dmd gets 
more pull requests than druntime and Phobos combined (it's also the project 
with the biggest bottleneck, because _everything_ goes through Walter rather 
than a small group of developers). So, I don't think that the license is 
negatively impacting us at all as far as contributions go. It was having the 
source in svn rather than in git up on github which was the real problem. 
We've gotten _way_ more contributions (especially to dmd) ever since we put it 
all up on github.

- Jonathan M Davis
May 09 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 00:27, Jonathan M Davis wrote:

 The only thing that isn't fully open source is the dmd backend, and dmd gets
 more pull requests than druntime and Phobos combined (it's also the project
 with the biggest bottleneck, because _everything_ goes through Walter rather
 than a small group of developers). So, I don't think that the license is
 negatively impacting us at all as far as contributions go. It was having the
 source in svn rather than in git up on github which was the real problem.
 We've gotten _way_ more contributions (especially to dmd) ever since we put it
 all up on github.


Sure.  I've said a number of times that I don't think the backend licence is a 
short-term problem, and that's because I don't see the 
multiple-avenues-of-contribution aspect as a short-term issue either.  The user 
and contributor base is currently too small for it to be a factor.

I do think, though, that it may be something that starts to bite as the 
community scales up in size.
May 09 2012
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 00:41, Joseph Rushton Wakeling wrote:

 I do think, though, that it may be something that starts to bite as the
 community scales up in size.


I'll add one more thing on this: you probably don't know whether or not you're 
missing out, as there's no real way you can measure the number of people who 
would like to engage with D but don't because of the licensing issues.

There _might_ be a surprise waiting the day the announcement is made:
"reference 
D compiler now fully open source".
May 09 2012
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 09/05/12 13:29, Paulo Pinto wrote:

 On Wednesday, 9 May 2012 at 10:43:22 UTC, deadalnix wrote:

 DMD's backend isn't open source.


 I know that, but DMD is only the reference compiler.


... only!


 While this is an unfortunate situation, there are other D compilers available,
 which are fully open source.

 The most important parts of D are the libraries and the compiler frontend, and
 those are open source.


One way round the situation might be to try and coordinate releases of DMD, GDC 
and LDC[1] so that they are feature-equivalent and have passed the same set of 
tests, with official announcements giving equal weight and endorsement to these 
compilers.

Doing this would ensure that at any given time there is available at least 1 
fully open-source compiler implementing the reference standard and blessed as 
"official" by the project.

It's probably not a short term priority, but could be a useful longer-term 
policy to adopt, especially of the "not open source" claims start to be 
increasingly problematic.

---------
[1] I'm not sure of the status of LDC regarding D2 -- I have the impression
that 
GDC is further ahead and has developed better procedures for integrating
updates 
to the D frontend ... ?
May 09 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 9 May 2012 at 16:20:55 UTC, Joseph Rushton Wakeling 
wrote:

 One way round the situation might be to try and coordinate 
 releases of DMD, GDC and LDC[1] so that they are 
 feature-equivalent and have passed the same set of tests, with 
 official announcements giving equal weight and endorsement to 
 these compilers.


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.


 [1] I'm not sure of the status of LDC regarding D2 -- I have 
 the impression that GDC is further ahead and has developed 
 better procedures for integrating updates to the D frontend ... 
 ?


Thanks to the great job Iain did on GDC, it is true that LDC is 
probably a bit less stable right now, but D2 is the main target 
in terms of developer effort for LDC now as well.

David
May 09 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.465.1336596027.24740.digitalmars-d puremagic.com...

 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.


I didn't realize that was currently an issue. I agree, that ability would be 
nice. Especially if/when we finally get good support for ARM-based phones 
and tablets (back in my day, we called them PDAs), as that would be 
completely non-DMD.


 That should put all the "not OS" complaints to bed properly.


Maybe, but I suspect most "not OSS" complaints would be coming from people 
who don't even know that much about D, and are just knee-jerking over "The 
main compiler's backend isn't OSS?!? Well fuck that, then!"

'Course, I have zero evidence to back up that assertion.
May 09 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 23:38, Nick Sabalausky a écrit :

 Maybe, but I suspect most "not OSS" complaints would be coming from people
 who don't even know that much about D, and are just knee-jerking over "The
 main compiler's backend isn't OSS?!? Well fuck that, then!"

 'Course, I have zero evidence to back up that assertion.


Just compare the number of contribution since the project have been 
mostly open sourced on on github. Numbers speak for themselves.
May 09 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 17:49:34 -0400, deadalnix <deadalnix gmail.com> wrot=
e:


 Le 09/05/2012 23:38, Nick Sabalausky a =C3=A9crit :

 Maybe, but I suspect most "not OSS" complaints would be coming from  =





 people
 who don't even know that much about D, and are just knee-jerking over=




  =


 "The
 main compiler's backend isn't OSS?!? Well fuck that, then!"

 'Course, I have zero evidence to back up that assertion.


 Just compare the number of contribution since the project have been  =



 mostly open sourced on on github. Numbers speak for themselves.


I think this was more of a factor of github than open source -- The  =

compiler was open sourced (in the same manner as it is on github) for  =

years on dsource.org under subversion.

See here: http://dsource.org/projects/dmd/changeset/183

-Steve
May 09 2012
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 09/05/12 23:38, Nick Sabalausky wrote:

 "Joseph Rushton Wakeling"<joseph.wakeling webdrake.net>  wrote in message
 news:mailman.465.1336596027.24740.digitalmars-d puremagic.com...

 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.


 I didn't realize that was currently an issue. I agree, that ability would be
 nice.


Yesterday or the day before I pulled the latest Phobos into my dev branch and 
tried to compile it, only for some unittests to fall over rather nastily.  Of 
course, it was because the latest Phobos updates relied on some recent updates 
to DMD and/or Druntime: I had to pull and compile the latest versions of those 
before Phobos would compile and pass tests.

It's unlikely that GDC and/or LDC could pick up those sorts of updates quickly 
enough to not impact on developers, unless there's a deliberate policy of 
keeping feature parity.  So that means (for now) there's no way that one can 
reliably hack on Phobos using one of the fully open source compilers.


 Especially if/when we finally get good support for ARM-based phones
 and tablets (back in my day, we called them PDAs), as that would be
 completely non-DMD.


Yea, ARM support seems important to me too, both for phones, tablets etc. and 
for much of the new upcoming server solutions.  I also fancy coding with D on a 
Raspberry Pi. :-)


 Maybe, but I suspect most "not OSS" complaints would be coming from people
 who don't even know that much about D, and are just knee-jerking over "The
 main compiler's backend isn't OSS?!? Well fuck that, then!"


This is my fear as well. :-(
May 09 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.476.1336601495.24740.digitalmars-d puremagic.com...

 On 09/05/12 23:38, Nick Sabalausky wrote:

 Especially if/when we finally get good support for ARM-based phones
 and tablets (back in my day, we called them PDAs), as that would be
 completely non-DMD.


 Yea, ARM support seems important to me too, both for phones, tablets etc. 
 and for much of the new upcoming server solutions.


Really? ARM servers? This is the first I've heard of it. (Intel must be 
crapping themselves.)


I also fancy coding with D on a Raspberry Pi. :-)


Me too! Imagine how much more power you could get out of it using D instead 
of the packed-in Python.

But I think the big bottleneck there is actually *getting* a Raspberry Pi ;) 
Seriously, I heard that some lucky few had actually gotten theirs a while 
ago, so I went looking to get in line for one (expecting there would still 
be quite a delay between ordering and shipping). But there's so much 
interest, nobody's even accepting preorders anymore. All you can do is get 
on a list to be notified of updates to availability. Apperently, even the 
preorders that *have* gone through are backlogged to at least the middle of 
summer.

Just as well, I guess: Even if I had one today, it'd probably be quite 
awhile before I'd even have the time to play with it anyway. And if I do get 
time, there's a VM image of it you can download and play with (which I got 
and still haven't looked at ;) ).
May 09 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/05/2012 06:35, Nick Sabalausky a crit :

 "Joseph Rushton Wakeling"<joseph.wakeling webdrake.net>  wrote in message
 news:mailman.476.1336601495.24740.digitalmars-d puremagic.com...

 On 09/05/12 23:38, Nick Sabalausky wrote:

 Especially if/when we finally get good support for ARM-based phones
 and tablets (back in my day, we called them PDAs), as that would be
 completely non-DMD.


 Yea, ARM support seems important to me too, both for phones, tablets etc.
 and for much of the new upcoming server solutions.


 Really? ARM servers? This is the first I've heard of it. (Intel must be
 crapping themselves.)


ARM is more energy efficient than x86 . This is a more and more serious 
alternative for datacenters.
May 10 2012
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 10:18, deadalnix wrote:

 Le 10/05/2012 06:35, Nick Sabalausky a crit :

 Really? ARM servers? This is the first I've heard of it. (Intel must be
 crapping themselves.)


 ARM is more energy efficient than x86 . This is a more and more serious
 alternative for datacenters.


Yea, it's in the process of arriving now but is surely going to be a very big 
deal -- lower energy consumption, lower heat production (= more densely packed 
datacentres), cheaper individual nodes ...

See e.g.:
http://www.bbc.com/news/technology-15540910
https://www.pcworld.com/article/249988/hp_to_make_arm_servers_available_for_testing_in_q2.html
http://www.omgubuntu.co.uk/2012/01/arm-servers-lca/

When you also factor in that within a year you're likely to be seeing full 
desktop solutions running off ARM-based phone/tablet devices [see e.g. 
http://www.ubuntu.com/devices/android ] it should be apparent that ARM is a
very 
important target for D.

To me, that's a reason as compelling as the licensing issues (if not more so) 
why the reference D compiler might want to switch to an alternative backend.
May 10 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 10 May 2012 12:38, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net>wrote:


 On 10/05/12 10:18, deadalnix wrote:


 Le 10/05/2012 06:35, Nick Sabalausky a =C3=A9crit :


 Really? ARM servers? This is the first I've heard of it. (Intel must be
 crapping themselves.)


 ARM is more energy efficient than x86 . This is a more and more serious
 alternative for datacenters.


 Yea, it's in the process of arriving now but is surely going to be a very
 big deal -- lower energy consumption, lower heat production (=3D more den=


sely

 packed datacentres), cheaper individual nodes ...

 See e.g.:
 http://www.bbc.com/news/**technology-15540910<http://www.bbc.com/news/tec=


hnology-15540910>

 https://www.pcworld.com/**article/249988/hp_to_make_arm_**
 servers_available_for_testing_**in_q2.html<https://www.pcworld.com/articl=


e/249988/hp_to_make_arm_servers_available_for_testing_in_q2.html>

 http://www.omgubuntu.co.uk/**2012/01/arm-servers-lca/<http://www.omgubunt=


u.co.uk/2012/01/arm-servers-lca/>

 When you also factor in that within a year you're likely to be seeing ful=


l

 desktop solutions running off ARM-based phone/tablet devices [see e.g.
 http://www.ubuntu.com/devices/**android<http://www.ubuntu.com/devices/and=


roid>] it should be apparent that ARM is a very important target for D.

 To me, that's a reason as compelling as the licensing issues (if not more
 so) why the reference D compiler might want to switch to an alternative
 backend.


Amen! :)
May 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2012 9:35 PM, Nick Sabalausky wrote:

 Just as well, I guess: Even if I had one today, it'd probably be quite
 awhile before I'd even have the time to play with it anyway. And if I do get
 time, there's a VM image of it you can download and play with (which I got
 and still haven't looked at ;) ).


Oh, I wish I could take time off and hack away on a Pi !

I've always wanted a computer that had no fan and used only a handful of watts.
May 12 2012
parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, May 12, 2012 at 1:21 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 5/9/2012 9:35 PM, Nick Sabalausky wrote:


 Just as well, I guess: Even if I had one today, it'd probably be quite
 awhile before I'd even have the time to play with it anyway. And if I do
 get
 time, there's a VM image of it you can download and play with (which I got
 and still haven't looked at ;) ).


 Oh, I wish I could take time off and hack away on a Pi !

 I've always wanted a computer that had no fan and used only a handful of
 watts.


I've been using a Trimslice ( http://trimslice.com/web/ ) as a home server
and router for a while now. Higher end specs, a nicer box, and they give a
discount to open source developers.
May 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2012 7:02 PM, Andrew Wiley wrote:

 On Sat, May 12, 2012 at 1:21 PM, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:
     I've always wanted a computer that had no fan and used only a handful of
watts.
 I've been using a Trimslice ( http://trimslice.com/web/ ) as a home server and
 router for a while now. Higher end specs, a nicer box, and they give a discount
 to open source developers.



But nobody makes a *desktop* fanless arm machine.
May 12 2012
next sibling parent "jerro" <a a.com> writes:
On Sunday, 13 May 2012 at 03:33:56 UTC, Walter Bright wrote:

 On 5/12/2012 7:02 PM, Andrew Wiley wrote:

 On Sat, May 12, 2012 at 1:21 PM, Walter Bright 
 <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:
    I've always wanted a computer that had no fan and used only 
 a handful of watts.
 I've been using a Trimslice ( http://trimslice.com/web/ ) as a 
 home server and
 router for a while now. Higher end specs, a nicer box, and 
 they give a discount
 to open source developers.



 But nobody makes a *desktop* fanless arm machine.


You could use a beagle board or a panda board as a desktop 
computer.
May 12 2012
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 5/12/2012 8:33 PM, Walter Bright wrote:

 On 5/12/2012 7:02 PM, Andrew Wiley wrote:

 On Sat, May 12, 2012 at 1:21 PM, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:
     I've always wanted a computer that had no fan and used only a handful of
watts.
 I've been using a Trimslice ( http://trimslice.com/web/ ) as a home server and
 router for a while now. Higher end specs, a nicer box, and they give a discount
 to open source developers.


 
 
 But nobody makes a *desktop* fanless arm machine.


... yet.
May 12 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Thu, 10 May 2012, Joseph Rushton Wakeling wrote:


 Yesterday or the day before I pulled the latest Phobos into my dev branch and
 tried to compile it, only for some unittests to fall over rather nastily.  Of
 course, it was because the latest Phobos updates relied on some recent updates
 to DMD and/or Druntime: I had to pull and compile the latest versions of those
 before Phobos would compile and pass tests.
 
 It's unlikely that GDC and/or LDC could pick up those sorts of updates quickly
 enough to not impact on developers, unless there's a deliberate policy of
 keeping feature parity.  So that means (for now) there's no way that one can
 reliably hack on Phobos using one of the fully open source compilers.


If you're using ldc or gdc, you should develop agains the gdc/ldc provided 
druntime and phobos too.
May 09 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 01:43, Brad Roberts wrote:

 If you're using ldc or gdc, you should develop agains the gdc/ldc provided
 druntime and phobos too.


No, that's a recipe for fragmentation.  Phobos should be developed in consort 
with the DMD frontend.  The problem is that DMD frontend updates take time to 
percolate across to GDC/LDC.
May 09 2012
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Thu, 10 May 2012, Joseph Rushton Wakeling wrote:


 On 10/05/12 01:43, Brad Roberts wrote:

 If you're using ldc or gdc, you should develop agains the gdc/ldc provided
 druntime and phobos too.


 
 No, that's a recipe for fragmentation.  Phobos should be developed in consort
 with the DMD frontend.  The problem is that DMD frontend updates take time to
 percolate across to GDC/LDC.


You're reading something other than what I said.  Develop against doesn't 
imply leave it forked.
May 09 2012
parent =?UTF-8?B?Ik1pY2hhw6ts?= Larouche" <michael.larouche gmail.com> writes:
On Thursday, 10 May 2012 at 00:28:43 UTC, Brad Roberts wrote:

 On Thu, 10 May 2012, Joseph Rushton Wakeling wrote:


 On 10/05/12 01:43, Brad Roberts wrote:

 If you're using ldc or gdc, you should develop agains the 
 gdc/ldc provided
 druntime and phobos too.


 
 No, that's a recipe for fragmentation.  Phobos should be 
 developed in consort
 with the DMD frontend.  The problem is that DMD frontend 
 updates take time to
 percolate across to GDC/LDC.


 You're reading something other than what I said.  Develop 
 against doesn't
 imply leave it forked.


But it implies additional maintenance: merge the upstream 
druntime/phobos, make sure your custom patches (if any) still 
works, delay in security and bug fix, additional support for the 
community if the version shipped with GDC and/or is too old.
May 09 2012
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 9 May 2012 17:20, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 [1] I'm not sure of the status of LDC regarding D2 -- I have the impression
 that GDC is further ahead and has developed better procedures for
 integrating updates to the D frontend ... ?


The procedure is 'get it done' approach.   Meld helps alot, not having
too many differences between the frontends helps alot, using the D2
testsuite at every stage of the process helps alot.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 09 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2012 9:37 AM, Iain Buclaw wrote:

 The procedure is 'get it done' approach.   Meld helps alot, not having
 too many differences between the frontends helps alot, using the D2
 testsuite at every stage of the process helps alot.



I don't know what I'd do without meld these days. It's one of the most useful 
programming tools to come down the pike in years!

There's a workalike on Windows called "winmerge" for those who develop on
Windows.
May 12 2012
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 12 May 2012 at 18:25:33 UTC, Walter Bright wrote:

 On 5/9/2012 9:37 AM, Iain Buclaw wrote:

 The procedure is 'get it done' approach.   Meld helps alot, 
 not having
 too many differences between the frontends helps alot, using 
 the D2
 testsuite at every stage of the process helps alot.



 I don't know what I'd do without meld these days. It's one of 
 the most useful programming tools to come down the pike in 
 years!

 There's a workalike on Windows called "winmerge" for those who 
 develop on Windows.


I don't know about meld, but I've found kdiff3 very good for 
3-way merge. Its merging algorithm is good and does most of the 
work.

A very good list of merging tools:
http://stackoverflow.com/questions/572237/whats-the-best-three-way-merge-tool
May 12 2012
prev sibling next sibling parent reply =?UTF-8?B?Ik1pY2hhw6ts?= Larouche" <michael.larouche gmail.com> writes:
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
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
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
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
May 09 2012
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 9 May 2012 at 21:06:40 UTC, Steven Schveighoffer 
wrote:

 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



See the last paragraph of this response:
http://forum.dlang.org/thread/jod1sg$2pma$1 digitalmars.com?page=2#post-mailman.465.1336596027.24740.digitalmars-d:40puremagic.com
May 09 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 17:09:10 -0400, Mehrdad <wfunction hotmail.com> wrote:


 On Wednesday, 9 May 2012 at 21:06:40 UTC, Steven Schveighoffer wrote:

 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



 See the last paragraph of this response:
 http://forum.dlang.org/thread/jod1sg$2pma$1 digitalmars.com?page=2#post-mailman.465.1336596027.24740.digitalmars-d:40puremagic.com


I must be missing something, or you referenced the post incorrectly...

-Steve
May 09 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 23:29, Steven Schveighoffer a écrit :

 On Wed, 09 May 2012 17:09:10 -0400, Mehrdad <wfunction hotmail.com> wrote:


 On Wednesday, 9 May 2012 at 21:06:40 UTC, Steven Schveighoffer wrote:

 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



 See the last paragraph of this response:
 http://forum.dlang.org/thread/jod1sg$2pma$1 digitalmars.com?page=2#post-mailman.465.1336596027.24740.digitalmars-d:40puremagic.com


 I must be missing something, or you referenced the post incorrectly...

 -Steve


dmd is the reference implementation. GDC is and will always lack behind. 
By definition.
May 09 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Again, Joseph's reply is what I'm referring to:

http://forum.dlang.org/post/mailman.473.1336599671.24740.digitalmars-d puremagic.com
May 09 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 09/05/12 23:06, Steven Schveighoffer wrote:

 So... Use GDC instead?


... and if I want to hack on Druntime or Phobos ... ? :-)

[cf. what I was told here ... 
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Hacking_on_Phob
s_34765.html#N34770 
]
May 09 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 17:39:36 -0400, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:


 On 09/05/12 23:06, Steven Schveighoffer wrote:

 So... Use GDC instead?


 .... and if I want to hack on Druntime or Phobos ... ? :-)

 [cf. what I was told here ...  
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/Hacking_on_Phob
s_34765.html#N34770  
 ]


For what purpose?  To get it included in phobos/druntime?  DMD.  But it  
will percolate to gdc afterwards.

But that's not exactly a problem with distribution, is it?  If you're  
hacking phobos or druntime for purposes of improving phobos or druntime,  
why do you need to distribute snn.lib?

If you just want to distribute programs, and you don't want to distribute  
snn.lib with them (which you are free to do BTW), then use gdc.

-Steve
May 09 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 00:23, Steven Schveighoffer wrote:

 On Wed, 09 May 2012 17:39:36 -0400, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 .... and if I want to hack on Druntime or Phobos ... ? :-)


 For what purpose? To get it included in phobos/druntime? DMD.


Well, yes, that's my point.  If I want to contribute to Phobos/Druntime, I 
_have_ to use a partially-proprietary program.  To me, that's an irritation. 
To 
other potential contributors, it's a blocking factor.


 But that's not exactly a problem with distribution, is it? If you're hacking
 phobos or druntime for purposes of improving phobos or druntime, why do you
need
 to distribute snn.lib?


I didn't say I did.  I'm just observing that contributing to the heart of the D 
project requires me to install and use proprietary code.

To me that's a tolerable compromise as (as you say) the changes percolate to
the 
fully open source solutions, and in any case DMD is in practice very open.  But 
there are people who _aren't_ willing to make that compromise, and others who 
will be put off before they even realize that compromise is possible.
May 09 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 18:32:26 -0400, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:


 But there are people who _aren't_ willing to make that compromise, and  
 others who will be put off before they even realize that compromise is  
 possible.


To be perfectly honest, I don't really care :)  I'm here to get stuff  
done, not debate about ideology.  Those who wish to complain about or  
avoid D, will.  And I really can't do much about that.  There are those  
who will refuse to use D because it's not copyleft.  Good luck getting  
those people on board ;)

I think we have a pretty awesome and talented team working on D, and in  
the end, performance is what matters, not who your friends are.

-Steve
May 09 2012
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 00:45, Steven Schveighoffer wrote:

 On Wed, 09 May 2012 18:32:26 -0400, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:


 But there are people who _aren't_ willing to make that compromise, and others
 who will be put off before they even realize that compromise is possible.


 There are those who will refuse to use D because it's not copyleft. Good luck
getting those people on board ;)


Do you mean there are those who will refuse to use D if it _is_ copyleft?

I've never heard of anybody refusing to use a piece of software because it had 
e.g. a permissive licence.  Refuse to contribute, possibly, but that's a much 
more extreme and fringe position than the "must be open source!" one.


 I think we have a pretty awesome and talented team working on D, and in the
end,
 performance is what matters, not who your friends are.


Re the team, we absolutely agree. :-)

Re friends: I always think it's a good idea to have lots, and from as diverse a 
range of backgrounds as possible.  I just don't see what _good_ it does to have 
the backend non-OS, given the possible harms it can do.

The short-term benefit is that the status quo allows the team to keep improving 
the language with minimal hassle (not having to learn a new backend model or 
negotiate with Symantec over licensing), but that's only a benefit up until the 
point where D2 stabilizes.  Beyond that, any advantage vanishes.
May 09 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 19:03:01 -0400, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:



 Re friends: I always think it's a good idea to have lots, and from as  
 diverse a range of backgrounds as possible.  I just don't see what  
 _good_ it does to have the backend non-OS, given the possible harms it  
 can do.


I don't think it's a matter of "good" vs. a matter of "reality".

There are two driving factors here:

1. Walter is, for better or worse, the benevolent dictator for D.  And he
has history/familiarity with this backend.
2. Walter does not want to "taint" his knowledge of compilers with some
other backend that would potentially harm his ability to write
closed-source code for profit.  He is very adamant about this.

I think the only real solution is for someone to write a good backend for
D from scratch, and then assign the appropriate rights to Walter.  I think
if Walter did it himself, it leaves dmd open to lawsuit from the current
copyright holder of the backend, since Walter's knowledge is so
intertwined with that code.

*I* would love to see the reference compiler for D actually written in D
completely, and fully open source.  But I think the current situation is
not very harmful at all -- The compiler is a tool, and one typically
doesn't care about the tool itself vs what it generates.

-Steve
May 10 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 10 May 2012 at 14:03:15 UTC, Steven Schveighoffer 
wrote:

 2. Walter does not want to "taint" his knowledge of compilers 
 with some
 other backend that would potentially harm his ability to write
 closed-source code for profit.  He is very adamant about this.


That's what I would have answered as well, from what I recall 
from previous discussions – but Walter, could we please get a 
definite statement from you? As far as I recall, most of the time 
a discussion of this topic came up so far, it went largely 
without any comments by you, even though you are the only person 
really qualified to answer any questions on this topic…


 I think the only real solution is for someone to write a good 
 backend for
 D from scratch, and then assign the appropriate rights to 
 Walter. I think
 if Walter did it himself, it leaves dmd open to lawsuit from 
 the current
 copyright holder of the backend, since Walter's knowledge is so
 intertwined with that code.


What exactly would that buy us – I don't quite see how it would 
allow Walter to work on it, compared to, say, LLVM or GCC. And I 
don't buy the argument that Walter can't look at the source of 
compilers not owned by him, because it supposedly might make him 
vulnerable to copyright claims. Program optimization is a quite 
well-researched topic, and besides, even if DMC was somehow 
»tainted« by LLVM code, Walter would just have to add a 
copyright note to the docs and could continue to distribute DMD 
under his own terms – LLVM is BSD(-style) licensed.

Besides, writing another new backend just for D/DMD would be pure 
madness in terms of resources required – even LLVM, which is 
backed by a bunch of companies, has a hard time against GCC in 
terms of optimization, let alone ICC (on x86).

David
May 10 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 May 2012 15:03:48 -0400, David Nadlinger <see klickverbot.at>=
  =

wrote:


 On Thursday, 10 May 2012 at 14:03:15 UTC, Steven Schveighoffer wrote:



 I think the only real solution is for someone to write a good backend=




  =


 for
 D from scratch, and then assign the appropriate rights to Walter. I  =





 think
 if Walter did it himself, it leaves dmd open to lawsuit from the curr=




ent

 copyright holder of the backend, since Walter's knowledge is so
 intertwined with that code.


 What exactly would that buy us =E2=80=93 I don't quite see how it woul=


d allow  =


 Walter to work on it


That's why I said "assign the appropriate rights" to Walter.  If Walter =
 =

owns the code, or can prove that nobody owns it (i.e. public domain), th=
en  =

he can't be sued.

Now, if he has to rewrite large portions of it, it probably doesn't make=
  =

sense.  I'm not sure of his position, I'm only speculating.


 compared to, say, LLVM or GCC. And I don't buy the argument that Walte=


r  =


 can't look at the source of compilers not owned by him, because it  =



 supposedly might make him vulnerable to copyright claims. Program  =



 optimization is a quite well-researched topic, and besides, even if DM=


C  =


 was somehow =C2=BBtainted=C2=AB by LLVM code, Walter would just have t=


o add a  =


 copyright note to the docs and could continue to distribute DMD under =


 =


 his own terms =E2=80=93 LLVM is BSD(-style) licensed


Wait till you hear the story of Walter and a room full of lawyers ;)


 Besides, writing another new backend just for D/DMD would be pure  =



 madness in terms of resources required =E2=80=93 even LLVM, which is b=


acked by a  =


 bunch of companies, has a hard time against GCC in terms of  =



 optimization, let alone ICC (on x86).


I honestly have no idea.  Never looked at it before.

-Steve
May 10 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 10, 2012 at 01:03:01AM +0200, Joseph Rushton Wakeling wrote:

 On 10/05/12 00:45, Steven Schveighoffer wrote:


[...]

There are those who will refuse to use D because it's not copyleft.
Good luck getting those people on board ;)


 
 Do you mean there are those who will refuse to use D if it _is_
 copyleft?
 
 I've never heard of anybody refusing to use a piece of software
 because it had e.g. a permissive licence.  Refuse to contribute,
 possibly, but that's a much more extreme and fringe position than
 the "must be open source!" one.


There are both. Some proprietary developers avoid GPL like the plague
due to the whole "you must publish all your precious source code if you
distribute the binary" issue. Some other developers, admittedly in the
minority compared to the first group, refuse to have anything to do with
non-GPL'd code (or at least, have an OSS-compliant license) because of
idealogical concerns. (For example, you will not be able to convince an
FSF developer to adopt dmd.)


[...]

 Re friends: I always think it's a good idea to have lots, and from
 as diverse a range of backgrounds as possible.  I just don't see
 what _good_ it does to have the backend non-OS, given the possible
 harms it can do.


But that's just crying over spilt milk. Walter has already tried to
change the license, to no avail.



 The short-term benefit is that the status quo allows the team to
 keep improving the language with minimal hassle (not having to learn
 a new backend model or negotiate with Symantec over licensing), but
 that's only a benefit up until the point where D2 stabilizes.
 Beyond that, any advantage vanishes.


So are you proposing that we rewrite the dmd backend with fresh code
that's not encumbered by the current license?


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss,
binary trees... and bugs.
May 09 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 01:14, H. S. Teoh wrote:

 There are both. Some proprietary developers avoid GPL like the plague
 due to the whole "you must publish all your precious source code if you
 distribute the binary" issue. Some other developers, admittedly in the
 minority compared to the first group, refuse to have anything to do with
 non-GPL'd code (or at least, have an OSS-compliant license) because of
 idealogical concerns. (For example, you will not be able to convince an
 FSF developer to adopt dmd.)


Well, "OSS-compliant licence" covers a LOT of options, not all of them 
GPL-compatible, not all of them copyleft.  I can't see there being a huge 
problem if DMD were distributed under a permissive license such as Apache, 
BSD/MIT or Boost.  Yes, there might be some hardcore people who would like a 
strong copyleft approach, but that's a much smaller number of people than the 
numbers who care about it being a licence that meets the FSF criteria for a
free 
licence.

As for the "avoid GPL" folks, you may already be buggered there. :-)  Or you 
could multi-license so that everyone's happy.  (MPL/GPL/LGPL tri-licence?)


 So are you proposing that we rewrite the dmd backend with fresh code
 that's not encumbered by the current license?


I think there are a number of possible solutions, including not just a rewrite 
but also just blessing either GDC or LDC as the reference implementation once 
their D2 support has reached maturity/parallel with DMD.  I'd favour LDC, to 
avoid the negative associations some people have with the GNU project.
May 09 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.500.1336605832.24740.digitalmars-d puremagic.com...

 On 10/05/12 01:14, H. S. Teoh wrote:


 So are you proposing that we rewrite the dmd backend with fresh code
 that's not encumbered by the current license?


 I think there are a number of possible solutions, including not just a 
 rewrite but also just blessing either GDC or LDC as the reference 
 implementation once their D2 support has reached maturity/parallel with 
 DMD.  I'd favour LDC, to avoid the negative associations some people have 
 with the GNU project.


LDC would need to get their Windows support into a usable state for that to 
happen. Last I checked (admittedly awhile ago), there didn't seem to be any 
movement in that direction.
May 09 2012
parent reply Gour <gour atmarama.net> writes:
On Thu, 10 May 2012 00:42:26 -0400
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote:


 LDC would need to get their Windows support into a usable state for
 that to happen. Last I checked (admittedly awhile ago), there didn't
 seem to be any movement in that direction.


I heard 3.1 is improving things and that should be soon...


Sincerely,
Gour

--=20
As the embodied soul continuously passes, in this body,=20
from boyhood to youth to old age, the soul similarly passes=20
into another body at death. A sober person is not bewildered=20
by such a change.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
May 10 2012
parent "Kagamin" <spam here.lot> writes:
On Thursday, 10 May 2012 at 13:09:10 UTC, Gour wrote:

 I heard 3.1 is improving things and that should be soon...


Wow
---
DW2 Exception Handling is enabled on Cygwin and MinGW
---

I wonder whether linux code for emitting dwarf exception tables 
will work out of the box on windows... and where to get unwinder?
May 10 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 May 2012 at 20:59:11 UTC, Mehrdad wrote:

 What about SNN.lib, which has no source code (even assembly 
 code) available whatsoever?


Well, the source is available if you buy it. $45 I think.
May 09 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/9/12 3:51 PM, Jonathan M Davis wrote:

 Yeah. The lack of open sourceness for the backend is pretty much complete FUD.


The problem is, the damage is there and is real. It's like in those 
crazy situations - an allegation of harassment still affects a teacher's 
career, even if there's a simple explanation. The only answer to "is it 
open source?" can be an unqualified "yes".

I wish we could get rid of this crappy backend situation.


Andrei
May 09 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 09, 2012 at 10:15:23PM -0500, Andrei Alexandrescu wrote:

 On 5/9/12 3:51 PM, Jonathan M Davis wrote:

Yeah. The lack of open sourceness for the backend is pretty much
complete FUD.


 
 The problem is, the damage is there and is real. It's like in those
 crazy situations - an allegation of harassment still affects a
 teacher's career, even if there's a simple explanation. The only
 answer to "is it open source?" can be an unqualified "yes".


Yeah, it may be FUD, but it still causes damage. Simply declaring it FUD
does not magically repair the damage.



 I wish we could get rid of this crappy backend situation.


[...]

How, though? Clearly, given what is said about Walter's situation, it
appears that he can't look at (much less work on) another backend
without legal implications and other issues. And asking someone to throw
away 20 years of work (rewrite the backend) is asking a bit too much.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by
throwing someone out a window", or more recently "to remove Windows from
a computer and replace it with something useful". :-) -- John Cowan
May 09 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 22:15:23 Andrei Alexandrescu wrote:

 On 5/9/12 3:51 PM, Jonathan M Davis wrote:

 Yeah. The lack of open sourceness for the backend is pretty much complete
 FUD.


 The problem is, the damage is there and is real. It's like in those
 crazy situations - an allegation of harassment still affects a teacher's
 career, even if there's a simple explanation. The only answer to "is it
 open source?" can be an unqualified "yes".


Well, that's what FUD does. It creates Fear Uncertainty and Doubt without 
being backed by facts. It just creates damage. So, the situation itself 
shouldn't be a problem, but people keep bringing it up anyway, which _does_ 
cause us problems.


 I wish we could get rid of this crappy backend situation.


Yeah, but I don't know how. As long as Semantec has the rights to it and won't 
change its license, we don't have much choice - not unless we want to replace 
the whole thing.

- Jonathan M Davis
May 09 2012
parent reply =?UTF-8?B?Ik1pY2hhw6ts?= Larouche" <michael.larouche gmail.com> writes:
On Thursday, 10 May 2012 at 03:35:37 UTC, Jonathan M Davis wrote:

 On Wednesday, May 09, 2012 22:15:23 Andrei Alexandrescu wrote:

 On 5/9/12 3:51 PM, Jonathan M Davis wrote:

 Yeah. The lack of open sourceness for the backend is pretty 
 much complete
 FUD.


 The problem is, the damage is there and is real. It's like in 
 those
 crazy situations - an allegation of harassment still affects a 
 teacher's
 career, even if there's a simple explanation. The only answer 
 to "is it
 open source?" can be an unqualified "yes".


 Well, that's what FUD does. It creates Fear Uncertainty and 
 Doubt without
 being backed by facts. It just creates damage. So, the 
 situation itself
 shouldn't be a problem, but people keep bringing it up anyway, 
 which _does_
 cause us problems.


 I wish we could get rid of this crappy backend situation.


 Yeah, but I don't know how. As long as Semantec has the rights 
 to it and won't
 change its license, we don't have much choice - not unless we 
 want to replace
 the whole thing.

 - Jonathan M Davis


It's a crazy idea I know, but maybe we could, as a community, buy 
the rights from Symantec. Blender was a close-source program 
originally and the open-source community raised money to buy the 
source code from the defunct company that made Blender.
May 09 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 May 2012 at 03:40:54 UTC, Michaël Larouche wrote:

 It's a crazy idea I know, but maybe we could, as a community,  
 buy the rights from Symantec. Blender was a close-source  
 program originally and the open-source community raised money  
 to buy the source code from the defunct company that made  
 Blender.


  I'd prefer to see LLVM used as the back end; mostly based on 
emerging technologies and it's likely a bit cleaner than GNU.

  Anyways. If the community wants to buy the rights so we can free 
it, I guess it's just a matter of collecting the money and 
finding out what their price is, and they have to weigh the cost 
vs current and future possible profits. How much would it cost to 
buy it from them? $100K? $25K?
May 09 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-10 06:09, Era Scarecrow wrote:


 I'd prefer to see LLVM used as the back end; mostly based on emerging
 technologies and it's likely a bit cleaner than GNU.


So do I.


 Anyways. If the community wants to buy the rights so we can free it, I
 guess it's just a matter of collecting the money and finding out what
 their price is, and they have to weigh the cost vs current and future
 possible profits. How much would it cost to buy it from them? $100K? $25K?


It would be interesting to get a price from Symantec.

-- 
/Jacob Carlborg
May 10 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-05-10 04:09:28 +0000, "Era Scarecrow" <rtcvb32 yahoo.com> said:


 On Thursday, 10 May 2012 at 03:40:54 UTC, Michaël Larouche wrote:

 It's a crazy idea I know, but maybe we could, as a community,  buy the 
 rights from Symantec. Blender was a close-source  program originally 
 and the open-source community raised money  to buy the source code from 
 the defunct company that made  Blender.


 
   I'd prefer to see LLVM used as the back end; mostly based on emerging 
 technologies and it's likely a bit cleaner than GNU.


When doing the DMD/Objective-C project[1], I was somewhat torn between 
building it on top of LDC (LLVM) or directly within DMD. I chose the 
second option because I wanted this to be later merged within the 
reference compiler, and Walter has been supportive of that. But that 
choice meant I could not reuse the code from LLVM/Clang for emitting 
the Objective-C binaries (I had to build it from scratch), and it means 
no ARM support (for iOS) until either DMD supports ARM or my changes 
get somehow ported to LDC (which probably won't be that 
straightforward).

For me, hacking the reference compiler is more work for initially less 
results… and this might have contributed to things being currently 
stalled. There is a big potential benefit to hacking the reference 
implementation: it's easier to keep things in sync later. But if it 
stalls initial development, there's no such benefit. Something tells me 
that if I restart the project, it might very well be top of LLVM 
instead of DMD, improvements to the reference compiler be damned.

In my opinion, the front end would gain much by being a standalone 
library: same library could be used with separate glue code for each 
backend. It'd also help to have a single druntime being shared between 
all those. I can always dream…

 [1]: http://michelf.com/projects/d-objc/

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-10 13:32, Michel Fortin wrote:


 In my opinion, the front end would gain much by being a standalone
 library: same library could be used with separate glue code for each
 backend. It'd also help to have a single druntime being shared between
 all those. I can always dream…


I completely agree.

-- 
/Jacob Carlborg
May 10 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 05:35, Jonathan M Davis wrote:

 Well, that's what FUD does. It creates Fear Uncertainty and Doubt without
 being backed by facts. It just creates damage. So, the situation itself
 shouldn't be a problem, but people keep bringing it up anyway, which _does_
 cause us problems.


If anything the present debate has confirmed, again, that the practical 
implications of the backend licence are negligible, that there are at least 2 
valid and fully open-source alternative compilers, and that the core D
community 
strongly supports those alternatives.  But you have to get _into_ the debate to 
appreciate that.

The problem is rather the note on Wikipedia which points out that the reference 
compiler backend is not open source.  That's a fact, and it's a fact which
leads 
people to make damaging assumptions.  And there's not really a lot you can do 
about that while the fact remains as it is.

FWIW I think there have been positive sides to the proprietary backend.  I'm
not 
sure we'd have had GDC or LDC if the backend had been open source, and GDC 
produces much more efficient code -- D is much more able to compete with C++ 
speed-wise as a result.


 Yeah, but I don't know how. As long as Semantec has the rights to it and won't
 change its license, we don't have much choice - not unless we want to replace
 the whole thing.


Assuming that LLVM is not an acceptable backend despite its permissive licence, 
and that the community can't buy out the code, I'd suggest again the idea of 
stabilizing the frontend and then synchronizing DMD, GDC and LDC updates, with 
all 3 endorsed as equally valid implementations of the reference standard.
May 10 2012
parent Don Clugston <dac nospam.com> writes:
On 10/05/12 11:02, Joseph Rushton Wakeling wrote:

 Assuming that LLVM is not an acceptable backend despite its permissive
 licence, and that the community can't buy out the code, I'd suggest
 again the idea of stabilizing the frontend and then synchronizing DMD,
 GDC and LDC updates, with all 3 endorsed as equally valid
 implementations of the reference standard.


Yes. This is what we need to work towards.
May 10 2012
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 09/05/12 22:51, Jonathan M Davis wrote:

 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.


Well, the backend licence fails to meet the standards of the Free Software 
definition or the Open Source definition.  Being able to freely redistribute
the 
software in both verbatim and modified forms is pretty much THE major criterion 
for either.  It's not FUD to say so, just a fact.

The FUD comes in because people take that fact to mean that the situation is 
worse than it is (e.g. they might think the development process is partially 
closed, when it isn't), or try and read things into it that aren't true (e.g. 
they might think you can't write D programs to operate in a purely FOSS 
environment, when in fact you have GDC and LDC).  All of this creates for you a 
burden of explanation that has to be repeated and repeated to potential users
or 
contributors.  A fully open-source reference compiler would take away all those 
problems.

On a more practical level, the inability of 3rd parties to distribute DMD could 
have an effect in limiting points of access to the software, with corresponding 
effects on the possible channels of contribution.  The ability to scale up the 
number of distribution and contribution channels is going to be increasingly 
important as D develops.
May 09 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 23:31, Joseph Rushton Wakeling a écrit :

 On a more practical level, the inability of 3rd parties to distribute
 DMD could have an effect in limiting points of access to the software,
 with corresponding effects on the possible channels of contribution. The
 ability to scale up the number of distribution and contribution channels
 is going to be increasingly important as D develops.


And even more practical : I can't bundle dmd with an IDE for D to 
provide an easy setup for a user. I can't create a repository where dmd 
sit in to make it easy t install on linux. This make it harder for 
beginner to get started with D.

I can't even fork dmd. And this is probably the most important one.

FOSS typically work in a dictatorship manner. This is ok, because the 
dictator HAVE TO do the right thing, or the project will fork and a new 
dictator will take the lead.

Having a non open source compiler as reference implementation is a major 
issue. Unless you are microsoft, google or some other huge company, you 
can't afford that.

Walter is arming his baby by trying to protect it.
May 09 2012
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 09/05/12 23:47, deadalnix wrote:

 And even more practical : I can't bundle dmd with an IDE for D to provide an
 easy setup for a user. I can't create a repository where dmd sit in to make it
 easy t install on linux. This make it harder for beginner to get started with
D.


Actually, "You can't bundle it with an IDE" was one of the exact examples I 
thought of making.


 Walter is arming his baby by trying to protect it.


I don't think this is Walter's intention as I believe he has worked quite hard 
to get that code open sourced.  AFAIK it's a constraint inherited from Digital 
Mars' past contractual obligations regarding that code.
May 09 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 23:47:57 deadalnix wrote:

 Le 09/05/2012 23:31, Joseph Rushton Wakeling a écrit :

 On a more practical level, the inability of 3rd parties to distribute
 DMD could have an effect in limiting points of access to the software,
 with corresponding effects on the possible channels of contribution. The
 ability to scale up the number of distribution and contribution channels
 is going to be increasingly important as D develops.


 
 And even more practical : I can't bundle dmd with an IDE for D to
 provide an easy setup for a user. I can't create a repository where dmd
 sit in to make it easy t install on linux. This make it harder for
 beginner to get started with D.
 
 I can't even fork dmd. And this is probably the most important one.
 
 FOSS typically work in a dictatorship manner. This is ok, because the
 dictator HAVE TO do the right thing, or the project will fork and a new
 dictator will take the lead.
 
 Having a non open source compiler as reference implementation is a major
 issue. Unless you are microsoft, google or some other huge company, you
 can't afford that.
 
 Walter is arming his baby by trying to protect it.


Umm. No. While Walter is the original creator of the backend, it was owned by 
the company that released it (Zortech) not him. Semantec bought Zortech, so 
they own the compiler. Digital Mars uses it with their permission (via 
licensing or leasing or whatever they did). So, Walter is bound by the license 
that Semantec uses for the backend.

http://en.wikipedia.org/wiki/Zortech
http://en.wikipedia.org/wiki/Digital_Mars

Walter can give redrisribution permissions if you ask (which he typically does 
quite freely), but I don't believe that he can give blanket permissions, and 
he definitely can't change the license. He's tried. As I understand it, if 
Walter could make the backend GPL, he would, but he can't.

- Jonathan M Davis
May 09 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 10/05/2012 00:22, Jonathan M Davis a écrit :

 On Wednesday, May 09, 2012 23:47:57 deadalnix wrote:

 Le 09/05/2012 23:31, Joseph Rushton Wakeling a écrit :

 On a more practical level, the inability of 3rd parties to distribute
 DMD could have an effect in limiting points of access to the software,
 with corresponding effects on the possible channels of contribution. The
 ability to scale up the number of distribution and contribution channels
 is going to be increasingly important as D develops.


 And even more practical : I can't bundle dmd with an IDE for D to
 provide an easy setup for a user. I can't create a repository where dmd
 sit in to make it easy t install on linux. This make it harder for
 beginner to get started with D.

 I can't even fork dmd. And this is probably the most important one.

 FOSS typically work in a dictatorship manner. This is ok, because the
 dictator HAVE TO do the right thing, or the project will fork and a new
 dictator will take the lead.

 Having a non open source compiler as reference implementation is a major
 issue. Unless you are microsoft, google or some other huge company, you
 can't afford that.

 Walter is arming his baby by trying to protect it.


 Umm. No. While Walter is the original creator of the backend, it was owned by
 the company that released it (Zortech) not him. Semantec bought Zortech, so
 they own the compiler. Digital Mars uses it with their permission (via
 licensing or leasing or whatever they did). So, Walter is bound by the license
 that Semantec uses for the backend.

 http://en.wikipedia.org/wiki/Zortech
 http://en.wikipedia.org/wiki/Digital_Mars

 Walter can give redrisribution permissions if you ask (which he typically does
 quite freely), but I don't believe that he can give blanket permissions, and
 he definitely can't change the license. He's tried. As I understand it, if
 Walter could make the backend GPL, he would, but he can't.

 - Jonathan M Davis


Understood. That is quite sad.
May 09 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/05/2012 22:00, Adam D. Ruppe a écrit :

 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.


I'm sorry but one would invest time in something he isn't even sure to 
be able to use himself.

Distribution freedom is really important.
May 09 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 May 2012 at 21:33:16 UTC, deadalnix wrote:

 I'm sorry but one would invest time in something he isn't even 
 sure to be able to use himself.


Of course you can use it yourself! That's personal use,
not distribution.


Now, I get the annoyance in not distributing it (without
permission) - it bugs me with the D-> JS fork too.

But it isn't /that/ big of a deal. It doesn't impact
the development model.
May 09 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:zhapcktjpldxzejorqor forum.dlang.org...

 Now, I get the annoyance in not distributing it (without
 permission) - it bugs me with the D-> JS fork too.


Huh?  The D -> JS fork has no need for the backend.  Just cut it out and 
distribute as you like!
May 12 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 May 2012 at 14:28:26 UTC, Daniel Murphy wrote:

 Huh?  The D -> JS fork has no need for the backend.  Just cut 
 it out and
 distribute as you like!


So far, I've found that easier said than done!

Perhaps if I really sat down and worked it it'd be better
though but it is just boring.
May 12 2012
prev sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:qlxeqfqyzlezwqerrkxn forum.dlang.org...

 On Wednesday, 9 May 2012 at 19:58:14 UTC, Michal 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.


Even that's not entirely true (and it does annoy me a little that it keeps 
getting repeated). The only thing it prohibits is distributing it yourself 
*without prior approval*. And considering that Walter's always been 
extremely reasonable about granting such requests (since the prior approval 
is only required because *his* hands are tied on that matter by...uhh...was 
it Borland?), it's really a non-issue.


 Doing a personal fork, modifying it, and doing a pull
 request or a patch back upstream happens in practice
 somewhat normally.
May 09 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 17:52:39 Nick Sabalausky wrote:

 (since the prior approval
 is only required because *his* hands are tied on that matter by...uhh...was
 it Borland?),


Semantec. They own the backend that dmd uses.

- Jonathan M Davis
May 09 2012
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
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
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 10, 2012 00:49:17 Joseph Rushton Wakeling wrote:

 On 10/05/12 00:41, Joseph Rushton Wakeling wrote:

 I do think, though, that it may be something that starts to bite as the
 community scales up in size.


 
 I'll add one more thing on this: you probably don't know whether or not
 you're missing out, as there's no real way you can measure the number of
 people who would like to engage with D but don't because of the licensing
 issues.
 
 There _might_ be a surprise waiting the day the announcement is made:
 "reference D compiler now fully open source".


But since that will never happen, it's a moot issue. It doesn't really matter 
if we would have had 10 times as many people contributing (which I very much 
doubt), Walter can't change the backend's license, so we're stuck with how 
things are. There's really no point in arguing about how it affects us (be it 
positively or negatively), since we can't do anything about it.

But gdc and ldc _do_ exist, so for the really picky people, there are fully 
FOSS options. And as the front-end stabilizes, which backend you use should 
matter less and less, so it should become less and less of an issue.

- Jonathan M Davis
May 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 09, 2012 at 06:53:37PM -0400, Jonathan M Davis wrote:

 On Thursday, May 10, 2012 00:49:17 Joseph Rushton Wakeling wrote:

 On 10/05/12 00:41, Joseph Rushton Wakeling wrote:

 I do think, though, that it may be something that starts to bite
 as the community scales up in size.


 
 I'll add one more thing on this: you probably don't know whether or
 not you're missing out, as there's no real way you can measure the
 number of people who would like to engage with D but don't because
 of the licensing issues.
 
 There _might_ be a surprise waiting the day the announcement is
 made: "reference D compiler now fully open source".


 
 But since that will never happen, it's a moot issue. It doesn't really
 matter if we would have had 10 times as many people contributing
 (which I very much doubt), Walter can't change the backend's license,
 so we're stuck with how things are. There's really no point in arguing
 about how it affects us (be it positively or negatively), since we
 can't do anything about it.


[...]

Dumb question: what prevents someone from rewriting dmd's backend with
new code that isn't entangled by the previous license?


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan
May 09 2012
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 00:53, Jonathan M Davis wrote:

 But since that will never happen, it's a moot issue. It doesn't really matter
 if we would have had 10 times as many people contributing (which I very much
 doubt), Walter can't change the backend's license, so we're stuck with how
 things are. There's really no point in arguing about how it affects us (be it
 positively or negatively), since we can't do anything about it.

 But gdc and ldc _do_ exist, so for the really picky people, there are fully
 FOSS options. And as the front-end stabilizes, which backend you use should
 matter less and less, so it should become less and less of an issue.


I don't understand why the project couldn't (or wouldn't) simply bless GDC or 
LDC as the reference implementation.  I do see why in the short term, as 
finalizing/stabilizing the front end, runtime and development library are much 
higher-priority goals, but in the longer term it seems like a viable
possibility.

It also seems beneficial to do so given that GDC and LDC offer much better 
possibilities for supporting architectures beyond x86/x86-64.
May 09 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-10 01:08, Joseph Rushton Wakeling wrote:


 I don't understand why the project couldn't (or wouldn't) simply bless
 GDC or LDC as the reference implementation. I do see why in the short
 term, as finalizing/stabilizing the front end, runtime and development
 library are much higher-priority goals, but in the longer term it seems
 like a viable possibility.

 It also seems beneficial to do so given that GDC and LDC offer much
 better possibilities for supporting architectures beyond x86/x86-64.


I'm not sure but I don't think Walter is allowed to work on other compilers.

-- 
/Jacob Carlborg
May 10 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 05/10/12 01:04, H. S. Teoh wrote:

 On Wed, May 09, 2012 at 06:53:37PM -0400, Jonathan M Davis wrote:

 On Thursday, May 10, 2012 00:49:17 Joseph Rushton Wakeling wrote:

 On 10/05/12 00:41, Joseph Rushton Wakeling wrote:

 I do think, though, that it may be something that starts to bite
 as the community scales up in size.


 I'll add one more thing on this: you probably don't know whether or
 not you're missing out, as there's no real way you can measure the
 number of people who would like to engage with D but don't because
 of the licensing issues.

 There _might_ be a surprise waiting the day the announcement is
 made: "reference D compiler now fully open source".


 But since that will never happen, it's a moot issue. It doesn't really
 matter if we would have had 10 times as many people contributing
 (which I very much doubt), Walter can't change the backend's license,
 so we're stuck with how things are. There's really no point in arguing
 about how it affects us (be it positively or negatively), since we
 can't do anything about it.


 [...]
 
 Dumb question: what prevents someone from rewriting dmd's backend with
 new code that isn't entangled by the previous license?


Something must, as otherwise there would ay least already be llvm and gcc
backends. Oh wait...

artur
May 09 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 16:04:14 H. S. Teoh wrote:

 Dumb question: what prevents someone from rewriting dmd's backend with
 new code that isn't entangled by the previous license?


It's a _ton_ of work for arguably little benefit. What we have for dmd works 
just fine, and if you want a fully open source backend, you can use gdc or ldc.

- Jonathan M Davis
May 09 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 09, 2012 at 07:16:22PM -0400, Jonathan M Davis wrote:

 On Wednesday, May 09, 2012 16:04:14 H. S. Teoh wrote:

 Dumb question: what prevents someone from rewriting dmd's backend
 with new code that isn't entangled by the previous license?


 
 It's a _ton_ of work for arguably little benefit. What we have for dmd
 works just fine, and if you want a fully open source backend, you can
 use gdc or ldc.


[...]

Right, so what's the reason behind not adopting gdc or ldc as the
reference compiler?


T

-- 
Не дорог подарок, дорога любовь.
May 09 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 May 2012 at 23:31:26 UTC, H. S. Teoh wrote:

 Right, so what's the reason behind not adopting gdc or ldc as 
 the reference compiler?


Have you actually used them? I've tried and never got
far.

dmd just works.
May 09 2012
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 01:33, Adam D. Ruppe wrote:

 Have you actually used them? I've tried and never got
 far.


Yes, but that's because right now they are playing perpetual catch-up with DMD. 
  With the frontend stabilized, it'll be a different situation.

GDC works extremely well for me in general, and also produces significantly 
faster executables than DMD.
May 09 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 May 2012 at 23:47:38 UTC, Joseph Rushton Wakeling 
wrote:

 GDC works extremely well for me in general, and also produces 
 significantly faster executables than DMD.


How did you install it? That's the stumbling block for me.
May 09 2012
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 9 May 2012 at 23:49:42 UTC, Adam D. Ruppe wrote:

 On Wednesday, 9 May 2012 at 23:47:38 UTC, Joseph Rushton 
 Wakeling wrote:

 GDC works extremely well for me in general, and also produces 
 significantly faster executables than DMD.


 How did you install it? That's the stumbling block for me.


Haha... getting GNU _anything_ working is always a stumbling 
block for me.

Either you have the 'right' version or you're blessed with 
incomprehensible errors.

/rant
May 09 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 01:49, Adam D. Ruppe wrote:

 How did you install it? That's the stumbling block for me.


In my case, the easy way: it's available as a package in Ubuntu. :-)

Ubuntu 12.04 has GDC 4.6.3 in its repositories, 11.10 had 4.6.1 if I remember 
correctly.

I haven't yet tried building it from source, but may do so at some point in the 
future.
May 09 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 10, 2012 at 01:59:27AM +0200, Joseph Rushton Wakeling wrote:

 On 10/05/12 01:49, Adam D. Ruppe wrote:

How did you install it? That's the stumbling block for me.


 
 In my case, the easy way: it's available as a package in Ubuntu. :-)


[...]

Yeah, I use Debian, and apt-get install gdc-4.6 does everything
necessary to setup gdc in working condition. Gotta love apt. :-)


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
May 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 10, 2012 at 01:33:39AM +0200, Adam D. Ruppe wrote:

 On Wednesday, 9 May 2012 at 23:31:26 UTC, H. S. Teoh wrote:

Right, so what's the reason behind not adopting gdc or ldc as the
reference compiler?


 
 Have you actually used them? I've tried and never got far.
 
 dmd just works.


I use gdc regularly without a hitch. The only catch is that it's always
a bit behind dmd, so it doesn't always work with the latest git
druntime/phobos. So for bleeding-edge D code I still have to resort to
dmd.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius
May 09 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 10, 2012 at 01:47:27AM +0200, Joseph Rushton Wakeling wrote:

 On 10/05/12 01:33, Adam D. Ruppe wrote:

Have you actually used them? I've tried and never got
far.


 
 Yes, but that's because right now they are playing perpetual
 catch-up with DMD.  With the frontend stabilized, it'll be a
 different situation.
 
 GDC works extremely well for me in general, and also produces
 significantly faster executables than DMD.


Yeah, gcc's backend has much more advanced optimizations that dmd.  I've
actually looked at the assembly code output for different D snippets,
and often find that gdc's output has just several instructions where dmd
would output half a page of instructions (or an entire function together
with the entire call/return sequence).

Plus the gcc backend automatically gives you access to a whole slew of
target architectures that dmd would never have the manpower to support.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps
well onto the problem space, which is also a mess, which we call
reality. Similarly, Perl was designed to be a mess, though in the
nicests of all possible ways. -- Larry Wall
May 09 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 09, 2012 16:32:34 H. S. Teoh wrote:

 On Wed, May 09, 2012 at 07:16:22PM -0400, Jonathan M Davis wrote:

 On Wednesday, May 09, 2012 16:04:14 H. S. Teoh wrote:

 Dumb question: what prevents someone from rewriting dmd's backend
 with new code that isn't entangled by the previous license?


 
 It's a _ton_ of work for arguably little benefit. What we have for dmd
 works just fine, and if you want a fully open source backend, you can
 use gdc or ldc.


 
 [...]
 
 Right, so what's the reason behind not adopting gdc or ldc as the
 reference compiler?


If nothing else, because Walter would be unable to work on it. He avoids 
looking at the source for any other compilers, because doing so could cause 
him legal issues when working on dmd/dmc's backend, which he does 
professionally. And given that Walter has worked on the backend for over 20 
years, I can't imagine that he's going to be all that excited at the prospect 
of throwing it away in favor of another one.

Once the front-end has stabilized (and it's getting there), it should become a 
non-issue, because then even if gdc and ldc are a version or two behind, it 
won't affect anywhere near as much (it will also likely become easier at that 
point for the gdc and ldc devs to keep them up-to-date).

- Jonathan M Davis
May 09 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 10, 2012 01:08:34 Joseph Rushton Wakeling wrote:

 On 10/05/12 00:53, Jonathan M Davis wrote:

 But since that will never happen, it's a moot issue. It doesn't really
 matter if we would have had 10 times as many people contributing (which I
 very much doubt), Walter can't change the backend's license, so we're
 stuck with how things are. There's really no point in arguing about how
 it affects us (be it positively or negatively), since we can't do
 anything about it.
 
 But gdc and ldc _do_ exist, so for the really picky people, there are
 fully
 FOSS options. And as the front-end stabilizes, which backend you use
 should
 matter less and less, so it should become less and less of an issue.


 
 I don't understand why the project couldn't (or wouldn't) simply bless GDC
 or LDC as the reference implementation. I do see why in the short term, as
 finalizing/stabilizing the front end, runtime and development library are
 much higher-priority goals, but in the longer term it seems like a viable
 possibility.
 
 It also seems beneficial to do so given that GDC and LDC offer much better
 possibilities for supporting architectures beyond x86/x86-64.


Walter works on dmd's backend for a living. He's been working on it for over 
20 years. I don't think that he's going to be very interested in using another 
backend.

Also, he _can't_ use another backend (unless he creates a new one from 
scratch), because looking the code for another backend could cause legal 
issues for him when he works on dmd/dmc's backend for his actual job.

There may be other major reasons as well, but those alone would make it so 
that Walter isn't going to want to switch. Certainly, if it were something 
that Walter really thought was a good idea, I expect that he would have done 
so by now.

- Jonathan M Davis
May 09 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 03:14, Jonathan M Davis wrote:

 If nothing else, because Walter would be unable to work on it. He avoids
 looking at the source for any other compilers, because doing so could cause
 him legal issues when working on dmd/dmc's backend, which he does
 professionally. And given that Walter has worked on the backend for over 20
 years, I can't imagine that he's going to be all that excited at the prospect
 of throwing it away in favor of another one.


Is that an issue for LLVM, which is BSD-licensed?  I will understand if the 
answer is, "I don't care, I don't even want to risk it."


 Once the front-end has stabilized (and it's getting there), it should become a
 non-issue, because then even if gdc and ldc are a version or two behind, it
 won't affect anywhere near as much (it will also likely become easier at that
 point for the gdc and ldc devs to keep them up-to-date).


Yes, I agree.  That's why I suggested as an alternative trying to synchronize 
releases of DMD, GDC and LDC so that they are always feature-equivalent, and 
endorsing all 3 as official implementations of the reference standard.
May 10 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 10, 2012 10:16:10 Joseph Rushton Wakeling wrote:

 On 10/05/12 03:14, Jonathan M Davis wrote:

 If nothing else, because Walter would be unable to work on it. He avoids
 looking at the source for any other compilers, because doing so could
 cause
 him legal issues when working on dmd/dmc's backend, which he does
 professionally. And given that Walter has worked on the backend for over
 20
 years, I can't imagine that he's going to be all that excited at the
 prospect of throwing it away in favor of another one.


 
 Is that an issue for LLVM, which is BSD-licensed? I will understand if the
 answer is, "I don't care, I don't even want to risk it."


You'll have to talk to Walter if you want to know what exactly he is willing 
and isn't willing to do or what he can and can't do.


 Once the front-end has stabilized (and it's getting there), it should
 become a non-issue, because then even if gdc and ldc are a version or two
 behind, it won't affect anywhere near as much (it will also likely become
 easier at that point for the gdc and ldc devs to keep them up-to-date).


 
 Yes, I agree. That's why I suggested as an alternative trying to
 synchronize releases of DMD, GDC and LDC so that they are always
 feature-equivalent, and endorsing all 3 as official implementations of the
 reference standard.


They all use the same front-end. I don't think that we really need to go any 
further than that. We have enough real, implementation stuff to worry about 
without increasing our workload like that. If anything, gdc and ldc just need 
more manpower. Then they'll always be caught up quickly after a dmd release. 
As the front-end matures, it'll take less effort to update to a new version of 
it anyway.

But if someone is going to consider dmd's backend's license to be an issue, 
they don't know enough to understand the situation properly, and I wouldn't 
expect anything with gdc and ldc to change that, since they'd _still_ have to 
know more to understand the situation properly. The fact that gdc and ldc 
_exist_ should solve the problem already, but we still get FUD. We'd still be 
getting FUD even if dmd's backend _were_ changed to the GPL, simply because it 
wasn't before. The situation can't really be fixed, so I don't see much point 
in trying to spend a lot of time and effort trying to fix it. We have a
compiler 
that works quite well and is not closed source, much as that gets spread 
around, and we have _two_ _fully_ open source compilers for those who care. If 
that doesn't solve the problem, I don't think anything will short of making 
dmd's backend fully open source (which we can't do and wouldn't completely 
eliminate the FUD even if we did).

- Jonathan M Davis
May 10 2012
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/05/12 21:01, Jonathan M Davis wrote:

 On Thursday, May 10, 2012 10:16:10 Joseph Rushton Wakeling wrote:

 Is that an issue for LLVM, which is BSD-licensed? I will understand if the
 answer is, "I don't care, I don't even want to risk it."


 You'll have to talk to Walter if you want to know what exactly he is willing
 and isn't willing to do or what he can and can't do.


Sure.  I was just not sure if this particular suggestion had been raised and 
answered by Walter before.


 But if someone is going to consider dmd's backend's license to be an issue,
 they don't know enough to understand the situation properly, and I wouldn't
 expect anything with gdc and ldc to change that, since they'd _still_ have to
 know more to understand the situation properly. The fact that gdc and ldc
 _exist_ should solve the problem already, but we still get FUD. We'd still be
 getting FUD even if dmd's backend _were_ changed to the GPL, simply because it
 wasn't before.


The difference is that with an OS-licensed backend, you can counter FUD with
one 
line -- "Here's the licence".  Without it, you have to go into the extended 
discussion we've just had, with so many opportunities for misunderstanding and 
confusion.  And yes, D would probably continue to suffer some FUD in the short 
term even with a backend licence change, but not in the long term -- look at
the 
history of Qt for a comparison.

GDC and LDC solve _one_ problem -- the problem of developing D programs using 
purely open source tools.  But they leave remaining the problem of contributing 
to the core of D using purely open source.

That's not a problem that is urgent to address right now but it is a problem 
that probably needs to be addressed at some point.


 The situation can't really be fixed, so I don't see much point
 in trying to spend a lot of time and effort trying to fix it.


Not for now, certainly.  I do think, though, that it's worth having the detail 
of the issues involved laid out and understood.  That allows for some longer 
term planning and thinking around possible solutions.
May 11 2012