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

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

Using Forth in the current year.

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

Contents

  Using Forth in the current year. Julian Fondren <julian.fondren@gmail.com> - 2015-11-30 14:35 -0800
    Re: Using Forth in the current year. Ron Aaron <rambamist@gmail.com> - 2015-12-01 06:43 +0200
    Re: Using Forth in the current year. Melzzzzz <mel@zzzzz.com> - 2015-12-01 06:13 +0100
      Re: Using Forth in the current year. rickman <gnuarm@gmail.com> - 2015-12-01 01:38 -0500
    Re: Using Forth in the current year. Paul Rubin <no.email@nospam.invalid> - 2015-11-30 21:22 -0800
    Re: Using Forth in the current year. Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 05:45 -0800
      Re: Using Forth in the current year. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-01 15:01 +0000
        Re: Using Forth in the current year. Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 08:30 -0800
        Re: Using Forth in the current year. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 16:35 +0000
    Re: Using Forth in the current year. Doug Hoffman <glidedog@gmail.com> - 2015-12-02 06:29 -0500
    Re: Using Forth in the current year. Hans Bezemer <the.beez.speaks@gmail.com> - 2015-12-05 13:34 +0100
      Re: Using Forth in the current year. Julian Fondren <julian.fondren@gmail.com> - 2015-12-05 05:56 -0800

#43988 — Using Forth in the current year.

Hello clf,

Have you heard that Forth can't be used for real applications,
because people are too caught up in having to come up with their own
data structures?  Have you heard that no Forth teaches the use of
'structs'?

I spent a week, working after work, and one weekend, writing a Forth
webserver.  As it only took me about an hour to achieve similar ends
with Erlang, this probably isn't impressive.  But the Forth webserver
runs in 22MB fixed memory and the Erlang webserver starts out using
1.1GB of RAM.  npm's 'http-server', written in Node.js, starts out
consuming 772MB of RAM.

Have you heard that those differences in memory use doesn't matter?

I say 'fixed memory' because the Forth webserver has a bunch of
constants and limits in it.  HTTP requests can only be up to some
multiple of KB in size; there can only ever be a hundred
simultaneous connections; and so on.

Have you heard that limits like this are bad design?  Have you heard
of the "Zero, One, Many" rule by which a webserver must handle
infinitely many connections sending HTTP requests without bounds?

Have you heard that there's no place for Forth outside of embedded
hardware?  If you've got even 1MB of flash, isn't it time to use a
'real language'?


1. Data structures.

The core of the webserver is pollserver.fs, which uses the Unix
poll() facility.  This facility is used mainly because its data
structures and values are well-documented, as opposed to select() for
example where you'll told to use some magic C macros, and nevermind
what they do.  poll() works on an array of pollfd structures:

  class pollfd
    variable fd        \ an actual socket
    hvariable events   \ states the server is interested in
    hvariable revents  \ states poll() found to apply to the socket
  end-class

  class pollserver
    max-clients 1+ pollfd builds[] pollfds
    max-clients 1+ client builds[] clients
  end-class

That's two arrays, both of MAX-CLIENTS 1+ size.  The clients array,
by mirroring the pollfd array, associates extra state with
connections.  Since this is a webserver, that state is what's needed
by HTTP connections:

  class client
    http-request builds request
    variable socket  \ pollfd
    variable reading \ or writing?
    variable created \ when
    variable fd      \ source file
    variable written \ bytes sent
    variable status  \ response status code
    variable peer    \ connected IP
    /write cell+ buffer: buffer
  end-class

To 'route' requests, to say that GET http://mydomain.com/blah should
be replied to with a 404, but that POST http://mydomain.com/comment
should accept the postdata and email it somewhere, and so on, should
there's also a simple linked list of routes:

  class route
    variable next
    variable 'name
    variable match-xt
    variable fulfill-xt
  end-class

  class routelist
    variable list
  end-class

If a route matches a request, then it's asked to fulfill the request.
If it doesn't, the next route is tried.  ROUTELIST holds the head of
the list, and methods to extend it and to make requests run the
gauntlet.

