Deyja preprocessor

kunitoki · 2006-06-12T07:14:15

i've started using a lot your preprocessor library and i encountered some little bugettes and some strange behaviours. i would like to notice a couple of things, this is the scripts used (rememeber the new lines used are the same): // testing out multifile debugging in the ide #include "test_preprocessor.ajs" #ifndef THISFILE #define THISFILE __FILE__ #endif #ifdef THISFILE #define OTHERFILE __FILE__ #endif #pragma WARNINGS_ON void main() { println (__LINE__); println (THISFILE); firstCall(2); println (OTHERFILE); println (__LINE__); } // end testing preprocessor // test_preprocessor.ajs float firstCall (int i) { return cfloat( secondCall (cfloat (i)) ); } int secondCall (float i) { int z = 0; return i; } now: 1. the __LINE__ auto define is starting from 0 (and not 1 as a common text editor would do), so all lines are less 1 than the real line value, i fixed by adding 1 to the setLineMacro function (easy to fix and not so important bug). 2. now when debugging this, i start the debugger from the first file and if i leave the last character of the included file not equal to a newline character (in the example is ending with "}", but could be even a space), i get a wrong file and line resolve: mainly "return i" of secondCall is resolved as first script file, line 2 (and not second file line 13). then if i add a newline to the end of the second file, all is working gr8. dunnow what could be this, i'm trying to figure out what's wrong with the inclusion of a file without a ending newline. if i found something i'll tell ya... and you the same of course ;) eheh

AngelCode Affiliates

Started by kunitoki May 27, 2006 04:04 AM

12 comments, last by kunitoki 18 years, 5 months ago

Rain Dog

136

May 30, 2006 12:13 PM

FYI: My usage of your preprocessor has also required me to account for an off by one line error, or perhaps it is the way angelscript reports lines also.

Deyja

920

May 30, 2006 03:46 PM

Well, like I said, I've always gotten the correct line numbers back out of the LineNumberTranslator; though I've determined that that was actually because of a bug in the #ifdef/#endif parsing (which I've fixed). The __LINE__ macro doesn't neccessarily need to give the actual line; my testing was only too ensure that __LINE__ invoked on consecutive lines resulted in consecutive numbers. I've fixed that too.

All fixes will be included in the next release of the Wrapper Library, whenever I get around to that. I don't want to release a new official version of the preprocessor until I de-monostate it. :)

http://jemgine.omnisu.com