You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(8) |
2003 |
Jan
(5) |
Feb
(4) |
Mar
(14) |
Apr
|
May
(27) |
Jun
(10) |
Jul
(3) |
Aug
(28) |
Sep
(27) |
Oct
(3) |
Nov
(14) |
Dec
(19) |
2004 |
Jan
(32) |
Feb
(15) |
Mar
(21) |
Apr
(69) |
May
(18) |
Jun
(15) |
Jul
(23) |
Aug
(14) |
Sep
(38) |
Oct
(20) |
Nov
(76) |
Dec
(27) |
2005 |
Jan
(24) |
Feb
(32) |
Mar
(39) |
Apr
(65) |
May
(69) |
Jun
(37) |
Jul
(32) |
Aug
(28) |
Sep
(28) |
Oct
(17) |
Nov
(30) |
Dec
(24) |
2006 |
Jan
(45) |
Feb
(38) |
Mar
(19) |
Apr
(26) |
May
(19) |
Jun
(29) |
Jul
(13) |
Aug
(26) |
Sep
(53) |
Oct
(46) |
Nov
(40) |
Dec
(85) |
2007 |
Jan
(45) |
Feb
(51) |
Mar
(69) |
Apr
(48) |
May
(75) |
Jun
(35) |
Jul
(35) |
Aug
(25) |
Sep
(11) |
Oct
(16) |
Nov
(9) |
Dec
(59) |
2008 |
Jan
(36) |
Feb
(17) |
Mar
(28) |
Apr
(13) |
May
(1) |
Jun
(25) |
Jul
(24) |
Aug
(52) |
Sep
(19) |
Oct
(52) |
Nov
(43) |
Dec
(80) |
2009 |
Jan
(33) |
Feb
(30) |
Mar
(18) |
Apr
(15) |
May
(29) |
Jun
(58) |
Jul
(48) |
Aug
(35) |
Sep
(52) |
Oct
(59) |
Nov
(46) |
Dec
(31) |
2010 |
Jan
(26) |
Feb
(45) |
Mar
(55) |
Apr
(59) |
May
(8) |
Jun
(24) |
Jul
(43) |
Aug
(31) |
Sep
(43) |
Oct
(33) |
Nov
(41) |
Dec
(19) |
2011 |
Jan
(17) |
Feb
(31) |
Mar
(5) |
Apr
(31) |
May
(17) |
Jun
(28) |
Jul
(15) |
Aug
(38) |
Sep
(21) |
Oct
(25) |
Nov
(21) |
Dec
(21) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(17) |
Apr
(16) |
May
(58) |
Jun
(13) |
Jul
(40) |
Aug
(12) |
Sep
(10) |
Oct
(10) |
Nov
(14) |
Dec
(4) |
2013 |
Jan
(9) |
Feb
(8) |
Mar
(17) |
Apr
(10) |
May
|
Jun
(9) |
Jul
(1) |
Aug
(7) |
Sep
(8) |
Oct
(22) |
Nov
(9) |
Dec
(6) |
2014 |
Jan
(30) |
Feb
(55) |
Mar
(38) |
Apr
(15) |
May
(7) |
Jun
(17) |
Jul
(15) |
Aug
(13) |
Sep
(21) |
Oct
(29) |
Nov
(7) |
Dec
(10) |
2015 |
Jan
(11) |
Feb
(19) |
Mar
(32) |
Apr
(17) |
May
(5) |
Jun
(3) |
Jul
(9) |
Aug
(7) |
Sep
(19) |
Oct
(3) |
Nov
(31) |
Dec
(23) |
2016 |
Jan
(11) |
Feb
(5) |
Mar
(8) |
Apr
(10) |
May
(15) |
Jun
(1) |
Jul
(11) |
Aug
(9) |
Sep
(11) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
2017 |
Jan
(18) |
Feb
(19) |
Mar
(40) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(14) |
Aug
(21) |
Sep
(27) |
Oct
(22) |
Nov
(42) |
Dec
(3) |
2018 |
Jan
(9) |
Feb
(7) |
Mar
(31) |
Apr
(5) |
May
(7) |
Jun
|
Jul
(6) |
Aug
(34) |
Sep
(2) |
Oct
(8) |
Nov
(29) |
Dec
(7) |
2019 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(62) |
May
(18) |
Jun
(12) |
Jul
(30) |
Aug
(8) |
Sep
(4) |
Oct
(8) |
Nov
(6) |
Dec
(12) |
2020 |
Jan
(24) |
Feb
(4) |
Mar
(11) |
Apr
(16) |
May
(6) |
Jun
(59) |
Jul
(51) |
Aug
(18) |
Sep
(32) |
Oct
(19) |
Nov
(12) |
Dec
(29) |
2021 |
Jan
(11) |
Feb
(27) |
Mar
(30) |
Apr
(10) |
May
(29) |
Jun
(14) |
Jul
(10) |
Aug
(3) |
Sep
(12) |
Oct
(10) |
Nov
(18) |
Dec
(19) |
2022 |
Jan
(11) |
Feb
(8) |
Mar
(21) |
Apr
(30) |
May
(3) |
Jun
(2) |
Jul
(16) |
Aug
(9) |
Sep
(4) |
Oct
(2) |
Nov
(17) |
Dec
(10) |
2023 |
Jan
(16) |
Feb
(21) |
Mar
(42) |
Apr
(8) |
May
(7) |
Jun
(32) |
Jul
(3) |
Aug
(22) |
Sep
(11) |
Oct
(3) |
Nov
(16) |
Dec
(12) |
2024 |
Jan
(8) |
Feb
(15) |
Mar
(29) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nicolas N. <ne...@ma...> - 2007-12-24 09:09:19
|
wil...@ai... (William Harold Newman) writes: > Are you sure you want to do this? If you are not suppressing style > warnings completely, I'd expect it's because you want to be warned > about things like defining unused variables and calling undefined > functions and so forth. Yes. > Issuing warnings about code like > (defgeneric suppressing-errors (family fun) > (defmethod suppresing-errors ((family decorated-family) fun) > (with-invoked-decorators (family) > (funcall fun))) > has always seemed to me to be in the same spirit, and the only thing > the compiler will be able to see wrong about that code is that the > the DEFMETHOD has no matching DEFGENERIC. OK, but this special style is probably not so rarely encountered. At least, it was mentioned also by Kent Pitman in comp.lang.lisp several times. I usually use it in cases like this: ;;; class definition (defclass () ...) ;;; method definitions - some of them are specializations of already ;;; existing generic functions, some of them are more for local use. At ;;; least for the moment I do not want to decide, if these should be ;;; functions or generic functions. (defmethod ... ()) ... > Also, it seems to me that that's an odd thing to use DEFMETHOD for. I > sometimes feel the need, but I meet the need with a family of > DEFMACROs like > (defmacro def-declaimed-fun (name (args types return-type &key inline) > &body body)) > `(progn (declaim ...) (defun ...))) > and > (defmacro def-declaimed-proc (name (args types &key inline) &body body) > `(def-declaimed-fun ,name (,args ,types (values) :inline ,inline) ,@body)) > If you choose to use DEFMETHOD instead, you're choosing to tell the > compiler something somewhat misleading about what you're doing; a > roundabout way to stop the style warnings would be to choose to be > less misleading. The macro has the problem, that highlighting probably will not work as well, and maybe also the editor will not be able to locate the function definition as well, especially if something in the file has changed. Merry christmas, Nicolas |
From: Nicolas N. <ne...@ma...> - 2007-12-24 09:00:25
|
Rudi Schlatte <ru...@co...> writes: > On 23.12.2007, at 05:20, Nicolas Neuss wrote: > >> Hello, >> >> I sometimes like to use DEFMETHOD as replacement for DEFUN + type >> declarations (i.e., even if there is no broader use of that function in >> which case a DEFGENERIC would make sense). In these cases, the style >> warning "implicitly creating new generic function" is a nuisance. Is it >> possible to switch off this warning selectively? > > In addition to all the points in Bill's reply, there's also > > (defgeneric foo (x) (:method ((x fixnum)) x)) Yes, I know, but this is still too clumsy to write for my taste. (BTW, the use of a type specifier like FIXNUM -which is not guaranteed to be a class- is non-standard.) Merry christmas, Nicolas > Since that form defines the generic function and a method, there are no > warnings. > > Rudi > > -- PD Dr. Nicolas Neuss University Karlsruhe Tel: 0049-721-608-7634 Email: ne...@ma... WWW: <http://www.mathematik.uni-karlsruhe.de/~neuss> |
From: Rudi S. <ru...@co...> - 2007-12-24 02:45:19
|
On 23.12.2007, at 05:20, Nicolas Neuss wrote: > Hello, > > I sometimes like to use DEFMETHOD as replacement for DEFUN + type > declarations (i.e., even if there is no broader use of that function > in > which case a DEFGENERIC would make sense). In these cases, the style > warning "implicitly creating new generic function" is a nuisance. > Is it > possible to switch off this warning selectively? In addition to all the points in Bill's reply, there's also (defgeneric foo (x) (:method ((x fixnum)) x)) Since that form defines the generic function and a method, there are no warnings. Rudi |
From: <wil...@ai...> - 2007-12-23 17:32:11
|
On Sat, Dec 22, 2007 at 10:20:55PM +0100, Nicolas Neuss wrote: > I sometimes like to use DEFMETHOD as replacement for DEFUN + type > declarations (i.e., even if there is no broader use of that function in > which case a DEFGENERIC would make sense). In these cases, the style > warning "implicitly creating new generic function" is a nuisance. Is it > possible to switch off this warning selectively? Are you sure you want to do this? If you are not suppressing style warnings completely, I'd expect it's because you want to be warned about things like defining unused variables and calling undefined functions and so forth. Issuing warnings about code like (defgeneric suppressing-errors (family fun) (defmethod suppresing-errors ((family decorated-family) fun) (with-invoked-decorators (family) (funcall fun))) has always seemed to me to be in the same spirit, and the only thing the compiler will be able to see wrong about that code is that the the DEFMETHOD has no matching DEFGENERIC. Also, it seems to me that that's an odd thing to use DEFMETHOD for. I sometimes feel the need, but I meet the need with a family of DEFMACROs like (defmacro def-declaimed-fun (name (args types return-type &key inline) &body body)) `(progn (declaim ...) (defun ...))) and (defmacro def-declaimed-proc (name (args types &key inline) &body body) `(def-declaimed-fun ,name (,args ,types (values) :inline ,inline) ,@body)) If you choose to use DEFMETHOD instead, you're choosing to tell the compiler something somewhat misleading about what you're doing; a roundabout way to stop the style warnings would be to choose to be less misleading. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C God grant me serenity to accept the code I cannot change, courage to change the code I can, and wisdom to know the difference. -- Erik Naggum |
From: Nicolas N. <ne...@ma...> - 2007-12-22 21:21:06
|
Hello, I sometimes like to use DEFMETHOD as replacement for DEFUN + type declarations (i.e., even if there is no broader use of that function in which case a DEFGENERIC would make sense). In these cases, the style warning "implicitly creating new generic function" is a nuisance. Is it possible to switch off this warning selectively? Thank you very much, Nicolas |
From: michael g. <mic...@gm...> - 2007-12-22 02:34:49
|
Ok, So I've been playing with sb-simd. Maybe its out of date, maybe not. The patches are against the x86 version, and I run x86-64 so doesn't matter for me. I started out on the task of bringing the MMX and SSE vector definitions over from the sb-simd patch, but I found native SSE support already for ordinary floating point.. presumably because x87 code is somewhat deprecated. Some of the code collides (not just contextually), and it would be much cleaner to add SIMD vector support on top of the code that is already there, I think. Though I'm still not entirely comfortable with the code. Is anyone familiar with these patches? From the SBCL developer's standpoint, what is needed to get primitive SIMD support rolled into the mainline code? I'm something of a math geek and I've got lots of code just begging for loop optimization. -M |
From: Terrence B. <ter...@jp...> - 2007-12-21 18:55:29
|
>From the Windows command shell, when I attempt to start sbcl, it does not load my .sbclrc file located at: c:/Documents and Settings/W049945/Application Data/.sbclrc even though, I had no problems with it loading from here before. The manual says it loads HOME/.sbclrc but HOME is not defined in my environment. What is odd is that after I supply the --userinit option with the location of my .sbclrc, then SBCL fails to find the sb-introspect package even though it used to. All of the above is happening directly from the Windows command shell. It all started happening with I played around with trying to get SBCL to run Common Music (http://commonmusic.sf.net) and when that failed I got it running under Clisp. But now I want to move back to SBCL for development and it is failing. Transcript of load after manually supplying --userinit follows: C:\>sbcl --userinit "c:\\Documents and Settings\\w049945\\Application Data\\.sbclrc" This is SBCL 1.0.9, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * (asdf:operate 'asdf:load-op 'redick) ; loading system definition from ; C:\cygwin\home\W049945\prg\redick\lisp\redick.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM REDICK {ACE8319}> as REDICK ; loading system definition from ; C:\cygwin\home\W049945\prg\lisp-asdf\series-2.2.9\series.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM SERIES {AFA2979}> as SERIES ; registering #<SYSTEM SERIES-TESTS {B0AF3B9}> as SERIES-TESTS ; compiling file "C:\\cygwin\\home\\W049945 \\prg\\redick\\lisp\\util\\array.lisp " (written 19 DEC 2007 11:19:17 AM): ; compiling (IN-PACKAGE :REDICK) ; compiling (DEFUN NOUN-RANK ...) ; compiling (DEFUN NOUN-SHAPE ...) ; compiling (DEFUN SET-ARRAY! ...) ; compiling (DEFUN PRODUCT-SCAN ...) ; compiling (DEFUN PRODUCT-SCAN_ ...) ; compiling (DEFUN ARRAY->VECTOR ...) ; compiling (DEFUN ARRAY-SPLIT ...) ; compiling (DEFUN ARRAY-JOIN ...) ; file: C:\cygwin\home\W049945\prg\redick\lisp\util\array.lisp ; in: DEFUN ARRAY-JOIN ; (LET* ((REDICK::CURRENT-DIMENSIONS (ARRAY-DIMENSIONS REDICK::A)) ; (REDICK::ZEROES ; (MAKE-SEQUENCE 'LIST (LENGTH REDICK::CURRENT-DIMENSIONS) ; :INITIAL-ELEMENT 0)) ; (REDICK::INNER-DIMENSIONS ; (ARRAY-DIMENSIONS (APPLY #'AREF REDICK::A REDICK::ZEROES))) ; (REDICK::TARGET-DIMENSIONS ; (APPEND REDICK::CURRENT-DIMENSIONS REDICK::INNER-DIMENSIONS)) ; (REDICK::TARGET-ARRAY (MAKE-ARRAY REDICK::TARGET-DIMENSIONS)) ; (REDICK::TARGET-ARRAY-INDICES ; (REDICK::X-PROD (MAPCAR #'REDICK::IOTA REDICK::TARGET-DIMENSIONS))) ; (REDICK::SPLIT-POINT (LENGTH REDICK::CURRENT-DIMENSIONS)) ; (REDICK::TMP ; (FORMAT T "array-join: ~A~%" REDICK::TARGET-ARRAY-INDICES))) ; (PROGN ; (LOOP REDICK::FOR REDICK::TAI REDICK::IN REDICK::TARGET-ARRAY-INDICES ; REDICK::FOR (REDICK::OUTER-I REDICK::INNER-I) = ; (MULTIPLE-VALUE-LIST ; (REDICK::SEQUENCE-PARTITION REDICK::TAI REDICK::SPLIT-POINT)) ; DO ; (LET* (# #) ; (SETF # REDICK::INNER-VAL))) ; REDICK::TARGET-ARRAY)) ; ; caught STYLE-WARNING: ; The variable TMP is defined but never used. ; C:\cygwin\home\W049945\prg\redick\lisp\util\array.fasl written ; compilation finished in 0:00:00 WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {B454D21}> on #<CL-SOURCE-FILE "array" {B477C81}>. debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR: The name "SB-INTROSPECT" does not designate any package. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<LOAD-OP NIL {B477C91}> on #<CL-SOURCE-FILE "fns" {B477CD1}>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL {B477C91}> on #<CL-SOURCE-FILE "fns" {B477CD1}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-INT:%FIND-PACKAGE-OR-LOSE "SB-INTROSPECT") 0] ; |
From: <ter...@jp...> - 2007-12-21 17:57:31
|
[my gmane post did not seem to go through. so I am emailing it] I have no system-wide .sbclrc. Although my user .sbclrc used to load perfectly fine from the Windows command shell, when I attempt to start sbcl, it no longer does. It is located at: c:/Documents and Settings/W049945/Application Data/.sbclrc even though I had no problems with it loading from here before. The manual says it loads HOME/.sbclrc but HOME is not defined in my environment. However, it was loading the .sbclrc loaded at c:/Documents and Settings/W049945/Application Data just fine. What is odd is that after I supply the --userinit option with the location of my .sbclrc, then SBCL fails to find the sb-introspect package even though it used to. All of the above is happening directly from the Windows command shell. It all started happening with I played around with trying to get SBCL to run Common Music (http://commonmusic.sf.net) and when that failed I got it running under Clisp. But now I want to move back to SBCL for development and it is failing. Transcript of load after manually supplying --userinit follows: C:\>sbcl --userinit "c:\\Documents and Settings\\w049945\\Application Data\\.sbclrc" This is SBCL 1.0.9, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * (asdf:operate 'asdf:load-op 'redick) ; loading system definition from ; C:\cygwin\home\W049945\prg\redick\lisp\redick.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM REDICK {ACE8319}> as REDICK ; loading system definition from ; C:\cygwin\home\W049945\prg\lisp-asdf\series-2.2.9\series.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM SERIES {AFA2979}> as SERIES ; registering #<SYSTEM SERIES-TESTS {B0AF3B9}> as SERIES-TESTS ; compiling file "C:\\cygwin\\home\\W049945\\prg\\redick\\lisp\\util\\array.lisp " (written 19 DEC 2007 11:19:17 AM): ; compiling (IN-PACKAGE :REDICK) ; compiling (DEFUN NOUN-RANK ...) ; compiling (DEFUN NOUN-SHAPE ...) ; compiling (DEFUN SET-ARRAY! ...) ; compiling (DEFUN PRODUCT-SCAN ...) ; compiling (DEFUN PRODUCT-SCAN_ ...) ; compiling (DEFUN ARRAY->VECTOR ...) ; compiling (DEFUN ARRAY-SPLIT ...) ; compiling (DEFUN ARRAY-JOIN ...) ; file: C:\cygwin\home\W049945\prg\redick\lisp\util\array.lisp ; in: DEFUN ARRAY-JOIN ; (LET* ((REDICK::CURRENT-DIMENSIONS (ARRAY-DIMENSIONS REDICK::A)) ; (REDICK::ZEROES ; (MAKE-SEQUENCE 'LIST (LENGTH REDICK::CURRENT-DIMENSIONS) ; :INITIAL-ELEMENT 0)) ; (REDICK::INNER-DIMENSIONS ; (ARRAY-DIMENSIONS (APPLY #'AREF REDICK::A REDICK::ZEROES))) ; (REDICK::TARGET-DIMENSIONS ; (APPEND REDICK::CURRENT-DIMENSIONS REDICK::INNER-DIMENSIONS)) ; (REDICK::TARGET-ARRAY (MAKE-ARRAY REDICK::TARGET-DIMENSIONS)) ; (REDICK::TARGET-ARRAY-INDICES ; (REDICK::X-PROD (MAPCAR #'REDICK::IOTA REDICK::TARGET-DIMENSIONS))) ; (REDICK::SPLIT-POINT (LENGTH REDICK::CURRENT-DIMENSIONS)) ; (REDICK::TMP ; (FORMAT T "array-join: ~A~%" REDICK::TARGET-ARRAY-INDICES))) ; (PROGN ; (LOOP REDICK::FOR REDICK::TAI REDICK::IN REDICK::TARGET-ARRAY-INDICES ; REDICK::FOR (REDICK::OUTER-I REDICK::INNER-I) = ; (MULTIPLE-VALUE-LIST ; (REDICK::SEQUENCE-PARTITION REDICK::TAI REDICK::SPLIT-POINT)) ; DO ; (LET* (# #) ; (SETF # REDICK::INNER-VAL))) ; REDICK::TARGET-ARRAY)) ; ; caught STYLE-WARNING: ; The variable TMP is defined but never used. ; C:\cygwin\home\W049945\prg\redick\lisp\util\array.fasl written ; compilation finished in 0:00:00 WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {B454D21}> on #<CL-SOURCE-FILE "array" {B477C81}>. debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR: The name "SB-INTROSPECT" does not designate any package. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<LOAD-OP NIL {B477C91}> on #<CL-SOURCE-FILE "fns" {B477CD1}>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL {B477C91}> on #<CL-SOURCE-FILE "fns" {B477CD1}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-INT:%FIND-PACKAGE-OR-LOSE "SB-INTROSPECT") 0] ; -- Terrence Brannon - SID W049945 614-213-2475 (office) 614-213-3426 (fax) 818-359-0893 (cell) ----------------------------------------- This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. |
From: Juho S. <js...@ik...> - 2007-12-18 13:39:07
|
"Alex Mizrahi" <ale...@gm...> writes: > helo > > SBCL 1.0.12 crashes on Linux x86_64 (CentOS 5, 2.6.18-8.el5) with > messages like this: > > ----- > debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD > "iolib worker 0" {1003C2A511}>: > Unhandled memory fault at #x0. > ----- > Final object pointer 0x2aacb0e6dde0, start 0x2aaab0e62000, end 0x2aaab0e62570 > fatal error encountered in SBCL pid 19749(tid 46912611776816): > GC invariant lost, file "gc-common.c", line 197 > ----- > > it happens on a multithreaded web server using UCW and iolib. > > what would be suggestions on debugging this error? The GC invariant lost message is basically telling that some memory corruption has happened, and the GC was the first one to notice it. It's hard to debug that after the fact. A backtrace will basically be useless, since it won't tell you anything about which piece of memory was corrupted, let alone what corrupted it. The iolib message is also somewhat suggestive of either memory corruption having happened, or memory corruption just happening. So figuring out what is going on there might be a good first step. So compile your application and libraries with a higher debug level, get a backtrace (or even better, a slime debugger), and see what exactly is referencing the null pointer. Then figure out why it's doing so :-) Also, to ensure that everything is being compiled at maximum safety, you could remove all fasls, (sb-ext:restrict-compiler-policy 'safety 3) and then recompile. This would help if the memory corruption is caused by Lisp code, e.g. some (safety 0) code doing an out of bounds array write, but not if it's something done by foreign code. > also i suspect there are less chanced crashing when only one thread is > used, is that correct? Having just one thread would reduce the chance of some kinds of errors (e.g. the GC moving an array that a foreign function has a pointer to). -- Juho Snellman |
From: Alex M. <ale...@gm...> - 2007-12-17 15:11:25
|
helo SBCL 1.0.12 crashes on Linux x86_64 (CentOS 5, 2.6.18-8.el5) with messages like this: ----- debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD "iolib worker 0" {1003C2A511}>: Unhandled memory fault at #x0. ----- Final object pointer 0x2aacb0e6dde0, start 0x2aaab0e62000, end 0x2aaab0e62570 fatal error encountered in SBCL pid 19749(tid 46912611776816): GC invariant lost, file "gc-common.c", line 197 ----- it happens on a multithreaded web server using UCW and iolib. what would be suggestions on debugging this error? i guess i should build SBCL with debug info and check core dump with gdb next time it crashes, are there chances i'll see somethign useful with it, given kind of error? also i suspect there are less chanced crashing when only one thread is used, is that correct? with best regards, Alex 'killer_storm' Mizrahi. |
From: Nikodemus S. <nik...@ra...> - 2007-12-12 18:05:40
|
T24gRGVjIDEyLCAyMDA3IDU6MDggUE0sIE1hcmMgSGFsYnLDvGdnZSA8bWFyYy5oYWxicnVlZ2dl QHVuaWJ3LmRlPiB3cm90ZToKCj4gc2JjbCBzZWVtcyBub3QgdG8gd29yayBvbiBhbiBJdGFuaXVt MiAodmFyaWluZyBlcnJvciBtZXNzYWdlcyBsaWtlCj4gIm1lbW9yeSBmYXVsdCIgb3IgInZhbHVl IGlzIG5vdCBvZiB0eXBlIFNCLUtFUk5FTDpDVFlQRSIpLgo+Cj4gQ2FuIGFueWJvZHkgc3VnZ2Vz dCBhbiBhbHRlcm5hdGl2ZSBMaXNwIHZlcnNpb24/IE9yIHN1Y2NlZGVkIGluIHJ1bm5pbmcKPiBz YmNsIG9uIExpbnV4L0l0YW5pdW0/CgpUaGVyZSBpcyBubyBJdGFuaXVtIHBvcnQgb2YgU0JDTCwg c28gaXQgbmVlZHMgdG8gYmUgcnVubmluZyBpbiB4ODYgZW11bGF0aW9uCm1vZGUgLS0gc2V0dGlu ZyB3aGljaCBpcyBwcmVzdW1hYmx5IHRoZSB0YXNrIG9mIHlvdXIgb3BlcmF0aW5nIHN5c3RlbS4K CldoYXQgZG9lcyB1bmFtZSAtYSBzYXk/IFdoZXJlIGRpZCB5b3Ugb2J0YWluIFNCQ0w/IFdoYXQg YXJlIHlvdSBkb2luZyB0aGF0CnByb3Zva2VzIHRoZXNlIGVycm9ycyAoanVzdCBzdGFydGluZyBT QkNMLCBvciBkbyB5b3UgYWN0dWFsbHkgaGF2ZSB0bwpydW4gc29tZSBjb2RlIHRvIHNlZSB0aGlz PykgV2hhdCBTQkNMIHZlcnNpb24gYXJlIHlvdSB1c2luZz8gQ2FuIHlvdSBnZXQKYSBiYWNrdHJh Y2U/CgpDaGVlcnMsCgogLS0gTmlrb2RlbXVzCg== |
From: <mar...@un...> - 2007-12-12 17:12:16
|
Hi everybody, sbcl seems not to work on an Itanium2 (variing error messages like "memory fault" or "value is not of type SB-KERNEL:CTYPE"). Can anybody suggest an alternative Lisp version? Or succeded in running sbcl on Linux/Itanium? Greetings Marc |
From: Terrence B. <met...@gm...> - 2007-12-11 23:22:23
|
On Dec 11, 2007 1:44 AM, Rudi Schlatte <ru...@co...> wrote: > sbcl on windows is not a cygwin-native program, and no amount of > pretending on your part will make it one :) lol |
From: Vodonosov A. <avo...@ya...> - 2007-12-11 16:38:23
|
Thank you for help. > On Dec 11, 2007 3:27 PM, Vodonosov Anton <avo...@ya...> wrote: > > > known bugs causing memory faults should be fixed in HEAD -- so it > > > > > would be interesting > > > > > to know which SBCL version you are using. > > > > Not the recent, SBCL 1.0 > Unless you have a pressing reason to use 1.0, I would recommend updating. > > Could you give some hints how to track down the pleace in the web > > server that causes most of consing? (I'm aware about profilers > > described in the manual and even tried statistical profiler, but > > may be you have some interesting advices?) > Use eg. the statistical profiler as described in the manual. > Cheers, > -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2007-12-11 16:19:54
|
On Dec 11, 2007 3:27 PM, Vodonosov Anton <avo...@ya...> wrote: > > known bugs causing memory faults should be fixed in HEAD -- so it > > > would be interesting > > > to know which SBCL version you are using. > > Not the recent, SBCL 1.0 Unless you have a pressing reason to use 1.0, I would recommend updating. > Could you give some hints how to track down the pleace in the web > server that causes most of consing? (I'm aware about profilers > described in the manual and even tried statistical profiler, but > may be you have some interesting advices?) Use eg. the statistical profiler as described in the manual. Cheers, -- Nikodemus |
From: Vodonosov A. <avo...@ya...> - 2007-12-11 15:34:56
|
> known bugs causing memory faults should be fixed in HEAD -- so it > would be interesting > to know which SBCL version you are using. Not the recent, SBCL 1.0 > > Maybe there is a way to speedup garbage collector or to tune > > sbcl to use less memory? (not generate debug information, etc.) > SPACE 3, DEBUG 0 -- but I doubt it'll get you far. Bottom line is that > current SBCL is not > really designed to run in 64Mb of memory. If you don't mind swapping > you can always try > increasing the virtual memory size... Could you give some hints how to track down the pleace in the web server that causes most of consing? (I'm aware about profilers described in the manual and even tried statistical profiler, but may be you have some interesting advices?) |
From: Nikodemus S. <nik...@ra...> - 2007-12-11 15:11:07
|
On Dec 11, 2007 2:19 PM, Vodonosov Anton <avo...@ya...> wrote: > debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR in thread #<THREAD {B7528C1}>: > > memory fault Possible causes: * SIGSEGV in foreign code. * Foreign code scribbling over the lisp heap causing lisp to try to access a location outside the heap. * Type-errors + SAFETY 0, TRULY-THE, or (> SPEED SAFETY). * Compiler bugs. A few of these have been seen during the last half a year or so, and all known bugs causing memory faults should be fixed in HEAD -- so it would be interesting to know which SBCL version you are using. > Maybe there is a way to speedup garbage collector or to tune > sbcl to use less memory? (not generate debug information, etc.) SPACE 3, DEBUG 0 -- but I doubt it'll get you far. Bottom line is that current SBCL is not really designed to run in 64Mb of memory. If you don't mind swapping you can always try increasing the virtual memory size... Cheers, -- Nikodemus |
From: Vodonosov A. <avo...@ya...> - 2007-12-11 14:44:35
|
> Thank you for reply, Nicodemus. Nikodemus. |
From: Vodonosov A. <avo...@ya...> - 2007-12-11 14:39:29
|
Hi. Thank you for reply, Nicodemus. > On Dec 11, 2007 1:22 AM, Anton Vodonosov <avo...@ya...> wrote: > > But after several "ab -n 100 -c 10 MY_URL" > > sbcl and whole system are very-very slow > > (because of wild swapping). Some time after > > this linux kills sbcl with message "out of memory". > Each thread gets it's own stack and tls area allocated, > which is probably part of what you are seeing here. I've tried also with thread pool in the web server, in particular configuring the thread pool to have only one thread (note, -c parameter of ApacheBench is the count of threads that is used by ApacheBench, not by web server). Also I've tried to specify some not big value to the --dynamic-space-size sbcl runtime option. With this sbcl signals "dynamic space exhausted" at some point. > > Is it possible to deal with it somehow? > Run less threads, and/or get more memory? 64Mb is tiny -- > esp. when you consider that plain SBCL image is almost 24Mb! Yes, but the work of the web server is not so heavy: read few strings from the socket connection and write some strings + binary array back to the connection. I suppose the problem is that memory is reserved faster than garbage collector have time to release it (even if the memory is already garbage). I've also tried to run (sb-ext:gc :type :full) after every several requests handled by the web server (for example after every 4). In this case sbcl is alive and more stable, but nevertheless it has difficulties: it became slow and web server sometimes drops requests. Also I've observed: debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR in thread #<THREAD {B7528C1}>: memory fault Maybe there is a way to speedup garbage collector or to tune sbcl to use less memory? (not generate debug information, etc.) Thanks, -Anton |
From: Nikodemus S. <nik...@ra...> - 2007-12-11 12:02:37
|
On Dec 11, 2007 1:22 AM, Anton Vodonosov <avo...@ya...> wrote: > But after several "ab -n 100 -c 10 MY_URL" > sbcl and whole system are very-very slow > (because of wild swapping). Some time after > this linux kills sbcl with message "out of memory". Each thread gets it's own stack and tls area allocated, which is probably part of what you are seeing here. > Is it possible to deal with it somehow? Run less threads, and/or get more memory? 64Mb is tiny -- esp. when you consider that plain SBCL image is almost 24Mb! Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2007-12-11 11:20:24
|
On Dec 11, 2007 3:37 AM, Haroldo Stenger <har...@gm...> wrote: > Should I care ? You are unlikely to have a seriously broken system -- just one that doesn't always backtrace as well as it should. Thanks for reporting. Anyone who can reproduce this, and can do a bit of bisection to locate the commit that introduces this -- doing that would be appreciated. Cheers, -- Nikodemus Siivola |
From: Rudi S. <ru...@co...> - 2007-12-11 06:45:11
|
On 11.12.2007, at 12:53, Terrence Brannon wrote: > On Dec 10, 2007 9:59 PM, Terrence Brannon <met...@gm...> wrote: >> >> Ok, now I would like to install the Cygwin version of SBCL-1.0.12. >> >> So I followed the instructions for installing a binary distribution >> and typed: >> >> INSTALL_ROOT=/usr/local sh install.sh >> >> Now, the problem is, the core file is not found unless I refer to it >> from within the /usr/local/lib/sbcl directory: > > I got some help from Alastair. > > export SBCL_HOME=`cygpath -w /usr/local/lib/sbcl/` > > gets it working. Why not just make a Windows installer via make-windows-installer.sh? sbcl on windows is not a cygwin-native program, and no amount of pretending on your part will make it one :) Granted, the message at the end of the compile should mention the non-windowsness of install.sh. Rudi |
From: Terrence B. <met...@gm...> - 2007-12-11 04:53:33
|
On Dec 10, 2007 9:59 PM, Terrence Brannon <met...@gm...> wrote: > On Dec 1, 2007 8:09 PM, Rudi Schlatte <ru...@co...> wrote: > > > > On 02.12.2007, at 08:52, Terrence Brannon wrote: > > > > > On Dec 1, 2007 7:42 PM, Rudi Schlatte <ru...@co...> wrote: > > >> > > >> cygwin's gcc, make &c, along with sbcl itself, can be used to build > > >> sbcl on windows. > > > > > > what command-line would I type to try this build? would I run the > > > command-line under the Windows command shell or a cygwin shell? > > > > The build is done within the cygwin shell. Make sure sbcl is in the > > path, then cd to the top-level source directory and type "sh > > make.sh". > > Ok, now I would like to install the Cygwin version of SBCL-1.0.12. > > So I followed the instructions for installing a binary distribution and typed: > > INSTALL_ROOT=/usr/local sh install.sh > > Now, the problem is, the core file is not found unless I refer to it > from within the /usr/local/lib/sbcl directory: I got some help from Alastair. export SBCL_HOME=`cygpath -w /usr/local/lib/sbcl/` gets it working. |
From: Haroldo S. <har...@gm...> - 2007-12-11 03:37:12
|
Hi dear lispers. I am compiling SBCL from source (sbcl-1.0.12) in Ubuntu 7.10, haroldo@ombu:~$ uname -a Linux ombu 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux haroldo@ombu:~$ The SBCL compiling finished fine. Then, I ran the regression test suite. Since there appeared : "Finished running tests. Status: Failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) 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" then I ran the tests again, with the --break-on-failure command line option. The debugger popped up when the first non-expected error appeared. At the end of the attached output, what seems to be the error appears: [....] ; compilation unit finished ; printed 2 notes ; in: LAMBDA NIL ; (GO #:G3682) ; ; note: deleting unreachable code ; (TAGBODY ; (SB-KERNEL:ASSERT-ERROR '(TYPEP '(YES . "no") '(CONS SYMBOL)) 'NIL NIL)) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 2 notes ; in: LAMBDA NIL ; (GO #:G3684) ; ; note: deleting unreachable code ; (TAGBODY ; (SB-KERNEL:ASSERT-ERROR '(TYPEP '(YES . "no") '(CONS SYMBOL T)) 'NIL NIL)) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 2 notes ; in: LAMBDA NIL ; (GO #:G3686) ; ; note: deleting unreachable code ; (TAGBODY ; (SB-KERNEL:ASSERT-ERROR '(TYPEP '(YES . "no") '(CONS T STRING)) 'NIL NIL)) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 2 notes ; in: LAMBDA NIL ; (GO #:G3688) ; ; note: deleting unreachable code ; (TAGBODY ; (SB-KERNEL:ASSERT-ERROR '(NOT (TYPEP '(YES . "no") '(CONS T NULL))) 'NIL ; NIL)) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 2 notes // Running /home/haroldo/sbcl-1.0.12/tests/condition.impure.lisp STYLE-WARNING: implicitly creating new generic function FROB-COUNTED-CONDITION // Running /home/haroldo/sbcl-1.0.12/tests/deadline.impure.lisp // Running /home/haroldo/sbcl-1.0.12/tests/debug.impure.lisp ; in: LAMBDA NIL ; (SB-INT:NAMED-LAMBDA ZOOP (ZEEP &KEY BEEP) (BLOCK ZOOP BLURP)) ; ==> ; #'(SB-INT:NAMED-LAMBDA ZOOP (ZEEP &KEY BEEP) (BLOCK ZOOP BLURP)) ; ; caught STYLE-WARNING: ; The variable BEEP is defined but never used. ; ; caught STYLE-WARNING: ; The variable ZEEP is defined but never used. ; in: LAMBDA NIL ; (BLOCK ZOOP BLURP) ; ; caught WARNING: ; undefined variable: BLURP ; ; caught WARNING: ; This variable is undefined: ; BLURP ; ; compilation unit finished ; caught 2 WARNING conditions ; caught 2 STYLE-WARNING conditions ; in: LAMBDA NIL ; (SB-INT:NAMED-LAMBDA VERIFY-BACKTRACE ; (TEST-FUNCTION FRAME-SPECS &KEY (ALLOW-STUNTED NIL)) ; (BLOCK VERIFY-BACKTRACE ; (LABELS ((ARGS-EQUAL # ; #)) ; (LET (#) ; (BLOCK OUTER-HANDLER #) ; RESULT)))) ; ==> ; #'(SB-INT:NAMED-LAMBDA VERIFY-BACKTRACE ; (TEST-FUNCTION FRAME-SPECS &KEY (ALLOW-STUNTED NIL)) ; (BLOCK VERIFY-BACKTRACE ; (LABELS ((ARGS-EQUAL # ; #)) ; (LET (#) ; (BLOCK OUTER-HANDLER #) ; RESULT)))) ; ; caught STYLE-WARNING: ; The variable ALLOW-STUNTED is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition ; in: LAMBDA NIL ; (#:UNDEFINED-FUNCTION 42) ; ; caught STYLE-WARNING: ; undefined function: #:UNDEFINED-FUNCTION ; ; caught STYLE-WARNING: ; undefined function: #:UNDEFINED-FUNCTION ; ; caught STYLE-WARNING: ; These functions are undefined: ; #:UNDEFINED-FUNCTION #:UNDEFINED-FUNCTION ; ; compilation unit finished ; caught 3 STYLE-WARNING conditions :MISSING-BACKTRACE (:BACKTRACE-STUNTED NIL) debugger invoked on a SIMPLE-ERROR: The assertion (VERIFY-BACKTRACE (LAMBDA () (TEST #'OPTIMIZED)) (LIST *UNDEFINED-FUNCTION-FRAME* (LIST '(FLET TEST) #'OPTIMIZED))) failed. 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: Retry assertion. 2: [SKIP-FILE] RUN-TESTS::SKIP-FILE 3: Ignore and continue with next --eval option. 4: [ABORT ] Skip rest of --eval options. 5: Skip to toplevel READ/EVAL/PRINT loop. 6: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). (SB-DEBUG::DEBUG-LOOP-FUN) 0] If I type 0, allowing the tests to continue, the "test failed, expected 104 return code, got 1" appears when the suite seems to finish without other failing tests. Should I care ? Best regards. Haroldo. |
From: Terrence B. <met...@gm...> - 2007-12-11 02:59:15
|
On Dec 1, 2007 8:09 PM, Rudi Schlatte <ru...@co...> wrote: > > On 02.12.2007, at 08:52, Terrence Brannon wrote: > > > On Dec 1, 2007 7:42 PM, Rudi Schlatte <ru...@co...> wrote: > >> > >> cygwin's gcc, make &c, along with sbcl itself, can be used to build > >> sbcl on windows. > > > > what command-line would I type to try this build? would I run the > > command-line under the Windows command shell or a cygwin shell? > > The build is done within the cygwin shell. Make sure sbcl is in the > path, then cd to the top-level source directory and type "sh > make.sh". Ok, now I would like to install the Cygwin version of SBCL-1.0.12. So I followed the instructions for installing a binary distribution and typed: INSTALL_ROOT=/usr/local sh install.sh Now, the problem is, the core file is not found unless I refer to it from within the /usr/local/lib/sbcl directory: Administrator@LIFEBOOK ~/mydocs/dl/sbcl-1.0.12 : sbcl fatal error encountered in SBCL pid 3100: can't find core file at /usr/local/lib/sbcl//sbcl.core Administrator@LIFEBOOK ~/mydocs/dl/sbcl-1.0.12 : /usr/local/bin/sbcl --core /usr/local/lib/sbcl/sbcl.core could not open file "/usr/local/lib/sbcl/sbcl.core" Administrator@LIFEBOOK /usr/local/lib/sbcl : ../../bin/sbcl.exe --core sbcl.core This is SBCL 1.0.12, 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. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * The entire install transcript is here: http://paste.lisp.org/display/52262#2 |