[Openmcl-devel] Portable AllegroServe for Clozure CL

[Gary Byers]

It'd be a little easier to say for certain if there was a backtrace or some
other context, but the error looks like it's coming from an attempt to
macroexpand something like:

(ccl::atomic-incf (net.aserve::wserver-free-workers ...) ...)

(CCL::ATOMIC-INCF place &optional (delta 1)) ; there's also a CCL::ATOMIC-DECF

knows how to atomically increment a few kinds of "places" (where the
term "place" means something like "accessor", in much the same way
that it does in discussing SETF and INCF and friends.)  That handful
includes (1) calls to CAR, CDR, and SVREF; (2) certain cases of THE,
LOCALLY, LET/LET* wrapped around (1), and (3) macro calls that expand
into (1) or (2).  The error is saying that
NET.ASERVE::WSERVER-FREE-WORKERS is none of these things.  It isn't
(at least not at the time the ATOMIC-INCF is being expanded); I
suppose that someone might think that it's 3 (a macro expected to
expand into one of the other cases) and that this may be an EVAL-WHEN issue.

It'd be nice if ATOMIC-INCF handled more cases (structure and slot accessors,
more of CxxxR, other kinds of arrays/vectors ...), and it'd be nice if it
was exported and documented.  Someday it hopefully will be, but (among other
issues) there'd be a LOT to document.

If you need to atomically incrememt something and you can't be sure that
CCL::ATOMIC-INCF will work (you can't even be sure that it'll be there), you
can use a heavier hammer:


(defvar *something-lock* (make-lock))

(defstatic *something* 0)       ; not thread-local

(defun atomically-increment-something ()
   (with-lock-grabbed (*something-lock*)
     (incf *something*)))


Of course, that's more expensive and you'd probably get tired of doing that
if you had to do it more than a few times.

Back to your question: if this code ever worked, it's likely that it did so
because NET.ASERVE::WSERVER-FREE-WORKERS was a macro that expanded into
something that CCL::ATOMIC-INCF could deal with; if it's not a macro at
the time it's being used (but will be later), that's obviously "some sort
of build problem".

On Tue, 18 Dec 2012, Dave Cooper wrote:

> 
> Dear All,
> I am trying to get the latest Quicklisp Portable Aserve:
> ??
> ? ?portableaserve-20121125-cvs/
> 
> ?working with the latest CCL from Apple Mac Store:
> 
> ? ?ccl-1.8-f95-macosx-x64?
> 
> Although it looks as though Portable Allegroserve has recently been updated
> for CCL (in October of 2012), I am still getting an error when doing
> ql:quickload on it:
> 
> ?value NET.ASERVE::WSERVER-FREE-WORKERS is not of the expected type (MEMBER
> THE LET LET* LOCALLY CAR CDR SVREF). [Condition of type TYPE-ERROR]
> 
> It looks like this probably worked in the past, since there are specific
> directives for :openmcl-native-threads around the initform of free-workers
> in main.cl.?
> 
> Has anyone a clue of what the issue is here, or would care to have a look at
> it? ?
> 
> We are working to get our Genworks-GDL system
> (http://github.com/genworks/Genworks-GDL) working on CCL, and I got the main
> kernel and basic geometry packages to build today. The next hurdle appears
> to be Portable Allegroserve (yes, we are somewhat entrenched in paserve as
> our webserver, moving to another CL webserver in the short term would not be
> trivial...)
> 
> 
> --
> 
> My Best,
> 
> Dave Cooper, Genworks Support
> david.cooper at genworks.com, dave.genworks.com(skype)
> USA: 248-327-3253(o), 1-248-330-2979(mobile)
> UK: 0191 645 1699
> 
>