Subject: Re: VB? Bah! Was...Re: Read macro blues: #+
From: Erik Naggum <>
Date: 1999/01/29
Newsgroups: comp.lang.lisp
Message-ID: <>

* Kenny Tilton <>
| BTW, I have been meaning to ask over here, seriously i am still
| evaluating ACL and will be stress-testing AllegroStore before fully
| committing my friend's dream project to these tools...anyone here using
| them for mission-critical "enterprise" stuff? Happy? Sad?

  I'm happy to relate that after two months of grueling development work,
  almost 95% of which has gone into surviving the idiotic behavior of
  various Microsoft products and Delphi in relation to sockets and the
  inability of Microsoft-inflicted programmers to implement protocols, plus
  the senile firewalls that randomly forget Network Address Translations,
  and a whole truckload of other network-related problems that we must
  survive and sail through, my client launched a new service today that
  increases the load on my application tenfold (it's been running since
  mid-August), now requires a master with slaves (currently one) to handle
  the real communications load and network hostilities, and has a hard
  real-time requirement of 4 seconds from submission to final destination,
  and this requires the cooperation of no less than 25 computers and
  thousands of miles of telecommunications cable, with all their failing
  routers and all kinds of human errors.  we average out at 2 seconds, and
  guesstimates indicate 1.3 to 1.5 seconds in network latency.

  the master and the slave both run Allegro CL 5.0 on cheap, used 133 PPro
  computers with 64M RAM and Linux.  the application goes out of its way to
  exercise the multiprocessing capabilities and the socket abstraction
  layer (somewhat modified to handle socket conditions more flexibly) in
  Allegro CL.  the existence of the entire new technologies department of
  the publishing company involved now rests with Allegro CL.  (they also
  run my private version of Emacs, since it would be disastrous if Emacs
  were to die -- the differences are, again, in handling socket errors, but
  also in removing unstable features.)

  having worked with Internet protocols at most layers since 1987, I can
  safely say that it would have taken me at least two years to get the same
  robustness out of a C application, now that I know just how much work was
  needed.  (I did not _expect_ to have to do traceroutes on live sockets,
  or survive and read data _past_ a connection reset error, and other such
  unreasonable low-level stuff, but now that I do, I'm really happy that I
  could do it in Common Lisp, and Allegro CL in particular.)

  but as for AllegroStore, the data my application works with is not
  persistent in my part of the big picture.  my application only handles
  the time-critical parts.

  not _all_ has been bliss, however.  I have rewritten the semi-lowlevel
  file system read/write routines so they wouldn't signal errors on their
  own, but call a generic function that may be specialized on the stream
  and the error symbol so they can ignore or return EOF on whole classes of
  errors, or signal an error if no other handlers exist.  in effect, I
  wanted to add programatically what I would do with the debugger to return
  a value or restart the operation, but even the debugger couldn't just
  ignore an error and continue.  I have disabled the incredibly annoying
  Unix signal SIGPIPE, which took a lot of work to get right, since Allegro
  CL uses it internally to shut down properly when the parent Emacs dies,
  and it had obviously been a lot work to live _with_ it, too.  I have
  rewritten the character handling functions so they are table-driven and
  can now handle any 7- or 8-bit character set you want.  since I use
  logical pathnames a lot, a few disagreements over the specification has
  required a number of _really_ low-level fixes.  Franz Inc has been ever
  helpful in fulfilling my needs and requirements even when disagreeing
  that something is a problem, however, and I can safely say that this
  project would not have been possible without their excellent support.  of
  course, one might argue that needing support is a sign of weakness on
  _both_ ends, but I have come to think that a division of labor as great
  as Common Lisp necessarily requires some sharing of insight both ways in
  order to make that division work profitably for both parties, and Franz
  Inc strongly agrees with that sentiment, at least as far as I'm concerned.

  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.