max-mapper

As a maintainer of native node add-on modules I have some questions about when and why NODE_MODULE_VERSION changes:

(@rvagg has anwered these in the comments below)

• does v8 use semver? how do you know when a v8 version breaks ABI compatibilility?
• is there a semantic meaning for v8 version numbers or is it arbitrary?
• who maintains this google doc I found? is it official?
• why is the latest entry from may in the v8 changelog? https://chromium.googlesource.com/v8/v8.git/+/master/ChangeLog
• how can you tell when all these future v8 versions will be stable? https://chromium.googlesource.com/v8/v8.git/+refs
• why must a node major version correspond to a specific v8 version? e.g. node v5 uses v8 4.6 and won't upgrade to 4.7

paulrouget

Document moved to: https://github.com/servo/servo/blob/master/HACKING_QUICKSTART.md

joliss

glog() {
  # requires git 1.8.3 for %C(auto) syntax
  git log --graph --date=short --pretty="%Cblue%ad%Creset %C(auto)%h %Cblue%an%Creset%C(auto)  %s __REFS:%d" "$@" \
    | perl -pe 's/__REFS:[^(]*\(([^)]+)\).*/$refs=$1; $refs=~s{, }{ }g; $refs=~s{tag: }{}g; $refs/e' \
    | less;
}

gl() {
  glog "$@" | head -n 10;
}

koreno

Prebase

git-prebase improves on 'git rebase -i' by adding information per commit regarding which files it touched.

• Each file gets an alpha-numeric identifier at a particular column, a list of which appears below the commit list. (The identifiers wrap around after the 62nd file)
• Commits can be moved up and down safely (without conflicts) as long as their columns don't clash (they did not touch the same file).

Installation

Add the executable to your path and git will automatically expose it as

varemenos

Get Git log in JSON format

git log --pretty=format:'{%n  "commit": "%H",%n  "abbreviated_commit": "%h",%n  "tree": "%T",%n  "abbreviated_tree": "%t",%n  "parent": "%P",%n  "abbreviated_parent": "%p",%n  "refs": "%D",%n  "encoding": "%e",%n  "subject": "%s",%n  "sanitized_subject_line": "%f",%n  "body": "%b",%n  "commit_notes": "%N",%n  "verification_flag": "%G?",%n  "signer": "%GS",%n  "signer_key": "%GK",%n  "author": {%n    "name": "%aN",%n    "email": "%aE",%n    "date": "%aD"%n  },%n  "commiter": {%n    "name": "%cN",%n    "email": "%cE",%n    "date": "%cD"%n  }%n},'

The only information that aren't fetched are:

• %B: raw body (unwrapped subject and body)
• %GG: raw verification message from GPG for a signed commit

max-mapper

We Need An Automated Module Build System

First, please read On Maintaining a Native Node Module

Problem: There is no standard way to build + distribute prebuilt binaries for node modules with native addons (e.g. C++ bindings).

There's a thing called NODE_MODULE_VERSION which is used to know if a native module was compiled for the correct version + flavor of node. If you are trying to load something compiled for e.g. iojs from February 2015 into node from March 2014 you will get an error something like Error: Module version mismatch. Expected 11, got 42. when you try and run your program. node uses numbers from 10 going up, and iojs uses numbers from 40 going up. The NODE_MODULE_VERSION gets bumped usually when V8 is upgraded, but sometimes for other reasons. It also gets even more complicated when you start talking about runtimes like Electron or Node-Webkit, but I won't get into that here. To my knowledge there is n

isaacs

Best Berry Cobbler

• Topping

  • 1 1/2 cups all-purpose flour
  • 1/2 cup firmly packed light brown sugar
  • 1 1/2 teaspoons double-acting baking powder
  • 3/4 teaspoon salt
  • 1 tablespoon cinnamon

• 1 tsp cardamom

evanlucas

commit 09e46c3d48d9c81daa68e4dc69a249fa80b3287f
Author: Evan Lucas <[email protected]>
Date:   Mon Jun 1 10:17:19 2015 -0500

    allow -ie

diff --git a/src/node.js b/src/node.js
index 2516478..d370ce0 100644
--- a/src/node.js
+++ b/src/node.js

isaacs

New approach:

• spawn('sh', ...)

  Find the -c arg.

  Parse, and split up by && and || and | and ;, expanding each bit.

  Then spawn the exploded command line. When we explode it, we need to do the same thing with looking up env and shebang results.

seiyria

update: this post has been moved to my blog

Welcome! You might be reading this out of curiosity, or because you want to improve your programming capabilities to stop people from exploiting your JS games. Given that the first thing I do when I open a new incremental is open the terminal and start messing around with your games, I figured it's about time to write something about what I see and how I break your games. Consequently, I'll describe ways you can protect your games from the basic code manipulations I perform. Some might say "you're just ruining the game for yourself!" while I'm going to turn around and say "I don't care" -- that's not the point of this!

NB: This will only apply to vanilla JS applications, which I see more commonly. Frameworks like AngularJS and such are out of scope for this post. Advanced techniques such as using a debugger, while slightly more on topic, will also be disregarded for now.

Le