I have installed two day ago enthought canopy 32 bit (for using python and its packages). When I run my antivirus, it found that the file:
_odepack.pyd
is a malware, specifically GEN:Variant.kazy.114716. It is inside
...users\appdata\local\enthought\canopy32\user\lib\site-packages\scipy\integrate
What is it? Is it a malware inside the installation?
This is a false positive that has been reported previously. Make sure you update your antivirus definitions, as this often solves the problem. Otherwise, you should add the file to the whitelist in the antivirus.
The odepack library implements solvers for ordinary differential equations in scipy.
Related
I wrote some code months ago testing different optimizations of a function. I've since updated my anaconda installations of scipy, numpy, etc. that the code uses. Now the functions have different speeds (some faster, some slower), despite using the same code.
Is there anyway to check what the previous version of scipy that was installed was so I can attempt to see if something in scipy changed affecting my code? I use anaconda for package management, so I'm not sure if there's some record of previously installed versions somewhere. In particular I'd like to check cKDTree and cdist to see if either has changed in any meaningful way since my last installed version.
In a Java project I am using matrix-toolkits-java (MTJ) for efficient matrix multiplication. This relies on netlib-java, which in turn relies on an optimized implementation of BLAS and LAPACK installed on the machine. It specifically looks for /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 to find these libraries.
When installing blas and lapack via Yum, we get symbolic links /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 pointing to the .so files from the reference blas and lapack installed via Yum.
Now we want to use implementations that are faster than the reference ones, in my case OpenBLAS. Irrelevant of whether I compile that myself, or install it via Yum, I end up with /usr/lib64/libopenblas-r0.2.18.so.
Now, according to any guide on the internet I am supposed to replace the symlinks to the reference implementation with symlinks to the OpenBLAS implementation, ending up with something like this:
libblas.so.3 -> libopenblas-r0.2.18.so
liblapack.so.3 -> libopenblas-r0.2.18.so
Okay, I can do that! I can do that with ln, or via alternatives. And if I do that, my code is happily using the fast OpenBLAS.
However, when ldconfig runs my awesome symbolic links are gone, they are overwritten by the reference BLAS and LAPACK installations. And then my software is sad and slow again.
So my question is, how to install OpenBLAS on CentOS/Fedora in such a way that running ldconfig will not destroy it? I can not remove the blas and lapack packages, as other clients of the host might rely on it. Rather I would somehow make the OS understand that OpenBLAS is an drop-in alternative to blas and lapack.
This article proposes installing openblas-compat via Yum. That fixes the issue for me. After installing the default blas package my software was still using OpenBLAS.
i don't think this behaviour is something that can be avoided without removing the reference implementations.
if you need to manually rebuild the ld.so.cache, you can run ldconfig -X to avoid updating links.
apart from that you will most likely have to create a custom script to restore the symbolic links to openblas after ldconfig updated the links
I am new to python, hoping to use it for scientific computation, data acquisition, etc. My ignorance is near total.
I am using a macbook pro, running OSX 10.9.5.
I first installed python 2.7, numpy, and matplotlib; can't remember where they came from. They seem to sit in /Library/Frameworks/Python.framework....
All was OK, until I realized I need scipy also. So, I installed the entire scipy stack from scipy.org, using 'sudo port install py27-numpy py27-scipy py27-matplotlib py27-ipython +notebook py27-pandas py27-sympy py27-nose', after having first installed xcode and the developer tools.
This new installation is located in \opt\local\var\macports\software...
Here's the question: When I run python in a terminal, it always defaults to the original installation. scipy, in particular, cannot be found. I suppose this is a path problem, but I am out of my depth here. Can someone help?
Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.
I seem to have wiped out my path environment variable a while back. I've been slowly restoring things. I have both MATLAB and the MATLAB compiler installed. DLL's I've created from the MATLAB compiler won't run because they can't find the MATLAB compiler runtime dlls. While I did find the particular files that are my immediate problem. I'm wondering if there is a MATLAB *.bat file or command I can type that will restore my path variable to what it was after MATLAB and the Compiler were installed. I'm hoping to forestall future problems.
In case it's version specific I'm running MATLAB R2010b, I'm running a 32 bit version on a 64 bit machine.
[Edit]
I thought I would add that the path I need for running the compiled version was:
C:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v714\runtime\win32
With luck, that one along with the two suggested in the answer will get me back to the original state.
restoredefaultpath might recover your MATLAB installation. Consider the use of startup.m, in order to easily undo changes to your environment.
You want to have these two directories on the PATH (I think the order is important):
C:\Program Files\MATLAB\R2010b\runtime\win32
C:\Program Files\MATLAB\R2010b\bin
Obviously you need to adjust the path to match your setup and architecture (those are on a WinXP 32-bit)
If you have a current software maintenance contract for your MATLAB, it may well be that the easy thing to do is just upgrade to the next version of MATLAB since R2011a is out now (unless there is some compelling reason why you must develop on R2010b. Running the software installer should recreate the default environment for MATLAB. I am, of course, assuming that you have Administrator access on your PC and have permission to install software.