axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] hyperlinked algebra


From: Bill Page
Subject: RE: [Axiom-developer] hyperlinked algebra
Date: Wed, 7 Dec 2005 23:23:54 -0500

On December 7, 2005 6:08 PM Tim Daly (root) wrote:

> 
> I've hacked src/doc/endpaper.pamphlet to add hyperlinks.
> most of the links go to catdef.spad.dvi because they are
> categories that live there. I don't know how to implement 
> #tags in latex yet.

This is possible if you generate a PDF or HTML. But whether
it will work with dvi files or not is likely to be highly
dependent on your particular dvi viewer software.

> 
> not everything goes to catdef. ffield goes to ffcat.spad.dvi
> and the data structures tend to go to aggcat but others can
> be found (e.g. matcat).

This raises the question again of whether it is really such a
good idea to aggregate Axiom categorys and domains into larger
groupings. Already this caused some problems with navigation to
source files in Hyperdoc and from the Axiom interpreter when
you went from about 1,300 individual spad files into about 350
pamphlet files. Currently you seem to be planning to take this
even further and aggregate the 350 into maybe 20 or so "volumes".
Doing this means that you can no longer take advantage of the
file system and you have to start building additional features
to access pieces of these files etc. Maybe we need to think more
about this and discuss it some more.

Often in web application design one is faced with a similar issue
of choosing the right level of "granularity" for the HTML pages.
If they are too big, then navigation degenerates into more or
less linear browsing and network performance suffers. If they
are too small, then it becomes hard for a reader to quickly get
the "big picture" and everything seems more complex unless
the navigation links are carefully designed and other access
methods like online searching is available.

I think the choice of granularity is also strongly influenced
by what tools one is using. One thing that drives you toward
a smaller number of larger "volumes" is the use of noweb-style
literate programming (i.e. pamphlets). Cliff reminded me recently
about "Leo" - a fairly new literate programming environment that
we discussed a while time ago.

See: http://webpages.charter.net/edreamleo/front.html

Leo is:

# A general **data management** environment.
  Leo shows user-created relationships among any kind data:
  computer programs, web sites, etc.
# An outlining editor for programmers.
  Leo embeds the **noweb** and CWEB markup languages in an
  outline context.
# A flexible **browser** for projects, programs, classes or
  any other data.
# A project manager.
  Leo provides **multiple views** of a project within a single
  outline.
  Leo naturally represents tasks that remain up-to-date.
# Portable. Leo runs on Windows, Linux and MacOS X.

etc. There is a lot of good documentation available about Leo
and it is a very active project with a large number of
registered developers.

I still think that using a literate programming tool like Leo
would be a big advantage over the "pamphlet" approach. And because
it is specifically designed as a "data management environment" in
addition to a programming environment, it goes a long way towards
solving the granularity issue because Leo's outline structure
allows you to organize smaller pieces into a coherent whole.

Of course, we are still in the same situation now as we were
when we last talked about this: Using Leo for Axiom would be a
big step and would involve a significant learning curve... and
here we are still with insufficient resources. :( But if there
are any Axiom developers who might find this sort of project
interesting, then I would be very happy to help setup an
experiment to try Leo with the Axiom source distribution.

> 
> I tried to use URLs to the wiki but xdvi can't handle them.

If you mean URLs of HTML pages on the wiki, then no of course
your dvi viewer can't handle that. But depending on the version
of the dvi viewer, it might pass such reference off to a real
web browser. If you use the href to point directly to the dvi
file using the url contents of the 'dvi' link on each pamphlet
thumbnail page, then I think that should work. If these dvi
files in turn included there own hyperref links than this
process could continue.

Or do you mean that the version of xdvi that you are using does
not understand urls (Internet links) of any kind? The href links
that you show below are not urls, but rather direct references
to local files.

> ...
> {\hbox{\hskip 4.0cm}}
> % SETCAT SetCategory
> {\psframebox{{\rnode{setcat}{\href{catdef.spad.dvi}{setcat}}}}}\\
> ...

Regards,
Bill Page.






reply via email to

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