[boost] Boost::filesystem : compile trouble on Sun Solaris
Using the sunpro toolset I get a strange error when compiling the boost::filesystem library (and thus all regression testing fails). Below you can find the error diagnostics. It comes down to an ambiguous overload of boost::operator==<...> but the two operator=='s (reported in the error message) are identical ! So why is this ambiguous ? I've been trying to find out where the operator== for directory_iterator is implemented. Seems that it comes from the iterator_facade. Also the header containing the iterator_facade declaration mentions support for operator== but still I do not grasp where the operator== is implemented. Maybe one of you can give me a hint where to look. Thanks in advance, toon bjam_filesystem.log Description: Binary data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] arithmetic traits
Arithmetic traits can be found in ublas. Just look for promote_traits in the ublas headers. > > I'm thinking that it would be useful to implement a traits > class that > > would > > give the return type of mixed scalar-complex arithmetic > operations. This > > would allow one to write generic algorithms that operate on > both scalar and > > complex types, inferring the return type. > > > Any opinions? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Tools/regression/run_tests.sh
I have adapted the run_test.sh in boost/tools/regression to take the ALL_LOCATE_TARGET into account. This requires following changes: $process_jam_log $ALL_LOCATE_TARGET < regress.log Instead of Cat regress.log | $process_jam_log (the latter also causes a warning since process_jam_log expects arguments) Additionally, compiler_status will need the extra command-line arguments : --local-root $ALL_LOCATE_TARGET This would make the script run without a problem when ALL_LOCATE_TARGET would be defined in the environment. But what if ALL_LOCATE_TARGET is not defined, the script will not function correctly anymore. So ideally there should be a way to test the ALL_LOCATE_TARGET env.var. and define it to $boost_root otherwise but I'm not sure how to do that. Rene ? Toon (btw, rene I did not mail you directly as I know you're automatically filtering your incoming mail) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problems with CVS?
> If you are accessing CVS via SSH (developer), you should not have any > problem. In fact CVS access has been very fast and reliable > lately for me > doing SSH access. Not for me. :ext: access using SSH is certainly less unreliable but it's not reliable at all. But this might be different in europe and the US (I understood from the SourceForge guys that they have mirrored servers in europe) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] is_nan
> seems like this code
>
> template< typename T >
> bool is_nan( const T& v )
> {
> return std::numeric_limits::has_quiet_NaN && (v != v);
> }
>
> does not work correctly on some machines.
Could you be more specific. On which machines for instance ?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Cvs trouble
The boost-sandbox is showing some strange behaviour. When checking out the boost-sandbox/numeric/bindings/traits/type.h using the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's only 1.2. The WebCVS also only shows up to version 1.2. Could others with both :ext: and :pserver: access confirm this ? (I must be doing soth wrong here because this is too crazy but there are no branches, I've updated using '-APCd' and all ) RCS file: /cvsroot/boost-sandbox/boost-sandbox/boost/numeric/bindings/traits/type. h,v Working file: type.h head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 3; selected revisions: 3 description: revision 1.3 date: 2003/06/23 16:12:01; author: tknapen; state: Exp; lines: +20 -2 new type conversions revision 1.2 date: 2003/06/03 14:38:28; author: tknapen; state: Exp; lines: +9 -4 made include guards uppercase revision 1.1 date: 2002/10/25 20:42:28; author: tknapen; state: Exp; another rework by Kresimir = RCS file: /cvsroot/boost-sandbox/boost-sandbox/boost/numeric/bindings/traits/type. h,v Working file: type.h head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: revision 1.2 date: 2003/06/03 14:38:28; author: tknapen; state: Exp; lines: +9 -4 made include guards uppercase revision 1.1 date: 2002/10/25 20:42:28; author: tknapen; state: Exp; another rework by Kresimir = ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] sequence_array contribution
On Thursday 22 May 2003 12:51, Maarten Hilferink wrote: > template struct sequence_array; > which has an interface that is almost compatible with > std::vector >; > but faster. and more compact I presume. AFAICT the drawback will be that the sequece is not as dynamic anymore as a vector-of-vectors (vov) > template struct sequence_array; > that uses an internal > std::vector m_Data; > for sequencial storage of sequences of T > and an additional > std::vector > m_Seqs; > for identifying allocated sequences. But isn't always gauranteed : m_seqs[i].second == m_seqs[i+1].first ? In this case you could shrink the memory footprrint with another pointer per innter vector. > sequence_array offers typedef iterator, const_iterator, reference, and > const_reference > with interfaces nearly compatibe with > std::vector*, const std::vector*, vector&, resp. const vector&. > (the sequences however don't have a reserve() member function, Why not ? I have something similar as you and definitly need reserve. But my reserve takes two arguments : the number of internal vectors (will reserve m_seqs) and the storage consumed by all internal vectors (will reserve m_data). > For the discussion, I have made my pre-boost facilities library available > at: > http://www.objectvision.nl/dms/downloads/rtc-src-2003-05-21.zip > It contains the file GeoSequence.h, which contains the > template struct SequenceArray; > I specifically would like to hear from you on the following design issues: > - I am considering to change the definition of the above mentioned m_Seqs > to: > std::vector > m_Seqs; > where m_Seqs[i].first and second are offsets of the start and end of > sequence i relative to m_Data.begin(). > This avoids adjustment when m_Data grows, for a small const access-time > penalty. In my implementation, I allways recalculate m_seqs when m_data grows. But you would need to perform profiling to know what's best actually. > 1. Arye you interested in such contribution? I am but need to make sure it provides enough performance for my specific case. > 3. Do you know of other solutions for efficient management of > sequence_arrays? vector-of-vectors with your home-brewn allocaters (using a pool for instance). > 4. Is my assumtion true that the above described behaviour could not have > been created > by using a smart allocator as a second template argument to std::vector? > (I assumed this since allocators cannot have a vector instance specific > state) oops, see question 3 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] --comment option for compiler status tables
On Friday 23 May 2003 18:15, Beman Dawes wrote: > Hopefully other regression testers will supply appropriate comment files > for their setups. I've also added this to the very handy run_tests.sh script of Rene (is that OK Rene ?) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Should regression summary consider both pass and warn aspassing?
On Sunday 25 May 2003 23:18, Beman Dawes wrote: > I think that Greg Comeau has a good point in his email below - reporting > separate pass / warn / fail statistics in the regression summary can be > misleading to naive readers. > > On the other hand, we certainly want to continue to report warnings in the > tables themselves. > > So it seems to me that in the summary we should lump "pass" and "warn" from > the tables together into a single "pass" category in the summary. > > Opinions? The number of warnings also provides valuable information but indeed it's not as important as the Pass/Fail categories so this needs to be communicated to the viewers as well. But how ? I support the suggestion of Greg indicating something like: Pass: 67% (3% warning) | Fail (33%) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Should we refine boost::timer
On Wednesday 21 May 2003 14:39, Jeff Garland wrote:
> Did you look at the attached test program which had this traits adapter?
nope. I must have missed that although I check all attachments (I think)
> static time_duration_type make_time_duration(time_rep start, time_rep end)
> {
> assert(CLOCKS_PER_SEC == time_duration_type::rep_type::res_adjust());
> return time_duration_type(0,0,0, end - start);
> }
I think the traits are too dependent on the time_duration_type coming from
the date-time library. It should be possible to reset the elapsed time using
a default-constructed time_duration_type and set the a time_duration_type
using an operator= instead of the constructor with 4 arguments.
But these are details that can be solved when making real-life
specialisations. So back to the overall strategy :
I think it's a good idea to provide a templated timer that can be
specialised for timing cpu-time or wall-clock time. The template-argument
however should be allowed to have different implementations
on different platforms. E.g. as I mentioned before, the clock()
function wraps around too quick. On 32-bit POSIX systems
(CLOCKS_PER_SEC must be 1M) you have a wraparound every 72 minutes.
So I would for instance implement the cpu-timer using getrusage (on linux) etc.
> That assumption really limits the use of the timer. For example,
> you can't use it in a user interface where a start/stop button
> can be controlled by a user to measure the total elapsed time on
> a task that might be interupted. For program timing there might be
> sections of the program execution I would like to ignore. This is
> not possible without a stop function.
OK, agreed.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] NO_MEMBER_TEMPLATE_KEYWORD on HPUX
Looking at
http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#cast_test acc
you could say that aCC supports no member template keywords.
However, the code sample at the bottom compiles fine ?!
Nevertheless, I'd like to add the patches in attachment to take
the 53800 version of HP_aCC into account, set the
BOOST_NO_MEMBER_TEMPLATE_KEYWORD
and disable the pthreads.
#include
template < bool b >
class if_true
{
public:
template < class Y, class N >
struct then { typedef Y type ; } ;
} ;
class B : public if_true< true >
:: template then< int, double >
{
} ;
int main()
{
std::cout << __HP_aCC << std::endl ;
B b ;
return 0 ;
}
Index: hpux.hpp
===
RCS file: /cvsroot/boost/boost/boost/config/platform/hpux.hpp,v
retrieving revision 1.10
diff -r1.10 hpux.hpp
25,31d24
< // HPUX has an incomplete pthreads implementation, so it doesn't
< // define _POSIX_THREADS, but it might be enough to implement
< // Boost.Threads.
< #if !defined(BOOST_HAS_PTHREADS) && defined(_POSIX_THREAD_ATTR_STACKADDR)
< # define BOOST_HAS_PTHREADS
< #endif
<
Index: hp_acc.hpp
===
RCS file: /cvsroot/boost/boost/boost/config/compiler/hp_acc.hpp,v
retrieving revision 1.13
diff -r1.13 hp_acc.hpp
39a40,43
> #if (__HP_aCC <= 53800 )
> #define BOOST_NO_MEMBER_TEMPLATE_KEYWORD
> #endif
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
On Thursday 13 February 2003 22:56, Rene Rivera wrote: > [2003-02-13] Beman Dawes wrote: > > >At 12:35 PM 2/13/2003, David Abrahams wrote: > > > > >Whatever we do with color, most of the text that needs to be readable > > >should be black on white. That's been shown to be most readable for > > >most people, on average. > > > >That's a good point. Color-blind people may have trouble with anything that > >depends purely on color to convey information. > > Yes, good point. > > OK, I've made some changes to the page... Added an "Age" column, removed > green from the age color scheme, and moved the age color scheme to the age > column only. It looks good and provides instantly the most important info. Good job ! t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
On Wednesday 12 February 2003 17:38, Rene Rivera wrote: > [2003-02-11] Beman Dawes wrote: > > >At 09:01 AM 2/10/2003, Toon Knapen wrote: > > > > >I think the traffic-light colors should suffice. I find adding black > > >confusing. > > > >I agree. The traffic-light metaphor falls apart when you add black. > > Yea, but black is used in the regresion tests themselves. How does it not > fall appart there? you've got a point there ! > Do we just get rid of black, and the 48 hour test become green? Or is there > some better way to show age? I would suggest to just use 3 colors : or black, yellow and red or green, yellow and red using both green and black is confusing. These colors should be used for the both the regression overview as well as the regression-logs per platform IMHO toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
On Saturday 08 February 2003 00:26, Rene Rivera wrote: > >If the old run is no longer relevent (as run date October 17 suggests) > >who would be responsible for removing it? > > I would think the person who ran the test, or Beman, or David, or any admin, > etc. These are results from compilations by Markus Shoepflin on VisualAge version 5. For a long time, he has not updated them anymore so let's ask him (he's in CC) > >> I've been trying to figure out a good way to show that some test are > newer > >> than others, because sorting by date is not possible, and I like that > >> suggestion very much :-] I'd prefer a bit more granularity than you > suggest > >> though. How'bout this: > >> > >> GREEN -- tests ran in the last 48 hours. > >> YELLOW -- tests ran in the last 7 days. > >> RED -- tests ran in the last 14 days. > >> BLACK -- tests are older than 14 days. > > > >I tend to like default (black) text to indicate there is no error, and > >only colour-code things that need attention. In your scheme it is the > >reverse, black being an 'abandoned' test suite. > > Ah, sorry that was my mistake. I really meant to keep your colors with just > the changed increments :-\ -- So it would be BLACK for 48 hours, and so on. I think the traffic-light colors should suffice. I find adding black confusing. Ideally the color green should only be used if the sources have not changed in the mean time so in general the colors depend on the amount of change between the sourced use for the test in respect to the sources in the CVS. But I can imagine that that's not possible or ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regression tests on Aix
I'm forced to halt my weekly updates of the Aix status pages for a while. Both machines we have are at the end of their lease and we're still discussing with IBM on the terms of a new machine. I hope the situation will be resolved quickly. Sorry for the inconvenience. still-commited-to-update-the-VisualAge-status-pages-at-least-weakly- and-assist-developers-ly yours. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Results of Cray SV1 regression tests
On Wednesday 05 February 2003 23:26, Matthias Troyer wrote: > On Wednesday, February 5, 2003, at 04:52 PM, Toon Knapen wrote: > > On Wednesday 05 February 2003 10:27, Matthias Troyer wrote: > >> After we get the regrssion tests to work, there will be a special > >> challenge for ublas or MTL-3: Calling the BLAS routine where > >> appropriate will be essential in getting any decent performance on > >> these types of CPUs. Does anybody know what the progress is on calling > >> BLAS from ublas where appropriate? > > > > The BLAS and LAPACK bindings for ublas are not complete yet but the > > most important functions are available. > > Great. Is this part of the boost CVS It's in the sandbox. If you're not familiar with the sandbox, drop me a line. > > > > Recently, Joerg started adding blocked operations (which deteriorate > > performance > > on vector-processors) so in the future we might need configuration > > macros to > > indicate if we're on superscalar or vector machines. > > That will indeed be useful once we start running large production codes > with sparse matrices on vector machines. For dense matrices the BLAS > calls should take care of the optimization? Again an advantage of using vendor-tune blas ;-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Do Jamfiles need copyrights?
Recently had a talk with a patent-laywer from Philips. I deduced following from this conversation (my own interpretation and IANAL) Copyright is automatic. From the moment you make something, you own the copyright (so actually no explicit copyright statement is necessary although it is advised). From the moment you change a file that is copyrighted by somebody else, copyright is shared (of course, generally the copyright does not allow you to make modifications) Now open-source projects (including boost) want to provide more rights to the user as the default copyright allows. So we add a copyright notice also indicating a license. This license is necessary to allow others to make modifications, distribute it etc. So that's why the boost source-code can be considered open-source. However if a Jamfile does not contain a license, default copyright-right apply and thus the Jamfile can not be distributed by others than the copyright-holder. So we certainly need to add a license statement and at the same time might indicate the copyright too (Indicating the license is still the most important aspect). On Wednesday 05 February 2003 23:18, Beman Dawes wrote: > At 01:16 PM 2/5/2003, Martin Wille wrote: > > >Beman Dawes wrote: > >> Bjorn Karlsson and I are wondering if Boost should require copyrights > on > >> Jamfiles. > > > >Jamfiles are part of the build system; they won't become part of > >a an executable. So everything is fine when a vendor ships a > >binary or a DLL. > > > >However, when Boost is incorporated to some other open source > >project, missing copyrights and licences might become a problem. > > > >Moreover, copyright statements hinder evil-doers to wrongfully > >claim ownership. > > > >I'm not a lawyer, so I'm just guessing, bit I think we should > >put copyrights into Jamfiles, Makefiles and the like as well. > > I'm convinced. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Fwd: Re: [boost] Results of Cray SV1 regression tests
On Wednesday 05 February 2003 10:27, Matthias Troyer wrote: > On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote: > After we get the regrssion tests to work, there will be a special > challenge for ublas or MTL-3: Calling the BLAS routine where > appropriate will be essential in getting any decent performance on > these types of CPUs. Does anybody know what the progress is on calling > BLAS from ublas where appropriate? The BLAS and LAPACK bindings for ublas are not complete yet but the most important functions are available. Recently, Joerg started adding blocked operations (which deteriorate performance on vector-processors) so in the future we might need configuration macros to indicate if we're on superscalar or vector machines. can't wait ! toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression: run_tests.sh
On Wednesday 22 January 2003 18:51, Rene Rivera wrote: > [2003-01-22] Toon Knapen wrote: > Ahh, maybe you should reread my post ;-) "0" is a successfull return for > "whence". A failure is anything other than zero, usually "1". Hence the > "whence foo", should return non-zero. but the build.sh still gives me biot:/home/tk/boost/boost/tools/build/jam_src> ./build.sh ### ### Using 'gcc' toolset. ### rm -rf bootstrap.gcc mkdir bootstrap.gcc gcc -o bootstrap.gcc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c ./build.sh[3]: gcc: not found. but whence indeed returns 1 if it's in the path : biot:/home/tk/boost/boost/tools/build/jam_src> whence foo biot:/home/tk/boost/boost/tools/build/jam_src> echo $? 1 biot:/home/tk/boost/boost/tools/build/jam_src> whence xlc /usr/vacpp/bin/xlc biot:/home/tk/boost/boost/tools/build/jam_src> echo $? 0 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression: run_tests.sh
> OK, I updated the script to prefer using "whence" to detect things in the > PATH. This should make it work for you. But to make sure could you see if > "whence" works in AIX any better... > > whence xlc 2>/dev/null ; echo $? > whence foo 2>/dev/null ; echo $? > > The expected result is: > > 0 > 1 > sorry to disappoint you (and me) biot:/home/tk/boost/boost/tools/build/jam_src> /bin/sh biot:/home/tk/boost/boost/tools/build/jam_src> whence xlc /usr/vacpp/bin/xlc biot:/home/tk/boost/boost/tools/build/jam_src> echo $? 0 biot:/home/tk/boost/boost/tools/build/jam_src> which xlc /usr/vacpp/bin/xlc biot:/home/tk/boost/boost/tools/build/jam_src> echo $? 0 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost and HPUX with aCC
On Tuesday 21 January 2003 18:43, Andrea Minuto wrote: > I need the boost library for HPUX platform and aCC compiler (3.3.x). Include the necessary boost-headers in your project and see if it works. Don't forget to use the '-AA' option because otherwise I'm almost sure it won't work. You can also check out the status-pages for HP (and other platforms/compilers) at : http://boost.sourceforge.net/regression-logs/ > I search the binary or the rules to compile the library.. Most of boost is implemented directly in the headers so don't worry now about building a boost-library. If you need it later in the process, we'll get you going. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression: run_tests.sh
> So it could be that the "hash" command doesn't work in AIX as I expected. To check I first go to a sh (I'm in ksh by default) to check if my PATH is propagated. The 'which' shows indeed that this is the case. However the 'hash' command has a zero-return (I did not know it but I suppose it's supposed to return a non-zero or ...?) biot:/home/tk/boost/boost/tools/build/jam_src> /bin/sh biot:/home/tk/boost/boost/tools/build/jam_src> which xlc /usr/vacpp/bin/xlc biot:/home/tk/boost/boost/tools/build/jam_src> hash xlc biot:/home/tk/boost/boost/tools/build/jam_src> echo $? 0 biot:/home/tk/boost/boost/tools/build/jam_src> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression: run_tests.sh
On Tuesday 21 January 2003 16:30, Rene Rivera wrote: > BUt I can't figure out why it doesn't detect the toolset? All the build.sh > does is check to see if "xlc" is in the path. I can confirm that xlc is in the path. So that's not it. Note though that calling 'xlc' without arguments will launch the manpages and thus you need to type 'q' to get to your prompt again. > Or do you mean that it uses > some other toolset to build bjam? Nope, no gcc is installed so it uses xlc or xlC. t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP regression tests
On Tuesday 21 January 2003 12:42, John Maddock wrote: > I missed that, the || !defined(BOOST_STRICT_CONFIG) part should not be > present against a version check that is clearly not the most recent > compiler version. Looks like we need someone to run the configure script > on the most recent compiler version and report the results. Here's the output of a ./configure run. It's substantially different from the current hp_acc.hpp though ;-?? *** ./configure: boost configuration utility *** Please stand by while exploring compiler capabilities... Be patient - this could take some time... Note that this test script only gives an approximate configuration - you will need to test the results carefully using the boost regresion test suite before using the results. *** Info : .cpp used as extension for tests checking for boost main tree... ./../.. checking for C++ compiler default output... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... no checking whether aCC accepts -g... yes checking for pthread_exit in -lpthread... yes checking for cos in -lm... yes checking for clock in -lrt... no checking Koenig lookup ... OK checking std::auto_ptr ... OK checking Full partial specialization support. ... OK checking functions in ... OK checking template specialisations of cv-qualified types ... OK checking template specialisations of cv-qualified void ... OK checking and ... OK checking and ... OK checking deduced typenames ... OK checking dependent nested template classes ... OK checking dependent non-type template parameters ... Failed checking is in namespace std ... OK checking exception handling support ... OK checking non-deduced function template parameters ... OK checking no function template ordering ... OK checking std::numeric_limits<__int64> ... OK checking inline member constant initialisation ... OK checking long long and integral constant expressions ... OK checking template iterator-constructors ... OK checking ... OK checking compile time constants in ... OK checking std::numeric_limits ... OK checking Specialisation of individual member functions. ... OK checking member templates keyword ... OK checking member template friends ... OK checking member templates ... OK checking friend operators in namespace ... OK checking partial specialisation ... OK checking private in aggregate types ... OK checking pointers to const member functions ... OK checking detection of unreachable returns ... OK checking ... Failed checking std::allocator ... Failed checking std::distance ... OK checking std::iterator_traits ... OK checking std::iterator ... OK checking std::locale ... OK checking std::messages ... OK checking std::min and std::max ... OK checking That the std output iterators are assignable ... OK checking std::use_facet ... OK checking std::basic_streambuf ... OK checking std::wstring ... OK checking std:: namespace for C API's ... OK checking swprintf ... Failed checking template template paramters. ... Failed checking using template declarations ... OK checking no void returns ... OK checking intrinsic wchar_t ... OK checking two argument version of use_facet... no checking BeOS Threads... no checking clock_gettime... Yes checking ... Yes checking GetSystemTimeAsFileTime... no checking gettimeofday... Yes checking and ... no checking long long... Yes checking macro version of use_facet: _USE... no checking __int64... no checking nanosleep... Yes checking ... Yes checking Named return value optimisation no checking limited std::allocator support... Yes checking pthread_delay_np... no checking pthread_mutexattr_settype... Yes checking pthread_yield... no checking POSIX Threads... Yes checking sched_yield... Yes checking SGI style ... no checking ... no checking stdint.h... no checking STLport version of use_facet... no checking ... Yes checking microsoft member templates... Yes checking microsoft's version of std::iterator... no checking MS Windows threads... no boost_base=./../.. checking original configuration ... done checking new configuration ... done configure: creating ./config.status config.status: executing default commands Adjustments to boost configuration have been written to user.hpp, copy this to boost/config/user.hpp to use "as is", or define BOOST_SITE_CONFIG to point to its location. TREAT THIS FILE WITH CARE. Autoconf generated options are not infallible! // (C) Copyright Boost.org 2001. // Do not check in modified versions of this file, // This file may be customised by the end user, but not by boost. // // Use this file to define a site and compiler specific // configuration policy, this version was auto-generated by // configure on Tue Jan 21 16:56:34 WET 2003 // With the following options: //CXX
[boost] regression tools
I can't compile the regression tools anymore on HP because psetid_t is not known. This is however defined in /usr/include/sys/types.h. I've no thread experience (I used distributed parallellism only) so I prefer someone else to make the necessary modif. gcc-C++-action ../../../libs/filesystem/build/bin/libfs.a/gcc/release/runtime-link-dynamic/operations_posix_windows.o In file included from /usr/include/pthread.h:7, from /home/tk/boost/boost/boost/detail/lwm_pthreads.hpp:19, from /home/tk/boost/boost/boost/detail/lightweight_mutex.hpp:83, from /home/tk/boost/boost/boost/detail/shared_count.hpp:27, from /home/tk/boost/boost/boost/shared_ptr.hpp:27, from /home/tk/boost/boost/boost/filesystem/operations.hpp:26, from ../../../libs/filesystem/src/operations_posix_windows.cpp:28: /usr/include/sys/pthread.h:1039: `psetid_t' was not declared in this scope /usr/include/sys/pthread.h:1039: parse error before `,' token ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regression: run_tests.sh
Rene, On IBM build.sh does not detect automagically that its supposed to use vacpp. So If you add $toolset (as shown) to the call to build.sh in run_tests.sh it works fine : LOCATE_TARGET=bin sh ./build.sh $toolset toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
> By "versioned" do you mean committed to CVS? Yes. > Not on a daily basis, because > of the space implications. of course. > OTHO, it is nice to have a set in CVS at the > time of each release. That was my intention. To have a status page for every release. Currently boost/status/compiler_status.html actually always points to the status of the CVS (indeed the regression system version 2 was used for the last release and only therefor there's a distinction between CVS and release status pages). So I would suggest that this page has one link per comiler. But at the release we rename the files on sourceforge (e.g. cs-aix.html would become cs-aix_rev_1_30.html). This would mean that the status page for the release is stable. The status pages that will be updated daily after the release still will be called cs-aix.html. Opinions ? t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
On Monday 20 January 2003 18:16, Rene Rivera wrote: > >No need to. I have to correct some stuff anyway. Just tell me how I need > > to name my files. I also added the trailing '6' but I'm not sure the > > status pages for 5 will be updated and thus the '6' may become > > irrelevant. > > Sure, the matching is now very simple it looks for a file of the form: > "*links*.html". Which it matches to its correponding "**.html". As long as > it matches that it will attempt to display the summary. OK. Now my question is (mostly to Beman) : Are status-pages also supposed to be versioned ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: regression tests on Aix
> It picked "cs-vacpp-links.html", there is no "cs-aix-links.html" ;-) > > What it did not pick was the "cs-vacpp-links_6.html", and that's because of > the extra "_6". If those where "cs-vacpp6-links.html" and "cs-vacpp6.html" > it would parse those. Oops I noticed in serious problem in the updates of the Aix status pages. The cs-vacpp-6-full.html has been updated almost every week but cs-vacpp_6.html was not updated (last update in octobre ;-( > > I'll see if I can change the detection to handle those types of cases. No need to. I have to correct some stuff anyway. Just tell me how I need to name my files. I also added the trailing '6' but I'm not sure the status pages for 5 will be updated and thus the '6' may become irrelevant. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Monday 20 January 2003 14:03, Matthias Troyer wrote: > On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote: > > If you can test and supply patches they would be much appreciated, > > come to > > that, I don't suppose you would like to volunteer to regularly run the > > regression tests on that platform would you (no problem if you can't > > though)? Testing on Cray would be useful if only because the > > architecture > > is so different from the usual 32-bit platforms we test on. > > I tried to run the regression test but the first problem I encountered > is that jam does not seem to work on a Cray machine: > And what happens if you use make directly ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Monday 20 January 2003 03:14, Rene Rivera wrote: > In order to make regression test browsing more pleasant for all of us. I > decided to work up a little script to gather up all the test results that > get posted to the boost.sourceforge.net site. So browse on over to: > > http://boost.sourceforge.net/regression-logs > > ..and take a look. Very very handy ! Did you put the link also in the doc in CVS somewhere ? t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Monday 20 January 2003 03:14, Rene Rivera wrote: > In order to make regression test browsing more pleasant for all of us. I > decided to work up a little script to gather up all the test results that > get posted to the boost.sourceforge.net site. So browse on over to: > > http://boost.sourceforge.net/regression-logs > > ..and take a look. > > And for those doing regression testing, this a zero maintenance page. Just > put up the cs-PLATFORM*.html files in there and they'll automatically show How come it picked up cs-aix.html and not cs-vacpp6.html. The latter is the one generated by the new regression test system, the former is still the old one. I can however rename the latter to cs-.html but since the same link is used in the 1.29 release, the status does not correspond with the code at that time anymore ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression tests for aCC are up
On Friday 17 January 2003 11:28, Rene Rivera wrote: > [2003-01-17] Toon Knapen wrote: > >On Friday 17 January 2003 12:32, John Maddock wrote: > >> So only the gcc tests will be run, I assume that you have some detritus > > in > > >> bin directory from previous HP aCC runs, which is why you are seeing > >> some results listed. Add the necessary toolset(s) to test_tools. > > > >Thanks John. Had some other minor trouble but finally it worked. > > What are the minor troubles? Are they with the run_test.sh script? Are they > with the BJam build.sh script? Something else? Basically anything we should > point out to people and/or try and fix? I've been struggling a bit with it so next time I'll update the status I'll start from scratch and make sure to notify all involved of the changes I had to make to make it work. Last time there were many minor issues and I lost track of them. Thanks for offering your help. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
On Friday 17 January 2003 11:07, David Abrahams wrote: > Toon Knapen <[EMAIL PROTECTED]> writes: > > On Friday 17 January 2003 14:59, David Abrahams wrote: > >> No, please restore that feature. The build system offers no > >> guarantees about the order in which specified libraries will be added > >> to NEEDLIBS, and we'd rather work in all circumstances than save > >> whatever miniscule amount of link time it takes to deal with the > >> repetition. > > > > Done. > > Nevertheless I use bjam also for my own project (as you might know) and > > there I've always removed the duplication because I don't want to allow > > developers to create circulare dependencies. And the system has worked > > fine (thanks again jamboosters) > > It's not just about circular dependencies. If library A depends on > library B, when you link them into an executable there's no guarantee > that they'll appear in the right order. OK but I never had any trouble with it so far (although NEEDLIBS is only used once in my linkline to prevent people from creating circular dependencies) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regression tests for aCC are up
On Friday 17 January 2003 12:32, John Maddock wrote: > So only the gcc tests will be run, I assume that you have some detritus in > bin directory from previous HP aCC runs, which is why you are seeing some > results listed. Add the necessary toolset(s) to test_tools. Thanks John. Had some other minor trouble but finally it worked. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
On Friday 17 January 2003 14:59, David Abrahams wrote: > No, please restore that feature. The build system offers no > guarantees about the order in which specified libraries will be added > to NEEDLIBS, and we'd rather work in all circumstances than save > whatever miniscule amount of link time it takes to deal with the > repetition. Done. Nevertheless I use bjam also for my own project (as you might know) and there I've always removed the duplication because I don't want to allow developers to create circulare dependencies. And the system has worked fine (thanks again jamboosters) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
On Friday 17 January 2003 13:55, David Abrahams wrote: > Toon Knapen <[EMAIL PROTECTED]> writes: > > In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next > > $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS > > typically contains other libs in the same project (==boost) whereas > > FINDLIBS typically contains external and/or system libs. NEEDLIBS is thus > > very likely to depend on FINDLIBS and thus needs to be in front of > > FINDLIBS. > > > > (I remember to have made the same remark about the link-line in > > gcc-tools.jam but still wanted first an 'OK' of everyone involved) > > I think you're right; it's OK with me if you change it. Done. I've also retained only one of the two NEEDLIBS (all libs appeared twice in the link-line). Is that OK ? This would only be necessary in case there would be circulare dependencies and I'm sure a well designed project like boost does not suffer from circular dependencies ;) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] intel-linux-tools.jam
In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS typically contains other libs in the same project (==boost) whereas FINDLIBS typically contains external and/or system libs. NEEDLIBS is thus very likely to depend on FINDLIBS and thus needs to be in front of FINDLIBS. (I remember to have made the same remark about the link-line in gcc-tools.jam but still wanted first an 'OK' of everyone involved) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression test on HP-UX
On Sunday 12 January 2003 13:32, John Maddock wrote: > > Rene, how can I get the aCC compile to work (it's reporting "Missing" the > > whole time as you can see) > > Likely options: > > 1) the HP results aren't being filtered through process_jam_log. > 2) you ran out of disk space and the targets weren't built. > 3) some other bjam invocation problem. > > Can you post the actual script you used to run the tests? It's the run_tests.sh with minor modifs. I also attached the output. run_tests.sh Description: application/shellscript hpux_run_tests.out.gz Description: GNU Zip compressed data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Hello MPL world
I've been looking through some real code to see where we pactically could
benefit from MPL and think I've found a nice one :
If one wants to integrate generic programming inside a strong OO designed
program, you might want to try to downcast a pointer to a base-class to all
possible derived-classes and once you found the right derived class (and got
all the type information you need again) you can restart using templates and
a real generic approach. However to do this 'trick ' in a scalable manner,
you need to try all downcasts based on a compile-time list of all derived
classes instead of hardcoding the list like :
downcast(base_class* base) {
derived1 d1 = dynamic_cast< derived1* >( base ) ;
if ( d1 ) foo< derived1 >( d1 ) ;
derived2 d2 = dynamic_cast< derived2* >( base ) ;
if ( d2 ) foo< derived2 >( d2 ) ;
}
This might seem like bad design but is a very helpfull construct to avoid
performance penalties from a to much OO oriented approach by implementing
performance critical pieces using generic programming. Therefor I think it
can appeal to many people that are coming from OO and start looking at
generic programming.
toon
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression test on HP-UX
On Friday 10 January 2003 17:29, Rene Rivera wrote: > I've update the build.sh to detect the "HP-UX" uname, and to added the -Ae > flag to build.sh and build.jam. The missing flag is what probably caused > the problems. Could you try it now? works _if_ you dont't forget to add the quotes, otherwise it reports that it can't find -Ae BOOST_JAM_CC="cc -Ae" > >This is probably because yacc is still used > > Is using yacc always been a problem in HP-UX? Even if the files are > pregenerated? Well I'm not sure what is happening but if I use make (without options) everything works fine but with build.sh I get : timestamp.c: variable.c: modules.c: strings.c: filesys.c: builtins.c: pwd.c: ./bootstrap.acc/jam0 -f build.jam --toolset=acc --toolset-root= build.jam:474: in module scope *** argument error * rule .package ( dst-dir : src-files + ) * called with: ( : bjam jam mkjambase yyacc ) * missing argument dst-dir build.jam:412:see definition of rule '.package' being called ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regression test on HP-UX
First run is uploaded, check it out via the compiler-status page in the CVS. Rene, how can I get the aCC compile to work (it's reporting "Missing" the whole time as you can see) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Thursday 09 January 2003 22:37, Rene Rivera wrote: > [2003-01-09] David Abrahams wrote: > OK that seems like a good idea. I'll add generic Unix cc toolset for > building bjam. tried it but : harry:/home/tk/boost/boost/tools/build/jam_src >./build.sh ### ### Could not find a suitable toolset. ### ### You can specify the toolset as the argument, i.e.: ### ./build.sh gcc ### ### Toolsets supported by this script are: ### acc, como, darwin, gcc, intel-linux, kcc, kylix, mipspro, ### sunpro, tru64cxx, vacpp ### A special toolset; cc, is available which is used as a fallback ### when a more specific toolset is not available and the cc command ### detected. ### and when doing ./build.sh cc harry:/home/tk/boost/boost/tools/build/jam_src >./build.sh cc ### ### Using 'cc' toolset. ### rm -rf bootstrap.cc mkdir bootstrap.cc cc -o bootstrap.cc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c command.c: compile.c: execnt.c: execunix.c: execvms.c: expand.c: filent.c: fileos2.c: fileunix.c: filevms.c: glob.c: hash.c: hdrmacro.c: headers.c: jam.c: jambase.c: jamgram.c: Warning 612: "y.tab.c", line 521 # Label 'yynewerror' has no uses. yynewerror: ^^^ Warning 612: "y.tab.c", line 526 # Label 'yyerrlab' has no uses. yyerrlab: ^ lists.c: make.c: make1.c: newstr.c: option.c: parse.c: pathunix.c: pathvms.c: regexp.c: rules.c: scan.c: search.c: subst.c: timestamp.c: variable.c: modules.c: strings.c: filesys.c: builtins.c: pwd.c: ./bootstrap.cc/jam0 -f build.jam --toolset=cc --toolset-root= build.jam:103: in module scope *** argument error * rule toolset ( name command : opt.out + : opt.define + : release-flags * : debug-flags * : linklibs * ) * called with: ( metrowerks : -o : -D : -subsystem console -runtime staticsingle -opt full -inline auto -inline level=8 : -subsystem console -runtime staticsingle -O0 -inline off ) * missing argument command build.jam:39:see definition of rule 'toolset' being called This is probably because yacc is still used > > But for aCC, can one of you tell what the output of 'uname' is. At least I > can test that in this case. harry:/home/tk/boost/boost/tools/build/jam_src >uname -a HP-UX harry B.11.22 U ia64 1850224727 unlimited-user license harry:/home/tk/boost/boost/tools/build/jam_src >uname HP-UX ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Thursday 09 January 2003 22:40, Rene Rivera wrote: > [2003-01-09] Toon Knapen wrote: > >Anyway, to compile jam_src you can use cc (with the -Ae option though) as > >you can see in the Jambase. > > PS. What does the -Ae option do? from the man pages of aCC/cc : -AeIn aC++, invokes aCC as an ANSI-C compiler, with additional support for HP-C language extensions. Refer to the HP-C compiler documentation for details of the HP-C language extensions. In ANSI C, this is the default Extended ANSI mode. Same as -Aa -D_HPUX_SOURCE +e. This would define the names (macros and typedefs) provided by the HP-UX Operating System and, in addition, allows extensions such as C99 features newly implemented in this release (complex and imaginary data types, STDC pragmas), $ characters in identifier names, sized enums, and sized bit-fields, and 64-bit integral types. Additional extensions may ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Thursday 09 January 2003 14:51, Beman Dawes wrote: > At 04:48 AM 1/9/2003, Toon Knapen wrote: > >I'm working on the port to HPUX (recently I've send a few msg's out on > >this) but have trouble compiling the regression-reporting tools. > >Already patched a few things in MPL but now the filesystem lib is > >causing headeaches. If you and/or Jens (did previous ports to HP) > >could help me out ... ? > > Toon, let me know what about the filesystem is causing problems. It is > supposed to be deliberately straightforward code to minimize porting > problems. I know but the problem reports soth. like (I'm at home so I can't give you the actual output now) "namespace nesting too deep". IMO it's not an error in the fslib but I just have to find some workaround to prevent the error from occuring. I'll keep you informed. t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Thursday 09 January 2003 12:12, Rene Rivera wrote: > It's doesn't because I haven't had time to add it since the toolset > appeared in Boost.Build ;-) I'll try and add ASAP. ... Question on this... > Is it a possibility to install only the C compiler (cc) without the C++ > compiler (aCC)? I'm asking to see if I can use the presense of "aCC" as an > indicator that it's all installed. I guess cc is installed by default (like on all unices) and aCC is a commerical product. So cc is always there and aCC is'nt. Anyway, to compile jam_src you can use cc (with the -Ae option though) as you can see in the Jambase. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Thursday 09 January 2003 16:06, David Abrahams wrote: > > is giving me trouble due to the LOCATE_TARGET. This apparantly makes > > that the sources are searched for in the bin subdir ?! Should'nt it > > be removed ? > > No, it means that targets will be placed in the bin subdir. OK, found the problem. Apparantly on my HP machine I should leave out the CC=gcc. BTW John I made sure that no command-line options are needed on the command-line to compile jamboost so I certainly prefer to remove the "CC=gcc". Is that OK ? > However, Rene has put together some new build scripts for bjam. The > new recommended procedure is: > >bash ./build.sh Apparantly does not know aCC yet ;( But why is it necessary. Had no trouble recently compiling jam_src with make on all platforms (I know, I should follow the discussions in the jamboost-ml more closely but so little time;( ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
> I did a bunch of testing on and porting to HP, but I wasn't using > filesystem or the post-processing tools. If it's giving you trouble > you might consider just using bjam to run tests for a while as you > pick off the low-hanging fruit. It might well be that Filesystem is > broken because of some simpler library it depends on. At the moment I'm going for John's suggestion : compile the tools with gcc and then proceed with aCC. I had my own script to do all the work but I figured I might as well use/contribute to the script in tools/regression/run_tests.sh. One question though, the line : cd $BOOST_ROOT/tools/build/jam_src && \ make CC=gcc YACC="" LOCATE_TARGET=bin is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Wednesday 08 January 2003 17:16, Rene Rivera wrote: > [2003-01-08] Beman Dawes wrote: > >At 07:58 AM 1/8/2003, John Maddock wrote: > > >This is another call for volunteers to come forward to help run the > > > boost regression tests on more platforms, particularly needed are the > > > >commercial > > > > >Unix variants (Solaris, HP, SGI Irix etc), but also Free|Net|OpenBSD and > > >MacOS X. I'm working on the port to HPUX (recently I've send a few msg's out on this) but have trouble compiling the regression-reporting tools. Already patched a few things in MPL but now the filesystem lib is causing headeaches. If you and/or Jens (did previous ports to HP) could help me out ... ? Once these tools compile, I'll provide fresh status pages every friday like I do for IBM. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost and HP aCC
While having major trouble compiling boost with HP/aC++ I was looking for compiler-patches on the HP-site. Now I was surprised to see that the version I have installed is not yet reported on the HP support site. I have version : harry:/home/tk >aCC -V aCC: HP aC++/ANSI C B3910B A.05.38 [Sep 12 2002] while the most recent version on the support site of HP is 5.37 ?! Check out : http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1740,00.html#support OTOH, looking at the status-pages for HP on the boost-site (using the previous version of the regression test suite, I'm still _trying_ to compile the new version but having trouble to compile it) Jens Maurer's compilation was'nt that bad. So to understand the whole issue of boost on HP better, and while trying to figure out the diff between the versions 1.x, 3.x and 5.x (Jens was on 3.3, I'm on 5.38), I would be interested to know about which aCC versions are used by all of you and which boost-libs you are using succesfully with your aCC compiler ? Thanks for any feedback and insight ! (you can respond on the list (preferable) or in private if you prefer that. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL on HPUX
Apparently with the introduction of BOOST_WORKAROUND, an __HP_aCC__ got warped into __IBMCPP__ (while the aCC version number is still correct). So Aleksey if you could apply this patch (or if you want me to do it ?) toon Index: integral_c.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/integral_c.hpp,v retrieving revision 1.11 diff -u -r1.11 integral_c.hpp --- integral_c.hpp 23 Dec 2002 04:59:55 - 1.11 +++ integral_c.hpp 3 Jan 2003 07:43:39 - @@ -49,7 +49,7 @@ typedef integral_c prior; #elif BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x561)) \ || BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(502)) \ -|| BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(53800)) +|| BOOST_WORKAROUND(__HP_aCC, BOOST_TESTED_AT(53800)) typedef integral_c next; typedef integral_c prior; #else ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost regression testing of MPL on HPUX
> >
> > aCC-C++-action
> > > ../../../libs/filesystem/build/bin/libfs.a/acc/release/runtime
> -link-dynamic/operations_posix_windows.o
> > Error 20: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56
> # '::' expected
> > before 'if_c'.
> > typedef typename if_c<
> >
> > Hmm, that's silly. Looks like aCC might need full qualification here.
> My guess as well. One if these might work:
> typedef typename mpl::if_c<
> or
>typedef typename ::boost::mpl::if_c<
>
>Please report back on it, and I'll check in the appropriate fix.
Finally I found out that aCC has a problem with the typename mixed with the
template spec. So if I write the construct like this it works. Could you
apply this patch ?
struct if_
{
typedef if_c<
BOOST_MPL_AUX_ICE_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(C)::value)
, T1
, T2
> parent_type ;
typedef typename parent_type::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT(3,if_,(C,T1,T2))
};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Linux regression test results
On Sunday 22 December 2002 20:09, David Abrahams wrote: > Alkis Evlogimenos <[EMAIL PROTECTED]> writes: > For those running regression tests (and most Boost.Build users), I > really recommend setting ALL_LOCATE_TARGET so that the products of > your build all go into a single directory tree that's not tangled into > your source tree. It makes it much easier, among other things, to > blow away the old built files. But AFAIK Beman's post-processing tools don't like that an alternative destination is set for the derived objects via ALL_LOCATE_TARGET (unless that has changed now too ?) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost regression testing of MPL on HPUX
On Thursday 19 December 2002 18:57, Toon Knapen wrote:
> I'm also in the process of creating status-pages for HPUX 11. I hope to
> checkin an acc-tools.jam tomorrow and upload already preliminary results
> too.
I've checked in a first version of
boost/tools/build/acc-tools.jam that I used for the hpux aCC version 5.38
compiler on hpux 11.22 on a bi-processor itanium machine.
No regression status pages are available yet as I don't succeed in compiling
the necessary libraries for the reporting tools ;(
So in my quest to compile the reporting tools I modified integral_c.hpp
Index: integral_c.hpp
===
RCS file: /cvsroot/boost/boost/boost/mpl/integral_c.hpp,v
retrieving revision 1.10
diff -r1.10 integral_c.hpp
27c27
< #if defined(BOOST_STRICT_CONFIG) || !defined(__HP_aCC) || __HP_aCC > 33900
---
> #if defined(BOOST_STRICT_CONFIG) || !defined(__HP_aCC) || __HP_aCC > 53800
52c52
< || defined(__HP_aCC) && __HP_aCC <= 33900)
---
> || defined(__HP_aCC) && __HP_aCC <= 53800)
And finally I got stuck on following codeline :
cd /home/tk/boost/boost/tools/regression/build ; bjam
...found 834 targets...
...using 1 temp target...
...updating 8 targets...
...using
exception.o...
aCC-C++-action
../../../libs/filesystem/build/bin/libfs.a/acc/release/runtime-link-dynamic/operations_posix_windows.o
Error 20: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56 # '::' expected
before 'if_c'.
typedef typename if_c<
Error 20: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56 # ''
expected before '<'.
typedef typename if_c<
^
Error 318: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56 # A template name
was expected instead of ''. Did you forget to
define the template?
typedef typename if_c<
^
Error 20: "/home/tk/boost/boost/boost/mpl/if.hpp", line 60 # ';' expected
before 'type'.
>::type type;
Error 445: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56 # Cannot recover
from earlier errors.
typedef typename if_c<
I tried several things, playing around with an empty config/user.hpp or
defining the same options as defined in config/compiler/hp_acc.hpp. So any
hints appreciated.
As I'll take a few days off, the mails in my inbox will pile up, so to make
sure I read your response, please also Cc: me directly. Thanks
toon
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression test sane-testing branch
On Tuesday 17 December 2002 16:10, Beman Dawes wrote: > (You can ignore this message unless you run Boost regression testing > software.) > > AFAIK, the changes are all working right now, and I'll switch the Win32 > tests over today. But I'll delay merging the sane-testing branch in CVS > until Friday to give users a bit of advance notice of the change. > > To change to the new setup, do this: > > * Rebuild bjam. > * Delete all bin directories (residue files are different). > * Change scripts to add the bjam --dump-tests option. > * Rebuld status reporting programs (use .../tools/regression/build/Jamfile) > Thanks Beman and David. I tried it on IBM/Aix and everything works just great. I recently adapted the Jamfile in the sandbox/filesystem/example directory to use the filesystem lib from the boost-cvs but this seems unnecessary now. I'm also in the process of creating status-pages for HPUX 11. I hope to checkin an acc-tools.jam tomorrow and upload already preliminary results too. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Extensions in Boost.Compatibility
On Thursday 12 December 2002 13:42, Jeremy Maitin-Shepard wrote: > On Thu, Dec 12, 2002 at 02:54:46PM +0100, Toon Knapen wrote: > > [snip] > > > > My only remaining question is : if the STL (used by the developer) > > already provides the algorithm (in the std namespace however), would'nt > > it be better to reuse it. Maybe that algorithm is written in a way to > > offer the best performance with that compiler ? > > I agree there could be performance benefits in using the compiler > vendor-supplied implementation. I see several issues with using these > implementations, however. First, due to the by-definition > non-standard nature of extensions, not all compiler vendors implement > them in exactly the same way, thus making them non-usable. Agreed, care must be taken too avoid having incompatibilities between the extensions provided by different STL's. Practically, the most common extensions have the same definition in all STL's (e.g. iota). Extensions that are still being heavily discussed however (like hash_map), will also heavily be discussed before they will be added to boost. So through the discussion forum we automatically filter the latter. > Even in > the case that a single interface is used by many vendors, by > immediately assuming that the vendor-supplied implementation should be > used when such an implementation exists eliminates the possibility of > imlementating the library with a different interface or more > functionality. We're still able to define 'extended' interfaces and provide always a implementation for those in boost as with any other function that is not provided by the STL being used. So Herve, what's your position on re-using STL provided algorithms (if they are provided). And are you planning to move your work from the boost-sandbox to the boost-cvs ? t ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] hash table library proposal (was Extensions inBoost.Compatibility)
On Friday 13 December 2002 14:50, Beman Dawes wrote: > Yes, but I think we should try to stick closely to the LWG proposal. In > fact, it might be an advantage for standardization to have an exact > implementation. (It might be worth asking Matt Austern how he proposes to > change the interface to deal with the issues still on the table.) > > Something completely different might be OK, too, but it doesn't serve > anyone's interest to do something "almost standard". That was the point of > the question. I agree totally. So the optimal solution would be to start from Matt's work. Another plan would be to start from Jeremy Maitin-Shepard's implementation and to try to converge to Matt's proposal ! ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] hash table library proposal (was Extensions inBoost.Compatibility)
On Thursday 12 December 2002 20:06, Beman Dawes wrote: > At 08:17 PM 12/11/2002, Jeremy Maitin-Shepard wrote: > >I forgot to mention in my previous post the following proposed ideas: > > > >A hash map and hash multimap in which a single value type is specified > >along with a traits class that is used to extract the key from the > >value type. The std::pair-specific hash_map and hash_multimap would > >then be based upon this generic implementation. > > > >If there is interest in this library, I will create an implementation. > > Are you aware that a hash_map proposal from Matt Austern is almost sure to > be included in the upcoming C++ Standard Library Technical Report? > > See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html > > The only reason that proposal wasn't accepted in Santa Cruz was a naming > controversy and some minor technical quibbles about tuning types being > specified with more precision than can be delivered. Still it makes sense to have it already in boost (until it's implemented by all compilers) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Extensions in Boost.Compatibility
On Thursday 12 December 2002 01:06, Jeremy Maitin-Shepard wrote: > It seems quite clear from the Boost.Compatbility rationale that extensions > to the C++ standard library do not belong in it. OK. And indeed boost _is_ an extension. So I think it makes sense to implement all these extensions in boost also (as Herve has done) and provide them in the boost namespace. My only remaining question is : if the STL (used by the developer) already provides the algorithm (in the std namespace however), would'nt it be better to reuse it. Maybe that algorithm is written in a way to offer the best performance with that compiler ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] STL extensions
On Wednesday 11 December 2002 22:11, Herve Bronnimann wrote: > There was also some work on algorithms. I have taken a very close look > at binary trees, and priority queues (Dietmar Kuehl's beta submission), > and linear-time sorting (radix, etc.) which is in the sandbox. I've also > implemented a full-fledged policy-based vector (again in the sandbox). Interesting. My intention was to provide the extensions of the SGI STL for every other STL if not present. Your scope is clearly much larger. You however, even if the algorithm is provided by the STL, do not use it but still use your own definition (e.g. iota). > Before you duplicate existing work, I should signal that Jeremy created > a sequence_algo in boost-sandbox, and I contributed a more compact > implementation of is_sorted there. In addition, there is: > > template > void iota(ForwardIterator first, ForwardIterator last, T value); > > template > bool contains(InputIterator first, InputIterator last, T value); > > template > bool all(InputIterator first, InputIterator last, Predicate p); > > template > bool none(InputIterator first, InputIterator last, Predicate p); > > template > bool any_if(InputIterator first, InputIterator last, Predicate p); > > template > bool is_sorted(ForwardIterator first, ForwardIterator last); > > template > bool is_sorted(ForwardIterator first, ForwardIterator last, > StrictWeakOrdering comp); > > > Please take a look at boost-sandbox/boost/sequence_algo/, especially: > algorithm.hpp > container_algo.hpp > non-modifying.hpp > as well as at boost-sandbox/boost/linear_sort, and > boost-sandbox/boost/policy_vector if you like. Are these functions all 'known' extensions or 'invented' by you (in the latter case, is there documentation although it's kind of self-documenting). Anyway, I like it ! Except for the name of the directory it is in maybe. And do you plan to add it to boost ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] trouble with browse info with VC++ 6.0 when boost files are included
When including some boost libraries Visual C++ 6.0 (with Intel compiler 7.0 and STLPort) is unable to generate the browse info. Have others experienced the same effect or is there some workaround ? In attachment is a very small demo program with which Visual C++ encounters some problems when generating the browse info. This one only includes type_traits and boost/numeric/ublas/vector.hpp The compiler reports the following error: Configuration: testbsc - Win32 Debug Compiling... main.cpp Unknown compiler version - please run the configure tests and report the results Linking... xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe' Creating browse info file... BSCMAKE: error BK1506 : cannot open file '.\Debug\main.sbr': No such file or directory Error executing bscmake.exe. testbsc.exe - 1 error(s), 0 warning(s) So, no browse info is generated. However, when line 7 (and 14) (i.e. ublas) is uncommented, BSCMAKE reports only a warning: Configuration: testbsc - Win32 Debug Compiling... main.cpp Unknown compiler version - please run the configure tests and report the results Linking... xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe' Creating browse info file... BSCMAKE: warning BK4503 : minor error in .SBR file '.\Debug\main.sbr' ignored testbsc.exe - 0 error(s), 1 warning(s) But when no boost files are included (comment out line 6, 7, 8, 14, 15), browse info is generated without a glitch: Configuration: testbsc - Win32 Debug Compiling... main.cpp Linking... xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe' Creating browse info file... testbsc.exe - 0 error(s), 0 warning(s) In the attached archive, you will find source files (main.ccp, defclass.hpp) and the workspace and project directories. toon testbsc.zip Description: Zip archive ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] STL extensions
On Tuesday 10 December 2002 10:54, David Abrahams wrote: > Toon Knapen <[EMAIL PROTECTED]> writes: > > Long time ago I inquired if it would be a good idea to provide STL > > extensions in boost that are not implemented by all STL's. IIRC David A > > responded that boost/compatibility was intended for this. > > That sort of surprises me. Sorry if I've unrightfully put words in your mounth. > I think they should go in boost, for sure, > but I thought the compatibility library was about fixing broken > std library implementations. This is really Ralf's bailiwick, though. > Ralf? To which Ralf responded : >I don't really have an opinion regarding Toon's proposal, but my gut feeling >is >that compatibility with the ISO standard is very different from compatibility >with someone's extensions. Maybe something like "extension adaptor" library >is >more appropriate? what about boost/stl_extension /? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] STL extensions
Long time ago I inquired if it would be a good idea to provide STL extensions
in boost that are not implemented by all STL's. IIRC David A responded that
boost/compatibility was intended for this.
So I finally started with implementing is_sorted and iota. Also as David
Abrahams suggested, I've put them in the boost namespace (but they reuse the
implementation in the std namespace if available). The definitions are also
located in a file with the same name (except for the attached .hpp
extension) as defined by the SGI/STL.
I propose to put these in the boost/compatibility directory. Opinions ?
#ifndef boost_compatibility_config_hpp
#define boost_compatibility_config_hpp
#if (__GNUC__ >= 3) && ( __GNUC_MINOR__ >= 1 )
#define BOOST_NO_IS_SORTED
#define BOOST_NO_IOTA
#endif
#if (__IBMCPP__)
#define BOOST_NO_IS_SORTED
#define BOOST_NO_IOTA
#endif
#if defined(__ICC)
#define BOOST_NO_IS_SORTED
#endif
#endif // boost_compatibility_config_hpp
#ifndef boost_compatibility_algorithm_hpp
#define boost_compatibility_algorithm_hpp
#include
#if ! defined( BOOST_NO_IS_SORTED )
#include
#endif
namespace boost {
#if defined( BOOST_NO_IS_SORTED )
template
bool is_sorted(ForwardIterator begin, ForwardIterator end)
{
if (begin == end) return true;
ForwardIterator next = begin ;
++next ;
for ( ; next != end; ++begin , ++next) {
if (*next < *begin) return false;
}
return true;
}
template
bool is_sorted(ForwardIterator begin, ForwardIterator end,
StrictWeakOrdering comp)
{
if (begin == end) return true;
ForwardIterator next = begin ;
++next ;
for ( ; next != end ; ++begin, ++next) {
if ( comp(*next, *first) ) return false;
}
return true;
}
#else
template
inline bool is_sorted(ForwardIterator begin, ForwardIterator end)
{ return std::is_sorted( begin, end ) ; }
template
inline bool is_sorted(ForwardIterator begin, ForwardIterator end,
StrictWeakOrdering comp)
{ return std::is_sorted( begin, end, comp ) ; }
#endif // NO_IS_SORTED
} // namespace boost
#endif // boost_compatibility_algorithm_hpp
#ifndef boost_compatibility_numeric_hpp
#define boost_compatibility_numeric_hpp
#include
#if ! defined( BOOST_NO_IOTA )
#include
#endif
namespace boost {
#if defined( BOOST_NO_IOTA )
template
void iota(ForwardIterator begin, ForwardIterator end, ValueType value)
{
while ( begin != end ) {
*begin = value ;
++begin ;
++value ;
}
}
#else
template
inline void iota(ForwardIterator begin, ForwardIterator end, ValueType value)
{ std::iota( begin, end, value ) ; }
#endif // NO_IOTA
} // namespace boost
#endif // boost_compatibility_numeric_hpp
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Proposed Boost config macro
On Monday 09 December 2002 15:32, Samuel Krempp wrote: > On the opposite hand, using the same kind of naming scheme, > #ifdef BOOST_NEED_UNREACHABLE_RETURN > return whatever; > #endif Well all the time I got really confused in this discussion but this proposal is very clear to me. I definitly would prefer this one. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP-UX support
On Wednesday 27 November 2002 12:23, John Maddock wrote: > > Is there a reason these version of aCC are not supported. I can imagine > > that > > > this is the case because they even don't support the new style headers > > like > > > (alhtough adding the -Aa flag to use it in standard compatible > > mode) ? > > Well as you may have noticed we don't have a HP aCC tester at present > (volunteers gratefully accepted), if you can let us know how to support > earlier versions I'm sure we can patch the headers. I'm willing to run the regression test regularly but I only have access to an HPUX 10.20 with aCC version 1.21 installed. But since this compiler does'nt even support the new-style headers I guess it's of little use. Next I have trouble finding info on the aCC compilers like the latest versions availble, the difference between the aCC compilers on HPUX 10.20 and HPUX 11 etc. It would already be a good start if someone knows all these compilers a little better. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] HP-UX support
Currently hp_acc.hpp in boost/config/compiler contains : // // versions check: // we don't support HP aCC prior to version 0: #if __HP_aCC < 33000 # error "Compiler not supported or configured - please reconfigure" #endif On my machine (HPUX 10.20 aCC version : aCC: HP ANSI C++ B3910B A.01.21 where __HP_aCC is only 5184. As also reported by John Hagen (with IIRC) the latest version of aCC on 10.20), this check fails for all compilers on 10.20. Is there a reason these version of aCC are not supported. I can imagine that this is the case because they even don't support the new style headers like (alhtough adding the -Aa flag to use it in standard compatible mode) ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas regression test problems
On Wednesday 20 November 2002 06:35, Aleksey Gurtovoy wrote: > > P.S.: Why aren't there any regression tests for mpl? > > There are, they just not included into the batch. Probably they should be; > there are some issues, mainly with the number of tests (currently ~60 and > more to come) - simply putting those into results table would render it > rather useless, IMO, and the corresponding increase in compile times might > also be a problem (for the tests runners). In any case, I almost never > checking in anything before the regressions passed. Some have mentioned multiple times that the regression-test batch should not take too long to compile. I don't share this opinion. The more tests, the better and as long as the tests can be compiled in less then one night I don't see a problem. For the status pages we (should) just have a cronjob that starts in the evening. As for reporting it's more difficult. Although Beman probably saw this one coming and thus provided functionality to make a status page that only reports the failed tests (as reported seperatly for windows 2K and vacpp) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] installing Boost on HP-UX 10.20
[snip discussion about writing a first acc-tools.jam] > > lanczos:/home/tk/boost/libs/numeric/ublas> /home/tk/bjam -sTOOLS=acc > > ...patience... > > ...patience... > > ...patience... > > ...found 3664 targets... > > ...updating 72 targets... > > aCC-C++-action > > ../../../libs/numeric/ublas/test1/bin/test1/acc/debug/runtime- > > link-dynamic/test1.o > > Error 112: "test1/test1.cpp", line 9 # Include file > > not found. > > #include > > ^^ > > OK, I think you said you have aCC v. 1.21. On my server, 'aCC --version' > gives "HP ANSI C++ B3910B A.01.23", so it looks like my shop is at v. 1.23 > and my experiences should be close to your own. Either way, you may have a > couple problems to surmount when trying to compile clean room C++ source: Does anybody know if there's a difference with aCC on HPUX 11 (we're talking about version 10.20 here). Because when checking out the status pages for HPUX 11 they don't seem so bad. > > (1) Certain header files normally included with angle brackets have to be > included with ".h" on the back of the file name because HP decided to go > with backward compatibility over standard behavior. Files on my system that > I know have this problem are fstream.h, iostream.h and new.h. Your mileage > may vary according to compiler setup. Is there currently an option in boost to use the old include files, I did'nt see any. So would it be interesting to add the new headers that include the old headers in boost/compatibility ? > > (2) On my system, I am getting errors like this: > > Error 20: > "/home/jbh8632/projects/work/boost/boost_1_29_0/boost/detail/allocator.hpp" >, line 182 # ';' expected before '::'. >typedef std::size_tsize_type; > ^^ > The reason is that, on my system, the compiler is configured to use the > global anonymous namespace instead of std::. That may or may not affect > you. I have to deal with it for historical reasons peculiar to my local > installation that I will not describe here. But since there's no iostream but only iostream.h I suppose namespace std does'nt even exist ? (sorry can't check myself now since I only have a few days a week acces to an HPUX machine) > > Now, I am seeing another problem that seems to be related to the file > boost/config/compiler/hp_acc.hpp. I am getting an error from bjam while > using your acc jamfile that look like this: > > aCC-C++-action > libs/regex/build/bin/libboost_regex.a/acc/debug/runtime-link-dynamic/c_rege >x _traits.o > Error 119: > "/home/jbh8632/projects/work/boost/boost_1_29_0/boost/config/compiler/hp_ac >c .hpp", line 32 # #error "Compiler not supported or configured - > please reconfigure" > # error "Compiler not supported or configured - please reconfigure > > ... > > I looked at hp_acc.hpp and found a couple of lines that seem to conflict, > namely: > > #if (__HP_aCC <= 33100).. > > #if (__HP_aCC <= 33300) || !defined(BOOST_STRICT_CONFIG).. > > and > > #if __HP_aCC < 33000 > # error "Compiler not supported or configured - please reconfigure" > #endif.. > > I am getting the error from the last one. I wrote and compiled a small > program (attached below my sig) and it tells me that: > > __HP_aCC == 12300 > BOOST_STRICT_CONFIG not defined. > > Now, if my compiler version is < 3.30 (and it is), then I'll always get an > error from the last preprocessor test, even though the previous #if blocks > in hp_acc.hpp seem to conditionally accept compiler versions < 3.30. Note > that BOOST_STRICT_CONFIG may or may not be defined somewhere in the bjam > build process, so my little program is not the necessarily accurate there. Seems (from cvs log) that John Maddock, Jens and Aleksey have worked on hp_acc.hpp so I hope they can provide some insight here. As I said before I'm trying to help you (John Hagen) out but have little experience with aCC. > > Well, that is what I have for now. I will have to go through the library > and remove all the std:: namespace identifiers to get the Boost libs to > begin compiling on my system, but first I want to know if my hp_acc.hpp is > correct or not. It's from the 1.29 tarball off the Boost site. You definitly should avoid to do that ! (John, I would like to continue the discussion on the boost-ml since there are some people with experience with boost on HPUX that will be able to provide some more info, I'm not crosposting to jamboost since all jamboosters are also boosters) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-install] Need help installing Boost on HP-UX
On Friday 15 November 2002 21:27, Hagen, John wrote: > Then I invoked "bjam" in the boost_root directory. After a while, two > things were evident: bjam wants to use gcc instead of aCC (gcc is also > installed on the system) and bjam failed to compile some of the libs and > then link the whole package (of course :). Indeed by default bjam builds with the gcc toolset. But you can specify the toolset on the cmd-line with 'bjam -sBUILD="vacpp"' for instance to use the IBM VisualAge compiler. I'm curious about the results you'll obtain with aCC. The boost status pages for HPUX only report about HPUX 11. IMO the compilers on HPUX 10.20 are not as up to date (we have for instance version A.01.21 which is the latets on HPUX AFAIK) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [uBLAS] Interest in Possible Small RefactorisationContribution
On Friday 15 November 2002 05:46, Matt Davies wrote: Could you post some code and or examples ? > I noticed some minor duplication in vector.hpp so using cut & paste and > a little inventiveness I have refactored scalar_vector, unit_vector and > zero_vector into a single function_vector that takes a single > vector_index_functor as its template argument. The benefits of this > refactorisation is that users can further extend with instances of > analytical functions / interpolants / whatever into a vector and it > will use the uBLAS optimisations and constructs as appropriate. I have > already been using it and *really* find it useful where I don't want to > use excessive memory or less efficient constructs when calculating > difference norms and/or resolving discretisations. It also saves a > reasonable amount of duplication in vector.hpp. > > Furthermore, I suspect that it might not be an order of complexity > further to create a function_matrix too based on the same ideas and for > the same benefits. > > Is anyone interested in my work on this? I am guessing that the > original maintainers probably have already thought of this as a lot of > their work is still over my head. If anyone is interested and would > like to guide and review my efforts (needed as this would potentially > be my first open source contribution -- although small) I am happy to > do more. I am hoping that (as it is mostly a cut&paste and as my > original work closely copies the style of the rest of uBLAS) it would > be easy to assimilate quickly. > > Matt > > http://careers.yahoo.com.au - Yahoo! Careers > - 1,000's of jobs waiting online for you! > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Can type_traits be user specialized?
On Wednesday 13 November 2002 14:39, Fernando Cacciola wrote: > Unfortunately, some compilers -like bcc55- provide a 'default' > numeric_limits<> with no compile-time constants, while the specializations > do have compile-time values. Therefore, boost's numeric_limits<> is not > picked up for these compilers; but trying to use numeric_limits<> with user > defined types fails to compile unless the types explicitly specialize it > properly. > > I see three possible solutions here: > > (1) REQUIRE user defined types to *properly* specialize numeric_limits. > (2) Enhance boost/limits.hpp so that it 'fixes' only the default > numeric_limits<> if only that one is broken. > (3) Define my own user specializable traits. > > (3) is IMO a very bad idea since we would end up with overlapping traits > and potential ODR violations. > (2) might be a better solution but requires further examination. > (1) is the easiest way to go from the library developer POV, but might > annoy users. IIRC, the problem even arises when using std::complex< double > as argument to std::numeric_limits<>. On gcc 3.2 for instance, the epsilon() is defined to be (0,0) which is certainly not correct and even highly dangerous. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed boost assert
Looks OK to me. I do have a question though but maybe it's out of scope. When testing programs, we also check the return value of the program to check no internal erros popped up. However, if assert calls abort(), the return value will be zero (at least on my linux box) and of course I would prefer to have a non-zero. But also when assert will throw there's no guarantee afaict what a terminate()'d exec will return. Any ideas ? toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] blas, lapack, cblas and amos bindings
Totally new BLAS and LAPACK bindings have been checked in at the boost-sandbox in boost/numeric/bindings. These new bindings can be used for ublas matrices, boost::array, std::vector, tnt etc. thanks to a uniform interface for all these container-types (in boost/numeric/bindings/traits) developed by Kresimir Fresl. It also contains detection of the fortran link-compatibility. The blas-bindings contains an extensive regression-test which at the same time serves as a performance test of the native ublas implementation in respect to (vendor-tuned) blas. (more info in libs/numeric/bindings/blas/test/index.html and libs/numeric/bindings/index.html) Note that the bindings are not complete but the 'framework' is there and it's just a matter of time to complete them. toon BTW: there has been extensive discussion on this topic at the ublas-dev mailinglist, see http://groups.yahoo.com/group/ublas-dev/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] interfaces to numerical functions
On Saturday 09 November 2002 16:05, Jason D Schmidt wrote: > Should algorithms that take an array of data simply take some > container as an argument and return as a container (if appropriate), or > should they take input iterators, an output iterator, and return an > output iterator (ala STL)? An STL-style algorithm would work just as > well for C arrays as for any standard container. If the algorithm takes > a std::valarray (not a standard container), for example, then the > programmer who writes the algorithm can take full advantage of the > natural math operations defined for > that class. After all, why should we even allow a user to integrate a > std::list of data? That's not the intended use of the list class. > However, that is THE one and only intended use of the valarray class, and > providing an iterator interface doesn't allow numerical algorithms to > operate on C++'s only numeric array class because valarrays don't have > iterators. Then again, maybe someone will want to use a boost::array as > often as a plain C array as often as their own array class; then that > user is forced to use the valarray class when it doesn't necessarily fit > his needs. You can find a solution to this in boost-sandbox/boost/numeric/bindings/traits/. For making bindings to several libraries from also a multitude of containers (in our case vectors and matrices) Kresimir Fresl developed a traits class that provides a uniform interface for a number of vector and matrix libraries such as boost::ublas, boost::array, std::vector, tnt etc. Since the algorithms you mention are really operations on vectors and matrices, pass the container to the function but access it via the above traits to be able to handle a multitude of different vector/matrix implementations. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
