[julia-users] Re: How to print ALL packages of Pkg.available()?

[Randy Zwitch]

You could do [println(x) for x in Pkg.available()]

On Monday, October 10, 2016 at 3:16:20 PM UTC-4, John Paul Vasquez wrote:
>
> Is there a command/option to display all the elements of a very long 
> array? The output gets cut in the middle. For example when calling 
> Pkg.available(), I only see the head and tail of the array. It is very 
> inconvenient when I wanted to find a package, assuming I don't have any 
> idea what the correct name of the package is, without relying on a web 
> browser.
>

[julia-users] Re: New Julia-Focused Blog: Pkg Update

[Randy Zwitch]

As a small other update, this is now the 40th blog added to Julia 
Bloggers...

On Thursday, October 6, 2016 at 5:16:44 AM UTC-4, Chris Rackauckas wrote:
>
> Hey, 
>   I am happy to announce Pkg Update, a new blog focused on summarizing the 
> large changes throughout the Julia package ecosystem. As I feel it's always 
> easier to get people involved once you already have things up and running, 
> I went ahead and created the first blog post 
> , detailing some recent changes in 
> JuliaMath, JuliaStats, JuliaDiffEq, JuliaML, etc. I hope you find this 
> interesting. As I mention in the post, I am looking for others who would 
> like to help contribute, especially as correspondents for a particular 
> organization. I feel like this can be very helpful for Julia users to 
> understand the rapidly evolving ecosystem. Hope you enjoy!
>

[julia-users] Re: Why was a fundamental indexing inconsistency introduced in 0.5?

[Randy Zwitch]

As someone who has never used repmat, I can't comment on that, but the 
"automatic squashing" makes perfect sense to me. The first syntax 
simplifies the structure down to a 1-D instead of a 2-D array with only one 
row (repmat aside, why would I want to keep the extra dimension if it 
doesn't contain any information?)


On Sunday, September 25, 2016 at 6:32:28 PM UTC-4, Joshua Jones wrote:
>
> The change to indexing within matrices in 0.5.0 is fundamentally 
> counterintuitive. For example:
>
> julia> frame32 = randn(16,7);
>
> julia> size(frame32[1,:])
> (7,)
>
> julia> size(frame32[1:1,:])
> (1,7)
>
> To be quite blunt, I think this is a terrible contradiction. It completely 
> breaks the repmat syntax that people have used in other languages for more 
> than 20 years. To obtain what my code *was* doing last week, I now need 
> to do one of:
> julia> repmat(frame32[1,:]', 16, 1)
> julia> repmat(frame32[1:1,:], 16, 1)
>
> In plain English, my code needs to take the transpose of an extracted row 
> for the result to be a row vector. Isn't this the very definition of 
> nonreflexive syntax?
>

[julia-users] Re: http://pkg.julialang.org/ needs updating.. I guess 0.5 is now recommended (and specific packages?)

[Randy Zwitch]

Thanks for sharing those web links. Though I do "big data" type work with 
Julia, I don't do any algorithm/math stuff in Julia. There are a few of us 
around, and more to come I'm sure.

On Wednesday, September 21, 2016 at 11:57:15 AM UTC-4, Páll Haraldsson 
wrote:
>
>
> At:
>
> http://pkg.julialang.org/
>
> http://pkg.julialang.org/pulse.html
>
> I see:
>
> "*v0.4.6 (current release)* — v0.5-pre (unstable)"
>
> former is no longer true, and I guess not the latter. Isn't "unstable" 
> meant to refer to Julia itself? Or packages..? Both?
>
> This is just a reminder to update..
>
>
>
>
> Great to see: "Listing all 1127 registered packages 
> ". Then there are some more.. 
> unknowns.. but of those registered:
>
>
>
> I see at least 5 web frameworks now (this "gluttony" is getting to be a 
> problem..), and 29 hits on "web", yes, infrastructure code, e.g. HTTP2.
>
>
> New ones I didn't know about:
> http://github.com/codeneomatrix/Merly.jl
>
> http://github.com/EricForgy/Pages.jl
>
>
> and what I've yet too look into (thought the newest one):
>
> http://github.com/wookay/Bukdu.jl
>
>
> Any recommendations? Great to know that there is just not math related.
>
> -- 
> Palli.
>

Re: [julia-users] Understanding Nullable as immutable

[Randy Zwitch]

OH! That makes a big difference in usability. :)

On Wednesday, September 21, 2016 at 12:50:26 PM UTC-4, Fengyang Wang wrote:
>
> There is no need to modify a copy; only the Nullable is immutable and not 
> its underlying value. Just instead of modifying ec.title, modify 
> get(ec.title). Like setfield!(get(ec.title), k, v). In short scripts, I 
> often define getindex(x::Nullable) = get(x) so that I can write ec.title[] 
> instead of get(ec.title), but type piracy is bad practice. This method 
> should really be in Base.
>
> On Wednesday, September 21, 2016 at 9:59:21 AM UTC-4, Randy Zwitch wrote:
>>
>> So get() to check if a value is there, and if there is modify a copy 
>> then overwrite?
>>
>> If that's the case, it might be worth the mental overhead to use Nullable 
>> types when mentally I'm viewing everything as a consistently mutating 
>> object until the desired result is achieved.
>>  
>> On Wednesday, September 21, 2016 at 9:49:44 AM UTC-4, Yichao Yu wrote:
>>>
>>> On Sep 21, 2016 9:42 AM, "Randy Zwitch"  
>>> wrote:
>>> >
>>> > I frequently have a design pattern of Union{Title, Void}. I was 
>>> thinking that I could redefine this as title::Nullable{Title}. However, 
>>> once I try to modify fields inside the Title type using setfield!(ec.title, 
>>> k, v), I get this error message:
>>> >
>>> > LoadError: type Nullable is immutable while loading In[19], in 
>>> expression starting on line 4
>>> >
>>> >
>>> >
>>> > My question is, why is the Nullable type immutable? My original 
>>> thought was that my Nullable definition was saying "There is either a Title 
>>> type here or nothing/missing", and maybe I know the value now or maybe I 
>>> know it later. But it seems the definition is actually "There could be a 
>>> Title type here or missing, and whatever you see first is what you will 
>>> always have"
>>> >
>>> > Is there a better way to express the former behavior other than as a 
>>> Union type? My use case is building JSON strings as specifications of 
>>> graphs for JavaScript libraries, so nearly every field of every type is 
>>> possibly missing for any given specification.
>>>
>>> Assign the whole object instead of mutating it.
>>>
>>> >
>>> > @with_kw type EChart <: AbstractEChartType
>>> > # title::Union{Title,Void} = Title()
>>> > title::Nullable{Title} = Title()
>>> > legend::Union{Legend,Void} = nothing
>>> > grid::Union{Grid,Void} = nothing
>>> > xAxis::Union{Array{Axis,1},Void} = nothing
>>> > yAxis::Union{Array{Axis,1},Void} = nothing
>>> > polar::Union{Polar,Void} = nothing
>>> > radiusAxis::Union{RadiusAxis,Void} = nothing
>>> > angleAxis::Union{AngleAxis,Void} = nothing
>>> > radar::Union{Radar,Void} = nothing
>>> > dataZoom::Union{DataZoom,Void} = nothing
>>> > visualMap::Union{VisualMap,Void} = nothing
>>> > tooltip::Union{Tooltip,Void} = nothing
>>> > toolbox::Union{Toolbox,Void} = Toolbox()
>>> > geo::Union{Geo,Void} = nothing
>>> > parallel::Union{Parallel,Void} = nothing
>>> > parallelAxis::Union{ParallelAxis,Void} = nothing
>>> > timeline::Union{Timeline,Void} = nothing
>>> > series::Union{Array{Series,1},Void} = nothing
>>> > color::Union{AbstractVector,Void} = nothing
>>> > backgroundColor::Union{String,Void} = nothing
>>> > textStyle::Union{TextStyle,Void} = nothing
>>> > animation::Union{Bool,Void} = nothing
>>> > animationDuration::Union{Int,Void} = nothing
>>> > animationEasing::Union{String,Void} = nothing
>>> > animationDelay::Union{Int,Void} = nothing
>>> > animationDurationUpdate::Union{Int,Void} = nothing
>>> > animationEasingUpdate::Union{String,Void} = nothing
>>> > animationDelayUpdate::Union{Int,Void} = nothing
>>> > end
>>>
>>

Re: [julia-users] Understanding Nullable as immutable

[Randy Zwitch]

So get() to check if a value is there, and if there is modify a copy then 
overwrite?

If that's the case, it might be worth the mental overhead to use Nullable 
types when mentally I'm viewing everything as a consistently mutating 
object until the desired result is achieved.
 
On Wednesday, September 21, 2016 at 9:49:44 AM UTC-4, Yichao Yu wrote:
>
> On Sep 21, 2016 9:42 AM, "Randy Zwitch"  > wrote:
> >
> > I frequently have a design pattern of Union{Title, Void}. I was thinking 
> that I could redefine this as title::Nullable{Title}. However, once I try 
> to modify fields inside the Title type using setfield!(ec.title, k, v), I 
> get this error message:
> >
> > LoadError: type Nullable is immutable while loading In[19], in 
> expression starting on line 4
> >
> >
> >
> > My question is, why is the Nullable type immutable? My original thought 
> was that my Nullable definition was saying "There is either a Title type 
> here or nothing/missing", and maybe I know the value now or maybe I know it 
> later. But it seems the definition is actually "There could be a Title type 
> here or missing, and whatever you see first is what you will always have"
> >
> > Is there a better way to express the former behavior other than as a 
> Union type? My use case is building JSON strings as specifications of 
> graphs for JavaScript libraries, so nearly every field of every type is 
> possibly missing for any given specification.
>
> Assign the whole object instead of mutating it.
>
> >
> > @with_kw type EChart <: AbstractEChartType
> > # title::Union{Title,Void} = Title()
> > title::Nullable{Title} = Title()
> > legend::Union{Legend,Void} = nothing
> > grid::Union{Grid,Void} = nothing
> > xAxis::Union{Array{Axis,1},Void} = nothing
> > yAxis::Union{Array{Axis,1},Void} = nothing
> > polar::Union{Polar,Void} = nothing
> > radiusAxis::Union{RadiusAxis,Void} = nothing
> > angleAxis::Union{AngleAxis,Void} = nothing
> > radar::Union{Radar,Void} = nothing
> > dataZoom::Union{DataZoom,Void} = nothing
> > visualMap::Union{VisualMap,Void} = nothing
> > tooltip::Union{Tooltip,Void} = nothing
> > toolbox::Union{Toolbox,Void} = Toolbox()
> > geo::Union{Geo,Void} = nothing
> > parallel::Union{Parallel,Void} = nothing
> > parallelAxis::Union{ParallelAxis,Void} = nothing
> > timeline::Union{Timeline,Void} = nothing
> > series::Union{Array{Series,1},Void} = nothing
> > color::Union{AbstractVector,Void} = nothing
> > backgroundColor::Union{String,Void} = nothing
> > textStyle::Union{TextStyle,Void} = nothing
> > animation::Union{Bool,Void} = nothing
> > animationDuration::Union{Int,Void} = nothing
> > animationEasing::Union{String,Void} = nothing
> > animationDelay::Union{Int,Void} = nothing
> > animationDurationUpdate::Union{Int,Void} = nothing
> > animationEasingUpdate::Union{String,Void} = nothing
> > animationDelayUpdate::Union{Int,Void} = nothing
> > end
>

[julia-users] Understanding Nullable as immutable

[Randy Zwitch]

I frequently have a design pattern of Union{Title, Void}. I was thinking 
that I could redefine this as title::Nullable{Title}. However, once I try 
to modify fields inside the Title type using setfield!(ec.title, k, v), I 
get this error message:

LoadError: type Nullable is immutable
while loading In[19], in expression starting on line 4



My question is, why is the Nullable type immutable? My original thought was 
that my Nullable definition was saying "There is either a Title type here 
or nothing/missing", and maybe I know the value now or maybe I know it 
later. But it seems the definition is actually "There could be a Title type 
here or missing, and whatever you see first is what you will always have"

Is there a better way to express the former behavior other than as a Union 
type? My use case is building JSON strings as specifications of graphs for 
JavaScript libraries, so nearly every field of every type is possibly 
missing for any given specification.

@with_kw type EChart <: AbstractEChartType
# title::Union{Title,Void} = Title()
title::Nullable{Title} = Title()
legend::Union{Legend,Void} = nothing
grid::Union{Grid,Void} = nothing
xAxis::Union{Array{Axis,1},Void} = nothing
yAxis::Union{Array{Axis,1},Void} = nothing
polar::Union{Polar,Void} = nothing
radiusAxis::Union{RadiusAxis,Void} = nothing
angleAxis::Union{AngleAxis,Void} = nothing
radar::Union{Radar,Void} = nothing
dataZoom::Union{DataZoom,Void} = nothing
visualMap::Union{VisualMap,Void} = nothing
tooltip::Union{Tooltip,Void} = nothing
toolbox::Union{Toolbox,Void} = Toolbox()
geo::Union{Geo,Void} = nothing
parallel::Union{Parallel,Void} = nothing
parallelAxis::Union{ParallelAxis,Void} = nothing
timeline::Union{Timeline,Void} = nothing
series::Union{Array{Series,1},Void} = nothing
color::Union{AbstractVector,Void} = nothing
backgroundColor::Union{String,Void} = nothing
textStyle::Union{TextStyle,Void} = nothing
animation::Union{Bool,Void} = nothing
animationDuration::Union{Int,Void} = nothing
animationEasing::Union{String,Void} = nothing
animationDelay::Union{Int,Void} = nothing
animationDurationUpdate::Union{Int,Void} = nothing
animationEasingUpdate::Union{String,Void} = nothing
animationDelayUpdate::Union{Int,Void} = nothing
end

Re: [julia-users] Does Julia 0.5 leak memory?

[Randy Zwitch]

Does the problem go away if you run gc()?



On Monday, September 19, 2016 at 3:55:14 PM UTC-4, K leo wrote:
>
> Thanks for the suggestion about valgrind.
>
> Can someone please let me first understand the expected behaviour for 
> memory usage.
>
> Let's say when I first starts Julia REPL it takes 5% of RAM (according to 
> top).  Then I include "myfile.jl" and run myfunction().  During the 
> execution of myfunction(), memory allocation of Julia reaches 40% of RAM 
> (again according to top).  Say running myfunction() involves no allocation 
> of global objects - all object used are local.  Then when myfunction() 
> finished and I am at the REPL prompt, should top show the memory usage of 
> Julia drops down to the previous level (5% of RAM)?  My current observation 
> is that it doesn't.  Is this the expected behaviour?
>
>

[julia-users] Re: Idea: Julia Standard Libraries and Distributions

[Randy Zwitch]

"Also, there's a good reason to ask "why fuss with distributions when 
anyone could just add the packages and add the import statements to their 
.juliarc?" (though its target audience is for people who don't know details 
like the .juliarc, but also want Julia to work seamlessly like MATLAB)."

I feel like if you're using MATLAB, it should be a really small step to 
teach about the .juliarc file, as oppose to the amount of 
maintenance/fragmentation that comes along with multiple distributions.

Point #1 makes sense for me, if only because that's a use case that can't 
be accomplished through simple textfile manipulation

On Tuesday, September 13, 2016 at 4:39:15 AM UTC-4, Chris Rackauckas wrote:
>
> I think one major point of contention when talking about what should be 
> included in Base due to competing factors:
>
>
>1. Some people would like a "lean Base" for things like embedded 
>installs or other low memory applications
>2. Some people want a MATLAB-like "bells and whistles" approach. This 
>way all the functions they use are just there: no extra packages to 
>find/import.
>3. Some people like having things in Base because it "standardizes" 
>things. 
>4. Putting things in Base constrains their release schedule. 
>5. Putting things in packages outside of JuliaLang helps free up 
>Travis.
>
>
> The last two concerns have been why things like JuliaMath have sprung up 
> to move things out of Base. However, I think there is some credibility to 
> having some form of standardization. I think this can be achieved through 
> some kind of standard library. This would entail a set of packages which 
> are installed when Julia is installed, and a set of packages which add 
> their using statement to the .juliarc. To most users this would be 
> seamless: they would install automatically, and every time you open Julia, 
> they would import automatically. There are a few issues there:
>
>
>1.  This wouldn't work with building from source. This idea works 
>better for binaries (this is no biggie since these users are likely more 
>experienced anyways)
>2. Julia would have to pick winners and losers.
>
> That second part is big: what goes into the standard library? Would all of 
> the MATLAB functions like linspace, find, etc. go there? Would the sparse 
> matrix library be included?
>
> I think one way to circumvent the second issue would be to allow for Julia 
> Distributions. A distribution would be defined by:
>
>
>1. A Julia version
>2. A List of packages to install (with versions?)
>3. A build script
>4. A .juliarc
>
> The ideal would be for one to be able to make an executable from those 
> parts which would install the Julia version with the specified packages, 
> build the packages (and maybe modify some environment variables / 
> defaults), and add a .juliarc that would automatically import some packages 
> / maybe define some constants or checkout branches. JuliaLang could then 
> provide a lean distribution and a "standard distribution" where the 
> standard distribution is a more curated library which people can fight 
> about, but it's not as big of a deal if anyone can make their own. This has 
> many upsides:
>
>
>1. Julia wouldn't have to come with what you don't want.
>2. Other than some edge cases where the advantages of Base come into 
>play (I don't know of a good example, but I know there are some things 
>which can't be defined outside of Base really well, like BigFloats? I'm 
> not 
>the expert on this.), most things could spawn out to packages without the 
>standard user ever noticing.
>3. There would still be a large set of standard functions you can 
>assume most people will have.
>4. You can share Julia setups: for example, with my lab I would share 
>a distribution that would have all of the JuliaDiffEq packages installed, 
>along with Plots.jl and some backends, so that way it would be "in the box 
>solve differential equations and plot" setup like what MATLAB provides. I 
>could pick packages/versions that I know work well together, 
>and guarantee their install will work. 
>5. You could write tutorials / run workshops which use a distribution, 
>knowing that a given set of packages will be available.
>6. Anyone could make their setup match yours by looking at the 
>distribution setup scripts (maybe just make a base function which runs 
> that 
>install since it would all be in Julia). This would be nice for some work 
>in progress projects which require checking out master on 3 different 
>packages, and getting some weird branch for another 5. I would give you a 
>succinct and standardized way to specify an install to get there.
>
>
> Side notes:
>
> [An interesting distribution would be that JuliaGPU could provide a full 
> distribution for which CUDAnative works (since it requires a different 
> Julia install)]
>
> [A "D

[julia-users] Re: TreeMap in Julia

[Randy Zwitch]

Vega.jl has the capability to render one, but doesn't yet have an 
easy-to-use function defined:

https://github.com/johnmyleswhite/Vega.jl/issues/109

You would need to translate the example JSON string into the 
VegaVisualization composite type in Julia, which can be slightly 
frustrating the first few times you do it, but eventually gets easier.

I'd love a pull request if you plan on tackling this!

On Wednesday, September 7, 2016 at 5:02:25 AM UTC-4, Ján Adamčák wrote:
>
> Hi, 
>
> Is there a tool for drawing Tree Map in Julia?
> I want draw something like this:
>
>
> 
>
>
>
>
>
>

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

[Randy Zwitch]

This is great Frederic, you beat me to it! Although, I was more thinking 
about how to incorporate it into the Vega.jl library, not expose the Vega 
Lite API as you have.

I look forward to cross-contributing with you between Vega.jl and 
VegaLite.jl!

On Tuesday, March 15, 2016 at 5:39:56 PM UTC-4, Frederic Testard wrote:
>
> The julia package VegaLite has just been added to the official repo ( 
> install with Pkg.add("VegaLite")  ). As the name suggests it provides 
> bindings to the VegaLite plotting library (yet another way to make graphs 
> with Julia !). VegaLite is a simplified version of Vega which reduces the 
> functionality but provides in turn a simpler way to define graphs (see 
> https://vega.github.io/vega-lite/).
>
> VegaLite uses graph descriptions in JSON but the julia syntax proposed by 
> the package looks more like the ggplot syntax where a series of functions 
> builds up the graph specs. You can check out the Quick tour/presentation at 
>  https://github.com/fredo-dedup/VegaLite.jl
>
> The supported backends are the standard REPL (a browser window will open), 
> Escher and Jupyter.
>
> Issues, enhancements proposals are of course welcome !
>
>
>
>
>

Re: [julia-users] Setting values of composite types using metaprogramming

[Randy Zwitch]

I ended up figuring out what I need using optional varargs:

function title!(ec::EChart; kwargs...)

for (k, v) in kwargs
  ec.title.(k) = v
end 

return ec
 
end

Thanks for the help everyone!

On Tuesday, December 29, 2015 at 3:36:24 PM UTC-5, Randy Zwitch wrote:
>
> The left side of the expression works, but the right side is still a 
> symbol, instead of the symbol's value. 
>
> On Tuesday, December 29, 2015 at 3:22:00 PM UTC-5, Erik Schnetter wrote:
>>
>> Would 
>>
>> for val in [:show, :zlevel, :z] 
>>ec.title.(val) = val 
>> end 
>>
>> work? 
>>
>> -erik 
>>
>>
>> On Tue, Dec 29, 2015 at 2:34 PM, Randy Zwitch 
>>  wrote: 
>> > I feel like I should be so much better at this than I am... 
>> > 
>> > How can I take code like: 
>> > 
>> > ec.title.show = show 
>> > ec.title.zlevel = zlevel 
>> > ec.title.z = z 
>> > 
>> > And change it to something like 
>> > 
>> > for val in [:show, :zlevel, :z] 
>> >:(ec.title.$val) = :($val) 
>> > end 
>> > 
>> > I'm just trying to dynamically reference and set the value of the 
>> composite 
>> > type field equal to the values passed to a function's keyword 
>> arguments. 
>>
>>
>>
>> -- 
>> Erik Schnetter  
>> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>>
>

Re: [julia-users] Setting values of composite types using metaprogramming

[Randy Zwitch]

The left side of the expression works, but the right side is still a 
symbol, instead of the symbol's value. 

On Tuesday, December 29, 2015 at 3:22:00 PM UTC-5, Erik Schnetter wrote:
>
> Would 
>
> for val in [:show, :zlevel, :z] 
>ec.title.(val) = val 
> end 
>
> work? 
>
> -erik 
>
>
> On Tue, Dec 29, 2015 at 2:34 PM, Randy Zwitch 
> > wrote: 
> > I feel like I should be so much better at this than I am... 
> > 
> > How can I take code like: 
> > 
> > ec.title.show = show 
> > ec.title.zlevel = zlevel 
> > ec.title.z = z 
> > 
> > And change it to something like 
> > 
> > for val in [:show, :zlevel, :z] 
> >:(ec.title.$val) = :($val) 
> > end 
> > 
> > I'm just trying to dynamically reference and set the value of the 
> composite 
> > type field equal to the values passed to a function's keyword arguments. 
>
>
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

Re: [julia-users] Setting values of composite types using metaprogramming

[Randy Zwitch]

Thanks Mauro, the @pack macro solution looks interesting, I'll try that out

On Tuesday, December 29, 2015 at 3:00:12 PM UTC-5, Mauro wrote:
>
> You could use the @pack macro from Parameters.jl: 
>
> @pack ec.title: show, zlevel, z 
>
> which is equivalent to your 
>
> ec.title.show = show 
> ec.title.zlevel = zlevel 
> ec.title.z = z 
>
> Otherwise use `setfield!`: 
>
> function f(t;kws...) 
>for (s,v) in kws 
>setfield!(t, s, v) 
>end 
> end 
>
> On Tue, 2015-12-29 at 20:34, Randy Zwitch  > wrote: 
> > I feel like I should be so much better at this than I am... 
> > 
> > How can I take code like: 
> > 
> > ec.title.show = show 
> > ec.title.zlevel = zlevel 
> > ec.title.z = z 
> > 
> > And change it to something like 
> > 
> > for val in [:show, :zlevel, :z] 
> >:(ec.title.$val) = :($val) 
> > end 
> > 
> > I'm just trying to dynamically reference and set the value of the 
> composite 
> > type field equal to the values passed to a function's keyword arguments. 
>

[julia-users] Setting values of composite types using metaprogramming

[Randy Zwitch]

I feel like I should be so much better at this than I am...

How can I take code like:

ec.title.show = show
ec.title.zlevel = zlevel
ec.title.z = z

And change it to something like

for val in [:show, :zlevel, :z]
   :(ec.title.$val) = :($val)
end

I'm just trying to dynamically reference and set the value of the composite 
type field equal to the values passed to a function's keyword arguments.

Re: [julia-users] Re: Juno bundles for Julia v0.4

[Randy Zwitch]

Thanks Mike. I'll keep my eye on the Atom development, and I'm sure we'll 
figure out something.

On Tuesday, December 22, 2015 at 7:29:26 AM UTC-5, Mike Innes wrote:
>
> Randy – for the detection you could try `isdefined(Main, :Jewel)`. 
> Unfortunately we don't have a good approach to dependencies yet (I think 
> Gadfly just dumps in its dependencies with every plot) but this is 
> something I'll be looking into as part of the Atom work. From your tweets 
> it looks like Vega is coming along really nicely, so I'm going to have to 
> start playing around with it, and I'll help with getting it integrated 
> where I can.
>
> Sheehan – it looks like the signing may have failed on the OS X release. 
> For now, right clicking and selecting "open" should do the trick.
>
> On Sun, 20 Dec 2015 at 02:43 Sheehan Olver  > wrote:
>
>> Hmm, double clicking Juno doesn't work (Says "Application can't be 
>> opened") but running Juno.app/Contents/MacOS/Electron works fine.  This is 
>> on El Capitan
>>
>>
>> On Saturday, December 19, 2015 at 3:24:39 AM UTC+11, Mike Innes wrote:
>>>
>>> Hey All,
>>>
>>> Juno bundles including Julia v0.4 are now available on the Julia 
>>> downloads page . If you're still using 
>>> Juno with Julia v0.3 the upgrade is definitely recommended – among other 
>>> things, features like precompilation make using packages like Gadfly much 
>>> easier. Enjoy!
>>>
>>> Cheers,
>>> Mike
>>>
>>

[julia-users] Re: Juno bundles for Julia v0.4

[Randy Zwitch]

Thanks Mike.

Tangent: what's the right way to programmatically detect being in the Juno 
environment? In the Vega plotting package, I have inline plotting working 
in Jupyter Notebook, but in Juno I get an error because load all my 
JavaScript using requirejs in Jupyter (but requirejs is not available in 
Juno).

Juno console:


   - 
   
   Invalid behavior: :lt.objs.langs.julia/commands
   
   - 
   
   TypeError: require.config is not a function
   at eval (eval at eval_scripts 
(/Applications/Juno.app/Contents/Resources/app/plugins/Julia-LT/julia_compiled.js),
 :3:15)
   at eval (native)
   at eval_scripts 
(/Applications/Juno.app/Contents/Resources/app/plugins/Julia-LT/julia_compiled.js:105:63)
   at Function.__BEH__commands 
(/Applications/Juno.app/Contents/Resources/app/plugins/Julia-LT/julia_compiled.js:294:46)
   at c 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:6196:14)
   at a 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:6236:18)
   at c 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:20443:76)
   at a 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:20477:18)
   at a 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:20488:34)
   at b 
(file:///Applications/Juno.app/Contents/Resources/app/core/node_modules/lighttable/bootstrap.js:20492:14)
   
   

Working Vega code for Jupyter Notebook:

https://github.com/johnmyleswhite/Vega.jl/blob/master/src/render.jl#L18-L68

On Friday, December 18, 2015 at 11:24:39 AM UTC-5, Mike Innes wrote:
>
> Hey All,
>
> Juno bundles including Julia v0.4 are now available on the Julia 
> downloads page . If you're still using 
> Juno with Julia v0.3 the upgrade is definitely recommended – among other 
> things, features like precompilation make using packages like Gadfly much 
> easier. Enjoy!
>
> Cheers,
> Mike
>

Re: [julia-users] Proposal: NoveltyColors.jl

[Randy Zwitch]

On Wednesday, December 2, 2015 at 3:12:36 AM UTC-5, Tomas Lycken wrote:
>
> Also, the naming discussion here is not *only* on naming; it's also on 
> the possibility of including *more things *in the package. I would be all 
> for having a package like Palettes.jl, which would include both 
> NoveltyColors.jl and other palettes, but that's not in conflict with the 
> current package - it's an extension, that might happen tomorrow, in a year, 
> or never at all, depending on whether someone actually finds it useful 
> enough to implement it.
>

People are free to extend my package as much as they like, or create a 
wrapper package that aggregates all these different packages. Not sure why 
that needs a waiting period for my package. 

On Wednesday, December 2, 2015 at 1:22:21 PM UTC-5, cormu...@mac.com wrote:
>
> I'm using [ColorSchemes.jl](https://github.com/cormullion/ColorSchemes.jl) 
> for my own purposes, but I'm happy to rename it if someone else wants the 
> name.


Is this on METADATA? I thought I had checked, but maybe I had missed. If 
so, then it makes my package a bit redundant, as I could've submitted a PR 
to your package. 

On Wednesday, December 2, 2015 at 1:39:09 PM UTC-5, Stefan Karpinski wrote:
>
> I'm still pretty unclear on what makes a color scheme a novelty.
>
>
I don't know, it seemed like having a plot based on the colors from the 
Grand Budapest Hotel or an outfit Beyonce wore would be a novelty, as 
opposed to something like ColorBrewer which explicitly tries to provide 
schemes that improve cartography. Since Tim has a majority of the commits 
on Color.jl and he thought it was an idea that stood on its own (per my 
reading into his approval comment above), I went with it. I really didn't 
think it would be this contentious.


 

[julia-users] Re: Julia career advice question (x-post r/julia)

[Randy Zwitch]

Practice both, it will make your programming that much better.

I think you'd be hard-pressed to find anyone here that ONLY knows Julia. In 
fact, I bet a majority of people here know at least 3 languages. That's not 
meant to be a discouraging thought, but rather, as a practical matter 
you're going to be expected to learn many languages in your career, no 
matter what you do. 


On Tuesday, December 1, 2015 at 3:19:13 PM UTC-5, dsi...@gmail.com wrote:
>
> Hi Everyone,
>
>
> I'm currently learning data science and I have a cs101 with python 
> background.
>
>
> I have this nagging feeling that Julia is going to be huge (and its 
> pleasing to code in) and so as I begin to learn stats with python, I keep 
> drifting over to Julia. Learning python seems like I'm investing in a stock 
> at its peak and its only downhill from there.
>
>
> However, I also have a nagging feeling that its not ready for productive 
> data to data analysis or data engineering type production, that the job 
> prospects will be slim for a while and that I will spend too much time 
> chasing pycall etc errors.
>
>
> Also with python I get can get a backup sysadmin, backend web etc job if 
> it turns out I'm terrible at stats.
>
>
> I'm thus vacillating and not sure which language to learn here on out.
>
>
> Are my considerations  sound? Any other thoughts on this please?
>
>
> Thanks!
>

Re: [julia-users] Proposal: NoveltyColors.jl

[Randy Zwitch]

Here's my PR, I'm not the one who merged it. However, between November 24 
and yesterday seems quite long enough for naming; I mean, no one else was 
really thinking of using NoveltyColors as a name, were they? Naming 
discussions to me only seem necessary when it's a common name so that 
someone doesn't squat on a name that's obvious and should be reserved.

https://github.com/JuliaLang/METADATA.jl/pull/4120

Ultimately, I just wanted to add these color palettes to Vega.jl, 
ColorBrewer.jl already shows that we're willing to have small color 
packages on METADATA, and I figured other people might want to use these 
palettes. Moving them inside of Vega.jl would take 30 seconds, so it 
doesn't really matter to me. Just trying to modularize for the benefit of 
the community.

On Tuesday, December 1, 2015 at 9:56:41 AM UTC-5, Andreas Lobinger wrote:
>
>
>
> On Tuesday, December 1, 2015 at 3:32:19 PM UTC+1, Randy Zwitch wrote:
>>
>> +1 Tom. 
>>
>> It's on METADATA now, so only focus now is to improve the package, the 
>> name isn't going to change.
>>
>
> I can not track it down right now (i think it was on the Color/Colors,jl 
> discussion) but wasn't there something like a holding time for METADATA.jl? 
> Like 48 hours? I cannot really understand, how a package like this with a 
> special interest flavour and somehow limited code makes it an official 
> package in a few hours? Without any naming discussion.
>

Re: [julia-users] Proposal: NoveltyColors.jl

[Randy Zwitch]

+1 Tom. 

It's on METADATA now, so only focus now is to improve the package, the name 
isn't going to change.

On Tuesday, December 1, 2015 at 9:24:02 AM UTC-5, Tom Breloff wrote:
>
> Calling it Palettes.jl would imply that it's the source for all important 
> palettes, whereas it seems NoveltyColors (or NoveltyPalettes) is a little 
> more specific, and probably more appropriate in this case. 
>
> On Monday, November 30, 2015, Eric Forgy > 
> wrote:
>
>> Cool. Suggestion: How about calling it "Palettes.jl"? Seems to be 
>> available.
>>
>> On Tuesday, December 1, 2015 at 9:17:04 AM UTC+8, Randy Zwitch wrote:
>>>
>>> A tangent to the current tangent:
>>>
>>> https://github.com/randyzwitch/NoveltyColors.jl now on METADATA. Would 
>>> love any feedback or contributions.
>>>
>>

[julia-users] Re: Proposal: NoveltyColors.jl

[Randy Zwitch]

A tangent to the current tangent:

https://github.com/randyzwitch/NoveltyColors.jl now on METADATA. Would love 
any feedback or contributions.

On Monday, November 30, 2015 at 6:42:38 PM UTC-5, Jeffrey Sarnoff wrote:
>
> How about using dictionaries -- xkcd[:skyblue] = 0x06c2ac? This would 
> open up the way for source specific named colors (e.g. paints).
>
>
>
> On Monday, November 30, 2015 at 5:38:10 PM UTC-5, Alex Mellnik wrote:
>>
>> On a related note, I've been thinking that it would be nice to include 
>> the results of the xkcd color survey <https://xkcd.com/color/rgb/> in 
>> Colors.jl.  Right now it has the CSS/SVG and X11 colors which is great for 
>> standardization, but sometimes you want to be able to get a RGB value 
>> corresponding to fairly specific and easy-to-remember color names (mocha, 
>> cerulean blue, etc).  I was originally going to stick it in a different 
>> package, but there might be a nice way to separate these names in Colors.jl
>>
>> -A
>>
>> On Tuesday, November 24, 2015 at 2:08:35 PM UTC-8, Randy Zwitch wrote:
>>>
>>> Since the Julia ecosystem is getting bigger, I figured I'd propose this 
>>> here first and see what people think is the right way forward (instead of 
>>> wasting people's time at METADATA)
>>>
>>> In the R community, they've created two packages of novelty color 
>>> schemes: Wes Anderson <https://github.com/karthik/wesanderson> and 
>>> Beyonce <https://github.com/dill/beyonce>. While humorous, these color 
>>> palettes are interesting to me and I'd like to make them available in 
>>> Vega.jl (and Julia more broadly). Should I:
>>>
>>> 1) Not do it at allbecause this is a serious, scientific community!
>>> 2) Do two separate packages, mimicking R
>>> 3) Create a single NoveltyColors.jl package, in case there are other 
>>> palettes that come up in the future
>>> 4) Make a feature request at Colors.jl (really not my favorite choice, 
>>> since there is so much cited research behind the palettes)
>>>
>>> I neglected to mention ColorBrewer.jl (which Vega.jl uses), since 
>>> ColorBrewer is a known entity in the plotting community.
>>>
>>> What do people think? Note, I'm not looking for anyone to do the work 
>>> (I'll do it), just looking for packaging input.
>>>
>>

[julia-users] Re: Interactive graph visualization in Julia

[Randy Zwitch]

This is also on my roadmap for Vega.jl 

On Monday, November 30, 2015 at 7:25:40 AM UTC-5, Weijian Zhang wrote:
>
> Dear all,
>
> I really like the force-directed graph example in d3 . 
> See http://bl.ocks.org/mbostock/4062045
> A user can drag the nodes and move the graph around.
>
> I am wondering if we can do something similar just with Julia? Is there a 
> Julia package for this?
>
> Thanks,
>
> Weijian
>
>
>

[julia-users] Re: Proposal: NoveltyColors.jl

[Randy Zwitch]

Novelty, as in non-rigorous. These color schemes may or may not be 
aesthetically pleasing, without any provided research to their 
"correctness" for journal printing, colorblind compatible, or any of the 
other features that Colors.jl currently provides.

On Wednesday, November 25, 2015 at 3:02:49 AM UTC-5, cormu...@mac.com wrote:
>
> Nice idea. I confess I'm slightly not too keen on the word "Novelty" - 
> reminds me of cheap Christmas presents... :)  You could consider making the 
> package a bit more general...  For my purposes I've been using a small bit 
> of code that extracts a selection of colors from images to make a palette. 
> Basically, it's this:
>
> using Images, Colors, Clustering
>
> function dominant_colors(img, n=10, i=10, tolerance=0.01; resize = 1)
> w, h = size(img)
> neww = round(Int, w/resize)
> newh = round(Int, w/resize)
> smaller_image = Images.imresize(img, (neww, newh))
> imdata = convert(Array{Float64}, 
> raw(separate(smaller_image).data))/256
> w, h, nchannels = size(imdata)
> d = transpose(reshape(imdata, w*h, nchannels))
> R = kmeans(d, n, maxiter=i, tol=tolerance)
> cols = RGB{Float64}[]
> for i in 1:nchannels:length(R.centers)
> push!(cols, RGB(R.centers[i], R.centers[i+1], R.centers[i+2]))
> end
> return cols, R.cweights/sum(R.cweights)
> end
>
> sorted_palette, wts = 
> dominant_colors(imread("/tmp/van-gogh-starry-sky.png"), 10, 40, resize=3)
>
> which gives a selection of colors from the image (with weights if needed). 
> An interesting feature of this is that the results always vary slightly 
> each time - sometimes I stack them to see the differences:
>
>
> 
>
>
>
>
>

[julia-users] Re: Proposal: NoveltyColors.jl

[Randy Zwitch]

NoveltyColors.jl it is. Figured I can make whatever mess I want, we can 
always merge to Colors.jl later if the palettes are popular enough.

On Tuesday, November 24, 2015 at 5:08:35 PM UTC-5, Randy Zwitch wrote:
>
> Since the Julia ecosystem is getting bigger, I figured I'd propose this 
> here first and see what people think is the right way forward (instead of 
> wasting people's time at METADATA)
>
> In the R community, they've created two packages of novelty color schemes: 
> Wes 
> Anderson <https://github.com/karthik/wesanderson> and Beyonce 
> <https://github.com/dill/beyonce>. While humorous, these color palettes 
> are interesting to me and I'd like to make them available in Vega.jl (and 
> Julia more broadly). Should I:
>
> 1) Not do it at allbecause this is a serious, scientific community!
> 2) Do two separate packages, mimicking R
> 3) Create a single NoveltyColors.jl package, in case there are other 
> palettes that come up in the future
> 4) Make a feature request at Colors.jl (really not my favorite choice, 
> since there is so much cited research behind the palettes)
>
> I neglected to mention ColorBrewer.jl (which Vega.jl uses), since 
> ColorBrewer is a known entity in the plotting community.
>
> What do people think? Note, I'm not looking for anyone to do the work 
> (I'll do it), just looking for packaging input.
>

Re: [julia-users] Proposal: NoveltyColors.jl

[Randy Zwitch]

I can't believe that a few hundred lines of code, with 5-8 colors a piece 
is going to do anything to load times. I was just concerned about adding 
frivolity to Colors.jl, since it has so much cited research that goes along 
with it. That, and given that ColorBrewer.jl exists separate from Colors.jl 
made it seem like Colors.jl might already be in a steady-state.

On Tuesday, November 24, 2015 at 5:51:07 PM UTC-5, Stefan Karpinski wrote:
>
> Why not have them available by default? Do these make loading Colors much 
> slower?
>
> On Tuesday, November 24, 2015, Tom Breloff > 
> wrote:
>
>> Single package preferred, and if possible it would be great to be fully 
>> compatible with Colors.jl.  It might be ideal if it was part of Colors.jl, 
>> but loaded on demand, perhaps by calling:
>>
>> function i_am_feeling_wacky_today()
>>   @eval include("wacky.jl")
>> end
>>
>> or some similar trickery...
>>
>> On Tue, Nov 24, 2015 at 5:27 PM, Gabriel Gellner 
>>  wrote:
>>
>>> As an end user that would love this, I would prefer a single package. 
>>> Put all them tasty, wacky colors in one place!
>>>
>>>
>>> On Tuesday, 24 November 2015 14:08:35 UTC-8, Randy Zwitch wrote:
>>>>
>>>> Since the Julia ecosystem is getting bigger, I figured I'd propose this 
>>>> here first and see what people think is the right way forward (instead of 
>>>> wasting people's time at METADATA)
>>>>
>>>> In the R community, they've created two packages of novelty color 
>>>> schemes: Wes Anderson <https://github.com/karthik/wesanderson> and 
>>>> Beyonce <https://github.com/dill/beyonce>. While humorous, these color 
>>>> palettes are interesting to me and I'd like to make them available in 
>>>> Vega.jl (and Julia more broadly). Should I:
>>>>
>>>> 1) Not do it at allbecause this is a serious, scientific community!
>>>> 2) Do two separate packages, mimicking R
>>>> 3) Create a single NoveltyColors.jl package, in case there are other 
>>>> palettes that come up in the future
>>>> 4) Make a feature request at Colors.jl (really not my favorite choice, 
>>>> since there is so much cited research behind the palettes)
>>>>
>>>> I neglected to mention ColorBrewer.jl (which Vega.jl uses), since 
>>>> ColorBrewer is a known entity in the plotting community.
>>>>
>>>> What do people think? Note, I'm not looking for anyone to do the work 
>>>> (I'll do it), just looking for packaging input.
>>>>
>>>
>>

[julia-users] Proposal: NoveltyColors.jl

[Randy Zwitch]

Since the Julia ecosystem is getting bigger, I figured I'd propose this 
here first and see what people think is the right way forward (instead of 
wasting people's time at METADATA)

In the R community, they've created two packages of novelty color schemes: Wes 
Anderson  and Beyonce 
. While humorous, these color palettes are 
interesting to me and I'd like to make them available in Vega.jl (and Julia 
more broadly). Should I:

1) Not do it at allbecause this is a serious, scientific community!
2) Do two separate packages, mimicking R
3) Create a single NoveltyColors.jl package, in case there are other 
palettes that come up in the future
4) Make a feature request at Colors.jl (really not my favorite choice, 
since there is so much cited research behind the palettes)

I neglected to mention ColorBrewer.jl (which Vega.jl uses), since 
ColorBrewer is a known entity in the plotting community.

What do people think? Note, I'm not looking for anyone to do the work (I'll 
do it), just looking for packaging input.

[julia-users] Re: Pre-ANN: PlotlyJS.jl

[Randy Zwitch]

"The same concept should work with Vega.jl in Juno."

I don't use Juno, but I'm happy to accept a pull request to Vega.jl if 
there are people who want to integrate Juno as well. The behavior from the 
REPL is to generate a standalone webpage and open a browser, and plot 
inline in Jupyter Notebook (which is what I use).

