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

[Bill Page]

On Thursday, September 30, 2004 12:25 PM Bob McElrath wrote:
> 
> root address@hidden wrote:
> > I hope that, in the longer term, the mathaction wiki page 
> > presents the original pamphlet file when you click 'edit'.
> > That would imply running noweb in the background when you
> > click 'save'.

That is *exactly* who the pamphlet support in MathAction will
work. You will be able to try it very soon now, once I tweak
l2h just a little more to avoid a problem in the way it creates
cross-references in an HTML+LaTeX file which sometimes messes
up the LatexWiki processing. Running it "in background" is
straight-forward.

> > The hard part, of course, is that the change might actually
> > fail, in which case there will be a noweb msg or latex log
> > file.

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.
 
> [Bob replied:]
> Right now the page is not rendered and an error is printed
> at the bottom of the page when you view it.  Ideally, this
> integration should be tighter.  Perhaps a "test" button that
> could pop up the rendered page?

YES! I would like this sort extension of LatexWiki very much.
It would also help solve the problem of "junk email" being
sent to wiki subscribers while just trying to get "something
stupid", right. I like to run the MathAction wiki with the
subscription options set to send all edits and not just the
new page stuff. But this can sometimes get tedious. If a
user could click a Draft or Preview button instead of the
Save button, then editing cycle could be (Edit, Preview)*,
Save with only the final Save resulting in sending the
diffs to the subscribers. A few weeks ago I did look at
the possibility of adding this but I realized that it would
really have to be an extension of ZWiki, not LatexWiki,
and I did not know enough about ZWiki to even attempt it.

> [Tim continued:]
> > If we could do this then it would be possible (at least
> > technically) to maintain axiom directly from the wiki
> > pages. Of course there are a lot of little steps along
> > the way. I'd like to see the ability to integrate CVS
> > (or arch?) automatically into web page changes.

I think that this will be quite easy to implement. The
only step that I see missing in what I am doing right now
would be some means to directly integrate the wiki pages
containing the pamphlet code into the notangle processing
in the build makefile. Wiki pages are Zope objects that are
not directly accessible to the file system.
 
> 
> This was mentioned before...
> 
> Zope has a rudimentary "change history" that can be used
> to undo bad changes, but it is crude as a versioning system.

Personally, I think that Zope's history mechanism would be
sufficient for most purposes (I don't know how many times
the Zope Undo has saved me from loosing important work)
although, granted it is not darcs, arch or even CVS. However
I think there are some Zope products available that do this
sort of integration with CVS and arch. I don't know how well
or even if this would work with ZWiki / LatexWiki / MathAction.

> [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?

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.

Regards,
Bill Page.