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

['Bill Hart' via julia-users]

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 out that thread again.
> I just did that Pkg.update thingy again, mainly git stash - git stash
> apply...In the end after I git stash apply it tells me
>
> On branch master
> Your branch is up-to-date with 'origin/master'.
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   windows_build.txt
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> What is that git add/commit good for ? Do I have to do it or why is
> telling me that?
>

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

['Bill Hart' via julia-users]

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 update itsself?! So what is the specific
> issue here?
>
>

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

['Bill Hart' via julia-users]

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

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

['Bill Hart' via julia-users]

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, digxx  wrote:

> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git config --global user.name "Diger"
>
> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git stash
>
> *** Please tell me who you are.
>
> Run
>
>   git config --global user.email "y...@example.com"
>   git config --global user.name "Your Name"
>
> to set your account's default identity.
> Omit --global to set the identity only in this repository.
>
> fatal: unable to auto-detect email address (got 'Diger@Diger-PC.(none)')
> Cannot save the current index state
>
> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git config --global user.email "diger..."
>
> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git stash
> Saved working directory and index state WIP on master: cc4ae5d Merge pull
> request #94 from thofma/update_version
> HEAD is now at cc4ae5d Merge pull request #94 from thofma/update_version
>
> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git stash apply
> On branch master
> Your branch is up-to-date with 'origin/master'.
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   windows_build.txt
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $
>
>
>
> Maybe just to update you. This is what I did. For whatever reason (which
> I'm not aware of) it seemed to work now...
> So I did git stash
> then:
> julia> Pkg.update()
> INFO: Updating METADATA...
> INFO: Updating Nemo master...
> INFO: Computing changes...
> INFO: No packages to install, update or remove
>
> and then git stash apply. If you dont mind would you tell me what is
> happening in the background?
>
>

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

['Bill Hart' via julia-users]

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:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   windows_build.txt
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
>

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

['Bill Hart' via julia-users]

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 branch master
> Your branch is up-to-date with 'origin/master'.
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   .gitignore
> modified:   .travis.yml
> modified:   LICENSE.md
> modified:   README.md
> modified:   REQUIRE
> modified:   appveyor.yml
> modified:   benchmarks/bernoulli_polynomials.jl
> modified:   benchmarks/charpoly_integers.jl
> modified:   benchmarks/det_commutative_ring.jl
> modified:   benchmarks/det_field.jl
> modified:   benchmarks/det_polynomials.jl
> modified:   benchmarks/fateman.jl
> modified:   benchmarks/minpoly_finite_field.jl
> modified:   benchmarks/minpoly_gcd_domain.jl
> modified:   benchmarks/minpoly_integers.jl
> modified:   benchmarks/pearce.jl
> modified:   benchmarks/polynomials_number_field.jl
> modified:   benchmarks/resultant.jl
> modified:   benchmarks/runbenchmarks.jl
> modified:   benchmarks/solve_polynomials.jl
> modified:   deps/build.jl
> modified:   deps/patch-alloc-2.7.4
> modified:   doc/about.md
> modified:   doc/build.jl
> modified:   doc/build/acb.md
> modified:   doc/build/arb.md
> modified:   doc/build/classgroup.md
> modified:   doc/build/finitefield.md
> modified:   doc/build/fraction.md
> modified:   doc/build/integer.md
> modified:   doc/build/matrix.md
> modified:   doc/build/maximalorder.md
> modified:   doc/build/numberfield.md
> modified:   doc/build/padic.md
> modified:   doc/build/perm.md
> modified:   doc/build/polynomial.md
> modified:   doc/build/rational.md
> modified:   doc/build/residue.md
> modified:   doc/build/series.md
> modified:   doc/constructors.md
> modified:   doc/index.md
> modified:   doc/mathjaxhelper.js
> modified:   doc/mkdocs.yml
> modified:   doc/src/acb.md
> modified:   doc/src/arb.md
> modified:   doc/src/classgroup.md
> modified:   doc/src/finitefield.md
> modified:   doc/src/fraction.md
> modified:   doc/src/integer.md
> modified:   doc/src/matrix.md
> modified:   doc/src/maximalorder.md
> modified:   doc/src/numberfield.md
> modified:   doc/src/padic.md
> modified:   doc/src/perm.md
> modified:   doc/src/polynomial.md
> modified:   doc/src/rational.md
> modified:   doc/src/residue.md
> modified:   doc/src/series.md
> modified:   doc/types.md
> modified:   src/AbstractTypes.jl
> modified:   src/Factor.jl
> modified:   src/Groups.jl
> modified:   src/Nemo.jl
> modified:   src/Rings.jl
> modified:   src/ambiguities.jl
> modified:   src/antic/AnticTypes.jl
> modified:   src/antic/nf_elem.jl
> modified:   src/arb/ArbTypes.jl
> modified:   src/arb/acb.jl
> modified:   src/arb/acb_mat.jl
> modified:   src/arb/acb_poly.jl
> modified:   src/arb/arb.jl
> modified:   src/arb/arb_mat.jl
> modified:   src/arb/arb_poly.jl
> modified:   src/flint/FlintTypes.jl
> modified:   src/flint/fmpq.jl
> modified:   src/flint/fmpq_mat.jl
> modified:   src/flint/fmpq_poly.jl
> modified:   src/flint/fmpq_rel_series.jl
> modified:   src/flint/fmpz.jl
> modified:   src/flint/fmpz_mat.jl
> modified:   src/flint/fmpz_mod_poly.jl
> modified:   src/flint/fmpz_mod_rel_series.jl
> modified:   src/flint/fmpz_poly.jl
> modified:   src/flint/fmpz_rel_series.jl
> modified:   src/flint/fq.jl
> modified:   src/flint/fq_nmod.jl
> modified:   src/flint/fq_nmod_poly.jl
> modified:   src/flint/fq_nmod_rel_series.jl
> modified:   src/flint/fq_poly.jl
> modified:   src/flint/fq_rel_series.jl
> modified:   src/flint/nmod_mat.jl
> modified:   src/flint/nmod_poly.jl
> modified:   src/flint/padic.jl
> modified:   src/flint/perm.jl
> modified:   src/generic/Fraction.jl
> modified:   src/generic/GenericTypes.jl
> modified:   src/generic/Matrix.jl
> modified:   src/generic/Poly.jl
> modified:   src/generic/RelSeries.jl
> modified:   src/generic/Residue.jl
> modified:   src/pari/PariFactor.jl
> modified:   

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

['Bill Hart' via julia-users]

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
>> 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.
>>
>
> hm...what?
> If I do git stash in cygwin I get:
>
>  Diger@Diger-PC ~
> $ git stash
> fatal: Not a git repository (or any of the parent directories): .git
>
> What specific changes are u refering to ?
>
>

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

['Bill Hart' via julia-users]

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, 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 maintain it a bit more carefully.
>>
>> Bill.
>>
>
> BTW, when trying to Pkg.update() it now tells me:
> julia> Pkg.update()
> INFO: Updating METADATA...
> WARNING: Package Nemo: skipping update (dirty)...
> INFO: Computing changes...
> INFO: No packages to install, update or remove
>
>

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

['Bill Hart' via julia-users]

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_build.txt ready to use with 64-bit machines
> and giving the changes to be made for 32-bit machines in comments.  That
> reverses the current orientation, and fits more of the likely user base.  I
> think that change gives you this:
>
>
> Note that windows_build.txt is preset for 32-bit Windows;
> for 64-bit machines, windows_build.txt should be this:
>
> # This is set for use with 64-bit Windows installations
> #
> #   To use this with  32-bit Windows installations,
> #   replace x86_64 with i686 throughout
> #   replace ABI=64 with ABI=32
>
>
> wget http://mpir.org/mpir-2.7.2.tar.bz2
> tar -xvf mpir-2.7.2.tar.bz2
> cd mpir-2.7.2
> ./configure --enable-shared --disable-static --enable-gmpcompat
> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
> make -j
> cd ..
> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
> tar -xvf mpfr-3.1.4.tar.bz2
> cd mpfr-3.1.4
> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared
> --disable-static
> make -j
> cd ..
> git clone https://github.com/wbhart/flint2
> https://github.com/wbhart/antic
> cd flint2
> ./configure --enable-shared --disable-static --with-mpir=/home/user/mpir-2.7.2
> --with-mpfr=/home/user/mpfr-3.1.4 --extensions=/home/user/antic
> # edit Makefile
> # in CLFAGS replace -ansi -pedantic with -std=c99
> # add -mtune=core2 -march=core2 to CFLAGS
> # add -I/home/User/flint2 to INCS
> # ensure EXTRA_SHARED_FLAGS contains -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
> 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 ../..
>
>
>
>
> On Friday, October 28, 2016 at 4:54:06 AM UTC-4, Bill Hart wrote:
>>
>> 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 stuff?

>>>
>>>
>>> I mean changing in the windows_build.txt
>>> By Pkg.build("Nemo") I do not run any executable, right?
>>>
>>
>>

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

['Bill Hart' via julia-users]

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 stuff?
>>
>
>
> I mean changing in the windows_build.txt
> By Pkg.build("Nemo") I do not run any executable, right?
>

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

['Bill Hart' via julia-users]

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 silently for various reasons.
>
>
> Maybe just to clarify, coz I found that weird too.
> Back then I ran Julia in cygwin (and I just tested again to see) becoz the
> file libflint-13.dll was present back then.
> When I start Julia in cygwin (I only tried via julia -p 4 - btw how do I
> start multiple processes in windows directly when I just have the icon?
>

You have to right click on it and edit it's properties.


> add -p 4 in the shortcut options??) and build Nemo after cloning it does
> create libflint-13.dll
>

However it is just 1kb and I didnt know (back then) it had to be an exact
> copy of libflint.dll
>

Ah, Cygwin must have created a symlink. Unfortunately these don't work on
Windows natively.


>

> When I run Julia terminal directly libflint-13.dll is not created at all.
>

That is odd, and we'll have to look into that.


>
> I wonder though now is why it doesnt really matter whether I build for 32
> Windows namley API=32 and i686 or for windows 64 API=64 and x86_64.
> Both seem to work, is that intended?
>

Both should work. If you use a 64 bit Julia executable it sould build the
64 bit version. Otherwise it should build the 32 bit version.

Bill.

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

['Bill Hart' via julia-users]

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 future, so you don't
have to go through this again!

Bill.

On 27 October 2016 at 21:39, digxx  wrote:

>
>
> Am Donnerstag, 27. Oktober 2016 21:25:54 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> You are home free!  Try arbfield(1) twice ..
>>
>
> Yes I know the warning is gone I'm just wondering why it always shows up
> the first time...
>
>
> home free? in terms of homedir() or what you mean?
>

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

['Bill Hart' via julia-users]

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 for dlls in the
left hand pane that it says are missing that appear related to gcc,
pthreads, arb, flint, gmp, mpfr, pari, arb, msys, etc. Anything that looks
like an MS dll can probably be ignored.

Bill.

On 27 October 2016 at 18:57, digxx  wrote:

> Actually:
> libflint-13.dll  14,156 KB
> is missing for me
>
> also is .git\
> under Nemo
>
>
> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> With 64-bit Win7, in my directory for Julia packages
>>
>> under Nemo:
>> .git\
>> benchmarks\
>> deps\
>> doc\
>> local\
>> src\
>> test\
>> .gitignore
>> .travis.yml
>> appveyor.yml
>> LICENSE.md
>> README.md
>> REQUIRE
>> todo.txt
>> windows_build.txt
>>
>> in deps:
>> antic\
>> arb\
>> flint2\
>> build.jl
>> mpfr-3.1.3.tar.bz2
>> mpir-2.7.2.tar.bz2
>> pari-2.7.4.tar.gz
>> patch-alloc-2.7.4
>>
>>
>> under local:
>> lib\
>>
>> in lib:
>> libarb.dll   22,350 KB
>> libflint.dll 14,156 KB
>> libflint-13.dll  14,156 KB
>> libpari.dll   6,067 KB
>> libgmp-16.dll   673 KB
>> libmpfr-4.dll   451 KB
>> libwinpthread-1.dll  84 KB
>>
>>
>>
>>
>> Note that windows_build.txt is preset for 32-bit Windows;
>> for 64-bit machines, windows_build.txt should be this:
>>
>> # start of file
>> # For Windows 64
>>
>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>> tar -xvf mpir-2.7.2.tar.bz2
>> cd mpir-2.7.2
>> ./configure --enable-shared --disable-static --enable-gmpcompat
>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>> make -j
>> cd ..
>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>> tar -xvf mpfr-3.1.4.tar.bz2
>> cd mpfr-3.1.4
>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared
>> --disable-static
>> make -j
>> cd ..
>> git clone https://github.com/wbhart/flint2
>> https://github.com/wbhart/antic
>> cd flint2
>> ./configure --enable-shared --disable-static
>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4
>> --extensions=/home/user/antic
>> # edit Makefile
>> # in CLFAGS replace -ansi -pedantic with -std=c99
>> # add -mtune=core2 -march=core2 to CFLAGS
>> # add -I/home/User/flint2 to INCS
>> # ensure EXTRA_SHARED_FLAGS contains -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
>> 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 ../..
>>
>> # For Windows 32:
>>
>> # replace x86_64 with i686 throughout
>> # replace ABI=64 with ABI=32
>>
>> # end of file
>>
>>
>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>>
>>> 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 are responsible for.
>>>
>>> Bill.
>>>
>>> [1] http://www.dependencywalker.com/
>>>
>>>
>>> On 27 October 2016 at 02:04, Bill Hart  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 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 using 64 bit Windows with Julia 0.5?

 Bill.

 On 26 October 2016 at 23:02, digxx  wrote:

> It's weird coz in julia 0.4.x it was running without any problems...
>


>>>

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

['Bill Hart' via julia-users]

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 are responsible for.

Bill.

[1] http://www.dependencywalker.com/


On 27 October 2016 at 02:04, Bill Hart  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 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 using 64 bit Windows with Julia 0.5?
>
> Bill.
>
> On 26 October 2016 at 23:02, digxx  wrote:
>
>> It's weird coz in julia 0.4.x it was running without any problems...
>>
>
>

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

['Bill Hart' via julia-users]

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 using 64 bit Windows with Julia 0.5?

Bill.

On 26 October 2016 at 23:02, digxx  wrote:

> It's weird coz in julia 0.4.x it was running without any problems...
>

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

['Bill Hart' via julia-users]

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
> I then removed Nemo within Julia and subsequently manually removed every
> nemo stuff I could find in folder v0.5
> I then started Julia (@Bill: This time I'm running Julia terminal directly
> not via cygwin since Jeffrey asked to do it)
> I ran: Pkg.update()
> Restarting Julia
> then: Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
> Restarting Julia
> Pkg.build("Nemo")
> Now since it finally found GIT it downloaded the antic, flint2 and arb
> stuff and builded Nemo.
> Quitting Julia and replacing the files Bill linked above by the ones
> already present in the folder Nemo/local/lib (actually libgmp-10.dll was
> missing before)
> Starting Julia and "using Nemo" with all the warnings
> restarting Julia and "using Nemo" again with no warnings...
> but then again:
>
>
> julia> using Nemo
>
> Welcome to Nemo version 0.5.1
>
> Nemo comes with absolutely no warranty whatsoever
>
>
> julia> rr=ArbField(64)
> Real Field with 64 bits of precision and error bounds
>
> julia> rr(1)
> ERROR: error compiling ArbField: error compiling Type: could not load
> library "libarb"
> RN
>
> julia>
>

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

['Bill Hart' via julia-users]

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
.dll files are cached by the operating system, so that when you download
them, it just gets them from cache and not from our website. I thought we
fixed that issue, but maybe your Windows is particularly resistant to our
fix.

Try deleting all the .dll files in Nemo/local/lib and replacing them with
the following files

http://nemocas.org/binaries/w64-libflint.dll
http://nemocas.org/binaries/w64-libgmp-10.dll
http://nemocas.org/binaries/w64-libgmp-16.dll
http://nemocas.org/binaries/w64-libmpfr-4.dll
http://nemocas.org/binaries/w64-libpari.dll
http://nemocas.org/binaries/w64-libarb.dll
http://nemocas.org/binaries/w64-libwinpthread-1.dll

Note that you will have to rename them all manually. You can see what they
should be renamed to in build.jl. Of course I'm assuming you have 64 bit
Windows. Otherwise you should replace all the w64's with w32 in the above.

Bill.

On 26 October 2016 at 21:17, digxx  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. 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
>> software you are using.
>>
>> Bill.
>>
>
> Hey,
> So I just removed the lines:
>
> #=
> try
>   run(`git clone https://github.com/wbhart/antic.git`
> )
> catch
>   cd(joinpath("$wdir", "antic"))
>   run(`git pull`)
> end
>
> cd(wdir)
>
> # install FLINT
> try
>   run(`git clone https://github.com/wbhart/flint2.git`
> )
> catch
>   cd(joinpath("$wdir", "flint2"))
>   run(`git pull`)
> end
> =#
>
> #=
> try
>   run(`git clone https://github.com/fredrik-johansson/arb.git`
> )
> catch
>   cd(joinpath("$wdir", "arb"))
>   run(`git pull`)
>   cd(wdir)
> end
> =#
>
> So u mean these are not needed for the installation of Nemo on windows???
> But the last one runs some arb sth...Dont I need it?
> The building works now and I can run Nemo but I ask about the arb sth bcoz
> now on the new Julia version I again get the error:
>
> julia> using Nemo
>
> Welcome to Nemo version 0.5.1
>
> Nemo comes with absolutely no warranty whatsoever
>
>
> julia> r=ArbField(64)
> Real Field with 64 bits of precision and error bounds
>
> julia> r(1)
> ERROR: error compiling ArbField: error compiling Type: could not load
> library "libarb"
> t
>
>

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

['Bill Hart' via julia-users]

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 software
you are using.

Bill.

On 26 October 2016 at 20:40, digxx  wrote:

> I do have Gitbash installed for some reason, but I never used it and it's
> in c:\programs
> Sorry for that stupid question but u mean put the folder with git-cmd.exe
> or git-bash.exe as an environment variable
>

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

['Bill Hart' via julia-users]

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 25, 2016 at 7:41 PM, Jeffrey Sarnoff <
> jeffrey.sarn...@gmail.com> wrote:
>
>> What happens if you restart that Julia from the windows menu (if that
>> does not launch cygwin terminal)
>> and  do >Pkg.build("Nemo") again?
>>
>> On Tue, Oct 25, 2016 at 7:37 PM, digxx  wrote:
>>
>>> Sry but I followed precisely ur steps i.e.:
>>> I installed a completely new version in D:\Julia\Julia-0.5.0 and added
>>> an environment variable JULIA_PKGDIR within D:\Julia because I didn't like
>>> the default one.
>>> I then initialized by Pkg.init()
>>> I ran Pkg.update()  (prob not needed here coz its new)
>>> I ran: Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
>>> I exitted and restarted julia
>>> I ran: Pkg.build("Nemo") and stumbled across:
>>>
>>> julia> Pkg.build("Nemo")
>>> INFO: Building Nemo
>>> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>>>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>>>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>>>  in include_from_node1(::String) at .\loading.jl:488
>>>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 2
>>> times)
>>>  in cd(::##2#4, ::String) at .\file.jl:48
>>>  in (::##1#3)(::IOStream) at .\none:13
>>>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>>>  in eval(::Module, ::Any) at .\boot.jl:234
>>>  in process_options(::Base.JLOptions) at .\client.jl:239
>>>  in _start() at .\client.jl:318
>>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting
>>> on line 1
>>> 
>>> ===[ ERROR: Nemo
>>> ]===
>>> 
>>>
>>> LoadError: chdir D:\Julia\v0.5\Nemo\deps\antic: no such file or
>>> directory (ENOENT)
>>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting
>>> on line 121
>>>
>>> 
>>> 
>>> 
>>> =
>>>
>>> 
>>> ==[ BUILD ERRORS
>>> ]===
>>> 
>>>
>>> WARNING: Nemo had build errors.
>>>
>>>  - packages with build errors remain installed in D:\Julia\v0.5
>>>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>>>  - build a single package by running its `deps/build.jl` script
>>>
>>> 
>>> 
>>> 
>>> =
>>>
>>>
>>
>

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

['Bill Hart' via julia-users]

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 the corresponding directory METADATA/Nemo (Pkg.dir("METADATA")
> subdir Nemo)
> and if they exist, .cache/Nemo, METADATA/.cache/Nemo
> restart Julia, do Pkg.update()
> > Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
> when its done, quit and restart Julia
> > Pkg.build("Nemo")
> when its done, restart Julia
> > using Nemo
> # a bunch of warnings, then Welcome to Nemo ...
> restart Julia
> > using  Nemo
> Welcome to Nemo ... (without the warnings)
>
>
> On Monday, October 24, 2016 at 1:24:30 PM UTC-4, digxx wrote:
>>
>> Hey,
>> Thx for ur reply. I tried both deleting all the files and run Pkg.build
>> again...
>> It however did not work as are all the files present too :-(
>> Julia in cygwin is correct...
>>
>

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

['Bill Hart' via julia-users]

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 tests due to this very change. We need to come up with a good fix 
> for the certificates location lookup issue on non-debian-based 
> distributions (https://github.com/JuliaLang/julia/issues/18693) before 
> new nightlies will get published.
>
>
> On Thursday, September 29, 2016 at 12:11:18 PM UTC-7, Tony Kelman wrote:
>>
>> nighties were a few days behind, I needed to log in and reconnect a few 
>> of the buildbots. Check in a few hours if the nightlies are dated with 
>> commits from today.
>
>

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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.

Bill.

On 23 October 2016 at 21:48, digxx  wrote:

> Maybe I should have pointed out that I'm on windows...
>

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

['Bill Hart' via julia-users]

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") in the same
>> session I get:
>>
> julia> Pkg.build("Nemo")
> INFO: Building Nemo
> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>  in include_from_node1(::String) at .\loading.jl:488
>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 2
> times)
>  in cd(::##2#4, ::String) at .\file.jl:48
>  in (::##1#3)(::IOStream) at .\none:13
>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>  in eval(::Module, ::Any) at .\boot.jl:234
>  in process_options(::Base.JLOptions) at .\client.jl:239
>  in _start() at .\client.jl:318
> while loading C:\cygwin64\home\Diger\.julia\v0.5\Nemo\deps\build.jl, in
> expression starting on line 1
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>   0Warning: Failed to create the file
> Warning: C:\cygwin64\home\Diger\.julia\v0.5\Nemo\local\lib\
> libwinpthread-1.dll:
> Warning:  Device or resource busy
> curl: (23) Failed writing body (0 != 1181)
> 
> [
> ERROR: Nemo ]===
> =
>
> LoadError: automatic download failed (error: 2147500036):
> http://nemocas.org/binaries/w64-libwinpthread-1.dll
> while loading C:\cygwin64\home\Diger\.julia\v0.5\Nemo\deps\build.jl, in
> expression starting on line 36
>
> 
> 
> 
> 
> ===
>
> 
> ===[
> BUILD ERRORS ]===
> =
>
> WARNING: Nemo had build errors.
>
>  - packages with build errors remain installed in
> C:\cygwin64\home\Diger\.julia\v0.5
>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>  - build a single package by running its `deps/build.jl` script
>
> 
> 
> 
> 
> ===
>
> When I start a new session in Julia I start with the previous download
> stuff first and then eventually end up with the error above (after manually
> starting Pkg.build("Nemo") again)
>

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

['Bill Hart' via julia-users]

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 deprecated, use `@static is_windows()` instead
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>  in include_from_node1(::String) at .\loading.jl:488
>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 2
> times)
>  in cd(::##2#4, ::String) at .\file.jl:48
>  in (::##1#3)(::IOStream) at .\none:13
>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>  in eval(::Module, ::Any) at .\boot.jl:234
>  in process_options(::Base.JLOptions) at .\client.jl:239
>  in _start() at .\client.jl:318
> while loading C:\cygwin64\home\Diger\.julia\v0.5\Nemo\deps\build.jl, in
> expression starting on line 1
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 85504  100 855040 0  72326  0  0:00:01  0:00:01 --:--:--
> 72707
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100  672k  100  672k0 0   266k  0  0:00:02  0:00:02 --:--:--
>  267k
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100  450k  100  450k0 0   192k  0  0:00:02  0:00:02 --:--:--
>  192k
> fatal: destination path 'antic' already exists and is not an empty
> directory.
> Already up-to-date.
> fatal: destination path 'flint2' already exists and is not an empty
> directory.
> Already up-to-date.
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 13.8M  100 13.8M0 0  1052k  0  0:00:13  0:00:13 --:--:--
> 1345k
> fatal: destination path 'arb' already exists and is not an empty directory.
> Already up-to-date.
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 21.8M  100 21.8M0 0   894k  0  0:00:24  0:00:24 --:--:--
>  926k
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 6066k  100 6066k0 0   825k  0  0:00:07  0:00:07 --:--:--
> 1198k
>
>
> every time I run Pkg.build("Nemo")
> So apparently it is never properly build.
> I'm using Julia 0.5.0 and Pkg.update("Nemo") also ran through the newest
> version.
> However the Pkg.build problem remains...
>

[julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

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 Sarnoff wrote:
>
> The exported logic requires both the real and the imaginary parts  be 
> given.
>
> ComplexField = AcbField(64)
> complexValue = ComplexField(1, 0)
>
>
>
>
>
> On Monday, October 17, 2016 at 8:08:40 AM UTC-4, digxx wrote:
>>
>> push...
>
>

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

['Bill Hart' via julia-users]

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

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

['Bill Hart' via julia-users]

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

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

['Bill Hart' via julia-users]

We are having problems running the Generic 64 bit x86 Linux binary on 
Gentoo. It appears to be looking for some Kerberos library. Is there 
something we need to install?

The German message below just says, "Cannot open the shared-object-file: 
file or directory not found"

fatal: error thrown and no exception handler available.
Base.InitError(mod=:LibGit2, error=ErrorException("could not load library 
"libgit2"
libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei oder 
Verzeichnis nicht gefunden"))
rec_backtrace at 
/home/centos/buildbot/slave/package_tarball64/build/src/stackwalk.c:84
record_backtrace at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:232
jl_throw at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:550
jl_errorf at 
/home/centos/buildbot/slave/package_tarball64/build/src/builtins.c:78
jl_dlerror at 
/home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:69 
[inlined]
jl_load_dynamic_library_ at 
/home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:209
jl_get_library at 
/home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:152
jl_load_and_lookup at 
/home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:163
unknown function (ip: 0x7f6334fe9346)
__init__ at ./libgit2/libgit2.jl:538
unknown function (ip: 0x7f6334fe9b58)
jl_call_method_internal at 
/home/centos/buildbot/slave/package_tarball64/build/src/julia_internal.h:189 
[inlined]
jl_apply_generic at 
/home/centos/buildbot/slave/package_tarball64/build/src/gf.c:1942
jl_apply at 
/home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392 
[inlined]
jl_module_run_initializer at 
/home/centos/buildbot/slave/package_tarball64/build/src/toplevel.c:83
_julia_init at 
/home/centos/buildbot/slave/package_tarball64/build/src/init.c:742
julia_init at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:283
main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.c:231
__libc_start_main at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x4013fc)

Bill.

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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 in every object in the 
"chained" heap, rather than per chain.

I was trying hard to keep memory usage down, since some of the large 
benchmarks we want to do will barely fit on the machine, otherwise.

I looked at the PR, and it seems relevant, but I'm not sure it directly 
deals with this issue.

The problem with immutables indeed seems to be that you can't make 
immutables that contain pointers stack allocated since they contain 
pointers. But the standard way of dealing with this is to have the GC 
conservatively scan the stack. Jeff seems to make this point.

On the other hand, he seems to suggest that such a mechanism already exists 
but earlier seems to suggest that you should only stack allocate something 
if it doesn't contain pointers. So I'm totally confused after reading that.

I suppose if the compiler is clever enough to elide the creation of tuples 
that are being written directly into heap allocated resources (such as 
arrays), then Jeff can get his way and problems such as the one I have wont 
occur. But I'm very sceptical that this would be a complete solution.

Bill.

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

['Bill Hart' via julia-users]

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 as explained 
above.

Here is an example using byte arrays:

a = b"abcd"

for i in 1:length(a) # <--- note I corrected an error in your original code
a[i] += 1
end

println(String(a))

Technically, the right way to deal with immutable objects is to just create 
a new one every time you want to change something. The compiler can then 
recognise that all you are doing is changing a string and it can decide to 
actually do the mutation behind the scenes automatically. On the other 
hand, I wouldn't necessarily expect this to be the case with Julia 
currently. 

As an example:

a = "abcd"

for i in 1:length(a)
   a ="$(a[1:i-1])$(a[i] + 1)$(a[i + 1:end])"
end

println(a)

Here I've used "string interpolation" and "ranges" to generate a new string 
from parts of the existing one.

I'm not suggesting this is a good way of doing it. I'm just demonstrating 
that this is a "functional" way of doing things, using immutables instead 
of the mutable strings we are used to in C.

Bill.

On Wednesday, 17 August 2016 19:52:47 UTC+2, Rishabh Raghunath wrote:
>
> Thank you for the immense support from this amazing group !!.. I am a 
> beginner in Julia and I am more familiar with the C language.. Now.. I 
> understand strings are immutable..
> I am actually learning Julia for use in a programming contest and love the 
> experience so far..
> There are often questions that require you to manipulate the characters 
> comprising the string. Its easy to do in C as strings are nothing but an 
> array of Characters and you can play around with it.. C is the online 
> language I know well.. So I do not know about other languages..
> But How do I such manipulation with the individual characters of a string 
> while still maintaining the type as a string.. You said its considered a 
> bad Idea to take this route...
> Please tell me how I should go about manipulating characters in Julia the 
> right way while the type is string..?
> For Example: Writing a Encrypting program requires me to modify the 
> characters in the string..
> I tried using Character Array but .. It prints out as separate characters 
> instead of a string
>
> On Wed, Aug 17, 2016 at 10:48 PM, g  
> wrote:
>
>> Isn't it a red herring to say that strings lack setindex because they are 
>> immutable? I think strings don't have setindex! because it is considered to 
>> be a bad API choice, at least partially because you can't do O(1) indexing 
>> for many string encodings.
>>
>> I can easily define a setindex! method* that does what the OP is 
>> expecting, so how can this be related to strings being immutable? 
>>
>> *julia> **Base.setindex!(s::ASCIIString, v,i) = s.data[i]=v*
>>
>> *setindex! (generic function with 58 methods)*
>>
>> *julia> **a="abc"*
>>
>> *"abc"*
>>
>> *julia> **a[1]='7';a*
>>
>> *"7bc"*
>>
>> *julia> **a[1]+=1;a*
>>
>> *"8bc"*
>>
>> *This works in 0.4, and I'm lead to believe this is considered a bad idea.
>>
>> On Wednesday, August 17, 2016 at 12:40:36 AM UTC-6, Jacob Quinn wrote:
>>>
>>> Strings are immutable (similar to other languages). There are several 
>>> different ways to get what you want, but I tend to utilize IOBuffer a lot:
>>>
>>> a = "abcd"
>>> io = IOBuffer()
>>>
>>> for char in a
>>> write(io, a + 1)
>>> end
>>>
>>> println(takebuf_string(io))
>>>
>>> -Jacob
>>>
>>> On Wed, Aug 17, 2016 at 12:30 AM, Rishabh Raghunath >> > wrote:
>>>

 Hello fellow Julia Users!!

 How do you manipulate the individual characters comprising a string in 
 Julia using a for loop ?
 For example:
 ###

 a = "abcd"

   for i in length(a)
a[i]+=1
  end

 print(a)

 
  I am expecting to get my EXPECTED OUTPUT as" bcde  "

  BUT I get the following error:  
 ##

  ERROR: MethodError: `setindex!` has no method matching 
 setindex!(::ASCIIString, ::Char, ::Int64)
  [inlined code] from ./none:2
  in anonymous at ./no file:4294967295

 ##
 I also tried using:

 for i in eachindex(a) instead of the for loop in the above program .. 
 And I get the same error..

 Please tell me what i should do to get my desired output ..
 Please respond ASAP..
 Thanks..

>>>
>>>
>

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

['Bill Hart' via julia-users]

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.

I've been looking around for a specific ticket for this tuple/immutable
issue, but haven't managed to find one.

I see "temporary tuple elision" on Jeff's compiler optimization tracker
marked as done, but I don't know what the details are. There's a bunch of
tickets around the place, mostly about fixed sized arrays and so on, which
seem to depend on efficient tuples. But this is all stuff that went up
before the tupocalypse (which I thought made tuples efficient).

I'd really like to make sure this issue has a ticket somewhere since it is
so fundamental. Do you by chance know where you saw this already? If not,
I'll make another ticket for it so it can be tracked explicitly.

The best I can find is [1]. But I don't see any links to open tickets
there. There is a pull request, but it's not totally clear to me what this
fixes (though it might explain why this hasn't been fixed already). I don't
understand how the Julia GC can work at all without marking roots in the
stack, so I'm not sure how to understand that PR.

Bill.

[1] https://groups.google.com/forum/#!topic/julia-users/LthfABeDN50



On 17 August 2016 at 19:11, Kristoffer Carlsson 
wrote:

> Just make a new type instead of the tuple and directly set the fields of
> it?

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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 don't understand why this would happen
(or how to work around it).

Bill.

On 17 August 2016 at 18:21, Kristoffer Carlsson 
wrote:

> Unless heap_s is a bitstype then the tuple will be allocated on the heap.
> But you are saying it is getting allocated twice?
>

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

['Bill Hart' via julia-users]

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.jl/blob/mpoly/src/generic/MPoly.jl

Specifically the issue is at lines 578 and 584.

To run this in Nemo, you would need to check out the mpoly branch, build
Nemo and use the following lines of code:

using Nemo

R, x, y, z, t = PolynomialRing(ZZ, ["x", "y", "z", "t"])

f = 1 + x + y + z + t
p = f^20;

q = Nemo.mul(p, p + 1);

It is this final line of code that in turn invokes Nemo.mul_johnson which
in turn invokes heapinsert!.

I am quite certain the line of code that I gave is at issue here. Instead
of simply writing the tuple directly into the array, it first allocates a
tuple on the heap, then copies that into the array. That obviously
shouldn't happen.

Bill.



On 17 August 2016 at 17:54, Kristoffer Carlsson 
wrote:

> As always, it is very helpful if there is some code that is actually
> runnable in the post that contains the problem. It is easier to run Julia
> code in Julia than in your brain :)

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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 mutable (I assume)
>
> They are not. They are basically wrappers around a tuple with conveniently
> defined methods on them to make them act like vectors / matrices. You
> cannot in Julia store mutable objects inline in an array.
>
> On Friday, 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. Since they are
>> mutable (I assume), we can pass them as an argument to a function to be
>> written to (as output). Of course I realise there are many applications
>> where the immutable tuples are better.
>>
>> Bill.
>>
>> On 12 August 2016 at 12:12, Kristoffer Carlsson 
>> wrote:
>>
>>> They are bitstypes so if you have a vectoe of them they will be stored
>>> "inline" in the vector.
>>
>>
>>

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

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 (as output). Of course I realise there are many applications
where the immutable tuples are better.

Bill.

On 12 August 2016 at 12:12, Kristoffer Carlsson 
wrote:

> They are bitstypes so if you have a vectoe of them they will be stored
> "inline" in the vector.

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

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 StaticArrays, if your
> data is all of the same type and `N` is a compile-time constant. I would be
> curious how they benchmark against `ntuple(f, Val{N})`.
>

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

['Bill Hart' via julia-users]

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
> know, and useful for software that isn't already portable to Windows.]
>
>
>> The Julia binaries from the website load, but unfortunately don't fully
>> work.
>>
>
> Why would it "be great to get this working"? Or at least [of interest] for
> you? I also did wander if it would work but since there is a Windows Julia
> binary, that we would want to maintain for a long time and not drop support
> of Julia that way, I do not see this as a priority, or on the horizon. Only
> that Julia version is supported back to Windows XP. Theoretically using a
> Linux ELF binary in Windows is interesting, but it could be a long time to
> a Windows 10-exclusive world(?).
>
>
The reason this could be interesting for some people is that not all C
libraries have been ported to Windows, and doing so is non-trivial. For
example, we'd like to rely on Singular and Gap and don't currently have the
resources to do a port. However, they work just fine on Ubuntu.

Of course supporting the WSL does not mean abandoning support for native
Windows.

Bill.

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

For me, the version using CartesianIndex is exactly the same speed as the
syntax with the Val, which in turn is faster than without Val.

It probably depends a lot on the application and what the compiler can
handle.

Bill.

On 10 August 2016 at 20:45, Jeffrey Sarnoff <jeffrey.sarn...@gmail.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:
>>>
>>> How about compared with:
>>>
>>> ntuple(i -> a[i] + b[i], Val{N})
>>>
>>>
>>> On 10 August 2016 at 20:32, Jeffrey Sarnoff <jeffrey...@gmail.com>
>>> wrote:
>>>
>>>> Bill,
>>>>
>>>> Following Eric's note, I tried (with a,b equi-length tuples)
>>>> function addTuples(a,b)
>>>> ca = CartesianIndex(a)
>>>> 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:
>>>>>
>>>>> This code seems to be (about 50%) faster than recursive functions:
>>>>>
>>>>> Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)
>>>>>
>>>>>
>>>>> But this seems (about 50%) slower:
>>>>>
>>>>>  ((a[i] + b[i] for i = 1:N)...)
>>>>>
>>>>>
>>>>> Anyway, I can use the first method, until I find something faster.
>>>>> It's definitely way more convenient. Thanks.
>>>>>
>>>>> Bill.
>>>>>
>>>>>
>>>>>
>>>>> On 10 August 2016 at 16:56, Erik Schnetter <schn...@gmail.com> wrote:
>>>>>
>>>>>> The built-in type `CartesianIndex` supports adding 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
>>>>>> "generated functions". These are similar to macros, but 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 10, 2016 at 9:57 AM, 'Bill Hart' via julia-users <
>>>>>> julia...@googlegroups.com> wrote:
>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>> The compiler doesn't do badly with recursive functions for handling
>>>>>>> tuples in very straightforward situations, but for example, if I want to
>>>>>>> create an immutable type based on a tuple the compiler doesn't seem to 
>>>>>>> be
>>>>>>> able to handle the necessary optimisations. At least, that is what I 
>>>>>>> infer
>>>>>>> from the timings. Consider
>>>>>>>
>>>>>>> immutable bill{N}
>>>>>>>d::NTuple{N, Int}
>>>>>>> end
>>>>>>>
>>>>>>> and I want to add two bill's together. If I have to add the tuples
>>>>>>> themselves using recursive functions, then I no longer seem to be able 
>>>>>>> to
>>>>>>> do something like:
>>>>>>>
>>>>>>> A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose
>>>>>>> elements are of type bill.
>>>>>>>
>>>>>>> I know how to handle tuples via arrays, but for efficiency reasons I
>>>>>>> certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 
>>>>>>> 1:N]...).
>>>>>>>
>>>>>>> Bill.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Erik Schnetter <schn...@gmail.com> http://www.perimeterinstitute.
>>>>>> ca/personal/eschnetter/
>>>>>>
>>>>>
>>>>>
>>>

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

How about compared with:

ntuple(i -> a[i] + b[i], Val{N})


On 10 August 2016 at 20:32, Jeffrey Sarnoff <jeffrey.sarn...@gmail.com>
wrote:

> Bill,
>
> Following Eric's note, I tried (with a,b equi-length tuples)
> function addTuples(a,b)
> ca = CartesianIndex(a)
> 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:
>>
>> This code seems to be (about 50%) faster than recursive functions:
>>
>> Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)
>>
>>
>> But this seems (about 50%) slower:
>>
>>  ((a[i] + b[i] for i = 1:N)...)
>>
>>
>> Anyway, I can use the first method, until I find something faster. It's
>> definitely way more convenient. Thanks.
>>
>> Bill.
>>
>>
>>
>> On 10 August 2016 at 16:56, Erik Schnetter <schn...@gmail.com> wrote:
>>
>>> The built-in type `CartesianIndex` supports adding 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
>>> "generated functions". These are similar to macros, but 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.
>>>
>>> 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
>>>
>>>
>>> On Wed, Aug 10, 2016 at 9:57 AM, 'Bill Hart' via julia-users <
>>> julia...@googlegroups.com> wrote:
>>>
>>>> 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).
>>>>
>>>> The compiler doesn't do badly with recursive functions for handling
>>>> tuples in very straightforward situations, but for example, if I want to
>>>> create an immutable type based on a tuple the compiler doesn't seem to be
>>>> able to handle the necessary optimisations. At least, that is what I infer
>>>> from the timings. Consider
>>>>
>>>> immutable bill{N}
>>>>d::NTuple{N, Int}
>>>> end
>>>>
>>>> and I want to add two bill's together. If I have to add the tuples
>>>> themselves using recursive functions, then I no longer seem to be able to
>>>> do something like:
>>>>
>>>> A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose
>>>> elements are of type bill.
>>>>
>>>> I know how to handle tuples via arrays, but for efficiency reasons I
>>>> certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 1:N]...).
>>>>
>>>> Bill.
>>>>
>>>
>>>
>>>
>>> --
>>> Erik Schnetter <schn...@gmail.com> http://www.perimeterinstitute.
>>> ca/personal/eschnetter/
>>>
>>
>>

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

You are right. My previous timings were totally wrong anyway, due to a bug
I introduced into my program. After fixing it, a fair comparison shows that:

Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], Val{N})


is exactly the same speed as the recursive functions I was using. And it is
at least 20% faster in my application than the version with N instead of
Val{N}.

Unfortunately, in my application, the other solution:

((a[i] + b[i] for i = 1:N)...)


is extremely slow, and in fact Julia crashes with a segfault before my
benchmark finishes (due to using too much memory). So that isn't an option.

Anyway, the first solution above is as fast as what I had, and much more
convenient. I will go with that for now.

Bill.

On 10 August 2016 at 18:17, Shashi Gowda <shashigowd...@gmail.com> wrote:

>
> Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> 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:
>
>> This code seems to be (about 50%) faster than recursive functions:
>>
>> Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)
>>
>>
>> But this seems (about 50%) slower:
>>
>>  ((a[i] + b[i] for i = 1:N)...)
>>
>>
>> Anyway, I can use the first method, until I find something faster. It's
>> definitely way more convenient. Thanks.
>>
>> Bill.
>>
>>
>>
>> On 10 August 2016 at 16:56, Erik Schnetter <schnet...@gmail.com> wrote:
>>
>>> The built-in type `CartesianIndex` supports adding 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
>>> "generated functions". These are similar to macros, but 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.
>>>
>>> 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
>>>
>>>
>>> On Wed, Aug 10, 2016 at 9:57 AM, 'Bill Hart' via julia-users <
>>> julia-users@googlegroups.com> wrote:
>>>
>>>> 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).
>>>>
>>>> The compiler doesn't do badly with recursive functions for handling
>>>> tuples in very straightforward situations, but for example, if I want to
>>>> create an immutable type based on a tuple the compiler doesn't seem to be
>>>> able to handle the necessary optimisations. At least, that is what I infer
>>>> from the timings. Consider
>>>>
>>>> immutable bill{N}
>>>>d::NTuple{N, Int}
>>>> end
>>>>
>>>> and I want to add two bill's together. If I have to add the tuples
>>>> themselves using recursive functions, then I no longer seem to be able to
>>>> do something like:
>>>>
>>>> A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose
>>>> elements are of type bill.
>>>>
>>>> I know how to handle tuples via arrays, but for efficiency reasons I
>>>> certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 1:N]...).
>>>>
>>>> Bill.
>>>>
>>>
>>>
>>>
>>> --
>>> Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.
>>> ca/personal/eschnetter/
>>>
>>
>>
>

