[daniel klein]

John Grove your #2 request is already taken care of. Just define the local macros in the command window instead of the do file editor.

Not really. Perhaps we have a different understanding of what John is asking for. A local defined via the command line will not be accessible within a do-file and vice versa. So my answer would be that this has already been taken care of: it is called global macro.

Best
Daniel

[Nick Cox]

Local macros that aren't: I am with daniel klein on this. I'd mention also include

If what is wanted is that local macro references make sense outside their scope or locale, then that would seem to make nonsense of the whole idea of local macro. Or, please explain precisely what your wishes are.

[Marc Kaulisch]

wbuchanan : It is the latter one. I only start getting used to this kind of data management (so please excuse errors in using the terminology) and like to communicate with a server over JSON using a REST API. The server accepts only connections over SSL - I tried -insheetjson- (SSC) and failed due to this missing feature. Why doing it over JSON and not directly over the database: Because we track each change done over the web and save the revisions. Otherwise these changes would not be trackable later (only with the syntax but then changes are documented in two places which is not good).

[Clyde Schechter]

wbuchanan Re #180, I don't think that's right. The local macros defined in the command window are only in scope for subsequent commands that are also given through the command window. If you define local macros in the command window and then try to refer to them when running a part of a do-file, they are out of scope.

The simplest way to use local macros in a do file without running the entire do-file is to comment out everything between the macro definitions and the part of the do-file you want to run. That method has been made even easier in the most current updates of Stata version 14.2 because you can now highlight a block of code in the do-file editor and then press Ctrl-/ to comment out the entire block. You can then later un-comment it by again selecting it and pressing Ctrl-/. (That's for Windows. There is an analogous keystroke shortcut in Mac and Unix. And it can be done in the do-file menus by selecting Edit->Advanced->Toggle comment.)

Added: Crossed with #181 through 183.

[wbuchanan]

Marc Kaulisch have you tried using jsonio? The examples I used when testing all came over https requests made to Google and I didn't have any issues with it. Maybe that would help the issue you're running into?

[wbuchanan]

daniel klein,

I think I may have read the initial post a bit differently. I agree with you and Nick Cox about the scoping issue. I wasn't aware of some of the new features that Clyde Schechter mentioned, but see how that could be a fairly reasonable solution.

[Marcos Almeida]

I'm thinking about a direct way to save high-quality (jpeg, tiff, png) graphs, such as selecting the graph to have 300 or 600 dpi.

[eric_a_booth]

Similar to Marcos's suggestion, I'd like to see the ability to natively export to scalable (.svg) format graphs.

[Marc Kaulisch]

wbuchanan : Not yet. I am reluctant to load the package from github. Do you plan to upload a newer version of jsonio to SSC?

[wbuchanan]

Marc Kaulisch hadn't realized I hadn't updated the SSC version in a while. In either case, I'd be curious to learn a bit more about your reluctance to install from SSC versus the location where the source code is located (feel free to message me directly about this if you'd like).

[eric_a_booth]

Marc Kaulisch hadn't realized I hadn't updated the SSC version in a while. In either case, I'd be curious to learn a bit more about your reluctance to install from SSC versus the location where the source code is located (feel free to message me directly about this if you'd like).

FWIW, I'm not reluctant to install things from Github or similar repositories for any software I use, but when it comes to Stata I do prefer to install packages from SSC because of the way it's integrated within the software. It makes updating the packages easy (especially when I share do-file code to coauthors who would find installing dependent .ado files from a non-SSC source daunting), and it helps me easily manage all the ado-file downloads & updates I need from one location when I have to, for example, migrate them over to a secure, non-internet-aware machine a few times a year. I've used other code repositories to store my working Stata ado code before but when I feel like it's ready to be widely used I push it to the SSC. I get that GitHub is where your (and a lot of) source code is located, but I suspect that because of the way SSC is used and introduced to Stata users, most of them think of the SSC as being the primary/central repository for Stata user-generated source code.

[Stephen Jenkins]

Eric (#188): it's already possible in the current version to produce .svg format graphs:

. graph export junk.svg
(file junk.svg written in SVG format)

Or have I misunderstood what you request?

[eric_a_booth]

Eric (#188): it's already possible in the current version to produce .svg format graphs:

. graph export junk.svg
(file junk.svg written in SVG format)

Or have I misunderstood what you request?

Stata is saving the file with a .svg extension but it's not a true scalable vector graphic, it's raster(bitmap) which has implications for quality of the image when scaling. I realize that the need for true svg graphics is probably not widespread, but I get requests from clients that need to distribute materials containing our Stata graphics in svg format (and they often point out that R can do this, ugh). I'm not sure how difficult this would be to add/implement and I certainly don't think it would be a high priority on Stata's list of new features to add, but I thought I'd put it out there just in case.

[Ronán Conroy]

I was rooting through my user-written commands today and, not for the first time, I wished that Stata had a manager similar to the package manager in RStudio. The smcl listing of user-installed ados is looking its age and offers little by way of searchability, organisation etc.

[Friedrich Huebler]

I was rooting through my user-written commands today and, not for the first time, I wished that Stata had a manager similar to the package manager in RStudio. The smcl listing of user-installed ados is looking its age and offers little by way of searchability, organisation etc.

Please consider mypkg.

ssc d mypkg