Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limited LLL support #408

Closed
wants to merge 21 commits into from
Closed

Limited LLL support #408

wants to merge 21 commits into from

Conversation

veox
Copy link
Contributor

@veox veox commented Dec 11, 2017

What's this about?

Provides limited support for LLL development. The limitations are detailed in docs/lll_support.rst.

Styled after PR #383.

Closes #400 as implemented.

What might be wrong?

  • The contract file names start with a capital letter.
  • Greeter.lll greets with numbers instead of strings.
  • Greeter.lll{,.abi} are duplicated between dirs tests/fixtures and populus/assets. The former is to run already-present tests. The latter is provisional, to simplify populus init --lll later on.
  • lllc is provided from the solidity-ubuntu-trusty.zip file, which is actually installed to get solc. If the Travis builds are moved away from Ubuntu 14.04 (Trusty), the binary might become unavailable.

Cute Animal Picture

Three languages! Wow! (gotten here, actual source unknown)

three dogs in an inflatable boat in a pool

Untested ATM.

Uses parts of Daniel Ellison's (@zigguratt) stdlib, inline:

https://github.com/zigguratt/lll-stdlib

at this commit:

zigguratt/lll-stdlib@fd9d57c
…`master`.

This should allow avoiding a `git` conflict when eventually
submitting PR.
Will allow easier `populus init --lll`, which was proposed
in PR ethereum#397.
backends/lll: WIP to retrieve bytecode{,_runtime}.

Looks like there's no simple way to get runtime bytecode
from `lllc`.

Possible approaches:

* provide functionality upstream (most useful to community);
* parse/strip available bytecode from `lllc` output.

backends/lll: compile() WIP, strip() stub.

backends/lll: compile() no-newline + strip() impl-n + WIP debug pprints.

Currently fails with `populus.exceptions.ValidationError` because reading
in `abi` from file as string - and leaving it at that!

Need to JSON it into an actual data structure.

backends/lll: json.load() ABI from file.

backends/lll: don't strip trailing `JUMPDEST` in `bytecode_runtime`.

NB: The whole "strip after JUMPDEST" approach is only likely to
work on contracts whose `bytecode` stores data there; and will
fail anyway if the data _itself_ contains `5b`. X_X

backends/lll: don't compare list to string in strip().
Tries to store/retrieve string greetings. This doesn't work.
Gets removed by `lllc`'s optimiser. :(

Might want to instead:

* parse LLL tree (retrieved from `lllc -t`) for literals;
* count their length;
* strip that much off the tail.
There's something I don't understand yet: when running `pytest`,
Populus can't decode the return value.

It seems that the HeadTail decoder (from `eth_abi`) gets a
bogus stream, where `seek` is a huge (32 bytes?) number that looks
like a hash. Perhaps this is related to

ethereum/solidity#1188

or perhaps, when storing/retrieving a string, some particular
encoding scheme has to be used.

I've tried many approaches (none of them are recorded in git
history), but none worked.

Therefore, resorting to using a simpler contract.
Literals are hard. For now, won't support them.

Depending on where in code they appear (deployment or runtime
code), and whether the `lit` keyword is used to define a macro,
it's difficult to determine if they have to be stripped.
…nd marker.

Literal support is dropped (for now).

I feel that a new language without LLL's quirks, perhaps a true
Lisp dialect, is in order.

LLLLLLL: lovely little low-level LLL-like language

This will have to wait, though.
Should also make it simpler later on to add `populus init --lll`.
@veox
Copy link
Contributor Author

veox commented Dec 11, 2017

One build job failed due to being unable to download Python 3.4. :/

@veox veox mentioned this pull request Dec 18, 2017
Seems that `lllc` considers (import "/path/to/file.lll") to be
relative to its own workdir, rather than the file that's to be
compiled.
@veox
Copy link
Contributor Author

veox commented Jan 4, 2018

I've pushed a commit to work around a bug in lllc; the Viper-specific build job failed:

E: Unable to locate package golang-1.7

@veox
Copy link
Contributor Author

veox commented Sep 26, 2018

Closing this as tech debt, especially in light of recent efforts to bring Populus up to speed with latest changes in Ethereum+Python.

Will revisit integration later.


I've packaged this branch up as-is into PyPI package populllus (repo on gitlab, backup on github).

It uses the same module name, populus, so is best installed in LLL-specific projects' virtualenvs.

(That's why I packaged it up: so I can specify it as a dependency in a few LLL projects that lack public CI.)

@veox veox closed this Sep 26, 2018
@veox veox mentioned this pull request Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LLL: how to specify ABI?
3 participants