I'm on mac.
As far as I know, even though Julia 0.3 is now officially released, Julia Studio still comes prepackaged with Julia 0.2. So I went to the package contents of Julia 0.3 and pointed the path in Julia Studio at the julia folder for Julia 0.3, however I received the error message:
Error: Failed to start Julia.
Expected location: /opt/Julia_Studio/bin/julia-basic/bin/julia-basic
So I changed the julia executable in the bin folder from 'julia' to 'julia-basic', to see if that would fix things. What happened instead was I got a bunch of deprecation warnings and while the julia interactive prompt loaded, when I tried to execute a command and hit return it just sits there stupidly not giving me anything back. What do?
It's possible, but only for point releases.
Julia as a language is evolving rapidly. Each release of Julia Studio works only for a specific version. Forio will be release new versions of Julia Studio with support for the official Julia 0.3 release soon. The current master branch at https://github.com/forio/julia-studio supports Julia 0.3 but building on OSX is somewhat involved.
Disclaimer: I work for Forio
Last time I checked Julia Studio, it was not possible to point it at an external Julia release. This was a limitation I have heard others complain about as well.
I cannot tell if and when this limitation is overcome.
When it is capable of pointing at an external release, I will take another look at Julia Studio.
Related
The Visual Studio Code extension for Jupyter notebooks lead me to this page and now I see that it is a "Python" page even though my question is about Julia. Sorry if this is inappropriate.
The VSC Jupyter extension page has long said that users of a Julia kernel should use Visual Studio Code Insiders, which I have been doing. However, it's a bit of a hassle to keep two versions of VSC up to date with especially settings, theme modifications, etc.
My question is: Superficial inspection seems to show that the Jupyter notebook extension with Julia works OK in VSC; is VSC-Insiders still required or recommended for Julia users? I'm at version 1.63 for both VSC and VSC-Insiders.
No, I'm reasonably sure the only requirement at this point is that your VS Code version is at least 1.60.1.
I have upgraded R from 3.3.3 to 3.4.1 and am finding that typing text directly into the R Console quickly becomes very laggy, even when R isn't using a lot of resources. I have observed this behavior running the last couple versions of macos sierra (10.12.6, etc.).
It is notable that R functions are not particularly slow when executed. Most of the time I use Textmate 2 to pass code to the console and the code passed in this fashion runs without delay.
I've done extensive searching, but I haven't found anyone else reporting this problem. I've found this behavior on two different macs: 2013 Macbook 13" and 2017 Macbook 15" and have encountered the same problem.
Is there an easy solution to this problem that I'm missing?
The only answer I have been able to find is to roll back R to version 3.3.3, which is the last version before R began using Clang and GNU Fortran to compile the executable (https://cran.r-project.org/bin/macosx/ for more info).
This is not an optimal solution since I have to go back to previous versions of some packages I use (which is further complicated by the hunt for the right version of problematic dependencies). I have been looking through the r-devel threads and don't see a discussion of this, which surprises me because I know that I can't be the only person dealing with this. I will contact the r-devel folks and will update here if I get any additional info.
Update
The discussion on this question has identified that the issue is with the macos R GUI. Unfortunately, it appears that the R GUI developers are aware of this issue, but it is not being listed as a bug. The developers suggest clearing the console – not a workable solution for me given how quickly the problem crops up.
I have come up with a better solution, though it is kind of odd. I realized that since the problem is with the GUI and not R, you can take an old version of the GUI (they are available from the R macos development page). I was hoping to be able to use GUI version 1.69, but this caused a crash immediately. version 1.68 on the other hand does work.
I installed R 3.4.1 on my computer and then downloaded the binary file for GUI version 1.68 and copied it into my applications folder (you don't have to do this, but if you do, make sure to rename the program because otherwise you will replace R). I think opened R via the GUI and loaded R 3.4.1 on R Mac GUI version 1.68. So far it seems to be working fine, confirming that the problem is indeed in the GUI.
The issue actually appeared long ago (at R3.1.2 release) once the developers started to use a newer version of Xcode (I think they moved from v.5 to v.8 and above). At that time Simon told me that this is Xcode and Apple's problem, so they can't do anything about it. He did however forced the compilation with an older Xcode which "avoided" the issue till R3.4. I presume they can no longer use this work-around.
Possible solution:
Try running: rm(list = ls(all.names = TRUE)) This should remove everything from your R console, including hidden objects.
Then run .rs.restartR(), which will restart R. Hopefully, whatever is clogging up the program will be gone.
Have you tried RStudio? I highly recommend that GUI to work with R.
If you need more speed you should considering using R with modified matrix products. For example, to use R with openBLAS I wrote a tutorial here: http://pacha.hk/2017-07-12_r_and_python_via_homebrew.html
It is very common for Julia packages to support multiple version of Julia at once. The standard workflow is make modifications in ~/.julia/v0.x/PackageName and then run Pkg.test("PackageName") on the package, but this only tests the package in whatever Julia 0.x is and not other versions. The other versions can't see the local changes since the modifications were only made in 0.x folder. Currently, I rely on Travis on catching problems, but the turn around time is much slower than running tests locally.
What is the proper method for testing a package on multiple versions of Julia locally? Symbolic links?
Use symbolic links.
I've been using symbolic links since julia v0.3. It works reasonably well. I'll typically have the package checked out in the lower version directory, (say 0.4), and have symbolic links in the directories for 0.5 and 0.6. I do this for all packages that I'm actively working on. Everything else get duplicated as part of the Pkg.add/clone process.
This only works of course when you have a single branch of your package (typicaly master) that supports all julia versions, via Compat. In cases where you have different branches for different julia versions, you'll need to have separate checkouts for each julia version.
I'm trying to use the profvis package to do memory profiling of a large job in R (64 bit), run under RStudio, run under windows 7. profvis keeps crashing and I get an error message saying that Pandoc is out of memory. The message is copied below.
My understanding, and please correct me if this is wrong, is that the problem is likely to go away if I can set the /LARGEADDRESSAWARE switch on Pandoc. And to do that, I need to install a linker, etc., do my own build, after learning how to do all those things. Or, there is a shortcut, involving installing MS Visual Studio, running the editbin utility, and set the switch that way. However a new install of Visual Studio is unhappy on my machine, and demands that I fix some unspecified problem with Windows Management Instrumentation before it will go forward.
So my question is this: Is there a way to set the /LARGEADDRESSAWARE switch on Pandoc from inside R?
I had a similar problem and was able to resolve it by following the advice at https://www.techpowerup.com/forums/threads/large-address-aware.112556/. See in the post where it has an Attached File called laa_2_0_4.zip. I downloaded it and ran the executable it contains. Basic mode was sufficient; I simply navigated to C:/Program Files/RStudio/bin/pandoc/pandoc and turned on the checkbox for Large Address Aware Flag (step 2), then did Commit Changes (step 3). After this, the profvis-invoked pandoc command eventually ran to success. I was able to watch pandoc's memory consumption in Task Manager rise up to a peak of about 2.7 GB.
I've been looking all over, but I can't find anything free that will let me simply display math formulas on a window. I found one for Visual C++.net, but no APIs. Are there any out there?
What format are the Math formulas in?
My first impulse would be to try and find a LaTeX library for C++ which will let you render out LaTeX to an image. That way you could display most basic formulas, but the formulas would have to be in the LaTeX format.
Try ReforMath (http://reformath.webnode.com). Runs under both Windows and Linux. It is unfinished though, but can render a number of elements.
What a great question! Yes, there is now: latexpp.
You'll have to install VS 2017 Community first with the minimal amount of C++ features checked (so it doesn't take all day).
Then you install Boost using the binary (try the latest).
But you still have to build boost. By using the VS > Tools > Visual Studio Command Prompt. CD to your boost directory and run .\bootstrap.bat, then .\bjam.exe. This will take all day.
Good news is it seems to be working so far on Windows 7, 64-bit with VS 2017 community and the latest boost 1.6.x.
The Latex library has other requirements, and I still haven't tried it but will post my notes here if any hickups.
Make sure all your directories are short, such as C:\VisualStudio2017. However, boost will then fail if you use your regular windows command prompt unless you do the vcvarsall.bat trick. The VS Command Prompt does that for you, so that boost can find your MSVC stuff. Boost would still probably fail if you used the default directory and didn't use the VS command prompt.
So, again, my boost is in C:\boost_{blah version} which you should shorten to C:\boost assuming you'll only use one version of boost.
One reason is that if you have to add the respective /bin directories to your system Path, then you won't fail by maxing out the length of Path value (yes, it has a max length). Also stuff is easy to find and especially from the command line so you can cd quickly there. If you don't want everything in C:\ then make a C:\__TOOLS or something short.
I will post my notes here when I've gotten LaTeX rendered.
Notes
When building boost with bjam, if it seemingly hangs for more than 10 mins on one item, then hit ctrl-C at the command line once. This seems to unhang it without canceling the install.
TODO