text:
RFC: Avoid HTTPApplication for CLI

HTTPApplication is a system for processing URLs in a webserver environment.
In a CLI context, it only introduces distractions.
For CLI requests, we should generate a CoreKernel object but handle BuildTasks and database building without using SilverStripe/Control. This would probably be a good time to create it as a Symfony console tool, perhaps incorporating one of the existing tools in this space as opposed to reinventing the wheel.
A special "run URL" option could be used for those cases when do do actually want a URL, but it should be the exception rather than the rule.
I'd recommend this as a 4.1 change that preserves the existing behaviour as deprecated.
Note that the implication of this is that no HTTPMiddlewares would ever get run in CLI mode, which simplifies things such as #7492.

Could it even be a separate tool, silverstripe/console perhaps?

Note that the implication of this is that no HTTPMiddlewares would ever get run in CLI mode, which simplifies things such as #7492.

This sounds about right to me!

One thing to consider is what "simulated web-requests" would do. One example I can think of is rendering the error page template into assets/error-404.html. Perhaps we just don't do that anymore, thus eliminating that need?

One thing to consider is what "simulated web-requests" would do. One example I can think of is rendering the error page template into assets/error-404.html. Perhaps we just don't do that anymore, thus eliminating that need?

It's a good question, I'd probably leave it separate from this issue. I think we need to look at how middlewares are typically used before deciding whether they should be included in the default render of a staticpublisher page or a 404 error page. My guess is that it's better to exclude them by default, as they are typically used to handle log-in, session, redirection, flush, header mangling, request blocking, none of which apply in such a case.
The error page generator and staticpublisher could probably have an extension hook where middlewares specific to those use cases could be attached, which by default would be empty.

This is rearing its ugly head again in a new use case: We want to generate the GraphQL schema during release packaging, which often happens in environments separate from the actual webserver (e.g. AWS CodeBuild or CircleCI). This happens through sake, but that kicks off all kinds of wrong assumptions about the state of the environment: Validate database credentials, execute middleware that relies on database queries, trigger HTTPOutputHandler to show errors. Its a good test case for our kernel architecture, but a bit of a rabbit hole.

Closing as this will be done as part of https://github.com/silverstripe/silverstripe-framework/issues/11341
The new sake will by default not use HTTPApplication nor HTTPRequest, though there is a sake navigate command that will essentially do what old sake did, for those who have a need to do that for whatever dark magic they're doing.

authors: GuySartorelli chillu sminnee tractorcow


text:
FIX: Prevent repeated lookup of obj.dependencies by Injector

This unnecessary repeated call to Injector slows down the construction
of frequently instantiated classes.
On admin/pages, this reduced execution from 1.67s to 1.56s, and it
reduced the impact of having an extension added to DBField by 33%
(from 100ms to 67ms)

Looks good to me!

Parent issue https://github.com/silverstripe/silverstripe-admin/issues/199

I've pushed up a linting fix. Will merge once it's green.

source: gharchive/pull-request

authors: sminnee tractorcow

repo: silverstripe/silverstripe-framework

license_type: permissive

license_source: github-api


text:
Update 03_Authentication.md

The value of SS_DEFAULT_ADMIN_USERNAME is registered in "Member->Email", so why is it called "SS_DEFAULT_ADMIN_USERNAME"?
I propose to name it to SS_DEFAULT_ADMIN_EMAIL for the default "unique_identifier_field" ('Email') and then we'll support different "unique_identifier_field" (like "Username" or other).

See https://github.com/silverstripe/silverstripe-framework/pull/9475#issuecomment-617104768

authors: alessandromarotta kinglozzer


text:
Remove cythonized files

Remove file
Update requirement.txt for continuous integration
python setup.py clean while also remove cythonized files

does sdist generate the C-files ?

No, but i can try.
I think i will try something like: python setup.py sdist --cythonized, instead of only sdist.

BTW there is a pbm with the qhull compilation here.

I think we should add cython to setup_requires in the setup.py... eventually except for sdist if the C files are embedded...

I'm checking for QHull, looks like an issue with different version of cython.

PR #1776 is fixing the qhull issue...

looks great to me.

authors: kif t20100 vallsv

repo: silx-kit/silx

license: MIT


text:
silx.gui: Check Qt/pyopengl platform compatibility; silx view/compare: Use matplotlib if OpenGL is not available

This PR updates isOpenGLAvailable to check the compatibility between Qt and pyopengl selected platforms.
It also updates silx view and silx compare to fallback on matplotlib if OpenGL is selected but not available.
closes #3630

I am not sure about your change with options.use_opengl_plot.
If you want to use opengl and it is not available, i prefer it to fail.
You still can remove if from the command line.

I reverted changes in silx compare and now silx view --use-opengl-plot forces OpenGL, but I left the matplotlib fallback when OpenGL is set in the settings.


text:
Pull version from pom.xml instead of hardcoding it.

What the title says. This fixes the version in the target jar's name (previously 1.0-SNAPSHOT) and also makes it easier to bump versions. Also added some things to pom.xml.

Implemented a similar thing to yours, thank you


text:
Support for nested checks