That's about it.  Structs, arrays of structs, and a list.  The
structs and arrays were all done with built-in SWOOP features, which
are documented in manuals that come with SwiftForth.  Looking around
at other OO facilities, I note that oof.fs also has explicit array
support, but that most others don't seem to.  Probably because
adjacent allocations of objects, under other systems, don't normally
have OO-related overhead for methods or whatever.

I don't see explicit support for lists, but gforth has an example
implementation of a list in its object.fs documentation.

By the way, although http://soton.mpeforth.com/flag/swoop/index.html
still doesn't have a gforth compatibility layer, I've written one.
It's an easy adaptation of the VFX layer.  Portable SWOOP is only
missing [OBJECTS ... OBJECTS] syntax and some of the extensibility
and extras that flavors give ASWOOP.


2. Memory usage.

For $10/month or so, you can get an account on a shared server that
has 64GB of RAM.  But, it's running MySQL and Apache already,
configured for thousands of sites already.  And by policy you're not
to have long-running processes, since people would of course have
servers at 1GB each if allowed, so you have to use CGI for dynamic
content.  Here, no, memory pretty much doesn't matter.  You would
strain something, trying to write a Forth CGI program that used as
much RAM as PHP does.

Although bugs still happen.  There's a Perl script that comes with
cPanel that makes an SQL query and just stuffs the answer, however
large it is, in a string.  Under certain conditions that SQL query
returns infinite data, and Perl will sit there and slowly use all of
the memory on the server.  These servers are so busy that when the
script's memory usage puts pressure on the filesystem cache, the
server will be overcome by direct disk I/O and will begin to spiral
to its death.

For $10/year, you can get a VPS with 1GB of RAM.

For $3/year, you can get a VPS with 128MB of RAM.  There's also a
64MB option.

Even with the $10/year option, 1GB of RAM is pretty tight when you
need sshd, some other minor services, and a database server, in
addition to your 1GB-resident webserver.

Even with the 64GB shared server, suppose you were actually in the
webhosting business?  There exist in the world servers that provide
free hosting for businesses in third-world countries, in a
partnership with tech companies.  These servers have, almost
entirely, websites made entirely out of static content.  And they
have multiple tens of thousands of them.  When Apache for whatever
reason must restart, it can take more than ten minutes for it to pull
itself together, just reading through its enormous library of virtual
hosts.  Even the /etc/passwd file takes time to process.

Does 'compilation speed' not matter when it comes to virtual host
configurations?

Apache has a defect.  It uses dynamic memory when it processes its
configuration.  It then doesn't free this memory, but never uses it
ever again.  So Linux eagerly shoves that unused memory into swap
space.  Apache also forks constantly, in order to run PHP programs as
separate processes with the permissions of a particular user.  When
Apache has more than a 100MB of unused garbage in swap, the speed of
its forks slow dramatically.  Which means that 'time to first byte',
a figure that waits on Apache processing a request, and then on a
fork, and then on a PHP process, and then on that process's output,
is also increased dramatically.

Memory doesn't matter -- but if you allocate and then stop using
a mere 100MB, people suddenly complain about page load times.  You
can restart Apache to pull it out of swap, but then you have to wait
for it to compile its virtual host configuration again.

And what about that long-running-process policy?  If you have all of
64GB of RAM, and only 64 customers to that server, then you can't
encourage them to run their own Node.js Express servers.  You won't
have RAM for anything else.  But what if 64 persistent webservers
only took a little over 1.3GB of RAM?  You could have NginX dispatch
requests to each customer's personal webserver, and which can fork
off PHP processes or whatever if it needs to.  If it has the same
swap defect and starts to slow down, restarting it is much faster
because it has a single user's configurations to consider, and the
associated outage is confined to a single user.

You just can't have per-customer Node webservers.  You really could
have per-customer Forth webservers.


3. Zero, One, Many

