updated to use updated Annotator API, which accommodates lazy initialization

had to change constructor signatures, push some constructor params into ResourceManager argument updated tests to conform to new multi-sentence DummyTextAnnotation TODO: verify that nom is behaving correctly (only finds predicates in first sentence) @christod there is no rush on this -- I've deployed a snapshot for use with a snapshot of pipeline for my own purposes.

Added 2 commits:

• 4a60b49f - added test to try to monitor memory use with repeated instantiation of local SRL objects
• 662afdd5 - updated to check for/add CLAUSE_STANFORD view before trying to apply SRL (otherw…

Reassigned to @khashab2

Added 1 commit:

• 2a98e89a - updated icu dependency to non-snapshot

This compiles and runs just fine on our group servers. One possibility for the failure is the circular dependency that this project creates by using the pipeline in a preprocessing module. We could replace this with a locally-build pipeline and remove the circularity.

The problems here are:

• replication of caching pipeline code
• replication of the stanford dependency/constituency parser handler, the latter of which will require an exclusions entry in the pipeline OR relocation to the SRL package @khashab2 (and @christod when you are feeling well enough): any thoughts?

I have two suggestions (I'm using Dragon NaturallySpeaking voice dictation):

1. We can move this code to the complete Cogcomp NLP super project. This way we can avoid the circular dependency on the pipeline.
2. We can use our own dependency parser once Mengxiong is finished with it

I'm fine with moving this this super-project; i'm just worrying about memory issues with Semaphore tests. If the SRL tests need more than 4G memory Semaphore would get angry all the time (unless of course we purchase a non-free account).

And this level of circularity won't be resolved by moving to super-project (unless EVERYTHING exist in one single project which probably is not desirable). Although it is undeniable that having things in one single multi-module project would make such wide changes easier to handle, because we apply the changes to all the projects at the same time.

For now, I say

• ignore the CI failure in SRL project, change the pipeline version to 0.1.24 (which hasn't been deployed yet), and deploy it.
• Then let's update the current PR for the pipeline with the new SRL, and merge/deploy it.
• Then restarting the SRL CI should pass (if not, we should fix it. )

I'm fine with Daniel's suggestion. Let me know if there's anything I can do.

Added 1 commit:

• 357fd39a - updated pipeline dependency

Status changed to merged

mentioned in commit f5b0df01

OK. Going ahead with Daniel's proposal.