sebcrozet / instant Goto Github PK
View Code? Open in Web Editor NEWA std::time::Instant replacement that works on WASM too.
License: BSD 3-Clause "New" or "Revised" License
A std::time::Instant replacement that works on WASM too.
License: BSD 3-Clause "New" or "Revised" License
Hiya, would it be alright to release 0.1.4 for the changes in #16?
Thanks!
checked_duration_since
was added in Rust 1.39.
https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since
Hi, I noticed recently while working on winit
that it no longer builds in the stdweb
configuration due to this crate. Building instant
directly yields (rustc 1.38.0 (625451e37 2019-09-23)
):
PS D:\code\instant> cargo build --target wasm32-unknown-unknown --features stdweb
Compiling instant v0.1.2 (D:\code\instant)
error[E0433]: failed to resolve: use of undeclared type or module `wasm_bindgen`
--> src\wasm.rs:92:13
|
92 | let v = js! { return performance.now(); };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `wasm_bindgen`
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error[E0433]: failed to resolve: use of undeclared type or module `WasmDescribe`
--> src\wasm.rs:92:13
|
92 | let v = js! { return performance.now(); };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `WasmDescribe`
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error[E0425]: cannot find function `inform` in this scope
--> src\wasm.rs:92:13
|
92 | let v = js! { return performance.now(); };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error[E0425]: cannot find value `FUNCTION` in this scope
--> src\wasm.rs:92:13
|
92 | let v = js! { return performance.now(); };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error: aborting due to 4 previous errors
Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: Could not compile `instant`.
To learn more, run the command again with --verbose.
This was working in the past (sorry! I don't know exactly when!) and I noticed this in the last week or so. I'm pretty confident the stdweb
and wasm-bindgen
versions don't matter here, as I've tried older versions with the same results.
Adding an explicit dependency in instant
's Cargo.toml
to wasm-bindgen
seems to solve the problem, but I'm mostly confused that (as far as I know) nothing changed to cause this break...?
Edit: I just realized I may have upgraded rust itself in between this working and not. Looking through the changelog, maybe rust-lang/cargo#6860 could cause a change here? But 1.36.0 was released in July and the last successful CI build for instant
ran when 1.1.2 released earlier this month. ๐
Querying for the performance object is really slow. In fact just calling over into JS at all is really slow and should be avoided as much as possible.
It seems like this crate isn't compatible with various tagets such as:
x86_64-unknown-linux-gnux32
:
Compiling instant v0.1.4
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-mx32" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/instant-550ae5fa912f454c.instant.abqweb52-cgu.0.rcgu.o" "-o" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/libinstant-550ae5fa912f454c.so" "-Wl,--version-script=/tmp/rustcMS7AWm/list" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/instant-550ae5fa912f454c.13ikqv5x1z64tajl.rcgu.o" "-Wl,--gc-sections" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/debug/deps" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libstd-702251223b604f84.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libpanic_unwind-b3ca9fba078e2f61.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libhashbrown-9a5e3e1c5ec45dd5.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_std_workspace_alloc-eb52a12b4f508d71.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libbacktrace-7efbc701b8c23305.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libbacktrace_sys-6ddf034c50a4d68a.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_demangle-41ee65a4a9c3bc91.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libunwind-9beeffcc394003d9.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcfg_if-33f9ae0a13c1a688.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/liblibc-ff7b06950e20877e.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/liballoc-4e001b7e791cd89e.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_std_workspace_core-51a60b0a2181fd75.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcore-499c7e2b3c33be99.rlib" "-Wl,--end-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcompiler_builtins-8c9a60c6d428b275.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-shared"
= note: /usr/bin/ld: cannot find crti.o: No such file or directory
armv5te-unknown-linux-gnueabi
:
Compiling instant v0.1.4
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.instant.1lj3dfed-cgu.0.rcgu.o" "-o" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/libinstant-c30ea17769597818.so" "-Wl,--version-script=/tmp/rustcIcG6Ag/list" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o" "-Wl,--gc-sections" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/debug/deps" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libstd-ad37c70b8f5034f7.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libpanic_unwind-73aaa15f218816c3.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libhashbrown-a5bf3f69444f613f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_alloc-7e20015b8d730e7f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libbacktrace-b52e2ce78c8d3d36.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libbacktrace_sys-bbe9aa043aa55b34.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_demangle-7c8cc70d44c6f1ce.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libunwind-8a842ec7048c7394.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcfg_if-1c2b804ca5542b4f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liblibc-bf6fc08186d861f4.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liballoc-d18fa1c7b0fb86fc.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_core-057abc730e843cfc.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcore-4a5b81689a4456fb.rlib" "-Wl,--end-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcompiler_builtins-e6cf897bfa39b5af.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil" "-shared"
= note: /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: error adding symbols: File in wrong format
This is likely because the crate is forcefully compiled as cdylib when it really shouldn't.
Would be nice to have a release of this lib to propagate the fix for #4. Particularly winit isn't working right now on web because of this.
Heya, I'm using governor
, which requires checked_sub
in Instant
.
instant::wasm::Instant
doesn't yet have the checked_*
operations, and so I'd like to add them.
when building this crate I get:
warning: /Users/stephan/code/github/instant/Cargo.toml: Found `feature = ...` in `target.'cfg(...)'.dependencies`. This key is not supported for selecting dependencies and will not work as expected. Use the [features] section instead: https://doc.rust-lang.org/cargo/reference/features.html
warning: /Users/stephan/code/github/instant/Cargo.toml: Found `feature = ...` in `target.'cfg(...)'.dependencies`. This key is not supported for selecting dependencies and will not work as expected. Use the [features] section instead: https://doc.rust-lang.org/cargo/reference/features.html
did something change in cargo and does this break maybe some platforms? I am grasping straws here, investigating my issue with rapier: dimforge/rapier#207
STR:
let now = Instant::now();
now.elapsed()
;If system time goes backwards in the intervening period, elapsed
will panic:
panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/instant-0.1.12/src/wasm.rs:24:9:
`earlier` cannot be later than `self`.
This seems to be largely because Instant
is based on local system time rather than a proper monotonic clock, violating the specification of std::time::Instant
. I think if we're going to do that, we need to let Instant::duration_since
saturate rather than panic.
This is going to seem like a dumb question, as I think I am just misreading your README.
I have a library (called 'flowrlib') that I want to use instant in, as it is compiled for native with one binary, and for wasm for a web app (which is a library, as I'm using wasm-pack etc to load it in web).
This is how I have configured the flowrlib Cargo.toml:
[features]
stdweb = [ "instant/stdweb" ]
wasm-bindgen = [ "instant/wasm-bindgen" ]
[dependencies]
instant = { version = "0.1", features = [ "now" ] }
(I tried without the stdweb and wasm-bindgen stuff, same problems).
Then I use it in the web library which is compiled to wasm (and hence this compiles flowrlib for wasm also as it is a dependency).
Web library Cargo.toml is thus:
[dependencies]
flowrlib = { path = "../../flowrlib", version = "~0.7.0" }
When I execute the resulting app in the browser I get the ''Time system call is not implemented by WebAssembly host'' message.
I tried also adding the
[features]
stdweb = [ "instant/stdweb" ]
wasm-bindgen = [ "instant/wasm-bindgen" ]
in the web-app library, but I can't as it says:
Caused by:
| Features and dependencies cannot have the same name: `wasm-bindgen`
as it needs wasm-bindgen as a dependency:
[dependencies]
wasm-bindgen = "0.2.25"
So, my question is double:
thanks!
Since stdweb
can work with wasm-bindgen
when using wasm-pack
but wasm-bindgen
does not work with cargo-web
, I think it should be safe to assume that, whenever the wasm-bindgen
feature is enabled the stdweb
feature can be ignored. It can happen that when a crate that depends on instant
has enabled the stdweb
feature and another has wasm-bindgen
enabled, conflicting implementations of now
will be included and causes a compile error.
When neither wasm-bindgen
or stdweb
features are used, the now
function exposes a foreign now
function, explicitly making it safe
.
This behavior produces the effect that the FFI now
is exposed even if wasm::now
is never called, just because it is extern "C"
. Unfortunately, this causes some unexpected issues in other crates. I propose to remove wasm::now
if no valid features are available, even if I understand that this is a breaking change.
Another possible solution is to change the behavior of the features in order to activate wasm-bindgen
by default if the target is wasm32-unknown-unknown
and stdweb
is not specified.
I am very open to discussion, even because the rationale behind blindly using an extern now
function is not clear to me. If you want I will be happy to open a PR when I have a clearer idea of what's the best thing that could be done.
Sometimes for unit tests or even for reproducible builds one wants to force a specific time to be returned by a call returning something like instant::now()
.
See https://reproducible-builds.org/docs/source-date-epoch/ for example.
This issue is relative to a winit issue, we are currently not able to build to a wasm32-unknown-unknown
target. A pull request was created (and merged) few month ago #10.
self.duration_since(SystemTime::now())
, https://github.com/sebcrozet/instant/blob/master/src/wasm.rs#L202, should be Self::now().duration_since(*self)
, like Instant
.
Hi,
That error shows up when running :
cargo test --release --target=wasm32-unknown-emscripten
Which emsdk should I be using?
When running within a web worker, there is no Window object available, and so the call to web_sys::window()
from the instant now()
implementation when using feature wasm-bindgen
results in a panic.
A performance.now()
implementation is available within the global scope available in a web worker (self
), but it is not currently exposed by the web_sys::WorkerGlobalScope
implementation. There is an upstream issue regarding this in wasm-bindgen: rustwasm/wasm-bindgen#1752
A fix is to use js-sys to grab the global() context and access the performance
implementation directly from that (so that it will work in both main thread and web worker contexts). Hopefully at some point in the future wasm-bindgen will provide a supported way of accessing attributes of the WindowOrWorkerGlobalScope
mixin through web-sys that work in both contexts.
I'll work on a PR to implement the immediately available js-sys based fix.
Rust supports 3 WASM targets:
Both wasm32-wasi and wasm32-unknown-emscripten have working Instant
types in libstd, so this crate should only enable the custom Instant
type for wasm32-unknown-unknown.
Having exploited the instant
crate in my toy WebAssembly game that I've been playing around with, I have come to the conclusion that the way that Cargo features are defined for this crate is a little sub-optimal for two reasons:
They're not self documenting. That is to say, if one intends to target wasm32
using wasm-bindgen
and expects that instant
will, therefore, use the JavaScript performance.now()
, one MUST express the wasm-bindgen
feature flag for instant
(similarly, for stdweb
) but the requirement to do so is easy to miss and missing it results in a rather obtuse error related to JavaScript module imports, at runtime.
Cargo feature flags are supposed to be strictly additive. The Cargo Book says: "...enabling a feature should not disable functionality..." The existence of the inaccurate
feature directly contravenes this recommendation and is, for me, an issue because my use-case requires accurate, high-precision performance counters and thus requires me to be sure that inaccurate
will not be set.
I'm happy to help fix this and submit a merge request, improving the use of feature flags, but I am not entirely sure how this should or even could be done, without introducing breaking changes to the crate. My first thought was to handle the first problem with a compilation warning that could be dismissed by setting a feature -- perhaps named js-extern-now
-- indicating that the user did, indeed, expect instant
to find now()
as a JS extern. To handle case 2, perhaps introducing a precise
feature which overrides (or conflicts) with inaccurate
would help but that seems somewhat messy.
dependencies
i am using wasm-bindgen.
Here is my instant's dependency:
instant = {version="0.1.1", features = [ "wasm-bindgen","now" ]}
i got this error 'now' called on an object that does not implement interface Performance in the browser.
The current version on master (https://github.com/sebcrozet/instant/blob/bdd142135d78387a02dfeaa8d6829a057892aca6/LICENSE) appears to diverge in the wording from the online texts I have found of that license.
https://opensource.org/licenses/BSD-3-Clause
https://spdx.org/licenses/BSD-3-Clause.html
In both of the above online sources, in the part where it says:
3. Neither the name of the copyright holder
The version in this repository says "name of the author
" instead of "name of the copyright holder
".
I caught that divergence through a tool I am developing for the legal team at my company. Please bear in mind that I don't have licensing knowledge nor can say if the texts are equivalent, just thought I would warn here about this in case it's not intentional.
Thanks for your time.
Repo to reproduce here: https://github.com/Takashiidobe/rvim/tree/test-building-x86_64-unknown-none
I was trying to compile one of my projects on a generic x86_64 target, which is defined by this target file:
// x86_64-unknown-none.json
{
"llvm-target": "x86_64-unknown-none",
"data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
"linker-flavor": "gcc",
"target-endian": "little",
"target-pointer-width": "64",
"target-c-int-width": "32",
"arch": "x86_64",
"os": "none",
"disable-redzone": true,
"features": "-mmx,-sse,+soft-float",
"executables": true
}
To do that I ran this command inside of my project to build it:
$ cargo build --target ./x86_64-unknown-none.json
Predictably this outputs an error:
Compiling cfg-if v1.0.0
Compiling smallvec v1.7.0
Compiling scopeguard v1.1.0
Compiling bitflags v1.3.2
error[E0463]: can't find crate for `core`
|
= note: the `x86_64-unknown-none-17810034709879873439` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-unknown-none-17810034709879873439`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `scopeguard` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed
So I need to build the stdlib. I did this by swapping to nightly:
$ rustup default nightly
and then running this:
$ cargo build -Z build-std --target ./x86_64-unknown-none.json
which outputs this:
Compiling compiler_builtins v0.1.49
Compiling core v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core)
Compiling libc v0.2.106
Compiling cc v1.0.69
Compiling memchr v2.4.1
Compiling std v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std)
Compiling parking_lot_core v0.8.5
Compiling unwind v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/unwind)
Compiling rustc-std-workspace-core v1.99.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling alloc v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/alloc)
Compiling cfg-if v0.1.10
Compiling adler v0.2.3
Compiling rustc-demangle v0.1.21
Compiling rustc-std-workspace-alloc v1.99.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)
Compiling panic_unwind v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/panic_unwind)
Compiling panic_abort v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/panic_abort)
Compiling gimli v0.25.0
Compiling object v0.26.2
Compiling hashbrown v0.11.0
Compiling std_detect v0.1.5 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/stdarch/crates/std_detect)
Compiling miniz_oxide v0.4.0
Compiling addr2line v0.16.0
Compiling proc_macro v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/proc_macro)
Compiling cfg-if v1.0.0
Compiling scopeguard v1.1.0
Compiling smallvec v1.7.0
Compiling bitflags v1.3.2
Compiling unicode-segmentation v1.8.0
Compiling instant v0.1.12
Compiling lock_api v0.4.5
error[E0658]: use of unstable library feature 'restricted_std'
|
= help: add `#![feature(restricted_std)]` to the crate attributes to enable
For more information about this error, try `rustc --explain E0658`.
error: could not compile `instant` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed
I'm guessing this can be fixed by adding #![feature(restricted_std)]
at the crate root for either this project or a dependent, but I'm not sure how this works in practice.
If nightly support and custom targets aren't a priority, feel free to close.
If this is coming from somewhere else, I can move the issue over there.
Thanks :)
In the README file, also shown on the crates.io page for the crate, there are several erroneous code snippets illustrating how the instant
crate is to be used. A recurring error in these snippets is to call instant::Instant::new()
instead of instant::Instant::now()
-- the former does not compile.
Merge-request incoming in 3...
In one of my projects, I have the necessity of representing an arbitrary instant in time, which include instants before the program start.
The current implementation relies on creating a Duration
from performe.now()
. Because performe.now()
return the time since the creation of the page/web worker, and because Duration
cannot represent negative values, the Wasm version of Instant
can only represent a small range of past instants.
For a tiny program like this:
fn main() {
println!("{:?}", instant::Duration::from_secs(1));
}
when running in debug mode, nothing bad happens, but when I run in release mode, I got this error:
= note: LINK : warning LNK4044: unrecognized option '/s'; ignored
[hidden]\tiny-ffmpeg-gui\target\release\deps\instant-bce189fdb2307e6a.instant.dt1bllbr-cgu.0.rcgu.o : fatal error LNK1107: invalid or corrupt file: cannot read at 0x55C
error: aborting due to previous error
error: could not compile `instant`.
I had another idea for an easy win for this crate: on non-WASM targets, instant
has an optional dependency on an obsolete build of the time
crate (version 0.2) if the now
feature is enabled, all to get the use of time::precise_time_s()
which is just a one-liner, calling std::time::SystemTime
, which is in std
, anyway. time::precise_time_s()
is also deprecated and, presumably because now
adds the extra burden of a dependency on the time
crate, now
is an optional feature. I propose:
Inlining the trivial implementation of time::precise_time_s()
into instant::native::now()
std
: https://docs.rs/time/0.2.27/src/time/lib.rs.html#547-553time
, anyway, and gone in 0.3 and up.time
0.2 dependency.Removing the now
feature, making instant::now()
always available, not optional.
instant
.I'll do it. Just say yea or nay... and, also, whether I should actually whack I did it, anyway. Please review.now
as a feature in Cargo.toml
, under [features]
, or leave it there, having no effect, to avoid introducing a breaking change.
can we have a new release so that we can update rapier and fix dimforge/rapier#207 that way?
see koute/stdweb#427
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.