FAQ
It may still be nice to have a stream interface on the writer. I don't
anticipate getting the encoder logic done anytime soon.

The decoder logic is about 4000L of C, while the encoder logic is about
6200L of C++.
My decoder logic ended up being about 1500L of Go, who knows how many lines
the encoder will end up being. Furthermore, I'll probably need to spend
some time learning the encoder does its magic.

JT
On Wednesday, October 28, 2015 at 5:23:57 AM UTC-7, Mike Houston wrote:

Excellent, in which case I won't attempt to wrap the stream interface, as
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
On Tuesday, October 27, 2015 at 5:20:33 PM UTC-7, Ian Lance Taylor wrote:

On Tue, Oct 27, 2015 at 5:01 PM, Mike Houston <schm...@gmail.com>
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,
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.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 18 of 18 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 9, '15 at 2:38p
activeOct 29, '15 at 4:08a
posts18
users11
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase