[Openmcl-devel] Portable AllegroServe for Clozure CL
david.cooper at genworks.com
Tue Dec 18 15:33:18 CST 2012
Thanks for you answer. Yep your analysis is pretty close -- there was a
macro which was trying to expand essentially to a
Clearly atomic-incf should not really have been used here in the first
place because it's unexported and undocumented.
So the thing which is trying to be incremented and decremented is a
semaphore. It appears that the correct way to deal with this is to use
ccl:signal-semaphore and ccl:wait-on-semaphore instead of the direct
atomic-incf and atomic-decf. I made that substitution, and portable aserve
seems to be functioning correctly now, at least within our framework.
I will let you know when the change is committed into Sourceforge in case
you care to review it.
By the way, the compile and fasl-load speed of CCL certainly is impressive!
On Tue, Dec 18, 2012 at 4:10 PM, Gary Byers <gb at clozure.com> wrote:
> 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
> 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
> It'd be nice if ATOMIC-INCF handled more cases (structure and slot
> 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
> 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),
> 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
>> 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
>> 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
>> it? ?
>> We are working to get our Genworks-GDL system
>> 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
>> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel