Open dmcc opened 8 years ago
This is from the move to slf4j for logging. In the next release, this will be worked around such that CoreNLP uses Redwood unless slf4j is in the classpath -- should be transparent for a Java user, but not crash if you're missing libraries.
The other option is to use the new CoreNLP Server to get output as protocol buffers, and not have to care at all about what the Java process does on its own time.
Thanks for the information, @gangeli! If the next slf4j-less release is not too far out, I'm inclined to skip making 3.6.0 work out of the box since it would involve a lot of CoreNLP-version-specific code to download and install slf4j (and/or Maven integration which is a dependency I'd rather not add since PyStanfordDependencies's goal is to have everything more or less handled in Python).
The server idea is interesting -- it would be nice to add it as a possible PyStanfordDependencies backend (though users would still need to obtain all the necessary jar files).
Is there a (fairly simple) workaround for this issue?
Oh, I've already cut slf4j out. You should be able to run the GitHub version of the code without slf4j in your classpath, and it shouldn't crash.
On Wed, Apr 13, 2016 at 12:32 PM, melodyju notifications@github.com wrote:
Is there a (fairly simple) workaround for this issue?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/dmcc/PyStanfordDependencies/issues/20#issuecomment-209613557
Thanks @gangeli. In that case, probably the easiest workaround (assuming you don't need exactly version 3.6.0 and are okay with an unreleased version) is to check out the latest CoreNLP version from GitHub, build it (looks like it will build with ant or gradle), and use that jar as your jar_filename
.
The next easiest option is to hack this line to include the path to a downloaded jar of slf4j. This should allow you to use version 3.6.0. We could add an option to make it easier to pass extra jars and/or command line flags for SubprocessBackend, but I'm hoping this type of case doesn't show up that much.
Oops; I completely ignored the context of the ticket... Yes, go with @dmcc 's workaround, until we release 3.7.0 (which I'm pushing to make as soon as possible, but may take until the summer).
Could it be that this bug is still present?
Quite possibly, unfortunately. Are you using 3.6.0 or 3.7.0? (I don't think we ever really resolved it for 3.6.0, not sure if it's still a problem in 3.7.0)
Well, I switched to 3.5.2 for now and it appears, that 3.7.0 is currently not available in the repository: http://repo1.maven.org/maven2/edu/stanford/nlp/stanford-corenlp/
Heh; clearly I was too optimistic about 3.7.0's release date. But, this should I hope be resolved in 3.7.0. It should be on maven soon.
CoreNLP version 3.6.0 has (at least) two changes which break PyStanfordDependencies:
stemStaticSynchronized
was renamed tostemStatic
SubprocessBackend
conversion tests:(comes from a command line like this:
java -ea -cp /path/to/stanford-corenlp-3.6.0.jar edu.stanford.nlp.trees.EnglishGrammaticalStructure -basic -treeFile treefile -keepPunct -originalDependencies
)@gangeli, is
slf4j
required to run CoreNLP 3.6.0?