diff --git a/default.nix b/default.nix index 75e4c40f23c..f7753590433 100644 --- a/default.nix +++ b/default.nix @@ -611,7 +611,7 @@ rec { nixpkgs.rustPlatform.buildRustPackage { name = "ic-wasm"; src = nixpkgs.sources.ic-wasm; - cargoSha256 = "sha256-wukv9q2nBPQM8XKwwzn/O2NfmiQYgiIOIzXRdvya4p8="; + cargoSha256 = "sha256-ydrwvAigwliqRE8/dIeogpERD5sFqRYrQ5N301bOo1Y="; doCheck = false; patchPhase = '' mkdir -p .cargo diff --git a/design/Stable.md b/design/Stable.md index eba0623e275..63a59318256 100644 --- a/design/Stable.md +++ b/design/Stable.md @@ -132,9 +132,9 @@ One way to store it would be in a Motoko-specific custom section; another alternative is as a separate internal asset. In either case, it is probably sufficient to use a textual representation. -Like for the IDL, the System would need to provide a way to extract this information from an on-chain canister. +Like for the IDL, the System would need to provide a way to extract this information from an onchain canister. -For even higher safety, [enhanced orthogonal persistence](OrthogonalPersistence.md) integrates the compatibility check in the runtime system, +For even higher safety, [enhanced orthogonal persistence](OrthogonalPersistence.md) integrates the compatibility check in the runtime system, such that it is atomically guarded and cannot be bypassed e.g. by skipping a `dfx` stable compatibility warning. ## Upgrade Hooks diff --git a/design/WhitePaper.md b/design/WhitePaper.md index bac583de1e4..695018dbf7d 100644 --- a/design/WhitePaper.md +++ b/design/WhitePaper.md @@ -370,7 +370,7 @@ becomes ``` Result.chain(g(1), func(x) { - Result.chain(g(2), + Result.chain(g(2), func(y) { Result.make(f(x, y)) } @@ -621,7 +621,7 @@ Note: the obvious "solution", namely storing closure environments inside the ori #### Upgrades and Memory -The most difficult problem to solve in the programming model of the IC by far is the question of safe and robust upgrades. +The most difficult problem to solve in the programming model of the IC by far is the question of safe and robust upgrades. For this purpose, Motoko implements powerful and safe persistence, see [Enhanced Orthogonal Persistence](OrthogonalPersistence.md). #### Upgrades and Methods @@ -666,13 +666,13 @@ Unfortunately, though, this is a more difficult problem than linking modules com Wasm component model offers a solution for secure intra-canister language interop on the IC. -#### On-chain Linking +#### Onchain Linking [Separate compilation](#separate-compilation) avoids the need to _compile_ applications in a monolitic manner, but it does not prevent the need to _deploy_ them in monolithic form. No matter how large an application and how small a change, upgrading always requires redeploying the entire code. -Also, it is not possible to share modules on-chain between multiple applications. For features like [unicode support](#text), it would be desirable if respective modules of the language runtime would only have to be installed on the chain once and could be shared between applications. +Also, it is not possible to share modules onchain between multiple applications. For features like [unicode support](#text), it would be desirable if respective modules of the language runtime would only have to be installed on the chain once and could be shared between applications. -Supporting this would require a new mechanism in the IC that allows canisters to consist of more than just a single Wasm module, and linking these modules _dynamically_, "on-chain", reminiscent of dynamic linking in conventional operating systems. Unfortunately, there currently isn't any mechanism planned for the IC to support that. +Supporting this would require a new mechanism in the IC that allows canisters to consist of more than just a single Wasm module, and linking these modules _dynamically_, "onchain", reminiscent of dynamic linking in conventional operating systems. Unfortunately, there currently isn't any mechanism planned for the IC to support that. ### Platform Support diff --git a/doc/md/getting-started/examples.md b/doc/md/getting-started/examples.md index 242e04b5461..c22bd82875f 100644 --- a/doc/md/getting-started/examples.md +++ b/doc/md/getting-started/examples.md @@ -60,7 +60,7 @@ Want to get started building with Motoko? Check out some of these sample project - [Appic](https://github.com/Appic-Solutions/Auto_Investment): Automatically by and sell tokens at a specific interval or time. -- [ICDex](https://github.com/iclighthouse/ICDex): An on-chain orderbook decentralized exchange written in Motoko. +- [ICDex](https://github.com/iclighthouse/ICDex): An onchain orderbook decentralized exchange written in Motoko. - [icrc7_motoko](https://github.com/noku-team/icrc7_motoko) and - [icrc7-mo](https://github.com/PanIndustrial-Org/icrc7.mo): Motoko implementations of the ICRC-7 NFT standard. diff --git a/doc/md/motoko-packages/cryptography.md b/doc/md/motoko-packages/cryptography.md index 1541c95651d..147b873e3d9 100644 --- a/doc/md/motoko-packages/cryptography.md +++ b/doc/md/motoko-packages/cryptography.md @@ -6,7 +6,7 @@ sidebar_position: 1 ## Mops packages for cryptography -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for cryptography functions: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for cryptography functions: - [`ic-certification`](https://mops.one/ic-certification): Canister signatures and certifications. diff --git a/doc/md/motoko-packages/data-structures.md b/doc/md/motoko-packages/data-structures.md index 37254996fb8..3084a281cb8 100644 --- a/doc/md/motoko-packages/data-structures.md +++ b/doc/md/motoko-packages/data-structures.md @@ -6,7 +6,7 @@ sidebar_position: 2 ## Mops packages for data structures -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for data structure implementations: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for data structure implementations: - [`augmented-btrees`](https://mops.one/augmented-btrees): An implementation of BTree variants, most notable the B+Tree. @@ -40,7 +40,7 @@ sidebar_position: 2 - [`stable-rbtree`](https://mops.one/stable-rbtree): Stable RBtree. -- [`stable-trie`](https://mops.one/stable-trie): Stable trie. +- [`stable-trie`](https://mops.one/stable-trie): Stable trie. - [`swb`](https://mops.one/swb): Sliding window buffers featuring random access functionalities. diff --git a/doc/md/motoko-packages/databases.md b/doc/md/motoko-packages/databases.md index 4765d9b4b7a..6dddd64c176 100644 --- a/doc/md/motoko-packages/databases.md +++ b/doc/md/motoko-packages/databases.md @@ -6,7 +6,7 @@ sidebar_position: 3 ## Mops packages for databases -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for database implementations: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for database implementations: - [`candb`](https://mops.one/candb): A flexible, performant, and scalable non-relational, multi-canister data store built for ICP. diff --git a/doc/md/motoko-packages/encoding.md b/doc/md/motoko-packages/encoding.md index 1e4c74af311..c46dc2fd030 100644 --- a/doc/md/motoko-packages/encoding.md +++ b/doc/md/motoko-packages/encoding.md @@ -6,7 +6,7 @@ sidebar_position: 4 ## Mops packages for encoding -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for encoding: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for encoding: - [`candid`](https://mops.one/candid): Encoding and decode Candid bytes. diff --git a/doc/md/motoko-packages/http.md b/doc/md/motoko-packages/http.md index e9744f6889e..4c3551b86a7 100644 --- a/doc/md/motoko-packages/http.md +++ b/doc/md/motoko-packages/http.md @@ -6,7 +6,7 @@ sidebar_position: 5 ## Mops packages for HTTP -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for HTTP and web functionalities: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for HTTP and web functionalities: - [`assets`](https://mops.one/assets): A library for adding asset canister functionality for your canister. diff --git a/doc/md/motoko-packages/icrc.md b/doc/md/motoko-packages/icrc.md index bbfb560d259..dca3dafd3d5 100644 --- a/doc/md/motoko-packages/icrc.md +++ b/doc/md/motoko-packages/icrc.md @@ -6,7 +6,7 @@ sidebar_position: 5 ## Mops packages for ICRC -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for ICRC tokens: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for ICRC tokens: - [`account`](https://mops.one/account): Implementation of ICRC-1 and ICRC-7 accounts. diff --git a/doc/md/motoko-packages/types-interfaces.md b/doc/md/motoko-packages/types-interfaces.md index 77da7546296..4aa7c123868 100644 --- a/doc/md/motoko-packages/types-interfaces.md +++ b/doc/md/motoko-packages/types-interfaces.md @@ -6,7 +6,7 @@ sidebar_position: 6 ## Mops packages for types and interfaces -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for types and interfaces: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for types and interfaces: - [`canistergeek`](https://mops.one/canistergeek): An open-source tool for tracking your project's cycles, memory status and logs. diff --git a/doc/md/motoko-packages/utilities.md b/doc/md/motoko-packages/utilities.md index d899cba0e0f..417c01bc8a0 100644 --- a/doc/md/motoko-packages/utilities.md +++ b/doc/md/motoko-packages/utilities.md @@ -6,7 +6,7 @@ sidebar_position: 7 ## Mops packages for utility functions -[Mops](https://mops.one/) is an on-chain package manager for Motoko. Here are some Mops packages for utility functions: +[Mops](https://mops.one/) is an onchain package manager for Motoko. Here are some Mops packages for utility functions: - [`backup`](https://mops.one/backup): Library for backup restore. @@ -62,7 +62,7 @@ sidebar_position: 7 - [`xtended-numbers`](https://mops.one/xtended-numbers): Extended functionality for number types, such as byte encoding. -- [`xtended-random`](https://mops.one/xtended-random): Extended library for random number generation. +- [`xtended-random`](https://mops.one/xtended-random): Extended library for random number generation. - [`xtended-text`](https://mops.one/xtended-text): Text manipulation. diff --git a/doc/md/writing-motoko/randomness.md b/doc/md/writing-motoko/randomness.md index 1bcbdbe987f..99009739c90 100644 --- a/doc/md/writing-motoko/randomness.md +++ b/doc/md/writing-motoko/randomness.md @@ -103,7 +103,7 @@ View this example on the [Motoko Playground](https://play.motoko.org/?tag=267523 :::tip The above solution directly uses the finite blob of 256-random bits returned by the management canister. Class `Random.Finite` uses this finite supply of bits to generate at most 256 coin flips, returning `null` when no more flips are possible. - + When its current supply of bits is exhausted, the code asynchronously requests another 256-bit blob to continue the shuffle. A more efficient, and equally robust approach would be to use the first 256-bit blob as a seed to a sequential pseudo random number generator, generating an infinite, lazy stream of bits, and then complete the shuffle with a single round of communication. ::: @@ -127,7 +127,7 @@ actor { ## Resources -- [On-chain randomness](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/advanced-features/randomness) +- [Onchain randomness](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/advanced-features/randomness) - [Random base library documentation](../base/Random.md) diff --git a/nix/sources.json b/nix/sources.json index db0ab733ddf..9594006d9f7 100644 --- a/nix/sources.json +++ b/nix/sources.json @@ -51,10 +51,10 @@ "homepage": null, "owner": "dfinity", "repo": "ic-wasm", - "rev": "9f3c746ecedc644f0e81b74297fcdda716f2d06e", - "sha256": "1c2zh6v270bp38ayc2q97q6s4l98zyac1ad8m74xbm5mrwf9737a", + "rev": "12f4cb76d0861aa7f72cea5741656213b4ef723b", + "sha256": "1ayxzgh2bvmj4c4yl9q20fmr00kyil6475lsfcwrvslg34s3lqlv", "type": "tarball", - "url": "https://github.com/dfinity/ic-wasm/archive/9f3c746ecedc644f0e81b74297fcdda716f2d06e.tar.gz", + "url": "https://github.com/dfinity/ic-wasm/archive/12f4cb76d0861aa7f72cea5741656213b4ef723b.tar.gz", "url_template": "https://github.com///archive/.tar.gz" }, "libtommath": { diff --git a/src/mo_values/numerics.ml b/src/mo_values/numerics.ml index cd540fe3db0..45ae04ced67 100644 --- a/src/mo_values/numerics.ml +++ b/src/mo_values/numerics.ml @@ -41,7 +41,7 @@ let bigint_of_double (f : Wasm.F64.t) : Big_int.big_int = (* Fraction part of IEEE 754 double, 52 bits from the float, with an implicit 1 at the 53rd bit *) - let frac = Int64.(logor (shift_right_logical (shift_left bits 12) 12) (shift_left (of_int 1) 52)) in + let frac = Int64.(logor (shift_right_logical (shift_left bits 12) 12) (shift_left one 52)) in if Int64.(equal exp bits_11) then (* Exponent is fully set: NaN or inf *) @@ -55,7 +55,7 @@ let bigint_of_double (f : Wasm.F64.t) : Big_int.big_int = let a = Big_int.big_int_of_int64 frac in - let a = if Int64.(compare exp (of_int 0)) < 0 then + let a = if Int64.(compare exp zero) < 0 then (* Exponent < 0, shift right *) Big_int.(shift_right_big_int a (- (Int64.to_int exp))) else @@ -64,7 +64,7 @@ let bigint_of_double (f : Wasm.F64.t) : Big_int.big_int = in (* Negate the number if sign bit is set (double is negative) *) - if Int64.shift_right_logical bits 63 = Int64.of_int 1 && a <> Big_int.zero_big_int then + if Int64.(shift_right_logical bits 63 = one) then Big_int.minus_big_int a else a diff --git a/test/run/issue-base653.mo b/test/run/issue-base653.mo new file mode 100644 index 00000000000..0f15a0d9c25 --- /dev/null +++ b/test/run/issue-base653.mo @@ -0,0 +1,4 @@ +import { floatCopySign; floatToInt64 } = "mo:⛔"; + +assert 0 == floatToInt64(-0.5); +assert 0 == floatToInt64(floatCopySign(0.0, -1.0));