[julia-users] Re: Help on performance issues

[Patrick Useldinger]

Jason,

very interesting reading. I'll have to go through that a few more times 
though ;-)

If anybody is interested, I ended up coding the whole Kakuro solver in 
Python 3. It will take 0.1 seconds (measured on my not-so-recent laptop) 
for a regular 9x9 puzzle, or 0.5 seconds for the one I included in the 
source code, classified "diabolical". Most of the time is actually spend in 
deepcopy() so you can probably get a big speedup if you create a specific 
deepcopy() function.

Given the fact that I need minutes to enter the puzzle in text format, this 
was good enough and I stopped optimisations right there. 

I ran it with pypy3 which also features a JIT compiler. The execution times 
were worse than with stock CPython for obvious reasons.

The code is available at https://github.com/uselpa/kakuro-solver.

Thanks to all of you for your feedback! An awesome community is what makes 
an excellent language a great language.

Regards,
Patrick

Re: [julia-users] Re: Re: are array slices views in 0.4?

[Tomas Lycken]

There’s no way this transition is going to be smooth without work from 
package devs to ensure compatibility anyway, but recent history (e.g. the 
Tuplocalypse) shows that packages recover quite rapidly due to the 
automated testing done by PkgEval.jl. Thus, packages with decent test 
suites will probably get a heads-up that this change is breaking for them 
long before 0.5.0 is released.

Given that these changes potentially allow quite extreme performance gains 
in many applications, I find it unlikely that package devs won’t want to 
spend some time fixing any bugs this behavior change introduces, but for 
those that just want to pin their package down before fixing it, they can 
say julia 0.4 0.4 or similar in their REQUIRE.jl, and not even allow 
installation on 0.5 (until they fix the problems, change the REQUIRE.jl and 
tag a new version). Note that many (most?) packages won’t even need this - 
package testing on the master branch will reveal to devs whether a package 
even needs touch-up or not.

I used from __future__ import print at the top of my python scripts for a 
long time, so I’m entirely in favor of something like that. However, I 
guess the behavior needs to be implemented and done in the master branch of 
Julia before we know exactly how to mimic it in a package (if it’s even 
possible).

// T

On Tuesday, November 3, 2015 at 7:41:17 AM UTC+1, Christoph Ortner wrote:

Why not do this via Compat.jl ?
> C
>
> On Tuesday, 3 November 2015 04:28:44 UTC, David Anthoff wrote:
>>
>> No, Compat generall ports the new syntax back to old versions. What I'm 
>> suggesting is quite different, namely that in julia 0.5 if you just use 
>> `[]` for slicing without anything else, you generate a warning, and then 
>> you have to opt-in to the NEW syntax. 
>>
>> > -Original Message- 
>> > From: julia...@googlegroups.com [mailto:julia- 
>> > us...@googlegroups.com] On Behalf Of Eric Forgy 
>> > Sent: Monday, November 2, 2015 3:30 PM 
>> > To: julia-users  
>> > Subject: RE: [julia-users] Re: Re: are array slices views in 0.4? 
>> > 
>> > Hi David, 
>> > 
>> > I'm not an expert, i.e. I've never used it, but your idea "using 
>> OldArrays" 
>> > sounds exactly like the purpose of Compat.jl, which I believe is the 
>> > compatibility module referred to. 
>> > 
>> > Have a look and good luck: 
>> > 
>> > https://github.com/JuliaLang/Compat.jl 
>>
> ​

[julia-users] Re: obtain T from Ptr{T} at runtime

[Gunnar Farnebäck]

julia> eltype(Ptr{Float64})
Float64

Den tisdag 3 november 2015 kl. 07:51:43 UTC+1 skrev Petr Hlavenka:
>
> Hi,
> is there a way to obtain a type T from a Ptr{T}, e.g. get UInt32 from 
> Ptr{UInt32}.
>
> I'm trying to fix NIDAQ for 0.4 (tupplecalypse)
>
> This is needed if I have a signature of a function (demonstration example 
> from base, in real NIDAQ package there is huge C header processed by 
> Clang.jl)
>
> cfunction = getfield(Base.dSFMT,:dsfmt_fill_array_close1_open2!)
> signature = cfunction.env.defs.sig
> pt = signature.types[2]
> out> Ptr{Float64}
>
> how to obtain the Float64 base type from Ptr{T} to construct the 
> appropriate array to pass into the function?
>
> Petr
>
>
>

[julia-users] obtain T from Ptr{T} at runtime

[Petr Hlavenka]

Hi,
is there a way to obtain a type T from a Ptr{T}, e.g. get UInt32 from 
Ptr{UInt32}.

I'm trying to fix NIDAQ for 0.4 (tupplecalypse)

This is needed if I have a signature of a function (demonstration example 
from base, in real NIDAQ package there is huge C header processed by 
Clang.jl)

cfunction = getfield(Base.dSFMT,:dsfmt_fill_array_close1_open2!)
signature = cfunction.env.defs.sig
pt = signature.types[2]
out> Ptr{Float64}

how to obtain the Float64 base type from Ptr{T} to construct the 
appropriate array to pass into the function?

Petr

Re: [julia-users] Re: Re: are array slices views in 0.4?

[Christoph Ortner]

Why not do this via Compat.jl ?
C

On Tuesday, 3 November 2015 04:28:44 UTC, David Anthoff wrote:
>
> No, Compat generall ports the new syntax back to old versions. What I'm 
> suggesting is quite different, namely that in julia 0.5 if you just use 
> `[]` for slicing without anything else, you generate a warning, and then 
> you have to opt-in to the NEW syntax. 
>
> > -Original Message- 
> > From: julia...@googlegroups.com  [mailto:julia- 
>  
> > us...@googlegroups.com ] On Behalf Of Eric Forgy 
> > Sent: Monday, November 2, 2015 3:30 PM 
> > To: julia-users > 
> > Subject: RE: [julia-users] Re: Re: are array slices views in 0.4? 
> > 
> > Hi David, 
> > 
> > I'm not an expert, i.e. I've never used it, but your idea "using 
> OldArrays" 
> > sounds exactly like the purpose of Compat.jl, which I believe is the 
> > compatibility module referred to. 
> > 
> > Have a look and good luck: 
> > 
> > https://github.com/JuliaLang/Compat.jl 
>

[julia-users] error: haskey of NULL PyObject ?

[Tony Kelman]

Does running Pkg.build() change anything?

[julia-users] Re: Help on performance issues

[Jason Merrill]

I decided to write a blog post based on the Kakuro puzzle solver problem 
from this thread:

http://squishythinking.com/2015/11/02/optimizing-kakuro-in-julia/

On Wednesday, October 21, 2015 at 7:08:35 PM UTC-4, Jason Merrill wrote:
>
> I got interested in trying to optimize this problem even further. Here are 
> the results:
>
> https://gist.github.com/jwmerrill/5b364d1887f40f889142
>
> I was able to get the benchmark down to a few microseconds (or ~100 
> microseconds if you count the time to build a look up table). Either way, 
> it's a pretty good improvement over 1+ seconds :-)
>
> The main trick is to represent a set of digits 1-9 as a binary integer. 
> There are only 2^9=512 such sets, so you can pack any of them into an 
> Int16. Then you can precompute the sum of each set and store those in a 
> look up table, so that finding the ways to decompose a given number is just 
> a table lookup.
>
> I think this is a pretty nice example of how Julia's dispatch system let 
> you have complex views and operations over a very simple data structure (in 
> this case, a single integer), with essentially 0 overhead.
>
> On Monday, October 19, 2015 at 7:39:03 AM UTC-4, Patrick Useldinger wrote:
>>
>> Hello
>> true but no summand may appear twice, and only numbers 1 to 9 may be 
>> used. For example, (10, 3) yields
>>
>> Array[Int16[2,3,5],Int16[1,4,5],Int16[1,3,6],Int16[1,2,7]]
>>
>> Regards,
>> -Patrick
>>
>

Re: [julia-users] Anaconda Python

[Isaiah Norton]

>
>  This is a bit of an attitude issue that got me "off".  The matplotlib
> maintainers have no such obligation.


Neither does Anaconda. Please stop, this whole discussion is ridiculous,
especially the "forking" nonsense. Conda will update their Matplotlib
version in good time. Dealing with large dependency graphs of binary
dependencies is a thankless pain in the ass [1].

Keep in mind that they are giving all of this away *for free*.

[1] (seriously, unless you've actually built Python and the whole SciPy
binary dependency stack from scratch on Windows, you have absolutely no
business writing philosophical rants about any of this)

On Mon, Nov 2, 2015 at 11:24 PM,  wrote:

> Thanks for the follow-up.  Again, I understand the convenience benefit of
> the self-contained conda.jl Python.  My concern is about where it leads
> practically.  Sorry to bring up the ideology stuff.  YMMV.
>
> As a practical matter, if Continuum were much faster to post updates to
> their repo at Anaconda.com this might be less of a problem.  On the conda
> group, someone requested a more upgraded matplotlib (this was from some
> time ago and the requester wanted 1.4) and the Continuum reply was that the
> matplotlib maintainers were free to also post their latest to what was then
> called Binstar.com.  This is a bit of an attitude issue that got me "off".
> The matplotlib maintainers have no such obligation.  They have a master
> branch on their github repo and they release to PyPi.  If Continuum wants
> to create their own binary as a service, of course they may--but it's on
> them to do so.
>
> There is now a bug in 1.4.3 with Numpy 1.10 that results in this message:
>
> FutureWarning: elementwise comparison failed; returning scalar instead,
> but in the future will perform elementwise comparison
>
> This was fixed by matplotlib 1.5.0 about 2 weeks ago (along with other
> things of course).  Not that long ago and a little bit of a lag as mutual
> dependencies get their issues sorted out isn't unreasonable.  But, they
> have and the master branch is fully released.
>
> This is hard for Julia and I was too harsh.  With large dependencies there
> is no totally easy way out.  Until a week ago I was happily using
> versions of Python I downloaded myself.  PyCall was finding them and all
> was good.  I ran into one annoying bug after upgrading matplotlib (first
> chart figure cannot be closed by code) so I was trying to sort that out.
> Never figured out what broke.  So, I switched to the conda.jl approach and
> moved on.  And then there was the latest... ...which lead to my post.
>

RE: [julia-users] Anaconda Python

[Tony Kelman]

They are working on it, and making pretty good progress. See 
http://numpy-discussion.10968.n7.nabble.com/numpy-1-11-0-dev0-windows-wheels-compiled-with-mingwpy-available-td41422.html,
 especially Nathaniel Smith's explanation of some of the technical issues about 
upstreaming. Someone has to fork something to make this stuff work. Numpy devs 
forked MinGW-w64 GCC, MSYS2 has a fork of CPython that builds with stock 
mingw-w64, etc.

[julia-users] errors with sun grid engine (SGE)

[Garrett Jenkinson]

Can someone help me figure out how to get julia 0.4 working on my SGE 
computing cluster? I tried ClusterMangers, but it throws a lot of errors 
(that I list below). For what it is worth, I had it working a long time ago 
in julia 0.3 on this cluster, but I have deleted that installation and 
really want to utilize the benefits of 0.4.

   
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-unknown-linux-gnu

julia> using ClusterManagers
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl:3
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl:3
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl:8
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl:8
WARNING: Union(args...) is deprecated, use Union{args...} instead.
 in depwarn at deprecated.jl:73
 in call at deprecated.jl:50
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in require at ./loading.jl:243
while loading 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl, in 
expression starting on line 14
WARNING: Union(args...) is deprecated, use Union{args...} instead.
 in depwarn at deprecated.jl:73
 in call at deprecated.jl:50
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in require at ./loading.jl:243
while loading 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl, in 
expression starting on line 70

julia> ClusterManagers.addprocs_sge(5)
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near no file:0
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near no file:0
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near no file:0
WARNING: src::AbstractCmd |> dest::AbstractCmd is deprecated, use 
pipeline(src,dest) instead.
 in depwarn at deprecated.jl:73
 in |> at deprecated.jl:50
 in launch at 
/home/student/wjenkin6/.julia/v0.4/ClusterManagers/src/qsub.jl:30
 in anonymous at task.jl:63
while loading no file, in expression starting on line 0
Unable to read script file because of error: error opening : No such file 
or directory
batch queue not available (could not run qsub)
0-element Array{Int64,1}

Here is my package status list:

julia> Pkg.status()
7 required packages:
 - Bio   0.1.0
 - ClusterManagers   0.0.5
 - FastaIO   0.1.4
 - Gadfly0.3.18
 - HDF5  0.5.6
 - JLD   0.5.6
 - NLopt 0.2.3
45 additional packages:
 - ArrayViews0.6.4
 - BinDeps   0.3.19
 - Blosc 0.1.4
 - BufferedStreams   0.0.2
 - Calculus  0.1.14
 - Codecs0.1.5
 - ColorTypes0.2.0
 - Colors0.6.0
 - Compat0.7.7
 - Compose   0.3.18
 - Contour   0.0.8
 - DataArrays0.2.19
 - DataFrames0.6.10
 - DataStructures0.3.13
 - Dates 0.4.4
 - Distances 0.2.1
 - Distributions 0.8.7
 - Docile0.5.19
 - DualNumbers   0.1.5
 - FileIO0.0.3
 - FixedPointNumbers 0.1.0
 - GZip  0.2.18
 - Grid  0.4.0
 - Hexagons  0.0.4
 - ImmutableArrays   0.0.11
 - IntervalTrees 0.0.4
 - Iterators 0.1.9
 - JSON  0.5.0
 - KernelDensity 0.1.2
 - Libz  0.0.2
 - Loess 0.0.5
 - MathProgBase  0.3.19
 - NaNMath   0.1.1
 - Optim 0.4.4
 - PDMats0.3.6
 - Reexport  0.0.3
 - SHA   0.1.2
 - Showoff   0.0.6
 - SortingAlgorithms 0.0.6
 - StatsBase 0.7.4
 - StatsFuns 0.2.0
 - Switch0.0.1
 - URIParser

RE: [julia-users] Re: Re: are array slices views in 0.4?

[David Anthoff]

No, Compat generall ports the new syntax back to old versions. What I'm 
suggesting is quite different, namely that in julia 0.5 if you just use `[]` 
for slicing without anything else, you generate a warning, and then you have to 
opt-in to the NEW syntax.

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Eric Forgy
> Sent: Monday, November 2, 2015 3:30 PM
> To: julia-users 
> Subject: RE: [julia-users] Re: Re: are array slices views in 0.4?
> 
> Hi David,
> 
> I'm not an expert, i.e. I've never used it, but your idea "using OldArrays"
> sounds exactly like the purpose of Compat.jl, which I believe is the
> compatibility module referred to.
> 
> Have a look and good luck:
> 
> https://github.com/JuliaLang/Compat.jl

RE: [julia-users] Anaconda Python

[David Anthoff]

Ah, interesting, I had been under the impression that numpy etc had windows 
wheels already, but clearly they are still working on that...

I don't see the appeal of WinPython over conda, then you just swap out one 
alternative distribution over another one.

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Tony Kelman
> Sent: Monday, November 2, 2015 5:30 PM
> To: julia-users 
> Subject: RE: [julia-users] Anaconda Python
> 
> That site isn't very specific on platform differences. I only see mac wheels 
> at
> https://pypi.python.org/pypi/numpy
> 
> WinPython might work, though it's quite a large bundle and wouldn't help on
> mac or linux. It could be complemented by a pip interface package for unices,
> but if you want something to happen in open source the best way is by doing
> it. Create the pieces you think are missing.

Re: [julia-users] Anaconda Python

[lewis]

You'd have to use home-brew or PSF Python for Mac (with pip).  As I pointed 
out, I don't know what to suggest for different versions of Linux as the 
package manager repo's for the various distros are often very out of date.

On Monday, November 2, 2015 at 5:29:44 PM UTC-8, Tony Kelman wrote:
>
> That site isn't very specific on platform differences. I only see mac 
> wheels at https://pypi.python.org/pypi/numpy
>
> WinPython might work, though it's quite a large bundle and wouldn't help 
> on mac or linux. It could be complemented by a pip interface package for 
> unices, but if you want something to happen in open source the best way is 
> by doing it. Create the pieces you think are missing.
>

Re: [julia-users] Anaconda Python

[lewis]

Thanks for the follow-up.  Again, I understand the convenience benefit of 
the self-contained conda.jl Python.  My concern is about where it leads 
practically.  Sorry to bring up the ideology stuff.  YMMV.

As a practical matter, if Continuum were much faster to post updates to 
their repo at Anaconda.com this might be less of a problem.  On the conda 
group, someone requested a more upgraded matplotlib (this was from some 
time ago and the requester wanted 1.4) and the Continuum reply was that the 
matplotlib maintainers were free to also post their latest to what was then 
called Binstar.com.  This is a bit of an attitude issue that got me "off". 
 The matplotlib maintainers have no such obligation.  They have a master 
branch on their github repo and they release to PyPi.  If Continuum wants 
to create their own binary as a service, of course they may--but it's on 
them to do so.

There is now a bug in 1.4.3 with Numpy 1.10 that results in this message:

FutureWarning: elementwise comparison failed; returning scalar instead, but 
in the future will perform elementwise comparison

This was fixed by matplotlib 1.5.0 about 2 weeks ago (along with other 
things of course).  Not that long ago and a little bit of a lag as mutual 
dependencies get their issues sorted out isn't unreasonable.  But, they 
have and the master branch is fully released.

This is hard for Julia and I was too harsh.  With large dependencies there 
is no totally easy way out.  Until a week ago I was happily using 
versions of Python I downloaded myself.  PyCall was finding them and all 
was good.  I ran into one annoying bug after upgrading matplotlib (first 
chart figure cannot be closed by code) so I was trying to sort that out. 
 Never figured out what broke.  So, I switched to the conda.jl approach and 
moved on.  And then there was the latest... ...which lead to my post.

RE: [julia-users] Anaconda Python

[Tony Kelman]

That site isn't very specific on platform differences. I only see mac wheels at 
https://pypi.python.org/pypi/numpy

WinPython might work, though it's quite a large bundle and wouldn't help on mac 
or linux. It could be complemented by a pip interface package for unices, but 
if you want something to happen in open source the best way is by doing it. 
Create the pieces you think are missing.

Re: [julia-users] Re: installing julia via cygwin

[tony]

You just need the embedded copy of portable git to be in place and on julia's 
path before cygwin's git. The installer is the fewest steps to make sure that's 
set up properly.



On Mon, Nov 2, 2015 at 5:02 PM -0800, "digxx"  wrote:
So basically you mean I have to change the way julia0.4 wants to shell out?
Telling him somehow to shell out to cygwin and not git via cygwin?

Re: [julia-users] Re: installing julia via cygwin

[digxx]

So basically you mean I have to change the way julia0.4 wants to shell out? 
Telling him somehow to shell out to cygwin and not git via cygwin?

Re: [julia-users] Re: installing julia via cygwin

[tony]

That created an installer, you need to run the installer to get a build of 
julia with everything in place for Pkg to work properly. There are manual ways 
of avoiding this step but it's a bit messy.




On Mon, Nov 2, 2015 at 4:59 PM -0800, "digxx"  wrote:
Again Thx for you answer: But I dont quite get what you mean.
I havent run this win-extras binary-dist though I just did. But it didnt
change anything :-/
I have some executable in my Julia folder now: julia-0.4.1-pre-x86_64.exe
Run it from shell by ./julia-0.4.1-pre-x86_64.exe will tell me:

-bash: ./julia-0.4.1-pre-x86_64.exe: Permission denied
Did you mean sth else?

Am Dienstag, 3. November 2015 00:25:31 UTC+1 schrieb Tony Kelman:

> Julia 0.4 and earlier shell out to command line git for Pkg. If you
> haven't run `make win-extras binary-dist` then run the generated installer,
> then when you run Julia in cygwin it is trying to call cygwin's git which
> does not work.
>
>
>
> On Mon, Nov 2, 2015 at 3:13 PM -0800, "digxx"  > wrote:
>
> @Tony: Yeah I knew that, though the actual command Seth proposed ./xxx is
> what I was looking for:  ./ for executables I didnt know :-(
> So now it seems to load in cygwin but when trying the Package thing I get
> this:
>
> julia> Pkg.status()
>
> INFO: Initializing package repository C:\cygwin64\home\Diger\.julia\v0.4
>
> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
>
> error: could not lock config file
> C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git/config: No
> such file or directory
>
> ERROR: failed process: Process(`git
> '--work-tree=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA'
> '--git-dir=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git'
> config remote.origin.url git://github.com/JuliaLang/METADATA.jl`
> , ProcessExited(255)) [255]
>
> in pipeline_error at process.jl:555
>
>
> So is there a write problem?
>
>
>
>
>
>
>

Re: [julia-users] Re: installing julia via cygwin

[digxx]

Again Thx for you answer: But I dont quite get what you mean.
I havent run this win-extras binary-dist though I just did. But it didnt 
change anything :-/
I have some executable in my Julia folder now: julia-0.4.1-pre-x86_64.exe
Run it from shell by ./julia-0.4.1-pre-x86_64.exe will tell me:

-bash: ./julia-0.4.1-pre-x86_64.exe: Permission denied
Did you mean sth else?

Am Dienstag, 3. November 2015 00:25:31 UTC+1 schrieb Tony Kelman:

> Julia 0.4 and earlier shell out to command line git for Pkg. If you 
> haven't run `make win-extras binary-dist` then run the generated installer, 
> then when you run Julia in cygwin it is trying to call cygwin's git which 
> does not work.
>
>
>
> On Mon, Nov 2, 2015 at 3:13 PM -0800, "digxx"  > wrote:
>
> @Tony: Yeah I knew that, though the actual command Seth proposed ./xxx is 
> what I was looking for:  ./ for executables I didnt know :-(
> So now it seems to load in cygwin but when trying the Package thing I get 
> this:
>
> julia> Pkg.status()
>
> INFO: Initializing package repository C:\cygwin64\home\Diger\.julia\v0.4
>
> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
>
> error: could not lock config file 
> C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git/config: No 
> such file or directory
>
> ERROR: failed process: Process(`git 
> '--work-tree=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA' 
> '--git-dir=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git' 
> config remote.origin.url git://github.com/JuliaLang/METADATA.jl` 
> , ProcessExited(255)) [255]
>
> in pipeline_error at process.jl:555
>
>
> So is there a write problem?
>
>
>
>
>
>
>

RE: [julia-users] Anaconda Python

[David Anthoff]

I think there are wheels for all of these: http://pythonwheels.com/

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Tony Kelman
> Sent: Monday, November 2, 2015 4:47 PM
> To: julia-users 
> Subject: RE: [julia-users] Anaconda Python
> 
> There still aren't Windows wheels for numpy, scipy, or matplotlib on PyPI are
> there? You can't build SciPy from source on Windows in a way that works
> with python.org MSVC python without needing either the Intel compilers, or
> a custom patched build of mingw-w64 that only Carl Kleffner knows how to
> use.

RE: [julia-users] Anaconda Python

[Tony Kelman]

There still aren't Windows wheels for numpy, scipy, or matplotlib on PyPI are 
there? You can't build SciPy from source on Windows in a way that works with 
python.org MSVC python without needing either the Intel compilers, or a custom 
patched build of mingw-w64 that only Carl Kleffner knows how to use.

RE: [julia-users] Anaconda Python

[David Anthoff]

I looked into a non-conda solution when I tried to integrate a python setup 
into IJulia's setup (the effort was finally superseded by the Conda.jl package).

pip had come a long way and would have worked for the case. I also think that 
wheels pretty much solve the binary distribution problem for packages on 
windows that had probably prompted the creation of conda in the first place.

The thing that never really worked was a private (portable) minimal python 
installation that didn't register itself into the system. I discussed that with 
the python devs on their mailing list and the general response was "that is 
just not something that is supported, it might work, or not". There are two 
issues around this: 1) you need to get the binaries into a directory on the 
users machine and 2) you need to be sure that when you start python.exe from 
that private directory, it ONLY loads things from this private python 
installation, and doesn't go out to load/modify stuff from/in any system 
installed python.

For 1), I ended up installing the windows binaries, then zipping up the python 
directory, hosting that on sourceforge, and then downloading and extracting 
that in the builds.jl script. Everything worked, but obviously this is not a 
solid way to handle this, i.e. to host my own binaries of python. I asked on 
the python-dev list whether there was any chance that python.org might just 
host a zip file like this, and they said no (at least for the time being).

For 2), I think the python devs think that this is not guaranteed at all by the 
current python.exe. In my own testing, everything worked, but I certainly 
didn't test all corner cases. I doubt that conda does any better, my guess is 
that they also are just lucky that everything works (but I might be wrong, 
maybe their fork is more extensive than I know).

So, I think the main blocking thing right now is that there doesn't exist a 
"minimal portable python" distribution, that just is a zip that has python and 
pip in it.

Cheers,
David

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Tony Kelman
> Sent: Monday, November 2, 2015 1:23 PM
> To: julia-users 
> Subject: [julia-users] Anaconda Python
> 
> Forks are good. The pure Python ecosystem and core language developers
> have left package management and distribution in a very broken state for
> the scientific stack for way too long, and Continuum had to come in and fix
> the situation themselves. They did so, users followed, and they even
> released the result as open source under a compatible license. The rest of
> the python ecosystem has demonstrated unmitigated tone deafness to the
> requirements of the scientific ecosystem by not learning from and adopting
> more of the way conda does things.
> 
> Does winpython have a minimal core and a binary-only package management
> system on top of it? Do they have binaries for the likes of scipy, matplotlib,
> jupyter etc that work with pycall and ijulia? We can consider supporting it 
> if it
> works, but if it doesn't work as well as Conda we shouldn't endorse it.
> Working software is what matters to users, more than ideology.
> 
> If someone wants to fork Julia or its package management, we would
> welcome the brainstorming of ideas and as long as the license of any new
> additions remains MIT, we can incorporate the improvements. Most forkers
> would rather fold their improvements back upstream, eventually, especially
> with large fast-moving projects. Look at what happened with io.js and
> node.js over the last year. Python-dev should have done the same, but they
> didn't.

[julia-users] Re: Anaconda Python

[J Luis]

> Does winpython have a minimal core and a binary-only package management 
> system on top of it? Do they have binaries for the likes of scipy, 
> matplotlib, jupyter etc that work with pycall and ijulia?
>

Not very experimented with Python by WinPython seams perfect for me. No 
install, no nothing. Just add it to path ... when need. Everything at hand 
with its own package manager or pip or easy_install. Multiple bitage 
pythons can leave side by side, works fine with Julia. "What else"? 

RE: [julia-users] Re: Re: are array slices views in 0.4?

[Eric Forgy]

Hi David,

I'm not an expert, i.e. I've never used it, but your idea "using OldArrays" 
sounds exactly like the purpose of Compat.jl, which I believe is the 
compatibility module referred to.

Have a look and good luck:

https://github.com/JuliaLang/Compat.jl

Re: [julia-users] Re: installing julia via cygwin

[tony]

Julia 0.4 and earlier shell out to command line git for Pkg. If you haven't run 
`make win-extras binary-dist` then run the generated installer, then when you 
run Julia in cygwin it is trying to call cygwin's git which does not work.




On Mon, Nov 2, 2015 at 3:13 PM -0800, "digxx"  wrote:
@Tony: Yeah I knew that, though the actual command Seth proposed ./xxx is
what I was looking for:  ./ for executables I didnt know :-(
So now it seems to load in cygwin but when trying the Package thing I get
this:

julia> Pkg.status()

INFO: Initializing package repository C:\cygwin64\home\Diger\.julia\v0.4

INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl

error: could not lock config file
C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git/config: No
such file or directory

ERROR: failed process: Process(`git
'--work-tree=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA'
'--git-dir=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git'
config remote.origin.url git://github.com/JuliaLang/METADATA.jl`,
ProcessExited(255)) [255]

in pipeline_error at process.jl:555


So is there a write problem?

[julia-users] Re: Sundials question

[Gabriel Gellner]

If you use the C interface and not the simplified interface you can pass an 
array of parameters to your lhs function. I found the best way to figure 
out how is to look at the code for how they made the `cvode` function (in 
Sundials.jl) to see how the C functions are being called and then look at 
the C manual for Sundials to see how to pass the arrays, it is very 
similar. Without more info it is hard to tell you exactly how to do it with 
your given community type.


On Monday, 2 November 2015 09:14:12 UTC-8, Timothée Poisot wrote:
>
> Hi list 
>
> I have a question related to SunDials.jl 
>
> We are building a model for which we currently have a function that 
> takes in two objects of custom types (c::Community and p::Parameters). 
> We'd like to move the code to Sundials, but we're not sure about the 
> best way to do it. 
>
> Currently, we have a function dNdt(c::Community, p::Parameters), 
> returning an array of Float64 with the derivative, for every population 
> size (stored in c.N[1], c.N[2], ...). 
>
> Is there a way to pass additional arguments to the functions used in 
> Sundial? 
>
> t 
>
> -- 
> Timothée Poisot, PhD 
>
> Professeur adjoint 
> Département des sciences biologiques 
> Université de Montréal 
>
> phone  : 514 343-7691 
> web: http://poisotlab.io 
> twitter: @PoisotLab 
> meeting: https://tpoisot.youcanbook.me/ 
>
>

Re: [julia-users] Re: question about Hessian in ForwardDiff return InexactError()

[tony]

It might be a different kind of InexactError then. Try adding a @show on the 
rhs value, see what type it is. The array might need to be constructed in a way 
that it's capable of holding dual number element types.




On Mon, Nov 2, 2015 at 3:18 PM -0800,  wrote:
Hi Tony:

Thanks, but remember you asked.

Your first request is answered by

const  dsts = 2 # dim( state vector )

which is set in the main file that calls to PF_RE_AR1_outer_alt.jl

In PF_RE_AR1_outer_alt.jl, I set

 cs00V = eye(dsts)
cs00V[2,2] = sigu*sigu/(1.0 - rho1*rho1)   # this is the line at which
Julia responds with ERROR: LoadError: InexactError()

Note that sigu and rho1 are Float64 types.

If you want, I can send you the complete set of Julia files/functions
generating the problem in ForwardDiff.hessian.

Best,

Jim


On Monday, November 2, 2015 at 10:31:08 AM UTC-5, Tony Kelman wrote:
>
> Misread the part where you said dsts = 2. Can you post more of the code,
> exactly how is dsts getting passed to these lines?
>
>
> On Monday, November 2, 2015 at 7:28:56 AM UTC-8, Tony Kelman wrote:
>>
>> By "the destination array" I meant the line
>>
>>  cs00V = eye(dsts)
>>
>> If dsts is an integer element type there, then cs00V will also have an
>> integer element type. Try eye(size(dsts)...)
>>
>>
>> On Monday, November 2, 2015 at 5:32:54 AM UTC-8, james...@gmail.com
>> wrote:
>>>
>>> Hi Tony:
>>>
>>> Thanks for the suggestion.
>>>
>>> Unfortunately, the result is the same.
>>>
>>> I initialized/pre-allocated the destination array for the Hessian as
>>>
>>> hessh = zeros(nparm,nparm)
>>>
>>> Julia's reply from the call to
>>>
>>> hessh = ForwardDiff.hessian(PF_RE_AR1_outer_alt, parms)
>>>
>>> began with
>>>
>>>
>>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>>
>>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>>
>>> followed by the ERROR: LoadError: InexactError() statement.
>>>
>>> Jim
>>>
>>>
>>> On Sunday, November 1, 2015 at 11:35:16 PM UTC-5, Tony Kelman wrote:

 You probably need to initialize the destination array with a floating
 point, rather than integer, element type.
>>>
>>>

[julia-users] Re: question about Hessian in ForwardDiff return InexactError()

[jamesmnason]

Hi Tony:

Thanks, but remember you asked.

Your first request is answered by

const  dsts = 2 # dim( state vector )

which is set in the main file that calls to PF_RE_AR1_outer_alt.jl

In PF_RE_AR1_outer_alt.jl, I set

 cs00V = eye(dsts)
cs00V[2,2] = sigu*sigu/(1.0 - rho1*rho1)   # this is the line at which 
Julia responds with ERROR: LoadError: InexactError()

Note that sigu and rho1 are Float64 types.

If you want, I can send you the complete set of Julia files/functions 
generating the problem in ForwardDiff.hessian.

Best,

Jim


On Monday, November 2, 2015 at 10:31:08 AM UTC-5, Tony Kelman wrote:
>
> Misread the part where you said dsts = 2. Can you post more of the code, 
> exactly how is dsts getting passed to these lines?
>
>
> On Monday, November 2, 2015 at 7:28:56 AM UTC-8, Tony Kelman wrote:
>>
>> By "the destination array" I meant the line
>>
>>  cs00V = eye(dsts)
>>
>> If dsts is an integer element type there, then cs00V will also have an 
>> integer element type. Try eye(size(dsts)...)
>>
>>
>> On Monday, November 2, 2015 at 5:32:54 AM UTC-8, james...@gmail.com 
>> wrote:
>>>
>>> Hi Tony:
>>>
>>> Thanks for the suggestion.
>>>
>>> Unfortunately, the result is the same.
>>>
>>> I initialized/pre-allocated the destination array for the Hessian as
>>>
>>> hessh = zeros(nparm,nparm)
>>>
>>> Julia's reply from the call to
>>>
>>> hessh = ForwardDiff.hessian(PF_RE_AR1_outer_alt, parms)
>>>
>>> began with
>>>
>>>
>>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>>
>>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>>
>>> followed by the ERROR: LoadError: InexactError() statement.
>>>
>>> Jim
>>>
>>>
>>> On Sunday, November 1, 2015 at 11:35:16 PM UTC-5, Tony Kelman wrote:

 You probably need to initialize the destination array with a floating 
 point, rather than integer, element type.
>>>
>>>

[julia-users] Re: Anaconda Python

[Gabriel Gellner]

Oh man ... please keep supporting anaconda. As a windows user being stuck 
with easy_install haunts my dreams. Anaconda may be forkish, but at least 
windows is a first class citizen. So many open source projects make using 
Windows beyond painful.

On Monday, 2 November 2015 13:00:51 UTC-8, le...@neilson-levin.org wrote:
>
> 
> I don't think you should support Anaconda Python.  I realize it is 
> convenient.  Providing a sort of private copy of Python and its packages 
> makes sense.  It simplifies installation and maintenance of key Julia 
> dependencies for users.  I just don't think you should use Anaconda to do 
> it. 
>
> Anaconda is fork of Python, its package management, its primary package 
> repository, and many of the packages themselves.  Forks are BAD.  It 
> borders on a commercial lock-in or, at a minimum, a technical lock-in to 
> Anaconda.
>
> I am a commercial software guy by experience.  I made a living from 
> commercial software and find that to be completely honorable.  This is not 
> an anti-commercial rant.  It IS, on the other hand, an anti-fork rant.
>
> Python is a vibrant community.  Julia is a vibrant community on a very 
> nice trajectory.  May they both continue.  Rather than a philosophical 
> discussion of Continuum and various open source license types, lets think 
> about this from the standpoint of Julia.
>
> Would you like it if someone came along and forked all of Julia, 
> especially Pkg, and created forks of every package?   To do so would be 
> entirely compliant with the MIT open source license.  So, it would be legal 
> (not that license enforcement is common in the open source world).  But, 
> would it be DESIRABLE?  You've done a fine thing to rely largely on git and 
> github.
>
> Probably not.  Is it possible that someone proposing enhancements found 
> that their suggestions were rejected?  Well, that can happen.  Perhaps that 
> would lead to a fork.  But, if there was community endorsement of the 
> suggestions from some reasonable plurality of members and enhancements 
> could be made without injury to those preferring some other code path, it 
> would be reasonable to accommodate particularly if the proposers backed 
> their suggestions with effort--working code that could be integrated under 
> the conditions mentioned.  I depict this in a somewhat negative way, but my 
> point is to confirm that *contributing is better than forking*.
>
> Typically, it is easier--and less negative--than the scenario I depicted. 
>  There is a community.  Some leaders are very technically adept and have a 
> vision (e.g., Julia is not C, Python, R, or Java so it won't do things just 
> like those or other languages...) so they have some sway over final 
> inclusion decisions.  And these technical leaders do care what the 
> community suggests; are open to suggestions and contributions; occasionally 
> reject some input with transparent reasons (transparency may not convince 
> the proposer, but it is good for everyone to see the dialog and decisions); 
> and often accept suggestions--implementing the suggestions themselves or 
> accepting pull requests.  But, realistically the core team makes most of 
> the commits and carries most of the work.
>
> This is probably how we want it to work.  We probably don't want a fork of 
> Julia and hope to avoid it and we will see Julia grow and be enhanced--most 
> often on the path and vision of the founders and sometimes with the 
> contributions of others. In the spirt of "do unto others...", let's not 
> encourage a fork of Python.
>
> This would mean using Python releases of the Python Software Foundation 
> (PSF) and its package repository PyPI.  There will be some inconvenience. 
>  Perhaps not all of the Python "cousins" are enamored of Julia and aren't 
> eager to be helpful.  Or perhaps they are merely neutral and busy.  But, it 
> supports their community to endorse it.  Do unto others...   As a serious 
> practical matter, the communities are not distinct.  Many user-developers 
> do use both Julia and Python.  We'd like both communities to thrive.  I 
> think Continuum would probably concur with the broad sentiment, though not 
> with my personal opinion about using Anaconda as a Julia dependency.  
>
> This requires some deep thought.  Using Anaconda is certainly a near-term 
> convenience.   On Windows, it is possible to get most of the same benefits 
> from the less commercially oriented release WinPython.  On Mac, ...from 
> Homebrew, which is also quite non-commercial.  On Linux, ...well, that is 
> another kettle of fragmentation--and probably better to rely on PSF than a 
> bunch of package repositories.  Consider:  how do you want the Julia 
> community to develop?  How does the Julia community overlap with the Python 
> community (and to a lesser extent the R community)?  How do choices affect 
> the healthy, long-term evolution of an open source community?
> 
>
> I've left out discussion of how open source commu

[julia-users] Path to module in Atom IDE

[Eric Forgy]

Hmm...

Try these two things:

1.) Make sure Julia is running, e.g, cnrl+' (cmd+') and type 1+1 or something 
into the console. I think Julia has to be running to see the "Julia Client" 
commands.

2.) When you're sure Julia is running, make sure the file is active and not the 
console, i.e. click into the file and away from the console, and then try 
command pallette -> Julia Client: Work in file folder. If you're in the 
console, when you try to set "Work in file folder", it will complain that it is 
not a directory (or something).

Hope this helps.

Re: [julia-users] Re: installing julia via cygwin

[digxx]

@Tony: Yeah I knew that, though the actual command Seth proposed ./xxx is 
what I was looking for:  ./ for executables I didnt know :-(
So now it seems to load in cygwin but when trying the Package thing I get 
this:

julia> Pkg.status()

INFO: Initializing package repository C:\cygwin64\home\Diger\.julia\v0.4

INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl

error: could not lock config file 
C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git/config: No 
such file or directory

ERROR: failed process: Process(`git 
'--work-tree=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA' 
'--git-dir=C:\cygwin64\home\Diger\.julia\v0.4\jul51F3.tmp\METADATA\.git' 
config remote.origin.url git://github.com/JuliaLang/METADATA.jl`, 
ProcessExited(255)) [255]

in pipeline_error at process.jl:555


So is there a write problem?

RE: [julia-users] Re: Re: are array slices views in 0.4?

[David Anthoff]

I’m not sure what you refer to by “Compatability module”.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Christoph Ortner
Sent: Monday, November 2, 2015 1:09 PM
To: julia-users 
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

How is this different from the Compatibility module?

 

Christoph

On Monday, 2 November 2015 20:44:38 UTC, David Anthoff wrote:

Yes, I like that kind of idea. How about specifically:

 

- If a package does nothing, every use of `[]` for slicing throws a deprecation 
warning on julia 0.5

- If you use `using OldArrays` the deprecation goes away, and you get the julia 
0.4 behavior (maybe this options is actually not even needed, or maybe it 
should even not exist, not sure)

- If you use `using NewArrays` you get the new slicing behavior on julia 0.5 

 

And then in julia 0.6 `[]` just gives the new behavior by default, i.e. the 
`using NewArrays` is no longer needed. In julia 0.6 `using NewArrays` could 
actually show a deprecation warning that this using statement is no longer 
needed.

 

From: julia...@googlegroups.com   
[mailto:julia...@googlegroups.com  ] On Behalf Of Cedric St-Jean
Sent: Monday, November 2, 2015 12:00 PM
To: julia-users  >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

Python's

from __future__ import division


was a reasonable way of transitioning. I would use it for slicing if it was 
available already.

On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote:

The `using OldArrays` approach would essentially require an opt-in from 
everyone before julia 0.5 is released, i.e. an opt-in action from all package 
devs, right? The danger there seems that I update to julia 0.5, but now I have 
no clue whether all the packages I rely on have either a) made sure that they 
are compatible with the new array handling or b) have added the `using 
OldArrays` approach so that they can delay dealing with the issue. The nice 
thing with the current deprecation handling is that as a user of a package that 
has failed to deal with these things, I get alerted to issues automatically and 
know that something might need my attention. But a `using OldArrays` approach 
doesn’t seem to do that, in the end it still just means that the semantics of 
`[]` are changed without the typical deprecation sequence of using multiple 
versions for such a change.

 

