Re: [julia-users] ls()?

[Adrian Lewis]

> You can find a thread/issue where this is discussed. Some group decided 
to call it readdir() and like it more. I just got used to it. I think it's 
silly, but it's just syntax.

I thought it might be an idea to stick with POSIX standards. 

On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas 
wrote:
>
>
>
> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>>
>> readdir()
>>
>> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis  
>> wrote:
>>
>>> In the filesystem package, if we have pwd() and cd(), why do we not have 
>>> ls()?
>>>
>>> Aidy
>>>
>>
>>

[julia-users] ls()?

[Adrian Lewis]

In the filesystem package, if we have pwd() and cd(), why do we not have 
ls()?

Aidy

[julia-users] Re: TK dependency woes

[Lewis Levin]

Further:  there is nothing about the command line.  If you 
include("script.jl") in julia, the first time it fails.  Immediately, run 
it a second time and it works.

Go figure.

This is still not really as it should be and looking for any further help.

On Monday, August 29, 2016 at 9:45:02 AM UTC-7, Lewis Levin wrote:
>
> Deeper view of the problem.  Either code in Julia packages or OS X itself 
> can't resolve symlinks properly.
>
> If you look at the conflict message, the conflict is between libtk.dylib 
> and /Library/Frameworks/Tk.framework/Versions/8.5/Tk.
>
> Here is the absurdity:  libtk.dylib is a symlink to libtk8.5.dylib which 
> is a symlink to /Library/Frameworks/Tk.framework/Versions/8.5/Tk.  
>
> So, there is only ONE version of TK installed.  The problem is the series 
> of symlinks.
>
> Unfortunately, due to OS X security it appears to be impossible to modify 
> things in /usr/lib.  I have tried with sudo and the OS still blocks.
>
>
>
> On Monday, August 29, 2016 at 9:30:20 AM UTC-7, Lewis Levin wrote:
>>
>> I'd seen that reference you suggested and I don't really want to change 
>> all the dependencies.  
>>
>> Something in the latest mods of ImageView or Images broke things.  All 
>> I've done is to reinstall Julia 0.4.6 and all packages.  All of the 
>> dependencies:  Python, TK, tcl have been left as is.
>>
>> If I do using Images, ImageView from the julia command line and then 
>> include a script all works.  If I include the script at the command line 
>> (the script contains using Images, ImageView) then it fails.
>>
>> Why should their be a difference?
>>
>>
>>

[julia-users] Re: TK dependency woes

[Lewis Levin]

Deeper view of the problem.  Either code in Julia packages or OS X itself 
can't resolve symlinks properly.

If you look at the conflict message, the conflict is between libtk.dylib 
and /Library/Frameworks/Tk.framework/Versions/8.5/Tk.

Here is the absurdity:  libtk.dylib is a symlink to libtk8.5.dylib which is 
a symlink to /Library/Frameworks/Tk.framework/Versions/8.5/Tk.  

So, there is only ONE version of TK installed.  The problem is the series 
of symlinks.

Unfortunately, due to OS X security it appears to be impossible to modify 
things in /usr/lib.  I have tried with sudo and the OS still blocks.



On Monday, August 29, 2016 at 9:30:20 AM UTC-7, Lewis Levin wrote:
>
> I'd seen that reference you suggested and I don't really want to change 
> all the dependencies.  
>
> Something in the latest mods of ImageView or Images broke things.  All 
> I've done is to reinstall Julia 0.4.6 and all packages.  All of the 
> dependencies:  Python, TK, tcl have been left as is.
>
> If I do using Images, ImageView from the julia command line and then 
> include a script all works.  If I include the script at the command line 
> (the script contains using Images, ImageView) then it fails.
>
> Why should their be a difference?
>
>
>

[julia-users] Re: TK dependency woes

[Lewis Levin]

I'd seen that reference you suggested and I don't really want to change all 
the dependencies.  

Something in the latest mods of ImageView or Images broke things.  All I've 
done is to reinstall Julia 0.4.6 and all packages.  All of the 
dependencies:  Python, TK, tcl have been left as is.

If I do using Images, ImageView from the julia command line and then 
include a script all works.  If I include the script at the command line 
(the script contains using Images, ImageView) then it fails.

Why should their be a difference?

[julia-users] TK dependency woes

[Lewis Levin]

It is a bit beyond me to debug what follows.

My Python build works fine.  PyPlot within Julia works fine.

 I suspect the problem is with the ImageView package.

objc[34842]: Class TKApplication is implemented in both 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and /usr/lib/libtk.dylib. 
One of the two will be used. Which one is undefined.

objc[34842]: Class TKMenu is implemented in both 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and /usr/lib/libtk.dylib. 
One of the two will be used. Which one is undefined.

objc[34842]: Class TKContentView is implemented in both 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and /usr/lib/libtk.dylib. 
One of the two will be used. Which one is undefined.

objc[34842]: Class TKWindow is implemented in both 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and /usr/lib/libtk.dylib. 
One of the two will be used. Which one is undefined.

