summaryrefslogtreecommitdiff
path: root/JOURNAL
diff options
context:
space:
mode:
authorMatthias Benkard <code@mail.matthias.benkard.de>2008-06-10 15:29:45 +0200
committerMatthias Benkard <code@mail.matthias.benkard.de>2008-06-10 15:29:45 +0200
commit15b5abf73cfcd3dc898b27d010a343076dec7bdf (patch)
tree5bc134c9ac5b9c15f5721d4d8f6b8a4b2f94e6f0 /JOURNAL
parentaa8645cdf28eb7b13d2813f5f0fe014df4d7b4b8 (diff)
JOURNAL: New entry.
darcs-hash:9ec170f8ce4942be47d4bfbbb7b7636ad935f865
Diffstat (limited to 'JOURNAL')
-rw-r--r--JOURNAL35
1 files changed, 34 insertions, 1 deletions
diff --git a/JOURNAL b/JOURNAL
index 06b11a4..8248fdd 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -3,7 +3,7 @@
#title Objective-CL Development Diary
#desc Random news from the Objective-CL lab
-; Time-stamp: <2008-03-23 14:10:56 mulk>
+; Time-stamp: <2008-06-10 15:27:51 mulk>
;
; C-c i t insert-time-stamp
; C-c C-t muse-project-publish-this-file
@@ -18,6 +18,39 @@ Context: [[http://matthias.benkard.de/objective-cl][The Objective-CL Project]].
----
+* 2008-03-26, 15:48:01 CET
+
+** Bundles And Nib Files
+
+Currently, there is no way of loading nib files without knowing their
+exact location on the host filesystem. This is unacceptable but a bit
+hard to solve.
+
+Every Cocoa application is normally located in its own application
+bundle, a directory containing resources such as nib files, among
+others. In contrast, simply loading Objective-CL into your Lisp image
+does not cause any reasonable bundle path to be registered, as the
+bundle path is determined from the running executable's name, which
+usually belongs to your Lisp system.
+
+There are two approaches to handle this situation:
+
+ 1. Create application bundles out of Objective-CL-based applications.
+ This may be done either from Lisp itself or by a shell script.
+
+ 2. Manually register the bundle path with the runtime somehow.
+
+The disadvantage of option 1 is that it's no good for interactive
+development, so option 2 is more or less needed additionally either way.
+
+Either approach might need to defer loading =libobjcl= until after the
+application's launch. This in turn would mean that Objective-CL would
+have to be split into two parts: a loader and the rest. The loader
+might have to provide =notinline=-declared stubs of all of Objective-CL's
+public functions as well as all public macro definitions. This would
+get ugly fast... An alternative is needed.
+
+
* 2008-03-21, 21:17:36 CET
** A Self-Evaluating Form