Skip to content

Add Windows setting for Azure Pipeline #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jun 11, 2019
Merged

Add Windows setting for Azure Pipeline #146

merged 10 commits into from
Jun 11, 2019

Conversation

termoshtt
Copy link
Member

@termoshtt termoshtt commented May 9, 2019

intel-mkl-src supports windows at 0.4.0.

@termoshtt
Copy link
Member Author

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@termoshtt
Copy link
Member Author

@jturner314
Copy link
Member

@termoshtt I got a notification saying that you're requesting me to install Azure Pipelines for the rust-ndarray organization. However, it looks like it's actually working after all. Do you need me to enable something?

By the way, I'm curious what your thoughts are on Azure Pipelines vs. Travis CI (currently used for ndarray and ndarray-stats.)

@termoshtt
Copy link
Member Author

However, it looks like it's actually working after all. Do you need me to enable something?

Thanks notify. It works well already. I am willing to add you to Azure Pipeline members if you wish.

Azure Pipelines vs. Travis CI

I've switch to azure pipeline from Circle CI on #141 for supporting macOS and windows. Azure Pipeline seems to be better option for projects including multi-platform FFI, saying rust-math/fftw and intel-mkl-src. For example, cc-rs and xz2-rs use Azure Pipeline.
In my experience, Windows and macOS on Travis CI is too slow and unstable (sometimes queue of Travis worker becomes too long) comparing to Azure Pipeline (and Linux on Travis). As far as using Linux, Travis CI is still a good option.

@termoshtt
Copy link
Member Author

running 8 tests
test fixed_lower ... FAILED
test fixed ... FAILED
test fixed_t ... ok
test fixed_t_lower ... ok
test ssqrt_lower ... FAILED
test ssqrt ... FAILED
test ssqrt_t ... ok
test ssqrt_t_lower ... ok

failures:

---- fixed_lower stdout ----
thread 'fixed_lower' panicked at 'called `Result::unwrap()` on an `Err` value: 1.2867360931346474', src\libcore\result.rs:997:5

---- fixed stdout ----
thread 'fixed' panicked at 'called `Result::unwrap()` on an `Err` value: 1.7736271894936035', src\libcore\result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

---- ssqrt_lower stdout ----
a = [[1.8349933074917306, 1.3049590285473338, 1.1309435871625373],
 [1.3049590285473338, 3.2353920583213256, 1.8178247743752314],
 [1.1309435871625373, 1.8178247743752314, 2.552417179493483]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
s = [[5.262696907193519, 4.008429621739351, -1.4736771017467638],
 [4.008429621739351, 8.316121159151518, -2.905130572475528],
 [-1.4736771017467638, -2.905130572475529, 1.4655056085810494]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
ss = [[45.93521096963445, 58.710960967588555, -21.560209425143455],
 [58.710960967588555, 93.66516280925704, -34.324033919005586],
 [-21.56020942514346, -34.32403391900559, 12.759214532127245]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
thread 'ssqrt_lower' panicked at 'called `Result::unwrap()` on an `Err` value: 24.928837631225495', src\libcore\result.rs:997:5

---- ssqrt stdout ----
a = [[2.42948638188623, 0.7087607886569429, 0.6763724352353948],
 [0.7087607886569429, 2.049722937005261, 0.9769700576946176],
 [0.6763724352353948, 0.9769700576946176, 2.0438297160123295]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
s = [[1.5290881345759924, 0.22011071480851208, 1.6567808849841827],
 [0.22011071480851208, 1.364981056053615, 0.60688335423758],
 [1.6567808849841825, 0.60688335423758, 2.3341932356154427]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
ss = [[5.131482150923574, 1.642488378970682, 6.534192256355293],
 [1.642488378970682, 2.2799294158094123, 2.6096425269124897],
 [6.534192256355292, 2.6096425269124897, 8.561688367692517]] shape=[3, 3], strides=[3, 1], layout=C (0x1), const ndim=2
thread 'ssqrt' panicked at 'called `Result::unwrap()` on an `Err` value: 2.63290695188842', src\libcore\result.rs:997:5


failures:
    fixed
    fixed_lower
    ssqrt
    ssqrt_lower

Tests of eigh with intel-mkl source on Windows failed if the array is in C stride.

@termoshtt
Copy link
Member Author

Intel MKL's dsyev (and others maybe) seems to return invalid eigenvectors when the array is C-form. This PR changes the behavior of eigh to make the returned array of eigenvectors Fortran-order.

@termoshtt termoshtt merged commit 6bfb38b into master Jun 11, 2019
@termoshtt termoshtt deleted the ci_windows branch July 17, 2020 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants