[julia-users] Re: indirect array indexing

[apaoluzzi]

OK!  many thanks for your fast reply
--a

On Friday, September 30, 2016 at 3:53:43 PM UTC+2, apao...@gmail.com wrote:
>
> Hi guys,
>
> I'm learning the language while implementing an advanced package for 
> geometric and solid modeling.
> My question is: What is the right idiom (shorter and/or faster) for 
> writing this kind of array indexing:
>
> linesFromLineArray(V,EV) = Any[[V[:,EV[:,k][1]] V[:,EV[:,k][2]]  ] for 
> k=1:size(EV,2)]
>
> The efficiency is the strongest issue, since this method should provide 
> the indirect indexing for any kind of cellular complexes.
> Many thanks for your help
>
>
> julia> V,EV
> (
> 2x10 Array{Float64,2}:
>  0.13611  0.14143  0.38501  0.42103  0.96927  0.90207  0.0 0.11508 
>  0.61437  0.52335
>  0.59824  0.58921  0.25964  0.24118  0.19741  0.34109  0.0213  0.0 
>  0.05601  0.17309,
>
> 2x5 Array{Int64,2}:
>  1  3  5  7   9
>  2  4  6  8  10)
>
> julia> linesFromLineArray(V,EV)
> 5-element Array{Any,1}:
>  2x2 Array{Float64,2}:
>  0.13611  0.14143
>  0.59824  0.58921
>  2x2 Array{Float64,2}:
>  0.38501  0.42103
>  0.25964  0.24118
>  2x2 Array{Float64,2}:
>  0.96927  0.90207
>  0.19741  0.34109
>  2x2 Array{Float64,2}:
>  0.0 0.11508
>  0.0213  0.0  
>  2x2 Array{Float64,2}:
>  0.61437  0.52335
>  0.05601  0.17309
>
>

[julia-users] Re: indirect array indexing

[vavasis]

First, it is better to use a 3-dimensional array rather than an array of 
arrays.  If you must use an array of arrays, it is better for the outer 
array to be of type Array{Array{Float,2},1} rather than Array{Any,1}.

For max performance, it is hard to beat explicit loops:

result = Array(Float64, size(V,1), 2, size(EV,2))
for k = 1 : size(EV,2)
for j = 1 : 2
 for i = 1 : size(V,1)
   result[i,j,k] = V[i,EV[j,k]]
 end
 end
end

There are some macro packages like Einsum.jl that let you hide the explicit 
loops.

-- Steve Vavasis




On Friday, September 30, 2016 at 9:53:43 AM UTC-4, apao...@gmail.com wrote:
>
> Hi guys,
>
> I'm learning the language while implementing an advanced package for 
> geometric and solid modeling.
> My question is: What is the right idiom (shorter and/or faster) for 
> writing this kind of array indexing:
>
> linesFromLineArray(V,EV) = Any[[V[:,EV[:,k][1]] V[:,EV[:,k][2]]  ] for 
> k=1:size(EV,2)]
>
> The efficiency is the strongest issue, since this method should provide 
> the indirect indexing for any kind of cellular complexes.
> Many thanks for your help
>
>
> julia> V,EV
> (
> 2x10 Array{Float64,2}:
>  0.13611  0.14143  0.38501  0.42103  0.96927  0.90207  0.0 0.11508 
>  0.61437  0.52335
>  0.59824  0.58921  0.25964  0.24118  0.19741  0.34109  0.0213  0.0 
>  0.05601  0.17309,
>
> 2x5 Array{Int64,2}:
>  1  3  5  7   9
>  2  4  6  8  10)
>
> julia> linesFromLineArray(V,EV)
> 5-element Array{Any,1}:
>  2x2 Array{Float64,2}:
>  0.13611  0.14143
>  0.59824  0.58921
>  2x2 Array{Float64,2}:
>  0.38501  0.42103
>  0.25964  0.24118
>  2x2 Array{Float64,2}:
>  0.96927  0.90207
>  0.19741  0.34109
>  2x2 Array{Float64,2}:
>  0.0 0.11508
>  0.0213  0.0  
>  2x2 Array{Float64,2}:
>  0.61437  0.52335
>  0.05601  0.17309
>
>

Re: [julia-users] Generic Linux binaries for julia-0.4.6

[Mauro]

Adapting the links found on
http://julialang.org/downloads/oldreleases.html
should work.  E.g.:

https://s3.amazonaws.com/julialang/bin/winnt/x64/0.4/julia-0.4.7-win64.exe

to

https://s3.amazonaws.com/julialang/bin/winnt/x64/0.4/julia-0.4.6-win64.exe

On Fri, 2016-09-30 at 23:15, amik...@gmail.com wrote:
> Hello,
>
> Sorry for the possibly dumb question: for benchmarking purposes I'm looking
> for the generic Linux binaries for julia-0.4.6 (I don't want to compile
> from the source). Can they still be found somewhere?
>
> Many thanks,

[julia-users] Generic Linux binaries for julia-0.4.6

[amiksvi]

Hello,

Sorry for the possibly dumb question: for benchmarking purposes I'm looking 
for the generic Linux binaries for julia-0.4.6 (I don't want to compile 
from the source). Can they still be found somewhere?

Many thanks,

[julia-users] Simple test functions generates different codegen

[mmh]

I would have that thought that these two function would produce the same 
code, but they do not.

Could someone care to explain the difference and which is preferred and why


http://pastebin.com/GJ8YPfV3

function test1(x)
y = 2.0
u = 2.320
x < 0 && (u = 32.0)
x > 1 && (u = 1.0)
return u + y
end


function test2(x)
y = 2.0
u = 2.320
u = x < 0 ? 32.0 : u
u = x > 1 ? 1.0 : u
return u + y
end


@code_llvm test1(2.2)

@code_llvm test2(2.2)

[julia-users] Parallelizing Error on 0.5 on Ubuntu

[ABB]

On this Julia version:

   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-pc-linux-gnu

running on:

Ubuntu 14.04.3 LTS

I am trying to do a Monte Carlo simulation in parallel across 36 workers.  

I have two problems (at least).

1.  Some of the workers terminate at the beginning of the simulation, but I 
don't understand the error message:

Worker 5 terminated.ERROR (unhandled task failure): ProcessExitedException()
 in yieldto(::Task, ::ANY) at ./event.jl:136
 in wait() at ./event.jl:169
 in wait(::Condition) at ./event.jl:27
 in wait(::Channel{Any}) at ./channels.jl:92
 in take!(::Channel{Any}) at ./channels.jl:73
 in #remotecall_fetch#606(::Array{Any,1}, ::Function, ::Function, 
::Base.Worker, ::Function, ::Vararg{Any,N}) at ./multi.jl:1066
 in remotecall_fetch(::Function, ::Base.Worker, ::Function, 
::Vararg{Any,N}) at ./multi.jl:1062
 in #remotecall_fetch#609(::Array{Any,1}, ::Function, ::Function, ::Int64, 
::Function, ::Vararg{Any,N}) at ./multi.jl:1080
 in remotecall_fetch(::Function, ::Int64, ::Function, ::Vararg{Any,N}) at 
./multi.jl:1080
 in 
(::Base.##667#668{Base.#+,ProjectModule.##45#47{Int64,Array{Any,1},Array{Any,2}},UnitRange{Int64},Array{UnitRange{Int64},1}})()
 
at ./multi.jl:1998

This is not a huge problem as the rest of the workers keep going and can 
finish the simulation, but I would like to understand what is going on, if 
possible.  (And maybe how to fix it so as to use those workers.)  

2.  The more important problem is that at the end of the simulation, I run 
into other errors and nothing is returned.  My (uninformed and probably 
wrong) guess is that there is something the program doesn't like about the 
fact that the different workers are finishing at different times?  The 
errors I get are:


ERROR (unhandled task failure): EOFError: read end of file
Worker 16 terminated.ERROR (unhandled task failure): 
ProcessExitedException()
 in yieldto(::Task, ::ANY) at ./event.jl:136
 in wait() at ./event.jl:169
 in wait(::Condition) at ./event.jl:27
 in wait(::Channel{Any}) at ./channels.jl:92
 in take!(::Channel{Any}) at ./channels.jl:73
 in #remotecall_fetch#606(::Array{Any,1}, ::Function, ::Function, 
::Base.Worker, ::Function, ::Vararg{Any,N}) at ./multi.jl:1066
 in remotecall_fetch(::Function, ::Base.Worker, ::Function, 
::Vararg{Any,N}) at ./multi.jl:1062
 in #remotecall_fetch#609(::Array{Any,1}, ::Function, ::Function, ::Int64, 
::Function, ::Vararg{Any,N}) at ./multi.jl:1080
 in remotecall_fetch(::Function, ::Int64, ::Function, ::Vararg{Any,N}) at 
./multi.jl:1080
 in 
(::Base.##667#668{Base.#+,ProjectModule.##45#47{Int64,Array{Any,1},Array{Any,2}},UnitRange{Int64},Array{UnitRange{Int64},1}})()
 
at ./multi.jl:1998

And - 

ERROR: LoadError: ProcessExitedException()
 in wait(::Task) at ./task.jl:135
 in collect_to!(::Array{Array{Float64,2},1}, 
::Base.Generator{Array{Task,1},Base.#wait}, ::Int64, ::Int64) at 
./array.jl:340
 in collect(::Base.Generator{Array{Task,1},Base.#wait}) at ./array.jl:308
 in preduce(::Function, ::Function, ::UnitRange{Int64}) at ./multi.jl:2002
 in (::ProjectModule.##44#46{Int64,Array{Any,1},Array{Any,2},Int64})() at 
./multi.jl:2011
 in macro expansion at ./task.jl:326 [inlined]
 in #OuterSim#43(::Int64, ::Int64, ::Int64, ::Array{Any,1}, ::Array{Any,2}, 
::Function, ::Int64) at /home/ubuntu/dynhosp/DataStructs.jl:1321
 in (::ProjectModule.#kw##OuterSim)(::Array{Any,1}, 
::ProjectModule.#OuterSim, ::Int64) at ./:0
 in include_from_node1(::String) at ./loading.jl:488
 in process_options(::Base.JLOptions) at ./client.jl:262
 in _start() at ./client.jl:318
while loading /home/ubuntu/dynhosp/Run.jl, in expression starting on line 9

And finally: 

ERROR (unhandled task failure): On worker 9:
ArgumentError: Dict(kv): kv needs to be an iterator of tuples or pairs
 in Type at ./dict.jl:388
 in CalcWTP at /home/ubuntu/dynhosp/DataStructs.jl:728
 in WTPMap at /home/ubuntu/dynhosp/DataStructs.jl:747
 in #PSim#32 at /home/ubuntu/dynhosp/DataStructs.jl:1024
 in #45 at ./multi.jl:2016
 in #625 at ./multi.jl:1421
 in run_work_thunk at ./multi.jl:1001
 in macro expansion at ./multi.jl:1421 [inlined]
 in #624 at ./event.jl:68
 in #remotecall_fetch#606(::Array{Any,1}, ::Function, ::Function, 
::Base.Worker, ::Function, ::Vararg{Any,N}) at ./multi.jl:1070
 in remotecall_fetch(::Function, ::Base.Worker, ::Function, 
::Vararg{Any,N}) at ./multi.jl:1062
 in #remotecall_fetch#609(::Array{Any,1}, ::Function, ::Function, ::Int64, 
::Function, ::Vararg{Any,N}) at ./multi.jl:1080
 in remotecall_fetch(::Function, ::Int64, ::Function, ::Vararg{Any,N}) at 
./multi.jl:1080
 in 
(::Base.##667#668{Base.#+,ProjectModule.##45#47{Int64,Array{Any,1},Array{Any,2}},UnitRang

[julia-users] JPEG 2000 values are doubled

[bogdan . grama]

 

On a simple conversion to UInt16 TIFF, the result pixel values are doubled.

As sample data use any of the Sentinel 2 bands from Amazon S3:
http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/35/T/MN/2016/8/29/0/


using Images
using FileIO

img = load("B01.jp2");
save("B01julia.tif", img);


I think the load function is responsible for this.
Any explanation?

[julia-users] Re: ANN: CUDAdrv.jl, and CUDA.jl deprecation

[Chris Rackauckas]

Thanks for the update.

On Thursday, September 29, 2016 at 6:31:29 PM UTC-7, Tim Besard wrote:
>
> Hi all,
>
> CUDAdrv.jl  is Julia wrapper for 
> the CUDA driver API -- not to be confused with its counterpart CUDArt.jl 
>  which wraps the slightly 
> higher-level CUDA runtime API.
>
> The package doesn't feature many high-level or easy-to-use wrappers, but 
> focuses on providing the necessary functionality for other packages to 
> build upon. For example, CUDArt uses CUDAdrv for launching kernels, while 
> CUDAnative (the in-development native programming interface) completely 
> relies on CUDAdrv for all GPU interactions.
>
> It features a ccall-like cudacall interface for launching kernels and 
> passing values:
> using CUDAdrv
> using Base.Test
>
> dev = CuDevice(0)
> ctx = CuContext(dev)
>
> md = CuModuleFile(joinpath(dirname(@__FILE__), "vadd.ptx"))
> vadd = CuFunction(md, "kernel_vadd")
>
> dims = (3,4)
> a = round(rand(Float32, dims) * 100)
> b = round(rand(Float32, dims) * 100)
>
> d_a = CuArray(a)
> d_b = CuArray(b)
> d_c = CuArray(Float32, dims)
>
> len = prod(dims)
> cudacall(vadd, len, 1, (DevicePtr{Cfloat},DevicePtr{Cfloat},DevicePtr{
> Cfloat}), d_a, d_b, d_c)
> c = Array(d_c)
> @test a+b ≈ c
>
> destroy(ctx)
>
> For documentation, refer to the NVIDIA docs 
> . Even though they don't 
> fully match what CUDAdrv.jl implements, the package is well tested, and 
> redocumenting the entire thing is too much work.
>
> Current master of this package only supports 0.5, but there's a tagged 
> version supporting 0.4 (as CUDArt.jl does so as well). It has been tested 
> on CUDA 5.0 up to 8.0, but there might always be issues with certain 
> versions (as the wrappers aren't auto-generated, and probably will never be 
> due to how NVIDIA has implemented cuda.h)
>
> Anybody thinking there's a lot of overlap between CUDArt and CUDAdrv is 
> completely right, but it mimics the overlap between CUDA's runtime and 
> driver APIs as in some cases we do specifically need one or the other (eg., 
> CUDAnative wouldn't work with only the runtime API). There's also some 
> legacy at the Julia side: CUDAdrv.jl is based on CUDA.jl, while CUDArt.jl 
> has been an independent effort.
>
>
> In other news, we have recently *deprecated the old CUDA.jl package*. All 
> users should now use either CUDArt.jl or CUDAdrv.jl, depending on what 
> suits them best. Neither is a drop-in replacement, but the changes should 
> be minor. At the very least, users will have to change the kernel launch 
> syntax, which should use cudacall as shown above. In the future, we might 
> re-use the CUDA.jl package name for the native programming interface 
> currently at CUDAnative.jl
>
>
> Best,
> Tim
>

Re: [julia-users] Re: eval in current scope

[Cedric St-Jean]

Looks like I was accidentally on 0.4, and hygiene rules changed in 0.5. 
This works:

using MacroTools

macro withself(fdef)
@assert @capture(fdef, fname_() = expr_)
esc(:(@generated function $(fname)(self)
expr = $(Expr(:quote, expr))
# Replace this with recursive traversal. For demo, I'm assuming a 
single function call
@assert @capture(expr, f_(args__))
:(($f)($([arg in fieldnames(self) ? Expr(:., :self, QuoteNode(arg)) 
: arg for arg in args]...)))
end))
end

type A
ii
oo
end

a = 20
@withself foo() = ii + oo + a

foo(A(33, 44))  # 97



On Friday, September 30, 2016 at 9:59:37 AM UTC-4, Cedric St-Jean wrote:
>
> This only works if A and type_fields are defined in the same module 
>> though. Although to be honest it surprised me a bit that it works at all, I 
>> guess the type definitions are evaluated prior to macro expansions? 
>>
>
> Good point. 
>
> You can use a generated function then:
>
> using MacroTools
>
> macro withself(fdef)
> @assert @capture(fdef, fname_() = expr_) # could accept other arguments
> :(@generated function $(esc(fname))(self)
> expr = $(Expr(:quote, expr))   # grab the `expr` from the macro 
> body
> # Replace this with recursive traversal. For demo, I'm assuming a 
> single function call
> @assert @capture(expr, f_(args__))
> :($f($([arg in fieldnames(self) ? Expr(:., :self, QuoteNode(arg)) 
> : arg for arg in args]...)))
> end)
> end
>
> type A
> ii
> oo
> end
>
> a = 20
> @withself foo() = ii + oo + a
>
> foo(A(33, 44))  # 97
>
> Since generated functions are passed the _type_ of their arguments, which 
> is what you were looking for. It's an abuse of Julia's metaprogramming 
> facilities in strict Lisp tradition ;)
>
> On Friday, September 30, 2016 at 5:32:49 AM UTC-4, Marius Millea wrote:
>
>>
>> Would eval'ing the type inside the macro work? This shows [:x, :y]
>>>
>>>
>> This only works if A and type_fields are defined in the same module 
>> though. Although to be honest it surprised me a bit that it works at all, I 
>> guess the type definitions are evaluated prior to macro expansions? 
>>
>>
>> A macro which defines a type-specific version @self_MyType of your @self 
>>> macro at the definition of the type: 
>>
>>
>> Yea, the solutions both me and fcard coded up originally involved having 
>> to call a macro on the type definition, this is precisely what I'm trying 
>> to get rid of right now. The reason for not using @unpack is just that its 
>> more verbose than this solution (at the price of the type redefinition 
>> thing, but for me its a fine tradeoff). It *really* like getting to write 
>> super concise functions which read just like the math they represent, 
>> nothing extra distracting, e.g. from my actual code:
>>
>> """Hubble constant at redshift z"""
>> @self Params Hubble(z) = Hfac*sqrt(ρx_over_ωx*((ωc+ωb)*(1+z)^3 + ωk*(1+z
>> )^2 + ωΛ) + ργ(z) + ρν(z))
>>
>>
>> """Optical depth between two redshifts given a free electron fraction 
>> history Xe"""
>> @self Params function τ(Xe::Function, z1, z2)
>> σT*(ωb*ρx_over_ωx)/mH*(1-Yp) * quad(z->Xe(z)/Hubble(z)*(1+z)^2, z1, 
>> z2)
>> end
>>
>>
>>
>>
>>
>>
>>  
>>
>>

Re: [julia-users] Re: eval in current scope

[Cedric St-Jean]

>
> This only works if A and type_fields are defined in the same module 
> though. Although to be honest it surprised me a bit that it works at all, I 
> guess the type definitions are evaluated prior to macro expansions? 
>

Good point. 

You can use a generated function then:

using MacroTools

macro withself(fdef)
@assert @capture(fdef, fname_() = expr_) # could accept other arguments
:(@generated function $(esc(fname))(self)
expr = $(Expr(:quote, expr))   # grab the `expr` from the macro body
# Replace this with recursive traversal. For demo, I'm assuming a 
single function call
@assert @capture(expr, f_(args__))
:($f($([arg in fieldnames(self) ? Expr(:., :self, QuoteNode(arg)) : 
arg for arg in args]...)))
end)
end

type A
ii
oo
end

a = 20
@withself foo() = ii + oo + a

foo(A(33, 44))  # 97

Since generated functions are passed the _type_ of their arguments, which 
is what you were looking for. It's an abuse of Julia's metaprogramming 
facilities in strict Lisp tradition ;)

On Friday, September 30, 2016 at 5:32:49 AM UTC-4, Marius Millea wrote:

>
> Would eval'ing the type inside the macro work? This shows [:x, :y]
>>
>>
> This only works if A and type_fields are defined in the same module 
> though. Although to be honest it surprised me a bit that it works at all, I 
> guess the type definitions are evaluated prior to macro expansions? 
>
>
> A macro which defines a type-specific version @self_MyType of your @self 
>> macro at the definition of the type: 
>
>
> Yea, the solutions both me and fcard coded up originally involved having 
> to call a macro on the type definition, this is precisely what I'm trying 
> to get rid of right now. The reason for not using @unpack is just that its 
> more verbose than this solution (at the price of the type redefinition 
> thing, but for me its a fine tradeoff). It *really* like getting to write 
> super concise functions which read just like the math they represent, 
> nothing extra distracting, e.g. from my actual code:
>
> """Hubble constant at redshift z"""
> @self Params Hubble(z) = Hfac*sqrt(ρx_over_ωx*((ωc+ωb)*(1+z)^3 + ωk*(1+z)^
> 2 + ωΛ) + ργ(z) + ρν(z))
>
>
> """Optical depth between two redshifts given a free electron fraction 
> history Xe"""
> @self Params function τ(Xe::Function, z1, z2)
> σT*(ωb*ρx_over_ωx)/mH*(1-Yp) * quad(z->Xe(z)/Hubble(z)*(1+z)^2, z1, z2
> )
> end
>
>
>
>
>
>
>  
>
>

Re: [julia-users] Re: Julia-i18n logo proposal

[Stefan Karpinski]

Lovely logo for i18n. 👍

On Fri, Sep 30, 2016 at 5:51 AM, Waldir Pimenta 
wrote:

> What a nice coincidence! That was totally unintended :)
>
> By the way, here's a reference for the most used writing systems:
> https://en.wikipedia.org/wiki/List_of_writing_systems#List_
> of_writing_scripts_by_adoption
>
>
> On Friday, September 30, 2016 at 9:16:05 AM UTC+1, Kenta Sato wrote:
>>
>> "朱" means a kind of red colors in Japanese (https://ja.wikipedia.org/wiki
>> /%E6%9C%B1%E8%89%B2). You placed it at the best circle of the logo.
>>
>> On Friday, September 30, 2016 at 9:47:04 AM UTC+9, Waldir Pimenta wrote:
>>>
>>> Hi all. I made a proposal for the logo for the Julia-i18n organization:
>>> http://imgh.us/julia-i18n_1.svg
>>>
>>> It uses the three most used scripts worldwide, and the characters are
>>> actually the start of the word “Julia” as written in each of those scripts.
>>>
>>> Looking forward to know what you guys think.
>>>
>>> --Waldir
>>>
>>

[julia-users] indirect array indexing

[apaoluzzi]

Hi guys,

I'm learning the language while implementing an advanced package for 
geometric and solid modeling.
My question is: What is the right idiom (shorter and/or faster) for writing 
this kind of array indexing:

linesFromLineArray(V,EV) = Any[[V[:,EV[:,k][1]] V[:,EV[:,k][2]]  ] for 
k=1:size(EV,2)]

The efficiency is the strongest issue, since this method should provide the 
indirect indexing for any kind of cellular complexes.
Many thanks for your help


julia> V,EV
(
2x10 Array{Float64,2}:
 0.13611  0.14143  0.38501  0.42103  0.96927  0.90207  0.0 0.11508 
 0.61437  0.52335
 0.59824  0.58921  0.25964  0.24118  0.19741  0.34109  0.0213  0.0 
 0.05601  0.17309,

2x5 Array{Int64,2}:
 1  3  5  7   9
 2  4  6  8  10)

julia> linesFromLineArray(V,EV)
5-element Array{Any,1}:
 2x2 Array{Float64,2}:
 0.13611  0.14143
 0.59824  0.58921
 2x2 Array{Float64,2}:
 0.38501  0.42103
 0.25964  0.24118
 2x2 Array{Float64,2}:
 0.96927  0.90207
 0.19741  0.34109
 2x2 Array{Float64,2}:
 0.0 0.11508
 0.0213  0.0  
 2x2 Array{Float64,2}:
 0.61437  0.52335
 0.05601  0.17309

[julia-users] Seg fault when using Logging.jl

[Stefan Kruger]

Not sure if this is the right place for this..

I encountered a seg fault in v.0.5 (also in v.0.4) when I introduced 
Logging.jl - my set of tests runs fine without Logging, but crashes 
immediately when I try to log something:

signal (11): Segmentation fault: 11

while loading /Users/stefan/.julia/v0.5/Couchzilla/test/crud_tests.jl, in 
expression starting on line 1

uv_write2 at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/deps/srccache/libuv-8d5131b6c1595920dd30644cd1435b4f344b46c8/src/unix/stream.c:1389

uv_write at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/deps/srccache/libuv-8d5131b6c1595920dd30644cd1435b4f344b46c8/src/unix/stream.c:1475

jl_uv_write at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/jl_uv.c:424

uv_write at ./stream.jl:809

unsafe_write at ./stream.jl:830

write at ./io.jl:175

print at ./strings/io.jl:70 [inlined]

with_output_color at ./util.jl:302

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

jl_apply at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.h:1392 
[inlined]

jl_f__apply at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/builtins.c:547

print_with_color at ./util.jl:306

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

err at /Users/stefan/.julia/v0.5/Logging/src/Logging.jl:53

#relax#2 at /Users/stefan/.julia/v0.5/Couchzilla/src/utils.jl:97

unknown function (ip: 0x318f98bb6)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

#relax at ./:0

#readdoc#6 at /Users/stefan/.julia/v0.5/Couchzilla/src/database.jl:177

readdoc at /Users/stefan/.julia/v0.5/Couchzilla/src/database.jl:126

unknown function (ip: 0x318f94f66)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

macro expansion; at 
/Users/stefan/.julia/v0.5/Couchzilla/test/crud_tests.jl:4 [inlined]

macro expansion; at ./test.jl:672 [inlined]

anonymous at ./ (unknown line)

unknown function (ip: 0x318f9484f)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_toplevel_eval_flex at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:569

jl_parse_eval_all at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/ast.c:717

jl_load at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:596 
[inlined]

jl_load_ at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:605

include_from_node1 at ./loading.jl:488

jlcall_include_from_node1_20125 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

do_call at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:66

eval at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:190

eval_body at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:534

eval_body at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:515

jl_interpret_call at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:573

jl_toplevel_eval_flex at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:572

jl_parse_eval_all at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/ast.c:717

jl_load at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:596 
[inlined]

jl_load_ at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:605

include_from_node1 at ./loading.jl:488

jlcall_include_from_node1_20125 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

process_options at ./client.jl:262

_start at ./client.jl:318

jlcall__start_21452 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

true_main at /usr/local/bin/julia (unknown line)

[julia-users] Re: ANN: CUDAdrv.jl, and CUDA.jl deprecation

[Simon Danisch]

Great work! :)

Well, I think GPUArrays should be the right place! If it is the right place 
depends on how much time and cooperation I get ;)
The plan is to integrate all these 3rd party libraries. If you could help 
me with that, it would already be a great first step to establish that 
library :)

