Re: [Hardhats] What tools do you use to read and write MUMPS?

[Tommy Martin]

I write standard M code daily and use Intersystems Cache on Windows 7.  It has a full-screen editor that operates much like Windows applications, i.e. cut/paste, drop/drag, "change every" or "change in selection" and more. The only things I have open are the editor and one terminal emulator screen which I use for debugging.

What you describe is not uncommon, i.e. setting variables which are used later.  Truthfully I would not waste time trying to figure out what a particular variable does unless there is a reason to do so.  Many M variable are created on the fly and many are NEWed which makes them disappear when the proper quit statement is encountered.  Some M routines list the important variables and requirements as comments but not all.

An important rule of mine is that all important variables will have a proper name (I namespace routines), like record number would be something of the order of AARECNUM and scratch variables would be like A,B,C, D, etc. Variables that might step on the VA File Manager (X, Y, G, etc) are always NEWed and those like % and derivatives are never used because they generally indicate system variables.

Hope this helps you a bit.

Tommy

On Sun, Feb 24, 2013 at 7:09 PM, Tyler Kiley <tyler...@gmail.com> wrote:

I'm a newcomer to MUMPS, and I've spent the last couple of weeks learning the syntax and idioms. One thing I have noticed is that the language is quite terse and occasionally ambiguous; it can be quite time-consuming to analyze existing code paths. As an example, I often see code in which a variable is set but never used within a single .m file; I'm guessing this variable is used by a subroutine at some point, but it takes a considerable amount of time to figure out which subroutine uses the variable. Right now, I find myself wrestling through these issues with liberal use of `grep`, but I'm wondering if there is a better way.

For those of you who write code for VistA on a regular basis, what does your development setup look like? What tools do you usually have open on-screen when you are writing or reading chunks of VistA code?

Cheers,

Tyler

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kevin Toppenberg]

What system are your working on?  I use GT.M, and have developed a debugger in the TMG library (search the archives).  It has an ability to convert the short form of commands (e.g. N) into their long form (e.g. NEW).  It does some colorization also that can help.

If you use VI on linux, there is a colorization plugin that you can get that helps there to.

Look at the date that the code was written.  Older code was VERY dense and very difficult to "decompile".  Best to consider it a binary blob of sorts.  For processing issues, each line was the equivalent of a paragraph in newer coding style.  Newer code tends to follow the pattern of one action on one line.

I agree with not bothering to track down all the uses of a variable.  Older code also tends to use the same variable name for multiple purposes, leading to further confustion.

Kevin

[Marty Mendelson]

Tyler,
  I do not write MUMPS code daily, nor am I an expert coder, so I find it quite helpful to have the utilities in Caché - the Word-like full screen editor and the contemporaneous terminal session. That way I can write and edit code, save it and then switch to the terminal and try to run it. Back to the editor to fix the errors, etc.

  I believe you can still get a free single-user install of Caché from the Intersystems web site. I run mine on XP. One warning is in order: Caché has been degraded to permit some non-MUMPS-standard code to run as if it were OK.  Such code will not run when moved to GT.M so you have to be careful to stick to the standard.

  The only thing I'd add to what's already been said is that MUMPS code is easily documented within the routine so that every variable could be documented where it is introduced. Just put a semicolon at the end of the line and then add the explanation. Should we all do it? You bet. Do we? You be the judge.

  Have fun.

[Dave Gifford]

I use cache editor and trial and error.  The New command and indirection are killers. I also insert sets to a scratch global to help trace before and after variable conditions

[Sam Habiel]

Tyler,

Welcome to the community, and thank you for a short and informative
introduction.

I would like to say that a good number of VISTA programmers use VPE,
which is a VISTA aware editor, but the editor leaves a lot to be
desired.

I would like to plug-in Joel Ivey's Eclipse-based Mumps editor, which
runs on both GT.M and Cache and runs XINDEX (a VISTA Lint tool) when
you save the routine.

