Narwhal2 - Narwhal and Jack

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Narwhal2
Received-SPF: pass (google.com: domain of rfo...@gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:to:message-id:in-reply-to:references:subject:x-mailer
         :mime-version:content-type:content-transfer-encoding;
        b=uVh9LTzWuA4oAM0VSCGPDg0Ln9i9A0l3Z017ffQFqWPnEvmk9zVbwWAt3LobK1MzbI
         YIxDoQ3NxcJEWPlZFGwVtNvE/df9YtQXFu0hdILTcP+ulscjNAwkjqWcXWq9tOsWGExa
         gh0oVmQZ4bT0oARHWdv7gvEXpeHD/1YQQRkyI=
Date: Thu, 14 Apr 2011 12:28:48 +0200
From: Irakli Gozalishvili <rfo...@gmail.com>
To: narwhaljs@googlegroups.com
Message-ID: <51A5C7AB8BE94DF28B8724208C723...@gmail.com>
In-Reply-To: <BANLkTinLJC0Vh1_0yOKiXZrwiADOtZR...@mail.gmail.com>
References: <4D94C697.4080...@christophdorn.com>
 <EF65BB13-DCBA-4936-A8DE-FACD11D1F...@gmail.com>
 <4D9B52A6.2090...@christophdorn.com>
 <BANLkTinLJC0Vh1_0yOKiXZrwiADOtZR...@mail.gmail.com>
Subject: Re: [narwhal] Narwhal2
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4da6cc60_7ba207f7_117"
Content-Transfer-Encoding: 8bit

--4da6cc60_7ba207f7_117
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

I like rebirth of narwhal as long as this time around it will be set of micro-libs that work on X platforms rather then one big monolith runtime that supports diff engines.

I think it will be nice if narwal2 will be what commonjs was intended to be, set of specs and cross engine implementations. 

Cheers!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

On Wednesday, 2011-04-06 at 05:17 , Tom Robinson wrote: 
> On Tue, Apr 5, 2011 at 10:34 AM, Christoph Dorn
> <christoph...@christophdorn.com> wrote:
> > On 11-04-04 6:45 PM, Tom Robinson wrote:
> > > 
> > > Kris Kowal and I are interested in "rebooting" the Narwhal project as a
> > > set of loosely coupled components (narwhal-lib, loaders, engines, etc). I
> > > think it would align with your goal of using PINF. I'm interested to hear
> > > what you'd like to see in Narwhal2 (or whatever it will be called).
> > 
> > My goal is to be able to *easily* use narwhal modules cross-platform without
> > needing to boot my app with narwhal.
> 
> Sounds like a good goal, though it's not going to be my only goal.
> 
> > 
> > I want to simply be able to map narwhal:
> > 
> > package.json ~ {
> > "mappings": {
> > "narwhal": "http://narwhal/"
> > }
> > }
> > 
> > And use modules with:
> > 
> > require("narwhal/util");
> > require("narwhal/file");
> > 
> > Where platform/engine specific code would be automatically loaded if needed
> > by a module.
> > 
> > With PINF I have the ability to resolve the following require:
> > 
> > require("./platforms/{platform}/node/module");
> > 
> > Where "{platform}" gets replaced with the value of 'require.platform' which
> > is sufficient to load platform-specific code.
> > 
> > I think narwhal2 should consist of all modules + engine code in one project
> > vs having engine code in external projects. This will make it easier to
> > compare feature support for various engines, share modules in various ways
> > between engine code and long-term provide the ability to reduce the
> > engine-specific code to the foundation modules that CommonJS will specify.
> 
> That's also probably a good idea. There's not a great reason for them
> to be separate, except to allow 3rd parties to add their own engines
> without our blessing, but they could still do that and have an
> installation script to copy/symlink their engine into your narwhal
> installation until we get it merged.
> 
> > 
> > I have started using the following directory layout:
> > 
> > lib/<narwhal-lib modules>
> 
> Why not lib/narwhal/<narwhal-lib modules> like it currently is?
> 
> > lib/commonjs/ <- for specified APIs
> 
> I like this, it solves the problem of certain platforms providing
> modules with naming conflicts with CommonJS. It also has the benefit
> that if you only use APIs under the "commonjs" namespace your code is
> guaranteed to work on any CommonJS platform that fully implements the
> APIs (in theory, of course). It does make CommonJS appear less
> important than the native modules the platform provides, but I'm ok
> with that at this point.
> 
> > lib/platform/<platform>/ <- engine specific code
> > 
> > Combine this with "{platform}" in require() and you have everything you need
> > to satisfy the requirements of the narwhal modules and can run this on any
> > supporting loader.
> > 
> > My goal is to contribute a continuous integration setup where we can test
> > all modules against all platforms. Once this is setup there is no reason why
> > narwhal cannot become the most portable utility library for JS and lead the
> > CommonJS spec process by implementation.
> > 
> > I am less interested in what narwhal provides in terms of it's package and
> > loader support unless we can bring it up to speed with the mappings spec or
> > provide sufficient hooks so I can splice in my own resolution logic. This
> > may actually be a good exercise to boil the core loader down to it's minimum
> > + plugin API. With PINF I use BravoJS for the core loader and extend it with
> > various plugins to implement the CommonJS package and mappings specs. If
> > narwhal can implement the same plugin interfaces with a different internal
> > implementation we are one spec closer to have a portable loader plugin API.
> 
> I would like for Narwhal to be something you can download and run out
> of the box, you shouldn't have to go get a loader/etc from somewhere
> else.
> 
> However we all have different ideas of what the best loader
> implementation and extensions look like, so it would be nice if the
> loader could be swapped out. That means Narwhal shouldn't rely on any
> extensions to CommonJS and it should be easy to swap in different
> loaders for different environments and maybe even use an existing
> platform's loader (Node or Rhino or whatever).
> 
> Narwhal is basically:
> 
> 1) JavaScript engine + some combination of shell scripts, JavaScript
> code, and native code for bootstrapping into (2) and possibly (3)
> 2) CommonJS loader
> 3) command-line bootstrapping code, including argument parsing, etc
> 4) platform-specific standard library bindings
> 5) pure JavaScript standard libraries
> 
> I'd like for each of these to be de-coupled as much as possible.
> 
> 1) Support several popular engines/platforms out of the box. Browsers,
> Node.js, Rhino, Jetpack, etc.
> 2) Include a basic loader but be able to easily swap it out for other loaders.
> 3) Optional, especially for embedded environments like the browser,
> Jetpack (?), Rhino embedded in an application or webserver, etc.
> 4) Depends on (5) but nothing else
> 5) Should be able to run this in ANY CommonJS environment without the
> rest of Narwhal. Perhaps requires separating into platform APIs
> (file/network/etc) and pure JS utilities (args, etc)
> 
> > One thing the narwhal loader system has that BravoJS does not is the ability
> > to easily create sub-namespaces via sandboxes. Sandboxes are also a concept
> > that I think would benefit from more rigid specification long-term. I am not
> > quite sure yet how deep they need to reach into the loader or how that can
> > be best achieved with minimal changes to a loader. I hope to implement
> > Sandboxes for BravoJS soon and will know more once that is done.
> 
> All the loaders Kris K and I have written (after my initial one) have
> been designed with this in mind. Basically you just need to
> encapsulate everything in a "sandbox" object, never rely on globals. A
> simple way to do that is just wrap your entire loader in function that
> returns the root "require" function and call it "Sandbox" :)
> 
> Standardizing an API for creating new module loader sandboxes is a
> good idea and probably will be part of the effort to make loaders
> swappable in Narwhal2.
> 
> > 
> > So overall I am in complete support of a reboot and am willing to contribute
> > time and resources to address project quality, docs and consistency. When it
> > comes to porting the engine code I really need some help as all the binary
> > stuff and how that fits into the various platforms is way over my head. I
> > can contribute the 'jetpack' engine as I am most familiar with it and can
> > pull code from various places. How the binary stuff fits into that we can
> > discuss.
> > 
> > I think we could have this up and running fast. We just need to get the
> > basics setup and working on the popular platforms and can tweak from there.
> > 
> > Christoph
> > 
> > 
> > > (I can't actually help with your problem. Kris can though)
> > > 
> > > -tom
> > > 
> > > On Mar 31, 2011, at 11:23 AM, Christoph Dorn wrote:
> > > 
> > > > I started porting narwhal-lib and associated engine files to a new
> > > > project that will run cross-platform on my PINF JS Loader [1].
> > > > 
> > > > I chose to do this as a new project to:
> > > > 
> > > > * Combine common and engine-specific modules in same package
> > > > * Remove all narwhal-specific module/package/sandbox code to focus on
> > > > utility modules
> > > > 
> > > > Initial supported platforms will be: node, jetpack, rhino
> > > > 
> > > > The idea is to be able to simply include the package in an existing
> > > > program and use the various narwhal modules vs having to bootstrap the
> > > > entire application with narwhal.
> > > > 
> > > > Once I have a bit more working I'll be posting links.
> > > > 
> > > > 
> > > > __HELP__: There are a couple of modules that I cannot locate the source
> > > > code for. These are:
> > > > 
> > > > require("narwhal/iconv-embedding");
> > > > require("narwhal/buffer-embedding")
> > > > 
> > > > Where can I find the implementations for these modules?
> > > > 
> > > > Also for nodejs I am porting the code from:
> > > > 
> > > > https://github.com/kriskowal/node/tree/narwhal-master/narwhal/lib
> > > > 
> > > > From memory, is there any reason why that node engine code should not
> > > > work with some adjustments?
> > > > 
> > > > I also found this module:
> > > > 
> > > > 
> > > > https://github.com/kriskowal/node/blob/6e7b1c6bc592b8454d821f9a0474a327f997be6c/narwhal/lib/node/buffer.js
> > > > 
> > > > that refers to:
> > > > 
> > > > require("node/buffer-embedding")
> > > > 
> > > > that I cannot locate.
> > > > 
> > > > Thanks
> > > > Christoph
> > > > 
> > > > [1] - https://github.com/pinf/loader-js
> > > > 
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > > "Narwhal and Jack" group.
> > > > To post to this group, send email to narwhaljs@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > narwhaljs+unsubscribe@googlegroups.com.
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/narwhaljs?hl=en.
> > 
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Narwhal and Jack" group.
> > To post to this group, send email to narwhaljs@googlegroups.com.
> > To unsubscribe from this group, send email to
> > narwhaljs+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/narwhaljs?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "Narwhal and Jack" group.
> To post to this group, send email to narwhaljs@googlegroups.com.
> To unsubscribe from this group, send email to narwhaljs+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/narwhaljs?hl=en.
> 

--4da6cc60_7ba207f7_117
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>
            <div>
                <span>I like rebirth of narwhal as long as this time arou=
nd it will be set of micro-libs that work on X platforms rather then one =
big monolith runtime that supports diff engines.</span></div><div><span><=
br></span></div><div><span>I think it will be nice if narwal2 will be wha=
t commonjs was intended to be, set of specs and cross engine implementati=
ons. &nbsp;&nbsp;<br>
                </span>
                <span><br>Cheers=21<br><span style=3D=22color:rgb(153, 15=
3, 153)=22>--</span><br style=3D=22color:rgb(153, 153, 153)=22><span styl=
e=3D=22color:rgb(153, 153, 153)=22>Irakli Gozalishvili</span><br style=3D=
=22color:rgb(153, 153, 153)=22><span style=3D=22color:rgb(153, 153, 153)=22=
>Web: <a style=3D=22color:rgb(153, 153, 153)=22 href=3D=22http://www.jedi=
toolkit.com/=22 target=3D=22=5Fblank=22>http://www.jeditoolkit.com/</a></=
span><br style=3D=22color:rgb(153, 153, 153)=22><span style=3D=22color:rg=
b(153, 153, 153)=22></span><span style=3D=22color:rgb(153, 153, 153)=22>A=
ddress: <a href=3D=22http://goo.gl/maps/3CHu=22 target=3D=22=5Fblank=22>2=
9 Rue Saint-Georges, 75009 Paris, =46rance</a></span><br><br></span>
               =20
                <=21-- <p style=3D=22color: =23a0a0a0;=22>On Wednesday, 2=
011-04-06 at 05:17 , Tom Robinson wrote:</p> -->
                <p style=3D=22color: =23a0a0a0;=22>On Wednesday, 2011-04-=
06 at 05:17 , Tom Robinson wrote:</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div>On Tue, Apr 5, 2011 at 10:34 AM, Chri=
stoph Dorn<br>&lt;<a href=3D=22mailto:christoph-gg=40christophdorn.com=22=
>christoph-gg=40christophdorn.com</a>&gt; wrote:<br><blockquote type=3D=22=
cite=22><div>On 11-04-04 6:45 PM, Tom Robinson wrote:<br><blockquote type=
=3D=22cite=22><div><br>Kris Kowal and I are interested in =22rebooting=22=
 the Narwhal project as a<br>set of loosely coupled components (narwhal-l=
ib, loaders, engines, etc). I<br>think it would align with your goal of u=
sing PIN=46. I'm interested to hear<br>what you'd like to see in Narwhal2=
 (or whatever it will be called).<br></div></blockquote><br>My goal is to=
 be able to *easily* use narwhal modules cross-platform without<br>needin=
g to boot my app with narwhal.<br></div></blockquote><br>Sounds like a go=
od goal, though it's not going to be my only goal.<br><br><blockquote typ=
e=3D=22cite=22><div><br>I want to simply be able to map narwhal:<br><br>p=
ackage.json =7E =7B<br>&nbsp;=22mappings=22: =7B<br>&nbsp; &nbsp;=22narwh=
al=22: =22<a href=3D=22http://narwhal=22>http://narwhal</a>/=22<br>&nbsp;=
=7D<br>=7D<br><br>And use modules with:<br><br>&nbsp;require(=22narwhal/u=
til=22);<br>&nbsp;require(=22narwhal/file=22);<br><br>Where platform/engi=
ne specific code would be automatically loaded if needed<br>by a module.<=
br><br>With PIN=46 I have the ability to resolve the following require:<b=
r><br>&nbsp;require(=22./platforms/=7Bplatform=7D/node/module=22);<br><br=
>Where =22=7Bplatform=7D=22 gets replaced with the value of 'require.plat=
form' which<br>is sufficient to load platform-specific code.<br><br>I thi=
nk narwhal2 should consist of all modules + engine code in one project<br=
>vs having engine code in external projects. This will make it easier to<=
br>compare feature support for various engines, share modules in various =
ways<br>between engine code and long-term provide the ability to reduce t=
he<br>engine-specific code to the foundation modules that CommonJS will s=
pecify.<br></div></blockquote><br>That's also probably a good idea. There=
's not a great reason for them<br>to be separate, except to allow 3rd par=
ties to add their own engines<br>without our blessing, but they could sti=
ll do that and have an<br>installation script to copy/symlink their engin=
e into your narwhal<br>installation until we get it merged.<br><br><block=
quote type=3D=22cite=22><div><br>I have started using the following direc=
tory layout:<br><br>&nbsp;lib/&lt;narwhal-lib modules&gt;<br></div></bloc=
kquote><br>Why not lib/narwhal/&lt;narwhal-lib modules&gt; like it curren=
tly is=3F<br><br><blockquote type=3D=22cite=22><div>&nbsp;lib/commonjs/ &=
lt;- for specified APIs<br></div></blockquote><br>I like this, it solves =
the problem of certain platforms providing<br>modules with naming conflic=
ts with CommonJS. It also has the benefit<br>that if you only use APIs un=
der the =22commonjs=22 namespace your code is<br>guaranteed to work on an=
y CommonJS platform that fully implements the<br>APIs (in theory, of cour=
se). It does make CommonJS appear less<br>important than the native modul=
es the platform provides, but I'm ok<br>with that at this point.<br><br><=
blockquote type=3D=22cite=22><div>&nbsp;lib/platform/&lt;platform&gt;/ &l=
t;- engine specific code<br><br>Combine this with =22=7Bplatform=7D=22 in=
 require() and you have everything you need<br>to satisfy the requirement=
s of the narwhal modules and can run this on any<br>supporting loader.<br=
><br>My goal is to contribute a continuous integration setup where we can=
 test<br>all modules against all platforms. Once this is setup there is n=
o reason why<br>narwhal cannot become the most portable utility library f=
or JS and lead the<br>CommonJS spec process by implementation.<br><br>I a=
m less interested in what narwhal provides in terms of it's package and<b=
r>loader support unless we can bring it up to speed with the mappings spe=
c or<br>provide sufficient hooks so I can splice in my own resolution log=
ic. This<br>may actually be a good exercise to boil the core loader down =
to it's minimum<br>+ plugin API. With PIN=46 I use BravoJS for the core l=
oader and extend it with<br>various plugins to implement the CommonJS pac=
kage and mappings specs. If<br>narwhal can implement the same plugin inte=
rfaces with a different internal<br>implementation we are one spec closer=
 to have a portable loader plugin API.<br></div></blockquote><br>I would =
like for Narwhal to be something you can download and run out<br>of the b=
ox, you shouldn't have to go get a loader/etc from somewhere<br>else.<br>=
<br>However we all have different ideas of what the best loader<br>implem=
entation and extensions look like, so it would be nice if the<br>loader c=
ould be swapped out. That means Narwhal shouldn't rely on any<br>extensio=
ns to CommonJS and it should be easy to swap in different<br>loaders for =
different environments and maybe even use an existing<br>platform's loade=
r (Node or Rhino or whatever).<br><br>Narwhal is basically:<br><br>1) Jav=
aScript engine + some combination of shell scripts, JavaScript<br>code, a=
nd native code for bootstrapping into (2) and possibly (3)<br>2) CommonJS=
 loader<br>3) command-line bootstrapping code, including argument parsing=
, etc<br>4) platform-specific standard library bindings<br>5) pure JavaSc=
ript standard libraries<br><br>I'd like for each of these to be de-couple=
d as much as possible.<br><br>1) Support several popular engines/platform=
s out of the box. Browsers,<br>Node.js, Rhino, Jetpack, etc.<br>2) Includ=
e a basic loader but be able to easily swap it out for other loaders.<br>=
3) Optional, especially for embedded environments like the browser,<br>Je=
tpack (=3F), Rhino embedded in an application or webserver, etc.<br>4) De=
pends on (5) but nothing else<br>5) Should be able to run this in ANY Com=
monJS environment without the<br>rest of Narwhal. Perhaps requires separa=
ting into platform APIs<br>(file/network/etc) and pure JS utilities (args=
, etc)<br><br><blockquote type=3D=22cite=22><div>One thing the narwhal lo=
ader system has that BravoJS does not is the ability<br>to easily create =
sub-namespaces via sandboxes. Sandboxes are also a concept<br>that I thin=
k would benefit from more rigid specification long-term. I am not<br>quit=
e sure yet how deep they need to reach into the loader or how that can<br=
>be best achieved with minimal changes to a loader. I hope to implement<b=
r>Sandboxes for BravoJS soon and will know more once that is done.<br></d=
iv></blockquote><br>All the loaders Kris K and I have written (after my i=
nitial one) have<br>been designed with this in mind. Basically you just n=
eed to<br>encapsulate everything in a =22sandbox=22 object, never rely on=
 globals. A<br>simple way to do that is just wrap your entire loader in f=
