Swimming with Narwhal(s)
Hannes Wallnoefer
the last few days I worked on making RingoJS more compatible with
Narwhal and Tusk (Narwhal's package manager), and I'm happy to say I
came pretty far - most of tusk and most of the packages in the catalog
are working, albeit currently with a special "narwhal compatibility
mode" that entails some tweaks to the engine and some modules. You can
read about it here:
Of course, the goal is to be able to use tusk without a special
compatibility mode, and to be able to maintain and install ringo-
related projects available as packages - both things we may split of
current ringo development (storable, hibernate, berkeley, webapp,
markdown...) and of course third party projects.
So in order to overcome narwhal compatibility mode and get this
feature into the main repository soon, here's the list of current
workarounds in narwhal compat mode:
* Allowing .js extension in module ids. The module spec (as I
understand it) says this isn't allowed, but narwhal allows it, and it
is used in some places. We can probably solve that, either by getting
consensus on the meaning of the module spec or by providing fixes for
the narwhal code in question.
* Using the __parent__ and __proto__ properties to access the parent
scope and prototypes of objects. This is disabled in ringo by
default , and used somewhere in tusk i think. Also not a big problem,
we can probably sort it out one way or the other.
* Adding the main script's parent directory to the module search path.
This is probably the biggest problem to overcome. I've become
sceptical of this ringo feature as well, because it breaks the use of
having an executable javascript file starting with #!/usr/bin/env
narwhal|ringo in a bin directory - ringo will put the bin directory on
the module search path, which is hardly what you want. On the other
hand, some ringo code now depends on this, for example the typical
webapp main.js won't work in narwhal mode because of this. Still,
medium term I tend towards making narwhal's behaviour the default in
ringo.
* Finally, there's a narwhal-shim.js bootstrap script that is run at
startup in narwhal mode: <http://github.com/hns/ringojs/blob/master/
modules/narwhal-shim.js>. This also isn't a big issue. Mostly it
tweaks some core modules and the require function to look like the
ones in narwhal. I don't have a big problem with adding most of these
by default, and long term commonjs standardization should make this
problem go away.
* Another issue, although not strictly related to narwhal
compatibility mode: Some of the standard modules in Narwhal (and
Ringo) are rather outdated. For example the "file" module still uses
the names from several spec revisions back. By becoming dependent on
narwhal/tusk, it becomes harder to update these. We'll either have to
move in lock-step with narwhal regarding standard commonjs modules,
maintain our own fork of narwhal/tusk, or convince the narwhal folks
to follow us when we update. Not a big issue, but worth being
considered.
I'm looking forward to hearing your thoughts on this!
Hannes
George Moschovitis
I believe Narwhal's Rhino engine is neglected lately, this
compatibility mode may be a great boost to both projects.
> * Allowing .js extension in module ids. The module spec (as I
> understand it) says this isn't allowed, but narwhal allows it, and it
> is used in some places.
I think .js extensions should be allowed, but the narwhal code should
be updated to remove these extensions.
Perhaps you could send a patch?
> Still, medium term I tend towards making narwhal's behaviour the default in
> ringo.
Nice.
> maintain our own fork of narwhal/tusk
Bad idea.
regards,
-g.
Hannes Wallnoefer
repository at <http://github.com/ringo/ringojs>! I updated the guide
on the wiki:
I was able to sort out most issues after all. We now have a few
narwhal compatibility hooks in our standard modules such as io.IO
being an alias for io.Stream.
The only major change I made is that the main script directory is no
longer added to the module search path automatically. I believe this
is a good change in the long run. I added a non-standard "directory"
property to the module object so you can easily restore old behaviour
using "require.paths.unshift(modules.directory)".
We are currently passing 414 tests from the narwhal test suite
compared to 501 tests passed by narwhal, and I could increase that to
469 locally by copying glob functionality from narwhal's file module
and a few tweaks to our stream class.
Also, Ringo packages have started to appear in various github
repositories, so things are looking really good. I'm looking forward
to hearing from you!
Hannes