Hi, it looks like the current version doesn't support nested checks.
If tests are in form of
describe( .....
       describe(......
               describe(......
                       expect(........

only the outer case will be taken into account as a test suite, and since there are no checks directly in it, it will be ignored, generating empty file (with only the root test suite.
It's not trivial to add it, but it's also not super hard. Do you plan to do it?

Issue addressed in PR: https://github.com/simbadltd/k6-junit/pull/11

Hi, I haven't thought about it. Since, I didn't see the actual code written with this paradigm utilizing nested groups feature. So, how about having it in a more generic way: just parse groups recurcively allowing any nesting level?
I'm curious if the following output xml will work for your case?:
    <?xml version=\"1.0\"?>
    <testsuites tests=\"6\" failures=\"3\">
      <testsuite id=\"0\" name=\"First Test Suite: Required fields\" tests=\"2\" failures=\"0\">
        <testcase name=\"expected response status to equal 204\" classname=\"First Test Suite: Required fields\" />
        <testcase name=\"expected response to be truthy\" classname=\"First Test Suite: Required fields\" />
      </testsuite>
      <testsuite id=\"1\" name=\"First Test Suite: Required and optional fields\" tests=\"1\" failures=\"0\">
        <testcase name=\"expected response status to equal 204\" classname=\"First Test Suite: Required and optional fields\" />
      </testsuite>
      <testsuite id=\"2\" name=\"Second Test Suite: Manage User\" tests=\"1\" failures=\"1\">
        <testcase name=\"expected Create instance response status to equal 201\" classname=\"Second Test Suite: Manage User\" >
          <failure message=\"0 / 1 (0.00%) checks passed\">0 / 1 (0.00%) checks passed</failure>
        </testcase>
      </testsuite>
      <testsuite id=\"3\" name=\"Second Test Suite: Manage Group\" tests=\"1\" failures=\"1\">
        <testcase name=\"expected Create tenant response status to equal 201\" classname=\"Second Test Suite: Manage Group\" >
          <failure message=\"0 / 1 (0.00%) checks passed\">0 / 1 (0.00%) checks passed</failure>
        </testcase>
      </testsuite>
      <testsuite id=\"4\" name=\"Thresholds\" tests=\"1\" failures=\"1\">
        <testcase name=\"checks: rate == 1.00\" classname=\"Thresholds\" >
          <failure message=\"threshold exceeded\">threshold exceeded</failure>
        </testcase>
      </testsuite>
    </testsuites>

Hi, I haven't thought about it. Since, I didn't see the actual code written with this paradigm utilizing nested groups feature. So, how about having it in a more generic way: just parse groups recurcively allowing any nesting level?
I'm curious if the following output xml will work for your case?:
    <?xml version=\"1.0\"?>
    <testsuites tests=\"6\" failures=\"3\">
      <testsuite id=\"0\" name=\"First Test Suite: Required fields\" tests=\"2\" failures=\"0\">
        <testcase name=\"expected response status to equal 204\" classname=\"First Test Suite: Required fields\" />
        <testcase name=\"expected response to be truthy\" classname=\"First Test Suite: Required fields\" />
      </testsuite>
      <testsuite id=\"1\" name=\"First Test Suite: Required and optional fields\" tests=\"1\" failures=\"0\">
        <testcase name=\"expected response status to equal 204\" classname=\"First Test Suite: Required and optional fields\" />
      </testsuite>
      <testsuite id=\"2\" name=\"Second Test Suite: Manage User\" tests=\"1\" failures=\"1\">
        <testcase name=\"expected Create instance response status to equal 201\" classname=\"Second Test Suite: Manage User\" >
          <failure message=\"0 / 1 (0.00%) checks passed\">0 / 1 (0.00%) checks passed</failure>
        </testcase>
      </testsuite>
      <testsuite id=\"3\" name=\"Second Test Suite: Manage Group\" tests=\"1\" failures=\"1\">
        <testcase name=\"expected Create tenant response status to equal 201\" classname=\"Second Test Suite: Manage Group\" >
          <failure message=\"0 / 1 (0.00%) checks passed\">0 / 1 (0.00%) checks passed</failure>
        </testcase>
      </testsuite>
      <testsuite id=\"4\" name=\"Thresholds\" tests=\"1\" failures=\"1\">
        <testcase name=\"checks: rate == 1.00\" classname=\"Thresholds\" >
          <failure message=\"threshold exceeded\">threshold exceeded</failure>
        </testcase>
      </testsuite>
    </testsuites>

That was my first idea actually, but then if you use it for CI/CD for example, which I believe is a pretty common case you end up with reporting of dozens of test suites, each of them having 1, 2, maybe 5 tests each. This is not very helpful.
I can imagine having a breakdown at one more level level deeper could be interesting for huge projects, but would be counterproductive for small, so probably the best alternative would be to parametrize it. We could pass current level in recursion and compare with the max-depth value

@mikocot  Great idea! I've added maxGroupNestingLevel config for that, so to fit your case you need to set it up to 2. Your case also has been included as a test here: _issue.10.spec.jsx.
Thanks for highlighting this and Happy coding!

Cool, thanks for adding it. I just don't understand why you couldn't do it on top of my PR, instead of copying the code directly into main.
Anyway, do you plan to release this versino to npm? It still has 1.0.3 as the latest.

Done, now you should see yourself as a contributor. New version has been already published. Latest version: 1.1.2. Enjoy your day and happy coding!

source: gharchive/issue

authors: mikocot simbadltd


text:
Allow hot reload of inventory in inventory watch

I consider this a bug.

This is fixed part in #33

repo: simbleau/cddns


text:
Добавить кнопку для возвращения на главную перед и после статьи и новости

Перед текстом (новостью или статьей) добавить 2 кнопки обе должны вести на главную, но на одной надпись "Это интересно, что тут есть ещё?", на другой "Это не то, что я искал, попробую снова".

Сразу не написал, нужно считать куда нажмёт пользователь для каждой статьи

Сделал

license: mit

license_source: bigquery


text:
insertOnConflictUpdate fires an 'UpdateKind.insert' during conflict/update

When calling 'insertOnConflictUpdate' that triggers a conflict and hence branches to perform an UPDATE, the code fires an 'insert' event.
Should probably fire an 'update' so UI knows to update existing records rather than perform a reload/insertion...
insert.dart
  Future<int> insert(
    Insertable<D> entity, {
    InsertMode? mode,
    UpsertClause<T, D>? onConflict,
  }) async {
    final ctx = createContext(entity, mode ?? InsertMode.insert,
        onConflict: onConflict);

    return await database.doWhenOpened((e) async {
      final id = await e.runInsert(ctx.sql, ctx.boundVariables);
      database
          .notifyUpdates({TableUpdate.onTable(table, kind: UpdateKind.insert)});
      return id;
    });
  }

The idea of the UpdateKind enum is  to properly consider triggers added to the database when considering which streams need updating. E.g. we when there's a trigger AFTER UPDATE ON foo BEGIN INSERT INTO bar ... END, we know that updates on foo also invalidate streams listening on bar.
There's no way for us to know whether an upsert ran an insert or an update since that decision happens in the database engine and not in Dart. The general statement we're running is an insert, and that's what we're reporting.

so UI knows to update existing records rather than perform a reload/insertion...

That's not really an accurate way to check for new records. The UI should react to changes of the current snapshot (by comparing the rows with the previous snapshot if necessary).
I'll document the limitation, but I don't think we should try to infer the update kind for upserts.

Thanks @simolus3,
That makes sense.
How I came about that conclusion (which may be incorrect), is I was calling 'insertOnConflictUpdate', which internally looks like this:
Future<int> insertOnConflictUpdate(Insertable<D> entity) {
    return insert(entity, onConflict: DoUpdate((_) => entity));
}

So it looked like it was an explicit decision happening in application code, to respond to a failed insert, with an update....
  Future<int> insert(
    Insertable<D> entity, {
    InsertMode? mode,
    UpsertClause<T, D>? onConflict,
  }) async {
    final ctx = createContext(entity, mode ?? InsertMode.insert,
        onConflict: onConflict);

    return await database.doWhenOpened((e) async {
      final id = await e.runInsert(ctx.sql, ctx.boundVariables);
      database
          .notifyUpdates({TableUpdate.onTable(table, kind: UpdateKind.insert)});
      return id;
    });
  }

But I guess, as you've explained, there is more going on there - perhaps other code paths to get to that point.
Thanks!


text:
Patch 1

This will enable the handling of .pyd files.

Hi, @CSchulzeTLK
Thx a lot for sending pull request!
I've merged and released v0.1.7
Please update with the following:
$ pip install stubdoc==0.1.7

authors: CSchulzeTLK simon-ritchie

repo: simon-ritchie/stubdoc


text:
🛑 Snow Boards NZ is down

In bbe3468, Snow Boards NZ (https://$SZ_SITE1/) was down:

HTTP code: 503
Response time: 1079 ms

Resolved: Snow Boards NZ is back up in 04cc7d1 after 5 minutes.


text:
WIP: Suggestions for executors

This is a PR with some suggestions for some executors to improve firebase's cli within nx. I have these changes currently as a workspace plugin that I have been playing around with and noticed a few issues pop-up which I think these executors help to fix ( #92 and #40 ). I have copied the local plugin into these repo quickly to gauge interest in including these in this plugin.
There are 3 executors:

cli: the way to interact with the firebase cli-tool - has been written to be similar to the firebase-tools when using in the terminal but with some tweaks to improve how it can be used in the project.json

kill-emulator: kills all the process running on the ports defined in the defined firebase.*.json

copy-local-files: used for handling .gitignored env files, namely .env.local and .secret.local

My project stucture is:
apps/
> example/
>> functions/
>> app/
>> firebase/

The project.json I have in the functions folder is
{
  "name": "example-functions",
  "$schema": "../../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/example/functions/src",
  "projectType": "application",
  "targets": {
    "build": {
      "executor": "@nx/esbuild:esbuild",
      "outputs": ["{options.outputPath}"],
      "options": {
        "project": "apps/example/functions/package.json",
        "outputPath": "dist/apps/example/functions",
        "main": "apps/example/functions/src/index.ts",
        "tsConfig": "apps/example/functions/tsconfig.app.json",
        "assets": ["apps/example/functions/.env.*"],
        "bundle": true,
        "minify": true,
        "generatePackageJson": true,
        "platform": "node",
        "esbuildOptions": {
          "splitting": true
        }
      },
      "configurations": {
        "watch": {
          "watch": true,
          "minify": false
        }
      }
    },
    "lint": {
      "executor": "@nx/linter:eslint",
      "options": {
        "lintFilePatterns": ["apps/example/functions/**/*.ts"]
      },
      "outputs": ["{options.outputFile}"]
    },
    "test": {
      "executor": "@nx/jest:jest",
      "outputs": ["{workspaceRoot}/coverage/apps/example/functions"],
      "options": {
        "jestConfig": "apps/example/functions/jest.config.ts",
        "passWithNoTests": true
      }
    },
    "copy-local-files": {
      "executor": "@workspace-plugin/firebase:copy-local-files",
      "inputs": ["{projectRoot}/.(secret|env).local"]
    }
  },
  "tags": []
}

and the project json I have for the firebase folder is:
{
  "name": "example-firebase",
  "$schema": "../../../node_modules/nx/schemas/project-schema.json",
  "projectType": "application",
  "targets": {
    "cli": {
      "executor": "@workspace-plugin/firebase:cli",
      "options": {
        "config": "firebase.example.json"
      }
    },
    "deploy": {
      "executor": "@workspace-plugin/firebase:cli",
      "options": {
        "command": "deploy",
        "config": "firebase.example.json",
        "non-interactive": true,
        "force": true
      },
      "dependsOn": [
        { "projects": ["example-functions"], "target": "build" }
      ],
      "configurations": {
        "dev": {
          "project": "example-dev"
        },
        "prd": {
          "project": "example-prd"
        }
      }
    },
    "emulators:start": {
      "executor": "@workspace-plugin/firebase:cli",
      "dependsOn": [
        { "projects": ["example-functions"], "target": "build" },
        {
          "projects": ["example-functions"],
          "target": "copy-local-files"
        }
      ],
      "options": {
        "command": "emulators:start",
        "config": "firebase.example.json"
      },
      "configurations": {
        "dev": {
          "project": "example-dev"
        },
        "prd": {
          "project": "example-prd"
        }
      }
    },
    "emulators:exec": {
      "executor": "@workspace-plugin/firebase:cli",
      "dependsOn": [
        { "projects": ["example-functions"], "target": "build" },
        {
          "projects": ["example-functions"],
          "target": "copy-local-files"
        }
      ],
      "options": {
        "command": "emulators:exec",
        "config": "firebase.example.json"
      },
      "configurations": {
        "dev": {
          "project": "example-dev"
        },
        "prd": {
          "project": "example-prd"
        }
      }
    },
    "emulators:web": {
      "executor": "@workspace-plugin/firebase:cli",
      "dependsOn": [
        { "projects": ["example-functions"], "target": "build" },
        {
          "projects": ["example-functions"],
          "target": "copy-local-files"
        }
      ],
      "options": {
        "command": "emulators:exec",
        "config": "firebase.example.json"
      },
      "configurations": {
        "dev": {
          "project": "example-dev",
          "_": ["npx nx run example-app:serve:dev"]
        },
        "prd": {
          "project": "example-prd",
          "_": ["npx nx run example-app:serve:prd"]
        }
      }
    },
    "serve": {
      "executor": "nx:run-commands",
      "options": {
        "commands": [
          "npx nx run example-functions:build:watch",
          "npx nx run example-firebase:emulators:start"
        ],
        "parallel": true
      },
      "configurations": {
        "dev": {
          "commands": [
            "npx nx run example-functions:build:watch",
            "npx nx run example-firebase:emulators:start:dev"
          ]
        },
        "prd": {
          "commands": [
            "npx nx run example-functions:build:watch",
            "npx nx run example-firebase:emulators:start:prd"
          ]
        },
        "dev:web": {
          "commands": [
            "npx nx run example-functions:build:watch",
            "npx nx run example-firebase:emulators:web:dev"
          ]
        },
        "prd:web": {
          "commands": [
            "npx nx run example-functions:build:watch",
            "npx nx run example-firebase:emulators:web:pre"
          ]
        }
      }
    },
    "emulators:kill": {
      "executor": "@workspace-plugin/firebase:kill-emulator",
      "options": {
        "config": "firebase.example.json"
      }
    }
  },
  "tags": [],
  "implicitDependencies": ["example-app", "example-functions"]
}

I have shared these jsons just to demonstrate how I am using the executors in the pr.
Again, this is just what I have found to be useful so far and am still working through a few things:

As soon as you use "run-commands" the interactivity breaks so selecting options for the command runs breaks and killing the emulators is no longer clean - this is demonstrated in the serve command (but this is the only way I have got the build:watch to work)
My pubsub emulators never seem to get a clean shutdown
I don't currently have a good way of connecting the frontend to the emulators based on if the emulators are running (I think this is a limitation of the firebase cli so don't know if it should be addressed here)

Let me know what you think

Hi, thanks for your PR. It's great to have submissions & experiementations, and I can see how such solutions might be useful for customising a specific workflow/workspace, but for a generic plugin like this one, I'm not sure it adds value over what we already have:

There is already a firebase target in v2 plugin app generator, which provides much of the functionality of your cli executor, so you can already just run npx nx my-project:firebase <firebase cli options>
There is also already killports target that forcefully cleans up the emulator processes
We are still stuck with the problem of Nx not passing termination signals properly to child processes so that cleanup is correct. Personally I believe this needs to be fixed in Nx. As you have found, even having a custom executor doesnt get around that fundamental task runner problem with Nx.

The copy-local-files executor you have is an interesting workaround, but I believe we can achieve the same outcome by modifying the .nxignore files with exclusion rules and add local secret files to the build executor assets array - I just havent had time to investigate this better.
For your custom NX_REACT_APP_STORAGE_EMULATOR type env vars, I can see why you took that approach. For me, I have added an environment.dev.ts file to my FE project (Angular in my case), and set the appropriate emulator client app vars from that. eg.
  providers: [
    {
      provide: AUTH_EMULATOR,
      useValue: environment.localEmulation ? ['http://localhost:9099'] : undefined,
    },
    {
      provide: FIRESTORE_EMULATOR,
      useValue: environment.localEmulation ? ['localhost', 8080] : undefined,
    },
    {
      provide: DATABASE_EMULATOR, // i.e., Realtime Database
      useValue: environment.localEmulation ? ['localhost', 9000] : undefined,
    },
    {
      provide: FUNCTIONS_EMULATOR,
      useValue: environment.localEmulation ? ['http://localhost', 5001] : undefined,
    },
  ],

I'm going to close this PR for now, but I welcome & will review future contributions.

repo: simondotm/nx-firebase


text:
How to use the go library ?

Hello,
I'm trying to use the s4 go library to encrypt and decrypt bytes.
But when using import "github.com/simonfrey/s4" as written in the README, I get a strange error :

go: finding github.com/simonfrey/s4 latest
go: downloading github.com/simonfrey/s4 v0.0.0-20210502093622-aa95753ec8f6
go: extracting github.com/simonfrey/s4 v0.0.0-20210502093622-aa95753ec8f6
go: test imports
github.com/simonfrey/s4: github.com/simonfrey/s4@v0.0.0-20210502093622-aa95753ec8f6: parsing go.mod:
module declares its path as: s4
but was required as: github.com/simonfrey/s4

I've tried the rewrite directive in my go.mod but it's only making things worse. How to correctly import this library ?
Thanks !

OK, I've managed to get it working with a golang mod replace statement. Sharing the solution here :slightly_smiling_face:
My go main file :
package main

import (
	"s4"
        "encoding/base64"
)

My go.mod file :
module github.com/xxx/yyy/v2

go 1.16

replace s4 => github.com/simonfrey/s4 v0.0.0-20210502093622-aa95753ec8f6

require s4 v0.0.0-00010101000000-000000000000

NB : you can replace v0.0.0-20210502093622-aa95753ec8f6 by latest and run go mod tidy.

I tagged the current master with v1.0 to make it work out of the box.
Could you please try if that fixed it. You should not need the replace anymore.

Hi,
I don't think it's related to a tag missing. It's nice though.
Here's a test main.go :
package main

import (
	"github.com/simonfrey/s4"
)

And a related go.mod :
module github.com/xxx/yyy/v2

go 1.16

require github.com/simonfrey/s4 latest

I still got the error :
go: github.com/simonfrey/s4@v0.0.0-20210502093622-aa95753ec8f6: parsing go.mod:
	module declares its path as: s4
	        but was required as: github.com/simonfrey/s4

I think it's related to the fact that module in s4/go.mod  is s4 and not github.com/simonfrey/s4.
This may not be all, I'm not completely sure. :slightly_smiling_face:

Nice catch. Should be fixed with: https://github.com/simonfrey/s4/commit/295f9713af70d434641fa8b3f8615099caffe120

Tested on my repo, I think this PR shoudl fix this for good !
I was getting this error without this :
../go/pkg/mod/github.com/simonfrey/s4@v0.0.0-20210726193420-57fa43c35b94/s4.go:7:2: package s4/crypto is not in GOROOT (/usr/lib/go-1.17/src/s4/crypto)

Works fine now 🙌


text:
I am not able to link resource with csv Import functionality

Hello Simon,
Good evening!
Please find the attachment for the image of page I am receiving after adding the component to tools.
Please it will be a great help to me if You could help in proceeding further in the same.
Thank you

This is an exception I am receiving.
[2019-05-30 12:40:42] production.ERROR: md5_file(): Filename cannot be empty {"userId":"230fbff0-5439-11e9-ab34-69ce6f383d7d","email":"admin@test.com","exception":"[object] (ErrorException(code: 0): md5_file(): Filename cannot be empty at D:\xampp\htdocs\laravel-crm\vendor\laravel\framework\src\Illuminate\Filesystem\Filesystem.php:109)

$file->getRealPath()
this method is returning empty

It looks like there's a bug here on Windows / XAMPP in the Filesystem library and seems like it's not specifically related to this package. Unfortunately I don't use either of those so it's going to be a little tricky for me to debug.
I'm going to close this issue, as I suspect you may face this issue elsewhere if you were to use the Illuminate\Support\Facades\File::hash() method, which would highlight a problem with your local development setup.
If anyone else can provide any insight, please feel free to assist.

authors: simonhamp softsnare

repo: simonhamp/laravel-nova-csv-import


text:
Remove user-specific values from .gitignore

This PR removes user-specific values from the .gitignore file. They should be configured per-machine in a global ~/.gitignore file. This ensures the project's .gitignore file only deals with files relevant to the project.
As Sebastian puts it:

My repository doesn't care about your editor configuration.

I agree with the sentiment, but these files are so common that it makes sense to share them. And even where they're not relevant, we're talking about a few lines in a text file... this isn't breaking the bank

authors: simonhamp svenluijten

repo: simonhamp/the-og


text:
Simple tasking program runs out of Mach Ports and crashes on macOS

I am trying to write a parallel, tasking version of a computationally expensive algorithm. I aim to do this
by introducing 3 tasks within a block statement that appears
in a procedure body.
On macOS, the program runs but crashes (killed with SIGKILL from the OS) because it seems to exhaust the OS's supply of
"Ports" - which are some kind of IPC resource used in the Mach/Darwin kernel. It runs fine on Intel/Linux.
Running that on Intel/macOS (Sonoma 14.0) with GNAT 13.1.0 yields:
RodPro2:tests rchapman$ ./tt
Killed: 9
I get the same results on Apple M1 Pro with macOS Ventura 13.5.2 and GNAT 13.1.0.
I attach a screenshot of the "top" utility running. You can see the "#PORTS" column has reached 221557. I think the OS kills the process at 262144 ports (2**18).
So.. some sort of resource leak in the runtime-library perhaps?
Here's the code:
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces;  use Interfaces;
procedure TT
is

   A, B, C : Unsigned_32 := 0;

   D : Unsigned_32;

   procedure P
   is
   begin
      declare
         task CA;
         task CB;
         task CC;

         task body CA is
         begin
            A := A + 1;
         end CA;

         task body CB is
         begin
            B := B + 1;
         end CB;

         task body CC is
         begin
            C := C + 1;
         end CC;
      begin
         null;
      end;

      D := (A + B + C) / 5;
   end P;

begin

   for I in 1 .. 1_000_000 loop
      P;
   end loop;
   Put_Line (D'Img);
end TT;

It turns out that 80,000 loops is OK, 90,000 fails. That’s 240,000 .. 270,000 tasks; cf 262144 ports.
I vaguely remember back in the day that we had an issue where aborting and the deallocating an allocated task wasn’t actually freeing the memory, because there were other resources involved - we worked round it by adding the task to a queue with a low-priority loop checked for a queue entry being actually terminated before deallocating.
I think AdaCore eventually implemented a solution, which would clearly involve hanging on to task-associated resources until ... whenever.
I found this link about Mach ports.
Also this posting about Paraffin - might suffer from the same problem, ofc

AdaCore said "No official support for macOS", so don't expect any help there...
Clearly something in the RTL or underlying pthreads libraries is allocating a Port for each task, but it's not getting de-allocated on task termination. Finding that is going to be tricky...

Where are the runtime library sources for macOS? I guess I'm looking for the bit that does task creation and termination in terms of pthreads...

Found 'em... in gcc/ada/libgnarl/ right?

Found 'em... in gcc/ada/libgnarl/ right?

Yes!
To get an idea of what’s used how, you can e.g. gnatmake tt.adb -c -u -f -gnatG -- it spits out an approximation of what the high-level translator has made of the source, and you can usually see where the RTS calls are made

I had another look at this: if you include delay System.Tick; in the loop, the number of ports remains under 20,000. But of course the whole thing runs painfully slowly.

Hmmm... any idea what the call to System.Tick is actually doing under the hood?

System.Tick is a named constant (0.01 [seconds] here).
My suspicion is that AdaCore have a low-priority task (or task-alike) which sweeps for unreferenced (& terminated) tasks and actually cleans them up, including releasing ports.

authors: rod-chapman simonjwright

repo: simonjwright/distributing-gcc


text:
Redis options as connect

Simon,
I tried using the default configuration with Azure Redis Cache and I identified that without passing some aditional arguments to redis, straw couldn't work.
I would appreciate if you accept my PR because i'm using your project into a big solution in my company.
Regards,
Líverton Oliveira.

Awesome. Thanks for the PR.

Would love to know some details on how you're using Straw.

Simon,
We are building a solution like stamplay, zapier, ifttt ... to connect softwares that people could save time if they had a solution like ours.Straw helps us a lot because we designed a topology to resolve our integrations. This topology still gets weekly updates as we discover new possibilities of integrations.
Do you know if after merging my pull request, npm will recognize it and serve latest version ?
Regards,
Líverton Oliveira.
Date: Sat, 23 Jul 2016 17:44:57 -0700
From: notifications@github.com
To: straw@noreply.github.com
CC: lifelipe7@live.com; author@noreply.github.com
Subject: Re: [simonswain/straw] Redis options as connect (#9)
Would love to know some details on how you're using Straw.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Looks like something in the tests is broken. I'm investigating.
I will also upgrade it to use a more recent version of Node (>=5.11) will this cause you any issues?

I tested "grunt test" here and it's all working .I think that node upgrade won't be a problem, we also use >= 5
Regards,Líverton Oliveira.Date: Sat, 23 Jul 2016 19:48:43 -0700
From: notifications@github.com
To: straw@noreply.github.com
CC: lifelipe7@live.com; author@noreply.github.com
Subject: Re: [simonswain/straw] Redis options as connect (#9)
Looks like something in the tests is broken. I'm investigating.
I will also upgrade it to use a more recent version of Node (>=5.11) will this cause you any issues?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Looks like passing through the opts to Redis also passes prefix which I think node-redis has started using. I've tweaked it to only send through the host and port. Can you please have a play with #aa27c6c (make sure you update modules too) and I'll push this out as v0.4.0 on NPM. Thanks!

It seems that I can only connect if send a password . Is it okay to merge another lines of code ? I tested here and password is optional but for Azure i really need this.

repo: simonswain/straw


text:
Mechanism for storing metadata in _metadata tables

Original title: Perhaps metadata should all live in a _metadata in-memory database
Inspired by #1150 - metadata should be exposed as an API, and for large Datasette instances that API may need to be paginated. So why not expose it through an in-memory database table?
One catch to this: plugins. #860 aims to add a plugin hook for metadata. But if the metadata comes from an in-memory table, how do the plugins interact with it?
The need to paginate over metadata does make a plugin hook that returns metadata for an individual table seem less wise, since we don't want to have to do 10,000 plugin hook invocations to show a list of all metadata.
If those plugins write directly to the in-memory table how can their contributions survive the server restarting?

Also: in #188 I proposed bundling metadata in the SQLite database itself alongside the data. This is a great way of ensuring metadata travels with the data when it is downloaded as a SQLite .db file. But how would that play with the idea of an in-memory _metadata table? Could that table perhaps offer views that join data across multiple attached physical databases?

Also: in #188 I proposed bundling metadata in the SQLite database itself alongside the data. This is a great way of ensuring metadata travels with the data when it is downloaded as a SQLite .db file. But how would that play with the idea of an in-memory _metadata table? Could that table perhaps offer views that join data across multiple attached physical databases?

A database that exposes metadata will have the same restriction as the new _internal database that exposes columns and tables, in that it needs to take permissions into account. A user should not be able to view metadata for tables that they are not able to see.
As such, I'd rather bundle any metadata tables into the existing _internal database so I don't have to solve that permissions problem in two places.

A database that exposes metadata will have the same restriction as the new _internal database that exposes columns and tables, in that it needs to take permissions into account. A user should not be able to view metadata for tables that they are not able to see.
As such, I'd rather bundle any metadata tables into the existing _internal database so I don't have to solve that permissions problem in two places.

What if metadata was stored in a JSON text column in the existing _internal tables? This would allow for users to invent additional metadata fields in the future beyond the current license, license_url etc fields - without needing a schema change.
The downside of JSON columns generally is that they're harder to run indexed queries against. For metadata I don't think that matters - even with 10,000 tables each with their own metadata a SQL query asking for e.g. "everything that has Apache 2 as the license" would return in just a few ms.

What if metadata was stored in a JSON text column in the existing _internal tables? This would allow for users to invent additional metadata fields in the future beyond the current license, license_url etc fields - without needing a schema change.
The downside of JSON columns generally is that they're harder to run indexed queries against. For metadata I don't think that matters - even with 10,000 tables each with their own metadata a SQL query asking for e.g. "everything that has Apache 2 as the license" would return in just a few ms.

So what if the databases, tables and columns tables in _internal each grew a new metadata text column?
These columns could be populated by Datasette on startup through reading the metadata.json file. But how would plugins interact with them?

So what if the databases, tables and columns tables in _internal each grew a new metadata text column?
These columns could be populated by Datasette on startup through reading the metadata.json file. But how would plugins interact with them?

So what if the databases, tables and columns tables in _internal each grew a new metadata text column?
These columns could be populated by Datasette on startup through reading the metadata.json file. But how would plugins interact with them?

So what if the databases, tables and columns tables in _internal each grew a new metadata text column?
These columns could be populated by Datasette on startup through reading the metadata.json file. But how would plugins interact with them?

One possibility: plugins could write directly to that in-memory database table. But how would they know to write again should the server restart? Maybe they would write to it once when called by the startup plugin hook, and then update it (and their own backing store) when metadata changes for some reason. Feels a bit messy though.
Also: if I want to support metadata optionally living in a _metadata table colocated with the data in a SQLite database file itself, how would that affect the metadata columns in _internal? How often would Datasette denormalize and copy data across from the on-disk _metadata tables to the _internal in-memory columns?

One possibility: plugins could write directly to that in-memory database table. But how would they know to write again should the server restart? Maybe they would write to it once when called by the startup plugin hook, and then update it (and their own backing store) when metadata changes for some reason. Feels a bit messy though.
Also: if I want to support metadata optionally living in a _metadata table colocated with the data in a SQLite database file itself, how would that affect the metadata columns in _internal? How often would Datasette denormalize and copy data across from the on-disk _metadata tables to the _internal in-memory columns?

Here are the requirements I'm currently trying to satisfy:

It should be possible to query the metadata for ALL attached tables in one place, potentially with pagination and filtering
Metadata should be able to exist in the current metadata.json file
It should also be possible to bundle metadata in a table in the SQLite database files themselves
Plugins should be able to define their own special mechanisms for metadata. This is particularly interesting for providing a UI that allows users to edit the metadata for their existing tables.

Here are the requirements I'm currently trying to satisfy:

It should be possible to query the metadata for ALL attached tables in one place, potentially with pagination and filtering
Metadata should be able to exist in the current metadata.json file
It should also be possible to bundle metadata in a table in the SQLite database files themselves
Plugins should be able to define their own special mechanisms for metadata. This is particularly interesting for providing a UI that allows users to edit the metadata for their existing tables.

The sticking point here seems to be the plugin hook. Allowing plugins to over-ride the way the question "give me the metadata for this database/table/column" is answered makes the database-backed metadata mechanisms much more complicated to think about.
What if plugins didn't get to over-ride metadata in this way, but could instead update the metadata in a persistent Datasette-managed storage mechanism?
Then maybe Datasette could do the following:

Maintain metadata in _internal that has been loaded from metadata.json
Know how to check a database for baked-in metadata (maybe in a _metadata table)
Know how to fall back on the _internal metadata if no baked-in metadata is available

If database files were optionally allowed to store metadata about tables that live in another database file this could perhaps solve the plugin needs - since an "edit metadata" plugin would be able to edit records in a separate, dedicated metadata.db database to store new information about tables in other files.

The sticking point here seems to be the plugin hook. Allowing plugins to over-ride the way the question "give me the metadata for this database/table/column" is answered makes the database-backed metadata mechanisms much more complicated to think about.
What if plugins didn't get to over-ride metadata in this way, but could instead update the metadata in a persistent Datasette-managed storage mechanism?
Then maybe Datasette could do the following:

Maintain metadata in _internal that has been loaded from metadata.json
Know how to check a database for baked-in metadata (maybe in a _metadata table)
Know how to fall back on the _internal metadata if no baked-in metadata is available

If database files were optionally allowed to store metadata about tables that live in another database file this could perhaps solve the plugin needs - since an "edit metadata" plugin would be able to edit records in a separate, dedicated metadata.db database to store new information about tables in other files.

Some SQLite databases include SQL comments in the schema definition which tell you what each column means:
CREATE TABLE User
        -- A table comment
(
        uid INTEGER,    -- A field comment
        flags INTEGER   -- Another field comment
);

The problem with these is that they're not exposed to SQLite in any mechanism other than parsing the CREATE TABLE statement from the sqlite_master table to extract those columns.
I had an idea to build a plugin that could return these. That would be easy with a "get metadata for this column" plugin hook - in the absence of one a plugin could still run that reads the schemas on startup and uses them to populate a metadata database table somewhere.

Some SQLite databases include SQL comments in the schema definition which tell you what each column means:
CREATE TABLE User
        -- A table comment
(
        uid INTEGER,    -- A field comment
        flags INTEGER   -- Another field comment
);

The problem with these is that they're not exposed to SQLite in any mechanism other than parsing the CREATE TABLE statement from the sqlite_master table to extract those columns.
I had an idea to build a plugin that could return these. That would be easy with a "get metadata for this column" plugin hook - in the absence of one a plugin could still run that reads the schemas on startup and uses them to populate a metadata database table somewhere.

The direction I'm leaning in now is the following:

Metadata always lives in SQLite tables
These tables can be co-located with the database they describe (same DB file)
... or they can be in a different DB file and reference the other database that they are describing
Metadata provided on startup in a metadata.json file is loaded into an in-memory metadata table using that same mechanism

Plugins that want to provide metadata can do so by populating a table. They could even maintain their own in-memory database for this, or they could write to the _internal in-memory database, or they could write to a table in a database on disk.

The direction I'm leaning in now is the following:

Metadata always lives in SQLite tables
These tables can be co-located with the database they describe (same DB file)
... or they can be in a different DB file and reference the other database that they are describing
Metadata provided on startup in a metadata.json file is loaded into an in-memory metadata table using that same mechanism

Plugins that want to provide metadata can do so by populating a table. They could even maintain their own in-memory database for this, or they could write to the _internal in-memory database, or they could write to a table in a database on disk.

So what would the database schema for this look like?
I'm leaning towards a single table called _metadata, because that's a neater fit for baking the metadata into the database file along with the data that it is describing. Alternatively I could have multiple tables sharing that prefix - _metadata_database and _metadata_tables and _metadata_columns perhaps.
If it's just a single _metadata table, the schema could look like this:

database
table
column
metadata

mytable

{"title": "My Table" }

mytable
mycolumn
{"description": "Column description" }

otherdb
othertable

{"description": "Table in another DB" }

If the database column is null it means "this is describing a table in the same database file as this _metadata table".
The alternative to the metadata JSON column would be separate columns for each potential metadata value - license, source, about, about_url etc. But that makes it harder for people to create custom metadata fields.

So what would the database schema for this look like?
I'm leaning towards a single table called _metadata, because that's a neater fit for baking the metadata into the database file along with the data that it is describing. Alternatively I could have multiple tables sharing that prefix - _metadata_database and _metadata_tables and _metadata_columns perhaps.
If it's just a single _metadata table, the schema could look like this:

database
table
column
metadata

mytable

{"title": "My Table" }

mytable
mycolumn
{"description": "Column description" }

otherdb
othertable

{"description": "Table in another DB" }

If the database column is null it means "this is describing a table in the same database file as this _metadata table".
The alternative to the metadata JSON column would be separate columns for each potential metadata value - license, source, about, about_url etc. But that makes it harder for people to create custom metadata fields.

Would this be a compound primary key on database, table, column? Does that work with null values?

Would this be a compound primary key on database, table, column? Does that work with null values?

Would also need to figure out the precedence rules:

What happens if the database has a _metadata table with data that conflicts with a remote metadata record from another database? I think the other database should win, because that allows plugins to over-ride the default metadata for something.
Do JSON values get merged together? So if one table provides a description and another provides a title do both values get returned?

Would also need to figure out the precedence rules:

What happens if the database has a _metadata table with data that conflicts with a remote metadata record from another database? I think the other database should win, because that allows plugins to over-ride the default metadata for something.
Do JSON values get merged together? So if one table provides a description and another provides a title do both values get returned?

From an implementation perspective, I think the way this works is SQL queries read the relevant metadata from ALL available metadata tables, then Python code solves the precedence rules to produce the final, combined metadata for a database/table/column.

From an implementation perspective, I think the way this works is SQL queries read the relevant metadata from ALL available metadata tables, then Python code solves the precedence rules to produce the final, combined metadata for a database/table/column.

Also: probably load column metadata as part of the table metadata rather than loading column metadata individually, since it's going to be rare to want the metadata for a single column rather than for an entire table full of columns.

Also: probably load column metadata as part of the table metadata rather than loading column metadata individually, since it's going to be rare to want the metadata for a single column rather than for an entire table full of columns.

Precedence idea:

First priority is non-_internal metadata from other databases - if those conflict then pick then the alphabetically-ordered-first database name wins
Next priority: _internal metadata, which should have been loaded from metadata.json
Last priority: the _metadata table from that database itself, i.e. the default "baked in" metadata

Precedence idea:

First priority is non-_internal metadata from other databases - if those conflict then pick then the alphabetically-ordered-first database name wins
Next priority: _internal metadata, which should have been loaded from metadata.json
Last priority: the _metadata table from that database itself, i.e. the default "baked in" metadata

I need to prototype this. Could I do that as a plugin? I think so - I could try out the algorithm for loading metadata and display it on pages using some custom templates.

I need to prototype this. Could I do that as a plugin? I think so - I could try out the algorithm for loading metadata and display it on pages using some custom templates.

One catch: solving the "show me all metadata for everything in this Datasette instance" problem.
Ideally there would be a SQLite table that can be queried for this. But the need to resolve the potentially complex set of precedence rules means that table would be difficult if not impossible to provide at run-time.
Ideally a denormalized table would be available that featured the results of running those precedence rule calculations. But how to handle keeping this up-to-date? It would need to be recalculated any time a _metadata table in any of the attached databases had an update.
This is a much larger problem - but one potential fix would be to use triggers to maintain a "version number" for the _metadata table - similar to SQLite's own built-in schema_version mechanism. Triggers could increment a counter any time a record in that table was added, deleted or updated.
Such a mechanism would have applications outside of just this _metadata system. The ability to attach a version number to any table and have it automatically incremented when that table changes (via triggers) could help with all kinds of other Datasette-at-scale problems, including things like cached table counts.

One catch: solving the "show me all metadata for everything in this Datasette instance" problem.
Ideally there would be a SQLite table that can be queried for this. But the need to resolve the potentially complex set of precedence rules means that table would be difficult if not impossible to provide at run-time.
Ideally a denormalized table would be available that featured the results of running those precedence rule calculations. But how to handle keeping this up-to-date? It would need to be recalculated any time a _metadata table in any of the attached databases had an update.
This is a much larger problem - but one potential fix would be to use triggers to maintain a "version number" for the _metadata table - similar to SQLite's own built-in schema_version mechanism. Triggers could increment a counter any time a record in that table was added, deleted or updated.
Such a mechanism would have applications outside of just this _metadata system. The ability to attach a version number to any table and have it automatically incremented when that table changes (via triggers) could help with all kinds of other Datasette-at-scale problems, including things like cached table counts.

Idea: version the metadata scheme. If the table is called _metadata_v1 it gives me a clear path to designing a new scheme in the future.

Idea: version the metadata scheme. If the table is called _metadata_v1 it gives me a clear path to designing a new scheme in the future.

Related: Here's an implementation of a get_metadata() plugin hook by @brandonrobertz next-LI@3fd8ce9

Here's a plugin that implements metadata-within-DBs: next-LI/datasette-live-config@72e335e887f1c69c54c6c2441e07148955b0fc9f
How it works: If a database has a __metadata table, then it gets parsed and included in the global metadata. It also implements a database-action hook with a UI for managing config.
More context: https://github.com/next-LI/datasette-live-config/blob/main/datasette_live_config/init.py#L109-L140

Datasette Cloud really wants this.

authors: brandonrobertz simonw

repo: simonw/datasette


text:
Unable to start the app on a clean install Cannot find module 'lodash/lang/isFunction'

Hi there,
As the title says, I'm unable to start the app ember serve after doing a "clean install"
npm cache clear && bower cache clean && trash node_modules bower_components && npm install && bower install

Here's my node & npm versions:
node -v
  v6.8.1
npm -v
  3.10.8

And, here's the output after running ember serve. Near the bottom the error Cannot find module 'lodash/lang/isFunction' appears.
ember-simple-auth [master] git pull && npm cache clear && bower cache clean && trash node_modules bower_components && npm install && bower install && ember s

bower deleted       Cached package ember-cli-shims: /Users/marc/.cache/bower/packages/edc1128f946163c8f20f02cc45477c5f/0.1.0
bower deleted       Cached package ember-cli-test-loader: /Users/marc/.cache/bower/packages/a755d6722c1e32820e24142cca883057/0.2.2
bower deleted       Cached package ember: /Users/marc/.cache/bower/packages/d36604908a147dd7bd71998ae02f2cc0/2.3.2
bower deleted       Cached package ember: /Users/marc/.cache/bower/packages/d36604908a147dd7bd71998ae02f2cc0/2.8.2
bower deleted       Cached package ember-qunit-notifications: /Users/marc/.cache/bower/packages/33f11d988133c551a72083ac4e63ce7b/0.1.0
bower deleted       Cached package qunit-notifications: /Users/marc/.cache/bower/packages/f8bbdcbbcd055141ec2aba7f019edc00/0.1.1
bower deleted       Cached package bootstrap-daterangepicker: /Users/marc/.cache/bower/packages/9089e7706f2e89aa3209d9ad80f61d1c/2.1.24
bower deleted       Cached package bootstrap: /Users/marc/.cache/bower/packages/478ab1d28ba78f550601bf536eea62f5/3.3.7
bower deleted       Cached package bootstrap-datepicker: /Users/marc/.cache/bower/packages/0b13b46afc85daad3aac8309cab7a9d6/1.6.4
bower deleted       Cached package jquery: /Users/marc/.cache/bower/packages/35300e45e44dbc6f186ed069533ef0af/2.1.4
bower deleted       Cached package jquery: /Users/marc/.cache/bower/packages/35300e45e44dbc6f186ed069533ef0af/3.1.1
bower deleted       Cached package moment: /Users/marc/.cache/bower/packages/bc513c8c04bcb090c1bc9c31b7ba3b0f/2.15.1
bower deleted       Cached package jquery: /Users/marc/.cache/bower/packages/35300e45e44dbc6f186ed069533ef0af/2.2.4
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated lodash-node@3.10.2: This package is discontinued. Use lodash@^4.0.0.
npm WARN deprecated minimatch@1.0.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated graceful-fs@1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN prefer global jsonlint@1.6.2 should be installed with -g
npm WARN prefer global npm@2.15.5 should be installed with -g
npm WARN prefer global jshint@2.9.3 should be installed with -g
npm WARN prefer global yuidocjs@0.9.0 should be installed with -g
ember-simple-auth@1.1.0 /Users/marc/Dev/github/clones/ember-simple-auth
├─┬ body-parser@1.15.2
│ ├── bytes@2.4.0
│ ├── content-type@1.0.2
│ ├─┬ debug@2.2.0
│ │ └── ms@0.7.1
│ ├── depd@1.1.0
│ ├─┬ http-errors@1.5.0
│ │ ├── inherits@2.0.1
│ │ ├── setprototypeof@1.0.1
│ │ └── statuses@1.3.0
│ ├── iconv-lite@0.4.13
│ ├─┬ on-finished@2.3.0
│ │ └── ee-first@1.1.1
│ ├── qs@6.2.0
│ ├─┬ raw-body@2.1.7
│ │ └── unpipe@1.0.0
│ └─┬ type-is@1.6.13
│   ├── media-typer@0.3.0
│   └─┬ mime-types@2.1.12
│     └── mime-db@1.24.0
├─┬ broccoli-asset-rev@2.5.0
│ ├── broccoli-asset-rewrite@1.1.0
│ ├─┬ broccoli-filter@1.2.4
│ │ ├── broccoli-kitchen-sink-helpers@0.3.1
│ │ ├── copy-dereference@1.0.0
│ │ └── walk-sync@0.3.1
│ ├─┬ json-stable-stringify@1.0.1
│ │ └── jsonify@0.0.0
│ ├─┬ matcher-collection@1.0.4
│ │ └── minimatch@3.0.3
│ └── rsvp@3.3.3
├─┬ broccoli-merge-trees@1.1.4
│ ├── broccoli-plugin@1.2.2
│ ├─┬ can-symlink@1.0.0
│ │ └── tmp@0.0.28
│ ├─┬ fast-ordered-set@1.0.3
│ │ └── blank-object@1.0.2
│ ├── fs-tree-diff@0.5.3
│ ├── heimdalljs@0.2.1
│ ├── heimdalljs-logger@0.1.7
│ ├─┬ rimraf@2.5.4
│ │ └─┬ glob@7.1.1
│ │   └── minimatch@3.0.3
│ └── symlink-or-copy@1.1.6
├─┬ broccoli-yuidoc@2.1.0
│ ├─┬ broccoli-caching-writer@2.0.4
│ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│ │ │ └── glob@5.0.15
│ │ ├── broccoli-plugin@1.1.0
│ │ ├── lodash-node@3.10.2
│ │ └── walk-sync@0.2.7
│ ├── broccoli-merge-trees@0.2.4
│ ├── merge@1.2.0
│ ├── rsvp@3.1.0
│ └─┬ yuidocjs@0.9.0
│   ├── graceful-fs@4.1.9
│   ├── markdown-it@4.4.0
│   ├── mdn-links@0.1.0
│   ├── minimatch@2.0.10
│   └── yui@3.18.1
├── ember-ajax@2.5.2
├─┬ ember-browserify@1.1.11
│ ├── acorn@2.7.0
│ ├─┬ broccoli-caching-writer@2.3.1
│ │ └── broccoli-plugin@1.1.0
│ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│ │ └── glob@5.0.15
│ ├─┬ browserify@13.1.0
│ │ ├── assert@1.3.0
│ │ ├─┬ browser-pack@6.0.1
│ │ │ ├─┬ combine-source-map@0.7.2
│ │ │ │ ├── convert-source-map@1.1.3
│ │ │ │ ├── inline-source-map@0.6.2
│ │ │ │ └── lodash.memoize@3.0.4
│ │ │ └── umd@3.0.1
│ │ ├── browser-resolve@1.11.2
│ │ ├─┬ browserify-zlib@0.1.4
│ │ │ └── pako@0.2.9
│ │ ├─┬ buffer@4.9.1
│ │ │ ├── base64-js@1.2.0
│ │ │ ├── ieee754@1.1.8
│ │ │ └── isarray@1.0.0
│ │ ├─┬ concat-stream@1.5.2
│ │ │ ├── readable-stream@2.0.6
│ │ │ └── typedarray@0.0.6
│ │ ├─┬ console-browserify@1.1.0
│ │ │ └── date-now@0.1.4
│ │ ├── constants-browserify@1.0.0
│ │ ├─┬ crypto-browserify@3.11.0
│ │ │ ├─┬ browserify-cipher@1.0.0
│ │ │ │ ├─┬ browserify-aes@1.0.6
│ │ │ │ │ └── buffer-xor@1.0.3
│ │ │ │ ├─┬ browserify-des@1.0.0
│ │ │ │ │ └─┬ des.js@1.0.0
│ │ │ │ │   └── minimalistic-assert@1.0.0
│ │ │ │ └── evp_bytestokey@1.0.0
│ │ │ ├─┬ browserify-sign@4.0.0
│ │ │ │ ├── bn.js@4.11.6
│ │ │ │ ├── browserify-rsa@4.0.1
│ │ │ │ ├─┬ elliptic@6.3.2
│ │ │ │ │ ├── brorand@1.0.6
│ │ │ │ │ └── hash.js@1.0.3
│ │ │ │ └─┬ parse-asn1@5.0.0
│ │ │ │   └── asn1.js@4.8.1
│ │ │ ├── create-ecdh@4.0.0
│ │ │ ├─┬ create-hash@1.1.2
│ │ │ │ ├── cipher-base@1.0.3
│ │ │ │ └── ripemd160@1.0.1
│ │ │ ├── create-hmac@1.1.4
│ │ │ ├─┬ diffie-hellman@5.0.2
│ │ │ │ └── miller-rabin@4.0.0
│ │ │ ├── pbkdf2@3.0.9
│ │ │ ├── public-encrypt@4.0.0
│ │ │ └── randombytes@2.0.3
│ │ ├── defined@1.0.0
│ │ ├── deps-sort@2.0.0
│ │ ├── domain-browser@1.1.7
│ │ ├── duplexer2@0.1.4
│ │ ├── events@1.1.1
│ │ ├── glob@5.0.15
│ │ ├─┬ has@1.0.1
│ │ │ └── function-bind@1.1.0
│ │ ├── htmlescape@1.1.1
│ │ ├── https-browserify@0.0.1
│ │ ├─┬ insert-module-globals@7.0.1
│ │ │ ├── is-buffer@1.1.4
│ │ │ └─┬ lexical-scope@1.2.0
│ │ │   └── astw@2.0.0
│ │ ├─┬ JSONStream@1.2.1
│ │ │ └── jsonparse@1.2.0
│ │ ├─┬ labeled-stream-splicer@2.0.0
│ │ │ ├── isarray@0.0.1
│ │ │ └── stream-splicer@2.0.0
│ │ ├─┬ module-deps@4.0.7
│ │ │ ├─┬ detective@4.3.1
│ │ │ │ └── acorn@1.2.2
│ │ │ └── stream-combiner2@1.1.1
│ │ ├── os-browserify@0.1.2
│ │ ├─┬ parents@1.0.1
│ │ │ └── path-platform@0.11.15
│ │ ├── path-browserify@0.0.0
│ │ ├── process@0.11.9
│ │ ├── punycode@1.4.1
│ │ ├── querystring-es3@0.2.1
│ │ ├── read-only-stream@2.0.0
│ │ ├─┬ readable-stream@2.1.5
│ │ │ ├── buffer-shims@1.0.0
│ │ │ ├── core-util-is@1.0.2
│ │ │ ├── process-nextick-args@1.0.7
│ │ │ └── util-deprecate@1.0.2
│ │ ├─┬ shasum@1.0.2
│ │ │ ├── json-stable-stringify@0.0.1
│ │ │ └── sha.js@2.4.5
│ │ ├─┬ shell-quote@1.6.1
│ │ │ ├── array-filter@0.0.1
│ │ │ ├── array-map@0.0.0
│ │ │ └── array-reduce@0.0.0
│ │ ├── stream-browserify@2.0.1
│ │ ├─┬ stream-http@2.4.0
│ │ │ ├── builtin-status-codes@2.0.0
│ │ │ └── to-arraybuffer@1.0.1
│ │ ├── string_decoder@0.10.31
│ │ ├── subarg@1.0.0
│ │ ├─┬ syntax-error@1.1.6
│ │ │ └── acorn@2.7.0
│ │ ├── timers-browserify@1.4.2
│ │ ├── tty-browserify@0.0.0
│ │ ├─┬ url@0.11.0
│ │ │ ├── punycode@1.3.2
│ │ │ └── querystring@0.2.0
│ │ ├─┬ util@0.10.3
│ │ │ └── inherits@2.0.1
│ │ ├─┬ vm-browserify@0.0.4
│ │ │ └── indexof@0.0.1
│ │ └── xtend@4.0.1
│ ├── core-object@1.1.0
│ ├─┬ derequire@2.0.3
│ │ ├── acorn@0.12.0
│ │ ├─┬ escope@2.0.7
│ │ │ ├─┬ es6-map@0.1.4
│ │ │ │ ├── d@0.1.1
│ │ │ │ ├── es5-ext@0.10.12
│ │ │ │ ├── es6-iterator@2.0.0
│ │ │ │ ├── es6-set@0.1.4
│ │ │ │ ├── es6-symbol@3.1.0
│ │ │ │ └── event-emitter@0.3.4
│ │ │ ├─┬ es6-weak-map@0.1.4
│ │ │ │ ├── es6-iterator@0.1.3
│ │ │ │ └── es6-symbol@2.0.1
│ │ │ ├── esrecurse@1.2.0
│ │ │ ├── estraverse@1.9.3
│ │ │ └── util-extend@1.0.3
│ │ └─┬ yargs@3.27.0
│ │   ├── camelcase@1.2.1
│ │   ├─┬ cliui@2.1.0
│ │   │ ├─┬ center-align@0.1.3
│ │   │ │ ├─┬ align-text@0.1.4
│ │   │ │ │ ├── longest@1.0.1
│ │   │ │ │ └── repeat-string@1.5.4
│ │   │ │ └── lazy-cache@1.0.4
│ │   │ └── right-align@0.1.3
│ │   ├── decamelize@1.2.0
│ │   ├─┬ os-locale@1.4.0
│ │   │ └─┬ lcid@1.0.0
│ │   │   └── invert-kv@1.0.0
│ │   ├── window-size@0.1.4
│ │   └── y18n@3.2.1
│ ├── ember-cli-version-checker@1.1.7
│ ├─┬ fs-tree@1.0.0
│ │ └── rimraf@2.2.8
│ ├─┬ md5-hex@1.3.0
│ │ └── md5-o-matic@0.1.1
│ ├─┬ mkdirp@0.5.1
│ │ └── minimist@0.0.8
│ ├── promise-map-series@0.2.3
│ ├─┬ quick-temp@0.1.6
│ │ ├── mktemp@0.4.0
│ │ ├── rimraf@2.2.8
│ │ └── underscore.string@2.3.3
│ ├─┬ through2@2.0.1
│ │ └── readable-stream@2.0.6
│ └─┬ walk-sync@0.2.7
│   └── ensure-posix-path@1.0.2
├─┬ ember-cli@2.7.0
│ ├── amd-name-resolver@0.0.5
│ ├── bower@1.7.9
│ ├─┬ bower-config@1.4.0
│ │ ├── mout@1.0.0
│ │ ├─┬ osenv@0.1.3
│ │ │ └── os-homedir@1.0.2
│ │ └── untildify@2.1.0
│ ├── bower-endpoint-parser@0.2.2
│ ├─┬ broccoli-babel-transpiler@5.6.1
│ │ ├─┬ babel-core@5.8.38
│ │ │ ├── babel-plugin-constant-folding@1.0.1
│ │ │ ├── babel-plugin-dead-code-elimination@1.0.2
│ │ │ ├── babel-plugin-eval@1.0.1
│ │ │ ├── babel-plugin-inline-environment-variables@1.0.1
│ │ │ ├── babel-plugin-jscript@1.0.4
│ │ │ ├── babel-plugin-member-expression-literals@1.0.1
│ │ │ ├── babel-plugin-property-literals@1.0.1
│ │ │ ├── babel-plugin-proto-to-assign@1.0.4
│ │ │ ├── babel-plugin-react-constant-elements@1.0.3
│ │ │ ├── babel-plugin-react-display-name@1.0.3
│ │ │ ├── babel-plugin-remove-console@1.0.1
│ │ │ ├── babel-plugin-remove-debugger@1.0.1
│ │ │ ├── babel-plugin-runtime@1.0.7
│ │ │ ├─┬ babel-plugin-undeclared-variables-check@1.0.2
│ │ │ │ └── leven@1.0.2
│ │ │ ├── babel-plugin-undefined-to-void@1.1.6
│ │ │ ├── babylon@5.8.38
│ │ │ ├── bluebird@2.11.0
│ │ │ ├── convert-source-map@1.3.0
│ │ │ ├── core-js@1.2.7
│ │ │ ├─┬ detect-indent@3.0.1
│ │ │ │ └── get-stdin@4.0.1
│ │ │ ├── esutils@2.0.2
│ │ │ ├── fs-readdir-recursive@0.1.2
│ │ │ ├── globals@6.4.1
│ │ │ ├─┬ home-or-tmp@1.0.0
│ │ │ │ └── user-home@1.1.1
│ │ │ ├─┬ is-integer@1.0.6
│ │ │ │ └── is-finite@1.0.2
│ │ │ ├── js-tokens@1.0.1
│ │ │ ├── json5@0.4.0
│ │ │ ├── output-file-sync@1.1.2
│ │ │ ├── path-exists@1.0.0
│ │ │ ├── private@0.1.6
│ │ │ ├─┬ regenerator@0.8.40
│ │ │ │ ├─┬ commoner@0.10.4
│ │ │ │ │ └── q@1.4.1
│ │ │ │ ├─┬ defs@1.1.1
│ │ │ │ │ ├─┬ alter@0.2.0
│ │ │ │ │ │ └── stable@0.1.5
│ │ │ │ │ ├── ast-traverse@0.1.1
│ │ │ │ │ ├── breakable@1.0.0
│ │ │ │ │ ├── simple-fmt@0.1.0
│ │ │ │ │ ├── simple-is@0.2.0
│ │ │ │ │ ├── stringmap@0.2.2
│ │ │ │ │ ├── stringset@0.2.1
│ │ │ │ │ └── tryor@0.1.2
│ │ │ │ ├── esprima-fb@15001.1001.0-dev-harmony-fb
│ │ │ │ └─┬ recast@0.10.33
│ │ │ │   └── ast-types@0.8.12
│ │ │ ├─┬ regexpu@1.3.0
│ │ │ │ ├── esprima@2.7.3
│ │ │ │ ├── regenerate@1.3.1
│ │ │ │ ├── regjsgen@0.2.0
│ │ │ │ └─┬ regjsparser@0.1.5
│ │ │ │   └── jsesc@0.5.0
│ │ │ ├── repeating@1.1.3
│ │ │ ├── shebang-regex@1.0.0
│ │ │ ├── slash@1.0.0
│ │ │ ├─┬ source-map-support@0.2.10
│ │ │ │ └── source-map@0.1.32
│ │ │ ├── to-fast-properties@1.0.2
│ │ │ ├── trim-right@1.0.1
│ │ │ └── try-resolve@1.0.1
│ │ └── clone@0.2.0
│ ├─┬ broccoli-concat@2.3.8
│ │ ├─┬ broccoli-caching-writer@2.3.1
│ │ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│ │ │ │ └── glob@5.0.15
│ │ │ ├── broccoli-plugin@1.1.0
│ │ │ └── walk-sync@0.2.7
│ │ ├─┬ broccoli-stew@1.4.0
│ │ │ └── minimatch@3.0.3
│ │ ├─┬ fast-sourcemap-concat@1.1.0
│ │ │ ├─┬ chalk@0.5.1
│ │ │ │ ├── ansi-styles@1.1.0
│ │ │ │ ├─┬ has-ansi@0.1.0
│ │ │ │ │ └── ansi-regex@0.2.1
│ │ │ │ ├── strip-ansi@0.3.0
│ │ │ │ └── supports-color@0.2.0
│ │ │ ├─┬ memory-streams@0.1.0
│ │ │ │ └─┬ readable-stream@1.0.34
│ │ │ │   └── isarray@0.0.1
│ │ │ └── source-map@0.4.4
│ │ ├── lodash.omit@4.5.0
│ │ └── lodash.uniq@4.5.0
│ ├── broccoli-config-loader@1.0.0
│ ├─┬ broccoli-config-replace@1.1.2
│ │ └── fs-extra@0.24.0
│ ├─┬ broccoli-funnel@1.0.7
│ │ ├── array-equal@1.0.0
│ │ ├── minimatch@3.0.3
│ │ └── path-posix@1.0.0
│ ├── broccoli-funnel-reducer@1.0.0
│ ├─┬ broccoli-sane-watcher@1.1.5
│ │ └── broccoli-slow-trees@1.1.0
│ ├── broccoli-source@1.1.0
│ ├── broccoli-viz@2.0.1
│ ├─┬ chalk@1.1.3
│ │ ├── ansi-styles@2.2.1
│ │ ├── has-ansi@2.0.0
│ │ ├── strip-ansi@3.0.1
│ │ └── supports-color@2.0.0
│ ├── clean-base-url@1.0.0
│ ├─┬ compression@1.6.2
│ │ ├── bytes@2.3.0
│ │ └── compressible@2.0.8
│ ├─┬ configstore@2.1.0
│ │ ├─┬ dot-prop@3.0.0
│ │ │ └── is-obj@1.0.1
│ │ ├── object-assign@4.1.0
│ │ ├── os-tmpdir@1.0.2
│ │ ├── uuid@2.0.3
│ │ ├─┬ write-file-atomic@1.2.0
│ │ │ ├── imurmurhash@0.1.4
│ │ │ └── slide@1.1.6
│ │ └── xdg-basedir@2.0.0
│ ├── core-object@2.0.6
│ ├── diff@2.2.3
│ ├─┬ ember-cli-broccoli@0.16.9
│ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│ │ │ └── glob@5.0.15
│ │ ├── connect@3.5.0
│ │ ├─┬ findup-sync@0.2.1
│ │ │ └── glob@4.3.5
│ │ └── mime@1.3.4
│ ├── ember-cli-get-component-path-option@1.0.0
│ ├─┬ ember-cli-legacy-blueprints@0.1.2
│ │ ├── ember-cli-get-dependency-depth@1.0.0
│ │ ├── ember-cli-lodash-subset@1.0.11
│ │ ├── ember-cli-valid-component-name@1.0.0
│ │ ├─┬ ember-router-generator@1.2.2
│ │ │ └─┬ recast@0.11.14
│ │ │   ├── ast-types@0.9.0
│ │ │   └── esprima@3.0.0
│ │ └── fs-extra@0.24.0
│ ├── ember-cli-normalize-entity-name@1.0.0
│ ├─┬ ember-cli-preprocess-registry@2.0.0
│ │ ├─┬ broccoli-clean-css@1.1.0
│ │ │ ├─┬ clean-css-promise@0.1.1
│ │ │ │ ├─┬ array-to-error@1.1.1
│ │ │ │ │ └── array-to-sentence@1.1.0
│ │ │ │ └─┬ clean-css@3.4.20
│ │ │ │   ├── commander@2.8.1
│ │ │ │   └── source-map@0.4.4
│ │ │ └─┬ inline-source-map-comment@1.0.5
│ │ │   └── sum-up@1.0.3
│ │ ├── lodash@3.10.1
│ │ └── process-relative-require@1.0.0
│ ├── ember-cli-string-utils@1.0.0
│ ├─┬ ember-try@0.2.6
│ │ ├─┬ cli-table2@0.2.0
│ │ │ ├── colors@1.1.2
│ │ │ └── lodash@3.10.1
│ │ ├─┬ ember-try-config@2.1.0
│ │ │ ├─┬ node-fetch@1.6.3
│ │ │ │ ├── encoding@0.1.12
│ │ │ │ └── is-stream@1.1.0
│ │ │ └── semver@5.3.0
│ │ ├── extend@3.0.0
│ │ ├── fs-extra@0.26.7
│ │ ├── semver@5.3.0
│ │ └── sync-exec@0.6.2
│ ├── escape-string-regexp@1.0.5
│ ├── exists-sync@0.0.3
│ ├── exit@0.1.2
│ ├── filesize@3.3.0
│ ├─┬ find-up@1.1.2
│ │ ├── path-exists@2.1.0
│ │ └─┬ pinkie-promise@2.0.1
│ │   └── pinkie@2.0.4
│ ├─┬ fs-extra@0.30.0
│ │ ├── jsonfile@2.4.0
│ │ └── klaw@1.3.0
│ ├── fs-monitor-stack@1.1.1
│ ├── fs-tree-diff@0.4.4
│ ├── get-caller-file@1.0.2
│ ├── git-repo-info@1.3.0
│ ├── glob@7.0.3
│ ├─┬ http-proxy@1.15.1
│ │ ├── eventemitter3@1.2.0
│ │ └── requires-port@1.0.0
│ ├── inflection@1.10.0
│ ├─┬ inquirer@0.12.0
│ │ ├── ansi-escapes@1.4.0
│ │ ├── ansi-regex@2.0.0
│ │ ├─┬ cli-cursor@1.0.2
│ │ │ └─┬ restore-cursor@1.0.1
│ │ │   ├── exit-hook@1.1.1
│ │ │   └── onetime@1.1.0
│ │ ├── cli-width@2.1.0
│ │ ├── figures@1.7.0
│ │ ├─┬ readline2@1.0.1
│ │ │ ├─┬ code-point-at@1.0.1
│ │ │ │ └── number-is-nan@1.0.1
│ │ │ ├── is-fullwidth-code-point@1.0.0
│ │ │ └── mute-stream@0.0.5
│ │ ├── run-async@0.1.0
│ │ ├── rx-lite@3.1.2
│ │ └── string-width@1.0.2
│ ├── is-git-url@0.2.3
│ ├── isbinaryfile@3.0.1
│ ├─┬ leek@0.0.21
│ │ ├─┬ lodash.assign@3.2.0
│ │ │ ├─┬ lodash._createassigner@3.1.1
│ │ │ │ ├── lodash._bindcallback@3.0.1
│ │ │ │ └── lodash.restparam@3.6.1
│ │ │ └── lodash.keys@3.1.2
│ │ └─┬ request@2.40.0
│ │   ├── aws-sign2@0.5.0
│ │   ├── forever-agent@0.5.2
│ │   ├─┬ form-data@0.1.4
│ │   │ ├── async@0.9.2
│ │   │ ├─┬ combined-stream@0.0.7
│ │   │ │ └── delayed-stream@0.0.5
│ │   │ └── mime@1.2.11
│ │   ├─┬ hawk@1.1.1
│ │   │ ├── boom@0.4.2
│ │   │ ├── cryptiles@0.2.2
│ │   │ ├── hoek@0.9.1
│ │   │ └── sntp@0.2.4
│ │   ├─┬ http-signature@0.10.1
│ │   │ ├── asn1@0.1.11
│ │   │ ├── assert-plus@0.1.5
│ │   │ └── ctype@0.5.3
│ │   ├── json-stringify-safe@5.0.1
│ │   ├── mime-types@1.0.2
│ │   ├── oauth-sign@0.3.0
│ │   ├── qs@1.0.2
│ │   ├── stringstream@0.0.5
│ │   ├── tough-cookie@2.3.1
│ │   └── tunnel-agent@0.4.3
│ ├─┬ markdown-it@6.0.4
│ │ ├─┬ argparse@1.0.9
│ │ │ └── sprintf-js@1.0.3
│ │ ├── entities@1.1.1
│ │ ├── linkify-it@1.2.4
│ │ ├── mdurl@1.0.1
│ │ └── uc.micro@1.0.3
│ ├─┬ markdown-it-terminal@0.0.3
│ │ ├─┬ cardinal@0.5.0
│ │ │ ├── ansicolors@0.2.1
│ │ │ └─┬ redeyed@0.5.0
│ │ │   └── esprima-fb@12001.1.0-dev-harmony-fb
│ │ ├─┬ cli-table@0.3.1
│ │ │ └── colors@1.0.3
│ │ └─┬ lodash.merge@3.3.2
│ │   ├── lodash._arraycopy@3.0.0
│ │   ├── lodash._arrayeach@3.0.0
│ │   ├── lodash._getnative@3.9.1
│ │   ├── lodash.isarguments@3.1.0
│ │   ├── lodash.isarray@3.0.4
│ │   ├─┬ lodash.isplainobject@3.2.0
│ │   │ └── lodash._basefor@3.0.3
│ │   ├── lodash.istypedarray@3.0.6
│ │   ├── lodash.keysin@3.0.8
│ │   └── lodash.toplainobject@3.0.0
│ ├─┬ minimatch@3.0.3
│ │ └─┬ brace-expansion@1.1.6
│ │   ├── balanced-match@0.4.2
│ │   └── concat-map@0.0.1
│ ├── node-modules-path@1.0.1
│ ├── node-uuid@1.4.7
│ ├─┬ nopt@3.0.6
│ │ └── abbrev@1.0.9
│ ├─┬ npm@2.15.5
│ │ ├── abbrev@1.0.7
│ │ ├── ansi@0.3.1
│ │ ├── ansi-regex@2.0.0
│ │ ├── ansicolors@0.3.2
│ │ ├── ansistyles@0.1.3
│ │ ├── archy@1.0.0
│ │ ├── async-some@1.0.2
│ │ ├── block-stream@0.0.9
│ │ ├── char-spinner@1.0.1
│ │ ├── chmodr@1.0.2
│ │ ├── chownr@1.0.1
│ │ ├── cmd-shim@2.0.2
│ │ ├─┬ columnify@1.5.4
│ │ │ └─┬ wcwidth@1.0.0
│ │ │   └─┬ defaults@1.0.3
│ │ │     └── clone@1.0.2
│ │ ├─┬ config-chain@1.1.10
│ │ │ └── proto-list@1.2.4
│ │ ├─┬ dezalgo@1.0.3
│ │ │ └── asap@2.0.3
│ │ ├── editor@1.0.0
│ │ ├── fs-vacuum@1.2.9
│ │ ├─┬ fs-write-stream-atomic@1.0.8
│ │ │ └── iferr@0.1.5
│ │ ├── fstream@1.0.8
│ │ ├─┬ fstream-npm@1.0.7
│ │ │ └── fstream-ignore@1.0.3
│ │ ├── github-url-from-git@1.4.0
│ │ ├── github-url-from-username-repo@1.0.2
│ │ ├─┬ glob@7.0.3
│ │ │ └── path-is-absolute@1.0.0
│ │ ├── graceful-fs@4.1.4
│ │ ├── hosted-git-info@2.1.4
│ │ ├── imurmurhash@0.1.4
│ │ ├── inflight@1.0.4
│ │ ├── inherits@2.0.1
│ │ ├── ini@1.3.4
│ │ ├─┬ init-package-json@1.9.3
│ │ │ ├─┬ glob@6.0.4
│ │ │ │ └── path-is-absolute@1.0.0
│ │ │ └── promzard@0.3.0
│ │ ├── lockfile@1.0.1
│ │ ├─┬ lru-cache@4.0.1
│ │ │ ├── pseudomap@1.0.2
│ │ │ └── yallist@2.0.0
│ │ ├─┬ minimatch@3.0.0
│ │ │ └─┬ brace-expansion@1.1.1
│ │ │   ├── balanced-match@0.2.1
│ │ │   └── concat-map@0.0.1
│ │ ├─┬ mkdirp@0.5.1
│ │ │ └── minimist@0.0.8
│ │ ├─┬ node-gyp@3.3.1
│ │ │ ├─┬ glob@4.5.3
│ │ │ │ └─┬ minimatch@2.0.10
│ │ │ │   └─┬ brace-expansion@1.1.3
│ │ │ │     ├── balanced-match@0.3.0
│ │ │ │     └── concat-map@0.0.1
│ │ │ ├─┬ minimatch@1.0.0
│ │ │ │ ├── lru-cache@2.7.3
│ │ │ │ └── sigmund@1.0.1
│ │ │ └─┬ path-array@1.0.1
│ │ │   └─┬ array-index@1.0.0
│ │ │     ├─┬ debug@2.2.0
│ │ │     │ └── ms@0.7.1
│ │ │     └─┬ es6-symbol@3.0.2
│ │ │       ├── d@0.1.1
│ │ │       └─┬ es5-ext@0.10.11
│ │ │         └── es6-iterator@2.0.0
│ │ ├── nopt@3.0.6
│ │ ├── normalize-git-url@3.0.2
│ │ ├─┬ normalize-package-data@2.3.5
│ │ │ └─┬ is-builtin-module@1.0.0
│ │ │   └── builtin-modules@1.1.0
│ │ ├── npm-cache-filename@1.0.2
│ │ ├── npm-install-checks@1.0.7
│ │ ├── npm-package-arg@4.1.0
│ │ ├─┬ npm-registry-client@7.1.0
│ │ │ ├─┬ concat-stream@1.5.1
│ │ │ │ ├─┬ readable-stream@2.0.5
│ │ │ │ │ ├── core-util-is@1.0.2
│ │ │ │ │ ├── isarray@0.0.1
│ │ │ │ │ ├── process-nextick-args@1.0.6
│ │ │ │ │ ├── string_decoder@0.10.31
│ │ │ │ │ └── util-deprecate@1.0.2
│ │ │ │ └── typedarray@0.0.6
│ │ │ └── retry@0.8.0
│ │ ├── npm-user-validate@0.1.2
│ │ ├─┬ npmlog@2.0.3
│ │ │ ├─┬ are-we-there-yet@1.1.2
│ │ │ │ └── delegates@1.0.0
│ │ │ └─┬ gauge@1.2.7
│ │ │   ├── has-unicode@2.0.0
│ │ │   ├─┬ lodash.pad@4.1.0
│ │ │   │ ├── lodash.repeat@4.0.2
│ │ │   │ └── lodash.tostring@4.1.2
│ │ │   ├── lodash.padend@4.2.0
│ │ │   └── lodash.padstart@4.2.0
│ │ ├── once@1.3.3
│ │ ├── opener@1.4.1
│ │ ├─┬ osenv@0.1.3
│ │ │ ├── os-homedir@1.0.0
│ │ │ └── os-tmpdir@1.0.1
│ │ ├── path-is-inside@1.0.1
│ │ ├─┬ read@1.0.7
│ │ │ └── mute-stream@0.0.5
│ │ ├─┬ read-installed@4.0.3
│ │ │ ├── debuglog@1.0.1
│ │ │ ├── readdir-scoped-modules@1.0.2
│ │ │ └── util-extend@1.0.1
│ │ ├─┬ read-package-json@2.0.4
│ │ │ ├─┬ glob@6.0.4
│ │ │ │ └── path-is-absolute@1.0.0
│ │ │ └─┬ json-parse-helpfulerror@1.0.3
│ │ │   └── jju@1.3.0
│ │ ├─┬ readable-stream@2.1.2
│ │ │ ├── core-util-is@1.0.2
│ │ │ ├── isarray@1.0.0
│ │ │ ├── process-nextick-args@1.0.7
│ │ │ ├── string_decoder@0.10.31
│ │ │ └── util-deprecate@1.0.2
│ │ ├─┬ realize-package-specifier@3.0.3
│ │ │ └── npm-package-arg@4.1.1
│ │ ├─┬ request@2.72.0
│ │ │ ├── aws-sign2@0.6.0
│ │ │ ├── aws4@1.3.2
│ │ │ ├─┬ bl@1.1.2
│ │ │ │ └─┬ readable-stream@2.0.6
│ │ │ │   ├── core-util-is@1.0.2
│ │ │ │   ├── isarray@1.0.0
│ │ │ │   ├── process-nextick-args@1.0.7
│ │ │ │   ├── string_decoder@0.10.31
│ │ │ │   └── util-deprecate@1.0.2
│ │ │ ├── caseless@0.11.0
│ │ │ ├─┬ combined-stream@1.0.5
│ │ │ │ └── delayed-stream@1.0.0
│ │ │ ├── extend@3.0.0
│ │ │ ├── forever-agent@0.6.1
│ │ │ ├─┬ form-data@1.0.0-rc4
│ │ │ │ └── async@1.5.2
│ │ │ ├─┬ har-validator@2.0.6
│ │ │ │ ├─┬ chalk@1.1.3
│ │ │ │ │ ├── ansi-styles@2.2.1
│ │ │ │ │ ├── escape-string-regexp@1.0.5
│ │ │ │ │ ├── has-ansi@2.0.0
│ │ │ │ │ └── supports-color@2.0.0
│ │ │ │ ├─┬ commander@2.9.0
│ │ │ │ │ └── graceful-readlink@1.0.1
│ │ │ │ ├─┬ is-my-json-valid@2.13.1
│ │ │ │ │ ├── generate-function@2.0.0
│ │ │ │ │ ├─┬ generate-object-property@1.2.0
│ │ │ │ │ │ └── is-property@1.0.2
│ │ │ │ │ ├── jsonpointer@2.0.0
│ │ │ │ │ └── xtend@4.0.1
│ │ │ │ └─┬ pinkie-promise@2.0.1
│ │ │ │   └── pinkie@2.0.4
│ │ │ ├─┬ hawk@3.1.3
│ │ │ │ ├── boom@2.10.1
│ │ │ │ ├── cryptiles@2.0.5
│ │ │ │ ├── hoek@2.16.3
│ │ │ │ └── sntp@1.0.9
│ │ │ ├─┬ http-signature@1.1.1
│ │ │ │ ├── assert-plus@0.2.0
│ │ │ │ ├─┬ jsprim@1.2.2
│ │ │ │ │ ├── extsprintf@1.0.2
│ │ │ │ │ ├── json-schema@0.2.2
│ │ │ │ │ └── verror@1.3.6
│ │ │ │ └─┬ sshpk@1.8.3
│ │ │ │   ├── asn1@0.2.3
│ │ │ │   ├── assert-plus@1.0.0
│ │ │ │   ├── dashdash@1.13.1
│ │ │ │   ├── ecc-jsbn@0.1.1
│ │ │ │   ├── getpass@0.1.6
│ │ │ │   ├── jodid25519@1.0.2
│ │ │ │   ├── jsbn@0.1.0
│ │ │ │   └── tweetnacl@0.13.3
│ │ │ ├── is-typedarray@1.0.0
│ │ │ ├── isstream@0.1.2
│ │ │ ├── json-stringify-safe@5.0.1
│ │ │ ├─┬ mime-types@2.1.11
│ │ │ │ └── mime-db@1.23.0
│ │ │ ├── node-uuid@1.4.7
│ │ │ ├── oauth-sign@0.8.2
│ │ │ ├── qs@6.1.0
│ │ │ ├── stringstream@0.0.5
│ │ │ ├── tough-cookie@2.2.2
│ │ │ └── tunnel-agent@0.4.3
│ │ ├── retry@0.9.0
│ │ ├─┬ rimraf@2.5.2
│ │ │ └─┬ glob@7.0.0
│ │ │   └── path-is-absolute@1.0.0
│ │ ├── semver@5.1.0
│ │ ├─┬ sha@2.0.1
│ │ │ └─┬ readable-stream@2.0.2
│ │ │   ├── core-util-is@1.0.1
│ │ │   ├── isarray@0.0.1
│ │ │   ├── process-nextick-args@1.0.3
│ │ │   ├── string_decoder@0.10.31
│ │ │   └── util-deprecate@1.0.1
│ │ ├── slide@1.1.6
│ │ ├── sorted-object@2.0.0
│ │ ├── spdx-license-ids@1.2.1
│ │ ├── strip-ansi@3.0.1
│ │ ├── tar@2.2.1
│ │ ├── text-table@0.2.0
│ │ ├── uid-number@0.0.6
│ │ ├── umask@1.1.0
│ │ ├─┬ validate-npm-package-license@3.0.1
│ │ │ ├── spdx-correct@1.0.2
│ │ │ └─┬ spdx-expression-parse@1.0.2
│ │ │   └── spdx-exceptions@1.0.4
│ │ ├─┬ validate-npm-package-name@2.2.2
│ │ │ └── builtins@0.0.7
│ │ ├─┬ which@1.2.8
│ │ │ ├─┬ is-absolute@0.1.7
│ │ │ │ └── is-relative@0.1.3
│ │ │ └── isexe@1.1.2
│ │ ├── wrappy@1.0.1
│ │ └── write-file-atomic@1.1.4
│ ├─┬ npm-package-arg@4.2.0
│ │ ├── hosted-git-info@2.1.5
│ │ └── semver@5.3.0
│ ├─┬ ora@0.2.3
│ │ └── cli-spinners@0.1.2
│ ├─┬ portfinder@1.0.8
│ │ └── async@1.5.2
│ ├─┬ quick-temp@0.1.5
│ │ ├── mktemp@0.3.5
│ │ └── rimraf@2.2.8
│ ├── resolve@1.1.7
│ ├─┬ sane@1.4.1
│ │ ├── exec-sh@0.2.0
│ │ ├─┬ fb-watchman@1.9.0
│ │ │ └─┬ bser@1.0.2
│ │ │   └── node-int64@0.4.0
│ │ ├── minimatch@3.0.3
│ │ ├── minimist@1.2.0
│ │ ├─┬ walker@1.0.7
│ │ │ └─┬ makeerror@1.0.11
│ │ │   └── tmpl@1.0.4
│ │ └── watch@0.10.0
│ ├── semver@5.3.0
│ ├─┬ temp@0.8.3
│ │ └── rimraf@2.2.8
│ ├─┬ testem@1.12.0
│ │ ├─┬ backbone@1.3.3
│ │ │ └── underscore@1.8.3
│ │ ├── bluebird@3.4.6
│ │ ├── charm@1.0.1
│ │ ├─┬ consolidate@0.14.1
│ │ │ └── bluebird@3.4.6
│ │ ├─┬ cross-spawn@4.0.2
│ │ │ ├─┬ lru-cache@4.0.1
│ │ │ │ ├── pseudomap@1.0.2
│ │ │ │ └── yallist@2.0.0
│ │ │ └─┬ which@1.2.11
│ │ │   └── isexe@1.1.2
│ │ ├── did_it_work@0.0.6
│ │ ├─┬ fireworm@0.7.1
│ │ │ ├── async@0.2.10
│ │ │ ├── is-type@0.0.1
│ │ │ ├── lodash.debounce@3.1.1
│ │ │ ├─┬ lodash.flatten@3.0.2
│ │ │ │ └── lodash._baseflatten@3.1.4
│ │ │ └── minimatch@3.0.3
│ │ ├─┬ js-yaml@3.6.1
│ │ │ └── esprima@2.7.3
│ │ ├── lodash.assignin@4.2.0
│ │ ├── lodash.clonedeep@4.5.0
│ │ ├── lodash.find@4.6.0
│ │ ├── mustache@2.2.1
│ │ ├─┬ node-notifier@4.6.1
│ │ │ ├─┬ cli-usage@0.1.4
│ │ │ │ └─┬ marked-terminal@1.6.2
│ │ │ │   ├─┬ cardinal@1.0.0
│ │ │ │   │ └─┬ redeyed@1.0.0
│ │ │ │   │   └── esprima@2.7.3
│ │ │ │   ├── lodash.assign@4.2.0
│ │ │ │   └─┬ node-emoji@1.4.1
│ │ │ │     └── string.prototype.codepointat@0.2.0
│ │ │ ├── growly@1.3.0
│ │ │ ├─┬ lodash.clonedeep@3.0.2
│ │ │ │ └── lodash._baseclone@3.3.0
│ │ │ ├── semver@5.3.0
│ │ │ └── shellwords@0.1.0
│ │ ├─┬ npmlog@4.0.0
│ │ │ ├─┬ are-we-there-yet@1.1.2
│ │ │ │ └── delegates@1.0.0
│ │ │ ├── console-control-strings@1.1.0
│ │ │ ├─┬ gauge@2.6.0
│ │ │ │ ├── aproba@1.0.4
│ │ │ │ ├── has-unicode@2.0.1
│ │ │ │ ├── signal-exit@3.0.1
│ │ │ │ └── wide-align@1.1.0
│ │ │ └── set-blocking@2.0.0
│ │ ├── printf@0.2.5
│ │ ├─┬ socket.io@1.4.7
│ │ │ ├─┬ engine.io@1.6.10
│ │ │ │ ├─┬ accepts@1.1.4
│ │ │ │ │ ├─┬ mime-types@2.0.14
│ │ │ │ │ │ └── mime-db@1.12.0
│ │ │ │ │ └── negotiator@0.4.9
│ │ │ │ ├── base64id@0.1.0
│ │ │ │ ├─┬ engine.io-parser@1.2.4
│ │ │ │ │ ├── after@0.8.1
│ │ │ │ │ ├── arraybuffer.slice@0.0.6
│ │ │ │ │ ├── base64-arraybuffer@0.1.2
│ │ │ │ │ ├── blob@0.0.4
│ │ │ │ │ ├─┬ has-binary@0.1.6
│ │ │ │ │ │ └── isarray@0.0.1
│ │ │ │ │ └── utf8@2.1.0
│ │ │ │ └─┬ ws@1.0.1
│ │ │ │   ├── options@0.0.6
│ │ │ │   └── ultron@1.0.2
│ │ │ ├─┬ has-binary@0.1.7
│ │ │ │ └── isarray@0.0.1
│ │ │ ├─┬ socket.io-adapter@0.4.0
│ │ │ │ └─┬ socket.io-parser@2.2.2
│ │ │ │   ├── debug@0.7.4
│ │ │ │   ├── isarray@0.0.1
│ │ │ │   └── json3@3.2.6
│ │ │ ├─┬ socket.io-client@1.4.6
│ │ │ │ ├── backo2@1.0.2
│ │ │ │ ├── component-bind@1.0.0
│ │ │ │ ├── component-emitter@1.2.0
│ │ │ │ ├─┬ engine.io-client@1.6.9
│ │ │ │ │ ├── component-inherit@0.0.3
│ │ │ │ │ ├── has-cors@1.1.0
│ │ │ │ │ ├── parsejson@0.0.1
│ │ │ │ │ ├── parseqs@0.0.2
│ │ │ │ │ ├── xmlhttprequest-ssl@1.5.1
│ │ │ │ │ └── yeast@0.1.2
│ │ │ │ ├── object-component@0.0.3
│ │ │ │ ├─┬ parseuri@0.0.4
│ │ │ │ │ └─┬ better-assert@1.0.2
│ │ │ │ │   └── callsite@1.0.0
│ │ │ │ └── to-array@0.1.4
│ │ │ └─┬ socket.io-parser@2.2.6
│ │ │   ├── benchmark@1.0.0
│ │ │   ├── component-emitter@1.1.2
│ │ │   ├── isarray@0.0.1
│ │ │   └── json3@3.3.2
│ │ ├── spawn-args@0.2.0
│ │ ├── styled_string@0.0.1
│ │ ├─┬ tap-parser@1.3.2
│ │ │ └── events-to-array@1.0.2
│ │ └── xmldom@0.1.22
│ ├── through@2.3.8
│ ├─┬ tiny-lr@0.2.1
│ │ ├─┬ body-parser@1.14.2
│ │ │ ├── bytes@2.2.0
│ │ │ ├── http-errors@1.3.1
│ │ │ └── qs@5.2.0
│ │ ├─┬ faye-websocket@0.10.0
│ │ │ └─┬ websocket-driver@0.6.5
│ │ │   └── websocket-extensions@0.1.1
│ │ ├── livereload-js@2.2.2
│ │ └── qs@5.1.0
│ ├─┬ tree-sync@1.1.4
│ │ └── walk-sync@0.2.7
│ ├── walk-sync@0.2.7
│ └─┬ yam@0.0.19
│   ├── fs-extra@0.26.7
│   └── lodash.merge@3.3.2
├─┬ ember-cli-app-version@1.0.1
│ └── git-repo-version@0.3.0
├─┬ ember-cli-babel@5.1.10
│ └── clone@1.0.2
├── ember-cli-base64@0.0.1
├─┬ ember-cli-blueprint-test-helpers@0.13.0
│ ├─┬ chai@3.5.0
│ │ ├── assertion-error@1.0.2
│ │ ├─┬ deep-eql@0.1.3
│ │ │ └── type-detect@0.1.1
│ │ └── type-detect@1.0.0
│ ├── chai-as-promised@5.3.0
│ ├── chai-files@1.4.0
│ ├─┬ ember-cli-internal-test-helpers@0.8.1
│ │ ├── configstore@1.4.0
│ │ ├─┬ cpr@0.4.3
│ │ │ └─┬ rimraf@2.4.5
│ │ │   └── glob@6.0.4
│ │ ├── fs-extra@0.24.0
│ │ └── walk-sync@0.2.7
│ ├─┬ findup@0.1.5
│ │ ├── colors@0.6.2
│ │ └── commander@2.1.0
│ ├── lodash.merge@4.6.0
│ ├─┬ tmp-sync@1.1.0
│ │ └─┬ fs-sync@0.2.6
│ │   ├─┬ glob@4.0.6
│ │   │ ├─┬ graceful-fs@3.0.11
│ │   │ │ └── natives@1.1.0
│ │   │ └─┬ minimatch@1.0.0
│ │   │   ├── lru-cache@2.7.3
│ │   │   └── sigmund@1.0.1
│ │   ├── iconv-lite@0.2.11
│ │   ├── lodash@1.2.1
│ │   ├── mkdirp@0.3.5
│ │   └─┬ rimraf@2.1.4
│ │     └── graceful-fs@1.2.3
│ └── walk-sync@0.2.7
├── ember-cli-content-security-policy@0.5.0
├─┬ ember-cli-dependency-checker@1.3.0
│ ├─┬ chalk@0.5.1
│ │ ├── ansi-styles@1.1.0
│ │ ├─┬ has-ansi@0.1.0
│ │ │ └── ansi-regex@0.2.1
│ │ ├── strip-ansi@0.3.0
│ │ └── supports-color@0.2.0
│ ├── is-git-url@0.2.0
│ └── semver@4.3.6
├─┬ ember-cli-htmlbars@1.1.0
│ ├─┬ broccoli-persistent-filter@1.2.11
│ │ └─┬ async-disk-cache@1.0.8
│ │   └─┬ istextorbinary@2.1.0
│ │     ├── binaryextensions@2.0.0
│ │     ├── editions@1.3.1
│ │     └── textextensions@2.0.1
│ ├── hash-for-dep@1.0.3
│ └─┬ strip-bom@2.0.0
│   └── is-utf8@0.2.1
├─┬ ember-cli-htmlbars-inline-precompile@0.3.5
│ └── babel-plugin-htmlbars-inline-precompile@0.1.0
├── ember-cli-inject-live-reload@1.4.1
├── ember-cli-is-package-missing@1.0.0
├─┬ ember-cli-jshint@1.0.5
│ └─┬ broccoli-jshint@1.2.0
│   ├─┬ chalk@0.4.0
│   │ ├── ansi-styles@1.0.0
│   │ ├── has-color@0.1.7
│   │ └── strip-ansi@0.1.1
│   ├─┬ findup-sync@0.3.0
│   │ └── glob@5.0.15
│   ├─┬ jshint@2.9.3
│   │ ├── cli@1.0.0
│   │ ├── lodash@3.7.0
│   │ ├── minimatch@3.0.3
│   │ └── shelljs@0.3.0
│   └─┬ mkdirp@0.4.2
│     └── minimist@0.0.8
├─┬ ember-cli-mocha@0.10.4
│ └─┬ ember-mocha@0.8.11
│   └─┬ ember-test-helpers@0.5.34
│     └── klassy@0.1.3
├── ember-cli-pretender@0.6.0
├─┬ ember-cli-release@0.2.9
│ ├─┬ git-tools@0.1.4
│ │ └── spawnback@1.0.0
│ ├── make-array@0.1.2
│ └─┬ moment-timezone@0.3.1
│   └── moment@2.15.1
├─┬ ember-cli-sri@2.1.1
│ └─┬ broccoli-sri-hash@2.1.2
│   ├─┬ broccoli-caching-writer@2.3.1
│   │ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│   │ │ └── glob@5.0.15
│   │ ├── broccoli-plugin@1.1.0
│   │ └── walk-sync@0.2.7
│   └── sri-toolbox@0.2.0
├── ember-cli-test-loader@1.1.0
├─┬ ember-cli-uglify@1.2.0
│ └─┬ broccoli-uglify-sourcemap@1.4.2
│   ├── source-map-url@0.3.0
│   └── walk-sync@0.1.3
├─┬ ember-data@2.8.1
│ ├── babel-plugin-feature-flags@0.2.3
│ ├── babel-plugin-filter-imports@0.2.1
│ ├─┬ broccoli-file-creator@1.1.1
│ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.9
│ │ │ └── glob@5.0.15
│ │ ├── broccoli-writer@0.1.1
│ │ └── rsvp@3.0.21
│ ├── ember-cli-path-utils@1.0.0
│ ├── ember-cli-test-info@1.0.0
│ ├── ember-inflector@1.9.6
│ ├── ember-runtime-enumerable-includes-polyfill@1.0.1
│ ├── npm-git-info@1.0.3
│ └── semver@5.3.0
├── ember-disable-prototype-extensions@1.1.0
├── ember-export-application-global@1.1.1
├── ember-getowner-polyfill@1.0.1
├── ember-load-initializers@0.5.1
├── ember-resolver@2.1.0
├─┬ ember-sinon@0.5.1
│ ├─┬ ember-cli-node-assets@0.1.4
│ │ └── broccoli-unwatched-tree@0.1.1
│ └─┬ sinon@1.17.6
│   ├── formatio@1.1.1
│   ├── lolex@1.3.2
│   └── samsam@1.1.2
├─┬ ember-suave@4.0.1
│ ├─┬ broccoli-jscs@2.0.0
│ │ ├─┬ findup-sync@0.4.3
│ │ │ ├─┬ detect-file@0.1.0
│ │ │ │ └── fs-exists-sync@0.1.0
│ │ │ ├─┬ is-glob@2.0.1
│ │ │ │ └── is-extglob@1.0.0
│ │ │ ├─┬ micromatch@2.3.11
│ │ │ │ ├─┬ arr-diff@2.0.0
│ │ │ │ │ └── arr-flatten@1.0.1
│ │ │ │ ├── array-unique@0.2.1
│ │ │ │ ├─┬ braces@1.8.5
│ │ │ │ │ ├─┬ expand-range@1.8.2
│ │ │ │ │ │ └─┬ fill-range@2.2.3
│ │ │ │ │ │   ├── is-number@2.1.0
│ │ │ │ │ │   ├── isobject@2.1.0
│ │ │ │ │ │   └── randomatic@1.1.5
│ │ │ │ │ ├── preserve@0.2.0
│ │ │ │ │ └── repeat-element@1.1.2
│ │ │ │ ├─┬ expand-brackets@0.1.5
│ │ │ │ │ └── is-posix-bracket@0.1.1
│ │ │ │ ├── extglob@0.3.2
│ │ │ │ ├── filename-regex@2.0.0
│ │ │ │ ├── kind-of@3.0.4
│ │ │ │ ├── normalize-path@2.0.1
│ │ │ │ ├─┬ object.omit@2.0.0
│ │ │ │ │ ├─┬ for-own@0.1.4
│ │ │ │ │ │ └── for-in@0.1.6
│ │ │ │ │ └── is-extendable@0.1.1
│ │ │ │ ├─┬ parse-glob@3.0.4
│ │ │ │ │ ├─┬ glob-base@0.3.0
│ │ │ │ │ │ └── glob-parent@2.0.0
│ │ │ │ │ └── is-dotfile@1.0.2
│ │ │ │ └─┬ regex-cache@0.4.3
│ │ │ │   ├── is-equal-shallow@0.1.3
│ │ │ │   └── is-primitive@2.0.0
│ │ │ └─┬ resolve-dir@0.1.1
│ │ │   ├── expand-tilde@1.2.2
│ │ │   └─┬ global-modules@0.2.3
│ │ │     ├─┬ global-prefix@0.1.4
│ │ │     │ └── ini@1.3.4
│ │ │     └── is-windows@0.2.0
│ │ └── minimatch@3.0.3
│ ├── js-string-escape@1.0.1
│ ├─┬ jscs@3.0.7
│ │ ├─┬ cst@0.4.6
│ │ │ ├─┬ babel-runtime@6.11.6
│ │ │ │ ├── core-js@2.4.1
│ │ │ │ └── regenerator-runtime@0.9.5
│ │ │ ├── babylon@6.12.0
│ │ │ └── source-map-support@0.4.4
│ │ ├── estraverse@4.2.0
│ │ ├── glob@5.0.15
│ │ ├─┬ htmlparser2@3.8.3
│ │ │ ├── domelementtype@1.3.0
│ │ │ ├── domhandler@2.3.0
│ │ │ ├─┬ domutils@1.5.1
│ │ │ │ └─┬ dom-serializer@0.1.0
│ │ │ │   └── domelementtype@1.1.3
│ │ │ ├── entities@1.0.0
│ │ │ └─┬ readable-stream@1.1.14
│ │ │   └── isarray@0.0.1
│ │ ├─┬ js-yaml@3.4.6
│ │ │ ├── esprima@2.7.3
│ │ │ └── inherit@2.2.6
│ │ ├─┬ jscs-jsdoc@2.0.0
│ │ │ ├── comment-parser@0.3.1
│ │ │ └─┬ jsdoctypeparser@1.2.0
│ │ │   └── lodash@3.10.1
│ │ ├── jscs-preset-wikimedia@1.0.0
│ │ ├─┬ jsonlint@1.6.2
│ │ │ ├── JSV@4.0.2
│ │ │ └─┬ nomnom@1.8.1
│ │ │   ├─┬ chalk@0.4.0
│ │ │   │ ├── ansi-styles@1.0.0
│ │ │   │ └── strip-ansi@0.1.1
│ │ │   └── underscore@1.6.0
│ │ ├── lodash@3.10.1
│ │ ├── minimatch@3.0.3
│ │ ├── natural-compare@1.2.2
│ │ ├── pathval@0.1.1
│ │ ├─┬ prompt@0.2.14
│ │ │ ├── pkginfo@0.4.0
│ │ │ ├── read@1.0.7
│ │ │ ├── revalidator@0.1.8
│ │ │ ├─┬ utile@0.2.1
│ │ │ │ ├── async@0.2.10
│ │ │ │ ├── deep-equal@1.0.1
│ │ │ │ ├── i@0.3.5
│ │ │ │ └── ncp@0.4.2
│ │ │ └─┬ winston@0.8.3
│ │ │   ├── async@0.2.10
│ │ │   ├── colors@0.6.2
│ │ │   ├── cycle@1.0.3
│ │ │   ├── eyes@0.1.8
│ │ │   ├── isstream@0.1.2
│ │ │   ├── pkginfo@0.3.1
│ │ │   └── stack-trace@0.0.9
│ │ ├── reserved-words@0.1.1
│ │ ├── strip-json-comments@1.0.4
│ │ ├── to-double-quotes@2.0.0
│ │ ├── to-single-quotes@2.0.1
│ │ ├── vow@0.4.12
│ │ ├─┬ vow-fs@0.3.6
│ │ │ └── vow-queue@0.4.2
│ │ └─┬ xmlbuilder@3.1.0
│ │   └── lodash@3.10.1
│ └── jscs-ember-deprecations@2.3.0
├─┬ express@4.14.0
│ ├─┬ accepts@1.3.3
│ │ └── negotiator@0.6.1
│ ├── array-flatten@1.1.1
│ ├── content-disposition@0.5.1
│ ├── cookie@0.3.1
│ ├── cookie-signature@1.0.6
│ ├── encodeurl@1.0.1
│ ├── escape-html@1.0.3
│ ├── etag@1.7.0
│ ├── finalhandler@0.5.0
│ ├── fresh@0.3.0
│ ├── merge-descriptors@1.0.1
│ ├── methods@1.1.2
│ ├── parseurl@1.3.1
│ ├── path-to-regexp@0.1.7
│ ├─┬ proxy-addr@1.1.2
│ │ ├── forwarded@0.1.0
│ │ └── ipaddr.js@1.1.1
│ ├── range-parser@1.2.0
│ ├─┬ send@0.14.1
│ │ └── destroy@1.0.4
│ ├── serve-static@1.11.1
│ ├── utils-merge@1.0.0
│ └── vary@1.1.0
├── git-repo-version@0.3.1
├─┬ glob@7.1.1
│ ├── fs.realpath@1.0.0
│ ├─┬ inflight@1.0.6
│ │ └── wrappy@1.0.2
│ ├── inherits@2.0.3
│ ├── minimatch@3.0.3
│ ├── once@1.4.0
│ └── path-is-absolute@1.0.1
├─┬ handlebars@4.0.5
│ ├── async@1.5.2
│ ├─┬ optimist@0.6.1
│ │ ├── minimist@0.0.10
│ │ └── wordwrap@0.0.2
│ ├─┬ source-map@0.4.4
│ │ └── amdefine@1.0.0
│ └─┬ uglify-js@2.7.3
│   ├── async@0.2.10
│   ├── source-map@0.5.6
│   ├── uglify-to-browserify@1.0.2
│   └─┬ yargs@3.10.0
│     └── window-size@0.1.0
├── loader.js@4.0.11
├── lodash@4.16.4
├── marked@0.3.6
├─┬ mocha@3.1.2
│ ├── browser-stdout@1.3.0
│ ├─┬ commander@2.9.0
│ │ └── graceful-readlink@1.0.1
│ ├── diff@1.4.0
│ ├─┬ glob@7.0.5
│ │ └── minimatch@3.0.3
│ ├── growl@1.9.2
│ ├── json3@3.3.2
│ ├─┬ lodash.create@3.1.1
│ │ ├─┬ lodash._baseassign@3.2.0
│ │ │ └── lodash._basecopy@3.0.1
│ │ ├── lodash._basecreate@3.0.3
│ │ └── lodash._isiterateecall@3.0.9
│ └─┬ supports-color@3.1.2
│   └── has-flag@1.0.0
├─┬ mocha-only-detector@0.1.0
│ ├── esprima@2.7.3
│ ├── esprimaq@0.0.1
│ └── glob@4.5.3
├─┬ morgan@1.7.0
│ ├── basic-auth@1.0.4
│ └── on-headers@1.0.1
├── silent-error@1.0.1
├── sinon-chai@2.8.0
└─┬ torii@0.8.0
  └── broccoli-string-replace@0.1.1

bower not-cached    https://github.com/twbs/bootstrap.git#~3.3.7
bower resolve       https://github.com/twbs/bootstrap.git#~3.3.7
bower not-cached    https://github.com/teddyzeenny/ember-mocha-adapter.git#~0.3.1
bower resolve       https://github.com/teddyzeenny/ember-mocha-adapter.git#~0.3.1
bower not-cached    https://github.com/davidchambers/Base64.js.git#~1.0.0
bower resolve       https://github.com/davidchambers/Base64.js.git#~1.0.0
bower not-cached    https://github.com/trek/pretender.git#~1.1.0
bower resolve       https://github.com/trek/pretender.git#~1.1.0
bower not-cached    https://github.com/components/ember.git#~2.7.0
bower resolve       https://github.com/components/ember.git#~2.7.0
bower not-cached    https://github.com/mochajs/mocha.git#~2.2.4
bower resolve       https://github.com/mochajs/mocha.git#~2.2.4
bower not-cached    https://github.com/ember-cli/ember-cli-shims.git#0.1.1
bower resolve       https://github.com/ember-cli/ember-cli-shims.git#0.1.1
bower not-cached    https://github.com/chaijs/chai.git#~2.3.0
bower resolve       https://github.com/chaijs/chai.git#~2.3.0
bower not-cached    https://github.com/blittle/sinon.js.git#~1.17.1
bower resolve       https://github.com/blittle/sinon.js.git#~1.17.1
bower checkout      base64#1.0.0
bower checkout      ember-mocha-adapter#0.3.1
bower checkout      ember-cli-shims#v0.1.1
bower checkout      pretender#1.1.0
bower checkout      sinonjs#v1.17.1
bower checkout      ember#2.7.3
bower checkout      chai#2.3.0
bower checkout      mocha#2.2.5
bower resolved      https://github.com/teddyzeenny/ember-mocha-adapter.git#0.3.1
bower resolved      https://github.com/davidchambers/Base64.js.git#1.0.0
bower invalid-meta  The "main" field has to contain only 1 file per filetype; found multiple .js files: ["app-shims.js","test-shims.js"]
bower resolved      https://github.com/ember-cli/ember-cli-shims.git#0.1.1
bower not-cached    https://github.com/components/ember.git#>=1.4
bower resolve       https://github.com/components/ember.git#>=1.4
bower checkout      ember#2.8.2
bower checkout      bootstrap#v3.3.7
bower resolved      https://github.com/trek/pretender.git#1.1.0
bower resolved      https://github.com/blittle/sinon.js.git#1.17.1
bower not-cached    https://github.com/trek/FakeXMLHttpRequest.git#^1.4.0
bower resolve       https://github.com/trek/FakeXMLHttpRequest.git#^1.4.0
bower not-cached    https://github.com/tildeio/route-recognizer.git#~0.1.1
bower resolve       https://github.com/tildeio/route-recognizer.git#~0.1.1
bower resolved      https://github.com/chaijs/chai.git#2.3.0
bower checkout      FakeXMLHttpRequest#1.4.0
bower resolved      https://github.com/mochajs/mocha.git#2.2.5
bower checkout      route-recognizer#v0.1.11
bower invalid-meta  The "main" field has to contain only 1 file per filetype; found multiple .js files: ["./ember.debug.js","./ember-template-compiler.js"]
bower resolved      https://github.com/components/ember.git#2.7.3
bower not-cached    https://github.com/jquery/jquery-dist.git#>= 1.7.0 < 3.0.0
bower resolve       https://github.com/jquery/jquery-dist.git#>= 1.7.0 < 3.0.0
bower resolved      https://github.com/trek/FakeXMLHttpRequest.git#1.4.0
bower mismatch      Version declared in the json (0.1.9) is different than the resolved one (0.1.11)
bower resolved      https://github.com/tildeio/route-recognizer.git#0.1.11
bower invalid-meta  The "main" field has to contain only 1 file per filetype; found multiple .js files: ["./ember.debug.js","./ember-template-compiler.js"]
bower resolved      https://github.com/components/ember.git#2.8.2
bower not-cached    https://github.com/jquery/jquery-dist.git#>= 1.7.0 < 4.0.0
bower resolve       https://github.com/jquery/jquery-dist.git#>= 1.7.0 < 4.0.0
bower checkout      jquery#3.1.1
bower checkout      jquery#2.2.4
bower resolved      https://github.com/jquery/jquery-dist.git#2.2.4
bower resolved      https://github.com/jquery/jquery-dist.git#3.1.1
bower resolved      https://github.com/twbs/bootstrap.git#3.3.7
bower install       ember-mocha-adapter#0.3.1
bower install       base64#1.0.0
bower install       ember-cli-shims#0.1.1
bower install       pretender#1.1.0
bower install       sinonjs#1.17.1
bower install       chai#2.3.0
bower install       mocha#2.2.5
bower install       ember#2.7.3
bower install       FakeXMLHttpRequest#1.4.0
bower install       route-recognizer#0.1.11
bower install       jquery#2.2.4
bower install       bootstrap#3.3.7

ember-mocha-adapter#0.3.1 bower_components/ember-mocha-adapter

base64#1.0.0 bower_components/base64

ember-cli-shims#0.1.1 bower_components/ember-cli-shims
└── ember#2.7.3

pretender#1.1.0 bower_components/pretender
├── FakeXMLHttpRequest#1.4.0
└── route-recognizer#0.1.11

sinonjs#1.17.1 bower_components/sinonjs

chai#2.3.0 bower_components/chai

mocha#2.2.5 bower_components/mocha

ember#2.7.3 bower_components/ember
└── jquery#2.2.4

FakeXMLHttpRequest#1.4.0 bower_components/FakeXMLHttpRequest

route-recognizer#0.1.11 bower_components/route-recognizer

jquery#2.2.4 bower_components/jquery

bootstrap#3.3.7 bower_components/bootstrap
└── jquery#2.2.4
Cannot find module 'lodash/lang/isFunction'
Error: Cannot find module 'lodash/lang/isFunction'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/marc/Dev/github/clones/ember-simple-auth/node_modules/babel-core/lib/api/node.js:21:29)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

Confirm the example app doesn't work for my either.

@amk221 are you seeing the same error?
Cannot find module 'lodash/lang/isFunction'

That should be fixed by npm installing again - I'm not sure what's causing it or whether it's a problem with ESA at all.

I nombom'd but still get
Cannot find module 'lodash/lang/isFunction'
Error: Cannot find module 'lodash/lang/isFunction'

oh ok, weird npm install after the initial nombom did fix it.

oh ok, weird npm install after the initial nombom did fix it.

hmm not me. I'm running nombom and npm install / ember serve from the root directory of the repo. Is that wrong?

Just tried it, the second npm install makes the app working.
the output of the second npm install is
ember-simple-auth@1.2.0-beta.1 /Users/sma01/work/git/ember-simple-auth
├─┬ broccoli-asset-rev@2.5.0
│ └─┬ broccoli-filter@1.2.4
│   └─┬ broccoli-kitchen-sink-helpers@0.3.1
│     └── glob@5.0.15
├─┬ ember-cli@2.7.0
│ └─┬ broccoli-babel-transpiler@5.6.1
│   └─┬ babel-core@5.8.38
│     ├─┬ babel-plugin-proto-to-assign@1.0.4
│     │ └── lodash@3.10.1
│     ├── lodash@3.10.1
│     └─┬ regenerator@0.8.40
│       └─┬ commoner@0.10.8
│         └── glob@5.0.15
└─┬ ember-network@0.3.1
  └─┬ broccoli-templater@1.0.0
    └─┬ broccoli-filter@0.1.14
      └─┬ broccoli-kitchen-sink-helpers@0.2.9
        └── glob@5.0.15

BTW my global ember-cli version is 2.10, maybe this as to do with this.

Not an ESA issue actually.

repo: simplabs/ember-simple-auth


text: error sudo dotnet SimplCommerce.WebHost.dll

repo: simplcommerce/SimplCommerce


text:
Auto determine font paths

When using S2D_CreateText(), font family names should be accepted, much like CSS. Fonts may either be absolute paths (e.g. when distributed with an app) or names which resolve to the correct font directory on the given OS. Generic font family names should also resolve properly, e.g. "serif", "san-serif", "monospace".

Probably should be the responsibility of libraries using Simple 2D instead.


text:
Fix compiler warning in MT6835.cpp

This change fixes a warning about an implicit overflow of MT6835_REG_CAL_STATUS.
unsigned conversion from 'int' to 'uint8_t' {aka 'unsigned char'} changes value from '275' to '19' [-Werror=overflow]

Thanks for this! I think I have made the same change locally already also :-D
We only take PRs against the "dev" branch of the code, so I changed that. After the tests run I will merge it.

Perfect, thanks a lot!

repo: simplefoc/Arduino-FOC-drivers


text:
proper memory graphs

we should graph things like buffers and caches so that it is easier to see true memory usage/pressure
sample:

+1, real memory usage is pretty critical for debugging

Done.

authors: aguynamedben mihasya synack

repo: simplegeo/metartg