unction that<br>returns the root =22require=22 function and call it =22Sa=
ndbox=22 :)<br><br>Standardizing an API for creating new module loader sa=
ndboxes is a<br>good idea and probably will be part of the effort to make=
 loaders<br>swappable in Narwhal2.<br><br><blockquote type=3D=22cite=22><=
div><br>So overall I am in complete support of a reboot and am willing to=
 contribute<br>time and resources to address project quality, docs and co=
nsistency. When it<br>comes to porting the engine code I really need some=
 help as all the binary<br>stuff and how that fits into the various platf=
orms is way over my head. I<br>can contribute the 'jetpack' engine as I a=
m most familiar with it and can<br>pull code from various places. How the=
 binary stuff fits into that we can<br>discuss.<br><br>I think we could h=
ave this up and running fast. We just need to get the<br>basics setup and=
 working on the popular platforms and can tweak from there.<br><br>Christ=
oph<br><br><br><blockquote type=3D=22cite=22><div>(I can't actually help =
with your problem. Kris can though)<br><br>-tom<br><br>On Mar 31, 2011, a=
t 11:23 AM, Christoph Dorn wrote:<br><br><blockquote type=3D=22cite=22><d=
iv>I started porting narwhal-lib and associated engine files to a new<br>=
project that will run cross-platform on my PIN=46 JS Loader =5B1=5D.<br><=
br>I chose to do this as a new project to:<br><br>&nbsp;* Combine common =
and engine-specific modules in same package<br>&nbsp;* Remove all narwhal=
-specific module/package/sandbox code to focus on<br>utility modules<br><=
br>Initial supported platforms will be: node, jetpack, rhino<br><br>The i=
dea is to be able to simply include the package in an existing<br>program=
 and use the various narwhal modules vs having to bootstrap the<br>entire=
 application with narwhal.<br><br>Once I have a bit more working I'll be =
