nlinker

/* In your config.h define a new variable RGBLIGHT_TIMEOUT and give it a value in milliseconds */

#define RGBLIGHT_SLEEP  // allows us to use rgblight_suspend() and rgblight_wakeup() in keymap.c
#define RGBLIGHT_TIMEOUT 30000  // 30 seconds

nlinker

    #[test]
    fn test_view() {
        let command = vec![make_command(
            1,
            &[39, 40, 41, 42, 43, 44, 45, 46, 47, 48],
            "The command",
        )];
        let jobs = vec![
            make_job(39, &[10, 20], &[], "Install packages on server oss2.local."),
            make_job(40, &[11, 21], &[39], "Configure NTP on oss2.local."),

nlinker

{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DuplicateRecordFields #-}
{-# LANGUAGE NamedFieldPuns #-}
{-# LANGUAGE OverloadedLabels #-}

import Control.Lens
import Data.Generics.Labels
import GHC.Generics
import Prelude hiding (id)
import qualified Prelude

nlinker

Setting up a MSI laptop with GPU (gtx1060)

Installing Ubuntu 18.04, CUDA, CDNN, Pytorch and TensorFlow

Installing Ubuntu 18.04

Get Image

https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-ubuntu#0

Install (solving issues)

nlinker

1. Separation of immutable and mutable logic

Quite a lot of different people have been on the same trail of thought. Gary Bernhardt's formulation of a "functional core, imperative shell" seems to be the most voiced.

"Boundaries" - Gary Bernhardt

"Imperative shell" that wraps and uses your "functional core".. The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately. Functional core — Many fast unit tests. Imperative shell — Few integration tests

https://www.youtube.com/watch?v=yTkzNHF6rMs

nlinker

# MIT License

# Copyright (c) 2016 Chandler Abraham

# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:

nlinker

{-# LANGUAGE ConstraintKinds       #-}
{-# LANGUAGE DeriveGeneric         #-}
{-# LANGUAGE FlexibleContexts      #-}
{-# LANGUAGE FlexibleInstances     #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE TemplateHaskell       #-}
{-# LANGUAGE TypeApplications      #-}
{-# LANGUAGE TypeFamilies          #-}

nlinker

A bijection between numbers and pairs of numbers

Every once in a while I am faced with someone who denies that the rational numbers (or fractions, or pairs of integers) can be put into a bijective correspondence with natural numbers. To deal with the situation, I coded up the bijection. So now I can just say: "Really? Interesting. Please provide a pair of numbers (i,j) which is not enumerated by f, as defined in my gist." I am still waiting for a valid counter-example.

Anyhow, here is a demo of f and g at work. I am using the Python version, but a Haskell variant is included as well.

The 100-th pair is:

>>> f(100)

(10, 4)

nlinker

[tool.poetry]
name = "mnist"
version = "0.1.0"
description = ""
authors = ["Nick Linker"]

[tool.poetry.dependencies]
python = "^3.6"

[tool.poetry.dev-dependencies]

nlinker

#[derive(Debug)]
struct OrderBook {
    pair_name: String,
    pair_id: u64,
    bids: HashMap<String, String>,
    asks: HashMap<String, String>,

}
fn parse_poloniex_full_order_book(msg: &str) -> OrderBook{