The only two changes to Kernel's DD are a new code (E for EHR) in the set of codes in the AGENCY CODE field .02 in the AGENCY file 4.11 and the same code added to the AGENCY CODE field 9 in the KERNEL SYSTEM PARAMETERS file 8989.3. And hashing algorithms are replaced for the stub routines XUSHSH and XUSHSHP that are redacted in the FOIA version of the routines. Of course, there is a fair amount of "localization" and initial setup that must always be done. VOE has improved on those steps just a bit.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Monger Sent: Tuesday, August 23, 2005 9:01 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Re: MUMPS v2? (and its implications for VistA) Not sure that a MUMPS V2 is viable, but I think much could be implemented by Kernel to enhance the functionality. To what extent will Kernel differ between World VistA distributions and FOIA VistA? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Tuesday, August 23, 2005 12:57 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Re: MUMPS v2? (and its implications for VistA) As an outsider, I would say that not breaking old code means that the new M system can load up and run vistA code without having to wrap it etc. No one seems to like change (just look to our discussion of "F" vs. "FOR" vs "for" etc.) So creating a new language by committee might be the kiss of death. Sometimes there just needs to be a smart leader that puts something out there, and then see if it catches on. It seems like there is such a leader behind perl or phython. I read an interview with him once on slashdot, but his name escapes me. Kevin On 8/23/05, Greg Woodhouse <[EMAIL PROTECTED]> wrote: > Unlike Jim Self, I've never had occasion to review the source code of > GT.M but I do not doubt that it is very well written. Compiling a > dynamic language like MUMPS does, of course, does pose special > challenges due to its dynamic nature. If I can invoke a routine > indirectly (by name) at run-time what are my options? Two obvious > alternatives that suggest themselves are compiling to an intermediate > representation (like Parrot from the Perl 6 project) or to rely on some > combination of thunking and just in time compilation. Nevertheless, it > should be possible to compile and run existing code. XECUTE statements, > of course, are used to executed MUMPS source that is specified at > run-time and so isn't really amenable to the same shortcuts as > indirection. > > That being said, it is not obvious to me that there is any technical > reason that existing compiled code could not be linked with VistA > components written in a newer version of the language, and hence the > requirement to not break existing code does not imply that the language > has to be frozen in time. Thus, it seems to me that the backward > compatibility argument is really a red herring, and the truth is that > there is little interest in developing a new version of the language. > That's fine, of course, but *I* am not particularly interested in > porting MUMPS to new platforms if there is little interest in updating > the language. > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > "Design quality doesn't ensure success, but design failure can ensure > failure." > > --Kent Beck > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
