Hey everybody. I’m working on a series of tutorials about ic-cron. This is the first one about how one can extend Sonic exchange by leveraging Open Internet Services paradigm.
Please, take a look. I would be very thankful if you could provide any feedback (post it here or in comments) and if you could repost it through your social media channels.
By the way, ic-cron was promoted to version 0.5!
What’s new:
kind - use your own type to differentiate between tasks);delay scheduling argument (now you can schedule a task to execute each monday 3PM at any other day of week);What would it take to have ic-cron library in Motoko instead of Rust?
I don’t know actually.
Some simple (and non-efficient) version should be pretty easy to implement. But ic-cron uses BinaryHeap collection, that makes it a lot more faster. So if you want a Motoko version of this library to have the same performance it will take same effort.
Thanks that’s really helpful, I have learned many things that I wasn’t aware of.
Appreciate your effort on this Alexander. A very nice contribution!
@senior.joinu , really valuable, it’s exactly what I am looking for as a starter for IC,
hope to have more such similar articles.
I feel it’s not easy to get the deep/practical knowledge for starter, reviewing official docs is not enough.
Getting a proper job in the field seems not easy as well at present(any other guys have similar concerns? ),
BTW, pls drop me a msg for details if there are proper opportunities(fullstack or backend), I think i am professional and love IC, Rust 
@senior.joinu
I have tried to deploy the example locally but I keep getting some error
The invocation to the wallet call forward method failed with the error: An error happened during the call: 5: Canister rrkah-fqaaa-aaaaa-aaaaq-cai trapped explicitly: Custom(No more values on the wire, the expected type principal is not opt, reserved or null)
dfx version 0.9.0
Steps I did.
dfx start --clean
Create canisters to get the local wallet canister needed for the next command
dfx canister create --all
dfx deploy --wallet rwlgt-iiaaa-aaaaa-aaaaa-cai --argument '(principal "my_principal")'
This builds successfully but fail at installing
Installing canisters... Creating UI canister on the local network. The UI canister on the "local" network is "ryjl3-tyaaa-aaaaa-aaaba-cai" Installing code for canister ic-cron-sonic-bot-example, with canister_id rrkah-fqaaa-aaaaa-aaaaq-cai The invocation to the wallet call forward method failed with the error: An error happened during the call: 5: Canister rrkah-fqaaa-aaaaa-aaaaq-cai trapped explicitly: Custom(No more values on the wire, the expected type principal is not opt, reserved or null)
Also deploying to production --network ic returns the same error.
Did you tried that?
This posts says that there is no need in --wallet argument if you did upgrade your dfx now.
Yes unfortunately this doesn’t work and also upgrading the wallet fails for some reason.
Most probably it’s related to the latest breaking changes with dfx 0.9.0
I found a work around, not sure it’s correct but it unblocked me for now.
pub fn init() {
let controller = caller();
....
}
I have another question, is there a way to test our code locally against the deployed Sonic canisters?
If I deployed that code locally it will try to find sonic canisters locally not on the mainnet and of course all the calls fails.
Hmm, I’m not sure if this workaround will work. Or at least you have to only call your canister from your own principal or only from your wallet.
Sonic’s code is not open sourced yet, so there is no way of testing locally.
Random question: do you know if ic-cron is cycle-intensive or is cheaper than the Motoko heartbeat functionality? See here for context.
My guess is that it’s equally as cycle-intensive (since the issue is on the system level and not programming language dependent), but I could be wrong.
Hmm… I don’t notice any problem with expensiveness. For a tutorial about Sonic I left my canister with cron task to keep polling exchange rate for a week. And it only wasted around $1 within that time.
excellent guide, thanks!
Thats wierd that @senior.joinu found it cheap. Now im not famliar with the rust side of things but is the heartbeat the same heartbeat timeframe as motoko (I think every block)?
If so, It doesnt seem right that on motoko its much more expensive if this iccron library calls the heartbeat call as frequently as on motoko.