[slime-devel] Slime, CLSQL, and reader macros
This is a follow up to a question I asked recently on the CLSQL list. I think the problem is my mental model of Slime. My environment is OS X 10.6.3, Clozure 1.3-r12755M, PostgreSQL 8.4.1, and CLSQL 5.0.5. My problem is with the CLSQL square bracket syntax in Slime. If I run the code below from a REPL started at the command line, it works fine. I can use either the file-enable-sql-reader-syntax or the locally-enable-sql-reader-syntax / restore-sql-reader-syntax-state pair fine. When I evaluate the same code in Slime with C-x C-e or C-c C-r, however, I get this error when defining add-customer: ;Compiler warnings : ; In ADD-CUSTOMER: Undeclared free variable [= ; In ADD-CUSTOMER: Undeclared free variable [ID] ; In ADD-CUSTOMER: Undeclared free variable ID] and this error when trying to add a customer object: Unbound variable: [= [Condition of type UNBOUND-VARIABLE] This happens with either way of enabling the square bracket syntax. Am I misunderstanding something fundamental about Slime? Has anyone managed to use Slime for CLSQL development with the square bracket syntax? Thanks, Patrick (in-package :common-lisp-user) (defpackage :clsql-testing (:use :common-lisp :clsql)) (in-package :clsql-testing) (file-enable-sql-reader-syntax) ;(locally-enable-sql-reader-syntax) (def-view-class customer () ((id :db-kind :key :db-constraints :not-null :initarg :id :reader id :type integer) (name :db-constraints :not-null :initarg :name :reader name :type string) (phone-number :db-constraints :not-null :initarg :phone-number :accessor phone-number :type string)) (:base-table "test_customer")) (defconstant +id-sequence+ "id_sequence") (defun add-customer (name phone-number) "Add a customer." (let ((id (sequence-next +id-sequence+))) (update-records-from-instance (make-instance 'customer :id id :name name :phone-number phone-number)) (first (select 'customer :where [= [id] id] :flatp t)))) (connect '("localhost" "db-name" "user" "password") :database-type :postgresql-socket :if-exists :new :pool t) (defparameter customer-foo (add-customer "Test Customer Foo" "0123456789")) (id customer-foo) ;(restore-sql-reader-syntax-state) (disconnect-pooled)
On 4/1/2010 9:41 AM, Patrick May wrote:
This is a follow up to a question I asked recently on the CLSQL list. I think the problem is my mental model of Slime.
My environment is OS X 10.6.3, Clozure 1.3-r12755M, PostgreSQL 8.4.1, and CLSQL 5.0.5.
My problem is with the CLSQL square bracket syntax in Slime. If I run the code below from a REPL started at the command line, it works fine. I can use either the file-enable-sql-reader-syntax or the locally-enable-sql-reader-syntax / restore-sql-reader-syntax-state pair fine. When I evaluate the same code in Slime with C-x C-e or C-c C-r, however, I get this error when defining add-customer:
;Compiler warnings : ; In ADD-CUSTOMER: Undeclared free variable [= ; In ADD-CUSTOMER: Undeclared free variable [ID] ; In ADD-CUSTOMER: Undeclared free variable ID]
and this error when trying to add a customer object:
Unbound variable: [= [Condition of type UNBOUND-VARIABLE]
This happens with either way of enabling the square bracket syntax.
Am I misunderstanding something fundamental about Slime? Has anyone managed to use Slime for CLSQL development with the square bracket syntax?
I've only really worked with SBCL so there might be something different in the implementations, but yes the square bracket reader syntax works fine for me under slime. Here's some more data that may help you with your model * Slime compiles some things with (eval (read "your code here")) e.g. the REPL does this and most of the 'Evaluation' commands that start with C-x; * Slime compiles some stuff with compile-file-- simple case is C-c C-k-- but sometimes it copies a region from emacs into a temporary file, and then calls compile-file on that -- most compilation commands that start with C-c probably do this. * According to the spec any modifications to the binding of *readtable* should be undone by the impl after it finishes COMPILE-FILE or LOADing a resource. There is no such restriction for eval. ALL of the clsql macros effect the binding leaving the previous readtable intact for when the impl restores it. My standard workflow: * Every file that needs it has (file-enable...) 1. load a project with asdf under slime 2. hack, at some point I go to redefine a function with C-c C-c, get the syntax error 3. go to the top of the file, evaluate the file-enable with C-x C-e * at this point, the *readtable* variable is permanently modified to point to a readtable that includes the [] syntax, there are no references to the old readtable. If i were to need to undo that I would need another function that sets for those characters, or to restart my lisp. This just about never comes up for me. Hope that helps! -- Nathan Bird nathan@acceleration.net http://www.acceleration.net/ Custom Programming, Design, Hosting, and Broadband.
[ Adding OpenMCL-devel, since CCL seems to be involved somehow in this problem. ] On Apr 1, 2010, at 10:32 AM, Nathan Bird wrote:
On 4/1/2010 9:41 AM, Patrick May wrote:
My environment is OS X 10.6.3, Clozure 1.3-r12755M, PostgreSQL 8.4.1, and CLSQL 5.0.5.
My problem is with the CLSQL square bracket syntax in Slime. If I run the code below from a REPL started at the command line, it works fine. I can use either the file-enable-sql-reader-syntax or the locally-enable-sql-reader-syntax / restore-sql-reader-syntax-state pair fine. When I evaluate the same code in Slime with C-x C-e or C-c C-r, however, I get this error when defining add-customer:
;Compiler warnings : ; In ADD-CUSTOMER: Undeclared free variable [= ; In ADD-CUSTOMER: Undeclared free variable [ID] ; In ADD-CUSTOMER: Undeclared free variable ID]
and this error when trying to add a customer object:
Unbound variable: [= [Condition of type UNBOUND-VARIABLE]
This happens with either way of enabling the square bracket syntax.
Am I misunderstanding something fundamental about Slime? Has anyone managed to use Slime for CLSQL development with the square bracket syntax?
I've only really worked with SBCL so there might be something different in the implementations, but yes the square bracket reader syntax works fine for me under slime.
Interesting. I tried this with SBCL and it worked. Why would ccl64 behave differently? (Code below.) Thanks, Patrick (in-package :common-lisp-user) (defpackage :clsql-testing (:use :common-lisp :clsql)) (in-package :clsql-testing) (file-enable-sql-reader-syntax) ;(locally-enable-sql-reader-syntax) (def-view-class customer () ((id :db-kind :key :db-constraints :not-null :initarg :id :reader id :type integer) (name :db-constraints :not-null :initarg :name :reader name :type string) (phone-number :db-constraints :not-null :initarg :phone-number :accessor phone-number :type string)) (:base-table "test_customer")) (defconstant +id-sequence+ "id_sequence") (defun add-customer (name phone-number) "Add a customer." (let ((id (sequence-next +id-sequence+))) (update-records-from-instance (make-instance 'customer :id id :name name :phone-number phone-number)) (first (select 'customer :where [= [id] id] :flatp t)))) (connect '("localhost" "db-name" "user" "password") :database-type :postgresql-socket :if-exists :new :pool t) (defparameter customer-foo (add-customer "Test Customer Foo" "0123456789")) (id customer-foo) ;(restore-sql-reader-syntax-state) (disconnect-pooled)
* Patrick May [2010-04-01 19:59+0200] writes:
Interesting. I tried this with SBCL and it worked. Why would ccl64 behave differently? (Code below.)
Probably because *readtable* is a only modified in the per-thread binding in CCL and if you only change it in the repl thread other threads don't see that. Helmut
On Apr 1, 2010, at 2:10 PM, Helmut Eller wrote:
* Patrick May [2010-04-01 19:59+0200] writes:
Interesting. I tried this with SBCL and it worked. Why would ccl64 behave differently? (Code below.)
Probably because *readtable* is a only modified in the per-thread binding in CCL and if you only change it in the repl thread other threads don't see that.
Thanks for the explanation. The problem seems to be with my mental model of how Slime is working. My mental model was that when I evaluate forms in the code buffer, the evaluation takes place in the REPL, since that's where I see the results (except for those displayed in the minibuffer). Since that model was clearly incorrect, I did the unthinkable and read the manual. Sure enough, section 3.1.3 discusses swank:*default-worker-thread-bindings* and even mentions issues with printer and reader behavior. Section 6.2.1 touches on similar issues with swank:*communication-style*. My goal is to have my development and testing in Slime reflect exactly what will happen when I run the same code in the same file from the command line. I see three possible ways of achieving this: 1) Configure Clozure to behave more like SBCL, if possible. 2) Use swank:*default-worker-thread-bindings* externally to the file somehow. 3) Set swank:*communication-style* to :fd-handler. Are there other solutions? What is my best option? What are the drawbacks to using :fd-handler? Thanks, Patrick
* Patrick May [2010-04-02 19:20+0200] writes:
My goal is to have my development and testing in Slime reflect exactly what will happen when I run the same code in the same file from the command line. I see three possible ways of achieving this:
1) Configure Clozure to behave more like SBCL, if possible. 2) Use swank:*default-worker-thread-bindings* externally to the file somehow. 3) Set swank:*communication-style* to :fd-handler.
:fd-handler doesn't work with CCL. You could set swank:*communication-style* to nil, which works with every backend, but of course loses some niceties, eg. you can't use M-. while Lisp does a lengthy computation.
Are there other solutions?
You could use swank:*readtable-alist* tell Slime that a certain readtable should be used for certain packages. If you have a EVAL-WHEN form to switch readtables at the beginning of the file, you could simply use C-c C-k and compile the file as one unit. Of course, that's not a real fix but good enough in many cases.
What is my best option?
Well, the easiest would be not to mess around with custom read syntax and follow the old advice: "don't fight your tools".
What are the drawbacks to using :fd-handler?
Only works with CMUCL/SBCL (but not on Windows) and some other rather technical problems that you probably don't want to know. Helmut
On Apr 2, 2010, at 2:20 PM, Helmut Eller wrote:
* Patrick May [2010-04-02 19:20+0200] writes:
My goal is to have my development and testing in Slime reflect exactly what will happen when I run the same code in the same file from the command line. I see three possible ways of achieving this:
1) Configure Clozure to behave more like SBCL, if possible. 2) Use swank:*default-worker-thread-bindings* externally to the file somehow. 3) Set swank:*communication-style* to :fd-handler.
:fd-handler doesn't work with CCL. You could set swank:*communication-style* to nil, which works with every backend, but of course loses some niceties, eg. you can't use M-. while Lisp does a lengthy computation.
Thanks for the details. Is supporting :fd-handler for CCL on the roadmap?
What is my best option?
Well, the easiest would be not to mess around with custom read syntax and follow the old advice: "don't fight your tools".
Like Slime, CLSQL is a pretty standard tool. I'm surprised to have so much trouble using them together. Thanks again for the help. Regards, Patrick
Like Slime, CLSQL is a pretty standard tool. I'm surprised to have so much trouble using them together.
fyi, we are using reader macros all around our projects and swank:*readtable-alist* works good enough together with an asdf customization that enables the readers while compiling/loading the files. http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.asdf;a=headblob;f=/sou... http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/inte... hth, -- attila ps: although we have a fix for swank that makes sldb-show-source less broken: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.slime;a=filediff;h=200...
On Apr 2, 2010, at 4:13 PM, Attila Lendvai wrote:
Like Slime, CLSQL is a pretty standard tool. I'm surprised to have so much trouble using them together.
fyi, we are using reader macros all around our projects and swank:*readtable-alist* works good enough together with an asdf customization that enables the readers while compiling/loading the files.
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.asdf;a=headblob;f=/sou...
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/inte...
Thanks for the links. Time for me to dive more deeply into the innards of Slime and CLSQL. Regards, Patrick
Patrick May <patrick.may@mac.com> writes:
On Apr 2, 2010, at 4:13 PM, Attila Lendvai wrote:
Like Slime, CLSQL is a pretty standard tool. I'm surprised to have so much trouble using them together.
fyi, we are using reader macros all around our projects and swank:*readtable-alist* works good enough together with an asdf customization that enables the readers while compiling/loading the files.
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.asdf;a=headblob;f=/sou...
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/inte...
Thanks for the links. Time for me to dive more deeply into the innards of Slime and CLSQL.
I suggest you make CLSQL use http://common-lisp.net/project/named-readtables/ and all your problems will go away eventually. -T.
* Patrick May [2010-04-02 21:03+0200] writes:
:fd-handler doesn't work with CCL. You could set swank:*communication-style* to nil, which works with every backend, but of course loses some niceties, eg. you can't use M-. while Lisp does a lengthy computation.
Thanks for the details. Is supporting :fd-handler for CCL on the roadmap?
No, CCL has threads so no need for :fd-handler. Helmut
On Apr 2, 2010, at 4:58 PM, Helmut Eller wrote:
* Patrick May [2010-04-02 21:03+0200] writes:
:fd-handler doesn't work with CCL. You could set swank:*communication-style* to nil, which works with every backend, but of course loses some niceties, eg. you can't use M-. while Lisp does a lengthy computation.
Thanks for the details. Is supporting :fd-handler for CCL on the roadmap?
No, CCL has threads so no need for :fd-handler.
I don't follow your logic. SBCL has threads on many platforms as well. More importantly, the behavior within Slime when running CCL is non-intuitive and the fix for that is not obvious (although I'm still working on it). The behavior of :fd-handler seems as though it would address the issue, so why wouldn't it be supported for CCL? Thanks, Patrick
* Patrick May [2010-04-03 16:13+0200] writes:
No, CCL has threads so no need for :fd-handler.
I don't follow your logic. SBCL has threads on many platforms as well.
Yeah, these days it would better to remove :fd-handler for SBCL.
More importantly, the behavior within Slime when running CCL is non-intuitive and the fix for that is not obvious (although I'm still working on it). The behavior of :fd-handler seems as though it would address the issue, so why wouldn't it be supported for CCL?
:fd-handler assumes that something runs an event loop when I/O operations like READ-CHAR would otherwise block. CCL doesn't do that. If you want to run it single threaded you can set swank:*communication-style* to nil. Helmut
participants (5)
-
Attila Lendvai -
Helmut Eller -
Nathan Bird -
Patrick May -
Tobias C. Rittweiler