From: Christophe R. <cs...@ca...> - 2012-10-21 15:30:39
|
Hi, I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) next weekend. In the meantime, could effort be placed on testing, and fixing any important errors that testing reveals, saving all the exciting new development for an effervescent burst of activity in a week or so's time? Thank you, Christophe |
From: Pascal C. <pc...@p-...> - 2012-10-21 15:49:17
|
Hi, I would have liked to report this earlier, and in a more complete way, but I'm currently extremely busy in the middle of a move. So let me just do a superficial report: SBCL 1.1 makes the MOP feature tests suite report two deviations that didn't exist before. One is about the class precedence list for funcallable-standard-object being in the wrong order, and the other for funcallable-standard-object not being an instance of standard-class. Whether this is actually an issue of SBCL or not is not clear yet. In my experience, it is sometimes the case that I just have to change the test code in MOP feature tests to make something work again. Testing for CLOS MOP compatibility is not an exact science, after all. So take this with a grain of salt. I hope to be able to investigate this better sometime in November, but maybe you already want to take a look at this yourself… Best, Pascal On 21 Oct 2012, at 17:30, Christophe Rhodes <cs...@ca...> wrote: > Hi, > > I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) > next weekend. In the meantime, could effort be placed on testing, and > fixing any important errors that testing reveals, saving all the > exciting new development for an effervescent burst of activity in a week > or so's time? > > Thank you, > > Christophe > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel -- Pascal Costanza The views expressed in this email are my own, and not those of my employer. |
From: Anton V. <avo...@ya...> - 2012-10-22 01:48:18
Attachments:
sbcl-crash.txt
|
I have run cl-test-grid tests (which now include recompilation and load of every ASDF system in Quicklisp + 56 test suites) on sbcl-1.1.0-linux-x86 and sbcl-1.1.0.45-f902660-linux-x86 (the recent from git) and compared results. The only difference is crash of sbcl-1.1.0.45-f902660-linux-x86 when recompiling weblocks - SBCL falls into LDB with heap exhausted (the full output copied from terminal is in the attached file). It is reproduced like this: $ rm -r ~/.cache/common-lisp/sbcl-1.1.0.45-f902660-linux-x86/ $ sbcl-git-bin/run.sh --eval "(ql:quickload :weblocks-test)" It happens not 100% of times, but very often (9 times from 10 attempts). On sbcl 1.1.0 this error doesn't happen (0 times from 10 attempts). The system were the tests are run has 512 MB or RAM and 1024 MB of heap. Best regards, - Anton |
From: Anton V. <avo...@ya...> - 2012-10-22 17:35:17
|
22.10.2012, 18:29, "David Lichteblau" <da...@li...>: > Is there anything special done by this run.sh? Previously saved core > file, additional asdf systems loaded, custom dynamic space size, etc.? No, just setting SBCL_HOME: $ cat lisps/sbcl-git-bin/run.sh #!/bin/sh export SBCL_HOME=/home/testgrid/lisps/sbcl-git-bin/lib/sbcl /home/testgrid/lisps/sbcl-git-bin/bin/sbcl "$1" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9" "${10}" "${11}" "${12}" "${13}" "${14}" "${15}" "${16}" "${17}" "${18}" "${19}" "${20}" "${21}" "${22}" "${23}" "${24}" "${25}" "${26}" "${27}" "${28}" "${29}" "${30}" "${31}" "${32}" "${33}" "${34}" "${35}" "${36}" "${37}" "${38}" "${39}" "${40}" "${41}" > (For comparison, an x86-64 build needs roughly 1/3rd more > memory on this test, and hence fails completely reliably during GC (with > either version of SBCL) when unduly restricted to the same amount of > dynamic space.) So it's not a bug, it's just not enough memory? |
From: David L. <da...@li...> - 2012-10-22 18:27:17
|
Quoting Anton Vodonosov (avo...@ya...): > 22.10.2012, 18:29, "David Lichteblau" <da...@li...>: > > Is there anything special done by this run.sh? Previously saved core > > file, additional asdf systems loaded, custom dynamic space size, etc.? > > No, just setting SBCL_HOME: OK. > > (For comparison, an x86-64 build needs roughly 1/3rd more > > memory on this test, and hence fails completely reliably during GC (with > > either version of SBCL) when unduly restricted to the same amount of > > dynamic space.) > > So it's not a bug, it's just not enough memory? Well, running with a larger --dynamic-space-size would likely help, e.g. 600 or 700. But that does not mean that it is not a regression. On x86 it is always possible that the conservative GC is being more conservative than usual, in the sense that it happens to see unfortunately many possible roots. Unless one considers said conservativeness a bug in itself, those effects would be merely by accident. But I'm interested because safepoint builds currently have an actual bug when it comes to timely GC, so obviously there is some concern that this problem could have leaked into normal builds (even though I don't see how that could be). One more thing to double-check: Can you send me the *features* of this binary? Or even make the binary available, to double-check whether the same build fails on my systems in the same way? d. |
From: Anton V. <avo...@ya...> - 2012-10-22 19:39:10
|
22.10.2012, 22:28, "David Lichteblau" <da...@li...>: > One more thing to double-check: Can you send me the *features* of this > binary? Or even make the binary available, to double-check whether the > same build fails on my systems in the same way? > Today I managed to reproduce it only 1 time from 6 attempts. If weblocks-test compilation really needs this memory and operates close to the limit; plus theGC is conservative, then what you say explains the situation, it may just happen incidentally, depending on the system state. If you still want to investigae: *features* (:QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ASDF-UNICODE :ALIEN-CALLBACKS :ANSI-CL :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS :CYCLE-COUNTER :ELF :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :LARGEFILE :LINKAGE-TABLE :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86) The binary: https://www.dropbox.com/s/dkrvtwljap82td9/sbcl-git-bin.tar.bz2 |
From: Elliott S. <ell...@gm...> - 2012-10-22 02:45:03
|
Could we please remove the -mno-cygwin flag added in 7aef55b130d95c384b63422807f1848faa9aba5a<http://repo.or.cz/w/sbcl.git/blobdiff/1dd3616e9eadaba9f1ca86b72d64551fbd75f399..7aef55b130d95c384b63422807f1848faa9aba5a:/src/runtime/Config.x86-win32>, or conditionalize it on building in Cygwin? This flag was removed from MinGW some time ago (about a year). The following fixes the build on my machine, but isn't terribly Cygwin friendly. diff --git a/src/runtime/Config.x86-win32 b/src/runtime/Config.x86-win32 index c81cac2..714d63f 100644 --- a/src/runtime/Config.x86-win32 +++ b/src/runtime/Config.x86-win32 @@ -36,7 +36,7 @@ endif GC_SRC = gencgc.c -CFLAGS = -g -Wall -O3 -fno-omit-frame-pointer -mno-cygwin -march=i686 -DWINVER=0x0501 +CFLAGS = -g -Wall -O3 -fno-omit-frame-pointer -march=i686 -DWINVER=0x0501 ASFLAGS = $(CFLAGS) CPP = cpp Thanks. On Sun, Oct 21, 2012 at 8:30 AM, Christophe Rhodes <cs...@ca...> wrote: > Hi, > > I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) > next weekend. In the meantime, could effort be placed on testing, and > fixing any important errors that testing reveals, saving all the > exciting new development for an effervescent burst of activity in a week > or so's time? > > Thank you, > > Christophe > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: David L. <da...@li...> - 2012-10-22 14:40:59
|
Quoting Elliott Slaughter (ell...@gm...): > Could we please remove the -mno-cygwin flag added in > 7aef55b130d95c384b63422807f1848faa9aba5a<http://repo.or.cz/w/sbcl.git/blobdiff/1dd3616e9eadaba9f1ca86b72d64551fbd75f399..7aef55b130d95c384b63422807f1848faa9aba5a:/src/runtime/Config.x86-win32>, > or conditionalize it on building in Cygwin? This flag was removed from > MinGW some time ago (about a year). Done! Thanks for the report. d. |
From: Elliott S. <ell...@gm...> - 2012-10-22 04:33:13
|
Hi, Since this next release is the debut of official thread support on Windows, I'd like to invite the community to participate in wider testing of the Windows build. I've put together an installer for a build of SBCL from git, which now includes sb-thread by default on Windows. You can download the installer from my personal website, below. Everything I've tried works on my system, so I don't expect any trouble, but if you find problems with this build, please let us know. https://elliottslaughter.com/files/sbcl-1.1.0.45-testing-x86-windows-binary.msi sha1 07eac740d3802d500fff7a92296ec15700f03dd4 On Sun, Oct 21, 2012 at 8:30 AM, Christophe Rhodes <cs...@ca...> wrote: > Hi, > > I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) > next weekend. In the meantime, could effort be placed on testing, and > fixing any important errors that testing reveals, saving all the > exciting new development for an effervescent burst of activity in a week > or so's time? > > Thank you, > > Christophe > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: David L. <da...@li...> - 2012-10-22 14:27:43
|
Hi, Quoting Anton Vodonosov (avo...@ya...): > The only difference is crash of sbcl-1.1.0.45-f902660-linux-x86 > when recompiling weblocks - SBCL falls into LDB with heap exhausted > (the full output copied from terminal is in the attached file). thank you for testing. Just based on looking at resident memory use reported by top, I'd say that WEBLOCKS-TEST compilation is a proceduce which just barely manages to keep below a memory utilization which still leaves enough space for GC to happen. Therefore, any change to SBCL which would cause GC to be more conservative, or to happen later, would have a good chance of breaking this build. (For comparison, an x86-64 build needs roughly 1/3rd more memory on this test, and hence fails completely reliably during GC (with either version of SBCL) when unduly restricted to the same amount of dynamic space.) However, I've just done 10 runs of "clear fasls and load :weblocks-test" on x86, and couldn't reproduce it. > It is reproduced like this: > > $ rm -r ~/.cache/common-lisp/sbcl-1.1.0.45-f902660-linux-x86/ > $ sbcl-git-bin/run.sh --eval "(ql:quickload :weblocks-test)" Is there anything special done by this run.sh? Previously saved core file, additional asdf systems loaded, custom dynamic space size, etc.? Thanks d. |
From: Anton V. <avo...@ya...> - 2012-10-23 00:09:00
|
22.10.2012, 08:34, "Elliott Slaughter" <ell...@gm...>: > Hi, > Since this next release is the debut of official thread support on Windows, I'd like to invite the community to participate in wider testing of the Windows build. I've put together an installer for a build of SBCL from git, which now includes sb-thread by default on Windows. You can download the installer from my personal website, below. > Everything I've tried works on my system, so I don't expect any trouble, but if you find problems with this build, please let us know. > https://elliottslaughter.com/files/sbcl-1.1.0.45-testing-x86-windows-binary.msi > sha1 07eac740d3802d500fff7a92296ec15700f03dd4 I have tested this release with cl-test-grid, and also the older SBCL release form the windows branch - sbcl-1.0.54.84.mswinmt.1137-215bdc8-win-x64. This table show the difference between results: http://common-lisp.net/project/cl-test-grid/sbcl/sbcl-win-1.0.54-vs-head.html The most of the failures shown for the new release sbcl-1.1.0.45-win-x86 are due to absence of 32bit native libraries. But some of the failures are from pure lisp libraries. For example this access violation: https://cl-test-grid.appspot.com/blob?key=647056 Or this cl-interpol failure: https://cl-test-grid.appspot.com/blob?key=647037 The clhs compilation error is strange: https://cl-test-grid.appspot.com/blob?key=648045 On linux clhs compile OK, and the SBCL from Windows branch compiles it successfully. You may want to review all the failures. Hint: ignore the failure of cl-openid test case "cl-openid.nonce-universal-time/random" - it's the problem in test case. I will now install and test the latest binary from windows branch, to compare it results with sbcl-1.1.0.45-win-x86. Best regards, - Anton |
From: David L. <da...@li...> - 2012-10-23 17:09:39
|
Quoting Anton Vodonosov (avo...@ya...): > The most of the failures shown for the new release sbcl-1.1.0.45-win-x86 > are due to absence of 32bit native libraries. But some of the failures > are from pure lisp libraries. [...] > You may want to review all the failures. So, cl-interpol, clhs, and "com.clearly-useful.generic-collection-interface" are the affected libraries? I'd absolutely want to investigate it, but unfortunately I have not yet managed to get any of these errors. Anton, which version of Windows does cl-test-grid run on? Elliott, does asdf/quicklisp fail with these systems for you, too? d. |
From: Anton V. <avo...@ya...> - 2012-10-23 17:56:34
|
23.10.2012, 21:10, "David Lichteblau" <da...@li...>: > So, cl-interpol, clhs, and "com.clearly-useful.generic-collection-interface" > are the affected libraries? > > I'd absolutely want to investigate it, but unfortunately I have not yet > managed to get any of these errors. > > Anton, which version of Windows does cl-test-grid run on? The results are from Windows 7, 64 bit. Quicklisp 2012-10-13. I can reproduce clhs and cl-interpol easily: (ql:quickload :clhs) => The same error as reported (ql:quickload :cl-interpol) (ql:quickload :cl-interpol-test) (cl-interpol-test:run-all-tests) => The same errors as were reported As for com.clearly-useful.generic-collection-interface, I have tried it several times: (ql:quickload :com.clearly-useful.generic-collection-interface) But it loaded OK, without errors. I guess the problem might been caused be some kind of race condition or alike. |
From: Jason A. <j.a...@gm...> - 2012-10-23 19:22:21
|
> > As for com.clearly-useful.generic-collection-interface, > I have tried it several times: > > (ql:quickload :com.clearly-useful.generic-collection-interface) > > But it loaded OK, without errors. I guess the problem might been > caused be some kind of race condition or alike. > I'm not sure why com.clearly-useful.generic-collection-interface would be failing… it doesn't create any threads just by loading. It defines one function using lparallel's defpfun in the file parallel.lisp[1], but won't call it unless bordeaux-threads is fully supported (present in *features*). Is merely using defpfun enough to cause a problem? I've updated the git repo to disable using it at all if full threading support isn't present, but I don't know if that's the exact problem here. parallel.lisp with conditional added: https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/blob/master/parallel.lisp |
From: Elliott S. <ell...@gm...> - 2012-10-25 01:59:10
|
On Tue, Oct 23, 2012 at 6:28 AM, David Lichteblau <da...@li...>wrote: > Quoting Anton Vodonosov (avo...@ya...): > > The most of the failures shown for the new release sbcl-1.1.0.45-win-x86 > > are due to absence of 32bit native libraries. But some of the failures > > are from pure lisp libraries. > [...] > > You may want to review all the failures. > > So, cl-interpol, clhs, and > "com.clearly-useful.generic-collection-interface" > are the affected libraries? > > I'd absolutely want to investigate it, but unfortunately I have not yet > managed to get any of these errors. > > Anton, which version of Windows does cl-test-grid run on? > Elliott, does asdf/quicklisp fail with these systems for you, too? > Yes, I see the same errors as Anton. I'm not sure I have any particular insight into why these are failing, but at least I have a backtrace from clhs: https://elliottslaughter.com/files/sbcl_1.1.0.45_error_clhs.txt I'm on Windows 7 SP 1, 64-bit. Updated Quicklisp client and dists today. If you want me to suggest anything for me to try, let me know. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: David L. <da...@li...> - 2012-10-25 14:11:59
|
Quoting Elliott Slaughter (ell...@gm...): > Yes, I see the same errors as Anton. I'm not sure I have any particular > insight into why these are failing, but at least I have a backtrace from > clhs: Thanks for testing; the clhs problem should be fixed in SBCL git. What's still open are the access violations, e.g. for cl-interpol. > I'm on Windows 7 SP 1, 64-bit. Updated Quicklisp client and dists today. OK. I'm testing Windows 7 32 bit, Windows 7 64 bit and Server 2012 and can't see these problems. > If you want me to suggest anything for me to try, let me know. It would be helpful to see: - Stacktraces from Lisp and/or ldb. - Or if ldb doesn't work, please try: SBCL_DYNDEBUG='backtrace_when_lost all' sbcl.exe --lose-on-corruption ... - Does it also fail with non-threaded builds? d. |
From: Elliott S. <ell...@gm...> - 2012-10-26 16:42:19
|
On Thu, Oct 25, 2012 at 7:08 AM, David Lichteblau <da...@li...>wrote: > Quoting Elliott Slaughter (ell...@gm...): > > If you want me to suggest anything for me to try, let me know. > > It would be helpful to see: > > - Does it also fail with non-threaded builds? I'm having trouble building the non-threaded build. https://elliottslaughter.com/files/build-sbcl-1.1.0.47-windows-nothreads.txt Here is my customize-target-features.lisp: (lambda (x) (set-difference x '(:sb-thread :sb-safepoint :sb-thruption :sb-wtimer))) The only other difference from my threaded build (which succeeded out-of-the-box on 1.1.0.47, by the way) is that I did *not* increase the space size: sh make.sh # no SBCL_DYNAMIC_SPACE_SIZE=900 -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: Christophe R. <cs...@ca...> - 2012-10-28 13:15:20
|
Christophe Rhodes <cs...@ca...> writes: > I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) > next weekend. In the meantime, could effort be placed on testing, and > fixing any important errors that testing reveals, saving all the > exciting new development for an effervescent burst of activity in a week > or so's time? Because of the reports of problems relating to some versions of Windows in some cases, I'm holding up for a little while to see if the issue can be isolated and fixed: absent any resolution, though, I'll be releasing next weekend. Keep on testing / developing / using, Cheers, Christophe |
From: Nikodemus S. <nik...@ra...> - 2012-10-29 06:37:54
|
On 28 October 2012 15:15, Christophe Rhodes <cs...@ca...> wrote: > Because of the reports of problems relating to some versions of Windows > in some cases, I'm holding up for a little while to see if the issue can > be isolated and fixed: absent any resolution, though, I'll be releasing > next weekend. > > Keep on testing / developing / using, Just to clarify: we are still in freeze? Cheers, -- Nikodemus |
From: Christophe R. <cs...@ca...> - 2012-10-29 10:12:22
|
Nikodemus Siivola <nik...@ra...> writes: > On 28 October 2012 15:15, Christophe Rhodes <cs...@ca...> wrote: > >> Because of the reports of problems relating to some versions of Windows >> in some cases, I'm holding up for a little while to see if the issue can >> be isolated and fixed: absent any resolution, though, I'll be releasing >> next weekend. >> >> Keep on testing / developing / using, > > Just to clarify: we are still in freeze? Yes, please. (But of course in the wonderful world of distributed everything, that only affects master). Cheers, Christophe |
From: Anton V. <avo...@ya...> - 2012-11-01 03:40:58
|
I can not reproduce crash when ql:quickloading com.clearly-useful.generic-collection-interface (tried many times, with cleaning .fasls). This means, there is no evidence the crash I observed initially is a regression caused by changes since last release. BTW, another difference I see between SBCL version from windows branch (I've tested the latest binary, sbcl-1.1.0.36.mswinmt.1201-284e340-win-x86), and the windows build from the master branch (sbcl-1.1.0.45-win-x86) is how it works with FFI. (ql:quickload :syslog) - succeeds on the windows branch, and fails on the master version with debugger invoked on a SB-ALIEN:UNDEFINED-ALIEN-ERROR in thread #<THREAD "main thread" RUNNING {23EFED39}>: Undefined alien: "openlog" Is it supposed to be so? |
From: Anton V. <avo...@ya...> - 2012-11-01 08:13:55
|
I mean (ql:quickload :cl-syslog) 01.11.2012, 07:42, "Anton Vodonosov" <avo...@ya...>: > > (ql:quickload :syslog) - succeeds on the windows branch, > and fails on the master version with > > debugger invoked on a SB-ALIEN:UNDEFINED-ALIEN-ERROR in thread > #<THREAD "main thread" RUNNING {23EFED39}>: > Undefined alien: "openlog" > > Is it supposed to be so? |
From: David L. <da...@li...> - 2012-11-01 19:27:16
|
Quoting Anton Vodonosov (avo...@ya...): > I mean (ql:quickload :cl-syslog) > > 01.11.2012, 07:42, "Anton Vodonosov" <avo...@ya...>: > > > > (ql:quickload :syslog) - succeeds on the windows branch, > > and fails on the master version with > > > > debugger invoked on a SB-ALIEN:UNDEFINED-ALIEN-ERROR in thread > > #<THREAD "main thread" RUNNING {23EFED39}>: > > Undefined alien: "openlog" > > > > Is it supposed to be so? In SBCL master up to and including the upcoming release, yes, this behaviour still exists. But the follow-up release will fix it. d. |
From: Elliott S. <ell...@gm...> - 2012-11-03 08:04:11
|
Windows build is up. The default configuration has threads enabled; if you need a non-threaded build, you can find it in the experimental folder. On Sun, Oct 21, 2012 at 8:30 AM, Christophe Rhodes <cs...@ca...> wrote: > Hi, > > I'd like to release sbcl-1.something (1.1.1? 1.2? 1.√2? Who knows?) > next weekend. In the meantime, could effort be placed on testing, and > fixing any important errors that testing reveals, saving all the > exciting new development for an effervescent burst of activity in a week > or so's time? > > Thank you, > > Christophe > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |