[Top][All Lists]

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

[Axiom-developer] Re: [fricas-devel] Re: Axiom Wiki and Portal are movin

From: Bill Page
Subject: [Axiom-developer] Re: [fricas-devel] Re: Axiom Wiki and Portal are moving
Date: Thu, 1 Nov 2007 10:07:09 -0400


On 01 Nov 2007 07:21:57 +0100, you wrote:
> I'm very grateful to you, even though I'm unhappy that
> will not have the same contents in future.  Oh dear, I link to it in a 
> paper...

I haven't checked this with Tim but I think it his intention to retain
ownership of the '' domain for the foreseeable
future independent of what ever happens to the ''
server. Even though the Axiom wiki and portal applications will not be
running on the '' server at some time in the near
future, it is possible of the owner of a domain to map specific names
in that domain to other machines. So with Tim's help we could manage
to keep the names  '' and
'' pointing at working versions of the Axiom
wiki and portal. Of course these web sites are always subject to
change over time since that is the nature of the applications but I do
not think you should fear that the link in your paper will not work in
the immediate future.

> "Bill Page" <address@hidden> writes:
> >
> >
> > and
> >
> >
> These names sound quite good to me.  "new synthesis" has something optimistic!

Good! I am very optimistic about Axiom. :-)

> > The most serious missing component at the new Axiom wiki site is the 
> > existing
> > database of IssueTracker reports. I have tried unsuccessfully to copy to the
> > old database to the new server. In any case it is also true that a number of
> > these reports may be obsolete or may not apply equally to all of the Axiom
> > projects. Also some of the Axiom projects (forks) have their own way of
> > tracking problems, e.g. OpenAxiom simply uses SourceForge. So I am open to
> > suggestions on how to proceed with this transferring this information 
> > (and/or
> > comments about whether this is really necessary or not).
> Oh dear, that's too bad.  In fact, I'm quite shocked.

Change is inevitable...

> I wanted to make the following suggestion already some time ago: If the three
> projects intend to cooperate, I think it would be a very wise thing to have
> only one database for bugs.

I agree.

> I like IssueTracker a lot, mainly, because it is so easy to demonstrate the
> bug.  Since we have several projects now, it would be necessary though to be
> able to select any subset of
> fixed in Axiom
> fixed in FriCAS
> fixed in OpenAxiom

That is a good suggestion. I think we can easily implement that.

Related to this is a subject which you have raised in the past about
mathaction. I think that in order to fully support all three flavors
of Axiom it will also probably be necessary to allow a user to specify
which version of Axiom is used to execute the commands contained in a
web page. Given the nature of the way that mathaction software works
(because it runs the entire contents of a page in one "batch" when you
click "save"), it would be difficult to refer to more than one version
of Axiom in the same web page. But I think that is desirable and I
plan to find a way to accomplish this. Hopefully pages which refer to
more than one version will be rare.

I propose the following syntax:


Perhaps we could also support some standard versions, e.g.


Here [...] is an optional parameter. {axiom} by itself would refer to
one of the three versions of axiom (no guarantee which one).
{axiom}[open-axiom] would refer to the most recently installed version
of open-axiom, etc.

> Since FriCas and Axiom refers to the IssueTracker numbers in the logfiles and
> in source, it is a must (if possible) to keep the database numbering as is.

That is possible since issuetracker entries are just wiki pages and
these can be easily renamed.

> Do you know already whether transferring is a fundamental problem?

No it is not a fundamental problem, it is only a result of a
combination of changes that makes the usual method of doing this (by a
program call ZSyncer) fail. The main reason for the failure is that
the page type field that indicates to ZWiki how to process the
contents of a page has changed in this new version. I tried to resolve
this problem by using the "export to xml" function that is built into
Zope and by using a script to edit the page type field before
re-importing it to the new server, but then I discovered that the
format of this xml file is quite complex and has also changed. To make
this work would require more time and programming. One approach might
be to hach the ZSyncer package so that it makes the change of page
types internally during the transfer.

The problem with the usual "cut-and-paste" method is that I have not
found any way to transfer the status and classification field
information. Only the text content of the page is visible. Of course
it would be possible to set the fields later, but we are talking about
nearly 300 pages.

An alternative that I haven't checked is using "External Edit". I do
not have the external edit feature enabled on my workstation so I
cannot easily check. Martin, I think you do use this right? Could you
check if the status field information appears editable when you access
the page this way? One more approach that *might* work is to use ftp
to access the page and copy it to the new system. ftp is currently
enabled at the site but not yet at the
newsynthesis site. I will try this as soon as I get a bit more serious
time to spend on it (this weekend).

Bill Page.

reply via email to

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