Re: [julia-users] Adding tuples

['Bill Hart' via julia-users]

This code seems to be (about 50%) faster than recursive functions:

Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)


But this seems (about 50%) slower:

 ((a[i] + b[i] for i = 1:N)...)


Anyway, I can use the first method, until I find something faster. It's
definitely way more convenient. Thanks.

Bill.



On 10 August 2016 at 16:56, Erik Schnetter <schnet...@gmail.com> wrote:

> The built-in type `CartesianIndex` supports adding 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
> "generated functions". These are similar to macros, but 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.
>
> 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
>
>
> On Wed, Aug 10, 2016 at 9:57 AM, 'Bill Hart' via julia-users <
> julia-users@googlegroups.com> wrote:
>
>> 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).
>>
>> The compiler doesn't do badly with recursive functions for handling
>> tuples in very straightforward situations, but for example, if I want to
>> create an immutable type based on a tuple the compiler doesn't seem to be
>> able to handle the necessary optimisations. At least, that is what I infer
>> from the timings. Consider
>>
>> immutable bill{N}
>>d::NTuple{N, Int}
>> end
>>
>> and I want to add two bill's together. If I have to add the tuples
>> themselves using recursive functions, then I no longer seem to be able to
>> do something like:
>>
>> A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose
>> elements are of type bill.
>>
>> I know how to handle tuples via arrays, but for efficiency reasons I
>> certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 1:N]...).
>>
>> Bill.
>>
>
>
>
> --
> Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.
> ca/personal/eschnetter/
>

