any try this forth webserver? the code looks incomprehensible to me

On Aug 18, 12:48 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> gavino wrote:
> > sweet, did you use it to provide dynamic pages or just static sofar?
>
> Static pages. There's this simple 4-line "dynamic content" package, but to
> be realistic, really useful dynamic content should at least have code to
> handle user logins and cookies, and that includes the refrigerator
> application (data base in files and directories is completely sufficient
> for many simpler tasks, but login is necessary if you want to do more than
> just monitoring, e.g. adjust the temperature or whatever). My philosophy is
> that you should pre-create as much "dynamic" content as possible - the
> number of updates is far less than the number of read accesses.
>
> The only excuse is when you can't predict how the dynamic content will look
> like, e.g. when you randomly insert ads, or when you give access to tons of
> data like web-mail interfaces or web-version control or this sort of
> application, and duplicating all that data is not feasible (especially in
> the web-VCS interface, where you can e.g. compare two different versions of
> the same file, which is stored as compact representation in the VCS, but
> has a combinatoric explosion in the web interface).
>
> What I should do to show how it works on dynamic content is to combine
> httpd.fs with wf.fs (the wiki format translater), and add the stuff for an
> actual simple wiki, like users, logins, and cookies. Certainly, if you are
> not logged in and just looking at the most recent versions of pages, you'll
> see static content in this example, too.
>
> > how many k does a single connection take up roughly?
>
> Depends on which Gforth engine you use. Execution speed is not really an
> issue here, so let's use gforth-itc. top tells me 1356k res, thereof 620k
> shared, but I don't really trust it. Examining /proc/<pid>/maps tells me
> that 200k are dynamically allocated by Gforth, when httpd.fs is compiled.
>
> > I admin apache prefork boxes that seem to take 20M eachchild when
> > running php apps.
>
> Yes, I can confirm that; that's my experience as well. On a 2GB machine, you
> can sustain 100 concurrent connections. With httpd.fs, you can probably
> sustain 10k concurrent connections on the same machine. That's enough for a
> hard slashdot DDoS attack (remember, bandwidth is no problem in this case,
> so you don't need to care about startup time and such; this is all in red
> alert mode then, anyway).
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/

10,000 YEAH BABY! but in its defense php was talking to db etc with
each apache child....this 10k would be static right?

gavino wrote:
> 10,000 YEAH BABY! but in its defense php was talking to db etc with
> each apache child....this 10k would be static right?

The 10k are static. So when you talk to a database, you have to count how
much memory the db takes per client, and what percentage of time the web
serves would be talking to the db. You probably could write the performance
critical parts of the db as a small Forth program, to reduce that load.
Also, the dynamic content part is yet not optimized to keep the connection
alive, this costs more Gforth starts.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Aug 19, 12:48 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> gavino wrote:
> > 10,000 YEAH BABY! but in its defense php was talking to db etc with
> > each apache child....this 10k would be static right?
>
> The 10k are static. So when you talk to a database, you have to count how
> much memory the db takes per client, and what percentage of time the web
> serves would be talking to the db. You probably could write the performance
> critical parts of the db as a small Forth program, to reduce that load.
> Also, the dynamic content part is yet not optimized to keep the connection
> alive, this costs more Gforth starts.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/

unless you used a FORTH databasE!!
damit i need to spend more time on starting forth and thinking forth
gaaaa!!
j fox told me that forth can absolutely rock on modern huge ram
hardware and uartus from freenode forth chat said same....
I bet postgresql is great but that any websites a forth db could do a
lot of heavy lifting.....and if one could be made to share N
nodes....it would scael accross 2+ boxes.....
a dream of mine as a sysamin is to stop seeing %% of the hardware
working hard while the 95% sit idle.....
how to make software use 2+ boxes is beyond me though
I look at stud like ruby queue so I know others are thinking along
same lines....http://www.codeforpeople.com/lib/rub...q-3.4.0/README

On Aug 19, 12:48 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> gavino wrote:
> > 10,000 YEAH BABY! but in its defense php was talking to db etc with
> > each apache child....this 10k would be static right?
>
> The 10k are static. So when you talk to a database, you have to count how
> much memory the db takes per client, and what percentage of time the web
> serves would be talking to the db. You probably could write the performance
> critical parts of the db as a small Forth program, to reduce that load.
> Also, the dynamic content part is yet not optimized to keep the connection
> alive, this costs more Gforth starts.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/

once I finish starting forth and thinking forth should I know enough
to read the code of your webserver.....or are there things I need to
learn elsewhere to do that?

gavino wrote:
> On Aug 19, 12:48 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> gavino wrote:
>>> 10,000 YEAH BABY! but in its defense php was talking to db etc with
>>> each apache child....this 10k would be static right?
>> The 10k are static. So when you talk to a database, you have to count how
>> much memory the db takes per client, and what percentage of time the web
>> serves would be talking to the db. You probably could write the performance
>> critical parts of the db as a small Forth program, to reduce that load.
>> Also, the dynamic content part is yet not optimized to keep the connection
>> alive, this costs more Gforth starts.
>>
>> --
>> Bernd Paysan
>> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/
>
> once I finish starting forth and thinking forth should I know enough
> to read the code of your webserver.....or are there things I need to
> learn elsewhere to do that?

