www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D library projects

reply Walter Bright <newshound1 digitalmars.com> writes:
For anyone looking for an easy, but valuable, contribution to D, take a 
look at the go runtime library.

There's a lot in there we could use in the D library:

http://golang.org/pkg/

The library is licensed under the 
http://creativecommons.org/licenses/by/3.0/
meaning we can adapt it to D.

Some packages that look particularly useful are:

archive.tar
compress.flate
crypto
debug
ebnf
encoding
gob
http
image
net
rpc
Nov 12 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 For anyone looking for an easy, but valuable, contribution to D, take a 
 look at the go runtime library.
 
 There's a lot in there we could use in the D library:
 
 http://golang.org/pkg/
 
 The library is licensed under the 
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.
 
 Some packages that look particularly useful are:
 
 archive.tar
 compress.flate
 crypto
 debug
 ebnf
 encoding
 gob
 http
 image
 net
 rpc

Ever heard of Tango?
Nov 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would require permission from the author(s) of those packages, as they'd need to be relicensed. (Tango uses the BSD license which seems to require notice on all binaries compiled with it, this is unacceptable for Phobos.) So far, only Sean and Don have been willing to do this.
Nov 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 14:40:10 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:
 grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would require permission from the author(s) of those packages, as they'd need to be relicensed. (Tango uses the BSD license which seems to require notice on all binaries compiled with it, this is unacceptable for Phobos.) So far, only Sean and Don have been willing to do this.

License 3.0) allows binary distribution without attribution. See http://www.dsource.org/projects/tango/wiki/License -Steve

Is there a plain English explanation of the Academic Free License anywhere? I read this somewhere on the Tango website before, but I wasn't sure how significant it was, since the Academic Free License is dense, long legalese w/o any plain English explanations. It would be truly great if Tango could be used under a license with permissiveness equivalent to the Boost license. It would help mend a pretty significant rift in the D community that started over a minor technicality.
Nov 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 It would be truly great if Tango could be used under a license with
permissiveness
 equivalent to the Boost license.  It would help mend a pretty significant rift
in
 the D community that started over a minor technicality.

Sean did a lot of searching, and found that the Boost license was the most permissive, so Phobos was relicensed with the Boost license. If Tango could dual license with Boost, this would slam-dunk solve the licensing issues once and for all. I hope the Tango team will consider this.
Nov 12 2009
parent reply Jacob Carlborg <doob me.com> writes:
On 11/12/09 22:02, Walter Bright wrote:
 dsimcha wrote:
 It would be truly great if Tango could be used under a license with
 permissiveness
 equivalent to the Boost license. It would help mend a pretty
 significant rift in
 the D community that started over a minor technicality.

Sean did a lot of searching, and found that the Boost license was the most permissive, so Phobos was relicensed with the Boost license. If Tango could dual license with Boost, this would slam-dunk solve the licensing issues once and for all. I hope the Tango team will consider this.

It's being discussed here: http://www.dsource.org/projects/tango/forums/topic/786#3407
Nov 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 It's being discussed here: 
 http://www.dsource.org/projects/tango/forums/topic/786#3407

Thanks for the pointer. I see the discussion is about adopting the Apache license. I strongly suggest considering the Boost license, as it is very permissive, and Phobos has converted to it. Boost has been battle-tested in the C++ community for years, and I am not aware of any problems or controversies about it. Another nice plus is that C++ users will likely already be familiar with Boost, their company lawyers likely have already approved using Boost licensed code, and so will be comfortable using D libraries identically licensed. http://www.boost.org/LICENSE_1_0.txt http://en.wikipedia.org/wiki/Boost_Software_License =========================================== Boost Software License - Version 1.0 - August 17th, 2003 Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ========================================================
Nov 12 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Robert Jacques wrote:
 
 The Apache 2.0 license requires attribution. It's therefore unsuitable 
 for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without proper 
 attribution;
 use any marks owned by The Apache Software Foundation in any way that 
 might state or imply that the Foundation endorses your distribution;
 use any marks owned by The Apache Software Foundation in any way that 
 might state or imply that you created the Apache software in question.
 
 It requires you to:
 include a copy of the license in any redistribution you may make that 
 includes Apache software;
 provide clear attribution to The Apache Software Foundation for any 
 distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.
Nov 12 2009
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Robert Jacques wrote:
 On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun <yigal100 gmail.com> 
 wrote:
 
 Robert Jacques wrote:
  The Apache 2.0 license requires attribution. It's therefore 
 unsuitable for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without proper 
 attribution;
 use any marks owned by The Apache Software Foundation in any way that 
 might state or imply that the Foundation endorses your distribution;
 use any marks owned by The Apache Software Foundation in any way that 
 might state or imply that you created the Apache software in question.
  It requires you to:
 include a copy of the license in any redistribution you may make that 
 includes Apache software;
 provide clear attribution to The Apache Software Foundation for any 
 distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.

First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW).

Ok, I ain't a layer so let's see if I understood you correctly: You're saying that if I write code using Tango, I can license *my* code with whatever I want. My source will require a tango dll to work and *that* dll must come with its apache 2.0 license file. That sounds completely reasonable to me. I don't get what the problem with this scheme of things.
Nov 13 2009
next sibling parent reply Don <nospam nospam.com> writes:
Yigal Chripun wrote:
 Robert Jacques wrote:
 On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun <yigal100 gmail.com> 
 wrote:

 Robert Jacques wrote:
  The Apache 2.0 license requires attribution. It's therefore 
 unsuitable for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without proper 
 attribution;
 use any marks owned by The Apache Software Foundation in any way 
 that might state or imply that the Foundation endorses your 
 distribution;
 use any marks owned by The Apache Software Foundation in any way 
 that might state or imply that you created the Apache software in 
 question.
  It requires you to:
 include a copy of the license in any redistribution you may make 
 that includes Apache software;
 provide clear attribution to The Apache Software Foundation for any 
 distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.

First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW).

Ok, I ain't a layer so let's see if I understood you correctly: You're saying that if I write code using Tango, I can license *my* code with whatever I want. My source will require a tango dll to work and *that* dll must come with its apache 2.0 license file. That sounds completely reasonable to me. I don't get what the problem with this scheme of things.

At the present time, D DLLs don't work with D apps. Only static linking works. And disallowing static linking is utterly ridiculous, anyway. Conditions 2 and 3 above are no problem. I'm a bit scared of 1, though. What does "give" mean? (It's not even "make available"). Sounds as though EVERY D app (even "Hello, world" apps) would need to include a license file for the standard library.
Nov 13 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Don wrote:
 Yigal Chripun wrote:
 Robert Jacques wrote:
 On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun 
 <yigal100 gmail.com> wrote:

 Robert Jacques wrote:
  The Apache 2.0 license requires attribution. It's therefore 
 unsuitable for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without proper 
 attribution;
 use any marks owned by The Apache Software Foundation in any way 
 that might state or imply that the Foundation endorses your 
 distribution;
 use any marks owned by The Apache Software Foundation in any way 
 that might state or imply that you created the Apache software in 
 question.
  It requires you to:
 include a copy of the license in any redistribution you may make 
 that includes Apache software;
 provide clear attribution to The Apache Software Foundation for any 
 distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.

First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW).

Ok, I ain't a layer so let's see if I understood you correctly: You're saying that if I write code using Tango, I can license *my* code with whatever I want. My source will require a tango dll to work and *that* dll must come with its apache 2.0 license file. That sounds completely reasonable to me. I don't get what the problem with this scheme of things.

At the present time, D DLLs don't work with D apps. Only static linking works. And disallowing static linking is utterly ridiculous, anyway. Conditions 2 and 3 above are no problem. I'm a bit scared of 1, though. What does "give" mean? (It's not even "make available"). Sounds as though EVERY D app (even "Hello, world" apps) would need to include a license file for the standard library.

I agree, supplying the stdlib license file with a hello, world executable would be very bad. Generally speaking, is static linking of the stdlib the right thing? I realize that's the only working option now, but when this is fixed (and it really should be fixed) would that still be the correct choice for the stdlib?
Nov 13 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
On 11/13/09 11:11, Yigal Chripun wrote:
 Don wrote:
 Yigal Chripun wrote:
 Robert Jacques wrote:
 On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun
 <yigal100 gmail.com> wrote:

 Robert Jacques wrote:
 The Apache 2.0 license requires attribution. It's therefore
 unsuitable for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without
 proper attribution;
 use any marks owned by The Apache Software Foundation in any way
 that might state or imply that the Foundation endorses your
 distribution;
 use any marks owned by The Apache Software Foundation in any way
 that might state or imply that you created the Apache software in
 question.
 It requires you to:
 include a copy of the license in any redistribution you may make
 that includes Apache software;
 provide clear attribution to The Apache Software Foundation for
 any distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.

First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW).

Ok, I ain't a layer so let's see if I understood you correctly: You're saying that if I write code using Tango, I can license *my* code with whatever I want. My source will require a tango dll to work and *that* dll must come with its apache 2.0 license file. That sounds completely reasonable to me. I don't get what the problem with this scheme of things.

