Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #4413 > unrolled thread

Yay! CGI forth interpreter success

Back to article view | Back to comp.lang.forth

Contents

  Yay! CGI forth interpreter success Tarkin <tarkin000@gmail.com> - 2011-07-24 19:08 -0700
    Re: Yay! CGI forth interpreter success Mark Wills <forthfreak@forthfiles.net> - 2011-07-25 05:17 -0700
      Re: Yay! CGI forth interpreter success John Passaniti <john.passaniti@gmail.com> - 2011-07-25 18:31 -0700
        Re: Yay! CGI forth interpreter success BruceMcF <agila61@netscape.net> - 2011-07-25 22:53 -0700
          Re: Yay! CGI forth interpreter success Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-26 19:34 +0000
        Re: Yay! CGI forth interpreter success Paul Rubin <no.email@nospam.invalid> - 2011-07-26 01:21 -0700
        Re: Yay! CGI forth interpreter success Mark Wills <forthfreak@forthfiles.net> - 2011-07-26 01:57 -0700
          Re: Yay! CGI forth interpreter success Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-26 19:48 +0000
            Re: Yay! CGI forth interpreter success mhx@iae.nl (Marcel Hendrix) - 2011-07-27 21:33 +0200
              Re: Yay! CGI forth interpreter success crc <charles.childers@gmail.com> - 2011-07-29 13:10 -0700
        Re: Yay! CGI forth interpreter success Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-26 17:48 +0100
          Re: Yay! CGI forth interpreter success Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-26 17:54 +0100
          Re: Yay! CGI forth interpreter success crc <charles.childers@gmail.com> - 2011-07-26 12:02 -0700
            Re: Yay! CGI forth interpreter success Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-29 17:36 +0100
        Re: Yay! CGI forth interpreter success anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-26 17:06 +0000
      Re: Yay! CGI forth interpreter success Tarkin <tarkin000@gmail.com> - 2011-07-30 12:35 -0700
        Re: Yay! CGI forth interpreter success Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 16:03 -0500
        Re: Yay! CGI forth interpreter success Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-31 10:47 +0000
      Re: Yay! CGI forth interpreter success Tarkin <tarkin000@gmail.com> - 2011-07-31 11:11 -0700
        Re: Yay! CGI forth interpreter success John Passaniti <john.passaniti@gmail.com> - 2011-08-03 09:41 -0700
          Re: Yay! CGI forth interpreter success Spam@ControlQ.com - 2011-08-03 13:54 -0400
          Re: Yay! CGI forth interpreter success Tarkin <Tarkin000@invalid.com> - 2011-08-04 23:06 +0000
            Re: Yay! CGI forth interpreter success John Passaniti <john.passaniti@gmail.com> - 2011-08-11 16:48 -0700
              Re: Yay! CGI forth interpreter success Tarkin <Tarkin000@gmail.com> - 2011-08-14 02:12 +0000
                Re: Yay! CGI forth interpreter success John Passaniti <john.passaniti@gmail.com> - 2011-08-13 22:03 -0700
                  Re: Yay! CGI forth interpreter success Tarkin <Tarkin000@gmail.com> - 2011-08-20 23:07 +0000
      Re: Yay! CGI forth interpreter success Tarkin <tarkin000@gmail.com> - 2011-07-31 11:12 -0700
      Re: Yay! CGI forth interpreter success Tarkin <tarkin000@gmail.com> - 2011-07-31 11:24 -0700

Page 1 of 2  [1] 2  Next page →

#4413 — Yay! CGI forth interpreter success

Hello all,
  I've been saying on here from time to time that I am
working on a modified version of jonesforth.
At long last, I have knocked together a decent enough
interpreter to begin testing a CGI interface...

: flow forth linux on web ;

Abstract:
  'flow' forth is a modified version of 'jonesforth' by Richard WM
