plan

[Federico Benavento]

I wrote a new small html incremental parser that just creates a tree of Node's
and keeps all the content, except the tags, as text, I think this
is the way to go since the JS engine manipulates text, some functions
that are not used yet like addnode() and mvnode() will be used by
the JS engine. the parser is in /n/sources/contrib/fgb/html.tgz,
there is a tiny htmlfmt is presented just for debugging and testing
it has a -t opt that shows the tree in an acme-friendly way.

Now I'm reading every cssparser that exists, one I thing I learned
is that I can't use yacc, because it's not suitable for multi-threaded apps.
maybe the lemon parser generator is the way to go.

The css parser is a must, since the html one is not aware about how
the content should be displayed.

The last part that is required is a box lib or something, that takes the
tree of Node's and the stylesheet and builds a new tree/list ready
to be draw in the screen.

JS engine should only touch the tree of Nodes.

comments?

--
Federico G. Benavento

[Aki Nyrhinen]

just comments and possible ideas; feel free to ignore as it's
highly unlikely that i'll contribute in any way to this project.

i'd just like you to know that i greatly appreciate the idea,
i hate the trend of increasing size, c++ and bugginess of
all mozilla-based browsers, and i know it doesn't need to
be that complicated.

On 12/12/06, Federico Benavento < bena...@gmail.com> wrote:

I wrote a new small html incremental parser that just creates a tree of Node's
and keeps all the content, except the tags, as text, I think this
is the way to go since the JS engine manipulates text, some functions
that are not used yet like addnode() and  mvnode() will be used by
the JS engine.

i agree this is probably the way to do it if you target mozilla
compatibility. i've tried writing some cross-browser javascript
programs and it seems to me that using the dom is the only
way to make the program work on all the major browsers.

i maybe wrong; this is very far from my field of expertise.

i remember seeing some references to javascript being translated
to scheme. as i think writing a scheme interpreter is  a much less
tedious undertaking than javascript, this might speed up development
and have the additional value of providing a good lisp interpreter
for plan9?

Now I'm reading every cssparser that exists, one I thing I learned
is that I can't use yacc, because it's not suitable for multi-threaded apps.
maybe the lemon parser generator is the way to go.

why is yacc not suited for multi-threaded programs? i suppose you mean it's
not re-entrant, but that doesn't mean you cannot use it. you can write the
parsers as external programs that generate their output to files or to
segattached memory, and neither is complicated.

then maybe i just like yacc want to force everyone else to like it too.

[Gabriel Diaz]

Hello

google code search has some pointers like

http://www.google.com/codesearch?hl=en&q=show:rEgdsr3NAZQ:l5lME-c0ImY:BeFlSXOwcvY&sa=N&ct=rd&cs_p=http://www.cortex.salk.edu/cortex.dist/c591.zip&cs_f=SOURCE/CSS/CSSTHRED.C

they have the css.y file and the surrounding machinery, if it helps.

gabi

[Federico Benavento]

Hola,

> just comments and possible ideas; feel free to ignore as it's
> highly unlikely that i'll contribute in any way to this project.
>

hey, this is why I created this list, I need to hear different point
of views and ideas, otherwise I'll keep hitting my head against
the wall without knowing why :)

> i remember seeing some references to javascript being translated
> to scheme. as i think writing a scheme interpreter is a much less
> tedious undertaking than javascript, this might speed up development
> and have the additional value of providing a good lisp interpreter
> for plan9?
>

I already have firefox's JS engine ported and by reading
http://developer.mozilla.org/en/docs/JavaScript_C_Engine_Embedder%27s_Guide
doesn't look too hard making abaco to use it.

> why is yacc not suited for multi-threaded programs? i suppose you mean it's
> not re-entrant, but that doesn't mean you cannot use it. you can write the
> parsers as external programs that generate their output to files or to
> segattached memory, and neither is complicated.
>
> then maybe i just like yacc want to force everyone else to like it too.
>
>

heh

thanks

--
Federico G. Benavento

[Federico Benavento]

gabi,

that's another kind of css (Cortex State System) :)

--
Federico G. Benavento

[Gabriel Diaz]

hello

LOL, that was just a quick search, i'm not web-capable, but i will try
to give a hand as much as i can, may be i end with some more knowledge
about the topic.

The intention of the mail was to show there are couple of
implementations using yacc and that google code search is an option to
find them, i will try to send more usefull emails on the future ;).

gabi

[elbing]

I'll be your nightmare too :p. As I said you last monday, next friday I'll probe your final abaco in my final home.

--
Elbing

2006/12/13, Gabriel Diaz < gabi...@gmail.com>: