- Web Wormhole https://webwormhole.io/ https://github.com/saljam/webwormhole
- ToffeeShare https://toffeeshare.com/
- FilePizza https://file.pizza/
ShareDrop sharedrop.io https://github.com/szimek/sharedrop(SOLD, not recommended, use one of the forks)A clone SnapDrop snapdrop.net https://github.com/RobinLinus/snapdrop(SOLD, not recommended, use one of the forks)- A fork PairDrop https://pairdrop.net/ https://github.com/schlagmichdoch/pairdrop
- Instant.io https://instant.io/
- FileTC https://file.tc/
The title is a bit broad. What I am going to write about is gather.town. I complained quite a bit re how recent conferences used the gather platform. Here I try to be more constructive, and explain why I think things were bad, and also how I think they can be improved (substantially).
I think gather.town is a fantastic interface, and I think it was mis-used or mal-used in some recent xACL conferences (EACL 2021, EMNLP 2020). It is really disappointing, as there is so much potential, which was not only left unfulfilled, but even in some cases was worse than not having gather at all. This post will try to explain what I think was bad, and how I think things can be improved.
Based on Summary Trace API,
device_name = tf.test.gpu_device_name()
if not tf.test.is_gpu_available():
raise SystemError('GPU device not found')
print('Found GPU at: {}'.format(device_name))
os.makedirs(os.path.join(args.exp_dir, 'plugins/profile'), exist_ok=True)
tf.summary.trace_on(graph=True, profiler=True)
tracing_params = params.copy()
A lot of Kotlin features can be traced back to functional programming languages, eg
- Heavy use of immutability-by-default and map, filter etc functions
- Type inference
- Data classes (which enable pattern matching)
- Null safety and dealing with the absence of values
However, Kotlin is missing many incredibly useful data types that are ubiquitous in functional programming languages, eg Either, Try etc.
The fundamental unit in PyTorch is the Tensor. This post will serve as an overview for how we implement Tensors in PyTorch, such that the user can interact with it from the Python shell. In particular, we want to answer four main questions:
- How does PyTorch extend the Python interpreter to define a Tensor type that can be manipulated from Python code?
- How does PyTorch wrap the C libraries that actually define the Tensor's properties and methods?
- How does PyTorch cwrap work to generate code for Tensor methods?
- How does PyTorch's build system take all of these components to compile and generate a workable application?
PyTorch defines a new package torch
. In this post we will consider the ._C
module. This module is known as an "extension module" - a Python module written in C. Such modules allow us to define new built-in object types (e.g. the Tensor
) and to call C/C++ functions.
from keras.layers import Recurrent | |
import keras.backend as K | |
from keras import activations | |
from keras import initializers | |
from keras import regularizers | |
from keras import constraints | |
from keras.engine import Layer | |
from keras.engine import InputSpec |
""" Some description. | |
""" | |
from __future__ import absolute_import | |
from __future__ import division | |
from __future__ import print_function | |
import sys | |
import json | |
import tqdm |
import numpy as np | |
from keras.layers import GRU, initializations, K | |
from collections import OrderedDict | |
class GRULN(GRU): | |
'''Gated Recurrent Unit with Layer Normalization | |
Current impelemtation only works with consume_less = 'gpu' which is already | |
set. | |
# Arguments |