bengfarrell

#include <node.h>
#include <v8.h>
#include <stdio.h>
#include <stdlib.h>

using namespace v8;

Handle<Value> getRandomCoords2D(const Arguments& args) {
    HandleScope scope;
    

valmat

// 
// May destructing variables for itarable types and tuples
// 

module vlm.utils.destructing;

import std.range      : empty, popFront, front;
import std.traits     : isIterable;
import std.typecons   : Tuple, tuple, isTuple;
import std.functional : forward;

penguinbroker

hitTool = new paper.Tool();
hitTool.activate();
hitTool.onMouseDown = function (event) {
	hitOptions = {
		segments: true,
		stroke: true,
		fill: true,
		tolerance: 5
	};
	hitResult = paper.project.hitTest(event.point, hitOptions);

boennemann

If you have a package where a lot of people are still using a legacy version of it you might want to keep pushing (security-)fixes to that "branch".

Let's say the "latest" version of your package is "5.4.0", but there is as significant amount of people still using "4.7.4" – the last version you released before doing "5.0.0".

You found a critical bug in "5.4.0" and push it as out as "5.4.1", but it applies to "4.7.4" as well and so you want to do "4.7.5".

Assuming you have semantic-release already set up, you can follow these steps to get that "4.7.5" legacy support release out.

1. Go to the relevant commit: git checkout v4.7.4
2. Create a new branch from it: git checkout -b 4.x (You can choose any branch name, just make sure to use the same in step 3)

henrysher

Slides for Re:Invent conference

• Re:Invent 2016
• Re:Invent 2015
• Re:Invent 2014
• Re:Invent 2013
• Re:Invent 2012

mattbaker

This example expects to have d3.min.js and d3.layout.min.js in the same directory as pie.js and pie_serv.js.

Run with node pie_serv.js

dnadlinger

module thrift_vibe;

import std.range;
import thrift.codegen.base : isService;
import thrift.protocol.base;
import thrift.protocol.processor;
import thrift.transport.base;
import thrift.util.cancellation;
import vibe.core.log;
import vibe.core.net;

joost

# Steps we will take:
# 1. Change boot2docker image type (this will take long)
# 2. Resize image
# 3. Resize partion (using GParted)
#
# Also see: https://docs.docker.com/articles/b2d_volume_resize/

# Stop boot2docker
boot2docker stop

markerikson

[02:06 PM] acemarke: @Steven : a couple other thoughts on the whole NODE_ENV thing. First, per my comments, it really is a Node concept. It's a system environment variable that Node exposes to your application, and apparently the Express web server library popularized using its value to determine whether to do optimizations or not
[02:08 PM] acemarke: Second, because of its use within the Node ecosystem, web-focused libraries also started using it to determine whether to they were being run in a "development" environment vs a "production" environment, with corresponding optimizations. For example, React uses that as the equivalent of a C #ifdef to act as conditional checking for debug logging and perf tracking. If process.env.NODE_ENV is set to "production", all those if clauses will evaluate to false.
Third, in conjunction with a tool like UglifyJS that does minification and removal of dead code blocks, a clause that is surrounded with if(process.env.NODE_ENV !== "development")

MartinNowak