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}

_{Dec}

S  M  T  W  T  F  S 



1

2

3

4

5

6
(1) 
7

8

9
(1) 
10

11

12

13

14

15

16

17

18

19

20
(1) 
21

22

23
(1) 
24
(1) 
25

26

27

28

29

30

31



From: Nikodemus Siivola <nikodemus@ra...>  20110324 06:07:41

Lutz Euler is the man  even though he's not subscribed, he used his powers to telepathically read the mail and figured out what's going on! Cheers,  Nikodemus  Forwarded message  From: Lutz Euler <lutz.euler@...> Date: 24 March 2011 01:49 Subject: Re: sbcl1.0.45 and maxima5.23.1 testsuite To: Nikodemus Siivola <nikodemus@...>, "Andrey G. Grozin" <A.G.Grozin@...> Cc: sbclhelp@... Nikodemus wrote: > On 17 January 2011 18:15, Andrey G. Grozin <A.G.Grozin@...> wrote: > >> Now there is a new testsuite failure with sbcl. It's rtest16, problem 385. >> It's about floatingpoint calculation of zeta(%i+3) (%i is the imaginary >> unit). sbcl produced a resulr with error of order 3*10^(9) instead of >> expected 10^(15). Earlier versions of sbcl did not have this failure. >> Looks like a regression. All the other lisps listed above also don't have >> this particular failure (ecl has 2 failures in rtest8, this is another >> story). Looks like something is calculated in single precision when it >> should be done in double. > > Do you recall what's the latest version in which that test passed? (It > fails with 1.0.44 as well.) > > Alternatively, if a Maxima wizard can reduce a testcase that doesn't > involve Maxima  just shows an SBCL operation that returns the wrong > value  what would help too. I am not a maxima wizard but I believe I have found the cause of the problem: SBCL's "expt" with integer or rational base and complex doublefloat exponent uses an intermediate singlefloat value for its calculations thus, while yielding a complex doublefloat result as required, this result is exact only to singlefloat precision. This behaviour is the same already in SBCL 0.8.12, which is the oldest version I happen to have available readily compiled. The details: Maxima's calculation of the zeta function with the argument of the test case is done using the lisp function "floatzeta", defined in maxima5.23.1/src/combin.lisp. The formula contains a sum of several terms each containing a quotient of something by "expt" of a small integer and the argument to the zeta function, the latter converted to complex doublefloat. These "expt"s are calculated directly using SBCL's "expt". Here is a trace: Maxima 5.23.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.46.42 (%i1) to_lisp(); Type (tomaxima) to restart, ($quit) to quit Maxima. MAXIMA> (trace expt) (EXPT) MAXIMA> (floatzeta #$(3+%i)$) 0: (EXPT 4 3.0) 0: EXPT returned 64.0 0: (EXPT 2 #C(2.0 1.0)) 0: EXPT returned #C(0.19230972430417587 0.15974031883619208) 0: (EXPT #C(7.2421875 1.0) #C(1.25 0.5)) 0: EXPT returned #C(4.418528303829868 10.318276280305101) 0: (EXPT 1 #C(3.0 1.0)) 0: EXPT returned #C(1.0 0.0) 0: (EXPT 1 0) 0: EXPT returned 1 0: (EXPT 1 0) 0: EXPT returned 1 0: (EXPT 21 #C(3.0 1.0)) 0: EXPT returned #C(9217.405235813078 897.5555997887233) 0: (EXPT 2 #C(3.0 1.0)) 0: EXPT returned #C(6.1539112363389945 5.11169025143816) ... ... [many more calls to (expt <small int> #C(3.0 1.0))] ... #C(1.1072144060921958 0.14829086482826961) The test case expects the following result: #C(1.10721440843141  0.1482908671781754) As a simple reduced test case without maxima we have: (expt 2 #C(3.0d0 1.0d0)) SBCL gives: #C(6.1539112363389945d0 5.11169025143816d0) Clisp (2.48) gives: #C(6.153911210911777d0 5.111690210509078d0) and Clisp with more precision (setf (system::longfloatdigits) 500): (expt 2 #C(3.0l0 1.0l0)) #C(6.15391121091177701262663994929016561152716795929571082535897...l0 5.11169021050907840920026329171761427405784430264463783596469...l0) The definition of "expt" is in sbcl/src/code/irrat.lisp. (defun expt (base power) ... (numberdispatch ((base number) (power number)) ... (((foreach fixnum (or bignum ratio) singlefloat doublefloat) complex) (if (and (zerop base) (plusp (realpart power))) (* base power) (exp (* power (log base))))) ...)) The calculation of (log base), base being an integer, yields a singlefloat as required by the standard. For the purpose of "expt" it may be a bug to use (log base) as the standard says in section 12.1.4.1 "Rule of Float and Rational Contagion": "When rationals and floats are combined by a numerical function, the rational is first converted to a float of the same format." For a quick test I replaced the calculation in the SBCL source as follows, (exp (* power (log (coerce base 'doublefloat)))) then compiled SBCL and maxima. This SBCL calculates: * (expt 2 #C(3.0d0 1.0d0)) #C(6.153911210911775d0 5.111690210509077d0) This seems to differ from Clisp's result only in the last bit of the real and imaginary part each. The zeta value calculated by maxima is then: (%i1) zeta (3 + %i), numer=true; (%o1) 1.107214408431409  .1482908671781753 %i The resulting maxima passes its test suite with no unexpected errors. In case it matters, the above is under x8664, except when using SBCL 0.8.12, which is x86. If "expt" indeed needs to be modified a correct fix seems a bit more complicated as currently there are two clauses dealing with complex exponents, both not distinguishing between single and double floats. The standard seems to require to look at all argument types and to use singlefloat calculations if all arguments are integer or rational or singlefloat, be it real or complex, and to use doublefloat calculations if at least one argument is doublefloat real or complex? Also, the current implementation of "expt" allows (with a complex exponent) bignums or ratios as the base that are too big or too small to be represented as a singlefloat, provided their logarithm can (and the exponent is such that the result fits in its type). If one doesn't want to lose this property, a function for log of ratios and integers returning a doublefloat would need to be defined. This may be easy as "log" already contains the needed logic, only unfortunately always coercing the result to singlefloat. On the other hand I believe the standard does not require this, so hopefully nobody depends on this accidental property. And, when the exponent is real, bignum/ratio bases too large and too small don't work anyway, currently. On the third hand, as "log" (intentionally, seemingly) deals with bignums and ratios that don't fit in a float, maybe "expt" should, too, even in the case of a real exponent? Moreover, "log" is implemented the way it is to be more exact in the case that its argument is a ratio very near to one. This carries over to "expt": The original SBCL calculates: * (expt (/ (expt 2 64) (1+ (expt 2 64))) #c(10 10)) #C(1.0 5.421011e19) whereas with the above hack we have the less exact #C(1.0d0 0.0d0) (Sorry, can't resist: Did you notice that "log" returns zero for rational arguments very near to one if the integer length of numerator and denominator differs by one? (log (/ (expt 2 64) (1 (expt 2 64)))) > 0.0 whereas (log (/ (1+ (expt 2 64)) (expt 2 64))) > 5.421011e20 which result would be correct for the former ratio, too.) Greetings Lutz 
From: Nikodemus Siivola <nikodemus@ra...>  20110323 18:42:48

On 17 January 2011 18:15, Andrey G. Grozin <A.G.Grozin@...> wrote: > Now there is a new testsuite failure with sbcl. It's rtest16, problem 385. > It's about floatingpoint calculation of zeta(%i+3) (%i is the imaginary > unit). sbcl produced a resulr with error of order 3*10^(9) instead of > expected 10^(15). Earlier versions of sbcl did not have this failure. > Looks like a regression. All the other lisps listed above also don't have > this particular failure (ecl has 2 failures in rtest8, this is another > story). Looks like something is calculated in single precision when it > should be done in double. Do you recall what's the latest version in which that test passed? (It fails with 1.0.44 as well.) Alternatively, if a Maxima wizard can reduce a testcase that doesn't involve Maxima  just shows an SBCL operation that returns the wrong value  what would help too. Cheers,  Nikodemus 
From: ach ach <christophamort@gm...>  20110320 21:46:07

I've tried to install sbcl 1.0.43 and 46 on a windows virtual server NT 6.1 amd quad core 64 and get this error message from the os: *Problem signature:* Problem Event Name: APPCRASH Application Name: sbcl.exe Application Version: 0.0.0.0 Application Timestamp: 4ca43314 Fault Module Name: StackHash_89b3 Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Code: c0000005 Exception Offset: 223bba75 OS Version: 6.1.7600.2.0.0.272.7 Locale ID: 1033 Additional Information 1: 89b3 Additional Information 2: 89b3e92533427e2da3556602c709d3fa Additional Information 3: 3b40 Additional Information 4: 3b4018f626b47e5d7fd8567544ccd6a3 ... sbcl crashes (freezes) after printing its normal 'welcome' message. The Exception Code: c0000005 normaly stands for a memory Access Violation, I don't belive that is true in this case. Any suggestions welcome, Christoph ps.: It is interesting that the multithreaded release sbcl1.0.45.XIII.252 from Anton Kovalenko works fine. 
From: Didier Verna <didier@lr...>  20110309 16:30:45

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31  April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.europeanlispsymposium.org/ Sponsors: EPITA, TUHH, Lispworks, Franz Inc., NovaSparks and Freiheit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ News: ~~~~~ * The final program is now online. * The early registration deadline is in 3 days, so hurry! Registration will still be possible afterwards. Invited Speakers: ~~~~~~~~~~~~~~~~~ Craig Zilles  Compiling for the common case Marc Battyani  Reconfigurable computing on steroids Apostolos Syropoulos  Scala: an OO surprise Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna  EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller  Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao  Instituto Superior Tecnico/INESCID, Portugal Christophe Rhodes  Goldsmiths College, University of London, UK David Edgar Liebke  Relevance Inc., USA Didier Verna  EPITA Research and Development Laboratory, France Henry Lieberman  MIT Media Laboratory, USA Jay McCarthy  Brigham Young University, USA Jose Luis Ruiz Reina  Universidad de Sevilla, Spain Marco Antoniotti  Universita Milano Bicocca, Italy Manuel Serrano  INRIA, France Michael Sperber  DeinProgramm, Germany Pascal Costanza  Vrije Universiteit of Brussel, Belgium Scott McKay  ITA Software, USA  Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com 
From: james anderson <james.anderson@se...>  20110306 12:45:35

On 20110227, at 12:39 , Nikodemus Siivola wrote: > On 27 February 2011 11:12, james anderson <james.anderson@...> > wrote: > >> i have noticed that a longrunning sbcl accumulates "unreferenced" >> dynamic objects. > [ ... ] > ...this actually isn't obvious at all. What does (SETF LITERAL > LANGUAGETAG do? > > Also, (sbext:gc) usually only runs the nursery collection. To force a > complete collection, you need to do (sbext:gc :full t). yes, a full gc reduces the accumulation significantly. what is the standard approach to altering the frequency/criteria for full collections? can one include the decision logic and a call to (gc :full t) in a postgc hook? is it better to record the intent and defer the gc call to some other timed task? would the deferred call be with or without gc off/on wrapping? in general, where does one find discussion of this issue in the documentation? thanks; 