I've added a 'compatibility layers' page to CLiki.
compatibility layers : code for solving compatibility between the different
Common Lisp implementations issues for things not in the CL standard.
This is intended for small layers like socket interface, foreign function
interface, etc. Not for heavy stuff like HTTP servers, even if one is
included in a particular implementation for instance.
So far I've only put Kevin Rosenberg's UFFI but I hope we will soon see more
compatibility layers.
Marc
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CEA9A96.3A5E3459@smi.de>
Marc Battyani wrote:
>
> compatibility layers : code for solving compatibility between the different
> Common Lisp implementations issues for things not in the CL standard.
> This is intended for small layers like socket interface, foreign function
> interface, etc. Not for heavy stuff like HTTP servers, even if one is
> included in a particular implementation for instance.
>
Great idea.
Best regards
AHz
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CEBB913.FF3484C3@smi.de>
Marc Battyani wrote:
>
> I've added a 'compatibility layers' page to CLiki.
>
Maybe it would also be a good idea to have a page where "similar"
functions
are described. I.e. CMU knows "run-program" to start an external program
and
i assume other lisps will have a similar mechanism.
Collecting those things make two things easier:
1. Writing code more portable
2. Building compatibility layers
That would make it much more easy to port programs specially for
beginners.
Would that also be possible on Cliki ?
Best regards
AHz
I would also add a "ranking" for layered libraries stating the "degree
of compatibility" across CL implementations.
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'.
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CECBC70.3D518952@smi.de>
Marco Antoniotti wrote:
>
> I would also add a "ranking" for layered libraries stating the "degree
> of compatibility" across CL implementations.
>
Mhh, that will incorporate a lot of work to find out.
A simpler approach is to say work/work-not with particular
implementations.
So a simple list of "compatible" implementations will do. Or not ?
Best
AHz
Andy <···@smi.de> writes:
> Marco Antoniotti wrote:
> >
> > I would also add a "ranking" for layered libraries stating the "degree
> > of compatibility" across CL implementations.
> >
> Mhh, that will incorporate a lot of work to find out.
> A simpler approach is to say work/work-not with particular
> implementations.
> So a simple list of "compatible" implementations will do. Or not ?
Maybe. My thinking is that if you are not dealing with something that
*needs* to be specific to one implementation, you should write
portable code. That is why I would go for a "portability measure".
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'.
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CED3084.CCCCA496@smi.de>
Marco Antoniotti wrote:
>
> Andy <···@smi.de> writes:
>
> > Marco Antoniotti wrote:
> > >
> > > I would also add a "ranking" for layered libraries stating the "degree
> > > of compatibility" across CL implementations.
> > >
> > Mhh, that will incorporate a lot of work to find out.
> > A simpler approach is to say work/work-not with particular
> > implementations.
> > So a simple list of "compatible" implementations will do. Or not ?
>
> Maybe. My thinking is that if you are not dealing with something that
> *needs* to be specific to one implementation, you should write
> portable code. That is why I would go for a "portability measure".
>
Sometimes i'm a little bit slow, sorry. But how will you qualify that ?
Best regards
AHz
Andy <···@smi.de> writes:
> Marco Antoniotti wrote:
...
> > Maybe. My thinking is that if you are not dealing with something that
> > *needs* to be specific to one implementation, you should write
> > portable code. That is why I would go for a "portability measure".
> >
> Sometimes i'm a little bit slow, sorry. But how will you qualify
> that ?
This requires a long answer. I do not know if an example would
suffice, but I will try.
Let's take a "socket library" (there are plenty out there). I am
generally not interested in a "publicly available" library marked
"Works under CMUCL and GCL". I am interested in a library marked
"Works on all implementations" and "it's interface is well thought
out." Not only that. I am also interested in a library marked by
"extensions can be written by adding a `separate' file to it."
It is true that this reflects the way I tend to write my code, but
that is the way I look at things.
What I am trying to get across is that I have a way of jundging a
library that goes beyond the immediate need of having it work on a
specific implementation. E.g. recently I appreciated 'scigraph',
quite nice. However, I do not think 'scigraph' solves "the" problem
of providing a cross-cutting graphing solution for Common Lisp as a
whole, therefore, I tend not to regard it as highly.
I hope I clarified my thoughts (which are developing as I write :))
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'.
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CEE6DBF.21D45D02@smi.de>
Marco Antoniotti wrote:
>
> Let's take a "socket library" (there are plenty out there). I am
> generally not interested in a "publicly available" library marked
> "Works under CMUCL and GCL". I am interested in a library marked
> "Works on all implementations" and "it's interface is well thought
> out." Not only that. I am also interested in a library marked by
> "extensions can be written by adding a `separate' file to it."
>
Since different users want different features it will still be hard to
make that ranking in a general way.
But on the other side at least the contributor of the library should
know what features his package has. So he can give a short feature list
as orientation.
Best regards
AHz
Andy <···@smi.de> writes:
> Marco Antoniotti wrote:
> >
> > Let's take a "socket library" (there are plenty out there). I am
> > generally not interested in a "publicly available" library marked
> > "Works under CMUCL and GCL". I am interested in a library marked
> > "Works on all implementations" and "it's interface is well thought
> > out." Not only that. I am also interested in a library marked by
> > "extensions can be written by adding a `separate' file to it."
> >
> Since different users want different features it will still be hard to
> make that ranking in a general way.
Yes it will.
> But on the other side at least the contributor of the library should
> know what features his package has. So he can give a short feature list
> as orientation.
Yes, but I want to make sure that the "measure" compelled contributors
to make their software portable, unless that is strictly non required
by the nature of the library.
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'.
"Andy" <···@smi.de> wrote
> Marc Battyani wrote:
> >
> > I've added a 'compatibility layers' page to CLiki.
> >
> Maybe it would also be a good idea to have a page where "similar"
> functions
> are described. I.e. CMU knows "run-program" to start an external program
> and i assume other lisps will have a similar mechanism.
> Collecting those things make two things easier:
>
> 1. Writing code more portable
> 2. Building compatibility layers
>
> That would make it much more easy to port programs specially for
> beginners.
> Would that also be possible on Cliki ?
IMO this kind of information should be put in the Common Lisp Cookbook
rather than CLiki.
The CL cookbook is there: http://cl-cookbook.sourceforge.net/
The best thing to do in that case should be to look at the run-program and
related functions in several implementations. Choose the best one and write
a thin compatibility layer for the other implementations. Release it under a
liberal license and publish it on the 'compatibility layer' page on CLiki.
If you are not sure about Lisp issues, post here and I'm sure you will get
some help.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Andy" <···@smi.de> wrote
> > Marc Battyani wrote:
> > >
> > > I've added a 'compatibility layers' page to CLiki.
> > >
> > Maybe it would also be a good idea to have a page where "similar"
> > functions are described. I.e. CMU knows "run-program" to start an
> > external program and i assume other lisps will have a similar
> > mechanism. Collecting those things make two things easier:
> >
> > 1. Writing code more portable
> > 2. Building compatibility layers
> >
> > That would make it much more easy to port programs specially for
> > beginners. Would that also be possible on Cliki ?
>
> IMO this kind of information should be put in the Common Lisp
> Cookbook rather than CLiki. The CL cookbook is there:
> http://cl-cookbook.sourceforge.net/
I think that some of these 'thin layers' are already part of CLOCC
<http://clocc.sf.net/>. As others have suggested it would be a good
start if someone wrote a CLOCC chapter for the cookbook where he/she
described what's in CLOCC and showed examples on it how it is to be
used.
Any volunteers? I will do this eventually if nobody else does, but
currently I'm up to my ears in work... :(
Edi.
"Edi Weitz" <···@agharta.de> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > "Andy" <···@smi.de> wrote
> > > Marc Battyani wrote:
> > > >
> > > > I've added a 'compatibility layers' page to CLiki.
> > > >
> > > Maybe it would also be a good idea to have a page where "similar"
> > > functions are described. I.e. CMU knows "run-program" to start an
> > > external program and i assume other lisps will have a similar
> > > mechanism. Collecting those things make two things easier:
> > >
> > > 1. Writing code more portable
> > > 2. Building compatibility layers
> > >
> > > That would make it much more easy to port programs specially for
> > > beginners. Would that also be possible on Cliki ?
> >
> > IMO this kind of information should be put in the Common Lisp
> > Cookbook rather than CLiki. The CL cookbook is there:
> > http://cl-cookbook.sourceforge.net/
>
> I think that some of these 'thin layers' are already part of CLOCC
> <http://clocc.sf.net/>. As others have suggested it would be a good
> start if someone wrote a CLOCC chapter for the cookbook where he/she
> described what's in CLOCC and showed examples on it how it is to be
> used.
> Any volunteers? I will do this eventually if nobody else does, but
> currently I'm up to my ears in work... :(
I have added CLOCC/PORT to the 'compatibility layers' page on CLiki.
It would be better to put individual links to the different layers in it but
as you noticed, time is a limited resource. I'm sure that we will find that
lots of compatibility layers around as everybody had to write a few of
them....
Marc
From: Andy
Subject: Re: Added a 'compatibility layers' page at CLiki
Date:
Message-ID: <3CEBD872.E52BE766@smi.de>
Marc Battyani wrote:
>
> IMO this kind of information should be put in the Common Lisp Cookbook
> rather than CLiki.
> The CL cookbook is there: http://cl-cookbook.sourceforge.net/
>
I just have had a short look to the CL cookbook. Yes, it seems to be a
more
appropriate place.
Best
AHz