I've recently started thinking about a fairly large web application.
So far, I'm familiar with doing this in C++ and in Perl. I was
talking with a friend who does this kind of stuff using JSP for all
the presentation and formatting of the HTML pages and Java
serverlettes for the backend computation. He's doing it all with the
Tomcat server. This type of design is appealing to me. I like the
seperation of controller from the view. I also like the idea of being
able to chain serverlettes.
Meanwhile you guys are wondering why I'm posting all this to c.l.l.
I've been doing a lot of reading on lisp for the past several months.
I have a little experience writing elisp for my daily emacs usage but
that's about it. I hear of all kinds of advantages of lisp. Then I
come across Erann Gat's study, "Lisp as an Alternative to Java"[1].
Also, Paul Graham's article, "Beating the Averages"[2], about using
lisp for web stuff. This and other stuff I've read make me want to
try this new project in lisp instead of Java.
The downside is that Java is well established in this arena and may
have really been designed for it. While I'm not really concerned with
herd mentality, it does mean lots of tools tailored to the task and
common parts of the problem space already solved.
Also, I remember a thread here not too far back talking about doing
HTML in Lisp[3]. There didn't seem to be much concensus. Some said
python was better for the task than lisp; others said no.
What I'm wanting to find (but haven't) is some repository of tips and
trick for doing HTML from CL. Is there an HTML framework already?
Paul Graham said he used Lisp for his web project. Are others? Is
everyone rolling their own from scratch?
[1] http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
[2] http://www.paulgraham.com/avg.html
[3] http://groups.google.com/groups?hl=en&safe=off&th=c3f14153a37c0212,13&start=0
--
(__) Doug Alcorn (···········@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
> What I'm wanting to find (but haven't) is some repository of tips and
> trick for doing HTML from CL. Is there an HTML framework already?
> Paul Graham said he used Lisp for his web project. Are others? Is
> everyone rolling their own from scratch?
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
is a webserver written in CL & includes a suite of functions related
to generating html. Though its undoubtably a oversimplistic (and
presumably fairly poorly designed) example, I have clhttp running on
my machine at work, a couple of the pages are dynamically created by
Lisp code;
http://posixfswdev1.gsfc.nasa.gov:8000
Gregm
Greg Menke <··········@mindspring.com> writes:
> > What I'm wanting to find (but haven't) is some repository of tips and
> > trick for doing HTML from CL. Is there an HTML framework already?
> > Paul Graham said he used Lisp for his web project. Are others? Is
> > everyone rolling their own from scratch?
>
>
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
>
> is a webserver written in CL & includes a suite of functions related
> to generating html.
I had seen this earlier but didn't really grok it. Do I understand
this is similar to Tomcat for Java or Zope for python? Basically, you
let apache handle port 80, but run cl-http on a different port to
handle a specific application? Then you write cl functions to handle
the various requests?
--
(__) Doug Alcorn (···········@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
Greg Menke <··········@mindspring.com> writes:
> > What I'm wanting to find (but haven't) is some repository of tips and
> > trick for doing HTML from CL. Is there an HTML framework already?
> > Paul Graham said he used Lisp for his web project. Are others? Is
> > everyone rolling their own from scratch?
I think the original posted pointed out a important issue: the lack of
basic level information on how to write CGI applications in
Lisp.
A good hub for WWW/Lisp pointers is:
http://ww.telent.net/cliki/Web
Unfortunately even there you cannot find clear information on how to
write a Lisp/CGI application. Of the topics listed there
* AlegroServe, Araneida, HTTP.LSP are all on the cl-httpd line: a WWW
server written in Lisp
* Clikki is itself an Araneida application
* I like Le Sursis which is 2 modules: a http generator and a CGI
layer which unfortunately only deals with GETs (not PUTs)
I was planning on adding the PUT method to it one of these days, but
I think the Lisp community would be better served if a better
programmer would do that.
And that is all I found: I could not find neither a complete package,
nor a tutorial on how to write cgi applications in Lisp. (actually
lispweb is a mailing list on WWW/Lisp but they have no search feature
on their archives :-(
cheers
jacques
Jacques Wainer <······@dcc.unicamp.br> writes:
> Unfortunately even there you cannot find clear information on how to
> write a Lisp/CGI application. Of the topics listed there
This is not very surprising really:
1) Most Lisp implementations are not optimized for startup time, which
makes CGI slow
2) The preferred way to develop in Lisp is interactively in a
persistent Lisp image. This fits badly with the
one-process-per-request CGI model too
If you can allocate some time to learning how to use any of the
persistent server implementations (I like Araneida, but then, I would),
you will find them a lot more pleasant to work with than debugging CGI
scripts ever was.
Really, other languages are moving away from CGI too. Java servlets,
mod_perl, fastcgi, Zope, etc
[le sursis]
> I was planning on adding the PUT method to it one of these days, but
> I think the Lisp community would be better served if a better
> programmer would do that.
I'd have thought that POST was of more general use than PUT anyway.
> And that is all I found: I could not find neither a complete package,
> nor a tutorial on how to write cgi applications in Lisp. (actually
> lispweb is a mailing list on WWW/Lisp but they have no search feature
> on their archives :-(
Although they don't have a search facility (actually, I havent checked
but I'll take your word for it) the archives have been quite well
indexed by Google, so if you can put together a reasonable Google
search term you might well find messages from the lispweb archives in
your results.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Jacques Wainer <······@dcc.unicamp.br> writes:
>
> > Unfortunately even there you cannot find clear information on how to
> > write a Lisp/CGI application. Of the topics listed there
>
> This is not very surprising really:
>
> 1) Most Lisp implementations are not optimized for startup time, which
> makes CGI slow
Yeah, but the languages people tend to do CGI scripting in aren't,
either (*cough* perl *cough*). This is anecdotal, of course, but on
the machines I've tried it on, CLISP starts up faster than Perl, and
even adjusting for startup time, spits out simple requests faster.
Just a pet peeve of mine...
In article <··············@tuiuiu.dcc.unicamp.br>, ······@dcc.unicamp.br says...
> And that is all I found: I could not find neither a complete package,
> nor a tutorial on how to write cgi applications in Lisp. (actually
> lispweb is a mailing list on WWW/Lisp but they have no search feature
> on their archives :-(
If you want to get an idea of what it's like to code a dynamic web
page in AllegroServe, the AllegroServe tutorial is online at
http://opensource.franz.com/aserve/tutorial.html
(if that link doesn't it's because we've finished revamping the
the opensource site so you'll have to start at
http://opensource.franz.com and navigate to the AllegroServe page
and then the tutorial)
-john foderaro
franz inc.
> > http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
> >
> > is a webserver written in CL & includes a suite of functions related
> > to generating html.
>
> I had seen this earlier but didn't really grok it. Do I understand
> this is similar to Tomcat for Java or Zope for python? Basically, you
> let apache handle port 80, but run cl-http on a different port to
> handle a specific application? Then you write cl functions to handle
> the various requests?
cl-http runs as its own webserver. I'm not aware of any particular
relationship to apache, you it on whatever port you want.
The html generation functions are somewhat buried in the
documentation, but essentially you create an instance of a URL class
which establishes some of the http-ism's of it (caching parameters,
language, etc...) in addition to where and what the content is. In
the case of a static file, you provide a pathname. If the content is
to be dynamically computed, you give a Lisp function. The function
receives the url that caused it to be called, along with a stream to
which the html is written. The various (many) functions which
generate the html are oriented towards being called from this context.
I found the "with-*" approach to be particularly useful because it
takes care of opening and closing all those horrid tags. It also
generates very compact html.
Like cgi, the Lisp function doesn't stick around running, it generates
the html and returns. If you want to retain state between calls, then
its up to you. I've not tried cookies, but they are apparently
supported, however I suspect it would be pretty easy to create some
kind of inherited session id so a url service function can hook up to
persistent session state.
There also appears to be some quite sophisticated relationships
established between cl-http and CLIM, which should allow objects to
generate their appearance as html for browsers and as CLIM for local
production- yet retain their coherence and identity. It looks neat.
I don't understand CLIM well enough yet.
Coming from a C/C++ world, at first it looks like a maze of twisty
passages, all alike- but once you start getting used to how things go
together, the possiblities really seem to open up. Its sort of a
different universe, much like going from Cobol to C++, and makes the
learning curve <seem> outrageously big. Most of my problems thus far
have been related to unlearning lots of semi/unconscious idioms and
assumptions which do not necessarily apply.
Gregm
"Doug Alcorn" <·····@seapine.com> wrote in message
···················@balder.seapine.com...
> Greg Menke <··········@mindspring.com> writes:
>
> > > What I'm wanting to find (but haven't) is some repository of tips and
> > > trick for doing HTML from CL. Is there an HTML framework already?
> > > Paul Graham said he used Lisp for his web project. Are others? Is
> > > everyone rolling their own from scratch?
> >
> >
> > http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
> >
> > is a webserver written in CL & includes a suite of functions related
> > to generating html.
> I had seen this earlier but didn't really grok it. Do I understand
> this is similar to Tomcat for Java or Zope for python? Basically, you
> let apache handle port 80, but run cl-http on a different port to
> handle a specific application? Then you write cl functions to handle
> the various requests?
If you look for an equivalent for Lisp of Tomcat for Java, you should look
at mod_lisp : www.fractalconcept.com/asp/html/mod_lisp.html
It is an Apache module that connect to one or more Lisp processes. Apache
handles the HTTP stuff (+ serving uninteresting things like .gif and other
static content) and Lisp handle the requests.
Marc
Others have also mentioned CL-HTTP as a server. If you will be using
Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
own HTTP server.
Finally, if you want to see another example of a Lisp and CL-HTTP based
dynamic page server, go to http://www.isi.edu/ontosaurus.html and look
at that browser. Except for the help pages, all of the content is
dynamically generated from an underlying knowledge base. With proper
permissions, you can even manipulate the information in the knowledge
base (but of course we don't all the general public to do that :). For
some fun, browse an instance and select "Find Similar Instances".
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Others have also mentioned CL-HTTP as a server. If you will be using
> Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> own HTTP server.
Uh, maybe. I heard that the cost of doing this was sky high, that
somehow the price of Allegro CL ballooned when you run it as a network
server or some such thing where there was an order of magnitude (or
more) in price shift if you wanted to deploy Allegro CL as a server.
But rather than listen to me quote gossip, can someone from Franz
speak to whether one can take a Franz Allegro and load AllegroServe
into it and then run it as a commercial server without owing
additional $?
On the one hand, I find this hard to believe because it would seem to
be a disincentive to use AllegroServe in Allegro CL. But stranger things
have happened. If it IS true, what is the line? Is it use of
AllegroServe itself? Any server? Any use of sockets?
I do so hate to deal in rumor, but Franz is the only vendor I know
that doesn't publish its prices. As far as I know, Xanalys, Digitool,
Corman CL, and Elwood Eclipse CL all have their prices published; I
couldn't check Symbolics because their web site was down. All other
implementations that come to mind are free... Am I forgetting someone?
It would help a lot in making purchase decisions for this info to be
published... Having a side-by-size price comparison table for the ALU
web site would be way cool. I'll see what I can do about that.
Kent M Pitman <······@world.std.com> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > Others have also mentioned CL-HTTP as a server. If you will be using
> > Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> > own HTTP server.
>
> Uh, maybe. I heard that the cost of doing this was sky high, that
> somehow the price of Allegro CL ballooned when you run it as a network
> server or some such thing where there was an order of magnitude (or
> more) in price shift if you wanted to deploy Allegro CL as a server.
>
> But rather than listen to me quote gossip, can someone from Franz
> speak to whether one can take a Franz Allegro and load AllegroServe
> into it and then run it as a commercial server without owing
> additional $?
Why should they speak here? Why don't you send them a mail and ask?
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@sevak.isi.edu (Thomas A. Russ) writes:
> >
> > > Others have also mentioned CL-HTTP as a server. If you will be using
> > > Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> > > own HTTP server.
> >
> > Uh, maybe. I heard that the cost of doing this was sky high, that
> > somehow the price of Allegro CL ballooned when you run it as a network
> > server or some such thing where there was an order of magnitude (or
> > more) in price shift if you wanted to deploy Allegro CL as a server.
> >
> > But rather than listen to me quote gossip, can someone from Franz
> > speak to whether one can take a Franz Allegro and load AllegroServe
> > into it and then run it as a commercial server without owing
> > additional $?
> Why should they speak here? Why don't you send them a mail and ask?
Oh, they absolutely don't have to respond here.
But then, neither do any of us have to recommend use of their products.
They make a quality product, but when I go to recommend a business
solution, I am not making a technical recommendation only. I need to
factor in price, license restrictions, etc.
If someone asked me what was a good car, I don't just automatically
say "Mercedes" or "BMW". I first ask what price range they are asking
about. I would find it tedious to have a car which was billed as a
"good car" but that did not identify whether it was marketing to
people with a lot or a little money. It's fine for a car company to
do that, but I'd just not bother to point anyone at that. I don't
like that kind of sales game, and it's not something I'm happy directing
others to. Having to say "You should look at X, Y, and Z because they
seem responsive to your technical and price needs, and product W because
nothing is known about it." doesn't work for me.
Yes, I could call Franz and pretend to want to buy something and ask
about the price, but I don't happen to want to make up a story. So I
just asked publicly. If I called they would probably ask a bunch of
info about me and my situation, but it's not me and my situation I want
info about. I want info about the product that is as useful for anyone
else as for me. And I see no reason for them not to offer such info
publicly.
They might see it differently, of course. But they're adults over
there. If they want a strategy of holding prices close to the vest,
they have presumably thought about the fact that they will suffer some
slings and arrows over the decision, and I'm not going to pull my
punches as if they can't take it. If they didn't think they could
take the heat, they'd have posted their prices.
Kent M Pitman <······@world.std.com> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > ···@sevak.isi.edu (Thomas A. Russ) writes:
> > >
> > > > Others have also mentioned CL-HTTP as a server. If you will be using
> > > > Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> > > > own HTTP server.
> > >
> > > Uh, maybe. I heard that the cost of doing this was sky high, that
> > > somehow the price of Allegro CL ballooned when you run it as a network
> > > server or some such thing where there was an order of magnitude (or
> > > more) in price shift if you wanted to deploy Allegro CL as a server.
> > >
> > > But rather than listen to me quote gossip, can someone from Franz
> > > speak to whether one can take a Franz Allegro and load AllegroServe
> > > into it and then run it as a commercial server without owing
> > > additional $?
> > Why should they speak here? Why don't you send them a mail and ask?
>
> Oh, they absolutely don't have to respond here.
>
> But then, neither do any of us have to recommend use of their
> products.
You don't have to recommend any Lisp if you do not want to. So what
would happen if someone said, well take Franz it's the best Lisp on
earth and works on everthing or simply just on foo? Isn't he/she
allowed to, just because they have no price tag?
>
> They make a quality product, but when I go to recommend a business
> solution, I am not making a technical recommendation only. I need to
> factor in price, license restrictions, etc.
Well have you visited their Web Site?
>
> Yes, I could call Franz and pretend to want to buy something and ask
> about the price, but I don't happen to want to make up a story. So I
> just asked publicly. If I called they would probably ask a bunch of
> info about me and my situation, but it's not me and my situation I want
> info about.
If they ask you just say. That's my business. If they insist than to
ask again,well *than* you know what to do I hope.
>I want info about the product that is as useful for anyone
> else as for me. And I see no reason for them not to offer such info
> publicly.
Well if they see that differently, you have to live with it or not use
it.
>
> If they didn't think they could
> take the heat, they'd have posted their prices.
Well I think that is a implication which can hold but must not. Now
you are posting about a WebServer or whatever, but you ask the people
which are interested to contact you directly. So why don't you publish
them? Couldn't you take the heat? Well Franz says the same, if you
want something from us contact us. I can't see the difference.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > If they didn't think they could
> > take the heat, they'd have posted their prices.
>
> Well I think that is a implication which can hold but must not. Now
> you are posting about a WebServer or whatever, but you ask the people
> which are interested to contact you directly.
By this I'm saying that it would be inconsistent for them to not publish
their prices and then to think it inappropriate that people would discuss
their having not done so. People want to discuss prices, and where prices
are absent, they will discuss the absence.
In the earlier message by me about my web server, I merely observed
that I was working on one. I specifically said it was not likely to
be anyone's first line of attack. This is exactly because it is not
in finished form and because, as a consequence, I have not established
pricing. The functionality changes daily. It is not a fully formed
product. It is not versioned. It is not documented. It's something
I could talk to someone about, but it might end up being a consulting
project unless it turned out they wanted either what I had already
done or what I was just about to have done. There is no place for
such discussion here, I think. I wouldn't want to see Franz discuss
its consulting products here. But Allegro CL is not a consulting
product--it's a versioned piece of software, released at a known time,
and packaged in shrinkwrap.
> So why don't you publish them?
I think this venue is about general-purpose information, not special
case information. I don't think Franz should publish its discussions
of consulting pricing. But I think for shrinkwrap products it should.
Your mileage may vary.
> Couldn't you take the heat?
Certainly I can take the heat. I am here explaining it. I don't
think your question is impertinent. I just think I have a good reason
for not publishing a price at this time. I hope I *will* be able to
publish prices at some point. For one thing, failing to do that seems
an almost sure way to make sure no one contacts me... I don't
seriously expect anyone to follow up given the sketchy info I gave--I
mostly only mentioned it at all for the sake of those who wanted to
inquire about or reference the "success" of using Lisp for this purpose.
> Well Franz says the same, if you
> want something from us contact us. I can't see the difference.
I can. I'm sorry you can't.
Kent M Pitman <······@world.std.com> writes:
> I think this venue is about general-purpose information, not special
> case information. I don't think Franz should publish its discussions
> of consulting pricing. But I think for shrinkwrap products it should.
> Your mileage may vary.
>
I think that 'should' is kind of strong here. Really they can do what
they want to, and it's good that they can. They're not the only
company who are vague about pricing - I don't know the current story
but pricing for things like workstations certainly used to be very
strange - typically there were published prices but they were only
slightly related to what you actually paid for a machine, after you
took into account discounts, tradeins and so on. Workstations are
something I'd regard as mostly shrink-wrapped (unlike say buying a big
server where it's clearly hard to publish a reasonable price since it
depends so much on what configuration you get - a fully-stuffed E10k
is obviously going to be many times the price of a minimal one).
Things like Oracle were also priced in obscure ways, at least until
uite recently.
So really, I think they (or any other vendor) can do what they want
about publishing prices or not, and it's up to the market to decide
whether their choice is right or not. That may be what you meant by
'should' of course, but it's not the sense I got.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
>
> > I think this venue is about general-purpose information, not special
> > case information. I don't think Franz should publish its discussions
> > of consulting pricing. But I think for shrinkwrap products it should.
> > Your mileage may vary.
> >
>
> I think that 'should' is kind of strong here. Really they can do what
> they want to, and it's good that they can.
Well, it's 'good' that I 'can' stay seated in a bus while a pregnant
woman stands, but I 'shouldn't' do so.
I think 'should' is correct. I wrote to them asking about prices (it
wasn't a story: I was interested, at that point) , and they answered
with some general figures, and added the caveat that the exact price
would depend on my situation/funding etc. And would I like to supply
them with that information ?
But they could easily put this info on their web (including the
caveat).
But they don't want to give you (the customer) information. They want
you to supply *them* with information.
> They're not the only
> company who are vague about pricing - I don't know the current story
> but pricing for things like workstations certainly used to be very
> strange - typically there were published prices but they were only
> slightly related to what you actually paid for a machine, after you
> took into account discounts, tradeins and so on. Workstations are
> something I'd regard as mostly shrink-wrapped (unlike say buying a big
> server where it's clearly hard to publish a reasonable price since it
> depends so much on what configuration you get - a fully-stuffed E10k
> is obviously going to be many times the price of a minimal one).
> Things like Oracle were also priced in obscure ways, at least until
> uite recently.
>
> So really, I think they (or any other vendor) can do what they want
> about publishing prices or not, and it's up to the market to decide
> whether their choice is right or not. That may be what you meant by
> 'should' of course, but it's not the sense I got.
>
It would be the decent thing to do to make their prices public, so
that customers can make informed comparisons.
Perhaps they are ashamed to make them public.
Regards,
Peter
-- Sharks may well be misunderstood creatures. I still don't want
one in my swimming pool.
Peter Wood <··········@worldonline.dk> writes:
>
> Well, it's 'good' that I 'can' stay seated in a bus while a pregnant
> woman stands, but I 'shouldn't' do so.
And exactly what does this have to do with a company publishing
pricing or not? I can't see any connection.
I started replying in more detail but I can't see this going anywhere,
so I'll just mention Hitler now and we can stop.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
> >
> > Well, it's 'good' that I 'can' stay seated in a bus while a pregnant
> > woman stands, but I 'shouldn't' do so.
>
> And exactly what does this have to do with a company publishing
> pricing or not? I can't see any connection.
>
I was pointing out that it is possible that one 'can' do something but
'shouldn't'. Its very obvious, unless you're a psychopath. You were
making the point (or seemed to be) that a vendor _can_ withhold
pricing information and therefore the word 'should' in the statement
'they should release it' is too strong. *Your* 'argument' (ie, 'they
can do what they want') does not have anything to do with what they
*should* do.
Maybe you just don't want to acknowledge the ethical dimension in the
relationship between customers and vendors.
> I started replying in more detail but I can't see this going anywhere,
> so I'll just mention Hitler now and we can stop.
>
This is a very bizarre thing to say. I assume you are having a bad
day. Maybe you are still suffering from a cold. Maybe you are just
fucking stupid. Stop if you want - doesn't bother me in the least.
regards,
Peter
> --tim
Peter Wood <··········@worldonline.dk> writes:
> Maybe you just don't want to acknowledge the ethical dimension in the
> relationship between customers and vendors.
Despite the fact that there can by definition be no more useful
content in this thread, I'll just comment that you've really made my
point for me. Are you claiming that it is not ethical for a company
to not publish prices (for some kinds of product), but to instead
require you to ask them? My point was precisely that this particular
issue is *not* an issue of ethics but an issue of choice by the
company (to publish prices or not) and by the consumer (to deal with
them or not). Note carefully that I have not asserted that there is
no ethical dimension in the relationship between customers and
vendors, just that publishing prices is not one.
There. I really will stop now.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
>
> > Maybe you just don't want to acknowledge the ethical dimension in the
> > relationship between customers and vendors.
>
> Despite the fact that there can by definition be no more useful
> content in this thread,
nngggggggggggggnnnnnggngngngn!!!
> I'll just comment that you've really made my
> point for me. Are you claiming that it is not ethical for a company
> to not publish prices (for some kinds of product), but to instead
> require you to ask them? My point was precisely that this particular
> issue is *not* an issue of ethics but an issue of choice by the
> company (to publish prices or not) and by the consumer (to deal with
> them or not). Note carefully that I have not asserted that there is
> no ethical dimension in the relationship between customers and
> vendors, just that publishing prices is not one.
>
<deep breath>
Saying there is an 'ethical dimension' to the issue of making public
their prices doesn't necessarily mean I believe its a black-and-white,
major issue. Like my example of the pregnant woman on the bus,
it's not exactly *unethical* to remain seated, but it would be decent
to give her the seat. I *should* give her the seat. I have the right
not to.
Not publishing their prices is not exactly unethical. It would be the
decent thing to do. It would suggest a willingness to allow potential
customers to make a more informed choice. It might mean people
wouldn't have to waste the time writing them a letter[1], just to get
solicited for information which is interesting to Franz.
It's not the end of the world if they don't but they *should* do it.
> There. I really will stop now.
Feel free.
Regards
Peter
[1] Of course, anyone who has the time to post on Usenet has too much
time on their hands anyway.
On 24 Aug 2001, Peter Wood wrote:
[snip]
> <deep breath>
>
> Saying there is an 'ethical dimension' to the issue of making public
> their prices doesn't necessarily mean I believe its a black-and-white,
> major issue. Like my example of the pregnant woman on the bus,
> it's not exactly *unethical* to remain seated, but it would be decent
> to give her the seat. I *should* give her the seat. I have the right
> not to.
The distinction you seem to be using is sometimes known as "justice
vs. decency" or "the required and the desired". If you think of slicing up
actions into three categories:
required/right/obligated to do
permitted, sometimes called "neutral" or "up to you"
forbidden/wrong/obligated not to do
Where required = ethical/moral, forbidden = unethical/immoral, often.
The if you go with the idea that the permitted are morally *neutral*, then
it's correct to say that doing a permitted action isn't "unethical". After
all, it's not required. But saying that everything not forbidden is
"ethical" ignores that they're *lots* of moral complexity in the permitted
category. For example, some permitting things may be more *morally
desirable* than others.
Giving up your seat for a pregnant, disabled, or eldery person is
(depending on the relative degrees of benefit) morally desirable (to
various degrees). Failing to do so properly subjects you to various
degrees of moral condemnation, even if never to that of being a *rights
violator*.
Note too that "moral" considerations aren't all that's in play. So giving
up your seat is also *nice*, and *considerate*, virtues which often, but
not always, go with morality (i.e., it's generally morally preferable to
be nice, but there are clear cases where being nicer is the wrong thing to
do).
> Not publishing their prices is not exactly unethical. It would be the
> decent thing to do. It would suggest a willingness to allow potential
> customers to make a more informed choice. It might mean people
> wouldn't have to waste the time writing them a letter[1], just to get
> solicited for information which is interesting to Franz.
[snip]
Whatever avoidences of minor wastings of time seem to register a very
minor impact on the moral desirability scale. Compare with the importance
of getting nutritional labels right.
There are, of course, some fairly potent prudential arguments to be made.
Cheers,
Bijan Parsia.
Hi,
Peter Wood <··········@worldonline.dk> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > I started replying in more detail but I can't see this going anywhere,
> > so I'll just mention Hitler now and we can stop.
>
> This is a very bizarre thing to say.
http://www.faqs.org/faqs/usenet/legends/godwin/
HTH
Peter Wood <··········@worldonline.dk> writes:
> This is a very bizarre thing to say. I assume you are having a bad
> day. Maybe you are still suffering from a cold. Maybe you are just
> fucking stupid. Stop if you want - doesn't bother me in the least.
There is a notorious case in the UK involving Usenet, libel cases and
comments about Hitler. I believe that is what is being referred to.
I think this is attempting to say that you were getting a little
irrational.
NB: this is not saying that I agree.
--
MJR (Not an official statement)
Please note changes of address http://stats.mth.uea.ac.uk/
MJ Ray <···@stats.mth.uea.ac.uk> writes:
> There is a notorious case in the UK involving Usenet, libel cases and
> comments about Hitler. I believe that is what is being referred to.
> I think this is attempting to say that you were getting a little
> irrational.
>
No, it's Godwin's law, although actually probably covered by Quirk's
exception.
>
> > There is a notorious case in the UK involving Usenet, libel cases and
> > comments about Hitler. I believe that is what is being referred to.
> > I think this is attempting to say that you were getting a little
> > irrational.
> >
>
> No, it's Godwin's law, although actually probably covered by Quirk's
> exception.
What is Quirk's Law? My copy of the the jargon file doesn't list it/
Gregm
Greg Menke <··········@mindspring.com> writes:
> What is Quirk's Law? My copy of the the jargon file doesn't list it/
>
Intentional invocations of Godwin's law don't work (and it's Quirk's
exception, not law). I think there may be some more.
--tim
Peter Wood <··········@worldonline.dk> writes:
> It would be the decent thing to do to make their prices public, so
> that customers can make informed comparisons.
I'm not sure how much decency is the central issue here. I don't expect
companies to act out of decency, though certainly some companies do. I
expect them to act out of self-interest. And I think the Lisp community
is badly managed as a potential advocacy organization for getting certain
basic concessions from vendors.
I think it would be entirely reasonable for the ALU as an advocacy
organization of users to demand certain things. Just as AAA (the American
Automobile Association) has the clout to demand weird discounts from all
kinds of places. The motivation of a hotel or car rental place or theme park
in offering a discount might be fear of loss of customer or it might be
desire to win over a whole block of customer. That's a fine line I just
don't find any use to worry about. Both are just manifestations of
self-interest, which is what businesses respond to.
We could, for example, take the following approach: that the ALU could
decide to maintain a price comparison chart and that any vendor that
is willing to give us its price list for the table could be listed.
Yes, we could say that vendors can be in the table even if they don't
offer the price, but that doesn't create the necessary self-interest
to motivate the vendor. So my feeling would be that one shouldn't offer
this luxury.
When one goes to travelocity one doesn't get a list of flights that are
in the specified price range plus the phone numbers of a number of private
jets that don't publish their prices. The only people who get included in
the price comparison game are the ones who offer up info to buy their way
in.
Information, sometimes, is money.
Kent M Pitman <······@world.std.com> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
> > It would be the decent thing to do to make their prices public, so
> > that customers can make informed comparisons.
>
> I'm not sure how much decency is the central issue here. I don't expect
> companies to act out of decency, though certainly some companies do. I
> expect them to act out of self-interest. And I think the Lisp community
> is badly managed as a potential advocacy organization for getting certain
> basic concessions from vendors.
>
> I think it would be entirely reasonable for the ALU as an advocacy
> organization of users to demand certain things. Just as AAA (the American
> Automobile Association) has the clout to demand weird discounts from all
> kinds of places. The motivation of a hotel or car rental place or theme park
> in offering a discount might be fear of loss of customer or it might be
> desire to win over a whole block of customer. That's a fine line I just
> don't find any use to worry about. Both are just manifestations of
> self-interest, which is what businesses respond to.
>
> We could, for example, take the following approach: that the ALU could
> decide to maintain a price comparison chart and that any vendor that
> is willing to give us its price list for the table could be listed.
> Yes, we could say that vendors can be in the table even if they don't
> offer the price, but that doesn't create the necessary self-interest
> to motivate the vendor. So my feeling would be that one shouldn't offer
> this luxury.
>
> When one goes to travelocity one doesn't get a list of flights that are
> in the specified price range plus the phone numbers of a number of private
> jets that don't publish their prices. The only people who get included in
> the price comparison game are the ones who offer up info to buy their way
> in.
>
> Information, sometimes, is money.
I agree with what you say here.
However, I would add the following (and I don't expect you to agree):
Businesses are organisations of people. They are bound by the same
moral obligations as the people who comprise them[1]. We should
expect decency from them, just as we should expect decency from our
neighbour or government. And if they behave indecently we have the
right (and probably duty) to react.
The fact that most governments and lots of businesses don't, in
practice, behave decently shouldn't change that.
Regards,
Peter
[1] I think people who own shares in, for example, a company which
makes landmines are morally implicated in the damage their product
causes.
Peter Wood <··········@worldonline.dk> writes:
> Kent M Pitman <······@world.std.com> writes:
> ...
> > Information, sometimes, is money.
>
> I agree with what you say here.
>
> However, I would add the following (and I don't expect you to agree):
>
> Businesses are organisations of people. They are bound by the same
> moral obligations as the people who comprise them[1]. We should
> expect decency from them, just as we should expect decency from our
> neighbour or government. And if they behave indecently we have the
> right (and probably duty) to react.
We are in complete agreement here.
> The fact that most governments and lots of businesses don't, in
> practice, behave decently shouldn't change that.
We are in complete agreement here, too.
Where we are not in complete agreement, apparently, is on the simple matter
of what things are in the ethical space and what not. I don't find the
matter of withholding prices to be an ethical matter. No harm is caused
me by their not telling me me their price schedule--indeed, harm is mostly
done them because I'm less likely to consider them as an option. If I
run out of options, in any case, I'll probably come back to them. But they
are putting themselves lower in my queue by behaving as they are, and my goal
is simply to make them aware of it so they don't shoot themselves in the
foot, and so incidentally I am not inconvenienced.
I am inconvenienced any time a vendor doesn't show up at my favorite
conference, doesn't advertise in my favorite magazine, and so on. But
none of these are ethical matters. That doesn't mean I might not try
to coerce them in "friendly" ways to change their behavior to suit me.
As I said, it's purely an issue of self-interest to me. Theirs vs mine.
But are they being ethical on this matter? I think so, regardless of
their posture.
> Regards,
> Peter
>
> [1] I think people who own shares in, for example, a company which
> makes landmines are morally implicated in the damage their product
> causes.
I realize you aren't directly trying to make a equivalence
relationship between Allegro and landmines, but this analogy is a bit
far afield for me.
Kent M Pitman <······@world.std.com> writes:
> We are in complete agreement here, too.
>
> Where we are not in complete agreement, apparently, is on the simple matter
> of what things are in the ethical space and what not. I don't find the
> matter of withholding prices to be an ethical matter. No harm is caused
> me by their not telling me me their price schedule--indeed, harm is mostly
> done them because I'm less likely to consider them as an option. If I
> run out of options, in any case, I'll probably come back to them. But they
> are putting themselves lower in my queue by behaving as they are, and my goal
> is simply to make them aware of it so they don't shoot themselves in the
> foot, and so incidentally I am not inconvenienced.
This is the principal reason I didn't buy Allegro. I sent their sales
people a request for pricing, they asked me what I wanted to do with
it and forwarded me to a salesperson who apparently didn't think I was
worth talking to because I never heard another word. Meanwhile,
Xanalys had the price on their website, so thats what I bought- no
fooling around with emails or salespeople necessary.
Since I'm not interested in "strategic
partnerships/relationships/whatever" with anyone other than my spouse,
I'm glad in retrospect to have not bought Allegro.
I suppose its one way of extracting additional money out of bigger
customers, but as a small-time customer its annoying. I don't think
its an ethical question as they are certainly free to sell their
product however they please.
Gregm
* Kent M Pitman wrote:
> Where we are not in complete agreement, apparently, is on the simple matter
> of what things are in the ethical space and what not. I don't find the
> matter of withholding prices to be an ethical matter. No harm is caused
> me by their not telling me me their price schedule--indeed, harm is mostly
> done them because I'm less likely to consider them as an option. If I
> run out of options, in any case, I'll probably come back to them. But they
> are putting themselves lower in my queue by behaving as they are, and my goal
> is simply to make them aware of it so they don't shoot themselves in the
> foot, and so incidentally I am not inconvenienced.
I think that one issue that's kind of been ignored here so far is that
it's not actually clear what `witholding' prices means. At least at
some level people seem to be asking for a company to have prices on
their website because that's `published'. Well, not that long ago
companies didn't have websites: what then would constitute publishing
prices? I don't think it would be reasonable to ask that all
advertising material has a price list - producing it is not cheap and
adding transient information means you have to do it more often, and
out-of-date information persists longer than you'd like. Actually
producing and maintaining a website is not as cheap as you'd like, and
things like google mean out-of-date information persists still.
Further the pricing scheme may not be simple. The company may want to
offer discounts to people under various circumstances. There can be
all sorts of complexities. It really is not cost-free to publish
prices, in fact it's not really clear to me what it means.
To give an example which does not involve Lisp vendors: Sun publish
prices for their machines. I've been buying Suns for a long time, and
there may be occasions on which I've actually paid the published
price, but I can't think of one. *certainly* my first instinct when
considering a purchase is to ring up the reseller and find out what
kind of deal we can get. This is not just for big expensive stuff,
this is for machines costing between $1000 and $3000. It's not
unethical that I have to do this, it's part of the game - I want to
get a cheap machine, and Sun want me to develop software which
supports their boxes before others, so we negotiate. If I was buying
a software package with a published price I would also try to
negotiate.
The cases where prices seem to be fairly clear are in serious
commodity items, like PCs, or Windows. But even there it's not at all
clear that the prices that are published mean that much. We bought a
laptop the other day and paid the published price (not the maker's
published price of course, but one of the many reseller prices). But
if we'd wanted 500 laptops would we have considered paying the
published price?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > Where we are not in complete agreement, apparently, is on the simple matter
> > of what things are in the ethical space and what not. I don't find the
> > matter of withholding prices to be an ethical matter. No harm is caused
> > me by their not telling me me their price schedule--indeed, harm is mostly
> > done them because I'm less likely to consider them as an option. If I
> > run out of options, in any case, I'll probably come back to them. But they
> > are putting themselves lower in my queue by behaving as they are, and my goal
> > is simply to make them aware of it so they don't shoot themselves in the
> > foot, and so incidentally I am not inconvenienced.
>
> I think that one issue that's kind of been ignored here so far is that
> it's not actually clear what `witholding' prices means.
That's easily cleared up. In this context, If they don't make the
prices available on the web, for comparison, that's withholding.
Thats what this discussion is about.
> some level people seem to be asking for a company to have prices on
> their website because that's `published'. Well, not that long ago
> companies didn't have websites: what then would constitute publishing
> prices?
In the back of my copy of On Lisp (Paul Graham), is an advert for
Allegro CL/PC version 1.0 with prices, and a discount. I would say
that's an example of what constitutes 'publishing prices'.
> I don't think it would be reasonable to ask that all
> advertising material has a price list - producing it is not cheap and
> adding transient information means you have to do it more often, and
> out-of-date information persists longer than you'd like. Actually
> producing and maintaining a website is not as cheap as you'd like, and
> things like google mean out-of-date information persists still.
>
I can't believe this. Are you seriously suggesting that communicating
a rough idea of their prices to x hundred potential customers (via a
web site) is more expensive than having staff answer x hundred email
queries?
You can also mark your information with a date. If I find a price
list on google with a date from 1993, I will assume it is no longer
accurate. You could also say 'good only for version XXX'.
> Further the pricing scheme may not be simple. The company may want to
> offer discounts to people under various circumstances. There can be
> all sorts of complexities. It really is not cost-free to publish
> prices, in fact it's not really clear to me what it means.
>
That is not a good reason for not publishing a guestimate of the
price. They can qualify it with buts and ifs, since that's what they
do anyway when you mail them. But I suppose you are now going to
suggest that it would be good business practice for them _never_ to
tell potential customers what their product costs. Not on the web,
not in email. In fact customers should just send Franz a blank,
signed cheque and wait happily to see how much it cost.
> To give an example which does not involve Lisp vendors: Sun publish
> prices for their machines. I've been buying Suns for a long time, and
> there may be occasions on which I've actually paid the published
> price, but I can't think of one. *certainly* my first instinct when
> considering a purchase is to ring up the reseller and find out what
> kind of deal we can get. This is not just for big expensive stuff,
> this is for machines costing between $1000 and $3000. It's not
> unethical that I have to do this, it's part of the game - I want to
> get a cheap machine, and Sun want me to develop software which
> supports their boxes before others, so we negotiate. If I was buying
> a software package with a published price I would also try to
> negotiate.
>
> The cases where prices seem to be fairly clear are in serious
> commodity items, like PCs, or Windows. But even there it's not at all
> clear that the prices that are published mean that much. We bought a
> laptop the other day and paid the published price (not the maker's
> published price of course, but one of the many reseller prices). But
> if we'd wanted 500 laptops would we have considered paying the
> published price?
None of this is relevant to the *issue* of making their prices
public. Lots of potential customers would like to get a rough idea of
what their product costs, without having to email them first.
Regards,
Peter
* Peter Wood wrote:
> That's easily cleared up. In this context, If they don't make the
> prices available on the web, for comparison, that's withholding.
> Thats what this discussion is about.
So you require a company to have a web site? If they don't they're
witholding prices? Hmm.
> I can't believe this. Are you seriously suggesting that communicating
> a rough idea of their prices to x hundred potential customers (via a
> web site) is more expensive than having staff answer x hundred email
> queries?
Yes. Because it may be incredibly hard to do in such a way as to have
meaning. The issue is that there is huge flexibility in pricing
software - it's not like cars where it actually costs you money to
make the car and you have some profit margin and the economics is
reasonably well-understood. Software pricing has models which vary
enormously (people even suggest that all software should be free),
and the same company may price on several models. Describing the
actual pricing models is difficult, especially as you may make them up
as you go along, and giving a worst-case price which is at least safe
(you *never* want to give a price and then say to a customer that you
actually will charge them more) leaves you open to all sorts of
attacks about how much your stuff costs. Again, look at Sun: they
used to quote worst-case prices, which were enormously higher than PC
prices. No-one ever paid these prices, but they still got huge flack
about how much their machines cost because some cretin journalist
would look up and see that a 3/50 was listed $20,000 or something when
actually no one ever paid more than $8,000.
> That is not a good reason for not publishing a guestimate of the
> price. They can qualify it with buts and ifs, since that's what they
> do anyway when you mail them. But I suppose you are now going to
> suggest that it would be good business practice for them _never_ to
> tell potential customers what their product costs. Not on the web,
> not in email. In fact customers should just send Franz a blank,
> signed cheque and wait happily to see how much it cost.
Right. Of course I am going to suggest that. Of course. I'll just
write my cheque now.
And I'd been getting quite a good impression of Danes, too.
--tim
Tim Bradshaw <···@cley.com> writes:
> The issue is that there is huge flexibility in pricing
> software
Actually, I'll have to check my law references to be sure, but I have
some doubt that it's legal to sell the identical product to different
people at different prices. If the actual product or the market
circumstance is legitimately different, that might justify it. But my
grocer can't just say "You seem like a nice guy" and give me a "nice
guy" discount, while saying to someone else "You look a little shady"
and then not do it. Nor can he say "You look rich, so you'll have to
pay a premium." I don't profess to be an expert in this branch of the
law, but I'm pretty sure a vendor doesn't have the total flexibility
here that you might expect them to have.
> Describing the
> actual pricing models is difficult, especially as you may make them up
> as you go along
Guess I've got some reading to do on antitrust and the uniform
commercial code. I'm sure it speaks to this matter, but I can't
remember how. Something about this idea makes me think that, in the
US at least, this ("making prices up as you go along") might not be
something you can just do for a commodity item (identical packaged
merchandise delivered to two customers under equivalent market
circumstances -- my pseudo-definition, btw, not sure if that's the
legal definition of commodity or whether being a commodity at all is
the hinge point to all of this, but I vaguely recollect from a
long-ago reading of some legal texts that a concept in this general
conceptual area is the hinge point).
Someone with a more specific legal knowledge than I have is certainly
invited to help me out / correct me here...
On Sun, 26 Aug 2001, Kent M Pitman wrote:
> Tim Bradshaw <···@cley.com> writes:
>
> > The issue is that there is huge flexibility in pricing
> > software
>
> Actually, I'll have to check my law references to be sure, but I have
> some doubt that it's legal to sell the identical product to different
> people at different prices.
Not only am I NAL, I don't have any law references. Nevertheless, I
am quite sure that it is legal to do this unless you violate the civil
rights of the buyer e.g., by charging a higher price to those of certain
races or ethnicities.
Whether anyone will still buy from you if you are perceived to be doing
this "unfairly" is another question...
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
> On Sun, 26 Aug 2001, Kent M Pitman wrote:
>
> > Tim Bradshaw <···@cley.com> writes:
> >
> > > The issue is that there is huge flexibility in pricing
> > > software
> >
> > Actually, I'll have to check my law references to be sure, but I have
> > some doubt that it's legal to sell the identical product to different
> > people at different prices.
>
> Not only am I NAL, I don't have any law references. Nevertheless, I
> am quite sure that it is legal to do this unless you violate the civil
> rights of the buyer e.g., by charging a higher price to those of certain
> races or ethnicities.
>
> Whether anyone will still buy from you if you are perceived to be doing
> this "unfairly" is another question...
The chief non-computer example of this phenomenon is an automobile dealer.
···@sevak.isi.edu (Thomas A. Russ) writes:
> The chief non-computer example of this phenomenon is an automobile dealer.
I think that's the chief non-computer `domestic' example, where by
`domestic' I mean something that ordinary people do. Companies tend
to vary prices a lot more when they buy/sell things, but ordinary
people don't see a lot of these deals being done and so assume it is
rare.
I think that the reason that it's not often seen by ordinary people,
and that cars are one of the few examples is that it's traditionally
done for things of high value, and cars are about the most expensive
thing that people buy where this might apply. The other high-value
item that people buy - a house - typically has so much individual
variation that this doesn't work (I guess it might for new houses -
I've never bought one less than 100 years old, so I don't really have
any experience (:-)).
Of course now the internet has changed everything, so we may see price
variation per-person in quite low-value items. (Someone is whispering
in my ear that the internet hasn't changed everything after all.)
--tim
Kent Pitman writes:
Actually, I'll have to check my law references to be sure, but I
have some doubt that it's legal to sell the identical product to
different people at different prices. If the actual product or
the market circumstance is legitimately different, that might
justify it. But my grocer can't just say "You seem like a nice
guy" and give me a "nice guy" discount, while saying to someone
else "You look a little shady" and then not do it. Nor can he say
"You look rich, so you'll have to pay a premium."
Kent, although you are generally the best language lawyer I know, you
have this one completely wrong, at least for the U.S., and almost
certainly for most of the rest of the world, too.
Get ready for the era of "personalized pricing" in everything, not
just software. Coca-cola is one of the pioneers. See, for example,
http://www.businessweek.com/1998/18/b3576023.htm
Larry
And now back to our regular c.l.lisp discussions....
--
Lawrence Hunter, Ph.D.
Director, Center for Computational Pharmacology
Associate Professor of Pharmacology, PMB & Computer Science
URL: http://compbio.uchsc.edu/Hunter
phone (303) 315-1094 UCHSC, Campus Box C236
fax (303) 315-1098 School of Medicine rm 2817b
cell (303) 324-0355 4200 E. 9th Ave.
email: ············@uchsc.edu Denver, CO 80262
Tim Bradshaw <···@cley.com> writes:
> * Peter Wood wrote:
>
> > That's easily cleared up. In this context, If they don't make the
^^^^^^^^^^^^
> > prices available on the web, for comparison, that's withholding.
> > Thats what this discussion is about.
>
> So you require a company to have a web site? If they don't they're
> witholding prices? Hmm.
'In this context' means among other things that the company in
question is called Franz, and does have a website.
>
> > I can't believe this. Are you seriously suggesting that communicating
> > a rough idea of their prices to x hundred potential customers (via a
> > web site) is more expensive than having staff answer x hundred email
> > queries?
>
> Yes. Because it may be incredibly hard to do in such a way as to have
> meaning. The issue is that there is huge flexibility in pricing
> software - it's not like cars where it actually costs you money to
> make the car and you have some profit margin and the economics is
> reasonably well-understood. Software pricing has models which vary
> enormously (people even suggest that all software should be free),
> and the same company may price on several models. Describing the
> actual pricing models is difficult, especially as you may make them up
> as you go along, and giving a worst-case price which is at least safe
> (you *never* want to give a price and then say to a customer that you
> actually will charge them more) leaves you open to all sorts of
> attacks about how much your stuff costs. Again, look at Sun: they
> used to quote worst-case prices, which were enormously higher than PC
> prices. No-one ever paid these prices, but they still got huge flack
> about how much their machines cost because some cretin journalist
> would look up and see that a 3/50 was listed $20,000 or something when
> actually no one ever paid more than $8,000.
This is irrelevant to what we're talking about. For one thing, it is
more expensive to have staff occupied with dealing with generally
curious customers, than to have those [potential] customers satisfy
their curiousity on a web page, which won't cost them anything
significant since it's there already. It would not break Franz to
have a link to a plain text listing of rough estimates of what their
products cost in some common cases.
And another thing; if it applied in *this* case, then they should not
give prices in reply to emails either. They should say they don't
quote prices until they know your situation. That's not what they do.
>
> > That is not a good reason for not publishing a guestimate of the
> > price. They can qualify it with buts and ifs, since that's what they
> > do anyway when you mail them. But I suppose you are now going to
> > suggest that it would be good business practice for them _never_ to
> > tell potential customers what their product costs. Not on the web,
> > not in email. In fact customers should just send Franz a blank,
> > signed cheque and wait happily to see how much it cost.
>
> Right. Of course I am going to suggest that. Of course. I'll just
> write my cheque now.
>
> And I'd been getting quite a good impression of Danes, too.
>
Is this some sort of obscure reference like the Hitler thing? What
does mentioning Danes mean in usenet? If you mean me, saa maa jeg
melde hus forbi.
Regards,
Peter
Tim Bradshaw <···@cley.com> writes:
> I think that one issue that's kind of been ignored here so far is that
> it's not actually clear what `witholding' prices means. At least at
> some level people seem to be asking for a company to have prices on
> their website because that's `published'. Well, not that long ago
> companies didn't have websites: what then would constitute publishing
> prices?
Price sheets on order forms distributed at a conference.
Price quotes over the phone without asking personal data. This would be
adequately minute-to-miute.
Price information in a magazine. I've seen this for Symbolics in
the distant past, and for Digitool. Most vendors of programming languages
sell through PC Connection and Outpost.COM and others, and I *assume* that
most vendors of Lisp don't do this only because they fear it won't bring the
necessary return or because they literally don't have the up-front revenue,
but not because they don't have a fixed price product.
Or, a timely response to this newsgroup saying "the price as of such-and-so
date is <blah>, even though it might go up in the future".
Most of the other vendors will do this, and I assume don't just because they
already have the perfect vehicle--a web page--for centralizing this
information. I myself won't generally quote a URL into the CL HyperSpec
even though I often could, just so that if the pages are renamed, there
isn't stale data--but the HyperSpec has its own lookup mechanism, so it's
not like I'm "withholding" the information about where to find soemthing.
I'll just say "look in chapter 2". By analogy, I consider "see our web pages"
to be adequately forthcoming.
> I don't think it would be reasonable to ask that all
> advertising material has a price list - producing it is not cheap and
> adding transient information means you have to do it more often, and
> out-of-date information persists longer than you'd like. Actually
> producing and maintaining a website is not as cheap as you'd like, and
> things like google mean out-of-date information persists still.
I maintain a number of web sites and consider it well within the
tractable range. For the vendor with no web page, the incremental
value of even one page on the web is well worth the minimal expense of
getting a minimal site. The first sale it leverages will probably pay
for the page's maintenance for a year. For someone who already maintains
a site, the incremental cost of maintaining a page of prices is even lower.
I don't think anyone expects a price-quote in a google-cached page to be
correct and I can't imagine that being a source of trouble. No one I know
quotes prices without a "prices subject to chnage without notice" disclaimer
and/or a "prices good until <date>" notation, and Google would cache that.
> Further the pricing scheme may not be simple. The company may want to
> offer discounts to people under various circumstances.
"Volume discounts and site licensing available." People who have big
organizations are used to negotiating and have far less need for this
information. The commodity end is mostly about the individual customer.
Beef or cars or lollipops may be a commodity with well-established price,
but I doubt McDonald's or the US Government pays that price, so I think
that's a red herring.
> There can be
> all sorts of complexities. It really is not cost-free to publish
> prices, in fact it's not really clear to me what it means.
It's clear to me. It establishes a baseline for comparison that is both
directly useful in the statistically common case of a single-unit purchase
and indirectly handy for establishing expectations as to where the price
will fall in the aggregate. It sounds to me as if what you're saying is
"Yes, Volvos may look expensive when purchased in 1's, but they will fall
below Honda Civics in price if purchased in the aggregate like the vendor
intends." I don't think that will happen for Volvos and I don't think it
will happen for the Lisp vendors. There might be places where they do have
competitive pricing in the aggregate, but all the more reason to make that
fact apparent rather than to hide it.
> To give an example which does not involve Lisp vendors: Sun publish
> prices for their machines. I've been buying Suns for a long time, and
> there may be occasions on which I've actually paid the published
> price, but I can't think of one.
Typically, though, the published prices and the discounts move up and down
together. Avis and Hertz often offer discounts, too, but then so does Budget.
When you get all done with it, you may pay less in all cases, but you can
still tell by the base prices that your'e going to pay more at Hertz/Avis
than at Budget/Thrifty. I'd be surprised if the same were not true for Sun.
> *certainly* my first instinct when
> considering a purchase is to ring up the reseller and find out what
> kind of deal we can get.
Reselling is not an issue in computer software because of licensing issues.
I agree it could complicate things a little for hardware.
> This is not just for big expensive stuff,
> this is for machines costing between $1000 and $3000. It's not
> unethical that I have to do this, it's part of the game - I want to
> get a cheap machine, and Sun want me to develop software which
> supports their boxes before others, so we negotiate. If I was buying
> a software package with a published price I would also try to
> negotiate.
I think this analogy is not a good one because I don't see a way to
include a software license without the price going up, while I can
understand how this could happen in reselling used software because of
(lack of) depreciation. In my experience, software licenses do not
depreciate--they either maintain their current value or sometimes even
go up; maybe you've seen otherwise. For example: Under the last Franz
license I saw (for Allegro CL 5.0, 2-3 years ago), you can't even
distribute executables from the existing (old) software at the price
you bought it at--you had to pay the current market price to continue
your right to distribute last year's deliverable. (This might have
changed; I'll let Franz speak for its current policy if it wants to.
I'm just saying it's hard to make a buck as a reseller with a policy
like this.)
> The cases where prices seem to be fairly clear are in serious
> commodity items, like PCs, or Windows. But even there it's not at all
> clear that the prices that are published mean that much.
Adobe and Macromedia software can be bought from PC Connection,
Outpost.COM, The PC Warehouse, etc. at slightly differing prices, but
that doesn't keep Adobe from publishing a "list price". The list
price allows you to tell what ballpark you'll be in. I care whether
I'm paying $10, $100, or $1000. I care whether I'm paying for
royalties or not. I don't care a hoot about whether it's $99 vs $110,
$999 or $1035.17.
> We bought a
> laptop the other day and paid the published price (not the maker's
> published price of course, but one of the many reseller prices). But
> if we'd wanted 500 laptops would we have considered paying the
> published price?
I debunked the negotiated price issue above. Single users (which is who
I think this is serving) don't get those. And it's rare for the curve lines
to cross even as prices come down. If vendor A's base price is above Vendor
B's, then I bet usually Vendor A's volume price will be above Vendor B's.
If that's not so, it's all the more reason for for Vendor A (with the lower
volume price) to publish prices.
Kent M Pitman <······@world.std.com> writes:
> I debunked the negotiated price issue above. Single users (which is who
> I think this is serving) don't get those. And it's rare for the curve lines
> to cross even as prices come down. If vendor A's base price is above Vendor
> B's, then I bet usually Vendor A's volume price will be above Vendor B's.
> If that's not so, it's all the more reason for for Vendor A (with the lower
> volume price) to publish prices.
I don't really have the energy to followup to this any more - I think
I'm clearly living on a different planet to both you and (fortunately)
Peter Wood. In your case the reason I'm on a different planet is the
second sentence above: I *certainly* negotiate prices as a single
user, and successfully so. Single users definitely can get negotiated
prices from software vendors.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I think this venue is about general-purpose information, not special
> > case information. I don't think Franz should publish its discussions
> > of consulting pricing. But I think for shrinkwrap products it should.
> > Your mileage may vary.
> >
>
> I think that 'should' is kind of strong here.
I didn't say "they should". I said "I think ... it should". Those are
different to me. Probably some people just think I say things in a verbose
way all the time, but I am often very particular about my use of verbs and
to me "I think" is adequate qualification. I meant to say: I do not
personally acknowledge a reason why they ought not, but I acknowledge that
others might acknowledge a reason why they ought not.
> Really they can do what they want to,
Yes, and I said this several times. Possibly in seeming contradiction
to my having said that "I think they should" publish the prices. I would
have said more simplly "They should publish the prices." otherwise.
I know some people think a personal statement automatically implies
one level of "I think", but this leads to philosophical/linguistic problems
in the discussion of objective truth, if you believe in that sort of thing.
I know I'm also not 100% consistent in the style of speech I refer to,
and that probably further confuses things, too, since sometimes I
speak inconsistently. Sometimes people probably breathe a sigh of
relief when I speak in a more simple declarative form, but sometimes
what I feel I am doing is not merely "being more brief" but "being
provocative by eliminating necessary qualifiers" either because I'm
being lazy (and perhaps not intending to provoke) or because I'm
trying to elicit discussion by appearing to leave no room for
alternatives. (In this case, I managed to provoke discussion even
having left room. Heh...)
Note that the last two paragraphs and this first sentence of this one
do not contain qualifications of "I think". This is because I believe (heh)
that the verb "to know" (and the implied state of "to know" used when simply
stating a declarative fact) implies both "I think" and "it happens to also
be true"; in those cases, my sense is that the verb "I think" would water
down my meaning and would be inappropriately placed (per H.P. Grice's rules
of Conversational Implicature).
> and it's good that they can.
I would have said here "I think it's good..." since there are alternate
world models involving goodness. The unconditional use of Good or Bad
is usually, in my experience, either dogma, confusion, or humor.
I don't, by the way, insist that language must be used in the precise way
I use it. Rather, I observe that, by its nature, all people use language
in an overly precise way because they require it to specify more things
than its stated meaning can. So they create complex operational rules for
its usage that convey extra meaning if only the listener would hear it. But
listeners have their own meaning and the more common result of such
superprecision is, as here, the impression of disagreement. Consider the
meaning of the words "beautiful", "pretty", "cute", "attractive", and
"handsome". There is some general dictionary agreement as to the meaning,
but I bet most people have never looked. I bet most people are substantially
more precise about the reproducibility of their own usage of thes terms
than are others able to be precise in understanding their usage. (I never
tried the experiment. I'm just, perhaps naively, confident it's so.)
> They're not the only
> company who are vague about pricing - I don't know the current story
> but pricing for things like workstations certainly used to be very
> strange - typically there were published prices but they were only
> slightly related to what you actually paid for a machine, after you
> took into account discounts, tradeins and so on.
In most such cases, I would think a base price could be established.
They might not want to do this because it serves their interest, but
it does feel like it serves mine as a consumer. A used car dealer
still does this kind of dealing even though they publish a price. The
price may not be perfect but establishes a start for the bidding.
Even if it plays fast and loose with several thousands of dollars, it
usually is within a factor of 2 of the right amount, and this is
plenty useful for telling certain customers who might be interested
whether they are in the right price ballpark.
Further, while I think it their right to decide not to offer me the price,
I don't think they are entitled automatically to a pass from me offering
critical words over the fact. If they were, this would remind me of the
neo-civil-disobedience movement where people are surprised to be arrested
for civil disobedience because civil disobedience is noble and deserves
no punishment. (What makes it noble is the personal assumption of risk,
not the having bought a pass from such risk. If they know there is no
danger, it loses its nobility.) Fine for any vendor to do something
that might piss off a customer, but not not fine to conclude the further
right that the customer therefore not be pissed.
> Workstations are
> something I'd regard as mostly shrink-wrapped (unlike say buying a big
> server where it's clearly hard to publish a reasonable price since it
> depends so much on what configuration you get - a fully-stuffed E10k
> is obviously going to be many times the price of a minimal one).
> Things like Oracle were also priced in obscure ways, at least until
> uite recently.
Because they were intended as consulting sales. As might be my web server,
and I have made no bones about that.
In many ways, I think everyone all around would be happier if Franz
sold their product as a consulting sale and not as a shrinkwrapped
product. I have said over and over that I don't really have a problem
with its technical quality--just its pricing. And not because it's
valued badly as a "business solution". It might be a very ordinary
price for a business solution--even a bargain basement price. But
what every other vendor is selling that purports to compete with them
is not a "business solution" but a "programming language". And there
is a sort of expectation that a programming language is a commodity (a
misunderstanding, perhaps when people compare across Lisps, but a fair
assumption within the Lisp community). Like cars (which are also
commodities), it seems to me, there are simple ones and ritzy ones,
and price can vary. But I find it odd to see one whose price cannot
be pegged.
> So really, I think they (or any other vendor) can do what they want
> about publishing prices or not,
I never challenged this statement.
> and it's up to the market to decide
> whether their choice is right or not.
I can't speak for the market. But none of us can. We can all speak for
ourselves as part of the market. And I have done so. I did not say I was
speaking for the market, nor did I mean to be. I spoke for myself as part
of the market, as I believe I am, and as I believe such "membership" entitles
me to.
> That may be what you meant by 'should' of course, but it's not the
> sense I got.
Nope. It's what I meant by "I think they should." ;-)
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> I know some people think a personal statement automatically implies
> one level of "I think", but this leads to philosophical/linguistic
problems
> in the discussion of objective truth, if you believe in that sort of
thing.
>
To add to the complication, many interpret "I think <foo>" as simply <foo>
making a jump in exactly the opposite direction your wording was meant to
block! There is no fool-proof AND practical way to communicate such
distinctions...
FWIW, I understood your original post to mean exactly what I understand this
last post to mean.... if I understood correctly....or something ;-)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
On Fri, 24 Aug 2001, Kent M Pitman wrote:
> In many ways, I think everyone all around would be happier if Franz
> sold their product as a consulting sale and not as a shrinkwrapped
> product. I have said over and over that I don't really have a problem
> with its technical quality--just its pricing. And not because it's
> valued badly as a "business solution". It might be a very ordinary
> price for a business solution--even a bargain basement price. But
> what every other vendor is selling that purports to compete with them
> is not a "business solution" but a "programming language". And there
> is a sort of expectation that a programming language is a commodity (a
> misunderstanding, perhaps when people compare across Lisps, but a fair
> assumption within the Lisp community). Like cars (which are also
> commodities), it seems to me, there are simple ones and ritzy ones,
> and price can vary. But I find it odd to see one whose price cannot
> be pegged.
They seem to be successful selling it as a business solution; my company
views Allegro as another piece of software in line with Oracle, Tibco,
etc. Whatever Franz is charging us (I don't know) it doesn't seem to be
out of line with that crowd.
While programmers might have a desire to see languages as a commodity, a
company will do everything it can to avoid having its products
commoditized. Franz seems to be doing a good job at that with its
"dynamic object oriented solution."
Tim
On 25 Aug 2001 05:37:11 GMT, Tim Moore <·····@herschel.bricoworks.com> wrote:
>While programmers might have a desire to see languages as a commodity, a
>company will do everything it can to avoid having its products
>commoditized. Franz seems to be doing a good job at that with its
>"dynamic object oriented solution."
I recenty purchased Allegro for Windows and Linux for the purpose of learning
Lisp and working with a many gigabyte set of densely relational data, the
Unified Medical Language System.
Perhaps I'm just slow or too new to Allegro, but this "dynamic object
oriented solution" -- that's just a marketing slogan, right? Or, is
there some other unique "object oriented" component that is present in
this Common Lisp implementation?
I further wonder, along the lines of Kent's initial question, may I
divulge how much I paid for Allegro or would I be breaking some clause
in the many page license agreement?
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
On Sat, 25 Aug 2001 23:32:16 +0200, Fernando <···@wanadoo.es> wrote:
>Hhmm... What is this unified medical language system? O:-)
It is a metathesaurus of vocabularies. There are about 40 vocabularies
in the UMLS. Manual review establishes semantic equivalences between concepts
in the vocabularies. Currently, there are roughly 800,000 concepts and 1.8
million strings in UMLS. There also tens of millions of records with further
information about the concepts, lexical terms, and strings. The web site
is at http://www.nlm.nih.gov/research/umls/umlsmain.html.
>No. Common Lisp (the language, not just Franz's implementation) is, among
>other things, object oriented and dynamic. It's a fact, not marketing mumble
>jumble. :-)
I understand, I was referring to "dynamic objects" beyond ANSI CL
with CLOS plus MOP.
I did buy AllegroStore and spent two months banging my head with their
tech support trying to get it to digest UMLS. I finally gave up on
AllegroStore and am happy with my "dynamic object"-based CLOS/SQL
hybrid.
>If they wanted their prices to be public, they would do it themselves. So if
>your license doesn't forbid it, you can, but out of courtesy "I think you
>shouldn't" (ask Kent for a precise definition of the quoted text ;-).
That makes sense!
Best,
Kevin
·····@boa.b9.com (Kevin Rosenberg) writes:
> I did buy AllegroStore and spent two months banging my head with their
> tech support trying to get it to digest UMLS. I finally gave up on
> AllegroStore and am happy with my "dynamic object"-based CLOS/SQL
> hybrid.
I'd be interested in your experiences building such a thing, as
UncommonSQL is addressing the same problem domain. It's always good
to get the perspectives others take on the persistence front.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
On Mon, 27 Aug 2001 16:10:22 GMT, Craig Brozefsky <·····@red-bean.com> wrote:
>> I did buy AllegroStore and spent two months banging my head with their
>> tech support trying to get it to digest UMLS. I finally gave up on
>> AllegroStore and am happy with my "dynamic object"-based CLOS/SQL
>> hybrid.
>
>I'd be interested in your experiences building such a thing, as
>UncommonSQL is addressing the same problem domain. It's always good
>to get the perspectives others take on the persistence front.
The main problems were performance and "Address Full" errors. I am
using dual 1GHz PIII systems with 2GB of RAM along with newest
versions of ACL and AllegroStore. In the end, the problem I believe is
that my schema has too many pointers from one object to another. Of
course, that pointer ability is what attracted to me AllegroStore
vs. using keyed index lookups in SQL.
The UMLS has 12 different relational databases. To lookup all the
information on a concept may take as many as 1000 links with various
subobjects linking to other objects. My understanding is that
AllegroStore with its Object Store backend tries to reserve memory for
objects that are referenced from an object. And for each referenced
object it reserves room for its entire page.
The first problem is with address full errors. Despite optimizing my
client address map to get 1GB of space for AllegroStore, I was still
getting address full errors with trying to import a test database
1/100th the size of the full database. Tech support helped and I could
get further with their assistance, but I was still unable to get
1/100th the database on both Windows and Linux platforms.
The other issue is performance. To import the text database into MySQL
along with index generation took about 2 hours. For AllegroStore,
trying to import 1/100th of the database, I was running out of address
space after 3 days of execution. At that rate, of course, it'd take a
year to import the data.
I tried three difference schema's over the months to get around those
problems. In the end, the only way that I felt that I could fully get
around the address full errors is to eliminate the pointers between my
objects and do key lookups. Rather than doing that, I just created my
own CLOS classes and used ODBC/SQL with lazy sub-object reads and
memoization for my database. I'm getting fine performance with this.
I think that AllegroStore can be good for rapid prototyping and maybe
even production systems with databases that are modest in size or do
not have much pointers between objects. For the large and densely
relational UMLS database, I wasted two valuable months trying to get
AllegroStore to work.
I hope that info helps.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Kent M Pitman <······@world.std.com> writes:
> They might see it differently, of course. But they're adults over
> there. If they want a strategy of holding prices close to the vest,
> they have presumably thought about the fact that they will suffer some
> slings and arrows over the decision, and I'm not going to pull my
> punches as if they can't take it. If they didn't think they could
> take the heat, they'd have posted their prices.
You better be careful Kent. The last person in this forum to
discuss Franz's pricing (or lack thereof) got roasted alive
and accused of being a danger to society. :-)
My take is that Franz doesn't want to be your "lisp vendor",
they want to be your "strategic business partner". This obviously makes
their pricing structure/strategy different.
But hey, that's just my take. Anybody wanna know the real story
had better talk to Franz.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Others have also mentioned CL-HTTP as a server. If you will be using
> Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> own HTTP server.
Somebody has ported aserve to other Common Lisp implementations. See
the discussions on the sourceforge project web site.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
···@sevak.isi.edu (Thomas A. Russ) writes:
> Others have also mentioned CL-HTTP as a server. If you will be using
> Allegro Common Lisp, then you might want to look at AllegroServe, Franz'
> own HTTP server.
>
> Finally, if you want to see another example of a Lisp and CL-HTTP based
> dynamic page server, go to http://www.isi.edu/ontosaurus.html and
> look
Not Found
The requested object does not exist on this server. The link you
followed is either outdated, inaccurate, or the server has been
instructed not to let you have it.
Any other pointer?
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'.
Doug Alcorn wrote:
>
>[...]
> What I'm wanting to find (but haven't) is some repository of tips and
> trick for doing HTML from CL. Is there an HTML framework already?
> Paul Graham said he used Lisp for his web project. Are others? Is
> everyone rolling their own from scratch?
Go googling for the following:
[1] LSP (lisp server pages) by Sunil Mishra.
[2] http://alpha.onshore.com for "IMHO"
[3] mod_lisp (which hooks into apache)
Have fun,
Eric
In article <··············@balder.seapine.com>, Doug Alcorn wrote:
>What I'm wanting to find (but haven't) is some repository of tips and
>trick for doing HTML from CL. Is there an HTML framework already?
>Paul Graham said he used Lisp for his web project. Are others? Is
>everyone rolling their own from scratch?
Tim Bradshaw, whom you can see posting here, has some example Lisp
code for generating HTML.
Take a look at http://www.tfeb.org/lisp/hax.html
Doug Alcorn <·····@seapine.com> writes:
> What I'm wanting to find (but haven't) is some repository of tips and
> trick for doing HTML from CL. Is there an HTML framework already?
> Paul Graham said he used Lisp for his web project. Are others? Is
> everyone rolling their own from scratch?
I have a web server (I rolled my own; not related to any of the
others) that's developed and deployed for some uses of my own (though
I continue to add featurism) but is not released yet. There are
enough free alternatives that I doubt this one will be free. If
anyone has a specific commercial need and is faced with writing their
own rather than use one of the existing ones, they can contact me to
find out what the current state and availability is. I don't expect it
to be anyone's first line of attack, at least for now, but I think it's
good for there to be multiple independent bloodlines out there in order
that people don't confuse the notion of "what one person thought to do
with Lisp and XML/HTML" with "what Lisp is able to do with XML/HTML".
My server has only been tested in LispWorks, but has only a couple of
very tiny non-portable parts. One of the things I hope to start to
identify is a standard set of functionality that all vendors need to
provide so that we as a community can bootstrap stuff like this reliably.
Also, my server is not presently designed for use on standard http
port 80, but not because it's technically infeasible to make it do
so--rather, because Apache is already better trusted for that
function, so I'm exploring the route of just having Lisp run as an
adjunct, more along the ways to how I understand modlisp to work. I
could make a Lisp that ran as root and did a tightly controlled set of
things before handing off to non-root, but no matter how I coded it,
and even if I open-sourced it, people would still see the .exe there
and worry it might do things they didn't understand or expect under
some stress situation because of non-trust in Lisp (notwithstanding
the possibly better likelihood that the things they DO trust would do
those same things more often); Apache is already serviceable and
extensible and I see no reason not to use it for the things I can do
and do well, and, importantly, that people already trust it to do
and do well.
Fernando <···@wanadoo.es> writes:
> On Thu, 23 Aug 2001 17:18:23 GMT, Kent M Pitman <······@world.std.com> wrote:
>
> >I have a web server (I rolled my own; not related to any of the
> >others) that's developed and deployed for some uses of my own (though
> >I continue to add featurism) but is not released yet. There are
> >enough free alternatives that I doubt this one will be free.
>
> Why did you decide to write your own web server? What features were you
> missing in the free and commercial alternatives out there? :-?
When I started out, there was mostly only CL-HTTP. It seemed
heavyweight in terms of its interface; it didn't seem intuitive to me.
I've used some ad hoc lispy web servers with more lightweight
interfaces and wanted to experiment with that as a separable module
instead of continuing to write little ad hoc ones for the rest of my
life.
It was a great surprise to me when AllegroServe came out. I was almost
ready to deploy, and the fact that it was free sofwtare undercut a lot of
unpaid work I'd done hoping to sell a server. Given that there was
a free version out, I had to revamp my rollout strategy and it remains to
be seen if I will ever recover what I have invested in the creation of mine.
I can't discuss what I plan to do in advance of rollout exactly
because at this point I'm seeking to make my version commercially
viable by having a unique set of product features. There is a good
chance that if I told you the features, some "helpful" person would
just duplicate them in AllegroServe and I'd again have lost more
investment. Right now I'm playing "double or nothing" on my original
investment, and might just lose several tens of thousands of dollars
in lost wages for having gone this way. But so it goes.
It's also slightly possible that I may not sell my version at all. I
might just use it as a proprietary way for me to build applications
that are unencumbered by the legal issues surrounding the other
alternatives. Or I might use it as a way of augmenting my personal
value as a consultant. I just haven't decided.
I look forward to getting far enough that I can say one way or another
what my total plan is and to be able to discuss what mine can do.
I'm sorry I can't do that right now.
Kent M Pitman <······@world.std.com> wrote:
: I have a web server (I rolled my own; not related to any of the
: others) that's developed and deployed for some uses of my own (though
: I continue to add featurism) but is not released yet.
do you have at least a feature map compared to aserve and cl-httpd?
or maybe apache if one cares, but apache might be too complicated and
old-fashioned.
* non-blocking IO or multithreaded?
* builtin session/state support?
* newbie aware? (probably not)
* which goodies?
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Reini Urban <······@x-ray.at> writes:
> Kent M Pitman <······@world.std.com> wrote:
> : I have a web server (I rolled my own; not related to any of the
> : others) that's developed and deployed for some uses of my own (though
> : I continue to add featurism) but is not released yet.
>
> do you have at least a feature map compared to aserve and cl-httpd?
I explained in another post why I can't answer this in general, but...
> or maybe apache if one cares, but apache might be too complicated and
> old-fashioned.
>
> * non-blocking IO or multithreaded?
I don't understand what "non-blocking IO" is; at least, not by name.
What does this term imply?
> * builtin session/state support?
> * newbie aware? (probably not)
Not sure what this would imply. Are you just making up buzzwords
or is there an articulatable need here?
> * which goodies?
Kent M Pitman <······@world.std.com> writes:
> Reini Urban <······@x-ray.at> writes:
>
> > Kent M Pitman <······@world.std.com> wrote:
> > : I have a web server (I rolled my own; not related to any of the
> > : others) that's developed and deployed for some uses of my own (though
> > : I continue to add featurism) but is not released yet.
> >
> > do you have at least a feature map compared to aserve and cl-httpd?
>
> I explained in another post why I can't answer this in general, but...
>
> > or maybe apache if one cares, but apache might be too complicated and
> > old-fashioned.
> >
> > * non-blocking IO or multithreaded?
>
> I don't understand what "non-blocking IO" is; at least, not by name.
> What does this term imply?
Try to read a character from a stream, if none is available, indicate
this. If the stream is closed, indicate this too, differently.
Possibly, "call this call-back when a character is available". I think
I've seen IO implemented that way too.
//Ingvar
--
A routing decision is made at every routing point, making local hacks
hard to permeate the network with.
Ingvar Mattsson <······@bofh.se> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Reini Urban <······@x-ray.at> writes:
> >
> > > * non-blocking IO or multithreaded?
> >
> > I don't understand what "non-blocking IO" is; at least, not by name.
> > What does this term imply?
>
> Try to read a character from a stream, if none is available, indicate
> this.
Is this asking the question, did I implement READ-CHAR-NO-HANG or something
else? I abhor dabbling in such matters, preferring this to be a vendor
issue. None of my substrate uses such an operation, so if a user wanted to
do it I guess they'd talk to their vendor about whether their socket streams
supported it. I could be entirely missing your point, of course. But it
seems to me that this isn't a question about the server, which is simply
an application program.
As far as I am aware, correct operation of a web server generally doesn't
get involved in this. (I haven't implemented Keep-Alive, which might need
this, so maybe at that point I'll change my mind.) But other than that,
I would expect that read operations naturally block (and should block) if
the other end of stream is not forthcoming with data. As to timeout,
I also haven't dealt with this, though it's on my list to look at as well.
> Possibly, "call this call-back when a character is available". I think
> I've seen IO implemented that way too.
Hmm. Where/how do people prefer to specify this? It sounds like it should
be a per-stream option, not a per-I/O-operation option, since it would be
downright tedious to manage this on every call to read-char. I could
probably encapsulate the socket stream with something that does
read-char-no-hang and then if no char is there hangs for a per-stream timeout
duration before giving up. Is that how this would normally be done?
One reason I'm writing the server is to flesh out my understanding of the
issues involved.
Kent M Pitman <······@world.std.com> writes:
> Ingvar Mattsson <······@bofh.se> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > Reini Urban <······@x-ray.at> writes:
> > >
> > > > * non-blocking IO or multithreaded?
> > >
> > > I don't understand what "non-blocking IO" is; at least, not by name.
> > > What does this term imply?
> >
> > Try to read a character from a stream, if none is available, indicate
> > this.
>
> Is this asking the question, did I implement READ-CHAR-NO-HANG or something
> else? I abhor dabbling in such matters, preferring this to be a vendor
> issue. None of my substrate uses such an operation, so if a user wanted to
> do it I guess they'd talk to their vendor about whether their socket streams
> supported it. I could be entirely missing your point, of course. But it
> seems to me that this isn't a question about the server, which is simply
> an application program.
>
> As far as I am aware, correct operation of a web server generally doesn't
> get involved in this. (I haven't implemented Keep-Alive, which might need
> this, so maybe at that point I'll change my mind.) But other than that,
> I would expect that read operations naturally block (and should block) if
> the other end of stream is not forthcoming with data. As to timeout,
> I also haven't dealt with this, though it's on my list to look at as well.
Yes and no, if I use threads, I'd prefer a blocking version (blockibng
for the thread, that is), if I write single-threaded, multiple-session
code, I prefer using non-blocking.
> > Possibly, "call this call-back when a character is available". I think
> > I've seen IO implemented that way too.
>
> Hmm. Where/how do people prefer to specify this? It sounds like it should
> be a per-stream option, not a per-I/O-operation option, since it would be
> downright tedious to manage this on every call to read-char. I could
> probably encapsulate the socket stream with something that does
> read-char-no-hang and then if no char is there hangs for a per-stream timeout
> duration before giving up. Is that how this would normally be done?
> One reason I'm writing the server is to flesh out my understanding of the
> issues involved.
The implementation I've looked slightly at is the asynchronous IO
under VMS and there you specify a callback at opening (well, I think
you can change the callback at any point, but ask someone who programs
VMS about that). Quite neat, in a way, but it's very different from
"normal" IO.
//Ingvar
--
"Reptilian slimeball namespace with your mind."
Pfy
Ingvar Mattsson <······@bofh.se> writes:
> ... if I use threads, I'd prefer a blocking version (blockibng
> for the thread, that is),
Blocking is naturally what you get in all Lisps, of course. So if you
confine yourself to multi-tasking lisps, you're all set, yes?
> if I write single-threaded, multiple-session
> code, I prefer using non-blocking.
Is the desire for a single-threaded version in a Lisp that has multi-threading
of some theoretical value that I'm missing? Or is a single-threaded server
just something you want to have in case you're deploying in a Lisp without
multi-tasking. I've never run into a case where I'd want to turn off
multi-tasking, but the world is a big place and I'm wondering if there's
someone out there who can enlighten me as to why one might sometimes want
to do that... Even if you wrote your own scheduler, I could see reasons to
want the other scheduler to be present, but maybe aficionados of schedulers
could tell me why that will give pathologically bad behavior in some case.
(I can sort of vaguely imagine how that would be, but it's the sort of thing
that would require carefuli study to confirm.)
> > > Possibly, "call this call-back when a character is available". I think
> > > I've seen IO implemented that way too.
> >
> > Hmm. Where/how do people prefer to specify this? It sounds like it should
> > be a per-stream option, not a per-I/O-operation option, since it would be
> > downright tedious to manage this on every call to read-char. I could
> > probably encapsulate the socket stream with something that does
> > read-char-no-hang and then if no char is there hangs for a per-stream timeout
> > duration before giving up. Is that how this would normally be done?
> > One reason I'm writing the server is to flesh out my understanding of the
> > issues involved.
>
> The implementation I've looked slightly at is the asynchronous IO
> under VMS and there you specify a callback at opening (well, I think
> you can change the callback at any point, but ask someone who programs
> VMS about that). Quite neat, in a way, but it's very different from
> "normal" IO.
Ah. Yes, if Lisp offered such an I/O model it would make sense. For
portability reasons, though, since Lips uses streams, I plan not to
try to do such a thing, though if someone made a general purpose API
to such a facility and then got a bunch of vendors to implement the
hooks for a standard API, I'd be happy to play with it... it does sound
like great "fun". I just have little patience with non-Lisp syntax or
documentation.
I just don't personally feel the urge to be a system programmer. Lisp is
supposed to BE the operating system, whether or not it is in reality. Like
some have said about Emacs, too, it bundles up the operating system and
shields application programmers from direct contact. (Yes, you can write
an OS in Lisp a la Symbolics, too, but that's not what I mean. I meant more
metaphorically.)
Kent M Pitman <······@world.std.com> writes:
> Ingvar Mattsson <······@bofh.se> writes:
>
> > ... if I use threads, I'd prefer a blocking version (blockibng
> > for the thread, that is),
>
> Blocking is naturally what you get in all Lisps, of course. So if you
> confine yourself to multi-tasking lisps, you're all set, yes?
I'd think so. When I write lisp, I try not to care how it works in the
depth of the machine (well, not *too* mucha nd not until it looks like
it may have performance issues).
> > if I write single-threaded, multiple-session
> > code, I prefer using non-blocking.
>
> Is the desire for a single-threaded version in a Lisp that has multi-threading
> of some theoretical value that I'm missing? Or is a single-threaded server
> just something you want to have in case you're deploying in a Lisp without
> multi-tasking. I've never run into a case where I'd want to turn off
> multi-tasking, but the world is a big place and I'm wondering if there's
> someone out there who can enlighten me as to why one might sometimes want
> to do that... Even if you wrote your own scheduler, I could see reasons to
> want the other scheduler to be present, but maybe aficionados of schedulers
> could tell me why that will give pathologically bad behavior in some case.
> (I can sort of vaguely imagine how that would be, but it's the sort of thing
> that would require carefuli study to confirm.)
Heh, only time I've done it was when writing in C (having a scheduler
consisting of (essentially) round-robin between connected clients,
with as little state as I could get away with kept per client/server
session) and the main reason was that writing threaded C code is more
unportable than I could be bothered with.
//Ingvar
--
"No. Most Scandiwegians use the same algorithm as you Brits.
"Ingvar is just a freak."
Stig Morten Valstad, in the Monastery
* Kent M Pitman <······@world.std.com>
| Ingvar Mattsson <······@bofh.se> writes:
|
| > if I write single-threaded, multiple-session
| > code, I prefer using non-blocking.
|
| Is the desire for a single-threaded version in a Lisp that has
| multi-threading of some theoretical value that I'm missing? Or is a
| single-threaded server just something you want to have in case
| you're deploying in a Lisp without multi-tasking. I've never run
| into a case where I'd want to turn off multi-tasking, but the world
| is a big place and I'm wondering if there's someone out there who
| can enlighten me as to why one might sometimes want to do
| that... Even if you wrote your own scheduler, I could see reasons to
| want the other scheduler to be present, but maybe aficionados of
| schedulers could tell me why that will give pathologically bad
| behavior in some case. (I can sort of vaguely imagine how that
| would be, but it's the sort of thing that would require carefuli
| study to confirm.)
Webservers that don't use a thread for each concurrent connection
excel in serving large files over low-bandwidth connections. If
you're mostly, say, serving movie clips to thousands of Internet users
with dialup connections, the number of threads can become a problem if
you use one thread per connection. And because all they do is copy
data to the socket once in a while, you may as well get rid of them.
Here's a paper about one such server (not written in Lisp):
Vivek S. Pai, Peter Druschel, and Willy Zwaenepoel, "Flash: An
efficient and portable web server," in Proceedings of the 1999
Annual Usenix Technical Conference, Monterey, Calif., June 1999.
<URL:http://www.ljosa.com/~ljosa/199.pdf>
--
Vebjorn Ljosa
Vebjorn Ljosa schrieb:
> * Kent M Pitman <······@world.std.com>
> | Ingvar Mattsson <······@bofh.se> writes:
> |
> | > if I write single-threaded, multiple-session
> | > code, I prefer using non-blocking.
> Webservers that don't use a thread for each concurrent connection
> excel in serving large files over low-bandwidth connections. If
> you're mostly, say, serving movie clips to thousands of Internet users
> with dialup connections, the number of threads can become a problem if
> you use one thread per connection. And because all they do is copy
> data to the socket once in a while, you may as well get rid of them.
I'd rather say the problem is serving a LOT of clients with small data.
~ 700 hits/second.
Not so the movie server sample. With such big files a separate thread
(spawned in advance as apache does) can better serve the client.
But for example the non-blocking thttpd or new python medusa is by far better
than apache which does the ordinary one thread-per-client. This needs a
lot of memory and the worst problem (for me) is the session handling.
Another major problem are the different MP lisp packages.
I never did non-blocking IO and it looks pretty complicated to me, but I
have the vague feeling that it would be much easier than with perl or python.
these are the only examples I know of. That's why I was asking.
> Here's a paper about one such server (not written in Lisp):
> Vivek S. Pai, Peter Druschel, and Willy Zwaenepoel, "Flash: An
> efficient and portable web server," in Proceedings of the 1999
> Annual Usenix Technical Conference, Monterey, Calif., June 1999.
> <URL:http://www.ljosa.com/~ljosa/199.pdf>
To "newbie awareness" later. This is not just a buzzword.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Reini Urban <······@x-ray.at> writes:
> Another major problem are the different MP lisp packages. I never
> did non-blocking IO and it looks pretty complicated to me, but I
> have the vague feeling that it would be much easier than with perl
> or python. these are the only examples I know of. That's why I was
> asking.
I've played around with non-blocking IO for sockets with Corman
Lisp. My latest version of the sockets package using non blocking
sockets and WaitForMultipleEvents to check or wait for events in the
queue and simulate blocking sockets. The idea was to allow breaking
out of what was normally a blocking socket operation and to experiment
with 'medusa' style web servers. Never got around to the latter
though. The sockets package will be available for download soon.
Chris.
--
http://www.double.co.nz/cl
Kent M Pitman wrote:
> Reini Urban <······@x-ray.at> writes:
>
>> Kent M Pitman <······@world.std.com> wrote:
>> : I have a web server (I rolled my own; not related to any of the
>> : others) that's developed and deployed for some uses of my own (though
>> : I continue to add featurism) but is not released yet.
>>
>> do you have at least a feature map compared to aserve and cl-httpd?
>
> I explained in another post why I can't answer this in general, but...
>
>> or maybe apache if one cares, but apache might be too complicated and
>> old-fashioned.
>>
>> * non-blocking IO or multithreaded?
>
> I don't understand what "non-blocking IO" is; at least, not by name.
> What does this term imply?
When writing server Software there are at least 3 possible approaches for
handling multiple simultaneous requests:
1) Fork multiple complete processes (UNIX fork() Approach)
This is what e. g. Servers like Apache do.
2) Run one process have multiple threads (lightweight processes...) for the
Requesthandling.
3) Run one process and only one thread of execution but have a central
"dispatching" loop that listens on multiple sockets in non-blocking mode
(if no data is available the programm continues to listen on another
socket)
1. is a interesting idea if the OS doesn't support Kernelthreads but the
server should use SMP systems efficiently.
2 and 3 are good ideas because you can share program resources easier.
If you have Kernelthreads 2. would combine the gain from 1 and 2/3.
CL-HTTP and AllegroServe use Approach 2 (Lightweight Processes).
I'm not sure but AFAIK CL-HTTP supports Approach 3 for CMUCL through
SERVE-EVENT...
ciao,
Jochen
--
http://www.dataheaven.de
In article <············@rznews2.rrze.uni-erlangen.de>, ···@dataheaven.de
says...
> 1) Fork multiple complete processes (UNIX fork() Approach)
> This is what e. g. Servers like Apache do.
> 2) Run one process have multiple threads (lightweight processes...) for the
> Requesthandling.
> 3) Run one process and only one thread of execution but have a central
> "dispatching" loop that listens on multiple sockets in non-blocking mode
> (if no data is available the programm continues to listen on another
> socket)
>
> CL-HTTP and AllegroServe use Approach 2 (Lightweight Processes).
AllegroServe will also do Approach 1 on Unix. I haven't used it in this
mode very much so it's still experimental. There are advantages
to it (a gc in one process won't stop your site from being responsive
as the other Lisp processes automatically take over serving requests).
There are disadvantages (no automatic shared state between requests,
and doing dynamic updates of the web site is more difficult).
-john foderaro
franz inc.
John Foderaro wrote:
> In article <············@rznews2.rrze.uni-erlangen.de>, ···@dataheaven.de
> says...
>> 1) Fork multiple complete processes (UNIX fork() Approach)
>> This is what e. g. Servers like Apache do.
>> 2) Run one process have multiple threads (lightweight processes...) for
>> the
>> Requesthandling.
>> 3) Run one process and only one thread of execution but have a central
>> "dispatching" loop that listens on multiple sockets in non-blocking
>> mode (if no data is available the programm continues to listen on
>> another
>> socket)
>>
>> CL-HTTP and AllegroServe use Approach 2 (Lightweight Processes).
>
> AllegroServe will also do Approach 1 on Unix. I haven't used it in this
> mode very much so it's still experimental. There are advantages
> to it (a gc in one process won't stop your site from being responsive
> as the other Lisp processes automatically take over serving requests).
> There are disadvantages (no automatic shared state between requests,
> and doing dynamic updates of the web site is more difficult).
Oh - yes true - I forgot this fact.
I've implemented the necessary code for Portable AllegroServe too but never
tried if it works there...
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> Kent M Pitman wrote:
>
>> Reini Urban <······@x-ray.at> writes:
>>
>>> Kent M Pitman <······@world.std.com> wrote:
>>> : I have a web server (I rolled my own; not related to any of the
>>> : others) that's developed and deployed for some uses of my own (though
>>> : I continue to add featurism) but is not released yet.
>>>
>>> do you have at least a feature map compared to aserve and cl-httpd?
>>
>> I explained in another post why I can't answer this in general, but...
>>
>>> or maybe apache if one cares, but apache might be too complicated and
>>> old-fashioned.
>>>
>>> * non-blocking IO or multithreaded?
>>
>> I don't understand what "non-blocking IO" is; at least, not by name.
>> What does this term imply?
>
> When writing server Software there are at least 3 possible approaches for
> handling multiple simultaneous requests:
>
> 1) Fork multiple complete processes (UNIX fork() Approach)
> This is what e. g. Servers like Apache do.
> 2) Run one process have multiple threads (lightweight processes...) for
> the
> Requesthandling.
> 3) Run one process and only one thread of execution but have a central
> "dispatching" loop that listens on multiple sockets in non-blocking
> mode (if no data is available the programm continues to listen on
> another
> socket)
>
> 1. is a interesting idea if the OS doesn't support Kernelthreads but the
> server should use SMP systems efficiently.
> 2 and 3 are good ideas because you can share program resources easier.
>
> If you have Kernelthreads 2. would combine the gain from 1 and 2/3.
>
> CL-HTTP and AllegroServe use Approach 2 (Lightweight Processes).
> I'm not sure but AFAIK CL-HTTP supports Approach 3 for CMUCL through
> SERVE-EVENT...
Just to add another point:
If the Lispsystem only supports non-Kernel threads it is important to run
the OS' sockets _always_ in non-blocking mode. This is what LW e.g. does
(at least on Linux). If you would not do so, all threads will stop running
if one thread is waiting for I/O.
I've observed this when I implemented SSL support for LispWorks.
The Lispsystem has to provide blocking on a higher level (at Lisplevel)
again then...
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> When writing server Software there are at least 3 possible approaches for
> handling multiple simultaneous requests:
>
> 1) Fork multiple complete processes (UNIX fork() Approach)
> This is what e. g. Servers like Apache do.
> 2) Run one process have multiple threads (lightweight processes...) for the
> Requesthandling.
> 3) Run one process and only one thread of execution but have a central
> "dispatching" loop that listens on multiple sockets in non-blocking mode
> (if no data is available the programm continues to listen on another
> socket)
That (3) sounds like a really really dumb idea. Why eat CPU by
polling each stream repeatedly, when you can go to sleep and let the
OS wake you up when something happens?
4) Run one process and only one thread of execution but have a central
"dispatching" loop that calls select() and only reads from a stream
when there is data in that stream waiting to be read
This is what SERVE-EVENT in CMUCL and SBCL does. It encapsulates the
select() call and runs user-supplied callback functions when a given
stream is available for reading or writing.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> When writing server Software there are at least 3 possible approaches for
>> handling multiple simultaneous requests:
>>
>> 1) Fork multiple complete processes (UNIX fork() Approach)
>> This is what e. g. Servers like Apache do.
>> 2) Run one process have multiple threads (lightweight processes...) for
>> the
>> Requesthandling.
>> 3) Run one process and only one thread of execution but have a central
>> "dispatching" loop that listens on multiple sockets in non-blocking
>> mode (if no data is available the programm continues to listen on
>> another
>> socket)
>
> That (3) sounds like a really really dumb idea. Why eat CPU by
> polling each stream repeatedly, when you can go to sleep and let the
> OS wake you up when something happens?
You've understood me wrong - Approach 3 is by fact best implemented by e.
g. select() or similar techniques.
> 4) Run one process and only one thread of execution but have a central
> "dispatching" loop that calls select() and only reads from a stream
> when there is data in that stream waiting to be read
>
> This is what SERVE-EVENT in CMUCL and SBCL does. It encapsulates the
> select() call and runs user-supplied callback functions when a given
> stream is available for reading or writing.
nonsense - 4 is the same approach as my 3 approach - the emphasis lies on
"dispatch" not on dummy-polling as you might have interpreted it
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> Daniel Barlow wrote:
>
> > Jochen Schmidt <···@dataheaven.de> writes:
> >
> >> 3) Run one process and only one thread of execution but have a central
> >> "dispatching" loop that listens on multiple sockets in non-blocking
> >> mode (if no data is available the programm continues to listen on
> >> another
> >> socket)
> >
> > That (3) sounds like a really really dumb idea. Why eat CPU by
> > polling each stream repeatedly, when you can go to sleep and let the
> > OS wake you up when something happens?
>
> You've understood me wrong - Approach 3 is by fact best implemented by e.
> g. select() or similar techniques.
OK, I misunderstood you. When you said non-blocking I assumed that
you meant the usual unix definition of non-blocking: that reads return
immediately if nothing is to be read, instead of waiting for something
to arrive.
If you're using a select() - or poll() - loop you will only be
attempting to read from a socket when there _is_ data available on it.
That's the point of select(). It won't block anyway (unless you read
from it multiple times), so non-blocking mode is a red herring.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> Daniel Barlow wrote:
>>
>> > Jochen Schmidt <···@dataheaven.de> writes:
>> >
>> >> 3) Run one process and only one thread of execution but have a central
>> >> "dispatching" loop that listens on multiple sockets in non-blocking
>> >> mode (if no data is available the programm continues to listen on
>> >> another
>> >> socket)
>> >
>> > That (3) sounds like a really really dumb idea. Why eat CPU by
>> > polling each stream repeatedly, when you can go to sleep and let the
>> > OS wake you up when something happens?
>>
>> You've understood me wrong - Approach 3 is by fact best implemented by e.
>> g. select() or similar techniques.
>
> OK, I misunderstood you. When you said non-blocking I assumed that
> you meant the usual unix definition of non-blocking: that reads return
> immediately if nothing is to be read, instead of waiting for something
> to arrive.
>
> If you're using a select() - or poll() - loop you will only be
> attempting to read from a socket when there _is_ data available on it.
> That's the point of select(). It won't block anyway (unless you read
> from it multiple times), so non-blocking mode is a red herring.
I would not call non-blocking a red herring - I would call select() a red
herring since it simply wraps up proper polling including notifiying
the process when I/O us possible. You _could_ do the same by using fcntl()
and signals - but why doing it by hand if a utility is handy that does it
for you. (Note that select() is not available on every OS! Sometimes this
approach is _really_ implemented by the programmer as setting the socket to
non-blocking mode and registering the socket with some notification
facility...)
Regardless of how to see it - they are exactly the same concept.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> I would not call non-blocking a red herring - I would call select() a red
> herring since it simply wraps up proper polling including notifiying
Well, more likely it calls the operating system which puts your task
on some wait queue to be woken up at some point after an interrupt
comes in from the network to tell us that there's more data. So, no
polling involved at all. That makes a big performance difference.
> the process when I/O us possible. You _could_ do the same by using fcntl()
> and signals - but why doing it by hand if a utility is handy that does it
> for you. (Note that select() is not available on every OS! Sometimes this
> approach is _really_ implemented by the programmer as setting the socket to
> non-blocking mode and registering the socket with some notification
> facility...)
If the socket is registered with "some notification facility" -
whether that's implemented by select, poll, POSIX aio, NT's
asynchronous IO, SIGIO or _whatever_ - we will be notified when it's
ready to read. Which is to say, when a read from it will not block.
So I still don't see why non-blocking mode is relevant.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I would not call non-blocking a red herring - I would call select() a red
>> herring since it simply wraps up proper polling including notifiying
>
> Well, more likely it calls the operating system which puts your task
> on some wait queue to be woken up at some point after an interrupt
> comes in from the network to tell us that there's more data. So, no
> polling involved at all. That makes a big performance difference.
I don't see where you see any difference?
Is it something completely different if the OS takes the task?
>
>> the process when I/O us possible. You _could_ do the same by using
>> fcntl() and signals - but why doing it by hand if a utility is handy that
>> does it for you. (Note that select() is not available on every OS!
>> Sometimes this approach is _really_ implemented by the programmer as
>> setting the socket to non-blocking mode and registering the socket with
>> some notification facility...)
>
> If the socket is registered with "some notification facility" -
> whether that's implemented by select, poll, POSIX aio, NT's
> asynchronous IO, SIGIO or _whatever_ - we will be notified when it's
> ready to read. Which is to say, when a read from it will not block.
> So I still don't see why non-blocking mode is relevant.
Two answers:
1) Not blocking on particular I/O calls _is_ non-blocking I/O...
2) Even if the UNIX socket "non-blocking" mode you imply here is meant
then it is a good idea to use it because if some function in your
system calls a read/write without checking the state, your whole server
will hang. In a Lispsystem like LW this will mean that _all_ threads are
blocking!!! Note that blocking does *not* only occur on READ as you
imply but also on WRITE and CL has no facility like LISTEN for WRITE.
select() includes the state if a WRITE is possible but as I said saying
that using select() is a complete different thing than polling is a red
herring since nothing other happens. You ever wondered why poll() is
called poll()?
The MAN-page says:
poll - wait for some event on a file descriptor
so I really don't see your point here...
Would you say poll I/O is blocked I/O or what?
For so far this approach is generally called "non-blocking I/O" or
"asynchronous I/O" but certainly not "select() I/O" so I somewhat
wondering why you can't see the "non-blocking" aspect in this topic...
So I still do not see where you see a completely different approach
using select()...
ciao,
Jochen
--
http://www.dataheaven.de
At the risk of making things even more confused let me
say the following.
Unix offers
1. blocking I/O - a read() or write() will only return
after the I/O has been done.
2. non-blocking I/O - read() and write() are also allowed
to return an error code that says that the operation
can't be completed right away, and thus the operation
was not even started.
Unix does not offer (but Windows does for certain devices):
3. asychronous I/O - read() or write() can effectively
return a value "in progress" which means that the I/O
as been started but not yet completed. The program
can check back periodically to see if the I/O is done.
Database people will claim that Unix write()'s are
asychronous since the write returns when the data
is put in a buffer to be written to the disk
and not after it's actually written. For most of
us that distinction doesn't matter.
Blocking and non-blocking modes are essentially
equivalent since if you have a blocking file
descriptor you can pretend it's non-blocking
by doing select() before the read()/write()
to see if it would block.
If you have a non-blocking file descriptor
you can pretend it's blocking by doing a
select() after a read()/write() returns
a code saying that it would block. When
the select says that reading/writing is
possible you loop back and try the read()/write()
again.
As far as poll() vrs select(). 'poll' is a
dirty word. It generally means that you're in a
tight loop burning cpu cycles waiting for something
to occur.
The poll() system call does not poll. Poll was a
poor choice of name for what it does.
poll() is basically a better version of select().
It has a better way of specifying the information
on which file descriptors are of interest and a
better way of returning the status of those
file descriptors.
Both poll() and select() cause the operating
system to note which events are of interest
and then the process is put to sleep until one
of those events occurs or until the certain
amount of time elapses.
-john foderaro
franz inc.
On Sat, 25 Aug 2001, John Foderaro wrote:
> Unix does not offer (but Windows does for certain devices):
>
> 3. asychronous I/O - read() or write() can effectively
> return a value "in progress" which means that the I/O
> as been started but not yet completed. The program
> can check back periodically to see if the I/O is done.
>
FreeBSD supports the "aio" family of asynchronous I/O calls defined in the
POSIX 1003.2 standard (I think that's the real-time stuff); I'm sure it's
not alone, but I don't have any other systems handy or powered on to
check.
Tim
John Foderaro wrote:
> At the risk of making things even more confused let me
> say the following.
>
> Unix offers
> 1. blocking I/O - a read() or write() will only return
> after the I/O has been done.
> 2. non-blocking I/O - read() and write() are also allowed
> to return an error code that says that the operation
> can't be completed right away, and thus the operation
> was not even started.
>
> Unix does not offer (but Windows does for certain devices):
>
> 3. asychronous I/O - read() or write() can effectively
> return a value "in progress" which means that the I/O
> as been started but not yet completed. The program
> can check back periodically to see if the I/O is done.
>
>
>
> Database people will claim that Unix write()'s are
> asychronous since the write returns when the data
> is put in a buffer to be written to the disk
> and not after it's actually written. For most of
> us that distinction doesn't matter.
Yes and that's a rather detailed description on the chaos of notions
that is available on a not very wide range of OS's (UNIX+Win)
So far I hope that it clears up why I don't have thought that it would be
a good idea to complicate things with this implementation
specific stuff if you want to describe multiplexing approaches generally in
a few lines!
> Blocking and non-blocking modes are essentially
> equivalent since if you have a blocking file
> descriptor you can pretend it's non-blocking
> by doing select() before the read()/write()
> to see if it would block.
You have to distinguish the UNIX'ish socket non-blocking mode
and doing non-blocking I/O in general.
You can do non-blocking I/O on sockets that are set to blocking-mode
in unix by using e. g. calls like select() and poll() as already
mentioned. But as I already have said this are UNIXisms and
IMHO it is suboptimal to bring them in a _general_ description
of multiplexing by using non-blocking I/O...
> If you have a non-blocking file descriptor
> you can pretend it's blocking by doing a
> select() after a read()/write() returns
> a code saying that it would block. When
> the select says that reading/writing is
> possible you loop back and try the read()/write()
> again.
>
> As far as poll() vrs select(). 'poll' is a
> dirty word. It generally means that you're in a
> tight loop burning cpu cycles waiting for something
> to occur.
If you read my first post in a generally UNIXsh way of doing things
and not realizing that I tried to use _general_ notions
then one might think that I propose "dummy-polling".
But I made clear that this is not what was meant - and therefore
I think there is _no_ different "event-based" fourth approach
in my first description like Dan implied.
> The poll() system call does not poll. Poll was a
> poor choice of name for what it does.
> poll() is basically a better version of select().
> It has a better way of specifying the information
> on which file descriptors are of interest and a
> better way of returning the status of those
> file descriptors.
> Both poll() and select() cause the operating
> system to note which events are of interest
> and then the process is put to sleep until one
> of those events occurs or until the certain
> amount of time elapses.
I've written:
3) Run one process and only one thread of execution but have a central
"dispatching" loop that listens on multiple sockets in non-blocking mode
(if no data is available the programm continues to listen on another
socket)
This does _not_ mean
Run one UNIX process and only one thread of execution but have a central
while() loop (in the UNIX process) that listens on multiple sockets in
UNIX socket non-blocking mode....
But more that
The "central dispatching loop" is under UNIX the kernel scheduler that
wakes up processes if I/O for them is available. And listening on multiple
sockets under unix is e.g. done by select(). Non-blocking means that we do
not block on a particular socket in our socket which is the general idea
behind this approach.
I think I might begin to sound a bit angry now - but I hate it if I try to
describe someone a general concept by using general words and then being
bashed down that I'm not specific enough - sorry.
Kent simply asked what non-blocking IO is in regard to writing Webservers
and I think I answered correctly enough that it is one approach besides
others to do multiplexing requests...
So I say now that I spreaded complete nonsense and dangerous misinformation
and have absolutely no clue on doing multiplexing I/O so that we can stop
this discussion now and begin talking on Lisp again...
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> I've written:
>
> 3) Run one process and only one thread of execution but have a central
> "dispatching" loop that listens on multiple sockets in non-blocking mode
> (if no data is available the programm continues to listen on another
> socket)
From your two explanatory articles, I understand now what you meant, but
have to admit that I also was confused. The source of my confusion was
in the phrase "listens on multiple sockets in non-blocking mode"; it is
not clear from the phrase whether the "non-blocking mode" applies to the
listen (i.e. select/poll call) or to the sockets. The correct answer, of
course, is that it is the sockets that are non-blocking, though that is
not necessary, as John Foderaro pointed out. What is necessary is that
whatever functionality it is that is doing your listening must itself block
until the next event (e.g., any socket becomes available, or else some
other signal occurs asynchronously) otherwise the program will start
wasting cycles.
> So I say now that I spreaded complete nonsense and dangerous misinformation
> and have absolutely no clue on doing multiplexing I/O so that we can stop
> this discussion now and begin talking on Lisp again...
I believe that this discussion is very relevant to CL. CL defines
the cl:listen function very specifically, and it does not allow
listening to more than one stream at a time. However, the lack
here is not in cl:listen's definition, but in the fact that CL does
not define multiprocessing. Note that although the latest part of
this thread has prima facie been about blocking vs non-blocking I/O,
the entire discussion hinges on and assumes some form of multiprocessing.
Without such an assumption, there is nothing to talk about. But many
CL implementatiuons have some sort of multiprocessing facility, so
we are still talking about CL, but instead of talking about standard
CL, we are talking about extensions in all cases.
--
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)
>>>>> "DR" == Duane Rettig <·····@franz.com> writes:
[let me pull one thing possibly out of context:]
[...]
DR> ... Note
DR> that although the latest part of this thread has prima facie
DR> been about blocking vs non-blocking I/O, the entire discussion
DR> hinges on and assumes some form of multiprocessing. Without
DR> such an assumption, there is nothing to talk about.
This confuses me in a way you didn't mean to probably. One of the
reasons one uses facilities like select/poll is to replace multiple
threads with multiple state machines in a single process. So maybe the
point of all this (except for what appears to be violent agreement)
is to avoid MP altogether for things like simple servers. So there is
stuff to talk about w/o assuming MP. But I also know you already know
what I just said, leaving me wondering what you meant?
DR> But many
DR> CL implementatiuons have some sort of multiprocessing
DR> facility, so we are still talking about CL, but instead of
DR> talking about standard CL, we are talking about extensions in
DR> all cases.
Indeed, but I think we are also talking about the non-MP case.
I will muddy the waters even further: The difference I want to stress
between the sigral driven POSIX AIO case and the standard select/poll
is that with AIO you get notification that the IO is complete and your
buffer is ready. So unlike select/poll the copy to userspace takes place
while you do other stuff. For CL, you basically hand over a heap allocated
array and forget about it until you get signalled that it has ben stuffed
with the stuff you asked for. What I am in the dark about is how the GC
would deal with something like this. Do facilities exist to tell GC
not to move certain parts of the heap? Is this a problem at all?
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "DR" == Duane Rettig <·····@franz.com> writes:
> [let me pull one thing possibly out of context:]
> [...]
> DR> ... Note
> DR> that although the latest part of this thread has prima facie
> DR> been about blocking vs non-blocking I/O, the entire discussion
> DR> hinges on and assumes some form of multiprocessing. Without
> DR> such an assumption, there is nothing to talk about.
>
> This confuses me in a way you didn't mean to probably. One of the
> reasons one uses facilities like select/poll is to replace multiple
> threads with multiple state machines in a single process.
I submit, however, that such a state machine is in fact a form
of multiprocessing. In fact, it is exactly how the non os-threads
version works in Allegro CL (i.e. the stack-groups version).
> So maybe the
> point of all this (except for what appears to be violent agreement)
> is to avoid MP altogether for things like simple servers. So there is
> stuff to talk about w/o assuming MP. But I also know you already know
> what I just said, leaving me wondering what you meant?
Perhaps the trouble is in the definitions of multiprocessing we are each
using. I am using the term in a broad sense, to include all forms of
multiprocessing, even those which run on a single operating-system
thread.
> DR> But many
> DR> CL implementatiuons have some sort of multiprocessing
> DR> facility, so we are still talking about CL, but instead of
> DR> talking about standard CL, we are talking about extensions in
> DR> all cases.
>
> Indeed, but I think we are also talking about the non-MP case.
The test is whether you can take such a "non-mp" case and provide
for IO operations on multiple state machiness (efficiently) without
going outside of the CL definition. Perhaps there are ways to do so,
but I can't think of any offhand.
> I will muddy the waters even further: The difference I want to stress
> between the sigral driven POSIX AIO case and the standard select/poll
> is that with AIO you get notification that the IO is complete and your
> buffer is ready. So unlike select/poll the copy to userspace takes place
> while you do other stuff.
Actually, this is not true; a good stack-group/mp implementation will only
lodge the lisp in the select when there is no other work to do. If there
is other work to do, that lisp-process should be doing that work (while
possibly waiting on the sockets that are not yet ready. Note also that
in the AIO case, if there is no other work to do then the lisp will either
wait for the notification or spin anyway. So the two cases are almost
equivalent. The only difference is that when you wait for the socket to
become ready for a single read() operation, the read() occurs all at once, and
you don't have to worry about the gc moving things. Note that even a blocking
read() call might not fill the buffer you give it all at once, so, for example,
to perform a read-sequence the implementation may have to perform a number
of read() calls.
> For CL, you basically hand over a heap allocated
> array and forget about it until you get signalled that it has ben stuffed
> with the stuff you asked for. What I am in the dark about is how the GC
> would deal with something like this. Do facilities exist to tell GC
> not to move certain parts of the heap? Is this a problem at all?
Yes, for AIO this can be a problem if the array to be filled is in the heap.
The problem can be mitigated somewhat by allocating the array in some static
area. But when the final destination is a heap-allocated (i.e. gc-movable)
array, some extra copying would have to be done (unless the gc can be told
to temporarily not move the array).
--
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)
>>>>> "DR" == Duane Rettig <·····@franz.com> writes:
[...]
DR> I submit, however, that such a state machine is in fact a form
DR> of multiprocessing.
I agree.
DR> [...]Perhaps the trouble is in the definitions of multiprocessing
DR> we are each using. I am using the term in a broad sense, to
DR> include all forms of multiprocessing, even those which run on
DR> a single operating-system thread.
Yes. I think I was talking about threads of control known to the
OS scheduler[s?].
[...]
DR> The test is whether you can take such a "non-mp" case and
DR> provide for IO operations on multiple state machiness
DR> (efficiently) without going outside of the CL definition.
DR> Perhaps there are ways to do so, but I can't think of any
DR> offhand.
I take this to mean without select/poll exposed at the CL level.
If so, I agree.
Thanks for the informative posting.
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>> "DR" == Duane Rettig <·····@franz.com> writes:
> [let me pull one thing possibly out of context:]
> [...]
> DR> ... Note
> DR> that although the latest part of this thread has prima facie
> DR> been about blocking vs non-blocking I/O, the entire discussion
> DR> hinges on and assumes some form of multiprocessing. Without
> DR> such an assumption, there is nothing to talk about.
>
> This confuses me in a way you didn't mean to probably. One of the
> reasons one uses facilities like select/poll is to replace multiple
> threads with multiple state machines in a single process. So maybe the
> point of all this (except for what appears to be violent agreement)
> is to avoid MP altogether for things like simple servers. So there is
> stuff to talk about w/o assuming MP. But I also know you already know
> what I just said, leaving me wondering what you meant?
The thread was discussing more the topic of "notification" of I/O events.
These is a critical element of multiprocessing environments. Think of
multiple running threads where one waits for I/O available on a socket.
You can imagine the thread having a wait-predicate that tests with a
function similar to LISTEN if input is available. The problem is now when
this test-predicate is tested. If there is no relation between the socket
and the waiting thread will not awake until some other system event (e.g.
mouse) triggers the testing of the predicate. The best would be to try to
awake the thread (test it's predicate) when I/O is available on the socket.
Therefore a lispsystem that provides MP has to provide some select/poll like
facility so that the user-space threads can be enabled when I/O is
available...
I disagree with the saying that without MP the issue of
blocking/non-blocking I/O is trivial (as Duane seems to imply with saying
that there is nothing to talk about...)
> DR> But many
> DR> CL implementatiuons have some sort of multiprocessing
> DR> facility, so we are still talking about CL, but instead of
> DR> talking about standard CL, we are talking about extensions in
> DR> all cases.
>
> Indeed, but I think we are also talking about the non-MP case.
>
> I will muddy the waters even further: The difference I want to stress
> between the sigral driven POSIX AIO case and the standard select/poll
> is that with AIO you get notification that the IO is complete and your
> buffer is ready. So unlike select/poll the copy to userspace takes place
> while you do other stuff. For CL, you basically hand over a heap
> allocated array and forget about it until you get signalled that it has
> ben stuffed
> with the stuff you asked for. What I am in the dark about is how the GC
> would deal with something like this. Do facilities exist to tell GC
> not to move certain parts of the heap? Is this a problem at all?
This is all a matter of implementation and does not _really_ describe
another concept. E. g. OpenSSLs I/O is asynchronously too if you use
non-blocking mode sockets. You even can let OpenSSL prefetch the data (so
it reads further filling it's buffers even if no read() occurs)
OpenSSL is really good designed in this parts and is IMHO much more useful
than most other approaches of this kind.
To your question regarding to the GC "Problem". These is indeed handled by
the normal FFI facility your Lispsystem provides and is therefore _highly_
system dependent. You do not tell the GC what parts of the heap not to move
- you "simply" allocate your needed memory in a static segment that is not
moved by the GC.
>
> cheers,
>
> BM
--
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> I disagree with the saying that without MP the issue of
> blocking/non-blocking I/O is trivial (as Duane seems to imply with saying
> that there is nothing to talk about...)
I was definitely not implying that it is trivial. However, I do agree
that "nothing to talk about" is a little extreme. Make that "much less
to talk about"...
--
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)
Duane Rettig wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I've written:
>>
>> 3) Run one process and only one thread of execution but have a central
>> "dispatching" loop that listens on multiple sockets in non-blocking
>> mode (if no data is available the programm continues to listen on
>> another
>> socket)
>
> From your two explanatory articles, I understand now what you meant, but
> have to admit that I also was confused. The source of my confusion was
> in the phrase "listens on multiple sockets in non-blocking mode"; it is
> not clear from the phrase whether the "non-blocking mode" applies to the
> listen (i.e. select/poll call) or to the sockets.
Yes - but simply saying "That (3) sounds like a really really dumb idea"
is IMHO the best way to upset someone and not really a kind way of trying
to understand what was meant...
This what at least what me react a bit upset...
> The correct answer, of
> course, is that it is the sockets that are non-blocking, though that is
> not necessary, as John Foderaro pointed out.
Not really - the problems here are deeper as it might seem on the first
glance. It is _really_ more than a good idea to use non-blocking mode
sockets even when using select()/poll() - as e. g. Luis Theran points out
too in another post. select() provides you with a way to get notifications
but if you still use blocking I/O there are myriads of things that may get
wrong. But I still insist on the fact that this are UNIX issues and not
issues of the concept per se. Other implementations provide better ways
and e. g. OpenSSL provides a way of doing non-blocking I/O in a way similar
to the classic UNIX way but better designed in several areas.
I don't think that we are still in Lisp as topics if we discuss how a
particular UNIX C-API implements this concept...
> What is necessary is that
> whatever functionality it is that is doing your listening must itself
> block until the next event (e.g., any socket becomes available, or else
> some other signal occurs asynchronously) otherwise the program will start
> wasting cycles.
Yes but this is not the reason why it is called non-blocking I/O.
And _how_ you interface your API with this "blocking" element can be made
in many different kinds...
>> So I say now that I spreaded complete nonsense and dangerous
>> misinformation and have absolutely no clue on doing multiplexing I/O so
>> that we can stop this discussion now and begin talking on Lisp again...
>
> I believe that this discussion is very relevant to CL. CL defines
> the cl:listen function very specifically, and it does not allow
> listening to more than one stream at a time. However, the lack
> here is not in cl:listen's definition, but in the fact that CL does
> not define multiprocessing.
The existence of LISTEN is not enough for MP (as you my imply) you need
some facility to trigger the wait-predicates of threads that are listening
on sockets. This facility is what is missing in the standard.
> Note that although the latest part of
> this thread has prima facie been about blocking vs non-blocking I/O,
> the entire discussion hinges on and assumes some form of multiprocessing.
> Without such an assumption, there is nothing to talk about. But many
> CL implementatiuons have some sort of multiprocessing facility, so
> we are still talking about CL, but instead of talking about standard
> CL, we are talking about extensions in all cases.
Not _really_ if the topic drifts further in particular UNIXisms instead of
Lisp topics.
ciao,
Jochen
--
http://www.dataheaven.de
In article <··························@news.dnai.com>, John Foderaro wrote:
>Unix does not offer (but Windows does for certain devices):
>
>3. asychronous I/O - read() or write() can effectively
>return a value "in progress" which means that the I/O
>as been started but not yet completed. The program
>can check back periodically to see if the I/O is done.
This information is out of date, since the UNIX interface has
the aio_* functions.
True asynchronous I/O means that you can initiate the
request, and then you are notified when it's done. In the
meanwhile, the system hangs on to your buffer, to minimize
how much copying has to be done. So in the case of output,
your buffer might be used directly by the target device
as a DMA source.
The completion notifications can take various forms:
- message added to a queue (which perhaps supports blocking waits).
- semaphore signal.
- callback function.
Daniel Barlow wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I would not call non-blocking a red herring - I would call select() a red
>> herring since it simply wraps up proper polling including notifiying
>
> Well, more likely it calls the operating system which puts your task
> on some wait queue to be woken up at some point after an interrupt
> comes in from the network to tell us that there's more data. So, no
> polling involved at all. That makes a big performance difference.
I fear the problem is that you think polling is "looping until an I/O event
occurs" - but that is completely wrong - it is simply "waiting until an I/O
event occurs"!
What you probably mean is "dummy polling" which would mean implementing the
waiting as a simple loop.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> wrote:
+---------------
| Daniel Barlow wrote:
| > Well, more likely it calls the operating system which puts your task
| > on some wait queue to be woken up at some point after an interrupt
| > comes in from the network to tell us that there's more data. So, no
| > polling involved at all. That makes a big performance difference.
|
| I fear the problem is that you think polling is "looping until an I/O event
| occurs" - but that is completely wrong - it is simply "waiting until an
| I/O event occurs"! What you probably mean is "dummy polling" which would
| mean implementing the waiting as a simple loop.
+---------------
I fear it is you who have somwhere learned a non-standard meaning of
"polling". Classically, what you are calling "dummy polling" is in
fact what everyone else know as simply "polling" -- testing some predicate
repeatedly, as impatient children do in the car: "Are we there yet?
Are we there yet? Are we there yet...?"
It meant that as far back as 1970 (if not before), when it applied to
such things as:
- Deciding which of a number of senders on a "polled multi-drop" shared
modem line should be granted access to send. The master node "polled"
each slave in turn, over & over, until one of the slaves replied with
non-null data (instead of a "I have nothing to do" response to the poll).
["Hub go-ahead polling" was a variant in which each node could hear all
the others, and thus no explicit "master" was needed, since the poll
sequence could be implicit. When you heard the station whose sequence
number wass just below yours say "Nothing more to send", you knew you
could go ahead and send. Datapoint's ARCnet worked that way.]
- A scheduler for an embedded application, where continuous polling
for each of the possible input events was sometimes much more
efficient that allowing interrupts. [In fact, our group has written
on-board firmware that works exactly that way quite recently.]
So polling does mean looping -- whether over one test or many -- until
(one of) the test(s) succeeds.
As another poster observed, the Unix System-V system call of that name
is *VERY* badly mis-named, since it actually doesn't "poll" at all.
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Daniel Barlow <···@telent.net> writes:
>
> If you're using a select() - or poll() - loop you will only be
> attempting to read from a socket when there _is_ data available on it.
> That's the point of select(). It won't block anyway (unless you read
> from it multiple times), so non-blocking mode is a red herring.
UNIX doesn't guarantee that some other process didn't read from or
write to the descriptor. Some kernels also return from select() on a
pipe when there are (potentially) many fewer than PIPE_BUF bytes
available to write.
(This is a UNIX and not a Lisp issue. But always use nonblock
operations after select() or poll().)
^L
In article <··············@balder.seapine.com> you wrote:
: Also, I remember a thread here not too far back talking about doing
: HTML in Lisp[3]. There didn't seem to be much concensus. Some said
: python was better for the task than lisp; others said no.
that must be me.
but you got it wrong. Lisp is much better than python or all
other languages (perl, c++, java, php, ...) doing web development.
the problem was more of practical nature. I didn't have enough time and I
didn't bother to maintain or inmprove it afterwards. otherwise I would have
invested in developing the needed tools in lisp, which e.g. zope or tomcat
or the mod_perl based frameworks already have.
for e-commerce I would write it from scratch. everything out there is a crap,
it can be written in lisp in 2-3 months.
tomcat is nice, has more, but lisp in the end is much better.
compared to mod_perl even more.
python is just the best of the crap.
btw: I also rejected zope after having ported 50% from the old JSP app to
python and did it in php now (95% finished). php is a pain. but I have a lot
of people there helping out and fixing tiny stuff (html mess, translations,
business logic). nevertheless I wouldn't want to repeat this experience. I
introduced a lot of lisp-style functionality into this app but the
colleagues didn't get it and the public parts were rejected to be included
into the core (so far. maybe in three months). it was too complicated and
abstract. I also critized their sql habits (no indices, no transaction
safety, no merge tables with mysql,
...), so that didn't help either. it's a big mess, very slow, but it is very
fast to understand.
the moral:
* it worked this way and it would have worked in perl or python or java also.
* in lisp I would have been happy, but alone.
* in php my colleagues and my boss is happy and I don't care that much.
* macros are really the best lisp feature.
* next time clisp, not cmucl in which I initially started. solely because
of the windows port. and my lisp colleague will be back from the army service
then.
: [3] http://groups.google.com/groups?hl=en&safe=off&th=c3f14153a37c0212,13&start=0
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Reini Urban <······@x-ray.at> writes:
> the moral:
> * it worked this way and it would have worked in perl or python or java also.
> * in lisp I would have been happy, but alone.
> * in php my colleagues and my boss is happy and I don't care that much.
> * macros are really the best lisp feature.
> * next time clisp, not cmucl in which I initially started. solely because
> of the windows port. and my lisp colleague will be back from the army service
> then.
This is pretty much what I've concluded without even starting. Since
I'm not part of some company, I don't worry too much about colleagues
and boss. I do worry about not being able to find help when I hit the
wall. I would also like to someday take on a partner to try the XP
Pair Programming thing.
Hmm, why is the windows port valuable to you? Are you constrained by
what platform you need to run on? Are you selling your software to a
client who chooses the platform? Or is it an internal decision to
host on windows?
--
(__) Doug Alcorn (···········@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
Doug Alcorn schrieb:
> Reini Urban <······@x-ray.at> writes:
>
> > the moral:
> > * it worked this way and it would have worked in perl or python or java also.
> > * in lisp I would have been happy, but alone.
> > * in php my colleagues and my boss is happy and I don't care that much.
> > * macros are really the best lisp feature.
> > * next time clisp, not cmucl in which I initially started. solely because
> > of the windows port. and my lisp colleague will be back from the army service
> > then.
>
> This is pretty much what I've concluded without even starting. Since
> I'm not part of some company, I don't worry too much about colleagues
> and boss. I do worry about not being able to find help when I hit the
> wall. I would also like to someday take on a partner to try the XP
> Pair Programming thing.
In fact I'm also my own boss. But I run out of time eventually (tight
deadlines)
and I need some other people to fix stuff, quick and now. "my boss" from the
quote above really is the client. he didn't argue against lisp at all, btw.
A partner for php pair programming is not really challenging :) Tried it.
Hitting the wall in php is also no issue :)
I did pair programming a couple of times in lisp (autolisp) and we loved it.
For common lisp I'll have to wait. It always turned out that someone does
the high-level and the other the low-level parts, but never in parallel.
> Hmm, why is the windows port valuable to you? Are you constrained by
> what platform you need to run on? Are you selling your software to a
> client who chooses the platform? Or is it an internal decision to
> host on windows?
I host on linux and develop on windows for years. I don't want to switch
development
to linux because I prefer the windows tools combined with cygwin by far.
With cmucl I have to sit on my ugly linux box which shouldn't really run X.
I'm thinking of switching over to cormanlisp with portable allegroserve.
This seems to be the best. ACL is just too expensive. I love the cmucl and
corman sources.
In the meantime my friend rudi schlatte is desperatly trying to port
SBCL to windows. It's still crashing on some signals. SBCL's python type
inferencer is super, the sources are great, but CLOS (PCL) is now much faster
in corman than in SBCL/cmucl.
whenever I manage windows not to leak too much (so far 3-4 days rebooting
cycles for the server) and not to spent too much RAM, I'll switch over from
linux to windows.
my neighbor is a crazy one. he's running his massive tourism search engine
on a stripped down win2k server with MS Jet (!) and IIS. it works fine, is
very
fast with only 1 Gig RAM and doesn't leak.
he tried oracle, mysql, ms sql and postgres also. hmm, jet... but I have to
believe him. jet should be really good in deep link trees, compared to
oracle or mysql.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Doug Alcorn <·····@seapine.com> writes:
> I've been doing a lot of reading on lisp for the past several months.
> I have a little experience writing elisp for my daily emacs usage but
> that's about it. I hear of all kinds of advantages of lisp. Then I
> come across Erann Gat's study, "Lisp as an Alternative to Java"[1].
> Also, Paul Graham's article, "Beating the Averages"[2], about using
> lisp for web stuff. This and other stuff I've read make me want to
> try this new project in lisp instead of Java.
You could take a middle-ground approach and use Kawa Scheme (not CL),
which is Java-based. You can use the JVM and Java objects without using
the Java language.
I think you'll find my Beautiful Report Language (BRL) an attractive
alternative to JSP that can coexist with JSP/servlet-based apps, even
sharing session variables.
--
Bruce R. Lewis http://brl.sourceforge.net/
I rarely read mail sent to ·······@my-deja.com