1. 01 Jul, 2016 1 commit
  2. 20 May, 2016 1 commit
    • Andrei Paskevich's avatar
      Prove_client: wait for the dedicated server process · 6b98a07c
      Andrei Paskevich authored
      this allows to account for the cumulative CPU time spent
      in the dedicated server in the stats of the client process,
      which is necessary to estimate correctly the execution
      time of coqtop on proof scripts using the why3 tactic.
      
      Also, make several connection attempts before giving up.
      6b98a07c
  3. 20 Apr, 2016 1 commit
  4. 15 Apr, 2016 1 commit
    • Andrei Paskevich's avatar
      Prove_client: API refactoring · c39eacf6
      Andrei Paskevich authored
      Do not store socket_name in a reference. Instead, provide two calls:
      [connect_external] that takes the socket name as an argument and
      [connect_internal] that starts a dedicated server on a fresh socket.
      If [Prove_client.send_request] is called when no connection is
      established, it calls [connect_internal].
      
      Rationale: the only reason to have a reference for socket_name is
      to delay the connection request (for example, until the first call
      to [Prove_client.send_request]). However, if the server is already
      running when we set [socket_name], it does not cost us anything to
      establish this connection right away. This is what [connect_external]
      is for. Otherwise, if the server is not running yet, the API client
      must ensure that it will be started before the first [send_request],
      or else the connection request fails. This requires synchronisation
      between the entity that starts the server and the Why3 process. In
      this case, the API client should just call [connect_external] once
      it knows that the server is up and running.
      
      TODO:
      - what is the semantics of [disconnect]? How should we handle the
        tasks in progress?
      - what is the semantics of [max_prover_running] when working with
        an external server?
      - how should we handle server-side disconnects (if at all)?
      c39eacf6
  5. 14 Apr, 2016 2 commits
    • Andrei Paskevich's avatar
      Prove_client: change the "standalone" logic · 39ed26b1
      Andrei Paskevich authored
      1. No default socket name is provided. If Why3 should connect to
         an external server, Prove_client.set_socket_name must be called
         first.
      
      2. If Prove_client.set_socket_name was never called, Why3 assumes
         to be in the stand-alone mode, and will start the server in the
         standard tmp directory (on Unix, $TMPDIR or /tmp, on Win, $TEMP or .).
         The socket name is set to be "why3server.<PID_of_Why3>.sock",
         to avoid clashes with other Why3 processes (fixes the Coq tactic).
      
      3. Global reference Prove_client.standalone is removed.
      
      4. Call_provers does not reexport Prove_client.set_socket_name.
      
      5. Prove_client.connect does nothing if the socket reference is set.
      39ed26b1
    • Johannes Kanig's avatar
      improve handling of runstdin command · 88ce0c36
      Johannes Kanig authored
      88ce0c36
  6. 12 Apr, 2016 1 commit
  7. 10 Apr, 2016 1 commit
  8. 07 Apr, 2016 2 commits
  9. 05 Apr, 2016 1 commit
  10. 25 Mar, 2016 3 commits
  11. 22 Mar, 2016 1 commit
  12. 19 Mar, 2016 1 commit
  13. 17 Mar, 2016 2 commits