www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tango vs Phobos

reply Graham St Jack <graham.stjack internode.on.net> writes:
Quite a while ago there was talk of rearranging Tango and Phobos so that 
they share the same runtime, allowing BOTH libraries to be available in 
the same compiler installation.

It looks to me as though D2 is stabilising, so now seems to be a good 
time to rationalise the two libraries in D2. I use D2 because I want the 
const stuff (and some other nice things too), but that locks me out of 
Tango and all the other libraries that use it, most notably GUI libraries.

Is anything happening on this front?
Aug 08 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Graham St Jack" <graham.stjack internode.on.net> wrote in message 
news:g7j16v$tfs$1 digitalmars.com...
 Quite a while ago there was talk of rearranging Tango and Phobos so that
 they share the same runtime, allowing BOTH libraries to be available in
 the same compiler installation.

 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want the
 const stuff (and some other nice things too), but that locks me out of
 Tango and all the other libraries that use it, most notably GUI libraries.

 Is anything happening on this front?

Well D2 forked around the same time as the D conference last year, at which that conclusion was reached, and since then W has made very little progress on merging the Phobos and Tango runtime libraries, instead focusing on new D2 features. *shrug*
Aug 08 2008
next sibling parent reply Graham St Jack <graham.stjack internode.on.net> writes:
On Sat, 09 Aug 2008 00:32:38 -0400, Jarrett Billingsley wrote:

 "Graham St Jack" <graham.stjack internode.on.net> wrote in message
 news:g7j16v$tfs$1 digitalmars.com...
 Quite a while ago there was talk of rearranging Tango and Phobos so
 that they share the same runtime, allowing BOTH libraries to be
 available in the same compiler installation.

 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want
 the const stuff (and some other nice things too), but that locks me out
 of Tango and all the other libraries that use it, most notably GUI
 libraries.

 Is anything happening on this front?

Well D2 forked around the same time as the D conference last year, at which that conclusion was reached, and since then W has made very little progress on merging the Phobos and Tango runtime libraries, instead focusing on new D2 features. *shrug*

Ok - well, I hope that will change soon.
Aug 08 2008
next sibling parent downs <default_357-line yahoo.de> writes:
Graham St Jack wrote:
 On Sat, 09 Aug 2008 00:32:38 -0400, Jarrett Billingsley wrote:
 
 "Graham St Jack" <graham.stjack internode.on.net> wrote in message
 news:g7j16v$tfs$1 digitalmars.com...
 Quite a while ago there was talk of rearranging Tango and Phobos so
 that they share the same runtime, allowing BOTH libraries to be
 available in the same compiler installation.

 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want
 the const stuff (and some other nice things too), but that locks me out
 of Tango and all the other libraries that use it, most notably GUI
 libraries.

 Is anything happening on this front?

which that conclusion was reached, and since then W has made very little progress on merging the Phobos and Tango runtime libraries, instead focusing on new D2 features. *shrug*

Ok - well, I hope that will change soon.

I think we all share that sentiment.
Aug 08 2008
prev sibling parent reply Auria <auria.mg gmail.com> writes:
Bill Baxter Wrote:

 On Sat, Aug 9, 2008 at 1:54 PM, Graham St Jack
 <graham.stjack internode.on.net> wrote:
 On Sat, 09 Aug 2008 00:32:38 -0400, Jarrett Billingsley wrote:

 "Graham St Jack" <graham.stjack internode.on.net> wrote in message
 news:g7j16v$tfs$1 digitalmars.com...
 Quite a while ago there was talk of rearranging Tango and Phobos so
 that they share the same runtime, allowing BOTH libraries to be
 available in the same compiler installation.

 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want
 the const stuff (and some other nice things too), but that locks me out
 of Tango and all the other libraries that use it, most notably GUI
 libraries.

 Is anything happening on this front?

Well D2 forked around the same time as the D conference last year, at which that conclusion was reached, and since then W has made very little progress on merging the Phobos and Tango runtime libraries, instead focusing on new D2 features. *shrug*

Ok - well, I hope that will change soon.

Doesn't sound like it will, now with "SafeD" and the "shared" variable ideas apparently on the to-do list. There's always something big, always just beyond the horizon. --bb

Yes, and even if i know this has been discussed to death, i'll allow myself to add i really dislike the direction D is taking. D's homepage states it is driven by practical experience and not academical feats. Hasn't a solid standard library been shown over time to be absolutely necessary for any language to become popular and highly usable? It seems like D is taking the direction of adding lots of sugar features, and misses basic practical experience stuff. All that sugar is totally useless if D doesn't even have a standard library upon which everything can be built
Aug 09 2008
parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
There is a stable language, it's called D1.

D2 should not be preempted by standard libraries, except experimental ones, 
built to assist the language design, so it is known to be sound. It is great 
to have two experts like Andrei and Walter work in tandem in a feedback 
loop. I'm also enthusiastic about the "leave no issue behind" mantra - 
within limits of course. It's sure to make D2 more coherent, dispite it's 
plethora of features.

It looks to me as if there are new libraries being built side-by-side with 
D2. At least foundational ones. It is hard to build higher-level ones when 
D2 is not stable; wasted work, one might say.

Also, I'm not sure what "misses basic practical experience stuff" means in 
the context of Andrei and Walter.

My newb impression at least :)

Bent

 Yes, and even if i know this has been discussed to death, i'll allow 
 myself to add i really dislike the direction D is taking. D's homepage 
 states it is driven by practical experience and not academical feats. 
 Hasn't a solid standard library been shown over time to be absolutely 
 necessary for any language to become popular and highly usable? It seems 
 like D is taking the direction of adding lots of sugar features, and 
 misses basic practical experience stuff. All that sugar is totally useless 
 if D doesn't even have a standard library upon which everything can be 
 built 

Aug 23 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Aug 9, 2008 at 1:54 PM, Graham St Jack
<graham.stjack internode.on.net> wrote:
 On Sat, 09 Aug 2008 00:32:38 -0400, Jarrett Billingsley wrote:

 "Graham St Jack" <graham.stjack internode.on.net> wrote in message
 news:g7j16v$tfs$1 digitalmars.com...
 Quite a while ago there was talk of rearranging Tango and Phobos so
 that they share the same runtime, allowing BOTH libraries to be
 available in the same compiler installation.

 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want
 the const stuff (and some other nice things too), but that locks me out
 of Tango and all the other libraries that use it, most notably GUI
 libraries.

 Is anything happening on this front?

Well D2 forked around the same time as the D conference last year, at which that conclusion was reached, and since then W has made very little progress on merging the Phobos and Tango runtime libraries, instead focusing on new D2 features. *shrug*

Ok - well, I hope that will change soon.

Doesn't sound like it will, now with "SafeD" and the "shared" variable ideas apparently on the to-do list. There's always something big, always just beyond the horizon. --bb
Aug 08 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Graham St Jack (graham.stjack internode.on.net)'s article
 Quite a while ago there was talk of rearranging Tango and Phobos so that
 they share the same runtime, allowing BOTH libraries to be available in
 the same compiler installation.

This has been the case for ages via the Tango / Tangobos bundled release.
 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want the
 const stuff (and some other nice things too), but that locks me out of
 Tango and all the other libraries that use it, most notably GUI libraries.
 Is anything happening on this front?

I can update the Tango runtime once I find the time, but some of the coding approaches in the Tango user code aren't entirely compatible with D 2.0. This was the original inspiration for the "scoped const" proposal. In short, it wouldn't be unreasonable to expect the Tango runtime to support D 2.0, but my understanding is that making the user code support D 2.0 would require a redesign in some cases, which is unlikely to occur. Sean
Aug 09 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:

 == Quote from Graham St Jack (graham.stjack internode.on.net)'s article
 Quite a while ago there was talk of rearranging Tango and Phobos so that
 they share the same runtime, allowing BOTH libraries to be available in
 the same compiler installation.

This has been the case for ages via the Tango / Tangobos bundled release.
 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want the
 const stuff (and some other nice things too), but that locks me out of
 Tango and all the other libraries that use it, most notably GUI
 libraries. Is anything happening on this front?

I can update the Tango runtime once I find the time, but some of the coding approaches in the Tango user code aren't entirely compatible with D 2.0. This was the original inspiration for the "scoped const" proposal. In short, it wouldn't be unreasonable to expect the Tango runtime to support D 2.0, but my understanding is that making the user code support D 2.0 would require a redesign in some cases, which is unlikely to occur.

There is a bugzilla entry (or two) that hinders porting Tango as it is. One issue was fixed with the latest release (2.018). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 09 2008
prev sibling next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Sean

So what is the plan to transition Tango to D2.0 ?

Is the Tango team waiting for const to be removed from D2.0, or will 
Tango continue to use D1.0 forever, or is the team waiting to see the 
final form of D2.0 before deciding what to do ?

Nick B



Sean Kelly wrote:
 == Quote from Graham St Jack (graham.stjack internode.on.net)'s article
 Quite a while ago there was talk of rearranging Tango and Phobos so that
 they share the same runtime, allowing BOTH libraries to be available in
 the same compiler installation.

This has been the case for ages via the Tango / Tangobos bundled release.
 It looks to me as though D2 is stabilising, so now seems to be a good
 time to rationalise the two libraries in D2. I use D2 because I want the
 const stuff (and some other nice things too), but that locks me out of
 Tango and all the other libraries that use it, most notably GUI libraries.
 Is anything happening on this front?

I can update the Tango runtime once I find the time, but some of the coding approaches in the Tango user code aren't entirely compatible with D 2.0. This was the original inspiration for the "scoped const" proposal. In short, it wouldn't be unreasonable to expect the Tango runtime to support D 2.0, but my understanding is that making the user code support D 2.0 would require a redesign in some cases, which is unlikely to occur. Sean

Aug 10 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Nick B wrote:

 Sean
 
 So what is the plan to transition Tango to D2.0 ?
 
 Is the Tango team waiting for const to be removed from D2.0, or will
 Tango continue to use D1.0 forever, or is the team waiting to see the
 final form of D2.0 before deciding what to do ?

We don't expect const to be removed :) As it is, this must be resolved before it is possible to properly port Tango: http://d.puremagic.com/issues/show_bug.cgi?id=2267 1644 was fixed now, but is in our opinion the lesser solution to the problem - we'd much rather have 1961. 2204 is still open I think. Also as long as closures are allocated on stack, that is likely to be rather detrimental to the performance. Once we have a resolution on that, work on the Tango D 2.0 branch will probably continue, and this branch will be available to all who need it. If possible, an official release may happen shortly after the time Walter calls D 2.0 to be stable. One other concern is that it is almost impossible to have code that is both D1 and D2 compatible, something which mean the mantainance of two branches, a potentially daunting task - it would be good if the "syntactical correctness" restriction on versioned out blocks could be removed for at least D1/D2 identifiers. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 10 2008
next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Lars

Thanks for the response.  Its good to know that the Tango team is 
planning to transition to D2.0, even if you still have some major issues 
to work through, and you have to wait until Walter fixes these critical 
bugs.

cheers

Nick B


Lars Ivar Igesund wrote:
 
 We don't expect const to be removed :) As it is, this must be resolved
 before it is possible to properly port Tango:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=2267
 
 1644 was fixed now, but is in our opinion the lesser solution to the
 problem - we'd much rather have 1961.
 
 2204 is still open I think.
 
 Also as long as closures are allocated on stack, that is likely to be rather
 detrimental to the performance.
 
 Once we have a resolution on that, work on the Tango D 2.0 branch will
 probably continue, and this branch will be available to all who need it. If
 possible, an official release may happen shortly after the time Walter
 calls D 2.0 to be stable.
 
 One other concern is that it is almost impossible to have code that is both
 D1 and D2 compatible, something which mean the mantainance of two branches,
 a potentially daunting task - it would be good if the "syntactical
 correctness" restriction on versioned out blocks could be removed for at
 least D1/D2 identifiers.
 

Aug 10 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick B wrote:
 Thanks for the response.  Its good to know that the Tango team is 
 planning to transition to D2.0, even if you still have some major issues 
 to work through, and you have to wait until Walter fixes these critical 
 bugs.

They're already fixed in the latest update.
Aug 13 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:g7mboq$qcl$1 digitalmars.com...

 Also as long as closures are allocated on stack, that is likely to be 
 rather
 detrimental to the performance.

Heap. That is another major blocker for me besides const. Most of my code uses nested functions that are never supposed to be closures, and this "feature" would cause it all to unnecessarily allocate memory.
Aug 10 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Jarrett Billingsley schrieb:
 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
 news:g7mboq$qcl$1 digitalmars.com...
 
 Also as long as closures are allocated on stack, that is likely to be 
 rather
 detrimental to the performance.

Heap. That is another major blocker for me besides const. Most of my code uses nested functions that are never supposed to be closures, and this "feature" would cause it all to unnecessarily allocate memory.

i second that. It is an closure solution which was implemented too easy, imho. 1.) it breaks the semantic of an existing syntax. So existing code can be broken without any warning. (change in runtime behaviour) 2.) there is still no alternative syntax to get the old behaviour 3.) the closures are not really closures. E.g. const variables can change value. (Bug 2043) This is definately a blocker to switch from D1 to D2.
Aug 10 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Frank Benoit wrote:
 Jarrett Billingsley schrieb:
 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
 news:g7mboq$qcl$1 digitalmars.com...

 Also as long as closures are allocated on stack, that is likely to be 
 rather
 detrimental to the performance.

Heap. That is another major blocker for me besides const. Most of my code uses nested functions that are never supposed to be closures, and this "feature" would cause it all to unnecessarily allocate memory.

i second that. It is an closure solution which was implemented too easy, imho. 1.) it breaks the semantic of an existing syntax. So existing code can be broken without any warning. (change in runtime behaviour)

Yup. Much like the change in meaning of "const," which I've admittedly complained about perhaps overmuch.
 2.) there is still no alternative syntax to get the old behaviour

I would prefer that the old behavior the the default and that "new &fn" or something similar would be used for full closures.
 3.) the closures are not really closures. E.g. const variables can 
 change value. (Bug 2043)

This one, at least, is clearly a bug. Sean
Aug 11 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn" 
 or something similar would be used for full closures.

We have already discussed why this is negative, when practically possible in D the default has to be the "safer" version (what "safer" is can be debated). Bye, bearophile
Aug 11 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn"
 or something similar would be used for full closures.


It's just a matter of opinion, I suppose. As D is a systems language, I don't agree with many arguments about safety when that safety conflicts with my ability to control what the language is doing behind the scenes. Portability between versions is also an issue--code that is correctly designed for D 1.0 may be unusable on D 2.0 because the default behavior for certain language features is different, although the syntax is still completely legal. Also, there isn't any way to easily grep for the use of delegates so finding such trouble spots requires a manual code review. Because one of Tango's core design goals was to have no hidden allocations, this behavior is a major concern for me because it forces me to choose between elegant algorithm design (which works fine in D 1.0) and a design that's portable between language versions in a way I find acceptable. I think if/when Tango is ever released for D 2.0 necessity may dictate that it be an unsupported release for reasons such as this. Sean
Aug 11 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 It's just a matter of opinion, I suppose.  As D is a systems language, I don't
 agree with many arguments about safety when that safety conflicts with my
 ability to control what the language is doing behind the scenes.

I agree that: - a system language has to be efficient; - there must be a short, readable and nice way to disable heap allocation of closures (that I think has to happen by default); - that sometimes safety has to be put aside (that's why I have said "practically possible": if a safe feature slows down code too much it's not much fit for a system language, especially when compiling in release mode). - I'm using D instead of Python because sometimes I need a modern language that runs my programs faster (this isn't a system purpose). Despite that, there are tons of situations where a "fast language" can help avoid bugs with little or no performance penalty (and adding a statement to disable the heap allocation of closures leads to no performance penalty). Examples of other possible improvements: foreach (i, x in array) instead of: foreach (i, x; array) (But people here have explained me that despite this being better for the programmer it's worse for the compiler, making it more complex etc, and in the end a worse compiler is bad for the programmer too). Or a switch() statement with a semantic safer than then C switch, or various other things that help you decrease bug count and on average produce a correctly running code in less time :-)
 Portability between versions is also an issue--code that is correctly designed
for D 1.0 may be unusable on D 2.0 because the default behavior for certain
language features is different, although the syntax is still completely legal.<

I have written a library that despite being surely tiny compared to Tango, is currently already 817 KB of code, with no redundancy inside, and it's written for D 1.x, so I understand your pain of porting things to D 2.x. Despite this, D is a young language still, and it's developing quickly still, so it's too much early now to impose too many backward constraints... D 1.x may die and be forgotten, and maybe D 2.x too (Walter already says that AST macros are for D 3.x) so every current big lib for D will probably need one or two major rewrites. In 5 years we may have CPUs with several cores, that the currently mostly-sequential code used in my libs and Tango will be partially obsolete, that may require large changes in the libs and maybe in the language too... Bye, bearophile
Aug 11 2008
prev sibling next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Sean Kelly wrote:
 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn"
 or something similar would be used for full closures.


It's just a matter of opinion, I suppose. As D is a systems language, I don't agree with many arguments about safety when that safety conflicts with my ability to control what the language is doing behind the scenes. Portability between versions is also an issue--code that is correctly designed for D 1.0 may be unusable on D 2.0 because the default behavior for certain language features is different, although the syntax is still completely legal. Also, there isn't any way to easily grep for the use of delegates so finding such trouble spots requires a manual code review. Because one of Tango's core design goals was to have no hidden allocations, this behavior is a major concern for me because it forces me to choose between elegant algorithm design (which works fine in D 1.0) and a design that's portable between language versions in a way I find acceptable. I think if/when Tango is ever released for D 2.0 necessity may dictate that it be an unsupported release for reasons such as this. Sean

Sean Can you explain what you mean by a "unsupported release" ? Do you mean that all bugs will not fixed or only a certain sub-set of bugs ? Nick B
Aug 12 2008
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Nick B wrote:
  > Can you explain what you mean by a "unsupported release" ?
 
 Do you mean that all bugs will not fixed or only a certain sub-set of 
 bugs ?

I suppose he means that there's no guarantee that bugs are fixed. They may or may not be.
Aug 12 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Alexander Panek wrote:

 Nick B wrote:
   > Can you explain what you mean by a "unsupported release" ?
 
 Do you mean that all bugs will not fixed or only a certain sub-set of
 bugs ?

I suppose he means that there's no guarantee that bugs are fixed. They may or may not be.

Well, it would rather be more that we cannot guarantee that things operates as intended as long as there is no way to specify what we need to specify, or that the D spec don't have the necessary guarantees for the operation of the language. Potentially unbounded running time due to unexpected allocations would be one such thing. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 12 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Nick B wrote:
 Sean Kelly wrote:
 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn"
 or something similar would be used for full closures.

possible in D the default has to be

It's just a matter of opinion, I suppose. As D is a systems language, I don't agree with many arguments about safety when that safety conflicts with my ability to control what the language is doing behind the scenes. Portability between versions is also an issue--code that is correctly designed for D 1.0 may be unusable on D 2.0 because the default behavior for certain language features is different, although the syntax is still completely legal. Also, there isn't any way to easily grep for the use of delegates so finding such trouble spots requires a manual code review. Because one of Tango's core design goals was to have no hidden allocations, this behavior is a major concern for me because it forces me to choose between elegant algorithm design (which works fine in D 1.0) and a design that's portable between language versions in a way I find acceptable. I think if/when Tango is ever released for D 2.0 necessity may dictate that it be an unsupported release for reasons such as this.

Can you explain what you mean by a "unsupported release" ?

For example, Tango currently provides guarantees about hidden memory allocations -- ie. it doesn't perform any, really. But with the new closure rules in D2 we can't provide the same guarantee without a redesign. So I'd consider Tango on D2 to be unsupported because it won't be able to provide the guarantees we provide on D1 without a rewrite, which we aren't planning on doing.
 Do you mean that all bugs will not fixed or only a certain sub-set of 
 bugs ?

See above. I wouldn't consider these bugs per se, just documented behavior. Sean
Aug 14 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
What about, at least initially, releasing a subset of Tango for D2 and gradually
porting more as issues are fixed?  For example, just for now, just release
whatever subset of Tango is high-level enough to run on top of the D2 Phobos
runtime and isn't plagued too severely by const issues, even if it doesn't mesh
perfectly, i.e. requires some casting, etc. on the part of client code.  I'm not
really sure, but I would guess that this would leave a reasonably large subset
with plenty of useful things.

To be honest, I'm not sure how feasible this is, but I thought I would throw it
out there as a suggestion.  Tango is a huge library with tons of nice stuff, and
it seems like a shame that D2 users can't use any of it if only parts of it are
broken.
Aug 12 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
dsimcha wrote:

 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just release
 whatever subset of Tango is high-level enough to run on top of the D2
 Phobos runtime and isn't plagued too severely by const issues, even if it
 doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client code. 

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a reasonably
 large subset with plenty of useful things.
 
 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if only
 parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 12 2008
next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Lars Ivar Igesund wrote:
 dsimcha wrote:
 
 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just release
 whatever subset of Tango is high-level enough to run on top of the D2
 Phobos runtime and isn't plagued too severely by const issues, even if it
 doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client code. 

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a reasonably
 large subset with plenty of useful things.

 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if only
 parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango.

When is the Tango team and Walter going to get in the same room to thrash though these differences, because if these issues are not resolved, then the split will get wider, and wider. Finally, both communities will go their separate ways, and the community (both D and Tango) will burn and die. Nick B
Aug 13 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Nick B wrote:

 Lars Ivar Igesund wrote:
 dsimcha wrote:
 
 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just
 release whatever subset of Tango is high-level enough to run on top of
 the D2 Phobos runtime and isn't plagued too severely by const issues,
 even if it doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client code.

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a
 reasonably large subset with plenty of useful things.

 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if
 only parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango.


Bugzilla entries exists, it is up to Walter to decide the way forward. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 13 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Denis Koroskin wrote:

 On Wed, 13 Aug 2008 15:25:29 +0400, Lars Ivar Igesund
 <larsivar igesund.net> wrote:
 
 Nick B wrote:

 Lars Ivar Igesund wrote:
 dsimcha wrote:

 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just
 release whatever subset of Tango is high-level enough to run on top of
 the D2 Phobos runtime and isn't plagued too severely by const issues,
 even if it doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client
 code.

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a
 reasonably large subset with plenty of useful things.

 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if
 only parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango.


Bugzilla entries exists, it is up to Walter to decide the way forward.

The biggest issue is diffent Tango and Phobos runtime implementation, I think. I didn't find any bugzilla reports on this subject, though. :(

Oh, I actually misinterpreted Nick's meaning. Whether it is an issue or not, depends on the POV. Doing anything with it, is in Walter's ballpark. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 13 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

Oh, I actually misinterpreted Nick's meaning. Whether it is an issue or not, depends on the POV. Doing anything with it, is in Walter's ballpark.

Please see my other post here on this topic.
Aug 13 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Moritz Warning (moritzwarning web.de)'s article
 On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:
 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...

Unfortunately, for this to be resolved it requires cooperation from both sides. It takes two to Tango, as they say (sorry, bad joke). Sean
Aug 13 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly Wrote:

 == Quote from Moritz Warning (moritzwarning web.de)'s article
 On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:
 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...

Unfortunately, for this to be resolved it requires cooperation from both sides. It takes two to Tango, as they say (sorry, bad joke). Sean

I see the D community heading for a split. One side will be D1 (hopefully a D 1.5) +tango, and the other side will be D2+phobos. I don't think of this as a bad thing nessescarily, just two different directions.
Aug 13 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Robert Fraser wrote:
 Sean Kelly Wrote:
 
 == Quote from Moritz Warning (moritzwarning web.de)'s article
 On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:
 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...

sides. It takes two to Tango, as they say (sorry, bad joke). Sean

I see the D community heading for a split. One side will be D1 (hopefully a D 1.5) +tango, and the other side will be D2+phobos. I don't think of this as a bad thing nessescarily, just two different directions.

I desperately hope not. I'm strongly active in both camps. I'm heartily sick of this situation. std.math and tango.math.Math/ tango.math.IEEE are now a cut and paste of each other, barring a very small number of lines. I want a single code base, but I'm not sure what more I can do.
Aug 13 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 std.math and tango.math.Math/ 
 tango.math.IEEE are now a cut and paste of each other, barring a very 
 small number of lines. I want a single code base, but I'm not sure what 
 more I can do.

And I appreciate your efforts here and can't thank you enough.
Aug 13 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote:
 Robert Fraser wrote:
 Sean Kelly Wrote:

 == Quote from Moritz Warning (moritzwarning web.de)'s article
 On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:
 The biggest issue is diffent Tango and Phobos runtime 
 implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...

sides. It takes two to Tango, as they say (sorry, bad joke).

I see the D community heading for a split. One side will be D1 (hopefully a D 1.5) +tango, and the other side will be D2+phobos. I don't think of this as a bad thing nessescarily, just two different directions.

I desperately hope not. I'm strongly active in both camps. I'm heartily sick of this situation. std.math and tango.math.Math/ tango.math.IEEE are now a cut and paste of each other, barring a very small number of lines. I want a single code base, but I'm not sure what more I can do.

I don't particularly like the status quo either, but as the maintainer of the runtime there's little I can do for Phobos. It's already been established that the Phobos user code will run on the Tango runtime with basically no modifications (the reverse isn't true), and D2 support simply requires time I don't have at the moment. I'm not sure what else to do here. Sean
Aug 14 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Robert Fraser wrote:
 I see the D community heading for a split. One side will be D1 (hopefully a D
1.5) +tango, and the other side will be D2+phobos.  I don't think of this as a
bad thing nessescarily, just two different directions.

That might be okay in an open source project, where the community can just fork the project and go their separate ways. But my assumption is that D1 will eventually be end-of-life'd, maybe when D3 eventually arrives. What happens to the D1 people then? Especially given the incompatibilities between D1 and D2. They won't be able to easily port their code, and my assumption is that they'll just be screwed. --benji
Aug 13 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Benji Smith Wrote:

 Robert Fraser wrote:
 I see the D community heading for a split. One side will be D1 (hopefully a D
1.5) +tango, and the other side will be D2+phobos.  I don't think of this as a
bad thing nessescarily, just two different directions.

That might be okay in an open source project, where the community can just fork the project and go their separate ways. But my assumption is that D1 will eventually be end-of-life'd, maybe when D3 eventually arrives. What happens to the D1 people then? Especially given the incompatibilities between D1 and D2. They won't be able to easily port their code, and my assumption is that they'll just be screwed. --benji

D1 is definitely not dead. LLVMDC only supports D1 and is soon to come out. Dil... I'm not sure how alive it is, but that's D1-only, too. Most D projects/libraries right now are D1-only.
Aug 13 2008
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Robert Fraser wrote:
 Benji Smith Wrote:
 
 Robert Fraser wrote:
 I see the D community heading for a split. One side will be D1 (hopefully a D
1.5) +tango, and the other side will be D2+phobos.  I don't think of this as a
bad thing nessescarily, just two different directions.

just fork the project and go their separate ways. But my assumption is that D1 will eventually be end-of-life'd, maybe when D3 eventually arrives. What happens to the D1 people then? Especially given the incompatibilities between D1 and D2. They won't be able to easily port their code, and my assumption is that they'll just be screwed. --benji

D1 is definitely not dead. LLVMDC only supports D1 and is soon to come out. Dil... I'm not sure how alive it is, but that's D1-only, too. Most D projects/libraries right now are D1-only.

Sure, that's the case now. But imagine yourself back in 1997, supporting Java 1.0 but (for whatever reason) not wanting to jump into Java 1.1. At the time, you wouldn't have had any problem with compilers, libraries, or JVMs. But eventually, you'd be screwed. Nobody can develop anything in Java 1.0 anymore. It's just not possible. My assumption is that D1 will eventually be as anachronistic as Java 1.0, and those who aren't willing to move their code to D2 will have to pick up their toys and go home. --benji
Aug 13 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Benji Smith wrote:

 Robert Fraser wrote:
 Benji Smith Wrote:
 
 Robert Fraser wrote:
 I see the D community heading for a split. One side will be D1
 (hopefully a D 1.5) +tango, and the other side will be D2+phobos.  I
 don't think of this as a bad thing nessescarily, just two different
 directions.

just fork the project and go their separate ways. But my assumption is that D1 will eventually be end-of-life'd, maybe when D3 eventually arrives. What happens to the D1 people then? Especially given the incompatibilities between D1 and D2. They won't be able to easily port their code, and my assumption is that they'll just be screwed. --benji

D1 is definitely not dead. LLVMDC only supports D1 and is soon to come out. Dil... I'm not sure how alive it is, but that's D1-only, too. Most D projects/libraries right now are D1-only.

Sure, that's the case now. But imagine yourself back in 1997, supporting Java 1.0 but (for whatever reason) not wanting to jump into Java 1.1. At the time, you wouldn't have had any problem with compilers, libraries, or JVMs. But eventually, you'd be screwed. Nobody can develop anything in Java 1.0 anymore. It's just not possible. My assumption is that D1 will eventually be as anachronistic as Java 1.0, and those who aren't willing to move their code to D2 will have to pick up their toys and go home. --benji

You probably have a point, but Java 1.0 was really dead in the water - I started programming in Java in 1998 back at the university, using 1.1, and I don't think I came over a single 1.0 reference. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Benji Smith wrote:
 Robert Fraser wrote:
 D1 is definitely not dead. LLVMDC only supports D1 and is soon to come
 out. Dil... I'm not sure how alive it is, but that's D1-only, too. 
 Most D projects/libraries right now are D1-only.

Sure, that's the case now. But imagine yourself back in 1997, supporting Java 1.0 but (for whatever reason) not wanting to jump into Java 1.1.

When you ship a Java application, you are reliant on it running on the customer's Java VM that is not under your control. If they don't have a Java 1.1 VM, your application doesn't work. The situation is different with a native compiler, because the customer doesn't need anything beyond the target machine/OS to run the application. Furthermore, you can continue to build those executables, regardless of future changes to the compiler, by simply saving a copy of the needed compiler. Even if you didn't save a copy of the compiler, all the various shipped versions of dmd are freely available on the Digital Mars site.
Aug 14 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Benji Smith wrote:
 Robert Fraser wrote:
 D1 is definitely not dead. LLVMDC only supports D1 and is soon to come
 out. Dil... I'm not sure how alive it is, but that's D1-only, too. 
 Most D projects/libraries right now are D1-only.

Sure, that's the case now. But imagine yourself back in 1997, supporting Java 1.0 but (for whatever reason) not wanting to jump into Java 1.1.

When you ship a Java application, you are reliant on it running on the customer's Java VM that is not under your control. If they don't have a Java 1.1 VM, your application doesn't work. The situation is different with a native compiler, because the customer doesn't need anything beyond the target machine/OS to run the application. Furthermore, you can continue to build those executables, regardless of future changes to the compiler, by simply saving a copy of the needed compiler. Even if you didn't save a copy of the compiler, all the various shipped versions of dmd are freely available on the Digital Mars site.

