Opened 12 years ago

Closed 12 years ago

#34 closed defect (fixed)

Standalone IDE Broken in 1.1-pre-070722 (DarwinX8664) with Leopard 9A499

Reported by: alms Owned by: gb
Priority: major Milestone:
Component: IDE Version: 1.1
Keywords: Cc:

Description

The standalone Cocoa IDE created with (REQUIRE "COCOA-APPLICATION") doesn't work. When you double-click on the icon it launches and the menubar comes up, but no Listener. The console output is attached as a document (hopefully).

Attachments (2)

Console Messages.log (63.3 KB) - added by alms 12 years ago.
Console Messages.2.log (63.3 KB) - added by alms 12 years ago.

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by alms

Changed 12 years ago by alms

comment:1 Changed 12 years ago by gb

  • Status changed from new to assigned

The backtrace helps (thanks); will fix.

comment:2 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

This should be fixed in SVN now, though I'd thought that the problem was fixed a while ago.

For the record (not very interesting):

The bridge distinguishes between "declared" and "private" ObjC classes; a "declared" class is one that's ... declared in the interfaces, while a private class exists in the runtime of a particular session. All private classes are subclasses of some declared class (even if that's only NSObject).

The exact set of "private" classes in the world can change from dot release to dot release. It can also change within a session (some private classes are defined lazily as UI components are first used.) We don't generally want CLOS to know much about them and we don't want that knowledge to persist across sessions: as far as CLOS is concerned, the set of ObjC classes in the world is exactly equivalent to the set of classes described in the interfaces we're using. (An image built to run on Tiger should run on any dot release of Tiger and should run on Leopard as long as Leopard is a proper superset of Tiger.)

We -do- need to be able to recognize instances of all ObjC classes as such; if we discover that something's an instance of a private ObjC class, we claim that it's actually an instance of the innermost declared superclass of that private class. (So something that's actually an instance of a NSGodAwfulInternalString class is treated as if it was an NSString.)

When we try to determine whether an arbitrary pointer is in fact an ObjC class or an instance of some ObjC class and conclude that it isn't, we ask the runtime whether any new classes have been defined behind our back. If so, we try to learn what we can about newly introduced classes - partitioning them into "declared" and "private" - and look at the pointer again.

When that code was first written, it did the partitioning step by consulting the interface database. That step generally shouldn't be necessary: we should already have processed every class declaration in the database when the image was built, so we aren't going to learn anything new about whether a declaration exists for a class by trying to look up the class in the database. That redundant step leads to an error if it happens before the system has an accurate idea of where the database files are (adding injury to insult.)

In the case where this happened under a new OS release ... the act of initializing the preferences pane and defaults database during startup introduced some new (private) classes to the runtime, and some operation introduced an instance of one of those private classes and forced the bridge to partition the new classes into the "private" and "declared" sets; that partitioning code tried to hit the database, whose path is presumably stored in the defaults database that we're trying to initialize.

comment:3 Changed 12 years ago by gb

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hadn't actually checked in objc-bridge/objc-runtime.lisp when I claimed that this was fixed.

comment:4 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from reopened to closed

I claim that this is actually fixed by changeset:7005 .

Note: See TracTickets for help on using tickets.