Possible Bug? Array.forEach in ctor doesn't work
James Carr
I've ran into an interesting issue with Array.prototype.forEach with
the latest node from git.
function Something(){
['one', 'two'].forEach(function(){})
}
if I call new Something(); this will work find and the forEach
executes. However if I declare some variable first
function Something(){
var a = 'a'
['one', 'two'].forEach(function(){})
}
and create a new instance it throws the exception TypeError: Cannot
call method 'forEach' of undefined. Assigning the array to a variable
works though
function Something(){
var a = 'a'
var b = ['one', 'two']
b.forEach(function(){})
}
Any idea what's up?
Thanks,
James
Matthias Ernst
> Hi All,
>
> I've ran into an interesting issue with Array.prototype.forEach with
> the latest node from git.
>
> function Something(){
> ['one', 'two'].forEach(function(){})
> }
>
> if I call new Something(); this will work find and the forEach
> executes. However if I declare some variable first
>
>
> function Something(){
> var a = 'a'
> ['one', 'two'].forEach(function(){})
> }
http://en.wikipedia.org/wiki/Space-time_tradeoff
In this case you're trading trailing semicolon bytes for time debugging.
Matthias
>
> and create a new instance it throws the exception TypeError: Cannot
> call method 'forEach' of undefined. Assigning the array to a variable
> works though
>
> function Something(){
> var a = 'a'
> var b = ['one', 'two']
> b.forEach(function(){})
> }
>
> Any idea what's up?
>
> Thanks,
> James
>
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>
Dean Landolt
On Sat, Jul 24, 2010 at 5:36 PM, James Carr <james....@gmail.com> wrote:http://en.wikipedia.org/wiki/Space-time_tradeoff
> Hi All,
>
> I've ran into an interesting issue with Array.prototype.forEach with
> the latest node from git.
>
> function Something(){
> ['one', 'two'].forEach(function(){})
> }
>
> if I call new Something(); this will work find and the forEach
> executes. However if I declare some variable first
>
>
> function Something(){
> var a = 'a'
> ['one', 'two'].forEach(function(){})
> }
In this case you're trading trailing semicolon bytes for time debugging.
James Carr
my no semi-colon convention over with me. Guess I'll have to start
using semi-colons again here. ;)
Is there really a performance drawback for not using semi-colons in V8?
Thanks,
James
Aaron Heckmann
Heh. Where's the no-semicolon crowd now? :)
--
Aaron
http://clickdummy.net
Dean Landolt
Marak Squires
--
Isaac Schlueter
Putting unnecessary semicolons everywhere is not the answer! Don't
believe the hype. Trust your aesthetic senses, they're right and good
and you should honor and value them. Stay true to your minimalist
spirit!
Just don't start lines with "[". Start them with ";[" instead, and
then you'll be able to copy and paste them anywhere, without worrying
about what's on the line above. Same for "(", for similar reasons.
;(function (){
var a = 'a'
;['one', 'two'].forEach(function(){})
})()
That way, you're only applying semicolons where they're actually relevant.
*Every* JavaScript engine works the same way in this regard. There is
absolutely no loss of portability, and no performance impact.
--i
James Carr
Marco Rogers
everywhere :) Sure they're unnecessary. But so are line breaks in
javascipt. Sure code with no line breaks is less readable. But I
feel the same way about code without semis.
No offense Isaac. It's just whenever you no semi-colon guys (anti-
coloners?) start evangelizing, I feel the need to play devils
advocate ;)
:Marco
mscdex
> I definitely honor and value mine. That's why I leave semis in
> everywhere :) Sure they're unnecessary. But so are line breaks in
> javascipt. Sure code with no line breaks is less readable. But I
> feel the same way about code without semis.
>
> No offense Isaac. It's just whenever you no semi-colon guys (anti-
> coloners?) start evangelizing, I feel the need to play devils
> advocate ;)
>
comments or something, since semicolons at the beginning are used as
comment symbols in other languages.
Isaac Schlueter
1. Marco has feelings about semicolons.
2. Starting with ; looks like some other construct from some other language.
You realize these are about the silliest possible arguments that could
be made, right? I mean, you're not saying anything. So, here's a
fitting rebuttal:
1. Isaac has other feelings about semicolons.
2. Magical imaginary pixies always have exactly three wings.
3. My list has one more thing in it than yours.
Ergo, semicolons should be minimized.
I propose a rule that we are only allowed to discuss this subject in
person, and after no fewer than 5 beers apiece, so at least we'll have
a good excuse for getting silly and belligerent. Or state your
priorities up front, so that we can say things that have objective
meaning.
I'm only being dismissive because this is a very stupid subject.
--i
Sotonin
James Carr
semicolons vs. no semicolons. :)
Sotonin
Isaac Schlueter
> Watch Douglas Crockfords "Javascript the good parts". I
> recall him going into details about how javascript's auto insertion of
> semi-colons is piss poor and nobody should rely on it. But hey. i just think
> they look better.
I've seen it. He doesn't go into the details about how JavaScript
breaks statements. He tells a few scary stories and shows some broken
code. He wrote a JS parser, so I assume he knows how it works.
Here's an explanation that is based in facts rather than FUD:
http://inimino.org/~inimino/blog/javascript_semicolons
--i
Isaac Schlueter
Have you guys put away 5 beers yet? Because otherwise, you should
really not be talking about this.
Terry Riegel
if a=b then
else
/if
Is much more readable to me than
if (a==b) {
} else {
}
But I don't mind because JavaScript makes up for it. I just started running my code through Crockfords jslint and I must say it has improved my codes readability to me at least.
Terry
Sent from my iPhone
Marco Rogers
find it odd that you're now calling this a stupid subject. My
recollection on this is that you and a few others are the ones that
always make this an issue by brow-beating people who people who like
semis. And if you don't think you've done that then I don't
understand how you are acting like my comment above is antagonistic.
It's not, but I'm sorry if I came across that way.
I think it's a silly subject too which is why I always want to make
sure that whenever it comes up, there are two sides. I feel like many
people who try to join the node community almost instantly get
bombarded with this by folks who make up the core group like you and
TJ. It can create a an atmosphere of apprehension as people will feel
that their code won't be respected as much if they decide to stick to
semi-colons. I just don't always feel like your tone is one that says
"yeah there's no difference so choose what you want." It always ends
up sounding like "yeah there's no technical difference so be cool like
me and don't use em for aesthetic reasons. You ARE cool right?"
Which is fine if that's way you want to go. But why stop me from
trying to create an atmosphere where it's okay to be on either side?
I don't think it's bad to argue about it. It's what programmers do.
I don't think I've ever told you or anyone else who doesn't use semis
that you're doing "the wrong thing". I've always said, yes it's an
aesthetic choice and you should choose whatever you want unless the
project has style guide rules.
But okay, I agree with the 5 beers rule. Starting.... now.
:Marco
PS - I don't really like beer :( Can I have Maker's and Coke instead?
Chris Winberry
We'll then
if (a===b) {...
must cause you conniptions. What if one wanted to actually evaluate the result of an assignment?
Marco Rogers
was supposed to be joking. My sincere apologies. I just thought it
was funny as a reverse to Marak's pro-semicolon comment.
> >>>> Watch Douglas Crockfords "Javascript the good parts". I
> >>>> recall him going into details about how javascript's auto insertion of
> >>>> semi-colons is piss poor and nobody should rely on it. But hey. i just
> think
> >>>> they look better.
>
> >>> I've seen it. He doesn't go into the details about how JavaScript
> >>> breaks statements. He tells a few scary stories and shows some broken
> >>> code. He wrote a JS parser, so I assume he knows how it works.
>
> >>> Here's an explanation that is based in facts rather than FUD:
> >>>http://inimino.org/~inimino/blog/javascript_semicolons
>
> >>> --i
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> >> To post to this group, send email to nod...@googlegroups.com.
> >> To unsubscribe from this group, send email to
>
> http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to
>
>
> http://groups.google.com/group/nodejs?hl=en.
>
>
>
>
Isaac Schlueter
belligerent. You're a friendly guy and you're joking around, and I
am, too. We just have this same conversation so often, that's all.
If there were new things coming out of it, then that'd be great, but
it's like, "I like them!" "I don't!" "My way is better!" "So and so
doesn't agree with you!" Booorrrrrinnnnggg.
It's worth noting that Ryan requires semicolons in nodejs code, and a
LOT of "big" node projects use the JSLint style. It's not my intent
(or TJ's, I'm sure) to browbeat anyone. I just have an issue with
people being wrong on my internets, especially when someone comes here
asking a question and gets the wrong answer. So if someone says that
semicolonless code isn't browser-safe, or compressible, or portable,
or performant, I feel the need to pipe up and point out the FUD.
For what it's worth (that is, for roughly nothing), I don't use them
in npm because:
1. It's harder for me to scan code when relevant tokens are on the
jagged-right edge.
2. The reduction in tokens, while jarring at first, is significantly
easier to scan once you get used to it.
3. npm has a lot of long lists and one-liner functions, so it's not
like there'd be a ton of semicolons anyway. They just seemed
extraneous.
I write npm for me, and it's great that some folks have found it
useful, but like... it's a hobby, and I'm going to write it in a way
that brings me artistic satisfaction. No one pays me to work on it,
it's just a fun problem space. It's like Mr. Miagi with the bonsai
tree. Your tree doesn't have to look like mine, and that's not what
it's about anyway. The JavaScript community is a peaceful anarchy.
If we're gonna talk about HOW to safely write semicolonless code (eg,
the suggestion to start lines with ";[" rather than "["), then that's
great, and super interesting, and there a lot of fascinating things
there. But this context-free "is it better to use them or not" meme,
gah, it's so lame.
And here I am totally making things worse by reacting to it. So, there's that.
--i
Marco Rogers
wasn't even involved. My apologies to him as well. I tend to cause
trouble when I'm sick.
Scott González
2. Unicorns are cooler than magical imaginary pixies.
3. Semicolons/no semicolons is like tabs/spaces, nobody ever wins and
there are always a mix of reasonable and silly statements.
4. I'm surprised there are no snarky comments from Marak yet.
Ergo, I don't care about this conversation.
Huh, these random lists are fun :-)
Shimon Doodkin
([]).push();
(function(){})();
Terry Riegel
Victor S
It allows you to waste so much time debugging because of 'invisible'
semicolons and other WTF's of language design.
I'm on the side of JSLint here. No weird formatting to confuse people,
no assuming the interpreter will fix your missing semicolons. It's
there, it should be there, you know it's there and shame on the
designer of JS to allow such leniency, in most other languages if you
make syntactical mistake you know it right away, error, done, no more
arguments.
- V
Isaac Schlueter
> I understand why we have =, ==, ===, I just don't care for it. But if that
> is how I had started I probably wouldn't care.
JavaScript is not a perfect languages.
But it turns out humans don't much like using perfect languages. We
like the *idea* of them, but there's a reason English is more popular
than Esperanto, just as JavaScript is more popular than Common Lisp.
--i
Isaac Schlueter
> to execute commands upon definition you should enclose them with ()
>
> ([]).push();
> (function(){})();
Starting lines with ( is as problematic as starting them with [. You
need to wrap lambdas in parens so that the interpreter treats it as a
function expression rather than a function statement. There's no need
for parens around anonymous arrays.
On Sun, Jul 25, 2010 at 08:49, Victor S <victo...@gmail.com> wrote:
> It allows you to waste so much time debugging because of 'invisible'
> semicolons
It's not "invisible" semicolons. That's not how the language works.
> No weird formatting to confuse people,
You don't think C-style formatting is weird?
> in most other languages if you
> make syntactical mistake you know it right away, error, done, no more
> arguments.
If you make syntax errors in JS, you know right away, too.
JS isn't C. Its a different language, with a different syntax.
--i
Mihai Călin Bazon
>
> But it turns out humans don't much like using perfect languages.
I think they do, but they don't know it yet.
> We like the *idea* of them, but there's a reason English is more popular
> than Esperanto, just as JavaScript is more popular than Common Lisp.
And what is that reason, oh, please enlight us with your infinite wisdom!
I'd take CL anytime. Unfortunately, we don't have much choice... JS is
still pretty good, compared to many others, so at least there is hope.
Cheers,
-Mihai
Jacob Rothstein
sibilant (and coffeescript, for that matter). Write in a more
aesthetic language that compiles to js and get the advantages of both.
Also, down with unnecessary semicolons! Think of them as a
disambiguation character for js's permissive whitespace policy.
–Jacob
(typed on a tiny keyboard)
On Jul 25, 2010, at 11:07 AM, "Mihai Călin Bazon"
<mihai...@gmail.com> wrote:
Tom
Isaac Schlueter
> On Sun, Jul 25, 2010 at 6:50 PM, Isaac Schlueter <i...@izs.me> wrote:
>> But it turns out humans don't much like using perfect languages.
> I think they do, but they don't know it yet.
They've had a lot of time to try to figure it out, and there have been
lots of attempts. So, I'm doubtful it's a question of "yet".
>> We like the *idea* of them, but there's a reason English is more popular
>> than Esperanto, just as JavaScript is more popular than Common Lisp.
>
> And what is that reason, oh, please enlight us with your infinite wisdom!
I have no idea. Just speaking empirically. My wisdom is finite.
--i
Shimon Doodkin
trading semicolon for debugging time.
On Jul 24, 6:56 pm, Matthias Ernst <matth...@mernst.org> wrote:
> > Hi All,
>
> > I've ran into an interesting issue with Array.prototype.forEach with
> > the latest node from git.
>
> > function Something(){
> > ['one', 'two'].forEach(function(){})
> > }
>
> > if I call new Something(); this will work find and the forEach
> > executes. However if I declare some variable first
>
> > function Something(){
> > var a = 'a'
> > ['one', 'two'].forEach(function(){})
> > }
>
> In this case you're trading trailing semicolon bytes for time debugging.
>
> Matthias
>
>
>
>
> > and create a new instance it throws the exception TypeError: Cannot
> > call method 'forEach' of undefined. Assigning the array to a variable
> > works though
>
> > function Something(){
> > var a = 'a'
> > var b = ['one', 'two']
> > b.forEach(function(){})
> > }
>
> > Any idea what's up?
>
> > Thanks,
> > James
>
Dean Landolt
Seems like this would be a reasonable occasion on which to plug
sibilant (and coffeescript, for that matter). Write in a more
aesthetic language that compiles to js and get the advantages of both.
Also, down with unnecessary semicolons! Think of them as a
disambiguation character for js's permissive whitespace policy.
Victor S
choice to the community... I think you could make anything pretty
popular... check out IE stats today...
Floby
it always works. why take the risk to add a (rather untraceable) bug ?
the same work as well if you put them at the beginning, it just looks
nothing like C-style syntax (which javascript has voluntarily
adopted).
you can learn when they are necessary and when they are not, you're
just doing a computer's job.
you can never put them and trust your interpreter to put them for you.
But it's a machine after all. you trust it, and next thing you now ->
skynet -> judgment day.
as in natural language, you can omit periods, question marks, etc. you
can think that people will figure them out anyway. well a) they may
not figure it out correctly b) they will think you're an uneducated
teenager. =)
Amen Amen. Blessed are those who put semicolons at the end of each
instruction for they will have working scripts. :D
Felix Geisendörfer
& discussion, let's vote and look at the outcome:
http://news.ycombinator.com/item?id=1547647
--fg
Chris Winberry
You missed one option: IDGaF
=)
Aaron Heckmann
Felix Geisendörfer
Not happy with democracy? If only JS had a strong authority figure
with an opinion on this ...
http://www.jslint.com/lint.html#semicolon
FWIW: I would *like* to not use semicolons in JS. But the current
"push" for that is IMHO a mix of ruby/python home sickness and "Let's
do this because we are smart enough to do it right.". Both are
terrible influences on style in any language.
--fg
On Jul 26, 2:34 pm, Aaron Heckmann <aaron.heckm...@gmail.com> wrote:
> Ahh, popularity contests...
>
> > .
> > groups.google.com/group/nodejs?hl=en.
>
> > >> > > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > >> > > To post to this group, send email to nod...@googlegroups.com.
> > >> > > To unsubscribe from this group, send email to
> > .
> > > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > > To post to this group, send email to nod...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > .
> >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> Aaronhttp://clickdummy.net
Isaac Schlueter
it always works."
Right, because semicoloned code NEVER has bugs, right? ;P
It also always work if you prefix the rare leading [ and ( with a
semicolon. The bugs that semicolons prevent are easier to prevent
with a prefix (because it's more easy to spot when it's missing), and
are also not very hard bugs to fix.
This is nothing but FUD. You could also argue that type coercion
sometimes causes bugs, so you shouldn't ever coerce strings to
objects. But I'm gonna go ahead and keep calling substr and length on
string natives.
The vote and appeal to authority adds no new information. We already
knew which style was more common, and which style Crockford prefers.
If commonness or Crockford-approval are important to you, then the
data is as clear as ever. Adding more data convinces no one of
anything. Clearly, the no-semicolon crowd doesn't care about the
crowd or the Crock.
I'm ok with you using semicolons. I'll follow your style if I send
you a patch request. You could even make that choice for reasons that
I think are silly; it's each hacker's responsibility to decide what's
important for the projects they own. I just wish that the lies and
fearmongering would stop. It's a cultural problem in the JavaScript
community. People try to solve their problems by following rules,
believing that the underlying logic is too hard, when in fact, it's
not very complicated at all. Then they make these noisy claims about
"hard to trace bugs".
npm is over 3500 lines of JavaScript, using most of the NodeJS API
surface, and doing some complicated juggling between radically
different configurations, file systems, and HTTP. I'm not trying to
toot my own horn here, but I believe that I am more qualified than the
average JavaScripter to say that, given a few simple guidelines, the
"semicolons prevent hard bugs" argument is pretty much bunk. npm has
bunches of tricky bugs -- I'm *very* aware of that -- but they're not
because of the syntax.
You cannot convince someone of anything until you know their
priorities. You learn that by asking, not telling. Sometimes, you
may learn that what they're doing, while not the way you do it in your
situation, makes perfect sense in theirs.
--i
2010/7/26 Felix Geisendörfer <fe...@debuggable.com>:
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Isaac Schlueter
serious coding in either. They're cute languages, but they're not
universal like C and JavaScript, so they don't matter much to me.
This isn't homesickness, but rather a desire to clear away the dust
and clutter in the home I love.
--i
Zachary Carter
"the thing is, when you put semicolons at the end of each instruction,
it always works."
Right, because semicoloned code NEVER has bugs, right? ;P
It also always work if you prefix the rare leading [ and ( with a
semicolon. The bugs that semicolons prevent are easier to prevent
with a prefix (because it's more easy to spot when it's missing), and
are also not very hard bugs to fix.
--
Zach Carter
Marco Rogers
we? But I realized it's worthless so feel free to skip it.
-----
I must say I am very disappointed that Isaac is still participating in
this thread. It seems that eradicating FUD is more important to him
than honoring a great pact involving beers. Even if in this instance
(rare to be sure) it's not actually FUD, but a reasonable
approximation of it. There's no false information out there about the
way javascript parsers work. Or false info about what happens when
you leave out semis in the wrong place. There is only false
interpretations of what that means. And the fact is that using semis
never hurt anyone. That disqualifies it as FUD in my book.
Bugs caused by missing semis in minified code do exist and they do
suck. They are not hard to *fix* as Isaacs agrees. But they are damn
hard to *find*. Because the parser doesn't give you much to go on
accept "someFunc is not a function" or some such nonsense. It doesn't
always give you the right line number to look at and if it's minified
then it might be the one line that has 95% of the rest of the code as
well. This is especially painful when it's code you've never seen and
have no insight into. To me that equals a buggy parser. To some, it
means I suck at debugging js. Fair enough.
So then you have to go find some js prettify function and run
everything through that. Then find some way to load the unminified
crap back into the page. Oh it's not your page you say? It's on your
client's machine and you can't have access? They just want you to
"tell them what's wrong". Well there are solutions for that as well,
(js debuggers? *shudder*). Eventually you figure it out and get it
fixed. But now you're cursing the person who decided it was cool to
leave out semicolons. Otherwise you would've totally been done with
this a while ago and I wouldn't have had to skip lunch... again.
Then you go back to your backend code that's in C. You continue
hacking and eventually you start to get frustrated by the repeated
compile cycles. You start to realize that at least a 4th of those are
caused by stupidly leaving out semicolons because you've learned to do
this in your js. So wait, you can't switch back and forth seamlessly
without thinking about it? What are you a bad programmer? It would
seem so to hear some people tell it.
It is absolutely true that there are no technical arguments to be made
for using semis everywhere. But there are very real and very valid
reasons for a person to decide for themselves that they want to
continue using them or not. It's VERY difficult for folks on either
side to concede that point. And admittedly, when asked to back up
their decisions, people on the pro-semis side tend to lead with the
poorly understood technical arguments. And those are easily shot
down. That is the paper tiger that Isaac is trying so valiantly to
slay. It's unfortunate on both sides and it's why this argument
continues to rage.
I added to the problem by throwing my own personal arguments into the
mix. But at no point was I ever trying to *convince* anyone. It's
not worth the effort. It was never "my list has more items than
yours". It was simply "here are my reasons for continuing to use
semis *despite fully understanding* all of the technical reasons Isaac
and others have stated". But I just want to throw my justifications
out there for people to use the next time they are beset by the no-
semis crew who are trolling for half-hearted arguments.
Personally, I don't care how other people code. If I don't like it,
I'll try my best to avoid your code. If I can't, then I'll try my
best to work with it and I won't say much if anything. The real
problem I have is with this palpable feeling of coercion that seems to
come from the other camp. That whole "if you were thinking clearly,
you'd see things my way" type of feeling. My aesthetic sense, my
attention to detail, my understanding of technical issues and my
desire to write "clean code" for others are all working properly I
assure you. I've just decided to go a different way. And what I
would really love is if you didn't care about that, and we could
continue to work together on more important things.
:Marco
Bradley Meck
when both can back themselves up.
Floby
you can focus on structural bugs.
and http://xkcd.com/757/
tjholowaychuk
Not so much sold but more just "meh" about it, now that I have to use
them all the time for SSJS they dont bug me so much
tjholowaychuk
looking (4 spaces too blah) than my older libs
George Stagas
comma first, brackets only when really needed) for a few days now and
my experience is that everything really just looks better, is easier
to read, easier to spot errors,
the code just got cleaner and prettier and there are reasons for that:
Having no semicolons in the end, just forces you to use more
whitespace, more new lines, before that
I would just use semicolons to do lot of jobs in one line, making my
code ugly and unreadable.
Commas first, are much better, you no longer need to go on the
previous line and add a comma
if you want to add a new item. The comma defines the new item, which
is what it's supposed to do.
So it goes with it, on the same line and that's the right way, I see
it now. Also this style forces you to use more
whitespace, indentation and newlines making the code more readable.
Also I tried using a space before the bracket on functions, and a
space before the parenthesis on closures, like this:
'function foo() {', 'var foo = function() {' for functions and
'function (){' for closures, although I have yet to see the
benefit from that other than it probably makes it a bit easier to spot closures.
I can't go back, even in 3 days using this style, everything else just
doesn't look as good. And I've never written
cleaner code like this before. I'm definetely keeping it.
2010/7/27 Bradley Meck <bradle...@gmail.com>:
Michael Fellinger
> Bugs caused by missing semis in minified code do exist and they do
> suck. They are not hard to *fix* as Isaacs agrees. But they are damn
> hard to *find*. Because the parser doesn't give you much to go on
> accept "someFunc is not a function" or some such nonsense. It doesn't
> always give you the right line number to look at and if it's minified
> then it might be the one line that has 95% of the rest of the code as
> well. This is especially painful when it's code you've never seen and
> have no insight into. To me that equals a buggy parser. To some, it
> means I suck at debugging js. Fair enough.
Are there no minifiers that simply strip spaces from the front of each line?
--
Michael Fellinger
CTO, The Rubyists, LLC
I check email a couple times daily; to reach me sooner, use:
http://awayfind.com/manveru