irb:

File.dirname("/Users/tolmasky") => "/Users"
File.driname("/Users/tolmasky/") => "/Users"

narwhal:

File.dirname("/Users/tolmasky") => "/Users"
File.driname("/Users/tolmasky/") => "/Users/tolmasky"

Complete or replace the implementation of "glob". Construct a unit test suite for "glob".

Refactor "tusk" so that packages can be installed in an autonomous virtual environment, as would be the case for a war/WEB-INF for Google AppEngine. "tusk install" and "tusk reheat" should have options to install packages in a virtual environment regardless of whether they have already been installed elsewhere on the module search path.

Add a feature or refactor "tusk" such that packages can be installed in a virtual environment in a "lean" fashion, meaning that only the essential directory trees are installed. This will become necessary for quota-encumbered virtual environments like war/WEB-INF for Google AppEngine.

Installing lean packages should be an option for both "tusk install" and "tusk reheat", which would install all packages in a lean fashion from the missing transitive dependencies in the package.json for the virtual environment.

Package maintainers would have the option of specifying in their "package.json" which directories are necessary for autonomous functionality, as a white list, usually omitting such directories as "tests", "examples", "docs", and "src". The default behavior would be to install all files.

Refactor the sandboxing module such that file system module loaders can discover a canonical top level identifier for any give path and the module search paths by discovering whether the module's path is within any of the module search paths and using the shortest possible route to reconstruct the corresponding top level identifier.

For example, given that the module search path is ["/usr/lib/js/packages/jack/lib", "/usr/lib/js"], the top level id for "/foo.js" would be the absolute id, "/foo.js", whereas the top level id, reverse engineered from the path to the program module given at the command line, for a path of "/usr/lib/js/packages/jack/lib/jackup.js" would be merely "jackup".

This feature would resolve the infrequent occurrence of reloading a cyclic dependency within the program module or modules loaded relatively therefrom.

Add support to the args module for options interleaved among arguments, preserving the respective execution order of the argument actions and option actions. Presently, all options must be specified before any arguments, as in:

tusk clone --user kriskowal --owner nitro

As opposed to the following terminal option syntax that is not yet supported:

tusk install nitro --force

Implement support for package versions in Tusk. Add support for dependency version predicates in package.json. Add support for installing multiple and specific versions of packages both in the system Narwhal packages and in virtual environment packages, and provide a tool for selecting versions. Write tusk freeze such that it records the versions of all de facto installed packages. Refactor tusk reheat to use the information recorded by tusk freeze to grab exact versions. Refactor lib/packages.js to verify dependency predicates. Consider adding a feature to inspect the graph of installed package versions and their dependencies to recommend the most current inter-compatible group of package versions as described by their package.json dependency predicates.

In package.json presently, .jars should be an array (or an array of one string) containing paths from the package.json file to any number of .jar files, or directories containing .jars. If it refers to a directory, the package loader should normalize that entry to a list of the jars in that directory. After normalization, the list of individual .jar files should be available as .jars.

Add support for packages that have a build step. Create a system for transactionally downloading packages and their transitive dependencies, then unbundling, building, generating documentation, and testing, within a virtual environment before installing the results into the system or virtual environment packages directory.

Consider making an installation transaction resumable if errors occur at any particular stage.

When Java is installed on Windows, it deals internally with Windows file system paths, even when it is running in Cygwin. So, there's a bit of confusion about when Narwhal should be operating on Windows paths and when it should be working on Unix paths. Cygwin will need an interoperability layer between Java and the File System API.

Create a build system and module loaders for the browser.

Support:

• production: performance (minification, bundling, browser cache induction, parallelism)
• development: preserves line numbers and file names
• static: built with a tool and saved as static files
• dynamic: served by a JSGI application on demand, with an LRU Cache
• sync
• async

Methods:

• via async XHR: no global footprint, but restricted to same origin.
• via sync XHR: great for development on static files, but slow, serial, and buggy in production, and also lacks file names for debugging in browsers.
• via inline script; embeds a bundle so subsequent may require modules.
• via blocking download script; downloads a bundle so subsequent may require modules.
• via deferred script injection; downloads a bundle or individual modules asynchronously. sync require not available for these modules in subsequent , so it must throw programmer errors or use an alternate, dangerous sync XHR loader for those cases.

Consider:

• bundling speeds up initial page loads, but collections of smaller files cache better for faster following page loads
• browser cache induction uses mtime-based unique identifiers with far-future expiration
• file names and line numbers can be preserved by module factories that do not inject newlines at the head and foot of the module, if the factories are installed with script injection.
• if modules are loaded from multiple small files, those components can be loaded in parallel, as with labjs. however, if modules are loaded asynchronously in non-deferred script tags, subsequent inline script tags will not be able to synchronously require those modules.
• after downloading a bundle, the client may initiate the download of the smaller factories for pre-caching; this only works if the modules are cacheable. the server must track whether it expects the browser to have downloaded the smaller factories to decide whether to send the bundle loader or module loader in subsequent requests.

Tusk tracks all files installed for each package in a .tusk/notes.json in the base of the system Narwhal installation or presently activated virtual environment, along with whether the package was installed in response to a explicit user request (as opposed to implicitly as a transitive dependency), and whether the installation completed. The intent for these notes is to eventually implement tusk remove for removing packages and all the files they drop, and tusk orphans | xargs tusk remove for garbage collecting unwanted packages. Presently, tusk creates symbolic links in the $PACKAGE_HOME/bin to each package's bins, but these are not tracked in .tusk/notes.json yet.

Implement package removal with tusk remove. This should employ .tusk/notes.json to remove all files installed by tusk. Some decision will have to be made about whether to destroy the entire package's tree or to leave any remaining, untracked files in the package's abandoned husk.

For the purpose of garbage collecting unwanted packages, implement tusk orphan, using .tusk/notes.json to discover whether any of the installed packages were installed as transitive dependencies of explicitly installed packages that have since been removed by the user.

lib/packages.js performs a topological sort of all installed packages. Presently, an error occurs if there is a cyclic dependency in any subgraph, for example, if "jack-servlet" and "appengine-java-sdk" are erroneously mutually dependent. Detect this case in lib/packages.json and during tusk create-catalog to avoid distributing faulty package catalogs.

Add a feature that permits a virtual environment or system Narwhal installation to subscribe to alternative and multiple package catalogs or catalog sources.

Perform the necessary migration steps to the ServerJS Unit Test API when that specification stabilizes.

Create a JSGI application and static complication tools that create and serve a group of module factories as a single, minified, compressed bundle for loading with a

Allow setting of default charset

Implement a promise-based asynchronous require for dynamically named module requests using either asynchronous XHR and eval (with no global footprint) or script injection (with a global module factory registration system).

Gather requirements and implement a JSON command line interface, suitable for transferring data to and from JSON for use in conjunction with other command line tools through pipelines.

Create a Base32 encoding module based off of Doug Crockford's alphabet and RFC 3548 for Python interoperability by default.

The util module presently has strong testing for its array, object, and string extend features. Most remaining features require unit tests.

Problem seen on Mac OS 10.5 with 0.1-RC2.

Steps to reproduce:

• tusk init foo
• cd foo
• ls -al bin

Expected: bin/activate should be a symlink to activate.bash
Actual: the symbolic link is line noise

Several of the unit test cases for scientific notation of floating point values do not presently conform to the unit test suite, and thus Python interoperability.

On repeated applications it returns different hashes for the same input string.

Does not work. It seems to be not implemented.

Looks like something broke with 46f31ce.

narwhal$ rm -rf .tusk/
narwhal$ git checkout <a href="/tlrobinson/narwhal/commit/72dfc8054febce04e6c4808fd43f4822b3d27159">72dfc80</a>
HEAD is now at 72dfc80... Add 'xterm' to make term module work on Ubuntu/Gnome.
narwhal$ tusk install foo
Downloading catalog.
Saving catalog.
ERROR: Package not found: "foo"
No new packages to install.
narwhal$ rm -rf .tusk/
narwhal$ git checkout <a href="/tlrobinson/narwhal/commit/46f31ce5609120703d314466379fe5570f9e3db7">46f31ce</a>
Previous HEAD position was 72dfc80... Add 'xterm' to make term module work on Ubuntu/Gnome.
HEAD is now at 46f31ce... Added a Java version check to narwhal-rhino.
narwhal$ tusk install foo
tusk update does not yet take arguments.

I think I'm only seeing the problem when I don't have a .tusk directory. I'm also going a little nuts so I may be missing something obvious.

