You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: contract-dev/gas.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -137,7 +137,7 @@ let sizeMsg = computeDataSize(
137
137
);
138
138
139
139
let fwdFee = getForwardFee(
140
-
sizeMsg.cells - 1,
140
+
sizeMsg.cells - 1,
141
141
sizeMsg.bits - msg.toCell().bits(),
142
142
isAccountInMasterchain
143
143
);
@@ -157,7 +157,7 @@ In Tolk, both computations can be performed with a call to `msg.send()` with mod
157
157
158
158
If the size of the outgoing message is bounded by the size of the incoming message, we can estimate the forward fee of an outgoing message to be no larger than the forward fee of the incoming message, that was already computed by TVM. Thus, we don't have to calculate it again. Note that this estimation is correct only for a contract system in the same workchain, because gas prices depend on the workchain.
159
159
160
-
```tolk
160
+
```tolk title="Tolk"
161
161
fun onInternalMessage(in: InMessage) {
162
162
val fwdFee = in.originalForwardFee;
163
163
// ...
@@ -170,7 +170,7 @@ Assume the contract receives a message with an unknown size and forwards it furt
170
170
171
171
For this case, in Tolk, there is a function `calculateForwardFeeWithoutLumpPrice()`. In TVM, it's implemented as [`GETFORWARDFEESIMPLE`](/tvm/instructions#f83c-getforwardfeesimple). This function does not take `lumpPrice` into account.
@@ -189,8 +189,8 @@ fun onInternalMessage(in: InMessage) {
189
189
}
190
190
}
191
191
192
-
else => {
193
-
// just accepted tons
192
+
else => {
193
+
// just accepted tons
194
194
}
195
195
}
196
196
}
@@ -244,9 +244,9 @@ The key mechanism: `setTvmRegisterC3()` switches the code register so the migrat
244
244
245
245
The example shows a counter contract that adds a metadata field through a hot upgrade. The storage structure changes: the original version stores only `adminAddress` and `counter`. The new version adds `metadata` and reorders fields.
246
246
247
-
Original contract (`main.tolk`):
247
+
Original contract:
248
248
249
-
```tolk expandable
249
+
```tolktitle="main.tolk" expandable
250
250
import "@stdlib/tvm-lowlevel"
251
251
252
252
struct (0x00001111) HotUpgrade {
@@ -260,7 +260,7 @@ type AllowedMessages =
260
260
| HotUpgrade
261
261
| IncreaseCounter
262
262
263
-
// migration function must have method_id
263
+
// migration function must have method_id
264
264
@method_id(2121)
265
265
fun hotUpgradeData(additionalData: cell?) { return null; }
266
266
@@ -273,21 +273,21 @@ fun onInternalMessage(in: InMessage) {
Copy file name to clipboardExpand all lines: foundations/addresses/derive.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ The `StateInit` is distinct from the account's current state. It is the initial
15
15
16
16
If it's known how to compose the contract's initial `code` and `data`, it's enough to follow the general algorithm mentioned above as is. Code and data form a `StateInit`, and the [workchain](/foundations/addresses/overview#workchain-id) is usually hardcoded. Below is one of the most common patterns when `code` is a constant cell known in advance and `data` is composed at runtime.
17
17
18
-
```tolk expandable
18
+
```tolktitle="Tolk" expandable
19
19
// Compose an address builder
20
20
fun calculateAddress(
21
21
code: cell,
@@ -63,7 +63,7 @@ The `calculateAddress` function uses the [`AutoDeployAddress`](/languages/tolk/f
63
63
64
64
When working with the [contract sharding](/contract-dev/contract-sharding) pattern, child contracts usually have a `StateInit` that depends on the parent. In the example below, the dependence is implemented by adding the parent address to the child `StateInit`. The same logic from the [simple on-chain](#on-chain-simple) case works here, and only `getData` has to be changed.
65
65
66
-
```tolk expandable
66
+
```tolktitle="Tolk" expandable
67
67
// Compose an address builder using the AutoDeployAddress built-in.
68
68
fun calculateAddress(code: cell, data: cell, workchain: int): builder {
69
69
val addr = AutoDeployAddress {
@@ -108,7 +108,7 @@ A [vanity contract](/contract-dev/vanity) allows _customizing_ the address of a
108
108
109
109
In this case, there is no real correlation between the data the contract holds and its final address. So there is no way to actually _derive_ the address. The only option left is to define a constant with the actual address that is obtained in advance.
Copy file name to clipboardExpand all lines: standard/tokens/nft/deploy.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -169,7 +169,7 @@ To deploy an item from a smart contract, send a message from the contract to the
169
169
170
170
The following example is a minimal smart contract that only implements the item deployment logic. In real deployments, this is integrated into a larger flow.
171
171
172
-
```tolk
172
+
```tolk title="Tolk"
173
173
// SnakeString describes a (potentially long) string inside a cell;
174
174
// short strings are stored as-is, like "my-picture.png";
175
175
// long strings are nested refs, like "xxxx".ref("yyyy".ref("zzzz"))
0 commit comments