% CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-20 2004/03/19 Sorry, I should have been testing this toolset earlier in the release process, but now that the official 1.32.0 is out and I've tried building it with the crufty old Sun CC, I've encountered a handful of errors and perhaps two valid warnings. The first is in date_time. It appears that Rogue Wave's std::locale::facet has an undocumented abstract virtual method __get_id. Attached is a patch which adds this method when building with SUNPRO_CC and RWSTD. This may be better done with some BOOST_* config macros, I'm not sure. There are several other errors in filesystem, program_options, serialization, and signals which manifest themselves as errors resolving overloads of iterator_traits. I'm attaching the output from my build as I'm unsure how to address these issues. Also, in archive/impl/basic_xml_grammar.hpp, the compiler warns that the StringType typedef is not accessible from the public interface of basic_xml_grammar (e.g. in the return_values struct). Making this one typedef public fixes this issue. Finally, the compiler warns about the "static" being anachronistic in boost_1_32_0/boost/smart_cast.hpp, lines 264 and 292 (the free functions smart_cast and smart_cast_reference). I think the compiler may actually be correct - what purpose does "static" serve here? I know this is a crufty toolset, but this code (at least date_time and filesystem) used to build with 1.31.0. -- Caleb Epstein caleb dot epstein at gmail dot com
On Mon, 22 Nov 2004 09:23:06 -0500, Caleb Epstein wrote
Yes, it would've been better to do this before the release -- honestly I'm suprised you've been using Sun Workshop and Boost -- I was under the impression that everyone that tried this gave up in frustration and used g++.
I'll try and take a look at this and check it in over the next few days...
I know this is a crufty toolset, but this code (at least date_time and filesystem) used to build with 1.31.0.
It would really help if we had a regression test runner for Solaris tools (hint, hint)-- that way we could see what works and what doesn't... Jeff
On Mon, 22 Nov 2004 07:46:35 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
We're doing this where possible, but there are still some legacy applications and 3rd party APIs I support that are Solaris-only. These are dwindling by the day, but there is still the occasional need for a Solaris build, and I'd like to be able to use what Boost facilities I can on this platform.
I'll gladly volunteer, but the process would be a very manual one. The Solaris machines to which I have access are firewalled, so I am not able to grab code from CVS regularly unless perhaps there is a regular Boost CVS "tarball" hosted via FTP or http/https. Similarly I wouldn't be able to host any web pages with the results of the build/regression tests; these would need to be pushed back to some other site again via FTP/http. Is this do-able? -- Caleb Epstein caleb dot epstein at gmail dot com
On Mon, 22 Nov 2004 12:21:44 -0500, Caleb Epstein wrote
Actually, you are in luck b/c I believe that is exactly how things work. Grab a tar from boost consulting, generate the results, upload to meta- comm -- the process is documented somewhere, but I don't have the link handy. Jeff
On Mon, Nov 22, 2004 at 12:21:44PM -0500, Caleb Epstein wrote:
There should be a nightly tarball of the repository here: http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 (at least, that's how it works for my sourceforge-hosted projects) jon -- "The ability to quote is a serviceable substitute for wit." - W. Sommerset Maugham
On Mon, 22 Nov 2004 17:40:50 +0000, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
Yes, but thats a tar of the entire CVS repository. I'm hoping for something more like a tarball of a particular BRANCH or the current trunk which needs building/testing. The entire CVSROOT seems like overkill, but I can live with it. At any rate, I just found the "run_tests.sh" script (http://boost.org/tools/regression/run_tests.sh) and made it work properly with POSIX /bin/sh (export VARIABLE=value is a no-no). Unfortunately, because SunPRO can't even build the 1.32 Boost.Filesystem, I can't get the compiler_status tool to build. So its a bit of a chicken/egg problem. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Our standard regression runner script does all this for you -- http://www.meta-comm.com/engineering/regression_setup/instructions.html. -- Aleksey Gurtovoy MetaCommunications Engineering
This seems to depend on a module "tarfile" that I don't have available: % python ~/bin/regression.py --help Traceback (most recent call last): File "/home/nbde52d/bin/regression.py", line 10, in ? import tarfile ImportError: No module named tarfile % python -V Python 2.2.1 On Tue, 23 Nov 2004 00:41:39 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
-- Caleb Epstein caleb dot epstein at gmail dot com
OK, having done that I now get an error trying to download the snapshot tarballs: # Downloading "http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2" to "/home/nbde52d/src/boost-regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/nbde52d/src/boost-regression/boost-CVS-HEAD.tar.bz2")... Traceback (most recent call last): File "regression.py", line 765, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 607, in regression get_source( user, tag, proxy, [] ) File "regression.py", line 270, in get_source unpack_tarball( tarball_path, regression_root ) File "regression.py", line 169, in unpack_tarball tar = tarfile.open( tarball_path, 'r|%s' % mode ) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/tarfile.py", line 886, in open _Stream(name, filemode, comptype, fileobj, bufsize)) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/tarfile.py", line 810, in __init__ self.firstmember = self.next() File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/tarfile.py", line 1559, in next buf = self.fileobj.read(BLOCKSIZE) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/tarfile.py", line 430, in read buf = self._read(size) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/tarfile.py", line 446, in _read buf = self.cmp.decompress(buf) IOError: invalid data stream Checking with wget, it seems that this is not a valid URL: wget http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2 --10:08:21-- http://www.meta-comm.com/engineering/boost/snapshot/boost-CVS-HEAD.tar.bz2 => `boost-CVS-HEAD.tar.bz2' Resolving proxy... done. Connecting to proxy[x.x.x.x]:8080... connected. Proxy request sent, awaiting response... 404 Object Not Found 10:08:22 ERROR 404: Object Not Found. -- Caleb Epstein caleb dot epstein at gmail dot com
OK, I figured out how to avoid fetching the tarballs with the --local flag and have uploaded the results of my regression test to: ftp://fx.meta-comm.com/boost-regression/boost_1_32_0/CalebEpstein.zip I had to do this manually because the regression.py script doesn't handly my FTP firewall properly. These results are with one small patch applied to date_time to work with the Roge Wave std::locale::facet. Please let me know if this is helpful and if I'm doing this correctly. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Caleb, I've moved your results over to ftp://fx.meta-comm.com/boost-regression/CVS-HEAD/ (the above is the incoming directory for the 1.32 tarball results, and your tests were run on the CVS main trunk's snapshot). The corresponding reports are available at the usual location -- http://www.meta-comm.com/engineering/boost-regression/developer/summary.html.
I had to do this manually because the regression.py script doesn't handly my FTP firewall properly.
Could you post the exact traceback? Chances are we can do something about it.
These results are with one small patch applied to date_time to work with the Roge Wave std::locale::facet.
Your might consider putting this into your comment file.
Please let me know if this is helpful
Most definitely.
and if I'm doing this correctly.
You are (besides the fact that uploads should go into ftp://fx.meta-comm.com/boost-regression/CVS-HEAD/). We should really get rid of the obstacles on the way to automated runs, though. I'll look into fixing the tarball issue you've reported earlier. -- Aleksey Gurtovoy MetaCommunications Engineering
On Tue, 30 Nov 2004 02:39:12 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
# Done writing "/home/nbde52d/src/boost-regression/results/CalebEpstein.xml". # Compressing "/home/nbde52d/src/boost-regression/results/CalebEpstein.xml"... # Done writing "/home/nbde52d/src/boost-regression/results/CalebEpstein.zip". # Uploading log archive "/home/nbde52d/src/boost-regression/results/CalebEpstein.zip" to ftp://fx.meta-comm.com/boost-regression/CVS-HEAD Traceback (most recent call last): File "./regression.py", line 765, in ? commands[ command ]( **accept_args( args ) ) File "./regression.py", line 612, in regression upload_logs( tag, runner, user ) File "./regression.py", line 545, in upload_logs upload_logs( regression_results, runner, tag, user ) File "/home/nbde52d/src/boost-regression/boost/tools/regression/xsl_reports/runner/collect_and_upload_logs.py", line 153, in upload_logs upload_to_ftp( tag, logs_archive ) File "/home/nbde52d/src/boost-regression/boost/tools/regression/xsl_reports/runner/collect_and_upload_logs.py", line 51, in upload_to_ftp ftp = ftplib.FTP( ftp_site ) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/ftplib.py", line 107, in __init__ self.connect(host) File "/home/eqdev/tools/sunos-sparc-gcc/python-2.3.4/lib/python2.3/ftplib.py", line 117, in connect for res in socket.getaddrinfo(self.host, self.port, 0, socket.SOCK_STREAM): socket.gaierror: (8, 'host/servname not known') I cannot resolve internet hostnames inside my firewall. I have an http proxy server which can handle http, https and ftp requests (e.g. ftp-over-http, which probably only supports RETR I suspect), as well as an FTP proxy server that uses the convention of specifying user@remotehost as the username to connect to Internet hosts. In other words, I do: % ftp ny-proxy Connected to ny-proxy. 220 nyinfppxy1 FTP proxy (Version V2.1) ready. Name (ny-proxy:nbde52d): annonymous@fx.meta-comm.com 331-(----GATEWAY CONNECTED TO fx.meta-comm.com----) 331-(220 filestor Microsoft FTP Service (Version 5.0).) 331 Password required for annonymous. Password: Then from there things behave like regular FTP. I don't think Python's ftplib has any out-of-the-box support for firewalls unlike the equivalent Perl module Net::FTP which honors the environment variable FTP_FIREWALL.
Done. This will be in the next zip I upload. I'm also attaching the two small patches to this message.
We should really get rid of the obstacles on the way to automated runs, though. I'll look into fixing the tarball issue you've reported earlier.
Thanks. There are also some other bugs I've found with regression.py: 1. Using the --mail argument crashes the script: % python ./regression.py --runner CalebEpstein --local boost_1_32_0 --toolsets sunpro --bjam-options "-j8" --mail caleb.epstein@gmail.com --proxy $http_proxy # Sending start notification to "caleb.epstein@gmail.com" # Sending report to "caleb.epstein@gmail.com" Traceback (most recent call last): File "./regression.py", line 765, in ? commands[ command ]( **accept_args( args ) ) File "./regression.py", line 625, in regression msg = regression_log + [ '' ] + apply( traceback.format_exception, sys.exc_info() ) TypeError: cannot concatenate 'str' and 'list' objects 2. The --local argument is not idempotent. If this points to a directory, it will be renamed to "boost", so a later run with the same arguments will fail. 3. The --local argument expects to be given a name like <tag>.<something> and takes the first portion before the . as a tag. If the name points to a directory like boost_1_32_0 the tag name is taken as this name with the last character dropped (e.g. "boost_1_32_"). 4. Unless --comment is supplied, an existing comment.html file will be overwritten. I found this one out the hard way! global comment_path if comment is None: log( 'Comment file "%s" not found; creating default comment.' % comment_ path ) f = open( comment_path, 'w' ) f.write( '<p>Tests are run on %s platform.</p>' % string.capitalize( sys .platform ) ) f.close() else: comment_path = os.path.join( regression_root, comment ) -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Oh, that's good enough. If you grab the latest 'regression.py' from http://cvs.sourceforge.net/viewcvs.py/boost/boost/tools/regression/xsl_repor... and provide it with the '--ftp-proxy' option, it will try the above route. A quick way to check whether it works or not without going through the whole regression cycle would be this: python regression.py upload-logs --runner=<your-runner-id> --ftp-proxy=<proxy> ^^^^^^^^^^^
It doesn't, at least it by itself; you need to bundle it with urllib2 to do the job, but if the above works, it's good enough for now.
Applied the toolset patch. You might want to post a separate message with more explicit subject line to catch the attention of Date-Time folks.
[snip various issues] We'll look into these. Thanks for the report! -- Aleksey Gurtovoy MetaCommunications Engineering
On Wed, 1 Dec 2004 04:20:30 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
[snip various issues]
A couple more. When bjam is not found in the regression directory and the script tries to build it, it runs "./build.sh ...", but the build.sh in the tarballs is not executable. This should be changed to "sh ./build.sh ..." Also, was the CVS-ROOT tarfile assembled on a Windows machine? I'm hitting several new issues having to do with files being formatted with MS-DOS CR-LF terminators. At least one test (regex/example/regex_timer) is never finishing because it is expecting to read the input string "quit" but it gets "quit^M". There is also a minor error spit out as a result of the tools/build/v1/testing.jam file being CR-LF'd: ---snip--- if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat /home/nbde52d/src/boost-regression/results/bin/boost/libs/graph/tes t/bellman-test.test/gcc/debug/bellman-test.output echo ====== END OUTPUT ====== fi exit $status /bin/sh: ^M: not found ---snip--- -- Caleb Epstein caleb dot epstein at gmail dot com
On Wed, 1 Dec 2004 04:20:30 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
OK it almost works. At least in my case, collect_and_upload_logs.py needs to turn off PASV mode: else: utils.log( ' Connecting through FTP proxy server "%s"' % ftp_proxy ) ftp = ftplib.FTP( ftp_proxy ) ftp.set_pasv (0) # turn off PASV mode ftp.login( 'anonymous@%s' % ftp_site, 'anonymous@' ) The use (or non-use) of PASV should probably be user-selectable. It might be nice to be able to turn on ftplib debugging too via FTP.set_debuglevel. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Incorporated.
The use (or non-use) of PASV should probably be user-selectable.
Let's wait and see if somebody needs a different setup.
It might be nice to be able to turn on ftplib debugging too via FTP.set_debuglevel.
Sure; OK, '--debug-level' in the latest 'regression.py' will do that for you. -- Aleksey Gurtovoy MetaCommunications Engineering
At 03:39 AM 11/30/2004, Aleksey Gurtovoy wrote:
Hum... The error messages for the filesystem library failures seem to be getting lost. I guessing the case is that the filesystem library isn't being built, rather than one of the test programs failing. It would be great if these Sun tests can be run regularly; it has always seemed a shame to not test on one of the commercially most important operating systems. --Beman
On Tue, 30 Nov 2004 12:03:22 -0500, Beman Dawes <bdawes@acm.org> wrote:
I think this is due to the fact that I passed -j8 to bjam as part of the regression run (this is a 24-way box). I suspect this confused the process that collects the results. I'll do future runs without -j.
Now that I know that I'm running the tests correctly and know where to place the results, I plan to set this up as a regular process. I will also do a gcc-on-Solaris regression run which is a currnetly untested configuration. What is the actual frequency that folks generally run these regression tests? Daily? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Yep, it's a known issue.
What is the actual frequency that folks generally run these regression tests? Daily?
Normally, yes. When the release comes close, the folks who can afford it often do more frequent runs, to speed up remote troubleshooting. -- Aleksey Gurtovoy MetaCommunications Engineering
On Tue, 30 Nov 2004 12:03:22 -0500, Beman Dawes <bdawes@acm.org> wrote:
Ask and ye shall receive. I've added the much-less-dire gcc results to my regression test runs: http://www.meta-comm.com/engineering/boost-regression/developer/summary.html It appears that gcc doesn't support std::wstring or wide character iostreams on Solaris, and most of the failures seem to be due to this. Aleksey: how do I get the compiler version information to show up as part of the toolset name in the regression results (e.g. gcc-3.3.4-sunos5 instead of just gcc)? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
Add a toolset as boost-root/tools/build/v1/gcc-3_3_4-sunos5.jam with: { extends gcc ; } -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Wed, 01 Dec 2004 14:53:19 -0600, Rene Rivera <grafik.list@redshift-software.com> wrote:
Thanks. I was hoping this might be handled automatically somehow, so I don't need to patch my Boost tarball or change anything when I upgrade gcc versions. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein writes:
Hopefully when we switch over to Boost.Build v2.
so I don't need to patch my Boost tarball or change anything when I upgrade gcc versions.
We could provide a way to alias a toolset in 'regression.py', but as soon as you'd want to start testing with two or more different gcc versions you'd _have_ to have a differently named toolset anyway, so basically it's not worth it. Patching is easy, though: just put an executable script named 'patch_boost' that does what you want in the same directory with 'regression.py' and it would be automatically picked up and executed before the actual tests are started. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
No patching is needed, IIUC. Just set BOOST_BUILD_PATH to point at a directory of yours, then boost/tools/build/v1, e.g.: BOOST_BUILD_PATH=/home/dave/toolsets:/home/daveboost/tools/build/v1 Then drop your own toolsets into the first directory. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (8)
-
Aleksey Gurtovoy -
Beman Dawes -
Caleb Epstein -
David Abrahams -
Jeff Garland -
John Maddock -
Jonathan Wakely -
Rene Rivera