Proposal to hard fork

[AArnott]

See AArnott#1

To be clear, the original author (@neuecc) has done an excellent job with this library. It's fast and measured, which is awesome. But it needs some changes made to suit our purposes and as it seems the author's priorities are elsewhere as this project hasn't moved lately and we're not seeing any responses to issues that we or others file, we plan to take this project forward ourselves.

If we had @neuecc's endorsement, we would keep the assembly and package name. But lacking that, we'll change the name to avoid confusion.

[odysoftware]

Everything sounds great to keep this project ongoing - because neuecc really created a great library - but it needs support. So lets see what neuecc says.

[neuecc]

If it will good for evolve to .NET, I'll agree it.
As you say, my response speed is slow, the period of interest is half a year.
(Just now, my next project approached the end and I was about to start updating the code generator at least.)
But it does not necessarily match the speed demanded by many people.
I have my idea that there are still many things I still have to update and the idea for my next big improvement,
I do not know when to handle it.

[neuecc]

As my absolute opinion, we should not ignore Unity correspondence.

[AArnott]

Thanks, @neuecc. Given your continued interest, and time available coming soon, rather than a hard fork, collaborating seems more appropriate. How would you feel about granting me push permissions to your project (and perhaps admin so I can set up web hooks and get a CI/PR build validation going on your project as I have going on my fork)?

If you were to do so, I'd merge changes I've made recently from my fork into your root project.
And here are some of my own top priorities for near-future work.
There are some teams within Microsoft that I'd make a high priority to respond to issues/PRs as well. PRs from others in the community I'd respond to, time permitting. I do have dozens of other OSS projects on github I maintain as well. I tend to insist on adding tests for any fix or feature submission. I'd at least start with that policy here until I get to know the insides and outs of your project better and understand the policy that you would like to hold up as the owner.

Thoughts?

[snielsson]

Great suggestions AArnott! I will be looking forward to use and test this library and hopefully be able to contribute myself.

[odysoftware]

Yeah that sounds great!!

One of my favourite wishes would be the compatibility of the library with unity .NET Standard 2.0 ! At the moment due to the use of emit - this is sadly not possible :)

But finally getting some new releases out with all the contributions would be really great. Last release was a year ago :)

[AArnott]

@odysoftware Let's take up this Unity discussion over here: AArnott#15. It's an interesting subject but I want to focus this thread on the fork vs. push permissions discussion.

[neuecc]

@AArnott Thank you, I agree with granting access.
Your project composition looks very beautiful!

Clearly I can not do maintenance by myself so I'm happy if this library can grow as OSS.

My concern is about Unity.
For example, if you simply support Span, it will be difficult to run on Unity.
There are many problems such as IL2CPP in Unity, and proper knowledge is needed to deal with it properly (and do not compromise performance).
And I think that it is weak to the people of Microsoft.

However, there are expectations that if a lot of people are concerned and properly discussed, it will be okay.

[AArnott]

I'm happy to support keeping Unity working. But yes, I'll be relying on you and anyone else more familiar with it than myself to act as guard rails for me. It sounds like before making "modernizing" changes that I should propose changes before making them since you can predict that some ideas are going to cause Unity complications from the outset. I've asked a question over at AArnott#9 to get the Span<T> conversation going.

I'm glad you like the refactoring I've done so far. I'm doing it in the 'master' branch, after having branched off the code for v1.8 which won't have API breaking changes, but still has some of the other fixes I've been making.

I'd also like to learn how you measure performance so I can do the same frequently as I'm coding up changes to make sure I'm not regressing any thing. Is your process for measuring documented anywhere?

[SimonCropp]

so seems no reason to hard fork now?

[AArnott]

Agreed, provided @neuecc follows up to grant me push permissions and/or review my PRs.

[AArnott]

@neuecc I haven't heard back from you on push permissions, nor seen any activity on my PRs. I'm now hitting merge conflicts when trying to update my fork with your changes since we haven't merged our codebases yet. Any update on when you intend to move forward with the merge plans?

[neuecc]

@AArnott Sorry, I've taken holidays(Christmas, new year).
If you're interested yet(sorry for to late...!) , I'd like to start to merge.
First of all, should I invite you as Collaborators?

[SimonCropp]

And access to the nuget

[AArnott]

Yes, sounds good.

[dzmitry-lahoda]

We run Unity 2018.3 targeting AOT with Memory well.

I have hacked SignalR -> MessagePack via aspnet/SignalR#3122.
Unity has broken Expression interpreter and bugs seems raised to Unity (from JamesNK/Newtonsoft.Json#1440 and from #338). LINQ is easy to avoid (issue raised)

Also SignalrR touches types of MessagePack which do Emit even not used Emited types later. So current API of MessagePack is not so Unity friendly.

mpc.exe is not msbuild task(issues raised) when it set as output) and does not run well on Mac(issues raised as well).

For nuget there is no(yet) solution either GlitchEnzo/NuGetForUnity#176.

So as of now MessagePack does not plays nice with new Unity and .NET Core infrastructure on Mac and iOS, with all code sharing possible via .NET Standard (Unity seems will support 2.1 either).

But with a bunch of hacks all works.

[neuecc]

@AArnott
Thanks, I've sent invite mail.

@dzmitry-lahoda
fixing mpc is now active -> #355
It is solved for Win/Linux, OSX is now working.
Generated code works well, it has already been demonstrated in many applications.