-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimise modules and publish them separately (part 1) #912
Conversation
… special.sigma -> sigma
# Conflicts: # sdk/js/src/main/scala/org/ergoplatform/sdk/js/Header.scala # sdk/js/src/main/scala/org/ergoplatform/sdk/js/Isos.scala # sdk/js/src/main/scala/org/ergoplatform/sdk/js/PreHeader.scala # sdk/shared/src/test/scala/org/ergoplatform/sdk/multisig/SigningSpec.scala
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Empty file added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed
|
||
/** Override default logging which outputs stack trace to the console. */ | ||
override protected def logError(t: Throwable): Unit = {} | ||
} | ||
object AvlTreeVerifier { | ||
def apply(tree: AvlTree, proof: Coll[Byte]): AvlTreeVerifier = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to make this method private (so apply is not a best name), and do a comment that digest is not updated!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
turned constructor of AvlTreeVerifier into private, added ScalaDoc for apply method, which serves as constructor (this is standard pattern in Scala, not sure what you mean by "not the best name").
It is created simply as AvlTreeVerifier(tree, proof)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that apply() is used around Scala ecosystem to create an object in consistent state. Which is not the case here - the state would be consistent only for lookup proofs.
createVerifier
was a dirty hack already, but now you are going further with it by endorsing a method used everywhere to create an object with inconsistent state in most cases.
Instead of hiding dangerous behavior silently under apply(), you need to limit access to dirty code and provide a warning(better, via naming also), or do a builder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please explain how createVerifier is a dirty hack?
Give an example of when "object with inconsistent state mostly" is created?
I don't understand your hints, please clarify.
Note, for each AvlTree operation, a new AvlTreeVerifier is created and not reused across operations. The role of createVerifier method is to do costing of creation itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you are calling def apply(tree: AvlTree, proof: Coll[Byte]): AvlTreeVerifier
, you are expecting from resulting tree to have digest AFTER proof application (otherwise, proof
argument does not make sense), which is not the case here, as resulting tree has digest BEFORE the proof. Thus the state is inconsistent and everywhere updateDigest
is called after apply
to restore consistency. That is what I am referring as a dirty hack to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AvlTree.digest is always connected with the proof in such a way, that when the verifier reconstructs the tree from the proof, the root node should have the avlTree.digest as the label.
This is checked in the Verifier constructor.
With this in mind I don't see any hacks you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AvlTree.digest is always connected with the proof in such a way, that when the verifier reconstructs the tree from the proof, the root node should have the avlTree.digest as the label. This is checked in the Verifier constructor. With this in mind I don't see any hacks you mentioned.
What check in the constructor are you talking about ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What check in the constructor are you talking about ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are expecting from resulting tree to have digest AFTER proof application
as far as I understand, after Verifier construction, the digest indeed corespoinds to the digest of the tree reconstructed from the proof. At least what I can learn from
require(startingDigest startsWith root.label)
in the computation of reconstructedTree field (which is done as part of constructor see topNode)resulting tree has digest BEFORE the proof
this is wrong
Starting digest is indeed corresponding to the proof's tree. However, my point was not about that, rather, about e relation between tree and proof.
I think as a quick workaround you can call it treeBeforeProof
, and update scaladoc accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But, it is not tree before proof, my point is that it is actually the tree AFTER proof.
Clarified this point in the ScalaDoc.
import scalan.RType | ||
import scalan.util.Extensions.BigIntegerOps | ||
import sigma.data.OverloadHack.Overloaded1 | ||
import sigma.data.{CollOverArrayBuilder, RType} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CollOverArrayBuilder import not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@@ -494,7 +492,7 @@ class CostingSigmaDslBuilder extends SigmaDslBuilder { dsl => | |||
implicit val validationSettings: SigmaValidationSettings = ValidationRules.currentSettings | |||
|
|||
// manual fix | |||
override val Colls: CollBuilder = new CollOverArrayBuilder | |||
override val Colls: CollBuilder = sigma.Colls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment is confusing, what does "manual fix" mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed here and in other places
case _: Box => BoxRType | ||
|
||
case _: AvlTreeData => AvlTreeDataRType | ||
case _: AvlTreeData => AvlTreeDataRType // TODO remove this RType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please describe in the comment why to remove
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
package object sigmastate { | ||
import CheckingSigmaBuilder._ | ||
|
||
/** RType descriptors for predefined types used in AOTC-based interpreter. */ | ||
def rtypeToClassTag = ??? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unused method with meaningless definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added clarifying scaladocs
package rewriting | ||
|
||
import scalan.reflection.{Platform, RClass, RConstructor} | ||
import sigma.reflection.{Platform, RClass, RConstructor} | ||
//import sigma.kiama.==> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commented out code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
|
||
/** Override default logging which outputs stack trace to the console. */ | ||
override protected def logError(t: Throwable): Unit = {} | ||
} | ||
object AvlTreeVerifier { | ||
def apply(tree: AvlTree, proof: Coll[Byte]): AvlTreeVerifier = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that apply() is used around Scala ecosystem to create an object in consistent state. Which is not the case here - the state would be consistent only for lookup proofs.
createVerifier
was a dirty hack already, but now you are going further with it by endorsing a method used everywhere to create an object with inconsistent state in most cases.
Instead of hiding dangerous behavior silently under apply(), you need to limit access to dirty code and provide a warning(better, via naming also), or do a builder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rename "sc" to "smartContracts", as sc is not descriptive
Agree, but I plan to rename it into |
Work towards #902, please read for motivation background.
In this PR: