Re: st: Stata 13 editor annoying behavior

[Sergiy Radyakin <serjradyakin@gmail.com>]

Jean-Luc,

I guess the way you are trying to use code editor is not exactly it
was intended to be used ('queue-ing' tasks). To summarize what's
written below, I don't see a solution to your problem, but hopefully
this explains what is going on.

The problem is that the 'stacking' behavior is really not documented
and rather unreliable. It can cause Stata to collide with itself in
competition for it's own resources (such as tempfiles), see here:

http://www.radyakin.org/statalist/statabugs/sharing_violation.png
(reproducible, click "do", then click "do" again without clearing the
"more" condition)

I have reported and demonstrated this issue to StataCorp twice, and
this moment was actually captured for the history here:
http://www.stata.com/meeting/new-orleans13/photos/i/NOLA13_42-big.jpg

Note that this behavior differs depending on whether anything is
selected in the editor. With the same code selected, pressing the "do"
button for the second time will ABORT the previous 'task', with the
consequence for the code above that you will not see the "done"
message. (You might have been lucky before, or simply didn't notice
the task was aborted). Stata's behavior is not very 'correct'. The
problem is that the previous command is logged with a zero error code,
as if it has succeeded, however it didn't execute completely. If one
had to audit the process and reproduce the same steps, but clearing
the more condition, or simply 'executing more slowly' so that the
previous task completes, they might get different results. Imho the
task that was aborted should be logged with at least some error code
into the commands history.

In principle however, I see no problem with implementing the behavior
you want. The problem might be in actually making the behavior
transparent to the user (remember the commands can be submitted to
Stata also from the console, and from other editor windows, which you
can open several at the same time). The immediate fix that I see
necessary is to make sure each code editor window gets a different
tempfile assigned to it, as currently they seem to be sharing the same
file, but anyways, it is up to StataCorp.

Best,
  Sergiy Radyakin




On Wed, Nov 6, 2013 at 9:34 AM, jean-luc morin-chesnel
<jeanluc.morinchesnel@gmail.com> wrote:
> Dear all
>
> I noticed a strange behavior with the new editor in Stata 13.
>
> Usually (with Stata 12) I used to select some code of my own, click to
> "execute selection" and before the computation ends I usually already
> selected and executed another piece of code. By doing so, I guess the
> tasks "stacked-up" in Stata's memory and I could see the final result
> at the end.
>
> Now this is not possible with Stata 13. If I select and execute some
> piece of code and I submit another piece of code BEFORE the first code
> ends, then stata aborts the first task... This is very annoying and I
> do not understand why it is the case..
>
> Could someone help me?
>
> Many thanks
> JL
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/statalist-faq/
> *   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/