March 2006 - Boost - lists.preview.boost.org

[1.34] branch for release on Monday
by Thomas Witt 20 Mar '06

20 Mar '06

Hi, I am going to create the release branch on Monday March 20 around 6pm PST. Please resolve as many outstanding issues as possible before the branch is done. Also check the Latest News section in boost/index.htm in CVS for any omissions. Thanks Thomas -- Thomas Witt witt(a)acm.org

3 4

Re: [boost] [1.34] branch for release on Monday
by Boris Gubenko 20 Mar '06

20 Mar '06

Ralf, did you test your patch with aCC V3 or only with aCC V6? If the latter is the case, I suggest, you conditionalize it with: #if __HP_aCC >= 60000 I doubt, that boost.python compiles with aCC3, but if it does, your patch is likely to break it. Thanks, Boris ----- Original Message ----- From: <boost(a)lists.boost.org> To: <boost(a)lists.boost.org> Sent: Sunday, March 19, 2006 9:32 AM Subject: Re: [boost] [1.34] branch for release on Monday > Return-Path: boost-bounces(a)lists.boost.org > Received: from compaqcce.compaq.com ([16.47.68.171]) > by bugsy.zko.dec.com (UCX V4.2-21H, OpenVMS V6.2 VAX); > Sun, 19 Mar 2006 09:32:33 -0500 > Received: from ztxmail01.ztx.compaq.com (ztxmail01.nz-cce.cpqcorp.net > [161.114.8.205]) > by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 005369520 > for <boris(a)bugsy.zko.dec.com>; Sun, 19 Mar 2006 08:34:34 -0600 (CST) > Received: from palrelrim04.pa.itc.hp.com (palrelrim04.pa.itc.hp.com > [192.151.81.52]) > by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id B30679C4E > for <boris(a)bugsy.zko.dec.com>; Sun, 19 Mar 2006 08:34:34 -0600 (CST) > Received: from palrelrim04.pa.itc.hp.com (localhost [127.0.0.1]) > by receive-from-antispam-filter (Postfix) with SMTP id 4D38594C0B > for <boris(a)bugsy.zko.dec.com>; Sun, 19 Mar 2006 06:37:54 -0800 (PST) > Received: from wowbagger.osl.iu.edu (wowbagger.osl.iu.edu > [129.79.245.252]) > by palrelrim04.pa.itc.hp.com (Postfix) with ESMTP id ED0A594C0E > for <boris.gubenko(a)hp.com>; Sun, 19 Mar 2006 06:37:53 -0800 (PST) > Received: from wowbagger.osl.iu.edu (localhost [127.0.0.1]) > by wowbagger.osl.iu.edu (Postfix) with ESMTP id 4CB55105628; > Sun, 19 Mar 2006 09:33:22 -0500 (EST) > X-Original-To: boost(a)lists.boost.org > Delivered-To: boost(a)lists.boost.org > Received: from web31507.mail.mud.yahoo.com (web31507.mail.mud.yahoo.com > [68.142.198.136]) > by wowbagger.osl.iu.edu (Postfix) with SMTP id C37CB1055A1 > for <boost(a)lists.boost.org>; Sun, 19 Mar 2006 09:33:16 -0500 (EST) > Received: (qmail 4177 invoked by uid 60001); 19 Mar 2006 14:34:14 -0000 > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; > h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; > b=Vo4JbxPxLxCLe0nwtdU9HNBs1YaOBKUc758av1HTrq3G3j2Qgj1jWGTML8MqB8ouB9TOpasfuY36WGkZN6DJxAMTnZAs8peNymBxUlDG3C2NZos/b2JFBCv9E11icuEcdkRLpaHdorr7lDp418ltyD1ft3f7u/kLxpwxonxe6hk= > ; > Message-ID: <20060319143413.4175.qmail(a)web31507.mail.mud.yahoo.com> > Received: from [24.4.205.206] by web31507.mail.mud.yahoo.com via HTTP; > Sun, 19 Mar 2006 06:34:13 PST > Date: Sun, 19 Mar 2006 06:34:13 -0800 (PST) > From: "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> > To: boost(a)lists.boost.org > In-Reply-To: <dviv3h$goo$1(a)sea.gmane.org> > MIME-Version: 1.0 > Subject: Re: [boost] [1.34] branch for release on Monday > X-BeenThere: boost(a)lists.boost.org > X-Mailman-Version: 2.1.6 > Precedence: list > Reply-To: boost(a)lists.boost.org > List-Id: Boost developers' mailing list <boost.lists.boost.org> > List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > <mailto:boost-request@lists.boost.org?subject=unsubscribe> > List-Archive: <http://lists.boost.org/MailArchives/boost> > List-Post: <mailto:boost@lists.boost.org> > List-Help: <mailto:boost-request@lists.boost.org?subject=help> > List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > <mailto:boost-request@lists.boost.org?subject=subscribe> > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Sender: boost-bounces(a)lists.boost.org > Errors-To: boost-bounces(a)lists.boost.org > X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: > 2006.3.19.61109 > > I have a one-line patch needed to support Boost.Python under HP-UX with > the > native aCC compiler: > > Index: type_id.hpp > =================================================================== > RCS file: /cvsroot/boost/boost/boost/python/type_id.hpp,v > retrieving revision 1.17 > diff -r1.17 type_id.hpp > 34a35 >> || (defined(__hpux) && defined(__HP_aCC)) \ > > > I tested this already in our local multi-platform (ca. 20) build, i.e. I > am > sure it will not cause trouble. Would it be OK to check this in before the > release branch is created? > > Thanks! > > Cheers, > Ralf > > --- Thomas Witt <witt(a)acm.org> wrote: > >> >> Hi, >> >> I am going to create the release branch on Monday March 20 around 6pm >> PST. Please resolve as many outstanding issues as possible before the >> branch is done. >> >> Also check the Latest News section in boost/index.htm in CVS for any >> omissions. >> >> Thanks >> >> Thomas >> >> -- >> Thomas Witt >> witt(a)acm.org >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > >

2 1

Boost vault dead?
by Andy Little 19 Mar '06

19 Mar '06

I cant seem to open http://www.boost-consulting.com/vault or indeed http://www.boost-consulting.com for around 2 hrs Just get Cannot find server or DNS error regards Andy Little

1 0

uniform_real rather alarmingly non-random?
by John Maddock 19 Mar '06

19 Mar '06

I seriously hope I'm doing something wrong here, but the last 20 bits in a double returned from uniform_real appear to always be zero. Is this by design? I really hope not! Here's the test code: template <class T> void test_random(T) { boost::mt19937 rnd; boost::uniform_real<T> ur_a(0.5, 1); boost::variate_generator<std::tr1::mt19937, std::tr1::uniform_real<T> > gen(rnd, ur_a); for(int j = 0; j < INT_MAX-2; ++j) { T v = gen(); // get the digits of T: unsigned long long i = (unsigned long long)std::floor(std::ldexp(v, std::numeric_limits<T>::digits)); i &= 0xfffff; // last 20 bits std::cout << std::hex << i << std::endl; } } Try calling with a double as an argument and it'll output nothing but zero's. John.

6 11

boost::compression viability
by sm garth 19 Mar '06

19 Mar '06

is there current consideration for a boost compression library? --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments.

2 3

[Boost-bugs] [ boost-Patches-1430820 ] [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report
by SourceForge.net 18 Mar '06

18 Mar '06

Patches item #1430820, was opened at 2006-02-13 18:49 Message generated for change (Comment added) made by speedsnail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Kevin J Bluck (kbluck) >Assigned to: Roland Schwarz (speedsnail) Summary: [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report Initial Comment: MSVC CRT memory debugger pedantically complains about an unreleased singleton allocation. Although the consensus is that this is a harmless annoyance, it does cause some concern for MSVC users who don't know what is happening. Issue discussed in this Boost mailing list thread: http://lists.boost.org/boost-users/2005/08/13538.php Attached is a patch for tss_hook.cpp, which uses the function _CrtSetDbgFlag to temporarily turn off heap allocation tracking for the particular allocation in question. It should have no effect except on MSVC debug builds. On my configuration (msvc-8_0) it eliminates the leak warnings. ---------------------------------------------------------------------- >Comment By: Roland Schwarz (speedsnail) Date: 2006-03-18 21:12 Message: Logged In: YES user_id=541730 I will look into this, since AFAIK Michael Glassford currently is not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1430820 ] [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report
by SourceForge.net 18 Mar '06

18 Mar '06

Patches item #1430820, was opened at 2006-02-13 09:49 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin J Bluck (kbluck) >Assigned to: Mike Glassford (glassfordm) Summary: [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report Initial Comment: MSVC CRT memory debugger pedantically complains about an unreleased singleton allocation. Although the consensus is that this is a harmless annoyance, it does cause some concern for MSVC users who don't know what is happening. Issue discussed in this Boost mailing list thread: http://lists.boost.org/boost-users/2005/08/13538.php Attached is a patch for tss_hook.cpp, which uses the function _CrtSetDbgFlag to temporarily turn off heap allocation tracking for the particular allocation in question. It should have no effect except on MSVC debug builds. On my configuration (msvc-8_0) it eliminates the leak warnings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1452743 ] [regex] fixes warning on mingw
by SourceForge.net 18 Mar '06

18 Mar '06

Patches item #1452743, was opened at 2006-03-17 13:00 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Baraclese (baraclese) >Assigned to: John Maddock (johnmaddock) Summary: [regex] fixes warning on mingw Initial Comment: [regex] [current cvs] mingw automatically defines NOMINMAX in bits/ os_defines.h to protect some standard headers. Compiler thus emits a warning about redefinition of NOMINMAX in static_mutex.cpp. [solution] Add #undef NOMINMAX before #define NOMINMAX to file libs\regex\src\static_mutex.cpp(27) Other files which define this are: libs\regex\src\regex.cpp(31) libs\regex\src\w32_regex_traits.cpp(27) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1452698 ] iostreams // file_descriptor::seek BUG on files > 4 GB
by SourceForge.net 18 Mar '06

18 Mar '06

Patches item #1452698, was opened at 2006-03-17 12:08 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452698&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jonathan Turkanis (turkanis) Summary: iostreams // file_descriptor::seek BUG on files > 4 GB Initial Comment: Boost 1.33.1 iostreams library file_descriptor::seek() method file_descriptor.cpp, line 198 Win32, Visual C++ 2005 The method seek() can return a wrong value of a newly set offset when the offset is further than 4 GB. //--------------- return offset_to_position((lDistanceToMoveHigh << 32) + dwResultLow); //--------------- The code above has a bug. On 32-bit systems the expression (lDistanceToMoveHigh << 32) equals to lDistanceToMoveHigh. The correct code should first cast the lDistanceToMoveHigh variable to 64-bit and then shift it. //--------------- return (static_cast<boost::intmax_t> lDistanceToMoveHigh) << 32) + dwResultLow; //--------------- Sergey Kolodkin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452698&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[regression] run_tests.sh regression.py
by Roland Schwarz 18 Mar '06

18 Mar '06

Apparently there are two scripts to generate regression test tables available. Can anyone please tell me when to use which? Is one of them deprecated or do they serve different purpose? Roland

2 4