@senior.joinu If I wrote somewhere that the replica included in any shipped version of dfx supports heartbeat, would you please point me to that?
The spec itself is always ahead of the implementation.
1 Like
@ericswanson
I’m really not satisfied with our conversation so far. What do you think you’re doing?
Here is your original post about 0.8.2
There is a link “Please see: dfx 0.8.2 release notes”
Let’s follow it. It leads to this page Smart Contracts on the Internet Computer
There is another link “Updated to Interface Spec 0.18.0”
Let’s follow once again.
It leads to this page Smart Contracts on the Internet Computer
Where one could easily see this text, stating that heartbeat mechanics are now implemented.
Would you kindly just uncover the ETA about heartbeat in dfx. This could greatly help other teams depending on this feature to plan their work, including me.
Unfortunately, I don’t have information about the ETA of the implementation of the heartbeat functionality.
You are right, the linked document The Internet Computer Interface Specification :: Internet Computer is not version-specific. I should have noted that in the release notes rather than implying that all of the information in it applies to spec 0.18.0 or to dfx 0.8.2.
It does not all apply to spec 0.18.0. The interface spec is updated independently. The Canister Heartbeat was added to spec 0.18.2, though one cannot find that out by reading the linked public spec doc. Furthermore, implementation follows the spec.
3 Likes
Sorry to hear that!
Thanks for the clarification.
Could you please tag someone that might know?
Fwiw, @ericswanson did ping me (a few hours ago, but i only recently saw it) to see if I can help him find out more on the ETA. I will ping some folks internally to try to see if we can get some clarity for @senior.joinu and the wider ICP community.
1 Like
I’m confused. IIUC, heartbeat was available prior to 0.8.3 but no longer available on 0.8.3.
So it sounds like it was already implemented before. Don’t we just need to rollback the commit that removed it?
FWIW, heartbeat is super important for any cronjob canisters. Hopefully, it can be supported in Motoko as well.
3 Likes
To be honest, I am new to the history of heartbeat so I cannot speak intelligently on it yet. Hopefully, I will soon once i learn more.
2 Likes
Hello all. @diegop pinged me on this thread regarding the confusion around heartbeats. The heartbeat functionality was implemented quite a while ago but initially was only enabled on the NNS subnet. Then it was enabled on all subnets. While all of this was done on the ic side, the various related repos (sdk and the spec) were not properly updated. We are slowly getting around to updating all the relevant repos now.
GitHub - akhi3030/heartbeat-example: A simple example of how to use the heartbeat functionality in rust canister smart contracts on the Internet Computer contains a simple example on how to use the heartbeat functionality. I’ve already given it to some external developers who have been able to use it successfully. Note that it does not use ic_cdk_macros yet. PRs are welcome if someone wants to update it.
Please let me know if you have any further troubles or if there is anything I can help with here.
6 Likes
Just to confirm,
- This Rust code still works in 0.8.3.
- This only works in Rust and not currently in Motoko.
Does that sound right?
1 Like
Thanks for testing! Yes, this sounds correct.
Yes, we can! By reading the changelog!
3 Likes
Random question, but can you explain what dfx cache delete and dfx cache install do?
If you delete the latest dfx version from the cache, how can you then install that same dfx version from the cache?
I don’t quite understand the purpose of the cache. It seems like a version manager of some kind, but it also doesn’t let the user select an older version of dfx to use (e.g. dfx cache use or something like that).
1 Like
FWIW, I just upgraded from dfx 0.7.1 to 0.8.4, and update calls are now at least 4-5 times faster locally with dfx start.
I don’t think the old --no-artificial-delay flag worked for me… now the default works great (i.e. it’s really fast).
2 Likes
dfx cache delete deletes from ~/.cache/dfinity/versions/ corresponding to the version of dfx being executed. dfx cache install conversely installs files from the executing dfx binary into that directory.
Installing dfx per the instructions at https://smartcontracts.org/ downloads the dfx binary to /usr/local/bin/dfx. Once you run dfx cache install, or another command that installs the cache, you’ll have that binary in two places: /usr/local/bin/dfx, and ~/.cache/dfinity/versions/<version>/dfx.
The purpose of the cache is twofold.
First, it holds files such as moc and replica, where dfx can access them. These are distributed within the dfx executable, but they take some time to unpack, and in the case of executables, of course they need to be on the filesystem.
Secondly, the cache holds other versions of dfx and its needed support files. If dfx.json specifies something like "dfx": "0.8.2", then if you run a different version of dfx, it will actually call the specified version. The other way you can do this is by setting the DFX_VERSION environment variable, for example DFX_VERSION=0.8.2 dfx start will start the replica that shipped with dfx 0.8.2, if that version is installed in your cache.
4 Likes
These are the kind of answers I love to read. Thanks!