If it's appropriate for a program to exhaust all of a server's
resources and then crash (or cause the server die) in response to an
absurd request, then you can follow this rule.  When that isn't
appropriate, you can't.  When there are also malicious requests, you
can't.

Servers have real, physical limitations, and so server software -
MySQL, Apache, exim, and friends - have software limitations.  On
occasion someone will, on a server with 16GB of RAM, configure Apache
or MySQL to use up to 128GB of RAM.  This never ends well.  MySQL
sometimes warns you about that -- "hey, according to these settings,
I can use up to this amount of memory.  I hope that's OK."  But it's
rarely obvious.  There is not actually a "use up to this much RAM"
configuration; there are connection limits, thread limits, etc.

And on a dedicated server, the ideal is not really to have your
servers use 100% of your resources.  Even if you could hit that
target exactly, it would mean that you had nothing left for
administration.  Nothing left for software upgrades or periodic
maintenance.  But even trying for that is bad: it would mean that you
had no RAM left for your OS to spend on filesystem cache.


4. Forth

All continues to matter that "doesn't matter anymore".  So Forth is
pretty good, and you should use it.  It will still be good in five
years when a typical server will have a full 1TB of RAM.


Cheers,
Julian

[toc] | [next] | [standalone]

#43994

On 01/12/2015 00:35, Julian Fondren wrote:
> Hello clf,
> 
> Have you heard that Forth can't be used for real applications,
> because people are too caught up in having to come up with their own
> data structures?  Have you heard that no Forth teaches the use of
> 'structs'?

Wow, Julian - excellent article!  Can you post it somewhere where I can
link to it?

Thanks!

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

#43995

On Mon, 30 Nov 2015 14:35:12 -0800 (PST)
Julian Fondren <julian.fondren@gmail.com> wrote:

> Hello clf,
> 
> Have you heard that Forth can't be used for real applications,
> because people are too caught up in having to come up with their own
> data structures?  Have you heard that no Forth teaches the use of
> 'structs'?

[root@maxa-pc ~]# pacman -Ss forth
[root@maxa-pc ~]# yaourt forth
1 aur/4th 3.62.0-4 (Out of Date) (7)
    A Forth Compiler
2 aur/ficl 4.1.0-1 (0)
    Forth Inspired Command Language
3 aur/gforth 0.7.3-1 [installed] (34)
    Fast and portable implementation of the ANS Forth language
4 aur/pforth-git c232a93-1 (0)
    A portable implementation of the Forth programming language written
in ANSI C 5 aur/retro-bzr 453-1 (0)
    Retro is a portable, stack-based language with roots in Forth.
==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
==> -------------------------------------------------------
==> 

Seems that problem with forth is that there is no compiler for it
on Linux....
What counts is availability of usable libraries and compilers.

> 
> I spent a week, working after work, and one weekend, writing a Forth
> webserver.  As it only took me about an hour to achieve similar ends
> with Erlang, this probably isn't impressive.

If you have http server in stdlib, like in Golang, you need 5
minutes ;)

  But the Forth webserver
> runs in 22MB fixed memory and the Erlang webserver starts out using
> 1.1GB of RAM.  npm's 'http-server', written in Node.js, starts out
> consuming 772MB of RAM.

Golang http server starts with 4mb and grows to 40mb.
rwasa, written in assembler takes 3mb and starts with 0.5mb.

> 
> Have you heard that those differences in memory use doesn't matter?

What matters is reqs/sec mostly.

> 
> I say 'fixed memory' because the Forth webserver has a bunch of
> constants and limits in it.  HTTP requests can only be up to some
> multiple of KB in size; there can only ever be a hundred
> simultaneous connections; and so on.
> 
> Have you heard that limits like this are bad design?  Have you heard
> of the "Zero, One, Many" rule by which a webserver must handle
> infinitely many connections sending HTTP requests without bounds?

That depends on site. If site is busy, having certain limits is same as
DOS...

> 
> Have you heard that there's no place for Forth outside of embedded
> hardware?  If you've got even 1MB of flash, isn't it time to use a
> 'real language'?

Forth is *slow*. That kills it's usage for me...

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

#43998

On 12/1/2015 12:13 AM, Melzzzzz wrote:
> On Mon, 30 Nov 2015 14:35:12 -0800 (PST)
> Julian Fondren <julian.fondren@gmail.com> wrote:
>
>> Hello clf,
>>
>> Have you heard that Forth can't be used for real applications,
>> because people are too caught up in having to come up with their own
>> data structures?  Have you heard that no Forth teaches the use of
>> 'structs'?
>
> [root@maxa-pc ~]# pacman -Ss forth
> [root@maxa-pc ~]# yaourt forth
> 1 aur/4th 3.62.0-4 (Out of Date) (7)
>      A Forth Compiler
> 2 aur/ficl 4.1.0-1 (0)
>      Forth Inspired Command Language
> 3 aur/gforth 0.7.3-1 [installed] (34)
>      Fast and portable implementation of the ANS Forth language
> 4 aur/pforth-git c232a93-1 (0)
>      A portable implementation of the Forth programming language written
> in ANSI C 5 aur/retro-bzr 453-1 (0)
>      Retro is a portable, stack-based language with roots in Forth.
> ==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
> ==> -------------------------------------------------------
> ==>
>
> Seems that problem with forth is that there is no compiler for it
> on Linux....
> What counts is availability of usable libraries and compilers.
>
>>
>> I spent a week, working after work, and one weekend, writing a Forth
>> webserver.  As it only took me about an hour to achieve similar ends
>> with Erlang, this probably isn't impressive.
>
> If you have http server in stdlib, like in Golang, you need 5
> minutes ;)
>
>    But the Forth webserver
>> runs in 22MB fixed memory and the Erlang webserver starts out using
>> 1.1GB of RAM.  npm's 'http-server', written in Node.js, starts out
>> consuming 772MB of RAM.
>
> Golang http server starts with 4mb and grows to 40mb.
> rwasa, written in assembler takes 3mb and starts with 0.5mb.
>
>>
>> Have you heard that those differences in memory use doesn't matter?
>
> What matters is reqs/sec mostly.
>
>>
>> I say 'fixed memory' because the Forth webserver has a bunch of
>> constants and limits in it.  HTTP requests can only be up to some
>> multiple of KB in size; there can only ever be a hundred
>> simultaneous connections; and so on.
>>
>> Have you heard that limits like this are bad design?  Have you heard
>> of the "Zero, One, Many" rule by which a webserver must handle
>> infinitely many connections sending HTTP requests without bounds?
>
> That depends on site. If site is busy, having certain limits is same as
> DOS...
>
>>
>> Have you heard that there's no place for Forth outside of embedded
>> hardware?  If you've got even 1MB of flash, isn't it time to use a
>> 'real language'?
>
> Forth is *slow*. That kills it's usage for me...

Really?  I'd like to see your benchmarks.

-- 

Rick

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

#43996

Julian Fondren <julian.fondren@gmail.com> writes:
> But the Forth webserver runs in 22MB fixed memory and the Erlang
> webserver starts out using 1.1GB of RAM.  npm's 'http-server', written
> in Node.js, starts out consuming 772MB of RAM.

Is that on a 64 bit system?  Even if yes, those numbers all sound way
too high.  Erlang runs ok in 64 meg embedded systems and Forth as you
know is generally tiny.  I have no experience with npm http-server but
people use it all the time on Beaglebone/RPi type systems with 256MB or
512MB and it doesn't use all the memory.

I did look at your Forth web server and thought the implementation
approach was pretty cute, though it was SwiftForth-dependent so I didn't
try it out.  I'd expect it to not need (much) more memory than the
httpd's found in (say) OpenWRT boards, which usually run in a few
hundred K or less.  Also, Fossil (fossil-scm.org) is a complete VCS, bug
tracker, wiki, and web server, written in C with an embedded SQL
database (SQLite), all in a single image of 2MB or so (used to be under
1MB but it's gotten bigger recently).  

> Have you heard that there's no place for Forth outside of embedded
> hardware?  If you've got even 1MB of flash, isn't it time to use a
> 'real language'?

RAM can also be a serious constraint ;-).

