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

[Beman Dawes]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost