QPQ-AG/gmserialization
9
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Package for zx #45

Merged
zxq9 merged 9 commits from zomp into master 2025-01-22 19:36:51 +09:00
Conversation 3 Commits 9 Files Changed 11 +60 -6
zxq9 commented 2025-01-22 14:35:14 +09:00
Owner
Copy Link

This packages the library for deployment on zx (migrating from the old otpr-aeserialization-* line).

It also adds a native Erlang fallback to invokation of the Blake2 algorithm, picking enacl if it is present, but proceeding with eblake2 if not.

This packages the library for deployment on zx (migrating from the old otpr-aeserialization-* line). It also adds a native Erlang fallback to invokation of the Blake2 algorithm, picking enacl if it is present, but proceeding with eblake2 if not.
zxq9 added 6 commits 2025-01-22 14:35:15 +09:00
zxq9 added 1 commit 2025-01-22 14:39:32 +09:00
Merge branch 'master' into zomp
All checks were successful
Gajumaru Serialization Tests / tests (push) Successful in -4m22s
Details
6fae7b4119
zxq9 requested review from dimitar.p.ivanov 2025-01-22 14:42:55 +09:00
zxq9 requested review from uwiger 2025-01-22 14:42:55 +09:00
zxq9 requested review from spivee 2025-01-22 14:43:17 +09:00
dimitar.p.ivanov reviewed 2025-01-22 14:58:08 +09:00
src/gmser_api_encoder.erl
@ -6,6 +6,7 @@
%%% @end
%%%-------------------------------------------------------------------
-module(gmser_api_encoder).
-vsn("0.1.2").
dimitar.p.ivanov commented 2025-01-22 14:58:08 +09:00
Owner
Copy Link

I am wondering if we plan keeping all of those versions in sync somehow, ex. when we change the encoder version, do we also bump the chain objects one? How would we test for compatibility?

I am wondering if we plan keeping all of those versions in sync somehow, ex. when we change the encoder version, do we also bump the chain objects one? How would we test for compatibility?
zxq9 commented 2025-01-22 15:26:54 +09:00
Author
Owner
Copy Link

Those are added by zx but could be omitted. The versions are clearly not in sync across projects (the version of serialization has never been in sync with bytecode or the compiler, for example).

Those are added by zx but could be omitted. The versions are clearly not in sync across projects (the version of serialization has never been in sync with bytecode or the compiler, for example).
dimitar.p.ivanov approved these changes 2025-01-22 14:58:15 +09:00
uwiger approved these changes 2025-01-22 15:45:23 +09:00
src/gmser_contract_code.erl
@ -51,0 +58,4 @@
% syncing a new node, for example).
blake2(Size, Bin) ->
try
enacl:generichash(Size, Bin)
uwiger commented 2025-01-22 15:43:48 +09:00
Owner
Copy Link

Actually, the slowest part of the error throwing machinery isn't the catch (it's actually very fast if not capturing stacktraces, and pretty fast even then), but the code:ensure_loaded/1 call needed before throwing an undef error.

If we can know (through initialization logic) that enacl will be loaded at this point, if present at all, we can use erlang:function_exported(enacl, generichash, 2).

Actually, the slowest part of the error throwing machinery isn't the `catch` (it's actually very fast if not capturing stacktraces, and pretty fast even then), but the `code:ensure_loaded/1` call needed before throwing an `undef` error. If we can know (through initialization logic) that `enacl` _will_ be loaded at this point, if present at all, we can use `erlang:function_exported(enacl, generichash, 2)`.
zxq9 commented 2025-01-22 17:00:31 +09:00
Author
Owner
Copy Link

Does that make the failed case more efficient?
I'm not sure where in initialization we could discover which case we're in, so I left it at call time.

Does that make the failed case more efficient? I'm not sure *where* in initialization we could discover which case we're in, so I left it at call time.
zomp.meta Outdated
@ -0,0 +9,4 @@
{key_name,none}.
{a_email,[]}.
{c_email,[]}.
{copyright,"Hans Svensson"}.
uwiger commented 2025-01-22 15:45:07 +09:00
Owner
Copy Link

Is this correct?

Is this correct?
zxq9 commented 2025-01-22 17:01:00 +09:00
Author
Owner
Copy Link

Ah, copyright, no. I think.

Ah, copyright, no. I think.
zxq9 marked this conversation as resolved
zxq9 added 1 commit 2025-01-22 17:02:06 +09:00
Update zomp meta copyright
All checks were successful
Gajumaru Serialization Tests / tests (push) Successful in -4m22s
Details
ece32da3e8
zxq9 added 1 commit 2025-01-22 19:36:26 +09:00
Add app file back
All checks were successful
Gajumaru Serialization Tests / tests (push) Successful in -4m21s
Details
749f7943d8
zxq9 merged commit 2db9ea6134 into master 2025-01-22 19:36:51 +09:00
zxq9 deleted branch zomp 2025-01-22 19:36:51 +09:00
zxq9 referenced this issue from a commit 2025-01-22 19:36:51 +09:00
Package for zx (#45)
Sign in to join this conversation.
Reviewers
No Reviewers
spivee
dimitar.p.ivanov
uwiger
Labels
Clear labels
bug
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
pig lipstick
Muggle-facing enhancements
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: QPQ-AG/gmserialization#45
No description provided.
Delete Branch "zomp"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?