Subject: Re: VB? Bah! Was...Re: Read macro blues: #+ From: Erik Naggum <erik@naggum.no> Date: 1999/01/29 Newsgroups: comp.lang.lisp Message-ID: <3126637651277605@naggum.no> * Kenny Tilton <tilt@liii.com> | 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. #:Erik -- SIGTHTBABW: a signal sent from Unix to its programmers at random intervals to make them remember that There Has To Be A Better Way.