* scheme directory @ 2000-05-03 4:52 Satoru Takabayashi 2000-05-03 12:15 ` Kalle Olavi Niemitalo 2000-05-03 15:03 ` interrupting the Scheme process Keisuke Nishida 0 siblings, 2 replies; 8+ messages in thread From: Satoru Takabayashi @ 2000-05-03 4:52 UTC (permalink / raw) To: guile-emacs Hi, I found the description of INSTALL file in the cvs repository was inappropriate. Original: # mkdir /usr/local/share/emacs/scheme # cp -r emacs /usr/local/share/emacs/scheme My suggestion: # mkdir /usr/local/share/emacs/20.6/scheme # cp -r emacs /usr/local/share/emacs/20.6/scheme or # mkdir /usr/local/share/emacs/site-scheme # cp -r emacs /usr/local/share/emacs/site-scheme Anyway, why should we install *.scm files into "/usr/local/share/emacs/20.6/scheme/emacs" instead of "/usr/local/share/emacs/20.6/scheme"? I think `emacs' at the end of the path is redundant. Moreover, it might be fine to install *.scm files automatically by `make install' of Guile Emacs. p.s. I am new to Scheme. I have been studying Scheme with Guile Emacs. scheme-interaction-mode is great. I hope interrupting the Scheme process with C-g will be possible. Thanks, -- Satoru Takabayashi ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: scheme directory 2000-05-03 4:52 scheme directory Satoru Takabayashi @ 2000-05-03 12:15 ` Kalle Olavi Niemitalo 2000-05-05 11:56 ` Ken Raeburn 2000-05-03 15:03 ` interrupting the Scheme process Keisuke Nishida 1 sibling, 1 reply; 8+ messages in thread From: Kalle Olavi Niemitalo @ 2000-05-03 12:15 UTC (permalink / raw) To: guile-emacs Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > # mkdir /usr/local/share/emacs/20.6/scheme > # cp -r emacs /usr/local/share/emacs/20.6/scheme This would be best, I think. > # mkdir /usr/local/share/emacs/site-scheme > # cp -r emacs /usr/local/share/emacs/site-scheme Actually, this is how it was before I changed "site-scheme" to "scheme". ;-) > Anyway, why should we install *.scm files into > "/usr/local/share/emacs/20.6/scheme/emacs" instead of > "/usr/local/share/emacs/20.6/scheme"? I think `emacs' at > the end of the path is redundant. The files contain Guile modules. For example, emacs/guile.scm is loaded with (use-module (emacs guile)). In the module name, `emacs' is not redundant. If we installed the *.scm files directly in .../scheme/, we would have to either change Guile's module-loading procedures or install a symlink somewhere. > Moreover, it might be fine to install *.scm files > automatically by `make install' of Guile Emacs. True. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: scheme directory 2000-05-03 12:15 ` Kalle Olavi Niemitalo @ 2000-05-05 11:56 ` Ken Raeburn 0 siblings, 0 replies; 8+ messages in thread From: Ken Raeburn @ 2000-05-05 11:56 UTC (permalink / raw) To: Kalle Olavi Niemitalo; +Cc: guile-emacs Eventually, it'd be nice to have Scheme code installed parallel to Lisp code -- i.e., the 20.6/scheme directory and a site-scheme directory, both.... ^ permalink raw reply [flat|nested] 8+ messages in thread
* interrupting the Scheme process 2000-05-03 4:52 scheme directory Satoru Takabayashi 2000-05-03 12:15 ` Kalle Olavi Niemitalo @ 2000-05-03 15:03 ` Keisuke Nishida 2000-05-04 10:21 ` Kalle Olavi Niemitalo 2000-05-05 12:08 ` Ken Raeburn 1 sibling, 2 replies; 8+ messages in thread From: Keisuke Nishida @ 2000-05-03 15:03 UTC (permalink / raw) To: guile-emacs Satoru Takabayashi <satoru-t@is.aist-nara.ac.jp> writes: > I hope interrupting the Scheme process with C-g will be possible. I have no idea of how this can be done right now. Emacs checks for quit in some loops such as eval. When the process is in the Scheme interpreter, we can't use the same way; instead, we have to generate a user interrupt. I guess it is possible for Guile Emacs to bind C-g to generate an interrupt before calling the Scheme evaluator, but I'm not sure about this part. Ken, do you have any idea? Also, once we come to support multi-thread programming with Emacs, things become more complicated. Probably we have to maintain threads in the same way as shells; that is, Emacs will have a "current thread" and "background threads", and the user may quit only the current thread by typing C-g, whereas background threads must be killed by a special command like M-x kill-thread. -- Kei ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: interrupting the Scheme process 2000-05-03 15:03 ` interrupting the Scheme process Keisuke Nishida @ 2000-05-04 10:21 ` Kalle Olavi Niemitalo 2000-05-05 12:08 ` Ken Raeburn 1 sibling, 0 replies; 8+ messages in thread From: Kalle Olavi Niemitalo @ 2000-05-04 10:21 UTC (permalink / raw) To: guile-emacs We might be able to use something like the "emergency escape" (double `C-g') feature. Add a C flag `scheme_evaluator_active' and make `scheme-eval' and `lisp-eval' set and reset it. Then in the `C-g' handler which usually tests `quit-flag', interrupt Guile instead if `scheme_evaluator_active' is set. Emacs would also have to convert Lisp quits to Scheme interrupts and vice versa when returning from the *-eval functions. Could this work? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: interrupting the Scheme process 2000-05-03 15:03 ` interrupting the Scheme process Keisuke Nishida 2000-05-04 10:21 ` Kalle Olavi Niemitalo @ 2000-05-05 12:08 ` Ken Raeburn 2000-05-06 8:00 ` Keisuke Nishida 1 sibling, 1 reply; 8+ messages in thread From: Ken Raeburn @ 2000-05-05 12:08 UTC (permalink / raw) To: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > I have no idea of how this can be done right now. Emacs checks for > quit in some loops such as eval. When the process is in the Scheme > interpreter, we can't use the same way; instead, we have to generate > a user interrupt. I guess it is possible for Guile Emacs to bind C-g > to generate an interrupt before calling the Scheme evaluator, but I'm > not sure about this part. Ken, do you have any idea? Guile has some hooks for recording that an interrupt has occurred and, at certain times, throwing an exception of some sort. If we could set that flag at C-g time, if Scheme code is currently running, might that do the trick? Then Scheme can trap the exception if it wants, but otherwise we throw back to the containing Lisp call. Propagating the unwind through possibly multiple lisp<->scheme interfaces could be hairy though; I haven't looked very closely at that stuff. > Also, once we come to support multi-thread programming with Emacs, > things become more complicated. Probably we have to maintain threads > in the same way as shells; that is, Emacs will have a "current thread" > and "background threads", and the user may quit only the current thread > by typing C-g, whereas background threads must be killed by a special > command like M-x kill-thread. Hm...that might be a way to do it. I also wonder if we might have cases where we want to send the interrupt to multiple threads -- i.e., if the "foreground" thread is sitting around waiting for N tasks to finish (e.g., get new news from news.mycompany.com, get email from pop.mycompany.com, get new news from news.redhat.com, etc), might we want to interrupt all of them and unwind the main thread only after they've died off? I suppose we could have a "spawn and wait for multiple threads" function which implements all of this on top of the scheme^Wplan you describe, by trapping the interrupt... Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: interrupting the Scheme process 2000-05-05 12:08 ` Ken Raeburn @ 2000-05-06 8:00 ` Keisuke Nishida 2000-05-06 10:34 ` Ken Raeburn 0 siblings, 1 reply; 8+ messages in thread From: Keisuke Nishida @ 2000-05-06 8:00 UTC (permalink / raw) To: guile-emacs Ken Raeburn <raeburn@raeburn.org> writes: > Guile has some hooks for recording that an interrupt has occurred and, > at certain times, throwing an exception of some sort. If we could set > that flag at C-g time, if Scheme code is currently running, might that > do the trick? Then Scheme can trap the exception if it wants, but > otherwise we throw back to the containing Lisp call. Propagating the > unwind through possibly multiple lisp<->scheme interfaces could be > hairy though; I haven't looked very closely at that stuff. It seems Emacs catches the interrupt by interrupt_signal in keyboard.c, so we could modify this function so that it also sets the Guile's flag. If this works, we can convert the signal from Guile into a Emacs's quit signal. In case this doesn't work, I don't know what to do. /* This routine is called at interrupt level in response to C-G. If interrupt_input, this is the handler for SIGINT. Otherwise, it is called from kbd_buffer_store_event, in handling SIGIO or SIGTINT. If `waiting_for_input' is non zero, then unless `echoing' is nonzero, immediately throw back to read_char. Otherwise it sets the Lisp variable quit-flag not-nil. This causes eval to throw, when it gets a chance. If quit-flag is already non-nil, it stops the job right away. */ SIGTYPE interrupt_signal (signalnum) /* If we don't have an argument, */ int signalnum; /* some compilers complain in signal calls. */ > Hm...that might be a way to do it. I also wonder if we might have > cases where we want to send the interrupt to multiple threads -- i.e., > if the "foreground" thread is sitting around waiting for N tasks to > finish (e.g., get new news from news.mycompany.com, get email from > pop.mycompany.com, get new news from news.redhat.com, etc), might we > want to interrupt all of them and unwind the main thread only after > they've died off? Probably. We should kill the parent thread and its children at the same time, though I guess we would still need kill-thread to kill detached threads, which are "background" threads. We don't want to close a GTK window, which may run in a separate thread, just by typing C-g, for example. > I suppose we could have a "spawn and wait for multiple threads" > function which implements all of this on top of the scheme^Wplan you > describe, by trapping the interrupt... Anyway, we can't work on this until your Guile-based Emacs appears :) -- Kei ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: interrupting the Scheme process 2000-05-06 8:00 ` Keisuke Nishida @ 2000-05-06 10:34 ` Ken Raeburn 0 siblings, 0 replies; 8+ messages in thread From: Ken Raeburn @ 2000-05-06 10:34 UTC (permalink / raw) To: guile-emacs Keisuke Nishida <kxn30@po.cwru.edu> writes: > It seems Emacs catches the interrupt by interrupt_signal in keyboard.c, > so we could modify this function so that it also sets the Guile's flag. > If this works, we can convert the signal from Guile into a Emacs's quit > signal. In case this doesn't work, I don't know what to do. Looks like the right place to start. Like I said, figuring out which language should get the interrupt and how to propagate the interrupt across language boundaries will probably be trickier than figuring out where to set the flags. > > I suppose we could have a "spawn and wait for multiple threads" > > function which implements all of this on top of the scheme^Wplan you > > describe, by trapping the interrupt... > > Anyway, we can't work on this until your Guile-based Emacs appears :) Yeah.... Emacs 21.1 is going into feature freeze soon, so it's a good time for me to stop putting changes into it and focus on merging it back into my guile-emacs source base. Then when the final release comes, I should be able to make diffs available rather quickly. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-05-06 10:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-03 4:52 scheme directory Satoru Takabayashi 2000-05-03 12:15 ` Kalle Olavi Niemitalo 2000-05-05 11:56 ` Ken Raeburn 2000-05-03 15:03 ` interrupting the Scheme process Keisuke Nishida 2000-05-04 10:21 ` Kalle Olavi Niemitalo 2000-05-05 12:08 ` Ken Raeburn 2000-05-06 8:00 ` Keisuke Nishida 2000-05-06 10:34 ` Ken Raeburn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).