During my work on a parsing library for AutoLISP yesterday I started to think about some debugging tools I wanted to write for AutoLISP. These tools include the following:
1) An AutoLISP function that will display the current values of all the variables in a function in a DCL dialog.
2) A functional testing library that includes export of test results to HTML and a DCL test result viewer dialog.
3) Support for Java like exceptions that can be thrown inside a function, and display error reporting to the user in a DCL dialog. This may involve some hacking to enable stack tracing and other debugging support through something like a “surveyos-execute” function.
I hope to start work on these tools soon, which will be released through the SurveyOS Project under the GPL Version 3. This is way better than debugging with alert function calls.
One reason I need these tools is because BricsCAD for Linux and AcceliCAD for Windows don’t have the VisualLISP editor that comes with AutoCAD.
The Sunburned Surveyor
One mistake that I’ve made for the last year as a programmer is writing custom parsers, from scratch, in the different programming languages I work with. I know realize I can save a lot of time and effort by factoring out common parsing tasks into a parsing library for each programming language I work in.
One of my current programming projects is to implement WKT import in CAD using AutoLISP. Instead of taking my traditional approach of writing a custom WKT parser from scratch, I’m going to create a parser library in AutoLISP, and then I will build the WKT parser using that library. I can then more easily implement other parsers (like a LandXML parser) in AutoLISP with more efficiently by using the parser library.
What does my parser library need to do?
It is going to handle three (3) basic tasks:
- Separate target strings into “chunks”. Four (4) basic chunks will need to be recognized. These are (1) whitespace, (2) groups of letters [or words], (3) groups of digits, (4) symbols [or punctuation]. (The groups of letters may also include embedded numbers).
- Process “chunks” into token chains.
- Interpret token chains into expressions.
This is different from the traditional parsing method in which tokens are produced in one step called scanning or lexing. I separate this into two (2) tasks: Chunk production and THEN token production. I’ll talk about this later in another blog post.
I started implementing the parser library for AutoLISP today. I’ve written functions that identify letters, digits, symbols, and whitespace using ASCII codes. I’ve started writing a function that will separate input strings into chunks.
When I’ve completed this parsing library in AutoLISP, I’ll implement it in Java and Python.
I’ll keep my readers posted on my progress.
The Sunburned Surveyor
I’ve decided to implement an AutoLISP software module manager in Python. (I’d write it in AutoLISP, but the language doesn’t have some of the filesystem API support that I need.) I’m looking for a plug-in framework I can use for the software similar to that found in Eclipse RCP, Netbeans RCP, or OpenJUMP.
After poking around the internet for a while, I managed to find this very helpful blog post from William E Hart with a review of some Python Plug-in Frameworks. The Yapsy Plug-in Framework in his list looks like what I need. I hope to use it in combination with the PyQT GUI toolkit to create a Python pluggable software framework for desktop applications similar to my Simple Pluggable Swing Program.
Yapsy Home Page