The issue is not just about outdated VMs, or outdated compilers. If you are developing an application that uses third-party libraries (which is very common in web-apps, and other big enterprise software), and those libraries require a newer version of your language, you will feel quite compelled to upgrade to the newer version in order to use that libraries. And eventually, if most libraries only support version X of the language, almost all software ends up using version X, and then version X-1 might become effectively dead (and that's something that could happen to D1). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Benji Smith" <dlanguage benjismith.net> wrote in message 
news:g7vlkg$2gmg$1 digitalmars.com...
 Robert Fraser wrote:
 Benji Smith Wrote:

 Robert Fraser wrote:
 I see the D community heading for a split. One side will be D1 
 (hopefully a D 1.5) +tango, and the other side will be D2+phobos.  I 
 don't think of this as a bad thing nessescarily, just two different 
 directions.

just fork the project and go their separate ways. But my assumption is that D1 will eventually be end-of-life'd, maybe when D3 eventually arrives. What happens to the D1 people then? Especially given the incompatibilities between D1 and D2. They won't be able to easily port their code, and my assumption is that they'll just be screwed. --benji

D1 is definitely not dead. LLVMDC only supports D1 and is soon to come out. Dil... I'm not sure how alive it is, but that's D1-only, too. Most D projects/libraries right now are D1-only.

Sure, that's the case now. But imagine yourself back in 1997, supporting Java 1.0 but (for whatever reason) not wanting to jump into Java 1.1. At the time, you wouldn't have had any problem with compilers, libraries, or JVMs. But eventually, you'd be screwed. Nobody can develop anything in Java 1.0 anymore. It's just not possible. My assumption is that D1 will eventually be as anachronistic as Java 1.0, and those who aren't willing to move their code to D2 will have to pick up their toys and go home. --benji

People are still using C89. *shrug*
Aug 14 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:
 LLVMDC only supports D1 and is soon to come out.

D2 is good, I can see only one or two problems in it, so making LLVMDC support D 2.x too looks important to me. What are the issues left in LLVMDC? I see the LLVM backend as the most (the only, maybe) important for the future of D (more important than the closed and not community-hackable backend of DMD, and the complex GCC), are such issues important? If they aren't important then it may be better for Walter to change the specs of D 2.x to made D 2.x fit for LLMV. Because D is meant as a language easy to compile too, but if has some features that can't be implemented well on free backends like the ones of GCC and LLMV then such features look like fit to be removed/modified, otherwise no fully complaint alternative implementations of D may appear, and this sounds silly. Two persons have already answered me regarding the idea of LLVM becoming the reference backend for the D language (that Walter too switches to work on), that most people can improve and tune, but I haven't understood the problems they have explained to me. Bye, bearophile
Aug 13 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Robert Fraser:
 LLVMDC only supports D1 and is soon to come out.

D2 is good, I can see only one or two problems in it, so making LLVMDC support D 2.x too looks important to me.

I have no idea what would prevent a backend that works with D1 from working with D2.
Aug 13 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 bearophile wrote:
 Robert Fraser:
 LLVMDC only supports D1 and is soon to come out.

D2 is good, I can see only one or two problems in it, so making LLVMDC support D 2.x too looks important to me.

I have no idea what would prevent a backend that works with D1 from working with D2.

Except for all our changes to the dmd frontend sources, I don't see any problem with updating LLVMDC to D2.0. Of course it would be a bit of work to implement the new expression/statement variations, but I'd assume nothing _too_ major. However the plan right now is to make a fully working D1.0 compiler, until that's done no work will go into future D2.0 support! Tomas
Aug 13 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 Except for all our changes to the dmd frontend sources, I don't see any 
 problem with updating LLVMDC to D2.0.

I suppose this process can be aided if you're willing to send me some diffs so I can incorporate the changes.
Aug 13 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 I suppose this process can be aided if you're willing to send me some 
 diffs so I can incorporate the changes.

I'll most likely hold you up on that ;) ... Most of the changes we've made are to fix portability/platform related issues. For example, extensive use of printf formatting flags unsupported by ming32, assumptions that target is 32bit, etc. These would be really nice to get fixed in your tree as they make up the majority of the changes, and it would make merging in your DMD updates quite a bit easier. Also it would probably help other people use the frontend for different things in the future. We're still at 1.033 in LLVMDC, but once I find the time to merge in 1.034 I'll take a look at this and see if I can conjure up some patches for review. Tomas
Aug 13 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 Most of the changes we've made are to fix portability/platform related 
 issues. For example, extensive use of printf formatting flags 
 unsupported by ming32,

Umm, those are standard C flags? Hasn't ming32 been updated yet?
 assumptions that target is 32bit, etc.
 
 These would be really nice to get fixed in your tree as they make up the 
 majority of the changes, and it would make merging in your DMD updates 
 quite a bit easier. Also it would probably help other people use the 
 frontend for different things in the future.

Yes, I agree. Absolutely!
 We're still at 1.033 in LLVMDC, but once I find the time to merge in 
 1.034 I'll take a look at this and see if I can conjure up some patches 
 for review.

I'm looking forward to it.
Aug 13 2008
next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 Tomas Lindquist Olsen wrote:
 We're still at 1.033 in LLVMDC, but once I find the time to merge in 
 1.034 I'll take a look at this and see if I can conjure up some 
 patches for review.

I'm looking forward to it.

I just had a tiny look, and it looks like you forgot the file(s) with the implementations for all the new arrayOp stuff like: Expression::buildArrayIdent Expression::buildArrayLoop Expression::arrayOp I'm guessing this is not intentional... Could you mail this to me? This address should work. Tomas
Aug 13 2008
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 Most of the changes we've made are to fix portability/platform related 
 issues. For example, extensive use of printf formatting flags 
 unsupported by ming32,

Umm, those are standard C flags? Hasn't ming32 been updated yet?
 assumptions that target is 32bit, etc.

 These would be really nice to get fixed in your tree as they make up 
 the majority of the changes, and it would make merging in your DMD 
 updates quite a bit easier. Also it would probably help other people 
 use the frontend for different things in the future.

Yes, I agree. Absolutely!

GDC has a couple of those portability changes too, that might be useful to merge back into DMD where that hasn't happened already... It also seems that Tango is having some problems with GDC, because it doesn't follow the DMD specification (sometimes for portability) Like: http://d.puremagic.com/issues/show_bug.cgi?id=670 http://d.puremagic.com/issues/show_bug.cgi?id=1066 http://d.puremagic.com/issues/show_bug.cgi?id=2191 Might be something worthwhile looking into, after the runtime issues between Phobos and Tango (i.e. the differences between DMD and GDC) --anders
Aug 14 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 
 Most of the changes we've made are to fix portability/platform related
 issues. For example, extensive use of printf formatting flags
 unsupported by ming32,

Umm, those are standard C flags? Hasn't ming32 been updated yet?
 assumptions that target is 32bit, etc.

 These would be really nice to get fixed in your tree as they make up
 the majority of the changes, and it would make merging in your DMD
 updates quite a bit easier. Also it would probably help other people
 use the frontend for different things in the future.

Yes, I agree. Absolutely!

GDC has a couple of those portability changes too, that might be useful to merge back into DMD where that hasn't happened already... It also seems that Tango is having some problems with GDC, because it doesn't follow the DMD specification (sometimes for portability) Like: http://d.puremagic.com/issues/show_bug.cgi?id=670 http://d.puremagic.com/issues/show_bug.cgi?id=1066 http://d.puremagic.com/issues/show_bug.cgi?id=2191 Might be something worthwhile looking into, after the runtime issues between Phobos and Tango (i.e. the differences between DMD and GDC)

This is actually an intended topic at the Tango conference, if many enough/right persons show up :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Tomas Lindquist Olsen wrote:
 Most of the changes we've made are to fix portability/platform related 
 issues. For example, extensive use of printf formatting flags 
 unsupported by ming32,

Umm, those are standard C flags? Hasn't ming32 been updated yet?
 assumptions that target is 32bit, etc.

 These would be really nice to get fixed in your tree as they make up 
 the majority of the changes, and it would make merging in your DMD 
 updates quite a bit easier. Also it would probably help other people 
 use the frontend for different things in the future.

Yes, I agree. Absolutely!
 We're still at 1.033 in LLVMDC, but once I find the time to merge in 
 1.034 I'll take a look at this and see if I can conjure up some 
 patches for review.

I'm looking forward to it.

Walter, thank you for agreeing with those changes! As the toolset of a language is highly important to its productivity, so does that mean that the more help the community gets in reusing and improving each others tools, the better D will be (especially since we don't have the backing of a large corporation, and most of D's contributers are volunteers/hobbyists). And even more important if that tool is the compiler (which is already being used in several projects). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling next sibling parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Robert Fraser Wrote:

 I see the D community heading for a split. One side will be D1 (hopefully a D
1.5) +tango, and the other side will be D2+phobos.  I don't think of this as a
bad thing nessescarily, just two different directions.

First, let me say that I have the highest regard, both personally and professionally, for Walter (and Andre and Bartosz and the others who are working on D 2.0) and also for the Tango development team. Both groups have a lot of talent and have worked hard to give us (at no cost!) a great language and a great library. The Tango developers have done important and valuable work, providing sturdy, efficient and rigorous implementations of many common software components. They have not only provided the Tango library, but they've also wrung out the language and pushed its capabilities to give us all a better picture of what is possible. (I'd love to see what they could do with the new features in D 2.0.) And they have been careful not to step on Walter's toes while they do this. They discussed the problem with Walter at the first D Language Conference and agreed on a solution: a common runtime module. They have narrowed the incompatibilities between phobos and tango to a minimal set and are waiting for Walter to meet them there. To live up to his part of the bargain, to put it bluntly. A year later he still hasn't done so. But Walter drives development his own way. Walter himself has said that the only difference between himself (and D) and a lot of other replacements for C/C++ is that he's stayed with it longer than they have. And so Walter will listen and respond to criticism, new concepts, alternative implementations and frantic pleas, but, at the end of the day, he will work toward what he sees as the best solution to the most pressing problems. This is mostly a good thing -- Walter has a long-term vision for the D programming language and he is determined to see it through. Of course, this also has a downside. Work that doesn't advance the main line that he has mapped out doesn't get his attention, or his time. It's not that he's unwilling, but he's doing a lot of work on developing what he sees as more fundamental things. So I don't think it is likely that Walter will delay or disturb his current effort to get D 2.0 pushed out the door. And he's made it clear that he not interested in going back to "fix" D 1.0. But what I would really like to see (and I don't think it's asking too much) is a clear statement from Walter that he will indeed make the changes the Tango developers are asking for at some future date. I don't think he even needs to commit himself to a specific date, just a reference point -- when D 2.0 is final, or when the functional programming stuff is in place, or whenever. I think all that we really NEED at this point is assurance that the two groups are not working at cross purposes. If this has already happened, if there is some agreement in place that I just don't know about, then I apologize for this rant. But it seems like little enough to ask. Paul
Aug 13 2008
next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 14 Aug 2008 02:05:37 +0400, Paul D. Anderson  
<paul.d.removethis.anderson comcast.andthis.net> wrote:

 Robert Fraser Wrote:

 I see the D community heading for a split. One side will be D1  
 (hopefully a D 1.5) +tango, and the other side will be D2+phobos.  I  
 don't think of this as a bad thing nessescarily, just two different  
 directions.

First, let me say that I have the highest regard, both personally and professionally, for Walter (and Andre and Bartosz and the others who are working on D 2.0) and also for the Tango development team. Both groups have a lot of talent and have worked hard to give us (at no cost!) a great language and a great library. The Tango developers have done important and valuable work, providing sturdy, efficient and rigorous implementations of many common software components. They have not only provided the Tango library, but they've also wrung out the language and pushed its capabilities to give us all a better picture of what is possible. (I'd love to see what they could do with the new features in D 2.0.) And they have been careful not to step on Walter's toes while they do this. They discussed the problem with Walter at the first D Language Conference and agreed on a solution: a common runtime module. They have narrowed the incompatibilities between phobos and tango to a minimal set and are waiting for Walter to meet them there. To live up to his part of the bargain, to put it bluntly. A year later he still hasn't done so. But Walter drives development his own way. Walter himself has said that the only difference between himself (and D) and a lot of other replacements for C/C++ is that he's stayed with it longer than they have. And so Walter will listen and respond to criticism, new concepts, alternative implementations and frantic pleas, but, at the end of the day, he will work toward what he sees as the best solution to the most pressing problems. This is mostly a good thing -- Walter has a long-term vision for the D programming language and he is determined to see it through. Of course, this also has a downside. Work that doesn't advance the main line that he has mapped out doesn't get his attention, or his time. It's not that he's unwilling, but he's doing a lot of work on developing what he sees as more fundamental things. So I don't think it is likely that Walter will delay or disturb his current effort to get D 2.0 pushed out the door. And he's made it clear that he not interested in going back to "fix" D 1.0. But what I would really like to see (and I don't think it's asking too much) is a clear statement from Walter that he will indeed make the changes the Tango developers are asking for at some future date. I don't think he even needs to commit himself to a specific date, just a reference point -- when D 2.0 is final, or when the functional programming stuff is in place, or whenever. I think all that we really NEED at this point is assurance that the two groups are not working at cross purposes. If this has already happened, if there is some agreement in place that I just don't know about, then I apologize for this rant. But it seems like little enough to ask. Paul

May I ask why is this post called like that? Walter has just responded that he is ready to make the asked changes to the runtime, and is waiting for a permission from some Tango members to do this. We will see a resolution pretty soon, hopefully!
Aug 13 2008
prev sibling next sibling parent superdan <super dan.org> writes:
Paul D. Anderson Wrote:

 Robert Fraser Wrote:
 
 I see the D community heading for a split. One side will be D1 (hopefully a D
1.5) +tango, and the other side will be D2+phobos.  I don't think of this as a
bad thing nessescarily, just two different directions.

First, let me say that I have the highest regard, both personally and professionally, for Walter (and Andre and Bartosz and the others who are working on D 2.0) and also for the Tango development team. Both groups have a lot of talent and have worked hard to give us (at no cost!) a great language and a great library. The Tango developers have done important and valuable work, providing sturdy, efficient and rigorous implementations of many common software components. They have not only provided the Tango library, but they've also wrung out the language and pushed its capabilities to give us all a better picture of what is possible. (I'd love to see what they could do with the new features in D 2.0.) And they have been careful not to step on Walter's toes while they do this. They discussed the problem with Walter at the first D Language Conference and agreed on a solution: a common runtime module. They have narrowed the incompatibilities between phobos and tango to a minimal set and are waiting for Walter to meet them there. To live up to his part of the bargain, to put it bluntly. A year later he still hasn't done so. But Walter drives development his own way. Walter himself has said that the only difference between himself (and D) and a lot of other replacements for C/C++ is that he's stayed with it longer than they have. And so Walter will listen and respond to criticism, new concepts, alternative implementations and frantic pleas, but, at the end of the day, he will work toward what he sees as the best solution to the most pressing problems. This is mostly a good thing -- Walter has a long-term vision for the D programming language and he is determined to see it through. Of course, this also has a downside. Work that doesn't advance the main line that he has mapped out doesn't get his attention, or his time. It's not that he's unwilling, but he's doing a lot of work on developing what he sees as more fundamental things. So I don't think it is likely that Walter will delay or disturb his current effort to get D 2.0 pushed out the door. And he's made it clear that he not interested in going back to "fix" D 1.0. But what I would really like to see (and I don't think it's asking too much) is a clear statement from Walter that he will indeed make the changes the Tango developers are asking for at some future date. I don't think he even needs to commit himself to a specific date, just a reference point -- when D 2.0 is final, or when the functional programming stuff is in place, or whenever. I think all that we really NEED at this point is assurance that the two groups are not working at cross purposes. If this has already happened, if there is some agreement in place that I just don't know about, then I apologize for this rant. But it seems like little enough to ask. Paul

bet you wish you'd read earlier what walt wrote in this thread eh. i thought pretty much along the same lines. but in fact walt's statement is revealing. changes perspective on the issue 180 radians (joke!). looks like he wasn't the bad (or careless or uninterested or unfocused... whatever) dood afterall? he was just being discreet? i take it there's been talks and stuff and walt just didn't get permission to mess with tango's code? why? for how long has this been goin' on, walt? and why didn't you tell this earlier? whoa. this is an epic moment. like one of those twists in a whodunit. killer wasn't her, it was her sister!
Aug 13 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)
Aug 13 2008
next sibling parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Walter Bright Wrote:

 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

Thanks for clarifying this, and I apologize, Walter, and reiterate my appreciation for what you do. But I was expressing my frustration at what I thought the situation was. If there was discussion about licensing issues I missed it. (I missed your earlier post in this thread because I was busy "composing" my tirade.) From my point of view this puts the ball squarely back in Tango's court. Is there a fundamental problem here? Can we move forward? Paul
Aug 13 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Paul D. Anderson wrote:
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)
 
 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?

I have not spoken out on it before out of respect for the Tango developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.
Aug 13 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,

 Paul D. Anderson wrote:
 
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)
 
 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?
 

developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.

If nothing else it will notify everyone who needs to do something to make it work.
Aug 13 2008
prev sibling next sibling parent Nick B <nick.barbalich gmail.com> writes:
Walter Bright wrote:
 Paul D. Anderson wrote:
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)

 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?

I have not spoken out on it before out of respect for the Tango developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.

Walter Thank you for bring these private discussions into the open. Nick B.
Aug 14 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Paul D. Anderson wrote:
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)

 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?

I have not spoken out on it before out of respect for the Tango developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.

I don't want to speak for others, but I believe that the issue with opening up the license for Tango concerns the user code, not the runtime. The initial request was for rights to all of Tango. Sean
Aug 14 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Paul D. Anderson wrote:
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)

 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?

I have not spoken out on it before out of respect for the Tango developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.

Thanks for bringing it out, at least it helps us "observers" have a better picture of why the current status quo. And indeed I was thinking that the ball was almost entirely in your court. ~~' -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling parent reply lurker <lurker lurk.com> writes:
Paul D. Anderson Wrote:

 Walter Bright Wrote:
 
 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

Thanks for clarifying this, and I apologize, Walter, and reiterate my appreciation for what you do. But I was expressing my frustration at what I thought the situation was. If there was discussion about licensing issues I missed it. (I missed your earlier post in this thread because I was busy "composing" my tirade.) From my point of view this puts the ball squarely back in Tango's court. Is there a fundamental problem here? Can we move forward? Paul

Hullo, Thats not happening now or recently. The ball its been rotting in Tango's court for one year plus. This is huge. I might need a couple days to process this information. Naming names is scary but, ..... is Walter saying Kris and Lars "MI Is Evil" Igesund deliberately prevented unification progress? One thing for sure. assert(cat !in bag); -Lurker
Aug 13 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
lurker wrote:
 Hullo,
 
 Thats not happening now or recently. The ball its been rotting in Tango's
court for one year plus. This is huge. I might need a couple days to process
this information. Naming names is scary but, ..... is Walter saying Kris and
Lars "MI Is Evil" Igesund deliberately prevented unification progress?
 
 One thing for sure. 
 
 assert(cat !in bag);
 
 -Lurker

Dozens of people have worked on Tango. Tracking who owns the code is nontrivial, as is contacting some of them. It might be impossible to get a license change cleared. Of course, if Walter replaced the Phobos runtime entirely with Tango's, that might not be an issue. But it would involve using the BSD license for those parts.
Aug 13 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is 
 nontrivial, as is contacting some of them. It might be impossible to get 
 a license change cleared.

I understand that. But my understanding (I am not a lawyer) of copyright law is that a couple of lines of code are not copyrightable. But major contributors to Tango should be reachable.
Aug 13 2008
parent reply "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is
 nontrivial, as is contacting some of them. It might be impossible to
 get a license change cleared.

I understand that. But my understanding (I am not a lawyer) of copyrigh=

 law is that a couple of lines of code are not copyrightable. But major
 contributors to Tango should be reachable.

I too am not a lawyer, but I was under the impression that contributions to Tango are still property of Tango and subject to the global Tango license. Maybe someone should ask a lawyer... there's a good radio phone-a-lawyer guy in my area I could call.
Aug 13 2008
parent reply Sean Reque <seanthenewt yahoo.com> writes:
Chris R. Miller Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is
 nontrivial, as is contacting some of them. It might be impossible to
 get a license change cleared.

I understand that. But my understanding (I am not a lawyer) of copyright law is that a couple of lines of code are not copyrightable. But major contributors to Tango should be reachable.

I too am not a lawyer, but I was under the impression that contributions to Tango are still property of Tango and subject to the global Tango license. Maybe someone should ask a lawyer... there's a good radio phone-a-lawyer guy in my area I could call.

There could be cause for concern. This is from http://www.sqlite.org/copyright.html """ Contributed Code In order to keep SQLite completely free and unencumbered by copyright, all new contributors to the SQLite code base are asked to dedicate their contributions to the public domain. If you want to send a patch or enhancement for possible inclusion in the SQLite source tree, please accompany the patch with the following statement: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law. We are not able to accept patches or changes to SQLite that are not accompanied by a statement such as the above. In addition, if you make changes or enhancements as an employee, then a simple statement such as the above is insufficient. You must also send by surface mail a copyright release signed by a company officer. A signed original of the copyright release should be mailed to: """
Aug 13 2008
next sibling parent reply "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Brad Roberts wrote:
 On Wed, 13 Aug 2008, Sean Reque wrote:
=20
 Chris R. Miller Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code i=





 nontrivial, as is contacting some of them. It might be impossible t=





 get a license change cleared.





 law is that a couple of lines of code are not copyrightable. But maj=




 contributors to Tango should be reachable.




 to Tango are still property of Tango and subject to the global Tango
 license.

 Maybe someone should ask a lawyer...  there's a good radio
 phone-a-lawyer guy in my area I could call.

There could be cause for concern. This is from http://www.sqlite.org/c=


 """
 Contributed Code

 In order to keep SQLite completely free and unencumbered by copyright,=


contributions to the public domain. If you want to send a patch or enhan= cement for possible inclusion in the SQLite source tree, please accompany= the patch with the following statement:
     The author or authors of this code dedicate any and all copyright =


he benefit of the public at large and to the detriment of our heirs and s= uccessors. We intend this dedication to be an overt act of relinquishment= in perpetuity of all present and future rights to this code under copyri= ght law.=20
 We are not able to accept patches or changes to SQLite that are not ac=


ges or enhancements as an employee, then a simple statement such as the a= bove is insufficient. You must also send by surface mail a copyright rele= ase signed by a company officer. A signed original of the copyright relea= se should be mailed to:
 """

The number of people that have touched the runtime layer of Tango is ve=

 limited.  The upper layers are of no concern for this thread.

Well why not try to establish a precedent for all of Tango? Tango is dual licensed Academic Free and BSD. So long as Walter + friends include a notice in the Readme file, it's completely legal for him to use any or ALL of Tango. That's a reality, since it's common practice to consider a note in the readme fulfillment of the BSD attribution clause. Most popular video games do this to legally use the ZLib compression libraries. As for the Sqlite disclaimer, I would think that's just an insurance. Plenty of other organizations don't do that. I've been on the Linux Kernel Janitor's list for two years now, and none of the patches that actually go into the Holy Kernel Itself are ever "protected" by any such disclaimer from the contributors. I would argue that by contributing to Tango/LKJ/Sqlite/OSS you are implicitly stating that you're /giving/ that code to the organization. No strings attached, released under the organization's license. Just my $0.02. IANAL, but from all I've observed, that is the way things work (if not legally, then in a de facto way).
Aug 13 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Chris R. Miller wrote:

 Brad Roberts wrote:
 On Wed, 13 Aug 2008, Sean Reque wrote:
 
 Chris R. Miller Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is
 nontrivial, as is contacting some of them. It might be impossible to
 get a license change cleared.

copyright law is that a couple of lines of code are not copyrightable. But major contributors to Tango should be reachable.

contributions to Tango are still property of Tango and subject to the global Tango license. Maybe someone should ask a lawyer... there's a good radio phone-a-lawyer guy in my area I could call.

There could be cause for concern. This is from http://www.sqlite.org/copyright.html """ Contributed Code In order to keep SQLite completely free and unencumbered by copyright, all new contributors to the SQLite code base are asked to dedicate their contributions to the public domain. If you want to send a patch or enhancement for possible inclusion in the SQLite source tree, please accompany the patch with the following statement: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law. We are not able to accept patches or changes to SQLite that are not accompanied by a statement such as the above. In addition, if you make changes or enhancements as an employee, then a simple statement such as the above is insufficient. You must also send by surface mail a copyright release signed by a company officer. A signed original of the copyright release should be mailed to: """

The number of people that have touched the runtime layer of Tango is very limited. The upper layers are of no concern for this thread.

Well why not try to establish a precedent for all of Tango? Tango is dual licensed Academic Free and BSD. So long as Walter + friends include a notice in the Readme file, it's completely legal for him to use any or ALL of Tango. That's a reality, since it's common practice to consider a note in the readme fulfillment of the BSD attribution clause. Most popular video games do this to legally use the ZLib compression libraries. As for the Sqlite disclaimer, I would think that's just an insurance. Plenty of other organizations don't do that. I've been on the Linux Kernel Janitor's list for two years now, and none of the patches that actually go into the Holy Kernel Itself are ever "protected" by any such disclaimer from the contributors. I would argue that by contributing to Tango/LKJ/Sqlite/OSS you are implicitly stating that you're /giving/ that code to the organization. No strings attached, released under the organization's license.

Tango as a project don't have copyright. It is kept by the individual contributors. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 
 Tango as a project don't have copyright. It is kept by the individual
 contributors.
 

wouldn't it be better that Tango as a project would own the copyright for all the code? In case that the project wants to change the license or give someone specific permission to the code base (like Walter asks for) that would be easier to accomplish by the Tango's maintainers. in the current state of affairs you need to contact each contributer and get his personal approval. Linux has the same policy and thus if Linus wants to move from GPLv2 to v3 he can't since he needs approval of all the thousands of contributers to the Linux kernel, some of which are dead. This is why all the GNU code is assigned to the FSF and without your agreement to transfer your copyrights to the FSF they won't accept your code. This is also standard practice in almost all OSS projects (with Linux a notable exception as described above). Of course, the sooner such a move is decided upon the easier it'll be to accomplish. Linux, for example, cannot change the license without talking to the dead or reimplementing parts of the code.
Aug 14 2008
next sibling parent Thomas Brix Larsen <brix brix-verden.dk> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 
 Tango as a project don't have copyright. It is kept by the individual
 contributors.
 

wouldn't it be better that Tango as a project would own the copyright for all the code? In case that the project wants to change the license or give someone specific permission to the code base (like Walter asks for) that would be easier to accomplish by the Tango's maintainers. in the current state of affairs you need to contact each contributer and get his personal approval. Linux has the same policy and thus if Linus wants to move from GPLv2 to v3 he can't since he needs approval of all the thousands of contributers to the Linux kernel, some of which are dead. This is why all the GNU code is assigned to the FSF and without your agreement to transfer your copyrights to the FSF they won't accept your code. This is also standard practice in almost all OSS projects (with Linux a notable exception as described above).

I'm not so sure about that. KDE and Wine atleast isn't copyrighted by their project foundations, but by their contributors, just like Linux.
 Of course, the sooner such a move is decided upon the easier it'll be to
 accomplish. Linux, for example, cannot change the license without
 talking to the dead or reimplementing parts of the code.

Aug 14 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 
 Tango as a project don't have copyright. It is kept by the individual
 contributors.
 

wouldn't it be better that Tango as a project would own the copyright for all the code?

At the very least you need some body (foundation, company) for that. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Yigal Chripun wrote:
 
 Lars Ivar Igesund wrote:
 Tango as a project don't have copyright. It is kept by the individual
 contributors.

for all the code?

At the very least you need some body (foundation, company) for that.

Of course and I'm sure it's a hassle to create one. but it is better to have such a body in the long term in order to facilitate the growth of the community, I think.
Aug 14 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Yigal Chripun wrote:
 Lars Ivar Igesund wrote:
 Tango as a project don't have copyright. It is kept by the individual
 contributors.

wouldn't it be better that Tango as a project would own the copyright for all the code? In case that the project wants to change the license or give someone specific permission to the code base (like Walter asks for) that would be easier to accomplish by the Tango's maintainers. in the current state of affairs you need to contact each contributer and get his personal approval.

Although the contributors retain copyright to their contributions they still must agree to place their code under the Tango license. This has never been an issue for us in the past, but then no one has ever asked us to change our license before :-)
 Linux has the same policy and thus if Linus wants to move from GPLv2 to
 v3 he can't since he needs approval of all the thousands of contributers
 to the Linux kernel, some of which are dead.

It's a good point, though the current Tango license is so loose that I don't foresee us ever needing to change it. All the artistic license requires is basically that the author information not be removed from the source code. That's as close to Public Domain as you can get without actually being Public Domain.
 Of course, the sooner such a move is decided upon the easier it'll be to
 accomplish. Linux, for example, cannot change the license without
 talking to the dead or reimplementing parts of the code.

Definitely. Sean
Aug 14 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Brad Roberts wrote:
 On Wed, 13 Aug 2008, Sean Reque wrote:
 
 Chris R. Miller Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is
 nontrivial, as is contacting some of them. It might be impossible to
 get a license change cleared.

law is that a couple of lines of code are not copyrightable. But major contributors to Tango should be reachable.

to Tango are still property of Tango and subject to the global Tango license. Maybe someone should ask a lawyer... there's a good radio phone-a-lawyer guy in my area I could call.

There could be cause for concern. This is from http://www.sqlite.org/copyright.html """ Contributed Code In order to keep SQLite completely free and unencumbered by copyright, all new contributors to the SQLite code base are asked to dedicate their contributions to the public domain. If you want to send a patch or enhancement for possible inclusion in the SQLite source tree, please accompany the patch with the following statement: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law. We are not able to accept patches or changes to SQLite that are not accompanied by a statement such as the above. In addition, if you make changes or enhancements as an employee, then a simple statement such as the above is insufficient. You must also send by surface mail a copyright release signed by a company officer. A signed original of the copyright release should be mailed to: """

The number of people that have touched the runtime layer of Tango is very limited. The upper layers are of no concern for this thread.

So limited, in fact, that the two Tango members who have not given permission to use their code have never actually touched the runtime. I'm very diligent about the "author" labels in the runtime modules, so this is easy to see. However, the problem is that there is no way to prove this to Walter, and he refuses to even look at Tango without permission from all of us for fear of "taint." Thus the impasse. Given Walter's experience with copyright issues I think his caution is certainly well-founded, but it does make things somewhat difficult if all of the contributors to Tango as a whole either can not or will not make their contributions Public Domain for use by Phobos. To be honest, I would even much rather have stuck with an artistic license at least for my portion, but what can you do. Fortunately, I trust that Walter isn't going to start trying to sell my code to companies and claim it's his own (my only real issue with the Public Domain license to begin with). Sean
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 The number of people that have touched the runtime layer of Tango is very 
 limited.  The upper layers are of no concern for this thread.

So limited, in fact, that the two Tango members who have not given permission to use their code have never actually touched the runtime. I'm very diligent about the "author" labels in the runtime modules, so this is easy to see. However, the problem is that there is no way to prove this to Walter, and he refuses to even look at Tango without permission from all of us for fear of "taint." Thus the impasse.

Eh? As far as I know, if you don't put your name on it, you don't own it. If I copyright something by putting a copyright notice on it after I release it, it doesn't magically copyright all the previously released versions that didn't have that copyright notice. *Especially* if there is an existing copyright notice in the file attributed to someone else, and the file is in the project that I am contributing to! This should be a non-issue. How could you ever "prove" this to anyone without videotaping them typing in the code? I respect that certain Tango authors do not want to have their code imported into Phobos, but that should not be a blocker if their code isn't in question. And even if contributors do not want their code in Phobos, too bad so sad. They agreed to license their code under the BSD license, and that means anyone can use the code for any reason as long as the original authors get credit.
 Given Walter's experience with copyright issues I think his caution is 
 certainly well-founded, but it does make things somewhat difficult if all 
 of the contributors to Tango as a whole either can not or will not make 
 their contributions Public Domain for use by Phobos.

I think his caution is a little too overzealous (if this is the reason). The whole point of an open-source license is code reuse. Phobos has an open source license. Tango has an open source license. Where is the conflict? -Steve
Aug 14 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Steven Schveighoffer wrote:

 "Sean Kelly" wrote
 The number of people that have touched the runtime layer of Tango is
 very
 limited.  The upper layers are of no concern for this thread.

So limited, in fact, that the two Tango members who have not given permission to use their code have never actually touched the runtime. I'm very diligent about the "author" labels in the runtime modules, so this is easy to see. However, the problem is that there is no way to prove this to Walter, and he refuses to even look at Tango without permission from all of us for fear of "taint." Thus the impasse.

Eh? As far as I know, if you don't put your name on it, you don't own it.

In many (most) countries, writing it means you have copyright. Whether you put your name there or not is irrelevant. Some have even stronger protection of the connection between code/work and author. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Lars Ivar Igesund" wrote
 Steven Schveighoffer wrote:

 "Sean Kelly" wrote
 The number of people that have touched the runtime layer of Tango is
 very
 limited.  The upper layers are of no concern for this thread.

So limited, in fact, that the two Tango members who have not given permission to use their code have never actually touched the runtime. I'm very diligent about the "author" labels in the runtime modules, so this is easy to see. However, the problem is that there is no way to prove this to Walter, and he refuses to even look at Tango without permission from all of us for fear of "taint." Thus the impasse.

Eh? As far as I know, if you don't put your name on it, you don't own it.

In many (most) countries, writing it means you have copyright. Whether you put your name there or not is irrelevant. Some have even stronger protection of the connection between code/work and author.

I would think that only comes into play if someone else publishes the code after stealing it from you. If you release it with someone else's name as the copyright holder, I don't see how you can prove your rights. It shouldn't be hard to prove who contributed what since all the history is in svn. To this end, even if Walter DID get permission from all the Tango devs, this does not preclude the possibility that someone else's code (not even from Tango) was stolen and contributed to Tango. There is no way to be 100% sure, so this whole issue is rather petty to me. But wouldn't it be enough for all the Tango devs (who didn't write the runtime) to put that in a signed statement? I can't see how releasing *all* of Tango in PD (or even the runtime, for that matter, but that's up to the devs of the runtime) makes it any more valid. -Steve
Aug 14 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 To this end, even if Walter DID get permission from all the Tango devs, this 
 does not preclude the possibility that someone else's code (not even from 
 Tango) was stolen and contributed to Tango.  There is no way to be 100% 
 sure, so this whole issue is rather petty to me.

That would not be good, but at least I would have taken reasonable steps and that's all that could be expected. In my experience with legal cases, taking reasonable steps carries the day. Frankly, the whole economy would collapse if you could not take a signed statement at face value.
 But wouldn't it be enough for all the Tango devs (who didn't write the 
 runtime) to put that in a signed statement?  I can't see how releasing *all* 
 of Tango in PD (or even the runtime, for that matter, but that's up to the 
 devs of the runtime) makes it any more valid.

Sean has emailed me an archive of the code that he owns the rights to. I believe this is probably sufficient to get compatibility, in which case that is plenty good enough.
Aug 14 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:
 
 Sean has emailed me an archive of the code that he owns the rights to. I 
   believe this is probably sufficient to get compatibility, in which 
 case that is plenty good enough.

I'd hate for this thread to end with an apparent resolution only to flair up after another year of no progress. What are the next steps? I assume it'll take a few months to fully integrate the two code bases, but we should be able to know sooner than that if what Sean sent you want enough to integrate the runtimes or not. I assume that the risk of legal taint will prevent you from doing a combined release of dmd v1.x, common runtime, phobos, and tango? Even without that, I assume releasing Tango with the dmd compiler may hamper the overall release process. Even so, once there's a common runtime, it'd be nice if we could have a combined releases of dmd+phobos+tango. If a community member provided a combo release (probably following a Tango release), would you put it up as a downloadable item on the digital mars site?
Aug 15 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Jason House wrote:
 Walter Bright Wrote:
  
 Sean has emailed me an archive of the code that he owns the rights to. I 
   believe this is probably sufficient to get compatibility, in which 
 case that is plenty good enough.

I'd hate for this thread to end with an apparent resolution only to flair up after another year of no progress. What are the next steps? I assume it'll take a few months to fully integrate the two code bases, but we should be able to know sooner than that if what Sean sent you want enough to integrate the runtimes or not. I assume that the risk of legal taint will prevent you from doing a combined release of dmd v1.x, common runtime, phobos, and tango? Even without that, I assume releasing Tango with the dmd compiler may hamper the overall release process. Even so, once there's a common runtime, it'd be nice if we could have a combined releases of dmd+phobos+tango. If a community member provided a combo release (probably following a Tango release), would you put it up as a downloadable item on the digital mars site?

The Tango team has provided such a release for quite a while now. It's the binary release with Tangobos bundled, and includes the latest DMD, Tango, and Phobos (as Tangobos) all in a single package. We could even produce a nightly binary snapshot bundle if anyone cared... right now we're just producing a plain old Tango binary snapshot. Sean
Aug 15 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Walter Bright Wrote:
  
 Sean has emailed me an archive of the code that he owns the rights to. I
   believe this is probably sufficient to get compatibility, in which
 case that is plenty good enough.

I'd hate for this thread to end with an apparent resolution only to flair up after another year of no progress. What are the next steps? I assume it'll take a few months to fully integrate the two code bases, but we should be able to know sooner than that if what Sean sent you want enough to integrate the runtimes or not. I assume that the risk of legal taint will prevent you from doing a combined release of dmd v1.x, common runtime, phobos, and tango? Even without that, I assume releasing Tango with the dmd compiler may hamper the overall release process. Even so, once there's a common runtime, it'd be nice if we could have a combined releases of dmd+phobos+tango. If a community member provided a combo release (probably following a Tango release), would you put it up as a downloadable item on the digital mars site?

There are other compilers than DMD, so I (as the current Tango release manager) see no practical way to coordinate releases of Tango and DMD. Tango bundles latest stable DMD when it is released, and if Tango is ever bundled with DMD, I would assume that to work in the same manner. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 15 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Lars Ivar Igesund Wrote:

 Jason House wrote:
 
 Even so, once there's a common runtime, it'd be nice if we could have a
 combined releases of dmd+phobos+tango.  If a community member provided a
 combo release (probably following a Tango release), would you put it up as
 a downloadable item on the digital mars site?

There are other compilers than DMD, so I (as the current Tango release manager) see no practical way to coordinate releases of Tango and

 Tango bundles latest stable DMD when it is released, and if Tango is ever
 bundled with DMD, I would assume that to work in the same manner.

Yes, that's the way it is now, and it's not something I really expect to change except that the non-runtime phobos pieces would be left in. The key question hidden in my last paragraph is if Walter would treat the Tango bundles as a first-class release of dmd. That means including it for one-click download from the download page with appropriate markings. Maybe using the combined Tango release as the beta version and dmd+phobos as the alpha version? I'm not too sure, but I'd really love to see a commitment to a unified D standard library (even if it bleeding edge releases miss some parts of the standard library)
Aug 15 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 The key question hidden in my last paragraph is if Walter would treat
 the Tango bundles as a first-class release of dmd.  That means
 including it for one-click download from the download page with
 appropriate markings.  Maybe using the combined Tango release as the
 beta version and dmd+phobos as the alpha version?  I'm not too sure,
 but I'd really love to see a commitment to a unified D standard
 library (even if it bleeding edge releases miss some parts of the
 standard library)

At the moment what we are planning to do with the runtime drop Sean provided us is to move towards core api compatibility. It's a good first step.
Aug 15 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Christopher Wright wrote:
 lurker wrote:
 Hullo,

 Thats not happening now or recently. The ball its been rotting in 
 Tango's court for one year plus. This is huge. I might need a couple 
 days to process this information. Naming names is scary but, ..... is 
 Walter saying Kris and Lars "MI Is Evil" Igesund deliberately 
 prevented unification progress?

 One thing for sure.
 assert(cat !in bag);

 -Lurker

Dozens of people have worked on Tango. Tracking who owns the code is nontrivial, as is contacting some of them. It might be impossible to get a license change cleared. Of course, if Walter replaced the Phobos runtime entirely with Tango's, that might not be an issue. But it would involve using the BSD license for those parts.

