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