1. 26 Sep, 2016 1 commit
    • MARCHE Claude's avatar
      Yet another attempt to fix unstability of prover answers · 32c8a24c
      MARCHE Claude authored
      - Call_provers.parse_prover_run does not attempt fixing answer anymore,
        except in the case where the answer is HighFailure and time is close
        to time limit (which is considered as Timeout)
      
      - Session_scheduler.fuzzy_proof_time is now more liberal, accepts
        that two answers Unknown or Timeout of OutOfMemory with less than
        10% difference in time are equivalent, and thus should not be
        reported as a significant change
      32c8a24c
  2. 26 Jul, 2016 2 commits
  3. 19 Jul, 2016 1 commit
    • Johannes Kanig's avatar
      Allow to keep unmatched theories · 4c744eba
      Johannes Kanig authored
      When Why3 is run on a file where some theories have been suppressed, it
      will delete the corresponding theories from the session file.  We now
      add an option keep_unmatched_theories to Session.update_session, which
      keeps all theories. In this commit, this option is always disabled.
      
      This is useful for SPARK, which sometimes only generates part of the
      Why3 file for efficiency reasons, but doesn't want the session file to
      be damaged because of that.
      
      * session.ml
      (import_theory)
      (import_goal)
      (import_proof_attempt)
      (import_transf): new functions to copy a session tree from an old
        session file
      (merge_file): keep old theories when keep_unmatched_theories is true
      * session_scheduler.ml
      (update_session): pass keep_unmatched_theories
      * why3session_lib.ml
      (read_update_session): pass keep_unmatched_theories
      4c744eba
  4. 10 Jun, 2016 2 commits
  5. 20 Apr, 2016 2 commits
    • Andrei Paskevich's avatar
      Session_scheduler: rework the scheduler environment type · 52580155
      Andrei Paskevich authored
      - drop the "running_check" queue, unused and unusable.
      
      - drop the "running_proofs" list, maintained in the proof server now.
      
      - send a proof task to the server as soon as it is added to
        "proof_attempts_queue" (still limited by 3 * maximum_running_proofs).
      
      - process "proof_attempts_queue" in the timeout_handler.
      
      - do not clear proof_attempts_queue on cancel_scheduled_proofs,
        since every task in it is already sent to the server, and we
        have no means at the moment to pass cancellation events to it.
      
        TODO: this probably should be supported: it is quite frustrating
        to have thirty proof tasks in proof_attempts_queue and not be able
        to stop those that have not started yet. To do this, we should
        decide whether we want cancel tasks one by one, or all at once,
        or both. A server should send a single answer for every task,
        which may be "ProverFinished" (if the cancellation request arrived
        too late), or "ProverInterrupted" (if we want to extend the
        "prover_update" type), or "ProverFinished (Unknown (Interrupted))"
        (if we want to extend the "reason_unknown" type).
      
      IMPORTANT: schedule_any_timeout behaves differently now: all
      such callbacks are immediately added to proof_attempts_queue,
      and thus are executed on every timeout event, without being
      limited by "maximum_running_proofs". This function is only
      used in why3session_run, with a comment saying that it should
      not be used there, so maybe we should drop this completely.
      52580155
    • Andrei Paskevich's avatar
      Call_provers: simplify API · 8159c0d7
      Andrei Paskevich authored
      Call_provers:
      
      - drop closures "pre_prover_call" and "post_prover_call". They were
        intended to be used for synchronous interaction with provers from
        multiple threads. This is now responsibility of the proof server:
        (a) any Call_prover.call_on_[file|buffer] submits the proof task
            immediately to the server;
        (b) all proof results are handled in the working Why3 thread.
      
      - Call_provers.query_call returns a tri-state "prover_update" type
        which can be one of: "ProverStarted" (returned after the proof
        server informs Why3 that a prover was started), "ProverFinished"
        (returned after the proof server returns the prover result), and
        "NoUpdates" (returned when the proof server has not sent any new
        updates concerning the proof task in question).
      
          IMPORTANT: query_call does not maintain the state of a given
        prover call. In a normal use case, "ProverFinished" is returned
        _exactly_ once, and "ProverStarted" _at_most_ once (never for
        an editor call or when rapidly overwritten by "ProverFinished").
      
          TODO: extend the proof server protocol and implementation to
        send "ProverStarted" events back to Why3.
      8159c0d7
  6. 14 Apr, 2016 3 commits
  7. 11 Apr, 2016 1 commit
  8. 07 Apr, 2016 1 commit
  9. 15 Mar, 2016 3 commits
  10. 14 Mar, 2016 2 commits
  11. 08 Mar, 2016 1 commit
  12. 18 Jan, 2016 2 commits
  13. 08 Jan, 2016 1 commit
  14. 10 Dec, 2015 1 commit
  15. 18 Nov, 2015 2 commits
    • Johannes Kanig's avatar
      O225-030 render traversal function more generic · d9a3aab4
      Johannes Kanig authored
      So that it can be used to search for other labels.
      
      * termcode.ml
      (search_labels): basically a copy of get_expls_fmla with extra argument
      for the callback
      (get_expls_fmla): rewritten to use search_labels
      d9a3aab4
    • Johannes Kanig's avatar
      O225-030 render traversal function more generic · 69de5f30
      Johannes Kanig authored
      So that it can be used to search for other labels.
      
      * termcode.ml
      (search_labels): basically a copy of get_expls_fmla with extra argument
      for the callback
      (get_expls_fmla): rewritten to use search_labels
      69de5f30
  16. 17 Nov, 2015 1 commit
    • David Hauzar's avatar
      Query cvc4 for reason of answer unknown and use it for counterexamples. · 5c3038bf
      David Hauzar authored
      When resource limit is hit, cvc4 outputs useless counterexample. Query
      cvc4 for the reason of answer unknown and use the answer to decide
      whether resource limit was hit. If it was hit, do not display the
      counterexample.
      
      * src/driver/call_provers.{ml|mli}
      (parse_prover_run): If the prover answers unknown, get the information
      about the reason of this answer.
      
      * src/printer/smtv2.ml
      (print_prop_decl): Query solver for the reason of answer unknown.
      
      * src/driver/driver.ml
      (load_driver): Initialize Unknown with no information about the reason
      of answer unknown.
      
      * src/session/session.ml
      (load_result): Initialize Unknown with no information about the reason
      of answer unknown.
      
      * src/session/session_scheduler.ml
      (schedule_proof_attempt)
      (edit_proof): Initialize Unknown with no information about the reason
      of answer unknown.
      
      * src/why3session/why3session_lib.ml
      (filter_spec): Initialize Unknown with no information about the reason
      of answer unknown.
      5c3038bf
  17. 21 Oct, 2015 1 commit
  18. 13 Oct, 2015 1 commit
  19. 09 Sep, 2015 2 commits
  20. 04 Sep, 2015 1 commit
  21. 30 Aug, 2015 1 commit
  22. 22 Jul, 2015 1 commit
  23. 21 Jul, 2015 1 commit
  24. 11 Jul, 2015 1 commit
  25. 12 Jun, 2015 1 commit
  26. 10 Jun, 2015 1 commit
  27. 09 Jun, 2015 1 commit
  28. 04 Jun, 2015 1 commit
  29. 03 Jun, 2015 1 commit