Merge branch 'master' into jt/add-stable-trie

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

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

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

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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)
 

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/<owner>/<repo>/archive/<rev>.tar.gz"
     },
     "libtommath": {

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

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));