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

RE: st: further version questions


From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   RE: st: further version questions
Date   Wed, 29 Sep 2004 17:02:41 +0100

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 
[email protected] 

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of 
> Stas Kolenikov
> Sent: 29 September 2004 16:23
> To: [email protected]
> 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 
> <[email protected]> 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
> > [email protected]
> > 
> > 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/



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