Re: [boost] Usability of http://boost.sourceforge.net/regression-logs

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-30 15:21:16

At 12:20 PM 1/29/2003, David Abrahams wrote:

 >This is a minor complaint about the wonderful automatically generated
 >page at http://boost.sourceforge.net/regression-logs/, and perhaps
 >also which tables we're generating and how we're generating them.
 >
 >When I'm interested in finding out how a library is performing on a
 >given platform, I tend to go to the compilers column and click a
 >link, expecting to see a table of results for that compiler.  Of
 >course, it takes me to the vendor's page instead.  I can't tell you
 >how many times I've made this mistake.

I've made the same mistake too.

 >It seems to me that while lib developers may be interested in the "big
 >table", most users, unless they care extraordinarily about
 >portability, will want to know about individual compiler results.  I
 >wonder if we shouldn't be assembling the HTML on-the-fly for all
 >tables, and just having testers upload jam logs?

Good grief, would SourceForge really let you do that kind of heavy-duty 
processing on their servers? It means uploading the rest of the residue, 
too. I guess the workload could be reduced if the information that goes in 
the current .xml files was centralized in a single test database file, but 
everything would still have to be uploaded first. Why do you thing it would 
be better to do the post-build processing on SourceForge rather than on 
regression tester's local machines?

 >  I know this goes
 >against the grain of Beman's desire to produce the HTML with C++ code
 >because of CGI portability issue, but I have the sense that until we
 >have a true portable C++ virtual machine this might be the wrong kind
 >of job for our favorite language.

Actually producing the HTML is probably less than 5% of the post-bjam 
processing. If instead we generated some other form like a combined .xml 
file that a CGI script then turned into HTML on the fly, that would be OK 
with me. But we would need a local version so developers can see results on 
their local machine, too. That would have to still be a regular C++ program 
(not CGI), or you would be increasing the length of the toolchain quite a 
bit.

I'm not sure I see the benefit.

As far as individual compiler results go, the current programs already have 
options to produce that style table, if it is what people would prefer. 
That could either be in addition to or a replacement for the current 
multi-compiler tables.

--Beman