My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you are expiriencing.
Gennad
Aleksey Gurtovoy wrote:
Below are the remaining changes that need to be commented on:
martin_wille
* tools/build/intel-linux-tools.jam: need -lrt, always
intel-linux-tools: added rt to FINDLIBS in order to make the
clock_gettime() function available (backport of a patch in
CVS HEAD)
Regards,
C:\Projects\boost.bc>bjam "-sTOOLS=vc7.1"
C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse error at
keyword (
C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse error at
keyword )
libs\date_time\build\Jamfile:31: in load-jamfiles
rule dll unknown in module
C:\Proje
En réponse à "Paul A. Bristow" <[EMAIL PROTECTED]>:
> But as Michael Caine said "Not a lot of people know that" - so I trust
> you will explain what it does too for the benefit of us mere non-mathematical
> mortals!
>
> Paul
I'm not sure to understand. Do you want me to explain what a convex hul
Gennadiy Rozental wrote:
My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you
> Boost.Config uses _POSIX_VERSION to determine wether sigaction()
> is available. The presence of _POSIX_VERSION doesn't indicate
> wether the POSIX API has actually been enabled.
>
> If we want to use Boost.Config to take care of this then
> Boost.Config also has to check wether POSIX has been en
Guillaume Melquiond <[EMAIL PROTECTED]> writes:
| In the case of a 1-dimension space, connected and convex set are
| equals: they are segments (or half-line or line or empty). Date
| manipulated by the date-time library are in a 1-dimension space (the
| real line) and periods are segments (non-emp
> The current approach is clearly too restrictive and isn't satisfactory.
> Beyond the problems you mention, there really isn't a single standard for
> portability. Even 8.3 names aren't portable to systems which don't allow
> periods in names. A whole family of checkers is needed, giving various
>
> > My understanding is that Boost.Config should take care about these
issues.
> > Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
> > case if there is no support for POSIX interfaces. Could you report the
value
> > of that flag in case of compilation failures you are expir
Daniel Frey wrote:
> Hi Dave,
>
> I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS
> HEAD. It was created in cooperation with Howard and I'm positiv that it's
> a good one-size-fits-all solution. I don't know about your shedule for
> 1.30.2, but you might want to consider mer
At 05:13 AM 8/18/2003, Gennadiy Rozental wrote:
>> Boost.Config uses _POSIX_VERSION to determine wether sigaction()
>> is available. The presence of _POSIX_VERSION doesn't indicate
>> wether the POSIX API has actually been enabled.
>>
>> If we want to use Boost.Config to take care of this then
>>
"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes:
> C:\Projects\boost.bc>bjam "-sTOOLS=vc7.1"
> C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse
> error at keyword (
> C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse
> error at keyword )
> libs\date_time\build\J
Jeff Gray <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>>Jeff, this is a very Python-specific problem. You'll probably have
>>better luck posting on the C++-sig:
>>
>>http://www.boost.org/more/mailing_lists.htm#cplussig
>>
> Thanks David, that is probably a better forum. I hadn't read
Aleksey Gurtovoy wrote:
Things to be done (at large):
1) Linux regressions, on RC_1_30_0. Martin, since fixing the aforementioned
problems involved some changes in the CVS (including some jam files), could
you please do a clean run?
Done. No regressions.
Regards,
m
__
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> For everyone's information, here's the status of 1.30.2 release preparation.
>
> Current status:
>
> Two outstanding problems with the win32 regressions (accidentally revealed
> bug in "testing.jam" + unexpected failures for the intel-stlport
> config
Peter Dimov wrote:
It is worth mentioning that this is a confirmed bug in CW
with -iso_templates on (unreferenced typedefs are incorrectly optimized out
at definition time). Masking compiler bugs in this way does not help
compiler writers who use Boost as a test suite.
The bug is already fixed for
> I'd be interested in such library.
> I think that boos::xml library should be using boost::spirit
> for parsing XML streams.
I have now hand-coded parser. I'm actually more interested whether the
interface of the library is ok, so I think I'll submit the current version,
and I'll try to switch t
Daniel Frey <[EMAIL PROTECTED]> writes:
> Peter Dimov wrote:
>> It is worth mentioning that this is a confirmed bug in CW
>> with -iso_templates on (unreferenced typedefs are incorrectly optimized out
>> at definition time). Masking compiler bugs in this way does not help
>> compiler writers who u
> I have been using expat for a while, and wrapping it in C++ classes.
> It's a very capable parser and supports lot's of stuff.
> My parser stuff is just done with a switch statement (since it's event
> driven), but it would be nice if you could use expat, but then
> "register" your element "ha
Daniel Frey wrote:
> Peter Dimov wrote:
>> It is worth mentioning that this is a confirmed bug in CW
>> with -iso_templates on (unreferenced typedefs are incorrectly
>> optimized out at definition time). Masking compiler bugs in this way
>> does not help compiler writers who use Boost as a test sui
HL7 v3, a health care application layer specification, uses the term with time intervals as
an operation on a totally ordered set that produces the smallest interval that is a superset.
For example, hull({[1,5], [7,10]}) == [1,10]
The unabridged specification part II available on Dr. Schadow's page
> May I come with a bit of scepticism? There's already XUL (see
> http://xulplanet.com for a start, and
> http://www.mozilla.org/catalog/architecture/xul/ for more details).
> I think Mozilla folks put some effort into it, so I wonder if
> XMLUI offers
> something new/better?
I would say that tar
At 05:43 AM 8/18/2003, John Torjo wrote:
>> The current approach is clearly too restrictive and isn't satisfactory.
>> Beyond the problems you mention, there really isn't a single standard
for
>> portability. Even 8.3 names aren't portable to systems which don't
allow
>> periods in names. A whole
David Abrahams wrote:
Daniel Frey <[EMAIL PROTECTED]> writes:
Peter Dimov wrote:
It is worth mentioning that this is a confirmed bug in CW
with -iso_templates on (unreferenced typedefs are incorrectly optimized out
at definition time). Masking compiler bugs in this way does not help
compiler writ
In discussions about being able to specify a function to check the validity
of path element names, a simple function pointer has been used:
typedef bool (*name_check)( const std::string & name );
Alternately, boost::function could be used. The boost::function docs
mention several advantages o
On Mon, 18 Aug 2003 06:34:35 -0500, John Fuller wrote
> HL7 v3, a health care application layer specification, uses the term
> with time intervals as
> an operation on a totally ordered set that produces the smallest
> interval that is a superset.
> For example, hull({[1,5], [7,10]}) == [1,10]
>
On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote
> Guillaume Melquiond <[EMAIL PROTECTED]> writes:
>
> | In the case of a 1-dimension space, connected and convex set are
> | equals: they are segments (or half-line or line or empty). Date
> | manipulated by the date-time library are in a 1-dim
Beman Dawes wrote:
> In discussions about being able to specify a function to check the
> validity of path element names, a simple function pointer has been
> used:
>
>typedef bool (*name_check)( const std::string & name );
>
> Alternately, boost::function could be used. The boost::function doc
Beman Dawes <[EMAIL PROTECTED]> writes:
> Yes. Plus there are some other issues.
>
> The actual interface would include boost::filesystem::path
> constructors which take an additional argument to explicitly specify a
> name checker function. In working out use cases, it seems that
> temporary over
Daniel Frey <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Daniel Frey <[EMAIL PROTECTED]> writes:
>>
>>>Peter Dimov wrote:
>>>
It is worth mentioning that this is a confirmed bug in CW
with -iso_templates on (unreferenced typedefs are incorrectly optimized out
at definition t
Beman Dawes <[EMAIL PROTECTED]> writes:
> In discussions about being able to specify a function to check the
> validity of path element names, a simple function pointer has been
> used:
>
>typedef bool (*name_check)( const std::string & name );
>
> Alternately, boost::function could be used. T
Edward Diener wrote:
> Beman Dawes wrote:
>> In discussions about being able to specify a function to check the
>> validity of path element names, a simple function pointer has been
>> used:
>>
>>typedef bool (*name_check)( const std::string & name );
>>
>> Alternately, boost::function could be
David Abrahams wrote:
>
> FWIW, Boost.Function is overkill for many simple cases. This might
> be a case where the FS library should just provide a class with a
> virtual function:
>
> struct checker
> {
> virtual ~checker() {}
> virtual bool operator()( s
"Jeff Garland" <[EMAIL PROTECTED]> writes:
| On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote
| > Guillaume Melquiond <[EMAIL PROTECTED]> writes:
| >
| > | In the case of a 1-dimension space, connected and convex set are
| > | equals: they are segments (or half-line or line or empty). Date
|
Martin Wille wrote:
> Aleksey Gurtovoy wrote:
>
> > Things to be done (at large):
> >
> > 1) Linux regressions, on RC_1_30_0. Martin, since fixing the
aforementioned
> > problems involved some changes in the CVS (including some jam files),
could
> > you please do a clean run?
>
> Done. No regressio
Well,
I've tried to work through the solutions to:
ld: common symbols not allowed with MH_DYLIB output format
Which are basically "-fno-common" on the compile line of each file, but
apart from the fact that tihs doesn't actually work in this case (we
still get the error), it's not really a ver
how about "span" ?
At Monday 2003-08-18 02:43, you wrote:
Guillaume Melquiond <[EMAIL PROTECTED]> writes:
| In the case of a 1-dimension space, connected and convex set are
| equals: they are segments (or half-line or line or empty). Date
| manipulated by the date-time library are in a 1-dimensi
Paul Hamilton wrote:
> Well,
>
> I've tried to work through the solutions to:
>
> ld: common symbols not allowed with MH_DYLIB output format
>
> Which are basically "-fno-common" on the compile line of each file, but
> apart from the fact that tihs doesn't actually work in this case (we
> still
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>
>> FWIW, Boost.Function is overkill for many simple cases. This might
>> be a case where the FS library should just provide a class with a
>> virtual function:
>>
>> struct checker
>> {
>> virtual ~c
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>>
>>> FWIW, Boost.Function is overkill for many simple cases. This might
>>> be a case where the FS library should just provide a class with a
>>> virtual function:
>>>
>>> struct checker
>>>
"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes:
| how about "span" ?
when read as "the period of time spanned by these two", I can make
sense of it, even not as a mathematician :-)
Well, I don't know how it sounds to native speakers.
-- Gaby
__
Fernando Cacciola wrote:
> Recently, Jens Maurer changed the guard at function scope
> from:
>
> #ifndef __GNUC__
> to
> #ifndef BOOST_NO_STDC_NAMESPACE
>
> and honestly, I didn't looked much at it as I should.
>
> BOOST_NO_STDC_NAMESPACE is documented to relate to C names,
> but swap is a C++ n
I suggested it because we write software for people who run multiple
experiments with "rest periods" between the data collection sessions. They
seem to use the word span to specify the approximate duration of the series
of tests. "These experiments were conducted over a span of 3 weeks." Then
It also has the advantage of being similar to the use of "makespan" as
the time from
the start time of the first job to the completion time of the last job
in job scheduling
problems.
On Monday, August 18, 2003, at 02:18 PM, Victor A. Wagner, Jr. wrote:
I suggested it because we write software
On the other hand, "hull" encompasses the idea of
a "periodic hull" that can be used for periodic intervals of time...
On Monday, August 18, 2003, at 02:39 PM, John Fuller wrote:
It also has the advantage of being similar to the use of "makespan" as
the time from
the start time of the first job t
Jens Maurer <[EMAIL PROTECTED]> writes:
> Fernando Cacciola wrote:
>> Recently, Jens Maurer changed the guard at function scope
>> from:
>>
>> #ifndef __GNUC__
>> to
>> #ifndef BOOST_NO_STDC_NAMESPACE
>>
>> and honestly, I didn't looked much at it as I should.
>>
>> BOOST_NO_STDC_NAMESPACE is d
Jens Maurer wrote:
> > BOOST_NO_STDC_NAMESPACE is documented to relate to C names,
> > but swap is a C++ name so I don't think such macro
> > should be used here.
>
> The CVS change of optional.hpp:1.10 is definitely incorrect,
> because STDC_NAMESPACE refers to C names, not C++ names.
> Sorry.
>
>
At 02:08 PM 8/18/2003, Edward Diener wrote:
>... one of the reasons, as I understand it, for
>boost::function and boost::bind is so the end-user has the benefit of
>defining his callback as he sees fit and not have it more rigidly
dictated
>by the implementation. That is the main reason I support
At 10:59 AM 8/18/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> Yes. Plus there are some other issues.
>>
>> The actual interface would include boost::filesystem::path
>> constructors which take an additional argument to explicitly specify a
>> name checker function. In
At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote:
>At Monday 2003-08-18 11:39, you wrote:
>>"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes:
>>
>>| how about "span" ?
>>
>>when read as "the period of time spanned by these two", I can make
>>sense of it, even not as a mathematician :-)
>>
>>W
Beman Dawes <[EMAIL PROTECTED]> writes:
| At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote:
|
| >At Monday 2003-08-18 11:39, you wrote:
| >>"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes:
| >>
| >>| how about "span" ?
| >>
| >>when read as "the period of time spanned by these two", I
"Jens Maurer" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
> > Recently, Jens Maurer changed the guard at function scope
> > from:
> >
> > #ifndef __GNUC__
> > to
> > #ifndef BOOST_NO_STDC_NAMESPACE
> >
> > and honestly, I didn't looked much at it as
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 10:59 AM 8/18/2003, David Abrahams wrote:
>
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> Yes. Plus there are some other issues.
> >>
> >> The actual interface would include boost::filesystem::path
> >> constructors which take an additional
Agreed - but what do we do if NOT is_iec559?
Give up? #error "Can only work with IEEE 754!"
Or choose a massive amount of decimal digits? eg 40?
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
mailto:[EMAIL PROTECTED]
| -Ori
David Abrahams wrote:
>
> Sure; I just don't want to have to be explicit about anything just to
> say "I'm doing native path manipulation", since I believe that's the
> 90% case. I don't want to be stopped by irrelevant portable path
> considerations nor uglify my code to avoid it.
I agree except
The Header section in the following pages is garbled.
Looks like a bunch of missing newlines.
http://www.boost.org/doc/html/any.reference.html
http://www.boost.org/doc/html/function.reference.html
-Jeremy
--
Jeremy Siek
Thanks - it does now make sense, but since (mercifully!) time is only
1-dimensional, I find the span suggestion more intuitive.
Paul
PS This explanation could usefully be added to the interval library
documentation. I was puzzled why the word 'hull' was used.
| -Original Message-
| From:
Beman Dawes wrote:
> At 02:08 PM 8/18/2003, Edward Diener wrote:
>
> >... one of the reasons, as I understand it, for
> >boost::function and boost::bind is so the end-user has the benefit
> of >defining his callback as he sees fit and not have it more rigidly
> dictated
> >by the implementation
The documentation notes that BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG controls
the choice of the internal time representation, between the "split" (32 bit
integer + 64 bit integer) and "counted" (64 bit integer only) varieties. The
documentation also suggests that the split representation is the defau
On Monday 18 August 2003 06:04 pm, Jeremy Siek wrote:
> The Header section in the following pages is garbled.
> Looks like a bunch of missing newlines.
>
> http://www.boost.org/doc/html/any.reference.html
> http://www.boost.org/doc/html/function.reference.html
>
> -Jeremy
Where would you like to s
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>
>> Sure; I just don't want to have to be explicit about anything just to
>> say "I'm doing native path manipulation", since I believe that's the
>> 90% case. I don't want to be stopped by irrelevant portable path
>> consideratio
Subject: Re: garbled boostboc output in online docs
^
Pretty funny.-^
Jeremy Siek <[EMAIL PROTECTED]> writes:
> The Header section in the following pages is garbled.
> Looks like a bunch of missing newlines.
--
Dave Abrahams
Boost Consulting
www.boost-con
I have some concerns about the implementation of the "period" concept, as
given in period.hpp. First of all, the documentation (for, say, date_period)
talks of the constructor
date_period(date begin,date last)
as creating a period as [begin,last). But really what is meant here is that
the "last"
Guess that would be a curiously recurring email subject line ;)
On Monday, August 18, 2003, at 08:15 PM, David Abrahams wrote:
Subject: Re: garbled boostboc output in online docs
^
Pretty funny.-^
___
Unsubscribe &
Hi Doug,
Hmm, I just viewed it with a different browser (Apple's Safari instead
of and old version of Netscape on a Sun) and now I see lots of newlines
(there were none before). Is this a case of non-portability of a html
tag, or a bug in Netscape?
Cheers,
Jeremy
On Monday, August 18, 2003, at
Jeremy Siek <[EMAIL PROTECTED]> wrote:
> Guess that would be a curiously recurring email subject line ;)
>
> On Monday, August 18, 2003, at 08:15 PM, David Abrahams wrote:
>
>>
>> Subject: Re: garbled boostboc output in online docs
>> ^
>> Pretty funny.-^
Y
Peter Dimov wrote:
Did you try to remove the "static const"?
Not sure if this would achieve the same effect as the code is trying to
get done. I think it's a static const so that the the compiler will
optimize it out and just init the string.
Paul.
-
Paul Hamilton
pHamtec P
67 matches
Mail list logo