Personally, I use vim when I am on GT.M and the Cache Studio when on
Cache. When debugging, I use the built-in GT.M debugger most the of
time. For complex code, I use Kevin's TMG Debugger. For Fileman
complexity, I would recommend Serenji (see below).

Serenji, which is a paid product, is by far the best editor of them
all. It's the only one that shows hover text for destination entry
points when you hover your mouse over them. It's free to use it as an
editor on GT.M. But it only works on Windows :-(; otherwise I would
use it.

None of the editors on the list is good enough for VISTA. I would like
to see integration with the data dictionary and code generation for
various boilerplate things we write all the time (like generating
FDAs), plus tight integration with the Dialog File.

Sam

[DL Wicksell]

Tyler:

If you use Vim and GT.M, I wrote a Vim plugin for MUMPS, which has
syntax highlighting, and several other features, notably the ability
to jump around easily within MUMPS code, following the control flow
using a tag stack system, and the ability to dump the contents of a
global into a split screen, all with simple key bindings.

It has lots of other features, and has extensive documentation, built
right into the plugin and accessible from within your editing session.

It is called AxioM and you can download it from
https://bitbucket.org/dlw/axiom
and it has a shell script that you can run that will install everything and
set everything up for you very simply. Installation instructions are in the
README.md file. Good luck to you in learning MUMPS.

>> quite helpful to have the utilities in Cach� - the Word-like full screen

>> editor and the contemporaneous terminal session. That way I can write and
>> edit code, save it and then switch to the terminal and try to run it. Back
>> to the editor to fix the errors, etc.
>>

>> I believe you can still get a free single-user install of Cach� from the
>> Intersystems web site. I run mine on XP. One warning is in order: Cach� has

--
David Wicksell
Vice President of Operations / COO
Fourth Watch Software, LC
575-636-2229


This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or coping of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.

[Tyler Kiley]

Wow. Thank you all for the warm welcome! It looks like there are definitely some interesting tools available out there - I will try these things out! The TMG debugger seems especially useful. It's really interesting how many resources are available once you start digging.

Cheers,

Tyler

[Tyler Kiley]

Oops. Meant to answer Kevin's question about my environment as well: I do my development on a mac with lots of virtual machines. I briefly experimented with GT.M on linux and eventually decided I wanted to give caché a whirl, so now I'm using a linux VM to run the caché db (along with vim and the unixy stuff that is invariably inconvenient in windows) and a windows VM for caché studio.

[Dave Gifford]

I use cache editor and trial and error.  The New command and

indirection are tough. I often set a scratch global to trace
variables at various points as well

On Feb 26, 2013 6:37 AM, "Marty Mendelson" <mart...@mkso.net> wrote:
>

[Ben Irwin]

Tyler,

Can you expand on your MAC environment?  Big MAC, MAC Mini.  Are you using Vmware?  Are you running any of the environments as a server?

I trade the following web link for MAC information.  I am considering a Mac Mini, with 250 GB SSD drive and 16 MB memory for a server.  I live in an area where we have 50MB fiber internet and they will allow me to have a server.

http://www.wbvista.info

Thanks,

Ben

[Tyler Kiley]

Ben,

Thanks for the link! The dictionary at that link is very useful. I found a similar one at http://code.osehra.org/dox/ after much digging; it's really interesting how many useful mumps resources are available and yet so very difficult to find through Google :P

I use a macbook pro, 16gb ram, 768gb ssd, two cheap 23" external displays from costco. No vmwware, just virtualbox. OSX isn't a great server OS, and it has some quirks compared to linux; if you want to use it as a *nix development server, you'll either wind up wrestling with it quite a bit or maybe just run an ubuntu or centos VM on top of it.

I spend most of my day working in Ruby on Rails, but I do some C# as well. Visual Studio 2010 runs adequately for my needs in a win7 vm. This M stuff is all new to me; at this point, I'm mostly just trying to get my sea legs - I don't have a real project with it, aside from idly pondering an entry to the scheduling contest :P

Cheers,

Tyler