headers
Daniel Barlow | 1 Jul 2004 20:03

Re: SB-THREAD: really discouraged under x86 Linux 2.4.x?

Paolo Amoroso <amoroso <at> mclink.it> writes:

> Daniel Barlow <dan <at> telent.net> writes:
>
>> reasons).  But it's just a web site; it does the same thing day in day
>
> Do you mean with kernel 2.6?

Kernel 2.4 (thought it's a Red Hat box, so might have NPTL support
anyway).  But more importantly, it's running an SBCL too old to know
about futexes.  Some day I will upgrade that

-dan

--

-- 
"please make sure that the person is your friend before you confirm"
Permalink | Reply | 0 comments |
headers
Pascal Costanza | 2 Jul 2004 01:54
Picon

Re: Problem with the MOP

Christophe Rhodes has given me a useful hint via email. Now, I have 
discovered another stumbling block: I override 
compute-discriminating-function in order to modify the actual 
discriminating function, roughly like this:

(defmethod compute-discriminating-function ((gf 
special-generic-function))
    (let ((dfun (call-next-method)))
       (lambda (&rest args)
          (declare (dynamic-extent args))
          (apply dfun <an-additional-argument> args))))

The conditions and the backtraces I get seem to indicate that I 
shouldn't do this, but supposedly rather return dfun unchanged. Is this 
correct, or may there be something else going on?

Pascal

On 26 Jun 2004, at 19:53, Pascal Costanza wrote:

> Hi,
>
> I am currently trying to port AspectL to SBCL. Among other things, I 
> am trying to do the following.
>
> I have defined a class special-generic-function as a subclass of 
> standard-generic-function that is an instance of the metaclass 
> funcallable-special-class. funcallable-special-class is a subclass of 
> special-class-mixin + funcallable-standard-class.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 2 Jul 2004 11:52
Picon
Picon
Favicon

Re: Problem with the MOP

Hi,

Pascal Costanza <costanza <at> web.de> writes:

> Christophe Rhodes has given me a useful hint via email. Now, I have
> discovered another stumbling block: I override
> compute-discriminating-function in order to modify the actual
> discriminating function, roughly like this:
>
> (defmethod compute-discriminating-function ((gf special-generic-function))
>   (let ((dfun (call-next-method)))
>     (lambda (&rest args)
>       (declare (dynamic-extent args))
>       (apply dfun <an-additional-argument> args))))
>
> The conditions and the backtraces I get seem to indicate that I
> shouldn't do this, but supposedly rather return dfun unchanged. Is
> this correct, or may there be something else going on?

