[Marc Kaulisch]

Marc Kaulisch
Which user-written JSON packages do you have difficulties with?

It is years ago and I was frustrated - as far as I remember I tried -insheetjson-, -jsonio- and -libjson-. If I remember correctly I was successful with -insheetjson- to do the part I needed, but I avoid JSON as much as possible. I know it is difficult to parse JSON but nonethless I - as user - would love to see some maybe automatic JSON-structure analysis and then an opportunity to transform it into a Stata-like data structure.

[wbuchanan]

Marc Kaulisch
I can appreciate that and it was what I tried to do with jsonio. There could potentially be other ways of abstracting things, but the structure of JSON doesn't make it the most easy/useful for transmitting rectangularized datasets.

[Jesse Wursten]

Jesse Wursten
As to your second question, if you have Stata 14 or later, you already have a Java instance available on your machine (it is bundled with Stata from that point forward since it is needed to support the Java API).

Ah, that's good to know! libjson seems to do what I need, looks like it can even submit structured API calls.

[Bruce Weaver]

-adoupdate- has an option to check only packages obtained from the SSC archive:

ssconly specifies that ado update check only packages obtained from the Statistical Software Components (SSC) archive at
        Boston College, which is provided at http://repec.org.  See [R] ssc for more information on the SSC.

If possible, it would be nice to have an option to exclude sites/sources that no longer work. E.g., when I execute -adoupdate- these days, every package from ats.ucla.edu causes a big slow-down, because UCLA has since reorganized its website (at least once), and the server is not responding.

   [20] fstar at http://www.ats.ucla.edu/stat/stata/ado/analysis:
        server not responding or package is no longer available

   [21] wtest at http://www.ats.ucla.edu/stat/stata/ado/analysis:
        server not responding or package is no longer available

   [22] simanova at http://www.ats.ucla.edu/stat/stata/ado/analysis:
        server not responding or package is no longer available

I would tell -adoupdate- to not bother checking UCLA packages if I could. ;-)

[William Lisowski]

Bruce Weaver #289 -
The three packages you cite are now downloadable as ZIP archives from

https://stats.oarc.ucla.edu/stata/ado/analysis/

and they are, as you have no doubt realized, no longer findable via search nor installable via net install. I see two alternatives to work around your problem.

The official approach would be to download the ZIP archives and put the contents into your PERSONAL directory, then ado uninstall the copies in your PLUS directory. These packages are unlikely to be updated by UCLA, so you might as well have them in your PERSONAL directory.

The hack approach would be to edit PLUS/stata.trk and delete the entries for these three packages. The packages will still be loaded by Stata from your PLUS directory, but not reported on by the ado commands. Or rather than delete the entries, perhaps you could experiment with changing the URL on the S record to one that exists but isn't a Stata download site so that ado update would promptly report something like the following.

. net get foo, from(https://google.com/)
file https://google.com/stata.toc not found
https://google.com/ either
  1)  is not a valid URL, or
  2)  could not be contacted, or
  3)  is not a Stata download site (has no stata.toc file).
r(601);

All the usual caveats and warnings about brain surgery for amateurs apply to this advice, it is not advice I would choose to follow should I have the need.

[Bruce Weaver]

Hi William Lisowski. I did contemplate doing something like you suggest in #290. But another possibility occurred to me: I contacted OARC at UCLA to suggest that they upload the packages to SSC. The person I corresponded with thought it was a good solution, but said that Phil Ender (who wrote most of the packages) would have to okay it first. (One might have to uninstall the current versions first and then reinstall them, but that would not be that big a deal.) I'll keep you posted.

Cheers,
Bruce

[Richard Williams]

Bruce Weaver said "If possible, it would be nice to have an option to exclude sites/sources that no longer work. E.g., when I execute -adoupdate- these days, every package from ats.ucla.edu causes a big slow-down, because UCLA has since reorganized its website (at least once), and the server is not responding."

As luck would have it, I wrote UCLA Stats people about that the other day because I could no longer find Phil Ender's -collin-. They said UCLA keeps on making them reorganize their web pages, which is sort of a pain. If you want packages from UCLA, from within Stata you should type

