tswaters

; bind ctrl+shift+alt f1-12 to output various macros files
Loop 12
{
  Hotkey, ^!+f%A_Index%, OutputMacroFile
}
return

OutputMacroFile:
  key := RegExReplace(A_thisHotkey, "[+!^]", "")
  FileRead, Contents, %AppData%\macros\%key%.txt

tswaters

This is way more complicated than it should be. The following conditions need to be met :

1. need to be able to track and merge in upstream changes
2. don't want remote commit messages in master
3. only interested in sub-directory of another repo
4. needs to go in a subdirectory in my repo.

In this particular case, I'm interested in bringing in the 'default' template of jsdoc as a sub-directory in my project so I could potentially make changes to the markup it genereates while also being able to update from upstream if there are changes. Ideally their template should be a separate repo added to jsdoc via a submodule -- this way I could fork it and things would be much easier.... but, it is what it is.

After much struggling with git, subtree and git-subtree, I ended up finding this http://archive.h2ik.co/2011/03/having-fun-with-git-subtree/ -- it basically sets up separate branches from tracking remote, the particular sub-directory, and uses git subtree contrib module to pull it all togther. Following are

tswaters

function ajax (opts) {
  if (this instanceof ajax) throw new Error("stop instantiating me!");
  if (!opts) throw new Error("pass opts, dummy.")
  if (!opts.url) throw new Error("pass url, dummy");
  if (!opts.method) throw new Error("pass method, dummy");

  var callbacks = {
    success: [],
    failure: [],
    always: []

tswaters

Not sure if this will at all come in handy, seems to me if the controller doesn't run it just won't show things. More of a starting point than anything else - without further ado, adding a $resolve function on a controller and have it resolve prior to controller initialization.

angular.module('resolve', [])
  .directive('resolveController', [
            '$controller', '$parse', '$injector', '$window',
    function($controller,   $parse,   $injector,   $window) {
      return {
        link: function(scope, elem, attrs) {
          var ctrlName = attrs.resolveController;

tswaters

setting up nodejs debugging on debian

$ npm insall -g node-inspector

$ node-inspector 
Node Inspector v0.12.2
Visit http://127.0.0.1:8080/?ws=127.0.0.1:8080&port=5858 to start debugging.

tswaters

function transformAttributes (stats) {
	attrs = parseInt(attrs, 8);
	var others  = attrs & 7;
	var user = attrs >> 3 & 7;
	var owner = attrs >> 6 & 7;
	return [
		owner & 4 ? 'r' : '-',
		owner & 2 ? 'w' : '-',
		owner & 1 ? 'x' : '-',

tswaters

Stubbing Classes and their Constructors in Native ES6

It's getting to that point. All the major evergreen browsers have (mostly) functional class keyword. But what does this mean for unit tests and the ability to stub constructors? In short, the answer is 'no'.

Many will tell you that es6 classes are just sugar coated es5 functions with prototypal inheritance setup. Mostly true - but there are two considerations that make testing more difficult:

• super is a magical keyword that calls the same method on the parent class. in cases with methods, easy enough to stub those, sinon.stub(parent.prototype, 'whatever') -- for super itself, there is no way to stub out the constructor call... normally not a huge deal, but...

• classes are not added to the global scope. where once you could call sinon.stub(global, 'SomeFunction'), sinon.stub(global, 'SomeClass') (or under window in the browser), this will throw an error.

tswaters

2016-04-21T16:07:40.563Z 6ti4fu88u7oq/1461254860543/16252/- INFO	hello	Seneca/2.0.0/6ti4fu88u7oq/1461254860543/16252/-	
2016-04-21T16:07:40.581Z 6ti4fu88u7oq/1461254860543/16252/- DEBUG	options	{ log:     { map:        [ { level: 'all',           handler: { [Function: print] routestr: '{ level: \'fatal\' }' } } ] },   tag: '-',   idlen: 12,   timeout: 11111,   default_plugins:     { basic: true,      cluster: true,      'mem-store': true,      repl: true,      transport: true,      web: true },   debug:     { fragile: false,      undead: false,      print: { options: false },      act_caller: false,      short_logs: false,      callpoint: false },   strict:     { result: true,      fixedargs: true,      add: false,      find: true,      maxloop: 11 },   actcache: { active: true, size: 11111 },   trace: { act: false, stack: false, unknown: 'warn' },   stats: { size: 1024, interval: 60000, running: false },   deathdelay: 11111,   admin: { local: false, prefix: '/admin' },   plugin: {},   internal:     { close_s

tswaters

Let's say you have a string that you want to include in browserify. This needs to be identified by a path so you can require it later, but a file does not exist at that path's location.

You can pass streams to browserify, and streams can include arbitrary strings... the key is ignoreMissing:true which will dutifully ignore any required files that aren't actually on the file system.

Now, for it to actually come through as something you can require, it needs to be exposed as an explicit string. While this works, it means you can only reference it by this name... see with-expose.js

The main problem of course is that mechanisms for directory loading won't work like they do in a normal commonjs fashion.

i.e., consider the following was used for ./requires:

tswaters

var moment = require('moment-timezone')

console.log(midnightPst('2017-12-31T13:59:59.999Z')) // provided as 11:59 HAST
console.log(midnightPst('2018-01-01T07:59:59.999Z')) // provided as 11:59 PST
console.log(midnightPst('2018-01-01T04:59:59.999Z')) // provided as 11:59 EST
console.log(midnightPst('2018-12-31T23:59:59.999Z')) // provided as 11:59 UTC

// east of GMT doesn't work.
console.log(midnightPst('2018-01-01T08:59:59.999Z')) // provided as 11:59 JST