Hi,
If I start slime using openmcl 0.14.2-p1 on jaguar (mac os 10.2) I get different behaviours that I can't explain when I evaluate lisp forms fin different ways.
I get one behaviour when I type C-x C-e after the form in the *slime-repl* buffer or when I type the form at the prompt and press enter and another behaviour when I type C-x C-e after the form in the *inferior-lisp* buffer.
The form in question opens a cocoa-window using a window-controller that is supposed to release the window when the window is closed. The problem is that the window is only released and deallocated when I evaluate the form to open the window from the inferior-lisp buffer by typing C-x C-e, not in the other cases.
Could you please give me some hints about the differences in evaluating forms in the various ways I described so that I might get to the bottom of this annoying bug I have. I have torn my hair out for almost a week trying to locate this bug in my code and now I am quite desperate. The bug only manifests itself with very particular combinations of the lisp-code that drives the gui and the nib-file that defines the gui.
I am sorry if this is off topic but I don't know how else to proceed.
// Anders
Anders Conradi beque@telia.com writes:
If I start slime using openmcl 0.14.2-p1 on jaguar (mac os 10.2) I get different behaviours that I can't explain when I evaluate lisp forms fin different ways.
I get one behaviour when I type C-x C-e after the form in the *slime-repl* buffer or when I type the form at the prompt and press enter and another behaviour when I type C-x C-e after the form in the *inferior-lisp* buffer.
Here are the cases:
`C-x C-e' should be the same in every buffer, except that some buffers have different Lisp packages associated with them than others. In a default OpenMCL configuration it will evaluate each `C-x C-e' in a new thread.
Entering the expression at the REPL is the same except that it always uses the same thread, i.e. one thread is dedicated to evaluating REPL expressions.
If you enter it at the *inferior-lisp* prompt then you are bypassing SLIME entirely. It will evaluate in the same way as OpenMCL does when running without SLIME.
The form in question opens a cocoa-window using a window-controller that is supposed to release the window when the window is closed. The problem is that the window is only released and deallocated when I evaluate the form to open the window from the inferior-lisp buffer by typing C-x C-e, not in the other cases.
I can't account for this. You're definitely pressing `C-x C-e' and not return in *inferior-lisp*? Can you give any more details?
-Luke
On måndag, jun 21, 2004, at 08:33 Europe/Stockholm, Luke Gorrie wrote:
Anders Conradi beque@telia.com writes:
If I start slime using openmcl 0.14.2-p1 on jaguar (mac os 10.2) I get different behaviours that I can't explain when I evaluate lisp forms fin different ways.
I get one behaviour when I type C-x C-e after the form in the *slime-repl* buffer or when I type the form at the prompt and press enter and another behaviour when I type C-x C-e after the form in the *inferior-lisp* buffer.
Here are the cases:
`C-x C-e' should be the same in every buffer, except that some buffers have different Lisp packages associated with them than others. In a default OpenMCL configuration it will evaluate each `C-x C-e' in a new thread.
Entering the expression at the REPL is the same except that it always uses the same thread, i.e. one thread is dedicated to evaluating REPL expressions.
If you enter it at the *inferior-lisp* prompt then you are bypassing SLIME entirely. It will evaluate in the same way as OpenMCL does when running without SLIME.
The form in question opens a cocoa-window using a window-controller that is supposed to release the window when the window is closed. The problem is that the window is only released and deallocated when I evaluate the form to open the window from the inferior-lisp buffer by typing C-x C-e, not in the other cases.
I can't account for this. You're definitely pressing `C-x C-e' and not return in *inferior-lisp*? Can you give any more details?
Sure.
If I perform the steps 1) Open emacs 2) Type M-x slime 3) Open rpn-debug.lisp 4) Type C-c C-k in the rpn-debug.lisp buffer 5) C-x b to the *slime-repl* 6) type (open-calc) *but not enter* 7) Type C-x C-e 8) Split the window into two frames, one containing *slime-repl* and one *inferior-lisp* 9) close the that opened by performing (open-calc)
Then I get the following in the *inferior-lisp* buffer: (load "/Users/acon/emacs/slime/swank-loader.lisp") (swank:start-server "/tmp/slime.11203") Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-p1! ? ; Warning: These Swank interfaces are unimplemented: ; (ADD-FD-HANDLER ADD-SIGIO-HANDLER LIST-CALLEES MACROEXPAND-ALL PROFILE PROFILE-PACKAGE PROFILE-REPORT PROFILE-RESET PROFILED-FUNCTIONS REMOVE-FD-HANDLERS REMOVE-SIGIO-HANDLERS SLDB-STEP UNPROFILE WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES #P"/Users/acon/Developer/Lisp/systems/slime/swank-loader.lisp" ? ;; Swank started at port: 59878. 59878 ? 2004-06-21 10:26:58.175 [11205] *** Illegal NSTableView data source (<RpnCalculator: 0x82339350>). Must implement numberOfRowsInTableView: and tableView:objectValueForTableColumn:row: 2004-06-21 10:26:58.176 [11205] Window awaken 2004-06-21 10:27:11.210 [11205] Closing calculator 2004-06-21 10:27:11.231 [11205] calculator dealloc
And this in *slime-repl*: ; SLIME: The Superior Lisp Interaction Mode for Emacs ;;;; Compile file /Users/acon/Developer/Lisp/systems/rpn/rpn-debu ... ;;;; (open-calc) ... CL-USER> (open-calc)
If I close emacs and perform the same steps up to step 4 and then do 5) switch to the *inferior-lisp* buffer 6) type (open-calc) *but not enter* 7) type C-x C-e
And then the same steps 8 & 9 I get in *inferior-lisp*: (load "/Users/acon/emacs/slime/swank-loader.lisp") (swank:start-server "/tmp/slime.11207") Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-p1! ? ; Warning: These Swank interfaces are unimplemented: ; (ADD-FD-HANDLER ADD-SIGIO-HANDLER LIST-CALLEES MACROEXPAND-ALL PROFILE PROFILE-PACKAGE PROFILE-REPORT PROFILE-RESET PROFILED-FUNCTIONS REMOVE-FD-HANDLERS REMOVE-SIGIO-HANDLERS SLDB-STEP UNPROFILE WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES #P"/Users/acon/Developer/Lisp/systems/slime/swank-loader.lisp" ? ;; Swank started at port: 59884. 59884 ? 2004-06-21 10:28:51.063 [11209] *** Illegal NSTableView data source (<RpnCalculator: 0x1b47610>). Must implement numberOfRowsInTableView: and tableView:objectValueForTableColumn:row: 2004-06-21 10:28:51.064 [11209] Window awaken 2004-06-21 10:29:02.021 [11209] Closing calculator 2004-06-21 10:29:02.053 [11209] calculator dealloc 2004-06-21 10:29:02.053 [11209] Window dealloc (open-calc)
And in *slime-repl*: ; SLIME: The Superior Lisp Interaction Mode for Emacs ;;;; Compile file /Users/acon/Developer/Lisp/systems/rpn/rpn-debu ... ;;;; (open-calc) ... CL-USER>
This is the part of my .emacs file that configures slime: ;; Slime - The Superior Lisp Interaction Mode for Emacs (add-to-list 'load-path "/Users/acon/emacs/slime/") (require 'slime) (add-hook 'lisp-mode-hook (lambda () (slime-mode t))) (setq inferior-lisp-program "/Users/acon/Applications/bin/openmcl") (add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t))) (setq common-lisp-hyperspec-root "file:///Users/acon/Documents/Bibliotek/HyperSpec-6-0/HyperSpec/")
I have attached a tarball containing rpn-debug.lisp and RpnCalculator.nib.
-Luke
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On Mon, 21 Jun 2004 00:40:40 +0200, Anders Conradi beque@telia.com said:
Anders> If I start slime using openmcl 0.14.2-p1 on jaguar (mac os 10.2) I get Anders> different behaviours that I can't explain when I evaluate lisp forms Anders> fin different ways.
Anders> I get one behaviour when I type C-x C-e after the form in the Anders> *slime-repl* buffer or when I type the form at the prompt and press Anders> enter and another behaviour when I type C-x C-e after the form in the Anders> *inferior-lisp* buffer.
Anders> The form in question opens a cocoa-window using a window-controller Anders> that is supposed to release the window when the window is closed. The Anders> problem is that the window is only released and deallocated when I Anders> evaluate the form to open the window from the inferior-lisp buffer by Anders> typing C-x C-e, not in the other cases.
Anders> Could you please give me some hints about the differences in evaluating Anders> forms in the various ways I described so that I might get to the bottom Anders> of this annoying bug I have. I have torn my hair out for almost a week Anders> trying to locate this bug in my code and now I am quite desperate. The Anders> bug only manifests itself with very particular combinations of the Anders> lisp-code that drives the gui and the nib-file that defines the gui.
Could be a threading issue -- Cocoa things should be run in the thread that is created by the OS when the application starts, which might be the inferior-lisp buffer.
__Martin
Martin Simmons martin@xanalys.com writes:
Could be a threading issue -- Cocoa things should be run in the thread that is created by the OS when the application starts, which might be the inferior-lisp buffer.
The weird part is that pressing `C-x C-e' should do the same thing in *inferior-lisp* as in any other buffer. Only pressing return would actually send the input to the listener. But there must be something subtle at work..
-Luke
Luke Gorrie luke@bluetail.com writes:
The weird part is that pressing `C-x C-e' should do the same thing in *inferior-lisp* as in any other buffer. Only pressing return would actually send the input to the listener. But there must be something subtle at work..
C-x C-e in the *inferior-lisp* is bound to lisp-eval-last-sexp and will send something to the listener. Should we change that?
Helmut.
On måndag, jun 21, 2004, at 14:19 Europe/Stockholm, Luke Gorrie wrote:
Martin Simmons martin@xanalys.com writes:
Could be a threading issue -- Cocoa things should be run in the thread that is created by the OS when the application starts, which might be the inferior-lisp buffer.
The weird part is that pressing `C-x C-e' should do the same thing in *inferior-lisp* as in any other buffer. Only pressing return would actually send the input to the listener. But there must be something subtle at work..
As thread interaction is very fragile and the symptoms can easily be this subtle unless all ducks are in a perfect row, and since my duck was out of line, I am sure this explains everything.
Since doing C-x C-e in the *slime-repl* buffer uses the same thread as pressing enter after the expression in the repl and C-x C-e in *inferior-lisp* uses a worker thread, I am sure there is some timing issue that causes the difference.
Thanks you all for your time, and sorry if I wasted it.
// Anders
-
Anders Conradi -
Helmut Eller -
Luke Gorrie -
Martin Simmons