At the present time, D DLLs don't work with D apps. Only static linking works. And disallowing static linking is utterly ridiculous, anyway. Conditions 2 and 3 above are no problem. I'm a bit scared of 1, though. What does "give" mean? (It's not even "make available"). Sounds as though EVERY D app (even "Hello, world" apps) would need to include a license file for the standard library.

I agree, supplying the stdlib license file with a hello, world executable would be very bad. Generally speaking, is static linking of the stdlib the right thing? I realize that's the only working option now, but when this is fixed (and it really should be fixed) would that still be the correct choice for the stdlib?

For C the obvious answer is dynamic linking because the target machine will (almost) always have the stdlib/runtime. For D I'm not sure, static linking allows stand alone applications.
Nov 13 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Yigal Chripun (yigal100 gmail.com)'s article
 Generally speaking, is static linking of the stdlib the right thing?
 I realize that's the only working option now, but when this is fixed
 (and it really should be fixed) would that still be the correct choice
 for the stdlib?

Yes, it is. First of all, much of the std. lib is templates. Here you don't have much of a choice. Second, IMHO dynamic linking is generally more trouble than it's worth. Static linking may be inefficient in that you keep 1 copy of each lib per process in memory, but it "just works". No conflicts, dependencies, etc. To me this is a worthwhile tradeoff.
Nov 13 2009
parent Daniel de Kok <me nowhere.nospam> writes:
On 2009-11-13 17:10:44 +0100, dsimcha <dsimcha yahoo.com> said:

 == Quote from Yigal Chripun (yigal100 gmail.com)'s article
 Generally speaking, is static linking of the stdlib the right thing?
 I realize that's the only working option now, but when this is fixed
 (and it really should be fixed) would that still be the correct choice
 for the stdlib?

Yes, it is. First of all, much of the std. lib is templates. Here you don't have much of a choice. Second, IMHO dynamic linking is generally more trouble than it's worth. Static linking may be inefficient in that you keep 1 copy of each lib per process in memory, but it "just works". No conflicts, dependencies, etc. To me this is a worthwhile tradeoff.

When there is a vulnerability in a standard library function, you don't really want to recompile all programs making use of it. Of course, for templates there's not much of an option... Take care, Daniel
Nov 14 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 [...]

On dsource you wrote: "The current situation requires to get an explicit permission to change the license from each contributor for his code and if someone cannot be contacted for any reason, his contribution cannot be re-licensed." That's a big problem. The only solution I can see is to relicense with the Boost license whatever you can of Tango. We faced the same issue with Phobos, and we're just going to dump what cannot be relicensed.
Nov 13 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 13/11/2009 20:51, Walter Bright wrote:
 Yigal Chripun wrote:
 [...]

On dsource you wrote: "The current situation requires to get an explicit permission to change the license from each contributor for his code and if someone cannot be contacted for any reason, his contribution cannot be re-licensed." That's a big problem. The only solution I can see is to relicense with the Boost license whatever you can of Tango. We faced the same issue with Phobos, and we're just going to dump what cannot be relicensed.

This is very important IMO, probably as important as the license itself. This is exactly why the GNU project rejects contributions even if they are licensed under the GPL unless the the contributer agrees to give ownership of the copyright to the FSF (the legal entity for the GNU project). Almost all open source projects do the same. a notable exception is the linux kernel and I think this influenced the decision to not upgrade to GPL3. Does that mean that all of Phobos is under one legal entity - Digital Mars I presume? If not, than it really should be and you should require the same policy for future contributions. I don't want to see each module licensed under a different person (Andrei, Sean, You, etc..).
Nov 14 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Yigal Chripun (yigal100 gmail.com)'s article
 On 13/11/2009 20:51, Walter Bright wrote:
 Yigal Chripun wrote:
 [...]

On dsource you wrote: "The current situation requires to get an explicit permission to change the license from each contributor for his code and if someone cannot be contacted for any reason, his contribution cannot be re-licensed." That's a big problem. The only solution I can see is to relicense with the Boost license whatever you can of Tango. We faced the same issue with Phobos, and we're just going to dump what cannot be relicensed.

This is exactly why the GNU project rejects contributions even if they are licensed under the GPL unless the the contributer agrees to give ownership of the copyright to the FSF (the legal entity for the GNU project). Almost all open source projects do the same. a notable exception is the linux kernel and I think this influenced the decision to not upgrade to GPL3. Does that mean that all of Phobos is under one legal entity - Digital Mars I presume? If not, than it really should be and you should require the same policy for future contributions. I don't want to see each module licensed under a different person (Andrei, Sean, You, etc..).

I personally would have a hard time giving the copyright up for stuff that I worked on without pay. I don't mind licensing it permissively, but the idea that it's even possible (even if it's not likely) for someone to prevent me from relicensing subsequent versions own code under whatever terms I want bothers me. For example, let's say that (hypothetically, not that this has any chance of happening) that Digital Mars switched to GPL for Phobos. If I had given them the copyright to my code, I wouldn't be able to keep the stuff I wrote permissively licensed.
Nov 14 2009
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 15/11/2009 00:28, dsimcha wrote:
 == Quote from Yigal Chripun (yigal100 gmail.com)'s article
 On 13/11/2009 20:51, Walter Bright wrote:
 Yigal Chripun wrote:
 [...]

On dsource you wrote: "The current situation requires to get an explicit permission to change the license from each contributor for his code and if someone cannot be contacted for any reason, his contribution cannot be re-licensed." That's a big problem. The only solution I can see is to relicense with the Boost license whatever you can of Tango. We faced the same issue with Phobos, and we're just going to dump what cannot be relicensed.

This is exactly why the GNU project rejects contributions even if they are licensed under the GPL unless the the contributer agrees to give ownership of the copyright to the FSF (the legal entity for the GNU project). Almost all open source projects do the same. a notable exception is the linux kernel and I think this influenced the decision to not upgrade to GPL3. Does that mean that all of Phobos is under one legal entity - Digital Mars I presume? If not, than it really should be and you should require the same policy for future contributions. I don't want to see each module licensed under a different person (Andrei, Sean, You, etc..).

I personally would have a hard time giving the copyright up for stuff that I worked on without pay. I don't mind licensing it permissively, but the idea that it's even possible (even if it's not likely) for someone to prevent me from relicensing subsequent versions own code under whatever terms I want bothers me. For example, let's say that (hypothetically, not that this has any chance of happening) that Digital Mars switched to GPL for Phobos. If I had given them the copyright to my code, I wouldn't be able to keep the stuff I wrote permissively licensed.

I can't see how that's possible. if you contribute to Phobos under Boost license and Phobos is re-licensed under GPL that would mean that any future versions would be GPL but you should be able to fork your original Boost licensed version and release subsequent versions of that under Boost license. The project needs to have the ability to adapt its license in the future due to various reasons. case in point is tango: they are discussing changing the license and maybe even go with a Phobos compatible license to help a merger of the two code bases. this requires all contributors (past and present) to agree to this and if somebody cannot be contacted for whatever reason (maybe he lost interest in Tango and D) than his code cannot be re-licensed. Big problem.
Nov 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 I can't see how that's possible. if you contribute to Phobos under Boost 
 license and Phobos is re-licensed under GPL that would mean that any 
 future versions would be GPL but you should be able to fork your 
 original Boost licensed version and release subsequent versions of that 
 under Boost license.
 
 The project needs to have the ability to adapt its license in the future 
 due to various reasons. case in point is tango: they are discussing 
 changing the license and maybe even go with a Phobos compatible license 
 to help a merger of the two code bases. this requires all contributors 
 (past and present) to agree to this and if somebody cannot be contacted 
 for whatever reason (maybe he lost interest in Tango and D) than his 
 code cannot be re-licensed. Big problem.

I agree. A relicense cannot take away a license granted for the older versions - it would only apply to the newer ones. For the Tango problem, I expect it'll wind up with a few modules that cannot be relicensed. Those will remain incompatible with Phobos, and so be it. Meanwhile, the rest will be compatible, hopefully that's enough and we can resolve these compatibility problems. Note that Druntime is based on my code I permissively licensed to Tango (and anyone else), subsequently extensively modified by Sean and others, and relicensed by them back to Phobos. Same goes for math functions by Don. So it is possible and productive to do this.
Nov 14 2009
prev sibling parent Janzert <janzert janzert.com> writes:
dsimcha wrote:
 == Quote from Yigal Chripun (yigal100 gmail.com)'s article
 On 13/11/2009 20:51, Walter Bright wrote:
 Yigal Chripun wrote:

This is exactly why the GNU project rejects contributions even if they are licensed under the GPL unless the the contributer agrees to give ownership of the copyright to the FSF (the legal entity for the GNU project). Almost all open source projects do the same. a notable exception is the linux kernel and I think this influenced the decision to not upgrade to GPL3. Does that mean that all of Phobos is under one legal entity - Digital Mars I presume? If not, than it really should be and you should require the same policy for future contributions. I don't want to see each module licensed under a different person (Andrei, Sean, You, etc..).

I personally would have a hard time giving the copyright up for stuff that I worked on without pay. I don't mind licensing it permissively, but the idea that it's even possible (even if it's not likely) for someone to prevent me from relicensing subsequent versions own code under whatever terms I want bothers me. For example, let's say that (hypothetically, not that this has any chance of happening) that Digital Mars switched to GPL for Phobos. If I had given them the copyright to my code, I wouldn't be able to keep the stuff I wrote permissively licensed.

While I believe it's true the FSF does require taking ownership[1], this is by no means universal for large open source projects. The two I'm semi-familiar with and could find fairly quickly are the agreements for Apache and Python. The Apache Software Foundation agreement[2] grants the foundation a "perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works". Similarly the Python Software Foundation agreement[3] gives the foundation "the irrevocable and perpetual right to make and distribute copies of any Contribution, as well as to create and distribute collective works and derivative works of any Contribution". So while both allow them to relicense the contributions they do not take the copyright ownership from the original author. Janzert [1] The closest I could find for the FSF's contributor agreement was http://www.gnu.org/licenses/why-assign.html which states that they require a copyright assignment but I don't see the actual agreement anywhere. [2] http://www.apache.org/licenses/#clas [3] http://www.python.org/psf/contrib/contrib-form-python/
Nov 14 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 This is very important IMO, probably as important as the license itself.
 This is exactly why the GNU project rejects contributions even if they 
 are licensed under the GPL unless the the contributer agrees to give 
 ownership of the copyright to the FSF (the legal entity for the GNU 
 project).
 Almost all open source projects do the same. a notable exception is the 
 linux kernel and I think this influenced the decision to not upgrade to 
 GPL3.
 
 Does that mean that all of Phobos is under one legal entity - Digital 
 Mars I presume? If not, than it really should be and you should require 
 the same policy for future contributions.
 I don't want to see each module licensed under a different person 
 (Andrei, Sean, You, etc..).

I think you make a very good point.
Nov 14 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Yigal Chripun wrote:
 This is very important IMO, probably as important as the license itself.
 This is exactly why the GNU project rejects contributions even if they 
 are licensed under the GPL unless the the contributer agrees to give 
 ownership of the copyright to the FSF (the legal entity for the GNU 
 project).
 Almost all open source projects do the same. a notable exception is 
 the linux kernel and I think this influenced the decision to not 
 upgrade to GPL3.

 Does that mean that all of Phobos is under one legal entity - Digital 
 Mars I presume? If not, than it really should be and you should 
 require the same policy for future contributions.
 I don't want to see each module licensed under a different person 
 (Andrei, Sean, You, etc..).

I think you make a very good point.

I think the GNU stuff is a bit different, because the GPL is an aggressive license -- the FSF intends to defend the license, taking offenders to court. Legal battles are expected, and having a single legal entity makes it easier to win the case. By contrast, the Boost license exists solely for the benefit of the users, giving them a guarantee that court cases will _not_ occur. I think that throughout Boost all of the authors retain their original copyright.
Nov 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 I think the GNU stuff is a bit different, because the GPL is an 
 aggressive license -- the FSF intends to defend the license, taking 
 offenders to court. Legal battles are expected, and having a single 
 legal entity makes it easier to win the case.
 By contrast, the Boost license exists solely for the benefit of the 
 users, giving them a guarantee that court cases will _not_ occur.
 I think that throughout Boost all of the authors retain their original 
 copyright.

It's true that GPL has an agenda that is not always in its users' best interests. The Boost license does.
Nov 15 2009
parent Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Walter Bright wrote:
 Don wrote:
 I think the GNU stuff is a bit different, because the GPL is an 
 aggressive license -- the FSF intends to defend the license, taking 
 offenders to court. Legal battles are expected, and having a single 
 legal entity makes it easier to win the case.
 By contrast, the Boost license exists solely for the benefit of the 
 users, giving them a guarantee that court cases will _not_ occur.
 I think that throughout Boost all of the authors retain their original 
 copyright.

It's true that GPL has an agenda that is not always in its users' best interests. The Boost license does.

The reason the that the GPL has enforcement court cases is to stop vendors taking GPL code and trying to make it their own, without following the requirements of the GPL. For examples see gpl-violations http://gpl-violations.org/ The project wants to act as information and communication platform between all parties involved with licensing of free software: * authors and copyright holders * vendors, OEM's, VAR's * users more details under the history: http://gpl-violations.org/about.html#history Nick B.
Nov 15 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 You're saying that if I write code using Tango, I can license *my* code 
 with whatever I want. My source will require a tango dll to work and 
 *that* dll must come with its apache 2.0 license file.
 
 That sounds completely reasonable to me. I don't get what the problem 
 with this scheme of things.

The problems are: 1. There seems to be much confusion about what the Apache license actually means. This means the users will be confused about it too. The more they need lawyers and court opinions on what it means, the more likely they are to just move on and use something else. 2. Phobos uses the Boost license. In order to mix in Tango libraries, then Phobos will have to be dual licensed with Boost and Apache. This is not a good state of affairs for users and their lawyers. One license for the standard library is expected. 3. The Boost license appears to be the most permissive of all. It's still in version 1, has been for many years, apparently nobody has felt it needs to be changed. 4. The Boost license is used extensively in the C++ community, including for corporate use, meaning it already has passed muster with corporate lawyers. D using the Boost license means it's a no-brainer for them - the license is already approved. 5. Tango is looking at relicensing anyway. I can't identify any reason to choose Apache over Boost, and 1..4 to choose Boost over Apache.
Nov 13 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 15 de noviembre a las 18:27 me escribiste:
 Don wrote:
I think the GNU stuff is a bit different, because the GPL is an
aggressive license -- the FSF intends to defend the license,
taking offenders to court. Legal battles are expected, and having
a single legal entity makes it easier to win the case.
By contrast, the Boost license exists solely for the benefit of
the users, giving them a guarantee that court cases will _not_
occur.
I think that throughout Boost all of the authors retain their
original copyright.

It's true that GPL has an agenda that is not always in its users' best interests. The Boost license does.

It's always in its users best interests, except when the users violates the license :) The GPL is always protecting the user, giving them the 4 basics rights. It doesn't protect intermediaries who want to use a free/libre library and close it up, but it's always in the *end user* best interests. That might be not be always practical in the corporate/business world (you can make business with the GPL too, though, there are plenty of examples), but that's a different issue, and I agree that to have the most wide acceptance, a language stdlib should use something more liberal, making the Boost license a good one. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- More people die from a champagne-cork popping, than from poison spiders
Nov 15 2009
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 15:48:27 -0500, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 14:40:10 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:
 grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would require permission from the author(s) of those packages, as they'd need to be relicensed. (Tango uses the BSD license which seems to require notice

 all binaries compiled with it, this is unacceptable for Phobos.) So

 only Sean and Don have been willing to do this.

License 3.0) allows binary distribution without attribution. See http://www.dsource.org/projects/tango/wiki/License -Steve

Is there a plain English explanation of the Academic Free License anywhere? I read this somewhere on the Tango website before, but I wasn't sure how significant it was, since the Academic Free License is dense, long legalese w/o any plain English explanations.

to put the second note on the above referenced license page ;) See

 It would be truly great if Tango could be used under a license with
 permissiveness
 equivalent to the Boost license.  It would help mend a pretty
 significant rift in
 the D community that started over a minor technicality.

Aside from being an almost insurmountable task to get all the developers to agree to do it, since the AFL allows permissions that are exactly in line with what the Tango devs want, I don't think they have any reason to change it. -Steve

Well this is great news. I read over the AFL text and it seems to basically be just be a more wordy, harder to parse equivalent to the Boost license. So the AFL is not the Boost license, but it is equivalently permissive. In other words they are (I think) compatible. For the convenience of the forum readers, here's the attribution rights block: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work.
Nov 12 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I wouldn't waste any time trying to get Tango to change their license.  
 Aside from being an almost insurmountable task to get all the developers 
 to agree to do it, since the AFL allows permissions that are exactly in 
 line with what the Tango devs want, I don't think they have any reason 
 to change it.

The reason to change it is simply that any user of Phobos/Tango has only one license to understand and agree to. Anything to make it easier for users and their lawyers is a good thing.
Nov 12 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 14:40:10 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would require permission from the author(s) of those packages, as they'd need to be relicensed. (Tango uses the BSD license which seems to require notice on all binaries compiled with it, this is unacceptable for Phobos.) So far, only Sean and Don have been willing to do this.

Tango is dual-licensed. The other license it uses (the Academic Free License 3.0) allows binary distribution without attribution. See http://www.dsource.org/projects/tango/wiki/License -Steve
Nov 12 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 15:48:27 -0500, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 14:40:10 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:
 grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would require permission from the author(s) of those packages, as they'd need to be relicensed. (Tango uses the BSD license which seems to require notice

 all binaries compiled with it, this is unacceptable for Phobos.) So  

 only Sean and Don have been willing to do this.

