Something's wrong with mudballs' closer-mop
Robin Lee Powell
I'm scared to touch this myself, because MOP is way beyond my ken,
but there seems to be something wrong with closer-mop on
mudballs+sbcl, because it doesn't seem to have subclassp ?
-Robin
$ rlwrap sbcl
This is SBCL 1.0.25.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
STYLE-WARNING: Implicitly creating new generic function COMPONENT-SUPPORTED-P.
STYLE-WARNING: Implicitly creating new generic function CREATE-REQUIREMENT.
STYLE-WARNING: Implicitly creating new generic function COMPONENT-REQUIREMENTS.
STYLE-WARNING: Implicitly creating new generic function LOAD-REQUIREMENT.
STYLE-WARNING:
Implicitly creating new generic function PROCESS-PARENTS-DEPENDENCIES.
STYLE-WARNING: Implicitly creating new generic function IMMEDIATE-DEPENDENCIES.
STYLE-WARNING:
Implicitly creating new generic function NON-OBVIOUS-DEPENDENCIES.
STYLE-WARNING: Implicitly creating new generic function INSTALLABLEP.
STYLE-WARNING: Implicitly creating new generic function ENSURE-EXISTENCE-OF.
STYLE-WARNING: Implicitly creating new generic function RESET-INSTANCE.
STYLE-WARNING:
Implicitly creating new generic function MAYBE-LOAD-CONDUIT-SYSTEMS.
STYLE-WARNING: Implicitly creating new generic function CONDUIT-SYSTEMS-OF.
STYLE-WARNING: Implicitly creating new generic function APPROPRIATE-NAME.
STYLE-WARNING: Implicitly creating new generic function CONFIG-FILE-OF.
* (mb:load :closer-mop)
WARNING: Redefining MUDBALLS version 0.3.2.
#<SYSDEF-USER::SERIAL-SYSTEM :CLOSER-MOP 0.50 {1003694E01}>
* closer-mop:subclassp
debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread #<THREAD "initial thread" RUNNING {10036A21C1}>:
SB-INT:SIMPLE-READER-PACKAGE-ERROR on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000205331}>:
Symbol "SUBCLASSP" not found in the CLOSER-MOP package.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Use symbol anyway.
1: [ABORT ] Exit debugger, returning to top level.
(SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000205331}> #\c)
0]
* closer-mop::subclassp
debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "initial thread" RUNNING {10036A21C1}>:
The variable CLOSER-MOP::SUBCLASSP is unbound.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-INT:SIMPLE-EVAL-IN-LEXENV CLOSER-MOP::SUBCLASSP #<NULL-LEXENV>)
0]
* #'closer-mop::subclassp
debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD "initial thread" RUNNING {10036A21C1}>:
The function CLOSER-MOP::SUBCLASSP is undefined.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-INT:SIMPLE-EVAL-IN-LEXENV #'CLOSER-MOP::SUBCLASSP #<NULL-LEXENV>)
0]
* #'closer-mop:subclassp
debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread #<THREAD "initial thread" RUNNING {10036A21C1}>:
SB-INT:SIMPLE-READER-PACKAGE-ERROR on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000205331}>:
The symbol "SUBCLASSP" is not external in the CLOSER-MOP package.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Use symbol anyway.
1: [ABORT ] Exit debugger, returning to top level.
(SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000205331}> #\c)
0]
*
Leslie P. Polzer
> I'm scared to touch this myself, because MOP is way beyond my ken,
You don't really need MOP knowledge here. :)
> but there seems to be something wrong with closer-mop on
> mudballs+sbcl, because it doesn't seem to have subclassp ?
I think it's a pretty recent introduction so maybe Mudballs
still refers to an old c2mop.
Robin Lee Powell
Ah, looks like. Thanks.
-Robin
Sean Ross
Yes, subclassp was added in c2mop version 0.55, I have upgraded closer-
mop to 0.55 which you can now update to.
Cheers,
Sean.
Robin Lee Powell
Thanks. I've done (mb:[update|upgrade]) and (mb:[clean|install] closer-mop),
and I still get the following weirdness when I run (mb:document :weblocks):
; file: /home/rlpowell/programming/mudballs/systems/document-action/0.1.11/action.lisp
; in:
; DEFMETHOD SYSDEF.DOCUMENT-ACTION::GENERATE-SYSTEM-DOC (MB.SYSDEF:SYSTEM T)
; (SYSDEF.DOCUMENT-ACTION::RENDER-SYSTEM-PAGE MB.SYSDEF:SYSTEM
; SYSDEF.DOCUMENT-ACTION::PACKAGES)
;
; caught STYLE-WARNING:
; undefined function: SYSDEF.DOCUMENT-ACTION::RENDER-SYSTEM-PAGE
;
; caught STYLE-WARNING:
; These functions are undefined:
; SYSDEF.DOCUMENT-ACTION::DOC-HINT-PATH
; SYSDEF.DOCUMENT-ACTION::METHOD-SIGNATURE
; SYSDEF.DOCUMENT-ACTION::PATH-FOR
; SYSDEF.DOCUMENT-ACTION::RENDER-EXTRA-INFO
; SYSDEF.DOCUMENT-ACTION::RENDER-SYSTEM-PAGE
;
; compilation unit finished
; caught 1 WARNING condition
; caught 10 STYLE-WARNING conditions
STYLE-WARNING: Implicitly creating new generic function PATH-FOR.
STYLE-WARNING: Implicitly creating new generic function DOC-HINT-PATH.
STYLE-WARNING: Implicitly creating new generic function RENDER-EXTRA-INFO.
STYLE-WARNING: Implicitly creating new generic function METHOD-SIGNATURE.
STYLE-WARNING: Implicitly creating new generic function RENDER-SYSTEM-PAGE.
STYLE-WARNING: redefining SUBCLASSP in DEFGENERIC
debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "initial thread" RUNNING {10036A32F1}>:
SUBCLASSP already names an ordinary function or a macro.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE ] Replace the function binding
1: [COMPILE-SYSTEM] Compile the component and retry.
2: [LOAD-SOURCE ] Load source file instead of fasl.
3: [RETRY ] Retry LOAD-ACTION on moptilities.lisp.
4: [IGNORE ] Ignore LOAD-ACTION on moptilities.lisp.
5: Retry LOAD-ACTION on "dev" 0.0.1.
6: Ignore LOAD-ACTION on "dev" 0.0.1.
7: Retry LOAD-ACTION on :MOPTILITIES 0.3.6.
8: Ignore LOAD-ACTION on :MOPTILITIES 0.3.6.
9: Retry COMPILE-ACTION on :METATILITIES 0.6.18.
10: Ignore COMPILE-ACTION on :METATILITIES 0.6.18.
11: Retry LOAD-ACTION on :METATILITIES 0.6.18.
12: Ignore LOAD-ACTION on :METATILITIES 0.6.18.
13: Retry COMPILE-ACTION on :WEBLOCKS 0.8.3.
14: Ignore COMPILE-ACTION on :WEBLOCKS 0.8.3.
15: Retry LOAD-ACTION on :WEBLOCKS 0.8.3.
16: Ignore LOAD-ACTION on :WEBLOCKS 0.8.3.
17: Retry DOCUMENT-ACTION on :WEBLOCKS 0.8.3.
18: Ignore DOCUMENT-ACTION on :WEBLOCKS 0.8.3.
19: [ABORT ] Exit debugger, returning to top level.
(ENSURE-GENERIC-FUNCTION
SUBCLASSP
:LAMBDA-LIST
(CHILD PARENT)
:DEFINITION-SOURCE
#S(SB-C:DEFINITION-SOURCE-LOCATION
:NAMESTRING "/home/rlpowell/programming/mudballs/systems/moptilities/0.3.6/dev/moptilities.lisp"
:TOPLEVEL-FORM-NUMBER 6
:PLIST NIL)
:DOCUMENTATION
"Returns t if child and parent both specifies classes and child is a subclass of the parent.")
0]
Sean Ross
On 27 Apr 2009, at 21:34, Robin Lee Powell wrote:
>
> On Mon, Apr 27, 2009 at 10:00:44AM +0100, Sean Ross wrote:
>>
>>
>> On 25 Apr 2009, at 20:57, Robin Lee Powell wrote:
>>
>>>
>>> On Sat, Apr 25, 2009 at 09:54:34AM +0200, Leslie P. Polzer
>>> wrote:
>>>>
>>>>
>>>>> I'm scared to touch this myself, because MOP is way beyond my
>>>>> ken,
>>>>
>>>> You don't really need MOP knowledge here. :)
>>>>
>>>>
>>>>> but there seems to be something wrong with closer-mop on
>>>>> mudballs+sbcl, because it doesn't seem to have subclassp ?
>>>>
>>>> I think it's a pretty recent introduction so maybe Mudballs
>>>> still refers to an old c2mop.
>>>
>>> Ah, looks like. Thanks.
>>>
>>
>>
>> Yes, subclassp was added in c2mop version 0.55, I have upgraded
>> closer- mop to 0.55 which you can now update to.
>
> Thanks. I've done (mb:[update|upgrade]) and (mb:[clean|install]
> closer-mop),
> and I still get the following weirdness when I run
> (mb:document :weblocks):
This was caused by a moptilities dependency on a particular version of
closer-mop.
I've uploaded a new version of moptilities and updated the system
definitions.
An (mb:upgrade) will sort this out.
- sean.
Robin Lee Powell
Great stuff! Thanks!
This is actually my one really large concern about mudballs: having
a single person, even one as amazingly helpful as you've been so
far, as a bottleneck. I've just seen that fail too many times.
-Robin
--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" See http://shrunklink.com/cdiz
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Sean Ross
On 27 Apr 2009, at 22:34, Robin Lee Powell wrote:
>
> On Mon, Apr 27, 2009 at 10:28:22PM +0100, Sean Ross wrote:
>>
>> On 27 Apr 2009, at 21:34, Robin Lee Powell wrote:
>>
>>>
>>> Thanks. I've done (mb:[update|upgrade]) and (mb:[clean|install]
>>> closer-mop), and I still get the following weirdness when I run
>>> (mb:document :weblocks):
>>
>>
>> This was caused by a moptilities dependency on a particular
>> version of closer-mop. I've uploaded a new version of moptilities
>> and updated the system definitions.
>>
>> An (mb:upgrade) will sort this out.
>
> Great stuff! Thanks!
>
> This is actually my one really large concern about mudballs: having
> a single person, even one as amazingly helpful as you've been so
> far, as a bottleneck. I've just seen that fail too many times.
Indeed, that is the largest issue at the moment and what I am
currently focusing on, with only myself
able to update these systems it's a catastrophe if I'm somehow unable
to continue in these tasks.
The good news is that most of these problems will go away once the
website has these system upload and creation facilities online.
- sean