SQLite Forum

SQLITE_ENABLE_STAT4 triggers failures in analyze3.test
Login
OK, it's a lot of tests. But the real number of permutations is a lot less than 87! because of mutual exclusion. Still a lot!

Just throwing this out: for several years I used my computer to run a SETI program analyzing data streams looking for alien signals. Literally millions of computers put all their idle time into the analyses.

What if we could use the same technology to examine SQLITE code and compile options. What would be the worthiness of such an endeavor? Probably we might find a few compiler errors. Or, we might discover some dead code if a certain combination of compile options were selected. Since the code quality is already very high (very few bugs), I would not expect the uncover many bugs.

But, if you tied the options to code segments and code segments to SQL statement pieces, then you could automate the test case generation. You could visualize the code in new and different ways.

We might start by partitioning the compiler options into groups of 5 or 10 that have something in common. Then dole each group out to 100 or a 1000 computers and let them crunch. Pull the results back and see what they say, what there is to learn.

The partitioning of the code is easy for a given set of compiler options. We have tools all over the place to allow us to gen deltas. If we use the delta generators in a new way we can gen a set of deltas for code changes for a single compiler option change. And by being smart about where in the code compiler options make a difference, we can reduce the permutations. We would find out rather quickly which compiler options interacted with each other. And which ones interacted with each other in strange and wonderful ways.

We can use SQLITE (of course) for the database underlying the analysis. You only need a pre-compiler to do this analysis (if you trust that all the various pre-compilers will generate the same code). How to tie the SQL to the code? We use Lemon for parsing, right? Take the output of Lemon and relate it to code segments. Since the code segments are influenced by the compiler options, one can link Lemon output and compiler options.

We need a body of SQL to drive this analysis. Collecting a unique set of SQL statements is another 87! problem which can be partitioned like compiler options can. I don't know lots of things about lots of things, but my application world revolves around database. And I'd like to understand it a lot better.