JOURNAL: Improve formatting.

darcs-hash:9660ca7bca703286dc716801740d035d8ee4d8e5

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