diff --git a/src/frontend/src/pages/Chapter/Chapter.view.tsx b/src/frontend/src/pages/Chapter/Chapter.view.tsx index e26f2b4..509444d 100644 --- a/src/frontend/src/pages/Chapter/Chapter.view.tsx +++ b/src/frontend/src/pages/Chapter/Chapter.view.tsx @@ -214,7 +214,7 @@ export const ChapterView = ({ {Object.keys(supports).length > 0 && (
setDisplay('solution')}> - Exercice + Exercise {Object.keys(supports).map((key, index) => ( setDisplay(key)}> diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterConditionals/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterConditionals/course.md index e6be199..e018ff0 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterConditionals/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterConditionals/course.md @@ -57,3 +57,9 @@ We want to conditionally change the engine attribute (third number) to 1 only if 1- Define a condition _if_ the engine attribute equal 0. Don't forget the attributes are defined as strings. 2- If the condition is met, apply changes and return resulting new ship code. Otherwise, return the given ship code (parameter *my\_ship*). + +⚠️ If you have installed LIGO then you can test the execution of the *modify\_ship* function by running the following command: + +``` +ligo run-function main.ligo modify_ship '("010433")' +``` \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/course.md index c08525d..d8b3afa 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/course.md @@ -242,4 +242,5 @@ let main (action,store : parameter * storage): return = 1- Write the _compile-storage_ command and the LIGO expression for initializing the *Sol* system containing planet "earth" with coordinates (2,7,1). -2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. Reuse the *Sol* system of step 1. +2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. +⚠️ Remind that the _dry-run_ command expects a parameter "" and a parameter "" as shown in Simulating section. For this _dry-run_ command you must write the "" parameter and reuse the *Sol* system of step 1 as "" parameter. diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md index e3122f5..ff304a7 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md @@ -39,7 +39,7 @@ ERC721 is the standard rule set for non-fungible tokens. This Fungible token standard provides basic functionality to transfer tokens, as well as to allow tokens to be approved so they can be spent by another on-chain third party. Possible actions : -_Appove_ - Sender can specify an amount of token that can be spent by someone else (from his account) +_Approve_ - Sender can specify an amount of token that can be spent by someone else (from his account) _Transfer_ - Transfer an amount of tokens from an account to another account (or third-party on-chain smart contract) _GetAllowance_ - Return the amount that can be spent by someone from sender's account _GetBalance_ - Return the sender's account balance @@ -167,7 +167,7 @@ Let's assume that the _TezosAcamedyToken_ has been deployed. Consider your account is _me_ (at address tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) which has been granted 1,000,000 tokens. Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7) -1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Write a ligo command line for preparing a simulated storage where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. +1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Complete the ligo command line for preparing a storage state where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. Write the storage state (all values of the storage must be filled). 2- Write a ligo command line for preparing the invocation of an *Approval* of 2 TAT (Tezos Academy Token) for *alice*. @@ -194,3 +194,14 @@ Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7) ``` 10- Write a Tezos command line that simulates your *Transfer* invocation. + +Remind the syntax of the tezos-client transfer command: + +``` +tezos-client transfer from to --arg '' --dry-run +``` + + = number of mutez of the transaction + = account who is emitting the transaction + = name of the contract + = michelson expression representing the entrypoint and its related parameters \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterFA12/exercise.cmd b/src/frontend/src/pages/Chapters/Camel/ChapterFA12/exercise.cmd index fcc1477..4351980 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterFA12/exercise.cmd +++ b/src/frontend/src/pages/Chapters/Camel/ChapterFA12/exercise.cmd @@ -7,7 +7,7 @@ ligo dry-run --sender=tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ fa12.mligo main ' from to --arg '' --dry-run // Modify the code below -ligo compile-parameter refa12.mligo main '' +ligo compile-parameter fa12.mligo main '' // Modify the code below ligo compile-storage fa12.mligo main '' // Modify the code below diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterFA20Operator/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterFA20Operator/course.md index 1ee2b5b..e713d1d 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterFA20Operator/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterFA20Operator/course.md @@ -176,7 +176,7 @@ Our NFT "token" is almost ready but to allow a new rule. We need Bob to transfer - Vera account is owner of the token 1 -2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *operator\_update\_to\_michelson* function to convert your parameters into the format expected by *Update\_operators* entry point. +2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *operator\_update\_to\_michelson* function to convert your parameters into the format expected by *Update\_operators* entry point. Don't forget to refer to fa2_interface to know the the expected type of *Update\_operators* entry point. 3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transferred token id is number 1 (token\_id and and amount must be 1). You can use the *transfer\_to\_michelson* function to convert your parameters into the format expected by *Transfer* entry point. diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterInteractions/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterInteractions/course.md index 61b8bdb..7876129 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterInteractions/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterInteractions/course.md @@ -106,6 +106,12 @@ let main (action, store : parameter * storage) : return is ) ``` -2- Consider the contract in the editor. Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. Your job is now to define the list of operations to send to the weapons. For this, start by creating _operations_ a list of type _operation_. +⚠️ Notice that the weapon smart contract provides two entrypoints Fire and Stop. + +2- Consider the contract in the editor which is responsible to control the left and right weapons. +⚠️ Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. (Variables *right\_laser* and *left\_laser* can be used as the target of a transaction). +Your job is now to define the list of transactions sent to the weapon contracts. For this, start by creating _operations_ a list of type _operation_. + +⚠️ Notice that _operations_ must be filled with transactions and is returned by the function _orders_. 3- Send a _Fire(5)_ transaction to the *right\_laser* contract, then _Stop_. Send a _Fire(5)_ transaction to the *left\_laser* contract, then _Stop_. diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterLambda/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterLambda/course.md index babd15c..405fd34 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterLambda/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterLambda/course.md @@ -143,7 +143,7 @@ Map.map applyDeduceCatg store.celestialbodies We want you to update our "starmap" contract in order to take this new rule into account. -1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. +1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. You must write a lambda function within the parentheses of _DeduceCategoryChange_ as shown in the Lambda definition section. The lambda function must implement the three following rules. 2- First rule : if the coordinates of a planet is (0,0,0) then the celestial body is considered as a STAR. diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterPolymorphism/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterPolymorphism/course.md index 07862b4..9b229e7 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterPolymorphism/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterPolymorphism/course.md @@ -44,19 +44,28 @@ Entry point names are written in the form of: _%myEntryPoint_ for the entry poin ## Your mission -Consider the following smart contracts : Squadron and Central (Exercice). +Consider the following smart contracts : Squadron and Central (Exercise). The Central contract acts as an inventory of ships (an entry point _RegisterShip_ is provided to register a ship). The Central contract can provide information of a ship to a calling contract via a callback transaction (an entry point _RetrieveShip_ is provided to query a ship). The Squadron contract provides an entry point _ModuleRequest_ to ask for ship information to the central contract. The Squadron contract provides an entry point _ModuleResponse_ which is called by the central contract when sending back the expected ship information. -As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send a transaction to a the calling contract. The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! +As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send the requested ship information to the caller (by sending a transaction to the calling contract). The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! -1- Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _actionSquadron contract option_ +⚠️ Notice that there are multiple tabs for displaying Squadron and Central smart contracts. Your goal is to complete the Central contract displayed in tab "Exercise". -2- Use a _match_ operator to extract the entry point if it exists (use temporary variable name *ci* in the _Some_). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. -3- In order to prepare the ship information that need to be sent back to the Squadron contract. Check the expected type of entry point _ModuleResponse_ and prepare a variable *ee* of this expected type containing the expected ship *e*. +1- First we want to call the moduleResponse entrypoint of the Squadron but we need to ensure that the *callbackAddress* is a squadron contract and has the expected entrypoint. Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _actionSquadron contract option_. +⚠️Remind that the entry point must be in quotations. +⚠️Remind that _option_ type means that maybe there is a value +⚠️Remind that _actionSquadron contract_ represents entrypoints following the _actionSquadron_ format. +⚠️So the type _actionSquadron contract option_ stands for "Maybe there are entrypoints which follow the _actionSquadron_ format". + +2- Use a _match_ operator to extract the entry point from *contractInterfaceOpt* if it exists (use temporary variable name *ci* in the _Some_). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. + +3- In order to prepare the ship information that need to be sent back to the Squadron contract. Prepare a variable called *ee* of type _actionModuleResponse_ containing the expected ship *e*. +⚠️ Notice that in Squadron smart contract the entry point _ModuleResponse_ expects a type _actionModuleResponse_. So when Central smart contract sends back the requested ship information it must respect the expected format (in our case it is a _actionModuleResponse_ containing a _ship_ record). + 4- Send a transaction to the retrieved entry point of the Squadron contract. The transaction must point to the _moduleResponse_ entrypoint of squadron contract and passing the right argument prepared in step 3. This transaction sends no money. The transaction is an _operation_ type that you can store in a variable *sendbackOperation*. diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterStrings/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterStrings/course.md index 15685ab..47ca6c1 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterStrings/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterStrings/course.md @@ -20,7 +20,12 @@ let full_greeting: string = greeting ^ " " ^ name ## Slicing Strings -Strings can be sliced using a built-in function _String.sub_ as follows: +Strings can be sliced using a built-in function _String.sub_ which takes three parameters: +- an _offset_ describing the index of first character that will be copied +- the _length_ describing the number of characters that will be copied (starting from the given offset) +- the _string_ being sliced + +The function _String.sub_ can be used as follows: ``` let name: string = "Captain Rogers" diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/course.md index 6c28bbb..fbe18f5 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/course.md @@ -66,3 +66,10 @@ We want to conditionally change the engine attribute (third number) to 1 only if 2- Then define a condition _if_ the engine attribute equal 0. Don't forget the attributes are defined as strings. 3- If the condition is met, change *modified\_ship* to it new value. Otherwise, _skip_ the instructions. + +⚠️ If you have installed LIGO then you can test the execution of the *modify\_ship* function by running the following command: + +``` +ligo run-function main.ligo modify_ship '("010433")' +``` + diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/exercise.ligo b/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/exercise.ligo index 26516dc..e1ac43a 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/exercise.ligo +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterConditionals/exercise.ligo @@ -6,5 +6,5 @@ const my_ship_price : tez = 3tez * 1.20 function modify_ship (const my_ship : ship_code) : ship_code is block { // Type your solution below - const modified_ship := String.sub(0n, 2n, my_ship) ^ "1" ^ String.sub(3n, 3n, my_ship) + const modified_ship = String.sub(0n, 2n, my_ship) ^ "1" ^ String.sub(3n, 3n, my_ship) } with modified_ship \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterDeployContract/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterDeployContract/course.md index 41a27e8..0046e48 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterDeployContract/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterDeployContract/course.md @@ -260,4 +260,5 @@ block { skip } with case action of 1- Write the _compile-storage_ command and the LIGO expression for initializing the *Sol* system containing planet "earth" with coordinates (2,7,1). -2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. Reuse the *Sol* system of step 1. +2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. +⚠️ Remind that the _dry-run_ command expects a parameter "" and a parameter "" as shown in Simulating section. For this _dry-run_ command you must write the "" parameter and reuse the *Sol* system of step 1 as "" parameter. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/course.md index 92fa9ac..f3b2da1 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/course.md @@ -39,7 +39,7 @@ ERC721 is the standard rule set for non-fungible tokens. This Fungible token standard provides basic functionality to transfer tokens, as well as allowing tokens to be approved so they can be spent by another on-chain third party. Possible actions : -_Appove_ - Sender can specify an amount of token that can be spent by someone else (from his account) +_Approve_ - Sender can specify an amount of token that can be spent by someone else (from his account) _Transfer_ - Transfer an amount of tokens from an account to another account (or third-party on-chain smart contract) _GetAllowance_ - Return the amount that can be spent by someone from sender's account _GetBalance_ - Return the sender's account balance @@ -203,7 +203,7 @@ Let's assume _TezosAcamedyToken_ has been deployed. Consider your account is _me_ (at address tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) which has been granted 1,000,000 token. Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7) -1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Write a ligo command line for preparing a simulated storage where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. +1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Complete the ligo command line for preparing a storage state where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. Write the storage state (all values of the storage must be filled). 2- Write a ligo command line for preparing the invocation of an *Approval* of 2 TAT (Tezos Academy Token) for *alice*. @@ -230,3 +230,14 @@ Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7) ``` 10- Write a Tezos command line that simulates your *Transfer* invocation. + +Remind the syntax of the tezos-client transfer command: + +``` +tezos-client transfer from to --arg '' --dry-run +``` + + = number of mutez of the transaction + = account who is emitting the transaction + = name of the contract + = michelson expression representing the entrypoint and its related parameters \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/exercise.cmd b/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/exercise.cmd index 287e954..ddd4062 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/exercise.cmd +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterFA12/exercise.cmd @@ -7,7 +7,7 @@ ligo dry-run --sender=tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ fa12.ligo main ' from to --arg '' --dry-run // Modify the code below -ligo compile-parameter refa12.ligo main '' +ligo compile-parameter fa12.ligo main '' // Modify the code below ligo compile-storage fa12.ligo main '' // Modify the code below diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterFA20Operator/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterFA20Operator/course.md index 7d73653..650de5e 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterFA20Operator/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterFA20Operator/course.md @@ -200,7 +200,7 @@ Our NFT "token" is almost ready but to allow a new rule. We need Bob to transfer - Vera account is owner of the token 1 -2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point. +2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point. Don't forget to refer to fa2_interface to know the the expected type of *Update\_operators* entry point. 3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transferred token id is number 1 (token\_id and and amount must be 1). You can use the *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Transfer* entry point. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterInteractions/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterInteractions/course.md index c9a1bc8..687349e 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterInteractions/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterInteractions/course.md @@ -108,6 +108,12 @@ function main (const action : parameter; const store : storage) : return is end) ``` -2- Consider the contract in the editor. Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. Your job is now to define the list of operations to send to the weapons. For this, start by creating _operations_ a list of type _operation_. +⚠️ Notice that the weapon smart contract provides two entrypoints Fire and Stop. + +2- Consider the contract in the editor which is responsible to control the left and right weapons. +⚠️ Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. (Variables *right\_laser* and *left\_laser* can be used as the target of a transaction). +Your job is now to define the list of transactions sent to the weapon contracts. For this, start by creating _operations_ a list of type _operation_. + +⚠️ Notice that _operations_ must be filled with transactions and is returned by the function _orders_. 3- Send a _Fire(5)_ transaction to the *right\_laser* contract, then _Stop_. Send a _Fire(5)_ transaction to the *left\_laser* contract, then _Stop_. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterLambda/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterLambda/course.md index 4333c65..de0e562 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterLambda/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterLambda/course.md @@ -136,7 +136,7 @@ Map.map (applyDeduceCatg, store.celestialbodies); We want you to update our "starmap" contract in order to take this new rule into account. -1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. +1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. You must write a lambda function within the parentheses of _DeduceCategoryChange_ as shown in the Lambda definition section. The lambda function must implement the three following rules. 2- First rule : if the coordinates of a planet is (0,0,0) then the celestial body is considered as a STAR. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterLists/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterLists/course.md index cae3d97..855878c 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterLists/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterLists/course.md @@ -60,7 +60,7 @@ const smaller_set : set (int) = Set.remove (3, my_set) ## Your mission -1- Define _itinary_ as a list of string names of celestial bodies representing your course. Start with _"earth"_ +1- Define a variable _itinary_ as a list of string names of celestial bodies representing your course. Start with _"earth"_ 2- On the next line, add _"sun"_ to the itinary. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterLoops/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterLoops/course.md index b3639e0..d9eff12 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterLoops/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterLoops/course.md @@ -64,6 +64,6 @@ Same from sets with _for i in set s_ and maps with _for key -> value in map m_ 1- Check the proposed code in the editor. Notice that we created a star map as a list of planet records. -2- Notice the unimplemented scan function. Suppose this function is called from the main function with the *star\_map* variable as its input _l_. Code a for loop that iterates through each record of the list. +2- Notice the unimplemented scan function. Suppose this function is called from the main function onto the *star\_map* variable. Code a for loop that iterates through each record of the list _l_ (given as parameter of the _scan_ function). 3- Inside the loop, code a conditional for *density* supperior to 100 and *atmospheric\_activity* true. If so, assign the planet to *destination*. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md index 1e221ab..b6514a0 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md @@ -222,7 +222,7 @@ Notice that in the _Withdraw_ function : Modify the existing *Multisig* contract in order to handle reputation level for each voters. We plan to grant reputation points when the message is really executed (one point of reputation for each voters). - 1- Modify storage to have an additionnal property called *reputation* which associates a _nat_ number to a voter. + 1- Modify the storage to have an additionnal property called *reputation* which associates a _nat_ number to a voter. In the *send* function, notice that voters are computed in a variable *new_store*. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterPolymorphism/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterPolymorphism/course.md index 60f578d..e421daf 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterPolymorphism/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterPolymorphism/course.md @@ -44,19 +44,28 @@ Entry point names are written in the form of: _%myEntryPoint_ for the entry poin ## Your mission -Consider the following smart contracts : Squadron and Central (Exercice). +Consider the following smart contracts : Squadron and Central (Exercise). The Central contract acts as an inventory of ships (an entry point _RegisterShip_ is provided to register a ship). The Central contract can provide information of a ship to a calling contract via a callback transaction (an entry point _RetrieveShip_ is provided to query a ship). The Squadron contract provides an entry point _ModuleRequest_ to ask for ship information to the central contract. The Squadron contract provides an entry point _ModuleResponse_ which is called by the central contract when sending back the expected ship information. -As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send a transaction to a the calling contract. The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! +As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send the requested ship information to the caller (by sending a transaction to the calling contract). The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! -1- Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _option(contract(actionSquadron))_ +⚠️ Notice that there are multiple tabs for displaying Squadron and Central smart contracts. Your goal is to complete the Central contract displayed in tab "Exercise". -2- Use a _case_ operator to extract the entry point if it exists (use temporary variable name *ci* in the case). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. -3- In order to prepare the ship information that need to be sent back to the Squadron contract. Check the expected type of entry point _ModuleResponse_ and prepare a variable *ee* of this expected type containing the expected ship *e*. +1- First we want to call the moduleResponse entrypoint of the Squadron but we need to ensure that the *callbackAddress* is a squadron contract and has the expected entrypoint. Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _option(contract(actionSquadron))_. +⚠️Remind that the entry point must be in quotations. +⚠️Remind that _option_ type means that maybe there is a value +⚠️Remind that _contract(actionSquadron)_ represents entrypoints following the _actionSquadron_ format. +⚠️So the type _option(contract(actionSquadron))_ stands for "Maybe there are entrypoints which follow the _actionSquadron_ format". + +2- Use a _case_ operator to extract the entry point from *contractInterfaceOpt* if it exists (use temporary variable name *ci* in the case). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. + +3- In order to prepare the ship information that need to be sent back to the Squadron contract. Prepare a variable called *ee* of type _actionModuleResponse_ containing the expected ship *e*. +⚠️ Notice that in Squadron smart contract the entry point _ModuleResponse_ expects a type _actionModuleResponse_. So when Central smart contract sends back the requested ship information it must respect the expected format (in our case it is a _actionModuleResponse_ containing a _ship_ record). + 4- Send a transaction to the retrieved entry point of the Squadron contract. The transaction must point to the _moduleResponse_ entrypoint of squadron contract and passing the right argument prepared in step 3. This transaction sends no money. The transaction is an _operation_ type that you can store in a variable *sendbackOperation*. diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterStrings/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterStrings/course.md index e775afc..38c7b80 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterStrings/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterStrings/course.md @@ -20,7 +20,12 @@ const full_greeting: string = greeting ^ " " ^ name ## Slicing Strings -Strings can be sliced using a built-in function _String.sub_ as follows: +Strings can be sliced using a built-in function _String.sub_ which takes three parameters: +- an _offset_ describing the index of first character that will be copied +- the _length_ describing the number of characters that will be copied (starting from the given offset) +- the _string_ being sliced + +The function _String.sub_ can be used as follows: ``` const name: string = "Captain Rogers" diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterConditionals/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterConditionals/course.md index 673f511..7e3341c 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterConditionals/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterConditionals/course.md @@ -69,3 +69,9 @@ We want to conditionally change the engine attribute (third number) to 1 only if 1- Define a condition _if_ the engine attribute equal 0. Don't forget the attributes are defined as strings. 2- If the condition is met, compute the new ship_code value in a constant *modified\_ship* and return *modified\_ship*. Otherwise, return the *my\_ship* constant (given as parameter of the function). + +⚠️ If you have installed LIGO then you can test the execution of the *modify\_ship* function by running the following command: + +``` +ligo run-function main.ligo modify_ship '("010433")' +``` \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterDeployContract/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterDeployContract/course.md index 452adec..84d606c 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterDeployContract/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterDeployContract/course.md @@ -248,4 +248,5 @@ let main = ((action,store) : (parameter,storage)): return => 1- Write the _compile-storage_ command and the LIGO expression for initializing the *Sol* system containing planet "earth" with coordinates (2,7,1). -2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. Reuse the *Sol* system of step 1. +2- Write the _dry-run_ command and the LIGO expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. +⚠️ Remind that the _dry-run_ command expects a parameter "" and a parameter "" as shown in Simulating section. For this _dry-run_ command you must write the "" parameter and reuse the *Sol* system of step 1 as "" parameter. diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterFA12/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterFA12/course.md index 106fdf6..7117b2d 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterFA12/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterFA12/course.md @@ -37,7 +37,7 @@ ERC721 is the standard rule set for non-fungible tokens. This Fungible token standard provides basic functionality to transfer tokens, as well as allowing tokens to be approved so they can be spent by another on-chain third party. Possible actions : -_Appove_ - Sender can specify an amount of token that can be spent by someone else (from his account) +_Approve_ - Sender can specify an amount of token that can be spent by someone else (from his account) _Transfer_ - Transfer an amount of tokens from an account to another account (or third-party on-chain smart contract) _GetAllowance_ - Return the amount that can be spent by someone from sender's account _GetBalance_ - Return the sender's account balance @@ -171,7 +171,7 @@ Let's assume _TezosAcamedyToken_ has been deployed. Consider your account is _me_ (at address tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ). Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7). -1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Write a ligo command line for preparing a simulated storage where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. +1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Complete the ligo command line for preparing a storage state where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1,000,000 tokens and no allowance. Write the storage state (all values of the storage must be filled). 2- Write a ligo command line for preparing the invocation of an *Approval* of 2 TAT (Tezos Academy Token) for *alice*. @@ -198,3 +198,14 @@ Consider alice's account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7). ``` 10- Write a Tezos command line that simulates your *Transfer* invocation. + +Remind the syntax of the tezos-client transfer command: + +``` +tezos-client transfer from to --arg '' --dry-run +``` + + = number of mutez of the transaction + = account who is emitting the transaction + = name of the contract + = michelson expression representing the entrypoint and its related parameters diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterFA12/exercise.cmd b/src/frontend/src/pages/Chapters/Reason/ChapterFA12/exercise.cmd index f32caab..c155fb8 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterFA12/exercise.cmd +++ b/src/frontend/src/pages/Chapters/Reason/ChapterFA12/exercise.cmd @@ -7,7 +7,7 @@ ligo dry-run --sender=tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ fa12.religo main ' from to --arg '' --dry-run // Modify the code below -ligo compile-parameter refa12.religo main '' +ligo compile-parameter fa12.religo main '' // Modify the code below ligo compile-storage fa12.religo main '' // Modify the code below diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterFA20Operator/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterFA20Operator/course.md index 0b26f47..94bc556 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterFA20Operator/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterFA20Operator/course.md @@ -220,7 +220,7 @@ Our NFT "token" is almost ready but to allow a new rule. We need Bob to transfer - Vera account is owner of the token 1 -2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point. +2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point. Don't forget to refer to fa2_interface to know the the expected type of *Update\_operators* entry point. 3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transferred token id is number 1 (token\_id and and amount must be 1). You can use the *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Transfer* entry point. diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterInteractions/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterInteractions/course.md index a4061d8..0493d2a 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterInteractions/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterInteractions/course.md @@ -111,6 +111,14 @@ let main = ((action, store) : (parameter, storage)) : return => { } ``` -2- Consider the contract in the editor. Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. Your job is now to define the list of operations to send to the weapons. For this, start by creating _operations_ a list of type _operation_. + +⚠️ Notice that the weapon smart contract provides two entrypoints Fire and Stop. + +2- Consider the contract in the editor which is responsible to control the left and right weapons. +⚠️ Notice the addresses of each weapon, and that the _orders_ function fetch the corresponding contracts. (Variables *right\_laser* and *left\_laser* can be used as the target of a transaction). +Your job is now to define the list of transactions sent to the weapon contracts. For this, start by creating _operations_ a list of type _operation_. + +⚠️ Notice that _operations_ must be filled with transactions and is returned by the function _orders_. 3- Send a _Fire(5)_ transaction to the *right\_laser* contract, then _Stop_. Send a _Fire(5)_ transaction to the *left\_laser* contract, then _Stop_. + diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterLambda/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterLambda/course.md index e3d32f2..69cd3ab 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterLambda/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterLambda/course.md @@ -136,7 +136,7 @@ Map.map (applyDeduceCatg, store.celestialbodies); We want you to update our "starmap" contract in order to take this new rule into account. -1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. +1- Write the _dry-run_ command and the associated invocation (entry point) for taking the new rule into account. You must write a lambda function within the parentheses of _DeduceCategoryChange_ as shown in the Lambda definition section. The lambda function must implement the three following rules. 2- First rule : if the coordinates of a planet is (0,0,0) then the celestial body is considered as a STAR. diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterPolymorphism/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterPolymorphism/course.md index 4fb792b..ae433ec 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterPolymorphism/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterPolymorphism/course.md @@ -44,19 +44,30 @@ Entry point names are written in the form of: _%myEntryPoint_ for the entry poin ## Your mission -Consider the following smart contracts : Squadron and Central (Exercice). +Consider the following smart contracts : Squadron and Central (Exercise). The Central contract acts as an inventory of ships (an entry point _RegisterShip_ is provided to register a ship). The Central contract can provide information of a ship to a calling contract via a callback transaction (an entry point _RetrieveShip_ is provided to query a ship). The Squadron contract provides an entry point _ModuleRequest_ to ask for ship information to the central contract. The Squadron contract provides an entry point _ModuleResponse_ which is called by the central contract when sending back the expected ship information. -As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send a transaction to a the calling contract. The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! +As you can see, the entry point _RetrieveShip_ calls the function _sendTx_ which is responsible to send the requested ship information to the caller (by sending a transaction to the calling contract). The implementation of the Central contract has not been finished. We need you to finish the _sendTx_ function! -1- Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _option(contract(actionSquadron))_ +⚠️ Notice that there are multiple tabs for displaying Squadron and Central smart contracts. Your goal is to complete the Central contract displayed in tab "Exercise". -2- Use a _switch_ operator to extract the entry point if it exists (use temporary variable name *ci* in the switch). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. -3- In order to prepare the ship information that need to be sent back to the Squadron contract. Check the expected type of entry point _ModuleResponse_ and prepare a variable *ee* of this expected type containing the expected ship *e*. + + +1- First we want to call the moduleResponse entrypoint of the Squadron but we need to ensure that the *callbackAddress* is a squadron contract and has the expected entrypoint. Try to retrieve the entry point %moduleResponse of the given *callbackAddress* and store the result in a variable called *contractInterfaceOpt* of type _option(contract(actionSquadron))_. +⚠️Remind that the entry point must be in quotations. +⚠️Remind that _option_ type means that maybe there is a value +⚠️Remind that _actionSquadron contract_ represents entrypoints following the _actionSquadron_ format. +⚠️So the type _option(contract(actionSquadron))_ stands for "Maybe there are entrypoints which follow the _actionSquadron_ format". + +2- Use a _switch_ operator to extract the entry point from *contractInterfaceOpt* if it exists (use temporary variable name *ci* in the _Some_). Otherwise throw an exception with error message "Entrypoint not found in contract Squadron" (and don't forget to cast the exception in the right type). The extracted entry point must be stored in a variable called *contractInterface*. + +3- In order to prepare the ship information that need to be sent back to the Squadron contract. Prepare a variable called *ee* of type _actionModuleResponse_ containing the expected ship *e*. +⚠️ Notice that in Squadron smart contract the entry point _ModuleResponse_ expects a type _actionModuleResponse_. So when Central smart contract sends back the requested ship information it must respect the expected format (in our case it is a _actionModuleResponse_ containing a _ship_ record). + 4- Send a transaction to the retrieved entry point of the Squadron contract. The transaction must point to the _moduleResponse_ entrypoint of squadron contract and passing the right argument prepared in step 3. This transaction sends no money. The transaction is an _operation_ type that you can store in a variable *sendbackOperation*. diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterStrings/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterStrings/course.md index bfc7104..009a409 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterStrings/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterStrings/course.md @@ -20,7 +20,12 @@ let full_greeting: string = greeting ++ " " ++ name; ## Slicing Strings -Strings can be sliced using a built-in function _String.sub_ as follows: +Strings can be sliced using a built-in function _String.sub_ which takes three parameters: +- an _offset_ describing the index of first character that will be copied +- the _length_ describing the number of characters that will be copied (starting from the given offset) +- the _string_ being sliced + +The function _String.sub_ can be used as follows: ``` let name: string = "Captain Rogers"; diff --git a/src/frontend/src/pages/Home/Home.style.tsx b/src/frontend/src/pages/Home/Home.style.tsx index c608828..27a3e50 100644 --- a/src/frontend/src/pages/Home/Home.style.tsx +++ b/src/frontend/src/pages/Home/Home.style.tsx @@ -440,7 +440,7 @@ export const HomeFooterGrid = styled.div` margin: auto; padding: 50px 0; display: grid; - grid-template-columns: 2fr 1fr 1fr 1fr 2fr; + grid-template-columns: 2fr 1fr 1fr 1fr 1fr 2fr; grid-gap: 30px; font-family: 'Proxima Nova'; diff --git a/src/frontend/src/pages/Home/Home.view.tsx b/src/frontend/src/pages/Home/Home.view.tsx index 29a84fe..048518b 100644 --- a/src/frontend/src/pages/Home/Home.view.tsx +++ b/src/frontend/src/pages/Home/Home.view.tsx @@ -85,7 +85,7 @@ export const HomeView = () => { )}

Learn to code Tezos Smart Contracts the easy way!

-

Tezos academy is a fun interactive tutorial to the LIGO language

+

Tezos Academy is a fun interactive tutorial to the LIGO language