Seems like I have to apologize for the 32bit confusion, when I tried
today it simply worked, no ht:Pack problems.

Anyway, I ran my import script which starts off with trying to load an xml =

(in "opml.xml" (and (xml?) (xml)))

That's how far (traceAll) goes, it simply manages to output 'xml'
before the interpreter locks up completely at 100% of cpu, I have to
kill it every time.

On Mon, Oct 26, 2009 at 4:46 PM, Henrik Sarvell <> wrote:
> About the Mac stuff, AFAIK everything works OK on the Intel architecture.
> Putting even a joule of effort into making things work on the old
> Motorola processors would be too much.
> On Mon, Oct 26, 2009 at 2:46 PM, Alexander Burger <> w=
>> On Mon, Oct 26, 2009 at 02:11:41PM +0100, Henrik Sarvell wrote:
>>> The only thing that is different is that I'm now running them on a
>>> 64bit system. The interpreter works just fine, it's just that ht:Pack
>>> thing that won't play ball.
>> Strange. What does 'file' say?
>> =A0 $ file lib/ht
>> =A0 lib/ht: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),=
 dynamically linked, stripped
>> Looking in "lib/ht" should show that 'Pack' exists:
>> =A0 $ strings lib/ht |fgrep Pack
>> =A0 Pack
>> Does this the case? Perhaps we can look at it together later in IRC?
>>> Oh btw, when it comes to the 64bit crash, I noticed that the database
>>> files were not numbered anymore but had file names such as for
>>> instance '@', and '@A', I suppose that's as it should be?
>> Yes, that's correct. The internal structure, the names of the DB files,
>> and the names of external symbols changed.
>> Files now have names consisting of '@' and the letters 'A' through 'O'.
>> External symbols no longer have a hyphen in their name, and consist of a
>> sequence of the above letters for the file part, and octal digits for
>> the object part (e.g. {AC71231}).
>> Cheers,
>> - Alex
>> --

Reply via email to