I still suspect that the problem you are having is not a stack limit issue. Instead it looks to me that you have found a bug in Maple or GOT, which I would suggest you report to support. If it is a bug, adjusting the stack limit will not help you solve the problem.
In case it is a stack limit problem, you can disable the stacklimit check by setting stacklimit=infinity. If you do this Maple will not be able to catch stacklimit problems and the kernel will simply crash when it runs out of stack space.
So, if I understand correctly there is an "afordable limit" say, determined the amount of RAM and the size of the swap partition, I guess.
It is also determined by the risk of something going wrong. On a single user machine like yours I think the risk is relatively low. I would not change the system limits. In Maple, I'd used the default unless I had some code that would not complete. The "too many levels of recursion" message is how Maple usually reports stack limit problems. The error you received is also a possibility, although that message can also mean something else went wrong.
I can't help you too much with the GOT problem as I am not very familar with it. It looks like you may have found a bug, rather than an acutal problem with stack limits.
However, I can explain how stack limits should work.
First, Windows and Unix are different. On windows the maximum stack limit is a fixed constant. This constant is the value you identified as max in your chart. We increased this constant in Maple 10, which is why the value you found is much larger than for previous versions. You can lower the stack limit in Maple.
On unix, the hard stack limit is set as part of the system configuration. Many shared unix boxes will set limits to keep one user from using all the system resources. However on many desktop linux boxes these limits are not set. It appears your linux machine does not have a hard stack limit set (or it is set to "infinity"). However you may still have a soft stack limit. A soft limit still limits the amount of stack space a process can use, but it can be adjusted by the user (up to the hard limit). When you set the stacklimit in Maple you are adjusting the soft limit.
On linux you can read the "ulimit" section of the bash/sh man page or the "limit" section of the tcsh/csh man page for more information on resource limits.
These limits are independent of the amount of RAM on the system. They can be set to whatever you like. However if they are set too large, a poorly written or malicious program could consume all the resources of the system and effectively halt the machine. The stack limits you describe are in kibibytes so a limit of 2937000 is almost 3 Gigs of memory.
As for the error messages, (1) is basically an improved version of (4). (2) and (3) are bugs. Those cases should be printing (1).
One generally does not need a large stack limit. Unless you are running very recusive functions, the default limits are usually fine.
I'd suggest taking a look at the tips section on www.vim.org
. I've found the orginazation of their tips sections works really nicely. In particular, any user can post tips and other users get to rate the tips. One can then search the tips based on the rating. Also, users can make comments to tips, adding their own similar ideas.
A similar system could be used for feature requests. I think users are much more likely to vote for a feature than post a "me to" comment. It would help us determine how important features are to a larger group than just those willing to post comments.
seems to be working again)