Re: [julia-users] Re: Nemo AcbField error

It's just telling you that you modified the file. If you don't want it to happen, save the file somewhere (so you don't lose the changes you made) and do git checkout windows_build.txt and it should stop happening. Bill. On 16 November 2016 at 20:10, digxx wrote: >

Re: [julia-users] Re: Nemo AcbField error

Yes, all packages have the same issue if you edit one of the files without committing the changes. Bill. On 4 November 2016 at 22:51, digxx wrote: > Ok, but why do I need to do that??? > I mean other packages also dont need git to put the changes to the side >

[julia-users] Re: ANN: Highlights.jl

Wow, that's really awesome. Thanks for writing this!

Re: [julia-users] Re: Nemo AcbField error

Sure. It's just taking all the changes that have been made and stashing them to one side. This means the Git repository is then "clean" and can be updated. Git stash apply takes the changes that had been stashed and reapplies them to the updated repository. Bill. On 2 November 2016 at 22:01,

Re: [julia-users] Re: Nemo AcbField error

That looks better. So now the git stash and git stash apply trick should work. Bill. On 31 October 2016 at 21:25, digxx wrote: > Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master) > $ git status > On branch master > Your branch is up-to-date with 'origin/master'. >

Re: [julia-users] Re: Nemo AcbField error

Oh yeah, if you use Cygwin Git it screws up all the line endings in the files, causing the Git repository to think every file needs committing. Use native Windows Git instead. Bill. On 31 October 2016 at 17:35, digxx wrote: > Diger@Diger-PC /cygdrive/d/julia/v0.5/nemo

Re: [julia-users] Re: Nemo AcbField error

Ok, it was just a guess. At least do git status in .julia/v0.5/Nemo to see what isn't clean. Bill. On 31 October 2016 at 15:07, digxx <diger_d...@hotmail.com> wrote: > > > Am Montag, 31. Oktober 2016 14:27:26 UTC+1 schrieb Bill Hart: >> >> It's probably due to the

Re: [julia-users] Re: Nemo AcbField error

com> wrote: > > > Am Freitag, 28. Oktober 2016 13:31:13 UTC+2 schrieb Bill Hart: >> >> We'll consider changing it. It's mainly supposed to be for us developers >> so we can build the binaries, but if people want to actually use it, I >> guess we should maint

Re: [julia-users] Re: Nemo AcbField error

H=/home/user/mpir-2.7.2/.libs:$PATH > LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure > --with-gmp-include=/home/user/mpir-2.7.2 > --with-gmp-lib=/home/user/mpir-2.7.2/.libs > --host=x86_64-pc-mingw > cd Omingw-x86_64-pc > make gp > cd ..

Re: [julia-users] Re: Nemo AcbField error

64 bit Windows will run 32 bit Windows binaries, yes. Of course we recommend the 64 bit ones. On 28 October 2016 at 10:52, digxx wrote: > Yes but when I do not manually change i686 and ABI=32 to the x64 it is >> running the 32bit version, right? >> You mean windows 64

Re: [julia-users] Re: Nemo AcbField error

On 27 October 2016 at 23:33, digxx wrote: > > > Am Donnerstag, 27. Oktober 2016 23:00:48 UTC+2 schrieb Tommy Hofmann: >> >> There is a reason I asked to check for two libflint files three days ago. >> I saw this error with the missing libflint-13.dll before. The ln

Re: [julia-users] Re: Nemo AcbField error

Yes, we'll eventually get rid of the warnings. Technically we only fully support Julia-0.4 at the moment. However, Nemo is known to work with Julia-0.5 with some warnings. Thanks for persisting with it. I'm glad it is working for you now. We'll try to figure out how to stop this happening in

Re: [julia-users] Re: Nemo AcbField error

s -static-libgcc -shared >> -Wl,--export-all-symbols >> make -j >> cd .. >> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz >> tar -xvf pari-2.7.6.tar.gz >> cd pari-2.7.6 >> export PATH=/home/user/mpir-2.7.2/.libs:$PATH >> LD

Re: [julia-users] Re: Nemo AcbField error

are responsible for. Bill. [1] http://www.dependencywalker.com/ On 27 October 2016 at 02:04, Bill Hart <goodwillh...@googlemail.com> wrote: > The only thing I can think of to suggest is try it again from scratch in > Julia-0.4 so we can rule out the dlls being corrupted on our websi

Re: [julia-users] Re: Nemo AcbField error

The only thing I can think of to suggest is try it again from scratch in Julia-0.4 so we can rule out the dlls being corrupted on our website somehow. I can't think what else could be wrong, unless something else changed in Julia itself on Windows, between versions 0.4 and 0.5. Jeffrey, are you

Re: [julia-users] Re: Nemo AcbField error

Well, I'm mystified. What version of Julia are you using? And what version of Windows? Is it 32 or 64 bit? Bill. On 26 October 2016 at 22:40, digxx wrote: > So, first of all it is (unfortunately) still not working... > What I did so far is this: > I removed my old GIT

Re: [julia-users] Re: Nemo AcbField error

:17, digxx <diger_d...@hotmail.com> wrote: > > > Am Mittwoch, 26. Oktober 2016 20:51:48 UTC+2 schrieb Bill Hart: >> >> I mean as an environment variable, specifically PATH. Alternatively you >> can just remove the lines from Nemo/deps/build.jl that run git.

Re: [julia-users] Re: Nemo AcbField error

I mean as an environment variable, specifically PATH. Alternatively you can just remove the lines from Nemo/deps/build.jl that run git. The source code is not needed on Windows. We only download it for you to keep in the spirit of the LGPL license, i.e. to supply you the source code for the

Re: [julia-users] Re: Nemo AcbField error

This is probably because Git is not in your path. We still haven't switched to libgit, which means the build script for Nemo still relies on Git being available on your machine. Bill. On 26 October 2016 at 01:43, Jeffrey Sarnoff wrote: > send me all the messages

Re: [julia-users] Re: Nemo AcbField error

We don't support Cygwin. The Nemo binaries are native Windows binaries. I was unaware there was a Cygwin version of Julia. Bill. On 24 October 2016 at 19:48, Jeffrey Sarnoff wrote: > I tried this on windows, it worked: > delete the directory Nemo (found with

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

I can confirm that the Julia nightly is now working on our Gentoo systems. Will there be a Julia-0.5 binary provided with the same fix? Bill. On Thursday, 29 September 2016 22:50:35 UTC+2, Tony Kelman wrote: > > Okay, the buildbot that was down was running centos which is failing some > of the

Re: [julia-users] Re: Nemo AcbField error

Well it downloads some source as well, but it isn't used. On 23 October 2016 at 21:59, digxx wrote: > or does it try to download the source here upon Pkg.build("Nemo") ? >

Re: [julia-users] Re: Nemo AcbField error

No, on Windows it doesn't build from source, but downloads binaries. After the downloading is done, that's it. It should be ready to use. If you still have the same problem, maybe we need to rebuild one of the binaries for you. I'll have to talk to Tommy and see what he knows about this problem.

Re: [julia-users] Re: Nemo AcbField error

Ah, you are on Windows. That explains why it doesn't go on any further. I will have to ask Tommy why he thought this was a Pari problem. I don't see it from the error you reported. Bill. On 23 October 2016 at 21:28, digxx wrote: > No it does not go on...When I manually

Re: [julia-users] Re: Nemo AcbField error

The above shows that everything downloaded ok, I think. Did it not then go on and rebuild everything? Bill. On 23 October 2016 at 21:11, digxx wrote: > It does not work either. When I run Pkg.build("Nemo") it starts > > julia> Pkg.build("Nemo") > INFO: Building Nemo >

[julia-users] Re: Nemo AcbField error

This is probably something we could fix easily enough. By the way, feel free to send support queries for Nemo to the Google list nemo-devel if you prefer. I believe Jeffrey is also signed up there, but we don't all notice the posts here. Bill. On Monday, 17 October 2016 22:43:07 UTC+2,

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

Do you mean the current nightly, or one to come? The current nightly seems to have the same issue. Also, we have ssl installed, so this doesn't seem to be a workaround. Bill. On 29 September 2016 at 17:52, Bill Hart <goodwillh...@googlemail.com> wrote: > Thanks! > > On 29 Septe

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

Thanks! On 29 September 2016 at 17:49, Tony Kelman <t...@kelman.net> wrote: > 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, B

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

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

Re: [julia-users] Help needed with excessive memory allocation for Tuples

I created [1] to make specific note of this issue. Bill. [1] https://github.com/JuliaLang/julia/issues/18084

Re: [julia-users] Help needed with excessive memory allocation for Tuples

On Wednesday, 17 August 2016 20:22:56 UTC+2, Kristoffer Carlsson wrote: > > See pr 8134. I dont think you have any worse cache locality than with your > original tuple. You are right. I just have more memory usage. The heap will in fact have better cache locality. I'll just have exp

Re: [julia-users] How to Manipulate each character in of a string using a for loop in Julia ?

Since strings are immutable in Julia, and immutable means you can't change them, you can't change the characters in a string whilst keeping them of type string. If you want to be able to change the characters directly, you need to use something other than a string, e.g. an array of characters

Re: [julia-users] Help needed with excessive memory allocation for Tuples

I basically extended the heap_s struct to also include the exp field. This uses twice the memory, but gets rid of the massive number of heap allocations. Unfortunately I lose the cache efficiency of the original solution, so it's still about 20-50% slower than it should be. It'll have to do for

Re: [julia-users] Help needed with excessive memory allocation for Tuples

Wowsers! That's one hell of a serious issue. On 17 August 2016 at 18:33, Kristoffer Carlsson wrote: > Immutables and tuples that contain references to heap allocated objects > are currently themselves allocated on the heap. There is an issue about it. > >

Re: [julia-users] Help needed with excessive memory allocation for Tuples

Wait, I understand why heap_s would be allocated on the heap. But why would a tuple involving a heap_s need to be allocated on the heap assuming the heap_s already exists? The tuple should just have the NTuple and one pointer (to a heap_s) at the machine level. This is clearly the problem, but I

Re: [julia-users] Help needed with excessive memory allocation for Tuples

It's very, very hard to produce working code that illustrates a problem when working on a very large system like ours. There's nearly 1000 lines of code just to set up the data! If you want to take a look, it's here, though I'm not sure how enlightening it will be:

Re: [julia-users] Help needed with excessive memory allocation for Tuples

N = 1 in the case I'm profiling/timing. It's typically < 10 in applications, usually much less. Bil. On 17 August 2016 at 17:50, Kristoffer Carlsson wrote: > What is N typically?

Re: [julia-users] Adding tuples

August 12, 2016 at 1:22:44 PM UTC+2, Bill Hart wrote: >> >> Awesome, I didn't realise this. I will definitely give them a try (and >> possibly eventually report back). It very likely makes more sense for our >> application for us to use these than an immutable tuple.

Re: [julia-users] Adding tuples

Awesome, I didn't realise this. I will definitely give them a try (and possibly eventually report back). It very likely makes more sense for our application for us to use these than an immutable tuple. Since they are mutable (I assume), we can pass them as an argument to a function to be written

Re: [julia-users] Adding tuples

We will have many of them, i.e. billions. Are FixedSizedArrays or StaticArrays individually allocated, e.g. if we have an array of them? Or would a large array of them be allocated once? Bill. On 12 August 2016 at 07:48, Andy Ferris wrote: > Bill, you might also consider

Re: [julia-users] Re: Windows subsystem for Linux

On 11 August 2016 at 10:47, Páll Haraldsson <pall.haralds...@gmail.com> wrote: > On Wednesday, August 3, 2016 at 3:07:55 PM UTC, Bill Hart wrote: >> >> I got the Windows 10 anniversary update and turned on the new Windows >> subsystem for Linux. >> > > [Yo

Re: [julia-users] Adding tuples

com> wrote: > relative to the same thing without the Val > > > On Wednesday, August 10, 2016 at 2:45:06 PM UTC-4, Jeffrey Sarnoff wrote: >> >> that slows it down by a factor of 5 >> >> On Wednesday, August 10, 2016 at 2:37:25 PM UTC-4, Bill Hart wrote: >>

Re: [julia-users] Adding tuples

; cb = CartesianIndex(b) > return (ca+cb).I > end > > > for me, with 100 values it ran ~60% faster, and with 1000 values much much > faster than > ntuple(i -> a[i] + b[i], N) > > > > On Wednesday, August 10, 2016 at 11:06:46 AM UTC-4, Bill Hart wrote

Re: [julia-users] Adding tuples

a[i] + b[i], Val{N}) > > should be slightly faster and should not allocate unlike > > Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N) > > > On Wed, Aug 10, 2016 at 8:36 PM, 'Bill Hart' via julia-users < > julia-users@googlegroups.com> wrote:

Re: [julia-users] Adding tuples

other package > available, and (b) you have examined Julia's performance and found it > lacking. > > I would avoid overloading operators for `NTuple`, and instead us a new > immutable type, since overloading operations for Julia's tuples can have > unintended side effects. > > -erik

Re: [julia-users] Re: Adding tuples

Oh, I didn't know about that either. This is also what I'm looking for. When I looked through tuple.jl for inspiration and through the documentation I just didn't see these (probably my fault for not looking carefully enough). Bill. On 10 August 2016 at 16:53, Pablo Zubieta

Re: [julia-users] Re: Adding tuples

map is incredibly slow and not at all useful for something like addition. However the first example looks like what I am looking for, depending on how it is implemented. Thanks. Bill. On 10 August 2016 at 16:45, Pablo Zubieta wrote: > Does something like this seems good

[julia-users] Adding tuples

Does anyone know an efficient way to add NTuples in Julia? I can do it using recursive functions, but for various reasons this is not efficient in my context. I really miss something like tuple(a[i] + b[i] for i in 1:N) to create the resulting tuple all in one go (here a and b would be

Re: [julia-users] Windows subsystem for Linux

ut 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 a

Re: [julia-users] Windows subsystem for Linux

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 >> con

Re: [julia-users] Windows subsystem for Linux

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-use

[julia-users] Re: Windows subsystem for Linux

. 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 li

[julia-users] Re: Windows subsystem for Linux

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.

[julia-users] Windows subsystem for Linux

I got the Windows 10 anniversary update and turned on the new Windows subsystem for Linux. The Julia binaries from the website load, but unfortunately don't fully work. I had hoped Julia might just work as I had heard many large programs just work, but alas, not yet. I tried both 0.4.6 and

Re: [julia-users] Re: [ANN] Nemo 0.5 released

. Bill. On 31 July 2016 at 18:32, Bill Hart <goodwillh...@googlemail.com> wrote: > It's because git has been removed on Windows in rc0. We don't support it > yet. You should be ok if you use Julia 0.4.6. > > Bill. > > On 31 July 2016 at 17:57, Chris Rackauckas <rackd...

Re: [julia-users] Re: [ANN] Nemo 0.5 released

It's because git has been removed on Windows in rc0. We don't support it yet. You should be ok if you use Julia 0.4.6. Bill. On 31 July 2016 at 17:57, Chris Rackauckas wrote: > Hey, > I am really interested in trying Nemo since I want to use the ArbFloats > and ArbReals

Re: [julia-users] Re: [ANN] Nemo 0.5 released

, I heard there was supposed to be a complex root isolation method? > > > On Wednesday, July 27, 2016 at 9:07:44 AM UTC+12, Bill Hart wrote: >> >> Hi all, >> >> We are pleased to release version 0.5 of Nemo, our computer algebra >> package written in Julia. &

[julia-users] [ANN] Nemo 0.5 released

Hi all, We are pleased to release version 0.5 of Nemo, our computer algebra package written in Julia. Instructions on how to get Nemo are on our website: http://nemocas.org/downloads.html Note that we have moved our repository, so existing users may need to reinstall. Documentation for

Re: [julia-users] ReadOnlyMemoryError() on Windows 64

It turns out that the improperly initialised struct was a coincidence and unrelated to the ReadOnlyMemoryError() we were getting on Windows. We have tracked the issue down, and it was very subtle. Basically the dll we built for MPIR (our GMP drop-in replacement) was being built incorrectly. It

Re: [julia-users] ReadOnlyMemoryError() on Windows 64

in our code (not properly initialising a struct being passed to C). This is almost certainly what was causing the issue on Windows. So I think the problem is likely solved. Bill. On Sunday, 24 July 2016 23:35:42 UTC+2, Yichao Yu wrote: > > On Sun, Jul 24, 2016 at 5:22 PM, 'Bill Hart' via

[julia-users] ReadOnlyMemoryError() on Windows 64

I built the dlls we make use of in our Nemo package a slightly odd way, but everything worked, all tests passed. I decided not to be lazy and built the dlls the correct way, and all of a sudden I get a ReadOnlyMemoryError() whilst running our test code. This is with either Julia 0.4.0 or 0.4.6

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

Well, I thought that when you link against libgmp normally, it doesn't care that the filename is libgmp-16.dll. I thought the linker just took care of it for you, So I was surprised by this behaviour. I might just be confused though. On Friday, 22 July 2016 22:30:50 UTC+2, Tony Kelman wrote: >

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

I found the issue. The dll is called libgmp-16.dll. But Julia expects the full name of the dll to be provided, i.e. libgmp-16, not just libgmp. This seems a bit fragile to me. Bill.

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

The errors are precisely the same if I invoke Julia with --inline=no. Bill. On 22 July 2016 at 20:25, Bill Hart <goodwillh...@googlemail.com> wrote: > What's totally bizarre about this, apart from the lack of traceback > information, is that this is precisely the same as the code u

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

What's totally bizarre about this, apart from the lack of traceback information, is that this is precisely the same as the code used in Julia itself in gmp.jl. Bill. On 22 July 2016 at 20:09, 'Bill Hart' via julia-users < julia-users@googlegroups.com> wrote: > I've narrowed it down to

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

I've narrowed it down to an issue in the following snippet of code which is in __init__ in our package: ccall((:__gmp_set_memory_functions, libgmp), Void, (Ptr{Void},Ptr{Void},Ptr{Void}), cglobal(:jl_gc_counted_malloc), cglobal(:jl_gc_counted_realloc_with_old_size),

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

I think there is a access violation occurring in one of the dlls we are loading in __init__. However, these are precisely the same dlls we used in the old version of Nemo, so I'm quite puzzled how they are causing an access violation just because we are using a later version of Nemo. I'll have

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

Here are some other things I tried: 1) Run Julia as administrator : no change 2) turn off precompilation : still doesn't work, error message below [2] That's the entire error message. There's no useful diagnostic information to suggest what might have gone wrong at all. Bill. [2]

