Merge pull request #2077 from ethereum/docsMove

copying docs from remix/docs to remix-ide/docs
pull/1/head
Rob 6 years ago committed by GitHub
commit 74ed4b6321
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
  1. 1
      .gitignore
  2. 216
      docs/Makefile
  3. 11
      docs/code_contribution_guide.md
  4. 14
      docs/community.md
  5. 28
      docs/compile.md
  6. 305
      docs/conf.py
  7. 69
      docs/contract_metadata.md
  8. 108
      docs/create_deploy.md
  9. 14
      docs/debugger.md
  10. 54
      docs/file_explorer.md
  11. BIN
      docs/images/a-Runtab-deploy-atAddress.png
  12. BIN
      docs/images/a-contract-inputs.png
  13. BIN
      docs/images/a-debug1-deploy.png
  14. BIN
      docs/images/a-debug2-udapp1.png
  15. BIN
      docs/images/a-debug2-udapp1a.png
  16. BIN
      docs/images/a-debug3-udapp2.png
  17. BIN
      docs/images/a-debug4-value-loc.png
  18. BIN
      docs/images/a-debug5-term-debug-but.png
  19. BIN
      docs/images/a-debug6-term-txn-hash.png
  20. BIN
      docs/images/a-debug7-debugger.png
  21. BIN
      docs/images/a-debug8-top3.png
  22. BIN
      docs/images/a-debug9-buttons.png
  23. BIN
      docs/images/a-debugger.png
  24. BIN
      docs/images/a-file-explorer-buttons-big.png
  25. BIN
      docs/images/a-file-explorer-buttons.png
  26. BIN
      docs/images/a-file-explorer1.png
  27. BIN
      docs/images/a-home-page.png
  28. BIN
      docs/images/a-hometab.png
  29. BIN
      docs/images/a-icon-swap.png
  30. BIN
      docs/images/a-icons-at-load.png
  31. BIN
      docs/images/a-jvm-calling-instance.png
  32. BIN
      docs/images/a-jvm-instance.png
  33. BIN
      docs/images/a-jvm.png
  34. BIN
      docs/images/a-layout1.png
  35. BIN
      docs/images/a-layout1c.png
  36. BIN
      docs/images/a-old-tuto_basicimport.png
  37. BIN
      docs/images/a-old-tuto_importgit.png
  38. BIN
      docs/images/a-old-tuto_importswarm.png
  39. BIN
      docs/images/a-plug.png
  40. BIN
      docs/images/a-plugin-man-local.png
  41. BIN
      docs/images/a-remixd-success.png
  42. BIN
      docs/images/a-runtab-recorder.png
  43. BIN
      docs/images/a-runtab1.png
  44. BIN
      docs/images/a-sol-compiler.png
  45. BIN
      docs/images/a-sol-editor.png
  46. BIN
      docs/images/a-static-analysis.png
  47. BIN
      docs/images/a-terminal-and-more.png
  48. BIN
      docs/images/a-themes.png
  49. BIN
      docs/images/a-udapp-inputs.png
  50. BIN
      docs/images/a-udapp-multi-param-man.png
  51. BIN
      docs/images/a-unit-testing1.png
  52. 39
      docs/import.md
  53. 89
      docs/index.rst
  54. 54
      docs/layout.md
  55. 10
      docs/locations.md
  56. 263
      docs/make.bat
  57. 22
      docs/plugin_manager.md
  58. 37
      docs/remix_tutorials_github.md
  59. 60
      docs/remixd.md
  60. 282
      docs/run.md
  61. 14
      docs/settings.md
  62. 18
      docs/solidity_editor.md
  63. 33
      docs/static_analysis.md
  64. 9
      docs/support.md
  65. 21
      docs/terminal.md
  66. 225
      docs/tutorial_debug.md
  67. 279
      docs/tutorial_geth-remix.md
  68. 57
      docs/udapp.md
  69. 41
      docs/unittesting.md

1
.gitignore vendored

@ -2,6 +2,7 @@
.vscode
build
node_modules
docs/_build
reports
soljson.js
soljson.js.*

@ -0,0 +1,216 @@
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = _build
# User-friendly check for sphinx-build
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
endif
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " applehelp to make an Apple Help Book"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " xml to make Docutils-native XML files"
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
@echo " coverage to run coverage check of the documentation (if enabled)"
.PHONY: clean
clean:
rm -rf $(BUILDDIR)/*
.PHONY: html
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
.PHONY: dirhtml
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
.PHONY: singlehtml
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
.PHONY: pickle
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
.PHONY: json
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
.PHONY: htmlhelp
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
.PHONY: qthelp
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Remix.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Remix.qhc"
.PHONY: applehelp
applehelp:
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
@echo
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
@echo "N.B. You won't be able to view it unless you put it in" \
"~/Library/Documentation/Help or install it in your application" \
"bundle."
.PHONY: devhelp
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/Remix"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Remix"
@echo "# devhelp"
.PHONY: epub
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
.PHONY: latex
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
.PHONY: latexpdf
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: latexpdfja
latexpdfja:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through platex and dvipdfmx..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: text
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
.PHONY: man
man:
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
.PHONY: texinfo
texinfo:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
.PHONY: info
info:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
.PHONY: gettext
gettext:
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
.PHONY: changes
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
.PHONY: linkcheck
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
.PHONY: doctest
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
.PHONY: coverage
coverage:
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
@echo "Testing of coverage in the sources finished, look at the " \
"results in $(BUILDDIR)/coverage/python.txt."
.PHONY: xml
xml:
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
@echo
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
.PHONY: pseudoxml
pseudoxml:
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
@echo
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."

@ -0,0 +1,11 @@
Code contribution guide
=======================
Remix is an open source tool and we encourage anyone to help us improve our tool.
You can do that by opening issues, giving feedback or by contributing a pull request
to our codebase.
The Remix application is built with JavaScript and it doesn't use any framework. We only
rely on selected set of npm modules, like `yo-yo`, `csjs-inject` and others. Check out the `package.json` files in the Remix submodules to learn more about the stack.
To learn more, please visit our [GitHub page](https://github.com/ethereum/remix-ide).

@ -0,0 +1,14 @@
Community
=======================
We know that blockchain ecosystem is very new and that lots of information is scattered around the web.
That is why we created a community support channel where we and other users try to answer your questions if
you get stuck using Remix. Please, join [the community](https://gitter.im/ethereum/remix) and ask for help.
For anyone who is interested in developing a custom plugin for Remix or who wants to contribute to the codebase,
we opened a [contributors' channel](https://gitter.im/ethereum/remix-dev) especially for developers working on Remix tools.
We would kindly ask you to respect the space and to use it for
getting help with your work and the developers' channel for discussions related to working on Remix codebase. If you have
ideas for collaborations or you want to promote your project, try to find some more appropriate channels to do so. Or you can contact
the main contributors directly on Gitter or Twitter.

@ -0,0 +1,28 @@
Compiler (Solidity)
===================
Clicking the Solidity icon in the icon panel brings you to the Solidty Compiler.
Compiling is triggered when you click the compile button ( **A. in image below**). If you want the file to be compiled each time the file is saved or when another file is selected - check the auto compile checkbox ( **B. in image below**).
If the contract has a lot of dependencies it can take a while to compile - so you use autocompilation at your discretion.
![](images/a-sol-compiler.png)
After each compilation, a list is updated with all the newly compiled
contracts. The contract compiled can be selected with the Contract pulldown menu ( **C. in image below**). Multiple contracts are compiled when one contract imports other contracts. Selecting a contract will show information about that one.
When the "Compilation Details" button is clicked ( **D. in image below**), a modal opens displaying detailed information about the current selected contract.
From this tab, you can also publish your contract to Swarm (only non
abstract contracts can be published).
Published data notably contains the `abi` and solidity source code.
After a contract is published, you can find its metadata information
using the bzz URL located in the details modal dialog `SWARM LOCATION`.
Compilation Errors and Warning are displayed below the contract section.
At each compilation, the static analysis tab builds a report. It is very
valuable when addressing reported issues even if the compiler doesn't
complain. ([see more](static_analysis.html))

@ -0,0 +1,305 @@
# -*- coding: utf-8 -*-
#
# Remix documentation build configuration file, created by
# sphinx-quickstart on Mon Feb 20 12:16:16 2017.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
# sys.path.insert(0, os.path.abspath('.'))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = []
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
# source_suffix = ['.rst', '.md']
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'Remix, Ethereum-IDE'
copyright = u'2018, Remix'
author = u'Remix team'
github_doc_root = 'https://github.com/ethereum/remix/tree/master/docs/'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = u'1'
# The full version, including alpha/beta/rc tags.
release = u'1'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['_build']
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
highlight_language = 'JavaScript'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (relative to this directory) to use as a favicon of
# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Language to be used for generating the HTML full-text search index.
# Sphinx supports the following languages:
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
#html_search_language = 'en'
# A dictionary with options for the search language support, empty by default.
# Now only 'ja' uses this config value
#html_search_options = {'type': 'default'}
# The name of a javascript file (relative to the configuration directory) that
# implements a search results scorer. If empty, the default will be used.
#html_search_scorer = 'scorer.js'
# Output file base name for HTML help builder.
htmlhelp_basename = 'Remixdoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
# Latex figure (float) alignment
#'figure_align': 'htbp',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'Remix.tex', u'Remix Documentation',
u'yann300', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'remix', u'Remix Documentation',
[author], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'Remix', u'Remix Documentation',
author, 'Remix', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False
from recommonmark.parser import CommonMarkParser
source_suffix = ['.rst', '.md']
source_parsers = {'.md': CommonMarkParser}
# app setup hook
# def setup(app):
# app.add_config_value('recommonmark_config', {
# 'url_resolver': lambda url: github_doc_root + url,
# 'enable_auto_toc_tree': True,
# 'enable_eval_rst': True,
# 'enable_auto_doc_ref': True,
# }, True)
# app.add_transform(AutoStructify)

@ -0,0 +1,69 @@
Build Artifact
==============
As compilation succeed Remix create a JSON file for each compiled contract.
These JSON files contains several metadata
Library Deployment
------------------
By default Remix automatically deploy needed libraries.
`linkReferences` contains a map representing libraries which depend on the current contract.
Values are addresses of libraries used for linking the contract.
`autoDeployLib` defines if the libraries should be auto deployed by Remix or if the contract should be linked with libraries described in `linkReferences`
Note that Remix will resolve addresses corresponding to the current network.
By default, a configuration key follow the form: `<network_name>:<networkd_id>`, but it is also possible
to define `<network_name>` or `<network_id>` as keys.
```
{
"VM:-": {
"linkReferences": {
"browser/Untitled.sol": {
"lib": "<address>",
"lib2": "<address>"
}
},
"autoDeployLib": true
},
"main:1": {
"linkReferences": {
"browser/Untitled.sol": {
"lib": "<address>",
"lib2": "<address>"
}
},
"autoDeployLib": true
},
"ropsten:3": {
"linkReferences": {
"browser/Untitled.sol": {
"lib": "<address>",
"lib2": "<address>"
}
},
"autoDeployLib": true
},
"rinkeby:4": {
"linkReferences": {
"browser/Untitled.sol": {
"lib": "<address>",
"lib2": "<address>"
}
},
"autoDeployLib": true
},
"kovan:42": {
"linkReferences": {
"browser/Untitled.sol": {
"lib": "<address>",
"lib2": "<address>"
}
},
"autoDeployLib": true
}
}
```

@ -0,0 +1,108 @@
Creating and Deploying a Contract
================================
There are 3 type of environments Remix can be plugged to:
`Javascript VM`, `Injected provider`, or `Web3 provider`. (for details see [Running transactions](http://remix.readthedocs.io/en/latest/run_tab.html))
Both `Web3 provider` and `Injected provider` require the use of an
external tool.
The external tool for `Web3 provider` is an Ethereum node and for
`Injected provider` Metamask.
The `JavaScript VM` mode is convenient because each execution runs in
your browser and you don't need any other software or Ethereum node to run it.
So, it is the easiest test environment - **no setup required!**
But keep in mind that reloading the browser when you are in the Javascript VM will restart Remix in an empty state.
For performance purposes ( which is to say - for testing in an environment that is closest to the mainnet), it might also be better to use an external node.
Selecting the VM mode
---------------------
Make sure the VM mode is selected. All accounts displayed in `Accounts`
should have 100 ether.
Sample contract
---------------
```
{.sourceCode .none}
pragma solidity ^0.5.1;
contract testContract {
uint value;
constructor (uint _p) public {
value = _p;
}
function setP(uint _n) payable public {
value = _n;
}
function setNP(uint _n) public {
value = _n;
}
function get () view public returns (uint) {
return value;
}
}
```
This contract is very basic. The goal is to quickly start to create and
to interact with a sample contract.
Deploying an instance
---------------------
The `Compile tab` displays information related to the current contract
(note that there can be more than one) (see ../compile\_tab).
Moving on, in the `Run tab` select, `JavaScript VM` to specify that you
are going to deploy an instance of the contract in the `JavaScript VM`
state.
![](images/a-jvm.png)
The constructor of `Ballot.sol` needs a parameter (of type `uint8`).
Give any value and click on `Deploy`.
The transaction which deploys the instance of `Ballot` is created.
In a "normal" blockchain, it can take several seconds to execute. This
is the time for the transaction to be mined. However, because we are
using the `JavaScript VM`, our execution is immediate.
The terminal will inform you about the transaction. You can see details
there and start debugging.
The newly created instance is displayed in the `run tab`.
![](images/a-jvm-instance.png)
Interacting with an instance
----------------------------
This new instance contains 3 actions which corresponds to the 3
functions (`setP`, `setPN`, `get`). Clicking on `SetP` or `SetPN` will
create a new transaction.
Note that `SetP` is `payable` (red button) : it is possible to send
value (Ether) to the contract.
`SetPN` is not payable (orange button - depending on the theme) : it is not possible to send
value (Ether) to the contract.
Clicking on `get` will not execute a transaction (usually its a blue button - depending on the theme). It doesn't execute a transaction because a `get` does not modify the state (variable
`value`) of this instance.
As `get` is `view` you can see the return value just below the
action.
![](images/a-jvm-calling-instance.png)

@ -0,0 +1,14 @@
Debugger
========
This module allows you to debug the transaction. It can be used to
deploy transactions created from Remix and already mined transactions.
(debugging works only if the current environment provides the necessary
features).
To get to the debugger - you can click the debug button in the terminal when a successful or failed transaction appears there. You can also load the module from the plugin manager and then click the bug in the icon panel. Or you can get to the debugger by running the debug command in the console.
![](images/a-debugger.png)
To learn more about how to use this tool go to the [debugger tutorial](tutorial_debug.html).

@ -0,0 +1,54 @@
File Explorer
=============
To get to the file explorers - click the file explorers icon.
![](images/a-file-explorer1.png)
The file explorer lists by default all the files stored in your browser.
You can see them in the browser folder. You can always rename, remove or
add new files to the file explorer.
Note that clearing the browser storage will permanently delete all the
solidity files you wrote. To avoid this, you can use Remixd, which
enables you to store and sync files in the browser with your local
computer ( for more information see [remixd](remixd.html) ).
![](images/a-file-explorer-buttons.png)
We will start by reviewing at the icons at the top left - from left to
the right:
Create new File
---------------
Creates a new `untitled.sol` file in Remix.
Add Local File
--------------
Allows you to select files from the local file system and import them to
the Remix browser storage.
Publish to Gist
---------------
Publishes all files from the browser folder to a gist.
Gist API has changed in 2018 and it unfortunately requires users to be authenticated to be able to publish a gist.
Click [this link](https://github.com/settings/tokens) to Github tokens setup and select Generate new token.
Then check only Create gists checkbox and generate a new token.
Then paste it in Remix (right panel/Settings tab) and click Save. Now you should be able to use the feature.
Copy to another Remix instance
------------------------
Enables you to copy files from the browser storage to another instance
(URL) of Remix.
Connect your filesystem to Remix
--------------------
Allows to sync between Remix and your local file system (see
[more about RemixD](remixd.html)).

Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 196 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 117 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

@ -0,0 +1,39 @@
Importing Source Files in Solidity
==================================
It is essential to know all many techniques for importing files.
For a tutorial about importing files see this [tutorial](https://github.com/ethereum/remix-workshops/tree/master/loading_via_npm_github_plugin).
For a detailed explanation of the `import` keyword see the
[Solidity documentation](https://solidity.readthedocs.io/en/develop/layout-of-source-files.html?highlight=import#importing-other-source-files)
Here are a some of the main methods of importing a file:
Importing a file from the browser's local storage
-------------------------------------------------
Files in Remix can be imported just by specifying their path. Please use ./ for relative paths to increase portability.
![](images/a-old-tuto_basicimport.png)
Importing a file from your computer's filesystem
-------------------------------------------------
This method uses **remixd** - the remix daemon. Please go to the [remixd tutorial](remixd.html) for instructions about how to bridge the divide between the browser and your computers filesystem.
Importing from GitHub
---------------------
It is possible to import files directly from GitHub with URLs like
`https://github.com/<owner>/<repo>/<path to the file>`.
![](images/a-old-tuto_importgit.png)
Importing from Swarm
--------------------
Files can be imported using all URLs supported by swarm. If you do not
have a swarm node, then use swarm-gateways.net.
![](images/a-old-tuto_importswarm.png)

@ -0,0 +1,89 @@
Welcome to Remix documentation!
===============================
Remix is a powerful, open source tool that helps you write Solidity contracts straight from the browser.
Written in JavaScript, Remix supports both usage in the browser and locally.
Remix also supports testing, debugging and deploying of smart contracts and much more.
Our Remix project with all its features is available
at `remix.ethereum.org <http://remix.ethereum.org>`__ and more information can be found in these
docs. Our IDE tool is available at `our GitHub repository
<https://github.com/ethereum/remix-ide>`__.
This set of documents covers instructions on how to use Remix and some tutorials to help you get started.
Useful links:
- `Solidity documentation <https://solidity.readthedocs.io>`__
- `Remix alpha <http://remix-alpha.ethereum.org>`__ - The version where we test new Remix release (not stable!).
- `Ethereum StackExchange for Remix <https://ethereum.stackexchange.com/questions/tagged/remix>`__
- `Community support channel <https://gitter.im/ethereum/remix>`__
- `Ðapp Developer resources (Ethereum wiki) <https://github.com/ethereum/wiki/wiki/Dapp-Developer-Resources>`__
.. toctree::
:maxdepth: 2
:caption: New Layout Intro
layout
.. toctree::
:maxdepth: 2
:caption: Tour of default modules
file_explorer
plugin_manager
settings
solidity_editor
terminal
.. toctree::
:maxdepth: 2
:caption: Tour of typical solidity modules
compile
run
udapp
debugger
static_analysis
.. toctree::
:maxdepth: 2
:caption: Using Remix
contract_metadata
create_deploy
tutorial_debug
import
remixd
unittesting
.. toctree::
:maxdepth: 2
:caption: Building Plugins
remix_plugin.md
.. toctree::
:maxdepth: 2
:caption: URLs & Downloads
locations
.. toctree::
:maxdepth: 2
:caption: Tutorials and workshops slides
remix_tutorials_github
.. toctree::
:maxdepth: 2
:caption: Code contribution guide
code_contribution_guide
community
support

@ -0,0 +1,54 @@
Remix-IDE Layout
==============
The new structure
--------------------
![](images/a-layout1c.png)
1. Icon Panel - click to change which plugin appears in the Side Panel
2. Side Panel - Most but not all plugins will have their GUI here.
3. Main Panel - In the old layout this was just for editing files. In the tabs can be plugins or files for the IDE to compile.
4. Terminal - where you will see the results of your interactions with the GUI's. Also you can run scripts here.
Icon Panel at Page Load
-----------------------
When you load remix - the icon panel show these icons by default.
![](images/a-icons-at-load.png)
Everything in remix is now a plugin... so the **[Plugin Manager](#plugin-manager)** is very important.
In the old layout, each basic task in remix was separated into the tabs. Now these tabs are plugins.
But to activate a half a dozen plugins - (or however many you are using) each time the page load is **tedious**. So learn about the **[Environments](#environments)**.
Homepage
--------
![](images/a-hometab.png)
The homepage is located in a tab in the Main Panel.
You can also get there by clicking the remix logo at the top of the icon panel.
### Environments
Clicking on one of the environment buttons loads up a collection of plugins. We currently have a **Solidity** Button and a **Vyper** button. In the future you will be able to save your own environment.
To see all the plugins go to the **plugin manager** - by selecting the plug in the icon panel.
![](images/a-plug.png)
The environment buttons are time & sanity savers - so you don't need to go to the plugin manager to get started everytime you load the page.
Plugin Manager
---------------
In order to make Remix flexible for integrating changes into its functionality and for integrating remix into other projects (your's for example), we've now made everything a plugin. This means that you only load the functionality you need. It also means that you need a place to turn off and on plugins - as your needs change. This all happens in the plug manager.
The Plugin Manager is also the place you go when you are creating your own plugin and you want to load your local plugin into Remix. In that case you'd click on the "Connect to a Local Plugin" link at the top of the Plugin Manager panel.
Themes
---------------
So you want to work on Remix with a dark theme or a gray theme or just a different theme that the one you are currently looking at? Go to the settings tab and at the bottom is a choice of lots of bootstrap based themes.
![](images/a-themes.png)

@ -0,0 +1,10 @@
Finding Remix
=============
So if you've found the documentation to Remix but don't know where to find Remix or if you want to run the remix-ide locally and want to find out where to download it - this page is here to help.
- An online version is available at [https://remix.ethereum.org](https://remix.ethereum.org). This version is stable and is updated at almost every release.
- An alpha online version is available at [https://remix-alpha.ethereum.org](https://remix-alpha.ethereum.org). This is not a stable version.
- npm `remix-ide` package `npm install remix-ide -g`. `remix-ide` create a new instance of `Remix IDE` available at [http://127.0.0.1:8080](http://127.0.0.1:8080) and make the current folder available to Remix IDE by automatically starting `remixd`.
see [Connection to `remixd`](http://remix.readthedocs.io/en/latest/tutorial_remixd_filesystem.html) for more information about sharing local file with `Remix IDE`.
- Github release: [https://github.com/ethereum/remix-ide/releases](https://github.com/ethereum/remix-ide/releases) . The source code is packaged at every release but still need to be built using `npm run build`.

@ -0,0 +1,263 @@
@ECHO OFF
REM Command file for Sphinx documentation
if "%SPHINXBUILD%" == "" (
set SPHINXBUILD=sphinx-build
)
set BUILDDIR=_build
set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
set I18NSPHINXOPTS=%SPHINXOPTS% .
if NOT "%PAPER%" == "" (
set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%
)
if "%1" == "" goto help
if "%1" == "help" (
:help
echo.Please use `make ^<target^>` where ^<target^> is one of
echo. html to make standalone HTML files
echo. dirhtml to make HTML files named index.html in directories
echo. singlehtml to make a single large HTML file
echo. pickle to make pickle files
echo. json to make JSON files
echo. htmlhelp to make HTML files and a HTML help project
echo. qthelp to make HTML files and a qthelp project
echo. devhelp to make HTML files and a Devhelp project
echo. epub to make an epub
echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter
echo. text to make text files
echo. man to make manual pages
echo. texinfo to make Texinfo files
echo. gettext to make PO message catalogs
echo. changes to make an overview over all changed/added/deprecated items
echo. xml to make Docutils-native XML files
echo. pseudoxml to make pseudoxml-XML files for display purposes
echo. linkcheck to check all external links for integrity
echo. doctest to run all doctests embedded in the documentation if enabled
echo. coverage to run coverage check of the documentation if enabled
goto end
)
if "%1" == "clean" (
for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
del /q /s %BUILDDIR%\*
goto end
)
REM Check if sphinx-build is available and fallback to Python version if any
%SPHINXBUILD% 1>NUL 2>NUL
if errorlevel 9009 goto sphinx_python
goto sphinx_ok
:sphinx_python
set SPHINXBUILD=python -m sphinx.__init__
%SPHINXBUILD% 2> nul
if errorlevel 9009 (
echo.
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
echo.installed, then set the SPHINXBUILD environment variable to point
echo.to the full path of the 'sphinx-build' executable. Alternatively you
echo.may add the Sphinx directory to PATH.
echo.
echo.If you don't have Sphinx installed, grab it from
echo.http://sphinx-doc.org/
exit /b 1
)
:sphinx_ok
if "%1" == "html" (
%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The HTML pages are in %BUILDDIR%/html.
goto end
)
if "%1" == "dirhtml" (
%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
goto end
)
if "%1" == "singlehtml" (
%SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
goto end
)
if "%1" == "pickle" (
%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
if errorlevel 1 exit /b 1
echo.
echo.Build finished; now you can process the pickle files.
goto end
)
if "%1" == "json" (
%SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
if errorlevel 1 exit /b 1
echo.
echo.Build finished; now you can process the JSON files.
goto end
)
if "%1" == "htmlhelp" (
%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
if errorlevel 1 exit /b 1
echo.
echo.Build finished; now you can run HTML Help Workshop with the ^
.hhp project file in %BUILDDIR%/htmlhelp.
goto end
)
if "%1" == "qthelp" (
%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
if errorlevel 1 exit /b 1
echo.
echo.Build finished; now you can run "qcollectiongenerator" with the ^
.qhcp project file in %BUILDDIR%/qthelp, like this:
echo.^> qcollectiongenerator %BUILDDIR%\qthelp\Remix.qhcp
echo.To view the help file:
echo.^> assistant -collectionFile %BUILDDIR%\qthelp\Remix.ghc
goto end
)
if "%1" == "devhelp" (
%SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
if errorlevel 1 exit /b 1
echo.
echo.Build finished.
goto end
)
if "%1" == "epub" (
%SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The epub file is in %BUILDDIR%/epub.
goto end
)
if "%1" == "latex" (
%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
if errorlevel 1 exit /b 1
echo.
echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
goto end
)
if "%1" == "latexpdf" (
%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
cd %BUILDDIR%/latex
make all-pdf
cd %~dp0
echo.
echo.Build finished; the PDF files are in %BUILDDIR%/latex.
goto end
)
if "%1" == "latexpdfja" (
%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
cd %BUILDDIR%/latex
make all-pdf-ja
cd %~dp0
echo.
echo.Build finished; the PDF files are in %BUILDDIR%/latex.
goto end
)
if "%1" == "text" (
%SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The text files are in %BUILDDIR%/text.
goto end
)
if "%1" == "man" (
%SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The manual pages are in %BUILDDIR%/man.
goto end
)
if "%1" == "texinfo" (
%SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.
goto end
)
if "%1" == "gettext" (
%SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The message catalogs are in %BUILDDIR%/locale.
goto end
)
if "%1" == "changes" (
%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
if errorlevel 1 exit /b 1
echo.
echo.The overview file is in %BUILDDIR%/changes.
goto end
)
if "%1" == "linkcheck" (
%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
if errorlevel 1 exit /b 1
echo.
echo.Link check complete; look for any errors in the above output ^
or in %BUILDDIR%/linkcheck/output.txt.
goto end
)
if "%1" == "doctest" (
%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
if errorlevel 1 exit /b 1
echo.
echo.Testing of doctests in the sources finished, look at the ^
results in %BUILDDIR%/doctest/output.txt.
goto end
)
if "%1" == "coverage" (
%SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage
if errorlevel 1 exit /b 1
echo.
echo.Testing of coverage in the sources finished, look at the ^
results in %BUILDDIR%/coverage/python.txt.
goto end
)
if "%1" == "xml" (
%SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The XML files are in %BUILDDIR%/xml.
goto end
)
if "%1" == "pseudoxml" (
%SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml
if errorlevel 1 exit /b 1
echo.
echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml.
goto end
)
:end

@ -0,0 +1,22 @@
Plugin Manager
===================
## Everything is a PLUGIN in Remix
In order to integrate new tools made by us and by ...you into Remix, we've now made everything a plugin.
This architcture will also allow Remix or just parts of Remix to be integrated into other projects (your's for example).
This means that you only load the functionality you need.
It also means that you can turn off and on plugins - as your needs change.
This all happens in the plug manager.
The Plugin Manager is also the place you go when you are creating your own plugin and you want to load your local plugin into Remix.
To load your local plugin, you'd click on the "Connect to a Local Plugin" link at the top of the Plugin Manager panel.
![](images/a-plugin-man-local.png)
To learn more about how to create your own plugin, go to
[the README of remix-plugin repo](https://github.com/ethereum/remix-plugin).

@ -0,0 +1,37 @@
Remix Tutorials
=======================
There are a series of tutorials in our github repo [remix-workshops](https://github.com/ethereum/remix-workshops).
We are in the process of upgrading these tutorials to use the new Remix layout.
In this repo there tutorials for all levels.
There are tutorials for specific remix functionalities like:
***Deploying***
Multiple ways of loading files in Remix
Deploying with libraries
Deploying a proxy contract
***Testing***
Testing Examples
Continuous integration
***Remix Plugin Development***
Developing a plugin for Remix and deploying it to swarm
***Other***
EtherAtom (walkthrough slides + screencast)
Debugging transactions with Remix IDE
Recording and replaying transactions
Using a Pipeline plugin for developing Solidity contracts with demo video
Running scripts in the Remix terminal (batch deployment) (proxy deployment)
***Additional external workshops***
Using Oraclize plugin in Remix

@ -0,0 +1,60 @@
Remixd: Get access your local filesystem
=========================================
`remixd` is an npm module. Its purpose is to give the remix web
application access to a folder on your local computer.
The code of `remixd` is
[here](https://github.com/ethereum/remixd) .
`remixd` can be globally installed using the following command:
`npm install -g remixd`
Or just install it in the directory of your choice by removing the -g flag:
`npm install remixd`
Then from the terminal, the command `remixd -s <absolute-path-to-the-shared-folder> --remix-ide <your-remix-ide-URL-instance>` will start `remixd` and will share the given folder with remix-ide.
For example, to use remixd with Remix IDE ( and not the alpha version) use this command:
`remixd -s <absolute-path-to-the-shared-folder> --remix-ide https://remix.ethereum.org`
Make sure that if you use https://remix.ethereum.org (secure http) in the remixd command (like in the example above), that you are also pointing your browser to https://remix.ethereum.org and not to http://remix.ethereum.org (plain old insecure http). Or if you want to use http in the browser use http in the remixd command.
The folder is shared using a websocket connection between `Remix IDE`
and `remixd`.
Be sure the user executing `remixd` has read/write permission on the
folder.
There is an option to run remixd in read-only mode, use `--read-only` flag.
**Warning!**
`remixd` provides `full read and write access` to the given folder for `any
application` that can access the `TCP port 65520` on your local host.
From `Remix IDE`, in the Plugin Manager you need to activate the remixd plugin.
A modal dialog will ask confirmation
Accepting this dialog will start a session.
If you do not have `remixd` running in the background - another modal will open up and it will say:
```
Cannot connect to the remixd daemon.
Please make sure you have the remixd running in the background.
```
Assuming you don't get the 2nd modal, your connection to the remixd daemon is successful. The shared folder will be available in the file explorer.
**When you click the activation of remixd is successful - there will NOT be an icon that loads in the icon panel.**
Click the File Explorers icon and in the swap panel you should now see the folder for `localhost`.
Click on the `localhost connection` icon:
![](images/a-remixd-success.png)

@ -0,0 +1,282 @@
Run & Deploy
============
The Run tab allows you to send transactions to the current environment.
To get to the Run & Deploy module - click the run icon in the icon panel.
In order to use this module you need to have a contract compiled. So if there is file name in the contract pulldown menu ( in the image below it's the pulldown that says **Ballot**), then you can interact with this contract. If nothing is there - then you need to select a contract - make it the active contract in the main panel, ( in the image below - on the right side of the page - in the main panel - you see the ballot.sol so it is the active contract) then go to the compiler module and compile it.
![](images/a-runtab1.png)
Run Setup
---------
The following settings allow you to directly influence the transaction
execution:
Environment:
- `JavaScript VM`: All the transactions will be executed in
a sandbox blockchain in the browser. This means nothing
will be persisted and a page reload will restart a new
blockchain from scratch, the old one will not be saved.
- `Injected Provider`: Remix will connect to an injected
web3 provider. `Metamask` is an example of
providers that inject web3, thus can be used with this
option.
- `Web3 Provider`: Remix will connect to a remote node. You
will need to provide the URL address to the selected
provider: geth, parity or any Ethereum client.
- Account: the list of accounts associated with the current
environment (and their associated balances).
- Gas Limit: the maximum amount of gas that can be set for all the
transactions created in Remix.
- Value: the amount of value for the next created transaction (this
value is always reset to 0 after each transaction execution).
![](images/a-Runtab-deploy-atAddress.png)
Initiate Instance
-----------------
This section contains the list of compiled contracts and 2 actions:
- `At Address` assumes the given address is an instance of the
selected contract. It is then possible to interact with an already
deployed contract. There's no check at this point, so be careful
when using this feature, and be sure you trust the contract at that
address.
- `Deploy` send a transaction that deploys the selected contract. When
the transaction is mined, the newly created instance will be added
(this might take several seconds). Note that if the `constructor`
has parameters, you need to specify them.
Pending Instances
-----------------
Validating a transaction take several seconds. During this time, the GUI
shows it in a pending mode. When transaction is mined the number of
pending transactions is updated and the transaction is added to the log
(see ../terminal)
Using the ABI
------------
Using `Deploy` or `At Address` is a classic use case of Remix. It is
possible though to interact with a contract by using its ABI. The ABI is
a JSON array which describe its interface.
To interact with a contract using the ABI, create a new file in Remix
with extension `*.abi` and copy the ABI content to it. Then in the input
next to `At Address`, put the Address of the contract you want to
interact with. Click on `At Address`, a new "connection" with the
contract will popup below.
Using the Recorder
------------------
The Recorder allows to save a bunch of transactions in a JSON file and
rerun them later either in the same environment or in another.
Saving to JSON allows to easily check the transaction list, tweak input
parameters, change linked library, etc...
We can find many use cases for the recorder, for instance:
: - After having coded and tested contracts in a constrained
environment (like the JavaScript VM), it could be interesting to
redeploy them easily in a more persisted environment (like a
Geth node) in order to check whether everything behaves normally
in a classic environment.
- Deploying contract does often require more than creating one
transaction.
- Working in a dev environment does often require to setup the
state in a first place.
![](images/a-runtab-recorder.png)
Saving a record ends up with the creation of this type of content (see
below):
In that specific record, 3 transactions are executed:
The first corresponds to the deployment of the lib `testLib`.
The second corresponds to the deployment of the contract `test`, the
first parameter of the constructor is set to 11. That contract depends
on a library. The linkage is done using the property `linkReferences`.
In that case we use the addres of the previously created library :
`created{1512830014773}`. the number is the id (timestamp) of the
transaction that leads to the creation of the library.
The third parameter corresponds to the call to the function `set` of the
contract `test` (the property to is set to: `created{1512830015080}`) .
Input parameters are `1` and
`0xca35b7d915458ef540ade6068dfe2f44e8fa733c`
all these transactions are created using the value of the accounts
`account{0}`.
```
{.sourceCode .none}
{
"accounts": {
"account{0}": "0xca35b7d915458ef540ade6068dfe2f44e8fa733c"
},
"linkReferences": {
"testLib": "created{1512830014773}"
},
"transactions": [
{
"timestamp": 1512830014773,
"record": {
"value": "0",
"parameters": [],
"abi": "0xbc36789e7a1e281436464229828f817d6612f7b477d66591ff96a9e064bcc98a",
"contractName": "testLib",
"bytecode": "60606040523415600e57600080fd5b60968061001c6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636d4ce63c146044575b600080fd5b604a6060565b6040518082815260200191505060405180910390f35b6000610d809050905600a165627a7a7230582022d123b15248b8176151f8d45c2dc132063bcc9bb8d5cd652aea7efae362c8050029",
"linkReferences": {},
"type": "constructor",
"from": "account{0}"
}
},
{
"timestamp": 1512830015080,
"record": {
"value": "100",
"parameters": [
11
],
"abi": "0xc41589e7559804ea4a2080dad19d876a024ccb05117835447d72ce08c1d020ec",
"contractName": "test",
"bytecode": "60606040526040516020806102b183398101604052808051906020019091905050806000819055505061027a806100376000396000f300606060405260043610610062576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680632f30c6f61461006757806338cc48311461009e57806362738998146100f357806387cc10e11461011c575b600080fd5b61009c600480803590602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610145565b005b34156100a957600080fd5b6100b1610191565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156100fe57600080fd5b6101066101bb565b6040518082815260200191505060405180910390f35b341561012757600080fd5b61012f6101c4565b6040518082815260200191505060405180910390f35b8160008190555080600160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055505050565b6000600160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff16905090565b60008054905090565b600073__browser/ballot.sol:testLib____________636d4ce63c6000604051602001526040518163ffffffff167c010000000000000000000000000000000000000000000000000000000002815260040160206040518083038186803b151561022e57600080fd5b6102c65a03f4151561023f57600080fd5b505050604051805190509050905600a165627a7a72305820e0b2510bb2890a0334bfe5613d96db3e72442e63b514cdeaee8fc2c6bbd19d3a0029",
"linkReferences": {
"browser/ballot.sol": {
"testLib": [
{
"length": 20,
"start": 511
}
]
}
},
"name": "",
"type": "constructor",
"from": "account{0}"
}
},
{
"timestamp": 1512830034180,
"record": {
"value": "1000000000000000000",
"parameters": [
1,
"0xca35b7d915458ef540ade6068dfe2f44e8fa733c"
],
"to": "created{1512830015080}",
"abi": "0xc41589e7559804ea4a2080dad19d876a024ccb05117835447d72ce08c1d020ec",
"name": "set",
"type": "function",
"from": "account{0}"
}
}
],
"abis": {
"0xbc36789e7a1e281436464229828f817d6612f7b477d66591ff96a9e064bcc98a": [
{
"constant": true,
"inputs": [],
"name": "get",
"outputs": [
{
"name": "",
"type": "uint256"
}
],
"payable": false,
"stateMutability": "view",
"type": "function"
}
],
"0xc41589e7559804ea4a2080dad19d876a024ccb05117835447d72ce08c1d020ec": [
{
"constant": true,
"inputs": [],
"name": "getInt",
"outputs": [
{
"name": "",
"type": "uint256"
}
],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": true,
"inputs": [],
"name": "getFromLib",
"outputs": [
{
"name": "",
"type": "uint256"
}
],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": true,
"inputs": [],
"name": "getAddress",
"outputs": [
{
"name": "",
"type": "address"
}
],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": false,
"inputs": [
{
"name": "_t",
"type": "uint256"
},
{
"name": "_add",
"type": "address"
}
],
"name": "set",
"outputs": [],
"payable": true,
"stateMutability": "payable",
"type": "function"
},
{
"inputs": [
{
"name": "_r",
"type": "uint256"
}
],
"payable": true,
"stateMutability": "payable",
"type": "constructor"
}
]
}
}
```

@ -0,0 +1,14 @@
Settings
========
To get to **Settings** click the gear a the very bottom of the icon panel.
You can find a link to the homepage (if you closed it) as well as a link to our Gitter Channel and for you aesthetes out there, we now have a rather large list of themes.
![](images/a-themes.png)
Another important settings:
- Text wrap: controls if the text in the editor should be wrapped.
- Enable optimization: defines if the compiler should enable optimization during compilation. Enabling this option saves execution gas. It is useful to enable optimization for contracts ready to be deployed in production but could lead to some inconsistencies when debugging such a contract.

@ -0,0 +1,18 @@
Solidity Editor
===============
The Remix editor recompiles the code each time the current file is
changed or another file is selected. It also provides syntax
highlighting mapped to solidity keywords.
![](images/a-sol-editor.png)
Here's the list of some important features:
- It display opened files as tabs.
- Compilation Warning and Error are displayed in the gutter
- Remix saves the current file continuously (5s after the last
changes)
- +/- on the top left corner enable you to increase/decrease the font
size of the editor

@ -0,0 +1,33 @@
Analysis
========
This section gives information about the last compilation. By default, a
new analysis is run at each compilation.
The analysis tab gives detailed information about the contract code. It
can help you avoid code mistakes and to enforce best practices.
![](images/a-static-analysis.png)
Here is the list of analyzers:
Security:
- Transaction origin: Warns if tx.origin is used
- Check effects: Avoid potential reentrancy bugs
- Inline assembly: Use of Inline Assembly
- Block timestamp: Semantics maybe unclear
- Low level calls: Semantics maybe unclear
- Block.blockhash usage: Semantics maybe unclear
Gas & Economy:
- Gas costs: Warns if the gas requirements of the functions
are too high
- This on local calls: Invocation of local functions via
this
Miscellaneous:
- Constant functions: Checks for potentially constant
functions
- Similar variable names: Checks if variable names are too
similar

@ -0,0 +1,9 @@
Support chat
=======================
We know that blockchain ecosystem is very new and that lots of information is scattered around the web.
That is why we created a community support chat where we and other users try to answer your questions if
you get stuck using Remix. Please, join [the Remix channel](https://gitter.im/ethereum/remix) and ask the community for help.
For anyone who is interested in developing a custom plugin for Remix or who wants to contribute to the codebase,
we've opened [another channel](https://gitter.im/ethereum/remix-dev) specially for developers working on Remix tool.

@ -0,0 +1,21 @@
Terminal
========
![](images/a-terminal-and-more.png)
Features, available in the terminal:
- It integrates a JavaScript interpreter and the `web3` object. It
enables the execution of the JavaScript script which interacts with
the current context. (note that `web3` is only available if the
`web provider` or `injected provider` mode is selected).
- It displays important actions made while interacting with the Remix
IDE (i.e. sending a new transaction).
- It displays transactions that are mined in the current context. You
can choose to display all transactions or only transactions that
refers to the contracts Remix knows (e.g transaction created from
the Remix IDE).
- It allows searching for the data and clearing the logs from the
terminal.
- You can run scripts by inputting them at the bottom after the `>`.

@ -0,0 +1,225 @@
Debugging transactions
======================
There are two ways to start debugging, each one corresponds to a different use case.
* from the transaction log in the Terminal - use this when you want to debug a transaction.
* from the Debugger - use this if you have a *transaction hash*.
### Initiate Debugging from the transaction log in the Terminal
Let's start with a basic contract ( or replace this one by your own ) :
- create a blank file in the file explorer (by clicking the + icon) and give it a name.
- copy the code below.
- compile the code.
- click the Run & Deploy icon in the icon panel.
```
pragma solidity >=0.5.1 <0.6.0;
contract Donation {
address owner;
event fundMoved(address _to, uint _amount);
modifier onlyowner { if (msg.sender == owner) _; }
address[] _giver;
uint[] _values;
constructor() public {
owner = msg.sender;
}
function donate() payable public {
addGiver(msg.value);
}
function moveFund(address payable _to, uint _amount) onlyowner public {
uint balance = address(this).balance;
uint amount = _amount;
if (_amount <= balance) {
if (_to.send(balance)) {
emit fundMoved(_to, _amount);
} else {
revert();
}
} else {
revert();
}
}
function addGiver(uint _amount) internal {
_giver.push(msg.sender);
_values.push(_amount);
}
}
```
For the purpose of this tutorial, we will run the `JavaScript VM`.
This simulates a custom blockchain. You could do the same using a proper backend node.
Let's deploy the contract:
Click the `Deploy` button
![](images/a-debug1-deploy.png)
You'll see the deployed instance (AKA the udapp).
![](images/a-debug2-udapp1a.png)
Then open it up (by clicking the caret).
![](images/a-debug3-udapp2.png)
We are going to call the `Donate` function and will send it ether.
To do this: in the value input box put in **2** and select Ether as the unit (and not wei like I did in the image below - well you could - it won't really change anything).
![](images/a-debug4-value-loc.png)
Then click the `Donate` button.
This will send Ether to the this function.
Because we are using the `JavaScript VM`, everything happens almost instantly. (If we had been using Injected Web 3, then we would have to need to approve the transaction, pay for gas and wait for the transaction to get mined.)
Remix displays information related to each transaction result in the terminal.
Check in the **terminal** where the transaction you just made is logged.
Click the debug button to start debugging it.
![](images/a-debug5-term-debug-but.png)
Before we get to the actual debugging tool, the next section show how to start debugging session directly from the Debugger.
### Initiate Debugging from the from the Debugger
Click the bug icon in the icon panel to get to the debugger in the side panel.
If you don't see the bug icon, go to the plugin manager and activate the debugger.
You can start a debug session by providing a `transaction hash`.
To find a transaction hash:
1. Go to a transaction in the terminal.
2. Click a line with a transaction - to exand the log.
3. The transaction hash is there - copy it.
![](images/a-debug6-term-txn-hash.png)
Then click in the debugger paste the hash and click on the `Start debugging` button.
![](images/a-debug7-debugger.png)
Using the debugger
------------------
![](images/a-debug8-top3.png)
The debugger allows one to see detailed informations about the
transaction's execution. It uses the editor to display the
location in the source code where the current execution is.
The navigation part contains a slider and buttons that can be used to
step through the transaction execution.
### More explaination of what these buttons do.
1. Step Into
2. Step Over Into
11 panels give detailed information about the execution:
### Instructions
The Instructions panel displays the bytecode of the current executing
contract- with the current step highlighted.
Important note: When this panel is hidden, the slider will have a
courser granularity and only stop at *expression boundaries*, even if they
are compiled into multiple EVM instructions. When the panel is
displayed, it will be possible to step over every instruction, even
those that refers to the same expression.
### Solidity Locals
The Solidity Locals panel displays local variables associated with the
current context.
### Solidity State
The Solidity State panel displays state variables of the current
executing contract.
### Low level panels
These panels display low level informations about the execution:
> - Stack
> - Storages Changes
> - Memory
> - Call Data
> - Call Stack
> - Return Value (only if the current step is a RETURN opcode)
> - Full Storages Changes (only at the end of the execution - display
> every storage change of every modified contract)
### Reverted Transaction
A transaction can be `reverted` (because of an *out of gas exception* or
Solidity `revert` statement or because of a low level exception).
It is important to be aware of the exception and to locate
where the exception is in the source code.
Remix will warn you when the execution throws an exception. The
`warning` button will jump to the last opcode before the exception
happened.
### Breakpoints
The two last buttons from the navigation area are used to jump either
back to the previous breakpoint or forward to the next breakpoint.
Breakpoints can be added and removed by clicking on the line number in the *Editor*.
When using debug session with breakpoints, the execution will jump to the first
encountered breakpoint.
**Important note:** If you add a breakpoint to a line that declares a
variable, it might be triggered twice: Once for initializing the
variable to zero and second time for assigning the actual value. As an
example, assume you are debugging the following contract:
```
pragma solidity >=0.5.1 <0.6.0;
contract ctr {
function hid () public {
uint p = 45;
uint m;
m = 89;
uint l = 34;
}
}
```
And let's says that breakpoints are set for the lines
`uint p = 45;`
`m = 89;`
`uint l = 34;`
then clicking on `Jump to next breakpoint` will stop at the following
lines in the given order:
> `uint p = 45;` (declaration of p)
>
> `uint l = 34;` (declaration of l)
>
> `uint p = 45;` (45 assigned to p)
>
> `m = 89;` (89 assigned to m)
>
> `uint l = 34;` (34 assigned to l)

@ -0,0 +1,279 @@
Debugging a Dapp using Remix & Geth
==========================================
The ultimate goal of this tutorial is to debug transactions that have
been created by a dapp front end.
It is easy in Remix to debug a transaction created from its own GUI.
However, setting up an environment that allows you to debug transactions
created outside of Remix, require a bit more of complexity.
We will need four tools for that :
> - Geth - this is the center piece and provides the blockchain
> environment. We will basically run geth in a dev mode.
> - Remix - this is the Ethereum IDE. We will use it to develop our
> Solidity contract.
> - Any code editor you want - in order to write your front end :)
Install the environment
-----------------------
### Install Metamask
Basically we will run our front end in the Metamask Chrome plugin ([Metamask](http://metamask.io)).
### Install Geth
[Geth](http://github.com/ethereum/go-ethereum/releases) is the official
Ethereum client.
Running the environment
-----------------------
### Run Geth
We will run a test node. This node will have a new empty state and will
not be synced to the main or ropsten network.
geth --ipcpath <test-chain-directory>/geth.ipc --datadir <test-chain-directory> --dev console
`<test-chain-directory>` is the folder where keys and chain data will be
stored.
`--ipcpath` defines the end point that other apps (like Metamask) use to
talk to geth.
`--datadir` specifies the data directory.
`--dev` sets the node into private chain mode and adds some debugging
flags.
Then we need to create accounts and mine a bit to generate some Ether:
// from the geth console :
personal.newAccount() // You can execute this command several time if you need more than one account.
miner.start() // generate some Ether.
miner.stop() // stop mining after 30s-60s - we could also keep mining.
Next time we run Geth, we will only need to mine transactions (no need
to recreate account).
### Starting Remix
In Mist click on `Develop` / `Open Remix IDE`
Remix will open in a new window. If this is the first time it is run,
the `Ballot` contract will be loaded.
Now, we need to check if Remix is connected to Mist:
Right panel / third tab from the left, `Injected Provider` should be
checked.
![image](remix4.png)
Right panel / second tab from the left, `Transaction Origin` should
contain accounts we have previously created in Geth.
![image](remix5.png)
Developing contract / front end
-------------------------------
### Donation contract - Dapp Back end
Here is a sample solidity contract.
Copy and paste the following inside remix:
```
{.sourceCode .none}
contract Donation {
address owner;
event fundMoved(address _to, uint _amount);
modifier onlyowner { if (msg.sender == owner) _; }
address[] _giver;
uint[] _values;
function Donation() {
owner = msg.sender;
}
function donate() payable {
addGiver(msg.value);
}
function moveFund(address _to, uint _amount) onlyowner {
uint balance = this.balance;
uint amount = _amount;
if (_amount <= this.balance) {
if (_to.send(this.balance)) {
fundMoved(_to, _amount);
} else {
throw;
}
} else {
throw;
}
}
function addGiver(uint _amount) internal {
_giver.push(msg.sender);
_values.push(_amount);
}
}
```
### Dapp Front end
and here is the front end:
```html
<div>
<div>Donation Contract</div>
<br/>
<input id='contractaddress' placeholder='contract address' />
<br/>
<div>
<br/>
<input id='fromGive' placeholder='from' /><input placeholder='amount' id='valueGive' /><button id="fallbackbtn" onclick="donate()">give</button>
<br/>
<br/>
<input id='fromMoveFund' placeholder='from' /><input id='moveFundTo' placeholder='move to' /><input id='amountToMove' placeholder='amount' /><button id="movefundbtn" onclick="movefund()">moveFund</button>
<br/>
<br/>
<div id='wait' ></div>
</div>
<br/>
<br/>
<div id='log'>
</div>
</div>
<script type="text/javascript">
function donate () {
var donation = contractspec.at(document.getElementById('contractaddress').value)
donation.donate({
from: document.getElementById('fromGive').value,
value: document.getElementById('valueGive').value
}, function (error, txHash) {
tryTillResponse(txHash, function (error, receipt) {
alert('done ' + txHash)
})
})
}
function movefund () {
var donation = contractspec.at(document.getElementById('contractaddress').value)
donation.moveFund(
document.getElementById('moveFundTo').value,
document.getElementById('amountToMove').value,
function (error, txHash) {
tryTillResponse(txHash, function (error, receipt) {
alert('done ' + txHash)
})
})
}
var contractspec = web3.eth.contract([{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_amount","type":"uint256"}],"name":"moveFund","outputs":[],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"donate","outputs":[],"payable":true,"type":"function"},{"inputs":[],"payable":false,"type":"constructor"},{"anonymous":false,"inputs":[{"indexed":false,"name":"_to","type":"address"},{"indexed":false,"name":"_amount","type":"uint256"}],"name":"fundMoved","type":"event"}]);
function tryTillResponse (txhash, done) {
document.getElementById('wait').innerHTML = 'waiting for the transaction to be mined ...'
web3.eth.getTransactionReceipt(txhash, function (err, result) {
if (!err && !result) {
// Try again with a bit of delay
setTimeout(function () { tryTillResponse(txhash, done) }, 500)
} else {
document.getElementById('wait').innerHTML = ''
var log = document.createElement("div")
log.innerHTML = JSON.stringify(result)
document.getElementById('log').appendChild(log)
done(err,result)
}
})
}
</script>
```
I would suggest serving this file using `http-serve`, but you can use
any web server you like.
Example: Dapp Front End <https://github.com/ltfschoen/dapp_front_end>
### Important notice !
The variable `contractspec` contains the abi of the `donation` contract.
This means that if you change something in the contract interface
(function names, parameters, ...) you need to copy the new abi from
remix to the front end.
Deploying
---------
Right panel / Red button `Create`
![image](remix1.png)
This creates a new transaction that deploys the `Donation` contract
(Mist will ask for the usual passphrase check).
Wait for the transaction to be mined (don't forget to activate mining
`miner.start()`). Once this is done, you can use it by executing the
`moveFund` and `donate` function. But this is not what we want to
achieve. We want to run and debug those functions from the front end.
Remix also display the address of the contract. Save it, we'll need this
address later.
![image](remix2.png)
Debugging
---------
From Mist, browse the above front end. In the first field, paste the
address of the newly created contract. Now, let's call the first
function (label `give`).
You will need an account and a value.
The account could be any account that is declared in the Wallet section
of Mist. This is the sender of the transaction that we are going to
create. The value should be no more than the actual balance of the
account - the unit is in wei, so just put `100` (100 wei), that should
be fine.
Click on `Give` and wait for the transaction to be mined.
The HTML block with id `log` is filled by all the transactions created
from the front end. It was easier for the purpose of this tutorial to
just log transactions in a div but you can have your own logging
mechanism.
There is only one field that we need, this is the `transactionHash`.
Copy it and switch to Remix. On the right side, the fifth panel shows a
small "bug" icon, that is the debugger.
Paste the hash into the transaction field and click on the `play`
button.
![image](remix3.png)
You are now entering a debug session for the call to `donate`.
Debugging in Remix is easier than with common tools like gdb because you
can freely move in time. Use the slider to change the current step and
click on the panels below to expand them and explore the curret state,
local variables, etc. There are also breakpoints to move between
sections of the code quickly, but more on all that later.
At the time of this writing, there is an issue that could break the
contract creation. The a workaround for that at
<https://github.com/ethereum/go-ethereum/issues/3653> . Please follow
the workaround or wait for this issue to be closed.
Also, although retrieving a contract's storage when Remix is using the
JavaScript VM is working well, there is still work to be done when Remix
is using eth or geth as backend.

@ -0,0 +1,57 @@
Run & Deploy (part 2)
=====================
## Deployed contracts
This section in the Run tab contains a list of deployed contracts to interact with through autogenerated UI of the deployed contract (also called udapp).
The deployed contract appears but is in its collapsed form.
![](images/a-debug2-udapp1a.png)
Click the sideways caret to open it up.
![](images/a-debug3-udapp2.png)
You will see the functions in the contract. The functions buttons can have different color buttons.
- Functions that are `constant` or `pure` functions in Solidity have a blue buttons. Clicking one of this type does not create a new transaction. So clicking will not cause state changes - it will only return a value stored in the contract - so it won't cost you anything in gas fees.
- Functions that changes the state of the contract are orange, clicking this type of function will cost gas and they do change the state of the contract and so they do create a new transaction.
But this transaction does not accept Ether.
- Functions that have red buttons are `payable` functions in Solidity. Clicking one of these will create a new transaction and this transaction can accept a **value**. The **value** is put in in the Value field which is under the Gas Limit field.
![](images/a-jvm-calling-instance.png)
For more information see more about [Solidity
modifier](http://solidity.readthedocs.io/en/develop/miscellaneous.html?highlight=pure#modifiers)
.
If a function requires input parameters, well.. you gotta put them in.
## Inputting parameters
![](images/a-udapp-inputs.png)
### Inputting parameters in the collapsed view
(Inputting all the parameters in a single input box)
+ The input box tells you what type each parameter needs to be.
+ Numbers and addresses do not need to be wrapped in double quotes.
+ Strings need to be wrapped.
+ Parameters are separated by commas.
In the example above the "delegate" function has 3 parameters.
### Inputting parameters in the expanded view
Clicking the 'down' caret brings you to the *Multi-param Manager* - where you can input the parameters one at a time. **Much less confusing!**
![](images/a-udapp-multi-param-man.png)
In the expanded view, strings do not need to be wrapped.
Clicking the clipboard icon will encode the inputs and will copy them. Only a valid set of inputs can be encoded.
So if you made a mistake and put a uint8 where an address should have been, clicking the clipboard here will give you an error.

@ -0,0 +1,41 @@
Unit Testing
============
Click the "double check" icon to get to the unit testing plugin. If you don't see this icon, go to the plugin manager and load up the unit testing plugin.
![](images/a-unit-testing1.png)
Generate test File
------------------
This create a new solidity file in the current folder suffixed with `_test`.
This file contains the minimun you need for running unit testing.
Run Tests
---------
This execute tests. The execution is run in a separate environment and the result is displayed below.
| Available functions | Supported types |
| ------------- | ------------- |
| `Assert.ok()` | `bool` |
| `Assert.equal()` | `uint`, `int`, `bool`, `address`, `bytes32`, `string` |
| `Assert.notEqual()` | `uint`, `int`, `bool`, `address`, `bytes32`, `string` |
| `Assert.greaterThan()` | `uint`, `int` |
| `Assert.lesserThan()` | `uint`, `int` |
see [https://github.com/ethereum/remix/blob/master/remix-tests/tests/examples_4/SafeMath_test.sol](https://github.com/ethereum/remix/blob/master/remix-tests/tests/examples_4/SafeMath_test.sol) for some code sample
Continuous integration
----------------------
remix-tests is also a CLI, it can be used in a continuous integration environement which support node.js.
Please find more information in the [remix-test repository](https://github.com/ethereum/remix/tree/master/remix-tests)
See also: example [Su Squares contract](https://github.com/su-squares/ethereum-contract/tree/e542f37d4f8f6c7b07d90a6554424268384a4186) and [Travis build](https://travis-ci.org/su-squares/ethereum-contract/builds/446186067) that uses remix-tests for continuous integration testing.
Loading…
Cancel
Save