Pre-processing is definitely an IDE thing. It could work this way:
1. Edit the program.
2. Hit F9., F10, whatever.
3. IDE sends the first object with a PRE section to the preprocessor designated therein (via STDIN, perhaps).
4. User preprocessor massages the program (removing the PRE section, which could also contain parameters) and outputs the results in standard Spin and assembly (to STDOUT, perhaps), or errors that it found (to STDERR).
5. IDE writes the results to a temporary file.
6. Repeat 3-5 for each object that has a PRE section, unless an error was reported (using a defined protocol), in which case the error is displayed in the IDE window where it occurred.
7. Send preprocessed files to compiler.
8. The compiled results can then be uploaded, if requested.
What to do about compiler errors? The simplest would be just to display the error in the processed code. Presumably, the preprocessor would have preceeded each group of processed code lines with a comment line containing the original code, as a context hint. More complex would be to come up with a specification for the comment line (to distinguish it from other comments), so the error could be displayed in the orignal code. Here, the IDE would find the error in the processed file, back up to the designated comment (containing the line number from the original file), and display the error there.
In any event, I don't see why the compiler itself needs to be involved with (or even know about) a user preprocessor. Nor is there any reason for the IDE to have knowledge about how the preprocessor works, beyond the I/O interface and, perhaps, the error protocol.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/18/2008 6:08:10 PM GMT
I've done it both ways, pre-processing in the IDE and as part of the Compiler. It doesn't really matter as long a the pre-processing is smart. For example, a HashString("Hello",CR,LF) macro may have had CR and LF defined in a CON so when pre-processing HashString to deliver a long constant it needs to be aware of not just #define substitutions but also CON constants. As those CON's could be object#name it has to be a bit smarter than a linear line-by-line pre-processor.
I prefer IDE to sub-executables to be via command line with just the path and name of a temporary file given which holds all parameters as that allows plug-ins to be in any language and not have to worry about the complexities of handling STDIN and STDOUT, it avoids that worry as well for others trying to use them. For example VB6 can run perfectly well as a hidden process but doesn't do STDIN/STDOUT easily. No matter how poor a person's choice of programming language may be, cutting them off causes grumbles and may even mean they don't deliver the killer pre-processing application.
There's an additional step in pre-processing, and that is for edited files in the IDE which haven't actually been saved to disk when the pre-processor wants files on disk. That's reasonably easy to overcome.
Taking Paul's comment into account, I'll update the Wiki page and add an explanation of the categories there.
Here's a tutorial on using STDIN, STDOUT, and STDERR with VB6. It doesn't seem overly complicated. But I don't use VB, so maybe I'm missing something.
The nice thing about using STDIO is that its application transcends platform differences, since most OSes support it transparently. Also, for people who want to use a preprocessor with the compiler from the command line, say, it's a simple matter to pipe output from one program into another.
But, heck, I'd take preprocessor hooks in almost any form at this point!
Chuck said...
Compiler output
Add option to always generate the .BINARY and .EEPROM files (instead of running the internal loader). This would allow the use of external loaders for linux and mac users. It would also allow two propellers (or more) propellers to be attached via USB and programmed by the external loader (for example, you could run two copies of Loader.py in watch mode, watching different binary files and connected to two different USB ports) by just compiling the appropriate top level object.
Comments
Pre-processing is definitely an IDE thing. It could work this way:
1. Edit the program.
2. Hit F9., F10, whatever.
3. IDE sends the first object with a PRE section to the preprocessor designated therein (via STDIN, perhaps).
4. User preprocessor massages the program (removing the PRE section, which could also contain parameters) and outputs the results in standard Spin and assembly (to STDOUT, perhaps), or errors that it found (to STDERR).
5. IDE writes the results to a temporary file.
6. Repeat 3-5 for each object that has a PRE section, unless an error was reported (using a defined protocol), in which case the error is displayed in the IDE window where it occurred.
7. Send preprocessed files to compiler.
8. The compiled results can then be uploaded, if requested.
What to do about compiler errors? The simplest would be just to display the error in the processed code. Presumably, the preprocessor would have preceeded each group of processed code lines with a comment line containing the original code, as a context hint. More complex would be to come up with a specification for the comment line (to distinguish it from other comments), so the error could be displayed in the orignal code. Here, the IDE would find the error in the processed file, back up to the designated comment (containing the line number from the original file), and display the error there.
In any event, I don't see why the compiler itself needs to be involved with (or even know about) a user preprocessor. Nor is there any reason for the IDE to have knowledge about how the preprocessor works, beyond the I/O interface and, perhaps, the error protocol.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/18/2008 6:08:10 PM GMT
I prefer IDE to sub-executables to be via command line with just the path and name of a temporary file given which holds all parameters as that allows plug-ins to be in any language and not have to worry about the complexities of handling STDIN and STDOUT, it avoids that worry as well for others trying to use them. For example VB6 can run perfectly well as a hidden process but doesn't do STDIN/STDOUT easily. No matter how poor a person's choice of programming language may be, cutting them off causes grumbles and may even mean they don't deliver the killer pre-processing application.
There's an additional step in pre-processing, and that is for edited files in the IDE which haven't actually been saved to disk when the pre-processor wants files on disk. That's reasonably easy to overcome.
Taking Paul's comment into account, I'll update the Wiki page and add an explanation of the categories there.
The nice thing about using STDIO is that its application transcends platform differences, since most OSes support it transparently. Also, for people who want to use a preprocessor with the compiler from the command line, say, it's a simple matter to pipe output from one program into another.
But, heck, I'd take preprocessor hooks in almost any form at this point!
-Phil
.