Issue 6: Assembler parser upcases lower case string
Project Member Reported by h.paul.h...@gmail.com, Feb 18, 2014
What steps will reproduce the problem?
1.
Msg       db  "Hello World!"
2.
3.

What is the expected output? What do you see instead?
Assembler parser upcases all these letters.  Thus, a program that could output the message produces HELLO WORLD!


Please use labels and text to provide additional information.


Feb 18, 2014
Project Member #1 vance.mo...@gmail.com
This one is going to be difficult, we call toUpperCase() on every token during passOne.
I believe we discussed this with you and at the time it was deemed to be a valid approach (can't imagine making that decision without your approval, but it is what it is now..).

Problem line is located at:
Class: edu.wtamu.wtcs.client.presenter.Assembler
Method: private void passOne(String text)
Line #88

	private void passOne(String text) {
		String[] lines = text.split("\n");
		int lineCount = lines.length;
		codes = new String[lineCount];
		labels = new String[lineCount];
		// tokens[0] has code
		// tokens[1] has comments
		String[] tokens;
		int i;
		for (i = 0; i < lineCount; i++) { // Removes comments
				tokens = lines[i].split(";");
				if (!lines[i].trim().equals(";")) {
					Log.info("PassOne: Line " + (i + 1) + " code is: " + tokens[0]);
					codes[i] = tokens[0].trim().toUpperCase();
				} else {
					codes[i] = "";
				}
		}

Mar 8, 2014
Project Member #2 brettdaw...@gmail.com
I don't know if this will be that bad. I think we will just have to expect both types of input for code, i.e. add and ADD. This should get rid of the necessity of uppercasing the tokens. That's how I handled my passTwo for Karel for Android.
Mar 8, 2014
Project Member #3 h.paul.h...@gmail.com
Case insensitivity is a significant plus to current implementation.   Don't want to throw out baby with bath water.  
-- Sent from my Samsung S 3 phone with K-@ Mail. Please excuse my brevity.
Mar 9, 2014
Project Member #4 tia...@gmail.com
Just from a cursory look at the Assembler it looks like we could refactor the nested If/Else tree into a single or nested switch that did the UpperCasing as it gathered the argument from the tokens array, so that the original string would retain its casing.  I am probably missing some subtle trouble down the road by doing it this way though; thoughts?
Mar 9, 2014
Project Member #5 tia...@gmail.com
Might be even simpler to only add the UpperCase() call to line 120 of Assembler if we wanted to avoid re-writing functional code.  This should preserve both the original string and current logic; though we might need to find other places down the line that expect the codes array to be uppercase.