Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Stata 13 editor annoying behavior


From   jean-luc morin-chesnel <[email protected]>
To   [email protected]
Subject   Re: st: Stata 13 editor annoying behavior
Date   Wed, 6 Nov 2013 17:58:34 +0100

Thanks Sergiy for this very complete answer, and for the definitive
(visual) evidence that you submitted this behavior to statacorp ;-)
I noticed this behavior too:


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



Agreed:


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



Thanks again

On 6 November 2013 17:24, Sergiy Radyakin <[email protected]> wrote:
> 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
> <[email protected]> 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/
*
*   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/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index