EJS
Daniel Friesen
writing some actual rules for translating ejs into js
Some compiling rules: http://draft.monkeyscript.org/ejs/spec.txt
An example .ejs file: http://draft.monkeyscript.org/ejs/example.ejs
And it's compiled form: http://draft.monkeyscript.org/ejs/example.js
For readability I've left newlines inside of strings, however most
likely compiled templates will replace newlines with \n after escaping
backslashes and single quotes.
So far I've omitted notes on actual code calls, originally I was
thinking of handling things with `this` but I'm thinking it'll be best
to specify names for arguments formally for passing data, or perhaps
make use of with.
A few interesting notes:
* Like JSONP a variable or callback can be specified so it's actually
possible to send compiled templates to the browser in fun ways that let
you use a template both browser and server side (as long as you avoid
newer syntaxes not supported in browsers, and include a minimal ejs.js
file if you make use of filters).
* I made this from the start with an understanding of some of erb's
faults, so there are actually some things you can do in ejs you can't do
in erb.
For example, in erb this will fail miserably: <ul><%= [1,2,3,4,5].map {
|i| %><li><%= i %></li><% }.join('\n') %></ul>
But in ejs this will work: <ul><%= [1,2,3,4,5].map( %><li><%=
arguments[0] %></li><% ).join('\n') %></ul>
Though I haven't specified syntax for naming the arguments going to
unclosed functional blocks, I'll probably use something like 1.8's
function() syntax sugar.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Zachary Carter
Daniel Friesen
For the record draft.monkeyscript.org should have the IP 75.101.178.185, you can get it to work for now by shoving "75.101.178.185 draft.monkeyscript.org" inside of your hosts file for now. I'll try to get the problem fixed, but you know how long it takes for DNS to update.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen
Anyone have suggestions for a decent DNS Service?
I normally register my domains through DreamHost, though I'm not
desperate enough to use their DNS Management. Otherwise my one .name got
me to use Answerable for one domain. I might consider using their DNS if
that's the way it goes. I was going to move away at one point anyways, I
wanted to move over to Amazon instead of Linode since my current server
is screwed up, and if I wanted to start a new temp server to slowly
replace the old one I'd basically have to pay for a second server for an
entire year, which I really don't need, so for that kind of switching
Amazon seams the best to use. Of course Amazon doesn't offer DNS like
Linode so obviously I need to find someone else anyways.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Zachary Carter wrote:
Daniel Friesen
xname.org looks interesting, but they consider having 25 zones to be
abuse. I'm a bit domain fanatic, I already have 12 zones and whenever I
actually get into implementing a project I like to register a domain for it.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Wes Garland
I do. Around here it takes about an hour.
Given your predilection for zone acquisition and your tinkerer's
mentality, I would recommend buying yourself a static IP and a copy of
DNS and Bind (O'Reilly).
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Daniel Friesen
started to pull back on that. Setting up my own mailserver just became
far to troublesome and I opted for Google Apps.
I already know enough about DNS though. Personally I don't go for the
de-facto tools, rather than Bind I'd probably opt for PowerDNS, nice
support for using a database as a backend.
It might be a good option for the small company I work for, but
personally finding a reasonable DNS host with fallback servers might be
best.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen
I actually got into Narcissus a little bit. I managed to get the
Narcissus parser to work browser side (Well, just with FireFox).
I think I could actually get EJS up off of a modified Narcissus. It's
just a little tricky to start off. I basically need to tweak
Narcissus's parser to see the <% %> tags and parse code specially
depending on if it's inside of one of those blocks or not.
If I could just get that much done, I could easily write the rest of
the code to compile an .ejs file into a .js file.
^_^ As a bonus, the EJS compiler would dish out syntax errors with
nice precise line numbers part of the .ejs files themselves (Last I
checked, that's yet another thing erb doesn't do)
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Kris Kowal
<nadir.s...@gmail.com> wrote:
> So what is everyone's thoughts on EJS?
EJS appears to have a lot in common with PHP and JSP. I've had the
pleasure of working with Django recently, which has one of the new
styles of template parser/formatters that are more structured and
readable, in addition to providing insightful tracebacks. Kevin
Dangoor and George Moschovitis pointed out JSON Template, which
appears to be a similar, strong, interoperable, and idiomatically
JavaScript contender for the template engine role.
http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Template.html
But, while I would personally go a different way, if you were to
provide a package of your EJS template engine, and if it were made
interoperable, I think your package could potentially be listed in a
ServerJS package index. Are you recommending that EJS be a component
of the ServerJS standard library?
Kris Kowal
Daniel Friesen
JSP though.
The real inspiration though is actually ERB:
http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/
And the other like implementations Erubis: http://www.kuwata-lab.com/erubis/
PHP embeds the PHP/Buffering syntax directly into the language. IMHO
that might actually not be the best method, you need to use ob_ calls
instead of writing actual templates, It's not optional, and the syntax
is globally dictated.
The difference between EJS and JSONTemplate, are basically the
differences between ERB and Liquid: http://www.liquidmarkup.org/
One converts the syntax into a pure language output buffered equivalent
which basically embedding it inside the output, and the other is a
formal template language.
At the moment I'm thinking of modifying the Tokenizer inside of
Narcissus to write the EJS compiler, so initially it'll only work within
a SpiderMonkey environment (ie: Getters/Setters).
In the future a little look into modifying the modified Narcissus to not
use the extensions could be possible.
I'd say EJS has a place anywhere. After a little cleaning up it could
work on it's own, as a ServerJS module, or even a MonkeyScript banana.
Initially EJS' use would probably be good in that website compiler we
were talking about on the list.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Robert Koberg
On May 3, 2009, at 7:34 PM, Daniel Friesen wrote:
>
> EJS does have some stuff in common with PHP, I don't really know about
> JSP though.
For JSP, you could write it like EJS, but not the only way. Of course
you can use JavaScript as the language of your JSP. And JSP would be
way faster.
The main problem with template schemes like EJS is they break XML well-
formedness -- completely unnecessary.
-Rob
Daniel Friesen
I see no reason to validate my .ejs file against XML, only the output
itself matters.
All this is simple output buffering, it simply outputs text. It's the
responsibility of the author of the .ejs file to make sure that their
output is well formed.
As a bonus to that, it means that you aren't limited to the world of
XHTML and you can use .ejs to get any kind of output you want, even
write a bit of looping stuff into CSS, JS, or whatnot. In fact I used
ERB at one point to write the CSS for a few color scheme classes.
Conversely I find that things like XSL which do guarantee XML
well-formed output get in the way and force you to write your templates
around the syntax, rather than write the template around your document.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Robert Koberg
On May 3, 2009, at 9:08 PM, Daniel Friesen wrote:
>
> XML well-formedness has no business in this area.
> I see no reason to validate my .ejs file against XML, only the output
> itself matters.
generate templates in-addition-to/instead-of just handwriting a
template. Or use the template in a transform that renders a larger page.
>
> All this is simple output buffering, it simply outputs text. It's the
> responsibility of the author of the .ejs file to make sure that their
> output is well formed.
several other options that don't break XML well-formedness. You get
the same result, but allow people to do things where you might not see
the need.
>
> As a bonus to that, it means that you aren't limited to the world of
> XHTML and you can use .ejs to get any kind of output you want, even
that breaks well-formedness rules when you *do* want XML.
-Rob
George Moschovitis
> Dangoor and George Moschovitis pointed out JSON Template, which
> appears to be a similar, strong, interoperable, and idiomatically
> JavaScript contender for the template engine role.
of changes:
http://github.com/gmosx/nitro/blob/b8cad5b89dda2be57db1c73686a1536f76cd2012/src/nitro/template.js
this basic implementation is reused in a more advanced template that
includes an xslt pre-processing step (if you need it):
http://github.com/gmosx/nitro/blob/b8cad5b89dda2be57db1c73686a1536f76cd2012/src/nitro/xsltemplate.js
-g.
--
www.nitrojs.org
Daniel Friesen
> On May 3, 2009, at 9:08 PM, Daniel Friesen wrote:
>
>
>> XML well-formedness has no business in this area.
>> I see no reason to validate my .ejs file against XML, only the output
>> itself matters.
>>
>
> I would argue that it reduces flexibility. I (and others) like to
> generate templates in-addition-to/instead-of just handwriting a
> template. Or use the template in a transform that renders a larger page.
>
templates in other templates?
>> All this is simple output buffering, it simply outputs text. It's the
>> responsibility of the author of the .ejs file to make sure that their
>> output is well formed.
>>
>
> Sure, but what is so bad about using ${ or {= or $[ or any of the
> several other options that don't break XML well-formedness. You get
> the same result, but allow people to do things where you might not see
> the need.
>
EJS.endTag = '}$';
Start/End is completely customizable, I could even step that up even
more to let you write up regexes and differentiate an = from a non = and
use different ends.
Though frankly I'd avoid any use of } or ] like the plague, <> are the
only parenthesis that make sense, something like this will become hell:
${ if( testing ) { }$Some nested block${ } }$
And it won't even parse right if you try EJS.endTag = '}';
But quite frankly I don't see much point in your template file being
valid xml, the output is what matters, and a valid xml template doesn't
mean you have valid xml output: (pardon the syntax, I don't have a
connection to check the JSONTemplate syntax right now)
<ul>
{section .list}
<li><a href="{href}">{if text}{text}</a>{or}Untitled{/if}</li>
{/section}
</ul>
That template is xml valid, but the output will be wrong any time there
is no text specified for an item in the list.
>> As a bonus to that, it means that you aren't limited to the world of
>> XHTML and you can use .ejs to get any kind of output you want, even
>>
>
> Fine, but there still is no *real* need to use angle brackets in a way
> that breaks well-formedness rules when you *do* want XML.
>
Then use them in a way that doesn't break well-formedness:
EJS.startTag = '<ejs>';
EJS.endTag = '</ejs>';
<ul><ejs>for ( let item in list ) {</ejs><li><ejs>= item
</ejs><li><ejs>}</ejs></ul>
The reason for the <% ... %> is:
A) Tradition
B) Trying to throw {} into the syntax when you're allowing direct
embedding of the entire language becomes a nightmare since {} already
have other meanings inside of the language.
Security and a simple expressed syntax vs. the power and flexibility of
having the entire language embedded.
Both have perfectly valid uses depending on what you need, pick what
works for your project and use it. There's no reason for one kind to die
off in favor of another.
Myself, sometimes I want the safe simple syntax of a normal template
language, and other times I have more use for the fully embedded setup.
> -Rob
>
>
>> write a bit of looping stuff into CSS, JS, or whatnot. In fact I used
>> ERB at one point to write the CSS for a few color scheme classes.
>> Conversely I find that things like XSL which do guarantee XML
>> well-formed output get in the way and force you to write your
>> templates
>> around the syntax, rather than write the template around your
>> document.
>>
>>
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>
>> Robert Koberg wrote:
>>
>>> On May 3, 2009, at 7:34 PM, Daniel Friesen wrote:
>>>
>>>
>>>
>>>> EJS does have some stuff in common with PHP, I don't really know
>>>> about
>>>> JSP though.
>>>>
>>>>
>>> For JSP, you could write it like EJS, but not the only way. Of course
>>> you can use JavaScript as the language of your JSP. And JSP would be
>>> way faster.
>>>
>>> The main problem with template schemes like EJS is they break XML
>>> well-
>>> formedness -- completely unnecessary.
>>>
>>> -Rob
>>>
>>>
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Robert Koberg
On May 4, 2009, at 11:24 AM, Daniel Friesen wrote:
>
> Robert Koberg wrote:
>> On May 3, 2009, at 9:08 PM, Daniel Friesen wrote:
>>
>>
>>> XML well-formedness has no business in this area.
>>> I see no reason to validate my .ejs file against XML, only the
>>> output
>>> itself matters.
>>>
>>
>> I would argue that it reduces flexibility. I (and others) like to
>> generate templates in-addition-to/instead-of just handwriting a
>> template. Or use the template in a transform that renders a larger
>> page.
>>
> Huh, what does XML Validity have to do with the ability to nest
> templates in other templates?
you seem to be missing the point. First, I should have written an
*xsl* transform -- apologies if this lead to confusion. You may not
care, but I do. When I have to deal with a template system that is not
able to be written in a well-formed manner (I see that yours can be),
I cannot transform it to meet my needs whether is for a full html page
render, conversion to JSON, conversion to atom, creation of reporting
for various occurences of things, and on and on and on. It ill require
manually rework from someone.
I am simply saying that angles brackets used in a way as to break xml
well-formedness are unnecessary and should be avoided.
think of the children!
-Rob
Daniel Friesen
like this?
-- template.ejs
<?xml version="1.0" encoding="UTF-8"?>
<list>
%: for each ( let item in list ) { ;%
<item>%:= item ;%</item>
%: } ;%
</list>
-- layout.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:template match="/">
<html>
<title>My List</title>
<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="//list">
<ul><xsl:apply-templates/></ul>
</xsl:template>
<xsl:template match="//list/item">
<li><xsl:apply-templates/></li>
</xsl:template>
----
then write:
var xsl = new XSL( File('layout.xsl').open('r').read() );
var template = xsl.transform( new XML(
File('template.ejs').open('r').read() ) );
var ejs = new EJS;
ejs.startTag = '%:';
ejs.endTag = ';%';
ejs.compile( template );
var html = ejs.run( { list: ['a', 'b', 'c'] } );
print( html );
Where you will start with template.ejs, and will be transformed into:
<!DOCTYPE ...>
<html>
<title>My List</title>
<body>
<ul>
%: for each ( let item in list ) { ;%
<li>%:= item ;%</li>
%: } ;%
</ul>
</body>
</html>
----
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen
and other bits and managed to get it to do something fun.
Here's a little preview:
>>> parse('...<% var foo = "bar"; if( true ) { %>...<% } %>...').toString();
{
type: TEMPLATE,
0: {
type: BUFFER,
end: 5,
lineno: 1,
start: 0,
tokenizer: [object Object],
value: ...
},
1: {
type: VAR,
0: {
type: IDENTIFIER,
end: 13,
initializer: {
type: STRING,
end: 21,
lineno: 1,
start: 16,
tokenizer: [object Object],
value: bar
},
lineno: 1,
name: foo,
readOnly: false,
start: 10,
tokenizer: [object Object],
value: foo
},
end: 13,
length: 1,
lineno: 1,
start: 6,
tokenizer: [object Object],
value: var
},
2: {
type: IF,
condition: {
type: TRUE,
end: 31,
lineno: 1,
start: 27,
tokenizer: [object Object],
value: true
},
elsePart: null,
end: 25,
lineno: 1,
start: 23,
thenPart: {
type: BLOCK,
0: {
type: BUFFER,
end: 43,
lineno: 1,
start: 36,
tokenizer: [object Object],
value: ...
},
end: 43,
length: 1,
lineno: 1,
start: 34,
tokenizer: [object Object],
value: {
},
tokenizer: [object Object],
value: if
},
3: {
type: BUFFER,
end: 51,
lineno: 1,
start: 46,
tokenizer: [object Object],
value: ...
},
bufferDecls: {
type: BUFFER,
end: 5,
lineno: 1,
start: 0,
tokenizer: [object Object],
value: ...
},{
type: BUFFER,
end: 43,
lineno: 1,
start: 36,
tokenizer: [object Object],
value: ...
},{
type: BUFFER,
end: 51,
lineno: 1,
start: 46,
tokenizer: [object Object],
value: ...
},
funDecls: ,
length: 4,
lineno: 1,
tokenizer: [object Object],
varDecls: {
type: IDENTIFIER,
end: 13,
initializer: {
type: STRING,
end: 21,
lineno: 1,
start: 16,
tokenizer: [object Object],
value: bar
},
lineno: 1,
name: foo,
readOnly: false,
start: 10,
tokenizer: [object Object],
value: foo
}
}
It's actually handling buffers inside of code already. There are other
steps to go though:
* Make sure it can handle things like <% fn( %>...<% ) %> as well as <%
var hash = { foo: %>...<% } %>
* Handle the echo cases: <%= ... %>
* Clean up the whole Narcissus modification to make it an isolated
system, and try to eliminate the SpiderMonkey extension dependencies
* Actually make it compile templates
Another fun bit for the road:
>>> parse("ABC\n<% var foo = 'bar';\n if( var f = 'red' ) fn(); %>\nXYZ");
SyntaxError: Missing operand; fileName: "", lineNumber: 3, cursor: 32
^_^ Pretty nice? It's actually catching JS syntax errors (Not EJS, JS
errors) and throwing syntax errors in the context of the template itself
rather than leaving syntax errors up to when you decide to execute the
compiled version and end up with a confusing jumble of code to look at (
;) like ERB and most other language embedding template systems)
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Kris Kowal
<nadir.s...@gmail.com> wrote:
> * Clean up the whole Narcissus modification to make it an isolated
> system, and try to eliminate the SpiderMonkey extension dependencies
If you're interested, I've already made a head start on porting
Narcissus to our module spec. The defs and parse modules work in
Narwhal, at least, although there are a couple properties left still.
I have no plans to do the exec module personally, but would be glad to
pull it from anyone who needs it. My interest in Narcissus is in
creating a module bundler and minifier (I would like to target both
client and server side with modules with Narwhal and Chiron).
http://github.com/kriskowal/narcissus/tree/master
Kris Kowal
Daniel Friesen
Though I probably might handle it myself with a standard function
wrapping and a bit of cleanup.
Since you put that code up, here's a repo with EJS' current state in it.
http://github.com/dantman/ejs/
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Kris Kowal wrote:
Daniel Friesen
Narcissus.
At one point I to was interested in writing a JS minifier in JS
(specifically I was hoping to port YUI's minifier to SpiderMonkey hoping
I could find a way to access the tokenizer used).
One thing I found out was that one of the things that YUIMin does is
check for IE conditional comments. It avoids removing any of these
comments and leaves them intact.
If I may, an interesting suggestion. Rather than finding comments and
leaving conditional comments alone, modify Narcissus to parse
conditional comments.
This brings in a number of nice possibilities. Conditional comments
become available for execution and you can output code based on
conditional comments (imagine using conditional comments to mark debug
code and passing a flag to make narcissus spit out code with or without
debug blocks. But other than that, you can minify JS inside of
conditional comments ;). That, is something I believe YUIMin does not do.
On another port note. Narcissus seams to be based around JS 1.5; It's
missing support for all the nice js1.6-1.8 additions like let, function
syntax sugar, destructors, and various other parts of the whole
generators and iterators bit.
If anyone is interested in porting Narcissus to a version that supports
the newer features, I'd be interested in that project. Or an even wilder
idea, a version that conditionally supports different JS versions ;).
Cause I'm over here in EJS left with syntax errors whenever I want to
use my favorite new features.
As for all these notes about Narcissus 'modification', it's unfortunate
but it looks like Narcissus wasn't build in a very extension friendly
manor. To use narcissus to do something other than pure js1.5 stuff you
need to hack it and modify it into a different piece of software
If anyone is interested in working on taking Narcissus and making it
into a system where someone can easily take the nice isolated Narcissus
package and only need to extend things to make it do something new
(Bonus if we can make it do this in a way that multiple different syntax
parsers based on Narcissus (ejs, js1.8, etc...) can coexist without
loading Narcissus more than once.) I'd be interested in discussing ideas
for that as well.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen
Working in the browser has turned to crap, FireBug is starting to get
more in the way than being a help.
I can't compile jslibs on my 64bit Ubuntu cause of an issue compiling
NSPR for it.
Frankly I don't feel like compiling boost from source for flusspferd
just cause it uses a version newer than what I already have installed
on my system.
The way Wes' GPSEE handles compiling SpiderMonkey gives me a real nice
fuzzy feeling, unfortunately I had an error when compiling GPSEE
itself. (I still love the compiling though... It's a little verbose in
what to do, but it's lent well to prebuilt packages and whatnot)
As for narwhal... Don't know if it's Rhino or Narwhal itself, but the
trick Narcissus uses evaling a const line breaks in Narwhal.
It's a shame it's still going to be awhile till I can get out a
contractor to help with the C/C++ side of MonkeyScript. If it were
ready I'd already have a nice interpreter and I'd be able to make use
of the debugger that Soubok is working on.
Kris Kowal
<nadir.s...@gmail.com> wrote:
> As for narwhal... Don't know if it's Rhino or Narwhal itself, but the
> trick Narcissus uses evaling a const line breaks in Narwhal.
Yeah, I fixed that in my version on github too, along with most of the
properties and such. It's probably not a perfect match for your use
case, and it's not complete, but it's a head start.
Kris Kowal
Wes Garland
The way Wes' GPSEE handles compiling SpiderMonkey gives me a real nice
fuzzy feeling, unfortunately I had an error when compiling GPSEE
itself. (I still love the compiling though... It's a little verbose in
what to do, but it's lent well to prebuilt packages and whatnot)
There is a recent bug + patch for building on linux from hdon which hasn't landed yet. I expect that to land on Monday. Long story short, I wrote "rpath," when I should have written "rpath=".
Re warm-and-fuzzies -- you still need a working NSPR 4.7 or better for GPSEE. There must be an Ubuntu package...
As for verbose/tricky instructions -- I'm hoping to improve those by distributing binaries some day. But I just can't bring myself to tell people to "make install" as root. It's very bad karma. :)
On the plus side, the current GPSEE build environment works well for development once you've installed it once; the dependencies are reasonably well set-up, so that if you, say, modify SpiderMonkey's Makefile.in, it will trigger a re-autoconfig, which in turns triggers a rebuild of everything that includes jsapi.h
If you're looking for a server-side JS project with a debugger, you could do worse than to look at Robert Schultz's project "Piston". (Robert is Sembiance on IRC). Pistonmonkey is a simple spidermonkey embedding that talks to the eclipse debugger plugin with some kind of RESTful HTTP protocol. I suspect it would be pretty easy to make Pistomonkey sit on top of GPSEE giving you serverjs modules if needed them (GPSEE is designed to work as a thin layer between spidermonkey and an embedding).
Word of warning -- you really want to run eclipse and pistonmonkey on the same machine. Running on separate machines will require that you somehow arrange for the inodes of the source files to line up on both boxes. I don't know enough java to fix this, and Robert just got married so he's probably out of commission for a bit. ;)
Wes
Wes Garland
Aristid Breitkreuz
> I'm a little at a loss for an interpreter to work in at the moment.
> Working in the browser has turned to crap, FireBug is starting to get
> more in the way than being a help.
> I can't compile jslibs on my 64bit Ubuntu cause of an issue compiling
> NSPR for it.
>
If you disable JS_THREADSAFE, Spidermonkey should work without NSPR.
> Frankly I don't feel like compiling boost from source for flusspferd
> just cause it uses a version newer than what I already have installed
> on my system.
>
We support versions 1.36, 1.37, 1.38 and 1.39 of Boost. Older versions
than that don't have all the features we use. (Specifically it is
boost::unordered_map, a hash map class introduced in 1.36, that makes
Flusspferd incompatible with Boost 1.35 and older. Before 1.36 was
rolled out, we used boost::multi_index_container for the same purpose,
but that really was a lot of unneeded overhead that we could strip by
moving to boost::unordered_map.)
But see <http://www.boost.org/users/history/>.
Of course Flusspferd requires a working Spidermonkey first.
Wes Garland
I'll also point out that compiling boost, while extremely time-consuming, is not particularly difficult. Pretty much configure, make, and go for a coffee. (I'm the next town. ;) )
Daniel Friesen
> On Sat, May 9, 2009 at 10:18 PM, Daniel Friesen
> <nadir.s...@gmail.com <mailto:nadir.s...@gmail.com>> wrote:
>
> The way Wes' GPSEE handles compiling SpiderMonkey gives me a real nice
> fuzzy feeling, unfortunately I had an error when compiling GPSEE
> itself. (I still love the compiling though... It's a little verbose in
>
> what to do, but it's lent well to prebuilt packages and whatnot)
>
>
> There is a recent bug + patch for building on linux from hdon which
> hasn't landed yet. I expect that to land on Monday. Long story short,
> I wrote "rpath," when I should have written "rpath=".
>
> Re warm-and-fuzzies -- you still need a working NSPR 4.7 or better for
> GPSEE. There must be an Ubuntu package...
> As for verbose/tricky instructions -- I'm hoping to improve those by
> distributing binaries some day. But I just can't bring myself to tell
> people to "make install" as root. It's very bad karma. :)
>
> On the plus side, the current GPSEE build environment works well for
> development once you've installed it once; the dependencies are
> reasonably well set-up, so that if you, say, modify SpiderMonkey's
> Makefile.in, it will trigger a re-autoconfig, which in turns triggers
> a rebuild of everything that includes jsapi.h
>
> If you're looking for a server-side JS project with a debugger, you
> could do worse than to look at Robert Schultz's project "Piston".
> (Robert is Sembiance on IRC). Pistonmonkey is a simple spidermonkey
> embedding that talks to the eclipse debugger plugin with some kind of
> RESTful HTTP protocol. I suspect it would be pretty easy to make
> Pistomonkey sit on top of GPSEE giving you serverjs modules if needed
> them (GPSEE is designed to work as a thin layer between spidermonkey
> and an embedding).
>
> Word of warning -- you really want to run eclipse and pistonmonkey on
> the same machine. Running on separate machines will require that you
> somehow arrange for the inodes of the source files to line up on both
> boxes. I don't know enough java to fix this, and Robert just got
> married so he's probably out of commission for a bit. ;)
Eclipse and my machines, especially when it has something to do with a
debugger.
http://jslibs.googlecode.com/svn/wiki/jslibs_debugger2.png
Soubok's looks interesting. The debugger itself is written in XUL.
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen
> Daniel Friesen schrieb:
>
>> I'm a little at a loss for an interpreter to work in at the moment.
>> Working in the browser has turned to crap, FireBug is starting to get
>> more in the way than being a help.
>> I can't compile jslibs on my 64bit Ubuntu cause of an issue compiling
>> NSPR for it.
>>
>>
>
> If you disable JS_THREADSAFE, Spidermonkey should work without NSPR.
>
The issue is Soubok's build system. He's got a whole libs/ folder which
pulls in sources for a number of other libraries. And he uses something
like recursive make and has it compile everything and does something
along the line of statically linking.
It works great from the standpoint of Windows where you're just about
completely unlikely to run into any of those libraries as shared
libraries. But doesn't lend itself to using ones that are available.
>> Frankly I don't feel like compiling boost from source for flusspferd
>> just cause it uses a version newer than what I already have installed
>> on my system.
>>
>>
>
> We support versions 1.36, 1.37, 1.38 and 1.39 of Boost. Older versions
> than that don't have all the features we use. (Specifically it is
> boost::unordered_map, a hash map class introduced in 1.36, that makes
> Flusspferd incompatible with Boost 1.35 and older. Before 1.36 was
> rolled out, we used boost::multi_index_container for the same purpose,
> but that really was a lot of unneeded overhead that we could strip by
> moving to boost::unordered_map.)
>
> But see <http://www.boost.org/users/history/>.
>
> Of course Flusspferd requires a working Spidermonkey first.
>
Ubuntu has boost 1.34, other than that though, I don't even know if the
SpiderMonkey 1.7 will work for Narcissus at the moment.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Aristid Breitkreuz
> Ubuntu has boost 1.34, other than that though, I don't even know if the
> SpiderMonkey 1.7 will work for Narcissus at the moment.
>
Ubuntu has newer versions available:
http://packages.ubuntu.com/search?keywords=boost%201.37
We support Spidermonkey 1.8+.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Peter Michaux
<nadir.s...@gmail.com> wrote:
>
> I've been writing some notes on EJS, so I've finally gotten around to
> writing some actual rules for translating ejs into js
>
> Some compiling rules: http://draft.monkeyscript.org/ejs/spec.txt
> An example .ejs file: http://draft.monkeyscript.org/ejs/example.ejs
> And it's compiled form: http://draft.monkeyscript.org/ejs/example.js
I've implemented something very similar before ServerJS started. I've
attached the source code as it may help. (It may also be throw away.)
Peter