Tango is actually dual licensed under both the BSD and an artistic license. We had actually considered a public domain license before Tango was announced until it was pointed out (by Thomas Kuehne, I believe) that copyright laws in some countries don't allow public domain as an option and treat such code as if the owner had not licensed it at all. Then we considered the ZLib license because it doesn't require attribution like the BSD license, but there were objections for this being a nonstandard license. So we finally settled on a dual BSD and artistic license to allow Tango to be the most broadly usable. To address the second issue, I think the only practical solution is for Phobos to run on top of the Tango runtime, quite similar to the Tango / Tangobos bundle we already provide. But this is simply my opinion. Sean
Aug 14 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:

 Christopher Wright wrote:
 lurker wrote:
 Hullo,

 Thats not happening now or recently. The ball its been rotting in
 Tango's court for one year plus. This is huge. I might need a couple
 days to process this information. Naming names is scary but, ..... is
 Walter saying Kris and Lars "MI Is Evil" Igesund deliberately
 prevented unification progress?

 One thing for sure.
 assert(cat !in bag);

 -Lurker

Dozens of people have worked on Tango. Tracking who owns the code is nontrivial, as is contacting some of them. It might be impossible to get a license change cleared. Of course, if Walter replaced the Phobos runtime entirely with Tango's, that might not be an issue. But it would involve using the BSD license for those parts.

Tango is actually dual licensed under both the BSD and an artistic license. We had actually considered a public domain license before Tango was announced until it was pointed out (by Thomas Kuehne, I believe) that copyright laws in some countries don't allow public domain as an option and treat such code as if the owner had not licensed it at all. Then we considered the ZLib license because it doesn't require attribution like the BSD license, but there were objections for this being a nonstandard license. So we finally settled on a dual BSD and artistic license to allow Tango to be the most broadly usable.

Academic, not artistic ;) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Lars Ivar Igesund (larsivar igesund.net)'s article
 Sean Kelly wrote:
 Christopher Wright wrote:
 lurker wrote:
 Hullo,

 Thats not happening now or recently. The ball its been rotting in
 Tango's court for one year plus. This is huge. I might need a couple
 days to process this information. Naming names is scary but, ..... is
 Walter saying Kris and Lars "MI Is Evil" Igesund deliberately
 prevented unification progress?

 One thing for sure.
 assert(cat !in bag);

 -Lurker

Dozens of people have worked on Tango. Tracking who owns the code is nontrivial, as is contacting some of them. It might be impossible to get a license change cleared. Of course, if Walter replaced the Phobos runtime entirely with Tango's, that might not be an issue. But it would involve using the BSD license for those parts.

Tango is actually dual licensed under both the BSD and an artistic license. We had actually considered a public domain license before Tango was announced until it was pointed out (by Thomas Kuehne, I believe) that copyright laws in some countries don't allow public domain as an option and treat such code as if the owner had not licensed it at all. Then we considered the ZLib license because it doesn't require attribution like the BSD license, but there were objections for this being a nonstandard license. So we finally settled on a dual BSD and artistic license to allow Tango to be the most broadly usable.


Whatever, the difference is academic ;-) (I am on a roll with the bad jokes lately) Sean
Aug 14 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

I prefer a looser tongue as long as it remains polite. (I consider your posts in this thread to be polite)
Aug 13 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
next sibling parent Helmut Leitner <leitner wikiservice.at> writes:
Lars Ivar Igesund wrote:
 Walter Bright wrote:
I have explained this to the main Tango developers on multiple
occasions. It is their right and privilege to license Tango as they see
fit, and I respect that and so have not spoken out on it before. But in
this thread I am being cast as a roadblock, which I feel is a little
unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

As a peripheral observer I see this partly as a communication problem, which does not put blame on one side or the other (have neither the intention nor the information nor the position to do so) but this doesn't make the problem less serious, quite to the contrary. Primarily I understand Walter. In his position I would really hate to be confronted with individual code contributor's notions, so that the license problem can't be solved for all the affected code and once for all, with a calculable (not a linear) effort. Assuming to understand Walter's character a little, I would think that there are principles of efficiency involved, that are also at the basis of D'S language design that we appreciate, that are not negotiable. Helmut
Aug 14 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.
Aug 14 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit.

No, this is not correct. Neither me nor Kris (who have been the ones involved) have any sort of copyright on the runtime. Sean have, and he has given you this explicit agreemeent. As asserted elsewhere, and by others, the copyrights on the rest of Tango not pertaining to the runtime, is not of relevance. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
next sibling parent superdan <super dan.org> writes:
Lars Ivar Igesund Wrote:

 Walter Bright wrote:
 
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit.

No, this is not correct. Neither me nor Kris (who have been the ones involved) have any sort of copyright on the runtime. Sean have, and he has given you this explicit agreemeent. As asserted elsewhere, and by others, the copyrights on the rest of Tango not pertaining to the runtime, is not of relevance.

