search

RGB-WG / rgb-schemata

Standard RGB schemata and schema compiler
Apache License 2.0
29 stars 20 forks source link

Fix compillation of MediaType #4

Closed crisdut closed 1 year ago

crisdut commented 1 year ago

When I add MediaType, the code gives the following error:

https://github.com/crisdut/rgbsc/blob/exp/media/examples/rgb21-token.rs#L40-L45

Reify(TypeAbsent(SemId(SemId(Array<32>(1614979d5f1561641161835702ab73ff24847fe00d5b42d3f8107549b8cd57aa)))))', examples/rgb21-token.rs:56:10
crisdut commented 1 year ago

Hi @dr-orlovsky,

Some updates:

The error occurs because EmbeddedMedia depends on MediaType (external ref). For some reason, when we compile the rgb21 std, the MediaType changes the SemId, and when we try find the reference in TypeSystem, we cannot found because EmbeddedMedia have only the old MediaType SemId referencing.

Everything works if we define MediaType as LIB_NAME_RGB21 instead of LIB_NAME_RGB_CONTRACT!

dr-orlovsky commented 1 year ago

@crisdut Thank you for the details! I was not able to figure that out and your information really helps. Working on this today

dr-orlovsky commented 1 year ago

Ok, the problem is caused by a bug (inconsistency) in how strict types computes semantic identifiers. I am working on the bugfix to that library - it will take about another day to complete.

crisdut commented 1 year ago

Ok, the problem is caused by a bug (inconsistency) in how strict types computes semantic identifiers. I am working on the bugfix to that library - it will take about another day to complete.

Sure,

Thanks @dr-orlovsky !

dr-orlovsky commented 1 year ago

You can track WIP here: https://github.com/strict-types/strict-types/pull/11

Since this is breaking I will also move strict types to use SHA256 instead of BLAKE3, which will fix the other issue we had with WASM

crisdut commented 1 year ago

Hi @dr-orlovsky,

I update the dependencies, but when I try to use EmbeddedMedia another error appears:

thread 'main' panicked at 'invalid token data: Reify(TypeAbsent(SemId(SemId(Array<32>(d3c2fa33b74ed7b4c900f9eb86633786dea89e4b13ad14e4d856f5e61d0b32ca)))))', examples/rgb21-token.rs:56:10
dr-orlovsky commented 1 year ago

Yes, I am continuing to work on it

dr-orlovsky commented 1 year ago

My second attempt: https://github.com/strict-types/strict-types/pull/14

I am checking it now does that PR solves this issue

dr-orlovsky commented 1 year ago

No, it doesn't. Continuing...

dr-orlovsky commented 1 year ago

https://github.com/strict-types/strict-types/pull/15 finally solved the issue

I have updated this PR

crisdut commented 1 year ago

@dr-orlovsky,

Really Really Congrats!!!

I will take the time to understand what you needed to do, as I noticed that there were a lot of changes.

I'm going to create some tests involving the entire contract, to see if we find another inconsistency like this.

But once again, thank you very much, your work is amazing!

dr-orlovsky commented 1 year ago

The problem was simple, but it was tough to find it: references to external types (coming from other libraries) were hashed for the second time when they were used inside other types.

To discover the problem I had to rewrite all parts of the code which are involved in the creation of semantic ids. Also, I had to separate symbolic versions of libraries and type systems (i.e. with names) from the versions used in serialization which internally use semantic ids and not names. That was helpful for the debugging.