Run Travis-CI in OSX in addition to Ubuntu

[nuclearGoblin]

It would be nice to have some sort of automatic testing for OSX to help with troubleshooting for Macs. Here is the documentation for OSX testing through Travis-CI, and here is the documentation for testing on multiple operating systems. It looks like including testing for both should be pretty straightforward.

[villaa]

See the notes in issue #10 for a run-down on some of the challenges with adding in OSX. Specifically it will be in the root installation installed and whether or not we have moved to the C++ internal version of the Mersenne Twister suggested in issue #27.

I suggest we solve issue #27 first and move to the internal C++ version of the Mersenne Twister, that will make this issue much easier to deal with.

[villaa]

see this Travis-CI link for a run-down of the precise distributions that Travis has available.

[villaa]

Implementing on different operating systems is documented here on Travis-CI.

Specifically this type of structure in the .travis.yml file may work:

language: python

jobs: include:

• os: linux python: 3.2 env: TOXENV=py32
• os: linux python: 3.3 env: TOXENV=py33
• os: osx language: generic env: TOXENV=py32
• os: osx language: generic env: TOXENV=py33 install:
• ./.travis/install.sh script: make test

[villaa]

check the OSX distributions on travis here.

[villaa]

Check out the techniques used here for mac OSX builds. And also perhaps here.

[villaa]

Installing miniconda from the command line might be a solution to getting a reasonable python environment going on OSX.

[villaa]

WARNING: job 621 passed the CI but it looks like realizeCascades did not run properly. Why??

[villaa]

WARNING: job 621 passed the CI but it looks like realizeCascades did not run properly. Why??

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

[villaa]

This error comes up on OSX builds. Tried to use the work-around listed in the post.

[nuclearGoblin]

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

Shoot. I think this is an oversight on my part. If I run the python script directly I definitely get an error code if the python script fails, but not when it's embedded in the bash script. Working on a fix now.

[nuclearGoblin]

@villaa Okay, just fixed this on develop.

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

[villaa]

I think I now have the OSX compile "working" but still getting a segfault error (only on OSX): [/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)

Trying to debug this but this thread suggests an X11 issue and the linked issue suggests it could be because ROOT itself or Qt were not compiled with X11 (XQuartz).

I don't know what's with this problem because I'm not even using graphics at all, so why should all this stuff matter?

[villaa]

Still having some odd segfaults for OSX. Time to bring out the big guns: gdb. I installed with brew like brew install gdb

What ensued was basically a 4 hour code-signing debacle because Mac is annoying. In any case these instructions eventually worked. Yes, TWO reboots were required.

Now I just have to remember how to use gdb.

[villaa]

Update: even after installing and signing gdb am having a lot of trouble correctly running it. When I finally get the executable correctly instrumented (I used -g -O0 flag and ran gdb on the original executable NOT the one made with a sudo make command) the gdb program hangs with something like:

Note: this version of macOS has System Integrity Protection.
Because `startup-with-shell' is enabled, gdb has worked around this by
caching a copy of your shell.  The shell used by "run" is now:
    /Users/villaa/Library/Caches/gdb/bin/sh
[New Thread 0x1703 of process 3447]
[New Thread 0x2803 of process 3447]

Instead I'm using lldb because of this snarky post.

[villaa]

while debugging found that the regex library I use to read the input files seems to be failing on OSX, and the behavior is different on Linux.

the library include is: #include<regex.h> and the object I'm using is in src/cascadeProd.c and is of type regex_t and the function regcomp used for the matching is not producing any matches on OSX (although it is on Linux).

[villaa]

this is the regular expression i'm playing with to see why it evaluates differently on OSX (Mojave).

[villaa]

On OSX (Mojave) the regex function regcomp() fails with this code: regexec() failed with 'repetition-operator operand invalid'

Whereas on Linux it gives success.

The failure may have to do with POSIX support for the ? operator in regex, see this post. I'm tired of this. I'm going to watch John Wick now.

[villaa]

Ugh, might I have to use boost?

[villaa]

Ok, so I think I just have to avoid using +? and *? as regex operators. I think I was using them incorrectly in the first regex quoted above anyway. They are meant to be taken together to give "lazy" action and I was using the ? to mean zero or one times for an expression like [0-9]+? by which I meant either no digits or any number, but really it was matching any number of digits "lazily."

here is an update of my regex: v2

[villaa]

here is an update of my regex: v3

[villaa]

here is another update: v4

[villaa]

final one that I'll try: v5

This one doesn't have any *? or +?

[villaa]

Making some progress based on my SO post, can probably start a pull request. Regex is weird, at least as implemented in regex.h; I was having a lot of trouble with the \s+ so one of the suggestions in my post showed me how to do that a different way: [[:space:]] supposedly this is more POSIX.

[villaa]

REALIZATION: even on Linux, the interpretation of scientific notation as double has always failed b/c the function interpretDbl in cascadeProd.c is not good at selecting scientific notation OR other double types.

This is hard to catch because the only cascades that test it are low-fraction cascades and there are likely to be other cascades in the file to give much larger values, so as long as they don't segfault the code, they'll be quite. Si28_ngam_all_cascades_rfmt_sorted.txt is a good one to test because it has many cascades in scientific notation. An even better tester file would have scientific notation on all cascades.

[villaa]

Addressed with PR #61