[Openmcl-devel] Re: problem building bosco on 0.14-031220
hamlink at comcast.net
Mon Dec 22 09:48:06 PST 2003
Slightly OT, but I think Allegro also enforces slot type declarations.
I haven't used it in a while to know for sure but I seem to recall it
getting in my way once with ":initform nil"s matched up with ":type
float"s or something like that.
On Monday, December 22, 2003, at 08:20 AM, Gary Byers wrote:
> On Mon, 22 Dec 2003, Raffael Cavallaro wrote:
>> On Dec 22, 2003, at 9:35 AM, Gary Byers wrote:
>>> Mikel Evins has been working on a different approach to Cocoa
>>> application development: in his "Bosco" system (see http://evins.net)
>>> he creates a skeletal bundle, copies a Cocoa-aware lisp image into
>>> that bundle, then incrementally turns the prototype application into
>>> something ... less prototypical. There may be some tradeoffs
>>> involved, but his approach certainly avoids the "pretend I'm over
>>> *DEFAULT-BUNDLE-EXECUTABLE-PATH* nonsense ...
>> I'm not sure if this is something that you, Gary, or Mikel would be
>> best equipped to deal with, but I've run into the following error when
>> trying to build bosco under OpenMCL version 0.14-031220:
>> raffaelc$ openmcl -l bosco.asd -e "(make)"
>>> Error in process listener(1): value #:BOSCO is not of the expected
>> type STRING.
>>> While executing: CCL::%SHARED-INITIALIZE
>>> Type :POP to abort.
>> Type :? for other options.
>> 1 >
> This was a minor but long-standing bug in asdf: a slot in an asdf class
> is declared to have a :TYPE of STRING, but the DEFSYSTEM macro (and
> uses of it) initialize this slot to a SYMBOL. OpenMCL 0.14-031220
> to be the first CL implementation that bothers to check this sort of
> A new version of asdf was released a few days ago.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel