Re: [julia-users] Re: MYSQL/MARIADB Big INSERT

[Ivar Nesje]

If you want to use prepared statements (for safely inserting strings) you will 
get a huge speedup if you wrap the insert queries in a transaction. 

Re: [julia-users] PSA: new ~/.julia_history format

[Ivar Nesje]

Open "Terminal"

Type
rm ~/.julia_history

[julia-users] How to insert new row/ egsisitng vector into array ?

[Ivar Nesje]

No, 
array size for Array{T, N} where N > 1 is immutable.

I think I have read somewhere that this is to make it easier to have automatic 
bounds check hoisting in loop, but I don't think we have that yet. 

[julia-users] Performance variability - can we expect Julia to be the fastest (best) language?

[Ivar Nesje]

That was lots of questions. I'll answer one.

>I know to get the best speed, 0.4 is needed. Still, (for the above) what are 
>the problems for 0.3? Have most of the fixed speed issues been backported? Is 
>Compat.jl needed (or have anything to do with speed?) I think slicing and 
>threads stuff (and global?) may be the only exceptions.

We maintain 0.3 for obvious bug fixes, and try to be really careful to not 
introduce new ones. Most of the performance enhancements are deep changes to 
the system that might introduce bugs, so they can't be backported easily.

Compat.jl is a tool you can use to support 0.4 and 0.3 with the same code base, 
without depreciation warnings. It has nothing to do with speed. 

[julia-users] Re: Do julia's profiling capabilities extend to the use of external code with ccall?

[Ivar Nesje]

Julia will not track memory allocations in c programs, but there is a keyword 
argument 

 
to Profile.print that you might try:

Profile.print(C=true)

Ivar

onsdag 25. mars 2015 11.30.39 UTC+1 skrev Patrick Sanan følgende:
>
> I am interested in profiling some julia code, but a substantial fraction 
> of the time and memory usage will be due to functions from an external 
> library, called with ccall. Should I be able to collect data about time 
> spent and memory resources used in this case?
>

[julia-users] Re: Does it make sence to use Uint8 instead of Int64 on x64 OS?

[Ivar Nesje]

If you store millions of them, you can use only 1/8 of the space, and get 
better memory efficiency.

onsdag 25. mars 2015 21.11.05 UTC+1 skrev Boris Kheyfets følgende:
>
> The question says it all. I wonder if on would get any benefits of keeping 
> small things in small containers: Uint8 instead of Int64 on x64 OS?
>

[julia-users] Re: What's the difference between @assert and @test?

[Ivar Nesje]

Good question!

In 0.4 the printing for @test has been improved quite significantly to 
display the values of variables.

julia> a,b = 1,2

julia> @test a==b 
ERROR: test failed: (1 == 2) 
in expression: a == b 
in error at error.jl:19 
in default_handler at test.jl:27 
in do_test at test.jl:50 

julia> @assert a==b
ERROR: AssertionError: a == b


There is some discussion in #10614 
 about means to disable 
assertions, so there is a conceptual difference in that assertions is used 
inside a program to test for invalid inputs to functions, but tests are 
usually runned externally to see that functions work correctly for 
different outputs.

Regards
Ivar

onsdag 25. mars 2015 18.26.30 UTC+1 skrev Ismael VC følgende:
>
> Hello guys!
>
> I just had someone ask me this question and I didn't know what to answer 
> him, example:
>
> julia> using Base.Test
>
> julia> @test 1 == 1
>
> julia> @test 1 == 3
> ERROR: test failed: 1 == 3
>  in error at error.jl:21 (repeats 2 times)
>
> julia> @assert 1 == 1
>
> julia> @assert 1 == 3
> ERROR: assertion failed: 1 == 3
>  in error at error.jl:21 (repeats 2 times)
>
> I fail to see the difference, besides that `@test` conveys the idea of 
> "testing". 
>
> Even the error message is even the same:  `in error at error.jl:21 
> (repeats 2 times)`
>
> Thanks!
>

Re: [julia-users] Symbol to string

[Ivar Nesje]

I'm really sorry. Seems like I should have checked that it actually worked.

I think the missing method could be considered a bug, does anyone know an 
issue for that on Github?

tirsdag 24. mars 2015 14.29.38 UTC+1 skrev verylu...@gmail.com følgende:
>
> `convert` does not seem to work with symbols. I get an error (same for 
> String and UTF8String as well).
> Test commands:
> testdf = DataFrame(A = [1,2,3], B=[2,3,4])
> string(names(testdf)[1]) # works
> convert(String, names(testdf)[1]) # throws error
> convert(ASCIIString, names(testdf)[1]) # throws error
> convert(UTF8String, names(testdf)[1]) # throws error
>
> Best Wishes.
>
> On Sunday, February 1, 2015 at 1:49:50 PM UTC-5, Ivar Nesje wrote:
>>
>> And more generally, for all types that makes sense to convert between, 
>> you can use the convert function
>>
>> convert(String, :blah)
>>
>> (or maybe better, to avoid type instability issues)
>> convert(ASCIIString, :blah)
>> convert(UTF8String, :blah)
>>
>> In 0.4 the default constructor for all types will fallback to convert, so 
>> for your own types, you usually just need to add a convert definition.
>>
>> søndag 1. februar 2015 16.29.48 UTC+1 skrev Milan Bouchet-Valat følgende:
>>>
>>> Le dimanche 01 février 2015 à 07:18 -0800, Arshak Navruzyan a écrit : 
>>> > Hello, 
>>> > 
>>> > A really basic question how do I turn a symbol into a string ? 
>>> > 
>>> > :blah -> "blah" 
>>> julia> string(:blah) 
>>> "blah" 
>>>
>>> Easy, isn't it? 
>>>
>>> Regards 
>>>
>>

[julia-users] Re: Julia v0.3.6

[Ivar Nesje]

There is 25 commits already on the branch.

https://github.com/JuliaLang/julia/compare/v0.3.6...release-0.3

But still 4 issues tagged "backport pending"

https://github.com/JuliaLang/julia/issues?q=+label%3A"backport+pending"+

[julia-users] Re: Uint8 arrays and deprecations in 0.4

[Ivar Nesje]

That depends on what you want to understand. Unsigned types is usually used as 
a generic collection of bits, and it is much easier to see bit patterns when it 
is shown as hex. It is also nice to make them visually distinguished. 

[julia-users] Re: Simple dispatch question

[Ivar Nesje]

If you have a signature

function commonprefix(str_arr::Array{AbstractString,1})

It means that it should only work on Arrays with element type 
AbstractString. If you call it with Array{UTF8String,1}, you can't push! a 
reference to a ASCIIString onto the array (without conversion), so the 
method does not apply. This is an arbitrary choice that the designers of 
Julia made that most users has questioned the decision at some point. The 
technical terms are invariance and contravariance.

Ivar

mandag 16. mars 2015 15.24.13 UTC+1 skrev Sisyphuss følgende:
>
> I have just made the same mistake this morning.
>
>
>
> On Monday, March 16, 2015 at 1:05:32 PM UTC+1, Simon Danisch wrote:
>>
>> It should be commonprefix{S <: AbstractString}(str_arr::Vector{S})
>> (Vector -> typealias Vector{T} Array{T, 1})
>> What you told julia with Vector{AbstractString} is that the function only 
>> takes Vectors with the element type of AbstractString.
>> Though, ["asdasd", "adasd"] has the concrete element type of ASCIIString 
>>
>> Am Montag, 16. März 2015 12:50:19 UTC+1 schrieb Julia User:
>>>
>>> just some simple beginners question:
>>>
>>>
>>> *1. Question:* Why does *Array{AbstractString,1}*: not work?
>>>
>>> ERROR: LoadError: MethodError: `commonprefix` has no method matching 
>>> commonprefix(::Array{ASCIIString,1})
>>>
>>>
>>> function commonprefix(str_arr::Array{AbstractString,1})
>>> min_idx = indmin(str_arr)
>>> common_prefix = str_arr[min_idx]
>>> common_length = length(common_prefix)
>>> # Other code skipped
>>> return common_length
>>> end
>>>
>>> common_endidx = commonprefix(["/home/Downloads/test", 
>>> "/home/Downloads/othertest"])
>>> println("AbstractString: $common_endidx")
>>>
>>>
>>>
>>>
>>>
>>>
>>> *2. Question:* is there an easy way to avoid rewriting most of the 
>>> functions code
>>>
>>>
>>>
>>> function commonprefix(str_arr::Array{ASCIIString,1})
>>> min_idx = indmin(str_arr)
>>> common_prefix = str_arr[min_idx]
>>> common_length = length(common_prefix)
>>> # Other code skipped
>>> return common_length
>>> end
>>>
>>> function commonprefix(str_arr::Array{UTF8String,1})
>>> min_idx = indmin(str_arr)
>>> common_prefix = str_arr[min_idx]
>>> common_length = length(common_prefix)
>>> # Other code skipped
>>> return common_length
>>> end
>>>
>>>
>>> # ASCIIString
>>> common_endidx = commonprefix(["/home/Downloads/test", 
>>> "/home/Downloads/othertest"])
>>> println("ASCIIString: $common_endidx")
>>> # UTF8String
>>> common_endidx = commonprefix(["/home/Downloads/átomos", 
>>> "/home/Downloads/otherátomos"])
>>> println("UTF8String: $common_endidx")
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>

[julia-users] Re: Copy a directory inclusive subfolders and keeping any symlinks.

[Ivar Nesje]

Just for further reference when people find this thread through search: 
#10506 

(sorry for bumping the thread for everyone who will read this)

fredag 13. mars 2015 00.29.23 UTC+1 skrev Julia User følgende:
>
> hi!
>
> Is there an ready or prefered way to copy a directory inclusive subfolders 
> and **keeping any symlinks / relative symlinks**.
>
>
>

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Ivar Nesje]