cut the oxpoop. `is not of relevance' afforded you to say brad and walter are stealing code from tango. walter is effing right to be pissed. if anyone told me that i'd bury their effing nose in their face. why have you been stalling for a year, lars? time to come clean.
Aug 14 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:g813qj$amf$2 digitalmars.com...
 Walter Bright wrote:

 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit.

No, this is not correct. Neither me nor Kris (who have been the ones involved) have any sort of copyright on the runtime. Sean have, and he has given you this explicit agreemeent. As asserted elsewhere, and by others, the copyrights on the rest of Tango not pertaining to the runtime, is not of relevance.

Slightly OT, and directed at this whole situation: I just sit back and laugh. *This* is open-source software? *This* is the supposed "freedom" and "openness" that the whole movement is about? People bickering for a _year_ over minutiae of licenses which are supposed to promote free use? What have we accomplished?
Aug 14 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Jarrett Billingsley wrote:
 
 Slightly OT, and directed at this whole situation: I just sit back and 
 laugh.  *This* is open-source software?  *This* is the supposed "freedom" 
 and "openness" that the whole movement is about?  People bickering for a 
 _year_ over minutiae of licenses which are supposed to promote free use?
 
 What have we accomplished? 
 
 

Someone once told me that the place with the most politics is academia. the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?! the problem with OSS is that it's free. if it where closed than it would be a matter of the amount of money which can be negotiated and agree upon. OSS is free therefore the only thing that matters is one's pride and that cannot be negotiated. In this Specific case: Walter needs his name on all the Phobos code and he stated his valid reasons for it. Tango developers want their names on the Tango code and rightly so, since they wrote it. in case of a merger of those two code bases you get one joint code base but *two* teams that want their name on the code. someone has to be first. all I can say is that I hope this gets resolved soon for the benefit of everyone here.
Aug 14 2008
next sibling parent Dee Girl <deegirl noreply.com> writes:
Yigal Chripun Wrote:

 Jarrett Billingsley wrote:
 
 Slightly OT, and directed at this whole situation: I just sit back and 
 laugh.  *This* is open-source software?  *This* is the supposed "freedom" 
 and "openness" that the whole movement is about?  People bickering for a 
 _year_ over minutiae of licenses which are supposed to promote free use?
 
 What have we accomplished? 
 
 

Someone once told me that the place with the most politics is academia. the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?! the problem with OSS is that it's free. if it where closed than it would be a matter of the amount of money which can be negotiated and agree upon. OSS is free therefore the only thing that matters is one's pride and that cannot be negotiated. In this Specific case: Walter needs his name on all the Phobos code and he stated his valid reasons for it. Tango developers want their names on the Tango code and rightly so, since they wrote it. in case of a merger of those two code bases you get one joint code base but *two* teams that want their name on the code. someone has to be first. all I can say is that I hope this gets resolved soon for the benefit of everyone here.

I do not know any thing about this. I am sorry if this does not help. I have algorithm.d open in my editor. I see this * Copyright (C) 2004-2006 by Digital Mars, www.digitalmars.com * Written by Andrei Alexandrescu, www.erdani.org Maybe it is because Andrei works for Digital Mars also? I do not know. What I see is Walter name is not in this file at all. If this is mistake please ignore. Thank you, Dee Girl
Aug 14 2008
prev sibling next sibling parent superdan <super dan.org> writes:
Yigal Chripun Wrote:

 Jarrett Billingsley wrote:
 
 Slightly OT, and directed at this whole situation: I just sit back and 
 laugh.  *This* is open-source software?  *This* is the supposed "freedom" 
 and "openness" that the whole movement is about?  People bickering for a 
 _year_ over minutiae of licenses which are supposed to promote free use?
 
 What have we accomplished? 
 
 

Someone once told me that the place with the most politics is academia. the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?!

intercourse yeah. applies to any place with low stakes. the lower the stakes the weirder the contest. when i worked for intel i visited their facilities in india. long story. so there's these two young brothers heading the office in b'lore. i got to hang out with them for a while. they were first generation in their family to ever wear shoes and prolly their kids would be the first generation to not shit in the street. and they was rich by indian std. now each dood drove a mercedes from intel as a work perk. they didn't own the cars. that's how it works there. identical so far as i could tell. and after a month on indian roads all cars look the same. but i digress. so i get them a bit drunk (easy but i digress again) and their insecurities come fore. guess what was their problem. one said his merc is longer than his brothers'. the morons really start to quarrel. finally they get to the parking lot and start drawing signs in the dirt and measure stuff. i kid you not. one actually does win by 3cm. must've been diff in the bumper n mask paraphernalia. the other's pissed. it was priceless. i should've shot the whole thing on tape.
 the problem with OSS is that it's free. if it where closed than it would
 be a matter of the amount of money which can be negotiated and agree upon.
 OSS is free therefore the only thing that matters is one's pride and
 that cannot be negotiated.
 
 
 In this Specific case:
 Walter needs his name on all the Phobos code and he stated his valid
 reasons for it. Tango developers want their names on the Tango code and
 rightly so, since they wrote it. in case of a merger of those two code
 bases you get one joint code base but *two* teams that want their name
 on the code. someone has to be first.
 
 all I can say is that I hope this gets resolved soon for the benefit of
 everyone here.

still tryin' to figure what interests are at play here. who cares about what? and who wants what? no idea. not holding my breath on resolving. they've been at it for a year.
Aug 14 2008
prev sibling next sibling parent reply Sean Reque <seanthenewt yahoo.com> writes:
Yigal Chripun Wrote:

 Jarrett Billingsley wrote:
 
 Slightly OT, and directed at this whole situation: I just sit back and 
 laugh.  *This* is open-source software?  *This* is the supposed "freedom" 
 and "openness" that the whole movement is about?  People bickering for a 
 _year_ over minutiae of licenses which are supposed to promote free use?
 
 What have we accomplished? 
 
 

Someone once told me that the place with the most politics is academia. the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?! the problem with OSS is that it's free. if it where closed than it would be a matter of the amount of money which can be negotiated and agree upon. OSS is free therefore the only thing that matters is one's pride and that cannot be negotiated. In this Specific case: Walter needs his name on all the Phobos code and he stated his valid reasons for it. Tango developers want their names on the Tango code and rightly so, since they wrote it. in case of a merger of those two code bases you get one joint code base but *two* teams that want their name on the code. someone has to be first. all I can say is that I hope this gets resolved soon for the benefit of everyone here.

If I understand correctly, this is an issue not for political reasons, but for legal and economic ones. Digital Mars as a company has to convince the corporate world that they can use the D tools offered without any legal ramifications. I do not see where pride is involved at all, at least on Walter's side. He said he has already given the Tango developers license to use re-license (Phobos?) code how they see fit, and is waiting for the same permission in return. Sean Reque
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Reque" wrote
 Yigal Chripun Wrote:

 Jarrett Billingsley wrote:
 Slightly OT, and directed at this whole situation: I just sit back and
 laugh.  *This* is open-source software?  *This* is the supposed 
 "freedom"
 and "openness" that the whole movement is about?  People bickering for 
 a
 _year_ over minutiae of licenses which are supposed to promote free 
 use?

 What have we accomplished?

Someone once told me that the place with the most politics is academia. the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?! the problem with OSS is that it's free. if it where closed than it would be a matter of the amount of money which can be negotiated and agree upon. OSS is free therefore the only thing that matters is one's pride and that cannot be negotiated. In this Specific case: Walter needs his name on all the Phobos code and he stated his valid reasons for it. Tango developers want their names on the Tango code and rightly so, since they wrote it. in case of a merger of those two code bases you get one joint code base but *two* teams that want their name on the code. someone has to be first. all I can say is that I hope this gets resolved soon for the benefit of everyone here.

If I understand correctly, this is an issue not for political reasons, but for legal and economic ones. Digital Mars as a company has to convince the corporate world that they can use the D tools offered without any legal ramifications. I do not see where pride is involved at all, at least on Walter's side. He said he has already given the Tango developers license to use re-license (Phobos?) code how they see fit, and is waiting for the same permission in return.

I don't know the details of the license that Walter gave to the Tango devs, but according to Phobos' license, no explicit permission is needed as long as you obey the license terms (which is pretty free in its terms), and in fact, Tango has the Phobos license in the runtime anyways, and obeys the license that ships with Phobos. So I don't see how it is relevant that Walter gave a specific license to Tango, it was not required (at least that's my understanding). It should be the same thing for Walter to accept Tango's modified version of the runtime (just include a copy of Tango's license). My understanding is that Walter is against doing that for the purpose of avoiding having 2 licenses in phobos. Both licenses are very similar, and completely compatible. I see that Walter doesn't like it, but I don't see why it is a problem? Perhaps you could elaborate more, Walter. Also, I would like to know specifically what Walter needs from the Tango team. What could it be that he needs that the Tango team is against? -Steve
Aug 14 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Sean Reque" wrote
 Yigal Chripun Wrote:

 Jarrett Billingsley wrote:
 Slightly OT, and directed at this whole situation: I just sit back and
 laugh.  *This* is open-source software?  *This* is the supposed 
 "freedom"
 and "openness" that the whole movement is about?  People bickering for 
 a
 _year_ over minutiae of licenses which are supposed to promote free 
 use?

 What have we accomplished?

the professors have so little decision power that they argue (intensely) about the smallest and stupidest of things. I guess you can say the same thing here: all the code is "open" and therefore everyone argues about the smallest details left to argue about like who's name is written on the copyright (and in what order) and stuff like that. besides, how can a person steal free code?! the problem with OSS is that it's free. if it where closed than it would be a matter of the amount of money which can be negotiated and agree upon. OSS is free therefore the only thing that matters is one's pride and that cannot be negotiated. In this Specific case: Walter needs his name on all the Phobos code and he stated his valid reasons for it. Tango developers want their names on the Tango code and rightly so, since they wrote it. in case of a merger of those two code bases you get one joint code base but *two* teams that want their name on the code. someone has to be first. all I can say is that I hope this gets resolved soon for the benefit of everyone here.

for legal and economic ones. Digital Mars as a company has to convince the corporate world that they can use the D tools offered without any legal ramifications. I do not see where pride is involved at all, at least on Walter's side. He said he has already given the Tango developers license to use re-license (Phobos?) code how they see fit, and is waiting for the same permission in return.

I don't know the details of the license that Walter gave to the Tango devs, but according to Phobos' license, no explicit permission is needed as long as you obey the license terms (which is pretty free in its terms)

Walter has been updating to the PD license in modules when has has some reason to modify them for code changes, so many modules retained a BSD license until recently (in fact, I think some still may). One of the first things I did with Tango was to try and normalize the license documentation in the runtime to make things easier to deal with. Fortunately, since Tango is dual licensed under BSD it was easy enough to use a common license for everything and make sure that Walter was listed as the copyright owner. I don't actually recall offhand if the modules are still BSD only or dual-licensed, but since Walter has given us rights to the code I suppose it no longer matters--with it, the artistic license should no longer conflict with any lingering BSD license requirements in Phobos. Sean
Aug 14 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I don't know the details of the license that Walter gave to the Tango devs, 

It's as I posted here. Tango may use any part of Phobos and *relicense* it under the Tango license that I have the power to do.
 but according to Phobos' license, no explicit permission is needed as long 
 as you obey the license terms (which is pretty free in its terms), and in 
 fact, Tango has the Phobos license in the runtime anyways, and obeys the 
 license that ships with Phobos.  So I don't see how it is relevant that 
 Walter gave a specific license to Tango, it was not required (at least 
 that's my understanding).  It should be the same thing for Walter to accept 
 Tango's modified version of the runtime (just include a copy of Tango's 
 license).  My understanding is that Walter is against doing that for the 
 purpose of avoiding having 2 licenses in phobos.  Both licenses are very 
 similar, and completely compatible.  I see that Walter doesn't like it, but 
 I don't see why it is a problem?  Perhaps you could elaborate more, Walter.

I don't know what more needs to be elaborated. There are two reasons for this: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code.
 Also, I would like to know specifically what Walter needs from the Tango 
 team.  What could it be that he needs that the Tango team is against?

What specifically I'd like from the Tango team is explicit permission for the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license. I have already provided a reciprocal agreement for the Tango team to use Phobos.
Aug 14 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Steven Schveighoffer wrote:
 I don't know the details of the license that Walter gave to the Tango 
 devs,

It's as I posted here. Tango may use any part of Phobos and *relicense* it under the Tango license that I have the power to do.
 but according to Phobos' license, no explicit permission is needed as 
 long as you obey the license terms (which is pretty free in its terms), 
 and in fact, Tango has the Phobos license in the runtime anyways, and 
 obeys the license that ships with Phobos.  So I don't see how it is 
 relevant that Walter gave a specific license to Tango, it was not 
 required (at least that's my understanding).  It should be the same thing 
 for Walter to accept Tango's modified version of the runtime (just 
 include a copy of Tango's license).  My understanding is that Walter is 
 against doing that for the purpose of avoiding having 2 licenses in 
 phobos.  Both licenses are very similar, and completely compatible.  I 
 see that Walter doesn't like it, but I don't see why it is a problem? 
 Perhaps you could elaborate more, Walter.

I don't know what more needs to be elaborated. There are two reasons for this: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code.

Easy. Don't say you wrote the Tango portions :) Both Tango and Phobos are well established, it is not like you are starting from scratch, and especially, both are maintained in SVN on a third-party site, so it is easy to see who wrote what when. I think you need to give a little on this...
 2. To avoid the untenable issue of a single module in Phobos having 
 different license for different lines of code.

Different *lines* of code? There is no reason to do that. Keep the license per module. If you make changes in a module that was licensed under Tango only, leave the license there. From my understanding, any code that Tango used from Phobos still has the original license that Phobos provided. I don't see a problem with that model.
 Also, I would like to know specifically what Walter needs from the Tango 
 team.  What could it be that he needs that the Tango team is against?

What specifically I'd like from the Tango team is explicit permission for the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license.

What is wrong with giving you permission to go over a given list of files that are specifically owned by people who don't mind you using their code? This should be adequate for creating a common core, as the core modules are well separated from the user portions. And why must they be relicensed? I don't really understand that part (but from Sean's messages, it looks like you already have that permission). What if someone gathered all the appropriate files together in a single package, and had the Tango developers sign off that Sean was the sole owner of the files in that package? Would that be enough?
 I have already provided a reciprocal agreement for the Tango team to use 
 Phobos.

Again, if this is the case, it was not used, because all of the Phobos-originated code (that I looked at anyways) still is licensed under the Phobos license. -Steve
Aug 14 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Steven Schveighoffer wrote:

 Also, I would like to know specifically what Walter needs from the Tango 
 team.  What could it be that he needs that the Tango team is against?

the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license.

What is wrong with giving you permission to go over a given list of files that are specifically owned by people who don't mind you using their code? This should be adequate for creating a common core, as the core modules are well separated from the user portions. And why must they be relicensed? I don't really understand that part (but from Sean's messages, it looks like you already have that permission).

I believe the issue is fear of "taint." In short, if Walter so much as glances at a module and it turns out that one of the authors isn't someone who has licensed his code to Walter then he could later accuse Walter of violating his copyright simply because something in Walters code looked vaguely similar. It's why Walter has never looked at GDC, for example, since he is in the business of writing compilers. Personally, I think copyright law is utterly ridiculous, but what can you do.
 What if someone gathered all the appropriate files together in a single 
 package, and had the Tango developers sign off that Sean was the sole owner 
 of the files in that package?  Would that be enough?

I actually send Walter a bundled copy of the Tango runtime years ago for just this reason, and didn't realize that Walter had never looked at it until probably a year later when Walter said he'd never looked at Tango at all. Sean
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Steven Schveighoffer wrote:

 Also, I would like to know specifically what Walter needs from the 
 Tango team.  What could it be that he needs that the Tango team is 
 against?

for the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license.

What is wrong with giving you permission to go over a given list of files that are specifically owned by people who don't mind you using their code? This should be adequate for creating a common core, as the core modules are well separated from the user portions. And why must they be relicensed? I don't really understand that part (but from Sean's messages, it looks like you already have that permission).

I believe the issue is fear of "taint." In short, if Walter so much as glances at a module and it turns out that one of the authors isn't someone who has licensed his code to Walter then he could later accuse Walter of violating his copyright simply because something in Walters code looked vaguely similar. It's why Walter has never looked at GDC, for example, since he is in the business of writing compilers. Personally, I think copyright law is utterly ridiculous, but what can you do.

Copyright law is not that rediculous (aside from the US DMCA). Looking at code and then writing something that uses the same ideas as the code is not a copyright violation. Possibly a patent violation, but that is only if your country has software patents (which, sadly, mine does), and you are not protected from patent infringements even if you *don't* look at the code. You don't copyright the ideas, you copyright the literal text of the code itself (and the exact bytes of the binary). But in this instance, you WANT the code to be identical because you want it to be compatible. Yet there should be no issue because the code is open source. Many many companies use open source software and have no problems because they attribute credit where credit is due. This should be no different. Not looking at the Tango runtime source because some random contributor who has nothing to do with Tango's runtime might try to sue Walter (for what, I can't imagine), is sort of like not ever trying to walk for fear you might fall down and break an arm. I think, after reading all this stuff, that Tango has minimalized the risk to a very tiny reasonable level, and it is up to Walter to take the steps to actually make the change possible. The only further right that Walter gains with having Tango code in the public domain is to claim credit for their work. So I tend to agree with those who don't want their code released as PD. -Steve
Aug 14 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 "Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Steven Schveighoffer wrote:

 Also, I would like to know specifically what Walter needs from the
 Tango team.  What could it be that he needs that the Tango team is
 against?

for the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license.

What is wrong with giving you permission to go over a given list of files that are specifically owned by people who don't mind you using their code? This should be adequate for creating a common core, as the core modules are well separated from the user portions. And why must they be relicensed? I don't really understand that part (but from Sean's messages, it looks like you already have that permission).

I believe the issue is fear of "taint." In short, if Walter so much as glances at a module and it turns out that one of the authors isn't someone who has licensed his code to Walter then he could later accuse Walter of violating his copyright simply because something in Walters code looked vaguely similar. It's why Walter has never looked at GDC, for example, since he is in the business of writing compilers. Personally, I think copyright law is utterly ridiculous, but what can you do.

code and then writing something that uses the same ideas as the code is not a copyright violation. Possibly a patent violation, but that is only if your country has software patents (which, sadly, mine does), and you are not protected from patent infringements even if you *don't* look at the code. You don't copyright the ideas, you copyright the literal text of the code itself (and the exact bytes of the binary). But in this instance, you WANT the code to be identical because you want it to be compatible. Yet there should be no issue because the code is open source. Many many companies use open source software and have no problems because they attribute credit where credit is due. This should be no different. Not looking at the Tango runtime source because some random contributor who has nothing to do with Tango's runtime might try to sue Walter (for what, I can't imagine), is sort of like not ever trying to walk for fear you might fall down and break an arm. I think, after reading all this stuff, that Tango has minimalized the risk to a very tiny reasonable level, and it is up to Walter to take the steps to actually make the change possible. The only further right that Walter gains with having Tango code in the public domain is to claim credit for their work. So I tend to agree with those who don't want their code released as PD.

For what it's worth, if having compatible runtimes is the only issue then I do maintain a "standard" of sorts that outlines the public interfaces the runtime libraries must provide: http://dsource.org/projects/tango/wiki/LibraryIntegrationGuide I've mentioned this to Walter et al. in the past, but no one seemed interested. Can't say I understand the reasoning, but what can you do. Sean
Aug 14 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Steven Schveighoffer wrote:
 Copyright law is not that rediculous (aside from the US DMCA).

constitution. Sadly, I don't see any public outcry against this and other laws like eavesdropping without a court order and other violations of basic rights as written in the constitution. Should I care for this really sad situation in which "the greatest democracy" is in? unfortunately the answer is yes because the US government influences and puts pressure on other countries to adjust to their view and thus indirectly influences our local laws. This is evident in the raid on the pirate bay's servers which was illegal according to local law and was done due to pressure from the US administration. our local copyright law was recently changed to be more like the US one, due to similar reasons.
Aug 14 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Yigal Chripun Wrote:

 Steven Schveighoffer wrote:
  > Copyright law is not that rediculous (aside from the US DMCA).
 US DMCA is not only ridiculous but also illegal since it violates the US
  constitution. Sadly, I don't see any public outcry against this and
 other laws like eavesdropping without a court order and other violations
 of basic rights as written in the constitution. Should I care for this
 really sad situation in which "the greatest democracy" is in?
 unfortunately the answer is yes because the US government influences and
 puts pressure on other countries to adjust to their view and thus
 indirectly influences our local laws.
 This is evident in the raid on the pirate bay's servers which was
 illegal according to local law and was done due to pressure from the US
 administration.
 our local copyright law was recently changed to be more like the US one,
  due to similar reasons.

I've had very mixed feelings about all this. One one hand, the letter of the law may be questionably constitutional. But millions of dollars every day are lost because people (including myself occasionally...) steal copyrighted material. Honestly, I think there should be much stricter penalties for things like internet piracy, because it's simply so widespread and damaging.
Aug 14 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Robert Fraser wrote:
 I've had very mixed feelings about all this. One one hand, the letter

 law may be questionably constitutional. But millions of dollars every day are
 lost because people (including myself occasionally...) steal copyrighted
 material. Honestly, I think there should be much stricter penalties for
 things like internet piracy, because it's simply so widespread and damaging.

Of course you have the right to have your own opinion (that's also in the constitution) but all of the above is bullshit. (sorry for the language). stealing only applies to physical things like chairs and cars. that whole metaphor of information as physical entities is wrong. you sure can infringe someone's copyrights but you cannot steal anything since there's nothing to steal. Now that we cleared that out of the way, let's touch other nonsenses in what you wrote: A) "millions of dollars every day are lost..." - Not true. you assume that if a person doesn't pirate he would have payed for the stuff. this is a wrong assumption since the majority of people would just use other alternatives. if I wouldn't be able to pirate MS office I'd probably search for a cheap commercial solution or install Open Office which is good enough for me and most other private people and small companies. no one in their right mind would pay 500$ for an office suit. think globally: in US standards paying for software is not that expensive and is convenient (and you pay for that as well) but for most of the world those prices are high. in Israel 500$ translates to roughly 2000 NIS which is a lot. B)"it's simply so ... damaging" - not so. If you look at music and films than the image is backwards: since it's easy to pirate I can download a lot of stuff try it out and only keep what I like. If I like it I'll tell friends and more people will be exposed to the content. pirating actually makes money for the copyright holder and helps him get recognized since it's advertising they don't need to pay for. If what you said was true than Red Hat and Novel wouldn't lasted more than a day. after all you can legally download their products from their respective websites! The issue is not whether piracy is moral or not. it's a fact of life - the internet provides an efficient means for distribution of information. either you take advantage of it or you insist on your old irrelevant business model and go extinct. business 101 - "The customer is always right." the moment they (RIAA, MPAA, etc..) broke that rule because they refused to evolve with respect to new technology and business models is the moment they signed their death warrants. I prefer supporting music artists by going to a concert and paying 100$ for a ticket rather than paying for CDs with shitty music the records companies advertise and try to stick in my throat. one last thing, before suggesting more penalties and such please read the following: http://www.gnu.org/philosophy/right-to-read.html *after* reading this, are you sure still that this is the way to go?
Aug 14 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Yigal Chripun Wrote:

 Robert Fraser wrote:
  > I've had very mixed feelings about all this. One one hand, the letter
 of the
 law may be questionably constitutional. But millions of dollars every day are
 lost because people (including myself occasionally...) steal copyrighted
 material. Honestly, I think there should be much stricter penalties for
 things like internet piracy, because it's simply so widespread and damaging.

Of course you have the right to have your own opinion (that's also in the constitution) but all of the above is bullshit. (sorry for the language). stealing only applies to physical things like chairs and cars. that whole metaphor of information as physical entities is wrong. you sure can infringe someone's copyrights but you cannot steal anything since there's nothing to steal.

Some philosopher said that all philosophical debates were inherently linguistic ones that stemmed from not having the words to represent the concepts being spoken about. We're using different definitions of "steal," but the concept is clear -- it's taking something you don't have the right to have taken without paying for, and the debate is over whether you do or should have that right.
 Now that we cleared that out of the way, let's touch other nonsenses in
 what you wrote:
 
 A) "millions of dollars every day are lost..." - Not true. you assume
 that if a person doesn't pirate he would have payed for the stuff. this
 is a wrong assumption since the majority of people would just use other
 alternatives.

Sure not everyone would have paid. But at least one person would have paid. Back in high school, I would have paid for a lot of the music I downloaded (perhaps not all of it) -- but I didn't since it was so easy for me to pirate it. The statement is that piracy costs at least $1 million/day in LOST SALES; if you would have used a free alternative, that's not factored into the argument.
 if I wouldn't be able to pirate MS office 

Mah paycheck!!! (that's paying me to post on D NGs...)
 I'd probably
 search for a cheap commercial solution or install Open Office which is
 good enough for me and most other private people and small companies. no
 one in their right mind would pay 500$ for an office suit. think
 globally: in US standards paying for software is not that expensive and
 is convenient (and you pay for that as well) but for most of the world
 those prices are high. in Israel 500$ translates to roughly 2000 NIS
 which is a lot.
 B)"it's simply so ... damaging" - not so.
 If you look at music and films than the image is backwards: since it's
 easy to pirate I can download a lot of stuff try it out and only keep
 what I like. If I like it I'll tell friends and more people will be
 exposed to the content. pirating actually makes money for the copyright
 holder and helps him get recognized since it's advertising they don't
 need to pay for.

I'm going to cry bull**** here. Quite a few sites offer legit free music/ video. The content creators/producers have made this available for precisely the reason you said -- so people view it and tell their friends or choose to buy higher-quality versions of it. The stuff they DON'T make available for free is not there because it is more profitable for them not to make it available. The creators/producers choose what to share for free -- NOT the consumers.
 If what you said was true than Red Hat and Novel wouldn't lasted more
 than a day. after all you can legally download their products from their
  respective websites!

Their business model is to make money off the support for their software, not the software itself.
 The issue is not whether piracy is moral or not. it's a fact of life -
 the internet provides an efficient means for distribution of
 information. either you take advantage of it or you insist on your old
 irrelevant business model and go extinct. 

Selling software/music/video/intellectual property for money is an extinct business model...? If that's your argument then o_O.
 business 101 - "The customer
 is always right." the moment they (RIAA, MPAA, etc..) broke that rule
 because they refused to evolve with respect to new technology and
 business models is the moment they signed their death warrants.
 
 I prefer supporting music artists by going to a concert and paying 100$
 for a ticket rather than paying for CDs with shitty music the records
 companies advertise and try to stick in my throat.
 
 one last thing, before suggesting more penalties and such please read
 the following: http://www.gnu.org/philosophy/right-to-read.html
 *after* reading this, are you sure still that this is the way to go?

I think what a lot of these arguments boil down to is people trying to justify taking stuff without paying for it. Plain and simple. I do on occasion download videos (these days only anime fansubs). And I don't feel bad about it. But I do know it's stealing. Downloading a $10 CD is really no better than shoplifting a $10 CD, because the people who worked to bring that CD into existence are not being paid for it.
Aug 14 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Warning: this can turn into a long debate...

Robert Fraser wrote:
 Yigal Chripun Wrote:
 
 Robert Fraser wrote:
  > I've had very mixed feelings about all this. One one hand, the letter
 of the
 law may be questionably constitutional. But millions of dollars every day are
 lost because people (including myself occasionally...) steal copyrighted
 material. Honestly, I think there should be much stricter penalties for
 things like internet piracy, because it's simply so widespread and damaging.

the constitution) but all of the above is bullshit. (sorry for the language). stealing only applies to physical things like chairs and cars. that whole metaphor of information as physical entities is wrong. you sure can infringe someone's copyrights but you cannot steal anything since there's nothing to steal.

Some philosopher said that all philosophical debates were inherently linguistic ones that stemmed from not having the words to represent the concepts being spoken about. We're using different definitions of "steal," but the concept is clear -- it's taking something you don't have the right to have taken without paying for, and the debate is over whether you do or should have that right.

I won't argue about wording and linguistics with you. this would be just silly. I'll simply agree that my definition of what stilling is differs from yours. I do disagree on one thing though: everything in life is a balance and a compromise. Democracy is a compromise between the rights of the individual and that of the community he belongs to, for one example. this notion of compromise is inherit in our discussion as well: on the one hand we have the right of the content creator to do what he wants with his creation and on the other hand we have the right of the public to access that creation. So we disagree on where the balance lies. However, please do not claim "it's taking something you don't have the right to have taken" since that right is also is present.
 
 Now that we cleared that out of the way, let's touch other nonsenses in
 what you wrote:

 A) "millions of dollars every day are lost..." - Not true. you assume
 that if a person doesn't pirate he would have payed for the stuff. this
 is a wrong assumption since the majority of people would just use other
 alternatives.

Sure not everyone would have paid. But at least one person would have paid. Back in high school, I would have paid for a lot of the music I downloaded (perhaps not all of it) -- but I didn't since it was so easy for me to pirate it. The statement is that piracy costs at least $1 million/day in LOST SALES; if you would have used a free alternative, that's not factored into the argument.

Hence, that statement is flawed since the vast majority of people would *NOT* have bought the content in question.
 
 if I wouldn't be able to pirate MS office 

Mah paycheck!!! (that's paying me to post on D NGs...)
 I'd probably
 search for a cheap commercial solution or install Open Office which is
 good enough for me and most other private people and small companies. no
 one in their right mind would pay 500$ for an office suit. think
 globally: in US standards paying for software is not that expensive and
 is convenient (and you pay for that as well) but for most of the world
 those prices are high. in Israel 500$ translates to roughly 2000 NIS
 which is a lot.
 B)"it's simply so ... damaging" - not so.
 If you look at music and films than the image is backwards: since it's
 easy to pirate I can download a lot of stuff try it out and only keep
 what I like. If I like it I'll tell friends and more people will be
 exposed to the content. pirating actually makes money for the copyright
 holder and helps him get recognized since it's advertising they don't
 need to pay for.

I'm going to cry bull**** here. Quite a few sites offer legit free music/ video. The content creators/producers have made this available for precisely the reason you said -- so people view it and tell their friends or choose to buy higher-quality versions of it. The stuff they DON'T make available for free is not there because it is more profitable for them not to make it available. The creators/producers choose what to share for free -- NOT the consumers.

As I said above, it's all a matter of balance: people are willing to pay for the _convenience_ of being able to download music online in good [lossless probably] quality. people are also willing to buy merchandise to support their favorite artist and of course, people are willing to pay to attend a concert/performance/etc of the artist. Those are all logical business models. however, people *aren't* willing to pay for the /right/ to download music. Where's the balance? simple - The record companies where selling us a cat in the bag for years and demanding us to pay again {and a larger sum at that] each time they switch formats. That's unacceptable to me. I am willing to pay for the convenience of an online service if that service was in fact convenient and I could get a feeling what I'm paying for. This does not mean DRM [this is finally dawned upon the companies]. A consumer expects that just like when he buys a car where he can drive it on what ever road he wants, the same would happen with the music. Since Apple allow for non-drm music in itunes - this is the last thing that needs to change in order for me to buy my music there. (also, I think the price is a bit high but that's just a matter of pricing which is solved by market forces) As soon as those online service evolve into something that is really convenient there will be no reason for the average user to want to pirate. pirating will never completely disappear but they'll be a minor thing.
 If what you said was true than Red Hat and Novel wouldn't lasted more
 than a day. after all you can legally download their products from their
  respective websites!

Their business model is to make money off the support for their software, not the software itself.

exactly. just one of the million posibilities of viable business models that do not equate the consumer and end user of the product to thieves, pirates and sinners in general.
 
 The issue is not whether piracy is moral or not. it's a fact of life -
 the internet provides an efficient means for distribution of
 information. either you take advantage of it or you insist on your old
 irrelevant business model and go extinct. 

Selling software/music/video/intellectual property for money is an extinct business model...? If that's your argument then o_O.

That's partly my argument. When was the last time you used a telegraph? That technology was replaced be better technologies. So what what about all those people that where trained with Morse code and telegraph equipment? Should the government force us to use telegraphs in order for them to keep their jobs? What about silent film actors? today actors are required to be able to speak properly as part of their profession, So what about all those actors that cannot speak properly? There are of course more examples where a new technology deprecated some profession or job. Same goes for all the jobs at record companies - they are unneeded and the record company itself is redundant in a world where the artist can create he's work alone and reach his audience directly via the web.
 
 business 101 - "The customer
 is always right." the moment they (RIAA, MPAA, etc..) broke that rule
 because they refused to evolve with respect to new technology and
 business models is the moment they signed their death warrants.

 I prefer supporting music artists by going to a concert and paying 100$
 for a ticket rather than paying for CDs with shitty music the records
 companies advertise and try to stick in my throat.

 one last thing, before suggesting more penalties and such please read
 the following: http://www.gnu.org/philosophy/right-to-read.html
 *after* reading this, are you sure still that this is the way to go?

I think what a lot of these arguments boil down to is people trying to justify taking stuff without paying for it. Plain and simple. I do on occasion download videos (these days only anime fansubs). And I don't feel bad about it. But I do know it's stealing. Downloading a $10 CD is really no better than shoplifting a $10 CD, because the people who worked to bring that CD into existence are not being paid for it.

Aug 14 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Yigal Chripun wrote:
 Warning: this can turn into a long debate...

Eh; I'm enjoying it ;-P. Gives a good break from Windows Forms.
 Democracy is a compromise between the rights
 of the individual and that of the community he belongs to, for one
 example. this notion of compromise is inherit in our discussion as well:
 on the one hand we have the right of the content creator to do what he
 wants with his creation and on the other hand we have the right of the
 public to access that creation.

Indeed, the discussion is about that right.
 A) "millions of dollars every day are lost..." - Not true. you assume
 that if a person doesn't pirate he would have payed for the stuff. this
 is a wrong assumption since the majority of people would just use other
 alternatives.

paid. Back in high school, I would have paid for a lot of the music I downloaded (perhaps not all of it) -- but I didn't since it was so easy for me to pirate it. The statement is that piracy costs at least $1 million/day in LOST SALES; if you would have used a free alternative, that's not factored into the argument.

Hence, that statement is flawed since the vast majority of people would *NOT* have bought the content in question.

No, _TAKING INTO ACCOUNT_ that some people would not have gotten the content "legally" and some would, I believe there's still over $1 million/day lost through piracy. Obviously, there's no way to measure this. Can we agree that there is at least one person who downloaded some content and if he had not been able to that he would have BOUGHT the content. If so, then there is a lost sale.
 As I said above, it's all a matter of balance:
 people are willing to pay for the _convenience_ of being able to
 download music online in good [lossless probably] quality. people are
 also willing to buy merchandise to support their favorite artist and of
 course, people are willing to pay to attend a concert/performance/etc of
 the artist. Those are all logical business models. however, people
 *aren't* willing to pay for the /right/ to download music.

Right, and that's the problem ;-P. There are also people who will go into an electronics store and aren't willing to pay for the right to use a certain MP3 player so walk out with it under their shirt.
 Where's the balance? simple - The record companies where selling us a
 cat in the bag for years and demanding us to pay again {and a larger sum
 at that] each time they switch formats. That's unacceptable to me. I am
 willing to pay for the convenience of an online service if that service
 was in fact convenient and I could get a feeling what I'm paying for.
 This does not mean DRM [this is finally dawned upon the companies]. A
 consumer expects that just like when he buys a car where he can drive it
 on what ever road he wants, the same would happen with the music.
 Since Apple allow for non-drm music in itunes - this is the last thing
 that needs to change in order for me to buy my music there. (also, I
 think the price is a bit high but that's just a matter of pricing which
 is solved by market forces)
 As soon as those online service evolve into something that is really
 convenient there will be no reason for the average user to want to
 pirate. pirating will never completely disappear but they'll be a minor
 thing.

 Selling software/music/video/intellectual property for money is an extinct
 business model...? If that's your argument then o_O.

That's partly my argument. When was the last time you used a telegraph? That technology was replaced be better technologies. So what what about all those people that where trained with Morse code and telegraph equipment? Should the government force us to use telegraphs in order for them to keep their jobs? What about silent film actors? today actors are required to be able to speak properly as part of their profession, So what about all those actors that cannot speak properly? There are of course more examples where a new technology deprecated some profession or job. Same goes for all the jobs at record companies - they are unneeded and the record company itself is redundant in a world where the artist can create he's work alone and reach his audience directly via the web.

There's already good DRM-free music sites (eMusic is one; Zune store is about half DRM-free and has an unlimited subscription plan). For video, most TV stations in the US provide free streams of their popular shows now, and Netflix has a good portion of its content available for streaming/instant-viewing. Many games are available for download via Direct2Drive, Steam, etc., and most productivity software is now licensed online so you never have to even go to the store. All this stuff is just as easy as piracy, the difference is you have to pay. Point: there are many paid alternatives that provide the same quality of experience that piracy does. People don't use them because they have to pay. Arguing "it's a better experience if you pirate" may have been valid 5 years ago, but it's not today. Anyways, music is a pretty bad example, since most online music sites are crap, record companies don't pay artists well, etc., etc. Let's restrict our domain to software, since we're both creators of software (I'm guessing) and it's our work that's being ripped off. Say you quit your day job, took out a loan, and spent two years, 10 hours a day developing a Photoshop-killer. Would you think people had the right to use it without paying you?
Aug 14 2008
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Brad Roberts wrote:
 <snip thread arguing both sides of the is there such a thing as IP>
 
 Guys.. I highly suggest just dropping this part of the thread.  Neither
 side will ever change the mind of the other.  It's a waste of time and
 energy.
 
 Later,
 Brad

Sure IP exists. How could we communicate here otherwise? ;)
Aug 15 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Yigal Chripun wrote:
 Brad Roberts wrote:
 <snip thread arguing both sides of the is there such a thing as IP>

 Guys.. I highly suggest just dropping this part of the thread.  Neither
 side will ever change the mind of the other.  It's a waste of time and
 energy.

 Later,
 Brad

Sure IP exists. How could we communicate here otherwise? ;)

With tubes of course... -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Brad Roberts wrote:
 <snip thread arguing both sides of the is there such a thing as IP>
 
 Guys.. I highly suggest just dropping this part of the thread.  Neither
 side will ever change the mind of the other.  It's a waste of time and
 energy.
 
 Later,
 Brad

Indeed, that would be the mature thing to do... but (like all internet wars), there's some fun to be had ;-P.
Aug 15 2008
parent BCS <ao pathlink.com> writes:
Reply to Robert,

 Brad Roberts wrote:
 
 <snip thread arguing both sides of the is there such a thing as IP>
 
 Guys.. I highly suggest just dropping this part of the thread.
 Neither side will ever change the mind of the other.  It's a waste of
 time and energy.
 
 Later,
 Brad

wars), there's some fun to be had ;-P.

WE NEED A digitalmars.D.OT!
Aug 15 2008
prev sibling parent downs <default_357-line yahoo.de> writes:
Robert Fraser wrote:
 Yigal Chripun Wrote:
 
 Robert Fraser wrote:
  > I've had very mixed feelings about all this. One one hand, the letter
 of the
 law may be questionably constitutional. But millions of dollars every day are
 lost because people (including myself occasionally...) steal copyrighted
 material. Honestly, I think there should be much stricter penalties for
 things like internet piracy, because it's simply so widespread and damaging.

the constitution) but all of the above is bullshit. (sorry for the language). stealing only applies to physical things like chairs and cars. that whole metaphor of information as physical entities is wrong. you sure can infringe someone's copyrights but you cannot steal anything since there's nothing to steal.

Some philosopher said that all philosophical debates were inherently linguistic ones that stemmed from not having the words to represent the concepts being spoken about. We're using different definitions of "steal," but the concept is clear -- it's taking something you don't have the right to have taken without paying for, and the debate is over whether you do or should have that right.

Apparently the concept is not clear, because we're not talking about "taking". We're talking about copying. Not the same thing.
 Now that we cleared that out of the way, let's touch other nonsenses in
 what you wrote:

 A) "millions of dollars every day are lost..." - Not true. you assume
 that if a person doesn't pirate he would have payed for the stuff. this
 is a wrong assumption since the majority of people would just use other
 alternatives.

Sure not everyone would have paid. But at least one person would have paid. Back in high school, I would have paid for a lot of the music I downloaded (perhaps not all of it) -- but I didn't since it was so easy for me to pirate it. The statement is that piracy costs at least $1 million/day in LOST SALES; if you would have used a free alternative, that's not factored into the argument.

Proof by anecdote. Good going.
 if I wouldn't be able to pirate MS office 

Mah paycheck!!! (that's paying me to post on D NGs...)
 I'd probably
 search for a cheap commercial solution or install Open Office which is
 good enough for me and most other private people and small companies. no
 one in their right mind would pay 500$ for an office suit. think
 globally: in US standards paying for software is not that expensive and
 is convenient (and you pay for that as well) but for most of the world
 those prices are high. in Israel 500$ translates to roughly 2000 NIS
 which is a lot.
 B)"it's simply so ... damaging" - not so.
 If you look at music and films than the image is backwards: since it's
 easy to pirate I can download a lot of stuff try it out and only keep
 what I like. If I like it I'll tell friends and more people will be
 exposed to the content. pirating actually makes money for the copyright
 holder and helps him get recognized since it's advertising they don't
 need to pay for.

I'm going to cry bull**** here. Quite a few sites offer legit free music/ video. The content creators/producers have made this available for precisely the reason you said -- so people view it and tell their friends or choose to buy higher-quality versions of it. The stuff they DON'T make available for free is not there because it is more profitable for them not to make it available. The creators/producers choose what to share for free -- NOT the consumers.
 If what you said was true than Red Hat and Novel wouldn't lasted more
 than a day. after all you can legally download their products from their
  respective websites!

Their business model is to make money off the support for their software, not the software itself.

I think he knows that.
 The issue is not whether piracy is moral or not. it's a fact of life -
 the internet provides an efficient means for distribution of
 information. either you take advantage of it or you insist on your old
 irrelevant business model and go extinct. 

Selling software/music/video/intellectual property for money is an extinct business model...? If that's your argument then o_O.

It's on its way out.
 business 101 - "The customer
 is always right." the moment they (RIAA, MPAA, etc..) broke that rule
 because they refused to evolve with respect to new technology and
 business models is the moment they signed their death warrants.

 I prefer supporting music artists by going to a concert and paying 100$
 for a ticket rather than paying for CDs with shitty music the records
 companies advertise and try to stick in my throat.

 one last thing, before suggesting more penalties and such please read
 the following: http://www.gnu.org/philosophy/right-to-read.html
 *after* reading this, are you sure still that this is the way to go?

I think what a lot of these arguments boil down to is people trying to justify taking stuff without paying for it. Plain and simple. I do on occasion download videos (these days only anime fansubs). And I don't feel bad about it. But I do know it's stealing.

Then you are wrong. :)
 Downloading a $10 CD is really
 no better than shoplifting a $10 CD, because the people who worked to
 bring that CD into existence are not being paid for it.

And how many cents off that CD do you think the people who made it will ever see? Not that this is relevant, since it is. not. stealing.
Aug 15 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Steven Schveighoffer wrote:
 I don't know the details of the license that Walter gave to the Tango 
 devs, 

It's as I posted here. Tango may use any part of Phobos and *relicense* it under the Tango license that I have the power to do.
 but according to Phobos' license, no explicit permission is needed as 
 long as you obey the license terms (which is pretty free in its 
 terms), and in fact, Tango has the Phobos license in the runtime 
 anyways, and obeys the license that ships with Phobos.  So I don't see 
 how it is relevant that Walter gave a specific license to Tango, it 
 was not required (at least that's my understanding).  It should be the 
 same thing for Walter to accept Tango's modified version of the 
 runtime (just include a copy of Tango's license).  My understanding is 
 that Walter is against doing that for the purpose of avoiding having 2 
 licenses in phobos.  Both licenses are very similar, and completely 
 compatible.  I see that Walter doesn't like it, but I don't see why it 
 is a problem?  Perhaps you could elaborate more, Walter.

I don't know what more needs to be elaborated. There are two reasons for this: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code.
 Also, I would like to know specifically what Walter needs from the 
 Tango team.  What could it be that he needs that the Tango team is 
 against?

What specifically I'd like from the Tango team is explicit permission for the Phobos team to go over the Tango code and be able to copy/use whatever portions of it are necessary to get the two libraries to have a compatible core, and to relicense those parts under the corresponding Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-) Sean
Aug 14 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have 
 a compatible core, and to relicense those parts under the 
 corresponding Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

If the cores are compatible at the API level, then one should be able to mix and match Tango/Phobos user level modules.
Aug 14 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g82ua5$1l6d$1 digitalmars.com...
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have a 
 compatible core, and to relicense those parts under the corresponding 
 Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

If the cores are compatible at the API level, then one should be able to mix and match Tango/Phobos user level modules.

Why one would want to do that is beyond me. If/when this licensing bullshit ever gets sorted, we still have the problem of two standard libraries designed with different goals and duplicate functionality. What then? How is that a solution? If it takes over a year to sort this licensing stuff, how long will it take to (god forbid) merge the two libraries? What are we solving here?
Aug 14 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g82uob$1mg2$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g82ua5$1l6d$1 digitalmars.com...
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have 
 a compatible core, and to relicense those parts under the corresponding 
 Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

If the cores are compatible at the API level, then one should be able to mix and match Tango/Phobos user level modules.

Why one would want to do that is beyond me.

No, don't interpret this as standard-library-fanboyism. By this I mean that even if you _could_ import modules from both phobos and tango, it would be next to impossible to use them together. They each have their own types, functions etc. for anything more complex than string manipulations and math (and even there they differ). You can't use a std.stream.Stream and a tango.io.Conduit together. You use one or the other. Hence, nothing has been solved.
Aug 14 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:g82uob$1mg2$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g82ua5$1l6d$1 digitalmars.com...
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have 
 a compatible core, and to relicense those parts under the corresponding 
 Phobos license.

compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

mix and match Tango/Phobos user level modules.


No, don't interpret this as standard-library-fanboyism. By this I mean that even if you _could_ import modules from both phobos and tango, it would be next to impossible to use them together. They each have their own types, functions etc. for anything more complex than string manipulations and math (and even there they differ). You can't use a std.stream.Stream and a tango.io.Conduit together. You use one or the other. Hence, nothing has been solved.

I think the idea is you could, say, use DWT (Tango) and DMDScript (Phobos) in the same application.
Aug 14 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 By this I mean that 
 even if you _could_ import modules from both phobos and tango, it would be 
 next to impossible to use them together.  They each have their own types, 
 functions etc. for anything more complex than string manipulations and math 
 (and even there they differ).  You can't use a std.stream.Stream and a 
 tango.io.Conduit together.  You use one or the other.  Hence, nothing has 
 been solved. 

I don't think anyone expects to mix up Stream and Conduit. But they should be able to mix up tango.io.Conduit with std.algorithm.
Aug 14 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to 
 have a compatible core, and to relicense those parts under the 
 corresponding Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

If the cores are compatible at the API level, then one should be able to mix and match Tango/Phobos user level modules.

I think it will turn out to be more complicated than that. The runtime contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least. Sean
Aug 14 2008
next sibling parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 15 Aug 2008 09:29:31 +0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission  
 for the Phobos team to go over the Tango code and be able to copy/use  
 whatever portions of it are necessary to get the two libraries to  
 have a compatible core, and to relicense those parts under the  
 corresponding Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

to mix and match Tango/Phobos user level modules.

I think it will turn out to be more complicated than that. The runtime contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least. Sean

Isn't it part of a runtime, i.e. something that is about to be unified?
Aug 14 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Koroskin Denis wrote:
 On Fri, 15 Aug 2008 09:29:31 +0400, Sean Kelly <sean invisibleduck.org> 
 wrote:
 
 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit 
 permission for the Phobos team to go over the Tango code and be 
 able to copy/use whatever portions of it are necessary to get the 
 two libraries to have a compatible core, and to relicense those 
 parts under the corresponding Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

able to mix and match Tango/Phobos user level modules.

I think it will turn out to be more complicated than that. The runtime contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least.

Isn't it part of a runtime, i.e. something that is about to be unified?

But this is more than just duplicating functionality. If the user wants to create a thread, what module does he import? Having compatible runtimes isn't quite the same has sharing a single common runtime. Sean
Aug 14 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:g8347r$201b$1 digitalmars.com...
 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have 
 a compatible core, and to relicense those parts under the corresponding 
 Phobos license.

I think this is arguably a reasonable first step, but working towards a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

If the cores are compatible at the API level, then one should be able to mix and match Tango/Phobos user level modules.

I think it will turn out to be more complicated than that. The runtime contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least.

As far as threads, I agree. One must be chosen. As far as exceptions, yes, one base must be chosen, and the exceptions put forth by the compiler must be chosen, but higher level exceptions do not have to be part of the runtime. For example, in Tango, socket exceptions are in the same module as array bound exception (which is needed by the compiler). These should be separated if we are to have a common runtime. And in that case, I think you can draw a clear line: what is needed to compile programs, and what is needed to start the runtime. Everything else should be standard library code, and should be relegated to whatever you fancy as the runtime. I propose these essential classes and modules be moved into a separate package, like std.runtime. So you would have std.runtime.thread, std.runtime.exception, etc. Or whatever. Then the line is even clearer. -Steve
Aug 15 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Sean Kelly" <sean invisibleduck.org> wrote in message 
 news:g8347r$201b$1 digitalmars.com...
 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to have 
 a compatible core, and to relicense those parts under the corresponding 
 Phobos license.

compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

mix and match Tango/Phobos user level modules.

contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least.

As far as threads, I agree. One must be chosen. As far as exceptions, yes, one base must be chosen, and the exceptions put forth by the compiler must be chosen, but higher level exceptions do not have to be part of the runtime. For example, in Tango, socket exceptions are in the same module as array bound exception (which is needed by the compiler). These should be separated if we are to have a common runtime.

This decision camw fairly late in the game, and the basic reasoning was that we wanted to establish a formal exception hierarchy. So a bunch of relatively standard exceptions were moved into tango.core.Exception to populate the hierarchy. The alternative would have been for multiple packages in Tango to try and declare and share a common top-level Exception class, and that was just too messy. However, I think it's worth noting that none of the exceptions declared in tango.core are terribly specific. Even SocketException is extremely broad, and as applicable for end users as it is for Tango itself. For what it's worth, this is one of the few bits of the runtime that I didn't send to Walter because others were involved in designing the hierarchy. Since there's no real code involved in exception declarations it was probably over-cautious of me to omit it, but I didn't want there to be any risk of contention later.
 And in that case, I think you can draw a clear line: what is needed to 
 compile programs, and what is needed to start the runtime.  Everything else 
 should be standard library code, and should be relegated to whatever you 
 fancy as the runtime.

Tango was designed from the start such that the runtime (that is, the code which is loaded invisibly for every D application) consists of three distinct parts: * the compiler runtime (ie. language support code) * the garbage collector * some subset of the standard library which the compiler and GC code may depend upon This design has some great advantages: * People with special needs (such as kernel developers) can replace or stub out an entire subset of the runtime if the default version doesn't suit their needs * The compiler runtime is completely separate from the other runtime code and may be maintained entirely separately--ie. it has no dependencies on standard library code * The garbage collector is completely separate as well. In fact, the GC may be chosen at link-time simply by specifying a different library. Tango contains two GCs to demonstrate this: one is the classic mark/sweep GC and the other simply calls malloc and free. Unfortunately however, none of this gets around the issue that the standard library portion of the code must exist in only one location. And I expect that both the Phobos and Tango team have a vested interest in not changing how this stuff is exposed. In the case of Tango, this interest is backed by the fact that we have a book in print documenting this stuff, which also happens to be the only English book about D that I'm aware of.
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even clearer.

See above. That would be fine except for the confusion it would cause for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code. Sean
Aug 15 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even clearer.

See above. That would be fine except for the confusion it would cause for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code. Sean

I suppose the magic of aliases and templates couldn't help at all here (i.e. make tango.Thread a compile-time wrapper around std.runtime.thread ...?)
Aug 15 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Robert Fraser wrote:
 Sean Kelly wrote:
 I propose these essential classes and modules be moved into a 
 separate package, like std.runtime.  So you would have 
 std.runtime.thread, std.runtime.exception, etc.  Or whatever.  Then 
 the line is even clearer.

See above. That would be fine except for the confusion it would cause for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code. Sean

I suppose the magic of aliases and templates couldn't help at all here (i.e. make tango.Thread a compile-time wrapper around std.runtime.thread ...?)

Currently, it's the opposite with Tango/Tangobos (std.thread.Thread basically aliases tango.core.Thread.Thread). But I consider this to be too much of a hack to have as a long-term solution. Sean
Aug 15 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 Robert Fraser wrote:
 Sean Kelly wrote:
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even 
 clearer.

See above. That would be fine except for the confusion it would cause for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code. Sean

I suppose the magic of aliases and templates couldn't help at all here (i.e. make tango.Thread a compile-time wrapper around std.runtime.thread ...?)

Currently, it's the opposite with Tango/Tangobos (std.thread.Thread basically aliases tango.core.Thread.Thread). But I consider this to be too much of a hack to have as a long-term solution.

The tango.core.Thread alias would be a convenience for backwards compatibility. It can be discouraged in favor of std.runtime.Thread. The only palatable solution I see is for a common namespace to exist. If you insist on the thread portion living in a namespace such as tango.core.Thread, then I can't see Phobos adopting that, and you are killing this whole compatibility project :( -Steve
Aug 15 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Sean Kelly" wrote
 Robert Fraser wrote:
 Sean Kelly wrote:
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even 
 clearer.

for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code. Sean

(i.e. make tango.Thread a compile-time wrapper around std.runtime.thread ...?)

basically aliases tango.core.Thread.Thread). But I consider this to be too much of a hack to have as a long-term solution.

The tango.core.Thread alias would be a convenience for backwards compatibility. It can be discouraged in favor of std.runtime.Thread. The only palatable solution I see is for a common namespace to exist. If you insist on the thread portion living in a namespace such as tango.core.Thread, then I can't see Phobos adopting that, and you are killing this whole compatibility project :(

I would very much like to see a single standard library for D. But certainly you can see that what you're asking is for Tango to forego all the consideration that has gone into its current design simply because Phobos is somehow inviolate, while at the same time Phobos for some reason wants to benefit from all the work that has gone into Tango. I'd hardly consider this collaboration, so you can perhaps understand why some of the other Tango team members aren't quite so cooperative as I have been. Truth be told, my desire to be conciliatory has long since been replaced with a desire to simply be done with the drama. So regardless of my opinion above (which is admittedly rather jaded and defensive), or perhaps in light of the reasons behind it, I'm mostly interested in just moving on. And because of this, I don't feel it's fair for me to speak for the rest of the Tango team. I'm simply hoping to clear the air and am following through with the promises I made to Walter a year ago when we last discussed all this. Sean
Aug 15 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Sean Kelly" <sean invisibleduck.org> wrote in message 
 news:g8347r$201b$1 digitalmars.com...
 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to 
 have a compatible core, and to relicense those parts under the 
 corresponding Phobos license.

a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

to mix and match Tango/Phobos user level modules.

contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least.

As far as threads, I agree. One must be chosen. As far as exceptions, yes, one base must be chosen, and the exceptions put forth by the compiler must be chosen, but higher level exceptions do not have to be part of the runtime. For example, in Tango, socket exceptions are in the same module as array bound exception (which is needed by the compiler). These should be separated if we are to have a common runtime.

This decision camw fairly late in the game, and the basic reasoning was that we wanted to establish a formal exception hierarchy. So a bunch of relatively standard exceptions were moved into tango.core.Exception to populate the hierarchy. The alternative would have been for multiple packages in Tango to try and declare and share a common top-level Exception class, and that was just too messy. However, I think it's worth noting that none of the exceptions declared in tango.core are terribly specific. Even SocketException is extremely broad, and as applicable for end users as it is for Tango itself.

I didn't mean exceptions need to be defined in individual modules, they can live in one file, but the user-lib exceptions need to be separate, because Phobos isn't going to care about Tango's SocketException for instance (or vice versa). There is nothing wrong with having runtime exceptions in one module, and being publicly imported in the user lib's exception module (which could remain as tango.core.Exception).
 For what it's worth, this is one of the few bits of the runtime that I 
 didn't send to Walter because others were involved in designing the 
 hierarchy.  Since there's no real code involved in exception declarations 
 it was probably over-cautious of me to omit it, but I didn't want there to 
 be any risk of contention later.

 And in that case, I think you can draw a clear line: what is needed to 
 compile programs, and what is needed to start the runtime.  Everything 
 else should be standard library code, and should be relegated to whatever 
 you fancy as the runtime.

Tango was designed from the start such that the runtime (that is, the code which is loaded invisibly for every D application) consists of three distinct parts: * the compiler runtime (ie. language support code) * the garbage collector * some subset of the standard library which the compiler and GC code may depend upon This design has some great advantages: * People with special needs (such as kernel developers) can replace or stub out an entire subset of the runtime if the default version doesn't suit their needs * The compiler runtime is completely separate from the other runtime code and may be maintained entirely separately--ie. it has no dependencies on standard library code * The garbage collector is completely separate as well. In fact, the GC may be chosen at link-time simply by specifying a different library. Tango contains two GCs to demonstrate this: one is the classic mark/sweep GC and the other simply calls malloc and free.

I agree that Tango's runtime design makes it ideal for splitting out from the user code.
 Unfortunately however, none of this gets around the issue that the 
 standard library portion of the code must exist in only one location. And 
 I expect that both the Phobos and Tango team have a vested interest in not 
 changing how this stuff is exposed.  In the case of Tango, this interest 
 is backed by the fact that we have a book in print documenting this stuff, 
 which also happens to be the only English book about D that I'm aware of.

Exposure can be aliased (see below).
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even clearer.

See above. That would be fine except for the confusion it would cause for readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code.

This is my view (might not work, but I think it could). For purposes of simplicity, I'll assume Walter currently develops the Phobos runtime (not that he doesn't, but I'm really not sure :). Maintenance of the merged runtime would become Walter's responsibility, with your help if necessary (ideas and help understanding, and enhancements if you wish). Any changes desired for the runtime would go through Phobos (and Walter). The Tango lib would use the now tango-fied Phobos runtime, with alias imports for existing code (e.g. tango.core.Thread would either publicly import std.thread or would privately import it, and alias the Thread class). Phobos user lib code would do the same, although I'd suspect that since Walter is maintaining the runtime, he'd want to follow Phobos' package and naming conventions. The one requirement for it is that the Phobos runtime MUST be separate from the user lib, and not depend on it. So no calling on Andrei's fancy Phobos-only templates :) This is similar to how I wanted Thread to use TimeSpan, but we can't because TimeSpan is part of the user lib. People who have the book can still use the code and ideas presented in the book, because the imports will alias the real classes/structs from the new Phobos runtime. BTW, since the book was released, there have been a lot of breaking changes, so the edge of that point is dulled quite a bit. How does this sound (for both you and Walter)? -Steve
Aug 15 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Sean Kelly" wrote
 Steven Schveighoffer wrote:
 "Sean Kelly" <sean invisibleduck.org> wrote in message 
 news:g8347r$201b$1 digitalmars.com...
 Walter Bright wrote:
 Sean Kelly wrote:
 What specifically I'd like from the Tango team is explicit permission 
 for the Phobos team to go over the Tango code and be able to copy/use 
 whatever portions of it are necessary to get the two libraries to 
 have a compatible core, and to relicense those parts under the 
 corresponding Phobos license.

a compatible core still means two separate cores, which means not being able to use Tango and Phobos together in the same app. So I'll admit to not completely understanding the reasoning behind this approach, but it's the only option so I'm happy to comply. Frankly, I don't want to be stuck maintaining the Tango runtime from now until doomsday anyway :-)

to mix and match Tango/Phobos user level modules.

contains user-visible code as well as the compiler support code and GC: exception definitions, the thread code, etc. And Phobos vs. Tango have different exception hierarchies, at the very least.

As far as exceptions, yes, one base must be chosen, and the exceptions put forth by the compiler must be chosen, but higher level exceptions do not have to be part of the runtime. For example, in Tango, socket exceptions are in the same module as array bound exception (which is needed by the compiler). These should be separated if we are to have a common runtime.

that we wanted to establish a formal exception hierarchy. So a bunch of relatively standard exceptions were moved into tango.core.Exception to populate the hierarchy. The alternative would have been for multiple packages in Tango to try and declare and share a common top-level Exception class, and that was just too messy. However, I think it's worth noting that none of the exceptions declared in tango.core are terribly specific. Even SocketException is extremely broad, and as applicable for end users as it is for Tango itself.

I didn't mean exceptions need to be defined in individual modules, they can live in one file, but the user-lib exceptions need to be separate, because Phobos isn't going to care about Tango's SocketException for instance (or vice versa). There is nothing wrong with having runtime exceptions in one module, and being publicly imported in the user lib's exception module (which could remain as tango.core.Exception).
 For what it's worth, this is one of the few bits of the runtime that I 
 didn't send to Walter because others were involved in designing the 
 hierarchy.  Since there's no real code involved in exception declarations 
 it was probably over-cautious of me to omit it, but I didn't want there to 
 be any risk of contention later.

 And in that case, I think you can draw a clear line: what is needed to 
 compile programs, and what is needed to start the runtime.  Everything 
 else should be standard library code, and should be relegated to whatever 
 you fancy as the runtime.

which is loaded invisibly for every D application) consists of three distinct parts: * the compiler runtime (ie. language support code) * the garbage collector * some subset of the standard library which the compiler and GC code may depend upon This design has some great advantages: * People with special needs (such as kernel developers) can replace or stub out an entire subset of the runtime if the default version doesn't suit their needs * The compiler runtime is completely separate from the other runtime code and may be maintained entirely separately--ie. it has no dependencies on standard library code * The garbage collector is completely separate as well. In fact, the GC may be chosen at link-time simply by specifying a different library. Tango contains two GCs to demonstrate this: one is the classic mark/sweep GC and the other simply calls malloc and free.

I agree that Tango's runtime design makes it ideal for splitting out from the user code.
 Unfortunately however, none of this gets around the issue that the 
 standard library portion of the code must exist in only one location. And 
 I expect that both the Phobos and Tango team have a vested interest in not 
 changing how this stuff is exposed.  In the case of Tango, this interest 
 is backed by the fact that we have a book in print documenting this stuff, 
 which also happens to be the only English book about D that I'm aware of.

Exposure can be aliased (see below).
 I propose these essential classes and modules be moved into a separate 
 package, like std.runtime.  So you would have std.runtime.thread, 
 std.runtime.exception, etc.  Or whatever.  Then the line is even clearer.

readers of our book. Also, maintenance responsibility is a potential issue. None of these issues are addressed by a simple desire to share code.

This is my view (might not work, but I think it could). For purposes of simplicity, I'll assume Walter currently develops the Phobos runtime (not that he doesn't, but I'm really not sure :). Maintenance of the merged runtime would become Walter's responsibility, with your help if necessary (ideas and help understanding, and enhancements if you wish). Any changes desired for the runtime would go through Phobos (and Walter). The Tango lib would use the now tango-fied Phobos runtime, with alias imports for existing code (e.g. tango.core.Thread would either publicly import std.thread or would privately import it, and alias the Thread class).

My original goal was to have Walter maintain the DMD compiler runtime and leave the rest to the appropriate parties. Walter clearly can't maintain the entire runtime because Tango includes compiler runtimes for GDC (currently) and LLVMC (soon), etc. Each of these should ideally be maintained by the respective compiler author. One of the problems in my mind is that Phobos isn't portable, as justified by the fact that GDC contains GPhobos. It's an untenable long-term solution.
 Phobos user lib code would do the same, although I'd suspect that since 
 Walter is maintaining the runtime, he'd want to follow Phobos' package and 
 naming conventions.  The one requirement for it is that the Phobos runtime 
 MUST be separate from the user lib, and not depend on it.  So no calling on 
 Andrei's fancy Phobos-only templates :)  This is similar to how I wanted 
 Thread to use TimeSpan, but we can't because TimeSpan is part of the user 
 lib.

Yeah, I wanted to move TimeSpan into the runtime so this would be possible but was out-voted. But I think we both agree that the Tango design is fairly close to ideal in that the runtime is entirely separate from the user code (aside from some of the necessary exported bits).
 People who have the book can still use the code and ideas presented in the 
 book, because the imports will alias the real classes/structs from the new 
 Phobos runtime.

One concern I have about moving the runtime into Phobos is portability / flexibility. Will it be possible to use the runtime without the user code as it is in Tango? Will it continue to be compiler-agnostic? I'll admit that I completely fail to see the point of the language creator being the go-to man for the standard library as well.
 BTW, since the book was released, there have been a lot of breaking changes, 
 so the edge of that point is dulled quite a bit.

Few, if any, of those breaking changes were covered by the book as far as I'm aware.
 How does this sound (for both you and Walter)?

When you get right down to it, I really don't want to be stuck working on Tango for the rest of my life, so my feelings are mixed. I think that D accepting Tango as the official standard library and Walter et al. collaborating with the Tango maintainers would be the optimal solution for all concerned. However, I also don't want to be placed in a position where I'm the linchpin holding everything together. My personal responsibilities have grown considerably since Tango was started and that's far more time and responsibility than I want, barring a considerable paycheck for doing so. So in short I think it would be a bad idea but I'd probably agree to it anyway because doing so is in my own best interest. Sean
Aug 15 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 Steven Schveighoffer wrote:
 This is my view (might not work, but I think it could).  For purposes of 
 simplicity, I'll assume Walter currently develops the Phobos runtime (not 
 that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's responsibility, 
 with your help if necessary (ideas and help understanding, and 
 enhancements if you wish).  Any changes desired for the runtime would go 
 through Phobos (and Walter).  The Tango lib would use the now tango-fied 
 Phobos runtime, with alias imports for existing code (e.g. 
 tango.core.Thread would either publicly import std.thread or would 
 privately import it, and alias the Thread class).

My original goal was to have Walter maintain the DMD compiler runtime and leave the rest to the appropriate parties. Walter clearly can't maintain the entire runtime because Tango includes compiler runtimes for GDC (currently) and LLVMC (soon), etc. Each of these should ideally be maintained by the respective compiler author.

Again, for the purposes of simplicity, I said Walter, but I meant 'Phobos runtime developer'. I don't know who that is or will be.
 One of the problems in my mind is that Phobos isn't portable, as justified 
 by the fact that GDC contains GPhobos.  It's an untenable long-term 
 solution.

Then let's make it portable :) At least the runtime portion.
 Phobos user lib code would do the same, although I'd suspect that since 
 Walter is maintaining the runtime, he'd want to follow Phobos' package 
 and naming conventions.  The one requirement for it is that the Phobos 
 runtime MUST be separate from the user lib, and not depend on it.  So no 
 calling on Andrei's fancy Phobos-only templates :)  This is similar to 
 how I wanted Thread to use TimeSpan, but we can't because TimeSpan is 
 part of the user lib.

Yeah, I wanted to move TimeSpan into the runtime so this would be possible but was out-voted. But I think we both agree that the Tango design is fairly close to ideal in that the runtime is entirely separate from the user code (aside from some of the necessary exported bits).
 People who have the book can still use the code and ideas presented in 
 the book, because the imports will alias the real classes/structs from 
 the new Phobos runtime.

One concern I have about moving the runtime into Phobos is portability / flexibility. Will it be possible to use the runtime without the user code as it is in Tango?

It has to be in order for both Tango and Phobos to use it. That is a requirement (one which should be satisfied by copying Tango's runtime).
 Will it continue to be compiler-agnostic?

That, I can't say. But with effort, it can be maintained that way. Perhaps once the port is done, external compilers can own their respective compiler parts. If they are using the new runtime, it should also be compatible with Tango. My idea of the porting should involve repackaging the Tango runtime into a generic style (or at least one that suits whoever is maintaining it), and then porting both libs to use the new runtime. The checks and balances come when releases are made that break compatibility, we submit bugs, the runtime gets fixed. It works no different than Tango development does today, except that the runtime code lives in Phobos.
 How does this sound (for both you and Walter)?

When you get right down to it, I really don't want to be stuck working on Tango for the rest of my life, so my feelings are mixed. I think that D accepting Tango as the official standard library and Walter et al. collaborating with the Tango maintainers would be the optimal solution for all concerned.

As someone who prefers Tango, D accepting Tango as the standard library would be fine with me. But realistically, that ain't gonna happen :) You have to respect that Phobos developers have a lot of time and effort invested in Phobos, and to see it just get replaced would be a huge kick in the ass for them. I think the optimal solution is for both libraries to coexist, AND to be binary compatible.
 However, I also don't want to be placed in a position where I'm the 
 linchpin holding everything together.  My personal responsibilities have 
 grown considerably since Tango was started and that's far more time and 
 responsibility than I want, barring a considerable paycheck for doing so. 
 So in short I think it would be a bad idea but I'd probably agree to it 
 anyway because doing so is in my own best interest.

I think you might only be a linchpin until the port is done, then if you don't want to continue maintaining, I'm sure that void will get filled. -Steve
Aug 15 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Steven Schveighoffer wrote:
 
 This is my view (might not work, but I think it could).  For purposes of
 simplicity, I'll assume Walter currently develops the Phobos runtime (not
 that he doesn't, but I'm really not sure :).
 
 Maintenance of the merged runtime would become Walter's responsibility,
 with your help if necessary (ideas and help understanding, and
 enhancements if
 you wish).  Any changes desired for the runtime would go through Phobos
 (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime, with
 alias imports for existing code (e.g. tango.core.Thread would either
 publicly import std.thread or would privately import it, and alias the
 Thread class).

Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime. If there should be a common-common (not only "just" compatible) runtime, it shouldn't be controlled by one compiler vendor. Note that the Tango runtime consists of 3 parts, where only one is compiler specific. That particular part should probably be controlled/reviewed by the compiler vendor, the rest (GC, threading, other things) should be independent. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 15 2008
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes of
 simplicity, I'll assume Walter currently develops the Phobos runtime (not
 that he doesn't, but I'm really not sure :).
 
 Maintenance of the merged runtime would become Walter's responsibility,
 with your help if necessary (ideas and help understanding, and
 enhancements if
 you wish).  Any changes desired for the runtime would go through Phobos
 (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime, with
 alias imports for existing code (e.g. tango.core.Thread would either
 publicly import std.thread or would privately import it, and alias the
 Thread class).

Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.
 If there should be a common-common (not only "just" compatible) runtime,
 it shouldn't be controlled by one compiler vendor. Note that the Tango
 runtime consists of 3 parts, where only one is compiler specific. That
 particular part should probably be controlled/reviewed by the compiler
 vendor, the rest (GC, threading, other things) should be independent.

I'll admit my understanding is limited, but I'd guess that will lead to even further fragmentation and non-portability. Wasn't D supposed to be more portable between compiler implementations than C++ as opposed to less portable?
Aug 15 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lutger wrote:

 Lars Ivar Igesund wrote:
 
 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes of
 simplicity, I'll assume Walter currently develops the Phobos runtime
 (not that he doesn't, but I'm really not sure :).
 
 Maintenance of the merged runtime would become Walter's responsibility,
 with your help if necessary (ideas and help understanding, and
 enhancements if
 you wish).  Any changes desired for the runtime would go through Phobos
 (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible) runtime,
 it shouldn't be controlled by one compiler vendor. Note that the Tango
 runtime consists of 3 parts, where only one is compiler specific. That
 particular part should probably be controlled/reviewed by the compiler
 vendor, the rest (GC, threading, other things) should be independent.

I'll admit my understanding is limited, but I'd guess that will lead to even further fragmentation and non-portability.

The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 16 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Lutger wrote:
 
 Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes of
 simplicity, I'll assume Walter currently develops the Phobos runtime
 (not that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's responsibility,
 with your help if necessary (ideas and help understanding, and
 enhancements if
 you wish).  Any changes desired for the runtime would go through Phobos
 (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible) runtime,
 it shouldn't be controlled by one compiler vendor. Note that the Tango
 runtime consists of 3 parts, where only one is compiler specific. That
 particular part should probably be controlled/reviewed by the compiler
 vendor, the rest (GC, threading, other things) should be independent.

even further fragmentation and non-portability.

The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

I don't understand your point. are you suggesting that things like the GC will be independent from the compiler? It seems to me that the model suggested by Sean is the way to go: ie: my code ---------- standard library user code and standardized APIs to the runtime (threading, etc --------------------------------- compiler + runtime A | compiler + runtime B | ..... if a user isn't satisfied by runtime/compiler A he should just switch vendors. All the user facing APIs are standardized in the stdlib so all is needed is to recompile..
Aug 16 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 Lutger wrote:
 
 Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes
 of simplicity, I'll assume Walter currently develops the Phobos
 runtime (not that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's
 responsibility, with your help if necessary (ideas and help
 understanding, and enhancements if
 you wish).  Any changes desired for the runtime would go through
 Phobos (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible)
 runtime, it shouldn't be controlled by one compiler vendor. Note that
 the Tango runtime consists of 3 parts, where only one is compiler
 specific. That particular part should probably be controlled/reviewed
 by the compiler vendor, the rest (GC, threading, other things) should
 be independent.

even further fragmentation and non-portability.

The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

I don't understand your point. are you suggesting that things like the GC will be independent from the compiler? It seems to me that the model suggested by Sean is the way to go: ie: my code ---------- standard library user code and standardized APIs to the runtime (threading, etc --------------------------------- compiler + runtime A | compiler + runtime B | ..... if a user isn't satisfied by runtime/compiler A he should just switch vendors. All the user facing APIs are standardized in the stdlib so all is needed is to recompile..

A common interface (API and ABI) would make this easier, but I just tend to think that a common implementation as long as possible would be even better - unification of efforts etc. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 16 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Yigal Chripun wrote:
 
 Lars Ivar Igesund wrote:
 Lutger wrote:

 Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes
 of simplicity, I'll assume Walter currently develops the Phobos
 runtime (not that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's
 responsibility, with your help if necessary (ideas and help
 understanding, and enhancements if
 you wish).  Any changes desired for the runtime would go through
 Phobos (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible)
 runtime, it shouldn't be controlled by one compiler vendor. Note that
 the Tango runtime consists of 3 parts, where only one is compiler
 specific. That particular part should probably be controlled/reviewed
 by the compiler vendor, the rest (GC, threading, other things) should
 be independent.

even further fragmentation and non-portability.

course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

GC will be independent from the compiler? It seems to me that the model suggested by Sean is the way to go: ie: my code ---------- standard library user code and standardized APIs to the runtime (threading, etc --------------------------------- compiler + runtime A | compiler + runtime B | ..... if a user isn't satisfied by runtime/compiler A he should just switch vendors. All the user facing APIs are standardized in the stdlib so all is needed is to recompile..

A common interface (API and ABI) would make this easier, but I just tend to think that a common implementation as long as possible would be even better - unification of efforts etc.

unified GC implementation (for example) independent of a specific vendor will remove some work from the compiler vendor but Id think this is rather a bad thing. I prefer each vendor to provide his own GC implementation (keeping with my example) which of course conforms to the standards (API, ABI, ...) so that I can change to a different vendor easily without any changes to my code (all I need to do is recompile). The benefit is that the vendors will compete for runtime performance which is good for the end user. I can choose vendor A's GC since it is more efficient with regards to memory (if I care for that) or vendor B's GC if it's faster, etc.. All I care is that everything that is visible to the end user is standardized - i.e. I can do GC.collect() in my code since it's in the APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care for performance reasons and such of course and for that I can just switch to a different vendor without any code changes)
Aug 16 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Yigal Chripun wrote:
 Lars Ivar Igesund wrote:
 Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 Lutger wrote:

 Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes
 of simplicity, I'll assume Walter currently develops the Phobos
 runtime (not that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's
 responsibility, with your help if necessary (ideas and help
 understanding, and enhancements if
 you wish).  Any changes desired for the runtime would go through
 Phobos (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

good idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible)
 runtime, it shouldn't be controlled by one compiler vendor. Note that
 the Tango runtime consists of 3 parts, where only one is compiler
 specific. That particular part should probably be controlled/reviewed
 by the compiler vendor, the rest (GC, threading, other things) should
 be independent.

even further fragmentation and non-portability.

course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

GC will be independent from the compiler? It seems to me that the model suggested by Sean is the way to go: ie: my code ---------- standard library user code and standardized APIs to the runtime (threading, etc --------------------------------- compiler + runtime A | compiler + runtime B | ..... if a user isn't satisfied by runtime/compiler A he should just switch vendors. All the user facing APIs are standardized in the stdlib so all is needed is to recompile..

think that a common implementation as long as possible would be even better - unification of efforts etc.

unified GC implementation (for example) independent of a specific vendor will remove some work from the compiler vendor but Id think this is rather a bad thing. I prefer each vendor to provide his own GC implementation (keeping with my example) which of course conforms to the standards (API, ABI, ...) so that I can change to a different vendor easily without any changes to my code (all I need to do is recompile).

I'd prefer being able to choose the GC I want without needing the compiler vendor to supply it. Otherwise, the compiler vendor either needs to know how to write a GC (unlikely) or they need to bundle a third-party GC. Also, different applications have different memory requirements. Tango allows the GC to be chosen at link-time, which allows for a great deal of flexibility.
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor B's
 GC if it's faster, etc..

Better to choose the GC separately from the compiler, then, so you can use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)

This is a standard library issue not a compiler runtime or GC issue. Sean
Aug 18 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Sean Kelly wrote:
 I'd prefer being able to choose the GC I want without needing the
 compiler vendor to supply it.  Otherwise, the compiler vendor either
 needs to know how to write a GC (unlikely) or they need to bundle a
 third-party GC.  Also, different applications have different memory
 requirements.  Tango allows the GC to be chosen at link-time, which
 allows for a great deal of flexibility. 

If we compare to Java than Sun provides more than one GC with its runtime and you can get even more specialized version GC if you really need it (real-time for example). I guess there's nothing wrong in getting a third party GC either. The point is that in Java those GCs are chosen by the runtime (you can specify if you run your app as a server or a client app and based on that the GC is chosen) or you can specify explicitly your GC too, I guess. Non of that should affect your code (unless you choose to use specific extensions to the GC API provided but a specialized GC). So, the choice of a GC doesn't affect your code.
 
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor B's
 GC if it's faster, etc..

Better to choose the GC separately from the compiler, then, so you can use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)

This is a standard library issue not a compiler runtime or GC issue.

it is an issue with the compiler runtime/GC if there isn't a standard API and when I change my GC/runtime I need to edit the source.
 
 
 Sean

Aug 23 2008
next sibling parent reply Vincent Richomme <forumer smartmobili.com> writes:
Yigal Chripun a écrit :
 Sean Kelly wrote:
  > I'd prefer being able to choose the GC I want without needing the
 compiler vendor to supply it.  Otherwise, the compiler vendor either
 needs to know how to write a GC (unlikely) or they need to bundle a
 third-party GC.  Also, different applications have different memory
 requirements.  Tango allows the GC to be chosen at link-time, which
 allows for a great deal of flexibility. 

If we compare to Java than Sun provides more than one GC with its runtime and you can get even more specialized version GC if you really need it (real-time for example). I guess there's nothing wrong in getting a third party GC either. The point is that in Java those GCs are chosen by the runtime (you can specify if you run your app as a server or a client app and based on that the GC is chosen) or you can specify explicitly your GC too, I guess. Non of that should affect your code (unless you choose to use specific extensions to the GC API provided but a specialized GC). So, the choice of a GC doesn't affect your code.
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor B's
 GC if it's faster, etc..

use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)


it is an issue with the compiler runtime/GC if there isn't a standard API and when I change my GC/runtime I need to edit the source.
 Sean


What I would like to know now: is there any progress between this Tango vs Phobos discussion... I still don't know if I can rely on Tango for my dev or on phobos and I think I am not the only one.
Aug 23 2008
next sibling parent reply Brian Price <blprice61 yahoo.com> writes:
My take on the Tango vs Phobos situation is:

For production use the only real choice is D1 (D2 being alpha) and it looks like
there are going to be so many changes in the language that going from a D1 app
to
a D2 app is going to require more than a bit of work and thought.

So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
and maintained library than Phobos.  I'd expect that to change in D2 and expect
the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

Regardless of the choice of library for use with D1, moving to D2 with either
library looks like a chore since Phobos seems to be undergoing some (much
needed)
significant changes from D1 to D2 versions.

As to the larger topic, D is potentially caught on the horns of a dilemma: D1 is
not a significant enough advance on current languages to justify a move even if
there were no library concerns; D2 may well be enough of a step forward to
justify
a move but there is the issue of timing.  My take is that if the upcoming C++
standard makes it into compilers used in common production before D2 is ready
for
prime time that D may never gain a real foothold in mainstream use.  I'm hoping
that the D2 team sets a deadline and leaves some things for a future D3 rather
than miss the window of opportunity.

Brian
Aug 23 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Brian Price wrote:
 My take on the Tango vs Phobos situation is:
 
 For production use the only real choice is D1 (D2 being alpha) and it looks
like
 there are going to be so many changes in the language that going from a D1 app
to
 a D2 app is going to require more than a bit of work and thought.

It's also worth mentioning that whatever is decided, no changes are likely to occur with D1 / Phobos1 because that version of D is frozen. So from a practical standpoint I think Tango and Tangobos will continue to be the preferred approach for development under D1.
 So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
 and maintained library than Phobos.  I'd expect that to change in D2 and expect
 the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

Pretty much. Though having some sort of shared runtime /may/ affect how some of the features in tango.core are exposed. I would obviously prefer if Phobos just built on top of Tango as with the Tango / Tangobos solution for D1, but that doesn't seem likely to happen.
 Regardless of the choice of library for use with D1, moving to D2 with either
 library looks like a chore since Phobos seems to be undergoing some (much
needed)
 significant changes from D1 to D2 versions.

Yup.
 As to the larger topic, D is potentially caught on the horns of a dilemma: D1
is
 not a significant enough advance on current languages to justify a move even if
 there were no library concerns; D2 may well be enough of a step forward to
justify
 a move but there is the issue of timing.  My take is that if the upcoming C++
 standard makes it into compilers used in common production before D2 is ready
for
 prime time that D may never gain a real foothold in mainstream use.  I'm hoping
 that the D2 team sets a deadline and leaves some things for a future D3 rather
 than miss the window of opportunity.

In my opinion, the benefits of D1 over comparable mainstream languages are quite substantial but difficult to quantify. The elegance of the language tends to produce vastly more maintainable code than C++, for example, which is a huge win for team development. As far as D2 is concerned, I think it's really too early to say. My current opinion is that the feature additions in D2 impact the syntax in such a way that they eliminate much of the advantage of D1--stemming from elegance and simplicity--in exchange for largely theoretical benefits. But D2 is still in development so who knows. Sean
Aug 25 2008
parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 Brian Price wrote:
 My take on the Tango vs Phobos situation is:
 
 For production use the only real choice is D1 (D2 being alpha) and it looks
like
 there are going to be so many changes in the language that going from a D1 app
to
 a D2 app is going to require more than a bit of work and thought.

It's also worth mentioning that whatever is decided, no changes are likely to occur with D1 / Phobos1 because that version of D is frozen. So from a practical standpoint I think Tango and Tangobos will continue to be the preferred approach for development under D1.
 So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
 and maintained library than Phobos.  I'd expect that to change in D2 and expect
 the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

Pretty much. Though having some sort of shared runtime /may/ affect how some of the features in tango.core are exposed. I would obviously prefer if Phobos just built on top of Tango as with the Tango / Tangobos solution for D1, but that doesn't seem likely to happen.

glad to hear that. there's quite a few of us who aren't quite fans of tango. i'd rather wait for bartosh walt & andrei to put their weight behind phobos2.
 Regardless of the choice of library for use with D1, moving to D2 with either
 library looks like a chore since Phobos seems to be undergoing some (much
needed)
 significant changes from D1 to D2 versions.

Yup.
 As to the larger topic, D is potentially caught on the horns of a dilemma: D1
is
 not a significant enough advance on current languages to justify a move even if
 there were no library concerns; D2 may well be enough of a step forward to
justify
 a move but there is the issue of timing.  My take is that if the upcoming C++
 standard makes it into compilers used in common production before D2 is ready
for
 prime time that D may never gain a real foothold in mainstream use.  I'm hoping
 that the D2 team sets a deadline and leaves some things for a future D3 rather
 than miss the window of opportunity.

In my opinion, the benefits of D1 over comparable mainstream languages are quite substantial but difficult to quantify. The elegance of the language tends to produce vastly more maintainable code than C++, for example, which is a huge win for team development. As far as D2 is concerned, I think it's really too early to say. My current opinion is that the feature additions in D2 impact the syntax in such a way that they eliminate much of the advantage of D1--stemming from elegance and simplicity--in exchange for largely theoretical benefits. But D2 is still in development so who knows.

u realize if u don't want that to look like fud u better back that up. i mean we could be sittin' on our ass and muse on them theoretical & practical issues. or we could write d2 and bring real arguments to the table. so how much d2 code have you written. i know i switched to d2 as soon as it was out. i have nuff freedom work to write at least part of my code in whatever. the more versions arrive with new stuff the more d1 looks to me like an ass-backwards neanderthal tool made of sticks bear claws and silex. could even go as far as sayin' d1 ain't ever gonna make it to prime time. it's just a cute lil language that has a few merits marred by its issues. all languages are like that. d2... d2 feels different because it is different. larger ambitions to address real problems in innovative ways. and leave no shit behind like most languages do in pursuit of the mother of all features. and the new team has much more knowledge than walt alone. (sorry walt. but i guess u'd agree.) so sean. how much d2 did you write. hope you agree it's hard to claim it has no practical advantages if you haven't practically used it. the irony, eh.
Aug 25 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Sean Kelly Wrote:
 
 Brian Price wrote:
 My take on the Tango vs Phobos situation is:

 For production use the only real choice is D1 (D2 being alpha) and it looks
like
 there are going to be so many changes in the language that going from a D1 app
to
 a D2 app is going to require more than a bit of work and thought.

likely to occur with D1 / Phobos1 because that version of D is frozen. So from a practical standpoint I think Tango and Tangobos will continue to be the preferred approach for development under D1.
 So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
 and maintained library than Phobos.  I'd expect that to change in D2 and expect
 the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

some of the features in tango.core are exposed. I would obviously prefer if Phobos just built on top of Tango as with the Tango / Tangobos solution for D1, but that doesn't seem likely to happen.

glad to hear that. there's quite a few of us who aren't quite fans of tango. i'd rather wait for bartosh walt & andrei to put their weight behind phobos2.
 Regardless of the choice of library for use with D1, moving to D2 with either
 library looks like a chore since Phobos seems to be undergoing some (much
needed)
 significant changes from D1 to D2 versions.

 As to the larger topic, D is potentially caught on the horns of a dilemma: D1
is
 not a significant enough advance on current languages to justify a move even if
 there were no library concerns; D2 may well be enough of a step forward to
justify
 a move but there is the issue of timing.  My take is that if the upcoming C++
 standard makes it into compilers used in common production before D2 is ready
for
 prime time that D may never gain a real foothold in mainstream use.  I'm hoping
 that the D2 team sets a deadline and leaves some things for a future D3 rather
 than miss the window of opportunity.

are quite substantial but difficult to quantify. The elegance of the language tends to produce vastly more maintainable code than C++, for example, which is a huge win for team development. As far as D2 is concerned, I think it's really too early to say. My current opinion is that the feature additions in D2 impact the syntax in such a way that they eliminate much of the advantage of D1--stemming from elegance and simplicity--in exchange for largely theoretical benefits. But D2 is still in development so who knows.

u realize if u don't want that to look like fud u better back that up. i mean we could be sittin' on our ass and muse on them theoretical & practical issues. or we could write d2 and bring real arguments to the table. so how much d2 code have you written.

A bit. I ported the Tango runtime to D2 once. The rest comes from parallels with C++. For example, one of my major issues with D2 is the syntax of the const design. It's theoretically pretty slick, but I'm not at all happy with the prospect of maintaining duplicate function implementations simply to overload on const. This is one of the things that drove me crazy about C++, and D2 is even worse in this regard because it has not only 'const' but 'invariant' as well. And don't say "don't like const, don't use it," because that isn't an option for me as a library developer. Another issue is more to do with code portability than with D2 itself. That is, the meaning of 'const' has changed between D1 and D2, with 'invariant' effectively replacing what 'const' was used for in D1. This makes it impossible to create code that has the same meaning in both versions of the language. Eventually, D1 will be forgotten and no one will care about this any more, but for Tango right now this is a significant issue in my opinion. Much of the rest is cosmetic--the sort of thing Walter likes to call "barn door" issues. I hate that we're stuck with 'enum' to signify manifest constants, for example. Heck, I hate that D supports anonymous enums at all, but making this an official feature in D2 is just crazy IMO. Maybe not a big deal to you, but what drew me to D in the first place were largely what I'd consider cosmetic improvements over C++.
 i know i switched to d2 as soon as it was out. i have nuff freedom  
 work to write at least part of my code in whatever. the more versions
 arrive with new stuff the more d1 looks to me like an ass-backwards
 neanderthal tool made of sticks bear claws and silex. could even go as
 far as sayin' d1 ain't ever gonna make it to prime time. it's just a
 cute lil language that has a few merits marred by its issues. all
 languages  are like that. d2... d2 feels different because it is
 different. larger ambitions to address real problems in innovative
 ways.  and leave no shit behind like most languages do
 in pursuit of the mother of all features.
 and the new team has much more knowledge than walt alone. (sorry
 walt. but i guess u'd agree.)

Yeah, D1 is a cute little language, but it's eminently usable. All D2 really has going for it at the moment is the const stuff, and I quite honestly don't care about that. This isn't because I don't work on projects large enough to require it--my last project was a few million lines of C++ maintained by a decent sized team--but rather because I feel that inelegant syntax is a greater issue for maintenance than language support for data mutability. I'd simply rather have nothing than something that I think will produce unmaintainable code.
 so sean. how much d2 did you write. hope you agree it's hard to claim it has
no practical advantages if you haven't practically used it. the irony, eh.

Not enough to speak with experience, quite honestly. Perhaps that will chance with this shared runtime business. Sean
Aug 25 2008
next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 superdan wrote:
 Sean Kelly Wrote:
 
 Brian Price wrote:
 My take on the Tango vs Phobos situation is:

 For production use the only real choice is D1 (D2 being alpha) and it looks
like
 there are going to be so many changes in the language that going from a D1 app
to
 a D2 app is going to require more than a bit of work and thought.

likely to occur with D1 / Phobos1 because that version of D is frozen. So from a practical standpoint I think Tango and Tangobos will continue to be the preferred approach for development under D1.
 So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
 and maintained library than Phobos.  I'd expect that to change in D2 and expect
 the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

some of the features in tango.core are exposed. I would obviously prefer if Phobos just built on top of Tango as with the Tango / Tangobos solution for D1, but that doesn't seem likely to happen.

glad to hear that. there's quite a few of us who aren't quite fans of tango. i'd rather wait for bartosh walt & andrei to put their weight behind phobos2.
 Regardless of the choice of library for use with D1, moving to D2 with either
 library looks like a chore since Phobos seems to be undergoing some (much
needed)
 significant changes from D1 to D2 versions.

 As to the larger topic, D is potentially caught on the horns of a dilemma: D1
is
 not a significant enough advance on current languages to justify a move even if
 there were no library concerns; D2 may well be enough of a step forward to
justify
 a move but there is the issue of timing.  My take is that if the upcoming C++
 standard makes it into compilers used in common production before D2 is ready
for
 prime time that D may never gain a real foothold in mainstream use.  I'm hoping
 that the D2 team sets a deadline and leaves some things for a future D3 rather
 than miss the window of opportunity.

are quite substantial but difficult to quantify. The elegance of the language tends to produce vastly more maintainable code than C++, for example, which is a huge win for team development. As far as D2 is concerned, I think it's really too early to say. My current opinion is that the feature additions in D2 impact the syntax in such a way that they eliminate much of the advantage of D1--stemming from elegance and simplicity--in exchange for largely theoretical benefits. But D2 is still in development so who knows.

u realize if u don't want that to look like fud u better back that up. i mean we could be sittin' on our ass and muse on them theoretical & practical issues. or we could write d2 and bring real arguments to the table. so how much d2 code have you written.

A bit. I ported the Tango runtime to D2 once. The rest comes from parallels with C++. For example, one of my major issues with D2 is the syntax of the const design. It's theoretically pretty slick, but I'm not at all happy with the prospect of maintaining duplicate function implementations simply to overload on const. This is one of the things that drove me crazy about C++, and D2 is even worse in this regard because it has not only 'const' but 'invariant' as well. And don't say "don't like const, don't use it," because that isn't an option for me as a library developer.

not sure why you keep on sneaking that `theoretically' word in. duplicate code blows, theoretically and practically. yeah that pisses me off too. i managed to avoid duplication thru concepts. dont 4get u only need to do that when you want the qualifier in the return type. often you don't. you can also rely on auto because now it deduces the return type for you. i recall walter promised he'll look into that. but i'm not holding my breath eh. constrained templates do the work for me no problem.
 Another issue is more to do with code portability than with D2 itself. 
 That is, the meaning of 'const' has changed between D1 and D2, with 
 'invariant' effectively replacing what 'const' was used for in D1.  This 
 makes it impossible to create code that has the same meaning in both 
 versions of the language.  Eventually, D1 will be forgotten and no one 
 will care about this any more, but for Tango right now this is a 
 significant issue in my opinion.