Jones.
It is written in assembler, using Intel syntax and assembled by FASM.
FASM (v. 1.69.31) emits an elf32 object file, which I then link using
a custom build of vlink (http://sun.hasenbraten.de/vlink/ ).
The resulting executable is 13772 bytes, and runs on any
Linux sporting kernel 2.6 (can be rebuilt for 2.4).
flow is non-standard, and non-ans compliant.

 By pairing flow with Linux, it gains access to all of the system
calls,
process management features, and device drivers that Linux
provides. Particularly, flow can act as a CGI script processor,
for dynamic web scripting in forth.

I have performed only the most cursory of testing; however, the intial
results are *very* promising. My testing setup is:
Debian Linux (32 bit) 2.6.26-2-686 #1 SMP
Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
Intel PII (Deschutes) @ 400MHz.
lighttpd-1.4.19 (ssl)

'lighty', as lighttpd is nicknamed, has 'mod_cgi' enabled,
with the following .conf file entry:
cgi.assign = ( ".4th" => "/usr/local/bin/flow" )

here is index.4th, a simple, bare-minimum cgi test:
--------------------8<----------------------------------------------
\ vim: set ft=forth: set ts=2:
: NEWL 13 EMIT 10 EMIT ;
." HTTP/1.1 200 OK" NEWL
." Content-Type: text/html; charset=UTF-8" NEWL
." Connection: close" NEWL
." X-Powered-By: flow-0.9" NEWL
NEWL
NEWL
." <html>" CR
."   <head>" CR
."     <title>FORTH CGI</title>" CR
."   </head>" CR
."   <body>" CR
."     <h3>It works!</h3>" CR
."     <p><strong>Hello, Browser!!!</strong><br />" CR
."     Forth CGI interpreter based on jonesforth, written by
Tarkin!!!.</p>" CR
."   </body>" CR
." <html>" CR

--------------------8<----------------------------------------------

It shows exactly what you expect that html to render as.

I modified the startup routine(s) to check ARGC, and if
it's > 1, loop through ARGV, and EVAL each file it can.
EVAL simply takes a string and length, transform into a
'\0'-terminated string, get a file descriptor for the filename,
and switch KEY to use that file descriptor to fetch characters.
On EOF, key is reset to use stdin (0).

The system is quick and precise ; however, errors are FATAL,
resulting in various Linux process-killers such as SEGFAULT
and 'floating point exception".

In a few days, I'll have a source tarball with all the necessary
softwaree to build it available.

TTFN,
  Tarkin

[toc] | [next] | [standalone]

#4417

On Jul 25, 3:08 am, Tarkin <tarkin...@gmail.com> wrote:
> Hello all,
>   I've been saying on here from time to time that I am
> working on a modified version of jonesforth.
> At long last, I have knocked together a decent enough
> interpreter to begin testing a CGI interface...
>
> : flow forth linux on web ;
>
> Abstract:
>   'flow' forth is a modified version of 'jonesforth' by Richard WM
> Jones.
> It is written in assembler, using Intel syntax and assembled by FASM.
> FASM (v. 1.69.31) emits an elf32 object file, which I then link using
> a custom build of vlink (http://sun.hasenbraten.de/vlink/).
> The resulting executable is 13772 bytes, and runs on any
> Linux sporting kernel 2.6 (can be rebuilt for 2.4).
> flow is non-standard, and non-ans compliant.
>
>  By pairing flow with Linux, it gains access to all of the system
> calls,
> process management features, and device drivers that Linux
> provides. Particularly, flow can act as a CGI script processor,
> for dynamic web scripting in forth.
>
> I have performed only the most cursory of testing; however, the intial
> results are *very* promising. My testing setup is:
> Debian Linux (32 bit) 2.6.26-2-686 #1 SMP
> Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
> Intel PII (Deschutes) @ 400MHz.
> lighttpd-1.4.19 (ssl)
>
> 'lighty', as lighttpd is nicknamed, has 'mod_cgi' enabled,
> with the following .conf file entry:
> cgi.assign = ( ".4th" => "/usr/local/bin/flow" )
>
> here is index.4th, a simple, bare-minimum cgi test:
> --------------------8<----------------------------------------------
> \ vim: set ft=forth: set ts=2:
> : NEWL 13 EMIT 10 EMIT ;
> ." HTTP/1.1 200 OK" NEWL
> ." Content-Type: text/html; charset=UTF-8" NEWL
> ." Connection: close" NEWL
> ." X-Powered-By: flow-0.9" NEWL
> NEWL
> NEWL
> ." <html>" CR
> ."   <head>" CR
> ."     <title>FORTH CGI</title>" CR
> ."   </head>" CR
> ."   <body>" CR
> ."     <h3>It works!</h3>" CR
> ."     <p><strong>Hello, Browser!!!</strong><br />" CR
> ."     Forth CGI interpreter based on jonesforth, written by
> Tarkin!!!.</p>" CR
> ."   </body>" CR
> ." <html>" CR
>
> --------------------8<----------------------------------------------
>
> It shows exactly what you expect that html to render as.
>
> I modified the startup routine(s) to check ARGC, and if
> it's > 1, loop through ARGV, and EVAL each file it can.
> EVAL simply takes a string and length, transform into a
> '\0'-terminated string, get a file descriptor for the filename,
> and switch KEY to use that file descriptor to fetch characters.
> On EOF, key is reset to use stdin (0).
>
> The system is quick and precise ; however, errors are FATAL,
> resulting in various Linux process-killers such as SEGFAULT
> and 'floating point exception".
>
> In a few days, I'll have a source tarball with all the necessary
> softwaree to build it available.
>
> TTFN,
>   Tarkin

Very very nice!

Given most browsers 'forgiveness' with white space, you could define
some HTML (at least the earlier ones, from 1.0/1.1) tags as Forth
words:

: <p>  ." <p>"  ;
: </p> ." </p>" ;

<p> Hello mother! </p> <p> Look at me! </p>

Tags that take parameters might be a difficult though... Eg. <table
width='100%'>

Although, having said that...

: <table> ( width% -- )
  ." <table width='" . ." %'>" ;

100 <table>

Now you are writing HTML with Forth ;-)

The point being, once you can *dynamically* render HTML using Forth
processing (rather than just pushing strings out with .") then you
truly have arrived at a true dynamic web processor.

Congratulations. This looks like great fun!

Mark

[toc] | [prev] | [next] | [standalone]

#4430

On Jul 25, 8:17 am, Mark Wills <forthfr...@forthfiles.net> wrote:
> Although, having said that...
>
> : <table> ( width% -- )
>   ." <table width='" . ." %'>" ;
>
> 100 <table>
>
> Now you are writing HTML with Forth ;-)

Most every language that I've done any web work in (Perl, Python,
Ruby, Lua) has one or more libraries to generate HTML
programmatically.  For a (simple) example with one Lua library:

    name = "Mark"
    P { "Hello ", B(name) }

Which would produce:

    <p>Hello <b>Mark</b></p>

The primary advantage being that the functions ensure that you
generate syntactically correct HTML.  More sophisticated libraries can
do things like this:

    IMG("example.jpg")

Which would produce:

    <img src="example.jpg" height="48" width="120" />

That is, it can look at the image metadata and incorporate that into
the HTML.

These kinds of libraries generally make generating HTML much easier
and cleaner.  But that's in part because there is a natural mapping
between infix function syntax and HTML tags.  That is, functions map
to tags, arguments map to either attributes or subordinate tags.  What
isn't clear to me is if there is some syntax in Forth that would be
equally as pleasant to work with.  Obviously that's a bit subjective,
but you pointed out the issue in your message.  Prefix syntax like in
your example...

    100 <table>

...just feels wrong.  It doesn't directly map into the generated
output, and I can't see how one would handle nested tags (which is
necessary for any real-world use).

I'd be interested if anyone has come up with a syntax for
programmatically generating HTML in Forth that's reasonable.

Another solution is to avoid the issue and instead come up with a
template system.  There, you put raw HTML in the code but with some
kind of escape to replace text with other text.  That has its charms,
especially when you can reference templates inside other templates.
But it's not quite the same thing and requires putting raw HTML in the
code.

[toc] | [prev] | [next] | [standalone]

#4433

On Jul 25, 9:31 pm, John Passaniti <john.passan...@gmail.com> wrote:
...

>     100 <table>
>
> ...just feels wrong.  It doesn't directly map into the generated
> output, and I can't see how one would handle nested tags (which is
> necessary for any real-world use).
>
> I'd be interested if anyone has come up with a syntax for
> programmatically generating HTML in Forth that's reasonable.

A markup organized around white space delimited tags which can be
translated into html by selecting a suitable wordlist as the markup
dictionary seems like one approach ...

\i{ Hello \b{ Mark \} \} \.

... then you can run a simple token interpreter that tests for the
lead escape, runs the literal token function on non-escaped
characters, searches escaped strings in the wordlist, executes them if
found, otherwise emits the remainder as a string.

One of the things that can be stored on the token stack is the
previous literate token function, so on thing an escaped command can
do is put its own literate executive in place ...
   \img{ example.jpg \}

... would put the image source and options interpreter in place,
popped off again by the token pop escape \}

I've never experimented with it enough to be sure which output
whitespace system is smoothest ~ a workable approach is to have first-
token, next-token and extend-token functions in a vector|object, the
first token in a sequence has no white space, subsequent tokens in a
sequence has preceding white space, and escaped strings end up with no
white space before or after, but there is likely a prettier looking
approach.

[toc] | [prev] | [next] | [standalone]

#4444

In article <573431e9-daef-40d7-9225-670a63c5642c@n35g2000yqf.googlegroups.com>,
BruceMcF  <agila61@netscape.net> wrote:
>On Jul 25, 9:31=A0pm, John Passaniti <john.passan...@gmail.com> wrote:
>...
>
>> =A0 =A0 100 <table>
>>
>> ...just feels wrong. =A0It doesn't directly map into the generated
>> output, and I can't see how one would handle nested tags (which is
>> necessary for any real-world use).
>>
>> I'd be interested if anyone has come up with a syntax for
>> programmatically generating HTML in Forth that's reasonable.
>
>A markup organized around white space delimited tags which can be
>translated into html by selecting a suitable wordlist as the markup
>dictionary seems like one approach ...
>
>\i{ Hello \b{ Mark \} \} \.
>
>... then you can run a simple token interpreter that tests for the
>lead escape, runs the literal token function on non-escaped
>characters, searches escaped strings in the wordlist, executes them if
>found, otherwise emits the remainder as a string.

It is a bit dirty but ciforth can do this with an empty prefix.
An empty prefix always matches.
: DUMMY  PARSE-NAME TYPE SPACE ; PREFIX IMMEDIATE.

Now comes the trick:
0 LATEST >NFA @ !       \ Trim "Dummy" to "".
If this is first in a wordlist, nothing gets past it
because it matches everything.

Maybe redefine SPACE such that we get a new line once in
80 chars.

>
>One of the things that can be stored on the token stack is the
>previous literate token function, so on thing an escaped command can
>do is put its own literate executive in place ...
>   \img{ example.jpg \}
>
>... would put the image source and options interpreter in place,
>popped off again by the token pop escape \}
>
>I've never experimented with it enough to be sure which output
>whitespace system is smoothest ~ a workable approach is to have first-
>token, next-token and extend-token functions in a vector|object, the
>first token in a sequence has no white space, subsequent tokens in a
>sequence has preceding white space, and escaped strings end up with no
>white space before or after, but there is likely a prettier looking
>approach.

I go for the embedded literal HTML, using multiple line strings.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#4434

John Passaniti <john.passaniti@gmail.com> writes:
>     100 <table>
> ...just feels wrong.  It doesn't directly map into the generated
> output, and I can't see how one would handle nested tags (which is
> necessary for any real-world use).
>
> I'd be interested if anyone has come up with a syntax for
> programmatically generating HTML in Forth that's reasonable.

Something similar to a typical xml dom library looks straightforward:

    s" table \<
       s" 100" s" width" attribute
       s" border" s" 1"  attribute
       s" tr \<
         s" red" s" bgcolor attribute
         s" td /<
           s" foobar" text
           />   \ end td tag
       />       \ end tr tag
    \>          \ end table
    s" p </>    \ new paragraph  (generates <p/>)

[toc] | [prev] | [next] | [standalone]

#4436

On Jul 26, 2:31 am, John Passaniti <john.passan...@gmail.com> wrote:
> Obviously that's a bit subjective,
> but you pointed out the issue in your message.  Prefix syntax like in
> your example...
>
>     100 <table>
>
> ...just feels wrong.  It doesn't directly map into the generated
> output, and I can't see how one would handle nested tags (which is
> necessary for any real-world use).
>

I think you're right. It's kinda neat, but ultimately would prove to
be more of a hindrance than a help. I think you'd soon tire of coding
a complete application like that.

I used to code ASP and would regularly wrap large HTML templates in
ASP code. The ASP would do a simple pattern match.

