May 10, 2012
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
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
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
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

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

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


May 10, 2012
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
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
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
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
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
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 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

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), then 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 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

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

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

-Steve