FLAG - Forth Library Action Group
Stephen Pelc
form.
If you have libraries to contribute and are prepared to write a
simple web page from the FLAG templates, please contact me.
A skeleton web site can be found at
http://soton.mpeforth.com/flag/
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
David N. Williams
> FLAG is a community website for hosting Forth libraries in source
> form.
>
> If you have libraries to contribute and are prepared to write a
> simple web page from the FLAG templates, please contact me.
>
> A skeleton web site can be found at
> http://soton.mpeforth.com/flag/
I haven't digested much of it yet, but enough to say, BRAVO!
-- David
Josh Grams
> FLAG is a community website for hosting Forth libraries in source
> form.
Despite the guidelines saying that the index.html for a project *must*
contain a contact e-mail address, the page for the EXTERN: syntax
doesn't...
--Josh
Anton Ertl
Where did you find guidelines or a page for the EXTERN: syntax? I do
not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
links to anything.
- 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 2009: http://www.euroforth.org/ef09/
Bruce McFarling
wrote:
> Josh Grams <j...@qualdan.com> writes:
> >Stephen Pelc wrote: <4b1d5e6c.31844...@192.168.0.50>
> >> FLAG is a community website for hosting Forth libraries in source
> >> form.
>
> >Despite the guidelines saying that the index.html for a project *must*
> >contain a contact e-mail address, the page for the EXTERN: syntax
> >doesn't...
>
> Where did you find guidelines or a page for the EXTERN: syntax? I do
> not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
> links to anything.
>
> - anton
http://soton.mpeforth.com/flag/extern/index.html
courtesy of the drop down box (Librarys / Hosted Systems / Access DLLs
and SOs), though the site should have a Web-1.0 direct link to a site
map page of direct links and not rely exclusively on javascript for
library access. Whatever information base is generating the javascript
menu system ought to be able to be used to generate a simple a-tag, ul-
tag site map.
The guidelines are in:
Stephen Pelc
(Anton Ertl) wrote:
>Where did you find guidelines or a page for the EXTERN: syntax? I do
>not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
>links to anything.
Try refreshing your browser.
Anton Ertl
>On Tue, 08 Dec 2009 14:42:53 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Where did you find guidelines or a page for the EXTERN: syntax? I do
>>not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
>>links to anything.
>
>Try refreshing your browser.
Pressing the "reload" button produces the same result.
Bruce McFarling
> though the site should have a Web-1.0 direct link to a site
> map page of direct links
Ah, it does, they just are different headings.
Marc Olschok
> steph...@mpeforth.com (Stephen Pelc) writes:
> >On Tue, 08 Dec 2009 14:42:53 GMT, an...@mips.complang.tuwien.ac.at
> >(Anton Ertl) wrote:
> >
> >>Where did you find guidelines or a page for the EXTERN: syntax? I do
> >>not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
> >>links to anything.
> >
> >Try refreshing your browser.
>
> Pressing the "reload" button produces the same result.
Could it be that the links are safely hidden inside some
Javascript inline?
--
Marc
Stephen Pelc
<nob...@nowhere.invalid> wrote:
>Could it be that the links are safely hidden inside some
>Javascript inline?
The sidebars and menus are built by Javascript routines.
The rationale is to make life easy for the site maintainers
and for people producing pages. If people want to be really
picky they can download the (not quite latest) style sheets
and scripts from the "Using" page and then send their
comments to me.
The point of the announcement was to solicit library code
for FLAG. Gerry Jackson has already contributed his ANS
test suite and more is coming.
Thak you all for your interest. At present the FLAG site
is maintained in my "ample spare time" while my other half
indulges in a hopefully transient Facebook addiction.
Bruce McFarling
> The sidebars and menus are built by Javascript routines.
> The rationale is to make life easy for the site maintainers
> and for people producing pages.
Not to be really picky, but as it stands, there are no links in Lynx.
The sidebars could be built on the fly without requiring Javascript on
the other side, or else a sitemap built on the fly on the server side
when a sitemap link is clicked, with something like Forthscript.
Anton Ertl
>On Tue, 8 Dec 2009 17:40:58 +0000 (UTC), Marc Olschok
><nob...@nowhere.invalid> wrote:
>
>>Could it be that the links are safely hidden inside some
>>Javascript inline?
>
>The sidebars and menus are built by Javascript routines.
>The rationale is to make life easy for the site maintainers
>and for people producing pages.
How does hiding the links in Javascript make life easier? Fewer users
and less feedback? Yes, that could work. OTOH, if that's the goal of
the site maintainers and people producing pages, why maintain the site
and produce pages at all?
> If people want to be really
>picky they can download the (not quite latest) style sheets
>and scripts from the "Using" page and then send their
>comments to me.
What "Using" page? And why should I comment on the style sheets and
scripts?
Anton Ertl
There are no links on that page that I can see, and my browser only
sees:
http://soton.mpeforth.com/flag/flagstyle.css
http://soton.mpeforth.com/flag/dropdown_one.css
Concerning Web 1.0, a site without links looks like Web -1.0 to me.
But I guess you were referring to Web 2.0. Really successful Web 2.0
projects like Wikipedia work perfectly well without JavaScript.
Stephen Pelc
(Anton Ertl) wrote:
>There are no links on that page that I can see, and my browser only
>sees:
Which browser and version? Is Javascript enabled?
>But I guess you were referring to Web 2.0. Really successful Web 2.0
>projects like Wikipedia work perfectly well without JavaScript.
Go to:
http://en.wikipedia.org/wiki/Forth_%28programming_language%29
and view the page source - it's littered with Javascript!
There's no content management system for FLAG, no database, just
a simple site. It was deliberate design decision. Until I have more
people helping out and a permanent home for it, the FLAG site remains
what I said it was, a rough prototype. I'm really sorry that the
idea of a repository for Forth library source code upsets you.
FLAG is not an MPE project, it's something I've done in my
"ample spare time". I'm not a web weenie.
IMHO, it would be more productive to contribute, and it might
take less time.
Bruce McFarling
> Which browser and version? Is Javascript enabled?
Evidently not.
> >But I guess you were referring to Web 2.0. Really successful Web 2.0
> >projects like Wikipedia work perfectly well without JavaScript.
> Go to:http://en.wikipedia.org/wiki/Forth_%28programming_language%29
> and view the page source - it's littered with Javascript!
Yes, and still, it WORKS when accessed with plain Lynx from a Windows
console. Its not a theoretical objection to the *presence* of
Javascript, its the decision to make access to the library for both
users and maintainers *dependent* on Javascript.
Wikipedia, Google, they all work without Javascript, even though they
make extensive use of Javascript when present.
> There's no content management system for FLAG, no database, just
> a simple site.
Except its a simple Web 2.0-only site.
> It was deliberate design decision.
A deliberate design decision to contradict the argument made in the
only page accessible to non-Javascript-enabled browsers:
"The key to a library is to make it easy to access for users to
download libraries. Similarly, it should be easy for library
maintainers to upload data."
> FLAG is not an MPE project, it's something I've done in my
> "ample spare time". I'm not a web weenie.
I don't follow why its not done as a Google group in those
circumstances - with a anyone can access, only invited members can
post setting it'd be easy for users to access, easy for library
maintainers to maintain. It would not require any prototyping at all,
and would be accessible to anyone - if I hooked up my Linux-on-floppy
machine to the hub, I could access a google group from Quark, which is
wget, a console tool oriented display utility, and some ash, sed, m4
and awk scripts.
> IMHO, it would be more productive to contribute, and it might
> take less time.
Here's a mirrored home page with links that work without Javascript:
Bruce McFarling
Ah, that doesn't work, Google search is more open than Google groups.
Its Blogspot that is the member of the Google family that is
accessible. Sorry, class 0830-1230, 1800-2200 today plus office hours,
I'm a bit groggy. I'll delete the FLAG-Mirror group and put up the
FLAG mirror blog tomorrow.
Bruce McFarling
> not see any guidelines on <http://soton.mpeforth.com/flag/>, nor any
> links to anything.
I've tested the following page with console Lynx, it has all the links
from the main site.
http://flag-mirror.blogspot.com/2009/12/flag-home-page-10-december-2009.html
Stephen Pelc
<agi...@netscape.net> wrote:
>I've tested the following page with console Lynx, it has all the links
>from the main site.
>
>http://flag-mirror.blogspot.com/2009/12/flag-home-page-10-december-2009.htm=
>l
Page not found, with or without the "=1".
Bruce McFarling
> On Thu, 10 Dec 2009 10:22:42 -0800 (PST), Bruce McFarling
>
> >I've tested the following page with console Lynx, it has all the links
> >from the main site.
>
> >l
>
> Page not found, with or without the "=1".
>
> Stephen
>
> --
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads
Ah, well I could test the page in advance, but couldn't test how the
link came through when posted. The reason it does not work with or
without the =l is the = needed to be deleted but not the l ... blogger
makes .html pages.
But no need to hit line length processing, as the base link works
fine:
MarkWills
> FLAG is a community website for hosting Forth libraries in source
> form.
>
> If you have libraries to contribute and are prepared to write a
> simple web page from the FLAG templates, please contact me.
>
> A skeleton web site can be found at
> http://soton.mpeforth.com/flag/
>
> Stephen
>
> --
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
Stephen,
Congratulations! A great effort. I hope it turns out to be successful
and productive for Forth programmers.
I would also add that I am dismayed that members of c.l.f, instead of
choosing to back you up and congratulate you, choose to deride how the
site itself is *coded*. How ridiculous. And completely predictable in
the one year that I have been frequenting this group. Despite the fact
that I find it completely predictable, I'm really at a loss to find
words to describe the pedantry and downright childness that has been
displayed here. It is a shame. I detect some jelousy. Despite the fact
that nobody else got off their ass to build a site, or even a google
group.
Until you did, of course. Then it was 'me too me too, oh I could do so
much better than that...'.
My suggestion: Ignore them. Maybe one day I'll be a good enough coder
to contribute some code myself. Until then, I'll periodically check
the site, and generally lurk.
But a big thumbs up from me.
Mark
Jonah Thomas
> I would also add that I am dismayed that members of c.l.f, instead of
> choosing to back you up and congratulate you, choose to deride how the
> site itself is *coded*. How ridiculous. And completely predictable in
> the one year that I have been frequenting this group. Despite the fact
> that I find it completely predictable, I'm really at a loss to find
> words to describe the pedantry and downright childness that has been
> displayed here. It is a shame. I detect some jelousy. Despite the fact
> that nobody else got off their ass to build a site, or even a google
> group.
>
> Until you did, of course. Then it was 'me too me too, oh I could do so
> much better than that...'.
If they do create something better then Stephen can take credit for
getting them started.
"You can tell the pioneers by the arrows in their backs."
MarkWills
You sir, are a wise man!
Anton Ertl
>On Wed, 09 Dec 2009 21:04:59 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>There are no links on that page that I can see, and my browser only
>>sees:
>
>Which browser and version?
Iceape (aka Seamonkey) 1.1.11
> Is Javascript enabled?
I have disabled JavaScript, like everyone who cares about security and
knows about the security issues of JavaScript.
>>But I guess you were referring to Web 2.0. Really successful Web 2.0
>>projects like Wikipedia work perfectly well without JavaScript.
>
>Go to:
>http://en.wikipedia.org/wiki/Forth_%28programming_language%29
>and view the page source - it's littered with Javascript!
That does not contradict what I wrote.
>I'm really sorry that the
>idea of a repository for Forth library source code upsets you.
Where did you get that idea? I find the idea great, and that's the
reason why I gave you feedback. There are many other broken websites
out there. Only for very few I take the effort to inform the
maintainer about problems. Most of them I just ignore; after all,
there are lots of good websites out there, so why waste time on a
broken one? Especially if the maintainer does not appreciate the
feedback.
Anton Ertl
>On Dec 9, 8:48=A0pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
>> There's no content management system for FLAG, no database, just
>> a simple site.
>
>Except its a simple Web 2.0-only site.
I don't see any Web 2.0 in it (yet), certainly not in the original
version nor in the version you provided
<http://soton.mpeforth.com/flag/using.html>. As far as I can see user
contributions are through emailing Stephen and Stephen manually
updating the site, i.e., the classic pre-2.0 mechanisms. Web 2.0
means web sites that facilitate many and easy user contributions,
particularly through the web.
Richard Owlett
> steph...@mpeforth.com (Stephen Pelc) writes:
>> On Wed, 09 Dec 2009 21:04:59 GMT, an...@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>>
>>> There are no links on that page that I can see, and my browser only
>>> sees:
>> Which browser and version?
>
> Iceape (aka Seamonkey) 1.1.11
>
>> Is Javascript enabled?
>
> I have disabled JavaScript, like everyone who cares about security and
> knows about the security issues of JavaScript.
>
Thank you. I thought I was a minuscule and maximally paranoid
minority for surfing *WITHOUT* JavaScript enabled.
I have only two requests of page designers using JavaScript:
1. That they check to see if it is enabled and give a warning
message if not.
2. That they follow request 1 ;)
A page which fails SILENTLY is *NOT* good.
http://soton.mpeforth.com/flag/ fails.
*NO* menus appear if JavaScript not enabled.
Stephen Pelc
(Anton Ertl) wrote:
>>Which browser and version?
>
>Iceape (aka Seamonkey) 1.1.11
Does this support the <noscript> tag?
>> Is Javascript enabled?
>
>I have disabled JavaScript, like everyone who cares about security and
>knows about the security issues of JavaScript.
Now I undestand. I last had the JavaScript security issues thrown at
me about ten years ago, and the world has moved on since then. I'll
certainly add a <noscript> section.
The real design problem here is about encapsulation and reducing
bandwidth. HTML has no way to include files except by scripting.
If you want to have a common look and feel to all pages, you either
have to have a content management system, or you have to use scripts.
A CMS requires sites to be installed, and there are dozens of CMS
systems. Building a site with style sheets and scripts requires no
installation other than copying a directory tree and getting a
link into the root of that tree. Even I can manage that.
Building the sidebar, banner and menus using script files simply
reduces the workload for page authors. It also means that if the
sidebar changes, e.g. for a new project, none of the project pages
have to be changes. Because scripts are cached, there's also a
bandwidth reduction when you view two or more pages.
Style sheets and scripts are a way factoring web pages. Factoring
web pages is just like factoring in Forth or any program. If you
can show me how to achieve the same level of factoring wihout
using JavaScript or a CMS while still meeting the site's design
objectives. I'll be happy to consider it. Perhaps we should do this
off-line.
Bruce McFarling
wrote:
> Bruce McFarling <agil...@netscape.net> writes:
> >On Dec 9, 8:48=A0pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> >> There's no content management system for FLAG, no database, just
> >> a simple site.
>
> >Except its a simple Web 2.0-only site.
>
> I don't see any Web 2.0 in it (yet), certainly not in the original
> version nor in the version you provided
> <http://soton.mpeforth.com/flag/using.html>. As far as I can see user
> contributions are through emailing Stephen and Stephen manually
> updating the site, i.e., the classic pre-2.0 mechanisms. Web 2.0
> means web sites that facilitate many and easy user contributions,
> particularly through the web.
What I intended to denote by "Web 2.0-only" was the browser
capabilities required to make full use of Web 2.0 facilities as
commonly provided. Search and replace any term you prefer to use to
denote that.
And of course, there were indeed Web 1.0 sites that facilitated many
and easy user contributions if those contributions were text - while
Javascript is necessary to access many Web 2.0 sites, it is certainly
not sufficient to take full advantage of all of them. Part of the push
among Internet Tablets to become first-class Web 2.0 tools is ability
to play Flash streaming video directly, without special provision of
an "m" front page and without special knowledge of the site's API.
Bruce McFarling
> Anton Ertl wrote:
Indeed, the warning message could contain a link to a site map page in
vanilla HTML 2.0.
That could be generated on the server side on the fly using the same
logic that is used to generate the menus on the fly in the user's
browser in the Javascript code.
Bruce McFarling
> I would also add that I am dismayed that members of c.l.f, instead of
> choosing to back you up and congratulate you, choose to deride how the
> site itself is *coded*. How ridiculous.
Pointing out a flaw in the site design is not derision. Its the way
that a newsgroup works when it works properly - multiple eyeballs
looked at the page using different systems with different set-ups and
reported back what works and what doesn't.
Even if Stephen Pelc was a professional web designer, it would be on
the one hand silly to deride him for the slip, and on the other hand a
fairly irresponsible omission - since this is a volunteer project for
the general benefit of the Forth community - to observe the slip and
fail to report it.
It would be even sillier to take what can easily be read as
constructive criticism and choose to read it as derision.
I don't know enough Javascript to read the Javascript code in the page
source and say what should be added to give an advisory message to non-
Javascript enabled browsers - nor enough Javascript to read the code
and translate it into a ``Forthscript'' style page that can generate a
site-map on the fly from the server side. So I can't generate a patch.
But I've done enough accessibility testing of websites with Lynx to
know that the first can be done and is normal practice, and have seen
enough Forth vocabularies for generating web pages on the fly to know
that the second is reasonably straightforward.
Ed
> ...
> Despite the fact
> that nobody else got off their ass to build a site, or even a google
> group.
Repositories for forth code have been around for years. When
BBS were common they all had file sections. One of the longest
maintained ftp forth sites is Taygeta.com. It even has a directory
'Applications/ANS'. The problem isn't so much a lack of sites to
store these things but a lack of forth users. With a declining user
base, the code just isn't going to be generated.
Forth is now mostly old-timers who've seen better days and a
few young sparks who reckon they can do better. There's really
not much happening on c.l.f. that's of any note. It's more a
social outing. Controversies, real or contrived, are a godsend
because it's the only thing that generates interest, albeit briefly :)
Bruce McFarling
> Forth is now mostly old-timers who've seen better days and a
> few young sparks who reckon they can do better.
There's also occasional reports from the two system houses of people
actually using it to get work done, but they may be as likely to come
to clf as a roofer is to go to a discussion group about nailguns.
gavino
> FLAG is a community website for hosting Forth libraries in source
> form.
>
> If you have libraries to contribute and are prepared to write a
> simple web page from the FLAG templates, please contact me.
>
> A skeleton web site can be found at
> http://soton.mpeforth.com/flag/
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
awesome!!!
where is forth webserver?
forth dns?
forth tcp/ip
forth firewall/packet filter?
forth irc?
Anton Ertl
>On Fri, 11 Dec 2009 11:03:39 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>Which browser and version?
>>
>>Iceape (aka Seamonkey) 1.1.11
>
>Does this support the <noscript> tag?
I don't know.
>>> Is Javascript enabled?
>>
>>I have disabled JavaScript, like everyone who cares about security and
>>knows about the security issues of JavaScript.
>
>Now I undestand. I last had the JavaScript security issues thrown at
>me about ten years ago, and the world has moved on since then.
What has changed? The security issues are still there, so how has the
world moved on? A few hypotheses:
1) Nobody cares about security anymore.
2) Nobody knows about the security issues of Javascript anymore.
3) Those who care about security issues and know about the security
issues of JavaScript have given up on trying to give feedback to
web designers about this stuff, because hardly any web designer
appreciates it and acts on the feedback. Instead, web designers
find various reasons for not taking action; e.g. "the world has
moved on", but the real reason in most cases is that the paying
customers do not know about the security issues of JavaScript and
want a glitzy web site, and giving the customer what he wants pays
better than educating him.
>The real design problem here is about encapsulation and reducing
>bandwidth. HTML has no way to include files except by scripting.
There are frames. They have their disadvantages, but they are still
better than JavaScript.
>A CMS requires sites to be installed, and there are dozens of CMS
>systems.
If you just want to include some HTML code, a simple macro processor
is sufficient. A Forth program with less than 50 lines could perform
this inclusion. Ok, for running it on a different site than yours
(which seems to be the scenario you have in mind) one would need a
Forth system that can access the Internet, or have a program like wget
in addition to a standard Forth program.
Anton Ertl
>On Dec 11, 11:34=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> I don't see any Web 2.0 in it (yet), certainly not in the original
>> version nor in the version you provided
>> contributions are through emailing Stephen and Stephen manually
>> means web sites that facilitate many and easy user contributions,
>> particularly through the web.
>
>What I intended to denote by "Web 2.0-only" was the browser
>capabilities required to make full use of Web 2.0 facilities as
>commonly provided. Search and replace any term you prefer to use to
>denote that.
What's required is HTML (as, e.g., the Wikipedia demonstrates),
nothing more.
What you mean are technologies that became popular at about the same
time, e.g., JavaScript and CSS in the case of the FLAG site, or Flash.
However, the use of these technologies does not turn a web site into a
Web 2.0 site, and vice versa, so they are orthogonal to Web 2.0.
Bruce McFarling
wrote:
> What you mean are technologies that became popular at about the same
> time, e.g., JavaScript and CSS in the case of the FLAG site, or Flash.
> However, the use of these technologies does not turn a web site into a
> Web 2.0 site, and vice versa, so they are orthogonal to Web 2.0.
They are not, however, orthogonal to Web 2.0 in practice, but are
rather pre-requisites to full participation at the majority of Web 2.0
sites - and full participation is the \:i{ sin qua non \} of Web 2.0.
Wikipedia may demonstrate that its not a technical requirement -
indeed, m.youtube.com demonstrates that they are not technical
requirements for multimedia Web 2.0 - but those demonstrations have
not sufficed in removing the requirement.
Frank Buss
> If you just want to include some HTML code, a simple macro processor
> is sufficient. A Forth program with less than 50 lines could perform
> this inclusion.
I would use PHP, because this is easier for creating web pages. But maybe
this would be a nice FLAG project :-)
> Ok, for running it on a different site than yours
> (which seems to be the scenario you have in mind) one would need a
> Forth system that can access the Internet, or have a program like wget
> in addition to a standard Forth program.
If you don't have a web provider with PHP support, you could create the
files offline and then sync the remote directory with one click in WinSCP
(if you are using Windows).
First install the PHP command line program:
http://www.php.net/get/php-5.2.11-win32-installer.msi/from/a/mirror
Choose no web server, when installing. Then edit the c:\Program
Files\PHP\php.ini file:
short_open_tag = On
asp_tags = On
This allows "<%= $foo; %>" style for embedding variables into webpages and
"<?" for starting a PHP code section.
I would suggest to separate presentation and content. In the
roottemplate.html is much code which is not interesting for a Forth library
author and if you want to change the layout (e.g. a new content dependant
sidebar), you have to change all library pages. I would use something like
this (I don't use Windows character encodings, but something more standard)
template.php:
<?
require "info.inc";
?>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title><%= $title; %></title>
</head>
<body>
<?
$last_modified = filemtime("content.html");
print "<p>Last updated: " . date("l, dS F Y", $last_modified) . "</p>\n";
?>
<h1><%= $title; %></h1>
<p><i>Author: <%= $author; %></i></p>
<?
require "content.html";
?>
</body>
</html>
And then the library author just have to write these files:
info.inc:
<?
$title = "The Title";
$author = "Frank Buss";
$email = "f...@frank-buss.de";
?>
content.html:
<p>
Hello World!
</p>
You can test it from the command line:
php template.php
Which creates this output:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>The Title</title>
</head>
<body>
<p>Last updated: Sunday, 13th December 2009</p>
<h1>The Title</h1>
<p><i>Author: Frank Buss</i></p>
<p>
Hello World!
</p>
</body>
</html>
If you don't have that much pages, add it to some batch files (e.g. "php
template.php > index.html" for each project directory) and you're done. Of
course, you can add some more scripting, to use always the same template
file without copying and automaticly scan all directories for content and
info files and call the php command line program, redirecting the output to
index.html. This would be a two-liner with Perl, which is available for
Windows, too. And I would add a site list page with links for all projects,
which can be generated from the Perl or a PHP script, too, e.g. with
additional short description and author for each project.
If the project grows, it is very easy to move the info.inc and content.html
pages to a full content managment system later.
Another useful idea: Use a version management system to store the page
sources. SVN is nice. I use it for all my projects.
If you don't have or don't want to install your own SVN server, you could
add a project on Sourceforge or Google Code and allow others to commit and
maintain it. On Sourceforge you have a Unix shell account and webspace and
you could just update the PHP files (I think Sourceforge webspace provides
PHP hosting, so you don't need to preprocess it) into the webspace.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Krishna Myneni
> FLAG is a community website for hosting Forth libraries in source
> form.
>
> If you have libraries to contribute and are prepared to write a
> simple web page from the FLAG templates, please contact me.
>
> A skeleton web site can be found at
> http://soton.mpeforth.com/flag/
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads
Hopefully the site will have contributors, although one point of
concern, for me, is the following. Pages on the site shouldn't be a
free for all, but some objective criteria for accepting/rejecting
contributions should be clearly spelled out. The statement on the main
page, "Libraries accepted for inclusion ..." should be followed up
with such criteria. Politics can never be fully exorcised out of such
efforts, but clear guidelines will help anyone considering a
contribution to the site.
Also, the following bit of nonsense should be removed from your main
page,
"Reinventing the wheel should be considered a sin."
For deploying code, I agree mostly with the above statement, but it is
antithesis to the notion of learning! FLAG should not only be a
resource for developing production code, but its contributions can
also serve as a model for learning to develop libraries.
Krishna
Stephen Pelc
iForth to FLAG.
Gerry Jackson's ANS test suite is also available.
A note about JavaScript has been added to the main page using
a <noscript> tag.
Two more library contributions are in preparation.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
Anton Ertl
>On Dec 12, 10:59=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>
>> What you mean are technologies that became popular at about the same
>> time, e.g., JavaScript and CSS in the case of the FLAG site, or Flash.
>> However, the use of these technologies does not turn a web site into a
>> Web 2.0 site, and vice versa, so they are orthogonal to Web 2.0.
>
>They are not, however, orthogonal to Web 2.0 in practice, but are
>rather pre-requisites to full participation at the majority of Web 2.0
>sites - and full participation is the \:i{ sin qua non \} of Web 2.0.
Lots of web sites nowadays use these technologies, and many even don't
work without them, so it should be no surprise if there are Web 2.0
sites with the same property. That does not make any web site that
uses these technologies a Web 2.0 website.
Actually, I would not be surprised if, among the successful Web 2.0
sites, the proportion that works without these technologies is higher
than among the web sites in general (simply because for many web sites
the glitz factor is what the customer wants, whereas for Web 2.0, lots
of contributors are what the customer wants).
Applying your argument to hybrid cars (for Web 2.0) and remote keyless
systems (for JavaScript etc.), would you say that the high proportion
of hybrid cars with remote keyless systems means that all cars with
remote keyless systems should be called hybrid cars? One can find
lots of other examples of this kind.
An example: the Web 2.0 site www.synchronkartei.de, which supported
contributing through an HTML interface, and at some point broke that
interface by replacing it with a JavaScript-based interface; they
later offered the HTML interface again for those who have disabled
JavaScript. Given that this Web site was Web 2.0 before it used
JavaScript, it's obvious that JavaScript is not necessary for being
Web 2.0 even for a Web 2.0 site that uses JavaScript.
And the large number of non-2.0 web sites that use JavaScript, Flash
etc. demonstrates that these technologies are not sufficient for
being Web 2.0.
Anton Ertl
>Hopefully the site will have contributors, although one point of
>concern, for me, is the following. Pages on the site shouldn't be a
>free for all, but some objective criteria for accepting/rejecting
>contributions should be clearly spelled out. The statement on the main
>page, "Libraries accepted for inclusion ..." should be followed up
>with such criteria. Politics can never be fully exorcised out of such
>efforts, but clear guidelines will help anyone considering a
>contribution to the site.
If it was a Web 2.0 site, one could combine a (mostly) free-for-all
approach with a user rating facility (or instead of or in addition to
the user ratings, one could use the Google pagerank of the subpage for
rating it). Of course, all of that only makes sense if there is a way
to query for subpages; again, one could use Google as a cheap
alternative to a home-grown query engine.
>Also, the following bit of nonsense should be removed from your main
>page,
>
>"Reinventing the wheel should be considered a sin."
I read that as a motivation for this project: Share your code and use
the shared code instead of reinventing the wheel!
Bruce McFarling
wrote:
> Applying your argument to hybrid cars (for Web 2.0) and remote keyless
> systems (for JavaScript etc.), would you say that the high proportion
> of hybrid cars with remote keyless systems means that all cars with
> remote keyless systems should be called hybrid cars? One can find
> lots of other examples of this kind.
Its not as if I equated requiring the common pre-requisites WITH Web
2.0. I coined "Web2.0-only" as a shorthand and said what it signified.
I understand and, indeed, approve of efforts to eliminate those
technically unnecessary barriers to access - having those technical
barriers in place may well be seen as contrary to the spirit of Web2.0
even as they plague Web2.0 sites.
Your discussion proves that you *know* about the type of sites I am
talking about, so I don't grasp why you prefer (1) arguing about
whether that is intrinsic to Web2.0, when I've never said anything
suggesting that it is, to (2) offering a shorthand that you find less
objectionable.
The fact that the car can be driven when the remote keyless system is
broken indicates that your analogy is quite a bit looser than is
required for a persuasive argument by analogy.
Bruce McFarling
> Anton Ertl wrote:
> > If you just want to include some HTML code, a simple macro processor
> > is sufficient. A Forth program with less than 50 lines could perform
> > this inclusion.
> I would use PHP, because this is easier for creating web pages. But maybe
> this would be a nice FLAG project :-)
Yes, as there are several public examples of Forthscript type
processing, if the web pages were generated out of a base file by a
server side Forthscript, a Forthscript code and base file could be a
FLAG project.
Krishna Myneni
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >Hopefully the site will have contributors, although one point of
> >concern, for me, is the following. Pages on the site shouldn't be a
> >free for all, but some objective criteria for accepting/rejecting
> >contributions should be clearly spelled out. The statement on the main
> >page, "Libraries accepted for inclusion ..." should be followed up
> >with such criteria. Politics can never be fully exorcised out of such
> >efforts, but clear guidelines will help anyone considering a
> >contribution to the site.
>
> If it was a Web 2.0 site, one could combine a (mostly) free-for-all
> approach with a user rating facility (or instead of or in addition to
> the user ratings, one could use the Google pagerank of the subpage for
> rating it). Of course, all of that only makes sense if there is a way
> to query for subpages; again, one could use Google as a cheap
> alternative to a home-grown query engine.
>
I'm not objecting to whatever model Stephen wants to follow for the
website, just that it be stated as clearly as possible. The main page
suggests some sort of review, and mentions a steering committee, while
the more detailed information about submissions to the site suggest
that it is fairly open. If the purpose is to develop a community
website, then a more decentralized decision-making on acceptance of
submissions is preferable (i.e. with the submissions going for peer
review). However, it is Stephen's site and he is free to do as he
chooses.
> >Also, the following bit of nonsense should be removed from your main
> >page,
>
> >"Reinventing the wheel should be considered a sin."
>
> I read that as a motivation for this project: Share your code and use
> the shared code instead of reinventing the wheel!
>
> - anton
> --
I believe that may have been what Stephen intended, but the wording
also suggests to me that multiple libraries for the same functionality
are discouraged, e.g. string libraries or OOP libraries. In any case,
I think it is an ill-considered statement to make on the main page.
> 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 2009:http://www.euroforth.org/ef09/
Krishna
Krishna Myneni
> ... Forth is now mostly old-timers who've seen better days ...
Your description of c.l.f. reminds me of the BBC program, "The Last of
the Summer Wine". Or, perhaps, as I have seen when in India, how the
remnants of the population of a rural village consists of old, retired
people, while the younger ones have departed in search of a better
life in the cities...
Krishna
Anton Ertl
>On Dec 13, 9:38=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Applying your argument to hybrid cars (for Web 2.0) and remote keyless
>> systems (for JavaScript etc.), would you say that the high proportion
>> of hybrid cars with remote keyless systems means that all cars with
>> lots of other examples of this kind.
>
>Its not as if I equated requiring the common pre-requisites WITH Web
>2.0. I coined "Web2.0-only" as a shorthand and said what it signified.
I find no definition in the posting where you first use the term.
>I understand and, indeed, approve of efforts to eliminate those
>technically unnecessary barriers to access - having those technical
>barriers in place may well be seen as contrary to the spirit of Web2.0
>even as they plague Web2.0 sites.
>
>Your discussion proves that you *know* about the type of sites I am
>talking about, so I don't grasp why you prefer (1) arguing about
>whether that is intrinsic to Web2.0, when I've never said anything
>suggesting that it is
Except by coining this name. Even if you define what it means (which
you did not, at least at first), if that name is successful, it will
be used without the definition, and the result will be that "Web 2.0"
loses its meaning.
It's as if you were a marketing guy for JavaScript who wants to
transfer the positive cachet of "Web 2.0" to your product by
associating the name with your product (and the general result if the
marketing campaign is successful is that the name uses its meaning).
And often the marketing guys don't use the term in its original form,
but use some altered form (e.g., "Web 2.0-only") so nobody can legally
demand that the product should have the properties commonly associated
with the unaltered term.
>to (2) offering a shorthand that you find less
>objectionable.
"JavaScript" or "JavaScript-only" is not so long that a shorthand is
required. But if you want a shorthand, "JS" is a common one.
>The fact that the car can be driven when the remote keyless system is
>broken indicates that your analogy is quite a bit looser than is
>required for a persuasive argument by analogy.
Ah, the "-only" aspect. Ok, replace "remote keyless system" with
"pneumatic tires" if that's relevant to your understanding of the
analogy.
Bruce McFarling
wrote:
> I find no definition in the posting where you first use the term.
No, I offered that later, when it turned out that the meaning was not
clear from the context. But earlier than here.
> It's as if you were a marketing guy for JavaScript who wants to
> transfer the positive cachet of "Web 2.0" to your product by
> associating the name with your product (and the general result if the
> marketing campaign is successful is that the name uses its meaning).
You are talking as if marketing is just advertising and promotion, but
in the market development side of marketing, this is exactly what has
been done by those promoting Javascript and Adobe Flash - making
possession of those technologies a pre-requisite for participating at
the majority of mainstream Web2.0 sites.
> >to (2) offering a shorthand that you find less
> >objectionable.
> "JavaScript" or "JavaScript-only" is not so long that a shorthand is
> required. But if you want a shorthand, "JS" is a common one.
Yes, but Javascript, while necessary for access to the full Web2.0
experience in most mainstream sites, is not sufficient. You also need
Adobe Flash - and, indeed, the ability to download and install the
latest flash plug-in when the one you are presently using is made
obsolete.
The co-ordinated drop down menu system and side-bar link list code
that was borrowed from the site only assumes the Javascript side, but
go to most mainstream Web2.0 sites with a working Flash plug-in and
you see whatever your browser shows for a non-working plug-in
scattered all over the place - the jigsaw puzzle piece with the flu in
Google Chrome.
> The fact that the car can be driven when the remote keyless system is
> >broken indicates that your analogy is quite a bit looser than is
> >required for a persuasive argument by analogy.
> Ah, the "-only" aspect. Ok, replace "remote keyless system" with
> "pneumatic tires" if that's relevant to your understanding of the
> analogy.
A closer analogy would be if I said that common hybrids require access
to a gasoline service station, and you pointed to an LNG or diesel or
ammonia burning pluggable hybrid that could run indefinitely within
its battery range on electric power alone, and did not need gasoline
at a service station to extend that range.
If I was talking from a place where the common hybrids are parallel
gasoline hybrids and not pluggable, the answer would not be that I
disagree with the statement, but that's not the kind of hybrid I was
talking about when I said normal hybrid.
I haven't seen you say anything about Web2.0 that I disagree with, and
have no emotional investment in the term that I coined, so if you have
a better term for the multitude of sites that assume that people
participating in Web2.0 have that specific technology set, which
thereby perpetuates the perceived need to have that technology set,
which thereby ensures that most people particiating in Web2.0 have
that technology set, which thereby allows the multitude of sites to
assume that people participating in Web2.0 have that specific
technology set, I'll happily use it. Javascript-only is only a partial
description of those kind of sites.
John Passaniti
2.0" is being used here seems to be based on the *technologies* that
are common in modern web sites and web applications. But the term
"Web 2.0" is more usefully a description of the kinds of applications
that promote online communities and sharing of information.
So a wiki is "Web 2.0". A blog is "Web 2.0". A RSS feed of new items
is "Web 2.0". Labeling messages with tags and then using those tags
to sort, relate, and navigate messages is "Web 2.0". Protocols that
relate people and indicate the relationship of context to people (like
XFN and FOAF) is "Web 2.0".
None of these things (and more) require JavaScript, exotic DOM
manipulation, Flash, SVG rendering, asynchronous RPC, or any of the
other many technologies commonly found in modern web sites and web
applications. That's because "Web 2.0" is less about the technology,
and more about moving the web from static pages to a platform for
people to collaborate. So yes, I would like to see "Web 2.0" features
in the FLAG. If I was managing it, I would structure it as a blog
with ongoing commentary about the state of FLAG, and possibly per-
library or per-developer blogs. I would also have a wiki where the
community could collaborate on the design and documentation of Forth
libraries. And I'd provide an RSS feed for both.
Note that none of that requires JavaScript, Flash, or other
"controversial" technologies. But those technologies aren't just
about "glitz" but improving user interfaces.
And regarding that last bit, Anton is absolutely correct that there
are potential security issues with JavaScript. There are also
potential security issues with plain email using social engineering.
Hell, clicking on *any* link could at any time take you to an
unexpected place if a DNS server was compromised. Oh, and since it's
possible to craft image files so that the renderer is subverted to
execute code, so I guess you better not view any web page that has
images.
So yes, I think that for those who are paranoid or trying to increase
their geek-cred by using down-level text-mode browsers, sprinkle
<noscript> tags and present to them the interface of their dreams--
straight text with hyperlinks. For the rest of us-- we'll suffer
through the improved usability and additional features that come from
modern interfaces.
Bruce McFarling
> Note that none of that requires JavaScript, Flash, or other
> "controversial" technologies. But those technologies aren't just
> about "glitz" but improving user interfaces.
This is an important point. While a subset of mainstream Web2.0 work
hard to maintain accessibility to those without those technologies,
even those tend to make *use* of those technologies where available to
make the site more usable.
There are many, eg, political discussion sites with more or less
WYSIWYG comment editors that can be deselected in favor of auto-
format, plain text and/or html text boxes, and can be used without
Javascript - indeed, with a console browser - but obviously is the
WYSIWYG comment editor is not there.
Indeed, you can Twitter from Lynx using the m. rather than www.
access, but you can't use TwitHive to get distinct panels of users in
distinct groups.
> So yes, I think that for those who are paranoid or trying to increase
> their geek-cred by using down-level text-mode browsers, sprinkle
> <noscript> tags and present to them the interface of their dreams--
> straight text with hyperlinks.
In education, testing accessibility with text-mode browsers is an
easier way of making sure that students will be able to get to the
information even with obsolete or inexpensive equipment.
Given the purpose of FLAG, it would be appealing if someone who had
brought a system up to the point of getting onto the net could go to
FLAG and use it as a repository.
However, I am not sure that <noscript> tags need to be scattered
around. As I noted, if a site map can be generated on the fly using
the same information that the Javascript uses to generate the drop
down menu and the link side-bar, then you'd only need the one
<noscript> tag and link to the site map.
gavino
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
I think this is where people get into the whole component thing.
Webpages reduced to reusibel pieces.
Some tools make each one have server side state.
here is an interesting stackless python tool doing it
http://www.nagare.org/trac/wiki/NagareDescription
John Passaniti
> > So yes, I think that for those who are paranoid or trying to increase
> > their geek-cred by using down-level text-mode browsers, sprinkle
> > <noscript> tags and present to them the interface of their dreams--
> > straight text with hyperlinks.
>
> In education, testing accessibility with text-mode browsers is an
> easier way of making sure that students will be able to get to the
> information even with obsolete or inexpensive equipment.
In any decent content management system, there is a clear separation
between the content and the presentation. I see nothing wrong with
starting FLAG exactly the way it is. If the underlying system is
based on modern principles of separating content from presentation, it
means that at any time, new interfaces can be created-- and offered
concurrently. If you had evidence that crushing throngs of people
would be offering a deluge of Forth code if not for some JavaScript
menus, I'd be with you. But as I happen to be someone who runs
several web sites-- and more importantly someone who collects browser
statistics on those sites-- I can tell you it's a tiny minority of
people out there who (1) aren't using graphical web browsers, (2)
don't have JavaScript enabled, (3) aren't using a browser that meets
most modern standards. So yes, if that means some poor student
somewhere stuck using Lynx is "locked out" of the FLAG site until a
down-level presentation is made, then oh well. They can instead use
the time they would have wasted writing some awesome Forth code and
send it to any of the 99% of people who will be accessing it with
their too-powerful machines, big monitors, and fast Internet
connections to post it for them.
It boils down to time management. On one of my partner's web sites, I
had to make the decision on if I should use my limited time to add
some functionality that would make it easier for people to post, or if
I should spend that same time to rework the site so it was more
accessible by people using text-mode browsers. So I pulled up the
statistics, found that 1% of the users were using Lynx. Go ahead and
guess how I spent my time. And as a result, there are now a couple
users who left the system. Maybe they'll come back when I get some
more time and come up with an interface that addresses them. Maybe
not. I'll try to sleep at night.
> Given the purpose of FLAG, it would be appealing if someone who had
> brought a system up to the point of getting onto the net could go to
> FLAG and use it as a repository.
Yep, and the vast majority of people can.
And for those few who can't, either because of limitations in their
environment or self-imposed "I won't use that site because it uses X"
mindsets, they are free to simply wait until others have the time to
generate an interface for them.
If I was running such a site, I would probably make the filesystem be
a Subversion or git repository, allowing tracking of changes. But if
I did that, I can bet someone out there would cry, "but I don't have a
Subversion or git client for my VIC-20." There are always people who
will not be able to access *some* technology.
Bruce McFarling
> On Dec 14, 7:50 pm, Bruce McFarling <agil...@netscape.net> wrote:
...
> If you had evidence that crushing throngs of people would be
> offering a deluge of Forth code if not for some JavaScript
> menus, I'd be with you.
"Doing this won't accomplish what nothing can accomplish, so
its clearly of no conceivable benefit to do this."
This is not a useful frame, so this part of the argument
can be ignored.
> But as I happen to be someone who runs several web sites--
> and more importantly someone who collects browser statistics
> on those sites-- I can tell you it's a tiny minority of
> people out there who (1) aren't using graphical web
> browsers, (2) don't have JavaScript enabled, (3) aren't using
> a browser that meets most modern standards.
It is also a tiny minority of people that have an
interest in a Forth code repository, so you've got
the small cross-tab frequency problem from contingency
analysis. You are assuming independence, but in the
small cell count problem, there can be substantial
interdependence that cannot be discriminated from
statistical independence - that is, if the risk of a
false positive is to be kept to some low level, the
risk of a false negative rises substantially.
If there are 1% of all potential browsers with that
type of browser and those accessing a Forth source
code library are 0.0[0]*1% of all potential browsers,
and there is every reason to expect a positive
correlation between the two, then it could be 1.2% of
the population of interest with that type of browser
or 12%.
> So yes, if that means some poor student somewhere
> stuck using Lynx is "locked out" of the FLAG site until
> a down-level presentation is made, then oh well.
Misframing again - confusing with the concrete reason
given above for why some in education use Lynx to test
accessibility as opposed to having a battery of different
specialized test set-ups. If it can be browsed in Lynx,
its a lot less likely to be problematic when browsed with
a screen reader or hand-me-down computer or mobile device.
In the situation at hand, five sources for potential
positive correlation that come to mind are:
* someone interested in Forth for embedded computing may
find the ability to download source code directly from the
repository appealing.
* The people who have those kind of browsers because of
resource constraints will almost all face some other
restrictions while using a system that can readily
support not just a Forth kernel, but often a full-fledged
Forth development environment.
* The people who are bringing up a new system constrained
by capabilities not yet up or running a recovery in a
system constrained by whatever it is recovering from would
be attracted to a code library that can be used to
bootstrap.
* The people who have those kind of browsers because of
the geek effect, derided above, may be more willing to
experiment with a niche language, especially if they
seen an intriguing application at FLAG.
* The people willing to dispense with commonplace
access because of a concern like Anton's security
concern might be more interested in accessing a code
library with code that they can test from the ground
up.
Most of those do not imply running the non-standard
browser all the time, or even much of the time,
but any would give a biased frequency distribution.
> They can instead use the time they would have
> wasted writing some awesome Forth code and send
> it to any of the 99% of people who will be accessing
> it with their too-powerful machines, big monitors,
> and fast Internet connections to post it for them.
If you vouch for the utility of sarcasm regarding
the site users when managing whatever web sites you
manage, I guess I'll have to take your word for it,
but its not a useful attitude for a librarian to
adopt.
> It boils down to time management.
Quite. If there was some modification of the site
under which Anton Ertl just might possibly consider
putting up and being librarian for a body of source
code, and it had as little overhead as a static site
map generated on the fly and accessed through a
noscript tag that, you suggest, 99% of viewer would
never see to be able to click on, and some other
modification of the site under which John Passaniti
might consider putting up and being librarian for a
body of course code, there really isn't any question
that first you'd do the static site map generated on
the fly and accessed through a noscript tag.
John Passaniti
> "Doing this won't accomplish what nothing can accomplish, so
> its clearly of no conceivable benefit to do this."
No, that's a distortion of what I wrote. I see obvious benefit in
making sure the FLAG site is accessible to down-level browsers (and
browsers the user chooses to cripple). The question isn't if there is
"no conceivable benefit" but what is the value of that benefit
relative to other efforts? It's a simple matter of getting the most
bang for the buck-- and the buck here is Stephen Pelc's. I see
nothing wrong with him starting off with the current framework, and
then moving to including other alternate user interfaces as he has
time (or as the Forth community wants to generate them).
> Misframing again - confusing with the concrete reason
> given above for why some in education use Lynx to test
> accessibility as opposed to having a battery of different
> specialized test set-ups. If it can be browsed in Lynx,
> its a lot less likely to be problematic when browsed with
> a screen reader or hand-me-down computer or mobile device.
I have no problem with this other than... Stephen put forth the effort
here, and he presumably chose software that would allow him to quickly
get the framework of the site up and running. He's free to consider
the suggestions for increased usability and make changes later. You
(and others) are also free to invest your own time and effort in
setting up your own site.
> * someone interested in Forth for embedded computing may
> find the ability to download source code directly from the
> repository appealing.
Yep, which is why I hope in the future that the code is available
without *any* user interface using predictable naming patterns. For
example, if there was a standard regular expression library named
"regex" it would be available at a predictable URL like:
http://soton.mpeforth.com/flag/lib/regex.tar.gz
Or whatever the actual standard would be. The point is that there
should be a predictable path, given a library name, that user agents
like wget could use to reliably get such libraries. Whatever other
user-oriented interfaces existed are a separate issue.
> * The people who have those kind of browsers because of
> resource constraints will almost all face some other
> restrictions while using a system that can readily
> support not just a Forth kernel, but often a full-fledged
> Forth development environment.
Then what you want isn't a web-based user-oriented presentation at
all. What you want is a set of standards (probably riding on top of
HTTP) where the user can query and obtain software, in much the same
way that binary package managers (like apt-get) work. Those standards
would be to define a catalog of libraries, be able to download
metadata for a library, and download the library itself. That kind of
interface is simpler than even Lynx, requiring nothing but HTTP and a
few conventions to download the files.
The result is, again, separation of content from presentation. Having
a scheme for organizing code like this, with catalogs and metadata
files allows the creation of arbitrary user interfaces. It allows a
web-based user interface, either stripped-down or jazzed-up. It
allows text-based user interfaces. It allows graphical user
interfaces for systems that offer such.
That's what I would do. But I'm not Stephen, and I'm not going to
tell him how to use his time.
> * The people who are bringing up a new system constrained
> by capabilities not yet up or running a recovery in a
> system constrained by whatever it is recovering from would
> be attracted to a code library that can be used to
> bootstrap.
Yep, so bypass Lynx all together, use HTTP as what it is (a transport
protocol), and devise a set of conventions so that someone can
reliably download code without any web-browser. All Stephen would
need to do would be to come up with naming and placement standards.
> * The people who have those kind of browsers because of
> the geek effect, derided above, may be more willing to
> experiment with a niche language, especially if they
> seen an intriguing application at FLAG.
Those geeks would be just fine with a text document saying "here is
the base URL, here is a list of libraries, and here is the naming and
placement standard for downloading them. No web is necessary. And
that has like a thousand more geek-cred points than even using Lynx.
Using user agents like wget or curl or even netcat is the macho he-man
way to get code.
> * The people willing to dispense with commonplace
> access because of a concern like Anton's security
> concern might be more interested in accessing a code
> library with code that they can test from the ground
> up.
If security is a real concern, then getting the raw files using wget
or curl solves that even better. Lynx has it's own security
concerns-- phishing attacks are even easier with Lynx since the
phisher doesn't even have to make the site look the same graphically.
> If you vouch for the utility of sarcasm regarding
> the site users when managing whatever web sites you
> manage, I guess I'll have to take your word for it,
> but its not a useful attitude for a librarian to
> adopt.
I'll vouch for the utility of getting the most bang for the buck.
I'll also vouch for personal experience in that no matter what kind of
web site one constructs, it's going to annoy some subset of people.
> > It boils down to time management.
>
> Quite. If there was some modification of the site
> under which Anton Ertl just might possibly consider
> putting up and being librarian for a body of source
> code, and it had as little overhead as a static site
> map generated on the fly and accessed through a
> noscript tag that, you suggest, 99% of viewer would
> never see to be able to click on, and some other
> modification of the site under which John Passaniti
> might consider putting up and being librarian for a
> body of course code, there really isn't any question
> that first you'd do the static site map generated on
> the fly and accessed through a noscript tag.
Actually, I've created enough web sites that I wouldn't start with a
web site at all.
I'd start first with a set of standards to define the architecture of
the site-- that would be naming and placement conventions for a
catalog, metadata files, and library code. I would design that such
that not only the web site, but any other user agents (including Forth
itself) could access that data.
I'd next be concerned about versioning of data, so I would build the
architecture on top of something like Subversion. Doing that does
four things. First, it maintains a HTTP interface. Second, it
provides history. Third, it allows easy replication of the repository
elsewhere. Fourth, it allows people to pull in that content using
externals (the equivalent exists for git and mercurial as well).
Finally, yes, I would probably create a static web site that was
driven from that content. It's wasteful to generate such on the fly--
it only needs to be generated whenever there are changes. I would
also sprinkle in a wiki's and blogs to help track progress and
collaborate on the development of libraries.
But... I'm not Stephen, and I wouldn't tell him how to use his time.
I also have different priorities. He seems to want to have a
repository for code. I would be much more interested in a site that
was centered around collaborative design of libraries and having the
same kind of ability to search, download, and install libraries that I
get with other languages. What Stephen wants (and what you seem to be
fixating on) is a web site where you can click on a link, download a
file, and then manually install it. That's so 90's. The goal should
ultimately be that if I want a library (say, a regular expression
library named "regex") I should be able to be able to run a simple
command-line interaction that looked like this:
$ flag-search regex
regex 2009-12-16 1.6 regular expression library for Forth
1 match
$ flag-info regex
library: regex
version: 1.6
date: 2009-12-16
description: regular expression library for Forth
license: MIT
author: Anna Rexia <anna....@gmail.com>
website: http://www.whatever.com/regex
dependencies: this, that, the-other
$ flag-get regex
regex requires the following libraries: this that the-other
download these libraries too? Y
this 1.1
that 2.1
the-other 1.5
regex 1.6
$ gforth
require regex
...
You'll note a lack of a web browser in the above. The web is just a
choice of user interface.
For inspiration, I'd recommend any of the following standards used by
other languages, such as Ruby's Gems, Lua's Rocks, PHP's Pear, Perl's
CPAN, etc.
David N. Williams
> [...]
>
> I'd start first with a set of standards to define the architecture of
> the site-- that would be naming and placement conventions for a
> catalog, metadata files, and library code. I would design that such
> that not only the web site, but any other user agents (including Forth
> itself) could access that data.
>
> I'd next be concerned about versioning of data, so I would build the
> architecture on top of something like Subversion. Doing that does
> four things. First, it maintains a HTTP interface. Second, it
> provides history. Third, it allows easy replication of the repository
> elsewhere. Fourth, it allows people to pull in that content using
> externals (the equivalent exists for git and mercurial as well).
I have very limited experience as a client of Subversion, but
this sounds appealing to me.
> Finally, yes, I would probably create a static web site that was
> driven from that content. It's wasteful to generate such on the fly--
> it only needs to be generated whenever there are changes. I would
> also sprinkle in a wiki's and blogs to help track progress and
> collaborate on the development of libraries.
Wiki/blog features appeal, too. As long as they don't use those
damned, cursive fonts. :-(
But that's easy for me to say, having no idea what it takes to set
such things up.
-- David