tfb
2017-8-19 13:05:33

@pnwamk Thanks for the pointers. I’d already built myself a datatype macro whose surface syntax looks pretty much exactly like your define-datatype; I’m interested to check out your type-case. Giving the type explicitly isn’t really a problem, but I’m curious if it would be possible to determine the type of the first form, since Typed Racket should know it (although maybe at the wrong time?).


leif
2017-8-19 13:53:06

Yup, that’s exactly what I’m talking about. :slightly_smiling_face:


leif
2017-8-20 00:41:40

@mflatt I want to double check with you as the docs aren’t 100% clear. When I allocate a cstruct using its make-<id> allocator, the result is still tracked by the GC, yes?


mflatt
2017-8-20 00:41:51

yes


leif
2017-8-20 00:42:16

Okay. So it is then not safe to hand a pointer to it to a C function that then takes ownership of it?


mflatt
2017-8-20 00:42:38

Correct.


leif
2017-8-20 00:42:56

In which case it looks like the only way to make one is to: A. call malloc explicitly in raw mode, and manually set the fields.


leif
2017-8-20 00:43:02

Okay cool, thanks you.


mflatt
2017-8-20 00:43:32

You can supply an alternative malloc mode with #:malloc-mode if you always want to allocate as, say, 'raw


mflatt
2017-8-20 00:43:52

Otherwise, yes, use malloc, etc..


leif
2017-8-20 00:44:00

okay cool, that makes sense.


leif
2017-8-20 00:44:02

Thank you


leif
2017-8-20 00:50:00

@mflatt Also, I presume list->cblock allocates the block with atomic?


mflatt
2017-8-20 00:53:51

That one does seem inadequately documented. I see that the implementation uses malloc with the given type, so that’s not always atomic.


leif
2017-8-20 00:56:25

Interesting, okay.


leif
2017-8-20 00:56:31

Thank you


leif
2017-8-20 01:02:06

@mflatt Its more that I wanted to hand it off to a c function.


leif
2017-8-20 01:02:29

But it looks like I’ll have to keep a copy around on the Racket side until I know its safe to free it.