Stupidity in CMUCL prettyprinter

Robert Maas, http://tinyurl.com/uh3t

unread,

Apr 25, 2008, 9:11:48 PM4/25/08

to

CMU Common Lisp 18b prints like this (part of larger form, the rest prints fine):
(MULTIPLE-VALUE-SETQ (COMPLOADFLG DATE FREQRATS)
(INSYM+FUNC+DIRSPEC+FILNAM+METHOD+OUTSYM-MAY-LOAD-OR-COMPUTE INSYM
#'WDHISTS-TO-
234GRAM-FREQRATS-MERGE
"/home/users/
rem/public_html/NewPub/ProxHash/"
"trans-skills
-freqrats.txt"
:BIGREAD
OUTSYM))

IMO a better way to prettyprint the same form would be:
(MULTIPLE-VALUE-SETQ (COMPLOADFLG DATE FREQRATS)
(INSYM+FUNC+DIRSPEC+FILNAM+METHOD+OUTSYM-MAY-LOAD-OR-COMPUTE INSYM
#'WDHISTS-TO-234GRAM-FREQRATS-MERGE
"/home/users/rem/public_html/NewPub/ProxHash/"
"trans-skills-freqrats.txt"
:BIGREAD OUTSYM))

Many years ago, when I was programming in PSL (Portable Standard
Lisp), I made an attempt to write a really good prettyprinter:
PP.LSP (REM033 85ZW) WorkPSL: Attempt to make a decent pretty-printer, using
; standard dynamic-programming method of saving all methods and passing them
; up for possible use at higher level

Another prettyprinter, not anything I wrote, wasn't so good:
PRETTY.PSL (DEL REM033 86Z87W) (Gone <90.8.11)
PRETTY.PSL (REM005-Q7) Same
PRETTY.PSL (DEL 89963R-3) "Deleted 1990.4.11"
% PRETTY.PSL: WorkPSL: Another prettyprinter, totally non-prettyprinted itself

I think this was the SL (Standard Lisp) version of that same not-mine pp:
PRETTY.SL (REM033 85ZW) WorkSL: Prettyprinter

I don't have access to SL or PSL now, so I can't just load the form
into SL or PSL and try using both the old not-mine and my own
prettyprinter to see how they compare. Would anybody be
sufficiently interested in comparing the prettyprinter I wrote to
the standard versions, so that it would be worth my effort to
translate my code to Common Lisp? Or does somebody else have a good
version of prettyprinter in Common Lisp that does a better version
than what's in CMUCL?

Message has been deleted

Robert Maas, http://tinyurl.com/uh3t

unread,

May 1, 2008, 2:31:31 AM5/1/08

to

> | CMU Common Lisp 18b prints like this (part of larger form, the rest
> | prints fine):

> From: Madhu <enom...@meer.net>
> I don't have a copy of 18b, or the enclosing context but since
> 19c at least
> * (pprint '(MULTIPLE-VALUE-SETQ (COMPLOADFLG DATE FREQRATS)

> (INSYM+FUNC+DIRSPEC+FILNAM+METHOD+OUTSYM-MAY-LOAD-OR-COMPUTE INSYM
> #'WDHISTS-TO-234GRAM-FREQRATS-MERGE
> "/home/users/rem/public_html/NewPub/ProxHash/"
> "trans-skills-freqrats.txt"

> :BIGREAD OUTSYM)))
> Does give:

> [SNIP]

> | Or does somebody else have a good version of prettyprinter in Common
> | Lisp that does a better version than what's in CMUCL?

> The current CMUCL pre-release (19e) is available at
> <http://common-lisp.net/project/cmucl/downloads/release/19e/pre-release/>
> This seems to do what you want.

I have essentially no available disk space on my personal account,
so I wouldn't be able to download and install 19e here.

> IIRC CMUCL 18b (1998) is around 10 years old.

That sounds wrong. Evidence: After I moved to this ISP in mid 2000,
when I first discovered that this ISP had CMUCL in late 2000 and
started my first serious use of it for a CGI demo (ported from
Macintosh Allegro CL) in 2001.Jan-Mar, and started my first more
major use of it 2001.Sep, and started my anti-spam software
2001.Nov, I discovered several bugs somewhere along that sequence
(including SLEEP not sleeping at all if given floating-point value
greater than 1, still not fixed in the current version here, and
the tilde-newline bug I mention just below as now fixed).
A couple years later I discovered that one of the bugs had been
fixed, namely the failure to recognize the tilde-newline control in
format strings (in format, error and cerror). Looking at the
write-date for CMUCL:
576 -rwxr-xr-x 1 root wheel 579696 Mar 11 2001 /usr/local/bin/lisp*
it seems that CMUCL 18b was installed at that time. That would make
it only just over seven years old currently. Is it possible that my
ISP didn't install 18b until it was already appx. three years old,
but at a time when there was no more recent stable version
available? Perhaps I was the first person on this ISP to seriously
use it, so the admin saw no reason to keep updating it before I
started using it near the start of 2001? That's the only way I can
think to reconcile your 10-yr estimate with download only just over
7 years ago.

> Reporting bugs in that version does not help anyone.

Except that some nice person might be able to confirm whether
there's a newer stable version that has the bugs fixed, which might
be good reason for the sysadmin to download that newer version.

> You would be better adviced to ask your provider to install a
> released CMUCL version.(*)

Unfortunately 19e is still pre-release according to what you wrote
earlier. There are several hundred users on this ISP, and I
wouldn't want to ask the admin to install a version that is only in
beta release and then discover it has some horrible bug nobody
noticed until after it was installed here, and then all my software
breaks and I have ask the admin to roll back to 18b. I'd rather
wait until there's a stable new version that somebody on the
newsgroup has confirmed has the various bugs fixed.

Now it would seem to me that there must be several stable versions
between 18b and 19e, so maybe I should ask the admin to install one
of them. But if there's a 19e in beta now it *must* mean that
there's some bug in previous versions in the 19* series, and I
really don't want to ask my admin to install a version with a known
bug. Until 19e is stable, I am not comfortable asking my ISP's
admin to download *any* version, old with known bug nor current beta.

I tried doing a Google search to find info about CMUCL 19e beta,
but couldn't find anything I could make sense of. Does anybody have
an estimate when 19e will be released? Is there any way to get
notified by e-mail when it's released?

Raymond Toy (RT/EUS)

unread,

May 1, 2008, 9:40:08 AM5/1/08

to

>>>>> "Robert" == Robert Maas <lisp1.3....@SpamGourmet.Com> writes:

Robert> Now it would seem to me that there must be several stable versions
Robert> between 18b and 19e, so maybe I should ask the admin to install one

There is 18c, 18d, 18e, 19a, 19b, 19c, 19d. They were all "stable",
basically meaning that someone thought that the current code was good
enough for something.

Robert> of them. But if there's a 19e in beta now it *must* mean that
Robert> there's some bug in previous versions in the 19* series, and I
Robert> really don't want to ask my admin to install a version with a known
Robert> bug. Until 19e is stable, I am not comfortable asking my ISP's
Robert> admin to download *any* version, old with known bug nor current beta.

Every version of cmucl, released or not, stable or not, has had bugs
and will continue to have bugs.

Robert> I tried doing a Google search to find info about CMUCL 19e beta,
Robert> but couldn't find anything I could make sense of. Does anybody have
Robert> an estimate when 19e will be released? Is there any way to get

19e will most likely be released today or tomorrow. There will be no
changes from the 19e-pre2 release done one month ago, since no one has
reported any issues with that pre-release.

Robert> notified by e-mail when it's released?

Best bet is to join the cmucl-help or cmucl-imp mailing list. That's
also the best place to report bugs, even if they're for ancient
versions. Then someone might be able to tell you if that bug has been
fixed.

There may even be an announcement here someday. Maybe.

Ray

Robert Maas, http://tinyurl.com/uh3t

unread,

May 8, 2008, 4:24:52 AM5/8/08

to

Robert> Now it would seem to me that there must be several stable versions
Robert> between 18b and 19e, so maybe I should ask the admin to install one

> From: raymond....@ericsson.com (Raymond Toy (RT/EUS))
> There is 18c, 18d, 18e, 19a, 19b, 19c, 19d. They were all "stable",
> basically meaning that someone thought that the current code was good
> enough for something.

