On Tuesday 11 March 2003 09:20 pm, Beman Dawes wrote:
> Doug Gregor is tentatively planning to host a session on the Boost
> documentation system he has been working on. No date or time yet.c
>
> Doug, how are your plans shaping up?
>
> --Beman
I'm mainly working on usability issues now, most impo
At 08:27 PM 3/11/2003, Alisdair Meredith wrote:
>Borland fails several tests due to missing exports from in its
>dynamic runtime library.
One question: Is there any way to work around the missing exports by adding
some Borland specific code to boost/limits.hpp? Or would that just cause
problems
At 09:07 PM 3/11/2003, Edward Diener wrote:
>While I realize it may be the only answer to the problems you mention,
>making libraries link to the static RTL where they would normally link to
>the dynamic RTL is IMHO a bad general solution. My reason for thinking
this
>is the problems which always
At 07:07 PM 3/11/2003, Alisdair Meredith wrote:
>Is there any reason the Spirit tests are not integrated into the
>regression suite at the moment?
Too much for 1.30.0. The same applies to Boost.Python.
As soon as 1.30.0 ships we need to review a bunch of operational issues,
including regression
At 07:12 PM 3/11/2003, Dietmar Kuehl wrote:
>Beman Dawes wrote:
>> The C++ Standards Committee will be meeting in Oxford, UK, April 7th
>> through 11th. As always, Boosters are welcome to attend as "technical
>> experts" - See http://www.boost.org/more/cpp_committee_meetings.html.
>
>Is there goin
"Alisdair Meredith" <[EMAIL PROTECTED]> escribió en el
mensaje news:[EMAIL PROTECTED]
> Borland fails several tests due to missing exports from in its
> dynamic runtime library.
>
> The following two patches will use static linking on the problem
> libraries (for borland only)
>
I'm not sure if th
I would like to suggest a change to token_iterator.hpp. I need my
token_iterator's token_function to be able to accumulate state. Therefore,
I would like to add the following public method to class
boost::detail::tokenizer_policy :
const TokenizerFunc &func() const {return func_;}
Note that
While I realize it may be the only answer to the problems you mention,
making libraries link to the static RTL where they would normally link to
the dynamic RTL is IMHO a bad general solution. My reason for thinking this
is the problems which always seem to occur when modules mix static and
dynamic
Borland fails several tests due to missing exports from in its
dynamic runtime library.
The following two patches will use static linking on the problem
libraries (for borland only)
BOOST_ROOT/status jamfile for config/limits test
cvs diff Jamfile (in directory C:\Projects\3rdParty\boost\statu
On Tue, 11 Mar 2003 12:22:19 +0100, Sam Partington wrote:
> As for the issue below, I also have no idea how to go about
> automatically selecting either method. Plus I think this might
> introduce complexities which make the compiler's job that much harder to
> optimise. Could well be wrong on t
Beman Dawes wrote:
> The C++ Standards Committee will be meeting in Oxford, UK, April 7th
> through 11th. As always, Boosters are welcome to attend as "technical
> experts" - See http://www.boost.org/more/cpp_committee_meetings.html.
Is there going to be general Boost meeting on Sunday something l
At 06:31 PM 3/11/2003, Beman Dawes wrote:
>At 03:57 PM 3/11/2003, Alisdair Meredith wrote:
>
> >All the links to warnings/fails point to the d: drive and so are a
> >little inaccessible right now
>
>Argh! I've been fooling around with the setup to allow running tests on
>both the main trunk and t
Is there any reason the Spirit tests are not integrated into the
regression suite at the moment?
I just updated status\jamfile to test locally and the only problem I had
was an MT test running away for a VC7 build
diff below
===
RCS
Having implemented [most of] the IOStreams library I think I can comment
on the array streams stuff:
- Stream buffers normally cannot be copied and I don't see any reason
why this should be different for array streams. The only good this
copy constructor would is to allow returning this kind o
M. Andre wrote:
>So I guess the config isn't included in all files? According to
the docs
>#include is an
>available header file with definitions without io.
Looks like I introduced a bug here. Will fix.
Thx,
Jeff
___
Unsubscribe & other
At 03:57 PM 3/11/2003, Alisdair Meredith wrote:
>All the links to warnings/fails point to the d: drive and so are a
>little inaccessible right now
Argh! I've been fooling around with the setup to allow running tests on
both the main trunk and the release candidate, and that is clearly having
so
Hello!
When compiling the following program on gcc 3.2 on a Linux box aginst the
boost in the CVS repository it fails
#include
int main(int argc, char** argv) {}
with
[EMAIL PROTECTED] michel]$ g++ i.c -I"/home/michel/boost/work"
In file included from
/home/michel/boost/work/boost/date_time/p
> * The Rationale for Array-Based Streams concludes "it may have real-life
> applications." It would be a bit more satisfying if there was at least one
> example of a real-life application.
I second this. Could anybody show an example where array_stream would be
preferable to stringstream.
In othe
"Eric Martel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> Nearly 5 months later, did anyone work on this bimap?
I didn't. ;)
> Will it be included anytime soon in an official distribution of boost?
Not unless someone ambitious like you decides to work on it some
more. ;
At 03:23 AM 3/10/2003, Geurt Vos wrote:
>Hi,
>Is there any reason boost::filesystem::path doesn't
>provide a swap(path &) function? If there is, I think
>the docs should explain why, but if there isn't, well,
>can it still be implemented before 1.30.0 goes gold?
Let me turn the question around and
"Eric Martel" <[EMAIL PROTECTED]> writes:
> Hi,
>
> After a quick Google search, I found out that Joaquín M López, the author of
> a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002
> 21:29:18) on the boost mailing list to promote his library. David B. Held
> replied abou
Gennaro Prota wrote:
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:
Perhaps I missed a part of the discussion, but what is wrong with Jaap's
suggestion:
#ifdef BOOST_STATIC_NDEBUG
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
#define
All the links to warnings/fails point to the d: drive and so are a
little inaccessible right now
Also, is there any way to get the 'differences emphasised' view? Often
a single test starts passing/failing and it is very hard to locate which
one has changed, especially without the previous test r
At 12:48 PM 3/11/2003, Gennadiy Rozental wrote:
>
>> It looks pretty explicit to me. If you think it can be improved,
>> please propose a doc patch.
>
>May be like this. See the patch attached.
Applied. Thanks!
--Beman
___
Unsubscribe & other changes:
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:
>> In effect I would prefer the one without __LINE__. But if any compiler
>> warns about duplicate typedefs than it's better having a single
>> version, with __LINE__, than #ifs.
>>
>> Also I have a slight preference for
Comments, based on reading the docs (without much background in
understanding the ins and outs of stream buffers):
* Needs a libs/io/test/Jamfile, using the subinclude approach from the main
status/Jamfile.
* The Stream-buffer-wrapping Streams Rationale section (there is no
Introduction sectio
Hi,
After a quick Google search, I found out that Joaquín M López, the author of
a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002
21:29:18) on the boost mailing list to promote his library. David B. Held
replied about using his work to include the bidirectionnal map to
on 3/11/03 11:45 AM, Beman Dawes at [EMAIL PROTECTED] wrote:
> At 11:01 AM 3/11/2003, Markus Schöpflin wrote:
>
>> The must be something wrong with the current darwin regression tests,
>> AFAICT. I just completed a full regression run of the latest RC
>> version and I get far lower failure rates
> It looks pretty explicit to me. If you think it can be improved,
> please propose a doc patch.
May be like this. See the patch attached.
Gennadiy.
begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;&5A6-O9&4N
M:'!P(%MM97)G92!C:&%N9V5S(&9R;[EMAIL PROTECTED]')U;[EMAIL PROTECTED]&[EMAIL
For those of you interested in subgraph isomorphism, I put a raw version of
Ullmann's algorithm at http://groups.yahoo.com/group/boost/files/ullmann.hpp
It uses BGL's interface.
Regards,
--
vladimir josef sykora
morphochem AG
gmunder str. 37-37a
81379 muenchen
tel. ++49-89-78005-0
fax ++49-89-7
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:
> I got it now. May be we could spell out explicitly what we are merging into
> branch: namely the deference between merged_to_RC_whatever and HEAD tags.
> Not all that fluent with cvs flags.
> A! I missed -F flag. Maybe we should spell it out exp
Gennaro Prota wrote:
On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:
#define BOOST_STATIC_ASSERT(c) \
typedef char boost_static_assert_typedef
When using several asserts in the same context some compilers could
complain about the duplicate typedef; if so past
At 11:01 AM 3/11/2003, Markus Schöpflin wrote:
>The must be something wrong with the current darwin regression tests,
>AFAICT. I just completed a full regression run of the latest RC
>version and I get far lower failure rates that the current regression
>results indicate (9% failures instead of 45
> > 1. I committed it in main trunk: cvs commit abc.cpp
> > 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
> > right now)
> > 3. I merge it to the release branch
>
> No, you got 2 and 3 reversed, and you only do the tagging after
> switching back to the trunk.
I got it no
First, a reminder that today is the last day for sumbitting a review for the update to
the I/O library.
This is my review of the I/O library, which is separate from my role as review manager.
I vote that the library update be accepted into boost. I examined the documentation
and code. The new
The must be something wrong with the current darwin regression tests,
AFAICT. I just completed a full regression run of the latest RC
version and I get far lower failure rates that the current regression
results indicate (9% failures instead of 45%).
I uploaded the results to the regression tes
At 10:36 AM 3/11/2003, Gennadiy Rozental wrote:
>> > P.S. Could you, please, clarify for me again what is the purpose of
>this
>> > tag? How does it related to the fixes I made in trunk after branch is
>> > created?
>>
>> The tag marks the last trunk revision that has been merged into the
>> branch
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:
>> > P.S. Could you, please, clarify for me again what is the purpose of this
>> > tag? How does it related to the fixes I made in trunk after branch is
>> > created?
>>
>> The tag marks the last trunk revision that has been merged into the
>> branch
On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:
>> #define BOOST_STATIC_ASSERT(c) \
>>typedef char boost_static_assert_typedef
>>
>> When using several asserts in the same context some compilers could
>> complain about the duplicate typedef; if so pasting t
> > P.S. Could you, please, clarify for me again what is the purpose of this
> > tag? How does it related to the fixes I made in trunk after branch is
> > created?
>
> The tag marks the last trunk revision that has been merged into the
> branch, so that when you do a merge to the branch you can alw
On Monday 03 March 2003 10:03 am, Lars Gullik Bjønnes wrote:
> I see that when upgrading LyX to use the upcomming 1.30.0 release
> instead of the 1.29.0 release our binary size increases by more than
> 125kB...
>
> I have not tried to figure out where that increase comes from, but the
> usual suspe
Joel de Guzman wrote:
> What compiler errors are you getting? If it's the attached "Buffer
> overrun detected!" error, then that's clearly a VC7.1 compiler bug.
I was able to reproduce Viv's problem using VC7.1 RC3 and the Boost 1.30.0
beta 1 release. It appears that the buffer overrun is related
Gennadiy Rozental wrote:
Hi, Beman
In examples for release procedure you are using: "merged_to_1_26_2". While
in "Release Procedures for the Release Manager" section you are mention:
"merged_to_RC_n_n_n". What is correct?
We have no "merged_to_1_30_0" tag in the CVS but a
"merged_to_RC_1_30_0" tag
At 12:23 AM 3/11/2003, Gennadiy Rozental wrote:
>Hi, Beman
>
>In examples for release procedure you are using: "merged_to_1_26_2".
While
>in "Release Procedures for the Release Manager" section you are mention:
>"merged_to_RC_n_n_n". What is correct?
Should read "merged_to_RC_1_26_2". Martin Will
At 04:16 AM 3/10/2003, Martin Wille wrote:
>the attached patch fixes two typos in the release procedures document.
Fixed. Thanks!
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:
> P.S. Could you, please, clarify for me again what is the purpose of this
> tag? How does it related to the fixes I made in trunk after branch is
> created?
The tag marks the last trunk revision that has been merged into the
branch, so that when yo
At 08:12 PM 3/10/2003, David Abrahams wrote:
>> OK to check this into the RC_1_30_0 branch?
>
>Go for it! You don't need to ask permission to make stuff work.
>(it's nice to notify the list when you do, though)
It helps me too; I'm trying to track outstanding issues with RC_1_30_0, so
it helps t
At 03:37 AM 3/11/2003, Lars Gullik Bjønnes wrote:
>Who should I send this to, to make someone have a look at it?
Posting it here is fine.
I haven't seen any postings from John Maddock in several days; I'm guessing
he has taken some time off after his push last week ago finishing the final
rege
> Who should I send this to, to make someone have a look at it?
Probably me, but I'm tied up right now, will be back around here once I get
cvs etc working on my new PC.
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cg
Dear all,
I need to split a string into tokens, and split the
resulting tokens again in a second pass. Currently,
I do this with boost::tokenizer initialized
with an escaped_list_separator.
The problem is that all the quote characters are
swallowed during the first pass, which makes
things
vc wrote:
>> Hi all,
>>
>> I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting
>> a Linux application on Windows. I got the BETA sources
>> (http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip)
>> and I give it a try, but the compiler stops with the "Buffer overrun
>>
Thanks for your comments Daniel, I will update the docs with a better
rationale and post the patch soon.
As for the issue below, I also have no idea how to go about automatically
selecting either method. Plus I think this might introduce complexities
which make the compiler's job that much harder
I just reported it.
Viv
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 8:14 PM
Subject: Re: [boost] When will be the next boost released?
> "vc" <[EMAIL PROTECTED]> writes:
>
Hi all,
I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting
a Linux application on Windows. I got the BETA sources
(http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip)
and I give it a try, but the compiler stops with the "Buffer overrun
detected!" error (see Vccrash.j
Who should I send this to, to make someone have a look at it?
--- Begin Message ---
The following patch fixes some compilation problems when
BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
(first hunk: when BOOST_NO_WREGEX is defined we end up including
) and something I found
55 matches
Mail list logo