[julia-users] Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

I just tried to run the latest (master) version of our Nemo package on Windows 64 using Julia 0.4.6 and after many ambiguity warnings (which are harmless) it bombs out with the message below [1]. What we have tried: 1) Building the old version of Nemo with Julia 0.4.6 : works OK 2) Building

Re: [julia-users] Re: Extending functions in Base (or another module)

You are a life saver. This is *precisely* what we need. Thank you for solving a very difficult problem for us. We were really pulling our hair out after searching for a solution. julia> module Nemo import Base: det abstract MatElem function det(a::MatElem)

[julia-users] Re: Extending functions in Base (or another module)

Another possibility: introduce a special "extends" syntax to Julia, e.g. module Hecke type SpecialMat <: Nemo.MatElem end function det(a::SpecialMat) if blah # do whatever else Nemo.det end end extends det Nemo.det # tells Julia to somehow treat the det implementation

[julia-users] Re: Extending functions in Base (or another module)

By the way, here are some potential things that could solve this for us: 1) Allow individual methods to be callable, as in Julia 0.4 (so long as we can look the methods up at "compile time" in a module and assign them to a const in the module so that they can be called). As far as we can see,

[julia-users] Extending functions in Base (or another module)

We have hit an issue that we can't seem to find a workaround for. Our only working workaround is no longer supported by Julia 0.5. The issue We implement determinant for various kinds of matrix types in Nemo and Hecke (two computer algebra/number theory packages). To do this, we

Re: [julia-users] Re: Double free or corruption (out)

2016 at 13:25, Bill Hart <goodwillh...@googlemail.com> wrote: > We are also suddenly getting crashes with 2.4.5. when running our (Nemo) > test suite. It says that some memory allocation is failing due to invalid > next size. I suspect there is a bug that wasn't there until the

