Bookmark and Share

Notice: On March 31, it was announced that Statalist is moving from an email list to a forum. The old list will shut down on April 23, and its replacement, is already up and running.

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

st: RE: Re: RE: Disk caching (?), Win XP, Textpad, and Stata

From   "Martin Weiss" <>
To   <>
Subject   st: RE: Re: RE: Disk caching (?), Win XP, Textpad, and Stata
Date   Fri, 28 May 2010 22:09:58 +0200


To be honest, Mike, I do not get every twist in the description of your
approach, but, using the same setup as recommended by Kieran in an earlier
post <>, I have
_never_ experienced this problem. Ultraedit is cheap relative to its
capabilities, and it has always worked like a charm for me. 

I would hazard the guess that the problem is somewhere in the transfer from
your editor to Stata, and not within Stata, so this does not look like a
subject for tech support.


-----Original Message-----
[] On Behalf Of Mike Lacy
Sent: Freitag, 28. Mai 2010 18:50
Subject: st: Re: RE: Disk caching (?), Win XP, Textpad, and Stata

I had previously written:
 >I recently found out that I am experiencing occasions in which,
 >having saved a modified version of a program before rerunning it in
 >Stata, the new version does not get run, but instead version from
 >perhaps seconds ago is run, giving the same error repeated.  I write
 >and run Stata programs in Textpad, and go back and forth from Stata
 >to Textpad, modifying code, rerunning it, etc.

and Martin Weiss and Kieran McCaul had kindly responded to my 
relatively esoteric, platform-specific question.  Responding to some 
of the ideas they raised:

Yes, I am using -cap drop myprog- at the beginning of my programs. 
And, it occurs to me now that my exact mechanism of running my code 
could be relevant and could at least clarify some things. So, at the 
expense of some grimy if not grim details, here's some more description:

First, I am using the common trick of setting up a macro in the text 
editor to save the currently highlighted block of text to a file 
(named c:\temp\ in my case), and then using a profile 
assignment in Stata to map the F8 key to -do 
"c:\"-.  And, I do have a line in my do-file that 
reloads the program of interest, i.e., the one that appears not to be 
getting updated, prior to the program being run. My code is something 
like this:

// my Main do file
... a bunch of do file statements
... but no user-written program being
... defined or run. Then at some point, I have
do ""  // this contains the program "myprog" that is not 
apparently being updated properly
//  I now use myprog, which should be "the latest," but it's not.
myprog..... (various arguments....)

So, I am running this Main do-file, using the F8 mapping, and it 
loads and then runs what should be the latest version of -myprog-. 
When I am doing this, my Main do file is open in one window, and 
"" is open in another.  I make some changes in 
"," save it (File-Save in Win XP), then re-run my Main 
do file, and what is run is not updated, as confirmed by (e.g.) some 
corrected spelling mistake not being changed when the program runs in 
Stata.   In case it matters, "" contains a short Stata program
(-myprog-) that loads and uses a Mata program defined in 
"". However, I believe I have experienced this problem 
without having any Mata program involved.

What makes me think it is a file caching issue, rather than a more 
ordinary Stata issue, is that if I use File-Save As, and save to the 
same file name (""), the program file actually does get 
updated as it should. My thought is that either 1) Textpad or Win XP 
is only virtually saving "," or 2) Stata is somehow 
obtaining the wrong (e.g., 5 sec. older) version of ""

Hope that this clarifies my description a bit.  Thanks in advance for 
your thoughts.

Regards - Mike

Mike Lacy, Assoc. Prof.
Soc. Dept., Colo. State. Univ.
Fort Collins CO 80523 USA

*   For searches and help try:

*   For searches and help try:

© Copyright 1996–2016 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   Site index