SMUsamaShah

Browser Based

1. Web Wormhole https://webwormhole.io/ https://github.com/saljam/webwormhole
2. ToffeeShare https://toffeeshare.com/
3. FilePizza https://file.pizza/
4. ShareDrop https://www.sharedrop.io/ https://github.com/szimek/sharedrop
   1. A clone SnapDrop https://snapdrop.net/ https://github.com/RobinLinus/snapdrop
      1. A fork PairDrop https://pairdrop.net/ https://github.com/schlagmichdoch/pairdrop
5. Instant.io https://instant.io/
6. file ai http://fileai.com/

yoavg

On virtual spaces (for scientific conferences)

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.

saravanabalagi

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()

androidfred

Kotlin Arrow

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.

johnloy

Electron apps

• Marp: Markdown presentation ecosystem.

• muryoimpl/slippr: markdown presentation app by Electron

• joe-re/cafe-pitch Markdown-driven presentation tool built on Electron.

Slide deck frameworks supporting Markdown source

killeent

A Tour of PyTorch Internals (Part I)

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:

1. How does PyTorch extend the Python interpreter to define a Tensor type that can be manipulated from Python code?
2. How does PyTorch wrap the C libraries that actually define the Tensor's properties and methods?
3. How does PyTorch cwrap work to generate code for Tensor methods?
4. How does PyTorch's build system take all of these components to compile and generate a workable application?

Extending the Python Interpreter

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.

aparrish

shamatar

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

tokestermw

""" Some description.
"""
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function

import sys
import json
import tqdm

udibr

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