summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--JOURNAL62
1 files changed, 32 insertions, 30 deletions
diff --git a/JOURNAL b/JOURNAL
index e94a28c..81398ef 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -3,7 +3,7 @@
#title Objective-CL Development Diary
#desc News from the Objective-CL lab
-; Time-stamp: <2008-03-18 17:50:00 mulk>
+; Time-stamp: <2008-03-18 18:00:52 mulk>
;
; C-c i t insert-time-stamp
; C-c C-t muse-project-publish-this-file
@@ -169,7 +169,7 @@ I don't have the slightest idea what that could mean. A bug in CMUCL's
hash table code?
-*** LispWorks Personal 5.0.1
+*** <verbatim>LispWorks</verbatim> Personal 5.0.1
Not timed yet. Will do that someday.
@@ -237,26 +237,27 @@ For the GNU runtime (from JIGS, the Java Interface to GNUstep):
- =JIGS/ObjcRuntimeUtilities.h=
- =JIGS/ObjcRuntimeUtilities2.m=
-For the NeXT runtime (from PyObjC):
+For the NeXT runtime (from <verbatim>PyObjC</verbatim>):
- =PyObjC/pyobjc-compat.h=
- =PyObjC/objc-runtime-compat.h=
- =PyObjC/objc-runtime-compat.m=
-Both the JIGS and PyObjC codebases are impressively modular. Those guys
-know what they're doing.
+Both the JIGS and <verbatim>PyObjC</verbatim> codebases are impressively
+modular. Those guys know what they're doing.
* 2008-01-27, 12:55:06 CET
Objective-CL now includes its own version of libffi, imported from an
-older version of PyObjC. (The current version only supports x86 and
-PowerPC.) Interestingly, according to the Web, Mac OS X 10.5 includes
-its own version of libffi. This is really good news! We can finally
-rest assured that Objective-CL does not break on Mac OS X because of
-libffi bitrot anytime soon. In order to take advantage of this new
-state of the world, the build system has been changed so as to only
-compile our own version of libffi if we can't find any on the system.
+older version of <verbatim>PyObjC</verbatim>. (The current version only
+supports x86 and PowerPC.) Interestingly, according to the Web, Mac OS
+X 10.5 includes its own version of libffi. This is really good news!
+We can finally rest assured that Objective-CL does not break on Mac OS X
+because of libffi bitrot anytime soon. In order to take advantage of
+this new state of the world, the build system has been changed so as to
+only compile our own version of libffi if we can't find any on the
+system.
The downside? We now depend on autoconf. I don't consider this a
problem, though.
@@ -298,16 +299,17 @@ http://svn.gna.org/svn/gnustep/libs/base/trunk/Headers/Additions/GNUstepBase/obj
** `char' Does Actually Indicate a Char, Sometimes
The latest changes made the test cases fail on GNUstep/x86, which either
-means that the PyObjC code is wrong, or the GNU runtime has very weird
-calling conventions that use =ints= as wrappers for =chars= or something.
-Anyway, I have reverted the changes for GNUstep and left them in place
-for Mac OS X (but note that I left the PyObjC code as it is, which means
-that libffi is still directed to treats chars as ints). As a result,
-both NeXT/PowerPC and GNUstep/x86 work for now, but I'm uncertain about
-the status of other architectures as well as calling methods with chars
-and shorts as arguments, which I've got no test cases for. I'm not
-confident that either GNUstep/PowerPC/SPARC/whatever or NeXT/x86 work
-the way my code expects them to.
+means that the <verbatim>PyObjC</verbatim> code is wrong, or the GNU
+runtime has very weird calling conventions that use =ints= as wrappers for
+=chars= or something. Anyway, I have reverted the changes for GNUstep and
+left them in place for Mac OS X (but note that I left the
+<verbatim>PyObjC</verbatim> code as it is, which means that libffi is
+still directed to treats chars as ints). As a result, both NeXT/PowerPC
+and GNUstep/x86 work for now, but I'm uncertain about the status of
+other architectures as well as calling methods with chars and shorts as
+arguments, which I've got no test cases for. I'm not confident that
+either GNUstep/PowerPC/SPARC/whatever or NeXT/x86 work the way my code
+expects them to.
* 2007-10-04, 16:52:32 CEST
@@ -316,14 +318,14 @@ the way my code expects them to.
There's a good chance that I've figured out what to do about the
=char/int= mess. As it turns out, it isn't even limited to =chars=, as
-=shorts= are affected, too. According to the code I took from PyObjC,
-specifically the typespec conversion functions in =libffi_support.m=, both
-GNUstep and NeXT/PowerPC treat =chars= and =shorts= as =ints=. The only
-platform that isn't brain-damaged in this way seems to be NeXT/x86. Or
-maybe it's even more brain-damaged, as it treats =shorts= and =chars=
-normally when they are used as arguments, but as =ints= when they're used
-as return values! At least GNUstep and NeXT/PowerPC are brain-damaged
-in a *consistent* manner.
+=shorts= are affected, too. According to the code I took from
+<verbatim>PyObjC</verbatim>, specifically the typespec conversion
+functions in =libffi_support.m=, both GNUstep and NeXT/PowerPC treat =chars=
+and =shorts= as =ints=. The only platform that isn't brain-damaged in this
+way seems to be NeXT/x86. Or maybe it's even more brain-damaged, as it
+treats =shorts= and =chars= normally when they are used as arguments, but as
+=ints= when they're used as return values! At least GNUstep and
+NeXT/PowerPC are brain-damaged in a *consistent* manner.
I figure the reason I never saw this problem in GNUstep is probably
endianness. The little-endian x86 lets you treat pointers to =ints= as