[Openmcl-devel] [CLSQL] Slime, CLSQL, and reader macros

[Robert Cram]

Gary, thanks, I was responding to a note from the 2010 archives, about some CLSQL macros for a special SQL query language, which used an altered readtable, swapping it in and out on demand.  In slime, the behavior didn’t work in 2010, and it still doesn’t in 2015 in CCL running in slime.  The 2010 notes were useful for me to identify and deal with the issue, so I responded with the aim of being helpful to anyone searching now or in the future for similar issues.

I’ve just re-picked up LISP after a lengthy time away from it, and I have little sense of what any currently relevant environments and tools are - it may be that commenting on CLSQL running in slime is quaint, or sad, or still perfectly relevant - I really don’t know.  It’s working for me, anyway.

- Bob 

Bob Cram
Robert Cram Construction
www.robertcramconstruction.com <http://www.robertcramconstruction.com/>
415-613-8319
robert at robertcramconstruction.com <mailto:robert at robertcramconstruction.com>
CA LIC 965300

> On Mar 5, 2015, at 10:13 AM, Gary Byers <gbyersnm at gmail.com> wrote:
> 
> I'm not sure that i  remember the specific problem that you're referring to.
> 
> In CCL, many special variables (including those that affect the reader and printer have thread-local bindings.)  I understand that this may not be what one wants in every case , but if your code is intentionally creating threads, having the value of e.g. *readtable* change in all threads becausee of something done in one thread can be undesirable and hard to track down and debug, and I think that there is at least a strong argument that CCL's behavior in this case is a reasonable default.
> 
> I  don't like or use SLME and I don't know if its behavior has changed since the last time that I tried to, but when I did I found that the default behavior of editor commands which try to read a selection from an editor buffer and execute the expression that was read is to execute that expression in a newly created thread (with a new set of dynamic bindings)  I can't think of any way in which this behavor can be callled reasonable.)
> 
> If I ever knew how to override this behavior, I've long since forgotten.  I understand that many people might find my solution - avoiding SLIME - a bit drastic, but I I don't exactly miss SLIME.
> 
> 
> On Wed, Mar 4, 2015 at 11:32 PM, Robert Cram <robert at robertcramconstruction.com <mailto:robert at robertcramconstruction.com>> wrote:
> I realize that this is an old thread, but the issue just came up for me.  Perhaps it was answered or solved later, but I didn’t find so.
> 
> A fix of some sort, in some versions of Clozure and emacs/slime, is this line:
> 
> (setf clsql-sys::*original-readtable* nil)
> 
> which resets the clsql readtable caching mechanism, which is unaware of the slime/mcl/ccl thread-specific readtable issue.
> 
> Used like this:
> 
> ;; Reset the mechanism.
> (setf clsql-sys::*original-readtable* nil)
> 
> ;; Alter the read table.
> (clsql::enable-sql-reader-syntax)
> 
> ;; Do whatever special syntax stuff you need to do:
> (defun blah (blah)
>   (clsql::select ‘blah
>                  :where [= [ ‘blah ‘blah]
>                  blah])
>   )
> ;; Disable the syntax….
> 
> The point is that killing the cache needs to happen in the same evaluation as the code with the special syntax.
> 
> I make no claim except that the original error goes away.
> 
> 
> Bob Cram
> Robert Cram Construction
> www.robertcramconstruction.com <http://www.robertcramconstruction.com/>
> 415-613-8319 <tel:415-613-8319>
> robert at robertcramconstruction.com <mailto:robert at robertcramconstruction.com>
> CA LIC 965300
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
> https://lists.clozure.com/mailman/listinfo/openmcl-devel <https://lists.clozure.com/mailman/listinfo/openmcl-devel>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20150305/7a1fe31e/attachment.htm>