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:
> Hello Bill,
> Sorry to grap o
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
> temporarily in order to be able to
Wow, that's really awesome. Thanks for writing this!
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, digx
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'.
> Changes not staged for commit
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
> $ git status
> On branc
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 changes in the git
>> repos
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 wrote:
>
>
> Am Freitag, 2
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,
> Consider distributing windows_bui
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 can still cope with 32bit s
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 command
>> can and will fail si
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 futu
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
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 a
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 u
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 and installed the new one
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
.d
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 softwar
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 output, please
>
> On Tue, Oct 2
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 Pkg.dir() subdir Nemo))
> delete th
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
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") ?
>
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.
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 start Pkg.build("Nemo")
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
> WARNING: `@windows` is dep
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, Jeffrey
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 17:49, Tony Kelman wrote:
>
>> S
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 having problems r
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
I created [1] to make specific note of this issue.
Bill.
[1] https://github.com/JuliaLang/julia/issues/18084
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 appearing
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 a
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 now
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.
>
>
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 d
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:
https://github.com/wbhart/Nemo.
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?
We have a (time critical function) with the following prototype:
heapinsert!{N}(xs::Array{Tuple{NTuple{N, UInt}, heap_s}, 1}, exp::NTuple{N,
UInt}, x::heap_s)
However, one line of code in the implementation is allocating gigabytes of
memory, which is causing a massive performance deficit in ou
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
wrote:
> > Since they are
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 to
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 FixedSizeArrays or Stat
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 non-beta/Insder program, good to
It is implemented very efficiently,
>>>>>> based on tuples.
>>>>>>
>>>>>> Otherwise, to generate efficient code, you might have to make use of
>>>>>> "generated functions". These are similar to macros, but they know about
t they know about the
>>> types upon which they act, and thus know the value of `N`. This is a bit
>>> low-level, so I'd use this only if (a) there is not other package
>>> available, and (b) you have examined Julia's performance and found it
>>> lacking.
>
> 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:
>
>> This cod
ble, 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
&
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 wrote:
> And just t
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 enough?
>
> Base.:+{N}(
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 tuples).
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
&g
m.
>>
>> 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'
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
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
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.
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 0.
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.
Bill
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 in DifferentialEquatio
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 change
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 Nemo
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
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
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
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:
>
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.
p.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:
>>
>>cc
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
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),
cgl
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
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]
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 th
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)
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
abo
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, th
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 extend
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
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
haven'
In this case the library interface requires that the function does not
return.
On 4 May 2016 at 15:03, Yichao Yu wrote:
> On Wed, May 4, 2016 at 8:32 AM, 'Bill Hart' via julia-users
> wrote:
> > At the very least the warning should print correctly. Currently there is
>
Wed, May 4, 2016 at 8:20 AM, 'Bill Hart' via julia-users
> wrote:
> > Julia is now issuing warnings because functions do not return, e.g:
> >
> > function flint_abort()
> > error("Problem in the Flint-Subsystem")
> > end
> >
> >
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)?
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
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
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 bi
The third regression is:
6382116 Jameson Nash 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.
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% regress
n Wednesday, March 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 ov
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,
>>> --Tim
>>
>> --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 minu
te:
>
> 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
> f
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 understandin
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
li
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 wrote:
> Le mardi 22 mars 2016 à 08:37 -0700, 'Bill Hart' via
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
eval(:(Base.promote_rule(::Type{$par_type}
Maybe. But that's not the full problem. It does work in a module, just not
in the Nemo module. I've no idea what is different about the Nemo module
that makes it not work there.
Bill.
On 22 March 2016 at 23:53, Jeffrey Sarnoff
wrote:
> aside:
>would it help others to find this to have a new
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 integers_mod
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
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 ther
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 promote_t
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 m
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
Nemo.promote_rule_exists(Nemo.Poly
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}}
V
1 - 100 of 158 matches
Mail list logo