Problem with libstrings.fs and the bootloader

Has anybody else encountered a weird interaction between the bootloader 
kit and libstrings.fs? I'm only on my first picforth program so it may 
be something daft I'm doing. Basically I've got a working emit word that 
sends a character to the UART and some code like this:

: emitln begin str-char dup while emit repeat drop $0d emit $0a emit ;
main : main initialise c" Hello World" emitln begin again ;

Using the bootloader, I get a huge amount of garbage printed out instead 
of the expected "Hello World\r\n". After a fair bit of debugging and 
reading the raw disassembly I discovered that str-char was returning 
complete garbage (as if it was being asked to read the wrong address), 
but the generated code appeared fine.

Then I decided to try programming the hex file onto the chip without the 
bootloader- and it worked perfectly first time. But I'd rather use the 
bootloader because it's several times quicker than taking the chip out 
and programming it in my PIC programmer.

On a similar note, has anybody succeeded in using pfd.py on a Mac OSX 
system? I've had to resort to running it on a Linux server because I get 
the following error message when I run it on my Mac, regardless of 
whether the PIC board is connected to the USB serial dongle or not:

Connecting to PicForth monitor (press Ctrl-C to abort):Traceback (most 
recent call last):
   File "./pfd.py", line 702, in ?
     main()
   File "./pfd.py", line 689, in main
     do_download(**options)
   File "./pfd.py", line 538, in do_download
     pic.connect(conn_callback)
   File "./pfd.py", line 209, in connect
     self.tty.write(" ")
   File "./pfd.py", line 175, in write
     os.write(self.fd, s)
OSError: [Errno 35] Resource temporarily unavailable

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer