[julia-users] Re: difference in Travis tests?

[Seth]

Thanks, Tony - I think this makes sense now. Appreciate the explanation.

On Thursday, February 19, 2015 at 7:04:07 PM UTC-8, Tony Kelman wrote:
>
> Misspoke slightly here - Travis doesn't build on every commit, rather it 
> builds on every push. So if you push multiple commits at the same time 
> you'll only get one build.
>
> Travis has always been doing this 2-builds business for PR's, but they 
> used to be sending notifications to the same status name 
> "continuous-integration/travis-ci," and github would only show the most 
> recent message that was sent to the same status endpoint. Now the branch 
> build sends to "continuous-integration/travis-ci/push," the PR merge build 
> sends to "continuous-integration/travis-ci/pr," and we see both statuses on 
> PR's that come from branches within the JuliaLang/julia repo. For PR's that 
> come from personal forks such as 
> https://github.com/JuliaLang/julia/pull/10250 (which was just merged, 
> click the red X next to the commit message) we only get the 
> "continuous-integration/travis-ci/pr" status.
>
>
> On Thursday, February 19, 2015 at 6:47:41 PM UTC-8, Tony Kelman wrote:
>>
>> As far as I can tell this is just a change in how Travis sends 
>> notifications to the GitHub status API. For contributors who have commit 
>> access to the main Julia repository and work on a pull request from a 
>> branch there, Travis builds every commit in every branch (unless the commit 
>> message contains "[ci skip]"). Then when a pull request is opened, Travis 
>> does a separate build of the merge commit that would result from merging 
>> the PR branch into the state of master at the time the build begins.
>>
>> If there's a difference in results, I suspect it's mostly down to the 
>> fact that Julia's CI tests still have a large number of intermittent 
>> failure modes that we haven't gotten to the bottom of yet. In some cases 
>> the failures might be caused by the actual difference in the code that gets 
>> built, the branch build runs on the state of the branch which may not 
>> contain newer changes that have been committed to master.
>>
>>
>> On Thursday, February 19, 2015 at 12:19:35 PM UTC-8, Seth wrote:
>>>
>>> I noticed recently that two travis tests (each against 0.3 and nightly, 
>>> so a total of 4 builds?) are occurring for each PR. In many cases one fails 
>>> while the other succeeds.
>>>
>>> What's the difference between the two (sets of) tests, and when/why did 
>>> this change happen?
>>>
>>> Thanks!
>>>
>>

Re: [julia-users] Julia on Raspberry Pi 2

[Seth]

Weird then. That should be working. The only thing I can think of is that 
you have to start over completely fresh to make sure configure sees it from 
the beginning?

In any case, I'm looking forward to your progress and hope you can find a 
solution to https://github.com/JuliaLang/julia/issues/10235 :)

S.

On Thursday, February 19, 2015 at 5:25:43 PM UTC-8, Sto Forest wrote:
>
> Thanks Seth, yes the chain seems good:
>
> root@pithree:/opt/julia# ls -al /usr/lib/libgfortran.so.3 
> lrwxrwxrwx 1 root root 45 Feb 19 17:21 /usr/lib/libgfortran.so.3 -> 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> root@pithree:/opt/julia# ls -al 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> lrwxrwxrwx 1 root root 20 Sep  6 12:52 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 -> libgfortran.so.3.0.0
> root@pithree:/opt/julia# ls -al 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> -rw-r--r-- 1 root root 655444 Sep  6 13:28 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> root@pithree:/opt/julia# 
>
> On Thursday, 19 February 2015 17:28:11 UTC, Seth wrote:
>>
>> Make sure that the symlink chain is unbroken. In mine:
>>
>> seth@redshift ~/dev/julia/julia $ ls -l /usr/lib/libgfortran.so.3
>> lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>>
>> seth@redshift ~/dev/julia/julia $ ls -l 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>> lrwxrwxrwx 1 root root 20 Sep  6 05:52 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 -> libgfortran.so.3.0.0
>>
>> seth@redshift ~/dev/julia/julia $ ls -l 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>> -rw-r--r-- 1 root root 655444 Sep  6 06:28 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>>
>> On Thursday, February 19, 2015 at 9:24:14 AM UTC-8, Sto Forest wrote:
>>>
>>> Thanks for the hint Seth, I've added the symlink but still get the error 
>>> ..
>>>
>>> /usr/bin/ld: cannot find -lgfortran
>>>
>>>
>>>
>>>
>>> On Thursday, 19 February 2015 17:13:41 UTC, Seth wrote:

 Also, the fact that you don't have /usr/lib/libgfortran.so.3 is 
 probably causing the issue. Try creating a symlink:

 lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
 /usr/lib/arm-linux-gnueabihf/libgfortran.so.3



 On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote:
>
> Different than what I have:
>
> /usr/share/doc/libgfortran3
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> /usr/lib/libgfortran.so.3
> /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
> /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
> /var/lib/dpkg/info/libgfortran3:armhf.postrm
> /var/lib/dpkg/info/libgfortran3:armhf.postinst
> /var/lib/dpkg/info/libgfortran3:armhf.symbols
> /var/lib/dpkg/info/libgfortran3:armhf.list
>
> This is on raspbian:
>
> Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 
> 2015 armv7l GNU/Linux
> seth@redshift ~/dev/julia/julia $ cat /etc/issue
> Raspbian GNU/Linux 7 \n \l
>
>
>
> On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:
>>
>> libgfortran-4.8 does seem to be  installed ( I don't think there is a 
>> version 4.7 in the package list )
>>
>>
>> Here is the result of a find for libgforrtan ...
>>
>> root@pithree:/opt/julia# find / -name "*libgfortran*"
>> /usr/share/doc/libgfortran3
>> /usr/share/doc/libgfortran-4.8-dev
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>> /opt/julia/contrib/fixup-libgfortran.sh
>> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
>> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
>> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
>> /var/lib/dpkg/info/libgf

[julia-users] Re: difference in Travis tests?

[Tony Kelman]

Misspoke slightly here - Travis doesn't build on every commit, rather it 
builds on every push. So if you push multiple commits at the same time 
you'll only get one build.

Travis has always been doing this 2-builds business for PR's, but they used 
to be sending notifications to the same status name 
"continuous-integration/travis-ci," and github would only show the most 
recent message that was sent to the same status endpoint. Now the branch 
build sends to "continuous-integration/travis-ci/push," the PR merge build 
sends to "continuous-integration/travis-ci/pr," and we see both statuses on 
PR's that come from branches within the JuliaLang/julia repo. For PR's that 
come from personal forks such 
as https://github.com/JuliaLang/julia/pull/10250 (which was just merged, 
click the red X next to the commit message) we only get the 
"continuous-integration/travis-ci/pr" status.


On Thursday, February 19, 2015 at 6:47:41 PM UTC-8, Tony Kelman wrote:
>
> As far as I can tell this is just a change in how Travis sends 
> notifications to the GitHub status API. For contributors who have commit 
> access to the main Julia repository and work on a pull request from a 
> branch there, Travis builds every commit in every branch (unless the commit 
> message contains "[ci skip]"). Then when a pull request is opened, Travis 
> does a separate build of the merge commit that would result from merging 
> the PR branch into the state of master at the time the build begins.
>
> If there's a difference in results, I suspect it's mostly down to the fact 
> that Julia's CI tests still have a large number of intermittent failure 
> modes that we haven't gotten to the bottom of yet. In some cases the 
> failures might be caused by the actual difference in the code that gets 
> built, the branch build runs on the state of the branch which may not 
> contain newer changes that have been committed to master.
>
>
> On Thursday, February 19, 2015 at 12:19:35 PM UTC-8, Seth wrote:
>>
>> I noticed recently that two travis tests (each against 0.3 and nightly, 
>> so a total of 4 builds?) are occurring for each PR. In many cases one fails 
>> while the other succeeds.
>>
>> What's the difference between the two (sets of) tests, and when/why did 
>> this change happen?
>>
>> Thanks!
>>
>

[julia-users] Re: difference in Travis tests?

[Tony Kelman]

As far as I can tell this is just a change in how Travis sends 
notifications to the GitHub status API. For contributors who have commit 
access to the main Julia repository and work on a pull request from a 
branch there, Travis builds every commit in every branch (unless the commit 
message contains "[ci skip]"). Then when a pull request is opened, Travis 
does a separate build of the merge commit that would result from merging 
the PR branch into the state of master at the time the build begins.

If there's a difference in results, I suspect it's mostly down to the fact 
that Julia's CI tests still have a large number of intermittent failure 
modes that we haven't gotten to the bottom of yet. In some cases the 
failures might be caused by the actual difference in the code that gets 
built, the branch build runs on the state of the branch which may not 
contain newer changes that have been committed to master.


On Thursday, February 19, 2015 at 12:19:35 PM UTC-8, Seth wrote:
>
> I noticed recently that two travis tests (each against 0.3 and nightly, so 
> a total of 4 builds?) are occurring for each PR. In many cases one fails 
> while the other succeeds.
>
> What's the difference between the two (sets of) tests, and when/why did 
> this change happen?
>
> Thanks!
>

Re: [julia-users] Functions

[Devendra Ghate]

Both the solutions (using immutable type and the earlier solution
suggested by Tamas).

I will check the performance and report back in a week or so.

Thank you,
Devendra

On Thu, Feb 19, 2015 at 09:45:39AM -0500, Isaiah Norton wrote:


