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?
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?
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?
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
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,
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
What version of windows are you using?
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.
do you have the lapack dll opened by some other julia process?
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
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?
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.
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.
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.
Check the travis docs for the apt sources and packages addons to install newer
compiler versions from the Ubuntu toolchain ppa.
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.
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
A number of packages end up storing absolute paths in generated files. You'll
likely need to re-run Pkg.build().
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.
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.
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
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.
>
>
You may have to remove the git tag from your local clone of the package repo.
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
Yeah I didn't realize the readme was suggesting that either, sorry. We should
automate the complicated part on our side.
What does Pkg.status() say? What operating system are you using? What is git
status in METADATA and the package repo?
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
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
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
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
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.
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.
>
>
ath, 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下
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
"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
&g
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
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
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.
Misread. Go into metadata and run git status. Post the output.
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.
;
>
> 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 t
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
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
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
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
Better to use a different branch name, not metadata-v2
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
make 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 vers
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
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
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.
git tags that don't get registered in metadata should be fine. What were you
seeing happen?
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.
>
>
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.
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.
; if isfile(reqfile)
> lines = open(readlines, reqfile)
> println("#"^20)
> println(pkg)
> for line in lines
> print(line)
> end
> println("")
> end
> end
>
>
>
>
> On Tue
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
eler 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, Sept
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
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
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
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.
>
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
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,
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
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:
&g
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,
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
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.
Try https://github.com/simonbyrne/GenericSVD.jl ?
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 up
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.
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,
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
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
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
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
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 <to...@kelman.net
> > wrote:
>
>> Though we should t
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:
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
> 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
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
ompat 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,
parse 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 signi
ms 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...@go
> 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
/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:
>
> &g
Depends on the package, but it rarely hurts to ask.
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:
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:
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
lia 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 <to...@kelman.net >
> 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,
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:
>
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
> 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.
>
>
e.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 setprotoco
1 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.
Can you try building against libjulia-debug or running this in a debugger? You
may need to statically link against openlibm.
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.
1 - 100 of 839 matches
Mail list logo
