So, I know CL didn't define a wide range of system-access libraries (threads,
GUI, network, even buffered IO until write-sequence seems to have been slipped
in -- I don't see it in earlier books). Looking around, it's seemed that
various libraries have tried to practically remedy this situation: uffi for
general system access, some CLOCC library for networking, CLIM among the
commercial Lisps for graphics, followed by McClim trying to implement it for
free.
My question is: how well does all this work in practice? Are people used to
actually writing a network- and graphics-using program which can slip between
CMUCL on Unix and Allegro on Windows, for example, with no more trouble than
providing a couple of libraries? And is McClim mostly usable now, or would I
be safer sticking to Garnet for now, for porting a Chez Scheme program which
needs graphics but not very complicated graphics?
-xx- Damien X-)
In article <············@hood.uits.indiana.edu>,
········@cs.indiana.edu (Damien R. Sullivan) wrote:
> So, I know CL didn't define a wide range of system-access libraries (threads,
> GUI, network, even buffered IO until write-sequence seems to have been slipped
> in -- I don't see it in earlier books). Looking around, it's seemed that
> various libraries have tried to practically remedy this situation: uffi for
> general system access, some CLOCC library for networking, CLIM among the
> commercial Lisps for graphics, followed by McClim trying to implement it for
> free.
>
> My question is: how well does all this work in practice? Are people used to
> actually writing a network- and graphics-using program which can slip between
> CMUCL on Unix and Allegro on Windows, for example, with no more trouble than
> providing a couple of libraries? And is McClim mostly usable now, or would I
> be safer sticking to Garnet for now, for porting a Chez Scheme program which
> needs graphics but not very complicated graphics?
I can't comment on the specific libraries because I don't have too much
experience with them.
However, my impression is that it's best to choose one CL implementation
that has the set of features that is closest to your specific needs and
stick to it while developing your application. If the situation comes up
in the future that you really need to port your app to other CLs you can
do that then. At least, this has been successfully done in the past in
the case of AllegroServe which has resulted in the ACL-COMPAT library.
Don't worry about problems that you dan't have right now. ;)
Of course, things are different when you want to build a library that is
intended to be portable across CL implementations from the very start,
like Kenny's Cells stuff. But I guess it's rarely the case that someone
is so brave. ;)
Pascal