Re: [julia-users] Re: Adding tuples

['Bill Hart' via julia-users]

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 to throw out another option, you might also consider
>
> ((a[i] + b[i] for i = 1:N)...)
>
> Pablo.
>

Re: [julia-users] Re: Adding tuples

['Bill Hart' via julia-users]

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}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)
>
> there is also
>
> map(+, a, b)
>
> where `a`, and `b` are the tuples you want to sum elementwise.
>
> There is a chance that eventually one will be able to also use broadcast
> or elementwise addition .+ for doing this.
>

[julia-users] Adding tuples

['Bill Hart' via julia-users]

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

The compiler doesn't do badly with recursive functions for handling tuples 
in very straightforward situations, but for example, if I want to create an 
immutable type based on a tuple the compiler doesn't seem to be able to 
handle the necessary optimisations. At least, that is what I infer from the 
timings. Consider

immutable bill{N}
   d::NTuple{N, Int}
end

and I want to add two bill's together. If I have to add the tuples 
themselves using recursive functions, then I no longer seem to be able to 
do something like:

A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose elements 
are of type bill.

I know how to handle tuples via arrays, but for efficiency reasons I 
certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 1:N]...).

Bill.

Re: [julia-users] Windows subsystem for Linux

['Bill Hart' via julia-users]

