axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: literate programming pamphlet files for MathAc


From: Bob McElrath
Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction
Date: Fri, 1 Oct 2004 11:26:35 -0700
User-agent: Mutt/1.5.6+20040523i

Bill Page address@hidden wrote:
> That is of course already a problem when writing Axiom and
> Reduce code that might fail for a variety of reasons. In fact
> it is also true for simple LaTeX coding errors and sometimes
> even unexpected results from "structured text" mode.

I am busy rewriting StructuredText right now.  My goal is to have it
*never* fail.  This is in keeping with the "wiki design
principles":http://c2.com/cgi/wiki?WikiDesignPrinciples .  Right now
StructuredText failes the 'tolerant' criteria.

However, latex/axiom/reduce *cannot* be tolerant since their input must
be precise.  Beyond being syntactically correct it must also be what the
user desired semantically.  Anyway, please take a look at my
WikiDocument attempts (see prev message).  This is the way of the
future.  As you are probably discovering, it can be very difficult, and
sometimes impossible to get two sets of regexes that operate on a
document from clashing.

Still though even with the StructuredText classes (also called STNG),
this is still fundamentally a pile of regexes.  It adds hierarchy.
i.e. in the example [this $x$] I want the link processor [] to get it
first and the latex processor $$ to get it second.  But this is still
not a formally defined grammar.

Python has a module 'Yappy' that is a true C{SLR}, C{LR(1)} and
C{LALR(1)} parser, if it is deemed desirable to formally specify the
syntax of the documents axiom uses.

> > [Bob replied:] 
> > There is also a Zope product called FileSystemSite in which
> > your site is stored in a directory on the filesystem, rather
> > than in the ZODB. Such a directory can simultaneously be a
> > CVS/arch/darcs repository. Presumably it wouldn't be that
> > hard to get Zope/ZWiki/LatexWiki to ignore the CVS directory.
> 
> That is yet another way to go, but have you ever tried
> running ZWiki this way? I suspect that ZWiki might be rather
> tightly integrated with the Zope object model so that this
> is not straight forward. For example a wiki page actually
> contains at least two representations of each page, the
> 'source' and the rendered 'presentation' form. Which of
> these would be stored in the file system. Both?

I have no idea.  Someone will have to try it.

> But there might well be some advantages to this on a large
> shared web site. Zope is notoriously slow at serving web
> pages (not surprizing considering all that it does). Storing
> the rendered pages on the file system would allow greater
> use direct use of the Apache front-end server instead of
> depending on http proxy. Already I do this kind of optimization
> for serving the image files from LatexWiki which are stored
> in the file system and not as Zope objects.

Be careful, down the road I intend to store latexwiki images in the
zodb.  For instance this makes it easier to let the users decide if they
want to see mathml or images.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
    
    It is unpatriotic to question the Kleptocracy.

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]