Update @Ericbla encoder fork

[stereokai]

Hi @keichi, I forked @Ericbla's binary-parser-encoder from #73 and updated it by cherry picking all the commits from this repo that were missing there. I also got all current tests passing both for the parser and the encoder.

Your binary-parser has the most developer friendly syntax out there in my opinion and it deserves an encoder to go along with it, and many users have also been showing interest in one. I'll be happy to commit for a little while to ensure this feature is implemented according to what you think is best for you and for the project.

Please let me know if you'd like to collaborate on this :)

[JeffBusch]

Any word on this getting merged? Seems like a lot of people were looking forward to this feature...

[Kreijstal]

Any word on this getting merged? Seems like a lot of people were looking forward to this feature...

They were looking for new mantainers after all.. I wouldn't pressure the mantainer lest we have the same thing like xz lmao, but I'm going to quietly use this fork instead

@stereokai not sure if this is much to ask, but can you write examples on how to use? (the encoding part)

[axi92]

Any thoughts on this? I think a lot of people like to use only one package instead of 2 =)
@keichi @yuhr

[stereokai]

@Kreijstal check out the encoder tests in this PR which were written by the original encoder developer, @Ericbla, it's very simple and straightforward, you define a parser as usual and then just call .encode(plainOldJsObject)

[Kreijstal]

@Kreijstal check out the encoder tests in this PR which were written by the original encoder developer, @Ericbla, it's very simple and straightforward, you define a parser as usual and then just call .encode(plainOldJsObject)

Ahh, thank you that was so simple...

[jonbarrow]

This looks REALLY nice, I'm wanting to use this fork in a project but am having some issues related to bit fields. Is there a clean way to mark the "end" of a bit field in the encoder? I've dug around the source and couldn't quite find a way to do so

There are some cases where data may be tightly packed in a way where many separate bit fields are directly next to each other, which ends up having issues since at the moment this would be treated as a single bit field and only 32 sequential bits are supported

In my case this data is Mii data from the Wii U/3DS, which makes heavy use of bit fields. This can be worked around by using .nest() with multiple parsers, but that feels a bit hacky imo?

[jonbarrow]

This seems to not be compatible with parsers which use negative seek values, which is a supported feature https://github.com/keichi/binary-parser#seekreloffset

[rain1]

Do you have plans to keep maintaining it? If yes you could create hard fork of it if original author does not want it in his repo. This way your project will come up independently in google search since default behaviour seems to be that only main project appears in google search and forks do not.

I have even seen case where such move revived dead project because all the sudden author felt need to save his project from being stolen.

[jonbarrow]

Do you have plans to keep maintaining it? If yes you could create hard fork of it if original author does not want it in his repo. This way your project will come up independently in google search since default behaviour seems to be that only main project appears in google search and forks do not.

I have even seen case where such move revived dead project because all the sudden author had to save his project from being stolen.

Not a fork, but I started a rewrite of this library a while ago to address both the lack of encoding (we didn't want to rely on forks like this, since forks can go away at any time) and some other issues we ran into with this library (such as supporting bit fields larger than 32 bits, and needing to encode non-UTF8 strings) https://github.com/PretendoNetwork/binary-parser (dev branch is more up to date)