Preserve enumerability for engines on which it is possible to use Object.defineProperty. Use the Object.defineProperty stub.

http://groups.google.com/group/narwhaljs/browse_thread/thread/6cb08191f6617e8e

To conform with the ratified http://wiki.commonjs.org/wiki/Modules/Meta

Upgrade Jack to use WebWorkers for safer shared-nothing event-loop concurrency. I have implemented worker support in the simple and jetty servlet handler at:
http://github.com/kriszyp/jack
(I also upgraded the simple and servlet handlers that I rewrote to users workers and promises to roughly the current direction for JSGI 0.3. Figured I might as well while I was hacking on them.)

As far as I can see while playing with tusk all the non-included engines are installed to the packages directory (not sure if it's a right behavior though), while enginePrefix points to the non existing path narwhal.js:58. This way you can obtain circular module require's between default/system and logger (That's what I had with xulrunner engine), unless first element in the system.prefixes points to the engines folder. But even in this case it seems to be consequence rather then expected behavior. I also found that it causes a bug on xulrunner engine cause in order to bootstrap worker I need a path to the engines bootstarp, but fs(system.enginePrefix).join("bootstrap.js") doesn't exists as it points to the directory engines/xulrunner/bootstarp.js while it suppose to point to packages/narwhal-xulrunner/bootstarp.js.

There is also different thing. Structure of the xulrunner-engines extension looks like:

bootsrap.js
packages.json
lib
    ....
narwhal
    engines
    packages
    ...

Take in mind that xulrunner engine is nor in narwhal/engines nor in narwhal/packages there for it can be constructed by narwhal.js. I would suggest to assign value system.enginePrefix in the bootstrap.js of the engine instead this was problem will be solved. I don't want to create patch as I'm not sure weather or not I'm missing something if not let me know so I'll make a patch. BTW all the engines would have to apply these on their side as well.

Should be pretty trivial to copy gem's behavior of simply first checking whether the file exists in the present working directory, and if it doesn't then hitting the internet.

tusk install blah
if (FILE.exists(blah))
//install from that file.

This isn't actually a bug but a feature request ;)

This isn't urgent as I can currently host my packages in catalog.json but it would be very nice. cdorn has multiple catalog support in his tusk-catalog branch but I am not sure how long it will take integrate that into master

I created a new package.json for "Jesyll", with dependencies ["markdown", "jsontemplate"], since I know I'll depend on those.

I then ran the program, and it said "can't find jesyll". And I tried with -d and -v and couldn't really see what the issue is. I was stuck on this and trying to compare with other packages until I figured out it's probably those nonexistent dependencies.

A nicer error message would be "can't find jsontemplate declared in jesyll/package.json". -v or -d could list the paths being searched too, like PYTHONVERBOSE=1 does.

tlrobinson said: While we're at it we should try to solve the OpenJDK problem once and for all. I have yet to find a combination of Rhino and the -Xbootclasspath/p: option that works.

js> system.fs.path(".").join("foo")
/foo

Currently the Narwhal loaders are all based on the filesystem. A module must be in the filesystem in one of the search paths. We need to add hooks to allow a loader to provide "virtual" search paths (for lack of a better term), which map module ids to module factories. This will allow things like modules compiled into the binary, zips, jars, etc.

http://groups.google.com/group/narwhaljs/browse_thread/thread/d812af07b3c6d4c6?hl=en

Currently the narwhal/repl module blocks while waiting for input, preventing other events from taking place. http://github.com/kriszyp/narwhal/commit/e52839226df3709d9c39058603d58902db22bf56 fixes this so that the input is accepted through a worker that fires events in the main repl module, thus the event loop can run while waiting user input.

readline should use the Rhino's shell input, rather than going directly to jline, so that
jline works in both debugger and command line:
http://github.com/kriszyp/narwhal/commit/7bbdce2ed704503f0156ef6a59da08a801a722df

I'm trying to setup Narwhal on windows using the directions from http://narwhaljs.org/quick-start.html but I run into a problem when I try to run tusk init hello-web
Here are my steps:
1. Clone git://github.com/280North/narwhal.git to C:\gited\narwhal
2. Add C:\gited\narwhal\bin to my path
3. cd to C:\gited
4. run "narwhal.cmd narwhal\examples\hello" this returns "Hello, World!"
5. run "narwhal.cmd narwhal\examples\narwhal" I see the narwhal, very pretty.
6. still following the quick start guide i run "narwhal --help" this gets the listing of narwhal commands
7. I then run "tusk init hello-web" This is where things start to go wrong.

the following directory structure is created at C:\gmosx

hello-web
  tusk
   bin
     sea
   lib

but I get the following error

org.mozilla.javascript.WrappedException: Wrapped java.io.IOException: 
Cannot run program "chmod": CreateProcess error=2, 
The system cannot find the file specified (C:\Gited\narwhal\engines \rhino\lib\os-engine.js#48) 
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1776) 
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:183) 
at org.mozilla.javascript.NativeJavaMethod.call (NativeJavaMethod.java:247) 
at org.mozilla.javascript.Interpreter.interpretLoop (Interpreter.java:1688) 
at script(C:\Gited\narwhal\engines\rhino\lib\os-engine.js:48) 
at script(C:\Gited\narwhal\engines\rhino\lib\os-engine.js:58) 
at script(C:\Gited\narwhal\lib\os.js:23) 
at script(C:\Gited\narwhal\engines\rhino\lib\file-engine.js: 123) 
at script(C:\Gited\narwhal\lib\file.js:603) 
at script(C:\Gited\narwhal\lib\narwhal\tusk\init.js:35) 
at script(C:\Gited\narwhal\lib\args.js:99) 
at script(C:\Gited\narwhal\lib\args.js:474) 
at script(C:\Gited\narwhal\lib\narwhal\tusk.js:163) 
at script(\C:\Gited\narwhal\bin\tusk:2) 
at script(C:\Gited\narwhal\bin\../lib/sandbox.js:250) 
at script(narwhal.js:209) 
at org.mozilla.javascript.Interpreter.interpret (Interpreter.java:845) 
at org.mozilla.javascript.InterpretedFunction.call (InterpretedFunction.java:164) 
at org.mozilla.javascript.optimizer.OptRuntime.callName (OptRuntime.java:97) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1._c_anonymous_1 (Unknown Source ) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1.call (Unknown Source) 
at org.mozilla.javascript.optimizer.OptRuntime.call2 (OptRuntime.java:76) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1._c_script_0 (Unknown Source) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1.call (Unknown Source) 
at org.mozilla.javascript.ContextFactory.doTopCall (ContextFactory.java:405) 
at org.mozilla.javascript.ScriptRuntime.doTopCall (ScriptRuntime.java:3066) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1.call (Unknown Source) 
at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_ js_1.exec (Unknown Source) 
at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:563) 
at org.mozilla.javascript.tools.shell.Main.processFileSecure (Main.java:485) 
at org.mozilla.javascript.tools.shell.Main.processFile (Main.java:451) 
at org.mozilla.javascript.tools.shell.Main.processSource (Main.java:443) 
at org.mozilla.javascript.tools.shell.Main.processFiles (Main.java:196) 
at org.mozilla.javascript.tools.shell.Main$IProxy.run (Main.java:117) 
at org.mozilla.javascript.Context.call(Context.java:517) t org.mozilla.javascript.ContextFactory.call (ContextFactory.java:514) 
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:179) 
at org.mozilla.javascript.tools.shell.Main.main(Main.java:157) 
Caused by: java.io.IOException: Cannot run program "chmod": 
CreateProcess error=2, The system cannot find the file specified 
at java.lang.ProcessBuilder.start(Unknown Source) 
at java.lang.Runtime.exec(Unknown Source) 
at java.lang.Runtime.exec(Unknown Source) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
at java.lang.reflect.Method.invoke(Unknown Source) 
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161) 
... 24 more 
Caused by: java.io.IOException: CreateProcess error=2, The system 
cannot find the file specified 
at java.lang.ProcessImpl.create(Native Method) 
at java.lang.ProcessImpl.<init>(Unknown Source) 
at java.lang.ProcessImpl.start(Unknown Source) 
... 32 more 

Now I know almost nothing about Linux but I do understand that chmod is a permission thing. I looked into narwhal\lib\narwhal\tusk\init.js and saw the only mention of chmod is on line line 35 where it says

sea.chmod(0755); 

I was trying to run

tusk.cmd help 

but i get the following error:

C:\Gited\280North\narwhal>tusk.cmd help
Usage: help [OPTIONS] COMMAND
A Narwhal project package manager.
require error: couldn't find "C:\Gited\280North\narwhal\lib\narwhal\tusk.js\list"

I looked at tusk.js and found

parser.command('list', module.id + '/list');

if i replace this with

parser.command('list', C:/Gited/280North/narwhal/lib/narwhal/tusk' + '/list');

The example works. Obviously you can't hard code the file path, but I couldn't find where module.id was set to override the windows behaviour.

I'm running Windows XP SP3

The zip module does not have a close method, and so calling unzip leaves the file in an open/locked state. Fix is here:
http://github.com/kriszyp/narwhal/commit/27b49bfe9c5372f820f3130d302606b797f8c24a

I think that the target module of a worker (the one indicated in the Worker constructor) should be able to detect that it is the initial module, presumably with (module.id == require.main). In worker.js I have tried setting workerGlobal.require.main = scriptName, but that does not seem to affect the require.main that is provided to the modules in the worker environment. I am not sure how one is supposed to set require.main.

Pull request:
util_refactor branch is here: http://github.com/nrstott/narwhal/tree/util_refactor

Discussion here: http://groups.google.com/group/narwhaljs/browse_thread/thread/233a8b1e73b66651

The commit is here: http://github.com/zaach/narwhal/commit/a5c4aa58828c0f3db6814bac0f27694dc3079c76

I'm running the 280 North fork on Windows XP
When I try to run the jack samples I get the following

Loading configuration module at C:\Gited\bar\jackconfig.js
TypeError: Argument 0 is not Java class: [JavaPackage org.simpleframework.http.core.Container].
org.mozilla.javascript.EcmaError: TypeError: Argument 0 is not Java class: [JavaPackage org.simpleframework.http.core.Container].
C:\Gited\narwhal\packages\jack\lib\jack\handler\simple.js#13)
    at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3659)
    at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3637)
    at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3665)
    at org.mozilla.javascript.ScriptRuntime.typeError2(ScriptRuntime.java:3684)
    at org.mozilla.javascript.JavaAdapter.js_createAdapter(JavaAdapter.java:173)
    at org.mozilla.javascript.JavaAdapter.execIdCall(JavaAdapter.java:126)
    at org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:129)
    at org.mozilla.javascript.BaseFunction.construct(BaseFunction.java:338)
    at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1735)
    at script(C:\Gited\narwhal\packages\jack\lib\jack\handler\simple.js:13)
    at script.main(C:\Gited\narwhal\packages\jack\lib\jackup.js:131)
    at script(\C:\Gited\narwhal\packages\jack\bin\jackup:2)
    at script(C:\Gited\narwhal\bin\../lib/sandbox.js:251)
    at script(narwhal.js:205)
    at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:845)
    at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
    at org.mozilla.javascript.optimizer.OptRuntime.callName(OptRuntime.java:97)
    ato rg.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1._c_anonymous_1(Unknown Source)
    at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1.call(Unknown Source)
    at org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:76)
    at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1._c_script_0(Unknown Source)
    at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1.call(Unknown Source)
    at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:405)
    at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3066)
    at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1.call(Unknown Source)
    at org.mozilla.javascript.gen.C__Gited_narwhal_engines_rhino_bin____bootstrap_js_1.exec(Unknown Source)
    at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:563)
    at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:485)
    at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:451)
    at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:443)
    at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:196)
    at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:117)
    at org.mozilla.javascript.Context.call(Context.java:517)
    at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:514)
    at org.mozilla.javascript.tools.shell.Main.exec(Main.java:179)
    at org.mozilla.javascript.tools.shell.Main.main(Main.java:157)

In the past I was able to fix this by setting my NARWHAL_CLASSPATH to C:\Gited\narwhal\packages\jack\jars\simple-4.1.10.jar but it no longer works.

In engines/rhino/lib/zip.js line 30:

throw new StopIteration();

should be

throw StopIteration;

When I turn Jack's reloader functionality on, I get this error when I call the resource function in the packages module:
TypeError: Cannot read property "length" from undefined

at C:\dev\narwhal\lib\packages.js:9

Consider implementing forEach on Binary streams in terms of read(null) (for read up the the default buffer length and execute a block with the result).

The read function from file.read in loader.js always comes from bootstrap.js instead of file.js.

This makes it impossible to create a loader (to be passed into a sandbox) that makes use of the file.js module.