Remove ffjson because of gccgo issues

[crosbymichael]

Fixes #362

Signed-off-by: Michael Crosby [email protected]

[wking]

51f8868 looks good to me. This will also require dropping ffjson from #349 if this PR lands first.

[JakeWarner]

LGTM

[vbatts]

so many lines.
@crosbymichael is there any other way you can still benefit from the unmarshal speed improvements?

[crosbymichael]

not that i know of at this point

[vbatts]

i wonder if having a build tag + go:generate would allow a way around incompatible things like gccgo?

[wking]

On Thu, Mar 31, 2016 at 11:52:21AM -0700, Michael Crosby wrote:

not that i know of at this point

The cludgy approach would be “fork this repo and keep ffjson in the
fork” (this could maybe happen in a separate long-running branch of
this repo, but I'm not clear enough on Go vendoring to know). Then
consumers could pick whichever implementation matched their preferred
performance / portability balance. With the ffjson being
autogenerated, maintaining the fork shouldn't be too much work.

[vbatts]

@wking noup

[wking]

On Thu, Mar 31, 2016 at 12:00:56PM -0700, Vincent Batts wrote:

i wonder if having a build tag + go:generate would allow a way
around incompatible things like gccgo?

This also sounds promising to me, and would certainly be cleaner than
using two branches/repos if it works out.

[JakeWarner]

Personally, I'd wait to potentially re-integrate ffjson until the issue behind pquerna/ffjson#172 is resolved as any golang1.6 builds aren't consistent due to the spec having anonymous structs. I see that @crosbymichael closed #361 due to this pull request.

[crosbymichael]

ya, i think we can remove for now and work with upstream to fix some of the issues that we have

[vbatts]

sounds fine.

LGTM

[mrunalp]

LGTM