<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel">
    <title>gmane.lisp.closer.devel</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/351"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/349"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/348"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/347"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/346"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/340"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/338"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/336"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/335"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/334"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/333"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/332"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/331"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/330"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/329"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/328"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/327"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/326"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/325"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.closer.devel/324"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/351">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/351</link>
    <description>&lt;pre&gt;
On Sep 9, 2012, at 18:46, Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt; wrote:

[...]


It's simpler than that - slot-boundp-using-class was just utterly broken for classes with non-standard metaclass.  r14154 has the embarrassing details.

Rudi
&lt;/pre&gt;</description>
    <dc:creator>Rudolf Schlatte</dc:creator>
    <dc:date>2012-09-19T19:02:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/349">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/349</link>
    <description>&lt;pre&gt;
On 5 Sep 2012, at 12:33, Rudolf Schlatte &amp;lt;rudi&amp;lt; at &amp;gt;constantly.at&amp;gt; wrote:



This would probably make sense.

On to the next bug:

CL-USER(1): (use-package :mop)
T

CL-USER(2): (defclass my-class (standard-class) ())
#&amp;lt;STANDARD-CLASS MY-CLASS {5122152B}&amp;gt;

CL-USER(3): (defmethod slot-unbound ((class my-class) object slot) (print :foo) (call-next-method))
#&amp;lt;STANDARD-METHOD SLOT-UNBOUND (MY-CLASS T T) {149BE3AA}&amp;gt;

CL-USER(4): (defclass test () ((slot :accessor test-slot)) (:metaclass my-class))
#&amp;lt;MY-CLASS TEST {79BC8795}&amp;gt;

CL-USER(8): (make-instance 'test)
#&amp;lt;TEST {21BF4C80}&amp;gt;

CL-USER(9): (slot-boundp * 'slot)
T

CL-USER(10): (test-slot **)

:FOO 
#&amp;lt;THREAD "interpreter" {12EEA1E7}&amp;gt;: Debugger invoked on condition of type UNBOUND-SLOT
  The slot SLOT is unbound in the object #&amp;lt;TEST {21BF4C80}&amp;gt;.
Restarts:
  0: TOP-LEVEL Return to top level.

It seems that as soon as a method on slot-unbound is defined, slot-boundp returns t no matter whether the slot is bound or not. This should not be the case.


Another issue that I'&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-09-09T16:46:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/348">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/348</link>
    <description>&lt;pre&gt;
On Aug 26, 2012, at 22:37, Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt; wrote:


[etc]

Nice.  For more fun and games, consider (setf (class-name *c1*) t) - instant universal superclass.  Anyway, both issues are hopefully fixed now.

I wonder if this should be added to ansi-tests.

Rudi
&lt;/pre&gt;</description>
    <dc:creator>Rudolf Schlatte</dc:creator>
    <dc:date>2012-09-05T10:33:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/347">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/347</link>
    <description>&lt;pre&gt;
On 26 Aug 2012, at 21:26, Rudolf Schlatte &amp;lt;rudi&amp;lt; at &amp;gt;constantly.at&amp;gt; wrote:



Perfect, these bug fixes come in very fast… :)

OK, on to the next bug: It seems that anonymous classes are always considered subtypes of other classes. This is not correct. Here is transcript:

CL-USER(1): (defparameter *c1* (make-instance 'standard-class))
*C1*
CL-USER(2): (defparameter *c2* (make-instance 'standard-class))
*C2*
CL-USER(3): (subtypep *c1* *c2*)
T
T
CL-USER(4): (defclass c1 () ())
#&amp;lt;STANDARD-CLASS C1 {4ABAD094}&amp;gt;
CL-USER(5): (defclass c2 () ())
#&amp;lt;STANDARD-CLASS C2 {2EC195E3}&amp;gt;
CL-USER(6): (subtypep 'c1 'c2)
NIL
T
CL-USER(7): (subtypep (find-class 'c1) (find-class 'c2))
NIL
T
CL-USER(8): (subtypep *c1* 'c1)
T
T
CL-USER(9): (subtypep 'c1 *c1*)
NIL
T

(The integration of types and classes is a bit complex. See 4.3.1 in the HyperSpec, especially the notion of "proper name", and 4.3.7.)

Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.
&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-08-26T20:37:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/346">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/346</link>
    <description>&lt;pre&gt;
On Aug 26, 2012, at 19:17, Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt; wrote:


(set-)standard-instance-access didn't check for invalid object layout, fixed in r14137.  Pure slot-value goes through a different code path for classes with metaclass standard-class, which did the check and update already.

Thanks for reporting!

Rudi
&lt;/pre&gt;</description>
    <dc:creator>Rudolf Schlatte</dc:creator>
    <dc:date>2012-08-26T19:26:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/340">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/340</link>
    <description>&lt;pre&gt;
On Aug 19, 2012, at 17:49, Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt; wrote:


Hi Pascal,

Thanks for the report and diagnosis!  This (and a related bug reported by Stas Boukarev) are hopefully fixed in svn.

Slot objects are allocated deep in Java-land (see SlotDefinition.java resp. clos.lisp:make-(direct|effective)-slot-definition for boring details) and the accessors defined in the SlotDefinition class used to believe they know everything about the layout of slot objects.  r14134 adds code paths for normal standard-object slot definitions.

Thanks again,

Rudi
&lt;/pre&gt;</description>
    <dc:creator>Rudolf Schlatte</dc:creator>
    <dc:date>2012-08-25T21:21:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/338">
    <title>Re: Closer-mop support for ABCL</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/338</link>
    <description>&lt;pre&gt;Hi Rudi,

I'm currently looking into adding support for ABCL 1.1 to the Closer project. I'm not only adding the support for Closer to MOP itself, but I'm also testing whether the other packages work (like ContextL, etc.).

I found a bug with regard to the slot layout of metaobject classes. It seems that fixed slot positions are assumed where this shouldn't be the case. Here is a transcript that illustrates the problem:

CL-USER(6): (defclass my-effective-slot-definition (standard-effective-slot-definition)
              ((additional-information :initarg :additional-information)))
#&amp;lt;STANDARD-CLASS MY-EFFECTIVE-SLOT-DEFINITION {55FD7136}&amp;gt;

CL-USER(7): (defclass my-class (standard-class) ())
#&amp;lt;STANDARD-CLASS MY-CLASS {1A78B825}&amp;gt;

CL-USER(8): (defmethod effective-slot-definition-class ((class my-class) &amp;amp;rest initargs)
              (find-class 'my-effective-slot-definition))
#&amp;lt;STANDARD-METHOD EFFECTIVE-SLOT-DEFINITION-CLASS (MY-CLASS) {6B8192B6}&amp;gt;

CL-USER(9): (defclass person () 
              ((name :initarg :n&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-08-19T15:49:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/336">
    <title>Re: closer-devel Digest, Vol 56, Issue 3</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/336</link>
    <description>&lt;pre&gt;Hi,

Unfortunately, there is only so much time I can afford to invest in this. Although I agree more documentation would be definitely very useful, I can only do very little in that direction right now.

Please feel free to ask questions, though, I can easily be lured into thinking about interesting ones. ;)

Closer-devel is a good mailing list for such questions, as is the pro mailing list at http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro - which may be more appropriate, depending on use case. (I follow both lists.)


Best,
Pascal

On 18 Mar 2012, at 20:23, Dan Lentz wrote:


--
Pascal Costanza



_______________________________________________
closer-devel mailing list
closer-devel&amp;lt; at &amp;gt;common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel
&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-03-18T21:57:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/335">
    <title>Re: ContextL: allow other keys in (re)initialize-instance methods for metaclasses</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/335</link>
    <description>&lt;pre&gt;It seems to work. Thanks a lot for the quick fix! I'm glad my report
was helpful.
Paul



On 19 Mar 2012, at 05:10, Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Paul Sexton</dc:creator>
    <dc:date>2012-03-18T20:20:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/334">
    <title>Re: closer-devel Digest, Vol 56, Issue 3</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/334</link>
    <description>&lt;pre&gt;wow, this is a really helpful example as I have recently been stumbling
about the problem of introducing a persistent subclass of layered-class
(specifically on top of the dstm transactional layered class example that I
found floating around and the associated paper by pascal.)   Is this
something that might be valuable to annotate a bit and include in the
contextl distro as an additional example?

contextl seems to be the answer to a number of questions regarding how to
combine meta class behaviors, but the biggest problem I have run into is
the sparseness of the papers and examples with regards to learning how to
model solutions based on layered class architectures.  This seems like a
useful addition?



Message: 1
Date: Sun, 18 Mar 2012 17:10:11 +0100
From: Pascal Costanza &amp;lt;pc&amp;lt; at &amp;gt;p-cos.net&amp;gt;
To: Paul Sexton &amp;lt;psexton.2a&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: closer-devel&amp;lt; at &amp;gt;common-lisp.net
Subject: Re: [closer-devel] ContextL: allow other keys in
   (re)initialize-instance methods for metaclasses
Message-ID: &amp;lt;4B1FC6C3-FAD1-4DAF-BA50-8AB&lt;/pre&gt;</description>
    <dc:creator>Dan Lentz</dc:creator>
    <dc:date>2012-03-18T19:23:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/333">
    <title>Re: ContextL: allow other keys in(re)initialize-instance methods for metaclasses</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/333</link>
    <description>&lt;pre&gt;Hi Paul,

Thanks a lot again for reporting this problem. This uncovered a conceptual omission in the meta-level architecture of ContextL. Fortunately, it was easy to fix.

Background: Layered classes need to be split into a "base" class that gives identity to a particular layered class, plus all the partial definitions that belong to the various layers. The base class refers to the partial classes making up its definition by way of direct superclass links. All of this is set up in the partial-class metaclass. There needs to be a separation of initargs, some of which need to be routed to the base class (such as the name of the class, the defining metaclass and the direct superclass links), and the others need to go to the various partial definitions (such as direct slot definitions, for example).

The problem you uncovered was that this separation into base and partial initargs was hardcoded, and there was no way to configure this in one's own subclasses of partial-class and layered-class.

I have now introdu&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-03-18T16:10:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/332">
    <title>Re: ContextL: allow other keys in (re)initialize-instance methods for metaclasses</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/332</link>
    <description>&lt;pre&gt;Thanks -- I have figured out how to stop the error from occurring, but
I now have a different problem: the initargs for classes other than
layered-class seem to get ignored and do not result in values being
stored in the class' slots.

Here is a simple example.
---------------------
(use-package :closer-mop)

(defclass serializable-class (standard-class)
  ((database :initarg :database)))

(defclass dummy-class (standard-class)
  ())

;; "layered serializable" metaclass
(defclass combined-class1 (contextl:layered-class serializable-class)
  ())

;; another metaclass for comparison. Only difference is it inherits
from dummy-class instead of layered-class.
(defclass combined-class2 (dummy-class serializable-class)
  ())

(defmethod validate-superclass ((class combined-class1) (superclass
standard-class))
  t)

(defmethod validate-superclass ((class combined-class2) (superclass
standard-class))
  t)

;; Trying to create a class that uses serializable-class as its metaclass causes
;; the error "invalid initialis&lt;/pre&gt;</description>
    <dc:creator>Paul Sexton</dc:creator>
    <dc:date>2012-03-16T00:32:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/331">
    <title>Re: ContextL: allow other keysin(re)initialize-instance methods for metaclasses</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/331</link>
    <description>&lt;pre&gt;Hi Paul,

I'm hesitating to make such a change, because it would weaken checking initialization arguments for validity.

Under normal circumstances, it is possible to make more initialization arguments valid for subclasses. See Section 7.1.2 of the HyperSpec. This also applies to metaobject classes. If for some reason this doesn't work for you, I would like to know about it and see whether something needs to be fixed. Please send some example, and some information which CL implementation you are using to test this.

Pascal

P.S.: I'm curious to hear about what you use ContextL for, and what you are adding in your subclasses. If you prefer, please feel free to contact me by private email on this. Thanks.

On 14 Mar 2012, at 21:56, Paul Sexton wrote:


--
Pascal Costanza
&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2012-03-15T18:59:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/330">
    <title>ContextL: allow other keys in(re)initialize-instance methods for metaclasses</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/330</link>
    <description>&lt;pre&gt;Hi

At present the metaclasses in contextl choke during initialisation if
they are passed keys that they do not recognise. This makes it very
difficult to create metaclasses derived from those classes, if the
derived metaclasses need to be passed their own arguments a la
':in-layer'.

Including &amp;amp;allow-other-keys in the argument lists for
(re)initialize-instance in cx-classes-in-layer.lisp and
cx-layer-metaclasses.lisp seems to fix this, and doesn't seem to have
any downsides. Would you consider making this change?

Thanks
Paul
&lt;/pre&gt;</description>
    <dc:creator>Paul Sexton</dc:creator>
    <dc:date>2012-03-14T20:56:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/329">
    <title>ELS 2012, Zadar, Croatia</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/329</link>
    <description>&lt;pre&gt;Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 


European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 


The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based syste&lt;/pre&gt;</description>
    <dc:creator>Marco Antoniotti</dc:creator>
    <dc:date>2012-02-01T13:10:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/328">
    <title>ELS2012 Zadar, Croatia, Call for Papers</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/328</link>
    <description>&lt;pre&gt;
Apologies for the multiple postings...

===========================================================================

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012
http://european-lisp-symposium.org

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We
encourage everyone interested in Lisp to participate.


The main theme of the 2012 European Lisp Conference is
"Interoperabilty: Systems, Libraries, Workflows".  Lisp based and
functional-languages based systems have grown a variety of solutions
to become more and more integrated with the wider world of Information
and Communication Technologies in current use.  There are several
dimensions to the scope of the solutions proposed, ranging from
"embedding" of inte&lt;/pre&gt;</description>
    <dc:creator>Marco Antoniotti</dc:creator>
    <dc:date>2012-01-23T11:58:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/327">
    <title>Re: an interesting contextl backtrace</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/327</link>
    <description>&lt;pre&gt;Hi Attila,

This indeed smells like a race condition, probably caused by a class being redefined in several threads at the same time. I'm not sure if we can declare this a responsibility of the CLOS implementation or not. I see a potential workaround for this, but I would need to invest a bit of time to figure this out. (My idea is to merge the slots that need to be checked if there are already some slots recorded in compute-slots, and check them all in a single execution of finalize-inheritance, which I think should be doable with a portable locking scheme.)

I will probably not be able to do this before the end of the year, though.

A temporary workaround may to define a lock per special-class metaobject, grab the lock at the beginning of compute-slots, and release it at the end of finalize-inheritance. (I don't believe this would be portable, and I'm not sure it eliminates all possible race conditions…)

Sorry if I cannot be of any more immediate help…


Pascal

On 14 Dec 2011, at 10:54, Attila Lendva&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2011-12-16T20:47:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/326">
    <title>an interesting contextl backtrace</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/326</link>
    <description>&lt;pre&gt;Pascal,

take a look at this interesting backtrace (i've cut the irrelevant parts)!

this is triggered on sbcl and contextl head, running a threaded
web-server. the request came from baudispider, which has a habit of
bombing the server with parallel requests.

a quick glance at the contextl code suggests that it's a race
condition, because the code seems to protect itself from the
unboundness of the slot...

any thoughts? shall we send it to sbcl-devel instead?

&lt;/pre&gt;</description>
    <dc:creator>Attila Lendvai</dc:creator>
    <dc:date>2011-12-14T09:54:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/325">
    <title>[ELS 2012] European Lisp Symposium 2012, Zadar,Croatia; call for papers</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/325</link>
    <description>&lt;pre&gt;Apologies for the multiple postings....

================================================================
European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012
http://european-lisp-symposium.org

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We
encourage everyone interested in Lisp to participate.


The main theme of the 2012 European Lisp Conference is
"Interoperabilty: Systems, Libraries, Workflows".  Lisp based and
functional-languages based systems have grown a variety of solutions
to become more and more integrated with the wider world of Information
and Communication Technologies in current use.  There are several
dimensions to the scope of the solutions proposed, ranging from
"embedding" of interpreters in &lt;/pre&gt;</description>
    <dc:creator>Marco Antoniotti</dc:creator>
    <dc:date>2011-11-17T16:03:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/324">
    <title>Re: Invitation to attend workshop on VirtualMachines and Intermediate Languages (VMIL) &lt; at &gt; SPLASH 2011</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/324</link>
    <description>&lt;pre&gt;Hi,

This announcement is not appropriate for this mailing list. Please double-check this more carefully next time.

Thanks,
Pascal

On 16 Sep 2011, at 15:28, Christoph Bockisch wrote:


--
Pascal Costanza
&lt;/pre&gt;</description>
    <dc:creator>Pascal Costanza</dc:creator>
    <dc:date>2011-09-16T21:10:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.closer.devel/323">
    <title>Invitation to attend workshop on Virtual Machines and Intermediate Languages (VMIL) &lt; at &gt; SPLASH 2011</title>
    <link>http://permalink.gmane.org/gmane.lisp.closer.devel/323</link>
    <description>&lt;pre&gt;Dear colleagues,

we would like to invite you to attend the workshop on
Virtual Machines and Intermediate Languages (VMIL 2011),
which will be co-located with SPLASH. Please note that the early
registration deadline for SPLASH is Sept. 23 and that it is required
that you register for the workshop participation.

This workshop is a forum for research in virtual machines
(VM) and intermediate languages (IL). It is dedicated to
identifying programming mechanisms and constructs that are
currently realized as code transformations or implemented in
libraries but should rather be supported at VM and IL level.

Besides the presentation of accepted papers, the workshop features an
invited talk by

Lars Bak, Google

For more details on the format and program of the workshop please see
our homepage:

http://www.cs.iastate.edu/~design/vmil/

We look forward to meeting you at the workshop.

Best regards,
Christoph Bockisch, Hridesh Rajan, Michael Haupt and Robert
Dyer
VMIL 2011 Organizers
&lt;/pre&gt;</description>
    <dc:creator>Christoph Bockisch</dc:creator>
    <dc:date>2011-09-16T13:28:46</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.closer.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.closer.devel</link>
  </textinput>
</rdf:RDF>