From: julia...@googlegroups.com   
[mailto:julia...@googlegroups.com] On Behalf Of Stefan Karpinski
Sent: Tuesday, October 27, 2015 7:43 AM
To: Julia Users mailto:julia...@googlegroups.com> >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

Yes, I'm concerned about this as well. I'm sure we'll come up with something. 
Maybe allow using the old behavior during a transitional period with something 
like `using OldArrays` and then when you've gotten the chance to double check 
your code, you can delete that line and move to the new behavior. We'll have to 
see.

 

On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff mailto:ant...@berkeley.edu> > wrote:

Are there plans to throw deprecation warnings in julia 0.5 whenever one slices 
an array with [], and then reuse the [] syntax to return views in julia 0.6? 
That would be approach that is consistent with previous changes of 
functionality, right?

 

I’m very much in favor of the new design, but I’m very worried about the 
transition. There seems an enormous potential for subtle bugs to go undetected 
for a long time… the tuple change was nicely phased in, as were any other 
breaking changes since I’ve used julia (since 0.2), i.e. I always had the 
impression that as long as I just fixed all depreciation warnings when a new 
version came out, I would be good. But my understanding right now for the array 
change is that the behavior of slicing with [] will change drastically, with 
essentially no indicator where in my code I might run into trouble, right?

 

From: julia...@googlegroups.com   
[mailto:julia...@googlegroups.com] On Behalf Of Stefan Karpinski
Sent: Monday, October 26, 2015 12:05 PM
To: Julia Users mailto:julia...@googlegroups.com> >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner mailto:christop...@gmail.com> > wrote:

Fabian - Many thanks for your comments. This was very helpful.

 

(c) if I want to write code now that shouldn't break with 0.5, what should I do?


I think when you need a copy, just surround your getindex with a copy function. 
(e.g. copy(x[:,10]) instead of x[:,10]). 

 

But this would lead me to make two copies. I was more interested in seeing 
whether there is a guideline on how to write code now so it doesn't have to be 
rewritten for 0.5.

 

There will be a solution in the Compat package once this change is made. It 
will probably consist of having a replacement for getindex that creat

Re: [julia-users] Immutable storage

[Yichao Yu]

On Mon, Nov 2, 2015 at 3:17 PM, Cedric St-Jean  wrote:
> immutable Bird
>height::Float32
> end
>
> immutable Cage
>bird::Bird
> end
>
> function catch(some_bird::Bird, some_animal)
> new_bird = Bird(10.2)
> c = Cage(b)
> ...
> new_bird
> end
>
> catch(b,b)
>

Assuming by boxed you mean gc allocation (which is the only time it is
stored as a tagged value in memory).

> 1. When are immutable values boxed? Is new_bird a boxed value? What about
> `some_bird` and `some_animal`?

They are boxed when it is necessary. For pretty much all the three
variables you have above, there isn't enough info to tell whether they
will be boxed.
With the current typeinf/codegen, they will be boxed if the variable
is not type stable.

> 2. I assume that Cage.bird is stored as an immediate value (no pointer).
> Isn't there a risk with large composite types that this is memory and CPU
> inefficient, having to copy it everywhere? Is that a consideration in

No, codegen will figure out the best way to pass them around.

> choosing immutable vs. type?

No.

In general, boxing is not what you need to think specifically about.
(You'll probably want to worry about type stability.)

>
> Cédric

[julia-users] error: haskey of NULL PyObject ?

[jda]

I am new to Julia and don't know how to deal with most error messages. 
 Before I could just do 

using PyPlot

and everything worked fine on my windows machine (Julia 0.4.0 repl).  Then 
it broke (possibly due to Pkg.update()? I don't remember at this point.). 
 So I looked up a few things and now it seems that I must do

ENV["PYTHON"]="";
using PyPlot

in order to avoid errors on the "using" line.  But now I have new errors. 
 The command

pcolormesh(rand(20,20))

now gives me the error:

ERROR: ArgumentError: haskey of NULL PyObject
  in pcolormesh at ...\PyPlot.jl:457

All of the above is really strange because on my other mac computer I can 
just do:  using PyPlot; pcolormesh(rand(20,20)); and it's all working fine. 
 I am sure there is something fundamental I am missing about how this works 
on a windows computer, especially since the errors are a new occurrence and 
it was plotting fine recently on the windows.

[julia-users] Re: Anyone know how to get help with Jupyter?

[Sheehan Olver]

I'm a fan of

@show 5+5
@show 5+6
@show 5+7

because then its easy to associate the input and the output

On Sunday, November 1, 2015 at 8:14:31 AM UTC+11, Cedric St-Jean wrote:
>
> Does
>
> display(5+5)
> display(5+6)
> display(5+7)
>
> work for you? I find it useful for displaying multiple plots/images.
>
> On Saturday, October 31, 2015 at 4:57:01 PM UTC-4, Daniel Carrera wrote:
>>
>> I apologize for asking a non-Julia question here, but for the life of me 
>> I cannot figure out how to contact the people working on Jupyter so I can 
>> ask them a question:
>>
>> http://jupyter.org/index.html
>>
>> I know that some Julia people are involved in Jupyter, so I hope somebody 
>> here knows. I am feeling a bit frustrated right now. You would think that 
>> they would have a visible link somewhere that told you how you can contact 
>> them. You would imagine that they would have a mailing list, or an IRC 
>> channel. I'm guessing that they probably do. But I just cannot find that 
>> information on their website, and I REALLY tried to find it.
>>
>> Does anyone know how I can ask a question to the Jupyter people? I just 
>> want to ask them how I can have multiple lines of output from the same 
>> cell. Back when it was called IPython you used to be able to write a single 
>> cell with several instructions, like:
>>
>> -
>> 5+5
>> 5+6
>> 5+7
>> -
>>
>> All that in the same cell. And then output would be 10, 11, 12 (all in 
>> different lines). Now I only get "12" -- the last line of output.
>>
>> So I am trying to find the Jupyter users mailing list, or IRC channel, or 
>> whatever they use so I can ask my question. I would be grateful for any 
>> pointers.
>>
>> Cheers,
>> Daniel.
>>
>

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

[Kristoffer Carlsson]

I put up a small illustration of how the Ball Tree recursively divides the 
points. Nothing fancy but I thought the plots where kinda 
cute. 
https://github.com/KristofferC/NearestNeighbors.jl/blob/master/examples/balltree_illustration.ipynb

On Monday, November 2, 2015 at 10:21:02 PM UTC+1, Kristoffer Carlsson wrote:
>
> If it is a metric (obeys triangle inequality and the other good stuff) 
> then the Ball Tree should be able to handle it.
>
> If you create an issue with some more information I could probably 
> implement it.
>
> I want to also fix so that it should be easier to use your own arbitrary 
> metrics but I might have to do some PRs towards Distances for that to 
> happen.
>
> On Monday, November 2, 2015 at 12:25:59 PM UTC+1, Christoph Ortner wrote:
>>
>>
>> Hi Kristoffer,
>>
>> Could one one possibly use this with a metric that effectively defines a 
>> torus? E.g., suppose my points are in (0,L) x (0, L) x (0, L) but a point x 
>> is identify with all other points x + Le1, x+Le2, etc .?
>>
>> Christoph
>>
>

[julia-users] Anaconda Python

[Tony Kelman]

Forks are good. The pure Python ecosystem and core language developers have 
left package management and distribution in a very broken state for the 
scientific stack for way too long, and Continuum had to come in and fix the 
situation themselves. They did so, users followed, and they even released the 
result as open source under a compatible license. The rest of the python 
ecosystem has demonstrated unmitigated tone deafness to the requirements of the 
scientific ecosystem by not learning from and adopting more of the way conda 
does things.

Does winpython have a minimal core and a binary-only package management system 
on top of it? Do they have binaries for the likes of scipy, matplotlib, jupyter 
etc that work with pycall and ijulia? We can consider supporting it if it 
works, but if it doesn't work as well as Conda we shouldn't endorse it. Working 
software is what matters to users, more than ideology.

If someone wants to fork Julia or its package management, we would welcome the 
brainstorming of ideas and as long as the license of any new additions remains 
MIT, we can incorporate the improvements. Most forkers would rather fold their 
improvements back upstream, eventually, especially with large fast-moving 
projects. Look at what happened with io.js and node.js over the last year. 
Python-dev should have done the same, but they didn't.

[julia-users] Re: Anaconda Python

[lewis]

Somewhat more pointedly, this text banner greets on booting Continuum 
Python:

Anaconda is brought to you by Continuum Analytics.

Please check out: http://continuum.io/thanks and https://anaconda.org


It sort of rubs me the wrong way...

Re: [julia-users] Re: Anaconda Python

[Steve Kelly]

Conda.jl is a community contribution as a package, not part of the core
language. Likewise it is not strictly required. It does make using PyCall
significantly more convenient. Maybe you might consider making a Pip.jl
package that does something similar?

On Mon, Nov 2, 2015 at 4:18 PM,  wrote:

> Yes.
>
> The practical problem is out of date packages and subtle incompatibilities
> between "system" installs of Python and the private one.
>
> I now use the "Julia" Python as my 2.7 version and a system Python from
> PSF for 3.5.
>
> Conda is limited to Python 3.4 and matplotlib 1.4.3.
>
> Conda et al will always lag a bit with the risk of more incompatibilities
> creeping in.
>

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

[Kristoffer Carlsson]

If it is a metric (obeys triangle inequality and the other good stuff) then 
the Ball Tree should be able to handle it.

If you create an issue with some more information I could probably 
implement it.

I want to also fix so that it should be easier to use your own arbitrary 
metrics but I might have to do some PRs towards Distances for that to 
happen.

On Monday, November 2, 2015 at 12:25:59 PM UTC+1, Christoph Ortner wrote:
>
>
> Hi Kristoffer,
>
> Could one one possibly use this with a metric that effectively defines a 
> torus? E.g., suppose my points are in (0,L) x (0, L) x (0, L) but a point x 
> is identify with all other points x + Le1, x+Le2, etc .?
>
> Christoph
>

[julia-users] Re: Anaconda Python

[lewis]

Yes.

The practical problem is out of date packages and subtle incompatibilities 
between "system" installs of Python and the private one.

I now use the "Julia" Python as my 2.7 version and a system Python from PSF 
for 3.5.

Conda is limited to Python 3.4 and matplotlib 1.4.3.

Conda et al will always lag a bit with the risk of more incompatibilities 
creeping in.

Re: [julia-users] Anaconda Python

[Steve Kelly]

The context is not clear. Is this regarding Conda.jl?

On Mon, Nov 2, 2015 at 4:00 PM,  wrote:

> 
> I don't think you should support Anaconda Python.  I realize it is
> convenient.  Providing a sort of private copy of Python and its packages
> makes sense.  It simplifies installation and maintenance of key Julia
> dependencies for users.  I just don't think you should use Anaconda to do
> it.
>
> Anaconda is fork of Python, its package management, its primary package
> repository, and many of the packages themselves.  Forks are BAD.  It
> borders on a commercial lock-in or, at a minimum, a technical lock-in to
> Anaconda.
>
> I am a commercial software guy by experience.  I made a living from
> commercial software and find that to be completely honorable.  This is not
> an anti-commercial rant.  It IS, on the other hand, an anti-fork rant.
>
> Python is a vibrant community.  Julia is a vibrant community on a very
> nice trajectory.  May they both continue.  Rather than a philosophical
> discussion of Continuum and various open source license types, lets think
> about this from the standpoint of Julia.
>
> Would you like it if someone came along and forked all of Julia,
> especially Pkg, and created forks of every package?   To do so would be
> entirely compliant with the MIT open source license.  So, it would be legal
> (not that license enforcement is common in the open source world).  But,
> would it be DESIRABLE?  You've done a fine thing to rely largely on git and
> github.
>
> Probably not.  Is it possible that someone proposing enhancements found
> that their suggestions were rejected?  Well, that can happen.  Perhaps that
> would lead to a fork.  But, if there was community endorsement of the
> suggestions from some reasonable plurality of members and enhancements
> could be made without injury to those preferring some other code path, it
> would be reasonable to accommodate particularly if the proposers backed
> their suggestions with effort--working code that could be integrated under
> the conditions mentioned.  I depict this in a somewhat negative way, but my
> point is to confirm that *contributing is better than forking*.
>
> Typically, it is easier--and less negative--than the scenario I depicted.
> There is a community.  Some leaders are very technically adept and have a
> vision (e.g., Julia is not C, Python, R, or Java so it won't do things just
> like those or other languages...) so they have some sway over final
> inclusion decisions.  And these technical leaders do care what the
> community suggests; are open to suggestions and contributions; occasionally
> reject some input with transparent reasons (transparency may not convince
> the proposer, but it is good for everyone to see the dialog and decisions);
> and often accept suggestions--implementing the suggestions themselves or
> accepting pull requests.  But, realistically the core team makes most of
> the commits and carries most of the work.
>
> This is probably how we want it to work.  We probably don't want a fork of
> Julia and hope to avoid it and we will see Julia grow and be enhanced--most
> often on the path and vision of the founders and sometimes with the
> contributions of others. In the spirt of "do unto others...", let's not
> encourage a fork of Python.
>
> This would mean using Python releases of the Python Software Foundation
> (PSF) and its package repository PyPI.  There will be some inconvenience.
> Perhaps not all of the Python "cousins" are enamored of Julia and aren't
> eager to be helpful.  Or perhaps they are merely neutral and busy.  But, it
> supports their community to endorse it.  Do unto others...   As a serious
> practical matter, the communities are not distinct.  Many user-developers
> do use both Julia and Python.  We'd like both communities to thrive.  I
> think Continuum would probably concur with the broad sentiment, though not
> with my personal opinion about using Anaconda as a Julia dependency.
>
> This requires some deep thought.  Using Anaconda is certainly a near-term
> convenience.   On Windows, it is possible to get most of the same benefits
> from the less commercially oriented release WinPython.  On Mac, ...from
> Homebrew, which is also quite non-commercial.  On Linux, ...well, that is
> another kettle of fragmentation--and probably better to rely on PSF than a
> bunch of package repositories.  Consider:  how do you want the Julia
> community to develop?  How does the Julia community overlap with the Python
> community (and to a lesser extent the R community)?  How do choices affect
> the healthy, long-term evolution of an open source community?
> 
>
> I've left out discussion of how open source communities can attract
> commercial participants.  That is indeed beneficial.  Look to Cloudera's
> role in the Hadoop community for a good example of how this can work.
>

Re: [julia-users] Re: Re: are array slices views in 0.4?

[Christoph Ortner]

How is this different from the Compatibility module?

Christoph

On Monday, 2 November 2015 20:44:38 UTC, David Anthoff wrote:
>
> Yes, I like that kind of idea. How about specifically:
>
>  
>
> - If a package does nothing, every use of `[]` for slicing throws a 
> deprecation warning on julia 0.5
>
> - If you use `using OldArrays` the deprecation goes away, and you get the 
> julia 0.4 behavior (maybe this options is actually not even needed, or 
> maybe it should even not exist, not sure)
>
> - If you use `using NewArrays` you get the new slicing behavior on julia 
> 0.5 
>
>  
>
> And then in julia 0.6 `[]` just gives the new behavior by default, i.e. 
> the `using NewArrays` is no longer needed. In julia 0.6 `using NewArrays` 
> could actually show a deprecation warning that this using statement is no 
> longer needed.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Cedric St-Jean
> *Sent:* Monday, November 2, 2015 12:00 PM
> *To:* julia-users >
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>  
>
> Python's
>
> from __future__ import division
>
>
> was a reasonable way of transitioning. I would use it for slicing if it 
> was available already.
>
> On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote:
>
> The `using OldArrays` approach would essentially require an opt-in from 
> everyone before julia 0.5 is released, i.e. an opt-in action from all 
> package devs, right? The danger there seems that I update to julia 0.5, but 
> now I have no clue whether all the packages I rely on have either a) made 
> sure that they are compatible with the new array handling or b) have added 
> the `using OldArrays` approach so that they can delay dealing with the 
> issue. The nice thing with the current deprecation handling is that as a 
> user of a package that has failed to deal with these things, I get alerted 
> to issues automatically and know that something might need my attention. 
> But a `using OldArrays` approach doesn’t seem to do that, in the end it 
> still just means that the semantics of `[]` are changed without the typical 
> deprecation sequence of using multiple versions for such a change.
>
>  
>
> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
> Behalf Of *Stefan Karpinski
> *Sent:* Tuesday, October 27, 2015 7:43 AM
> *To:* Julia Users 
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>  
>
> Yes, I'm concerned about this as well. I'm sure we'll come up with 
> something. Maybe allow using the old behavior during a transitional period 
> with something like `using OldArrays` and then when you've gotten the 
> chance to double check your code, you can delete that line and move to the 
> new behavior. We'll have to see.
>
>  
>
> On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff  
> wrote:
>
> Are there plans to throw deprecation warnings in julia 0.5 whenever one 
> slices an array with [], and then reuse the [] syntax to return views in 
> julia 0.6? That would be approach that is consistent with previous changes 
> of functionality, right?
>
>  
>
> I’m very much in favor of the new design, but I’m very worried about the 
> transition. There seems an enormous potential for subtle bugs to go 
> undetected for a long time… the tuple change was nicely phased in, as were 
> any other breaking changes since I’ve used julia (since 0.2), i.e. I always 
> had the impression that as long as I just fixed all depreciation warnings 
> when a new version came out, I would be good. But my understanding right 
> now for the array change is that the behavior of slicing with [] will 
> change drastically, with essentially no indicator where in my code I might 
> run into trouble, right?
>
>  
>
> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
> Behalf Of *Stefan Karpinski
> *Sent:* Monday, October 26, 2015 12:05 PM
> *To:* Julia Users 
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>  
>
> On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner  
> wrote:
>
> Fabian - Many thanks for your comments. This was very helpful.
>
>  
>
> (c) if I want to write code now that shouldn't break with 0.5, what should 
> I do?
>
>
> I think when you need a copy, just surround your getindex with a copy 
> function. (e.g. copy(x[:,10]) instead of x[:,10]). 
>
>  
>
> But this would lead me to make two copies. I was more interested in seeing 
> whether there is a guideline on how to write code now so it doesn't have to 
> be rewritten for 0.5.
>
>  
>
> There will be a solution in the Compat package once this change is made. 
> It will probably consist of having a replacement for getindex that creates 
> a slice rather than a copy so that calling copy won't result in two copies. 
> I.e. it will backport the 0.5 behavior to earlier versions of Julia.
>
>  
>
> Regarding this change I am also more on the sceptical side. I would very 
> much pref

