> Yes - millseconds, microsconds, nanoseconds ... please.
Done.
> And time_point shounds VERY MUCH better to me (than ptime or time).
My only worry about time_point is then things like local_time or
multiprecision_time (no these don't currently exist in the library) would
probably need to be l
On Wed, 03 Sep 2003 17:09:08 -0400, Philip Miller wrote
> David Abrahams wrote:
>
> > I'm trying to get a ptime relative to 1/1/1970, so I did:
> >
> > using namespace boost::date_time;
> > ptime d;
> > ...
> > boost::posix_time::time_duration since_1970 = d - 1/Jan/1970;
> >
> > E
On Wed, 03 Sep 2003 15:20:50 -0400, David Abrahams wrote
> >> Disable the macros where neccessary? You can do it temporarily and
> >> provide an alias typedef.
> >
> > But what other code would that break if you disable the macro?
>
> None. When you find the nonconforming platform, you find th
On Wed, 03 Sep 2003 15:10:13 -0400, David Abrahams wrote
> "Jeff Garland" <[EMAIL PROTECTED]> writes:
>
> >>Jeff G wrote:
> >> I'm thinking it would have to be defined like this
> >> Duration / Duration --> Integer
> >>
&g
On Wed, 03 Sep 2003 15:27:24 -0400, David Abrahams wrote
> This is causing an ambiguity:
>
> using namespace boost::date_time;
^^^
Right, you don't need the line above.
> using namespace boost::posix_time;
> time_duration since_1970 = d - 1/Jan/1970;
On Wed, 03 Sep 2003 15:09:11 -0400, David Abrahams wrote
> "Jeff Garland" <[EMAIL PROTECTED]> writes:
>
> > On Tue, 02 Sep 2003 19:10:03 -0400, David Abrahams wrote
> >> Where is this documented, and what is "nano" in the table entry below?
>
On Wed, 03 Sep 2003 15:07:59 -0400, David Abrahams wrote
> "Jeff Garland" <[EMAIL PROTECTED]> writes:
>
> > On Tue, 02 Sep 2003 19:00:42 -0400, David Abrahams wrote
> >> The "fractional seconds" concept is undocumented. My guess it's
> &
On Wed, 3 Sep 2003 Paul Bristow wrote
> Although I an growing to like date_time, I have to agree that some names are
> less than ideal. I found kday less than intuitive.
This name actually comes from Calendrical Calculations. But I'm not stuck on
it if you you have other suggestions.
> Docu
> > My first choice was 'time'. However, as I recall I ran into some
> > nasty macros that interfered with that name, sigh. time_point would be
> > another possibility, but it is longer. I'm certainly open to suggestions...
> Disable the macros where neccessary? You can do it temporarily an
>Jeff G wrote:
> I'm thinking it would have to be defined like this
> Duration / Duration --> Integer
>
>I think Duration / Duration --> double would be more appropriate.
I have intentionally avoided floating point types in the library because there
is no reason to suffer the loss of correctness
On Tue, 02 Sep 2003 19:10:03 -0400, David Abrahams wrote
> Where is this documented, and what is "nano" in the table entry below?
It isn't. nano is an enum value that isn't really useful for much except
indexing into string tables like in the previous email.
> static boost::date_time::time
On Tue, 02 Sep 2003 19:00:42 -0400, David Abrahams wrote
> The "fractional seconds" concept is undocumented. My guess it's
> something like:
>
> x.fractional_seconds() == x.ticks() % seconds(1).ticks()
>
> This needs to be nailed down.
Yep the docs don't say enough on this.
Basically, ti
On Tue, 02 Sep 2003 18:27:59 -0400, David Abrahams wrote
> Suppose I want to know how many minutes there are in a particular
> duration d? My intuition says:
>
> d / minutes(1)
>
> But there's no such operator. Why not?
An interesting point. Probably should be possible. While additi
On Tue, 02 Sep 2003 16:50:09 -0400, David Abrahams wrote
> I'm just getting started with the date_time library, and I think I'm
> gonna like it.
Let's hope so!
> I have some quibbles with the naming choices though
> (shocking! me of all people!) For example, why is the nested
> namespace calle
On Sun, 31 Aug 2003 09:59:26 +0200, Martin Wille wrote
> Jeff Garland wrote:
> > The regression test page seems to be on a diet
> >
> > http://boost.sourceforge.net/regression-logs/
>
> You can find some of the other results at
>http://boost.sourcefor
Before I make this request I'd just like to thank all the boosters that have
contributed to the creation of the regrssion test system and actually run
regression tests. It is an essential tool for portable library development.
I don't know how we got things done correctly before we had this.
So
On Thu, 28 Aug 2003 19:35:57 +0100, Paul A. Bristow wrote
> Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option
> /Za 'disable language extensions' it seems that
>
> boost::int64_t isn't available.
>
> After a journey through the labryinthine config modules, I have got compiling
>
On Wed, 20 Aug 2003 08:30:38 +1000, Chris Trengove wrote
> "Jeff Garland" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Yes at the moment there is really no effect because the library doesn't
> > contain any time functions. It may no
On Tue, 19 Aug 2003 13:25:37 +1000, Chris Trengove wrote
> 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
On Mon, 18 Aug 2003 16:28:22 -0400, Beman Dawes wrote
> FWIW, I'm both a native-speaker and familiar with convex hulls.
> Regardless, "span" sounds better to me for use in the context of a
> Date-Time library.
Ok, span it is. Updates checked into CVS
Jeff
_
On Tue, 19 Aug 2003 10:08:51 +1000, Chris Trengove wrote
> 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 doc
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
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 Sun, 17 Aug 2003 08:11:14 +0200 (CEST), gmelquio wrote
> I just wanted to mention that the interval library names this
> operation "hull". It is a mathematically defined term since the
> operation is indeed a convex hull.
>
> Just my two eurocents,
>
> Guillaume
Thanks, I like it. Precise
On Sat, 16 Aug 2003 23:31:05 -0400, Jeremy B. Maitin-Shepard wrote
> > Yes, of course, it is not really a union either. I think
> > merge_inclusive is fine.
>
> How about "maximize" or "maximize_duration" or just "max" or
> "max_duration"?
Thx for the ideas, but...
I'm leary of these b/c this i
> >"Peter Dimov" <[EMAIL PROTECTED]> wrote:
>> I am not sure that it should be the responsibility of the path class to
>> enforce some notion of portability.
I haven't been following this whole discussion, but I'll chime in here b/c
I believe some of this might be partially due to comments I m
On Sat, 16 Aug 2003 09:05:10 +1000, Chris Trengove wrote
> "Jeff Garland" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Sure, can do. What would you call it: merge_inclusive, earliest_latest,
> rename
> > merge to union and call it merge,
Stephan T. Lavavej wrote:
> In working with my date/time code I've encountered another problem with
> Boost. I can reproducibly get lexical_cast to segfault. It happens when a
> ...details omitted...
>
> Red Hat 9, gcc 3.3, Boost 1.30.0:
You should upgrade your lexical_cast.hpp to the CVS ve
On Fri, 15 Aug 2003 12:36:52 +1000, Chris Trengove wrote
> I think the big issue in using random access iterators is whether
> you want to support the difference concept. It is relatively
> straightforward to implement, say
>
> year_iterator i(date(2003,1,1));
> year_iterator j(date(2005,1,1));
On Tue, 12 Aug 2003 22:15:28 -0700, Stephan T. Lavavej wrote
> [Dave Abrahams]
> > If I don't hear of any new problems with the RC_1_30_0 branch I'm
> > going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
>
> There's one little problem... it doesn't compile cleanly under
> -Wshado
> I've just installed 3.3.1 on Windows, and am getting those same four
> failure plus failures from:
>
> date_time/testmicrosec_time_clock (runtime failure)
This is likely due to the posix API call to std::time not providing
stable return values. That is, when I sample the time rapidl
On Tue, 12 Aug 2003 10:44:45 +1000, Chris Trengove wrote
> The date iterators in Boost Date-Time appear to be designed to
> support iteration forward in time, being modelled on the STL
> InputIterator. However, at times it is convenient to iterate
> backwards in time, and the temptation is just
On Thu, 7 Aug 2003 21:53:30 +0100, Paul A. Bristow wrote
> I have built the date examples OK, but I am getting a compile error
> when trying to build the time_math.cpp example with MSVC 7.1 aka
> .net 2003
>
> I:/boost_1_30_0\boost\lexical_cast.hpp(147) : error C2679: binary
> '<<' : no operato
On Sat, 9 Aug 2003 08:01:13 +0100, Paul A. Bristow wrote
> Please can you say why we need yet another file type? what is wrong
> with .cpp or .hpp?
In date_time the intent is to conditionally inline code for tuning
performance. I believe the first time I saw this used was in the ACE library
where
John -
Sorry to be slow on this reply...
John Torjo wrote:
> > > [1]
> > > unary operator-(time_iterator).
> > > Example: -hours(24) instead of hours(-24).
> > > (seems more straightforward)
> >
> > I see your point, but then don't you have to add all the other
> > operators for consistency? Not
On Tue, 12 Aug 2003 14:41:16 +0200, Martin Wille wrote
> a couple of libraries are regressing for gcc-2.95.3/Linux:
>
>date_time
I've been making a number of enhancements to date-time and that has caused
the test failures. The fixes for these have already been checked into CVS, so
the next
On Mon, 4 Aug 2003 20:17:03 -0700, Stephan T. Lavavej wrote
> time_duration behaves highly nonintuitively. A time_duration should
> be convertible to seconds by calculating td.hours() * 3600 +
> td.minutes() * 60 + td.seconds(), right? Wrong!
Hmm, I agree that this is not nice...
>...example o
On Sat, 9 Aug 2003 20:00:08 +0100, Paul A. Bristow wrote
> I suggest that I wait for the 30.1 release to be available, retest
> with strict mode and then mail you off-list with results from .net
> 2003 aka 7.1.
Do you mean 1.31.0 or 1.30.2? The changes I'm speaking of are not
in 1.30.2. I expe
On Wed, 6 Aug 2003 10:11:20 -0700, Stephan T. Lavavej wrote
> [Jeff Garland]
> > The downside of this is that when you are printing a time duration:
> > std::cout << td.hours() << ':' << td.minutes() << ':' << td.seconds();
> &g
On Mon, 4 Aug 2003 12:50:36 +0300, John Torjo wrote
> Told you I'd come back for more ;)
> Here are some more improvements I would consider useful:
>
> [1]
> unary operator-(time_iterator).
> Example: -hours(24) instead of hours(-24).
> (seems more straightforward)
I see your point, but then don
> > Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html
> > file in the date-time docs that was not checked in when 1.30 was released...
> > thus causing a broken link from the main page in the downloaded docs. I
> > believe Dave hacked the website to fix this, but it was
Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html
file in the date-time docs that was not checked in when 1.30 was released...
thus causing a broken link from the main page in the downloaded docs. I
believe Dave hacked the website to fix this, but it was still broken in
John Torjo wrote:
> I've been using date_time, and it's really cool!
Thanks.
> However, I would have a small request:
> For time iterators: we have hours(), minutes(), seconds(), but no days().
>
> Of course, instead of days(1) we can have hours(24), still I think it's more
> expressive to have
On Tue, 15 Jul 2003 19:19:08 +0200, Thomas Witt wrote
> David Abrahams wrote:
> > Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> > When we released 1.30.0, despite extensive pre-release testing, it
> > went out with several prominent showstopper bugs. Don't you think
> > we'll make the same mista
On Wed, 09 Jul 2003 09:33:44 -0400, Stefan Seefeld wrote
> hi there,
>
> what is the suggested way to persist a time_duration into a string ?
> I tried 'to_iso_string' but there is no corresponding
> 'duration_from_iso_string'. Shouldn't that exist (if only for
> symmetry) ?
Yes it should be th
> > I don't know about the other libraries? Is there a standard for this in
> > boost or is it up to the libraries? Should they be commonised?
Thorsten Ottosen wrote
> Ideally, yes. I would prefer .c_str() for const char* conversion and
> str() for std::string
In date-time there are several
On Thu, 26 Jun 2003 11:33:19 -0400, Philip Miller wrote
> The date_time reference manual seems to be available only at
>
http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/index.html.
> Unfortunately, there are times when I need to look at the reference
> manual without an internet
On Thu, 26 Jun 2003 14:35:26 -0400, Philip Miller wrote
> I am trying out the boost 1.30.0 date_time library and am quite pleased
> with it. I just came across a "feature" on which I would appreciate
> some help. There is an asymmetry when converting a ptime to/from a
> simple string. The to_sim
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 abo
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 a
> >From: "Philip Miller" <[EMAIL PROTECTED]>
>
> > Now, the reason for my posting. I am using MSVC 7.0 and am unable to
> > compile the date_time library tests. Compiling time_parsing.hpp gives
> > me an error in lexical_cast, where there is no output operator for the
> > lexical_cast compiled f
> On Mon, Jun 23, 2003 at 06:53:28AM -0700, Jeff Garland wrote:
> > [snip]
> > Ok will do. I'll add some protections or rounding for when durations
> > support higher than microsecond resolution. I'll let you know when
> > this gets added.
>
&g
S. Seefeld wrote
> I'd suggest these two converters to be added:
>
> timeval to_timeval(const ptime &t)
>...
>
> timeval to_timeval(const time_duration &d)
>...
>
> the latter is especially useful as select() operates with durations,
> so there is no need to convert between 1970-01-01 relative
> I note that boost::posix_time supports on certain platforms
> the generation of a ptime from a timeval (using gettimeofday()).
>
> I have a time class in my own project which can be cast from/to
> timeval, so I can use it in conjunction with calls to 'select()',
> which expects a timeval pointe
On Thu, 19 Jun 2003 17:15:11 -0400, Stefan Seefeld wrote
> little precision:
>
> the posix_time::time_duration type seems to come close to
> what I want. However, the documentation isn't very clear on
> what 'fractional_seconds()' actually stands for.
fractional_seconds is a count. It is relativ
On Sun, 15 Jun 2003 12:55:04 +0100, John Maddock wrote
> Again subject says it all, please fix and apply an existing boost
> licence if possible
Done.
Jeff
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Synge -
I have applied a fix that is equivalent to your patch. Let me know if it works.
Sorry to be so slow on this...
Jeff
> -Original Message-
> [mailto:[EMAIL PROTECTED] Behalf Of Synge Todo
> Sent: Thursday, May 29, 2003 10:15 PM
> Subject: [boost] patch for date_time library
>
>
Jonathon T. wrote:
> I have several class templates for producing standard streambufs based on
> classes with read, write and seek functions (or a suitable subset thereof.)
> I have used them successfully to access tcp connections, cryptographic
> routines, OLE compound documents, zip files,
John M. wrote:
> The bcp utility is a tool for extracting subsets of Boost, it's
> useful for Boost authors who want to distribute their library
> separately from Boost,
> and for Boost users who want to distribute a subset of Boost with
> their application.
John -
Many thx for doing this, I'm
Andreas - good to see your submission. I briefly scanned it, and it looks
good :-) I'm hope to find some time to play with it in earnest.
Just wanted to comment on the UML/SDL comparison. I won't try to summarize
and relate to the earlier points, but here are a few thoughts:
1) I have a collea
> I was just repeating myself here, I guess. I was basically saying it would
> be nice to be able to adjust big units (like months) backwards by small
> units (like days).
Well, you can take the iterator content and then do calculation with the
date:
...
date d = *date_itr;
date d2 = d -
Christopher Currie wrote:
>Hello,
>
>Attached is a quick patch to microsec_time_clock.hpp, which in CVS fails to compile
>under
>cygwin due to a missing header file. Please let me know if there’s something that I’m
>doing wrong here. I found the bug trying to build the socket library in boost-sa
On Thu, 17 Apr 2003 17:41:24 +0400, Vladimir Prus wrote
> I think that the filesystem library would very benefit from two functions:
>
> std::string extension(const boost::filesystem::path&);
> boost::filesystem::path change_extension(const
> boost::filesystem::path&, const std::str
> I get the following error when trying to compile
> date_time/microsec_time_clock.hpp from the current CVS with cygwin/gcc.
>
> C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse
> error
>before `;' token
I believe there are issues supporting the C interface used by the
> > I think this is a good addition, but we should probably make the
> > addition for all Win32 compilers since I think this is actually
> > part of the Win32 api.
> >
>
> I agree with that. Would it be better to make it a millisec_clock, or
> just use the microsec_clock but the resolution is o
> I read on the date_time change history about a new function for
> calculating ISO 8601 week number.
>
> I should note that this week number is rather useless without
> the corresponding year number. ISO 8601 week-based year is not
> always the same as the actual year. For example, 2nd January 19
> C++Builder doesn't currently support the microsec_clock of date_time
> because of its standard library. Would it be possible to add code to
> get the time using Win32 methods as this gives millisecond times?
I think this is a good addition, but we should probably make the
addition for all Wi
> gcc testgregorian_calendar.cpp -I/home/tony/work/boost_1_29_0/ -lstdc++
>
> It gives many linking problems, such as,
>
> /tmp/ccMBFqqI.o: In function `main':
> /tmp/ccMBFqqI.o(.text+0x154): undefined reference to
> `boost::date_time::gregorian_calendar_base
> long, unsigned short, unsigned s
rrectly constructed.
Reported by sourceforge bug: 628054 among others.
Last modified: Sun Feb 9 10:41:53 MST 2003
by Jeff Garland © 2000-2002
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> My patience has been exhausted. The folks that care about configuring
> lexical_cast for GCC 2.95.3 with the SGI library need come forward
Do you mean without? The regression tests with the SGI library look
fine...
> immediately and tell us how to
> OK, so how I ask for preliminary review? Posting a mail here?
Yes, you can just ask for preliminary feedback on this list.
Another thing you can do is put the code in the boost-sandbox.
This helps get things into the boost structure and allows other
boosters to keep up with changes as the lib
On Sun, 16 Mar 2003 17:34:18 -0500, Beman Dawes wrote
> I'll go over the do-list again after dinner, but it looks like
> almost all problems have been cleared except for this one.
I don't know if the Linux results are up to date, but
it appears that we have still taken a step backward with
lexica
On Sun, 16 Mar 2003 18:17:19 -0700, Victor A. Wagner, Jr. wrote
> it APPEARS that some library is needed. What this library is, I do
> NOT know.
The Jamfile under libs/filesystem/build builds a library called
libfs. There is a mention of this in the 'Do-List' page, but
it looks like the docs
All -
I'm posting this review (with permission of the author) that
was not posted on the list during the review. This review was
considered as part of the library acceptance. Anyway, the review
may be of interest to other variant users as it is quite detailed
and implements a novel use of varia
> Well, it was my intention then to probe the Boost community for interest
> in the library, and my impression was it raised little impetus.
Ok, well I would be interested in seeing this in boost. A
project I am working on would have benefited from a birectional
map and it seems like a pretty ha
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
Message/1558173
F. Cacciola http://aspn.activestate.com/ASPN/Mail/Message/1541664
R. Richter (private email).
Thanks to all the reviewers.
Jeff Garland
Variant Review Manager
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> >The multiple merge thing is probably much less of an issue when
> >working from trunk to branch, but it still could be useful to have
> >the tag. I would call the tag "merged_to_".
>
>OK, I'll add that to the procedure.
>
> >Does that clear up my concern?
>
>Yes, thanks. I'll aim to get the n
> > What is the point of that? How are the tags used?
>
> The point is that if there are multiple merges from the trunk to the
> branch, you'll need something to mark the version on the trunk of the
> previous merge. At the point you first create the branch, the
> previous merge point is the same
> No one disagreed with this assessment.
>
> Jeff Garland posts a partially updated set of developer procedures:
> http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm
>
> At this point the discussion fragments into details and corner cas
> Phil,
>
> On Monday 03 March 2003 23:28, Phil Nash wrote:
> > This request seems to have been left up in the air. I know that many are
> > busy with the release schedule, and there is an identified shortage of
> > review managers, but it would have been nice to have at least acknowledged
> > th
The Variant Review is now closed. Thanks to all who participated.
I will be collating the results and will post them in the next
few days.
Jeff
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
All -
This is a reminder about the variant formal review. The
review period was scheduled to end on Tuesday Feb 25th,
but since we got a late start I have asked and received
additional time from the review wizard. The review is now
scheduled to end Sunday March 2nd.
The variant library offers a
> Thanks Jeff. All tests but one now pass for VA!
>
> testmicrosec_time_clock fails for VA6 with one single failure out of
> 150. It works ok for VA5, though...
It might be a spurious failure. As you can imagine testing
clock measurements is a bit dicey. That particular test
takes a bunch of
> I think I'm inclined to take Dave's last suggestion, rename
> the template function and remove all the macros.
I've checked this change into CVS -- removing all dependencies
on std::abs. This should clear this up once and for all
and removes all the macro hackery. And now, hopefully, this
wil
Dave A. wrote:
> > AFAICT the logic is backwards: you should assume there's no
> > std::abs which works on long long and use your own function by
> > default, only using std::abs if the compiler is *known* to support
> > that extension... if it's even worth the trouble (it'll be less
> > code to
> >Take a look at bosot/date_time/compiler_config.hpp which
> >does something similar. All we need to do to fix these regressions
> >is add the compiler to the list of those that don't have std::abs
> >at line 34.
>
> Based on the above, I've bump the VC++ version up to 1310 to cover version
> The problem is, VA _has_ std::abs. You just need a specialization for
> long long then.
>
> namespace std {
> template<> long long abs(long long n) { return llabs(n); }
> }
>
> Don't know if this is legal, though.
How about just skipping the template:
#ifdef _VA_WHATEVER_COMPILER_MACRO_IS
n
> Many of the regression tests for the date time library are failing
> currently because the library relies on std::abs being
> available. AKAIK, the C++ standard doesn't require this so the library
> shouldn't make use of it.
>
> Maybe datetime should specify it's own version of abs like this:
> >We don't want to stick all of the generated HTML into CVS (too big).
>
>If it is too big for the regular CVS, isn't it too big for the >distribution
too? How big is big?
This is a radical idea, but maybe that's what's needed.
What if we did this:
1) Create a new CVS repository ala the sandbox
> I don't know exactly what you mean by "non-trivial sever" and what you
> get from ACE/expect not to get from Boost.Socket that a non-trivial
> server requires?
Depends on the server, CDR formatting, thread-safe queues come to mind.
There are probably a few threading things as well. Of course
All -
Today is the start of the formal review of the Variant library
by Eric Friedman and Itay Maman. The review will run until
Tuesday Feb. 25th. I will be serving as review manager.
The variant library offers a simple, type-safe solution for
manipulating an object from an inhomogeneous set o
At Friday, 14 February 2003, you wrote:
>So I'm proposing we spend Saturday and Sunday trying to clear regression
>test problems, and then branch-for-release Monday around noon Eastern
US
>time, (5PM UTC).
>
>Comments?
Works for me
Jeff
__
> On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
> > So in summary, I think we should focus the Boost.Socket effort
> > on what is currently described as 'level 1 - OS platform layer'
> > and 'level 2 - basic connectivity layer' leaving m
First, let me just say thanks to all the regression testers -- this
is really a critical asset to boost developers. And the new summary
page is very helpful and the addition of the age is very nice!
I have a small request. Please send me test results for the
date_time testmicrosec_time_clock tes
...various comments about ACE from various authors
> >> [...]
> >> How about borrowing ideas from ACE, but implementing them in
> >> modern C++? Or has that been discussed already? Or is the ACE
> >> framework too obsolete-C++ to be a useful design?
> >
> > We probably should at least consid
Scott K wrote:
> Hi all,
> I have a small family of statistics classes which I have used from time
> to time. The one I use most often is simply called stats.
> Here's an example of it's use:
> ...details snipped...
I'm sure there are folks interested in statistical (and other)
functions. I've d
> execute-test
> ..\status\bin\testdate_iterator.test\vc7\release\runtime-link-dynamic\testda
> te_iterator.run
> == BEGIN OUTPUT ==
> Pass :: base iterator
> 20020101 20020102 20020103 20020203
> Pass :: day iterator -- 2 days
> Pass :: day iterator -- 2 days
> Pass :: day iterator -- 2 da
> > Curiously the one failure for date-time
> > was in handling of big time durations. The failure is
> > probably an overflow problem, which can happen if you try
> > to use a plain 32-bit integer to get nano-second resolutions
> > and large time durations. Nano-second resolution is the default
> Another problem is that the type long long exists but is not supported
> by the standard library (e.g. the operator <<(std::ostream&, long long)
> is not defined). Since long and long long are both 64 bit there is
> actually no need to ever use long long. I'll have to check why long
> long is
1 - 100 of 155 matches
Mail list logo
