online algebra files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

online algebra files

daly
Bill,

I just saw the page
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FrontPage

This ROCKS! Nice work.

Being able to create/update axiom online would be great because it
would make the modification task "embarrassingly parallel" in most
aspects. It will, of course, make my life of integrating it all a
living hell but it would be worthwhile anyway.

There are still a lot of "quality" tasks that go on behind the scenes.
I document changes, update the CHANGELOG, rebuild from scratch, hand
check the testcase output, cross-build on various platforms, and
"round-trip" the changes (checkin, erase, checkout, rebuild, retest)
before release. And finally the release gets pushed to all three
archives (arch, savannah, sourceforge).  I don't see how these tasks
can be performed in parallel. I do feel they are necessary to make
sure the quality stays high. Every step is there because it eliminates
some problem that has bitten me in the past.

We need to think about ways to merge a web-based changes to the
official archive. How do you see this happening? Would it be
possible to do a

  diff -Naur archive.version web.version >web.version.patch

for changed files? The "diff -Naur old new" is my primary tool.

Tim



_______________________________________________
Axiom-developer mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Reply | Threaded
Open this post in threaded view
|

Re: online algebra files

Bob McElrath-2
root [[hidden email]] wrote:
> Bill,
>
> I just saw the page
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FrontPage
>
> This ROCKS! Nice work.

Ok that is cool.

A few (very obvious) directions for future work...I wish I had more
time...
1) HTML instead of images
2) Fill in abstracts for each domain
3) Disable comments on these pages.  (Or, organize them differently...we
surely don't want to be appending comments to the source code!)

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "In science, 'fact' can only mean 'confirmed to such a degree that it would
    be perverse to withhold provisional assent.' I suppose that apples might
    start to rise tomorrow, but the possibility does not merit equal time in
    physics classrooms." -- Stephen Jay Gould (1941 - 2002)

_______________________________________________
Axiom-developer mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/axiom-developer

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: online algebra files

Page, Bill
In reply to this post by daly
Tim,

On Thursday, October 20, 2005 11:00 AM you wrote:
> ...
> Being able to create/update axiom online would be great because
> it would make the modification task "embarrassingly parallel"
> in most aspects. It will, of course, make my life of integrating
> it all a living hell but it would be worthwhile anyway.

;) Actually, my intention was to make your life **easier**
and also to reduce the amount of time required to make patches
to Axiom.

>
> There are still a lot of "quality" tasks that go on behind the
> scenes. I document changes, update the CHANGELOG, rebuild from
> scratch, hand check the test case output, cross-build on various
> platforms, and "round-trip" the changes (checkin, erase, checkout,
> rebuild, retest) before release. And finally the release gets
> pushed to all three archives (arch, savannah, sourceforge).

You can (should?) of course continue to do this. I agree that it
is important to maintain at lease one Axiom source archive that
can be treated as "authoritative".

> I don't see how these tasks can be performed in parallel. I do
> feel they are necessary to make sure the quality stays high.
> Every step is there because it eliminates some problem that has
> bitten me in the past.

I think each developer has his own style and preferred tools.
I do not see anything wrong with other developers working in
parallel with their versions of the Axiom sources and submitting
patches to you - better using the new MathAction online access
to the 'axiom--test--1' archive.

One thing that we need to insist on, however is that all developers
take the time to write documentation about the changes they are
making. HI think having the Axiom pamphlet source on-line and
visible should help to encourage developers to do this.

>
> We need to think about ways to merge a web-based changes to the
> official archive. How do you see this happening? Would it be
> possible to do a
>
>   diff -Naur archive.version web.version >web.version.patch
>
> for changed files? The "diff -Naur old new" is my primary tool.
>

What I have in mind is for updates of the Axiom source on
MathAction to be mirrored in a separate tla branch archive
I have called 'axiom--test--1'. This is not implemented yet
but it will be very easy to do. That way, after making some
changes online, a developer could just do a

  % cd axiom--test--1
  % tla update
  % ./configure
  % make

and immediately start testing the new experimental version.

To (selectively) transfer these changes to the 'axiom--main--1'
branch tla has some simple built-in diff-style commands for
comparing versions between branches and applying patches. Of
course one could also continue to do it the old fashioned manually
intensive way with just "diff -Naur old new".

Regards,
Bill Page.


_______________________________________________
Axiom-developer mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Reply | Threaded
Open this post in threaded view
|

RE: online algebra files

Page, Bill
In reply to this post by daly
On Thursday, October 20, 2005 12:25 PM Bob McElrath wrote:
>
> A few (very obvious) directions for future work...I wish I had more
> time...
> 1) HTML instead of images

Well, yes but ... :)

The only image used is just the first page of the document
derived by 'dvipng' from the associated 'dvi' file. You should
think of this as only a kind of "thumbnail" for the actual
document. It is much smaller than any HTML representation of
the actual document and therefore displays more quickly on
less powerful workstations and slow network connections.

This is the whole problem using pure LaTeX source on LateWiki.
After some experiments with embedded PDF, I had to agree with
your initial revulsion to that approach. So I had hoped instead
to be able to use a good LaTeX to XHTML+MathML (such as tex4ht)
and really present the document to the user this way. But as
we know there are still many problems with this approach. At
this time I am still considering whether to provide 'mml' as
a display option along with 'dvi' and 'pdf'.

> 2) Fill in abstracts for each domain

Yes! Please, someone start to do this ASAP.

> 3) Disable comments on these pages.  (Or, organize them
> differently...we surely don't want to be appending comments
> to the source code!)

The current pamphlet source format on MathAction has two
parts: the '\documentclass ... \end{document}' part containing
the actual pamphlet source from the Axiom distribution, followed
immediately by the LatexWiki-style StructuredText+LaTeX+Axiom
content (possibly none).

The page is rendered by first applying 'noweave' to the entire
page source. This has the side-effect of ignoring any material
following \end{document}. The resulting LaTeX source is then
processed by the following sequence of commands:

  latex
  latex
  dvipdfm
  dvipng -l 1

A header contain the png graphic and linking to the other
formats is created and then the remaining part of the source
(if any) is simply processed as if it was of pagetype

  StructuredText + LaTeX ( + Axiom )

As usual, comments are simply appended to the end of the
page source and so are rendered in the same way as before.

I do not see any problems with collecting comments as part
of the page source. Because of the literate programming noweb
format these will remain invisible to the extracted source
code and to the rendered documentation. But as time permits
it will be possible for pamphlet editors to easily review
these comments and either discard them or incorporate them
into the pamphlet source.  

To me, this seemed like "the best of both worlds". :)

Regards,
Bill Page.


_______________________________________________
Axiom-developer mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/axiom-developer