posting links.<br><br><br>=5F=5FHELP=5F=5F: There are a couple of modules=
 that I cannot locate the source<br>code for. These are:<br><br>&nbsp;req=
uire(=22narwhal/iconv-embedding=22);<br>&nbsp;require(=22narwhal/buffer-e=
mbedding=22)<br><br>Where can I find the implementations for these module=
s=3F<br><br>Also for nodejs I am porting the code from:<br><br>&nbsp;<a h=
ref=3D=22https://github.com/kriskowal/node/tree/narwhal-master/narwhal/li=
b=22>https://github.com/kriskowal/node/tree/narwhal-master/narwhal/lib</a=
><br><br>&nbsp;=46rom memory, is there any reason why that node engine co=
de should not<br>work with some adjustments=3F<br><br>I also found this m=
odule:<br><br><br><a href=3D=22https://github.com/kriskowal/node/blob/6e7=
b1c6bc592b8454d821f9a0474a327f997be6c/narwhal/lib/node/buffer.js=22>https=
://github.com/kriskowal/node/blob/6e7b1c6bc592b8454d821f9a0474a327f997be6=
c/narwhal/lib/node/buffer.js</a><br><br>that refers to:<br><br>&nbsp;requ=
ire(=22node/buffer-embedding=22)<br><br>that I cannot locate.<br><br>Than=
ks<br>Christoph<br><br>=5B1=5D - <a href=3D=22https://github.com/pinf/loa=
der-js=22>https://github.com/pinf/loader-js</a><br><br>--<br>You received=
 this message because you are subscribed to the Google Groups<br>=22Narwh=