It just happens during precompilation I think. I'll look into it and see if
I can get some more information.

On 4 August 2016 at 11:30, Tony Kelman <t...@kelman.net> wrote:

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

Re: [julia-users] Windows subsystem for Linux

['Bill Hart' via julia-users]

Ok, I'll hold off making a ticket then. Tony, do you think the double free
and corruption with Julia 0.5.0 could be independent of Microsoft. I'm not
seeing that behaviour anywhere else. Do we have any tools that might help
track it down? Or is it just not worth it for now?

Bill.

On 4 August 2016 at 08:54, Tony Kelman <t...@kelman.net> wrote:

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

Re: [julia-users] Windows subsystem for Linux

['Bill Hart' via julia-users]

I agree, it would be great to get it going.

I'll open a ticket later on tonight or tomorrow. I'm not sure I can 
contribute much more to it myself. I think the first thing to do might be 
to contact the libuv people and ask them whether libuv is expected to run 
on WSL. It may just be a waiting game, until Microsoft are able to 
implement enough syscalls for them.

Bill.

On Wednesday, 3 August 2016 18:53:34 UTC+2, Stefan Karpinski wrote:
>
> Would be great to get this working. Maybe open an issue to track this?
>
> On Wednesday, August 3, 2016, 'Bill Hart' via julia-users <
> julia...@googlegroups.com > wrote:
>
>> In fact, both the old and new versions of libuv seem to fail their test 
>> suites on WSL. I imagine they tie into the system calls pretty tightly and 
>> Microsoft may not have implemented them all fully or correctly as of the 
>> moment. Perhaps things will improve with the next release of WSL.
>>
>> Bill.
>>
>> On Wednesday, 3 August 2016 18:23:53 UTC+2, Bill Hart wrote:
>>>
>>> Julia seems to use an old version of libuv. People have noticed that 
>>> libuv has problems on WSL. I don't know whether these have been fixed or 
>>> not. I couldn't find any specific tickets for it. But perhaps the latest 
>>> libuv works on WSL and maybe that points to a possible solution.
>>>
>>> Bill.
>>>
>>

[julia-users] Re: Windows subsystem for Linux

['Bill Hart' via julia-users]

In fact, both the old and new versions of libuv seem to fail their test 
suites on WSL. I imagine they tie into the system calls pretty tightly and 
Microsoft may not have implemented them all fully or correctly as of the 
moment. Perhaps things will improve with the next release of WSL.

Bill.

On Wednesday, 3 August 2016 18:23:53 UTC+2, Bill Hart wrote:
>
> Julia seems to use an old version of libuv. People have noticed that libuv 
> has problems on WSL. I don't know whether these have been fixed or not. I 
> couldn't find any specific tickets for it. But perhaps the latest libuv 
> works on WSL and maybe that points to a possible solution.
>
> Bill.
>

[julia-users] Re: Windows subsystem for Linux

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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.5.0-pre Julia binaries from the website. It seems 
the subsystem returns a Not Enough Memory error whenever Julia tries to 
spawn, which it does pretty often. This seems to be the main and perhaps 
only problem preventing Julia 0.4.6 working for now. I tried defining a 
function and running it, and this caused no issues.

There are also double free or corruption errors with Julia 0.5.0. Note that 
I am only getting this in Julia 0.5.0, not anything else, e.g. Sage seems 
to work ok and passes much of its test suite without any such errors. Apart 
from the spawn issue, Julia 0.4.6 also doesn't have this problem.

I tried building Julia 0.4.6 from source and the main issue I hit was that 
pcre2 requires a stack limit of 16MB, but WSL is limited to 8MB. There is a 
build option for pcre to use heap instead of stack, but it obviously hasn't 
been maintained. It still complains it can't set the stack to the right 
limit. And ulimit refuses to increase the limit. I ended up just replacing 
the relevant test code with an empty shell script so the build could 
continue.

Also, when building LLVM and fftw it frequently corrupted the .o files, so 
some of them had to be built more than once to get a valid .o file. This 
seems to be avoidable by not doing a parallel build. But of course that 
takes a very long time.

BLAS seems to take an extremely long time to build, making building from 
source pretty much impractical on the subsystem at present. It takes many 
hours. The main problem seems to be the glacially slow filesystem. The 
compute performance seems to be isomorphic to a real Ubuntu server in the 
tests I've done, including ones that allocate lots of memory. Of course 
slow build times are not that important given that it is supposed to work 
with standard Ubuntu binaries which can be built elsewhere.

I was able to get the build to complete though and Julia 0.4.6 ran, but it 
has the same issue with spawn as with the binaries on the Julia website, 
e.g. 

julia> run(`ls`)
ERROR: could not spawn `ls`: not enough memory (ENOMEM)
 in _jl_spawn at process.jl:262
 in anonymous at process.jl:415
 in setup_stdio at ./process.jl:403
 in __spawn#58__ at ./process.jl:414
 in run at ./process.jl:530

There should be enough memory on this machine. I think the message is 
caused by some other issue.

Bill.

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

['Bill Hart' via julia-users]

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.

On 31 July 2016 at 18:32, Bill Hart  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  wrote:
>
>> Hey,
>>   I am really interested in trying Nemo since I want to use the ArbFloats
>> and ArbReals in DifferentialEquations.jl for "faster BigFloats". However, I
>> am getting the following error when trying to build Nemo:
>>
>> julia> Pkg.build("Nemo")
>> INFO: Building Nemo
>> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>>  in @windows(::Any, ::Any) at .\deprecated.jl:473
>>  in include_from_node1(::String) at .\loading.jl:426
>>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:442 (repeats 2
>> times)
>>  in cd(::##2#4, ::String) at .\file.jl:48
>>  in (::##1#3)(::IOStream) at .\none:13
>>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>>  in eval(::Module, ::Any) at .\boot.jl:234
>>  in process_options(::Base.JLOptions) at .\client.jl:239
>>  in _start() at .\client.jl:318
>> while loading C:\Users\Chris\.julia\v0.5\Nemo\deps\build.jl, in
>> expression starting on line 1
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>> 100 85504  100 855040 0   668k  0 --:--:-- --:--:-- --:--:--
>>  668k
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>> 100  672k  100  672k0 0  2690k  0 --:--:-- --:--:-- --:--:--
>> 2690k
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>> 100  450k  100  450k0 0  1925k  0 --:--:-- --:--:-- --:--:--
>> 1925k
>> [ ERROR: Nemo
>> ]=
>>
>> LoadError: chdir C:\Users\Chris\.julia\v0.5\Nemo\deps/antic: no such file
>> or directory (ENOENT)
>> while loading C:\Users\Chris\.julia\v0.5\Nemo\deps\build.jl, in
>> expression starting on line 121
>>
>>
>> 
>>
>> [ BUILD ERRORS
>> ]
>>
>> WARNING: Nemo had build errors.
>>
>>  - packages with build errors remain installed in
>> C:\Users\Chris\.julia\v0.5
>>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>>  - build a single package by running its `deps/build.jl` script
>>
>>
>> 
>>
>> This is on v0.5-rc0 with Windows 10.
>>
>> On Saturday, July 30, 2016 at 6:33:17 PM UTC-7, Marcus Appelros wrote:
>>>
>>> The use case is similar to AlphaGo, ie deterministic full information
>>> game with a huge state space.
>>>
>>> That reinforcement package looks interesting, looking into it. Love to
>>> collaborate
>>>
>>
>

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

['Bill Hart' via julia-users]

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 DifferentialEquations.jl for "faster BigFloats". However, I
> am getting the following error when trying to build Nemo:
>
> julia> Pkg.build("Nemo")
> INFO: Building Nemo
> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in @windows(::Any, ::Any) at .\deprecated.jl:473
>  in include_from_node1(::String) at .\loading.jl:426
>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:442 (repeats 2
> times)
>  in cd(::##2#4, ::String) at .\file.jl:48
>  in (::##1#3)(::IOStream) at .\none:13
>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>  in eval(::Module, ::Any) at .\boot.jl:234
>  in process_options(::Base.JLOptions) at .\client.jl:239
>  in _start() at .\client.jl:318
> while loading C:\Users\Chris\.julia\v0.5\Nemo\deps\build.jl, in expression
> starting on line 1
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 85504  100 855040 0   668k  0 --:--:-- --:--:-- --:--:--
>  668k
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100  672k  100  672k0 0  2690k  0 --:--:-- --:--:-- --:--:--
> 2690k
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100  450k  100  450k0 0  1925k  0 --:--:-- --:--:-- --:--:--
> 1925k
> [ ERROR: Nemo
> ]=
>
> LoadError: chdir C:\Users\Chris\.julia\v0.5\Nemo\deps/antic: no such file
> or directory (ENOENT)
> while loading C:\Users\Chris\.julia\v0.5\Nemo\deps\build.jl, in expression
> starting on line 121
>
>
> 
>
> [ BUILD ERRORS
> ]
>
> WARNING: Nemo had build errors.
>
>  - packages with build errors remain installed in
> C:\Users\Chris\.julia\v0.5
>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>  - build a single package by running its `deps/build.jl` script
>
>
> 
>
> This is on v0.5-rc0 with Windows 10.
>
> On Saturday, July 30, 2016 at 6:33:17 PM UTC-7, Marcus Appelros wrote:
>>
>> The use case is similar to AlphaGo, ie deterministic full information
>> game with a huge state space.
>>
>> That reinforcement package looks interesting, looking into it. Love to
>> collaborate
>>
>

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

['Bill Hart' via julia-users]

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 changed the name of all the "generic" types in
generic/GenericTypes.jl, mainly by putting Gen in front of the type names.
Again you can compare with your older version of the file.

We do have complex root finding. The function is called roots. It is
documented on the polynomials page [1].

Bill.

[1] http://nemocas.github.io/Nemo.jl/latest/build/polynomial/#root-finding

On 30 July 2016 at 22:43, Alireza Nejati  wrote:

> Very cool! Is there a page where these changes are described more? How has
> the abstract type hierarchy been changed?
>
> Also, 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.
>>
>> 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, including example code, how to get started etc.,
>> is available online:
>>
>> http://nemocas.github.io/Nemo.jl/latest/
>>
>> The new features of Nemo 0.5 include:
>>
>> * Wrap Arb's arb_mat, acb_mat (matrices over R and C)
>> * Wrap Arb's arb_poly, acb_poly (polys over R and C)
>> * Completely rewritten, online documentation
>> * Wrap Flint's fmpq_mat (matrices over Q)
>> * Nullspace over the integers (using HNF)
>> * Factorisations now return a Dict
>> * Make caching of parent objects optional
>> * Add benchmarks
>> * Remove a lot of type instability
>> * Integrate C libraries with Julia's counted malloc
>> * Redesign abstract type hierarchy
>> * Appveyor continuous integration for Windows
>> * Lots of cleaning up and restructuring of the code base
>> * Many bug fixes
>>
>> We will release a small update in the next few weeks to support Julia 0.5
>> when it comes out, However it should work with nightlies right now with
>> some warnings.
>>
>> Enjoy,
>>
>> The Nemo Developers.
>>
>

[julia-users] [ANN] Nemo 0.5 released

['Bill Hart' via julia-users]

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, including example code, how to get started etc., is 
available online:

http://nemocas.github.io/Nemo.jl/latest/

The new features of Nemo 0.5 include:

* Wrap Arb's arb_mat, acb_mat (matrices over R and C)
* Wrap Arb's arb_poly, acb_poly (polys over R and C)
* Completely rewritten, online documentation
* Wrap Flint's fmpq_mat (matrices over Q)
* Nullspace over the integers (using HNF)
* Factorisations now return a Dict
* Make caching of parent objects optional
* Add benchmarks
* Remove a lot of type instability
* Integrate C libraries with Julia's counted malloc
* Redesign abstract type hierarchy
* Appveyor continuous integration for Windows
* Lots of cleaning up and restructuring of the code base
* Many bug fixes

We will release a small update in the next few weeks to support Julia 0.5 
when it comes out, However it should work with nightlies right now with 
some warnings.
 
Enjoy,

The Nemo Developers.

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

['Bill Hart' via julia-users]

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 was using linux assembly code instead of Windows, causing 
all sorts of problems.

The following is a bit off topic, but just in case anyone else encounters 
this issue themselves, here is the correct way to build MPIR and MPFR dlls 
on Windows 64 under msys2 with mingw-w64 compiler installed and in the PATH 
(assuming MPIR's ./config.guess claims you have a core2):

wget http://mpir.org/mpir-2.7.2.tar.bz2
tar -xvf mpir-2.7.2.tar.bz2
cd mpir-2.7.2
./configure --enable-shared --disable-static --enable-gmpcompat 
--build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
cd ..
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
tar -xvf mpfr-3.1.4.tar.bz2
cd mpfr-3.1.4
./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
--disable-static
make -j
cd ..

Bill.

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

['Bill Hart' via julia-users]

Coincidentally we had a failure in the same test on Linux today (after 
running it hundreds of times before without issue).

My colleague had the bright idea of running that test many times so that we 
could reliably reproduce the error on Linux. We then found the bug, which 
was in fact a bug 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 
> <julia...@googlegroups.com > wrote: 
> > 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 on Windows 64. 
> > 
> > depends22 shows no problems with the dlls and that they don't depend on 
> the 
> > msys dll. I'm quite sure I've built them correctly. 
> > 
> > Julia seems to think the dlls are valid, I just get that error. 
> > 
> > Does anyone have any insight into what this error is and what is causing 
> it? 
>
> The error means there's some memory error. It's impossible to tell 
> what's causing it without more detail. 
>
> > 
> > Bill. 
>

[julia-users] ReadOnlyMemoryError() on Windows 64

['Bill Hart' via julia-users]

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 on Windows 64.

depends22 shows no problems with the dlls and that they don't depend on the 
msys dll. I'm quite sure I've built them correctly.

Julia seems to think the dlls are valid, I just get that error.

Does anyone have any insight into what this error is and what is causing it?

Bill.

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

['Bill Hart' via julia-users]

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:
>
> Fragile how? The -16 is part of the library name.

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

['Bill Hart' via julia-users]

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)

['Bill Hart' via julia-users]

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 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 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),
>>   cglobal(:jl_gc_counted_free))
>>
>> Can anyone see what could possibly be wrong with this? It works just fine
>> on Linux, but not Windows 64.
>>
>> Note, we define libgmp as follows (which I am sure is correct):
>>
>> const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
>> const libdir = joinpath(pkgdir, "local", "lib")
>> const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")
>>
>> Bill.
>>
>
>

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

['Bill Hart' via julia-users]

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 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),
>   cglobal(:jl_gc_counted_free))
>
> Can anyone see what could possibly be wrong with this? It works just fine
> on Linux, but not Windows 64.
>
> Note, we define libgmp as follows (which I am sure is correct):
>
> const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
> const libdir = joinpath(pkgdir, "local", "lib")
> const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")
>
> Bill.
>

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

['Bill Hart' via julia-users]

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),
  cglobal(:jl_gc_counted_free))

Can anyone see what could possibly be wrong with this? It works just fine 
on Linux, but not Windows 64.

Note, we define libgmp as follows (which I am sure is correct):

const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
const libdir = joinpath(pkgdir, "local", "lib")
const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")

Bill.

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

['Bill Hart' via julia-users]

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 to check all the julia code we use to load the dlls and see what 
we changed. I know that we are setting some memory functions now that we 
didn't use to set, so Julia can do counted_malloc.

This is a real head scratcher, because I can't think of a plausible 
explanation for the problem. If I remove all the code to set the memory 
functions except the one to set the GMP memory functions, it complains that 
it can't find the GMP dll. That's despite the fact that we use this dll 
without problems in the old version of Nemo.

Bill.

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

['Bill Hart' via julia-users]

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] [ ERROR: Nemo 
]=

failed process: 
Process(`'C:\Users\User\AppData\Local\Julia-0.4.6\bin\julia' 
--check-bounds=yes --code-coverage=none --color=yes 
'C:\Users\User\.julia\v0.4\Nemo\test\runtests.jl'`, 
ProcessExited(3221225477)) [3221225477]


ERROR: Nemo had test errors
 in error at error.jl:21

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

['Bill Hart' via julia-users]

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 the new version of Nemo with Julia 0.4.0 : same failure

3) Building the old version of Nemo with Julia 0.4.0 : works OK

This suggests that we've changed something in the latest version of Nemo 
that screws up precompilation on Windows 64. But we haven't any idea what 
it might be. It works just fine under Linux.

Does anyone have any idea what might be going wrong on Windows 64?

Bill.

[1] 

ERROR: Failed to precompile Nemo to C:\Users\User\.julia\lib\v0.4\Nemo.ji
 in error at error.jl:21

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

['Bill Hart' via julia-users]

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)
 return 1
  end
  type nemomat <: MatElem
  end
  export nemomat
  export det
   end
Nemo

julia> module Hecke
  using Nemo
  import Nemo.det
  type SpecialMat <: Nemo.MatElem
 data::Int
  end
  function det(a::SpecialMat)
 if a.data == 4
return 3
 else
return invoke(det, (Nemo.MatElem,), a)
 end
  end
  export SpecialMat
  export det
   end
Hecke

julia> using Hecke

julia> s = SpecialMat(3)
Hecke.SpecialMat(3)

julia> t = SpecialMat(4)
Hecke.SpecialMat(4)

julia> det(s)
1

julia> det(t)
3

Let's help search engines with this, since we were unable to find anything, 
and it is such an important issue:

trouble extending a Base function in Julia
How do I call a specific version of a function in Julia for specific types
How do I call a more general version of a function in Julia
How do I call a less specific version of a function in Julia
How do I call a specific method in Julia
method to apply a function in Julia
invoking a given version of a function in Julia

To the Julia devs: please, please don't remove this functionality!

Bill.

On Tuesday, 28 June 2016 18:40:27 UTC+2, Rafael Fourquet wrote:
>
> I'm far from expert on those questions, but would the "invoke" function 
> work? 
> I think it's considered to be a tool of the last resort, but seems to 
> be the situation you are in! 
>
> invoke(f, (types...), args...) 
>
>   Invoke a method for the given generic function matching the 
> specified types (as a tuple), on the specified arguments. The 
> arguments must be compatible with 
>   the specified types. This allows invoking a method other than the 
> most specific matching method, which is useful when the behavior of a 
> more general 
>   definition is explicitly needed (often as part of the implementation 
> of a more specific method of the same function). 
>

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

['Bill Hart' via julia-users]

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 
above specially so it can call the Nemo version of the function without 
calling itself.

end # module

The behaviour would be: if extends is missing, it gives an ambiguity 
warning about Nemo.det vs Hecke.det if someone calls det after including 
Hecke and Nemo.

Bill.

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

['Bill Hart' via julia-users]

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, this 
has been removed in Julia 0.5.

2) Have a syntax for calling a method with a given signature, e.g. 
apply(det, (MatElem,), m) or something like that. Something like this used 
to exist in Julia but has been removed.

3) Have Julia not print an ambiguity warning about 
Base.det/Nemo.det/Hecke.det when calling det on a matrix where there is a 
specific implementation for that type in Hecke, but only something more 
general in the other modules. Currently Julia complains that you might mean 
Base.det or Hecke.det even though the former does not implement a function 
for matrices of type SpecialMat. But why? What's ambiguous here?

4) Remove the requirement for a module to extend the definition from Base 
or whatever other packages it uses, if it is only defining the function for 
one of its own types and not a type that is present in Base or that other 
module.

5) Introduce a way of calling an implementation provided by a specific 
module, e.g. specifying Nemo.det would only call the version actually 
defined in Nemo. This might feel like the current behaviour, but it doesn't 
actually work, since it is Base.det or Nemo.det that Hecke needs to be 
overloaded in the first place. So calling Nemo.det from within Hecke.det 
just causes it to call Hecke.det for that specific type, causing a stack 
overflow. 

6) Allow us to define function Hecke.det (and still export it as det) in 
Hecke, and call Nemo.det from within that implementation. Again, this might 
feel like the current behaviour, but it doesn't work because it is Nemo.det 
or Base.det that needs to be defined in Hecke, currently.

Bill.

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

['Bill Hart' via julia-users]

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 
Base.det in Nemo.

Hecke depends on Nemo and tries to extend Nemo.det (or Base.det).

Hecke wants to define det for one of its own types, let's call it 
SpecialMat. Now Hecke's SpecialMat belongs to Nemo's abstract type MatElem, 
i.e. SpecialMat <: MatElem.

Nothing unusual so far.

The problem is: Hecke would like to call the det function provided by Nemo 
in case the algorithm they provide is going to be slower (a decision that 
is made at runtime).

What we try
=

So what we naturally try in Hecke is something like the following 
(obviously this code doesn't actually work):

module Hecke

using Nemo

type SpecialMat <: MatElem  ## Nemo has a MatElem type class and a 
"generic" det algorithm for any type that belongs to it
   # some data
end

function det(m::SpecialMat)

# do different things depending on properties of the matrix m

   if check_some_properties_of_a_matrix(m)
   # implementation of special determinant algorithm that only works 
for Hecke SpecialMat's
   else
   Nemo.det(m) # fallback to the Nemo implementation of det (which is 
extensive)
   end
end

export det

end # module

Here are some potential solutions we tried which didn't work:

1) Only import the functions from Nemo that Hecke doesn't need to overload, 
i.e. don't import det from Nemo (or Base)

This causes Julia to tell the user that det could refer to Base.det or 
Hecke.det, even though Base.det doesn't provide a function for the 
specified type. We certainly can't expect the user to have to look up all 
the documentation for Base, Nemo and Hecke every time they call a function 
so they know how to qualify it. So this isn't a workable solution, 
obviously. It's also far too verbose.

2) Try to qualify the function name with the name of the module, i.e. call 
Nemo.det in the Hecke definition of the function, as above. 

   This doesn't work, since it is Nemo.det that currently has being 
overloaded. So the Hecke det function just segfaults when called.

3) Look up the method table for the function we require and call the 
specific method. 

   This works in Julia 0.4, but the ability to call methods has been 
removed in 0.5.

This is an exceedingly frustrating problem. In fact it also occurs within 
Nemo itself, since every time we want to implement a specialised version of 
a generic function for a specific type, and have it fall back to the 
generic version in certain cases determined at runtime, we can't do it, 
without first renaming the generic implementation to something else with a 
different name.

This sort of thing is making it very difficult to build large systems. It's 
not fair to the developers of Hecke to ask them to duplicate all the code 
in Nemo just so they can make this work, or alternatively force Nemo to 
define every function twice so that there is a callable version with a 
different name.

Does anyone know a workaround (any hack that works will do) for this issue, 
that works in Julia 0.4 and Julia 0.5?

And is there a plan to fix this sort of issue in Julia in the future? The 
module system currently makes it quite hard to work with multiple modules. 
We are often encouraged to split our large systems into smaller 
modules/packages to get around certain issues, and then when we do that, 
the module system actually gets in the way.

Bill.

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

