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 + unix shell + AppleScript = Happy, productive geek


From   Sergiy Radyakin <serjradyakin@gmail.com>
To   "statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu>
Subject   Re: st: Stata + unix shell + AppleScript = Happy, productive geek
Date   Wed, 30 Oct 2013 16:20:12 -0400

On Wed, Oct 30, 2013 at 3:12 PM, Glenn Hoetker <Glenn.Hoetker@asu.edu> wrote:


"....Basically, it looks for lines that include "local" in them..."

Glenn,

1. note that locals can be defined (among other things):

- from Mata's st_local()
- from a similar plugin function SF_macro_save;
- using c_local   http://www.stata.com/statalist/archive/2003-12/msg00385.html;
- as a result of Stata's tokenize/syntax/args/other similar commands;
- as a result of indirect referencing, which would not be possible to
resolve at design-time;

My understanding is that your script will not catch any of those locals.

2. So you are saying that one program can 'peek' into the memory of
another in Apple? How secure is that?
Specifically it reminds me:
http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe
Wouldn't you need at least admin/debug rights to do that?

3. I would be quite interested in fact in the 'watch' window in Stata,
which would display the values of locals/globals at runtime. A
comprehensive solution would, imho, pull them out right from the
Stata's memory (locals a_test and b_test, each is 4 chars long+zero
terminator):

    addr  typ/usb  user     len  pos              name
---------------------------------------------------------------------------------------------------------------------------------------------
06504c28 5179/ -1     5       5    0              _b_test
06504ca8 5179/ -1     5       5    0              _a_test

Unfortunately, Stata does not expose this functionality in a way
convenient for consuming it programmatically neither through the
undocumented command above, nor through -macro dir-. The problem is
not of displaying the content - that is very well manageable given the
current functionality, but rather getting called after each line that
Stata executes to refresh the content.

Anyhow, don't stop at just locals. I see same utility in tracking the
use of globals, matrices, tempfiles, and file handles.

Best, Sergiy Radyakin



> One of the relatively under-appreciated gems of Stata, that I've only recently discovered, is its very complete AppleScript library.  It is much better than, say, the current support in Apple's iWorks programs.  Obviously, this only applies to those working on Macs.  Since the Mac OS is a Unix system, one also has access to the shell.  Better yet, .do and .ado files are just plain text.
>
> So, playing around, I put together a quick script using both AppleScript and the shell to solve a problem I had.  Particularly when writing .ado files, I tend to have LOTS of local macros and can't always remember exactly what they are called or how they are defined at the moment (yes, better coding practices would help alleviate that, but what's more fun)...
>
> The script below, which requires modification to work anywhere but on my machine, is meant to just give an example of what one can do with this combination of technologies in hopes that it might inspire others.  It provides a near real-time display of all the local macros defined in the .do/.ado file that was frontmost in Stata when the script was invoked.  Sample output would be
>
>         aicQuad = r(aic)
>         bLnState b`j'
>         bQuadState b`i'
>         bTvState b`i'
>         df_r = e(df_r)
>         display_options level(`level') `eform'
>         i 1
>
> Not beautiful, but a useful reminder that beats searching through a multi hundred line file.
>
> Anyway, here is the Applescript script, with the contents of the accompanying shell script included in the comments at the end.  I know it needs to be refactored (i.e., it looks monkey-written), but it's functional.
>
> ------------------------------------------------------------------------------------
> (*
>
> This script is offered as an example only and will require modification in order to run for anyone
> but it its author.  Its purpose is to display in near real time display a list of all the local macros
> defined in the .do/.ado file that was frontmost in Stata when the script was invoked.
>
> *)
>
> -- Be sure the .do/.ado file you wish extract locals from is the front window in Stata before invoking.
> -- No error checking if it isn't.
>
> tell application "StataMP"
>         activate
>         set theDoFile to file of front document as alias
>         set theDoFileName to the name of front document as text
>         tell application "Finder" to set thePwd to POSIX path of (the container of theDoFile as alias)
> end tell
>
>
> -- Before TextMate can open the file "locals.txt" it needs to exist.  But, I can't create it if it
> -- already exists.  So, first try to delete; then create; then open.  I use TextMate b/c it is usually
> -- open on my machine and, critically, it updates its display when the file is updated on the disk.  Any
> -- text editor would work, but some text editors do not update, which is less convenient for this purpose.
> -- No error checking, so if you already have a file called "locals.txt" in that directory, it will get clobbered.
>
> tell application "Finder"
>         try
>                 delete file "locals.txt" of folder (the container of theDoFile as alias)
>         end try
>         make new file at (the container of theDoFile as alias) with properties {name:"locals.txt"} with replacement
>         open file "locals.txt" of folder (container of theDoFile as alias) using ((path to applications folder as text) & "TextMate.app")
> end tell
>
> tell application "TextMate" to activate
>
>
> -- We don't want the shell process to run forever, so I used gtimeout, which can be installed via
> -- MacPorts.  There are many other ways one could manage this.   When I have time, I'll write a simple
> -- script to kill the process programmatically.  In the interim, I just let it run for 10 minutes at
> -- a time.
>
>
> do shell script "/sw/bin/gtimeout 10m sh ~/scripts/showStataLocals.sh " & quoted form of thePwd & " " & quoted form of theDoFileName & "&"
>
> display dialog "Done, but you can start again"  -- In Mavericks, one could put this in the notifications center instead.
>
> -- One could put a command here to delete the locals.txt file upon completion.
>
>
> (* Here is the text of the shell file showStataLocals.sh, invoked above.  Basically, it looks for lines that include
> "local" in them, strips leading text and "local", sorts the resulting macros, and saves it to a file called "locals.txt".
> It updates that file every 30 seconds to keep it current with your editing.
>
> Obviously, you'll need to  adjust the invocation based on where you store the shell script.  I could have simply make it one
> honking big "do shell script" line with semicolons, but I find that hard to debug.  Perhaps next time.
>
>
>
> #!/bin/sh
>
> cd "$1"
>
> while true
> do
>         grep local $2 |  sed 's/^.*local //' | sort > locals.txt
>         sleep 30
>
> done
>
> *)
>
>
>
>
> Glenn Hoetker
> Arizona State University | W. P. Carey School of Business
> Dean's Council Distinguished Scholar & Associate Professor
> Affiliate Professor   Sandra Day O'Conner College of Law
> Senior Sustainability Scholar   Global Institute of Sustainability
> Faculty Fellow   Center for Science, Law & Innovation
> Glenn.Hoetker@asu.edu  | http://hoetker.faculty.asu.edu | 480-965-4566
>
>
> *
> *   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