Am Freitag, 30. September 2016 03:31:29 UTC+2 schrieb Tim Besard:
>
> Hi all,
>
> CUDAdrv.jl  is Julia wrapper for 
> the CUDA driver API -- not to be confused with its counterpart CUDArt.jl 
>  which wraps the slightly 
> higher-level CUDA runtime API.
>
> The package doesn't feature many high-level or easy-to-use wrappers, but 
> focuses on providing the necessary functionality for other packages to 
> build upon. For example, CUDArt uses CUDAdrv for launching kernels, while 
> CUDAnative (the in-development native programming interface) completely 
> relies on CUDAdrv for all GPU interactions.
>
> It features a ccall-like cudacall interface for launching kernels and 
> passing values:
> using CUDAdrv
> using Base.Test
>
> dev = CuDevice(0)
> ctx = CuContext(dev)
>
> md = CuModuleFile(joinpath(dirname(@__FILE__), "vadd.ptx"))
> vadd = CuFunction(md, "kernel_vadd")
>
> dims = (3,4)
> a = round(rand(Float32, dims) * 100)
> b = round(rand(Float32, dims) * 100)
>
> d_a = CuArray(a)
> d_b = CuArray(b)
> d_c = CuArray(Float32, dims)
>
> len = prod(dims)
> cudacall(vadd, len, 1, (DevicePtr{Cfloat},DevicePtr{Cfloat},DevicePtr{
> Cfloat}), d_a, d_b, d_c)
> c = Array(d_c)
> @test a+b ≈ c
>
> destroy(ctx)
>
> For documentation, refer to the NVIDIA docs 
> . Even though they don't 
> fully match what CUDAdrv.jl implements, the package is well tested, and 
> redocumenting the entire thing is too much work.
>
> Current master of this package only supports 0.5, but there's a tagged 
> version supporting 0.4 (as CUDArt.jl does so as well). It has been tested 
> on CUDA 5.0 up to 8.0, but there might always be issues with certain 
> versions (as the wrappers aren't auto-generated, and probably will never be 
> due to how NVIDIA has implemented cuda.h)
>
> Anybody thinking there's a lot of overlap between CUDArt and CUDAdrv is 
> completely right, but it mimics the overlap between CUDA's runtime and 
> driver APIs as in some cases we do specifically need one or the other (eg., 
> CUDAnative wouldn't work with only the runtime API). There's also some 
> legacy at the Julia side: CUDAdrv.jl is based on CUDA.jl, while CUDArt.jl 
> has been an independent effort.
>
>
> In other news, we have recently *deprecated the old CUDA.jl package*. All 
> users should now use either CUDArt.jl or CUDAdrv.jl, depending on what 
> suits them best. Neither is a drop-in replacement, but the changes should 
> be minor. At the very least, users will have to change the kernel launch 
> syntax, which should use cudacall as shown above. In the future, we might 
> re-use the CUDA.jl package name for the native programming interface 
> currently at CUDAnative.jl
>
>
> Best,
> Tim
>

[julia-users] Re: Julia-i18n logo proposal

[Waldir Pimenta]

What a nice coincidence! That was totally unintended :)

