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
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 "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
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.


 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


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:
Nov 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 It's being discussed here: 



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 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:



 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
parent reply "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:



 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
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
parent reply "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
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 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 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 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 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 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 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
next sibling 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 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 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 reply "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  


 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


 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
next sibling parent reply 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


 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


 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


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
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  






 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


 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


 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 next 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 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 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 Kyle <k-foley onu.edu> writes:
Walter Bright Wrote:


 For anyone looking for an easy, but valuable, contribution to D, take a 
 look at the go runtime library.

 ...


Should we submit these kinds of things through bugzilla?  What  is the
preferred method?
Nov 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Kyle wrote:

 Walter Bright Wrote:
 

 For anyone looking for an easy, but valuable, contribution to D, take a 
 look at the go runtime library.

 ...


 
 Should we submit these kinds of things through bugzilla?  What  is the
preferred method?
 


That's a good question. Probably Bugzilla is the best venue for now.
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 "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
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 "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
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 reply "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
next 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 parent reply "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
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 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?


 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


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?


 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


 
 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
parent reply "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
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?


 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


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
parent reply "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
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 reply "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'm of the same opinion.


 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
parent reply 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'm of the same opinion.


 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
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 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 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