I agree with Kent that the line by line interpretation is an issue that
needs to be addressed. It is one of the constraints I faced when I added
O-word control structures to the language.
In particular, the line at a time interpretation caused me to opt for
control structures with labels. "Real" languages don't require labels to
match an if with the corresponding else.
I totally ignored issues involved with MDI (although I recognized that
they were there -- barely). Of course, that came back to bite me when I
wanted to call subroutines from MDI. Getting those calls to work was
possible, but if you have an error in the MDI code, error handling falls
apart.
There are things that are worth doing that aren't worth doing right. I
still believe that was the right decision at the time, but a major
rewrite is way overdue. At the same time, I would consider adding new
variable types. A string type would be useful for those of us (or those
of you) who would like to do engraving of strings. That would probably
also require removing the conversion of the entire line to lower case
during (or prior to) the lexing.
Regards,
Ken
On 10/28/2011 1:29 PM, Kent A. Reed wrote:
On 10/28/2011 6:46 AM, Michael Haberler wrote:
I've written up a wiki page on the
status:http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RemappingStatus
It's intended as a extended Readme to clarify what we're getting into, and as a
rough guide for reviewers (hint..)
I encourage developers, and the EMC2 Board in particular, to read the 'Problem
Areas in EMC2' section, and comment
-Michael
Michael:
I like your writeup.
As much as I want to be I've had to admit to myself that I'm not going
to be a core EMC2 developer nor am I likely in my remaining years to
work with machinery that requires your g-code remapping capability.
Still, I see much good for EMC2 generally in your proposal. I
particularly like the introduction of embedded Python and an
"extensible distributed shared memory mechanism with late binding."
I'm not one to debate it, but the idea of breaking away from
line-by-line interpretation seems long overdue.
As well, I give you high marks for experimenting rather than simply
expounding theoretically.
Regarding the adoption of redis, the risks seem minimal and manageable
and the benefits seem substantial.
Regarding a proposed revamp of EMC2's logging capability and the
question of Python, do you believe Python's existing logging
capability is sufficient or do you envision some sort of
Python-log4cxx mashup?
I've been a huge fan of Python since I heard Guido speak at NIST many
years ago. On the other hand, my best programmer was a Tcl/Tk-head,
and we had many frank and open discussions (that's diplomat-speak for
"arguments) concerning the two, so I can imagine there may be some
push back on choosing just one interpretive language. Still, I think
using just one would improve EMC2's longevity (guess which one I would
choose:-)). Less is more.
I like that your writeup addresses the kinds of questions I claimed in
a recent rant should be answered in a good proposal---what is the
problem, how would it be addressed, what would be the benefits, etc.
One of those questions was "how will the results be implemented?"
Maybe it's clear to the developers and the board, but it isn't clear
to me which of the items you discuss need be introduced simultaneously
as a major revision and which can be introduced individually as minor
revisions.
Please keep up the good work!
Regards,
Kent
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
203-426-3769
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
