partition' returns empty list for various files about liquid-fixpoint

[christetreault]

Some additional background:

At first, I didn't check for this case. I assumed that the system would consider mempty as a failure, and was just returning the result. However if you mconcat [] you get mempty, and the system considers this to be Sat.

This only fails 1 of the regression tests so I added this check to solvePar

   case fis of
      [] -> solveExt c fi
      [onePart] -> solveExt c onePart
      _ -> --stuff

which would use the serial solver in this case. However, it has now occured to me that this is shortsighted, and that this is just hiding a bug in the system. Now solvePar throws an exception on the empty list case, and it is clear that this issue is much more pervasive than I initially thought.

[ranjitjhala]

Interesting. Will take a look at this ASAP. In the meantime I'm guessing
you can make progress on the other benchmarks?

On Wed, Aug 5, 2015 at 11:20 PM, Chris Tetreault [email protected]
wrote:

Some additional background:

At first, I didn't check for this case. I assumed that the system would
consider mempty as a failure, and was just returning the result. However
if you mconcat [] you get mempty, and the system considers this to be Sat.

This only fails 1 of the regression tests so I added this check to
solvePar

case fis of
[] -> solveExt c fi
[onePart] -> solveExt c onePart
_ -> --stuff

which would use the serial solver in this case. However, it has now
occured to me that this is shortsighted, and that this is just hiding a bug
in the system. Now solvePar throws an exception on the empty list case,
and it is clear that this issue is much more pervasive than I initially
thought.

—
Reply to this email directly or view it on GitHub
#93 (comment)
.

Ranjit.

[christetreault]

Yes, and if I run out of stuff to do there is always the book.

[ranjitjhala]

I just pushed a fix for this issue (to the cores branch). Can you take a
look?

(We were getting empty lists when the input FInfo had ZERO constraints...)

Interestingly, like many others, a bug that would have been caught if we
were using LH on itself :)

On Fri, Aug 7, 2015 at 12:33 AM, Chris Tetreault [email protected]
wrote:

Yes, and if I run out of stuff to do there is always the book.

—
Reply to this email directly or view it on GitHub
#93 (comment)
.

Ranjit.

[christetreault]

I'm seeing no change in behavior. Is this the fix?

d7d7244

[ranjitjhala]

Sorry, looks like I forgot to push. (But now I did.)

This is the fix, can you see if it works?

https://github.com/ucsd-progsys/liquid-fixpoint/blob/cores/src/Language/Fixpoint/Partition.hs#L53

Also, how are you running the tests?

[christetreault]

I've been using make test, however when I do I get this error when the test goes to actually run:

cabal exec ./dist/build/test/test -- --smtsolver z3 --hide-successes --rerun-update -p 'Unit/' -j1 +RTS -N1 -RTS
cabal: The program './dist/build/test/test' is required but it could not be
found.
Makefile:65: recipe for target 'test' failed
make: *** [test] Error 1

I strongly suspect that this is because of my slightly wonky cabal setup, so I haven't reported it as a bug. As a workaround, I do this:

$ cabal exec bash
$ ./dist/build/test/test --smtsolver z3 --hide-successes --rerun-update -p 'Unit/' -j1 +RTS -N1 -RTS

for testing the single-threaded implementation or:

$ cabal exec bash
$ ./dist/build/test/test --smtsolver z3 --hide-successes --rerun-update -p 'Unit/' -j1 +RTS -N4 -RTS --liquid-opts --cores=4

for multithreaded. I kind of like it this way because it makes it easy to tweak the arguments (things like showing success)

[christetreault]

...and still no dice. I am getting this trace output though:

Trace: [flattened] : []

[christetreault]

I just verified that all files that were previously failing are still failing

[christetreault]

It looks like your fix works if you don't specify a number of partitions. I'll go ahead and see if I can't apply your fix to partitonByConstraints'

[christetreault]

OK I've updated partition' to apply the fix to both the Nothing case and the Just n case. I've also cleaned up the code a bit, and deleted a bunch of superfluous stuff.

I re-ran the tests, and now the only failing tests are the five from issue #88.

At this point, I believe that this issue can be closed.