00:14:31 christoph_debian, no idea if it's the case on debian, but some distros use an additional release number to distinguish between different builds (e.g. the packager might enable/disable a feature, link against a different version of a dependency, or apply patches before building, in which case such changes would be represented by incrementing the release number) 00:16:59 Thra11: we have a -$something for that ;-) 00:17:40 my guess is that debian build traditionally adding a .debian at the end of the version to distinguish it from vanilla sbcl and it had a .0. bewenn that to allow for vcs snapshots 00:17:58 while still maintaining monotone version numbering 00:18:52 I made it 1 1.1.2 for now and dropped the .0 00:19:53 debian packages cvs snapshots!? I thought debian was the distro where everything had to be stable and/or prehistoric. (I've not used debian myself) 00:20:42 everything's at the maintainer's discretion 00:21:02 and sbcl seems to have had bugfixes for releases in subsequent cvs versions around 0.9.0 00:21:05 in 2005 01:23:09 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 276 seconds] 03:28:46 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 252 seconds] 03:40:54 -!- Thra11 [~thrall@29.192.125.91.dyn.plus.net] has quit [Ping timeout: 240 seconds] 04:07:26 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Remote host closed the connection] 04:08:25 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 04:14:19 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Remote host closed the connection] 04:14:40 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 04:20:14 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 240 seconds] 04:31:48 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 04:37:20 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Remote host closed the connection] 04:40:27 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 05:07:51 stassats [~stassats@wikipedia/stassats] has joined #sbcl 05:19:27 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:20:03 seems that i can't build sbcl with debug 3, complains about recursive definitions of known functions 06:20:19 or maybe it's because of speed 0 06:22:51 or of compilation-speed 0 06:28:33 no, it just can't be built with speed less than 2 06:29:06 or just speed less than safety 06:36:50 well, debug 3 build works ok, but it goes bonkers when i insert a break into ir1-convert-lambda 07:22:25 and debug 3 build produces lots of test failures, chiefly concerned with debugging, unsurprisingly 07:48:20 -!- Bike [~Glossina@207-224-23-226.ptld.qwest.net] has quit [Ping timeout: 255 seconds] 07:53:31 sdemarre [~serge@91.176.115.80] has joined #sbcl 08:04:07 if we're wishing: I'd like a sbcl that could be built with coverage information 08:04:24 (pcl currently can't be, because of the walking stuff in make-method-lambda) 08:08:00 *stassats* is annoyed by the uneasiness of removing BREAK from the compiler internals 08:08:08 i'll break my "c" key at that rate 08:39:09 edgar-rft [~GOD@HSI-KBW-091-089-000-047.hsi2.kabelbw.de] has joined #sbcl 08:43:14 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 255 seconds] 08:54:35 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 09:11:13 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 10:08:47 Hi, when building the sbcl 1.1.2 for openSUSE in the build system for the distro sometimes the testin of sb-concurrency fails "Test SB-CONCURRENCY-TEST::FRLOCK.1 failed" 10:10:06 This happens randomly, meaning in another build it will succeed but the next time it may fail again for x86 or x86_64 or both . Any ideas what is going on 10:10:13 you might want to paste the details to the mailing list or the bug-tracker 10:10:46 Ok will post to the bug-tracker 10:22:29 Ok filed the bug see https://bugs.launchpad.net/sbcl/+bug/1087955 10:26:30 madanyang: is it a low-end or very busy system? 10:27:36 stassats: They are kvm instances running on the opensuse build system 10:27:56 can you add that to the bug description? 10:28:17 stassats: will do 10:28:24 the kvm bit in particular 10:29:50 <_8david> madanyang: does it fail with the timeout or with something else? Can you bump up the timeout a little to make certain that it's not just being slow? 10:30:09 <_8david> (the timeout is in place because the test would otherwise fail by hanging on windows) 10:30:41 _8david: from the description, it looks like a timeout 10:30:48 but 60 seconds seems quite generous 10:31:13 but, on a busy system with virtual machines, quite possible it's not enough 10:32:43 <_8david> well, and if it's hanging exactly like on Windows (CPU idle), one might be excused for beginning to think about the possibility that maybe it isn't just failing due to a Windows threading bug after all 10:33:23 <_8david> So, someone go and fix it on Windows first, then see if that helps for madanyang. :-) 10:33:30 stassats: Can't seem to add a comment to the bug but more info about buildsystem http://openbuildservice.org/ 10:33:51 you can edit the bug description 10:34:25 _8david: Expected values: NIL Actual value: #. 10:38:17 stassats: Guess not my day when I edit the bug and try to save there is an error message popping up :( 10:44:24 ok, paste what you want to add and i'll add it 10:50:04 stassats:" The builds are on KVM instances and for each build the kvm is reinitiliazed doing just that package build they are isolated with no services running. " 10:51:47 ok, done 10:54:32 stassats: Thanks. I have increased the time out from 60 to 120 and issued a rebuild .Will report the outcome 11:00:24 wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has joined #sbcl 11:17:53 so you know, if you just want to rebuild the contributed modules (including their tests) you don't need to do a full rebuild 11:25:55 superjudge [~mjl@c83-250-198-227.bredband.comhem.se] has joined #sbcl 11:35:54 Krysof: That would be true if it was a local machine, but this is a build farm hosted at opensuse servers where there is no login access 11:42:13 <_8david> BTW, if it's about getting an rpm done, you could just patch the test to be marked as an expected failure. 11:42:40 <_8david> Or even just touch test-passed to allow installation. 11:46:25 _8david: while it is true that the rpm should build is the ultimate goal, aren't the tests supposed to be showing if the code works as it it designed to be. I think as the package maintainer I have to be sure that it will work for the end user else I will be the first to be assingned for the opensuse bug 11:46:57 <_8david> yes, but the test and the feature being tested are very new 11:48:58 _8david: so if I disable the test and for some reason there is a bug related to the sb:concurrency in the openSUSE packages you will provide the solution asap ;) 11:50:47 according to launchpad, there're 540 bugs of some sort in SBCL 11:51:01 so, one more shouldn't make you too unhappy 12:02:12 so for 10 distributions each with i586 and x86_64 builds hence total of builds 20 : with time out 120 only 5 fails . Options used --with-sb-xref-for-internals --with-sb-core-compression using sbcl 1.1.1 build on opensuse servers 12:02:15 Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has joined #sbcl 12:04:55 <_8david> hmm. I'm still wondering whether you're idle, or just busy on a slow system. 12:05:07 <_8david> Can you wrap a TIME form around this test stuff and send the output? 12:06:44 -!- sdemarre [~serge@91.176.115.80] has quit [Ping timeout: 248 seconds] 12:52:23 Thra11 [~thrall@29.192.125.91.dyn.plus.net] has joined #sbcl 12:57:52 _8david: do you mean (time (deftest* bla bla)) 13:01:43 <_8david> not quite; I think (deftest* (...) (time (handler-case ...)) ...) would be right. 13:21:37 sdemarre [~serge@91.176.115.80] has joined #sbcl 13:32:50 _8david: ok rebuilding but I don't think that would help as on each build I will be scheduled to a different machine Nevertheless I added the relevant part to https://bugs.launchpad.net/sbcl/+bug/1087955 13:34:02 ARG-COUNT-ERROR? that doesn't seem right 13:37:05 did you wrap the two last nils into time? 13:37:38 implying that you shouldn't 13:52:31 *stassats* is perplexed by the ir-tranforms, the result seemingly depends on the order at which source-forms appear 13:53:01 (values #'x (x 1)) produces significantly different code from (values (x 1) #'x) 13:53:22 when x is inlined 13:55:02 -!- Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 13:55:31 definetely not my day :( 13:55:54 madanyang: so, did you fix the TIME form? 13:58:24 stassats: yes , hopefully correct this time waiting for the builds 14:27:53 ok this time only 3 builds failed and I have updated https://bugs.launchpad.net/sbcl/+bug/1087955 14:28:42 <_8david> "not idle" then 14:29:25 <_8david> so my timeout simply doesn't take slow hosts into account 14:30:27 <_8david> Still, I wouldn't want to just increase the timeout, because we have so many of those silly test cases already that run or hang as long as a whole test suite in some other file. It's a little annoying during development to waste minutes on doing nothing. 14:30:48 <_8david> ... or, you know, someone could just fix windows threading so that the test passes. 14:31:03 add something like bogomips? 14:31:53 <_8david> So. Probably #+win32 WITH-TIMEOUT #-win32 PROGN is the best workaround for now, but I'm not in SBCL development mode this weekend. 14:32:16 still won't help with spikes of activity on non-idle systems 14:33:46 <_8david> why not? If those systems are #-win32, they won't have a timeout any more. And if they are #+win32, there are bigger problems than non-idleness. 14:34:08 i was conversing with myself 14:34:15 <_8david> And it's still better than the alternative, which is #+win32 (error "failing test explicitly, because it would hang"). 14:35:03 <_8david> stassats: oh :-) 14:35:13 <_8david> Yeah, no, if you're looking for a "clever" solution, I think one could impose a timeout on (max 0 (- real-time run-time)) instead of real-time as such. 14:36:15 but it still might hang due to a bug, so removing timeouts isn't that good 14:36:29 -!- wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has quit [Quit: Client Quit] 14:38:30 _8david: but that supposedly won't work on virtual machines 14:39:13 from the paste, it seems to use 400% of cpu alright 14:40:11 <_8david> that's the point. My form will constantly yield 0 and not exceed any timeout. As it should on this host. 14:40:32 but what if it's a bug and it will hang? 14:41:48 <_8david> depends on whether we're discussion theory or reality. In reality, when this test fails, it doesn't busyloop, it hangs idle. At least that's what my timeout is protecting against. 14:41:54 LiamH [~none@96.231.227.13] has joined #sbcl 14:41:58 on another failure it is 199.75% CPU and 121.915620 seconds of total run time (21.209326 user, 100.706294 system) 14:42:48 _8david: besides, i don't know how to make such a time-out 14:42:48 _8david: suboptimal for refactorings like our switch to spinlocks, but that's a minor issue. 14:42:57 <_8david> But if we go on with the discussion like this, it's going to be next week before we've reached a conclusion. 14:43:07 <_8david> By that time, I'll have gotten hold of nikodemus who can explain frlocks to me. So. 14:43:30 http://en.wikipedia.org/wiki/Seqlock <- frlock. 14:43:48 <_8david> Let's go back to fixing the issue, not papering over the test. :-) 14:43:49 for now, the only affected people are on busy virtual machines, so, let them deal with it by removing time-outs 14:45:11 madanyang: is it a relatively old kvm? Might this be a known performance bug with futexes in KVM? 14:46:24 wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has joined #sbcl 14:47:05 pkhuong: I have no idea as this is the build service for openSUSE and some builds are done using XEN so I never know which build host the package for that release will end up 15:07:14 -!- sdemarre [~serge@91.176.115.80] has quit [Ping timeout: 240 seconds] 15:47:31 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 15:50:41 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:11:40 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 16:16:15 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 16:26:05 sdemarre [~serge@91.176.115.80] has joined #sbcl 17:20:39 -!- wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has quit [Quit: none] 17:25:29 Thra11_ [~thrall@87.114.43.202] has joined #sbcl 17:26:25 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 17:27:56 -!- Thra11 [~thrall@29.192.125.91.dyn.plus.net] has quit [Ping timeout: 255 seconds] 17:39:35 -!- sdemarre [~serge@91.176.115.80] has quit [Ping timeout: 240 seconds] 17:55:34 -!- Thra11_ [~thrall@87.114.43.202] has quit [Ping timeout: 240 seconds] 17:57:48 sdemarre [~serge@91.176.115.80] has joined #sbcl 18:10:33 Thra11_ [~thrall@87.114.43.202] has joined #sbcl 18:11:59 -!- LiamH [~none@96.231.227.13] has quit [Quit: Leaving.] 18:17:15 -!- sdemarre [~serge@91.176.115.80] has quit [Ping timeout: 240 seconds] 18:20:15 wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has joined #sbcl 18:24:51 slyrus [~chatzilla@adsl-99-190-98-53.dsl.pltn13.sbcglobal.net] has joined #sbcl 18:38:06 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 18:50:14 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 250 seconds] 18:57:21 Krystof: R's graphing libraries are the worst -- except for all the others I've tried 18:57:56 thanks for swankr though, or this whole exercise would be even more of a nightmare! 20:06:23 wow, a satisfied user 20:06:32 clearly my business plan is now validated 20:21:18 -!- slyrus [~chatzilla@adsl-99-190-98-53.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 276 seconds] 20:22:06 pjb [~t@92.103.75.130] has joined #sbcl 20:22:26 simkoc [~smuxi@88-134-28-142-dynip.superkabel.de] has joined #sbcl 20:25:01 is there a way to adapt sb-profile:profile to figure out how much additional memory is used after a certain functioncall during execution time? 20:26:38 slyrus [~chatzilla@adsl-99-190-98-53.dsl.pltn13.sbcglobal.net] has joined #sbcl 20:33:22 Also, for what you want, I think you'd have to call the garbage collector before and after the call. 20:40:52 i know, i am currently trying to minimize the problem and using room after calling the gc 20:41:17 but as my problem is contained in quite a system i am not sure if i am able to find the right spot 20:41:27 therefore some kind of automatism would be quite handy 20:41:44 there's an allocation profiler in sb-sprof 20:41:51 that might help, at least 20:48:19 that one is way too verbose, is there no macro that outputs the difference of memory usage after the execution of the body? 20:53:03 no 22:12:51 -!- superjudge [~mjl@c83-250-198-227.bredband.comhem.se] has quit [Ping timeout: 252 seconds] 22:23:13 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 22:25:00 is there a nice function name for rounding away from zero? prolong, for the symmetry with truncate? (: 22:25:12 Oh, let's ask #lisp. 22:39:32 sdemarre [~serge@91.176.115.80] has joined #sbcl 22:55:23 -!- wbooze [~wbooze@xdsl-84-44-178-52.netcologne.de] has quit [Ping timeout: 252 seconds] 23:03:47 prxq [~mommer@mnhm-5f75ed8b.pool.mediaWays.net] has joined #sbcl 23:18:14 -!- sdemarre [~serge@91.176.115.80] has quit [Ping timeout: 240 seconds] 23:22:07 LiamH [~none@96.231.227.13] has joined #sbcl 23:26:34 Bike [~Glossina@207-224-23-226.ptld.qwest.net] has joined #sbcl 23:33:13 -!- edgar-rft [~GOD@HSI-KBW-091-089-000-047.hsi2.kabelbw.de] has quit [Quit: game over] 23:38:19 Krystof: aroudn? 23:38:22 around even... 23:41:04 -!- prxq [~mommer@mnhm-5f75ed8b.pool.mediaWays.net] has quit [Quit: Leaving] 23:44:36 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl