Some special FriCAS-specific LaTeX commands might not be understood by MathAction. For example:

  \def\zag#1#2{
    {{\hfill \left. {#1} \right|}
     \over
     {\left| {#2} \right. \hfill}
    }
  }

This LaTeX definition has to go in the preamble that is stored in the wiki page LatexTemplate. This template is used when LaTeX commands are converted to images. \zag is used in the output generated by the following commands:

(1) -> continuedFraction(22/35)

(1)

continuedFraction(%pi)

(2)

continuedFraction(4 / %pi)

(3)

Bill:

Is it possible (and easy) to break the MathAction screen into two independent scroll areas during editing mode, one for editing and one for preview? That way, one can keep track of editing better. Currently, the preview screen scroll dominates; so the request is to limit the preview screen scroll just like the edit area scroll, in its own subwindow.

Also, right now, when a page is being edited, it is not locked, and there is a chance (it happens often enough) that someone else may beat one to the finish before a save. Is there an easy way to merge the two edits so the slow guy would not lose the edits? (Otherwise, the only way would be to save frequently, generating a lot of uninteresting reports.)

How about an alert if two people are editing the same page at the same time?

Thanks.

William

William Sit asked:

Is it possible (and easy) to break the MathAction screen into two independent scroll areas during editing mode, one for editing and one for preview?

Great suggestion! Yes it is possible and it wasn't too difficult. Please try the new edit/preview page format and let me know if this works better for you.

About competing edits: Merging simultaneous edits is quite hard. MathAction is based on ZWiki so it behaves as described here:

http://zwiki.org/GeneralDiscussion200311

"Zwiki prevents data loss due to simultaneous edits, throwing up a warning when the second person tries to save. It doesn't warn you earlier - can't, really. Normally when someone else is active on a page you'll see a very recent last edited timestamp, and you'll be forewarned. What it could do, and doesn't, is assist the second editor in merging their edits, instead of just telling them to go back and start again. I believe this situation happens rarely on most sites, though."

Improvements to this behaviour is still on the "wish list":

http://zwiki.org/661GiveMoreWarningOfSimultaneousEdits

In the preferences menu you can change the height of the edit window from the default of 20 lines of text to something smaller or larger. Click Save and then the size of the edit window will change the next time you click edit.

billpage wrote:

Please try the new edit/preview page format and let me know if this works better for you.

Excellent, thanks for the speed job. It works quite well and I can synchronize (manually) the editing and preview.

The preview area on my screen is about half the height of the editing area. Can that be made more even?

William

billpage wrote:

In the preferences menu you can change the height of the edit window from the default of 20 lines of text to something smaller or larger. Click Save and then the size of the edit window will change the next time you click edit.

You must be reading my mind. Now, will you be providing similar control for the preview window?

William

In the preferences menu look for the line:

  Editform width: 60 height: 20 Preview height: 20

You can now change the height of both the edit window and the preview window from the default of 20 lines of text to something smaller or larger. Click Save and then the size of the windows will change the next time you click Edit and Preview.

William Sit wrote:

I can synchronize (manually) the editing and preview.

Try clicking the box labelled Sync() below the edit scrollbar. When this box is checked Sync(x) the edit and preview windows are synchronized. On Internet Explorer the sychoronization is immediate. On FireFox (due to a bug in current version of FireFox) the sychnronization occurs only when you click the mouse in the text window.

Please let me know how this works for you. If there is a problem, please tell me what browser you are using.

billpage wrote:

Try clicking the box labelled 'Sync [ ]?' below the edit scrollbar. When this box is checked 'Sync [x]?' the edit and preview windows are synchronized.

Wow, this is working great! It will save a ton of time editing. Thanks.

In Internet Explorer and Firefox, if the Sync[] is checked when the windows are out of sync, they will sync with this offset after the Sync[x]?. (Not complaining, just an observation).

In the preference, would it be possible to use percent of vertical space instead of number of lines? That way, if the size of the browser window is changed, (maybe) the two windows will resize proportionally?

William

Here's the last thing on my MathAction wishlist for now ...

It is now possible to preview your comments before adding them to a page! Comment preview works the same way as when editing a whole page, but only the new text is displayed in the preview window. You must click Save to actually add the comment to the page.

Previewing is especially important for the MathAction wiki because typing correct and Axiom commands is often more difficult that when just writing plain text.

For some unknown reason, [my output] was [wrong] but now becomes the correct answer! (Actually, it turns back to [wrong] when I click the "reply", but for the page, it gave the correct answer [when]? redone!

When I edit the message of Mon, 11 Jul 2005 18:18:25 -0500, and preview, the answer changes to the correct one! When I cancel this change, the correct answer remains, but then if I "reply" to the message again ![it becomes wrong] again.

Reason: When I edit, the entire page is re-rendered and hence the answer is the correct answer (not 1), but when I reply, a new instance of Axiom is started, and hence the value of p is just a variable p.

I think Mathaction should be more consistent, or else we may be wasting a lot of time.

So Mathaction should give a warning that in using the reply box (instead of directly editing the page), a new session of Axiom is initiated.

William Sit wrote:

When I edit, the entire page is re-rendered and hence the answer is the correct answer (not 1), but when I reply, a new instance of Axiom is started.

That is essentially correct. It is a limitation of MathAction.

In fact, in both cases a new Axiom session is started when you click Save. Axiom starts, computes some output and then stops. The output is converted to a web page (rendered) and the resulting web page is saved. But the state of the calculation in Axiom is not saved.

As you say, the difference is that when you use edit and then Save, all of the commands on the whole page are executed by Axiom and the entire page is re-rendered. But when you simply use Add comment, only the commands contained in that comment are executed by Axiom, nothing else. The additional comment is rendered and then added to the bottom of the existing page.

Preview does the same except the result is not saved.

This means that the commands contained in the comment will not refer to any previously computed values on the same page until the whole page is re-calculated, either by a subsequent edit and Save or by clicking refresh (see right side above comment box).

Mathaction should give a warning

Maybe we should add something to the comment box such as:

Click refresh after Save if comments refer to previous results.

Or can you suggest another way to say this in a brief but clear manner?

Bill, thanks for confirming what MathAction does. Actually, I simply did not notice the "Click refresh to recalculate all" and now that I am aware of the difference between edit and add comment, that should be ok. Prior to your upgrading preview for comments, I seldom use add comments, to avoid broadcasting too many editing changes after save.

In order to present a consistent page, there should not be this difference. I think any time someone press "save" (or even "preview") using "add comments", the entire page should be recomputed. (I know this is less efficient, but it would avoid treating potentially unintentional wrong results as correct (since when a viewer reads the page, the same error remains until page is refreshed). And we did a lot of minor editing that would recompute anyway (even though very often, the axiom code was not changed).

It is possible for simple Axiom commands to cause an infinite loop and not terminate. E.g.:

  i:=1
  repeat
    i:=i+1

such loops can also happen in more complex cases due to programming errors.

The server can only tolerate a small number of such non-terminating Axiom processes. In order to prevent the server from freezing up, I have set a time limit of 1 minute of CPU time on all Axiom processes on the MathAction server. If a loop or other very long running Axiom command exceeds this limit, the process is subject to temination by the operating system.

Of course there are some Axiom calculations that are not infinite loops but which might take much longer than 1 minute to complete but I think 1 minute of CPU time on this server is a generous limit for must things that people would want to do with MathAction and should not cause anyone any problems.

Please let me know if you have any concerns with this new MathAction access policy.