Date: 11 Jan 1988 16:30:45 EST (Mon) From: Dan Hoey To: SF-LOVERS Subject: Liavek In SFL V13 #5, Beth Eades recommends the Liavek series, mentioning that there were only two published so far. Presumably she means *Liavek* and *Players of Luck*, and I'll agree they are excellent. The third volume, *Wizard's Row*, came out a month or two ago. I was disappointed. The fables in the first two volumes (remember ``The Wandering Eye'') were discontinued, and the stories in the third seemed depressing and pointless. Dan --- Newsgroups: comp.lang.lisp From: hoey@etl.ARPA (Dan Hoey) Date: 6 May 88 14:26:34 GMT Subject: Re: Compiling lexical closures d...@eraserhead.UUCP (David A Duff) writes: >In lucid common lisp, compiling the function that generates the >closure will, indeed, cause the function to generate a compiled >closure. Also, if you try to just compile a closure by itself >e.g. (compile nil (return-a-closure)), you get the following message: >...References to this environment will not be compiled correctly.... >Offhand, I can't see any reason why a compile shouldn't be able to >do this correctly, since the closure obviously must have a pointer >to the the environment that was in effect at the time that it was >created. I assume that it was just a special case that the >implementors chose to ignore. I think the key here is that the format of the environment for an interpreted closure doesn't have to be the same as the format of the environment for a compiled closure. This works because in its usual operation, the compiler compiles the environment for each bit of code it compiles. So the job of an implementor to deal with the special case would be to either 1) Convert the interpreter environment to a compiler environment on entry, and restore any changes on exit, or 2) Emit compiled code that can manage references to an interpreter environment. Either choice would be a lot of work to implement a feature not required by the Common Lisp specification. The runtime overhead for choice 1 might well exceed the gains made by compiling. Choice 2 might require sweeping changes throughout the code generator. With the costs in mind, it is a lot easier to understand why ignoring this case is a good idea. Dan --- Newsgroups: comp.bugs.4bsd From: hoey@ai.etl.army.mil (Dan Hoey) Date: 13 May 88 15:46:34 GMT Subject: calendar(1) says egrep: regular expression too long. Index: usr.bin/calendar/calendar.c 4.3BSD +FIX Description: On some Fridays calendar(1) says ``egrep: regular expression too long.'' This is because /usr/lib/calendar makes a regular expression that is too long. It only happens on Fridays because the pattern has to match four days on Fridays. I have only observed this problem near the end of the month, and it isn't happening today (13 May). I don't know why it only happens on some Fridays. It definitely happens when the date is Friday 29 April. I sent in a fix for this for 4.2 but the bug was still there in 4.3. I sent in a fix for 4.3, but I haven't seen it here, so this is my latest attempt to find out what price I have to pay to get out of going through all these things twice. Repeat-By: On Friday 29 April type "calendar". Fix: The pattern can be made smaller by grouping some common parts with parentheses. This fix also allows dates of the form "*/5" to match the fifth of any month just like "* 5" does. Note that it is unwise to mention "*/5" inside a C comment. Of course, this can be fixed by fixing egrep's idea of what a regular expression's maximum size is, but I don't see why we shouldn't fix calendar, too. Someone else can show how to fix egrep. Context diff: *** /tmp/,RCSt1028981 Fri Apr 29 09:34:42 1988 --- calendar.c Fri Apr 29 09:34:24 1988 *************** *** 1,4 ! static char *sccsid = "@(#)calendar.c 4.5 (Berkeley) 84/05/07"; /* /usr/lib/calendar produces an egrep -f file that will select today's and tomorrow's calendar entries, with special weekend provisions --- 1,4 ----- ! static char *sccsid = "@(#)calendar.c 4.>5 (Hoey) 88/04/29"; /* /usr/lib/calendar produces an egrep -f file that will select today's and tomorrow's calendar entries, with special weekend provisions *************** *** 4,9 calendar entries, with special weekend provisions used by calendar command */ #include --- 4,12 ----- calendar entries, with special weekend provisions used by calendar command + + Modified to minimize pattern size so egrep won't barf. Also allow + wild-card dates in slash format. */ #include *************** *** 25,30 }; struct tm *localtime(); tprint(t) long t; { --- 28,36 ----- }; struct tm *localtime(); + int disjunct = 0; /* True if we are working on second or later disjunct of + the pattern. */ + tprint(t) long t; { *************** *** 30,36 { struct tm *tm; tm = localtime(&t); ! printf("(^|[ (,;])((%s[^ \t]*[ \t]*|(0%d|%d)/)0*%d)([^0123456789]|$)\n", month[tm->tm_mon], tm->tm_mon + 1, tm->tm_mon + 1, tm->tm_mday); printf("(^|[ (,;])((\\*[ \t]*)0*%d)([^0123456789]|$)\n", --- 36,51 ----- { struct tm *tm; tm = localtime(&t); ! if (!disjunct) { ! /* Pattern for start of date and open parenthesis */ ! printf("(^|[ \t(,;])("); ! disjunct = 1; ! } else { ! /* Next date */ ! printf ("\n"); ! } ! /* [Jj]an 5 or \* 5 or 1/5 */ ! printf("((%s[^ \t]*|\\*)[ \t]*|(0*%d|\\*)/)0*%d", month[tm->tm_mon], tm->tm_mon + 1, tm->tm_mday); } *************** *** 32,40 tm = localtime(&t); printf("(^|[ (,;])((%s[^ \t]*[ \t]*|(0%d|%d)/)0*%d)([^0123456789]|$)\n", month[tm->tm_mon], ! tm->tm_mon + 1, tm->tm_mon + 1, tm->tm_mday); ! printf("(^|[ (,;])((\\*[ \t]*)0*%d)([^0123456789]|$)\n", ! tm->tm_mday); } main() --- 47,53 ----- /* [Jj]an 5 or \* 5 or 1/5 */ printf("((%s[^ \t]*|\\*)[ \t]*|(0*%d|\\*)/)0*%d", month[tm->tm_mon], ! tm->tm_mon + 1, tm->tm_mday); } main() *************** *** 53,56 t += DAY; tprint(t); } } --- 66,71 ----- t += DAY; tprint(t); } + /* End of date. Make sure date ends cleanly. */ + printf(")([^0-9]|$)\n"); } --- Newsgroups: comp.lang.lisp From: hoey@ai.etl.army.mil (Dan Hoey) Date: 10 Jun 88 20:19:03 GMT Subject: Re: Kyoto Common LISP bug (SORT function) y...@cgl.ucsf.edu (dave yee) writes: >I think i've found a bug in KCL (Kyoto Common LISP). It's not a bug. >Suppose i have a structure... The presence of a structure is irrelevant. >(setq sorted-boxes (sort unsorted-boxes #'< :key'box-item-code)) >well, the function returns the correct value, BUT the original >list is not sorted, furthermore *elements of the list are missing*!!! The definition of sort doesn't claim to sort the original list. It might leave it sorted, but you can't count on it. >Now, i'm still a beginner, but if this is a feature of KCL i would >appreciate an explanation as to why. During the course of any reasonably efficient sorting algorithm, we might expect the sorted list to be formed, while the original list would not be the sorted list. Typically it would be a tail of the sorted list. Since it would take extra work to make the original list be the sorted list, KCL does not waste time doing so. >Oh, and i should add that i've tested this using SUN Common LISP and >the problem does *not* exist. Well, you haven't tested it with all possible lists. Many sorting algorithms only exhibit the behavior on large lists. >Any suggestions? (when (setq sorted-boxes (sort (copy-list unsorted-boxes) #'< :key 'box-item-code)) (setf (car unsorted-boxes) (car sorted-boxes) (cdr unsorted-boxes) (cdr sorted-boxes))) Dan --- Date: 14 Jun 88 20:59:56 GMT From: hoey@ai.etl.army.mil (Dan Hoey) To: SF-LOVERS Subject: Re: Jurgen (was Job -- love or hate) cjk@celerity.UUCP (chris kevlahan ) writes: >When I read Job, I couldn't help being constantly reminded of [James >Branch Cabell]. Job lifted several elements from Cabell's Jurgen. I have heard it claimed that Job was a fairly direct adaptation of Jurgen, but I don't see a full parallel. >J.B.C.'s books also contain the earliest reference that I can find to the >ultra-supreme-being "Kochei the deathless".... That's ``Koschei'', and He is an invention of Cabell's. It is easy to believe otherwise unless you realize that all the citations in Cabell's novels are to fictitious works invented by Cabell. Dan --- Date: 12 Jul 88 20:53:15 GMT From: hoey@ai.etl.army.mil (Dan Hoey) To: SF-LOVERS Subject: Re: The Man-Kzin Wars abostick@gethen.UUCP (Alan Bostick) writes: On the Smoke Ring books: >I, too, found them boring. This was compounded by the initial howler in >the orientation of the integral trees: He had them oriented by tidal >stress so that their long axis pointed towards the primary, but also made >great pains to point out that there was a wind shear due to the differing >orbital velocities of the air masses at either end. This wind shear ought >to apply a substantial torque to the trees, causing their equilibrium >position to be significantly away from the "vertical". Well, that depends on their density, and the distribution of mass. Certainly if they were dense enough, the tilt would be negligible. Also, they are counterbalanced to some extent by the weight of the tails. It would take more work than I am willing to expend to figure out how dense and how counterbalanced we are talking about. But unless *you* expend that work, I you are mistaken in claiming it impossible. To call it a ``howler'' is to claim the work in proving this stuff is trivial. >Not only that, but with all that wind shear... Helmholtz instability... >(it seems to me, not having tried any calculations or simulations) ... >questions about the fluid flow in the Smoke Ring that could only be >answered by careful thought, calculation, and probably simulation. E.g., >... large-scale circulation of atmosphere ... thermally direct, or ... >Rossby waves .... In short, not only was it boring, but I couldn't >believe in it either. You make it clear that you don't know whether it's possible or not. Why is it then unbelievable? If it bores you, fine, but I find it hard to believe in your technical quibbles when you haven't done the work you claim is necessary to determine whether they are valid. Dan --- Newsgroups: sci.electronics Followup-To: sci.math From: hoey@ai.etl.army.mil (Dan Hoey) Date: 20 Jul 88 17:43:51 GMT Subject: Re: Triangular manhole covers (was WHat are those holes for?) ua...@uhnix2.uh.edu (Michael B. Vederman) writes: >Actually, If you don't know, it's because any other shape would either >be too much of a waste of area (such as a triangle) or the lid would be >able to fall through the hole and down into the bowels of the city! l...@killer.DALLAS.TX.US (Lance Franklin) writes: >...a equilateral triangle for a manhole cover wouldn't >fall into the hole either. ri...@ai.etl.army.mil (Richard Rosenthal) writes: >Triangular (3 sided) covers cannot fall through the hole. But in fact you *can* slide an equilateral triangle through a hole of the same shape and slightly smaller size. You turn it sixty degrees and slide it through at the base of the hole. It works because the altitude of the triangle is less than the side. You can fudge it by making the cover thick enough, or making the ledge wider. You can fudge it with a square cover too--just make the cover in the shape of a cube. Dan --- Date: 20 Jul 88 18:14:20 GMT From: hoey@ai.etl.army.mil (Dan Hoey) To: Physics@unix.SRI.COM Subject: Boundaries (Was A BRIEF HISTORY OF TIME by S. Hawking) Mark had defined the boundary of a set A as the intersection of the closures of A and its complement. That is *not* an analytic definition, but a purely topological one. It is in a sense more topological than the one from manifold theory that Greg mentions, since it applies in any topological space (not just in manifolds). It does not require that the space it is embedded in is Euclidean. It does, however, require that the set A be embedded in some larger space. For this reason, we distinguish the concept by calling it the ``boundary of a subset'' as opposed to the ``boundary of a manifold'' that Greg defines. To call either the ``topological definition'' is to invite confusion. --- Newsgroups: comp.software-eng From: hoey@ai.etl.army.mil (Dan Hoey) Date: 5 Aug 88 22:04:28 GMT Subject: Re: Looking for a program to merge two files interactively pr...@paul.rutgers.edu (Lorien Y. Pratt) writes: >I have a program which consists of about 100 different files. A couple of >months ago, I began two sets of modifications to this program, each of which >was kept in a different directory. I now would like to merge these >modifications into a single program. You haven't mentioned whether you kept around a crucial piece of information: the common ancestor from which both versions were derived. There are several programs such as RCS's "merge" (based on Unix's "diff3") that can be used to merge the versions semi-automatically. Where the modifications overlap, both pieces are included in the output, and you get to merge them automatically with your favorite editor. Dan --- Newsgroups: comp.lang.lisp From: hoey@ai.etl.army.mil (Dan Hoey) Date: 24 Aug 88 15:01:34 GMT Subject: Re: Amusing Code a...@soi.UUCP (Alex Zatsman) writes about modifying quoted structure, as in >(defun Init-Stack () (setf *Stack* '((:Bottom-Frame)))) >(defun Push-Object (Object) (push Object (car *Stack*))) where calling PUSH-OBJECT can modify the quoted constant in INIT-STACK. The current feeling of a lot of the Common Lisp developers is that such behavior is an error. In particular, if an implementation has the capability of supporting read-only storage, then it may use that storage for quoted structure, and calling PUSH-OBJECT may signal an error. A better way of writing INIT-STACK is (defun Init-Stack () (setf *Stack* (list '(:Bottom-Frame)))) Dan --- Newsgroups: comp.lang.scheme From: hoey@AIC.NRL.NAVY.MIL (Dan Hoey) Date: 12 Oct 88 17:43:58 GMT Subject: Automatic programming My favorite version of the LAMBDA self-reproducer is ((LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA)) '(LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA))) though SCHEMErs will have to forgo the pun. There is also (format t "~A~:*~S)" "(format t \"~A~:*~S)\" ") Dan --- Newsgroups: comp.lang.lisp From: hoey@ai.etl.army.mil (Dan Hoey) Date: 31 Oct 88 17:04:44 GMT Subject: Re: Summing a list bar...@kulla.think.com.UUCP (Barry Margolin) writes: >I don't know why :KEY was left out. In my opinion, the best way to do >this currently is > (flet ((+-weight (x y) > (+ (box-weight x) (box-weight y)))) > (reduce #'+-weight ...)) The problem there is that if you do that with more than two elements, you end up trying to take the box-weight of the sum of two box-weights, and numbers aren't boxes. The ``right'' way is (flet ((+-weight (x y) (+ x (box-weight y)))) (reduce #'+-weight ... :initial-value 0)) Guy has explained the omission of :KEY based on some feature of REDUCE, but I don't remember it being extremely convincing. Dan ---