Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can you obtain the location of the dofile currently being executed?

    Some context might be useful. One issue I often run into is that I want to edit a dofile while it is running. E.g. I code some stuff, run it, notice some things aren't as they should be and change it in the code. Unfortunately, I cannot save these changes until the current program is finished running or I press break. In most cases that's fine. However, sometimes this is very annoying, for example when manually parallelising the dofiles (e.g. the same dofile runs on different PCs, but using different data). Sometimes, I make changes that I think will improve it, but I am still interested in the results the old method will provide. If the old code causes Stata to hang, I will not be able to save these changes.

    Of course, there are manual solutions to all these issues. For example, I could make a small alteration (one extra whitespace for example) to each dofile without saving. This would cause Stata to run a temporary file instead, allowing me to edit the original without issue. But I have to admit, I often forget and sometimes it's also inconvenient (because if you're as forgetful as I am, you might not remember whether the dofile was altered because you made a significant change or because you wanted to have it run as a temporary file).

    One less manual solution I came up with is the following. Write a program that 1. reads in your entire dofile (the actual dofile would have to be saved I think, but perhaps this too can be avoided), 2. stores it as a tempfile, 3. executes the tempfile and 4.stops the current dofile.

    Each step is manageable. 1-2 can be performed using a tempfile <tempname> and copy <location> <tempname>. 3. Can be done by calling Stata from the command line, from Stata (e.g. tell Stata to tell the commandline to run Stata). This would either open a new Stata window or write the output to a log file which could then be opened. 4. Is simply exit.

    However, I have two substitutable unresolved issues. First, it would be much more convenient if you didn't need to specify the location of the dofile. Instead, I'm looking for a way to extract which dofile is currently executed. E.g. if you
    Code:
    do "<dofileFolder>/dofileName.do"
    I would love to extract "<dofileFolder>/dofileName.do" and use it to feed my copy command. In other words, is there a dofile equivalent to c(filename)?

    Second, the current technique requires the dofile to be saved. It would be much safer if it could also execute unsaved dofiles. I have literally no idea how to do that, though.

    Any ideas? I apologise if my description was a bit rambly, please do not hesitate the ask clarifying questions or better solutions than the one I propose.

    PS: Another issue is to avoid recursiveness, (the code to call a tempfile should not be executed when the tempfile is called) but I think this can be solved in many different ways (though it might not be easy).
    Last edited by Jesse Wursten; 22 Sep 2016, 09:44.

  • #2
    See http://www.statalist.org/forums/foru...-after-do-file for a Picardesque solution to the title question.

    Robert Picard

    Comment


    • #3
      Since this question comes over and over again, I just wonder is there any consensus of what should be returned as an answer in case of nested do files?
      Say if we had this magic function, what will be the result for a [meta] structure like this?

      Code:
      master.do {
        do task1.do
        do task2.do
        do task3.do
      }
      
      task1.do {
        do cmd1
        do cmd2
        do cmd3
      }
      
      cmd1.do {
        Stata.GetDoFileName()
      }




      Last edited by Sergiy Radyakin; 22 Sep 2016, 13:14. Reason: added missing extension

      Comment


      • #4
        In the case of project (from SSC), the answer is unambiguously the do-file that issued the call to obtain the name of the currently running do-file. If a do-file includes the following line of code:

        Code:
        project, doinfo
        project returns the following info:
        Code:
              r(pname)       the project name
              r(pdir)        the project's main directory
              r(bdate)       build start date
              r(btime)       build end date
              r(dofile)      do-file stub name (i.e. minus the ".do" extension)
        project maintains a LIFO stack to keep track of currently running do-files. When building a project, the master do-file is first pushed on the stack. If the master do-file calls a nested do-file, project suspends the logging of the master do-file, initiates logging of the nested do-file and pushes the new do-file on the stack. The process can repeat for as many nested do-file as is allowed in Stata. When a nested do-file terminates, its log is closed and it is popped out of the stack. The log file for the do-file on the top of the stack is then restarted.

        Comment

        Working...
        X