Hello Oliver,
On 18-Apr-99 12:43:52, you wrote:
>[EMAIL PROTECTED] wrote:
>> >> I wonder what are the advantages of using bytecode compiler and then an
>> >> interpreter for Javascript when you always have to interpreter the
>> >> Javascript source code from the pages.
>>
>> >It's both a design and a speed issue. The design issue is that it's
>> >easily implemented with a bison generated parser:), the speed issue is
>> >that it's
>>
>> Ah, well, it's the usual tokenizing. With this all these new Internet
>> manias to invent new concepts, I thought you were actually saving a byte
>> code stream to disk cache.
>No, it's not simply a tokenizing (this takes place before a parser is even
>involved). The source text is really compiled down into the usual P-Code
>representation for a virtual machine with an expression and an object
>reference stack. This is nothing new, it's a standard issue when designing
>compilers. A "real" compiler just generates target-architecture dependant
>machine code from the P-representation.
Right, but last time I studied compilers, what goes into the parser stacks
are actually the encoded integer values of the tokens.
>I could save the P-Code to disk, but I doubt it would gain much.
>Bison-generated parsers are horribly fast, even on Amiga-class CPUs :),
>and Javascript code normally isn't excessivly large.
Right.
>> >That's just a subset of the MSIE one, too.
>>
>> So, what features does it have besides the ones in DOM standard? Layers?
>Generally, it's much more flexible in respect to what object properties can
>be changed "on the fly" after the page is represented. The only "dynamic"
>aspects in the Mozilla object model are document.write() and the ability
>to replace Image.src (in a limited fashion).
I guess you mean before NS 4. I haven't studied the Dynamic capabilities
of Netscape but I know it handles layers.
>> Talking about MSIE, is Voyager going to have a progressive HTML table
>> layout engine that starts laying tables before they are fully loaded.
>> Voyager has been fast in many issues, but currently it is particularly
>> retarded rendering tables, even when compared with other Amiga browsers
>> that also wait to load the tables definition till the end.
>"www.freshmeat.net" is a good example for this. However, there are
>two issues:
Yes, I disabled a lot of stuff in my preferences in Freshmeat to ensure that
the article text appears as soon as it is loaded even before the discussion
threads that I generatlly don't care.
>a) You can't really render a table before it is fully parsed, because
>you simply don't know the size beforehand. TABLE WIDTH and TD WIDTH are
>just advisory. Would you *could* do, however, is render the table as
>far as possible, and drop all the layouting when more data is available.
>I haven't implemented this yet, but it surely is possible (V does something
>similiar when hitting <IMG> without size specifications)
Exactly. IE5 and Gecko based browsers do this for tables. Since a lot of
Web designers forget that loading from the Web is not as immediate as
loading from the disk, they often abuse of nested tables. It would be
great if Voyager could be that smart and relayout while the data is still
coming at least when the data transfer stalls or periodically.
Regards,
Manuel Lemos
E-mail: [EMAIL PROTECTED]
URL: http://www.e-na.net/the_author.html
PGP key: finger:[EMAIL PROTECTED]
--
