[julia-users] Re: Unexpected Performance Behaviour

[Eric Forgy]

I still don't understand the details of the new functions in v0.5. but I'd 
be inclined to think this test depends on whether you're on v0.4.6 or 
v0.5.0.

On Tuesday, August 2, 2016 at 12:53:27 PM UTC+8, Greg Plowman wrote:
>
> I get timing/allocations the other way around. (test1, hard-coded version 
> is fast without allocation)
> @code_warntype for test2 shows type-instability for s (because return type 
> cannot be inferred for f1)
>
>
> On Tuesday, August 2, 2016 at 2:33:24 PM UTC+10, Christoph Ortner wrote:
>
>> Below are two tests, in the first a simple polynomial is "hard-coded", in 
>> the second it is passed as a function. I would expect the two to be 
>> equivalent, but the second case is significantly faster. Can anybody 
>> explain what is going on?  @code_warntype doesn't show anything that would 
>> explain it? 
>>
>> function test1(N)
>>
>> r = 0.234; s = 0.0
>> for n = 1:N
>> s += r^3 + r^5
>> end
>> return s
>> end
>>
>>
>> function test2(N, f1)
>> r = 0.234; s = 0.0
>> for n = 1:N
>> s += f1(r)
>> end
>> return s
>> end
>>
>>
>> g1(r) = r^3 + r^5
>>
>>
>> test1(10)
>> test2(10, g1)
>>
>>
>> println("Test1: hard-coded functions")
>> @time test1(1_000_000)
>> @time test1(1_000_000)
>> @time test1(1_000_000)
>>
>>
>> println("Test2: pass functions")
>> @time test2(1_000_000, g1)
>> @time test2(1_000_000, g1)
>> @time test2(1_000_000, g1)
>>
>>
>>
>>
>> # $ julia5 weird_test2.jl
>> # Test1: hard-coded functions
>> #   0.086683 seconds (4.00 M allocations: 61.043 MB, 50.75% gc time)
>> #   0.142487 seconds (4.00 M allocations: 61.035 MB, 76.91% gc time)
>> #   0.025388 seconds (4.00 M allocations: 61.035 MB, 4.28% gc time)
>> # Test2: pass functions
>> #   0.000912 seconds (5 allocations: 176 bytes)
>> #   0.000860 seconds (5 allocations: 176 bytes)
>> #   0.000846 seconds (5 allocations: 176 bytes)
>>
>>
>>
>>
>>
>>

[julia-users] Re: Unexpected Performance Behaviour

['Greg Plowman' via julia-users]

I get timing/allocations the other way around. (test1, hard-coded version 
is fast without allocation)
@code_warntype for test2 shows type-instability for s (because return type 
cannot be inferred for f1)


On Tuesday, August 2, 2016 at 2:33:24 PM UTC+10, Christoph Ortner wrote:

> Below are two tests, in the first a simple polynomial is "hard-coded", in 
> the second it is passed as a function. I would expect the two to be 
> equivalent, but the second case is significantly faster. Can anybody 
> explain what is going on?  @code_warntype doesn't show anything that would 
> explain it? 
>
> function test1(N)
>
> r = 0.234; s = 0.0
> for n = 1:N
> s += r^3 + r^5
> end
> return s
> end
>
>
> function test2(N, f1)
> r = 0.234; s = 0.0
> for n = 1:N
> s += f1(r)
> end
> return s
> end
>
>
> g1(r) = r^3 + r^5
>
>
> test1(10)
> test2(10, g1)
>
>
> println("Test1: hard-coded functions")
> @time test1(1_000_000)
> @time test1(1_000_000)
> @time test1(1_000_000)
>
>
> println("Test2: pass functions")
> @time test2(1_000_000, g1)
> @time test2(1_000_000, g1)
> @time test2(1_000_000, g1)
>
>
>
>
> # $ julia5 weird_test2.jl
> # Test1: hard-coded functions
> #   0.086683 seconds (4.00 M allocations: 61.043 MB, 50.75% gc time)
> #   0.142487 seconds (4.00 M allocations: 61.035 MB, 76.91% gc time)
> #   0.025388 seconds (4.00 M allocations: 61.035 MB, 4.28% gc time)
> # Test2: pass functions
> #   0.000912 seconds (5 allocations: 176 bytes)
> #   0.000860 seconds (5 allocations: 176 bytes)
> #   0.000846 seconds (5 allocations: 176 bytes)
>
>
>
>
>
>

[julia-users] Unexpected Performance Behaviour

[Christoph Ortner]

Below are two tests, in the first a simple polynomial is "hard-coded", in 
the second it is passed as a function. I would expect the two to be 
equivalent, but the second case is significantly faster. Can anybody 
explain what is going on?  @code_warntype doesn't show anything that would 
explain it? 

function test1(N)

r = 0.234; s = 0.0
for n = 1:N
s += r^3 + r^5
end
return s
end


function test2(N, f1)
r = 0.234; s = 0.0
for n = 1:N
s += f1(r)
end
return s
end


g1(r) = r^3 + r^5


test1(10)
test2(10, g1)


println("Test1: hard-coded functions")
@time test1(1_000_000)
@time test1(1_000_000)
@time test1(1_000_000)


println("Test2: pass functions")
@time test2(1_000_000, g1)
@time test2(1_000_000, g1)
@time test2(1_000_000, g1)




# $ julia5 weird_test2.jl
# Test1: hard-coded functions
#   0.086683 seconds (4.00 M allocations: 61.043 MB, 50.75% gc time)
#   0.142487 seconds (4.00 M allocations: 61.035 MB, 76.91% gc time)
#   0.025388 seconds (4.00 M allocations: 61.035 MB, 4.28% gc time)
# Test2: pass functions
#   0.000912 seconds (5 allocations: 176 bytes)
#   0.000860 seconds (5 allocations: 176 bytes)
#   0.000846 seconds (5 allocations: 176 bytes)

Re: [julia-users] Re: Tuples of Functions

[Christoph Ortner]

Yichao: your FunctionWrappers.jl package is really helpful - thank you. 

For anybody interested, I posted a gist 
 comparing 
performance of hard-coded functions with functions in a tuple (factor 10 
worse performance) and functionwrappers in a tuple (ca 10% reduced 
performance)

Re: [julia-users] Slides/notebook of Amit Murthy's presentation at Juliacon 2016?

[Islam Badreldin]

Correction: link to the master branch not to a specific 
commithttps://github.com/andreasnoack/ParallelWorkshop/tree/master
  -Islam
_
From: Islam Badreldin 
Sent: Monday, August 1, 2016 9:25 PM
Subject: Re: [julia-users] Slides/notebook of Amit Murthy's presentation at 
Juliacon 2016?
To: julia-users 


Hi ArrigoI know that the JuliaCon 2016 Parallel Workshop notebooks are hosted 
in this repository 
https://github.com/andreasnoack/ParallelWorkshop/tree/e662628637654b4ac2727ccdf7d686d08e4115ee
Are you looking for the ArrayFire Tutorial notebook located in there?
  -Islam
_
From: Arrigo Benedetti 
Sent: Monday, August 1, 2016 8:46 PM
Subject: [julia-users] Slides/notebook of Amit Murthy's presentation at 
Juliacon 2016?
To: julia-users 


Unfortunately around min 44 in the video of Amit Murthy's presentation at the 
Juliacon 2016 Parallel Programming workshop the slide panel is totally out of 
focus so I was wondering if the slides or notebook are available somewhere.

thanks!

-Arrigo

https://youtu.be/euZkvgx0fG8?list=PLP8iPy9hna6SQPwZUDtAM59-wPzCPyD_S

Re: [julia-users] Slides/notebook of Amit Murthy's presentation at Juliacon 2016?

[Islam Badreldin]

Hi ArrigoI know that the JuliaCon 2016 Parallel Workshop notebooks are hosted 
in this repository 
https://github.com/andreasnoack/ParallelWorkshop/tree/e662628637654b4ac2727ccdf7d686d08e4115ee
Are you looking for the ArrayFire Tutorial notebook located in there?
  -Islam

_
From: Arrigo Benedetti 
Sent: Monday, August 1, 2016 8:46 PM
Subject: [julia-users] Slides/notebook of Amit Murthy's presentation at 
Juliacon 2016?
To: julia-users 


Unfortunately around min 44 in the video of Amit Murthy's presentation at the 
Juliacon 2016 Parallel Programming workshop the slide panel is totally out of 
focus so I was wondering if the slides or notebook are available somewhere.

thanks!

-Arrigo

https://youtu.be/euZkvgx0fG8?list=PLP8iPy9hna6SQPwZUDtAM59-wPzCPyD_S

[julia-users] Slides/notebook of Amit Murthy's presentation at Juliacon 2016?

[Arrigo Benedetti]

Unfortunately around min 44 in the video of Amit Murthy's presentation at 
the Juliacon 2016 Parallel Programming workshop the slide panel is totally 
out of focus so I was wondering if the slides or notebook are available 
somewhere.

thanks!

-Arrigo

https://youtu.be/euZkvgx0fG8?list=PLP8iPy9hna6SQPwZUDtAM59-wPzCPyD_S

[julia-users] Re: issue with setdiff

[Joris Bierkens]

Thank you Tim, that works,

julia> setdiff(Set([1,2,3,4]),Set([2,3,5]))
Set([4,1])

has the expected behaviour, as well as

julia> setdiff(Set{Int}([1,2,3,4]),Set{Int}([2,3,5]))
Set([4,1])

On Monday, August 1, 2016 at 6:52:57 PM UTC+1, Tim Wheeler wrote:
>
> Your Set constructor is incorrect.
> Try Set{Int}([1,2,3,4]) instead.
>

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

['Tobias Knopp' via julia-users]

I think that Steven has a point here. Technically we have all in place and 
Tims "Reexport" snipped is indeed the solution for creating Matlab like 
toolboxes. Its quite interesting that nobody has yet done such a 
metapackage. Maybe its because those users knowing the packages like the 
fine-grained control and therefore don't require a big metapackage?

I also think that the large amount of research users naturally leads to 
many smaller packages that are formed in a bottom up process and therefore 
are quite inhomogeneous.

In my opinion it would need two ingredients to improve on this front
- It would be good to find areas, where there are many smaller incompatible 
packages that would benefit from a unification/reorganization.
- In my opinion it would also need some popularity system that makes it 
dead simple to know, which is the standard package for a common task and 
which is much more experimental.

Maybe it could also work trying to make a top down analysis: What are the 
10 main packages a user could search for?

Best

Tobias
 

Am Montag, 1. August 2016 17:36:56 UTC+2 schrieb Steven Sagaert:
>
> When I say "work well together" I don't just mean that their versions 
> technically work together without errors, but also that they match 
> stylistically and that the datastructures that they expect as input/output 
> match so that no excessive translation and/or copying of data is needed 
> which is bad for performance and style.  That kind of discussion is for 
> example happening in OCAML to come to a platform and how to resolve the 
> ocaml standard lib vs Jane street lib schism.
>
> On Monday, August 1, 2016 at 5:19:17 PM UTC+2, Steven Sagaert wrote:
>>
>> I think the most important part of it is the idea of having a second 
>> (beyond the standard lib that comes with the runtime) larger, optional 
>> layer of curated libs that are known to work together. That together with 
>> the metapackage idea for easy inclusion ( maybe with possible overrides as 
>> in the Rust proposal) would be very handy for people who do not do Julia 
>> coding all the time and hence cannot follow the larger package ecosystem 
>> closely. People who do not want this second layer could still just use the 
>> standard lib + whatever packages they want. One could even extend this to 
>> multiple layer, each one more optional and lighter curated: standard lib -> 
>> platform light -> extended paltform -> ...
>>
>> Now there is already a good attempt in the julia ecosystem to group 
>> related packages in webpages and try to avoid too much libraries that do 
>> the same or partially overlap (more like scientific Python, rather than the 
>> R jungle) and that's great, but per group there still  are several 
>> competing packages and sometimes it's unclear from the descriptions to pick 
>> a clear winner. A curated subset of these "the platform"  by the community 
>> that adrresses the most common needs except maybe for special niches, would 
>> be very helpful. That's all :)
>>
>> On Monday, August 1, 2016 at 4:33:24 PM UTC+2, Stefan Karpinski wrote:
>>>
>>> There's a fair amount of discussion of the Rust Platform proposal over 
>>> here:
>>>
>>> https://internals.rust-lang.org/t/proposal-the-rust-platform/3745
>>>
>>> In short there's a lack of agreement to this in Rust. Moreover, in Rust, 
>>> different versions of libraries are much more closely locked to each other, 
>>> whereas in Julia the coupling is much looser. Steven, since you're in favor 
>>> of this idea, can you explain why you think it's a good idea for Julia? 
>>> What problems does it solve?
>>>
>>> On Mon, Aug 1, 2016 at 7:31 AM, Tony Kelman  wrote:
>>>
 The vision I personally have for this would be something more like SUSE 
 Studio (https://susestudio.com/) where it's just a few clicks, or a 
 configuration file in the build system, that could give you a set of 
 default-installed packages of your choosing, and make installers for your 
 own custom "spins" of a Julia-with-packages distribution.



 On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote:
>
> module MyMetaPackage 
>
> using Reexport 
>
> @reexport using PackageA 
> @reexport using PackageB 
> ... 
>
> end 
>
> Best. 
> --Tim 
>
> On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote: 
> > is more than just a webpage with a list of packages... for starters 
> the 
> > concept of metapackage. 
> > 
> > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote: 
> > > Maybe you already know about it, but there is a curated list of 
> packages 
> > > at https://github.com/svaksha/Julia.jl 
> > > 
> > > On Mon, Aug 01 2016, Steven Sagaert wrote: 
> > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/ 
>
>
>
>>>

[julia-users] Error in installing Mongo package on Mac OS

[Tony Kelman]

Does Pkg.checkout("Homebrew") and restarting Julia make any difference? If not, 
go back to the tagged release with Pkg.free("Homebrew")

[julia-users] Error in installing Mongo package on Mac OS

[Roger Whitney]

I am new to Julia and am trying to use the Mongo package. I am using Julia 
0.4.6 on Mac OS 10.11.6. When I try to add (or build) the package using 
Pkg.add("Mongo") or Pkg.build("Mongo")I get the error:

"Error: Cannot install mongo-c because conflicting formulae are installed.


  libbson: because mongo-c installs the libbson headers


Please `brew unlink libbson` before continuing.


Unlinking removes a formula's symlinks from 
/Users/whitney/.julia/v0.4/Homebrew/deps/usr. You can

link the formula again after the install finishes. You can --force this

install, but the build may fail or cause obscure side-effects in the

resulting software."


I then tried to unlink libbson using: Homebrew.brew(`unlink libbson`) and 
then tried building Mongo again, but had the same error.


Has anyone been able to install the Mongo package on a Mac?  Any help would 
be appreciated. There was a thread on the Mongo package about a year ago 
which ended in people claiming they were able to install the package but 
errors there seemed different. 

[julia-users] Re: issue with setdiff

[Tim Wheeler]

Your Set constructor is incorrect.
Try Set{Int}([1,2,3,4]) instead.

[julia-users] issue with setdiff

[Joris Bierkens]

I a seemingly ok Julia installation, version 0.4.6 (2016-06-19 17:16 UTC), 
I try the command 

julia> setdiff(Set(1,2,3,4),Set(2,3,5))

and I get the following error:

ERROR: MethodError: `convert` has no method matching 
convert(::Type{Set{T}}, ::Int64, ::Int64, ::Int64, ::Int64)
This may have arisen from a call to the constructor Set{T}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  Set(::Any)
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, ::T)
  ...
 in call at essentials.jl:57

This is unexpected, especially since I have copied this line from this 
 tutorial.

Does somebody have any advise what is going wrong? Thanks, Joris

[julia-users] Re: Anonymous Functions in 0.5 - Performance

[Christopher Alexander]

Yup, that did it.  And wow is it fast.

*function testing(k::Vector)*

  *return map((x::Float64) -> x^2, k)*


*end*

*@time testing(k)*0.07 seconds (7 allocations: 8.125 KB)



On Monday, August 1, 2016 at 12:25:59 PM UTC-4, David P. Sanders wrote:
>
> Don't do benchmarks in global scope. Wrap everything in a function. 

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Tony Kelman]

I think Pkg.add should obey setprotocol!, it's likely a bug that Pkg.init 
doesn't. The extra colon after .com probably is malformed so isn't the 
first error correct? The second issue might be fixed by some authentication 
changes that Keno just merged a few minutes ago, there should be binaries 
that include that fix built in a few hours.


