The Solidity Contract-Oriented Programming Language - By chatting here you agree to the https://github.com/ethereum/solidity/blob/develop/CODE_OF_CONDUCT.md
0.6.10 compiler setting
Hi, anyone knows how to fix this error. I go through this website "https://truffleframework.com/docs/truffle/reference/configuration#compiler-configuration", But I didn't understand what to do. truffle(develop)> compile
Compiling your contracts...
Compiling ./contracts/StarNotary.sol
/mnt/d/Blockchain/Project2Test/node_modules/openzeppelin-solidity/contracts/token/ERC721/ERC721.sol:3:1: ParserError: Source file requires different compiler version (current compiler is 0.5.16+commit.9c3226ce.Emscripten.clang - note that nightly builds are considered to be strictly less than the released version
pragma solidity ^0.6.0;
^---------------------^
Error: Truffle is currently using solc 0.5.16, but one or more of your contracts specify "pragma solidity ^0.6.0".
Please update your truffle config or pragma statement(s).
(See https://truffleframework.com/docs/truffle/reference/configuration#compiler-configuration for information on
configuring Truffle to use a specific solc compiler version.)
Compilation failed. See above.
Node v12.18.1
so it seems we can now use
memoryinexternalfunctions, I'm wondering if anyone knows if there are any practical side effects of doing this?
This was mostly a side-effect of relaxing the restrictions of data locations based on function visibility when allowing calldata arguments to public and internal functions. I'm not sure there really are situations in which using memory arguments to external functions makes that much sense - it'll always be end up being a calldata->memory copy, so I guess it can be convenient, if you only want to use a memory copy of the argument anyways and don't want to write the (equivalent) function f(SomeType calldata x) external { SomeType memory x2 = x; ... }. At least I don't see much use of it beyond that.
prerelease.txt (which if I had known about would not have needed to dl the release ;))
@ekpyron some people suggested they mainly use
externalto avoid the function being called internally - the idea is thatmsg.senderis also the "direct caller" in an external function. So I guess it makes a lot of sense to decouple the data location from the "visibility"
Yep, decoupling makes sense - I just don't think the particular combination external + memory will be used that often (or at least it will rarely really have an advantage over external + calldata).
Hi. Can anybody help me understand this scheduling mechanism?
contract Lottery {
address alarm; // set by some other mechanism.
function beginLottery() public {
... // Do whatever setup needs to take place.
// Now we schedule the picking of the winner.
bytes4 sig = bytes4(sha3("pickWinner()"));
// approximately 24 hours from now
uint targetBlock = block.number + 5760;
// 0x1991313 is the ABI signature computed from `bytes4(sha3("scheduleCall(...)"))`.
alarm.call(0x1991313, address(this), sig, targetBlock)
}
function pickWinner() public {
...
}
}i don't understand the 'ABI signature computed from... part
I want to learn how to schedule calls inside a contract and also unschedule if possible
@andrepadez: https://ethereum.stackexchange.com/questions/234/what-is-an-abi-and-why-is-it-needed-to-interact-with-contracts -- so, it's a binary identifier of the contract method you're calling. This is used to locate the actual method in the binary code. So, as the comment says, very much the same as the sig that is sent along as a callback.
The alarm part: By starting a lottery, some alarm contract is notified that the lottery is about to start. After that point, this contract doesn't do much but wait until pickWinner() is called by some other contract like alarm (or anyone else). Presumably pickWinner() starts by checking that the right amount of blocks have passed.
- I know what an ABI is, i work with web3 also
- this documentation is explicitly to schedule calls within the same contract
1 - how do i get the specific value (0x1991313) or both params are the result of the hashing?
so it would be:alarm.call(sig, address(this), sig, targetBlock)
2 - if i use keccak256 instead of sha3, will it work the same?
3 - doesn't this operation cost gas? where is it coming from?
- You get the specific value just as the comment suggests,
bytes4(sha3("scheduleCall(...)"))with...being replaced with whatever the actual signature is. Since you know what an ABI is, you'll know how to specify..., but in case you need it refreshed, a good place to read is: https://solidity.readthedocs.io/en/latest/abi-spec.html -- I presume they're just hardcoding it to save compute time because Solidity does not have this as a compile-time macro. - SHA-3 is a family of algorithms that is a subset of Keccak, so Keccak256 is (in) SHA-3. So
sha3()means Keccak-256. See instruction set at the bottom of page 29 in Ethereum Yellow Paper (https://ethereum.github.io/yellowpaper/paper.pdf): "SHA3: Compute Keccak-256 hash." - Operations cost gas, yes. This gas is given by the caller of a method. Could you clarify?
@andrepadez: I could be wrong, but I don't see a way for a contract to call itself without interference. You can do something like a request-response model where a contract tells another contract to get back to it at some point in time, and when that time comes, and that contract calls itself, continue the response part.
Yes, sig and 0x1991313 will be constant. They represent method interfaces that don't change in the lifetime of the contract.
Regarding gas cost: The cost of executing a call is paid by the caller of the method. If you want, you can make the contract refund the caller, but initially, it is the caller who pays.
alarm is the Lottery contract, this seems a bit over-complicated (leaving room for unused modularity).
finishProcess method is called?
