I haven't used Lisp much in quite a few years -- most of my porting
experience between Lisps occurred in CLtL1 days, when things weren't so
well nailed down. Recently I've been quite pleased to play around with
Corman CommonLisp -- it seems great on machines hundreds of times faster
than in the olden days.
In need of a utility for cleanng up my storage on a very messed up mail
server, I decided to port to it an open-source POP3 and IMAP client I
found on the Allegro CL website. This seemed very easy at first -- both
systems had multiprocessing (possibly written by the same guy), socket
interfaces, etc. The potentially tricky areas involving the network
stuff turned out to be simple, once I discovered the stream wrappers for
the Corman Lisp socket code which made porting that part almost entirely
a matter of changing package names. Most of the work turned out to be
in areas where I never expected problems -- wasting time dealing with
that accursed if* macro that Franz sprinkles liberally over its code,
and dealing with several nasty little nonstandard characters used in the
Allegro implementation (some of which triggered no compiler warnings or
errors but just produced bizarre and confusing behavior). The compiler
told me something was wrong with
(char-code #\^b)
and a workaround was easy (but non-portable). However, some details
have faded from my lisp knowledge -- I didn't remember that #\linefeed
was not a standard character, or even worse, that Corman Lisp would have
(eq (char-code #\linefeed) (char-code #\l)) ==> t
so the parser of responses from the mail server would think it reached
the end of a line every time it saw the character #\l, and the command
dispatcher would append #\l instead of #\newline to the commands sent to
the server, so the server would hang waiting for more.
There were also some seemingly gratuitous package shifts in Allegro,
such as cl::format-control --> excl::format-control as accessors for
simple-condition slots.
Is this a typical experience porting somewhat platform-dependent code
between CommonLisp implementations? Is it usually such a nuisance? I'm
not trying to start a flame war, just get some assessment of common
experience.
Jeff
On Wed, 17 Oct 2001 04:40:22 GMT, "Jeff Greif"
<······@spam-me-not.alumni.princeton.edu> wrote:
>
>Is this a typical experience porting somewhat platform-dependent code
>between CommonLisp implementations? Is it usually such a nuisance? I'm
>not trying to start a flame war, just get some assessment of common
>experience.
>
We have noted the problems you mentioned with Corman Lisp and will address them
shortly. There are still a number of defects relating to standard conformance,
and many of them are being addressed, with the help of a number of other people
who, like you, are porting other packages. For some reason, it seems only
recently that quite a bit of work has started to be done with Corman Lisp and
older code, and I feel this is a sign of increased product recognition and
maturity. I believe that within the next few months most (at least the major)
areas of incompatibility will have been addressed.
At the same time, if you fix any of the problems yourself (you have the source
code) we appreciate it if you send your fixes to ····@corman.net and they will
be incorporated into the main code stream.
Roger Corman
"Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
> The compiler
> told me something was wrong with
> (char-code #\^b)
> and a workaround was easy (but non-portable).
You had this literally in code? I don't understand why. Don't you
just mean 2?
I can understand doing (defconstant +control-b+ (code-char 2)) and
using that in places (though generally a #\ followed by the character whose
code is 2 ports fine to most places for me).
I don't generally use Corman CL (not for any principled reason), so I can't
speak to its particular nuances, bit I just didn't understand the issue here.
> However, some details
> have faded from my lisp knowledge -- I didn't remember that #\linefeed
> was not a standard character, or even worse, that Corman Lisp would have
> (eq (char-code #\linefeed) (char-code #\l)) ==> t
> so the parser of responses from the mail server would think it reached
> the end of a line every time it saw the character #\l, and the command
> dispatcher would append #\l instead of #\newline to the commands sent to
> the server, so the server would hang waiting for more.
This is definitely Corman-specific and he seems to be on top of it for you.
> There were also some seemingly gratuitous package shifts in Allegro,
> such as cl::format-control --> excl::format-control as accessors for
> simple-condition slots.
CL defines no external symbol FORMAT-CONTROL. And there is no reason to
assume any particular internal symbol exists at all.
If you're using internal symbols in any package, you're hitting a SERIOUS
red flag to even continued workage in the same implementation much less
porting.
> Is this a typical experience porting somewhat platform-dependent code
> between CommonLisp implementations?
Most implementations I've dealt with handle #\Linefeed and #\Return
correctly.
Most implementations I've dealt with do fine with ASCII control chars,
if that's what you wanted, by just constructing (code-char 2).
The rest of the stuff looks like normal porting issues that you can
easily see coming. As soon as you're using stuff that's not in the spec,
you know you're up against a vendor-by-vendor issue. Just keep a file
that isolates this stuff away from your main body of code, which should
never deal with this, and your porting problems usually stay pretty simple.
> Is it usually such a nuisance?
You're using non-portable things and you expressed a list of about 3 tiny
things you had to modify to do the port. I'm not sure I understand this
use of the term "nuisance" well enough to answer.
> I'm not trying to start a flame war, just get some assessment of
> common experience.
Details of individual projects vary widely, so it's hard to say what
constitutes an average or common experience. But in my experience,
the first port is the hardest and it falls off by factors of 2-4 in
difficulty after that with each new port.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
>
> > The compiler
> > told me something was wrong with
> > (char-code #\^b)
> > and a workaround was easy (but non-portable).
>
> You had this literally in code? I don't understand why. Don't you
> just mean 2?
>
The compiler found it for me in the code I was porting! I fixed it by
assuming it meant 2. When I got past wondering whether something
strange was happening in the socket code and diagnosed the bug below, I
changed #\linefeed to (code-char 10).
> > However, some details
> > have faded from my lisp knowledge -- I didn't remember that
#\linefeed
> > was not a standard character, or even worse, that Corman Lisp would
have
> > (eq (char-code #\linefeed) (char-code #\l)) ==> t
> > so the parser of responses from the mail server would think it
reached
> > the end of a line every time it saw the character #\l, and the
command
> > dispatcher would append #\l instead of #\newline to the commands
sent to
> > the server, so the server would hang waiting for more.
> This is definitely Corman-specific and he seems to be on top of it for
you.
Roger Corman sent me patches this afternoon, which is more than
unusually responsive! I'm not trying to grouse at Corman Lisp. So far
it's been very good. The bug I hit is pretty obscure. It was amazing
how potent it turned out to be.
> You're using non-portable things and you expressed a list of about 3
tiny
> things you had to modify to do the port. I'm not sure I understand
this
> use of the term "nuisance" well enough to answer.
I guess it was irksome not to have solved or nearly solved the problems
when the compiler stopped complaining -- the debugging lasted several
times longer, and turned out to mainly involve code that should have
been portable -- a tokenizer and what was ultimately an obscure and
fancy variant of readline for the socket stream. Just wishful thinking,
I guess. At least I didn't have to learn how to debug the FFI.
Jeff
"Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
> Is this a typical experience porting somewhat platform-dependent code
> between CommonLisp implementations? Is it usually such a nuisance? I'm
Well, the If* Experience can be resolved quite easily by downloading
said macro from
http://www.franz.com/~jkf/ifstar.txt
(linked from http://opensource.franz.com/aserve/index.html)
If anyone at Franz is listening, they might want to consider putting
another link on the front of opensource.franz.com, because not
everybody is going to check either the Allegroserve pages or the
"Coding Standards" page (not really wishing to start that debate again)
The rest of the problems sound not completely atypical
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
"Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
> so the parser of responses from the mail server would think it reached
> the end of a line every time it saw the character #\l, and the command
> dispatcher would append #\l instead of #\newline to the commands sent to
> the server, so the server would hang waiting for more.
I came across this porting AllegroServe to Corman Lisp. I put a
workaround in the AllegroServe port but neglected to inform
Roger. Sorry about that, if I had it would probably already be
fixed. The fix was to do the following:
(in-package :cl)
(defcharname "LINEFEED" (int-char 10))
I also included If* for Corman Lisp in the AllegroServe port if I
recall. See my website http://www.double.co.nz/cl.
I'm glad you found the sockets and multiprocessing libraries useful. I
wrote them for Corman Lisp and tried to make them fit the Allegro API
so as to make porting code easier. Included in the AllegroServe port
is a socket wrapper that matches the Allegro API as well. This makes
porting socket code even easier.
I looked at porting the POP and IMAP packages as well but never found
the time. Would you consider making your port available?
> Is this a typical experience porting somewhat platform-dependent
> code between CommonLisp implementations?
Yes. The main problems are usually sockets, multiprocessing and
GUI. That's why I wrote the sockets and MP packages to model ACL so as
to make porting a bit easier.
Chris.
--
http://www.double.co.nz/cl
Chris Double <·····@double.co.nz> writes:
> "Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
>
> > so the parser of responses from the mail server would think it reached
> > the end of a line every time it saw the character #\l, and the command
> > dispatcher would append #\l instead of #\newline to the commands sent to
> > the server, so the server would hang waiting for more.
>
> I came across this porting AllegroServe to Corman Lisp. I put a
> workaround in the AllegroServe port but neglected to inform
> Roger. Sorry about that, if I had it would probably already be
> fixed. The fix was to do the following:
>
> (in-package :cl)
> (defcharname "LINEFEED" (int-char 10))
DEFCHARNAME?
This is implementation dependent: I would use the fully qualified
name for it.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Chris,
Thanks a lot for all the work you've done with socket and MP libraries.
Yes, I'll be happy to make the imap/pop3 port available once I test it a
little better. In my confusion about the bugs I ran into, I ripped out
a complicated function that was a fancy way of reading a line from a
socket, using a pool of buffers to avoid allocations, and some other
bells and whistles that would probably best have been handled a
different way. I want to try putting back the original function since I
removed some of its extra goodies in my simplified version.
I don't know where to contribute it -- should I just email it to you?
Jeff
"Chris Double" <·····@double.co.nz> wrote in message
···················@double.co.nz...
> "Jeff Greif" <······@spam-me-not.alumni.princeton.edu> writes:
>
> I'm glad you found the sockets and multiprocessing libraries useful. I
> wrote them for Corman Lisp and tried to make them fit the Allegro API
> so as to make porting code easier. Included in the AllegroServe port
> is a socket wrapper that matches the Allegro API as well. This makes
> porting socket code even easier.
>
> I looked at porting the POP and IMAP packages as well but never found
> the time. Would you consider making your port available?
>