On Sunday 17 August 2014 00:33:56 Gregg Eshelman did opine
And Gene did reply:
> On 8/16/2014 4:43 PM, Gene Heskett wrote:
> >> http://linuxcnc.org/docs/html/hal/canonical-devices.html
> >
> > I just read thru that from every direction.
> >
> > Not one character was wasted to recommend a way to enumerate multiple
> > inputs to differentiate the first from the last. No wonder we have
> > such a mish-mash that cannot now be corrected without breaking every
> > machine config we've ever built.
> >
> > Yeah, it could be fixed, but the screams of gored oxen will
> > reverberate all thru the land. So we are doomed to deal with that
> > legacy forever I'd imagine.
>
> There comes a time in many a software project when it's best to just
> toss it all and start over instead of trying to support all that has
> come before.
>
> One of the big reasons to do that is correcting long-standing problems,
> but to do so requires changing how one goes about writing the code for
> the part where the problem is.
>
> One case was the Netscape web browser. It had a very annoying problem
> with forms where after clicking the button to submit the form it'd just
> sit there for a while then go to an error "Document contains no data.".
> But while Netscape was twiddling its digital thumbs, the same form
> could be filled out and submitted successfully with Internet Explorer.
>
> The Netscape crew never would admit the problem existed and each time
> they supposedly started over on the browser from scratch, they managed
> to reproduce that same problem. Eventually they just removed the error
> message so the browser would just give up on sending the data without
> popping up an error window. Click the button and watch the spinning
> hourglass for a while... then nothing happens but the cursor returns to
> the arrow and the form wasn't sent.
>
> Could be that some of their coders were using old pieces of code to
> save time, or it could have been the way they "knew how to do it" on
> that part of the code and wrote new code that worked just as poorly as
> the old code - replicating the bug in a slightly different way.
>
> How many ways would LCNC benefit from a major "house cleaning" to clear
> out dusty old bits that have been deprecated, "spaghetti code" and
> other things that have been let go for a while?
I don't see that its anywhere near that state yet. But I don't see as
much hoorah as some in fixing some of the ways a config file was written
at each minor level update either.
Writing a .hal file using the names= syntax in the loadrt lines makes for
.hal files that are a heck of a lot easier to trace tomorrow, or even next
year, so enum-ing a pile of and2's should be very strongly discouraged.
To me, the only sensible way to do it is in a
modulename.function_description format, such as having an abs.encdir, and
an abs.piddir, something along the lines of what we do for argv(1) in a
"net" line, where we should be using a signal-name that describes what
this signal is doing.
But that isn't going to be 100% usable until every module can accept a
naming scheme that only allows whats between the dots to be used as the
enumerator. Presently we have some that apply the naming to the whole
module, and we still have some modules that do not accept the names=
format at all.
IMO, formalizing the input enumerators to either use the .in-#
universally, or just the .in#, which I don't care as long as its
universally used.
And likewise, restricting the names= so that ONLY the 0,1,2 enumeration
portion of the referenced name for the rest of the file is replaced by the
names= function, so that the descriptive name fits between the dots and
_only_ between the dots every place else in the file.
So we could have a
loadrt and2 names=.spndl,.fwd-on,.rev-on,.etc0,.etc1
and get modules named
and2.spndl, and2.fwd-on, and2.rev-on, and2.etc0, and2.etc1
addf's would remain unchanged, using the whole loadrt generated name
Code readability wouldn't be markedly enhanced, but error less code write
ability would be greatly enhanced because of the standardized way its
done. Having to open a man page to see what syntax this module expects is
a PITA, that part, and the 'in' enumeration should be consistent for every
module that can be loadrt'd.
So, fix the "in" enumeration in the 2.7 release, fix the names= in the 2.8
release, and get rid of the old code that allows what we can do now, out
by 2.9. That way, one session in gedit, using its global replace ability,
per minor release upgrade shouldn't really gore that many oxen at a time
because its one thing at a time.
OTOH, my hand in steering this great ship, has an effect comparable to
rowing with a toothpick. But if I can suggest ways to improve it, I sure
will. ;-)
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
