From: Peter G. <pe...@ar...> - 2007-03-27 21:11:19
|
Using 1.0.4.3 as build host: * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 331.48user 12.65system 5:44.96elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2208413minor)pagefaults 0swaps //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.4.6, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. internal error #26 SC: 15, Offset: 0 $1= 0x1000001bff: other pointer fatal error encountered in SBCL pid 13993(tid 46912503430768): internal error too early in init, can't recover LDB monitor ldb> -Peter |
From: fred v. <fr...@fr...> - 2007-03-27 21:45:39
|
just got the same output, same lisp, same sources, same arch. FV Peter Graves a écrit : > Using 1.0.4.3 as build host: > > * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good > 331.48user 12.65system 5:44.96elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+2208413minor)pagefaults 0swaps > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.4.6, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > internal error #26 > SC: 15, Offset: 0 $1= 0x1000001bff: other pointer > fatal error encountered in SBCL pid 13993(tid 46912503430768): > internal error too early in init, can't recover > > LDB monitor > ldb> > > -Peter > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Christophe R. <cs...@ca...> - 2007-03-27 21:46:03
|
Peter Graves <pe...@ar...> writes: > internal error #26 > SC: 15, Offset: 0 $1= 0x1000001bff: other pointer > fatal error encountered in SBCL pid 13993(tid 46912503430768): > internal error too early in init, can't recover > > LDB monitor > ldb> >From a little bit of remote debugging, I think this is a failed AVER, because the MT random number generator works in 32-bit chunks even on a 64-bit platform, so %inclusive-random-fixnum doesn't work (as most-positive-fixnum is larger than most-positive-random-chunk). Dunno how best to fix this -- pull two random chunks in on 64-bit platforms instead of one? Or is it easy to adjust the MT to 64-bit operation? Best, Christophe |
From: Sidney M. <si...@si...> - 2007-03-27 22:30:03
|
Christophe Rhodes wrote, On 28/3/07 9:45 AM: > Or is it easy to adjust the MT to 64-bit > operation? The MT seems pretty firmly 32 bit, but Googling found, in addition to a simple 64 bit variant at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html this supposedly faster and better MT that also supports 64 bits: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html -- Sidney Markowitz http://www.sidney.com |
From: <wil...@ai...> - 2007-03-28 12:09:19
|
Argh, argh, argh. On Wed, Mar 28, 2007 at 10:29:19AM +1200, Sidney Markowitz wrote: > Christophe Rhodes wrote, On 28/3/07 9:45 AM: > > Or is it easy to adjust the MT to 64-bit > > operation? The quick fix is just to rewrite RANDOM-CHUNK so that on 64-bit machines it returns two 32-bit chunks from the RNG pasted together. I should be able to commit that in a few hours. It'll be unnecessarily inefficient, doing two 32-bit MT samples even to calculate (RANDOM 4), but it'll be simple and easy for someone with performance issues to rewrite in terms of... > The MT seems pretty firmly 32 bit, but Googling found, in addition to a > simple 64 bit variant at > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html > > this supposedly faster and better MT that also supports 64 bits: > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html Yes, that looks (and looked) good to me. I'm not sure how I managed to misunderstand what was going to happen on 64-bit machines under the current arrangement. I looked at the code and thought about it, and even at one point remember writing a comment saying that the 64-bit extension looked like the way to go there. Also, another performance tweak that I considered even before this fiasco would be to maintain RANDOM-STATE.LEFTOVER-RANDOM-BITS and RANDOM-STATE.N-LEFTOVER-RANDOM-BITS fields, and use them for narrow RANDOM-of-INTEGER calls, so that the usual path through (RANDOM 4) could do a calculation like (PROG1 (AND 3 (RANDOM-STATE.LEFTOVER-RANDOM-BITS STATE)) (SETF (RANDOM-STATE.LEFTOVER-RANDOM-BITS STATE) (ASH (RANDOM-STATE.LEFTOVER-RANDOM-BITS STATE) -2)) (DECF (RANDOM-STATE.N-LEFTOVER-RANDOM-BITS STATE) 2)). I don't know whether it is worth doing, but however worthy of doing it was before, it will be about twice as worthy on 64-bit machines after this fix and before coding the 64-bit twister. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: <wil...@ai...> - 2007-03-28 14:39:55
|
On Wed, Mar 28, 2007 at 07:09:16AM -0500, William Harold Newman wrote: > Argh, argh, argh. [snip] > I'm not sure how I managed to misunderstand what was going to happen > on 64-bit machines under the current arrangement. I looked at the code > and thought about it, and even at one point remember writing a comment > saying that the 64-bit extension looked like the way to go there. The code in 1.0.4.7 is intended to fix the problem, though I don't know how to test it on x86-64 myself. It at least passes tests and builds itself on my x86/linux machine, so at hopefully despite being composed in haste it didn't introduce gross bugs for 32-bit machines. I'd be interested in hearing from anyone who can test 1.0.4.7 on x86-64 whether it works this time. I'd also be interested in a pointer to information about ways I could test such things myself. I seem to remember discussion of SourceForge machines available for testing such things. However, I don't remember any recent discussion, and I can't think of any good keywords for pulling the information out of the mailing list archives. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Sidney M. <si...@si...> - 2007-03-28 14:53:08
|
William Harold Newman wrote, On 29/3/07 2:39 AM: > I seem to remember discussion of SourceForge > machines available for testing such things. Not good news: https://sourceforge.net/forum/forum.php?forum_id=665363 "As of 2007-02-08, SourceForge.net Compile Farm service has been officially discontinued. We feel that our resources are best used at this time in improving other parts of our existing SourceForge.net service offering, and in introducing other high-demand features. There are no immediate plans to offer a replacement for our Compile Farm service." |
From: Christophe R. <cs...@ca...> - 2007-03-28 14:57:35
|
wil...@ai... (William Harold Newman) writes: > I'd also be interested in a pointer to information about ways I could > test such things myself. I seem to remember discussion of SourceForge > machines available for testing such things. I believe that this is no longer an option, as SourceForge has shut down their compile farm because of lack of resources. > However, I don't remember any recent discussion, and I can't think > of any good keywords for pulling the information out of the mailing > list archives. HP still has, I believe, a testdrive program (which allows development on a variety of different arch/OS combinations); that's the only option I know of for testing before commit, short of finding a friend with suitable hardware. On the other hand, I personally don't see that the occasional build breakage on some platforms is a large problem, especially early in the monthly cycle: that's what the nice pool of people who are willing to try CVS is for, to report (and sometimes even fix) problems on architectures inaccessible to an individual. Cheers, Christophe |
From: Peter G. <pe...@ar...> - 2007-03-28 16:03:47
|
On Wed, 28 Mar 2007 at 09:39:55 -0500, William Harold Newman wrote: > I'd be interested in hearing from anyone who can test 1.0.4.7 on > x86-64 whether it works this time. 1.0.4.7 builds OK on Linux x86-64 (using 1.0.4.3 as build host). There is one unexpected test failure: Finished running tests. Status: Failure: arith.pure.lisp / LOGCOUNT Expected failure: callback.impure.lisp / UNDERFLOW-DETECTION Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE FORCE-END-OF-FILE) test failed, expected 104 return code, got 1 -Peter |
From: Harald Hanche-O. <ha...@ma...> - 2007-03-28 16:14:47
|
+ Peter Graves <pe...@ar...>: | On Wed, 28 Mar 2007 at 09:39:55 -0500, William Harold Newman wrote: | > I'd be interested in hearing from anyone who can test 1.0.4.7 on | > x86-64 whether it works this time. | | 1.0.4.7 builds OK on Linux x86-64 (using 1.0.4.3 as build host). | | There is one unexpected test failure: | | Finished running tests. | Status: | Failure: arith.pure.lisp / LOGCOUNT FWIW, I see the same failure on macosx/ppc (sbcl 1.0.4.6), so this may be a portable bug. 8-) (It also grumbles twice about an unhandled error in stream.impure.lisp.) - Harald Hanche-Olsen |
From: <wil...@ai...> - 2007-03-28 16:48:51
|
On Wed, Mar 28, 2007 at 06:14:20PM +0200, Harald Hanche-Olsen wrote: > + Peter Graves <pe...@ar...>: > > | On Wed, 28 Mar 2007 at 09:39:55 -0500, William Harold Newman wrote: > | > I'd be interested in hearing from anyone who can test 1.0.4.7 on > | > x86-64 whether it works this time. > | > | 1.0.4.7 builds OK on Linux x86-64 (using 1.0.4.3 as build host). > | > | There is one unexpected test failure: > | > | Finished running tests. > | Status: > | Failure: arith.pure.lisp / LOGCOUNT > > FWIW, I see the same failure on macosx/ppc (sbcl 1.0.4.6), so this may > be a portable bug. 8-) Thank you both for the quick feedback. The test seems to be ambiguous about whether it's a bug in RANDOM. The new RANDOM code in general provides a different output sequence than the old, so the change to the new RANDOM code could trigger different failures in the LOGCOUNT test even without any bugs in RANDOM. On the other hand, the failure could be caused by another bug in the new RANDOM code, e.g., a TYPE-ERROR signalled from within the RANDOM call. If anyone reasons "where there was one bug, there are probably more," and thus checks whether the new RANDOM code is at fault by determining what kind of exception is signalled where in that test, I will try not to brazen it out if RANDOM is found guilty again. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Cyrus H. <ch...@bo...> - 2007-03-28 17:04:08
|
On a, presumably, related note, there seems to be another problem with thew new random: * (random (1- (expt 2 31))) debugger invoked on a SIMPLE-TYPE-ERROR: Argument X is not a INTEGER: NIL Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:TWO-ARG-IOR NIL 2520021) 0] backtrace 0: (SB-KERNEL:TWO-ARG-IOR NIL 2520021) 1: (RANDOM 2147483647 #S(RANDOM-STATE :STATE #.(MAKE-ARRAY 627 :ELEMENT-TYPE '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '(0 2567483615 4 4357 300933633 1838352333 1039116329 1822211541 2902250641 835884317 743498041 2037202853 ...)))) (I discovered this via a failure in sb-posix-tests/UTIMES.1, which is, coincidentally, where I had triggered a bug that I fixed in 1.0.4.3, but this seems to be unrelated to that.) Cyrus On Mar 28, 2007, at 9:48 AM, William Harold Newman wrote: > On Wed, Mar 28, 2007 at 06:14:20PM +0200, Harald Hanche-Olsen wrote: >> + Peter Graves <pe...@ar...>: >> >> | On Wed, 28 Mar 2007 at 09:39:55 -0500, William Harold Newman wrote: >> | > I'd be interested in hearing from anyone who can test 1.0.4.7 on >> | > x86-64 whether it works this time. >> | >> | 1.0.4.7 builds OK on Linux x86-64 (using 1.0.4.3 as build host). >> | >> | There is one unexpected test failure: >> | >> | Finished running tests. >> | Status: >> | Failure: arith.pure.lisp / LOGCOUNT >> >> FWIW, I see the same failure on macosx/ppc (sbcl 1.0.4.6), so this >> may >> be a portable bug. 8-) > > Thank you both for the quick feedback. > > The test seems to be ambiguous about whether it's a bug in RANDOM. The > new RANDOM code in general provides a different output sequence than > the old, so the change to the new RANDOM code could trigger different > failures in the LOGCOUNT test even without any bugs in RANDOM. On the > other hand, the failure could be caused by another bug in the new > RANDOM code, e.g., a TYPE-ERROR signalled from within the RANDOM call. > > If anyone reasons "where there was one bug, there are probably more," > and thus checks whether the new RANDOM code is at fault by determining > what kind of exception is signalled where in that test, I will try not > to brazen it out if RANDOM is found guilty again. > > -- > William Harold Newman <wil...@ai...> > PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C > Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan > Swift's epitaph > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: <wil...@ai...> - 2007-03-28 17:14:56
|
On Wed, Mar 28, 2007 at 10:04:02AM -0700, Cyrus Harmon wrote: > On a, presumably, related note, there seems to be another problem > with thew new random: > * (random (1- (expt 2 31))) Hmm. Thank you. It seems I am in the population of programmers for whom Joel Spolsky's advice never to rewrite the code from scratch is particularly apt.:-( Or, less pessimistically, I should perhaps at least try harder to take smaller steps. Also it is clear in hindsight that my excuse for not checking in tests isn't an excuse for not testing the code before the commit by, e.g., calling it once on each possible input value. In any case I shall try to fix it. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Harald Hanche-O. <ha...@ma...> - 2007-03-28 17:16:45
|
+ wil...@ai... (William Harold Newman): | On Wed, Mar 28, 2007 at 06:14:20PM +0200, Harald Hanche-Olsen wrote: | > + Peter Graves <pe...@ar...>: | > | Failure: arith.pure.lisp / LOGCOUNT | > | > FWIW, I see the same failure on macosx/ppc (sbcl 1.0.4.6), so this may | > be a portable bug. 8-) | | Thank you both for the quick feedback. | | If anyone reasons "where there was one bug, there are probably more," | and thus checks whether the new RANDOM code is at fault by determining | what kind of exception is signalled where in that test, [...] Here's a quick backtrace: debugger invoked on a SIMPLE-TYPE-ERROR: Argument X is not a INTEGER: NIL Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Continue 1: [SKIP-FILE] RUN-TESTS::SKIP-FILE 2: Ignore and continue with next --eval option. 3: [ABORT ] Skip rest of --eval options. 4: Skip to toplevel READ/EVAL/PRINT loop. 5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). (SB-DEBUG::DEBUG-LOOP-FUN) 0] backtrace 0: (SB-DEBUG::DEBUG-LOOP-FUN) 1: (SB-DEBUG::DEBUG-LOOP-FUN) 2: (INTERNAL-DEBUG) 3: (SB-DEBUG::%INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {1225D1C1}>) 4: ((LAMBDA ())) 5: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA #) {1225D475}>) 6: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA #) {1225D455}>) 7: (INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {1225D1C1}>) 8: (INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {1225D1C1}>) 9: (REALLY-INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {1225D1C1}>) 10: ((LAMBDA (ERROR)) #<SIMPLE-TYPE-ERROR {1225D1C1}>) 11: ((LAMBDA (ERROR)) #<SIMPLE-TYPE-ERROR {1225D1C1}>) 12: (SIGNAL #<SIMPLE-TYPE-ERROR {1225D1C1}>) 13: (ERROR SIMPLE-TYPE-ERROR) 14: (SB-KERNEL:TWO-ARG-IOR NIL 48006393) 15: (RANDOM 1073741824 #S(RANDOM-STATE :STATE #.(MAKE-ARRAY 627 :ELEMENT-TYPE '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '(0 2567483615 132 4357 300933633 1838352333 1039116329 1822211541 2902250641 835884317 743498041 2037202853 ...)))) 16: (NIL) 17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (WITH-TEST (:NAME :LOGCOUNT) (FLET ((TEST (X N) (UNLESS # #))) (DOTIMES (I 128) (LET (#) (TEST X 1) (TEST # I) (TEST # I))) (FLET ((TEST-LOGCOUNT # # #)) (DOTIMES (I 200) (LET # # #))))) #<NULL-LEXENV>) 18: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" {11864609}> NIL NIL) 19: (SB-FASL::INTERNAL-LOAD #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" :ERROR NIL NIL :SOURCE :DEFAULT) 20: (SB-FASL::INTERNAL-LOAD #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" :ERROR NIL NIL NIL :DEFAULT) 21: (LOAD #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp") 22: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LOAD #P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp") #<NULL-LEXENV>) 23: (RUN-TESTS::PURE-RUNNER (#P"/local/src/lisp/sbcl/sbcl-cvs/tests/arith.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/array.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/character.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/clos.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/compiler.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/condition.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/filesys.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/float.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/gcd.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/hash.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/interface.pure.lisp" #P"/local/src/lisp/sbcl/sbcl-cvs/tests/lambda-list.pure.lisp" ...) #<FUNCTION RUN-TESTS::LOAD-TEST>) 24: (RUN-TESTS::RUN-ALL) 25: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN-TESTS::RUN-ALL) #<NULL-LEXENV>) 26: (SB-IMPL::PROCESS-EVAL-OPTIONS ((DISABLE-DEBUGGER) "(with-compilation-unit () (load \"run-tests.lisp\"))" "(run-tests::run-all)")) 27: (SB-IMPL::TOPLEVEL-INIT) 28: ((LABELS SB-IMPL::RESTART-LISP)) 0] 0 // Running pure tests (#<FUNCTION RUN-TESTS::CLOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::LOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::CLOAD-TEST>) // Running impure tests (#<FUNCTION RUN-TESTS::SH-TEST>) - Harald |
From: <wil...@ai...> - 2007-03-28 17:44:23
|
On Wed, Mar 28, 2007 at 07:16:24PM +0200, Harald Hanche-Olsen wrote: > Here's a quick backtrace: > > debugger invoked on a SIMPLE-TYPE-ERROR: Argument X is not a INTEGER: NIL > > 13: (ERROR SIMPLE-TYPE-ERROR) > 14: (SB-KERNEL:TWO-ARG-IOR NIL 48006393) > 15: (RANDOM > 1073741824 > #S(RANDOM-STATE :STATE #.(MAKE-ARRAY 627 :ELEMENT-TYPE '(UNSIGNED-BYTE 32) > :INITIAL-CONTENTS > '(0 2567483615 132 4357 300933633 > 1838352333 1039116329 1822211541 > 2902250641 835884317 743498041 > 2037202853 ...)))) Thank you. My code evidently sucks. I still think it is a reasonable redesign in a general sort of way. I was overoptimistic about how long it was going to take to do it, though, and then obviously lapsed into a ridiculously cavalier attitude about testing it. Furthermore, even if at other times I might be stubborn enough to try to fix it in place (not likely, I think), in any case I will have to be away from computer a lot in the next few days, so now is not the time. When my cvs diff -D '2007-03-27 05:58:12 UTC' finishes I intend to use the appropriate "patch" tricks to revert it, and then think at leisure about resubmitting some cleaned-up variant some other time. Sorry, all, for the confusion. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |