Document how to interrupt busy SerAPI. about coq-serapi HOT 15 CLOSED

That works.

from coq-serapi.

Hi Clément, thanks for the example, it touches many things so I'll try to answer all of them and I cc @gares who may know better:

• This is expected behavior as of now, Coq is busy completing your observing command, note that you didn't get the Completed answer. Thus, your next Control command is just queued.
• I didn't document the proper way to interrupt SerAPI, (sending it a signal), this is a TODO.
• SerAPI doesn't enable any asynchronous processing for now. I am trying to do it but true async processing in Coq comes with significant limitations so we should assume Coq behaves synchronously for now.
• I've added a link to a bit of Stm documentation to the README. In particular, note that Add always returns the StmInfo with the stateId, you don't need to wait for the feedback. Secondly, note that your last Add is incorrect, you are adding at state 2 without doing an EditAt.
• Third, I've got a version of Add that can add the whole/parts of the document almost running! However, it needs a bit of API change in the Stm but IMHO that should go throu.

Best, E.

from coq-serapi.

I've renamed the issue as IMO we need to document what is SerAPI behavior when it is busy. The way things work now are:

• A control command is considered busy if SerAPI didn't emit a Completed answer.

• You can abort the current command by sending a signal, then SerAPI will print Interrupted and the state will go back to the exact point before the control command.

  (this is a TODO, there are slight race conditions here unfortunately at the level of Coq, but it shouldn't worry us too much).

from coq-serapi.

Thanks for the clarification :) I the long run, I think it would be really nice to decouple queuing and processing; that is, it would be really nice if the IDE could send multiple enqueues and get state ids for them, regardless of whether the underlying process is busy.

I just tried it in CoqIDE, and indeed it doesn't work there either (you can't enqueue more things while it's busy). I guess I can simulate this on the IDE side :)

from coq-serapi.

You can get multiple StateId for multiple adds, it is only when "observing" them that Coq will get busy.
So the question is, can we make Coq "observe" in a different thread.

Indeed that should be possible in CoqIDE did you see
https://coq.inria.fr/refman/Reference-Manual031.html?

The main problem is that this mode is still very experimental and has many limitations due to Coq's imperative nature; however SerAPI should be able to async "Observe" some day too.

from coq-serapi.

Also, coqide -debug will print a DAG of the document to /tmp. This may give you an idea on how the document could look in the end.

from coq-serapi.

Neat :) No hurry; I'm just getting started in understanding these things.

from coq-serapi.

Some bits of intel I've gathered in my unfortunate experience with the
protocol:

• indeed the intent of the state id in the input of the add command is not
  to tell to which state to add the sentence to, but just to assert what the
  current state should be. It's weird.
• upon errors, you will get notified both by a valuefail and by an errormsg
  feedback. The former will carry the last valid state while the latter will
  carry the failed state. In my experience, on the ide side, you will want to
  process all the current feedback before looking at the value, as it might
  refer to a state that has only been known to be processing from the current
  set of feedback messages.
• something I still don't understand is whether there's a way to get coq to
  deliver feedback independently from queries. Right now in PeaCoq I
  periodically send a status message because I don't hear back from feedback
  messages until I process another command. Does this not happen to either of
  you? Do you know what I could be doing wrong?

I am following all of your commits and ideas silently by the way. I'm just
away from my laptop this weekend. :) Keep up the cool work.

On Sun, Jun 12, 2016, 04:37 Emilio Jesús Gallego Arias <
[email protected]> wrote:

Hi Clément, thanks for the example, it touches many things so I'll try to
answer all of them and I cc @gares https://github.com/gares who may
know better:

This is expected behavior as of now, Coq is busy completing your
observing command, note that you didn't get the Completed answer.
Thus, your next Control command is just queued.

I didn't document the proper way to interrupt SerAPI, (sending it a
signal), this is a TODO.

SerAPI doesn't enable any asynchronous processing for now. I am trying
to do it but true async processing in Coq comes with significant
limitations so we should assume Coq behaves synchronously for now.

I've added a link to a bit of Stm documentation to the README. In
particular, note that Add always returns the StmInfo with the stateId,
you don't need to wait for the feedback. Secondly, note that your last
Add is incorrect, you are adding at state 2 without doing an EditAt.

Third, I've got a version of Add that can add the whole/parts of the
document almost running! However, it needs a bit of API change in the Stm
but IMHO that should go throu.

Best, E.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAdNjvYYzzoXE-BUn_cywbfMqm5Sw_yrks5qK-9_gaJpZM4IzsV1
.

from coq-serapi.

Hi @Ptival , thanks for your comments! I'll reply in order:

• I dunno how it goes in the XML protocol, but in the Stm API and SerAPI the state_id indeed corresponds to the ~ontop' parameter, that is, which state to add the sentence to. Do you mean the?newtipparameter? Or are you talking aboutedit_id` ?
• This incosistency is fixed by coq/coq#203. If merged (I hope) feedback canonically corresponds to a particular chunk of program or state_id.
• I am not sure I understand what you mean here. Do you have an example of "feedback independent from queries"?

Thanks for the comments again! Let me know of any problem/suggestion/need of PeaCoq !

from coq-serapi.

@ejgallego All my points were describing the XML protocol. The Stm API seems better designed than what is exposed by the XML protocol.

For the third point, it might actually be an issue with how I set up my code to work actually. Since I'm using HTTP and not something more streamy like websockets, I can only send responses to the client in some synchronous way. So feedback messages are buffered until the client emits another message. I will look into making this better, probably starting to build upon serapi.

As for my other needs, the one I can think of right now is a way to restart coqtop with a new set of arguments. If you can already do that, it should be pretty perfect.

from coq-serapi.

Hi @Ptival ! Indeed that is Add problem seems weird, if you want to provide more details by mail Enrico and I may be able to help, the xml protocol should implement Stm.add directly (see ide_slave.ml:add).

Regarding the sockets part, by default Coq is fully synchronous and will emit all the feedback messages before returning from the call. Feedback.set_feeder is called, note however than a ML pluging/toplevel may chose to queue the messages.

I am extremely interested in the last point, could you elaborate on the concrete need? What is the cmdline that you need to change?

Note that one design choice of SerAPI is to break with Coq legacy command line options. Indeed, I'd love to get rid of all of them, but not sure it is a good idea.

Cheers,
E.

from coq-serapi.

I have pushed a minimal async API in ca3d7b5 , it could be more convenient in your context if you want to be event-based.

from coq-serapi.

For my last need, I think it was partially adressed in another of your comments. It really is two things:

• the ability to restart the process
• the ability to pass in _CoqProject arguments/options

For the ability to restart the process, it is not that I need it, but rather than in my experience, as time goes, if I keep sending sentences and using EditAt 0 to rewind, the coqtop process will gradally become ever-so slower. This could have been either an issue of my Haskell layer, or an intrinsic coqtop issue, and I have not yet examined further.
A hard process reset would fix this.

For the argument/options, I just need to be able to pass them, but as you mentioned, you can do it via some commands.

from coq-serapi.

Hi Valentin!

For restarting the process I would just kill it. Does that not work?

Regarding the arguments, I'd be happy to support them, just open a new issue for each concrete argument please.

As I've mentioned in some other issue, setting loadpaths can be done with the (Control (LibAdd xx)) command, feel free to complain about this approach if it badly covers your particular use case.

Best,
E

from coq-serapi.

Cool! Let me know of anything else. I'm looking forward to try PeaCoq again soon!

from coq-serapi.