FWD » Core Development » Conversion Tools

I looked into this issue and what I've found is:
In ClearStream mread, at the end

-      if (sym.size() == 1 && fspre.getFileName().equals("/"))
+      if (sym.size() == 2 && fspre.getFileName().equals("/"))
       {
          return super.read();
       }
       else
       {
+         super.unread(' ');
          clearCount++;
-         return ' ';
+         return '\n';
       }
    }

This change fixes all the harness EOF errors, but only if we dont have a NL present at any of the files(also include files)

What happens in OE (and FWD) when there is an NL present at EOF in a file? It sounds like the fix needs some work. Also, please put the changes into a branch.

I will explain the issue better after some analysis:
When sym.size() = = 2 (sym being the "stack call" of the files) it means that we are in the rootfile, meaning that when preprocessing a simple file, we shouldn't append a ' '.
In the code from trunk that size is checked for value 1, thus having all tests appending at the EOF a ' '.
When sym has a bigger size (meaning that the rootfile included other .i files) it has to append this ' ' and a NL.

I have taken basic.p as example.
Let's say we replace the ' ' at the end of mread with L, this is the output in FWD:

MESSAGE "Hello World!".
L

MESSAGE "This is something else, isn't it?".
L
L

Now if we preprocess in OE:

MESSAGE "Hello World!".
L

MESSAGE "This is something else, isn't it?".
L

Now doing the same test on named_args_.._03.p

display "1" label "~{name1}" 
        "2" label "~{name2}" 
        "1"      label "~{1}" 
        "2"      label "~{2}" 
        ""      label "~{3}" 
        ""      label "~{4}" 
        ""      label "~{5}" 
        ""      label "~{6}" 
        ""      label "~{7}" 
        "1 2"      label "~{*}" 
        '&name1="1" &name2="2"'     label "~{* (named)}".
        LL

display "1" label "~{name1}" 
        "2" label "~{name2}" 
        "1"      label "~{1}" 
        "2"      label "~{2}" 
        ""      label "~{3}" 
        ""      label "~{4}" 
        ""      label "~{5}" 
        ""      label "~{6}" 
        ""      label "~{7}" 
        "1 2"      label "~{*}" 
        '&name1="1" &name2="2"'     label "~{* (named)}".

L

So basic.p has 1 include file and inside that is another include file(2 per total) vs named_args.. which has only one include.
Now what is wierd is that in FWD basic.p the 2 L's at the end are on different lines, not the same line, like in the example above.
I am looking into why this is the case, why these two are on different lines.
So having a single value for L for those 2 cases it's not possible since the L in the 2nd testcase is right next to the first L.

OK, the bottom line here: please keep going with the fixes. The FWD output should match OE output exactly.

I have created 9905a with rev 15868 with my changes.
I have added the following change

-      if (sym.size() == 1 && fspre.getFileName().equals("/"))
+      if (sym.size() == 2 && fspre.getFileName().equals("/"))
       {
          return super.read();
       }
       else
       {
-         clearCount++;
-         return ' ';
+         super.unread(' ');
+         clearCount += 2;
+         return '\n';
       }

The issue i addressed earlier about the random NL that appear:
When we have a .i file that we include, in OE if it has a empty NL at the end, it ignores it and follows the convention of '\n ' being appended at the end.
In FWD the include file is copied as is, meaning that we have that last empty NL.

All changes have been moved to 6859b.