freenode/#sbcl - IRC Chatlog
Search
12:57:05
Lycurgus
is it a misperception that sbcl doesn't seem to converge to a more bug free state ?
13:03:23
scymtym
i don't know about ccl, let alone acl, but SBCL certainly is not bug free and has not been bug free at any point
13:04:41
Lycurgus
well I've built a number of older code sets lately, so gotten deeper into x-implementation experience
13:07:00
Lycurgus
also my question was about process, convergence, I don't expect any conventionally produced software to be entirely bug free
13:07:27
pkhuong
pfdietz's automated tester does a pretty good job at finding increasingly subtle issues
13:08:45
pkhuong
you also get a lot of port-specific churn with very young ports like power. does it mean that the x86 ports are currently buggier?
13:10:10
jackdaniel
fixes only prove that software is better tested, not that it has more issues. test suites running across multiple implementations could give some comparison (given that tests discover interested edge cases)
13:12:44
Lycurgus
i suppose I will just have to give up the idea of a single implementation used for all cl sources
13:13:49
Lycurgus
ACTION has zero inclination to maintain an implementation, i.e. below the cl level
13:14:40
Lycurgus
and based on experience with other code sets, I fear ACL will be least problematic
13:15:46
Lycurgus
and I'm pretty sure but will confirm that sbcl is snag rich, as it has been in the others
13:16:00
scymtym
one thing that has converged (and improved, imho) in SBCL is regression testing. we run automated tests and bug fixes mostly have corresponding regression tests
13:16:49
Lycurgus
i don't want to go into the matter of CCL statement on generic functions outside of CLOS
13:18:22
jackdaniel
yes, ccl is a very complete implementation standard-wise (and beyond that of course)
13:19:08
jackdaniel
Lycurgus: I'm confused, given you track sbcl's progress since fork from cmucl it is hard to believe you don't know that clos (and generic functions) are part of the standard
15:32:46
dkny
scymtym: my verify-freelist patch isn't valid for synchronized tables because the lock is already release by the verify step. So my hash-table.impure failure is just noise
15:35:24
scymtym
dkny: i didn't have time to look into the issue further, but i don't think the hash-table in clx is synchronized
15:36:48
scymtym
dkny: i had one more idea that i couldn't try yet: i could encapsulate the hash-table functions to find all static call sites and calling threads. may that reveals a usage error clx
15:37:02
dkny
right. But I was concerned about the invariant failure in hash-table impure, until I realized that the verified itself was not valid
15:53:35
dkny
if the synchronization is external to gethash/puthash/remhash such as in 'with-display', it would be ok
15:54:59
dkny
moving the verify inside the lock fixed all the failures in hash-table.impure, so I'm once again convinced that the invariant is correct
16:06:56
scymtym
i'll continue to look for failures and usage errors in clx, but the reproduction probability is very low and i don't have a lot of time at the moment