scarecrow1123

import argparse
import logging
from logging import Filter
from logging.handlers import QueueHandler, QueueListener

import torch
import torch.distributed as dist
import torch.multiprocessing as mp
from torch.multiprocessing import Queue

scarecrow1123

{
    // ....
    "trainer": {
        "type": "fp16-trainer",
        "mixed_precision": true,
        // other options
    }
    // ....
}

scarecrow1123

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

scarecrow1123

General Information

• Conversations and lectures
• based on the actual speech that is used at Universities
• Accents - North America, U.K. and Australia
• 2 to 3 conversations and 4 - 6 lectures
• Can be heard only one time
• conversations - 3 minutes long and 5 mcqs
• questions can't be seen while listening to the conversations
• Lecures - 5 mins long and 6 mcqs
• 60 - 90 mins to complete the listening section

scarecrow1123

Moved to a separate repository

scarecrow1123

tmux cheatsheet

As configured in my dotfiles.

start new:

tmux

start new with session name:

scarecrow1123

Classes

Reduce accessbility

Somehow the author keeps on reiterating this point the reason for which essentially boils down as below

• The client need not know the internal implementation/representation of the class/object
• If exposed, it would become cumbersome in the event of changing the implementation/representation of the class, which may cause several breakages in client code. On the other hand if the field was exposed through getter methods, the change in the implementation would have gone unnoticed by the client.
• Allow public access, if neccessary only in case of static final and primitive fields.(even in this case, when the field or object itself is passed from one thread to another, one needs to exercise caution - why?)
• But a final array field may not become immutable after all. In that case make it private and expose an unmodifiable public list field. Or make it private and provide a getter method which returns a copy of the array.

scarecrow1123

Test mbostock's awesome bl.ocks.org

scarecrow1123

set expandtab
set shiftwidth=2
set softtabstop=2
set autoindent
syntax enable

set number 	"show line numbers
set cursorline 	"highlight current line
filetype indent on

scarecrow1123

# tmux.conf - almost everything noted from the book "tmux Productive Mouse-Free Development" by "Brian P. Hogan"
# change default prefix to C-a and unbind C-b
set -g prefix C-a
unbind-key C-b

# to enable other programs to detect C-a(by double pressing)
bind-key C-a send-prefix

# '|' for vertical split and '-' for horizontal split
bind | split-window -h