These are chat archives for symengine/symengine

18th
Jul 2015
Ondřej Čertík
@certik
Jul 18 2015 01:03
@isuruf I think the reason your and my environment in appveyor are different (yours has the VS 2015 installed and mine not) is due to this: http://www.appveyor.com/blog/2015/06/23/new-oss-build-environment-and-xamarin-support, I think I probably created an account earlier, so by default I have the old virtual machine without VS 2015, and as they said, they are transitioning to the new virtual machine in few weeks, while your account was created after that blog post, so by default it already has VS 2015.
Ondřej Čertík
@certik
Jul 18 2015 03:53
@isuruf ok, I got it working: https://ci.appveyor.com/project/isuruf/symengine/build/217, it builds and tests pass, except those platform dependent tests (the same issue as for Intel).
Ondřej Čertík
@certik
Jul 18 2015 04:03
And if I comment the tests out, then everything passes: https://ci.appveyor.com/project/isuruf/symengine/build/218
Isuru Fernando
@isuruf
Jul 18 2015 04:34
My account was not created after that blog post, but they are rolling it out to users gradually
@certik, let me know when you have polished it up to be merged.
Ondřej Čertík
@certik
Jul 18 2015 04:43
@isuruf yes, I need probably 1h or so.
@isuruf yes, if you can get mingw working, that would be awesome.
Isuru Fernando
@isuruf
Jul 18 2015 04:45
MinGW is working locally, but hangs on appveyor
Ondřej Čertík
@certik
Jul 18 2015 04:49
can you post a link?
Amit Kumar
@aktech
Jul 18 2015 04:50
Hi @certik what do you use for debugging in cpp?
Ondřej Čertík
@certik
Jul 18 2015 04:51
@aktech I use gdb if I need to debug. But most of the time, I just enable the automatic stacktrace (WITH_BFD=yes) and since it can't segfault in Debug mode, I very rarely use gdb.
Isuru Fernando
@isuruf
Jul 18 2015 04:52
@aktech, I'm using CLion as my IDE and debugging support and CMake support is very good
Amit Kumar
@aktech
Jul 18 2015 04:53
Thanks @certik @isuruf , will try both of these.
Ondřej Čertík
@certik
Jul 18 2015 04:53
I use vim and develop in a terminal.
Isuru Fernando
@isuruf
Jul 18 2015 04:54
@aktech, CLion should be free for you if you have a university email account.
Amit Kumar
@aktech
Jul 18 2015 04:54
Nowadays, I am switching to vim, so It will take some time to get hold of it.
@isuruf I don't have that.
Ondřej Čertík
@certik
Jul 18 2015 04:54
@isuruf try to comment out test_rcp, and see if other tests hang out as well.
Also, try to run them directly, instead of via cmake. Finally, you can use RDP to login to the work node (before running ctest) : http://www.appveyor.com/docs/how-to/rdp-to-build-worker, and debug by hand to see what is going on. On my Ubuntu, I used remmina to connect there and it worked great.
Amit Kumar
@aktech
Jul 18 2015 04:59
@isuruf There is an option for Official document for students, will try that.
Isuru Fernando
@isuruf
Jul 18 2015 05:12
@certik, Commenting out test_rcp doesn't work as it hangs on the next test.
Running the tests directly doesn't work either
@certik, how do I login to appveyor using RDP?
Ondřej Čertík
@certik
Jul 18 2015 05:14

@isuruf then you need to login there remotely to see what is going on. mingw is like that unfortunately, that it sometimes just segfaults or hangs. So if it doesn't work, we can give up.

You login there by adding the line at the end of appveyor.yml per the link I sent.

Ondřej Čertík
@certik
Jul 18 2015 05:38
@isuruf here you go: sympy/symengine#545
This tests MSVC in Debug mode with all our checks. Now we also need to add another tests in Release mode (to test our RCP classes). Otherwise we are in great shape.
Isuru Fernando
@isuruf
Jul 18 2015 06:04
Got MinGW working
Ondřej Čertík
@certik
Jul 18 2015 06:04
Cool, send a PR.
Did the dialog pop up once you connected using RDP?
Isuru Fernando
@isuruf
Jul 18 2015 06:06
Yes
Ondřej Čertík
@certik
Jul 18 2015 06:06
Excellent. I am glad you figured it out.
Ondřej Čertík
@certik
Jul 18 2015 07:20
sympy/symengine#546
Isuru Fernando
@isuruf
Jul 18 2015 07:21
ICC doesn't have reserve? That's strange
Ondřej Čertík
@certik
Jul 18 2015 07:21
It is indeed strange.
I wish there was a way to setup CI with Intel compilers. But for now I'll just compile it by hand once in a while. Everything works.
Isuru Fernando
@isuruf
Jul 18 2015 07:25
sympy/symengine#547
Ondřej Čertík
@certik
Jul 18 2015 07:26
I am compiling with PGI now. It also doesn't have reserve. I bet both Intel and PGI are using some kind of old C++ standard library.
Isuru Fernando
@isuruf
Jul 18 2015 07:29
I tried multiple times to have multi line if blocks in #547, but failed, so I used the if statement everywhere
Ondřej Čertík
@certik
Jul 18 2015 07:35
We can probably switch to a PowerShell or a batch script, similarly to what we do for Travis.
@isuruf any comments to sympy/symengine#546 ?
or can we merge it.
Isuru Fernando
@isuruf
Jul 18 2015 07:40
#547 passes tests as well
Ondřej Čertík
@certik
Jul 18 2015 07:42
Here are the PGI fixes: sympy/symengine#548
I am still reviewing your PR.
Isuru Fernando
@isuruf
Jul 18 2015 07:45
Thanks
Isuru Fernando
@isuruf
Jul 18 2015 07:55
Can you access messages in gitter from yesterday
Ondřej Čertík
@certik
Jul 18 2015 07:55

We've done huge progress. The library code now builds on Linux (clang, gcc, intel, pgi), Mac (clang, gcc), Windows (msvc, mingw). That's plenty of compilers, I think it's essentially 4 independent vendors, so that shows that our code is platform independent.

What remains is to get the Release build working for MSVC and also testing in Python.
Later we should use Travis and AppVeyor to automatically upload the binaries online (for example to anaconda.org) for all Linux, Mac and Windows. Finally, we should then also let Travis and AppVeyor handle our release management, so that everything is fully automatic.

Ondřej Čertík
@certik
Jul 18 2015 08:09
I think I can access messages from yesterday. Why?
Isuru Fernando
@isuruf
Jul 18 2015 08:13
I couldn't earlier. It's fine now
Ondřej Čertík
@certik
Jul 18 2015 08:20
Yes, and I only have gcc 4.4 or so. Which explains it.
Ondřej Čertík
@certik
Jul 18 2015 08:26
I am going to bed now.
Isuru Fernando
@isuruf
Jul 18 2015 11:58
My branch for Python in appveyor is here,
https://github.com/isuruf/symengine/tree/windows1
Francesco Biscani
@bluescarni
Jul 18 2015 11:59
@isuruf do you know which mingw distribution appveyor is using?
Isuru Fernando
@isuruf
Jul 18 2015 12:00
mingw.org one
Francesco Biscani
@bluescarni
Jul 18 2015 12:00
I see, thanks!
I see that in that discussion you linked there is someone detailing how to setup with a different mingw distribution, pretty interesting
Isuru Fernando
@isuruf
Jul 18 2015 12:59
@bluescarni, yes. Do you know how to install gmp with it?
Francesco Biscani
@bluescarni
Jul 18 2015 13:08
@isuruf last May I had to spend a couple of weeks working on a Windows laptop, so I spent some time making sure Piranha would compile and run properly there
I used mingw64 to get a full 64 bit build on Windows 7
and I had to compile GMP and MPFR as dependencies of course
Isuru Fernando
@isuruf
Jul 18 2015 13:09
There's nothing like mingw-get right?
Francesco Biscani
@bluescarni
Jul 18 2015 13:09
I managed to create static libraries for both rather easily
correct
there's a GUI installer
but I don't see why one could not get the full environment running on a local VM, package it and pull it from appveyor
I got also Boost compiled and running with full C++11 support and piranha's Python bindings were working as well
that required a bit of wrestling though
but I managed in the end
to compile GNU packages like GMP and MPFR on mingw you will also need msys
as you need to be able to run configure
msys is a small self-contained thingie though, so no big deal
Isuru Fernando
@isuruf
Jul 18 2015 13:12
looks like there's some work to do. I'll take a look after I get Python bindings working for MinGW
Francesco Biscani
@bluescarni
Jul 18 2015 13:13
the only thing I was not able to solve was to get a DLL of MPFR. GMP would produce a DLL, but MPFR not. In the end I just switched to static libs, but I suspect it is fixable
for the 64bit python bindings you will have to do some wrestling with mingw and the Python headers
basically, the Python headers do not setup properly the 64bit environment if you are using MinGW
it took me a long time to find the solution for that, in the end I found this webpage:
the important section is "Setup Python for compilation of extensions"
basically you have to patch the Python headers and create version of the Python library that can be used by MinGW 64 bit via a tool called gendef
it all works in the end, but it was hairy to get there
A friend of mine wrote down some of the steps here: https://github.com/esa/pagmo/wiki/Guide-to-Compilation-on-Windows-x64
Francesco Biscani
@bluescarni
Jul 18 2015 13:18
might be useful if you ever decide to support mingw 64 bit
Isuru Fernando
@isuruf
Jul 18 2015 13:18
Thanks. I'll take a look. Hopefully MinGW and MSVC won't be that much of a problem
Francesco Biscani
@bluescarni
Jul 18 2015 13:19
np, good luck with it ... I can't stomach working on Windows unless absolutely forced, so as soon as I got this working I was satisfied :)
but it is important to have a Windows version, both for the users and for code quality
Isuru Fernando
@isuruf
Jul 18 2015 13:48
Python extensions compile, but there are linking errors.
Which should I link against? libpython2.7a or python27.lib?
Francesco Biscani
@bluescarni
Jul 18 2015 13:57
is this 64 or 32 bit?
I can't honestly remember which is the right now, I just try them both and see which works usually :)
Isuru Fernando
@isuruf
Jul 18 2015 13:58
32 bit. since its MinGW I guess libpython2.7a
Francesco Biscani
@bluescarni
Jul 18 2015 13:58
should be yes
Isuru Fernando
@isuruf
Jul 18 2015 13:58
tried both, neither works
Francesco Biscani
@bluescarni
Jul 18 2015 14:06
can you try the dll?
Isuru Fernando
@isuruf
Jul 18 2015 14:06
there's no dll
Francesco Biscani
@bluescarni
Jul 18 2015 14:08
c:\windows\system32\python27.dll ?
Isuru Fernando
@isuruf
Jul 18 2015 14:13
Ah yes, will try that one
Isuru Fernando
@isuruf
Jul 18 2015 14:32
Doesn't work
Francesco Biscani
@bluescarni
Jul 18 2015 14:38
are you testing this directly in appveyor or do you have a VM in front of you?
Isuru Fernando
@isuruf
Jul 18 2015 14:38
directly in appveyor through RDP
Francesco Biscani
@bluescarni
Jul 18 2015 14:38
can you paste the output of the compilation?
Isuru Fernando
@isuruf
Jul 18 2015 14:39
Linking CXX shared library symengine_wrapper.dll
CMakeFiles\symengine_wrapper.dir/objects.a(symengine_wrapper.cpp.obj):symengine_
wrapper.cpp:(.text+0x39): undefined reference to `_imp___PyThreadState_Current'
CMakeFiles\symengine_wrapper.dir/objects.a(symengine_wrapper.cpp.obj):symengine_
wrapper.cpp:(.text+0xc2): undefined reference to `_imp__PyBaseObject_Type'
CMakeFiles\symengine_wrapper.dir/objects.a(symengine_wrapper.cpp.obj):symengine_
wrapper.cpp:(.text+0x102): undefined reference to `_imp__PyBaseObject_Type'
There are multiple errors like this
Francesco Biscani
@bluescarni
Jul 18 2015 14:42
the same errors regardless of the library you link against?
Isuru Fernando
@isuruf
Jul 18 2015 14:42
yes
Francesco Biscani
@bluescarni
Jul 18 2015 14:43
that's weird... can you run a verbose compilation to see exactly how the linking is happening?
Isuru Fernando
@isuruf
Jul 18 2015 15:29
found the issue, it was in our CMakeLists.txt
Francesco Biscani
@bluescarni
Jul 18 2015 15:32
oh cool.. wasn't the Python library being linked in?
Isuru Fernando
@isuruf
Jul 18 2015 15:33
yes
Ondřej Čertík
@certik
Jul 18 2015 15:52
@bluescarni in your experience, do people use mingw a lot? My idea initially was to mainly make sure things work with MSVC. That's a big deal. But since we have this all setup, @isuruf figured out why not to also test mingw.
Francesco Biscani
@bluescarni
Jul 18 2015 15:55
@certik in short, I think it is worth
Ondřej Čertík
@certik
Jul 18 2015 15:55
Btw, the MSVC compiler (VS 2015) seem very robust, it compiles the current SymEngine master without problems and we use quite a bit of C++11 (thought not as much as Piranha). Our next step that I forgot to mention is to also enable warnings and make them errors. MSVC seems to have some good warnings that gcc or clang doesn't.
Francesco Biscani
@bluescarni
Jul 18 2015 15:56
MinGW support means another set of platform checks, hence more robust and healthy code in general
minwg64 is a robust compiler, certainly the best C++11 compiler available on windows right now
it compiles tons of big open source projects, including IIRC Firefox
Ondřej Čertík
@certik
Jul 18 2015 15:56
@bluescarni ah ok. Do you think we need to test 32 bits at all? I would just test 64bts on windows.
I am actually not sure if we test 32bits or 64 bits with MSVC.
Francesco Biscani
@bluescarni
Jul 18 2015 15:57
I think it's good to go the extra mile and do the 32 bits as well, I wouldn't expect it to be too different from the 64 bits setup
Isuru Fernando
@isuruf
Jul 18 2015 15:57
@certik, updates
We are building in debug mode in MSVC, hence we need python27_d.lib
Managed to build python extensions in MinGW, but they cannot be loaded from a python shell
We are building with 32 bits
Ondřej Čertík
@certik
Jul 18 2015 15:58
Are we doing 32bits with MSVC or mingw?
Isuru Fernando
@isuruf
Jul 18 2015 15:59
32 bits both
Francesco Biscani
@bluescarni
Jul 18 2015 15:59
It's true that 32bits is dying out, but still.. I'd expect ARM 32bit and 32bits Windows installations to be around for quite a while still
Ondřej Čertík
@certik
Jul 18 2015 15:59
I see, perfect. So we need to add 64bits for both as well.
@isuruf How do you tell MSVC to compile in 64bits?
Isuru Fernando
@isuruf
Jul 18 2015 16:00
/p:Platform=%PLATFORM%
you have to use the correct msbuild as well
Ondřej Čertík
@certik
Jul 18 2015 16:02
@bluescarni you should have written an appveyor.yml for your setup. I must say that I love appveyor, since you essentially document everything you need to do in order to get the code compile, from a clean VM (that only has default installs, as far as I can tell). I used to use vagrant + mingw to do precisely this (https://github.com/certik/numpy-vendor), but these days I would just try to use appveyor.
I wish there was some service that would also test Intel compilers. I wouldn't mind paying for it.
Francesco Biscani
@bluescarni
Jul 18 2015 16:09
I think I can reproduce the setup quite quickly once I am on a Windows machine, I have those wiki pages as references and the code is still on the laptop
but I had no idea at the time of the existence of appveyor... and also it does not seems to have the MinGW version I'd use
in general I don't have the bandwidth to keep on developing Piranha and follow these things closely... given the finite energy, I prefer to focus on the essentials (coding + extensive unit testing, which bores me out of my mind and pretty much dries up any energy for non-coding tasks)
@isuruf and @Sumith1896 have been helping out with travis configs and other workflow improvements, for which I am grateful :)
Ondřej Čertík
@certik
Jul 18 2015 16:15
@bluescarni you need to have this automatic CI testing infrastructure setup. Otherwise it's a lot of work to port the code to a new compiler.
The point is that you've already done all the hard work, it's just about writing it down into appveyor.yml.
Francesco Biscani
@bluescarni
Jul 18 2015 16:16
it will be soon... but right now it's either GCC or clang, so it's not much point even trying with MSVC until they implement expression SFINAE
but you are right on the appveyor + mingw side
Ondřej Čertík
@certik
Jul 18 2015 16:17
the VS2015 still doesn't implement it?
Isuru Fernando
@isuruf
Jul 18 2015 16:17
With piranha, there are additional problems like memory.
Francesco Biscani
@bluescarni
Jul 18 2015 16:17
no, it's about the last feature they are missing
Ondřej Čertík
@certik
Jul 18 2015 16:17
Ok.
see here
@isuruf in MSVC or MinGW?
Ondřej Čertík
@certik
Jul 18 2015 16:18
I see, so they are working on it.
Francesco Biscani
@bluescarni
Jul 18 2015 16:18
yes.. they can't really implement the standard library fully without that
Isuru Fernando
@isuruf
Jul 18 2015 16:19
There were out of memory issues with gcc on travis
Francesco Biscani
@bluescarni
Jul 18 2015 16:19
ah yes ok... working on it, I will have a reduced test suite for automatic integration
Ondřej Čertík
@certik
Jul 18 2015 16:23
@bluescarni if you compile just a C library or a C interface with mingw (let's say), is it compatible with MSVC?
Francesco Biscani
@bluescarni
Jul 18 2015 16:24
C should be no problem, if you have C++ you need to compile everything with either MSVC or MinGW, at least in 64 bit mode
I am not sure what the problem is, but I recall something about differences in exception handling... basically if you throw from a MSVC dll you cannot catch it from MinGW
or something along these lines
Ondřej Čertík
@certik
Jul 18 2015 16:26
Yes, it's the same problem with C++ on all platforms, you just need to stick to the same compiler. But with C, it should be interoperable. Except that there is some issue with the /MT, /MD, /MTd... flags (https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx)
It looks like even the C library must be compiled with the same flags in order to use it as the main program?
It might have been the C++ version of mpir causing the issues --- it was compiled with /MTd, but my main code only with /MT I think, and it flipped some debug flags in header files, so I got linking errors.
Francesco Biscani
@bluescarni
Jul 18 2015 16:28
I am not completely sure about that... generally I have just used the default flags from CMake, which do include the multi-threading ones IIRC when using MinGW... I could for instance throw exceptions from C++ and catch them in the Python bindings via Boost.Python without issues
(Boost.Python has a mechanism to translate exceptions from C++ into Python)
Ondřej Čertík
@certik
Jul 18 2015 16:29
I had to modify the default CMake flags using -DCMAKE_CXX_FLAGS_DEBUG="/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1 /W1"
Francesco Biscani
@bluescarni
Jul 18 2015 16:29
everything had been compiled with MinGW though
Ondřej Čertík
@certik
Jul 18 2015 16:29
(I took the default flags, but added /MTd)
Francesco Biscani
@bluescarni
Jul 18 2015 16:30
I don't know much about MPIR, I have just been using GMP in general
Ondřej Čertík
@certik
Jul 18 2015 16:30
I need to look into this in more details. I suspect I might just tell cmake to use shared or static library, I am not sure which one is the default.
@bluescarni GMP seems to have issues compiling with MSVC.
Francesco Biscani
@bluescarni
Jul 18 2015 16:31
https://github.com/bluescarni/piranha/blob/master/pyranha/CMakeLists.txt this is what I use for the Python bindings, there's not much platform specific really
ahh I see
basically just use ADD_LIBRARY from CMake and change the name prefix to avoid putting lib... in front
some switching around for the extension... Windows wants often .pyd for instance
I knew that GMP is not very MSVC friendly, some years ago there was a guy providing up-to-date binary packages from GMP and MPFR
I think he stopped after MPIR started, ironically, because he thought it would be pointless to keep on doing that
Isuru Fernando
@isuruf
Jul 18 2015 16:42
@certik, can you take a look here
https://ci.appveyor.com/project/isuruf/symengine/build/271/job/iy671elxo2lr5ghp#L464
Python extension is built, but cannot be loaded from a python shell
You might want to run these commands in a command prompt
cd C:\projects\symengine\build
set PATH=C:\MinGW\bin;%PATH%
set PATH=C:\Python27\Scripts;%PATH%
Francesco Biscani
@bluescarni
Jul 18 2015 16:46
can you try to change the extension of the module to .pyd?
"Of course, foo.pyd is required if you want to say import foo."
Isuru Fernando
@isuruf
Jul 18 2015 16:48
ImportError: DLL load failed: The specified module could not be found.
Isuru Fernando
@isuruf
Jul 18 2015 17:10
Got it working. renaming to .pyd and adding MinGW\bin to path worked
All test pass. :D
Ondřej Čertík
@certik
Jul 18 2015 17:19
@isuruf excellent!
Send a PR.
I've been finishing #532. I had it a bit wrong after all --- previously I had to use class Basic : public EnableRCPFromThis<const Basic> which always felt wrong to me. Now we can finally use class Basic : public EnableRCPFromThis<Basic> and things work.
Ondřej Čertík
@certik
Jul 18 2015 17:30
So http://mpir.org/mpir-2.7.0.zip times out, so MSVC tests fail. Great, I think we need to host it ourselves on github.
Isuru Fernando
@isuruf
Jul 18 2015 17:34
is there an equivalent of cmake --build . for installing?
Is there a equivalent of cmake --build . for installing?
Ondřej Čertík
@certik
Jul 18 2015 17:36
Good question, I don't know.
#551 should fix the time out issue.
Ondřej Čertík
@certik
Jul 18 2015 17:41
So we should host that tarball on our github as well.
Isuru Fernando
@isuruf
Jul 18 2015 18:23
@certik, I can't cancel a build in main repo's appveyor
Aren't they using github permissions?
Ondřej Čertík
@certik
Jul 18 2015 18:37
@isuruf I need to figure out the premissions still. I think I need to add you in somehow.
I am fixing the tarballs for now.
In #551 we now host everything on github.com/symengine
Francesco Biscani
@bluescarni
Jul 18 2015 18:50
@certik how do you script things on appveyor? powershell?
Ondřej Čertík
@certik
Jul 18 2015 18:51
You can use either batch (cmd.exe) or powershell
Francesco Biscani
@bluescarni
Jul 18 2015 18:52
ty
hard to believe it's 2015 and DOS scripting is still going :)
Ondřej Čertík
@certik
Jul 18 2015 18:55
Well, it's 2015 and linux scripting is essentially Unix scripting, which is even older.
Francesco Biscani
@bluescarni
Jul 18 2015 18:56
true... C and Fortran are even older :) it's just that Windows batch files look quite a bit more simplistic than bash scripting
Ondřej Čertík
@certik
Jul 18 2015 18:56
Yeah, they suck. This powershell thing is better, but I don't know how well supported it will be in the future.
What's nice about Bash is that it will be supported essentially forever, and it's good enough.
Francesco Biscani
@bluescarni
Jul 18 2015 18:57
that's a usual concern with closed source technologies
Ondřej Čertík
@certik
Jul 18 2015 18:58
@isuruf we should rearrange our tests -- on Appveyor we should run MSVC first, on Travis, we should first run gcc, and then OSX immediately afterwards. That way you get a quick feedback on 3 different platforms. Then we can run the rest of the tests.
Isuru Fernando
@isuruf
Jul 18 2015 18:59
that's a good idea
Ondřej Čertík
@certik
Jul 18 2015 19:02
What do you think the failure is here: https://travis-ci.org/sympy/symengine/jobs/71575483, that's why #551 failed.
First of all, the Ruby wrappers have a warning, that for some reason didn't turn into an error (it should have), and second of all, the actual error seems "Can only use bundle clean when --path is set or --force is set", but I have no idea why that PR would trigger that.
Plus that error doesn't seem to come from our own code, but rather something that Travis itself does...
Isuru Fernando
@isuruf
Jul 18 2015 19:06
Yes, a quick fix would be to remove the cache: bundler statements
Ondřej Čertík
@certik
Jul 18 2015 19:06
Ok let me try.
Isuru Fernando
@isuruf
Jul 18 2015 19:08
Btw, we can reduce the number of tests in travis by combining the python and ruby tests
@certik, that error was probably there earlier, but we didn't see it because set -x was not set and it was not reported as an error because set -e was not set
Ondřej Čertík
@certik
Jul 18 2015 19:22
I am not sure, since that script exited fine.
In any case, yes, we should combine Python + Ruby tests together.
Isuru Fernando
@isuruf
Jul 18 2015 19:24
we use source bin/install_travis.sh which means set -e is set for the whole environment as well.
Ondřej Čertík
@certik
Jul 18 2015 19:24
Ah, I think that might be a mistake.
Why do we need to do it?
Isuru Fernando
@isuruf
Jul 18 2015 19:24
for miniconda
Ondřej Čertík
@certik
Jul 18 2015 19:25
Well, we can turn it off at the end of the script
Isuru Fernando
@isuruf
Jul 18 2015 19:25
yes
Ondřej Čertík
@certik
Jul 18 2015 20:26
The shippable builds are finally available even if you don't log in.
They just fixed it today. So anyone can now easily check if something is wrong with them. That's very useful.