After I posted my original query, somebody in the UK offered me an
account on a machine where I would have disk space available to
download a new CMUCL version and play with it. When I reach a good
stopping point with my current ProxHash project, I'll probably
download the most recent stable version, which looks ilke 19d at
the moment, and see how it works in regard to both the
prettyprinter problem and the outright bug in SLEEP that I
experience in version 18b here.

Note: The bug in SLEEP isn't a problem, because I just use my own patch:
(defun cl-sleep (sec)
(cond ((and (not (integerp sec)) (>= sec 1.0))
(multiple-value-bind (int frac) (floor sec)
(sleep int) (sleep frac)))
(t (sleep sec))))
Still it'd be nice to know if they ever fixed it in the distributed CMUCL.

> 19e will most likely be released today or tomorrow. There will be no
> changes from the 19e-pre2 release done one month ago, since no one has
> reported any issues with that pre-release.

So now that it's been a few days since you posted that, it's now
already been released in the mean time?

> Best bet is to join the cmucl-help or cmucl-imp mailing list.

In an age of spam, and where I don't have any access to any
spam-protected e-mail account, joining mailing lists isn't
practical. If and when our local governments provides assistance to
low-income victims of spam who can't afford to spend ten thousand
dollars per spam just to hire lawyers and private detectives to
track down spammers and sue them for $1000 per spam, then I would
have a real defense against spam and I would be safe to join
mailing lists.

There's a possibility I might someday be able to set up my own SMTP
server on that computer in the UK I mentionned earlier. But at the
present time I don't have the time/energy to start another major
project, until my current major project has reached a good stopping
point.

Raymond Toy (RT/EUS)

unread,

May 8, 2008, 8:53:39 AM5/8/08

to

>>>>> "Robert" == Robert Maas <usenet1.3...@SpamGourmet.Com> writes:

Robert> Note: The bug in SLEEP isn't a problem, because I just use my own patch:
Robert> (defun cl-sleep (sec)
Robert> (cond ((and (not (integerp sec)) (>= sec 1.0))
Robert> (multiple-value-bind (int frac) (floor sec)
Robert> (sleep int) (sleep frac)))
Robert> (t (sleep sec))))
Robert> Still it'd be nice to know if they ever fixed it in the distributed CMUCL.

Well, I don't remember (but my memory is going) anyone ever mentioning
a bug with sleep, so, in all probability the bug still exists. But
18d was a long time ago.

>> 19e will most likely be released today or tomorrow. There will be no
>> changes from the 19e-pre2 release done one month ago, since no one has
>> reported any issues with that pre-release.

Robert> So now that it's been a few days since you posted that, it's now
Robert> already been released in the mean time?

Most binaries are in place, but no formal announcement yet, because
we're waiting for possibly one more binary.

>> Best bet is to join the cmucl-help or cmucl-imp mailing list.

Robert> In an age of spam, and where I don't have any access to any
Robert> spam-protected e-mail account, joining mailing lists isn't
Robert> practical. If and when our local governments provides assistance to

The cmucl-help and cmucl-imp mailing lists are closed. I haven't seen
any spam there after the lists became subscription-only. I also have
good luck with gmail, but perhaps you don't want to use that.

Ray

Madhu

unread,

May 8, 2008, 10:02:55 AM5/8/08

to

* (Raymond Toy (RT/EUS)) <sxdabj1...@rtp.ericsson.se> :
Wrote on Thu, 08 May 2008 08:53:39 -0400:

|>>>>> "Robert" == Robert Maas <usenet1.3...@SpamGourmet.Com> writes:
| Robert> Still it'd be nice to know if they ever fixed it in the distributed CMUCL.

| Well, I don't remember (but my memory is going) anyone ever mentioning
| a bug with sleep, so, in all probability the bug still exists. But
| 18d was a long time ago.

No, i think the following fixes the bug which Robert is referring to

18b (not 18d :) was tagged at 1.29.2.1.

--
Madhu

Don Geddis

unread,

May 8, 2008, 2:26:05 PM5/8/08

to