[julia-users] Anaconda Python

[lewis]

I don't think you should support Anaconda Python.  I realize it is 
convenient.  Providing a sort of private copy of Python and its packages 
makes sense.  It simplifies installation and maintenance of key Julia 
dependencies for users.  I just don't think you should use Anaconda to do 
it. 

Anaconda is fork of Python, its package management, its primary package 
repository, and many of the packages themselves.  Forks are BAD.  It 
borders on a commercial lock-in or, at a minimum, a technical lock-in to 
Anaconda.

I am a commercial software guy by experience.  I made a living from 
commercial software and find that to be completely honorable.  This is not 
an anti-commercial rant.  It IS, on the other hand, an anti-fork rant.

Python is a vibrant community.  Julia is a vibrant community on a very nice 
trajectory.  May they both continue.  Rather than a philosophical 
discussion of Continuum and various open source license types, lets think 
about this from the standpoint of Julia.

Would you like it if someone came along and forked all of Julia, especially 
Pkg, and created forks of every package?   To do so would be entirely 
compliant with the MIT open source license.  So, it would be legal (not 
that license enforcement is common in the open source world).  But, would 
it be DESIRABLE?  You've done a fine thing to rely largely on git and 
github.

Probably not.  Is it possible that someone proposing enhancements found 
that their suggestions were rejected?  Well, that can happen.  Perhaps that 
would lead to a fork.  But, if there was community endorsement of the 
suggestions from some reasonable plurality of members and enhancements 
could be made without injury to those preferring some other code path, it 
would be reasonable to accommodate particularly if the proposers backed 
their suggestions with effort--working code that could be integrated under 
the conditions mentioned.  I depict this in a somewhat negative way, but my 
point is to confirm that *contributing is better than forking*.

Typically, it is easier--and less negative--than the scenario I depicted. 
 There is a community.  Some leaders are very technically adept and have a 
vision (e.g., Julia is not C, Python, R, or Java so it won't do things just 
like those or other languages...) so they have some sway over final 
inclusion decisions.  And these technical leaders do care what the 
community suggests; are open to suggestions and contributions; occasionally 
reject some input with transparent reasons (transparency may not convince 
the proposer, but it is good for everyone to see the dialog and decisions); 
and often accept suggestions--implementing the suggestions themselves or 
accepting pull requests.  But, realistically the core team makes most of 
the commits and carries most of the work.

This is probably how we want it to work.  We probably don't want a fork of 
Julia and hope to avoid it and we will see Julia grow and be enhanced--most 
often on the path and vision of the founders and sometimes with the 
contributions of others. In the spirt of "do unto others...", let's not 
encourage a fork of Python.

This would mean using Python releases of the Python Software Foundation 
(PSF) and its package repository PyPI.  There will be some inconvenience. 
 Perhaps not all of the Python "cousins" are enamored of Julia and aren't 
eager to be helpful.  Or perhaps they are merely neutral and busy.  But, it 
supports their community to endorse it.  Do unto others...   As a serious 
practical matter, the communities are not distinct.  Many user-developers 
do use both Julia and Python.  We'd like both communities to thrive.  I 
think Continuum would probably concur with the broad sentiment, though not 
with my personal opinion about using Anaconda as a Julia dependency.  

This requires some deep thought.  Using Anaconda is certainly a near-term 
convenience.   On Windows, it is possible to get most of the same benefits 
from the less commercially oriented release WinPython.  On Mac, ...from 
Homebrew, which is also quite non-commercial.  On Linux, ...well, that is 
another kettle of fragmentation--and probably better to rely on PSF than a 
bunch of package repositories.  Consider:  how do you want the Julia 
community to develop?  How does the Julia community overlap with the Python 
community (and to a lesser extent the R community)?  How do choices affect 
the healthy, long-term evolution of an open source community?


I've left out discussion of how open source communities can attract 
commercial participants.  That is indeed beneficial.  Look to Cloudera's 
role in the Hadoop community for a good example of how this can work.

RE: [julia-users] Re: Re: are array slices views in 0.4?

[David Anthoff]

Yes, I like that kind of idea. How about specifically:

 

- If a package does nothing, every use of `[]` for slicing throws a deprecation 
warning on julia 0.5

- If you use `using OldArrays` the deprecation goes away, and you get the julia 
0.4 behavior (maybe this options is actually not even needed, or maybe it 
should even not exist, not sure)

- If you use `using NewArrays` you get the new slicing behavior on julia 0.5 

 

And then in julia 0.6 `[]` just gives the new behavior by default, i.e. the 
`using NewArrays` is no longer needed. In julia 0.6 `using NewArrays` could 
actually show a deprecation warning that this using statement is no longer 
needed.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Cedric St-Jean
Sent: Monday, November 2, 2015 12:00 PM
To: julia-users 
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

Python's

from __future__ import division


was a reasonable way of transitioning. I would use it for slicing if it was 
available already.

On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote:

The `using OldArrays` approach would essentially require an opt-in from 
everyone before julia 0.5 is released, i.e. an opt-in action from all package 
devs, right? The danger there seems that I update to julia 0.5, but now I have 
no clue whether all the packages I rely on have either a) made sure that they 
are compatible with the new array handling or b) have added the `using 
OldArrays` approach so that they can delay dealing with the issue. The nice 
thing with the current deprecation handling is that as a user of a package that 
has failed to deal with these things, I get alerted to issues automatically and 
know that something might need my attention. But a `using OldArrays` approach 
doesn’t seem to do that, in the end it still just means that the semantics of 
`[]` are changed without the typical deprecation sequence of using multiple 
versions for such a change.

 

From: julia...@googlegroups.com   
[mailto:julia...@googlegroups.com  ] On Behalf Of Stefan Karpinski
Sent: Tuesday, October 27, 2015 7:43 AM
To: Julia Users  >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

Yes, I'm concerned about this as well. I'm sure we'll come up with something. 
Maybe allow using the old behavior during a transitional period with something 
like `using OldArrays` and then when you've gotten the chance to double check 
your code, you can delete that line and move to the new behavior. We'll have to 
see.

 

On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff  > wrote:

Are there plans to throw deprecation warnings in julia 0.5 whenever one slices 
an array with [], and then reuse the [] syntax to return views in julia 0.6? 
That would be approach that is consistent with previous changes of 
functionality, right?

 

I’m very much in favor of the new design, but I’m very worried about the 
transition. There seems an enormous potential for subtle bugs to go undetected 
for a long time… the tuple change was nicely phased in, as were any other 
breaking changes since I’ve used julia (since 0.2), i.e. I always had the 
impression that as long as I just fixed all depreciation warnings when a new 
version came out, I would be good. But my understanding right now for the array 
change is that the behavior of slicing with [] will change drastically, with 
essentially no indicator where in my code I might run into trouble, right?

 

From: julia...@googlegroups.com   
[mailto:julia...@googlegroups.com  ] On Behalf Of Stefan Karpinski
Sent: Monday, October 26, 2015 12:05 PM
To: Julia Users  >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner  > wrote:

Fabian - Many thanks for your comments. This was very helpful.

 

(c) if I want to write code now that shouldn't break with 0.5, what should I do?


I think when you need a copy, just surround your getindex with a copy function. 
(e.g. copy(x[:,10]) instead of x[:,10]). 

 

But this would lead me to make two copies. I was more interested in seeing 
whether there is a guideline on how to write code now so it doesn't have to be 
rewritten for 0.5.

 