License 3.0) allows binary distribution without attribution. See http://www.dsource.org/projects/tango/wiki/License -Steve

Is there a plain English explanation of the Academic Free License anywhere? I read this somewhere on the Tango website before, but I wasn't sure how significant it was, since the Academic Free License is dense, long legalese w/o any plain English explanations.

Agreed, it was in fact my mis-interpretation of the AFL that caused Tango to put the second note on the above referenced license page ;) See http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=82496
 It would be truly great if Tango could be used under a license with  
 permissiveness
 equivalent to the Boost license.  It would help mend a pretty  
 significant rift in
 the D community that started over a minor technicality.

I wouldn't waste any time trying to get Tango to change their license. Aside from being an almost insurmountable task to get all the developers to agree to do it, since the AFL allows permissions that are exactly in line with what the Tango devs want, I don't think they have any reason to change it. -Steve
Nov 12 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 2:17 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Jacob Carlborg wrote:
 It's being discussed here:
 http://www.dsource.org/projects/tango/forums/topic/786#3407

Thanks for the pointer. I see the discussion is about adopting the Apache license. I strongly suggest considering the Boost license, as it is very permissive, and Phobos has converted to it. Boost has been battle-tested in the C++ community for years, and I am not aware of any problems or controversies about it. Another nice plus is that C++ users will likely already be familiar with Boost, their company lawyers likely have already approved using Boost licensed code, and so will be comfortable using D libraries identically licensed.

To be fair I think all those things are true of the Apache license too.
 http://www.boost.org/LICENSE_1_0.txt
 http://en.wikipedia.org/wiki/Boost_Software_License

 ===========================================
 Boost Software License - Version 1.0 - August 17th, 2003

 Permission is hereby granted, free of charge, to any person or organization
 obtaining a copy of the software and accompanying documentation covered by
 this license (the "Software") to use, reproduce, display, distribute,
 execute, and transmit the Software, and to prepare derivative works of the
 Software, and to permit third-parties to whom the Software is furnished to
 do so, all subject to the following:

 The copyright notices in the Software and this entire statement, including
 the above license grant, this restriction and the following disclaimer,
 must be included in all copies of the Software, in whole or in part, and
 all derivative works of the Software, unless such copies or derivative
 works are solely in the form of machine-executable object code generated by
 a source language processor.

 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
 SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
 FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
 ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 DEALINGS IN THE SOFTWARE.
 ========================================================

Boost certainly wins on brevity. Brevity FTW! It looks to me like Boost and Apache 2.0 say basically exactly the same thing, just Apache dedicates entire paragraphs to explaining what the meaning of "is" is. --bb
Nov 12 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 12 Nov 2009 17:31:21 -0500, Bill Baxter <wbaxter gmail.com> wrote:

 On Thu, Nov 12, 2009 at 2:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Jacob Carlborg wrote:
 It's being discussed here:
 http://www.dsource.org/projects/tango/forums/topic/786#3407

