[Caml-list] toplevel is hanging
wes...@ilt.fhg.de
I occasionally have a problem with the toplevel running in Emacs (20.4.1, Tuareg mode) under
Windows NT. When I use modules like
module Mymod =
struct
....
end;;
place the cursor at "end;;" and type C-E the toplevel hangs and Emacs doesn't
react any more until I shut down the toplevel in the Windows Task Manager. This happens
not with every "module end;;" construct but I already had some of this situations. When I read
the file with the "module end;;" construct with "#use "file.ml" then it works. Did anybody have
similar experiences and is there any way around?
Rolf Wester
-------------------------------------
Rolf Wester
wes...@ilt.fhg.de
-------------------
To unsubscribe, mail caml-lis...@inria.fr. Archives: http://caml.inria.fr
Mattias Waldau
I really like tuareg, but it hanged my emacs too often.
I tried to understand what went wrong but failed. I think that Windows is
the problem, since the creator of tuareg never gets it.
I use Windows 2000. Are there people out there using tuareg on Windows?
/mattias
David McClain
> I use Windows 2000. Are there people out there using tuareg on Windows?
Yes, I use Tuareg all the time. I'm on Win/NT 4.0 (SP6) and Win/98SE. I am
still using OCaml 3.0 and the Tuareg that was available last May. I'm using
EMACS 20.6.1 and I am still on Cygwin32 B20.
I have been watching these posts on the latest software and it makes me
think I did the right thing to wait a while for the "bleeding edge" issues
to become resolved.
But otherwise, great stuff!! Thanks to INRIA and all the terrific
contributors!
- DM
Chris Hecker
>Did anybody have
>similar experiences and is there any way around?
This sounds very similar to the problem I had running with the toplevel on emacs 20.7.1 and Win2k. If so, it's not Tuareg's fault (I use caml-mode), it's emacs' fault. I thought I posted about this, but I can't find it, so I guess not. I spent an entire day debugging this, including building the compiler, the bytecode runtime, emacs, and debugging a ton of code interacting between the two processes. Here goes:
What's happening is that the toplevel sends a string (either "# ", " ", or "* " depending on if you're in a comment ("* " is only in 3.01), it's seen a ;;, etc.) after every line you send to it. This is what keeps you indented when you do multiline stuff. However, it also sends all those strings even if you're piping code directly do it (it can't tell whether you hit return at the prompt or sent it a \n in a region).
So, there's [what I'd call] a bug in the way process-send-region (which is aliased to comint-send-region, which is what's called to send stuff to consoles inside emacs) handles output. If you have a lot of stuff and you want to send it to the toplevel, process-send-region will write to the process' handle, but not try to read. Well, if it's enough stuff that the OS buffer fills up and emacs blocks on the write, then the other process has to grind through the data to eat it all up and unblock emacs. Unfortunately, the caml toplevel is busy outputting the two-character strings (above) after every "\n" that it sees, and so if you send it a bunch of code, the write pipe back to emacs fills up, because emacs isn't reading from it. So, you just deadlocked the two processes.
There are two fixes:
1. Recompile the toplevel to not output " " and "* " on newlines. This is trivial (make sure you copy the new toplevel lib into your lib dir so ocamlmktop builds the new one). This is what I did, and it fixed the problem (and I don't care about the auto-indent on return at the prompt). The fix is to go to toplevel/toploop.ml, and the function refill_lexbuf near the bottom. There'll be an output_string at the top of the function that outputs one of the strings. Make the " " a "" (and the "* " a "" if you're on 3.01). It's a hack, to be sure, but it's simple and it works.
2. Fix emacs. The documentation for process-send-region says "If the region is more than 500 characters long, it is sent in several bunches. This may happen even for shorter regions. Output from processes can arrive in between bunches." They did this to fix this exact process interlock problem. Of course, this is not what the source code does. The source only breaks up _lines_ that are longer than a certain length, but the problem is the regions we're sending have short lines, but lots of newlines. If the code actually did what the docs say then this wouldn't have happened. I did not feel like messing with the heinous emacs source (this function is particularly beautiful :), so I did #1.
Hope this helps.
As a bonus, this will also fix the weird thing where the error message would be spaced way over in the inferior buffer (I don't know if you have that problem or not). This was because all the spaces got output before the error message.
Chris
PS. As another bonus, here's what I bind to ^C^T. This evals the entire file, which makes it really easy to interactively develop a standalone program (obviously, since I was evaling entire files, I ran into the hang problem pretty early on, once the source got to ~500 lines):
(define-key caml-mode-map "\C-c\C-t"
(lambda ()
"Eval the entire buffer with *inferior-caml*"
(interactive)
(inferior-caml-eval-region (point-min) (point-max))))
wes...@ilt.fhg.de
thanks for your reply. I consider to recompile Ocaml with the changes
outlined by you. For the moment I put the code that makes the toplevel
and Emacs hang in a seperate file and load it with #use "file.ml" (a hack too).
Does anybody know wether this same problem is also present when using
XEmacs instead of Emacs? I installed the WinNT version of XEmacs but
it behaves a little strange. If my problem could be solved by using XEmacs
it could be worth to make XEmacs run correctly (if possible).
Rolf Wester
>
> >Did anybody have
> >similar experiences and is there any way around?
>
> This sounds very similar to the problem I had running with the toplevel on
> emacs 20.7.1 and Win2k. If so, it's not Tuareg's fault (I use caml-mode),
> it's emacs' fault. I thought I posted about this, but I can't find it, so
> I guess not. I spent an entir e day debugging this, including building
> the compiler, the bytecode runtime, emacs, and debugging a ton of code
> interacting between the two processes. Here goes:
>
> What's happening is that the toplevel sends a string (either "# ", " ",
> or "* " depending on if you're in a comment ("* " is only in 3.01), it's
> seen a ;;, etc.) after every line you send to it. This is what keeps you
> indented when you do multiline stuf f. However, it also sends all those
> strings even if you're piping code directly do it (it can't tell whether
> you hit return at the prompt or sent it a \n in a region).
>
> So, there's [what I'd call] a bug in the way process-send-region (which is
> aliased to comint-send-region, which is what's called to send stuff to
> consoles inside emacs) handles output. If you have a lot of stuff and you
> want to send it to the toplevel, p rocess-send-region will write to the
> process' handle, but not try to read. Well, if it's enough stuff that the
> OS buffer fills up and emacs blocks on the write, then the other process
> has to grind through the data to eat it all up and unblock emacs. Unf
> ortunately, the caml toplevel is busy outputting the two-character strings
> (above) after every "\n" that it sees, and so if you send it a bunch of
> code, the write pipe back to emacs fills up, because emacs isn't reading
> from it. So, you just deadlocked t he two processes.
>
> There are two fixes:
>
> 1. Recompile the toplevel to not output " " and "* " on newlines. This
> is trivial (make sure you copy the new toplevel lib into your lib dir so
> ocamlmktop builds the new one). This is what I did, and it fixed the
> problem (and I don't care about the au to-indent on return at the prompt).
> The fix is to go to toplevel/toploop.ml, and the function refill_lexbuf
> near the bottom. There'll be an output_string at the top of the function
> that outputs one of the strings. Make the " " a "" (and the "* " a "" if
> you're on 3.01). It's a hack, to be sure, but it's simple and it works.
>
> 2. Fix emacs. The documentation for process-send-region says "If the
> region is more than 500 characters long, it is sent in several bunches.
> This may happen even for shorter regions. Output from processes can arrive
> in between bunches." They did this to fix this exact process interlock
> problem. Of course, this is not what the source code does. The source
> only breaks up _lines_ that are longer than a certain length, but the
> problem is the regions we're sending have short lines, but lots of
> newlines.
> If the code actually did what the docs say then this wouldn't have
> happened. I did not feel like messing with the heinous emacs source
> (this function is particularly beautiful :), so I did #1.
>
> Hope this helps.
>
> As a bonus, this will also fix the weird thing where the error message
> would be spaced way over in the inferior buffer (I don't know if you have
> that problem or not). This was because all the spaces got output before
> the error message.
>
> Chris
>
> PS. As another bonus, here's what I bind to ^C^T. This evals the entire
> file, which makes it really easy to interactively develop a standalone
> program (obviously, since I was evaling entire files, I ran into the hang
> problem pretty early on, once the so urce got to ~500 lines):
>
> (define-key caml-mode-map "\C-c\C-t"
> (lambda ()
> "Eval the entire buffer with *inferior-caml*"
> (interactive)
> (inferior-caml-eval-region (point-min) (point-max))))
>
Stefan Monnier
>> 2. Fix emacs. The documentation for process-send-region says "If the
>> region is more than 500 characters long, it is sent in several bunches.
>> This may happen even for shorter regions. Output from processes can arrive
>> in between bunches." They did this to fix this exact process interlock
>> problem. Of course, this is not what the source code does. The source
>> only breaks up _lines_ that are longer than a certain length, but the
>> problem is the regions we're sending have short lines, but lots of newlines.
>> If the code actually did what the docs say then this wouldn't have
>> happened. I did not feel like messing with the heinous emacs source
>> (this function is particularly beautiful :), so I did #1.
I can't remember seeing this particular bug-report, but I'll look into it.
Of course, there's a third solution (the one used in sml-mode) which
is for tuareg to use a temporary file.
Stefan
wes...@ilt.fhg.de
could you be so kind and tell me how this can be done. Do I have
do change the Tuareg *.el files or some entries in my .emacs file?
Thank you
Rolf Wester
-------------------------------------
Rolf Wester
wes...@ilt.fhg.de
Michel Schinz
[...]
> > I can't remember seeing this particular bug-report, but I'll look
> > into it. Of course, there's a third solution (the one used in
> > sml-mode) which is for tuareg to use a temporary file.
> >
> Hi Stefan,
>
> could you be so kind and tell me how this can be done. Do I have
> do change the Tuareg *.el files or some entries in my .emacs file?
The easiest thing is to look at Stefan's sml mode and port the code to
Tuareg. If you just want Tuareg to use temporary files, it's pretty
easy. Sml-mode adds some bells and whistles to that (mostly concerning
error handling), which are a bit less trivial to port.
I did that for an enhanced version of the "standard" Caml mode (Leroy,
Zimmerman and Garrigue's one) which is lying, half finished, somewhere
on my harddisk. I'll try to put it in a releasable state soon, if I
can find some time.
Michel.
Xavier Leroy
> 1. Recompile the toplevel to not output " " and "* " on newlines.
I'm willing to add a command-line flag (or an environment variable)
to the OCaml toplevel that will change its output format so that it
works better under Emacs. Suppressing the indentation output as you
described is a good start. I'd be interested to hear suggestions from
those of you that have experience writing "Inferior-xxx" Emacs modes.
(Since this is rather technical, e-mail ca...@inria.fr rather than this
list, thanks.)
- Xavier Leroy