Simple Eidos in Habitus

[maxaalexeeva]

Hi @kwalcock,

I am trying to use SimpleEidos again (like described here #92) and am getting the error pasted below. I see that it wants something related to glove embeddings defined, but don't know where that should happen. One major difference I see between the time we used simple eidos last time and now is the version of processors. I checked, and with procVer=8.4.7 the example() you have in #92 ran through once. Other times. I keep getting a different error (something about stannford nlp util metal class and time expressions).

Do you happen to know what this is about? Thanks!

[info] running org.clulab.habitus.interviews.SimpleEidosInterviewsReader 
[dynet] Loading DyNet from /tmp/libdynet_swig-3619538635534874860.so...
[dynet] random seed: 2522620396
[dynet] allocating memory: 512MB
[dynet] memory allocation done.
Apr 25, 2022 8:38:40 AM de.jollyday.util.ClassLoadingUtil loadClass
WARNING: Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: edu.stanford.nlp.time.JollyDayHolidays$MyXMLManager
Apr 25, 2022 8:38:40 AM de.jollyday.util.ClassLoadingUtil loadClass
WARNING: Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: de.jollyday.datasource.impl.XmlFileDataSource
Apr 25, 2022 8:38:40 AM de.jollyday.util.XMLUtil unmarshallConfiguration
WARNING: Could not create JAXB context using the current threads context classloader. Falling back to ObjectFactory class classloader.
2022-04-25 08:38:41.313499: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA
java.lang.ExceptionInInitializerError
        at org.clulab.processors.fastnlp.FastNLPProcessorWithSemanticRoles.srl(FastNLPProcessorWithSemanticRoles.scala:37)
        at org.clulab.processors.Processor.annotate(Processor.scala:97)
        at org.clulab.processors.Processor.annotate$(Processor.scala:90)
        at org.clulab.processors.shallownlp.ShallowNLPProcessor.annotate(ShallowNLPProcessor.scala:34)
        at org.clulab.wm.eidos.components.ComponentsBuilder.$anonfun$processorsPrimerLoader$2(ComponentsBuilder.scala:85)
        at org.clulab.wm.eidos.components.ComponentLoader.$anonfun$loaded$7(ComponentLoader.scala:46)
        at org.clulab.wm.eidoscommon.utils.Timer$.time(Timer.scala:73)
        at org.clulab.wm.eidos.components.ComponentLoader.$anonfun$loaded$6(ComponentLoader.scala:46)
        at scala.util.Success.$anonfun$map$1(Try.scala:255)
        at scala.util.Success.map(Try.scala:213)
        at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
        at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
        at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
        at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
        at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
        at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
        at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
        at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
        at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
Caused by: java.lang.RuntimeException: ERROR: parameter glove.matrixResourceName must be defined!
        at org.clulab.utils.Configured.getArgString(Configured.scala:34)
        at org.clulab.utils.Configured.getArgString$(Configured.scala:31)
        at org.clulab.utils.ConfigWithDefaults.getArgString(Configured.scala:44)
        at org.clulab.dynet.ConstEmbeddingsGlove$.load(ConstEmbeddingsGlove.scala:99)
        at org.clulab.dynet.ConstEmbeddingsGlove$.load(ConstEmbeddingsGlove.scala:89)
        at org.clulab.dynet.ConstEmbeddingsGlove$.<init>(ConstEmbeddingsGlove.scala:30)
        at org.clulab.dynet.ConstEmbeddingsGlove$.<clinit>(ConstEmbeddingsGlove.scala)
        ... 19 more

[kwalcock]

Do you have a branch that I can check out? "ERROR: parameter glove.matrixResourceName must be defined!" makes it sound like there is a configuration file that should have that value, but the value or the whole configuration file might be missing.

[maxaalexeeva]

@kwalcock here eidos-reader-cascade
This is literally just a copy paste of the script from that pr I mentioned above with just the class name different and run() commented out. This is not exactly how I will be using it, but I think things break down already at the stage of loading eidos.

[kwalcock]

It was working for me with both IntelliJ and sbt until I did a clean and now I get the same error. The output below from evicted is worrisome. Both processors and eidos are dependencies of habitus, but eidos itself has a processors dependency with a different version. Normally one would only include the most distant dependency and let sbt fill in the middle. I'm debugging now.

[info]  * org.clulab:processors-main_2.12:8.4.8 is selected over 8.4.7
[info]      +- org.clulab:habitus_2.12:0.2.0-SNAPSHOT             (depends on 8.4.8)
[info]      +- org.clulab:processors-openie_2.12:8.4.8            (depends on 8.4.8)
[info]      +- org.clulab:processors-corenlp_2.12:8.4.8           (depends on 8.4.8)
[info]      +- org.clulab:eidos-eidoscommon_2.12:1.5.1            (depends on 8.4.7)

[maxaalexeeva]

@kwalcock thank you!

[kwalcock]

I still don't have an explanation, but if I erase target, project/target, and project/project/target, then it will run once with sbt. The second time, it breaks again. It seems to always run OK in IntelliJ, though. I think that we are getting some "undefined behavior" as the result of the dependency conflicts. Maybe the order in which files are written to disk is significant. I'd stick with IntelliJ. Perhaps when eidos is (eventually) updated to use the same processors version as habitus, the problem will go away.

[MihaiSurdeanu]

We should upgrade Eidos to 8.5.0 when it’s released... On April 25, 2022 at 12:42:26 PM, Keith Alcock ***@***.***) wrote: I still don't have an explanation, but if I erase target, project/target, and project/project/target, then it will run once with sbt. The second time, it breaks again. It seems to always run OK in IntelliJ, though. I think that we are getting some "undefined behavior" as the result of the dependency conflicts. Maybe the order in which files are written to disk is significant. I'd stick with IntelliJ. Perhaps when eidos is (eventually) updated to use the same processors version as habitus, the problem will go away. — Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI75TSKRYC6MLTVRYMWLS3VG3YR7ANCNFSM5UJBZRQA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[maxaalexeeva]

@kwalcock it does not run for me in intellij either. I think I might try just using the regular eidos for now. should work for my purposes.

[kwalcock]

Any workaround you can find is welcome. I still can't explain it.