That's one place off at the end of a 10 petabyte array. We're really planning 
for the future. But as I think about it, we've grown 10 MB to 10 GB arrays in 
20 years, so who knows what the future will bring. 

Personally I think learning the difference between Float and Int is a pretty 
basic programming skill, that is better thought at entry level, than in a "post 
mortem" when something really bad happened. This distinction also makes 
programs easier to read, because it forces one style of programming.

[julia-users] Question: Variable Names lenght / speed

[Ivar Nesje]

There seems to be a limit on 524,288 bytes. (See 
https://github.com/JuliaLang/julia/pull/8241)

Naturally we use a little bit more memory for long variable names when parsing, 
but I highly doubt that it is measurable.

At runtime the length of variable name does not affect the speed.

[julia-users] Re: Something equivalent to Python's xrange()?

[Ivar Nesje]

Python learned that lesson in moving from python 2 to python 3, so Julia 
creates lazy ranges by default. With the focus Julia has on performance, 
this would probably an obvious choice anyway.

For the ideom you present, we actually don't even create a range (because 
of inlining), but generate equivalent machine code to the similar C code.

for (int i = 1; i <= 10; i++){
#println(i)
}

Regards

torsdag 12. mars 2015 14.19.31 UTC+1 skrev Ali Rezaee følgende:
>
> Hi,
>
> I am trying to iterate over a range of numbers. I know I can do this:
>
> for i in 1:10
> println(i)
> end
>
> but, if I am not wrong, it creates a list from 1 to 10 and iterates over 
> it.
> Is there a more memory efficient method so that it does not create and 
> store the list? something that returns an iterator object similar to 
> Python's xrange().
>
> Many thanks
>

Re: [julia-users] Different ways to create a vector of strings in Julia

[Ivar Nesje]

>
> So, what you would want to do is `Array{String,1}()`. 
> That ought to construct a array of strings with dimension 1 but doesn't. 


But in 0.4 you can use Array{String,1}(0) to create a 1d array with 0 
elements. Note that you have to provide the size of the array, and 0 is not 
default (, but maybe it should be?)

Re: [julia-users] Saving timing results from @time

[Ivar Nesje]

>
> The is true, and that is also what I wanted to do. When using @elapsed, 
> should I then be worried about garbage collection affecting my times?


When making benchmarks you should worry about everything!, and make efforts 
to ensure that your synthetic results actually extrapolates to the code you 
optimize based on the benchmarks (or at least know that you might have 
uncertenty in your result). Garbage collection is a quite time consuming 
process that it is hard to predict when it will run. The worst situation is 
if the first algorithm allocates lots of memory, and the second algorithm 
gets penalized when it needs some memory and the GC finds out that it is 
time to collect.

The implementation for @elapsed is very simple 
,
 
so it will not exclude gc or any other overhead. Arguably ignoring it would 
be cheating.

# print nothing, return elapsed time 
macro elapsed(ex) 
quote 
local t0 = time_ns() 
local val = $(esc(ex)) 
(time_ns()-t0)/1e9 
end 
end

@Simon Danish
A benchmarking suite as a package will be really great!

[julia-users] Re: Informal Call for a Julia π - day challenge

[Ivar Nesje]

 

*julia> **big(pi)*

*3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00
 
with 256 bits of precision*

lørdag 7. mars 2015 18.59.47 UTC+1 skrev Alan Edelman følgende:
>
> With about a week left, I'd love to find out how many digits of  π  we can 
> get only from Julia.
>
> Perhaps we can coordinate a worldwide distributed computation this week.
>
>
>

[julia-users] Re: @parallel (+) for and zip()

[Ivar Nesje]

Yes, this is an issue with how @paralell and zip is implemented.

As a temporary fix, you can use 

for (a1,a2) in collect(zip(B,B))
  a1+a2
end

or

for i in 1:min(length(B), length(B))
  a1, a2 = B[i], B[i]
  a1+a2
end


But I'm not sure how that will affect your parallelization efforts.

lørdag 7. mars 2015 00.56.07 UTC+1 skrev Júlio Hoffimann følgende:
>
> Consider this code:
>
> A = eye(3)
> B = {A,A,A}
>
> for (a1,a2) in zip(B,B)
>   a1+a2
> end
>
> It works fine. If I add @parallel (+) it fails with:
>
> exception on 1: ERROR: MethodError: `getindex` has no method matching 
> getindex(::Base.Zip2{Array{Any,1},Array{Any,1}}, ::Int64)
>  in anonymous at no file:1471
>  in anonymous at multi.jl:1320
>  in run_work_thunk at multi.jl:617
>  in run_work_thunk at multi.jl:626
>  in anonymous at task.jl:6
>
> Could you please confirm this is a bug?
>
> -Júlio
>

Re: [julia-users] Pkg.generate reads git user.name with commas

[Ivar Nesje]

We're looking forward to merge your pull request on github when you have time. 
Even the small fixes needs to be done, and the more people that feels 
comfortable with the contribution process, the fewer bugs we'll have. 

Anyway's great to get feedback early so that annoying issues like that, doesn't 
sneak into a release. Don't feel that you can't report an issue without a fix.

[julia-users] Re: Print(char(0x08))

[Ivar Nesje]

I don't think the backspace character will be interpreted as you want it by 
a web browser. It doesn't really make sense in a stored format like HTML.

fredag 6. mars 2015 19.46.28 UTC+1 skrev DP følgende:
>
> I am using juliabox (v0.3.6)
>
> On Saturday, March 7, 2015 at 12:10:16 AM UTC+5:30, Ivar Nesje wrote:
>>
>> It works for me in the standard OSX terminal with a recent 0.4 version. 
>> What kind of system (and julia version) are you on? (versioninfo() tells us 
>> everything we need).
>>
>> fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
>>>
>>> print("123",char(0x08),"567")
>>> println()
>>> print("123",char(0x09),"567")
>>>
>>> 123567
>>>
>>> 123 567
>>>
>>> As per ASCII Characters,
>>>
>>> ht horizontal tab 
>>> bs backspace
>>>
>>> Why backspace is not working?
>>> Am I doing something wrong?
>>> ​
>>>
>>>

[julia-users] Re: Print(char(0x08))

[Ivar Nesje]

It works for me in the standard OSX terminal with a recent 0.4 version. 
What kind of system (and julia version) are you on? (versioninfo() tells us 
everything we need).

fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
>
> print("123",char(0x08),"567")
> println()
> print("123",char(0x09),"567")
>
> 123567
>
> 123 567
>
> As per ASCII Characters,
>
> ht horizontal tab 
> bs backspace
>
> Why backspace is not working?
> Am I doing something wrong?
> ​
>
>

[julia-users] Re: Confused about parametrization type

