Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] Making frama-c-gui a read-only tool?

-- Loïc Correnson (2017-02-06)
> Thanks Yannick for the pointers on your memcached-based solution !

Note that some of our customers actually implemented their own caching solution before, intercepting calls to provers to return the cached result. That's how Altran for example use memcached for their large projects.

> To complete your notes on using Why3, I would just mention that in Frama-C/WP (current version), using `-wp-prover why3ide` actually uses a why3-session to store and reuse proof results.

Interesting. Of course, one issue then is how you replay/display results when they come from different sources like EVA and WP. In SPARK, we have the same issue with the results from our static analyzer CodePeer (see an explanation of the integration here: http://www.spark-2014.org/entries/detail/spark-and-codepeer-a-good-match <http://www.spark-2014.org/entries/detail/spark-and-codepeer-a-good-match>), which we don't save currently in the Why3 session file, hence in replay mode CodePeer is rerun (which is OK), but in display mode it is rerun too (which is not ideal). How do you solve this issue in Frama-C?

--
Yannick Moy, Senior Software Engineer, AdaCore



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/frama-c-discuss/attachments/20170206/043a8bd0/attachment.html>