On Monday, August 1, 2016 at 8:31:44 AM UTC-7, Daniel O'Malley wrote:
>
> I tried the Pkg.init("ssh://...") a couple different ways, but neither 
> worked.
>
> Pkg.init("ssh://g...@github.com:/JuliaLang/METADATA.jl.git")
>
> gave GitError(Code:EINVALIDSPEC, Class:Net, Malformed URL 
> 'ssh://g...@github.com:/JuliaLang/METADATA.jl.git').
>
> Pkg.init("ssh://g...@github.com/JuliaLang/METADATA.jl.git")
>
> asked me about my ssh keys then resulted in an authentication failure. If 
> I were to get Pkg.init() working in this way, Pkg.add and other Pkg 
> functions would still have problems though, right?
>
> On Monday, August 1, 2016 at 9:09:22 AM UTC-6, Tony Kelman wrote:
>>
>> That could be considered a bug, Pkg.init should probably respect the 
>> Pkg.setprotocol! setting, at least when using the DEFAULT_META value. You 
>> should also be able to do Pkg.init("ssh://g...@github.com:/
>> JuliaLang/METADATA.jl.git") as a workaround to avoid having to go through 
>> command-line git.
>>
>>
>> On Monday, August 1, 2016 at 7:01:51 AM UTC-7, Daniel O'Malley wrote:
>>>
>>> Oh, sorry for the mixup. Doing a
>>>
>>> git clone ssh://g...@github.com:/JuliaLang/METADATA.jl.git
>>>
>>> from a shell succeeds. I haven't had success trying to change the 
>>> protocol with Pkg.setprotocol! though. Whether I do 
>>> Pkg.setprotocol!("ssh"), Pkg.setprotocol!("git"), or 
>>> Pkg.setprotocol!("notaprotocol"), Pkg.init() seems to always try to clone 
>>> via https.
>>>
>>> On Sunday, July 31, 2016 at 10:31:38 PM UTC-6, Tony Kelman wrote:

 No, I meant ssh:// or git:// url's for packages.


 On Sunday, July 31, 2016 at 7:02:15 PM UTC-7, Daniel O'Malley wrote:
>
> Tony, thanks for the quick response and all the work you put into 
> julia. It would be great to have the package system working for Mac/Linux 
> from behind a proxy without needing to rebuild anything. If you need 
> someone to help test from behind a proxy, please let me know. I'd be 
> happy 
> to do it.
>
> When you say "ssh remotes", do you mean something like 
> addprocs(["machine1", "machine2"])? That does work for me, but I haven't 
> tried addprocs'ing to a machine outside our network.
>
> On Sunday, July 31, 2016 at 6:12:12 PM UTC-6, Tony Kelman wrote:
>>
>> I believe you need to build libgit2 against libcurl in order for 
>> proxies to work on linux and mac. We do not currently have it set up in 
>> our 
>> build system to do that in a self contained distributable way for 
>> binaries, 
>> but it might not be too hard to write the necessary makefile to make it 
>> work.
>>
>> We were prioritizing getting ssh remotes to work again for the first 
>> rc. Do ssh remotes work over proxies by any chance? I don't currently 
>> have 
>> immediate access to an environment behind a proxy to test this, but we 
>> had 
>> looked into setting one up that we could revisit.
>>
>

[julia-users] Anonymous Functions in 0.5 - Performance

[David P. Sanders]

Don't do benchmarks in global scope. Wrap everything in a function. 

[julia-users] Anonymous Functions in 0.5 - Performance

[Christopher Alexander]

Hi all!  I am wondering if perhaps I am getting the syntax wrong with 
respect to the proper way to do anonymous functions in 0.5.  I am not 
seeing any performance increase when using them as I expected.

For example:


*k = rand(1000)*

*@time map((x::Float64) -> x^2, k)*0.025886 seconds (12.55 k allocations: 
567.842 KB)



*squareit(x::Float64) = x^2*

*@time map(squareit, k)*

0.000103 seconds (7 allocations: 8.125 KB)

Or are you not going to get a speed increase using "map"?

Thanks!

Chris

[julia-users] Re: web scraping with Julia

[Avik Sengupta]

This may be a good opportunity to introduce our CSS Selector library in 
Julia, Cascadia.jl : https://github.com/Algocircle/Cascadia.jl

The code is based on the Cascadia GO library by Andy Balhom. 

Cascadia.jl uses the Gumbo.jl html parser, and allows querying of the 
resulting parse tree with CSS selectors. That allows you go extract data 
out of html documents with relative ease. There is an example in the 
package that scrapes one page on StackOverflow. 

Regards
-
Avik

On Monday, 1 August 2016 09:46:43 UTC+1, STAR0SS wrote:
>
> I used HTTPClient to get the page and Gumbo to parse it some time ago 
> (near v0.3)
>
> https://github.com/porterjamesj/Gumbo.jl
>
> I was doing things like that, it's probably not the most elegant
> way of doing it, but it was working fine:
>
> function get_hrefs(body::HTMLElement)
> links = String[]
> for elem in preorder(body)
> if typeof(elem) == HTMLElement{:a}
> try
> push!(links,getattr(elem, "href"))
> catch
> end
> end
> end
> return links
> end
>

[julia-users] Re: How to make a variable length tuple with inferred type

[Kristoffer Carlsson]

Nope. nuple(::Function, ::Int) is not type stable because the return type 
depends on the value of the integer.

On Monday, August 1, 2016 at 5:17:10 PM UTC+2, mmh wrote:
>
> Is this a known bug/regression?
>
> On Sunday, July 31, 2016 at 10:53:11 PM UTC-4, Sheehan Olver wrote:
>>
>> It still doesn't infer the type in 0.5:
>>
>> *julia> **@code_warntype ntuple( x -> 0, 3)*
>>
>> Variables:
>>
>>   #self#::Base.#ntuple
>>
>>   f::##5#6
>>
>>   n::Int64
>>
>>
>> Body:
>>
>>   begin 
>>
>>   unless (Base.sle_int)(n::Int64,0)::Bool goto 3
>>
>>   return (Core.tuple)()::Tuple{}
>>
>>   3: 
>>
>>   unless (n::Int64 === 1)::Bool goto 6
>>
>>   return (Core.tuple)($(QuoteNode(0)))::Tuple{Int64}
>>
>>   6: 
>>
>>   unless (n::Int64 === 2)::Bool goto 9
>>
>>   return 
>> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64}
>>
>>   9: 
>>
>>   unless (n::Int64 === 3)::Bool goto 12
>>
>>   return 
>> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64}
>>
>>   12: 
>>
>>   unless (n::Int64 === 4)::Bool goto 15
>>
>>   return 
>> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64}
>>
>>   15: 
>>
>>   unless (n::Int64 === 5)::Bool goto 18
>>
>>   return 
>> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64,Int64}
>>
>>   18: 
>>
>>   unless (Base.slt_int)(n::Int64,16)::Bool goto 21
>>
>>   return (Core._apply)(Core.tuple,$(Expr(:invoke, LambdaInfo for 
>> ntuple(::##5#6, ::Int64), :(Base.ntuple), :(f), 
>> :((Base.box)(Int64,(Base.sub_int)(n,5),(Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64,Int64})
>> *::Tuple{Vararg{Any,N}}*
>>
>>   21: 
>>
>>   return $(Expr(:invoke, LambdaInfo for _ntuple(::Function, ::Int64), 
>> :(Base._ntuple), :(f), :(n)))
>>
>>   end*::Tuple*
>>
>> On Monday, August 1, 2016 at 10:34:30 AM UTC+10, David P. Sanders wrote:
>>>
>>>
>>>
>>> El domingo, 31 de julio de 2016, 20:16:04 (UTC-4), Sheehan Olver 
>>> escribió:

 I'm doing the following:


 immutable FooIterator{d} end

 Base.start(::FooIterator{d}) = tuple(zeros(Int,d)...)::NTuple{d,Int}

>>>
>>>
>>> You can use the `ntuple` function, which constructs a tuple from a 
>>> function:
>>>
>>> julia> ntuple( x -> 0, 3)
>>> (0,0,0)
>>>
>>> julia> typeof(ans)
>>> Tuple{Int64,Int64,Int64}
>>>  
>>>


 But is there a more elegant way of getting the type inferred?  I 
 suppose I can override low order d directly:

 Base.start(::FooIterator{2}) = (0,0)
 Base.start(::FooIterator{3}) = (0,0,0)

>>>

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Steven Sagaert]

When I say "work well together" I don't just mean that their versions 
technically work together without errors, but also that they match 
stylistically and that the datastructures that they expect as input/output 
match so that no excessive translation and/or copying of data is needed 
which is bad for performance and style.  That kind of discussion is for 
example happening in OCAML to come to a platform and how to resolve the 
ocaml standard lib vs Jane street lib schism.

On Monday, August 1, 2016 at 5:19:17 PM UTC+2, Steven Sagaert wrote:
>
> I think the most important part of it is the idea of having a second 
> (beyond the standard lib that comes with the runtime) larger, optional 
> layer of curated libs that are known to work together. That together with 
> the metapackage idea for easy inclusion ( maybe with possible overrides as 
> in the Rust proposal) would be very handy for people who do not do Julia 
> coding all the time and hence cannot follow the larger package ecosystem 
> closely. People who do not want this second layer could still just use the 
> standard lib + whatever packages they want. One could even extend this to 
> multiple layer, each one more optional and lighter curated: standard lib -> 
> platform light -> extended paltform -> ...
>
> Now there is already a good attempt in the julia ecosystem to group 
> related packages in webpages and try to avoid too much libraries that do 
> the same or partially overlap (more like scientific Python, rather than the 
> R jungle) and that's great, but per group there still  are several 
> competing packages and sometimes it's unclear from the descriptions to pick 
> a clear winner. A curated subset of these "the platform"  by the community 
> that adrresses the most common needs except maybe for special niches, would 
> be very helpful. That's all :)
>
> On Monday, August 1, 2016 at 4:33:24 PM UTC+2, Stefan Karpinski wrote:
>>
>> There's a fair amount of discussion of the Rust Platform proposal over 
>> here:
>>
>> https://internals.rust-lang.org/t/proposal-the-rust-platform/3745
>>
>> In short there's a lack of agreement to this in Rust. Moreover, in Rust, 
>> different versions of libraries are much more closely locked to each other, 
>> whereas in Julia the coupling is much looser. Steven, since you're in favor 
>> of this idea, can you explain why you think it's a good idea for Julia? 
>> What problems does it solve?
>>
>> On Mon, Aug 1, 2016 at 7:31 AM, Tony Kelman  wrote:
>>
>>> The vision I personally have for this would be something more like SUSE 
>>> Studio (https://susestudio.com/) where it's just a few clicks, or a 
>>> configuration file in the build system, that could give you a set of 
>>> default-installed packages of your choosing, and make installers for your 
>>> own custom "spins" of a Julia-with-packages distribution.
>>>
>>>
>>>
>>> On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote:

 module MyMetaPackage 

 using Reexport 

 @reexport using PackageA 
 @reexport using PackageB 
 ... 

 end 

 Best. 
 --Tim 

 On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote: 
 > is more than just a webpage with a list of packages... for starters 
 the 
 > concept of metapackage. 
 > 
 > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote: 
 > > Maybe you already know about it, but there is a curated list of 
 packages 
 > > at https://github.com/svaksha/Julia.jl 
 > > 
 > > On Mon, Aug 01 2016, Steven Sagaert wrote: 
 > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/ 



>>

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Daniel O'Malley]

I tried the Pkg.init("ssh://...") a couple different ways, but neither 
worked.

Pkg.init("ssh://g...@github.com:/JuliaLang/METADATA.jl.git")

gave GitError(Code:EINVALIDSPEC, Class:Net, Malformed URL 
'ssh://g...@github.com:/JuliaLang/METADATA.jl.git').

Pkg.init("ssh://g...@github.com/JuliaLang/METADATA.jl.git")

asked me about my ssh keys then resulted in an authentication failure. If I 
were to get Pkg.init() working in this way, Pkg.add and other Pkg functions 
would still have problems though, right?

On Monday, August 1, 2016 at 9:09:22 AM UTC-6, Tony Kelman wrote:
>
> That could be considered a bug, Pkg.init should probably respect the 
> Pkg.setprotocol! setting, at least when using the DEFAULT_META value. You 
> should also be able to do Pkg.init("ssh://g...@github.com:/
> JuliaLang/METADATA.jl.git") as a workaround to avoid having to go through 
> command-line git.
>
>
> On Monday, August 1, 2016 at 7:01:51 AM UTC-7, Daniel O'Malley wrote:
>>
>> Oh, sorry for the mixup. Doing a
>>
>> git clone ssh://g...@github.com:/JuliaLang/METADATA.jl.git
>>
>> from a shell succeeds. I haven't had success trying to change the 
>> protocol with Pkg.setprotocol! though. Whether I do 
>> Pkg.setprotocol!("ssh"), Pkg.setprotocol!("git"), or 
>> Pkg.setprotocol!("notaprotocol"), Pkg.init() seems to always try to clone 
>> via https.
>>
>> On Sunday, July 31, 2016 at 10:31:38 PM UTC-6, Tony Kelman wrote:
>>>
>>> No, I meant ssh:// or git:// url's for packages.
>>>
>>>
>>> On Sunday, July 31, 2016 at 7:02:15 PM UTC-7, Daniel O'Malley wrote:

 Tony, thanks for the quick response and all the work you put into 
 julia. It would be great to have the package system working for Mac/Linux 
 from behind a proxy without needing to rebuild anything. If you need 
 someone to help test from behind a proxy, please let me know. I'd be happy 
 to do it.

 When you say "ssh remotes", do you mean something like 
 addprocs(["machine1", "machine2"])? That does work for me, but I haven't 
 tried addprocs'ing to a machine outside our network.

 On Sunday, July 31, 2016 at 6:12:12 PM UTC-6, Tony Kelman wrote:
>
> I believe you need to build libgit2 against libcurl in order for 
> proxies to work on linux and mac. We do not currently have it set up in 
> our 
> build system to do that in a self contained distributable way for 
> binaries, 
> but it might not be too hard to write the necessary makefile to make it 
> work.
>
> We were prioritizing getting ssh remotes to work again for the first 
> rc. Do ssh remotes work over proxies by any chance? I don't currently 
> have 
> immediate access to an environment behind a proxy to test this, but we 
> had 
> looked into setting one up that we could revisit.
>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Oliver Schulz]

Thanks, Pablo. Uh, do you think that PR will make it into 0.5?

On Monday, August 1, 2016 at 3:41:23 PM UTC+2, Pablo Zubieta wrote:
>
> This should work if https://github.com/JuliaLang/julia/pull/17389 gets 
> merged.
>
> On Monday, August 1, 2016 at 3:06:36 PM UTC+2, Oliver Schulz wrote:
>>
>> > Not before the bug is fixed and this is also orthogonal to loop fusion. 
>>
>> Sure, I get that. But that means then that bug is fixed, things like 
>> broadcasting with (e.g.) muladd will be possible again? That would be 
>> wonderful!
>>
>>
>>
>> On Monday, August 1, 2016 at 2:47:44 PM UTC+2, Yichao Yu wrote:
>>>
>>> On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz 
>>>  wrote: 
>>> > So cases like 
>>> > 
>>> > broadcast((x,y,z)->..., A, B, C) 
>>> > 
>>> > can't be supported any longer? Darn. :-( I love the things you guys 
>>> are 
>>> > doing in regard to fusing operations, but that was a very, very useful 
>>> thing 
>>> > to have. Is there any other way to do this now? 
>>>
>>> Not before the bug is fixed and this is also orthogonal to loop fusion. 
>>>
>>> > 
>>> > On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote: 
>>> >> 
>>> >> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz 
>>> >>  wrote: 
>>> >> > Hi, 
>>> >> > 
>>> >> > sorry if this is already covered somewhere - have the semantics of 
>>> >> > broadcast 
>>> >> > changed in Julia 0.5? 
>>> >> 
>>> >> Essentially https://github.com/JuliaLang/julia/issues/17314 
>>> >> The promote_op basically assumes everything is a pure unary or binary 
>>> >> operator. 
>>> >> 
>>> >> > 
>>> >> > In 0.4, I can do 
>>> >> > 
>>> >> > broadcast(muladd, rand(5), rand(5), rand(5)) 
>>> >> > 
>>> >> > But in 0.5 (0.5.0-rc0+86), I get 
>>> >> > 
>>> >> > ERROR: MethodError: no method matching muladd(::Float64, ::Float64) 
>>> >> > Closest candidates are: 
>>> >> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247 
>>> >> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177 
>>> >> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at 
>>> >> > promotion.jl:239 
>>> >> >   ... 
>>> >> > [...] 
>>> >> > 
>>> >> > 
>>> >> > Is this a bug, or to be expected? 
>>> >> > 
>>> >> > Cheers, 
>>> >> > 
>>> >> > Oliver 
>>> >> > 
>>>
>>

[julia-users] Re: web scraping with Julia

[Alex Mellnik]

Ivan,

What sort of contents do you need to get?  For simple things Requests.jl 
may work, but for more complex scrapes I would suggest using Selenium.  You 
can install the Python package and call it with something like 

using PyCall
@pyimport selenium.webdriver as webdriver
driver = webdriver.Firefox()
driver["get"]("http://something.net/blah/index.js;)
contents = string(driver["page_source"])
driver["quit"]()

This is a pretty simple example, but you should have a lot more flexibility 
going forward.  

-Alex


On Sunday, July 31, 2016 at 3:23:07 PM UTC-7, Ivan Pandžić wrote:
>
> Hey, guys, I have already searched a lot online, but can't seem to get 
> anything working. I have tried LibCURL.jl, Requests.jl and HTTPClient.jl. 
> Basically, what I need is something that allows me to get the contents of a 
> website. What's the best way?
>
> Thanks!
>
> Ivan
>

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Steven Sagaert]

I think the most important part of it is the idea of having a second 
(beyond the standard lib that comes with the runtime) larger, optional 
layer of curated libs that are known to work together. That together with 
the metapackage idea for easy inclusion ( maybe with possible overrides as 
in the Rust proposal) would be very handy for people who do not do Julia 
coding all the time and hence cannot follow the larger package ecosystem 
closely. People who do not want this second layer could still just use the 
standard lib + whatever packages they want. One could even extend this to 
multiple layer, each one more optional and lighter curated: standard lib -> 
platform light -> extended paltform -> ...

Now there is already a good attempt in the julia ecosystem to group related 
packages in webpages and try to avoid too much libraries that do the same 
or partially overlap (more like scientific Python, rather than the R 
jungle) and that's great, but per group there still  are several competing 
packages and sometimes it's unclear from the descriptions to pick a clear 
winner. A curated subset of these "the platform"  by the community that 
adrresses the most common needs except maybe for special niches, would be 
very helpful. That's all :)

On Monday, August 1, 2016 at 4:33:24 PM UTC+2, Stefan Karpinski wrote:
>
> There's a fair amount of discussion of the Rust Platform proposal over 
> here:
>
> https://internals.rust-lang.org/t/proposal-the-rust-platform/3745
>
> In short there's a lack of agreement to this in Rust. Moreover, in Rust, 
> different versions of libraries are much more closely locked to each other, 
> whereas in Julia the coupling is much looser. Steven, since you're in favor 
> of this idea, can you explain why you think it's a good idea for Julia? 
> What problems does it solve?
>
> On Mon, Aug 1, 2016 at 7:31 AM, Tony Kelman  > wrote:
>
>> The vision I personally have for this would be something more like SUSE 
>> Studio (https://susestudio.com/) where it's just a few clicks, or a 
>> configuration file in the build system, that could give you a set of 
>> default-installed packages of your choosing, and make installers for your 
>> own custom "spins" of a Julia-with-packages distribution.
>>
>>
>>
>> On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote:
>>>
>>> module MyMetaPackage 
>>>
>>> using Reexport 
>>>
>>> @reexport using PackageA 
>>> @reexport using PackageB 
>>> ... 
>>>
>>> end 
>>>
>>> Best. 
>>> --Tim 
>>>
>>> On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote: 
>>> > is more than just a webpage with a list of packages... for starters 
>>> the 
>>> > concept of metapackage. 
>>> > 
>>> > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote: 
>>> > > Maybe you already know about it, but there is a curated list of 
>>> packages 
>>> > > at https://github.com/svaksha/Julia.jl 
>>> > > 
>>> > > On Mon, Aug 01 2016, Steven Sagaert wrote: 
>>> > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/ 
>>>
>>>
>>>
>

[julia-users] Re: How to make a variable length tuple with inferred type

[mmh]

Is this a known bug/regression?

On Sunday, July 31, 2016 at 10:53:11 PM UTC-4, Sheehan Olver wrote:
>
> It still doesn't infer the type in 0.5:
>
> *julia> **@code_warntype ntuple( x -> 0, 3)*
>
> Variables:
>
>   #self#::Base.#ntuple
>
>   f::##5#6
>
>   n::Int64
>
>
> Body:
>
>   begin 
>
>   unless (Base.sle_int)(n::Int64,0)::Bool goto 3
>
>   return (Core.tuple)()::Tuple{}
>
>   3: 
>
>   unless (n::Int64 === 1)::Bool goto 6
>
>   return (Core.tuple)($(QuoteNode(0)))::Tuple{Int64}
>
>   6: 
>
>   unless (n::Int64 === 2)::Bool goto 9
>
>   return 
> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64}
>
>   9: 
>
>   unless (n::Int64 === 3)::Bool goto 12
>
>   return 
> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64}
>
>   12: 
>
>   unless (n::Int64 === 4)::Bool goto 15
>
>   return 
> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64}
>
>   15: 
>
>   unless (n::Int64 === 5)::Bool goto 18
>
>   return 
> (Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64,Int64}
>
>   18: 
>
>   unless (Base.slt_int)(n::Int64,16)::Bool goto 21
>
>   return (Core._apply)(Core.tuple,$(Expr(:invoke, LambdaInfo for 
> ntuple(::##5#6, ::Int64), :(Base.ntuple), :(f), 
> :((Base.box)(Int64,(Base.sub_int)(n,5),(Core.tuple)($(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64,Int64,Int64})
> *::Tuple{Vararg{Any,N}}*
>
>   21: 
>
>   return $(Expr(:invoke, LambdaInfo for _ntuple(::Function, ::Int64), 
> :(Base._ntuple), :(f), :(n)))
>
>   end*::Tuple*
>
> On Monday, August 1, 2016 at 10:34:30 AM UTC+10, David P. Sanders wrote:
>>
>>
>>
>> El domingo, 31 de julio de 2016, 20:16:04 (UTC-4), Sheehan Olver escribió:
>>>
>>> I'm doing the following:
>>>
>>>
>>> immutable FooIterator{d} end
>>>
>>> Base.start(::FooIterator{d}) = tuple(zeros(Int,d)...)::NTuple{d,Int}
>>>
>>
>>
>> You can use the `ntuple` function, which constructs a tuple from a 
>> function:
>>
>> julia> ntuple( x -> 0, 3)
>> (0,0,0)
>>
>> julia> typeof(ans)
>> Tuple{Int64,Int64,Int64}
>>  
>>
>>>
>>>
>>> But is there a more elegant way of getting the type inferred?  I suppose 
>>> I can override low order d directly:
>>>
>>> Base.start(::FooIterator{2}) = (0,0)
>>> Base.start(::FooIterator{3}) = (0,0,0)
>>>
>>

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Tony Kelman]

That could be considered a bug, Pkg.init should probably respect the 
Pkg.setprotocol! setting, at least when using the DEFAULT_META value. You 
should also be able to do Pkg.init("ssh://g...@github.com:/
JuliaLang/METADATA.jl.git") as a workaround to avoid having to go through 
command-line git.


On Monday, August 1, 2016 at 7:01:51 AM UTC-7, Daniel O'Malley wrote:
>
> Oh, sorry for the mixup. Doing a
>
> git clone ssh://g...@github.com:/JuliaLang/METADATA.jl.git
>
> from a shell succeeds. I haven't had success trying to change the protocol 
> with Pkg.setprotocol! though. Whether I do Pkg.setprotocol!("ssh"), 
> Pkg.setprotocol!("git"), or Pkg.setprotocol!("notaprotocol"), Pkg.init() 
> seems to always try to clone via https.
>
> On Sunday, July 31, 2016 at 10:31:38 PM UTC-6, Tony Kelman wrote:
>>
>> No, I meant ssh:// or git:// url's for packages.
>>
>>
>> On Sunday, July 31, 2016 at 7:02:15 PM UTC-7, Daniel O'Malley wrote:
>>>
>>> Tony, thanks for the quick response and all the work you put into julia. 
>>> It would be great to have the package system working for Mac/Linux from 
>>> behind a proxy without needing to rebuild anything. If you need someone to 
>>> help test from behind a proxy, please let me know. I'd be happy to do it.
>>>
>>> When you say "ssh remotes", do you mean something like 
>>> addprocs(["machine1", "machine2"])? That does work for me, but I haven't 
>>> tried addprocs'ing to a machine outside our network.
>>>
>>> On Sunday, July 31, 2016 at 6:12:12 PM UTC-6, Tony Kelman wrote:

 I believe you need to build libgit2 against libcurl in order for 
 proxies to work on linux and mac. We do not currently have it set up in 
 our 
 build system to do that in a self contained distributable way for 
 binaries, 
 but it might not be too hard to write the necessary makefile to make it 
 work.

 We were prioritizing getting ssh remotes to work again for the first 
 rc. Do ssh remotes work over proxies by any chance? I don't currently have 
 immediate access to an environment behind a proxy to test this, but we had 
 looked into setting one up that we could revisit.

>>>

Re: [julia-users] Re: Tuples of Functions

[Christoph Ortner]

thank you Kristoffer for the explanation and Yichao for pointing that 
package. I will give it a try; as I need it (or, would like to have it) in 
a very limited context, hopefully it will solve my problem.

[julia-users] ANN: DifferentialEquations.jl

[Chris Rackauckas]

I am pleased to announce the first release of DifferentialEquations.jl 
.

An accompanying blog post explains the motivation and philosophy of the 
package in more detail. 


DifferentialEquations.jl is a library of methods for solving various 
differential equations. DifferentialEquations.jl makes it easy to access 
many different methods for solving equations and plot the results. This 
v0.1 release marks that the core of DifferentialEquations.jl is complete, 
which includes:


   - The standard ODE, SDE, and PDE (Heat and Poisson) solvers 
   

   .
   - Plot recipes for all the basic types.
   - Tests for convergence of every algorithm.
   - Extensive documentation 
   and 
   tutorials 
   

   .

DifferentialEquations.jl also has many special features not seen in other 
differential equation libraries, which includes (but is not limited to):


   - A simple interface via multiple-dispatch (see the blog post 
   
   ).
   - Implementations of Feagin's Order 10, 12, and 14 Runge-Kutta methods 
   

   .
   - Compatibility with Julia-defined number types 
   
.
 This 
   has been tested to work with Bigs, DecFP, and ArbFloats, and is actively 
   being tested with ArbReals and DoubleDouble.
   - Wrappers to ODE.jl and ODEInterface.jl 
   
,
 
   giving you instant access to tons of different solver methods just by 
   changing the `alg` keyword.
   - State-of-the-art stochastic differential equation solvers 
   
.
 Implemented 
   are results from recent papers, and many other algorithms (including fast 
   adaptivity and highly-stable explicit methods) are waiting on a private 
   branch until papers are published.
   - Finite element solvers for some common stochastic PDEs 
   

 including 
   the Reaction-Diffusion equation used to describe Turing Morphogenesis 
   

   .
   - An algorithm design and testing suite 
   

   .
   
For more information, check out the documentation 
or the 
IJulia 
tutorial notebooks 
.
 If 
you're interested in contributing, please see the Contributor's Guide 

 
and/or chat with me on the Gitter channel 
.

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Stefan Karpinski]

There's a fair amount of discussion of the Rust Platform proposal over here:

https://internals.rust-lang.org/t/proposal-the-rust-platform/3745

In short there's a lack of agreement to this in Rust. Moreover, in Rust,
different versions of libraries are much more closely locked to each other,
whereas in Julia the coupling is much looser. Steven, since you're in favor
of this idea, can you explain why you think it's a good idea for Julia?
What problems does it solve?

On Mon, Aug 1, 2016 at 7:31 AM, Tony Kelman  wrote:

> The vision I personally have for this would be something more like SUSE
> Studio (https://susestudio.com/) where it's just a few clicks, or a
> configuration file in the build system, that could give you a set of
> default-installed packages of your choosing, and make installers for your
> own custom "spins" of a Julia-with-packages distribution.
>
>
>
> On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote:
>>
>> module MyMetaPackage
>>
>> using Reexport
>>
>> @reexport using PackageA
>> @reexport using PackageB
>> ...
>>
>> end
>>
>> Best.
>> --Tim
>>
>> On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote:
>> > is more than just a webpage with a list of packages... for starters the
>> > concept of metapackage.
>> >
>> > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote:
>> > > Maybe you already know about it, but there is a curated list of
>> packages
>> > > at https://github.com/svaksha/Julia.jl
>> > >
>> > > On Mon, Aug 01 2016, Steven Sagaert wrote:
>> > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/
>>
>>
>>

[julia-users] Embedding Multiple Indipendent Julia Intreperters within a C++ Program

[Akila Wajirasena]

Hi All,

I am working on integrating julia to our software where we will have 
multiple threads (p_threads) within our program.
We need to create multiple independent julia interpreters; one for each 
thread and let them work independently.

I have found following answers in the users groups and they are 
contradictory;

And multiple julia environments are currently not possible.

https://groups.google.com/d/msg/julia-users/9rr5H_qZfKg/iNl2_rpwo_0J   


With this answer from Stefan

It may, however, be easier to have multiple independent Julia interpreters 
> in a single process with separate Julia Core/Base/Main modules. If the 
> interpreters are going to be in different threads, there would have to be 
> locks around access to mutable global structures, but that might be ok. 
> Unlike, say Python, there's no interpreter, so there would be no GIL – once 
> code is generated, it can freely execute without different threads blocking 
> each other. That would actually be a rather interesting project.


https://groups.google.com/d/msg/julia-users/PSdfGfI3eyc/ni6FgzCDvCUJ


What is the correct answers to this problem. 

Also I found that julia supports multi threading as of now according to 
this github issue 
https://github.com/JuliaLang/julia/issues/1790

Does this invalidates the previous answers given in 2014.

Thanks & Regards,

Akila

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Daniel O'Malley]

Oh, sorry for the mixup. Doing a

git clone ssh://g...@github.com:/JuliaLang/METADATA.jl.git

from a shell succeeds. I haven't had success trying to change the protocol 
with Pkg.setprotocol! though. Whether I do Pkg.setprotocol!("ssh"), 
Pkg.setprotocol!("git"), or Pkg.setprotocol!("notaprotocol"), Pkg.init() 
seems to always try to clone via https.

On Sunday, July 31, 2016 at 10:31:38 PM UTC-6, Tony Kelman wrote:
>
> No, I meant ssh:// or git:// url's for packages.
>
>
> On Sunday, July 31, 2016 at 7:02:15 PM UTC-7, Daniel O'Malley wrote:
>>
>> Tony, thanks for the quick response and all the work you put into julia. 
>> It would be great to have the package system working for Mac/Linux from 
>> behind a proxy without needing to rebuild anything. If you need someone to 
>> help test from behind a proxy, please let me know. I'd be happy to do it.
>>
>> When you say "ssh remotes", do you mean something like 
>> addprocs(["machine1", "machine2"])? That does work for me, but I haven't 
>> tried addprocs'ing to a machine outside our network.
>>
>> On Sunday, July 31, 2016 at 6:12:12 PM UTC-6, Tony Kelman wrote:
>>>
>>> I believe you need to build libgit2 against libcurl in order for proxies 
>>> to work on linux and mac. We do not currently have it set up in our build 
>>> system to do that in a self contained distributable way for binaries, but 
>>> it might not be too hard to write the necessary makefile to make it work.
>>>
>>> We were prioritizing getting ssh remotes to work again for the first rc. 
>>> Do ssh remotes work over proxies by any chance? I don't currently have 
>>> immediate access to an environment behind a proxy to test this, but we had 
>>> looked into setting one up that we could revisit.
>>>
>>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Pablo Zubieta]

This should work if https://github.com/JuliaLang/julia/pull/17389 gets 
merged.

On Monday, August 1, 2016 at 3:06:36 PM UTC+2, Oliver Schulz wrote:
>
> > Not before the bug is fixed and this is also orthogonal to loop fusion. 
>
> Sure, I get that. But that means then that bug is fixed, things like 
> broadcasting with (e.g.) muladd will be possible again? That would be 
> wonderful!
>
>
>
> On Monday, August 1, 2016 at 2:47:44 PM UTC+2, Yichao Yu wrote:
>>
>> On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz 
>>  wrote: 
>> > So cases like 
>> > 
>> > broadcast((x,y,z)->..., A, B, C) 
>> > 
>> > can't be supported any longer? Darn. :-( I love the things you guys are 
>> > doing in regard to fusing operations, but that was a very, very useful 
>> thing 
>> > to have. Is there any other way to do this now? 
>>
>> Not before the bug is fixed and this is also orthogonal to loop fusion. 
>>
>> > 
>> > On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote: 
>> >> 
>> >> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz 
>> >>  wrote: 
>> >> > Hi, 
>> >> > 
>> >> > sorry if this is already covered somewhere - have the semantics of 
>> >> > broadcast 
>> >> > changed in Julia 0.5? 
>> >> 
>> >> Essentially https://github.com/JuliaLang/julia/issues/17314 
>> >> The promote_op basically assumes everything is a pure unary or binary 
>> >> operator. 
>> >> 
>> >> > 
>> >> > In 0.4, I can do 
>> >> > 
>> >> > broadcast(muladd, rand(5), rand(5), rand(5)) 
>> >> > 
>> >> > But in 0.5 (0.5.0-rc0+86), I get 
>> >> > 
>> >> > ERROR: MethodError: no method matching muladd(::Float64, ::Float64) 
>> >> > Closest candidates are: 
>> >> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247 
>> >> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177 
>> >> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at 
>> >> > promotion.jl:239 
>> >> >   ... 
>> >> > [...] 
>> >> > 
>> >> > 
>> >> > Is this a bug, or to be expected? 
>> >> > 
>> >> > Cheers, 
>> >> > 
>> >> > Oliver 
>> >> > 
>>
>

[julia-users] How to set JULIA_NUM_THREADS for remote workers?

[Oliver Schulz]

Is it possible to pass on or explicitly set JULIA_NUM_THREADS for remote 
workers started via

addprocs([host1, ...])

?

Re: [julia-users] Re: Interactive Animated PyPlot in IJulia

[Christoph Ortner]

Just played with the examples in GR.jl/examples. Works really well. Thank 
you!


On Saturday, 30 July 2016 16:25:44 UTC+1, Josef Heinen wrote:
>
> The first animation (slide 10) updates a 3d surface frame by frame - the 
> noise added could also be the result of an intensive calculation or a 
> real-time signal. There is a demo in the GR example section showing a 3d 
> power spectrum calculated from the microphone audio input ...
>
> On Saturday, July 30, 2016 at 11:12:43 AM UTC+2, Thomas Hudson wrote:
>>
>> This isn't quite what I want: as with the discussion above, while 
>> the example code has a sequence of predetermined graphs to be plotted, what 
>> I'm really interested in is plotting the results of a more 
>> intensive calculation frame by frame as it runs, rather than doing the 
>> calculation of the entire trajectory, and plotting a manipulable plot after 
>> the fact.
>>
>> Nevertheless, it's useful to know that you can do some fancy plot 
>> manipulation in this way!
>>
>> On Saturday, 30 July 2016, Josef Heinen  wrote:
>>
>>> This 
>>> 
>>>  is 
>>> probably what you are looking for. If you need special Matplotlib features, 
>>> you can even mix GR and PyPlot (see slides 10 and 13 from my 
>>> 
>>>  SciPy 
>>> 2016 talk which demonstrate the performance and interoperability)
>>>
>>> On Friday, July 29, 2016 at 5:03:11 PM UTC+2, Christoph Ortner wrote:

 Thanks for figuring this out, Tom.  I'd also be interested in 
 a Reactive and Interact solution.

>>>
>>>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Oliver Schulz]

> Not before the bug is fixed and this is also orthogonal to loop fusion. 

Sure, I get that. But that means then that bug is fixed, things like 
broadcasting with (e.g.) muladd will be possible again? That would be 
wonderful!



On Monday, August 1, 2016 at 2:47:44 PM UTC+2, Yichao Yu wrote:
>
> On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz 
>  wrote: 
> > So cases like 
> > 
> > broadcast((x,y,z)->..., A, B, C) 
> > 
> > can't be supported any longer? Darn. :-( I love the things you guys are 
> > doing in regard to fusing operations, but that was a very, very useful 
> thing 
> > to have. Is there any other way to do this now? 
>
> Not before the bug is fixed and this is also orthogonal to loop fusion. 
>
> > 
> > On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote: 
> >> 
> >> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz 
> >>  wrote: 
> >> > Hi, 
> >> > 
> >> > sorry if this is already covered somewhere - have the semantics of 
> >> > broadcast 
> >> > changed in Julia 0.5? 
> >> 
> >> Essentially https://github.com/JuliaLang/julia/issues/17314 
> >> The promote_op basically assumes everything is a pure unary or binary 
> >> operator. 
> >> 
> >> > 
> >> > In 0.4, I can do 
> >> > 
> >> > broadcast(muladd, rand(5), rand(5), rand(5)) 
> >> > 
> >> > But in 0.5 (0.5.0-rc0+86), I get 
> >> > 
> >> > ERROR: MethodError: no method matching muladd(::Float64, ::Float64) 
> >> > Closest candidates are: 
> >> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247 
> >> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177 
> >> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at 
> >> > promotion.jl:239 
> >> >   ... 
> >> > [...] 
> >> > 
> >> > 
> >> > Is this a bug, or to be expected? 
> >> > 
> >> > Cheers, 
> >> > 
> >> > Oliver 
> >> > 
>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Yichao Yu]

On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz
 wrote:
> So cases like
>
> broadcast((x,y,z)->..., A, B, C)
>
> can't be supported any longer? Darn. :-( I love the things you guys are
> doing in regard to fusing operations, but that was a very, very useful thing
> to have. Is there any other way to do this now?

Not before the bug is fixed and this is also orthogonal to loop fusion.

>
> On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote:
>>
>> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz
>>  wrote:
>> > Hi,
>> >
>> > sorry if this is already covered somewhere - have the semantics of
>> > broadcast
>> > changed in Julia 0.5?
>>
>> Essentially https://github.com/JuliaLang/julia/issues/17314
>> The promote_op basically assumes everything is a pure unary or binary
>> operator.
>>
>> >
>> > In 0.4, I can do
>> >
>> > broadcast(muladd, rand(5), rand(5), rand(5))
>> >
>> > But in 0.5 (0.5.0-rc0+86), I get
>> >
>> > ERROR: MethodError: no method matching muladd(::Float64, ::Float64)
>> > Closest candidates are:
>> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247
>> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177
>> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at
>> > promotion.jl:239
>> >   ...
>> > [...]
>> >
>> >
>> > Is this a bug, or to be expected?
>> >
>> > Cheers,
>> >
>> > Oliver
>> >

Re: [julia-users] Changed broadcast semantics in 0.5?

[Oliver Schulz]

So cases like

broadcast((x,y,z)->..., A, B, C)

can't be supported any longer? Darn. :-( I love the things you guys are 
doing in regard to fusing operations, but that was a very, very useful 
thing to have. Is there any other way to do this now?

On Monday, August 1, 2016 at 2:22:07 PM UTC+2, Yichao Yu wrote:
>
> On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz 
>  wrote: 
> > Hi, 
> > 
> > sorry if this is already covered somewhere - have the semantics of 
> broadcast 
> > changed in Julia 0.5? 
>
> Essentially https://github.com/JuliaLang/julia/issues/17314 
> The promote_op basically assumes everything is a pure unary or binary 
> operator. 
>
> > 
> > In 0.4, I can do 
> > 
> > broadcast(muladd, rand(5), rand(5), rand(5)) 
> > 
> > But in 0.5 (0.5.0-rc0+86), I get 
> > 
> > ERROR: MethodError: no method matching muladd(::Float64, ::Float64) 
> > Closest candidates are: 
> >   muladd(::Float64, ::Float64, ::Float64) at float.jl:247 
> >   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177 
> >   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at 
> > promotion.jl:239 
> >   ... 
> > [...] 
> > 
> > 
> > Is this a bug, or to be expected? 
> > 
> > Cheers, 
> > 
> > Oliver 
> > 
>

Re: [julia-users] Changed broadcast semantics in 0.5?

[Yichao Yu]

On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz
 wrote:
> Hi,
>
> sorry if this is already covered somewhere - have the semantics of broadcast
> changed in Julia 0.5?

Essentially https://github.com/JuliaLang/julia/issues/17314
The promote_op basically assumes everything is a pure unary or binary operator.

>
> In 0.4, I can do
>
> broadcast(muladd, rand(5), rand(5), rand(5))
>
> But in 0.5 (0.5.0-rc0+86), I get
>
> ERROR: MethodError: no method matching muladd(::Float64, ::Float64)
> Closest candidates are:
>   muladd(::Float64, ::Float64, ::Float64) at float.jl:247
>   muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177
>   muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at
> promotion.jl:239
>   ...
> [...]
>
>
> Is this a bug, or to be expected?
>
> Cheers,
>
> Oliver
>

[julia-users] Changed broadcast semantics in 0.5?

[Oliver Schulz]

Hi,

sorry if this is already covered somewhere - have the semantics of 
broadcast changed in Julia 0.5?

In 0.4, I can do

broadcast(muladd, rand(5), rand(5), rand(5))

But in 0.5 (0.5.0-rc0+86), I get

ERROR: MethodError: no method matching muladd(::Float64, ::Float64)
Closest candidates are:
  muladd(::Float64, ::Float64, ::Float64) at float.jl:247
  muladd(::Real, ::Real, ::Complex{T<:Real}) at complex.jl:177
  muladd{T<:Number}(::T<:Number, ::T<:Number, ::T<:Number) at promotion.jl:
239
  ...
[...]


Is this a bug, or to be expected?

Cheers,

Oliver

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Tony Kelman]

The vision I personally have for this would be something more like SUSE 
Studio (https://susestudio.com/) where it's just a few clicks, or a 
configuration file in the build system, that could give you a set of 
default-installed packages of your choosing, and make installers for your 
own custom "spins" of a Julia-with-packages distribution.


On Monday, August 1, 2016 at 2:08:06 AM UTC-7, Tim Holy wrote:
>
> module MyMetaPackage 
>
> using Reexport 
>
> @reexport using PackageA 
> @reexport using PackageB 
> ... 
>
> end 
>
> Best. 
> --Tim 
>
> On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote: 
> > is more than just a webpage with a list of packages... for starters the 
> > concept of metapackage. 
> > 
> > On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote: 
> > > Maybe you already know about it, but there is a curated list of 
> packages 
> > > at https://github.com/svaksha/Julia.jl 
> > > 
> > > On Mon, Aug 01 2016, Steven Sagaert wrote: 
> > > > see https://aturon.github.io/blog/2016/07/27/rust-platform/ 
>
>
>

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Tony Kelman]

You can use Pkg.setprotocol!("https"). On Windows libgit2 and libssh2 
should be linking against the built-in native winhttp backend and they 
might not need libcurl for proxy support there, but I don't know how to 
configure them for proxy support. This is going to require some testing, 
investigation, and figuring out what does and does not work. See 
https://github.com/JuliaLang/julia/issues/13472#issuecomment-202568599 
where at least one person reports winhttp "should be fine."


On Monday, August 1, 2016 at 1:35:28 AM UTC-7, Andreas Lobinger wrote:
>
> So do i understand correctly that the current win64 build doesn't include 
> git/ssh via proxy? Or is just the setting in (where?) missing? Is there a 
> counterpart to the https-insteadof-git setting available?
> I know it's not helpful, but i get (behind a company http/https proxy) the 
> same error with Pkg.init() (which is in comparision to other RC0 issues a 
> showstopper).
>
>

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Tim Holy]

module MyMetaPackage

using Reexport

@reexport using PackageA
@reexport using PackageB
...

end

Best.
--Tim

On Monday, August 1, 2016 1:48:47 AM CDT Steven Sagaert wrote:
> is more than just a webpage with a list of packages... for starters the
> concept of metapackage.
> 
> On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote:
> > Maybe you already know about it, but there is a curated list of packages
> > at https://github.com/svaksha/Julia.jl
> > 
> > On Mon, Aug 01 2016, Steven Sagaert wrote:
> > > see https://aturon.github.io/blog/2016/07/27/rust-platform/

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Steven Sagaert]

is more than just a webpage with a list of packages... for starters the 
concept of metapackage.

On Monday, August 1, 2016 at 10:25:33 AM UTC+2, Tamas Papp wrote:
>
> Maybe you already know about it, but there is a curated list of packages 
> at https://github.com/svaksha/Julia.jl 
>
> On Mon, Aug 01 2016, Steven Sagaert wrote: 
>
> > see https://aturon.github.io/blog/2016/07/27/rust-platform/ 
>
>

Re: [julia-users] Re: A Very Simple Benchmark for Brutal-force Loops in Several Languages: revised, Julia is fast!

[Sisyphuss]

Julia is not as "mature" as VBA, which prevents "analysts" of large firms 
adopting it.

In addition, they will be happier to continue using global variables.



On Monday, August 1, 2016 at 8:14:37 AM UTC+2, Eric Forgy wrote:
>
> I mentioned to Prof. Edelman (only half jokingly) at an event in 
> Singapore, that we should add Excel/VBA to the list of benchmarks. 
>
> If I'm in a corporate setting and trying to sell Julia for some internal 
> project, the person making the call has probably never heard of any of the 
> languages in the Julia benchmark, but they have heard of Excel/VBA, so, as 
> silly as it may seem, I actually think it could go a long way for Julia 
> evangelists to see more comparisons to Excel/VBA.
>
> On Monday, August 1, 2016 at 1:45:24 AM UTC+8, hustf wrote:
>>
>> It is nice to have a little check on speed from time to time. I still use 
>> VBA for easy cooperation with less programming savvy colleguaes.
>>
>> Julia 1.17s.
>> VBA (excel alt + f11):12 s.
>>
>> This is a bit unfair to neolithic man Joel Spolsky since no optimization 
>> was performed:
>>
>> Sub benchmark()
>> nsamples = 100
>> Dim y() As Double
>> ReDim y(1 To nsamples)
>> x = y
>> For i = 1 To nsamples
>> x(i) = (i - 1) * 5 / (nsamples - 1)
>> Next
>> Debug.Print ("\nBrutal-force loops, 100 times:")
>> sngtime = Timer
>> For m = 1 To 100
>> For n = 1 To nsamples
>> y(n) = Cos(2 * x(n) + 5)
>> Next
>> Next
>> Debug.Print Timer - sngtime
>> End Sub
>>
>>

[julia-users] Re: web scraping with Julia

[STAR0SS]

I used HTTPClient to get the page and Gumbo to parse it some time ago (near 
v0.3)

https://github.com/porterjamesj/Gumbo.jl

I was doing things like that, it's probably not the most elegant
way of doing it, but it was working fine:

function get_hrefs(body::HTMLElement)
links = String[]
for elem in preorder(body)
if typeof(elem) == HTMLElement{:a}
try
push!(links,getattr(elem, "href"))
catch
end
end
end
return links
end

[julia-users] Re: Pkg.init() problems on 0.5-rc0

[Andreas Lobinger]

So do i understand correctly that the current win64 build doesn't include 
git/ssh via proxy? Or is just the setting in (where?) missing? Is there a 
counterpart to the https-insteadof-git setting available?
I know it's not helpful, but i get (behind a company http/https proxy) the 
same error with Pkg.init() (which is in comparision to other RC0 issues a 
showstopper).

Re: [julia-users] Re: Tuples of Functions

[Yichao Yu]

On Mon, Aug 1, 2016 at 4:15 PM, Kristoffer Carlsson
 wrote:
> The problem is not with the return value of the passed functions, it is with
> inferring the type of `f`. Each function has it's own type and that in turn
> makes `f` bind to different types (first f1 then f2) in the loop i.e a type
> instability.

Ref https://github.com/JuliaLang/julia/issues/13984 and a proof of
principle implementation at
https://github.com/yuyichao/FunctionWrappers.jl that I wrote a few
days ago. Note that the package is mainly an experiment to check what
features are needed and I'm not planing to register it.

>
>
> On Monday, August 1, 2016 at 5:53:23 AM UTC+2, Christoph Ortner wrote:
>>
>> Consider the following code snippet which shows the following expect
>> problem (on v0.5): if I form a tuple of functions, pass this tuple to
>> another function, then julia cannot infer enough information about them and
>> runs into a type instability.
>>
>> MY QUESTION is: is there a work-around?  I.e., can I form an array, tuple,
>> etc of functions and call them without losing type stability?
>>
>> (declaring return-type did not help, which surprised me since I thought
>> that would give the additional information about what the two functions f1,
>> f2 in the tuple do)
>>
>>
>> function test(N, ff)
>> r = 0.234; s = 0.0
>> for n = 1:N, f in ff
>> s = s + f(r)::Float64
>> end
>> return s
>> end
>>
>>
>> function test2(N, f1, f2)
>> r = 0.234; s = 0.0
>> for n = 1:N
>> s = s + f1(r) + f2(r)
>> end
>> return s
>> end
>>
>>
>> f1(r::Float64)::Float64 = r^3
>> f2(r::Float64)::Float64 = r^5
>>
>>
>> test(10, (f1,f2))
>> test(10, (f1,f1))
>> test2(10, f1,f2)
>>
>>
>> @time test(1_000_000, (f1,f2))# 0.079190 seconds (4.00 M
>> allocations...
>> @time test2(1_000_000, f1, f2)# 0.002279 seconds (5 allocations: 176
>> bytes)
>> @time test(1_000_000, (f1,f1))# 0.002664 seconds (5 allocations: 176
>> bytes)
>>
>>
>>
>

[julia-users] Re: I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Andreas Lobinger]

My first reaction was: Just go forward and do it. Then i started to read 
the comments in
https://internals.rust-lang.org/t/proposal-the-rust-platform/3745/35

Re: [julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Tamas Papp]

Maybe you already know about it, but there is a curated list of packages
at https://github.com/svaksha/Julia.jl

On Mon, Aug 01 2016, Steven Sagaert wrote:

> see https://aturon.github.io/blog/2016/07/27/rust-platform/

[julia-users] Re: Tuples of Functions

[Kristoffer Carlsson]

The problem is not with the return value of the passed functions, it is 
with inferring the type of `f`. Each function has it's own type and that in 
turn makes `f` bind to different types (first f1 then f2) in the loop i.e a 
type instability.


On Monday, August 1, 2016 at 5:53:23 AM UTC+2, Christoph Ortner wrote:
>
> Consider the following code snippet which shows the following expect 
> problem (on v0.5): if I form a tuple of functions, pass this tuple to 
> another function, then julia cannot infer enough information about them and 
> runs into a type instability. 
>
> MY QUESTION is: is there a work-around?  I.e., can I form an array, tuple, 
> etc of functions and call them without losing type stability?
>
> (declaring return-type did not help, which surprised me since I thought 
> that would give the additional information about what the two functions f1, 
> f2 in the tuple do)
>
>
> function test(N, ff)
> r = 0.234; s = 0.0
> for n = 1:N, f in ff
> s = s + f(r)::Float64
> end 
> return s
> end 
>
>
> function test2(N, f1, f2)
> r = 0.234; s = 0.0
> for n = 1:N
> s = s + f1(r) + f2(r)
> end 
> return s
> end 
>
>
> f1(r::Float64)::Float64 = r^3
> f2(r::Float64)::Float64 = r^5
>
>
> test(10, (f1,f2))
> test(10, (f1,f1))
> test2(10, f1,f2)
>
>
> @time test(1_000_000, (f1,f2))# 0.079190 seconds (4.00 M 
> allocations...
> @time test2(1_000_000, f1, f2)# 0.002279 seconds (5 allocations: 176 
> bytes)
> @time test(1_000_000, (f1,f1))# 0.002664 seconds (5 allocations: 176 
> bytes)
>
>
>
>

[julia-users] Re: Goto code

[Alexei Serdiuk]

Thanks!
>
>

[julia-users] I'd like to see something like the Rust platform proposal in the Julia ecosystem

[Steven Sagaert]

see https://aturon.github.io/blog/2016/07/27/rust-platform/

Re: [julia-users] Re: How to make a variable length tuple with inferred type

[Sheehan Olver]

Cool!

Sent from my iPhone

> On 1 Aug 2016, at 17:23, Simon Danisch  wrote:
> 
> How about:
> julia> @code_warntype ntuple( x -> 0, Val{3})
> Variables:
>   #self#::Base.#ntuple
>   f::##1#2
>   #unused#::Type{Val{3}}
> 
> Body:
>   begin
>   $(Expr(:static_parameter, 2)) # line 73:
>   # meta: location tuple.jl _ntuple 80
>   # meta: location tuple.jl _ntuple 80
>   SSAValue(1) = $(QuoteNode(0))
>   # meta: pop location
>   # meta: pop location
>   return 
> (Core.tuple)(SSAValue(1),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64}
>   end::Tuple{Int64,Int64,Int64}
> 
> Am Montag, 1. August 2016 02:16:04 UTC+2 schrieb Sheehan Olver:
>> 
>> I'm doing the following:
>> 
>> 
>> immutable FooIterator{d} end
>> 
>> Base.start(::FooIterator{d}) = tuple(zeros(Int,d)...)::NTuple{d,Int}
>> 
>> 
>> But is there a more elegant way of getting the type inferred?  I suppose I 
>> can override low order d directly:
>> 
>> Base.start(::FooIterator{2}) = (0,0)
>> Base.start(::FooIterator{3}) = (0,0,0)