On Monday, November 23, 2015 at 11:47:38 AM UTC-5, Eric Forgy wrote:
>
> Hi everyone,
>
>
> In this post 
>  
> from last Wednesday, Hans-Peter pointed out that plotly.js was made open 
> source (  https://plot.ly/javascript/open-source-announcement/ ).
>
>
> Anyway, I tried my hands at writing a wrapper for the JS API. There 
> already exists Plotly.jl, but that is an API to interact with the company's 
> server requiring login info, etc. With the opening of the JS API, the 
> interaction between Julia and Plotly can be much simpler, I think.
>
>
> In the other post, I mused that it should be straightforward to hook up 
> Plotly.js with Juno, so here is a snapshot:
>
>
>
> 
>
>
> To make it interactive, I used WebSockets.jl. One neat artifact of that is 
> you can stream the charts to multiple connections. 
>
>
> Here is a silly video demo of me controlling 4 browsers (only 3 are 
> visible) including an iPhone from Juno: 
> https://www.youtube.com/watch?v=mWDyyfVNqP0
>
>
> The same concept should work with Vega.jl in Juno.
>
>
> I call this a "Pre-announcement", because it is not really ready for the 
> wild yet, but it is far enough that if some friendlies would like to have a 
> look and help me get it in shape, that would be more than welcome.
>
>
> Currently, I am struggling a bit to get the paths correct. If I "git 
> clone" it and run it from the REPL, then I can make it work, but if I 
> "Pkg.clone" it, the path to the html containing the scripts is wrong. 
>
>
> Here are the lines in question:
>
>
> # res = Response(open(readall,Pkg.dir("Plotly","src","web","plotly.html")))
> res = Response(open(readall,"web/plotly.html"))
>
> When run from the REPL (after CD'ing to the directory), the code will find 
> plotly.html. But if I Pkg.clone, it can't find it. It seems to find it when 
> I use the commented Pkg.dir, but then that doesn't work when I'm trying to 
> test before committing to Github and Pkg.checkout etc. Any ideas?
>
> Anyway, this has been kind of fun and if others can help improve it, that 
> would be a great learning experience for me.
>
> Best regards,
> Eric
>

Re: [julia-users] Interesting: Plotly has become open source

[Randy Zwitch]

Eric, are you the person who I should talk to about getting Vega.jl to 
render inside Atom/Juno? I already render natively inside Jupyter Notebook, 
and to browser from the REPL, so it seems like it shouldn't be much effort 
to get Atom support.

On Tuesday, November 17, 2015 at 5:16:07 PM UTC-5, Eric Forgy wrote:
>
> This is very cool and it should be possible to natively include this 
> inside Atom/Juno.

Re: [julia-users] Interesting: Plotly has become open source

[Randy Zwitch]

Uh, I take that back. The latest update to the Plotly package references 
0.2.1 and is mostly API calls. I don't time for a whole re-write.

https://github.com/plotly/Plotly.jl

On Tuesday, November 17, 2015 at 2:00:02 PM UTC-5, Randy Zwitch wrote:
>
> Plot.ly already has a Julia package, so it seems like just a matter of not 
> calling the API and instead doing the JS calls. I think the bigger question 
> is whether the company has a plan to update their package yet. I'd 
> (probably) be interested in fixing the package, assuming it didn't take 
> hours and hours of work to switch it over to the JavaScript library.
>
> On Tuesday, November 17, 2015 at 1:41:01 PM UTC-5, Tom Breloff wrote:
>>
>> This is great!  For those involved with Plotly.jl, Vega.jl, Bokeh.jl, or 
>> anything else with similar technology, are there any major hurdles in 
>> accessing this from Julia?
>>
>> On Tue, Nov 17, 2015 at 1:04 PM, Hans-Peter  wrote:
>>
>>> See announcement: https://plot.ly/javascript/open-source-announcement/.
>>>
>>> I only used PyPlot so far but this sounds interesting. Offline 'plotly 
>>> plotting' without api key should be possible now.
>>>
>>
>>

Re: [julia-users] Interesting: Plotly has become open source

[Randy Zwitch]

Plot.ly already has a Julia package, so it seems like just a matter of not 
calling the API and instead doing the JS calls. I think the bigger question 
is whether the company has a plan to update their package yet. I'd 
(probably) be interested in fixing the package, assuming it didn't take 
hours and hours of work to switch it over to the JavaScript library.

On Tuesday, November 17, 2015 at 1:41:01 PM UTC-5, Tom Breloff wrote:
>
> This is great!  For those involved with Plotly.jl, Vega.jl, Bokeh.jl, or 
> anything else with similar technology, are there any major hurdles in 
> accessing this from Julia?
>
> On Tue, Nov 17, 2015 at 1:04 PM, Hans-Peter  > wrote:
>
>> See announcement: https://plot.ly/javascript/open-source-announcement/.
>>
>> I only used PyPlot so far but this sounds interesting. Offline 'plotly 
>> plotting' without api key should be possible now.
>>
>
>

Re: [julia-users] Anyone interested in H20.ai package?

[Randy Zwitch]

https://github.com/randyzwitch/H2O.jl/issues/1

On Tuesday, November 17, 2015 at 11:03:23 AM UTC-5, Randy Zwitch wrote:
>
> I guess it depends on how you look at it, but I was using the Requests 
> library (which uses HttpParser). So we wouldn't have to deal with the 
> BinDeps issue explicitly, but it's still there. 
>
> I don't really care about the licensing, so making it Apache is no big 
> deal to me.
>
> I'll write up my notes from talking to H2O as a first issue in the repo 
> and the discussion can go from there.
>
> On Tuesday, November 17, 2015 at 10:30:10 AM UTC-5, Christof Stocker wrote:
>>
>> Funny coincidence. I have been playing around with its REST API 
>> recently. I was thinking of mirroring the R package (and thus have a 
>> more or less identical interface), which is Apache licensed and is 
>> really nice to use. I did, however, have two concerns that discouraged 
>> me. My main concern is the rapid pace of changes of H2O. I think that 
>> even if you'd had a fully implemented H2O package that it would be quite 
>> some work to keep it up to date. The second, more minor concern is that 
>> I don't see a way of implementing the package without binary 
>> dependencies, since HttpParser.jl introduces one. But this is more of a 
>> personal preference of avoiding binary dependencies 
>>
>> That being said, if you are really interested in doing this via the REST 
>> API, then I am interested in contributing. I do think, though, that it 
>> should be Apache licensed. Don't know if it makes a difference, but just 
>> to be on the safe side. 
>>
>> On 2015-11-17 16:04, Randy Zwitch wrote: 
>> > I've been using H2O quite a bit at work, because it does a few things 
>> > well (I mostly use it for random forest and GBM) and is easy to use. 
>> > 
>> > I talked with the company at length about creating a Julia package and 
>> > the company is supportive of open-source contributions, so I created a 
>> > stump of a package. Anyone interested in working on it with me? Right 
>> > now, I'm still in between about using PyCall for everything or 
>> > attacking the API directly. Anyone interested in helping can help me 
>> > derive a development plan... 
>> > 
>> > https://github.com/randyzwitch/H2O.jl 
>>
>>

Re: [julia-users] Anyone interested in H20.ai package?

[Randy Zwitch]

I guess it depends on how you look at it, but I was using the Requests 
library (which uses HttpParser). So we wouldn't have to deal with the 
BinDeps issue explicitly, but it's still there. 

I don't really care about the licensing, so making it Apache is no big deal 
to me.

I'll write up my notes from talking to H2O as a first issue in the repo and 
the discussion can go from there.

On Tuesday, November 17, 2015 at 10:30:10 AM UTC-5, Christof Stocker wrote:
>
> Funny coincidence. I have been playing around with its REST API 
> recently. I was thinking of mirroring the R package (and thus have a 
> more or less identical interface), which is Apache licensed and is 
> really nice to use. I did, however, have two concerns that discouraged 
> me. My main concern is the rapid pace of changes of H2O. I think that 
> even if you'd had a fully implemented H2O package that it would be quite 
> some work to keep it up to date. The second, more minor concern is that 
> I don't see a way of implementing the package without binary 
> dependencies, since HttpParser.jl introduces one. But this is more of a 
> personal preference of avoiding binary dependencies 
>
> That being said, if you are really interested in doing this via the REST 
> API, then I am interested in contributing. I do think, though, that it 
> should be Apache licensed. Don't know if it makes a difference, but just 
> to be on the safe side. 
>
> On 2015-11-17 16:04, Randy Zwitch wrote: 
> > I've been using H2O quite a bit at work, because it does a few things 
> > well (I mostly use it for random forest and GBM) and is easy to use. 
> > 
> > I talked with the company at length about creating a Julia package and 
> > the company is supportive of open-source contributions, so I created a 
> > stump of a package. Anyone interested in working on it with me? Right 
> > now, I'm still in between about using PyCall for everything or 
> > attacking the API directly. Anyone interested in helping can help me 
> > derive a development plan... 
> > 
> > https://github.com/randyzwitch/H2O.jl 
>
>

[julia-users] Anyone interested in H20.ai package?

[Randy Zwitch]

I've been using H2O quite a bit at work, because it does a few things well 
(I mostly use it for random forest and GBM) and is easy to use.

I talked with the company at length about creating a Julia package and the 
company is supportive of open-source contributions, so I created a stump of 
a package. Anyone interested in working on it with me? Right now, I'm still 
in between about using PyCall for everything or attacking the API directly. 
Anyone interested in helping can help me derive a development plan...

https://github.com/randyzwitch/H2O.jl

[julia-users] Re: Google releases TensorFlow as open source

[Randy Zwitch]

Sure. I'm not against anyone doing anything, just that it seems like Julia 
suffers from an "expert/edge case" problem right now. For me, it'd be 
awesome if there was just a scikit-learn (Python) or caret (R) type 
mega-interface that ties together the packages that are already coded 
together. From my cursory reading, it seems like TensorFlow is more like a 
low-level toolkit for expressing/solving equations, where I see Julia 
lacking an easy method to evaluate 3-5 different algorithms on the same 
dataset quickly.

A tweet I just saw sums it up pretty succinctly: "TensorFlow already has 
more stars than scikit-learn, and probably more stars than people actually 
doing deep learning"


On Tuesday, November 10, 2015 at 11:28:32 PM UTC-5, Alireza Nejati wrote:
>
> Randy: To answer your question, I'd reckon that the two major gaps in 
> julia that TensorFlow could fill are:
>
> 1. Lack of automatic differentiation on arbitrary graph structures.
> 2. Lack of ability to map computations across cpus and clusters.
>
> Funny enough, I was thinking about (1) for the past few weeks and I think 
> I have an idea about how to accomplish it using existing JuliaDiff 
> libraries. About (2), I have no idea, and that's probably going to be the 
> most important aspect of TensorFlow moving forward (and also probably the 
> hardest to implement). So for the time being, I think it's definitely 
> worthwhile to just have an interface to TensorFlow. There are a few ways 
> this could be done. Some ways that I can think of:
>
> 1. Just tell people to use PyCall directly. Not an elegant solution.
> 2. A more julia-integrated interface *a la* SymPy.
> 3. Using TensorFlow as the 'backend' of a novel julia-based machine 
> learning library. In this scenario, everything would be in julia, and 
> TensorFlow would only be used to map computations to hardware.
>
> I think 3 is the most attractive option, but also probably the hardest to 
> do.
>

[julia-users] Re: Google releases TensorFlow as open source

[Randy Zwitch]

For me, the bigger question is how does TensorFlow fit in/fill in gaps in 
currently available Julia libraries? I'm not saying that someone who is 
sufficiently interested shouldn't wrap the library, but it'd be great to 
identify what major gaps remain in ML for Julia and figure out if 
TensorFlow is the right way to proceed. 

We're certainly nowhere near the R duplication problem yet, but certainly 
we're already repeating ourselves in many areas.

On Monday, November 9, 2015 at 4:02:36 PM UTC-5, Phil Tomson wrote:
>
> Google has released it's deep learning library called TensorFlow as open 
> source code:
>
> https://github.com/tensorflow/tensorflow
>
> They include Python bindings, Any ideas about how easy/difficult it would 
> be to create Julia bindings?
>
> Phil
>

[julia-users] Re: Setting default values in Composite Type definitions

[Randy Zwitch]

Thanks Kristoffer and Cedric, these both get to the heart of the question 
that I am asking.

Stephen, your idea of the macro does achieve what I'm trying to do, except 
for the fact I already have a macro doing that which I'm trying to get OUT 
of my code :) It's good to know the reason why the macro is there is 
because what I want to do isn't currently possible (instead of programmer 
magic for the fun of it).

On Wednesday, November 4, 2015 at 3:09:00 AM UTC-5, Kristoffer Carlsson 
wrote:
>
> This is also a good package for default values in types, keyword arguments 
> in type construction and more: https://github.com/mauro3/Parameters.jl

[julia-users] Setting default values in Composite Type definitions

[Randy Zwitch]

I've been working on understanding some macro code I inherited, which (I 
believe) essentially does this:

type VegaAxis2
_type::Union{AbstractString, Void} = "x"
scale::Union{AbstractString, Void} = "x"
orient::Union{AbstractString, Void} = nothing
title::Union{AbstractString, Void} = nothing
titleOffset::Union{Number, Void} = nothing
format::Union{AbstractString, Void} = nothing
ticks::Union{Number, Void} =  nothing
values::Union{Vector, Void} = nothing
subdivide::Union{Number, Void} = nothing
tickPadding::Union{Number, Void} = nothing
tickSize::Union{Number, Void} = nothing
tickSizeMajor::Union{Number, Void} = nothing
tickSizeMinor::Union{Number, Void} = nothing
tickSizeEnd::Union{Number, Void} = nothing
offset::Union{Number, Dict{Any, Any}, Void} = nothing
layer::Union{AbstractString, Void} = nothing
grid::Union{Bool, Void} = nothing
properties::Union{Dict{Any,Any}, Void} = nothing
end

Running the code above verbatim gives the following error:

LoadError: syntax: "_type::Union{AbstractString,Void}=x" inside type definition 
is reserved
while loading In[87], in expression starting on line 20


I believe macro itself is simulating this behavior by writing out the following 
and time VegaAxis2() is called:


VegaAxis2("x","x",nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing,nothing)


Long story short, why is the assignment behavior inside Composite Types 
reserved? Is this always going to be the behavior, or will this restriction be 
removed in the future, so that you can assign default values?

[julia-users] Re: map() vs. comprehensions

[Randy Zwitch]

I'm going to guess either it's because of the anonymous function definition 
within your map function. Note that you aren't getting *exactly* the same 
results, as the Array types are different.

It also isn't universally true that comprehensions are faster. See the 
following counter-example:

*julia> **s = ["as", "sdf", "qwer"]*

*3-element Array{ASCIIString,1}:*

* "as"  *

* "sdf" *

* "qwer"*


*julia> **@time [length(i) for i in s]*

  0.19 seconds (10 allocations: 384 bytes)

*3-element Array{Any,1}:*

* 2*

* 3*

* 4*


*julia> **@time map(length, s)*

  0.15 seconds (5 allocations: 256 bytes)

*3-element Array{Int64,1}:*

* 2*

* 3*

* 4*


In this case (after multiple runs), map is even or just slightly faster 
than a comprehension. I presume map is faster here because it knows the 
result of function will be Array{Int64}, where as the comprehension Julia 
doesn't know and returns an Array{Any}

On Wednesday, October 21, 2015 at 8:55:50 AM UTC-4, Ján Dolinský wrote:
>
> Hi,
>
> I'd like to check which approach is a better one for the example below. 
> The task is rather simple, each string in vector "s" should be "surrounded" 
> by square brackets.
>
> e.g.
>
> s = AbstractString["as", "sdf", "qwer"] # s is typically a lot longer
>
> @time st1 = AbstractString[ "[" * i * "]" for i in s ]
>   0.57 seconds (16 allocations: 672 bytes)
> 3-element Array{AbstractString,1}:
>  "[as]"  
>  "[sdf]" 
>  "[qwer]"
>
> @time st2 = map(x->"["*x*"]", s)
>   0.002932 seconds (33 allocations: 2.035 KB)
> 3-element Array{ASCIIString,1}:
>  "[as]"  
>  "[sdf]" 
>  "[qwer]"
>
>
>
> The both expressions yield same results. I wonder whether from the 
> language design point of view one approach should be preferred over the 
> other. Comprehension here is considerably faster, I wonder why.
>
> Thanks,
> Jan
>
>

[julia-users] Re: ANN: Julia v0.4.0 released!

[Randy Zwitch]

By building from the release branch, I was robbed of all the excitement! :)

HQSML-146932:julia rzwitc200$ julia

   *_*

   *_**   _ **_**(_)**_** |  A fresh approach to technical 
computing*

  *(_)** | **(_)* *(_)**|  Documentation: http://docs.julialang.org*

*   _ _   _| |_  __ _   |  Type "?help" for help.*

*  | | | | | | |/ _` |  |*

*  | | |_| | | | (_| |  |  Version 0.4.1-pre+3 (2015-10-09 10:34 UTC)*

* _/ |\__'_|_|_|\__'_|  |  Commit d2ace40* (0 days old release-0.4)*

*|__/   |  x86_64-apple-darwin14.5.0*



Great job everyone!



On Friday, October 9, 2015 at 8:38:16 AM UTC-4, Eric Forgy wrote:
>
> Congrats guys. This is a great time to be learning Julia. I've been 
> reading and watching for a while now, but am only starting my first fairly 
> serious Julia project now (and bringing 8 of my devs with me) and am so 
> glad to have Juno/Atom for a very clean workflow. Setting working module is 
> awesome. Feels good to be boarding this train! Looking forward to 0.5 and 
> hope we can help.
>
> On Friday, October 9, 2015 at 7:20:32 PM UTC+8, Tony Kelman wrote:
>>
>> At long last, we can announce the final release of Julia 0.4.0! See 
>> http://julialang.org/blog/2015/10/julia-0.4-release/ for more 
>> details. Binaries are available from the usual place 
>> , and please report all issues to 
>> either the issue tracker  or 
>> email the julia-users list.
>>
>> Many thanks to all the contributors, package authors, users and reporters 
>> of issues who helped us get here. We'll be releasing regular monthly bugfix 
>> backports from the 0.4.x line, while major feature work is ongoing on 
>> master for 0.5-dev. Enjoy!
>>
>>

[julia-users] Re: The status of Julia's Webstack

[Randy Zwitch]

I'm sure if you submitted a pull request to any of the packages mentioned 
to fix the holes, it would be accepted with open arms.

On Tuesday, October 6, 2015 at 5:05:10 PM UTC-4, Mohammed El-Beltagy wrote:
>
> It seems that Morsel.jl and Meddle.jl are quietly dieing away. I noticed 
> that after I did Pkg.update and found that my previously working code is is 
> now failing. Looking that the repositories on github, I noticed that both 
> have been failing their tests. I had to pin down Morsel, Meddle, 
> HttpCommon, HttpServer, and HttpParser to earlier versions to keep my 
> server running. 
>
> There claimed replacement "Mux.jl" is morel like Meddle and can to be 
> regarded as a micro framework. This leaves a significant hole in Julia's 
> package echo system. I wonder if there are any attempts to fill that hole. 
>

[julia-users] Re: What are the "strengths" of the Julia "ecosystem" (e.g. for bio and quants/finance)? This is not a very specific question (while sub-questions are), you've been warned..

[Randy Zwitch]

Julia is as capable as any of the languages you have mentioned as far as 
I'm concerned. When I read "people want to get work done", I read that as 
"people want SOMEONE ELSE to do the work". Julia probably isn't the place 
for them now, if they are looking for someone else to have already provided 
them with every package with every functionality they would ever want. R, 
Python, MATLAB, C/C++, Java, Scala, PHP, JavaScript are all viable 
substitutes in different ways.

But if someone is the type of person who likes to build things and 
collaborate with smart people, then the Julia community will welcome you 
with open arms. 



On Wednesday, September 23, 2015 at 8:04:14 AM UTC-4, Páll Haraldsson wrote:
>
>
> [I have friends who might benefit from Julia.]
>
> Say for, quants/finance and bio (genome sequencing and systems biology). 
> And for me, for web use (what is recommended, Escher; Mux, isn't that 
> Sinatra-style? Nothing available similar to Django/Rails? Or needed? Would 
> Python/Django and Julia work well together? Anyone tried?)
>
> [I just do not want to be "promoting" Julia too much if the libraries are 
> hopelessly broken/immature, and I can't judge myself in very specific 
> cases. Even is they could help, but better to know then. Pointers to good 
> libraries in these three areas that you trust would be good.]
>
>
> I pretty much think I know the strengths of Julia -  as a language, but 
> people want to get work done, and libraries matter. I'm not just asking for 
> existence, I'm aware of a lot of libraries in these and other areas, I'm 
> thinking what is the coverage of those areas and are they beta quality (and 
> help needed?)?
>
> I don't know maybe the questions about these areas need to be more 
> targeted? Should I ask the what they do/need as I'm ignorant of that..? I'm 
> also just curious in general how big the landscape of powerful libraries 
> is.. I understand e.g the optimization libraries are best in class..
>
>
> [My quant (physicist friend used Python/Numpy/C++, and the systems biology 
> one MATLAB/C++. I guess if there are gaps you can easily use the other 
> languages together to fill them, less so with MATLAB?]
>
>
> Thanks,
> -- 
> Palli
>
>

Re: [julia-users] [ANN] Plots.jl, a plotting interface

[Randy Zwitch]

Nope, just another generic statement :) 

All I mean is, I'm trying to make a wrapper for Vega that is simple/obvious 
and powerful. All of my code will be focused on the "Vega way" of doing 
things, as opposed to an abstract way for all backends as you are 
approaching things. So there could be overlap, but I'm not at the point 
where I'm actively looking for synergies, since there's so much more to do 
to make Vega.jl viable at all.

On Monday, September 14, 2015 at 11:04:31 AM UTC-4, Tom Breloff wrote:
>
> Randy: do you have an issue or design description of what you're looking 
> to accomplish with your "interactivity interface"?  There could be more 
> overlap than you think...
>
> On Mon, Sep 14, 2015 at 11:02 AM, Randy Zwitch  > wrote:
>
>> Sure, I was just speaking in generic terms. My goals for Vega are similar 
>> to your goals for static plots; in addition, I'm looking to define an 
>> interactivity interface...both of which don't necessarily overlap with 
>> Tom's goals with Plots.jl, but may in the future.
>>
>> On Monday, September 14, 2015 at 10:50:29 AM UTC-4, Daniel Carrera wrote:
>>>
>>> Hi Randy,
>>>
>>> To be clear, interactivity (as I understand it) is not something I want 
>>> or would use. I need to change the plot settings programmatically so I can 
>>> reproduce the exact same plot later if I need to.
>>>
>>> Cheers,
>>> Daniel.
>>>
>>> On 14 September 2015 at 16:02, Randy Zwitch  
>>> wrote:
>>>
>>>> Daniel, this is the approach that I'm taking with Vega.jl; trying to 
>>>> make simple things obvious to change and crazy interactivity from Vega 
>>>> accessible *somehow* (still working on that!). Not sure how that will fit 
>>>> into a common plot interface, but once I'm further along, hopefully I can 
>>>> contribute to this effort.
>>>>
>>>> On Monday, September 14, 2015 at 9:03:31 AM UTC-4, Daniel Carrera wrote:
>>>>>
>>>>> On Friday, 11 September 2015 03:48:44 UTC+2, Tom Breloff wrote:
>>>>>>
>>>>>> Hi Miguel... Looking forward to your comments. The short answer is 
>>>>>> that it depends on the situation. For functionality that just isn't 
>>>>>> possible for a backend, I'll probably just throw an error (ideally with 
>>>>>> a 
>>>>>> message describing other backends that can do what you're looking for). 
>>>>>> For 
>>>>>> some cases, I might automatically replace the call with something 
>>>>>> similar. 
>>>>>> For an example, I couldn't figure out how to make a "sticks" plot in 
>>>>>> Gadfly, so I made a bar plot instead. I hope that the package authors 
>>>>>> can 
>>>>>> help me with this process though... Sometimes there's undocumented 
>>>>>> functionality that does what I need, and it would be a big help to have 
>>>>>> package authors contribute. 
>>>>>>
>>>>>> I also want to hear from people on visualizations that aren't 
>>>>>> possible with this API, as this all falls apart if you only cover some 
>>>>>> of 
>>>>>> your needs through Plots.jl. Look at the TODO at the bottom of the 
>>>>>> readme 
>>>>>> for an idea of my roadmap, and let me know if you want me to add to or 
>>>>>> prioritize something. 
>>>>>>
>>>>>
>>>>>
>>>>> Overwhelmingly, I do relatively simple scatter plots and line plots; 
>>>>> with the occasional "heat map" plot. The priority for me is to be able to 
>>>>> fiddle with the details of the plot: change the font, define a new 
>>>>> colour, 
>>>>> remove the tick marks, have two y-axes, change the aspect ratio, insert 
>>>>> formulas in LaTeX, etc. So the plot itself is usually very simple, but I 
>>>>> need to be able to make any change requested by my supervisor, or the 
>>>>> journal editor, or the referee.
>>>>>
>>>>> Cheers,
>>>>> Daniel.
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, September 10, 2015, Miguel Bazdresch  
>>>>>> wrote:
>>>>>>
>>

Re: [julia-users] [ANN] Plots.jl, a plotting interface

[Randy Zwitch]

Sure, I was just speaking in generic terms. My goals for Vega are similar 
to your goals for static plots; in addition, I'm looking to define an 
interactivity interface...both of which don't necessarily overlap with 
Tom's goals with Plots.jl, but may in the future.

On Monday, September 14, 2015 at 10:50:29 AM UTC-4, Daniel Carrera wrote:
>
> Hi Randy,
>
> To be clear, interactivity (as I understand it) is not something I want or 
> would use. I need to change the plot settings programmatically so I can 
> reproduce the exact same plot later if I need to.
>
> Cheers,
> Daniel.
>
> On 14 September 2015 at 16:02, Randy Zwitch  > wrote:
>
>> Daniel, this is the approach that I'm taking with Vega.jl; trying to make 
>> simple things obvious to change and crazy interactivity from Vega 
>> accessible *somehow* (still working on that!). Not sure how that will fit 
>> into a common plot interface, but once I'm further along, hopefully I can 
>> contribute to this effort.
>>
>> On Monday, September 14, 2015 at 9:03:31 AM UTC-4, Daniel Carrera wrote:
>>>
>>> On Friday, 11 September 2015 03:48:44 UTC+2, Tom Breloff wrote:
>>>>
>>>> Hi Miguel... Looking forward to your comments. The short answer is that 
>>>> it depends on the situation. For functionality that just isn't possible 
>>>> for 
>>>> a backend, I'll probably just throw an error (ideally with a message 
>>>> describing other backends that can do what you're looking for). For some 
>>>> cases, I might automatically replace the call with something similar. For 
>>>> an example, I couldn't figure out how to make a "sticks" plot in Gadfly, 
>>>> so 
>>>> I made a bar plot instead. I hope that the package authors can help me 
>>>> with 
>>>> this process though... Sometimes there's undocumented functionality that 
>>>> does what I need, and it would be a big help to have package authors 
>>>> contribute. 
>>>>
>>>> I also want to hear from people on visualizations that aren't possible 
>>>> with this API, as this all falls apart if you only cover some of your 
>>>> needs 
>>>> through Plots.jl. Look at the TODO at the bottom of the readme for an idea 
>>>> of my roadmap, and let me know if you want me to add to or prioritize 
>>>> something. 
>>>>
>>>
>>>
>>> Overwhelmingly, I do relatively simple scatter plots and line plots; 
>>> with the occasional "heat map" plot. The priority for me is to be able to 
>>> fiddle with the details of the plot: change the font, define a new colour, 
>>> remove the tick marks, have two y-axes, change the aspect ratio, insert 
>>> formulas in LaTeX, etc. So the plot itself is usually very simple, but I 
>>> need to be able to make any change requested by my supervisor, or the 
>>> journal editor, or the referee.
>>>
>>> Cheers,
>>> Daniel.
>>>
>>>
>>>  
>>>
>>>>
>>>>
>>>> On Thursday, September 10, 2015, Miguel Bazdresch  
>>>> wrote:
>>>>
>>>>> Hi Tom,
>>>>>
>>>>> I'm the author of Gaston.jl. This looks interesting, and I'll take a 
>>>>> closer look. I'm wondering, how do you plan to handle the different 
>>>>> capabilities of each backend? Say, for example, that the user specifies a 
>>>>> plot that Gaston can't handle -- maybe the marker type is not supported 
>>>>> by 
>>>>> Gnuplot, or something like that.
>>>>>
>>>>> -- mb
>>>>>
>>>>> On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff  wrote:
>>>>>
>>>>>> This may be a slightly premature announcement, but I wanted to put it 
>>>>>> out there so that people that have strong opinions have a chance to give 
>>>>>> their thoughts.  Here's the link:
>>>>>>
>>>>>> https://github.com/tbreloff/Plots.jl
>>>>>>
>>>>>> Plots.jl is intended to be an API/interface that sits above other 
>>>>>> plotting packages (backends) and gives the user simple, consistent, and 
>>>>>> flexible plotting commands.  It's a problem when someone is used to a 
>>>>>> package which is great for interactive plots, but then has to re-learn 
>>>>>> and 
>>>

Re: [julia-users] [ANN] Plots.jl, a plotting interface

[Randy Zwitch]

Daniel, this is the approach that I'm taking with Vega.jl; trying to make 
simple things obvious to change and crazy interactivity from Vega 
accessible *somehow* (still working on that!). Not sure how that will fit 
into a common plot interface, but once I'm further along, hopefully I can 
contribute to this effort.

On Monday, September 14, 2015 at 9:03:31 AM UTC-4, Daniel Carrera wrote:
>
> On Friday, 11 September 2015 03:48:44 UTC+2, Tom Breloff wrote:
>>
>> Hi Miguel... Looking forward to your comments. The short answer is that 
>> it depends on the situation. For functionality that just isn't possible for 
>> a backend, I'll probably just throw an error (ideally with a message 
>> describing other backends that can do what you're looking for). For some 
>> cases, I might automatically replace the call with something similar. For 
>> an example, I couldn't figure out how to make a "sticks" plot in Gadfly, so 
>> I made a bar plot instead. I hope that the package authors can help me with 
>> this process though... Sometimes there's undocumented functionality that 
>> does what I need, and it would be a big help to have package authors 
>> contribute. 
>>
>> I also want to hear from people on visualizations that aren't possible 
>> with this API, as this all falls apart if you only cover some of your needs 
>> through Plots.jl. Look at the TODO at the bottom of the readme for an idea 
>> of my roadmap, and let me know if you want me to add to or prioritize 
>> something. 
>>
>
>
> Overwhelmingly, I do relatively simple scatter plots and line plots; with 
> the occasional "heat map" plot. The priority for me is to be able to fiddle 
> with the details of the plot: change the font, define a new colour, remove 
> the tick marks, have two y-axes, change the aspect ratio, insert formulas 
> in LaTeX, etc. So the plot itself is usually very simple, but I need to be 
> able to make any change requested by my supervisor, or the journal editor, 
> or the referee.
>
> Cheers,
> Daniel.
>
>
>  
>
>>
>>
>> On Thursday, September 10, 2015, Miguel Bazdresch  
>> wrote:
>>
>>> Hi Tom,
>>>
>>> I'm the author of Gaston.jl. This looks interesting, and I'll take a 
>>> closer look. I'm wondering, how do you plan to handle the different 
>>> capabilities of each backend? Say, for example, that the user specifies a 
>>> plot that Gaston can't handle -- maybe the marker type is not supported by 
>>> Gnuplot, or something like that.
>>>
>>> -- mb
>>>
>>> On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff  wrote:
>>>
 This may be a slightly premature announcement, but I wanted to put it 
 out there so that people that have strong opinions have a chance to give 
 their thoughts.  Here's the link:

 https://github.com/tbreloff/Plots.jl

 Plots.jl is intended to be an API/interface that sits above other 
 plotting packages (backends) and gives the user simple, consistent, and 
 flexible plotting commands.  It's a problem when someone is used to a 
 package which is great for interactive plots, but then has to re-learn and 
 re-code new plots in another package when producing publication-quality 
 plots (or vice versa).  The same goes for switching between desktop GUIs 
 and javascript technologies... sometimes one package is better than 
 another 
 for a specific task, and it's a shame to be forced to choose.

 I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl 
 backends.  See the examples to get a sense of how they differ.  I think 
 Vega.jl and UnicodePlots.jl might be next on my priority list, but please 
 let me know if I should prioritize differently.  Note: This is still a 
 work 
 in progress, and I will probably change parts of the API, and not every 
 plot type is implemented yet.

 Please let me know comments, wish lists, etc.  Issues are great for 
 actionable items, comments can go here.  This effort was partially 
 inspired 
 by various discussions here and on github, which prompted the forming of 
 https://github.com/JuliaPlot, and an effort to improve the plotting 
 landscape with tutorials and documentation.  If you're interested: 
 https://github.com/JuliaPlot/juliaplot_docs/issues

 Tom

>>>
>>>

[julia-users] Re: 'in' should carry out more typechecking

[Randy Zwitch]

How do you enumerate all of the cases that are "oddball"?

*julia> **[1,2,3] in Any[[1],[2],[3],[1,2,3]]*

*true*


*julia> **[1,2,3] in [[1],[2],[3],[1,2,3]]*

*false*


In the first case, because I declare the array of type "Any", I have an 
Array of Arrays (Array{Any, 1}). In that case, the "in" statement is 
perfectly valid to test for and is true.


In the second case, you get false. What's difficult here is that I think 
the compiler is confused due to the change in concentation syntax:


*julia> **typeof([[1],[2],[3],[1,2,3]])*

*WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead*

 in depwarn at ./deprecated.jl:73

 in oldstyle_vcat_warning at ./abstractarray.jl:29

 in vect at abstractarray.jl:32

while loading no file, in expression starting on line 0

*Array{Int64,1}*



I'm not proposing a solution, just highlighting that it would be pretty 
difficult to protect everyone from themselves. At some point, people need 
to be precise about what they mean.




On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, vav...@uwaterloo.ca 
wrote:
>
> About a year ago I proposed on this forum that 'in' should do more 
> type-checking.  For example, the expression
>
>[1,2,3] in [1,2,3,4]
>
> is almost certainly a programmer error.  But Julia accepts it without 
> complaint and returns 'false'.  I myself have had problems with the wrong 
> version of 'in' getting called and nonsensical results returned.
>
> The argument raised against this proposal was the following.  According to 
> Julia semantics, "a in b" is equivalent to
>
>  for x in b
> if x==a
>return true
> end
>  end
>  return false 
>
> But in fact, as the Julia 0.4 recent masters show, there are at least two 
> cases in which 'in' does not follow these semantics and returns an error if 
> it thinks the programmer made a mistake.  (See the trace below-- both are 
> cases where Julia 0.4 changed behavior from 0.3).
>
> It is important for Julia to be vigilant about catching obvious programmer 
> errors.  This will help improve its chances for use in introductory 
> programming courses at universities, among other reasons.
>
> I propose the following: In Julia 0.5, Base should be broken up into Base 
> and ExpansiveBase.  Functions like in(x::Any,itr::Any) from reduce.jl or 
> start(x::Number) from number.jl that allow oddball user code to be accepted 
> by the compiler would be put into ExpansiveBase.  The semantics for 
> 'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or 
> that there exists a method convert(eltype(b),a).
>
> -- Steve Vavasis
>
>
> julia> 0 in IntSet()
> WARNING: stored zeros in IntSet is deprecated
>  in depwarn at deprecated.jl:63
>  in in at intset.jl:163
> while loading no file, in expression starting on line 0
> false
>
> julia> (1,2) in Dict{Any,Any}()
> ERROR: Associative collections only contain Pairs;
> Either look for e.g. A=>B instead, or use the `keys` or `values`
> function if you are looking for a key or value respectively.
>  in in at dict.jl:13
>
>

[julia-users] Including JavaScript libraries for Jupyter Notebook/IJulia

[Randy Zwitch]

Hi all - 

I have an open issue on the IJulia tracker, but I didn't want to leave the 
burden to just Matthias.

If you can help me re-add Jupyter Notebook support back to the Vega.jl 
master branch, it would be greatly appreciated. The current version of Vega 
on METADATA works through the notebook, but it doesn't work with Vega 2, 
and in general I'd like to solve this the right way once and for all. 
 Thanks!

https://github.com/JuliaLang/IJulia.jl/issues/345

Randy 

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

[Randy Zwitch]

Great job Avik! I can confirm that JDBC.jl works on Teradata on OSX.

On Friday, July 17, 2015 at 9:05:51 AM UTC-4, Avik Sengupta wrote:
>
> I am pleased to announce the availability of JDBC.jl. Available via your 
> favourite package repository: Pkg.add("JDBC") or at 
> https://github.com/aviks/JDBC.jl . It has a dependency on JavaCall.jl, 
> and you will need to install Java where you want to use it. 
>
> Currently this supports plain SQL (insert/update/select/DDL), prepared 
> statements and stored procedures.  The interface mimics the Java JDBC API. 
> The primary data access method is to iterate over the Resultset. An 
> optional "readtable" method can convert a ResultSet into a Julia Dataframe. 
>
> Blob types are not supported yet, nor are more esoteric features such as 
> scrollable cursors or Rowsets. However the power of JavaCall means that you 
> can easily drop down and directly call Java methods that are not yet 
> wrapped. Issues or PR's about missing functionality is welcome. 
>
> Finally, there are tons of different databases that have JDBC drivers. I 
> cannot feasibly test them all myself. So please let me know any reports of 
> success or failure with different databases. 
>
> Regards
> -
> Avik
>
>
>  
>

[julia-users] Re: Too many packages?

[Randy Zwitch]

I've been trying to take Vega down the same road as you are with your Qwt 
package Tom, with no external dependencies.

On Monday, July 13, 2015 at 9:29:14 AM UTC-4, Tom Breloff wrote:
>
> Packages:  I fall into the camp of "tiny base, curated packages".  It 
> would be great to have an absolutely minimal core julia, and then lots of 
> "build recipes" for those people that want a matlab-like experience.  For 
> example, JuliaStats could be responsible for compiling a "best of breed" 
> list of key stats and plotting packages for the "stats recipe", etc.  Then 
> on installation you can say what recipes you'd like to include (maybe it 
> defaults to most/all of the major recipes so people don't even need to 
> think about it?).
>
> Plotting:  I agree that simple plotting with minimal dependencies is the 
> way to go for a standard package.  I don't think Gadfly fits that very well 
> in it's current form... there needs to be simple ways to plot and there 
> should not be a strong (or any?) dependency on DataFrames.  I'm certainly 
> not recommending that this become standard, but look at the readme of 
> https://github.com/tbreloff/Qwt.jl 
> 
>  
> as what I think the basic plotting interface should look like.
>
> On Monday, July 13, 2015 at 5:12:53 AM UTC-4, yu...@altern.org wrote:
>>
>> On Sunday, 12 July 2015 22:47:42 UTC+2, Tony Kelman wrote:
>>
>>> > I think there's a big differences between developing core features in 
>>> packages and shipping them with the default version and having optional 
>>> third party packages implementing core features.
>>>
>>> Like what, exactly? If the complaint is about ease of installation of 
>>> packages, then that's a known and acknowledged bug (set of bugs) that 
>>> people are thinking about how to do a better job of. We could always use 
>>> more help making things better.
>>>
>>
>> If there's a bunch of official packages that are shipped with default 
>> version it's like having no packages, it's just a way for the devs to 
>> organize their work internally that doesn't concern the user too much.
>>
>> On the other hand for third party packages the user has to find them, 
>> install them, debug them, worry about long term maintenance, etc. In 
>> reality it's a bit more fuzzy than that, so maybe my distinction isn't so 
>> relevant.
>>
>>
>> For plotting I think it would be better to have any plotting than none, 
>> even though not everybody will agree on the best choice for the one. The 
>> least dependencies seems the most important criteria to me, as long as you 
>> can draw lines, points and surfaces with decent performances. The high 
>> level interface doesn't matter that much in my opinion. 
>>
>

[julia-users] Re: Juliacon 2015 videos?

[Randy Zwitch]

They were all recorded. Be patient, everyone is a volunteer :)

On Wednesday, July 1, 2015 at 8:07:18 AM UTC-4, Hans-Peter wrote:
>
> Will there be videos of the 2015 Juliacon? Where... :-)
> Thanks.
>

[julia-users] JuliaCon: Software expectations / attendance lists?

[Randy Zwitch]

Two thoughts as a workshop presenter:

1) What version of Julia should we be using, both so that the presenter 
knows and anyone following along has a similar environment?

2) Along the lines of #1, are all of the talks just going to be a 
free-for-all of attendance? I'm not suggesting that anything rigorous is 
desirable, just wondering how I would communicate to people coming to my 
workshop (hopefully someone!). Or, should we just do environment/package 
setup via GitHub at the beginning of the session?

[julia-users] Re: New article about Julia, Viral Shah

[Randy Zwitch]

New by way of 2013? :)

On Monday, June 1, 2015 at 3:15:27 AM UTC-4, Scott Jones wrote:
>
> http://analyticsindiamag.com/interview-viral-shah-co-creator-of-julia/
>

[julia-users] Re: Julia blogging and contributions

[Randy Zwitch]

I set up juliabloggers...being worried, I checked the site and it still 
checks the blogs of those that submitted their domains; strangely, everyone 
just stop blogging at the same time I guess (including myself). Not sure 
what to make of that, other than people just being busy.

If anyone doesn't want to go through the hassle of setting up their own 
blog, I guess I could create individual WordPress accounts (though, I was 
hoping to have little-to-no manual intervention into the blog).

On Monday, March 23, 2015 at 11:51:44 AM UTC-4, Hans W Borchers wrote:
>
> Julia Blogging and Contributions
>
>   * The last entry on juliabloggers.com is now three and a half months 
> old. 
> I understand that the core developers don't have much time to write 
> blog 
> entries. Are there other reasons why blogging has stopped for Julia?
>
>   * Are there Julia blogs specializing in numerical mathematics, 
> differential 
> equations, optimization and/or simulation?
>
>   * Are there blogs that would be interested in receiving contributions 
> from 
> time to time? I will not set up my own blog, but every now and then I 
> may 
> have something to add in this area.
> (Kind of 'multi-blogs' -- is this against the law of blogs?)
>
> Thanks for clarifications or hints.
>
>

[julia-users] Re: how to paste png into ipython julia notebook?

[Randy Zwitch]

True. I share my notebooks as GitHub repos, so I've always passed the 
images along.

On Friday, March 13, 2015 at 11:50:32 AM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Friday, March 13, 2015 at 11:44:57 AM UTC-4, Randy Zwitch wrote:
>>
>> You can also use plain HTML in a markdown cell.
>>
>
> Yes, you can use  tags, but then the image data is not included 
> in the notebook file itself, so unless the image is on a server somewhere 
> that makes it more annoying to share the notebook (as you have to remember 
> to copy the image file along with the notebook). 
>

[julia-users] Re: how to paste png into ipython julia notebook?

[Randy Zwitch]

You can also use plain HTML in a markdown cell.

On Wednesday, March 11, 2015 at 12:05:07 PM UTC-4, Edward Chen wrote:
>
> from IPython.display import Image
> Image(filename='image.png')
>
> doesn't seem to work
>
> Thanks!
> -Ed
>

[julia-users] Re: Getting people to switch to Julia - tales of no(?) success

[Randy Zwitch]

I'm like you Seth in that I don't use most of the stuff that people on this 
list talk about. I also have no frame-of-reference to MATLAB, just a 
Python/R/SQL guy (and recovering SAS user).

For me, the language is plenty stable, but I also appreciate a challenge. 
But for my common workflow, I mostly just need to interpolate strings, get 
data from databases, make plots. I successfully use Hadoop via Julia via 
ODBC via Hive (whew!) nearly everyday, and it works great for me. Gadlfy is 
a bit slow to get started up, but given that I can output to d3 and post to 
the web...that's a pretty killer feature. 

So it's really just perspective. I show people what I'm doing, and if they 
get interested, great. As a previous commenter wrote, there are people who 
create languages/packages and people who wait for the packages to be 
developed. 


On Thursday, March 5, 2015 at 10:38:00 AM UTC-5, Seth wrote:
>
> I'm probably one of the few Julia users who's NOT using it for scientific 
> / numerical analysis / very-obscure-technical-field work. I'm just a 
> general programmer - I'm more interested in getting data from point A to 
> point B, processing it quickly (whether that's parsing web server logs or 
> creating user activity graphs - a lot of the work I do is security 
> related), and then outputting it in a way that makes sense to me. I use 
> python but find that Julia's speed (both of execution and of development) 
> is too good to pass up, especially for complex things. (Also, python's 
> regex handling is horrific, and really, no general programmer is still 
> using Perl :) )
>
> For my use case Julia is both amazingly good and incredibly frustrating. I 
> love writing Julia code, but the instability of some of the core libraries 
> drives me nuts. Here's my biggest challenge:
>
> Core to any language should be a standards-based way of getting data in 
> and out. Right now Julia's a bit of a mess in that regard. For example, 
> Base has download(), which in turn relies on system utilities: curl, wget, 
> or fetch, according to the docs, which also say something to the effect of 
> "casual use only". JuliaWeb (of which I am a member) has a variety of 
> packages with duplicate functionality, including Requests.jl and 
> HTTPClient, but there is no settled standard yet for the underlying 
> technology, and each package has its own set of limitations not found (or 
> better hidden) in more mature packages in other languages.
>
> Until we figure out a way to make it easy for folks to get their data into 
> and out of Julia, I think we're leaving potential new users "on the table", 
> unwilling to switch because migration is just too hard, and the lack of 
> good data transfer / network utilities is a large part of that. So this is 
> my plea: if you're interested in helping form the basis for a great 
> web/data transport stack in Julia, please join us in JuliaWeb. We've got a 
> list of issues posted https://github.com/JuliaWeb/Roadmap/issues in case 
> you feel an urge to help fix some things and develop some new things. It's 
> pretty much a green field at this point.
>
>
>

[julia-users] Re: CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT

[Randy Zwitch]

Submitted. Looking forward to making it to JuliaCon this year, speaker or 
otherwise!

On Monday, February 23, 2015 at 9:46:57 PM UTC-5, Jiahao Chen wrote:
>
> On behalf of the JuliaCon 2015 Program Committee, it is my pleasure to 
> announce that the *Call for Participation **for JuliaCon 2015 is now 
> open.*
>
> Venue: MIT Ray & Maria Stata Center, 32 Vassar Street, Cambridge, 
> Massachusetts 02139.
>
> *Call for Participation closes: April 8, 2015, 11:59pm EDT*
> *Estimated notification: April 18, 2015*
> *JuliaCon dates: June 24 - 28, 2015*
>
> JuliaCon proposal submission form: link .
> JuliaCon website: juliacon.org (to be updated shortly)
> JuliaCon program committee email: juli...@googlegroups.com .
>
> JuliaCon 2015 is looking for Julia users like you to speak! We’re looking 
> for talks and workshops about using Julia, whether that means writing a 
> Julia package or doing your research using Julia.
>
> *Who will decide the program?*
>
> The JuliaCon program committee is composed of entirely of volunteer 
> organizers and can be reached at juli...@googlegroups.com  
> with any questions or comments. Please limit your submissions to no more 
> than 3 proposals.
>
> If you’re having trouble deciding on a topic, please send us an email; 
> we’re happy to help.
>
> *What kinds of presentations are we looking for?*
>
> We are looking for speakers for three types of presentations: regular 
> talks, lightning talks, and workshops. The types of presentations differ in 
> the amount of time allotted.
>
>- Each regular talk will receive *35 minutes* of presentation time and *5 
>minutes* for Q&A.
>- Each lightning talk will receive *8 minutes* to speak and *2 minutes* 
>for Q&A.
>- Workshops are larger blocks of time which are useful for tutorials, 
>in-depth presentations of deeper ideas, and hackathons. Each workshop slot 
>will be given *up to 3 hours*. Please note in your proposal how much 
>time your workshop will require.
>
> Speakers are expected to bring their own laptops to connect to the 
> projectors.
>
> *What will the audience be like?*
>
> The audience will be users of Julia, and come from widely varying 
> backgrounds and interests. They range from professional programmers who 
> enjoy new languages to professors who use Julia as a tool in their work. 
> While many Julia users are very comfortable with math and statistics, the 
> only thing you can consistently assume is that they’ve written some Julia 
> code before.
>
> JuliaCon 2015 will also feature a tutorial for new users.
>
> *What topics are you looking for?*
>
> As long as it’s about Julia or using Julia, it’s on topic. We’re looking 
> for talks about work that you’ve already done or have made significant 
> progress on. Demos are welcome.
>
> Last year, there were many talks about specific Julia packages. This is a 
> great way to advertise a package you wrote (or love to use). We want to 
> know what your package does, how it does it, and how did using Julia affect 
> your package, for better or worse.
>
> See the video recordings from last year at juliacon.org to get a feel for 
> what people presented and what the audience expected.
>
> If you want to speak but are having trouble coming up with a topic, the 
> best topics are centered on your experience using Julia. Besides creating 
> or maintaining a package, your experience teaching Julia or using Julia in 
> your work or research would also be interesting. We are specifically 
> interested in your experience with Julia in a classroom setting.
>
> If you’re looking for presentation ideas, consider talks about: compilers, 
> runtimes, parallelism, experiences teaching Julia, scientific computing, 
> and/or visualization.
>
> *Do you have any tips for filling out the submission form?*
>
> *Biography:*
>
> This will be listed on the website when the speakers are announced. This 
> is a good place to mention if you’ve created a Julia package or maintain 
> one.
>
> *Title:*
>
> Make your title reflect your topic (rather than being clever) Please 
> reserve “Julia In Production” style titles for experience reports of using 
> Julia at companies, not research. (customer-facing, revenue-generating, 
> etc). However, we still do want to hear about using Julia for research, 
> just don’t use the word production in the title.
>
> *Abstract:*
>
> The abstract is a summary of what you wanted to do, what you ended up 
> doing, the results you obtained, and what you learned from the experience. 
> This will be listed on the website if your talk is accepted.
>
> *Special notes:*
>
> Please note in your submission if:
>
>- You do not want your presentation recorded and posted on the 
>JuliaCon website. We plan to record all presentations by default.
>- You need additional resources beyond the standard video projector 
>and laser pointer. (We expect speakers to bring their own laptops unless 
>you ask f

[julia-users] Re: Almost at 500 packages!

[Randy Zwitch]

Geez, had I known there would be a race to 500, I'd have submitted my OAuth 
1 package (per Stefan's point though, I'm sans documentation and tests at 
the moment)

On Tuesday, January 20, 2015 at 3:39:33 PM UTC-5, Viral Shah wrote:
>
> I wonder what the 500th package will be.
>
> -viral
>
> On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote:
>>
>> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
>> registered packages with at least one version tagged that are Julia 0.4-dev 
>> compatible (493 on Julia 0.3).
>>
>> Thanks to all the package developers for their efforts in growing the 
>> Julia package ecosystem!
>>
>>

Re: [julia-users] Re: home page content

[Randy Zwitch]

I think it would please everyone if you moved daily televised scrums.


On Wednesday, December 10, 2014 4:53:50 PM UTC-5, John Myles White wrote:
>
> Stefan, I shared your moment of terror about the idea of posting plans 
> (essentially all of which will be invalidated) to the home page.
>
> Although it's huge volume of e-mail, I do feel like people who want to 
> keep up with new developments in Julia should try to subscribe to the issue 
> tracker and watch decisions get made in real time. It's a large increase in 
> workload to ask people to both do work on Julia and write up regular 
> reports about the work.
>
>  -- John
>
> On Dec 10, 2014, at 1:48 PM, Stefan Karpinski  > wrote:
>
> I have to say the concept of putting plans up on the home page fills me 
> with dread. That means I have update the home page while I'm planning 
> things and as that plan changes and then do the work and then document it. 
> It's hard enough to actually do the work.
>
> On Wed, Dec 10, 2014 at 4:44 PM, David Anthoff  > wrote:
>
>> +1 on that! Even vague plans that are subject to change would be great to 
>> have.
>>
>>  
>>
>> *From:* julia...@googlegroups.com  [mailto:
>> julia...@googlegroups.com ] *On Behalf Of *Christian Peel
>> *Sent:* Wednesday, December 10, 2014 10:15 AM
>> *To:* julia...@googlegroups.com 
>> *Subject:* Re: [julia-users] Re: home page content
>>
>>  
>>
>> One thing that I would very much appreciate is some kind of development 
>> schedule.  For example
>>   - Some kind of general roadmap
>>   - a plan for when 0.4 and future releases will come
>>   - Any plans to switch to a regular schedule?  (yearly, six
>> months, ...) 
>>   - What features remain before a 1.0 release?
>>   - When will following arrive?
>> > faster compilation
>> > pre-compiled modules
>> > Interactive debugging; line numbers for all errors
>> > Automatic reload on file modification.
>> > Solving P=NP
>>
>> I know that it's tough to make such a schedule, but anything that you can 
>> provide would be helpful. Also, I'd be happy for something like a weekly 
>> update; or a weekly blog post to help those who don't peruse this group in 
>> depth each day.
>>
>> Thanks!
>>
>> Chris
>>
>> On Wednesday, December 10, 2014 5:41:35 AM UTC-8, Tamas Papp wrote:
>>
>> From the discussion, it looks like that homepages for programming 
>> languages (and realed projects) serve two purposes: 
>>
>> A. provide resources for the existing users (links to mailing lists, 
>> package directories, documentation, etc) 
>>
>> B. provide information for potential new users (showcasing features of 
>> the language, links to tutorials). 
>>
>> Given that space on the very front page is constrained (in the soft 
>> sense: no one wants pages that go on and on any more), I think that 
>> deciding on a balance between A and B would be a good way to focus the 
>> discussion. 
>>
>> Once we have decided that, we can shamelessly copy good practices. 
>>
>> For example, 
>>
>> 1. the R website emphasizes content for existing users (in a non-flashy 
>> way that I am OK with), with very little material for new users, 
>>
>> 2. about 1/3 of the middle bar on 
>> https://www.haskell.org/haskellwiki/Haskell is for new users 
>> (explanations/tutorials/etc), the 1/3 is for existing users (specs, 
>> libraries), and the final 1/3 is for both (forums, wiki, etc), 
>>
>> 3. http://new-www.haskell.org/ is mostly caters to potential new users 
>> ("see how great this language is"), 
>>
>> 4. the content of clojure.org is similarly for potential new users, 
>> while the sidebar has links for existing users. 
>>
>> Best, 
>>
>> Tamas 
>>
>> On Wed, Dec 10 2014, Hans W Borchers  wrote: 
>>
>> > Look at the R home page. R is one of the most popular languages, and 
>> esp. so 
>> > for statistical and computational applications. A programming language 
>> does 
>> > not need bloated home pages. 
>> > 
>> > I like the old Haskell home page much more than the new one. The new 
>> one 
>> > has 
>> > large, uninformative background pictures and not much information in a 
>> > small 
>> > and readable view. The HaskellWiki front page was much better in that. 
>> It 
>> > may 
>> > not even be decided which version will win. 
>> > 
>> > [Clojure])http://clojure.org/) has a nice, simple and informative home 
>> > page, 
>> > while [Scala](http://www.scala-lang.org/) has overdone it like the new 
>> > Haskell. For other approaches see the [Nim](http://nimrod-lang.org/) - 
>> > formerly 'Nimrod' - and [Nemerle](http://nemerle.org/) home pages. 
>> > 
>> > In the end I feel the condensed form of the Python home page will 
>> attract 
>> > more interest, for example with 'latest news' and 'upcoming events' on 
>> the 
>> > first page.This gives the impression of a lively and engaged community. 
>> > 
>> > 
>> > On Wednesday, December 10, 2014 11:23:37 AM UTC+1, Tim Holy wrote: 
>> >> 
>> >> I like the Haskell one better than the Rust one. 
>> >> 
>> >> --Tim 
>> >

Re: [julia-users] Re: home page content

[Randy Zwitch]

Note that the framework is in place via juliabloggers.com. If someone 
wanted to pick up this task, but didn't want to dedicate creating a blog, 
I'm willing to create an author account to post directly.

On Wednesday, December 10, 2014 1:46:03 PM UTC-5, John Myles White wrote:
>
> As always in Julia (and OSS in general), I think the problem is that 
> there's no labor supply to do most "nice" things for the community. 
> Everybody would love to see weekly updates. Not many people have both the 
> time and desire to do the work. 
>
>  -- John 
>
> On Dec 10, 2014, at 10:41 AM, Tamas Papp > 
> wrote: 
>
> > 
> > On Wed, Dec 10 2014, Christian Peel > 
> wrote: 
> > 
> >> provide would be helpful. Also, I'd be happy for something like a 
> weekly 
> >> update; or a weekly blog post to help those who don't peruse this group 
> in 
> >> depth each day. 
> > 
> > there was 
> > 
> > http://thisweekinjulia.github.io/ 
> > 
> > but it has not been updated since late October. 
> > 
> > best, 
> > 
> > Tamas 
>
>

Re: [julia-users] Metaprogramming: what's going on here/is there a better way?

[Randy Zwitch]

Thanks for all of the input everyone, I think I get what's going on now!

On Tuesday, November 18, 2014 7:19:44 AM UTC-5, Mike Innes wrote:
>
> Ah ok, that's a nice trick too – I didn't know you could do that (although 
> it makes perfect sense).
>
> Note that this also constructs the string at runtime, though.
>
> On 18 November 2014 12:13, > wrote:
>
>>
>>
>> On Tuesday, November 18, 2014 7:40:53 PM UTC+10, Mike Innes wrote:
>>>
>>> The basic reason for this is that it's fairly common to write something 
>>> like:
>>>
>>> quote
>>>   let x = 5
>>> "x is $x"
>>>   end
>>> end |> eval #> "x is 5"
>>>
>>
>> But to do what the OP wants I think you can do "x is $($x)" (but I don't 
>> have Julia available just now to test.
>>
>> Cheers
>> Lex
>>
>> [...]
>>
>
>

Re: [julia-users] Metaprogramming: what's going on here/is there a better way?

[Randy Zwitch]

It would appear so...I swear that I tried that, but I guess I didn't try 
that permutation!

So what's it about the @eval macro that doesn't allow for regular string 
interpolation, that I have to use the string() function instead of an 
inline $?

On Monday, November 17, 2014 9:50:55 PM UTC-5, Jacob Quinn wrote:
>
> Can you just do
>
>
> funcname = (:get_help_configuration, :get_help_languages, 
> :get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
> endpoint = ("help/configuration.json", "help/languages.json", 
> "help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")
>
> for (func, endp) in Dict(funcname, endpoint)
> @eval begin function ($func)(; options=Dict{String, String}())
> 
> r = get_oauth(string("https://api.twitter.com/1.1/";, $endp), 
> options)
>
> return r.status == 200 ? JSON.parse(r.data) : r
>
> end
> end
> end
>
>
> ?
>
> On Mon, Nov 17, 2014 at 9:35 PM, Randy Zwitch  > wrote:
>
>> I've seen this type of function generation in other packages, and wanted 
>> to try it for myself. This file in Twitter.jl has 5 functions with the same 
>> overall structure:
>>
>> https://github.com/randyzwitch/Twitter.jl/blob/master/src/help.jl
>>
>>
>> Here's what I ended up doing, which works, but I've got no idea why I had 
>> to write the string interpolation the way I did. I went through many 
>> permutations here, so if someone could explain why the `:($(string("
>> https://api.twitter.com/1.1/";, $endp))` line needs to be written that 
>> way for string interpolation, it would be appreciated. And any improvements 
>> in general are welcome. 
>>
>>
>>
>> funcname = (:get_help_configuration, :get_help_languages, 
>> :get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
>> endpoint = ("help/configuration.json", "help/languages.json", 
>> "help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")
>>
>> for (func, endp) in Dict(funcname, endpoint)
>> @eval begin function ($func)(; options=Dict{String, String}())
>> 
>> r = get_oauth(:($(string("https://api.twitter.com/1.1/";, 
>> $endp))), options)
>>
>> return r.status == 200 ? JSON.parse(r.data) : r
>>
>> end
>> end
>> end
>>
>> Thanks!
>>
>
>

[julia-users] Metaprogramming: what's going on here/is there a better way?

[Randy Zwitch]

I've seen this type of function generation in other packages, and wanted to 
try it for myself. This file in Twitter.jl has 5 functions with the same 
overall structure:

https://github.com/randyzwitch/Twitter.jl/blob/master/src/help.jl


Here's what I ended up doing, which works, but I've got no idea why I had 
to write the string interpolation the way I did. I went through many 
permutations here, so if someone could explain why the 
`:($(string("https://api.twitter.com/1.1/";, 
$endp))` line needs to be written that way for string interpolation, it 
would be appreciated. And any improvements in general are welcome. 



funcname = (:get_help_configuration, :get_help_languages, 
:get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
endpoint = ("help/configuration.json", "help/languages.json", 
"help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")

for (func, endp) in Dict(funcname, endpoint)
@eval begin function ($func)(; options=Dict{String, String}())

r = get_oauth(:($(string("https://api.twitter.com/1.1/";, $endp))), 
options)

return r.status == 200 ? JSON.parse(r.data) : r

end
end
end

Thanks!

[julia-users] Re: Julia Tech Talk at the University of Pennsylvania

[Randy Zwitch]

Feels official now. Better get my presentation finished!

On Monday, November 10, 2014 9:25:23 PM UTC-5, Ted Fujimoto wrote:
>
> Hi all,
>
> Feel free to come by if you're around Philly!
>
> Julia Tech Talk on Thursday, November 13 at 6:00pm at Wu and Chen 
> Auditorium
> When: Thursday, November 13 
> <https://www.facebook.com/events/calendar/2014/November/13> at 6:00pm
> Where: Wu and Chen Auditorium 
> <https://www.facebook.com/pages/Wu-and-Chen-Auditorium/145368958832977> 
> Philadelphia, 
> Pennsylvania 19104
>
>  
>
> On Thursday, November 13th @ 6pm the Dining Philosophers will be hosting a 
> talk on the Julia Programming language in Wu & Chen Auditorium. Julia has 
> the elegance and familiarity of Python and Matlab, with speed close to C, 
> and is completely open source. This is a great opportunity for anyone 
> interested in scientific and parallel computation, machine learning, data 
> analysis, and visualization. There will be a giveaway of online JuliaBox 
> codes for the Julia language for all attendees!
>
> Speakers: Ted Fujimoto (CIT Masters student) and Randy Zwitch (Senior Data 
> Scientist at Comcast)
>
>  
>
> Randy Zwitch is Senior Data Scientist at Comcast, researching how to 
> improve the overall customer viewing experience using petabyte-scale tools 
> and datasets. Randy also contributes to the R and Julia open-source 
> communities, creating and maintaining packages primarily related to the web 
> (HTTP requests/APIs, Server Log Parsing, Geo-Location, etc.) and database 
> access. 
>
>
> Abstract: Using publicly available datasets, Randy will provide an intro 
> to machine learning using ad-hoc Julia code and via add-on packages.
>

[julia-users] Re: This week in Julia

[Randy Zwitch]

Done. You might want to label your future posts as "This week in Julia: 
October 17th" or similar, the tweet just went out labeled "October 10", 
which people might not understand the significance of.

On Monday, October 13, 2014 9:51:01 AM UTC-4, Matt Bauman wrote:
>
> That's perfect.  Thanks Randy!
>
> On Monday, October 13, 2014 9:15:07 AM UTC-4, Randy Zwitch wrote:
>>
>> Matt - 
>>
>> If you're ok with it, I can add this to juliabloggers.com and it will 
>> automatically get tweeted out to the community.
>>
>> Thanks,
>> Randy
>>
>> On Monday, October 13, 2014 9:02:25 AM UTC-4, Rick Graham wrote:
>>>
>>> Very cool!
>>>
>>> Any chance of emitting a Tweet and/or Google+ entry when there are new 
>>> items/updates?
>>>
>>> Thanks!
>>>
>>> On Friday, October 10, 2014 10:30:11 PM UTC-4, Matt Bauman wrote:
>>>>
>>>> This is an experiment.  I think it'd be really amazing to have weekly 
>>>> updates about what's going on in Julia master, particularly during this 
>>>> crazy 0.4-dev period.  So I figured I'd give it a shot.  Take a look:
>>>>
>>>> http://thisweekinjulia.github.io/julia/2014/10/10/October-10.html
>>>>
>>>> I first tried a post like this two weeks ago over on reddit and it was 
>>>> pretty well received.  But I think GitHub pages will make creating these 
>>>> posts much simpler.  No, this doesn't replace NEWS.md (that's where I 
>>>> glean 
>>>> a lot of this information from!), and I *really* don't expect folks who 
>>>> are 
>>>> implementing the features and changes to be updating this blog.  But I 
>>>> think it'd be great if other folks would help me keep it up-to-date.
>>>>
>>>> Pull requests and collaborators are very welcome!  
>>>> https://github.com/thisweekinjulia/thisweekinjulia.github.io
>>>>
>>>

[julia-users] Re: This week in Julia

[Randy Zwitch]

Matt - 

If you're ok with it, I can add this to juliabloggers.com and it will 
automatically get tweeted out to the community.

Thanks,
Randy

On Monday, October 13, 2014 9:02:25 AM UTC-4, Rick Graham wrote:
>
> Very cool!
>
> Any chance of emitting a Tweet and/or Google+ entry when there are new 
> items/updates?
>
> Thanks!
>
> On Friday, October 10, 2014 10:30:11 PM UTC-4, Matt Bauman wrote:
>>
>> This is an experiment.  I think it'd be really amazing to have weekly 
>> updates about what's going on in Julia master, particularly during this 
>> crazy 0.4-dev period.  So I figured I'd give it a shot.  Take a look:
>>
>> http://thisweekinjulia.github.io/julia/2014/10/10/October-10.html
>>
>> I first tried a post like this two weeks ago over on reddit and it was 
>> pretty well received.  But I think GitHub pages will make creating these 
>> posts much simpler.  No, this doesn't replace NEWS.md (that's where I glean 
>> a lot of this information from!), and I *really* don't expect folks who are 
>> implementing the features and changes to be updating this blog.  But I 
>> think it'd be great if other folks would help me keep it up-to-date.
>>
>> Pull requests and collaborators are very welcome!  
>> https://github.com/thisweekinjulia/thisweekinjulia.github.io
>>
>

[julia-users] ANN: LogParser.jl

[Randy Zwitch]

Just a heads-up that I pushed LogParser.jl to METADATA this weekend. This 
package is somewhat small at the moment, providing just a single function 
for parsing Apache Server logs and providing a DataFrame method to work 
with the data in a tabular format. While my regex is specifically tailored 
to the Apache Combined format 
, it will *probably* 
work if your server records in the Apache Commons format.

The use of this package can be for numerous things such as understanding 
how much bandwidth you use to detecting bots and even as a zero-cost web 
analytics system. I'm planning on making a blog post showing how 
LogParser.jl can be used with GeoIP.jl and UAParser.jl (both projects I've 
also worked on and/or created) to take the LogParser output and break it up 
further into location and user-agent components.

Finally, I've named it LogParser generically, as I'm open to adding other 
log types. I'm currently thinking about adding Hive logs, but if people 
have other formats that would be useful and can provide a sample file, I'll 
see about writing the regexes to parse them.

Hope someone finds this useful (besides me!).

[julia-users] Re: Current state of 3rd party APIs in Julia?

[Randy Zwitch]

Julia and Postgres works fine using the ODBC.jl package; I know there is 
also a Postgres-specific package in the works. I've used the AWS.jl package 
to download from S3, but haven't used it enough to say it "just works".

I'm not aware of Google package APIs.

On Sunday, September 21, 2014 4:25:15 PM UTC-4, Ed wrote:
>
> Please?
>
> On Friday, September 19, 2014 11:37:21 AM UTC-6, Ed wrote:
>>
>> Hello, I was wondering if anybody knows what's the current state of the 
>> connectors between Julia and postgres, Amazon S3, and Google Storage and 
>> Google BigQuery? Do they "just work", or are they buggy, or completely 
>> unusable/not built yet?
>>
>

Re: [julia-users] Re: How to allocate Ptr{Ptr{Ptr{Uint8}}} with ccall?

[Randy Zwitch]

Perfect, thank you, I see it now (David's code 'result' is 2). So I can 
loop over unsafe_load and add to an array if I chose.

Though, likely I won't. This library is starting to make me believe I could 
more quickly re-write these functions in Julia once I know what it is they 
do!

On Monday, September 15, 2014 3:14:52 PM UTC-4, Isaiah wrote:
>
> oauth_split_url_parameters returns the number of parameters it finds. This 
> is a fairly common C idiom: caller passes a double or triple pointer, and 
> the function returns "number of things" it allocated.
>
> On Mon, Sep 15, 2014 at 2:55 PM, Randy Zwitch  > wrote:
>
>> Ivar, your code returned an error:
>>
>> ERROR: type: ccall: in argument 2, expected Ptr{Ptr{Uint8}}, got 
>> Ptr{Array{Uint8,1}}
>>  in oauth_split_url_parameters at none:3
>>
>>
>> David, your code worked for me, but it seems that you need to know how 
>> many parameters are in the string. Is there a way to just return as an 
>> array?
>>
>>
>> On Monday, September 15, 2014 2:27:57 PM UTC-4, Randy Zwitch wrote:
>>>
>>> No problem, I'll test it out...that's what VM's are for :)
>>>
>>> On Monday, September 15, 2014 2:22:31 PM UTC-4, Ivar Nesje wrote:
>>>>
>>>> I should probably not post this untested code, but it is way too 
>>>> tempting when I need to install a library to actually test it.
>>>>
>>>> function oauth_split_url_parameters(url::String)
>>>> argv = Ptr{Array{Uint8,1}}[C_NULL]
>>>> argc = ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(
>>>> Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>>> result = Array(UTF8String, argc)
>>>> for i = 1:argc
>>>> result[i] = bytestring(argv[1][i])
>>>> end
>>>> ccall((:oath_free_array,LIBOAUTH), Nothing, (Ptr{Cint}, 
>>>> Ptr{Ptr{Ptr{Uint8}}}), &argc, argv)
>>>> return result
>>>> end
>>>>
>>>> kl. 17:37:15 UTC+2 mandag 15. september 2014 skrev Ivar Nesje følgende:
>>>>>
>>>>> That seems like a really tricky function to wrap. You need to do C 
>>>>> style memory handling in order for this to work, and C style memory 
>>>>> handling requires you to really look in the documentation (for the 
>>>>> function) to see how it works. Example code for how this function is used 
>>>>> correctly from C is almost mandatory.
>>>>>
>>>>> I found this example 
>>>>> <http://liboauth.sourceforge.net/tests_2oauthexample_8c-example.html>, 
>>>>> apparently from the OAuth site, where they demonstrate how to do a poor 
>>>>> job 
>>>>> and leak memory. DON'T USE IT!!!
>>>>>
>>>>> I'll try to write a correct implemementation that uses 
>>>>> oauth_free_array 
>>>>> <http://liboauth.sourceforge.net/oauth_8h.html#ada81dd39be59cadbc1bd77df78ffef52>(int*
>>>>>  
>>>>> c, char**arg) to clean up. 
>>>>>
>>>>> Ivar
>>>>>
>>>>>
>>>>> kl. 16:47:44 UTC+2 mandag 15. september 2014 skrev Randy Zwitch 
>>>>> følgende:
>>>>>>
>>>>>> Continuing on my attempt to learn Julia ccall by wrapping 
>>>>>> liboauth...I have the following code that was mostly generated by 
>>>>>> Clang.jl:
>>>>>>
>>>>>>
>>>>>> https://github.com/randyzwitch/OAuth.jl/blob/
>>>>>> master/src/OAuth.jl#L248-254
>>>>>>
>>>>>>
>>>>>> function oauth_split_url_parameters(url::String,argv::Ptr{Ptr{Ptr{
>>>>>> Uint8}}})
>>>>>> result = ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(
>>>>>> Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>>>>> if result == C_NULL
>>>>>> error("oauth_split_url_parameters failed")
>>>>>> end
>>>>>> return result
>>>>>> end
>>>>>>
>>>>>> I'm pretty sure I want to re-write this code to remove the second 
>>>>>> argument, since the second argument is just allocating space for an 
>>>>>> array. 
>>>>>> I don't want to return the Cint for success/fail, but rather the array 
>>>>>> that 
>>>>>> splits the 'url' argument.
>>>>>>
>>>>>> function oauth_split_url_parameters(url::String)
>>>>>> argv = *Ptr{Ptr{Ptr{Uint8}}}* #What Julia code actually goes 
>>>>>> here to make this work?
>>>>>> result = ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(
>>>>>> Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>>>>> if result == C_NULL
>>>>>> error("oauth_split_url_parameters failed")
>>>>>> end
>>>>>> return argv
>>>>>> end
>>>>>>
>>>>>> I've tried allocating an array() in place of Ptr{Ptr{Ptr{Uint8}}} , 
>>>>>> but that doesn't work. I think this is an array of pointers to string 
>>>>>> variables? How can I make this work?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>>
>

[julia-users] Re: How to allocate Ptr{Ptr{Ptr{Uint8}}} with ccall?

[Randy Zwitch]

Ivar, your code returned an error:

ERROR: type: ccall: in argument 2, expected Ptr{Ptr{Uint8}}, got 
Ptr{Array{Uint8,1}}
 in oauth_split_url_parameters at none:3


David, your code worked for me, but it seems that you need to know how many 
parameters are in the string. Is there a way to just return as an array?


On Monday, September 15, 2014 2:27:57 PM UTC-4, Randy Zwitch wrote:
>
> No problem, I'll test it out...that's what VM's are for :)
>
> On Monday, September 15, 2014 2:22:31 PM UTC-4, Ivar Nesje wrote:
>>
>> I should probably not post this untested code, but it is way too tempting 
>> when I need to install a library to actually test it.
>>
>> function oauth_split_url_parameters(url::String)
>> argv = Ptr{Array{Uint8,1}}[C_NULL]
>> argc = 
>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>> result = Array(UTF8String, argc)
>> for i = 1:argc
>> result[i] = bytestring(argv[1][i])
>> end
>> ccall((:oath_free_array,LIBOAUTH), Nothing, (Ptr{Cint}, 
>> Ptr{Ptr{Ptr{Uint8}}}), &argc, argv)
>> return result
>> end
>>
>> kl. 17:37:15 UTC+2 mandag 15. september 2014 skrev Ivar Nesje følgende:
>>>
>>> That seems like a really tricky function to wrap. You need to do C style 
>>> memory handling in order for this to work, and C style memory handling 
>>> requires you to really look in the documentation (for the function) to see 
>>> how it works. Example code for how this function is used correctly from C 
>>> is almost mandatory.
>>>
>>> I found this example 
>>> <http://liboauth.sourceforge.net/tests_2oauthexample_8c-example.html>, 
>>> apparently from the OAuth site, where they demonstrate how to do a poor job 
>>> and leak memory. DON'T USE IT!!!
>>>
>>> I'll try to write a correct implemementation that uses oauth_free_array 
>>> <http://liboauth.sourceforge.net/oauth_8h.html#ada81dd39be59cadbc1bd77df78ffef52>(int*
>>>  
>>> c, char**arg) to clean up. 
>>>
>>> Ivar
>>>
>>>
>>> kl. 16:47:44 UTC+2 mandag 15. september 2014 skrev Randy Zwitch følgende:
>>>>
>>>> Continuing on my attempt to learn Julia ccall by wrapping liboauth...I 
>>>> have the following code that was mostly generated by Clang.jl:
>>>>
>>>>
>>>>
>>>> https://github.com/randyzwitch/OAuth.jl/blob/master/src/OAuth.jl#L248-254
>>>>
>>>>
>>>> function 
>>>> oauth_split_url_parameters(url::String,argv::Ptr{Ptr{Ptr{Uint8}}})
>>>> result = 
>>>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>>> if result == C_NULL
>>>> error("oauth_split_url_parameters failed")
>>>> end
>>>> return result
>>>> end
>>>>
>>>> I'm pretty sure I want to re-write this code to remove the second 
>>>> argument, since the second argument is just allocating space for an array. 
>>>> I don't want to return the Cint for success/fail, but rather the array 
>>>> that 
>>>> splits the 'url' argument.
>>>>
>>>> function oauth_split_url_parameters(url::String)
>>>> argv = *Ptr{Ptr{Ptr{Uint8}}}* #What Julia code actually goes here 
>>>> to make this work?
>>>> result = 
>>>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>>> if result == C_NULL
>>>> error("oauth_split_url_parameters failed")
>>>> end
>>>> return argv
>>>> end
>>>>
>>>> I've tried allocating an array() in place of Ptr{Ptr{Ptr{Uint8}}} , but 
>>>> that doesn't work. I think this is an array of pointers to string 
>>>> variables? How can I make this work?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>

[julia-users] Re: How to allocate Ptr{Ptr{Ptr{Uint8}}} with ccall?

[Randy Zwitch]

No problem, I'll test it out...that's what VM's are for :)

On Monday, September 15, 2014 2:22:31 PM UTC-4, Ivar Nesje wrote:
>
> I should probably not post this untested code, but it is way too tempting 
> when I need to install a library to actually test it.
>
> function oauth_split_url_parameters(url::String)
> argv = Ptr{Array{Uint8,1}}[C_NULL]
> argc = 
> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
> result = Array(UTF8String, argc)
> for i = 1:argc
> result[i] = bytestring(argv[1][i])
> end
> ccall((:oath_free_array,LIBOAUTH), Nothing, (Ptr{Cint}, 
> Ptr{Ptr{Ptr{Uint8}}}), &argc, argv)
> return result
> end
>
> kl. 17:37:15 UTC+2 mandag 15. september 2014 skrev Ivar Nesje følgende:
>>
>> That seems like a really tricky function to wrap. You need to do C style 
>> memory handling in order for this to work, and C style memory handling 
>> requires you to really look in the documentation (for the function) to see 
>> how it works. Example code for how this function is used correctly from C 
>> is almost mandatory.
>>
>> I found this example 
>> <http://liboauth.sourceforge.net/tests_2oauthexample_8c-example.html>, 
>> apparently from the OAuth site, where they demonstrate how to do a poor job 
>> and leak memory. DON'T USE IT!!!
>>
>> I'll try to write a correct implemementation that uses oauth_free_array 
>> <http://liboauth.sourceforge.net/oauth_8h.html#ada81dd39be59cadbc1bd77df78ffef52>(int*
>>  
>> c, char**arg) to clean up. 
>>
>> Ivar
>>
>>
>> kl. 16:47:44 UTC+2 mandag 15. september 2014 skrev Randy Zwitch følgende:
>>>
>>> Continuing on my attempt to learn Julia ccall by wrapping liboauth...I 
>>> have the following code that was mostly generated by Clang.jl:
>>>
>>>
>>> https://github.com/randyzwitch/OAuth.jl/blob/master/src/OAuth.jl#L248-254
>>>
>>>
>>> function 
>>> oauth_split_url_parameters(url::String,argv::Ptr{Ptr{Ptr{Uint8}}})
>>> result = 
>>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>> if result == C_NULL
>>> error("oauth_split_url_parameters failed")
>>> end
>>> return result
>>> end
>>>
>>> I'm pretty sure I want to re-write this code to remove the second 
>>> argument, since the second argument is just allocating space for an array. 
>>> I don't want to return the Cint for success/fail, but rather the array that 
>>> splits the 'url' argument.
>>>
>>> function oauth_split_url_parameters(url::String)
>>> argv = *Ptr{Ptr{Ptr{Uint8}}}* #What Julia code actually goes here 
>>> to make this work?
>>> result = 
>>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>>> if result == C_NULL
>>> error("oauth_split_url_parameters failed")
>>> end
>>> return argv
>>> end
>>>
>>> I've tried allocating an array() in place of Ptr{Ptr{Ptr{Uint8}}} , but 
>>> that doesn't work. I think this is an array of pointers to string 
>>> variables? How can I make this work?
>>>
>>> Thanks.
>>>
>>>
>>>

[julia-users] Re: How to allocate Ptr{Ptr{Ptr{Uint8}}} with ccall?

[Randy Zwitch]

Thanks Ivar. When I get further along, I'd love for you to take a look at 
what I did. Right now, I'm blindly wrapping the functions as practice, but 
if you look in my code/tests, I can tell there are functions there that are 
either duplicative or don't make sense. And if my naive wrapping is leaking 
memory because the original function is leaking memory, I'd love to get 
that taken care of before adding to METADATA :)

On Monday, September 15, 2014 11:37:15 AM UTC-4, Ivar Nesje wrote:
>
> That seems like a really tricky function to wrap. You need to do C style 
> memory handling in order for this to work, and C style memory handling 
> requires you to really look in the documentation (for the function) to see 
> how it works. Example code for how this function is used correctly from C 
> is almost mandatory.
>
> I found this example 
> <http://liboauth.sourceforge.net/tests_2oauthexample_8c-example.html>, 
> apparently from the OAuth site, where they demonstrate how to do a poor job 
> and leak memory. DON'T USE IT!!!
>
> I'll try to write a correct implemementation that uses oauth_free_array 
> <http://liboauth.sourceforge.net/oauth_8h.html#ada81dd39be59cadbc1bd77df78ffef52>(int*
>  
> c, char**arg) to clean up. 
>
> Ivar
>
>
> kl. 16:47:44 UTC+2 mandag 15. september 2014 skrev Randy Zwitch følgende:
>>
>> Continuing on my attempt to learn Julia ccall by wrapping liboauth...I 
>> have the following code that was mostly generated by Clang.jl:
>>
>>
>> https://github.com/randyzwitch/OAuth.jl/blob/master/src/OAuth.jl#L248-254
>>
>>
>> function 
>> oauth_split_url_parameters(url::String,argv::Ptr{Ptr{Ptr{Uint8}}})
>> result = 
>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>> if result == C_NULL
>> error("oauth_split_url_parameters failed")
>> end
>> return result
>> end
>>
>> I'm pretty sure I want to re-write this code to remove the second 
>> argument, since the second argument is just allocating space for an array. 
>> I don't want to return the Cint for success/fail, but rather the array that 
>> splits the 'url' argument.
>>
>> function oauth_split_url_parameters(url::String)
>> argv = *Ptr{Ptr{Ptr{Uint8}}}* #What Julia code actually goes here to 
>> make this work?
>> result = 
>> ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
>> if result == C_NULL
>> error("oauth_split_url_parameters failed")
>> end
>> return argv
>> end
>>
>> I've tried allocating an array() in place of Ptr{Ptr{Ptr{Uint8}}} , but 
>> that doesn't work. I think this is an array of pointers to string 
>> variables? How can I make this work?
>>
>> Thanks.
>>
>>
>>

[julia-users] How to allocate Ptr{Ptr{Ptr{Uint8}}} with ccall?

[Randy Zwitch]

Continuing on my attempt to learn Julia ccall by wrapping liboauth...I have 
the following code that was mostly generated by Clang.jl:


https://github.com/randyzwitch/OAuth.jl/blob/master/src/OAuth.jl#L248-254


function oauth_split_url_parameters(url::String,argv::Ptr{Ptr{Ptr{Uint8}}})
result = 
ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
if result == C_NULL
error("oauth_split_url_parameters failed")
end
return result
end

I'm pretty sure I want to re-write this code to remove the second argument, 
since the second argument is just allocating space for an array. I don't 
want to return the Cint for success/fail, but rather the array that splits 
the 'url' argument.

function oauth_split_url_parameters(url::String)
argv = *Ptr{Ptr{Ptr{Uint8}}}* #What Julia code actually goes here to 
make this work?
result = 
ccall((:oauth_split_url_parameters,LIBOAUTH),Cint,(Ptr{Uint8},Ptr{Ptr{Ptr{Uint8}}}),url,argv)
if result == C_NULL
error("oauth_split_url_parameters failed")
end
return argv
end

I've tried allocating an array() in place of Ptr{Ptr{Ptr{Uint8}}} , but 
that doesn't work. I think this is an array of pointers to string 
variables? How can I make this work?

Thanks.

Re: [julia-users] Re: [ANN] Yelp.jl package

[Randy Zwitch]

Ah, I missed that. You're certainly more elegant than I am in Julia. :)

On Wednesday, September 10, 2014 3:13:32 PM UTC-4, Jacob Quinn wrote:
>
> It does. See here 
> <https://github.com/quinnj/Yelp.jl/blob/67390bef28c3060917ceb33998b8ff7ae7029932/src/Yelp.jl#L23>
> .
> ​
>
> On Wed, Sep 10, 2014 at 2:35 PM, Randy Zwitch  > wrote:
>
>> Nice. Does Yelp not require sorting the parameters in alphabetical order 
>> like Twitter?
>>
>>
>> On Wednesday, September 10, 2014 1:57:43 PM UTC-4, Jacob Quinn wrote:
>>>
>>> Hey everyone,
>>>
>>> If anyone else needs access to the Yelp API, I put together a small 
>>> package that interfaces. It supports both the search and business version 
>>> 2.0 APIs. Feel free to check it out.
>>>
>>> A thanks to Randy Zwitch and his Twitter.jl package for the quick and 
>>> dirty OAuth code to get this up and running.
>>>
>>> https://github.com/quinnj/Yelp.jl
>>>
>>> -Jacob
>>>
>>
>

[julia-users] Re: [ANN] Yelp.jl package

[Randy Zwitch]

Nice. Does Yelp not require sorting the parameters in alphabetical order 
like Twitter?

On Wednesday, September 10, 2014 1:57:43 PM UTC-4, Jacob Quinn wrote:
>
> Hey everyone,
>
> If anyone else needs access to the Yelp API, I put together a small 
> package that interfaces. It supports both the search and business version 
> 2.0 APIs. Feel free to check it out.
>
> A thanks to Randy Zwitch and his Twitter.jl package for the quick and 
> dirty OAuth code to get this up and running.
>
> https://github.com/quinnj/Yelp.jl
>
> -Jacob
>

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Jacob and I are now collaborating on wrapping the liboauth library, if 
anyone else is interested:

https://github.com/randyzwitch/OAuth.jl

On Tuesday, September 9, 2014 8:41:49 AM UTC-4, Randy Zwitch wrote:
>
> Yes I do want to collaborate Jacob, because I probably need some of the 
> functionality too! I'll put it up when I get home tonight and add you to 
> the repo.
>
> On Tuesday, September 9, 2014 8:32:41 AM UTC-4, Jacob Quinn wrote:
>>
>> Hey Randy,
>>
>> Any update on the liboath wrapping? I'd be willing to help if you've 
>> started as I need the functionality. Want to throw up what you have in a 
>> repo and collaborate?
>>
>> -Jacob
>>
>>
>> On Monday, September 1, 2014 6:10:49 PM UTC-4, Randy Zwitch wrote:
>>>
>>> Kevin, adding const in front gave me this error:
>>>
>>> type: ccall: expected Symbol, got Ptr{None} 
>>>
>>> while loading In[3], in expression starting on line 3
>>>
>>> Luckily João, your code finally worked for me! So if I understand this 
>>> correctly, the problem was that we were originally passing a Ptr to ccall, 
>>> when all I should've been doing is passing a string declared as a constant?
>>>
>>>  
>>>
>>> On Monday, September 1, 2014 4:46:07 PM UTC-4, João Felipe Santos wrote:
>>>>
>>>> I'm sorry, there was a mistake in my example. The dlopen step should be 
>>>> used just to check whether the file is accessible as a shared library. 
>>>> ccall expects the full path to the .dylib file in case the library is not 
>>>> at a "standard" location.
>>>>
>>>> Do something like this instead:
>>>> 
>>>> const liboauth = "/path/to/liboauth"
>>>> (dlopen_e(liboauth) == C_NULL) && error("Unable to load shared 
>>>> library at the given path.")
>>>> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, 
>>>> (Ptr{Uint8}, Ptr{Uint8}), testurl, testkey)
>>>> println(bytestring(b64d))
>>>>
>>>> Note that you have to use bytestring and not string. string will create 
>>>> a string from printing the pointer (which will show something like 
>>>> Ptr{Uint8} @0x012345). bytestring converts a C string from a pointer 
>>>> to 
>>>> an ASCIIString, which is what you want.
>>>>
>>>> --
>>>> João Felipe Santos
>>>>
>>>>
>>>> On Mon, Sep 1, 2014 at 4:24 PM, Randy Zwitch  
>>>> wrote:
>>>>
>>>>> Thanks for the suggestions everyone. Unfortunately, neither the code 
>>>>> from Ivar nor João worked for me.
>>>>>
>>>>>  liboauth = dlopen("/usr/local/lib/liboauth.dylib")
>>>>>
>>>>>  Out[8]:
>>>>>
>>>>> Ptr{Void} @0x7fdc665c5ca0
>>>>>
>>>>>  In [9]:
>>>>>
>>>>  
>>
>>>  function oauth_sign_hmac_sha1(m::String,k::String)
>>>>>
>>>>> res = 
>>>>> ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
>>>>>
>>>>> if res == C_NULL
>>>>>
>>>>> error("oauth_sign_hmac_sha1 failed")
>>>>>
>>>>> end
>>>>>
>>>>> return string(res)
>>>>>
>>>>> end
>>>>>
>>>>>  
>>>>>
>>>>> testurl = 
>>>>> "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
>>>>>
>>>>> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
>>>>>
>>>>> oauth_sign_hmac_sha1(testurl, testkey)   
>>>>>
>>>>>   type: oauth_sign_hmac_sha1: in ccall: first argument not a pointer or 
>>>>> valid constant expression, expected DataType, got Type{(Any...,)}
>>>>> while loading In[9], in expression starting on line 11
>>>>>
>>>>>  in oauth_sign_hmac_sha1 at In[9]:2
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  testurl = 
>>>>> "GET&

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Yes I do want to collaborate Jacob, because I probably need some of the 
functionality too! I'll put it up when I get home tonight and add you to 
the repo.

On Tuesday, September 9, 2014 8:32:41 AM UTC-4, Jacob Quinn wrote:
>
> Hey Randy,
>
> Any update on the liboath wrapping? I'd be willing to help if you've 
> started as I need the functionality. Want to throw up what you have in a 
> repo and collaborate?
>
> -Jacob
>
>
> On Monday, September 1, 2014 6:10:49 PM UTC-4, Randy Zwitch wrote:
>>
>> Kevin, adding const in front gave me this error:
>>
>> type: ccall: expected Symbol, got Ptr{None} 
>>
>> while loading In[3], in expression starting on line 3
>>
>> Luckily João, your code finally worked for me! So if I understand this 
>> correctly, the problem was that we were originally passing a Ptr to ccall, 
>> when all I should've been doing is passing a string declared as a constant?
>>
>>  
>>
>> On Monday, September 1, 2014 4:46:07 PM UTC-4, João Felipe Santos wrote:
>>>
>>> I'm sorry, there was a mistake in my example. The dlopen step should be 
>>> used just to check whether the file is accessible as a shared library. 
>>> ccall expects the full path to the .dylib file in case the library is not 
>>> at a "standard" location.
>>>
>>> Do something like this instead:
>>> 
>>> const liboauth = "/path/to/liboauth"
>>> (dlopen_e(liboauth) == C_NULL) && error("Unable to load shared 
>>> library at the given path.")
>>> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, 
>>> (Ptr{Uint8}, Ptr{Uint8}), testurl, testkey)
>>> println(bytestring(b64d))
>>>
>>> Note that you have to use bytestring and not string. string will create 
>>> a string from printing the pointer (which will show something like 
>>> Ptr{Uint8} @0x012345). bytestring converts a C string from a pointer to 
>>> an ASCIIString, which is what you want.
>>>
>>> --
>>> João Felipe Santos
>>>
>>>
>>> On Mon, Sep 1, 2014 at 4:24 PM, Randy Zwitch  
>>> wrote:
>>>
>>>> Thanks for the suggestions everyone. Unfortunately, neither the code 
>>>> from Ivar nor João worked for me.
>>>>
>>>>  liboauth = dlopen("/usr/local/lib/liboauth.dylib")
>>>>
>>>>  Out[8]:
>>>>
>>>> Ptr{Void} @0x7fdc665c5ca0
>>>>
>>>>  In [9]:
>>>>
>>>  
>
>>  function oauth_sign_hmac_sha1(m::String,k::String)
>>>>
>>>> res = 
>>>> ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
>>>>
>>>> if res == C_NULL
>>>>
>>>> error("oauth_sign_hmac_sha1 failed")
>>>>
>>>> end
>>>>
>>>> return string(res)
>>>>
>>>> end
>>>>
>>>>  
>>>>
>>>> testurl = 
>>>> "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
>>>>
>>>> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
>>>>
>>>> oauth_sign_hmac_sha1(testurl, testkey)   
>>>>
>>>>   type: oauth_sign_hmac_sha1: in ccall: first argument not a pointer or 
>>>> valid constant expression, expected DataType, got Type{(Any...,)}
>>>> while loading In[9], in expression starting on line 11
>>>>
>>>>  in oauth_sign_hmac_sha1 at In[9]:2
>>>>
>>>>
>>>>
>>>>
>>>>  testurl = 
>>>> "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
>>>>
>>>> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
>>>>
>>>> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, (Ptr{Uint8}, 
>>>> Ptr{Uint8}), testurl, testkey)
>>>>
>>>> bytestring(b64d)
>>>>
>>>>   type: anonymous: in ccall: fir

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Kevin, adding const in front gave me this error:

type: ccall: expected Symbol, got Ptr{None} 

while loading In[3], in expression starting on line 3

Luckily João, your code finally worked for me! So if I understand this 
correctly, the problem was that we were originally passing a Ptr to ccall, 
when all I should've been doing is passing a string declared as a constant?

 

On Monday, September 1, 2014 4:46:07 PM UTC-4, João Felipe Santos wrote:
>
> I'm sorry, there was a mistake in my example. The dlopen step should be 
> used just to check whether the file is accessible as a shared library. 
> ccall expects the full path to the .dylib file in case the library is not 
> at a "standard" location.
>
> Do something like this instead:
> 
> const liboauth = "/path/to/liboauth"
> (dlopen_e(liboauth) == C_NULL) && error("Unable to load shared library 
> at the given path.")
> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, 
> (Ptr{Uint8}, Ptr{Uint8}), testurl, testkey)
> println(bytestring(b64d))
>
> Note that you have to use bytestring and not string. string will create a 
> string from printing the pointer (which will show something like Ptr{Uint8} 
> @0x012345). bytestring converts a C string from a pointer to an 
> ASCIIString, which is what you want.
>
> --
> João Felipe Santos
>
>
> On Mon, Sep 1, 2014 at 4:24 PM, Randy Zwitch  > wrote:
>
>> Thanks for the suggestions everyone. Unfortunately, neither the code from 
>> Ivar nor João worked for me.
>>
>>  liboauth = dlopen("/usr/local/lib/liboauth.dylib")
>>
>>  Out[8]:
>>
>> Ptr{Void} @0x7fdc665c5ca0
>>
>>  In [9]:
>>  
>> function oauth_sign_hmac_sha1(m::String,k::String)
>>
>> res = 
>> ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
>>
>> if res == C_NULL
>>
>> error("oauth_sign_hmac_sha1 failed")
>>
>> end
>>
>> return string(res)
>>
>> end
>>
>>  
>>
>> testurl = 
>> "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
>>
>> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
>>
>> oauth_sign_hmac_sha1(testurl, testkey)   
>>
>>   type: oauth_sign_hmac_sha1: in ccall: first argument not a pointer or 
>> valid constant expression, expected DataType, got Type{(Any...,)}
>> while loading In[9], in expression starting on line 11
>>
>>  in oauth_sign_hmac_sha1 at In[9]:2
>>
>>
>>
>>
>>  testurl = 
>> "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
>>
>> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
>>
>> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, (Ptr{Uint8}, 
>> Ptr{Uint8}), testurl, testkey)
>>
>> bytestring(b64d)
>>
>>   type: anonymous: in ccall: first argument not a pointer or valid constant 
>> expression, expected DataType, got Type{(Any...,)}
>> while loading In[10], in expression starting on line 3
>>
>>  in anonymous at no file
>>
>>
>> Does this mean I compiled the library wrong? When I did the 'make' step, 
>> after it was complete, I did 'make installcheck' and the 3 tests reported 
>> that they completed successfully.
>>
>> At a higher level, I like Isaiah's suggestion of doing this process by 
>> hand to really get to understanding what is going on. Is there an eaier 
>> external library that one of you could suggest that I could use to walk 
>> through the entire process? I've done the examples in the manual using 
>> :clock and :getenv and understand what is going on, so now I want to work 
>> with a user-installed library to make sure I really get the process. I 
>> started with OAuth to see if I could make something usable to work with my 
>> Twitter package, but maybe it's not the best starting place.
>>
>>
>> On Monday, September 1, 2014 10:47:22 AM UTC-4, João Felipe Santos wrote:
>>
>>> You need to do ccalls using Ptr{Uint8}. What you can do actually is wrap 
>>&

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Thanks for the suggestions everyone. Unfortunately, neither the code from 
Ivar nor João worked for me.

liboauth = dlopen("/usr/local/lib/liboauth.dylib")

Out[8]:

Ptr{Void} @0x7fdc665c5ca0

In [9]:

function oauth_sign_hmac_sha1(m::String,k::String)

res = 
ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)

if res == C_NULL

error("oauth_sign_hmac_sha1 failed")

end

return string(res)

end

 

testurl = 
"GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"

testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"

oauth_sign_hmac_sha1(testurl, testkey)   

type: oauth_sign_hmac_sha1: in ccall: first argument not a pointer or valid 
constant expression, expected DataType, got Type{(Any...,)}
while loading In[9], in expression starting on line 11

 in oauth_sign_hmac_sha1 at In[9]:2




testurl = 
"GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"

testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"

b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, (Ptr{Uint8}, 
Ptr{Uint8}), testurl, testkey)

bytestring(b64d)

type: anonymous: in ccall: first argument not a pointer or valid constant 
expression, expected DataType, got Type{(Any...,)}
while loading In[10], in expression starting on line 3

 in anonymous at no file


Does this mean I compiled the library wrong? When I did the 'make' step, 
after it was complete, I did 'make installcheck' and the 3 tests reported 
that they completed successfully.

At a higher level, I like Isaiah's suggestion of doing this process by hand 
to really get to understanding what is going on. Is there an eaier external 
library that one of you could suggest that I could use to walk through the 
entire process? I've done the examples in the manual using :clock and 
:getenv and understand what is going on, so now I want to work with a 
user-installed library to make sure I really get the process. I started 
with OAuth to see if I could make something usable to work with my Twitter 
package, but maybe it's not the best starting place.


On Monday, September 1, 2014 10:47:22 AM UTC-4, João Felipe Santos wrote:
>
> You need to do ccalls using Ptr{Uint8}. What you can do actually is wrap 
> the Clang.jl-generated functions with your own functions with an 
> alternative signature, and then convert from ASCIIString to Ptr{Uint8}. 
> Note that you probably will need to do it anyways to wrap the return types, 
> since you probably do not want to work with pointers from Julia :)
>
> In that specific example, if m and k are ASCIIStrings, conversions will be 
> done automatically:
>
> testurl = "GET&http%3A%2F%2Fphotos.example.net
> %2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal"
> testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00"
> b64d = ccall((:oauth_sign_hmac_sha1, liboauth), Ptr{Uint8}, 
> (Ptr{Uint8}, Ptr{Uint8}), testurl, testkey)
>
> Note that b64d here will be a Ptr{Uint8}, which you can convert to a Julia 
> string by using bytestring(b64d).
>
> --
> João Felipe Santos
>
>
> On Mon, Sep 1, 2014 at 9:55 AM, Randy Zwitch  > wrote:
>
>> To make it a bit more concrete, the C library has this test function:
>>
>>   testurl = "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3D"
>>   "vacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce"
>>   "%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26o"
>>   "auth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk"
>>   "%26oauth_version%3D1.0%26size%3Doriginal";
>>   testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00";
>>   b64d = oauth_sign_hmac_sha1(testurl , testkey);
>>
>> In Julia, I have this generated from Clang.jl:
>>
>> liboauth = dlopen("/usr/local/lib/liboauth.dylib")
>>
>> function oauth_sign_hmac_sha1(m::Ptr{Uint8},k::Ptr{Uint8})
>> 
>> ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
>> end
>>
>> What modifications do I need to make

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

