jfhbrook

[api]: New apis / changes to apis
[test]: Update test/* files
[dist]: Changes to submodules, version bumps, updates to package.json
[minor]: Small changes
[doc]: Updates to documentation
[ux]: Updates to UX
[fix]: Bug fixes
[bin]: Update binary scripts associated with the project
[merge]: Resolved git merge from upstream or otherwise
[refactor]: Refactor of existing code with no external API changes

jadeallenx

tl;dr You should watch this.

It's interesting to me that a significant number of talks in this year's Strange Loop conference referenced a 1966 paper by Peter Landin called (somewhat tongue in cheek) "The Next 700 Programming Languages". In this paper, Landin describes a programming language which he says in a footnote might be aptly called "Church without the lambda" - but which in the paper is called "If You See What I Mean" (ISWIM).

Alvaro's talk delved deeply into the question of "What is the semantics or meaning of a program?" Alvaro's thesis is that the meaning of a program is to produce desired outcomes from a computing system but that current languages focus on

ashleygwilliams

last night's papers

papers tef sent you last night

• Object-Oriented Programming Versus Abstract Data Types, William R. Cook
• On the Duality of Operating System Structures, Hugh C. Lauer, Roger M. Needham
• The Expression Problem, Philip Wadler

papers forrest sent you last night

vizanto

{ config, lib, pkgs, ... }:

{
  imports = [ ];

  ### SmartOS Linux Branded Zone specific configuration

  nix.extraOptions = ''
    build-users-group =
  '';

ecin

package main

/*
Ping vs Pong: A Gladiatorial Match
Two goroutines enter, only one leaves...
*/

/*
#cgo LDFLAGS: -lprobes -L/usr/local/lib
#include "probes.h"

tarcieri

Semiprivate Keys

🚨 DANGER: INSECURE! 🚨

This may have seemed like a great idea in 2013, but the repeated "set/clear bits", a.k.a. clamping phases at each level of the hierarchy slowly subtract key strength.

Don't use this as described. Check out Ristretto.

Original text

Semi-private keys are an expansion of the traditional idea

rycee

{ config, lib, ... }:

with lib;

let

  cfg = config.services.nixBinaryCacheCache;

  nginxCfg = config.services.nginx;

raulraja

{-# LANGUAGE DeriveFunctor #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE OverlappingInstances #-}

module Main where

import Control.Monad.Free

Ruben-E

Setup interface eth1 and configure the DHCP/DNS server

configure
 
set interfaces ethernet eth1 address 192.168.2.254/24
set interfaces ethernet eth1 description "eth1 - LAN"
set interfaces ethernet eth1 duplex auto
set interfaces ethernet eth1 speed auto
 

steeve

How to cross compile Go with CGO programs for a different OS/Arch

It is possible to compile Go programs for a different OS, even though go build says otherwise.

You'll need:

• a valid toolchain for the platform/os you're targetting
• Go Tip (works on 1.1 and 1.2rc1 but you might as well be on tip)
• golang-crosscompile helper script https://github.com/davecheney/golang-crosscompile
• the patch provided