freenode/#sbcl - IRC Chatlog
Search
14:30:25
_death
interesting because recently I wrote some defstruct heavy code (and got to know new pitfalls.. e.g., slots without initializers (that sbcl &aux commit... yikes), or a slot named P without predicate option...) and didn't encounter this
14:42:30
Bike
oh yeah, think we hit that building sbcl with clasp. some destruct assuming a nil default
14:45:18
Bike
and yeah, it's different from ordinary lambda lists, because defstrut is kind of bizarre
14:45:50
_death
right.. that's what I mean.. the standard says it's undefined (as well as slots without initforms).. that's why I consider it a quality of implementation issue
14:48:50
_death
I had to go through some of my code (not yet all..) and fix the defstruct slot specs
14:56:36
_death
stassats: I mean in my subjective model of the language as I understand it.. since it's one more unnecessary twist I would've preferred to see a CDR document specifying NIL values, but obviously not everyone agrees
14:58:01
_death
stassats: I had (defstruct foo bar zot) and expected (foo-bar (make-foo)) to return NIL
14:59:01
_death
that's only by accident.. I also expected &aux to initialize to NIL, and it's not, so I've no guarantee that my code will work in the future
15:00:24
_death
that's why I would've been more comfortable with a CDR document specifying this behavior and implementators affirming compliance to it
15:13:00
_death
stassats: I had BOA constructors with &aux, but luckily they all initialized the slot (otherwise, there's not much point in &aux :).. I guess that's why I've not noticed this
15:30:59
_death
if &aux is almost never used that way, why is it important that &aux foo has the foo slot unbound or set to 0
15:47:59
_death
I understand it's more efficient to do nothing, but it's also more surprising.. and if it rarely happens, is the concern about efficiency justified?
20:05:24
karlosz
does sbcl spin up multiple threads during warm compilation when its compile fileing?
20:05:54
karlosz
i see no evidence that it does yet on sb-thread i seem to be getting non deterministic crashes during warm init
20:13:19
karlosz
okay, i see that a new thread is spun up on GC on #+sb-thread to finalize instead of running on its own
21:30:08
karlosz
okay, im pretty certain my alloc-tls-index assembly routine and CAS vops are correct
21:35:06
karlosz
some other times it gives a type error saying some IR1 object like ctran or block is not of type layout