Maybe you could use value types (
http://julia.readthedocs.org/en/latest/manual/types/#value-types ),
however, you need to use the latest nighly builds for that. Eg



Something very similar to the first example actually works in 0.3:

immutable Problem{S} end

f(::Type{Problem{1}}, x) = x^2
f(::Type{Problem{2}}, x) = sin(x)



f(Problem{1}, 1)


1


f(Problem{2}, 1)


0.8414709848078965


On Thu, Feb 19, 2015 at 4:24 AM, Tamas Papp  wrote:


Hi,

Maybe you could use value types (
http://julia.readthedocs.org/en/latest/manual/types/#value-types ),
however, you need to use the latest nighly builds for that. Eg

func(::Type{Val{1}}, x) = x^2
func(::Type{Val{2}}, x) = sin(x)

func(Val{1},1)  # => 1
func(Val{2},1)  # => sin(1)

If you want to stick with 3.6 for now, you could create types for the
cases.

type Case1 end
func(::Type{Case1}, x) = x^2
type Case2 end
func(::Type{Case2}, x) = sin(x)

func(Case1, 1)  # => 1
func(Case2, 1)  # => sin(1)

Best,

Tamas

On Thu, Feb 19 2015, Devendra Ghate  wrote:

> Hello everyone,
>
> Consider following function:
>
> ~~~
> function funca(problem, x)
>if problem == 1
>   return  x^2;
>elseif
>problem == 2
> return sin(x);
> end
> end
> ~~~
>
> I have shown only 2 cases. However, there are around 100 cases. These
> `if ... else` statements are being evaluated unnecessarily. If I use
> `switch` structure then it will be faster. But I want to do away with
> these.
>
> Since the arguments and their datatypes remain the same, I don't know
> how to create multiple methods for function.
>
> What is the best strategy to achieve this?
>
> Background:
>
> I am trying to implement a library of ODE solvers for my students.
>
> $y`` + a(x)y` + b(x) = f(x) $
>
> Above function calculates $a(x)$ for a given problem at a specific $x_0$.
>
> So there should various ODE problems defined via the coefficients of
> the derivative terms. My students will then implement various solution
> strategies and compare their performance for these problems. So I need
> to provide
> them with functions `funca` `funcb` `funcf` which give the appropriate
> coefficient depending on the problem.




--
Devendra Ghate

Re: [julia-users] Julia on Raspberry Pi 2

[Sto Forest]

Thanks Seth, yes the chain seems good:

root@pithree:/opt/julia# ls -al /usr/lib/libgfortran.so.3 
lrwxrwxrwx 1 root root 45 Feb 19 17:21 /usr/lib/libgfortran.so.3 -> 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3
root@pithree:/opt/julia# ls -al 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3
lrwxrwxrwx 1 root root 20 Sep  6 12:52 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3 -> libgfortran.so.3.0.0
root@pithree:/opt/julia# ls -al 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
-rw-r--r-- 1 root root 655444 Sep  6 13:28 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
root@pithree:/opt/julia# 

On Thursday, 19 February 2015 17:28:11 UTC, Seth wrote:
>
> Make sure that the symlink chain is unbroken. In mine:
>
> seth@redshift ~/dev/julia/julia $ ls -l /usr/lib/libgfortran.so.3
> lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>
> seth@redshift ~/dev/julia/julia $ ls -l 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> lrwxrwxrwx 1 root root 20 Sep  6 05:52 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 -> libgfortran.so.3.0.0
>
> seth@redshift ~/dev/julia/julia $ ls -l 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> -rw-r--r-- 1 root root 655444 Sep  6 06:28 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>
> On Thursday, February 19, 2015 at 9:24:14 AM UTC-8, Sto Forest wrote:
>>
>> Thanks for the hint Seth, I've added the symlink but still get the error 
>> ..
>>
>> /usr/bin/ld: cannot find -lgfortran
>>
>>
>>
>>
>> On Thursday, 19 February 2015 17:13:41 UTC, Seth wrote:
>>>
>>> Also, the fact that you don't have /usr/lib/libgfortran.so.3 is probably 
>>> causing the issue. Try creating a symlink:
>>>
>>> lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
>>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>>>
>>>
>>>
>>> On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote:

 Different than what I have:

 /usr/share/doc/libgfortran3
 /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
 /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
 /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
 /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
 /usr/lib/libgfortran.so.3
 /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
 /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
 /var/lib/dpkg/info/libgfortran3:armhf.md5sums
 /var/lib/dpkg/info/libgfortran3:armhf.shlibs
 /var/lib/dpkg/info/libgfortran3:armhf.postrm
 /var/lib/dpkg/info/libgfortran3:armhf.postinst
 /var/lib/dpkg/info/libgfortran3:armhf.symbols
 /var/lib/dpkg/info/libgfortran3:armhf.list

 This is on raspbian:

 Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 
 2015 armv7l GNU/Linux
 seth@redshift ~/dev/julia/julia $ cat /etc/issue
 Raspbian GNU/Linux 7 \n \l



 On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:
>
> libgfortran-4.8 does seem to be  installed ( I don't think there is a 
> version 4.7 in the package list )
>
>
> Here is the result of a find for libgforrtan ...
>
> root@pithree:/opt/julia# find / -name "*libgfortran*"
> /usr/share/doc/libgfortran3
> /usr/share/doc/libgfortran-4.8-dev
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> /opt/julia/contrib/fixup-libgfortran.sh
> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.postrm
> /var/lib/dpkg/info/libgfortran3:armhf.postinst
> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
> /var/lib/dpkg/info/libgfortran3:armhf.symbols
> /var/lib/dpkg/info/libgfortran3:armhf.list
> /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb
>
>
>
> On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:
>>
>> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or 
>> something similar. It is odd th

[julia-users] Re: [`call`/`convert` functions] I don't understand this `MethodError` (v0.4.0-dev+3353 / Win 64 bits).

[Ismael VC]

If Julia already makes an automatic default inner constructor, wouldn't it 
be a good idea to also make an automatic default outer constructor like 
this:

julia> abstract Foo

julia> type Bar{T<:Number} <: Foo
   x::T

   Bar(x::T) = new(x)
   end

julia> Bar{T<:Number}(x::T) = Bar{T}(x)
Bar{T<:Number} (constructor with 1 method)

julia> Bar(5), Bar(5.5), Bar(3//5), Bar(big(5.3))
(Bar{Int32}(5),Bar{Float64}(5.5),Bar{Rational{Int32}}(3//5),
99982236431605997495353221893310546875e+00 with 256

julia> Bar(5), Bar(5.5), Bar(3//5)
(Bar{Int32}(5),Bar{Float64}(5.5),Bar{Rational{Int32}}(3//5))

Or what's the advantage in doing it the way it is now?

El martes, 17 de febrero de 2015, 12:59:00 (UTC-6), Ismael VC escribió:
>
> Why can't I create an instance of this `Bar` type with the following 
> enforced invariants?
>
> julia> versioninfo()
> Julia Version 0.4.0-dev+3353
> Commit 0179028* (2015-02-14 17:08 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> abstract Foo
>
> julia> type Bar{T<:Number} <: Foo
>value::Nullable{Complex{T}}
>x::Int
>y::Int
>
>function Bar(x::Int, y::Int)
>x < 0 || y < 0 && error()
>x < y ? new(Nullable{Complex{T}}(), x, y) : error()
>end
>end
>
> julia> Bar{T<:Number}(value::T, x::Int, y::Int) = 
> Bar(Nullable(complex(value)), x, y)
> Bar{T<:Number}
>
> julia> methods(Bar)
> 2-element Array{Any,1}:
>  call{T<:Number}(::Type{Bar{T<:Number}},value::T<:Number,x::Int64,y::Int64) 
> at none:1
>  call{T}(::Type{T},args...) at base.jl:36
>
> julia> Bar(1, 8)
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{Bar{T<:Number}}, ::Int64, ::Int64)
> This may have arisen from a call to the constructor Bar{T<:Number}(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   convert{T}(::Type{T}, ::T)
>
>  in call at base.jl:36
>
> julia> Bar(5.7, 1, 8)
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{Bar{T<:Number}}, ::Nullable{Complex{Float64}}, ::Int64, 
> ::Int64)
> This may have arisen from a call to the constructor Bar{T<:Number}(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   convert{T}(::Type{T}, ::T)
>
>  in call at none:1
>
> How could I implement the this type's constructors? I don't understand the 
> new `call` constructors! :'(
>
>

Re: [julia-users] How to prevent SQL injection in Julia?

[Philip Tellis]

Opened issue #74

Re: [julia-users] can't add packages

[Jeff Kopmanis]

That did it, Seth!

git config --global url."https://github.com/".insteadOf git://github.com

Just ran the Julia Pkg.add("HDF5") and it worked splendidly!

Thanks for your help!

-Jeff. :)

On Thu, Feb 19, 2015 at 4:53 PM, Seth  wrote:

> Get it working on the command line first :)
>
> On Thursday, February 19, 2015 at 1:52:44 PM UTC-8, Jeff Kopmanis wrote:
>>
>> Thanks.  That article recommends using https: instead of git:   Could it
>> be a MIME-type error or misconfig?
>>
>> If I want to use the https URL, where do you change that?  Is there a
>> setup file somewhere?
>>
>> On Thu, Feb 19, 2015 at 4:49 PM, Seth  wrote:
>>
>>> That looks unrelated, but the linked issue (
>>> https://github.com/JuliaLang/julia/issues/8810) might help.
>>>
>>> On Thursday, February 19, 2015 at 1:46:30 PM UTC-8, Jeff Kopmanis wrote:

 Found something...  it might be a combination of the v0.3 Julia and >=
 10.8 OSX

 https://github.com/JuliaLang/julia/issues/6880

 On Thu, Feb 19, 2015 at 4:43 PM, Jeff Kopmanis 
 wrote:

> nope. Identically.
>
> I did sysadmin for nearly 17 years at the UMich math dept (macOSX,
> solaris, linux) and this one has me scratchin' my head.
>
> On Thu, Feb 19, 2015 at 4:42 PM, Seth  wrote:
>
>> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If
>> you try both the OSX version and the macports version (using absolute 
>> paths
>> to confirm), do they behave differently?
>>
>> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis
>> wrote:
>>>
>>> This is my ~/.gitconfig:
>>>
>>> [user]
>>> name = Jeff Kopmanis
>>> email = kopm...@umich.edu
>>> [core]
>>> excludesfile = /Users/kopmanis/.gitignore_global
>>> [difftool "sourcetree"]
>>> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
>>> path =
>>> [mergetool "sourcetree"]
>>> cmd = /Applications/SourceTree.app/C
>>> ontents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor
>>> \"$BASE\" -merge \"$MERGED\"
>>> trustExitCode = true
>>>
>>> Its on MacOSX 10.9.  I moved the file aside and it behaves
>>> identically.
>>>
>>> Running the git command with the -v  switch instead of -q gives the
>>> following:
>>>
>>> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
>>> METADATA
>>> Cloning into 'METADATA'...
>>> fatal: unable to connect to github.com:
>>> github.com[0: 192.30.252.131]: errno=Operation timed out
>>>
>>> This is exactly what the -q switch did.  There was about a 2 minute
>>> (90 second) wait after the "Cloning into 'METADATA'..." message.  Here's
>>> what telnet did:
>>>
>>> $ telnet github.com 9418
>>> Trying 192.30.252.130...
>>> Connected to github.com.
>>> Escape character is '^]'.
>>> ^]
>>> telnet> close
>>> Connection closed.
>>>
>>> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so
>>> funky. I use git daily and it doesn't give me any troubles with 
>>> CloudForge
>>> or Github (we have another project that uses Github).
>>>
>>> Which git is Julia using? If it hard codes a location it could be
>>> using the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple
>>> Git-48)).  MacPorts is the one I use in my path, which is at
>>> /opt/local/bin/git.
>>>
>>> I'm not sure why 2-factor auth would be an issue, since cloning is
>>> anonymous and pretty public??
>>>
>>> Thanks for your help...any ideas would be welcome.
>>>
>>> -Jeff.
>>>
>>> On Thu, Feb 19, 2015 at 4:19 PM, Seth 
>>> wrote:
>>>
 If it turns out to be a git issue then you have to fix the
 underlying git issue before trying to use git with Julia.

 Do you have a ~/.gitconfig? What's in it? If you run the git clone
 with -v instead of -q, what do you see?

 Just to be clear: this does not appear to be an issue with Julia;
 it's with (your installation of) git. Fix that and Julia should start
 working.



 On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis
 wrote:
>
> It's never asked me to authenticate...it just sits there until the
> connection times out.  I don't do 2-factor auth on my machine, and 
> not with
> github.
>
> If it turns out to be a git issue, how do I tell Julia to use the
> correct/additional options when doing Pkg.?? calls?
>
> On Thu, Feb 19, 2015 at 4:12 PM, Seth 
> wrote:
>
>> I recall running into this problem with OSX a while ago. Turns
>> out it was an interaction between user credentials in .gitconfig and
>> 2-factor auth. If that sounds similar to you

Re: [julia-users] can't add packages

[Seth]

Get it working on the command line first :)

On Thursday, February 19, 2015 at 1:52:44 PM UTC-8, Jeff Kopmanis wrote:
>
> Thanks.  That article recommends using https: instead of git:   Could it 
> be a MIME-type error or misconfig?
>
> If I want to use the https URL, where do you change that?  Is there a 
> setup file somewhere?
>
> On Thu, Feb 19, 2015 at 4:49 PM, Seth  > wrote:
>
>> That looks unrelated, but the linked issue (
>> https://github.com/JuliaLang/julia/issues/8810) might help.
>>
>> On Thursday, February 19, 2015 at 1:46:30 PM UTC-8, Jeff Kopmanis wrote:
>>>
>>> Found something...  it might be a combination of the v0.3 Julia and >= 
>>> 10.8 OSX
>>>
>>> https://github.com/JuliaLang/julia/issues/6880
>>>
>>> On Thu, Feb 19, 2015 at 4:43 PM, Jeff Kopmanis  
>>> wrote:
>>>
 nope. Identically.

 I did sysadmin for nearly 17 years at the UMich math dept (macOSX, 
 solaris, linux) and this one has me scratchin' my head.

 On Thu, Feb 19, 2015 at 4:42 PM, Seth  wrote:

> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If 
> you try both the OSX version and the macports version (using absolute 
> paths 
> to confirm), do they behave differently?
>
> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis 
> wrote:
>>
>> This is my ~/.gitconfig:
>>
>> [user]
>> name = Jeff Kopmanis
>> email = kopm...@umich.edu
>> [core]
>> excludesfile = /Users/kopmanis/.gitignore_global
>> [difftool "sourcetree"]
>> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
>> path = 
>> [mergetool "sourcetree"]
>> cmd = /Applications/SourceTree.app/C
>> ontents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor 
>> \"$BASE\" -merge \"$MERGED\"
>> trustExitCode = true
>>
>> Its on MacOSX 10.9.  I moved the file aside and it behaves 
>> identically.
>>
>> Running the git command with the -v  switch instead of -q gives the 
>> following:
>>
>> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
>> METADATA
>> Cloning into 'METADATA'...
>> fatal: unable to connect to github.com:
>> github.com[0: 192.30.252.131]: errno=Operation timed out
>>
>> This is exactly what the -q switch did.  There was about a 2 minute 
>> (90 second) wait after the "Cloning into 'METADATA'..." message.  Here's 
>> what telnet did:
>>
>> $ telnet github.com 9418
>> Trying 192.30.252.130...
>> Connected to github.com.
>> Escape character is '^]'.
>> ^]
>> telnet> close
>> Connection closed.
>>
>> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so 
>> funky. I use git daily and it doesn't give me any troubles with 
>> CloudForge 
>> or Github (we have another project that uses Github).
>>
>> Which git is Julia using? If it hard codes a location it could be 
>> using the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple 
>> Git-48)).  MacPorts is the one I use in my path, which is at 
>> /opt/local/bin/git.
>>
>> I'm not sure why 2-factor auth would be an issue, since cloning is 
>> anonymous and pretty public??
>>
>> Thanks for your help...any ideas would be welcome.
>>
>> -Jeff.
>>
>> On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:
>>
>>> If it turns out to be a git issue then you have to fix the 
>>> underlying git issue before trying to use git with Julia.
>>>
>>> Do you have a ~/.gitconfig? What's in it? If you run the git clone 
>>> with -v instead of -q, what do you see?
>>>
>>> Just to be clear: this does not appear to be an issue with Julia; 
>>> it's with (your installation of) git. Fix that and Julia should start 
>>> working.
>>>
>>>
>>>
>>> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis 
>>> wrote:

 It's never asked me to authenticate...it just sits there until the 
 connection times out.  I don't do 2-factor auth on my machine, and not 
 with 
 github.

 If it turns out to be a git issue, how do I tell Julia to use the 
 correct/additional options when doing Pkg.?? calls?

 On Thu, Feb 19, 2015 at 4:12 PM, Seth  
 wrote:

> I recall running into this problem with OSX a while ago. Turns out 
> it was an interaction between user credentials in .gitconfig and 
> 2-factor 
> auth. If that sounds similar to your setup, you might want to check 
> that 
> git is authenticating you properly at the command line.
>
>
> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis 
> wrote:
>>
>> I have the exact same problem under OSX. Telnetting to github.com 
>>

Re: [julia-users] can't add packages

[Jeff Kopmanis]

Thanks.  That article recommends using https: instead of git:   Could it be
a MIME-type error or misconfig?

If I want to use the https URL, where do you change that?  Is there a setup
file somewhere?

On Thu, Feb 19, 2015 at 4:49 PM, Seth  wrote:

> That looks unrelated, but the linked issue (
> https://github.com/JuliaLang/julia/issues/8810) might help.
>
> On Thursday, February 19, 2015 at 1:46:30 PM UTC-8, Jeff Kopmanis wrote:
>>
>> Found something...  it might be a combination of the v0.3 Julia and >=
>> 10.8 OSX
>>
>> https://github.com/JuliaLang/julia/issues/6880
>>
>> On Thu, Feb 19, 2015 at 4:43 PM, Jeff Kopmanis  wrote:
>>
>>> nope. Identically.
>>>
>>> I did sysadmin for nearly 17 years at the UMich math dept (macOSX,
>>> solaris, linux) and this one has me scratchin' my head.
>>>
>>> On Thu, Feb 19, 2015 at 4:42 PM, Seth  wrote:
>>>
 I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you
 try both the OSX version and the macports version (using absolute paths to
 confirm), do they behave differently?

 On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:
>
> This is my ~/.gitconfig:
>
> [user]
> name = Jeff Kopmanis
> email = kopm...@umich.edu
> [core]
> excludesfile = /Users/kopmanis/.gitignore_global
> [difftool "sourcetree"]
> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
> path =
> [mergetool "sourcetree"]
> cmd = /Applications/SourceTree.app/C
> ontents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor
> \"$BASE\" -merge \"$MERGED\"
> trustExitCode = true
>
> Its on MacOSX 10.9.  I moved the file aside and it behaves identically.
>
> Running the git command with the -v  switch instead of -q gives the
> following:
>
> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
> METADATA
> Cloning into 'METADATA'...
> fatal: unable to connect to github.com:
> github.com[0: 192.30.252.131]: errno=Operation timed out
>
> This is exactly what the -q switch did.  There was about a 2 minute
> (90 second) wait after the "Cloning into 'METADATA'..." message.  Here's
> what telnet did:
>
> $ telnet github.com 9418
> Trying 192.30.252.130...
> Connected to github.com.
> Escape character is '^]'.
> ^]
> telnet> close
> Connection closed.
>
> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so
> funky. I use git daily and it doesn't give me any troubles with CloudForge
> or Github (we have another project that uses Github).
>
> Which git is Julia using? If it hard codes a location it could be
> using the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple
> Git-48)).  MacPorts is the one I use in my path, which is at
> /opt/local/bin/git.
>
> I'm not sure why 2-factor auth would be an issue, since cloning is
> anonymous and pretty public??
>
> Thanks for your help...any ideas would be welcome.
>
> -Jeff.
>
> On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:
>
>> If it turns out to be a git issue then you have to fix the underlying
>> git issue before trying to use git with Julia.
>>
>> Do you have a ~/.gitconfig? What's in it? If you run the git clone
>> with -v instead of -q, what do you see?
>>
>> Just to be clear: this does not appear to be an issue with Julia;
>> it's with (your installation of) git. Fix that and Julia should start
>> working.
>>
>>
>>
>> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis
>> wrote:
>>>
>>> It's never asked me to authenticate...it just sits there until the
>>> connection times out.  I don't do 2-factor auth on my machine, and not 
>>> with
>>> github.
>>>
>>> If it turns out to be a git issue, how do I tell Julia to use the
>>> correct/additional options when doing Pkg.?? calls?
>>>
>>> On Thu, Feb 19, 2015 at 4:12 PM, Seth 
>>> wrote:
>>>
 I recall running into this problem with OSX a while ago. Turns out
 it was an interaction between user credentials in .gitconfig and 
 2-factor
 auth. If that sounds similar to your setup, you might want to check 
 that
 git is authenticating you properly at the command line.


 On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis
 wrote:
>
> I have the exact same problem under OSX. Telnetting to github.com
> over port 9418 connects just fine.  I've tried both the MacPorts 
> install
> and the binary install from julialang.org with identical (failed)
> results. I've tried the git command suggested below and the connection
> fails again. The documentation link everyone keeps pointing us to (
>>>

Re: [julia-users] can't add packages

[Seth]

That looks unrelated, but the linked issue 
(https://github.com/JuliaLang/julia/issues/8810) might help.

On Thursday, February 19, 2015 at 1:46:30 PM UTC-8, Jeff Kopmanis wrote:
>
> Found something...  it might be a combination of the v0.3 Julia and >= 
> 10.8 OSX
>
> https://github.com/JuliaLang/julia/issues/6880
>
> On Thu, Feb 19, 2015 at 4:43 PM, Jeff Kopmanis  > wrote:
>
>> nope. Identically.
>>
>> I did sysadmin for nearly 17 years at the UMich math dept (macOSX, 
>> solaris, linux) and this one has me scratchin' my head.
>>
>> On Thu, Feb 19, 2015 at 4:42 PM, Seth > > wrote:
>>
>>> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you 
>>> try both the OSX version and the macports version (using absolute paths to 
>>> confirm), do they behave differently?
>>>
>>> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:

 This is my ~/.gitconfig:

 [user]
 name = Jeff Kopmanis
 email = kopm...@umich.edu
 [core]
 excludesfile = /Users/kopmanis/.gitignore_global
 [difftool "sourcetree"]
 cmd = opendiff \"$LOCAL\" \"$REMOTE\"
 path = 
 [mergetool "sourcetree"]
 cmd = /Applications/SourceTree.app/
 Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor 
 \"$BASE\" -merge \"$MERGED\"
 trustExitCode = true

 Its on MacOSX 10.9.  I moved the file aside and it behaves identically.

 Running the git command with the -v  switch instead of -q gives the 
 following:

 $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
 METADATA
 Cloning into 'METADATA'...
 fatal: unable to connect to github.com:
 github.com[0: 192.30.252.131]: errno=Operation timed out

 This is exactly what the -q switch did.  There was about a 2 minute (90 
 second) wait after the "Cloning into 'METADATA'..." message.  Here's what 
 telnet did:

 $ telnet github.com 9418
 Trying 192.30.252.130...
 Connected to github.com.
 Escape character is '^]'.
 ^]
 telnet> close
 Connection closed.

 I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so 
 funky. I use git daily and it doesn't give me any troubles with CloudForge 
 or Github (we have another project that uses Github).

 Which git is Julia using? If it hard codes a location it could be using 
 the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)). 
  
 MacPorts is the one I use in my path, which is at /opt/local/bin/git.

 I'm not sure why 2-factor auth would be an issue, since cloning is 
 anonymous and pretty public??

 Thanks for your help...any ideas would be welcome.

 -Jeff.

 On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:

> If it turns out to be a git issue then you have to fix the underlying 
> git issue before trying to use git with Julia.
>
> Do you have a ~/.gitconfig? What's in it? If you run the git clone 
> with -v instead of -q, what do you see?
>
> Just to be clear: this does not appear to be an issue with Julia; it's 
> with (your installation of) git. Fix that and Julia should start working.
>
>
>
> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis 
> wrote:
>>
>> It's never asked me to authenticate...it just sits there until the 
>> connection times out.  I don't do 2-factor auth on my machine, and not 
>> with 
>> github.
>>
>> If it turns out to be a git issue, how do I tell Julia to use the 
>> correct/additional options when doing Pkg.?? calls?
>>
>> On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:
>>
>>> I recall running into this problem with OSX a while ago. Turns out 
>>> it was an interaction between user credentials in .gitconfig and 
>>> 2-factor 
>>> auth. If that sounds similar to your setup, you might want to check 
>>> that 
>>> git is authenticating you properly at the command line.
>>>
>>>
>>> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis 
>>> wrote:

 I have the exact same problem under OSX. Telnetting to github.com 
 over port 9418 connects just fine.  I've tried both the MacPorts 
 install 
 and the binary install from julialang.org with identical (failed) 
 results. I've tried the git command suggested below and the connection 
 fails again. The documentation link everyone keeps pointing us to (
 https://github.com/julialang/julia#source-download-and-compilation 
 )
  
 doesn't address this situation, so please stop referring us to this.

 I'

Re: [julia-users] can't add packages

[Seth]

I'm afraid I'm out of real ideas. The last thing I'd check is to use the IP 
address ending in .130 in the git request directly: 

git clone -v -b metadata-v2 git://192.30.252.130/JuliaLang/METADATA.jl 
METADATA


but this is grasping at straws at this point.

On Thursday, February 19, 2015 at 1:43:54 PM UTC-8, Jeff Kopmanis wrote:
>
> nope. Identically.
>
> I did sysadmin for nearly 17 years at the UMich math dept (macOSX, 
> solaris, linux) and this one has me scratchin' my head.
>
> On Thu, Feb 19, 2015 at 4:42 PM, Seth  > wrote:
>
>> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you 
>> try both the OSX version and the macports version (using absolute paths to 
>> confirm), do they behave differently?
>>
>> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:
>>>
>>> This is my ~/.gitconfig:
>>>
>>> [user]
>>> name = Jeff Kopmanis
>>> email = kopm...@umich.edu
>>> [core]
>>> excludesfile = /Users/kopmanis/.gitignore_global
>>> [difftool "sourcetree"]
>>> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
>>> path = 
>>> [mergetool "sourcetree"]
>>> cmd = /Applications/SourceTree.app/
>>> Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor 
>>> \"$BASE\" -merge \"$MERGED\"
>>> trustExitCode = true
>>>
>>> Its on MacOSX 10.9.  I moved the file aside and it behaves identically.
>>>
>>> Running the git command with the -v  switch instead of -q gives the 
>>> following:
>>>
>>> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
>>> METADATA
>>> Cloning into 'METADATA'...
>>> fatal: unable to connect to github.com:
>>> github.com[0: 192.30.252.131]: errno=Operation timed out
>>>
>>> This is exactly what the -q switch did.  There was about a 2 minute (90 
>>> second) wait after the "Cloning into 'METADATA'..." message.  Here's what 
>>> telnet did:
>>>
>>> $ telnet github.com 9418
>>> Trying 192.30.252.130...
>>> Connected to github.com.
>>> Escape character is '^]'.
>>> ^]
>>> telnet> close
>>> Connection closed.
>>>
>>> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so 
>>> funky. I use git daily and it doesn't give me any troubles with CloudForge 
>>> or Github (we have another project that uses Github).
>>>
>>> Which git is Julia using? If it hard codes a location it could be using 
>>> the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)).  
>>> MacPorts is the one I use in my path, which is at /opt/local/bin/git.
>>>
>>> I'm not sure why 2-factor auth would be an issue, since cloning is 
>>> anonymous and pretty public??
>>>
>>> Thanks for your help...any ideas would be welcome.
>>>
>>> -Jeff.
>>>
>>> On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:
>>>
 If it turns out to be a git issue then you have to fix the underlying 
 git issue before trying to use git with Julia.

 Do you have a ~/.gitconfig? What's in it? If you run the git clone with 
 -v instead of -q, what do you see?

 Just to be clear: this does not appear to be an issue with Julia; it's 
 with (your installation of) git. Fix that and Julia should start working.



 On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:
>
> It's never asked me to authenticate...it just sits there until the 
> connection times out.  I don't do 2-factor auth on my machine, and not 
> with 
> github.
>
> If it turns out to be a git issue, how do I tell Julia to use the 
> correct/additional options when doing Pkg.?? calls?
>
> On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:
>
>> I recall running into this problem with OSX a while ago. Turns out it 
>> was an interaction between user credentials in .gitconfig and 2-factor 
>> auth. If that sounds similar to your setup, you might want to check that 
>> git is authenticating you properly at the command line.
>>
>>
>> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis 
>> wrote:
>>>
>>> I have the exact same problem under OSX. Telnetting to github.com 
>>> over port 9418 connects just fine.  I've tried both the MacPorts 
>>> install 
>>> and the binary install from julialang.org with identical (failed) 
>>> results. I've tried the git command suggested below and the connection 
>>> fails again. The documentation link everyone keeps pointing us to (
>>> https://github.com/julialang/julia#source-download-and-compilation 
>>> )
>>>  
>>> doesn't address this situation, so please stop referring us to this.
>>>
>>> I've also tried moving files into /usr/local/shared/julia/site/v0.3 
>>> to duplicate an install, but that's useless, as it thinks its still in 
>>> that 
>>> individual user's direct

Re: [julia-users] can't add packages

[Jeff Kopmanis]

Found something...  it might be a combination of the v0.3 Julia and >= 10.8
OSX

https://github.com/JuliaLang/julia/issues/6880

On Thu, Feb 19, 2015 at 4:43 PM, Jeff Kopmanis  wrote:

> nope. Identically.
>
> I did sysadmin for nearly 17 years at the UMich math dept (macOSX,
> solaris, linux) and this one has me scratchin' my head.
>
> On Thu, Feb 19, 2015 at 4:42 PM, Seth  wrote:
>
>> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you
>> try both the OSX version and the macports version (using absolute paths to
>> confirm), do they behave differently?
>>
>> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:
>>>
>>> This is my ~/.gitconfig:
>>>
>>> [user]
>>> name = Jeff Kopmanis
>>> email = kopm...@umich.edu
>>> [core]
>>> excludesfile = /Users/kopmanis/.gitignore_global
>>> [difftool "sourcetree"]
>>> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
>>> path =
>>> [mergetool "sourcetree"]
>>> cmd = /Applications/SourceTree.app/
>>> Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor
>>> \"$BASE\" -merge \"$MERGED\"
>>> trustExitCode = true
>>>
>>> Its on MacOSX 10.9.  I moved the file aside and it behaves identically.
>>>
>>> Running the git command with the -v  switch instead of -q gives the
>>> following:
>>>
>>> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
>>> METADATA
>>> Cloning into 'METADATA'...
>>> fatal: unable to connect to github.com:
>>> github.com[0: 192.30.252.131]: errno=Operation timed out
>>>
>>> This is exactly what the -q switch did.  There was about a 2 minute (90
>>> second) wait after the "Cloning into 'METADATA'..." message.  Here's what
>>> telnet did:
>>>
>>> $ telnet github.com 9418
>>> Trying 192.30.252.130...
>>> Connected to github.com.
>>> Escape character is '^]'.
>>> ^]
>>> telnet> close
>>> Connection closed.
>>>
>>> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so
>>> funky. I use git daily and it doesn't give me any troubles with CloudForge
>>> or Github (we have another project that uses Github).
>>>
>>> Which git is Julia using? If it hard codes a location it could be using
>>> the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)).
>>> MacPorts is the one I use in my path, which is at /opt/local/bin/git.
>>>
>>> I'm not sure why 2-factor auth would be an issue, since cloning is
>>> anonymous and pretty public??
>>>
>>> Thanks for your help...any ideas would be welcome.
>>>
>>> -Jeff.
>>>
>>> On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:
>>>
 If it turns out to be a git issue then you have to fix the underlying
 git issue before trying to use git with Julia.

 Do you have a ~/.gitconfig? What's in it? If you run the git clone with
 -v instead of -q, what do you see?

 Just to be clear: this does not appear to be an issue with Julia; it's
 with (your installation of) git. Fix that and Julia should start working.



 On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:
>
> It's never asked me to authenticate...it just sits there until the
> connection times out.  I don't do 2-factor auth on my machine, and not 
> with
> github.
>
> If it turns out to be a git issue, how do I tell Julia to use the
> correct/additional options when doing Pkg.?? calls?
>
> On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:
>
>> I recall running into this problem with OSX a while ago. Turns out it
>> was an interaction between user credentials in .gitconfig and 2-factor
>> auth. If that sounds similar to your setup, you might want to check that
>> git is authenticating you properly at the command line.
>>
>>
>> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis
>> wrote:
>>>
>>> I have the exact same problem under OSX. Telnetting to github.com
>>> over port 9418 connects just fine.  I've tried both the MacPorts install
>>> and the binary install from julialang.org with identical (failed)
>>> results. I've tried the git command suggested below and the connection
>>> fails again. The documentation link everyone keeps pointing us to (
>>> https://github.com/julialang/julia#source-download-and-compilation
>>> )
>>> doesn't address this situation, so please stop referring us to this.
>>>
>>> I've also tried moving files into /usr/local/shared/julia/site/v0.3
>>> to duplicate an install, but that's useless, as it thinks its still in 
>>> that
>>> individual user's directory (there must be some hard coded paths 
>>> somewhere
>>> in the installed packages).
>>>
>>> What's next, folks?
>>>
>>> -Jeff. :(
>>>
>>> On Saturday, August 2, 201

Re: [julia-users] can't add packages

[Jeff Kopmanis]

nope. Identically.

I did sysadmin for nearly 17 years at the UMich math dept (macOSX, solaris,
linux) and this one has me scratchin' my head.

On Thu, Feb 19, 2015 at 4:42 PM, Seth  wrote:

> I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you
> try both the OSX version and the macports version (using absolute paths to
> confirm), do they behave differently?
>
> On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:
>>
>> This is my ~/.gitconfig:
>>
>> [user]
>> name = Jeff Kopmanis
>> email = kopm...@umich.edu
>> [core]
>> excludesfile = /Users/kopmanis/.gitignore_global
>> [difftool "sourcetree"]
>> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
>> path =
>> [mergetool "sourcetree"]
>> cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh
>> \"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
>> trustExitCode = true
>>
>> Its on MacOSX 10.9.  I moved the file aside and it behaves identically.
>>
>> Running the git command with the -v  switch instead of -q gives the
>> following:
>>
>> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
>> METADATA
>> Cloning into 'METADATA'...
>> fatal: unable to connect to github.com:
>> github.com[0: 192.30.252.131]: errno=Operation timed out
>>
>> This is exactly what the -q switch did.  There was about a 2 minute (90
>> second) wait after the "Cloning into 'METADATA'..." message.  Here's what
>> telnet did:
>>
>> $ telnet github.com 9418
>> Trying 192.30.252.130...
>> Connected to github.com.
>> Escape character is '^]'.
>> ^]
>> telnet> close
>> Connection closed.
>>
>> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so
>> funky. I use git daily and it doesn't give me any troubles with CloudForge
>> or Github (we have another project that uses Github).
>>
>> Which git is Julia using? If it hard codes a location it could be using
>> the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)).
>> MacPorts is the one I use in my path, which is at /opt/local/bin/git.
>>
>> I'm not sure why 2-factor auth would be an issue, since cloning is
>> anonymous and pretty public??
>>
>> Thanks for your help...any ideas would be welcome.
>>
>> -Jeff.
>>
>> On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:
>>
>>> If it turns out to be a git issue then you have to fix the underlying
>>> git issue before trying to use git with Julia.
>>>
>>> Do you have a ~/.gitconfig? What's in it? If you run the git clone with
>>> -v instead of -q, what do you see?
>>>
>>> Just to be clear: this does not appear to be an issue with Julia; it's
>>> with (your installation of) git. Fix that and Julia should start working.
>>>
>>>
>>>
>>> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:

 It's never asked me to authenticate...it just sits there until the
 connection times out.  I don't do 2-factor auth on my machine, and not with
 github.

 If it turns out to be a git issue, how do I tell Julia to use the
 correct/additional options when doing Pkg.?? calls?

 On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:

> I recall running into this problem with OSX a while ago. Turns out it
> was an interaction between user credentials in .gitconfig and 2-factor
> auth. If that sounds similar to your setup, you might want to check that
> git is authenticating you properly at the command line.
>
>
> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis
> wrote:
>>
>> I have the exact same problem under OSX. Telnetting to github.com
>> over port 9418 connects just fine.  I've tried both the MacPorts install
>> and the binary install from julialang.org with identical (failed)
>> results. I've tried the git command suggested below and the connection
>> fails again. The documentation link everyone keeps pointing us to (
>> https://github.com/julialang/julia#source-download-and-compilation
>> )
>> doesn't address this situation, so please stop referring us to this.
>>
>> I've also tried moving files into /usr/local/shared/julia/site/v0.3
>> to duplicate an install, but that's useless, as it thinks its still in 
>> that
>> individual user's directory (there must be some hard coded paths 
>> somewhere
>> in the installed packages).
>>
>> What's next, folks?
>>
>> -Jeff. :(
>>
>> On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski
>> wrote:
>>>
>>> Julia is just using the git program, so the problem here must be
>>> with git connecting to github.com over the git protocol. Can you
>>> try doing
>>>
>>> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
>>> METADAT

Re: [julia-users] can't add packages

[Seth]

I'm at a loss. I'm using the OSX git (part of xcode) on 10.10.2. If you try 
both the OSX version and the macports version (using absolute paths to 
confirm), do they behave differently?

On Thursday, February 19, 2015 at 1:35:23 PM UTC-8, Jeff Kopmanis wrote:
>
> This is my ~/.gitconfig:
>
> [user]
> name = Jeff Kopmanis
> email = kopm...@umich.edu 
> [core]
> excludesfile = /Users/kopmanis/.gitignore_global
> [difftool "sourcetree"]
> cmd = opendiff \"$LOCAL\" \"$REMOTE\"
> path = 
> [mergetool "sourcetree"]
> cmd = 
> /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh \"$LOCAL\" 
> \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
> trustExitCode = true
>
> Its on MacOSX 10.9.  I moved the file aside and it behaves identically.
>
> Running the git command with the -v  switch instead of -q gives the 
> following:
>
> $ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
> METADATA
> Cloning into 'METADATA'...
> fatal: unable to connect to github.com:
> github.com[0: 192.30.252.131]: errno=Operation timed out
>
> This is exactly what the -q switch did.  There was about a 2 minute (90 
> second) wait after the "Cloning into 'METADATA'..." message.  Here's what 
> telnet did:
>
> $ telnet github.com 9418
> Trying 192.30.252.130...
> Connected to github.com.
> Escape character is '^]'.
> ^]
> telnet> close
> Connection closed.
>
> I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so funky. 
> I use git daily and it doesn't give me any troubles with CloudForge or 
> Github (we have another project that uses Github).
>
> Which git is Julia using? If it hard codes a location it could be using 
> the MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)).  
> MacPorts is the one I use in my path, which is at /opt/local/bin/git.
>
> I'm not sure why 2-factor auth would be an issue, since cloning is 
> anonymous and pretty public??
>
> Thanks for your help...any ideas would be welcome.
>
> -Jeff.
>
> On Thu, Feb 19, 2015 at 4:19 PM, Seth  > wrote:
>
>> If it turns out to be a git issue then you have to fix the underlying git 
>> issue before trying to use git with Julia.
>>
>> Do you have a ~/.gitconfig? What's in it? If you run the git clone with 
>> -v instead of -q, what do you see?
>>
>> Just to be clear: this does not appear to be an issue with Julia; it's 
>> with (your installation of) git. Fix that and Julia should start working.
>>
>>
>>
>> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:
>>>
>>> It's never asked me to authenticate...it just sits there until the 
>>> connection times out.  I don't do 2-factor auth on my machine, and not with 
>>> github.
>>>
>>> If it turns out to be a git issue, how do I tell Julia to use the 
>>> correct/additional options when doing Pkg.?? calls?
>>>
>>> On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:
>>>
 I recall running into this problem with OSX a while ago. Turns out it 
 was an interaction between user credentials in .gitconfig and 2-factor 
 auth. If that sounds similar to your setup, you might want to check that 
 git is authenticating you properly at the command line.


 On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis 
 wrote:
>
> I have the exact same problem under OSX. Telnetting to github.com 
> over port 9418 connects just fine.  I've tried both the MacPorts install 
> and the binary install from julialang.org with identical (failed) 
> results. I've tried the git command suggested below and the connection 
> fails again. The documentation link everyone keeps pointing us to (
> https://github.com/julialang/julia#source-download-and-compilation 
> )
>  
> doesn't address this situation, so please stop referring us to this.
>
> I've also tried moving files into /usr/local/shared/julia/site/v0.3 
> to duplicate an install, but that's useless, as it thinks its still in 
> that 
> individual user's directory (there must be some hard coded paths 
> somewhere 
> in the installed packages).
>
> What's next, folks?
>
> -Jeff. :(
>
> On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski 
> wrote:
>>
>> Julia is just using the git program, so the problem here must be with 
>> git connecting to github.com over the git protocol. Can you try doing
>>
>> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
>> METADATA
>>
>> at the command line? Hopefully you can narrow it down to a failing 
>> case.
>>
>>
>> On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan  
>> wrote:
>>
>>> I am able to use git protocol there's no problem with that, git 
>>> work

Re: [julia-users] can't add packages

[Jeff Kopmanis]

This is my ~/.gitconfig:

[user]
name = Jeff Kopmanis
email = kopma...@umich.edu
[core]
excludesfile = /Users/kopmanis/.gitignore_global
[difftool "sourcetree"]
cmd = opendiff \"$LOCAL\" \"$REMOTE\"
path =
[mergetool "sourcetree"]
cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh
\"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
trustExitCode = true

Its on MacOSX 10.9.  I moved the file aside and it behaves identically.

Running the git command with the -v  switch instead of -q gives the
following:

$ git clone -v -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
METADATA
Cloning into 'METADATA'...
fatal: unable to connect to github.com:
github.com[0: 192.30.252.131]: errno=Operation timed out

This is exactly what the -q switch did.  There was about a 2 minute (90
second) wait after the "Cloning into 'METADATA'..." message.  Here's what
telnet did:

$ telnet github.com 9418
Trying 192.30.252.130...
Connected to github.com.
Escape character is '^]'.
^]
telnet> close
Connection closed.

I'm using git v2.2.1, and its the MacPorts copy, since MacOSX is so funky.
I use git daily and it doesn't give me any troubles with CloudForge or
Github (we have another project that uses Github).

Which git is Julia using? If it hard codes a location it could be using the
MacOSX standard copy in /usr/bin/git (version 1.8.5.2 (Apple Git-48)).
MacPorts is the one I use in my path, which is at /opt/local/bin/git.

I'm not sure why 2-factor auth would be an issue, since cloning is
anonymous and pretty public??

Thanks for your help...any ideas would be welcome.

-Jeff.

On Thu, Feb 19, 2015 at 4:19 PM, Seth  wrote:

> If it turns out to be a git issue then you have to fix the underlying git
> issue before trying to use git with Julia.
>
> Do you have a ~/.gitconfig? What's in it? If you run the git clone with -v
> instead of -q, what do you see?
>
> Just to be clear: this does not appear to be an issue with Julia; it's
> with (your installation of) git. Fix that and Julia should start working.
>
>
>
> On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:
>>
>> It's never asked me to authenticate...it just sits there until the
>> connection times out.  I don't do 2-factor auth on my machine, and not with
>> github.
>>
>> If it turns out to be a git issue, how do I tell Julia to use the
>> correct/additional options when doing Pkg.?? calls?
>>
>> On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:
>>
>>> I recall running into this problem with OSX a while ago. Turns out it
>>> was an interaction between user credentials in .gitconfig and 2-factor
>>> auth. If that sounds similar to your setup, you might want to check that
>>> git is authenticating you properly at the command line.
>>>
>>>
>>> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis wrote:

 I have the exact same problem under OSX. Telnetting to github.com over
 port 9418 connects just fine.  I've tried both the MacPorts install and the
 binary install from julialang.org with identical (failed) results.
 I've tried the git command suggested below and the connection fails again.
 The documentation link everyone keeps pointing us to (
 https://github.com/julialang/julia#source-download-and-compilation
 )
 doesn't address this situation, so please stop referring us to this.

 I've also tried moving files into /usr/local/shared/julia/site/v0.3 to
 duplicate an install, but that's useless, as it thinks its still in that
 individual user's directory (there must be some hard coded paths somewhere
 in the installed packages).

 What's next, folks?

 -Jeff. :(

 On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski
 wrote:
>
> Julia is just using the git program, so the problem here must be with
> git connecting to github.com over the git protocol. Can you try doing
>
> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
> METADATA
>
> at the command line? Hopefully you can narrow it down to a failing
> case.
>
>
> On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan 
> wrote:
>
>> I am able to use git protocol there's no problem with that, git works
>> out of the box. However somehow julia can't connect to github. I added
>> julia from the ppa .
>>
>>
>> On Sat, Aug 2, 2014 at 9:07 AM, Stefan Karpinski <
>> ste...@karpinski.org> wrote:
>>
>>> You are most likely behind a firewall. Can you clone packages from
>>> github manually using the git protocol? Can you telnet to github.com
>>> on port 9418?
>>>
>>>
>>> On Fri, Aug 1, 2014 at 5:48 PM, Shubham Bhushan 
>>> wrote:
>>>

Re: [julia-users] computing speed of log

[Rohan Fernando]

Thanks, using Float32 speeds up the code a bit:

*julia> **function f1()*

   *a=2.0*

   *for i=1:100*

   *a+=exp(a%2+1);*

   *end*

   *@printf "%20.5e \n" a*

   *end*

*f1 (generic function with 1 method)*


*julia> **@time f1()*

 8.75047e+06 

elapsed time: 0.068128135 seconds (805832 bytes allocated)


*julia> **@time f1()*

 8.75047e+06 

elapsed time: 0.045130403 seconds (528 bytes allocated)


*julia> **@time f1()*

 8.75047e+06 

elapsed time: 0.045146918 seconds (528 bytes allocated)


*julia> **function f2()*

   *a::Float32 = 2.0*

   *b::Float32 = 2.0*

   *for i=1:100*

   *a += exp(a%b + 1)*

   *end*

   *@printf "%20.5e \n" a*

   *end*

*f2 (generic function with 1 method)*


*julia> **@time f2()*

 8.74511e+06 

elapsed time: 0.051448558 seconds (728816 bytes allocated)


*julia> **@time f2()*

 8.74511e+06 

elapsed time: 0.035552156 seconds (528 bytes allocated)


*julia> **@time f2()*

 8.74511e+06 

elapsed time: 0.035797496 seconds (528 bytes allocated)


I think a=2.0f32 gives something different from what I intended:


*julia> **a = 2.0f32*

*2.0f32*


*julia> **@printf "%10.5e \n" a*

2.0e+32 




On Wednesday, February 18, 2015 at 8:40:48 PM UTC-6, Kuba Roth wrote:
>
> I think this comparison is not fair since C++ version uses float32 and 
> Julia float64 by default. 
> If you provide that information to the compiler the results are similar. 
>
> function test1() 
> a=2.0f32 
> for i=1:100 
> a+=exp(a%2.0f32); 
> end 
> end 
>
> @time test1() 
>
> Julia elapsed time: 0.018281912 seconds (125220 bytes allocated) 
> C++   me 3 clicks (0.03 seconds). 
>
>
> Interstingly Julia's example using Integer in mod operation is slower: 
> a+=exp(a%2); 
> elapsed time: 0.049916461 seconds (304116 bytes allocated) 
>
> These toy benchmarks are pointless anyway.

Re: [julia-users] can't add packages

[Seth]

If it turns out to be a git issue then you have to fix the underlying git 
issue before trying to use git with Julia.

Do you have a ~/.gitconfig? What's in it? If you run the git clone with -v 
instead of -q, what do you see?

Just to be clear: this does not appear to be an issue with Julia; it's with 
(your installation of) git. Fix that and Julia should start working.



On Thursday, February 19, 2015 at 1:15:46 PM UTC-8, Jeff Kopmanis wrote:
>
> It's never asked me to authenticate...it just sits there until the 
> connection times out.  I don't do 2-factor auth on my machine, and not with 
> github.
>
> If it turns out to be a git issue, how do I tell Julia to use the 
> correct/additional options when doing Pkg.?? calls?
>
> On Thu, Feb 19, 2015 at 4:12 PM, Seth  > wrote:
>
>> I recall running into this problem with OSX a while ago. Turns out it was 
>> an interaction between user credentials in .gitconfig and 2-factor auth. If 
>> that sounds similar to your setup, you might want to check that git is 
>> authenticating you properly at the command line.
>>
>>
>> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis wrote:
>>>
>>> I have the exact same problem under OSX. Telnetting to github.com over 
>>> port 9418 connects just fine.  I've tried both the MacPorts install and the 
>>> binary install from julialang.org with identical (failed) results. I've 
>>> tried the git command suggested below and the connection fails again. The 
>>> documentation link everyone keeps pointing us to (
>>> https://github.com/julialang/julia#source-download-and-compilation 
>>> )
>>>  
>>> doesn't address this situation, so please stop referring us to this.
>>>
>>> I've also tried moving files into /usr/local/shared/julia/site/v0.3 to 
>>> duplicate an install, but that's useless, as it thinks its still in that 
>>> individual user's directory (there must be some hard coded paths somewhere 
>>> in the installed packages).
>>>
>>> What's next, folks?
>>>
>>> -Jeff. :(
>>>
>>> On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski wrote:

 Julia is just using the git program, so the problem here must be with 
 git connecting to github.com over the git protocol. Can you try doing

 git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
 METADATA

 at the command line? Hopefully you can narrow it down to a failing case.


 On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan  
 wrote:

> I am able to use git protocol there's no problem with that, git works 
> out of the box. However somehow julia can't connect to github. I added 
> julia from the ppa .
>
>
> On Sat, Aug 2, 2014 at 9:07 AM, Stefan Karpinski  > wrote:
>
>> You are most likely behind a firewall. Can you clone packages from 
>> github manually using the git protocol? Can you telnet to github.com 
>> on port 9418?
>>  
>>
>> On Fri, Aug 1, 2014 at 5:48 PM, Shubham Bhushan  
>> wrote:
>>
>>> please help I can't add any packages I really really want to use 
>>> julia but i can't and the mailing list is terrible. But still I am 
>>> hoping 
>>> someone will help.
>>>  so here's what I am getting
>>> julia> Pkg.init()
>>> INFO: Initializing package repository /home/shubham/.julia/v0.2
>>> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
>>> fatal: unable to connect to github.com:
>>> github.com[0: 192.30.252.131]: errno=Connection timed out
>>>
>>> ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
>>> github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) 
>>> [128]
>>>  in pipeline_error at process.jl:476
>>>  in run at process.jl:453
>>>  in anonymous at no file:43
>>>  in cd at file.jl:22
>>>  in init at pkg/dir.jl:41
>>>  in init at pkg.jl:15
>>>
>>>
>>> please help. 
>>>
>>>
>>>  
>>
>
>
> -- 
> http://about.me/shubham.bhushan
>  


>
>
> -- 
> Jeff Kopmanis
> Monroe Big Band: http://monroebigband.com
> Sweet Melissa: http://sweetmelissarocks.com
> Soul Kitchen: http://soulkitchencooks.com
> Orange Can Astronomy http://orange-can.blogspot.com
> Pickle Reviews http://pickle-review.blogspot.com
> Saxessories http://saxessories.blogspot.com
> ** Go Green and leave this email on the Screen! **
>  

Re: [julia-users] can't add packages

[Jeff Kopmanis]

It's never asked me to authenticate...it just sits there until the
connection times out.  I don't do 2-factor auth on my machine, and not with
github.

If it turns out to be a git issue, how do I tell Julia to use the
correct/additional options when doing Pkg.?? calls?

On Thu, Feb 19, 2015 at 4:12 PM, Seth  wrote:

> I recall running into this problem with OSX a while ago. Turns out it was
> an interaction between user credentials in .gitconfig and 2-factor auth. If
> that sounds similar to your setup, you might want to check that git is
> authenticating you properly at the command line.
>
>
> On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis wrote:
>>
>> I have the exact same problem under OSX. Telnetting to github.com over
>> port 9418 connects just fine.  I've tried both the MacPorts install and the
>> binary install from julialang.org with identical (failed) results. I've
>> tried the git command suggested below and the connection fails again. The
>> documentation link everyone keeps pointing us to (
>> https://github.com/julialang/julia#source-download-and-compilation
>> )
>> doesn't address this situation, so please stop referring us to this.
>>
>> I've also tried moving files into /usr/local/shared/julia/site/v0.3 to
>> duplicate an install, but that's useless, as it thinks its still in that
>> individual user's directory (there must be some hard coded paths somewhere
>> in the installed packages).
>>
>> What's next, folks?
>>
>> -Jeff. :(
>>
>> On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> Julia is just using the git program, so the problem here must be with
>>> git connecting to github.com over the git protocol. Can you try doing
>>>
>>> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl
>>> METADATA
>>>
>>> at the command line? Hopefully you can narrow it down to a failing case.
>>>
>>>
>>> On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan 
>>> wrote:
>>>
 I am able to use git protocol there's no problem with that, git works
 out of the box. However somehow julia can't connect to github. I added
 julia from the ppa .


 On Sat, Aug 2, 2014 at 9:07 AM, Stefan Karpinski 
 wrote:

> You are most likely behind a firewall. Can you clone packages from
> github manually using the git protocol? Can you telnet to github.com
> on port 9418?
>
>
> On Fri, Aug 1, 2014 at 5:48 PM, Shubham Bhushan 
> wrote:
>
>> please help I can't add any packages I really really want to use
>> julia but i can't and the mailing list is terrible. But still I am hoping
>> someone will help.
>>  so here's what I am getting
>> julia> Pkg.init()
>> INFO: Initializing package repository /home/shubham/.julia/v0.2
>> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
>> fatal: unable to connect to github.com:
>> github.com[0: 192.30.252.131]: errno=Connection timed out
>>
>> ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
>> github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
>>  in pipeline_error at process.jl:476
>>  in run at process.jl:453
>>  in anonymous at no file:43
>>  in cd at file.jl:22
>>  in init at pkg/dir.jl:41
>>  in init at pkg.jl:15
>>
>>
>> please help.
>>
>>
>>
>


 --
 http://about.me/shubham.bhushan

>>>
>>>


-- 
Jeff Kopmanis
Monroe Big Band: http://monroebigband.com
Sweet Melissa: http://sweetmelissarocks.com
Soul Kitchen: http://soulkitchencooks.com
Orange Can Astronomy http://orange-can.blogspot.com
Pickle Reviews http://pickle-review.blogspot.com
Saxessories http://saxessories.blogspot.com
** Go Green and leave this email on the Screen! **

Re: [julia-users] can't add packages

[Seth]

I recall running into this problem with OSX a while ago. Turns out it was 
an interaction between user credentials in .gitconfig and 2-factor auth. If 
that sounds similar to your setup, you might want to check that git is 
authenticating you properly at the command line.

On Thursday, February 19, 2015 at 12:30:56 PM UTC-8, Jeff Kopmanis wrote:
>
> I have the exact same problem under OSX. Telnetting to github.com over 
> port 9418 connects just fine.  I've tried both the MacPorts install and the 
> binary install from julialang.org with identical (failed) results. I've 
> tried the git command suggested below and the connection fails again. The 
> documentation link everyone keeps pointing us to (
> https://github.com/julialang/julia#source-download-and-compilation 
> )
>  
> doesn't address this situation, so please stop referring us to this.
>
> I've also tried moving files into /usr/local/shared/julia/site/v0.3 to 
> duplicate an install, but that's useless, as it thinks its still in that 
> individual user's directory (there must be some hard coded paths somewhere 
> in the installed packages).
>
> What's next, folks?
>
> -Jeff. :(
>
> On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski wrote:
>>
>> Julia is just using the git program, so the problem here must be with git 
>> connecting to github.com over the git protocol. Can you try doing
>>
>> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
>> METADATA
>>
>> at the command line? Hopefully you can narrow it down to a failing case.
>>
>>
>> On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan  
>> wrote:
>>
>>> I am able to use git protocol there's no problem with that, git works 
>>> out of the box. However somehow julia can't connect to github. I added 
>>> julia from the ppa .
>>>
>>>
>>> On Sat, Aug 2, 2014 at 9:07 AM, Stefan Karpinski  
>>> wrote:
>>>
 You are most likely behind a firewall. Can you clone packages from 
 github manually using the git protocol? Can you telnet to github.com 
 on port 9418?
  

 On Fri, Aug 1, 2014 at 5:48 PM, Shubham Bhushan  
 wrote:

> please help I can't add any packages I really really want to use julia 
> but i can't and the mailing list is terrible. But still I am hoping 
> someone 
> will help.
>  so here's what I am getting
> julia> Pkg.init()
> INFO: Initializing package repository /home/shubham/.julia/v0.2
> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
> fatal: unable to connect to github.com:
> github.com[0: 192.30.252.131]: errno=Connection timed out
>
> ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
> github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
>  in pipeline_error at process.jl:476
>  in run at process.jl:453
>  in anonymous at no file:43
>  in cd at file.jl:22
>  in init at pkg/dir.jl:41
>  in init at pkg.jl:15
>
>
> please help. 
>
>
>  

>>>
>>>
>>> -- 
>>> http://about.me/shubham.bhushan
>>>  
>>
>>

Re: [julia-users] computing speed of log

[Rohan Fernando]

Memory allocation was 93896 bytes when I ran the function in iJulia 
Notebook. When I run it from the console it allocates only 96 bytes as you 
suggested!

Thanks very much to all the helpful messages!

On Wednesday, February 18, 2015 at 8:10:35 PM UTC-6, Stefan Karpinski wrote:
>
> Time it twice – those 93896 bytes allocated are from code generation. This 
> code should not allocate any memory except the return value, which should 
> be about 96 bytes or something like that.
>
> On Wed, Feb 18, 2015 at 8:01 PM, Rohan Fernando  > wrote:
>
>> Sorry, I used log in the earlier script. Now with a=2.0, C++ is only 
>> twice as fast.
>>
>> function f1()
>> a=2.0
>> for i=1:100
>> a+=exp(a%2+1);
>> end
>> a
>> end
>> @time f1()
>>
>> elapsed time: 0.051447387 seconds (93896 bytes allocated)
>>
>>
>> On Wednesday, February 18, 2015 at 6:11:41 PM UTC-6, Peter Simon wrote:
>>
>>> Not sure why this is, but when I replace 2 with 2.0 in the first line of 
>>> the function it seems to speed up by a factor of 8.
>>>
>>> On Wednesday, February 18, 2015 at 3:48:15 PM UTC-8, Rohan Fernando 
>>> wrote:

 Wrapped in function, but timing did not change.

 function f1()
 a=2
 for i=1:100
 a+=log(a%2+1);
 end
 a
 end
 @time f1()

 output:

 elapsed time: 0.151813773 seconds (64080600 bytes allocated, 15.55% gc 
 time)



 On Wednesday, February 18, 2015 at 5:19:21 PM UTC-6, Stefan Karpinski 
 wrote:
>
> Try wrapping the Julia code in a function and try again. The slow part 
> is incrementing `a` not the exp.
>
> http://julia.readthedocs.org/en/latest/manual/performance-
> tips/#avoid-global-variables
>
> On Wed, Feb 18, 2015 at 6:15 PM, Rohan Fernando  
> wrote:
>
>> Here is the C++ code:
>>
>>
>> #include 
>>
>> #include 
>>
>>
>>
>> int main(int argc, const char * argv[]) {
>>
>>
>> srand (time(NULL));
>>
>>
>> clock_t t;
>>
>> int a=2;
>>
>> t = clock();
>>
>> for (unsigned i=0; i<100; i++) {
>>
>> //a+=(log(a));
>>
>> a+=exp(a%2);
>>
>> //a+=(rand()%2+1);
>>
>> }
>>
>> 
>>
>> t = clock() - t;
>>
>> printf ("It took me %d clicks (%f seconds).\n",t,((float)t)/CLOC
>> KS_PER_SEC);
>>
>> std::cout<>
>> return 0;
>>
>> }
>>
>>
>> The output:
>>
>>
>> *It took me 22177 clicks (0.022177 seconds).*
>>
>> *201*
>>
>> Program ended with exit code: 0
>>
>> Julia Code:
>>
>> a=2
>> @time for i=1:100
>> a+=exp(a%2);
>> end
>>
>> ouput:
>>
>> elapsed time: 0.136568599 seconds (4784 bytes allocated, 18.22% gc 
>> time)
>>
>>
>>
>> Thanks.
>>
>> On Wednesday, February 18, 2015 at 4:56:40 PM UTC-6, Stefan Karpinski 
>> wrote:
>>>
>>> How did you do the timing?
>>>
>>> On Wed, Feb 18, 2015 at 5:54 PM, Rohan Fernando  
>>> wrote:
>>>
 I ran both, Julia and C++, on Mac OS X 10.10.2.

 Is that the information you asked for? 

 Thanks!

 On Wednesday, February 18, 2015 at 2:32:23 PM UTC-6, 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 <
> rohan...@gmail.com> wrote:
>
>>
>>
>> The log and exponential functions in Julia are about five times 
>> slower than in C++. Is this reasonable? 
>>
>
>
>>>
>
>

Re: [julia-users] can't add packages

[Jeff Kopmanis]

I have the exact same problem under OSX. Telnetting to github.com over port 
9418 connects just fine.  I've tried both the MacPorts install and the 
binary install from julialang.org with identical (failed) results. I've 
tried the git command suggested below and the connection fails again. The 
documentation link everyone keeps pointing us to (
https://github.com/julialang/julia#source-download-and-compilation 
)
 
doesn't address this situation, so please stop referring us to this.

I've also tried moving files into /usr/local/shared/julia/site/v0.3 to 
duplicate an install, but that's useless, as it thinks its still in that 
individual user's directory (there must be some hard coded paths somewhere 
in the installed packages).

What's next, folks?

-Jeff. :(

On Saturday, August 2, 2014 at 12:34:15 PM UTC-4, Stefan Karpinski wrote:
>
> Julia is just using the git program, so the problem here must be with git 
> connecting to github.com over the git protocol. Can you try doing
>
> git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl 
> METADATA
>
> at the command line? Hopefully you can narrow it down to a failing case.
>
>
> On Sat, Aug 2, 2014 at 2:56 AM, Shubham Bhushan  > wrote:
>
>> I am able to use git protocol there's no problem with that, git works out 
>> of the box. However somehow julia can't connect to github. I added julia 
>> from the ppa .
>>
>>
>> On Sat, Aug 2, 2014 at 9:07 AM, Stefan Karpinski > > wrote:
>>
>>> You are most likely behind a firewall. Can you clone packages from 
>>> github manually using the git protocol? Can you telnet to github.com on 
>>> port 9418?
>>>  
>>>
>>> On Fri, Aug 1, 2014 at 5:48 PM, Shubham Bhushan >> > wrote:
>>>
 please help I can't add any packages I really really want to use julia 
 but i can't and the mailing list is terrible. But still I am hoping 
 someone 
 will help.
  so here's what I am getting
 julia> Pkg.init()
 INFO: Initializing package repository /home/shubham/.julia/v0.2
 INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
 fatal: unable to connect to github.com:
 github.com[0: 192.30.252.131]: errno=Connection timed out

 ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
 github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
  in pipeline_error at process.jl:476
  in run at process.jl:453
  in anonymous at no file:43
  in cd at file.jl:22
  in init at pkg/dir.jl:41
  in init at pkg.jl:15


 please help. 


  
>>>
>>
>>
>> -- 
>> http://about.me/shubham.bhushan
>>  
>
>

Re: [julia-users] using both plt.hist and base.hist

[Kevin Squire]

Didn't know that--thanks for the info!

On Thursday, February 19, 2015, David P. Sanders 
wrote:

>
>
> El miércoles, 18 de febrero de 2015, 15:58:13 (UTC-6), Kevin Squire
> escribió:
>>
>> Hi Sam,
>>
>> Just to be clear, you're using PyPlot.jl in Julia, right?  The way you
>> wrote the code above doesn't actually run in Julia ("base" is "Base" and
>> "plt" is "PyPlot"--did you alias those?), and I want to make sure that
>> you're not doing something like, e.g., using Python and loading pyjulia.
>>
>
> Actually, the Julia `PyPlot` package automatically provides an alias `plt`
> for closer compatibility with how `matplotlib` is typically used in Python.
>
> David.
>
>
>>
>> Anyway, assuming that's true...
>>
>> It's unfortunate that the help is overwritten (might be worth opening an
>> issue in PyPlot.jl), but in fact, the version in Base is still working just
>> fine.  In fact, I don't see a way to call the version in PyPlot without
>> using "PyPlot.hist":
>>
>> julia> using PyPlot
>> Warning: Method definition eltype(Any,) in module Base at
>> abstractarray.jl:10 overwritten in module Compat at
>> /Users/kevin/.julia/v0.3/Compat/src/Compat.jl:163.
>> INFO: Loading help data...
>>
>> julia> hist
>> hist (generic function with 6 methods)
>>
>> julia> hist(rand(1:10, 100))#calls the Base version
>> (0.0:2.0:10.0,[18,14,21,18,29])
>>
>> julia> @which hist(rand(1:10, 100))
>> hist(v::AbstractArray{T,1}) at statistics.jl:599
>>
>> julia> @which PyPlot.hist(rand(1:10, 100))
>> hist(args...) at /Users/kevin/.julia/v0.3/PyPlot/src/PyPlot.jl:367
>>
>> Cheers,
>>Kevin
>>
>>
>> On Wed, Feb 18, 2015 at 10:47 AM,  wrote:
>>
>>> Hi,
>>>
>>> Once I've loaded pyplot, I can't figure out how to use the base.hist
>>> function. What is the workaround?
>>>
>>> help(base.hist) returns the plt.hist functionality.
>>>
>>
>>

Re: [julia-users] Re: Convert Array{Float64,1} to Type{Float64}

[Christian Dengler]

Ty guys, works fine now. The dot function is exactly what i was looking 
for. 

Am Dienstag, 17. Februar 2015 21:57:14 UTC+1 schrieb Tim Holy:
>
> or dot(v,v) or sumabs2(v) 
>
> --Tim 
>
> On Tuesday, February 17, 2015 12:42:34 PM Simon Danisch wrote: 
> > julia> v*v' 
> > 1x1 Array{Int64,2}: 
> >  14 
> > This is an array, while w[1] is a Float64. 
> > So you need to do something like first(v*v') 
> > or (v*v')[1] 
> > 
> > Am Dienstag, 17. Februar 2015 21:04:04 UTC+1 schrieb Christian Dengler: 
> > > Hello, 
> > > 
> > > I recently discovered Julia, and tried to convert some of my code. I 
> ran 
> > > into a problem, changing values in a sparse matrix. The entries i want 
> to 
> > > put in the sparse matrix result from a dot product. The error message 
> is 
> > > "ERROR: `convert` has no method matching convert(::Type{Float64}, 
> > > 
> > > ::Array{Float64,1})" The problem can be reproduces with the following 
> > > ::lines 
> > > 
> > > of code. 
> > > 
> > > v = [1 2 3] 
> > > w = spzeros(1, 1) 
> > > w[1] = v*v' 
> > > 
> > > Does anyone know how to solve this? 
> > > 
> > > Thanks, 
> > > Christian 
> > > 
> > > PS: I'm using Julia version 0.3.5 on Linux 
>
>

[julia-users] difference in Travis tests?

[Seth]

I noticed recently that two travis tests (each against 0.3 and nightly, so 
a total of 4 builds?) are occurring for each PR. In many cases one fails 
while the other succeeds.

What's the difference between the two (sets of) tests, and when/why did 
this change happen?

Thanks!

Re: [julia-users] Ccall argument tuple error

[Jameson Nash]

I'm not sure what you are expecting this to do. You can't fwrite to a Julia
stream object, nor does that appear to be the C signature of fwrite. You
seem to have a lowercase void there, which is causing the Julia error,
although I suspect you will get a segfault if that typo wasn't there.

However, instead, call the Julia "write" function, and let dispatch do the
right thing.
On Thu, Feb 19, 2015 at 2:13 PM Kuba Roth  wrote:

> Hi there,
> Can somebody give me a hand debugging the following ccall please?
> I have run out of ideas how to provide arguments. None of below work and
> give:
> ERROR: error interpreting ccall argument tuple
>  in anonymous at no file
>
> a = Uint8[]
> append!(a,[1,2,3])
> z = open("myfile", "w")
> ccall( (:fwrite, "libc"), Int32, (Ptr{Void}, Int32, Int32, Ptr{void},), a,
> 1, 3, z)
> ccall( (:fwrite, "libc"), Int32, (Ptr{Void}, Int32, Int32, Ptr{void},), a,
> 1, 3, z.ios)
>
>
> Also I'm not sure if I need to pass IOStream or Array (z.ios) to the ccall
>
> Much appreciate your suggestions.
> Thank you,
> Kuba

[julia-users] Ccall argument tuple error

[Kuba Roth]

Hi there,
Can somebody give me a hand debugging the following ccall please? 
I have run out of ideas how to provide arguments. None of below work and give: 
ERROR: error interpreting ccall argument tuple
 in anonymous at no file

a = Uint8[]
append!(a,[1,2,3])
z = open("myfile", "w")
ccall( (:fwrite, "libc"), Int32, (Ptr{Void}, Int32, Int32, Ptr{void},), a, 1, 
3, z)
ccall( (:fwrite, "libc"), Int32, (Ptr{Void}, Int32, Int32, Ptr{void},), a, 1, 
3, z.ios)


Also I'm not sure if I need to pass IOStream or Array (z.ios) to the ccall

Much appreciate your suggestions. 
Thank you,
Kuba

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

[Patrick O'Leary]

For what it's worth, I did see Oscar make a comment on an issue this 
morning which confirms that his clock is off.

On Thursday, February 19, 2015 at 12:53:31 AM UTC-6, Ivar Nesje wrote:
>
> 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] How to prevent SQL injection in Julia?

[Jacob Quinn]

Those are great questions/ideas. I've been meaning to implement prepared
statements for a while now, so I should probably just hunker down and do it
as it's not that difficult. Having an escape function of sorts would be
interesting as well. Feel free to open an issue on the repo and we can push
things forward.

https://github.com/quinnj/ODBC.jl/issues

-Jacob

On Thu, Feb 19, 2015 at 11:39 AM, Philip Tellis 
wrote:

> I'm using the ODBC package to connect to a database and make a few SQL
> queries.  For some of these queries, the table name or values in the WHERE
> clause come from variables, and I need a way to safely quote them for use
> in an SQL string.
>
> Is there a standard method in Julia to do this?
>
> For values in the WHERE clause, prepared statements would be useful, but I
> couldn't find a way to do this with ODBC.
>
> For table names, a simple sql escape function would help (one that was
> database character set aware).  Something similar to PHP's
> mysqli_real_escape_string:
> http://php.net/manual/en/mysqli.real-escape-string.php
>
> Does Julia have either of these methods?
>
> Thanks,
>
> Philip
>

[julia-users] getting into a clean state (Errors on Gtk and Winston)

[Andreas Lobinger]

Hello colleagues,

Gtk 0.8.0 seems to be seriously broken - at least on my box. I try to 
checkout v0.7.10. Then Winston is in this missing-Graphics-package stage.
Can someone please share the steps needed to get Gtk back to displaying 
windows again (and not segfaulting when closing) AND Winston to work with 
it again.
I thought i could manage this, but i'm lost in versioning hell.

Thank you in advance.

Wishing a happy day,
Andreas

[julia-users] How to prevent SQL injection in Julia?

[Philip Tellis]

I'm using the ODBC package to connect to a database and make a few SQL 
queries.  For some of these queries, the table name or values in the WHERE 
clause come from variables, and I need a way to safely quote them for use 
in an SQL string.

Is there a standard method in Julia to do this?

For values in the WHERE clause, prepared statements would be useful, but I 
couldn't find a way to do this with ODBC.

For table names, a simple sql escape function would help (one that was 
database character set aware).  Something similar to PHP's 
mysqli_real_escape_string: 
http://php.net/manual/en/mysqli.real-escape-string.php

Does Julia have either of these methods?

Thanks,

Philip

Re: [julia-users] using both plt.hist and base.hist

[David P. Sanders]

El miércoles, 18 de febrero de 2015, 15:58:13 (UTC-6), Kevin Squire 
escribió:
>
> Hi Sam,
>
> Just to be clear, you're using PyPlot.jl in Julia, right?  The way you 
> wrote the code above doesn't actually run in Julia ("base" is "Base" and 
> "plt" is "PyPlot"--did you alias those?), and I want to make sure that 
> you're not doing something like, e.g., using Python and loading pyjulia.
>

Actually, the Julia `PyPlot` package automatically provides an alias `plt` 
for closer compatibility with how `matplotlib` is typically used in Python.

David.
 

>
> Anyway, assuming that's true...
>
> It's unfortunate that the help is overwritten (might be worth opening an 
> issue in PyPlot.jl), but in fact, the version in Base is still working just 
> fine.  In fact, I don't see a way to call the version in PyPlot without 
> using "PyPlot.hist":
>
> julia> using PyPlot
> Warning: Method definition eltype(Any,) in module Base at 
> abstractarray.jl:10 overwritten in module Compat at 
> /Users/kevin/.julia/v0.3/Compat/src/Compat.jl:163.
> INFO: Loading help data...
>
> julia> hist
> hist (generic function with 6 methods)
>
> julia> hist(rand(1:10, 100))#calls the Base version
> (0.0:2.0:10.0,[18,14,21,18,29])
>
> julia> @which hist(rand(1:10, 100))
> hist(v::AbstractArray{T,1}) at statistics.jl:599
>
> julia> @which PyPlot.hist(rand(1:10, 100))
> hist(args...) at /Users/kevin/.julia/v0.3/PyPlot/src/PyPlot.jl:367
>
> Cheers,
>Kevin
>
>
> On Wed, Feb 18, 2015 at 10:47 AM, > 
> wrote:
>
>> Hi,
>>
>> Once I've loaded pyplot, I can't figure out how to use the base.hist 
>> function. What is the workaround?
>>
>> help(base.hist) returns the plt.hist functionality.
>>
>
>

Re: [julia-users] Most effective way to build a large string?

[David P. Sanders]

El martes, 17 de febrero de 2015, 10:47:08 (UTC-6), Stefan Karpinski 
escribió:
>
> IOBuffer is what you're looking for:
>
> buf = IOBuffer()
> for i = 1:100
> println(buf, i)
> end
> takebuf_string(buf) # => returns everything that's been written to buf.
>
> The takebuf_string function really needs a new name.
>

Could that function just be called `string`?
The current behaviour of string applied to an IOBuffer does not seem useful:

julia> i = IOBuffer()
IOBuffer(data=Uint8[...], readable=true, writable=true, seekable=true, 
append=false, size=0, maxsize=Inf, ptr=1, mark=-1)

julia> string(i)
"IOBuffer(data=Uint8[...], readable=true, writable=true, seekable=true, 
append=false, size=0, maxsize=Inf, ptr=1, mark=-1)"
 

>
> On Tue, Feb 17, 2015 at 9:06 AM, Maurice Diamantini <
> maurice.d...@gmail.com > wrote:
>
>> Hi,
>>
>> In Ruby, String is mutable which allows to build large strings like this:
>> txt = ""
>> for ...
>> txt << "yet another line\n"
>> end
>> # do something with txt
>>
>> The Julia the (bad) way I use is to do:
>> txt = ""
>> for ...
>> txt *=  "yet another line\n"
>> end
>> # do something with txt
>>
>> Which is very slow for a big string (because it build a new more and more 
>> string at each iteration).
>>
>> So is there another way to do it (in standard Julia)?
>> Or is there another type which could be used (something like a Buffer 
>> type or Array type)?
>>
>> Thank,
>> -- Maurice
>>
>
>

Re: [julia-users] Re: anyway to get immutable constants?

[Stefan Karpinski]

There's an ImmutableArrays package as well:

https://github.com/twadleigh/ImmutableArrays.jl

The key is that immutability is a property of a type, not a binding, so
immutable arrays are an entirely different type of object than mutable ones.

On Thu, Feb 19, 2015 at 12:02 PM, Petr Krysl  wrote:

> Could not functions be used for this purpose?
>
> Let us say you wish to get a constant array: How about you call a function
> that will give you that array by CONSTRUCTING it on the fly. Since the
> logic of the function is immutable, you get a constant array.
>
> P
>
>
> On Wednesday, February 18, 2015 at 4:37:08 PM UTC-8, Zouhair Mahboubi
> wrote:
>>
>> I think I read somewhere in the docs that constants in Julia can be
>> modified, but only as long as the type is kept the same.
>>
>> This is not ideal, but at least there’s a warning message about it.
>> Except that if the type is an array, and one modifies an entry in it, or
>> modifies a reference to this const, there is no warning…
>>
>> const z = [0,0]
>> z = [1, 1]; #produces warning
>> z[1] = 2; #does not produce warning
>> y = z;
>> y[1] = 3; #does not produce warning
>>
>> this has caused me some pain as having code like this can lead to
>> confusing behavior:
>>
>>
>> const z0 = [0,0]
>> function foo(x)
>> y = z0
>> if x != 0
>>   y[1] = x
>> end
>> return y
>> end
>> foo(0) #returns [0,0]
>> foo(1) #returns [1,0]
>> foo(0) #returns [1,0]
>>
>> And of course at no point do I get a warning that z0 was changed…
>>
>> I guess my question is how do I get around this? do I have to do a
>> copy(z0)? or is there a way to enforce immutability of constants?
>>
>> Thanks,
>> -z
>> ​
>>
>

[julia-users] Re: [ERROR: syntax: invalid assignment location] When trying to overload the `Base.==` method.

[Ismael VC]

Thank you Sean.

El jueves, 19 de febrero de 2015, 9:36:58 (UTC-6), Ismael VC escribió:
>
> Is this a parsing bug? I wanted to use `Base.==` to make it more explicit, 
> as I've seen it's good style. This happens in both v0.3.5 and v0.4-dev
>
> julia> type Foo end
>
> julia> import Base.==
>
> julia> Base.==(x::Foo, y::Foo) = true
> ERROR: syntax: invalid assignment location
>
> julia> Base.(==)(x::Foo, y::Foo) = true
> ERROR: syntax: invalid method name "Base.(==)"
>
> julia> ==(x::Foo, y::Foo) = true
> == (generic function with 80 methods)
>
>
>

Re: [julia-users] Julia on Raspberry Pi 2

[Seth]

Make sure that the symlink chain is unbroken. In mine:

seth@redshift ~/dev/julia/julia $ ls -l /usr/lib/libgfortran.so.3
lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3

seth@redshift ~/dev/julia/julia $ ls -l 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3
lrwxrwxrwx 1 root root 20 Sep  6 05:52 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3 -> libgfortran.so.3.0.0

seth@redshift ~/dev/julia/julia $ ls -l 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
-rw-r--r-- 1 root root 655444 Sep  6 06:28 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0

On Thursday, February 19, 2015 at 9:24:14 AM UTC-8, Sto Forest wrote:
>
> Thanks for the hint Seth, I've added the symlink but still get the error ..
>
> /usr/bin/ld: cannot find -lgfortran
>
>
>
>
> On Thursday, 19 February 2015 17:13:41 UTC, Seth wrote:
>>
>> Also, the fact that you don't have /usr/lib/libgfortran.so.3 is probably 
>> causing the issue. Try creating a symlink:
>>
>> lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>>
>>
>>
>> On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote:
>>>
>>> Different than what I have:
>>>
>>> /usr/share/doc/libgfortran3
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
>>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>>> /usr/lib/libgfortran.so.3
>>> /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
>>> /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
>>> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
>>> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
>>> /var/lib/dpkg/info/libgfortran3:armhf.postrm
>>> /var/lib/dpkg/info/libgfortran3:armhf.postinst
>>> /var/lib/dpkg/info/libgfortran3:armhf.symbols
>>> /var/lib/dpkg/info/libgfortran3:armhf.list
>>>
>>> This is on raspbian:
>>>
>>> Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 
>>> armv7l GNU/Linux
>>> seth@redshift ~/dev/julia/julia $ cat /etc/issue
>>> Raspbian GNU/Linux 7 \n \l
>>>
>>>
>>>
>>> On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:

 libgfortran-4.8 does seem to be  installed ( I don't think there is a 
 version 4.7 in the package list )


 Here is the result of a find for libgforrtan ...

 root@pithree:/opt/julia# find / -name "*libgfortran*"
 /usr/share/doc/libgfortran3
 /usr/share/doc/libgfortran-4.8-dev
 /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
 /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
 /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
 /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
 /opt/julia/contrib/fixup-libgfortran.sh
 /var/lib/dpkg/info/libgfortran3:armhf.md5sums
 /var/lib/dpkg/info/libgfortran3:armhf.shlibs
 /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
 /var/lib/dpkg/info/libgfortran3:armhf.postrm
 /var/lib/dpkg/info/libgfortran3:armhf.postinst
 /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
 /var/lib/dpkg/info/libgfortran3:armhf.symbols
 /var/lib/dpkg/info/libgfortran3:armhf.list
 /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb



 On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:
>
> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or 
> something similar. It is odd that it wouldn’t find libgfortran - perhaps 
> it 
> is a path issue. 
>
> -viral 
>
>
>
> > On 19-Feb-2015, at 5:45 pm, Sto Forest  
> wrote: 
> > 
> > Latest hurdle seems to be the absence of  lgfortran 
> > 
> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > /usr/bin/ld: cannot find -lgfortran 
> > collect2: error: ld returned 1 exit status 
> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
> failed 
> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
> > Makefile:87: rec

Re: [julia-users] Julia on Raspberry Pi 2

[Sto Forest]

Thanks for the hint Seth, I've added the symlink but still get the error ..

/usr/bin/ld: cannot find -lgfortran




On Thursday, 19 February 2015 17:13:41 UTC, Seth wrote:
>
> Also, the fact that you don't have /usr/lib/libgfortran.so.3 is probably 
> causing the issue. Try creating a symlink:
>
> lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>
>
>
> On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote:
>>
>> Different than what I have:
>>
>> /usr/share/doc/libgfortran3
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>> /usr/lib/libgfortran.so.3
>> /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
>> /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
>> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
>> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
>> /var/lib/dpkg/info/libgfortran3:armhf.postrm
>> /var/lib/dpkg/info/libgfortran3:armhf.postinst
>> /var/lib/dpkg/info/libgfortran3:armhf.symbols
>> /var/lib/dpkg/info/libgfortran3:armhf.list
>>
>> This is on raspbian:
>>
>> Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 
>> armv7l GNU/Linux
>> seth@redshift ~/dev/julia/julia $ cat /etc/issue
>> Raspbian GNU/Linux 7 \n \l
>>
>>
>>
>> On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:
>>>
>>> libgfortran-4.8 does seem to be  installed ( I don't think there is a 
>>> version 4.7 in the package list )
>>>
>>>
>>> Here is the result of a find for libgforrtan ...
>>>
>>> root@pithree:/opt/julia# find / -name "*libgfortran*"
>>> /usr/share/doc/libgfortran3
>>> /usr/share/doc/libgfortran-4.8-dev
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
>>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
>>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>>> /opt/julia/contrib/fixup-libgfortran.sh
>>> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
>>> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
>>> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
>>> /var/lib/dpkg/info/libgfortran3:armhf.postrm
>>> /var/lib/dpkg/info/libgfortran3:armhf.postinst
>>> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
>>> /var/lib/dpkg/info/libgfortran3:armhf.symbols
>>> /var/lib/dpkg/info/libgfortran3:armhf.list
>>> /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb
>>>
>>>
>>>
>>> On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:

 Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
 similar. It is odd that it wouldn’t find libgfortran - perhaps it is a 
 path 
 issue. 

 -viral 



 > On 19-Feb-2015, at 5:45 pm, Sto Forest  
 wrote: 
 > 
 > Latest hurdle seems to be the absence of  lgfortran 
 > 
 > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
 [-Wunused-variable] 
 > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
 > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
 [-Wunused-variable] 
 > /usr/bin/ld: cannot find -lgfortran 
 > collect2: error: ld returned 1 exit status 
 > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
 failed 
 > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
 > Makefile:87: recipe for target 'shared' failed 
 > make[2]: *** [shared] Error 2 
 > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
 Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
 libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
 errors building SandyBridge support. Both these options can also be used 
 simultaneously. *** 
 > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' 
 failed 
 > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 
 > Makefile:64: recipe for target 'julia-deps' failed 
 > make: *** [julia-deps] Error 2 
 > 
 > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: 
 > Is there a way to get Julia running on the new Raspberry Pi 2, 
 

Re: [julia-users] Julia on Raspberry Pi 2

[Seth]

Also, the fact that you don't have /usr/lib/libgfortran.so.3 is probably 
causing the issue. Try creating a symlink:

lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> 
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3



On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote:
>
> Different than what I have:
>
> /usr/share/doc/libgfortran3
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> /usr/lib/libgfortran.so.3
> /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
> /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
> /var/lib/dpkg/info/libgfortran3:armhf.postrm
> /var/lib/dpkg/info/libgfortran3:armhf.postinst
> /var/lib/dpkg/info/libgfortran3:armhf.symbols
> /var/lib/dpkg/info/libgfortran3:armhf.list
>
> This is on raspbian:
>
> Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 
> armv7l GNU/Linux
> seth@redshift ~/dev/julia/julia $ cat /etc/issue
> Raspbian GNU/Linux 7 \n \l
>
>
>
> On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:
>>
>> libgfortran-4.8 does seem to be  installed ( I don't think there is a 
>> version 4.7 in the package list )
>>
>>
>> Here is the result of a find for libgforrtan ...
>>
>> root@pithree:/opt/julia# find / -name "*libgfortran*"
>> /usr/share/doc/libgfortran3
>> /usr/share/doc/libgfortran-4.8-dev
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
>> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
>> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
>> /opt/julia/contrib/fixup-libgfortran.sh
>> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
>> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
>> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
>> /var/lib/dpkg/info/libgfortran3:armhf.postrm
>> /var/lib/dpkg/info/libgfortran3:armhf.postinst
>> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
>> /var/lib/dpkg/info/libgfortran3:armhf.symbols
>> /var/lib/dpkg/info/libgfortran3:armhf.list
>> /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb
>>
>>
>>
>> On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:
>>>
>>> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
>>> similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path 
>>> issue. 
>>>
>>> -viral 
>>>
>>>
>>>
>>> > On 19-Feb-2015, at 5:45 pm, Sto Forest  wrote: 
>>> > 
>>> > Latest hurdle seems to be the absence of  lgfortran 
>>> > 
>>> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
>>> [-Wunused-variable] 
>>> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
>>> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
>>> [-Wunused-variable] 
>>> > /usr/bin/ld: cannot find -lgfortran 
>>> > collect2: error: ld returned 1 exit status 
>>> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
>>> failed 
>>> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
>>> > Makefile:87: recipe for target 'shared' failed 
>>> > make[2]: *** [shared] Error 2 
>>> > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
>>> Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
>>> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
>>> errors building SandyBridge support. Both these options can also be used 
>>> simultaneously. *** 
>>> > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' 
>>> failed 
>>> > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 
>>> > Makefile:64: recipe for target 'julia-deps' failed 
>>> > make: *** [julia-deps] Error 2 
>>> > 
>>> > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: 
>>> > Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
>>> under raspbian ? 
>>> > 
>>> > 
>>>
>>>

Re: [julia-users] Julia on Raspberry Pi 2

[Seth]

Different than what I have:

/usr/share/doc/libgfortran3
/usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a
/usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a
/usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec
/usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3
/usr/lib/libgfortran.so.3
/home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh
/home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh
/var/lib/dpkg/info/libgfortran3:armhf.md5sums
/var/lib/dpkg/info/libgfortran3:armhf.shlibs
/var/lib/dpkg/info/libgfortran3:armhf.postrm
/var/lib/dpkg/info/libgfortran3:armhf.postinst
/var/lib/dpkg/info/libgfortran3:armhf.symbols
/var/lib/dpkg/info/libgfortran3:armhf.list

This is on raspbian:

Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 
armv7l GNU/Linux
seth@redshift ~/dev/julia/julia $ cat /etc/issue
Raspbian GNU/Linux 7 \n \l



On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote:
>
> libgfortran-4.8 does seem to be  installed ( I don't think there is a 
> version 4.7 in the package list )
>
>
> Here is the result of a find for libgforrtan ...
>
> root@pithree:/opt/julia# find / -name "*libgfortran*"
> /usr/share/doc/libgfortran3
> /usr/share/doc/libgfortran-4.8-dev
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3
> /opt/julia/contrib/fixup-libgfortran.sh
> /var/lib/dpkg/info/libgfortran3:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.shlibs
> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
> /var/lib/dpkg/info/libgfortran3:armhf.postrm
> /var/lib/dpkg/info/libgfortran3:armhf.postinst
> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
> /var/lib/dpkg/info/libgfortran3:armhf.symbols
> /var/lib/dpkg/info/libgfortran3:armhf.list
> /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb
>
>
>
> On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:
>>
>> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
>> similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path 
>> issue. 
>>
>> -viral 
>>
>>
>>
>> > On 19-Feb-2015, at 5:45 pm, Sto Forest  wrote: 
>> > 
>> > Latest hurdle seems to be the absence of  lgfortran 
>> > 
>> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
>> [-Wunused-variable] 
>> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
>> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
>> [-Wunused-variable] 
>> > /usr/bin/ld: cannot find -lgfortran 
>> > collect2: error: ld returned 1 exit status 
>> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
>> failed 
>> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
>> > Makefile:87: recipe for target 'shared' failed 
>> > make[2]: *** [shared] Error 2 
>> > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
>> Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
>> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
>> errors building SandyBridge support. Both these options can also be used 
>> simultaneously. *** 
>> > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' 
>> failed 
>> > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 
>> > Makefile:64: recipe for target 'julia-deps' failed 
>> > make: *** [julia-deps] Error 2 
>> > 
>> > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: 
>> > Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
>> under raspbian ? 
>> > 
>> > 
>>
>>

Re: [julia-users] Why does my Julia code run so slow?

[Tim Holy]

In addition to the suggestions from the nice people who are taking the time to 
respond to your question, see also 
http://docs.julialang.org/en/release-0.3/manual/performance-tips/

--Tim

On Thursday, February 19, 2015 06:51:20 AM Zhixuan Yang wrote:
> Hello everyone,
> 
> Recently I'm working on my first Julia project, a word embedding training
> program similar to Google's word2vec 
> (the code of word2vec is indeed very high-quality, but I want to add more
> features, so I decided to write a new one). Thanks to Julia's
> expressiveness, it cost me less than 2 days to write the entire program.
> But it runs really slow, about 100x slower than the C code of word2vec (the
> algorithm is the same). I've been trying to optimize my code for several
> days (adding type annotations, using BLAS to do computation, eliminating
> memory allocations ...), but it is still 30x slower than the C code.
> 
> The critical part of my program is the following function (it also consumes
> most of the time according to the profiling result):
> 
> function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: Int64;
> α :: Float64 = 0.025, input_gradient :: Union(Nothing, Array{Float64}) =
> nothing)
> predict!(c, x)
> c.outputs[y] -= 1
> 
> if input_gradient != nothing
> # input_gradient = ( c.weights * outputs' )'
> BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
> end
> 
> # c.weights -= α * x' * outputs;
> BLAS.ger!(-α, vec(x), c.outputs, c.weights)
> end
> 
> function predict!(c :: LinearClassifier, x :: Array{Float64})
> c.outputs = vec(softmax(x * c.weights))
> end
> 
> type LinearClassifier
> k :: Int64 # number of outputs
> n :: Int64 # number of inputs
> weights :: Array{Float64, 2} # k * n weight matrix
> 
> outputs :: Vector{Float64}
> end
> 
> And the entire program can be found here
> . Could you please check my code and
> tell me what I can do to get performance comparable to C.
> 
> Regards.
> Yang Zhixuan

[julia-users] Re: anyway to get immutable constants?

[Petr Krysl]

Could not functions be used for this purpose?

Let us say you wish to get a constant array: How about you call a function 
that will give you that array by CONSTRUCTING it on the fly. Since the 
logic of the function is immutable, you get a constant array.

P

On Wednesday, February 18, 2015 at 4:37:08 PM UTC-8, Zouhair Mahboubi wrote:
>
> I think I read somewhere in the docs that constants in Julia can be 
> modified, but only as long as the type is kept the same.
>
> This is not ideal, but at least there’s a warning message about it. Except 
> that if the type is an array, and one modifies an entry in it, or modifies 
> a reference to this const, there is no warning…
>
> const z = [0,0]
> z = [1, 1]; #produces warning
> z[1] = 2; #does not produce warning
> y = z;
> y[1] = 3; #does not produce warning
>
> this has caused me some pain as having code like this can lead to 
> confusing behavior:
>
>
> const z0 = [0,0]
> function foo(x)
> y = z0
> if x != 0
>   y[1] = x
> end
> return y
> end
> foo(0) #returns [0,0]
> foo(1) #returns [1,0]
> foo(0) #returns [1,0]
>
> And of course at no point do I get a warning that z0 was changed…
>
> I guess my question is how do I get around this? do I have to do a 
> copy(z0)? or is there a way to enforce immutability of constants?
>
> Thanks,
> -z
> ​
>

[julia-users] Re: [ERROR: syntax: invalid assignment location] When trying to overload the `Base.==` method.

[Sean Marshallsay]

I'm not sure whether it's considered a bug or not but it's definitely known 
about. You can do it like this if you want:

julia> Base.(:(==))
== (generic function with 79 methods)



On Thursday, 19 February 2015 15:36:58 UTC, Ismael VC wrote:
>
> Is this a parsing bug? I wanted to use `Base.==` to make it more explicit, 
> as I've seen it's good style. This happens in both v0.3.5 and v0.4-dev
>
> julia> type Foo end
>
> julia> import Base.==
>
> julia> Base.==(x::Foo, y::Foo) = true
> ERROR: syntax: invalid assignment location
>
> julia> Base.(==)(x::Foo, y::Foo) = true
> ERROR: syntax: invalid method name "Base.(==)"
>
> julia> ==(x::Foo, y::Foo) = true
> == (generic function with 80 methods)
>
>
>

Re: [julia-users] Julia on Raspberry Pi 2

[Sto Forest]

libgfortran-4.8 does seem to be  installed ( I don't think there is a 
version 4.7 in the package list )


Here is the result of a find for libgforrtan ...

root@pithree:/opt/julia# find / -name "*libgfortran*"
/usr/share/doc/libgfortran3
/usr/share/doc/libgfortran-4.8-dev
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec
/usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0
/usr/lib/arm-linux-gnueabihf/libgfortran.so.3
/opt/julia/contrib/fixup-libgfortran.sh
/var/lib/dpkg/info/libgfortran3:armhf.md5sums
/var/lib/dpkg/info/libgfortran3:armhf.shlibs
/var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums
/var/lib/dpkg/info/libgfortran3:armhf.postrm
/var/lib/dpkg/info/libgfortran3:armhf.postinst
/var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list
/var/lib/dpkg/info/libgfortran3:armhf.symbols
/var/lib/dpkg/info/libgfortran3:armhf.list
/var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb



On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote:
>
> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
> similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path 
> issue. 
>
> -viral 
>
>
>
> > On 19-Feb-2015, at 5:45 pm, Sto Forest  > wrote: 
> > 
> > Latest hurdle seems to be the absence of  lgfortran 
> > 
> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > /usr/bin/ld: cannot find -lgfortran 
> > collect2: error: ld returned 1 exit status 
> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
> failed 
> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
> > Makefile:87: recipe for target 'shared' failed 
> > make[2]: *** [shared] Error 2 
> > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild 
> with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
> errors building SandyBridge support. Both these options can also be used 
> simultaneously. *** 
> > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' failed 
> > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 
> > Makefile:64: recipe for target 'julia-deps' failed 
> > make: *** [julia-deps] Error 2 
> > 
> > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: 
> > Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
> under raspbian ? 
> > 
> > 
>
>

[julia-users] Re: Why does my Julia code run so slow?

[Sean Marshallsay]

The two things that jump out at me straight away are keyword arguments and 
nullable fields. Changing those keyword arguments into optional positional 
arguments might give you a bit of a boost.

The thing that will really make a difference though (I expect) is 
`input_gradient::Union(Nothing,Array{Float64})`, that will be a massive 
performance killer and you should probably use an empty array instead (i.e. 
`input_gradient::Array{Float64}=Float64[]`). If that's not possible 
consider splitting the function into two methods, one that has an 
input_gradient argument and one that doesn't, then you can do your nothing 
checking outside the function.

On Thursday, 19 February 2015 14:51:20 UTC, Zhixuan Yang wrote:
>
> Hello everyone, 
>
> Recently I'm working on my first Julia project, a word embedding training 
> program similar to Google's word2vec  
> (the code 
> of word2vec is indeed very high-quality, but I want to add more features, 
> so I decided to write a new one). Thanks to Julia's expressiveness, it cost 
> me less than 2 days to write the entire program. But it runs really slow, 
> about 100x slower than the C code of word2vec (the algorithm is the same). 
>  I've been trying to optimize my code for several days (adding type 
> annotations, using BLAS to do computation, eliminating memory allocations 
> ...), but it is still 30x slower than the C code. 
>
> The critical part of my program is the following function (it also 
> consumes most of the time according to the profiling result):
>
> function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: Int64; 
> α :: Float64 = 0.025, input_gradient :: Union(Nothing, Array{Float64}) = 
> nothing)
> predict!(c, x)
> c.outputs[y] -= 1
>
> if input_gradient != nothing
> # input_gradient = ( c.weights * outputs' )'
> BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
> end
>
> # c.weights -= α * x' * outputs;
> BLAS.ger!(-α, vec(x), c.outputs, c.weights)
> end
>
> function predict!(c :: LinearClassifier, x :: Array{Float64})
> c.outputs = vec(softmax(x * c.weights))
> end
>
> type LinearClassifier
> k :: Int64 # number of outputs
> n :: Int64 # number of inputs
> weights :: Array{Float64, 2} # k * n weight matrix
>
> outputs :: Vector{Float64}
> end
>
> And the entire program can be found here 
> . Could you please check my code 
> and tell me what I can do to get performance comparable to C. 
>
> Regards.
> Yang Zhixuan
>

Re: [julia-users] Why does my Julia code run so slow?

[Mauro]

Without having looked at your code too closely:

Keyword arguments don't work that well.  If I recall correctly, their
type cannot be used inside the function body.  How is performance if you
don't use the keywords?  (although they should not be impacting
performance if not used in a particular call)

Presumably you read:
http://docs.julialang.org/en/latest/manual/performance-tips/

On Thu, 2015-02-19 at 15:51, Zhixuan Yang  wrote:
> Hello everyone, 
>
> Recently I'm working on my first Julia project, a word embedding training 
> program similar to Google's word2vec  
> (the code 
> of word2vec is indeed very high-quality, but I want to add more features, 
> so I decided to write a new one). Thanks to Julia's expressiveness, it cost 
> me less than 2 days to write the entire program. But it runs really slow, 
> about 100x slower than the C code of word2vec (the algorithm is the same). 
>  I've been trying to optimize my code for several days (adding type 
> annotations, using BLAS to do computation, eliminating memory allocations 
> ...), but it is still 30x slower than the C code. 
>
> The critical part of my program is the following function (it also consumes 
> most of the time according to the profiling result):
>
> function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: Int64; 
> α :: Float64 = 0.025, input_gradient :: Union(Nothing, Array{Float64}) = 
> nothing)
> predict!(c, x)
> c.outputs[y] -= 1
>
> if input_gradient != nothing
> # input_gradient = ( c.weights * outputs' )'
> BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
> end
>
> # c.weights -= α * x' * outputs;
> BLAS.ger!(-α, vec(x), c.outputs, c.weights)
> end
>
> function predict!(c :: LinearClassifier, x :: Array{Float64})
> c.outputs = vec(softmax(x * c.weights))
> end
>
> type LinearClassifier
> k :: Int64 # number of outputs
> n :: Int64 # number of inputs
> weights :: Array{Float64, 2} # k * n weight matrix
>
> outputs :: Vector{Float64}
> end
>
> And the entire program can be found here 
> . Could you please check my code and 
> tell me what I can do to get performance comparable to C. 
>
> Regards.
> Yang Zhixuan

Re: [julia-users] Julia on Raspberry Pi 2

[Seth]

This seemed to get past all the dependencies for me:

sudo apt-get install libblas3gf liblapack3gf libfftw3-dev libgmp3-dev 
libmpfr-dev libblas-dev liblapack-dev gfortran cmake gcc-4.7  g++-4.7 
libgfortran3


On Thursday, February 19, 2015 at 6:42:14 AM UTC-8, Viral Shah wrote:
>
> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
> similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path 
> issue. 
>
> -viral 
>
>
>
> > On 19-Feb-2015, at 5:45 pm, Sto Forest  > wrote: 
> > 
> > Latest hurdle seems to be the absence of  lgfortran 
> > 
> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: 
> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
> [-Wunused-variable] 
> > /usr/bin/ld: cannot find -lgfortran 
> > collect2: error: ld returned 1 exit status 
> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' 
> failed 
> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 
> > Makefile:87: recipe for target 'shared' failed 
> > make[2]: *** [shared] Error 2 
> > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild 
> with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
> errors building SandyBridge support. Both these options can also be used 
> simultaneously. *** 
> > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' failed 
> > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 
> > Makefile:64: recipe for target 'julia-deps' failed 
> > make: *** [julia-deps] Error 2 
> > 
> > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: 
> > Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
> under raspbian ? 
> > 
> > 
>
>

[julia-users] [ERROR: syntax: invalid assignment location] When trying to overload the `Base.==` method.

[Ismael VC]

Is this a parsing bug? I wanted to use `Base.==` to make it more explicit, 
as I've seen it's good style. This happens in both v0.3.5 and v0.4-dev

julia> type Foo end

julia> import Base.==

julia> Base.==(x::Foo, y::Foo) = true
ERROR: syntax: invalid assignment location

julia> Base.(==)(x::Foo, y::Foo) = true
ERROR: syntax: invalid method name "Base.(==)"

julia> ==(x::Foo, y::Foo) = true
== (generic function with 80 methods)

Re: [julia-users] quick type-stability question about using similar()

[Roy Wang]

Thanks for your explanation, Milan!

On Thursday, 19 February 2015 10:29:10 UTC-5, Milan Bouchet-Valat wrote:
>
> Le jeudi 19 février 2015 à 07:10 -0800, Roy Wang a écrit : 
> > I'd appreciate it if someone can help me out with two questions: 
> > 
> > I think this function is not a type-stable function. This is because 
> > the type of out depends on the input A. If it is type-stable, why? 
> No, it *is* type stable, precisely because the type of the output 
> depends only on the *type* of the input (or at least it seems it works 
> that way, but without more code it's hard to tell). Type-instability is 
> when the type of the output depends on the *value* of the input. 
>
> > function myfunc(A) 
> > out=similar(A) 
> > 
> > #performs some computation that is then stored in out 
> > return out 
> > 
> > end 
> > 
> > 
> > 
> > I think this function is a type-stable function. If it isn't, why? 
> > function myfunc!(out,A) 
> > 
> > #performs some computation that mutates out 
> > return nothing 
> > 
> > end 
> > 
> > 
> > If my conclusions are correct, would you say it is better programming 
> > practice to use the second function as much as possible? 
> The second function is also type stable (AFAICT). The difference is that 
> it does not create a copy of the input, i.e. it works in place. This can 
> be better programming practice as it allocates less memory. The 
> convention in Julia is to provide both myfunc!() and a convenience 
> wrapper caller myfunc() which calls myfunc!(similar(A)). 
>
>
> Regards 
>

Re: [julia-users] Publishing a package

[Sergey Bartunov]

четверг, 19 февраля 2015 г., 17:57:30 UTC+3 пользователь Spencer Russell 
написал:
>
> I went through a bit of this in earlier AudioIO versions where I had a C 
> shim around PortAudio. I think this commit 
> 
>  should 
> be a decent one to see how I was doing it. Eventually I ended up 
> pre-compiling and shipping binaries, before finally ditching the C code and 
> writing it in pure Julia.
>  
> That said, are you sure you need the C code? It definitely makes 
> distribution more of a pain, and slows down the install process. I also 
> discovered there are a lot of Julia users who don't have a C toolchain 
> installed, so none of them will be able to use your package.
>

Unfortunately, yes. I couldn't achieve comparable performance with pure 
julia code and so managed to rewrite performance-critical pieces in C.

Maybe I could write some fallback code in julia that will be used if C code 
could not be compiled.
 

>  
>  
> On Thu, Feb 19, 2015, at 09:46 AM, Sergey Bartunov wrote:
>
> I'm going to release a new julia package which contains some C code. I 
> would like to compile that code during installation and to specify somehow 
> that this package is UNIX-only as it uses SharedArrays. What is the best 
> way to implement this?
>  
> This package implements a machine learning algorithm and the learning 
> process is quite sophisticated, so I also would like to include some julia 
> and shell scripts which simplify usage of the package but are not 100% 
> required. So would it be a good practice to put these scripts in a separate 
> directory?
>  
>  
>  

Re: [julia-users] quick type-stability question about using similar()

[Milan Bouchet-Valat]

Le jeudi 19 février 2015 à 07:10 -0800, Roy Wang a écrit :
> I'd appreciate it if someone can help me out with two questions:
> 
> I think this function is not a type-stable function. This is because
> the type of out depends on the input A. If it is type-stable, why?
No, it *is* type stable, precisely because the type of the output
depends only on the *type* of the input (or at least it seems it works
that way, but without more code it's hard to tell). Type-instability is
when the type of the output depends on the *value* of the input.

> function myfunc(A)
> out=similar(A)
> 
> #performs some computation that is then stored in out
> return out
> 
> end
> 
> 
> 
> I think this function is a type-stable function. If it isn't, why?
> function myfunc!(out,A)
> 
> #performs some computation that mutates out
> return nothing
> 
> end
> 
> 
> If my conclusions are correct, would you say it is better programming
> practice to use the second function as much as possible?
The second function is also type stable (AFAICT). The difference is that
it does not create a copy of the input, i.e. it works in place. This can
be better programming practice as it allocates less memory. The
convention in Julia is to provide both myfunc!() and a convenience
wrapper caller myfunc() which calls myfunc!(similar(A)).


Regards

[julia-users] quick type-stability question about using similar()

[Roy Wang]

I'd appreciate it if someone can help me out with two questions:

I think this function is not a type-stable function. This is because the 
type of out depends on the input A. If it is type-stable, why?
function myfunc(A)
out=similar(A)

#performs some computation that is then stored in out
return out
end


I think this function is a type-stable function. If it isn't, why?
function myfunc!(out,A)

#performs some computation that mutates out
return nothing
end

If my conclusions are correct, would you say it is better programming 
practice to use the second function as much as possible?

Re: [julia-users] Type matching in Julia version 0.4.0-dev+3434

[Stefan Karpinski]

The NEWS.md file 
is a good place to look for changes:

https://github.com/JuliaLang/julia/blob/master/NEWS.md#language-changes

The new behavior of [ ] is the first item under language changes

with links to the relevant issues and pull requests.

The type matching change may well be a bug fix since Array{Any,1} and
Array{Array,1} are incomparable types (i.e. neither is a subtype of the
other, nor are they the equivalent). I'd have to see this spelled out a bit
more to know what change you're referring to.



On Thu, Feb 19, 2015 at 5:49 AM, Robert DJ  wrote:

> Hi,
>
> I have just updated Julia for the first time in 10 days and now I face
> problems with old code:
>
> - The error "WARNING: [a] concatenation is deprecated; use [a;] instead".
> Easy to fix, but what is the reasoning behind adding the ";"?
>
> - Type matching has changed: I have a function that takes arguments of the
> type `Array{Array{T,N},1}` (output from `typeof`; in words, it is an array
> where each element is an Array{Any,1} with multiple Array{Float,2}).
> As type specification in the function, `Array{Any,1}` used to work, but
> not anymore.
> Specifying the type as `Array{Array{T,N},1}` with N being an appropriate
> number doesn't work either.
> Is there a solution to this?
>
> Thanks,
>
> Robert
>
>

Re: [julia-users] Re: Julia on Raspberry Pi 2

[Isaiah Norton]

No, "Cortex-blah" is the model family, but the architecture is still
ARMv7-A for both.

http://en.wikipedia.org/wiki/ARM_Cortex-A7
http://en.wikipedia.org/wiki/ARM_Cortex-A15

(ARM nomenclature can admittedly be quite bewildering)

On Thu, Feb 19, 2015 at 9:47 AM, Viral Shah  wrote:

> It also appears that the Raspberry Pi 2 has a Cortex A7 processor -
> whereas in ARM.inc, we are building LLVM for cortex A9. Perhaps that may
> need to be changed and llvm probably needs to be recompiled.
>
> -viral
>
>
> On Wednesday, February 18, 2015 at 9:00:07 PM UTC+5:30, Seth wrote:
>>
>>
>>
>> On Saturday, February 14, 2015 at 12:11:04 PM UTC-8, Sto Forest wrote:
>>>
>>> Is there a way to get Julia running on the new Raspberry Pi 2, perhaps
>>> under raspbian ?
>>>
>>>
>>>
>>
>> So close! It ended here with an error:
>>
>> sort.jl
>> combinatorics.jl
>> version.jl
>> error during bootstrap:
>> LoadError(at "sysimg.jl" line 170: LoadError(at "version.jl" line 102:
>> BoundsError(a=Array{Union, 1}[], i=(1,
>>
>> Makefile:162: recipe for target 
>> '/home/seth/dev/julia/julia/usr/lib/julia/sys0.o'
>> failed
>> make[1]: *** [/home/seth/dev/julia/julia/usr/lib/julia/sys0.o] Error 1
>> Makefile:76: recipe for target 'julia-sysimg-release' failed
>> make: *** [julia-sysimg-release] Error 2
>>
>>
>>
>

Re: [julia-users] Publishing a package

[Spencer Russell]

I went through a bit of this in earlier AudioIO versions where I had a
C shim around PortAudio. I think this commit[1] should be a decent one
to see how I was doing it. Eventually I ended up pre-compiling and
shipping binaries, before finally ditching the C code and writing it in
pure Julia.

That said, are you sure you need the C code? It definitely makes
distribution more of a pain, and slows down the install process. I also
discovered there are a lot of Julia users who don't have a C toolchain
installed, so none of them will be able to use your package.


On Thu, Feb 19, 2015, at 09:46 AM, Sergey Bartunov wrote:
> I'm going to release a new julia package which contains some C code. I
> would like to compile that code during installation and to specify
> somehow that this package is UNIX-only as it uses SharedArrays. What
> is the best way to implement this?
>
> This package implements a machine learning algorithm and the learning
> process is quite sophisticated, so I also would like to include some
> julia and shell scripts which simplify usage of the package but are
> not 100% required. So would it be a good practice to put these scripts
> in a separate directory?



Links:

  1. 
https://github.com/ssfrr/AudioIO.jl/tree/9d9af6e4cd01caf518de90cd97ab32f209ec5615

[julia-users] Why does my Julia code run so slow?

[Zhixuan Yang]

Hello everyone, 

Recently I'm working on my first Julia project, a word embedding training 
program similar to Google's word2vec  (the 
code 
of word2vec is indeed very high-quality, but I want to add more features, 
so I decided to write a new one). Thanks to Julia's expressiveness, it cost 
me less than 2 days to write the entire program. But it runs really slow, 
about 100x slower than the C code of word2vec (the algorithm is the same). 
 I've been trying to optimize my code for several days (adding type 
annotations, using BLAS to do computation, eliminating memory allocations 
...), but it is still 30x slower than the C code. 

The critical part of my program is the following function (it also consumes 
most of the time according to the profiling result):

function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: Int64; 
α :: Float64 = 0.025, input_gradient :: Union(Nothing, Array{Float64}) = 
nothing)
predict!(c, x)
c.outputs[y] -= 1

if input_gradient != nothing
# input_gradient = ( c.weights * outputs' )'
BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
end

# c.weights -= α * x' * outputs;
BLAS.ger!(-α, vec(x), c.outputs, c.weights)
end

function predict!(c :: LinearClassifier, x :: Array{Float64})
c.outputs = vec(softmax(x * c.weights))
end

type LinearClassifier
k :: Int64 # number of outputs
n :: Int64 # number of inputs
weights :: Array{Float64, 2} # k * n weight matrix

outputs :: Vector{Float64}
end

And the entire program can be found here 
. Could you please check my code and 
tell me what I can do to get performance comparable to C. 

Regards.
Yang Zhixuan

[julia-users] Re: Julia on Raspberry Pi 2

[Viral Shah]

It also appears that the Raspberry Pi 2 has a Cortex A7 processor - whereas 
in ARM.inc, we are building LLVM for cortex A9. Perhaps that may need to be 
changed and llvm probably needs to be recompiled.

-viral

On Wednesday, February 18, 2015 at 9:00:07 PM UTC+5:30, Seth wrote:
>
>
>
> On Saturday, February 14, 2015 at 12:11:04 PM UTC-8, Sto Forest wrote:
>>
>> Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
>> under raspbian ? 
>>
>>
>>
>
> So close! It ended here with an error:
>
> sort.jl
> combinatorics.jl
> version.jl
> error during bootstrap:
> LoadError(at "sysimg.jl" line 170: LoadError(at "version.jl" line 102: 
> BoundsError(a=Array{Union, 1}[], i=(1,
>
> Makefile:162: recipe for target 
> '/home/seth/dev/julia/julia/usr/lib/julia/sys0.o' failed
> make[1]: *** [/home/seth/dev/julia/julia/usr/lib/julia/sys0.o] Error 1
> Makefile:76: recipe for target 'julia-sysimg-release' failed
> make: *** [julia-sysimg-release] Error 2
>
>  
>

Re: [julia-users] Functions

[Isaiah Norton]

>
> Maybe you could use value types (
> http://julia.readthedocs.org/en/latest/manual/types/#value-types ),
> however, you need to use the latest nighly builds for that. Eg


Something very similar to the first example actually works in 0.3:

immutable Problem{S} end
> f(::Type{Problem{1}}, x) = x^2
> f(::Type{Problem{2}}, x) = sin(x)

> f(Problem{1}, 1)
>
1

> f(Problem{2}, 1)

0.8414709848078965


On Thu, Feb 19, 2015 at 4:24 AM, Tamas Papp  wrote:

> Hi,
>
> Maybe you could use value types (
> http://julia.readthedocs.org/en/latest/manual/types/#value-types ),
> however, you need to use the latest nighly builds for that. Eg
>
> func(::Type{Val{1}}, x) = x^2
> func(::Type{Val{2}}, x) = sin(x)
>
> func(Val{1},1)  # => 1
> func(Val{2},1)  # => sin(1)
>
> If you want to stick with 3.6 for now, you could create types for the
> cases.
>
> type Case1 end
> func(::Type{Case1}, x) = x^2
> type Case2 end
> func(::Type{Case2}, x) = sin(x)
>
> func(Case1, 1)  # => 1
> func(Case2, 1)  # => sin(1)
>
> Best,
>
> Tamas
>
> On Thu, Feb 19 2015, Devendra Ghate  wrote:
>
> > Hello everyone,
> >
> > Consider following function:
> >
> > ~~~
> > function funca(problem, x)
> >if problem == 1
> >   return  x^2;
> >elseif
> >problem == 2
> > return sin(x);
> > end
> > end
> > ~~~
> >
> > I have shown only 2 cases. However, there are around 100 cases. These
> > `if ... else` statements are being evaluated unnecessarily. If I use
> > `switch` structure then it will be faster. But I want to do away with
> > these.
> >
> > Since the arguments and their datatypes remain the same, I don't know
> > how to create multiple methods for function.
> >
> > What is the best strategy to achieve this?
> >
> > Background:
> >
> > I am trying to implement a library of ODE solvers for my students.
> >
> > $y`` + a(x)y` + b(x) = f(x) $
> >
> > Above function calculates $a(x)$ for a given problem at a specific $x_0$.
> >
> > So there should various ODE problems defined via the coefficients of
> > the derivative terms. My students will then implement various solution
> > strategies and compare their performance for these problems. So I need
> > to provide
> > them with functions `funca` `funcb` `funcf` which give the appropriate
> > coefficient depending on the problem.
>
>

[julia-users] Publishing a package

[Sergey Bartunov]

I'm going to release a new julia package which contains some C code. I
would like to compile that code during installation and to specify somehow
that this package is UNIX-only as it uses SharedArrays. What is the best
way to implement this?

This package implements a machine learning algorithm and the learning
process is quite sophisticated, so I also would like to include some julia
and shell scripts which simplify usage of the package but are not 100%
required. So would it be a good practice to put these scripts in a separate
directory?

Re: [julia-users] Julia on Raspberry Pi 2

[Viral Shah]

Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something 
similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path 
issue.

-viral



> On 19-Feb-2015, at 5:45 pm, Sto Forest  wrote:
> 
> Latest hurdle seems to be the absence of  lgfortran 
> 
> lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ [-Wunused-variable]
> lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’:
> lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ [-Wunused-variable]
> /usr/bin/ld: cannot find -lgfortran
> collect2: error: ld returned 1 exit status
> Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' failed
> make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1
> Makefile:87: recipe for target 'shared' failed
> make[2]: *** [shared] Error 2
> *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild with 
> 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking libpthread.so, 
> and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were errors building 
> SandyBridge support. Both these options can also be used simultaneously. ***
> Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' failed
> make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1
> Makefile:64: recipe for target 'julia-deps' failed
> make: *** [julia-deps] Error 2
> 
> On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote:
> Is there a way to get Julia running on the new Raspberry Pi 2, perhaps under 
> raspbian ? 
> 
> 

Re: [julia-users] cannot resize array with shared data

[Kevin Squire]

Hi Andrew,

A very similar issue came up in
https://github.com/JuliaLang/julia/issues/4592, which was addressed by

https://github.com/JuliaLang/julia/commit/2570b4a60e5ab5c438c57ed9a3eafa5c881bc39a

If you look at the fix, you'll see that the error in your code comes from
array_try_unshare or jl_array_grow_end.  In either case, unsharing/resizing
doesn't work for arrays sharing data with "how == 3", which means that the
data being resized is actually just a pointer to the original data (defined
here 
).

In your case, what is happening is that a string is created ("hello world"),
and the variable a simply gets a pointer to the underlying string data (the
b_str macro does just that
), so
it's sharing data (with a string that isn't referenced anymore), and
therefore can't be resized.

At a minimum, it would be great to have this information somewhere in the
docs.  A more informative error might also be useful.  Would you mind
opening up an issue (and/or if you're so motivated, a pull request)?

Cheers,

   Kevin



On Thu, Feb 19, 2015 at 2:39 AM, andrew cooke  wrote:

> Hi,
>
> I'm trying to understand the bug report at
> https://github.com/andrewcooke/CRC.jl/issues/4 which has
>
> julia> using CRC
>
> julia> crc32c = crc(CRC_32_C)
> handler (generic function with 3 methods)
>
> julia> a = b"hello world";
>
> julia> crc32c(a)
> 0xc99465aa
>
> julia> resize!(a, 5)
> ERROR: cannot resize array with shared data
>  in resize! at ./array.jl:545
>
> but I can find no docs on what "shared data" for arrays means.  All I have
> found is the C code at
> https://github.com/JuliaLang/julia/blob/master/src/array.c which, tbh, is
> a little opaque (what is a->how? how can i reset a->shared?)
>
> It sounds like the array code is doing something like reference counting
> and refusing to be mutable when there are references?  How do I decrement
> the count?
>
> Is there any documentation on sharing of arrays?
>
> My guess is that a caller could work round this by making a copy, but that
> seems inefficient.  Especially since my code simply iterates through the
> data and then "no longer cares".
>
> Sorry, this email is very vague.  Given the lack of docs (nothing about
> sharing in the manual i can see) I wonder if I've stumbled over some
> internal detail that should not be exposed to users?
>
> Any help appreciated,
> Andrew
>

Re: [julia-users] Functions

[Jameson Nash]

Are you sure that it is actually meaningfully slower? llvm might infer a
switch statement from the common structure, but even if not, you are
talking about a very small number of extra assembly instruction, relative
to say, computing sin(x)
On Thu, Feb 19, 2015 at 4:02 AM Devendra Ghate 
wrote:

> Hello everyone,
>
> Consider following function:
>
> ~~~
> function funca(problem, x)
>if problem == 1
>   return  x^2;
>elseif
>problem == 2
> return sin(x);
> end
> end
> ~~~
>
> I have shown only 2 cases. However, there are around 100 cases. These
> `if ... else` statements are being evaluated unnecessarily. If I use
> `switch` structure then it will be faster. But I want to do away with
> these.
>
> Since the arguments and their datatypes remain the same, I don't know
> how to create multiple methods for function.
>
> What is the best strategy to achieve this?
>
> Background:
>
> I am trying to implement a library of ODE solvers for my students.
>
> $y`` + a(x)y` + b(x) = f(x) $
>
> Above function calculates $a(x)$ for a given problem at a specific $x_0$.
>
> So there should various ODE problems defined via the coefficients of
> the derivative terms. My students will then implement various solution
> strategies and compare their performance for these problems. So I need
> to provide
> them with functions `funca` `funcb` `funcf` which give the appropriate
> coefficient depending on the problem.
>
> --
> Cheers,
> Devendra
>

Re: [julia-users] Working around current limitations of functions as variables and anonymous functions

[Tim Holy]

On 0.4 there are some pretty good solutions to this problem, but nothing has 
yet been "wrapped up" into something very convenient. (There are a few 
nontrivial issues left to figure out, since it involves automatic generation of 
types.)

I don't have time to find it for you right now, but you can search for old 
posts here (or perhaps julia-dev) on stagedfunctions and call overloading. 
(Mauro was involved in that thread.) Also see 
https://github.com/JuliaOpt/Optim.jl/issues/102#issuecomment-74658825

--Tim


On Wednesday, February 18, 2015 09:25:11 PM colintbow...@gmail.com wrote:
> Hi all,
> 
> Using Julia v0.3.x, there appears to be a significant performance hit when
> using functions as variables or using anonymous functions. I asked a
> StackOverflow question about it here
>  
> to-optimize-when-a-function-is-passed-a-function>, and, as I understand it,
> the problem is that the compiler is currently unable to determine the type
> of the output of a function when that function is itself a variable or an
> anonymous function - consequently, a big performance hit. I run into this
> issue on an (almost) daily basis, so I was wondering what the best
> work-around is at this point. Thus far, there are three solutions I'm aware
> of:
> 
> 1) Suffer the slower performance: If the function-as-variable/anonymous
> function is itself a fairly big function, then the slow-down associated
> with the unknown output type is not such a big deal when overall run-time
> is taken into consideration. However, frequently the function in question
> is simple, and so this option is not really tenable in these cases.
> 
> 2) Use Tim Holy's very cool FastAnonymous
>  package: For the case of
> anonymous functions, this package speeds things up quite a bit. However, my
> understanding is that it is still a bit of a work-around. Moreover, there
> are some cases in my code where there was still a fairly significant
> performance hit relative to the in-lined case (if anyone wants more detail
> on this I'm happy to provide it)
> 
> 3) Write in-line code: This results in the best possible speed, but there
> ends up being quite a lot of code duplication in my function. For example,
> my code might look something like this:
> if method == "Method1"
> for n = 1:N
> y[n] = Method1Function(x1[n], x2[n])
> end
> elseif method == "Method2"
> for n = 1:N
> y[n] = Method2Function(x1[n], x2[n])
> end
> elseif etc
>   .
>   .
>   .
> end
> Most of the time the loops are more complicated than just simply iterating
> from 1:N, so the code gets really long and is mostly duplication. Moreover,
> if you want to allow for an arbitrarily large class of functions to be
> applied within the loop, this solution is not tenable.
> 
> I understand the core development team is currently aiming to deal with
> this by v1.0, although there was some noise here
>   about trying to get
> things working by the v0.4 stable release. In the meantime, I'm interested
> in the best work-around that other members of this user-group have come up
> with.
> 
> Cheers,
> 
> Colin

[julia-users] Re: Julia on Raspberry Pi 2

[Sto Forest]

Latest hurdle seems to be the absence of  lgfortran 

lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ 
[-Wunused-variable]
lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’:
lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ 
[-Wunused-variable]
/usr/bin/ld: cannot find -lgfortran
collect2: error: ld returned 1 exit status
Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' failed
make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1
Makefile:87: recipe for target 'shared' failed
make[2]: *** [shared] Error 2
*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild 
with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking 
libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
errors building SandyBridge support. Both these options can also be used 
simultaneously. ***
Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' failed
make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1
Makefile:64: recipe for target 'julia-deps' failed
make: *** [julia-deps] Error 2

On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote:
>
> Is there a way to get Julia running on the new Raspberry Pi 2, perhaps 
> under raspbian ? 
>
>
>

Re: [julia-users] Is there a way to "parallel broadcast" a function?

[René Donner]

You could try the table functions from 
https://github.com/rened/FunctionalData.jl

julia> Pkg.update(); Pkg.add("FunctionalData")

julia> ptable((x,y)->x+y, 1:2, 1:3)
2x3 Array{Int64,2}:
2  3  4
3  4  5

table does not parallelize, ptable uses all workers, and ltable uses only the 
local workers.

In case your results cannot be stored in a dense numerical array, use ptableany 
instead.

I just added this - if it does not work for your case please file an issue.



Am 19.02.2015 um 01:40 schrieb DumpsterDoofus :

> I sometimes generate arrays using array comprehension syntax like this:
> 
> array = [func(a,k) for a in 0.0:0.01:1.0, k in 0.0:0.01:1.0];
> 
> or alternately using `broadcast` like this:
> 
> array = broadcast(func, linspace(0,1,101)', linspace(0,1,101))
> 
> This is the Julia equivalent to the following Mathematica code:
> 
> array = Outer[func, Range[0,1,0.01], Range[0,1,0.01]];
> 
> To parallelize in Mathematica, you typically wrap the expression in 
> `Parallelize`:
> 
> array = Parallelize[Outer[func, Range[0,1,0.01], Range[0,1,0.01]]];
> 
> Is there a simple way to "parallel broadcast" or "parallel array 
> comprehension" in Julia yet? I know I could manually chop the workload into 
> chunks, and then feed them to available worker processes using `@spawnat`, 
> and then fuse the results together into one large array, but I was wondering 
> if there was a non-kludgy way to automatically distribute array comprehension 
> syntax.

[julia-users] Type matching in Julia version 0.4.0-dev+3434

[Robert DJ]

Hi,

I have just updated Julia for the first time in 10 days and now I face 
problems with old code:

- The error "WARNING: [a] concatenation is deprecated; use [a;] instead". 
Easy to fix, but what is the reasoning behind adding the ";"?

- Type matching has changed: I have a function that takes arguments of the 
type `Array{Array{T,N},1}` (output from `typeof`; in words, it is an array 
where each element is an Array{Any,1} with multiple Array{Float,2}). 
As type specification in the function, `Array{Any,1}` used to work, but not 
anymore. 
Specifying the type as `Array{Array{T,N},1}` with N being an appropriate 
number doesn't work either. 
Is there a solution to this?

Thanks,

Robert

[julia-users] cannot resize array with shared data

[andrew cooke]

Hi,

I'm trying to understand the bug report at 
https://github.com/andrewcooke/CRC.jl/issues/4 which has

julia> using CRC

julia> crc32c = crc(CRC_32_C)
handler (generic function with 3 methods)

julia> a = b"hello world";

julia> crc32c(a)
0xc99465aa

julia> resize!(a, 5)
ERROR: cannot resize array with shared data
 in resize! at ./array.jl:545

but I can find no docs on what "shared data" for arrays means.  All I have 
found is the C code at 
https://github.com/JuliaLang/julia/blob/master/src/array.c which, tbh, is a 
little opaque (what is a->how? how can i reset a->shared?)

It sounds like the array code is doing something like reference counting 
and refusing to be mutable when there are references?  How do I decrement 
the count?

Is there any documentation on sharing of arrays?

My guess is that a caller could work round this by making a copy, but that 
seems inefficient.  Especially since my code simply iterates through the 
data and then "no longer cares".

Sorry, this email is very vague.  Given the lack of docs (nothing about 
sharing in the manual i can see) I wonder if I've stumbled over some 
internal detail that should not be exposed to users?

Any help appreciated,
Andrew

Re: [julia-users] Functions

[Tamas Papp]

Hi,

Maybe you could use value types (
http://julia.readthedocs.org/en/latest/manual/types/#value-types ),
however, you need to use the latest nighly builds for that. Eg

func(::Type{Val{1}}, x) = x^2
func(::Type{Val{2}}, x) = sin(x)

func(Val{1},1)  # => 1
func(Val{2},1)  # => sin(1)

If you want to stick with 3.6 for now, you could create types for the
cases.

type Case1 end
func(::Type{Case1}, x) = x^2
type Case2 end
func(::Type{Case2}, x) = sin(x)

func(Case1, 1)  # => 1
func(Case2, 1)  # => sin(1)

Best,

Tamas

On Thu, Feb 19 2015, Devendra Ghate  wrote:

> Hello everyone,
>
> Consider following function:
>
> ~~~
> function funca(problem, x)
>if problem == 1
>   return  x^2;
>elseif
>problem == 2
> return sin(x);
> end
> end
> ~~~
>
> I have shown only 2 cases. However, there are around 100 cases. These
> `if ... else` statements are being evaluated unnecessarily. If I use
> `switch` structure then it will be faster. But I want to do away with
> these.
>
> Since the arguments and their datatypes remain the same, I don't know
> how to create multiple methods for function.
>
> What is the best strategy to achieve this?
>
> Background:
>
> I am trying to implement a library of ODE solvers for my students.
>
> $y`` + a(x)y` + b(x) = f(x) $
>
> Above function calculates $a(x)$ for a given problem at a specific $x_0$.
>
> So there should various ODE problems defined via the coefficients of
> the derivative terms. My students will then implement various solution
> strategies and compare their performance for these problems. So I need
> to provide
> them with functions `funca` `funcb` `funcf` which give the appropriate
> coefficient depending on the problem.

[julia-users] Functions

[Devendra Ghate]

Hello everyone,

Consider following function:

~~~
function funca(problem, x)
   if problem == 1
  return  x^2;
   elseif
   problem == 2
return sin(x);
end
end
~~~

I have shown only 2 cases. However, there are around 100 cases. These
`if ... else` statements are being evaluated unnecessarily. If I use
`switch` structure then it will be faster. But I want to do away with
these.

Since the arguments and their datatypes remain the same, I don't know
how to create multiple methods for function.

What is the best strategy to achieve this?

Background:

I am trying to implement a library of ODE solvers for my students.

$y`` + a(x)y` + b(x) = f(x) $

Above function calculates $a(x)$ for a given problem at a specific $x_0$.

So there should various ODE problems defined via the coefficients of
the derivative terms. My students will then implement various solution
strategies and compare their performance for these problems. So I need
to provide
them with functions `funca` `funcb` `funcf` which give the appropriate
coefficient depending on the problem.

-- 
Cheers,
Devendra