obscure problems using NWNScriptCompiler.exe

[Legacy_azaz1234]

               

hi there,

 

i'm compiling some scripts i've written and most of them compile and run fine. however, i've run into a little problem w/one of them, and the compiler gives me the following cryptic error msg :

Cleaning up defunct resource manager instance 'NWN2CliExt_3748'...

in addition, it often segmentation faults right afterwards.

 

i'm invoking it like this -

NWNScriptCompiler.exe -g -q -1 -v1.69 -a -n{nwn location} -i{include_path} -c script.nss

it seems to choke on a case statement; if i comment it out, the script compiles.

 

has anyone ever used this compiler before and run across this error?  if so, any idea what it means?  i'm wondering why this particular script won't compile and damned if i can figure it out, it compiles fine w/the toolset compiler.

 

thanks!

               
               

               
            

[Legacy_meaglyn]

               

I don't use that compiler but do use an out of tree compiler and  have noticed that the toolset compiler is more generous with what it allows to be used as a case statement value. Can you show what your case statement looks like?  If commenting out the case statement fixes the issue then I'd focus on that.

               
               

               
            

[Legacy_azaz1234]

               

i think i've found the problem. as strange as this may sound, the compiler barfs when a negative number is used in a case statement.

 

i've used the following snippet to test -

const int    NOT_AN_OBJECT = -1;

void update_list(object oPC, object oTarget, location lTarget)
{
    string type = "";

    int otype = GetObjectType(oTarget);
    switch(otype) {
      case OBJECT_TYPE_CREATURE:
        type = "creature";
        break;
      case OBJECT_TYPE_PLACEABLE:
        type = "form";
        break;
      case -1:                      // a location
      //case NOT_AN_OBJECT:
        type = "location";
        break;
    }

    // operative code here

}

void main() { }

as is, the code won't compile. if you comment out line 15 and uncomment line 16, the code compiles. in fact, you can replace the '-1' w/any negative number and the compiler will barf.

 

obviously i could work around this issue by defining a constant, but that still leaves me a little dubious about the compiler. if it won't accept this, it might be compiling other code into something buggy but not telling me...

 

what compiler do you use, meaglyn? do you get good results with it?

               
               

               
            

[Legacy_meaglyn]

               

Well that looks like a bug '>

 

 

obviously i could work around this issue by defining a constant, but that still leaves me a little dubious about the compiler. if it won't accept this, it might be compiling other code into something buggy but not telling me...

 

what compiler do you use, meaglyn? do you get good results with it?

 

I wouldn't worry about it making buggy code if you are testing. It's not like you are writing an OS with lots of subtle untestable code paths and infinite possibilities for memory corruption. If it's making bad code you should find it in testing.

 

I use this on Linux which is my edits to Niv's tree of the compiler from the old nwn-tools release. I think it is based on work by Torlak back in the day.

It works pretty well for me.

               
               

               
            

[Legacy_azaz1234]

               

thanks for the info.

 

i'd like to use your version. i went ahead and cloned it to my machine, but ran into a problem during the make. everything up through the support libraries went fine, but when it got to the compiler preprocessor, i got the following errors :

/cygdrive/n/nwn/build/nwntools/_NscLib/NscCompiler.cpp:391:43: error: 'location_type' in 'class yy::parser' does not name a type
 void yy::parser::error (const yy::parser::location_type& l,
                                           ^
/cygdrive/n/nwn/build/nwntools/_NscLib/NscCompiler.cpp:391:6: error: prototype for 'void yy::parser::error(const int&, const string&)' does not match any in class 'yy::parser'
 void yy::parser::error (const yy::parser::location_type& l,
      ^
In file included from /cygdrive/n/nwn/build/nwntools/_NscLib/NscContext.h:56:0,
                 from /cygdrive/n/nwn/build/nwntools/_NscLib/NscCompiler.cpp:42:NscParser.hpp:315:10: error: candidates are: void yy::parser::error(const yy::parser::syntax_error&)
     void error (const syntax_error& err);
          ^
NscParser.hpp:312:18: error:                 virtual void yy::parser::error(const string&)
     virtual void error (const std::string& msg);
                  ^
_NscLib/CMakeFiles/nsc.dir/build.make:84: recipe for target '_NscLib/CMakeFiles/nsc.dir/NscCompiler.cpp.o' failed
make[2]: *** [_NscLib/CMakeFiles/nsc.dir/NscCompiler.cpp.o] Error 1
CMakeFiles/Makefile2:225: recipe for target '_NscLib/CMakeFiles/nsc.dir/all' failed
make[1]: *** [_NscLib/CMakeFiles/nsc.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

i think i'm a little out of my depth here... %-|

any hints you could give me on how i could get this to compile ?

 

               
               

               
            

[Legacy_meaglyn]

               

I've never tried to build it using cygwin.  That's an odd error though. The type is defined in the referenced include file.

 

Try adding

using namespace  yy;

to _NscLib/NscCompiler.cpp at around line 47 (after all the chunk of #includes). See if that works.

               
               

               
            

[Legacy_azaz1234]

               

I've never tried to build it using cygwin.  That's an odd error though. The type is defined in the referenced include file.

 

Try adding

using namespace  yy;

to _NscLib/NscCompiler.cpp at around line 47 (after all the chunk of #includes). See if that works.

 

still doesn't compile.

 

there's another error i just noticed, i must've missed it earlier -

NscParser.ypp: warning: 11 shift/reduce conflicts [-Wconflicts-sr]

...but apparently shift/reduce conflicts usually aren't show-stoppers, so i don't think this is the cause.

 

i noticed that the type location_type doesn't appear anywhere in the source tree except for this one line, where it's referenced in NscCompiler.cpp:393 (391 before i added the namespace ref). googling around a bit, i see that there's a hook normally supplied by bison when it generates the parser, which required the programmer to create the actual function definition -- which would explain why it isn't defined in the source tree. unfortunately, this syntax was used for bison v.2.7 and earlier. the syntax has been changed in more recent versions [mine's 3.0.4]. haven't figured out how to make the change to the code in order to accommodate the newer version, i don't know how to use bison or flex, and i don't know how i'd need to change the function parameter... :/

               
               

               
            

[Legacy_meaglyn]

               

I suspected that would not work but thought it worth a try.

 

Umm, location_type is typdefed in the yy::parser class in

_NscLib/NscParser.hpp:71:    typedef location location_type;

in my tree. Not sure what you are looking at if it's not there. Take a look at the NscParser.hpp file your bison is generating and see if there is anything related to location.  Could try changing the type in that routine to

yy::location&

You may have more luck if you try to get your cygwin to have an older version of bison. I have not used later versions of bison. But if I get some time I will try it.

 

               
               

               
            

[Legacy_azaz1234]

               

Umm, location_type is typdefed in the yy::parser class in

_NscLib/NscParser.hpp:71:    typedef location location_type;

in my tree. Not sure what you are looking at if it's not there.

 

 

heh... mine's COMPLETELY different at line 71 -

#if !defined _Noreturn \
     && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112)
# if defined _MSC_VER && 1200 <= _MSC_VER
#  define _Noreturn __declspec (noreturn)
# else
#  define _Noreturn YY_ATTRIBUTE ((__noreturn__))
# endif
#endif

Take a look at the NscParser.hpp file your bison is generating and see if there is anything related to location.  Could try changing the type in that routine to

yy::location&

 

nothing that obvious. it looks like they've completely changed the syntax, if not the paradigm itself. they mention semantic_type and token_type frequently, and a slew of other types too, obviously, but no more return_type anywhere. no references to location anywhere, and arbitrarily foreshortening location_type to location didn't fix it. '> it looks like location is available only indirectly, as though it's now subsumed by the symbol type. but here i'm getting in way over my head.

 

You may have more luck if you try to get your cygwin to have an older version of bison.

 

i was able to compile bison 2.6 (from 2012) cleanly on my machine, but it returned exactly the same error as 3.0.4. i then tried 2.0, which dates from 2005 -- same problem.

 

what version of bison are you using?

 

 

I have not used later versions of bison. But if I get some time I will try it.

you can get all releases here -
http://ftp.gnu.org/gnu/bison

you may want to get the latest-n-greatest even if you don't want to update the nsscomp source, then for no other reason than to see what it's actually generating, for amusement's (?) sake.

               
               

               
            

[Legacy_meaglyn]

               

2.7.1 I believe.  The simple fix is to look at the error routine which in 3.0 only takes the string argument. That gets past that error but then there are others which don't make much sense either. This will take a bit more work it looks like... 

               
               

               
            

[Legacy_meaglyn]

               

BTW, I assume you did a make clean before trying the other bison versions? If not then you've still building with the NscParser.hpp file generated by the 3.0 bison.

               
               

               
            

[Legacy_azaz1234]

               

2.7.1 I believe.

huh. i tried going all the way back to 2.0, got the same problem. maybe your bison is a particular release specific to the version of linux you're running on?

 

The simple fix is to look at the error routine which in 3.0 only takes the string argument. That gets past that error but then there are others which don't make much sense either. This will take a bit more work it looks like...

happy to help in any way i can.

 

BTW, I assume you did a make clean before trying the other bison versions? If not then you've still building with the NscParser.hpp file generated by the 3.0 bison.

yup.  make clean, then  make from the tld.

               
               

               
            

[Legacy_meaglyn]

               

Try a git pull.  You need to also remove the CMakeCache.txt file since that is not removed by make clean (should fix that I suppose). I'm not sure how you implemented your different versions but if the path to each was different then that would explain it not working. What's checked in now builds for me using either bison 2.7.1 or 3.0.4.  But again, you have to remove the cache file since that now contains the bison version and the related preprocessor macro. 

               
               

               
            

[Legacy_azaz1234]

               

that's brilliant. '>

compiler compiles cleanly, even w/3.0.4.

thanks so much for fixing that! '>  i'm looking fwd to getting some cleaner .nsc's now, & w/o all the funny stuff the other one was throwing my way.

 

cheers