You can subscribe to this list here.
2009 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(16) |
Feb
(1) |
Mar
(10) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(1) |
2011 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(5) |
Jul
(1) |
Aug
(8) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
2012 |
Jan
(2) |
Feb
(2) |
Mar
(8) |
Apr
(6) |
May
(13) |
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
(5) |
Feb
(1) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(11) |
Jul
(9) |
Aug
|
Sep
(4) |
Oct
|
Nov
(12) |
Dec
(6) |
2014 |
Jan
(6) |
Feb
(17) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
2015 |
Jan
(2) |
Feb
(1) |
Mar
(6) |
Apr
(2) |
May
|
Jun
(5) |
Jul
(7) |
Aug
(2) |
Sep
(5) |
Oct
(3) |
Nov
(16) |
Dec
(15) |
2016 |
Jan
(11) |
Feb
(11) |
Mar
(5) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
(12) |
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(4) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(6) |
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
(9) |
Aug
|
Sep
(12) |
Oct
(2) |
Nov
|
Dec
(8) |
2020 |
Jan
(12) |
Feb
(3) |
Mar
(4) |
Apr
(4) |
May
(27) |
Jun
(14) |
Jul
(3) |
Aug
(7) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2021 |
Jan
(2) |
Feb
(6) |
Mar
(8) |
Apr
(10) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
(6) |
Dec
(8) |
2022 |
Jan
(7) |
Feb
(4) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
(14) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(5) |
Dec
(6) |
2023 |
Jan
(18) |
Feb
(2) |
Mar
(28) |
Apr
(8) |
May
(3) |
Jun
(24) |
Jul
(11) |
Aug
(22) |
Sep
(20) |
Oct
(27) |
Nov
(12) |
Dec
(2) |
2024 |
Jan
(5) |
Feb
(45) |
Mar
(31) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Robert B. <rob...@gm...> - 2024-03-18 12:38:05
|
> That just shows that Linux is not a serious OS. 'free' as in 'what it is worth'! La propriété, c'est le vol. Actually, I am so happy with Gnu, SBCL, Google, and Debian that I cannot express it well enough to try. But I felt that my little close encounter with 'death' was worth reporting. I do not usually use the clock on my cell phone to help report bugs! Thank you, Bob On Mon, Mar 18, 2024 at 7:28 AM Stas Boukarev <sta...@gm...> wrote: > > That just shows that Linux is not a serious OS. > > On Mon, Mar 18, 2024 at 12:01 PM Robert Boyer < rob...@gm...> wrote: >> >> Dear heroes, you wonderful SBCL bug guys, >> >> Is this a bug, or just the way it is supposed to be? For example, how about a good old fashioned error message of some sort? >> >> The following kills my Chromebook. In a previous very related message I sent a lot >> of info, namely /proc/cpuinfo. Let me know if you want any more info. >> >> ;;; sbcl --dynamic-space-size 32000 --no-userinit >> ;;; This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp. >> >> (defun sum (n) >> (declare (fixnum n)) >> (let ((ar (make-array n :element-type '(integer 0 1))) >> (cnt 0) >> (i 0)) >> (declare (type (array (integer 0 1) (*))) >> (fixnum cnt i)) >> (loop >> (cond ((eql i n) (return nil))) >> (setf (aref ar i) 1) >> (incf i)) >> (setf i 0) >> (loop >> (cond ((eql i n) (return cnt))) >> (incf cnt (aref ar i)) >> (incf i)))) >> >> (sum (expt 10 11)) >> >> ;;; My Chromebook dies. My best evidence is that the clock on the side panel >> ;;; gets way behind. Sometimes, the machine will reboot by itself, but not >> ;;; well. >> >> ;;; ⏻ with ⟳ held down it is! >> >> Bob >> _______________________________________________ >> Sbcl-bugs mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs |
From: Stas B. <sta...@gm...> - 2024-03-18 12:28:30
|
That just shows that Linux is not a serious OS. On Mon, Mar 18, 2024 at 12:01 PM Robert Boyer <rob...@gm...> wrote: > Dear heroes, you wonderful SBCL bug guys, > > Is this a bug, or just the way it is supposed to be? For example, how > about a good old fashioned error message of some sort? > > The following kills my Chromebook. In a previous very related message I > sent a lot > of info, namely /proc/cpuinfo. Let me know if you want any more info. > > ;;; sbcl --dynamic-space-size 32000 --no-userinit > ;;; This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp. > > (defun sum (n) > (declare (fixnum n)) > (let ((ar (make-array n :element-type '(integer 0 1))) > (cnt 0) > (i 0)) > (declare (type (array (integer 0 1) (*))) > (fixnum cnt i)) > (loop > (cond ((eql i n) (return nil))) > (setf (aref ar i) 1) > (incf i)) > (setf i 0) > (loop > (cond ((eql i n) (return cnt))) > (incf cnt (aref ar i)) > (incf i)))) > > (sum (expt 10 11)) > > ;;; My Chromebook dies. My best evidence is that the clock on the side > panel > ;;; gets way behind. Sometimes, the machine will reboot by itself, but not > ;;; well. > > ;;; ⏻ with ⟳ held down it is! > > Bob > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Robert B. <rob...@gm...> - 2024-03-18 09:00:50
|
Dear heroes, you wonderful SBCL bug guys, Is this a bug, or just the way it is supposed to be? For example, how about a good old fashioned error message of some sort? The following kills my Chromebook. In a previous very related message I sent a lot of info, namely /proc/cpuinfo. Let me know if you want any more info. ;;; sbcl --dynamic-space-size 32000 --no-userinit ;;; This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp. (defun sum (n) (declare (fixnum n)) (let ((ar (make-array n :element-type '(integer 0 1))) (cnt 0) (i 0)) (declare (type (array (integer 0 1) (*))) (fixnum cnt i)) (loop (cond ((eql i n) (return nil))) (setf (aref ar i) 1) (incf i)) (setf i 0) (loop (cond ((eql i n) (return cnt))) (incf cnt (aref ar i)) (incf i)))) (sum (expt 10 11)) ;;; My Chromebook dies. My best evidence is that the clock on the side panel ;;; gets way behind. Sometimes, the machine will reboot by itself, but not ;;; well. ;;; ⏻ with ⟳ held down it is! Bob |
From: Robert B. <rob...@gm...> - 2024-03-17 14:58:23
|
>> Try read-sequence instead I shall. Thank you. Bob On Sun, Mar 17, 2024 at 9:50 AM Stas Boukarev <sta...@gm...> wrote: > Try read-sequence instead. > > On Sun, Mar 17, 2024 at 5:32 PM Robert Boyer <rob...@gm...> > wrote: > >> Thanks again for SBCL, the best Lisp I have ever used. >> >> read-byte and write-byte seem a lot slower than /usr/bin/cp by a factor >> of 4. >> >> The file cp.lisp is attached. >> >> > sbcl --no-userinit >> This is SBCL 2.2.9.debian, 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. >> * (load "cp.lisp") >> -rw-r----- 1 bob chronos-access 1250000000 Mar 16 17:10 >> primes-below-10000000000.bin >> T >> * (compare) >> Evaluation took: >> 142.388 seconds of real time >> 67.973978 seconds of total run time (63.841888 user, 4.132090 system) >> 47.74% CPU >> 158,563,705,669 processor cycles >> 0 bytes consed >> >> Evaluation took: >> 32.013 seconds of real time >> 0.002824 seconds of total run time (0.001445 user, 0.001379 system) >> 0.01% CPU >> 15 forms interpreted >> 35,648,311,244 processor cycles >> 0 bytes consed >> >> #<SB-IMPL::PROCESS :EXITED 0> >> * (/ 142.388 32.013) >> 4.447818 >> * >> _______________________________________________ >> Sbcl-bugs mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs >> > |
From: Robert B. <rob...@gm...> - 2024-03-17 14:55:28
|
So sorry for yet another shitpost! The brilliance of you guys is beyond belief to me. > Notice in particular that the man page says the data never leave kernel memory Way beyond me! I'll be sure to read "How to Ask Questions" before posting again. Thanks so much, Bob On Sun, Mar 17, 2024 at 9:42 AM Douglas Katzman <do...@go...> wrote: > cp does not copy 1 byte at a time. The fact that it's only off by a > factor of 4.5 is god-damned impressive. > On Linux, cp makes at most *TWO* system calls for entire copy operation. > One copy_file_range > <https://man7.org/linux/man-pages/man2/copy_file_range.2.html> for some > chunk granularity that I don't know, and one for the remainder. > Notice in particular that the man page says the data never leave kernel > memory > > But I have to agree with MrDispatch as to your intent here- > Unless you come back and say that you've read How to Ask Questions > <http://www.catb.org/~esr/faqs/smart-questions.html> front to back and > tried your darndest to ask smart questions, I'm inclined to filter out the > shitposts > |
From: Stas B. <sta...@gm...> - 2024-03-17 14:50:29
|
Try read-sequence instead. On Sun, Mar 17, 2024 at 5:32 PM Robert Boyer <rob...@gm...> wrote: > Thanks again for SBCL, the best Lisp I have ever used. > > read-byte and write-byte seem a lot slower than /usr/bin/cp by a factor of > 4. > > The file cp.lisp is attached. > > > sbcl --no-userinit > This is SBCL 2.2.9.debian, 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. > * (load "cp.lisp") > -rw-r----- 1 bob chronos-access 1250000000 Mar 16 17:10 > primes-below-10000000000.bin > T > * (compare) > Evaluation took: > 142.388 seconds of real time > 67.973978 seconds of total run time (63.841888 user, 4.132090 system) > 47.74% CPU > 158,563,705,669 processor cycles > 0 bytes consed > > Evaluation took: > 32.013 seconds of real time > 0.002824 seconds of total run time (0.001445 user, 0.001379 system) > 0.01% CPU > 15 forms interpreted > 35,648,311,244 processor cycles > 0 bytes consed > > #<SB-IMPL::PROCESS :EXITED 0> > * (/ 142.388 32.013) > 4.447818 > * > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Douglas K. <do...@go...> - 2024-03-17 14:42:53
|
cp does not copy 1 byte at a time. The fact that it's only off by a factor of 4.5 is god-damned impressive. On Linux, cp makes at most *TWO* system calls for entire copy operation. One copy_file_range <https://man7.org/linux/man-pages/man2/copy_file_range.2.html> for some chunk granularity that I don't know, and one for the remainder. Notice in particular that the man page says the data never leave kernel memory But I have to agree with MrDispatch as to your intent here- Unless you come back and say that you've read How to Ask Questions <http://www.catb.org/~esr/faqs/smart-questions.html> front to back and tried your darndest to ask smart questions, I'm inclined to filter out the shitposts |
From: MrDispatch <MrD...@pr...> - 2024-03-17 14:37:29
|
You know, the usual troll tactics were to ask "why no browser in <your language>", but yeah, there's Nyxt. -------- Original Message -------- On Mar 17, 2024, 15:30, Robert Boyer wrote: > Thanks again for SBCL, the best Lisp I have ever used. > > read-byte and write-byte seem a lot slower than /usr/bin/cp by a factor of 4. > > The file cp.lisp is attached. > >> sbcl --no-userinit > This is SBCL 2.2.9.debian, 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. > * (load "cp.lisp") > -rw-r----- 1 bob chronos-access 1250000000 Mar 16 17:10 primes-below-10000000000.bin > T > * (compare) > Evaluation took: > 142.388 seconds of real time > 67.973978 seconds of total run time (63.841888 user, 4.132090 system) > 47.74% CPU > 158,563,705,669 processor cycles > 0 bytes consed > > Evaluation took: > 32.013 seconds of real time > 0.002824 seconds of total run time (0.001445 user, 0.001379 system) > 0.01% CPU > 15 forms interpreted > 35,648,311,244 processor cycles > 0 bytes consed > > #<SB-IMPL::PROCESS :EXITED 0> > * (/ 142.388 32.013) > 4.447818 > * |
From: Robert B. <rob...@gm...> - 2024-03-17 14:31:36
|
Thanks again for SBCL, the best Lisp I have ever used. read-byte and write-byte seem a lot slower than /usr/bin/cp by a factor of 4. The file cp.lisp is attached. > sbcl --no-userinit This is SBCL 2.2.9.debian, 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. * (load "cp.lisp") -rw-r----- 1 bob chronos-access 1250000000 Mar 16 17:10 primes-below-10000000000.bin T * (compare) Evaluation took: 142.388 seconds of real time 67.973978 seconds of total run time (63.841888 user, 4.132090 system) 47.74% CPU 158,563,705,669 processor cycles 0 bytes consed Evaluation took: 32.013 seconds of real time 0.002824 seconds of total run time (0.001445 user, 0.001379 system) 0.01% CPU 15 forms interpreted 35,648,311,244 processor cycles 0 bytes consed #<SB-IMPL::PROCESS :EXITED 0> * (/ 142.388 32.013) 4.447818 * |
From: Robert B. <rob...@gm...> - 2024-03-17 13:35:09
|
Thanks so very much! Back to 6th grade for me. Bob On Sun, Mar 17, 2024 at 8:24 AM Douglas Katzman <do...@go...> wrote: > > > On Sun, Mar 17, 2024 at 7:33 AM Robert Boyer <rob...@gm...> > wrote: > >> >> ;;; A bit array of 10^11 elements takes up 10^8 bytes, less than 1 >> gigabyte. >> >> Check your assumptions > > ** (format t "~,,'_:d~%" (/ (expt 10 11) 8))* > 12_500_000_000 > |
From: Douglas K. <do...@go...> - 2024-03-17 13:24:19
|
On Sun, Mar 17, 2024 at 7:33 AM Robert Boyer <rob...@gm...> wrote: > > ;;; A bit array of 10^11 elements takes up 10^8 bytes, less than 1 > gigabyte. > > Check your assumptions ** (format t "~,,'_:d~%" (/ (expt 10 11) 8))* 12_500_000_000 |
From: MrDispatch <MrD...@pr...> - 2024-03-17 11:38:25
|
Perhaps there would be more answers in the scripture ? What would Jesus say about it ? -------- Original Message -------- On Mar 17, 2024, 12:32, Robert Boyer wrote: > ;;; On sudden death for a very nice, rather new Lenovo Chromebook. cat > ;;; /proc/cpuinfo at the end. > > ;;; Jeremiah chapter 8 v. 22: Is there no balm in Gilead? > > ;;; Start SBCL in this way: > > ;;; sbcl --dynamic-space-size 32000 --no-userinit > > ;;; SBCL has asked for, and seems to have gotten, 32 gigabytes of some > ;;; fantasy substance. > > ;;; A bit array of 10^11 elements takes up 10^8 bytes, less than 1 gigabyte. > > ;;; Make one defun. > > (defun sum (n) > (declare (fixnum n)) > (let ((ar (make-array n :element-type '(integer 0 1))) > (cnt 0) > (i 0)) > (declare (type (array (integer 0 1) (*))) > (fixnum cnt i)) > (loop > (cond ((eql i n) (return nil))) > (setf (aref ar i) 1) > (incf i)) > (setf i 0) > (loop > (cond ((eql i n) (return cnt))) > (incf cnt (aref ar i)) > (incf i)))) > > ;;; Eval one form. > > (time (sum (expt 10 10))) > > ;;; Takes 50 seconds. Ok! > > ;;; Try for more: > > (time (sum (expt 10 11))) > > ;;; That last form kills SBCL and my Chromebook so badly that a reboot of the > ;;; Chromebook is needed. One proof of Chromebook death is that the > ;;; Chromebook panel displays a time that is very, very wrong, minutes behind > ;;; the right time. Even I know it is time for the superdooper power button: > ;;; ⏻ with ⟳ held down it is! > > ;;; The sad death tale continues sometimes. Eventually, the screen goes > ;;; blank. The Chromebook restarts, so it thinks. I try to start Emacs. I am > ;;; told I need to restart Linux, and press 'ok'. I am again told I need to > ;;; restart Linux. Even I know it is time for: ⏻ with ⟳ held down it is! > > #| >> cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 156 > model name : Intel(R) Celeron(R) N4500 @ 1.10GHz > stepping : 0 > microcode : 0x1 > cpu MHz : 1113.600 > cache size : 4096 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 27 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms rdseed smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves arat vnmi umip waitpkg gfni rdpid movdiri movdir64b md_clear arch_capabilities > vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml tsc_scaling usr_wait_pause > bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs srbds mmio_stale_data > bogomips : 2227.20 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 156 > model name : Intel(R) Celeron(R) N4500 @ 1.10GHz > stepping : 0 > microcode : 0x1 > cpu MHz : 1113.600 > cache size : 4096 KB > physical id : 1 > siblings : 1 > core id : 0 > cpu cores : 1 > apicid : 1 > initial apicid : 1 > fpu : yes > fpu_exception : yes > cpuid level : 27 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms rdseed smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves arat vnmi umip waitpkg gfni rdpid movdiri movdir64b md_clear arch_capabilities > vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml tsc_scaling usr_wait_pause > bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs srbds mmio_stale_data > bogomips : 2227.20 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > > |# > > ;;; Local Variables: ;;; > ;;; mode: Lisp ;;; > ;;; coding: utf-8 ;;; > ;;; End: ;;; |
From: Robert B. <rob...@gm...> - 2024-03-17 11:33:20
|
;;; On sudden death for a very nice, rather new Lenovo Chromebook. cat ;;; /proc/cpuinfo at the end. ;;; Jeremiah chapter 8 v. 22: Is there no balm in Gilead? ;;; Start SBCL in this way: ;;; sbcl --dynamic-space-size 32000 --no-userinit ;;; SBCL has asked for, and seems to have gotten, 32 gigabytes of some ;;; fantasy substance. ;;; A bit array of 10^11 elements takes up 10^8 bytes, less than 1 gigabyte. ;;; Make one defun. (defun sum (n) (declare (fixnum n)) (let ((ar (make-array n :element-type '(integer 0 1))) (cnt 0) (i 0)) (declare (type (array (integer 0 1) (*))) (fixnum cnt i)) (loop (cond ((eql i n) (return nil))) (setf (aref ar i) 1) (incf i)) (setf i 0) (loop (cond ((eql i n) (return cnt))) (incf cnt (aref ar i)) (incf i)))) ;;; Eval one form. (time (sum (expt 10 10))) ;;; Takes 50 seconds. Ok! ;;; Try for more: (time (sum (expt 10 11))) ;;; That last form kills SBCL and my Chromebook so badly that a reboot of the ;;; Chromebook is needed. One proof of Chromebook death is that the ;;; Chromebook panel displays a time that is very, very wrong, minutes behind ;;; the right time. Even I know it is time for the superdooper power button: ;;; ⏻ with ⟳ held down it is! ;;; The sad death tale continues sometimes. Eventually, the screen goes ;;; blank. The Chromebook restarts, so it thinks. I try to start Emacs. I am ;;; told I need to restart Linux, and press 'ok'. I am again told I need to ;;; restart Linux. Even I know it is time for: ⏻ with ⟳ held down it is! #| > cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 156 model name : Intel(R) Celeron(R) N4500 @ 1.10GHz stepping : 0 microcode : 0x1 cpu MHz : 1113.600 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 27 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms rdseed smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves arat vnmi umip waitpkg gfni rdpid movdiri movdir64b md_clear arch_capabilities vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml tsc_scaling usr_wait_pause bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs srbds mmio_stale_data bogomips : 2227.20 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 156 model name : Intel(R) Celeron(R) N4500 @ 1.10GHz stepping : 0 microcode : 0x1 cpu MHz : 1113.600 cache size : 4096 KB physical id : 1 siblings : 1 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 27 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms rdseed smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves arat vnmi umip waitpkg gfni rdpid movdiri movdir64b md_clear arch_capabilities vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml tsc_scaling usr_wait_pause bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs srbds mmio_stale_data bogomips : 2227.20 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: |# ;;; Local Variables: ;;; ;;; mode: Lisp ;;; ;;; coding: utf-8 ;;; ;;; End: ;;; |
From: MrDispatch <MrD...@pr...> - 2024-03-13 10:44:43
|
Hi, [disclaimer: certainly not SBCL expert] since SBCL is able to produce nice tight assembly with (debug 0) (safety 0) (speed 3) - after you silence all the helpful warnings == add type annotations / ensure type stability, I'd try the straight-forward way. For makenan (declare (ignore arg)) and returning the right incantation for NaN. For dparts, using the appropriate operation (does the cl spec support it, or exported parts of SBCL internals?) Then I'd look at (disassemble #'...), and hopefully it would look good ? -------- Original Message -------- On Mar 6, 2024, 23:15, Richard Fateman wrote: > I am trying to use SBCL NaNs for storing and retrieving information. (in Maxima > computer algebra system). > > Here's what I have working in another lisp (Allegro CL) > > (setf v (makenan "hello")) ; returns #.*NAN-DOUBLE* > > (dparts v) ; returns multiple values: sign, exponent, fraction... > 0 > 1024 > 6755427571938927 > > (num2chars 6755427571938927) ; returns " hello" > > I would like to implement makenan, dparts, num2chars > in SBCL. In Allegro CL with (optimize (safety 0)(speed 3)) > I can do the first two by making an alias of a 64-bit float with > an array of bits. > Suggestions? Thanks > Richard Fateman |
From: Richard F. <fa...@gm...> - 2024-03-06 22:15:26
|
I am trying to use SBCL NaNs for storing and retrieving information. (in Maxima computer algebra system). Here's what I have working in another lisp (Allegro CL) (setf v (*makenan* "hello")) ; returns #.*NAN-DOUBLE* (*dparts* v) ; returns multiple values: sign, exponent, fraction... 0 1024 6755427571938927 (*num2chars* 6755427571938927) ; returns " hello" I would like to implement makenan, dparts, num2chars in SBCL. In Allegro CL with (optimize (safety 0)(speed 3)) I can do the first two by making an alias of a 64-bit float with an array of bits. Suggestions? Thanks Richard Fateman |
From: Qian Y. <old...@gm...> - 2024-03-06 12:11:43
|
Thanks, I can confirm that the complication time is much improved after your change. - Best, - Qian On 3/6/24 04:12, Stas Boukarev wrote: > I added a hash-table, so it should be somewhat faster. > > On Tue, Mar 5, 2024 at 5:05 PM Qian Yun <old...@gm...> wrote: > >> Hi, >> >> Thanks for looking into this. >> >> You can debug using this repo: >> >> https://github.com/oldk1331/fricas0 >> >> It compiles fricas source code to pure lisp code. >> >> You can reproduce this issue by: >> >> ```` >> cd fricas0 >> ## comment out the last expression in fricas.lisp, >> ## so that you stay in Lisp REPL instead of fricas REPL >> sbcl --load fricas.lisp >> > (in-package "BOOT") >> > (compile-file "algebra/COMMONOP.lsp") >> ```` >> >> I'm using "COMMONOP.lsp" here, the slow down is 10x: 12s vs 2min. >> (The 25x slow down is RSIMP.lsp which is in the newer release of >> fricas, not this version.) >> >> - Best, >> - Qian >> >> On 3/5/24 20:23, Stas Boukarev wrote: >>> fricas uses makefiles for compilation, so it's hard to profile. >>> >>> On Tue, Mar 5, 2024 at 1:21 PM Qian Yun <old...@gm...> wrote: >>> >>>> When compiling FriCAS with sbcl-2.4.2, the complication time triples. >>>> Closer look finds out that the complication of a certain file takes >>>> 200s while sbcl-2.4.1 takes 8s. >>>> >>>> git bisect points to this commit: >>>> >>>> c2a71639b7c3ae5f3f0abe08cf9e8cf0cafcdbb4 >>>> map-equality-constraints: process type ranges, not just constants. >>>> >>>> I wonder if this information is enough. If not, I can provide >>>> more detailed steps on how to reproduce this. >>>> >>>> - Best, >>>> - Qian >>>> >>>> >>>> _______________________________________________ >>>> Sbcl-bugs mailing list >>>> Sbc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs >>>> >>> >> > |
From: Robert B. <rob...@gm...> - 2024-03-05 23:37:53
|
Thank so much. Bob On Tue, Mar 5, 2024 at 5:36 PM Stas Boukarev <sta...@gm...> wrote: > If it's not being loaded then it means it's not in ~. > > On Wed, Mar 6, 2024 at 12:57 AM Robert Boyer <rob...@gm...> > wrote: > >> >> > head .sbclrc >> ;;; -*- coding: utf-8 Mode: Lisp -*- >> >> (format t "~%Note: Version 130 of .sbclrc.") >> (format >> t >> "~%Note: Loading >> /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/.sbclrc.") >> (format t "~%Note: Requiring :sb-posix.") >> (require :sb-posix) >> (format t "~%Note: Setting *print-miser-width* to 100.") >> (setq *print-miser-width* 99) >> >> >> > sbcl >> This is SBCL 2.2.9.debian, 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. >> * >> _______________________________________________ >> Sbcl-bugs mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs >> > |
From: Stas B. <sta...@gm...> - 2024-03-05 23:36:24
|
If it's not being loaded then it means it's not in ~. On Wed, Mar 6, 2024 at 12:57 AM Robert Boyer <rob...@gm...> wrote: > > > head .sbclrc > ;;; -*- coding: utf-8 Mode: Lisp -*- > > (format t "~%Note: Version 130 of .sbclrc.") > (format > t > "~%Note: Loading > /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/.sbclrc.") > (format t "~%Note: Requiring :sb-posix.") > (require :sb-posix) > (format t "~%Note: Setting *print-miser-width* to 100.") > (setq *print-miser-width* 99) > > > > sbcl > This is SBCL 2.2.9.debian, 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. > * > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Robert B. <rob...@gm...> - 2024-03-05 21:56:42
|
> head .sbclrc ;;; -*- coding: utf-8 Mode: Lisp -*- (format t "~%Note: Version 130 of .sbclrc.") (format t "~%Note: Loading /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/.sbclrc.") (format t "~%Note: Requiring :sb-posix.") (require :sb-posix) (format t "~%Note: Setting *print-miser-width* to 100.") (setq *print-miser-width* 99) > sbcl This is SBCL 2.2.9.debian, 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. * |
From: Stas B. <sta...@gm...> - 2024-03-05 20:12:59
|
I added a hash-table, so it should be somewhat faster. On Tue, Mar 5, 2024 at 5:05 PM Qian Yun <old...@gm...> wrote: > Hi, > > Thanks for looking into this. > > You can debug using this repo: > > https://github.com/oldk1331/fricas0 > > It compiles fricas source code to pure lisp code. > > You can reproduce this issue by: > > ```` > cd fricas0 > ## comment out the last expression in fricas.lisp, > ## so that you stay in Lisp REPL instead of fricas REPL > sbcl --load fricas.lisp > > (in-package "BOOT") > > (compile-file "algebra/COMMONOP.lsp") > ```` > > I'm using "COMMONOP.lsp" here, the slow down is 10x: 12s vs 2min. > (The 25x slow down is RSIMP.lsp which is in the newer release of > fricas, not this version.) > > - Best, > - Qian > > On 3/5/24 20:23, Stas Boukarev wrote: > > fricas uses makefiles for compilation, so it's hard to profile. > > > > On Tue, Mar 5, 2024 at 1:21 PM Qian Yun <old...@gm...> wrote: > > > >> When compiling FriCAS with sbcl-2.4.2, the complication time triples. > >> Closer look finds out that the complication of a certain file takes > >> 200s while sbcl-2.4.1 takes 8s. > >> > >> git bisect points to this commit: > >> > >> c2a71639b7c3ae5f3f0abe08cf9e8cf0cafcdbb4 > >> map-equality-constraints: process type ranges, not just constants. > >> > >> I wonder if this information is enough. If not, I can provide > >> more detailed steps on how to reproduce this. > >> > >> - Best, > >> - Qian > >> > >> > >> _______________________________________________ > >> Sbcl-bugs mailing list > >> Sbc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > >> > > > |
From: Qian Y. <old...@gm...> - 2024-03-05 14:05:22
|
Hi, Thanks for looking into this. You can debug using this repo: https://github.com/oldk1331/fricas0 It compiles fricas source code to pure lisp code. You can reproduce this issue by: ```` cd fricas0 ## comment out the last expression in fricas.lisp, ## so that you stay in Lisp REPL instead of fricas REPL sbcl --load fricas.lisp > (in-package "BOOT") > (compile-file "algebra/COMMONOP.lsp") ```` I'm using "COMMONOP.lsp" here, the slow down is 10x: 12s vs 2min. (The 25x slow down is RSIMP.lsp which is in the newer release of fricas, not this version.) - Best, - Qian On 3/5/24 20:23, Stas Boukarev wrote: > fricas uses makefiles for compilation, so it's hard to profile. > > On Tue, Mar 5, 2024 at 1:21 PM Qian Yun <old...@gm...> wrote: > >> When compiling FriCAS with sbcl-2.4.2, the complication time triples. >> Closer look finds out that the complication of a certain file takes >> 200s while sbcl-2.4.1 takes 8s. >> >> git bisect points to this commit: >> >> c2a71639b7c3ae5f3f0abe08cf9e8cf0cafcdbb4 >> map-equality-constraints: process type ranges, not just constants. >> >> I wonder if this information is enough. If not, I can provide >> more detailed steps on how to reproduce this. >> >> - Best, >> - Qian >> >> >> _______________________________________________ >> Sbcl-bugs mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs >> > |
From: Stas B. <sta...@gm...> - 2024-03-05 12:23:31
|
fricas uses makefiles for compilation, so it's hard to profile. On Tue, Mar 5, 2024 at 1:21 PM Qian Yun <old...@gm...> wrote: > When compiling FriCAS with sbcl-2.4.2, the complication time triples. > Closer look finds out that the complication of a certain file takes > 200s while sbcl-2.4.1 takes 8s. > > git bisect points to this commit: > > c2a71639b7c3ae5f3f0abe08cf9e8cf0cafcdbb4 > map-equality-constraints: process type ranges, not just constants. > > I wonder if this information is enough. If not, I can provide > more detailed steps on how to reproduce this. > > - Best, > - Qian > > > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Qian Y. <old...@gm...> - 2024-03-05 10:08:55
|
When compiling FriCAS with sbcl-2.4.2, the complication time triples. Closer look finds out that the complication of a certain file takes 200s while sbcl-2.4.1 takes 8s. git bisect points to this commit: c2a71639b7c3ae5f3f0abe08cf9e8cf0cafcdbb4 map-equality-constraints: process type ranges, not just constants. I wonder if this information is enough. If not, I can provide more detailed steps on how to reproduce this. - Best, - Qian |
From: Robert B. <rob...@gm...> - 2024-03-04 09:12:05
|
> But... sbcl doesn't read gzip files. What an idiot I am! Gravest apologies! Bob On Mon, Mar 4, 2024 at 2:58 AM Stas Boukarev <sta...@gm...> wrote: > But... sbcl doesn't read gzip files. > > On Mon, Mar 4, 2024 at 11:55 AM Robert Boyer <rob...@gm...> > wrote: > >> Dear SBCL folks, >> >> I believe there is a bug in the way that SBCL reads .gz files. >> >> I think that reading .gz files is so wonderful! >> >> Probably, this is all a stupid mistake of mine. Apologies in advance. >> >> I have attached the file eratosthenes.lisp, which is also >> >> >> https://drive.google.com/file/d/1-BJpLETDg88hMNZ8b73Vni2mR1Z7CMcg/view?usp=drive_link >> >> so gmail will probably also give you another copy with this message. >> >> Here is what I type: >> >> cd /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/ >> >> sbcl --dynamic-space-size 32000 >> >> ;;; We hope that the file "eratosthenes.lisp" exists here. >> >> (load "eratosthenes.lisp") >> >> (defparameter size (expt 10 6)) >> >> (time (build-sieve size)) >> >> ;;; Builds Eratosthenes' sieve for the nonnegative integers below size. >> >> (defparameter bin-file (format nil "primes-below-~s.bin" size)) >> >> ;;; We now create bin-file. >> >> (time (write-bytes)) >> >> (defparameter gz-file (concatenate 'string bin-file ".gz")) >> >> ;;; We next gzip that .bin file to also get a .gz version. >> >> (time (run-program "/usr/bin/gzip" (list bin-file "-k"))) >> >> (defparameter gz-file (concatenate 'string bin-file ".gz")) >> >> ;;; Because we gave gzip the '-k' keyword it did not delete bin-file. >> >> ;;; Now we reveal a difference between SBCL's reading of bin-file and its >> ;;; reading of gz-file. >> >> (time (read-bytes bin-file)) >> >> (defparameter answer1 (aref *sieve* 0)) >> >> (time (read-bytes gz-file)) >> >> (defparameter answer2 (aref *sieve* 0)) >> >> ;;; We get different results: >> >> (cond ((not (equal answer1 answer2)) >> (error "bad................................."))) >> >> >> >> >> Here is the output I get: >> >> This is SBCL 2.2.9.debian, 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. >> * >> Note: Loading version 105 of eratosthenes.lisp. >> Note: Last edited Mar 3, 2024. >> Note: Finished loading eratosthenes.lisp >> T >> * SIZE >> * >> Note: running (build-sieve 1,000,000). >> Evaluation took: >> 0.037 seconds of real time >> 0.036608 seconds of total run time (0.036608 user, 0.000000 system) >> 100.00% CPU >> 41,207,045 processor cycles >> 1,776 bytes consed >> >> OK >> * BIN-FILE >> * Evaluation took: >> 0.054 seconds of real time >> 0.018726 seconds of total run time (0.017602 user, 0.001124 system) >> 35.19% CPU >> 60,212,938 processor cycles >> 0 bytes consed >> >> "primes-below-1000000.bin" >> * GZ-FILE >> * Evaluation took: >> 0.009 seconds of real time >> 0.001558 seconds of total run time (0.000352 user, 0.001206 system) >> 22.22% CPU >> 21 forms interpreted >> 9,632,889 processor cycles >> 0 bytes consed >> >> #<SB-IMPL::PROCESS :EXITED 2> >> * GZ-FILE >> * Evaluation took: >> 0.025 seconds of real time >> 0.015007 seconds of total run time (0.012961 user, 0.002046 system) >> 60.00% CPU >> 27,695,516 processor cycles >> 30,064 bytes consed >> >> DONE >> * ANSWER1 >> * Evaluation took: >> 0.012 seconds of real time >> 0.006580 seconds of total run time (0.004992 user, 0.001588 system) >> 58.33% CPU >> 13,574,046 processor cycles >> 11,888 bytes consed >> >> DONE >> * ANSWER2 >> * >> debugger invoked on a SIMPLE-ERROR in thread >> #<THREAD "main thread" RUNNING {1001348003}>: >> bad................................. >> >> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. >> >> restarts (invokable by number or by possibly-abbreviated name): >> 0: [ABORT] Exit debugger, returning to top level. >> >> (SB-INT:SIMPLE-EVAL-IN-LEXENV (ERROR >> "bad.................................") #<NULL-LEXENV>) >> 0] >> >> >> Thanks so much for SBCL which is the best system I have ever used >> excepting Emacs. >> I hope SBCL and Emacs merge. Even with their new 'native-compile', >> the speed of Emacs Lisp is nothing to compare with that of SBCL. >> >> Bob >> _______________________________________________ >> Sbcl-bugs mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs >> > |
From: Stas B. <sta...@gm...> - 2024-03-04 08:58:53
|
But... sbcl doesn't read gzip files. On Mon, Mar 4, 2024 at 11:55 AM Robert Boyer <rob...@gm...> wrote: > Dear SBCL folks, > > I believe there is a bug in the way that SBCL reads .gz files. > > I think that reading .gz files is so wonderful! > > Probably, this is all a stupid mistake of mine. Apologies in advance. > > I have attached the file eratosthenes.lisp, which is also > > > https://drive.google.com/file/d/1-BJpLETDg88hMNZ8b73Vni2mR1Z7CMcg/view?usp=drive_link > > so gmail will probably also give you another copy with this message. > > Here is what I type: > > cd /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/ > > sbcl --dynamic-space-size 32000 > > ;;; We hope that the file "eratosthenes.lisp" exists here. > > (load "eratosthenes.lisp") > > (defparameter size (expt 10 6)) > > (time (build-sieve size)) > > ;;; Builds Eratosthenes' sieve for the nonnegative integers below size. > > (defparameter bin-file (format nil "primes-below-~s.bin" size)) > > ;;; We now create bin-file. > > (time (write-bytes)) > > (defparameter gz-file (concatenate 'string bin-file ".gz")) > > ;;; We next gzip that .bin file to also get a .gz version. > > (time (run-program "/usr/bin/gzip" (list bin-file "-k"))) > > (defparameter gz-file (concatenate 'string bin-file ".gz")) > > ;;; Because we gave gzip the '-k' keyword it did not delete bin-file. > > ;;; Now we reveal a difference between SBCL's reading of bin-file and its > ;;; reading of gz-file. > > (time (read-bytes bin-file)) > > (defparameter answer1 (aref *sieve* 0)) > > (time (read-bytes gz-file)) > > (defparameter answer2 (aref *sieve* 0)) > > ;;; We get different results: > > (cond ((not (equal answer1 answer2)) > (error "bad................................."))) > > > > > Here is the output I get: > > This is SBCL 2.2.9.debian, 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. > * > Note: Loading version 105 of eratosthenes.lisp. > Note: Last edited Mar 3, 2024. > Note: Finished loading eratosthenes.lisp > T > * SIZE > * > Note: running (build-sieve 1,000,000). > Evaluation took: > 0.037 seconds of real time > 0.036608 seconds of total run time (0.036608 user, 0.000000 system) > 100.00% CPU > 41,207,045 processor cycles > 1,776 bytes consed > > OK > * BIN-FILE > * Evaluation took: > 0.054 seconds of real time > 0.018726 seconds of total run time (0.017602 user, 0.001124 system) > 35.19% CPU > 60,212,938 processor cycles > 0 bytes consed > > "primes-below-1000000.bin" > * GZ-FILE > * Evaluation took: > 0.009 seconds of real time > 0.001558 seconds of total run time (0.000352 user, 0.001206 system) > 22.22% CPU > 21 forms interpreted > 9,632,889 processor cycles > 0 bytes consed > > #<SB-IMPL::PROCESS :EXITED 2> > * GZ-FILE > * Evaluation took: > 0.025 seconds of real time > 0.015007 seconds of total run time (0.012961 user, 0.002046 system) > 60.00% CPU > 27,695,516 processor cycles > 30,064 bytes consed > > DONE > * ANSWER1 > * Evaluation took: > 0.012 seconds of real time > 0.006580 seconds of total run time (0.004992 user, 0.001588 system) > 58.33% CPU > 13,574,046 processor cycles > 11,888 bytes consed > > DONE > * ANSWER2 > * > debugger invoked on a SIMPLE-ERROR in thread > #<THREAD "main thread" RUNNING {1001348003}>: > bad................................. > > Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (SB-INT:SIMPLE-EVAL-IN-LEXENV (ERROR > "bad.................................") #<NULL-LEXENV>) > 0] > > > Thanks so much for SBCL which is the best system I have ever used > excepting Emacs. > I hope SBCL and Emacs merge. Even with their new 'native-compile', > the speed of Emacs Lisp is nothing to compare with that of SBCL. > > Bob > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |