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

Trying to make sense and ordering of unit names #1073

Closed
wants to merge 1 commit into from

Conversation

alexvandesande
Copy link

I suppose this is the kind of pull request you do when it’s late at night and you become mad with something. This time is one of the most controversial small things about ethereum, unit names. Every other week someone comes to us and ask why we don’t stick to SI units. Sure, no one remembers which is supposed to be babbage, but what’s the deal with Kwei with a uppercase K, kilo doesn’t start with uppercase! Why are unit names written in full but prefixes just the letter? It’s not Mbyte or mliter, it’s either the Megabyte or the ml. And grand, really? It’s not a SI unit it’s a number.

I always say that unit names are just suggestions and we should only use ether and wei, but in practice that doesn’t work.

Most things are in ether. Gas prices are usually in finney or szabo. Basic functions are in wei.

Then it dawns on me that the only that actually matter are ether, finney and szabo, and they have a direct 1000 relationship. Here’s a nice mnemonic: they’re the micro and the mili. A Finney is a mili-ether, szabo is the micro-ether. Ether, mili, micro. Now I usually don’t memorize the micro but since I’m having to remember the szabo anyway, why not the micro-?

So I did some cosmetic changes, made the comments clearer on this, and added support for SI prefixes femto-, pico-, nano-, micro- and mili-

Just giving developers more choice, since so many of them asked for this

Now maybe you’ll reject this because frankly this is not that relevant. But it’s okay, because in my heart finney will always be the micro-ether.

@tgerring
Copy link
Contributor

+1 for more options. maybe it's a bit confusing now, but the community will eventually settle on whichever suits them best

@carver
Copy link
Contributor

carver commented May 22, 2015

The milli- prefix has two L's -- https://en.wikipedia.org/wiki/Milli-

@alexvandesande
Copy link
Author

I'm closing this pull request and moving it to the appropriate library

alexvandesande/web3.js#1

tony-ricciardi pushed a commit to tony-ricciardi/go-ethereum that referenced this pull request Jan 20, 2022
### Description

This PR includes the necessary bits to setup a CI pipeline that cross-compiles all geth tools into release binaries for the platforms we want/support. Currently these are:

- ✅Linux 32bit/64bit
- ✅Darwin 32bit/64bit (~pending on ethereum#1082~ merged!)
- ✅Windows 64bit (~pending on celo-bls-go v0.1.6 release~ ~pending on ethereum#1089~ merged!)

Elements of the PR:

- `Dockerfile.binaries` for the container where cross-compilation occurs. It's based on a [fork of xgo](https://github.com/techknowlogick/xgo), and includes some back-ported mingw packages for the windows build.


- Changes to the `geth` build scripts:
   - Introduce a new CI environment in `internal/build/env.go` which which can be used for Google Cloud Build.
   - Create a new ci task in `build/ci.go` that bundles the binaries into well named release archive


- `cloudbuild-binaries.yaml` which defines the CI pipeline. It should be used in conjunction with a trigger on `release/.*` and `master` branches and the trigger should have to variables:
  - `_BUCKET` with the name of the google cloud storage bucket where the artefacts will be stored
  - `_BUILD_TARGETS` comma-separated string of build targets. e.g. `linux/amd64,linux/386`

#### Shortcomings 

- 🔴 The geth `build.Environment` struct requires the commit timestamp, which is then passed to `main.gitDate` in the binaries that it builds. Usually this is extracted from the git but in Cloud Build in the CI steps the git data is stripped and all we have is what's passed through env vars. I have substituted the commit timestamp with the build timestamp instead.
- 🟡 The `xgo` image is really large (3gb) and adds about ~4minutes to the build time

#### Release artefacts

The pipeline outputs release artefacts into `<bucket>/<branch>/<file>`. For example here's the output of a test build:

<img width="553" alt="Screenshot 2020-06-29 at 11 41 00" src="https://user-images.githubusercontent.com/304771/85994959-1433eb00-b9fe-11ea-9180-22ea95cb774c.png">

A few things to notice here:

- The folder is `<bucket>/release/1.1` yet the version is `1.0.0-unstable` this is because there isn't any enforced relationship between the branch name and the version sourced from `params/version.go` which is the authoritative source. So in this case I just created the dummy `release/1.1` branch on my fork in order to play around. Because we're using the branch name in the path all "nightly" version will be stored in the `<bucket>/master` folder, if we setup the trigger on `master`.

- There are 2 archives per platform, one containing only `geth` and the other containing all binary tools located inside `cmd`, just like geth releases. ⚠️ The archives also contain the "COPYING" file, we need to decide if we want to make changes to that ⚠️
 

#### Post-merge TODOs:

- [x] Create a bucket and triggers in `celo-testnet` to start running the pipeline
- [x] Enable more build targets as they are unblocked 
 
### Tested

I have currently tested the CI pipeline in a personal google cloud project and tested the linux binaries in docker.

### Related issues

- Fixes ethereum#1073 

### Backwards compatibility

Changes are only related to tooling so no problem with compatibility.
maoueh pushed a commit to streamingfast/go-ethereum that referenced this pull request Sep 30, 2022
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.

3 participants