Hi Ken Thank you for your continuing quest.
On Mon, 2007-02-05 at 09:23 -0500, Kenneth Lerman wrote: > In my continuing quest to improve the interpreter, I've come across a couple > of issues where I'd like some guidance. > > The change I'm working on now has two aspects: > > 1 -- If there is a call to a subroutine that has not already been defined, > the interpreter first looks to see if there is another file that defines the > o-word. It does this by looking for a file named oNNNN (where NNNN is the > number of the o-word). > > 2 -- If there is no such file, it then starts skipping forward in the > current file until it finds the o-word. If there is no such o-word in the > current file, it is an error. Some systems do place all of the subroutines at the end rather than the beginning of a program so this should be a good addition. I also like very much the idea of the ability to use libraries of common subroutines. I'd be much less enthusiastic about us supplying a library as a part of a distribution. > This capability allows files that have been executed in this manner to > reference o-words in other files with a limitation of the maximum number of > subroutine levels. At the present time, this is set at ten, but could easily > be increased. > > This facility would let us have libraries of gcode that would be included by > reference. The next step would be to support named o-words. So, > o<InterpolateCircle> would be a valid o-word, and would cause the file > InterpolateCircle to be loaded. (In the case of named o-words, I would not > put the letter 'o' in front of the name.) > > The following issues arise: > > 1 -- What directory (or directories) should the interpreter look in for the > file oNNNN? Some alternatives are: (a) a fixed directory, (b) specify a > directory search path in the configuration file, (c) specify a directory > search path by use of an environment variable (e.g. > GCODE_PATH=/home/emc/gcode:/usr/local/gcode) > > 2 -- Is there a standard extension we should use for gcode files? Should > that be oNNNN.ngc, for instance? I like the use of .ngc for any g-code file specific to EMC and I'd place libraries of code in the place where the install puts the samples. In my case, I tend to make directories below that location for projects and for customers. > 3 -- The error message facility in the interpreter is very limited in that > the messages are fixed. So in the case where the interpreter is skipping > forward in the file and the oword doesn't exist (in the case of a typo, for > instance), there is no apparent way for an error message to tell what o-word > it was seeking, what the name of the current file is, or what line in the > file called the missing oword. > > I believe that I've seen a bug report that refers to the fact that an error > message is in english. Support for other languages in the error messages > would also be desirable, but I'm probably NOT the person to implement that. Making error messages from the interpreter multilingual is a good thing. It should be expanded system wide using a common "plan." This plan should include passing a unique arg like the missing value, or the offending line number, or whatever it is that caused the error message. > 4 -- The interface from the interpreter to Axis should probably be extended > so that axis can be aware of the current line number and file name. I'm not > familiar with the interface and would appreciate suggestions in this area. > (For all I know, that info might already be available.) IMO this is not just needed by AXIS but should be made a part of the NML messaging system. Rayh ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
