Skip to content

Commit abc237d

Browse files
authored
chore: add an appropriate title to all Tolk code blocks outside of /languages/tolk (#1480)
1 parent 69d2571 commit abc237d

File tree

8 files changed

+35
-35
lines changed

8 files changed

+35
-35
lines changed

contract-dev/gas.mdx

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -137,7 +137,7 @@ let sizeMsg = computeDataSize(
137137
);
138138
139139
let fwdFee = getForwardFee(
140-
sizeMsg.cells - 1,
140+
sizeMsg.cells - 1,
141141
sizeMsg.bits - msg.toCell().bits(),
142142
isAccountInMasterchain
143143
);
@@ -157,7 +157,7 @@ In Tolk, both computations can be performed with a call to `msg.send()` with mod
157157

158158
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.
159159

160-
```tolk
160+
```tolk title="Tolk"
161161
fun onInternalMessage(in: InMessage) {
162162
val fwdFee = in.originalForwardFee;
163163
// ...
@@ -170,7 +170,7 @@ Assume the contract receives a message with an unknown size and forwards it furt
170170

171171
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.
172172

173-
```tolk
173+
```tolk title="Tolk"
174174
fun onInternalMessage(in: InMessage) {
175175
val origFwdFee = in.originalForwardFee;
176176

contract-dev/upgrades.mdx

Lines changed: 23 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ If there's not enough Toncoin to execute action phase with the code update, but
5252

5353
### Example
5454

55-
```tolk expandable
55+
```tolk title="Tolk" expandable
5656
struct (0x1111) UpgradeContract {
5757
data: cell?
5858
code: cell?
@@ -77,8 +77,8 @@ fun onInternalMessage(in: InMessage) {
7777
}
7878
}
7979
80-
else => {
81-
// just accept TON
80+
else => {
81+
// just accept TON
8282
}
8383
}
8484
}
@@ -116,7 +116,7 @@ The admin can also send `RejectUpgrade` at any time to cancel a pending upgrade.
116116

117117
### Example
118118

119-
```tolk expandable
119+
```tolk title="Tolk" expandable
120120
struct UpgradeContract {
121121
data: cell?
122122
code: cell?
@@ -171,7 +171,7 @@ fun onInternalMessage(in: InMessage) {
171171
172172
ApproveUpgrade => {
173173
var storage = lazy Storage.load();
174-
174+
175175
assert (in.senderAddress == storage.adminAddress) throw 100;
176176
assert (storage.CurrentRequest != null) throw 301;
177177
assert (storage.CurrentRequest!.timestamp + storage.timeout < blockchain.now()) throw 302;
@@ -189,8 +189,8 @@ fun onInternalMessage(in: InMessage) {
189189
}
190190
}
191191
192-
else => {
193-
// just accepted tons
192+
else => {
193+
// just accepted tons
194194
}
195195
}
196196
}
@@ -244,9 +244,9 @@ The key mechanism: `setTvmRegisterC3()` switches the code register so the migrat
244244

245245
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.
246246

247-
Original contract (`main.tolk`):
247+
Original contract:
248248

249-
```tolk expandable
249+
```tolk title="main.tolk" expandable
250250
import "@stdlib/tvm-lowlevel"
251251
252252
struct (0x00001111) HotUpgrade {
@@ -260,7 +260,7 @@ type AllowedMessages =
260260
| HotUpgrade
261261
| IncreaseCounter
262262
263-
// migration function must have method_id
263+
// migration function must have method_id
264264
@method_id(2121)
265265
fun hotUpgradeData(additionalData: cell?) { return null; }
266266
@@ -273,21 +273,21 @@ fun onInternalMessage(in: InMessage) {
273273
HotUpgrade => {
274274
var storage = lazy Storage.load();
275275
assert (in.senderAddress == storage.adminAddress) throw 1111;
276-
276+
277277
contract.setCodePostponed(msg.code);
278278
279279
setTvmRegisterC3(transformSliceToContinuation(msg.code.beginParse()));
280280
hotUpgradeData(msg.additionalData);
281-
}
281+
}
282282
283283
IncreaseCounter => {
284284
var storage = lazy Storage.load();
285285
storage.counter += 1;
286286
storage.save();
287287
}
288288
289-
else => {
290-
// just accept TON
289+
else => {
290+
// just accept TON
291291
}
292292
}
293293
}
@@ -317,9 +317,9 @@ The `hotUpgradeData()` function in the original code returns `null` because it d
317317
1. `setTvmRegisterC3()` switches register C3 to the new code immediately
318318
1. `hotUpgradeData(msg.additionalData)` is called and runs with the new code
319319

320-
New contract with migration (`new.tolk`):
320+
New contract with migration:
321321

322-
```tolk
322+
```tolk title="new.tolk"
323323
import "@stdlib/tvm-lowlevel"
324324
325325
struct (0x00001111) HotUpgrade {
@@ -333,13 +333,13 @@ type AllowedMessages =
333333
| HotUpgrade
334334
| IncreaseCounter
335335
336-
// migration function must have method_id
336+
// migration function must have method_id
337337
@method_id(2121)
338-
fun hotUpgradeData(additionalData: cell?) {
338+
fun hotUpgradeData(additionalData: cell?) {
339339
var oldStorage = lazy oldStorage.load();
340340
341341
assert (additionalData != null) throw 1112;
342-
342+
343343
var storage = Storage {
344344
adminAddress: oldStorage.adminAddress,
345345
counter: oldStorage.counter,
@@ -368,21 +368,21 @@ fun onInternalMessage(in: InMessage) {
368368
HotUpgrade => {
369369
var storage = lazy Storage.load();
370370
assert (in.senderAddress == storage.adminAddress) throw 1111;
371-
371+
372372
contract.setCodePostponed(msg.code);
373373
374374
setTvmRegisterC3(transformSliceToContinuation(msg.code.beginParse()));
375375
hotUpgradeData(msg.additionalData);
376-
}
376+
}
377377
378378
IncreaseCounter => {
379379
var storage = lazy Storage.load();
380380
storage.counter += 1;
381381
storage.save();
382382
}
383383
384-
else => {
385-
// just accept TON
384+
else => {
385+
// just accept TON
386386
}
387387
}
388388
}

ecosystem/api/price.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ take_pool_state#bddd4954 query_id:uint64 reserve0:Coins reserve1:Coins total_sup
3939

4040
Here is a smart contract snippet in [Tolk](/languages/tolk) illustrating how you can send the 'provide' message:
4141

42-
```tolk
42+
```tolk title="Tolk"
4343
struct (0x6e24728d) ProvideDeDustPool {
4444
queryId: uint64
4545
doIncludeAssets: bool

foundations/addresses/derive.mdx

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ The `StateInit` is distinct from the account's current state. It is the initial
1515

1616
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.
1717

18-
```tolk expandable
18+
```tolk title="Tolk" expandable
1919
// Compose an address builder
2020
fun calculateAddress(
2121
code: cell,
@@ -63,7 +63,7 @@ The `calculateAddress` function uses the [`AutoDeployAddress`](/languages/tolk/f
6363

6464
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.
6565

66-
```tolk expandable
66+
```tolk title="Tolk" expandable
6767
// Compose an address builder using the AutoDeployAddress built-in.
6868
fun calculateAddress(code: cell, data: cell, workchain: int): builder {
6969
val addr = AutoDeployAddress {
@@ -108,7 +108,7 @@ A [vanity contract](/contract-dev/vanity) allows _customizing_ the address of a
108108

109109
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.
110110

111-
```tolk
111+
```tolk title="Tolk"
112112
// Constant address in raw format.
113113
const VANITY_ADDRESS_RAW: address = address("0:4de24b95c1c3c9b6a94231460716192c7d2b4e444ca6ae9a98bc5c4b3fcdef3f");
114114
@@ -129,7 +129,7 @@ This may seem similar to the [vanity](#on-chain-vanity) case, but it serves a di
129129

130130
The logic here is more similar to the [simple](#on-chain-simple) case. The only difference is the additional `toShard` field.
131131

132-
```tolk expandable
132+
```tolk title="Tolk" expandable
133133
// Compose an address builder using the AutoDeployAddress built-in.
134134
fun deriveAddress(target: address, prefixLength: int): builder {
135135
val code = getCode();

foundations/messages/external-out.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ As outbound external messages do not carry any Toncoin value, the price of their
4141

4242
In Tolk, outbound external messages may be composed using the `createExternalLogMessage` function.
4343

44-
```tolk
44+
```tolk title="Tolk"
4545
tolk 1.2
4646
4747
struct(0x10) ValueWasDeposited {

standard/tokens/nft/deploy.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -169,7 +169,7 @@ To deploy an item from a smart contract, send a message from the contract to the
169169

170170
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.
171171

172-
```tolk
172+
```tolk title="Tolk"
173173
// SnakeString describes a (potentially long) string inside a cell;
174174
// short strings are stored as-is, like "my-picture.png";
175175
// long strings are nested refs, like "xxxx".ref("yyyy".ref("zzzz"))

standard/tokens/nft/nft-2.0.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -187,7 +187,7 @@ The TEP-66 standard does not define the body of internal messages used to delive
187187

188188
Below is an example contract snippet written in Tolk:
189189

190-
```tolk
190+
```tolk title="Tolk"
191191
// You should retrieve these values by calling the collection's getter method beforehand
192192
struct Storage {
193193
numerator: uint16

tvm/get-method.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ PROGRAM{
4848

4949
The above is equivalent to the following Tolk code, which compiles to almost identical Fift code.
5050

51-
```tolk
51+
```tolk title="Tolk"
5252
fun main() { }
5353
5454
get fun get_x(): int {

0 commit comments

Comments
 (0)