Re: [julia-users] Re: Double free or corruption (out)

We are also suddenly getting crashes with 2.4.5. when running our (Nemo) test suite. It says that some memory allocation is failing due to invalid next size. I suspect there is a bug that wasn't there until the last few days, since we were passing just fine on Travis. Though at this stage, I

Re: [julia-users] Warning cfunction does not return

In this case the library interface requires that the function does not return. On 4 May 2016 at 15:03, Yichao Yu <yyc1...@gmail.com> wrote: > On Wed, May 4, 2016 at 8:32 AM, 'Bill Hart' via julia-users > <julia-users@googlegroups.com> wrote: > > At the very least

Re: [julia-users] Warning cfunction does not return

com> wrote: > On Wed, May 4, 2016 at 8:20 AM, 'Bill Hart' via julia-users > <julia-users@googlegroups.com> wrote: > > Julia is now issuing warnings because functions do not return, e.g: > > > > function flint_abort() > > error("Problem in the Flint-Subsy

[julia-users] Warning cfunction does not return

Julia is now issuing warnings because functions do not return, e.g: function flint_abort() error("Problem in the Flint-Subsystem") end What is the standard way of making Julia accept this as a valid function (it is not meant to return)?

[julia-users] Re: Int or Int64

Int is either Int32 or Int64, depending on the machine. Int64 does still seem to be defined on a 32 bit machine. In fact, even Int128 is defined. But of course it is going to have to emulate processor instructions to do 64 bit arithmetic unless the machine actually has such instructions. So it

Re: [julia-users] Test code taking forever to start

I did a little bit more bisecting to try and find the most recent regression, but I'm not sure if I nailed it or not. All the data is now summarised in the ticket here: https://github.com/JuliaLang/julia/issues/15615

Re: [julia-users] Test code taking forever to start

Rather than trying to nail down the remaining regressions, I think I am just going to give the data I've collected, which illustrates a problem, namely that in a very short space there can be massive improvements, immediately followed by massive regressions. This essentially violates the git

Re: [julia-users] Test code taking forever to start

The third regression is: 6382116 Jameson Nash <...@gmail.com> implement recursive type-inference It's about a 25% regression. There are some other much smaller regressions (~7%) before that which I skipped over. Still trying to track down a potential fourth regression. Bill.

Re: [julia-users] Test code taking forever to start

I'm sorry, please ignore that merge commit. I think that git bisect screwed up due to the fact that there are in fact a couple of major regressions in the range I was bisecting. The first of these is at the following commit: 8f4238a do type-inference using a work queue It's about a 35%

Re: [julia-users] Test code taking forever to start

rch 23, 2016 04:34:25 PM 'Bill Hart' via julia-users > wrote: > > On Thursday, 24 March 2016 00:33:04 UTC+1, Bill Hart wrote: > > > It seems there may have been two regressions. The first regression > with a > > > slowdown factor of just over 2 seems to be:

Re: [julia-users] Test code taking forever to start

On Thursday, 24 March 2016 00:33:04 UTC+1, Bill Hart wrote: > > It seems there may have been two regressions. The first regression with a > slowdown factor of just over 2 seems to be: > > 639621859863609c5f3abbc2ed75c675695b3693 is the first bad

Re: [julia-users] Test code taking forever to start

4650 M test I will try to find time to find the second regression, which occurs between 1bfabbb and 1bfabbb I believe. Bill. On Wednesday, 23 March 2016 15:23:05 UTC+1, Bill Hart wrote: > > I'll see if it is possible. Currently our code does not work at all with > large chunks of th

Re: [julia-users] Test code taking forever to start

: > > If you can git-bisect the change, it would be a huge help. > > Best, > --Tim > > On Wednesday, March 23, 2016 06:18:23 AM 'Bill Hart' via julia-users > wrote: > > In very recent Julia-0.5-dev the test code in our Nemo module takes > forever > > to

[julia-users] Re: dispatch on type of tuple from ...

The following seems to work, but I'm not sure whether it was what you wanted: import Base.getindex type Foo{T <: Tuple} end getindex{T}(f::Foo{Tuple{T}}, index::T...) = 42 Foo{Tuple{Int}}()[9] Bill. On Wednesday, 23 March 2016 14:38:20 UTC+1, Tamas Papp wrote: > > Hi, > > My

[julia-users] Test code taking forever to start

In very recent Julia-0.5-dev the test code in our Nemo module takes forever to start running. It's close to 2 minutes. This compares with about 15s with older Julia-0.5-dev, say 3 months ago before the LLVM switchover. Does anyone know why there is this massive performance regression. Is it

Re: [julia-users] Problems with in, == and Tuples of types

Thanks for the suggestion. Perhaps this will allow me to finally work around this issue. I will file a ticket as suggested as soon as I find time. Thanks again. Bill. On 23 March 2016 at 10:11, Milan Bouchet-Valat <nalimi...@club.fr> wrote: > Le mardi 22 mars 2016 à 08:37 -0700, '

[julia-users] Re: Problems knowing when a promote_rule exists, and

So here is an example of how broken this is. I have the following code: println(par_type, " ", T2, " ", Base.promote_rule(par_type, T2), " ", Base.promote_rule(par_type, T2) != par_type) if Base.promote_rule(par_type, T2) != par_type

Re: [julia-users] Re: Problems with in, == and Tuples of types

to be how it works! > As I recall there was a meetup where JeffB explains that promote_rule > always never cares about the order of its arguments and internals generate > lookups for both orderings. > > > On Tuesday, March 22, 2016 at 6:26:51 PM UTC-4, Bill Hart wrote: >&g

[julia-users] Re: Problems with in, == and Tuples of types

of the order of its arguments. But maybe such an application exists. So maybe this is actually reasonable behaviour. Bill. On Tuesday, 22 March 2016 22:58:29 UTC+1, Bill Hart wrote: > > Another problem: > > 5) We have been using promote_type to find out the type returned by a >

