Commits

Peter Szilagyi  committed 6f47052 Merge
  • Participants
  • Parent commits 8077579, 5e05cb5

Comments (0)

Files changed (4)

File TODO.org

-# -*- mode: org -*-
-#+STARTUP: indent
-
-* Feature requests
-** Delete trailing blank lines in ocaml files.  --mstanojevic
-* Open
-** Omake.next-error is slow on large builds
-*** sweeks
-I am doing a build of our main repo, with about 75k targets
-and 50 errors. Running next-error takes 5-10 seconds to run. I think
-the performance of this used to be OK. I haven't done a large build in
-a while, so I guess this problem was introduced in the last month.
-
-*** sweeks
-I should add that there was no obvious CPU use of emacs or
-omake_server while I was waiting. I never saw their CPU use move about
-2% during the 5-10%.
-
-
-** omake-mode degrading emacs keystroke performance
-*** sweeks
-I have two emacsen running on the same machine, with the only
-difference being that one is connected to omake-server doing a build
-and the other isn't connected to omake server. The visible response of
-keypresses (especially with hold to repeat) is much better in the
-emacs that isn't talking to omake server. If I stop the build, the
-emacs talking to omake server gets better, but it's still worse than a
-clean emacs. If I stop omake server, then the emacs reverts to good
-keypress resposiveness.  I think there's room for improvement in
-interfering less with emacs. I find that the poor responsiveness with
-a build running negatively affects my interaction with emacs.
-
-*** sweeks
-I just compared the keystroke responsiveness of tip to that of
-the most recent roll to test here, 705108ac39fe. Things have gotten
-much worse in the last month. I think this issue needs to be
-addressed. The responsiveness is bad enough that I'm switching back to
-705108ac39fe.
-
-** omake-server spinning at 100%+ CPU
-*** sweeks
-Ron hit a case today in which his omake_server_test.exe was spinning
-using 110% CPU. There was one other omake_server_test.exe process
-running, with arguments "server running", and it was hung not using
-CPU, I believe since the time the server started spinning.  The
-mode-log for the relevant emacs was last updated at the time the
-server started spinning. Here's the tail of the log.
-
-Async   : server ping -counter 511 -pid 29122 -version 13
-Read    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))\n
-Eval    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
-Server  : (Omake.Ping.ack 511)
-Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
-Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
-Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
-Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
-Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
-Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
-Here's the tail of the server log.
-
-[2012-07-25 09:48:20.597985] omake server received: (Ping 29122((version 13)(uid 511)))
-[2012-07-25 09:48:20.598030] Writing: (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
-[2012-07-25 09:48:20.714021] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
-[2012-07-25 09:48:21.717247] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
-I did an strace on the spinning omake server, and didn't see much. I did notice that there weren't any calls to select, other than from the OCaml ticker thread. So async cycles weren't running. That seems to point to an infinite loop within an async job as opposed to an infinite loop continually running new jobs.
-
-*** sweeks
-Ron adds that his entire emacs was hung when the problem happened.
-
-*** seanmcl
-It would be cool if there were a way to send the server a
-message saying 'print a stack trace on stdout'.  Where can I learn
-more about the ocaml ticker thread? For example, I don't know how you
-inferred your comment about the select calls.
-
-*** seanmcl
-Interestingly, there are only two 'let rec' calls in the
-entire program. One 'Error.dedup' is obviously terminating by
-induction on the input. The second 'Files.omakeroot_dir' walks up the
-file name for omakeroot_dir. It is less obvious that it terminates
-since it's dealing with a string, and while the string usually gets
-smaller, Filename.dirname "/" == "/". But I check for that case, so I
-don't see any obvious looping.
-
-*** seanmcl
-I'm putting this on hold, since I haven't heard anything in over a month.
-
-*** sweeks
-Sam E caused omake-server to spin using 100% CPU several times today. Interestingly, on the last one, while we were looking into it, omake-server stopped spinning, and appeared to continue functioning normally. It now seems likely to me there is a quadratic (or worse) performance issue in omake server's processing of omake output. Regexps are always a good candidate.
-Here is the tail of the project-log.
-
-[2012-09-06 11:11:44.481373] New output
-[2012-09-06 11:11:44.534868] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
-[2012-09-06 11:11:45.034537] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
-[2012-09-06 11:11:45.481933] New output
-[2012-09-06 11:11:46.536472] New output
-[2012-09-06 11:11:51.713523] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 6.1s
-[2012-09-06 11:11:55.892051] New output
-[2012-09-06 11:11:55.901067] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
-[2012-09-06 11:12:14.752257] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 7.3s
-[2012-09-06 11:12:32.609426] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 25s
-[2012-09-06 11:12:43.124088] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 35s
-[2012-09-06 11:12:43.126133] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
-[2012-09-06 11:13:07.277727] New output
-[2012-09-06 11:13:08.288586] New output
-The "omake did not reach EOF for" warnings fit with omake server spinning on something computational, preventing the async file-tail job from getting a chance to run.
-
-The raw buffer is small, 137,361 bytes. However, it has some very long lines (10k characters), further pointing at something superlinear in line length like regexp handling. Here are the line lengths:
-
-41
-89
-92
-89
-29
-77
-16
-43
-26
-48
-28
-28
-28
-31
-36
-25
-56
-89
-24
-38
-41
-7594
-115
-114
-110
-188
-115
-114
-110
-109
-115
-114
-110
-123
-32
-43
-47
-43
-9714
-17
-61
-89
-60
-215
-32
-56
-47
-56
-10048
-17
-61
-89
-73
-202
-32
-43
-47
-43
-9996
-17
-61
-89
-60
-208
-32
-49
-47
-49
-10020
-17
-61
-89
-66
-210
-32
-51
-47
-51
-10028
-17
-61
-89
-68
-210
-32
-51
-47
-51
-10028
-17
-61
-89
-68
-268
-45
-82
-213
-46
-57
-38
-57
-53
-57
-10034
-23
-67
-95
-74
-44
-55
-38
-55
-53
-55
-10026
-23
-67
-95
-72
-46
-57
-38
-57
-53
-57
-10034
-23
-67
-95
-74
-38
-49
-38
-49
-53
-49
-10002
-23
-67
-95
-66
-51
-62
-38
-62
-53
-62
-10054
-23
-67
-95
-79
-38
-49
-38
-49
-53
-49
-9720
-23
-67
-95
-66
-41
-All the long lines were of the form:
-
-      + ../../../bin/link-quietly ocamlopt.opt ...
-where the "..." is lots of -I switches and libraries.
-
-I don't see that omake-server even needs to understand such lines, so
-perhaps we could put a simple hack in to just not process them.
-
-*** seanmcl
-Yeah, any line may go through 13 regexp calls, some of which
-have a number of alternations. I'd rather not tinker with Pcre or the
-regular expressions themselves. I like your idea of filtering
-problematic lines. I ran the server on a file with very long lines,
-but it terminated quickly. There must have been some property of Sam's
-particular lines.
-
-** Stopping omake server leaves around omake processes
-*** sweeks
-If I run "controller stop" from the command line, omake server leaves
-around the omake processes that it was managing.
-
-*** seanmcl
-Ug. Right. Maybe service_command could have an argument that runs some
-cleanup code before stopping the daemon. I'll have to dig into the
-commands themselves to get the behavior I want.
-
-*** seanmcl
-Now we use service_command's start, but the old stop which kills the
-children processes. On hold whether we should fix service_command to
-install a signal handler for sigint.
-
-*** sweeks
-I chatted with Nathan about this. He agrees that [Service_command]
-should handle SIGTERM and call [exit] so that [at_exit] handlers can
-run.  He also pointed out that [Service_command] may be going away
-from [Core_extended], being replaced by something that subsumes it,
-but is also more tied to being inside Jane Street.
-
-To make progress now, how about you fix [Service_command] in your
-clone of Core to do this?
-
-** After closing dedicate omake status frame, C-c C-c dies
-*** mml
-with "Wrong type argument: frame-live-p, #<dead frame Emacs: 0x1d869540>
-
-*** seanmcl
-I run into this sometimes in other packages. Emacs gets
-confused somehow by referring to a dead frame. In emergencies you can
-do: run this if you can't kill a buffer due to a dead-frame error
-(setq menu-updating-frame nil) but I'll work on finding why it's
-happening to omake-mode.
-
-** Remove 'watching' a project from user consideration.
-
-*** seanmcl
-Now the only way to kill a project will be from the projects window or
-command line. It will significantly simplify the user interface.
-
-** omake-mode just hangs when omake runs out of memory
-*** seanmcl
-I'm running on a low-memory virtual OS, and while building core I ran
-out of memory. Omake-mode just hung, even though there was a readable
-message in the raw output:
-
-{{{
-:* omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
-[===========================================================   ] 03857 / 03954
-
-:* omake: targets were not rebuilt because of errors:
-   core_extended-108.07.00/lib/patience_diff.cmx
-      depends on: core_extended-108.07.00/lib/patience_diff.ml
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib patience_diff.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
-      Fatal error: exception Out_of_memory
-      Called from file "arg.ml", line 216, characters 4-32
-      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
-   core_extended-108.07.00/lib/patience_diff.o
-      depends on: core_extended-108.07.00/lib/patience_diff.ml
-   core_extended-108.07.00/lib/procfs.cmx
-      depends on: core_extended-108.07.00/lib/procfs.ml
-      - build core_extended-108.07.00/lib procfs.cmx
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib procfs.cmx
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
-      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
-   core_extended-108.07.00/lib/procfs.o
-      depends on: core_extended-108.07.00/lib/procfs.ml
-   core_extended-108.07.00/lib/readline.cmx
-      depends on: core_extended-108.07.00/lib/readline.ml
-   core_extended-108.07.00/lib/readline.o
-      depends on: core_extended-108.07.00/lib/readline.ml
-      - build core_extended-108.07.00/lib readline.o
-      + <compute 1 value dependencies>
-      - build core_extended-108.07.00/lib readline.o
-      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
-      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
-:* omake: polling for filesystem changes
-}}}
-
-** error flickers between brown and white in omake status buffer
-*** moconnor (via pszilagyi): noticed this with a single error,
-latest prod release (2012-12-03), and Emacs 24.
-*** pszilagyi: I think I've seen it, too.
-* Hold
-
-* Closed
-

File todo/Jane.haskell.patch

+diff --git a/elisp/jane/jane-micro-features.el b/elisp/jane/jane-micro-features.el
+--- a/elisp/jane/jane-micro-features.el
++++ b/elisp/jane/jane-micro-features.el
+@@ -488,7 +560,7 @@
+ 
+ ;; (Jane.haskell)
+ (defun Jane.haskell ()
+-  (require 'haskell-site-file)
++  (load-library "haskell-site-file")
+   (require 'haskell-mode)
+   (require 'haskell-indent)
+   (add-hook 'haskell-mode-hook

File todo/TODO.org

+# -*- mode: org -*-
+#+STARTUP: indent
+
+* Notes
+
+Things to think on:
+
+  - How do I submit an issue?
+  - How do I comment on an issue?
+  - How do I close an issue?
+  - How are the maintainers notified when I do any of the above?
+
+** Opening issues
+
+*** Structure
+
+Please use the following structure for issues:
+
+\** SUMMARY
+\*** USER:
+comment
+\*** USER:
+comment
+...
+
+*** Preformatted blocks
+
+Be careful of * on the front of lines, especially
+in omake output.  If there are stars org-mode will think they are
+headers.  Either escape the first star on any line of output,
+or use an EXAMPLE block that protect stars.
+
+To insert an example block, use
+
+#+BEGIN_EXAMPLE
+    block
+      with
+         structure
+      I want
+    to keep
+    *** omake:
+#+END_EXAMPLE
+
+*** Including files
+
+To include a file, say a patch or output, copy the file to this
+directory and save the link with double square brackets, e.g.
+
+[[file:./FILE]]
+
+which makes a link.  Follow the link using C-c C-o `org-open-at-point'.
+
+*** Adding comments
+
+Include your comment at the bottom of the issue/conversation, so they
+are in chronological order from top to bottom.
+
+** Closing issues
+
+Move the issue to the bottom of the `Closed' section.
+
+* Feature requests
+** Delete trailing blank lines in ocaml files.  --mstanojevic
+* High
+** omake-mode degrading emacs keystroke performance
+*** sweeks
+I have two emacsen running on the same machine, with the only
+difference being that one is connected to omake-server doing a build
+and the other isn't connected to omake server. The visible response of
+keypresses (especially with hold to repeat) is much better in the
+emacs that isn't talking to omake server. If I stop the build, the
+emacs talking to omake server gets better, but it's still worse than a
+clean emacs. If I stop omake server, then the emacs reverts to good
+keypress resposiveness.  I think there's room for improvement in
+interfering less with emacs. I find that the poor responsiveness with
+a build running negatively affects my interaction with emacs.
+
+*** sweeks
+I just compared the keystroke responsiveness of tip to that of
+the most recent roll to test here, 705108ac39fe. Things have gotten
+much worse in the last month. I think this issue needs to be
+addressed. The responsiveness is bad enough that I'm switching back to
+705108ac39fe.
+
+** Omake.next-error is slow on large builds
+*** sweeks
+I am doing a build of our main repo, with about 75k targets
+and 50 errors. Running next-error takes 5-10 seconds to run. I think
+the performance of this used to be OK. I haven't done a large build in
+a while, so I guess this problem was introduced in the last month.
+
+*** sweeks
+I should add that there was no obvious CPU use of emacs or
+omake_server while I was waiting. I never saw their CPU use move about
+2% during the 5-10%.
+
+** omake-server spinning at 100%+ CPU
+*** sweeks
+Ron hit a case today in which his omake_server_test.exe was spinning
+using 110% CPU. There was one other omake_server_test.exe process
+running, with arguments "server running", and it was hung not using
+CPU, I believe since the time the server started spinning.  The
+mode-log for the relevant emacs was last updated at the time the
+server started spinning. Here's the tail of the log.
+
+Async   : server ping -counter 511 -pid 29122 -version 13
+Read    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))\n
+Eval    : (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
+Server  : (Omake.Ping.ack 511)
+Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
+Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
+Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
+Read    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))\n
+Eval    : (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
+Server  : (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t)
+Here's the tail of the server log.
+
+[2012-07-25 09:48:20.597985] omake server received: (Ping 29122((version 13)(uid 511)))
+[2012-07-25 09:48:20.598030] Writing: (progn (Omake.Server.logf "Server  : (Omake.Ping.ack 511)") (Omake.Ping.ack 511))
+[2012-07-25 09:48:20.714021] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
+[2012-07-25 09:48:21.717247] Writing: (progn (Omake.Server.logf "Server  : (load \"/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el\" t t t)") (load "/tmp/omake-server/yminsky/mnt/local/sda1/yminsky/jane/live-prod/elisp.el" t t t))
+I did an strace on the spinning omake server, and didn't see much. I did notice that there weren't any calls to select, other than from the OCaml ticker thread. So async cycles weren't running. That seems to point to an infinite loop within an async job as opposed to an infinite loop continually running new jobs.
+
+*** sweeks
+Ron adds that his entire emacs was hung when the problem happened.
+
+*** seanmcl
+It would be cool if there were a way to send the server a
+message saying 'print a stack trace on stdout'.  Where can I learn
+more about the ocaml ticker thread? For example, I don't know how you
+inferred your comment about the select calls.
+
+*** seanmcl
+Interestingly, there are only two 'let rec' calls in the
+entire program. One 'Error.dedup' is obviously terminating by
+induction on the input. The second 'Files.omakeroot_dir' walks up the
+file name for omakeroot_dir. It is less obvious that it terminates
+since it's dealing with a string, and while the string usually gets
+smaller, Filename.dirname "/" == "/". But I check for that case, so I
+don't see any obvious looping.
+
+*** seanmcl
+I'm putting this on hold, since I haven't heard anything in over a month.
+
+*** sweeks
+Sam E caused omake-server to spin using 100% CPU several times today. Interestingly, on the last one, while we were looking into it, omake-server stopped spinning, and appeared to continue functioning normally. It now seems likely to me there is a quadratic (or worse) performance issue in omake server's processing of omake output. Regexps are always a good candidate.
+Here is the tail of the project-log.
+
+[2012-09-06 11:11:44.481373] New output
+[2012-09-06 11:11:44.534868] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
+[2012-09-06 11:11:45.034537] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
+[2012-09-06 11:11:45.481933] New output
+[2012-09-06 11:11:46.536472] New output
+[2012-09-06 11:11:51.713523] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 6.1s
+[2012-09-06 11:11:55.892051] New output
+[2012-09-06 11:11:55.901067] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
+[2012-09-06 11:12:14.752257] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 7.3s
+[2012-09-06 11:12:32.609426] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 25s
+[2012-09-06 11:12:43.124088] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake did not reach EOF for 35s
+[2012-09-06 11:12:43.126133] File_tail warning: /tmp/omake-server/sehrlichman/mnt/local/sda1/sehrlichman/trees/hedger-tools.108.05.00.00/omake reached EOF
+[2012-09-06 11:13:07.277727] New output
+[2012-09-06 11:13:08.288586] New output
+The "omake did not reach EOF for" warnings fit with omake server spinning on something computational, preventing the async file-tail job from getting a chance to run.
+
+The raw buffer is small, 137,361 bytes. However, it has some very long lines (10k characters), further pointing at something superlinear in line length like regexp handling. Here are the line lengths:
+
+41
+89
+92
+89
+29
+77
+16
+43
+26
+48
+28
+28
+28
+31
+36
+25
+56
+89
+24
+38
+41
+7594
+115
+114
+110
+188
+115
+114
+110
+109
+115
+114
+110
+123
+32
+43
+47
+43
+9714
+17
+61
+89
+60
+215
+32
+56
+47
+56
+10048
+17
+61
+89
+73
+202
+32
+43
+47
+43
+9996
+17
+61
+89
+60
+208
+32
+49
+47
+49
+10020
+17
+61
+89
+66
+210
+32
+51
+47
+51
+10028
+17
+61
+89
+68
+210
+32
+51
+47
+51
+10028
+17
+61
+89
+68
+268
+45
+82
+213
+46
+57
+38
+57
+53
+57
+10034
+23
+67
+95
+74
+44
+55
+38
+55
+53
+55
+10026
+23
+67
+95
+72
+46
+57
+38
+57
+53
+57
+10034
+23
+67
+95
+74
+38
+49
+38
+49
+53
+49
+10002
+23
+67
+95
+66
+51
+62
+38
+62
+53
+62
+10054
+23
+67
+95
+79
+38
+49
+38
+49
+53
+49
+9720
+23
+67
+95
+66
+41
+All the long lines were of the form:
+
+      + ../../../bin/link-quietly ocamlopt.opt ...
+where the "..." is lots of -I switches and libraries.
+
+I don't see that omake-server even needs to understand such lines, so
+perhaps we could put a simple hack in to just not process them.
+
+*** seanmcl
+Yeah, any line may go through 13 regexp calls, some of which
+have a number of alternations. I'd rather not tinker with Pcre or the
+regular expressions themselves. I like your idea of filtering
+problematic lines. I ran the server on a file with very long lines,
+but it terminated quickly. There must have been some property of Sam's
+particular lines.
+
+** Stopping omake server leaves around omake processes
+*** sweeks
+If I run "controller stop" from the command line, omake server leaves
+around the omake processes that it was managing.
+
+*** seanmcl
+Ug. Right. Maybe service_command could have an argument that runs some
+cleanup code before stopping the daemon. I'll have to dig into the
+commands themselves to get the behavior I want.
+
+*** seanmcl
+Now we use service_command's start, but the old stop which kills the
+children processes. On hold whether we should fix service_command to
+install a signal handler for sigint.
+
+*** sweeks
+I chatted with Nathan about this. He agrees that [Service_command]
+should handle SIGTERM and call [exit] so that [at_exit] handlers can
+run.  He also pointed out that [Service_command] may be going away
+from [Core_extended], being replaced by something that subsumes it,
+but is also more tied to being inside Jane Street.
+
+To make progress now, how about you fix [Service_command] in your
+clone of Core to do this?
+
+** After closing dedicate omake status frame, C-c C-c dies
+*** mml
+with "Wrong type argument: frame-live-p, #<dead frame Emacs: 0x1d869540>
+
+*** seanmcl
+I run into this sometimes in other packages. Emacs gets
+confused somehow by referring to a dead frame. In emergencies you can
+do: run this if you can't kill a buffer due to a dead-frame error
+(setq menu-updating-frame nil) but I'll work on finding why it's
+happening to omake-mode.
+
+** Remove 'watching' a project from user consideration.
+
+*** seanmcl
+Now the only way to kill a project will be from the projects window or
+command line. It will significantly simplify the user interface.
+
+** omake-mode just hangs when omake runs out of memory
+*** seanmcl
+I'm running on a low-memory virtual OS, and while building core I ran
+out of memory. Omake-mode just hung, even though there was a readable
+message in the raw output:
+
+#+BEGIN_EXAMPLE
+ * omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
+[===========================================================   ] 03857 / 03954
+
+ * omake: targets were not rebuilt because of errors:
+core_extended-108.07.00/lib/patience_diff.cmx
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
+Fatal error: exception Out_of_memory
+Called from file "arg.ml", line 216, characters 4-32
+      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
+core_extended-108.07.00/lib/patience_diff.o
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+core_extended-108.07.00/lib/procfs.cmx
+depends on: core_extended-108.07.00/lib/procfs.ml
+      - build core_extended-108.07.00/lib procfs.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib procfs.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
+      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
+core_extended-108.07.00/lib/procfs.o
+depends on: core_extended-108.07.00/lib/procfs.ml
+core_extended-108.07.00/lib/readline.cmx
+depends on: core_extended-108.07.00/lib/readline.ml
+core_extended-108.07.00/lib/readline.o
+depends on: core_extended-108.07.00/lib/readline.ml
+      - build core_extended-108.07.00/lib readline.o
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib readline.o
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
+      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
+ * omake: polling for filesystem changes
+#+END_EXAMPLE
+
+** improve support for error messages from compiling C
+*** sweeks:
+We compile C code using OMake. Right now, errors in C lead to
+{{{ Compilation was not successful, but it's stopped and there are no errors. Something is wrong }}}
+
+It would be good for these to produce errors that are visited in the ordinary way, with Omake.next-error.
+
+** Improve user feedback when querying ocamlspotter fails
+*** sweeks:
+Perhaps we could improve emacs's behavior when querying ocamlspotter for a type fails. It would be nice to give the user some indication of why it failed. Right now, I think it's often silent.
+E.g. If ocamlspotter fails with
+
+Warning: source z.ml is newer than the spot
+then I think this doesn't make it back to the user.
+** Jane.find-file-in-project should commit to unique matches
+*** mml:
+say there is one file in my repo named comment.ml. If I do
+Jane.fine-file-in-project and type comment.ml and hit enter, I get
+Possible completions are: comment.ml in dev/code-review/cr-server/
+comment.mli in dev/code-review/cr-server/
+
+I'd the function just went ahead and picked comment.ml since that is
+the only file of that (base)name.
+*** mstanojevic:
+I've noticed this as well. Workaround is to type space after the
+filename and then enter and it will choose the file you want.
+
+** Opensource license
+*** seanmcl:
+We don't have a LICENSE file. Choose one, probably the same as core.
+** Scan server log for errors
+*** seanmcl:
+Now when the server encounters an error, it dutifully logs it, but the
+log is only inspected haphazardly. We should scan the logs
+periodically and alert the user somehow that an error has
+occurred. Perhaps the command line tool will warn about it when
+running any command, an/or it could be sent to all Emacs processes.
+
+** Keybindings for projects buffer
+*** sweeks:
+How about
+q for quit d for delete project
+
+(like dired)
+
+** error flickers between brown and white in omake status buffer
+*** moconnor (via pszilagyi):
+noticed this with a single error, latest prod release (2012-12-03),
+and Emacs 24.
+*** pszilagyi:
+I think I've seen it, too.
+** Unit test failures
+*** seanmcl
+I played around with this a bit more. It is easy to make unit tests
+fail. E.g. in core/lib_test, use a prefix argument to OMake.compile
+and run "jomake runtest" rather than the usual "jomake". You can then
+edit one of the unit tests (e.g. bigstring_test.ml) to put in an
+[assert false].
+
+Every way I've tried this, I get omake mode to report
+
+Compilation was not successful, but it's stopped and there are no
+errors. Something is wrong
+
+I don't know how to mix a type error with a unit-test error.
+
+Looking at Ron's output again, it looks to me like we might be able to
+fix this problem without reproducing it. Perhaps the parser for omake
+output could recognize a line that identifies a (phony?) target like
+
+<phony <base/core/lib_test/command-tests/check>>
+
+and end the current error message at that target?
+
+** Bitbucket docs
+*** seanmcl:
+Make a wiki and readme for external users.
+** Omake mode just hangs when low on memory
+*** seanmcl:
+I'm running on a low-memory virtual OS, and while building core I ran out of memory. Omake-mode just hung, even though there was a readable message in the raw output:
+\*** omake: blocked (25 min 04.50 sec, 10/777 scans, 1387/2133 rules, 1907/7179 digests)
+[===========================================================   ] 03857 / 03954
+
+\*** omake: targets were not rebuilt because of errors:
+core_extended-108.07.00/lib/patience_diff.cmx
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib patience_diff.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo [[../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/patience_diff.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c patience_diff.ml
+Fatal error: exception Out_of_memory
+Called from file "arg.ml", line 216, characters 4-32
+      - exit core_extended-108.07.00/lib patience_diff.cmx, 55.11 sec, code 2
+core_extended-108.07.00/lib/patience_diff.o
+depends on: core_extended-108.07.00/lib/patience_diff.ml
+core_extended-108.07.00/lib/procfs.cmx
+depends on: core_extended-108.07.00/lib/procfs.ml
+      - build core_extended-108.07.00/lib procfs.cmx
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib procfs.cmx
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -pp 'camlp4o   ../../lib/pa_type_conv/pa_type_conv.cmo ../../lib/pa_sexp_conv/pa_sexp_conv.cmo ../../lib/pa_bin_prot/pa_bin_prot.cmo ../../lib/pa_fields_conv/pa_fields_conv.cmo ../../lib/pa_variants_conv/pa_variants_conv.cmo ../../lib/pa_compare/pa_compare.cmo ../../lib/pa_pipebang/pa_pipebang.cmo ../../lib/pa_ounit/pa_ounit.cmo pa_macro.cmo -pa-ounit-ident core_extended-108.07.00/lib/procfs.ml' -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -I ../../lib/oUnit -I ../../lib/sexplib -for-pack Core_extended -c procfs.ml
+      - exit core_extended-108.07.00/lib procfs.cmx, 2 min 16.04 sec, code 127
+core_extended-108.07.00/lib/procfs.o
+depends on: core_extended-108.07.00/lib/procfs.ml
+core_extended-108.07.00/lib/readline.cmx
+depends on: core_extended-108.07.00/lib/readline.ml
+core_extended-108.07.00/lib/readline.o
+depends on: core_extended-108.07.00/lib/readline.ml
+      - build core_extended-108.07.00/lib readline.o
+      + <compute 1 value dependencies>
+      - build core_extended-108.07.00/lib readline.o
+      + ocamlopt.opt -I +camlp4 -thread -w @a-4-7-29-28-9 -strict-sequence -annot -inline 20 -nodynlink -g -I ../../lib/bin_prot -I ../../lib/fieldslib -I ../../lib/sexplib -I ../../lib/variantslib -I ../../lib/core -I ../../lib/pcre -for-pack Core_extended -c readline.ml
+      - exit core_extended-108.07.00/lib readline.o, 39.92 sec, code 127
+\*** omake: polling for filesystem changes
+
+** Push our tuareg changes
+*** seanmcl:
+Our copy of Tuareg has changes Christophe's doesn't. Push them upstream.
+
+** Improve feedback when an invalid command is supplied to Omake.compile
+*** sweeks:
+When one uses a prefix arg to supply a command to Omake.compile, and
+then supplies an invalid command, the feedback to the user could be
+improved. Currently, the status buffer says: Progress : No files
+processed yet [ | ]
+
+FATAL ERROR: The omake process is dead.
+
+and there is an "exec failed" message in the raw buffer. It would be
+good to get the "exec failed" message into the status buffer. It seems
+like omake server should have a pretty good idea what's going on, and
+should be able to communicate it to emacs.
+
+We also briefly confused ourselves by not distinguishing "omake
+process" from the error message, and "omake server", thinking that the
+error message meant the omake server was dead, when it wasn't. We were
+misremembering the other error message.
+
+ERROR: The server is not responding.
+
+wonder whether the use of "FATAL ERROR" and the red coloring is too
+much in this case. IMO, the server being down is much more serious
+(typically indicating a bug) than omake exiting, which may just
+indicate user error. Perhaps we should use purple for server down. Or
+stop using red for "The omake process is dead." Also, maybe the text
+could be improved, perhaps eliminating the word "process". How about:
+
+ERROR: omake is not running
+
+BTW, this came up when a user tried to set an environment variable
+using bash syntax in a custom command line (rather than
+Omake.toggle-env). Perhaps we could do something to make clear what
+language is allowed when a command is specified (i.e. not bash), and
+to preempt even trying to run omake when the command syntax is
+invalid.
+
+** Discovery of jomake/omake in server config file
+*** seanmcl:
+Now it defaults to jomake, and home users must edit the config by
+hand. This is annoying. Search in the path for jomake, and otherwise
+omake.
+
+** Jane.auto-modes not working
+At least Haskell, SML and dot-mode are not working with the same
+error: "(void-function <mode-name>)" For haskell the fix is to say
+(load-library "haskell-site-file") instead of (require
+'haskell-site-file). I haven't looked into others
+[[%0A./Jane.haskell.patch][
+
+[[file:Jane.haskell.patch]]
+
+** Add an elisp command to "ignore" errors from a file
+*** sweeks:
+Sometimes I fix errors in file A by changing file B. Omake mode only
+sees B change, and doesn't remove the error until it sees A change. In
+big compiles, this ccould be a long time. I'd like a way to manually
+force omake mode to act as if it had seen a file change:
+Omake.clear-errors-for-file
+
+I currently simulate this by add whitespace to file A, waiting until
+omake-mode clears A's errors, and then deleting the whitespace.
+
+Of course, if the change to B didn't actually fix the errors,
+omake-mode should re-display them when it compiles A again (or when it
+starts polling again without having had to compile A).
+
+*** seanmcl:
+We decided to have a new class of errors, Ignored. Ignored errors show
+up below Current, Unvisited, and Visited. Ignored errors are never
+cycled-through if there exists a Visited or Unvisited error. If both
+of those categories are empty, then we cycle through Ignored
+errors. Errors can be manually moved to and from Ignored by running
+Omake.toggle-ignored-errors in a file. Errors are automatically
+promoted from Ignored to Unvisited when an ignored file is recompiled.
+
+*** sweeks:
+A possible slightly different way of handling things.
+
+Ignored errors are never cycled through.  If the user runs next-error
+and there are ignored errors but no visited or unvisited errors, then
+omake-mode selects a file from the unvisited errors (perhaps the file
+that was ignored longest ago) and toggles it, so that the errors
+become visited or unvisited, at which point next-error does its normal
+thing.  The user can manually run toggle-ignored-errors for a file by
+pressing enter on an ignored error from that file in the status
+buffer.
+
+** Info files should have an index
+*** seanmcl: Add one to both info files.
+
+** Update info docs
+*** seanmcl: Lots has changed
+** Status buffer coopts minibuffer and interferes with Omake.shutdown
+*** sweeks:
+Files: ldn-qws-010.delacy.com:/tmp/omake-server/dastapov/bug-report/1
+
+User report:
+
+Over the last week I've twice found myself in a situation where
+Omake-mode status buffer decides that it has to occupy the minibufer
+and stay there.
+
+Minibuffer still acts as minibuffer, except that now it is 10 lines
+high and refuses to be shrinked.
+
+If you create new frame, only one of them would have a \"corrupt\"
+minibuffer.
+
+I know that this has happened to nchapman as well.
+
+Omake.shutdown does not solve this - new compilations come up in
+minibuffer.
+
+Omake.shutdown-and-remove-hooks does, though - minibuffer gets back to
+normal.
+
+Sadly, I am writing this bugreport _after_ I figured out that
+shutdown-and-remove-hooks is the solution :(
+
+I don't know how to recreate this :(
+
+If this happens to me again I'll try to do a better investigation
+
+** Show error counts in projects buffer
+*** sweeks:
+Also, how about a status column? It would say one of the following:
+Building Failure Success
+*** seanmcl:
+Right now for projects that aren't watched we don't have this data. Is
+it OK to just include the data for watched projects?
+*** sweeks:
+I'll take what I can get. If we include the data only for watched projects, the UI should make clear that the data for unwatched project is unknown, not zero.
+
+I'd like to leave open something to get all the data someday.
+
+I'm thinking more and more that I would like the notion of "watching"
+out of the face of users as much as possible. The only user-visible
+effect I can think of that "watching" has is for the decision
+omake-server has to make about killing a project. For people like me
+who have kill_when_watched=false, even that has no effect. So I think
+that for such people watching is a completely artificial and
+unnecessary notion. I'd like to auto-watch all projects.
+*** seanmcl:
+That sounds right. I just wonder how do you unwatch them? There is a
+nonzero cost to watching a project, since emacs is constantly
+asynchronously updating the status buffer and logging. Hmm... I
+suppose if they kill the status buffer that should do the trick.  I
+agree the watching stuff in the projects buffer is mostly noise. It
+needs to be much more nicely formatted too.
+*** sweeks:
+How about maintaining the following two invariants:
+
+(there is a projects buffer) if and only if (omake-server sends to
+emacs the information for all projects needed to completely fill out
+the projects buffer)
+
+For all projects P, (there is a status buffer for P) iff (omake-server
+sends to emacs the information to fill out the status buffer for P)
+
+Then, one only pays performance for the information one wants.
+
+I think then that the notion of watching completely disappears for
+people who have kill_when_unwatched=false. I'm tempted to just take
+the semantic change of making that the behavior for everyone. Then we
+make a distinction between killing the status buffer and killing the
+project. People can either kill a project by running
+Omake.kill-project, C-c C-k, or using the projects buffer.
+
+I'm warming to the idea of inflicting that change on people, as
+perhaps the benefit of removing the notion of watching from the model
+outweighs the cost.
+
+** Ocamlpro indentation
+*** seanmcl:
+Try to get this to work.
+** Restarting a build should reuse the existing build's error window
+*** sweeks:
+This is better than the current behavior, which is to kill the
+existing error buffer, and then use the window selection algorithm to
+pick a new one.
+*** seanmcl:
+This appears to have been resolved some time ago. I can't
+reproduce. Please reopen if you notice the problem again.
+*** sweeks:
+This problem is still around. I just reproduced it. I use a dedicated
+error frame. I started building two projects, and had each of their
+status buffers displayed in a window in my dedicated error frame. I
+then restarted a project, and it deleted the buffer in one window, and
+then replaced the status buffer in the other window when it restarted.
+
+** Stale writer exception
+*** seanmcl: I got this some time ago [[file:stale-writer-exn.txt]]
+
+* Medium
+* Low
+** Use elisp buttons rather than text properties
+*** seanmcl:
+I just discovered button.el, which makes things prettier that I
+was doing with text-properties and lexical-let. In particular, the
+errors and project buffers have such buttons.
+
+** Remove spin lock in Omake.Server.start
+*** seanmcl:
+When I tried (sleep-for N) in the function Omake.Server.start, an
+asyncronous process sometimes interrupted it and it broke some
+invariants. The spin lock works, but is a wart. Try to come up with
+something better.
+
+** Fix Js.underscore_is_* to play nicely with C-M-{f,b}
+*** dhouse:
+Perhaps this isn't possible, but I would love the following semantics: M-{f,b} move forwards and backwards between underscores, and C-M-{f,b} move forwards and backwards between "actual" word boundaries, where by "actual" I mean what you would get if you said that ?_ was not a word boundary for the duration of the call.
+E.g.:
+#+BEGIN_EXAMPLE
+                F o o . f o o _ b a r _ b a z  ( )
+With M-{f,b }  |   ->  | ->  |  ->   |  ->   | -> |
+With C-M-{f,b} |   ->  |        ->           | -> |
+#+END_EXAMPLE
+*** sweeks:
+My understanding is that this is now working, and all that is left to
+do here is rename Js.* as Jane.*.
+*** seanmcl:
+No, house wants something slightly more complex. He wants to have
+`forward-sexp' treat _ like a word char and `forward-word' treat _
+like punctuation.
+
+** Make ocamlspot work with tramp
+*** anon:
+Right now, ocamlspot.el is not usable on remote repositories with
+tramp, which is very annoying.  Simply applying
+s/call-process/process-file/ on the definition of ocamlspot-run-query
+made it work for me.
+*** valantin:
+Actually, it is not quite enough yet. With the previous proposal,
+displaying type at point works, but not going to the definition of the
+element at point (it tries to open the file on the local machine
+instead of the remote one).  If ocamlspot returned relative paths in
+its output, I think it would have worked. In any case, I added the
+following thing in my .emacs to make it work (I am sure it can be done
+in a better way, I never program in elisp):
+
+#+BEGIN_EXAMPLE
+;; returns the part of the path that contains the machine name (or "" for a local path)
+(defun tramp-prefix-of-path (path)
+  (let* ((prev-dir (directory-file-name path))
+        (dir (directory-file-name (file-name-directory prev-dir))))
+    (while (and dir (not (equal dir prev-dir)))
+      (setq prev-dir dir)
+      (setq dir (directory-file-name (file-name-directory prev-dir))))
+    (substring (if dir dir prev-dir) 0 -1)))
+
+;; the value of filename is the only thing that changed compared to ocamlspot.el
+(defun ocamlspot-jump-to-path-range (path-range)
+  (if (string-match "^<?\\(.*\\):\\(l[\-0-9]+c[\-0-9]+b[\-0-9]+:l[\-0-9]+c[\-0-9]+b[\-0-9]+\\|[0-9]+:[0-9]+\\|all\\|-1:-1\\)>?$" path-range)
+      (let ((filename (concat (tramp-prefix-of-path default-directory) (match-string 1 path-range)))
+            (position (match-string 2 path-range)))
+        ;; display the result
+        (ocamlspot-jump-to-spot filename position)
+        (let ((type (ocamlspot-find-val-or-type)))
+          ;; (if type (ocamlspot-message-add (format "Type: %s" type)))
+          ))
+    ;; failed to get the normal result
+    ;; CR jfuruse: this is an error message. Should be decolated?
+    (ocamlspot-message-add path-range)))
+#+END_EXAMPLE
+
+** Make M-q inside a comment leave following code alone
+*** dhouse:
+I have a feeling this has an easy answer but I can't think of it.
+Suppose I have some code which is not indented ideally according to
+M-x indent-region, and I want it to stay that way, for whatever
+reason. (Maybe it is someone else's code, maybe it is some edge case,
+etc.)
+
+If I insert a comment before this code and attempt to use M-q
+(fill-paragraph) inside the comment, then the code that follows will
+be re-indented.
+
+E.g.:
+
+#+BEGIN_EXAMPLE
+let () =
+  (* foo *)
+  Foo.foo_bar_baz
+      poorly_indented arguments
+#+END_EXAMPLE
+
+M-q inside the comment:
+
+#+BEGIN_EXAMPLE
+let () =
+  (* foo *)
+  Foo.foo_bar_baz
+    poorly_indented arguments
+A workaround is to use narrow-to-region first, including a line of code above the comment so that it gets the indentation of the comment right, or alternatively to insert another, dummy paragraph inside the comment, e.g.:
+
+let () =
+  (* foo
+
+     bar
+  *)
+  Foo.foo_bar_baz
+      poorly_indented arguments
+Then the "foo" bit can be filled without affecting the following code (presumably because it is now in a new paragraph).
+#+END_EXAMPLE
+
+** Use markers instead of file/line/char triples
+*** seanmcl:
+markers have the nice property that they are updated as the file is
+edited, so Omake.next-error can find an error even if code above the
+error changed.
+
+** omake-mode support for refactoring
+*** sweeks:
+Nathan mentioned to me the excellent idea that we could scrape OMake output to automatically assist with refactoring. For example, suppose one renames module "Foo" to "Bar". Well, then whenever OMake spits out an error "Unbound module Foo", we likely want to replace "Foo" with "Bar" at the point of that error.
+I was thinking that since omake-mode already parses OMake output and understands the structure of OCaml error messages, we could add some emacs functionality to assist with refactoring.
+
+I imagine a function Omake.rename-module that would prompt for the old
+and new module names, and would instruct omake-mode to, when it
+encounters an unbound-module error, rather than display the error in
+the [Errors] buffer, automatically replace the old name with the new
+name in the code. Similarly for Omake.rename-variable.
+
+** pdiff type errors
+*** sweeks:
+For type error messages that we can parse well enough to detect [t1 !=
+t2], it would be cool to display in emacs the pdiff of [t1] and [t2],
+as a way of making it easier for the user to find the source of the
+type error.
+
+** Lift the 50 error limit
+*** seanmcl:
+Improve performance/streaming so that the 50 error limit is no longer
+necessary.
+
+** Show command that caused an error
+*** seanmcl:
+It would be cool to have a keybinding that would let me toggle display
+of the build command that led to the current error message. Maybe the
+keybinding should just be the existing C-c C-h, but that would add a
+new field to the displayed error, "Build command: ..."
+
+** Can't kill project if directory has gone away
+
+*** sweeks:
+I just moved a directory for a project that was building. Now I can
+not kill the project, because omake-mode complains that it cannot set
+the current directory to the now-gone directory.
+
+** Flymake highlighting of errors
+*** seanmcl:
+It would be cool if the tuareg buffer would highlight errors from
+omake. Maybe in the style of fly-make, or maybe with something like
+this:
+
+#+BEGIN_EXAMPLE
+;; Some code that will make it so the background color of the lines that gcc ;; found errors on, should be in another color.
+
+(defvar all-overlays ())
+
+(defun delete-this-overlay (overlay is-after begin end &optional len) (delete-overlay overlay))
+
+(defun highlight-current-line () (interactive) (setq current-point (point)) (beginning-of-line) (setq beg (point)) (forward-line 1) (setq end (point)) ;; Create and place the overlay (setq error-line-overlay (make-overlay 1 1))
+
+;; Append to list of all overlays (setq all-overlays (cons error-line-overlay all-overlays))
+
+(overlay-put error-line-overlay 'face '(background-color . "pink")) (overlay-put error-line-overlay 'modification-hooks (list 'delete-this-overlay)) (move-overlay error-line-overlay beg end) (goto-char current-point))
+
+(defun delete-all-overlays () (while all-overlays (delete-overlay (car all-overlays)) (setq all-overlays (cdr all-overlays))))
+
+(defun highlight-error-lines (compilation-buffer, process-result) (interactive) (delete-all-overlays) (condition-case nil (while t (next-error) (highlight-current-line)) (error nil)))
+
+(setq compilation-finish-function 'highlight-error-lines)
+#+END_EXAMPLE
+** Visual flickering in [Errors] buffer
+*** sweeks:
+With a large error message expanded as the current error, the error
+noticeably flickers between blue and orange, remaining primarily
+blue. The frequency of the flicker is not regular and the interval is
+often less than a second. Also, if I Alt-tab, the error freezes in the
+orange color.
+*** seanmcl:
+Does it happen only when the mouse is over the text, or even when it's not?
+*** sweeks:
+I missed an important fact in my report -- the flickering was
+occurring on the error that I had the mouse over. So, it being
+(darkish) blue made sense -- the problem was the flicker.  I also
+noticed that the size of the error does not matter. I can hover over a
+small error, whether current or not, and see the flicker.
+
+So, in summary, any error that is hovered over has a flicker, and is
+mostly right color, but ocassionally flickers to the wrong color (the
+non-hover color), except with Alt-Tab, in which case the hover color
+is lost. Perhaps the alt-tab behavior is unavoidable, since perhaps
+the window system tells emacs that the mouse is no longer
+hovering. But I hope the flicker is avoidable.
+
+Clearly very small, since I can just move my mouse to cut off the
+flicker.
+** Only ask to save files under omakeroot
+*** seanmcl:
+Now when compiling it asks about all files
+
+* Hold
+* Closed

File todo/stale-writer-exn.txt

+[2012-10-04 12:17:53.862014] Caught exception: ("writer buffer has data older than"
+  (2m
+    ((id 2)
+      (fd
+        ((file_descr 11)
+          (info
+            (socket
+              ((listening_on
+                 ((type_
+                    ((family
+                       ((family PF_UNIX) (address_of_sockaddr_exn <fun>)
+                         (sexp_of_address <fun>)))
+                      (socket_type SOCK_STREAM)))
+                   (fd
+                     ((file_descr 7)
+                       (info
+                         (replaced
+                           (listening
+                             (previously_was
+                               (replaced
+                                 ((socket
+                                    (bound_on
+                                      (Unix /tmp/omake-server/seanmcl/socket)))
+                                   (previously_was
+                                     (socket
+                                       ((family
+                                          ((family PF_UNIX)
+                                            (address_of_sockaddr_exn <fun>)
+                                            (sexp_of_address <fun>)))
+                                         (socket_type SOCK_STREAM))))))))))
+                       (kind (Socket Passive)) (supports_nonblock true)
+                       (have_set_nonblock true)
+                       (state (Close_requested <fun>))
+                       (watching
+                         ((read Stop_requested) (write Not_watching)))
+                       (watching_has_changed true) (num_active_syscalls 1)
+                       (close_finished Empty)))))
+                (client (Unix "")))))
+          (kind (Socket Active)) (supports_nonblock true)
+          (have_set_nonblock true) (state Closed)
+          (watching ((read Not_watching) (write Not_watching)))
+          (watching_has_changed false) (num_active_syscalls 0)
+          (close_finished (Full ()))))
+      (monitor
+        (((name
+            (writer
+              (2
+                ((file_descr 11)
+                  (info
+                    (socket
+                      ((listening_on
+                         ((type_
+                            ((family
+                               ((family PF_UNIX)
+                                 (address_of_sockaddr_exn <fun>)
+                                 (sexp_of_address <fun>)))
+                              (socket_type SOCK_STREAM)))
+                           (fd
+                             ((file_descr 7)
+                               (info
+                                 (replaced
+                                   (listening
+                                     (previously_was
+                                       (replaced
+                                         ((socket
+                                            (bound_on
+                                              (Unix
+                                                /tmp/omake-server/seanmcl/socket)))
+                                           (previously_was
+                                             (socket
+                                               ((family
+                                                  ((family PF_UNIX)
+                                                    (address_of_sockaddr_exn
+                                                      <fun>)
+                                                    (sexp_of_address <fun>)))
+                                                 (socket_type SOCK_STREAM))))))))))
+                               (kind (Socket Passive))
+                               (supports_nonblock true)
+                               (have_set_nonblock true)
+                               (state (Close_requested <fun>))
+                               (watching
+                                 ((read Stop_requested) (write Not_watching)))
+                               (watching_has_changed true)
+                               (num_active_syscalls 1)
+                               (close_finished Empty)))))
+                        (client (Unix "")))))
+                  (kind (Socket Active)) (supports_nonblock true)
+                  (have_set_nonblock true) (state Closed)
+                  (watching ((read Not_watching) (write Not_watching)))
+                  (watching_has_changed false) (num_active_syscalls 0)
+                  (close_finished (Full ()))))))
+           (here ()) (id 13) (has_seen_error true)
+           (someone_is_listening true))
+          ((name try_with) (here ()) (id 3) (has_seen_error true)
+            (someone_is_listening true))
+          ((name main) (here ()) (id 1) (has_seen_error false)
+            (someone_is_listening false))))
+      (background_writer_state Running) (syscall Per_cycle)
+      (bytes_received 125012) (bytes_written 115370) (scheduled <opaque>)
+      (scheduled_bytes 78) (buf <opaque>) (scheduled_back 78) (back 9642)
+      (flushes <opaque>) (close_state Closed) (close_finished (Full ()))
+      (producers_to_flush_at_close ()) (flush_at_shutdown_elt (<opaque>))
+      (check_buffer_age
+        (((writer <opaque>)
+           (queue
+             ((115448 (2012-10-04 12:15:53.563347))
+               (115448 (2012-10-04 12:15:54.737617))
+               (115530 (2012-10-04 12:15:55.748610))
+               (115608 (2012-10-04 12:15:56.749863))
+               (115608 (2012-10-04 12:15:57.750891))
+               (115786 (2012-10-04 12:15:58.994137))
+               (115946 (2012-10-04 12:15:59.995361))
+               (116124 (2012-10-04 12:16:00.998639))
+               (116124 (2012-10-04 12:16:02.000941))
+               (116284 (2012-10-04 12:16:03.003073))
+               (116284 (2012-10-04 12:16:04.005636))
+               (116284 (2012-10-04 12:16:05.008578))
+               (116362 (2012-10-04 12:16:06.104666))
+               (116362 (2012-10-04 12:16:08.196400))
+               (116362 (2012-10-04 12:16:11.818595))
+               (116440 (2012-10-04 12:16:13.350277))
+               (116618 (2012-10-04 12:16:14.351110))
+               (116696 (2012-10-04 12:16:15.353081))
+               (116696 (2012-10-04 12:16:16.354335))
+               (116696 (2012-10-04 12:16:17.356096))
+               (116856 (2012-10-04 12:16:18.360273))
+               (116856 (2012-10-04 12:16:19.361688))
+               (116938 (2012-10-04 12:16:20.366526))
+               (117194 (2012-10-04 12:16:21.367626))
+               (117372 (2012-10-04 12:16:22.370804))
+               (117550 (2012-10-04 12:16:23.429643))
+               (117888 (2012-10-04 12:16:24.619434))
+               (118066 (2012-10-04 12:16:25.857979))
+               (118326 (2012-10-04 12:16:27.127206))
+               (118404 (2012-10-04 12:16:28.130890))
+               (118404 (2012-10-04 12:16:29.139606))
+               (118482 (2012-10-04 12:16:30.146893))
+               (118564 (2012-10-04 12:16:31.147824))
+               (118564 (2012-10-04 12:16:32.152173))
+               (118742 (2012-10-04 12:16:33.414890))
+               (119080 (2012-10-04 12:16:34.547260))
+               (119080 (2012-10-04 12:16:35.600659))
+               (119418 (2012-10-04 12:16:36.604368))
+               (119596 (2012-10-04 12:16:37.608680))
+               (119596 (2012-10-04 12:16:38.621683))
+               (119674 (2012-10-04 12:16:39.623251))
+               (119852 (2012-10-04 12:16:40.625706))
+               (119934 (2012-10-04 12:16:41.629083))
+               (120012 (2012-10-04 12:16:42.633820))
+               (120272 (2012-10-04 12:16:43.636096))
+               (120272 (2012-10-04 12:16:44.639992))
+               (120350 (2012-10-04 12:16:45.641182))
+               (120350 (2012-10-04 12:16:46.695615))
+               (120610 (2012-10-04 12:16:47.697113))
+               (120866 (2012-10-04 12:16:48.701113))
+               (120948 (2012-10-04 12:16:49.703089))
+               (120948 (2012-10-04 12:16:50.704603))
+               (121026 (2012-10-04 12:16:51.708413))
+               (121108 (2012-10-04 12:16:52.715559))
+               (121108 (2012-10-04 12:16:53.717387))
+               (121186 (2012-10-04 12:16:54.719915))
+               (121268 (2012-10-04 12:16:55.729846))
+               (121268 (2012-10-04 12:16:56.732962))
+               (121346 (2012-10-04 12:16:57.736190))
+               (121428 (2012-10-04 12:16:58.741322))
+               (121606 (2012-10-04 12:16:59.742754))
+               (121684 (2012-10-04 12:17:00.744085))
+               (121684 (2012-10-04 12:17:01.746291))
+               (121766 (2012-10-04 12:17:02.747616))
+               (121844 (2012-10-04 12:17:03.752869))
+               (121844 (2012-10-04 12:17:04.754920))
+               (121844 (2012-10-04 12:17:05.756069))
+               (121922 (2012-10-04 12:17:06.790280))
+               (121922 (2012-10-04 12:17:07.803926))
+               (121922 (2012-10-04 12:17:08.807413))
+               (121922 (2012-10-04 12:17:09.916023))
+               (122178 (2012-10-04 12:17:10.921649))
+               (122260 (2012-10-04 12:17:11.930533))
+               (122260 (2012-10-04 12:17:12.933697))
+               (122338 (2012-10-04 12:17:13.939950))
+               (122338 (2012-10-04 12:17:15.010704))
+               (122338 (2012-10-04 12:17:16.012889))
+               (122416 (2012-10-04 12:17:17.014977))
+               (122416 (2012-10-04 12:17:18.019154))
+               (122416 (2012-10-04 12:17:19.019897))
+               (122494 (2012-10-04 12:17:20.020808))
+               (122494 (2012-10-04 12:17:21.023501))
+               (122494 (2012-10-04 12:17:22.026909))
+               (122572 (2012-10-04 12:17:23.145379))
+               (122654 (2012-10-04 12:17:24.146265))
+               (122654 (2012-10-04 12:17:25.146645))
+               (122732 (2012-10-04 12:17:26.148141))
+               (122732 (2012-10-04 12:17:27.149603))
+               (122732 (2012-10-04 12:17:28.151140))
+               (122810 (2012-10-04 12:17:29.152841))
+               (122810 (2012-10-04 12:17:30.155118))
+               (122810 (2012-10-04 12:17:31.157370))
+               (122888 (2012-10-04 12:17:32.161359))
+               (122888 (2012-10-04 12:17:33.163102))
+               (122888 (2012-10-04 12:17:37.886686))
+               (122966 (2012-10-04 12:17:39.488674))
+               (123226 (2012-10-04 12:17:40.489633))
+               (123304 (2012-10-04 12:17:41.490538))
+               (123304 (2012-10-04 12:17:42.490834))
+               (123386 (2012-10-04 12:17:43.491605))
+               (123464 (2012-10-04 12:17:44.493086))
+               (123642 (2012-10-04 12:17:45.493950))
+               (123902 (2012-10-04 12:17:46.495500))
+               (124158 (2012-10-04 12:17:47.535982))
+               (124336 (2012-10-04 12:17:48.788807))
+               (124418 (2012-10-04 12:17:49.790822))
+               (124496 (2012-10-04 12:17:50.830242))
+               (124674 (2012-10-04 12:17:51.836048))
+               (124756 (2012-10-04 12:17:52.839038))
+               (125012 (2012-10-04 12:17:53.842799))))
+           (maximum_age 2m) (too_old (Full ())))))
+      (consumer_left Empty) (raise_when_consumer_leaves false))))
+[2012-10-04 12:17:56.471228] Caught exception: (Unix.Unix_error "Connection refused" connect
+  "((fd 6) (addr (ADDR_UNIX /tmp/omake-server/seanmcl/socket)))")