Edit detail for MathAction Problems revision 1 of 8

changed:
-
Some special Axiom-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:
\begin{axiom}
continuedFraction(22/35)
continuedFraction(%pi)
continuedFraction(4 / %pi)
\end{axiom}


From unknown Wed Jun 8 17:10:30 -0500 2005
From: unknown
Date: Wed, 08 Jun 2005 17:10:30 -0500
Subject: Sandbox optimization
Message-ID: <20050608171030-0500@page.axiom-developer.org>

Obviously, this page is not used to report problems?

Is there any way to break Sandbox into pages and still retain the no-email property? The sandbox now has lots of computation and each change seem to require all of these to be recomputed (is that right)? So separating these into pages (that is, allowing anyone to create a new Sandbox page) will allow a more organized and efficient display.

From billpage Wed Jun 8 19:01:13 -0500 2005
From: billpage
Date: Wed, 08 Jun 2005 19:01:13 -0500
Subject: You can report MathAction problems in IssueTracker
Message-ID: <20050608190113-0500@page.axiom-developer.org>

but I don't mind if you find this more convenient for comments
like this.

I thought your idea was a good one, so I have changed MathAction
so that all pages whose name starts with SandBox will be
*quiet pages*, i.e. editing and creating new such pages will
not generate email notices of any kind.

Let me know if this seems ok.

From wyscc Thu Jun 9 04:30:20 -0500 2005
From: wyscc
Date: Thu, 09 Jun 2005 04:30:20 -0500
Subject: Sandbox breaking up
Message-ID: <20050609043020-0500@page.axiom-developer.org>

Great, and thanks. So it's time to break up the Sandbox page into shorter pages. I tried to move Rubey's guessing sequence to a new Sandbox.GuessingSequence and it seems to work well. I did make a mistake by naming the page incorrectly without the Sandbox prefix. I also had to remove QuestionMark as subtopic.

For the brief time that the old Sandbox is breaking up, each change on that page still takes a fair amount of time, but as more and more are moved, it will be faster.

We can use this to set up pages where common or new packages can be tested like a tutorial -- much like the hyperdoc demos.

From wyscc Tue Jul 5 15:39:13 -0500 2005
From: wyscc
Date: Tue, 05 Jul 2005 15:39:13 -0500
Subject: Breaking up scrolling, competitive edits
Message-ID: <20050705153913-0500@page.axiom-developer.org>

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

From billpage Tue Jul 5 21:33:23 -0500 2005
From: billpage
Date: Tue, 05 Jul 2005 21:33:23 -0500
Subject: two independent scroll areas during editing mode
Message-ID: <20050705213323-0500@page.axiom-developer.org>

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


From billpage Tue Jul 5 21:41:15 -0500 2005
From: billpage
Date: Tue, 05 Jul 2005 21:41:15 -0500
Subject: controlling edit window height
Message-ID: <20050705214115-0500@page.axiom-developer.org>

In the "preferences":UserOptions 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'.

From WilliamSit Tue Jul 5 21:59:59 -0500 2005
From: William Sit
Date: Tue, 05 Jul 2005 21:59:59 -0500
Subject: [MathAction problems] two independent scrollareas during editing mode
Message-ID: <42CB4941.3D0FA9C@cunyvm.cuny.edu>

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


From WilliamSit Tue Jul 5 22:04:59 -0500 2005
From: William Sit
Date: Tue, 05 Jul 2005 22:04:59 -0500
Subject: [MathAction problems] controlling edit windowheight
Message-ID: <42CB4A68.D49A0001@cunyvm.cuny.edu>

billpage wrote:
> In the "preferences":UserOptions 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


From billpage Wed Jul 6 16:16:48 -0500 2005
From: billpage
Date: Wed, 06 Jul 2005 16:16:48 -0500
Subject: controlling preview window height
Message-ID: <20050706161648-0500@page.axiom-developer.org>

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'.


From billpage Wed Jul 6 19:17:12 -0500 2005
From: billpage
Date: Wed, 06 Jul 2005 19:17:12 -0500
Subject: edit and preview window synchronization
Message-ID: <20050706191712-0500@page.axiom-developer.org>

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.

From WilliamSit Wed Jul 6 22:25:36 -0500 2005
From: William Sit
Date: Wed, 06 Jul 2005 22:25:36 -0500
Subject: [MathAction problems] edit and preview windowsynchronization
Message-ID: <42CCA0BF.94290217@cunyvm.cuny.edu>

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


From billpage Thu Jul 7 00:31:57 -0500 2005
From: billpage
Date: Thu, 07 Jul 2005 00:31:57 -0500
Subject: preview of comments
Message-ID: <20050707003157-0500@page.axiom-developer.org>

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 $\text{\LaTeX}$ and Axiom commands is often more
difficult that when just writing plain text.

From wyscc Mon Jul 11 18:54:08 -0500 2005
From: wyscc
Date: Mon, 11 Jul 2005 18:54:08 -0500
Subject: Magic? I 'm confused!
Message-ID: <20050711185408-0500@page.axiom-developer.org>
In-Reply-To: <20050711181825-0500@page.axiom-developer.org>

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!

