I have emacs + sbcl + slime installed. I have this function defined
(defun jugar ()
(let* ((nodoActual *nodo-inicial*)
(estadoActual (nodo-estado nodoActual))
(timeStart nil)
(timeEnd nil)
)
(loop while (not (es-estado-final estadoActual)) do
(setf *hojas* 0)
(setf timeStart (get-universal-time))
(setf nodoActual (decision-minimax nodoActual *profundidad* timeStart))
(setf timeEnd (get-universal-time))
(setf estadoActual (nodo-estado nodoActual))
(imprime-en-fichero estadoActual)
(format t "Hojas analizadas: ~a ~%" *hojas*)
(format t "Tiempo empleado: ~a ~%~%" time))
))
that makes a series of calls and print some variables in a loop.
The problem is when I call (jugar) from the *slime-repl sbcl* buffer, the prompt waits until (jugar) execution ends for showing all the (format …) together. I tried the same from a terminal (running sbcl) and it works well, so I guess it is something related to emacs or slime. How can I fix it?
proksid's answer mentions force-output, which is on the right track, but there are actually a few related possibilities. The documentation for force-output also describes finish-output (and clear-output, which isn't relevant for us):
finish-output, force-output, and clear-output exercise control over
the internal handling of buffered stream output.
finish-output attempts to ensure that any buffered output sent to
output-stream has reached its destination, and then returns.
force-output initiates the emptying of any internal buffers but does
not wait for completion or acknowledgment to return.
clear-output attempts to abort any outstanding output operation in
progress in order to allow as little output as possible to continue to
the destination.
If you want to guarantee that the output from the different iterations doesn't get interleaved (I don't know whether this is likely or not), you might want to consider finish-output instead of force-output. In either case, at least be aware of both options.
Add (force-output) after last (format ) call.
Related
When serving large files from Clack/Hunchentoot with Slime connected, I sometimes see error messages like SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s"... Those are caused by the browser prematurely dropping connections (which is totally OK). The problem is that each time it happens, SLDB pops up. Which is annoying.
Is there a way I can inhibit certain errors in SLDB such as the above? I still would like to see them in an error log, but definitely not in SLDB.
You can subclass PROCESS-CONNECTION for your acceptor and do your own error handling for this error.
Let's start by defining a custom acceptor:
(defclass no-error-acceptor (hunchentoot:acceptor)
())
Then we can create a wrapper around PROCESS-CONNECTION that inhibits printing of a message for this specific error:
(defmethod hunchentoot:process-connection ((acceptor no-error-acceptor) (socket t))
(handler-case
(call-next-method)
(sb-impl::simple-stream-perror (condition)
;; Perhaps log the error here?
nil)))
Make sure you actually start the server using this acceptor in order for it to be used.
UPDATED
Since your system uses Hunchentoot, you could set the global variable HUNCHENTOOT:*CATCH-ERRORS-P* to T. This should guarantee that the all the conditions arising in code managed by Hunchentoot are catched by Hanchentoot itself and not passed to the debugger.
To disable the debugger in any Common Lisp implementation (both inside a shell REPL as well as the Slime REPL inside Emacs) you could use the predefined global variable *debugger-hook*, by assigning to it a two argument function. The function will receive the condition and the current value of *debugger-hook* when it is called, and can handle the condition or return normally, and in this case the debugger is invoked. For instance, you could simply print the condition:
* (defun my-debug(condition hook)
(declare (ignore hook))
(print condition)
(abort))
DEBUG-IGNORE
* (setf *debugger-hook* #'my-debug)
#<FUNCTION MY-DEBUG>
This second method however cannot work when using Hunchentoot together with Slime, due to the way the two packages interact with respect to the debugging strategies.
In this case one could adopt the solution found by Mike Ivanov, that redefines the swank-debugger-hook function before starting Swank:
(in-package swank)
(setq swank-debugger-hook-orig #'swank-debugger-hook)
(defun swank-debugger-hook (condition hook)
(etypecase condition
(sb-int:simple-stream-error
(progn
(princ "*** Stream error" *error-output*)
(abort)))
(t (funcall swank-debugger-hook-orig condition hook))))
(in-package cl-user)
(swank:create-server :port 4008 :dont-close t)
In my .emacs file, I have:
(defadvice narrow-to-region (around test activate)
(message "advice")
ad-do-it)
When I call narrow-to-region, the advice runs and prints 'advice' before narrowing.
When I call narrow-to-defun, it does not.
I found where narrow-to-defun is defined - in lisp.el, and re-evaluated the function. At this point, the advice started running.
What could cause this?
The problem is, apparently, due to byte-compilation and therefore the inability to advise the narrowing primitives (narrow-to-region is the primitive, narrow-to-defun calls narrow-to-region).
The following post on Null Program ("The Limits of Emacs Advice") goes into detail about this problem. Here's the shortish version from deep in the post:
It turns out narrow-to-region is so special -- probably because it's used very frequently -- that it gets its own bytecode. The primitive function call is being compiled away into a single instruction. This means my advice will not be considered in byte-compiled code. Darnit. The same is true for widen (code 126).
As to why the advice started working after you re-evaluated narrow-to-defun: I'm guessing it's because you ended up replacing the byte-compiled version when you re-evaluated.
#Dan described the problem well. Here is some info that might help you work around it.
What you can do is to advise (or to redefine) also narrow-to-defun (and perhaps narrow-to-page), so it acts similarly.
FWIW, I do something similar in library wide-n.el (see Multiple Narrowings).
I advise narrow-to-region. But I also redefine narrow-to-defun and narrow-to-page. In all 3 cases I make the same change, to record the details of each narrowing so you can return to them later. Here is the advice, for example:
(defadvice narrow-to-region (before push-wide-n-restrictions activate)
"Push the region limits to `wide-n-restrictions'.
You can use `C-x n x...' to widen to previous buffer restrictions."
(when (or (interactive-p) wide-n-push-anyway-p)
(wide-n-push (ad-get-arg 0) (ad-get-arg 1)))) ; Args START and END.
And here is the relevant part of the narrow-to-defun redefinition:
...
(goto-char end)
(re-search-backward "^\n" (- (point) 1) t)
(when (or (interactive-p) wide-n-push-anyway-p) (wide-n-push beg end)) ; <=====
(narrow-to-region beg end))))
read-line and read-char both require you press Enter key after typing something. Is there any mechanism in Common Lisp that would allow the program to continue upon the press of any single character immediately, without requiring the additional step of pressing Enter?
I'm trying to build a quick, dynamic text input interface for a program so users can quickly navigate around and do different things by pressing numbers or letters corresponding to onscreen menus. All the extra presses of the Enter key seriously interrupt the workflow. This would also be similar to a "y/n" type of interrogation from a prompt, where just pressing "y" or "n" is sufficient.
I am using SBCL, if that makes a difference. Perhaps this is implementation specific, as I tried both examples on this page and it does not work (I still need to press Enter); here's the first one:
(defun y-or-n ()
(clear-input *standard-input*)
(loop as dum = (format t "Y or N for yes or no: ")
as c = (read-char)
as q = (and (not (equal c #\n)) (not (equal c #\y)))
when q do (format t "~%Need Y or N~%")
unless q return (if (equal c #\y) 'yes 'no)))
read-char doesn't require you to press enter. E.g.,
CL-USER> (with-input-from-string (x "hello")
(print (read-char x)))
#\h
Similarly, if you send some input into SBCL from the command line, it will be read without a newline:
$ echo -n hello | sbcl --eval "(print (read-char))"
…
#\h
After reading and printing #\h, SBCL saw the ello:
*
debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD
"initial thread" RUNNING
{1002979011}>:
The variable ELLO is unbound.
I think this is enough to confirm that it's not that read-char needs a newline, but rather that the buffering of the input is the problem. I think this is the same problem (or non-problem) that's described in a comp.lang.lisp thread from 2008: Re: A problem with read-char. The user asks:
Is it possible to make read-char behave like getch in С when working
with interactive stream (standard-input)? In SBCL read-char wants
"enter" key to unhang from REPL, in C getchar returns immediately
after user press key on keyboard. Probably is possible to run code
that uses read-char with direct console access, aside REPL?
There were four responses (see the thread index to get to all of them). These explain why this behavior is observed (viz., that the Lisp process isn't getting raw input from the terminal, but rather buffered input). Pascal Bourguignon described the problem, and a way to handle this with CLISP (but doesn't provide all that much help, aside from the usual good advice) about working around this in SBCL:
The difference is that curses puts the terminal in raw mode to be able
to receive the characters from the keyboard one at a time, instead of
leaving the terminal in cooked mode, where the unix driver bufferize
lines and handles backspace, amongst other niceties.
…
Now, I don't know about SBCL, (check the manual of SBCL). I only have
the Implementation Notes of CLISP loaded in my wetware. In CLISP you
can use the EXT:WITH-KEYBOARD macro (while the basic output features
of curses are provided by the SCREEN package).
Rob Warnock's response included some workaround code for CMUCL that might or might not work for SBCL:
I once wrote the following for CMUCL for an application that wanted
to be able to type a single character response to a prompt without
messing up the terminal screen:
(defun read-char-no-echo-cbreak (&optional (stream *query-io*))
(with-alien ((old (struct termios))
(new (struct termios)))
(let ((e0 (unix-tcgetattr 0 old))
(e1 (unix-tcgetattr 0 new))
(bits (logior tty-icanon tty-echo tty-echoe
tty-echok tty-echonl)))
(declare (ignorable e0 e1)) ;[probably should test for error here]
(unwind-protect
(progn
(setf (slot new 'c-lflag) (logandc2 (slot old 'c-lflag) bits))
(setf (deref (slot new 'c-cc) vmin) 1)
(setf (deref (slot new 'c-cc) vtime) 0)
(unix-tcsetattr 0 tcsadrain new)
(read-char stream))
(unix-tcsetattr 0 tcsadrain old)))))
SBCL has probably diverged considerably from CMUCL in this area, but
something similar should be doable with SBCL. Start by looking in the
SB-UNIX or maybe the SB-POSIX packages...
User vippstar's response provided a link to what might be the most portable solution
Since you want to do something that might not be portable to a
microcontroller (but the benifit is the much more enhanced UI), use a
non-standard library, such as CL-ncurses.
Adding another answer to point out the existence of this tutorial: cl-charms crash course, by Daniel "jackdaniel" Kochmański. Disabling buffering is related to how the terminal is configured, and cl-charms is a library that exploit the ncurses C library to configure the terminal for interactive usage.
I found cl-charms, which seems to be a fork of the abandoned cl-curses. However, the included example program charms-paint uses 100 % CPU to run the trivial paint application. The problem seems to be that the main loop busy-waits for input.
You could use the trivial-raw-io library to read a single character without pressing Enter. Usage: (trivial-raw-io:read-char). It works on SBCL, CCL, CMUCL, and CLISP on Linux, and should work on other Unix-like operating systems as well. The library has only one simple dependency (the alexandria library), and it is licensed under the BSD 2-clause license.
I've struggled recently with the same issue and I ended up solving it simply by using FFI to interact with termios and disable canonical mode. Essentially that what's mentioned in #JoshuaTaylor's response. I couldn't get that code to work with SBCL, for whatever reason, so I made a few changes. Here is the complete working code (only tested with SBCL):
(define-alien-type nil
(struct termios
(c_iflag unsigned-long)
(c_oflag unsigned-long)
(c_cflag unsigned-long)
(c_lflag unsigned-long)
(c_cc (array unsigned-char 20))
(c_ispeed unsigned-long)
(c_ospeed unsigned-long)))
(declaim (inline tcgetattr))
(define-alien-routine "tcgetattr" int
(fd int)
(term (* (struct termios))))
(declaim (inline tcsetattr))
(define-alien-routine "tcsetattr" int
(fd int)
(action int)
(term (* (struct termios))))
(defun read-single-byte (&optional (s *standard-input*))
(with-alien ((old (struct termios))
(new (struct termios)))
(let ((e0 (tcgetattr 0 (addr old)))
(e1 (tcgetattr 0 (addr new)))
(n-lflag (slot new 'c_lflag)))
(declare (ignorable e0 e1))
(unwind-protect
(progn
(setf (ldb (byte 1 8) n-lflag) 0) ; disables canonical mode
(setf (ldb (byte 1 3) n-lflag) 0) ; disables echoing input char
(setf (slot new 'c_lflag) n-lflag)
(tcsetattr 0 0 (addr new))
(read-byte s))
(tcsetattr 0 0 (addr old))))))
Simply interfacing with termios should do the trick, there is no need for external libraries. You can find on termios's man page more information (https://man7.org/linux/man-pages/man3/termios.3.html), but essentially it's when the terminal is in canonical mode (ICANON) that it needs to wait for a line delimiter before the contents of the buffer become available. I hope this helps!
I'm writing a derived mode, based on comint-mode. The mode is an interface to a command line program (GRASS gis), and the comint mode completion works for the programs. I'm trying to add on support for completing the arguments to the program, via completion-at-point-functions. A toy example is:
(setq my-commands
'(("ls"
("my-completion-1")
("my-completion-2"))
("mv"
("my-completion-3")
("my-completion-4"))))
(defun my-completion-at-point ()
(interactive)
(let ((pt (point)) ;; collect point
start end)
(save-excursion ;; collect the program name
(comint-bol)
(re-search-forward "\\(\\S +\\)\\s ?"))
(if (and (>= pt (match-beginning 1))
(<= pt (match-end 1)))
() ;; if we're still entering the command, pass completion on to
;; comint-completion-at-point by returning nil
(let ((command (match-string-no-properties 1)))
(when (member* command my-commands :test 'string= :key 'car)
;; If the command is one of my-commands, use the associated completions
(goto-char pt)
(re-search-backward "\\S *")
(setq start (point))
(re-search-forward "\\S *")
(setq end (point))
(list start end (cdr (assoc command my-commands)) :exclusive 'no))))))
(push 'my-completion-at-point completion-at-point-functions)
This almost works. I get normal completion of program names. However, if I have entered ls at the command line, hitting tab inserts my-completion- and doesn't offer the two options. Hitting tab again inserts my-completion- a second time, so that I now have ls my-completion-mycompletion-.
My actual code includes a few lines to check for multi-line commands, but makes no changes to the completion code. With this version of the code, I hitting tab on a line that starts with one of the program names in my-commands I am presented with a list of the possible arguments to complete the command with, but nothing is inserted in the buffer, and the list does not get narrowed by typing the first few letters of an argument.
I've been over the manual, but I can't figure out the correct way to write a completion-at-point function. Any ideas what I'm missing?
I have looked briefly at pcomplete, but the didn't really understand the 'documentation', and didn't make any progress.
The problem seems to be with the way you're finding start and end to return the boundaries of the argument at point. I didn't spend long enough debugging it to be sure of the details, but I think if you call the function interactively you'll see that it returns the same value for start and end, and this means that the completion UI doesn't know to use the argument at point to select from the completion table you've passed it.
Changing the last part of your function to the following seems to be one fix:
(when (member* command my-commands :test 'string= :key 'car)
;; If the command is one of my-commands, use the associated completions
(goto-char pt)
(let ((start
(save-excursion
(skip-syntax-backward "^ ")
(point))))
(list start pt (cdr (assoc command my-commands)) :exclusive 'no)))))))
This gives the expected results when added as an element of completion-at-point-functions.
Here I've used skip-syntax-backward instead of regexp search, which I think is slightly more idiomatic Elisp for this kind of thing. It just says to move point backwards across anything that is not in syntax class "whitespace". The skip-syntax functions return the distance moved rather than the value of point, so we have to add a call to point at the end of the save-excursion.
If you do use regexp searches in a function like this, it's usually a good idea to pass t for the fourth argument, noerror, so that it doesn't pass on errors to the user if it fails to match. This does mean that you have to check for yourself whether the return value is nil, though.
Finally, instead of push to add the completion function you might want to use add-hook as follows:
(add-hook 'completion-at-point-functions 'my-completion-at-point nil t)
This does two useful things: it checks whether your function is already in the hook before adding it, and (by passing t for the fourth argument, local) it only adds the function to the buffer-local value of the completion-at-point hook. This is almost certainly what you want, since you don't want to use these completions in every other Emacs buffer when you press the TAB key.
Is there any way to write something like this without taking over emacs?
(defun dumb-wait (seconds)
(let ((done (+ (second (current-time)) seconds)))
(while (< (second (current-time)) done)
(message "waiting"))))
(dump-wait 5) will block emacs from 5 seconds. Is there anyway to write this so it doesn't block? I just want to be in a loop and check some condition from time to time, and still be able to use emacs.
Thanks!
(run-at-time time repeat function &rest args) should do it. nil as time means now.
(setq my-timer
(run-at-time nil 5 (lambda () (message "waiting")))) ; returns timer object
;; or
(setq my-timer
(run-at-time nil 5 'message "waiting"))
(cancel-timer my-timer) ; use timer object from above
Edit:
The parameter repeat expects a number as seconds, however there's a function timer-duration, which you can use instead of the number. It returns the number of seconds as provided with a string parameter. This is somewhat easier to read for big intervals.
(timer-duration "3 hours 2 seconds 1 millisec") ; => 10802.001
Possible word you can use are defined in the variable timer-duration-words.
On a related note, there's no general way to write Emacs Lisp code that doesn't block because the language doesn't have features like coroutines, continuations and threading (yet). Instead, you've got to look for asynchronous inbuilts that do something closest to what you want. Example: url-retrieve and async-shell-command. Some applications like SLIME have managed to work around this issue and have implemented a sort of threading on their own, while others like gnus are waiting for Emacs Lisp to improve.