Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[strainer]

Thanks, I count myself lucky if I get away with being called "etymological picky". That idea of a stack sounds like a well designed heap management system. I do also have a load of files lying around called blast.html/js/... short for blastosphere which connects in with the origins of matrix.

Also seems like "const and let" should clearly have been name "let and mut" but at this stage Ive got the feeling I should let it be.

[MorleyDev]

It's partially historical. Lots of browsers were already supporting const as an unofficial extension to the language, so they just formalised it as a part of the language.

JavaScript is up there with C++ in terms of being shackled with a lot of language features that exist for historical reasons.

Even it's name is a result of historical weirdness, the language having nothing in common with Java.

[Parsely]

I'm really frustrated with this C++ program.

So I built my program by debugging in the terminal, I've never done this before. I ran into a problem I can't solve by inserting print statements in my code, so I fell back on an IDE and set up my project in Netbeans. The problem is, my program is intended to be run in the terminal, and I pass the input by redirecting it in:

Code: [Select]

./a.out << input.txt
When I'm in Netbeans though, I can't do that. I don't want to refactor my code to work with an fstream object. Please, for the love of god, how can I use an IDE with breakpoints without having to refactor my code? In the meantime I guess I'll try and learn to use breakpoints in the terminal, ugh...

I can't even see how intractable my problem is yet, because it's not creating any output (which is why printf() failed me). I'll leave a zip with my code in it here after I remove all the human names from it, I wouldn't mind some help getting it to output correctly. It's a recursive descent parser

[bloop_bleep]

Eclipse with C++ is a bit heavy and a bit invasive, but the upside of that is you can specify a run configuration that takes standard input from a file, and a bazillion other options.

[Parsely]

So, I worked out the earlier issue I described. I was using "<<" instead of "<" to redirect input. I'm dummy brain. I even did this correctly earlier to test the parser. Anyway, that let me make a bunch of progress and now I'm getting actual output! Still problems though

I've already tested the parser and it consumed all the input with no errors so I'm confident that that works. The new problem is that the statements are being executed in reverse order. This is my first time handling a vector in C++ and that's the structure the statements are stored in so that probably has something to do with it. I sense something is wrong with the way I'm inserting statements into the vector and not with my for loop. Once I fix that, I think I have a problem with the way I'm accessing or storing the operands/constants/left hand side variable, this is the most intimidating issue. I'm also vaguely suspicious of the memory vector where my constants and variable values are stored

Code: (sample basic input) [Select]

MAIN
X = 1;
Y = X;
OUTPUT X;
OUTPUT Y;
1 2 3 18 19

Code: (expected output) [Select]

1 1

Code: (sample basic input) [Select]

MAIN
INPUT X;
INPUT Y;
X = X + Y;
Y = X+Y;
OUTPUT X;
OUTPUT Y;
3 7 18 19

Code: (expected output) [Select]

10 17
The INPUT statements consume one integer token, from left to right, and assign it. Any extra input is discarded

I don't know EBNF notation, but here's the grammar reference that I used to write the parser.

Spoiler: Grammar (click to show/hide)

Spoiler: Read this if you are going to dive into the source (click to show/hide)

The file I'm doing all the work in is parser.cc. lexer.cc and inputbuf.cc contain utilities and they work great, no issues there so don't bother reading them too closely except for some key info like the definition of Token. compile.sh is the shell script I use to compile, you'll see I'm using std c++11.

I have a function for parsing the left hand side of each grammar rule.

The stmt struct is what I'm using to store the different parts of statements, it also handles basic arithmetic expressions with two operands. Ignore the struct stmt * next pointer, that's left over from when I was thinking about implementing my own linked list.

Global variables:
unordered_map sym_ map is for mapping the algebraic variables onto an address for its value in mem_vec. Lookup() interacts with this
mem_vec is a vector for storing values of symbol variables and constants. No duplicate values. Lookup() interacts with this
inputs_vec is a vector just for storing all the inputs, inputs are all the lines AFTER
list<stmt> stmt_list is the list containing all the statements, these are meant to be executed in order in programExecution()
unordered_map<string, list<stmt> > procStmt_map; // Map for lists of procedures

Yet to be implemented is the procedure and do statement functions. Once I can execute a statement list properly those ones follow pretty cleanly since all you're doing is storing a statement list for each procedure, and executing it when it's invoked. Same deal with do except you loop

[Parsely]

Line 195. You're pushing to the front of the vector each time, meaning that the last statement is the first element of the vector. You then read it from beginning to end, which is, hence, in reverse order.

Thanks, just changed push_front to push_back and that fixed that. So now we're executing in the right order. Two problems now though:
- I tested with the input below, it returns 8 when we expect 5. Also, the lines 520-523 commented "TEST STATEMENT" in the switch statement aren't doing what I expect them to and printing out the integer values at those locations in the memory vector, what gives? Am I accessing the vector incorrectly, or am I messing up when I assign them values? It doesn't always print the strings either... Also, reading that statement now it doesn't really make sense what I'm trying to print, I should print the actual character symbol representing the LHS and not the value of the LHS, but still

Code: (input returns 8, expected 5) [Select]

MAIN
INPUT w;
x = w+1;
y = w+2;
z = x+y;
OUTPUT z;
1 4 17
- I tested that first sample input up above and it looks like my code has a bug somewhere in parseExpr(), it throws a syntax error while it's trying to consume "X = 1;", I didn't detect this error before because I was only testing with statements that have two operands

[Reelya]

General rule of thumb is that you can never have enough debug prints. Dump the entire set of variables you're storing after each instruction is executed, then look for discrepancies.

How I would do this is to break parsing up using an "eval" function that can be called recursively.

How this would work at the base case, is that if eval sees just a number, it returns that number. If it sees just a variable name, it looks up the variable and returns its numerical value.

At the next level, if eval see "(" it looks ahead for the (matching) ")" symbol, then calls eval again on the inner contents. Doing it this way, recursively, means that you get accurate brackets handling for free, basically.

I think you'd need two passes for the last bit, one pass resolves all variable names (probably by calling eval again, because that reduces redundant code), * and / operations and a final pass to resolve all + and - operations. Since everything that's inside brackets is already dealt with by splitting out that bit of the string and calling "eval" again for it, you don't need to worry about the complexity of brackets.

It's a little more work, but this is how you might make a simple general expression parser that's more flexible.

[Parsely]

General rule of thumb is that you can never have enough debug prints. Dump the entire set of variables you're storing after each instruction is executed, then look for discrepancies.

I described my issues doing that:

Also, the lines 520-523 commented "TEST STATEMENT" in the switch statement aren't doing what I expect them to and printing out the integer values at those locations in the memory vector, what gives? Am I accessing the vector incorrectly, or am I messing up when I assign them values? It doesn't always print the strings either... Also, reading that statement now it doesn't really make sense what I'm trying to print, I should print the actual character symbol representing the LHS and not the value of the LHS, but still

Spoiler: This is where I'm executing statements and trying to debug in my description above (click to show/hide)

Code: [Select]

void Parser::executeProgram(list<stmt> statement_list)
{
struct stmt pc; // The statement being operated on
int nextInput = 0; // Index for inputs vector

for (list<stmt>::iterator it = statement_list.begin(); it != statement_list.end(); ++it) { // For each statement in the list
pc = *it; // The stmt to operate on, get it by dereferencing the iterator

/*** BEGIN TEST BLOCK ***/
cout << "stmt: {stmtType: ";
switch (pc.stmtType) { // ASSIGN 1, INPUT 2, OUTPUT 3, INVOKE 4, DO 5
case 1: // ASSIGN
cout << "assign";
break;
case 2: // INPUT
cout << "input";
break;
case 3: // OUTPUT
cout << "output";
break;
case 4: // INVOKE
cout << "invoke";
break;
case 5: // DO
cout << "do";
break;
}

cout << ", operatorType: ";
switch(pc.operatorType) {
case 1: // PLUS
cout << "plus";
break;
case 2: // MINUS
cout << "minus";
break;
case 3: // DIV
cout << "div";
break;
case 4: // MULT
cout << "mult";
break;
case 0: // NOOP
cout << "noop";
break;
}

cout << "}\n";
//pc.LHS; // memory address of LHS
//pc.op1; // address of the first operand
//pc.op2; // address of the second operand
/*** END TEST BLOCK ***/

                // Execute a statement based on statement type
switch (pc.stmtType) {
case 1: // ASSIGN
switch(pc.operatorType) {
case 1: // PLUS
cout << mem_vec[pc.LHS]; // TEST STATEMENT
cout << " = " + mem_vec[pc.op1]; // TEST STATEMENT
cout << " + " + mem_vec[pc.op2]; // TEST STATEMENT
cout << "\n"; // TEST STATEMENT
mem_vec[pc.LHS] = mem_vec[pc.op1] + mem_vec[pc.op2];
break;
case 2: // MINUS
mem_vec[pc.LHS] = mem_vec[pc.op1] - mem_vec[pc.op2];
break;
case 3: // DIV
mem_vec[pc.LHS] = mem_vec[pc.op1] / mem_vec[pc.op2];
break;
case 4: // MULT
mem_vec[pc.LHS] = mem_vec[pc.op1] * mem_vec[pc.op2];
break;
case 0: // NOOP
mem_vec[pc.LHS] = mem_vec[pc.op1];
break;
}
case 2: // INPUT
mem_vec[pc.op1] = inputs_vec[nextInput];
nextInput++;
break;
case 3: // OUTPUT
cout << "output: ";
cout << mem_vec[pc.op1] << "\n";
break;
case 4: // INVOKE
// do stuff
break;
case 5: // DO
// do stuff
break;
}
}
}

This is where the action is for the aforementioned input, since this is where we're actually executing an addition statement. In the code below, the first three lines are where I'm printing out. I changed this a little from what is in the .rar because my debug statements didn't make sense semantically, this represents what I'm running now

Code: [Select]

cout << "LHS before execution = " + mem_vec[pc.LHS]; // TEST STATEMENT
cout << "\n"; // TEST STATEMENT
cout << "expect LHS = " + mem_vec[pc.op1]; // TEST STATEMENT
cout << " + " + mem_vec[pc.op2]; // TEST STATEMENT
cout << "\n"; // TEST STATEMENT
mem_vec[pc.LHS] = mem_vec[pc.op1] + mem_vec[pc.op2]; // Execute addition
cout << "LHS after execution = " + mem_vec[pc.LHS]; // TEST STATEMENT
But like I said, this doesn't print as expected! Some of the strings before the mem_vec references are missing characters, and in some places no integer is printed at all! I feel like this is an issue converting the integers to string or something, maybe I should do the conversion explicitly first? I'll screenshot my output once I have a chance so you can see what I mean

Edit: OK you edited in a bunch of stuff while I was typing. Need a minute to read

Edit2: I'm at the stage where I've actually already consumed all of the input and I've stored all of the tokens and ALL the syntax checks out perfectly (small exception where an expression only has one operand as in "X = 5" but "X = 5 + X" is stored fine with no syntax error). My parser is able to check the grammar perfectly. The problem I'm having is, these statements are arithmetic statements, and once I parse them I am storing them as a struct so I can execute them like a program, this is where my problem is happening

[Reelya]

What I edited in is unrelated to your current problem, it's just a different approach to parsing to the one you're using.

But my point about the debugs prints, is that you're not printing ALL your variables each time anything happens. You're just printing what you expect to change. If it's not acting as expected, you're probably doing something unexpected. Doing a complete memory dump of ALL variables, even ones that you don't expect to be affected may trigger an "aha" moment or give you leads towards where the error is. Do a literal entire "stack dump" after literally every little change, and see where something unexpected occurs. Just write a function which does a "core dump" of your entire system, and do one of those after each instruction, see where things go off the rails. For example, input 1 to "w", then dump all variables, then set "X=W+0", then dump all variables again. And so on, with different inputs and amounts.

EDIT: Note how you said bits of some strings are missing. That may indicate that your tokenizer isn't actually breaking the tokens at the right places, so it's something to check. Also, cout should always correctly output ints as ints, since it uses operator overloading to always get the correct conversion, thanks to OO. The only issue could be if you're storing something as a string and you didn't properly parse it in the first place.

[Parsely]

But the parts of strings that are missing when I print are the literals I'm writing in the cout statement

Code: (input) [Select]

cout << "LHS before execution = " + mem_vec[pc.LHS]; // TEST STATEMENT
cout << "\n"; // TEST STATEMENT
cout << "expect LHS = " + mem_vec[pc.op1]; // TEST STATEMENT
cout << " + " + mem_vec[pc.op2]; // TEST STATEMENT
cout << "\n"; // TEST STATEMENT
mem_vec[pc.LHS] = mem_vec[pc.op1] + mem_vec[pc.op2]; // Execute addition
cout << "LHS after execution = " + mem_vec[pc.LHS]; // TEST STATEMENT
cout << "\n\n"; // TEST STATEMENT
Output:


That doesn't have anything to do with my parsing. I'm not storing any string in my vector, mem_vec only stores the integer values of the constants and variables in the expressions. The lexer is working just fine

The core dump function is a good point though, I see what you mean, I'll implement that later if I can just get my mem_vec to actually output integers

E: OK, I think something is wrong when I'm setting the values for LHS, op1, and op2, that's the only thing that would explain what's going on here, and I would have known that sooner if I had just printed out everything

E2: OK, the problem is definitely in parseExpr() and lookup(). When I print the lexeme (string value of the token) in parseExpr() it's giving me what I expect, but the int value is empty when I try to get that after calling lookup() on that token, so I think lookup() is failing to store and/or retrieve the address correctly. Lookup() is supposed to store new algebraic symbols in an unordered map in a symbol-address pair, where the address is the index to a corresponding spot in the memory vector so I can reserve a position to store that symbol's value there. Constants are also stored in the mem_vec  by lookup() when they're encountered in an expression. Lookup() searches for the constant in the mem_vec and the symbol in the unordered map before it tries to store them.

E3: Fixed this bug :sunglasses:

- I tested that first sample input up above and it looks like my code has a bug somewhere in parseExpr(), it throws a syntax error while it's trying to consume "X = 1;", I didn't detect this error before because I was only testing with statements that have two operands

[strainer]

mem_vec's values are clearly not converting to string properly for cout.

Parsely, I do wonder at how you get people diving into your zip files and following the fast shifting trains of thought and focus, with no obvious recognition of the extra time and attention spent by those do unpack things and make suggestions. Mere mortals have to carefully compose their problem and make it accessible in code snippets or a repo, and to somewhat limit inquiries to a economical number of pressing issues. But I guess this is not stack-overflow and you may in practice be hosting some kind of adventure game

[Parsely]

mem_vec's values are clearly not converting to string properly for cout.

OK, I'll look into this soon.

E: mem_vec is a vector of integers, so shouldn't cout automatically convert the integer to a string, or else fail to compile?
E2: Using to_string() made my debug statements work, thanks! I guess mixing literals when using cout is not a good idea, and I should always convert them explicitly

Parsely, I do wonder at how you get people diving into your zip files and following the fast shifting trains of thought and focus, with no obvious recognition of the extra time and attention spent by those do unpack things and make suggestions. Mere mortals have to carefully compose their problem and make it accessible in code snippets or a repo, and to somewhat limit inquiries to a economical number of pressing issues. But I guess this is not stack-overflow and you may in practice be hosting some kind of adventure game

Sorry, I hear you. No one owes me anything, I don't expect anyone to understand my code easily, and therefore I do really appreciate the amount of effort that Reelya and Ispil have put into helping me out with this problem, it's very helpful and I value that. I'll try to be more clear and concise in the future.

[strainer]

mem_vec is a vector of integers, so shouldn't cout automatically convert the integer to a string, or else fail to compile?

As much as I can recall, string and char conversions in c++ are not always what they seem and possibility cout itself has its own idiosyncracies, eg. maybe it can't tell they are ints so I would try casting to int or things like "std::to_string((int)mem_vec[key])" until something works. I do often find c++ like an old text based adventure game trying find the one true way of saying "poke open trapdoor with broom handle"

[Parsely]

Lol yeah, I agree on that one. I noticed I actually had some compiler errors when trying to do things like:

Code: [Select]

cout << "some string literal" + integer1 + "some other string literal"Let me try and reproduce the error just for funsies

Fakeedit:
There it is

Spoiler: cout does not like mixing literals (click to show/hide)

[bloop_bleep]

Yah, make one a string first before concatenating.