Its the age of the internet! A quick web search said yes it does. Done in
the ORB. I assume LispWorks CORBA supports that.
Sorry for wasting your time.
Wade
>>>>> "wade" == Wade Humeniuk <········@cadvision.com> writes:
wade> Its the age of the internet! A quick web search said yes it
wade> does. Done in the ORB. I assume LispWorks CORBA supports
wade> that.
I don't think I've ever seen any indication that LW's Corba
implementation supports encryption. But of course, you can encrypt
stuff using ssh and port forwarding. If you are interested, then do:
% man ssh
check out the -L and -g options.
It's not trivial, but it's doable.
dave
>>>>> "db" == David Bakhash <·····@alum.mit.edu> writes:
db> I don't think I've ever seen any indication that LW's Corba
db> implementation supports encryption. But of course, you can encrypt
db> stuff using ssh and port forwarding.
that won't work in general: for example if you use an iterator you
will receive a new object reference on a new, dynamically assigned,
unforwarded port. Same situation if you use callbacks.
Several ORBs support SSLIOP, where authentication and encryption are
provided by SSL. ObLisp: SSL streams would be nice to have in CL.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
>>>>>> "db" == David Bakhash <·····@alum.mit.edu> writes:
>
> db> I don't think I've ever seen any indication that LW's Corba
> db> implementation supports encryption. But of course, you can encrypt
> db> stuff using ssh and port forwarding.
>
> that won't work in general: for example if you use an iterator you
> will receive a new object reference on a new, dynamically assigned,
> unforwarded port. Same situation if you use callbacks.
>
> Several ORBs support SSLIOP, where authentication and encryption are
> provided by SSL. ObLisp: SSL streams would be nice to have in CL.
This is what Wade at least meant. Wade and I talked a bit on his idea to
build a "pure" CL implementation of the SSL protocol. (He has already done
some work - so IMHO I think it is not a good idea to bash him that he only
complains and is not willing to help!!!)
I've done some work writing a LispWorks binding to OpenSSL.
I would be happy if at least a CLISPer and a CMUCLer would join the effort.
My proposal would be to do the streams stuff in portable Gray-Streams code
and the buffering in mostly portable CL. So the implementation-dependend
stuff will be mainly restricted on the socket-interface (at least getting a
fd) and the foreign-functions (not many and not difficult).
I personally would like to see a Allegro Socket API compatible API for the
sockets, as this API is slim nice and already supports SSL. I wish we could
replace the CLOCC-Port NET stuff with that. (It is already rather similar
to the ACL interface).
To the topic of using Gray Streams - I know that they are probably not
perfect and Franz' Simple Streams are probably a better solution. But
Gray-Streams are widely accepted and implemented and residing in a kind of
"Status Quo" will hurt Common Lisp more than a later change to Simple
Streams.
CLOCC-Port NET should be not a hack to combine what all have in common but
it should support all features available. It is IMHO better if e. g. SSL is
in the beginnings probably only supported by ACL, Corman and LW because a
defined standard API will force the others to implement this too ASAP.
Please - All people that don't like the way the actual CLOCC Port is done
or has another opinion on doing the SSL stuff I described above - STAND UP,
rise your hands - I *want* to discuss this so that we can find a solution
that does not split the comunity like in the past. NOW all people have the
chance to _say_ how the future comunity-standard Socket API should look
like!
Talking on comunity I think we should try to work a bit more together
I have by myself spent alot of my spare-time creating stuff that I thought
would be needed in the comunity. One of the reasons I've done it was trying
to trigger some more activities. It is incredible difficult to convince
people that e. g. an AServe port to CMUCL and/or CLISP could be already
there if someone would stand up and would try to help a little bit.. I
mainly use LispWorks so if I port that thing to CMUCL or CLISP this would
have not much immediate gain for me. I _want_ it because I think this would
be a good thing for the comunity.
I _need_ SSL-sockets for LispWorks and I try to create them for me - I
would not _need_ SSL-sockets in CLISP or CMUCL but the comunity needs them.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Eric Marsden wrote:
>
> >>>>>> "db" == David Bakhash <·····@alum.mit.edu> writes:
> >
> > db> I don't think I've ever seen any indication that LW's Corba
> > db> implementation supports encryption. But of course, you can encrypt
> > db> stuff using ssh and port forwarding.
> >
> > that won't work in general: for example if you use an iterator you
> > will receive a new object reference on a new, dynamically assigned,
> > unforwarded port. Same situation if you use callbacks.
> >
> > Several ORBs support SSLIOP, where authentication and encryption are
> > provided by SSL. ObLisp: SSL streams would be nice to have in CL.
>
> [snip]
>
> Please - All people that don't like the way the actual CLOCC Port is done
> or has another opinion on doing the SSL stuff I described above - STAND UP,
> rise your hands - I *want* to discuss this so that we can find a solution
> that does not split the comunity like in the past. NOW all people have the
> chance to _say_ how the future comunity-standard Socket API should look
> like!
Can I suggest that you post a careful proposal? Then people at least
will probably be clear on what you are trying to achieve, and will
doubtless be able to offer helpful advice. At the moment, speaking for
myself, I don't feel I can say anything as I have absolutely no idea
what you're aiming for.
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes wrote:
> Can I suggest that you post a careful proposal? Then people at least
> will probably be clear on what you are trying to achieve, and will
> doubtless be able to offer helpful advice. At the moment, speaking for
> myself, I don't feel I can say anything as I have absolutely no idea
> what you're aiming for.
Hm...
what do I aim for....?
Didn't I say it? I'm over to build a SSL-binding for LispWorks. I offer
_my_ help to those who want a SSL-binding for their Lisp-System too.
AFAIK the remaining Lispsystems are CMUCL, CLISP and MCL. I'm
rather busy and therefore I'm not able to produce a binding for all those
Environments. I suppose there are people using those environments that have
the capability to write foreign-bindings (at least simple ones) and know how
to open a socket and get the fd in their Lisp (or are able to find out).
I see this as a chance that we can combine this effort to create a clean
and common Socket-API (probably based on CLOCC-Port NET).
As the chances of a common socket-API are higher if more people like it I
want to encourage the people here in c.l.l what they like or dislike on the
exising APIs and how the best API could look like.
Regards,
Jochen
Hi,
It is my opinion that ACL has the most comfortable socket API. Given
that SSL is highly important to today's programmers, it wouldn't be
such a bad idea to just ask Xanalys to implement SSL sockets. In the
meantime, it also seems that many people (including myself) want a
more low-level socket interface, though not as low-level necessarily
as the CMUCL one I've seen (which might as well be written in C).
In general, though Xanalys has a lot on their plate right now, I'm
sure that they'd at least consider implementing SSL and providing an
ACL-like interface to sockets (maybe even more well thought-out).
I think that, at some point, I'll also have to ask them for SSL, since
it would be useful for me as well.
dave
"David Bakhash" <·····@alum.mit.edu> wrote in message ···················@alum.mit.edu...
> <SNIP>
> In general, though Xanalys has a lot on their plate right now,
Dave - why do you say that? LispWorks is the implementation I use so I'm interested
on any insight you might have on Xanalys. Are these good things on their plate, or bad
things? Just curious, and concerned about their wellbeing since I do like LispWorks.
Julian
hey,
julian> "David Bakhash" <·····@alum.mit.edu> wrote in message
julian> ···················@alum.mit.edu... >> <SNIP> >> In general,
julian> though Xanalys has a lot on their plate right now,
julian> Dave - why do you say that? LispWorks is the implementation I
julian> use so I'm interested on any insight you might have on
julian> Xanalys. Are these good things on their plate, or bad things?
julian> Just curious, and concerned about their wellbeing since I do
julian> like LispWorks.
I'm just aware of some of the important enhancements that are coming
soon, such as the Linux ODBC support. This is only one major
enhancement. They also have many clients, like me, and maintaining
clients, fixing bugs, adding private patches, etc. is a lot of work.
The things I want from Xanalys are pretty simple. I'm not too
concerned about them. They are:
1) regexp support (which they already have somewhere in their editor
code)
2) ODBC support on Linux
3) lower-level socket interface
I have temporary solutions for all these things, so I'm not too
worried. This company has come through for me and others I've worked
with for several years, and so at this point I have complete faith in
them. In fact, I was working with them right through the
Harlequin->Xanalys thing, and things only seemed to get better.
dave
David Bakhash wrote:
> hey,
>
> julian> "David Bakhash" <·····@alum.mit.edu> wrote in message
> julian> ···················@alum.mit.edu... >> <SNIP> >> In general,
> julian> though Xanalys has a lot on their plate right now,
>
> julian> Dave - why do you say that? LispWorks is the implementation I
> julian> use so I'm interested on any insight you might have on
> julian> Xanalys. Are these good things on their plate, or bad things?
> julian> Just curious, and concerned about their wellbeing since I do
> julian> like LispWorks.
>
> I'm just aware of some of the important enhancements that are coming
> soon, such as the Linux ODBC support. This is only one major
> enhancement. They also have many clients, like me, and maintaining
> clients, fixing bugs, adding private patches, etc. is a lot of work.
>
> The things I want from Xanalys are pretty simple. I'm not too
> concerned about them. They are:
>
> 1) regexp support (which they already have somewhere in their editor
> code)
It is maybe here, but having regexp support as an editor search-tool and
as a tool for writing efficient parsers is something different - This does
not mean that the editor-regexp support in LispWorks lacks this - but it is
maybe a reason why it is not in LispWorks as a parsing tool.
For your interest I've written a implementation of the regexp-Test of
Bagley's Language Shootout page using the META parsing techinque described
by Baker. The code is on the third place (after MLTON and BIGLOO). It is
faster than Perl, MAWK or all the languages that used PCRE.
If you want to use this META parsing technique with LispWorks then you
should replace the TYPEP stuff with something other. CMUCLs TYPEP (using
MEMBER typespecs) is *lightning* fast - alot faster than using bitvectors
or CASE forms for representing char-sets.
Btw.: In the meantime all tests available are implemented for CMUCL and if
you look at http://www.bagley.org/~doug/shootout/craps.shtml you will see
that CMUCL is now at the 5th place (of 28 languages, C++ is on place 4) of
the CPU Score table and on the third place (after OCAML and OCAMLB) on the
CPU and LOC Score table.
Some tests e.g. the "Spell Checker" test needs a better implementation
(CMUCL is on place 17 - much slower than Java or python!)
I know that this benchmarks have little real-world value - but they at
least show which parts of an particular *implementation* of a language could
be optimized. I think CMUCLs hashtables could need some optimization but I
don't know if this is fair (and correct) to say.
> 2) ODBC support on Linux
Is there something wrong with SQL-ODBC, UncommonSQL or the combination of
both? Yes vendor-support of this things would be nice but since there are
working solutions this is IMHO not so important...
> 3) lower-level socket interface
I would like to see SSL-Sockets and UDP sockets and chunking support. As
ACL is the only Lisp that supports that all I would wish if they would use
ACL's API for that and would not invent a new one.
I've written a mail to Xanalys support-team on this topic today.
Regards,
Jochen
>>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
[...]
JS> Btw.: In the meantime all tests available are implemented for
JS> CMUCL and if you look at
JS> http://www.bagley.org/~doug/shootout/craps.shtml you will see
JS> that CMUCL is now at the 5th place (of 28 languages, C++ is on
JS> place 4) of the CPU Score table and on the third place (after
JS> OCAML and OCAMLB) on the CPU and LOC Score table. Some tests
JS> e.g. the "Spell Checker" test needs a better implementation
JS> (CMUCL is on place 17 - much slower than Java or python!)
[...]
Having submitted code to the shootout, I'd like to point several
things out:
-- Dound Bagley makes NO effort to and discourages people from
attributing any serious semantics to the score table. Take it
at PR value -- not seriously (read the fine print to see why).
This is partly why he calls it CRAPS.
-- Some of the benchmarks where CMUCL does badly require line oriented
IO, and Doug insists something like read-line be used. I have
submitted several as-fast-as-C solutions but couldn't get any in.
Don't waste effort unless you can magically make read-line not cons up
a new string every time.
-- I have a quick and messy hack in there for the moments benchmark.
Someone with more motivation should clean that up and maybe
implement the linear time median algorithm (DB said he'd allow it).
JS> I know that this benchmarks have little real-world value - but
JS> they at least show which parts of an particular
JS> *implementation* of a language could be optimized. I think
JS> CMUCLs hashtables could need some optimization but I don't
JS> know if this is fair (and correct) to say.
I'd like to hear ideas on this also. It seems that one way to
enabling more efficient hash tables would be telling makehash
what type the keys would be and perhaps providing the test
predicate.
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
> [...]
> JS> Btw.: In the meantime all tests available are implemented for
> JS> CMUCL and if you look at
> JS> http://www.bagley.org/~doug/shootout/craps.shtml you will see
> JS> that CMUCL is now at the 5th place (of 28 languages, C++ is on
> JS> place 4) of the CPU Score table and on the third place (after
> JS> OCAML and OCAMLB) on the CPU and LOC Score table. Some tests
> JS> e.g. the "Spell Checker" test needs a better implementation
> JS> (CMUCL is on place 17 - much slower than Java or python!)
> [...]
>
> Having submitted code to the shootout, I'd like to point several
> things out:
>
> -- Dound Bagley makes NO effort to and discourages people from
> attributing any serious semantics to the score table. Take it
> at PR value -- not seriously (read the fine print to see why).
> This is partly why he calls it CRAPS.
Yes this is what I tried to say with "no real-world value".
As I first saw this benchmark site I thought "what a bull#%$"
but after thinking a while on it I realized that this site encourages the
people to try out how to make things fast in a particular or
language/implementation. And for CMUCL it shows that Lisp can be comparable
to "fast" languages like C++ or C while "compactness of code" is retained.
There are at least some tests in at which the CMUCL code is alot faster
than the C++ examples:
e.g the
Exceptions Test: CMUCL 40x faster than g++
Count Words Test: CMUCL 4x faster than g++
Yes the reason why C++ is in some tests (like the Count words Test) slower
is simply because the test is badly implemented - but in real life there is
a lot of code written bad and this shows only that speed is mostly a matter
of knowledge and capabilities of the programmer and not of particular
languages.
> -- Some of the benchmarks where CMUCL does badly require line oriented
> IO, and Doug insists something like read-line be used. I have
> submitted several as-fast-as-C solutions but couldn't get any in.
> Don't waste effort unless you can magically make read-line not cons up
> a new string every time.
None of my code was refused so far (Matrix Multiplication, Producer
Consumer Threads, Hashtable I, Regular Expressions)...
I don't think he insists on language inbuilt constructs - if you implement a
FAST-READLINE that reuses it's buffer I'm sure he will accept it.
For the Matrix-Multiplication test I implemented the multidimensional arrays
by using a 1-dimensional simple-array - this gave me a 5 fold speed up for
this test! For the hash-table I test I implemented a simple fixnum->string
converter that is *alot* faster than using a generic READ-FROM-STRING.
The regexp Test uses META instead of "real" regexps like PCRE.
> -- I have a quick and messy hack in there for the moments benchmark.
> Someone with more motivation should clean that up and maybe
> implement the linear time median algorithm (DB said he'd allow it).
The actual code is from you and is quite fast IMHO but if CMUCL will reach
1st place in this test... ;-)
I'm sure it is doable to come before C++ if some of the tests get some
work...
> JS> I know that this benchmarks have little real-world value - but
> JS> they at least show which parts of an particular
> JS> *implementation* of a language could be optimized. I think
> JS> CMUCLs hashtables could need some optimization but I don't
> JS> know if this is fair (and correct) to say.
>
> I'd like to hear ideas on this also. It seems that one way to
> enabling more efficient hash tables would be telling makehash
> what type the keys would be and perhaps providing the test
> predicate.
The problem is maybe that Common Lisps Hashtables are so generic - most
languages allow only strings for their hashtables and can therefore offer
quite alot optimization here.
ciao,
Jochen
>>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
[...]
JS> Yes this is what I tried to say with "no real-world value".
JS> As I first saw this benchmark site I thought "what a bull#%$"
JS> but after thinking a while on it I realized that this site
JS> encourages the people to try out how to make things fast in a
JS> particular or language/implementation.
Exactly my thoughts. I don't think the benchmark set is "serious"
with some appropriate meaning of the scare quotes, but it certainly
leverages whatever obsessive traits you have to make you understand
your compiler.
JS> [...] Yes the reason why C++ is in some tests (like the Count words
JS> Test) slower is simply because the test is badly implemented -
JS> but in real life there is a lot of code written bad and this
JS> shows only that speed is mostly a matter of knowledge and
JS> capabilities of the programmer and not of particular
JS> languages.
I agree for _some_ languages. With something like Tcl, you're basically
sunk if your code's slow and have to punt to C. With CMUCL you can
generally stay within Lisp and write your C code there. This is not
a bad thing, because you can then turn your c-ish Lisp into a macro
and hide it.
[...]
JS> None of my code was refused so far (Matrix Multiplication,
JS> Producer Consumer Threads, Hashtable I, Regular
JS> Expressions)... I don't think he insists on language inbuilt
JS> constructs - if you implement a FAST-READLINE that reuses it's
JS> buffer I'm sure he will accept it.
Nope. Any fast readline I come up with ends up either doing char-by-char
reads or scanning for #\newline in a read-sequence'ed buffer. Once you
know the performance is there, you can wrap up the ugliness of keeping
a global buffer into a with-mumble macro that binds the buffer reader
function and everything end up looking clean. Amazing how much faster
these go actually, but despite e-pestering him I couldn't sway his opinion
yet. I think you had better luck because you didn't break any rules
that he explicitly stated. I kinda understand why he wants to stay with
built-ins, the reason why I posted the warning was to prevent someone from
wasting time on a sumbission that'll be rejected. I just happened to have
some lisp code that I used to scan multi-gig log files so it wasn't
a big waste for me when I found out about the read-line requirement.
JS> [...] The actual code is from you and is quite fast IMHO but if
JS> CMUCL will reach 1st place in this test... ;-) I'm sure it is
JS> doable to come before C++ if some of the tests get some
JS> work...
Yes, but you have to understand that I am cheating some. I have a fast
float reader there that does not handle errors (we're going agains
atof though), I also stuck the sort function in the same file so
everything is available to CMUCL to do its work with optimizations.
You can probably get some additional speed-ups by doing signed byte
arithmetic. But what would make it the fastest would be the O(n)
median.
If you want to monkey around with the programs, also take a peek at sieve.
When you use fixnums for flags, it spills over to the L2 cache on Doug's
machine and slows down (he's using a P-II). If you can get bit vectors
to go fast OR are able to aref byte arrays without the shift involved
in fixnum untagging, you can get the speed very close to C's. I
couldn't get that to go my way when I tried it.
[on hash tables]
JS> The problem is maybe that Common Lisps Hashtables are so
JS> generic - most languages allow only strings for their
JS> hashtables and can therefore offer quite alot optimization
JS> here.
I agree. Our arrays are generic too but we can make them fast
by declarations and such. There's no such facility for hash tables.
I suspect one could roll their own hashtable extension with some
internal compiler transforms reasonably easily in CMUCL, but the
peek I took into the compiler source was insufficient for me to
judge how much work would really be entailed.
cheers,
BM
Jochen Schmidt <···@dataheaven.de> writes:
> None of my code was refused so far (Matrix Multiplication, Producer
> Consumer Threads, Hashtable I, Regular Expressions)...
> I don't think he insists on language inbuilt constructs - if you implement a
> FAST-READLINE that reuses it's buffer I'm sure he will accept it.
I added just a few implementations and if you believe it or not at
least in Eiffel I could found not a bug but a flaw in the design of
how a feature was implemented. What I like about this page is that one
can play with different languages and one can send him his
suggestions. And they are usually incluced. At least mine were all.
What I suggested that he might check how sensitive the different
solutions are. on the CRAPS site you can give weights to thinks you
think are important. Play with it and you'll see what happens.
What I would like to see are more and more tests, so if you have one
on your mind why don't you give it a try. He warns to take all this
things to seriously, but at least you can see the different
solutions, and I find it at least interesting enough to spend some
time with it. If some more do that, now I'm sure we'll see a lot of
more tests, and suddenly that are serious results, because if the
sheer mass of solutions.
Another adding I would find very useful is implementation time. I
don't say that speed does not matter, but IMHO much less than ever
before. At least on the desktop we do not have to care so much, on how
"efficient" it is. Often getting things done is more important than to
get them run fast. I do not have the latest figures, but I do think
that the costs from a Solution are getting more and more ruled by the
development effort read human work. I guess in the 70s the percantage
HW - SW was maybe 80:20 whereas it is today aroiund 10:90 (a guess) or
even more lending towards SW. Does anyone has some better figures?
>
> The problem is maybe that Common Lisps Hashtables are so generic - most
> languages allow only strings for their hashtables and can therefore offer
> quite alot optimization here.
I think this has changed a lot with OO-languages. Just some example in
Eiffel any object can be the key if it is has an hash-code
implementation. Now if you look into the header of a Hash Table
implementation you'll find
HASH_TABLE[G,K->HASHABLE] which is as generic as can be. Of course G
have to be one type...
Regards
Friedrich
David Bakhash <·····@alum.mit.edu> writes:
> It is my opinion that ACL has the most comfortable socket API. Given
> that SSL is highly important to today's programmers, it wouldn't be
> such a bad idea to just ask Xanalys to implement SSL sockets. In the
> meantime, it also seems that many people (including myself) want a
> more low-level socket interface, though not as low-level necessarily
> as the CMUCL one I've seen (which might as well be written in C).
I don't think you mean CMU CL's sockets, but Dan Barlow's socket
interface, which works both in CMU CL and SBCL (where its the only
interface). IIRC being as low-level as the BSD socket API itself was
one of the design goals of that interface.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> I don't think you mean CMU CL's sockets, but Dan Barlow's socket
> interface, which works both in CMU CL and SBCL (where its the only
> interface). IIRC being as low-level as the BSD socket API itself was
> one of the design goals of that interface.
Pretty much, yes. The reasoning is that it's hard to predict what the
user may want to do, so let's cop out and just give him the tools to
build the API he wants. I'm still not sure what a "high level"
sockets API should look like, though I suspect that a
"with-open-socket" macro would be a good place to start.
Incidentally, db-sockets is actually not any more the only socket
support for SBCL: Martin Atzmueller has created NET-SBCL-SOCKETS,
which is based on CMUCLs interface. So, you have a choice. Ain't
life grand?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
>>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
Daniel> Pretty much, yes. The reasoning is that it's hard to predict what the
Daniel> user may want to do, so let's cop out and just give him the tools to
Daniel> build the API he wants. I'm still not sure what a "high level"
Daniel> sockets API should look like, though I suspect that a
Daniel> "with-open-socket" macro would be a good place to start.
One problem with higher level socket interfaces are that they are at
risk of focusing too narrowly on the wellknown socket types (ie. UNIX,
TCP and UDP). The ACL socket API has this problem whereas the socket
interface in something like Guile Scheme (I do not know the CMUCL
ones) allows you the full flexibility of the classic C API.
So IMHO, a socket API should provide the necessary hooks to allow the
specification of both address family and socket type.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
>
> Daniel> Pretty much, yes. The reasoning is that it's hard to predict what the
> Daniel> user may want to do, so let's cop out and just give him the tools to
> Daniel> build the API he wants. I'm still not sure what a "high level"
> Daniel> sockets API should look like, though I suspect that a
> Daniel> "with-open-socket" macro would be a good place to start.
>
> One problem with higher level socket interfaces are that they are at
> risk of focusing too narrowly on the wellknown socket types (ie. UNIX,
> TCP and UDP). The ACL socket API has this problem whereas the socket
> interface in something like Guile Scheme (I do not know the CMUCL
> ones) allows you the full flexibility of the classic C API.
>
> So IMHO, a socket API should provide the necessary hooks to allow the
> specification of both address family and socket type.
TLI was/is a sort of reasonable higher level api- although its still
"socket-like" it seems to interoperate with varying protocols without
too much pain- at least for simpler things. I used it for SPX
communications between DOS machines some time ago, presumably the
tcp/ip bindings are a reasonable match.
Gregm
hey
>> meantime, it also seems that many people (including myself) want a
>> more low-level socket interface, though not as low-level
>> necessarily as the CMUCL...
pierre> I don't think you mean CMU CL's sockets, but Dan Barlow's
pierre> socket interface, which works both in CMU CL and SBCL (where
pierre> its the only interface). IIRC being as low-level as the BSD
pierre> socket API itself was one of the design goals of that
pierre> interface.
thanks for that correction. That's right.
dave
David Bakhash <·····@alum.mit.edu> writes:
> hey
>
> >> meantime, it also seems that many people (including myself) want a
> >> more low-level socket interface, though not as low-level
> >> necessarily as the CMUCL...
>
> pierre> I don't think you mean CMU CL's sockets, but Dan Barlow's
> pierre> socket interface, which works both in CMU CL and SBCL (where
> pierre> its the only interface). IIRC being as low-level as the BSD
> pierre> socket API itself was one of the design goals of that
> pierre> interface.
>
> thanks for that correction. That's right.
It's not *entirely* right - SBCL has another socket library
written by Martin Atzmueller, and also had a "port" of the CMUCL
socket library for a while.
--
Raymond Wiker
·············@fast.no
Raymond Wiker <·············@fast.no> writes:
> It's not *entirely* right - SBCL has another socket library
> written by Martin Atzmueller, and also had a "port" of the CMUCL
> socket library for a while.
Oops, I missed that development...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Jochen Schmidt <···@dataheaven.de> writes:
> To the topic of using Gray Streams - I know that they are probably not
> perfect and Franz' Simple Streams are probably a better solution. But
> Gray-Streams are widely accepted and implemented and residing in a kind of
> "Status Quo" will hurt Common Lisp more than a later change to Simple
> Streams.
Of course, I would tend to be be prejudiced :-) but I also would like
to see other implementations of simple-streams spring up soon. I
published the first draft of the spec early last year, and although
there have been some improvements to it, it is largely unchanged in
concept. The current version of the spec is in fact our 6.0 streams
document: http://www.franz.com/support/documentation/6.0/doc/streams.htm,
and I would still be happy if other vendors or volunteers would create
implementations on their platforms - I have had a couple of queries
along those lines, but I am not sure if any progress has been made by
any of those who inquired. The spec that the document describes has
always been and still is available for public use and implementation.
And if anyone has improvements, we would of course be interested in
hearing those ideas as well.
We actually incorporated Gray Streams into our lisp circa 1990/1991.
I don't know if any other CL implementations had them back then, and
I believe that Gray Streams has only taken hold in other implementations
in the last couple of years. Unfortunately (or fortunately) we have
had all those preliminary years to discover the idiosyncrasies and
outright problems that Gray streams offer, not the least of which is
a performance wall which is very hard to climb over or to get around.
The document cited above describes some of the semantic problems.
Finally, although we now encourage the use of simple-streams, Gray
Streams are still available in Allegro CL on an autoload basis and
back compatibility is fairly carefully maintained. Other vendors
should be able to do the same, so there should be very little
adjustment needed by the CL user community, even for those who
specialize their Gray streams classes.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: David Bakhash
Subject: Re: Streams design (was: CORBA and Encryption)
Date:
Message-ID: <m3y9qsmbxt.fsf@alum.mit.edu>
>>>>> "duane" == Duane Rettig <·····@franz.com> writes:
duane> Of course, I would tend to be be prejudiced :-) but I also
duane> would like to see other implementations of simple-streams
duane> spring up soon. I published the first draft of the spec early
duane> last year, and although there have been some improvements to
duane> it, it is largely unchanged in concept.
It's definitely nice to see some new thought going into Lisp streams,
to see a spec being published for the rest of the community, and I
certainly recognize the problems that simple-streams try to solve.
But I still prefer Gray streams. Call me crazy.
dave
hey,
db> I don't think I've ever seen any indication that LW's Corba
db> implementation supports encryption. But of course, you can
db> encrypt stuff using ssh and port forwarding.
eric> that won't work in general: for example if you use an iterator
eric> you will receive a new object reference on a new, dynamically
eric> assigned, unforwarded port. Same situation if you use
eric> callbacks.
wow. didn't know about this stuff. That's a shame.
eric> Several ORBs support SSLIOP, where authentication and
eric> encryption are provided by SSL. ObLisp: SSL streams would be
eric> nice to have in CL.
If anyone knows about how to do this with LispWorks, then please do
write about it.
dave