@florence you’re the relevant person for the pict test timeouts on drdr, right?

Is there anything I can do to help you debug those (such as access to the drdr machine)?

Is there a possibility to implement generic interfaces after one has defined a struct. Ok, since this is Lisp anything is possible … but is there a well defined way (maybe documented even?)

Sofar all examples first define the interface and then implement that interface while defining the struct. I know it must be possible as @lexi.lambda must have done something with the generic/collections

@robkuz it’s possible but not with normal structs, you’ll have to add an indirection later on top of them that supports it. And it probably wouldn’t work with normal struct properties

@robkuz racket/generic doesn’t really allow that. I wrote a multimethod package that allows that sort of thing, but it’s pretty half-baked.

@robkuz: You can, by adding a #:defaults clause when defining the interface.

@stamourv …but then it’s an O(n) predicate lookup instead of a hash lookup. :(

Yes, but I’d expect n to be pretty small in most cases. And it would be a struct type property lookup otherwise, which I don’t think involves hashing.

oh, right. that’s even better—I would hope struct properties are constant time.

@stamourv @lexi.lambda pretty sure it’s a hash table

As in, struct type properties are stored in a hash table?

https://github.com/racket/racket/blob/master/racket/src/racket/src/struct.c#L1122

Ah, look at that. Didn’t expect that.

totally out of curiosity, what did you expect it to be?

Alist?

The number of properties a struct type has would typically be small, I’d imagine.

what’s a good way to make a struct safe for users to use without breaking if you add more fields while still allowing them to define subtypes of the struct?

I’m okay with field name overlap between sub and supertypes breaking clients, I just don’t want adding any field at all to break them

that’s a great question that i’m interested in, too

there’s some really funky stuff when you want to use #:super around struct copy and such

it comes up a lot and it’s the thing that frustrates me most about structs

@samth I can reproduce the timeouts locally (on my linux desktop only), but the stacktraces are not really helpful, and im not sure how to proceed. It’s somehow related to: the JIT, unsafe-fl operations, and futures.

The test case is a small one, involving just the blur function, (which uses unsafe-fl and futures)

its hard to minimize further b/c inlining the blur function and modifying it in seemingly any way decreases the probability that the program will freeze

@florence For that sort of thing, rr is very nice because you can just run the program repeatedly until failure, and then debug the failed one

it also will likely go away with the upcoming chez rewrite so its been fairly low priority.

I never got rr to work, but the programs actually just locked up so I was able to attach gdb. It tends to get stuck in seeming arbitrary functions who’s names suggest they have to do with allocation iirc.

I could also just disable the pict tests that call jack-o-lantern and blur for now to make drdr shut up, since the bug is ages old anyways

@samth ^

what didn’t work on rr?

also just disabling those tests would be good since that would reduce the hang-rate on drdr

There wasn’t something prebuilt for my platform and I never got building from source working I think? Idr its been like a year since ive looked at this.

I’ll update the issue and disable the tests when I get home.