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

Re: st: further version questions


From   Stas Kolenikov <skolenik@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: further version questions
Date   Wed, 29 Sep 2004 20:52:19 -0400

I totally agree that this is a working solution, that I don't debate.
I just don't like it that much.

On the second thought, if you staring caring about the program
versions, the data base of what program depends on what version of
another program will quickly be getting quite huge. So it is better be
left to the programmers who really have crucial dependencies between
elements of a program. So mine is an overshoot, and yours is more
relevant indeed.

Stas

On Wed, 29 Sep 2004 17:02:41 +0100, Nick Cox <n.j.cox@durham.ac.uk> wrote:
> I am sorry that you find this inelegant. It was offered
> as a practical solution, not as an exemplar of elegance.
> 
> For my part, I can't support your urging StataCorp to
> introduce new commands which aren't needed. There
> are many things more needed and more desired.
> 
> Nick
> n.j.cox@durham.ac.uk
> 
> 
> 
> > -----Original Message-----
> > From: owner-statalist@hsphsun2.harvard.edu
> > [mailto:owner-statalist@hsphsun2.harvard.edu]On Behalf Of
> > Stas Kolenikov
> > Sent: 29 September 2004 16:23
> > To: statalist@hsphsun2.harvard.edu
> > Subject: Re: st: further version questions
> >
> >
> > Well certainly so, but you'd agree this is not a very elegant
> > solution. It's like saying, "Why would one need return values r() or
> > e() or s() if you can just return the results in $S_1, $S_2, etc.?"
> >
> > Stas
> >
> > On Wed, 29 Sep 2004 13:54:13 +0100, Nick Cox
> > <n.j.cox@durham.ac.uk> wrote:
> > > I am not clear that this need depend on StataCorp
> > > introducing new commands.
> > >
> > > Any user-programmer could set up a system like
> > > this using globals and locals.
> > >
> > > In one main program a programmer could set
> > >
> > > global frog_version 42
> > >
> > > and in called programs could set
> > >
> > > local frog_version 42
> > > if `frog_version' != $frog_version {
> > >         di as err "frog: using a mix of old and new versions"
> > >         exit 498
> > > }
> > >
> > > and so on.
> > >
> > > Nick
> > > n.j.cox@durham.ac.uk
> > >
> > > Stas Kolenikov
> > >
> > >
> > >
> > > > > But that would gain you nothing, really. -mvis- is just part
> > > > > of a package and the whole package would need
> > > > > to be scanned in a bid to remove Stata 8 features,
> > > > > which would I guess require considerable programming
> > > > > expertise.
> > > >
> > > > Can I pick from here on my own thing? Each time I update Sophia
> > > > Rabe-Heskteh's -gllamm-, some of the modules come out to
> > be outdated,
> > > > which I only find out when it crashes. (I know -net
> > install- should
> > > > work perfectly, but I found once that one of the older pieces was
> > > > sitting in a directory of -adopath- prior to others, and
> > thus caused
> > > > problems until I deleted it from there). So for all five or six
> > > > ado-files I have to type -which gllamm-, -which
> > gllapred-, etc., and
> > > > compare to the current versions on -gllamm- website.
> > > >
> > > > So my suggestion/wish/grumble to Stata Corp. is to set up
> > something
> > > > like -userversion- version control system, so that the internal
> > > > version of the module is specified not through
> > > >
> > > > *! v.3.1 NJC 29 September 2004
> > > >
> > > > in the first line of the ado-file, but as a
> > > >
> > > > *! NJC 29 September 2004
> > > > program define blahblah, eclass
> > > >    version 8.2
> > > >    userversion 3.1
> > > >    userneed blahblah_ll 1.11
> > > >    ...
> > > > end
> > > >
> > > > Then whenever -blahblah- calls -blahblah_ll-, the
> > -userversion- of the
> > > > latter is checked against 1.11 and should be no less than
> > that. Or an
> > > > option like
> > > >
> > > >    userneed blahblah_ll 1.11, strict
> > > >
> > > > can be provided for the lazy programmers like me who do
> > not want to
> > > > program their routines to be backward compatible, so that
> > the current
> > > > version of -blahblah- will only accept -userversion 1.11- to work
> > > > with.
> > > >
> > > > Is this too much to ask for? Does anybody else in the
> > stataworld need
> > > > this except me?
> 
> *
> *   For searches and help try:
> *   http://www.stata.com/support/faqs/res/findit.html
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
> 



-- 
Stas Kolenikov
http://stas.kolenikov.name
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



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