Golang bindings

[euforic]

• Add command to package.json to generate go bindings
• Generate Go bindings

Please Merge #74 before merging this PR

I generated the GoDoc in markdown for a temporary reference.
GoBinding Docs

[jcvernaleo]

When I try to generate the go code locally it fails:

jcv@triforce metronome $ npm run generate:go

> metronome@1.0.0 generate:go /home/jcv/code/bloq/autonomoussoftware/metronome
> abigen --sol=./contracts/monolithic.sol --pkg=metronome > metronome.go

npm ERR! code ELIFECYCLE
npm ERR! errno 255
npm ERR! metronome@1.0.0 generate:go: `abigen --sol=./contracts/monolithic.sol --pkg=metronome > metronome.go`
npm ERR! Exit status 255
npm ERR! 
npm ERR! Failed at the metronome@1.0.0 generate:go script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/jcv/.npm/_logs/2018-09-21T12_48_20_044Z-debug.log

Running the command manually I get:

jcv@triforce metronome $ abigen --sol=./contracts/monolithic.sol --pkg=metronomeFailed to build Solidity contract: solc: exit status 1
./contracts/monolithic.sol:314:15: Error: Expected identifier but got '('
    constuctor() public {
              ^

I'm using a pretty recent solc and abigen:

jcv@triforce metronome $ solc --version 
solc, the solidity compiler commandline interface
Version: 0.4.25+commit.59dbf8f1.Linux.g++
jcv@triforce metronome $ apt search abigen
Sorting... Done
Full Text Search... Done
abigen/xenial,now 1.8.15+build15102+xenial amd64 [installed]
  Source code generator to convert Ethereum contract definitions into easy to use, compile-time type-safe Go packages.

Are you using a particular version of solc or abigen?

[jcvernaleo]

Also, it might be best to split this into 2 PR, one for anything smart contract related and one that depends on that with the go code and the generate step that way they can be reviewed separately. Since the smart contracts are already deployed, I'm not sure if those changes can go in really (but that is more @gabmontes's area than mine).

[jcvernaleo]

That said, I'm very happy to see go bindings here!

[jgarzik]

Comments:

• The axiom is that we just shouldn't change the Solidity code, now that it is deployed.
• My guess -- explanation from @euforic requested -- is that the changes are what makes the Go code generation work.
• If that's the case, I would like to see a PR where the 1st commit is simply duplicating monolithic.sol, and the 2nd and successive commits in that PR are the transformations.

[euforic]

@jcvernaleo Sorry not sure how the typo got in, but fixed that and pushed the changes. I will break it into two commits as requested. Instead of duplicating monolithic.sol do you want to just push a git tag to tag the version this way if the contract is ever updated and redeployed we can just tag the new versions?

[euforic]

@jcvernaleo @jgarzik I put in another PR #74 that just updates the comments to allow for the contract to compile with the latest version of solc

[euforic]

@jcvernaleo @jgarzik Ok this PR only covers the actually Go binding generation function and the generated Go code. It's built off of #74 pending PR branch so once that is merged the changes to the contract will disappear from this PR changes

[jcvernaleo]

Would it be possible to generate the go bindings using the version of solc that was initially used (looks like 0.4.21 based on package-lock.json) or does generating the go code require the newer solc?

Mostly wondering if we can get the go code in without touching the contracts.

[jcvernaleo]

Regardless of the question above, the generate command now works for me and generates identical code when I run it as in the pull request (other than a single newline oddly enough). So on the go side, I'm happy with this PR (once we decide on #74).

[euforic]

@jcvernaleo so the only changes to the contract now are just ... added to the doc blocks that are missing the required docs. So nothing would change for the compiled contract, it might just add the docs to the ABI. The issue with using an older version of the compiler is we will miss out on any of the improvements and / or bug fixes from the latest code generator. One big problem is you will have to have everyone downgrade there installed version of abigen to an older version in order to compile too.

[jcvernaleo]

Downgrading abigen is definitely more of a pain than downgrading solc.

[patidarmanoj10]

No changes in contract needed . closing this as new PR #95 will take care of this.