User bio

OOP bg, worked as EDI/Interface TS for EPIC out of college which got me into the Healthcare/HL7/MUMPS game.

A few years later I was first introduced to the ISC stack in managing a group of HS instances.

Enjoy creating utilities that increase efficiency.

Member since Aug 6, 2019

Has anyone ever converted an HL7-embedded Base64-encoded PDF TO (HL7-embedded) RTF?

This looks great, but i noticed the linked LibreOffice conversion table seems to indicate PDF can only be exported (conversion target), not imported (conversion source)

Honestly interested in PDF of any kind; "converting" B64 PDF to a flatfile *.pdf is trivial, but it looks like using *.pdf as a source is not supported for LibreOffice method?

FWIW: Ensemble v2016.2 on Windows

@hans was a typo, thanks for the catch; i have corrected it. ;)

I find myself agreeing with Mike W on this one in being generally in favor of (some) abbreviations, though I can certainly understand the "fully written out = easier to read (and thus maintain) code" argument.

I should also add: I have found I apply abbreviations inconsistently (Much to my internal engineer's chagrin)

s/set is an easy one and as mentioned, quickly becomes comfortable. I also tend to use d/do.

However, for control-flow items (for/if/while) i find myself always writing these out.  After reading John's subcomment above, I wonder if indeed this could be related to the larger "semantic gap" that develops in (for example) parsing "f" vs "for" / "i" vs "if" -  it is harder for NLP english brain to quickly internalize the true meaning.

One additional point touched on: preserving spacing. Abbreviations won't usually save vertical space, but I would contend that sometimes horizontal space (which they do save)  is a premium as well. Lines running offscreen can be annoyance at best, but at worst can cause a programmer to misparse or even completely miss sections of code. For this reason, I will usually try to break long lines (ie, a long concatted string) over multiple lines with an indented "_". Abbreviating saves hspace as well - albeit moreso $ objs functions than commands.

Speaking of which... Wasn't asked by OP, but similarly for objs functions: I will almost always use $P over $Piece, $S over $Select (but not $C for $CASE wink ).  I can understand rationale for spelling these out but as these (especially some $S) expressions can get complex, I find abbreviating the func itself helps keep focus on the expression logic itself. Sometimes an extra space between parens can go a long way towards maximizing this clarity. Oh, and $ZDT >> $ZDATETIME any day :) Similarly, would anyone actually ever write $HOROLOG over $H ?

In a similar, related vein of "cautionary M tales" - found this lovely gem crawling some forums last year (from a much older post from the days where the Cache tech stack was perhaps a bit less mature) :

"The following is a valid line of MUMPS code:

A       B:C  D E F G=H:I:J K:L M N O,P Q:R  S T=UVW X YZ

It means "Line is labelled A.  Breakpoint if C is true.  Do the E subroutine.  For G=H to J, incrementing by I. If L is true, kill (unset) the M variable.  Create new variables O and P.  If R is true, quit.  Set the T variable = the UVW variable.  Execute the contents of the YZ variable as if it contains valid MUMPS code." I remember showing some code to a college friend when I'd been working with it for a few months, and he asked why my printer was spewing line noise."

From <>

Brad has no followers yet.
Brad has not followed anybody yet.
Global Masters badges: