snoyberg

{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TypeFamilies #-}
module Main (main) where

import Foreign
import Foreign.C.Types

parsonsmatt

instance ToSchema (Book' '[]) where
    declareNamedSchema _ =
        pure . NamedSchema Nothing $ mempty
            & type_ .~ SwaggerObject

instance (KnownSymbol k, ToSchema v, ToSchema (Book' xs)) => ToSchema (Book' ( k :=> v ': xs )) where
    declareNamedSchema _ = do
        valRef <- declareSchemaRef (Proxy @v)
        let key = Text.pack (symbolVal (Proxy @k))
            rest = toNamedSchema (Proxy @(Book' xs))

embanner

jcoglan

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef char * BLOB;

typedef struct BufferChunk {
    int length;
    int cursor;
    BLOB data;

Rich-Harris

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

• TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
• In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
• Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

joshdover

Idiomatic React Testing Patterns

Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.

Setup

I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern that gives great defaults for each test example but allows every example to override props when needed:

predict.py

import numpy as np
import tensorflow as tf
from tensorflow.python.ops import seq2seq
from tensorflow.python.ops import rnn_cell

seed = 7
np.random.seed(7)


def generate_sequences(sequence_num, sequence_length, batch_size):

ghoseb

(ns clj-spec-playground
  (:require [clojure.string :as str]
            [clojure.spec :as s]
            [clojure.test.check.generators :as gen]))

;;; examples of clojure.spec being used like a gradual/dependently typed system.

(defn make-user
  "Create a map of inputs after splitting name."
  ([name email]

alirobe

### 
###
### UPDATE: For Win 11, I recommend using this tool in place of this script: 
### https://christitus.com/windows-tool/
### https://github.com/ChrisTitusTech/winutil
### https://www.youtube.com/watch?v=6UQZ5oQg8XA
### iwr -useb https://christitus.com/win | iex
###
###

nateberkopec

# gem 'rails'
gem "activerecord"
gem "actionpack"
gem "actionview"
gem "actionmailer"
gem "activejob"
gem "activesupport"
gem "railties"
gem "sprockets-rails"
gem 'sqlite3'