To make it a bit more concrete, the C library has this test function:

  testurl = "GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3D"
  "vacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce"
  "%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26o"
  "auth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk"
  "%26oauth_version%3D1.0%26size%3Doriginal";
  testkey = "kd94hf93k423kf44&pfkkdhi9sl3r4s00";
  b64d = oauth_sign_hmac_sha1(testurl , testkey);

In Julia, I have this generated from Clang.jl:

liboauth = dlopen("/usr/local/lib/liboauth.dylib")

function oauth_sign_hmac_sha1(m::Ptr{Uint8},k::Ptr{Uint8})

ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
end

What modifications do I need to make to the Clang Julia code to run this 
test?



On Monday, September 1, 2014 8:54:59 AM UTC-4, Randy Zwitch wrote:
>
> Thanks for the detailed response João! As it turns out, I didn't have any 
> .dylib files as part of the downloaded code, but I was able to figure out 
> how to compile the code and I believe I've got the library installed 
> locally now.
>
> When you reference that most of my Ptr{Uint8} values are really just 
> looking for string inputs, can I modify the Julia function signature to 
> take ::ASCIIString instead? Or is this something where I have the leave the 
> type signatures as they are, but understand what the function is actually 
> looking for from the documentation?
>
> On Sunday, August 31, 2014 9:19:21 PM UTC-4, João Felipe Santos wrote:
>>
>> Hello Randy,
>>
>> the following comes from my experience with ccall and Julia 
>> documentation. Please anyone correct me if I explained any of the internals 
>> wrong!
>>
>> The API seems to be really simple so pretty much everything can be done 
>> with standard Julia types. Clang.jl seems to have generated correct code 
>> for it.
>>
>> Regarding 2, liboauth.dylib (or .dll, or .so on Linux) has to be loaded 
>> and passed to ccall. You can load it by hand using dlopen, like this:
>> 
>> liboauth = dlopen("/path/of/liboauth.dylib")
>>
>> This will raise an error if the path is not valid. If the library is in 
>> your environment's standard path, you can pass its name to ccall as a 
>> string instead of creating a pointer with dlopen.
>>
>> Most of the Ptr{Uint8} you got in the code generated by Clang.jl are 
>> actually mapping char *, which are C strings (ASCII, not Unicode). For 
>> example, let's say you wanted to call puts from libc, which is a function 
>> that gets a string as its argument, prints it to the screen followed by a 
>> newline, and returns the number of printed characters. You could do it like 
>> this:
>>
>> ccall((:puts, "libc"), Cint, (Ptr{Uint8},), "Hello, Randy")
>>
>> So, you basically can pass your string as the function argument and it 
>> should work. You don't need to pass a pointer, but it's good to know that 
>> your Julia ASCIIString was converted to Ptr{Uint8} internally.
>>
>> With this you should be able to call functions, but you still need to be 
>> able to recover their output. The second argument to ccall is the C 
>> function return type, but note that often C functions do not return their 
>> output in the return type, but in a variable which was passed by reference 
>> as one of its arguments. I don't know enough of liboauth to know what's the 
>> case, so you will need to check the documentation. See the sections 
>> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#accessing-data-through-a-pointer
>>  
>> and 
>> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#passing-pointers-for-modifying-inputs
>>  
>> for more details on that.
>>
>> --
>> João Felipe Santos
>>
>>
>> On Sun, Aug 31, 2014 at 8:17 PM, Randy Zwitch  
>> wrote:
>>
>>> Hi all - 
>>>
>>> I've been trying to learn more about C and how Julia interacts and 
>>> decided to play around with Clang.jl. I decided I was going to wrap 
>>> liboauth from here:
>>>
>>> http://liboauth.sourceforge.net/oauth_8h_source.html
>>>
>>> I downloaded the C source, which resided in my OSX Downloads directory. 
>>> Using the following Julia code generated a bunch of output:
>>>
>>>   [1]:
>>>  
>>> using Clang.wrap_c
>>>
>>>  In [2]:
>>>   
>>> con

Re: [julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Thanks for the detailed response João! As it turns out, I didn't have any 
.dylib files as part of the downloaded code, but I was able to figure out 
how to compile the code and I believe I've got the library installed 
locally now.

When you reference that most of my Ptr{Uint8} values are really just 
looking for string inputs, can I modify the Julia function signature to 
take ::ASCIIString instead? Or is this something where I have the leave the 
type signatures as they are, but understand what the function is actually 
looking for from the documentation?

On Sunday, August 31, 2014 9:19:21 PM UTC-4, João Felipe Santos wrote:
>
> Hello Randy,
>
> the following comes from my experience with ccall and Julia documentation. 
> Please anyone correct me if I explained any of the internals wrong!
>
> The API seems to be really simple so pretty much everything can be done 
> with standard Julia types. Clang.jl seems to have generated correct code 
> for it.
>
> Regarding 2, liboauth.dylib (or .dll, or .so on Linux) has to be loaded 
> and passed to ccall. You can load it by hand using dlopen, like this:
> 
> liboauth = dlopen("/path/of/liboauth.dylib")
>
> This will raise an error if the path is not valid. If the library is in 
> your environment's standard path, you can pass its name to ccall as a 
> string instead of creating a pointer with dlopen.
>
> Most of the Ptr{Uint8} you got in the code generated by Clang.jl are 
> actually mapping char *, which are C strings (ASCII, not Unicode). For 
> example, let's say you wanted to call puts from libc, which is a function 
> that gets a string as its argument, prints it to the screen followed by a 
> newline, and returns the number of printed characters. You could do it like 
> this:
>
> ccall((:puts, "libc"), Cint, (Ptr{Uint8},), "Hello, Randy")
>
> So, you basically can pass your string as the function argument and it 
> should work. You don't need to pass a pointer, but it's good to know that 
> your Julia ASCIIString was converted to Ptr{Uint8} internally.
>
> With this you should be able to call functions, but you still need to be 
> able to recover their output. The second argument to ccall is the C 
> function return type, but note that often C functions do not return their 
> output in the return type, but in a variable which was passed by reference 
> as one of its arguments. I don't know enough of liboauth to know what's the 
> case, so you will need to check the documentation. See the sections 
> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#accessing-data-through-a-pointer
>  
> and 
> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#passing-pointers-for-modifying-inputs
>  
> for more details on that.
>
> --
> João Felipe Santos
>
>
> On Sun, Aug 31, 2014 at 8:17 PM, Randy Zwitch  > wrote:
>
>> Hi all - 
>>
>> I've been trying to learn more about C and how Julia interacts and 
>> decided to play around with Clang.jl. I decided I was going to wrap 
>> liboauth from here:
>>
>> http://liboauth.sourceforge.net/oauth_8h_source.html
>>
>> I downloaded the C source, which resided in my OSX Downloads directory. 
>> Using the following Julia code generated a bunch of output:
>>
>>   [1]:
>>  
>> using Clang.wrap_c
>>
>>  In [2]:
>>   
>> context = wrap_c.init(; output_file="liboauth.jl", 
>> header_library=x->"liboauth", common_file="liboauth.jl", 
>> clang_diagnostics=true)
>>
>> context.options.wrap_structs = true
>>
>> wrap_c.wrap_c_headers(context, 
>> ["/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h"])
>>
>>  WARNING: wrap_c_headers: deprecated
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:112:46: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:138:54: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:138:86: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:315:67: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:315:81: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:320:66: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:320:80: error: 
>> unknown type name 'size_t'
>> /Users/randyzwitch/D

[julia-users] Help with Clang.jl for a C beginner

[Randy Zwitch]

Hi all - 

I've been trying to learn more about C and how Julia interacts and decided 
to play around with Clang.jl. I decided I was going to wrap liboauth from 
here:

http://liboauth.sourceforge.net/oauth_8h_source.html

I downloaded the C source, which resided in my OSX Downloads directory. 
Using the following Julia code generated a bunch of output:

 [1]:

using Clang.wrap_c

In [2]:

context = wrap_c.init(; output_file="liboauth.jl", 
header_library=x->"liboauth", common_file="liboauth.jl", clang_diagnostics=true)

context.options.wrap_structs = true

wrap_c.wrap_c_headers(context, 
["/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h"])

WARNING: wrap_c_headers: deprecated
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:112:46: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:138:54: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:138:86: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:315:67: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:315:81: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:320:66: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:320:80: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:519:28: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:532:30: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:670:61: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:688:57: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:715:43: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:717:70: warning: type 
specifier missing, defaults to 'int' [-Wimplicit-int]
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:717:77: warning: type 
specifier missing, defaults to 'int' [-Wimplicit-int]
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:717:77: error: 
redefinition of parameter 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:717:70: note: previous 
declaration is here
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:741:24: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:771:43: error: unknown 
type name 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:773:70: warning: type 
specifier missing, defaults to 'int' [-Wimplicit-int]
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:773:77: warning: type 
specifier missing, defaults to 'int' [-Wimplicit-int]
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:773:77: error: 
redefinition of parameter 'size_t'
/Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h:773:70: note: previous 
declaration is here

WRAPPING HEADER: /Users/randyzwitch/Downloads/liboauth-1.0.3/src/oauth.h

WARNING: Not wrapping MacroInstantiation   OA_GCC_VERSION_AT_LEAST
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated
WARNING: Not wrapping MacroInstantiation   attribute_deprecated

writing liboauth.jl

Out[2]:

1-element Array{Any,1}:
 nothing



Output:


const LIBOAUTH_VERSION = "1.0.3"
const LIBOAUTH_VERSION_MAJOR = 1
const LIBOAUTH_VERSION_MINOR = 0
const LIBOAUTH_VERSION_MICRO = 3
const LIBOAUTH_CUR = 8
const LIBOAUTH_REV = 7
const LIBOAUTH_AGE = 8

# Skipping MacroDefinition: OA_GCC_VERSION_AT_LEAST ( x , y ) ( __GNUC__ > 
x || __GNUC__ == x && __GNUC_MINOR__ >= y )
# Skipping MacroDefinition: attribute_deprecated __attribute__ ( ( 
deprecated ) )

# begin enum ANONYMOUS_1
typealias ANONYMOUS_1 Uint32
const OA_HMAC = (uint32)(0)
const OA_RSA = (uint32)(1)
const OA_PLAINTEXT = (uint32)(2)
# end enum ANONYMOUS_1

# begin enum OAuthMethod
typealias OAuthMethod Uint32
const OA_HMAC = (uint32)(0)
const OA_RSA = (uint32)(1)
const OA_PLAINTEXT = (uint32)(2)
# end enum OAuthMethod
function oauth_sign_hmac_sha1(m::Ptr{Uint8},k::Ptr{Uint8})

ccall((:oauth_sign_hmac_sha1,liboauth),Ptr{Uint8},(Ptr{Uint8},Ptr{Uint8}),m,k)
end

function 
oauth_sign_hmac_sha1_raw(m:

Re: [julia-users] JuliaLang Logo usage

[Randy Zwitch]

Since we're talking about it...what font is the logo in?

On Thursday, August 28, 2014 4:24:09 AM UTC-4, Andreas Lobinger wrote:
>
> btw: is the logo stored somewhere? I see a .svg version included in the 
> julialang.org webpage, but i guess that's not the normative source.
>
> On Thursday, August 28, 2014 5:15:10 AM UTC+2, Stefan Karpinski wrote:
>>
>> That would be great. Let me know how it goes.
>>
>> On Aug 27, 2014, at 10:42 PM, Ted Fujimoto  wrote:
>>
>> Thanks Stefan! If our gatherings are successful, maybe you or some Julia 
>> people at MIT could stop by. 
>>
>>
>> On Wed, Aug 27, 2014 at 10:35 PM, Stefan Karpinski  
>> wrote:
>>
>>> Nice! I grant you permission. I suspect it counts as fair use anyway.
>>>
>>>
>>> On Wed, Aug 27, 2014 at 10:30 PM, Ted Fujimoto  
>>> wrote:
>>>
 Hi,

 I'm at UPenn trying to start some gatherings centered around getting to 
 know and use the Julia Programming Language. How do I get permission to 
 use 
 the JuliaLang logo in our (strictly academic) meeting advertisements, 
 surveys, etc.? Can anyone here grant me permission?

 Thanks.

>>>
>>>
>>

Re: [julia-users] Semi-OT: Recommendations for learning just enough C for Julia

[Randy Zwitch]

João, I'd love to see your example. Even with light documentation, I think 
I could follow along. But from yours and everyone else's comments, it 
sounds like there really isn't too easy a way out here, that I should just 
break down and spend a few days/weeks playing around.

Thanks for your detailed comments Isaiah, they are really helpful as well 
to get me started.


On Friday, August 15, 2014 2:15:46 PM UTC-4, João Felipe Santos wrote:
>
> I once wrote a simple example of how to write and compile C code as a 
> shared library and call from Julia using ccall. I could share it if you are 
> interested, although it has no documentation at all at the moment besides a 
> couple of comments.
>
> Main things you have to know from C are types, structs, arrays and 
> pointers, passing arguments to functions by value and by reference, and the 
> basics of memory allocation (this is almost the whole language, excluding 
> standard libraries and quirkier parts of C99). 
>
> Regarding the shared library part, you could probably live only knowing it 
> is a way of exporting symbols from a binary file (.so on Linux, .dll on 
> Windows, .dylib on OS X) in a way other programs can use them.
>
> I may have simplified or overcomplicated things, but I think these are the 
> basic concepts one would need to write code that uses a shared library.
>
> --
> João Felipe Santos
>
>
> On Fri, Aug 15, 2014 at 1:15 PM, Randy Zwitch  > wrote:
>
>> I know the standard recommendation of K&R for people who want to learn C. 
>> But what would people's recommendations be to learn *just enough* C to be 
>> comfortable using C libraries from within Julia? For example, the manual 
>> states:
>>
>> "The code to be called must be available as a shared library. Most C and 
>> Fortran libraries ship compiled as shared libraries already... "
>>
>> Having done almost nothing in C, this statement doesn't help me a whole 
>> lot, since I don't know what a shared library is. For instance, I've come 
>> across a few .h files as open-source projects, but I think the above 
>> statement is referring to .so files? 
>>
>> So any recommendations how can I get enough knowledge about C to use 
>> ccall if I desire, without taking a ton of time away from Julia? I also 
>> know Python and R as a frame of reference.
>>
>
>

[julia-users] Semi-OT: Recommendations for learning just enough C for Julia

[Randy Zwitch]

I know the standard recommendation of K&R for people who want to learn C. 
But what would people's recommendations be to learn *just enough* C to be 
comfortable using C libraries from within Julia? For example, the manual 
states:

"The code to be called must be available as a shared library. Most C and 
Fortran libraries ship compiled as shared libraries already... "

Having done almost nothing in C, this statement doesn't help me a whole 
lot, since I don't know what a shared library is. For instance, I've come 
across a few .h files as open-source projects, but I think the above 
statement is referring to .so files? 

So any recommendations how can I get enough knowledge about C to use ccall 
if I desire, without taking a ton of time away from Julia? I also know 
Python and R as a frame of reference.

[julia-users] Re: Julia call to Seaborn library

[Randy Zwitch]

Interesting question. I obviously didn't evaluate that as part of the blog 
post, but it seems like it could be possible. The one hiccup could be that 
Seaborn seems to be a wrapper around matplotlib, so that Seaborn code can 
be used interchangeably with matplotlib within Python. Not knowing how 
PyPlot.jl works, if you were to import Seaborn using PyCall, maybe they all 
would communicate to the same backend and work?

 

On Tuesday, July 29, 2014 7:22:06 AM UTC-4, Bernd Blasius wrote:
>
>
>
> A recent post on reddit 
> http://badhessian.org/2014/07/six-of-one-plot-half-dozen-of-the-other/ 
> brought 
> my attention to the python seaborn package: 
> http://web.stanford.edu/~mwaskom/software/seaborn/
> Seaborn is a really cool Python visualization library based on matplotlib 
> and pandas, and provides a high-level interface for drawing attractive 
> statistical graphics.
>
> Any chance to use this library already from Julia via PyPlot or PyCall??
>
> --Bernd
>

Re: [julia-users] Semi-OT: Finding optimal k in k-means

[Randy Zwitch]

Thanks Rene and Jacob! These are both certainly helpful, as I don't have a 
really structured project I'm working on at the moment, I'm just supposed 
to try and "find something interesting" with all this hardware I have 
access to. So trying different methods beyond k-means I certainly possible, 
I'll just need to get my academic paper chops up a bit :)

On Monday, July 28, 2014 10:27:53 AM UTC-4, Jacob Quinn wrote:
>
> This probably isn't very helpful currently, but I've been meaning to try 
> to do a `kd-tree` implementation that allows for fast clustering for up to 
> 7-10 dimensions. (there's also ad-trees for categorical data that has even 
> better performance gains over traditional algorithms).
>
>
> http://www.autonlab.org/autonweb/14669/version/2/part/5/data/moore-veryfast.pdf?branch=main&language=en
>
> As a fun fact, Andrew Moore (author of the two algorithms/data structures 
> mentioned above) started the Google Pittsburgh office after leaving CMU and 
> he's just agreed to come back to CMU as the new dean of computer science!
>
> -Jacob
>
>
>
> On Mon, Jul 28, 2014 at 9:31 AM, René Donner  > wrote:
>
>> Hi,
>>
>> perhaps Quick-Shift clustering might be interesting as well [1]. It is 
>> easy to implement, fast, and in contrast to k-means / k-medoids (which it 
>> generalizes) has the very appealing property that the initial, hierachical 
>> data-structure has to be computed only once - you can then investigate 
>> different settings of the parameter \tau (the splitting criterium) 
>> extremely fast.
>>
>> In many cases it is easier to find a reasonable \tau than to come up with 
>> the exact number of clusters your data is expected to have.
>>
>> Cheers,
>>
>> Rene
>>
>> [1] http://www.robots.ox.ac.uk/~vedaldi/assets/pubs/vedaldi08quick.pdf
>>
>>
>>
>>
>>
>> Am 28.07.2014 um 15:06 schrieb Randy Zwitch > >:
>>
>> > I'm about to undertake a clustering exercise for a lot of data (Roughly 
>> 100MM rows*12 columns for every week, mixed floats/ints, for as many weeks 
>> as I choose to use). I was going to attempt to downsample to 1MM events or 
>> so and use the Clustering.jl package to try and pre-gather some idea of how 
>> many clusters to estimate, since clustering a billion or more events will 
>> take a bit of computation time. I'm familiar with the 'elbow method' of 
>> determining k, but that seems a bit arbitrary.
>> >
>> > Is anyone familiar with either of the techniques described in these two 
>> papers? There is a blog post (link) that states that the f(K) method is an 
>> order of magnitude better in performance time by removing the need for 
>> monte carlo methods. If anyone has any practical experience with these or 
>> advice about other methods (bonus for providing Julia code!), it would be 
>> much appreciated.
>> >
>> > http://www.stanford.edu/~hastie/Papers/gap.pdf
>> >
>> > http://www.ee.columbia.edu/~dpwe/papers/PhamDN05-kmeans.pdf
>> >
>> >
>>
>>
>

[julia-users] Semi-OT: Finding optimal k in k-means

[Randy Zwitch]

I'm about to undertake a clustering exercise for a lot of data (Roughly 
100MM rows*12 columns for every week, mixed floats/ints, for as many weeks 
as I choose to use). I was going to attempt to downsample to 1MM events or 
so and use the Clustering.jl package to try and pre-gather some idea of how 
many clusters to estimate, since clustering a billion or more events will 
take a bit of computation time. I'm familiar with the 'elbow method' of 
determining k, but that seems a bit arbitrary.

Is anyone familiar with either of the techniques described in these two 
papers? There is a blog post (link 
)
 
that states that the f(K) method is an order of magnitude better in 
performance time by removing the need for monte carlo methods. If anyone 
has any practical experience with these or advice about other methods 
(bonus for providing Julia code!), it would be much appreciated.

http://www.stanford.edu/~hastie/Papers/gap.pdf

http://www.ee.columbia.edu/~dpwe/papers/PhamDN05-kmeans.pdf

[julia-users] Re: Build failing with: `libopenspecfun.so.0': File exists

[Randy Zwitch]

Thanks, this got me this morning

On Friday, July 11, 2014 12:29:22 AM UTC-4, Pontus Stenetorp wrote:
>
> Everyone, 
>
> I read the GitHub activity as well as julia-dev and build Julia on a 
> daily basis, but I have not seen any mention of this error.  Since it 
> dodged the standard `make cleanall`, I thought I should share the 
> simple, rather obvious, fix just in case someone tries to search for 
> the issue.  Apparently there are some shared library symlink leftovers 
> that are not desirable, possibly due to a version bump.  Just clean 
> them out with `rm deps/openspecfun/libopenspecfun.*`, run the standard 
> `make testall` and you should be good to go again. 
>
> Regards, 
> Pontus Stenetorp 
>

Re: [julia-users] Question about surprising behavior of zip/using multiple columns in data frame

[Randy Zwitch]

Oh, ok, thanks! I wasn't realizing you were using '...' as splat, but 
rather "How did you not remember this..."

On Tuesday, July 1, 2014 9:54:18 PM UTC-4, Jacob Quinn wrote:
>
> jinx Isaiah :)
>
>
> On Tue, Jul 1, 2014 at 9:51 PM, Isaiah Norton  > wrote:
>
>> Regarding this:
>> > I was somewhat surprised that I had to reference the fields in the 
>> tuple by position
>>
>> there are two ways to do it:
>> 1) `value...` will splat the arguments
>> 2) `[datetime(year,month,day) for (year,month,day) in zip(test[:Year], 
>> test[:Month], test[:DayofMonth])]` will do what you want. (note the 
>> parens around the second (year,month,day)
>>
>>
>>
>>
>> On Tue, Jul 1, 2014 at 9:44 PM, Randy Zwitch > > wrote:
>>
>>> Sorry, not following...try value how? 
>>>
>>>
>>> On Tuesday, July 1, 2014 9:40:46 PM UTC-4, Isaiah wrote:
>>>
>>>> Try "value..."
>>>>
>>>>
>>>> On Tue, Jul 1, 2014 at 9:37 PM, Randy Zwitch  
>>>> wrote:
>>>>
>>>>> I have a data frame where the year, month, day, hour, etc. are in 
>>>>> different columns. I want to use Datetime.jl to make timestamps, then do 
>>>>> some processing.
>>>>>
>>>>> I tried to attack the problem like the following (which is to say, 
>>>>> Python-style), but it didn't work:
>>>>>
>>>>> test[:start_date] = [datetime(year,month,day) for year,month,day in 
>>>>> zip(test[:Year], test[:Month], test[:DayofMonth])]
>>>>>
>>>>> The working solution:
>>>>>
>>>>> test[:start_date] = [datetime(value[1],value[2],value[3]) for value 
>>>>> in zip(test[:Year], test[:Month], test[:DayofMonth])]
>>>>>
>>>>> I was somewhat surprised that I had to reference the fields in the 
>>>>> tuple by position, when syntax like a,b,c = (1,2,3) works elsewhere. 
>>>>> Is there something I'm missing/forgetting? Is there a better way to use 
>>>>> multiple columns from a data frame in a function to return a new column 
>>>>> in 
>>>>> the data frame?
>>>>>
>>>>
>>>>
>>
>

[julia-users] Re: Lowering the (mostly social/psychological) barriers to sharing packages?

[Randy Zwitch]

This doesn't seem like a great idea to me. I felt a great sense of 
accomplishment when I had my first package listed on METADATA, as I felt 
like I made a tangible contribution to the community (in the same way I'm 
proud of having a CRAN package). So for me, I'd question the value of 
having a package that's "sort of ok, but I'm not confident in it, and maybe 
I'll update it if someone compliments me or submits a pull request to 
extend the package..." It just seems so passive, when the barrier is 
actually pretty low to getting a package on METADATA (compared to the 
beatings that CRAN hands out).

There's going to be good code and bad code, and having the hook into GitHub 
provides a great mechanism for continuous improvement. The Julia community 
is the friendliest that I'm a part of, but maybe we just need to do more to 
have people believe in themselves.

What I do think we need is a better way to discover packages. For example, 
I had no idea what Nettle was until Viral (?) clued me into it having 
crypto functions.


On Tuesday, July 1, 2014 9:07:47 PM UTC-4, Iain Dunning wrote:
>
> Hi all,
>
> Something that came up in some discussions I had at *JuliaCon* is that 
> people perceive packages in METADATA as being for more "serious" packages, 
> i.e. by being there there is an implication of a certain minimum quality. A 
> lot of my efforts in the package ecosystem have been try to help package 
> developers to live up to that expectation. A consequence of this perception 
> is that some people might be averse to list their work on METADATA, for 
> fear its not good enough/not ready.
>
> You can currently list a package on METADATA with:
> - a version 0.0.0, which was the preferred way originally but is now 
> discouraged. This tagged version's hash would be updated as needed (i.e. it 
> doesn't follow master)
> - a listing with no tagged version, which allows someone to do 
> Pkg.add("YourPkg") and automatically get the most up-to-date version of 
> your package.
>
> Of course, you pretty much need to announce your package somewhere other 
> than METADATA to let users know it exists, and users can you 
> Pkg.clone("..") almost as easily as Pkg.add("..") with a no-version 
> listing. Currently pkg.julialang.org doesn't show packages without a 
> version, so the no-version listing is of limited utility for 
> discoverability.
>
> A proposal that came up a few times at the conference was for some sort of 
> METADATA-EXTRA, which only has versions of packages without version numbers 
> and is open to everyone and anyone. It'd be super easy to add packages - 
> simply add a name and URL to a list. Perhaps it could be accessed through a 
> package not in Base, e.g. PkgExtra.
> It would have 
> PkgExtra.update_listing() - refresh local list of package names and URLs
> PkgExtra.add(pkgname..) - git clone a package to ~/.juila/v0.x/
> PkgExtra.update(pkgname...) - git pull the packages
> PkgExtra.rm(pkgname...) - nuke the packages
> So basically, super simple. User could even be responsible for satisfying 
> any dependencies of the packages installed this way. At the most, the 
> REQUIRE in the package should be used, to keep this system as light-weight 
> as possible.
>
> So this wouldn't be much work to get going, but I was more curious to see 
> if there is actually demand for this. I'm worried its one of those things 
> people say they want, but I'm not sure if the demand is real. This might be 
> bad just in that it "forks" METADATA sort of, which is possibly not a great 
> idea for a new package. On the plus side, it could encourage even more 
> development and sharing.
>
> Thoughts?
>

Re: [julia-users] Question about surprising behavior of zip/using multiple columns in data frame

[Randy Zwitch]

Sorry, not following...try value how? 

On Tuesday, July 1, 2014 9:40:46 PM UTC-4, Isaiah wrote:
>
> Try "value..."
>
>
> On Tue, Jul 1, 2014 at 9:37 PM, Randy Zwitch  > wrote:
>
>> I have a data frame where the year, month, day, hour, etc. are in 
>> different columns. I want to use Datetime.jl to make timestamps, then do 
>> some processing.
>>
>> I tried to attack the problem like the following (which is to say, 
>> Python-style), but it didn't work:
>>
>> test[:start_date] = [datetime(year,month,day) for year,month,day in 
>> zip(test[:Year], test[:Month], test[:DayofMonth])]
>>
>> The working solution:
>>
>> test[:start_date] = [datetime(value[1],value[2],value[3]) for value in 
>> zip(test[:Year], test[:Month], test[:DayofMonth])]
>>
>> I was somewhat surprised that I had to reference the fields in the tuple 
>> by position, when syntax like a,b,c = (1,2,3) works elsewhere. Is there 
>> something I'm missing/forgetting? Is there a better way to use multiple 
>> columns from a data frame in a function to return a new column in the data 
>> frame?
>>
>
>

[julia-users] Question about surprising behavior of zip/using multiple columns in data frame

[Randy Zwitch]

I have a data frame where the year, month, day, hour, etc. are in different 
columns. I want to use Datetime.jl to make timestamps, then do some 
processing.

I tried to attack the problem like the following (which is to say, 
Python-style), but it didn't work:

test[:start_date] = [datetime(year,month,day) for year,month,day in 
zip(test[:Year], test[:Month], test[:DayofMonth])]

The working solution:

test[:start_date] = [datetime(value[1],value[2],value[3]) for value in 
zip(test[:Year], test[:Month], test[:DayofMonth])]

I was somewhat surprised that I had to reference the fields in the tuple by 
position, when syntax like a,b,c = (1,2,3) works elsewhere. Is there 
something I'm missing/forgetting? Is there a better way to use multiple 
columns from a data frame in a function to return a new column in the data 
frame?

Re: [julia-users] Re: juliabloggers.com is now live!

[Randy Zwitch]

Sorry I missed this before...is this still an issue? WordPress RSS feeds 
should be pretty standardized to work with any reader, but if there is an 
issue, I can see if there's a setting I'm missing.

On Tuesday, June 17, 2014 5:17:02 PM UTC-4, K leo wrote:
>
> I use g2reader (http://www.g2reader.com) and can't subscribe to this.   
> Don't know why.  It complains about: 
>
> Entered url doesn't contain valid feed or doesn't link to feed. It is 
> also possible feed contains no items. 
>
> On 06/17/2014 08:38 PM, Randy Zwitch wrote: 
> > My apologies, I think the link got mangled last time. Here it is 
> > again: http://www.juliabloggers.com/feed/ 
> > <http://www.juliabloggers.com/feed/> 
> > 
> > On Monday, June 16, 2014 9:18:45 PM UTC-4, K leo wrote: 
> > 
> > Is there something wrong with the feed? 
> > 
> > http://www.juliabloggers.com/feed/ 
> > juliabloggers.com 
> > <http://www.juliabloggers.com/feed/juliabloggers.com> 
> > Entered url doesn't contain valid feed or doesn't link to feed. It 
> is 
> > also possible feed contains no items. 
> > 
>
>

[julia-users] Gadfly: switching colors for boxplot

[Randy Zwitch]

In the Gadfly documentation 
(http://dcjones.github.io/Gadfly.jl/geom_boxplot.html), it makes mention 
that behind the scenes, these aesthetics are used:

Aesthetics used directly:

   - x
   - middle
   - lower_hinge
   - upper_hinge
   - lower_fence
   - upper_fence
   - outliers


It's clear how to create the plot example, but how can I manipulate the 
aesthetics, such as changing the box color from blue to white or the middle 
value from light blue to black?

plot(dataset("lattice", "singer"), x="VoicePart", y="Height", Geom.boxplot)

Re: [julia-users] ODBC.jl: Getting connection string syntax back

[Randy Zwitch]

Done, thanks

On Thursday, June 19, 2014 5:00:20 PM UTC-4, Jacob Quinn wrote:
>
> Hmmm..I believe there is a way to do this. Would you mind opening an 
> issue about it and I'll put it on my todo list?
>
> -Jacob
>
>
> On Thu, Jun 19, 2014 at 12:39 PM, Randy Zwitch  > wrote:
>
>> In ODBC.jl, if you call advancedconnect() on Windows with no arguments, 
>> it pops up the ODBC manager and lets you pick a DSN. I am able to connect 
>> to my database just fine, but I'd like to be able to script my connection 
>> later on.
>>
>> Is there a way to get the full connection string back? I've tried conn 
>> and Connections objects at the REPL, but all I get back are PTR 
>> references. 
>>
>
>

[julia-users] ODBC.jl: Getting connection string syntax back

[Randy Zwitch]

In ODBC.jl, if you call advancedconnect() on Windows with no arguments, it 
pops up the ODBC manager and lets you pick a DSN. I am able to connect to 
my database just fine, but I'd like to be able to script my connection 
later on.

Is there a way to get the full connection string back? I've tried conn and 
Connections objects at the REPL, but all I get back are PTR references. 

Re: [julia-users] juliabloggers.com is now live!

[Randy Zwitch]

It's up to you. If you remove Feedburner, you remove whatever stats you 
might be getting. But you'll get a better looking attribution URL on Julia 
Bloggers. So you'd get:

http://julialang.org/blog/2013/05/graphical-user-interfaces-part1/

instead of

http://feedproxy.google.com/~r/JuliaLang/~3/SHZGDk581qM/graphical-user-interfaces-part1

I don't think you guys have any problems ranking in Google, so I'm not sure 
it's even worth the 5 minutes to change.

On Tuesday, June 17, 2014 11:15:40 AM UTC-4, Stefan Karpinski wrote:
>
> I set that up back in 2012 and I know squat about RSS or setting up feeds, 
> so if anyone has any good ideas about alternate setups, I'm all ears. I 
> have no attachment to feedburner.
>
>
> On Tue, Jun 17, 2014 at 9:33 AM, Randy Zwitch  > wrote:
>
>> I did add the julialang.org/blog feed to Julia Bloggers already. The 
>> attribution is a bit messed up because they are re-directing their feed 
>> using Feedburner, then Feedburner re-directs to the actual URL; I'll try to 
>> figure out how to get the attribution to point directly to the blog post.
>>
>> Here are the posts from the official blog:
>>
>> http://www.juliabloggers.com/author/julia-developers/
>>
>>
>> On Tuesday, June 17, 2014 9:04:37 AM UTC-4, Tobias Knopp wrote:
>>>
>>> Randy, would it be possible to integrate the page in julialang.org 
>>> (under the blog section)?
>>> If not it would probably be good to add a link there + maybe remove the 
>>> dublicated posts.
>>>
>>> Cheers,
>>>
>>> Tobi
>>>
>>> Am Dienstag, 17. Juni 2014 14:39:46 UTC+2 schrieb Randy Zwitch:
>>>>
>>>> I think this is just a caching issue, the attribution should be on all 
>>>> pages.
>>>>
>>>> On Tuesday, June 17, 2014 3:44:47 AM UTC-4, Mauro wrote:
>>>>>
>>>>> Thanks for putting this together!  One more thing about authors, on 
>>>>> pages like for example this one
>>>>> http://www.juliabloggers.com/using-asciiplots-jl/
>>>>> there should be the same attribution as on the front page.
>>>>>
>>>>> On Tuesday, June 17, 2014 1:19:48 AM UTC+1, Randy Zwitch wrote:
>>>>>>
>>>>>> Ok, there is now more obvious attribution on each post, with the 
>>>>>> author name and link of the original post prominently displayed before 
>>>>>> the 
>>>>>> article.
>>>>>>
>>>>>> If anyone else has any other recommendations/requests (still need a 
>>>>>> logo!), please let me know.
>>>>>>
>>>>>
>

Re: [julia-users] juliabloggers.com is now live!

[Randy Zwitch]

I did add the julialang.org/blog feed to Julia Bloggers already. The 
attribution is a bit messed up because they are re-directing their feed 
using Feedburner, then Feedburner re-directs to the actual URL; I'll try to 
figure out how to get the attribution to point directly to the blog post.

Here are the posts from the official blog:

http://www.juliabloggers.com/author/julia-developers/

On Tuesday, June 17, 2014 9:04:37 AM UTC-4, Tobias Knopp wrote:
>
> Randy, would it be possible to integrate the page in julialang.org (under 
> the blog section)?
> If not it would probably be good to add a link there + maybe remove the 
> dublicated posts.
>
> Cheers,
>
> Tobi
>
> Am Dienstag, 17. Juni 2014 14:39:46 UTC+2 schrieb Randy Zwitch:
>>
>> I think this is just a caching issue, the attribution should be on all 
>> pages.
>>
>> On Tuesday, June 17, 2014 3:44:47 AM UTC-4, Mauro wrote:
>>>
>>> Thanks for putting this together!  One more thing about authors, on 
>>> pages like for example this one
>>> http://www.juliabloggers.com/using-asciiplots-jl/
>>> there should be the same attribution as on the front page.
>>>
>>> On Tuesday, June 17, 2014 1:19:48 AM UTC+1, Randy Zwitch wrote:
>>>>
>>>> Ok, there is now more obvious attribution on each post, with the author 
>>>> name and link of the original post prominently displayed before the 
>>>> article.
>>>>
>>>> If anyone else has any other recommendations/requests (still need a 
>>>> logo!), please let me know.
>>>>
>>>

Re: [julia-users] juliabloggers.com is now live!

[Randy Zwitch]

I think this is just a caching issue, the attribution should be on all 
pages.

On Tuesday, June 17, 2014 3:44:47 AM UTC-4, Mauro wrote:
>
> Thanks for putting this together!  One more thing about authors, on pages 
> like for example this one
> http://www.juliabloggers.com/using-asciiplots-jl/
> there should be the same attribution as on the front page.
>
> On Tuesday, June 17, 2014 1:19:48 AM UTC+1, Randy Zwitch wrote:
>>
>> Ok, there is now more obvious attribution on each post, with the author 
>> name and link of the original post prominently displayed before the article.
>>
>> If anyone else has any other recommendations/requests (still need a 
>> logo!), please let me know.
>>
>