look the full half. for tango right now it's an issue. tomorrow it won't.
 Much of the rest is cosmetic--the sort of thing Walter likes to call 
 "barn door" issues.  I hate that we're stuck with 'enum' to signify 
 manifest constants, for example.  Heck, I hate that D supports anonymous 
 enums at all, but making this an official feature in D2 is just crazy 
 IMO.  Maybe not a big deal to you, but what drew me to D in the first 
 place were largely what I'd consider cosmetic improvements over C++.

it's a big issue to me just in the opposite direction. the c enum is brain damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on the definition syntax. so i guess that does mean somethin'.) the c++ enum grew one lonely neuron. problem is we got just used to the wrong. we won't blink an eye at enum { a = 1, b = 2 }; but we get pissed at enum { a = 1.1, b = 2.5 }; i myself was pissed to no end there was no way to define true constants in c++. so im super happy walter fixed that. how others can actually have a problem with that is beyond me. i had an old ford when i was a kid. it had a fidgety starter. only dad and i could start the car. just like in bttf. one day i'd opened it already so i fixed the starter. guess what. somehow i missed the old bad starter. i'd gotten used to it. but then i had a reason. now sis could start the car too. enum ain't a problem. get over urself already.
  > i know i switched to d2 as soon as it was out. i have nuff freedom  
  > work to write at least part of my code in whatever. the more versions
  > arrive with new stuff the more d1 looks to me like an ass-backwards
  > neanderthal tool made of sticks bear claws and silex. could even go as
  > far as sayin' d1 ain't ever gonna make it to prime time. it's just a
  > cute lil language that has a few merits marred by its issues. all
 languages  are like that. d2... d2 feels different because it is

 ways.  and leave no shit behind like most languages do

> and the new team has much more knowledge than walt alone. (sorry > walt. but i guess u'd agree.) Yeah, D1 is a cute little language, but it's eminently usable. All D2 really has going for it at the moment is the const stuff, and I quite honestly don't care about that.

you gotta be intercoursin' kiddin' me. hellooo. concepts. i came to the point where i call bullsolidwaste on unconstrained templates. all templates should be constrained. also destructors and the postblit business. now i can have automatic cleanup like in c++. better yet there's gc so i dun need to clean up a lot of stuff. only files'n stuff. guess someone's not keepin' with'em news.
  This isn't because I don't work on 
 projects large enough to require it--my last project was a few million 
 lines of C++ maintained by a decent sized team--but rather because I 
 feel that inelegant syntax is a greater issue for maintenance than 
 language support for data mutability.  I'd simply rather have nothing 
 than something that I think will produce unmaintainable code.
 
 so sean. how much d2 did you write. hope you agree it's hard to claim it has
no practical advantages if you haven't practically used it. the irony, eh.

Not enough to speak with experience, quite honestly. Perhaps that will chance with this shared runtime business.

then quite honestly ur naysayin' is tenuous.
Aug 25 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
superdan wrote:
 it's a big issue to me just in the opposite direction. the c enum is brain
damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on
the definition syntax. so i guess that does mean somethin'.) the c++ enum grew
one lonely neuron. problem is we got just used to the wrong. we won't blink an
eye at
 
 enum { a = 1, b = 2 };
 
 but we get pissed at
 
 enum { a = 1.1, b = 2.5 };

I see the first as a problem, too. An enum is an _enumeration_. It should not be abused for bitfields, masks, constants or anything else. Look at how it's used in Java/C# (ignoring the fact that Java's enum is actually syntactic sugar for a class...): - Only named enums are supported (otherwise, what are you enumerating?) - They can't be used as bitfields/masks (constants can be used for this purpose) - You can't define them as arbitrary values. In D, it's all water under the bridge and it's just a keyword; it doesn't matter that much. That being said, it's still a bad selection of keyword IMO and there's no argument that's going to convince me that `enum string CRLF = "\r\n";` is somehow an _enumeration_.
Aug 25 2008
next sibling parent reply superdan <super dan.org> writes:
Robert Fraser Wrote:

 superdan wrote:
 it's a big issue to me just in the opposite direction. the c enum is brain
damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on
the definition syntax. so i guess that does mean somethin'.) the c++ enum grew
one lonely neuron. problem is we got just used to the wrong. we won't blink an
eye at
 
 enum { a = 1, b = 2 };
 
 but we get pissed at
 
 enum { a = 1.1, b = 2.5 };

I see the first as a problem, too. An enum is an _enumeration_.

yeah. an enumerated type to be pedantic. as in, let me enumerate some stuff. i don't see an integer following from that.
 It 
 should not be abused for bitfields, masks, constants or anything else. 

that's not an abuse. it's just use. let me enumerate some math constants. enum math_constants { pi = 3.14, e = 2.71, avocado = 6.023e-23, } there was no abuse, your honor.
 Look at how it's used in Java/C# (ignoring the fact that Java's enum is 
 actually syntactic sugar for a class...):
 
 - Only named enums are supported (otherwise, what are you enumerating?)

i am enumerating symbolic constants that logically belong together but don't have the same type.
 - They can't be used as bitfields/masks (constants can be used for this 
 purpose)

but enums are constants. so it looks like those doods got it all wrong because they have two concepts for the same thing.
 - You can't define them as arbitrary values.

how do you mean that. must pi be 10./3. or what.
 In D, it's all water under the bridge and it's just a keyword; it 
 doesn't matter that much. That being said, it's still a bad selection of 
 keyword IMO and there's no argument that's going to convince me that 
 `enum string CRLF = "\r\n";` is somehow an _enumeration_.

no but if you put it like this maybe it changes your perspective. enum line_terminator { crlf = "\r\n", cr = "\r", lf = "\n", lfcr = "\n\r" } eh.
Aug 25 2008
parent Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Robert Fraser Wrote:
 
 superdan wrote:
 it's a big issue to me just in the opposite direction. the c enum is brain
damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on
the definition syntax. so i guess that does mean somethin'.) the c++ enum grew
one lonely neuron. problem is we got just used to the wrong. we won't blink an
eye at

 enum { a = 1, b = 2 };

 but we get pissed at

 enum { a = 1.1, b = 2.5 };


yeah. an enumerated type to be pedantic. as in, let me enumerate some stuff. i don't see an integer following from that.

That's fine. I'd be okay with enumerated types containing floating point values, strings, whatever. But they should always have a name. Using them to declare globally usable constants is just wrongheaded.
 It 
 should not be abused for bitfields, masks, constants or anything else. 

that's not an abuse. it's just use. let me enumerate some math constants. enum math_constants { pi = 3.14, e = 2.71, avocado = 6.023e-23, } there was no abuse, your honor.
 Look at how it's used in Java/C# (ignoring the fact that Java's enum is 
 actually syntactic sugar for a class...):

 - Only named enums are supported (otherwise, what are you enumerating?)

i am enumerating symbolic constants that logically belong together but don't have the same type.

Yeah, I see what you're saying. I'd say that it's logically a mis-use of 'enum', but it does the trick.
 - They can't be used as bitfields/masks (constants can be used for this 
 purpose)

but enums are constants. so it looks like those doods got it all wrong because they have two concepts for the same thing.

I disagree. An enum is a constrained type. Each element of an enum does happen to be a constant, but so what. More general constrained types would be similar: int[0..5] x; // an integer required to be between 0 and 5 Sean
Aug 26 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:
 I see the first as a problem, too. An enum is an _enumeration_. It 
 should not be abused for bitfields, masks, constants or anything else. 
 Look at how it's used in Java/C# (ignoring the fact that Java's enum is 
 actually syntactic sugar for a class...):
 
 - Only named enums are supported (otherwise, what are you enumerating?)
 - They can't be used as bitfields/masks (constants can be used for this 
 purpose)
 - You can't define them as arbitrary values.

Take C# this example from my job: [Flags] // hint to the compiler: treat it as a bitfield public enum DaysOfWeek { Monday = 1, Tuesday = 2, Wednesday = 4, Thursday = 8, Friday = 16, Saturday = 32, Sunday = 64, None = 0, All = 127 } DaysOfWeek weekends = DaysOfWeek.Saturday | DaysOfWeek.Sunday;
 In D, it's all water under the bridge and it's just a keyword; it 
 doesn't matter that much. That being said, it's still a bad selection of 
 keyword IMO and there's no argument that's going to convince me that 
 `enum string CRLF = "\r\n";` is somehow an _enumeration_.

