Naddiseo

/* global require, module */
var isString = require('lodash/lang/isString');

var htmlTags = (
	'^(html|base|head|link|meta|style|title|address|article|' +
	'body|footer|header|h[1-6]|hgroup|nav|section|dd|div|dl|dt|' +
	'figcaption|figure|hr|li|main|ol|p|pre|ul|a|abbr|b|bdi|bdo|br|' +
	'cite|code|data|dfn|em|i|kbd|mark|q|rp|rt|rtc|ruby|s|samp|small|span|strong|sub|' +
	'time|u|var|wbr|area|audio|img|map|track|video|embed|iframe|object|param|source|' +
	'canvas|noscript|script|del|ins|caption|col|colgroup|table|tbody|td|tfoot|th|thead|tr|' +

pelonpelon

function state (namespace) {
  if (!namespace) return internalState[internalState.length - 1]
  internalState.push([namespace, options])
  m.redirect(namespace, options)
}

function goto (namespace, options) {
  return function (e) {
    e.preventDefault()
    e.stopPropagation()

avesus

xset r rate 170 77 setxkbmap -layout "us,ru" -option "grp:caps_toggle" -option "grp_led:scroll" -option "compose:ralt"

joyrexus

Nice answer on stackoverflow to the question of when to use one or the other content-types for POSTing data, viz. application/x-www-form-urlencoded and multipart/form-data.

“The moral of the story is, if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.”

---

Matt Bridges' answer in full:

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing

StephanHoyer

'use strict';

var m = require('mithril');
var extend = require('lodash').extend;
var setFocus = require('../util/viewhelper').setFocus;
var keymage = require('keymage');

function noop(){}

function addClass(el, className) {

barneycarroll

var animating = false;

// Define an animator consisting of optional incoming and outgoing animations. 
// alwaysAnimate is false unless specified as true: false means an incoming animation will only trigger if an outgoing animation is also in progress.
// forcing dontClone to true means the outward animation will use the original element rather than a clone. This could improve performance by recycling elements, but can lead to trouble: clones have the advantage of being stripped of all event listeners.
function animator( incoming, outgoing, alwaysAnimate, dontClone ){
	// The resulting animator can be applied to any number of components
	return function animate( x, y, z ){
		var config;
		var parent;

bsharper

# If you run this as a script it should patch and compile BPG for you
wget http://bellard.org/bpg/libbpg-0.9.tar.gz
tar xvzf libbpg-0.9.tar.gz
cd libbpg-0.9
wget https://gist.githubusercontent.com/bsharper/dd517547f6e1bcabf6be/raw/d125ab609e07e4fd624137543d36eb48bcaab91b/bpg_osx.patch
patch -p1 < bpg_osx.patch
# Output should be:
#   patching file Makefile
#   patching file libavutil/mem.c
# If you see something like "patch unexpectedly ends in middle of line" it should still work

mbbx6spp

Gerrit vs Github: for code review and codebase management

Sure, Github wins on the UI. Hands down. But, despite my initial annoyance with Gerrit when I first started using it almost a year ago, I am now a convert. Fully. Let me tell you why.

Note: This is an opinionated (on purpose) piece. I assume your preferences are like mine on certain ideas, such as:

• Fast-forward submits to the target branch are better than allowing merge commits to the target branch. The reason I personally prefer this is that, even if a non-conflicting merge to the target branch is possible, the fact that the review/pull request is not up to date with the latest on the target branch means feature branch test suite runs in the CI pipeline reporting on the review/PR may not be accurate. Another minor point is that forced merge commits are annoying as fuck (opinion) and clutter up Git log histories unnecessarily and I prefer clean histories.
• Atomic/related changes all in one commit is something worth striving for. Having your dev

avesus

program > file       # write program stdout to file
program1 | program2  # send stdout of program1 to stdin of program2
program < file       # write file to program stdin
program1 && program2 # exec program2 only if program1 returns 0
program1; program2   # exec program2 ever if program1 failed

cmd1; cmd2; cmd3 & - will only execute cmd3 in the background
cmd1 && cmd2 && cmd3 & - will execute the entire chain in the background IF there are no errors.

To cater for unconditional execution, using parenthesis solves this :

pburtchaell

/**
 * VH and VW units can cause issues on iOS devices: http://caniuse.com/#feat=viewport-units
 * 
 * To overcome this, create media queries that target the width, height, and orientation of iOS devices. 
 * It isn't optimal, but there is really no other way to solve the problem. In this example, I am fixing 
 * the height of element `.foo` —which is a full width and height cover image.
 *
 * iOS Resolution Quick Reference: http://www.iosres.com/
 */