Heartbeat improvements / Timers [Community Consideration]

I am running into this error when I enable the timers feature. Any ideas?

image

@Severin @berestovskyy

EDIT: Some more context. I have enabled the timer’s feature in my Cargo.toml for the crate requiring this feature. Hence, my imports work.

If you look at the error message, it seems to be breaking because an internal dependency of ic_cdk, ic0::global_timer_set is not resolved.

Other things I tried:

  • nuked my target directory and tried building again
  • enabled the feature in both the workspace cargo toml and the crate using it

So it’s all good now, or there is still an issue?

1 Like

I managed to solve it.

When I had posted I had already enabled the timer’s feature.

What solved it was running cargo update after enabling the timer feature.
That was the missing piece.

1 Like

Are timers in motoko 0.7.4? If not, when is the plan?

2 Likes

Motoko Canister Timers are in the code review, as the target for the feature is Q1 2023. Hopefully, it will be finished sooner, but let’s not rush and allow the guys finish their job…

We’ll update this thread once there are news.

7 Likes

Is there a way to call async functions (i.e. raw_rand()) within the function invoked by set_timer/set_timer_interval?

1 Like

@berestovskyy gave an example here: Timers API: async function execution · Issue #351 · dfinity/cdk-rs · GitHub

2 Likes

It might make sense to make the handler async, WDYT @AdamS ?

1 Like

It might make things more ergonomic if it was, but since most of the time you won’t need to, I elected to remove the overhead for users who don’t need it. You can always ic_cdk::spawn a future from a sync context.

1 Like

I finally waited for the release of timers feature in the motoko 0.7.5, but after updating the version of moc in vessel I still get an error.

I use this command for updating vessel moc compiler:

vessel verify --version 0.7.5

I also updated motoko-base in package-set.dhall:

    { name = "base"
    , repo = "https://github.com/dfinity/motoko-base"
    , version = "moc-0.7.5"
    , dependencies = [] : List Text
    },

Despite these steps, I can’t import functions with

import { cancelTimer; setTimer } = "mo:⛔";

What else should I do to take advantage of the timer functionality?

@rabbithole Haven’t tried it yet but here is an example

There are no problems with examples, I looked at different examples, including in tests. The problem is that I can’t compile the code with the latest motoko 0.7.5. What am I doing wrong?

I’m not sure what is going on with 0.7.5. Either there is a bug and the feature was not fully enabled, or the changelog is slightly misleading because the release only includes the internal compiler support, with the matching base library exposing the feature to follow in the next release.

@ggreif would know the answer but might be on holiday still.

I’ll try to investigate tomorrow.

If you are using dfx to build the sources, you may still need to tell dfx to actually use moc 0.7.5 using environment variable DFX_MOC_PATH (or similar, I may be misremembering the name)

1 Like

This should work with the latest released moc. What compile error do you get for this?


Please note also that this is merely accessing the compiler internals, and there is still a pending PR for the base library: feat: user-facing API for timers by ggreif · Pull Request #474 · dfinity/motoko-base · GitHub. Your updated package-set.dhall won’t change anything.

@ggreif I don’t see cancelTimer and setTimer listed here

Because they are separated away in motoko/timers-api.mo at master · dfinity/motoko · GitHub, and -no-timer suppresses them.

Oh, I see. Just checked setTimer, works fine for me, no compiler errors

2 Likes
Caused by: Failed while trying to build all canisters.
  The build step failed for canister 'ryjl3-tyaaa-aaaaa-aaaba-cai' (journal) with an embedded error: Failed to build Motoko canister 'journal'.: Failed to compile Motoko.: Failed to run 'moc'.: The command '"/Users/khalik/.cache/dfinity/versions/0.12.2-beta.0/moc" "/Users/khalik/Documents/projects/ng-storage/src/backend/journal/main.mo" "-o" "/Users/khalik/Documents/projects/ng-storage/.dfx/local/canisters/journal/journal.wasm" "-c" "--debug" "--idl" "--stable-types" "--public-metadata" "candid:service" "--actor-idl" "/Users/khalik/Documents/projects/ng-storage/.dfx/local/canisters/idl/" "--actor-alias" "journal" "ryjl3-tyaaa-aaaaa-aaaba-cai" "--package" "array" ".vessel/array/v0.2.1/src" "--package" "base" ".vessel/base/moc-0.7.5/src" "--package" "base-0.7.3" ".vessel/base-0.7.3/aafcdee0c8328087aeed506e64aa2ff4ed329b47/src" "--package" "bimap" ".vessel/bimap/main/src" "--package" "encoding" ".vessel/encoding/v0.4.1/src" "--package" "io" ".vessel/io/v0.3.1/src" "--package" "uuid" ".vessel/uuid/main/src"' failed with exit status 'exit status: 1'.
...
type error [M0119], object field cancelTimer is not contained in expected type
  module {}

@claudio are right, in my error you can see that the compilation uses moc from .cache/dfinity/versions/0.12.2-beta.0/moc, not the one that comes with vessel
DFX_MOC_PATH="$(vessel bin)/moc" works! But I don’t know how to tell the VS Code linter also the compiler version.
@ggreif I should wait for the public api with PR #474

I saw the description of the compiler release and decided that the timers would be hidden in primitives without a public API, but I’m glad I was wrong.

P.S. I’m embarrassed that I drew the attention of the team during the holidays, thank you!

No worries! Let the questions come!

1 Like

Does awaiting pause the timer or mess with the intervals like with the heartbeat?