)))
(grpc-slice p))
(define s (make-grpc-slice))
(grpc-slice-length s)
(grpc-slice-length (begin0 s (set! s #f)))
On Tue, Oct 3, 2017 at 7:55 PM, Eric Dobson <eric.n.dob...@gmail.com> wrote:
> Parsing it out in atomic mode probably will work, I'll look at that. The
> callb
not, then I don't have a better idea than the approach you describe.
> I don't quite follow why you'd need new functionality from wills, since
> a will procedure on a cpointer already receives the cpointer back when
> there are otherwise no references to the cpointer.
>
> At Tue, 3
I'm dealing with some foreign apis that want to be passed long lived output
pointers to structs. The apis eventually call back indicating that the
struct has been filled in appropriately and then I want to read out the
values and deallocate the structs. I'm using atomic interior memory for
these
George: I don't see that invariant for java in anything that I search for
on Java finalizers. Do you have a reference? In particular java only has
one finalizer per object (the finalize method) and across objects the
references I found seem to imply that there is no guaranteed order?
I'm trying to write some racket code which interfaces with a foreign
library and provides a safe interface. Some of the functions I'm calling
allocate memory and need to have this explicitly freed by the caller. The
'allocator' binding from ffi/unsafe/alloc seems to solve this problem, but
I'm
I have been downloading racket in my continuous builds for a while from
http://mirror.racket-lang.org/installers/6.6/racket-minimal-6.6-x86_64-macosx.tgz
but today it stopped working. Is this just a transient error with the
server or should I change my urls? I noticed that the new urls on the
I'm seeing slow expansion (on the order of hundreds of milliseconds) for
the following program:
https://gist.github.com/endobson/e165edf224b4028db48d
It is a single function of generated code. Similar functions that don't use
match as extensively are much faster < 10 milliseconds.
I'm trying to
That seems to be defined as _uintptr which could be different than 'size_t'
in C, but is probably a better choice than '_int64'.
On Tue, Jun 16, 2015 at 9:55 AM, Marc Burns m4bu...@uwaterloo.ca wrote:
What about _size in ffi/unsafe ?
On Jun 14, 2015, at 1:39 PM, Eric Dobson eric.n.dob
I'm currently on working on bindings to a foreign library that has elements
in structs that are defined as time_t and size_t. I couldn't find anything
in the core ffi types that corresponded to these, so currently I am using
int64_t as that was what I found was correct for the system I'm currently
9 matches
Mail list logo