newForm(name:="frmCountries")
dropDownBox(name:="ddbCountries", contents:="USA,United Kingdom,
Canada")

Very nice, and allows one (once the templates have been developed) to
treat the HTML just an abstraction, and simply stay in "code land"
rather than worry about balancing tags!

Mark

[toc] | [prev] | [next] | [standalone]

#4445

In article <07e39c7f-9fe5-4a12-979b-4d543a04a813@t7g2000vbv.googlegroups.com>,
Mark Wills  <forthfreak@forthfiles.net> wrote:
>On Jul 26, 2:31=A0am, John Passaniti <john.passan...@gmail.com> wrote:
>> Obviously that's a bit subjective,
>> but you pointed out the issue in your message. =A0Prefix syntax like in
>> your example...
>>
>> =A0 =A0 100 <table>
>>
>> ...just feels wrong. =A0It doesn't directly map into the generated
>> output, and I can't see how one would handle nested tags (which is
>> necessary for any real-world use).
>>
>
>I think you're right. It's kinda neat, but ultimately would prove to
>be more of a hindrance than a help. I think you'd soon tire of coding
>a complete application like that.
>
>I used to code ASP and would regularly wrap large HTML templates in
>ASP code. The ASP would do a simple pattern match.
>
>newForm(name:=3D"frmCountries")
>dropDownBox(name:=3D"ddbCountries", contents:=3D"USA,United Kingdom,
>Canada")
>
>Very nice, and allows one (once the templates have been developed) to
>treat the HTML just an abstraction, and simply stay in "code land"
>rather than worry about balancing tags!

Balancing goes nicely with coroutines ( ;: in colorforth)
Sorry for the ciforth-ism but I just can't stand S" in this
kind of application.

: bold   "<b>" TYPE CO   "</b>" TYPE ;
: html   "<html>" TYPE CO   "</html>" TYPE ;

: aap   html bold "we gaan naar rome" TYPE ;

aap

<html><b>we gaan naar rome</b></html> OK

: co R> R> SWAP >R >R ;
s/ "/ S" /g

Groetjes Albert







>
>Mark


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#4458

Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: Yay! CGI forth interpreter success

[..]
> Balancing goes nicely with coroutines ( ;: in colorforth)
> Sorry for the ciforth-ism but I just can't stand S" in this
> kind of application.

> : bold   "<b>" TYPE CO   "</b>" TYPE ;
> : html   "<html>" TYPE CO   "</html>" TYPE ;

> : aap   html bold "we gaan naar rome" TYPE ;

> aap

> <html><b>we gaan naar rome</b></html> OK

> : co R> R> SWAP >R >R ;

I like it!  Wasn't crc mentioning/showing this trick a few years ago?

Why [S]" .." TYPE ? I think the following reads even nicer.

FORTH> : CO  2R> SWAP 2>R [ -opt ] ; \ prevent optimization  ok

FORTH> : bold ." <b>" CO ." </b>" ;  ok
FORTH> : html ." <html>" CO ." </html>" ;  ok
FORTH> : aap  html bold ." we gaan naar rome" ;  ok

FORTH> aap  <html><b>we gaan naar rome</b></html> ok

-marcel

[toc] | [prev] | [next] | [standalone]

#4484

On Jul 27, 3:33 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes Re: Yay! CGI forth interpreter success
>
> [..]
>
> > Balancing goes nicely with coroutines ( ;: in colorforth)
> > Sorry for the ciforth-ism but I just can't stand S" in this
> > kind of application.
> > : bold   "<b>" TYPE CO   "</b>" TYPE ;
> > : html   "<html>" TYPE CO   "</html>" TYPE ;
> > : aap   html bold "we gaan naar rome" TYPE ;
> > aap
> > <html><b>we gaan naar rome</b></html> OK
> > : co R> R> SWAP >R >R ;
>
> I like it!  Wasn't crc mentioning/showing this trick a few years ago?

I've been using it in Retro for several years now, though my name for
it is 'later', not 'co'.

-- crc

[toc] | [prev] | [next] | [standalone]

#4441

On 26/07/2011 02:31, John Passaniti wrote:
[...]

> I'd be interested if anyone has come up with a syntax for
> programmatically generating HTML in Forth that's reasonable.
>

I'm currently in the early stages of implementing an HTML generator for 
a club web-site I manage and have gone for a simple syntax such as:

<p Hello >

which would generate <p>Hello</p>

Tags like <p are Forth words in a tags wordlist. When <p is executed it 
generates <p> and calls a word called scan-element which repeatedly gets 
the next space delimited word, looks it up in the tags wordlist, if 
found it is executed otherwise it is copied to the output. > is a word 
in the tags wordlist which, when executed, causes an exit from 
scan-element returning to <p which then generates the closing </p>.

If, say, we want a class attribute to embolden the text we could write

<p <cl bolded > Hello >
which would generate
<p class="bold">Hello</p>

because <cl is a Forth word in the tags wordlist that generates class=" 
and then recursively calls scan-element. bold would be a class defined 
in the accompanying CSS file.

Initially there is a word called <html that kicks everything off by 
doing its stuff and calling scan-element. There is a template for the 
boilerplate at the beginning of an HTML file.

I don't propose to have any syntax checking in terms of which tags can 
be nested inside other tags so nonsense HTML could be generated from 
silly input. Since it is purely for my own use for a particular web-site 
that is acceptable to me.

As I said it is a work in progress and I don't see any show-stoppers so 
far, but I may change syntax if a better idea is suggested or if some 
existing software is recommended that has minimal markup.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#4442

On 26/07/2011 17:48, Gerry Jackson wrote:
[...]

> <p <cl bolded > Hello >

Sorry, a last minute incomplete edit. This should of course read

<p <cl bold > Hello >

[...]


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#4446

On Jul 26, 12:48 pm, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
> On 26/07/2011 02:31, John Passaniti wrote:
> [...]
>
> > I'd be interested if anyone has come up with a syntax for
> > programmatically generating HTML in Forth that's reasonable.
>
> I'm currently in the early stages of implementing an HTML generator for
> a club web-site I manage and have gone for a simple syntax such as:
>
> <p Hello >
>
> which would generate <p>Hello</p>
>
> Tags like <p are Forth words in a tags wordlist. When <p is executed it
> generates <p> and calls a word called scan-element which repeatedly gets
> the next space delimited word, looks it up in the tags wordlist, if
> found it is executed otherwise it is copied to the output. > is a word
> in the tags wordlist which, when executed, causes an exit from
> scan-element returning to <p which then generates the closing </p>.
>
> If, say, we want a class attribute to embolden the text we could write
>
> <p <cl bolded > Hello >
> which would generate
> <p class="bold">Hello</p>
>
> because <cl is a Forth word in the tags wordlist that generates class="
> and then recursively calls scan-element. bold would be a class defined
> in the accompanying CSS file.
>
> Initially there is a word called <html that kicks everything off by
> doing its stuff and calling scan-element. There is a template for the
> boilerplate at the beginning of an HTML file.
>
> I don't propose to have any syntax checking in terms of which tags can
> be nested inside other tags so nonsense HTML could be generated from
> silly input. Since it is purely for my own use for a particular web-site
> that is acceptable to me.
>
> As I said it is a work in progress and I don't see any show-stoppers so
> far, but I may change syntax if a better idea is suggested or if some
> existing software is recommended that has minimal markup.
>
> --
> Gerry

I've used something similar in the past. It worked pretty well. From
my old system:

( html ( head ( title ." test" ) )
  ( body ( h1 ." Home" )
    ( hr )
    a' class="bold"' ( p ." Welcome everyone" ) ) )

I had ( and ) handle parsing and creating the html tags. Your way
looks a little cleaner though, especially with regards to attribute
handling.

I've recently been experimenting with an implementation layered over
some of the features of my (non-standard) Forth dialect:

[ [ [ "test" ] title ] head
  [ [ "home" ] h1
    hr
    [ "Welcome everyone" ] "bold" attr:class p
  ] body
] html

While my new one works well overall, I'm still considering options for
declaring attributes.

-- crc

[toc] | [prev] | [next] | [standalone]

#4479

On 26/07/2011 20:02, crc wrote:
> On Jul 26, 12:48 pm, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
> wrote:
>> On 26/07/2011 02:31, John Passaniti wrote:
>> [...]
>>
>>> I'd be interested if anyone has come up with a syntax for
>>> programmatically generating HTML in Forth that's reasonable.
>>
>> I'm currently in the early stages of implementing an HTML generator for
>> a club web-site I manage and have gone for a simple syntax such as:
>>
>> <p Hello>
>>
>> which would generate<p>Hello</p>
>>
>> Tags like<p are Forth words in a tags wordlist. When<p is executed it
>> generates<p>  and calls a word called scan-element which repeatedly gets
>> the next space delimited word, looks it up in the tags wordlist, if
>> found it is executed otherwise it is copied to the output.>  is a word
>> in the tags wordlist which, when executed, causes an exit from
>> scan-element returning to<p which then generates the closing</p>.
>>
>> If, say, we want a class attribute to embolden the text we could write
>>
>> <p<cl bolded>  Hello>
>> which would generate
>> <p class="bold">Hello</p>
>>
>> because<cl is a Forth word in the tags wordlist that generates class="
>> and then recursively calls scan-element. bold would be a class defined
>> in the accompanying CSS file.
>>
>> Initially there is a word called<html that kicks everything off by
>> doing its stuff and calling scan-element. There is a template for the
>> boilerplate at the beginning of an HTML file.
>>
>> I don't propose to have any syntax checking in terms of which tags can
>> be nested inside other tags so nonsense HTML could be generated from
>> silly input. Since it is purely for my own use for a particular web-site
>> that is acceptable to me.
>>
>> As I said it is a work in progress and I don't see any show-stoppers so
>> far, but I may change syntax if a better idea is suggested or if some
>> existing software is recommended that has minimal markup.
>>
>> --
>> Gerry
>
> I've used something similar in the past. It worked pretty well. From
> my old system:
>
> ( html ( head ( title ." test" ) )
>    ( body ( h1 ." Home" )
>      ( hr )
>      a' class="bold"' ( p ." Welcome everyone" ) ) )
>
> I had ( and ) handle parsing and creating the html tags. Your way
> looks a little cleaner though, especially with regards to attribute
> handling.
>
> I've recently been experimenting with an implementation layered over
> some of the features of my (non-standard) Forth dialect:
>
> [ [ [ "test" ] title ] head
>    [ [ "home" ] h1
>      hr
>      [ "Welcome everyone" ] "bold" attr:class p
>    ] body
> ] html
>
> While my new one works well overall, I'm still considering options for
> declaring attributes.
>
> -- crc

While I don't understand how your Forth works, you are going for a 
postfix syntax. I am trying to avoid that. My approach has been driven 
from the requirements of the web site I manage. Typically I receive a 
contribution from a club member (often a MS Word document) that needs to 
go on the web site. Contributors are not usually programmers (indeed 
some are barely computer literate) and can't be expected to add either 
HTML markup or the stripped down markup I'm proposing. It's much easier 
for me to edit their offering, so I want an approach that requires 
minimal work on my part, hence the minimal markup I described.

As far as attributes are concerned, given that I have a limited number 
of styles used on the site I may well simplify things a bit more for the 
commonly used styles e.g. for a bold paragraph write:

<pb Hello >

to generate <p class="bold">Hello</p>

This can be implemented by <pb calling the more primitive tag words I 
described before.

I've looked on the internet for HTML generators and could only find the 
following:

Bernd Paysan's Forth Wiki Markup http://www.jwdt.com/~paysan/ which is 
documented in German. It does a similar job but I think I would have to 
spend time experimenting, examining code and examples before I could use it.

Forth Markup Language FML http://forthfreak.net/index.cgi?FML which 
seems to be written for Retro Forth (is that yours?) which AFAIK is not 
ANS Forth so not suitable for me. The LATER idea is nice but not ANS Forth.

The FFL XML/HTML writer which seems to be a lower level library 
providing code to write tags etc. which could be used by my code.

HTML generator http://drdobbs.com/web-development/212501814 which 
doesn't offer what I want.

Bernd Paysan's looks the most promising for me but, given the learning 
curve I'd rather continue with my HTML generator - the Forth curse 
strikes again :-)

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#4443

