How to update julia 0.4 without pain? - julia

Recently, I want to update my current 0.4.X version to latest 0.5.0. What's the best practice to accomplish this job?
Do I have to first remove my current version before installing the new one?
What about these installed packages, do I have to reinstall them one by one? Can my IDE (like Atom) support the new version automatically (or only with slight modification)?

Take the .julia/v0.4/REQUIRE file and plop it in .julia/v0.5, and then when you Pkg.update() it will add all of those packages. You might need to do using Atom in the REPL in order to have Juno properly re-compile before using it.

Related

Changing environment in Kaggle? (Option Disabled)

A kaggle (private) notebook of mine was created an year ago so it uses an environment (package versions) of the date when it was created. To use the latest package versions, there's an option to change Environment Preferences from within the Edit page of a notebook. But turns out, the option is disabled.
The only other way to get the latest package versions now is to upgrade them all manually by pip calls from within the notebook for each module. This was working fine until I required a newer version of pandas. You need to upgrade any module before importing in kaggle to use the upgraded version, otherwise it uses the old one. And pandas is one of the few libraries that is preloaded with every notebook start, so an upgrade call to it still does not use the latest pandas. What can I do here? Any tips on how I can enable the environment preference option?
It was a problem on Kaggle's end. They have rolled out a fix.
More details
If it happens again, create a thread on kaggle forum I guess, just like I did.

Automatically update package

I have written an R package, hosted on Github, that I would like users to always run the most up-to-date version. What is the best practice for checking within R, preferably at package loading, if there is a newer version? And if there is a newer version to download and install it.
I know I can get the current installed version using packageVersion('MyPackage').
I guess one way to get the repository version number would be to download the DESCRIPTION file, and use some regex to search for the version number. But is there a better way?
Having established that an update is available, is there then a safe way to install it from within the same package at loading. For example having something like
if (github_ver > installed_ver) {
install_github('MyRepository/MyPackage')
}
embedded in the .onLoad() hook? Although this way looks risky to me.

How to only install versions of packages that were made under a specific R release?

I use the Revolution R Enterprise distribution that is built upon R 3.2.2. Hence, I have an interest in only employing package versions that are based on this R release as well. Checking packages like 'checkpoint' or the Revolution MRAN page, I only found ways to access snapshots of CRAN datewise. Is there a way to install the most recent package versions still compatible with a certain R release?
I found a heuristical solution to my own problem:
Find out about the release date of the stable R version succeeding your working version.
Set up an R script that calls all the packages you need for your project via individual library() or require() calls.
Use checkpoint(release date minus at least one day) to automatically create a project specific library which is in harmony with your working R version.
Step 2 is a failsafe way to ensure detection of all necessary packages. I called them by sapply(package.list, require), which checkpoint() was not able to handle. A possible caveat against this solution might be that it possibly does not deliver the very last version of a package which is still compatible with your older R version. Alternatively, to be very sure, instead of the stable release one could use the prerelease date to be absolutely sure about compatibility.

What does "Running Meteor from a checkout" as seen in meteor (mrt) console output actually mean?

I have suddenly started getting the following message - all seems to work but i don't know why im getting it / what it really means for my app.
The only thing i can think of is that some smart-package im using is looking for an older version of meteor, and mrt is clever enough to not use a meteor version that will break it?
Stand back while Meteorite does its thing
Done installing smart packages
Ok, everything's ready. Here comes Meteor!
=> Running Meteor from a checkout -- overrides project version (0.6.2)
The thing is i'm pretty sure i want to be running on 0.6.2 not overriding it to some other version.
So what does this mean really? - and what do i need to do to not get it.
Thanks
I'm not too sure why it uses that odd terminology. Version 0.6.0 introduced project versions, so each project could run its own version of meteor similar to how meteorite does with smart.json
What Running Meteor from a checkout -- overrides project version (0.6.2) means is this version is overridden by the version in your smart.json. Typically the latest version on the master branch on github (which is checked out hence the wording). So at this moment if you ran mrt it would use 0.6.2.1
I'm sure over time meteorite will eventually be folded into meteor. 0.6.0 was just released a short while ago so some updates still need to be done to make them work better together.

Upgrading Tinn-R

I'm using Tinn-R version 2.2.0.2 and I want to upgrade to the latest version 2.3.4.4. I couldn't find any upgrade options in the menus of Tinn-R. So my question is: Is it safe to download and just install the new version? Will it overwrite my current Tinn-R settings?
As far as I can remember, the new version overwrites the existing one without a problem. In my case, however, the new version had many more problems in communicating with R console. For example it was very often the case that I was pressing the R send: selection button and nothing was happening.
I considered myself very lucky to have kept the Tinn-R 2.2.0.2 installer, and this is what I am using until now.
With every new version Tinn-R tries to preserve (as much as possible) the user's preferences related to old version.
These preferences are stored in a temporary file (INI). This file is never removed when the program is uninstalled.
Farrel is correct:
In the user guide it Clearly states que Should one uninstall the prior Tinn-R and then install the new version!
In time, it was released two new versions this week (with many new features):
3.0.1.8: http://sourceforge.net/p/tinn-r/news/2013/11/tinn-r-3018-released/
3.0.1.9: http://sourceforge.net/p/tinn-r/news/2013/11/tinn-r-3019-released/
I went through what you just did and switched because of it to notepad++ combined with NppToR.
Good luck,
Tal
Perhaps I am just a sheep who blindly follows but I stick to the instructions in the Tinn-R help file.
C:/Tinn-R/doc/english/user_guide/user_guide.html#basic_configuration_installconfigure
The easiest way to access the user guide is from the Tinn-R menu.
Help>Main>User guide>HTML
In the user guide it clearly states that one should uninstall the prior Tinn-R and then install the new version.

Resources