['Bill Hart' via julia-users]

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 2016 at 13:25, Bill Hart  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 last few
> days, since we were passing just fine on Travis. Though at this stage, I
> haven't checked whether we are still passing on Travis.
>
> Bill.
>
> On 31 May 2016 at 12:52, Nils Gudat  wrote:
>
>> Resurrecting this very old thread - after having been able to solve the
>> model with no seg faults over the last couple of months, they have now
>> returned and occur much faster (usually within 2 hours of running the code).
>> I have refactored the code a little so that it hopefully will be possible
>> for others to run it. Cloning the entire repo at
>> http://github.com/nilshg/LearningModels, it should run when altering the
>> path in
>> https://github.com/nilshg/LearningModels/blob/master/NHL/NHL_maximize.jl
>> to whatever path it has been cloned to.
>>
>> I'm running this code on a 16-core Ubuntu 14.04 machine with Julia 0.4.5
>> installed an all packages on the latest tagged versions.
>>
>> On Tuesday, September 29, 2015 at 1:43:31 PM UTC+1, Nils Gudat wrote:
>>>
>>> The code usually segfaults after 2-5 hours, and is available at
>>> http://github.com/nilshg/LearningModels, however I haven't written it
>>> up in a way that is easy to run (right now it depends on some data not
>>> included in the repo), so I'll have to restructure a bit before you can run
>>> it. I'll try to do so today if I find the time.
>>>
>>
>

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

['Bill Hart' via julia-users]

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't checked whether we are still passing on Travis.

Bill.

On 31 May 2016 at 12:52, Nils Gudat  wrote:

> Resurrecting this very old thread - after having been able to solve the
> model with no seg faults over the last couple of months, they have now
> returned and occur much faster (usually within 2 hours of running the code).
> I have refactored the code a little so that it hopefully will be possible
> for others to run it. Cloning the entire repo at
> http://github.com/nilshg/LearningModels, it should run when altering the
> path in
> https://github.com/nilshg/LearningModels/blob/master/NHL/NHL_maximize.jl
> to whatever path it has been cloned to.
>
> I'm running this code on a 16-core Ubuntu 14.04 machine with Julia 0.4.5
> installed an all packages on the latest tagged versions.
>
> On Tuesday, September 29, 2015 at 1:43:31 PM UTC+1, Nils Gudat wrote:
>>
>> The code usually segfaults after 2-5 hours, and is available at
>> http://github.com/nilshg/LearningModels, however I haven't written it up
>> in a way that is easy to run (right now it depends on some data not
>> included in the repo), so I'll have to restructure a bit before you can run
>> it. I'll try to do so today if I find the time.
>>
>

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

['Bill Hart' via julia-users]

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 the warning should print correctly. Currently there is
> no
> > end-of-line when the message is printed, so we end up with a handful of
> > these errors stuck one after the other.
> >
> > But I too wonder what is the purpose of the warning.
>
> Throwing inside a C callback is usually a bad idea (most C libraries
> won't handle it correctly and cleanly). However, the issue with the
> warning is that while it does capture the most obvious case where you
> made a type and the function always throws an error, there are cases
> as you describe where this might be useful and the error also doesn't
> capture the case where the function can conditionally throw (which
> IMHO is worse than always throw since at least you'll notice while
> testing if that's not actually what you want).
>
> >
> > On 4 May 2016 at 14:27, Yichao Yu <yyc1...@gmail.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-Subsystem")
> >> > end
> >> >
> >> >
> >> > What is the standard way of making Julia accept this as a valid
> function
> >> > (it
> >> > is not meant to return)?
> >> >
> >>
> >> This warning was added in
> >> https://github.com/JuliaLang/julia/pull/15972 . I personally think it
> >> should be removed. @Jameson.
> >>
> >> >
> >
> >
>

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

['Bill Hart' via julia-users]

At the very least the warning should print correctly. Currently there is no
end-of-line when the message is printed, so we end up with a handful of
these errors stuck one after the other.

But I too wonder what is the purpose of the warning.

On 4 May 2016 at 14:27, Yichao Yu <yyc1...@gmail.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-Subsystem")
> > end
> >
> >
> > What is the standard way of making Julia accept this as a valid function
> (it
> > is not meant to return)?
> >
>
> This warning was added in
> https://github.com/JuliaLang/julia/pull/15972 . I personally think it
> should be removed. @Jameson.
>
> >
>

[julia-users] Warning cfunction does not return

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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 
could well be quite a bit slower.

On Wednesday, 13 April 2016 11:09:27 UTC+2, vincent leclere wrote:
>
> Hi all,
>
> quick question: I am building a package and has been defining types with 
> Int64 or Float64 properties.
> Is there any reason why I should be using Int and Float instead ? (Does 
> Int64 work on 32bits processors ?)
> Will it be at the price of efficiency loss ?
>
> Thanks
>

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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 bisect working assumption that there is one bad commit and you are 
trying to find it.

Here is a list of commits I have hit during various commits and the times I 
got for those commits. There was also another commit I hit where the time 
improved by a factor of 2, but all subsequent attempts to build any commits 
of Julia failed and so I had to clone the repository again. Because of 
this, I threw that data point away as likely corrupt.

41fb1ba good 15s
79a0d7b good
5ea20fc good
275c7e8 good
bea07fc good
c5704ed good
0318444 good

6396218 bad1
3b7f18a bad1
63daf4f bad1
1bfabbb bad1
179a439 bad1
0b6cab6 bad1
d8ec4a7 bad1
064b03c bad1
53b02a6 bad1
ca6f253 bad1 42s

8f4238a bad2 59s
f67203c bad2 53s
af81431 bad2 58s

6382116 bad3 73s 
24276a5 bad3 74s
79b08ca bad3 73s
93cb2ae bad3 71s
5baedf4 bad3 72s

70a3120 ??   48s

8af0134 bad4 82s
def50a0 bad4 78s
039f57b bad4 78s
597dc7b bad4 78s
adc1ed8 bad4 78s
fc469b6 bad4 78s
be9f208 bad5 87s
master  bad5 90s

In summary, the commits that I know are serious regressions for sure are:

6396218
8f4238a
6382116
8af0134

There's also a regression somewhere between fc469b6 and cf68f4d3 (the 
latter being master some time today) which I didn't bisect yet. At this 
point I'm not sure how useful this is.

Bill.

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

['Bill Hart' via julia-users]

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

['Bill Hart' via julia-users]

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% regression.

There are still at least two regressions to track down.

Bill.

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

['Bill Hart' via julia-users]

The second bad commit is:

7facd20 Merge pull request #15300 from JuliaLang/jn/typeinfq

However this is only about a 60% regression. There is still a third commit 
that is bad. I will try to bisect it today if I can.

There is also a fourth smaller regression of about 10% somewhere, but I 
didn't bother tracking that down as we can live with that.

Bill.

On Thursday, 24 March 2016 02:15:57 UTC+1, Tim Holy wrote:
>
> That's a big help. I'm not certain Jeff reads julia-users, however, so you 
> might want to file an issue. 
>
> Best, 
> --Tim 
>
> On 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 over 2 seems to be: 
> > > 
> > > 639621859863609c5f3abbc2ed75c675695b3693 is the first bad commit 
> > > commit 639621859863609c5f3abbc2ed75c675695b3693 
> > > Author: Jeff Bezanson <jeff.b{...@gmail.com > 
> > > Date:   Tue Jan 26 23:33:19 2016 -0500 
> > > 
> > > modify Base.Test not to create a closure for each test 
> > > : 
> > > :04 04 9c84c85afaed99190f3e744123dccc732f2c760e 
> > > 
> > > 486795536d95d1fb14fd9f7f415fb63cd9c6e490 M  base 
> > > 
> > > :04 04 48205a7b1b007692c81b1a8d931cb44f6cc97be8 
> > > 
> > > acb43cd0ecece4237e1834b7a3b577f312884650 M  test 
> > > 
> > > I will try to find time to find the second regression, which occurs 
> > > between 1bfabbb and 1bfabbb I believe. 
> > 
> > Sorry, that should say between 1bfabbb and 9d6e726. 
> > 
> > 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 the Julia commits in that interval. We had to work 
> around 
> > >> 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, 
> > >>> --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 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 
> > >>> 
> > >>> > likely that it can be fixed? It's really killing our development 
> > >>> 
> > >>> cycle. 
> > >>> 
> > >>> > Bill. 
>
>

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

['Bill Hart' via julia-users]

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 commit
> commit 639621859863609c5f3abbc2ed75c675695b3693
> Author: Jeff Bezanson <jeff.b{xx}@gmail.com>
> Date:   Tue Jan 26 23:33:19 2016 -0500
>
> modify Base.Test not to create a closure for each test
>
> :04 04 9c84c85afaed99190f3e744123dccc732f2c760e 
> 486795536d95d1fb14fd9f7f415fb63cd9c6e490 M  base
> :04 04 48205a7b1b007692c81b1a8d931cb44f6cc97be8 
> acb43cd0ecece4237e1834b7a3b577f312884650 M  test
>
> I will try to find time to find the second regression, which occurs 
> between 1bfabbb and 1bfabbb I believe.
>
>
Sorry, that should say between 1bfabbb and 9d6e726.

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 the Julia commits in that interval. We had to work around 
>> 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, 
>>> --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 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 
>>> > likely that it can be fixed? It's really killing our development 
>>> cycle. 
>>> > 
>>> > Bill. 
>>>
>>>

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

['Bill Hart' via julia-users]

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 commit
commit 639621859863609c5f3abbc2ed75c675695b3693
Author: Jeff Bezanson <jeff.b{xx}@gmail.com>
Date:   Tue Jan 26 23:33:19 2016 -0500

modify Base.Test not to create a closure for each test

:04 04 9c84c85afaed99190f3e744123dccc732f2c760e 
486795536d95d1fb14fd9f7f415fb63cd9c6e490 M  base
:04 04 48205a7b1b007692c81b1a8d931cb44f6cc97be8 
acb43cd0ecece4237e1834b7a3b577f312884650 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 the Julia commits in that interval. We had to work around 
> 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, 
>> --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 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 
>> > likely that it can be fixed? It's really killing our development cycle. 
>> > 
>> > Bill. 
>>
>>

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

['Bill Hart' via julia-users]

I'll see if it is possible. Currently our code does not work at all with 
large chunks of the Julia commits in that interval. We had to work around 
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, 
> --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 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 
> > likely that it can be fixed? It's really killing our development cycle. 
> > 
> > Bill. 
>
>

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

['Bill Hart' via julia-users]

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 understanding was that ... in a method argument forms a tuple, but I 
> don't know how to dispatch on that. Self-contained example: 
>
> import Base.getindex 
>
> type Foo{T <: Tuple} 
> end 
>
> getindex{T}(f::Foo{T}, index::T...) = 42 
>
> Foo{Tuple{Int}}()[9] ## won't match 
>
> ## workaround with wrapper: 
>
> _mygetindex{T}(f::Foo{T}, index::T) = 42 
> mygetindex{T}(f::Foo{T}, index...) = _mygetindex(f, index) 
>
> mygetindex(Foo{Tuple{Int}}(), 9) 
>
> Is it possible to make it work without a wrapper in current Julia? 
>
> Best, 
>
> Tamas 
>

[julia-users] Test code taking forever to start

['Bill Hart' via julia-users]

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 
likely that it can be fixed? It's really killing our development cycle.

Bill.

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

['Bill Hart' via julia-users]

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, '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
> >
> > sig_table = [x.sig for x in methods(Base.promote_rule)]
> >
> > V = Tuple{typeof(Base.promote_rule),Type{Mymod.mytype},Type{Int64}}
> >
> > V in sig_table # returns true!!
> >
> > for s in sig_table # prints yes
> >if V == s
> >   println("yes")
> >end
> > end
> >
> > for s in sig_table # prints nothing
> >if s == V
> >   println("yes")
> >end
> > end
> >
> > Can someone explain what the difference between == and "in" is. For
> > example, why shouldn't == be symmetric? And why should "in" tell me
> > something is in an array that is clearly not in there?
> in() relies on isequal() for some collections like dicts. But that's
> not the issue here, you're not even calling that function. It looks
> like there's a bug with ==. Please file an issue on GitHub about it.
>
> BTW, you can use === with types instead, and it seems to work fine
> here.
>
>
> Regards
>
>
> > Metaquestion: what is the easiest way of checking if a promote_rule
> > already exists? We have to create promote_rules at run time in
> > response to user input (so it can't be done statically) and now the
> > Julia compiler complains with pages of warnings because we are
> > overwriting existing promote rules (actually, we are, harmlessly). We
> > want to get rid of the warnings and the easiest way is to check if
> > that promote rule already exists before defining it again.
> >
> > We can't just do method_exists because it always returns true for
> > promote_rule, with any signature. So we need to check whether the
> > promote rule with the precise signature we want to define already
> > exists. For example
> >
> > method_exists(Base.promote_rule, Tuple{Type{Mymod.mytype},
> > Type{Int}})
> >
> > returns true.
> >
> > Bill.
>

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

['Bill Hart' via julia-users]

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}, ::Type{$T2}) = 
$par_type))
  end