> poll() ... is used mainly because its data structures and values are
> well-documented, as opposed to select() for example where you'll told
> to use some magic C macros, and nevermind what they do.

Select just returns bit maps of which fd's have i/o available.  But poll
or epoll are better if you have lots of active channels.

> For $10/month or so, you can get an account on a shared server that
> has 64GB of RAM.  But, it's running MySQL and Apache already,
> configured for thousands of sites already.  And by policy you're not
> to have long-running processes, since people would of course have
> servers at 1GB each if allowed, so you have to use CGI for dynamic
> content.  Here, no, memory pretty much doesn't matter.

Look up erlangonxen.org - you can spin up a complete Erlang VM running
directly on a Xen hypervisor (no *nix kernel) in about 20 msec.  So you
can launch one from scratch on every request, no need for long running
processes or even long running computers ;-).

> You would strain something, trying to write a Forth CGI program that
> used as much RAM as PHP does.

PHP can run in a few meg, Forth should of course use less.

> Even with the $10/year option, 1GB of RAM is pretty tight when you
> need sshd, some other minor services, and a database server, in
> addition to your 1GB-resident webserver.

Nah, to misquote Bill Gates, 64MB should be enough for anyone.

http://lowendbox.com/blog/yes-you-can-run-18-static-sites-on-a-64mb-link-1-vps/

Really though, the JS bloatware that everyone these days puts into their
web pages need gigabytes of memory on the client side, so I wonder what
a 64MB server is proving.

> Apache has a defect.

Nobody uses Apache on small sites any more.

> If you have all of 64GB of RAM, and only 64 customers to that server,
> then you can't encourage them to run their own Node.js Express

I'd be interested in the memory footprints if you run your tests again
under a 32 bit kernel.  People run Node all the time in tiny little VPS's.

> All continues to matter that "doesn't matter anymore".  So Forth is
> pretty good, and you should use it.  It will still be good in five
> years when a typical server will have a full 1TB of RAM.

An Erlang-like Forth system with isolated lightweight processes instead
of the classic shared memory multitasker could be interesting.  I guess
OForth is something like that.

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

#44011

On Monday, November 30, 2015 at 10:43:28 PM UTC-6, Ron Aaron wrote:
> Wow, Julian - excellent article!  Can you post it somewhere where I can
> link to it?

Yeah, I can do that in a few days.


On Monday, November 30, 2015 at 11:13:19 PM UTC-6, Melzzzzz wrote:
> Seems that problem with forth is that there is no compiler for it
> on Linux....

Huh?  gforth is a very good implementation of Forth.  If you need a
static binary, and don't see gforth's loadable images as close enough
for that, then there's also lina, iForth, SwiftForth, and VFX Forth.
In order of cost, starting with free.

lina looks pretty bad in some easy benchmarks, but it improves
remarkably in them when you do produce a binary.

> > 
> > Have you heard that those differences in memory use doesn't matter?
> 
> What matters is reqs/sec mostly.
> 

OK, npm's 'http-server', in Node.js, just serving a static index page
over localhost:

  Requests per second:    434.52 [#/sec] (mean)
  Time per request:       115.068 [ms] (mean)
  Time per request:       2.301 [ms] (mean, across all concurrent requests)
  Transfer rate:          1001.02 [Kbytes/sec] received

  Connection Times (ms)
                min  mean[+/-sd] median   max
  Connect:        0    1   0.9      1       9
  Processing:    62  114  23.3    103     235
  Waiting:       49   99  23.1     91     215
  Total:         62  115  23.5    104     238

  Percentage of the requests served within a certain time (ms)
    50%    104
    66%    126
    75%    132
    80%    135
    90%    145
    95%    161
    98%    171
    99%    182
   100%    238 (longest request)

And the same with the 'http-server' binary, in Forth:

  Requests per second:    4117.81 [#/sec] (mean)
  Time per request:       12.142 [ms] (mean)
  Time per request:       0.243 [ms] (mean, across all concurrent requests)
  Transfer rate:          8525.15 [Kbytes/sec] received

  Connection Times (ms)
                min  mean[+/-sd] median   max
  Connect:        0    6  71.4      1    1004
  Processing:     0    2  12.5      1     403
  Waiting:        0    2  12.5      1     402
  Total:          1    8  76.8      2    1406

  Percentage of the requests served within a certain time (ms)
    50%      2
    66%      2
    75%      3
    80%      3
    90%      3
    95%      4
    98%      5
    99%     10
   100%   1406 (longest request)

The outliers are definitely due to a bug.

> Forth is *slow*. That kills it's usage for me...

ha ha!  But no really, what kills for you?


On Monday, November 30, 2015 at 11:22:34 PM UTC-6, Paul Rubin wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
> > But the Forth webserver runs in 22MB fixed memory and the Erlang
> > webserver starts out using 1.1GB of RAM.  npm's 'http-server', written
> > in Node.js, starts out consuming 772MB of RAM.
> 
> Is that on a 64 bit system?  Even if yes, those numbers all sound way
> too high.  Erlang runs ok in 64 meg embedded systems and Forth as you
> know is generally tiny.  I have no experience with npm http-server but
> people use it all the time on Beaglebone/RPi type systems with 256MB or
> 512MB and it doesn't use all the memory.

That's just looking at (/proc/$PID/status) VmPeak on a 64 bit system.
SwiftForth is 32-bit only and that's what's running the Forth web
server.

> I did look at your Forth web server and thought the implementation
> approach was pretty cute, though it was SwiftForth-dependent so I
> didn't try it out.

It uses some features of SWOOP that aren't in Portable SWOOP, it uses
a few words of a networking library that could be easily replaced by
words from any other network library, and it probably has the odd
SwiftForth-ism, like assuming that :NONAME leaves the resultant XT
and nothing else on the stack.

I'll port it eventually, if nobody else does, but proably not for a
good while.  There's more serious work to be done.

> Really though, the JS bloatware that everyone these days puts into their
> web pages need gigabytes of memory on the client side, so I wonder what
> a 64MB server is proving.

It'd be proving something about servers, I'd think.

Any time a website can offload something onto a user, it generally
should do.  Users care about page load times and responsiveness and
about the UI, but: they aren't counting CPU seconds; they *have*
gigabytes of memory; they are already eating the cost of an expensive
web browser; and so on.


-- Julian

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

#44016

Julian Fondren <julian.fondren@gmail.com> writes:

<SNIP>

>It uses some features of SWOOP that aren't in Portable SWOOP, it uses
>a few words of a networking library that could be easily replaced by
>words from any other network library, and it probably has the odd
>SwiftForth-ism, like assuming that :NONAME leaves the resultant XT
>and nothing else on the stack.

Isn't that just being ISO compliant?

<SNIP>

>-- Julian
-- 
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]

#44018

On Tuesday, December 1, 2015 at 9:01:14 AM UTC-6, Albert van der Horst wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
> >It uses some features of SWOOP that aren't in Portable SWOOP, it uses
> >a few words of a networking library that could be easily replaced by
> >words from any other network library, and it probably has the odd
> >SwiftForth-ism, like assuming that :NONAME leaves the resultant XT
> >and nothing else on the stack.
> 
> Isn't that just being ISO compliant?

This leaves just an XT on the stack:

  :NONAME ... ;

But what about this?

  :NONAME


The actual code I'm thinking of is

  : if: ( route -- route )
    :noname over -> match-xt !
    s" [OBJECTS client names client OBJECTS] " evaluate ;

  : do: ( route -- route )
    :noname over -> fulfill-xt !
    s" [OBJECTS client names client OBJECTS] " evaluate ;

As used in code like:

  simple :: time-rule
    if: m" /time" ;
    do: client created @ .now ;


lina looks to work similarly, but on gforth I'd need

  : if: ( route -- route )
    >r :noname over r> -> match-xt !  ... ;


-- Julian

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

#44090

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Julian Fondren <julian.fondren@gmail.com> writes:
>
><SNIP>
>
>>It uses some features of SWOOP that aren't in Portable SWOOP, it uses
>>a few words of a networking library that could be easily replaced by
>>words from any other network library, and it probably has the odd
>>SwiftForth-ism, like assuming that :NONAME leaves the resultant XT
>>and nothing else on the stack.
>
>Isn't that just being ISO compliant?

The standard :NONAME has the stack effect ( C: -- colon-sys )( S: -- xt ).
So no, a standard program cannot assume that :NONAME just leaves the
xt on the stack.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44040

On 11/30/15 5:35 PM, Julian Fondren wrote:

>    class pollfd
>      variable fd        \ an actual socket
>      hvariable events   \ states the server is interested in
>      hvariable revents  \ states poll() found to apply to the socket
>    end-class
>
>    class pollserver
>      max-clients 1+ pollfd builds[] pollfds
>      max-clients 1+ client builds[] clients
>    end-class

> The structs and arrays were all done with built-in SWOOP features,
> which are documented in manuals that come with SwiftForth.  Looking
> around at other OO facilities, I note that oof.fs also has explicit
> array support, but that most others don't seem to.

FMS has always supported arrays-as-instance-variables. In this case you
want an array of objects. One helper class will provide that:
(The following is for FMS single inheritance)

:class obj[] <super ordered-col
  :m new ( class-xt -- )
     max-size @ 0 do dup >body (dict) self add: loop drop ;m
;class

:class pollserver
   max-clients 1+ obj[] pollfds
   max-clients 1+ obj[] clients
   :m init: ['] pollfd pollfds new
            ['] client clients new ;m
;class

Class pollserver needs slightly more code than the SWOOP version but it
gets you the same thing.


> I don't see explicit support for lists, but gforth has an example
> implementation of a list in its object.fs documentation.

FMS will support any kind of list. Couldn't any object extension? There
are several example list classes provided in addition to order-col
including dynamically resizable lists with iteration methods.


> By the way, although http://soton.mpeforth.com/flag/swoop/index.html
> still doesn't have a gforth compatibility layer, I've written one.
> It's an easy adaptation of the VFX layer.  Portable SWOOP is only
> missing [OBJECTS ... OBJECTS] syntax and some of the extensibility
> and extras that flavors give ASWOOP.

FMS has always supported dynamically created objects that can be stored
in locals or any place:

: try { sam -- }  sam dot ;

: test heap> point { joe }
   joe try  joe <free ;

FMS is compatible with any ANS Forth, i.e. fully portable.

-Doug

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

#44082

Julian Fondren wrote:

> Have you heard that Forth can't be used for real applications,
> because people are too caught up in having to come up with their own
> data structures?  Have you heard that no Forth teaches the use of
> 'structs'?
 
> I spent a week, working after work, and one weekend, writing a Forth
> webserver.  As it only took me about an hour to achieve similar ends
> with Erlang, this probably isn't impressive.  But the Forth webserver
> runs in 22MB fixed memory and the Erlang webserver starts out using
> 1.1GB of RAM.  npm's 'http-server', written in Node.js, starts out
> consuming 772MB of RAM.
Ok. Stop. I wrote a static webserver running in 64K in one evening. No, I
don't intend to use it (if at all) for a real life application where it
should handle hundreds of simultaneous connections at the same time - but
it can be done.

And my Forth handles structs - so does the manual of course.

Hans Bezemer

https://www.youtube.com/watch?v=60BSYkpUzBI

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

#44086

On Saturday, December 5, 2015 at 6:32:57 AM UTC-6, The Beez wrote:
> Julian Fondren wrote:
> 
> > Have you heard that Forth can't be used for real applications,
> > because people are too caught up in having to come up with their own
> > data structures?  Have you heard that no Forth teaches the use of
> > 'structs'?
>  
> > I spent a week, working after work, and one weekend, writing a Forth
> > webserver.  As it only took me about an hour to achieve similar ends
> > with Erlang, this probably isn't impressive.  But the Forth webserver
> > runs in 22MB fixed memory and the Erlang webserver starts out using
> > 1.1GB of RAM.  npm's 'http-server', written in Node.js, starts out
> > consuming 772MB of RAM.
> Ok. Stop. I wrote a static webserver running in 64K in one evening. No, I
> don't intend to use it (if at all) for a real life application where it
> should handle hundreds of simultaneous connections at the same time - but
> it can be done.
> 
> And my Forth handles structs - so does the manual of course.
> 
> Hans Bezemer
> 
> https://www.youtube.com/watch?v=60BSYkpUzBI

Hahahaha.  Thank you!  I was far too pleased with myself to worry
much about the kind of response my post would get, but thinking
now, this post is precisely what I should have expected.  I
should've gotten a wall of posts like this.

Did you know that gforth comes with a webserver that has been used
for years, which is far simpler because it offloads the networking
onto inetd?  There is even a very good writeup about it.  And have
you heard that Greg Bailey invented Forth networking and has used
it professionally in all kinds of ways?  And have you heard that
VFX Forth, the professional version, comes with HTTP and other
servers?  I am 100% sure that VFX's webserver knows better than to
reply to a HEAD request with full page content!  And I'm sure that
Factor and RetroForth both have webservers, with extra
concatenativity.

All that might be done has all been done already.  And far better,
in far less memory, and in far less time.  And if I'm not prepared
right now to swallow a burning coal, then I'd better review the
math on how much memory that webserver really uses, and hurry up
and port it to a Forth that doesn't link in libc.

I should tell you, though, that your webserver doesn't really need
to handle 'hundreds of simultaneous connections'.  A mere ten
hundreds, I find, is never much challenged until deliberate abuse
clogs the server up, or enormous problems outside of the server
slow it down.  The latter nine hundreds - especially the latter
eight -- are nearly superfluous for legitimate activity.

And if your webserver is not robust enough to replace Apache on a
shared webhosting server, or to replace NginX+PHP on a large
business's cluster of servers, it is not useless.  First of all,
if it can serve a single website and answer only 6 connections,
then it's about optimal for Firefox with default settings.  People
want single-site local webservers for things like web development,
and just using http as a frontend for some application, and even
game development now that there are HTML5-emitting game engines
like RPGMaker MV.  I have personally guided nontechnical people
towards installing Node.js just to serve some files that Chrome
refused to load directly for JavaScript security reasons.

Second of all, whatever state it is in, people can potentially
improve it towards their own ends.  HTTP, especially now with
smartphones, is massively abused for services that look nothing
like websites, and it can be nice to have something that doesn't
waste its time trawling filesystems for .htaccess files.

Third of all, since it's your webserver, in 4th, I suppose it's
pretty portable and that you can make a single tiny executable out
of it?  Guiding someone through installing such a thing would be
even nicer than guiding them towards Node.js, where I had to say
"get npm, then use it to install http-server, which pulls in like
60 modules, which puts an executable script...  somewhere, which
you can then use".  And that should work just as well on windows.

And there are also uses such as mine: I have some RPGMaker MV
games and I'd like to serve them from really cheap VPSes that I
only pay a few dollars for per year.  And I'd like to help others
do this - others who, not being professional administrators, would
benefit from not having to deal with something they'd have to
configure and secure and not let consume all of their RAM or disk
and die if given a harsh look.

Call it a mini tactical webserver.  It's useful.

As it was, I couldn't get Greg Bailey's webserver.  I didn't want
buy to MPE just for its webserver.  I wanted more control and than
I expected from an inetd-served webserver.  And your server wasn't
available.  And that other SwiftForth server that someone had was
Windows-only or something.  And I'd already written pollserver.fs.
So things sort of fell together this way.  I would apologize, but
I remain pleased with myself :-)


Cheers,
Julian

[toc] | [prev] | [standalone]

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

csiph-web