In general, sadly, questions that are formulated like this about the
MOP will tend to be answered by "I don't know".  The MOP specification
is, well, not terribly tight; furthermore, the specification and the
implementation written by the same people diverge in behaviour... and
(with one possible exception, but I don't think he reads this list,
and in any case he's been inactive for quite a while) the cmucl/sbcl
community contains no MOP experts.  (For more evidence of this, see my
replies to Edwin M Westbrook of yesterday on sbcl-devel).

So, that said, what would greatly assist in this kind of discussion is
a slightly more precise problem description.  Since we number no
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pascal Costanza | 3 Jul 2004 01:56
Picon

Re: Problem with the MOP


On 2 Jul 2004, at 11:52, Christophe Rhodes wrote:

> In general, sadly, questions that are formulated like this about the
> MOP will tend to be answered by "I don't know".  The MOP specification
> is, well, not terribly tight; furthermore, the specification and the
> implementation written by the same people diverge in behaviour... and
> (with one possible exception, but I don't think he reads this list,
> and in any case he's been inactive for quite a while) the cmucl/sbcl
> community contains no MOP experts.  (For more evidence of this, see my
> replies to Edwin M Westbrook of yesterday on sbcl-devel).

OK, sorry about that.

> So, that said, what would greatly assist in this kind of discussion is
> a slightly more precise problem description.

OK, I have hacked around a bit, and I think I can provide a better 
question. In fact, I think I have detected a bug. Here is the code:

(defmethod compute-discriminating-function
            ((gf special-generic-function))
   (let ((dfun (call-next-method))
	(dynamic-scope-prototype (class-prototype (dynamic-scope gf))))
     (lambda (&rest args)
       (declare (dynamic-extent args))
       (apply dfun dynamic-scope-prototype args))))

I have checked the MOP specs, and this should work. (The MOP explicitly 
states that one can override compute-discriminating-function, which
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marco Baringer | 5 Jul 2004 20:02
Picon

specializing methods on conditions


this snippet is either a relativly minor bug in sbcl or a major bug
in my understanding of CLOS:

CL-USER> (software-type)
"Darwin"
CL-USER> (software-version)
"6.8"
CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"0.8.12"
CL-USER> (defvar *j* 0)
*J*
CL-USER> (define-condition c () ((a-slot :initform (incf *j*))))
C
CL-USER> (defmethod a-method ((x c)) x)
STYLE-WARNING: implicitly creating new generic function A-METHOD
#<STANDARD-METHOD A-METHOD (C) {485D1051}>
CL-USER> *j*
1
CL-USER> 

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nikodemus Siivola | 5 Jul 2004 20:18
Picon
Picon

Re: specializing methods on conditions

On Mon, 5 Jul 2004, Marco Baringer wrote:

> this snippet is either a relativly minor bug in sbcl or a major bug
> in my understanding of CLOS:

This is due to SHARED-INITIALIZE :AFTER CONDITION setting the prototype
slot of the class metaobject, and constructing the prototype with
MAKE-CONDITION. I'll see what can be done.

Nice to have simple CLOS bugs. ;-)

Cheers,

 -- Nikodemus                   "Not as clumsy or random as a C++ or Java.
                             An elegant weapon for a more civilized time."

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 6 Jul 2004 00:02
Picon
Picon

Re: specializing methods on conditions

On Mon, 5 Jul 2004, Marco Baringer wrote:

> this snippet is either a relativly minor bug in sbcl or a major bug
> in my understanding of CLOS:

> CL-USER> (defvar *j* 0)
> *J*
> CL-USER> (define-condition c () ((a-slot :initform (incf *j*))))
> C
> CL-USER> (defmethod a-method ((x c)) x)
> STYLE-WARNING: implicitly creating new generic function A-METHOD
> #<STANDARD-METHOD A-METHOD (C) {485D1051}>
> CL-USER> *j*
> 1

Fixed in SBCL 0.8.12.24. Thanks for the report.

Cheers,

 -- Nikodemus                   "Not as clumsy or random as a C++ or Java.
                             An elegant weapon for a more civilized time."

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 0 comments |
headers
smishra | 13 Jul 2004 08:57
Favicon

A package named mop?

Hi,

Unlike cmucl (and many other lisps), sbcl doesn't seem to define a 
package named mop. Is this deliberate? It's easy enough to add a 
rename-package to my code, but it is a bit of an annoyance.

Sunil

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 13 Jul 2004 09:16
Picon
Picon
Favicon

Re: A package named mop?

smishra <at> speakeasy.net writes:

> Unlike cmucl (and many other lisps), sbcl doesn't seem to define a
> package named mop. Is this deliberate? It's easy enough to add a
> rename-package to my code, but it is a bit of an annoyance.

It's moderately intentional, at least from my part.  The reasoning is
that a MOP, unlike the standard COMMON-LISP package, will vary in its
behaviour between implementations: simply providing the same package
name is not sufficient to bless a MOP-using system with portability.
(And the MOP from The Art of the Metaobject Protocol is only one of
many possible MOPs for CLOS...)

If your use of the MOP is of the de-facto portable operators, the way
I would recommend using the MOP package is something like
  (defpackage "FOO"
    (:use "CL" #+sbcl "SB-MOP" #+cmu "MOP" #+allegro "ACLMOP"))
or maybe
  (defpackage "FOO"
    (:use "CL")
    #+sbcl (:import-from "SB-MOP" "SLOT-VALUE-USING-CLASS")
    #+cmu  (:import-from "MOP" "SLOT-VALUE-USING-CLASS"))

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
(Continue reading)

Permalink | Reply | 2 comments |
headers
smishra | 13 Jul 2004 17:10
Favicon

Re: A package named mop?

I realize that MOP is not standard. And I realize there are many 
possible MOP's. However, the MOP in AMOP has been the primary source of 
MOP's in all the Lisp's I've seen. The only exception had been MCL, but 
that was in MCL 3.x days. All lisps have a package named MOP, but the 
name is just a nickname. The reason for preferring a nickname over a 
use-package or an import is that I want to keep explicit all the 
non-standard stuff my code uses. I don't mind special casing sbcl and 
adding a nickname to sb-mop, but seems like this is splitting hairs, at 
the cost of making sbcl different from other lisps.

Sunil

Christophe Rhodes wrote:
> smishra <at> speakeasy.net writes:
> 
> 
>>Unlike cmucl (and many other lisps), sbcl doesn't seem to define a
>>package named mop. Is this deliberate? It's easy enough to add a
>>rename-package to my code, but it is a bit of an annoyance.
> 
> 
> It's moderately intentional, at least from my part.  The reasoning is
> that a MOP, unlike the standard COMMON-LISP package, will vary in its
> behaviour between implementations: simply providing the same package
> name is not sufficient to bless a MOP-using system with portability.
> (And the MOP from The Art of the Metaobject Protocol is only one of
> many possible MOPs for CLOS...)
> 
> If your use of the MOP is of the de-facto portable operators, the way
> I would recommend using the MOP package is something like
(Continue reading)

Permalink | Reply | 1 comment |

Gmane