Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: Which and return list

Subject   RE: st: Which and return list
Date   Fri, 19 Mar 2004 14:31:51 +0000

I guess the flaw with the upstream solution is that this
requires the users of your programs to be as efficient as you

I get many emails like  "why can't your program do this?" and
generally the solution is have you done this command  -ssc install

This is ok for new features of old commands (that are already implemented)
but when you create a new command that
requires a newer version of an old command should I automatically force
every user to update the commands I want updated? This would be the easiest
way for me and would
be an upstream solution but I doubt the person sitting on a slow phone line
will thank me.


Adrian Mander MSc PhD, Principal Statistician, GlaxoSmithKline, Mail Code
HW8133, New Frontiers Science Park (South), Harlow, Essex, CM19 5AW. Tel:
01279 63 1203 Fax: 01279 64 4003

                      "Nick Cox"                                                                                                               
                      Sent by:                         To:                                                 
                                                       Subject: RE: st: Which and return list                                                  
                      19-Mar-2004 13:05                                                                                                        
                      Please respond to                                                                                                        

I sometimes want to distinguish between upstream
and downstream solutions to problems. That is,
_where_ do you catch the problem and tackle it? This is
usually a metaphor of mine, but one which stems
from a professional situation in geography and
a personal situation in which I live right by
what counts as one of Britain's major rivers and
ponder its changing state as I walk to and from
work each day.

Fred here is pondering downstream solutions to
problems. I want to suggest upstream solutions.

Frankly, I think the first problem is
a messy problem. For example, it's not even true that
an ado can be identified by picking up
the first keyword in each line of a do-file (think
prefixes like -quietly-, think continuation lines).
Then what is to be done about -do- files that call
other -do- files or programs, and so on?

Isn't the upstream solution just to think more
about how your collaborators use your programs?
Why not insist that the price of collaboration is
that their installs your latest programs,
bundled as packages, each time they start up their
Stata? (This does depend on your keeping your archive
up-to-date, but it doesn't depend on their remembering
anything, which sounds like the weaker link.)

The second problem prompts me to similar comments.
When I wanted to start keeping tracking of various
programs I had written, it took me an absurdly
long time to realise that the best solution was just
a Stata data file. Once the file was set up, the maintenance
is trivial, and I needed no special tools
for anything, just Stata's built-in commands.


> -----Original Message-----
> From:
> []On Behalf Of Fred Wolfe
> Sent: 19 March 2004 12:00
> To:
> Subject: Re: st: Which and return list
> Yes, there is a need for a program like this.
> I have the situation in which research fellows use programs
> that I and
> others have developed. There is a archive, web accessibe, in
> which we place
> new ado files. However, fellows often do not take advantage
> of the archive
> or occasionally we forget to post changes to the archive.
> What then follows
> is that not everyone has an updated set of ado files. The
> question for us
> is whether two are more users have the same set of ado files.
> The program that I would like to see is allied to Ade's
> request. I would
> like to see a program that scanned a DO file for ado files and then
> reported back in a sorted list the version of the ado files.
> There might be
> statements to allow or prevent searching some files such as
> Stata Corp
> files or STBPlus files. This would be a helpful utility.
> A second program that would be helpful is one that would
> search for ado
> files by a keyword. Keyword searches work fine for StataCorp
> and STB files,
> but not for ordinary ado files that one may have written and
> placed in the
> ado/personal directory. What I have been doing is to place a
> line in the
> ado file like this:
> *! keyword: some keywords
> and then use the search program -dtsearch- to search for
> "keyword" and the
> actual keywords within 25 characters.
> The reason I need to search is that I often forget the names
> of programs
> not often used.
> Fred
> At 04:14 AM 3/19/2004, you wrote:
> >Has anyone ever wanted to program an ado file that inspected
> the version of
> >another program.
> >If only  the -which- command inspected the  *! lines and
> stripped out the
> >version number.
> >
> >Perhaps there should be a set of standard *! lines at the start of an
> >adofile to help with this.
> >
> >e.g.
> >*! Version : 1.42
> >Then -which- could give the version number in the return list.
> >
> >Any thoughts anyone?
> >
> >cheers
> >Ade
> >
> >Adrian Mander MSc PhD, Principal Statistician,
> GlaxoSmithKline, Mail Code
> >HW8133, New Frontiers Science Park (South), Harlow, Essex,
> CM19 5AW. Tel:
> >01279 63 1203 Fax: 01279 64 4003
> >
> >
> >
> >*
> >*   For searches and help try:
> >*
> >*
> >*
> Fred Wolfe
> National Data Bank for Rheumatic Diseases
> Wichita, Kansas
> Tel (316) 263-2125     Fax (316) 263-0761
> *
> *   For searches and help try:
> *
> *
> *

*   For searches and help try:

*   For searches and help try:

© Copyright 1996–2017 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index