Merge branch 'feature/11-configure-versioned-docs' into 'dev'
#11 configure versioned docs See merge request ligolang/ligo!20
This commit is contained in:
Matej Šima
commit
4479bd9bae
@ -8,6 +8,20 @@ stages:
|
||||
- build_and_deploy_website
|
||||
- test
|
||||
|
||||
.website_build: &website_build
|
||||
stage: build_and_deploy_website
|
||||
image: node:8
|
||||
before_script:
|
||||
- cd gitlab-pages/website
|
||||
- npm install
|
||||
script:
|
||||
- npm run version next
|
||||
- npm run build
|
||||
after_script:
|
||||
- cp -r gitlab-pages/website/build/ligo public
|
||||
artifacts:
|
||||
paths:
|
||||
- public
|
||||
|
||||
.docker: &docker
|
||||
image: docker:1.11
|
||||
@ -16,7 +30,7 @@ stages:
|
||||
|
||||
.docker_build: &docker_build
|
||||
script:
|
||||
- docker build -t $LIGO_REGISTRY_IMAGE:latest -f ./docker/Dockerfile .
|
||||
- docker build -t $LIGO_REGISTRY_IMAGE:next -f ./docker/Dockerfile .
|
||||
|
||||
.before_script: &before_script
|
||||
before_script:
|
||||
@ -90,8 +104,9 @@ build-current-docker-image:
|
||||
<<: *docker_build
|
||||
except:
|
||||
- master
|
||||
- dev
|
||||
|
||||
# When a MR/PR is merged to master
|
||||
# When a MR/PR is merged to dev
|
||||
# take the previous build and publish it to Docker Hub
|
||||
build-and-publish-latest-docker-image:
|
||||
stage: build_and_deploy_docker
|
||||
@ -99,25 +114,16 @@ build-and-publish-latest-docker-image:
|
||||
<<: *docker_build
|
||||
after_script:
|
||||
- docker login -u $LIGO_REGISTRY_USER -p $LIGO_REGISTRY_PASSWORD
|
||||
- docker push $LIGO_REGISTRY_IMAGE:latest
|
||||
- docker push $LIGO_REGISTRY_IMAGE:next
|
||||
only:
|
||||
- master
|
||||
- dev
|
||||
|
||||
|
||||
# Pages are deployed from both master & dev, be careful not to override 'next'
|
||||
# in case something gets merged into 'dev' while releasing.
|
||||
pages:
|
||||
stage: build_and_deploy_website
|
||||
image: node:8
|
||||
before_script:
|
||||
- cd gitlab-pages/website
|
||||
- npm install
|
||||
script:
|
||||
- npm run build
|
||||
- pwd
|
||||
- cd ../..
|
||||
- pwd
|
||||
- cp -r gitlab-pages/website/build/ligo public
|
||||
artifacts:
|
||||
paths:
|
||||
- public
|
||||
<<: *website_build
|
||||
only:
|
||||
- master
|
||||
- dev
|
||||
|
||||
|
||||
2
gitlab-pages/.gitignore
vendored
2
gitlab-pages/.gitignore
vendored
@ -10,3 +10,5 @@ website/build/
|
||||
website/yarn.lock
|
||||
website/node_modules
|
||||
website/i18n/*
|
||||
website/versioned_docs/version-next
|
||||
website/versioned_sidebars/version-next-sidebars.json
|
||||
@ -1,2 +0,0 @@
|
||||
up:
|
||||
docker-compose up
|
||||
@ -13,6 +13,9 @@ services:
|
||||
- ./website/i18n:/app/website/i18n
|
||||
- ./website/pages:/app/website/pages
|
||||
- ./website/static:/app/website/static
|
||||
- ./website/versioned_sidebars:/app/website/versioned_sidebars
|
||||
- ./website/versioned_docs:/app/website/versioned_docs
|
||||
- ./website/sidebars.json:/app/website/sidebars.json
|
||||
- ./website/siteConfig.js:/app/website/siteConfig.js
|
||||
- ./website/versions.json:/app/website/versions.json
|
||||
working_dir: /app/website
|
||||
|
||||
20
gitlab-pages/docs/contributors/documentation-and-releases.md
Normal file
20
gitlab-pages/docs/contributors/documentation-and-releases.md
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
id: documentation-and-releases
|
||||
title: Documentation and releases
|
||||
---
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
In case you'd like to contribute to the docs, you can find them at [`gitlab-pages/docs`]() in their raw markdown form.
|
||||
Deployment of the docs/website for LIGO is taken care of within the CI, from `dev` and `master` branches.
|
||||
|
||||
## Releases & versioning
|
||||
|
||||
### Development releases (next)
|
||||
|
||||
Development releases of Ligo are tagged as `next` and are built with each commit to the `dev` branch. Both the docker image & the website are published automatically.
|
||||
|
||||
### Stable releases
|
||||
|
||||
Releases tagged with version numbers `x.x.x` are built manually, both docs & the docker image. While deployment of the website is handled by the CI.
|
||||
@ -5,22 +5,24 @@ title: Installation
|
||||
|
||||
There are currently two ways to get started with Ligo, both of those will allow you to use the Ligo CLI with your contracts. You can choose to use either the Docker image, or to compile & build the Ligo CLI yourself.
|
||||
|
||||
## Docker
|
||||
## Dockerized installation (recommended)
|
||||
|
||||
> 🐳 You can find instructions on how to install Docker [here](https://docs.docker.com/install/).
|
||||
|
||||
Easiest way to use LIGO is through the Docker image available at [Docker Hub](https://hub.docker.com/r/stovelabs/granary-ligo). Sources for the image can be found on [Github](https://github.com/stove-labs/granary/blob/develop/docker/ligo/Dockerfile).
|
||||
Easiest way to use LIGO is through the Docker image available at [Docker Hub](https://hub.docker.com/r/ligolang/ligo). Sources for the image can be found on [Gitlab](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
||||
You can either run the docker image yourself, or you can setup a global ligo executable as shown below.
|
||||
|
||||
### Setting up a globally available `ligo` executable
|
||||
```zsh
|
||||
wget https://gitlab.com/maht0rz/ligo-documentation/blob/master/ligo-docker.sh && \
|
||||
sudo cp ligo-docker.sh /usr/local/bin/ligo && \
|
||||
sudo chmod +x /usr/local/bin/ligo && \
|
||||
rm ligo-docker.sh
|
||||
```
|
||||
|
||||
> ⚠️ Please note that the **current docker image is quite chunky**, it may take a while to download depending on your internet connection.
|
||||
> You can install additional ligo versions by replacing `next` with the required version number
|
||||
|
||||
```zsh
|
||||
# next (pre-release)
|
||||
curl https://gitlab.com/ligolang/ligo/raw/dev/scripts/installer.sh | bash "next"
|
||||
|
||||
# e.g. 1.0.0 (stable)
|
||||
curl https://gitlab.com/ligolang/ligo/raw/master/scripts/installer.sh | bash "1.0.0"
|
||||
```
|
||||
|
||||
**Verify your ligo installation by running:**
|
||||
```zsh
|
||||
@ -28,9 +30,9 @@ ligo --help
|
||||
```
|
||||
|
||||
|
||||
## Manual installation
|
||||
## Manual installation (advanced)
|
||||
|
||||
For now, please refer to the steps described in the [Dockerfile](https://github.com/stove-labs/granary/blob/develop/docker/ligo/Dockerfile).
|
||||
For now, please refer to the steps described in the [Dockerfile](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
||||
|
||||
|
||||
|
||||
|
||||
@ -6,6 +6,8 @@
|
||||
"publish-gh-pages": "docusaurus-publish",
|
||||
"write-translations": "docusaurus-write-translations",
|
||||
"version": "docusaurus-version",
|
||||
"preversion": "node preversion.js",
|
||||
"postversion": "node postversion.js",
|
||||
"rename-version": "docusaurus-rename-version"
|
||||
},
|
||||
"devDependencies": {
|
||||
|
||||
@ -26,22 +26,22 @@ class HomeSplash extends React.Component {
|
||||
<div className="homeSplashFade">
|
||||
<div className="wrapper homeWrapper">
|
||||
|
||||
<div class="tabs">
|
||||
<div class="nav-tabs">
|
||||
<div id="tab-group-3-tab-4" class="nav-link active" data-group="group_3"
|
||||
<div className="tabs">
|
||||
<div className="nav-tabs">
|
||||
<div id="tab-group-3-tab-4" className="nav-link active" data-group="group_3"
|
||||
data-tab="tab-group-3-content-4">Pascaligo</div>
|
||||
{/* <div id="tab-group-3-tab-5" class="nav-link" data-group="group_3"
|
||||
{/* <div id="tab-group-3-tab-5" className="nav-link" data-group="group_3"
|
||||
data-tab="tab-group-3-content-5">Camligo</div> */}
|
||||
</div>
|
||||
<div class="tab-content">
|
||||
<div id="tab-group-3-content-4" class="tab-pane active" data-group="group_3" tabIndex="-1">
|
||||
<div className="tab-content">
|
||||
<div id="tab-group-3-content-4" className="tab-pane active" data-group="group_3" tabIndex="-1">
|
||||
<div>
|
||||
<span>
|
||||
<pre><code class="hljs css language-Pascal">// variant defining pseudo multi-entrypoint actions<br />type action is<br />| Increment of int<br />| Decrement of int<br /><br />function add (const a : int ; const b : int) : int is<br /> block {'{ skip }'} with a + b<br /><br />function subtract (const a : int ; const b : int) : int is<br /> block {'{ skip }'} with a - b<br /><br />// real entrypoint that re-routes the flow based on the action provided<br />function main (const p : action ; const s : int) : (list(operation) * int) is<br /> block {'{ skip }'} with ((nil : list(operation)),<br /> case p of<br /> | Increment n -> add(s, n)<br /> | Decrement n -> subtract(s, n)<br /> end)<br /></code></pre>
|
||||
<pre><code className="hljs css language-Pascal">// variant defining pseudo multi-entrypoint actions<br />type action is<br />| Increment of int<br />| Decrement of int<br /><br />function add (const a : int ; const b : int) : int is<br /> block {'{ skip }'} with a + b<br /><br />function subtract (const a : int ; const b : int) : int is<br /> block {'{ skip }'} with a - b<br /><br />// real entrypoint that re-routes the flow based on the action provided<br />function main (const p : action ; const s : int) : (list(operation) * int) is<br /> block {'{ skip }'} with ((nil : list(operation)),<br /> case p of<br /> | Increment n -> add(s, n)<br /> | Decrement n -> subtract(s, n)<br /> end)<br /></code></pre>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
<div id="tab-group-3-content-5" class="tab-pane" data-group="group_3" tabIndex="-1">
|
||||
<div id="tab-group-3-content-5" className="tab-pane" data-group="group_3" tabIndex="-1">
|
||||
<div>
|
||||
<span>
|
||||
SOON
|
||||
@ -90,8 +90,8 @@ class HomeSplash extends React.Component {
|
||||
<div className="inner">
|
||||
<ProjectTitle siteConfig={siteConfig} />
|
||||
<PromoSection>
|
||||
<Button href={docUrl('setup-installation.html')}>Getting started</Button>
|
||||
<Button href={docUrl('contributors/origin.html')}>Contributing</Button>
|
||||
<Button href={docUrl('setup-installation.html')}>Get Started</Button>
|
||||
<Button href={docUrl('contributors/origin.html')}>Contribute</Button>
|
||||
|
||||
</PromoSection>
|
||||
</div>
|
||||
|
||||
115
gitlab-pages/website/pages/en/versions.js
Normal file
115
gitlab-pages/website/pages/en/versions.js
Normal file
@ -0,0 +1,115 @@
|
||||
/**
|
||||
* Copyright (c) 2017-present, Facebook, Inc.
|
||||
*
|
||||
* This source code is licensed under the MIT license found in the
|
||||
* LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
||||
const React = require('react');
|
||||
|
||||
const CompLibrary = require('../../core/CompLibrary');
|
||||
|
||||
const Container = CompLibrary.Container;
|
||||
|
||||
const CWD = process.cwd();
|
||||
|
||||
const versions = require(`${CWD}/versions.json`);
|
||||
|
||||
function Versions(props) {
|
||||
const {config: siteConfig} = props;
|
||||
const latestVersion = versions[0];
|
||||
const repoUrl = `https://github.com/${siteConfig.organizationName}/${
|
||||
siteConfig.projectName
|
||||
}`;
|
||||
return (
|
||||
<div className="docMainWrapper wrapper">
|
||||
<Container className="mainContainer versionsContainer">
|
||||
<div className="post">
|
||||
<header className="postHeader">
|
||||
<h1>{siteConfig.title} Versions</h1>
|
||||
</header>
|
||||
<h3 id="latest">Current version (Stable)</h3>
|
||||
<table className="versions">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>{latestVersion}</th>
|
||||
<td>
|
||||
{/* You are supposed to change this href where appropriate
|
||||
Example: href="<baseUrl>/docs(/:language)/:id" */}
|
||||
<a
|
||||
href={`${siteConfig.baseUrl}${siteConfig.docsUrl}/${
|
||||
props.language ? props.language + '/' : ''
|
||||
}setup-installation`}>
|
||||
Documentation
|
||||
</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href={repoUrl}>Source Code</a>
|
||||
</td>
|
||||
{/* <td>
|
||||
<a href="">Release Notes</a>
|
||||
</td> */}
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="rc">Pre-release versions</h3>
|
||||
<table className="versions">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>next</th>
|
||||
<td>
|
||||
{/* You are supposed to change this href where appropriate
|
||||
Example: href="<baseUrl>/docs(/:language)/next/:id" */}
|
||||
<a
|
||||
href={`${siteConfig.baseUrl}${siteConfig.docsUrl}/${
|
||||
props.language ? props.language + '/' : ''
|
||||
}next/setup-installation`}>
|
||||
Documentation
|
||||
</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href={repoUrl}>Source Code</a>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="archive">Past Versions</h3>
|
||||
<p>Here you can find previous versions of the documentation.</p>
|
||||
<table className="versions">
|
||||
<tbody>
|
||||
{versions.map(
|
||||
version =>
|
||||
version !== latestVersion && version !== "next" && (
|
||||
<tr>
|
||||
<th>{version}</th>
|
||||
<td>
|
||||
{/* You are supposed to change this href where appropriate
|
||||
Example: href="<baseUrl>/docs(/:language)/:version/:id" */}
|
||||
<a
|
||||
href={`${siteConfig.baseUrl}${siteConfig.docsUrl}/${
|
||||
props.language ? props.language + '/' : ''
|
||||
}${version}/setup-installation`}>
|
||||
Documentation
|
||||
</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href={`${repoUrl}/releases/tag/v${version}`}>
|
||||
Release Notes
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
),
|
||||
)}
|
||||
</tbody>
|
||||
</table>
|
||||
<p>
|
||||
You can find past versions of this project on{' '}
|
||||
<a href={repoUrl}>Gitlab</a>.
|
||||
</p>
|
||||
</div>
|
||||
</Container>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
module.exports = Versions;
|
||||
1
gitlab-pages/website/postversion.js
Normal file
1
gitlab-pages/website/postversion.js
Normal file
@ -0,0 +1 @@
|
||||
// require('./preversion');
|
||||
8
gitlab-pages/website/preversion.js
Normal file
8
gitlab-pages/website/preversion.js
Normal file
@ -0,0 +1,8 @@
|
||||
// This script is used to remove 'next' from the versions.json file in order to re-create in the CI
|
||||
const versions = require('./versions.json')
|
||||
const fs = require('fs');
|
||||
|
||||
const versionsWithoutNext = versions
|
||||
.filter(version => version !== "next");
|
||||
|
||||
fs.writeFileSync("./versions.json", JSON.stringify(versionsWithoutNext));
|
||||
@ -5,7 +5,7 @@
|
||||
"API": ["api-cli-commands"]
|
||||
},
|
||||
"contributors-docs": {
|
||||
"Introduction": ["contributors/origin", "contributors/philosophy"],
|
||||
"Introduction": ["contributors/origin", "contributors/philosophy", "contributors/getting-started", "contributors/documentation-and-releases"],
|
||||
"Big Picture": [
|
||||
"contributors/big-picture/overview",
|
||||
"contributors/big-picture/front-end",
|
||||
@ -13,7 +13,6 @@
|
||||
"contributors/big-picture/back-end",
|
||||
"contributors/big-picture/vendors"
|
||||
],
|
||||
"Road Map": ["contributors/road-map/short-term", "contributors/road-map/long-term"],
|
||||
"Contributing": ["contributors/contributing/getting-started"]
|
||||
"Road Map": ["contributors/road-map/short-term", "contributors/road-map/long-term"]
|
||||
}
|
||||
}
|
||||
|
||||
@ -99,7 +99,7 @@ const siteConfig = {
|
||||
headerLinks: [
|
||||
{doc: 'setup-installation', label: 'Docs'},
|
||||
{doc: 'api-cli-commands', label: 'CLI'},
|
||||
{doc: 'contributors/origin', label: 'Contributing'},
|
||||
{doc: 'contributors/origin', label: 'Contribute'},
|
||||
],
|
||||
|
||||
// If you have users set above, you add it here:
|
||||
@ -159,7 +159,7 @@ const siteConfig = {
|
||||
|
||||
// You may provide arbitrary config keys to be used as needed by your
|
||||
// template. For example, if you need your repo's URL...
|
||||
// repoUrl: 'https://github.com/facebook/test-site',
|
||||
repoUrl: 'https://gitlab.com/ligolang/ligo',
|
||||
};
|
||||
|
||||
module.exports = siteConfig;
|
||||
|
||||
@ -57,26 +57,41 @@ ul {
|
||||
border: 1px solid #B2210C;
|
||||
color: #B2210C;
|
||||
}
|
||||
/*
|
||||
dark red: B2210C
|
||||
*/
|
||||
|
||||
.button:hover, .promoSection .buttonWrapper:first-of-type > a.button {
|
||||
background: #B2210C;
|
||||
color: white;
|
||||
}
|
||||
|
||||
|
||||
blockquote {
|
||||
background-color: rgba(178, 33, 12, 0.7);
|
||||
border-left: 8px solid #B2210C;
|
||||
color: white;
|
||||
background-color: rgba(26, 26, 26, 0.6);
|
||||
border-left: 8px solid rgba(26, 26, 26, 0.7);
|
||||
color: rgba(255,255,255, 0.8);
|
||||
}
|
||||
|
||||
blockquote a {
|
||||
color: rgba(255,255,255, 0.8);
|
||||
border-bottom: 1px solid rgba(255,255,255, 0.8);
|
||||
}
|
||||
|
||||
blockquote a:hover {
|
||||
color: rgba(255,255,255, 1);
|
||||
border-bottom: 1px solid rgba(255,255,255, 1);
|
||||
}
|
||||
/*
|
||||
blockquote {
|
||||
background-color: rgba(252, 214, 0, 0.687);
|
||||
border-left-color: rgba(240, 210, 37, 1);
|
||||
color: rgba(0, 0, 0, 0.632);
|
||||
} */
|
||||
|
||||
a {
|
||||
color: rgba(26, 26, 26, 0.7);
|
||||
color: rgba(12, 12, 12, 0.8);
|
||||
}
|
||||
|
||||
a:hover {
|
||||
color: rgba(26, 26, 26, 1);
|
||||
color: rgb(12, 12, 12);
|
||||
}
|
||||
|
||||
.homeContainer .homeWrapper .projectLogo {
|
||||
|
||||
@ -0,0 +1,48 @@
|
||||
---
|
||||
id: version-next-api-cli-commands
|
||||
title: CLI Commands
|
||||
original_id: api-cli-commands
|
||||
---
|
||||
|
||||
Contracts written in Ligo can be compiled using the `ligo` executable.
|
||||
|
||||
|
||||
## Compiling a contract
|
||||
|
||||
Compile your contract with a specific entry point.
|
||||
|
||||
```zsh
|
||||
ligo compile-contract SOURCE_FILE [ENTRY_POINT]
|
||||
```
|
||||
|
||||
#### Example
|
||||
|
||||
```zsh
|
||||
ligo compile-contract examples/counter.ligo main
|
||||
```
|
||||
|
||||
## Defining the initial storage
|
||||
|
||||
If your contract implements a sophisticated storage, you can compile a Ligo expression into a Michelson value quite easily.
|
||||
|
||||
```zsh
|
||||
ligo compile-storage SOURCE_FILE ENTRY_POINT EXPRESSION
|
||||
```
|
||||
|
||||
#### Example
|
||||
```zsh
|
||||
ligo compile-storage examples/counter.ligo main 5
|
||||
# Outputs: 5
|
||||
```
|
||||
|
||||
## Invoking the contract with a parameter
|
||||
|
||||
```zsh
|
||||
ligo compile-parameter SOURCE_FILE ENTRY_POINT EXPRESSION
|
||||
```
|
||||
|
||||
#### Example
|
||||
```zsh
|
||||
ligo compile-parameter examples/counter.ligo main "Increment(5)"
|
||||
# Outputs: (Right 5)
|
||||
```
|
||||
@ -0,0 +1,19 @@
|
||||
---
|
||||
id: version-next-back-end
|
||||
title: Back End
|
||||
original_id: back-end
|
||||
---
|
||||
|
||||
The Back-End is the part that compiles down to Michelson. Instead of a single compilation step, it is separated in two parts.
|
||||
## Transpiler and Mini_C
|
||||
The Transpiler is a function that takes as input the Typed AST, and outputs expressions in a language that is basically a Michelson based on with named variables and first-class-environments.
|
||||
On the one hand, there are cases in the AST like `E_if_bool` or `E_make_empty_list` that would be directly translated in Michelson like `IF {} {}` or `NIL`.
|
||||
On the other hand, there are cases in the AST like `E_variable` or `E_environment_select` that specifically target the compiler.
|
||||
The files of the Transpiler are in `transpiler/`, while those of Mini_c are in `mini_c/`.
|
||||
## Compiler
|
||||
The previous LIGO’s compilation to Michelson model was quite complicated. The current one is quite straightforward, where the environment of variables (x -> 12, y -> “foo”) is compiled as Michelson stack (12 :: foo).
|
||||
It has been simplified for multiple reasons:
|
||||
Having a simple model reduces its number of points of failure.
|
||||
Having a simple model makes optimizing it easier.
|
||||
We submitted a change to the Tezos’ protocol that actually make it more efficient.
|
||||
|
||||
@ -0,0 +1,16 @@
|
||||
---
|
||||
id: version-next-front-end
|
||||
title: Front End
|
||||
original_id: front-end
|
||||
---
|
||||
|
||||
The Front-End is the part that deals with all syntactical matters. LIGO supports multiple Front-Ends. Each Front-End is composed of three different parts.
|
||||
## Parser
|
||||
A Parser is a function that takes a string of source code and outputs a structured representation of the program. This part usually uses Menhir, a parser generator compatible with OCaml.
|
||||
Its files are in `parser/parser_name`.
|
||||
## Concrete Syntax Tree
|
||||
The CST is the aforementioned structured representation of the program. Is is structurally very close to the source code, and is mostly an intermediary there because manipulating string is not practical.
|
||||
Its files are in `parser/parser_name`.
|
||||
## Simplifier
|
||||
A Simplifier is a function that takes a CST and outputs the corresponding Common AST. This is the actual bridge between a given syntax and LIGO.
|
||||
Its files are in `simplify/parser_name`.
|
||||
@ -0,0 +1,17 @@
|
||||
---
|
||||
id: version-next-middle-end
|
||||
title: Middle End
|
||||
original_id: middle-end
|
||||
---
|
||||
|
||||
The Middle-End is the core of LIGO. It is also composed of three parts.
|
||||
## Common AST
|
||||
The Common AST is the closest thing to what could be called “LIGO lang”. As such, it should be as simple as possible. Collapsing particular cases in more general constructs is encouraged. Documenting it is crucial for people who’ll write new parsers or editor support for Front-end related things.
|
||||
Its files are in `ast_simplified/`, of interest is the definition of the AST itself in `ast_simplified/types.ml`.
|
||||
## Type Checker
|
||||
The Type Checker, among other things, checks that a given AST is valid with regard to type-safety. It also annotates expressions with their types, free-variables and local environments.
|
||||
As time passes, we want to make the type-system stronger, to encode arbitrarily complex properties in an extensible manner.
|
||||
Its files are in `typer/`.
|
||||
## Typed AST
|
||||
The Typed AST is the result of Type Checker. On top of it, we also want to define/export many features aiming at making building tools on top LIGO as easy as possible.
|
||||
Its files are in `ast_typed/`, of interest is the definition of the Typed AST itself in `ast_typed/types.ml`.
|
||||
@ -0,0 +1,17 @@
|
||||
---
|
||||
id: version-next-overview
|
||||
title: Overview
|
||||
original_id: overview
|
||||
---
|
||||
|
||||
After going through the design principles and a few considerations linked to them, getting the Big Picture needs diving in technical matters.
|
||||
|
||||
|
||||
|
||||
As shown in the Schema, LIGO’s compiler is separated in roughly 3 separate parts:
|
||||
|
||||
- The Middle End. This is the core of LIGO. It defines its core data-structure (the Common AST), and its type-checking algorithm.
|
||||
|
||||
- The Front End. This is the bridge between a given syntax and the Common AST.
|
||||
|
||||
- The Back End. This is the bridge between the Common AST and a given compilation target. Currently, our only target is Michelson, but we’ll also target Marigold, and if Tezos moves to Web Assembly, Web Assembly.
|
||||
@ -0,0 +1,22 @@
|
||||
---
|
||||
id: version-next-vendors
|
||||
title: Vendors
|
||||
original_id: vendors
|
||||
---
|
||||
|
||||
Next to LIGO’s main pipeline, we use some other libraries, that are in the folder `vendors`.
|
||||
## ligo-utils
|
||||
This, quite expectedly, defines utilities that are used in LIGO.
|
||||
There are three kinds of utilities, corresponding to their dependencies.
|
||||
|
||||
`tezos-utils` contain utilities that depend on some Tezos libraries.
|
||||
|
||||
`proto-alpha-utils` contain utilities that depend on the compilation of some Tezos protocol. It is very big and thus can’t be compiled in JS. This is because of a dependency to this that we don’t have LIGO in the browser yet.
|
||||
|
||||
`simple-utils` contain most utilities. For instance, in `simple-utils` are `X_list` and `X_option`, that extend the `List` module and the `option` type found in `Pervasives`.
|
||||
|
||||
Of particular interest in `simple-utils` is `trace.ml`, a module used pervasively in LIGO’s code-base. It deals with exceptions (and soon enough debugging annotations) in a functional manner. It offers a lot of utilities to build, combine and propagate exceptions. Given it’s used everywhere, that it relies on some advanced features of OCaml (higher order functions, ppx preprocessing) and that it exposes **a lot** of functions, it’s a good idea to look at this file’s documentation.
|
||||
## tezos-modded
|
||||
`tezos-modded` is a modded version of Tezos. There are modifications in it that are quite useful (exposing more functions from the protocol, giving more options to functions already defined), but not integrated yet.
|
||||
It should in the end be integrated into the Tezos protocol, but until then, we use this.
|
||||
|
||||
@ -0,0 +1,11 @@
|
||||
---
|
||||
id: version-next-origin
|
||||
title: Origin
|
||||
original_id: origin
|
||||
---
|
||||
|
||||
LIGO is a programming language that aims to provide developers with an uncomplicated and safer way to implement smart-contracts. LIGO is currently being implemented for the Tezos blockchain and as a result, it compiles down to Michelson - the native smart-contract language of Tezos.
|
||||
|
||||
> Smart-contracts are programs that run within a blockchain network.
|
||||
|
||||
LIGO was initially meant to be a language for developing Marigold, on top of a hacky framework called Meta-Michelson. However, due to the attention received by the Tezos community, a decision has been put into action to develop LIGO as a standalone language that will support Tezos directly as well.
|
||||
@ -0,0 +1,46 @@
|
||||
---
|
||||
id: version-next-philosophy
|
||||
title: Philosophy
|
||||
original_id: philosophy
|
||||
---
|
||||
|
||||
To understand LIGO’s design choices, it’s important to get its philosophy. There are two main concerns that we have in mind when building LIGO.
|
||||
|
||||
|
||||
|
||||
## Safety
|
||||
Once a smart-contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart-contracts.
|
||||
|
||||
### Automated Testing
|
||||
Automated Testing is the process through which a program will run some other program, and check that this other program behaves correctly.
|
||||
There already is a testing library for LIGO programs written in OCaml that is used to test LIGO itself. Making it accessible to users will greatly improve safety. A way to do so would be to make it accessible from within LIGO.
|
||||
|
||||
### Static Analysis
|
||||
Static analysis is the process of having a program analyze another one.
|
||||
For instance, type systems are a kind of static analysis through which it is possible to find lots of bugs. There is already a fairly simple type system in LIGO, and we plan to make it much stronger.
|
||||
|
||||
### Conciseness
|
||||
Writing less code gives you less room to introduce errors and that's why LIGO encourages writing lean rather than chunky smart-contracts.
|
||||
|
||||
---
|
||||
|
||||
## Ergonomics
|
||||
Having an ergonomic product is crucial on multiple levels:
|
||||
Making features easily accessible ensures they’ll actually get used.
|
||||
Not wasting users time on idiosyncrasies frees more time for making contracts safer or building apps.
|
||||
Keeping users in a Flow state makes it possible to introduce more complex features in the language.
|
||||
There are multiple ways to improve ergonomics.
|
||||
|
||||
### The Language
|
||||
LIGO should contain as few surprises as possible. This is usually known as the principle of least surprise.
|
||||
|
||||
Most programmers who will use LIGO have already spent a lot of time learning to develop in an existing language, with its own set of conventions and expectations. These expectations are often the most important to accommodate. This is why C-style syntaxes are especially popular (e.g. JavaScript), C-style is well known and new languages want to take advantage of that familiarity. Therefore as an extension of the principle of least surprise, LIGO supports more than one syntax. The least surprising language for a new developer is the one that they have already learned how to use. It’s probably not practical to replicate the syntax of every programming language, so LIGO takes the approach of replicating the structure used by languages from a particular paradigm.
|
||||
|
||||
It is packaged in a Docker container, so that no particular installation instructions are required.
|
||||
|
||||
### Editor Support
|
||||
Without editor support, a lot of manipulations are very cumbersome. Checking for errors, testing, examining code, refactoring code, etc. This is why there is ongoing work on editor support, starting with highlighting and code-folding.
|
||||
|
||||
### Docs
|
||||
Docs include documentation of the languages, tutorials, as well as examples and design patterns.
|
||||
We’re a long way from there. But having extensive docs is part of our goals.
|
||||
@ -0,0 +1,21 @@
|
||||
---
|
||||
id: version-next-long-term
|
||||
title: Longer term
|
||||
original_id: long-term
|
||||
---
|
||||
|
||||
Soon enough, the Schema for the front-end will look like this:
|
||||
|
||||
|
||||
|
||||
Basically, as we support more syntaxes (up to half a dozen), we’ll have a bigger need for a unified representation and generation of the helpers around it.
|
||||
For instance:
|
||||
Parsers. So far, parsers are generated by LR grammars. LR grammars have a steep learning curve, regularly making not worth it for someone to learn the whole formalism to extend a given grammar with a few cases. Generating those LR Grammars would thus save a lot of time.
|
||||
Displayers. The idea is that if you can parse and display code in a given syntax, it becomes much easier to have a translator between each syntax. So that not only it becomes possible for users to write code in their favorite syntax, but also to only read code in their favorite syntax.
|
||||
BNFs. BNF grammars are a common formalism to represent grammars. They are understood by many tools, and are an easy way to document a given syntax.
|
||||
## Super Type System
|
||||
Soon enough, the Schema for the middle-end will look like this:
|
||||
|
||||
Basically, this schema shows that the Back-End will stop being the main consumer of the Typed AST, and the External World will in its stead.
|
||||
As such, annotating the AST with quality information, documenting it and exposing the libraries that produced the information in the first place will be paramount.
|
||||
The imagined type-system so far is a mixture of MLF, extensible data-types and Algebraic Effects.
|
||||
@ -0,0 +1,21 @@
|
||||
---
|
||||
id: version-next-short-term
|
||||
title: Short term
|
||||
original_id: short-term
|
||||
---
|
||||
|
||||
## Documentation and Testing
|
||||
We lack documentation and tests. Top priority.
|
||||
Tests are needed at multiple levels:
|
||||
Unit tests. Most utility functions should be tested individually.
|
||||
Interface tests. Parts of the pipeline (Typer, Transpiler-Compiler, etc.) should be tested as black boxes.
|
||||
Integration tests. Typical user scenarios, as interacted with the CLI, should be tested.
|
||||
## Exposing Features
|
||||
Many features have already been developed or nearly developed, and mostly need to be shown some attention, and then be exposed to the outside world, for instance:
|
||||
Testing LIGO code
|
||||
Step-by-step interpreter
|
||||
LIGO in the browser
|
||||
Propagating source locations for error messages
|
||||
Dry-running a contract
|
||||
## Refactoring
|
||||
For the longer-term, it’s crucial to refactor big parts of the code base. This is needed to lower the complexity of the code base, so that it’s easier both for everyone (including API consumers) to interact with it.
|
||||
@ -0,0 +1,45 @@
|
||||
---
|
||||
id: version-next-language-basics-entrypoints
|
||||
title: Entrypoints
|
||||
original_id: language-basics-entrypoints
|
||||
---
|
||||
|
||||
## Defining an entry point
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--Pascaligo-->
|
||||
```Pascal
|
||||
function main (const p : int ; const s : int) : (list(operation) * unit) is
|
||||
block {skip} with ((nil : list(operation)), s + 1)
|
||||
```
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
|
||||
## Multiple entry points
|
||||
|
||||
Multiple entrypoints are currently not supported in Michelson, however with Ligo, you can work that around by using variants.
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--Pascaligo-->
|
||||
```Pascal
|
||||
// variant defining pseudo multi-entrypoint actions
|
||||
type action is
|
||||
| Increment of int
|
||||
| Decrement of int
|
||||
|
||||
function add (const a : int ; const b : int) : int is
|
||||
block { skip } with a + b
|
||||
|
||||
function subtract (const a : int ; const b : int) : int is
|
||||
block { skip } with a - b
|
||||
|
||||
// real entrypoint that re-routes the flow based on the action provided
|
||||
function main (const p : action ; const s : int) : (list(operation) * int) is
|
||||
block {skip} with ((nil : list(operation)),
|
||||
case p of
|
||||
| Increment n -> add(s, n)
|
||||
| Decrement n -> subtract(s, n)
|
||||
end)
|
||||
```
|
||||
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
@ -0,0 +1,23 @@
|
||||
---
|
||||
id: version-next-language-basics-functions
|
||||
title: Functions
|
||||
original_id: language-basics-functions
|
||||
---
|
||||
|
||||
## Defining a function
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--Pascaligo-->
|
||||
```Pascal
|
||||
// multiply(1, 2) = 2
|
||||
function multiply (const a : int ; const b : int) : int is
|
||||
begin
|
||||
const result : int = a * b ;
|
||||
end with result
|
||||
|
||||
// add(1, 2) = 3
|
||||
function add (const a : int ; const b : int) : int is
|
||||
block { skip } with a + b
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
@ -0,0 +1,13 @@
|
||||
---
|
||||
id: version-next-language-basics-operators
|
||||
title: Operators
|
||||
original_id: language-basics-operators
|
||||
---
|
||||
|
||||
## Available operators
|
||||
|
||||
|Michelson |Pascaligo |Description |
|
||||
|--- |--- |--- |
|
||||
| `SENDER` | `sender` | Address that initiated the current transaction
|
||||
| `SOURCE` | `source` | Address that initiated the transaction, which triggered the current transaction. (useful e.g. when there's a transaction sent by another contract)
|
||||
| `AMOUNT` | `amount` | Amount of tez sent by the transaction that invoked the contract
|
||||
@ -0,0 +1,19 @@
|
||||
---
|
||||
id: version-next-language-basics-variables
|
||||
title: Variables
|
||||
original_id: language-basics-variables
|
||||
---
|
||||
|
||||
## Defining a variable
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--Pascaligo-->
|
||||
```Pascal
|
||||
// int
|
||||
const four : int = 4;
|
||||
|
||||
// string
|
||||
const name : string = "John Doe";
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
@ -0,0 +1,39 @@
|
||||
---
|
||||
id: version-next-setup-installation
|
||||
title: Installation
|
||||
original_id: setup-installation
|
||||
---
|
||||
|
||||
There are currently two ways to get started with Ligo, both of those will allow you to use the Ligo CLI with your contracts. You can choose to use either the Docker image, or to compile & build the Ligo CLI yourself.
|
||||
|
||||
## Dockerized installation (recommended)
|
||||
|
||||
> 🐳 You can find instructions on how to install Docker [here](https://docs.docker.com/install/).
|
||||
|
||||
Easiest way to use LIGO is through the Docker image available at [Docker Hub](https://hub.docker.com/r/ligolang/ligo). Sources for the image can be found on [Gitlab](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
||||
You can either run the docker image yourself, or you can setup a global ligo executable as shown below.
|
||||
|
||||
### Setting up a globally available `ligo` executable
|
||||
|
||||
> You can install additional ligo versions by replacing `next` with the required version number
|
||||
|
||||
```zsh
|
||||
# next (pre-release)
|
||||
curl https://gitlab.com/ligolang/ligo/blob/master/scripts/installer.sh | bash "next"
|
||||
|
||||
# e.g. 1.0.0 (stable)
|
||||
curl https://gitlab.com/ligolang/ligo/blob/master/scripts/installer.sh | bash "1.0.0"
|
||||
```
|
||||
|
||||
**Verify your ligo installation by running:**
|
||||
```zsh
|
||||
ligo --help
|
||||
```
|
||||
|
||||
|
||||
## Manual installation (advanced)
|
||||
|
||||
For now, please refer to the steps described in the [Dockerfile](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,35 @@
|
||||
{
|
||||
"version-next-docs": {
|
||||
"Setup": [
|
||||
"version-next-setup-installation"
|
||||
],
|
||||
"Language Basics": [
|
||||
"version-next-language-basics-variables",
|
||||
"version-next-language-basics-functions",
|
||||
"version-next-language-basics-entrypoints",
|
||||
"version-next-language-basics-operators"
|
||||
],
|
||||
"API": [
|
||||
"version-next-api-cli-commands"
|
||||
]
|
||||
},
|
||||
"version-next-contributors-docs": {
|
||||
"Introduction": [
|
||||
"version-next-contributors/origin",
|
||||
"version-next-contributors/philosophy",
|
||||
"version-next-contributors/getting-started",
|
||||
"version-next-contributors/documentation-and-releases"
|
||||
],
|
||||
"Big Picture": [
|
||||
"version-next-contributors/big-picture/overview",
|
||||
"version-next-contributors/big-picture/front-end",
|
||||
"version-next-contributors/big-picture/middle-end",
|
||||
"version-next-contributors/big-picture/back-end",
|
||||
"version-next-contributors/big-picture/vendors"
|
||||
],
|
||||
"Road Map": [
|
||||
"version-next-contributors/road-map/short-term",
|
||||
"version-next-contributors/road-map/long-term"
|
||||
]
|
||||
}
|
||||
}
|
||||
1
gitlab-pages/website/versions.json
Normal file
1
gitlab-pages/website/versions.json
Normal file
@ -0,0 +1 @@
|
||||
["next"]
|
||||
@ -3,10 +3,21 @@
|
||||
# curl https://gitlab.com/ligolang/ligo/blob/master/scripts/installer.sh | bash
|
||||
# Make sure the marigold/ligo image is published at docker hub first
|
||||
set -euET -o pipefail
|
||||
echo "Installing LIGO"
|
||||
version=$1
|
||||
printf "\nInstalling LIGO ($version)\n\n"
|
||||
|
||||
# Install the ligo.sh from master
|
||||
wget https://gitlab.com/ligolang/ligo/blob/master/scripts/ligo.sh
|
||||
if [ $version = "next" ]
|
||||
then
|
||||
# Install the ligo.sh from master
|
||||
wget https://gitlab.com/ligolang/ligo/raw/dev/scripts/ligo.sh
|
||||
else
|
||||
# Install the ligo.sh from master
|
||||
wget https://gitlab.com/ligolang/ligo/raw/master/scripts/ligo.sh
|
||||
fi
|
||||
|
||||
|
||||
# Overwrite LIGO version in the executable
|
||||
sed -i '' "s/latest/$version/g" ligo.sh
|
||||
|
||||
# Copy the exucutable to the appropriate directory
|
||||
sudo cp ligo.sh /usr/local/bin/ligo
|
||||
@ -14,7 +25,7 @@ sudo chmod +x /usr/local/bin/ligo
|
||||
rm ligo.sh
|
||||
|
||||
# Pull the docker image used by ligo.sh
|
||||
docker pull ligolang/ligo:latest
|
||||
docker pull "ligolang/ligo:$version"
|
||||
|
||||
# Installation finished, try running 'ligo' from your CLI
|
||||
echo "Installation successful, try to run 'ligo --help' now. \n"
|
||||
printf "\nInstallation successful, try to run 'ligo --help' now.\n"
|
||||
Loading…
Reference in New Issue
Block a user