[CLI] crashing on incorrect arguments (cache caching ?)

[kevinchern]

Version: be3bbce

Fixed in: https://github.com/UBC-Stat-ML/blangSDK/commit/eeaba3aa493c03b170acc86a40fba6de533f6d07#diff-a82ae04972228cc12ea17d6dd56e1c22R127

Error message example:

ERROR:Exponential cannot be resolved. (file:Example.bl line : 13 column : 13)
ERROR:Exponential cannot be resolved. (file:Example.bl line : 14 column : 12)
ERROR:NonClockTreePrior cannot be resolved. (file:Example.bl line : 15 column : 26)
ERROR:UnrootedTreeLikelihood cannot be resolved. (file:Example.bl line : 16 column : 37)

Reproduction steps:

Directory structure:

NOTE ./dat is not ./data

./Example.bl
./dat/primates.fasta

Commands:

rm -r .blang-compilation

blang --model demo.Example \
--model.observations.file data/primates.fasta \
--model.observations.encoding DNA \
--engine PT \
--engine.random 1

mv dat data

blang --model demo.Example \
--model.observations.file data/primates.fasta \
--model.observations.encoding DNA \
--engine PT \
--engine.random 1

ERROR

Any subsequent runs with any model will throw similar errors, for example:

echo "model A { laws { | Integer a = 0 ~ LogPotential(0) } }" > Test.bl && blang --model A throws ERROR:LogPotential cannot be resolved. (file:Test.bl line : 1 column : 35)

Running the following works:

rm -r .blang-compilation
echo "model A { laws { | Integer a = 0 ~ LogPotential(0) } }" > Test.bl && blang --model A

[kevinchern]

@alexandrebouchard this is reproducible in https://github.com/UBC-Stat-ML/blangSDK/commit/be3bbce11d5c5e780ab3c779f40409b6b704d790

https://github.com/UBC-Stat-ML/blangSDK/commit/eeaba3aa493c03b170acc86a40fba6de533f6d07#diff-a82ae04972228cc12ea17d6dd56e1c22R127 commenting out --no-daemon argument actually fixed this issue. I am having trouble seeing why using the daemon would fix it, is it worth further investigation for the time being?

For now I left a comment in the code pointing to this issue (in my fork).

[alexandrebouchard]

That's really weird indeed. I certainly didn't expect --no-daemon to fix things, it was more a performance trade-off test I wanted to make.

Can you double check that adding back --no-daemon will make the issue reappear?

Also I had a question on the initial report: there error report mentions a file 'hello.bl' which was not in the hierarchy you described. Where is this hello.bl located?

Thanks!

[kevinchern]

Yep! I tried eeaba3a with --no-daemon added back in, and it is throwing the same error again.

Updated comment regarding hello.bl: it was in the same root directory, but I completely removed that. The error message now corresponds to Example's error message, and the directory structure is identical to what is reported.

echo "model A { laws { | Integer a = 0 ~ LogPotential(0) } }" > Test.bl && blang --model A throws ERROR:LogPotential cannot be resolved. (file:Test.bl line : 1 column : 35)

[alexandrebouchard]

Strange.. I tried reproducing with or without --nodaemon and couldn't get the same error.

Maybe the blang command was stale i.e. ./setup-cli.sh was not called at some point in the scenario.

Another possibility is that the dependencies.txt file was not included in this example?

Finally, note that even after moving dat->data the file input is also incorrect, it should be .fasta not .fast

Let me know if the error persists though. I can try it on your laptop on Monday too.

[kevinchern]

Sorry for the mixup, the actual tests were with the correct names (fasta) I invited you to a github repo for reproducing the error; this error was replicated in a ubuntu VM.

[alexandrebouchard]

Thanks!

Here is an hypothesis: the error message suggests that somehow the blangSDK build directory somehow got deleted or corrupted. To figure out if this is the case try running setup-cli.sh to see if it fixes the issue. If it does, it will remain to figure out what did the deletion/corruption...

[kevinchern]

I setup after checking out the commit, and ran the blang binary via absolute path to check. Let's go over it in the meeting today.

[alexandrebouchard]

Sounds good. Wrote an update on the error reproducibility repo too. Suggests at least one part of the fix will be to detect duplicated gradle dependencies