munificent

#include <time.h> //  Robert Nystrom
#include <stdio.h> // @munificentbob
#include <stdlib.h> //     for Ginny
#define  r return    //    2008-2019
#define  l(a, b, c, d) for (i y=a;y\
<b; y++) for (int x = c; x < d; x++)
typedef int i;const i H=40;const i W
=80;i m[40][80];i g(i x){r rand()%x;
}void cave(i s){i w=g(10)+5;i h=g(6)
+3;i t=g(W-w-2)+1;i u=g(H-h-2)+1;l(u

MrTrustor

#!/bin/bash

# Copyright 2017 Théo Chamley
# 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:
#
# The above copyright notice and this permission notice shall be included in all copies or

sorenlouv

function mySlowFunction(baseNumber) {
	console.time('mySlowFunction');
	let result = 0;	
	for (var i = Math.pow(baseNumber, 7); i >= 0; i--) {		
		result += Math.atan(i) * Math.tan(i);
	};
	console.timeEnd('mySlowFunction');
}

mySlowFunction(8); // higher number => more iterations => slower

skevy

Note

I would recommend @acdlite's redux-actions over the methods suggested in this Gist.

The methods below can break hot-reloading and don't support Promise-based actions.

Even though 'redux-actions' still uses constants, I've come to terms with the fact that constants can be good, especially in bigger projects. You can reduce boilerplate in different places, as described in the redux docs here: http://gaearon.github.io/redux/docs/recipes/ReducingBoilerplate.html

---

acdlite

/**
 * Basic proof of concept.
 * - Hot reloadable
 * - Stateless stores
 * - Stores and action creators interoperable with Redux.
 */

import React, { Component } from 'react';

export default function dispatch(store, atom, action) {

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

tbranyen

1. Include Weather Icons in your app: https://github.com/erikflowers/weather-icons

2. Include the below JSON in your application, for example purposes, lets assume it's a global named weatherIcons.

3. Make a request to OpenWeatherMap:

req = $.getJSON('http://api.openweathermap.org/data/2.5/weather?q=London,uk&callback=?');

dt

light <- hardware.pin8;
light.configure(ANALOG_IN);

was_brewing <- false;
brew_light <- 45000;

poll_time <- 30;
skip_updates <- 10;
until_heartbeat <- 0;

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {

dt

light <- hardware.pin8;
light.configure(ANALOG_IN);

function check() {
  agent.send("lvl", light.read());
  imp.wakeup(10, check);
}
check();