*ERROR: LoadError: LoadError: LoadError: LoadError: Tk.TclError("error 
initializing Tcl: Can't find a usable init.tcl in the following 
directories: \n
/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/tcl8.5 
/Applications/Julia-0.4.6.app/Contents/Resources/lib/tcl8.5 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/library 
/Applications/Julia-0.4.6.app/Contents/Resources/library 
/Applications/Julia-0.4.6.app/Contents/Resources/tcl8.5.9/library 
/Applications/Julia-0.4.6.app/Contents/tcl8.5.9/library\n\n/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/init.tcl:
 
version conflict for package \"Tcl\": have 8.5.9, need exactly 
8.5.17\nversion conflict for package \"Tcl\": have 8.5.9, need exactly 
8.5.17\nwhile executing\n\"package require -exact Tcl 8.5.17\"\n
(file 
\"/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/init.tcl\" 
line 19)\ninvoked from within\n\"source 
/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts/init.tcl\"\n  
  (\"uplevel\" body line 1)\ninvoked from within\n\"uplevel #0 [list 
source \$tclfile]\"\n\n\nThis probably means that Tcl wasn't installed 
properly.\n")*

* in init at /Users/lewislevin/.julia/v0.4/Tk/src/tkwidget.jl:58*

* in include at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include_from_node1 at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include_from_node1 at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in require at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include_from_node1 at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in require at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in include_from_node1 at 
/Applications/Julia-0.4.6.app/Contents/Resources/julia/lib/julia/sys.dylib*

*while loading /Users/lewislevin/.julia/v0.4/Tk/src/tkwidget.jl, in 
expression starting on line 454*

*while loading /Users/lewislevin/.julia/v0.4/Tk/src/Tk.jl, in expression 
starting on line 37*

*while loading /Users/lewislevin/.julia/v0.4/ImageView/src/ImageView.jl, in 
expression starting on line 14*

*while loading /Users/lewislevin/Dropbox/Online Coursework/Stanford Machine 
Learning/Assignments/julia-ex7/ex7.jl, in expression starting on line 23*

[julia-users] Re: object properties variable

[Lewis Lehe]

thanks, this did it for me.

On Monday, August 15, 2016 at 8:48:31 PM UTC-7, John Myles White wrote:
>
> getfield(foo, :bar)
>
> You can iterate over the fieldnames(foo) to print things. I would avoid a 
> potentially wasteful conversion to a dictionary since it doesn't buy you 
> anything in terms of expressive power.
>
> --John
>
> On Monday, August 15, 2016 at 8:38:04 PM UTC-7, Lewis Lehe wrote:
>>
>> Hi I was wondering if there is a way to do this? To access a fieldname 
>> with a variable?
>>
>> type Foo
>>  bar:Float64
>> end
>>
>> foo = Foo(5.0)
>>
>> test = :bar
>> foo[test]
>>
>>
>>
>> Also, I wondered if there is a way to convert an object into a dict? I 
>> want to "println" an object in a way that's readable in the output, like a 
>> Dict.
>>
>>
>>
>>

[julia-users] object properties variable

[Lewis Lehe]

Hi I was wondering if there is a way to do this? To access a fieldname with 
a variable?

type Foo
 bar:Float64
end

foo = Foo(5.0)

test = :bar
foo[test]



Also, I wondered if there is a way to convert an object into a dict? I want 
to "println" an object in a way that's readable in the output, like a Dict.

[julia-users] pyplot plots in atom Plots pane

[Lewis Lehe]

Hi I am using the PyPlot package to make mathematical plots, and I use the 
Atom julia client.

Is there a way to make the plots appear in the Plots pane? I don't know 
exactly what it is good for. They pop up in their own windows behind the 
atom client, and it is a hassle to switch windows to see my plot.

Re: [julia-users] Re: array of arrays to multi-dimensional array

[Lewis Lehe]

thanks Islam! I had tried to use the vcat and did't get the result I
wanted, but I didn't think of using the splats.

On Fri, Jun 10, 2016 at 11:01 AM, Islam Badreldin  wrote:

> Hi Lewis
>
> Please see below
>
>
> On Friday, June 10, 2016 at 12:48:57 PM UTC-4, Lewis Lehe wrote:
>
>> Hi I I wondered if there is a neat in Julia way to create a
>> multi-dimensional array from an array of arrays. This would be useful for
>> creating data structures programatically.
>>
>> For example...
>>
>> arr = map(x->[0 1 2 3],1:8)
>>
>> now i have this array of arrays. but what I would really like is to make
>> the entries into the rows of an 8x4 matrix.
>>
>> Is there a simple way to do this?
>>
>
> As Tim pointed out, cat and friends are the answer. For your
> specific examples, this works for me (using ... for splat):
>
> > vcat(arr...)
> 8x4 Array{Int64,2}:
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>  0  1  2  3
>
>
> Cheers,
> Islam
>

[julia-users] array of arrays to multi-dimensional array

[Lewis Lehe]

Hi I I wondered if there is a neat in Julia way to create a 
multi-dimensional array from an array of arrays. This would be useful for 
creating data structures programatically.

For example...

arr = map(x->[0 1 2 3],1:8)

now i have this array of arrays. but what I would really like is to make 
the entries into the rows of an 8x4 matrix.

Is there a simple way to do this?

[julia-users] Re: GUI toolkits for Julia: Gtk vs Tk vs others

[Lewis Levin]

The Python doc for tk will provide some hints...

On Sunday, March 27, 2016 at 5:09:51 PM UTC-7, Daniel Carrera wrote:
>
> Hello,
>
> When it comes to GUI toolkits in Julia, Gtk seems to be the main choice, 
> followed by Tk. At least in terms of development effort:
>
> Gtk.jl -- 444 commits, 23 contributors
> Tk.jl -- 235 commits, 28 contributors
> PySide.jl -- 35 commits, 2 contributors
>
>
> Although I like Gtk, I'm curious. Is there a reason Gtk gets more 
> attention? Maybe Tk is just easier to support, so it doesn't need as many 
> commits. But Tk also has less documentation. So I do get the impression Gtk 
> gets more attention. Why would Gtk or Tk be preferred in the context of 
> Julia?
>
> My understanding is that Gtk is great on Linux but doesn't work so well on 
> Windows and Mac. Tk has historically been considered ugly ("looks like 
> Motif") but my impression is that this was fixed long ago. Gtk has more 
> widgets than Tk and I think also more inputs. Qt is supposed to be great on 
> other platforms. Are C++ toolkits more difficult to support? Oh, there is 
> no package for wxWidgets, and that's also a C++ toolkit. Maybe that's a 
> factor? Or maybe people just like the look of Gtk.
>
>
> Cheers,
> Daniel.
>

Re: [julia-users] shell command didn't work

[Lewis Levin]

Of course.

And that's the hardest thing:  what we're used to in Bash doesn't work in 
Julia.

Thanks.

[julia-users] Re: Julia and Atom

[Lewis Levin]

I've been pretty happy using Atom with just "language-julia".  I've tried 
Juno:  julia-client and ink with the support installed into julia.  But, 
there are many problems and few benefits.  Maybe we get too dependent on 
fancy IDEs.  

I also install terminal-plus.  Just launch a terminal--it starts by default 
in your project folder, type julia, and do stuff.  It's not much more than 
having a separate terminal window open, but actually the ui nav to go back 
and forth between code and terminal really is convenient.  Sure, I have to 
type include("somefile.jl") but mostly that's just up-arrow.  

It's just so convenient and no complexity.  autocomplete is sort of 
over-rated.  You get autocomplete for your own variables just from Atom. 
 For language keywords, the issue is really knowing what to use to 
accomplish your goal.  Saving 3 keystrokes isn't as important.

For charting I use jupyter.

For debugging I just use print statements.  Real debugging support would be 
nice.

Most of the non-language specific stuff an IDE provides, such as git, and 
working with other languages is there.

Until someone super serious like the jetbrains guys decide to support 
Julia, we'll survive.

[julia-users] shell command didn't work

[Lewis Levin]

Not sure what was wrong with this:

function preparation()
>
> run(pipeline(`find -s /Volumes/ll1t/pictures/`, 
>> "~/Dropbox/Elements/QuickRef/export.txt"))
>
> run(pipeline(`find -s /Volumes/Photos/Pictures/`, 
>> "~/Dropbox/Elements/QuickRef/source.txt"))
>
> end
>
>
Error from the shell level was no such file or directory.

Weird because if I open a shell and run find exactly as shown (with a 
redirect of course), it works.

Same for running within julia with shell escape ;.

Bunch of oddities in the evolving syntax.  If it's not important (probably 
isn't) then why not just deprecate the whole thing?  No more bugs, no more 
documentation.   Someone will complain, "I can do shell cmds from Python, 
Ruby, ..." to which say, "Sure you can still use those tools and use Julia. 
 It's all great."

Not being flip here.  It seems like this has changed over the releases; 
still seems a bit clumsy (ignoring my own example of user error).  It's ok 
if it is not a priority.  There are lots of things to do.  I'll admit it is 
a reasonable thing to do, but not if it keeps getting very complicated.

I'd be happy with spawning a shell and passing a literal and crossing 
fingers.  No output would come back to Julia but that is ok:  mostly likely 
use case is to create/modify/delete files.  

Love to know what I did wrong.  I was just being lazy and trying to put my 
"setup" into the script.  Takes 3 secs to do from shell manually. 

Re: [julia-users] Re: metaprogramming update variable when slider changes

[Lewis Lehe]

Hey Stefan,
I figured it out. I had to do something along these lines:

x = 2.0
function change_variable(z)
eval(:($z = 3.0))
end
change_variable(:x)





On Friday, March 25, 2016 at 12:00:50 PM UTC-7, Stefan Karpinski wrote:
>
> You may want to check out Interact.jl: 
> https://github.com/JuliaLang/Interact.jl
>
> On Fri, Mar 25, 2016 at 1:59 PM, Lewis Lehe  > wrote:
>
>> Err that is
>>
>>   slider[:on_changed](
>>#WHERE I WANT THE MACRO TO GO
>>variable = slider.val
>>  )
>>
>>
>>
>> On Friday, March 25, 2016 at 10:57:34 AM UTC-7, Lewis Lehe wrote:
>>>
>>> Hi, 
>>> I am learning about metaprogramming and macros. I have a very basic case 
>>> but am unsure about what Julia is capable of. last time I asked a question 
>>> here I got a very helpful answer shortly.
>>>
>>> I am making sliders for a matplotlib plot. I would that when a slider 
>>> changes, it changes some the value of some variable. Here is an example.
>>>
>>> frequency = 2.0
>>> function makeSlider(axSlider, variable):
>>>   slider = widget.Slider(axSlider; valinit=variable)
>>>   slider.on_changed(
>>> #WHERE I WANT THE MACRO TO GO
>>> variable = slider.val
>>>   )
>>>   slider
>>> end
>>> freqSlider = makeSlider(axFrequency,frequency)
>>>
>>>
>>> Is this possible? I did not see any use cases like this in the 
>>> documentation. 
>>>
>>> I would normally do it by keeping all my constants as properties of some 
>>> World type (or in some world Dictionary) and passing the key to the 
>>> function, but I wanted to learn how to use this part of Julia.
>>>
>>> Thanks!
>>>
>>
>

Re: [julia-users] Re: metaprogramming update variable when slider changes

[Lewis Lehe]

But I want to code in atom and render the chart with PyPlot, not jupyter 
notebook. 

Also, I would just like to know how to do this.

On Friday, March 25, 2016 at 12:00:50 PM UTC-7, Stefan Karpinski wrote:
>
> You may want to check out Interact.jl: 
> https://github.com/JuliaLang/Interact.jl
>
> On Fri, Mar 25, 2016 at 1:59 PM, Lewis Lehe  > wrote:
>
>> Err that is
>>
>>   slider[:on_changed](
>>#WHERE I WANT THE MACRO TO GO
>>variable = slider.val
>>  )
>>
>>
>>
>> On Friday, March 25, 2016 at 10:57:34 AM UTC-7, Lewis Lehe wrote:
>>>
>>> Hi, 
>>> I am learning about metaprogramming and macros. I have a very basic case 
>>> but am unsure about what Julia is capable of. last time I asked a question 
>>> here I got a very helpful answer shortly.
>>>
>>> I am making sliders for a matplotlib plot. I would that when a slider 
>>> changes, it changes some the value of some variable. Here is an example.
>>>
>>> frequency = 2.0
>>> function makeSlider(axSlider, variable):
>>>   slider = widget.Slider(axSlider; valinit=variable)
>>>   slider.on_changed(
>>> #WHERE I WANT THE MACRO TO GO
>>> variable = slider.val
>>>   )
>>>   slider
>>> end
>>> freqSlider = makeSlider(axFrequency,frequency)
>>>
>>>
>>> Is this possible? I did not see any use cases like this in the 
>>> documentation. 
>>>
>>> I would normally do it by keeping all my constants as properties of some 
>>> World type (or in some world Dictionary) and passing the key to the 
>>> function, but I wanted to learn how to use this part of Julia.
>>>
>>> Thanks!
>>>
>>
>

[julia-users] Re: metaprogramming update variable when slider changes

[Lewis Lehe]

Err that is

  slider[:on_changed](
   #WHERE I WANT THE MACRO TO GO
   variable = slider.val
 )



On Friday, March 25, 2016 at 10:57:34 AM UTC-7, Lewis Lehe wrote:
>
> Hi, 
> I am learning about metaprogramming and macros. I have a very basic case 
> but am unsure about what Julia is capable of. last time I asked a question 
> here I got a very helpful answer shortly.
>
> I am making sliders for a matplotlib plot. I would that when a slider 
> changes, it changes some the value of some variable. Here is an example.
>
> frequency = 2.0
> function makeSlider(axSlider, variable):
>   slider = widget.Slider(axSlider; valinit=variable)
>   slider.on_changed(
> #WHERE I WANT THE MACRO TO GO
> variable = slider.val
>   )
>   slider
> end
> freqSlider = makeSlider(axFrequency,frequency)
>
>
> Is this possible? I did not see any use cases like this in the 
> documentation. 
>
> I would normally do it by keeping all my constants as properties of some 
> World type (or in some world Dictionary) and passing the key to the 
> function, but I wanted to learn how to use this part of Julia.
>
> Thanks!
>

[julia-users] metaprogramming update variable when slider changes

[Lewis Lehe]

Hi, 
I am learning about metaprogramming and macros. I have a very basic case 
but am unsure about what Julia is capable of. last time I asked a question 
here I got a very helpful answer shortly.

I am making sliders for a matplotlib plot. I would that when a slider 
changes, it changes some the value of some variable. Here is an example.

frequency = 2.0
function makeSlider(axSlider, variable):
  slider = widget.Slider(axSlider; valinit=variable)
  slider.on_changed(
#WHERE I WANT THE MACRO TO GO
variable = slider.val
  )
  slider
end
freqSlider = makeSlider(axFrequency,frequency)


Is this possible? I did not see any use cases like this in the 
documentation. 

I would normally do it by keeping all my constants as properties of some 
World type (or in some world Dictionary) and passing the key to the 
function, but I wanted to learn how to use this part of Julia.

Thanks!

[julia-users] pre-compile with userimg.jl instructions

[Lewis Lehe]

Hi I am new to Julia and trying to pre-compile modules with the userimg.jl 
file, to speed up loading. There are instructions of various dates around 
online. But none seem complete.

I am looking for step-by-step instructions on setting this up in OSX. I 
think that would be helpful for a good number of people.

In the Documentation it says "To create a custom system image that can be 
used to start julia with the -J option, recompile Julia after modifying the 
file base/userimg.jl to require the desired modules." 
So I went into base/ and created a file, userimg.jl, that looks like this

Base.require("Gadfly")
Base.require("DataFrames")
Base.require("PyPlot")

Now I don't know what I would enter in the terminal to recompile Julia 
itself.

Also, once it works, will I be able to start julia with the -J option if I 
am using Jupyter notebook?

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

[Lewis Levin]

Awesome!


>

[julia-users] DataFrame conversion challenge

[Lewis Levin]

Here is a simple statement:
full_frl_college[:jun_sen] = Float64(full_frl_college[:jun_sen])

Here is the resulting error message:

LoadError: MethodError: `convert` has no method matching 
convert(::Type{Float64}, ::DataArrays.DataArray{Int64,1})


What is the right approach to this conversion?  I tried 
convert(DataArrays.DataArray{Float64,1}, full_frl_college[:jun_sen])
which did not work.

Answering my own question, both of these work:
x = Array{Float64,1}(collect(full_frl_college[exist, :jun_sen]))
# or
full_frl_college[:jun_sen]=Array{Float64,1}full_frl_college[:jun_sen]
# note the collect() above is NOT needed

So, all is good.

My confusion was taking the error message too literally and trying to 
convert using the DataArray type.  Does the DataArrays.DataArray type 
enable DataFrames to do its NA handling? If so, then I'd really want to use 
that type rather than Array{Float64, N}.  For this data, I'd already purged 
the NAs so it didn't matter.

Obviously, dimensionality is part of the type of the starting and target 
types.  Perhaps that is a bit too restrictive.  Is it possible that if a 
conversion will be, in effect, an element-wise conversion of the entire 
contents of the array that the conversion/promotion should be allowed?  I 
realize that with mixed types it can be unclear what a conversion "means". 
 But, when the object is already of one type and the target is of one type 
it seems intuitive to just do the conversion even if the types, strictly 
speaking, don't match because of dimensionality.  I guess this is a request 
for "element-wise" conversion.

Seems like this would make Julia more approachable.  Also, it could make 
the job of package developers, working with arrays and matrices, a bit 
easier because they wouldn't need methods for as many cases.

Re: [julia-users] Re: [ANN] MathGL graphics library wrapper

[lewis . hein]

Quite possibly I could. I wasn't aware of Interpolations.jl when I built 
the splines library.

Note: I have now released the splines package 
(https://github.com/LewisHein/Splines.jl) and updated the install 
instructions. So the MathGL package *should* install without problems now.

Please let me know if there is anything more I haven't fixed

On Saturday, March 5, 2016 at 3:09:38 AM UTC-7, Tomas Lycken wrote:
>
> Just guessing by the name, but it seems to me that you might be able to 
> leverage Interpolations.jl to get rid of the dependency on Splines.jl.
>
> https://github.com/tlycken/Interpolations.jl 
>
> // T 
>

[julia-users] Re: [ANN] MathGL graphics library wrapper

[lewis . hein]

Oooh. Now that should not be happening. The mimetypes.jl file is definitely 
part of the package on my end

As for the error with missing Splines.jl, I didn't realize that that was 
still a dependency. I will post the Splines.jl package as soon as I can, 
probably later today. I will also try to add installation instructions.

All of your testing is very much appreciated. I think I'd better set up a 
"permanently clean" VM where I can test some of this stuff and create fewer 
annoying hassles for others trying to use my code

Lewis

On Friday, March 4, 2016 at 3:36:51 PM UTC-7, Christoph Ortner wrote:
>
> Further down the source file, there is an include
>
> include("mimetypes.jl")
>
> but there is no file mimetypes.jl anywhere. Is it possible that the 
> repository is incomplete?
>
> C
>

Re: [julia-users] Re: [ANN] MathGL graphics library wrapper

[lewis . hein]

OK, I apologize for the problems. The reason for the error on "using 
Splines" is that I also am working on a splines package that I need and 
added some plotting features to plot my splines. So, you can either delete 
that line and any functions that take a Spline as an argument (There aren't 
many) , or you can wait until I get my splines library posted. (I don't 
know how long this will be; hopefully soon). A third option would be to 
take a look here:

https://github.com/thomastaudt/MathGL.jl

It appears that someone else had the same idea that I did. His probably has 
way fewer rough edges, too. If you want my plotOpStack functionality, then 
that would be trivially easy (a few dozen lines of code) to add to any 
julia-based plotting system, MathGL.jl, gadfly, etc.

As for installing MathGL, it should be in the repo for most mainstream 
linux distros; If you are running windows then I think they have an 
installer.

It should be possible to have MathGL.jl install the MathGL library 
automatically, given a developer who knows their way around the julia 
packaging system sufficiently. The one thing that gave me pause is (other 
than that I don't know my way around the packaging system that well) is 
that MathGL is a 20 Mb download, which would hugely increase the size of my 
package

Lewis
On Friday, March 4, 2016 at 12:27:22 PM UTC-7, Christoph Ortner wrote:
>
>
> looks really nice, but I just spent 30 minutes trying to install MathML. 
> This is when I lose interest. Sorry. 
>
> Any chance to have MathML.jl install MathML automatically?
>
> Christoph
>
>

[julia-users] [ANN] MathGL graphics library wrapper

[Lewis Hein]

Hi all

MathGL is a really nice plotting library that I have been using
extensively for the past year. When I took the plunge recently and
switched my research codebase over to julia, I wanted MathGL to follow
it, especially as there are some things such as animations, windowing
toolkit widgets, and the incredible customizeability and diversity of
the plots that I couldn't find in other plotting packages. Therefore, I
took the obvious solution and built a julia interface. The code is on
github here:

https://github.com/LewisHein/MathGL.jl

Lewis

[julia-users] dataframes convert problem with solution

[lewis]

I was using the dataframes convert method that allows replacement of NA 
with an arbitrary value.  I thought I had it working, but maybe I forgot to 
save and was running an old version.

Anyway, it appears I am using the method from the dataframes documentation, 
but it results in a type error:

Using DataFrames

city = readtable(fname)
points = convert(Array, city[:,2:end], NaN)  # converts NA values to 
NaN == not a number

Results in:

*ERROR: MethodError: `convert` has no method matching 
convert(::Type{Array{T,N}}, ::DataFrames.DataFrame, ::Float64)*

*This may have arisen from a call to the constructor Array{T,N}(...),*

*since type constructors fall back to convert methods.*

Closest candidates are:

  convert{T,N}(::Type{Array{T,N}}, *::DataArrays.DataArray{T,N}*, ::Any)

  convert{T,R,N}(::Type{Array{T,N}}, *::DataArrays.PooledDataArray{T,R,N}*, 
::Any)

  convert(::Type{Array{T,N}}, ::DataFrames.AbstractDataFrame)

  ...

 in hcluster at /Users/lewislevinmbr/Dropbox/Online Coursework/MIT Intro 
6002x/Assignments/Probset_6/df_hcluster.jl:85

DataFrames documentation shows:

dv = @data([NA, 3, 2, 5, 4])mean(convert(Array, dv, 11))

Seems like I am doing the same thing, just using the float value NaN.  The 
columns of city that are being sliced are indeed Float64.  

This certainly works, but will fail if any value is NA (not a problem with 
sample dataset, but I would like to generalize...):

points = Array{Float64}(city[:, 2:end])  # fails if any value is NA
>

Kept breaking this down and solved it.  The convert with replacement of NA 
values only works on type::DataArray, not the DataFrames type.  So, first 
convert to DataArray, then do the conversion with replacement of NA, thus:

city = readtable(fname)
>
> points = convert(Array{Float64,2}, DataArray(city[:, 2:end]), NaN)  # 
>> converts NA to NaN
>
>
That's what I wanted--and got.  Works like a champ.  I think replacing NaN 
with NA is pretty useful.  NaN's will propagate like NA's in a DataArray 
type, but Array{Float64} is noticeably faster.  

You could ask, "why are you doing this?  ...like why even use a DataFrame 
at all with its ability to handle NAs if you are just going to convert back 
out of it?"
Well, good question.   The simple answer is for the simple data reading and 
handling of row/col names and simple summary stats, etc.  And then, since 
the core data array has no NA's and is float, get the improved performance 
for handling the data subset as Array{Float64,2}.

And, yes, I did the experiment with readcsv and this also works, but 
provides no handling of NA.

So, I think the most general is loading the data as a DataFrame, deciding 
what to do with NA, and then converting.

There is enough here to handle lots of different approaches.  Just 
experimenting. 

[julia-users] is there a quick way to delete a variable from a jld file

[lewis]

I've used @save and @load to save variables from some experimenting 
sessions.  Now, I want to get rid of a view.

@save to a new variable doesn't quite work if I started by @load  'ing as 
there is no way to remove an item from an existing Julia workspace (except 
the entire workspace).

Can I save incrementally into an existing JLD "file"?  This would do the 
trick.

If there is no quick&dirty way then I'll just use the functional API and 
start a fresh session file.

Tx.

Re: [julia-users] Moore foundation grant.

[lewis]

Fantastic.

Re: [julia-users] Re: PyPlot won't close first figure drawn

[lewis]

I posted as an issue over on PyPlot.  I got a reply about Python but not 
about the problem.

Please point out how I have been negative.  I've tried to provide 
information and one other user confirms that he has also seen the problem. 
 I thought I was being pretty clear to just ask for clues or pointers to 
other things I can try or look at it.

On Tuesday, November 10, 2015 at 10:50:04 AM UTC-8, Tom Breloff wrote:
>
> Lewis:  There are a couple things to note:
>
>- This belongs as a PyPlot issue... it's not really appropriate for 
>julia-users
>- I think people have been slow to help you, not because you're a 
>"noob", but because of your extreme negativity so far.
>
> You've spent enough time on this that you're probably also the most 
> qualified to solve it.
>
> On Tue, Nov 10, 2015 at 1:34 PM, > 
> wrote:
>
>> I'd still really like help with this.
>>
>> Here are some possible problems with the way just the first figure is 
>> being handled within PyPlot:
>>  1.being put in the figure_queue, which holds figures for 
>> IJulia--this shouldn't be happening as I am not using IJulia in this case;
>>  2.   somehow matplotlib is losing it: the close() function in PyPlot is 
>> a straightforward pycall to put[:close]--with a figure argument f.  But, 
>> when you plot without defining a figure first there is no figure to 
>> reference.  Calls to close don't pass any argument.  It's not clear why 
>> this would be a problem because everything works for the 2nd and all 
>> subsequent plots created WITHOUT first starting an identified figure.  
>> 3.  gcf() can't find the figure.  When I run gcf after the first plot, it 
>> actually creates a NEW figure because it doesn't see that any figure exists 
>> (even though it is there because matplotlib created it and it's on the 
>> screen in a tk window).
>>
>> So, number 3 seems to point to the symptom that in the handoff between 
>> matplotlib and pyplot, the first figure created is getting lost.  Perhaps 
>> someone can point me to the next level so I can keep trying to diagnose 
>> this.
>>
>> It seems folks aren't so interested in problems that are rarely seen and 
>> are reported by Noobs.  We were all once noobs. I may be a permanent noob.  
>> I realize there are cooler things to focus on in the future trajectory of 
>> Julia, but this is an actual problem.
>>   
>>
>> On Monday, November 9, 2015 at 11:07:50 AM UTC-8, Ethan Anderes wrote:
>>>
>>> I have noticed something similar. 
>>>
>>> For example, if I do:
>>>
>>> julia> using PyPlot
>>>
>>> julia> figure(1)
>>>
>>> julia> plot(sin(1:10))
>>>
>>> julia> figure(2)
>>>
>>> julia> plot(cos(1:10))
>>>
>>> then close the first figure (by clicking the red button with my mouse) I 
>>> get a spinning beach ball. I’m on OSX 10.11.1 using Anaconda python. PyPlot 
>>> is at version "PyPlot"=>v"2.1.1+" and my system info is
>>>
>>> julia> versioninfo()
>>> Julia Version 0.4.1-pre+16
>>> Commit 2cdef5d (2015-10-24 06:33 UTC)
>>> Platform Info:
>>>   System: Darwin (x86_64-apple-darwin15.0.0)
>>>   CPU: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>>>   LAPACK: libopenblas64_
>>>   LIBM: libopenlibm
>>>   LLVM: libLLVM-3.3
>>>
>>>
>>> ​
>>>
>>
>

[julia-users] Re: PyPlot won't close first figure drawn

[lewis]

I'd still really like help with this.

Here are some possible problems with the way just the first figure is being 
handled within PyPlot:
 1.being put in the figure_queue, which holds figures for IJulia--this 
shouldn't be happening as I am not using IJulia in this case;
 2.   somehow matplotlib is losing it: the close() function in PyPlot is a 
straightforward pycall to put[:close]--with a figure argument f.  But, when 
you plot without defining a figure first there is no figure to reference. 
 Calls to close don't pass any argument.  It's not clear why this would be 
a problem because everything works for the 2nd and all subsequent plots 
created WITHOUT first starting an identified figure.  
3.  gcf() can't find the figure.  When I run gcf after the first plot, it 
actually creates a NEW figure because it doesn't see that any figure exists 
(even though it is there because matplotlib created it and it's on the 
screen in a tk window).

So, number 3 seems to point to the symptom that in the handoff between 
matplotlib and pyplot, the first figure created is getting lost.  Perhaps 
someone can point me to the next level so I can keep trying to diagnose 
this.

It seems folks aren't so interested in problems that are rarely seen and 
are reported by Noobs.  We were all once noobs. I may be a permanent noob. 
 I realize there are cooler things to focus on in the future trajectory of 
Julia, but this is an actual problem.
  

On Monday, November 9, 2015 at 11:07:50 AM UTC-8, Ethan Anderes wrote:
>
> I have noticed something similar. 
>
> For example, if I do:
>
> julia> using PyPlot
>
> julia> figure(1)
>
> julia> plot(sin(1:10))
>
> julia> figure(2)
>
> julia> plot(cos(1:10))
>
> then close the first figure (by clicking the red button with my mouse) I 
> get a spinning beach ball. I’m on OSX 10.11.1 using Anaconda python. PyPlot 
> is at version "PyPlot"=>v"2.1.1+" and my system info is
>
> julia> versioninfo()
> Julia Version 0.4.1-pre+16
> Commit 2cdef5d (2015-10-24 06:33 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin15.0.0)
>   CPU: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
>
> ​
>

[julia-users] Re: no one knows this.....

[lewis]

Thanks!

On Thursday, October 29, 2015 at 8:22:32 PM UTC-7, Steven G. Johnson wrote:
>
> A direct translation of the Python code works fine for me (with the 
> default TkAgg backend on MacOS):
>
> one = figure(1)
> plot(1:4)
> two = figure(2)
> scatter(randn(25),randn(25))
> figure(1)
> title("Title")
>
> wm = get_current_fig_manager()
> wm[:window][:attributes]("-topmost", 1)
> wm[:window][:attributes]("-topmost", 0)
>
>
> Everyone using PyPlot and PyCall should read this sentence from the PyCall 
> README five times:
>
> The biggest diffence from Python is that object attributes/members are 
> accessed with o[:attribute] rather than o.attribute
>
>

[julia-users] PyPlot won't close first figure drawn

[lewis]

Not getting any answers to a weird problem.

PyPlot won't close the first figure it creates.  Subsequent figures can be 
created and closed.  gcf will not return a valid id for the first figure 
drawn.  plt[:get_fignums]() won't return a value for the first figure 
(e.g.--the first figure is not included in the returned vector of figures). 
 The only way to close the orphaned figure is to exit Julia.  Further if 
you click on the figure window and try to manually close it you will get an 
infinite spinning beach ball.  You can, however, switch back to Julia repl, 
which is happily running just fine.

This is part of a script that draws figures with interactive on and clears 
them with a user prompt. It is sort of annoying that the first one can 
never be closed.  The same symptom can be observed using Julia 
interactively:

using PyPlot
plot(1:5)  # -> figure draws fine in a tk window
close() # -> nothing happens
scatter(rand(25),rand(25)) # -> draws just fine
close() #-> closes the scatter as you'd expect and only the first figure 
remains
close() # -> nothing happens

You can explicitly create the first figure with figure() or figure(1) and 
the same problem occurs.

Environment:
os x 10.11.1 ("el capitan")
python 2.7.10 from www.python.org
matplotlib 1.5.0 and dependencies (via pip)
numpy 1.10.1 (via pip)
Julia 0.4.0
latest PyCall & PyPlot (with backend :tk)
xquartz 2.7.8 (latest per "upgrade..." on about box)
tk 8.5.18 (latest from ActiveState)

This does not occur when conda installs its own Python--same version, 
except built by Continuum, with equivalent versions of all Python packages 
 I don't consider just using conda an appropriate solution, as that seems 
to be avoiding finding an answer.  As of 2 weeks ago there was no problem 
so something (not clear what) changed in the mean time.  There is a path to 
this Python as: /Library/Frameworks/Python.framework/Versions/2.7/bin which 
is the first directory in PATH. (Note: this is NOT the system python which 
is at /system/library/...).  Also, I can't switch to Winston or Gadfly as I 
need surface plots and contour plots--PyPlot to matplotlib is the only way 
to create these from Julia that I am aware of.

When installing PyCall and PyPlot the comment output identifies this 
version of Python.

I am trying to sort out the figure logic in PyPlot.jl but it is hard for me 
to figure (no pun intended) it out.

Of course, I'll provide any and all additional information about my 
configuration, etc and can try other things to help diagnose this weird 
thing.

Thanks,
Lewis

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

[lewis]

I did not build Julia from source.  But, I am back in business using system 
Python.  Never got conda to build everything on Windows.

On Wednesday, November 4, 2015 at 2:19:18 PM UTC-8, Luke Stagner wrote:
>
> It will only work if you installed from source(I.e cloned the main Julia 
> repository and manually compiled). If you did that the directory would 
> usually be in your home directory.
> On Nov 4, 2015 2:10 PM, > wrote:
>
>> I have setup PyCall using a system Python (2.7.10).  I get ERROR: 
>> ArgumentError: haskey of NULL PyObject
>>  in plot at C:\Users\Lewis\.julia\v0.4\PyPlot\src\PyPlot.jl:457
>>
>> Matplotlib works fine in IPython.
>>
>> I'm stuck.  Which directory needs git clean?
>>
>> On Wednesday, November 4, 2015 at 2:03:32 PM UTC-8, Luke Stagner wrote:
>>>
>>> I noticed it happened after I updated anaconda. Perhaps something went 
>>> wrong there
>>>
>>>
>>> On 11/04/2015 02:01 PM, le...@neilson-levin.org wrote:
>>>
>>> I have the same problem.  I am going back to using a system Python and 
>>> giving up on conda.  Works fine on Mac (par for the course that things tend 
>>> to work on Mac).  I previously had Julia using matplotlib using WinPython.  
>>> Wanted to try the conda approach.  Too many problems, though.  Hours later 
>>> after uninstalling .julia and uninstalling Julia itself and starting over 
>>> still can't get it to build and run. 
>>>
>>> On Tuesday, November 3, 2015 at 5:16:45 AM UTC-8, jda wrote: 
>>>>
>>>> Nope, still the same haskey of NULL error.
>>>>
>>>
>>>

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

[lewis]

I have setup PyCall using a system Python (2.7.10).  I get ERROR: 
ArgumentError: haskey of NULL PyObject
 in plot at C:\Users\Lewis\.julia\v0.4\PyPlot\src\PyPlot.jl:457

Matplotlib works fine in IPython.

I'm stuck.  Which directory needs git clean?

On Wednesday, November 4, 2015 at 2:03:32 PM UTC-8, Luke Stagner wrote:
>
> I noticed it happened after I updated anaconda. Perhaps something went 
> wrong there
>
>
> On 11/04/2015 02:01 PM, le...@neilson-levin.org  wrote:
>
> I have the same problem.  I am going back to using a system Python and 
> giving up on conda.  Works fine on Mac (par for the course that things tend 
> to work on Mac).  I previously had Julia using matplotlib using WinPython. 
>  Wanted to try the conda approach.  Too many problems, though.  Hours later 
> after uninstalling .julia and uninstalling Julia itself and starting over 
> still can't get it to build and run. 
>
> On Tuesday, November 3, 2015 at 5:16:45 AM UTC-8, jda wrote: 
>>
>> Nope, still the same haskey of NULL error.
>>
>
>

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

[lewis]

I have the same problem.  I am going back to using a system Python and 
giving up on conda.  Works fine on Mac (par for the course that things tend 
to work on Mac).  I previously had Julia using matplotlib using WinPython. 
 Wanted to try the conda approach.  Too many problems, though.  Hours later 
after uninstalling .julia and uninstalling Julia itself and starting over 
still can't get it to build and run. 

On Tuesday, November 3, 2015 at 5:16:45 AM UTC-8, jda wrote:
>
> Nope, still the same haskey of NULL error.
>

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

[lewis]

What directory is the julia repository in?

On Wednesday, November 4, 2015 at 1:37:19 PM UTC-8, Luke Stagner wrote:
>
> I recently had a similar error. To fix it I had to do 
> git clean -xdf
>
> in the julia repository if you installed from source
>
> I found the fix in this PyCall issue 
> https://github.com/stevengj/PyCall.jl/issues/65
>
>
> On Wednesday, November 4, 2015 at 11:58:53 AM UTC-8, Tom Breloff wrote:
>>
>> You probably have a corrupted cache from whatever you were manually 
>> changing.  I recommend just deleting your "~/.julia/v0.4" and starting 
>> again.  I just did this on my windows machine (just to make sure it's not a 
>> Plots issue) and after doing only "Pkg.add("Plots"); using Plots" it 
>> completes without error.
>>
>> I don't think you necessarily need to be on master for PyCall/PyPlot.  
>> After starting fresh, try just `Pkg.add("PyCall"); Pkg.add("PyPlot")` and 
>> see if that works for you.
>>
>> On Wed, Nov 4, 2015 at 2:34 PM, jda  wrote:
>>
>>> I did Pkg.checkout("PyCall"); Pkg.build("PyCall") and PyCall is now 
>>> version 1.1.2 master.  The using Plots command still gives the error:
>>>
>>>   
>>> ERROR:  ArgumentError:  Docile not found in path
>>>   in require at loading.jl:233
>>>   in stale_cachefile at loading.jl:439
>>>   in recompile_stale at loading.jl:457
>>>   in _require_from_serialized at loading.jl:83
>>>   in _require_from_serialized at loading.jl:109
>>>   in require at loading.jl:219
>>>
>>>
>>

Re: [julia-users] Anaconda Python

[lewis]

I have built it all on Mac.  It really was quite terrible--put it all in a 
bash script and its worse yet on Windows--I tried and quickly went to 
WinPython or PythonXY in preference to Anaconda or ActiveState, both of 
which I also tried. I am glad that I don't have to any more. Haven't had to 
for about a year and a half.  Which is why we do want a decent approach to 
binary distribution.   I agree that forking as a way to test innovation 
with an intention to eventually re-integrate is a fine way to make 
progress.  A permanent fork, on the other hand, seems undesirable though it 
happens for a variety of reasons.  

It appears that Python has stepped up to this, if belatedly and 
incompletely.  There are pre-built binaries available for Mac and Windows 
for numpy, matplotlib, scipy, and pandas provided by the maintainers of 
those packages.  These folks have stepped up and contributed a lot.  There 
are wheels for Mac and Windows for all of them--except Numpy on Windows. 
 In general, according to the scipy umbrella website, these binaries are 
targeted to the PSF binary distributions (2.7.10 and 3.5.0--with earlier 
versions available in many cases).  I am afraid that Linux is more 
challenging though in some cases the package repos for the major distros 
offer binaries though those are likely to lag. I think the recent breakage 
in some Python packages has occurred in the cycle of upgrading to work with 
Python 2.7.10 and 3.5.0.  Despite improvement it remains messy.

If Julia weren't so very good at integrating other things--Python, C, R, 
and using git as a package manager--we wouldn't be having the discussion. 
 We are having it because Julia's core team carefully invested where it 
should--in the defining innovations of the language--while finding very 
efficient ways to bootstrap some of the maintenance "machinery" and 
leveraging other platforms for needed capabilities.  The pace of progress, 
as a result, is simply astonishing for a language--really a nascent 
ecosystem--that has been here such a short time.

There are still issues managing large binary dependencies, but it must be 
done because having thousands of people build very large libraries doesn't 
make sense. I think Julia user-developers want to use the capabilities 
Julia provides without becoming sys admins.  Sounds like the Julia core 
team has some ideas for this, especially for statically compiled pure Julia 
packages (bring'em on!).  As to preferences for Python distributions, it 
seems a few things occasionally break when using PSF Python distro with pip 
managed packages.  It used to work; it will get sorted out.  Relying 
exclusively on a quasi-proprietary distro for the long-term doesn't seem 
like a good thing, though it has been expedient as an option and it is fine 
to have more than one option.  It makes sense for Julia to provide a 
self-contained Python for Julia users, especially for matplotlib/PyPlot.jl 
but also because it is so easy to use PyCall for lots of things.

I stirred up a rat's nest here and I am dropping it. In a way, this is more 
of an issue for the Python community than the Julia community.  Julia has 
adopted a new approach with more up to date and broadly adopted tooling 
(git--though the binary issue remains) which allows for much more rapid 
progress.  

On Monday, November 2, 2015 at 8:52:39 PM UTC-8, Isaiah wrote:
>
>  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 

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.

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

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

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

[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] 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.

[julia-users] Re: no one knows this.....

[lewis]

Here is some code:

using PyPlot

function chartplay()
one = figure(1)
plot(1:4)
two = figure(2)
scatter(randn(25),randn(25))
figure(1)
title("Title")
plt[:show]()
wm = get_current_fig_manager() 
dump(wm)
#= python code to get a plot figure window to be topmost.
I could not figure out how to do these calls
wm = plt.get_current_fig_manager() 
wm.window.attributes('-topmost', 1)
wm.window.attributes('-topmost', 0)
=#

#= attempt to use via julia PyPlot -- didn't work
plt[:window](wm, "-topmost", 1)
plt[:window](wm, "-topmost", 0)
# figure 1 should be either the top window of all or at least 
"above" figure 2
=#
end

[julia-users] Re: no one knows this.....

[lewis]

Here are some of the solutions proposed for matplotlib:

with qt4agg backend:

fig = gcf()
fig.canvas.manager.window.raise_()


Here is one that works with tk backend:

import matplotlib.pyplot as plt
wm = plt.get_current_fig_manager() 
wm.window.attributes('-topmost', 1)
wm.window.attributes('-topmost', 0)


So, that is what I meant by gyrations.  I'll put the second on in a code 
fragment and post in a second.

[julia-users] spurious update

[lewis]

This happens every once in a while:

Oct 27 19:05:21  julia[83314] : void CGSUpdateManager::log() 
const: conn 0x1ff43: spurious update.


This is the result of producing a PyPlot chart figure.  


Any one know why this happens?

[julia-users] no one knows this.....

[lewis]

Using pyplot with multiple figures, choose one to display as the topmost 
window. There are crazy gyrations in matplotlib that only work with certain 
backends.

Generally, Julia makes the matplotlib API much nicer.  Once the whole thing 
loads it is quick enough.

But, this very basic thing seems almost impossible.

Things that don't work:
figure(1)

figure(1)
plt[:show]()

plt[:show](1)

I am out of things to try.

[julia-users] Re: Interest in a Seattle-Area Julia Meetup?

[lewis]

Happy also to join.

On Monday, October 19, 2015 at 8:47:06 PM UTC-7, Daniel Jones wrote:
>
> Count me in! I'm happy to present something as well. I know of a few Julia 
> users at UW, not all of whom are necessarily on github, so I suspect 
> there'd be more than 9 people interested.
>
>
> On Monday, October 19, 2015 at 12:46:02 PM UTC-7, tim@multiscalehn.com 
> wrote:
>>
>> I work for a company where we are big fans of Julia, and are using it for 
>> several projects. We have thrown around the idea of hosting a meetup. We 
>> have the space and the resources to put it on, and could provide some good 
>> content. I know there are some active Julia devs at the UW but I wanted to 
>> put out feelers to see who might be interested in attending, or even 
>> better, giving a talk or demo. I guarantee a good time will be had by all.
>>
>> - Tim
>>
>

[julia-users] colors on cmd on Windows 10

[Lewis Levin]

Running Julia in powershell or cmd, the background color of output lines is 
always black.  If you set cmd or powershell to black this is fine.  With 
any other default background color, you get Julia output written on black 
bands across the window.

I installed cmder (very nice thing).  It is a Conemu with clink and other 
improvements. Small download and portable install on windows.  very clean.

Since cmder is a unix shell, Julia works nicely with it and inherits  the 
shell colors:  always looks good.

Probably should fix for windows users.  (I am Mac and Windows.)

Julia is way slower on Windows and I am using a very fast Win machine with 
flash drive.

[julia-users] Re: What is the right path to Python

[lewis]

Solved.  the answer is  provide path pointing directly to the python 
executable.


>

[julia-users] Re: What is the right path to Python

[lewis]

Never mind.  This was a 64 bit to 32 bit conflict.  Message didn't help, 
but a bunch of searches did.  Comment on doc stands, but user error was the 
culprit.

On Thursday, October 15, 2015 at 3:02:54 PM UTC-7, le...@neilson-levin.org 
wrote:
>
> For building PyCall and other integrations to Python, need to set:
>
> let user_data_dir
> ENV["PATH"] = 
> JULIA_HOME*";"*joinpath(JULIA_HOME,"..","Git","bin")*";"*ENV["PATH"]
> #haskey(ENV,"JULIA_EDITOR") || (ENV["JULIA_EDITOR"] = "start") #start 
> is not a program, so this doesn't work
> ENV["PYTHON"] = "C:\\Program Files 
> (x86)\\WinPython-32bit-2.7.9.5\\python-2.7.9\\python.exe"
> end
>
> EXACTLY what must the path in ENV["PYTHON"] point to?  Please don't 
> recommend conda, ok?   I have 2 installs to Python already with lots of 
> packages, including Matplotlib and Numpy.  Don't want to manage yet another.
>
> Should the path point to the python executable?  It's dll?  Or to the 
> directory that contains the python executable.   PyCall documentation is 
> rather vague on the point:  If you want to use a different version of 
> Python on your system, you can change the Python version by setting the 
> PYTHON environment variable and then re-running Pkg.build("PyCall"). In 
> Julia:
>
> ENV["PYTHON"] = "... path of the python program you want ..."
> Pkg.build("PyCall")
>
> That's a little bit too loose. Path directly to the exe or to the folder 
> containing the exe. I've tried both and neither
> see to work.
>
>

[julia-users] Re: What is the right path to Python

[lewis]

With path to the exe, this is what I get:

LoadError: Couldn't find libpython; check your PYTHON environment variable
while loading C:\Users\Lewis\.julia\v0.4\PyCall\deps\build.jl, in 
expression starting on line 17

So, the path needs  to be to something else.

Of course, the real solution is the include the right path in the system 
PATH variable.  I have paths to the exe, to scripts, and to site packages, 
which is the standard thing to do. But, Julia doesn't agree with this.

Lots of  wasted  frustration on something that should  be simple but for 
clearer documentation.

On Thursday, October 15, 2015 at 3:02:54 PM UTC-7, le...@neilson-levin.org 
wrote:
>
> For building PyCall and other integrations to Python, need to set:
>
> let user_data_dir
> ENV["PATH"] = 
> JULIA_HOME*";"*joinpath(JULIA_HOME,"..","Git","bin")*";"*ENV["PATH"]
> #haskey(ENV,"JULIA_EDITOR") || (ENV["JULIA_EDITOR"] = "start") #start 
> is not a program, so this doesn't work
> ENV["PYTHON"] = "C:\\Program Files 
> (x86)\\WinPython-32bit-2.7.9.5\\python-2.7.9\\python.exe"
> end
>
> EXACTLY what must the path in ENV["PYTHON"] point to?  Please don't 
> recommend conda, ok?   I have 2 installs to Python already with lots of 
> packages, including Matplotlib and Numpy.  Don't want to manage yet another.
>
> Should the path point to the python executable?  It's dll?  Or to the 
> directory that contains the python executable.   PyCall documentation is 
> rather vague on the point:  If you want to use a different version of 
> Python on your system, you can change the Python version by setting the 
> PYTHON environment variable and then re-running Pkg.build("PyCall"). In 
> Julia:
>
> ENV["PYTHON"] = "... path of the python program you want ..."
> Pkg.build("PyCall")
>
> That's a little bit too loose. Path directly to the exe or to the folder 
> containing the exe. I've tried both and neither
> see to work.
>
>

[julia-users] What is the right path to Python

[lewis]

For building PyCall and other integrations to Python, need to set:

let user_data_dir
ENV["PATH"] = 
JULIA_HOME*";"*joinpath(JULIA_HOME,"..","Git","bin")*";"*ENV["PATH"]
#haskey(ENV,"JULIA_EDITOR") || (ENV["JULIA_EDITOR"] = "start") #start 
is not a program, so this doesn't work
ENV["PYTHON"] = "C:\\Program Files 
(x86)\\WinPython-32bit-2.7.9.5\\python-2.7.9\\python.exe"
end

EXACTLY what must the path in ENV["PYTHON"] point to?  Please don't 
recommend conda, ok?   I have 2 installs to Python already with lots of 
packages, including Matplotlib and Numpy.  Don't want to manage yet another.

Should the path point to the python executable?  It's dll?  Or to the 
directory that contains the python executable.   PyCall documentation is 
rather vague on the point:  If you want to use a different version of 
Python on your system, you can change the Python version by setting the 
PYTHON environment variable and then re-running Pkg.build("PyCall"). In 
Julia:

ENV["PYTHON"] = "... path of the python program you want ..."
Pkg.build("PyCall")

That's a little bit too loose. Path directly to the exe or to the folder 
containing the exe. I've tried both and neither
see to work.

Re: [julia-users] Get an array or just a string of all installed Julia packages

[lewis]

Great.  Thanks.

When you say (new installation) Pkg.update() what is (new installation) 
on the command line?  Does it mean cd over there first?

On Sunday, October 11, 2015 at 3:08:12 AM UTC-7, Tim Holy wrote:
>
> Try this: 
> (new installation) Pkg.init() 
> cp OldInstallation/.julia/v0.4/REQUIRE NewInstallation/.julia/v0.4/ 
> (new installation) Pkg.update() 
>
> As for your original question, collect(keys(Pkg.installed())) should do 
> what 
> you ask. 
>
> --Tim 
>
> On Saturday, October 10, 2015 12:47:01 PM le...@neilson-levin.org 
>  wrote: 
> > I would like to generate a list of all the packages I've installed. 
>  Each 
> > time I install Julia (which I've done a lot recently, but will settle 
> down 
> > now that 0.4.0 is released--Yeah!) I need to install packages again.  It 
> > would be nice to have a list.  It would be nicer to be able to install 
> them 
> > as a batch, but since makes take a long time and can be fragile I am OK 
> > without a batch. 
> > 
> > Basically, I want pip freeze > mypkgs.txt within the Julia repl. 
> >  Unfortunately, since Pkg.status is ::void it produces no output to 
> > capture.  I tried pipeline.  No go. 
> > 
> > Should be easy;  seems an obvious request.  Writing a little Julia 
> script 
> > is a fine solution, but without being able to capture Pkg.status not 
> sure 
> > what it would look like. 
> > 
> > Thanks 
>
>

[julia-users] Get an array or just a string of all installed Julia packages

[lewis]

I would like to generate a list of all the packages I've installed.  Each 
time I install Julia (which I've done a lot recently, but will settle down 
now that 0.4.0 is released--Yeah!) I need to install packages again.  It 
would be nice to have a list.  It would be nicer to be able to install them 
as a batch, but since makes take a long time and can be fragile I am OK 
without a batch.

Basically, I want pip freeze > mypkgs.txt within the Julia repl. 
 Unfortunately, since Pkg.status is ::void it produces no output to 
capture.  I tried pipeline.  No go.

Should be easy;  seems an obvious request.  Writing a little Julia script 
is a fine solution, but without being able to capture Pkg.status not sure 
what it would look like.

Thanks

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[lewis]

I know it may feel to the insiders/developers that the requestors are being 
a bit dogmatic with expectations from other languages.

2 cautions:
1.  Insiders need to be careful not to be defensive:  converts are here 
because they are fans and evangelists (potentially) in their community. 
Gotchas hurt that evangelism subtly.  And insiders need to also be careful 
that they don't only listen to POV that is entirely julian (even though 
there is much good in julian).  "Noobs" will never seem as cogent or 
knowledgeable in these discussion as insiders (no disrespect meant to any 
poster!).  But, we were all once noobs (I am sort of perpetually there...).

2. Now is the time to really think it through.  As the language matures and 
gains more users it gets harder and harder to make such changes. So as 
entrenched as positions may tend to get--be diplomatic and understanding. 
 This is just one decision, but a whole set of these decisions make an 
impact on the language. A priority on clarity and ease of programming is 
really important--more so than a too early focus on optimization. 
 Whichever approach is adopted, some sort of optimization is later possible 
(to a point--needing memory to hold an instantiated vector is a harder 
thing to optimize).

Julians are really great for be willing to discuss and consider options so 
openly.  

[julia-users] Re: Julia 0.4.0-rc4 abstract types in functional signatures don't seem to work

[lewis]

Yup.  Thanks Kristoffer.  I did a few more little things in julia and 
figured it out before I saw your post:

function(x::Real, y::Real)
return 2x - y
end

function(x::Real, y::Array{Real, 1})
return 2x - y[1]
end

First one works; second one does not.

It is the use of Array, a compound object.  I guess that means types aren't 
covariant (is that the right term?).  It's unfortunate.  ML and some of the 
lisps would probably handle it.  It's not a big deal.  It is documented but 
you sort of have to put a few concepts together.  It's sort of cool that 
the parametric type function signature DOES work.  Less familiar concept to 
code, but the user of the method doesn't see it.

On Thursday, October 8, 2015 at 2:43:08 AM UTC-7, Kristoffer Carlsson wrote:
>
> There is a difference between an abstract type like Number and a type 
> parameterized by an abstract types like Vector{Number}.
>
> While it is true that for example Float64 is a subtype of Number it is not 
> true that Vector{Float64} is a subtype of Vector{Number}.
>
>
>
> On Thursday, October 8, 2015 at 11:35:05 AM UTC+2, le...@neilson-levin.org 
> wrote:
>>
>> Thanks Tomas, but what you are saying seems to violate the manual.
>>
>> Here is the verbatim example:
>>
>> (from Chapter 12, "Methods", page 104)
>>
>> As you can see, the arguments must be precisely of type Float64. Other 
>> numeric types, such as integers or 32- bit floating-point values, are not 
>> automatically converted to 64-bit floating-point, nor are strings parsed as 
>> numbers. Because Float64 is a concrete type and concrete types cannot be 
>> subclassed in Julia, such a definition can only be applied to arguments 
>> that are exactly of type Float64. It may often be useful, however, to 
>> write more general methods where the declared parameter types are abstract: 
>>
>>
>> julia> f(x::Number, y::Number) = 2x - y;
>>
>> julia> f(2.0, 3)1.0
>>
>>
>> This method definition applies to any pair of arguments that are 
>> instances of Number. They need not be of the same type, so long as they 
>> are each numeric values. The problem of handling disparate numeric types is 
>> delegated to the arithmetic operations in the expression2x - y. 
>>
>>
>> Can't see how that is different than my use of the abstract type Real. 
>>  In fact, the above example from the manual naturally works with Real.
>>
>>
>> Is there something special about one-line function definitions?
>>
>> I think my objection stands unless there are more rules or I missed 
>> something and defined the function incorrectly or did the type restriction 
>> incorrectly.
>>
>> Still confused.
>>
>

[julia-users] Re: Julia 0.4.0-rc4 abstract types in functional signatures don't seem to work

[lewis]

Thanks Tomas, but what you are saying seems to violate the manual.

Here is the verbatim example:

(from Chapter 12, "Methods", page 104)

As you can see, the arguments must be precisely of type Float64. Other 
numeric types, such as integers or 32- bit floating-point values, are not 
automatically converted to 64-bit floating-point, nor are strings parsed as 
numbers. Because Float64 is a concrete type and concrete types cannot be 
subclassed in Julia, such a definition can only be applied to arguments 
that are exactly of type Float64. It may often be useful, however, to write 
more general methods where the declared parameter types are abstract: 


julia> f(x::Number, y::Number) = 2x - y;

julia> f(2.0, 3)1.0


This method definition applies to any pair of arguments that are instances 
of Number. They need not be of the same type, so long as they are each 
numeric values. The problem of handling disparate numeric types is 
delegated to the arithmetic operations in the expression2x - y. 


Can't see how that is different than my use of the abstract type Real.  In 
fact, the above example from the manual naturally works with Real.


Is there something special about one-line function definitions?

I think my objection stands unless there are more rules or I missed 
something and defined the function incorrectly or did the type restriction 
incorrectly.

Still confused.

[julia-users] Julia 0.4.0-rc4 abstract types in functional signatures don't seem to work

[lewis]

Here is a simple function to evaluate a polynomial. Different potential 
function signatures are shown in the commented lines:


# 1 function p{T<:Real, Y<:Real}(x::T, coeff::Array{Y,1}) # this works
# 2 function p(x::Real, coeff::Array{Real,1}) # DOES NOT WORK
# 3 function p(x::Any, coeff::Array{Any,1}) # DOES NOT WORK

function p(x, coeff) # works but you better use it right
px = 0
for (i,v) in enumerate(coeff)
px += v * x^(i-1)
end
return px
end




Here are the results I observed:
1. The parametric type used for the parameter types works. Both the input 
value x and the array of coeffs must be real AND they can be different 
sub-types of real.

2. This seems like it SHOULD work but it does not. Example of output: 

*julia> **include("polyeval.jl")*

*p (generic function with 1 method)*


*julia> **methods(p)*

*# 1 method for generic function "p":*

*p(x::Real, coeff::Array{Real,1}) at 
/Users/lewislevinmbr/Dropbox/julia-code/just-learning/polyeval.jl:5*


*julia> **p(2.1,[1,1.0])*

*ERROR: MethodError: `p` has no method matching p(::Float64, 
::Array{Float64,1})*

Closest candidates are:

  p(::Real, *::Array{Real,1}*)

 
The problem appears to be that the concrete types of the arguments are not 
being mapped to the abstract types of the function parameters. All examples 
I see in documentation suggest this should work. Am I doing something wrong 
here? 

3. This looks like it should work. It should match the last, uncommented 
function signature allowing any argument types. I say work in the sense it 
should have no compile time exception and should accept any argument types. 
It is likely to generate runtime errors for lots of inputs. But, it 
produces a MethodError always. 

4. This function signature doesn't type the parameters. It should 
operationally be the same as 3. Naturally, it runs with the same caveat 
about runtime errors. 

What's going on here?

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[lewis]

Seems a bad idea even as syntactic sugar, except for the case of using 
PyCall (when the target language is loosely object oriented).

If you prefer object oriented dispatch, many languages offer it.  With 
strong typing, optionally as Julia provides, OO dispatch can off make class 
inheritance very difficult.  I realize the OP has no issue with multiple 
dispatch and wants to preserve it and the syntactic sugar would rarely, if 
ever interfere with it.  Since multiple dispatch is expressed with function 
call syntax, Julia should stick to that.  While I wouldn't want Julia to go 
too wild down the functional programming path, the key benefits of FP that 
Julia provides--namely, multiple dispatch, 1st class functions, and 
closures--are really great and handily fit a language with a more 
imperative style.

In Python (I still love Python), x.f(y) is really just syntactic sugar for 
f(x,y).  It almost seems silly to have it at all.  And since Julia is even 
less OO than Python, which is to say not at all then it seems almost 
misleading to mimic the OO syntax since OO is definitely NOT what is 
happening under the hood.

While I realize the OP is not really asking for it, it is still worth 
pointing out that there seems little benefit to going down the OO path.

[julia-users] Re: Can't build Cairo

[lewis]

See later:  email.  Tony is right and the work has been done by Meris and 
Elliott over at github staticfloat/juliadeps.


On Monday, October 5, 2015 at 12:49:50 PM UTC-7, le...@neilson-levin.org 
wrote:
>
> This must be the most reported problem with Julia packages.  Perhaps we've 
> allowed the dependency stack to become much too long.  Typically the error 
> trace is impenetrable to anyone but one of the package maintainers, and 
> often not them because it's in a deeper dependency for which they're not 
> responsible.  Something to think about long term as Julia becomes more 
> widely used. This sort of stuff can drive people away quickly to more 
> reliable stacks such as R and Python.  (Not saying better or that we can't 
> use multiple tools, just that this kind of package mgmt. fragility is not a 
> good thing.)
>
> Mac OS X el capitan
>
> julia-0.4.0-rc4
>
> Here are the messages:
>
> *==>** Installing staticfloat/juliadeps/cairo dependency: *
> *staticfloat/juliadeps/pixma*
>
> *==>** Downloading http://cairographics.org/releases/pixman-0.32.6.tar.gz 
> *
>
> Already downloaded: 
> /Users/lewislevinmbr/Library/Caches/Homebrew.jl/pixman-0.32.6.tar.gz
>
> *==>** ./configure --disable-silent-rules 
> --prefix=/Users/lewislevinmbr/.julia/v0.4/Homebrew*
>
> *==>** make install*
>
> Last 15 lines from 
> /Users/lewislevinmbr/Library/Logs/Homebrew/pixman/02.make:
>
> /bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
> -I.. -g -O2 -Wall -Wdeclaration-after-statement -fno-strict-aliasing 
> -fvisibility=hidden -c -o pixman-utils.lo pixman-utils.c
>
> libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall 
> -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -c 
> pixman-utils.c  -fno-common -DPIC -o .libs/pixman-utils.o
>
> /bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
> -I..-mmmx -Winline -g -O2 -Wall -Wdeclaration-after-statement 
> -fno-strict-aliasing -fvisibility=hidden -c -o 
> libpixman_mmx_la-pixman-mmx.lo `test -f 'pixman-mmx.c' || echo 
> './'`pixman-mmx.c
>
> libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -mmmx -Winline -g -O2 
> -Wall -Wdeclaration-after-statement -fno-strict-aliasing 
> -fvisibility=hidden -c pixman-mmx.c  -fno-common -DPIC -o 
> .libs/libpixman_mmx_la-pixman-mmx.o
>
> /bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
> -I..-msse2 -Winline -g -O2 -Wall -Wdeclaration-after-statement 
> -fno-strict-aliasing -fvisibility=hidden -c -o 
> libpixman_sse2_la-pixman-sse2.lo `test -f 'pixman-sse2.c' || echo 
> './'`pixman-sse2.c
>
> libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -msse2 -Winline -g -O2 
> -Wall -Wdeclaration-after-statement -fno-strict-aliasing 
> -fvisibility=hidden -c pixman-sse2.c  -fno-common -DPIC -o 
> .libs/libpixman_sse2_la-pixman-sse2.o
>
> libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall 
> -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -c 
> pixman-utils.c -o pixman-utils.o >/dev/null 2>&1
>
> pixman-mmx.c:100:20: error: constraint 'K' expects an integer constant 
> expression
>
> : "y" (__A), "K" (__N)
>
>   ^~~
>
> 1 error generated.
>
> make[1]: *** [libpixman_mmx_la-pixman-mmx.lo] Error 1
>
> make[1]: *** Waiting for unfinished jobs
>
> libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -msse2 -Winline -g -O2 
> -Wall -Wdeclaration-after-statement -fno-strict-aliasing 
> -fvisibility=hidden -c pixman-sse2.c -o libpixman_sse2_la-pixman-sse2.o 
> >/dev/null 2>&1
>
> make: *** [install-recursive] Error 1
>
>
> READ THIS: https://git.io/brew-troubleshooting
>
> If reporting this issue please do so at (not Homebrew/homebrew):
>
>   https://github.com/staticfloat/homebrew-juliadeps/issues
>
>
> Warning: 
>
> *[ ERROR: Cairo 
> ]=*
>
>
> *LoadError: failed process: 
> Process(`/Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/bin/brew 
> install --force-bottle staticfloat/juliadeps/cairo`, ProcessExited(1)) [1]*
>
> *while loading /Users/lewislevinmbr/.julia/v0.4/Cairo/deps/build.jl, in 
> expression starting on line 144*
>
>
>
> *=*
>
>
> *[ BUILD ERRORS 
> ]=*
>
>
> *WARNING: Cairo had build errors.*
>
>
> * - packages with build errors remain installed in 
> /Users/lewislevinmbr/.julia/v0.4*
>
> * - build the package(s) and all dependencies with `Pkg.build("Cairo")`*
>
> * - build a single package by running its `deps/build.jl` script*
>
>
>
> *=*
>
>
> *Looks like pixma is the culprit.  I had other problems with Julia 0.3.11. 
> Seems like 4.0 is getting so close that focus will shift.*
>
> *Suggest

[julia-users] Re: Cairo install problems

[lewis]

No, actually, it was different: the brew formula needs to be changed and a 
new "bottle" for el capitan had to be created.

But, it is solved due to Elliot and Meris' great work.  (and prompt...!)

[julia-users] Re: Cairo install problems

[lewis]

The nice people at Homebrew/juliadeps, aka staticfloat, aka Elliott Saba, 
merged the change into master and now the latest installs by default and 

*IT WORKS. *

[julia-users] Re: Cairo install problems

[lewis]

An update.  There is a pull request on juliadep at github for a new brew 
formula that fixes the problem. Unfortunately, staticfloat hasn't started 
creating bottles (binaries) for el capitan so no immediate solution.

However, the new formula is available as a commit.  Anyway I can get 
Homebrew.jl to use a specific commit from github.  Pkg.clone() doesn't seem 
to do it and there appears to be no way to get Homebrew to do it.

Guess I'll have to wait.

[julia-users] Re: Cairo install problems

[lewis]

I guess I am not quite ready to call this closed. Gadfly installed 
successfully without dependency Cairo.  But, of course, Cairo is needed for 
pdf and png output.  

Cairo won't install.  Now it gets stuck trying to install pixman.  Looks 
like a bug in the make file.  I won't bother pasting in the trace; I'll 
report over at Homebrew julia dev as recommended.

Comments about too many dependencies and too much fragility apply.

Julia needs a "native" graphics package (whatever "native" may mean...).



On Monday, October 5, 2015 at 12:49:50 PM UTC-7, le...@neilson-levin.org 
wrote:
>
>
>
> Posted, but for some reason the post disappeared as I am new to the group.
>
> Ran BinDep.debug("Cairo") --nice feature!--to see if I could figure out 
> more.  
>
> It suggests that dependencies that failed to build aren't needed on my 
> platform (which makes on wonder why any attempt to build them occurred...).
>
> Here is the output:
>
> *julia> **BinDeps.debug("Cairo")*
>
> *INFO: Reading build script...*
>
> The package declares 1 dependencies.
>
>  - Library Group "cairo"
>
>  - Library "png" (not applicable to this system)
>
>  - Library "pixman" (not applicable to this system)
>
>  - Library "ffi" (not applicable to this system)
>
>  - Library "gettext"
>
> - Satisfied by:
>
>   - Homebrew Bottles gettext at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libintl.dylib
>
>   - Homebrew Bottles gettext at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgettextpo.dylib
>
> - Providers:
>
>   - Homebrew Bottles gettext
>
>   - BinDeps.AptGet package gettext (can't provide)
>
>   - BinDeps.Yum package gettext-libs (can't provide)
>
>   - Autotools Build
>
>  - Library "gobject"
>
> - Satisfied by:
>
>   - Homebrew Bottles glib at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgobject-2.0.dylib
>
> - Providers:
>
>   - Homebrew Bottles glib
>
>   - BinDeps.AptGet package libglib2.0-0 (can't provide)
>
>   - BinDeps.Yum package glib2 (can't provide)
>
>   - Autotools Build
>
>  - Library "freetype" (not applicable to this system)
>
>  - Library "fontconfig" (not applicable to this system)
>
>  - Library "cairo"
>
> - Providers:
>
>   - Homebrew Bottles cairo
>
>   - BinDeps.AptGet package libcairo2 (can't provide)
>
>   - BinDeps.Yum package cairo (can't provide)
>
>   - Autotools Build
>
>  - Library "pango"
>
> - Providers:
>
>   - Homebrew Bottles pango
>
>   - BinDeps.AptGet package libpango1.0-0 (can't provide)
>
>   - BinDeps.Yum package pango (can't provide)
>
>   - Autotools Build
>
>  - Library "pangocairo"
>
> - Providers:
>
>   - Homebrew Bottles pango
>
>   - BinDeps.AptGet package libpango1.0-0 (can't provide)
>
>   - BinDeps.Yum package pango (can't provide)
>
>   - Autotools Build
>
>  - Library "zlib" (not applicable to this system)
>
>
> But, when I run using Cairo, it fails to precompile:
>
>
> *julia> **using Cairo*
>
> *INFO: Precompiling module Cairo...*
>
> ERROR: LoadError: could not open file 
> /Users/lewislevinmbr/.julia/v0.4/Cairo/src/../deps/deps.jl
>
>  in include at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  [inlined code] from none:2
>
>  in anonymous at no file:0
>
>  in process_options at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in _start at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
> while loading /Users/lewislevinmbr/.julia/v0.4/Cairo/src/Cairo.jl, in 
> expression starting on line 7
>
> *ERROR: Failed to precompile Cairo to 
> /Users/lewislevinmbr/.julia/lib/v0.4/Cairo.ji*
>
> * in error at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*
>
> * in compilecache at loading.jl:383*
>
> * in require at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*
>
>
> *The reason I want Cairo is for Gadfly.  This is just one of several 
> Gadfly dependencies that fail to build.  In my other post I pointed out 
> that this seems to become a serious general problem for the Julia 
> community.  The deep dependency stacks of packages lead to many failures 
> that are hard to debug leading to a general impression of fragility.  Since 
> there is not any reasonable "native" graphics package for Julia (though 
> PyPlot works quite well), we are thus compelled to the deep de

[julia-users] Re: Cairo install problems

[lewis]

OK.  Solved by the usual expedient of deleting .julia and starting over. 
 Not clear always what happens, but if you try to do too much to a new 
install of Julia (0.4.0-rc4 in this case) it just hasn't settled down.

I quickly got PyPlot and all dependencies and Gadfly and some of its 
dependencies installed.  Now I just need to test with pdf output to see if 
Cairo got installed.

Call it resolved and no new information that hasn't been reported many 
times before.

BTW, loving Julia.  I will post a benchmark of a machine learning 
simulation with Python, Cython, Pypy, Python/Numba, Nim (compiled).

Great syntax all 'round.  Speed without fussing.  Library support will 
happen.

On Monday, October 5, 2015 at 12:49:50 PM UTC-7, le...@neilson-levin.org 
wrote:
>
>
>
> Posted, but for some reason the post disappeared as I am new to the group.
>
> Ran BinDep.debug("Cairo") --nice feature!--to see if I could figure out 
> more.  
>
> It suggests that dependencies that failed to build aren't needed on my 
> platform (which makes on wonder why any attempt to build them occurred...).
>
> Here is the output:
>
> *julia> **BinDeps.debug("Cairo")*
>
> *INFO: Reading build script...*
>
> The package declares 1 dependencies.
>
>  - Library Group "cairo"
>
>  - Library "png" (not applicable to this system)
>
>  - Library "pixman" (not applicable to this system)
>
>  - Library "ffi" (not applicable to this system)
>
>  - Library "gettext"
>
> - Satisfied by:
>
>   - Homebrew Bottles gettext at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libintl.dylib
>
>   - Homebrew Bottles gettext at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgettextpo.dylib
>
> - Providers:
>
>   - Homebrew Bottles gettext
>
>   - BinDeps.AptGet package gettext (can't provide)
>
>   - BinDeps.Yum package gettext-libs (can't provide)
>
>   - Autotools Build
>
>  - Library "gobject"
>
> - Satisfied by:
>
>   - Homebrew Bottles glib at 
> /Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgobject-2.0.dylib
>
> - Providers:
>
>   - Homebrew Bottles glib
>
>   - BinDeps.AptGet package libglib2.0-0 (can't provide)
>
>   - BinDeps.Yum package glib2 (can't provide)
>
>   - Autotools Build
>
>  - Library "freetype" (not applicable to this system)
>
>  - Library "fontconfig" (not applicable to this system)
>
>  - Library "cairo"
>
> - Providers:
>
>   - Homebrew Bottles cairo
>
>   - BinDeps.AptGet package libcairo2 (can't provide)
>
>   - BinDeps.Yum package cairo (can't provide)
>
>   - Autotools Build
>
>  - Library "pango"
>
> - Providers:
>
>   - Homebrew Bottles pango
>
>   - BinDeps.AptGet package libpango1.0-0 (can't provide)
>
>   - BinDeps.Yum package pango (can't provide)
>
>   - Autotools Build
>
>  - Library "pangocairo"
>
> - Providers:
>
>   - Homebrew Bottles pango
>
>   - BinDeps.AptGet package libpango1.0-0 (can't provide)
>
>   - BinDeps.Yum package pango (can't provide)
>
>   - Autotools Build
>
>  - Library "zlib" (not applicable to this system)
>
>
> But, when I run using Cairo, it fails to precompile:
>
>
> *julia> **using Cairo*
>
> *INFO: Precompiling module Cairo...*
>
> ERROR: LoadError: could not open file 
> /Users/lewislevinmbr/.julia/v0.4/Cairo/src/../deps/deps.jl
>
>  in include at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  [inlined code] from none:2
>
>  in anonymous at no file:0
>
>  in process_options at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in _start at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib
>
> while loading /Users/lewislevinmbr/.julia/v0.4/Cairo/src/Cairo.jl, in 
> expression starting on line 7
>
> *ERROR: Failed to precompile Cairo to 
> /Users/lewislevinmbr/.julia/lib/v0.4/Cairo.ji*
>
> * in error at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*
>
> * in compilecache at loading.jl:383*
>
> * in require at 
> /Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*
>
>
> *The reason I want Cairo is for Gadfly.  This is just one of several 
> Gadfly dependencies that fail to build.  In my other post I pointed out 
> that this seems to become a serious general problem for the Julia 
> community.  The deep dependency stacks of packages lead to many failures 
> that are hard to debug leading to a 

[julia-users] Re: Cairo install problems

[lewis]

More cairo debugging.   Pkg.status() shows both Cairo and Gadfly as 
installed.
But, trying to use Cairo:

*julia> **using Gadfly*

*INFO: Precompiling module Gadfly...*

ERROR: LoadError: could not open file 
/Users/lewislevinmbr/.julia/v0.4/Cairo/src/../deps/deps.jl

Note the load error. Well, there is no such deps.jl anywhere in the Cairo 
package tree.  So, of course it can't be loaded.

I also installed cairo, successfully, with homebew outside of julia, but 
that doesn't help julia in the slightest.

This stuff seems rather fragile and the source of many problems.

[julia-users] Cairo install problems

[lewis]

Posted, but for some reason the post disappeared as I am new to the group.

Ran BinDep.debug("Cairo") --nice feature!--to see if I could figure out 
more.  

It suggests that dependencies that failed to build aren't needed on my 
platform (which makes on wonder why any attempt to build them occurred...).

Here is the output:

*julia> **BinDeps.debug("Cairo")*

*INFO: Reading build script...*

The package declares 1 dependencies.

 - Library Group "cairo"

 - Library "png" (not applicable to this system)

 - Library "pixman" (not applicable to this system)

 - Library "ffi" (not applicable to this system)

 - Library "gettext"

- Satisfied by:

  - Homebrew Bottles gettext at 
/Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libintl.dylib

  - Homebrew Bottles gettext at 
/Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgettextpo.dylib

- Providers:

  - Homebrew Bottles gettext

  - BinDeps.AptGet package gettext (can't provide)

  - BinDeps.Yum package gettext-libs (can't provide)

  - Autotools Build

 - Library "gobject"

- Satisfied by:

  - Homebrew Bottles glib at 
/Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/lib/libgobject-2.0.dylib

- Providers:

  - Homebrew Bottles glib

  - BinDeps.AptGet package libglib2.0-0 (can't provide)

  - BinDeps.Yum package glib2 (can't provide)

  - Autotools Build

 - Library "freetype" (not applicable to this system)

 - Library "fontconfig" (not applicable to this system)

 - Library "cairo"

- Providers:

  - Homebrew Bottles cairo

  - BinDeps.AptGet package libcairo2 (can't provide)

  - BinDeps.Yum package cairo (can't provide)

  - Autotools Build

 - Library "pango"

- Providers:

  - Homebrew Bottles pango

  - BinDeps.AptGet package libpango1.0-0 (can't provide)

  - BinDeps.Yum package pango (can't provide)

  - Autotools Build

 - Library "pangocairo"

- Providers:

  - Homebrew Bottles pango

  - BinDeps.AptGet package libpango1.0-0 (can't provide)

  - BinDeps.Yum package pango (can't provide)

  - Autotools Build

 - Library "zlib" (not applicable to this system)


But, when I run using Cairo, it fails to precompile:


*julia> **using Cairo*

*INFO: Precompiling module Cairo...*

ERROR: LoadError: could not open file 
/Users/lewislevinmbr/.julia/v0.4/Cairo/src/../deps/deps.jl

 in include at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

 in include_from_node1 at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

 in include at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

 in include_from_node1 at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

 [inlined code] from none:2

 in anonymous at no file:0

 in process_options at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

 in _start at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib

while loading /Users/lewislevinmbr/.julia/v0.4/Cairo/src/Cairo.jl, in 
expression starting on line 7

*ERROR: Failed to precompile Cairo to 
/Users/lewislevinmbr/.julia/lib/v0.4/Cairo.ji*

* in error at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*

* in compilecache at loading.jl:383*

* in require at 
/Applications/Julia-0.4.0-rc4.app/Contents/Resources/julia/lib/julia/sys.dylib*


*The reason I want Cairo is for Gadfly.  This is just one of several Gadfly 
dependencies that fail to build.  In my other post I pointed out that this 
seems to become a serious general problem for the Julia community.  The 
deep dependency stacks of packages lead to many failures that are hard to 
debug leading to a general impression of fragility.  Since there is not any 
reasonable "native" graphics package for Julia (though PyPlot works quite 
well), we are thus compelled to the deep dependency stacks.  So, 
that problem needs to be solved.  But, perhaps a higher priority is native 
graphics.*

[julia-users] Can't build Cairo

[lewis]

This must be the most reported problem with Julia packages.  Perhaps we've 
allowed the dependency stack to become much too long.  Typically the error 
trace is impenetrable to anyone but one of the package maintainers, and 
often not them because it's in a deeper dependency for which they're not 
responsible.  Something to think about long term as Julia becomes more 
widely used. This sort of stuff can drive people away quickly to more 
reliable stacks such as R and Python.  (Not saying better or that we can't 
use multiple tools, just that this kind of package mgmt. fragility is not a 
good thing.)

Mac OS X el capitan

julia-0.4.0-rc4

Here are the messages:

*==>** Installing staticfloat/juliadeps/cairo dependency: *
*staticfloat/juliadeps/pixma*

*==>** Downloading http://cairographics.org/releases/pixman-0.32.6.tar.gz*

Already downloaded: 
/Users/lewislevinmbr/Library/Caches/Homebrew.jl/pixman-0.32.6.tar.gz

*==>** ./configure --disable-silent-rules 
--prefix=/Users/lewislevinmbr/.julia/v0.4/Homebrew*

*==>** make install*

Last 15 lines from 
/Users/lewislevinmbr/Library/Logs/Homebrew/pixman/02.make:

/bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
-I.. -g -O2 -Wall -Wdeclaration-after-statement -fno-strict-aliasing 
-fvisibility=hidden -c -o pixman-utils.lo pixman-utils.c

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall 
-Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -c 
pixman-utils.c  -fno-common -DPIC -o .libs/pixman-utils.o

/bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
-I..-mmmx -Winline -g -O2 -Wall -Wdeclaration-after-statement 
-fno-strict-aliasing -fvisibility=hidden -c -o 
libpixman_mmx_la-pixman-mmx.lo `test -f 'pixman-mmx.c' || echo 
'./'`pixman-mmx.c

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -mmmx -Winline -g -O2 
-Wall -Wdeclaration-after-statement -fno-strict-aliasing 
-fvisibility=hidden -c pixman-mmx.c  -fno-common -DPIC -o 
.libs/libpixman_mmx_la-pixman-mmx.o

/bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. 
-I..-msse2 -Winline -g -O2 -Wall -Wdeclaration-after-statement 
-fno-strict-aliasing -fvisibility=hidden -c -o 
libpixman_sse2_la-pixman-sse2.lo `test -f 'pixman-sse2.c' || echo 
'./'`pixman-sse2.c

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -msse2 -Winline -g -O2 
-Wall -Wdeclaration-after-statement -fno-strict-aliasing 
-fvisibility=hidden -c pixman-sse2.c  -fno-common -DPIC -o 
.libs/libpixman_sse2_la-pixman-sse2.o

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall 
-Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -c 
pixman-utils.c -o pixman-utils.o >/dev/null 2>&1

pixman-mmx.c:100:20: error: constraint 'K' expects an integer constant 
expression

: "y" (__A), "K" (__N)

  ^~~

1 error generated.

make[1]: *** [libpixman_mmx_la-pixman-mmx.lo] Error 1

make[1]: *** Waiting for unfinished jobs

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -msse2 -Winline -g -O2 
-Wall -Wdeclaration-after-statement -fno-strict-aliasing 
-fvisibility=hidden -c pixman-sse2.c -o libpixman_sse2_la-pixman-sse2.o 
>/dev/null 2>&1

make: *** [install-recursive] Error 1


READ THIS: https://git.io/brew-troubleshooting

If reporting this issue please do so at (not Homebrew/homebrew):

  https://github.com/staticfloat/homebrew-juliadeps/issues


Warning: 

*[ ERROR: Cairo 
]=*


*LoadError: failed process: 
Process(`/Users/lewislevinmbr/.julia/v0.4/Homebrew/deps/usr/bin/brew 
install --force-bottle staticfloat/juliadeps/cairo`, ProcessExited(1)) [1]*

*while loading /Users/lewislevinmbr/.julia/v0.4/Cairo/deps/build.jl, in 
expression starting on line 144*


*=*


*[ BUILD ERRORS 
]=*


*WARNING: Cairo had build errors.*


* - packages with build errors remain installed in 
/Users/lewislevinmbr/.julia/v0.4*

* - build the package(s) and all dependencies with `Pkg.build("Cairo")`*

* - build a single package by running its `deps/build.jl` script*


*=*


*Looks like pixma is the culprit.  I had other problems with Julia 0.3.11. 
Seems like 4.0 is getting so close that focus will shift.*

*Suggestions?*