From: dhtml on
On Apr 19, 9:02 am, "Richard Cornford" <Rich...(a)litotes.demon.co.uk>
wrote:
> Andrew Dupont wrote:
> > On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:

> One of the arguments paraded in favour of these libraries is that they
> are examined, worked on and used by very large numbers of people, and so
> they should be of reasonably high quality because with many eyes looking
> at the code obvious mistakes should not go unnoticed. My experience of
> looking at code from the various 'popular' libraries suggests that this
> is a fallacy, because (with the exception of YUI (for obvious reasons))

Not obvious.

There's plenty of bugs YUI. A good number of them are reported in the
bugtracker (public) yet others are reported on the Yahoo internal bug
tracker (Bugzilla). Others may still be unfiled.

I don't 100% agree that the problem is not that the authors aren't
smart enough. A lot of these problems come from the process. Things
like having one guy own such-such piece of code, or the code freezes.
Or testing the happy path of maybe 20% of an object's methods.

> all of the 'popular' library contain numerous obviously stupid mistakes.

Including YUI.

They also have bug trackers. As Andrew pointed out, Prototype does
too.

A fix for the bug that was demonstrated seems to be by simply putting
the &amp; last.

String.prototype.unescapeHTML = function() {
return this.replace(/&lt;/g,'<')
.replace(/&gt;/g,'>')
.replace(/&amp;/g,'&');
};

That would need to be tested out though.

Right?

Garrett

> Richard.
From: beegee on
On Apr 21, 2:50 pm, Zeroglif <zerog...(a)gmail.com> wrote:
> On 21 ÁÐÒ, 17:44, beegee <bgul...(a)gmail.com> wrote:
>
> > On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> > wrote:
>
> > > beegee wrote:
> > > > Uh, no.  Do you understand what compilation is?
>
> > > Yes, do you?
>
> > Transforming an english-like higher level programming language coded
> > program into a lower-level programming language coded program for the
> > benefits of speed and size.
>
> Brendan Eich (JavaScript):
> "Client JavaScript reads source from SCRIPT tag contents, but compiles
> it into an internal bytecode for faster interpretation."
>
> Eric Lippert (JScript):
> "JScript Classic acts like a compiled language in the sense that
> before any JScript Classic program runs, we fully syntax check the
> code, generate a full parse tree, and generate a bytecode. We then run
> the bytecode through a bytecode interpreter. In that sense, JScript is
> every bit as "compiled" as Java. The difference is that JScript does
> not allow you to persist or examine our proprietary bytecode. Also,
> the bytecode is much higher-level than the JVM bytecode -- the JScript
> Classic bytecode language is little more than a linearization of the
> parse tree, whereas the JVM bytecode is clearly intended to operate on
> a low-level stack machine."

Thanks for the quotes. I thought, at first, from reading them that I
had been totally wrong about compilation of javascript. Then I read
deeper in the second quote about what the byte code is. And really,
it is not a true compilation. It is still a first pass optimization.
In fact I wouldn't be surprised if the same machine that can interpret
unprocessed javascript, interprets the bytecode.

Bob
From: Thomas 'PointedEars' Lahn on
beegee wrote:
> Thanks for the quotes. I thought, at first, from reading them that I had
> been totally wrong about compilation of javascript. Then I read deeper
> in the second quote about what the byte code is. And really, it is not a
> true compilation. It is still a first pass optimization.

Winding around your error, are you? It is true compilation, as true as
byte-code compilation in Java is, for example.

> In fact I wouldn't be surprised if the same machine that can interpret
> unprocessed javascript, interprets the bytecode.

Bytecode is platform-independent, of course, because a Virtual Machine
interprets it. As I have said, in that sense at least JavaScript[tm],
and as it turns out JScript also, are compiled languages.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: VK on
On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Bytecode is platform-independent, of course, because a Virtual Machine
> interprets it. As I have said, in that sense at least JavaScript[tm],
> and as it turns out JScript also, are compiled languages.

???

What is interpreted language then for you? Read next line of code -
Parse for token - Create internal code - Execute - Forgot this code -
Cleared the memory - Moved to the next line? Something like that?
There is no such engine since Enigma and Cyclometer at least :-)

Javascript is being stored and delivered to the engine in the raw text
source code format. The engine naturally compiles it to be able to use
so the engine works with compiled code - but Javascript is not a
compiled language. Try to see the difference, if you can.

P.S. JScript.NET _is_ a compiled language.
From: Thomas 'PointedEars' Lahn on
VK wrote:
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Bytecode is platform-independent, of course, because a Virtual Machine
>> interprets it. As I have said, in that sense at least JavaScript[tm],
>> and as it turns out JScript also, are compiled languages.
>
> [...]

Please spare us your fantasies about what other people might think. Thank
you in advance.

> Javascript is being stored and delivered to the engine in the raw text
> source code format. The engine naturally compiles it to be able to use
> so the engine works with compiled code - but Javascript is not a
> compiled language.

Yes, it is. What you describe is called Just-In-Time (JIT) compilation.

> Try to see the difference, if you can.

There is no difference at all, Often Wrong. One can even compile the same
source code into a file in bytecode format, and have the same JavaScript VM
execute that (as it is possible on NES-compatible servers).

> P.S. JScript.NET _is_ a compiled language.

As are JavaScript and JScript. As hard as it may be for you to understand,
compilation does not require a file on the filesystem as its result.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
First  |  Prev  |  Next  |  Last
Pages: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: displaying a page from an iframe
Next: print scrollable div