More than anyone else here, this message is to you, Erik, because you are
the day to day expression of everything that is wrong with C.L.L.
Samir Barjoud (can now legally drink, but why?)
it must be great to be able to find someone to blame for all ills or
evils you see. I wish I had the intellectual capacity for this
simplicity, sometimes. understanding the more complex interplay of
factors is such an _effort_ most of the time.
if people came with documentation, could men get the womanual?
* wle...@mailbag.com (William Barnett-Lewis)
| More than anyone else here, this message is to you, Erik, because you are
| the day to day expression of everything that is wrong with C.L.L.
I enjoy most of the *off topics* the news group has but this personality analysis should be carried on by personal email. If Erick wants to boil someone in oil in public...it is his business. If you wish to take issue with Erick please email him directly.
Hmmm strange how a news group reflects life in general.
Neither Erick or any one's _personality_ is going to influence the future of lisp to any extent. So please let's give it a rest and put the time to better use.....writing lisp. Writing lisp and lisp programs might help lisp more or maybe start a lisp user group at your local college. I stopped by Texas Christian University library not to long ago; the last time a lisp or scheme book of any kind was checked out by a student was 1993. There were _six_ books on lisp or scheme...and you know they don't even know Erick. (there were three full sections on java).
One of the students at TCU is helping me put muLisp on an EPROM. The professor was in the lab talking to us while we were working. I ran a lisp (muLisp) program for him that contained an algorithm that Gareth McCaughan cooked up for serial data gathering. I can not say that I made a convert but he is ordering muLisp for the department even though they do little or no DOS (muLisp is a DOS program) work.
As I said in my first posting to this NG....lisp on the other end of things that is small, fast, low-level has a place in the world. Controlls machines, electornics, and communications. If you have ever made little machines go with Forth we will love doing it with lisp.....you can maintain your code, remember what a piece of code does and how it does it. If you don't have a little machine, well get one and muLisp. Beats the hell out of tring to develope personalities online.
btw Erick I am interested in your 99.95% uptime and how your run your test application in parallel with production. Does your application not have a "dayend" process for backup, archive, billing etc or do you count this as uptime also?
muLisp a machine and smile
the uptime statistics are for the hours of regular operation, that is
from 04:00 through 23:00 on weekdays and from 18:00 through 23:00 on
Sundays. outside those hours, the system can be taken down for (major)
upgrades. we have start of day reset at 00:00 which basically unloads
all the heavy objects (they are loaded back from disk if needed) and runs
a global GC. there's also a start of week reset at Sunday 00:00. (both
are run manually if the system needs downtime in the off hours.) backup
is not disruptive. other administrative functions run concurrently with
normal system operation.
by the way, 99.95% uptime is for the entire period of operation. we had
99.996% uptime until the backup operator failed to call me while I was at
the Lisp Conforence, mistakenly thinking that my sleep was more important
than getting the system back on track -- unfortunately, I don't know what
caused this problem. it could have been that Emacs got problems with the
way it stupidly fails to close X connections after the last frame on a
display is closed -- Emacs gets seriously confused when a remote X server
goes down. other than this fairly major incident, the downtime has been
the time it has taken to correct a problem when some process invoked the
Allegro CL debugger due to some simple coding mistakes or some unexpected
problems with the input from one of the many clients we talk to. even
with outright bugs that would have terminated any other application,
recovery has taken a few minutes at worst. thus, we have extremely fine-
grained control over the failure modes, and the excellent multiprocessing
debugging environment in Allegro CL makes it possible to survive almost
all kinds of problems.
the source of several small downtime incidents has actually been isolated
to a problem in Linux: select(2) spuriously returns, lying that a socket
in listen(2) mode would not block on an accept(2) call. (it lies in
other situations, too, but they are much less of a "permanent block".)
figuring out which socket to connect to to unblock it falls in the "life
is too long to know this stuff well" category. the solution was a second
call to select(2) with that socket, only, and ignoring failed ACCEPT-
-CONNECTION calls. what's really interesting here is that I get _way_
more control over low-level issues like this in Allegro CL than I would
have done in C, as I would have to _build_ an abstraction/protection
layer on top of the "standard" socket interface in C to get the ability
to make small changes to it -- and Allegro CL already has that, so it was
merely a matter of tweaking the existing "abstractive layer".
-- snip --
> As I said in my first posting to this NG....lisp on the other end of
> things that is small, fast, low-level has a place in the world.
> Controlls machines, electornics, and communications. If you have ever
> made little machines go with Forth we will love doing it with
I've never heard of lisp being described as small or fast before:)
Maybe it can _seem_ fast on modern (fast) CPUs though. However, to
compare its "smallness" and "fastness" with Forth is like comparing...
OK so I can't think of a good analogy... I'm sure both Forth and lisp
can do the same things... but so can a Turing machine.
However, I remember something about "the right tool for the job."
How small and fast can you make your "small, fast" lisp? My cuurent
Forth environment is a 68HC11 with an 8K (ROMed) Forth and 2K RAM.
Can your "small" lisp fit into such an environment?
> you can maintain your code, remember what a piece of code does
> and how it does it. If you don't have a little machine, well get
> one and muLisp. Beats the hell out of tring to develope personal-
> ities online.
-- snip --
> muLisp a machine and smile
I'm looking forward to trying muLisp on my DOS box and compare its
smallnes and speed to Pygmy Forth:)
With best wishes,
> I've never heard of lisp being described as small or fast before:)
> Maybe it can _seem_ fast on modern (fast) CPUs though. However, to
> compare its "smallness" and "fastness" with Forth is like comparing...
> OK so I can't think of a good analogy... I'm sure both Forth and lisp
> can do the same things... but so can a Turing machine.
Actually I think Lisp and Forth have a lot in common in the mind-set
area. Programming in each is a matter of extending the language; both
languages are designed to make that easy and both even tend to be
implemented that way.
For those who've never read the Forth newsgroups, I think it'd be
interesting to do so for the perspective it gives on another language
that has much the same philosophy as Lisp though the realization of
that philosophy is wildly different.
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
Fred Gilham wrote:
> Ken Deboy <glockr@locked_and_loaded.reno.nv.us> writes:
> > can do the same things... but so can a Turing machine.
> Actually I think Lisp and Forth have a lot in common in the mind-set
> area. Programming in each is a matter of extending the language; both
> languages are designed to make that easy and both even tend to be
> implemented that way.
> Forth is a very powerful language. muLisp's 16 bit program can't compare
> with forth's size, it runs about 50k. As for the right tool for the right
> job....well muLisp has a set of functions that let you program at a very low
> levels (interrupts, registers, segments etc). I have included a very simple
> program that illustrates one of them MEMORY [address,value,flag] (if value is
> not nil, value is writen to address, if flag is not nil it handles word's if
> nil bytes)
I use the parallel port to controll stepper motors (from old disk drives etc).
This program tells you what parallel ports the computer has. _I_ find lisp
programs interface the machine, computer, and programmer well. _I_ find forth
programs not as programmer friendly as lisp but I have seen forth used by
programmers more apt at the language and was very impressed. To me MEMORY is
much more descriptive than "!" and "." (i think those are store and fetch but
maybe i've forgetten).
> ;;;muLisp 16 bit program for DOS to locate parallel ports
> ;;;address stored as follows
> ;;;; -----------------------------------------------
> ;;;;| 408 | 409 | 40a | 40b | 40c | 40d |
> ;;;;| lpt1 | lpt2 | lpt3 |
> ;;;;| low | high | low | high | low | high |
> ;;;;| byte | byte | byte | byte | byte | byte |
> ;;;; -----------------------------------------------
> ;;; 00 00 will retrun if lpt port not present
> (setq *read-base* 16 *print-base* 16)
> (defun parallel-ports-available ()
> (setq lpt1-low (memory 408))
> (setq lpt1-high (memory 409))
> (setq lpt2-low (memory 40a))
> (setq lpt2-high (memory 40b))
> (setq lpt3-low (memory 40c))
> (setq lpt3-high (memory 40d))
> (if (and (= 00 lpt1-low) (= 00 lpt1-high))
> (print "LPT1 IS NOT PRESENT")
> (print "LPT1 IS PRESENT"))
> (if (and (= 00 lpt2-low) (= 00 lpt2-high))
> (print "LPT2 IS NOT PRESENT")
> (print "LPT2 IS PRESENT"))
> (if (and (= 00 lpt3-low) (= 00 lpt3-high))
> (print "LPT3 IS NOT PRESENT")
> (print "LPT3 IS PRESENT")))
> I have sat here and wondered over a longish time why Lisp is dying a slow
> death and yet ST-80 holds, at least, steady. This is, I think, because it
> is like getting a frikking tooth pulled to get an answer out of anyone
> other than Barry or a certain former member of harlequin.
> More than anyone else here, this message is to you, Erik, because you are
> the day to day expression of everything that is wrong with C.L.L.
I have seen Erik answer *plenty* of questions here. If your
diagnosis were "Lisp people are rude" then I'd understand
that last sentence, but refusal to give information doesn't
seem to me to be among Erik's faults.
(Incidentally, a quick DejaNews trawl doesn't reveal *any* Lisp
questions from you since 1995. I'm puzzled.)
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
>More than anyone else here, this message is to you, Erik, because you are
>the day to day expression of everything that is wrong with C.L.L.
Erik is very free with his knowledge and opinions. I don't necessarily
agree with his opinions, but he is a useful member of this group.
Have you ever hung around comp.lang.perl.misc? Last time I was there,
the civility level of certain experts was somewhere in the Erik
category, and none of the experts answered a question I was asking.
By your reasoning, Perl should be as dead as Autocoder by now.
Instead, it seems to be more popular than Common Lisp (no accounting
for taste, I guess). For that matter, what's ST80 or Squeak,
and are they or it or whatever really more used than Lisp?
ST80 -- SmallTalk 80 ( from whom these days? it keeps changing.
There is also the IBM VisuageAge product. )
Squeak -- A highly portable (virtual machine ), "self contained", and
"open source" Smalltak implementation initially created by
Alan Kay et. al. at Apple. Luckily "freed" before the
Apple's R&D was "steved".
There seems to be a healthy market for software developed in SmallTalk.
Relative to Java and C++ I'd say Lisp and Smalltalk were in aproximately the
same status. Smalltalk, being OO, slightly higher in terms in
favorable hype factor.
[ CLOS is "strange" to most initiated in OO. For example UML doesn't
exactly map onto CLOS like the more "popular" OO languages.
Thereby can't float on the hype factor as well. ]
[ a "healthy market" is one in which vibrant enough to be self sustaining.
Not necessarily showing double digit growth, plastered on the
front page of trade journals, and/or filling you local newspaper's
want ads. ]
Lyman S. Taylor "I'm a Doctor! Not a commando."
(ly...@cc.gatech.edu) The enhanced EMH Doctor in a ST:Voyager epidsode.
this doesn't make sense as you explain it. could you be more specific?
(assume that I know all the protocol specs by heart, actually helped
write the Internet Host Requirements RFCs, and sometimes do network
debugging for a living.) I don't see how you are supposed to be able to
"remove" a connection attempt (by which I assume you mean a TCP SYN) and
presumably _before_ the SYN ACK can see a RST from the other end. which
type of ICMP packet do you mean could interfere here?
| if an application cannot accept any blocking it is supposed to set the
| listening socket to non blocking mode first, then the accept'ed sockets
| will be non blocking too and return EAGAIN when the connection
| disappeared. The application has to handle this inherent race by
this scenario seems extremely unlikely to cause blocking calls. yet it
happens. with both TCP logs and ICMP logs on the system in question,
select returns an apparently random fd from either the input or output
set without evidence of activity. in the test case where this has
happened to me, the machine does _nothing_ apart from waiting for
connections on 64 sockets, input on 64 sockets, and output on 64 sockets.
there is _no_ activity that should trigger and make select return, yet it
does, and there is, invariably, nothing there. the network only has the
usual background noises, to which it does not seem to relate in any way.
| In what other situations do you think does select "lie" too?
it has lied to me about write not blocking on sockets. just today, I had
to shut down the whole application and restart it because we couldn't
wait for my finding the bug during production hours. uptime requirements
are extremely tight. we were down for 3 minutes, and during that time,
all of nine people had been yanked out of whatever concentration the have
left and asked to participate in fixing the problem.
the problem is actually two-fold: select is used a number of fds, but
when a false positive is returned, due to system internals, it keeps
retrying on only the one that failed for a while before giving up on it,
and returning to normal operation. sometimes, it doesn't give up. I
have looked over the Allegro CL code and I can find no fault with it.
I have coded around this by asking select if he lied about the return
value, and if it doesn't confirm the return value, I ignore it and retry.
(I have replaced the functions FILESYS-WRITE-BYTES and -STRING, and
FILESYS-READ-BYTES and -BUFFER.) I have found _nothing_ to support any
theory of external influences of any kind, although I'm sure there's
_something_, like a clock ticking or some other apparently-innocuous
element. I wish I understood what's going on, but I have stopped my
research at select, and have coded around select, and that appears to
remove the problem, for whatever reason. if and when I have more time,
I'd like to dig even deeper, but this has already cost us some delays and
I have some catching up and some code cleanup to do.
| There are possible scenarios, e.g. when the final ACK is delayed, the
| SYN-ACK is retransmitted, RST is send for the SYN-ACK, SYN-ACK arrives in
| between and select succeeds, RST arrives, application calls accept.
yup, but these abnormal cases were all handled correctly, and we still
got bogus return values from select.
| Do multiple processes/threads write to this socket?
there's only one Linux process/thread, but within the Allegro CL process,
multiple Lisp processes talk to these sockets. however, only one process
does listen, read, or write on any given socket at any given time.
(separate Lisp processes take care of input and output, though.)
| One common bug that may cause it is that Linux select differes from BSD
| select in a critical point: Linux select modifies the passed timeval to
| the time left after select finished, BSD leaves it alone. A lot of
| applications forget to reinitialize the timeout before every select call
| in their main loop. You can check for this situation simply with strace.
| Of course there should be no bit set then in the output fd_sets in this
yes, this possibility has been investigated (with strace as you suggest)
and found not to apply. timeouts cause the sets to be cleared on return,
as expected. the error does _not_ occur while tracing -- the system has
to be quiet in some weird way for this to happen. that's why it took so
long to figure it out, and while I'm not sure select is the real culprit
and I may only have cured a symptom.
while I would appreciate any help in this matter, I also feel somewhat
exhausted by it and I'm unhappy to go over the details yet again. it
also doesn't appear to be comp.lang.lisp material. when I feel up to it,
and I'm able to reproduce it consistently, whatever that means in a case
like this, I'll try and work with both Franz Inc and Linux developers to
see how these things interact so unreliably.
I regret that I'm not at liberty to share the code modified code with
other than Allegro CL licensees, and I'm letting Franz Inc engineers take
care of any other customers who might report similar problems. at least
we know that this can happen and we know a way that appears to circumvent
the problem that doesn't break when the real cause is found.
I've said this before, but one of the more bizarre things about this
whole experience is that I have _more_ low-level control over things in
Allegro CL than I would have in C. in C I can trace the system calls,
but in Allegro CL I can trace nigh everything, and peeking under the hood
has never been easier. this did come as somewhat of a revelation to me.