You wouldn't get to the keyword "enum" just from the definition of "enumeration". But it's not too far from the previous usage.
Aug 25 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Robert Fraser wrote:
 superdan wrote:
 it's a big issue to me just in the opposite direction. the c enum is 
 brain damaged. even dennis ritchie so much as acknowledged it. (and he 
 won't budge on the definition syntax. so i guess that does mean 
 somethin'.) the c++ enum grew one lonely neuron. problem is we got 
 just used to the wrong. we won't blink an eye at

 enum { a = 1, b = 2 };

 but we get pissed at

 enum { a = 1.1, b = 2.5 };

I see the first as a problem, too. An enum is an _enumeration_. It should not be abused for bitfields, masks, constants or anything else. Look at how it's used in Java/C# (ignoring the fact that Java's enum is actually syntactic sugar for a class...): - Only named enums are supported (otherwise, what are you enumerating?) - They can't be used as bitfields/masks (constants can be used for this purpose) - You can't define them as arbitrary values. In D, it's all water under the bridge and it's just a keyword; it doesn't matter that much. That being said, it's still a bad selection of keyword IMO and there's no argument that's going to convince me that `enum string CRLF = "\r\n";` is somehow an _enumeration_.

Right. I simply disagree with the suggestion that a label is a label and we should forget about it and move on. If a word is used to represent something then the representation should be consistent with the meaning of the word, not some outdated convention from a language where the feature is considered a mistake anyway. I'd prefer to take the long view... when teaching D to college students in 10 years, what kind of answer is "well, it derives from a broken convention in a language you've never heard of" to the question "why does D use 'enum' to represent manifest constants?" However, I realize this will never change so I'll suppress my angst and move on ;-) Sean
Aug 26 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
superdan wrote:
 Sean Kelly Wrote:
 
 superdan wrote:
 Sean Kelly Wrote:

 Brian Price wrote:
 My take on the Tango vs Phobos situation is:

 For production use the only real choice is D1 (D2 being alpha) and it looks
like
 there are going to be so many changes in the language that going from a D1 app
to
 a D2 app is going to require more than a bit of work and thought.

likely to occur with D1 / Phobos1 because that version of D is frozen. So from a practical standpoint I think Tango and Tangobos will continue to be the preferred approach for development under D1.
 So, restricting the answer to D1, Tango seems to be a more full featured ,
robust,
 and maintained library than Phobos.  I'd expect that to change in D2 and expect
 the natural choice there will be Phobos (barring a ton of work by the Tango
crew).

some of the features in tango.core are exposed. I would obviously prefer if Phobos just built on top of Tango as with the Tango / Tangobos solution for D1, but that doesn't seem likely to happen.

 Regardless of the choice of library for use with D1, moving to D2 with either
 library looks like a chore since Phobos seems to be undergoing some (much
needed)
 significant changes from D1 to D2 versions.

 As to the larger topic, D is potentially caught on the horns of a dilemma: D1
is
 not a significant enough advance on current languages to justify a move even if
 there were no library concerns; D2 may well be enough of a step forward to
justify
 a move but there is the issue of timing.  My take is that if the upcoming C++
 standard makes it into compilers used in common production before D2 is ready
for
 prime time that D may never gain a real foothold in mainstream use.  I'm hoping
 that the D2 team sets a deadline and leaves some things for a future D3 rather
 than miss the window of opportunity.

are quite substantial but difficult to quantify. The elegance of the language tends to produce vastly more maintainable code than C++, for example, which is a huge win for team development. As far as D2 is concerned, I think it's really too early to say. My current opinion is that the feature additions in D2 impact the syntax in such a way that they eliminate much of the advantage of D1--stemming from elegance and simplicity--in exchange for largely theoretical benefits. But D2 is still in development so who knows.


parallels with C++. For example, one of my major issues with D2 is the syntax of the const design. It's theoretically pretty slick, but I'm not at all happy with the prospect of maintaining duplicate function implementations simply to overload on const. This is one of the things that drove me crazy about C++, and D2 is even worse in this regard because it has not only 'const' but 'invariant' as well. And don't say "don't like const, don't use it," because that isn't an option for me as a library developer.

