Trouble using emacs-w32 from cywgin (emacs-24.5.2) about fstar-mode.el

[cpitclaudel]

Hey Nik,

I'll look into this today; thanks for reporting it. Were you explicitly trying to get F* to play nicely with cygwin, or did you switch for other reasons?

Cheers,
Clément.

[cpitclaudel]

Hey Nik,

Looks like I can't reproduce this. Could you give me a bit more info on your setup?

I used the latest release of F* with Emacs-w32 from a clean Cygwin install. With that setup, processing the following file (with C-RET between each section) doesn't seem to show any problem:

module Test
  let f = "hello"

  let g = "world"

  let h = "!"

The debug output looks like this:

Processing queue
QUERY [#push
module Test
  let f = "hello"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed)
End of buffer
Processing queue
QUERY [#push


  let g = "world"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed processed)
End of buffer
Processing queue
QUERY [#push


  let h = "!"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed processed processed)

Re debug output: there's not much more than (setq fstar-subp-debug t), which you seem to already have.

Will you be at POPL? It might me a good time to look at this quickly, if we don't resolve it by then.

[nikswamy]

Thanks for taking a look, Clement. Much appreciated as always.

The machine I was using has crashed meanwhile. So, I can't repro anymore either. Hope I'll have more to report if/when the machine comes back.

Sent from a mobile device

On Thu, Jan 14, 2016 at 9:37 AM -0800, "Clément Pit--Claudel" [email protected] wrote:

Hey Nik,

Looks like I can't reproduce this. Could you give me a bit more info on your setup?

I used the latest release of F* with Emacs-w32 from a clean Cygwin install. With that setup, processing the following file (with C-RET between each section) doesn't seem to show any problem:

module Test
  let f = "hello"

  let g = "world"

  let h = "!"

The debug output looks like this:

Processing queue
QUERY [#push
module Test
  let f = "hello"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed)
End of buffer
Processing queue
QUERY [#push


  let g = "world"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed processed)
End of buffer
Processing queue
QUERY [#push


  let h = "!"
#end #done-ok #done-nok
]
OUTPUT [
#done-ok
]
RESPONSE [t] []
Queue is empty (processed processed processed)

Re debug output: there's not much more than (setq fstar-subp-debug t), which you seem to already have.

Will you be at POPL? It might me a good time to look at this quickly, if we don't resolve it by then.

---

Reply to this email directly or view it on GitHub:
#29 (comment)

[cpitclaudel]

Thanks for the quick reply. I'll leave this open, feel free to add details if the faulty behaviour returns.

[msprotz]

Hi Clément,

I also now have this behavior. If you're interested in debugging this, feel free to ping me on Skype. Thanks!

[cpitclaudel]

I'm definitely interested in making everything work smoothly for everyone :) Which version of Emacs are you using?

[msprotz]

GNU Emacs 24.5.1 (x86_64-unknown-cygwin, GTK+ Version 3.14.13)
of 2015-06-23 on desktop-new

[cpitclaudel]

Thanks. Can you try to reproduce after running M-: (setq fstar-subp-debug t)? It will create a trace similar to the one that nick posted; hopefully there'll be interesting info there.

Do you think you could zip up your build of F★ and upload it somewhere? I could try reproducing the issue locally :)

[msprotz]

The first message is sent, then I see (in the buffer) QUERY [#push some-fstar-chunk ...], then nothing happens.

Yes, I'll zip up my build.

Maybe it's related to whether I'm running an OCaml F★ or an F# F★ ? I'll try to debug.

[cpitclaudel]

Indeed, it could be an Ocaml/F# thing. The only testing I did on Windows was with the released version. A very useful thing for me would be to see what F★ is getting from Emacs; maybe there's a way to make it write a dump to a file?

[nikswamy]

I tried the f# version without troubles on another build of 24.5.1.

If you give fstar --debug yes, it should dump a file called transcript in the current dir.

Sent from a mobile device

On Wed, Feb 3, 2016 at 7:09 AM -0800, "Clément Pit--Claudel" [email protected] wrote:

Indeed, it could be an Ocaml/F# thing. The only testing I did on Windows was with the released version. A very useful thing for me would be to see what F★ is getting from Emacs; maybe there's a way to make it write a dump to a file?

---

Reply to this email directly or view it on GitHub:
#29 (comment)

[msprotz]

Yes, I can do that but I need to pass an extra argument to F★ (namely, --debug). How can I customize that with the interactive mode?

[cpitclaudel]

Try fstar-subp-prover-args :)

fstar-subp-prover-args is a variable defined in ‘fstar-mode.el’.
Its value is nil

Documentation:
Used for computing arguments to pass to F* in interactive mode.

If set to a string, that string is considered to be a single
argument to pass to F*.  If set to a list of strings, each element
of the list is passed to F*.  If set to a function, that function
is called in the current buffer without arguments, and expected
to produce a string or a list of strings.

Some examples:

- (setq fstar-subp-prover-args "--ab") results in F* being
called as ’fstar.exe --in --ab’.

- (setq fstar-subp-prover-args '("--ab" "--cd")) results in
F* being called as ’fstar.exe --in --ab --cd’.

- (setq fstar-subp-prover-args (lambda () '("--ab" "--cd")))
results in F* being called as ’fstar.exe --in --ab --cd’.

To debug unexpected behaviours with this variable, try
evaluating (fstar-subp-get-prover-args).  Note that passing
multiple arguments as one string will not work: you should use
'("--aa" "--bb"), not "--aa --bb"

You can customize this variable.

So (setq fstar-subp-prover-args '("--debug")) should be enough.

[msprotz]

Ok so I managed to do that. In fstar/fstar.fs, in the interactive_mode function, there's a transcript file where every bit received by F★ from Emacs gets written.

My Emacs got stuck in the following state:

Here's the contents of the Messages buffer:

Started F* interactive with arguments ("--in" "--debug" "Extreme")
Processing queue
QUERY [#push
module Foo
#end #done-ok #done-nok
]
OUTPUT [Opening file: D:\cygwin\home\protz\Code\fstar\lib\prims.fst
]
OUTPUT [Checking module: Prims
]
OUTPUT [
#done-ok
]
RESPONSE [t] [Opening file: D:\cygwin\home\protz\Code\fstar\lib\prims.fst
Checking module: Prims]
Queue is empty (processed)
Processing queue
QUERY [#push









let x = 2
#end #done-ok #done-nok
]

Here's the content of the transcript file once things get stuck:

protz@Joprotze-Z420:/tmp $ cat transcript 
#push
module Foo
#end #done-ok #done-nok

[cpitclaudel]

Interesting. So F★ is not receiving the second message. I wonder why... I can look at this if you send me your binary; if I can reproduce this, things will be much easier to debug.

Can you see if running M-: (process-send-string fstar-subp--process "\n") RET a few times after things get stuck would fix the issue?

[msprotz]

Doesn't help

[cpitclaudel]

@msprotz Can you send the binary? :)

[msprotz]

https://www.dropbox.com/s/dg0k7c98d4ep72q/fstar-bug.tar.bz2?dl=0

[msprotz]

That's the contents of my bin/ folder; I built this F★ using Visual Studio Enterprise 2015 in the Release configuration. Thanks for looking into that!

[msprotz]

Note that a build using the ocaml output didn't have this issue for me, but I can't say that this hasn't happened in the past with the ocaml build of F★.

[cpitclaudel]

Do any of the problems in this thread still happen? If so, can can someone give me a small example that I should run on windows, along with relevant version information? Thanks!

[cpitclaudel]

Assuming fixes. Please reopen if needed :)