[Openmcl-devel] Portable AllegroServe for Clozure CL

[Dave Cooper]

Hi Gary,

 Thanks for you answer. Yep your analysis is pretty close -- there was a
macro which was trying to expand essentially to a

   (ccl::atomic-incf  (ccl:make-semaphore))

or

   (ccl::atomic-decf (ccl:make-semaphore))


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
> 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<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
>>
>>
>>


-- 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20121218/b6069017/attachment.htm>