net from https://stats.oarc.ucla.edu/stat/stata/ado/analysis

and you can then click on whatever package you want.

The UCLA people also that some packages may be sent off to SSC where they will have a more stable home.

EDIT: You might want to uninstall your current UCLA packages and reinstall from the new location. That should buy you some time, at least until UCLA reorganizes again. Or, just wait a while, and see if there is a mass exodus of UCLA programs over to SSC.

[Alan Riley (StataCorp)]

-adoupdate- has an option to check only packages obtained from the SSC archive:

ssconly specifies that ado update check only packages obtained from the Statistical Software Components (SSC) archive at
Boston College, which is provided at http://repec.org. See [R] ssc for more information on the SSC.

If possible, it would be nice to have an option to exclude sites/sources that no longer work. E.g., when I execute -adoupdate- these days, every package from ats.ucla.edu causes a big slow-down, because UCLA has since reorganized its website (at least once), and the server is not responding.

 [20] fstar at http://www.ats.ucla.edu/stat/stata/ado/analysis:
server not responding or package is no longer available

[21] wtest at http://www.ats.ucla.edu/stat/stata/ado/analysis:
server not responding or package is no longer available

[22] simanova at http://www.ats.ucla.edu/stat/stata/ado/analysis:
server not responding or package is no longer available

I would tell -adoupdate- to not bother checking UCLA packages if I could. ;-)

Here is a potential fix, but please make sure you backup your stata.trk file first so you can put it back in place if anything goes wrong!

In Stata, type sysdir. This should show you where your PLUS directory is. In that directory you will find a file named stata.trk. Make a copy of it someplace safe.

Now, in Stata, cd to the PLUS directory where stata.trk is. Then type

filefilter stata.trk newstata.trk, from("http://www.ats.ucla.edu") to("https://stats.oarc.ucla.edu")

The .trk file is just a text file. If you look at newstata.trk in a text editor, you should see that all the UCLA URLs have been updated to their new site. Assuming you are happy with the change, you can now get rid of stata.trk (remember you were supposed to make a backup of it up above) and rename newstata.trk to stata.trk. adoupdate should then be happy assuming the rest of the directory structure on the UCLA site is the same and the Stata packages are still there.

[Bruce Weaver]

Thanks Richard Williams and Alan Riley (StataCorp). In my exchange with the UCLA folks, I got the impression that they would like to move things to SSC so that they don't have to deal with these problems next time they are directed to reorganize their website. So I'm optimistic that will happen. But I do like Alan's solution in the meantime. ;-)

[Bruce Weaver]

I suggest that the vsquish option for -margins- be made the default setting, as I cannot immediately think of situations in which I would prefer to have "the blank space[s] separating factor-variable terms or time-series–operated variables". YMMV.

[Clyde Schechter]

Well, FWIW, I find the -vsquish- format ugly, at best, and when there are a large number of factor variables, unreadable altogether. So, I suppose it's a matter of taste. Well, as the Russians say, one should not argue over tastes. So maybe the way to do this is for Stata to give us -set vsquish {off | on }, [permanently]- and make everybody happy.

[Bruce Weaver]

So maybe the way to do this is for Stata to give us -set vsquish {off | on }, [permanently]- and make everybody happy.

Excellent suggestion, Clyde.

[daniel klein]

I do not think that Stata (and/or Mata) offer any tools for measuring code coverage, right? I would like to see that. Given that Stata is not primarily a programming language (Mata might well be different), I realize that this is a somewhat esoteric item on the wishlist.

[wbuchanan]

daniel klein
James Fielder and someone else worked on a unit test framework for Mata that has been on GitHub for a bit. It doesn’t measure code coverage specifically, but I don’t imagine it would be too difficult to extend their work to test how many functions/methods have unit tests defined for them.

That said, along the lines of your suggestion it would definitely be interesting to get some integrations set up with CI tools for those using VCS to incorporate more unit and regression testing into the development process.

[John Mullahy]

There's a current Statalist thread that concerns the possibility of expanding existing SMCL markup directives for Stata graphs. This idea may merit consideration for v18.

https://www.statalist.org/forums/for...77#post1649277