You can subscribe to this list here.
2000 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
|
May
(16) |
Jun
(5) |
Jul
(5) |
Aug
(27) |
Sep
(25) |
Oct
(10) |
Nov
(40) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(78) |
Feb
(80) |
Mar
(35) |
Apr
(73) |
May
(97) |
Jun
(44) |
Jul
(38) |
Aug
(43) |
Sep
(94) |
Oct
(124) |
Nov
(13) |
Dec
(79) |
2002 |
Jan
(144) |
Feb
(68) |
Mar
(128) |
Apr
(117) |
May
(90) |
Jun
(63) |
Jul
(42) |
Aug
(66) |
Sep
(97) |
Oct
(89) |
Nov
(92) |
Dec
(88) |
2003 |
Jan
(101) |
Feb
(127) |
Mar
(103) |
Apr
(145) |
May
(211) |
Jun
(143) |
Jul
(67) |
Aug
(184) |
Sep
(212) |
Oct
(117) |
Nov
(181) |
Dec
(86) |
2004 |
Jan
(92) |
Feb
(95) |
Mar
(163) |
Apr
(242) |
May
(202) |
Jun
(114) |
Jul
(94) |
Aug
(148) |
Sep
(163) |
Oct
(111) |
Nov
(95) |
Dec
(133) |
2005 |
Jan
(148) |
Feb
(102) |
Mar
(213) |
Apr
(178) |
May
(202) |
Jun
(199) |
Jul
(189) |
Aug
(309) |
Sep
(126) |
Oct
(128) |
Nov
(148) |
Dec
(156) |
2006 |
Jan
(222) |
Feb
(184) |
Mar
(152) |
Apr
(176) |
May
(189) |
Jun
(186) |
Jul
(75) |
Aug
(182) |
Sep
(103) |
Oct
(144) |
Nov
(265) |
Dec
(197) |
2007 |
Jan
(175) |
Feb
(202) |
Mar
(212) |
Apr
(309) |
May
(203) |
Jun
(162) |
Jul
(207) |
Aug
(156) |
Sep
(136) |
Oct
(99) |
Nov
(199) |
Dec
(201) |
2008 |
Jan
(190) |
Feb
(201) |
Mar
(180) |
Apr
(132) |
May
(204) |
Jun
(149) |
Jul
(125) |
Aug
(102) |
Sep
(86) |
Oct
(269) |
Nov
(167) |
Dec
(291) |
2009 |
Jan
(155) |
Feb
(119) |
Mar
(174) |
Apr
(186) |
May
(168) |
Jun
(217) |
Jul
(107) |
Aug
(134) |
Sep
(111) |
Oct
(184) |
Nov
(81) |
Dec
(140) |
2010 |
Jan
(91) |
Feb
(93) |
Mar
(132) |
Apr
(137) |
May
(86) |
Jun
(112) |
Jul
(38) |
Aug
(112) |
Sep
(111) |
Oct
(124) |
Nov
(52) |
Dec
(49) |
2011 |
Jan
(72) |
Feb
(115) |
Mar
(91) |
Apr
(38) |
May
(119) |
Jun
(129) |
Jul
(34) |
Aug
(140) |
Sep
(37) |
Oct
(58) |
Nov
(130) |
Dec
(59) |
2012 |
Jan
(20) |
Feb
(9) |
Mar
(41) |
Apr
(89) |
May
(69) |
Jun
(21) |
Jul
(14) |
Aug
(24) |
Sep
(52) |
Oct
(49) |
Nov
(45) |
Dec
(21) |
2013 |
Jan
(36) |
Feb
(53) |
Mar
(50) |
Apr
(142) |
May
(125) |
Jun
(120) |
Jul
(89) |
Aug
(82) |
Sep
(45) |
Oct
(104) |
Nov
(69) |
Dec
(40) |
2014 |
Jan
(28) |
Feb
(85) |
Mar
(99) |
Apr
(108) |
May
(92) |
Jun
(73) |
Jul
(49) |
Aug
(65) |
Sep
(48) |
Oct
(61) |
Nov
(34) |
Dec
(41) |
2015 |
Jan
(84) |
Feb
(46) |
Mar
(81) |
Apr
(83) |
May
(56) |
Jun
(27) |
Jul
(47) |
Aug
(30) |
Sep
(31) |
Oct
(57) |
Nov
(65) |
Dec
(90) |
2016 |
Jan
(52) |
Feb
(71) |
Mar
(76) |
Apr
(37) |
May
(43) |
Jun
(16) |
Jul
(17) |
Aug
(51) |
Sep
(48) |
Oct
(40) |
Nov
(21) |
Dec
(36) |
2017 |
Jan
(40) |
Feb
(57) |
Mar
(47) |
Apr
(45) |
May
(28) |
Jun
(30) |
Jul
(53) |
Aug
(71) |
Sep
(48) |
Oct
(58) |
Nov
(42) |
Dec
(49) |
2018 |
Jan
(94) |
Feb
(50) |
Mar
(59) |
Apr
(56) |
May
(27) |
Jun
(35) |
Jul
(32) |
Aug
(56) |
Sep
(35) |
Oct
(26) |
Nov
(35) |
Dec
(46) |
2019 |
Jan
(36) |
Feb
(53) |
Mar
(53) |
Apr
(37) |
May
(28) |
Jun
(12) |
Jul
(75) |
Aug
(81) |
Sep
(70) |
Oct
(46) |
Nov
(115) |
Dec
(124) |
2020 |
Jan
(65) |
Feb
(95) |
Mar
(289) |
Apr
(106) |
May
(165) |
Jun
(63) |
Jul
(129) |
Aug
(107) |
Sep
(86) |
Oct
(85) |
Nov
(94) |
Dec
(107) |
2021 |
Jan
(67) |
Feb
(103) |
Mar
(131) |
Apr
(98) |
May
(116) |
Jun
(85) |
Jul
(26) |
Aug
(133) |
Sep
(60) |
Oct
(130) |
Nov
(196) |
Dec
(120) |
2022 |
Jan
(155) |
Feb
(107) |
Mar
(123) |
Apr
(232) |
May
(194) |
Jun
(139) |
Jul
(82) |
Aug
(58) |
Sep
(49) |
Oct
(71) |
Nov
(69) |
Dec
(117) |
2023 |
Jan
(142) |
Feb
(64) |
Mar
(114) |
Apr
(34) |
May
(56) |
Jun
(113) |
Jul
(87) |
Aug
(99) |
Sep
(49) |
Oct
(97) |
Nov
(88) |
Dec
(131) |
2024 |
Jan
(158) |
Feb
(106) |
Mar
(181) |
Apr
(63) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nikodemus S. <nik...@ra...> - 2006-08-16 19:09:01
|
Levente Mészáros <lev...@gm...> writes: > ; caught WARNING: > ; Asserted type (MOD 1152921504606846975) conflicts with derived type > ; (VALUES (OR FUNCTION SB-PCL::METHOD-CALL SB-PCL::FAST-METHOD-CALL) > &OPTIONAL). > ; See also: > ; The SBCL Manual, Node "Handling of Types" Fixed in 0.9.15.36, thanks for the report! The overwhelming majority of other similar warnings caused by high DEBUG policies should be fixed too. If you can still get warnings using 0.9.15.36 or later, by pumping up DEBUG, please report! Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Nikodemus S. <nik...@ra...> - 2006-08-16 18:25:24
|
Christophe Rhodes <cs...@ca...> writes: > Nice catch, but I think we can do even slightly better than that. > Consider > (deftype foo () '(satisfies even-and-greater-than-two-p)) > (deftype bar () '(satisfies sum-of-two-primes-p)) > > (type= 'foo 'bar) > should be NIL, NIL (unless someone's proved or disproved Goldbach's > conjecture while I wasn't looking). But > (type= '(cons foo integer) '(cons bar symbol)) > > should be NIL, T, even though there's ambiguity in the CAR. Unfortunately not so, as both FOO and BAR may turn out to be the empty type, in which case the whole CONS type is really the NIL type. Took a while to figure that one out -- not eased by the rather hairy test-case that happened to catch it. ;-) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Nikodemus S. <nik...@ra...> - 2006-08-16 18:17:55
|
Nikodemus Siivola <nik...@ra...> writes: > My CONS type patch broke type.impure.lisp, which I somehow managed to > overlook. Fixed in 0.9.15.35. (Though there is a minor FIXME now left in CONS :SIMPLE-= if someone is motivated to sort it out -- it is now slightly more conservative then it strictly has to be.) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Teemu K. <ch...@s2...> - 2006-08-16 15:40:59
|
Yaroslav Kavenchuk <kav...@je...> writes: > Teemu Kalvas wrote: > > > Index: run-program.c > > =================================================================== > > RCS file: /cvsroot/sbcl/sbcl/src/runtime/run-program.c,v > > retrieving revision 1.12 > > retrieving revision 1.13 > <skip> > > + if ( ( out >= 0 ) && ( out != _fileno ( stdout ) ) ) { > > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return > > (HANDLE)-1; > > + } > > + if ( ( in >= 0 ) && ( in != _fileno ( stdout ) ) ) { > Ups... ^^ ^^ ^^^^^^ (need stdin) > > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return > > (HANDLE)-1; > > + } > > + if ( ( err >= 0 ) && ( err != _fileno ( stdout ) ) ) { > Ups too ^^^ ^^^ ^^^^^^ (need stderr) > > And, maybe, add processing errors? (closing std*_backup handles if they > are initialized and replace the in/out/err handles if they redefined) Whoops. I've got a fixed version on my office computer (which is the only win32 I have for use), and I'll commit it tomorrow. I also reordered the cleanup and close approppriate fds on errors. -- Teemu |
From: Teemu K. <ch...@s2...> - 2006-08-16 15:39:36
|
Yaroslav Kavenchuk <kav...@je...> writes: > run-program not work with non-fd-stream? Only on win32? > > * (with-output-to-string (s) > (run-program "c:/gnu/bin/sh.exe" '("--version") :output s)) > > "" > * > debugger invoked on a SIMPLE-ERROR: > #<SB-IMPL::STRING-OUTPUT-STREAM {A596F19}> is closed. > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (SB-KERNEL:CLOSED-FLAME #<SB-IMPL::STRING-OUTPUT-STREAM {A596F19}>) > 0] This is actually a known, very old bug, which just is easier to trigger on win32 than on unix. Even on unix if the program writes a lot of output, the pipe will become full, and SBCL and the program will end up in deadlock. On win32, the synchronization required by the pipe is tighter, and the deadlock will happen no matter what the size of the output is. The real fix is somewhat unclear to me. In this case, SBCL could not wait for the program to finish, but start it and then start reading the pipe and feeding the data into the receiving stream. I'm just not sure how to get it right in the general case. Writing into string-streams or having :output :stream works perfectly if you just :wait nil, but then you have to pay attention to synchronization yourself. -- Teemu |
From: Yaroslav K. <kav...@je...> - 2006-08-16 10:37:06
|
> spawnvp() on Windows simply concatenate arguments over space (without > any conversation or processing of arguments). If the string argument > contains #\Space or #\", it argument should be made in #\" (and internal > > #\" -> (#\\ #\")) and so on. > I insert in function "toplevel-init" (print options) Result: * (run-program (first *POSIX-ARGV*) (list "--core" SB-INT:*CORE-STRING* "--noinform" "--no-sysinit" "--no-userinit" "--eval" "(sb-ext:quit :unix-status 104)") :output t) os_map: 8, 0x1000, 02000000, 0x1000. os_map: 8, 0x2000, 05000000, 0x1000. os_map: 8, 0x3000, 09000000, 0x1558000. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" ("--no-sysinit" "--no-userinit" "--eval" "(sb-ext:quit" ":unix-status" "104)") debugger invoked on a SIMPLE-ERROR: ... * (run-program (first *POSIX-ARGV*) (list "--core" SB-INT:*CORE-STRING* "--noinform" "--no-sysinit" "--no-userinit" "--eval" "\"(sb-ext:quit :unix-status 104)\"") :output t) os_map: 8, 0x1000, 02000000, 0x1000. os_map: 8, 0x2000, 05000000, 0x1000. os_map: 8, 0x3000, 09000000, 0x1558000. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" ("--no-sysinit" "--no-userinit" "--eval" "(sb-ext:quit :unix-status 104)") #<SB-IMPL::PROCESS :EXITED 104> And small experiment: * (run-program (first *POSIX-ARGV*) (list "--core" SB-INT:*CORE-STRING* "--noinform" "--no-sysinit" "--no-userinit" "--eval \"(sb-ext:quit :unix-status 104)\"") :output t) os_map: 8, 0x1000, 02000000, 0x1000. os_map: 8, 0x2000, 05000000, 0x1000. os_map: 8, 0x3000, 09000000, 0x1558000. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" ("--no-sysinit" "--no-userinit" "--eval" "(sb-ext:quit :unix-status 104)") #<SB-IMPL::PROCESS :EXITED 104> Please, help me - apply my patch or any other decision of the given problem. Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Sidney M. <si...@si...> - 2006-08-16 04:09:12
|
Sidney Markowitz wrote, On 16/8/06 2:37 PM: > But trying to do something like > > (setf *proc* (run-program "/bin/echo" '("bar") :output :stream) > > and then using read-char-no-hang on the output slot of *proc* the way the test > in run-program.impure.lisp does it does not work. That means that the bug does > not depend on how run-program.impure.lisp constructs the two-way stream. Correction: I tried to put together a self-contained test more carefully, and realised I had made a mistake. The following correctly evaluates to #\f on both Mac OS and Ubuntu Linux: (let* ((proc (run-program "/bin/echo" '("foo") :output :stream :wait nil)) (out (slot-value proc 'sb-impl::output))) (sleep 0.2) (read-char-no-hang out)) However without the (sleep 0.2) it evaluates to nil on Mac OS and to #\f on Ubuntu Linux. Since tests/run-program.impure.lisp does have a (sleep 0.2) in it, this does not narrow the problem down enough after all. Sidney Markowitz http://www.sidey.com |
From: Sidney M. <si...@si...> - 2006-08-16 02:37:10
|
Sidney Markowitz wrote, On 15/8/06 4:57 PM: > Testing on a MacBook (Intel dual core processor) running Mac OS 10.4.7, the > run-program.impure.lisp test fails in sbcl version 14 and the latest cvs > version with the error: > > Unhandled SIMPLE-ERROR: wanted "4" from ed, got "" Narrowing the problem down some more, this works: (with-open-file (out "footest.tmp" :direction :output :if-exists :supersede) (run-program "/bin/echo" '("bar") :output out)) But trying to do something like (setf *proc* (run-program "/bin/echo" '("bar") :output :stream) and then using read-char-no-hang on the output slot of *proc* the way the test in run-program.impure.lisp does it does not work. That means that the bug does not depend on how run-program.impure.lisp constructs the two-way stream. Can someone try this on a BSD system? I've noticed that sometimes a bug like this that shows up in MacOS X may also appear in real BSDs. Sidney Markowitz http://www.sidney.com |
From: Sidney M. <si...@si...> - 2006-08-15 15:08:09
|
A little more experimenting with tests/run-program.impure.lisp under Mac OS 10.4.7 on an Intel MacBook: I changed the run-program form to (defvar *ed* (run-program "/bin/ed" (list *tmpfile*) :input *in* :output t :wait nil)) and simulated the rest of the test with the output going directly to the console instead of having to be read from the *out* stream. That worked ok, so the input half of the stream works with pipe, but not the output half. - Sidney Markowitz http://www.sidney.com |
From: Nikodemus S. <nik...@ra...> - 2006-08-15 14:53:08
|
My CONS type patch broke type.impure.lisp, which I somehow managed to overlook. Fix coming up. Sorry for the bother, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Christophe R. <cs...@ca...> - 2006-08-15 11:25:49
|
Nikodemus Siivola <de...@us...> writes: > (!define-type-method (cons :simple-=) (type1 type2) > (declare (type cons-type type1 type2)) > - (and (type= (cons-type-car-type type1) (cons-type-car-type type2)) > - (type= (cons-type-cdr-type type1) (cons-type-cdr-type type2)))) > + (multiple-value-bind (match win) > + (type= (cons-type-car-type type1) (cons-type-car-type type2)) > + (if (and match win) > + (type= (cons-type-cdr-type type1) (cons-type-cdr-type type2)) > + (values nil win)))) Nice catch, but I think we can do even slightly better than that. Consider (deftype foo () '(satisfies even-and-greater-than-two-p)) (deftype bar () '(satisfies sum-of-two-primes-p)) (type= 'foo 'bar) should be NIL, NIL (unless someone's proved or disproved Goldbach's conjecture while I wasn't looking). But (type= '(cons foo integer) '(cons bar symbol)) should be NIL, T, even though there's ambiguity in the CAR. Cheers, Christophe |
From: Yaroslav K. <kav...@je...> - 2006-08-15 10:23:23
|
run-program not work with non-fd-stream? Only on win32? * (with-output-to-string (s) (run-program "c:/gnu/bin/sh.exe" '("--version") :output s)) "" * debugger invoked on a SIMPLE-ERROR: #<SB-IMPL::STRING-OUTPUT-STREAM {A596F19}> is closed. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:CLOSED-FLAME #<SB-IMPL::STRING-OUTPUT-STREAM {A596F19}>) 0] Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-08-15 09:12:44
|
Nikodemus Siivola wrote: > Christophe Rhodes <cs...@ca...> writes: > >> What kind of quoting are we talking about here? What is the issue at >> hand? > > In terms of Yaroslavs's patch going from \\\\ to \\, I believe, > but I didn't look too hard. > > Interms of quoting & escaping characters in pathnames, I find No, problem not in #\\. Problem in #\" and #\Space inside argument. spawnvp() on Windows simply concatenate arguments over space (without any conversation or processing of arguments). If the string argument contains #\Space or #\", it argument should be made in #\" (and internal #\" -> (#\\ #\")) and so on. Now does not work: (run-program "sbcl" '("--core" "sbcl.core" "--eval" "(quit :unix-status 104)")) Need: (run-program "sbcl" '("--core" "sbcl.core" "--eval" "\"(quit :unix-status 104)\"")) My offer: --- sbcl/src/code/run-program.lisp 10 Jun 2006 01:00:58 -0000 +++ sbcl/src/code/run-program.lisp 13 Aug 2006 21:42:08 -0000 @@ -812,7 +812,15 @@ proc ;; It's friendly to allow the caller to pass any string ;; designator, but internally we'd like SIMPLE-STRINGs. - (simple-args (mapcar (lambda (x) (coerce x 'simple-string)) args))) + (simple-args + (mapcar + (lambda (x) + (coerce + (if (position-if (lambda (c) (find c '(#\" #\Space))) x) + (write-to-string x) + x) + 'simple-string)) + args))) (unwind-protect (let ((pfile (if search or something similar Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-08-15 07:51:08
|
Teemu Kalvas wrote: > Index: run-program.c > =================================================================== > RCS file: /cvsroot/sbcl/sbcl/src/runtime/run-program.c,v > retrieving revision 1.12 > retrieving revision 1.13 <skip> > + if ( ( out >= 0 ) && ( out != _fileno ( stdout ) ) ) { > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return > (HANDLE)-1; > + } > + if ( ( in >= 0 ) && ( in != _fileno ( stdout ) ) ) { Ups... ^^ ^^ ^^^^^^ (need stdin) > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return > (HANDLE)-1; > + } > + if ( ( err >= 0 ) && ( err != _fileno ( stdout ) ) ) { Ups too ^^^ ^^^ ^^^^^^ (need stderr) And, maybe, add processing errors? (closing std*_backup handles if they are initialized and replace the in/out/err handles if they redefined) Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Sidney M. <si...@si...> - 2006-08-15 04:57:59
|
Testing on a MacBook (Intel dual core processor) running Mac OS 10.4.7, the run-program.impure.lisp test fails in sbcl version 14 and the latest cvs version with the error: Unhandled SIMPLE-ERROR: wanted "4" from ed, got "" sbcl version 13 passes, but version 14 contains a change to run-program and adds the test that is failing to run-program.impure.lisp. Calling run-program with :output t does work ok. Trying the same thing in a current Ubuntu linux on the same MacBook works fine. -- Sidney Markowitz http://www.sidney.com |
From: <me...@ho...> - 2006-08-14 22:39:09
|
Two patches are attached. The patch in ht-pre.diff contains indentation changes to target-hash-table.lisp to make the lines fit into a 80 char wide emacs and a small refactoring of hash table related code in gencgc. Namely, of the x86/x86-64 version of scav_vector a function called scav_hash_table_entries is split off in preparation for the next patch and some repetitive code is factored out, too. The second patch (wht.diff, requires the first) implements weak hash tables on x86/x86-64 platforms. Supported weakness types are :KEY, :VALUE, :KEY-AND-VALUE and :KEY-OR-VALUE. The implementation is based on cmucl's weak hash table code. Summary: * scav_vector defers scavenging of weak hash tables until ... * ... newspace scavenging at which time the deferred weak hash tables are scavenged according to their WEAKNESS type (this happens after each scan of newspace) * finally just before weak pointers are scanned (i.e. with the purpose of breaking them) the weak hash tables are scanned (i.e. the appropriate entries are removed) too. Tests are not included because I find it exceedingly difficult to construct reliable test cases with a conservative gc. There are a number of outstanding issues, too. Since I am likely to have limited hacking time for some days to come here it is anyway. Cheers, Gabor TODO: * somewhat meaningful tests * make the rest of the gencgc platforms use the same hash table code as x86 does. GENGC on PPC being non-conservative this could help a lot with the testing. * implement it on cheneygc platforms * verify that in practice it is possible to trigger the O(W^2+N) worst case as Bruno claims (see http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-writeup.html) * speed it up by implementing the 3rd variant in the paper (should be a relatively local change) |
From: Thiemo S. <th...@ne...> - 2006-08-14 21:09:00
|
Juho Snellman wrote: [snip] > I don't really like the stable/development split. It's going to > discourage people from upgrading their SBCL more often, while we want > to do the opposite. > > One of the great things about monthly time-boxed releases is that > regressions are found pretty quickly, since many users will regularly > upgrade to the latest release. Branding them as development releases > will mean that some of those users will instead stay with the stable > release. Likewise we'll probably get a fair amount of stale bug > reports (for bugs fixed in 1.1.*) from people still using 1.0. > > My preference would be for something like: > > * 1.0.1 released one month later, no guarantees over source / binary > compatibility with 1.0. But we encourage people releasing > non-portable internals-using software to maintain > backwards-compability with 1.0 at least until the release of 1.1, > expected to happen about a year later. > > For example, if we make changes in 1.0.5 which also require changes to > Slime, the usual backwards-compability code in Slime will be marked as > "Don't delete before SBCL 1.1 release". FWIW, this sounds like a reasonable compromise between stability and further development to me. Thiemo |
From: Juho S. <js...@ik...> - 2006-08-14 17:59:12
|
Nikodemus Siivola <nik...@ra...> writes: > Christophe Rhodes <cs...@ca...> writes: > > > * 1.1.0 released one month later, no guarantees over source / binary > > compatibility with 1.0; a branch for 1.0 maintenance set up for > > those who want to support 1.0 with bugfixes; > > I think I would prefer this, plus possibly a Linux style "even > minor-versions are stable", kind of thing. > > That way the normally merry development could continue pretty much as > now, and the next "significant" release would be something less > intimidating then 2.0... I don't really like the stable/development split. It's going to discourage people from upgrading their SBCL more often, while we want to do the opposite. One of the great things about monthly time-boxed releases is that regressions are found pretty quickly, since many users will regularly upgrade to the latest release. Branding them as development releases will mean that some of those users will instead stay with the stable release. Likewise we'll probably get a fair amount of stale bug reports (for bugs fixed in 1.1.*) from people still using 1.0. My preference would be for something like: * 1.0.1 released one month later, no guarantees over source / binary compatibility with 1.0. But we encourage people releasing non-portable internals-using software to maintain backwards-compability with 1.0 at least until the release of 1.1, expected to happen about a year later. For example, if we make changes in 1.0.5 which also require changes to Slime, the usual backwards-compability code in Slime will be marked as "Don't delete before SBCL 1.1 release". > > ? Put another way, what does 1.0 actually mean? (Does it mean that > > we have to document all the bits we have lazily not been documenting? > > What about bits we don't want to document because they're not > > finished?) > > Rename all internal package SB%FOO instead of SB-FOO, so it is "obvious" > they are internal, and move unfinished stuff away from SB-EXT? This seems rather pointless. People who need to use internals will do so, regardless of how the package is named, so I don't really see much of a benefit. It'd also be an incredibly disruptive change, breaking any software that refers to the SBCL internals in any way. Which is more than you might think, for example Araneida, clx, cl-sql, kmrcl, McCLIM, and Slime. Which isn't to say that we should completely freeze the internals. But I'd prefer to only break things when the internals really change, not on a whim. -- Juho Snellman |
From: Nikodemus S. <nik...@ra...> - 2006-08-14 17:06:12
|
Christophe Rhodes <cs...@ca...> writes: > * 1.1.0 released one month later, no guarantees over source / binary > compatibility with 1.0; a branch for 1.0 maintenance set up for > those who want to support 1.0 with bugfixes; I think I would prefer this, plus possibly a Linux style "even minor-versions are stable", kind of thing. That way the normally merry development could continue pretty much as now, and the next "significant" release would be something less intimidating then 2.0... > ? Put another way, what does 1.0 actually mean? (Does it mean that > we have to document all the bits we have lazily not been documenting? > What about bits we don't want to document because they're not > finished?) Rename all internal package SB%FOO instead of SB-FOO, so it is "obvious" they are internal, and move unfinished stuff away from SB-EXT? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Christophe R. <cs...@ca...> - 2006-08-14 15:56:33
|
William Harold Newman <wil...@ai...> writes: > Thinking about binary incompatibilities (another day, another > increment to +FASL-FILE-VERSION+) my thoughts naturally turn to > version numbers... Whoops, yes, sorry. I might make that happen some more this month if I can get round some more PCL nastinesses. > Would it be appropriate to pick an arbitrary month, probably late in > this year, and plan to call its ordinary late-in-the-month release > version 1.0? I nominate October or November. (December 25th would be a > cute choice but probably not the most practical, since people tend to > be distracted by travel and whatnot.) I'm generally positive about this. (This actually matches the vague handwavy time I mentioned to people 18 months ago, so clearly I have not only telepathic debugging skills but also working precognition...) What I would like to see before agreeing completely is a vague consensus about what happens after 1.0. Is it * 1.0.1 released one month later, no guarantees over source / binary compatibility with 1.0; or * 1.0.1 released several months later, no guarantees over source / binary compatibility with 1.0; or * 1.1.0 released one month later, no guarantees over source / binary compatibility with 1.0; a branch for 1.0 maintenance set up for those who want to support 1.0 with bugfixes; or * something else ? Put another way, what does 1.0 actually mean? (Does it mean that we have to document all the bits we have lazily not been documenting? What about bits we don't want to document because they're not finished?) This sounds more Angsty than it should. As I say, I'm generally positive, really... :-) Cheers, Christophe |
From: Nikodemus S. <nik...@ra...> - 2006-08-14 15:29:48
|
William Harold Newman <wil...@ai...> writes: > Would it be appropriate to pick an arbitrary month, probably late in > this year, and plan to call its ordinary late-in-the-month release > version 1.0? I nominate October or November. (December 25th would be a > cute choice but probably not the most practical, since people tend to > be distracted by travel and whatnot.) Sounds good to me. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: William H. N. <wil...@ai...> - 2006-08-14 13:24:39
|
Thinking about binary incompatibilities (another day, another increment to +FASL-FILE-VERSION+) my thoughts naturally turn to version numbers... We seem to be short of dramatic excuses for version 1.0, in part because you all are too good at slipstreaming harmless little changes (such as unicode, threading, mswindows support, or the fopcompiler) into minor releases without messing up stability for those of us still contentedly using the old features. However, approaching 0.9.20 is starting to look like a good enough excuse to me. Would it be appropriate to pick an arbitrary month, probably late in this year, and plan to call its ordinary late-in-the-month release version 1.0? I nominate October or November. (December 25th would be a cute choice but probably not the most practical, since people tend to be distracted by travel and whatnot.) -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Mike T. <mi...@pa...> - 2006-08-13 21:53:28
|
> Many thanks! And especially you Yaroslav! Mike Thomas. |
From: Yaroslav K. <kav...@tu...> - 2006-08-13 21:40:21
|
If change part of your patch for src/runtime/run-program.c from > + if ( out >= 0 ) { > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return (HANDLE)-1; > + } > + if ( in >= 0 ) { > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return (HANDLE)-1; > + } > + if ( err >= 0 ) { > + if ( _dup2 ( err, _fileno ( stderr ) ) != 0 ) return (HANDLE)-1; > + } to > + if ( ( out >= 0 ) && ( out != _fileno ( stdout ) ) ) { > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return (HANDLE)-1; > + } > + if ( ( in >= 0 ) && ( in != _fileno ( stdin ) ) ) { > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return (HANDLE)-1; > + } > + if ( ( err >= 0 ) && ( err != _fileno ( stderr ) ) ) { > + if ( _dup2 ( err, _fileno ( stderr ) ) != 0 ) return (HANDLE)-1; > + } All works! Many thanks! -- WBR, Yaroslav Kavenchuk. |
From: <bdo...@la...> - 2006-08-13 05:48:53
|
On Sat, Aug 12, 2006 at 03:48:16PM +0200, karol skocik wrote: > Hi guys, > I am confused from behaviour of this piece of code: > > (let ((real-time (get-internal-real-time))) > (sleep 0.01) > (loop :for new-real-time = (get-internal-real-time) > :repeat 1000000000 > :do (if (> real-time new-real-time) > (error "!!!!!!!!!! real-time = ~a, new-real-time = ~a~%" real-time > new-real-time) > (setf real-time new-real-time)))) > > If I understand correctly, new-real-time should be always greater or > equal than time measured in executing previous iteration of loop. > However, this is not true. I often get error which looks like this : > > !!!!!!!!!! real-time = 1276670, new-real-time = 1276669 I haven't been able to reproduce this in about twenty minutes of runtime on my system. Looking at the implementation of GET-INTERNAL-REAL-TIME, though, its output is a pretty trivial computation from the results of gettimeofday(2). At first guess I'd say something is stepping the clock on your system backward to keep in time sync with something else. What I don't understand, however, is that both ntpdate and ntpd itself (on Linux, which I see you are running) will slowly slew the clock (effectively "changing the speed" of time) if the offset isn't above a certain threshold, to keep time always going in the right direction. (See the adjtime(2) and adjtimex(2) man pages.) I don't know of anything that would be stepping the clock backwards by about one millisecond intervals. You can try running this C program and see if you see similar behavior: #include <stdlib.h> #include <stdio.h> #include <sys/time.h> #include <time.h> int main() { struct timeval last, cur; gettimeofday(&last, NULL); for (;;) { gettimeofday(&cur, NULL); if ((cur.tv_sec < last.tv_sec) || ((cur.tv_sec == last.tv_sec) && (cur.tv_usec < last.tv_usec))) { printf("Time went backwards! last = %d.%06d cur = %d.%06d\n", last.tv_sec, last.tv_usec, cur.tv_sec, cur.tv_usec); } last = cur; } return 0; } -bcd -- *** Brian Downing <bdowning at lavos dot net> |