So it's supposed to check if the promote_rule already returns its first 
argument and omit defining the promote_rule if it does.

Here is what it prints:

Nemo.Poly{Nemo.fmpz_poly} Nemo.fmpz Union{} true
WARNING: Method definition promote_rule(Type{Nemo.Poly{Nemo.fmpz_poly}}, 
Type{Nemo.fmpz}) in module Nemo at 
/home/wbhart/.julia/v0.5/Nemo/src/generic/Poly.jl:1754 overwritten at 
/home/wbhart/.julia/v0.5/Nemo/src/generic/Poly.jl:1754.

In other words, it tells me that the promote_rule does not exist, so goes 
ahead and creates it, and then tells me that it already exists.

This is clearly totally broken. I strongly suspect this is a bug related to 
the equality problem I outlined in the first post.

Bill.

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

['Bill Hart' via julia-users]

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_n where
it would need to know n in order to do this. It can't know that just from
the type, however.

This assumption that you can always construct a value of a given type just
from the type information is littered throughout Julia. It causes a lot of
problems for us. For example, the matrix code in Julia everywhere wants to
be able to do zero(T) where T is some type. But again, you can't construct
the zero object of integers modulo n without knowing n, and you certainly
don't want n in the type (or the compiler will dispatch on n, which would
make multimodular algorithms takes hours instead of a second as everything
was recompiled over and over for every modulus n you used).

The matrix code should be using zero(v) where v is a value of type T. You
can always construct one value of a given type from another value of that
type.

I don't know a solution for the convert problem. Probably it has to be the
same, i.e. you need to convert one value to the type of another value. I'm
sure no one is going to like that solution, but I don't see any other way
around it.

Bill.

On 22 March 2016 at 23:39, Jeffrey Sarnoff 
wrote:

> That is not supposed 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:
>>
>> 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 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
>>> 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 there is no
>>> promote_rule for the supplied types. But this doesn't work in Nemo.
>>>
>>> Even though we have an explicit promote rule (not generated at runtime)
>>>
>>> Base.promote_rule{T <: Integer}(::Type{fmpz_poly}, ::Type{T}) = fmpz_poly
>>>
>>> a call to Base.promote_rule(fmpz_poly, Int) inside Nemo returns Union{}.
>>>
>>> However, such a call from the REPL results in Nemo.fmpz_poly.
>>>
>>> There's clearly something broken here. I need to be able to explicitly
>>> tell if the promote_rules that I create actually exist or not. At present I
>>> only seem to be able to do that from the REPL, not inside my actual module.
>>>
>>> Bill.
>>>
>>

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

['Bill Hart' via julia-users]

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 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 
> 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 there is no 
> promote_rule for the supplied types. But this doesn't work in Nemo.
>
> Even though we have an explicit promote rule (not generated at runtime)
>
> Base.promote_rule{T <: Integer}(::Type{fmpz_poly}, ::Type{T}) = fmpz_poly
>
> a call to Base.promote_rule(fmpz_poly, Int) inside Nemo returns Union{}.
>
> However, such a call from the REPL results in Nemo.fmpz_poly.
>
> There's clearly something broken here. I need to be able to explicitly 
> tell if the promote_rules that I create actually exist or not. At present I 
> only seem to be able to do that from the REPL, not inside my actual module.
>
> Bill.
>

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

['Bill Hart' via julia-users]

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 there is no 
promote_rule for the supplied types. But this doesn't work in Nemo.

Even though we have an explicit promote rule (not generated at runtime)

Base.promote_rule{T <: Integer}(::Type{fmpz_poly}, ::Type{T}) = fmpz_poly

a call to Base.promote_rule(fmpz_poly, Int) inside Nemo returns Union{}.

However, such a call from the REPL results in Nemo.fmpz_poly.

There's clearly something broken here. I need to be able to explicitly tell 
if the promote_rules that I create actually exist or not. At present I only 
seem to be able to do that from the REPL, not inside my actual module.

Bill.

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

['Bill Hart' via julia-users]

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_type in completely the wrong way elsewhere 
in Nemo. So that's already something we have to fix. But that just explains 
why the last solution didn't work, not the other problems we are having.

It certainly doesn't explain why any of the earlier solutions to my 
metaquestion don't work, including yours Jeffrey.

So, to summarise the questions so far:

1) Why does Julia define a completely generic promote_rule for any two 
types?

2) Why is  "V == s" but "s != V" in the first post of mine above?

3) Why does the function promote_rule_exists that I defined above work fine 
at the REPL but not when I place it inside the Nemo module? (Though it does 
seem to work fine when I place it in a module created in the REPL, even 
when using parameterised types and eval as we are in Nemo.)

4) What is the approved way to tell if a promote_rule exists (so that we 
can avoid getting duplicate definition warnings from the compiler)? By 
"tell if it exists", I mean tell if there is a proper promote_rule for that 
signature, not just that Julia defines a completely generic promote_rule or 
some other quasi-promote_rule exists.

Bill.

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

['Bill Hart' via julia-users]

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 module created in the REPL, it behaves as 
expected.

So instead I tried the following:

julia> using Nemo

julia> promote_type(Nemo.Poly{Nemo.Residue{Nemo.fmpq_poly}}, Nemo.fmpq_poly)
Nemo.PolyElem{T}

julia> @which promote_type(Nemo.Poly{Nemo.Residue{Nemo.fmpq_poly}}, 
Nemo.fmpq_poly)
promote_type{T,S}(::Type{T}, ::Type{S}) at promotion.jl:121

Why is Julia defining a completely generic promote_rule for types it knows 
nothing about, and giving a completely invalid type as the result?

I thought of just defining:

function promote_rule_exists{T1, T2}(::Type{T1}, ::Type{T2})
   return promote_type(T1, T2) == T1
end

Since all the promote_rules we create are of this form. But then it returns 
true for cases where promote_type(T1, T2) is not T1!! This seems to happen 
in cases where promote_type returns a parameterised type rather than a 
concrete type (and thus presumably is coming from a promote_rule defined by 
Julia.

But it doesn't consistently return true in such a case, making it 
impossible to work around the problem.

Basically it looks to me like there is a large amount of breakage in 
current master. Either that or promote_type, promote_rule, == and "in" are 
now all so counterintuitive that I don't understand how they work. Or I 
suppose I could just be being very stupid about something.

Bill.

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

['Bill Hart' via julia-users]

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{Nemo.fmpz_poly}, Nemo.fmpz)

after the relevant promote rule has been created, e.g. by

using Nemo
R, x = PolynomialRing(ZZ, "x")
S, y = PolynomialRing(R, "y")

one of the side-effects of which is to create the relevant promote_rule, 
the function returns false.

However, if I create the promote_rule_exists function in the REPL and call 
it instead, it returns true.

I have no idea why it would return a different value depending whether it 
is inside a module or not.

Any ideas?

Bill.



On Tuesday, 22 March 2016 20:03:49 UTC+1, Jeffrey Sarnoff wrote:
>
> This 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 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 in sig_table # returns true!!
>>
>> for s in sig_table # prints yes
>>if V == s
>>   println("yes")
>>end
>> end
>>
>> for s in sig_table # prints nothing
>>if s == V
>>   println("yes")
>>end
>> end
>>
>> Can someone explain what the difference between == and "in" is. For 
>> example, why shouldn't == be symmetric? And why should "in" tell me 
>> something is in an array that is clearly not in there?
>>
>> Metaquestion: what is the easiest way of checking if a promote_rule 
>> already exists? We have to create promote_rules at run time in response to 
>> user input (so it can't be done statically) and now the Julia compiler 
>> complains with pages of warnings because we are overwriting existing 
>> promote rules (actually, we are, harmlessly). We want to get rid of the 
>> warnings and the easiest way is to check if that promote rule already 
>> exists before defining it again.
>>
>> We can't just do method_exists because it always returns true for 
>> promote_rule, with any signature. So we need to check whether the promote 
>> rule with the precise signature we want to define already exists. For 
>> example
>>
>> method_exists(Base.promote_rule, Tuple{Type{Mymod.mytype}, Type{Int}})
>>
>> returns true.
>>
>> Bill.
>>
>

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

['Bill Hart' via julia-users]

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 in sig_table # returns true!!

for s in sig_table # prints yes
   if V == s
  println("yes")
   end
end

for s in sig_table # prints nothing
   if s == V
  println("yes")
   end
end

Can someone explain what the difference between == and "in" is. For 
example, why shouldn't == be symmetric? And why should "in" tell me 
something is in an array that is clearly not in there?

Metaquestion: what is the easiest way of checking if a promote_rule already 
exists? We have to create promote_rules at run time in response to user 
input (so it can't be done statically) and now the Julia compiler complains 
with pages of warnings because we are overwriting existing promote rules 
(actually, we are, harmlessly). We want to get rid of the warnings and the 
easiest way is to check if that promote rule already exists before defining 
it again.

We can't just do method_exists because it always returns true for 
promote_rule, with any signature. So we need to check whether the promote 
rule with the precise signature we want to define already exists. For 
example

method_exists(Base.promote_rule, Tuple{Type{Mymod.mytype}, Type{Int}})

returns true.

Bill.

[julia-users] Performance regression with latest master?

['Bill Hart' via julia-users]

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}

function +(a::ZZ, b::Int)
   r = ZZ(length(a))
   ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int, Int), 
r, a, 3, b)
   return r
end

function doit(n::Int)
   a = ZZ(3)
   a[1] = rand(UInt)
   a[2] = rand(UInt)
   a[3] = rand(UInt)

   for s = 1:n
  a += s
   end

   return a
end

doit(10)


I realise the example is not mathematically very meaningful, nor is it the 
best way to compute anything in particular. It's cut down from a larger 
example to illustrate the performance regression clearly.

Bill.

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

['Bill Hart' via julia-users]

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 Carlsson 
wrote:

> Can you bisect to the right commit?
>
> You can create a julia script that runs "exit(1)" on a bad commit and "
> exit(0)" on a good commit.
>
> Then create a bisect_runner.sh with
>
> make || exit 125
>
> 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 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}
>>
>> function +(a::ZZ, b::Int)
>>r = ZZ(length(a))
>>ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int,
>> Int), r, a, 3, b)
>>return r
>> end
>>
>> function doit(n::Int)
>>a = ZZ(3)
>>a[1] = rand(UInt)
>>a[2] = rand(UInt)
>>a[3] = rand(UInt)
>>
>>for s = 1:n
>>   a += s
>>end
>>
>>return a
>> end
>>
>> doit(10)
>>
>>
>> I realise the example is not mathematically very meaningful, nor is it
>> the best way to compute anything in particular. It's cut down from a larger
>> example to illustrate the performance regression clearly.
>>
>> Bill.
>>
>>