not sure why you keep on sneaking that `theoretically' word in. duplicate code blows, theoretically and practically. yeah that pisses me off too. i managed to avoid duplication thru concepts. dont 4get u only need to do that when you want the qualifier in the return type. often you don't. you can also rely on auto because now it deduces the return type for you. i recall walter promised he'll look into that. but i'm not holding my breath eh. constrained templates do the work for me no problem.
 Another issue is more to do with code portability than with D2 itself. 
 That is, the meaning of 'const' has changed between D1 and D2, with 
 'invariant' effectively replacing what 'const' was used for in D1.  This 
 makes it impossible to create code that has the same meaning in both 
 versions of the language.  Eventually, D1 will be forgotten and no one 
 will care about this any more, but for Tango right now this is a 
 significant issue in my opinion.

look the full half. for tango right now it's an issue. tomorrow it won't.
 Much of the rest is cosmetic--the sort of thing Walter likes to call 
 "barn door" issues.  I hate that we're stuck with 'enum' to signify 
 manifest constants, for example.  Heck, I hate that D supports anonymous 
 enums at all, but making this an official feature in D2 is just crazy 
 IMO.  Maybe not a big deal to you, but what drew me to D in the first 
 place were largely what I'd consider cosmetic improvements over C++.

it's a big issue to me just in the opposite direction. the c enum is brain damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on the definition syntax. so i guess that does mean somethin'.) the c++ enum grew one lonely neuron. problem is we got just used to the wrong. we won't blink an eye at enum { a = 1, b = 2 }; but we get pissed at enum { a = 1.1, b = 2.5 }; i myself was pissed to no end there was no way to define true constants in c++. so im super happy walter fixed that. how others can actually have a problem with that is beyond me. i had an old ford when i was a kid. it had a fidgety starter. only dad and i could start the car. just like in bttf. one day i'd opened it already so i fixed the starter. guess what. somehow i missed the old bad starter. i'd gotten used to it. but then i had a reason. now sis could start the car too. enum ain't a problem. get over urself already.

My problem isn't with the concept, it's with the word. That's why I said it's a "barn door" issue. To me, the meaning of 'enum' is "enumerated type." It has nothing to do with declaring manifest constants. That's why I also think that anonymous enums should be illegal. Just give us a new label for this stuff ("manifest" was proposed). Or heck, make constants not addressable and eliminate storage for the altogether. I can't think of a single instance in my time as a programmer where I actually wanted to take the address of a constant. What's the point? You can't modify it anyway.
  > i know i switched to d2 as soon as it was out. i have nuff freedom  
  > work to write at least part of my code in whatever. the more versions
  > arrive with new stuff the more d1 looks to me like an ass-backwards
  > neanderthal tool made of sticks bear claws and silex. could even go as
  > far as sayin' d1 ain't ever gonna make it to prime time. it's just a
  > cute lil language that has a few merits marred by its issues. all
 languages  are like that. d2... d2 feels different because it is

 ways.  and leave no shit behind like most languages do

> and the new team has much more knowledge than walt alone. (sorry > walt. but i guess u'd agree.) Yeah, D1 is a cute little language, but it's eminently usable. All D2 really has going for it at the moment is the const stuff, and I quite honestly don't care about that.

you gotta be intercoursin' kiddin' me. hellooo. concepts. i came to the point where i call bullsolidwaste on unconstrained templates. all templates should be constrained. also destructors and the postblit business. now i can have automatic cleanup like in c++. better yet there's gc so i dun need to clean up a lot of stuff. only files'n stuff.

Concepts can be done in D1 as well. The D2 stuff is just syntactic sugar for: void fn(T, bool cond : true = SomeTest!(T))( T val ) {} I've been doing this sort of thing in Tango forever. That isn't to say that I don't want real concept support--I totally do--it just isn't worth some of the other baggage in D2 right now. Tell you the truth, what I probably want most from D2 is overload sets. Function overloading in D1 just plain sucks and is a constant annoyance for me. Fixing this alone is enough to make me put up with a lot of other stuff I don't like. But on the flip side I can't actually use it yet because Tango has to work on D1 as well.
 guess someone's not keepin' with'em news.

Nah. I only care about features I can't fake in D1 already.
  This isn't because I don't work on 
 projects large enough to require it--my last project was a few million 
 lines of C++ maintained by a decent sized team--but rather because I 
 feel that inelegant syntax is a greater issue for maintenance than 
 language support for data mutability.  I'd simply rather have nothing 
 than something that I think will produce unmaintainable code.

 so sean. how much d2 did you write. hope you agree it's hard to claim it has
no practical advantages if you haven't practically used it. the irony, eh.

chance with this shared runtime business.

then quite honestly ur naysayin' is tenuous.

I said at the start that it's my current opinion and may change, so yeah, it's totally tenuous. Sean
Aug 26 2008
parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 superdan wrote:
 enum ain't a problem. get over urself already.

My problem isn't with the concept, it's with the word. That's why I said it's a "barn door" issue. To me, the meaning of 'enum' is "enumerated type." It has nothing to do with declaring manifest constants.

guess u have to retake the driving test then. enumerated type means: i enumerate this type's possible values. they are necessarily constants. and since they are there they are manifest. viola. da gamba.
 That's why I also think that anonymous enums should be 
 illegal.

then anonymous classes should be illegal too?
  Just give us a new label for this stuff ("manifest" was 
 proposed).

talkin' about that long view of yers. imagine teaching kids. hey-hey, kids. today we do constant definitions. well, we sure aren't lackin'em. the more the merrier. const a = 1; invariant a = 1; enum { a = 1 } manifest a = 1; kid #1: teacher, what's the diff between const and invariant? teacher: in this case none. kid #2: how about enum and invariant? teacher: in all cases none. kid #3: why both const and invariant? teacher: they have different meanings as we talked yesterday in the megacore class. kid #4: but why both enum and manifest if they're always the same thing? teacher: oops, bell's ringin'. don't forget the homework for tomorrow: implement opIndex in o(n).
  Or heck, make constants not addressable and eliminate 
 storage for the altogether.

that ruins everything about const.
  I can't think of a single instance in my 
 time as a programmer where I actually wanted to take the address of a 
 constant.  What's the point?  You can't modify it anyway.

taking a slice off a const string.
  > i know i switched to d2 as soon as it was out. i have nuff freedom  
  > work to write at least part of my code in whatever. the more versions
  > arrive with new stuff the more d1 looks to me like an ass-backwards
  > neanderthal tool made of sticks bear claws and silex. could even go as
  > far as sayin' d1 ain't ever gonna make it to prime time. it's just a
  > cute lil language that has a few merits marred by its issues. all
 languages  are like that. d2... d2 feels different because it is

 ways.  and leave no shit behind like most languages do

> and the new team has much more knowledge than walt alone. (sorry > walt. but i guess u'd agree.) Yeah, D1 is a cute little language, but it's eminently usable. All D2 really has going for it at the moment is the const stuff, and I quite honestly don't care about that.

you gotta be intercoursin' kiddin' me. hellooo. concepts. i came to the point where i call bullsolidwaste on unconstrained templates. all templates should be constrained. also destructors and the postblit business. now i can have automatic cleanup like in c++. better yet there's gc so i dun need to clean up a lot of stuff. only files'n stuff.

Concepts can be done in D1 as well. The D2 stuff is just syntactic sugar for: void fn(T, bool cond : true = SomeTest!(T))( T val ) {} I've been doing this sort of thing in Tango forever. That isn't to say that I don't want real concept support--I totally do--it just isn't worth some of the other baggage in D2 right now.

see here's some fud again.
  Tell you the truth, 
 what I probably want most from D2 is overload sets.  Function 
 overloading in D1 just plain sucks and is a constant annoyance for me. 
 Fixing this alone is enough to make me put up with a lot of other stuff 
 I don't like.  But on the flip side I can't actually use it yet because 
 Tango has to work on D1 as well.

overload sets are cool. guess if i were a shrink i'd say ur beef with d2 is that u have this tango/d1 worry hangin' over ya.
 guess someone's not keepin' with'em news.

Nah. I only care about features I can't fake in D1 already.
  This isn't because I don't work on 
 projects large enough to require it--my last project was a few million 
 lines of C++ maintained by a decent sized team--but rather because I 
 feel that inelegant syntax is a greater issue for maintenance than 
 language support for data mutability.  I'd simply rather have nothing 
 than something that I think will produce unmaintainable code.

 so sean. how much d2 did you write. hope you agree it's hard to claim it has
no practical advantages if you haven't practically used it. the irony, eh.

chance with this shared runtime business.

then quite honestly ur naysayin' is tenuous.

I said at the start that it's my current opinion and may change, so yeah, it's totally tenuous.

cool. then guess u can help it.
Aug 26 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Sean Kelly wrote:
 
 Another issue is more to do with code portability than with D2 itself.
 That is, the meaning of 'const' has changed between D1 and D2, with
 'invariant' effectively replacing what 'const' was used for in D1.  This
 makes it impossible to create code that has the same meaning in both
 versions of the language.

What if D1 was augmented to allow the keyword invariant in those cases where D2 has a conflicting meaning for const? That wouldn't break any D1 code or add any functionality. I think it's a fair request.
Aug 25 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 d2... d2 feels different because it is
 different. larger ambitions to address real problems in innovative
 ways. and leave no shit behind like most languages do in pursuit of
 the mother of all features. and the new team has much more knowledge
 than walt alone. (sorry walt. but i guess u'd agree.)

I would agree. D1 was about at the limit of my abilities. D2 goes way beyond that, and that is possible because it is much more of a team effort.
Aug 25 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Vincent Richomme wrote:
 Yigal Chripun a écrit :
 Sean Kelly wrote:
  > I'd prefer being able to choose the GC I want without needing the
 compiler vendor to supply it.  Otherwise, the compiler vendor either
 needs to know how to write a GC (unlikely) or they need to bundle a
 third-party GC.  Also, different applications have different memory
 requirements.  Tango allows the GC to be chosen at link-time, which
 allows for a great deal of flexibility. 

If we compare to Java than Sun provides more than one GC with its runtime and you can get even more specialized version GC if you really need it (real-time for example). I guess there's nothing wrong in getting a third party GC either. The point is that in Java those GCs are chosen by the runtime (you can specify if you run your app as a server or a client app and based on that the GC is chosen) or you can specify explicitly your GC too, I guess. Non of that should affect your code (unless you choose to use specific extensions to the GC API provided but a specialized GC). So, the choice of a GC doesn't affect your code.
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor 
 B's
 GC if it's faster, etc..

use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)


it is an issue with the compiler runtime/GC if there isn't a standard API and when I change my GC/runtime I need to edit the source.

What I would like to know now: is there any progress between this Tango vs Phobos discussion... I still don't know if I can rely on Tango for my dev or on phobos and I think I am not the only one.

Yes. Sean
Aug 25 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Yigal Chripun wrote:
 Sean Kelly wrote:
  > I'd prefer being able to choose the GC I want without needing the
 compiler vendor to supply it.  Otherwise, the compiler vendor either
 needs to know how to write a GC (unlikely) or they need to bundle a
 third-party GC.  Also, different applications have different memory
 requirements.  Tango allows the GC to be chosen at link-time, which
 allows for a great deal of flexibility. 

If we compare to Java than Sun provides more than one GC with its runtime and you can get even more specialized version GC if you really need it (real-time for example). I guess there's nothing wrong in getting a third party GC either. The point is that in Java those GCs are chosen by the runtime (you can specify if you run your app as a server or a client app and based on that the GC is chosen) or you can specify explicitly your GC too, I guess. Non of that should affect your code (unless you choose to use specific extensions to the GC API provided but a specialized GC). So, the choice of a GC doesn't affect your code.

It shouldn't, or there would be little point in supporting swappable GCs.
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor B's
 GC if it's faster, etc..

use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)


it is an issue with the compiler runtime/GC if there isn't a standard API and when I change my GC/runtime I need to edit the source.

Fortunately, Tango provides such a "standard API" so no source changes are needed unless you do something like drop in a "GC" that simply calls malloc and free, in which case your app will leak if it isn't written with this in mind. Sean
Aug 25 2008
parent Josh Szepietowski <Goosey gmail.com> writes:
Sean Kelly Wrote:

 Yigal Chripun wrote:
 Sean Kelly wrote:
  > I'd prefer being able to choose the GC I want without needing the
 compiler vendor to supply it.  Otherwise, the compiler vendor either
 needs to know how to write a GC (unlikely) or they need to bundle a
 third-party GC.  Also, different applications have different memory
 requirements.  Tango allows the GC to be chosen at link-time, which
 allows for a great deal of flexibility. 

If we compare to Java than Sun provides more than one GC with its runtime and you can get even more specialized version GC if you really need it (real-time for example). I guess there's nothing wrong in getting a third party GC either. The point is that in Java those GCs are chosen by the runtime (you can specify if you run your app as a server or a client app and based on that the GC is chosen) or you can specify explicitly your GC too, I guess. Non of that should affect your code (unless you choose to use specific extensions to the GC API provided but a specialized GC). So, the choice of a GC doesn't affect your code.

It shouldn't, or there would be little point in supporting swappable GCs.
 The benefit is that the vendors will compete for runtime performance
 which is good for the end user. I can choose vendor A's GC since it is
 more efficient with regards to memory (if I care for that) or vendor B's
 GC if it's faster, etc..

use the best of breed of each.
 All I care is that everything that is visible to the end user is
 standardized - i.e. I can do GC.collect() in my code since it's in the
 APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
 for performance reasons and such of course and for that I can just
 switch to a different vendor without any code changes)


it is an issue with the compiler runtime/GC if there isn't a standard API and when I change my GC/runtime I need to edit the source.

Fortunately, Tango provides such a "standard API" so no source changes are needed unless you do something like drop in a "GC" that simply calls malloc and free, in which case your app will leak if it isn't written with this in mind. Sean

Just wanted to voice that being able to overload the GC functions as in the D Conference 2007 talk is kind of a killer feature for me. Whatever shakedown happens from the phobos/tango runtime unificiation (which IMHO should be the first priority for the D 'standard library community') I really hope the swappable GC functions stay.
Aug 25 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Yigal Chripun wrote:
 Lars Ivar Igesund wrote:
 Lutger wrote:

 Lars Ivar Igesund wrote:

 Steven Schveighoffer wrote:
  
 This is my view (might not work, but I think it could).  For purposes of
 simplicity, I'll assume Walter currently develops the Phobos runtime
 (not that he doesn't, but I'm really not sure :).

 Maintenance of the merged runtime would become Walter's responsibility,
 with your help if necessary (ideas and help understanding, and
 enhancements if
 you wish).  Any changes desired for the runtime would go through Phobos
 (and
 Walter).  The Tango lib would use the now tango-fied Phobos runtime,
 with alias imports for existing code (e.g. tango.core.Thread would
 either publicly import std.thread or would privately import it, and
 alias the Thread class).

idea. The current situation ensued for a reason. Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.

existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
  
 If there should be a common-common (not only "just" compatible) runtime,
 it shouldn't be controlled by one compiler vendor. Note that the Tango
 runtime consists of 3 parts, where only one is compiler specific. That
 particular part should probably be controlled/reviewed by the compiler
 vendor, the rest (GC, threading, other things) should be independent.

even further fragmentation and non-portability.

course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

I don't understand your point. are you suggesting that things like the GC will be independent from the compiler? It seems to me that the model suggested by Sean is the way to go: ie: my code ---------- standard library user code and standardized APIs to the runtime (threading, etc --------------------------------- compiler + runtime A | compiler + runtime B | ..... if a user isn't satisfied by runtime/compiler A he should just switch vendors. All the user facing APIs are standardized in the stdlib so all is needed is to recompile..

I think it's worth distinguishing a bit more detail: my code -------------------------- standard library | ------------------------------------------------------- compiler runtime | garbage collector | std. lib runtime With the above model, the runtime is actually made up of three distinct components: the compiler support code, the GC, and some user-visible runtime code which I've termed the "standard library runtime." This model provides a clear division of labor: the compiler writer worries only about the compiler support code, OS geeks can create the GC, and library programmers can work on the library bit. Sean
Aug 18 2008
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Lars Ivar Igesund wrote:

 Lutger wrote:

 How does it ignore it? It sounds rather like the opposite to me: the very
 existence of multiple runtimes and the vested interest in those runtimes
 (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.

Ok I think I understand and agree that some room for this potential would be good, of course. What I'm worried about is that D libraries will depend on specific api (not only implementation) of the runtime, which could lead to a mess when we'll have more and more of such implementations. Simply put, I'm afraid that in the future to make a cross-platform code we'll have to do something equivalent to a C++ header file consisting of dozens of bizarre #ifdef ... #elif etc. logic. Or worse, need a massive porting effort or wrapping libraries a la tangobos if you need a D library developed for a different compiler. Perhaps more interfaces could be standardized? I don't know. I'd hate to see a thread in some years called 'phobos vs tango vs dil vs dang vs llvmdc vs etc.' ;) </hyperbole>
Aug 16 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lutger wrote:

 Lars Ivar Igesund wrote:
 
 Lutger wrote:

 How does it ignore it? It sounds rather like the opposite to me: the
 very existence of multiple runtimes and the vested interest in those
 runtimes (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.

Ok I think I understand and agree that some room for this potential would be good, of course. What I'm worried about is that D libraries will depend on specific api (not only implementation) of the runtime, which could lead to a mess when we'll have more and more of such implementations. Simply put, I'm afraid that in the future to make a cross-platform code we'll have to do something equivalent to a C++ header file consisting of dozens of bizarre #ifdef ... #elif etc. logic. Or worse, need a massive porting effort or wrapping libraries a la tangobos if you need a D library developed for a different compiler.

A way to ensure that there are common, good and well defined interfaces is what I try to hint at. I don't think all of those can be properly achieved by letting one vendor decide. I also think that having a common place to have the compiler independent implementation would help this goal, ie that compiler vendors don't need to write this themselves. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 16 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Lutger wrote:
 Lars Ivar Igesund wrote:
 
 Lutger wrote:

 How does it ignore it? It sounds rather like the opposite to me: the very
 existence of multiple runtimes and the vested interest in those runtimes
 (Tango's primarily) are the key reason for unification.

implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.

Ok I think I understand and agree that some room for this potential would be good, of course. What I'm worried about is that D libraries will depend on specific api (not only implementation) of the runtime, which could lead to a mess when we'll have more and more of such implementations.

This is why the Tango runtime is designed the way it is -- it eliminates all dependency on standard library implementation. The API exposed is very simply and completely portable.
 Simply put, I'm afraid that in the future to make a cross-platform code
 we'll have to do something equivalent to a C++ header file consisting of
 dozens of bizarre #ifdef ... #elif etc. logic. Or worse, need a massive
 porting effort or wrapping libraries a la tangobos if you need a D library
 developed for a different compiler.

And this is the reason for making the runtime separately available from /any/ standard library :-) Sean
Aug 18 2008
prev sibling parent sambeau <sambeau-nospam gmail.com> writes:
Lars Ivar Igesund Wrote:

 Based on historical evidence, this doesn't sound like a particularly good
 idea. The current situation ensued for a reason.

* sigh *
Aug 15 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 As far as threads, I agree.  One must be chosen.

The threading issue is more problematic. D 2.0 is doing a ground up rethink on how to approach threading, and it's hard to imagine that not impacting the threading part of the library. A common exception base is much more straightforward.
Aug 15 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Steven Schveighoffer wrote:
 As far as threads, I agree.  One must be chosen.

The threading issue is more problematic. D 2.0 is doing a ground up rethink on how to approach threading, and it's hard to imagine that not impacting the threading part of the library.

So is classic threading going to be thrown out entirely? If so then I guess it eliminates the problem of exposing a Thread class.
 A common exception base is much more straightforward.

Agreed. Sean
Aug 15 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 Steven Schveighoffer wrote:
 As far as threads, I agree.  One must be chosen.

The threading issue is more problematic. D 2.0 is doing a ground up rethink on how to approach threading, and it's hard to imagine that not impacting the threading part of the library.

So is classic threading going to be thrown out entirely? If so then I guess it eliminates the problem of exposing a Thread class.

I don't know. Bartosz is working on it. He understands the issues far better than I do. What I do believe is that handling concurrency well will be a breakthrough feature for D.
Aug 15 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 In this Specific case:
 Walter needs his name on all the Phobos code and he stated his valid
 reasons for it. Tango developers want their names on the Tango code and
 rightly so, since they wrote it. in case of a merger of those two code
 bases you get one joint code base but *two* teams that want their name
 on the code. someone has to be first.

No, I do not "need my name" on the Phobos code. I have no interest in taking credit for others' work. As I have stated previously, the idea here is to: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. It is not an issue of credit, I have no problem with (and strongly encourage) the people who wrote the code having their name in it and taking credit. At one point, Brad was trying to do some merging and was accused of "stealing" from Tango. I was told later that this was in jest, but this kind of thing cannot be taken lightly. Phobos needs to be squeaky clean in the legal department. I have done my part and have provided an explicit, clear, and unambiguous license for Tango to use whatever parts of Phobos they need and to put it under the Tango license (for all the parts for which I have a right to do so). All I ask is for a reciprocal agreement.
Aug 14 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright wrote:
 Yigal Chripun wrote:
 In this Specific case:
 Walter needs his name on all the Phobos code and he stated his valid
 reasons for it. Tango developers want their names on the Tango code and
 rightly so, since they wrote it. in case of a merger of those two code
 bases you get one joint code base but *two* teams that want their name
 on the code. someone has to be first.

No, I do not "need my name" on the Phobos code. I have no interest in taking credit for others' work. As I have stated previously, the idea here is to: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. It is not an issue of credit, I have no problem with (and strongly encourage) the people who wrote the code having their name in it and taking credit. At one point, Brad was trying to do some merging and was accused of "stealing" from Tango. I was told later that this was in jest, but this kind of thing cannot be taken lightly. Phobos needs to be squeaky clean in the legal department. I have done my part and have provided an explicit, clear, and unambiguous license for Tango to use whatever parts of Phobos they need and to put it under the Tango license (for all the parts for which I have a right to do so). All I ask is for a reciprocal agreement.

Walter, from my POV which is that of a user, all I see is a huge storm in a cup of water from a year ago. I do not take a side in this nor do I care for the issues both sides raise. as I've said in my previous post which is quoted in this post already and I'll quote here again "[Walter] stated his valid reasons". So you see, I do not question your reasons. All I see as a user is that Steven compared the licenses and they're almost Identical, Sean Kelly has given you permission to all his code and I see his posts and see no reason this hasn't been solved a year ago. I'm a user. I should not care if contributer A insulted/jested with Developer B. Since you do not have any issues with giving credit (where it is due) and Sean gave you a free hand with all his code, All of your points above are achieved in regard to the runtime. You want more prove to see the authors of the runtime? Check the version control logs. But really, unless this issue is solved and solved *soon*, both versions of D are a dead end. This is far more important to resolve than any new feature in D2. again, as an average user that just want to use D, I can happily live without array ops, native thread local memory and other features for a few months, But I really must insist that D needs a standardized runtime library, now. otherwise I have no use for D at all no matter what fancy tricks it has under its sleeves. The only thing left to say is that this should be handled in the same way a pope is selected: all cardinals gather in his room and they are not allowed to leave this room until a new pope is selected which is signaled by white smoke. (I've been to Italy and the guide showed us where it supposed to come from). this is what currently needed to solve this. put everything else aside (both you and the Tango devs) and give us white smoke. until I see that white smoke coming from this NG, I (and I'm sure many others) will see no future in D.
Aug 14 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 Since you do not have any issues with giving credit (where it is due)
 and Sean gave you a free hand with all his code, All of your points
 above are achieved in regard to the runtime.

Sean has sent me a zip of the runtime code that he owns. I think that will be adequate to resolve the problem.
Aug 14 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

From phobos/phoboslicense.txt: * Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com * Written by Walter Bright (followed by BSD license) Those lines are an issue. Are you asking for copyright assignment? That's a bit much to ask. An alternative problem is this: * Placed in the Public Domain A number of modules in phobos/internal are marked public domain. Are you asking for Tango's internals to be placed in the public domain? That also is a bit much to ask. The BSD license is simply public domain with attribution. So what is the issue with using it? Phobos already uses it. Just with your name as the copyright holder. Or do you want an agreement to allow relicensing of Phobos and Tango, let's say to incompatible licenses, and still allow Phobos and Tango to share code afterward? It's unclear what you want or need that you don't already have.
Aug 14 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Christopher Wright wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

From phobos/phoboslicense.txt: * Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com * Written by Walter Bright (followed by BSD license) Those lines are an issue. Are you asking for copyright assignment? That's a bit much to ask. An alternative problem is this: * Placed in the Public Domain A number of modules in phobos/internal are marked public domain. Are you asking for Tango's internals to be placed in the public domain? That also is a bit much to ask.

Walter is asking for us to give him the right to distribute any and all of Tango within Phobos under the Public Domain license. What I've never understood is why it's enough for myself, Kris, and Lars to provide this permission when Tango has had a ton of individual contributors. But then I am not a lawyer. Sean
Aug 14 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Walter is asking for us to give him the right to distribute any and all 
 of Tango within Phobos under the Public Domain license.  What I've never 
 understood is why it's enough for myself, Kris, and Lars to provide this 
 permission when Tango has had a ton of individual contributors.  But 
 then I am not a lawyer.

Because you guys are the leaders and spokesmen for Tango. But that's moot at the moment anyway, because it seems what you have provided is sufficient, and I thank you for that.
Aug 14 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

From phobos/phoboslicense.txt: * Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com * Written by Walter Bright (followed by BSD license) Those lines are an issue. Are you asking for copyright assignment? That's a bit much to ask.

I've provided the same to Tango.
 An alternative problem is this:
  *  Placed in the Public Domain
 
 A number of modules in phobos/internal are marked public domain. Are you 
 asking for Tango's internals to be placed in the public domain? That 
 also is a bit much to ask.

Why is it a bit much to ask?
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.
 So what is the 
 issue with using it? Phobos already uses it. Just with your name as the 
 copyright holder.
 
 Or do you want an agreement to allow relicensing of Phobos and Tango, 
 let's say to incompatible licenses, and still allow Phobos and Tango to 
 share code afterward?
 
 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption. 2. Having multiple licenses for one source module is an untenable situation.
Aug 14 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:
 The problems are two:
 
 1. Phobos has already been accused of stealing code from Tango. 
 Therefore, I would like explicit permission from the Tango team. I am 
 not going to take code from Tango and put it in Phobos without explicit 
 permission from the Tango team. Any hint of Phobos not having a clean 
 legal pedigree will impair its adoption.
 
 2. Having multiple licenses for one source module is an untenable situation.

From reading this thread, it seems Sean gave permission for the Tango runtime to be re-licensed under the Phobos one. Given this, is the roadblock that you also need permission for the user code or that Sean's permission given for the runtime was not explicit enough?
Aug 14 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Christopher Wright wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they 
 see
 fit, and I respect that and so have not spoken out on it before. 
 But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

From phobos/phoboslicense.txt: * Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com * Written by Walter Bright (followed by BSD license) Those lines are an issue. Are you asking for copyright assignment? That's a bit much to ask.

I've provided the same to Tango.

If you had assigned your copyright to the Tango developers, then the files would read: * Copyright (C) 2004-2005 by Sean Kelly, Lars Ivar Igesund, Don Clugson....
 An alternative problem is this:
  *  Placed in the Public Domain

 A number of modules in phobos/internal are marked public domain. Are 
 you asking for Tango's internals to be placed in the public domain? 
 That also is a bit much to ask.

Why is it a bit much to ask?

The BSD license allows anyone to do anything with the work as long as the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code. I don't believe that you would do so. But by requiring Tango to be placed in the public domain, you're allowing everyone else to do so.
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.
 So what is the issue with using it? Phobos already uses it. Just with 
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and Tango, 
 let's say to incompatible licenses, and still allow Phobos and Tango 
 to share code afterward?

 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?
 2. Having multiple licenses for one source module is an untenable 
 situation.

You can license any merged modules under the BSD license, unless they are under some other license currently. Public domain isn't a license, and it's compatible with every license.
Aug 14 2008
parent reply superdan <super dan.org> writes:
Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. Are 
 you asking for Tango's internals to be placed in the public domain? 
 That also is a bit much to ask.

Why is it a bit much to ask?

The BSD license allows anyone to do anything with the work as long as the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

you're not following what walt says eh. his problem is not he wanna steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.
 I don't believe that you would do so. But by requiring Tango to be 
 placed in the public domain, you're allowing everyone else to do so.

he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.

 So what is the issue with using it? Phobos already uses it. Just with 
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and Tango, 
 let's say to incompatible licenses, and still allow Phobos and Tango 
 to share code afterward?

 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?

no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.
Aug 14 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. Are
 you asking for Tango's internals to be placed in the public domain?
 That also is a bit much to ask.

Why is it a bit much to ask?

The BSD license allows anyone to do anything with the work as long as the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

you're not following what walt says eh. his problem is not he wanna steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.

The problem is, there is never a guarantee of that. Joe Shmoe can come along and claim that he works with Sean and Sean stole all his D Thread code and gave it to tango. Now, even though the entire Tango team has given permission to Walter, he is still in trouble. The answer is, either Walter accepts that Sean (and others who gave permission) are the rightful owners of the Tango runtime, and he has permission to use it, or Walter is so paranoid that he trusts nobody who says they own code, and he doesn't use it. He needs to have some faith that the person who says they own the code actually does.
 I don't believe that you would do so. But by requiring Tango to be
 placed in the public domain, you're allowing everyone else to do so.

he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

I agree with you on this, but the fact still remains that Walter is not safe as soon as he looks at any code, no matter who says they wrote it, unless he himself wrote it. I think this is taking it a little too extreme.
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.

 So what is the issue with using it? Phobos already uses it. Just with
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and Tango,
 let's say to incompatible licenses, and still allow Phobos and Tango
 to share code afterward?

 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?

no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.

The owners have given him permission, and promised not to slander. Anyone who cries foul after the rightful owners have given permission is full of crap, and I will be the first to say so. So long as Walter and co. just look at the proper files (the ones with the permission). Hell, I don't care if he looks at all of tango, as long as he either doesn't copy the code, or if he does, obeys the license requirements. I don't think any Tango devs are waiting to jump on Walter at the first chance Phobos is compatible with Tango. I think everyone in Tango is interested in having Phobos and Tango compatible. -Steve
Aug 14 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "superdan" wrote
 Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. Are
 you asking for Tango's internals to be placed in the public domain?
 That also is a bit much to ask.

Why is it a bit much to ask?

The BSD license allows anyone to do anything with the work as long as the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

you're not following what walt says eh. his problem is not he wanna steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.

The problem is, there is never a guarantee of that. Joe Shmoe can come along and claim that he works with Sean and Sean stole all his D Thread code and gave it to tango. Now, even though the entire Tango team has given permission to Walter, he is still in trouble.

do you want us to participate in a dialog. or revel in improbable possibilities. this is a red herring.
 The answer is, either Walter accepts that Sean (and others who gave 
 permission) are the rightful owners of the Tango runtime, and he has 
 permission to use it, or Walter is so paranoid that he trusts nobody who 
 says they own code, and he doesn't use it.  He needs to have some faith that 
 the person who says they own the code actually does.

i gather you don't quite read all messages. walt don't want to deliver a compiler with code he can't control. he must deliver code he can change. if that code works with tango walt must know what he gotta do. to do so he must look at tango. sean is cool with that. kris and lars "mi" ivar arent.
 I don't believe that you would do so. But by requiring Tango to be
 placed in the public domain, you're allowing everyone else to do so.

he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

I agree with you on this, but the fact still remains that Walter is not safe as soon as he looks at any code, no matter who says they wrote it, unless he himself wrote it. I think this is taking it a little too extreme.

yeah, ur interpretation. that's extreme.
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.

 So what is the issue with using it? Phobos already uses it. Just with
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and Tango,
 let's say to incompatible licenses, and still allow Phobos and Tango
 to share code afterward?

 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?

no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.

The owners have given him permission, and promised not to slander.

now i am sure u read every other message in this thread. go back and read'em all.
  Anyone 
 who cries foul after the rightful owners have given permission is full of 
 crap, and I will be the first to say so.

no permission was given. do you like me post drunk sometimes.
  So long as Walter and co. just 
 look at the proper files (the ones with the permission).  Hell, I don't care 
 if he looks at all of tango, as long as he either doesn't copy the code, or 
 if he does, obeys the license requirements.

_you_ don't care. others can't wait. they cried foul as soon as there was potential code could've been copied. gorramit. at least if there was da momma of all code. but it's java containers net stack log4j etc. just how many ways could log4j be in d.
 I don't think any Tango devs are waiting to jump on Walter at the first 
 chance Phobos is compatible with Tango.  I think everyone in Tango is 
 interested in having Phobos and Tango compatible.

would be great but don't quite look like it. why don't u do some homework and read messages. i took 2 days. then talk.
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. 
 Are
 you asking for Tango's internals to be placed in the public domain?
 That also is a bit much to ask.

Why is it a bit much to ask?

The BSD license allows anyone to do anything with the work as long as the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

you're not following what walt says eh. his problem is not he wanna steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.

The problem is, there is never a guarantee of that. Joe Shmoe can come along and claim that he works with Sean and Sean stole all his D Thread code and gave it to tango. Now, even though the entire Tango team has given permission to Walter, he is still in trouble.

do you want us to participate in a dialog. or revel in improbable possibilities. this is a red herring.

I'm glad you see the futility in it :) I was going off of the messages that said that the owners of the runtime gave permission, but for some reason Walter still refused to look at the runtime package that Sean sent. What I read in other messages (yes, I've read every one, except for the rant on copyrights and pirating) is that he accepts that Sean (and others) gave permission, but it's possible that some of the other Tango devs had a hand in the runtime (even though they don't claim authorship), and so he wants the permission of ALL the Tango devs. Sounds a little extreme to me, so I pointed out that this issue is not black and white. There is a risk associated with it, and I believe Tango devs have minimized the risk, while still protecting their rights as developers for code Walter doesn't need.
 The answer is, either Walter accepts that Sean (and others who gave
 permission) are the rightful owners of the Tango runtime, and he has
 permission to use it, or Walter is so paranoid that he trusts nobody who
 says they own code, and he doesn't use it.  He needs to have some faith 
 that
 the person who says they own the code actually does.

i gather you don't quite read all messages. walt don't want to deliver a compiler with code he can't control. he must deliver code he can change. if that code works with tango walt must know what he gotta do. to do so he must look at tango. sean is cool with that. kris and lars "mi" ivar arent.

You gather incorrectly. You also have not understood that Tango is split into runtime and user code. Walter needs to look at the Tango-runtime code, not Tango-user code. And for that, he has the permission he needs (from Sean). He doesn't need permission from Kris and Lars because they don't modify the runtime code. And nobody is claiming that Walter can't control the Tango code that he uses. Without any extra permission, I can copy the Tango code, and modify it to my hearts content, release it in binary and source form till the day I die, as long as I give the original authors credit. I think Walter understands that view as he has the SAME REQUIREMENTS on Phobos. What I have understood from the messages is that he does not want to look at tango in case he (in the future) writes something similar to the tango code without realizing it, and gets blamed for copyright infringement. If he only looks at the runtime code, he shouldn't have anything to worry about.
 I don't believe that you would do so. But by requiring Tango to be
 placed in the public domain, you're allowing everyone else to do so.

he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

I agree with you on this, but the fact still remains that Walter is not safe as soon as he looks at any code, no matter who says they wrote it, unless he himself wrote it. I think this is taking it a little too extreme.

yeah, ur interpretation. that's extreme.

It's just a possibility, not what I think is likely :) In anything like this, there is always *some* risk. That is what I was trying to convey.
 The BSD license is simply public domain with attribution.

No, it is not. Public Domain code is not copyrighted and does not require a license.

 So what is the issue with using it? Phobos already uses it. Just 
 with
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and 
 Tango,
 let's say to incompatible licenses, and still allow Phobos and 
 Tango
 to share code afterward?

 It's unclear what you want or need that you don't already have.

The problems are two: 1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?

no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.

The owners have given him permission, and promised not to slander.

now i am sure u read every other message in this thread. go back and read'em all.

No need, I remember everything :)
  Anyone
 who cries foul after the rightful owners have given permission is full of
 crap, and I will be the first to say so.

no permission was given. do you like me post drunk sometimes.

Quote from Sean: "As the author of this code, I've long since given my permission. I believe that's all that's necessary." Quote from Walter: "In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such" Which should be enough. Sean is the owner of the code he needs, nobody else on the Tango team owns the runtime code. Sean has even sent Walter a package file with the code he owns which (quote from Walter): "is probably sufficient to get compatibility, in which case that is plenty good enough." So it looks like he has what he needs legally and technically to get it done. I might be wrong, but his recent posts sound like he is now satisfied with what he has.
  So long as Walter and co. just
 look at the proper files (the ones with the permission).  Hell, I don't 
 care
 if he looks at all of tango, as long as he either doesn't copy the code, 
 or
 if he does, obeys the license requirements.

_you_ don't care. others can't wait. they cried foul as soon as there was potential code could've been copied. gorramit. at least if there was da momma of all code. but it's java containers net stack log4j etc. just how many ways could log4j be in d.

I wasn't here for that. I don't know what was said or who said it, but there is a history of Phobos/Tango bad blood that I really am not a part of, and can't really comment on. All I can say is that, although the wounds seem to still exist, the two parties both seem interested in resolving this problem. And there is a huge investment of time and energy into Tango. The developers have every right to ensure that nobody else claims they wrote it. I don't think Walter needs blanket permission to circumvent that.
 I don't think any Tango devs are waiting to jump on Walter at the first
 chance Phobos is compatible with Tango.  I think everyone in Tango is
 interested in having Phobos and Tango compatible.

would be great but don't quite look like it. why don't u do some homework and read messages. i took 2 days. then talk.

I read as they come in, and respond as I read. You are completely wrong if you think the Tango people don't want this resolved. -Steve
Aug 15 2008
parent reply Vincent Richomme <forumer smartmobili.com> writes:
Steven Schveighoffer a crit :
 "superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. 
 Are
 you asking for Tango's internals to be placed in the public domain?
 That also is a bit much to ask.


the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.

along and claim that he works with Sean and Sean stole all his D Thread code and gave it to tango. Now, even though the entire Tango team has given permission to Walter, he is still in trouble.

possibilities. this is a red herring.

I'm glad you see the futility in it :) I was going off of the messages that said that the owners of the runtime gave permission, but for some reason Walter still refused to look at the runtime package that Sean sent. What I read in other messages (yes, I've read every one, except for the rant on copyrights and pirating) is that he accepts that Sean (and others) gave permission, but it's possible that some of the other Tango devs had a hand in the runtime (even though they don't claim authorship), and so he wants the permission of ALL the Tango devs. Sounds a little extreme to me, so I pointed out that this issue is not black and white. There is a risk associated with it, and I believe Tango devs have minimized the risk, while still protecting their rights as developers for code Walter doesn't need.
 The answer is, either Walter accepts that Sean (and others who gave
 permission) are the rightful owners of the Tango runtime, and he has
 permission to use it, or Walter is so paranoid that he trusts nobody who
 says they own code, and he doesn't use it.  He needs to have some faith 
 that
 the person who says they own the code actually does.

compiler with code he can't control. he must deliver code he can change. if that code works with tango walt must know what he gotta do. to do so he must look at tango. sean is cool with that. kris and lars "mi" ivar arent.

You gather incorrectly. You also have not understood that Tango is split into runtime and user code. Walter needs to look at the Tango-runtime code, not Tango-user code. And for that, he has the permission he needs (from Sean). He doesn't need permission from Kris and Lars because they don't modify the runtime code. And nobody is claiming that Walter can't control the Tango code that he uses. Without any extra permission, I can copy the Tango code, and modify it to my hearts content, release it in binary and source form till the day I die, as long as I give the original authors credit. I think Walter understands that view as he has the SAME REQUIREMENTS on Phobos. What I have understood from the messages is that he does not want to look at tango in case he (in the future) writes something similar to the tango code without realizing it, and gets blamed for copyright infringement. If he only looks at the runtime code, he shouldn't have anything to worry about.
 I don't believe that you would do so. But by requiring Tango to be
 placed in the public domain, you're allowing everyone else to do so.

the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

safe as soon as he looks at any code, no matter who says they wrote it, unless he himself wrote it. I think this is taking it a little too extreme.


It's just a possibility, not what I think is likely :) In anything like this, there is always *some* risk. That is what I was trying to convey.
 The BSD license is simply public domain with attribution.

require a license.

 So what is the issue with using it? Phobos already uses it. Just 
 with
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and 
 Tango,
 let's say to incompatible licenses, and still allow Phobos and 
 Tango
 to share code afterward?

 It's unclear what you want or need that you don't already have.

1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

redistribute Tango code without proper attribution?

that a tyrangot will _claim_ walt redistributed tango code without proper attribution.


read'em all.

No need, I remember everything :)
  Anyone
 who cries foul after the rightful owners have given permission is full of
 crap, and I will be the first to say so.


Quote from Sean: "As the author of this code, I've long since given my permission. I believe that's all that's necessary." Quote from Walter: "In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such" Which should be enough. Sean is the owner of the code he needs, nobody else on the Tango team owns the runtime code. Sean has even sent Walter a package file with the code he owns which (quote from Walter): "is probably sufficient to get compatibility, in which case that is plenty good enough." So it looks like he has what he needs legally and technically to get it done. I might be wrong, but his recent posts sound like he is now satisfied with what he has.
  So long as Walter and co. just
 look at the proper files (the ones with the permission).  Hell, I don't 
 care
 if he looks at all of tango, as long as he either doesn't copy the code, 
 or
 if he does, obeys the license requirements.

potential code could've been copied. gorramit. at least if there was da momma of all code. but it's java containers net stack log4j etc. just how many ways could log4j be in d.

I wasn't here for that. I don't know what was said or who said it, but there is a history of Phobos/Tango bad blood that I really am not a part of, and can't really comment on. All I can say is that, although the wounds seem to still exist, the two parties both seem interested in resolving this problem. And there is a huge investment of time and energy into Tango. The developers have every right to ensure that nobody else claims they wrote it. I don't think Walter needs blanket permission to circumvent that.
 I don't think any Tango devs are waiting to jump on Walter at the first
 chance Phobos is compatible with Tango.  I think everyone in Tango is
 interested in having Phobos and Tango compatible.

and read messages. i took 2 days. then talk.

I read as they come in, and respond as I read. You are completely wrong if you think the Tango people don't want this resolved. -Steve

would like to express my feeling as a user. I am working for a few months on cross-compilers for embedded platforms and I have started with wince. My first idea was to build specific libraries with an approach inspired from Java or .Net Worlds and I didn't want to use phobos nor tango. First I thought that everything I need was the D compiler with no runtime at all and I could built my lib beyond it but I think it doesn't work like that. I only hope this issue will be solved quickly and we 'll get a common runtime.
Aug 15 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Vincent Richomme wrote:
 Steven Schveighoffer a crit :
 "superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 Christopher Wright Wrote:

 Walter Bright wrote:
 Christopher Wright wrote:
 A number of modules in phobos/internal are marked public domain. 
 Are
 you asking for Tango's internals to be placed in the public domain?
 That also is a bit much to ask.


the authors get proper recognition. The one incentive to distribute the work is this recognition (besides encouraging others to help with the project). If you're not going to take any Tango code and claim that it is yours, then the BSD license shouldn't cause any problems for you. If you require public domain, that implies that the BSD license causes problems for you. That implies that you're going to steal code.

steal and get away with it. problem is that he doesn't wanna be accused of stealing. poop man. he got accused before even lookin' at the gorram thing. also his problem is not he doesn't wanna acknowledge whodunit. i grepped around phobos and there's many names in there. there's even a guy whos name is in there tho all his stuff has been rewritten since. what walt wanna is look at tango without fear that some dood will cry he stole his code. after all there's only this many ways you can do trivial sh... stuff like async i/o and logging and containers. slander comes easily and goes not so easily. is he paranoid? sure as hell he is. oh, wait. some dood _did_ cry walt stole (thru brad) his precious soon as they was within a hundred miles. all this while walt is known to give credit down to the dog pooping in the driveway walt was looking at when he came with an idea. give me an intercoursing break.

along and claim that he works with Sean and Sean stole all his D Thread code and gave it to tango. Now, even though the entire Tango team has given permission to Walter, he is still in trouble.

possibilities. this is a red herring.

I'm glad you see the futility in it :) I was going off of the messages that said that the owners of the runtime gave permission, but for some reason Walter still refused to look at the runtime package that Sean sent. What I read in other messages (yes, I've read every one, except for the rant on copyrights and pirating) is that he accepts that Sean (and others) gave permission, but it's possible that some of the other Tango devs had a hand in the runtime (even though they don't claim authorship), and so he wants the permission of ALL the Tango devs. Sounds a little extreme to me, so I pointed out that this issue is not black and white. There is a risk associated with it, and I believe Tango devs have minimized the risk, while still protecting their rights as developers for code Walter doesn't need.
 The answer is, either Walter accepts that Sean (and others who gave
 permission) are the rightful owners of the Tango runtime, and he has
 permission to use it, or Walter is so paranoid that he trusts nobody 
 who
 says they own code, and he doesn't use it.  He needs to have some 
 faith that
 the person who says they own the code actually does.

deliver a compiler with code he can't control. he must deliver code he can change. if that code works with tango walt must know what he gotta do. to do so he must look at tango. sean is cool with that. kris and lars "mi" ivar arent.

You gather incorrectly. You also have not understood that Tango is split into runtime and user code. Walter needs to look at the Tango-runtime code, not Tango-user code. And for that, he has the permission he needs (from Sean). He doesn't need permission from Kris and Lars because they don't modify the runtime code. And nobody is claiming that Walter can't control the Tango code that he uses. Without any extra permission, I can copy the Tango code, and modify it to my hearts content, release it in binary and source form till the day I die, as long as I give the original authors credit. I think Walter understands that view as he has the SAME REQUIREMENTS on Phobos. What I have understood from the messages is that he does not want to look at tango in case he (in the future) writes something similar to the tango code without realizing it, and gets blamed for copyright infringement. If he only looks at the runtime code, he shouldn't have anything to worry about.
 I don't believe that you would do so. But by requiring Tango to be
 placed in the public domain, you're allowing everyone else to do so.

for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

not safe as soon as he looks at any code, no matter who says they wrote it, unless he himself wrote it. I think this is taking it a little too extreme.


It's just a possibility, not what I think is likely :) In anything like this, there is always *some* risk. That is what I was trying to convey.
 The BSD license is simply public domain with attribution.

require a license.

 So what is the issue with using it? Phobos already uses it. Just 
 with
 your name as the copyright holder.

 Or do you want an agreement to allow relicensing of Phobos and 
 Tango,
 let's say to incompatible licenses, and still allow Phobos and 
 Tango
 to share code afterward?

 It's unclear what you want or need that you don't already have.

1. Phobos has already been accused of stealing code from Tango. Therefore, I would like explicit permission from the Tango team. I am not going to take code from Tango and put it in Phobos without explicit permission from the Tango team. Any hint of Phobos not having a clean legal pedigree will impair its adoption.

redistribute Tango code without proper attribution?

worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.


read'em all.

No need, I remember everything :)
  Anyone
 who cries foul after the rightful owners have given permission is 
 full of
 crap, and I will be the first to say so.


Quote from Sean: "As the author of this code, I've long since given my permission. I believe that's all that's necessary." Quote from Walter: "In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such" Which should be enough. Sean is the owner of the code he needs, nobody else on the Tango team owns the runtime code. Sean has even sent Walter a package file with the code he owns which (quote from Walter): "is probably sufficient to get compatibility, in which case that is plenty good enough." So it looks like he has what he needs legally and technically to get it done. I might be wrong, but his recent posts sound like he is now satisfied with what he has.
  So long as Walter and co. just
 look at the proper files (the ones with the permission).  Hell, I 
 don't care
 if he looks at all of tango, as long as he either doesn't copy the 
 code, or
 if he does, obeys the license requirements.

was potential code could've been copied. gorramit. at least if there was da momma of all code. but it's java containers net stack log4j etc. just how many ways could log4j be in d.

I wasn't here for that. I don't know what was said or who said it, but there is a history of Phobos/Tango bad blood that I really am not a part of, and can't really comment on. All I can say is that, although the wounds seem to still exist, the two parties both seem interested in resolving this problem. And there is a huge investment of time and energy into Tango. The developers have every right to ensure that nobody else claims they wrote it. I don't think Walter needs blanket permission to circumvent that.
 I don't think any Tango devs are waiting to jump on Walter at the first
 chance Phobos is compatible with Tango.  I think everyone in Tango is
 interested in having Phobos and Tango compatible.

homework and read messages. i took 2 days. then talk.

I read as they come in, and respond as I read. You are completely wrong if you think the Tango people don't want this resolved. -Steve

would like to express my feeling as a user. I am working for a few months on cross-compilers for embedded platforms and I have started with wince. My first idea was to build specific libraries with an approach inspired from Java or .Net Worlds and I didn't want to use phobos nor tango. First I thought that everything I need was the D compiler with no runtime at all and I could built my lib beyond it but I think it doesn't work like that. I only hope this issue will be solved quickly and we 'll get a common runtime.

As an aside, I think the most expedient approach for you would be to grab the Tango runtime, ignore the user code, and work on creating a compiler runtime. It can contain as much or as little code as you need so long as you expose the few functions that the other runtime bits rely on. Tango was built from the ground up with this in mind, since basically all of the users of Ares (upon which the Tango runtime is based) were kernel and compiler developers. Sean
Aug 15 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
superdan wrote:
 Christopher Wright Wrote:
 I don't believe that you would do so. But by requiring Tango to be 
 placed in the public domain, you're allowing everyone else to do so.

he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

He wanted permission to license Tango as Phobos is licensed. Phobos was licensed in a BSD-like license, but Walter has been changing it to public domain. Walter did explicitly say that he wanted to relicense Tango as public domain, I believe.
 The BSD license is explicit permission. Or do you intend to redistribute 
 Tango code without proper attribution?

no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.

The accusation was ridiculous. As such, Walter would trivially fulfill the requirements of the BSD license.
Aug 15 2008
parent lihong <llzyf sina.com> writes:
We offer World of Warcraft Power Leveling and World of Warcraft
powerleveling,Age of Conan Powerleveling and Lord fo Ring Online
Powerleveling.WoW Powerleveling service and cheap wow Powerleveling,World of
Warcraft Power leveling sale for you. AOC Power leveling,Cheap AOC
Powerleveling .All service is faster,safer,and cheaper.We Please remember,we
are your online game helper.
<a href=http://www.pvpsale.com>WOW Powerleveling</a>
<a href=http://www.pvpsale.com/powerleveling.asp>WOW Power leveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-US-Powerleveling.asp>World of
Warcraft Powerleveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-EU-Powerleveling.asp>World of
Warcraft power leveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-US-Gold.asp>wow gold</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-EU-Gold.asp>wow gold</a>
<a href=http://www.pvpsale.com/Age-of-Conan-Powerleveling.html>Age of Conan
Powerleveling</a>
<a href=http://www.pvpsale.com/Age-of-Conan-Power-leveling.html>Age of Conan
Power leveling</a>
<a href=http://www.pvpsale.com/AOC-Powerleveling.asp>AOC Powerleveling</a>
<a href=http://www.pvpsale.com/AOC-Power-leveling.asp>AOC Power leveling</a>
<a href=http://www.pvpsale.com/AOC-Powerleveling.html>AOC Powerleveling</a>
<a href=http://www.pvpsale.com/AOC-Power-leveling.html>AOC Power leveling</a>
<a href=http://www.pvpsale.com/Final-Fantasy-XI-Gil.asp>Final Fantasy XI Gil</a>
<a href=http://www.pvpsale.com/Final-Fantasy-XI.asp>FFXI Gil</a>
<a href=http://www.pvpsale.com/Florensia-Gold.asp>Florensia Gold</a>
<a href=http://www.pvpsale.com/Dekaron-EU.asp>Dekaron Dil</a>
<a href=http://www.pvpsale.com/Requiem-Online.asp>Requiem Gold</a>
<a href=http://www.pvpsale.com/Rohan-Online.asp>Rohan Gold</a>
<a href=http://www.pvpsale.com/Warhammer-Online-Powerleveling.asp>Warhammer
Powerleveling</a>
<a href=http://www.pvpsale.com/Warhammer-Online.asp>Warhammer Online</a>
Aug 15 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

The BSD license of Tango is here http://www.dsource.org/projects/tango/wiki/BSDLicense The license of Phobos is here http://www.dsource.org/projects/phobos/browser/trunk/phobos/phoboslicense.txt These license texts are almost identical. Both say that you can freely distribute the library in source or binary form, as long as you retain the license. Two differences I see. One, the Phobos license requires you to identify if you have changed the file. Two, the Phobos license is more lax on requiring acknowledgement for binaries. But you can't claim you wrote the binary completely without giving acknowledgement (at least, that's my interpretation). I don't want to point any fingers, all I want to do is help resolve the situation. From Walter's camp, are these licenses really THAT different for you to believe that Phobos will be split into 2 licenses? And even if it is, who cares? The license is so similar, you simply include both for the Phobos runtime. Many pieces of software have long lists of acknowledgements and licenses in their binary distribution (i.e. portions of this software copyright ...) From Tango's camp, the Phobos license is very similar, couldn't you allow licensing the runtime under the Phobos license as well? I can't see how it would hurt, the Phobos license is only slightly more restrictive, but still is in the same spirit of the BSD license. The one thing it lacks is an absolute requirement for acknowledgement in binary form, but it is required if you claim authorship of software or distribute in source form. So nobody can go around claiming they wrote Tango, but if they claim any authorship of anything, Tango must be there. Someone's got to give here, maybe there is just a lack of communication, or maybe there are deeper issues under the surface... To me, this is a no brainer. If the license is the only thing stopping you, fix it. I'm willing to help in any way I can. Please set any bad blood aside for this one issue. -Steve
Aug 14 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

available. :)

license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies. This issue must be settled in advance of looking at Tango, not after the fact.

The BSD license of Tango is here http://www.dsource.org/projects/tango/wiki/BSDLicense The license of Phobos is here http://www.dsource.org/projects/phobos/browser/trunk/phobos/phoboslicense.txt These license texts are almost identical. Both say that you can freely distribute the library in source or binary form, as long as you retain the license. Two differences I see. One, the Phobos license requires you to identify if you have changed the file. Two, the Phobos license is more lax on requiring acknowledgement for binaries. But you can't claim you wrote the binary completely without giving acknowledgement (at least, that's my interpretation).

This documentation requirement for binaries is why Tango adopted a dual license scheme. In prior jobs I'd never be able to get a corporate lawyer to approve the use of a library containing such a requirement, and I wanted to be able to use Tango at work someday :-)
 From Tango's camp, the Phobos license is very similar, couldn't you allow 
 licensing the runtime under the Phobos license as well?  I can't see how it 
 would hurt, the Phobos license is only slightly more restrictive, but still 
 is in the same spirit of the BSD license.  The one thing it lacks is an 
 absolute requirement for acknowledgement in binary form, but it is required 
 if you claim authorship of software or distribute in source form.  So nobody 
 can go around claiming they wrote Tango, but if they claim any authorship of 
 anything, Tango must be there.

Releasing code into the public domain relinquishes any right to claim authorship as well. I provided permission for Walter to use the runtime code as PD anyway, with the request that Phobos, at least, mention me as the author / contributor as appropriate. But I think it's asking a lot that other Tango contributors do the same... particularly when all their contributions are user code. If this permission were given, Walter could quite legally take all of Tango, relabel it as Phobos and distribute it as his own. Not that I expect him to, but it would be within his rights to do so. Sean
Aug 14 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
  If this permission were given, Walter
 could quite legally take all of Tango, relabel it as Phobos and 
 distribute it as his own.  Not that I expect him to, but it would be 
 within his rights to do so.

So could anyone with code in Phobos that I wrote and labeled Public Domain. This hardly seems to be a sensible strategy to feed megalomania <g>. Falsely claiming ownership of public domain code is a futile gesture, as the internet record of these things is not going away, and it would just make the person that tried it a pathetic, obvious fraud. Bottom line, I don't want the license in Phobos to be any impediment to anyone wanting to use D.
Aug 14 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Sean Kelly wrote:
  If this permission were given, Walter
 could quite legally take all of Tango, relabel it as Phobos and 
 distribute it as his own.  Not that I expect him to, but it would be 
 within his rights to do so.

So could anyone with code in Phobos that I wrote and labeled Public Domain. This hardly seems to be a sensible strategy to feed megalomania <g>. Falsely claiming ownership of public domain code is a futile gesture, as the internet record of these things is not going away, and it would just make the person that tried it a pathetic, obvious fraud. Bottom line, I don't want the license in Phobos to be any impediment to anyone wanting to use D.

Then, regardless of the Tango-Phobos runtime integration discussion, what do you say about Sean's comment that Phobos license might still pose some problems is certain situations? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they see
 fit, and I respect that and so have not spoken out on it before. But in
 this thread I am being cast as a roadblock, which I feel is a little
 unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies.

Personally, I've never met a corporate lawyer who would authorize use of Public Domain code, for two reasons. First, the assumption seems to be that PD code is really actually owned by someone and no one knows who that is. Second, lawyers (and build teams even moreso) very much like having a responsible party, even if the license absolves the author of any direct responsibility for code issues as most licenses do. Case in point, I've never been able to use Boost at any of my previous jobs because the licensing scheme is too open. Also, I've had to fight tooth and nail to use BSD licensed code at work because of the attribution requirement (that the library must be mentioned in documentation accompanying any shipped product). All of the above was considered when working out a licensing scheme for Tango. We wanted a license that would allow Tango to be used by everyone, first and foremost. I could never have done that with Phobos under the current license.
 This issue must be settled in advance of looking at Tango, not after the 
 fact.

The contention is about the user code, I believe. You have asked for blanket permission to incorporate all of Tango as Public Domain code in Phobos even though the only portion of the code you seem to care about is the runtime. As the sole maintainer of the runtime I have long since given you permission to use that portion of the code as you see fit, but this is obviously not sufficient. I honestly have no idea how we can proceed any further, given that I don't expect other Tango contributors to agree to release their (user) code into the Public Domain. Sean
Aug 14 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Moritz Warning (moritzwarning web.de)'s article
 On Thu, 14 Aug 2008 11:49:06 -0700, Sean Kelly wrote:
 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they
 see fit, and I respect that and so have not spoken out on it before.
 But in this thread I am being cast as a roadblock, which I feel is a
 little unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies.

Personally, I've never met a corporate lawyer who would authorize use of Public Domain code, for two reasons. First, the assumption seems to be that PD code is really actually owned by someone and no one knows who that is. Second, lawyers (and build teams even moreso) very much like having a responsible party, even if the license absolves the author of any direct responsibility for code issues as most licenses do. Case in point, I've never been able to use Boost at any of my previous jobs because the licensing scheme is too open. Also, I've had to fight tooth and nail to use BSD licensed code at work because of the attribution requirement (that the library must be mentioned in documentation accompanying any shipped product). All of the above was considered when working out a licensing scheme for Tango. We wanted a license that would allow Tango to be used by everyone, first and foremost. I could never have done that with Phobos under the current license.
 This issue must be settled in advance of looking at Tango, not after
 the fact.

The contention is about the user code, I believe. You have asked for blanket permission to incorporate all of Tango as Public Domain code in Phobos even though the only portion of the code you seem to care about is the runtime. As the sole maintainer of the runtime I have long since given you permission to use that portion of the code as you see fit, but this is obviously not sufficient. I honestly have no idea how we can proceed any further, given that I don't expect other Tango contributors to agree to release their (user) code into the Public Domain. Sean

But that don't have to be done right now. There is no license issue with the Tango runtime, Work could be started with the runtime any time. - right? Walter? Sean?

I think so, but Walter apparently disagrees. Sean
Aug 14 2008
prev sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Walter Bright wrote:
 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

[Don wrote] The number of people that have touched the runtime layer of Tango is very limited. Walter has confirmed that Sean & Don gave given him the legal statement he requires. So who are the other Tango developers who have submitted code for the runtime layer ? Would these developers like to comment as to why they would, or would not, like to give such a legal statement to Walter ? Nick B.
Aug 14 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Nick B wrote:
 Walter Bright wrote:
 Paul D. Anderson wrote:
 But what I
 would really like to see (and I don't think it's asking too much) is
 a clear statement from Walter that he will indeed make the changes
 the Tango developers are asking for at some future date.

In order for this to happen, I need a clear and unambiguous statement from the Tango developers that Phobos can incorporate parts of the Tango runtime and place them under the Phobos license. I have already provided a reciprocal license to Tango. I've asked for that for over a year, and so far only Sean and Don have done so. Such an agreement is necessary for the following reasons: 1. To ensure Phobos is free of any legal taint and any accusations of stealing code. 2. To avoid the untenable issue of a single module in Phobos having different license for different lines of code. I have explained this to the main Tango developers on multiple occasions. It is their right and privilege to license Tango as they see fit, and I respect that and so have not spoken out on it before. But in this thread I am being cast as a roadblock, which I feel is a little unfair, so I will loosen my tongue and speak up a bit :-)

[Don wrote] The number of people that have touched the runtime layer of Tango is very limited. Walter has confirmed that Sean & Don gave given him the legal statement he requires. So who are the other Tango developers who have submitted code for the runtime layer ?

Mikola Lysenko is the only one I can think of offhand, as Tango's Fiber implementation is based on his StackThreads. Steve S. may be listed as a contributor for the Thread code as well.
 Would these developers like to comment as to why they would, or would 
 not, like to give such a legal statement to Walter ?

As the author of this code, I've long since given my permission. I believe that's all that's necessary. Sean
Aug 14 2008
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Fri, Aug 15, 2008 at 09:25:50PM -0400, Christopher Wright wrote:
 The accusation was ridiculous. As such, Walter would trivially fulfill 
 the requirements of the BSD license.

What about the users of the language? Suppose the standard library was BSD licensed and I wrote a D program. Am I now required to add their copyright notice with my program whenever I distribute it? That's a pain in the ass. I like to distribute my programs in binary form just by giving a link to the .exe saying 'here it is, do whatever you want with it. Have fun!' With the BSD license restrictions, I couldn't do that. The license in the phobos files is perfect for me. That's how a standard library should be licensed - infinitely convenient. -- Adam D. Ruppe http://arsdnet.net
Aug 15 2008
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Robert Fraser wrote:
...
 I see the D community heading for a split. One side will be D1 (hopefully
 a D 1.5) +tango, and the other side will be D2+phobos.  I don't think of
 this as a bad thing nessescarily, just two different directions.

I find this all to be a bit confusing. A 'split' was kind of inevitable since the D2 branch and the phobos / tango division. (Actually since D2 there was more unification for a while, because a stable version of D didn't exist before.) But this kind of split was (is?) also something temporary and had workarounds (tangobos). At least I perceived it as temporary, until now. What do you mean by a D 1.5? This all gives the vague impression there is a movement towards forking the language itself. That's not a split in the D community, more like part of the D community saying goodbye and starting their own language with a seperate community. I hope I'm wrong here, but would like to know if this is the case or intent.
Aug 14 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robert Fraser wrote:
 Sean Kelly Wrote:
 
 == Quote from Moritz Warning (moritzwarning web.de)'s article
 On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:
 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...

sides. It takes two to Tango, as they say (sorry, bad joke). Sean

I see the D community heading for a split. One side will be D1 (hopefully a D 1.5) +tango, and the other side will be D2+phobos. I don't think of this as a bad thing nessescarily, just two different directions.

Oh, it would definitely be bad, that's for sure. Any such duplication of effort in a developing language such as D would be very harmful. Having two standard libraries is already bad IMO, but having each standard library force the use of a particular D language version... now that would be disastrous! -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Unfortunately, for this to be resolved it requires cooperation from both
 sides.  It takes two to Tango, as they say (sorry, bad joke).

For my part, I have explicitly allowed the Tango team to look at, use and incorporate any part of Phobos into Tango without prejudice and release it under the Tango license (excluding stuff that I didn't write that has its own copyright license terms). A lot of the new stuff, such as the array op code are even in the public domain to make it super easy. In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such, but the rest of the Tango team have not been willing to, and they have every right to not do so, but it does stand in the way of cooperation. P.S. The reason for the relicense when code is transferred is to avoid the untenable situation of one module in the library having different licenses for different sections of code.
Aug 13 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Brad Roberts wrote:

 On Wed, 13 Aug 2008, Walter Bright wrote:
 
 Date: Wed, 13 Aug 2008 14:32:32 -0700
 From: Walter Bright <newshound1 digitalmars.com>
 Reply-To: digitalmars.D <digitalmars-d puremagic.com>
 To: digitalmars-d puremagic.com
 Newsgroups: digitalmars.D
 Subject: Re: Tango vs Phobos
 
 Sean Kelly wrote:
 Unfortunately, for this to be resolved it requires cooperation from
 both
 sides.  It takes two to Tango, as they say (sorry, bad joke).

For my part, I have explicitly allowed the Tango team to look at, use and incorporate any part of Phobos into Tango without prejudice and release it under the Tango license (excluding stuff that I didn't write that has its own copyright license terms). A lot of the new stuff, such as the array op code are even in the public domain to make it super easy. In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such, but the rest of the Tango team have not been willing to, and they have every right to not do so, but it does stand in the way of cooperation. P.S. The reason for the relicense when code is transferred is to avoid the untenable situation of one module in the library having different licenses for different sections of code.

Additionally, Sean has had commit access to phobos for well over a year. As far as I can recall, there's been no submits. I did a good bit of unification of the thread model at one point (though far from complete), and was accused of stealing code from Tango (no, I'm not going to try to dig up exact quotes). It left a rather sour taste in my mouth at which point my enthusiasm was somewhat diminished. I let the license issue further stall any effort on my part. I hate airing dirty laundry, so I hope this to be my one and only post on the topic.

To be fair, there was anger at the approach chosen on your side when starting with this work, and too strong words may have been used, and if I was guilty, I am sorry for that. As it was, we didn't in any way feel that what happened in any way reflected what we talked to Walter about at the conference. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Brad Roberts wrote:
 On Wed, 13 Aug 2008, Walter Bright wrote:
 
 Date: Wed, 13 Aug 2008 14:32:32 -0700
 From: Walter Bright <newshound1 digitalmars.com>
 Reply-To: digitalmars.D <digitalmars-d puremagic.com>
 To: digitalmars-d puremagic.com
 Newsgroups: digitalmars.D
 Subject: Re: Tango vs Phobos

 Sean Kelly wrote:
 Unfortunately, for this to be resolved it requires cooperation from both
 sides.  It takes two to Tango, as they say (sorry, bad joke).

incorporate any part of Phobos into Tango without prejudice and release it under the Tango license (excluding stuff that I didn't write that has its own copyright license terms). A lot of the new stuff, such as the array op code are even in the public domain to make it super easy. In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such, but the rest of the Tango team have not been willing to, and they have every right to not do so, but it does stand in the way of cooperation. P.S. The reason for the relicense when code is transferred is to avoid the untenable situation of one module in the library having different licenses for different sections of code.

Additionally, Sean has had commit access to phobos for well over a year. As far as I can recall, there's been no submits. I did a good bit of unification of the thread model at one point (though far from complete), and was accused of stealing code from Tango (no, I'm not going to try to dig up exact quotes). It left a rather sour taste in my mouth at which point my enthusiasm was somewhat diminished. I let the license issue further stall any effort on my part.

I don't even have time to maintain the Tango runtime, let alone the Phobos runtime as well. And I honestly don't know what I should change given that I don't know what the plan is for the Phobos runtime. As for accusations about stealing code, I will only say that I never made any such accusations. But I do recall some contention at the time for your having full commit rights to Tango, etc, so I do understand your concern. Sean
Aug 14 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Brad Roberts wrote:
 On Wed, 13 Aug 2008, Brad Roberts wrote:
 
 As far as I can recall, there's been no submits.  I did a good bit of 
 unification of the thread model at one point (though far from complete), 
 and was accused of stealing code from Tango (no, I'm not going to try to 
 dig up exact quotes).

Sorry.. the implication was that Sean made the accusations which isn't the case. He was very helpful in integrating the changes and reviewing both the tango and phobos changes that I made -- obviously far more on the phobos side.

As an aside... that code change review tool you had set up on PureMagic was super cool. Sean
Aug 14 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Nick B Wrote:

 Lars Ivar Igesund wrote:
 dsimcha wrote:
 
 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just release
 whatever subset of Tango is high-level enough to run on top of the D2
 Phobos runtime and isn't plagued too severely by const issues, even if it
 doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client code. 

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a reasonably
 large subset with plenty of useful things.

 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if only
 parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango.

When is the Tango team and Walter going to get in the same room to thrash though these differences, because if these issues are not resolved, then the split will get wider, and wider. Finally, both communities will go their separate ways, and the community (both D and Tango) will burn and die.

I recognize a number of core Tango folks participating in this thread. I find it very telling that Walter has not found this thread sufficiently interesting to reply.
Aug 13 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 There isn't really a subset of Tango that can run on top of any Phobos
 runtime. The Tango runtime probably works fine with D2 without any major
 changes, it is the user library that is problematic. The work on the
 porting has begun in a branch in Tango's svn repository, but cannot be
 continued properly until certain issues are fixed.

I don't understand. I fixed the one issue you identified to me that was impeding Tango on D2 (Bugzilla 1644, and 2204 is the same). What else is there?
Aug 13 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:
 There isn't really a subset of Tango that can run on top of any Phobos
 runtime. The Tango runtime probably works fine with D2 without any major
 changes, it is the user library that is problematic. The work on the
 porting has begun in a branch in Tango's svn repository, but cannot be
 continued properly until certain issues are fixed.

I don't understand. I fixed the one issue you identified to me that was impeding Tango on D2 (Bugzilla 1644, and 2204 is the same). What else is there?

I wasn't aware that 2204 was a duplicate of 1644, and I guess Steven wasn't either. If there are no further stumbling blocks, all are great :) Although, clearly, the better solution would be fixing Bugzilla 1961, 1644 is only a workaround for that. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Lars Ivar Igesund" wrote
 Walter Bright wrote:

 Lars Ivar Igesund wrote:
 There isn't really a subset of Tango that can run on top of any Phobos
 runtime. The Tango runtime probably works fine with D2 without any major
 changes, it is the user library that is problematic. The work on the
 porting has begun in a branch in Tango's svn repository, but cannot be
 continued properly until certain issues are fixed.

I don't understand. I fixed the one issue you identified to me that was impeding Tango on D2 (Bugzilla 1644, and 2204 is the same). What else is there?

I wasn't aware that 2204 was a duplicate of 1644, and I guess Steven wasn't either. If there are no further stumbling blocks, all are great :) Although, clearly, the better solution would be fixing Bugzilla 1961, 1644 is only a workaround for that.

In fact, I wasn't aware. 2204 was a legitimate bug, which worked in D 2.007. 1644 was an enhancement request, I didn't really consider it a bug, but it did not work in 2.007. So I viewed them as separate issues. Of course, it's entirely possible that in adding the 1644 enhancement, the 2204 bug also got fixed. I'll check it (haven't had a chance yet to try out the new D2). I also would have preferred 1961, but I understand the preference for 1644 as 1961 would be a huge feature change. I still think 1961 is a worthwhile enhancement, but I don't think it blocks D2/Tango development at this time. I will check the status of these bugs soon. The benefits of 1961: Not a template solution. Ability to not munge the caller's const contract. -Steve
Aug 14 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote
 In fact, I wasn't aware.  2204 was a legitimate bug, which worked in D 
 2.007.  1644 was an enhancement request, I didn't really consider it a 
 bug, but it did not work in 2.007.  So I viewed them as separate issues.

 Of course, it's entirely possible that in adding the 1644 enhancement, the 
 2204 bug also got fixed.  I'll check it (haven't had a chance yet to try 
 out the new D2).

Confirmed that both issues are fixed in 2.018, at least for the given test cases. I'll work on trying to port the Tango branch again :) -Steve
Aug 15 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn"
 or something similar would be used for full closures.


It's just a matter of opinion, I suppose. As D is a systems language, I don't agree with many arguments about safety when that safety conflicts with my ability to control what the language is doing behind the scenes. Portability between versions is also an issue--code that is correctly designed for D 1.0 may be unusable on D 2.0 because the default behavior for certain language features is different, although the syntax is still completely legal. Also, there isn't any way to easily grep for the use of delegates so finding such trouble spots requires a manual code review.

But does delegate usage cause that much erroneous outer variable heap allocation? (by erroneous, I mean in situations were it would not be necessary) Or is the problem here that you are afraid that the developer might make a mistake were he would create a delegate that would capture an outer variable (and thus heap allocate it), but the developer would not notice it? Would a semantic tool that detects delegate's outer variables (ie, the heap-allocated local variables) be useful? I think it wouldn't be too hard to create such functionality in Descent/Mmrnmhrm. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 15 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I would prefer that the old behavior the the default and that "new &fn"
 or something similar would be used for full closures.

possible in D the default has to be

It's just a matter of opinion, I suppose. As D is a systems language, I don't agree with many arguments about safety when that safety conflicts with my ability to control what the language is doing behind the scenes. Portability between versions is also an issue--code that is correctly designed for D 1.0 may be unusable on D 2.0 because the default behavior for certain language features is different, although the syntax is still completely legal. Also, there isn't any way to easily grep for the use of delegates so finding such trouble spots requires a manual code review.

But does delegate usage cause that much erroneous outer variable heap allocation? (by erroneous, I mean in situations were it would not be necessary)

From what I've been told, it does. But I haven't personally tested D 2.0 enough to say.
 Or is the problem here that you are afraid that the developer might make 
 a mistake were he would create a delegate that would capture an outer 
 variable (and thus heap allocate it), but the developer would not notice 
 it?

No. My issue is simply with performance guarantees.
 Would a semantic tool that detects delegate's outer variables (ie, the 
 heap-allocated local variables) be useful? I think it wouldn't be too 
 hard to create such functionality in Descent/Mmrnmhrm.

Not sure. I'd have to look into how the compiler decides whether to heap allocate before saying. Sean
Aug 15 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 But does delegate usage cause that much erroneous outer variable heap 
 allocation? (by erroneous, I mean in situations were it would not be 
 necessary)

From what I've been told, it does. But I haven't personally tested D 2.0 enough to say.

Is there any bug report or code sample of such situation? I recall you mentioning this problem before, but I haven't seen any concrete example so far. (not saying there isn't ;) )
 Or is the problem here that you are afraid that the developer might 
 make a mistake were he would create a delegate that would capture an 
 outer variable (and thus heap allocate it), but the developer would 
 not notice it?

No. My issue is simply with performance guarantees.

Guarentees by the D spec itself? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 18 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Bruno Medeiros wrote:

 Sean Kelly wrote:
 Bruno Medeiros wrote:
 But does delegate usage cause that much erroneous outer variable heap
 allocation? (by erroneous, I mean in situations were it would not be
 necessary)

From what I've been told, it does. But I haven't personally tested D 2.0 enough to say.

Is there any bug report or code sample of such situation? I recall you mentioning this problem before, but I haven't seen any concrete example so far. (not saying there isn't ;) )

I believe others have shown that it can disrupt normal running. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 18 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Lars Ivar Igesund wrote:
 Bruno Medeiros wrote:
 
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 But does delegate usage cause that much erroneous outer variable heap
 allocation? (by erroneous, I mean in situations were it would not be
 necessary)

2.0 enough to say.

mentioning this problem before, but I haven't seen any concrete example so far. (not saying there isn't ;) )

I believe others have shown that it can disrupt normal running.

I was asking for a piece of code were the compiler would unnecessarily heap-allocate a local (and not a situation where doing so would botch up a program). But in reading Frank Benoit's post in the full closure thread below, I've already seen one meanwhile. I didn't know the compiler heap-allocated a local in every situation where a local is used as an outer variable. That indeed puts a serious burden on the use of scoped closures :( -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bruno Medeiros wrote:
 But in reading Frank Benoit's post in the full closure thread below, 
 I've already seen one meanwhile. I didn't know the compiler 
 heap-allocated a local in every situation where a local is used as an 
 outer variable. That indeed puts a serious burden on the use of scoped 
 closures :(

It doesn't do it in every situation. It does it in a situation where a pointer is taken to a function that accesses it.
Aug 18 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 But in reading Frank Benoit's post in the full closure thread below, 
 I've already seen one meanwhile. I didn't know the compiler 
 heap-allocated a local in every situation where a local is used as an 
 outer variable. That indeed puts a serious burden on the use of scoped 
 closures :(

It doesn't do it in every situation. It does it in a situation where a pointer is taken to a function that accesses it.

Hum, that's right, I hadn't noticed. My previous comment was due to the fact that I was always experimenting with delegate literals. And unfortunately a delegate literal itself counts as "taking a pointer to a function", so any outer variable used in a delegate literal will be allocated. :/ -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 25 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 But does delegate usage cause that much erroneous outer variable heap 
 allocation? (by erroneous, I mean in situations were it would not be 
 necessary)

From what I've been told, it does. But I haven't personally tested D 2.0 enough to say.

Is there any bug report or code sample of such situation? I recall you mentioning this problem before, but I haven't seen any concrete example so far. (not saying there isn't ;) )
 Or is the problem here that you are afraid that the developer might 
 make a mistake were he would create a delegate that would capture an 
 outer variable (and thus heap allocate it), but the developer would 
 not notice it?

No. My issue is simply with performance guarantees.

Guarentees by the D spec itself?

No, guarantees by Tango. Like how the STL provides "big O" guarantees for its algorithms. Sean
Aug 18 2008
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 13 Aug 2008, Walter Bright wrote:

 Date: Wed, 13 Aug 2008 14:32:32 -0700
 From: Walter Bright <newshound1 digitalmars.com>
 Reply-To: digitalmars.D <digitalmars-d puremagic.com>
 To: digitalmars-d puremagic.com
 Newsgroups: digitalmars.D
 Subject: Re: Tango vs Phobos
 
 Sean Kelly wrote:
 Unfortunately, for this to be resolved it requires cooperation from both
 sides.  It takes two to Tango, as they say (sorry, bad joke).

For my part, I have explicitly allowed the Tango team to look at, use and incorporate any part of Phobos into Tango without prejudice and release it under the Tango license (excluding stuff that I didn't write that has its own copyright license terms). A lot of the new stuff, such as the array op code are even in the public domain to make it super easy. In order for Phobos to move towards compatibility, I need a reciprocal statement from the Tango team. The Tango license does not allow this, and I try to be very careful in making sure Phobos is clean from a legal standpoint. Sean and Don have been most generous in offering such, but the rest of the Tango team have not been willing to, and they have every right to not do so, but it does stand in the way of cooperation. P.S. The reason for the relicense when code is transferred is to avoid the untenable situation of one module in the library having different licenses for different sections of code.

Additionally, Sean has had commit access to phobos for well over a year. As far as I can recall, there's been no submits. I did a good bit of unification of the thread model at one point (though far from complete), and was accused of stealing code from Tango (no, I'm not going to try to dig up exact quotes). It left a rather sour taste in my mouth at which point my enthusiasm was somewhat diminished. I let the license issue further stall any effort on my part. I hate airing dirty laundry, so I hope this to be my one and only post on the topic. Sigh, Brad
Aug 13 2008
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 13 Aug 2008, Brad Roberts wrote:

 As far as I can recall, there's been no submits.  I did a good bit of 
 unification of the thread model at one point (though far from complete), 
 and was accused of stealing code from Tango (no, I'm not going to try to 
 dig up exact quotes).

Sorry.. the implication was that Sean made the accusations which isn't the case. He was very helpful in integrating the changes and reviewing both the tango and phobos changes that I made -- obviously far more on the phobos side. Sigh, Brad
Aug 13 2008
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 13 Aug 2008, Sean Reque wrote:

 Chris R. Miller Wrote:
 
 Walter Bright wrote:
 Christopher Wright wrote:
 Dozens of people have worked on Tango. Tracking who owns the code is
 nontrivial, as is contacting some of them. It might be impossible to
 get a license change cleared.

I understand that. But my understanding (I am not a lawyer) of copyright law is that a couple of lines of code are not copyrightable. But major contributors to Tango should be reachable.

I too am not a lawyer, but I was under the impression that contributions to Tango are still property of Tango and subject to the global Tango license. Maybe someone should ask a lawyer... there's a good radio phone-a-lawyer guy in my area I could call.

There could be cause for concern. This is from http://www.sqlite.org/copyright.html """ Contributed Code In order to keep SQLite completely free and unencumbered by copyright, all new contributors to the SQLite code base are asked to dedicate their contributions to the public domain. If you want to send a patch or enhancement for possible inclusion in the SQLite source tree, please accompany the patch with the following statement: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law. We are not able to accept patches or changes to SQLite that are not accompanied by a statement such as the above. In addition, if you make changes or enhancements as an employee, then a simple statement such as the above is insufficient. You must also send by surface mail a copyright release signed by a company officer. A signed original of the copyright release should be mailed to: """

The number of people that have touched the runtime layer of Tango is very limited. The upper layers are of no concern for this thread. Later, Brad
Aug 13 2008
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
<snip thread arguing both sides of the is there such a thing as IP>

Guys.. I highly suggest just dropping this part of the thread.  Neither
side will ever change the mind of the other.  It's a waste of time and
energy.

Later,
Brad
Aug 14 2008
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Sean Kelly schrieb:
 
 3.) the closures are not really closures. E.g. const variables can 
 change value. (Bug 2043)

This one, at least, is clearly a bug.

I think this is not a bug in the compiler. Instead it shows the bug in the concept. The concept is "simply allocate the whole stack frame on the heap". But it turns out to be not sufficient. Now what? Heap allocated each scope also? for every loop iteration?
Aug 11 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Frank Benoit (keinfarbton googlemail.com)'s article
 Sean Kelly schrieb:
 3.) the closures are not really closures. E.g. const variables can
 change value. (Bug 2043)

This one, at least, is clearly a bug.

the concept. The concept is "simply allocate the whole stack frame on the heap". But it turns out to be not sufficient. Now what? Heap allocated each scope also? for every loop iteration?

Yup. It's essentially the same as heap allocating for the scope created by a function call. I imagine the hope is that compiler introspection would be able to figure out when such allocations are necessary and when only one would suffice. Barring that, the programmer would need some way of indicating this to the compiler, which is something we need anyway as always heap allocating in a systems language renders delegates unusable for certain classes of application. Sean
Aug 11 2008
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
I'm sorry this just seems like crap logic. I probably will be unhappy 
about going into this but oh well.

On Fri, 15 Aug 2008 05:25:08 +0300, Yigal Chripun wrote:

 Warning: this can turn into a long debate...
 
 Robert Fraser wrote:
 Yigal Chripun Wrote:
 
 Robert Fraser wrote:
  > I've had very mixed feelings about all this. One one hand, the
  > letter
 of the
 law may be questionably constitutional. But millions of dollars every
 day are lost because people (including myself occasionally...) steal
 copyrighted material. Honestly, I think there should be much stricter
 penalties for things like internet piracy, because it's simply so
 widespread and damaging.

the constitution) but all of the above is bullshit. (sorry for the language). stealing only applies to physical things like chairs and cars. that whole metaphor of information as physical entities is wrong. you sure can infringe someone's copyrights but you cannot steal anything since there's nothing to steal.

Some philosopher said that all philosophical debates were inherently linguistic ones that stemmed from not having the words to represent the concepts being spoken about. We're using different definitions of "steal," but the concept is clear -- it's taking something you don't have the right to have taken without paying for, and the debate is over whether you do or should have that right.

I won't argue about wording and linguistics with you. this would be just silly. I'll simply agree that my definition of what stilling is differs from yours. I do disagree on one thing though: everything in life is a balance and a compromise. Democracy is a compromise between the rights of the individual and that of the community he belongs to, for one example. this notion of compromise is inherit in our discussion as well: on the one hand we have the right of the content creator to do what he wants with his creation and on the other hand we have the right of the public to access that creation. So we disagree on where the balance lies. However, please do not claim "it's taking something you don't have the right to have taken" since that right is also is present.

Why does the public have the right to access that creation? I'm sorry, I don't think me or Robert would agree with you that when something has been created everyone has the right to have access to that creation.
 Now that we cleared that out of the way, let's touch other nonsenses
 in what you wrote:

 A) "millions of dollars every day are lost..." - Not true. you assume
 that if a person doesn't pirate he would have payed for the stuff.
 this is a wrong assumption since the majority of people would just use
 other alternatives.

Sure not everyone would have paid. But at least one person would have paid. Back in high school, I would have paid for a lot of the music I downloaded (perhaps not all of it) -- but I didn't since it was so easy for me to pirate it. The statement is that piracy costs at least $1 million/day in LOST SALES; if you would have used a free alternative, that's not factored into the argument.

Hence, that statement is flawed since the vast majority of people would *NOT* have bought the content in question.
 
 if I wouldn't be able to pirate MS office

Mah paycheck!!! (that's paying me to post on D NGs...)
 I'd probably
 search for a cheap commercial solution or install Open Office which is
 good enough for me and most other private people and small companies.
 no one in their right mind would pay 500$ for an office suit. think
 globally: in US standards paying for software is not that expensive
 and is convenient (and you pay for that as well) but for most of the
 world those prices are high. in Israel 500$ translates to roughly 2000
 NIS which is a lot.
 B)"it's simply so ... damaging" - not so. If you look at music and
 films than the image is backwards: since it's easy to pirate I can
 download a lot of stuff try it out and only keep what I like. If I
 like it I'll tell friends and more people will be exposed to the
 content. pirating actually makes money for the copyright holder and
 helps him get recognized since it's advertising they don't need to pay
 for.

I'm going to cry bull**** here. Quite a few sites offer legit free music/ video. The content creators/producers have made this available for precisely the reason you said -- so people view it and tell their friends or choose to buy higher-quality versions of it. The stuff they DON'T make available for free is not there because it is more profitable for them not to make it available. The creators/producers choose what to share for free -- NOT the consumers.

for the _convenience_ of being able to download music online in good [lossless probably] quality. people are also willing to buy merchandise to support their favorite artist and of course, people are willing to pay to attend a concert/performance/etc of the artist. Those are all logical business models. however, people *aren't* willing to pay for the /right/ to download music. Where's the balance? simple - The record companies where selling us a cat in the bag for years and demanding us to pay again {and a larger sum at that] each time they switch formats. That's unacceptable to me. I am willing to pay for the convenience of an online service if that service was in fact convenient and I could get a feeling what I'm paying for. This does not mean DRM [this is finally dawned upon the companies]. A consumer expects that just like when he buys a car where he can drive it on what ever road he wants, the same would happen with the music. Since Apple allow for non-drm music in itunes - this is the last thing that needs to change in order for me to buy my music there. (also, I think the price is a bit high but that's just a matter of pricing which is solved by market forces) As soon as those online service evolve into something that is really convenient there will be no reason for the average user to want to pirate. pirating will never completely disappear but they'll be a minor thing.

Your claim is that most people only pirate for convenience. I can see this for some, but I do not see it as a majority. I know people will not only buy products the pirate because the like them, but pirate products they bought to have more control over them. I realize that helps your case and not mine, but I facts are good to have.
 If what you said was true than Red Hat and Novel wouldn't lasted more
 than a day. after all you can legally download their products from
 their
  respective websites!

Their business model is to make money off the support for their software, not the software itself.

exactly. just one of the million posibilities of viable business models that do not equate the consumer and end user of the product to thieves, pirates and sinners in general.

You can sell software/music... and not treat your customers as thieves. Your only say that this model makes it impossible for an end-user to become one.
 
 
 The issue is not whether piracy is moral or not. it's a fact of life -
 the internet provides an efficient means for distribution of
 information. either you take advantage of it or you insist on your old
 irrelevant business model and go extinct.

Selling software/music/video/intellectual property for money is an extinct business model...? If that's your argument then o_O.

That's partly my argument. When was the last time you used a telegraph? That technology was replaced be better technologies. So what what about all those people that where trained with Morse code and telegraph equipment? Should the government force us to use telegraphs in order for them to keep their jobs? What about silent film actors? today actors are required to be able to speak properly as part of their profession, So what about all those actors that cannot speak properly? There are of course more examples where a new technology deprecated some profession or job. Same goes for all the jobs at record companies - they are unneeded and the record company itself is redundant in a world where the artist can create he's work alone and reach his audience directly via the web.

This statement shows that we are fight 2 different battles. I don't care about record companies, and I don't think Robert does either. If you aren't buying records/cds whatever it is they do to publish work, they don't need to make money. However, the creator/composer/programmer what- have-you can/should/does have the right to charge/limit/collect/deny... what-not his work in any manner he sees fit. If he goes through a record company that is the only legal distribution of his work that can be obtained. You do not have the right to decide his choice of distribution is invalid because it does not suit you. When you buy it you are also not buying the right to redistribute it. The owner also has the right to limit the medium to which his product can run. While I think these things, DRM, are stupid it is still their right, and thus I decided not to buy it. Unfortunately that is how the free market work. It is not a matter of, If I want the product I can access it by any means necessary, but I can either live with the choice of the author or boycott it. And boycotting fails because of the number of people that go with option 1. Question, a lot of your argument rides on the one that pirated either getting others to buy the product or purchasing other products from the creator. What if none of that happens and the creator makes no money on said pirate, is it still not stealing?
 
 
 business 101 - "The customer
 is always right." the moment they (RIAA, MPAA, etc..) broke that rule
 because they refused to evolve with respect to new technology and
 business models is the moment they signed their death warrants.

 I prefer supporting music artists by going to a concert and paying
 100$ for a ticket rather than paying for CDs with shitty music the
 records companies advertise and try to stick in my throat.

 one last thing, before suggesting more penalties and such please read
 the following: http://www.gnu.org/philosophy/right-to-read.html
 *after* reading this, are you sure still that this is the way to go?

I think what a lot of these arguments boil down to is people trying to justify taking stuff without paying for it. Plain and simple. I do on occasion download videos (these days only anime fansubs). And I don't feel bad about it. But I do know it's stealing. Downloading a $10 CD is really no better than shoplifting a $10 CD, because the people who worked to bring that CD into existence are not being paid for it.


Aug 14 2008
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Fri, 15 Aug 2008 14:41:20 -0700, Walter Bright wrote:

 Sean Kelly wrote:
 Walter Bright wrote:
 Steven Schveighoffer wrote:
 As far as threads, I agree.  One must be chosen.

The threading issue is more problematic. D 2.0 is doing a ground up rethink on how to approach threading, and it's hard to imagine that not impacting the threading part of the library.

So is classic threading going to be thrown out entirely? If so then I guess it eliminates the problem of exposing a Thread class.

I don't know. Bartosz is working on it. He understands the issues far better than I do. What I do believe is that handling concurrency well will be a breakthrough feature for D.

Sounds like a nifty feature, but please keep in mind that users like to have control about everything if they want to. Otherwise D is becoming quite restricted. Like the garbage collector (GC) can be turned off and manual memory management can be used, automatic threading in D should give similar control. But the current gc handling is a bit inflexible. Turning off the gc still leaves the gc code in the binary without additional work. But that's another story. :)
Aug 15 2008
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Jarrett Billingsley wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:g7mboq$qcl$1 digitalmars.com...
 
 Also as long as closures are allocated on stack, that is likely to be
 rather
 detrimental to the performance.

Heap.

Heap. Stack. Hack. Ehrm ... sorry ... -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 10 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 14 Aug 2008 22:15:50 +0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 Walter Bright wrote:
 Paul D. Anderson wrote:
 Thanks for clarifying this, and I apologize, Walter, and reiterate my
 appreciation for what you do. But I was expressing my frustration at
 what I thought the situation was. If there was discussion about
 licensing issues I missed it. (I missed your earlier post in this
 thread because I was busy "composing" my tirade.)

 From my point of view this puts the ball squarely back in Tango's
 court. Is there a fundamental problem here? Can we move forward?

developers' right to license Tango as they see fit. These discussions have been done via email, not on a public forum. I know that not all of the Tango developers were involved with it, as quite a diverse group has worked on Tango, and I apologize for that. But it is clearly time to bring this out into the open.

I don't want to speak for others, but I believe that the issue with opening up the license for Tango concerns the user code, not the runtime. The initial request was for rights to all of Tango. Sean

That's a merger - a process so many people are waiting for!
Aug 14 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Sun, 10 Aug 2008 13:18:20 +0400, Lars Ivar Igesund  
<larsivar igesund.net> wrote:

 Nick B wrote:

 Sean

 So what is the plan to transition Tango to D2.0 ?

 Is the Tango team waiting for const to be removed from D2.0, or will
 Tango continue to use D1.0 forever, or is the team waiting to see the
 final form of D2.0 before deciding what to do ?

We don't expect const to be removed :) As it is, this must be resolved before it is possible to properly port Tango: http://d.puremagic.com/issues/show_bug.cgi?id=2267 1644 was fixed now, but is in our opinion the lesser solution to the problem - we'd much rather have 1961. 2204 is still open I think. Also as long as closures are allocated on stack, that is likely to be rather detrimental to the performance. Once we have a resolution on that, work on the Tango D 2.0 branch will probably continue, and this branch will be available to all who need it. If possible, an official release may happen shortly after the time Walter calls D 2.0 to be stable. One other concern is that it is almost impossible to have code that is both D1 and D2 compatible, something which mean the mantainance of two branches, a potentially daunting task - it would be good if the "syntactical correctness" restriction on versioned out blocks could be removed for at least D1/D2 identifiers.

We need some other kind of `version' for this, I'm afraid. Something like this, maybe: #version (StructInsteadOfClass) struct Foo { #else class Foo { #end void bar() {} }
Aug 11 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Mon, 11 Aug 2008 20:03:29 +0400, Koroskin Denis <2korden gmail.com>  
wrote:

 On Sun, 10 Aug 2008 13:18:20 +0400, Lars Ivar Igesund  
 <larsivar igesund.net> wrote:

 Nick B wrote:

 Sean

 So what is the plan to transition Tango to D2.0 ?

 Is the Tango team waiting for const to be removed from D2.0, or will
 Tango continue to use D1.0 forever, or is the team waiting to see the
 final form of D2.0 before deciding what to do ?

