[boost] Re: Draft of new Boost Software License
Dave, > Nothing is legally bullet-proof. People should not have illusions > about that. I know, law is not an "exact science" and all that. What I meant is that boosters should stand a *very low* chance of ever having legal problems as a result of their (maybe flawed) work on the boost distribution. And there should be an equally low chance of someone legally rereleasing boost work under his name without mentioning the original authtors. Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compose_f_gxy_hxy
On Thu, 26 Jun 2003 01:08:24 +0200, Daniel Frey wrote: > To complete the implementation of combined_argument_type, it would help After waking up this morning, I immediately realized that the implementation will not do what it promised. I have a better implementation right now which is about 80% finished. Before spamming the group with more and more versions, I'd just like to hear whether there is any interest in a compose_f_gxy_hxy. And sorry again for the lousy first implementation :) Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Current CVS Snapshot or...?
Drazen DOTLIC wrote: > Hi, Hi Drazen, > My company is using boost and we would very much like to use variant > library immediately and not wait for the next official release of > boost. Now, we know that this might not be sensible, but we are ready > to take the risk. At the same time, we don't want to break anything > else in the boost (and by chain reaction in our code). It seems that > variant lib is dependent on (branch of?) mpl, The version of the Variant library in the CVS' main trunk depends (naturally) only on the main trunk components - MPL not being an exception. The question is which parts of the main trunk you need/can get without breaking things. > so what I would like to > know is: what is the most sane branch/snapshot we should take from the > cvs to get reasonably stable boost (overall) with variant in whatever > state it is ATM? As far as MPL goes, I would say you can safely update it from the main trunk - that is, if you are currently using 1.30.0 release. To determine the status of other Variant dependencies you can use our experimental status reports which employ automatically collected 1.30.0-snapshot's failures to highlight the differences between now and then: http://boost.sourceforge.net/regression-logs/user_summary_page.html Basically, 'unexp.' there signals a new failure (or a new library/test case). Of course, you would have to use your own judgment to determine how critical are those to you. HTH, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
[2003-06-25] David Abrahams wrote: >Rene Rivera <[EMAIL PROTECTED]> writes: > >> >> Permission is hereby granted, free of charge, to any person or organization >> obtaining a copy of the software covered by this license (the "Software") >> to: use, reproduce, display, distribute, execute, transmit, > >This part of the list lacks a subject "The Software". > >> prepare derivative works of the Software, > >Which you want to avoid confusing with this. Then perhaps two separate sentences would make that distinction clear. >This part of the license has been fairly carefully worked out. It's >good to make things read more easily, but they must retain their >unambiguous meaning.** I see that all of it was carefully crafted (not being sarcastic, just in case). I was just trying to portray what I understood. Which, since it is different than what the Lawyers meant is a problem IMO. >> and to permit third-parties to whom the Software is furnished to do >> so, > >I prefer "and to permit others to do so". This phrase has just been >approved by the lawyers as legally equivalent, and it's much easier to >read, so I hope we'll use it. Shorter is good :-) >> all subject to the following: > > > >> The copyright notice in the Software and this entire statement, including >> the above license grant, this restriction, and the following disclaimer, >> must be included, in whole or in part, in all copies of the >> Software, and > >That makes it sounds like it's OK to include just part of the >copyright, license, etc. Once again my remarks (**) apply here. Yes I saw, and I thought my later reply pointed that out. But perhaps it also didn't :-\ I'll say it again more directly... It's good work from the Lawyers. Being easily understood and still legally accurate are very hard things to reconcile. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
At 03:25 PM 6/25/2003, Rene Rivera wrote: >... >>* Boosters for whom English isn't their primary language; is the license >>understandable? > >Spanish is my first, but English is a very close second. The impression I >got is that it's somewhat hard to parse as it is. I had to read the second >"paragraph" a few times before I managed to parse out the different parts >of it. > >The main difficulty in the first part (the first two "paragraphs") is the >the lists in it are inconsistent and hard to see which are the items. For >example, the switching from simple items to adding "and" in some of them >threw me. I was expecting the list to end, but it did not. The second >paragraph is long; and without any separators other than the commas it's >hard to read. > >Here's an edited version which might be better for non-english readers to >understand: > >... I think the approach to take is to forward the concern to the lawyers, and let them see if they can say what they want to say with more, but shorter, sentences. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 09:39 PM 6/25/2003, David Abrahams wrote: >... > >> and to permit third-parties to whom the Software is furnished to do >> so, > >I prefer "and to permit others to do so". This phrase has just been >approved by the lawyers as legally equivalent, and it's much easier to >read, so I hope we'll use it. It seems like an improvement to me, too. I'll re-read the relevant emails tomorrow morning when I'm more alert, and then make the change unless some problem surfaces. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 01:50 PM 6/25/2003, Alexander Terekhov wrote: > >Beman Dawes wrote: >[...] >> * Boosters (or their lawyers) from countries other than the US; do they >> spot any issues missed by Boost's US-centric legal team? > >They seem to have missed a whole bunch of issues "surrounding" implied >patent license. 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. ^^ If I understand correctly, "TITLE AND NON-INFRINGEMENT" are basically legal code-words which covers a vast range of issues such as ownership, patents, trade secrets, etc. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Draft of new Boost Software License
At 06:22 PM 6/25/2003, Joel de Guzman wrote: >Andreas Huber <[EMAIL PROTECTED]> wrote: > >|| What about html files? Are they considered to be under >|| the "the Software" umbrella? Html or any other form of >|| electronic documentation can be seen as software but you >|| could just as well argue that it's only data (which >|| AFAICT would not fall under the license then). > >Software can be purely data, right? The documentation >IMO, should be part of "the Software". It is all part of "the Software" if I understand correctly, but I've also already added the concern to the issues list for the lawyers. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
At 03:43 PM 6/25/2003, Maciej Sobczak wrote: >Well, I have a question. >I understand that the text of this license is primarily intended to be >used by Boost libraries and those that are candidates to be included in >Boost. >However, apart from the main Boost effort, some of the Boosters or just >Boost lurkers may find the text of the license very good for their own >work, which is not connected to the Boost itself. > >Long version: >Let's imagine the following situation (it can apply to any developer on >this planet): I write some code and want it to get public. It is outside >of mainstream Boost interest, so I do not intend to submit it to Boost. >Being concerned with the legal issues, I want to have a license text >that is proven to be OK from the lawyers' viewpoint. Of course, a lot of >people (Boosters and lawyers) have spent their time preparing and >reviewing the Boost license and ensuring that it meets the high >standards of today's open software. Is it OK if I just copy-n-paste the >Boost license into my own work? Is it OK if I use only part of it? >This can have many implications, including legal precedents - for >example, when some of my users abuse the license or just asks me what he >can do with the software, I can just point him to Boost pages, FAQs, >etc. In other words, I may hide behind the curtains sewed by people who >just never took me and my work into account. Is it OK if I do it? > >Short version: >Is there any copyright on the Boost license text? >What license protects the Boost license? :) I think part of the answer is that by submitting the Boost Software License to the OSI, if accepted, it will become available to anyone who wants to use it. But I'm passing some of the above on to the lawyers to get their take on the questions. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
At 03:17 PM 6/25/2003, Ronald Garcia wrote: >... > >In reading the license, I think the definition of "Software" needs to be >broadened to explicitly include the documentation, test suites, etc. >see: >http://www.opensource.org/licenses/mit-license.php for an example. I'll pass that on to the lawyers. I'm making a list of issues to ask them about. > Additionally, the BSD license goes into even more detail >with respect to software, binaries, etc. > >I feel that it's good to have a human-readable license, but it >seems more pressing to ensure proper coverage of the legal issues, even >if it means that the license gets a little longer. In this specific >case where the license will (hopefully) cover much of Boost, I >presume that it will be placed in the distribution and all files covered >mentioned by reference. In that case, it seems fine to me for the >license to be longer and more explicit. One of the worries the lawyers express over longer licenses is that more verbiage offers an opposing lawyer more opportunity to find a loophole. Notice that the new license is sometimes referred to as the "short-form" license. There was another proposed license first, which was longer. In the end, the senior lawyers preferred the shorter license. There was also explicit discussion (and a write-up) on some of the other common licenses, such as BSD. It would have been a lot easier for these legal folks to just say "use the BSD" license. The reason they went to considerable trouble to research and then write a specific Boost license is that they believe it will do a better job for Boost than other OSI licenses. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
"Andreas Huber" <[EMAIL PROTECTED]> writes: > Beman, > > Thanks for your work on this. Looks good to me. One minor thing: > >> No change from the current status. If your project does not >> redistribute Boost source code, you don't have to redistribute the >> license, regardless of how much non-Boost source code is >> redistributed. >> >> Hope that helps, > > What about html files? Are they considered to be under the "the > Software" umbrella? Html or any other form of electronic > documentation can be seen as software but you could just as well > argue that it's only data (which AFAICT would not fall under the > license then). > > BTW, I (German mother-tongue) agree with Rene that the long > sentences are a bit difficult to grasp. However, I don't care that > much as long as it's legally bullet-proof. Nothing is legally bullet-proof. People should not have illusions about that. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Maciej Sobczak <[EMAIL PROTECTED]> writes: > Let's imagine the following situation (it can apply to any developer > on this planet): I write some code and want it to get public. It is > outside of mainstream Boost interest, so I do not intend to submit it > to Boost. > > Being concerned with the legal issues, I want to have a license text > that is proven to be OK from the lawyers' viewpoint. That's a very fuzzy notion. This license is only "proven to be OK" relative to certain goals and notions of acceptable risk. Those parameters may not apply to you. > Of course, a lot of people (Boosters and lawyers) have spent their > time preparing and reviewing the Boost license and ensuring that it > meets the high standards of today's open software. Is it OK if I > just copy-n-paste the Boost license into my own work? Is it OK if I > use only part of it? This can have many implications, including > legal precedents - for example, when some of my users abuse the > license or just asks me what he can do with the software, I can just > point him to Boost pages, FAQs, etc. In other words, I may hide > behind the curtains sewed by people who just never took me and my > work into account. Is it OK if I do it? > Short version: > Is there any copyright on the Boost license text? > What license protects the Boost license? :) Ugh, meta-licensing. I'm not sure about this. I've Bcc'd the lawyers to see what they say about this. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
At 06:31 PM 6/25/2003, Matt Hurd wrote: >>The author of a derivative work can put in a more restrictive license >>right? In this case, wording that gives the full Boost permission must >>still be included according to the draft license. >>This would lead to a license text like: > > >I am a little confused. Like Jaarko, I read it as viral. > >If you produced a derivative work, or copy paste a little code, then you >are bound to include the boost license which makes your source open as >well... No, including the Boost license doesn't make your source open. There is nothing in either the new or old Boost licenses which requires that source code be redistributed or otherwise made available. >Seems akin to LGPL. > >Is this the intention or have I misread it? When you cut-and-paste a bit of copyrighted code into your own code, you've created a derived work of the copyrighted code. That's the way copyright law works, even if your code is really large and the cut-and-paste copyright code is fairly trivial. (Under some circumstances copying a small portion can be considered "fair use", but that is starting to drift off-topic.) The Boost licenses have always said something like "... provided this copyright notice appears in all copies." The word "copies" is used in the copyright sense, and so always included any partial copies which aren't "fair-use". So the only change is that the new license makes it much clearer that it applies not only to whole copies but also partial copies, and also makes it much clearer that the copyright and license reproduction requirements don't apply to machine-executable object code. There is no new or old requirement that derived works' source code be open. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Rene Rivera <[EMAIL PROTECTED]> writes: > [2003-06-25] Beman Dawes wrote: > >>For more background, including rationale, a FAQ, and acknowledgements, see >>http://boost.sourceforge.net/misc/license-background.html > > Nice. > >>* Boosters for whom English isn't their primary language; is the license >>understandable? > > Spanish is my first, but English is a very close second. The > impression I got is that it's somewhat hard to parse as it is. I had > to read the second "paragraph" a few times before I managed to parse > out the different parts of it. > > The main difficulty in the first part (the first two "paragraphs") > is the the lists in it are inconsistent and hard to see which are > the items. For example, the switching from simple items to adding > "and" in some of them threw me. I was expecting the list to end, but > it did not. The second paragraph is long; and without any separators > other than the commas it's hard to read. > > Here's an edited version which might be better for non-english > readers to understand: > > > Permission is hereby granted, free of charge, to any person or organization > obtaining a copy of the software covered by this license (the "Software") > to: use, reproduce, display, distribute, execute, transmit, This part of the list lacks a subject "The Software". > prepare derivative works of the Software, Which you want to avoid confusing with this. This part of the license has been fairly carefully worked out. It's good to make things read more easily, but they must retain their unambiguous meaning.** > and to permit third-parties to whom the Software is furnished to do > so, I prefer "and to permit others to do so". This phrase has just been approved by the lawyers as legally equivalent, and it's much easier to read, so I hope we'll use it. > all subject to the following: > The copyright notice in the Software and this entire statement, including > the above license grant, this restriction, and the following disclaimer, > must be included, in whole or in part, in all copies of the > Software, and That makes it sounds like it's OK to include just part of the copyright, license, etc. Once again my remarks (**) apply here. > 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML API for C++, second round
Glen Knowles wrote: _ptr has a very specific meaning in CORBA as well, you must explicitly manage the deletion of the object yourself, like, well... a pointer. If you must use the CORBA namings this, at my first look, seems closer to _var then _ptr. At which point I also think _ref is a better choice. well, right, I was thinking of the relationship between _ptr (proxy) and servant, not of the _ptr <-> proxy relationship. I don't think _ptr means that the object in question is a pointer to a proxy (and the _ptr <-> _var distinction really is about the proxy management), but pointer-to-the-servant. In that sense there is no semantic difference between _ptr and _var. Anyways, I don't really have any preference, so if everybody here would be more comfortable with _ref I can certainly switch. I just don't want to go back and forth all day :-) Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] API Review request: XML API for C++, second round
Title: RE: [boost] API Review request: XML API for C++, second round From: Stefan Seefeld [mailto:[EMAIL PROTECTED]] >>Daryle Walker wrote: >> On Tuesday, June 24, 2003, at 8:12 PM, Stefan Seefeld wrote: >> >> [SNIP] >> >>> As the wrapper objects have reference semantics, I append '_ptr' to >>> their name to stress that fact. A practical side-effect of this is >> >> [TRUNCATE] >> >> Shouldn't the type names use a suffix of "_ref" instead? (I don't need >> to know that they're [possibly] implemented as pointers.) > >it seems 'pointer' has for you a very precise (C/C++) meaning. >I just used _ptr the same way it is used in CORBA (i.e. the C++ >mapping), where it doesn't imply anything about the implementation. > >I believe _ptr and _ref are fairly equivalent. _ptr has a very specific meaning in CORBA as well, you must explicitly manage the deletion of the object yourself, like, well... a pointer. If you must use the CORBA namings this, at my first look, seems closer to _var then _ptr. At which point I also think _ref is a better choice. Glen
Re: [boost] API Review request: XML API for C++, second round
Daryle Walker wrote: On Tuesday, June 24, 2003, at 8:12 PM, Stefan Seefeld wrote: [SNIP] As the wrapper objects have reference semantics, I append '_ptr' to their name to stress that fact. A practical side-effect of this is [TRUNCATE] Shouldn't the type names use a suffix of "_ref" instead? (I don't need to know that they're [possibly] implemented as pointers.) it seems 'pointer' has for you a very precise (C/C++) meaning. I just used _ptr the same way it is used in CORBA (i.e. the C++ mapping), where it doesn't imply anything about the implementation. I believe _ptr and _ref are fairly equivalent. Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML API for C++, second round
On Tuesday, June 24, 2003, at 8:12 PM, Stefan Seefeld wrote: [SNIP] As the wrapper objects have reference semantics, I append '_ptr' to their name to stress that fact. A practical side-effect of this is [TRUNCATE] Shouldn't the type names use a suffix of "_ref" instead? (I don't need to know that they're [possibly] implemented as pointers.) Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] date_time, lexical_cast and MSVC 7.0
On Wed, 25 Jun 2003 18:38:46 -0400, Beman Dawes wrote > At 09:02 AM 6/24/2003, Jeff Garland wrote: > > >... I wonder if we should consider releasing 1.30.1 ... > > The Variant Library has been added, so it would be 1.31.0. And, yes, > I think we should start talking about a schedule. I was thinking of just a patch release to fix the one lexical_cast file, but a full release would work too. Have we ever been done a small patch release to fix a couple critical bugs? I know we've discussed it, but I don't ever remember one... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] compose_f_gxy_hxy
Inspired by an article at the CUJ from Andrei Alexandrescu, I was
finally able to come up with a compose_f_gxy_hxy-adapter. I think that
it's the missing adapter to make compose.hpp complete. In the companies
production code, I needed it and used a much easier implementation with
some limitations, so it's not just a toy example.
The code attached is a first cut, tested on Intel C++ 7.1 and GCC 3.3.
The GCC 2.95.3 has problems with it I haven't solved yet (and I don't
know if it's possible at all). Anyway, I'd like to hear some comments
whether it's a good idea and should be pushed forward or if it better be
buried :)
I attached a modified compose.hpp and a new file for the same directory
where I put the type selection code, called combined_argument_type.hpp.
It needs some boostification and you need to read Andrei's article to
understand it. Really. :) Andrei's article can be found here:
http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm
As I put the implementation into a separate file, it should now also be
easy for boost to provide min/max (probably in utility.hpp?) like
suggested by Andrei if requested - although I'm not totally convinced
it's a good idea as IMHO min/max should have value semantics (the
currently have AFAICS) and not reference-semantics, but that's another
story.
To complete the implementation of combined_argument_type, it would help
if mpl::vector would have 16 instead of 10 arguments, but that can be
done later if there is interest in compose_f_gxy_hxy. I currently simply
removed the first types of the type-list, I've just been lazy, so don't
wonder how this should work. It won't. :)
Comments?
Regards, Daniel
// Add some nice header here... :)
#ifndef BOOST_COMBINED_ARGUMENT_TYPE_HPP
#define BOOST_COMBINED_ARGUMENT_TYPE_HPP
#include
#include
#include
#include
#include
#include
namespace boost {
template< typename L, typename R > struct combined_argument_type
{
private:
typedef mpl::vector<
const bool,
const char,
const signed char,
const unsigned char,
const wchar_t,
const short,
const unsigned short > cutted_types; // GRRR, vector should allow 16 elements!
typedef mpl::vector<
const int,
const unsigned int,
const long,
const unsigned long,
const long long,
const unsigned long long,
const float,
const double,
const long double > sorted_types;
typedef typename remove_const< L >::type non_const_L;
typedef typename remove_const< R >::type non_const_R;
enum {
is_const_L = ( is_const< L >::value || !is_const< R >::value ),
is_const_R = ( is_const< R >::value || !is_const< L >::value ),
pos_L = mpl::find< sorted_types, const L >::type::pos::value,
pos_R = mpl::find< sorted_types, const R >::type::pos::value,
l2r = is_const_R && is_convertible< non_const_L&, non_const_R& >::value,
r2l = is_const_L && is_convertible< non_const_R&, non_const_L& >::value
};
typedef typename mpl::if_< is_convertible< R, L >, L, R >::type T1;
typedef typename mpl::if_c< ( pos_L != -1 ) && ( pos_L < pos_R ), R, T1 >::type T2;
typedef typename mpl::if_c< l2r, R&, T2 >::type T3;
public:
typedef typename mpl::if_c< r2l, L&, T3 >::type type;
};
} // namespace boost
#endif // BOOST_COMBINED_ARGUMENT_TYPE_HPP
/* supplementing compose function objects
* Fri Jul 16 21:01:58 MEST 1999
*/
/* The following code example is taken from the book
* "The C++ Standard Library - A Tutorial and Reference"
* by Nicolai M. Josuttis, Addison-Wesley, 1999
*
* (C) Copyright Nicolai M. Josuttis 1999.
* Permission to copy, use, modify, sell and distribute this software
* is granted provided this copyright notice appears in all copies.
* This software is provided "as is" without express or implied
* warranty, and with no claim as to its suitability for any purpose.
*/
// See http://www.boost.org/libs/compose for Documentation.
#ifndef BOOST_COMPOSE_HPP
#define BOOST_COMPOSE_HPP
#include
#include
namespace boost {
/**
* type nullary_function
* - as supplement to unary_function and binary_function
**/
template
struct nullary_function {
typedef Result result_type;
};
/**
* ptr_fun for functions with no argument
**/
template
class pointer_to_nullary_function : public nullary_function
{
protected:
Result (*ptr)();
public:
pointer_to_nullary_function() {
}
explicit pointer_to_nullary_function(Result (*x)()) : ptr(x) {
}
Result operator()() const {
return ptr();
}
};
template
inline pointer_to_nullary_function ptr_fun(Result (*x)())
{
return pointer_to_nullary_function(x);
}
/***
RE: [boost] Re: Draft of new Boost Software License
>Matt Hurd wrote: >> >> >The author of a derivative work can put in a more restrictive license >> >right? In this case, wording that gives the full Boost permission must >> >still be included according to the draft license. >> >This would lead to a license text like: >> >> >> I am a little confused. Like Jaakko, I read it as viral. >> >> If you produced a derivative work, or copy paste a little code, then you >> are bound to include the boost license which makes your source open as >> well... >> >> Seems akin to LGPL. >> >> Is this the intention or have I misread it? > >"derivative works of the Software" != "the Software" Sorry, I must be having a bad hair day... I still read it as including the copyright in derivative works from the second paragraph... I would prefer to see acknowledgement of the origin/author(s) as viral. Still confused but I am a little slow, Matt. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Draft of new Boost Software License
Joel de Guzman wrote: > Software can be purely data, right? The documentation > IMO, should be part of "the Software". I would agree but do lawyers think this way too? Is there a generally-accepted definition of what software is? Maybe I'm being pedantic ;-) Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Matt Hurd wrote: > > >The author of a derivative work can put in a more restrictive license > >right? In this case, wording that gives the full Boost permission must > >still be included according to the draft license. > >This would lead to a license text like: > > > I am a little confused. Like Jaarko, I read it as viral. > > If you produced a derivative work, or copy paste a little code, then you > are bound to include the boost license which makes your source open as > well... > > Seems akin to LGPL. > > Is this the intention or have I misread it? "derivative works of the Software" != "the Software" well... unless you work for SCO. ;-) regards, alexander. -- "With SCO's announcement of upping the ante in its lawsuit against IBM (now seeking up to $50 billion in damages), the world is in agreement that SCO owns the world of comedy. As such, SCO is rightfully claiming that all jokes, humor, and laugher is derived from their lawsuit with IBM and belongs to SCO's IP. Furthermore, SCO has sent out letters to over 1,500 well know comics, comedians, and talk show hosts indicating that they may be infringing on SCO'c IP and may be subject to damage claims by SCO. As all humor belongs to SCO, SCO has also sent a letter to R. Dangerfield demanding that he stop being funny or he may face legal action." -- unknown ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] date_time, lexical_cast and MSVC 7.0
At 09:02 AM 6/24/2003, Jeff Garland wrote: >... I wonder if we should consider releasing 1.30.1 ... The Variant Library has been added, so it would be 1.31.0. And, yes, I think we should start talking about a schedule. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
>The author of a derivative work can put in a more restrictive license >right? In this case, wording that gives the full Boost permission must >still be included according to the draft license. >This would lead to a license text like: I am a little confused. Like Jaarko, I read it as viral. If you produced a derivative work, or copy paste a little code, then you are bound to include the boost license which makes your source open as well... Seems akin to LGPL. Is this the intention or have I misread it? Regards, Matt. Australian is my native tongue... ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Draft of new Boost Software License
Andreas Huber <[EMAIL PROTECTED]> wrote: || What about html files? Are they considered to be under || the "the Software" umbrella? Html or any other form of || electronic documentation can be seen as software but you || could just as well argue that it's only data (which || AFAICT would not fall under the license then). Software can be purely data, right? The documentation IMO, should be part of "the Software". || BTW, I (German mother-tongue) agree with Rene that the || long sentences are a bit difficult to grasp. However, I || don't care that much as long as it's legally || bullet-proof. I agree. Kudos to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen! Cheers, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Draft of new Boost Software License
Hi Beman & others, One thing is slightly confusing. The second paragraph says: The copyright notice in the Software and this entire statement, _including the above license grant_, this restriction and the following disclaimer, must be included ... The author of a derivative work can put in a more restrictive license right? In this case, wording that gives the full Boost permission must still be included according to the draft license. This would lead to a license text like: "Permission is hereby granted, free of charge,..." "No, no, no... I didn't really mean that. You must pay ..." Best, Jaakko Järvi & Jeremiah Willcock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Draft of new Boost Software License
Beman, Thanks for your work on this. Looks good to me. One minor thing: > No change from the current status. If your project does not > redistribute Boost source code, you don't have to redistribute the > license, regardless > of how much non-Boost source code is redistributed. > > Hope that helps, What about html files? Are they considered to be under the "the Software" umbrella? Html or any other form of electronic documentation can be seen as software but you could just as well argue that it's only data (which AFAICT would not fall under the license then). BTW, I (German mother-tongue) agree with Rene that the long sentences are a bit difficult to grasp. However, I don't care that much as long as it's legally bullet-proof. Thanks & Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML API for C++, second round
Hi Bohdan, even though you may think of a dom tree as 'just another tree', there is really quite a bit of domain-specific semantics associated with it that makes it impractical to use a general-purpose tree/graph library as the underlying representation. To get an idea of what these xml-specific features are, you may look into the code of libxml2. They do quite a lot of work which you may be unaware of until you really need it. Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Interest in FC++?
I would like to see if there is interest in incorporating the FC++ library into Boost. FC++ is a library for functional programming. In FC++ we program with "functoids" (classes which define operator() and obey certain other conventions). The library features include: - higher order, polymorphic (template) functions (direct functoids) - lazy lists - library of useful functions, combinators, and monads (mostly mimicking the Standard Library of the language Haskell) - currying - infix function syntax - dynamically bound functions (indirect functoids) - effect combinators - interfaces to STL via iterators - ways to transform normal C++ functions/methods into functoids - reference-counted pointers - a lambda sublanguage, with syntax for lambda, let, letrec, do-notation, and monad comprehensions Much of the documentation for FC++ can be found at http://www.cc.gatech.edu/~yannis/fc++/ and the rest appears linked from http://www.cc.gatech.edu/~yannis/fc++/New1.5/ (which has a pre-release of the upcoming version (v1.5), currently out for beta-testing). The upcoming release comprises about 9000 lines of code and compiles on a number of different compilers (g++, Comeau, Intel, MSVC++). I have received mail a couple times in the past few years expressing interest in adding FC++ to Boost. However until now, I have been unwilling (1) to do the work to "Boostify" the library, and (2) to lose any "creative control" to tinker with things on my own whims. I think now the library has finally settled down, and all the major features I have wanted to add are included in the upcoming release (v1.5) of FC++. And I have some free time this summer to do the work. Which is why I'm now finally talking to you-all. So I am sending this mail to see: (1) If there is still interest in adding FC++ to Boost, and (2) If there is interest, what-all needs to be changed with the FC++ library to make it meet the standards of Boost. With regards to (1), I hope yes, but the Boost Lambda Library has a bit of conceptual overlap with FC++, so I can imagine this issue being potentially contentious. (FC++ and Lambda ostensibly provide much of the same kinds of functionality, but while there is overlap, each library does a lot of "its own thing" too. I (and Jaakko too, probably) can say more about this if necessary.) With regards to (2), I have been reading all the stuff on the Boost web site regarding submissions, and so I am aware of a number of issues, including: - Reuse: FC++ "reinvents" a number of Boost's libraries in its implementation, such as smart pointers and metaprogramming tricks. A Boost version of FC++ should reuse Boost libraries for this. - Documentation: as of yet, there is no good singular "users guide" for FC++ aimed at the audience of C++ programmers; I'd need to write one. - Naming conventions: FC++ uses a naming convention other than Boost's (including systematically using capital letters in identifiers). But at this point I'm probably already getting ahead of myself. So I'll stop talking and ask people to comment with regards to "interest" in FC++. Thanks, Brian -- -Brian McNamara ([EMAIL PROTECTED]) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: API Review request: XML API for C++, second round
Hi, Some time ago there was tree-container proposal and if i don't mind there is one in files section or in sandbox. During this discussion someone mentioned that same interface can be used for xml document ... Just curious if it is good idea ? Or it is unusable for heterogenous xml (libxml2) objects like nodes,attributes, text .. ? IMHO i like libraries which manual first lines contain ".. Xxx library/class has the same interface as Yyy library/class ... ". regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
[2003-06-25] Rene Rivera wrote: >must be included, in whole or in part, in all copies of the Software, and >all derivative works of the Software. Oops, that should be: "...must me included in all... of the Software, in whole or in part. It just goes to show how hard it can be to understand this part ;-) -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
> My preference is for there to be a single license file in the > boost root > directory, and each file covered include a link. So a source > code file > might contain something like: > > // (C) Jane Programmer, 2003 > // > // See www.boost.org/license for license terms and conditions > // > // See www.boost.org/libs/janes-lib for documentation > > I'm not sure everyone agrees with that approach - part of the > reason for > discussion is to finalize that. I agree. Repetition in source code is, at best, annoying. Even if it is only in a license comment and not the code itself. Having the license in the file itself also... [sorry, sent too soon] ...makes the text subject to tools like "find" and "replace" which can alter copyright and is undetectable by the compilation process. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
> My preference is for there to be a single license file in the > boost root > directory, and each file covered include a link. So a source > code file > might contain something like: > > // (C) Jane Programmer, 2003 > // > // See www.boost.org/license for license terms and conditions > // > // See www.boost.org/libs/janes-lib for documentation > > I'm not sure everyone agrees with that approach - part of the > reason for > discussion is to finalize that. I agree. Repetition in source code is, at best, annoying. Even if it is only in a license comment and not the code itself. Having the license in the file itself also ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 01:10 PM 6/25/2003, Daniel Frey wrote: >... > >I read the FAQ but I still have a question about the "machine-executable >object code generated by a source language processor". The Software we >sell and distribute contains config files in XML, HTML files, >documentation in various formats and other non-binary files. Even worse, >some part are written in JavaScript/Java (jsp) or PHP. So there are >parts that are distributed as source-code, but still it doesn't contain >C++ sources. From my current understanding, this is not against the >Booster's intentions and the current licenses. That's correct. > I think that the term >used in the suggested new boost license could be a problem here. Reading the entire sentence, the phrase "of the Software" appears three times. Note the capitalization of "Software". That makes it clear that the copyright, license, etc, reproduction requirement only applies to any Boost software, not any non-Boost portions. It doesn't matter what form the non-Boost portions are in; they aren't covered by the license. The inclusion of the "of the Software" phrase prevents the problem you are worried about AFAICS. > Could >someone please explain why - as the FAQ put it - "More detailed wording >was rejected as not being legally necessary, and reducing readability." >and how this covers the above case. The detailed wording was things like adding "such as a compiler or assembler" to "source language processor". > Or is it actually intended that we >cannot use boost for our project? No change from the current status. If your project does not redistribute Boost source code, you don't have to redistribute the license, regardless of how much non-Boost source code is redistributed. Hope that helps, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML API for C++, second round
Hamish Mackenzie wrote:
Why should the node-wrappers keep the document alive?
for consistency, and convenience. In the same way you can get down from
the document to the individual nodes you can get up: node.parent() and
node.document() provide the means to walk up towards the document root.
node.begin_children() lets you iterate over all current child nodes,
i.e. the nodes it returns will all be valid, thus this iterator
interface is as stable as that of linked lists.
I expect the same from node.parent() and node.document(), i.e. as long
as there is an API to walk the tree, it should return valid objects.
That is not to say that these objects will remain valid over time.
As you point out, erasing the content of a container will invalidate
iterators you may still hold for that container.
Imagine a factory object that is initialized with a dom::node_ptr
(holding configurational data, say). Whenever you access its method,
the object looks up data in the node...
class factory
{
public:
factory(dom::node_ptr n) : my_node(n) {}
foo create_foo(); /* access my_node */
bar create_bar(); /* access my_node */
private:
dom::node_ptr my_node;
};
factory 'owns' the node, so whereever you instantiate the factory,
you'd read in a dom::document, look up the relevant node, and pass
that to the constructor:
factory *f;
{
dom::document_ptr document("config.xml");
dom::node_set set = document.root_node().find("//factory.info");
f = new factory(set[0]);
} // document and set are now deleted, but factory still references
// the document through its 'my_node' member
If the document wasn't ref-counted, you'd need to pass it along with
the node to the factory, as only the factory would know when to drop
it (in its destructor, presumably).
Here is the analogy I think works best...
container --> document
container::value_type --> node
container::iterator --> node_iterator
container::pointer_type --> node_pointer
container::reference_type --> node_reference
hmm, that makes it look simpler than it actually is: is there really
a single 'value_type' ? Is there really a single iterator ? (iterating
over all child nodes of a given parent and iterating over all attributes
is not the same)
Also, what is a node_reference (as opposed to a pointer) ?
Consider the following
std::vector< foo > x;
...
foo * y = &x[0];
x.erase( x.begin(), x.end() );
I don't expect y to add_ref x. I wouldn't mind if it did, but it
wouldn't make y any more valid after the call to erase.
agreed. However, you explicitely erase elements, while all I want to
prevent is implicit object destruction just because a reference to it
goes out of scope.
So the problem with add reffing the document is... what happens if the
root node or some parent of a node you have a pointer to is erased from
the document? libxml2 has no way of knowing you have a pointer to a
child node.
that's right. And adding such a feature may be quite expensive memory /
performance wise. As I said, I don't feel it's a problem, as you would
explicitely remove the node, so you should know what you are doing
anyways. (As you said, you wouldn't even expect an iterator to be valid
after you erase the container's content).
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
Hi, Beman Dawes wrote: Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now have a pretty close to final draft of a new Boost Software License. The draft license itself is at http://boost.sourceforge.net/misc/LICENSE.txt Wow! While we are interested in comments from any Booster, we would particularly like to hear from: * Boosters for whom English isn't their primary language; is the license understandable? It looks ok for me. * Boosters (or their lawyers) from countries other than the US; do they spot any issues missed by Boost's US-centric legal team? * Boost developers; if there are aspects of the license that make you hesitate about adopting it, what are the issues? Well, I have a question. I understand that the text of this license is primarily intended to be used by Boost libraries and those that are candidates to be included in Boost. However, apart from the main Boost effort, some of the Boosters or just Boost lurkers may find the text of the license very good for their own work, which is not connected to the Boost itself. Long version: Let's imagine the following situation (it can apply to any developer on this planet): I write some code and want it to get public. It is outside of mainstream Boost interest, so I do not intend to submit it to Boost. Being concerned with the legal issues, I want to have a license text that is proven to be OK from the lawyers' viewpoint. Of course, a lot of people (Boosters and lawyers) have spent their time preparing and reviewing the Boost license and ensuring that it meets the high standards of today's open software. Is it OK if I just copy-n-paste the Boost license into my own work? Is it OK if I use only part of it? This can have many implications, including legal precedents - for example, when some of my users abuse the license or just asks me what he can do with the software, I can just point him to Boost pages, FAQs, etc. In other words, I may hide behind the curtains sewed by people who just never took me and my work into account. Is it OK if I do it? Short version: Is there any copyright on the Boost license text? What license protects the Boost license? :) -- Maciej Sobczak http://www.maciejsobczak.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
[2003-06-25] Beman Dawes wrote: >For more background, including rationale, a FAQ, and acknowledgements, see >http://boost.sourceforge.net/misc/license-background.html Nice. >* Boosters for whom English isn't their primary language; is the license >understandable? Spanish is my first, but English is a very close second. The impression I got is that it's somewhat hard to parse as it is. I had to read the second "paragraph" a few times before I managed to parse out the different parts of it. The main difficulty in the first part (the first two "paragraphs") is the the lists in it are inconsistent and hard to see which are the items. For example, the switching from simple items to adding "and" in some of them threw me. I was expecting the list to end, but it did not. The second paragraph is long; and without any separators other than the commas it's hard to read. Here's an edited version which might be better for non-english readers to understand: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software covered by this license (the "Software") to: use, reproduce, display, distribute, execute, transmit, 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 notice in the Software and this entire statement, including the above license grant, this restriction, and the following disclaimer, must be included, in whole or in part, in all copies of the Software, 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 dislaimer is fine] -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
On Wed, 25 Jun 2003, Beman Dawes wrote: > Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now > have a pretty close to final draft of a new Boost Software License. > I am glad to hear that some folks have been working on this. These issues are quite important and might make any legal issues surrounding Boost easier, especially as it gains visibility and use. > This draft represents a lot of discussion between the lawyers and Boost > moderators, and both groups are quite happy with the results. So now it's > time to open it up for comments from the whole Boost community. In reading the license, I think the definition of "Software" needs to be broadened to explicitly include the documentation, test suites, etc. see: http://www.opensource.org/licenses/mit-license.php for an example. Additionally, the BSD license goes into even more detail with respect to software, binaries, etc. I feel that it's good to have a human-readable license, but it seems more pressing to ensure proper coverage of the legal issues, even if it means that the license gets a little longer. In this specific case where the license will (hopefully) cover much of Boost, I presume that it will be placed in the distribution and all files covered mentioned by reference. In that case, it seems fine to me for the license to be longer and more explicit. Again, much kudos to all who have been working on this. ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
At 01:27 PM 6/25/2003, Paul Mensonides wrote: >> * Boost developers; if there are aspects of the license that make you >> hesitate about adopting it, what are the issues? > >It looks fine to me Beman. Is this license (once it is completely >ironed out) supposed to go in each file? The license is worded so that it works either in each file or separately. My preference is for there to be a single license file in the boost root directory, and each file covered include a link. So a source code file might contain something like: // (C) Jane Programmer, 2003 // // See www.boost.org/license for license terms and conditions // // See www.boost.org/libs/janes-lib for documentation I'm not sure everyone agrees with that approach - part of the reason for discussion is to finalize that. The exact wording of the "See ... for license ..." is yet to be decided. We will follow the lawyers advice, in any case. > If so, where do you put the >credentials for who created what? Or do we leave that out altogether? Each file still needs to carry a copyright, as in the past. I probably should have mentioned that Diane Cabell and her helpers see several additional legal issues Boost should deal with in addition to the license. One of those has to do with legal aspects of "who created what". But while those issues are starting to come into focus, they are not ready for full discussion yet. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
Peter Dimov wrote: > Aleksey Gurtovoy wrote: > > Peter Dimov wrote: > >> > >> Also, please note that I don't mind the _developer summary_ being > >> "aggressive" in its pass/fail reports. There are no "expected > >> failures" there as far as I'm concerned. Every failure needs to be > >> reported in red, with pass->fail transitions emphasized. > > > > Do you mean that there are no expected failures for the smart_ptr > > library (which we'll take care of soon), or something else? 'Cause > > I, for instance, definitely would like to see a CVS health report in > > terms of regressions rather than absolute failures. > > I meant that my objections applied to the user summary, not > the developer summary, OK, I understood that one. > and that I personally don't need a way to mask a 'fail' on the > developer summary, even if I expect a test to fail on this > configuration. Interesting. Given the total number of failures we have, it's practically impossible to track the regressions if the "expected" failures are not masked, though - especially when changes are made to something as basic as 'config' or 'type_traits'. We can easily provide such report, I am just trying to determine what are the use cases. Could you please elaborate on yours? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Experimental audience-targeted regression results
Peter Dimov wrote: >>> Beman's approach, where unexpected failures were automatically >>> determined by comparing the current run with aprevious run, seems to >>> cope better with this scenario, and requires no manual input. >> >> Does it? What if the previous run was a total failure - what the next >> one is going to show? > > Nothing will go wrong; it's only pass->fail transitions that are > emphasized. But that's my point. If current run was a disaster, in the next one - which can happen an hour later - the new failures won't be emphasized since they are not new anymore - even although they _are_ regressions and need to be fixed! > False pass->fail transitions can only happen for > compile-fail/link-fail tests that aren't that significant. > > >> IMO it can work only if you have a trusted snapshot of what is >> considered a "good" CVS state and you update it "pessimistically" - >> that is, remove the expected failures that are now passing and leave >> everything else intact - automatically, of course. And that's exactly >> what we are going to do. > > I didn't realize that the plan was to automatically manage the expected > failures. It wasn't at the very beginning, but thanks to your and other people's comments our understanding evolved, and so did the plan :). Thank you, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes wrote: [...] > * Boosters (or their lawyers) from countries other than the US; do they > spot any issues missed by Boost's US-centric legal team? They seem to have missed a whole bunch of issues "surrounding" implied patent license. regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
> * Boost developers; if there are aspects of the license that make you > hesitate about adopting it, what are the issues? It looks fine to me Beman. Is this license (once it is completely ironed out) supposed to go in each file? If so, where do you put the credentials for who created what? Or do we leave that out altogether? Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Trouble building latest CVS (Intel 7.1 and VC7)
Beman Dawes wrote: > Intel's 7.1 upgrade doesn't bump their release macro! It is still > reporting 700. > > I tried to update to use Intel 7.1 with VC++ 7.1, but am getting > strange results. The IDE integration doesn't seem to provide a way to > switch to the Intel compiler. Boost tests are getting weird link > failures. No std::endl for example. Either the Intel release isn't > ready for VC++ 7.1 (in spite of claims to the contrary) or I've done > something stupid. > > Which VC++ version are you integrating Intel with? Have you gotten it > to work with VC++ 7.1? > Currently ours is configured to integrate (and be compatible with) MSVC 6.0. We didn't try anything else (yet). > Also, your setup is confusing the bjam automatic version deduction. If you mean all those 'wchar_t'-related failures, it doesn't have anything to do with the bjam version deduction - it's "boost/config/compiler/intel.hpp" that is at fault here. As per http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864, a standalone Intel C++ 7.x does not automatically define _WCHAR_T_DEFINED macro, but then checking just for that one to determine whether we need to set BOOST_NO_INTRINSIC_WCHAR_T is not enough, because the former one is also getting defined in Dinkumware's header, so currently the success of the compilation on Intel 7.x in VC6 compatibility mode very much depends on the order of includes of various boost headers. For instance, this one-liner compiles: #include "boost/type_trais/is_integral.hpp" but this one already does not: #include #include "boost/type_trais/is_integral.hpp" Since the toolset automatically, through the command line, defines _NATIVE_WCHAR_T_DEFINED whenever '/Zc:wchar_t' is specified, I would say that #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else # ifndef _WCHAR_T_DEFINED #define BOOST_NO_INTRINSIC_WCHAR_T # endif #endif lines in "boost/config/compiler/intel.hpp" should look more like #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else # if !defined(_NATIVE_WCHAR_T_DEFINED) #define BOOST_NO_INTRINSIC_WCHAR_T # endif #endif but then the file's history shows that we went through quite a few iterations on this one, so I am not that sure. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes wrote:
Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now
have a pretty close to final draft of a new Boost Software License.
For as many Boost libraries as possible, the plan is to replace the
individual licenses with the "official" Boost license. Of course, the
developers who hold the copyrights for each library must agree. We'll
also submit the Boost license to the OSI (http://www.opensource.org/)
for certification.
This draft represents a lot of discussion between the lawyers and Boost
moderators, and both groups are quite happy with the results. So now
it's time to open it up for comments from the whole Boost community.
Nice work and I appreciate it. I hope that something as a single boost
license will be adopted soon.
For more background, including rationale, a FAQ, and acknowledgements,
see http://boost.sourceforge.net/misc/license-background.html
The draft license itself is at
http://boost.sourceforge.net/misc/LICENSE.txt
I read the FAQ but I still have a question about the "machine-executable
object code generated by a source language processor". The Software we
sell and distribute contains config files in XML, HTML files,
documentation in various formats and other non-binary files. Even worse,
some part are written in JavaScript/Java (jsp) or PHP. So there are
parts that are distributed as source-code, but still it doesn't contain
C++ sources. From my current understanding, this is not against the
Booster's intentions and the current licenses. I think that the term
used in the suggested new boost license could be a problem here. Could
someone please explain why - as the FAQ put it - "More detailed wording
was rejected as not being legally necessary, and reducing readability."
and how this covers the above case. Or is it actually intended that we
cannot use boost for our project?
While we are interested in comments from any Booster, we would
particularly like to hear from:
* Boosters for whom English isn't their primary language; is the license
understandable?
I'm from Germany ("Old Europe", ya know ;) and I don't have problems to
understand it. And I'm not an expert in real languages as you might have
noticed from my other postings already :o)
* Boosters (or their lawyers) from countries other than the US; do they
spot any issues missed by Boost's US-centric legal team?
Can't really comment on this one as I'm not a lawyer - just a laymen.
* Boost developers; if there are aspects of the license that make you
hesitate about adopting it, what are the issues?
Sadly, yes. See above...
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Draft of new Boost Software License
Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now have a pretty close to final draft of a new Boost Software License. For as many Boost libraries as possible, the plan is to replace the individual licenses with the "official" Boost license. Of course, the developers who hold the copyrights for each library must agree. We'll also submit the Boost license to the OSI (http://www.opensource.org/) for certification. This draft represents a lot of discussion between the lawyers and Boost moderators, and both groups are quite happy with the results. So now it's time to open it up for comments from the whole Boost community. For more background, including rationale, a FAQ, and acknowledgements, see http://boost.sourceforge.net/misc/license-background.html The draft license itself is at http://boost.sourceforge.net/misc/LICENSE.txt While we are interested in comments from any Booster, we would particularly like to hear from: * Boosters for whom English isn't their primary language; is the license understandable? * Boosters (or their lawyers) from countries other than the US; do they spot any issues missed by Boost's US-centric legal team? * Boost developers; if there are aspects of the license that make you hesitate about adopting it, what are the issues? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Current CVS Snapshot or...?
Hi, My company is using boost and we would very much like to use variant library immediately and not wait for the next official release of boost. Now, we know that this might not be sensible, but we are ready to take the risk. At the same time, we don't want to break anything else in the boost (and by chain reaction in our code). It seems that variant lib is dependent on (branch of?) mpl, so what I would like to know is: what is the most sane branch/snapshot we should take from the cvs to get reasonably stable boost (overall) with variant in whatever state it is ATM? Thanks, Drazen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] posix_time to timeval conversion
Jeremy Maitin-Shepard wrote: > The thread library as of boost 1.30 does provide a struct xtime, which > is similar to timeval, except that xtime represents a time, while > timeval represents a time duration. The documentation for the thread > library suggests, however, that xtime is intended as a temporary > solution only, and that it will be replaced by a more complete boost > time library. I do not know whether William E. Kempf has already > planned to make this change in the next revision of the thread > library, but it seems that the Boost date/time library is precisely > the library that should replace xtime; I think Bill and I both have this conversion on the todo list. Not sure when we will get to it. I think the point still remains that if the thread interface is recast in terms of time_duration then the thread lib will need to get access, in some cases, to a timeval to adapt to the operating system. Thus it seems logical we would put this conversion function into date_time since we have multiple other libraries that might need this conversion. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML API for C++, second round
On Wed, 2003-06-25 at 01:12, Stefan Seefeld wrote:
> hi there,
>
> some weeks ago I proposed an API for XML, which triggered an interesting
> discussion. Hamish Mackenzie proposed a somewhat simpler mechanism to attach
> the C++ wrapper objects to the C structs from libxml2.
>
> I reworked the API to use that mechanism, so now using an xml document
> looks somewhat like:
>
> dom::document_ptr document("1.0");
> dom::element_ptr root = document.create_root_node("root");
> dom::element_ptr child = root.append_child("child");
> dom::text_ptr text = root.append_text("hello world");
> for (dom::element_ptr::child_iterator i = root.begin_children();
> i != root.end_children();
> ++i)
>std::cout << i->get_name() << std::endl;
>
> As the wrapper objects have reference semantics, I append '_ptr' to
> their name to stress that fact. A practical side-effect of this is
> that the document is now ref-counted, as it doesn't own the node-wrappers
> any more (as was the case in my former API).
Why should the node-wrappers keep the document alive?
Here is the analogy I think works best...
container --> document
container::value_type --> node
container::iterator --> node_iterator
container::pointer_type --> node_pointer
container::reference_type --> node_reference
Consider the following
std::vector< foo > x;
...
foo * y = &x[0];
x.erase( x.begin(), x.end() );
I don't expect y to add_ref x. I wouldn't mind if it did, but it
wouldn't make y any more valid after the call to erase.
So the problem with add reffing the document is... what happens if the
root node or some parent of a node you have a pointer to is erased from
the document? libxml2 has no way of knowing you have a pointer to a
child node.
I think the solution is that the node iterators/pointers/reference
should not own anything (as is the convention with containers). The
document owns the root node, the root node owns it's children and so on.
If a particular implementation (such as MSXML) has ref counting built in
that's fine but it should not be a requirement. The boost::xml
interface requirements could simply state "iterators, pointers and
references for nodes are invalidated by deleting the document to which
they belong or by erasing them from the document (erasing a parent node
erases it's children)". It doesn't matter if for some implementations
they are still valid. We can add a remove function something like...
class document
{
public:
std::auto_ptr< document > remove( node_iterator i );
};
This would take a node and all its children and put them in a new
document object. An implementation that has a underlying mechanism for
nodes to exist without the implementations document object could allow
xml::document to exist with just a root node and make the appropriate
optimisation to remove.
--
Hamish Mackenzie <[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Experimental audience-targeted regression results
> Well, we didn't do anything special to mis-configure it ;), besides > choosing MSVC 6 compatibility mode (during the setup, as opposite to > MSVC 7.0 one). Any ideas what's the right way to fix that? The problem is that there is no way for the config system to tell how your Intel compiler is set up, and which conformance options have been set (because Intel doesn't define any macros to indicate which options have been enabled/disabled), so... you basically have to set up boost.config manually to match your compiler options. On unix platforms running the configure script would do that, but that's a little tricky on win32 :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math constants - nearest values - are they valued?
I am now confident that I understand what you are proposing. It certainly seems "The Right Thing To Do" (tm) but is more complicated for me to calculate, though not too bad. I would welcome confirmation from other potential users that they agree. Paul PS Of course the problem of macro, function, template function is still to be resolved and is still being worked on elsewhere. PPS I couldn't see in the ISO C++ spec if float and double is required to be 32 and 64 bits. Any Language Lawyers care to say? | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Guillaume Melquiond | Sent: Wednesday, June 25, 2003 8:59 AM | To: Boost mailing list | Subject: RE: [boost] Re: Math constants - nearest values | | | On Sun, 22 Jun 2003, Paul A Bristow wrote: | | > | Consequently, more than one constant out of 1 may suffer | > | from this problem. So it is rare, but it is not impossible. | > | It's why I was suggesting that a library should provide a | > | mean to know if a number representing a constant is the | > | nearest or not. | > | > One constant out of 1 seems a rather small risk. | | > Can't we just check that all the constants we offer are in fact the | > nearest? | | Yes. | | > Since very few contain many zeros, I think I am prepared to wager a few | > beers on this one! | | > So does this mean that the presentation function will use the 'exactly | > representable' decimal digits appropriate for the floating point format | > (choice of 5) and for the FP type float, double, long double to give to | > the compiler to use? | | Sorry, I'm not sure I clearly understand what you mean. What I would do is | something like | | float the_constant_f = ... /* a 24 binary digits representation */; | double the_constant_d = ... /* a 53 binary digits representation */; | long double the_constant_ld = | #ifdef LONG_DOUBLE_IS_80_BITS | ... /* a 64 binary digits representation */; | #elif defined(LONG_DOUBLE_IS_128_BITS) | ... /* a 102 binary digits representation */; | #else /* we don't know this floating-point format */ | ... /* a 40 decimal digits approximation */; | #define the_constant_LONG_DOUBLE_MAY_NOT_BE_ACCURATE | #endif | /* And then there would be all the wrappers... */ | | The binary representations will be exact values in order to avoid compiler | rounding. So all possible floating-point formats should be thought of. | However, if one of them is missing, we fall back on a common 40 decimal | digits constant. Since we can't be sure there won't be any rounding | problem, we flag the result as being "maybe inaccurate". Does it make | sense? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math constants - nearest values
On Sun, 22 Jun 2003, Paul A Bristow wrote: > | Consequently, more than one constant out of 1 may suffer > | from this problem. So it is rare, but it is not impossible. > | It's why I was suggesting that a library should provide a > | mean to know if a number representing a constant is the > | nearest or not. > > One constant out of 1 seems a rather small risk. > Can't we just check that all the constants we offer are in fact the > nearest? Yes. > Since very few contain many zeros, I think I am prepared to wager a few > beers on this one! > So does this mean that the presentation function will use the 'exactly > representable' decimal digits appropriate for the floating point format > (choice of 5) and for the FP type float, double, long double to give to > the compiler to use? Sorry, I'm not sure I clearly understand what you mean. What I would do is something like float the_constant_f = ... /* a 24 binary digits representation */; double the_constant_d = ... /* a 53 binary digits representation */; long double the_constant_ld = #ifdef LONG_DOUBLE_IS_80_BITS ... /* a 64 binary digits representation */; #elif defined(LONG_DOUBLE_IS_128_BITS) ... /* a 102 binary digits representation */; #else /* we don't know this floating-point format */ ... /* a 40 decimal digits approximation */; #define the_constant_LONG_DOUBLE_MAY_NOT_BE_ACCURATE #endif /* And then there would be all the wrappers... */ The binary representations will be exact values in order to avoid compiler rounding. So all possible floating-point formats should be thought of. However, if one of them is missing, we fall back on a common 40 decimal digits constant. Since we can't be sure there won't be any rounding problem, we flag the result as being "maybe inaccurate". Does it make sense? > Paul > > PS How do we check? Does it depend on the FP format? It depends on the source FP format and on the destination FP format. We check it by looking if the rounded down version of the most precise value is equal to the less precise version of the constant. But it doesn't matter anymore if we explicitely give the values of the constant for all the formats and not only for the most precise format. Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Are their any rumors about boost 1.31?
Hello Boosters! Currently we are still using boost version 1.29.0, but would like to use a newer version. You all know that such a transfer means work on large projects, so I would like to ask, whether anyone knows, when possibly boost 1.31 is going to be published? If this point of time is not so far away from now, we would probably prefer to wait on it... Btw, I would like to express my very high respect for this fantastic library which is still growing because of the high engagement and the personal initiative of all its participants! Thank you, Daniel Spangenberg from Bremen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