Thanks for the pointer. I see the discussion is about adopting the Apache license. I strongly suggest considering the Boost license, as it is very permissive, and Phobos has converted to it. Boost has been battle-tested in the C++ community for years, and I am not aware of any problems or controversies about it. Another nice plus is that C++ users will likely already be familiar with Boost, their company lawyers likely have already approved using Boost licensed code, and so will be comfortable using D libraries identically licensed.

To be fair I think all those things are true of the Apache license too.
 http://www.boost.org/LICENSE_1_0.txt
 http://en.wikipedia.org/wiki/Boost_Software_License

 ===========================================
 Boost Software License - Version 1.0 - August 17th, 2003

 Permission is hereby granted, free of charge, to any person or  
 organization
 obtaining a copy of the software and accompanying documentation covered  
 by
 this license (the "Software") to use, reproduce, display, distribute,
 execute, and transmit the Software, and to prepare derivative works of  
 the
 Software, and to permit third-parties to whom the Software is furnished  
 to
 do so, all subject to the following:

 The copyright notices in the Software and this entire statement,  
 including
 the above license grant, this restriction and the following disclaimer,
 must be included in all copies of the Software, in whole or in part, and
 all derivative works of the Software, unless such copies or derivative
 works are solely in the form of machine-executable object code  
 generated by
 a source language processor.

 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS  
 OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO  
 EVENT
 SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE  
 LIABLE
 FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR  
 OTHERWISE,
 ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR  
 OTHER
 DEALINGS IN THE SOFTWARE.
 ========================================================

Boost certainly wins on brevity. Brevity FTW! It looks to me like Boost and Apache 2.0 say basically exactly the same thing, just Apache dedicates entire paragraphs to explaining what the meaning of "is" is. --bb

The Apache 2.0 license requires attribution. It's therefore unsuitable for a standard library. From the website FAQ: " It forbids you to: redistribute any piece of Apache-originated software without proper attribution; use any marks owned by The Apache Software Foundation in any way that might state or imply that the Foundation endorses your distribution; use any marks owned by The Apache Software Foundation in any way that might state or imply that you created the Apache software in question. It requires you to: include a copy of the license in any redistribution you may make that includes Apache software; provide clear attribution to The Apache Software Foundation for any distributions that include Apache software. "
Nov 12 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 12 Nov 2009 16:19:24 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:
 I wouldn't waste any time trying to get Tango to change their license.   
 Aside from being an almost insurmountable task to get all the developers  
 to agree to do it, since the AFL allows permissions that are exactly in  
 line with what the Tango devs want, I don't think they have any reason  
 to change it.

 -Steve

I remember there being some questions regarding AFL 3.0's GPL compatibility.
Nov 12 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 12 Nov 2009 16:39:31 -0500, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 15:48:27 -0500, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 14:40:10 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:
 grauzone wrote:
 Ever heard of Tango?

Yes, and I'd be happy to: 1. have Tango available for D2 and work with Druntime. 2. move individual packages from Tango to Phobos. This would



 permission from the author(s) of those packages, as they'd need to  



 relicensed. (Tango uses the BSD license which seems to require  



 on
 all binaries compiled with it, this is unacceptable for Phobos.) So

 only Sean and Don have been willing to do this.

License 3.0) allows binary distribution without attribution. See http://www.dsource.org/projects/tango/wiki/License -Steve

Is there a plain English explanation of the Academic Free License anywhere? I read this somewhere on the Tango website before, but I wasn't sure how significant it was, since the Academic Free License is dense, long legalese w/o

 plain
 English explanations.

Tango to put the second note on the above referenced license page ;) See

 It would be truly great if Tango could be used under a license with
 permissiveness
 equivalent to the Boost license.  It would help mend a pretty
 significant rift in
 the D community that started over a minor technicality.

Aside from being an almost insurmountable task to get all the developers to agree to do it, since the AFL allows permissions that are exactly in line with what the Tango devs want, I don't think they have any reason to change it. -Steve

Well this is great news. I read over the AFL text and it seems to basically be just be a more wordy, harder to parse equivalent to the Boost license. So the AFL is not the Boost license, but it is equivalently permissive. In other words they are (I think) compatible. For the convenience of the forum readers, here's the attribution rights block: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work.

The AFL does have attribution issues due to clause 1c), which puts rather restrictive conditions on the license the binary copy is distributed under. 1C is also what causes it to be incompatible with other licenses, such as the GPL. Also, the AFL requires (clause 3) every program contain a copy of the AFL licensed source code.
Nov 12 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun <yigal100 gmail.com>  
wrote:

 Robert Jacques wrote:
  The Apache 2.0 license requires attribution. It's therefore unsuitable  
 for a standard library. From the website FAQ:
 "
 It forbids you to:
 redistribute any piece of Apache-originated software without proper  
 attribution;
 use any marks owned by The Apache Software Foundation in any way that  
 might state or imply that the Foundation endorses your distribution;
 use any marks owned by The Apache Software Foundation in any way that  
 might state or imply that you created the Apache software in question.
  It requires you to:
 include a copy of the license in any redistribution you may make that  
 includes Apache software;
 provide clear attribution to The Apache Software Foundation for any  
 distributions that include Apache software.
 "

excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution.

First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW).
Nov 12 2009
prev sibling next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 For anyone looking for an easy, but valuable, contribution to D, take a
 look at the go runtime library.
 
 There's a lot in there we could use in the D library:
 
 http://golang.org/pkg/
 
 The library is licensed under the
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.
 
 Some packages that look particularly useful are:
 
 ebnf 

This one sounded interesting, but it looks like the go lib doesn't really do anything. Are you thinking a parser engine somewhat analogous to a regular expression engine? I really like the idea of having one of those built in to the standard library.
Nov 12 2009
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Nov 12, 2009 at 10:59:38AM -0800, Walter Bright wrote:
 Some packages that look particularly useful are:
 http
 image
 net

I have some code that might be useful for these, that I've accumulated over time. Warning, ugly code: IMAGE RELATED http://arsdnet.net/dcode/png.d This one is a from scratch PNG library. It isn't quite complete, but I'm using it already in my DWS project - the fetchPaletteWin32, getANDMask, and getFlippedUnfilteredDatastream (nice names, I know) functions can take indexed, semi-transparent PNG files and spit out the pieces to make a Windows ico type icon. Also in there are functions to make doing palette swaps easier. It *should* compile as both D1 and D2. I originally wrote it in D2, but had to use it in a D1 project, so I cut out the immutable, etc. to make it work there. Why not use libpng? When I started it, I just wanted to see some of the bytes in the file. Then it grew from there, since I prefer using small code over bigger libraries. http://arsdnet.net/dcode/dimage Another image thing. It is part D and part C. It reads and writes (some) Windows .bmp files, and can display them on both Windows and Linux. auto a = new BMP("image.bmp"); a.display(); // pops up a window showing the bmp Also allows some basic read/write of the bmp's pixels in memory. NETWORK RELATED http://arsdnet.net/dcode/httpdconnection.d This is a module to my network manager* that speaks HTTP as a server - well, enough of it so my browser could view the pages it served anyway. Still needs more work to be complete, but is already good enough to run a website off. In fact, my one of my websites is written /entirely/ in D, and runs on a custom minimal Linux system that takes a total of 18 MB on disk and 8 MB running! Its IP address has been commandeered, but here's the same program running on another server of mine: http://206.125.170.166:81/ * My network manager is here: http://arsdnet.net/dcode/netman.d and it does sending, reading, and connections using the select() call. Problem with it is it is a little ugly and Linux only. Umm where was I.. I forgot. Oh well, one more: MISC http://arsdnet.net/dcode/exec.d This one offers one function: exec(...) which runs a child process, directing its stdio into strings. It is Linux only and kinda sucks - I made it just for some shell script like things a long time ago. I'd like to redo this to work with input and output ranges, and work across platforms, along with some convenience functions to really kill shell scripting, but haven't had the time. ========== I have a buttload of code here, in various messy forms. (The coolest one is a 2D, networked game engine for D1... no website though. And now of course my d windowing system project is moving along. http://arsdnet.net/dws ) But my weekends only have time to do so much about cleaning it up and posting it to the web. -- Adam D. Ruppe http://arsdnet.net
Nov 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:
 I have some code that might be useful for these, that I've accumulated
 over time. 

Sounds like you've got a great start here!
Nov 12 2009
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright wrote:
 For anyone looking for an easy, but valuable, contribution to D, take a 
 look at the go runtime library.
 
 There's a lot in there we could use in the D library:
 
 http://golang.org/pkg/
 
 The library is licensed under the 
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.
 
 Some packages that look particularly useful are:
 
 archive.tar
 compress.flate
 crypto
 debug
 ebnf
 encoding
 gob
 http
 image
 net
 rpc

Go also has a go package that contains: ast doc parser printer scanner token see http://golang.org/pkg/go/
Nov 12 2009
prev sibling next sibling parent reply jcc7 <jccalvarese gmail.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 For anyone looking for an easy, but valuable, contribution to D,
 take a look at the go runtime library.

 There's a lot in there we could use in the D library:

 http://golang.org/pkg/

 The library is licensed under the
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.

I don't want to rain on your parade, but attribution could be an issue. (I'm not sure where the license is for the library, so that text I found may only apply to the compiler.) From http://golang.org/LICENSE: // Copyright (c) 2009 The Go Authors. All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions are // met: // // * Redistributions of source code must retain the above copyright // notice, this list of conditions and the following disclaimer. // * Redistributions in binary form must reproduce the above // copyright notice, this list of conditions and the following disclaimer // in the documentation and/or other materials provided with the // distribution. jcc7
Nov 12 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 2:09 PM, jcc7 <jccalvarese gmail.com> wrote:

 From http://golang.org/LICENSE:

 // Copyright (c) 2009 The Go Authors. All rights reserved.

 // =A0 =A0* Redistributions in binary form must reproduce the above
 // copyright notice, this list of conditions and the following
 disclaimer
 // in the documentation and/or other materials provided with the
 // distribution.

 jcc7

Maybe they'll change it if someone points out to them that it's a lame requirement to have for a standard library. --bb
Nov 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Maybe they'll change it if someone points out to them that it's a lame
 requirement to have for a standard library.

It's a deal breaker for a standard library, but I don't think that is the license used for the library.
Nov 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
jcc7 wrote:
 I don't want to rain on your parade, but attribution could be an
 issue.
 (I'm not sure where the license is for the library, so that text I
 found may only apply to the compiler.)

The library is under the creative commons license, which is different, though I haven't read it carefully.
Nov 12 2009
parent reply Florian Sonnenberger <nairolf online.de> writes:
Walter Bright wrote:

 The library is under the creative commons license, which is different,
 though I haven't read it carefully.

Are you sure? Every file of the lib I've looked at starts with: // Copyright 2009 The Go Authors. All rights reserved. // Use of this source code is governed by a BSD-style // license that can be found in the LICENSE file. Examples: http://golang.org/src/pkg/compress/flate/deflate.go http://golang.org/src/pkg/fmt/format.go http://golang.org/src/pkg/json/parse.go http://golang.org/src/pkg/regexp/regexp.go Florian
Nov 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Florian Sonnenberger wrote:
 Walter Bright wrote:
 
 The library is under the creative commons license, which is different,
 though I haven't read it carefully.

Are you sure? Every file of the lib I've looked at starts with:

I stand corrected. I was looking at the documentation pages.
 
 // Copyright 2009 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
 Examples:
 http://golang.org/src/pkg/compress/flate/deflate.go
 http://golang.org/src/pkg/fmt/format.go
 http://golang.org/src/pkg/json/parse.go
 http://golang.org/src/pkg/regexp/regexp.go
 
 
 Florian

Nov 12 2009
prev sibling next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:
 For anyone looking for an easy, but valuable, contribution to D, take a
 look at the go runtime library.
 
 There's a lot in there we could use in the D library:
 
 http://golang.org/pkg/
 
 The library is licensed under the
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.
 
 Some packages that look particularly useful are:
 
 archive.tar
 compress.flate
 crypto
 debug
 ebnf
 encoding
 gob
 http
 image
 net
 rpc

What phobos is really lacking is a bunch of container classes, ala stl. I've been pondering swiping/porting the container classes from stlport. License looks like the port could be re-licensed as boost. good idea/bad idea? - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK/v3ZT9LetA9XoXwRAuNSAJ9ndpYtQsF5L8VkS7aa0hTi1K8RRQCeJiVh zidBkl5rizaqeOqX7K+FNxQ= =fWea -----END PGP SIGNATURE-----
Nov 14 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sat, Nov 14, 2009 at 10:58 AM, div0 <div0 users.sourceforge.net> wrote:

 What phobos is really lacking is a bunch of container classes, ala stl.
 I've been pondering swiping/porting the container classes from stlport.
 License looks like the port could be re-licensed as boost.

 good idea/bad idea?

STL implementation code is horrifically unreadable. But potentially worse is that the design is, I suspect, thoroughly entrenched in assumptions based on the limitations of C++ templates (contributing to that unreadablility). And they're designed around iterators rather than ranges, which will surely make for some significant differences. I sure wouldn't try to port STLport or any other flavor of STL to D. I kinda think the best way to write a container lib for D would just be to go back to square one: pseudocode in CLR and other algorithms books. Certainly not the quickest way, though. Anyway I thought Steve S. or Dimscha or someone said they were writing a D2 container lib already. No? --bb
Nov 14 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article
 On Sat, Nov 14, 2009 at 10:58 AM, div0 <div0 users.sourceforge.net> wrote:
 What phobos is really lacking is a bunch of container classes, ala stl.
 I've been pondering swiping/porting the container classes from stlport.
 License looks like the port could be re-licensed as boost.

 good idea/bad idea?

worse is that the design is, I suspect, thoroughly entrenched in assumptions based on the limitations of C++ templates (contributing to that unreadablility). And they're designed around iterators rather than ranges, which will surely make for some significant differences. I sure wouldn't try to port STLport or any other flavor of STL to D. I kinda think the best way to write a container lib for D would just be to go back to square one: pseudocode in CLR and other algorithms books. Certainly not the quickest way, though. Anyway I thought Steve S. or Dimscha or someone said they were writing a D2 container lib already. No? --bb

Someone (I think it's Steve) has his dcollections lib. Tango has a bunch of collections. I've written a few collections that are specifically designed for, and somewhat coupled to my TempAlloc allocator. (hash sets, hash tables are there, AVL trees are almost ready) These will be Boost licensed and could easily be adapted to "normal" GC memory management once we figure out what the API should be. I've also written an associative array implementation that's specifically designed with the current GC implementation in mind (RandAA). I think what we really need is to define what paradigm we're using for collections. Here are some questions that really need to be answered before we can start implementing a std.collections: 1. How do we prioritize the following when tradeoffs have to be made: a. Safety b. Flexibility c. Performance d. Simplicity/Ease of use STL, for example, primarily focuses on performance and flexibility at the expense of simplicity and safety. We might not want that tradeoff. 2. Should we use an OO flavor w/ classes and explicit Interface interfaces or a more template-y flavor with structs and compile-time interfaces? 3. Reference or value semantics? 4. What primitives must a collection have by definition? 5. To what extent should collections be designed with the limitations of the current GC in mind? 6. Should we allow custom allocators? I would actually say no, because based on my experience with my TempAlloc collections, if you're using a custom allocator, you probably want to design the implementation with the details of that allocator in mind. Furthermore, it may be hard to make things safe without knowing something about how the memory allocator works. For example, my TempAlloc data structures place deleted nodes on free lists local to the collection, because you can only delete stuff from TempAlloc in LIFO order, so this is the only way the memory could get recycled. They are also not designed with even the slightest consideration for sharing across threads because TempAlloc-allocated memory isn't supposed to be shared across threads. Finally, since TempAlloc itself is inherently a performance hack, they place a premium on performance at the expense of safety and flexibility.
Nov 14 2009
next sibling parent reply BLS <windevguy hotmail.de> writes:
On 14/11/2009 21:09, dsimcha wrote:
 I think what we really need is to define what paradigm we're using for
 collections.  Here are some questions that really need to be answered before we
 can start implementing a std.collections:

I think we should split collections into : std.collections.mutable std.collections.immutable I would prefer classes and interfaces. Instead of using AVL respective RB Trees, why not investigate a bit in Left Leaning RB Trees.. Skip Lists. Having a bunch of common data structures as part of phobos would be nice...
Nov 14 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-14 16:14:02 -0500, BLS <windevguy hotmail.de> said:

 On 14/11/2009 21:09, dsimcha wrote:
 I think what we really need is to define what paradigm we're using for
 collections.  Here are some questions that really need to be answered before we
 can start implementing a std.collections:
 

I think we should split collections into : std.collections.mutable std.collections.immutable

Can't work: immutable is a keyword. :-) And I think having immutable as a type modifier in the language makes it pointless an inelegant to categorize collections into mutable and immutable kinds. You could have fixed-size, or fixed-content collections types though (enabling some optimizations), but don't call these immutable (or mutable) if you want to avoid confusion with the keyword. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 14 2009
parent BLS <windevguy hotmail.de> writes:
On 15/11/2009 01:58, Michel Fortin wrote:
 I think we should split collections into :
 std.collections.mutable
 std.collections.immutable

Can't work: immutable is a keyword. :-)

Ouch.. frankly said : inspired by Scala.. still thinking it would make sense to split.
Nov 15 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Bill Baxter (wbaxter gmail.com)'s article
 On Sat, Nov 14, 2009 at 10:58 AM, div0 <div0 users.sourceforge.net> wrote:
 What phobos is really lacking is a bunch of container classes, ala stl.
 I've been pondering swiping/porting the container classes from stlport.
 License looks like the port could be re-licensed as boost.

 good idea/bad idea?

worse is that the design is, I suspect, thoroughly entrenched in assumptions based on the limitations of C++ templates (contributing to that unreadablility). And they're designed around iterators rather than ranges, which will surely make for some significant differences. I sure wouldn't try to port STLport or any other flavor of STL to D. I kinda think the best way to write a container lib for D would just be to go back to square one: pseudocode in CLR and other algorithms books. Certainly not the quickest way, though. Anyway I thought Steve S. or Dimscha or someone said they were writing a D2 container lib already. No? --bb

Someone (I think it's Steve) has his dcollections lib.

I think http://www.gobosoft.com/eiffel/gobo/structure/ with some ideas from dcollections would be great. I don't think Java's collections form a good design for D.
 Tango has a bunch of
 collections.

Are those following Java's collection design?
 I think what we really need is to define what paradigm we're using for
 collections.  Here are some questions that really need to be answered before we
 can start implementing a std.collections:
 
 1.  How do we prioritize the following when tradeoffs have to be made:
 
     a.  Safety
     b.  Flexibility
     c.  Performance
     d.  Simplicity/Ease of use
 
 STL, for example, primarily focuses on performance and flexibility at the
expense
 of simplicity and safety.  We might not want that tradeoff.

I think policies should decide here. Let the user make the choice and offer a good set of defaults.
 2.  Should we use an OO flavor w/ classes and explicit Interface interfaces or
a
 more template-y flavor with structs and compile-time interfaces?

I'd be leaning more towards classes, but I'm still waiting for a killer argument one way or another.
 3.  Reference or value semantics?

I'm again leaning towards reference semantics.
 4.  What primitives must a collection have by definition?

This is a long discussion. I've exposed briefly a couple of opinions in the past, for example I think Container!T should expose: bool empty(); bool add(T); T popAny(); OnePassIterator!T opSlice(); Perhaps OnePassIterator could be ForwardIterator, but I'm not positive. Better container reflect more detailed primitives. Please advise.
 5.  To what extent should collections be designed with the limitations of the
 current GC in mind?

I don't know. Probably some tradeoffs may be necessary, but I hope not.
 6.  Should we allow custom allocators?  I would actually say no, because based
on
 my experience with my TempAlloc collections, if you're using a custom
allocator,
 you probably want to design the implementation with the details of that
allocator
 in mind.  Furthermore, it may be hard to make things safe without knowing
 something about how the memory allocator works.

Good question. Would love to, but I don't know how to design a good solution. Andrei
Nov 14 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Sat, 14 Nov 2009 22:08:23 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 dsimcha wrote:
 Tango has a bunch of
 collections.

Are those following Java's collection design?

code, not the Java design (which was also based on Doug Lea's design). The newer ones are rewritten from scratch, but in the same feel. dcollections have some Java feel in that they are classes and interfaces, but also add C++ style iterators (cursors).
 I think what we really need is to define what paradigm we're using for
 collections.  Here are some questions that really need to be answered
 before we
 can start implementing a std.collections:
  1.  How do we prioritize the following when tradeoffs have to be made:
      a.  Safety
     b.  Flexibility
     c.  Performance
     d.  Simplicity/Ease of use
  STL, for example, primarily focuses on performance and flexibility at
 the expense
 of simplicity and safety.  We might not want that tradeoff.

I think policies should decide here. Let the user make the choice and offer a good set of defaults.

allow for the user to choose his weapon -- power and speed vs. safe. I think simplicity is a given. For example, it could be a version statement that decides whether ranges of a container do runtime checks for safety.
 2.  Should we use an OO flavor w/ classes and explicit Interface
 interfaces or a
 more template-y flavor with structs and compile-time interfaces?

I'd be leaning more towards classes, but I'm still waiting for a killer argument one way or another.

be a little strenuous. All the builtin D container types are essentially reference types (arrays are not exactly reference types but behave mostly like reference types), I don't see why we should change that. Making them classes allows for interfaces which helps allow runtime decisions for things like copying data between containers that are of different types. See dcollections and how easy it is to copy data from one type to another.
 6.  Should we allow custom allocators?  I would actually say no,
 because based on
 my experience with my TempAlloc collections, if you're using a custom
 allocator,
 you probably want to design the implementation with the details of that
 allocator
 in mind.  Furthermore, it may be hard to make things safe without
 knowing
 something about how the memory allocator works.

Good question. Would love to, but I don't know how to design a good solution.

collection class. Using a custom allocator has brought tremendous speedups, because you go through fewer collection cycles, and waste much less space. I think it's possible to design a custom allocator framework that is hidden completely from the API. dcollections has 2 different allocators -- the default is a custom allocator I wrote to cut down on the GC collection cycles (which I also contributed to Tango and is now their default allocator), and the alternative is an allocator which simply uses the GC to allocate all nodes with 'new'. The code to use such containers does not change if you change the allocator. Tango does have an allocator that ONLY works for pure value types (types that have no pointers in them), and it is even faster than my custom allocator, but it requires you "know what you are doing." I think with the power of D2 we should be able to come up with some template magic that disallows such an allocator from being used with the wrong types. -Steve

After looking at dcollections some more, it looks very well thought out and IMHO is a good starting point for a std.collections, provided a few issues are taken care of: 1. License needs to be Boost, not BSD. You'd need to relicense it under Boost. 2. Needs to be D2-ified, which you mentioned a few posts back that you were going to do anyhow. 3. I don't know how your cursor concept would interact with ranges. You've mentioned that cursors have some capabilities that ranges don't, but they are also more awkward to use. For a std.collections, I think being range-based is a must. Also, have you considered contributing the Hash class to the AA project on dsource and nominating it to replace the current AA implementation?
Nov 14 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 My hash implementation isn't anything special, I basically implemented the
 pseudo code from my algo book.  The only reason it outperforms AA is
 because of the custom allocator.
 -Steve

Yes, but the allocation scheme is the main problem with the current implementation. IMHO memory allocation is one of the trickiest parts of designing an efficient hash table. My RandAA implementation is designed to get around this by simply performing very few allocations. In fact, if you know the approximate size that the table will be before you start creating it, you can simply pre-allocate the whole thing in O(1) allocations, and then never have to allocate while building the table. However, this comes at some cost in terms of lookup performance. If you have an even better solution, it would be great if it's used in the builtin AAs, instead of being buried in std.collections (or worse yet, in a third party lib), which most people won't use use b/c the builtin AAs have nicer syntax and are more discoverable.
Nov 15 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Sun, 15 Nov 2009 01:17:25 -0500, dsimcha <dsimcha yahoo.com> wrote:
 3.  I don't know how your cursor concept would interact with ranges.  
 You've
 mentioned that cursors have some capabilities that ranges don't, but 
 they are also
 more awkward to use.  For a std.collections, I think being range-based 
 is a must.

I agree. I want to try and preserve the functions that cursors provide aside from ranges (namely, referring to a single element). What I'm planning to do is have ranges replace the traversal functions of cursors and change cursors to simply reference types. That is, you can maintain a cursor that points at a given element, but you can't move it to another element in the container without changing it back into a range.

That sounds very good!
 BTW, cursors are just C++ iterators, but the term Iterator is currently 
 defined in Tango as something that you can pass to foreach, so I needed 
 a different name :)
 
 Now, if I could just find the time...

...or the collaborators... :o)
 Also, have you considered contributing the Hash class to the AA 
 project on dsource
 and nominating it to replace the current AA implementation?

My hash implementation isn't anything special, I basically implemented the pseudo code from my algo book. The only reason it outperforms AA is because of the custom allocator.

That's a good practical reason to design in custom allocators from day one then. Andrei
Nov 15 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-15 00:09:43 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 I agree -- it should be possible with the metaprogramming power of D to 
  allow for the user to choose his weapon -- power and speed vs. safe.  
 I  think simplicity is a given.
 
 For example, it could be a version statement that decides whether 
 ranges  of a container do runtime checks for safety.

Interesting, although you'll probably want better granularity than a version statement. If your containers are going to be used with SafeD perhaps you'll want a safe and an unsafe variant of some accessor functions (one with bound checks being called for safe code, the other without).
 I think shoehorning containers that are graph based into value types 
 might  be a little strenuous.  All the builtin D container types are 
 essentially  reference types (arrays are not exactly reference types 
 but behave mostly  like reference types), I don't see why we should 
 change that.
 
 Making them classes allows for interfaces which helps allow runtime  
 decisions for things like copying data between containers that are of  
 different types.  See dcollections and how easy it is to copy data from 
  one type to another.

I'm of the same opinion. That said, I'm wondering if the container classes shouldn't also be made final (unlike dcollections). Being classes would make them easy to pass as interfaces, but them being final would help skip the virtual calls whenever you don't pass them as interfaces. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 15 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-11-15 00:09:43 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:
 
 I agree -- it should be possible with the metaprogramming power of
 D to  allow for the user to choose his weapon -- power and speed
 vs. safe.  I  think simplicity is a given.
 
 For example, it could be a version statement that decides whether 
 ranges  of a container do runtime checks for safety.

Interesting, although you'll probably want better granularity than a version statement. If your containers are going to be used with SafeD perhaps you'll want a safe and an unsafe variant of some accessor functions (one with bound checks being called for safe code, the other without).

Here's the current proposal as distilled from the recent newsgroup comments. I think Michal Minich made a very good point here: ===============================
 I think there are two cases:
 
 User would want max performance from a some library, but he does not 
 care about performance. User should have the right to override 
 intentions of library writer, making his code less safe, to achieve 
 speed. Compiler flag -unsafe (or -unsafe-no-bounds-checking) should
 do this. The user will know that he is *overriding* the original
 safety to lower level.
 
 Also, when a library writer wants his code to appeal and be usable to
  most users, he should mark it  safe or  trusted. But in situation,
 when he knows that safe code would be always bounds-checked (there is
 no -unsafe compiler switch), he may rather mark his code  trusted,
 even if it would be safe, in order to appeal to user that don't want
 slow (bounds-checked) library. If the library writer knows that users
 can override safety (bounds-checking), he would not hesitate to use
  safe where appropriate.
 
 the -unsafe-no-bounds-checking flag is essential for properly working
 of safeness in D.

There were arguments to the same effect, but the above brings an original insight into the psychological and social aspects of the matter. So I think a good solution is: a) Have -release KEEP bounds checking for safe functions, and REMOVE them for the others. We may consider that bounds checking in non- safe functions are done with assert(). b) Define a new flag -no-bounds-checking that allows bounds checking removal even for safe functions.
 I think shoehorning containers that are graph based into value
 types might  be a little strenuous.  All the builtin D container
 types are essentially  reference types (arrays are not exactly
 reference types but behave mostly  like reference types), I don't
 see why we should change that.
 
 Making them classes allows for interfaces which helps allow runtime
  decisions for things like copying data between containers that are
 of different types.  See dcollections and how easy it is to copy
 data from  one type to another.

I'm of the same opinion.

I couldn't find the details on copying. How does dcollections solve it? It's a double dispatch issue.
 That said, I'm wondering if the container 
 classes shouldn't also be made final (unlike dcollections). Being 
 classes would make them easy to pass as interfaces, but them being
 final would help skip the virtual calls whenever you don't pass them
 as interfaces.

Sounds nice. Andrei
Nov 15 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Sun, 15 Nov 2009 11:49:18 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Michel Fortin wrote:
 I think shoehorning containers that are graph based into value
 types might  be a little strenuous.  All the builtin D container
 types are essentially  reference types (arrays are not exactly
 reference types but behave mostly  like reference types), I don't
 see why we should change that.
  Making them classes allows for interfaces which helps allow runtime
  decisions for things like copying data between containers that are
 of different types.  See dcollections and how easy it is to copy
 data from  one type to another.


I couldn't find the details on copying. How does dcollections solve it? It's a double dispatch issue.

I don't see how it's a double dispatch issue... If you want to copy data from one container to another, you simply pass the container to add: container1.add(container2); Because they implement interfaces, there is only one function generated for this (with templated structs, you'd need one implementation per container combination). I do *some* optimization in case container2 is the same type as container1. But for all containers, adding an element is a quick operation and traversing to the next element is a quick operation, so I don't see why you'd need special implementations for certain combinations of containers, necessitating double-dispatch.

Ok, thanks for clarifying. I thought the overhead of traversal is considerable, which would make it advantageous to specialize add on select pairs of containers.
 That said, I'm wondering if the container classes shouldn't also be 
 made final (unlike dcollections). Being classes would make them easy 
 to pass as interfaces, but them being
 final would help skip the virtual calls whenever you don't pass them
 as interfaces.

Sounds nice.

Yes, I intended to do that, but I wasn't sure if it made sense to prevent people from inheriting from the classes, so I went the safer route. My recent experiments have shown me that virtual calls actually aren't all that more expensive anyways than just normal calls...

I see. Now, in this brave new world, inheritance seems to be often shunned in favor of composition, and I see it plausible that a library-offered container fosters composition if you want to provide your own container. Andrei
Nov 15 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 14/11/2009 20:58, Steven Schveighoffer wrote:
 collections will be D2 eventually.  It already supports D1 via Tango or
 Phobos.  I want to make it aware of D2-like features (const, ranges,
 etc), so it's not just a simple port.

 http://www.dsource.org/projects/dcollections

I think is very well done and hope for a D2 port. Just two notes : 1) I think the Collection Interface should contain removeAll()/wipeOut() 2) I prefer ICollection instead of Collection. cause D just uses : instead of implements. You wrote : Able to swap out underlying implementation of a container, or customize implementation. *** ***class TreeMap(K, V, alias ImplTemp=RBTree, This mean that f.i. I am able to replace your RB Tree implemtation for TreeMap with f.i. LL RB Tree. Right ? Guess what I want to ask is : What do I have to keep in mind to give it a try ?
Nov 15 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BLS wrote:
 On 14/11/2009 20:58, Steven Schveighoffer wrote:
 collections will be D2 eventually.  It already supports D1 via Tango or
 Phobos.  I want to make it aware of D2-like features (const, ranges,
 etc), so it's not just a simple port.

 http://www.dsource.org/projects/dcollections

I think is very well done and hope for a D2 port. Just two notes : 1) I think the Collection Interface should contain removeAll()/wipeOut()

Yes; I also forgot to add it to the minimal interface. I suggest we use clear() throughout for all objects (i.e. delete's replacement). Andrei
Nov 15 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 15/11/2009 18:19, Steven Schveighoffer wrote:
 On Sun, 15 Nov 2009 04:18:51 -0500, BLS <windevguy hotmail.de> wrote:

 On 14/11/2009 20:58, Steven Schveighoffer wrote:
 collections will be D2 eventually. It already supports D1 via Tango or
 Phobos. I want to make it aware of D2-like features (const, ranges,
 etc), so it's not just a simple port.

 http://www.dsource.org/projects/dcollections

I think is very well done and hope for a D2 port.

Thanks!

dCollections are really outstanding ... super clean code, flexible allocators, change of the underlying algo. Just a 5* WOW.
 Just two notes :
 1) I think the Collection Interface should contain removeAll()/wipeOut()

Does Collection.clear() not fit the bill? From docs: * Collection!(V) clear (); clear the container of all values

Mea culpa. Sorry , should read the source more carefully.
 2) I prefer ICollection instead of Collection. cause D just uses :
 instead of implements.

It is a good point. I shied away from IXxx for interfaces because of how much loathing I had for MFC's nomenclature, but it would make sense to change it. I also was originally writing dcollections for inclusion into Tango, so I followed the existing naming scheme there.
 You wrote :
 Able to swap out underlying implementation of a container, or
 customize implementation. ***
 ***class TreeMap(K, V, alias ImplTemp=RBTree,

 This mean that f.i. I am able to replace your RB Tree implemtation for
 TreeMap with f.i. LL RB Tree. Right ?

Yes.
 Guess what I want to ask is : What do I have to keep in mind to give
 it a try ?

The comments are outdated, but there is a list of functions your implementation must have. For example see: http://www.dsource.org/projects/dcollections/docs/current/dcollections.TreeMap.html

Thanks, will do.
 The beginning documentation sort of outlines a list of functions
 necessary. But I've changed around things such as e.g. how the compare
 function is passed. It used to be a delegate, now it is an alias passed
 to the implementation template.

 My recommendation is to look at the methods and properties of RBTree
 struct in this file:
 http://www.dsource.org/projects/dcollections/docs/current/dcollections.RBTree.html

Already done :)
 Try to implement those basic methods and properties, and I think it will
 work. I will eventually get around to fixing that documentation to
 reflect the correct requirements. Once I port to D2, however, I can use
 template contracts and hopefully that is more self-documenting.

 If you have trouble, please submit tickets on the dsource web site, I
 will try to fix whatever is wrong. You are the first person I know of
 who wants to test this feature, so I'm interested in how it works out :)

I am afraid I have to 'cause of mistakes.
 Also if you get a good implementation together, and are willing to
 contribute, I can incorporate it into dcollections.

 -Steve

I could imagine (and would like) to contribute a clean Skip List, and LL RB Tree implementation for dcollections. == Now : Sorry for my ignorance ... but Why the heck : struct RBNode(V) instead of : struct RBNode(K, V) Björn
Nov 15 2009
next sibling parent BLS <windevguy hotmail.de> writes:
On 15/11/2009 21:53, BLS wrote:
 ==
 Now : Sorry for my ignorance ... but Why the heck :

 struct RBNode(V)

 instead of :

 struct RBNode(K, V)

Because of : dcollections.TreeMap struct element ; the elements that are passed to the tree. Note that if you define a custom update or compare function, it should take element structs, not K or V. ??
Nov 15 2009
prev sibling parent BLS <windevguy hotmail.de> writes:
On 16/11/2009 00:16, Steven Schveighoffer wrote:
 On Sun, 15 Nov 2009 15:53:08 -0500, BLS <windevguy hotmail.de> wrote:


 ==
 Now : Sorry for my ignorance ... but Why the heck :

 struct RBNode(V)

 instead of :

 struct RBNode(K, V)

It was my way of providing the exact same implementation for TreeMap, TreeSet, and TreeMultiSet (same deal between HashMap and HashSet, and HashMultiSet). TreeSet and TreeMultiSet have no keys, so the basic difference between them is the comparator function for TreeMap (which is passed in by the class to the impl) compares only the keys. So hopefully, if you create a specialized implementation for TreeMap, it can be fed into TreeSet and TreeMultiSet, and you get 3 containers for the price of one :) If you can think of a better way, I would be glad to consider it. -Steve

Ok I see. Becomes also clear : that struct RBNode(V) : INode(V) would make sense.. -Björn
Nov 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 14 Nov 2009 14:30:04 -0500, Bill Baxter <wbaxter gmail.com> wrote:

 On Sat, Nov 14, 2009 at 10:58 AM, div0 <div0 users.sourceforge.net>  
 wrote:

 What phobos is really lacking is a bunch of container classes, ala stl.
 I've been pondering swiping/porting the container classes from stlport.
 License looks like the port could be re-licensed as boost.

 good idea/bad idea?

STL implementation code is horrifically unreadable. But potentially worse is that the design is, I suspect, thoroughly entrenched in assumptions based on the limitations of C++ templates (contributing to that unreadablility). And they're designed around iterators rather than ranges, which will surely make for some significant differences. I sure wouldn't try to port STLport or any other flavor of STL to D. I kinda think the best way to write a container lib for D would just be to go back to square one: pseudocode in CLR and other algorithms books. Certainly not the quickest way, though. Anyway I thought Steve S. or Dimscha or someone said they were writing a D2 container lib already. No?

dcollections will be D2 eventually. It already supports D1 via Tango or Phobos. I want to make it aware of D2-like features (const, ranges, etc), so it's not just a simple port. http://www.dsource.org/projects/dcollections -Steve
Nov 14 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
div0 wrote:
 What phobos is really lacking is a bunch of container classes, ala stl.
 I've been pondering swiping/porting the container classes from stlport.
 License looks like the port could be re-licensed as boost.
 good idea/bad idea?

It's a great idea, and Andrei is hard at work doing that!
Nov 14 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 14 Nov 2009 22:08:23 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 dsimcha wrote:
 Tango has a bunch of
 collections.

Are those following Java's collection design?

The original collections in Tango were ported from Doug Lea's original code, not the Java design (which was also based on Doug Lea's design). The newer ones are rewritten from scratch, but in the same feel. dcollections have some Java feel in that they are classes and interfaces, but also add C++ style iterators (cursors).
 I think what we really need is to define what paradigm we're using for
 collections.  Here are some questions that really need to be answered  
 before we
 can start implementing a std.collections:
  1.  How do we prioritize the following when tradeoffs have to be made:
      a.  Safety
     b.  Flexibility
     c.  Performance
     d.  Simplicity/Ease of use
  STL, for example, primarily focuses on performance and flexibility at  
 the expense
 of simplicity and safety.  We might not want that tradeoff.

I think policies should decide here. Let the user make the choice and offer a good set of defaults.

I agree -- it should be possible with the metaprogramming power of D to allow for the user to choose his weapon -- power and speed vs. safe. I think simplicity is a given. For example, it could be a version statement that decides whether ranges of a container do runtime checks for safety.
 2.  Should we use an OO flavor w/ classes and explicit Interface  
 interfaces or a
 more template-y flavor with structs and compile-time interfaces?

I'd be leaning more towards classes, but I'm still waiting for a killer argument one way or another.

I think shoehorning containers that are graph based into value types might be a little strenuous. All the builtin D container types are essentially reference types (arrays are not exactly reference types but behave mostly like reference types), I don't see why we should change that. Making them classes allows for interfaces which helps allow runtime decisions for things like copying data between containers that are of different types. See dcollections and how easy it is to copy data from one type to another.
 6.  Should we allow custom allocators?  I would actually say no,
 because based on
 my experience with my TempAlloc collections, if you're using a custom  
 allocator,
 you probably want to design the implementation with the details of that  
 allocator
 in mind.  Furthermore, it may be hard to make things safe without  
 knowing
 something about how the memory allocator works.

Good question. Would love to, but I don't know how to design a good solution.