John Passaniti <john.passaniti@gmail.com> writes:
>On Jul 25, 8:17=A0am, Mark Wills <forthfr...@forthfiles.net> wrote:
> For a (simple) example with one Lua library:
>
>    name =3D "Mark"
>    P { "Hello ", B(name) }
>
>Which would produce:
>
>    <p>Hello <b>Mark</b></p>
[...]
>  Prefix syntax like in
>your example...
>
>    100 <table>
>
>...just feels wrong.  It doesn't directly map into the generated
>output, and I can't see how one would handle nested tags (which is
>necessary for any real-world use).

I don't know what you mean with "directly map", but about nesting, how
about:

s" Hello" name B P type

for your Lua example.  And that's postfix, not prefix.

>Another solution is to avoid the issue and instead come up with a
>template system.  There, you put raw HTML in the code but with some
>kind of escape to replace text with other text.  That has its charms,
>especially when you can reference templates inside other templates.
>But it's not quite the same thing and requires putting raw HTML in the
>code.

Yes, I am currently working on something like that:

... HTML stuff ... <forth> Forth code that outputs HTML </forth> HTML stuff

Of course in between <forth> and </forth> your library stuff would
still be useful, but apart from a few examples I am going to leave
that part to someone else.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

[toc] | [prev] | [next] | [standalone]

#4503

On Jul 25, 8:17 am, Mark Wills <forthfr...@forthfiles.net> wrote:
> On Jul 25, 3:08 am, Tarkin <tarkin...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hello all,
> >   I've been saying on here from time to time that I am
> > working on a modified version of jonesforth.
> > At long last, I have knocked together a decent enough
> > interpreter to begin testing a CGI interface...
>
> > : flow forth linux on web ;
>
> > Abstract:
> >   'flow' forth is a modified version of 'jonesforth' by Richard WM
> > Jones.
> > It is written in assembler, using Intel syntax and assembled by FASM.
> > FASM (v. 1.69.31) emits an elf32 object file, which I then link using
> > a custom build of vlink (http://sun.hasenbraten.de/vlink/).
> > The resulting executable is 13772 bytes, and runs on any
> > Linux sporting kernel 2.6 (can be rebuilt for 2.4).
> > flow is non-standard, and non-ans compliant.
>
> >  By pairing flow with Linux, it gains access to all of the system
> > calls,
> > process management features, and device drivers that Linux
> > provides. Particularly, flow can act as a CGI script processor,
> > for dynamic web scripting in forth.
>
> > I have performed only the most cursory of testing; however, the intial
> > results are *very* promising. My testing setup is:
> > Debian Linux (32 bit) 2.6.26-2-686 #1 SMP
> > Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
> > Intel PII (Deschutes) @ 400MHz.
> > lighttpd-1.4.19 (ssl)
>
> > 'lighty', as lighttpd is nicknamed, has 'mod_cgi' enabled,
> > with the following .conf file entry:
> > cgi.assign = ( ".4th" => "/usr/local/bin/flow" )
>
> > here is index.4th, a simple, bare-minimum cgi test:
> > --------------------8<----------------------------------------------
> > \ vim: set ft=forth: set ts=2:
> > : NEWL 13 EMIT 10 EMIT ;
> > ." HTTP/1.1 200 OK" NEWL
> > ." Content-Type: text/html; charset=UTF-8" NEWL
> > ." Connection: close" NEWL
> > ." X-Powered-By: flow-0.9" NEWL
> > NEWL
> > NEWL
> > ." <html>" CR
> > ."   <head>" CR
> > ."     <title>FORTH CGI</title>" CR
> > ."   </head>" CR
> > ."   <body>" CR
> > ."     <h3>It works!</h3>" CR
> > ."     <p><strong>Hello, Browser!!!</strong><br />" CR
> > ."     Forth CGI interpreter based on jonesforth, written by
> > Tarkin!!!.</p>" CR
> > ."   </body>" CR
> > ." <html>" CR
>
> > --------------------8<----------------------------------------------
>
> > It shows exactly what you expect that html to render as.
>
> > I modified the startup routine(s) to check ARGC, and if
> > it's > 1, loop through ARGV, and EVAL each file it can.
> > EVAL simply takes a string and length, transform into a
> > '\0'-terminated string, get a file descriptor for the filename,
> > and switch KEY to use that file descriptor to fetch characters.
> > On EOF, key is reset to use stdin (0).
>
> > The system is quick and precise ; however, errors are FATAL,
> > resulting in various Linux process-killers such as SEGFAULT
> > and 'floating point exception".
>
> > In a few days, I'll have a source tarball with all the necessary
> > softwaree to build it available.
>
> > TTFN,
> >   Tarkin
>
> Very very nice!
>
> Given most browsers 'forgiveness' with white space, you could define
> some HTML (at least the earlier ones, from 1.0/1.1) tags as Forth
> words:
>
> : <p>  ." <p>"  ;
> : </p> ." </p>" ;
>

Yes, that came next in testing! I also wrapped the headers like so:
--------------------------8<------------------------------------------
: .H1 ." HTTP/1.1 200 OK" NEWL;
: .H2 ." Content-Type: text/html; charset=utf-8" NEWL ;
: .H3 ." Connection: close" NEWL ;
: .H4 ." X-Powered-By: flow-0.9" NEWL ;
: .HTTP .H1 .H2 .H3 .H4 NEWL NEWL ;
\ tags already defined....
<html>
  <head>
      <title>flow CGI</title>
  </head>
  <body>
    <p><h3>It works!</h3>This is <strong>'Hello, browser!'</strong>
for forth CGI!</p>
  </body>
</html>
----------------------------
>8-----------------------------------------

> <p> Hello mother! </p> <p> Look at me! </p>
>
> Tags that take parameters might be a difficult though... Eg. <table
> width='100%'>
>
> Although, having said that...
>
> : <table> ( width% -- )
>   ." <table width='" . ." %'>" ;
>
> 100 <table>
>

Many ways, already bandied about, to skin that cat :^) ....

> Now you are writing HTML with Forth ;-)
>
> The point being, once you can *dynamically* render HTML using Forth
> processing (rather than just pushing strings out with .") then you
> truly have arrived at a true dynamic web processor.
>

Kinda splitting hairs, I think (just sayin').
Conditionally spitting out strings is the simplest, most primitive way
to dynamically generate HTML. Consider:

\ CSTRING converts addr,len to NULL-term'd string
\ STRLEN gives the string length of a NULL-term'd string

: ARRAY CREATE CELLS ALLOT DOES> SWAP CELLS + ;
: STRCPY CSTRING DUP STRLEN 1+ ROT SWAP CMOVE ;

VARIABLE R1 1 CELLS ALLOT
VARIABLE R2 1 CELLS ALLOT
VARIABLE R3 2 CELLS ALLOT

R1 S" ONE"   STRCPY
R2 S" TWO"   STRCPY
R3 S" THREE" STRCPY
3 NUMS S" THREE" CSTRING !

\ it might be my impl. but this seems backward for ! (STORE)...
3 ARRAY NUMS
R1 0 NUMS !
R2 1 NUMS !
R3 2 NUMS !

: ROWS
  0
  BEGIN
    2DUP = IF 2DROP EXIT THEN
    <TR> DUP 1+ SWAP <TD> DUP 48 + EMIT </TD> <TD> NUMS @ DUP STRLEN
TELL </TD> </TR>
  AGAIN
;

.HTTP
<html>
<head><title>Dynamic Table</title></head>
<body>

."    <table border=1>"
3 ROWS \ <--- dynamic row generation
."    </table>" \ I could have used </table> here,
\ but I prefer symmetry

</body>
</html>

\\ EOF

I think it's going to be a combination of one or more of the following
that will make or break this type of forth-CGI programming:
 1) ease of querying the environment variables (practically as MUST
for CGI)
 2) non-standard parsing of stdin (i.e. NOT _interpreting_ stdin )
 3) readability and easy implementation of conditionals/loops
 4) string handling facilities

I will start a new thread on string handling and factors thereof...


Before anyone asks or points out that my string-handling seems clumsy,
consider that environment strings under Linux are NULL-terminated
strings ; in for a penny, out for a pound - that is, since I
already have to deal with NULL-terminated strings for environment
variables and file manipulation, I use them elsewhere as well.

> Congratulations. This looks like great fun!
>

Thank you, and thanks to everyone for their input!

> Mark

TTFN,
  Tarkin

[toc] | [prev] | [next] | [standalone]

#4505

Tarkin <tarkin000@gmail.com> writes:

