Skip to content
Jamie Willis edited this page Jan 29, 2021 · 7 revisions

Frequently Asked Questions

TODO

Frequently Encountered Problems

When I try and use many, skipMany, lift1, lift2, or lift3 I get a "Cannot resolve overloaded method" error

This is a problem with the transitionary API between Parsley 2 and Parsley 3. You need to explicitly hide the deprecated values from parsley.Parsley or import explicitly what you need:

// This would be ok, if you only needed the operators and pure
import parsley.Parsley.{LazyParsley, pure}
import parsley.combinator.many

// This is also ok, but may give you a deprecation warning about having included
// the deprecated `many`: this is probably an issue with scalac!
import parsley.Parsley.{many => _, skipMany => _, /*etc*/, _}
import parsley.combinator.{many, skipMany}

I can't build Parsley on Windows!

This is also a problem with the transitionary API. The deprecated Implicits.class and implicits.class are indisinguishable on Windows! The fix is to mark the directory where the classes are generated as case-sensitive, which can be done by opening a PowerShell terminal in the bin directory and issuing the command: fsutil.exe file setCaseSensitiveInfo . enable. This issue does not affect the use of Parsley on windows, as jars are still case sensitive and is built in a linux environment

I have problems when using Parsley with sbt-assembly on Windows!

This is actually the same problem as above: when sbt-assembly builds your jar, it first unpacks the dependencies into a folder ready to unpack. Again, on Windows this is catastrophic! The solution is similar to before, but a tiny bit more involved this time.

The first step is to make a folder called assembly in your project's base directory (where the build.sbt lives). Then you need to use the steps above to mark it as case sensitive. You can check you have done this properly with fsutil.exe file queryCaseSensitiveInfo assembly with a terminal cd'd into your base directory.

Now you just need to point sbt-assembly at that directory to use when it is doing the unpacking and repacking. This can be done by adding the following to the project settings:

assemblyOption in assembly := (assemblyOption in assembly).value.copy(
        assemblyDirectory = baseDirectory.value / "assembly"
    )

This tells the plugin that it should use the assembly folder to perform its work: and, conveniently, we've marked that as case-sensitive. Once the jar has been assembled, it will work fine no matter where it is placed.