michaelsbradleyjr

   "devDependencies" : {
     "test-run": ">=0.19.0",
     "connect": ">=1.6.0"
   },
   "scripts" : {
      "postinstall": "$SHELL __script/postinstall.sh",
      "test": "cd t/ && node ./index.js",
      "web-test": "node __script/test-run-server.js"
   }

michaelsbradleyjr

var connect = require('connect')

var server = connect.createServer()

server.use(connect.logger())
      .use(connect.favicon())
      .use('/jsan', connect.static(__dirname + '/../node_modules/.jsan'))
      .use('/', connect.directory(__dirname + '/..'), { icons : true })
      .use('/', connect.static(__dirname + '/..'))

michaelsbradleyjr

var connect = require('connect')

var server = connect.createServer()

server.use(connect.logger())
      .use(connect.favicon())
      .use('/jsan', connect.static(__dirname + '/../node_modules/.jsan'))
      .use('/', connect.directory(__dirname + '/..'), { icons : true })
      .use('/', connect.static(__dirname + '/..'))

michaelsbradleyjr

-> % npm ls
/home/michael/fixJsan/working
└─┬ joosex-meta-lazy-jsanfix@0.3.3 
  └── joose-jsanfix@3.19.0  invalid

michaelsbradleyjr

{
   "repository" : {
      "web" : "https://github.com/SamuraiJack/JooseX-Meta-Lazy",
      "url" : "https://github.com/SamuraiJack/JooseX-Meta-Lazy",
      "type" : "git"
   },
   "directories" : {
      "man" : "./man",
      "lib" : "./lib",
      "doc" : "./doc/mmd"

michaelsbradleyjr

Next-gen Joose

My goal is to outline some of my thoughts on how a next-gen Joose (e.g. Joose4) might be structured around AMD style modules and avoid use of global namespaces, for Joose itself and Classes, Roles, etc. that are defined with Joose.Class(), Joose.Role(), etc.

This is an outline only, and not an attempt to rigorously solve all of the technical problems faced in such a big shift in the design of the Joose object system.

AMD require, define are assumed to be implemented

As hinted at above, this outline will assume that runtime environment fully supports the AMD spec. For browsers, that means using an implementation like RequireJS. For node.js, that means creating some sort of "shim" so that modules defined with asynchronous loading in mind will work without modification and alongside synchronously loaded modules. RequireJS, for example, provides an r.js adapter for use with node.js, but at pres

michaelsbradleyjr

#!/bin/bash

#PODNAME: postinstall.sh

CURRENT_PKG_DIR=$(pwd)

NPM_ROOT=$(npm root 2>/dev/null)

ONE_UP_NPM_ROOT="$NPM_ROOT/../.."

michaelsbradleyjr

use Modern::Perl;
use Term::ANSIColor qw( :constants );
use IPC::Run3;
use Capture::Tiny qw( tee );

my @cmd = qw( node t/index.js  );

my ($stdout, $stderr) = tee {
        run3 \@cmd;
};

michaelsbradleyjr

var EventEmitter = require('events').EventEmitter

var continuation = new EventEmitter()

var i   = 1
var end = 1000

var doThisManyTimes = function () {
  someAsyncFacilityYoureUsing(arg1, arg2 ..., function callback() {
    continuation.emit('continue')

michaelsbradleyjr

## ----- classof.coffee ----- ##

_classof = (o) ->
  if o is null
    'Null'
  else if o is undefined
    'Undefined'
  else
    Object.prototype.toString.call(o).slice(8,-1)