www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Top 5

reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



I hope it's not wrong to show this link here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168

Bye,
bearophile
Oct 08 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 I hope it's not wrong to show this link here:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168



To those more directly involved: Would I be wrong saying the
Phobos/Tango split never would have happened if D had a truly open
development process?  I know Sean wanting to experiment with different
GCs was one reason for it, but if Sean had been able to get access to
the official D runtime to begin with, I suspect he would have designed
his extensions in a way that was more compatible with the existing
code.  Let me know if I'm way off base there.

--bb
Oct 08 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?



Possibly.  Ares (a precursor to Tango) was basically created as an 
attempt to try and coordinate community effort for Phobos submissions. 
The goals of the project changed over time, but that was the basic 
inspiration.


Sean
Oct 08 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Sean Kelly wrote:

 Bill Baxter wrote:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> 
 wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=77168 



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?



 Possibly.  Ares (a precursor to Tango) was basically created as an 
 attempt to try and coordinate community effort for Phobos submissions. 
 The goals of the project changed over time, but that was the basic 
 inspiration.



I should add, however, that I'm not sure whether the resulting druntime 
would have existed if Phobos were more open.  I don't think I would have 
messed with things quite so aggressively if I had actual users and 
compatibility to worry about ;-)  So things may have worked out for the 
best anyway.


Sean
Oct 08 2008
prev sibling parent reply Aarti_pl <aarti interia.pl> writes:
Bill Baxter pisze:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?  I know Sean wanting to experiment with different
 GCs was one reason for it, but if Sean had been able to get access to
 the official D runtime to begin with, I suspect he would have designed
 his extensions in a way that was more compatible with the existing
 code.  Let me know if I'm way off base there.
 
 --bb



I think the same.

And similar think can happen in nearest future also. LDC (was LLVMDC) is 
approaching release quality very fast. Who will use DMD then, while you 
will have better compiler with more bugs fixed than in DMD, better 
linker and optimizer and more open people working currently on LDC?

This is for D core team to rethink how to cooperate with LDC team, so 
that community can get best from resources we have. Maintaining obsolete 
back-end by Walter will be loose-loose situation for everyone.

It might sound like contradiction but it seems that more openness gives 
more control finally.

BR
Marcin Kuszczak
(aarti_pl)
Oct 09 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Aarti_pl wrote:

 Bill Baxter pisze:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> 
 wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=77168 



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?  I know Sean wanting to experiment with different
 GCs was one reason for it, but if Sean had been able to get access to
 the official D runtime to begin with, I suspect he would have designed
 his extensions in a way that was more compatible with the existing
 code.  Let me know if I'm way off base there.

 --bb



 I think the same.
 
 And similar think can happen in nearest future also. LDC (was LLVMDC) is 
 approaching release quality very fast. Who will use DMD then, while you 
 will have better compiler with more bugs fixed than in DMD, better 
 linker and optimizer and more open people working currently on LDC?
 
 This is for D core team to rethink how to cooperate with LDC team, so 
 that community can get best from resources we have. Maintaining obsolete 
 back-end by Walter will be loose-loose situation for everyone.
 
 It might sound like contradiction but it seems that more openness gives 
 more control finally.
 
 BR
 Marcin Kuszczak
 (aarti_pl)



I hope so, but realistically LDC only works on x86 Linux and there's a 
lot of work getting it to work on other platforms (much of this work on 
LLVM itself instead of just LDC).
Oct 09 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robert Fraser wrote:

 Aarti_pl wrote:

 Bill Baxter pisze:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile 
 <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=77168 



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?  I know Sean wanting to experiment with different
 GCs was one reason for it, but if Sean had been able to get access to
 the official D runtime to begin with, I suspect he would have designed
 his extensions in a way that was more compatible with the existing
 code.  Let me know if I'm way off base there.

 --bb



 I think the same.

 And similar think can happen in nearest future also. LDC (was LLVMDC) 
 is approaching release quality very fast. Who will use DMD then, while 
 you will have better compiler with more bugs fixed than in DMD, better 
 linker and optimizer and more open people working currently on LDC?

 This is for D core team to rethink how to cooperate with LDC team, so 
 that community can get best from resources we have. Maintaining 
 obsolete back-end by Walter will be loose-loose situation for everyone.

 It might sound like contradiction but it seems that more openness 
 gives more control finally.

 BR
 Marcin Kuszczak
 (aarti_pl)



 I hope so, but realistically LDC only works on x86 Linux and there's a 
 lot of work getting it to work on other platforms (much of this work on 
 LLVM itself instead of just LDC).



What do you mean? Are there any significant issues with LLVM itself on 
the Windows platform?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2008
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bruno Medeiros wrote:

 Robert Fraser wrote:

 I hope so, but realistically LDC only works on x86 Linux and there's a 
 lot of work getting it to work on other platforms (much of this work 
 on LLVM itself instead of just LDC).



 What do you mean? Are there any significant issues with LLVM itself on 
 the Windows platform?



According to a recent post to their mailing list, the most significant 
problem for LLVM on Windows is that most of their developers work on 
Linux machines or Macs...
Oct 15 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Related to the LDC (LLVMDC), at the moment it's for D1, but when you want to
adapt LDC to D2, this may be used to implement its closures. This stuff will be
present in LLVM 2.4 that will be out in about two weeks:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html


This feature is similar to nested functions and closures, but does not require
stack trampolines (with most ABIs) and supports returning closures from
functions that define them. Note that actually using Blocks requires a small
runtime that is not included with llvm-gcc.<