> On Jul 25, 8:17 am, Mark Wills <forthfr...@forthfiles.net> wrote:
>> On Jul 25, 3:08 am, Tarkin <tarkin...@gmail.com> wrote:
>> > here is index.4th, a simple, bare-minimum cgi test:
>> > --------------------8<----------------------------------------------
>> > \ vim: set ft=forth: set ts=2:
>> > : NEWL 13 EMIT 10 EMIT ;
>> > ." HTTP/1.1 200 OK" NEWL
>> > ." Content-Type: text/html; charset=UTF-8" NEWL
>> > ." Connection: close" NEWL
>> > ." X-Powered-By: flow-0.9" NEWL
>> > NEWL
>> > NEWL
>> > ." <html>" CR
>> > ."   <head>" CR
>> > ."     <title>FORTH CGI</title>" CR
>> > ."   </head>" CR
>> > ."   <body>" CR
>> > ."     <h3>It works!</h3>" CR
>> > ."     <p><strong>Hello, Browser!!!</strong><br />" CR
>> > ."     Forth CGI interpreter based on jonesforth, written by
>> > Tarkin!!!.</p>" CR
>> > ."   </body>" CR
>> > ." <html>" CR
>>
>> Very very nice!
>>
>> Given most browsers 'forgiveness' with white space, you could define
>> some HTML (at least the earlier ones, from 1.0/1.1) tags as Forth
>> words:
>>
>> : <p>  ." <p>"  ;
>> : </p> ." </p>" ;
>>
>
> Yes, that came next in testing! I also wrapped the headers like so:
> --------------------------8<------------------------------------------
> : .H1 ." HTTP/1.1 200 OK" NEWL;
> : .H2 ." Content-Type: text/html; charset=utf-8" NEWL ;
> : .H3 ." Connection: close" NEWL ;
> : .H4 ." X-Powered-By: flow-0.9" NEWL ;
> : .HTTP .H1 .H2 .H3 .H4 NEWL NEWL ;
> \ tags already defined....
> <html>
>   <head>
>       <title>flow CGI</title>
>   </head>
>   <body>
>     <p><h3>It works!</h3>This is <strong>'Hello, browser!'</strong>
> for forth CGI!</p>
>   </body>
> </html>

Are you really using Forth's text interpreter, here?  There's no space
after <title> for it to be recognized as a word.  If you're not using
Forth at this point, how will you embed any Forth logic?  If you've
extended the interpreter so that <title> is pulled off and then allowed
to do its own parsing of the bare ` flow CGI ' that follows, how does
its parser know to interpret some text as Forth?  I think of

  : title ." flow CGI" ;
  <html>
    <head> <title> title ( <-- executed.) </title> </head>
  <body>
    <p> .( It works!) </p>
  </body> </html>

You get a mileage from hitting space a few extra times.  It's suddenly
clear what's Forth and what isn't; you don't have to do anything special
to switch between HTML and Forth; porting becomes a matter of a prelude
with some definitions, rather than having to (temporarily?) extend or
duplicate or hack the system's text interpreter.  And rather than having
to edit the code to insert the spaces, which is an irritation for
version control.

> \ it might be my impl. but this seems backward for ! (STORE)...
> 3 ARRAY NUMS
> R1 0 NUMS !
> R2 1 NUMS !
> R3 2 NUMS !

  ! ( x a-addr -- )
  NUMS ( u -- a-addr )

What seems backwards?

> : ROWS
>   0
>   BEGIN
>     2DUP = IF 2DROP EXIT THEN
>     <TR> DUP 1+ SWAP <TD> DUP 48 + EMIT </TD> <TD> NUMS @ DUP STRLEN
> TELL </TD> </TR>
>   AGAIN
> ;

  [char] 0 +       \ clearer

  (.)              \ works for two-digit numbers.

  : rows ( n -- )  \ is this so awful?
    0 ?do <tr>
      <td> i (.) type </td>  \ may want a 1+ here
      <td> i nums @ dup strlen tell </td>
    </tr> loop ;

[toc] | [prev] | [next] | [standalone]

#4510

In article <fdd95e41-c342-4653-a551-454f54828409@a4g2000yqg.googlegroups.com>,
Tarkin  <tarkin000@gmail.com> wrote:
<SNIP>
>
>I think it's going to be a combination of one or more of the following
>that will make or break this type of forth-CGI programming:
> 1) ease of querying the environment variables (practically as MUST
>for CGI)
> 2) non-standard parsing of stdin (i.e. NOT _interpreting_ stdin )
> 3) readability and easy implementation of conditionals/loops
> 4) string handling facilities

Add
  5) Light weight startup or turnkey.

ciforth does a good job on all accounts.

"HOME" GET-ENV TYPE
/home/albert OK
It doesn't get any better.

PREFIX allows for "non-standard parsing" while doing
ordinary interpreting. PREFIX is non-standard, but it is
the only non-standard word you need.

Use of loops and conditionals during interpret mode by
compilation to a temp area, transparently.

$@ $! $/ $C+ $+!
Simplistic and easy to use.

30 K executable at most. A turnkey is a 30+X K executable,
if you can't stand the cost of loading GET-ENV from a
library.

>
>I will start a new thread on string handling and factors thereof...

Don't go overboard in the string handling. Next time you wake up
it is Xmas 2025.

>Before anyone asks or points out that my string-handling seems clumsy,
>consider that environment strings under Linux are NULL-terminated
>strings ; in for a penny, out for a pound - that is, since I
>already have to deal with NULL-terminated strings for environment
>variables and file manipulation, I use them elsewhere as well.

I seriously doubt that decision. Using adr,len pair is a
natural for Forth internals. GET-ENV produces an adr,len
pair and I never looked back.
(You can steal you GET-ENV from ciforth library, it is really
pretty trivial.)

>
>TTFN,
>  Tarkin

Have fun!
Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#4513

On Jul 25, 8:17 am, Mark Wills <forthfr...@forthfiles.net> wrote:
> On Jul 25, 3:08 am, Tarkin <tarkin...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hello all,
> >   I've been saying on here from time to time that I am
> > working on a modified version of jonesforth.
> > At long last, I have knocked together a decent enough
> > interpreter to begin testing a CGI interface...
>
> > : flow forth linux on web ;
>
> > Abstract:
> >   'flow' forth is a modified version of 'jonesforth' by Richard WM
> > Jones.
> > It is written in assembler, using Intel syntax and assembled by FASM.
> > FASM (v. 1.69.31) emits an elf32 object file, which I then link using
> > a custom build of vlink (http://sun.hasenbraten.de/vlink/).
> > The resulting executable is 13772 bytes, and runs on any
> > Linux sporting kernel 2.6 (can be rebuilt for 2.4).
> > flow is non-standard, and non-ans compliant.
>
> >  By pairing flow with Linux, it gains access to all of the system
> > calls,
> > process management features, and device drivers that Linux
> > provides. Particularly, flow can act as a CGI script processor,
> > for dynamic web scripting in forth.
>
> > I have performed only the most cursory of testing; however, the intial
> > results are *very* promising. My testing setup is:
> > Debian Linux (32 bit) 2.6.26-2-686 #1 SMP
> > Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
> > Intel PII (Deschutes) @ 400MHz.
> > lighttpd-1.4.19 (ssl)
>
> > 'lighty', as lighttpd is nicknamed, has 'mod_cgi' enabled,
> > with the following .conf file entry:
> > cgi.assign = ( ".4th" => "/usr/local/bin/flow" )
>
> > here is index.4th, a simple, bare-minimum cgi test:
> > --------------------8<----------------------------------------------
> > \ vim: set ft=forth: set ts=2:
> > : NEWL 13 EMIT 10 EMIT ;
> > ." HTTP/1.1 200 OK" NEWL
> > ." Content-Type: text/html; charset=UTF-8" NEWL
> > ." Connection: close" NEWL
> > ." X-Powered-By: flow-0.9" NEWL
> > NEWL
> > NEWL
> > ." <html>" CR
> > ."   <head>" CR
> > ."     <title>FORTH CGI</title>" CR
> > ."   </head>" CR
> > ."   <body>" CR
> > ."     <h3>It works!</h3>" CR
> > ."     <p><strong>Hello, Browser!!!</strong><br />" CR
> > ."     Forth CGI interpreter based on jonesforth, written by
> > Tarkin!!!.</p>" CR
> > ."   </body>" CR
> > ." <html>" CR
>
> > --------------------8<----------------------------------------------
>
> > It shows exactly what you expect that html to render as.
>
> > I modified the startup routine(s) to check ARGC, and if
> > it's > 1, loop through ARGV, and EVAL each file it can.
> > EVAL simply takes a string and length, transform into a
> > '\0'-terminated string, get a file descriptor for the filename,
> > and switch KEY to use that file descriptor to fetch characters.
> > On EOF, key is reset to use stdin (0).
>
> > The system is quick and precise ; however, errors are FATAL,
> > resulting in various Linux process-killers such as SEGFAULT
> > and 'floating point exception".
>
> > In a few days, I'll have a source tarball with all the necessary
> > softwaree to build it available.
>
> > TTFN,
> >   Tarkin
>
> Very very nice!
>

Thank you!

> Given most browsers 'forgiveness' with white space, you could define
> some HTML (at least the earlier ones, from 1.0/1.1) tags as Forth
> words:
>
> : <p>  ." <p>"  ;
> : </p> ." </p>" ;
>
> <p> Hello mother! </p> <p> Look at me! </p>
>

Yes, that was the next logical step in testing.
I even wrapped the headers, a word for each, and then
defined the word .HTTP to push them all out in sequence.

> Tags that take parameters might be a difficult though... Eg. <table
> width='100%'>
>
> Although, having said that...
>
> : <table> ( width% -- )
>   ." <table width='" . ." %'>" ;
>
> 100 <table>
>

That and other techniques are discussed.
I'm caught in a bind ; by blending HTML and forth code,
it will just be a diluted PHP with forth syntax.
However, I think there is a chance for some innovation....

> Now you are writing HTML with Forth ;-)
>
> The point being, once you can *dynamically* render HTML using Forth
> processing (rather than just pushing strings out with .") then you
> truly have arrived at a true dynamic web processor.
>

I am splitting hairs, here, but (conditionally) pushing strings
*is* dynamically rendering HTML. Generating tags is more akin
to data hiding, I think?....

> Congratulations. This looks like great fun!
>
> Mark

Thanks again, and thanks everyone for their input!

I think I've got some old ideas that will be new all over again.
1) maybe have a page buffer, and blit all your strings to it.
   Once you've injected fragments and dynamically generated HTML,
   hose it through stdout, either all at once, or reusing the buffer
   for large amounts of response text (file download, perhaps?).

2) I liked Albert VdH's and/or crc's couroutine tag balancing act,
   but I had problems with the body getting tangled in the title...
   So, why not have a tag stack? As you push out tags, push the
   end tags (address of, anyway) onto the tag stack. Pop the
   tag stack as needed. Since HTML attributes are usually (always?)
   in the opening tag, this puts the onus on the word that creates
   tags to parse and fill the attributes.

I've already got a primitive tag stack that is 128 cells deep.
I'm thinking of adding most, if not all, of the HTML tags to
some sort of string repository in my executable. It'll bloat,
but then generating tags consists of fetching the tag string
address, DUP it and push it on the tag stack, fetch the string
and decorate it with '<', parse attributes, decorate attributes
with qoutes, decorate with '>', blit the tag
(directly to stdout or indirectly to the page buffer),and then
at the appropriate time, pop the tag stack, decorate with '<' and '>',
and so on.

something like:
<: html :>              \ ( -- [html] )
<: head :>              \ ( [html] -- [html][head ] )
<: link rel=stylesheet type=text/css :> \ (1) see below
;>                      \ pop [head] ( [html][head] -- [html] )
<: body class=foo :>    \ parse attributes ( [html] -- [html][body] )
<: p Hello, browser! ;> \ push+pop of [p]  ( [html][body] -- [html]
[body] )
;> ;>                    \ pop [body] pop [html] ( [html][body] -- )
\ end of example

Should spit out:

<html>
<head>
<link rel="stylesheet" type="text/css>
</head>
<body class="foo">
<p>Hello, browser!</p>
</body>
</html>
<body class="foo">
<p>Hello, browser!</p>
</body>
</html>

So, I've introduced some tag-stack words:
<: enter tag parsing (definition?) string fetch, decorate & blit

:> exit tag parsing, push tag string on tag stack (if needed)
(1) tags like <link> and <br>, in HTML 4.01, don't have a closing tag!

;>
pop tag stack, decorate, and blit

Ugly as sin. Simple. Forth-ish, perhaps.

Then there is always the technique of using semi-static HTML,
manipulated by DOM and ECMAscript, which simply uses
XMLHTTPRequest objects to call F/CGI urls for XML, HTML, JSON,
or plain text data, dynamically modifying the document client-side.

Perhaps a JSON DSL in Forth?

TTFN,
  Tarkin

[toc] | [prev] | [next] | [standalone]

#4565

On Jul 31, 2:11 pm, Tarkin <tarkin...@gmail.com> wrote:
> pop tag stack, decorate, and blit

Minor point, but blit?  Traditionally, "blit" refers to moving blocks
of bitmap data (BLock Image Transfer).  Do you mean copying strings?

> Perhaps a JSON DSL in Forth?

That should be interesting.  Given the flexibility of JSON, you will
likely have to come up with a way to attribute values with their type
(object, array, string, (floating point) number, true, false, null)
and some form of key/value store for objects.  Or not.  In the finest
tradition of Forth, you're free to implement just the subset of
functionality your application needs.  It just wouldn't be be JSON at
that point.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web