[julia-users] Re: Problems with in, == and Tuples of types

Another problem: 5) We have been using promote_type to find out the type returned by a promote_rule we defined, which has mostly worked fine, oddly enough. But now that I realise that's not what promote_type is for, I switched to using promote_rule instead, since it just returns Union{} if

[julia-users] Re: Problems with in, == and Tuples of types

Apparently, promote_type doesn't return the type you get from a promote_rule, but the smallest type which can contain both types, which apparently doesn't have to be a concrete type or even something you get from a promote_rule! That's really confusingly named! That means we are using

[julia-users] Re: Problems with in, == and Tuples of types

This is proving impossible to work around. Firstly, I can't seem to produce a minimal example of the behaviour I just mentioned. If the promote_rule_exists function is placed in the Nemo module itself it returns a different value to if I define the function at the REPL. But if I place it in a

[julia-users] Re: Problems with in, == and Tuples of types

checks whether a specific promote rule exists: > > promotionExists{T1, T2}( ::Type{T1}, ::Type{T2} ) = (Union{} != > promote_rule(T1,T2)) > > > > On Tuesday, March 22, 2016 at 11:37:56 AM UTC-4, Bill Hart wrote: >> >> I'm having trouble understanding the following be

[julia-users] Problems with in, == and Tuples of types

I'm having trouble understanding the following behaviour in 0.5.0-dev+3171. I wonder if someone can tell me what I'm doing wrong. module Mymod type mytype end end sig_table = [x.sig for x in methods(Base.promote_rule)] V = Tuple{typeof(Base.promote_rule),Type{Mymod.mytype},Type{Int64}}

[julia-users] Performance regression with latest master?

We are seeing a performance regression with a factor of 1.5 or 2.0 (depending on machine) for the following simple C interface code between 0.4.2 and today's master (not sure where the problem initially showed up, but within the last 50 days): import Base: + typealias ZZ Array{UInt, 1}

Re: [julia-users] Re: Performance regression with latest master?

gt; julia -e 'include("test_script.jl")' > > and then do a bisect run ./bisect_runner.sh after having marked a good > and bad commit. > > > > On Wednesday, March 16, 2016 at 5:25:11 PM UTC+1, Bill Hart wrote: >> >> We are seeing a performance regression with

  1   2   3   >