First off (oh no, another bad pun), you must think that I can’t count. Yes, I know 9 doesn’t come after 4 but I thought it was time bump the version number a bit. This is basically the beta-release for 0.10 which implies that most functionality is in the backend and there’s a usable console front end. After v0.10, work will concentrate on a GUI and not the console. However, the console will be there forever and ever.
In this release, just about all functions of the BS2 used in the FIRST Robotics Competition are implemented (basically, I can’t think of any more that I can think of using, if you can, please tell me). This includes for-loops, lookup, and lookdown.
There are numerous bug-fixes in this release. Basically, all the code I have (from several different teams doing different things) runs on it and does not cause any errors (that said, I don’t know if the output is correct). If you’re code doens’t run on it, please send it to me and I’ll make things work.
Also in this release, there is a command-interpreter for the console. The command interpreter currently accepts several commands:
open - open a set of files for interpretting; follow the command by the list of files
run - run the open files
continue - continue from a breakpoint
break - set a breakpoint; follow the command by the file number and line number
print - print the value of a symbol (variable, constant, etc.)
quit - quit the interpreter
There also is a README and Changelog available on the web site.
As always, emulationFIRST is found here:
I downloaded this program, and I have to say, this is nice. I was also a programmer for our team… and I plan on majoring in Computer Science when I enter college this fall, and from my point of view you deserve mad props for this. This year, I worked on a mathematics parsing program which would do things like 2.5^(2*-4) and whatnot in correct order. Considering that my big glorious project is actually something you will implement as one component of your big initiative that is emulationFIRST, I really have no place to make suggestions, but I’ll do it anyway.
Parser programs are very OOP-friendly. I did mine in C++ and built it around classes. The power in this is that you can make a general token class a base class and have all the different kinds of tokens, like reserved words or math operators, different derived classes. But what I love about C++ in this case is try, catch, and throw. Whenever I have a parsing error I just throw an exception and it gets me right where I want to be in my program flow. I understand that your deeply entrenched by now in the structure of your program and a conversion to classes would be too time-consuming for what it’s worth. Plus you might not have the compiler for it.
Real time??? You can use the game ports in a computer to test it out. I know it’s a stretch and it’s probably better to somehow do it from the OI, but hey, it’s just an idea.
If you go GUI, my suggestion is compile the C to DLL and have a VB front-end slide right on top of it. This way, you could possibly implement suggestion #2. But, this is platform limited, and I don’t know if you have the compiler for it. This is just the easier way I would do it; if you do it in C, then all the more respect to you.
Again, props. I saw your web site, good luck with the co-op and with RIT. I’ll read some more of this code… looks yummy.
The main reason I wrote the program in C as opposed to C++ is the fact that the tools I used (Bison and Flex) output C code. They also happen to be fairly standard tools on Unix (going by the names Yacc and Lex). Flex is a tokenizer. It allows you to specify regular-expressions and the Flex command will take your input file (in emulationFIRST the file is pbasic.l) and create a tokenizer that you can call. Bison is a program that allows you to specify certain patterns of tokens and takes your input file (in emulationFIRST the file is pbasic.y) and outputs a C file. This C file is based around a state machine. Overall, the combination of Bison and Flex works wonders as it made a lot of the actually parsing much much easier.
The other reason that C was used over C++ is that I tend to prefer C a bit. For what was needed, C++ seemed like it would be overkill.
As far as a GUI goes, I’ve already written the program to separate the input from the actual processing. You can look at the file console.c (it runs the UI right now) and you can see that the parser never calls any function in console.c (except by using call-backs/function pointers). I’m planning to base my GUI on GTK 2.0 which was originally native for Linux but also has a Windows port (and may have a Mac port, I’m not sure). GTK is written in C so it makes it easier to interface with other C code.
If you have any questions or whatnot, please feel free to contact me.
Oh… so I was getting over-impressed because this was machine generated code, and I thought you wrote it all. :mad: Well, cool, as soon as I get to working with UNIX in college, I’m making mad parsers then. You see Bill Gates, this is what happens when you put UNIX out of the mainstream with your infernal happy-user software! We lose access to the wierdly-named phat stuff!!
The only machine generated files are pbasic.tab.c, pbasic.tab.h, and lex.yy.c. All the other files were written by me. I also don’t tend to use goto’s in my code. But basically all the generated parsers are are state machines. And some of the code that actually gets put in the generated files was written by me. Bison and Flex have the ability (and it’s used most of the time) to put code insert code inline. If you look at the various pbasic.y and pbasic.l files you can see where the code that’s dropped in inline is.