AssemblyScript Grant Q1 2021

Hi @nearmax,

I just posted a proposal in the assemblyscript dao for borsh-as [1], made in collaboration with @willemneal. The project is fully functional, thoroughly tested, and is in the process of being added to the near-sdk.

This borsh implementation is actually part of a larger package called serial-as [2], which standardizes serializers in assemblyscript. Thanks to serial-as, developers only need to implement a few methods (encode_number, decode_string, etc), and do not need to worry about implementing a transform. Furthermore, serial-as readily provides a set of tests that both basic (u*, sting, array, etc) and complex objects (Nullable objects, Nested objects, Inheritance, etc)

Besides borsh, we have also implemented JSON in serial-as. While the current implementation is just a wrapper around assemblyscript-json, the idea for the near future is to use a more memory-efficient implementation. We can achieve this by simplifying the internal representations used while decoding an object (known as Values in assemblyscript-json). While the new implementation is still a work-in-progress (we are still deciding on some aspects with @willemneal), it is already fully functional, completely compatible with as-json, and thoroughly tested (see the feat-standalone-json branch).

serial-as has been in development for the past 3 months, and I plan to keep working on it and maintaining it. Because of this, I would like to ask the committee to consider giving a grant for serial-as and its upcoming development/maintenance.

Thank you for your time,
Guillermo

[1] serial-as/borsh at main · gagdiez/serial-as · GitHub
[2] GitHub - gagdiez/serial-as: Building a generalized encoder for assembly script

Interesting, if you need there is a whole set of tests here which you can easily adapt for your package. They should save you time writing tests and help to make sure that everything is correct.

Looking forward to see the comparison!

1 Like

Awesome! Thanks for the tests!

For the record, I have changed ownership of this grant and the post itself to @jim .

Hi @jim, when you have time please have a look at my message above related to AS grants. Thanks!

Hey @gagdiez. @willemneal and I will synch on this today. Thanks for all the info. We’ll review shortly.

3000 NEAR claimed by @gagdiez

3000 NEAR claimed by @ashutoshvarma

Hi @jim, Hope you are doing fine!
I have been working on near-sdk-as simulation bounty.
As the last remaining part of Finish near-sdk-as simulation test framework, I created the PR (feat: Update simulator tests for new `near-runner` API by ashutoshvarma · Pull Request #648 · near/near-sdk-as · GitHub) and it was merged.
But I don’t know why my proposal failed SputnikDAO
Let me know when you are ready, I will make the proposal for the same again.
Thanks

Hi @jim, when you have time please have a look at my message above for AS grants.
Thanks

Hey @ashutoshvarma! Sorry about the delay here. Please resubmit and I’ll get this taken care of soon :slightly_smiling_face:

Hi @jim @jberrytech , please find the new proposal

Hi @jim,@jberrytech, this proposal is also going to expire soon. Kindly make time for this.

Hi @jim @nearmax,

I have been trying to connect with you guys for a long time. I’ve completed the work as per the grant and all the PRs are merged.
I have made proposals many times but they eventually expire. Kindly respect my time and the work that I have done for the NEAR community.

Best
Ashutosh

1 Like

1200 NEAR claimed 6 by @ashutoshvarma

Hey, I’m interested in applying for the as-bignum muldiv grant. However, I’m confused on the exact requirements involved. I have the following questions:

  • as-bignum apparently already has muldiv for u128. Do I just have to implement muldiv for u256?
  • I’d like to know more about the faster u128 division algorithm. Is it required for the grant, and may I have some sources (academic papers, wikipedia pages) about the algorithm to implement?

Hey @rom. This is great that you are interested in this problem. @vlad, could you take a look at this and provide some guidance?

Thanks for the response. I’ve already shot an email at @nearmax about this, but I’d just like to note here that implementing both an optimized implementation of muldiv (which requires optimized mulmod, multiply, and divide operations for u256) and I’m assuming some fast paths for u128 division would take hundreds upon hundreds of lines of heavily tested code. I’ve already finished an unoptimized implementation here that takes up 500 lines and took entire days to make. In my opinion, relative to the sizes of other grants, the difficulty doesn’t match the reward. I’d be happy to optimize my existing code and merge into the as-bignum repository for a higher grant, if that’s possible.

1 Like