al and Jack=22 group.<br>To post to this group, send email to <a href=3D=22=
mailto:narwhaljs=40googlegroups.com=22>narwhaljs=40googlegroups.com</a>.<=
br>To unsubscribe from this group, send email to<br><a href=3D=22mailto:n=
arwhaljs+unsubscribe=40googlegroups.com=22>narwhaljs+unsubscribe=40google=
groups.com</a>.<br>=46or more options, visit this group at<br><a href=3D=22=
http://groups.google.com/group/narwhaljs=3Fhl=3Den=22>http://groups.googl=
e.com/group/narwhaljs=3Fhl=3Den</a>.<br></div></blockquote></div></blockq=
uote><br>--<br>You received this message because you are subscribed to th=
e Google Groups<br>=22Narwhal and Jack=22 group.<br>To post to this group=
, send email to <a href=3D=22mailto:narwhaljs=40googlegroups.com=22>narwh=
aljs=40googlegroups.com</a>.<br>To unsubscribe from this group, send emai=
l to<br><a href=3D=22mailto:narwhaljs+unsubscribe=40googlegroups.com=22>n=
arwhaljs+unsubscribe=40googlegroups.com</a>.<br>=46or more options, visit=
 this group at<br><a href=3D=22http://groups.google.com/group/narwhaljs=3F=
hl=3Den=22>http://groups.google.com/group/narwhaljs=3Fhl=3Den</a>.<br></d=
iv></blockquote><br>-- <br>You received this message because you are subs=
cribed to the Google Groups =22Narwhal and Jack=22 group.<br>To post to t=
his group, send email to <a href=3D=22mailto:narwhaljs=40googlegroups.com=
=22>narwhaljs=40googlegroups.com</a>.<br>To unsubscribe from this group, =
send email to <a href=3D=22mailto:narwhaljs+unsubscribe=40googlegroups.co=
m=22>narwhaljs+unsubscribe=40googlegroups.com</a>.<br>=46or more options,=
 visit this group at <a href=3D=22http://groups.google.com/group/narwhalj=
s=3Fhl=3Den=22>http://groups.google.com/group/narwhaljs=3Fhl=3Den</a>.<br=
></div></div></span>
               =20
               =20
               =20
               =20
                </blockquote>
               =20
                <div>
                    <br>
                </div>
            </div>
        </div>
--4da6cc60_7ba207f7_117--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
