Bhaskar A wonderful explanation, congratulation!
Excuse me that I misspelled your name. Wolfgang Giere "K.S. Bhaskar" wrote: > Fil is correct. The GT.M ability to configure development environments > is exceptionally flexible. Read and digest the following when you have > a few minutes to absorb the examples. > > A GT.M process searches for its routines using the $ZROutines intrinsic > special variable, not unlike the Java CLASSPATH or UNIX shell $PATH > environment variables. Thus, if Fil and I are developers and Fil wants > to work on some Lab modules, he can create a /home/fil/lab subdirectory > for his work and if I am working on Oncology, I can create a > /home/bhaskar/onc subdirectory for my work. If the reference (or > production) routines are in the directory /opt/vista_23.98/o for the > object files and /opt/vista_23.98/r for the source files, Fil can set > his $ZROU to "/home/fil/lab /opt/vista_23.98/o". All he needs to do is > copy that set of routines that he wants to work on from > /opt/vista_23.98/r to /home/fil/lab and change them. He doesn't need to > copy all 20,000+ routines from /opt/vista_23.98/r to /home/fil/lab. > Furthermore, by configuring /opt/vista_23.98/o and /opt/vista_23.98/r so > that Fil does not have write access (e.g., making them world read-only > or setting up ownership and permissions so that he does not have > access), we can ensure that Fil cannot inadvertently or deliberately > change anything in the reference / production environment. > > Now consider when Fil and I are done with our work. Since he and I have > been working in parallel, we will want to test our work for mutual > (in)compatibility. I can set my $ZROU to "/home/bhaskar/onc > /home/fil/lab /opt/vista_23.98/o" and Fil can set his $ZROU to > "/home/fil/lab /home/bhaskar/onc /opt/vista_23.98/o". This allows us to > use each other's routines in our own unit test environments to see > whether we have stepped on each other's toes. > > This also simplifies version control, because it means that when I am > ready to check in my work, the only files we need to look at are in > /home/bhaskar/lab, since I could not have changed something else, even > inadvertently. > > We can take this example further. Suppose that Fil and I are doing our > work with a new GT.M version and part of what we are doing is to enhance > the application software to take advantage of a new feature in the new > release, say a $Increment() function. He and I can set up a shared > directory, say /var/newstuff to which we both have read/write access. I > can set up $ZROU to be "/home/bhaskar/onc > /var/newstuff(/opt/vista_23.98/r)" and Fil can set up his $ZROU to > "/home/fil/lab /var/newstuff(/opt/vista_23.98/r)". Now, whenever he or > I reference a routine from the reference / production environment, the > new GT.M version will dynamically compile and place the object file in > /var/newstuff, but the source routines in /opt/vista_23.98/r are > unchanged. > > There are similar things we can do with M globals using a global > directory pointed to by $ZGBLdir. For example, if the data dictionary > is defined in ^DIC, Fil and I can create global directories that place > ^DIC in the production / reference database. If I have read-only access > to that database file, I cannot possibly change it during the course of > my development, not even inadvertently, and we are assured that my > software is compatible with the production data dictionary. Taking this > one step further, if we know that my oncology work is only supposed to > affect globals ^ABC and ^DEF, we can set up a global directory and > database files that allow me read/write access only to those two > globals, and read-only access to everything else. [Note, a limitation > in GT.M today is that this slicing and dicing of globals can be done at > the level of the global variable, and not at the level of the index.] > > Quite apart from the flexibility this offers, I like to think of these > types of practices as "defensive programming", not unlike defensive > driving. We programmers are human beings who are prone to err, and > defensive programming reduces the probability of errors. > > Sorry to have rambled. I meant this to be a short e-mail, but my > fingers ran away from my intentions. > > -- Bhaskar > > On Mon, 2004-12-06 at 14:02, Beza, Fil wrote: > > Based on Dr. Giere's description, GT.M has the ability to share selected > > routines between environments and have each environment have it's own > > set of globals which is the way to go. Actually, that's just perfect > > for a vendor to provide ASP services - One set of Vista routines and > > each client gets their own set of files - sweet - you can have your cake > > and eat it too! > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Tyrus > > Maynard > > Sent: Monday, December 06, 2004 8:54 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [Hardhats-members] FileMan for GT.M > > > > Wolfgang, > > I will also go back to your earlier posting on DINIT I mentioned you > > in the "extraction" camp only because you started with a full > > installation (yes, selective use is not the same as isolating your > > learning space from other available routines using an extraction) . > > JLZ has similarly advocated expedient selective use ( as I quote from > > another thread) " If diamond is not available, I would install openvista > > semiviva 0.4 and ignore most of that, keep to a name/numberspace, and > > draw upon the rest when it suits the task." > > When I get back to my Vista machine perhaps I should join your camp, > > although my goal is not personal use based on experience, it will be > > just for learning. > > For that primordial purpose I am a little distrustful of having too > > many addon routines standing by...but I don't know what should be > > considered the ideal Fileman Lite or Fileman+ ... not to mention the > > strategy for isolating it on GTM. > > When I learned to swim they just threw me in (that was the supervised > > method of the day). In returning to this threadname, I am just asking > > for which is the shallow end of the pool and with rescuers available, > > it may not matter which end you start in. > > Thanks for clarification > > > > Rusty > > > > > If you have installed Vista you can just leave it alone and reinstall > > > all the files needed using the FileMan installation routine DINIT (Do > > > ^DINIT). > > > You will > > > have to answer some questions but the resualt is a running and > > > complete FileMan. > > > It uses the routines in your vista distribution. It is not necessary > > > to figure out which ones (of course all DI* routines, but a few > > > others, too). I did no extraction at all, only an addition: A new > > > FileMan for my "private" use. > > > > > > Wolfgang Giere > > > > > > > > > > > > T Maynard wrote: > > > > > >> > > >> > > >> The extraction camp: > > >> This includes setting up a new gtmglbldir from latest VistA as > > >> done by Wolfgang Giere ...but that camp does not convey what the > > >> essential extraction files would be to the likes of me. > > *************************************************************************** > This electronic mail transmission contains confidential and/or privileged > information intended only for the person(s) named. > Any use, distribution, copying or disclosure by another person is strictly > prohibited. > *************************************************************************** > > NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus et peut contenir de l'information privilegiee, > confidentielle et/ou dispensee de divulgation aux termes des lois > applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas > destine, veuillez le mentionner immediatement a l'expediteur et effacer ce > courriel. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
