evancz

port module Spelling exposing (..)

import Html exposing (..)
import Html.App as App
import Html.Attributes exposing (..)
import Html.Events exposing (..)
import String


main =

lencioni

// Usage:
// 
// function loader() {
//   return new Promise((resolve) => {
//     if (process.env.LAZY_LOAD) {
//       require.ensure([], (require) => {
//         resolve(require('./SomeComponent').default);
//       });
//     }
//   });

natefaubion

test = map ((*) 2) >>> filter ((>) 15) >>> drop 3 >>> map show
src1 = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
src2 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

res1 = transduce' test src1 :: [String]
res2 = transduce' test src2 :: List String

darrenderidder

var Model = {};

var View = {};

var Controller = {};

kritzcreek

Generating collections of random numbers in PureScript

A problem that I've seen beginners run into in Haskell or PureScript a couple of times now is how to generate a List of random numbers. It's a common requirement for little games (which make for great first projects) to generate these, and it definitely seems to be a stumbling block.

Why are random numbers hard?

Randomness is considered a side effect in purely functional languages, which means that to generate them you usually need access to Eff/IO, which in turn means we need to deal with Monads. And while generating a single random number is usually pretty easy with do-notation, the typical intuition beginners have built when going from single values to a collection is to use map, but that fails.

Type-Directed-Search to the rescue

busypeoples

type field =
  | O
  | X

type position = (field, field, field, field)

type box = (position, position, position, position)

type units = list<box>

kumekay

#!/bin/bash

set -e

CURRENT_NAME="CurrentName"
CURRENT_OTP="current_name"

NEW_NAME="NewName"
NEW_OTP="new_name"

evancz

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

lambda-mike

Kakoune

set verbose mode (good for learning) :set -add global autoinfo normal

Movement

Goto

10g - go to line 10

Phate6660

Cryptography

https://github.com/spieglt/cloaker - password-based file encryptor (NOTE: uses Qt)
https://github.com/str4d/rage - file encryption tool and librarary that uses the age format

Media

https://github.com/mohanson/gameboy - gameboy emulator
https://github.com/bartwillems/lyriek - fetch the lyrics of a song playing in an mpris-compatible player
https://github.com/JakeStanger/mpd-discord-rpc - discordrpc for mpd