   Deyja preprocessor
  i've started using a lot your preprocessor library and i encounteredsome 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_ONvoid main() {  println (__LINE__);  println (THISFILE);  firstCall(2);  println (OTHERFILE);  println (__LINE__);}// end testing preprocessor// test_preprocessor.ajsfloat 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   
Quote: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).I've never used the __LINE__ macro myself, so, eh. Make sure you don't mess with the running line count, or the Line Number Translator won't work right. I made this change in preprocess.cpp -static void setLineMacro(DefineTable& define_table, unsigned int line){DefineEntry def;Lexem l;l.type = NUMBER;std::stringstream sstr;sstr << (line+1);    //<-- This line changed.sstr >> l.value;def.lexems.push_back(l);define_table["__LINE__"] = def;}If you're using boost, you should change that to use lexical_cast instead of stringstream.Quote: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 ;) ehehIt used to crash if you left off the newline. Since my IDE always adds the newline, and I edit my scripts in the IDE, it went a long time before I caught it. Theres a slightly newer version of the preprocessor inside my Wrapper Library; you should try that one and see if you have the same problems.I'm going to look at it; I think I know what's happening. You should be able to just stick an extra newline onto the end of every file as it's loaded. Of course, it will think every file is one line too long - but that's fine, because a blank line can't have errors anyway.Add the following between lines 509 and 510 of preprocess.cppdata.push_back('\n');This essentially forces every file to end with a newline token. When it didn't, the last line of the included file became to same line as the #include was on in the first file, and every line after that was off by one.:) ;  I think I should emphasize; my changes were made to the version included with my Wrapper Library, which may or may not be different from the version on my website. You can get the wrapper library at www.omnisu.com/files/sil.zipAlso, can you show me how you implemented that pragma? Did you add the ability to disable the #warning directive, which doesn't actually serve a usefull purpose anyway? Or are you toggling warnings in AngelScript?   ;  thanx deyja, i've looked in the sil.zip but the preprocessor implementation is the same that i have (except a couple of new #directives that i'm using in my ide, which don't cause any new line chattering)... anyway, adding a new line is faulting all the lines that i have in files, so actually i have to find another workaround, maybe taking care of that offset.since i don't like angelscript to report lots of warnings when passing a float to a double type, i'm actually turning them off angelscript ;)void asCCompiler::Warning(const char *msg, asCScriptNode *node){  // just avoid here reporting warnings};  apart from the __LINE__ macro, i noticed that also in the error and warning output the lines are counted starting 0, not 1... just to tell ya ;)   ;  I don't see how that can be the case, as I've always gotten proper line numbers back out of it.Quote:anyway, adding a new line is faulting all the lines that i have in files, so actually i have to find another workaroundWhat, exactly, do you mean by 'faulting'?   ;  Testing shows that everything is fine. I'm going to need you to be a lot more specific about your errors, and give me a sample program that replicates them. Preferably the whole app; not just the scripts.Additionally, check how you are parsing the error messages to get the line number that you pass to the line number translator.[Edited by - Deyja on May 28, 2006 8:58:43 AM];  i just means that i have done this tweak in preprocessor:void PrintErrorMessage(const String& errmsg){String str;str << current_file << " (" <<(lines_this_file+1) << ") Error : " << errmsg;(*error_stream) << str;number_of_errors++;}void PrintWarningMessage(const String& errmsg){String str;str << current_file << " (" <<(lines_this_file+1) << ") Warning : " << errmsg;(*error_stream) << str;}adding 1 to the lines_this_file global variable, of course starting from 0 and not 1. now all is perfect.anyway now adding the line that u told me, forcing every included files to have a finishing endline, is working.   ;  Well, that's good to know. :/   ;  ok i know, nothing fancy, just to share with you what i've discovered trying and trying and trying out the preprocessor :D   