I have installed Atom and julia 1.0.0, the julia-client and uber-juno all installed,but why it cant run ?enter image description here
Juno supports Julia v0.7 for now, not v1.0 yet. Please install Julia v0.7 as it provides the same new features as v1.0 and not yet removed the deprecated ones from v0.6.x.
Related
On Ubuntu in a Conda environment with Python 3.7.3, when I run
conda install -c conda-forge opencv
I get OpenCV 3.4.2 (checked with import cv2 and then cv2._version__) even though https://anaconda.org/conda-forge/opencv indicates version 4.11. Why?
Note that I didn't have OpenCV installed previously (I ran conda uninstall opencv and it got completely removed)
tl;dr You likely have previously installed dependencies that need updating. If you require a specific version, say 4.1, then express this to Conda:
conda install -c conda-forge opencv=4.1
Explanation
How Conda Interprets Specifications
A literal translation of the command
conda install -c conda-forge opencv
would go something like
With the conda-forge channel included, ensure that some version of the package opencv is installed in the currently active environment.
The logic here implies that any version it can install would be a valid solution. It also doesn't tell it that it must come from Conda Forge, only that that channel should be included.1
Two-Stage Solve Strategy
Starting with v4.7, Conda uses a two-stage dependency solving strategy. The two stages are
Solve with an implicit --freeze-installed|--no-update-deps flag. This attempts to find the newest version of the requested package that has no conflicts with installed packages. That is, it considers any installation of the package, no matter the version, to be a satisfactory solution. If it works, then it's done. Otherwise, move on to...
An unrestricted solve (what used to be default in Conda < 4.7). This frees up dependencies to be updated and will often result in the latest versions being installed unless there are previous explicit specifications on those packages.2
This strategy aims to provide a faster solve and install experience, by avoiding having to change anything in your environment. It also helps keep the environment stable by avoiding unnecessary version changes.
Specific Failure in Question
What happened in OP's case? One of the dependencies requirements of OpenCV was likely newer in v4.1.1 than what was already installed, but that dependency's version was compatible with installing OpenCV 3.4.2. Hence, the only thing that would change was adding opencv plus missing dependencies. Technically, this is a valid solution since one only asked for some version of opencv to be installed.
Getting the Latest Version
Option: Specifying the Version
If you know you want a specific version then you can always specify it
conda install -c conda-forge opencv=4.1.1
and since Conda can't install this without updating something in your env, the first round of solve will fail, and the full solve will get it for you.
Option: Skip the Freeze
Of course, you may not always know what the latest version number is and don't want to have to look this up on Anaconda Cloud every time. Fortunately, there is the --update-deps flag that essentially skips over the first solve stage and goes straight to the full solve. This will install the latest version for your system, as well as update any of the dependencies.
conda install --update-deps -c conda-forge opencv
Important Note: The --update-deps flag has a side-effect of converting dependencies to explicit specifications. While this is an internal environment state (managed through <env>/conda-meta/history), it does have some behavioral consequences (bugs!):
the result of the conda env export --from-history command will subsequently include all packages, instead of just the ones the user explicitly requested in the past
conda remove will not be able to prune dependencies; e.g., if scipy was installed, it would pull in numpy; if only scipy depended on numpy and scipy was removed, normally numpy would also get removed. This wouldn't work after using the --update-deps flag.
[1]: The behavior here depends on the channel_priority configuration option. With the strict setting, conda-forge would be prioritized over other channels; with the flexible setting, it is simply added to the list and the latest compatible version from any channel is selected.
[2]: One can check the explicit specifications of an environment with conda env export --from-history.
What is the difference between Julia and Julia Pro offered by Julia Computing?
Does Julia Pro have any enterprise library which isn't available in Julia?
As you can read in the project description there are a few optional packages you can install on top of the "free version" (mostly in the area of Excel integration and business workflow), but the main "difference" is in the installation process, expecially in Windows or Mac:
With standard Julia you need three steps: install Julia itself, install an editor (e.g. Juno/Atom or VScode with the Julia extension), add the desired packages.
With JuliaPro, you have these three steps by just clicking an installer.
Julia Pro is a all in one simple solution as Anaconda for Python.
I just upgraded Julia from 1.3.1 to 1.4.2. That worked well. However, when I start Juno it still uses the old Julia version. How can I fix this?
(I'm working on a Windows 10 machine, but I guess answers for other OS' should be helpful as well.)
You can set the path in the Atom package settings of the julia-client package (shortcut to get there is Ctrl+J followed by Ctrl+,):
I am running R 3.6.1 on a Mac Mini running Sierra and a MacBook Pro running El Capitan. I normally get all the R packages that I need from CRAN or github and use them without issues, but I am trying to install and use an R package (NicheMapR) that requires a fortran compiler and this is giving me issues. Even after installing gfortran, the R package still does not work (the fortran code seems to be compiled but the package installation fails). The package developer suggested that installing R via homebrew might solve the problem. On the contrary, my hunch is that it would lead to a world of pain, to quote Walter from the Big Lebowski. My questions are:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Can the two versions coexist?
Is the homebrew version going to affect the regular one?
Finally: is homebrew going to help or will it simply open a whole
new can of worms?
Many thanks in advance.
Yes, installing from homebrew is a recipe for pain. It's specifically recommended against by the official CRAN binary maintainer see his remarks from March 2016 on r-sig-mac.
Regarding your questions, this can be summarized as:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Positives: Select your own BLAS and easily work with geospatial tools.
Downsides: Always needing to compile each R package.
Can the two versions coexist?
Yes. The homebrew version installs into a different directory. But, watch out for library collision (see next question). However, you will have to deal with symbolic linking regarding what version of R is accessible from the console and you will also need to look into using RSwitch to switch between R versions.
Is the homebrew version going to affect the regular one?
Yes, if the library paths overlap. There will be problems regarding package installation and loading. Make sure to setup different library paths. To do so, please look at the .libPaths() documentation.
Finally: is homebrew going to help or will it simply open a whole new can of worms?
Yes and no. Unless you know what you're doing, opt for the CRAN version of R and its assorted goodies.
I'm planning a new build system for our project running on Centos 5.4. I intend to use SCons. I noticed the latest stable SCons version is 2.0.1 while Centos 5.4 comes with 1.2.
I'm new to SCons so I'd like to understand more about the features/stability ratio between the versions.
Would you recommend installing and using the latest version or sticking to what comes from my OS repository?
Since 1.2 the changes have been bug fixes and documentation improvements. There haven't been any new features.
The 2.x version of SCons drops support for Python versions older than 2.4, updating some of the internal code to use newer idioms but without affecting any user visible APIs. That's the reason for the major version number change. If CentOS comes with a recent version of python then this won't affect you either way.
There have been a lot of fixes for newer versions of the various Microsoft compiler versions, but this won't affect a CentOS install.
The bug fixes since SCons 1.2.0 also solve problems in the Fortran, TeX and LaTeX builders. If you make use of Fortran or LaTeX then it would probably be worth upgrading. Otherwise I think you would be hard pushed to spot any day-to-day difference between 1.2.0 and 2.0.1.