From 2b9099f7de3b8e17f13bf501e6acc73857e463e8 Mon Sep 17 00:00:00 2001 From: Matthias Benkard Date: Tue, 18 Mar 2008 21:43:59 +0100 Subject: JOURNAL: Improve formatting. darcs-hash:9660ca7bca703286dc716801740d035d8ee4d8e5 --- JOURNAL | 62 ++++++++++++++++++++++++++++++++------------------------------ 1 file 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 +*** LispWorks 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 PyObjC): - =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 PyObjC 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 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. 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 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. * 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 +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. 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 -- cgit v1.2.3