By the way, here's a reference for the most used writing systems: 
https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scripts_by_adoption

On Friday, September 30, 2016 at 9:16:05 AM UTC+1, Kenta Sato wrote:
>
> "朱" means a kind of red colors in Japanese (
> https://ja.wikipedia.org/wiki/%E6%9C%B1%E8%89%B2). You placed it at the 
> best circle of the logo. 
>
> On Friday, September 30, 2016 at 9:47:04 AM UTC+9, Waldir Pimenta wrote:
>>
>> Hi all. I made a proposal for the logo for the Julia-i18n organization: 
>> http://imgh.us/julia-i18n_1.svg
>>
>> It uses the three most used scripts worldwide, and the characters are 
>> actually the start of the word “Julia” as written in each of those scripts.
>>
>> Looking forward to know what you guys think.
>>
>> --Waldir
>>
>

Re: [julia-users] Re: eval in current scope

[Marius Millea]

> Would eval'ing the type inside the macro work? This shows [:x, :y]
>
>
This only works if A and type_fields are defined in the same module though. 
Although to be honest it surprised me a bit that it works at all, I guess 
the type definitions are evaluated prior to macro expansions? 


A macro which defines a type-specific version @self_MyType of your @self 
> macro at the definition of the type: 


Yea, the solutions both me and fcard coded up originally involved having to 
call a macro on the type definition, this is precisely what I'm trying to 
get rid of right now. The reason for not using @unpack is just that its 
more verbose than this solution (at the price of the type redefinition 
thing, but for me its a fine tradeoff). It *really* like getting to write 
super concise functions which read just like the math they represent, 
nothing extra distracting, e.g. from my actual code:

"""Hubble constant at redshift z"""
@self Params Hubble(z) = Hfac*sqrt(ρx_over_ωx*((ωc+ωb)*(1+z)^3 + ωk*(1+z)^2 
+ ωΛ) + ργ(z) + ρν(z))


"""Optical depth between two redshifts given a free electron fraction 
history Xe"""
@self Params function τ(Xe::Function, z1, z2)
σT*(ωb*ρx_over_ωx)/mH*(1-Yp) * quad(z->Xe(z)/Hubble(z)*(1+z)^2, z1, z2)
end






 

Re: [julia-users] Re: Julia-i18n logo proposal

[henri.gir...@gmail.com]

赤 chinese /red /scarlet (very near) lol
Le 30/09/2016 à 10:16, Kenta Sato a écrit :
"朱" means a kind of red colors in Japanese 
(https://ja.wikipedia.org/wiki/%E6%9C%B1%E8%89%B2). You placed it at 
the best circle of the logo.


On Friday, September 30, 2016 at 9:47:04 AM UTC+9, Waldir Pimenta wrote:

Hi all. I made a proposal for the logo for the Julia-i18n
organization: http://imgh.us/julia-i18n_1.svg


It uses the three most used scripts worldwide, and the characters
are actually the start of the word “Julia” as written in each of
those scripts.

Looking forward to know what you guys think.

--Waldir

[julia-users] Re: Julia-i18n logo proposal

[Kenta Sato]

"朱" means a kind of red colors in Japanese 
(https://ja.wikipedia.org/wiki/%E6%9C%B1%E8%89%B2). You placed it at the 
best circle of the logo. 

On Friday, September 30, 2016 at 9:47:04 AM UTC+9, Waldir Pimenta wrote:
>
> Hi all. I made a proposal for the logo for the Julia-i18n organization: 
> http://imgh.us/julia-i18n_1.svg
>
> It uses the three most used scripts worldwide, and the characters are 
> actually the start of the word “Julia” as written in each of those scripts.
>
> Looking forward to know what you guys think.
>
> --Waldir
>

Re: [julia-users] Re: eval in current scope

[Mauro]

On Fri, 2016-09-30 at 00:53, Marius Millea  wrote:
> I think there's at least once scenario where eval-in-a-macro is not a
> mistake, mainly when you want to generate some code that depends on 1) some
> passed in expression and 2) something which can only be known at runtime.

I think one of the problems with macro-evals is that (at least the
advanced user) will expect a macro to do a pure syntax transform,
independent of the state of the runtime.  Anything else would be
surprising.  Maybe macros which call `eval` should have names with an
`!` to advertise their non-standard-ness?

> Here's my example:
>
> The macro (@self) which I'm writing takes a type name and a function
> definition, and gives the function a "self" argument of that type and
> rewrites all occurrences of the type's fields, X, to self.X. Effectively it
> takes this:
>
> type MyType
> x
> end
>
> @self MyType function inc()
> x += 1
> end
>
> and spits out:
>
> function inc(self::MyType)
> self.x += 1
> end
>
> (if this sounds familiar, its because I've discussed it here before, which
> spun off this , that I'm
> currently working on tweaking)
>
>
> To do this my code needs to modify the function expression, but this
> modification depends on fieldnames(MyType), which can *only* be known at
> runtime. Hence what I'm doing is,
>
> macro self(typ,func)
>
> function modify_func(fieldnames)
> # in here I have access to `func` expression *and*
> `fieldnames(typ)` as evaluated at runtime
> # return modified func expression
> end
>
> quote
> $(esc(:eval))($modify_func(fieldnames($(esc(typ)
> end
>
> end
>
> I don't see a cleaner way of doing this, but I'm happy to take suggestions.
>
> (Btw: my original question was w.r.t. that last "eval', which makes it so
> that currently this doesn't work on function closures. I'm still processing
> the several suggestions in this context...)
>
>
> On Tuesday, September 27, 2016 at 5:12:44 PM UTC+2, Steven G. Johnson wrote:
>>
>> On Tuesday, September 27, 2016 at 10:27:59 AM UTC-4, Stefan Karpinski
>> wrote:
>>>
>>> But note that if you want some piece of f to be "pasted" from the user
>>> and have access to certain parts of the local state of f, it's probably a
>>> much better design to let the user pass in a function which f calls,
>>> passing the function the state that it should have access to:
>>>
>>
>> Right; using "eval" in a function is almost always a mistake, an
>> indication that you should really be using a higher-order function.
>> 
>>