There will be a solution in the Compat package once this change is made. It 
will probably consist of having a replacement for getindex that creates a slice 
rather than a copy so that calling copy won't result in two copies. I.e. it 
will backport the 0.5 behavior to earlier versions of Julia.

 

Regarding this change I am also more on the sceptical side. I would very much 
prefer a copy-on-write like solution like Matlab and R provide, but I don't 
know if and how this would be possible to implement, so I don't raise my voice 
here. 
To me the main benefit of this change is that it drove the main developers to 
make array views much more performant and first class members of julia. As Tim 
Holy mentioned, the actual change seems to be be very

[julia-users] Re: Here is a new one...

[ggggg]

I see the same thing when using matplotlib (via Julia OR python) on OSX 
when using a GTK backend.

[julia-users] Re: Here is a new one...

[lewis]

Actually, it probably came from one of PyPlot, PyCall or dependencies 
within conda Python.

The first time, Julia crashed big time.  I reinstalled Julia and all 
packages.  Everything runs despite the deprecation warnings.

On Monday, November 2, 2015 at 12:09:23 PM UTC-8, le...@neilson-levin.org 
wrote:
>
> 2015-11-02 12:07:38.737 julia[34306:196259] setCanCycle: is deprecated.  
> Please use setCollectionBehavior instead
>
> 2015-11-02 12:07:38.747 julia[34306:196259] setCanCycle: is deprecated.  
> Please use setCollectionBehavior instead
>
>
> Huh?
>
>
> Probably came from MAT.
>

[julia-users] Immutable storage

[Cedric St-Jean]

immutable Bird
   height::Float32
end

immutable Cage
   bird::Bird
end

function catch(some_bird::Bird, some_animal)
new_bird = Bird(10.2)
c = Cage(b)
...
new_bird
end

catch(b,b)

1. When are immutable values boxed? Is new_bird a boxed value? What about 
`some_bird` and `some_animal`?
2. I assume that Cage.bird is stored as an immediate value (no pointer). 
Isn't there a risk with large composite types that this is memory and CPU 
inefficient, having to copy it everywhere? Is that a consideration in 
choosing immutable vs. type?

Cédric

[julia-users] Here is a new one...

[lewis]

2015-11-02 12:07:38.737 julia[34306:196259] setCanCycle: is deprecated.  
Please use setCollectionBehavior instead

2015-11-02 12:07:38.747 julia[34306:196259] setCanCycle: is deprecated.  
Please use setCollectionBehavior instead


Huh?


Probably came from MAT.

Re: [julia-users] Re: Re: are array slices views in 0.4?

[Cedric St-Jean]

Python's

from __future__ import division

was a reasonable way of transitioning. I would use it for slicing if it was 
available already.

On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote:
>
> The `using OldArrays` approach would essentially require an opt-in from 
> everyone before julia 0.5 is released, i.e. an opt-in action from all 
> package devs, right? The danger there seems that I update to julia 0.5, but 
> now I have no clue whether all the packages I rely on have either a) made 
> sure that they are compatible with the new array handling or b) have added 
> the `using OldArrays` approach so that they can delay dealing with the 
> issue. The nice thing with the current deprecation handling is that as a 
> user of a package that has failed to deal with these things, I get alerted 
> to issues automatically and know that something might need my attention. 
> But a `using OldArrays` approach doesn’t seem to do that, in the end it 
> still just means that the semantics of `[]` are changed without the typical 
> deprecation sequence of using multiple versions for such a change.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Stefan Karpinski
> *Sent:* Tuesday, October 27, 2015 7:43 AM
> *To:* Julia Users >
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>  
>
> Yes, I'm concerned about this as well. I'm sure we'll come up with 
> something. Maybe allow using the old behavior during a transitional period 
> with something like `using OldArrays` and then when you've gotten the 
> chance to double check your code, you can delete that line and move to the 
> new behavior. We'll have to see.
>
>  
>
> On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff  > wrote:
>
> Are there plans to throw deprecation warnings in julia 0.5 whenever one 
> slices an array with [], and then reuse the [] syntax to return views in 
> julia 0.6? That would be approach that is consistent with previous changes 
> of functionality, right?
>
>  
>
> I’m very much in favor of the new design, but I’m very worried about the 
> transition. There seems an enormous potential for subtle bugs to go 
> undetected for a long time… the tuple change was nicely phased in, as were 
> any other breaking changes since I’ve used julia (since 0.2), i.e. I always 
> had the impression that as long as I just fixed all depreciation warnings 
> when a new version came out, I would be good. But my understanding right 
> now for the array change is that the behavior of slicing with [] will 
> change drastically, with essentially no indicator where in my code I might 
> run into trouble, right?
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Stefan Karpinski
> *Sent:* Monday, October 26, 2015 12:05 PM
> *To:* Julia Users >
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>  
>
> On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner  > wrote:
>
> Fabian - Many thanks for your comments. This was very helpful.
>
>  
>
> (c) if I want to write code now that shouldn't break with 0.5, what should 
> I do?
>
>
> I think when you need a copy, just surround your getindex with a copy 
> function. (e.g. copy(x[:,10]) instead of x[:,10]). 
>
>  
>
> But this would lead me to make two copies. I was more interested in seeing 
> whether there is a guideline on how to write code now so it doesn't have to 
> be rewritten for 0.5.
>
>  
>
> There will be a solution in the Compat package once this change is made. 
> It will probably consist of having a replacement for getindex that creates 
> a slice rather than a copy so that calling copy won't result in two copies. 
> I.e. it will backport the 0.5 behavior to earlier versions of Julia.
>
>  
>
> Regarding this change I am also more on the sceptical side. I would very 
> much prefer a copy-on-write like solution like Matlab and R provide, but I 
> don't know if and how this would be possible to implement, so I don't raise 
> my voice here. 
> To me the main benefit of this change is that it drove the main developers 
> to make array views much more performant and first class members of julia. 
> As Tim Holy mentioned, the actual change seems to be be very small, but it 
> needed and still needs a lot of work to make it possible. 
>
>  
>
> My own scepticism comes from the idea that using immutable objects 
> throughout prevents bugs and one should only use mutable objects sparingly 
> (primarily for performance - but I thought it shouldn't be the default)
>
>  
>
> Copy-on-write is complex and leads to brittle performance properties that 
> cannot be reasoned about locally. The semantics of R and Matlab also 
> notoriously make it impossible to write efficient mutating functions – 
> people generally end up writing C extensions to do that.
>
>  
>
> It remains to be seen how this pans out, but keep in mind that C, C++, 
> Java, Fortran, Julia, Python, Ruby, etc. a

[julia-users] has anyone implemented minimax function approximation with BigFloats?

[Jeffrey Sarnoff]

Has anyone implemented minimax (or near minimax) function approximation 
over a given interval using BigFloats?

RE: [julia-users] Re: Re: are array slices views in 0.4?

[David Anthoff]

The `using OldArrays` approach would essentially require an opt-in from 
everyone before julia 0.5 is released, i.e. an opt-in action from all package 
devs, right? The danger there seems that I update to julia 0.5, but now I have 
no clue whether all the packages I rely on have either a) made sure that they 
are compatible with the new array handling or b) have added the `using 
OldArrays` approach so that they can delay dealing with the issue. The nice 
thing with the current deprecation handling is that as a user of a package that 
has failed to deal with these things, I get alerted to issues automatically and 
know that something might need my attention. But a `using OldArrays` approach 
doesn’t seem to do that, in the end it still just means that the semantics of 
`[]` are changed without the typical deprecation sequence of using multiple 
versions for such a change.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Stefan Karpinski
Sent: Tuesday, October 27, 2015 7:43 AM
To: Julia Users 
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

Yes, I'm concerned about this as well. I'm sure we'll come up with something. 
Maybe allow using the old behavior during a transitional period with something 
like `using OldArrays` and then when you've gotten the chance to double check 
your code, you can delete that line and move to the new behavior. We'll have to 
see.

 

On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Are there plans to throw deprecation warnings in julia 0.5 whenever one slices 
an array with [], and then reuse the [] syntax to return views in julia 0.6? 
That would be approach that is consistent with previous changes of 
functionality, right?

 

I’m very much in favor of the new design, but I’m very worried about the 
transition. There seems an enormous potential for subtle bugs to go undetected 
for a long time… the tuple change was nicely phased in, as were any other 
breaking changes since I’ve used julia (since 0.2), i.e. I always had the 
impression that as long as I just fixed all depreciation warnings when a new 
version came out, I would be good. But my understanding right now for the array 
change is that the behavior of slicing with [] will change drastically, with 
essentially no indicator where in my code I might run into trouble, right?

 

From: julia-users@googlegroups.com   
[mailto:julia-users@googlegroups.com  ] On 
Behalf Of Stefan Karpinski
Sent: Monday, October 26, 2015 12:05 PM
To: Julia Users mailto:julia-users@googlegroups.com> >
Subject: Re: [julia-users] Re: Re: are array slices views in 0.4?

 

On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner mailto:christophortn...@gmail.com> > wrote:

Fabian - Many thanks for your comments. This was very helpful.

 

(c) if I want to write code now that shouldn't break with 0.5, what should I do?


I think when you need a copy, just surround your getindex with a copy function. 
(e.g. copy(x[:,10]) instead of x[:,10]). 

 

But this would lead me to make two copies. I was more interested in seeing 
whether there is a guideline on how to write code now so it doesn't have to be 
rewritten for 0.5.

 

There will be a solution in the Compat package once this change is made. It 
will probably consist of having a replacement for getindex that creates a slice 
rather than a copy so that calling copy won't result in two copies. I.e. it 
will backport the 0.5 behavior to earlier versions of Julia.

 

Regarding this change I am also more on the sceptical side. I would very much 
prefer a copy-on-write like solution like Matlab and R provide, but I don't 
know if and how this would be possible to implement, so I don't raise my voice 
here. 
To me the main benefit of this change is that it drove the main developers to 
make array views much more performant and first class members of julia. As Tim 
Holy mentioned, the actual change seems to be be very small, but it needed and 
still needs a lot of work to make it possible. 

 

My own scepticism comes from the idea that using immutable objects throughout 
prevents bugs and one should only use mutable objects sparingly (primarily for 
performance - but I thought it shouldn't be the default)

 

Copy-on-write is complex and leads to brittle performance properties that 
cannot be reasoned about locally. The semantics of R and Matlab also 
notoriously make it impossible to write efficient mutating functions – people 
generally end up writing C extensions to do that.

 

It remains to be seen how this pans out, but keep in mind that C, C++, Java, 
Fortran, Julia, Python, Ruby, etc. all use mutable non-copy-on-write arrays 
everywhere and the world has not ended. Slices are a bit different, but NumPy, 
for example, creates views for slices and that works well in the SciPy 
ecosystem.

 

Philosophically, I think that returning

[julia-users] Path to module in Atom IDE

[Jon Norberg]

Hm, command palette just says "no match found" and even if I type it nothing 
changes.

Also, 1) if I have a file outside the module folder, can I load it somehow by 
providing a path? and 2) I quite like hydrogen, does it work the same way to 
load a module with Julia Client:  etc?

Re: [julia-users] Disable ESS-mode in emacs

[Ista Zahn]

Probably

 (add-to-list 'auto-mode-alist '("\\.jl\\'" . julia-mode))

should do it, though I'm not sure what the advantage would be.

Best,
Ista

On Mon, Nov 2, 2015 at 10:05 AM, Asbjørn Nilsen Riseth
 wrote:
> Hi emacs users,
>
> is there a way to disable ESS[Julia] in emacs? I'd like to use julia-mode
> without invoking ESS.
>
> ESS is installed globally on my system, but I don't have root rights to
> uninstall it.
>
>
>

[julia-users] Disable ESS-mode in emacs

[Asbjørn Nilsen Riseth]

Hi emacs users,

is there a way to disable ESS[Julia] in emacs? I'd like to use julia-mode 
without invoking ESS.

ESS is installed globally on my system, but I don't have root rights to 
uninstall it.

[julia-users] Re: Custom parsing of csv files in DataFrames

[Alex Mellnik]

I think it may be easiest to do this conversion in your own program after 
using readtable:

using DataFrames
#Make some canned data instead of reading from a table
df = DataFrame(datestring = ["12 Apr 1996", "05 Aug 2015"], moneystring = 
["\$12.75", "\$0.69"])
df[:date] = Date()
df[:money] = 0.0
dateformat = Dates.DateFormat("dd uuu ")
#map! and not map to preserve types
map!(d->DateTime(d,dateformat), df[:date], df[:datestring])
map!(x->float(lstrip(x,'$')), df[:money], df[:moneystring])
df

Re: [julia-users] why does @eval (a=b) set a global variable?

[Yichao Yu]

On Mon, Nov 2, 2015 at 12:52 PM, Deniz Yuret  wrote:
> If I have the following function:
>
> function foo(k,v)
> @eval ($(symbol(k))=$v)
> println(bar)
> end
>
>
> and I call it with:
>
> foo("bar", 5)
>
> then the global variable bar is set to 5 and the function prints 5.
>
> Is there any way to make @eval set a local variable inside foo instead?  (I
> tried prefixing the assignment with local which didn't work).

No. You can't construct arbitrary expressions at runtime and hope the
compiler to reason about what you constructed.

>
> thanks,
> deniz
>

[julia-users] Path to module in Atom IDE

[Eric Forgy]

>From the command pallete, try typing "Julia Client: Work in file folder". I 
>had the same problem and should have submitted a PR to the docs (and will if 
>no one beats me to it). Hope that helps.

[julia-users] why does @eval (a=b) set a global variable?

[Deniz Yuret]

If I have the following function:

function foo(k,v)
@eval ($(symbol(k))=$v)
println(bar)
end


and I call it with:

foo("bar", 5)

then the global variable bar is set to 5 and the function prints 5.

Is there any way to make @eval set a local variable inside foo instead?  (I 
tried prefixing the assignment with local which didn't work).

thanks,
deniz

Re: [julia-users] Why does setting ENV["TZ"] in the REPL behave differently?

[Stefan Karpinski]

That seems like the right way. We should probably have an official API for
that.

On Mon, Nov 2, 2015 at 10:44 AM, Josef Sachs  wrote:

> > On Mon, 2 Nov 2015 09:16:16 -0500, Josef Sachs said:
>
> > On Mon, 2 Nov 2015 08:56:05 -0500, Stefan Karpinski said:
> >> Seems like libc must not check the TZ variable each time, possibly
> >> due to performance considerations?
>
> > Right.  So is there a way that I can get the julia process to do a
> tzset()
> > after I do
> > ENV["TZ"] = whatever
> > ?
>
> Is this the right approach?  It seems to work.
>
> julia> tzset() = ccall(:tzset, Void, ())
> tzset (generic function with 1 method)
>
> julia> println(Libc.strftime("%Y-%m-%d %H:%M:%S",time()))
> 2015-11-02 10:40:39
>
> julia> tzset()
>
> julia> println(Libc.strftime("%Y-%m-%d %H:%M:%S",time()))
> 2015-11-02 15:40:48
>

[julia-users] Sundials question

[Timothée Poisot]

Hi list 

I have a question related to SunDials.jl

We are building a model for which we currently have a function that
takes in two objects of custom types (c::Community and p::Parameters).
We'd like to move the code to Sundials, but we're not sure about the
best way to do it. 

Currently, we have a function dNdt(c::Community, p::Parameters),
returning an array of Float64 with the derivative, for every population
size (stored in c.N[1], c.N[2], ...).

Is there a way to pass additional arguments to the functions used in
Sundial? 

t

-- 
Timothée Poisot, PhD

Professeur adjoint
Département des sciences biologiques
Université de Montréal

phone  : 514 343-7691
web: http://poisotlab.io
twitter: @PoisotLab
meeting: https://tpoisot.youcanbook.me/

[julia-users] Path to module in Atom IDE

[Jon Norberg]

Dear Julia users,

I just switched to atom IDE from Juno. I am puzzled by one thing. 

As in Juno, I first cd(myDir) to move to the directory where I have the files 
for the module I am developing. In Juno I could then just type using myModule 
to load it but in Atom I now only get


LoadError: ArgumentError: myModule not found in path
while loading In[5], in expression starting on line 1

in require at 
/Applications/Julia-0.4.app/Contents/Resources/julia/lib/julia/sys.dylibLoadError
LoadError: ArgumentError: myModule not found in path
while loading In[5], in expression starting on line 1

typing pwd() I get the right path and typing reader() I get a list of files 
that includes the files I am expecting.

Anyone have any idea what I am doing wrong?

Thanks, Jon

Re: [julia-users] Why does setting ENV["TZ"] in the REPL behave differently?

[Josef Sachs]

> On Mon, 2 Nov 2015 09:16:16 -0500, Josef Sachs said:

> On Mon, 2 Nov 2015 08:56:05 -0500, Stefan Karpinski said:
>> Seems like libc must not check the TZ variable each time, possibly
>> due to performance considerations?

> Right.  So is there a way that I can get the julia process to do a tzset()
> after I do
> ENV["TZ"] = whatever
> ?

Is this the right approach?  It seems to work.

julia> tzset() = ccall(:tzset, Void, ())
tzset (generic function with 1 method)

julia> println(Libc.strftime("%Y-%m-%d %H:%M:%S",time()))
2015-11-02 10:40:39

julia> tzset()

julia> println(Libc.strftime("%Y-%m-%d %H:%M:%S",time()))
2015-11-02 15:40:48

[julia-users] Re: question about Hessian in ForwardDiff return InexactError()

[Tony Kelman]

By "the destination array" I meant the line

 cs00V = eye(dsts)

If dsts is an integer element type there, then cs00V will also have an 
integer element type. Try eye(size(dsts)...)


On Monday, November 2, 2015 at 5:32:54 AM UTC-8, james...@gmail.com wrote:
>
> Hi Tony:
>
> Thanks for the suggestion.
>
> Unfortunately, the result is the same.
>
> I initialized/pre-allocated the destination array for the Hessian as
>
> hessh = zeros(nparm,nparm)
>
> Julia's reply from the call to
>
> hessh = ForwardDiff.hessian(PF_RE_AR1_outer_alt, parms)
>
> began with
>
>
> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>
> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>
> followed by the ERROR: LoadError: InexactError() statement.
>
> Jim
>
>
> On Sunday, November 1, 2015 at 11:35:16 PM UTC-5, Tony Kelman wrote:
>>
>> You probably need to initialize the destination array with a floating 
>> point, rather than integer, element type.
>
>

[julia-users] Re: question about Hessian in ForwardDiff return InexactError()

[Tony Kelman]

Misread the part where you said dsts = 2. Can you post more of the code, 
exactly how is dsts getting passed to these lines?


On Monday, November 2, 2015 at 7:28:56 AM UTC-8, Tony Kelman wrote:
>
> By "the destination array" I meant the line
>
>  cs00V = eye(dsts)
>
> If dsts is an integer element type there, then cs00V will also have an 
> integer element type. Try eye(size(dsts)...)
>
>
> On Monday, November 2, 2015 at 5:32:54 AM UTC-8, james...@gmail.com wrote:
>>
>> Hi Tony:
>>
>> Thanks for the suggestion.
>>
>> Unfortunately, the result is the same.
>>
>> I initialized/pre-allocated the destination array for the Hessian as
>>
>> hessh = zeros(nparm,nparm)
>>
>> Julia's reply from the call to
>>
>> hessh = ForwardDiff.hessian(PF_RE_AR1_outer_alt, parms)
>>
>> began with
>>
>>
>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>
>> ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
>>
>> followed by the ERROR: LoadError: InexactError() statement.
>>
>> Jim
>>
>>
>> On Sunday, November 1, 2015 at 11:35:16 PM UTC-5, Tony Kelman wrote:
>>>
>>> You probably need to initialize the destination array with a floating 
>>> point, rather than integer, element type.
>>
>>

[julia-users] SharedArray - intialisation by filename

[Matthew Pearce]

So I was poking around the SharedArray code, and saw that there was a 
method for creating one given a file name.

After some further playing about I've realised the file has to be in some 
sort of binary format (e.g. created by write(somefileio, somearray) ) due 
to something to do with mmapping in the background.

I can't see anything in the docs about this usage, and for me this is quite 
close to my use case.

My question is whether this feature is likely to disappear or not, given it 
isn't in the docs? 
Or whether documenting it has just not been gotten round to yet?

Much appreciated

Matthew

Re: [julia-users] Why does setting ENV["TZ"] in the REPL behave differently?

[Josef Sachs]

> On Mon, 2 Nov 2015 08:56:05 -0500, Stefan Karpinski said:

> Seems like libc must not check the TZ variable each time, possibly
> due to performance considerations?

Right.  So is there a way that I can get the julia process to do a tzset()
after I do
ENV["TZ"] = whatever
?

Re: [julia-users] help with a macro to stringize high precision floating point values

[David P. Sanders]

El lunes, 2 de noviembre de 2015, 7:58:17 (UTC-6), Stefan Karpinski 
escribió:
>
> I think we should probably make it possible to access the full string of 
> a numeric literal in a macro but that is a substantial change to the parser.
>

That would be great.

Off-topic: Jeffrey, will your Float128 library be correctly-rounded?
 

>
> On Monday, November 2, 2015, David P. Sanders  > wrote:
>
>>
>>
>> El lunes, 2 de noviembre de 2015, 6:35:46 (UTC-6), Milan Bouchet-Valat 
>> escribió:
>>>
>>> Le lundi 02 novembre 2015 à 00:58 -0800, Jeffrey Sarnoff a écrit : 
>>> > I have many values like 
>>> >  0.6584871727288045313850172023417636020375045372547107712468813403 
>>> > that come from Maple and I would like to avoid doing this by 
>>> > copy/paste for each one: 
>>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 
>>> > 5372547107712468813403")) 
>>> > 
>>> > I tried writing a macro that would put quotes around the value and 
>>> > then affix the rest -- without good result. 
>>> > julia>@fromMaple 
>>> > 0.6584871727288045313850172023417636020375045372547107712468813403 
>>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 
>>> > 5372547107712468813403")) 
>>> > 
>>> > The REPL converts  the unenquoted value to a Float64 before I get at 
>>> > it. 
>>> > 
>>> > Help is appreciated. 
>>> I don't think you can work around this at the moment. The best you can 
>>> do is to define a non-standard string literal by creating a @f128_str 
>>> macro, so that you can type these numbers as 
>>> f128"0.6584871727288045313850172023417636020375045372547107712468813403 
>>> ". 
>>>
>>
>> There is already a `big` macro:
>>
>> Float128(big"0.65848717272880453138501720234176360203750453725471077124688134")
>>
>> Instead of copying and pasting in the REPL, couldn't you write these 
>> numbers to a file
>> and read them in as strings in Julia?
>>  
>> There has been some discussion in the past about forwarding strings like 
>> this to the parser
>> already wrapped in a macro (as is done for large integer values); I don't 
>> recall what the 
>> issue with this was.
>>
>

Re: [julia-users] help with a macro to stringize high precision floating point values

[Stefan Karpinski]

I think we should probably make it possible to access the full string of a
numeric literal in a macro but that is a substantial change to the parser.

On Monday, November 2, 2015, David P. Sanders  wrote:

>
>
> El lunes, 2 de noviembre de 2015, 6:35:46 (UTC-6), Milan Bouchet-Valat
> escribió:
>>
>> Le lundi 02 novembre 2015 à 00:58 -0800, Jeffrey Sarnoff a écrit :
>> > I have many values like
>> >  0.6584871727288045313850172023417636020375045372547107712468813403
>> > that come from Maple and I would like to avoid doing this by
>> > copy/paste for each one:
>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504
>> > 5372547107712468813403"))
>> >
>> > I tried writing a macro that would put quotes around the value and
>> > then affix the rest -- without good result.
>> > julia>@fromMaple
>> > 0.6584871727288045313850172023417636020375045372547107712468813403
>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504
>> > 5372547107712468813403"))
>> >
>> > The REPL converts  the unenquoted value to a Float64 before I get at
>> > it.
>> >
>> > Help is appreciated.
>> I don't think you can work around this at the moment. The best you can
>> do is to define a non-standard string literal by creating a @f128_str
>> macro, so that you can type these numbers as
>> f128"0.6584871727288045313850172023417636020375045372547107712468813403
>> ".
>>
>
> There is already a `big` macro:
>
> Float128(big"0.65848717272880453138501720234176360203750453725471077124688134")
>
> Instead of copying and pasting in the REPL, couldn't you write these
> numbers to a file
> and read them in as strings in Julia?
>
> There has been some discussion in the past about forwarding strings like
> this to the parser
> already wrapped in a macro (as is done for large integer values); I don't
> recall what the
> issue with this was.
>

Re: [julia-users] Why does setting ENV["TZ"] in the REPL behave differently?

[Stefan Karpinski]

Seems like libc must not check the TZ variable each time, possibly due to
performance considerations?

On Monday, November 2, 2015, Avik Sengupta  wrote:

> I'm not sure why this behaves differently. The now() function calls down
> to time_now() in libc, and while we do a setenv() when changing ENV,
> clearly that change is not reaching down to the relevant parts of libc.
>
> In terms of workaround, if you wanted UTC time, then `now(Base.Dates.UTC)`
> will give you that. For other timezone conversions, you may want to look at
> the TimeZones package.  (https://github.com/quinnj/TimeZones.jl)
>
> On Sunday, 1 November 2015 16:10:52 UTC, Josef Sachs wrote:
>>
>> Works as expected with `julia -e`, but the environment variable
>> does not seem to be respected when set in the REPL.  Can someone
>> explain the reason, and possibly provide a workaround?
>>
>> $ TZ=UTC julia -e 'println(now())'
>> 2015-11-01T16:02:37
>> $ julia -e 'println(now())'
>> 2015-11-01T11:02:42
>> $ julia -e 'ENV["TZ"] = "UTC"; println(now())'
>> 2015-11-01T16:03:07
>> $ julia
>>_
>>_   _ _(_)_ |  A fresh approach to technical computing
>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>_ _   _| |_  __ _   |  Type "?help" for help.
>>   | | | | | | |/ _` |  |
>>   | | |_| | | | (_| |  |  Version 0.4.1-pre+22 (2015-11-01 00:06 UTC)
>>  _/ |\__'_|_|_|\__'_|  |  Commit 669222e (0 days old release-0.4)
>> |__/   |  x86_64-linux-gnu
>>
>> julia> ENV["TZ"] = "UTC"; println(now())
>> 2015-11-01T11:03:28
>>
>

[julia-users] Re: question about Hessian in ForwardDiff return InexactError()

[jamesmnason]

Hi Tony:

Thanks for the suggestion.

Unfortunately, the result is the same.

I initialized/pre-allocated the destination array for the Hessian as

hessh = zeros(nparm,nparm)

Julia's reply from the call to

hessh = ForwardDiff.hessian(PF_RE_AR1_outer_alt, parms)

began with

ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}
ForwardDiff.HessianNumber{7,Float64,Tuple{Float64,Float64,Float64,Float64,Float64,Float64,Float64}}

followed by the ERROR: LoadError: InexactError() statement.

Jim


On Sunday, November 1, 2015 at 11:35:16 PM UTC-5, Tony Kelman wrote:
>
> You probably need to initialize the destination array with a floating 
> point, rather than integer, element type.

Re: [julia-users] Julia license/patents possibly use "Universal Permissive License"?

[Stefan Karpinski]

The MIT license was and still is the simplest, best-known liberal license.
It's way too late to change the license now and there's no compelling
reason to do so. We'd have to get permission from the 400+ people who have
made contributions to Julia. For what benefit? A license that has the same
practical effect that is less well-known?

There are no known (to me) patents that apply to anything in Julia. Since
we don't have any Julia-related patents, granting them doesn't accomplish
anything. While I understand the motivation for patent retribution clauses
like the one in the Apache License, it just rubs me the wrong way.

On Monday, November 2, 2015, Páll Haraldsson 
wrote:

>
> First a question in the current [main] license:
>
> A. Is there some reason the MIT [Expat] license was used (other than maybe
> just the default for MIT people)?
>
>
> B. If it is just to be short and uncomplicated, the Universal Permissive
> License, I've just become aware of, also seems to fit the bill:
>
> http://www.gnu.org/licenses/license-list.en.html#UPL
>
>
> The FSF just added it to their list in September:
>
>
> https://www.fsf.org/blogs/licensing/universal-permissive-license-added-to-license-list
> "we still recommend using Apache 2.0 for simple programs"..
>
>
> It is also OSI compliant:
>
> http://opensource.org/licenses/UPL
>
>
> I've seen languages use MPL [2.0], a long license, without problems
> (expect the length..). If I recall Apache 2.0 has also been used, also
> long, and while the FSF says ok, note they say only compatible with GPL v3,
> not v2.
>
>
> C. Some projects have a PATENT grant file, I'm not aware of any patents,
> and I assume there are no submarine patents.. Maybe we would want the UPL
> to make it explicit? Dual license with MIT?
>
> --
> Palli.
>
>

Re: [julia-users] help with a macro to stringize high precision floating point values

[David P. Sanders]

El lunes, 2 de noviembre de 2015, 6:35:46 (UTC-6), Milan Bouchet-Valat 
escribió:
>
> Le lundi 02 novembre 2015 à 00:58 -0800, Jeffrey Sarnoff a écrit : 
> > I have many values like 
> >  0.6584871727288045313850172023417636020375045372547107712468813403 
> > that come from Maple and I would like to avoid doing this by 
> > copy/paste for each one: 
> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 
> > 5372547107712468813403")) 
> > 
> > I tried writing a macro that would put quotes around the value and 
> > then affix the rest -- without good result. 
> > julia>@fromMaple 
> > 0.6584871727288045313850172023417636020375045372547107712468813403 
> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 
> > 5372547107712468813403")) 
> > 
> > The REPL converts  the unenquoted value to a Float64 before I get at 
> > it. 
> > 
> > Help is appreciated. 
> I don't think you can work around this at the moment. The best you can 
> do is to define a non-standard string literal by creating a @f128_str 
> macro, so that you can type these numbers as 
> f128"0.6584871727288045313850172023417636020375045372547107712468813403 
> ". 
>

There is already a `big` macro:
Float128(big"0.65848717272880453138501720234176360203750453725471077124688134")

Instead of copying and pasting in the REPL, couldn't you write these 
numbers to a file
and read them in as strings in Julia?
 
There has been some discussion in the past about forwarding strings like 
this to the parser
already wrapped in a macro (as is done for large integer values); I don't 
recall what the 
issue with this was.

Re: [julia-users] help with a macro to stringize high precision floating point values

[Milan Bouchet-Valat]

Le lundi 02 novembre 2015 à 00:58 -0800, Jeffrey Sarnoff a écrit :
> I have many values like
>  0.6584871727288045313850172023417636020375045372547107712468813403
> that come from Maple and I would like to avoid doing this by
> copy/paste for each one:
> Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504
> 5372547107712468813403"))
> 
> I tried writing a macro that would put quotes around the value and
> then affix the rest -- without good result.
> julia>@fromMaple
> 0.6584871727288045313850172023417636020375045372547107712468813403
> Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504
> 5372547107712468813403"))
> 
> The REPL converts  the unenquoted value to a Float64 before I get at
> it.
> 
> Help is appreciated.
I don't think you can work around this at the moment. The best you can
do is to define a non-standard string literal by creating a @f128_str
macro, so that you can type these numbers as
f128"0.6584871727288045313850172023417636020375045372547107712468813403
".

But you'd still have to add the quotes.


Regards

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

[Christoph Ortner]

Hi Kristoffer,

Could one one possibly use this with a metric that effectively defines a 
torus? E.g., suppose my points are in (0,L) x (0, L) x (0, L) but a point x 
is identify with all other points x + Le1, x+Le2, etc .?

Christoph

[julia-users] Re: Julia license/patents possibly use "Universal Permissive License"?

[Jeffrey Sarnoff]

One reason to stay with MIT License is that it has been in wide use for 
some time.  The UPL is newer, and in these matters, there is quite a bit of 
import in subtle wording; experience clarifies.

If you, or someone else wants to make the UPL rights available, just say 
e.g. (I am not a lawyer)
"You may choose to use this material either under the MIT License or under 
the Universal Permissive License"

On Monday, November 2, 2015 at 5:50:42 AM UTC-5, Páll Haraldsson wrote:
>
>
> First a question in the current [main] license:
>
> A. Is there some reason the MIT [Expat] license was used (other than maybe 
> just the default for MIT people)?
>
>
> B. If it is just to be short and uncomplicated, the Universal Permissive 
> License, I've just become aware of, also seems to fit the bill:
>
> http://www.gnu.org/licenses/license-list.en.html#UPL
>
>
> The FSF just added it to their list in September:
>
>
> https://www.fsf.org/blogs/licensing/universal-permissive-license-added-to-license-list
> "we still recommend using Apache 2.0 for simple programs"..
>
>
> It is also OSI compliant:
>
> http://opensource.org/licenses/UPL
>
>
> I've seen languages use MPL [2.0], a long license, without problems 
> (expect the length..). If I recall Apache 2.0 has also been used, also 
> long, and while the FSF says ok, note they say only compatible with GPL v3, 
> not v2.
>
>
> C. Some projects have a PATENT grant file, I'm not aware of any patents, 
> and I assume there are no submarine patents.. Maybe we would want the UPL 
> to make it explicit? Dual license with MIT?
>
> -- 
> Palli.
>
>

[julia-users] Julia license/patents possibly use "Universal Permissive License"?

[Páll Haraldsson]

First a question in the current [main] license:

A. Is there some reason the MIT [Expat] license was used (other than maybe 
just the default for MIT people)?


B. If it is just to be short and uncomplicated, the Universal Permissive 
License, I've just become aware of, also seems to fit the bill:

http://www.gnu.org/licenses/license-list.en.html#UPL


The FSF just added it to their list in September:

https://www.fsf.org/blogs/licensing/universal-permissive-license-added-to-license-list
"we still recommend using Apache 2.0 for simple programs"..


It is also OSI compliant:

http://opensource.org/licenses/UPL


I've seen languages use MPL [2.0], a long license, without problems (expect 
the length..). If I recall Apache 2.0 has also been used, also long, and 
while the FSF says ok, note they say only compatible with GPL v3, not v2.


C. Some projects have a PATENT grant file, I'm not aware of any patents, 
and I assume there are no submarine patents.. Maybe we would want the UPL 
to make it explicit? Dual license with MIT?

-- 
Palli.

[julia-users] Re: Why does setting ENV["TZ"] in the REPL behave differently?

[Avik Sengupta]

I'm not sure why this behaves differently. The now() function calls down to 
time_now() in libc, and while we do a setenv() when changing ENV, clearly 
that change is not reaching down to the relevant parts of libc. 

In terms of workaround, if you wanted UTC time, then `now(Base.Dates.UTC)` 
will give you that. For other timezone conversions, you may want to look at 
the TimeZones package.  (https://github.com/quinnj/TimeZones.jl)

On Sunday, 1 November 2015 16:10:52 UTC, Josef Sachs wrote:
>
> Works as expected with `julia -e`, but the environment variable 
> does not seem to be respected when set in the REPL.  Can someone 
> explain the reason, and possibly provide a workaround? 
>
> $ TZ=UTC julia -e 'println(now())' 
> 2015-11-01T16:02:37 
> $ julia -e 'println(now())' 
> 2015-11-01T11:02:42 
> $ julia -e 'ENV["TZ"] = "UTC"; println(now())' 
> 2015-11-01T16:03:07 
> $ julia 
>_ 
>_   _ _(_)_ |  A fresh approach to technical computing 
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org 
>_ _   _| |_  __ _   |  Type "?help" for help. 
>   | | | | | | |/ _` |  | 
>   | | |_| | | | (_| |  |  Version 0.4.1-pre+22 (2015-11-01 00:06 UTC) 
>  _/ |\__'_|_|_|\__'_|  |  Commit 669222e (0 days old release-0.4) 
> |__/   |  x86_64-linux-gnu 
>
> julia> ENV["TZ"] = "UTC"; println(now()) 
> 2015-11-01T11:03:28 
>

Re: [julia-users] Re: typealias vs. const

[Tomas Lycken]

Thanks, the results were interesting enough :)

julia> expand(:(typealias A B))
:(begin
const A
A = B
return B
end)

julia> expand(:(typealias A{T} B{T,1}))
:((AST(:($(Expr(:lambda, Any[:T], Any[Any[Any[:T,:Any,0]],Any[],1,Any[]], 
:(begin
const A
GenSym(0) = 
(top(TypeConstructor))((top(svec))(T),(top(apply_type))(Main.B,T,1))
Main.A = GenSym(0)
return GenSym(0)
end))((top(TypeVar))(:T,top(Any),true)))

Conclusion: Non-parametric type aliases are simple. Parametric type aliases 
are not :)

// T

On Friday, October 30, 2015 at 7:31:57 PM UTC+1, Yichao Yu wrote:

On Fri, Oct 30, 2015 at 1:34 PM, Tomas Lycken  > wrote: 
> >> `const A = T` is what `typealias A T` lowered to when it doesn't have 
> type 
> >> parameters 
> > 
> > I wanted to inspect the output of this lowering pass, but 
> `@code_lowered` 
> > was apparently not what I was looking for (at least, `@code_lowered 
> > :(typealias Foo Int)` didn't work...). 
> > 
> > However, I understand your statement as follows: 
> > 
> > `typealias A T` is equivalent to `const A = T`, while `typealias A{S} 
> T{S}` 
> > does something more involved? What does `typealias A{S} T{Foo,S}` do? I 
> > assume these are not possible using `const  = ` constructs, 
> right? 
>
> right. Try `expand(:(typealias A B))` 
>
> > 
> > // T 
> > 
> > On Friday, October 30, 2015 at 1:45:37 PM UTC+1, Yichao Yu wrote: 
> >> 
> >> On Fri, Oct 30, 2015 at 8:29 AM, FANG Colin  wrote: 
> >> > I have got the same confusion. Any ideas? 
> >> > 
> >> > I have even seen usage of A = T (no const) 
> >> > (http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), 
> is 
> >> > it 
> >> > supposed to be bad (slow) because it is a global variable? 
> >> > 
> >> 
> >> no const will have performance issue since it's a global. 
> >> `const A = T` is what `typealias A T` lowered to when it doesn't have 
> >> type parameters. In this case, it's just a matter of style. Being 
> >> consistent within a file is probably better but you can pick whichever 
> >> you prefer. 
> >> 
> >> > 
> >> > 
> >> > On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson 
> >> > wrote: 
> >> >> 
> >> >> Given a type T, what is the difference in practice between 
> >> >>  typealias A T 
> >> >> and 
> >> >>  const A = T 
> >> >> ? 
> >> >> 
> >> >> There seems to be some disagreement over which one to use (e.g. 
> >> >> 
> >> >> 
> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577).
>  
>
> >> >> 
> >> >> My impression is that there is no difference, and that the only 
> >> >> advantage 
> >> >> of a typealias is that it can be parameterized.  Is that right? 
> >> >> 
> >> >> If they are equivalent, what is the Julian style?  Even in Julia 
> Base 
> >> >> it 
> >> >> doesn't seem to be entirely consistent. 
>
​

[julia-users] Escher show pdf file

[Yakir Gagnon]

I guess this is for the future, but in case it’s easy and already here, I 
sure could use some kind of pdf viewing in Escher…
So something like the image(path_to_image) -> tile from the Content API, 
only for a (local, in assets) pdf.

Thanks for all the great work!

A slow work around will be to (imagemagick) convert the pdf to an image 
first. 
​

[julia-users] help with a macro to stringize high precision floating point values

[Jeffrey Sarnoff]

I have many values 
like 0.6584871727288045313850172023417636020375045372547107712468813403
that come from Maple and I would like to avoid doing this by copy/paste for 
each one:
Float128(parse(BigFloat,"0.6584871727288045313850172023417636020375045372547107712468813403"))

I tried writing a macro that would put quotes around the value and then 
affix the rest -- without good result.
julia>@fromMaple 
0.6584871727288045313850172023417636020375045372547107712468813403
Float128(parse(BigFloat,"0.6584871727288045313850172023417636020375045372547107712468813403"))

The REPL converts  the unenquoted value to a Float64 before I get at it.

Help is appreciated.