Well, I have played for a while with the wordcount.fan example app. My idea was to change it to be in a more functional style, so the first thing I had done was to replace this code

file.eachLine |line|
  {
    "// skip empty lines"
    if (line.trim.isEmpty) return

    "// split and trim on whitespace into words"
    words := line.split

    "// count each one"
    words.each |word| { wordCounts[word] += 1 }
  }

with this:

file .readAllLines .exclude { it.trim.isEmpty } .split .each { wordCounts[it] += 1 }

But, before I came to the previous solution I had went through the process of trials&errors. Some of those trials work correctly in F4 although they are obviously wrong, e.g.:

file readAllLines exclude { it.trim.isEmpty } split each { wordCounts[it] += 1 }

or even this one:

file readAllLines exclude { it.trim.isEmpty } each { wordCounts[it] += 1 }

In both cases F4 argues with "Expected expression statement", meaning I have to put dots before method calls, but despite that warning, when I hit run, it runs without errors and produces correct result. In the second example I have even left the split method call and it still works. It won't run if I run this example as a script from the console but in F4 it runs without problems. Does F4 accidentally uses some kind of cash or something else I can't be sure but this situation confuses me a lot.

If I am not mistaken, there was a similar issue posted a couple of months ago. It was due to the fact that F4 doesn't remove the previously compiled pod upon compilation fail so it will still run the last successful compilation.

As far as I remember, it was solved by removing it manually in the build.fan.

You need to pay attention to the errors in the compile window and ignore the run results if compile failed - they will be the old code.

Or, quite tricky, you change the build script to run only if compile succeeds by overriding the method. Posted here some while ago I think by me.

@tomcl

You need to pay attention to the errors in the compile window and ignore the run results if compile failed - they will be the old code.

No, it won't resolve the issue. E.g. if I add the dots to the following code:

file readAllLines exclude { it.trim.isEmpty } each { wordCounts[it] += 1 }

making this:

file .readAllLines .exclude { it.trim.isEmpty } .each { wordCounts[it] += 1 }

it will make compile window happy. The app will compile without errors and I'll get the right output (probably from the cache). But the problem still exists as I'm aware that this code is not correct. It misses split method call. The right code is the following one:

file .readAllLines .exclude { it.trim.isEmpty } .split .each { wordCounts[it] += 1 }

@tomcl

Or, quite tricky, you change the build script to run only if compile succeeds by overriding the method. Posted here some while ago I think by me.

Will try to find it.

When you compile the code either it succeeds or not? And if it succeeds then the build stuff will think it succeeds, so I guess changing it will not help.

The compile window pre-compilation is of course not accurate - it must work on partial information. But when you start a build you should get errors indicated whenever the build fails - and hence most unfortunately the last working build gets executed.

I'm not aware of a build that succeeds but does not overwrite the old pod by a new one - so maybe something else is happening here?

Note that I'm not Eclipse user so maybe I use it in a wrong way. Now I have commented out the following line:

//file .readAllLines .exclude { it.trim.isEmpty } .split .each { wordCounts[it] += 1 }

Nothing happens. I still get the correct results although it is impossible. F4 pulls results from some cache and I don't know where it is. Tried Build-Clean and nothing happened. It still runs correctly. At the end I have manually deleted all the structure bin/fan/lib/fan/FantomExamples.pod and now F4 gives me an error:

[20:41:48 07-Sep-14] [err] [pathenv] Cannot parse path: C:\Users\rasa\f4workspace\FantomExamples\bin\fan
  sys::ArgErr: Invalid Uri scheme for local file: c:\Users\rasa\f4workspace\FantomExamples\bin\fan/
    fan.sys.LocalFile.uriToFile (LocalFile.java:64)
    fan.sys.File.make (File.java:26)
    util::PathEnv.parsePath (PathEnv.fan:47)
    fan.sys.List.each (List.java:588)
    util::PathEnv.parsePath (PathEnv.fan:43)
    ...

I don't know how to make pod again but the restore it from the Recycle Bean?

What errors do you see in the Problems View?

The Problems View looks like this:

But yours will have different errors / problems in it.

There's no errors in Problems View. It is empty.

I've just found what was the problem. I've been using JRE 8 and after switching to JRE 7 everything got the way it should be. F4 reported in the Error Log:

eclipse.buildId=unknown java.version=1.8.0_11 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86

Warning Sun Sep 07 21:48:00 CEST 2014 The Java indexing could not index C:/Program Files/Java/jre8/lib/ext/nashorn.jar|jdk/nashorn/internal/objects/NativeFloat64Array$Constructor.class. This .class file doesn't follow the class file format specification. Please report this issue against the .class file vendor

Didn't take this warning seriously because of famous Java backward compatibility and also because nashorn is a JavaScript runtime inside JRE, but you see the result.

Ah, I always use JDK 1.6 - I've never needed a version of Java that's more bloated than that.

Didn't take this warning seriously because of famous Java backward compatibility and also because nashorn is a JavaScript runtime inside JRE, but you see the result.

You're speaking about *forward* compatibility, i.e., the capability of an old (1.7) version to work with a new format (1.8). Forward compatibility can be expected for things like HTML, where the output simply looks different and possibly ugly and that's all.

Expecting this for a binary format of program code makes no sense (unless you've used -target 1.7). It would be a disaster to even try to interpret such code (security issues and whatever).

Yes, I was in doubt whether to write backward or forward compatibility, but since I had used latest JRE to run the code written in earlier version, I put backward. Note that one of the most prominent JRE features is backward compatibility, the main reason why Java is so limited in adding new features.

Described problem was not related to JRE 8 but to F4. I have tested the script out of the F4 IDE and Fantom compiler v1.0.66 behaved as expected despite the fact that the default JRE on my comp is v1.8.0_11.