In dcollections, the custom allocator is a template argument for the collection class. Using a custom allocator has brought tremendous speedups, because you go through fewer collection cycles, and waste much less space. I think it's possible to design a custom allocator framework that is hidden completely from the API. dcollections has 2 different allocators -- the default is a custom allocator I wrote to cut down on the GC collection cycles (which I also contributed to Tango and is now their default allocator), and the alternative is an allocator which simply uses the GC to allocate all nodes with 'new'. The code to use such containers does not change if you change the allocator. Tango does have an allocator that ONLY works for pure value types (types that have no pointers in them), and it is even faster than my custom allocator, but it requires you "know what you are doing." I think with the power of D2 we should be able to come up with some template magic that disallows such an allocator from being used with the wrong types. -Steve
Nov 14 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 15 Nov 2009 04:18:51 -0500, BLS <windevguy hotmail.de> wrote:

 On 14/11/2009 20:58, Steven Schveighoffer wrote:
 collections will be D2 eventually.  It already supports D1 via Tango or
 Phobos.  I want to make it aware of D2-like features (const, ranges,
 etc), so it's not just a simple port.

 http://www.dsource.org/projects/dcollections

I think is very well done and hope for a D2 port.

Thanks!
 Just two notes :
 1) I think the Collection Interface should contain  removeAll()/wipeOut()

Does Collection.clear() not fit the bill? From docs: * Collection!(V) clear (); clear the container of all values
 2) I prefer ICollection instead of Collection. cause D just uses :  
 instead of implements.

It is a good point. I shied away from IXxx for interfaces because of how much loathing I had for MFC's nomenclature, but it would make sense to change it. I also was originally writing dcollections for inclusion into Tango, so I followed the existing naming scheme there.
 You wrote :
 Able to swap out underlying implementation of a container, or customize  
 implementation. ***
 ***class TreeMap(K, V,        alias ImplTemp=RBTree,

 This mean that f.i. I am able to replace your RB Tree implemtation for  
 TreeMap with f.i. LL RB Tree. Right ?

Yes.
  Guess what I want to ask is : What do I have to keep in mind to give it  
 a try ?

The comments are outdated, but there is a list of functions your implementation must have. For example see: http://www.dsource.org/projects/dcollections/docs/current/dcollections.TreeMap.html The beginning documentation sort of outlines a list of functions necessary. But I've changed around things such as e.g. how the compare function is passed. It used to be a delegate, now it is an alias passed to the implementation template. My recommendation is to look at the methods and properties of RBTree struct in this file: http://www.dsource.org/projects/dcollections/docs/current/dcollections.RBTree.html Try to implement those basic methods and properties, and I think it will work. I will eventually get around to fixing that documentation to reflect the correct requirements. Once I port to D2, however, I can use template contracts and hopefully that is more self-documenting. If you have trouble, please submit tickets on the dsource web site, I will try to fix whatever is wrong. You are the first person I know of who wants to test this feature, so I'm interested in how it works out :) Also if you get a good implementation together, and are willing to contribute, I can incorporate it into dcollections. -Steve
Nov 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 15 Nov 2009 11:49:18 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
 I think shoehorning containers that are graph based into value
 types might  be a little strenuous.  All the builtin D container
 types are essentially  reference types (arrays are not exactly
 reference types but behave mostly  like reference types), I don't
 see why we should change that.
  Making them classes allows for interfaces which helps allow runtime
  decisions for things like copying data between containers that are
 of different types.  See dcollections and how easy it is to copy
 data from  one type to another.


I couldn't find the details on copying. How does dcollections solve it? It's a double dispatch issue.

I don't see how it's a double dispatch issue... If you want to copy data from one container to another, you simply pass the container to add: container1.add(container2); Because they implement interfaces, there is only one function generated for this (with templated structs, you'd need one implementation per container combination). I do *some* optimization in case container2 is the same type as container1. But for all containers, adding an element is a quick operation and traversing to the next element is a quick operation, so I don't see why you'd need special implementations for certain combinations of containers, necessitating double-dispatch.
 That said, I'm wondering if the container classes shouldn't also be  
 made final (unlike dcollections). Being classes would make them easy to  
 pass as interfaces, but them being
 final would help skip the virtual calls whenever you don't pass them
 as interfaces.

Sounds nice.

Yes, I intended to do that, but I wasn't sure if it made sense to prevent people from inheriting from the classes, so I went the safer route. My recent experiments have shown me that virtual calls actually aren't all that more expensive anyways than just normal calls... -Steve
Nov 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 15 Nov 2009 01:17:25 -0500, dsimcha <dsimcha yahoo.com> wrote:

 After looking at dcollections some more, it looks very well thought out  
 and IMHO
 is a good starting point for a std.collections, provided a few issues  
 are taken
 care of:

 1.  License needs to be Boost, not BSD.  You'd need to relicense it  
 under Boost.

Yes, I need to do that...
 2.  Needs to be D2-ified, which you mentioned a few posts back that you  
 were going
 to do anyhow.

Yes.
 3.  I don't know how your cursor concept would interact with ranges.   
 You've
 mentioned that cursors have some capabilities that ranges don't, but  
 they are also
 more awkward to use.  For a std.collections, I think being range-based  
 is a must.

I agree. I want to try and preserve the functions that cursors provide aside from ranges (namely, referring to a single element). What I'm planning to do is have ranges replace the traversal functions of cursors and change cursors to simply reference types. That is, you can maintain a cursor that points at a given element, but you can't move it to another element in the container without changing it back into a range. BTW, cursors are just C++ iterators, but the term Iterator is currently defined in Tango as something that you can pass to foreach, so I needed a different name :) Now, if I could just find the time...
 Also, have you considered contributing the Hash class to the AA project  
 on dsource
 and nominating it to replace the current AA implementation?

My hash implementation isn't anything special, I basically implemented the pseudo code from my algo book. The only reason it outperforms AA is because of the custom allocator. -Steve
Nov 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 15 Nov 2009 12:48:34 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Ok, thanks for clarifying. I thought the overhead of traversal is  
 considerable, which would make it advantageous to specialize add on  
 select pairs of containers.

In all cases, traversing all elements of a container is an O(n) operation. For a binary tree, traversing a *single* element can be up to O(lgn), but it amortizes out to O(n) over the whole container, because you traverse every edge exactly twice, and there are at most 2 edges per node. So it works out to be about O(4n). -Steve
Nov 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 15 Nov 2009 15:53:08 -0500, BLS <windevguy hotmail.de> wrote:


 ==
 Now : Sorry for my ignorance ... but Why the heck :

 struct RBNode(V)

 instead of :

 struct RBNode(K, V)

It was my way of providing the exact same implementation for TreeMap, TreeSet, and TreeMultiSet (same deal between HashMap and HashSet, and HashMultiSet). TreeSet and TreeMultiSet have no keys, so the basic difference between them is the comparator function for TreeMap (which is passed in by the class to the impl) compares only the keys. So hopefully, if you create a specialized implementation for TreeMap, it can be fed into TreeSet and TreeMultiSet, and you get 3 containers for the price of one :) If you can think of a better way, I would be glad to consider it. -Steve
Nov 15 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 02:16:09 +0300, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Sun, 15 Nov 2009 15:53:08 -0500, BLS <windevguy hotmail.de> wrote:


 ==
 Now : Sorry for my ignorance ... but Why the heck :

 struct RBNode(V)

 instead of :

 struct RBNode(K, V)

It was my way of providing the exact same implementation for TreeMap, TreeSet, and TreeMultiSet (same deal between HashMap and HashSet, and HashMultiSet). TreeSet and TreeMultiSet have no keys,

I'd say it has no values but keys.
 so the basic difference between them is the comparator function for  
 TreeMap (which is passed in by the class to the impl) compares only the  
 keys.

That's the key! Maybe I'm missing something, but when do you need to compare values?
 So hopefully, if you create a specialized implementation for TreeMap, it  
 can be fed into TreeSet and TreeMultiSet, and you get 3 containers for  
 the price of one :)

 If you can think of a better way, I would be glad to consider it.

Nov 15 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 02:07:47 -0500, Denis Koroskin <2korden gmail.com>  
wrote:

 On Mon, 16 Nov 2009 02:16:09 +0300, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Sun, 15 Nov 2009 15:53:08 -0500, BLS <windevguy hotmail.de> wrote:


 ==
 Now : Sorry for my ignorance ... but Why the heck :

 struct RBNode(V)

 instead of :

 struct RBNode(K, V)

It was my way of providing the exact same implementation for TreeMap, TreeSet, and TreeMultiSet (same deal between HashMap and HashSet, and HashMultiSet). TreeSet and TreeMultiSet have no keys,

I'd say it has no values but keys.

You could look at it that way, but I think it would be just as awkward to declare RBNode(K, V) using RBNode!(V, void) and do some weird static-if stuff for sets.
 so the basic difference between them is the comparator function for  
 TreeMap (which is passed in by the class to the impl) compares only the  
 keys.

That's the key! Maybe I'm missing something, but when do you need to compare values?

In TreeSet. There are no keys, only values. Or you could say, the keys are the values. From the point of view of RBNode, it doesn't care, it just uses the comparator function given to it. -Steve
Nov 16 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 12/11/2009 19:59, Walter Bright wrote:
 For anyone looking for an easy, but valuable, contribution to D, take a
 look at the go runtime library.

 There's a lot in there we could use in the D library:

 http://golang.org/pkg/

 The library is licensed under the
 http://creativecommons.org/licenses/by/3.0/
 meaning we can adapt it to D.

 Some packages that look particularly useful are:

 archive.tar
 compress.flate
 crypto
 debug
 ebnf
 encoding
 gob
 http
 image
 net
 rpc

erm. may I ask why std.json (generously offered) did not make it into phobos ? Seems to be a bit too difficult to contribute. No ?
Nov 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BLS wrote:
 erm.
 may I ask why std.json (generously offered) did not make it into phobos 
 ? Seems to be a bit too difficult to contribute. No ?

No reason other than being overwhelmed with work.
Nov 19 2009