freenode/#sbcl - IRC Chatlog
Search
8:11:28
|3b|
myrkraverk: you probably have thread support, but something is broken somewhere, and if you install that build you won't have the sb-concurrency contrib
8:12:39
|3b|
it adds some things like lock-free queues... depends on whether you want to use it, or use something that uses it
8:19:01
|3b|
and can you paste that building-contrib.sb-concurrency file from failed build somewhere if you still have it?
8:31:03
cryptomarauder[m
ok, cause I have a fresh install and loading quicklisp complains about Invalid source registry (:DIRECTORY (NIL "systems/")) (will be skipped)
8:31:40
cryptomarauder[m
that is it's complaining from wtihin ASDF/SOURCE-REGISTRY:INVALID-SOURCE-REGISTRY
8:44:53
|3b|
ACTION thought i'd seen similar error5s from it being set wrong (though i think that was ubuntu or something)
8:47:21
|3b|
next guess would be something configured asdf wrong (or configured it in a way that became wrong after an upgrade or something)... lots of ways to configure asdf though, so not sure easiest way to debug that
8:48:12
cryptomarauder[m
yeah I'm looking at the different debug output from running the top level form again
10:13:19
|3b|
ACTION is confused by that build log :/ it will have to wait for someone more awake to look at it :p
10:16:11
myrkraverk
I tried to build it again, but (of course) get the same error in sb concurrency.
10:16:29
|3b|
myrkraverk: so x8664, old ubuntu, building as root? any options to make.sh? any idea if the system was heavily loaded when the tests were running?
10:17:26
myrkraverk
Test SB-CONCURRENCY-TEST::FRLOCK.1 failed Form: (HANDLER-CASE (WITH-TIMEOUT 10 (SB-CONCURRENCY-TEST::TEST-FRLOCKS)) (TIMEOUT (SB-CONCURRENCY-TEST::C) (ERROR "~A" SB-CONCURRENCY-TEST::C))) Expected values: NIL NIL Actual value: #<SIMPLE-ERROR "~A" {10037F3143}>.
10:29:56
|3b|
only other things i can thing of to try are building as a normal user instead of root, and building current code from git in case whatever it is has been fixed
10:40:38
|3b|
maybe try editing contrib/sb-concurrency/tests/test-frlock.lisp and change *minimum-sleep* from 0.0001 to 0.01 on line 23 or so and build again
10:42:43
|3b|
ACTION wonders if the system has a lower than usual resolution clock... vague memory of that being true of some virtualization setups
10:44:29
myrkraverk
possibly. I'll have to check a little later; I have other things to do right now.
10:46:32
stassats
is it reasonable to not install a contrib just because a test fails? i may change that, has never seemed reasonable to me
10:47:20
|3b|
ACTION would probably pick something in between,like having an easy way to say install it anyway
10:53:46
scymtym
stassats: :bit-position-overrun fails on x86: https://ci.cor-lab.org/job/sbcl-master/featureset=1,label=ubuntu_trusty_32bit/lastCompletedBuild/consoleFull
10:54:46
scymtym
also, can we change bit-vector.impure-cload.lisp to just bit-vector.impure.lisp and then control the compiler noise?
10:56:01
scymtym
i would rather have bit-vector.impure.lisp and use specific policies (or iterate over all policies) for the tests that need it
11:01:04
scymtym
i can't find a justification in the commit logs either. the test file just started like that and stayed that way, it seems
11:02:40
scymtym
ignoring that it conflates multiple issues, the first commit has a reasonable message
11:05:37
stassats
i remember using emacs vcs when sbcl used cvs, so it wasn't all that much different from git
11:39:26
stassats
maybe i could try an azure vm, so that i could work from the laptop, although the latency would probably hurt
11:50:31
stassats
maybe i could use some of that newfangled container technology, so that i don't have to set up after each vm change
12:15:28
myrkraverk
So afaict now, I have 1.4.1 with sb-concurrency (though I don't know how to test it quickly)
12:16:55
stassats
you could simulate its passing with touch obj/asdf-cache/sb-concurrency/test-passed.test-report
12:18:33
scymtym
ACTION suspects the 10 second timeout in the sb-concurrency tests to be responsible for some of the build failures he is seeing as well
12:27:10
scymtym
i'm just saying that some test failures could be avoided by having the test do less work and/or relaxing the timeout
12:28:06
stassats
it takes a minute to build sbcl without contribs here, i wouldn't be pleased for a simple test taking up another minute
12:32:56
stassats
and i can't makes heads or tails with this azure stuff, i can't find a promised cheap vm i could run for 12 months
12:33:29
jdz
Shouldn't it be categorized as a "stress test" and be invoked only manually if the user wants?
12:34:41
scymtym
the duration of successful test runs is not affected by the timeout. it only determines how long it takes to turn a slow or hanging run into a failure
12:37:25
flip214
I believe that recent (~ 2 months?) SBCLs have a false positive regarding "note: deleting unreachable code".
12:39:32
flip214
I had an ITERATE clause (FINALLY (RETURN (make-instance '...))) that was marked as unreachable, but the function returned the right result
12:42:44
flip214
stassats: well, the function only had that single exit point, and returned the right result.
12:45:39
flip214
stassats: which macroexpansion? the first one doing the DEFUN around? the ITERATE clause, once? twice?
12:47:31
flip214
doing that on the DEFUN gives me a listing with only one occurrence of the function call that's being told as "unreachable"
12:51:07
flip214
grrr, simply truncating two FLETs outside the ITERATE makes the note go away already
12:57:58
stassats
sb-concurrency using up all ram on windows, that's what people are saying when theire vms are locking up
12:59:30
flip214
hmmm, right now I even have that note with a split-up version of the loop .... same code given as unreachable
13:17:56
flip214
I guess as soon as you understand the cause you'll be able to produce a much smaller testcase
13:21:14
flip214
still not true, BRANCH comes from a hash-table-lookup and that returns NIL most of the time.