Printable View
I'm not sure what you mean? I put the files the demo program needs in the folder and build everything at once. It compiles (finally, after many modifications) but fails to run. (My Visual Studio project zip file is above.) What's the point of a library and a demo program if they don't work?Quote:
Originally Posted by matsp
That is of course a darn good question, but it wouldn't be the first time in history that someone has written code that doesn't work on one or another system.
I'll see if I can make it work.
--
Mats
Thanks!
I've been wracking my brain over this all night yesterday and this morning. The sad thing is that all of this is *before* even starting the actual program we have to do haha
I downloaded the Windows Zip file, deleted the .exe and .obj files (don't delete the bison and flex executables tho', or you will have to re-extract them from the original zip file), and then "make -f MAKEFILE.MSC", and went to the logic directory and ran CNFDemo.exe - works just as the description says.
I will caveat this by saying that I am using a Visual Studio .Net that is a few years old - but I doubt that will make the difference.
Going back to the original post: #line is there to allow the compiler to generate debug information that relates to the original source. I doubt very much this would cause a problem in the execution of the code.
--
Mats
I'm guessing you are on linux? I don't have the make command or the nmake command.Quote:
Originally Posted by matsp
Yes, perhaps that is something specific to your visual studio version?
Make and nmake both give command not found errors when I try to use them.
No, Visual Studio does not run on Linux. It is Windows, alright.
Have you tried running a command prompt and doing "c:\program files\microsoft visual studio ...\vc...\bin\vcvars32.bat" to set up the environment variables for the visual studio tools. At least in my old version, I've got the nmake as part of visual studio - it may not be part of newer ones, as I can't run the later versions on my ancient OS.Quote:
Originally Posted by Paul22000
--
Mats
In visual studio, you should have a start menu thing that says something like "visual studio command prompt" that runs the batch file mats mentioned which sets your paths. Then you can do nmake.Quote:
Originally Posted by Paul22000
Ah, I see. I ran the bat file and then did nmake and it compiled. However, it looks like that's just a one-time thing. I still can't run within Visual Studio (so I can debug and do the project).Quote:
Originally Posted by matsp
Is there a way to get Visual Studio to be able to debug with this?
Mostly I'm just worried about the "no source code thing".
I have no way of debugging (or even starting the real program). Has anyone ever run into this before?
I have no idea. I got your zip thing and fired up Visual Studio and hit F7, and then F5, and got an error, I guess, with this call stack:Quote:
Originally Posted by Paul22000
and the little arrow pointing at the line if(yyn==0) goto yyerrlab. It looks like source code to me. Edit: Well, I don't know. It did take me to disassembly, rather than code. But there is a yyerrlab label in that same function -- why it didn't take me there I don't know. But that's where I would expect to go. Note that I didn't step through everything to see what was going on to cause that error in the first place.Code:> cnf_logic_converter.exe!yyparse() Line 640 C++
cnf_logic_converter.exe!parse(const char * str=0x00429914) Line 29 C++
cnf_logic_converter.exe!main(int argc=1, char * * argv=0x00036688) Line 24 + 0xa bytes C++
cnf_logic_converter.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C
cnf_logic_converter.exe!mainCRTStartup() Line 399 C
Yeah, I don't know, that YY sh!t is causing all hell to break loose. I'm trying to just get rid of it now, by seeing if I can make my own "parse" function instead of the one getting called from main. That YY bison crap is absolute SH!T.
Yes, of course, Bison has only survived the last 15 years by people who don't know as much as you... You know, guys like Larry Wall who writes Perl, and the guys behind gcc - they obviously don't know how to write a parser proberly, so they use sh!t that doesn't work....Quote:
Originally Posted by Paul22000
Your code doesn't work when I compile it with my compiler - the original code WORKS. Have you considered that there may be some difference?
I tried looking at your diffs, but I couldn't make out anything that actually matters - probably because it's getting late.
--
Mats
Sorry, I'm getting frustrated with this. I did not mean to offend. =\Quote:
Originally Posted by matsp
Yes, I don't think I made any relevant changes. Did you get it to debug by any chance? Perhaps Bison just doesn't work with debuggers?Quote:
Your code doesn't work when I compile it with my compiler - the original code WORKS. Have you considered that there may be some difference?
I tried looking at your diffs, but I couldn't make out anything that actually matters - probably because it's getting late.
Sorry again, I've got a crapton on my plate for this week, and it's only Monday, oy...
Alright, pretty detailed question. This code makes no sense whatsoever, I'm going crazy here :(
Code:PropNode* parse( const char* str )
{
YY_BUFFER_STATE bstate = yy_scan_string( str );
// How does str get attached to logicStatements?
logicStatements = new std::list<PropNode*>();
yyparse();
PropNode* node;
if( logicStatements->size() == 0 ) // How does logicStatements ever become non-empty??
node = 0;
else
node = *(logicStatements->begin());
delete logicStatements;
logicStatements = 0;
yy_delete_buffer(bstate);
return node;
}