For the first merge with the release branch, I only want to include some of the
changes I've been working on (fixes and some trivial changes), so I'm starting
again from 1.34.1.
[SVN r38873]
From Mark Rodgers Fri Dec 1 12:59:14 2006
X-Apparently-To: ahd6974-boostorg -at- yahoo.com via 68.142.206.160; Fri, 01 Dec 2006 12:59:41 -0800
X-Originating-IP: [195.112.4.54]
Return-Path: <mark.rodgers -at- cadenza.co.nz>
Authentication-Results: mta550.mail.mud.yahoo.com from=cadenza.co.nz; domainkeys=neutral (no sig)
Received: from 195.112.4.54 (EHLO smtp.nildram.co.uk) (195.112.4.54) by mta550.mail.mud.yahoo.com with SMTP; Fri, 01 Dec 2006 12:59:40 -0800
Received: from snagglepuss.cadenza.co.nz (81-6-246-87.dyn.gotadsl.co.uk [81.6.246.87]) by smtp.nildram.co.uk (Postfix) with ESMTP id D32EA2B6D8C for <ahd6974-boostorg -at- yahoo.com>; Fri, 1 Dec 2006 20:59:35 +0000 (GMT)
Received: from penfold.cadenza.co.nz ([192.168.55.56]) by snagglepuss.cadenza.co.nz with esmtp (Exim 4.63) (envelope-from <mark.rodgers -at- cadenza.co.nz>) id J9M4Y9-0009TO-9K for ahd6974-boostorg -at- yahoo.com; Fri, 01 Dec 2006 20:58:57 +0000
Message-ID: <457097A2.1090305@cadenza.co.nz>
Date: Fri, 01 Dec 2006 20:59:14 +0000
From: "Mark Rodgers" <mark.rodgers -at- cadenza.co.nz>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: ahd6974-boostorg -at- yahoo.com [Edit - Delete]
Subject: Re: [boost] Reminder: Need your permission to correct license & copyright issues
References: <379990.36007.qm@web33507.mail.mud.yahoo.com>
In-Reply-To: <379990.36007.qm@web33507.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 812
Gidday Andreas
Sure that's fine. I'm happy for you to do 1, 2 and 3.
Regards
Mark
Andreas Huber wrote:
> Hello Mark
>
> Quite a while ago it was decided that every file that goes into the
> 1.34 release of the Boost distribution (www.boost.org) needs uniform
> license and copyright information. For more information please see:
>
> <http://www.boost.org/more/license_info.html>
>
> You are receiving this email because several files you contributed
> lack such information or have an old license:
>
> boost/functional/functional.hpp
> boost/libs/functional/binders.html
> boost/libs/functional/function_test.cpp
> boost/libs/functional/function_traits.html
> boost/libs/functional/index.html
> boost/libs/functional/mem_fun.html
> boost/libs/functional/negators.html
> boost/libs/functional/ptr_fun.html
> boost/people/mark_rodgers.htm
>
> I therefore kindly ask you to grant the permission to do the
> following:
>
> 1. For the files above that already have a license text (all except
> mark_rodgers.htm), replace the license text with:
>
> "Distributed under the Boost Software License, Version 1.0. (See
> accompanying file LICENSE_1_0.txt or copy at
> http://www.boost.org/LICENSE_1_0.txt)"
>
> 2. For the file that does not yet have a license and copyright
> (mark_rodgers.htm) add the same license text as under 1. and add the
> following copyright:
>
> "(c) Copyright Mark Rodgers 2000"
>
> 3. (Optional) I would also want to convert all HTML files to conform
> the HTML 4.01 Standard by running them through HTML Tidy, see
> <http://tidy.sf.net>
>
> It would be great if you could grant me permission to do 1 & 2 and
> optionally also 3.
>
> Thank you!
>
> Regards,
>
> Andreas Huber
>
[SVN r36245]
extension implementation a little clearer. It also fixes a problem where the
visual C++ include once pragma was preventing the extensions from being loaded
on the second include.
[SVN r35314]
For the record: I removed the overload because it was causing an ambiguity that I was too lazy to work out at the time. It turned out this was because wchar_t was defined as unsigned short - using BOOST_NO_INTRINSIC_WCHAR_T was the right way to deal with this so the overload no longer needs to be disabled.
[SVN r33114]
1. hash_float is no longer dependent on the main hash header.
2. hash_float(0) == 0 which makes it easier to implement hash<complex>(),
although this might lead to users assuming that it can be expected even though
it isn't part of the documented interface.
[SVN r32780]
Daniel James
nobody
Andreas Huber