Dask Working Notes - Posts tagged release

Dask Release 2.2.0

2019-08-02T00:00:00+00:00

I’m pleased to announce the release of Dask version 2.2. This is a significant release with bug fixes and new features. The last blogged release was 2.0 on 2019-06-22. This blogpost outlines notable changes since the last post.

You can conda install Dask:

conda install dask

or pip install from PyPI:

pip install dask[complete] --upgrade

Full changelogs are available here:

As always there are too many changes to list here, instead we’ll highlight a few that readers may find interesting, or that break old behavior. In particular we discuss the following:

Parquet rewrite
Nicer HTML output for Clients and Logs
Hyper-parameter selection with Hyperband in Dask-ML
Move bytes I/O handling out of Dask to FSSpec
async/await everywhere, and cleaner setup for developers
A new SSH deployment solution

1 - Parquet Rewrite

Today Dask DataFrame can read and write Parquet data using either fastparquet or Apache Arrow.

import dask.dataframe as dd

df = dd.read_parquet("/path/to/mydata.parquet", engine="arrow")
# or
df = dd.read_parquet("/path/to/mydata.parquet", engine="fastparquet")

Supporting both libraries within Dask has been helpful for users, but introduced some maintenance burden, especially given that each library co-evolved with Dask dataframe over the years. The contract between Dask Dataframe and these libraries was convoluted, making it difficult to evolve swiftly.

To address this we’ve formalized what Dask expects of Parquet reader/writers into a more formal Parquet Engine contract. This keeps maintenance costs low, enables independent development for each project, and allows for new engines to emerge.

Already a GPU-accelerated Parquet reader is available in a PR on the RAPIDS cuDF library.

As a result, we’ve also been able to fix a number of long-standing bugs, and improve the functionality with both engines.

Some fun quotes from Sarah Bird during development

I am currently testing this. So far so good. I can load my dataset in a few seconds with 1800 partitions. Game changing!

and

I am now successfully working on a dataset with 74,000 partitions and no metadata. Opening dataset and df.head() takes 7 - 30s. (Presumably depending on whether s3fs cache is cold or not). THIS IS HUGE! This was literally impossible before.

The API remains the same, but functionality should be smoother.

Thanks to Rick Zamora, Martin Durant for doing most of the work here and to Sarah Bird, Wes McKinney, and Mike McCarty for providing guidance and review.

2 - Nicer HTML output for Clients and Logs

from dask.distributed import Client
client = Client()

Client

Scheduler: tcp://127.0.0.1:60275
Dashboard: http://127.0.0.1:8787/status

Cluster

Workers: 4
Cores: 12
Memory: 17.18 GB

client.cluster.logs()

Scheduler

distributed.scheduler - INFO - Clear task state
distributed.scheduler - INFO -   Scheduler at:     tcp://127.0.0.1:60275
distributed.scheduler - INFO -   dashboard at:            127.0.0.1:8787
distributed.scheduler - INFO - Register tcp://127.0.0.1:60281
distributed.scheduler - INFO - Register tcp://127.0.0.1:60282
distributed.scheduler - INFO - Starting worker compute stream, tcp://127.0.0.1:60281
distributed.scheduler - INFO - Starting worker compute stream, tcp://127.0.0.1:60282
distributed.scheduler - INFO - Register tcp://127.0.0.1:60285
distributed.scheduler - INFO - Register tcp://127.0.0.1:60286
distributed.scheduler - INFO - Starting worker compute stream, tcp://127.0.0.1:60285
distributed.scheduler - INFO - Starting worker compute stream, tcp://127.0.0.1:60286
distributed.scheduler - INFO - Receive client connection: Client-6b6ba1d0-b3bd-11e9-9bd0-acde48001122

tcp://127.0.0.1:60281

distributed.worker - INFO -       Start worker at:      tcp://127.0.0.1:60281
distributed.worker - INFO -          Listening to:      tcp://127.0.0.1:60281
distributed.worker - INFO - Waiting to connect to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          3
distributed.worker - INFO -                Memory:                    4.29 GB
distributed.worker - INFO -       Local Directory: /Users/mrocklin/workspace/dask/dask-worker-space/worker-c4_44fym
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------

tcp://127.0.0.1:60282

distributed.worker - INFO -       Start worker at:      tcp://127.0.0.1:60282
distributed.worker - INFO -          Listening to:      tcp://127.0.0.1:60282
distributed.worker - INFO - Waiting to connect to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          3
distributed.worker - INFO -                Memory:                    4.29 GB
distributed.worker - INFO -       Local Directory: /Users/mrocklin/workspace/dask/dask-worker-space/worker-quu4taje
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------

tcp://127.0.0.1:60285

distributed.worker - INFO -       Start worker at:      tcp://127.0.0.1:60285
distributed.worker - INFO -          Listening to:      tcp://127.0.0.1:60285
distributed.worker - INFO - Waiting to connect to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          3
distributed.worker - INFO -                Memory:                    4.29 GB
distributed.worker - INFO -       Local Directory: /Users/mrocklin/workspace/dask/dask-worker-space/worker-ll4cozug
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------

tcp://127.0.0.1:60286

distributed.worker - INFO -       Start worker at:      tcp://127.0.0.1:60286
distributed.worker - INFO -          Listening to:      tcp://127.0.0.1:60286
distributed.worker - INFO - Waiting to connect to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          3
distributed.worker - INFO -                Memory:                    4.29 GB
distributed.worker - INFO -       Local Directory: /Users/mrocklin/workspace/dask/dask-worker-space/worker-lpbkkzj6
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:      tcp://127.0.0.1:60275
distributed.worker - INFO - -------------------------------------------------

Note: this looks better under any browser other than IE and Edge

Thanks to Jacob Tomlinson for this work.

3 - Hyperparameter selection with HyperBand

Dask-ML 1.0 has been released with a new HyperBandSearchCV meta-estimator for hyper-parameter optimization. This can be used as an alternative to RandomizedSearchCV to find similar hyper-parameters in less time by not wasting time on hyper-parameters that are not promising.

>>> import numpy as np
>>> from dask_ml.model_selection import HyperbandSearchCV
>>> from dask_ml.datasets import make_classification
>>> from sklearn.linear_model import SGDClassifier

>>> X, y = make_classification(chunks=20)
>>> est = SGDClassifier(tol=1e-3)
>>> param_dist = {'alpha': np.logspace(-4, 0, num=1000),
>>>               'loss': ['hinge', 'log', 'modified_huber', 'squared_hinge'],
>>>               'average': [True, False]}

>>> search = HyperbandSearchCV(est, param_dist)
>>> search.fit(X, y, classes=np.unique(y))
>>> search.best_params_
{'loss': 'log', 'average': False, 'alpha': 0.0080502}

Thanks to Scott Sievert. You can see Scott talk about this topic in greater depth by watching his SciPy 2019 talk.

4 - Move bytes I/O handling out of Dask to FSSpec

We’ve spun out Dask’s internal code to read and write raw data to different storage systems out to a separate project, fsspec.

Here is a small example:

import fsspec

with fsspec.open("https://github.com/dask/dask/edit/master/README.rst") as f:
    print(f.read(1000))

with fsspec.open("s3://bucket/myfile.csv") as f:
    df = pd.read_csv(f)

with fsspec.open("hdfs:///path/to/myfile.csv") as f:
    df = pd.read_csv(f)

with fsspec.open("gcs://bucket/myfile.csv") as f:
    df = pd.read_csv(f)

Dask’s I/O infrastructure to read and write bytes from systems like HDFS, S3, GCS, Azure, and other remote storage systems is arguably the most uniform and comprehensive in Python today. Through tooling like s3fs, gcsfs, and ~~hdfs3~~ pyarrow.hdfs, it’s easy to read and write data in a Pythonic way to a variety of remote storage systems.

Early on we decided that we wanted this code to live outside of the mainline Dask codebase, which is why they are independent projects. This choice allowed other libraries, like Pandas, Zarr, and others to benefit from this work, without a strict dependency on Dask. However, there was still code within Dask that helped to unify them a bit. We’ve moved this code out to an external project, fsspec which includes all of the centralization code that Dask used to provide, as well as a formal specification for what a remote data system should look like in order to be compatible. This also helps to unify efforts with other projects like Arrow.

Special thanks to Martin Durant for shepherding Dask’s I/O infrastructure over the years, and for doing the more immediate work of splitting out fsspec.

You can read more about FSSpec and its transition out of Dask here.

5 - Async/Await everywhere, and cleaner setup for developers

In Dask 2.0 we dropped Python 2 support and now support only Python 3.5 and above. This allows us to adopt async and await syntax for concurrent execution rather than an older coroutine based approach with yield. The differences here started out as largely aesthetic, but triggered a number of substantive improvements as we walked through the codebase cleaning things up. Starting and stopping internal Scheduler, Worker, Nanny, and Client objects is now far more uniform, reducing the presence of subtle bugs.

This is discussed in more detail in the Python API setup documentation and is encapsulated in this code example from those docs:

import asyncio

from dask.distributed import Scheduler, Worker, Client

async def f():
    async with Scheduler() as s:
        async with Worker(s.address) as w1, Worker(s.address) as w2:
            async with Client(s.address, asynchronous=True) as client:
                future = client.submit(lambda x: x + 1, 10)
                result = await future
                print(result)

asyncio.get_event_loop().run_until_complete(f())

As a result of this and other internal cleanup intermittent testing failures in our CI have disappeared, and developer mood is high :)

6 - A new SSHCluster

We’ve added a second SSH cluster deployment solution. It looks like this:

from distributed.deploy.ssh2 import SSHCluster  # this will move in future releases

cluster = SSHCluster(
    hosts=["host1", "host2", "host3", "host4"],
    # hosts=["localhost"] * 4  # if you want to try this out locally,
    worker_kwargs={"nthreads": 4},
    scheduler_kwargs={},
    connect_kwargs={"known_hosts": None}
)

Note that this object is experimental, and subject to change without notice

We worked on this for two reasons:

Our user survey showed that a surprising number of people were deploying Dask with SSH. Anecdotally they seem to be just SSHing into machines and then using Dask’s normal Dask Command Line Interface)

We wanted a solution that was easier than this.
We’ve been trying to unify the code in the various deployment solutions (like Kubernetes, SLURM, Yarn/Hadoop) to a central codebase, and having a simple SSHCluster as a test case has proven valuable for testing and experimentation.

Also note, Dask already has a dask-ssh solution today that is more mature

We expect that unification of deployment will be a central theme for the next few months of development.

Acknowledgements

There have been two releases since the last time we had a release blogpost. The following people contributed to the following repositories since the 2.0 release on June 30th:

dask/dask
- Brett Naul
- Daniel Saxton
- David Brochart
- Davis Bennett
- Elliott Sales de Andrade
- GALI PREM SAGAR
- James Bourbeau
- Jim Crist
- Loïc Estève
- Martin Durant
- Matthew Rocklin
- Matthias Bussonnier
- Natalya Rapstine
- Nick Becker
- Peter Andreas Entschev
- Ralf Gommers
- Richard (Rick) Zamora
- Sarah Bird
- Sean McKenna
- Tom Augspurger
- Willi Rath
- Xavier Holt
- andrethrill
- asmith26
- msbrown47
- tshatrov
dask/distributed
- Christian Hudon
- Gabriel Sailer
- Jacob Tomlinson
- James Bourbeau
- Jim Crist
- Martin Durant
- Matthew Rocklin
- Pierre Glaser
- Russ Bubley
- tjb900
dask/dask-jobqueue
- Guillaume Eynard-Bontemps
- Leo Singer
- Loïc Estève
- Matthew Rocklin
- Stuart Berg
dask/dask-examples
- Chris White
- Ian Rose
- Matthew Rocklin
dask/dask-mpi
- Anderson Banihirwe
- Kevin Paul
- Matthew Rocklin
dask/dask-kubernetes
- Matthew Rocklin
- Tom Augspurger
dask/dask-ml
- Roman Yurchak
- Tom Augspurger
dask/dask-yarn
- Al Johri
- Jim Crist
dask/dask-examples

Dask Release 2.0

2019-06-22T00:00:00+00:00

Please take the Dask User Survey for 2019. Your reponse helps to prioritize future work.

We are pleased to announce the release of Dask version 2.0. This is a major release with bug fixes and new features.

Most major version changes of software signal many new and exciting features. That is not the case with this release. Instead, we’re bumping the major version number because we’ve broken a few APIs to improve maintainability, and because we decided to drop support for Python 2.

This blogpost outlines these changes.

As always, you can conda install Dask:

conda install dask

or pip install from PyPI:

pip install "dask[complete]" --upgrade

Full changelogs are available here:

Drop support for Python 2

Python 2 reaches end of life in 2020, just six months away. Most major PyData projects are dropping Python 2 support around now. See the Python 3 Statement for more details about some of your favorite projects.

Python 2 users can continue to use older versions of Dask, which are in widespread use today. Institutions looking for long term support of Dask in Python 2 may wish to reach out to for-profit consulting companies, like Quansight.

Dropping Python 2 will allow maintainers to spend more of their time fixing bugs and developing new features. It will also allow the project to adopt more modern development practices going forward.

Small breaking changes

We now include a list with a brief description of most of the breaking changes:

The distributed.bokeh module has moved to distributed.dashboard
Various ncores keywords have been moved to nthreads
Client.map/gather/scatter no longer accept iterators and Python queue objects. Users can handle this themselves with submit/as_completed or can use the Streamz library.
The worker /main route has moved to /status
Cluster.workers is now a dictionary mapping worker name to worker, rather than a list as it was before

Some larger fun changes

We didn’t only break things. We also added some new things :)

Array metadata

Previously Dask Arrays were defined by their shape, chunkshape, and datatype, like float, int, and so on.

Now, Dask Arrays also know the type of their chunks. Historically this was almost always a NumPy array, so it didn’t make sense to store, but now that Dask Arrays are being used more frequently with sparse array chunks and GPU array chunks we now maintain this information as well in a ._meta attribute. This is already how Dask dataframes work, so it should be familiar to advanced users of that module.

>>> import dask.array as da
>>> x = da.eye(1000000)
>>> x._meta
array([], shape=(0, 0), dtype=float64)

>>> import sparse
>>> s = x.map_blocks(sparse.COO.from_numpy)
>>> s._meta
<COO: shape=(0, 0), dtype=float64, nnz=0, fill_value=0.0>

This work was largely done by Peter Entschev

Array HTML output

Dask arrays now print themselves nicely in Jupyter notebooks, showing a table of information about their size and chunk size, and also a visual diagram of their chunk structure.

import dask.array as da
x = da.ones((10000, 1000, 1000))

	Array	Chunk
Bytes	80.00 GB	125.00 MB
Shape	(10000, 1000, 1000)	(250, 250, 250)
Count	640 Tasks	640 Chunks
Type	float64	numpy.ndarray

1000 1000 10000

Proxy Worker dashboards from the Scheduler dashboard

If you’ve used Dask.distributed they you’re probably familiar with Dask’s scheduler dashboard, which shows the state of computations on the cluster with a real-time interactive Bokeh dashboard. However you may not be aware that Dask workers also have their own dashboard, which shows a completely separate set of plots for the state of that individual worker.

Historically these worker dashboards haven’t been as commonly used because it’s hard to connect to them. Users don’t know their address, or network rules don’t enable direct web connections. Fortunately, the scheduler dashboard is now able to proxy a connection from the user to the worker dashbaord.

You can access this by clicking on the “Info” tab and then selecting the “dashboard” link next to any of the workers. You will need to also install jupyter-server-proxy

pip install jupyter-server-proxy

Thanks to Ben Zaitlen for this fun addtition. We hope that now that these plots are made more visible, people will invest more into developing plots for them.

Black everywhere

We now use the Black code formatter throughout most Dask repositories. These repositories include pre-commit hooks, which we recommend when developing on the project.

cd /path/to/dask
git checkout master
git pull upstream master

pip install pre-commit
pre-commit install

Git will then call black and flake8 whenever you attempt to commit code.

Dask Gateway

We would also like to inform readers about the somewhat new Dask Gateway project that enables institutions and IT to control many Dask clusters for a variety of users.

Acknowledgements

There have been several releases since the last time we had a release blogpost. The following people contributed to the following repositories since the 1.1.0 release on January 23rd:

dask/dask
- (Rick) Richard J Zamora
- Abhinav Ralhan
- Adam Beberg
- Alistair Miles
- Álvaro Abella Bascarán
- Anderson Banihirwe
- Aploium
- Bart Broere
- Benjamin Zaitlen
- Bouwe Andela
- Brett Naul
- Brian Chu
- Bruce Merry
- Christian Hudon
- Cody Johnson
- Dan O’Donovan
- Daniel Saxton
- Daniel Severo
- Danilo Horta
- Dimplexion
- Elliott Sales de Andrade
- Endre Mark Borza
- Genevieve Buckley
- George Sakkis
- Guillaume Lemaitre
- HSR05
- Hameer Abbasi
- Henrique Ribeiro
- Henry Pinkard
- Hugo
- Ian Bolliger
- Ian Rose
- Isaiah Norton
- James Bourbeau
- Janne Vuorela
- John Kirkham
- Jim Crist
- Joe Corbett
- Jorge Pessoa
- Julia Signell
- JulianWgs
- Justin Poehnelt
- Justin Waugh
- Ksenia Bobrova
- Lijo Jose
- Marco Neumann
- Mark Bell
- Martin Durant
- Matthew Rocklin
- Michael Eaton
- Michał Jastrzębski
- Nathan Matare
- Nick Becker
- Paweł Kordek
- Peter Andreas Entschev
- Philipp Rudiger
- Philipp S. Sommer
- Roma Sokolov
- Ross Petchler
- Scott Sievert
- Shyam Saladi
- Søren Fuglede Jørgensen
- Thomas Zilio
- Tom Augspurger
- Yu Feng
- aaronfowles
- amerkel2
- asmith26
- btw08
- gregrf
- mbarkhau
- mcsoini
- severo
- tpanza
dask/distributed
- Adam Beberg
- Benjamin Zaitlen
- Brett Jurman
- Brett Randall
- Brian Chu
- Caleb
- Chris White
- Daniel Farrell
- Elliott Sales de Andrade
- George Sakkis
- James Bourbeau
- Jim Crist
- John Kirkham
- K.-Michael Aye
- Loïc Estève
- Magnus Nord
- Manuel Garrido
- Marco Neumann
- Martin Durant
- Mathieu Dugré
- Matt Nicolls
- Matthew Rocklin
- Michael Delgado
- Michael Spiegel
- Muammar El Khatib
- Nikos Tsaousis
- Olivier Grisel
- Peter Andreas Entschev
- Sam Grayson
- Scott Sievert
- Tom Augspurger
- Torsten Wörtwein
- amerkel2
- condoratberlin
- deepthirajagopalan7
- jukent
- plbertrand
dask/dask-ml
- Alejandro
- Florian Rohrer
- James Bourbeau
- Julien Jerphanion
- Matthew Rocklin
- Nathan Henrie
- Paul Vecchio
- Ryan McCormick
- Saadullah Amin
- Scott Sievert
- Sriharsha Atyam
- Tom Augspurger
dask/dask-jobqueue
- Andrea Zonca
- Guillaume Eynard-Bontemps
- Kyle Husmann
- Levi Naden
- Loïc Estève
- Matthew Rocklin
- Matyas Selmeci
- ocaisa
dask/dask-kubernetes
- Brian Phillips
- Jacob Tomlinson
- Jim Crist
- Joe Hamman
- Joseph Hamman
- Matthew Rocklin
- Tom Augspurger
- Yuvi Panda
- adam
dask/dask-examples
- Christoph Deil
- Genevieve Buckley
- Ian Rose
- Martin Durant
- Matthew Rocklin
- Matthias Bussonnier
- Robert Sare
- Tom Augspurger
- Willi Rath
dask/dask-labextension
- Daniel Bast
- Ian Rose
- Matthew Rocklin
- Yuvi Panda

Dask Release 1.1.0

2019-01-23T00:00:00+00:00

I’m pleased to announce the release of Dask version 1.1.0. This is a major release with bug fixes and new features. The last release was 1.0.0 on 2018-11-29. This blogpost outlines notable changes since the last release.

You can conda install Dask:

conda install dask

or pip install from PyPI:

pip install dask[complete] --upgrade

Full changelogs are available here:

A lot of work has happened over the last couple months, and we encourage people to look through the changelog to get a sense of the kinds of incremental changes that developers are working on.

There are also a few notable changes in this release that we’ll highlight here:

Support for the recent Numpy 1.16 and Pandas 0.24 releases
Support for Pandas Extension Arrays (see Tom Augspurger’s post on the topic)
High level graph in Dask dataframe and operator fusion in simple cases
Increased support for other libraries that look enough like Numpy and Pandas to work within Dask Array/Dataframe

Support for Numpy 1.16 and Pandas 0.24

Both Numpy and Pandas have been evolving quickly over the last few months. We’re excited about the changes to extensibility arriving in both libraries. The Dask array/dataframe submodules have been updated to work well with these recent changes.

Pandas Extension Arrays

In particular Dask Dataframe supports Pandas Extension arrays, meaning that it’s easier to use third party Pandas packages like CyberPandas or Fletcher in parallel with Dask Dataframe.

For more information see Tom Augspurger’s post

High Level Graphs in Dask Dataframe

For a while Dask array has had some high level graphs for “atop” operations (elementwise, broadcasting, transpose, tensordot, reductions), which allow for reduced overhead and task fusion on computations within this class.

y = da.exp(x + 1).T  # These operations get fused to a single task

We’ve renamed atop to blockwise to be a bit more generic, and have also started applying it to Dask Dataframe, which helps to reduce overhead substantially when doing computations with many simple operations.

This still needs to be improved to increase the class of cases where it works, but we’re already seeing nice speedups on previously unseen workloads.

The da.atop function has been deprecated in favor of da.blockwise. There is now also a dd.blockwise which shares a common code path.

Non-Pandas dataframe and Non-Numpy array types

We’re working to make Dask a bit more agnostic to the types of in-memory array and dataframe objects that it can manipulate. Rather than having Dask Array be a grid of Numpy arrays and Dask Dataframe be a sequence of Pandas dataframes, we’re relaxing that constraint to a grid of Numpy-like arrays and a sequence of Pandas-like dataframes.

This is an ongoing effort that has targetted alternate backends like scipy.sparse, pydata/sparse, cupy, cudf and other systems.

There were some recent posts on arrays and dataframes that show proofs of concept for this with GPUs.

Acknowledgements

There have been several releases since the last time we had a release blogpost. The following people contributed to the dask/dask repository since the 0.19.0 release on September 5th:

Anderson Banihirwe
Antonino Ingargiola
Armin Berres
Bart Broere
Carlos Valiente
Daniel Li
Daniel Saxton
David Hoese
Diane Trout
Damien Garaud
Elliott Sales de Andrade
Eric Wolak
Gábor Lipták
Guido Imperiale
Guillaume Eynard-Bontemps
Itamar Turner-Trauring
James Bourbeau
Jan Koch
Javad
Jendrik Jördening
Jim Crist
Jonathan Fraine
John Kirkham
Johnnie Gray
Julia Signell
Justin Dennison
M. Farrajota
Marco Neumann
Mark Harfouche
Markus Gonser
Martin Durant
Matthew Rocklin
Matthias Bussonnier
Mina Farid
Paul Vecchio
Prabakaran Kumaresshan
Rahul Vaidya
Stephan Hoyer
Stuart Berg
TakaakiFuruse
Takahiro Kojima
Tom Augspurger
Yu Feng
Zhenqing Li
@milesial
@samc0de
@slnguyen

The following people contributed to the dask/distributed repository since the 0.19.0 release on September 5th:

Adam Klein
Brett Naul
Daniel Farrell
Diane Trout
Dirk Petersen
Eric Ma
Jim Crist
John Kirkham
Gaurav Sheni
Guillaume Eynard-Bontemps
Loïc Estève
Marius van Niekerk
Matthew Rocklin
Michael Wheeler
MikeG
NotSqrt
Peter Killick
Roy Wedge
Russ Bubley
Stephan Hoyer
@tjb900
Tom Rochette
@fjetter