[Ivar Nesje]

   
   1. Make sure that your code is correct for the inputs you allow. There 
   is no need to accept BigFloat (nor Float16) if you end up converting to 
   Float64 for the calculation anyway (the user of your code can do that 
   himself). If you don't care enough about different precisions to even think 
   about  how it will affect your program, I think it is better to add a TODO 
   comment in the code/documentation, so that others that care might submit 
   the required changes in a PR.
   2. Testing your algorithm with random Float16 and BigInt will sometimes 
   raise new issues that affects Float64, but is much harder to find there. 
   There is definitely value in thinking about how different makes a 
   difference (or why it doesn't).


Usually you shouldn't use abstract types in a type definition, but rather 
make a parametric type. This is for performance, because the current Julia 
runtime is very slow if it can't statically infer the types of the members 
of a type. See that

type A{T<:FloatingPoint}
  member::T
end

is usually much better than

type A
member::FloatingPoint
end

Regards
Ivar

torsdag 5. mars 2015 18.27.38 UTC+1 skrev Simon Danisch følgende:
>
> I think it's a good idea to have things parametric and type stable. So I'd 
> vote for T <: FloatingPoint.
> Like this, the type you call a function with can be propagated down to all 
> other functions and no conversions are needed.
> As you said, this gets difficult as some people have Float64 hard coded 
> all over the place. It's understandable as John pointed out. 
> But for someone like me who works with GPU's which depending on the 
> graphics card perform up to 30 times faster with Float32, this is quite 
> annoying as I always need to convert©.
>
> Am Donnerstag, 5. März 2015 17:55:40 UTC+1 schrieb Benjamin Deonovic:
>>
>> Moving a post from julia issues to here since it is more appropriate: 
>> https://github.com/JuliaLang/julia/issues/10408
>>
>> If I am making a function or composite type that involves floating point 
>> numbers, should I enforce those numbers to be Float64 or FloatingPoint? I 
>> thought 
>> it should be FloatingPoint so that the function/type will work with any 
>> kind of floating point number. However, several julia packages enforce 
>> Float64 (e.g. Distributions package Multinomial distribution) and so I run 
>> into problems and have to put in a lot of converts in my code to Float64. Am 
>> I doing this wrong? I'm quite new to julia
>>
>>
>> I don't have any intention to use non Float64 floatingpoints numbers, I'm 
>> just trying to write good code. I saw a lot of examples where people 
>> recommended to to use Integer rather than Int64 or String rather than 
>> ASCIIString, etc. I'm just trying to be consistent. I'm fine just using 
>> Float64 if that is the appropriate approach here.
>>
>

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

[Ivar Nesje]

>
>  I'd also like a REPL command which prints out a list of all of the 
> objects currently in memory space (like 'whos' in Octave)

I'd recommend you try the obscurely named whos() in Julia :)

torsdag 5. mars 2015 14.38.05 UTC+1 skrev David Higgins følgende:
>
> Oh, and an IDE is the other requirement of my hard core programming 
> brethren. The debugger is higher on their list of priorities, but the IDE 
> is also vital (and one capable of handling projects, etc. we do large scale 
> numerical projects).
>
> David.
>
> On Thursday, 5 March 2015 14:35:23 UTC+1, David Higgins wrote:
>>
>> I agree with many of the comments above. I recommend Julia only to a 
>> subset of my colleagues. From Matlab the barrier to entry is incredibly low 
>> and you gain on both speed and price, the only argument against is that 
>> Matlab users tend to have years of experience in their one language and not 
>> such a habit of learning new languages.
>>
>> I personally moved from mainly GPGPU based programming using C; despite 
>> the difficulty of that field I found the move painful due to a lack of 
>> detailed documentation (my perception). Don't get me wrong, there's enough 
>> documentation out there to make a decent stab at getting things done. But 
>> I'm used to having a much more nuanced understanding of a language and the 
>> documentation doesn't yet go into this level of detail, nor are there 
>> sufficient examples out there.
>>
>> For my colleagues who are strong programmers (Python particularly), they 
>> refuse to touch the language until there's a debugger. At the very least 
>> they want to be able to set breakpoints and run to them. Personally, I'd 
>> also like a REPL command which prints out a list of all of the objects 
>> currently in memory space (like 'whos' in Octave). This seems like a basic 
>> requirement for REPL based numerical programming.
>>
>> Julia is elegant and growing strongly, but I'm still quite selective 
>> about who I proselytise to. I have the feeling that it will be so many 
>> times a more comfortable experience in 6-12 months time that I'd rather not 
>> colour people's early experiences in a negative light if better is soon to 
>> come.
>>
>> David.
>>
>

[julia-users] Re: Bad julia performance on aligned memory accesses

[Ivar Nesje]

Benchmarks like this is kind of useless because you're doing a meaningless 
task, that one of the systems optimize away, but the other faithfully does 
in the inefficient manner you prescribed.

This is because Octave (and Matlab) uses copy on write (COW) semantics and 
has spent huge efforts to use memory efficient in vectorized expressions. 
That way they don't need to copy anything, and save a tremendous amount of 
time on such simple benchmarks on copying performance. Copy on write is 
often easier for users, but much harder to deeply understand in order to 
implement efficient algorithms. It's easy to construct similar benchmarks 
where the COW semantics causes similar performance issues the other way, so 
that is definitely a double edged sword.

Another issue here is that Julia has to do twice as much copying as you 
might expect, because a[1:n,1:n] currently creates a copy instead of a view 
to the same memory, and then it needs to be copied again into b. One of the 
targets for Julia 0.4 is to make a[1:n,1:n] return a View instead of a full 
copy and that will make a huge difference.

The most efficient way to do what you are trying (without cheating by using 
the observation that nothing really needs to be done) is to replace the 
code with copy!(b,a). You will see that the execution time is cut to around 
1/3, because you elimit lots of temporary arrays and half of the copying.



PS: Generally Julia also prefer to be benchmarked in a function that 
doesn't access globals, so that we get full benefit of our JIT compiler. 
Real performance sensitive code is usually written that way, so thats the 
code we want to be really sure is fast. This doesn't matter much in this 
example, but if your benchmark isn't limited by calls to library code, 
you'll see a huge difference.

n=1000;
b = Array(Float64,n,n);
a=rand(n,n);

function test(n,b,a)
for i=1:1
b[1:n,1:n]=a[1:n,1:n];
#b=a;
 end
end

@time test(n,b,a)
@time test(n,b,a)



torsdag 5. mars 2015 09.15.34 UTC+1 skrev Ranjan Anantharaman følgende:
>
> Hello I was comparing the performance of two snippets of MATLAB (running 
> on Octave) and Julia code on Windows. 
>
> MATLAB code:
>
> n=1000;
> a=rand(n,n);
>
> tic
> for i=1:1
> b(1:n,1:n)=a(1:n,1:n);
> %b=a;
> end
> toc
>
> JULIA Code: 
>
> n=1000;
> b = Array(Float64,n,n);
> a=rand(n,n);
>
> tic();
> for i=1:1
>   b[1:n,1:n]=a[1:n,1:n];
>   #b=a;
> end
> toc();
>   
> I understand that both the statements in the loop are b=a, but I decided 
> to index the arrays and see what happened. 
>
> The MATLAB code takes 0.22 seconds (on Octave ) whereas the JULIA code 
> takes between 80 to 100 seconds (varies every time). 
>
> I think Octave is performing some simple optimization here, and I think 
> Julia might benefit from the same. 
>
> Version info: Octave 3.6.4 and Julia 0.4.0-dev (but I saw the same happen 
> in 0.3.5 too)
>
>
>

[julia-users] Exponential function approximation

[Ivar Nesje]

Casting is called reinterpret in Julia. 

[julia-users] Re: Repmat speed

[Ivar Nesje]

Fixing the type declarations for inner and outer (Array{Int,1} instead of 
Array{Int}), and isolating the type unstable R array filling in a extra 
function, cut the time down from 1.5 to 1 second. There are still a huge 
difference though.

A ugly attempt is at https://github.com/julialang/julia/commit/fe359a4 

mandag 2. mars 2015 13.25.48 UTC+1 skrev Simon Kornblith følgende:
>
> Keyword arguments can add additional overhead when calling a function and 
> prevent its return type from being inferred properly, but the code that 
> runs is specialized for the types of the keyword arguments, so I don't 
> think keyword arguments alone explain this. But it looks like there is some 
> type instability inside repeat because it creates arrays where the number 
> of dimensions can't be inferred.
>
> Simon
>
> On Monday, March 2, 2015 at 5:35:15 AM UTC-5, Ivar Nesje wrote:
>>
>> The speed difference is because Julia doesn't specialize for specific 
>> types for keyword arguments, and type unstable code creates really slow 
>> loops in Julia.
>>
>> Thanks for reporting, I'll work on a fix.
>>
>> mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
>>>
>>> Hi Steven,
>>>
>>> Thanks for your answer but my question is a bit different.
>>> I'm not asking about creating a mesh grid and how or why doing it. 
>>> My question is more "naive": 
>>> Why the first method is faster than the 2 with only (well written) 1 
>>> line command.
>>>
>>> and a more general question is: why "repeat" is slower than "repmat"   , 
>>> for example: 
>>>
>>> *tic(); repmat([1:10],1000,1000); toc()*
>>>
>>> elapsed time: 0.035878247 seconds
>>>
>>>
>>> *tic(); **repeat([1:10],outer=[1000,1000]);** toc()*
>>>
>>> elapsed time: 1.176858309 seconds
>>>
>>> Thanks
>>>
>>>
>>> Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :
>>>>
>>>> Hello, 
>>>>
>>>> I have a question about the best way to implement a grid similar to a 
>>>> mesh grid: 
>>>> My first intuition was to do the following: 
>>>>
>>>> nx = 256
>>>> nb = 195
>>>>
>>>> kx = [-nx/2:-1+nx/2]
>>>>
>>>> tic()
>>>> k1   = repmat(kx,1,nx)
>>>> k1v = vec(k1)'#/nx
>>>> k1m = repmat(k1v,nb,1)
>>>> toc()
>>>> # 0.0256 sec 
>>>>
>>>> Then I tried in one operation the following: 
>>>> tic()
>>>> ka = repeat(kx,outer=[nx,nb])'# reshape( 
>>>> repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
>>>> toc()
>>>> # 0.477
>>>>
>>>> Does somebody knows why the repeat is ~20 times slower than the 
>>>> repeat/vec/repmat 
>>>> Is it the best way to do this ?
>>>>
>>>> Thanks in advance
>>>>
>>>> Bests.
>>>>
>>>> Antony
>>>>
>>>>

[julia-users] Re: Repmat speed

[Ivar Nesje]

The speed difference is because Julia doesn't specialize for specific types 
for keyword arguments, and type unstable code creates really slow loops in 
Julia.

Thanks for reporting, I'll work on a fix.

mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
>
> Hi Steven,
>
> Thanks for your answer but my question is a bit different.
> I'm not asking about creating a mesh grid and how or why doing it. 
> My question is more "naive": 
> Why the first method is faster than the 2 with only (well written) 1 line 
> command.
>
> and a more general question is: why "repeat" is slower than "repmat"   , 
> for example: 
>
> *tic(); repmat([1:10],1000,1000); toc()*
>
> elapsed time: 0.035878247 seconds
>
>
> *tic(); **repeat([1:10],outer=[1000,1000]);** toc()*
>
> elapsed time: 1.176858309 seconds
>
> Thanks
>
>
> Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :
>>
>> Hello, 
>>
>> I have a question about the best way to implement a grid similar to a 
>> mesh grid: 
>> My first intuition was to do the following: 
>>
>> nx = 256
>> nb = 195
>>
>> kx = [-nx/2:-1+nx/2]
>>
>> tic()
>> k1   = repmat(kx,1,nx)
>> k1v = vec(k1)'#/nx
>> k1m = repmat(k1v,nb,1)
>> toc()
>> # 0.0256 sec 
>>
>> Then I tried in one operation the following: 
>> tic()
>> ka = repeat(kx,outer=[nx,nb])'# reshape( 
>> repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
>> toc()
>> # 0.477
>>
>> Does somebody knows why the repeat is ~20 times slower than the 
>> repeat/vec/repmat 
>> Is it the best way to do this ?
>>
>> Thanks in advance
>>
>> Bests.
>>
>> Antony
>>
>>

Re: [julia-users] Re: pmap not respecting srand set seed settings

[Ivar Nesje]

If you find evidence that there is anything wrong with the first N random 
numbers in the standard Random Number Generator (RNG) in Julia, we would 
consider that a bug, fix it, and release a new point release faster than a 
Lenovo CTO is able to arrange a meeting with someone who understands the https 
protocol.

You should still be aware that we optimize for speed and statistical bias, so 
you should not rely on the built-in RNG for cryptography or other security 
related purposes.

[julia-users] Is it safe to take a pointer to a temporary array?

[Ivar Nesje]

No, pointer doesn't keep a reference to the original array. See 
http://docs.julialang.org/en/latest/stdlib/c/?highlight=pointer#Base.pointer

The second call can be written safely as

ccall((:fun, :lib), Void, (Ptr{Int64},), [1,2])

[julia-users] Re: building Julia could not allocate pools

[Ivar Nesje]

Thanks for reporting

The error seems to be coming from /src/gc.c#L482 
,
 
which was added in #8699  which 
was merged 24 Ja 
n 
 (~30 days 
ago)

As nobody else has reported this, someone will probably need more 
information about your system in order to debug this properly, as it likely 
is system dependent. Can you try to download any of the pre-buildt binaries 
to see if they work?

Ivar



fredag 27. februar 2015 14.18.55 UTC+1 skrev lapeyre@gmail.com følgende:
>
> Anyone know something about this ?
>
> I did not build the latest Julia (master branch) since about 30 days.
> Now, when I do 'git pull' and 'make' I am getting various error messages:
>
>could not allocate pools
>Aborted
>Makefile:165: recipe for target 
> '/home/jlapeyre/software_source/julia/usr/lib/julia/sys0.o' failed
>
> This was a few days ago, so I 'pulled' every once in a while, hoping the 
> problem would go away.
> I tried make clean, make cleanall, make distcleanall. Then dependencies 
> also fail to build
> I removed even the packages with   make -C deps distcleanall.
>
> I have not changed my tool chain since the last successful build. I can't 
> recall, but there is a
> chance (but, I think not) that I moved the entire repository from one 
> place to another.
>
> Since I don't see any noise about this, something tells me its not a 
> common problem.
>
> --John
>

[julia-users] pmap not respecting srand set seed settings

[Ivar Nesje]

I think something like @everywhere srand(seed) would partially work, but you'd 
still suffer from non determinism in the scheduler that might run different 
portions of the array in different processes depending on the current load on 
your computer. 

[julia-users] pmap not respecting srand set seed settings

[Ivar Nesje]

No, that is not possible with pmap. 

[julia-users] Is it OK (stylistically) to override missing Base functionality in a package?

[Ivar Nesje]

We have seen quite a few instances where Base functions were extended with 
methods without restriction to non-Base types, and it caused problems when 
Julia was updated.

Is randomly breaking in new versions of Julia your style?

Re: [julia-users] Re: World of Julia

[Ivar Nesje]

Strange that GitHub excludes merge commits on their site, but not in their 
API.

mandag 23. februar 2015 19.57.19 UTC+1 skrev Jiahao Chen følgende:
>
> Fair enough, but that would mean actually parsing the commit history :)
>
> Thanks,
>
> Jiahao Chen
> Staff Research Scientist
> MIT Computer Science and Artificial Intelligence Laboratory
>
> On Mon, Feb 23, 2015 at 1:08 PM, Patrick O'Leary  > wrote:
>
>> On Sunday, February 22, 2015 at 5:50:09 PM UTC-6, Jiahao Chen wrote:
>>>
>>> World of Julia is now updated in time for the 2015 Oscars.
>>>
>>> 336 contributors to JuliaLang/julia
>>> 545 packages
>>> 695 devs total
>>>
>>> IJulia notebook: https://github.com/jiahao/ijulia-notebooks/blob/
>>> master/2014-06-30-world-of-julia.ipynb
>>>
>>> Nbviewer link: http://nbviewer.ipython.org/urls/raw.github.com/
>>> jiahao/ijulia-notebooks/master/2014-06-30-world-of-julia.ipynb
>>>
>>
>> A small suggestion: it may be more insightful if you remove merge 
>> commits; I would say I'm definitely overcounted in the current results.
>>
>
>

Re: [julia-users] Re: -1 days old master

[Ivar Nesje]

Git stores committer time with timezone, and we ask git for a UNIX timestamp 
and compare to the current system unix timestamp on startup, so I'm pretty sure 
we do things correctly.

If the system clock is wrong, there is not much we can do.

Re: [julia-users] computing speed of log

[Ivar Nesje]

Also log will throw a DomainErrror in Julia if you give it a negative 
argument. That is another check and might prevent some optimizations.

onsdag 18. februar 2015 21.36.12 UTC+1 skrev Stefan Karpinski følgende:
>
> What system are you on? And what libm are you using?
>
> On Wed, Feb 18, 2015 at 3:31 PM, Stefan Karpinski  > wrote:
>
>> Depends on how fast your system libm is – and how accurate. There's a 
>> tradeoff.
>>
>> On Wed, Feb 18, 2015 at 3:07 PM, Rohan Fernando > > wrote:
>>
>>>
>>>
>>> The log and exponential functions in Julia are about five times slower 
>>> than in C++. Is this reasonable? 
>>>
>>
>>
>

[julia-users] Re: pcre-8.31 checksum failure

[Ivar Nesje]

Nothing seems to have changed with regards to pcre the last 9 months, and I 
just tried to download it and it worked.

It might have been some intermittent error with the server, so delete the 
file and try again.

onsdag 18. februar 2015 12.04.26 UTC+1 skrev Patrick Sanan følgende:
>
> I'm getting the following error when trying to build on the release-0.3 
> branch. Is this likely an issue with my network, or has something changed 
> recently?
>
>
> ===
>   ERROR: sha512 checksum failure on pcre-8.31.tar.bz2, should be:
>   bdc369b967f1d9db36d228fb291a436611d19c2f7df64a265a5c748f797763b8
>   d66e161fd0ecd60a8a9f28fa3bc7d22d61e619c9a16c5a26c71923e2b1802145
>   But `shasum -a 512 pcre-8.31.tar.bz2 | awk '{ print $1; }'` results in:
>   d1bf6ce313d8d8cabfd9276a234a2b53b7c400044173e9319c0d235c87334a7e
>   e1ae8895b47fdba684c018514f6da9d57dda9734330b9e50a8b63b017c06d49c
>   This can happen due to bad downloads or network proxies, please check 
> your
>   network proxy/firewall settings and delete deps/pcre-8.31.tar.bz2
>   to force a redownload when you are ready
>
> ===
>

Re: [julia-users] Re: -1 days old master

[Ivar Nesje]

Definitely possible. The code is at 
https://github.com/JuliaLang/julia/blob/master/base/version.jl#L210

Re: [julia-users] Re: -1 days old master

[Ivar Nesje]

Nice, I'm glad my code didn't crash when given unexpected input.

Maybe we should check the system clock against a online time server when you 
run make test. We just use the timestamp git adds when committing, so other 
than that, there doesn't seem like there is much new can do.

Re: [julia-users] Various questions about Int(), int(), and 0.4

[Ivar Nesje]

Array{Int}(A)

Should probably also work soon.

Re: [julia-users] Various questions about Int(), int(), and 0.4

[Ivar Nesje]

I definitely agree that the info message has some confusing aspects.  Please 
open an issue (or a PR) with Lint.jl so that the info reads something like.

INFO: In 0.4, replace int() with Int(), or some of the other explicit rounding 
functions. (round, trunc, etc...)

Re: [julia-users] Colour blind friendly defaults for plotting?

[Ivar Nesje]

Thanks for bringing up this important issue. There was some previous discussion 
in https://github.com/dcjones/Gadfly.jl/issues/21 that might interest you.

Re: [julia-users] Define `similar` function for a custom array

[Ivar Nesje]

Please don't tell him to use +1 and -1 to manipulate UTF8String indexes. Use 
nextind and prevind. 

[julia-users] Re: Utility / purpose of Pair() in 0.4?

[Ivar Nesje]

 Pair is defined as

immutable Pair{A,B}
first::A
second::B
end

, so it is type specialized with two parameters A and B.

Pair has its own syntax key => value and is used extensively with dicts.

Ivar

onsdag 4. februar 2015 19.58.42 UTC+1 skrev Seth følgende:
>
> I stumbled across Pair by accident and didn't find anything in the way of 
> docs, so I started playing with it and looking at the source.
>
> I can't figure out what the use case might be. It doesn't appear to be 
> type-optimized; that is, it doesn't use type parameterization to provide 
> speed/efficiency gains. It appears to allow Any=>Any, which I guess might 
> be useful, but I don't see how it might be better than a tuple. Using it in 
> lieu of an explicit type such as 
>
> immutable Edge
> src::Int
> dst::Int
> end
>
> results in (my) code being an order of magnitude slower - I assume it's 
> because I've specified the types of the members.
>
> What is the intended use case for the Pair type, and did I miss the 
> documentation?
>
>

[julia-users] Re: Types with keywords as field names

[Ivar Nesje]

I would imagine that symbol("try") and @eval does make this possible, but as 
the syntax for using the type will also use the same thrick, you will get 
pretty incomprehensible code. 

[julia-users] Re: select! with range creating a memory allocation

[Ivar Nesje]

Yes, if you are on windows, the nightly installer is the easiest way. Be sure 
to keep the old downloads, and remember what versions you use so that you can 
revert if a new change causes trouble with your setup. (How careful you must 
be, depends on how acceptable it is for you to have a broken Julia install 
until you adapt your code to a breaking change)

[julia-users] Re: Data structure with variable length outputs

[Ivar Nesje]

As you probably realized vcat makes a copy of the vector, so it is 
inefficient when you use it repeatedly. Julia provides the push! and append! 
functions 
so that you can efficiently add elements to the end of a vector. There is 
also a sizehint! function if you know how many elements there will 
ultimately be, and want to save a few copies when the array grows. 

søndag 1. februar 2015 15.31.40 UTC+1 skrev Christopher Fisher følgende:
>
> Hi all-
>
> I am trying to figure out a graceful way to store output from a model 
> simulation. Each simulated trial produces a single reaction time, a single 
> choice and a vector of visual fixations generated by a Markov chain. The 
> complicating factor is that the size of the vector of visual fixations 
> varies on each simulated trial and I would like to generate multiple 
> simulated trials. Is there a way to store these outputs in a data structure 
> that will be easy to access in other functions?
>
> A related issue is the dynamic nature of the vector size. I am currently 
> using vcat to add new values to the vector. Is there a more efficient 
> method?
>
> Thank you in advance for your help.
>

