A linked list in the same address space would solve the problem for the preview, but wouldn't solve the problem for actual program execution. (I assume that the interpreter runs in a different address in that case). Also, a linked list is far more complex than reading a named pipe that contains the text of the error and traceback messages.
A named pipe would be just another file as far as Axis is concerned. When Axis started, it would start a read on the named pipe and display whatever it reads. Of course, that would require periodic polling on the pipe or a separate thread to read the pipe. That would be true whether it were a named pipe that is read or a linked list. The interpreter already has a mechanism to translate an error message to a string. The file rs274ngc_pre.cc: contains the function void Interp::error_text(int error_code, char *error_text, int max_size) which returns the error_text, given the error_code. I have changed the file gcodemodule.cc to use that function. Assuming that is the only place in Axis that translates the error messages, this should simplify things. A next step in internationalization should be to have the interpreter call the translation routines. Ken [EMAIL PROTECTED] Mark Kenny Products Company, LLC 55 Main Street Voice: (203)426-7166 Newtown, CT 06470 Fax: (203)426-9138 http://www.MarkKenny.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Epler Sent: Monday, February 05, 2007 5:15 PM To: EMC developers Subject: Re: [Emc-developers] Better Error Handling For The Interpreter Named pipes? That sounds like a case of overkill. When AXIS generates the preview, the g-code interpreter lives in the same address space, so any kind of in-memory structure is going to be fine. For instance, a linked list or array of frames, each containing a filename, line number, and the "local" variables. Plus a way to access the "global" variables. Right now the interpreter has strings that are marked for translation, but it does no translation itself. Instead, when the GUI gets the error message by number, it looks it up in the catalog. But if the message has been formatted (e.g., turned from "X coordinate %f is too big" to "X coordinate 1000 is too big") then it can't simply be looked up in the catalog. This means adding to the interpreter the step that looks up the format string to find the translated format string. I suggest getting rid of the 100 or so different numbered errors because it is a needless complication to have two ways to look up an error: One by looking up an entry in a table based on the number, and another by looking in some buffer for a string. Throw out the old cruft when you replace it. Don't keep the old cruft around forever. (at least as far as the mostly-internal API is concerned, I'm not suggesting that you break compatability with old g-codes) Jeff ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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
