Re: [julia-users] ReadOnlyMemoryError() after Pkg.init()??

[Tony Kelman]

I think you'll have to run in a debugger, either Gallium.jl (installed manually 
since Pkg isn't working for you) or gdb or lldb, to see exactly where the error 
is happening in libgit2 cloning METADATA. Do the 0.5.0 generic Linux release 
binaries have the same problem?

[julia-users] ReadOnlyMemoryError() after Pkg.init()??

[Tony Kelman]

Was this by any chance a source build in the same git clone where you had 
previously compiled the master 0.6-dev branch of julia?

Re: [julia-users] problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[Tony Kelman]

Most likely there are various platform-checking if statements that don't 
properly handle the freebsd situation of being not linux and not macos and not 
windows. Does Atom support FreeBSD, do they have binaries available? If so, a 
few more careful fallbacks might be able to fix this?

[julia-users] Re: Julia not working - Xcode needs updating...

[Tony Kelman]

This is coming from Homebrew (https://github.com/Homebrew/brew/pull/1384) 
which is used by several packages to manage binary dependencies on mac.

On Sunday, October 30, 2016 at 9:30:46 AM UTC-7, dayc...@icloud.com wrote:
>
> So I got back from a week away from the computer, and Julia's suddenly not 
> working on my Mac (it's mainly due to Cairo.jl, I think), and when I try to 
> rebuild it it appears to be that my version of Xcode is out of date:
>
> Error: Your Xcode (8.0) is outdated.
> Please update to Xcode 8.1 (or delete it).
> Xcode can be updated from the App Store.
>
> Which is fine
>
> But, Xcode 8.1 was released on Thursday 27th (related to this week's Apple 
> Event I suppose). That's only a couple of days ago! I like the 
> responsiveness (I think) and we're all used to living on the bleeding edge, 
> but it's still surprising that this happened so quickly, and that there's 
> no notice or anything anywhere, that I could see, that Julia installations 
> would be broken immediately they released a new version of Xcode.
>
> Was I the only one affected !?
>
>

[julia-users] Re: VS code extension

[Tony Kelman]

The repo's MIT licensed, so unless this person changed the license of their 
additions, yes. Best to preserve git authorship attribution if you can. 
Pull requests to the JuliaEditorSupport repository are encouraged, I 
imagine.


On Friday, October 28, 2016 at 3:31:56 AM UTC-7, Zac wrote:
>
> Hi, I'm using a fork of this that implements completions, function 
> parameter hints, documentation hovers, linting and definitions. I pulled it 
> from another fork that has subsequently disappeared (github.com/novatena). 
> This 
>
> Given that someone else did most of the work is it ok to share it here? 
>
> On Tuesday, July 5, 2016 at 4:33:06 PM UTC, FANG Colin wrote:
>>
>> Thank you.
>>
>> I used to use https://github.com/Mike43110/julia.vscode which 
>> unfortunately doesn't provide the command for mark selection as comments. 
>>
>

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Tony Kelman]

Given that we're not going to change either llvm or libgit2 to use anything 
other than cmake, and other dependencies are increasingly adopting it as 
well, it's pretty much inevitable that we'll eventually use it if 
first-class MSVC support is ever going to happen. We're very much doing the 
wrong backwards thing by invoking cmake from gnu make, it's not designed 
for that workflow to do the right thing at all. I'm not surprised version 
upgrades confuse it.


On Thursday, October 27, 2016 at 7:27:08 AM UTC-7, Isaiah wrote:
>
> Or even better: let's remove a lot of complexity and move the whole Julia 
>> build system to CMake.
>
>
> The main advantage I see to CMake is support for Visual Studio. I would 
> not consider it a reduction of complexity -- CMake is very much like 
> regexes: now you have two problems. Or perhaps three...
>
> set(number_problems 3 FORCE CACHE PARENT_SCOPE)
>
> I think I saw an issue about this some time
>
>
> https://github.com/JuliaLang/julia/pull/11754
>
>
> On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens  > wrote:
>
>>
>> On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton > > wrote:
>>
>>>
 I'm not sure if there's any good way to introspect this and trigger a 
>>> reconfigure from Julia's build system without adding a lot of complexity.
>>>
>>
>> Or even better: let's remove a lot of complexity and move the whole Julia 
>> build system to CMake. I think I saw an issue about this some time, so I 
>> guess it's non-trivial, but I'd be willing to help.
>>
>
>

[julia-users] Pkg.add("IJulia") fails

[Tony Kelman]

What version of windows are you using?

[julia-users] Re: CoinOptServices

[Tony Kelman]

Look at the actual logs. It installs fine, just has a handful of known test 
failures that are due to bugs in the upstream library. Something is preventing 
the lapack dll from being overwritten on your system. That's not a problem 
that's been seen anywhere else as far as I'm aware.

[julia-users] Re: CoinOptServices

[Tony Kelman]

do you have the lapack dll opened by some other julia process?

[julia-users] Re: How to install JuMP without SSL errors?

[Tony Kelman]

If you don't have a really good reason to be using 0.6-dev right now, you 
shouldn't be. Use 0.5.0 if at all possible.


On Sunday, October 16, 2016 at 8:55:07 AM UTC-7, Rick Graham wrote:
>
> Ref:  https://github.com/JuliaOpt/JuMP.jl/issues/864
>
> I can't seem to add package JuMP.  Other packages seem to be added fine.
>
> How can I fix this?
>
> OS: Fedora 24
>
> julia> versioninfo()
> Julia Version 0.6.0-dev.986
> Commit 6c9f5af (2016-10-16 05:19 UTC)
> Platform Info:
>   OS: Linux (x86_64-redhat-linux)
>   CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>
>
>
> julia> Pkg.add("JuMP")
> INFO: Cloning cache of Calculus from 
> https://github.com/johnmyleswhite/Calculus.jl.git
> INFO: Cloning cache of DataStructures from 
> https://github.com/JuliaLang/DataStructures.jl.git
> INFO: Cloning cache of ForwardDiff from 
> https://github.com/JuliaDiff/ForwardDiff.jl.git
> INFO: Cloning cache of JuMP from https://github.com/JuliaOpt/JuMP.jl.git
> ERROR: Cannot clone JuMP from https://github.com/JuliaOpt/JuMP.jl.git. SSL 
> error:  - UNKNOWN ERROR CODE (0001)
>  in prefetch(::String, ::String, ::Array{String,1}) at ./pkg/cache.jl:56
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, 
> ::Set{String}) at ./pkg/entry.jl:512
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:476
>  in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, 
> ::Vararg{Base.Pkg.Types.VersionSet,N}) at ./pkg/entry.jl:30
>  in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at 
> ./task.jl:363
>  in sync_end() at ./task.jl:314
>  in macro expansion at ./task.jl:330 [inlined]
>  in add(::String, ::Base.Pkg.Types.VersionSet) at ./pkg/entry.jl:50
>  in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() 
> at ./pkg/dir.jl:31
>  in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, 
> ::String) at ./file.jl:69
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) 
> at ./pkg/dir.jl:31
>  in add(::String) at ./pkg/pkg.jl:100
>
>

[julia-users] Re: run command inserting spurious newlines into return values

[Tony Kelman]

Powershell has types for xml, so maybe telling it to expect an xml result (or 
convert the string to xml) would result in different output formatting?

[julia-users] Re: BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Tony Kelman]

It starts with / so it's an absolute path, and system-wide. Either don't 
include the leading /, or use one of the BinDeps "dir" functions to determine 
what to set prefix to. The autotools provider probably sets an okay default for 
that, but check what other packages do.

[julia-users] Re: BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Tony Kelman]

sounds like the library can't handle out of tree builds? you should also use a 
local prefix, not a system-wide one that would require sudo.

[julia-users] BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Tony Kelman]

Try using the unpacked_dir keyword argument to the Sources provider to tell it 
the github tarball has a different folder name that it extracts to than its 
default assumption.

[julia-users] Ancient Gfortran/GCC version in Travis-CI image

[Tony Kelman]

Check the travis docs for the apt sources and packages addons to install newer 
compiler versions from the Ubuntu toolchain ppa.

[julia-users] Re: Changing Repositories Without Deleting METADATA

[Tony Kelman]

The conclusion I'd take out of that is not to use GitHub Desktop. It tries to 
hide too many important things like this from you. As far as git GUIs go, try 
SourceTree, it has a much more direct mapping between command line operations 
and GUI buttons.

Re: [julia-users] Generic Linux binaries for julia-0.4.6

[Tony Kelman]

We can add a note to the downloads page saying that past versions are still 
available by just modifying the version number in the url, if that would 
help.


On Saturday, October 1, 2016 at 2:17:09 AM UTC-7, Mauro wrote:
>
> On Sat, 2016-10-01 at 10:38, ami...@gmail.com  wrote: 
> > Great, a bit ashamed I didn't even try that... Thank you Mauro. 
>
> No worries, if I recall correctly, I know because I had asked too... 
>

[julia-users] copying package repository for update to 0.5

[Tony Kelman]

A number of packages end up storing absolute paths in generated files. You'll 
likely need to re-run Pkg.build().

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

Okay, the buildbot that was down was running centos which is failing some 
of the tests due to this very change. We need to come up with a good fix 
for the certificates location lookup issue on non-debian-based 
distributions (https://github.com/JuliaLang/julia/issues/18693) before new 
nightlies will get published.


On Thursday, September 29, 2016 at 12:11:18 PM UTC-7, Tony Kelman wrote:
>
> nighties were a few days behind, I needed to log in and reconnect a few of 
> the buildbots. Check in a few hours if the nightlies are dated with commits 
> from today.

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

nighties were a few days behind, I needed to log in and reconnect a few of the 
buildbots. Check in a few hours if the nightlies are dated with commits from 
today.

[julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

Should be fixed on nightly and hopefully in a future 0.5.x point release. 
In the meantime try installing openssl and/or krb5?


On Thursday, September 29, 2016 at 6:20:19 AM UTC-7, Bill Hart wrote:
>
> We are having problems running the Generic 64 bit x86 Linux binary on 
> Gentoo. It appears to be looking for some Kerberos library. Is there 
> something we need to install?
>
> The German message below just says, "Cannot open the shared-object-file: 
> file or directory not found"
>
> fatal: error thrown and no exception handler available.
> Base.InitError(mod=:LibGit2, error=ErrorException("could not load library 
> "libgit2"
> libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei oder 
> Verzeichnis nicht gefunden"))
> rec_backtrace at 
> /home/centos/buildbot/slave/package_tarball64/build/src/stackwalk.c:84
> record_backtrace at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:232
> jl_throw at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:550
> jl_errorf at 
> /home/centos/buildbot/slave/package_tarball64/build/src/builtins.c:78
> jl_dlerror at 
> /home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:69 
> [inlined]
> jl_load_dynamic_library_ at 
> /home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:209
> jl_get_library at 
> /home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:152
> jl_load_and_lookup at 
> /home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:163
> unknown function (ip: 0x7f6334fe9346)
> __init__ at ./libgit2/libgit2.jl:538
> unknown function (ip: 0x7f6334fe9b58)
> jl_call_method_internal at 
> /home/centos/buildbot/slave/package_tarball64/build/src/julia_internal.h:189 
> [inlined]
> jl_apply_generic at 
> /home/centos/buildbot/slave/package_tarball64/build/src/gf.c:1942
> jl_apply at 
> /home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392 
> [inlined]
> jl_module_run_initializer at 
> /home/centos/buildbot/slave/package_tarball64/build/src/toplevel.c:83
> _julia_init at 
> /home/centos/buildbot/slave/package_tarball64/build/src/init.c:742
> julia_init at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:283
> main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.c:231
> __libc_start_main at /lib64/libc.so.6 (unknown line)
> unknown function (ip: 0x4013fc)
>
> Bill.
>

[julia-users] Re: PkgDev.tag issues

[Tony Kelman]

The "no changes to commit" issue sounds like 
https://github.com/JuliaLang/PkgDev.jl/issues/28, especially since you're 
on Windows. I don't know what's going on there or where to start debugging. 
I'm a little surprised you're only the second one to report the issue, I'd 
think it would have happened to more people by now. What version of Windows?


On Saturday, September 24, 2016 at 11:16:35 PM UTC-7, Brandon Taylor wrote:
>
> Ok, I deleted the extraneous tags, and retagged. Same thing messages about 
> no changes to commit.
>
> So I git added the new v0.1.0 folder and then committed manually.
>
> Then I tried PkgDev.publish() and I got this:
>
> ERROR: GitError(Code:EAUTH, Class:None, No errors)
>  in macro expansion at .\libgit2\error.jl:99 [inlined]
>  in #push#53(::Bool, ::Base.LibGit2.PushOptions, ::Function, 
> ::Base.LibGit2.GitRemote, ::Array{String,1}) at .\libgit2\remote.jl:84
>  in (::Base.LibGit2.#kw##push)(::Array{Any,1}, ::Base.LibGit2.#push, 
> ::Base.LibGit2.GitRemote, ::Array{String,1}) at .\:0
>  in #push#94(::String, ::String, ::Array{String,1}, ::Bool, 
> ::Nullable{Base.LibGit2.UserPasswordCredentials}, ::Function, 
> ::Base.LibGit2.GitRepo) at .\libgit2\libgit2.jl:185
>  in (::Base.LibGit2.#kw##push)(::Array{Any,1}, ::Base.LibGit2.#push, 
> ::Base.LibGit2.GitRepo) at .\:0
>  in 
> (::PkgDev.Entry.##6#11{Dict{String,Array{String,1}}})(::Base.LibGit2.GitRepo) 
> at C:\Users\jsnot\.julia\v0.5\PkgDev\src\entry.jl:114
>  in with(::PkgDev.Entry.##6#11{Dict{String,Array{String,1}}}, 
> ::Base.LibGit2.GitRepo) at .\libgit2\types.jl:638
>  in publish(::String, ::String) at 
> C:\Users\jsnot\.julia\v0.5\PkgDev\src\entry.jl:97
>  in publish() at C:\Users\jsnot\.julia\v0.5\PkgDev\src\PkgDev.jl:70
>
> So then I tried to checkout PkgDev as suggested here:
> https://github.com/JuliaLang/PkgDev.jl/issues/69
>
> and now I'm getting
>
> INFO: Validating METADATA
> INFO: Creating a personal access token for Julia Package Manager on GitHub.
> You will be asked to provide credentials to your GitHub account.
> Enter host password for user 'bramtayl':
> INFO: Pushing ChainMap permanent tags: v0.1.0
> INFO: Submitting METADATA changes
> INFO: Forking JuliaLang/METADATA.jl to bramtayl
> INFO: Pushing changes as branch pull-request/2ed12a90
> ERROR: GitError(Code:ERROR, Class:Net, Remote error: access denied or 
> repository not exported: /2/nw/29/05/c9/6106340/69147216.git)
>  in macro expansion at .\libgit2\error.jl:99 [inlined]
>  in #push#53(::Bool, ::Base.LibGit2.PushOptions, ::Function, 
> ::Base.LibGit2.GitRemote, ::Array{String,1}) at .\libgit2\remote.jl:84
>  in (::Base.LibGit2.#kw##push)(::Array{Any,1}, ::Base.LibGit2.#push, 
> ::Base.LibGit2.GitRemote, ::Array{String,1}) at .\:0
>  in #push#94(::String, ::String, ::Array{String,1}, ::Bool, 
> ::Nullable{Base.LibGit2.UserPasswordCredentials}, ::Function, 
> ::Base.LibGit2.GitRepo) at .\libgit2\libgit2.jl:185
>  in (::Base.LibGit2.#kw##push)(::Array{Any,1}, ::Base.LibGit2.#push, 
> ::Base.LibGit2.GitRepo) at .\:0
>  in (::PkgDev.Entry.##2#3)(::Base.LibGit2.GitRepo) at 
> C:\Users\jsnot\.julia\v0.5\PkgDev\src\entry.jl:39
>  in with(::PkgDev.Entry.##2#3, ::Base.LibGit2.GitRepo) at 
> .\libgit2\types.jl:638
>  in #pull_request#1(::String, ::String, ::String, ::Function, ::String) at 
> C:\Users\jsnot\.julia\v0.5\PkgDev\src\entry.jl:15
>  in (::PkgDev.Entry.#kw##pull_request)(::Array{Any,1}, 
> ::PkgDev.Entry.#pull_request, ::String) at .\:0
>  in publish(::String, ::String) at 
> C:\Users\jsnot\.julia\v0.5\PkgDev\src\entry.jl:121
>  in publish() at C:\Users\jsnot\.julia\v0.5\PkgDev\src\PkgDev.jl:70
>
>
> On Saturday, September 24, 2016 at 10:02:21 PM UTC-4, Tony Kelman wrote:
>>
>> You may have to remove the git tag from your local clone of the package 
>> repo.
>
>

[julia-users] Re: PkgDev.tag issues

[Tony Kelman]

You may have to remove the git tag from your local clone of the package repo.

[julia-users] Re: LightXML Ubuntu 16.04 julia 0.4.5

[Tony Kelman]

You might need the -dev version to get a plain "libxml2.so" in addition to 
the version with an soname in it. I thought Julia should be able to find 
the soname versions too, but maybe not?


On Saturday, September 24, 2016 at 5:34:12 AM UTC-7, Ján Adamčák wrote:
>
> I tried sudo apt-get install libxml2, but I got answer from ubuntu:
>
> libxml2 is already the newest version (2.9.3+dfsg 1-1ubuntu0.1).
> libxml2 is tagged as manually installed.
>
> But from julia I got same answer:
>
> ERROR: error compiling call: could not load library "libxml2"
>
>
>
> Dňa sobota, 24. septembra 2016 14:18:27 UTC+2 Kaj Wiik napísal(-a):
>>
>> Try
>>
>> sudo apt install libxml2
>>
>>
>>
>> On Saturday, September 24, 2016 at 12:52:46 PM UTC+3, Ján Adamčák wrote:
>>>
>>> Hi Guys,
>>>
>>> I tried use LightXML on Ubuntu 16.04, but I got an error: 
>>>
>>> ERROR: error compiling call: could not load library "libxml2"
>>>
>>> Can You help me?
>>>
>>> Thanks.
>>>
>>> Log:
>>>
>>>  _
>>>   _   _ _(_)_ |  A fresh approach to technical computing
>>>  (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>>   _ _   _| |_  __ _   |  Type "?help" for help.
>>>  | | | | | | |/ _` |  |
>>>  | | |_| | | | (_| |  |  Version 0.4.5 (2016-03-18 00:58 UTC)
>>> _/ |\__'_|_|_|\__'_|  |  
>>> |__/   |  x86_64-linux-gnu
>>>
>>> julia> Pkg.status()
>>> No packages installed
>>>
>>> julia> Pkg.add("LightXML")
>>> INFO: Cloning cache of Compat from git://
>>> github.com/JuliaLang/Compat.jl.git
>>> INFO: Cloning cache of LightXML from git://
>>> github.com/JuliaIO/LightXML.jl.git
>>> INFO: Installing Compat v0.9.2
>>> INFO: Installing LightXML v0.4.0
>>> INFO: Building LightXML
>>> INFO: Package database updated
>>> INFO: METADATA is out-of-date — you may not have the latest version of 
>>> LightXML
>>> INFO: Use `Pkg.update()` to get the latest versions of your packages
>>>
>>> julia> Pkg.update()
>>> INFO: Updating METADATA...
>>> INFO: Computing changes...
>>> INFO: No packages to install, update or remove
>>>
>>> julia> using LightXML
>>> INFO: Precompiling module LightXML...
>>>
>>> julia> # create an empty XML document
>>>   xdoc = XMLDocument()
>>> ERROR: error compiling call: could not load library "libxml2"
>>>
>>>
>>>
>>>
>>>

Re: [julia-users] Re: Adding publications easier

[Tony Kelman]

Yeah I didn't realize the readme was suggesting that either, sorry. We should 
automate the complicated part on our side.

[julia-users] PkgDev.tag issues

[Tony Kelman]

What does Pkg.status() say? What operating system are you using? What is git 
status in METADATA and the package repo?

[julia-users] Re: Problem with 0.4.7 mac os distribution

[Tony Kelman]

This was a temporary hiccup with a buildbot misconfiguration issue in one of 
the pieces of software we use (but are about to stop using) to build the mac 
binaries. We uploaded a replacement build that should have this fixed, try 
removing the copy of 0.4.7 you downloaded and replacing it with a fresh copy.

[julia-users] Adding publications easier

[Tony Kelman]

What do you propose? Github is about as simple as we can do, considering also 
the complexity of maintaining something from thr project side. There are plenty 
of people around the community who are happy to walk you through the process of 
making a pull request, and if it's not explained in enoug detail then we can 
add more instructions if it would help. What have you tried so far?

[julia-users] ANN: Julia v0.5.0 released!

[Tony Kelman]

At long last, we can announce the final release of Julia 0.5.0! See the 
release notes at 
https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md for more 
details, and expect a blog post with some highlights within the next few 
days. Binaries are available from the usual place 
, and please report all issues to either 
the issue tracker  or email the 
julia-users list. Don't CC julia-news, which is intended to be low-volume, 
if you reply to this message.

Many thanks to all the contributors, package authors, users and reporters 
of issues who helped us get here. We'll be releasing regular monthly bugfix 
backports from the 0.5.x line, while major feature work is ongoing on 
master for 0.6-dev. Enjoy!


We haven't made the change just yet, but to package authors: please be 
aware that `release` on Travis CI for `language: julia` will change meaning 
to 0.5 shortly. So if you want to continue supporting Julia 0.4 in your 
package, please update your .travis.yml file to have an "- 0.4" entry under 
`julia:` versions. When you want to drop support for Julia 0.4, update your 
REQUIRE file to list `julia 0.5` as a lower bound, and the next time you 
tag the package be sure to increment the minor or major version number via 
`PkgDev.tag(pkgname, :minor)`.

[julia-users] ANN: Julia 0.4.7 released

[Tony Kelman]

Hello all! The latest bugfix release of the Julia 0.4.x line has been 
released. We've been a bit distracted with 0.5 release candidates so this 
also took longer than our usual monthly target. This may be the last 
release of the 0.4 line, unless new issues are brought to our attention 
that need backporting to the release-0.4 branch. Binaries are available 
from the usual place  (however the links 
for 0.4.7 will be moved to the old releases page very soon), and as is 
typical with such things, please report all issues to either the issue 
tracker , or email the 
julia-users list. If you reply to this message on julia-users, please do 
not cc julia-news which is intended to be low-volume.

This is a bugfix release, see this commit log 
 for the list 
of bugs fixed between 0.4.6 and 0.4.7. Bugfix backports to the 0.4.x line 
may continue if necessary. If you are a package author and want to rely on 
functionality that did not work in earlier 0.4.x releases but does work in 
0.4.7 in your package, please be sure to change the minimum julia version 
in your REQUIRE file to 0.4.7 accordingly. If you're not sure about this, 
you can test your package specifically against older 0.4.x releases on 
Travis and/or locally.

This is a recommended upgrade for anyone using previous releases who 
intends to keep using Julia 0.4 even after Julia 0.5.0 gets released, and 
should act as a drop-in replacement for prior 0.4.x releases. If you find 
any regressions relative to previous releases, please let us know.

-Tony

Re: [julia-users] Re: julia installation broken

[Tony Kelman]

This sounds like it may have been a download issue or a corrupt repo, 
and/or a bug in any fallback code that Pkg might contain to attempt to deal 
with problems in cloning. If you can reproduce it reliably, would be 
valuable to report the sequence of steps you used to get into the error 
state.


On Sunday, September 18, 2016 at 6:38:52 AM UTC-7, Michael Borregaard wrote:
>
> Thanks a lot, Jeffrey! Incredibly, this worked.
>
> Best,
> Michael
>
> On Fri, Sep 16, 2016 at 6:48 PM, Jeffrey Sarnoff  > wrote:
>
>> I have had this happen, too.  My suggestion is  grounded in persistence 
>> rather than deep mastery of Julia's structural and file relationships.
>> So someone else may have a more studied approach with some explaining.  
>> Until then,
>>
>> quit() Julia.
>> To have an new install be really clean, first cd  to /.julia/ 
>> and delete the directory `v0.5` -- if that is overkill because you do not 
>> want to redo many Pkg.add()s then cd v0.5 and delete the METADATA directory 
>> the REQUIRE file and the META_BRANCH file and the entry for whatever 
>> packages you had added just before this difficulty (including those that 
>> have hiccuped on precompile).   
>> now delete and then reget the most current binary for your system 
>> julia-0.5.0-rc4-osx10.7+.dmg 
>>
>> 
>> install
>> Then start julia and quit().  Then start Julia and do Pkg.update() then 
>> quit().
>> Then start julia and do Pkg.add() for 1 package you want then quit(). 
>> then start julia and do using  (so it precompiles) and quit().
>> now try using that package.
>>
>>
>>
>>
>>
>>
>> On Friday, September 16, 2016 at 4:43:06 AM UTC-4, Michael Borregaard 
>> wrote:
>>>
>>> Hi, Is this the right forum for troubleshooting / issues with my julia 
>>> install?
>>>
>>> I have kept having problems with packages giving error on precompile, 
>>> rendering julia unusable. I then reinstalled julia-0.5-rc4, and removed my 
>>> .julia folder from my home dir to do a fresh install. Now, Julia fails with 
>>> an error message when I do Pkg.update():
>>>
>>> julia> Pkg.update()
>>> INFO: Initializing package repository /Users/michael/.julia/v0.5
>>> INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
>>> ERROR: SystemError (with /Users/michael/.julia/v0.5/METADATA): rmdir: 
>>> Directory not empty
>>>  in #systemerror#51 at ./error.jl:34 [inlined]
>>>  in (::Base.#kw##systemerror)(::Array{Any,1}, ::Base.#systemerror, 
>>> ::Symbol, ::Bool) at ./:0
>>>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at ./file.jl:125
>>>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at 
>>> /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
>>>  in (::Base.Filesystem.#kw##rm)(::Array{Any,1}, ::Base.Filesystem.#rm, 
>>> ::String) at ./:0
>>>  in init(::String, ::String) at ./pkg/dir.jl:62
>>>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
>>> ::Vararg{Any,N}) at ./pkg/dir.jl:28
>>>  in update() at ./pkg/pkg.jl:210
>>>
>>> I assums that a completely clean install should work. Are there keys to 
>>> delete etc that will give me a properly clean install? I am on Mac OS X 
>>> (newest version).
>>> Thanks!
>>>
>>
>

[julia-users] Re: LZMA decompression with Julia

[Tony Kelman]

Your best bet is probably https://github.com/yuyichao/LibArchive.jl


On Saturday, September 17, 2016 at 7:14:56 AM UTC-7, Femto Trader wrote:
>
> Hello,
>
> I'd like to read a LZMA compressed file with Julia.
> I haven't found such a library.
> Maybe I missed it ?
>
> Any help is welcome.
>
> Kind regards
>

[julia-users] Re: How can I add the path of Julia packages to Cygwin?

[Tony Kelman]

You can add

export JULIA_PKGDIR=C:/Users/you/.julia

to then end of your .bashrc file in Cygwin.


For git, check the order of things in
ENV["PATH"]
run(`which -a git`)

from inside Julia. If the git that's part of Julia comes before Cygwin's 
/usr/bin/git, I think you should be okay.

On Saturday, September 17, 2016 at 6:30:31 AM UTC-7, zlqs1985 wrote:
>
> Hi,tony, thanks for timely and insightful reply. Unfortunately, I'm new to 
> cygwin (linux) and not quite sure what step should I take to make the the 
> job done. For example, where can I find the julia package path, and to 
> which I add these path in cygwin, with which command ("export" as I 
> guess?). For the git issue, I think I first need to uninstall the git 
> package in cygwin and then call git outside, is that true? Thank you for 
> your help.
>
> 在 2016年9月17日星期六 UTC+8下午8:33:11，Tony Kelman写道：
>>
>> When you run a login terminal in Julia, your HOME is set differently than 
>> outside of Cygwin. You could set the environment variable JULIA_PKGDIR to 
>> your normal package directory. Note that if you're using Julia 0.4, you 
>> should avoid having Cygwin's git in your path, or have it later than the 
>> version of git that comes with Julia 0.4. The Julia package manager isn't 
>> compatible with Cygwin's version of git, but on Julia 0.5 the package 
>> manager no longer uses command-line git so it's not an issue.
>>
>>
>> On Saturday, September 17, 2016 at 2:15:57 AM UTC-7, zlqs1985 wrote:
>>>
>>> I want to make Cygwin  my default julia working env. It proved that I 
>>> can dive into julia successfully within cygwin. However, when I want to use 
>>> package ,say 
>>> using Distributions
>>> , the cmd throwed error message told me that : ArgumentError: 
>>> distribution not found in path
>>> Well, it's clear I have not added the package path to cygwin, an action 
>>> I take for granted in windows cmd.
>>> Can  linux command like 
>>> export PATH=/cgdrive/c/ .. julia package path .. :$PATH
>>> resolve my problem? Any suggestion are highly appreciated.
>>>
>>

[julia-users] Re: How can I add the path of Julia packages to Cygwin?

[Tony Kelman]

When you run a login terminal in Julia, your HOME is set differently than 
outside of Cygwin. You could set the environment variable JULIA_PKGDIR to 
your normal package directory. Note that if you're using Julia 0.4, you 
should avoid having Cygwin's git in your path, or have it later than the 
version of git that comes with Julia 0.4. The Julia package manager isn't 
compatible with Cygwin's version of git, but on Julia 0.5 the package 
manager no longer uses command-line git so it's not an issue.


On Saturday, September 17, 2016 at 2:15:57 AM UTC-7, zlqs1985 wrote:
>
> I want to make Cygwin  my default julia working env. It proved that I can 
> dive into julia successfully within cygwin. However, when I want to use 
> package ,say 
> using Distributions
> , the cmd throwed error message told me that : ArgumentError: distribution 
> not found in path
> Well, it's clear I have not added the package path to cygwin, an action I 
> take for granted in windows cmd.
> Can  linux command like 
> export PATH=/cgdrive/c/ .. julia package path .. :$PATH
> resolve my problem? Any suggestion are highly appreciated.
>

[julia-users] Re: How can I add the path of Julia packages to Cygwin?

[Tony Kelman]

"a login terminal in Cygwin" rather, sorry

On Saturday, September 17, 2016 at 5:33:11 AM UTC-7, Tony Kelman wrote:
>
> When you run a login terminal in Julia, your HOME is set differently than 
> outside of Cygwin. You could set the environment variable JULIA_PKGDIR to 
> your normal package directory. Note that if you're using Julia 0.4, you 
> should avoid having Cygwin's git in your path, or have it later than the 
> version of git that comes with Julia 0.4. The Julia package manager isn't 
> compatible with Cygwin's version of git, but on Julia 0.5 the package 
> manager no longer uses command-line git so it's not an issue.
>
>
> On Saturday, September 17, 2016 at 2:15:57 AM UTC-7, zlqs1985 wrote:
>>
>> I want to make Cygwin  my default julia working env. It proved that I can 
>> dive into julia successfully within cygwin. However, when I want to use 
>> package ,say 
>> using Distributions
>> , the cmd throwed error message told me that : ArgumentError: 
>> distribution not found in path
>> Well, it's clear I have not added the package path to cygwin, an action I 
>> take for granted in windows cmd.
>> Can  linux command like 
>> export PATH=/cgdrive/c/ .. julia package path .. :$PATH
>> resolve my problem? Any suggestion are highly appreciated.
>>
>

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

That benchmark doesn't say what they were using for "normal backends" - was it 
openblas or atlas or the reference blas, which set of kernels, were they using 
multithreading, etc. The open source Julia build will almost certainly have 
faster FFT's than SciPy without MKL, since Julia uses FFTW but SciPy uses a 
slower non-GPL-licensed implementation. Note that we had a bug on our buildbots 
regarding optimization flags in some dependencies so you may want to wait until 
0.4.7 binaries or test with 0.5.0-rc4 or newer for comparing FFT performance.

Julia Computing offers custom solutions that aren't necessarily listed on the 
products page of our website yet, you can inquire at the contact address there.

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

mic probably means xeon phi, so that's likely for cross compiling to a xeon phi 
device from a windows host. Based on the sizes of the .lib files, I take what I 
said back, those probably are static libraries. I did this many months ago and 
have a Make.user somewhere.

Before you spend too much time on this, how sure are you that MKL will make a 
major difference over openblas on your application? openblas is close in 
performance to MKl on many, but not quite all operations. In some cases it may 
even be faster. Open source Julia is much better supported against openblas, 
especially on Windows. There are avenues for commercial supported Julia as well.

[julia-users] deprecating julia v0.3 -> are there still 0.3 users?

[Tony Kelman]

Note also that as of several weeks ago, METADATA is frozen for Julia 0.3 and 
unless specific exceptions are requested, we're not merging any new tags of 
packages that support Julia 0.3. The existing tags will be left as is.

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Tony Kelman]

Misread. Go into metadata and run git status. Post the output.

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Tony Kelman]

While it's good that things are now working, deleting the old copy means we 
will now never know what went wrong. Please stop suggesting that as a first 
step, Chris and Davis. Moving it to a different name at least keeps it around 
for debugging.

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

Something's broken, you'll probably have to run that in gdb and try to get 
a backtrace. I don't think the .lib files are full-fledged static libraries 
(how big are they?), I suspect they are import libraries that go along with 
the corresponding dll's. So the mingw naming convention from them would be 
libmkl_rt.dll.a for mkl_rt.lib. The main thing you want to do is make sure 
the blas and lapack library ccall's are getting pointed to the mkl_rt.dll.


On Wednesday, September 14, 2016 at 3:14:52 PM UTC-7, Zhong Pan wrote:
>
> Thanks, Tony, with your help I think I am pretty close.
>
> Yes you are right, I searched for *.dll and found them in a folder that I 
> didn't notice before.
>
> Here's what I did last based on your comments to move things forward a few 
> steps more:
>
> (1) Copied all the 17 .lib files from "C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win"
>  
> to 
> "C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib".
>  
> Changed them from .lib files to .a files and added prefix "lib". So now the 
> 17 files look like:
>
> libmkl_blas95_ilp64.a
> libmkl_blas95_lp64.a
> libmkl_core.a
> libmkl_core_dll.a
> libmkl_intel_ilp64.a
> libmkl_intel_ilp64_dll.a
> libmkl_intel_lp64.a
> libmkl_intel_lp64_dll.a
> libmkl_intel_thread.a
> libmkl_intel_thread_dll.a
> libmkl_lapack95_ilp64.a
> libmkl_lapack95_lp64.a
> libmkl_rt.a
> libmkl_sequential.a
> libmkl_sequential_dll.a
> libmkl_tbb_thread.a
> libmkl_tbb_thread_dll.a
>
>
>
> (2) Copied all the .dll files from "C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\redist\intel64_win\mkl"
>  
> to 
> "C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\bin".
>  
> This includes the folder "33". Here are all the files that got copied:
>
> 1033/mkl_msg.dll
> libimalloc.dll
> mkl_avx.dll
> mkl_avx2.dll
> mkl_avx512.dll
> mkl_avx512_mic.dll
> mkl_core.dll
> mkl_def.dll
> mkl_intel_thread.dll
> mkl_mc.dll
> mkl_mc3.dll
> mkl_rt.dll
> mkl_sequential.dll
> mkl_tbb_thread.dll
> mkl_vml_avx.dll
> mkl_vml_avx2.dll
> mkl_vml_avx512.dll
> mkl_vml_avx512_mic.dll
> mkl_vml_cmpt.dll
> mkl_vml_def.dll
> mkl_vml_mc.dll
> mkl_vml_mc2.dll
> mkl_vml_mc3.dll
>
>
> (3) "make -j 4" again. This time, there was no "Cannot find BLAS 
> libraries" error anymore. The build went on for a while until here:
>
> floatfuncs.jl
>
> Please submit a bug report with steps to reproduce this fault, and any 
> error messages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x0 -- unknown function (ip: 
> )
> unknown function (ip: )
> *** This error is usually fixed by running `make clean`. If the error 
> persists, try `make cleanall`. ***
> make[1]: *** [Makefile:200: 
> /c/users/zpan/Documents/GitHub/julia/usr/lib/julia/sys.o] Error 1
> make: *** [Makefile:69: julia-sysimg-release] Error 2
>
>
> I tried both "make clean" and "make cleanall", and the same problem 
> persisted. I also tried renaming the .dll and .a files in a couple ways in 
> vain. 
>
> Again, any help appreciated!! Hope I am close to success. When I am done I 
> will repeat the process and document it here for others to see.
>
>
>
>
> On Wednesday, September 14, 2016 at 3:02:40 PM UTC-5, Tony Kelman wrote:
>>
>> Which configure file was this from? Julia doesn't need the .lib files, it 
>> needs the dll, and I assure you there are dlls in MKL. However some of the 
>> dependencies may need the .lib files, and/or you can try copying them to a 
>> .dll.a file name if that helps libtool or configure work better.
>>
>>
>>>>

Re: [julia-users] ls()?

[Tony Kelman]

Julia supports Windows, which is not a posix platform. So while Julia uses 
posix-inspired names in some places, that's not universally the case, and 
they're often jargony and confusing if you're not a Unix user.


On Wednesday, September 14, 2016 at 1:30:25 PM UTC-7, Evan Fields wrote:
>
> Which can get gnarly on Windows, depending how you launched Julia. E.g. 
> just launching from the Julia executable:
>
>
> shell> ls
> ERROR: could not spawn `ls`: no such file or directory (ENOENT)
>  in _jl_spawn(::String, ::Array{String,1}, ::Ptr{Void}, ::Base.Process, 
> ::RawFD, ::RawFD, ::RawFD) at .\process.jl:321
>  in #414 at .\process.jl:478 [inlined]
>  in setup_stdio(::Base.##414#415{Cmd,Ptr{Void},Base.Process}, 
> ::Tuple{RawFD,RawFD,RawFD}) at .\process.jl:466
>  in #spawn#413(::Nullable{Base.ProcessChain}, ::Function, ::Cmd, 
> ::Tuple{RawFD,RawFD,RawFD}, ::Bool, ::Bool) at .\process.jl:477
>  in run(::Cmd) at .\process.jl:591
>  in repl_cmd(::Cmd, ::Base.Terminals.TTYTerminal) at .\client.jl:91
>
> julia>
>
> (It works fine if launched from Git bash)
>

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

Which configure file was this from? Julia doesn't need the .lib files, it 
needs the dll, and I assure you there are dlls in MKL. However some of the 
dependencies may need the .lib files, and/or you can try copying them to a 
.dll.a file name if that helps libtool or configure work better.

On Wednesday, September 14, 2016 at 12:28:16 PM UTC-7, Zhong Pan wrote:
>
> BTW I did try Tony's idea of adding "lib" as prefix to each .lib filename. 
> That didn't solve the problem.
>
> On Wednesday, September 14, 2016 at 2:07:14 PM UTC-5, Zhong Pan wrote:
>>
>> Just to report my progress and ask for help again if anybody succeeded in 
>> building Julia 0.4 or 0.5 on Windows with MKL.
>>
>> I backed off a little and tried building release-0.5 on Windows following 
>> the standard instructions below. That is, without any MKL related 
>> configurations.
>> https://github.com/JuliaLang/julia/blob/master/README.windows.md 
>> 
>> But the build failed with Error 2 (some dependency failed to build). 
>>
>> Since my main focus is to get MKL to work rather than trying out 0.5, I 
>> tried building release-0.4 first following the same instructions (no MKL). 
>> And that was a success!
>> Encouraged, I added the following lines to Make.user and copied the 17 
>> .lib files from the MKL library to julia/usr/bin and julia/usr/lib and 
>> C:\mkllib
>> USE_INTEL_MKL = 1
>> USE_INTEL_MKL_FFT = 1
>> USE_INTEL_LIBM = 1
>>
>> I also did this, though I know it probably won't matter:
>> export MKLLIB=/c/mkllib
>>
>> "make -j 4" failed with the expected error:
>>
>> ...
>> configure: error: Cannot find BLAS libraries
>> ...
>> make: *** [Makefile:51: julia-deps] Error 2
>>
>> I know CMake probably won't be able to figure out Windows style libraries 
>> by itself, but I don't know how to make this work. Could anyone help? 
>>
>> P.S. the 17 MKL .lib files are listed below:
>>
>> mkl_blas95_ilp64.lib
>> mkl_blas95_lp64.lib
>> mkl_core.lib
>> mkl_core_dll.lib
>> mkl_intel_ilp64.lib
>> mkl_intel_ilp64_dll.lib
>> mkl_intel_lp64.lib
>> mkl_intel_lp64_dll.lib
>> mkl_intel_thread.lib
>> mkl_intel_thread_dll.lib
>> mkl_lapack95_ilp64.lib
>> mkl_lapack95_lp64.lib
>> mkl_rt.lib
>> mkl_sequential.lib
>> mkl_sequential_dll.lib
>> mkl_tbb_thread.lib
>> mkl_tbb_thread_dll.lib
>>
>>
>>
>>
>>
>>

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Tony Kelman]

Better to go into METADATA and check with git status exactly what happened 
before completely deleting it. Otherwise we'll never know what happened. At 
least move it to a different name so it's not gone.


On Wednesday, September 14, 2016 at 10:07:43 AM UTC-7, Chris Rackauckas 
wrote:
>
> +1000 for the REQUIRE hack. Never knew about that. Be careful to save the 
> packages you've been working on (or just commit and push somewhere) if you 
> do this though.
>
> On Wednesday, September 14, 2016 at 10:02:22 AM UTC-7, David P. Sanders 
> wrote:
>>
>>
>> I am a fan of deleting the entire .julia directory in your home directory 
>> and reinstalling your packages.
>>
>> You can also just keep the REQUIRE file from .julia/v0.4 somewhere, do 
>> Pkg.init(), then copy the REQUIRE file back and do
>> Pkg.resolve()  to reinstall everything you previously had installed.
>>
>> El martes, 13 de septiembre de 2016, 10:54:43 (UTC-4), Rahul Mourya 
>> escribió:
>>>
>>> Hi,
>>> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
>>> git to use https: git config --global url."https://".insteadOf git://.
>>> Under this setting, I'm able to install packages using Pkg.add(), 
>>> however, when I use Pkg.update(), I get following error:
>>>
>>> INFO: Updating METADATA...
>>> Cannot pull with rebase: You have unstaged changes.
>>> Please commit or stash them.
>>> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
>>> [1]
>>>  in pipeline_error at process.jl:555
>>>  in run at process.jl:531
>>>  in anonymous at pkg/entry.jl:283
>>>  in withenv at env.jl:160
>>>  in anonymous at pkg/entry.jl:282
>>>  in cd at ./file.jl:22
>>>  in update at ./pkg/entry.jl:272
>>>  in anonymous at pkg/dir.jl:31
>>>  in cd at file.jl:22
>>>  in cd at pkg/dir.jl:31
>>>  in update at ./pkg.jl:45
>>>
>>> what could be the reason? Any workaround this?
>>>
>>> Thanks!
>>>
>>

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

maybe better to just temporarily add gcc's location to your working path for 
the duration of the make (don't leave it there longer though).

I think that linker error is from arpack. Try making a copy of mkl_rt.dll 
called libmkl_rt.dll and see if that helps. libtool isn't able to link against 
dlls that don't have a lib prefix unless you have a corresponding .dll.a import 
library (maybe copying and renaming one od the .lib files to libmkl_rt.dll.a 
could also work?) because being annoying is what libtool does.

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Tony Kelman]

Better to use a different branch name, not metadata-v2

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

Intel compilers on windows are MSVC style, which our build system is not really 
set up to handle. There is experimental partial support (search for "MSVC 
support tracking issue" if you're interested) but it would really require 
rewriting the build system to use cmake to work smoothly.

You can build Julia from source with mingw but direct the build system to use 
an mkl library instead of building openblas from source. At one point mkl on 
windows didn't export gfortran style naming conventions for blas and lapack 
functions, but recent versions do last I checked. Could even be able to switch 
from an existing Julia binary by rebuilding the system image.

Re: [julia-users] Configuring incomplete (julia-deps error 2)

[Tony Kelman]

Should probably report the issue to the Debian cmake maintainer and see if 
they can backport the fix from 
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5d9a8283cfac15b4a5a07f18d5eb10c1f388505

On Sunday, September 11, 2016 at 1:55:50 PM UTC-7, Davide wrote:
>
> Thanks Tony, with cmake v. 3.6.2 the configuration passed and now the 
> compilation is going on.
> Debian stable comes with cmake v.3.0.2.
>
>Best,
>
>Davide
>
> On Sunday, September 11, 2016 at 10:17:44 PM UTC+2, Tony Kelman wrote:
>>
>> There's a bug in some versions of cmake's FindOpenSSL. Just download and 
>> use the latest version of cmake from 
>> https://cmake.org/files/v3.6/cmake-3.6.2-Linux-x86_64.tar.gz
>>
>>
>> On Sunday, September 11, 2016 at 12:42:27 PM UTC-7, Davide wrote:
>>>
>>> I put the output of make (with no -j option and got with tee) in file 
>>> makejulia.log, together with the files CMakeError.log and CMakeOutput.log 
>>> in the following GitHub gist:
>>>
>>>https://gist.github.com/anonymous/842016eeac177a2ad634b359592fd6bb
>>>
>>> Thanks,
>>>
>>>Davide
>>>
>>> On Sunday, September 11, 2016 at 8:10:00 PM UTC+2, Milan Bouchet-Valat 
>>> wrote:
>>>>
>>>> Le dimanche 11 septembre 2016 à 11:05 -0700, Davide a écrit : 
>>>> > Hi, 
>>>> > 
>>>> > I am trying to compile v0.5rc04 and I get the error reported below 
>>>> > during configuration. 
>>>> > My system: Debian GNU/Linux 64bit on an Intel i7 machine. 
>>>> > I checked for the required external dependencies and all are 
>>>> > installed. 
>>>> > I have MARCH=native in Make.user. 
>>>> > 
>>>> > The last lines of the output of the make command (make -j 4) are: 
>>>> > 
>>>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:293 
>>>> > (list): 
>>>> >   list GET given empty list 
>>>> > Call Stack (most recent call first): 
>>>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>>>> > 
>>>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:294 
>>>> > (list): 
>>>> >   list GET given empty list 
>>>> > Call Stack (most recent call first): 
>>>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>>>> > 
>>>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:296 
>>>> > (list): 
>>>> >   list GET given empty list 
>>>> > Call Stack (most recent call first): 
>>>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>>>> > 
>>>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:298 
>>>> > (list): 
>>>> >   list GET given empty list 
>>>> > Call Stack (most recent call first): 
>>>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>>>> > 
>>>> > -- Configuring incomplete, errors occurred! 
>>>> > 
>>>> >Thanks for help, 
>>>> > 
>>>> >Davide 
>>>> Please call make without -j, and post a longer excerpt of the log (e.g. 
>>>> in a GitHub gist). 
>>>>
>>>>
>>>> Regards 
>>>>
>>>

Re: [julia-users] Configuring incomplete (julia-deps error 2)

[Tony Kelman]

There's a bug in some versions of cmake's FindOpenSSL. Just download and 
use the latest version of cmake from 
https://cmake.org/files/v3.6/cmake-3.6.2-Linux-x86_64.tar.gz


On Sunday, September 11, 2016 at 12:42:27 PM UTC-7, Davide wrote:
>
> I put the output of make (with no -j option and got with tee) in file 
> makejulia.log, together with the files CMakeError.log and CMakeOutput.log 
> in the following GitHub gist:
>
>https://gist.github.com/anonymous/842016eeac177a2ad634b359592fd6bb
>
> Thanks,
>
>Davide
>
> On Sunday, September 11, 2016 at 8:10:00 PM UTC+2, Milan Bouchet-Valat 
> wrote:
>>
>> Le dimanche 11 septembre 2016 à 11:05 -0700, Davide a écrit : 
>> > Hi, 
>> > 
>> > I am trying to compile v0.5rc04 and I get the error reported below 
>> > during configuration. 
>> > My system: Debian GNU/Linux 64bit on an Intel i7 machine. 
>> > I checked for the required external dependencies and all are 
>> > installed. 
>> > I have MARCH=native in Make.user. 
>> > 
>> > The last lines of the output of the make command (make -j 4) are: 
>> > 
>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:293 
>> > (list): 
>> >   list GET given empty list 
>> > Call Stack (most recent call first): 
>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>> > 
>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:294 
>> > (list): 
>> >   list GET given empty list 
>> > Call Stack (most recent call first): 
>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>> > 
>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:296 
>> > (list): 
>> >   list GET given empty list 
>> > Call Stack (most recent call first): 
>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>> > 
>> > CMake Error at /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:298 
>> > (list): 
>> >   list GET given empty list 
>> > Call Stack (most recent call first): 
>> >   CMakeLists.txt:277 (FIND_PACKAGE) 
>> > 
>> > -- Configuring incomplete, errors occurred! 
>> > 
>> >Thanks for help, 
>> > 
>> >Davide 
>> Please call make without -j, and post a longer excerpt of the log (e.g. 
>> in a GitHub gist). 
>>
>>
>> Regards 
>>
>

[julia-users] ANN: Julia 0.5.0-rc4 now available

[Tony Kelman]

I have just tagged and uploaded release candidate 4 for Julia version 
0.5.0. Binaries are available from

https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc4-linux-x86_64.tar.gz
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc4-linux-i686.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc4-linux-arm.tar.gz
 
https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc4-osx10.7+.dmg 
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc4-win64.exe 
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc4-win32.exe 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc4.sha256 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc4.md5 
For gpg signatures (with this key http://julialang.org/juliareleases.asc) 
of the Linux tar.gz binaries, append .asc to the filename.

Sorry there was a bit of a delay, one of the precompilation-related 
backports just after RC3 had a bug that took some time to get fixed. Please 
test this and report any issues. Unless anything major comes up over the 
weekend or early next week, I plan doing at most a handful more very small 
backports then tagging 0.5.0 final. Bugfixes will continue to be backported 
to the release-0.5 branch for an 0.5.1 patch release roughly a month after 
that.

-Tony

Re: [julia-users] Re: PSA: New package registration requirements

[Tony Kelman]

You can modify the branch on your metadata fork and remove some of the tag 
files. Usually Pkg.publish is used after just one or two local Pkg.tag's.

Re: [julia-users] Re: PSA: New package registration requirements

[Tony Kelman]

git tags that don't get registered in metadata should be fine. What were you 
seeing happen?

Re: [julia-users] Re: Conda.jl needs a new maintainer

[Tony Kelman]

You can, you have to create a new "organization" account (it isn't really 
tied to github organizations from what I remember though) and adjust / 
reset the webhook.


On Wednesday, September 7, 2016 at 3:07:21 PM UTC-7, David Anthoff wrote:
>
> I believe AppVeyor always is bound to a personal account, i.e. I don’t 
> think you can have the second type of URL. 
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Steven G. Johnson
> *Sent:* Wednesday, September 7, 2016 1:49 PM
> *To:* julia-users >
> *Subject:* Re: [julia-users] Re: Conda.jl needs a new maintainer
>
>  
>
> I'm not completely sure of the right way to re-enable AppVeyor ... I did 
> it for PyCall, but it shows up as 
> https://ci.appveyor.com/project/StevenGJohnson/pycall-jl-nu3aa  how 
> do I enable it as https://ci.appveyor.com/project/JuliaPy/pycall-jl?
>
>
> On Wednesday, September 7, 2016 at 1:46:08 PM UTC-4, Tony Kelman wrote:
>
> Please re enable all CI services for every repo that was moved into that 
> prganization. Travis and AppVeyor don't always handle repo moves very well.
>
>

Re: [julia-users] Re: Conda.jl needs a new maintainer

[Tony Kelman]

Please re enable all CI services for every repo that was moved into that 
prganization. Travis and AppVeyor don't always handle repo moves very well.

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

FengYang is right. Remove ConjugatePriors. That package needs a new tag 
that's compatible with the latest versions of its dependencies, otherwise 
having it installed is going to cause issues like this.

I'm not sure what's needed beyond 
https://github.com/JuliaStats/ConjugatePriors.jl/pull/10


On Tuesday, September 6, 2016 at 8:41:38 PM UTC-7, Tony Kelman wrote:
>
> Did you post your full Pkg.status() yet? Is something keeping you stuck on 
> StatsFuns 0.2.x? The only new upper bound I see in the METADATA versions is 
> from https://github.com/JuliaLang/METADATA.jl/pull/5613
>
>
> On Tuesday, September 6, 2016 at 4:09:07 PM UTC-7, Tim Wheeler wrote:
>>
>> Okay, here is the same thing but from my METADATA.
>>
>> Code:
>>
>> metadata_dir = "/home/tim/.julia/v0.4/METADATA"
>> for (pkg, version) in Pkg.installed()
>>
>> reqfile = joinpath(metadata_dir, pkg, "versions", string(version), 
>> "requires")
>>
>> if isfile(reqfile)
>> lines = open(readlines, reqfile)
>> println("#"^20)
>> println(pkg)
>> for line in lines
>> print(line)
>> end
>> println("")
>> end
>> end
>>
>>
>>
>>
>> On Tuesday, September 6, 2016 at 11:17:28 AM UTC-7, Tony Kelman wrote:
>>>
>>> I hate to have to say "RTFM" about this so often, but see 
>>> http://docs.julialang.org/en/release-0.4/manual/strings/#version-number-literals.
>>>  
>>> The trailing dash means including prereleases of the given version. 
>>> (Considering how unintuitive this is we should probably transition to 
>>> something clearer when we redesign Pkg.) The first number given is an 
>>> inclusive lower bound, and if a second number is given then it's an 
>>> exclusive upper bound.
>>>
>>> I see a few packages applying upper bounds to ForwardDiff, and a few to 
>>> MathProgBase and ReverseDiffSparse. I may have missed something (were these 
>>> taken from METADATA or the package directory? It should be the former, 
>>> sorry if I didn't say as much - METADATA can be changed after-the-fact but 
>>> tagged package content can't) but those don't look like they would conflict.
>>>
>>> On Tuesday, September 6, 2016 at 10:03:27 AM UTC-7, Tim Wheeler wrote:
>>>>
>>>> I wrote the script  and put the output in the attached file.
>>>>
>>>> I assume that the '-' at the end of a dep is an upperbound?
>>>>
>>>> On Tuesday, September 6, 2016 at 9:35:46 AM UTC-7, Tim Wheeler wrote:
>>>>>
>>>>> Ok, will do!
>>>>>
>>>>> On Tuesday, September 6, 2016 at 9:31:25 AM UTC-7, Tony Kelman wrote:
>>>>>>
>>>>>> There's a bug somewhere with that error message, I've seen it points 
>>>>>> at the wrong package. If we can come up with a reproducible test case 
>>>>>> here 
>>>>>> it'll help for fixing the bug and making that message more useful.
>>>>>>
>>>>>> It's almost certainly not Compat (I don't think anyone has ever added 
>>>>>> an upper bound to a Compat dependency). Perhaps loop over 
>>>>>> Pkg.installed() 
>>>>>> and display the contents of the REQUIRE file for the specific tags you 
>>>>>> have 
>>>>>> currently installed, see who is upper-bounding each other? We do need 
>>>>>> better tools for debugging this kind of thing to make it easier to 
>>>>>> figure 
>>>>>> out what the dependency resolver is doing, which bound constraints are 
>>>>>> active etc.
>>>>>>
>>>>>>
>>>>>> On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler wrote:
>>>>>>>
>>>>>>> Okay - I removed GaussianMixtures and now it is complaining about 
>>>>>>> Compat. 
>>>>>>>
>>>>>>> ERROR: unsatisfiable package requirements detected: no feasible 
>>>>>>> version could be found for package: Compat
>>>>>>>
>>>>>>> I wrote a script to run through all package REQUIRE files and print 
>>>>>>> out the Compat line, if any. None of these found anything specifying an 
>>>>>>> upper-bound.
>>>>&

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

Did you post your full Pkg.status() yet? Is something keeping you stuck on 
StatsFuns 0.2.x? The only new upper bound I see in the METADATA versions is 
from https://github.com/JuliaLang/METADATA.jl/pull/5613


On Tuesday, September 6, 2016 at 4:09:07 PM UTC-7, Tim Wheeler wrote:
>
> Okay, here is the same thing but from my METADATA.
>
> Code:
>
> metadata_dir = "/home/tim/.julia/v0.4/METADATA"
> for (pkg, version) in Pkg.installed()
>
> reqfile = joinpath(metadata_dir, pkg, "versions", string(version), 
> "requires")
>
> if isfile(reqfile)
> lines = open(readlines, reqfile)
> println("#"^20)
> println(pkg)
> for line in lines
> print(line)
> end
>     println("")
> end
> end
>
>
>
>
> On Tuesday, September 6, 2016 at 11:17:28 AM UTC-7, Tony Kelman wrote:
>>
>> I hate to have to say "RTFM" about this so often, but see 
>> http://docs.julialang.org/en/release-0.4/manual/strings/#version-number-literals.
>>  
>> The trailing dash means including prereleases of the given version. 
>> (Considering how unintuitive this is we should probably transition to 
>> something clearer when we redesign Pkg.) The first number given is an 
>> inclusive lower bound, and if a second number is given then it's an 
>> exclusive upper bound.
>>
>> I see a few packages applying upper bounds to ForwardDiff, and a few to 
>> MathProgBase and ReverseDiffSparse. I may have missed something (were these 
>> taken from METADATA or the package directory? It should be the former, 
>> sorry if I didn't say as much - METADATA can be changed after-the-fact but 
>> tagged package content can't) but those don't look like they would conflict.
>>
>> On Tuesday, September 6, 2016 at 10:03:27 AM UTC-7, Tim Wheeler wrote:
>>>
>>> I wrote the script  and put the output in the attached file.
>>>
>>> I assume that the '-' at the end of a dep is an upperbound?
>>>
>>> On Tuesday, September 6, 2016 at 9:35:46 AM UTC-7, Tim Wheeler wrote:
>>>>
>>>> Ok, will do!
>>>>
>>>> On Tuesday, September 6, 2016 at 9:31:25 AM UTC-7, Tony Kelman wrote:
>>>>>
>>>>> There's a bug somewhere with that error message, I've seen it points 
>>>>> at the wrong package. If we can come up with a reproducible test case 
>>>>> here 
>>>>> it'll help for fixing the bug and making that message more useful.
>>>>>
>>>>> It's almost certainly not Compat (I don't think anyone has ever added 
>>>>> an upper bound to a Compat dependency). Perhaps loop over Pkg.installed() 
>>>>> and display the contents of the REQUIRE file for the specific tags you 
>>>>> have 
>>>>> currently installed, see who is upper-bounding each other? We do need 
>>>>> better tools for debugging this kind of thing to make it easier to figure 
>>>>> out what the dependency resolver is doing, which bound constraints are 
>>>>> active etc.
>>>>>
>>>>>
>>>>> On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler wrote:
>>>>>>
>>>>>> Okay - I removed GaussianMixtures and now it is complaining about 
>>>>>> Compat. 
>>>>>>
>>>>>> ERROR: unsatisfiable package requirements detected: no feasible 
>>>>>> version could be found for package: Compat
>>>>>>
>>>>>> I wrote a script to run through all package REQUIRE files and print 
>>>>>> out the Compat line, if any. None of these found anything specifying an 
>>>>>> upper-bound.
>>>>>>
>>>>>> I would like to find the offending packages. Is there a good way to 
>>>>>> go about doing this?
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> ArgParse:  Compat 0.7.3
>>>>>> ArrayViews:Compat
>>>>>> AutomotiveDrivingModels:   Compat 0.8
>>>>>> AxisAlgorithms:Compat 0.8
>>>>>> BayesNets: Compat
>>>>>> BinDeps:   Compat 0.8.4
>>>>>> Blink: Compat 0.8.6
>>>>>> Blosc: Compat 0.8
>>>>>> B

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

0.5.0-pre is actually strictly greater than 0.5.0-dev. Packages currently can't 
have extra build information like that unless you tag non-semver releases in 
metadata. They're either at a tag, between tags, or at more recent point than 
the latest tag. I think a format that has more annotations in it than the 
current require files, something like an optional allow_prereleases entry in a 
toml file.

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

I hate to have to say "RTFM" about this so often, but see 
http://docs.julialang.org/en/release-0.4/manual/strings/#version-number-literals.
 
The trailing dash means including prereleases of the given version. 
(Considering how unintuitive this is we should probably transition to 
something clearer when we redesign Pkg.) The first number given is an 
inclusive lower bound, and if a second number is given then it's an 
exclusive upper bound.

I see a few packages applying upper bounds to ForwardDiff, and a few to 
MathProgBase and ReverseDiffSparse. I may have missed something (were these 
taken from METADATA or the package directory? It should be the former, 
sorry if I didn't say as much - METADATA can be changed after-the-fact but 
tagged package content can't) but those don't look like they would conflict.

On Tuesday, September 6, 2016 at 10:03:27 AM UTC-7, Tim Wheeler wrote:
>
> I wrote the script  and put the output in the attached file.
>
> I assume that the '-' at the end of a dep is an upperbound?
>
> On Tuesday, September 6, 2016 at 9:35:46 AM UTC-7, Tim Wheeler wrote:
>>
>> Ok, will do!
>>
>> On Tuesday, September 6, 2016 at 9:31:25 AM UTC-7, Tony Kelman wrote:
>>>
>>> There's a bug somewhere with that error message, I've seen it points at 
>>> the wrong package. If we can come up with a reproducible test case here 
>>> it'll help for fixing the bug and making that message more useful.
>>>
>>> It's almost certainly not Compat (I don't think anyone has ever added an 
>>> upper bound to a Compat dependency). Perhaps loop over Pkg.installed() and 
>>> display the contents of the REQUIRE file for the specific tags you have 
>>> currently installed, see who is upper-bounding each other? We do need 
>>> better tools for debugging this kind of thing to make it easier to figure 
>>> out what the dependency resolver is doing, which bound constraints are 
>>> active etc.
>>>
>>>
>>> On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler wrote:
>>>>
>>>> Okay - I removed GaussianMixtures and now it is complaining about 
>>>> Compat. 
>>>>
>>>> ERROR: unsatisfiable package requirements detected: no feasible version 
>>>> could be found for package: Compat
>>>>
>>>> I wrote a script to run through all package REQUIRE files and print out 
>>>> the Compat line, if any. None of these found anything specifying an 
>>>> upper-bound.
>>>>
>>>> I would like to find the offending packages. Is there a good way to go 
>>>> about doing this?
>>>>
>>>> Thank you.
>>>>
>>>> ArgParse:  Compat 0.7.3
>>>> ArrayViews:Compat
>>>> AutomotiveDrivingModels:   Compat 0.8
>>>> AxisAlgorithms:Compat 0.8
>>>> BayesNets: Compat
>>>> BinDeps:   Compat 0.8.4
>>>> Blink: Compat 0.8.6
>>>> Blosc: Compat 0.8
>>>> BufferedStreams:   Compat 0.8.4
>>>> Cairo: Compat 0.8.0
>>>> Calculus:  Compat 0.4.0
>>>> Codecs:Compat 0.7.20
>>>> Colors:Compat 0.8.0
>>>> Compose:   Compat 0.8.0
>>>> Conda: Compat 0.8
>>>> ConjugatePriors:   Compat 0.4.0
>>>> Contour:   Compat 0.8.0
>>>> DataArrays:Compat 0.8.6
>>>> DataFrames:Compat 0.8
>>>> Debug: Compat
>>>> Discretizers:  Compat
>>>> Distances: Compat 0.8.4
>>>> Distributions: Compat 0.4.0
>>>> Docile:Compat 0.7.1
>>>> FastAnonymous: Compat
>>>> FileIO:Compat 0.7.19
>>>> FixedPointNumbers: Compat 0.7.14
>>>> FixedSizeArrays:   Compat 0.8.7
>>>> Formatting:Compat
>>>> ForwardDiff:   Compat 0.8.6
>>>> Gadfly:Compat 0.8.5
>>>> Glob:  Compat
>>>> Graphs:Compat 0.7.16
>>>> Gtk:   Compat 0.8.0
>>>> GtkUtilities:

Re: [julia-users] Re: Conda.jl needs a new maintainer

[Tony Kelman]

Overlaps quite a bit with JuliaInterop, doesn't it? Conda isn't strictly a 
Python package manager, though it's most often used that way.


On Tuesday, September 6, 2016 at 7:42:08 AM UTC-7, Viral Shah wrote:
>
> Created JuliaPy and sent the invites to authors and contributors of 
> various py*.jl packages.
>
> -viral
>
> On Tuesday, September 6, 2016 at 7:32:34 PM UTC+5:30, Steven G. Johnson 
> wrote:
>>
>> Viral, can you set up JuliaPy and send invites to the relevant people?
>>
>

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

There's a bug somewhere with that error message, I've seen it points at the 
wrong package. If we can come up with a reproducible test case here it'll 
help for fixing the bug and making that message more useful.

It's almost certainly not Compat (I don't think anyone has ever added an 
upper bound to a Compat dependency). Perhaps loop over Pkg.installed() and 
display the contents of the REQUIRE file for the specific tags you have 
currently installed, see who is upper-bounding each other? We do need 
better tools for debugging this kind of thing to make it easier to figure 
out what the dependency resolver is doing, which bound constraints are 
active etc.


On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler wrote:
>
> Okay - I removed GaussianMixtures and now it is complaining about Compat. 
>
> ERROR: unsatisfiable package requirements detected: no feasible version 
> could be found for package: Compat
>
> I wrote a script to run through all package REQUIRE files and print out 
> the Compat line, if any. None of these found anything specifying an 
> upper-bound.
>
> I would like to find the offending packages. Is there a good way to go 
> about doing this?
>
> Thank you.
>
> ArgParse:  Compat 0.7.3
> ArrayViews:Compat
> AutomotiveDrivingModels:   Compat 0.8
> AxisAlgorithms:Compat 0.8
> BayesNets: Compat
> BinDeps:   Compat 0.8.4
> Blink: Compat 0.8.6
> Blosc: Compat 0.8
> BufferedStreams:   Compat 0.8.4
> Cairo: Compat 0.8.0
> Calculus:  Compat 0.4.0
> Codecs:Compat 0.7.20
> Colors:Compat 0.8.0
> Compose:   Compat 0.8.0
> Conda: Compat 0.8
> ConjugatePriors:   Compat 0.4.0
> Contour:   Compat 0.8.0
> DataArrays:Compat 0.8.6
> DataFrames:Compat 0.8
> Debug: Compat
> Discretizers:  Compat
> Distances: Compat 0.8.4
> Distributions: Compat 0.4.0
> Docile:Compat 0.7.1
> FastAnonymous: Compat
> FileIO:Compat 0.7.19
> FixedPointNumbers: Compat 0.7.14
> FixedSizeArrays:   Compat 0.8.7
> Formatting:Compat
> ForwardDiff:   Compat 0.8.6
> Gadfly:Compat 0.8.5
> Glob:  Compat
> Graphs:Compat 0.7.16
> Gtk:   Compat 0.8.0
> GtkUtilities:  Compat 0.7.16
> GZip:  Compat 0.8.0
> HDF5:  Compat 0.8.0
> Hexagons:  Compat
> Hiccup:Compat 0.8.2
> HttpCommon:Compat 0.7.20
> HttpParser:Compat 0.7.20
> HttpServer:Compat 0.7.16
> IJulia:Compat 0.7.20
> ImageMagick:   Compat 0.7.7
> Images:Compat 0.8.4
> ImageView: Compat 0.4.6
> IniFile:   Compat 0.7.4
> Interact:  Compat 0.7
> Interpolations:Compat 0.8.0
> Ipopt: Compat 0.8.0
> Iterators: Compat
> JLD:   Compat 0.8.0
> JSON:  Compat 0.8.4
> JuMP:  Compat 0.8.6
> KernelDensity: Compat
> LaTeXStrings:  Compat 0.8.0
> Lazy:  Compat 0.8.0
> LegacyStrings: Compat 0.8.4
> Libz:  Compat 0.8.0
> LightXML:  Compat 0.8.3
> Lint:  Compat 0.8.2
> Loess: Compat 0.8.4
> MacroTools:Compat
> MathProgBase:  Compat 0.7.13
> MbedTLS:   Compat 0.8.0
> MLBase:Compat
> MultivariateStats: Compat 0.8.4
> Mustache:  Compat 0.7.18
> NBInclude: Compat 0.7.9
> Nettle:Compat 0.8.0
> NLopt: Compat 0.8
> Optim: Compat 0.8.4
> ParserCombinator:  Compat 0.7.12
> PDMats:Compat
> PGFPlots:  Compat 0.8.0
> PlotlyJS:  Compat 0.7.16
> Plots: Compat
> PositiveFactorizations:Compat 0.8.4
> ProfileView:   Compat 0.8.0
> PyCall:Compat 0.7.1
> PyPlot:Compat 0.4
> Ratios:Compat
> RDatasets: Compat
> Reactive:  Compat
> Reel: 

[julia-users] Re: Pkg.update() does not pull latest version?

[Tony Kelman]

The upper bound was done in METADATA do avoid Distributions 0.10 breaking 
GaussianMixtures, see 
https://github.com/JuliaLang/METADATA.jl/pull/5634#issuecomment-233810018. 
However GaussianMixtures 0.1.0 was released 
https://github.com/JuliaLang/METADATA.jl/pull/5790 which should support 
Distributions 0.10. Maybe something is preventing you from installing 
Clustering 0.6 or ScikitLearnBase 0.0.2? What's the rest of your Pkg.status?


On Tuesday, September 6, 2016 at 8:38:01 AM UTC-7, Tim Wheeler wrote:
>
> Okay, this is a little weird.
>
> If I run the following it looks like the culprit is a dirty package:
>
> julia> Pkg.checkout("Distributions")
> INFO: Checking out Distributions master...
> INFO: Pulling Distributions latest master...
> WARNING: Distributions is fixed at 0.10.1+ conflicting with requirement 
> for GaussianMixtures: [0.0.0,0.10.0)
>
> The weird thing is that the REQUIRE file for GaussianMixtures does not 
> mention the 0.10.1+
>
> julia 0.3 
> Clustering
> Distributions
> PDMats
> Compat
> JLD
>
> Where does that come from?
>
>
> On Tuesday, September 6, 2016 at 8:31:44 AM UTC-7, Tim Wheeler wrote:
>>
>> Hi Julia Users,
>>
>> I just noticed something a little weird. I am using Distributions.jl 
>> (great package btw) in Julia 0.4.6 on Ubuntu, and it is listed in 
>> Pkg.status() as a required package:
>>
>> Distributions 0.8.9
>>
>> I checked on METADATA and on the Distributions.jl github - there is a 
>> more recent version. In fact, there are several more recent versions.
>>
>> I ran Pkg.update(), which updated some things but did not change 
>> Distributions.jl. Am I missing something? Is there some package that 
>> requires Distributions be less-than-current?
>>
>> Thank you,
>> -Tim
>>
>

[julia-users] Re: RDatasets "UndefVarError: displaysize not defined"

[Tony Kelman]

This should be reported as an issue - probably to the DataFrames.jl 
package. Can you get it to happen in Julia 0.4 outside of IJulia?


On Monday, August 29, 2016 at 12:30:19 PM UTC-7, Rock Pereira wrote:
>
> I switched to 0.5.0 rc3
> Everything is OK.
>

[julia-users] Re: Hard time with Compat and 0.5

[Tony Kelman]

You generally only need to call the @compat macro when you're trying to use 
some new syntax that didn't parse correctly on older versions of Julia. If 
it parses correctly, Compat usually implements it with normal functions and 
methods, no need for a syntax-rewriting macro.


On Monday, August 29, 2016 at 6:11:19 AM UTC-7, J Luis wrote:
>
>  
>>
>> No, it is:
>>
>> t = unsafe_wrap(Array, Gb.data, h.size)
>>
>> as in the deprecation warning.
>>
>  
> Thanks (I'd figured it out too meanwhile)
>  
>
>> (You don't need @compat just for function calls.   You only need @compat 
>> for things where the syntax changes in a more complicated way.)
>>
>
> Hmm, what do you mean by this? If I don't use @compat (which I tried) I 
> get tons of deprecation messages. 
>

[julia-users] RFC: Proposing to freeze METADATA for package versions that support Julia 0.3

[Tony Kelman]

In the interest of moving nightly PackageEvaluator testing to running 
against 0.4, 0.5, and 0.6-dev, I'm proposing we freeze METADATA for Julia 
0.3. New package versions that support Julia 0.3 would fail the Travis 
check, by default. We can make case-by-case exceptions if absolutely 
needed, but I believe this is the safest path forward to leaving Julia 0.3 
alone - what currently works should remain working, and nothing new could 
break by releasing some new package versions that do support 0.3 when other 
packages that may depend on that package have moved on to only supporting 
Julia 0.4 a while ago.


If you're a package author, check the minimum Julia version dependency in 
your REQUIRE file. If it already says 0.4 or later, you don't need to do 
anything. If it still says 0.3, this change would mean you should raise the 
minimum Julia version to (at least) 0.4 before making your next tag. And 
when you make that new tag, since it's dropping Julia 0.3 support it should 
use a new package minor version via Pkg.tag("Foo", :minor).

If anyone has any comments or objections, let me know at 
https://github.com/JuliaLang/METADATA.jl/pull/6146. I'll be leaving that 
open for at least a few days.

Re: [julia-users] Invalid history file (~/.julia_history) format

[Tony Kelman]

Looks like this is resolved now, but just for completeness, what are 
ENV["HOMEDRIVE"] and ENV["HOMEPATH"] on your system?

On Thursday, August 25, 2016 at 4:17:59 AM UTC-7, Andy Dobson wrote:
>
> Ah - no - I've got it!  Now it works!  Thank you all very much, especially 
> Kristoffer!
>
>
>
> On Thursday, August 25, 2016 at 12:13:09 PM UTC+1, Andy Dobson wrote:
>>
>> It doesn't seem to. I've tried searching for %.julia_history% to get at 
>> hidden files - is there some other trick to find it?
>>
>>
>>
>> On Thursday, August 25, 2016 at 11:56:22 AM UTC+1, Kristoffer Carlsson 
>> wrote:
>>>
>>> Does that file exist? If so, removing it should fix your problems.
>>>
>>> On Thursday, August 25, 2016 at 12:54:31 PM UTC+2, Andy Dobson wrote:

 It says:

 "M:\\.julia_history"

 (This is not where the program files are written/held - they are on the 
 C-drive, and all outputs are written to a separate networked drive).  

 On Wednesday, August 24, 2016 at 6:05:27 PM UTC+1, Kristoffer Carlsson 
 wrote:
>
> What does it say when you run 
>
> Base.REPL.find_hist_file()
>
>
>
> On Wednesday, August 24, 2016 at 6:31:58 PM UTC+2, Andy Dobson wrote:
>>
>> I've uninstalled everything again, and I *think* I've deleted all 
>> julia-related files, but when I re-install Julia I still get the same 
>> error 
>> message.  
>>
>>
>> On Wednesday, August 24, 2016 at 1:12:25 PM UTC+1, Kristoffer 
>> Carlsson wrote:
>>>
>>> It is likely "~/.juliarc" that is the file you are after.
>>>
>>> On Wednesday, August 24, 2016 at 11:47:16 AM UTC+2, Andy Dobson 
>>> wrote:

 Hi Kristoffer,

 I don't know if this is the right file 
 (/julia-0.4.6/etc/julia/juliarc), but this is what it says:

 # This file should contain site-specific commands to be executed on 
 Julia startup
 # Users should store their own personal commands in homedir(), in a 
 file named .juliarc.jl

 # Set up environment for Julia Windows binary distribution
 ENV["PATH"] = 
 JULIA_HOME*";"*joinpath(JULIA_HOME,"..","Git","bin")*";"*ENV["PATH"]


 Should there be more here? 


 On Wednesday, August 24, 2016 at 10:36:10 AM UTC+1, Kristoffer 
 Carlsson wrote:
>
> Maybe you can look into the .juliarc file at the line where it is 
> telling you the error is and see if anything looks strange.
>
> On Wednesday, August 24, 2016 at 11:11:54 AM UTC+2, Andy Dobson 
> wrote:
>>
>> No, it didn't create another one. I think you're right and I 
>> didn't delete what Julia was looking for. But it seems very strange 
>> that 
>> this error message appeared without any sort of prompt - I'm not 
>> doing 
>> anything that I haven't been doing for the last 6 months.
>>
>>
>> On Tuesday, August 23, 2016 at 1:51:54 PM UTC+1, Stefan Karpinski 
>> wrote:
>>>
>>> That's strange. Did it create a ~/.julia_history file after you 
>>> deleted the old one? If so, what's in it?
>>>
>>> I wonder if the ~/.julia_history file you deleted was not the 
>>> one that Julia's looking at.
>>>
>>> On Tue, Aug 23, 2016 at 8:10 AM, Andy Dobson <
>>> a_d_m_...@hotmail.com> wrote:
>>>
 Hi All, 

 This morning when starting Julia 0.4.3 (which I've been using 
 daily since February) I received this error message : 

 -
 ERROR: Invalid history file (~/.julia_history) format: 
 If you have a history file left over from an older version of 
 Julia, 
 try renaming or deleting it. 
 Invalid character: '#' at line 465034 
  in error at error.jl:22 

 - 

 A thread on this site ("PSA: new ~/.julia_history 
 format") suggested deleting the julia_history file. I tried 
 this, and it did not work. Next I uninstalled Julia and 
 re-installed the 
 latest (0.4.6) version. The error message is the same.   

 Can anybody suggest a solution? I'm running on Windows 7 
 Enterprise. 

 Thanks 

 Andy


>>>

[julia-users] Re: making a sparse matrix with structural zeros?

[Tony Kelman]

A bit. Sparse matrices with stored zeros were mostly an "I know what I'm 
doing" feature until recently. If you're familiar with the CSC data 
structure you can also call the low-level SparseMatrixCSC constructor 
directly:

julia> SparseMatrixCSC(1, 1, [1,2], [1], [0])
1x1 sparse matrix with 1 Int64 entries:
[1, 1]  =  0


On Thursday, August 25, 2016 at 12:23:02 AM UTC-7, Gabriel Goh wrote:
>
> thats a bit of a hack, tho. Guess I can just target Julia 0.5 and ignore 
> this.
>
> On Thursday, August 25, 2016 at 12:01:03 AM UTC-7, Tony Kelman wrote:
>>
>> Try
>>
>> julia> flagval = -123456789
>> -123456789
>>
>> julia> A = sparse([1],[1],flagval)
>> 1×1 sparse matrix with 1 Int64 nonzero entries:
>> [1, 1]  =  -123456789
>>
>> julia> A.nzval[A.nzval .== flagval] = 0
>> 0
>>
>> julia> A
>> 1×1 sparse matrix with 1 Int64 nonzero entries:
>> [1, 1]  =  0
>>
>>
>>
>> On Wednesday, August 24, 2016 at 11:24:29 PM UTC-7, Gabriel Goh wrote:
>>>
>>> Say I want a 1x1 matrix with some structural zeros. Julia 0.4.* gives
>>>
>>> julia> sparse([1],[1], 0)
>>> 1x1 sparse matrix with 0 Int64 entries:
>>>
>>> while Julia 0.5 does
>>>
>>> julia> sparse([1],[1],0)
>>> 1×1 sparse matrix with 1 Int64 nonzero entries:
>>> [1, 1]  =  0
>>>
>>> the latter behavior is what I prefer, is there a way to emulate it in 
>>> Julia 0.4? 
>>>
>>

[julia-users] Re: making a sparse matrix with structural zeros?

[Tony Kelman]

Try

julia> flagval = -123456789
-123456789

julia> A = sparse([1],[1],flagval)
1×1 sparse matrix with 1 Int64 nonzero entries:
[1, 1]  =  -123456789

julia> A.nzval[A.nzval .== flagval] = 0
0

julia> A
1×1 sparse matrix with 1 Int64 nonzero entries:
[1, 1]  =  0



On Wednesday, August 24, 2016 at 11:24:29 PM UTC-7, Gabriel Goh wrote:
>
> Say I want a 1x1 matrix with some structural zeros. Julia 0.4.* gives
>
> julia> sparse([1],[1], 0)
> 1x1 sparse matrix with 0 Int64 entries:
>
> while Julia 0.5 does
>
> julia> sparse([1],[1],0)
> 1×1 sparse matrix with 1 Int64 nonzero entries:
> [1, 1]  =  0
>
> the latter behavior is what I prefer, is there a way to emulate it in 
> Julia 0.4? 
>

[julia-users] Re: Tab completion for sub-modules names

[Tony Kelman]

What version of Julia are you on? My memory might be hazy but there's a 
chance this has been implemented recently on master? If not, then this does 
sound like it would be useful to implement.


On Wednesday, August 24, 2016 at 4:49:50 PM UTC-7, Miguel Goncalves wrote:
>
> In the Julia REPL if I have a super-module Food which loads in a 
> sub-module Fruit,
>
> module Food
>
> using Fruit
>
> include("nutrition.jl")
> export carbohydrate
> export fat
> export protein
>
> end
>
> then pressing tab after typing,
>
> Food.
>
> I get the list,
>
> carbohydratefatprotein
>
> But the sub-module Fruit does not show up for tab completion. However, 
> after manually typing,
>
> Food.Fruit.
>
> I do have tab completion for everything which is exported by the Fruit 
> sub-module.
>
> Could this behavior be changed to support tab completion for sub-modules 
> names? This will facilitate working with nested modules.
>

Re: [julia-users] Re: 0.5.0 rc3 error

[Tony Kelman]

The actual error likely occurred much earlier. You could try

for i in `seq 10` do; make -j4; done

then you'd probably see the actual error.

If I had to guess, you're probably missing one or more of gfortran, libssl-dev, 
m4, or cmake.

[julia-users] algorithmic linear algebra question

[Tony Kelman]

Try https://github.com/simonbyrne/GenericSVD.jl ?

[julia-users] Re: ANN: Julia 0.5.0-rc2 now available

[Tony Kelman]

Release candidate 3 is now available:

https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc3-linux-x86_64.tar.gz
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc3-linux-i686.tar.gz
 
https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc3-osx10.7+.dmg 
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc3-win64.exe 
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc3-win32.exe 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc3.sha256 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc3.md5

This has backported the addition of proxy support for the package manager 
via libcurl on Linux and Mac (libgit2 should support proxies fine on 
Windows without needing libcurl). Please test and report any issues. There 
are some open pull requests fixing issues involving precompilation that we 
will likely want to make a release candidate 4 with towards the end of the 
week or early next week, but if nothing else major comes up, that could be 
our last RC before tagging 0.5.0 final.


On Friday, August 12, 2016 at 5:38:20 AM UTC-7, Tony Kelman wrote:
>
> I have just tagged and uploaded release candidate 2 for Julia version 
> 0.5.0. Binaries are available from
>
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc2-linux-x86_64.tar.gz
>  
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc2-linux-i686.tar.gz
>  
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc2-osx10.7+.dmg
>  
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc2-win64.exe
>  
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc2-win32.exe
>  
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.sha256 
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.md5 
> For gpg signatures (with this key http://julialang.org/juliareleases.asc) 
> of the Linux tar.gz binaries, append .asc to the filename.
>
> (arm binaries are taking a while to build, I will upload them later - we 
> will also put links to this release candidate on the web site soon)
>
> The primary thing this does not yet include that we do plan on getting 
> into the final 0.5.0 release is proxy support for the package manager. A 
> preliminary version of that has been merged to master but still has some 
> build system issues that need to be worked out. We will put out a release 
> candidate 3 next week that will hopefully have this resolved, along with 
> any other major bug fixes that happen by then. If all goes well and no 
> major blocking issues come up after that, RC3 could possibly be the last 
> release candidate and promoted to final, but we will see how it goes next 
> week. Follow the progress at 
> https://github.com/JuliaLang/julia/issues/17418 and please report any 
> issues you find.
>
> -Tony
>
>

[julia-users] Re: JupyterLab

[Tony Kelman]

I saw a demo of this a few days ago at PyData SF. And I think they gave an 
earlier demo at PyData London. The video for the latter is probably already 
uploaded, and the former should get posted soon.

[julia-users] Re: IJulia kernel dies repeatedly with 0.5.0-rc2

[Tony Kelman]

Please provide as much information as possible with reports like this. 
Exactly what output and error messages are you seeing? The download links 
posted in the mailing list announcement threads should still work, you can 
install multiple versions of Julia side by side.


On Friday, August 12, 2016 at 2:27:38 PM UTC-7, Chris Stook wrote:
>
> I'm using Windows 10.  I updated to 0.5.0-rc2, then performed the 
> following updates.
>
> Pkg.update()
> Pkg.build("IJulia")
>
> There were lots of warnings, and ZMQ failed to build.
>
> Now, when I open IJulia the kernel repeatedly dies and restarts.
>
> Is there a fix for this?
>
> If I just need to wait for rc3, how do I go back to rc0 until then?
>
> Thanks,
> Chris
>

[julia-users] Re: Juno IDE Console Error: supertype not defined

[Tony Kelman]

I believe there was an update of Media.jl that should have fixed this, what 
does Pkg.status() say?

On Friday, August 12, 2016 at 1:40:11 PM UTC-7, Andrew Rushby wrote:
>
> I'm running into the same error message. I've tried reinstalling as well 
> as Pkg.update() as I've seen suggested elsewhere, but no luck. As I'm 
> rather new to this, is there anything else I could try?
>
> On Thursday, 11 August 2016 18:25:57 UTC-7, Tony Kelman wrote:
>>
>> This is what happens when packages Juno depends on have no unit tests. It 
>> looks like it's been fixed on master of Media.jl which should get tagged 
>> shortly.
>>
>> On Thursday, August 11, 2016 at 3:59:27 PM UTC-7, Kaela Martin wrote:
>>>
>>> When running Juno IDE with Atom, I get the following error message:
>>>
>>> UndefVarError: supertype not defined
>>>  in distance at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:8
>>>  in nearest at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:13
>>>  in anonymous at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:17
>>>  in _mapreduce at reduce.jl:145
>>>  in mapreduce at reduce.jl:159
>>>  in nearest at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:16
>>>  in getdisplay at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:114
>>>  in render at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:166
>>>  [inlined code] from C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:41
>>>  in anonymous at C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:108
>>>  in withpath at C:\Users\kaelam\.julia\v0.4\Requires\src\require.jl:37
>>>  in withpath at C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:53
>>>  [inlined code] from C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:107
>>>  in anonymous at task.jl:58
>>>
>>> I've tried uninstalling the Media package, deleting the file manually, 
>>> updating the packages, and still get the same error when using Atom. The 
>>> Julia terminal works fine, but the console in Atom fails for any input even 
>>> 1+1.
>>>
>>> Unistalling and re-installing IDE results in the same error. Any 
>>> suggestions?
>>>
>>

[julia-users] Re: ANN: Julia 0.5.0-rc2 now available

[Tony Kelman]

Could you try to profile and see where the time is spent? LLVM 3.7 (used on 
0.5) is known to be significantly slower in compile time than LLVM 3.3 
(used on 0.4).


On Friday, August 12, 2016 at 8:52:42 AM UTC-7, Uwe Fechner wrote:
>
> Thanks your hard work!
>
> Nevertheless I am a little bit disappointed with the time, needed for 
> including my own code.
> With Julia 0.5.0rc2 it needs 11.5 s, with Julia 0.4.6 it was only 6.34 s. 
> Is this to be expected?
>
> I am using packages like PyPlot and JuMP, but I think they are precompiled.
>
> (On Ubuntu 16.06, 64 bits).
>
> Julia 0.5.0 rc2
>
> julia> tic();include("Plotting.jl");toc()
> Min (nonlinear expression)
> Subject to
>  1 nonlinear constraint
>  0.15 ≤ area ≤ 2500
>  60 ≤ height ≤ 500
> elapsed time: 11.500368527 seconds
> 11.500368527
>
> julia> tic();aenarete();toc()
>
>
> **
> This program contains Ipopt, a library for large-scale nonlinear 
> optimization.
>  Ipopt is released as open source code under the Eclipse Public License 
> (EPL).
>  For more information visit http://projects.coin-or.org/Ipopt
>
> **
>
> elapsed time: 7.29577799 seconds
> 7.29577799
>
>
> --
>
> Julia 0.4.6
>
> julia> tic();include("Plotting.jl");toc()
> Min (nonlinear expression)
> Subject to
>  1 nonlinear constraint
>  0.15 ≤ area ≤ 2500
>  60 ≤ height ≤ 500
> elapsed time: 6.347609088 seconds
> 6.347609088
>
> julia> tic();aenarete();toc()
>
>
> **
> This program contains Ipopt, a library for large-scale nonlinear 
> optimization.
>  Ipopt is released as open source code under the Eclipse Public License 
> (EPL).
>  For more information visit http://projects.coin-or.org/Ipopt
>
> **
>
> elapsed time: 6.116511336 seconds
> 6.116511336
>
> On Friday, August 12, 2016 at 2:38:20 PM UTC+2, Tony Kelman wrote:
>>
>> I have just tagged and uploaded release candidate 2 for Julia version 
>> 0.5.0. Binaries are available from
>>
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc2-linux-x86_64.tar.gz
>>  
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc2-linux-i686.tar.gz
>>  
>>
>> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc2-osx10.7+.dmg
>>  
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc2-win64.exe
>>  
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc2-win32.exe
>>  
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.sha256 
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.md5 
>> For gpg signatures (with this key http://julialang.org/juliareleases.asc) 
>> of the Linux tar.gz binaries, append .asc to the filename.
>>
>> (arm binaries are taking a while to build, I will upload them later - we 
>> will also put links to this release candidate on the web site soon)
>>
>> The primary thing this does not yet include that we do plan on getting 
>> into the final 0.5.0 release is proxy support for the package manager. A 
>> preliminary version of that has been merged to master but still has some 
>> build system issues that need to be worked out. We will put out a release 
>> candidate 3 next week that will hopefully have this resolved, along with 
>> any other major bug fixes that happen by then. If all goes well and no 
>> major blocking issues come up after that, RC3 could possibly be the last 
>> release candidate and promoted to final, but we will see how it goes next 
>> week. Follow the progress at 
>> https://github.com/JuliaLang/julia/issues/17418 and please report any 
>> issues you find.
>>
>> -Tony
>>
>>

[julia-users] ANN: Julia 0.5.0-rc2 now available

[Tony Kelman]

I have just tagged and uploaded release candidate 2 for Julia version 
0.5.0. Binaries are available from

https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc2-linux-x86_64.tar.gz
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc2-linux-i686.tar.gz
 
https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc2-osx10.7+.dmg 
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc2-win64.exe 
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc2-win32.exe 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.sha256 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.md5 
For gpg signatures (with this key http://julialang.org/juliareleases.asc) 
of the Linux tar.gz binaries, append .asc to the filename.

(arm binaries are taking a while to build, I will upload them later - we 
will also put links to this release candidate on the web site soon)

The primary thing this does not yet include that we do plan on getting into 
the final 0.5.0 release is proxy support for the package manager. A 
preliminary version of that has been merged to master but still has some 
build system issues that need to be worked out. We will put out a release 
candidate 3 next week that will hopefully have this resolved, along with 
any other major bug fixes that happen by then. If all goes well and no 
major blocking issues come up after that, RC3 could possibly be the last 
release candidate and promoted to final, but we will see how it goes next 
week. Follow the progress at https://github.com/JuliaLang/julia/issues/17418 
and please report any issues you find.

-Tony

[julia-users] Re: Juno IDE Console Error: supertype not defined

[Tony Kelman]

This is what happens when packages Juno depends on have no unit tests. It 
looks like it's been fixed on master of Media.jl which should get tagged 
shortly.

On Thursday, August 11, 2016 at 3:59:27 PM UTC-7, Kaela Martin wrote:
>
> When running Juno IDE with Atom, I get the following error message:
>
> UndefVarError: supertype not defined
>  in distance at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:8
>  in nearest at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:13
>  in anonymous at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:17
>  in _mapreduce at reduce.jl:145
>  in mapreduce at reduce.jl:159
>  in nearest at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:16
>  in getdisplay at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:114
>  in render at C:\Users\kaelam\.julia\v0.4\Media\src\system.jl:166
>  [inlined code] from C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:41
>  in anonymous at C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:108
>  in withpath at C:\Users\kaelam\.julia\v0.4\Requires\src\require.jl:37
>  in withpath at C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:53
>  [inlined code] from C:\Users\kaelam\.julia\v0.4\Atom\src\eval.jl:107
>  in anonymous at task.jl:58
>
> I've tried uninstalling the Media package, deleting the file manually, 
> updating the packages, and still get the same error when using Atom. The 
> Julia terminal works fine, but the console in Atom fails for any input even 
> 1+1.
>
> Unistalling and re-installing IDE results in the same error. Any 
> suggestions?
>

Re: [julia-users] Julia and sshd tests

[Tony Kelman]

The warning makes sense since it is skipping some tests. I'm asking more 
how we can avoid skipping those tests on non-Debian distros, without 
writing lots more Julia code.


On Tuesday, August 9, 2016 at 10:55:52 AM UTC-7, Keno Fischer wrote:
>
> Well, we could write an ssh server in julia and just use that to test 
> against, but who would want to do that ;). If it's just a matter of me 
> having put a scary warning there, I guess we can take that out.
>
> On Tue, Aug 9, 2016 at 1:44 PM, Tony Kelman  > wrote:
>
>> Though we should try to make them more flexible to run on distributions 
>> that have them in non-Debian locations. Is there an alternative way we can 
>> get those tests to run via an executable that can run as non-root on 
>> openSUSE?
>>
>>
>> On Tuesday, August 9, 2016 at 7:39:42 AM UTC-7, Keno Fischer wrote:
>>>
>>> The tests that are being bypassed are for functionality of the package 
>>> manager's SSH client capability for git clone over SSH. So yes, those tests 
>>> are bypassed if ssh is not available, but is shouldn't be a big problem as 
>>> long as SSH clone runs ok. I think the more important aspect of those tests 
>>> is that they run on CI to make sure we don't accidentally break the various 
>>> ways to clone over SSH.
>>>
>>> On Tue, Aug 9, 2016 at 2:40 AM, Colin Beckingham  
>>> wrote:
>>>
>>>> I always run Julia as non-root, so there is not much surprise when 
>>>> "make testall" says it cannot find sshd, which on openSUSE lives in 
>>>> /usr/sbin and is not accessible by non-root due to permissions. Testall by 
>>>> normal user bypasses the related test and continues to success. Attempting 
>>>> to run Julia as root to allow this test to run results in error in testing 
>>>> libgit2 since no keys are set up. I'm not worrying about this until I have 
>>>> good reason to run Julia in root. Does the fact that openSUSE makes sshd 
>>>> unavailable to non-root users bypass some important tests?
>>>>
>>>
>>>
>

Re: [julia-users] Julia and sshd tests

[Tony Kelman]

Though we should try to make them more flexible to run on distributions 
that have them in non-Debian locations. Is there an alternative way we can 
get those tests to run via an executable that can run as non-root on 
openSUSE?


On Tuesday, August 9, 2016 at 7:39:42 AM UTC-7, Keno Fischer wrote:
>
> The tests that are being bypassed are for functionality of the package 
> manager's SSH client capability for git clone over SSH. So yes, those tests 
> are bypassed if ssh is not available, but is shouldn't be a big problem as 
> long as SSH clone runs ok. I think the more important aspect of those tests 
> is that they run on CI to make sure we don't accidentally break the various 
> ways to clone over SSH.
>
> On Tue, Aug 9, 2016 at 2:40 AM, Colin Beckingham  > wrote:
>
>> I always run Julia as non-root, so there is not much surprise when "make 
>> testall" says it cannot find sshd, which on openSUSE lives in /usr/sbin and 
>> is not accessible by non-root due to permissions. Testall by normal user 
>> bypasses the related test and continues to success. Attempting to run Julia 
>> as root to allow this test to run results in error in testing libgit2 since 
>> no keys are set up. I'm not worrying about this until I have good reason to 
>> run Julia in root. Does the fact that openSUSE makes sshd unavailable to 
>> non-root users bypass some important tests?
>>
>
>

[julia-users] Re: julia and sparse matrix computation: is there plan?

[Tony Kelman]

Given that SuiteSparse.jl is a package and not part of base Julia, it 
doesn't have to meet the quality standards that code contributed to Base 
usually would. Publicly posted code (with a license or agreement to 
contribute under an existing license) is better than nothing, and the 
maintainers of that package can decide what quality bar it would have to 
meet - in terms of tests and documentation, which is what I assume you mean 
- before merging it. Even just an open pull request would serve as a 
starting point for discussion to see who else would be interested.


On Friday, August 5, 2016 at 4:12:17 PM UTC-7, vav...@uwaterloo.ca wrote:
>
> Tony,
>
> I would be happy to share my prototypes for these wrappers with you or 
> anyone else, but I would not be interested in implementing and testing 
> library versions of them.  This was the point of my first posting.  It's 
> not clear to me who would be interested in that thankless and 
> time-consuming task.  Just like you, I have a "day job"!
>
> -- Steve
>
>
> On Friday, August 5, 2016 at 6:11:45 PM UTC-4, Tony Kelman wrote:
>>
>> Those all sound useful and would be worth contributing to the 
>> SuiteSparse.jl package if you'd like to do that.
>>
>>
>> On Friday, August 5, 2016 at 3:07:14 PM UTC-7, vav...@uwaterloo.ca wrote:
>>>
>>> Tony,
>>>
>>> Here are a few Julia routines sparse matrix routines that I looked for 
>>> and didn't find.  Maybe I looked in the wrong place.
>>>
>>> - Getting the P'*L factor from SuiteSparse's sparse Cholesky back into 
>>> Julia.  In other words, if F is the cholmod representation of the Cholesky 
>>> factor, then sparse(F[:L]) works to retrieve the L factor, but 
>>> sparse(F[:PtL]) does not work to retrieve P'*L (so I wrote my own wrapper).
>>>
>>> - A general routine for computing a null vector.  So I wrote my own, 
>>> based on the squeezed SuiteSparse QR factorization.  (See the next item.)
>>>
>>> - A routine to extract the squeezed R factor from the SuiteSparse QR 
>>> factorization.  I wrote a wrapper for this.
>>>
>>> All of this functionality is built into Matlab.
>>>
>>> -- Steve
>>>
>>>
>>>
>>> On Friday, August 5, 2016 at 5:54:24 PM UTC-4, Tony Kelman wrote:
>>>>
>>>> > Furthermore, the exposed APIs give the Julia programmer significantly 
>>>> fewer capabilities than the sparse matrix suite of Matlab.
>>>>
>>>> Like what? There is a SuiteSparse.jl package under the JuliaSparse 
>>>> organization that currently has a handful of routines (Julia ports) but 
>>>> will be the home as more of the bindings gradually get migrated there, and 
>>>> out of base Julia. The long-term plan is to be less reliant on SuiteSparse 
>>>> as the only option, and instead to come up with a more general interface 
>>>> that multiple different solver packages could plug into. Outside of base 
>>>> Julia, a SuiteSparse.jl package would be more flexible to wrap as much of 
>>>> the SuiteSparse API as its contributors and maintainers choose.
>>>>
>>>>
>>>> On Friday, August 5, 2016 at 2:17:09 PM UTC-7, vav...@uwaterloo.ca 
>>>> wrote:
>>>>>
>>>>> Sparse matrix computation is a key aspect of scientific computing. 
>>>>>  The creators of Julia made the smart decision to rely on SuiteSparse, 
>>>>> high-quality free C++ software that carries out most of the common sparse 
>>>>> matrix factorizations and related operations very efficiently.
>>>>>
>>>>> The issue that concerns me is that the wrappers in Julia, namely, 
>>>>> cholmod.jl, spqr.jl and umfpack.jl, expose only a small fraction of 
>>>>> SuiteSparse's capabilities.  Furthermore, the exposed APIs give the Julia 
>>>>> programmer significantly fewer capabilities than the sparse matrix suite 
>>>>> of 
>>>>> Matlab.
>>>>>
>>>>> And the reason for this limitation has become clear to me over the 
>>>>> past few days as I tried to develop a routine to find a right null vector 
>>>>> of a sparse matrix using SuiteSparse: it is difficult and tedious to 
>>>>> write 
>>>>> Julia wrappers for the routines in SuiteSparse.  Even figuring out 
>>>>> whether 
>>>>> a particular variable is an Int32 or Int64 requires poring over 
>>>>> SuiteSparse's nested header files full of conditional platform-dependent 
>>>>> compilation directives.  And my resulting wrapper works only on one 
>>>>> platform for one version of Julia and one version of SuiteSparse.  It is 
>>>>> clear that whoever wrote cholmod.jl, spqr.jl and umfpack.jl put a lot of 
>>>>> time and painstaking effort into getting these interfaces correct.
>>>>>
>>>>> And this raises a question: will Julia ever fully incorporate 
>>>>> SuiteSparse?  Will its sparse matrix capabilities ever approach Matlab's? 
>>>>>  Who will take the time to write, test and maintain cross-platform Julia 
>>>>> wrappers for SuiteSparse?  This is a tedious job that carries little 
>>>>> glory 
>>>>> - I certainly would not want to do it!  And yet sparse matrix computation 
>>>>> is so important.
>>>>>
>>>>>

Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

> But I can't change those settings, these are not my packages. 

You set in the yml file, you can do it in a PR.


On Friday, August 5, 2016 at 4:00:08 PM UTC-7, David Anthoff wrote:
>
> > There's a setting on both travis and appveyor where you can mark certain 
> > entries in the build matrix as allowed failures. So they will run and 
> you can 
> > look at the logs, but failing won't cause a red status. This is good for 
> nightlies 
> > or when a package doesn't entirely support 32 bit, etc. 
>
> But I can't change those settings, these are not my packages. 
>
> > You should be changing the appveyor files in the same PR to add testing 
> > against 0.5 anyway. Same on Travis, "release" is going to change meaning 
> so 
> > it's better to split entries for 0.4 and 0.5. 
>
> Yep, been doing that. 
>
> > What I'll do right now is replace the 0.5-latest downloads on s3 with 
> rc1+1. 
> > That way Travis and Appveyor can have this bug fixed, but we're not 
> making 
> > a new tag until more things are backported. 
>
> That is perfect, that will completely solve this problem, thanks! 
>

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

There's a setting on both travis and appveyor where you can mark certain 
entries in the build matrix as allowed failures. So they will run and you can 
look at the logs, but failing won't cause a red status. This is good for 
nightlies or when a package doesn't entirely support 32 bit, etc.

You should be changing the appveyor files in the same PR to add testing against 
0.5 anyway. Same on Travis, "release" is going to change meaning so it's better 
to split entries for 0.4 and 0.5.

What I'll do right now is replace the 0.5-latest downloads on s3 with rc1+1. 
That way Travis and Appveyor can have this bug fixed, but we're not making a 
new tag until more things are backported.

Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

> I’m not going to change their appveyor to nightly builds

Why not? You can make it an allowed failure for now.


On Friday, August 5, 2016 at 3:17:29 PM UTC-7, David Anthoff wrote:
>
> Well, I was hopping around opening PRs in packages that I don’t maintain 
> and fixing 0.5 compat things in those packages. I’m not going to change 
> their appveyor to nightly builds, so I’ll just stop fixing other packages 
> until RC2 is out.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Tony Kelman
> *Sent:* Friday, August 5, 2016 2:56 PM
> *To:* julia-users >
> *Subject:* Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries 
> available
>
>  
>
> Use nightly for now, or change your appveyor script to temporarily 
> download these rc1+1 binaries. There are a lot of things pending for 
> backporting to the release-0.5 branch, and I'd like to test them properly 
> before making another tag.
>
> On Friday, August 5, 2016 at 2:26:47 PM UTC-7, David Anthoff wrote:
>
> Any chance you could just tag RC2 really soon, before the normal weekly 
> schedule? This 
> https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549 
> being on RC1 essentially breaks all appveyor builds on julia 0.5 right now, 
> and that makes cleaning up packages really difficult.
>
>  
>
> Manual links to RC1+1 binaries don’t end up on the appveyor builds, so 
> that is not really a practical option. My sense is that people would have 
> to put package cleanup on hold until appveyor builds are back in business, 
> which seems really not good. After all the whole point of releasing these 
> RCs that are not candidates for a release is presumably so that package 
> maintainers can get their packages to work on 0.5.
>
>  
>
> Cheers,
>
> David
>
>  
>
>  
>
> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
> Behalf Of *Tony Kelman
> *Sent:* Friday, August 5, 2016 10:49 AM
> *To:* julia-users 
> *Subject:* Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries 
> available
>
>  
>
> rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful 
> to test against:
>
>
> https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
>
> https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
>
> https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe
>
> (these links will stop working in about a month since julianightlies 
> doesn't keep files around forever, but consider this an early preview 
> between rc1 and rc2)
>
>
> On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:
>
> > always the latest RC, and then the final version?
>
> Yes.
>
> We don't currently do automated nightly builds from release branches. Any 
> sha from a branch within JuliaLang/julia can easily be built on demand 
> though.
>
>
> On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:
>
> Excellent!
>
>  
>
> Going forward, what will I get from
>
>  
>
>
> http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe
>
>  
>
> I assume not nightly builds from the release-0.5 branch, but always the 
> latest RC, and then the final version?
>
>  
>
> Is there a stable link that would get me the nightly builds from 
> release-0.5 on windows?
>
>  
>
> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
> Behalf Of *Tony Kelman
> *Sent:* Thursday, August 4, 2016 6:53 AM
> *To:* julia-users 
> *Subject:* [julia-users] Re: Announcing 0.5.0-rc0 and binaries available
>
>  
>
> 0.5.0-rc1 has been tagged and binaries are now available.
>
>
> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
> https://s3.amazonaws.com/julialang/bin/checksum

[julia-users] Re: julia and sparse matrix computation: is there plan?

[Tony Kelman]

Those all sound useful and would be worth contributing to the 
SuiteSparse.jl package if you'd like to do that.


On Friday, August 5, 2016 at 3:07:14 PM UTC-7, vav...@uwaterloo.ca wrote:
>
> Tony,
>
> Here are a few Julia routines sparse matrix routines that I looked for and 
> didn't find.  Maybe I looked in the wrong place.
>
> - Getting the P'*L factor from SuiteSparse's sparse Cholesky back into 
> Julia.  In other words, if F is the cholmod representation of the Cholesky 
> factor, then sparse(F[:L]) works to retrieve the L factor, but 
> sparse(F[:PtL]) does not work to retrieve P'*L (so I wrote my own wrapper).
>
> - A general routine for computing a null vector.  So I wrote my own, based 
> on the squeezed SuiteSparse QR factorization.  (See the next item.)
>
> - A routine to extract the squeezed R factor from the SuiteSparse QR 
> factorization.  I wrote a wrapper for this.
>
> All of this functionality is built into Matlab.
>
> -- Steve
>
>
>
> On Friday, August 5, 2016 at 5:54:24 PM UTC-4, Tony Kelman wrote:
>>
>> > Furthermore, the exposed APIs give the Julia programmer significantly 
>> fewer capabilities than the sparse matrix suite of Matlab.
>>
>> Like what? There is a SuiteSparse.jl package under the JuliaSparse 
>> organization that currently has a handful of routines (Julia ports) but 
>> will be the home as more of the bindings gradually get migrated there, and 
>> out of base Julia. The long-term plan is to be less reliant on SuiteSparse 
>> as the only option, and instead to come up with a more general interface 
>> that multiple different solver packages could plug into. Outside of base 
>> Julia, a SuiteSparse.jl package would be more flexible to wrap as much of 
>> the SuiteSparse API as its contributors and maintainers choose.
>>
>>
>> On Friday, August 5, 2016 at 2:17:09 PM UTC-7, vav...@uwaterloo.ca wrote:
>>>
>>> Sparse matrix computation is a key aspect of scientific computing.  The 
>>> creators of Julia made the smart decision to rely on SuiteSparse, 
>>> high-quality free C++ software that carries out most of the common sparse 
>>> matrix factorizations and related operations very efficiently.
>>>
>>> The issue that concerns me is that the wrappers in Julia, namely, 
>>> cholmod.jl, spqr.jl and umfpack.jl, expose only a small fraction of 
>>> SuiteSparse's capabilities.  Furthermore, the exposed APIs give the Julia 
>>> programmer significantly fewer capabilities than the sparse matrix suite of 
>>> Matlab.
>>>
>>> And the reason for this limitation has become clear to me over the past 
>>> few days as I tried to develop a routine to find a right null vector of a 
>>> sparse matrix using SuiteSparse: it is difficult and tedious to write Julia 
>>> wrappers for the routines in SuiteSparse.  Even figuring out whether a 
>>> particular variable is an Int32 or Int64 requires poring over SuiteSparse's 
>>> nested header files full of conditional platform-dependent compilation 
>>> directives.  And my resulting wrapper works only on one platform for one 
>>> version of Julia and one version of SuiteSparse.  It is clear that whoever 
>>> wrote cholmod.jl, spqr.jl and umfpack.jl put a lot of time and painstaking 
>>> effort into getting these interfaces correct.
>>>
>>> And this raises a question: will Julia ever fully incorporate 
>>> SuiteSparse?  Will its sparse matrix capabilities ever approach Matlab's? 
>>>  Who will take the time to write, test and maintain cross-platform Julia 
>>> wrappers for SuiteSparse?  This is a tedious job that carries little glory 
>>> - I certainly would not want to do it!  And yet sparse matrix computation 
>>> is so important.
>>>
>>>

Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

Use nightly for now, or change your appveyor script to temporarily download 
these rc1+1 binaries. There are a lot of things pending for backporting to 
the release-0.5 branch, and I'd like to test them properly before making 
another tag.

On Friday, August 5, 2016 at 2:26:47 PM UTC-7, David Anthoff wrote:
>
> Any chance you could just tag RC2 really soon, before the normal weekly 
> schedule? This 
> https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549 
> being on RC1 essentially breaks all appveyor builds on julia 0.5 right now, 
> and that makes cleaning up packages really difficult.
>
>  
>
> Manual links to RC1+1 binaries don’t end up on the appveyor builds, so 
> that is not really a practical option. My sense is that people would have 
> to put package cleanup on hold until appveyor builds are back in business, 
> which seems really not good. After all the whole point of releasing these 
> RCs that are not candidates for a release is presumably so that package 
> maintainers can get their packages to work on 0.5.
>
>  
>
> Cheers,
>
> David
>
>  
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Tony Kelman
> *Sent:* Friday, August 5, 2016 10:49 AM
> *To:* julia-users >
> *Subject:* Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries 
> available
>
>  
>
> rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful 
> to test against:
>
>
> https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
>
> https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
>
> https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
>
> https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe
>
> (these links will stop working in about a month since julianightlies 
> doesn't keep files around forever, but consider this an early preview 
> between rc1 and rc2)
>
>
> On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:
>
> > always the latest RC, and then the final version?
>
> Yes.
>
> We don't currently do automated nightly builds from release branches. Any 
> sha from a branch within JuliaLang/julia can easily be built on demand 
> though.
>
>
> On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:
>
> Excellent!
>
>  
>
> Going forward, what will I get from
>
>  
>
>
> http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe
>
>  
>
> I assume not nightly builds from the release-0.5 branch, but always the 
> latest RC, and then the final version?
>
>  
>
> Is there a stable link that would get me the nightly builds from 
> release-0.5 on windows?
>
>  
>
> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
> Behalf Of *Tony Kelman
> *Sent:* Thursday, August 4, 2016 6:53 AM
> *To:* julia-users 
> *Subject:* [julia-users] Re: Announcing 0.5.0-rc0 and binaries available
>
>  
>
> 0.5.0-rc1 has been tagged and binaries are now available.
>
>
> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5
>
> (append .asc to the linux .tar.gz links for gpg signatures)
>
>
> There will be a RC2 next week. An especially nasty bug was introduced on 
> master right before we branched for release-0.5 and I unfortunately missed 
> it in my testing. I had a PkgEval run going but tagged before it was 
> finished, in order to get binaries building. I won't be repeating that 
> mistake next time.
>
>
> On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:
>
> Hello everyone,
>
>  
>
> You may have noticed 0.5.0-rc0 being tagged last week. The binaries are 
> now all ready and available for testing. This is

[julia-users] Re: julia and sparse matrix computation: is there plan?

[Tony Kelman]

> Furthermore, the exposed APIs give the Julia programmer significantly 
fewer capabilities than the sparse matrix suite of Matlab.

Like what? There is a SuiteSparse.jl package under the JuliaSparse 
organization that currently has a handful of routines (Julia ports) but 
will be the home as more of the bindings gradually get migrated there, and 
out of base Julia. The long-term plan is to be less reliant on SuiteSparse 
as the only option, and instead to come up with a more general interface 
that multiple different solver packages could plug into. Outside of base 
Julia, a SuiteSparse.jl package would be more flexible to wrap as much of 
the SuiteSparse API as its contributors and maintainers choose.


On Friday, August 5, 2016 at 2:17:09 PM UTC-7, vav...@uwaterloo.ca wrote:
>
> Sparse matrix computation is a key aspect of scientific computing.  The 
> creators of Julia made the smart decision to rely on SuiteSparse, 
> high-quality free C++ software that carries out most of the common sparse 
> matrix factorizations and related operations very efficiently.
>
> The issue that concerns me is that the wrappers in Julia, namely, 
> cholmod.jl, spqr.jl and umfpack.jl, expose only a small fraction of 
> SuiteSparse's capabilities.  Furthermore, the exposed APIs give the Julia 
> programmer significantly fewer capabilities than the sparse matrix suite of 
> Matlab.
>
> And the reason for this limitation has become clear to me over the past 
> few days as I tried to develop a routine to find a right null vector of a 
> sparse matrix using SuiteSparse: it is difficult and tedious to write Julia 
> wrappers for the routines in SuiteSparse.  Even figuring out whether a 
> particular variable is an Int32 or Int64 requires poring over SuiteSparse's 
> nested header files full of conditional platform-dependent compilation 
> directives.  And my resulting wrapper works only on one platform for one 
> version of Julia and one version of SuiteSparse.  It is clear that whoever 
> wrote cholmod.jl, spqr.jl and umfpack.jl put a lot of time and painstaking 
> effort into getting these interfaces correct.
>
> And this raises a question: will Julia ever fully incorporate SuiteSparse? 
>  Will its sparse matrix capabilities ever approach Matlab's?  Who will take 
> the time to write, test and maintain cross-platform Julia wrappers for 
> SuiteSparse?  This is a tedious job that carries little glory - I certainly 
> would not want to do it!  And yet sparse matrix computation is so important.
>
>

Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful 
to test against:

https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe

(these links will stop working in about a month since julianightlies 
doesn't keep files around forever, but consider this an early preview 
between rc1 and rc2)


On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:
>
> > always the latest RC, and then the final version?
>
> Yes.
>
> We don't currently do automated nightly builds from release branches. Any 
> sha from a branch within JuliaLang/julia can easily be built on demand 
> though.
>
>
> On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:
>>
>> Excellent!
>>
>>  
>>
>> Going forward, what will I get from
>>
>>  
>>
>>
>> http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe
>>
>>  
>>
>> I assume not nightly builds from the release-0.5 branch, but always the 
>> latest RC, and then the final version?
>>
>>  
>>
>> Is there a stable link that would get me the nightly builds from 
>> release-0.5 on windows?
>>
>>  
>>
>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
>> Behalf Of *Tony Kelman
>> *Sent:* Thursday, August 4, 2016 6:53 AM
>> *To:* julia-users 
>> *Subject:* [julia-users] Re: Announcing 0.5.0-rc0 and binaries available
>>
>>  
>>
>> 0.5.0-rc1 has been tagged and binaries are now available.
>>
>>
>> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5
>>
>> (append .asc to the linux .tar.gz links for gpg signatures)
>>
>>
>> There will be a RC2 next week. An especially nasty bug was introduced on 
>> master right before we branched for release-0.5 and I unfortunately missed 
>> it in my testing. I had a PkgEval run going but tagged before it was 
>> finished, in order to get binaries building. I won't be repeating that 
>> mistake next time.
>>
>>
>> On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:
>>
>> Hello everyone,
>>
>>  
>>
>> You may have noticed 0.5.0-rc0 being tagged last week. The binaries are 
>> now all ready and available for testing. This is a good point for package 
>> developers to make their packages ready for 0.5, and for users to test 
>> their codes on the new release.
>>
>>  
>>
>>
>> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc0-linux-arm.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc0-linux-x86_64.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc0-linux-i686.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc0-osx10.7+.dmg
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc0-win64.exe
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc0-win32.exe
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.sha256
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.md5
>>
>>  
>>
>> We expect to have a new rc roughly every week until all the dust settles 
>> and 0.5.0 is finally released. Follow the progress at:
>>
>>  
>>
>> https://github.com/JuliaLang/julia/issues/17418
>>
>>  
>>
>> -viral
>>
>>  
>>
>>

[julia-users] CALL TO ACTION for package devs

[Tony Kelman]

Depends on the package, but it rarely hurts to ask.

Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

> always the latest RC, and then the final version?

Yes.

We don't currently do automated nightly builds from release branches. Any 
sha from a branch within JuliaLang/julia can easily be built on demand 
though.


On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:
>
> Excellent!
>
>  
>
> Going forward, what will I get from
>
>  
>
>
> http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe
>
>  
>
> I assume not nightly builds from the release-0.5 branch, but always the 
> latest RC, and then the final version?
>
>  
>
> Is there a stable link that would get me the nightly builds from 
> release-0.5 on windows?
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Tony Kelman
> *Sent:* Thursday, August 4, 2016 6:53 AM
> *To:* julia-users >
> *Subject:* [julia-users] Re: Announcing 0.5.0-rc0 and binaries available
>
>  
>
> 0.5.0-rc1 has been tagged and binaries are now available.
>
>
> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5
>
> (append .asc to the linux .tar.gz links for gpg signatures)
>
>
> There will be a RC2 next week. An especially nasty bug was introduced on 
> master right before we branched for release-0.5 and I unfortunately missed 
> it in my testing. I had a PkgEval run going but tagged before it was 
> finished, in order to get binaries building. I won't be repeating that 
> mistake next time.
>
>
> On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:
>
> Hello everyone,
>
>  
>
> You may have noticed 0.5.0-rc0 being tagged last week. The binaries are 
> now all ready and available for testing. This is a good point for package 
> developers to make their packages ready for 0.5, and for users to test 
> their codes on the new release.
>
>  
>
>
> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc0-linux-arm.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc0-linux-x86_64.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc0-linux-i686.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc0-osx10.7+.dmg
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc0-win64.exe
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc0-win32.exe
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.sha256
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.md5
>
>  
>
> We expect to have a new rc roughly every week until all the dust settles 
> and 0.5.0 is finally released. Follow the progress at:
>
>  
>
> https://github.com/JuliaLang/julia/issues/17418
>
>  
>
> -viral
>
>  
>
>

[julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

https://github.com/JuliaLang/julia/issues/17809, made visible on master by 
https://github.com/JuliaLang/julia/pull/17774 but evidently pre-existing? 
Reverting #17774 might be the simplest thing to do immediately, but I'm not 
sure - some deep details of the type system appear to be causing the issue.


On Thursday, August 4, 2016 at 7:09:11 AM UTC-7, Uwe Fechner wrote:
>
> Which bug (issue) was it?
>
> On Thursday, August 4, 2016 at 3:53:29 PM UTC+2, Tony Kelman wrote:
>>
>> 0.5.0-rc1 has been tagged and binaries are now available.
>>
>>
>> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
>>
>> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
>>
>> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5
>>
>> (append .asc to the linux .tar.gz links for gpg signatures)
>>
>>
>> There will be a RC2 next week. An especially nasty bug was introduced on 
>> master right before we branched for release-0.5 and I unfortunately missed 
>> it in my testing. I had a PkgEval run going but tagged before it was 
>> finished, in order to get binaries building. I won't be repeating that 
>> mistake next time.
>>
>>
>> On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:
>>>
>>> Hello everyone,
>>>
>>> You may have noticed 0.5.0-rc0 being tagged last week. The binaries are 
>>> now all ready and available for testing. This is a good point for package 
>>> developers to make their packages ready for 0.5, and for users to test 
>>> their codes on the new release.
>>>
>>>
>>> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc0-linux-arm.tar.gz
>>>
>>> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc0-linux-x86_64.tar.gz
>>>
>>> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc0-linux-i686.tar.gz
>>>
>>> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc0-osx10.7+.dmg
>>>
>>> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc0-win64.exe
>>>
>>> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc0-win32.exe
>>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.sha256
>>> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.md5
>>>
>>> We expect to have a new rc roughly every week until all the dust settles 
>>> and 0.5.0 is finally released. Follow the progress at:
>>>
>>> https://github.com/JuliaLang/julia/issues/17418
>>>
>>> -viral
>>>
>>>

[julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[Tony Kelman]

0.5.0-rc1 has been tagged and binaries are now available.

https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5

(append .asc to the linux .tar.gz links for gpg signatures)


There will be a RC2 next week. An especially nasty bug was introduced on 
master right before we branched for release-0.5 and I unfortunately missed 
it in my testing. I had a PkgEval run going but tagged before it was 
finished, in order to get binaries building. I won't be repeating that 
mistake next time.


On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:
>
> Hello everyone,
>
> You may have noticed 0.5.0-rc0 being tagged last week. The binaries are 
> now all ready and available for testing. This is a good point for package 
> developers to make their packages ready for 0.5, and for users to test 
> their codes on the new release.
>
>
> https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc0-linux-arm.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc0-linux-x86_64.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc0-linux-i686.tar.gz
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc0-osx10.7+.dmg
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc0-win64.exe
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc0-win32.exe
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.sha256
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.md5
>
> We expect to have a new rc roughly every week until all the dust settles 
> and 0.5.0 is finally released. Follow the progress at:
>
> https://github.com/JuliaLang/julia/issues/17418
>
> -viral
>
>

Re: [julia-users] Windows subsystem for Linux

[Tony Kelman]

Maybe. What are you running that hits a double free? Does it happen when 
run in julia-debug? What about under gdb?


On Thursday, August 4, 2016 at 2:16:58 AM UTC-7, Bill Hart wrote:
>
> Ok, I'll hold off making a ticket then. Tony, do you think the double free 
> and corruption with Julia 0.5.0 could be independent of Microsoft. I'm not 
> seeing that behaviour anywhere else. Do we have any tools that might help 
> track it down? Or is it just not worth it for now?
>
> Bill.
>
> On 4 August 2016 at 08:54, Tony Kelman > 
> wrote:
>
>> I don't think there's anything specific we can fix here, we have to wait 
>> for Microsoft to gradually fix the rest of the syscalls they haven't 
>> implemented all the way yet. Good to know this is available without having 
>> to opt in to the unstable test builds of Windows 10 now. Last I looked at 
>> it, the build performance was far better than compiling Julia from source 
>> in Cygwin or MSYS2, but not quite as good as Linux. I imagine it would be 
>> much slower if you build in a /mnt/c location (and according to David 
>> Anthoff, autotools in patchelf has some issues there, probably related to 
>> file timestamps), better to stay within the WSL /home/ filesystem. As long 
>> as you do that you can compile Julia from source as if you're on normal 
>> Ubuntu, but it won't pass all of the tests. Parallelism won't work until 
>> they fix getifaddrs for example.
>>
>>
>>
>> On Wednesday, August 3, 2016 at 9:59:22 AM UTC-7, Bill Hart wrote:
>>>
>>> I agree, it would be great to get it going.
>>>
>>> I'll open a ticket later on tonight or tomorrow. I'm not sure I can 
>>> contribute much more to it myself. I think the first thing to do might be 
>>> to contact the libuv people and ask them whether libuv is expected to run 
>>> on WSL. It may just be a waiting game, until Microsoft are able to 
>>> implement enough syscalls for them.
>>>
>>> Bill.
>>>
>>> On Wednesday, 3 August 2016 18:53:34 UTC+2, Stefan Karpinski wrote:
>>>>
>>>> Would be great to get this working. Maybe open an issue to track this?
>>>>
>>>> On Wednesday, August 3, 2016, 'Bill Hart' via julia-users <
>>>> julia...@googlegroups.com> wrote:
>>>>
>>>>> In fact, both the old and new versions of libuv seem to fail their 
>>>>> test suites on WSL. I imagine they tie into the system calls pretty 
>>>>> tightly 
>>>>> and Microsoft may not have implemented them all fully or correctly as of 
>>>>> the moment. Perhaps things will improve with the next release of WSL.
>>>>>
>>>>> Bill.
>>>>>
>>>>> On Wednesday, 3 August 2016 18:23:53 UTC+2, Bill Hart wrote:
>>>>>>
>>>>>> Julia seems to use an old version of libuv. People have noticed that 
>>>>>> libuv has problems on WSL. I don't know whether these have been fixed or 
>>>>>> not. I couldn't find any specific tickets for it. But perhaps the latest 
>>>>>> libuv works on WSL and maybe that points to a possible solution.
>>>>>>
>>>>>> Bill.
>>>>>>
>>>>>
>

Re: [julia-users] Windows subsystem for Linux

[Tony Kelman]

I don't think there's anything specific we can fix here, we have to wait 
for Microsoft to gradually fix the rest of the syscalls they haven't 
implemented all the way yet. Good to know this is available without having 
to opt in to the unstable test builds of Windows 10 now. Last I looked at 
it, the build performance was far better than compiling Julia from source 
in Cygwin or MSYS2, but not quite as good as Linux. I imagine it would be 
much slower if you build in a /mnt/c location (and according to David 
Anthoff, autotools in patchelf has some issues there, probably related to 
file timestamps), better to stay within the WSL /home/ filesystem. As long 
as you do that you can compile Julia from source as if you're on normal 
Ubuntu, but it won't pass all of the tests. Parallelism won't work until 
they fix getifaddrs for example.


On Wednesday, August 3, 2016 at 9:59:22 AM UTC-7, Bill Hart wrote:
>
> I agree, it would be great to get it going.
>
> I'll open a ticket later on tonight or tomorrow. I'm not sure I can 
> contribute much more to it myself. I think the first thing to do might be 
> to contact the libuv people and ask them whether libuv is expected to run 
> on WSL. It may just be a waiting game, until Microsoft are able to 
> implement enough syscalls for them.
>
> Bill.
>
> On Wednesday, 3 August 2016 18:53:34 UTC+2, Stefan Karpinski wrote:
>>
>> Would be great to get this working. Maybe open an issue to track this?
>>
>> On Wednesday, August 3, 2016, 'Bill Hart' via julia-users <
>> julia...@googlegroups.com> wrote:
>>
>>> In fact, both the old and new versions of libuv seem to fail their test 
>>> suites on WSL. I imagine they tie into the system calls pretty tightly and 
>>> Microsoft may not have implemented them all fully or correctly as of the 
>>> moment. Perhaps things will improve with the next release of WSL.
>>>
>>> Bill.
>>>
>>> On Wednesday, 3 August 2016 18:23:53 UTC+2, Bill Hart wrote:

 Julia seems to use an old version of libuv. People have noticed that 
 libuv has problems on WSL. I don't know whether these have been fixed or 
 not. I couldn't find any specific tickets for it. But perhaps the latest 
 libuv works on WSL and maybe that points to a possible solution.

 Bill.

>>>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Tony Kelman]

It's still on master for now to see if we can come up with a fix that 
doesn't require reverting, but it will be reverted on the just-created 
release-0.5 branch for now - see 
https://github.com/JuliaLang/julia/pull/17804


On Wednesday, August 3, 2016 at 11:29:54 PM UTC-7, Kevin Squire wrote:
>
>
> On Wed, Aug 3, 2016 at 8:35 PM, Kevin Squire  > wrote:
>
>> For completeness, PR #17389 was merged 
>> , and issue #17314 was 
>> closed .
>>
>
> ... and was just reverted, because it caused massive performance issues 
> .
>
>  
>
>>
>> Cheers,
>>Kevin
>>
>> On Mon, Aug 1, 2016 at 8:28 AM, Oliver Schulz > > wrote:
>>
>>> Thanks, Pablo. Uh, do you think that PR will make it into 0.5?
>>>
>>>
>>> On Monday, August 1, 2016 at 3:41:23 PM UTC+2, Pablo Zubieta wrote:

 This should work if https://github.com/JuliaLang/julia/pull/17389 gets 
 merged.

 On Monday, August 1, 2016 at 3:06:36 PM UTC+2, Oliver Schulz wrote:
>
> > Not before the bug is fixed and this is also orthogonal to loop 
> fusion. 
>
> Sure, I get that. But that means then that bug is fixed, things like 
> broadcasting with (e.g.) muladd will be possible again? That would be 
> wonderful!
>
>
>
> On Monday, August 1, 2016 at 2:47:44 PM UTC+2, Yichao Yu wrote:
>>
>> On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz 
>>  wrote: 
>> > So cases like 
>> > 
>> > broadcast((x,y,z)->..., A, B, C) 
>> > 
>> > can't be supported any longer? Darn. :-( I love the things you guys 
>> are 
>> > doing in regard to fusing operations, but that was a very, very 
>> useful thing 
>> > to have. Is there any other way to do this now? 
>>
>> Not before the bug is fixed and this is also orthogonal to loop 
>> fusion. 
>>
>> > 
>> > On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote: 
>> >> 
>> >> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz 
>> >>  wrote: 
>> >> > Hi, 
>> >> > 
>> >> > sorry if this is already covered somewhere - have the semantics 
>> of 
>> >> > broadcast 
>> >> > changed in Julia 0.5? 
>> >> 
>> >> Essentially https://github.com/JuliaLang/julia/issues/17314 
>> >> The promote_op basically assumes everything is a pure unary or 
>> binary 
>> >> operator. 
>> >> 
>> >> > 
>> >> > In 0.4, I can do 
>> >> > 
>> >> > broadcast(muladd, rand(5), rand(5), rand(5)) 
>> >> > 
>> >> > But in 0.5 (0.5.0-rc0+86), I get 
>> >> > 
>> >> > ERROR: MethodError: no method matching muladd(::Float64, 
>> ::Float64) 
>> >> > Closest candidates are: 
>> >> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247 
>> >> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177 
>> >> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at 
>> >> > promotion.jl:239 
>> >> >   ... 
>> >> > [...] 
>> >> > 
>> >> > 
>> >> > Is this a bug, or to be expected? 
>> >> > 
>> >> > Cheers, 
>> >> > 
>> >> > Oliver 
>> >> > 
>>
>
>>
>

[julia-users] Re: MUMPS server workaround?

[Tony Kelman]

Hey Sarah. So the download of Mumps when you build Ipopt actually comes 
from a ./get.Mumps bash script that's part of Ipopt's source code - see 
https://projects.coin-or.org/BuildTools/browser/ThirdParty/Mumps/stable/1.5/get.Mumps.

If it doesn't come back soon, we could potentially add a patch to Ipopt.jl 
that modifies that file and adds the location of a server that we use for 
caching various source downloads to deal with situations like this.


On Wednesday, August 3, 2016 at 8:52:05 PM UTC-7, Sarah Koehler wrote:
>
>  I have been trying to add Ipopt to Julia on a new computer (Ubuntu 
> 64-bit) today, and I am running into the issue of the MUMPS server being 
> down. Is it at all possible to tell Julia to download MUMPS from another 
> server such as ANL ? 
> It seems the server for MUMPS has been down for at least 20 minutes now. 
> Example error message below...
>
>
> --2016-08-03 17:37:07--  (try: 4)  
> http://mumps.enseeiht.fr/MUMPS_4.10.0.tar.gz
> Connecting to mumps.enseeiht.fr (mumps.enseeiht.fr)|147.127.176.144|:80... 
> connected.
> HTTP request sent, awaiting response... No data received.
> Retrying.
>
>
>

[julia-users] Re: Embedding julia in VC++ app - crash in jl_init()

[Tony Kelman]

Yes, we probably could. See 
https://github.com/JuliaLang/julia/issues/11419, opened by node-julia's 
author.


On Tuesday, August 2, 2016 at 7:46:13 PM UTC-7, Kit Adams wrote:
>
> Many thanks for these helpful pointers, which led me to this: 
> https://node-julia.readme.io/docs/the-windows-situation
>
> Linking against a libopenlibm.lib import library created manually from 
> libopenlibm.dll using dumpbin and lib fixed the crash.
>
> Also, in looking to link against libjulia-debug, I noticed the 
> lib/libjulia.dll.a and lib/libjulia-debug.dll.a import libraries supply 
> with the julia install.
> Linking against these works in VS2012 and saves having to manually create 
> an import library from libjulia.dll.
>
> I wonder if a libopenlibm.dll.a could be added to the lib folder in future 
> releases to ease linking to julia from MSVC?
>
> Thanks again,
> Kit
>
> On Wednesday, August 3, 2016 at 2:27:32 AM UTC+12, Tony Kelman wrote:
>>
>> Can you try building against libjulia-debug or running this in a 
>> debugger? You may need to statically link against openlibm.
>
>

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Tony Kelman]

This sounds like the issue people have been reporting at 
https://github.com/JuliaLang/PkgDev.jl/issues/48, though it's more likely a 
problem with base Julia.

On Tuesday, August 2, 2016 at 9:21:43 AM UTC-7, Daniel O'Malley wrote:
>
> OK, I tried again with the latest nightlies. Now Pkg.init("ssh://
> g...@github.com/JuliaLang/METADATA.jl.git") succeeds. However, I'm still 
> not able to add packages. Pkg.setprotocol!("ssh") does seem to work with 
> Pkg.add though:
>
> julia> Pkg.setprotocol!("ssh"); Pkg.add("ACME")
> INFO: Cloning cache of ACME from ssh://github.com/HSU-ANT/ACME.jl.git
> WARNING: The explicitly provided credentials were incompatible with the 
> server's supported authentication methods
> ERROR: Cannot clone ACME from ssh://github.com/HSU-ANT/ACME.jl.git. No 
> errors
>  in prefetch(::String, ::String, ::Array{String,1}) at ./pkg/cache.jl:56
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, 
> ::Set{String}) at ./pkg/entry.jl:512
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:476
>  in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, 
> ::Vararg{Base.Pkg.Types.VersionSet,N}) at ./pkg/entry.jl:30
>  in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at 
> ./task.jl:309
>  in sync_end() at ./task.jl:275
>  in macro expansion at ./task.jl:284 [inlined]
>  in add(::String, ::Base.Pkg.Types.VersionSet) at ./pkg/entry.jl:51
>  in 
> (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() at 
> ./pkg/dir.jl:31
>  in 
> cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, 
> ::String) at ./file.jl:59
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
> ::Vararg{Any,N}) at ./pkg/dir.jl:31
>  in add(::String) at ./pkg/pkg.jl:100
>
> On Monday, August 1, 2016 at 11:24:51 AM UTC-6, Tony Kelman wrote:
>>
>> I think Pkg.add should obey setprotocol!, it's likely a bug that Pkg.init 
>> doesn't. The extra colon after .com probably is malformed so isn't the 
>> first error correct? The second issue might be fixed by some authentication 
>> changes that Keno just merged a few minutes ago, there should be binaries 
>> that include that fix built in a few hours.
>>
>>
>> On Monday, August 1, 2016 at 8:31:44 AM UTC-7, Daniel O'Malley wrote:
>>>
>>> I tried the Pkg.init("ssh://...") a couple different ways, but neither 
>>> worked.
>>>
>>> Pkg.init("ssh://g...@github.com:/JuliaLang/METADATA.jl.git")
>>>
>>> gave GitError(Code:EINVALIDSPEC, Class:Net, Malformed URL 
>>> 'ssh://g...@github.com:/JuliaLang/METADATA.jl.git').
>>>
>>> Pkg.init("ssh://g...@github.com/JuliaLang/METADATA.jl.git")
>>>
>>> asked me about my ssh keys then resulted in an authentication 
>>> failure. If I were to get Pkg.init() working in this way, Pkg.add and other 
>>> Pkg functions would still have problems though, right?
>>>
>>> On Monday, August 1, 2016 at 9:09:22 AM UTC-6, Tony Kelman wrote:
>>>>
>>>> That could be considered a bug, Pkg.init should probably respect the 
>>>> Pkg.setprotocol! setting, at least when using the DEFAULT_META value. You 
>>>> should also be able to do Pkg.init("ssh://g...@github.com:/
>>>> JuliaLang/METADATA.jl.git") as a workaround to avoid having to go 
>>>> through command-line git.
>>>>
>>>>
>>>> On Monday, August 1, 2016 at 7:01:51 AM UTC-7, Daniel O'Malley wrote:
>>>>>
>>>>> Oh, sorry for the mixup. Doing a
>>>>>
>>>>> git clone ssh://g...@github.com:/JuliaLang/METADATA.jl.git
>>>>>
>>>>> from a shell succeeds. I haven't had success trying to change the 
>>>>> protocol with Pkg.setprotocol! though. Whether I do 
>>>>> Pkg.setprotocol!("ssh"), Pkg.setprotocol!("git"), or 
>>>>> Pkg.setprotocol!("notaprotocol"), Pkg.init() seems to always try to clone 
>>>>> via https.
>>>>>
>>>>> On Sunday, July 31, 2016 at 10:31:38 PM UTC-6, Tony Kelman wrote:
>>>>>>
>>>>>> No, I meant ssh:// o

[julia-users] Re: Error in installing Mongo package on Mac OS

[Tony Kelman]

Looks like this was reported at 
https://github.com/JuliaLang/Homebrew.jl/issues/139 - might want to click 
"subscribe" there or leave a comment saying you're also having the same 
issue, in case more information is needed to debug what's happening.

On Tuesday, August 2, 2016 at 7:24:51 AM UTC-7, Tony Kelman wrote:
>
> Homebrew might be using a lock file or something that has gotten in a 
> strange state. You might want to open an issue on github at 
> JuliaLang/Homebrew.jl and cc @staticfloat who is the primary author of that 
> package.

[julia-users] Embedding julia in VC++ app - crash in jl_init()

[Tony Kelman]

Can you try building against libjulia-debug or running this in a debugger? You 
may need to statically link against openlibm.

[julia-users] Re: Error in installing Mongo package on Mac OS

[Tony Kelman]

Homebrew might be using a lock file or something that has gotten in a strange 
state. You might want to open an issue on github at JuliaLang/Homebrew.jl and 
cc @staticfloat who is the primary author of that package.