Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/build-on-btc/btc-dev-env.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ To develop Bitcoin applications to be deployed on ICP, your local developer envi

- The Rust toolchain for installing Rust packages and compiling Rust code.

- The Motoko compiler and base library for writing and compiling Motoko code.
- The Motoko compiler and standard library (core) for writing and compiling Motoko code.

- The IC SDK for creating, deploying, and managing smart contracts.

Expand All @@ -36,9 +36,9 @@ Before developing BTC applications in Rust, you will need to install the Rust to
- [The Rust programming language.](https://www.rust-lang.org/tools/install)
- [The `cargo` package manager.](https://doc.rust-lang.org/cargo/getting-started/installation.html)

### Motoko compiler and base library
### Motoko compiler and standard library (core)

The Motoko compiler (`moc`) and base library are included in the IC SDK installation as described below. Alternatively, you can install them on their own through the [Motoko release binaries](https://github.com/dfinity/motoko/releases).
The Motoko compiler (`moc`) and the core library (the standard library for Motoko) are included in the IC SDK installation as described below. Alternatively, you can install them on their own through the [Motoko release binaries](https://github.com/dfinity/motoko/releases).

### IC SDK

Expand Down
2 changes: 1 addition & 1 deletion docs/building-apps/canister-management/topping-up.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ Canisters can check their balance programmatically.
<AdornedTabs groupId="language">
<TabItem value="motoko" label="Motoko" default>

Motoko canisters can use the [ExperimentalCycles library](/motoko/base/ExperimentalCycles) to interact with cycles.
Motoko canisters can use the [Cycles library](/motoko/core/Cycles) to interact with cycles.

</TabItem>

Expand Down
2 changes: 1 addition & 1 deletion docs/building-apps/essentials/gas-cost.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -184,5 +184,5 @@ Common errors related to cycles include:
- [Cycles management services](/building-apps/canister-management/topping-up#using-a-cycles-management-service).

### Counting instructions
- [Motoko function `countInstructions`](/motoko/base/ExperimentalInternetComputer#function-countinstructions).
- [Motoko function `countInstructions`](/motoko/core/InternetComputer#function-countinstructions).
- [IC interface specification](/references/ic-interface-spec#system-api-performance-counter).
4 changes: 2 additions & 2 deletions docs/building-apps/network-features/randomness.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ import { BetaChip } from "/src/components/Chip/BetaChip";

<MarkdownChipRow labels={["Advanced", "Concept"]} />

The Internet Computer provides a secure and verifiable way to generate random numbers directly within canisters. This functionality is exposed through the [raw_rand](/references/ic-interface-spec#ic-raw_rand) method offered by the [management canister](/references/system-canisters/management-canister) and the [Motoko Random module](/motoko/base/Random).
The Internet Computer provides a secure and verifiable way to generate random numbers directly within canisters. This functionality is exposed through the [raw_rand](/references/ic-interface-spec#ic-raw_rand) method offered by the [management canister](/references/system-canisters/management-canister) and the [Motoko Random module](/motoko/core/Random).

The method takes no input and returns 32 pseudo-random bytes to the caller.

Expand Down Expand Up @@ -44,7 +44,7 @@ actor {
};
```

In addition to the `raw_rand` method, Motoko offers a [Random module](/motoko/base/Random) for generating random numbers.
In addition to the `raw_rand` method, Motoko offers a [Random module](/motoko/core/Random) for generating random numbers.

</TabItem>

Expand Down
6 changes: 3 additions & 3 deletions docs/building-apps/network-features/time-and-timestamps.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -133,11 +133,11 @@ fn to_date(timestamp: &u64) -> OffsetDateTime {
For some applications, it may be useful to calculate the time that has passed between two timestamps. Below is an example canister written in Motoko that demonstrates how to use [timers](periodic-tasks-timers.mdx) to generate two timestamps, then creates a function that can be used to calculate the difference:

```motoko no-repl
import Debug "mo:base/Debug";
import { setTimer; recurringTimer } = "mo:base/Timer";
import Debug "mo:core/Debug";
import { setTimer; recurringTimer } = "mo:core/Timer";
import Time "mo:time/time";
import DateTime "mo:datetime/DateTime";
import Int "mo:base/Int";
import Int "mo:core/Int";

actor Alarm {

Expand Down
2 changes: 1 addition & 1 deletion docs/building-apps/security/canister-upgrades.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,6 @@ Using the Rust CDK, the recurring timer is also lost on upgrade as explained in

- In Motoko canisters, global timers should be set up in the actor initializer for canister installation or reinstallation. Canister-wide timers should be set in the `post_upgrade` hook for upgrades, as timers do not survive upgrades and must be explicitly set up thereafter.

- See the Motoko documentation on [recurringTimer](/motoko/base/Timer#function-recurringtimer).
- See the Motoko documentation on [recurringTimer](/motoko/core/Timer#function-recurringtimer).

- See the Rust documentation on [set_timer_interval](https://docs.rs/ic-cdk/0.6.9/ic_cdk/timer/fn.set_timer_interval.html).
2 changes: 1 addition & 1 deletion docs/building-apps/test/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ There are three types of testing:

Unit testing refers to testing a single function or component of a piece of code by itself, thus testing a single *unit* of the code. Unit testing does not take into consideration how the single unit functions with other components of the application. The scope of unit testing is more narrow compared to other types of testing and is designed to catch bugs or errors that may occur for each individual unit of the application's code.

In Motoko, the [base library](https://github.com/dfinity/motoko-base/tree/master/test) contains files that can be used for unit testing. Most testing files utilize the Motoko Matchers test library to provide testing functionality. Motoko Matchers also includes a package for executing unit tests within canisters.
In Motoko, the [core library](https://github.com/caffeinelabs/motoko-core) (the recommended standard library) contains modules and patterns used in unit testing. Many projects also use the Motoko Matchers test library for testing functionality. Motoko Matchers includes a package for executing unit tests within canisters.

For tests that use large datasets or have long-running test batches, Motoko also provides the [BigTest library](https://github.com/matthewhammer/motoko-bigtest).

Expand Down
2 changes: 1 addition & 1 deletion docs/references/execution-errors.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -253,7 +253,7 @@ An example of this error is:
  Canister violated contract: Size of method_name 22000 exceeds the allowed limit of 20000.
```

Method names are generally short (similar to function names), so it is likely a bug in the calling canister that creates a name that is too long. Consider running the canister locally and using debug printing ([using `Debug` in Motoko](/motoko/base/Debug/) or [`println!` in Rust](https://docs.rs/ic-cdk/latest/ic_cdk/macro.println.html)) to verify that the correct method name is being called.
Method names are generally short (similar to function names), so it is likely a bug in the calling canister that creates a name that is too long. Consider running the canister locally and using debug printing ([using `Debug` in Motoko](/motoko/core/Debug/) or [`println!` in Rust](https://docs.rs/ic-cdk/latest/ic_cdk/macro.println.html)) to verify that the correct method name is being called.


### Canister made a call with too large a payload
Expand Down
22 changes: 12 additions & 10 deletions docs/tutorials/developer-liftoff/level-1/1.1-motoko-lvl1.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -61,20 +61,22 @@ let z = do {

The variable `z` now stores the result value of `3` and can be called by additional methods.

Next, let's look at using and importing the base Motoko library.
Next, let's look at using and importing the Motoko standard library.

## Using the base library
## Using the core library

Motoko is designed to minimize built-in types and operations, so whenever possible, the Motoko base library provides the necessary operations and types for developers to utilize.
The recommended standard library for Motoko is **core** ([mops.one/core](https://mops.one/core), [changelog](https://github.com/caffeinelabs/motoko-core/blob/main/Changelog.md)). The older **base** library is still supported; see the [base-to-core migration guide](https://docs.internetcomputer.org/motoko/base-core-migration) when moving to core.

The base library includes a selection of modules that focus on the core features of Motoko. The base library is still under development and is expected to grow in size as additional features are developed.
Motoko is designed to minimize built-in types and operations, so whenever possible, the Motoko core library provides the necessary operations and types for developers to utilize.

To import the base library, the `import` keyword can be used at the start of your Motoko code file. After the `import` keyword, you need to provide a **local module name** and a **file path** that the import declaration can use to locate the imported module.
The core library includes a selection of modules that focus on the essential features of Motoko and is the actively maintained standard library.

To import the core library, the `import` keyword can be used at the start of your Motoko code file. After the `import` keyword, you need to provide a **local module name** and a **file path** that the import declaration can use to locate the imported module.

For example, to import a local module named 'Debug,' you can use the following import statement:

```motoko no-repl no-repl
import Debug "mo:base/Debug";
import Debug "mo:core/Debug";
```

Then, to use this imported library, you can call the module with a line of code such as:
Expand All @@ -83,15 +85,15 @@ Then, to use this imported library, you can call the module with a line of code
Debug.print("Hello world!");
```

In this demonstration, you import Motoko code, indicated by the `mo:` prefix, then specify the `base/` path, indicating that you are using the base library, followed by the module's file name, `Debug.mo`. Note that the `.mo` extension is not included in the import statement.
In this demonstration, you import Motoko code, indicated by the `mo:` prefix, then specify the `core/` path, indicating that you are using the core library, followed by the module's file name, `Debug.mo`. Note that the `.mo` extension is not included in the import statement.

Additionally, you can import Motoko code and other modules using their relative paths. For example, if you have a Motoko program named `types.mo` that you'd like to import into your Motoko file, you can use the following import declaration:

```motoko no-repl no-repl
import Types "./types";
```

In this import declaration, you don't need to include the `mo:` prefix or the `base/` path, since you are importing a module from a local relative path rather than the base library.
In this import declaration, you don't need to include the `mo:` prefix or the `core/` path, since you are importing a module from a local relative path rather than the core library.

## Declarations and expressions

Expand Down Expand Up @@ -241,7 +243,7 @@ Additionally, Motoko supports the following user-defined non-primitive value for
Earlier, recall that you printed a value using the imported `Debug` library:

```motoko no-repl
import Debug "mo:base/Debug";
import Debug "mo:core/Debug";
Debug.print("hello world");
```

Expand All @@ -254,7 +256,7 @@ Next, let's look at transforming a Motoko value into a human-readable text strin
The `debug_show` primitive value permits converting a large class of values into type `Text` values. For example, let's convert three values of type `Text`, `Nat`, and `Text` into human-readable text:

```motoko no-repl
import Debug "mo:base/Debug";
import Debug "mo:core/Debug";
Debug.print(debug_show(("hello", 42, "world")))
```

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ This project can be opened in [ICP Ninja](https://icp.ninja/s/JwL2z) or you can
### Defining a stable variable

```motoko title="src/stable_storage_example_backend/main.mo"
import Nat "mo:base/Nat";
import Nat "mo:core/Nat";

actor Counter {

Expand Down Expand Up @@ -108,7 +108,7 @@ dfx canister stop stable_storage_example_backend
Then, let's alter the code of your canister. To keep things simple, you're going to change the counter increment value from '1' to '3'. Your altered code looks like this:

```motoko title="src/stable_storage_example_backend/main.mo"
import Nat "mo:base/Nat";
import Nat "mo:core/Nat";

actor Counter {

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ The amount of security your dapp needs depends on your dapp's use case and funct
Queries are defined by the function modifier `query` in Motoko. Below is a simple query call used with a query the current time from the network:

```motoko
import Time "mo:base/Time";
import Time "mo:core/Time";

actor QueryCall {

Expand All @@ -80,8 +80,8 @@ In comparison to query calls, update calls have the opposite trade-off of perfor
Update calls are not defined with a function modifier in Motoko like query calls are. Below is a simple update call that counts the number of characters within the inputted string, updates the value of the variable `size`, then returns a `true` or `false` value if that number of characters is divisible by 2.

```motoko
import Text "mo:base/Text";
import Bool "mo:base/Bool";
import Text "mo:core/Text";
import Bool "mo:core/Bool";

actor countCharacters {
    public func test(text : Text) : async Bool {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ There are three primary types of testing:

## Motoko unit testing

The Motoko base library contains a series of test files that can be used for unit testing, including tests for individual types, such as `Text`, `Array`, `Func`, etc. [Check out the full library of test files](https://github.com/dfinity/motoko-base/tree/master/test).
The Motoko core library (the recommended standard library) contains test files and examples that can be used for unit testing, including tests for types such as `Text`, `Array`, `Func`, etc. [Check out the motoko-core repository](https://github.com/caffeinelabs/motoko-core) for the library and its tests.

Many of these test files import a library called Motoko Matchers, which contains several packages that can be imported and used to provide testing functionalities.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -149,6 +149,10 @@ In this example, the following happens:

Want to learn more about actor classes? Take a look at the documentation on [actor class management](/motoko/language-manual#actor-class-management) for more information.

:::info
The Buckets and Map samples above may use the older **base** library. For new projects, prefer the [core library](https://mops.one/core) and see the [base-to-core migration guide](https://docs.internetcomputer.org/motoko/base-core-migration) when moving to core.
:::

## Using multiple actors

Only one actor can be defined in a Motoko file, and a single actor is always compiled into a single canister. To create multiple actors, you'll need to create multiple Motoko files and build multiple canisters.
Expand Down
26 changes: 11 additions & 15 deletions docs/tutorials/developer-liftoff/level-3/3.1-package-managers.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ ICP Ninja supports adding Mops packages to projects. For example, open the [Flyi
# Motoko dependencies (https://mops.one/)

[dependencies]
base = "0.14.1"
core = "0.0.0" # Check latest version at https://mops.one/core. Prefer core over base for new projects.
```

Simply edit this file with any Mops packages you'd like to use within your project. For example:
Expand Down Expand Up @@ -105,23 +105,19 @@ You will also be prompted to choose if you'd like to use a GitHub workflow. This

### Adding packages to `mops.toml`.

To install a package with Mops, you need to specify the package in the `mops.toml` file within your project. To add a package to this file, you can use the command `maps add` and then the package name:
To install a package with Mops, you need to specify the package in the `mops.toml` file within your project. To add a package to this file, you can use the command `mops add` and then the package name. For the recommended standard library (core):

```bash
mops add base
mops add core
```

Or, you can add packages directly from GitHub by specifying the repository's URL:

```bash
mops add https://github.com/dfinity/motoko-base
mops add https://github.com/caffeinelabs/motoko-core
```

You can also specify the branch, commit hash, or tag by adding `#<branch/tag/hash>`:

```bash
mops add https://github.com/dfinity/motoko-base#moc-0.9.1
```
You can also specify the branch, commit hash, or tag by adding `#<branch/tag/hash>`. For existing projects using the older base library, see the [base-to-core migration guide](https://docs.internetcomputer.org/motoko/base-core-migration).

If you have a locally stored package, you can put the source files inside your project's directory and then add them by specifying the path:

Expand All @@ -148,15 +144,15 @@ If you develop a package that you'd like to publish so other developers can use
Once a package has been installed, you can import it into your Motoko code file using the line `import PackageName "mo:<package_name>";`, such as:

```motoko title="src/character_count/main.mo"
import Text "mo:base/Text";
import Bool "mo:base/Bool";
import Text "mo:core/Text";
import Bool "mo:core/Bool";

actor characterCount {

    public func test(text: Text) : async Bool {
        let size = Text.size(text);
        return size % 2 == 0;
    };
public func test(text: Text) : async Bool {
let size = Text.size(text);
return size % 2 == 0;
};
};
```

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ Developers can certify their canister's data and assets in two ways:

### Certified data Motoko module

The Motoko base library includes a module called `CertifiedData` that contains the following system API methods for certified data:
The Motoko core library includes a module called `CertifiedData` that contains the following system API methods for certified data:

```motoko no-repl
let set : (data : Blob) -> ()
Expand Down
Loading