[julia-users] Re: How to make a variable length tuple with inferred type

[Simon Danisch]

How about:
julia> @code_warntype ntuple( x -> 0, Val{3})
Variables:
  #self#::Base.#ntuple
  f::##1#2
  #unused#::Type{Val{3}}

Body:
  begin
  $(Expr(:static_parameter, 2)) # line 73:
  # meta: location tuple.jl _ntuple 80
  # meta: location tuple.jl _ntuple 80
  SSAValue(1) = $(QuoteNode(0))
  # meta: pop location
  # meta: pop location
  return 
(Core.tuple)(SSAValue(1),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64}
  end::Tuple{Int64,Int64,Int64}

Am Montag, 1. August 2016 02:16:04 UTC+2 schrieb Sheehan Olver:
>
> I'm doing the following:
>
>
> immutable FooIterator{d} end
>
> Base.start(::FooIterator{d}) = tuple(zeros(Int,d)...)::NTuple{d,Int}
>
>
> But is there a more elegant way of getting the type inferred?  I suppose I 
> can override low order d directly:
>
> Base.start(::FooIterator{2}) = (0,0)
> Base.start(::FooIterator{3}) = (0,0,0)
>

[julia-users] Re: Cluster manager, change ssh

[Dupont]

Sorry for not being precise. What I meant is that the scheduler is OAR.