_i
index_ip1 = index_1[key_i]
$body
end
end
The macros in Base.Cartesian almost solve the comprehension problem too, if
I make a version that can take arbitrary iters rather than just a number...
On 25 September 2016 at 18:53, Yichao Yu <yyc1...@gmail.com> wrote:
> On Sun,
I'm doing a lot of code-generation. There are two patterns that come up all
over the place - adding a suffix to a symbol and interpolating from an
array comprehension. This is pretty verbose even in the simplest case:
quote
...
row = tuple($([:($(Symbol("val_$ix))) for ix in order]...))
...
to make life easier for the compiler and my allocations went away.
I'm still interested in the second half of the question though - is there a
better way to debug allocation problems other than guesswork?
On 22 September 2016 at 14:06, Jamie Brandon <ja...@scattered-thoughts.net>
wrote:
September 2016 at 14:01, Jamie Brandon <ja...@scattered-thoughts.net>
wrote:
> I have a query compiler which emits Julia code. The code contains lots of
> calls to generated functions, which include sections like this:
>
> hi = gallop(column, column[finger.lo], fi
I have a query compiler which emits Julia code. The code contains lots of
calls to generated functions, which include sections like this:
hi = gallop(column, column[finger.lo], finger.lo, finger.hi, <=)
Finger{$(C+1)}(finger.lo, hi)
Finger is an immutable, isbits type:
immutable
ype{TArray{T}}) = ...
>
>
> But I'm getting a little confused about what you're trying to accomplish
> with that type parameter for the number of elements in the first place.
On 8 January 2016 at 18:23, Stefan Karpinski <ste...@karpinski.org> wrote:
> On Fri, Jan 8, 2
the behavior you want. In the future we may have syntax for this.
>
> Btw, the top type is called Any. ANY is a hack to let you hint to the
> compiler that it should not specialize a method on an argument.
>
> On Fri, Jan 8, 2016 at 11:26 AM, Jamie Brandon
> <ja...@scattered-tho
>> The fact that you can write NTuple{Any,Int} at all seems to be a bug:
>>
>> julia> NTuple{Any,Int}
>> ERROR: TypeError: NTuple: in parameter 1, expected Int64, got Type{Any}
>> in eval at ./boot.jl:265
>>
>> julia> NTuple{ANY,Int}
>> NTup
pected Int64, got Type{Any}
> in eval at ./boot.jl:265
>
> julia> NTuple{ANY,Int}
> NTuple{ANY,Int64}
>
>
> I'm not sure what's going on with that, but I've filed an issue: #14607.
>
> On Fri, Jan 8, 2016 at 2:00 PM, 'Jamie Brandon' via julia-users
> &l
I'm a little surprised by this:
julia> Hamt.NArray{4,Int64} <: Hamt.NArray{ANY,Int64}
true
julia> Type{Hamt.NArray{4,Int64}} <: Type{Hamt.NArray{ANY,Int64}}
false
I was trying to make call specialise on T but not N with:
call{T}(t::Type{NArray{ANY,T}}) = ...
This works perfectly for values:
I've seen it mentioned (eg in
https://groups.google.com/forum/#!msg/julia-dev/eBwqLqiZSPc/N0QlPMC015EJ)
that Julia can emit DWARF info for Julia functions. This does not seem to
be working for me (see gdb below and cachegrind attached). Is there
something I need to enable, or some dependency I
k up
> on the breakpoint. On the julia side, the registration with GDB should
> happen here
> (https://github.com/JuliaLang/julia/blob/ce1e856975af4dc8fc12dac8f5526c92feda60cb/src/jitlayers.cpp#L178),
> in latest master at least.
>
> On Tue, Jan 5, 2016 at 4:23 PM, 'Jamie Brandon' via julia-us
.user should be sufficient.
>
> On Tue, Jan 5, 2016 at 2:50 PM, Jamie Brandon <jami...@googlemail.com
> > wrote:
>
>> I've seen it mentioned (eg in
>> https://groups.google.com/forum/#!msg/julia-dev/eBwqLqiZSPc/N0QlPMC015EJ)
>> that Julia can emit DWARF info for Julia
ANDATORY_PATH = /usr/share/gconf/i3.mandatory.path
HOME = /home/jamie
Package Directory: /home/jamie/.julia/v0.5
No packages installed
On 5 January 2016 at 14:30, Keno Fischer <kfisc...@college.harvard.edu> wrote:
> Yeah, that should work.
>
> On Tue, Jan 5, 2016 at 3:28 PM, 'Ja
make -C deps distclean-llvm`
>>
>> On Tue, Jan 5, 2016 at 9:08 AM, Isaiah Norton <isaiah.nor...@gmail.com>
>> wrote:
>>>
>>> Probably need 'make -C steps distclean-llvm' before rebuild.
>>>
>>>
>>> On Tuesday, January 5, 2016, Jamie
Ooops, MARCH=native
On 5 January 2016 at 14:26, Jamie Brandon <jamii...@googlemail.com> wrote:
> Ok, so I currently have Make.user with:
>
> LLVM_VER=3.7.1
> ARCH=native
>
> and I'm building with `make debug`. Does that seem right?
>
> On 5 January 2016
julia> Vector[[1,2], [3, 4]]
2-element Array{Array{T,1},1}:
[1,2]
[3,4]
julia> [[1,2] [3,4]]
2x2 Array{Int64,2}:
1 3
2 4
julia> [[1,2], [3,4]]
WARNING: [a,b] concatenation is deprecated; use [a;b] instead
in depwarn at deprecated.jl:73
in oldstyle_vcat_warning at ./abstractarray.jl:29
may be able to
learn something from the internals. Thanks.
On Tuesday, 5 January 2016 13:08:06 UTC, Tim Holy wrote:
>
> Of possible interest:
> https://github.com/simonster/StructsOfArrays.jl
>
> --Tim
>
> On Tuesday, January 05, 2016 04:41:37 AM Jamie Br
, check whether the type is `isbits`.
>
> On Mon, Jan 4, 2016 at 7:15 PM, Jamie Brandon <
> ja...@scattered-thoughts.net > wrote:
>
>> This surprised me:
>>
>> immutable A
>> a::UInt32
>> b::UInt32
>> c::UInt64
>> d::UInt64
>
This surprised me:
immutable A
a::UInt32
b::UInt32
c::UInt64
d::UInt64
end
sizeof(A[A(0,0,0,0), A(0,0,0,0)]) # 48
immutable B
a::UInt32
b::UInt32
c::Vector{UInt64}
d::Vector{UInt64}
end
sizeof(B[B(0,0,[],[]), B(0,0,[],[])]) # 16
I expected the latter to also have size 48 ie
Contrary to
https://groups.google.com/forum/#!msg/julia-users/B_5SYRaY9YI/0Auz3c_IWr8J
I'm not seeing popcnt emitted on my machine. Is there something additional
I need to do? Is there a way to see what cpu-target julia is setting?
cat /proc/cpuinfo | grep popcnt
flags: fpu vme de pse
ltiple places in Julia's C++
> code that talks to LLVM, but I don't think this information is made
> available to Julia code.
>
> -erik
>
>
>
> On Sun, Jan 3, 2016 at 6:59 PM, Jamie Brandon <jamii...@googlemail.com> wrote:
>> Contrary to
>> https:
December 2015 at 15:04, Jamie Brandon <jamii...@googlemail.com> wrote:
> Hmmm, if I look in the llvm ir for each I can see calling
> @julia_dedup_sorted_23928 vs @julia_dedup_sorted_23931 and these are
> stable when I recompile f, so presumably those are the cached methods.
> If I
Hmmm, if I look in the llvm ir for each I can see calling
@julia_dedup_sorted_23928 vs @julia_dedup_sorted_23931 and these are
stable when I recompile f, so presumably those are the cached methods.
If I could somehow grab the ir for those I would have a way to check
whether or not they are being
In the case of dedup_sorted, the generated code for both types is fine and
the code for f() shows dedup_sorted being called with the correct type in
both cases. Is there any way to check whether the function actually gets
specialised?
On Tuesday, 29 December 2015 14:51:51 UTC, Jamie Brandon
for x in xs
> push!(ys, construct(ykey, x))
> end
> return ys
> end
>
> reshape([(10,11,12),(13,14,15)],NTuple{2,Int}[],(1,3))
>
> Above: 0.021351 seconds (500.00 k allocations: 30.518 MB, 17.76% gc time)
> Type{Val{T}} reshape2: 0.021599 seconds (500
I have two versions of this reshape function -
https://gist.github.com/jamii/62b3c3695fba95f3f09b
The produce near-identical ast from code_warntype -
https://www.diffchecker.com/awnv9zvv
But code_lowered shows that reshape naively boxes tuples whereas reshape2
does something much more
27 matches
Mail list logo