[julia-users] Re: select! with range creating a memory allocation

[Ivar Nesje]

This issue will fix itself when `a[r]` returns a subarray with 0.4 (this 
hasn't landed in master yet, and reminds me that the pending change will 
require a huge documentation effort that change affect APIs).

The improved garbage collection that was merged in master recently will 
likely greatly reduce the performance penalty for such short lived 
allocations.

Ivar

søndag 1. februar 2015 11.53.02 UTC+1 skrev julia.e...@gmail.com følgende:
>
> I realize this is a more developer issue, but I'm wondering if anyone else 
> thinks it would be a good idea for select! to be changed to not return A[r] 
> (which allocates memory).
>
>
> I think it could return (A[r.start], A[r.stop]), sub(A, r) or even 
> nothing.  As it stands it seems like a performance penalty that can be 
> avoided since the rest of the function should operate on memory in place. 
>
>
> In my own project I've made a local copy of select for this reason and 
> taken out the return value.
>

Re: [julia-users] Symbol to string

[Ivar Nesje]

And more generally, for all types that makes sense to convert between, you 
can use the convert function

convert(String, :blah)

(or maybe better, to avoid type instability issues)
convert(ASCIIString, :blah)
convert(UTF8String, :blah)

In 0.4 the default constructor for all types will fallback to convert, so 
for your own types, you usually just need to add a convert definition.

søndag 1. februar 2015 16.29.48 UTC+1 skrev Milan Bouchet-Valat følgende:
>
> Le dimanche 01 février 2015 à 07:18 -0800, Arshak Navruzyan a écrit : 
> > Hello, 
> > 
> > A really basic question how do I turn a symbol into a string ? 
> > 
> > :blah -> "blah" 
> julia> string(:blah) 
> "blah" 
>
> Easy, isn't it? 
>
> Regards 
>

Re: [julia-users] short circuit list comprehension

[Ivar Nesje]

any() is short-circuiting if the length of array is more than 16. That 
seems like dubious semantics to me.

Ivar

fredag 30. januar 2015 09.39.28 UTC+1 skrev Mike Innes følgende:
>
> Ok, I now see that `all` isn't short-circuiting, which is kind of 
> surprising/annoying. Anyone know why that is?
>
> You can easily define your own short-circuiting `all` to do this:
>
> all′(f, xs) =
>   isempty(xs) ? true :
>   f(xs[1]) && all′(f, xs[2:end])
>
> The other thing you could try is to check out Lazy.jl. If you call, for 
> example,
>
> @time all(map(f,list(1,2,3,5)))
>
> The `list` construct actually takes care of short-circuiting for you, so 
> what looks like a very expensive `map` operation is actually very cheap.
>
> On 30 January 2015 at 08:05, Mike Innes 
> > wrote:
>
>> How about `all(f, values)`?
>>
>> On 30 January 2015 at 06:51, Wai Yip Tung > > wrote:
>>
>>> I want to apply function f() over a range of value. f() returns true for 
>>> success and false for failure. Since f() is expensive, I want short circuit 
>>> computation, i.e. it stops after the first failure. 
>>>
>>> In python, I can do this in an elegant way with the all() function and 
>>> generator expression.
>>>
>>> if all(f(x) for x in values)
>>>   # success
>>> else
>>>   # failure
>>>
>>> From what I understand, there is no generator expression in Julia. List 
>>> comprehension will evaluate the full list. Even if I try to use for loop, I 
>>> can't use the control variable to check if the loop has run to finish or 
>>> not.
>>>
>>> i = 0
>>> for i in 1:length(values)
>>> if !f(values[i])
>>>   break
>>>end
>>> end
>>> # The status is ambiguous if i==length(values) 
>>>
>>> My last resort is to add flags to indicate if is success or not. Is 
>>> there some more elegant way to do this?
>>>
>>>
>>
>

[julia-users] Looking for suggsetions to speed up function calls that have @cpp ccall()

[Ivar Nesje]

Did you time your function twice? The first time you call a function it needs 
to be compiled, and for very small tests, that process will dominate.

julia-users@googlegroups.com

[Ivar Nesje]

You need to use  

(&)([true,true], [true,false],[false,true])

I think this is because & is used as a special character in ccall. I have 
seen this raised a few times, but I don't know what to search for to find 
the previous discussions.

Regards Ivar

mandag 26. januar 2015 15.33.06 UTC+1 skrev Patrick O'Leary følgende:
>
> Using JuliaParser.jl as a reference, it loks like & is in the class 
> unary_and_binary_ops, as well as syntactic_binary_ops. The | operator is 
> not in either of these classes. At least one reason for the difference in 
> lowering to the AST is that & is also an addressof-like operator in the 
> context of a ccall. I suspect, however, that the inconsistency in usage of 
> the surface syntax can be regarded as a bug--you should go ahead and file 
> an issue.
>
> On Monday, January 26, 2015 at 6:28:49 AM UTC-6, Gabriel Mitchell wrote:
>>
>> Here are two statements, one written with chained binary operations the 
>> other in prefix notation 
>>
>> >>[true,true] | [true,false] | [false,true]
>> 2-element Array{Bool,1}:
>>  true
>>  true
>> >>|([true,true], [true,false],[false,true])
>> 2-element Array{Bool,1}:
>>  true
>>  true
>>
>>
>> Now I can also do the first for & as in
>> >>[true,true] & [true,false] & [false,true]
>> 2-element Array{Bool,1}:
>>  false
>>  false
>>
>> However if I try this in the prefix notation
>>
>> &([true,true], [true,false],[false,true])
>>
>> unsupported or misplaced expression &
>> while loading In[32], in expression starting on line 1
>>
>> Looking a little closer, I find that the parser does this
>>
>> >>:(|([true,true], [true,false],[false,true])).head
>> :call
>> >>:(&([true,true], [true,false],[false,true])).head
>> :&
>>
>> Can someone tell me, is this behavior for '&' on purpose? If so can 
>> someone point to some documentation so I can read about said purpose? I was 
>> interested in making calls in the function prefix notation so that i can 
>> write something like '&(bunchofarrays...)'. This works for '|' but not for 
>> '&' on my version (0.3.4). Or if there is a more idiomatic way to achieve 
>> this effect I'd also like to here.
>>
>>

[julia-users] Re: Creating an array of arrays

[Ivar Nesje]

This behaviour is intended and as I understand it a relic from Matlab 
(where you can't have arrays of arrays). It is the basis for a convenient 
array construction from a range (eg, [1:5] gives [1,2,3,4,5] instead of an 
array with a Range object), so there are more to it than you might think.

There seems to be lots of people arguing against this behaviour, so I 
expect it to change at some point.

See: #8599  and linked issues 
for more discussion.

Regards Ivar

mandag 26. januar 2015 10.47.17 UTC+1 skrev Michael Partheil følgende:
>
> Dear all,
>
> just a short question about something I found quite a bit confusing: I 
> want to create an Array of Array of Int, so I wrote:
> julia> [[1,2], [3,4]]
> 4-element Array{Int64,1}: 
>  1 
>  2 
>  3 
>  4
>
> As you can see this turns into an Array of Ints instead, i.e. the inner 
> brackets are ignored. It works if I explicitly specify the type:
> julia> Vector{Int}[[1,2], [3,4]]
> 2-element Array{Array{Int64,1},1}:
>  [1,2]
>  [3,4]
>
> Is this behavior intended? Is there a better/recommended way to create an 
> Array of Arrays? I would be happy if someone could briefly clarify this!
>
> Thanks a lot
> Michael
>
> PS: I'm using Julia 0.3.2 on OSX 10.9.5
>

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

[Ivar Nesje]

Currently we bundle loads of binary dependencies in order to include batteries 
for common cases. There will always be some tension about what to include, so 
creating different distributions seems to be the way to please everyone. 

See also https://github.com/JuliaLang/julia/issues/5155

Re: [julia-users] Why are macro's arguments treated as tuples despite having no parentheses around them?

[Ivar Nesje]

See also #7232 <https://github.com/JuliaLang/julia/issues/7232> where the 
suggestion is to disallow space before the parenthesis in function 
definitions and function calls. That will at least make julia code more 
consistent in that functions and macros work more similarly.

lørdag 24. januar 2015 17.00.17 UTC+1 skrev Erik Schnetter følgende:
>
> On Jan 24, 2015, at 2:53 , Ivar Nesje > 
> wrote: 
> > 
> > See also 
> > 
> > @test(1, 2, 3, 4) 
>
> ... and compare this to 
>
> @test (1, 2, 3, 4) 
>
> (with white space before the parenthesis). 
>
> That's a part of Julia's syntax that I don't like. On the other hand, the 
> ability to pass whitespace-separated arguments to macros instead of only 
> comma-separated values is a very powerful feature, as it allows passing in 
> statements without having to wrap them in parentheses. 
>
> -erik 
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>
> My email is as private as my paper mail. I therefore support encrypting 
> and signing email messages. Get my PGP key from https://sks-keyservers.net. 
>
>
>

[julia-users] Are there macros that expand to file name, function name and line numbers like in C?

[Ivar Nesje]

There is 
http://docs.julialang.org/en/latest/stdlib/file/?highlight=file#Base.@__FILE__, 
but the others are not yet implemented. 

[julia-users] Re: Why are macro's arguments treated as tuples despite having no parentheses around them?

[Ivar Nesje]

See also 

@test(1, 2, 3, 4)

[julia-users] Re: How do I print the name of the passed argument in a macro when it is an anonymous function

[Ivar Nesje]

No, using eval inside a macro is (almost) never what you want.

A macro is a function that transform one expression to another expression. You 
should return an expression that print the string version of the input, not 
print directly in the macro. 

[julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Ivar Nesje]

Originally posted at https://github.com/JuliaLang/julia/issues/9863

[julia-users] julia array type?

[Ivar Nesje]

The problem here is a parsing ambiguity, because tuples support indexing. I 
believe there is an issue on github for this, but I can't figure out what to 
search for.

It might be more obvious that (Float64, Int)[2] is ambiguous. 

[julia-users] Re: How to find if a variable is empty or not?

[Ivar Nesje]

> but this is uggly

And it will change in 0.4 (I think)

Re: [julia-users] disable @inbounds in tests?

[Ivar Nesje]

Pretty much anything. Compiler bugs are certainly possible, but also bugs in 
the standard library. Generally pure Julia code shouldn't segfault, unless 
you're using ccall or the unsafe_ family.

If you can post a link to a reasonably short segfaulting example here, there is 
a good chance that someone will look at it and find the bug.

[julia-users] Re: Error: zeros(UTF8String, 5)

[Ivar Nesje]

And why isn't this most frequently asked question covered in our FAQ? 

http://docs.julialang.org/en/latest/manual/faq/

Re: [julia-users] Error: zeros(UTF8String, 5)

[Ivar Nesje]

I think there might have been a package that defined something like this once. 
Do you get this error from a package? 

[julia-users] Re: Julia cannot compute factorial(21) while Octave can

[Ivar Nesje]

Currently *OverflowError* doesn't have a message field, so to do this, you 
have to either let showerror 

 
check the backtrace to look for *factoria*l or add a text field, so that 
factorial can add the message to the exception.

I think we eventually want all exceptions to have a string field with a 
message, but there has been raised some concerns about the performance 
overhead in some situations. It seems possible to fix that problem, but I 
don't really understand the underlying issues well enough to comment on 
that.

Ivar

onsdag 14. januar 2015 21.48.36 UTC+1 skrev g følgende:
>
> Is there a way to provide a suggestion with the error?
>
> It currently says this, 
>
> *julia> **factorial(21)*
>
> *ERROR: OverflowError()*
>
> * in factorial_lookup at combinatorics.jl:27*
>
> * in factorial at combinatorics.jl:35*
>
> Maybe it would be more useful if it said
>
> *julia> **factorial(21)*
>
> *ERROR: OverflowError("perhaps you want factorial(big(21)) instead?")*
>
> * in factorial_lookup at combinatorics.jl:27*
>
> * in factorial at combinatorics.jl:35*
>
> On Wednesday, January 14, 2015 at 11:37:17 AM UTC-7, Viral Shah wrote:
>>
>> I am guessing, that like Matlab, octave uses doubles to represent 
>> integers, and hence you can go a bit farther than with integers. That 
>> should be the same as factorial(21.0) in julia. Of course, you can also use 
>> BigInt and such, which has already been discussed here.
>>
>> -viral
>>
>> On Tuesday, January 13, 2015 at 8:40:06 AM UTC+5:30, Carlos Baptista 
>> wrote:
>>>
>>> I understand that factorial(21) is quite a large number and therefore an 
>>> OverflowError is perfectly understandable. However, with Octave I can go up 
>>> to factorial(170) (if I go higher I receive Inf). Is there a way to go 
>>> beyond factorial(20) in Julia?
>>>
>>

[julia-users] Re: Constructors for types containing other types

[Ivar Nesje]

I can see two solutions. Either you define an outer constructor for 
MyOtherType,

MyOtherType(i::Int) = MyOtherType(MyType(i))

or you can consider MyType equivalent to an Int, so that you define convert

convert(::Type{MyType}, i::Int) = MyType(i)

Ivar

tirsdag 13. januar 2015 07.24.25 UTC+1 skrev Nathaniel Virgo følgende:
>
> I have a custom type with a constructor function, and I have another type 
> that has several members of this type. The problem is that the inner type's 
> constructor doesn't get called when I would expect it to. Here is a minimal 
> example to show what I mean:
>
> type MyType
>  member::Int64
>  anothermember::Float64
> end
>
> function MyType(value::Int64)
>  return MyType(value, 0.0)
> end
>
> foo = MyType(42)  # ok
>
> type MyOtherType
>  member::MyType
> end
>
> bar = MyOtherType(42)  # this gives an error
>
>
> The error this gives is as follows:
>
> ERROR: `convert` has no method matching convert(::Type{MyType}, ::Int64)
>  in convert at base.jl:13
>  in include at /Applications/Julia-0.3.3.app/Contents/Resources/julia/lib/
> julia/sys.dylib
>  in include_from_node1 at loading.jl:128
>  in process_options at /Applications/Julia-0.3.3.app/Contents/Resources/
> julia/lib/julia/sys.dylib
>  in _start at /Applications/Julia-0.3.3.app/Contents/Resources/julia/lib/
> julia/sys.dylib (repeats 2 times)
> while loading /Users/ndv21/Dropbox/Code/Irreversible binary string 
> chemistry/test.jl, in expression starting on line 17
>
> What can I do to make this work. E.g. how can I ensure that `convert` will 
> call my type's constructor appropriately? (The `convert` documentation 
> doesn't say.) Or is there a better way to do this?
>
>
> Nathaniel
>
>

[julia-users] Later methods definition replaces the previous one?

[Ivar Nesje]

New method definitions will replace the previous definition.

If you put the function in a module and bring them into you scope with 
using/importall, you'll run into 
https://github.com/JuliaLang/julia/issues/4345, which can be considered either 
a bug or a missing feature. 

[julia-users] Re: Naming of functions advice

[Ivar Nesje]

> Also, it's faster as multiple dispatch allows to call the function directly, 
> instead of determining which code to execute via if/else.

It is only faster to use a type (and dispatch), if the type can be inferred at 
compile time.

Re: [julia-users] Julia cannot compute factorial(21) while Octave can

[Ivar Nesje]

Octave uses Float64 numbers by default, so factorial(20) in octave is 
equivalent to factorial(20.0) in Julia.

[julia-users] Re: how to input array or convert string to array?

[Ivar Nesje]

Note that there might be a security issue, because whoever inputs data to your 
program also get the ability to run arbitrary code on the computer. In a local 
setting where everyone who input data, also have access to changing the code, 
this isn't an issue, but be careful if you plan to take input from strangers 
(eg on a Web server).

Re: [julia-users] Re: Where is documentation on { } notation for creating an Array(Any,1) ??

[Ivar Nesje]

See 
https://github.com/JuliaLang/julia/commit/be0f0dafa798c26279f4ece2f70afa9fc078772c

Re: [julia-users] How to define help text for a module function so that it displays in REPL

[Ivar Nesje]

Compat.jl doesn't have doc, but there is a package that is reported to do this 
for 0.3. I think it was Doctile.jl, but I might remember wrong.

Re: [julia-users] Re: Where is documentation on { } notation for creating an Array(Any,1) ??

[Ivar Nesje]

Yes, but he is looking at the 0.4 documentation,  so naturally he won't find it 
there. Try the 0.3 documentation. 

[julia-users] Weird type behaviour when creating an array of arrays from list comprehensions

[Ivar Nesje]

Unfortunately yes, this is (currently) expected.

The problem is that B is a global variable and currently we can't analyze the 
code in the comprehension to ensure that it doesn't change the type of B.

Various suggestions has come up about how to fix this, but currently your 
options is to make B a local variable (put everything in a function) or declare 
B as const.  

[julia-users] Re: How do you change the default location for package installation in Windows?

[Ivar Nesje]

>I wander why 0.2 (meaning not 0.3.4)?

Probably because this is a really old thread. 

Re: [julia-users] How can I achieve C-like ## in Julia

[Ivar Nesje]

The problem is where we should stop adding methods to allow symbols to work as 
strings.

* might be fine though, so please submit your code as a pull request, so we can 
get more opinions on the matter. (Be sure to link to this discussion and to 
post a link to the PR here)

Re: [julia-users] How can I achieve C-like ## in Julia

[Ivar Nesje]

The implementation will naturally also use string intermediaries, so you won't 
get much better performance.

Re: [julia-users] How can I achieve C-like ## in Julia

[Ivar Nesje]

I like $(symbol("gen_$x")) better than $(:gen_ * x), and others might agree. 
There is also an issue about implementing too much of the string API for 
symbols, because they have different performance characteristics.

[julia-users] Unexpected performance drop when passing functions

[Ivar Nesje]

Yes, this is the current situation. Don't call functions in this way in a hot 
inner loop where you care about performance (yet). There are lots of things 
that can be done to improve this situation, but it hasn't reached the top of 
anyone's todo list yet.

The best current workaround is to use a functor (search the code to see how we 
define and use the term to implement reduce and friends)

Re: [julia-users] How can I achieve C-like ## in Julia

[Ivar Nesje]

>
> May I ask why $ is needed before symbol()?
>

The same reason why you need $ in front of x. The function expression needs 
a symbol as its name, and you want to dynamically generate that symbol at 
macro evaluation time, in order to have access to the x variable.

Re: [julia-users] Re: Nullable use cases / expected behavior?

[Ivar Nesje]

>
> Forgot to say Base.== returns bool, so this now makes == type unstable.


Type stable (in the context of Julia) means that the return type can be 
statically inferred from the argument types. This means that + is type 
stable, even though it returns a Float64 if the arguments are Float64 and 
Int if the arguments are Int.

+(a::Int, b::Int) would be type unstable if typemax(Int) + 1 would be a 
BigInt, because then you'd have to look at the value of a and b to figure 
out what the type of the returned value would be.

This is an easy mistake to make, but the distinction is important.

[julia-users] Re: Why does string('a') work but convert(ASCIIString,'a') does not?

[Ivar Nesje]

I can't see any argument for why it would be wrong to add the requested 
method. Please open an issue (or better yet a Pull request) on github, so 
that we can have more opinions on the matter.

The implementation could be as simple as

*convert{T<:AbstractString}(::Type{T}, c::Char) = convert(T, string(c))*
but we probably want a more efficient approach that doesn't allocate a 
IOBuffer to create a single character string. (in testing this I also 
discovered that we are missing convert(::Type{SubString}, a::ASCIIString), 
and that might also be quite trivial to implement and somewhat useful)

We are in the process of changing a few fundamentals about how strings 
works internally, so it is really important that we include tests for the 
new behaviour so that it isn't forgotten in the rewrite.

Ivar


kl. 02:25:53 UTC+1 onsdag 7. januar 2015 skrev ele...@gmail.com følgende:
>
>
>
> On Wednesday, January 7, 2015 10:51:54 AM UTC+10, Ronald L. Rivest wrote:
>>
>> Using Julia 0.3.4.  The following seems somehow inconsistent.  Is there
>> something about the philosophy of `convert` I am missing??
>>
>> *julia> convert(ASCIIString,'a')*
>>
>> *ERROR: `convert` has no method matching convert(::Type{ASCIIString}, 
>> ::Char)*
>>
> Char is a Unicode codepoint so it cannot be guaranteed to be convertable 
> to ASCIIString.  But you could argue that conversion to UTF8String (or 
> other unicodes) should work, but at least in 0.3.4 it doesn't.
>
> Cheers
> Lex
>  
>
>> * in convert at base.jl:13*
>>
>> *julia> string('a')*
>>
>> *"a"*
>>
>> *julia> typeof(ans)*
>>
>> *ASCIIString (constructor with 2 methods)*
>>
>> Cheers,
>>
>> Ron
>>
>

Re: [julia-users] [ANN] Blink.jl – Web-based GUIs for Julia

[Ivar Nesje]

Have you seen https://github.com/JuliaLang/julia/pull/8987?

[julia-users] Constructing Expr from s-expressions

[Ivar Nesje]

Not directly related to your question, but dump takes a optional parameter to 
change the output limitation. 

Eg:
dump(ex, 100)
prints a deeper version of the AST than
dump(ex)

[julia-users] Re: What does (1,2,(3,4)...) mean?

[Ivar Nesje]

See https://github.com/JuliaLang/julia/issues/4869

kl. 19:19:26 UTC+1 lørdag 3. januar 2015 skrev René Donner følgende:
>
> Hi, 
>
> I wanted to append the tuple (3,4) to the tuple (1,2), expecting (1,2,3,4) 
> as output: 
>
>   julia> a = (1,2,(3,4)...) 
>   (1,2,(3,4)...) 
>
> It turns out I have to use tuple(1,2,(3,4)...) == (1,2,3,4). 
>
> I understand (1,2,3,4) and (1,2,(3,4)), but what does the output 
> "(1,2,(3,4)...)", which has type (Int64,Int64,DataType), actually mean and 
> what is it used for? 
>
> Thanks! 
>
> Rene 
>
>
>
>

Re: [julia-users] Re: bug in jacobisymbol Combinatorics.jl

[Ivar Nesje]

The issue tracker is off for Github forks. If the package has moved and is 
maintained at @jiahao's fork, he should break the fork relation.

kl. 19:11:19 UTC+1 lørdag 3. januar 2015 skrev Jiahao Chen følgende:
>
> Thanks for the report and the fix.
>
> I've updated the code and strengthened the test; the only change was to 
> use Cint instead of Int32 for consistency with our C calling code:
>
>
> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#type-correspondences
>
> I've also enabled the issue tracker; didn't realize it was off.
>
> On Sat Jan 03 2015 at 12:52:41 PM > 
> wrote:
>
>> Changing the line that calls libgmp like this ( Int is replaced with 
>> Int32 )
>>
>>  return convert(Int,ccall((:__gmpz_jacobi, :libgmp), Int32,
>>
>> gives correct results. The C header and code says the return type is 
>> 'int'.
>> All values that should be -1, come out 4294967295.  This may be system
>> dependent, but I only have one laptop available at the moment.
>>
>>
>>
>> On Saturday, January 3, 2015 6:44:40 PM UTC+1, lapeyre@gmail.com 
>> wrote:
>>>
>>> This is not correct
>>>
>>> julia> jacobisymbol(10,7)
>>> 4294967295
>>>
>>> This happens in v0.3 and v0.4
>>> I can send more information, and have a possible fix. I tried to find a 
>>> way to make a comment or issue or something at
>>> https://github.com/jiahao/Combinatorics.jl,
>>> but was unable to find a button for it.  Better to talk before issuing a 
>>> PR.
>>>
>>> --John
>>>
>>>

[julia-users] Re: How to heapify and array?

[Ivar Nesje]

 

*Collections.heapify!(x)*

kl. 11:22:24 UTC+1 lørdag 3. januar 2015 skrev Rodolfo Santana følgende:
>
> Let's say I have an array x=rand(10) . How do I use the heapify! function 
> to heapify x?
>
> Thanks!
> -Rodolfo
>
>
>

Re: [julia-users] Is this behaviour caused by a hygiene issue? If not. What causes it?

[Ivar Nesje]

> Usually, they get merged within days, and often backported to the 0.3 version 
> of the manual as well.

It's an oversight if documentation improvements doesn't get backported (if it 
is not documenting new features in 0.4-dev). Please bump the relevant pull 
requests so that we can fix that.

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

[Ivar Nesje]

Yes, Git allows for many different models for development. As Julia is a 
pretty small project (compared to the linux kernel), we have a much simpler 
structure. Julia is also in a early phase so we are exploring different 
options, and we need a branch to distribute and try out new ideas. We 
also occasionally do backwards incompatible changes, so it is really great 
that we have now left the single rolling release model that we had before 
0.3.0, but keep a stable branch with 0.3 without BC breaking changes.

Currently we are maintaining two main branches (master and release-0.3). I 
can definitely see the point that it would be great to have an additional 
develop branch, in order to have more widespread testing of changes before 
committing to master. Unfortunately that will require tons of extra effort 
and confusion and heighten the barrier for contribution. Considering the 
current size of the community, I don't think it will be much of a blessing.

We test all significant changes in a branch backed PR and run automated 
regression tests on multiple platforms. Some issues will naturally not be 
caught in such a process, and some will only occasionally be trigger a test 
failure when a race condition occurs. Some issues still will only fail the 
build on a VM with a specific processor (or amount of memory), so it will 
be hard to figure out.

Ivar

kl. 17:18:09 UTC+1 torsdag 1. januar 2015 skrev Ismael VC følgende:
>
> Ok, so the branching models in "git book" are just examples not 
> instructions.
>
>
> Thanks Sean!
>
> On Thu, Jan 1, 2015 at 9:36 AM, Sean Marshallsay  > wrote:
>
>> Ismael,
>>
>> I think you're over-compliacating Julia's workflow slightly, in that 
>> first image you posted (
>> http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows 
>> )
>>  
>> just replace the word "master" with "stable/release" and the word "develop" 
>> with "master" and that's pretty much it.
>>
>> On Thursday, 1 January 2015 09:14:29 UTC, Ismael VC wrote:
>>>
>>> Tobias: I don't think that Julia is more frequently broken, but Dann 
>>> experienced this (his blog post started this discussion), I have also 
>>> experienced it several times (but I'm an inexpert noob) and of course I'm 
>>> sure other have also experienced this.
>>>
>>> I just wanted to know the advantages of Julia's approach compared to 
>>> following things by the "book".
>>>
>>> I know the correct thing it to check if there is an open issue or else 
>>> open an issue (I've spent last year studying git and a lot of stuff), and 
>>> all I know comes from whatever I have available to study from, like the git 
>>> book, and since I clearly don't understand, I just want to understand the 
>>> issue.
>>>
>>> Keno: I certainly want to provide feedback and learn, you'll be having 
>>> me around a lot starting from this year. :D
>>>
>>> Obviously I didn't follow the 0.3 dev cycle, but now I have configured 
>>> gmail, to recieve absolutely every notification from the Julia project.
>>>
>>> As a mater of fact I'll start building Julia from master again tonight 
>>> and report any issues I might encounter, something I stopped doing because 
>>> of my lack of knowledge and the availability of binaries.
>>>
>>> Thanks you both for taking the time to answer my concerns.
>>>
>>> On Thu, Jan 1, 2015 at 2:45 AM, Tobias Knopp  
>>> wrote:
>>>
 Hi Ismael,

 why do you think that master is more frequently broken in Julia than in 
 other projects?
 This really does not happen often. People develop in branches and after 
 serious review they are merged to master.

 This discussion further is to isolated and does not take into account 
 that Julia is a programming language and that it is very important to 
 testbed language changes during a development period.

 The discussion is, by the way, very funny because we had during the 0.3 
 dev period effectively a "rolling release", i.e. development snapshots 
 were 
 regularly made and these were kept stable.

 Cheers,

 Tobi



 Am Donnerstag, 1. Januar 2015 09:12:59 UTC+1 schrieb Ismael VC:
>
> Perhaps we could add a diagram of the Julia work flow because I think 
> we are using neither one of those models, we don't have lieutenants, nor 
> a 
> dictator do we?
>  
>
> ​I'm sorry for the ugly diagram, I just want to really understand the 
> current work flow, so correct me if I'm wrong.
>
> I don't know about Linux, but I wonder how frequently do they happen 
> to have a broken master? I this also common situation among distributed 
> open source projects? (I'm going to study Rust's approach too.) 
>
> I just thought that the master had to be as stable as possible 
> (reference) and by using the dicta

[julia-users] Re: in-place copying mutable vs immutable

[Ivar Nesje]

If you also want to look at the implementation of a function, the @less and 
@edit macros is very time saving alternatives to @which.

kl. 15:34:56 UTC+1 tirsdag 30. desember 2014 skrev Steven G. Johnson 
følgende:
>
> Note that the PriorityQueue type in Base may do what you want. 

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Ivar Nesje]

If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 and 
fix it in a new 0.3.5 point release.

Ivar

kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
>
> I think this have to be fixed in Compat, so that's probably the right 
> place to open an issue (or preferably a PR).
>
> You also don't need @compat, because (currently) Compat just generically 
> defines 
> the new functions 
> <https://github.com/JuliaLang/Compat.jl/blob/73c4a03c82928bed5656103ccfede9a5c878656d/src/Compat.jl#L40-48>
>  
> on Julia 0.3.
>
> Ivar
>
> kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:
>>
>> I don't know if this is a problem with core Julia, with Compat.jl or with 
>> my own code, but I can't figure out how to get this working.
>>
>> On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
>> can't figure out how to do this with the 0.4 method names and Compat: 
>>
>> julia> using Compat
>>
>> julia> @compat round(Int, 1//2)
>> ERROR: `iround` has no method matching iround(::Type{Int64}, 
>> ::Rational{Int64})
>>  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45
>>
>> Am I doing something wrong here, or should I file an issue? If I should, 
>> is the problem with Compat.jl or with core Julia?
>>
>> Thanks,
>>
>> // T
>>
>

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Ivar Nesje]

I think this have to be fixed in Compat, so that's probably the right place 
to open an issue (or preferably a PR).

You also don't need @compat, because (currently) Compat just generically 
defines 
the new functions 

 
on Julia 0.3.

Ivar

kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:
>
> I don't know if this is a problem with core Julia, with Compat.jl or with 
> my own code, but I can't figure out how to get this working.
>
> On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
> can't figure out how to do this with the 0.4 method names and Compat: 
>
> julia> using Compat
>
> julia> @compat round(Int, 1//2)
> ERROR: `iround` has no method matching iround(::Type{Int64}, 
> ::Rational{Int64})
>  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45
>
> Am I doing something wrong here, or should I file an issue? If I should, 
> is the problem with Compat.jl or with core Julia?
>
> Thanks,
>
> // T
>

[julia-users] Re: Revision release notes

[Ivar Nesje]

No, the release-0.3 branch (that we tag 0.3.x releases from) only receives 
bug fixes that (hopefully) doesn't break backward compatibility. Everything 
is captured in the "Numerous bugfixes" bullet.

You can look at the list of commits 
 if you 
need more specific what was actually fixed.

Ivar

kl. 07:14:59 UTC+1 fredag 26. desember 2014 skrev Eric Davies følgende:
>
> Are there release notes for 0.3.1+? Looking at NEWS.md, it seems that only 
> 0.3.0 appears. 
>

[julia-users] Re: Julia documentation is ready for translation/internationalization on Transifex!

[Ivar Nesje]

This is great!

transifex looks good, and I wish you the best of luck. I'm no use in 
Spanish or German, but if I see a great (updated) manual in a few languages 
in 6 month time, I might look into translating to Norwegian.

I just want to give a word of warning that the Julia documentation isn't 
static, so you will need some simple (and partially automated) way of 
keeping everything up to date.

Ivar

kl. 22:39:47 UTC+1 torsdag 25. desember 2014 skrev Ismael VC følgende:
>
>
> 
> Here is a screenshot of the transifex editor in action, I wonder if it 
> works from a smartphone!
>
>
>

[julia-users] Re: make errors and git version issues

[Ivar Nesje]

I'm really at loss for what to try here. I'm upgrading to git 2.0, but the 
release notes doesn't seem to have changes that would break anything.

kl. 08:22:01 UTC+1 tirsdag 23. desember 2014 skrev Svaksha følgende:
>
> On Tue, Dec 23, 2014 at 7:09 AM, SVAKSHA > 
> wrote: 
> > On Mon, Dec 22, 2014 at 8:34 PM, Ivar Nesje  > wrote: 
> >> 3 days old version: This looks really weird, and I can't really see how 
> this 
> >> can happen. The first I would check is that you are actually running 
> the 
> >> julia you just built, rather than a a 3 days old julia from another 
> > 
> > Well, the make errors came after a fresh compile from the 
> > 20a5c3d888dd9317065390b8bbd984 
> > 17addeb65c commit. 
> > 
> > Fwiw, I had deleted the old julia repo and .julia directory, cloned 
> > julia afresh and compiled it again because the earlier commit was 
> > showing a 3-day old master.  Despite running make after doing a fresh 
> > pull**[0] today morning it still says "Version 0.4.0-dev+2200 
> > (2014-12-18 17:30 UTC) Commit 79d473c (4 days old master)". Really 
> > odd. 
> > 
> > 
> >> directory. The next point on the list is to post git status and the 
> last 
> >> line of sh base/version_git.sh so that we can see if it gives us a 
> clue. 
> > 
> > After a git pull since last night, 
> > ~/julia$ git status 
> > On branch master 
> > Your branch is ahead of 'origin/master' by 17 commits. **[0] 
> >   (use "git push" to publish your local commits) 
> > nothing to commit, working directory clean 
> > 
> > **[0] NB: this is odd, when tig shows this: 
> > https://gist.github.com/svaksha/76716563322d9065e672 
>
> Fwiw, I use the git version 2.2.1 and I'm wondering if the problem is 
> because I updated git after the security bug issue and dont use the OS 
> packaged version of git? It should'nt be related but I cannot put a 
> finger on the weird git behaviour. Just thinking out loud. 
>
> SVAKSHA ॥  http://about.me/svaksha  ॥ 
>

[julia-users] Re: make errors and git version issues

[Ivar Nesje]

This is two separate issues, so I'll try to answer them separately.

3 days old version: This looks really weird, and I can't really see how 
this can happen. The first I would check is that you are actually running 
the julia you just built, rather than a a 3 days old julia from another 
directory. The next point on the list is to post git status and the last 
line of sh base/version_git.sh so that we can see if it gives us a clue.

The checksum issue is because the one of our dependencies needs to be 
downloaded separately, and you didn't get a file exactly equal to the file 
we got when we added the dependency. This is usually caused by networking 
issues, but can have many other sources. Typically the best way to find out 
is to examine the size of deps/pcre-8.36.tar.bz2 to see if it is about 1.5 
MB.

kl. 17:34:32 UTC+1 mandag 22. desember 2014 skrev Svaksha følgende:
>
> Hi, I noticed git version issues with the commit 
> bf5a4041b6f9edc5a09a20c7442b63147e907e49, 
> 2014-12-22 14:17 ivarne o │ [origin/HEAD] [origin/master] 
> Fixed function links in doc/manual/strings.rst 
>
> Trying to update and testall/ distclean would still result in an old 
> Commit 79d473c (3 days old master) 
>
> Next, I did a fresh clone of the repo and compiled the commit 
> 20a5c3d888dd9317065390b8bbd98417addeb65c, 
> 2014-12-22 10:46 Stefan Karpinski   M─┐ [master] Merge pull request 
> #9391 from garborg/copyempty 
>
> which throws this error : 
>
> ~/julia$ make 
> ===
>  
>
>   ERROR: sha512 checksum failure on pcre-8.36.tar.bz2, should be: 
>   acd2bc6911be7b518ad4aca3c3ccbe98bdbeabf0e77d6b04009838c7825b563a 
>   001377f8c3a6a8a0583ec32ee9fefe05e3c1a69f272fe5084469a6b6c2148fbf 
>   But `sha512sum pcre-8.36.tar.bz2 | awk '{ print $1; }'` results in: 
>   2dd8240aca5feeb0f64b5a35cff5974e153e6ddeed72e78507303d479bfbdb51 
>   182236eb3fb02d538abd6e0afe29bc19fddf6957e5c60adcd35fa8049bd80c36 
>   This can happen due to bad downloads or network proxies, please check 
> your 
>   network proxy/firewall settings and delete deps/pcre-8.36.tar.bz2 
>   to force a redownload when you are ready 
> ===
>  
>
> make[2]: *** [pcre-8.36/configure] Error 2 
> make[1]: *** [julia-release] Error 2 
> make: *** [release] Error 2 
>
>
>
> $ julia 
>_ 
>_   _ _(_)_ |  A fresh approach to technical computing 
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org 
>_ _   _| |_  __ _   |  Type "help()" for help. 
>   | | | | | | |/ _` |  | 
>   | | |_| | | | (_| |  |  Version 0.4.0-dev+2200 (2014-12-18 17:30 UTC) 
>  _/ |\__'_|_|_|\__'_|  |  Commit 79d473c (3 days old master) 
> |__/   |  i686-linux-gnu 
>
> julia> versioninfo() 
> Julia Version 0.4.0-dev+2200 
> Commit 79d473c (2014-12-18 17:30 UTC) 
> Platform Info: 
>   System: Linux (i686-linux-gnu) 
>   CPU: Intel(R) Pentium(R) CPU B950 @ 2.10GHz 
>   WORD_SIZE: 32 
>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY 
> Nehalem) 
>   LAPACK: liblapack.so.3 
>   LIBM: libopenlibm 
>   LLVM: libLLVM-3.3 
>
> Is this is a bug or a git / network issue? 
> TIA, SVAKSHA ॥  http://about.me/svaksha  ॥ 
>

[julia-users] Re: Can't Define New Functors Using Numeric Extensions 0.6.2 in Julia 0.3.3

[Ivar Nesje]

Yes, everything is fine now. I noticed only 5 people were following 
NumericExtensions.jl, so it's probably better to ask here.

The error seems really strange. Do you load some code from a file, or do you 
paste everything directly in the REPL? Have you defined the type multiple times 
in the same session?

[julia-users] Can't Define New Functors Using Numeric Extensions 0.6.2 in Julia 0.3.3

[Ivar Nesje]

Please don't double post your questions without linking between them. It's 
really annoying to answer a question, just to find out that it was answered 1 
hour ago another place.

 https://github.com/lindahua/NumericExtensions.jl/issues/49

[julia-users] Re: home page content

[Ivar Nesje]

kl. 13:01:36 UTC+1 fredag 19. desember 2014 skrev Bas Dirks følgende:
>
> Where do I send my technical (front-end) suggestions?
>

For simple changes a Pull Request at 
https://github.com/JuliaLang/julialang.github.com would be great. For more 
drastic changes it's probably a good idea to open an issue for discussion 
first.