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 wrote: > > > Am Montag, 31. Oktober 2016 14:27:26 UTC+1 schrieb Bill Hart: >> >> It's probably due to the fact that you've made some

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

It's probably due to the fact that you've made some changes in the git repository. You can do git stash to temporarily store the changes you made, then do Pkg.update() and then if you still need the changes, do git stash apply. Bill. On 31 October 2016 at 13:58, digxx

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

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 maintain it a bit more carefully. Bill. On 28 October 2016 at 12:34, Jeffrey Sarnoff wrote: > Bill, >

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

It could well be libflint-13.dll is the problem. It's just a copy of the other flint dll, so you can make that any way you like. Just copy the file and rename the copy. As for the dll DependencyWalker claims is missing, I don't know what it does and it might not be relevant. We are mainly looking

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

Actually, there is one more thing you could do. Download DependencyWalker [1] and run it on libarb.dll in place where it currently is in your Nemo/local/lib directory. It's bound to complain a lot, and there will be lots of yellow flags. But what we are looking for is missing dependencies that we

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

And you are not running it inside the Cygwin shell now? If not, then I honestly don't know why this is happening. As Jeffrey says, it doesn't happen on his Windows. And no, you don't require the arb source code on Windows. There does seem to be a problem on some versions of Windows whereby the

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 wrote: > Thanks! > > On 29 September 2016 at

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

Thanks! On 29 September 2016 at 17:49, Tony Kelman 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, Bill Hart wrote: >> >> We are

[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

Ah, ok. Thanks for clarifying this. We probably have the optimum for now. There are other things we can do in our application to get better performance anyway, so we'll focus on those now. Thanks for all the help! Bill. On 12 August 2016 at 13:46, Kristoffer Carlsson

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 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. >> > > [You mean the subsystem and bash is no

Re: [julia-users] Adding tuples

and subtracting, >>>>>> and presumably also multiplication. It is implemented very efficiently, >>>>>> based on tuples. >>>>>> >>>>>> Otherwise, to generate efficient code, you might have to make use of >>>>>> "g

Re: [julia-users] Adding tuples

ce 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] 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

omorrow. 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 >&g

Re: [julia-users] Windows subsystem for Linux

t;> >> 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...@googleg

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

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.

[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

Alternatively, you can remove the lines in Nemo/deps/build.jl that invoke git. They aren't actually needed to run Nemo. They just download the source code for the various modules, which are prebuilt anyway on Windows. But I can't guarantee it'll work. We haven't worked on supporting rc0 yet.

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

Hi, the way the type hierarchy has changed is only relevant if you have code written against an old version of Nemo and want to switch it to the new version. Probably the easiest way to see what's different is to look at AbstractTypes.jl and compare with the older version you have. We also

[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)

sed 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 an issue in the following snippet of code which >> is in __init__ in our package: >>

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)

I've checked that the problem we were having doesn't happen with Julia 0.4.5 on Travis. In fact, it also doesn't happen on another one of our systems with Julia 0.4.5, so at this stage we have no idea what the problem is. It may be totally unrelated to the problem you are having. Bill. On 31 May

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

>> various things and don't know precisely when they were switched on or off. >> >> Bill. >> >> On Wednesday, 23 March 2016 14:54:22 UTC+1, Tim Holy wrote: >>> >>> If you can git-bisect the change, it would be a huge help. >>> >>> Best, >>>

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

>> >> 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 start running. It's close to 2 min

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

Bill Hart' via julia-users a > écrit : > > 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 > > > >

[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

Definitely doesn't work that way. If I check both orderings the code to fix (5) works. You might be thinking of promote, not promote_rule. That's not a useful function though because it tries to convert values to a given type, which is basically useless for things like a conversion to

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

OK I solved (5). Apparently promote_rule needs to be defined for both orderings of its arguments if one wants it to work with arguments in either order. I can't think of any reason why one wouldn't expect a promote_rule to come up with a common type to which both can be promoted, regardless of

[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

Thanks, that looks like an elegant solution if we can make it work. Unfortunately it doesn't. I added the following function to Nemo: function promote_rule_exists{T1, T2}(::Type{T1}, ::Type{T2}) return Union{} != Base.promote_rule(T1, T2) end But when I do

[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?

I can only partially bisect. The regression happens between: 75fc9104ee24 (more recent) and dc6b0de80550 (older) But few of the intervening commits actually build, so I can't refine it further. There's something like 40 commits in that range. Bill. On 16 March 2016 at 18:28, Kristoffer

  1   2   >