Bye,
bearophile
Oct 15 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
bearophile wrote:

 Related to the LDC (LLVMDC), at the moment it's for D1, but when you want to
adapt LDC to D2, this may be used to implement its closures. This stuff will be
present in LLVM 2.4 that will be out in about two weeks:
 
 http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html
 

 This feature is similar to nested functions and closures, but does not require
stack trampolines (with most ABIs) and supports returning closures from
functions that define them. Note that actually using Blocks requires a small
runtime that is not included with llvm-gcc.<



 Bye,
 bearophile



 From what I read 'Blocks' is not part of LLVM, just implemented on top of it.
We'll probably 
do our own implementation of closures when we get to D2 (whenever that may be).

We already do things quite differently for D1's nested functions (compared to
DMD).
Oct 16 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Tomas Lindquist Olsen:


 We'll probably do our own implementation of closures when we get to D2
(whenever that may be).<



I see.



 We already do things quite differently for D1's nested functions (compared to
DMD).<



May I ask what's the difference? I am curious.

Bye and thank you,
bearophile
Oct 16 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruno Medeiros Wrote:

 Robert Fraser wrote:

 I hope so, but realistically LDC only works on x86 Linux and there's a 
 lot of work getting it to work on other platforms (much of this work on 
 LLVM itself instead of just LDC).



 What do you mean? Are there any significant issues with LLVM itself on 
 the Windows platform?



Namely structured exception handling.

I'd actually like to see a Phoenix compiler on Windows. Many Windows developers
use MSVC, and being able to statically link to MSVC-generated code will help in
migration of existing codebases to D (DMD uses the same object format as MS,
but it won't link). It would also open the door to CLI support (shall we call
it D.NET or D#?).
Oct 15 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Robert Fraser wrote:

 Bruno Medeiros Wrote:

 Robert Fraser wrote:

 I hope so, but realistically LDC only works on x86 Linux and there's a 
 lot of work getting it to work on other platforms (much of this work on 
 LLVM itself instead of just LDC).



 the Windows platform?



 Namely structured exception handling.
 
 I'd actually like to see a Phoenix compiler on Windows. Many Windows
developers use MSVC, and being able to statically link to MSVC-generated code
will help in migration of existing codebases to D (DMD uses the same object
format as MS, but it won't link). It would also open the door to CLI support
(shall we call it D.NET or D#?).



In the end LLVM could get us all that. There's already work getting LLVM do
work with MSVC and 
there is actually a MSIL backend for LLVM as well.
Oct 16 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Tomas Lindquist Olsen wrote:

 Robert Fraser wrote:

 Bruno Medeiros Wrote:

 Robert Fraser wrote:

 I hope so, but realistically LDC only works on x86 Linux and there's 
 a lot of work getting it to work on other platforms (much of this 
 work on LLVM itself instead of just LDC).



 on the Windows platform?



 Namely structured exception handling.

 I'd actually like to see a Phoenix compiler on Windows. Many Windows 
 developers use MSVC, and being able to statically link to 
 MSVC-generated code will help in migration of existing codebases to D 
 (DMD uses the same object format as MS, but it won't link). It would 
 also open the door to CLI support (shall we call it D.NET or D#?).



 In the end LLVM could get us all that. There's already work getting LLVM 
 do work with MSVC and there is actually a MSIL backend for LLVM as well.



True, but considering the calisthenics it takes to build LLVM *itself* 
under VS, I don't know how they'll ever get LLVM-generated code linking 
with MS-generated code.

That being said, LLVMDC for Windows is the low-lying fruit here; an 
entire Phoenix-based compiler would be a lot more work.
Oct 16 2008
prev sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 8, 2008 at 10:38 PM, Bill Baxter <wbaxter gmail.com> wrote:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 I hope it's not wrong to show this link here:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168



 To those more directly involved: Would I be wrong saying the
 Phobos/Tango split never would have happened if D had a truly open
 development process?  I know Sean wanting to experiment with different
 GCs was one reason for it, but if Sean had been able to get access to
 the official D runtime to begin with, I suspect he would have designed
 his extensions in a way that was more compatible with the existing
 code.  Let me know if I'm way off base there.

 --bb



There probably never would have been a split.  If the community
developed (or had a major hand in developing) the standard library,
there would have been no reason to create an alternate.
Oct 08 2008
parent Don <nospam nospam.com.au> writes:
Jarrett Billingsley wrote:

 On Wed, Oct 8, 2008 at 10:38 PM, Bill Baxter <wbaxter gmail.com> wrote:

 On Thu, Oct 9, 2008 at 11:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 But as a meta-wish I  heartily agree with whoever it was who said the
 development process needs to be made more open.



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77168



 Phobos/Tango split never would have happened if D had a truly open
 development process?  I know Sean wanting to experiment with different
 GCs was one reason for it, but if Sean had been able to get access to
 the official D runtime to begin with, I suspect he would have designed
 his extensions in a way that was more compatible with the existing
 code.  Let me know if I'm way off base there.

 --bb



 There probably never would have been a split.  If the community
 developed (or had a major hand in developing) the standard library,
 there would have been no reason to create an alternate.



The community _was_ playing the major part in developing Phobos. At 
least in the time I've been involved with D. The problem was, it was 
incredibly painful to get stuff into it. (Purely for technical reasons, 
not because of reluctance on Walter's part). So Phobos was almost 
completely stagnant.

If Phobos had been on dsource a year or two earlier, the split might not 
have happened.
Oct 09 2008