Hi,
I'm a begginer with this language. I run it under Linux and i want to know
if is possible to use sockets with it. Where can i find a tutorial or a
book about this?
Thanks
In article <·······················@news-reader.eresmas.com>,
keriko <················@yahoo.es> wrote:
> Hi,
> I'm a begginer with this language. I run it under Linux and i want to know
> if is possible to use sockets with it. Where can i find a tutorial or a
> book about this?
> Thanks
Consult the manual of the Lisp you are using.
In article <····························@news-50.dca.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article <·······················@news-reader.eresmas.com>,
> keriko <················@yahoo.es> wrote:
>
> > Hi,
> > I'm a begginer with this language. I run it under Linux and i want to know
> > if is possible to use sockets with it. Where can i find a tutorial or a
> > book about this?
> > Thanks
>
> Consult the manual of the Lisp you are using.
CTMOTLYAU
keriko <················@yahoo.es> wrote:
> Hi,
> I'm a begginer with this language. I run it under Linux and i want to know
> if is possible to use sockets with it. Where can i find a tutorial or a
> book about this?
> Thanks
Since sockets are, unfortunately, not part of the Common Lisp standard,
each implementations handles them differently, but socket support is
usually there. Grab the documentation/manual of your particular Lisp
implementation and look into the appropriate sections.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber <···@usenet.thangorodrim.de> writes:
> keriko <················@yahoo.es> wrote:
> > Hi,
> > I'm a begginer with this language. I run it under Linux and i want to know
> > if is possible to use sockets with it. Where can i find a tutorial or a
> > book about this?
> > Thanks
>
> Since sockets are, unfortunately, not part of the Common Lisp standard,
> each implementations handles them differently, but socket support is
> usually there. Grab the documentation/manual of your particular Lisp
> implementation and look into the appropriate sections.
Of if you are using C, or C++, or most languages:
Since sockets are, unfortunately, not part of the C standard,
each implementations handles them differently, but socket support is
usually there. Grab the documentation/manual of your particular C
implementation and look into the appropriate sections.
Note that the Sockets "standard" also varies some across
operating systems.
What would be useful is a standard Common Lisp binding for
the Sockets library, but of course it doesn't belong on the
Common Lisp _language_ standard.
Are there not several candidates available at this time,
implemented with an API that's portable across implementations?
(I don't know, because I just use the proprietary ones directly.)
If one types in {"Common Lisp" sockets} to Google,
you get back as the first hits:
* The Common Lisp Cookbook - Sockets
cl-cookbook.sourceforge.net/sockets.html
The Common Lisp Cookbook. This is a collaborative project that aims to provide for
Common Lisp something similar to the Perl Cookbook published by O'Reilly. ...
cl-cookbook.sourceforge.net/ - 9k - Cached - Similar pages
* CLiki : Networking
Lisp code for various; CommonURI - CommonURI is a Allegro Common
Lisp (ACL) Networking NET-dot-URI compatible library for handling
URIs; db-sockets - db-sockets
* Common Lisp
p Support for using sockets through a proxy server is part of the package. ...
Common Lisp socket-level interface to the PostgreSQL RDBMS. ...
cbbrowne.com/info/commonlisp.html
* Chris' Corman Lisp Collection
A package that emulates some of the Allegro Common Lisp
multiprocessing functionality. Requires the SOCKETS and MP packages.
www.double.co.nz/cl/
So I'd start by looking at those pages.
Thanks,
I always search lisp stockets, not common lisp socktes, so i had a bit more
results.
Thanks.
Christopher C. Stacy escribio:
> Alexander Schreiber <···@usenet.thangorodrim.de> writes:
>
>> keriko <················@yahoo.es> wrote:
>> > Hi,
>> > I'm a begginer with this language. I run it under Linux and i want to
>> > know
>> > if is possible to use sockets with it. Where can i find a tutorial or a
>> > book about this?
>> > Thanks
>>
>> Since sockets are, unfortunately, not part of the Common Lisp standard,
>> each implementations handles them differently, but socket support is
>> usually there. Grab the documentation/manual of your particular Lisp
>> implementation and look into the appropriate sections.
>
> Of if you are using C, or C++, or most languages:
>
> Since sockets are, unfortunately, not part of the C standard,
> each implementations handles them differently, but socket support is
> usually there. Grab the documentation/manual of your particular C
> implementation and look into the appropriate sections.
>
> Note that the Sockets "standard" also varies some across
> operating systems.
>
> What would be useful is a standard Common Lisp binding for
> the Sockets library, but of course it doesn't belong on the
> Common Lisp _language_ standard.
>
> Are there not several candidates available at this time,
> implemented with an API that's portable across implementations?
> (I don't know, because I just use the proprietary ones directly.)
> If one types in {"Common Lisp" sockets} to Google,
> you get back as the first hits:
>
> * The Common Lisp Cookbook - Sockets
> cl-cookbook.sourceforge.net/sockets.html
> The Common Lisp Cookbook. This is a collaborative project that aims
> to provide for Common Lisp something similar to the Perl Cookbook
> published by O'Reilly. ... cl-cookbook.sourceforge.net/ - 9k - Cached
> - Similar pages
>
> * CLiki : Networking
> Lisp code for various; CommonURI - CommonURI is a Allegro Common
> Lisp (ACL) Networking NET-dot-URI compatible library for handling
> URIs; db-sockets - db-sockets
>
> * Common Lisp
> p Support for using sockets through a proxy server is part of the
> package. ...
> Common Lisp socket-level interface to the PostgreSQL RDBMS. ...
> cbbrowne.com/info/commonlisp.html
>
> * Chris' Corman Lisp Collection
> A package that emulates some of the Allegro Common Lisp
> multiprocessing functionality. Requires the SOCKETS and MP packages.
> www.double.co.nz/cl/
>
> So I'd start by looking at those pages.
keriko <················@yahoo.es> writes:
> I always search lisp stockets, not common lisp socktes,
> so i had a bit more results.
Yeah, I guess it's always better to say "Common Lisp" (in quotes).
Otherwise, you'll get lots of Emacs stuff and other junk.
Follow those links and the other suggestions from this list, and look
around at where all that points you. After you have digested some of
the stuff, come back and give us a reading on what you think of it
It would be useful for people who are maintaining those web sites
to know how easy it is to find stuff (once you've gotten started).
Alexander Schreiber wrote:
> keriko <················@yahoo.es> wrote:
>
>>Hi,
>> I'm a begginer with this language. I run it under Linux and i want to know
>>if is possible to use sockets with it. Where can i find a tutorial or a
>>book about this?
>> Thanks
>
> Since sockets are, unfortunately, not part of the Common Lisp standard,
> each implementations handles them differently, but socket support is
> usually there. Grab the documentation/manual of your particular Lisp
> implementation and look into the appropriate sections.
I guess there's a tradeoff, isn't it?
Calling a POSIX-compliant sockets implementation through the UFFI layer costs
you performance, and using a vendor layer keeps you from being portable.
Or did I get wrong what UFFI is about? Is it a good solution?
With kind regards,
Oliver
> * Oliver Korpilla <·······@su-ynaqfuhg.qr> [2004-09-27 10:19:33 +0200]:
>
> Calling a POSIX-compliant sockets implementation through the UFFI
> layer costs you performance, and using a vendor layer keeps you from
> being portable.
Use CLOCC/PORT/net.lisp.
http://clocc.sf.net
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Bus error -- driver executed.
Oliver Korpilla wrote:
> Alexander Schreiber wrote:
>
>> keriko <················@yahoo.es> wrote:
>>
>>> Hi,
>>> I'm a begginer with this language. I run it under Linux and i want to
>>> know
>>> if is possible to use sockets with it. Where can i find a tutorial or a
>>> book about this?
>>> Thanks
>>
>>
>> Since sockets are, unfortunately, not part of the Common Lisp standard,
>> each implementations handles them differently, but socket support is
>> usually there. Grab the documentation/manual of your particular Lisp
>> implementation and look into the appropriate sections.
>
>
> I guess there's a tradeoff, isn't it?
>
> Calling a POSIX-compliant sockets implementation through the UFFI layer
> costs you performance, and using a vendor layer keeps you from being
> portable.
>
> Or did I get wrong what UFFI is about?
Yes. First of all, UFFI is mostly macrology, meaning it is not around at
run-time to effect performance at all. Second, even if UFFI were a thin
layer of runtime functions the performace cost would be negligible in
comparison to the socket performance itself.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Yes. First of all, UFFI is mostly macrology, meaning it is not around
> at run-time to effect performance at all. Second, even if UFFI were a
> thin layer of runtime functions the performace cost would be
> negligible in comparison to the socket performance itself.
>
> kenny
Kenny,
While I agree that UFFI is mostly macrology, using UFFI can have
substantial performance implications. For example, on CMUCL (as of
late September 2004), all UFFI calls to get a slot from a structure
translate down into CMUCL alien calls to get a slot from the
structure, where the type of the slot and structure are undeclared.
This causes each slot access to cons approximately 100 KB, as opposed
to consing nothing if the type were correctly declared. This is under
discussion currently (see the UFFI mailing list), but it is not
entirely trivial to fix --- because of some issues in how the API is
laid out, one cannot simply "just add type declarations" to the expansion.
I agree that an "ideal implementation" of UFFI would not have any of
these issues, and should be essentially as efficient as using (a
subset) of the implementations FFI, but the current UFFI isn't quite
there.
Cheers,
rif
rif wrote:
>>Yes. First of all, UFFI is mostly macrology, meaning it is not around
>>at run-time to effect performance at all. Second, even if UFFI were a
>>thin layer of runtime functions the performace cost would be
>>negligible in comparison to the socket performance itself.
>>
>>kenny
>
>
> Kenny,
>
> While I agree that UFFI is mostly macrology, using UFFI can have
> substantial performance implications. For example, on CMUCL (as of
> late September 2004), all UFFI calls to get a slot from a structure
> translate down into CMUCL alien calls to get a slot from the
> structure, where the type of the slot and structure are undeclared.
> This causes each slot access to cons approximately 100 KB, as opposed
> to consing nothing if the type were correctly declared. This is under
> discussion currently (see the UFFI mailing list)...
ok, i had a vague feeling i was missing some context. and now that you
mention it, i do recall this cmucl issue coming up before.
, but it is not
> entirely trivial to fix --- because of some issues in how the API is
> laid out, one cannot simply "just add type declarations" to the expansion.
>
> I agree that an "ideal implementation" of UFFI would not have any of
> these issues, and should be essentially as efficient as using (a
> subset) of the implementations FFI, but the current UFFI isn't quite
> there.
i do not follow the uffi list any more, but if cmucl requires
declarations other implementations do not, is the problem with uffi or
cmucl? i would hate to have to complicate all uffi coding just because
of limitations in one FFI implementation.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> i do not follow the uffi list any more, but if cmucl requires
> declarations other implementations do not, is the problem with uffi or
> cmucl? i would hate to have to complicate all uffi coding just because
> of limitations in one FFI implementation.
I find it difficult to say whether the problem is with UFFI or CMUCL,
although I lean towards thinking it should be fixed in UFFI. It's an
issue in how they interact.
Briefly, (uffi:get-slot-value *f* 'foo 'x) expands under CMUCL into
(alien:slot *f* 'x). The fact that *f* is of type (alien (* foo)) is
ignored by UFFI. The natural fix is to change the expansion of
alien:slot. However, this conflates with another issue, which is that
in UFFI, there is no way to specify that an object is of type (alien
foo) rather than (alien (* foo)). Because UFFI throws out the type
for CMUCL, and CMUCL will automatically dereference the pointer,
(uffi:get-slot-value *f* 'foo 'x) works whether *f* is an (alien foo)
OR an (alien (* foo)), but I think it only works in the former case
"by accident." There does not seem to be any way, according to the
documentation of UFFI, to access slots of objects of type (alien foo).
This comes up if (as I often do) one wants ot access nested
structures.
My suggested fix is to add some syntax to UFFI so that we can
distinguish the (alien foo) from the (alien (* foo)) case. Once this
was added, we could add the appropriate type declaration to each
expansion, and avoid consing.
One could alternately get a 98% fix from CMUCL. The inefficiency
comes from the fact that if the type is not known at compile time,
several functions are eval'd at runtime, and then funcall'd. If we
memoized these functions, we could get full efficiency on the second
and all subsequent calls to get a slot from an object of a given type.
We'd have to be a little careful if the foreign type got redefined.
This solution has the additional advantage that the user no longer has
to declare their types at all. The CMUCL implementors didn't seem in
favor of this approach when I mentioned it on the cmucl-devel list,
and suggested declaring the types instead, so I'll defer to that
wisdom.
rif
Kenny Tilton <·······@nyc.rr.com> writes:
> rif wrote:
>
> > I agree that an "ideal implementation" of UFFI would not have any of
> > these issues, and should be essentially as efficient as using (a
> > subset) of the implementations FFI, but the current UFFI isn't quite
> > there.
>
> i do not follow the uffi list any more, but if cmucl requires
> declarations other implementations do not, is the problem with uffi or
> cmucl? i would hate to have to complicate all uffi coding just because
> of limitations in one FFI implementation.
The problem is with UFFI -- it takes a somewhat different approach to
things that Alien, which means it's going to have to do more work to
generate efficient Alien code that for most FFIs. Unfortunately, it
seems to only do enough work to generate working Alien code. My guess
is there are very few CMUCL'ers and SBCL'ers who use UFFI, so no one
with the ability to fix UFFI for Alien has the motivation to do so.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > rif wrote:
> >
> > > I agree that an "ideal implementation" of UFFI would not have any of
> > > these issues, and should be essentially as efficient as using (a
> > > subset) of the implementations FFI, but the current UFFI isn't quite
> > > there.
> >
> > i do not follow the uffi list any more, but if cmucl requires
> > declarations other implementations do not, is the problem with uffi or
> > cmucl? i would hate to have to complicate all uffi coding just because
> > of limitations in one FFI implementation.
>
> The problem is with UFFI -- it takes a somewhat different approach to
> things that Alien, which means it's going to have to do more work to
> generate efficient Alien code that for most FFIs. Unfortunately, it
> seems to only do enough work to generate working Alien code. My guess
> is there are very few CMUCL'ers and SBCL'ers who use UFFI, so no one
> with the ability to fix UFFI for Alien has the motivation to do so.
Upon further reflection, I agree it's pretty much a UFFI problem. But
it's not just an efficiency issue. The spec for UFFI seems to me to
be incorrect, in that there is no semantically correct way to use UFFI
to deal with nested structures. If the spec were correct, it would
likely be quite easy (we're talking a couple of one line changes for
someone moderately knowledgeable --- heck, even I could do them) to
make it efficient under CMUCL.
rif
rif wrote:
> Upon further reflection, I agree it's pretty much a UFFI problem. But
> it's not just an efficiency issue. The spec for UFFI seems to me to
> be incorrect, in that there is no semantically correct way to use UFFI
> to deal with nested structures. If the spec were correct, it would
> likely be quite easy (we're talking a couple of one line changes for
> someone moderately knowledgeable --- heck, even I could do them)...
I be puzzled. What is holding you or anyone else back? Is this not why
we have open source? LTk uses pipes to talk to Tk because UFFI does not
support callbacks from C. My UFFI does -- I Just Added It(tm). For it
go, I say. I just whack at open source as if it were my own code, which
is a PITA when I grab the latest official version. :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> rif wrote:
> > Upon further reflection, I agree it's pretty much a UFFI problem. But
> > it's not just an efficiency issue. The spec for UFFI seems to me to
> > be incorrect, in that there is no semantically correct way to use UFFI
> > to deal with nested structures. If the spec were correct, it would
> > likely be quite easy (we're talking a couple of one line changes for
> > someone moderately knowledgeable --- heck, even I could do them)...
>
> I be puzzled. What is holding you or anyone else back? Is this not why
> we have open source? LTk uses pipes to talk to Tk because UFFI does
> not support callbacks from C. My UFFI does -- I Just Added It(tm). For
> it go, I say. I just whack at open source as if it were my own code,
> which is a PITA when I grab the latest official version. :)
I pretty much only use CMUCL (and SBCL a little bit). Currently, I
have one program that uses UFFI and depends crucially on it being
efficient. For this program, I have a solution in place that's a
combination of a slight modification of UFFI (done within the program)
and using the CMUCL FFI directly. So my program works for me, now,
which takes a lot of the urgency out.
I have posted about the issue on the UFFI mailing list, and I'm hoping
it will eventually be resolved; internally I have a solution that
works for me. I'm not interested in forking UFFI over this,
especially because it's quite possible that there are issues with
other CLs that UFFI supports that make my solution bogus, and I don't
currently have the time available to properly understand all the FFIs.
Your point is well taken, however.
Cheers,
rif
················@yahoo.es writes:
> Hi,
> I'm a begginer with this language. I run it under Linux and i want to know
> if is possible to use sockets with it. Where can i find a tutorial or a
> book about this?
> Thanks
>
Hi, maybe you can have a look to the clocc port:
http://clocc.sourceforge.net/dist/port.html
especially net.lisp for sockets over severals common lisp
implementations.
Philippe
--
Philippe Brochard <········@SPAM_free.fr>
http://hocwp.free.fr
-=-= http://www.gnu.org/home.fr.html =-=-
In article <·······················@news-reader.eresmas.com>, keriko wrote:
> Hi,
> I'm a begginer with this language. I run it under Linux and i want to know
> if is possible to use sockets with it. Where can i find a tutorial or a
> book about this?
> Thanks
http://cl-cookbook.sourceforge.net/sockets.html
Used library supports all lisp implementations on linux I know.
Differences between implementations are really stupid - who for hell create
for nearly every implementation different name for same function !!!
Jan
Jan Gregor <··········@NOSPAMquick.cz> writes:
> Differences between implementations are really stupid - who for hell create
> for nearly every implementation different name for same function !!!
It would be a bad idea to give them the same name when they usually
have different semantics
-dan
--
"please make sure that the person is your friend before you confirm"
In article <··············@noetbook.telent.net>, Daniel Barlow wrote:
> Jan Gregor <··········@NOSPAMquick.cz> writes:
>
>> Differences between implementations are really stupid - who for hell create
>> for nearly every implementation different name for same function !!!
>
> It would be a bad idea to give them the same name when they usually
> have different semantics
>
>
> -dan
>
Agree. But why are there differences ?
Jan Gregor <··········@NOSPAMquick.cz> writes:
> In article <··············@noetbook.telent.net>, Daniel Barlow wrote:
> > Jan Gregor <··········@NOSPAMquick.cz> writes:
> >
> >> Differences between implementations are really stupid - who for hell create
> >> for nearly every implementation different name for same function !!!
> >
> > It would be a bad idea to give them the same name when they usually
> > have different semantics
> >
> >
> > -dan
> >
>
> Agree. But why are there differences ?
Because they're running on different operating systems?