We don't expect const to be removed :) As it is, this must be resolved before it is possible to properly port Tango: http://d.puremagic.com/issues/show_bug.cgi?id=2267 1644 was fixed now, but is in our opinion the lesser solution to the problem - we'd much rather have 1961. 2204 is still open I think. Also as long as closures are allocated on stack, that is likely to be rather detrimental to the performance. Once we have a resolution on that, work on the Tango D 2.0 branch will probably continue, and this branch will be available to all who need it. If possible, an official release may happen shortly after the time Walter calls D 2.0 to be stable. One other concern is that it is almost impossible to have code that is both D1 and D2 compatible, something which mean the mantainance of two branches, a potentially daunting task - it would be good if the "syntactical correctness" restriction on versioned out blocks could be removed for at least D1/D2 identifiers.

We need some other kind of `version' for this, I'm afraid. Something like this, maybe: #version (StructInsteadOfClass) struct Foo { #else class Foo { #end void bar() {} }

I would also like to have something like this: #if CompileTimeConfig.TargetOS == OS.MacOS && CompileTimeConfig.TargetOSVersion >= 10_3_2 // do something #else // do something else #endif Note that it is exactly like static if (sameCondition) { } (i.e. it can benefit from CTFE etc), but allows wrong code in false clause.
Aug 11 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Mon, 11 Aug 2008 22:39:56 +0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 Frank Benoit wrote:
 Jarrett Billingsley schrieb:
 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message  
 news:g7mboq$qcl$1 digitalmars.com...

 Also as long as closures are allocated on stack, that is likely to be  
 rather
 detrimental to the performance.

Heap. That is another major blocker for me besides const. Most of my code uses nested functions that are never supposed to be closures, and this "feature" would cause it all to unnecessarily allocate memory.

It is an closure solution which was implemented too easy, imho. 1.) it breaks the semantic of an existing syntax. So existing code can be broken without any warning. (change in runtime behaviour)

Yup. Much like the change in meaning of "const," which I've admittedly complained about perhaps overmuch.
 2.) there is still no alternative syntax to get the old behaviour

I would prefer that the old behavior the the default and that "new &fn" or something similar would be used for full closures.

If I understand the issue correctly, it's not a delegate itself that should be allocated on heap but rather a function context (i.e. local variables): auto foo() { int i = 0; int bar() { return ++i; } return &bar; } It's clear enough that i should be allocated on heap. On the other side, there is a scope modifier, that doesn't allow returning of pointer to the attributed variable: auto foo() { scope Bar bar = new Bar(); return bar; // illegal } So these variables should be allocated on stack in any case, even for delegates: auto foo() { scope Bar bar = new Bar(); Bar foobar() { return bar; } doSomething(&foobar); // legal (unless foobar is saved somewhere in global scope) return &foobar; // illegal } Note that bar is a scoped variable and isn't supposed to be heap allocated. So a solution would be to allow marking built-in type and struct instances as scope, too, and those variable won't be heap allocated. The default one, however, would be non-scope, i.e. heap-allocated. It fits perfectly with current semantics, it allows marking of some variables as heap- others as scope-allocated (flexibility), it doesn't introduce any new keywords or concepts.
 3.) the closures are not really closures. E.g. const variables can  
 change value. (Bug 2043)

This one, at least, is clearly a bug. Sean

Aug 12 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:

 Examples of other possible improvements:
 foreach (i, x in array)
 instead of:
 foreach (i, x; array)
 (But people here have explained me that despite this being better for  
 the programmer it's worse for the compiler, making it more complex etc,  
 and in the end a worse compiler is bad for the programmer too).

Why not make it foreach (i, x of ar) ? Oh right. Because that would add keywords to the language. Other ideas (that do not add keywords): foreach (i, x with ar) foreach (i, x for ar) foreach (i, x scope ar) and of course, there's my favorite: foreach (i, x enum ar) -- Simen
Aug 12 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 13 Aug 2008 15:25:29 +0400, Lars Ivar Igesund  
<larsivar igesund.net> wrote:

 Nick B wrote:

 Lars Ivar Igesund wrote:
 dsimcha wrote:

 What about, at least initially, releasing a subset of Tango for D2 and
 gradually
 porting more as issues are fixed?  For example, just for now, just
 release whatever subset of Tango is high-level enough to run on top of
 the D2 Phobos runtime and isn't plagued too severely by const issues,
 even if it doesn't mesh
 perfectly, i.e. requires some casting, etc. on the part of client  
 code.

There isn't really a subset of Tango that can run on top of any Phobos runtime. The Tango runtime probably works fine with D2 without any major changes, it is the user library that is problematic. The work on the porting has begun in a branch in Tango's svn repository, but cannot be continued properly until certain issues are fixed.
 I'm not really sure, but I would guess that this would leave a
 reasonably large subset with plenty of useful things.

 To be honest, I'm not sure how feasible this is, but I thought I would
 throw it
 out there as a suggestion.  Tango is a huge library with tons of nice
 stuff, and it seems like a shame that D2 users can't use any of it if
 only parts of it are broken.

It is typically the behaviour of certain core parts (text manipulation, io) that doesn't work properly, and so most of the other parts of Tango won't work either. Right now it isn't really compilable either if I understand correctly. But we got people on it! :) Really, it would be swell if Tango could work with D2, but currently D2 is not usable for a library like Tango.


Bugzilla entries exists, it is up to Walter to decide the way forward.

The biggest issue is diffent Tango and Phobos runtime implementation, I think. I didn't find any bugzilla reports on this subject, though. :(
Aug 13 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 13 Aug 2008 15:29:45 +0400, Denis Koroskin wrote:


 The biggest issue is diffent Tango and Phobos runtime implementation, I
 think.
 I didn't find any bugzilla reports on this subject, though. :(

I haven't taken a look at those runtime implementation differences, but I wonder why there are no activities to solve this issue. It makes it look like the participants are playing the golden throne game...
Aug 13 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 14 Aug 2008 12:02:46 +0400, Lars Ivar Igesund  
<larsivar igesund.net> wrote:

 Walter Bright wrote:

 Lars Ivar Igesund wrote:
 There isn't really a subset of Tango that can run on top of any Phobos
 runtime. The Tango runtime probably works fine with D2 without any  
 major
 changes, it is the user library that is problematic. The work on the
 porting has begun in a branch in Tango's svn repository, but cannot be
 continued properly until certain issues are fixed.

I don't understand. I fixed the one issue you identified to me that was impeding Tango on D2 (Bugzilla 1644, and 2204 is the same). What else is there?

I wasn't aware that 2204 was a duplicate of 1644, and I guess Steven wasn't either. If there are no further stumbling blocks, all are great :) Although, clearly, the better solution would be fixing Bugzilla 1961, 1644 is only a workaround for that.

Too bad 2204 was marked as an acceptable solution :)
Aug 14 2008
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Thu, 14 Aug 2008 11:49:06 -0700, Sean Kelly wrote:

 Walter Bright wrote:
 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 I have explained this to the main Tango developers on multiple
 occasions. It is their right and privilege to license Tango as they
 see fit, and I respect that and so have not spoken out on it before.
 But in this thread I am being cast as a roadblock, which I feel is a
 little unfair, so I will loosen my tongue and speak up a bit :-)

And we have on equally many occasions told you that the code you need is available. :)

I respectfully disagree. The Tango team has stopped short of providing a license to use the Tango code in Phobos with a reciprocal agreement that allows it to be distributed under the Phobos license. I also cannot accept something vague, it has to be explicit. I've dealt with lawyers many times, and spelling it out directly and explicitly avoids a lot of future potential problems. Furthermore, if Phobos has a wishy-washy legal pedigree, corporate lawyers will not buy off on allowing D to be used in their companies.

Personally, I've never met a corporate lawyer who would authorize use of Public Domain code, for two reasons. First, the assumption seems to be that PD code is really actually owned by someone and no one knows who that is. Second, lawyers (and build teams even moreso) very much like having a responsible party, even if the license absolves the author of any direct responsibility for code issues as most licenses do. Case in point, I've never been able to use Boost at any of my previous jobs because the licensing scheme is too open. Also, I've had to fight tooth and nail to use BSD licensed code at work because of the attribution requirement (that the library must be mentioned in documentation accompanying any shipped product). All of the above was considered when working out a licensing scheme for Tango. We wanted a license that would allow Tango to be used by everyone, first and foremost. I could never have done that with Phobos under the current license.
 This issue must be settled in advance of looking at Tango, not after
 the fact.

The contention is about the user code, I believe. You have asked for blanket permission to incorporate all of Tango as Public Domain code in Phobos even though the only portion of the code you seem to care about is the runtime. As the sole maintainer of the runtime I have long since given you permission to use that portion of the code as you see fit, but this is obviously not sufficient. I honestly have no idea how we can proceed any further, given that I don't expect other Tango contributors to agree to release their (user) code into the Public Domain. Sean

That issue will probably be sorted out (I hope). But that don't have to be done right now. There is no license issue with the Tango runtime, Work could be started with the runtime any time. - right? Walter? Sean?
Aug 14 2008