From wyscc Mon Jul 11 19:09:14 -0500 2005
From: wyscc
Date: Mon, 11 Jul 2005 19:09:14 -0500
Subject: Oh, my! MathAction playing tricks.
Message-ID: <20050711190914-0500@page.axiom-developer.org>
In-Reply-To: <20050711181825-0500@page.axiom-developer.org>

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.

From wyscc Mon Jul 11 19:39:36 -0500 2005
From: wyscc
Date: Mon, 11 Jul 2005 19:39:36 -0500
Subject: Conclusion
Message-ID: <20050711193936-0500@page.axiom-developer.org>

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.

From BillPage Mon Jul 11 21:24:05 -0500 2005
From: Bill Page
Date: Mon, 11 Jul 2005 21:24:05 -0500
Subject: MathAction playing tricks
Message-ID: <20050711212405-0500@page.axiom-developer.org>

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:

<em>Click _refresh_ after 'Save' if comments refer to
previous results.</em>

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

From wyscc Mon Jul 11 22:08:32 -0500 2005
From: wyscc
Date: Mon, 11 Jul 2005 22:08:32 -0500
Subject: Thanks
Message-ID: <20050711220832-0500@page.axiom-developer.org>
In-Reply-To: <20050711212405-0500@page.axiom-developer.org>

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).


From BillPage Sat Jul 16 17:08:22 -0500 2005
From: Bill Page
Date: Sat, 16 Jul 2005 17:08:22 -0500
Subject: Time limits for Axiom execution
Message-ID: <20050716170822-0500@page.axiom-developer.org>

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.

Some special Axiom-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:

axiom

continuedFraction(22/35)

(1)

Type: ContinuedFraction(Integer)

axiom

continuedFraction(%pi)

(2)

Type: ContinuedFraction(Integer)

axiom

continuedFraction(4 / %pi)

(3)

Type: ContinuedFraction(Integer)

Sandbox optimization --unknown, Wed, 08 Jun 2005 17:10:30 -0500 reply

Obviously, this page is not used to report problems?

Is there any way to break Sandbox into pages and still retain the no-email property? The sandbox now has lots of computation and each change seem to require all of these to be recomputed (is that right)? So separating these into pages (that is, allowing anyone to create a new Sandbox page) will allow a more organized and efficient display.

You can report MathAction? problems in IssueTracker? --billpage, Wed, 08 Jun 2005 19:01:13 -0500 reply

but I don't mind if you find this more convenient for comments like this.

I thought your idea was a good one, so I have changed MathAction? so that all pages whose name starts with SandBox? will be quiet pages, i.e. editing and creating new such pages will not generate email notices of any kind.

Let me know if this seems ok.

Sandbox breaking up --wyscc, Thu, 09 Jun 2005 04:30:20 -0500 reply

Great, and thanks. So it's time to break up the Sandbox page into shorter pages. I tried to move Rubey's guessing sequence to a new Sandbox.GuessingSequence? and it seems to work well. I did make a mistake by naming the page incorrectly without the Sandbox prefix. I also had to remove QuestionMark? as subtopic.

For the brief time that the old Sandbox is breaking up, each change on that page still takes a fair amount of time, but as more and more are moved, it will be faster.

We can use this to set up pages where common or new packages can be tested like a tutorial

much like the hyperdoc demos.

Breaking up scrolling, competitive edits --wyscc, Tue, 05 Jul 2005 15:39:13 -0500 reply

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

two independent scroll areas during editing mode --billpage, Tue, 05 Jul 2005 21:33:23 -0500 reply

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

controlling edit window height --billpage, Tue, 05 Jul 2005 21:41:15 -0500 reply

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.

[MathAction problems]? two independent scrollareas during editing mode --William Sit, Tue, 05 Jul 2005 21:59:59 -0500 reply

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

[MathAction problems]? controlling edit windowheight --William Sit, Tue, 05 Jul 2005 22:04:59 -0500 reply

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

controlling preview window height --billpage, Wed, 06 Jul 2005 16:16:48 -0500 reply

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.

edit and preview window synchronization --billpage, Wed, 06 Jul 2005 19:17:12 -0500 reply

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.

[MathAction problems]? edit and preview windowsynchronization --William Sit, Wed, 06 Jul 2005 22:25:36 -0500 reply

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

preview of comments --billpage, Thu, 07 Jul 2005 00:31:57 -0500 reply

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.

Magic? I 'm confused! --wyscc, Mon, 11 Jul 2005 18:54:08 -0500 reply

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!

Oh, my! MathAction? playing tricks. --wyscc, Mon, 11 Jul 2005 19:09:14 -0500 reply

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.

Conclusion --wyscc, Mon, 11 Jul 2005 19:39:36 -0500 reply

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.

MathAction? playing tricks --Bill Page, Mon, 11 Jul 2005 21:24:05 -0500 reply

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?

Thanks --wyscc, Mon, 11 Jul 2005 22:08:32 -0500 reply

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).

Time limits for Axiom execution --Bill Page, Sat, 16 Jul 2005 17:08:22 -0500 reply

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.