Starting Forth and Thinking Forth are both pretty dated. Some of the
worst problems with SF are fixed in the version posted at www.forth.com,
but many anachronisms (especially assumptions about how implementations
are structured) remain.

My books (Forth Application Techniques and Forth Programmer's Handbook)
both represent modern systems and usage, and also go into a lot more
detail. There is also a new book at MPE's web site.

But to really get a feel for things, it would help to read the simpler
examples that come with any of the mainstream Forths, and then write
some code on your own. Trying to dive in by reading code for something
as complex as a web server (even a simple web server) is like trying to
jump onto a moving train. Learn to walk before trying to run.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Aug 21, 2:51 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> gavino wrote:
> > On Aug 19, 12:48 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> >> gavino wrote:
> >>> 10,000 YEAH BABY! but in its defense php was talking to db etc with
> >>> each apache child....this 10k would be static right?
> >> The 10k are static. So when you talk to a database, you have to count how
> >> much memory the db takes per client, and what percentage of time the web
> >> serves would be talking to the db. You probably could write the performance
> >> critical parts of the db as a small Forth program, to reduce that load.
> >> Also, the dynamic content part is yet not optimized to keep the connection
> >> alive, this costs more Gforth starts.
>
> >> --
> >> Bernd Paysan
> >> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/
>
> > once I finish starting forth and thinking forth should I know enough
> > to read the code of your webserver.....or are there things I need to
> > learn elsewhere to do that?
>
> Starting Forth and Thinking Forth are both pretty dated. Some of the
> worst problems with SF are fixed in the version posted atwww.forth.com,
> but many anachronisms (especially assumptions about how implementations
> are structured) remain.
>
> My books (Forth Application Techniques and Forth Programmer's Handbook)
> both represent modern systems and usage, and also go into a lot more
> detail. There is also a new book at MPE's web site.
>
> But to really get a feel for things, it would help to read the simpler
> examples that come with any of the mainstream Forths, and then write
> some code on your own. Trying to dive in by reading code for something
> as complex as a web server (even a simple web server) is like trying to
> jump onto a moving train. Learn to walk before trying to run.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

ok
thank you
will the techniques in your books allow me to work with helforth/
gforth or are they only compatible with forth inc. forth?

On Aug 21, 2:51 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> gavino wrote:
> > On Aug 19, 12:48 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> >> gavino wrote:
> >>> 10,000 YEAH BABY! but in its defense php was talking to db etc with
> >>> each apache child....this 10k would be static right?
> >> The 10k are static. So when you talk to a database, you have to count how
> >> much memory the db takes per client, and what percentage of time the web
> >> serves would be talking to the db. You probably could write the performance
> >> critical parts of the db as a small Forth program, to reduce that load.
> >> Also, the dynamic content part is yet not optimized to keep the connection
> >> alive, this costs more Gforth starts.
>
> >> --
> >> Bernd Paysan
> >> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/
>
> > once I finish starting forth and thinking forth should I know enough
> > to read the code of your webserver.....or are there things I need to
> > learn elsewhere to do that?
>
> Starting Forth and Thinking Forth are both pretty dated. Some of the
> worst problems with SF are fixed in the version posted atwww.forth.com,
> but many anachronisms (especially assumptions about how implementations
> are structured) remain.
>
> My books (Forth Application Techniques and Forth Programmer's Handbook)
> both represent modern systems and usage, and also go into a lot more
> detail. There is also a new book at MPE's web site.
>
> But to really get a feel for things, it would help to read the simpler
> examples that come with any of the mainstream Forths, and then write
> some code on your own. Trying to dive in by reading code for something
> as complex as a web server (even a simple web server) is like trying to
> jump onto a moving train. Learn to walk before trying to run.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

I went ahead and got a copy of the handbook.

gavino wrote:
....
> ok
> thank you
> will the techniques in your books allow me to work with helforth/
> gforth or are they only compatible with forth inc. forth?

All of our books cover ANS Forth. Discussion of FORTH, Inc.-specific
features (many of which also appear in other Forths) are marked as such.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Aug 21, 4:31 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> gavino wrote:
>
> ...
>
> > ok
> > thank you
> > will the techniques in your books allow me to work with helforth/
> > gforth or are they only compatible with forth inc. forth?
>
> All of our books cover ANS Forth. Discussion of FORTH, Inc.-specific
> features (many of which also appear in other Forths) are marked as such.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

both on way via amazon
I've got an archlinux box at home with 3Ghz chip and 2G ram.
At work intel core duo 2.4gz +2G ram.
do forthers do app in memory liek prevalence layer / prevayler, while
keeping blobs on disk?