this seems like the better long-term solution.
Thanks for the clarification on passing pointers Ian, that is much clearer
to me now.
Mike.
On Wednesday, October 28, 2015 at 6:09:49 AM UTC, thebroke...@gmail.com
wrote:
I finished a Brotli decoder in pure Go, you can find the package here:
- https://github.com/dsnet/compress
After implementing this, I feel like Brotli is at least 2-3x more
complicated than DEFLATE. At least I could keep the entire specification
for DEFLATE in my head... I couldn't do it for Brotli. Currently, the
library passes on all the test files that the official Brotli repo
contains. The next steps for the package will be:
1. Writing more unit tests to ensure correctness of the decoder. I
want to hit as many edge conditions as possible and places where I was not
sure what the specification was exactly dictating.
2. Improve performance of the decoder.
3. Start work on an encoder.
Enjoy,
JT
--- https://github.com/dsnet/compress
After implementing this, I feel like Brotli is at least 2-3x more
complicated than DEFLATE. At least I could keep the entire specification
for DEFLATE in my head... I couldn't do it for Brotli. Currently, the
library passes on all the test files that the official Brotli repo
contains. The next steps for the package will be:
1. Writing more unit tests to ensure correctness of the decoder. I
want to hit as many edge conditions as possible and places where I was not
sure what the specification was exactly dictating.
2. Improve performance of the decoder.
3. Start work on an encoder.
Enjoy,
JT
On Tuesday, October 27, 2015 at 5:20:33 PM UTC-7, Ian Lance Taylor wrote:
then it is fine to allocate a []byte in Go, pass the address of
element 0 of the slice to C, and let C code fill in the bytes.
The GC is not blocked during a call to a C function.
Never use reflect.SliceHeader. It was a mistake to make it an
exported type. As the docs say, it can not be used safely or
portably.
Ian
On Tue, Oct 27, 2015 at 5:01 PM, Mike Houston wrote:
With cgo, is it appropriate to allocate a buffer in Go and pass it to the C
decompression function to put its output in, or should I be allocating the
buffer on the C-side and copying it to Go using GoBytes or
reflect.SliceHeader? Or does it matter? Will the GC be blocked during the
call into a C function?
If we adopt the rules described in https://golang.org/issue/12416,With cgo, is it appropriate to allocate a buffer in Go and pass it to the C
decompression function to put its output in, or should I be allocating the
buffer on the C-side and copying it to Go using GoBytes or
reflect.SliceHeader? Or does it matter? Will the GC be blocked during the
call into a C function?
then it is fine to allocate a []byte in Go, pass the address of
element 0 of the slice to C, and let C code fill in the bytes.
The GC is not blocked during a call to a C function.
Never use reflect.SliceHeader. It was a mistake to make it an
exported type. As the docs say, it can not be used safely or
portably.
Ian
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
