✶ Troubleshoot errors when running the unstable DEV branch
Your "subtype declaration" section is wrong: the abstract type does not define a block (you should just have "abstract Foo", not "abstract Foo ... end")
The "String" type is deprecated in favor of AbstractString in 0.4
[1:10] is deprecated in 0.4, in favor of [1:10;] to explicitly vcat.
You can just use +, not .+, for element-wise addition. (It doesn't hurt to do .+, but it is unnecessary.)
help("func") is gone in 0.4
Pkg.build("Package") is useful to rebuild a package if the package build failed or your system configuration changed.
char(n) is deprecated in favor of Char(n) in 0.4
"Beware of multi-byte Unicode characters" is a bit misleading; it is not the Unicode "character" (technically you are referring to "codepoints") that is multi-byte, but rather the codepoint's encoding in UTF-8 (the default in Julia). Maybe "Beware of multi-byte Unicode encodings in UTF-8"
(Of course, there are many other subtleties with Unicode: e.g. your example string "Ångström" can also be written "Ångström", which looks identical but actually uses a different set of codepoints via "combining characters".)
UintN in Julia 0.4 is deprecated in favor of UIntN (note caps).
Note there is also Complex{T}; Complex128 is just a shorthand for Complex{Float64}.
im is the "imaginary unit", not the "imaginary number".
eps() is an abbreviation for eps(Float64). eps(T) is also defined for other types.
In 0.4, TypeName(val) automatically calls convert(TypeName, val) if no other constructor is available. This also means that, when you are defining your own type, you should extend Base.convert if you have new conversions, rather than adding constructors.
eye(N) is an NxN identity; calling it "N-dimensional" may confuse people into thinking it returns an N-dimensional array.
M' is a synonym for ctranspose(M) (conjugate transpose). M.' is transpose(M) without conjugation. Of course, for real matrices they are equivalent.
Note that we can also do "for i in 1:10" ... this syntax is perhaps a bit clearer in that it generalizes to iterating over other kinds of containers.
To exit a loop you do "break", not "exit" (which is a function).
Functions with ! appended mutate at least one of their arguments. Not necessarily the first one (e.g. see A_ldiv_B!), although this is the most common.
If you need tail-call optimization, it is more idiomatic to simply write a loop.
Instead of in(val,arr), you can simply do "val in arr"
The dictionary syntax has changed in 0.4: use Dict(a=>b, ...)
{...} is deprecated in 0.4. Use Any[...].
it is more idiomatic to put "do" on the same line:
map(collection) do elem
...
end
You can override Base.show(io, ex) rather than Base.showerror.
"import ModuleName" does not import "all names". It imports the module, but the only symbol imported is ModuleName itself; everything else must be accessed via ModuleName.something.
You should think of macros as being evaluated at parse-time, not run-time. Basically:
@test_approx_eq does not check equality to machine precision. It checks equality at much lower precision. In 0.4, you can also just use @test x ≈ y, where ≈ is \approx and is a synonym for the isapprox function.
The typical convention in Julia is to avoid underscores unless they are needed for readability. i.e. we have iseven, not is_even. This does not differ for variables vs. functions.
For performance, you should avoid abstract types in collections, but also as fields of types.
Fork a process or just ccall fork
any
and all
short-circuit, https://github.com/JuliaLang/julia/pull/11774empty!(Base.have_warned)
For starters, what something should belong to is not always unambiguous - viz. should a function that splits string a at every occurrence of b be a.split(b) or b.split(a)? None of the solutions is inherently significantly better than the other.
More importantly, search in Julia does not belong to either "Hello World" or e. It belongs to the current namespace. In OOP languages, x.f(y) is the combination of two things: f being under the namespace of x, and f being defined as f(self, y). self is then substituted with x, and so it effectively devolves to f(x, y). Classes are used as proxy namespaces, so that search would be held in the namespace of the string classed object "Hello World" in your example. The benefit of that is that you know where to look for the function. In Julia, there's an overarching namespace. There is an expense associated with that, which is why OOP languages do what they do. But just by changing how we express f(x, y) to x.f(y) or y.f(x) actually doesn't change any of that. Nothing short of actually implementing a full-blown class system with behaviours that properly 'belong to' classes does. Which is not what the design decision was when Julia was started. As such, while I like the syntactic simplification involved here, I just can't see how it would be either trivial but useless or useful but subverting some fundamental underlying design decisions.
./julia/<package>/
./src/
, keep the various source files. One, specifically is called "nomodule.jl". This contains a require(<types.jl>)
and "include(<functions.jl>)
reload("nomodule.jl
) from the REPL. This replaces all functions, except for the type definitions which can't be updated.ctrl-D; julia; reload("nomodule.jl")
which can be a bit of a pain.Pkg.clone(<github>)
to load a sort-of-stable version into ~/.juliaA cache. Other than that, no idea what it accomplishes (aside from reading the code to find out) or why it works the way it does. It was added in https://github.com/JuliaLang/julia/commit/df7a08893e4402182ec64178ffdb3130aa228943 but there are no design docs on the package manager. Ask Stefan. Also, .cache
moved to being shared between different versioned package directories on 0.4 because of https://github.com/JuliaLang/julia/pull/7361. It worked that way on unix in 0.3 as well. With better support for making directory junctions via the symlink function (which was still a pretty new feature when 0.3.0 was released), that PR made the behavior consistent on Windows as well.
import MyModule
will import package module on all workers (because @everywhere is redundant) which is @everywhere because if the module needs to be re-precompiled then it will be compiled only once.Old SO thread: http://stackoverflow.com/questions/14092316/simplest-ways-to-make-a-julia-package-available-to-others
To move a large number of packages installed on the old system to a new one, do Pkg.init()
, then copy only the REQUIRE
file from ~/.julia/v0.x/
folder, then do a Pkg.update()
on the cli.
To ping a package to a version, the correct command is: Pkg.checkout(pkg,branch)
. From, http://julia.readthedocs.org/en/latest/manual/packages/#checkout-pin-and-free
Set environment variable JULIA_PKGDIR
for all users : http://docs.julialang.org/en/release-0.4/stdlib/pkg/#Base.Pkg.dir
You can write using A, B
to use both A and B but then you can't list specific
bindings.
Example:
´´´using A: fooA, barA
using B: fooB, barB
´´´
REQUIRE is deprecated, try using these: (include, reload, using, import)
import
, https://github.com/JuliaLang/julia/issues/12069From Leah: I think his summary in #11031 is accurate, and the reason given directly in the reply is the reason for using/importall to be different. Issue #8000 is a discussion of ways to change/simplify the syntax.
I'll take a stab at rephrasing the different in case that helps. There is only one difference, and on the surface (syntax-wise) it may seem very minor. The difference between "using" and "importall" is that with "using" you need to say "function Foo.bar(.." to extend module Foo's function bar with a new method, but with "importall" or "import Foo.bar", you only need to say "function bar(..." and it automatically extends module Foo's function bar.
If you use "importall", then "function Foo.bar(..." and "function bar(..." become equivalent. If you use "using", then they are different.
The reason this is important enough to have been given separate syntax is that you don't want to accidentally extend a function that you didn't know existed, because that could easily cause a bug. This is most likely to happen with a method that takes a common type like string or int, because both you and the other module could define a method to handle such a common type. If you use importall, then you'll replace the other module's implementation of "bar(s::String)" with your new implementation, which could easily do something complete different (and break all/many future usages of the other functions in module Foo that depend on calling bar).
On Wednesday, September 30, 2015 at 9:27:29 PM UTC-4, Sebastian Good wrote:
Setting JULIA_PKGPATH lets me put everything in a more amenable spot, but transporting everything over to another identical machine results in inconsistent behavior with precompiled binaries. They are always “stale”. Is there a good resource to consult to understand binary staleness?
Staleness is determined by this function:
In particular, it is considered stale if the absolute path changes, or if the modification time of a dependency (which is checked via the absolute path) does not match the modification time of the file when the cache was created.
So, a precompiled image will be considered stale if you change the absolute path of the cache or source directories. It might be nice to make these relocatable without invalidating the cache.
However, in the meantime I don't think there is much downside to just having the user re-precompile the packages. Precompilation is very different than building the package; it doesn't require internet access or other external resources, and re-running precompilation can basically only fail if importing the package fails, in which case you probably have bigger problems.
I have built it all on Mac. It really was quite terrible--put it all in a bash script and its worse yet on Windows--I tried and quickly went to WinPython or PythonXY in preference to Anaconda or ActiveState, both of which I also tried. I am glad that I don't have to any more. Haven't had to for about a year and a half. Which is why we do want a decent approach to binary distribution. I agree that forking as a way to test innovation with an intention to eventually re-integrate is a fine way to make progress. A permanent fork, on the other hand, seems undesirable though it happens for a variety of reasons.
It appears that Python has stepped up to this, if belatedly and incompletely. There are pre-built binaries available for Mac and Windows for numpy, matplotlib, scipy, and pandas provided by the maintainers of those packages. These folks have stepped up and contributed a lot. There are wheels for Mac and Windows for all of them--except Numpy on Windows. In general, according to the scipy umbrella website, these binaries are targeted to the PSF binary distributions (2.7.10 and 3.5.0--with earlier versions available in many cases). I am afraid that Linux is more challenging though in some cases the package repos for the major distros offer binaries though those are likely to lag. I think the recent breakage in some Python packages has occurred in the cycle of upgrading to work with Python 2.7.10 and 3.5.0. Despite improvement it remains messy.
If Julia weren't so very good at integrating other things--Python, C, R, and using git as a package manager--we wouldn't be having the discussion. We are having it because Julia's core team carefully invested where it should--in the defining innovations of the language--while finding very efficient ways to bootstrap some of the maintenance "machinery" and leveraging other platforms for needed capabilities. The pace of progress, as a result, is simply astonishing for a language--really a nascent ecosystem--that has been here such a short time.
There are still issues managing large binary dependencies, but it must be done because having thousands of people build very large libraries doesn't make sense. I think Julia user-developers want to use the capabilities Julia provides without becoming sys admins. Sounds like the Julia core team has some ideas for this, especially for statically compiled pure Julia packages (bring'em on!). As to preferences for Python distributions, it seems a few things occasionally break when using PSF Python distro with pip managed packages. It used to work; it will get sorted out. Relying exclusively on a quasi-proprietary distro for the long-term doesn't seem like a good thing, though it has been expedient as an option and it is fine to have more than one option. It makes sense for Julia to provide a self-contained Python for Julia users, especially for matplotlib/PyPlot.jl but also because it is so easy to use PyCall for lots of things.
I stirred up a rat's nest here and I am dropping it. In a way, this is more of an issue for the Python community than the Julia community. Julia has adopted a new approach with more up to date and broadly adopted tooling (git--though the binary issue remains) which allows for much more rapid progress.
How to create a stable version of Julia + Gadfly + PyPlot + IJulia (+ other packages?) that prevents the students running Pkg.add(...)/Pkg.update()
, as packages have a tendency to occasionally break on updates, and it's a headache dealing with this during the lecture. The possible solutions are:
The Julia package manager lacks solutions to two problems that npm
solves with nested dependencies inside the project folder:
Pkg.restore()
to install everything you need.?
julia> Docs.@repl sin
search: sin sinh sind sinc sinpi asin using isinf asinh asind isinteger
julia> @doc sin
, where sin(x)
== Compute sine of x, where x is in radians
1) Create an account or sign in to GitHub https://github.com/ (my user name is TeroFrondelius and it's used from here on as an example) 2) Install Git to your computer https://git-scm.com/book/en/v2/Getting-Started-Installing-Git 3) Fork Julia to your repository https://github.com/JuliaLang/julia 4) Clone and build Julia from source to your computer (from your forked repository) https://github.com/JuliaLang/julia#source-download-and-compilation
`git clone git@github.com:TeroFrondelius/julia.git`
`cd julia`
`make -j 8`
5) Find the function documentation, which you want to write an example. Let's say you want to write more examples for round() function http://julia.readthedocs.org/en/latest/stdlib/math/#Base.round:
`find -name *.rst | xargs grep "round("` (this will help you to locate the ./doc/stdlib/math.rst file where the round() function documentation is written.
6) edit the ./doc/stdlib/math.rst with your favorite editor (i.e. Juno http://junolab.org/)
.. doctest::
julia> round(1.7)
2.0
7) run the doctest using the command make -C doc doctest
(and make sure your new doctest will pass)
8) Add updated files using command git add ./doc/stdlib/math.rst
9) Commit the files to your repository and add a description message:
git commit -m "new doctest for round()"
10) git push git@github.com:TeroFrondelius/julia.git 11) At your repository (https://github.com/TeroFrondelius/julia), create a pull request
julia> foo = "abc"; bar = "bac"; zoo = "234";
julia> if foo == "abc" && bar == "bac" && zoo != "123"
println("Please see http://docs.julialang.org/en/latest/manual/control-flow/")
end
Base.JLOptions().code_coverage
, (see https://github.com/JuliaLang/julia/blob/68b403f820fbd2f7401e12a90d487f41c96ca652/base/options.jl)using BinDeps, PkgName BinDeps.debug("PkgName")
Important DEV Notes from Tony
✶ Hey folks, an announcement for package authors and users who care about testing:
We've had support for Julia package testing on Travis CI for almost 9 months now, ref https://groups.google.com/forum/#!msg/julia-users/BtCxh4k9hZA/ngUvxdxOxQ8J if you missed the original announcement. Up to this point we supported the following settings for which Julia version to test against:
language: julia
julia:
- release
- nightly
Release has meant the latest release version in the 0.3.x series, and nightly has meant the latest nightly build of 0.4-dev master. Once Julia 0.4.0 gets released, the meaning of these settings will change, where release will be the latest version in the 0.4.x series, and nightly will be the latest nightly build of 0.5-dev master. Considering the wide install base and number of packages that may want to continue supporting 0.3 even after 0.4.0 gets released, we've just added support for additional version options in your .travis.yml file. You can now do
julia:
- release
- nightly
- 0.3
Or, if you want to test with specific point releases, you can do that too (there should not usually be much need for this, but it could be useful once in a while to compare different point releases):
julia:
- release
- nightly
- 0.3
- 0.3.10
The oldest point release for which we have generic Linux binaries available is 0.3.1. If you enable multi-os support for your repository (see http://docs.travis-ci.com/user/multi-os/), then you can go back as far as 0.2.0 on OS X. Note that you'd need to replace the default test script with the old-fashioned julia test/runtests.jl
since Pkg.test
and --check-bounds=yes
are not supported on Julia version 0.2.x. The downloads of those versions would fail on Linux workers so you may need to set up a build matrix with excluded jobs (see http://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix).
I've noticed many people with .travis.yml files that perhaps no longer mean quite what people think they do.
In particular:
language: julia julia:
Currently means "Test on Julia 0.3.11 and Julia 0.5-dev" When Julia 0.4.0 comes out, it'll mean "Test on Julia 0.4.0 and Julia 0.5-dev"
My preference has been to make it precise, so either
language: julia julia:
If you want to try to support all 3 versions, or
language: julia julia:
If you just want to support the stable versions, or
language: julia julia:
If you want to give up on 0.3 (which is fine, just make sure you update your REQUIRE file!)
So..
10 * [1:3] is fine
10 / [1:3] is an error
10 ^ [1:3] also erroneous
.*
, ./
and .^
for element-wise operations.https://stackoverflow.com/questions/24578430/changing-vertices-value-with-graphs-jl?rq=1
https://stackoverflow.com/questions/23480722/what-is-a-symbol-in-julia?rq=1
http://julia.readthedocs.org/en/latest/stdlib/ http://bogumilkaminski.pl/files/julia_express.pdf https://groups.google.com/forum/#!msg/julia-users/F4FQJMzbHsY/eRl7ZHl7KiIJ http://quant-econ.net/jl/julia_libraries.html https://github.com/stevengj/Cubature.jl/blob/master/src/Cubature.jl
A new Images.jl has been tagged and it now uses FileIO for image loading and saving. I've introduced FileIO in previous posts to this mailing list; it improves the the ability to dynamically choose package(s) for image I/O.
One consequence is that by default, you may not have any installed image loaders. If you're using Images interactively, FileIO will likely prompt you to install appropriate package(s) as it discovers you need them.
However, this doesn't happen in "non-interactive" usage. So, if you maintain a package whose tests depend on loading or saving images, I highly recommend adding a test/REQUIRE file that specifies the package(s) you need for image I/O. For example:
Contents of MyPkg/test/REQUIRE: ImageMagick
That should do the trick for the large majority of cases.