Experimental Physics and Industrial Control System

Deb & Jeff write:
>
> The ascii format was created specifically for providing an upgrade path so
> that existing displays could be used after additions/changes were made 
> to edd/dm. Since dm uses only the binary format, the compactness of the 
> ascii files was not considered an issue.

Which is the same reason we came up with the ascii database formats (and
before that, those short-form reports.  The average binary formats are 
just too rigid to allow growth.

> When medm work began, it used the edd/dm ascii format and diverged from
> there.  At that point in time there was a discussion about keeping the 
> file formats in sync.  The author of medm at that time felt this was not
> an important issue.

This was unfortunate and started a tad before I was around.  I never backed 
the decision, even though I am a member of the APS camp.

> Edd/dm ascii format has also diverged since then to support new features 
> and functionality.  The work done recently so that medm display files 
> could be imported into dm was a conversion from medm ascii format to edd/dm
> ascii format followed by saving the ascii files in binary format.

This is something I was not aware of.  The good news is that since none of the
real information content has been changed it would be no big deal to write
a lex and yacc program to read the new MEDM stuff and spit out the old stuff.
Converting the old format to the new might be a little harder because there
is no useful context information in its grammar.  But it is still doable in
a day or two.  I guess it was a bit weenie-like of me not to write them
as standalones when Fred and I were changing things.

> The issue here may really be one of backward compatibility vs upward 
> compatibility.  It is reasonable to expect that display files, etc. from
> one version work with the next version of a tool.  While it would definitely
> be desireable, it may be too much to expect that new versions of display 
> files work with older versions of the same tool or others.  Having advance
> notice about such upcoming incompatibilites with tools you're using would 
> certainly be in order, though.  As Chip mentioned, communication and 
> documentation are essential to prevent other problems like this. As a tool 
> author, this point is one that I intend to keep in mind for future releases.   

consider this advance notice.  MEDM is not hard-nosed about the formats (yet)
and can do both.  What is the big deal?

> It is unfortunate that the suggestion of a collaboration to merge medm and edd/dm
> did not meet with the same enthusiasm and support that other EPICS collaborative
> efforts have.  Had this been the case, the differences would have been resolved.
> (and maybe tech-talk wouldn't need to invest in a fire extinguisher :-) )  If
> this compatibility is important to the EPICS community, maybe we can still
> collaborate on this issue and try to maintain consistency in the display list.
> Or maybe just having them documented is sufficient.  Opinions? 

They should be compatible.  Fred or I should write the stand-alone converter.
I think using DM or MEDM to convert them is ugly.

Why there was such a religous issue about DM/MEDM is quite beyond me.  I expect
that Mark's (oops I droppped a name) widget-vs-gadget crap is no longer an 
issue with you guys?  The real issue of concern to the collaboration should be
the use of non-standard (expensive) 3rd party junk that got into MEDM... which
as I understand it, is #ifdef-able out these days anyway.  (And in fact is 
the source of a few programming nightmares ahead in the Java version which 
you DMers can safely hand back to APS ;-))

I am not saying that DM should be dumped, it is a VERY useful tool.  What I
am saying is that I think most of the feuding about this stuff started on
something that was an effeciency issue to LANL that is probably no longer a 
reasonable arguement.  And that the only feul left for it is residual anger 
and a new target for finger pointing... XRT-graph, the font-nightmares and
what ever-else is fixable with a few #ifdefs in MEDM.

> > I don't want to ask who came up with that horribly unorganized mess of a 
> > format in the first place.  I suspect that it is the same $#&&^% that came up
> > with the unbelievably odd message-button behaviour (that has hopefully been
> > fixed by now) that I recall from 1992.
> 
> The "unbelievably odd behavior of the message button" in dm was mandated
> by the GTA project, the project responsible for the majority of EPICS edd/dm
> funding at the time.  It has since been changed to follow the design as 
> originally intended.  (FYI, the person responsible for the "horribly unorganized 
> mess" was not the same $#&&^% that implemented the message button.  Gotta keep 
> our EPICS history straight :-) ) 

There is NO way that anyone could have explicitly asked for that specific 
implementation.  It had to be a misunderstanding.  No self-respecting scientist 
should even allow themselves to *think* that way.  My 6-pack bet for the year 
is that someone didn't feel like making work for themselves and used the 
release message text string as a flag instead of the semantics that any sane 
human would intuitively associate with a string field that is named "release 
message."

I suspect that one of three things happened there:

1) Misunderstanding of what was WANTED (not specified... wanted.)
2) Sane understanding and implementation of what a message button should so
   followed by an ugly non-intuitive hack to compensate for missing 
   functionality (which has happened to all of us before... see GPIB's 
   responds-to-writes nightmare.)
3) One very non-intuitive design decision that should have been fixed long ago.

> > So anyway... the point of today's rambling is to let the folks at JeffersonBAF
> > know that my Java stuff is not exactly in sync with the new MEDM format
> > either.  It needs to have the RGB parser changed to read the 3-byte RGB
> > values instead of the R=, G=, B= cruft that it had in it when I sent it
> > to you.  You might consider adding a little logic to let it read both formats
> > automagically... though I'd rather see the old format not supported at all
> > since it adds something like 70KB to every screen and 
> 
> >taked several seconds to parse using my (admittedely less-than-optimal) logic.
> p.s. We suspect that since medm supports only an ascii format it will be very 
> difficult to beat the compactness of the edd/dm format--this approach "taked" 
> less time to parse, rampant "bogosities" and all.  (All "flaming" aside, your 
> decision to implement such changes does make sense for medm. )

I have never looked at the binary format for DM, but unless you are doing a 
variable-sized record format, I actually think that an ascii one COULD come
close to both size and speed (see also the database and SDR studies from a 
few years back.)  One might have to make a few more changes to the grammar and
keywording but me thinks it is doable.  Me also thinks that portability is
worth the hit in init-time performance I was allowed to use as a handicap (and 
did not require... run the same tests again today now that the SDR stuff is 
gone) in the ascii database tests.

I gess the moral of this thread is that we gotta make sure that even the most
intensly feuding applications should remain compatible.  And I vote that 
stand-alone file converters, like the ones Jim has provided us for much of
his ascii database work, are the way to go because they are easy to compile
and run.  If someone can not run MEDM and has MEDM files, how can they build
MEDM so they can use it to convert the files to DM format?


--John Winans

Replies:

Re: FLAME medm watson

Navigate by Date:

Prev: subscribe Xiaosong GENG

Next: Re: FLAME medm Jim B. Kowalkowski

Index: 1994  1995  <1996>  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: FLAME medm Deb Kerstiens

Next: Re: FLAME medm watson

Index: 1994  1995  <1996>  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024