usenet1.3...@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t) wrote on Thu, 08 May 2008:
>> Best bet is to join the cmucl-help or cmucl-imp mailing list.
>
> In an age of spam, and where I don't have any access to any spam-protected
> e-mail account, joining mailing lists isn't practical.

You seem to read this newsgroup (comp.land.lisp) ok.

The CMUCL mailing lists are also available as newsgroups.
Just point your newsreader at the (free) gmane.org, and subscribe to
gmane.lisp.cmucl.general
gmane.lisp.cmucl.devel

_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
We tend to scoff at the beliefs of the ancients. But we can't scoff at them
personally, to their faces, and this is what annoys me.
-- Deep Thoughts, by Jack Handey

Raymond Toy (RT/EUS)

unread,

May 8, 2008, 5:32:09 PM5/8/08

to

>>>>> "Don" == Don Geddis <d...@geddis.org> writes:

Don> usenet1.3...@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t) wrote on Thu, 08 May 2008:
>>> Best bet is to join the cmucl-help or cmucl-imp mailing list.
>>
>> In an age of spam, and where I don't have any access to any spam-protected
>> e-mail account, joining mailing lists isn't practical.

Don> You seem to read this newsgroup (comp.land.lisp) ok.

Don> The CMUCL mailing lists are also available as newsgroups.
Don> Just point your newsreader at the (free) gmane.org, and subscribe to
Don> gmane.lisp.cmucl.general
Don> gmane.lisp.cmucl.devel

Presumably, Robert will also want to send messages to report bugs.
The gmane lists don't work anymore for sending messages to the list.

Ray

Raymond Toy (RT/EUS)

unread,

May 8, 2008, 5:32:55 PM5/8/08

to

>>>>> "Madhu" == Madhu <eno...@meer.net> writes:

Madhu> * (Raymond Toy (RT/EUS)) <sxdabj1...@rtp.ericsson.se> :
Madhu> Wrote on Thu, 08 May 2008 08:53:39 -0400:

Madhu> |>>>>> "Robert" == Robert Maas <usenet1.3...@SpamGourmet.Com> writes:
Madhu> | Robert> Still it'd be nice to know if they ever fixed it in the distributed CMUCL.

Madhu> | Well, I don't remember (but my memory is going) anyone ever mentioning
Madhu> | a bug with sleep, so, in all probability the bug still exists. But
Madhu> | 18d was a long time ago.

Madhu> No, i think the following fixes the bug which Robert is referring to

That was almost ten years ago. No wonder why I don't remember. :-)

Thanks,

Ray

Robert Maas, http://tinyurl.com/uh3t

unread,

Oct 9, 2009, 3:47:57 AM10/9/09

to

> From: Madhu <eno...@meer.net>

> No, i think the following fixes the bug which Robert is referring to
> ,---- From `cvs log code/multi-proc.lisp' :
> |
> | revision 1.31
> | date: 1998-09-26 23:54:42 +0530; author: pw; state: Exp; lines: +4 -3;
> |
> | SLEEP was broken for real arguments greater than one, sleeping for
> | approximately twice as long as requested.
> |
> `----
> 18b (not 18d :) was tagged at 1.29.2.1.

I didn't reply when I first saw this 1.5 years ago, because it
looked irrelevant to my bug report and I didn't want to make a fuss
over your mistake. But you brought up the issue again, citing the
article, claiming you'd already answered my question 1.5 years ago
when in fact you have *never* answered *my* question, so I felt the
need to clarify the issue:

The bug fixed in that report is that (sleep 2.5) sleeps for 5 seconds.

The bug I reported, which persisted since that fix on the system I
was using, through CMUCL 18b on FreeBSD 4.10-STABLE, but is finally
fixed in CMUCL 19c on FreeBSD 7.1-PRERELEASE, was that (sleep 2.5)
returns immediately without sleeping at all, not even a hundredth
of a second.

Please understand the difference between the two bugs,
and the difference as to when they were fixed,
the double-sleep bug allegedly fixed in 18b,
the zero-sleep bug not fixed (on FreeBSD) until sometime after then.

Now there's one other possibility, that the bug was *never* fixed,
but it only strikes x86 computers without the SSE chip, and *that*
may be why the bug went away when we moved to the new shell account
with new version of FreeBSD on double-quad-core CPU. I know the new
shell has the SSE chip because after I downloaded and installed
CMUCL 19f on my personal account and tested it, to reduce disk
space I tried moving the SSE coreimage to my Trash folder, but when
I started up CMUCL 19f the next time it complained that the CPU had
SSE but the coreimage wasn't available so it was reverting to the
regular x86 core instead (so then I moved the SSE coreimage back
from Trash to where it had been, and CMUCL 19f then started
normally with SSE core instead of reverting). Of course now that I
know what to look for, I can see it in the startup message where it
says: With core: /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib/lisp-sse2.core
Hmm, I wonder if I can test my hypothesis in the following way:
-1- Move the SSE core to Trash folder.
-2- Start up CMUCL 19f, so it reverts to non-SSE core.
-3- (sleep 2.5) and see if it works or not.
Doing that experiment now. Note it's x87 not x86 core. I didn't
notice that difference before.
> ~/Tmps/TmpCmucl/bin/lisp
Warning: Chip supports SSE2, but could not find SSE2 core.
Falling back to x87 core.
CMU Common Lisp 19f (19F), running on shell0.rawbw.com
With core: /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib/lisp-x87.core
Dumped on: Tue, 2009-03-10 20:58:42-07:00 on daland
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2008-11-12 16:36:41
* (time (sleep 2.5))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 2.5 seconds of real time
..
Hypothesis disproven, the sleep-zero bug was fixed even in vanilla
x87 core, at least for CMUCL 19f. I have no practical way to test
whether the x87 core of CMUCL 19c has the sleep-zero bug fixed
because the core is on the system directory where I can't mess with
it. (No, I don't have enough spare disk space that I could download
another copy of CMUCL 19c and tinker with it, unless I first delete
my copy of CMUCL 19f, which I'd rather not do at this time.)

Thomas F. Burdick

unread,

Oct 9, 2009, 4:14:41 AM10/9/09

to

On Oct 9, 9:47 am, seeWebInst...@rem.intarweb.org (Robert Maas,
http://tinyurl.com/uh3t) wrote:

> Please understand the difference between the two bugs,

Please understand the difference between comp.lang.lisp and "Robert's
personal cmucl bug reporting system".

Madhu

unread,

Oct 9, 2009, 11:55:35 AM10/9/09

to

* (Robert Maas, http://tinyurl.com/uh3t) <REM-2009...@Yahoo.Com> :
Wrote on Fri, 09 Oct 2009 00:47:57 -0700:

See my message this week in another thread:

Date: Wed, 07 Oct 2009 05:08:18 +0530
Message-ID: <m3vdisx...@moon.robolove.meer.net>

And the messages upthread. This particular message includes the the only
relevant change in the CMUCL sources (other than the one you quoted
above, which I posted 1.5 years ago), and it dates from Jan 1998.

[..]

| Now there's one other possibility, that the bug was *never* fixed,
| but it only strikes x86 computers without the SSE chip, and *that*
| may be why the bug went away when we moved to the new shell account
| with new version of FreeBSD on double-quad-core CPU.

Again you are indulging in unwarranted speculation. The SLEEP code has
not changed since september 1998, and the bug you faced was probably
fixed in the code in January 1998, as I noted in the above thread. I
suspect your 18b build predates the January fix.

--
Madhu

Robert Maas, http://tinyurl.com/uh3t

unread,

Oct 20, 2009, 3:47:56 AM10/20/09

to

> From: Madhu <enom...@meer.net>

> See my message this week in another thread:
> Date: Wed, 07 Oct 2009 05:08:18 +0530

> Message-ID: <m3vdisxfdh....@moon.robolove.meer.net>

I hate the way Google Groups trashes anything with an atsign in it,
in the grossly stupidly mistaken belief it's an e-mail address that
needs protection from harvesting by spammers' bots.

> The SLEEP code has not changed since september 1998, and the bug
> you faced was probably fixed in the code in January 1998, as I
> noted in the above thread. I suspect your 18b build predates the
> January fix.

Hmm, going to old shell for a moment:

FreeBSD 4.10-STABLE (SHELL) #0: Thu Feb 16 03:07:17 PST 2006

shell.rawbw.com% lisp
CMU Common Lisp 18b, running on shell.rawbw.com
Send questions and bug reports to your local CMU CL maintainer, or to cmucl-help
@cons.org. and cmuc...@cons.org. respectively.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
I didn't notice before, but that version of CMUCL doesn't say when
it was built, only which-date version of PCL CLOS it
copied/converted.

shell.rawbw.com% whereis lisp
lisp: /usr/local/bin/lisp /usr/local/man/man1/lisp.1.gz
shell.rawbw.com% ls -l /usr/local/bin/lisp /usr/local/man/man1/lisp.1.gz

576 -rwxr-xr-x 1 root wheel 579696 Mar 11 2001 /usr/local/bin/lisp*

3 -rwxr-xr-x 1 root wheel 2417 Mar 11 2001 /usr/local/man/man1/lisp.1.gz*
That looks like the date the ISP installed it, not the date it was
originally built, so that doesn't help resolve the question either.

By comparison, the new 19c on the new shell says clearly when it was built:
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com

See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86

CLOS based on Gerd's PCL 2004/04/14 03:32:47
It must have been built shortly (within hours) before it was "dumped".

OK, one thing's starting to bother me, as this thread continues to
gather clues: It says the target was Intel x86, but the machine
it's running on is Intel Xeon. Does anybody reading this thread
know if that difference could cause a compatibility problem?

Hmm, I just now noticed something I didn't notice before, when I
telnet back to the new shell, I see:

FreeBSD/amd64 (shell0.rawbw.com) (ttyp2)
Last login: Sun Oct 18 10:05:47 from max0.rawbw.net
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009

Since the system-miagration message clearly says we're running on
Intel Xeon, but the TELNET-greeting says this is FreeBSD/amd64,
could it be that the admin installed the wrong build of FreeBSD,
installed an AMD build to run instead on an Intel Xeon dual-quad??
If so, it's amazing the system runs at all, and more amazingly:
> uptime
12:45AM up 210 days, 21:09, 5 users, load averages: 0.46, 0.40, 0.32
(This is relevant to the other thread regarding page-fault signals
crashing CMUCL whenever a second GC happens within a given
coreimage run.)

Raymond Toy

unread,

Oct 20, 2009, 12:10:38 PM10/20/09

to

>>>>> "Robert" == Robert Maas <seeWeb...@rem.intarweb.org> writes:

Robert> shell.rawbw.com% lisp
Robert> CMU Common Lisp 18b, running on shell.rawbw.com
Robert> Send questions and bug reports to your local CMU CL maintainer, or to cmucl-help
Robert> @cons.org. and cmuc...@cons.org. respectively.
Robert> Loaded subsystems:
Robert> Python 1.0, target Intel x86
Robert> CLOS based on PCL version: September 16 92 PCL (f)
Robert> I didn't notice before, but that version of CMUCL doesn't say when
Robert> it was built, only which-date version of PCL CLOS it
Robert> copied/converted.

AFAICT, 18b was released around July 1998...

Robert> By comparison, the new 19c on the new shell says clearly when it was built:

Well, because 19c (or earlier) added that feature.

Robert> CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
Robert> With core: /usr/local/lib/cmucl/lib/lisp.core
Robert> Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
Robert> See <http://www.cons.org/cmucl/> for support information.
Robert> Loaded subsystems:
Robert> Python 1.1, target Intel x86
Robert> CLOS based on Gerd's PCL 2004/04/14 03:32:47
Robert> It must have been built shortly (within hours) before it was "dumped".

Robert> OK, one thing's starting to bother me, as this thread continues to
Robert> gather clues: It says the target was Intel x86, but the machine
Robert> it's running on is Intel Xeon. Does anybody reading this thread
Robert> know if that difference could cause a compatibility problem?

There's nothing magic about it. That "Intel x86" is hardwired into
the build and basically means the compiler is targeted for an x86.
There used to be some specific things for AMD, Pentium Pros, Pentiums,
and i486, but I don't think those features are turned on anymore,
except i486 and Pentium which are enabled. They should work on
everything later than a Pentium. :-)

Ray