Nimbus
Support:
- Team blog post on our meeting in Berlin: https://our.status.im/nimbus-berlin-update/
- Documentation: https://nimbus-libs.status.im/#get-started
- Revamped build system, can directly use nim-beacon-chain instead of going through Nimbus
import std/cpuinfo | |
import macros | |
echo "CPU name: ", cpuName() | |
echo "CPUs: ", countProcessors() | |
macro checkFeatures(body: untyped) = | |
result = newStmtList() | |
for call in body: |
Nimbus
Support:
20190815 - Eth 2.0 implementers call #23
Nimbus
Team in Berlin.
"Good artists borrow, great artists steal." -- Pablo Picasso
The Nim destructors and new runtime were introduced to provide GC-less path forward for Nim libraries and applications where it made sense. One of their explicit use case is making threading easier.
import | |
# STD lib | |
os, strutils, threadpool, strformat | |
# bench | |
# ../wtime | |
# Using Nim's standard threadpool | |
# Compile with "nim c --threads:on -d:release -d:danger --outdir:build benchmarks/fibonacci/stdnim_fib.nim" | |
# | |
# Note: it breaks at fib 16. |
20190724 - ETH 2.0 Implementers Call 22 | |
https://github.com/ethereum/eth2.0-pm/issues/64 | |
---------------------------------- | |
Nimbus team | |
Core: | |
- Most of 0.8.1 implemented except SSZ | |
- On the verge of important changes: |
title: ssz testing, with minimal config, randomized with mode one | |
summary: Test suite for ssz serialization and hash-tree-root | |
forks_timeline: testing | |
forks: [phase0] | |
config: minimal | |
runner: ssz | |
handler: static | |
test_cases: | |
- Attestation: | |
value: |
title: BLS sign msg | |
summary: BLS Sign a message | |
forks_timeline: mainnet | |
forks: [phase0] | |
config: mainnet | |
runner: bls | |
handler: sign_msg | |
test_cases: | |
- input: {privkey: '0x263dbd792f5b1be47ed85f8938c0f29586af0d3ac7b977f21c278fe1462040e3', | |
message: '0x0000000000000000000000000000000000000000000000000000000000000000', |
I suspect most developers are using the libdispatch inefficiently due to the way it was presented to us at the time it was introduced and for many years after that, and due to the confusing documentation and API. I realized this after reading the 'concurrency' discussion on the swift-evolution mailing-list, in particular the messages from Pierre Habouzit (who is the libdispatch maintainer at Apple) are quite enlightening (and you can also find many tweets from him on the subject).
My take-aways are: