[julia-users] Re: redefining Base method for `show`

[Jeffrey Sarnoff]

module Rationality

abstract SymbolicMathematics

export SymbolicRational

import Base: STDOUT, string, show, Rational

type SymbolicRational <: SymbolicMathematics
num::Int128
den::Int128

SymbolicRational{I<:Signed}(num::I, den::I) = new(Int128(num), 
Int128(den))
SymbolicRational{I<:Signed}(q::Rational{I}) = SymbolicRational(q.num, 
q.den)
end

function string(x::SymbolicRational)
return string(x.num, "/", x.den)
end

function string{I}(x::Rational{I})
return string(x.num, "//", x.den)
end

function show(io::IO, x::SymbolicRational)
s = string(x)
print(io, s)
end
show(x::SymbolicRational) = show(STDOUT, x)

function show{I}(io::IO, x::Rational{I})
s = string(x)
print(io, s)
end
show{I}(x::Rational{I}) = show(STDOUT, x)

end # module Rationality


using Rationality

p = 3//5

q = SymbolicRational(p)

pstr = string(p);

qstr = string(q);

p_q = string(pstr, "   ", qstr)

println(p_q)

show([p, q])








On Friday, October 14, 2016 at 9:52:51 AM UTC-4, lapeyre@gmail.com 
wrote:
>
> I'm thinking of symbolic mathematics (Symata.jl). Another example is 
> `SymPy.jl`, which prints rationals the same way I want to, like this: 
> "2/3". But in SymPy.jl, rationals are not `Rational`'s, but rather wrapped 
> python objects, so the problem with printing does not arise. If I wrapped 
> `Rational`'s it would introduce a lot of complexity.
>
> So far, walking expression trees to wrap objects of certain types just 
> before printing seems to be working well.
>
> On Friday, October 14, 2016 at 4:23:27 AM UTC+2, Jeffrey Sarnoff wrote:
>>
>> I assume you meant x::T in type A{T}.  Why do you want to do this:
>>
>>> Every time a Rational or Symbol or Bool is encountered on any level, I 
>>> want it to print differently than Base.show does it.
>>>
>> Do you want to adorn it (like "3//5" -> "{3//5}") or alter it (like 
>> "3//5" -> "2//5")?
>>
>> Also, I think you are approaching solving your problem in way more suited 
>> to another language.  But I really have no idea what your motivation is.
>>
>> On Tuesday, October 11, 2016 at 7:21:35 PM UTC-4, lapeyre@gmail.com 
>> wrote:
>>>
>>> To make it concrete, I have
>>>
>>> type A{T}
>>>x
>>>a::Array{Any,1}
>>> end
>>>
>>> The elements of the array a are numbers, Symbols, strings, etc., as well 
>>> as more instances of type A{T}.  They
>>> may be nested to arbitrary depth. If I call show on an instance of A{T}, 
>>> then show will be called recursively
>>> on all parts of the tree. Every time a Rational or Symbol or Bool is 
>>> encountered on any level, I want it to print differently than Base.show 
>>> does it.
>>>
>>>
>>> On Tuesday, October 11, 2016 at 11:48:46 PM UTC+2, Jeffrey Sarnoff wrote:

 Are you saying  a and b and c and d?

 (a) that you have a outer type which has a Rational field and has 
 another field of a type that has a field which is typed Rational or is 
 typed e.g. Vector{Rational}   

 (b) and displaying a value of the outer type includes displaying the 
 Rationals from withiin the field of the inner type

 (c) and when displaying that value, you want to present the outer 
 type's Rational field a special way

 (d) and when displaying that value, you want to present the Rational 
 fields of the inner type in the usual way


 On Tuesday, October 11, 2016 at 1:23:37 PM UTC-4, lapeyre@gmail.com 
 wrote:
>
> I think I understand what you are saying (not sure).  A problem that 
> arises is that if I call show or print on an object, then show or print 
> may 
> be called many times on fields and fields of fields, etc., including from 
> within Base code before the call returns. I don't know how to tell the 
> builtin julia code my preference for printing rationals. The only way I 
> know to get a redefinition of show eg M.show to work in all situations, 
> is 
> to copy all the code that might be called. Maybe I'm missing something, 
> but 
> I can't see a way around this.
>
> I'm not familiar with the idea of a fencing module.
>
> On Monday, October 10, 2016 at 11:30:18 PM UTC+2, Jeffrey Sarnoff 
> wrote:
>>
>> You could wrap your redefinitions in a module M without exporting 
>> show explicitly.   
>> `using M`  and accessing the your variation as `M.show` may give the 
>> localization you want.
>> Should it not, then doing that within some outer working context, a 
>> fencing module, may add enough flexibility.
>>
>>
>> On Monday, October 10, 2016 at 4:18:52 PM UTC-4, 
>> lapeyre@gmail.com wrote:
>>>
>>> For the record, a workable solution, at least for this particular 
>>> code: I pass all output through wrapout() at the outermost output call. 
>>> The 
>>> object to be printed is traversed recursively. All types fall through 
>>> except for the handful that I want to 

[julia-users] Failed to precompile LightGraphs

[varun7rs]

I recently installed the LightGraphs package for my work but when I enter 
"using LightGraphs", I get an error saying failed to precompile LightGraphs 
to /home/user/.julia/lib/v0.5/LightGraphs.jl. Can you please tell me what 
the error is about and how to get  LightGraphs working again?

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Bart Janssens]

In addition to this, CxxWrap.jl has some additional convenience classes to
work with Julia arrays from C++, see
https://github.com/JuliaInterop/CxxWrap.jl#working-with-arrays

Cheers,

Bart

On Sat, Oct 15, 2016 at 2:45 AM Isaiah Norton 
wrote:

> On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick  wrote:
>
>
> After determining that an array was returned, how would you determine what
> the inner type of the array is (i.e. the type of the objects it contains)?
>
>
> `jl_array_eltype`
>
>
>
> And furthermore, if it returns an array of type "Any", would there be any
> way to tell what the type is of any arbitrary element in that array?
>
>
> `jl_typeof`, after retrieving the element (which will be boxed)
>
>
>
> Thanks!
>
>
>

[julia-users] Type-stable global variables?

[Andrei Zh]

What is the most straightforward way to make a variable in the global scope 
that can change it's value, but not its type? So far I use this: 

const GLOBAL_VAR = [MyType[]]  # array with single element

set_global_var(x::MyType) = GLOBAL_VAR[1] = x
get_goval_var() = GLOBAL_VAR[1]

This works fine and preserves type stability, but looks quite unintuitive. 
Is there more standard container or another way (e.g. type assertions or 
something) to handle such cases? 

[julia-users] quadgk with 2 arguments

[digxx]

having a function of the form f(s,t) defined is it possible to somehow tell 
quadgk to not evaluate until I supply a value for s while t should be the 
integration variable?
e.g. sth like. The syntax I found so far excluded any arguments...
g=s-> quadgk(f(s,*),0,1)

[julia-users] Re: quadgk with 2 arguments

[Daniel O'Malley]

I think what you want is

g(s) = quadgk(t->f(s,t), 0, 1)

On Saturday, October 15, 2016 at 6:37:58 PM UTC-6, digxx wrote:
>
> having a function of the form f(s,t) defined is it possible to somehow 
> tell quadgk to not evaluate until I supply a value for s while t should be 
> the integration variable?
> e.g. sth like. The syntax I found so far excluded any arguments...
> g=s-> quadgk(f(s,*),0,1)
>

[julia-users] Re: quadgk with 2 arguments

[Kristoffer Carlsson]

Perhaps this is what you mean:

s = 1.0
quadgk(t -> f(s,t),0,1)



On Sunday, October 16, 2016 at 2:37:58 AM UTC+2, digxx wrote:
>
> having a function of the form f(s,t) defined is it possible to somehow 
> tell quadgk to not evaluate until I supply a value for s while t should be 
> the integration variable?
> e.g. sth like. The syntax I found so far excluded any arguments...
> g=s-> quadgk(f(s,*),0,1)
>

Re: [julia-users] Reductions sometimes not typestable?

[Yichao Yu]

On Sat, Oct 15, 2016 at 6:21 PM, jw3126  wrote:

>
>
> On Sunday, October 16, 2016 at 12:12:14 AM UTC+2, Yichao Yu wrote:
>>
>>
>>
>> 2016-10-15 18:06 GMT-04:00 jw3126 :
>>
>>> myop(::Int16, ::Int16) = Int32(1)
>>> myop(::Int16, ::Int32) = Int64(1)
>>> myop(::Int16, ::Int64) = Int128(1)
>>> myop(::Int16, ::Int128) = Int128(1)
>>>
>>> foldr(myop, Int16[1]) |> typeof |> println
>>> foldr(myop, Int16[1,1]) |> typeof |> println
>>> foldr(myop, Int16[1,1,1]) |> typeof |> println
>>> foldr(myop, Int16[1,1,1,1]) |> typeof |> println
>>>
>>>
>>> gives
>>>
>>>
>>> Int32
>>> Int64
>>> Int128
>>> Int128
>>>
>>> Would it be better if the answer was typestable (always Int128)? See
>>> also here .
>>>
>>
>> Yes it would be better if you implement your operation that way and no
>> the compiler cannot do this.
>>
>
> One could change the promotion in foldr to use something like the
> following:
>
> accumulate_eltype(op, T) = accumulate_eltype(op, T, T)
>

The `promote_op` business is messed up enough. I don't think we need yet
another promotion system to make it harder to write code in most cases.


>
> function accumulate_eltype(op, T, S)
> S_next = promote_op(op, T, S)
> if S == S_next
> return S
> else
> return accumulate_eltype(op, T, S_next)
> end
> end
>
>>
>>
>>

[julia-users] Re: quadgk with 2 arguments

[digxx]

Btw: Can quadgk also be used for complex functions? (the integration is 
still over a real range)

[julia-users] Root finding package

[digxx]

So I know there is Roots but is there also one for finding complex roots?

[julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?

[colintbowers]

Hi all,

Twice now I've thought I had overloaded the appropriate functions for a new 
type, only to observe apparent inconsistencies in the way the new type 
behaves. Of course, there were no inconsistencies. Instead, the observed 
behaviour stemmed from overloading a function that is not at the bottom of 
the function chain. The two examples where I stuffed up were:

1) overloading Base.< instead of overloading Base.isless, and

2) overloading Base.string(x) instead of overloading Base.show(io, x).

My question is this: What is the communities best solution/resource for 
knowing which functions are at the bottom of the chain and thus are the 
ones that need to be overloaded for a new type?

Cheers and thanks in advance to all repsonders,

Colin

[julia-users] Interpolations.jl: how to use the scale function?

[Florian Oswald]

Hi folks,

I have question on SO that needs some attention. thanks!

http://stackoverflow.com/questions/40045208/how-to-use-scale-in-interpolations-jl

[julia-users] Nemo AcbField error

[digxx]

Maybe I'm doing sth wrong or sth has changed since 0.4 but I get an error 
using an AcbField

r=AcbField(64)
res=r(1)

ERROR: LoadError: error compiling AcbField: error compiling Type: could not 
load library "libarb"
▒
 in include_from_node1(::String) at .\loading.jl:488

Re: [julia-users] Reductions sometimes not typestable?

[Yichao Yu]

2016-10-15 18:06 GMT-04:00 jw3126 :

> myop(::Int16, ::Int16) = Int32(1)
> myop(::Int16, ::Int32) = Int64(1)
> myop(::Int16, ::Int64) = Int128(1)
> myop(::Int16, ::Int128) = Int128(1)
>
> foldr(myop, Int16[1]) |> typeof |> println
> foldr(myop, Int16[1,1]) |> typeof |> println
> foldr(myop, Int16[1,1,1]) |> typeof |> println
> foldr(myop, Int16[1,1,1,1]) |> typeof |> println
>
>
> gives
>
>
> Int32
> Int64
> Int128
> Int128
>
> Would it be better if the answer was typestable (always Int128)? See also
> here .
>

Yes it would be better if you implement your operation that way and no the
compiler cannot do this.

[julia-users] Re: Interpolations.jl: how to use the scale function?

[Kristoffer Carlsson]

itp2 = scale(itp,0:0.1:1)
itp2[0]
# 0.0




On Saturday, October 15, 2016 at 10:04:37 PM UTC+2, Florian Oswald wrote:
>
> Hi folks,
>
> I have question on SO that needs some attention. thanks!
>
>
> http://stackoverflow.com/questions/40045208/how-to-use-scale-in-interpolations-jl
>

[julia-users] Reductions sometimes not typestable?

[jw3126]

 

myop(::Int16, ::Int16) = Int32(1)
myop(::Int16, ::Int32) = Int64(1)
myop(::Int16, ::Int64) = Int128(1)
myop(::Int16, ::Int128) = Int128(1)

foldr(myop, Int16[1]) |> typeof |> println
foldr(myop, Int16[1,1]) |> typeof |> println
foldr(myop, Int16[1,1,1]) |> typeof |> println
foldr(myop, Int16[1,1,1,1]) |> typeof |> println
 

gives


Int32
Int64
Int128
Int128

Would it be better if the answer was typestable (always Int128)? See also 
here .

Re: [julia-users] Reductions sometimes not typestable?

[jw3126]

On Sunday, October 16, 2016 at 12:12:14 AM UTC+2, Yichao Yu wrote:
>
>
>
> 2016-10-15 18:06 GMT-04:00 jw3126 :
>
>> myop(::Int16, ::Int16) = Int32(1)
>> myop(::Int16, ::Int32) = Int64(1)
>> myop(::Int16, ::Int64) = Int128(1)
>> myop(::Int16, ::Int128) = Int128(1)
>>
>> foldr(myop, Int16[1]) |> typeof |> println
>> foldr(myop, Int16[1,1]) |> typeof |> println
>> foldr(myop, Int16[1,1,1]) |> typeof |> println
>> foldr(myop, Int16[1,1,1,1]) |> typeof |> println
>>  
>>
>> gives
>>
>>
>> Int32
>> Int64
>> Int128
>> Int128
>>
>> Would it be better if the answer was typestable (always Int128)? See 
>> also here .
>>
>
> Yes it would be better if you implement your operation that way and no the 
> compiler cannot do this.
>

One could change the promotion in foldr to use something like the following:

accumulate_eltype(op, T) = accumulate_eltype(op, T, T)

function accumulate_eltype(op, T, S)
S_next = promote_op(op, T, S)
if S == S_next
return S
else
return accumulate_eltype(op, T, S_next) 
end
end 

>  
>
>

[julia-users] Re: quadgk with 2 arguments

[digxx]

thx

[julia-users] Root finding package

[David P. Sanders]

https://github.com/giordano/PolynomialRoots.jl

[julia-users] Re: Root finding package

[Chris Rackauckas]

I don't know if NLsolve handles complex roots but I've always found it to 
be very good. Maybe you can just act like the problem is on a vector of two 
points (the real and imaginary parts) and solve for where the norm of f(x) 
is zero.

On Saturday, October 15, 2016 at 4:56:23 PM UTC-7, digxx wrote:
>
> So I know there is Roots but is there also one for finding complex roots?
>

Re: [julia-users] help with @generated function call please?

[Erik Schnetter]

A generated function is only useful if you perform a non-trivial
calculation based on the argument types. You don't do that here, so I
wonder whether simply using the Cartesian indexing macros by themselves
would be sufficient.

Note also that you don't need to write `$N` in your code; using `N`
directly has the same effect here.

I'm not saying that generated functions should be avoided at all costs, but
if it isn't necessary here you might as well skip the associated
complications.

-erik

On Fri, Oct 14, 2016 at 11:51 AM, Florian Oswald 
wrote:

> hi all,
>
> I want to evaluate a function at each index of an array. There is a N
> dimensional function, and I want to map it onto an N-dimensional array:
>
> fpoly(x::Array{Real,5}) = x[1] + x[2]^2 + x[3] + x[4]^2 + x[5]
>
> want to do
>
> a = rand(2,2,2,2,2);
> b = similar(a)
>
> for i1 in indices(a,1)
> for i2 in indices(a,2)
> ...
> b[i1,i2,i3,i4,i5] = fpoly(a[i1,i2,i3,i4,i5])
> end
> end...
>
> I tried:
> # actually want to do it inplace
> @generated function set_poly!{T,N}(a::Array{T,N})
> quote
> @nloops $N i a begin
> @nref $N a i = @ncall $N fpoly i->a[i]
> end
> end
> end
>
> but that fails. I dont get further than:
>
> macroexpand(:(@nloops 3 j a begin
> x = @ncall 3 fpoly i->a[j]
> end))
>
> *quote  # cartesian.jl, line 62:*
>
> *for j_3 = indices(a,3) # cartesian.jl, line 63:*
>
> *nothing # cartesian.jl, line 64:*
>
> *begin  # cartesian.jl, line 62:*
>
> *for j_2 = indices(a,2) # cartesian.jl, line 63:*
>
> *nothing # cartesian.jl, line 64:*
>
> *begin  # cartesian.jl, line 62:*
>
> *for j_1 = indices(a,1) # cartesian.jl, line 63:*
>
> *nothing # cartesian.jl, line 64:*
>
> *begin  # REPL[145], line 2:*
>
> *x = fpoly(a[j],a[j],a[j])*
>
> *end # cartesian.jl, line 65:*
>
> *nothing*
>
> *end*
>
> *end # cartesian.jl, line 65:*
>
> *nothing*
>
> *end*
>
> *end # cartesian.jl, line 65:*
>
> *nothing*
>
> *end*
>
> *end*
>
>
>
> *which is a start but how can I get the LHS right the indices of a right?*
>
>
>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] help with @generated function call please?

[Florian Oswald]

Yes I think you are right about that. Using a comprehension is just as good
for my case. But part of me would like to just finally understand that part
of Julia! Ok will have to wait for the next opportunity. :-)

Thanks anyway.
Florian

On Saturday, 15 October 2016, Erik Schnetter  wrote:

> A generated function is only useful if you perform a non-trivial
> calculation based on the argument types. You don't do that here, so I
> wonder whether simply using the Cartesian indexing macros by themselves
> would be sufficient.
>
> Note also that you don't need to write `$N` in your code; using `N`
> directly has the same effect here.
>
> I'm not saying that generated functions should be avoided at all costs,
> but if it isn't necessary here you might as well skip the associated
> complications.
>
> -erik
>
> On Fri, Oct 14, 2016 at 11:51 AM, Florian Oswald  > wrote:
>
>> hi all,
>>
>> I want to evaluate a function at each index of an array. There is a N
>> dimensional function, and I want to map it onto an N-dimensional array:
>>
>> fpoly(x::Array{Real,5}) = x[1] + x[2]^2 + x[3] + x[4]^2 + x[5]
>>
>> want to do
>>
>> a = rand(2,2,2,2,2);
>> b = similar(a)
>>
>> for i1 in indices(a,1)
>> for i2 in indices(a,2)
>> ...
>> b[i1,i2,i3,i4,i5] = fpoly(a[i1,i2,i3,i4,i5])
>> end
>> end...
>>
>> I tried:
>> # actually want to do it inplace
>> @generated function set_poly!{T,N}(a::Array{T,N})
>> quote
>> @nloops $N i a begin
>> @nref $N a i = @ncall $N fpoly i->a[i]
>> end
>> end
>> end
>>
>> but that fails. I dont get further than:
>>
>> macroexpand(:(@nloops 3 j a begin
>> x = @ncall 3 fpoly i->a[j]
>> end))
>>
>> *quote  # cartesian.jl, line 62:*
>>
>> *for j_3 = indices(a,3) # cartesian.jl, line 63:*
>>
>> *nothing # cartesian.jl, line 64:*
>>
>> *begin  # cartesian.jl, line 62:*
>>
>> *for j_2 = indices(a,2) # cartesian.jl, line 63:*
>>
>> *nothing # cartesian.jl, line 64:*
>>
>> *begin  # cartesian.jl, line 62:*
>>
>> *for j_1 = indices(a,1) # cartesian.jl, line 63:*
>>
>> *nothing # cartesian.jl, line 64:*
>>
>> *begin  # REPL[145], line 2:*
>>
>> *x = fpoly(a[j],a[j],a[j])*
>>
>> *end # cartesian.jl, line 65:*
>>
>> *nothing*
>>
>> *end*
>>
>> *end # cartesian.jl, line 65:*
>>
>> *nothing*
>>
>> *end*
>>
>> *end # cartesian.jl, line 65:*
>>
>> *nothing*
>>
>> *end*
>>
>> *end*
>>
>>
>>
>> *which is a start but how can I get the LHS right the indices of a right?*
>>
>>
>>
>
>
> --
> Erik Schnetter  >
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] ERROR: Target architecture mismatch

[ABB]

I think this is the actual error:

/home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(946):
 
error #303: explicit type is missing ("int" assumed)
  auto args = db.names.back().move_full();
   ^
  detected during:
instantiation of "const char *parse_unresolved_name(const char 
*, const char *, C &) [with C=::Db]" at line 3042
instantiation of "const char *parse_expression(const char *, 
const char *, C &) [with C=::Db]" at line 1520
instantiation of "const char *parse_array_type(const char *, 
const char *, C &) [with C=::Db]" at line 1707
instantiation of "const char *parse_type(const char *, const 
char *, C &) [with C=::Db]" at line 3866
instantiation of "const char *parse_special_name(const char *, 
const char *, C &) [with C=::Db]" at line 4026
instantiation of "const char *parse_encoding(const char *, 
const char *, C &) [with C=::Db]" at line 4185
instantiation of "void demangle(const char *, const char *, C 
&, int &) [with C=::Db]" at line 4267

/home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(948):
 
error: namespace "std" has no member "move"
  db.names.back().first += std::move(args);

^
  detected during:
instantiation of "const char *parse_unresolved_name(const char 
*, const char *, C &) [with C=::Db]" at line 3042
instantiation of "const char *parse_expression(const char *, 
const char *, C &) [with C=::Db]" at line 1520
instantiation of "const char *parse_array_type(const char *, 
const char *, C &) [with C=::Db]" at line 1707
instantiation of "const char *parse_type(const char *, const 
char *, C &) [with C=::Db]" at line 3866
instantiation of "const char *parse_special_name(const char *, 
const char *, C &) [with C=::Db]" at line 4026
instantiation of "const char *parse_encoding(const char *, 
const char *, C &) [with C=::Db]" at line 4185
instantiation of "void demangle(const char *, const char *, C 
&, int &) [with C=::Db]" at line 4267

/home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp(3476):
 
error: namespace "std" has no member "move"
  db.names.push_back(std::move(args));
  ^
  detected during:
instantiation of "const char *parse_base_unresolved_name(const 
char *, const char *, C &) [with C=::Db]" at line 1000
instantiation of "const char *parse_unresolved_name(const char 
*, const char *, C &) [with C=::Db]" at line 3042
instantiation of "const char *parse_expression(const char *, 
const char *, C &) [with C=::Db]" at line 1520
instantiation of "const char *parse_array_type(const char *, 
const char *, C &) [with C=::Db]" at line 1707
instantiation of "const char *parse_type(const char *, const 
char *, C &) [with C=::Db]" at line 3866
instantiation of "const char *parse_special_name(const char *, 
const char *, C &) [with C=::Db]" at line 4026
instantiation of "const char *parse_encoding(const char *, 
const char *, C &) [with C=::Db]" at line 4185
instantiation of "void demangle(const char *, const char *, C 
&, int &) [with C=::Db]" at line 4267

compilation aborted for 
/home1/04179/abean/julia/deps/srccache/llvm-svn/lib/Demangle/ItaniumDemangle.cpp
 
(code 4)
make[4]: *** 
[lib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o] Error 4
make[3]: *** [lib/Demangle/CMakeFiles/LLVMDemangle.dir/all] Error 2
make[2]: *** [all] Error 2
make[1]: *** [scratch/llvm-svn/build_Release/build-compiled] Error 2
make: *** [julia-deps] Error 2




On Saturday, October 15, 2016 at 1:54:54 PM UTC-5, ABB wrote:
>
> How smart of me.  I was confused because it looked like the version of 
> curl was the correct one.  I'll run it again and see where it messes up 
> this time.  Thanks for fixing that.
>
> On Saturday, October 15, 2016 at 1:51:28 PM UTC-5, Erik Schnetter wrote:
>>
>> You didn't show the actual error message. Debugging is easier if (after 
>> seeing an error) you re-run with "make -j1", so that the error message 
>> doesn't scroll away.
>>
>> -erik
>>
>> On Sat, Oct 15, 2016 at 1:41 PM, ABB  wrote:
>>
>>> I'm getting a new error. This is with the following make.user:
>>>
>>> LLVM_VER=svn
>>> USEICC=1
>>> USEIFC=1
>>> USE_INTEL_MKL=1
>>> USE_INTEL_MKL_FFT=1
>>> USE_INTEL_LIBM=1
>>>
>>>
>>> building directly on the  (KNL) compute node (in parallel: make -j 68)
>>>
>>> configure: amending tests/server/Makefile
>>> configure: amending tests/libtest/Makefile
>>> configure: amending docs/examples/Makefile
>>> configure: Configured to build curl/libcurl:
>>>
>>>   curl version: 7.50.1
>>>   Host setup:   x86_64-unknown-linux-gnu
>>>   Install prefix:   

[julia-users] Re: Parallel file access

[Steven Sagaert]

It still surprises me how in the scientific computing field people still 
refuse to learn about databases and then replicate database functionality 
in files in a complicated and probably buggy way. HDF5  is one example, 
there are many others. If you want to to fancy search (i.e. speedup search 
via indices) or do things like parallel writes/concurrency you REALLY 
should use databases. That's what they were invented for decades ago. 
Nowadays there a bigger choice than ever: Relational or non-relational 
(NOSQL), single host or distributed, web interface or not,  disk-based or 
in-memory,... There really is no excuse anymore not to use a database if 
you want to go beyond just reading in a bunch of data in one go in memory.

On Monday, October 10, 2016 at 5:09:39 PM UTC+2, Zachary Roth wrote:
>
> Hi, everyone,
>
> I'm trying to save to a single file from multiple worker processes, but 
> don't know of a nice way to coordinate this.  When I don't coordinate, 
> saving works fine much of the time.  But I sometimes get errors with 
> reading/writing of files, which I'm assuming is happening because multiple 
> processes are trying to use the same file simultaneously.
>
> I tried to coordinate this with a queue/channel of `Condition`s managed by 
> a task running in process 1, but this isn't working for me.  I've tried to 
> simiplify this to track down the problem.  At least part of the issue seems 
> to be writing to the channel from process 2.  Specifically, when I `put!` 
> something onto a channel (or `push!` onto an array) from process 2, the 
> channel/array is still empty back on process 1.  I feel like I'm missing 
> something simple.  Is there an easier way to go about coordinating multiple 
> processes that are trying to access the same file?  If not, does anyone 
> have any tips?
>
> Thanks for any help you can offer.
>
> Cheers,
> ---Zachary
>

Re: [julia-users] linspace question; bug?

[Stefan Karpinski]

On Fri, Oct 14, 2016 at 8:17 PM, Páll Haraldsson 
wrote:

>
> Nobody makes a one element linspace intentionally, but would it be bad to
> allow it?
>

Yes, it's better to raise an error when asked to do something that makes no
sense than to do some arbitrary wrong thing.

I wouldn't have posted if not for seeing "Real" that is the real question
> (bug?).
>

There's a discussion about this somewhere. The linspace type is likely to
change in 0.6 anyway.

Re: [julia-users] ERROR: Target architecture mismatch

[ABB]

I'm getting a new error. This is with the following make.user:

LLVM_VER=svn
USEICC=1
USEIFC=1
USE_INTEL_MKL=1
USE_INTEL_MKL_FFT=1
USE_INTEL_LIBM=1


building directly on the  (KNL) compute node (in parallel: make -j 68)

configure: amending tests/server/Makefile
configure: amending tests/libtest/Makefile
configure: amending docs/examples/Makefile
configure: Configured to build curl/libcurl:

  curl version: 7.50.1
  Host setup:   x86_64-unknown-linux-gnu
  Install prefix:   /home1/04179/abean/julia/usr
  Compiler: icc
  SSL support:  enabled (mbedTLS)
  SSH support:  enabled (libSSH2)
  zlib support: no  (--with-zlib)
  GSS-API support:  no  (--with-gssapi)
  TLS-SRP support:  no  (--enable-tls-srp)
  resolver: default (--enable-ares / --enable-threaded-resolver)
  IPv6 support: enabled
  Unix sockets support: enabled
  IDN support:  no  (--with-{libidn,winidn})
  Build libcurl:Shared=yes, Static=yes
  Built-in manual:  enabled
  --libcurl option: enabled (--disable-libcurl-option)
  Verbose errors:   enabled (--disable-verbose)
  SSPI support: no  (--enable-sspi)
  ca cert bundle:   /etc/pki/tls/certs/ca-bundle.crt
  ca cert path: no
  ca fallback:  no
  LDAP support: no  (--enable-ldap / --with-ldap-lib / 
--with-lber-lib)
  LDAPS support:no  (--enable-ldaps)
  RTSP support: enabled
  RTMP support: no  (--with-librtmp)
  metalink support: no  (--with-libmetalink)
  PSL support:  no  (--with-libpsl)
  HTTP2 support:disabled (--with-nghttp2)
  Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 
POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP

make: *** [julia-deps] Error 2


Does anyone have any advice for this one?  I didn't find previous 
discussion of this problem.

Re: [julia-users] ERROR: Target architecture mismatch

[ABB]

How smart of me.  I was confused because it looked like the version of curl 
was the correct one.  I'll run it again and see where it messes up this 
time.  Thanks for fixing that.

On Saturday, October 15, 2016 at 1:51:28 PM UTC-5, Erik Schnetter wrote:
>
> You didn't show the actual error message. Debugging is easier if (after 
> seeing an error) you re-run with "make -j1", so that the error message 
> doesn't scroll away.
>
> -erik
>
> On Sat, Oct 15, 2016 at 1:41 PM, ABB  
> wrote:
>
>> I'm getting a new error. This is with the following make.user:
>>
>> LLVM_VER=svn
>> USEICC=1
>> USEIFC=1
>> USE_INTEL_MKL=1
>> USE_INTEL_MKL_FFT=1
>> USE_INTEL_LIBM=1
>>
>>
>> building directly on the  (KNL) compute node (in parallel: make -j 68)
>>
>> configure: amending tests/server/Makefile
>> configure: amending tests/libtest/Makefile
>> configure: amending docs/examples/Makefile
>> configure: Configured to build curl/libcurl:
>>
>>   curl version: 7.50.1
>>   Host setup:   x86_64-unknown-linux-gnu
>>   Install prefix:   /home1/04179/abean/julia/usr
>>   Compiler: icc
>>   SSL support:  enabled (mbedTLS)
>>   SSH support:  enabled (libSSH2)
>>   zlib support: no  (--with-zlib)
>>   GSS-API support:  no  (--with-gssapi)
>>   TLS-SRP support:  no  (--enable-tls-srp)
>>   resolver: default (--enable-ares / --enable-threaded-resolver)
>>   IPv6 support: enabled
>>   Unix sockets support: enabled
>>   IDN support:  no  (--with-{libidn,winidn})
>>   Build libcurl:Shared=yes, Static=yes
>>   Built-in manual:  enabled
>>   --libcurl option: enabled (--disable-libcurl-option)
>>   Verbose errors:   enabled (--disable-verbose)
>>   SSPI support: no  (--enable-sspi)
>>   ca cert bundle:   /etc/pki/tls/certs/ca-bundle.crt
>>   ca cert path: no
>>   ca fallback:  no
>>   LDAP support: no  (--enable-ldap / --with-ldap-lib / 
>> --with-lber-lib)
>>   LDAPS support:no  (--enable-ldaps)
>>   RTSP support: enabled
>>   RTMP support: no  (--with-librtmp)
>>   metalink support: no  (--with-libmetalink)
>>   PSL support:  no  (--with-libpsl)
>>   HTTP2 support:disabled (--with-nghttp2)
>>   Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 
>> POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP
>>
>> make: *** [julia-deps] Error 2
>>
>>
>> Does anyone have any advice for this one?  I didn't find previous 
>> discussion of this problem.
>>
>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Type-stable global variables?

[Yichao Yu]

On Sat, Oct 15, 2016 at 8:59 AM, Andrei Zh 
wrote:

> What is the most straightforward way to make a variable in the global
> scope that can change it's value, but not its type? So far I use this:
>
> const GLOBAL_VAR = [MyType[]]  # array with single element
>
> set_global_var(x::MyType) = GLOBAL_VAR[1] = x
> get_goval_var() = GLOBAL_VAR[1]
>
> This works fine and preserves type stability, but looks quite unintuitive.
> Is there more standard container or another way (e.g. type assertions or
> something) to handle such cases?
>

Use `const GLOBAL_VAR = Ref{MyType}()` and `GLOBAL_VAR[]`. The plan is that
this will essentially be how a typed non-const global be implemented in the
future.

Re: [julia-users] Does julia -L work with plots?

[Stefan Rigger]

Works great, thanks!

On Sat, Oct 15, 2016 at 2:56 AM, Isaiah Norton 
wrote:

> Call `show()` at the end of the script. See explanation here:
>
> https://github.com/JuliaPy/PyPlot.jl#non-interactive-plotting
>
> On Fri, Oct 14, 2016 at 1:17 PM, Stefan Rigger 
> wrote:
>
>>
>>
>> Hello everyone,
>>
>> I'm using julia to numerically solve partial differential equations and
>> use PyPlot to plot the solutions. I'd like to be able to calculate a
>> solution and plot entering something like
>> julia -L file.jl
>>
>> in Terminal but unfortunately, this doesn't seem to work (there is no
>> window opening where one can view the solution). I've attached a small .jl
>> file if you want to test it yourself. Is there any way one can get this to
>> work? Thank you for your time,
>>
>> Best Regards,
>> Stefan Rigger
>>
>
>

[julia-users] Re: Parallel file access

[Ralph Smith]

How are the processes supposed to interact with the database?  Without 
extra synchronization logic, SQLite.jl gives (occasionally)
ERROR: LoadError: On worker 2:
SQLite.SQLiteException("database is locked")
which on the face of it suggests that all workers are using the same 
connection, although I opened the DB separately in each process.
(I think we should get "busy" instead of "locked", but then still have no 
good way to test for this and wait for a wake-up signal.)
So we seem to be at least as badly off as the original post, except with DB 
calls instead of simple writes.

We shouldn't have to stand up a separate multithreaded DB server just for 
this. Would you be kind enough to give us an example of simple (i.e. not 
client-server) multiprocess DB access in Julia?

On Saturday, October 15, 2016 at 9:40:17 AM UTC-4, Steven Sagaert wrote:
>
> It still surprises me how in the scientific computing field people still 
> refuse to learn about databases and then replicate database functionality 
> in files in a complicated and probably buggy way. HDF5  is one example, 
> there are many others. If you want to to fancy search (i.e. speedup search 
> via indices) or do things like parallel writes/concurrency you REALLY 
> should use databases. That's what they were invented for decades ago. 
> Nowadays there a bigger choice than ever: Relational or non-relational 
> (NOSQL), single host or distributed, web interface or not,  disk-based or 
> in-memory,... There really is no excuse anymore not to use a database if 
> you want to go beyond just reading in a bunch of data in one go in memory.
>
> On Monday, October 10, 2016 at 5:09:39 PM UTC+2, Zachary Roth wrote:
>>
>> Hi, everyone,
>>
>> I'm trying to save to a single file from multiple worker processes, but 
>> don't know of a nice way to coordinate this.  When I don't coordinate, 
>> saving works fine much of the time.  But I sometimes get errors with 
>> reading/writing of files, which I'm assuming is happening because multiple 
>> processes are trying to use the same file simultaneously.
>>
>> I tried to coordinate this with a queue/channel of `Condition`s managed 
>> by a task running in process 1, but this isn't working for me.  I've tried 
>> to simiplify this to track down the problem.  At least part of the issue 
>> seems to be writing to the channel from process 2.  Specifically, when I 
>> `put!` something onto a channel (or `push!` onto an array) from process 2, 
>> the channel/array is still empty back on process 1.  I feel like I'm 
>> missing something simple.  Is there an easier way to go about coordinating 
>> multiple processes that are trying to access the same file?  If not, does 
>> anyone have any tips?
>>
>> Thanks for any help you can offer.
>>
>> Cheers,
>> ---Zachary
>>
>

Re: [julia-users] Type-stable global variables?

[Andrei Zh]

Thanks, this is exactly what I was looking for. 

On Saturday, October 15, 2016 at 4:08:48 PM UTC+3, Yichao Yu wrote:
>
>
>
> On Sat, Oct 15, 2016 at 8:59 AM, Andrei Zh  > wrote:
>
>> What is the most straightforward way to make a variable in the global 
>> scope that can change it's value, but not its type? So far I use this: 
>>
>> const GLOBAL_VAR = [MyType[]]  # array with single element
>>
>> set_global_var(x::MyType) = GLOBAL_VAR[1] = x
>> get_goval_var() = GLOBAL_VAR[1]
>>
>> This works fine and preserves type stability, but looks quite 
>> unintuitive. Is there more standard container or another way (e.g. type 
>> assertions or something) to handle such cases? 
>>
>
> Use `const GLOBAL_VAR = Ref{MyType}()` and `GLOBAL_VAR[]`. The plan is 
> that this will essentially be how a typed non-const global be implemented 
> in the future.
>  
>
>

[julia-users] PyTest.jl - pytest-like testing framework for Julia - work-in-progress

[pdobacz]

Hello all!

I have made an attempt to start building a pytest-like testing framework 
for Julia. There is a (quite preliminary) package here: 
https://github.com/pdobacz/PyTest.jl

I intend to go along these lines:
  - follow pytest (http://doc.pytest.org/en/latest/) as closely as 
reasonably possible. Rationale: it is an accomplished framework, which I 
really appreciate using, hence I use it as inspiration and specification, 
to "not reinvent the wheel".
  - stray from pytest only when absolutely necessary, just to remain julian 
and adhere to existing standards
  - remain compatible with Base.Test

What PyTest.jl can do at the current state?
  - define and use fixtures (parametrized fixtures too!) to do 
setup/teardown pytest-style.
  - select a subset of tests to run (simplified "-k" option from pytest)
  - demonstrate being thoroughly tested itself!
  - not too much really, as it is still WIP, but I am going to sketch out a 
roadmap soon

I reach out to you to:
  - hear voices of support and encouragement (well, or criticism) - are 
there any pytest-and-julia-fans like myself?
  - get opinions and guidance - what would you recommend doing next?
  - find julia packages that could use such testing framework - ones that 
have complicated setup/teardown code to be organized and managed. I'd need 
such package to pivot my work in the right direction

(BTW, I am aware of Fixtures.jl, I just decided to stick more closely to 
pytest. Any comments from creators of Fixtures.jl?)

Re: [julia-users] ERROR: Target architecture mismatch

[Erik Schnetter]

You didn't show the actual error message. Debugging is easier if (after
seeing an error) you re-run with "make -j1", so that the error message
doesn't scroll away.

-erik

On Sat, Oct 15, 2016 at 1:41 PM, ABB  wrote:

> I'm getting a new error. This is with the following make.user:
>
> LLVM_VER=svn
> USEICC=1
> USEIFC=1
> USE_INTEL_MKL=1
> USE_INTEL_MKL_FFT=1
> USE_INTEL_LIBM=1
>
>
> building directly on the  (KNL) compute node (in parallel: make -j 68)
>
> configure: amending tests/server/Makefile
> configure: amending tests/libtest/Makefile
> configure: amending docs/examples/Makefile
> configure: Configured to build curl/libcurl:
>
>   curl version: 7.50.1
>   Host setup:   x86_64-unknown-linux-gnu
>   Install prefix:   /home1/04179/abean/julia/usr
>   Compiler: icc
>   SSL support:  enabled (mbedTLS)
>   SSH support:  enabled (libSSH2)
>   zlib support: no  (--with-zlib)
>   GSS-API support:  no  (--with-gssapi)
>   TLS-SRP support:  no  (--enable-tls-srp)
>   resolver: default (--enable-ares / --enable-threaded-resolver)
>   IPv6 support: enabled
>   Unix sockets support: enabled
>   IDN support:  no  (--with-{libidn,winidn})
>   Build libcurl:Shared=yes, Static=yes
>   Built-in manual:  enabled
>   --libcurl option: enabled (--disable-libcurl-option)
>   Verbose errors:   enabled (--disable-verbose)
>   SSPI support: no  (--enable-sspi)
>   ca cert bundle:   /etc/pki/tls/certs/ca-bundle.crt
>   ca cert path: no
>   ca fallback:  no
>   LDAP support: no  (--enable-ldap / --with-ldap-lib /
> --with-lber-lib)
>   LDAPS support:no  (--enable-ldaps)
>   RTSP support: enabled
>   RTMP support: no  (--with-librtmp)
>   metalink support: no  (--with-libmetalink)
>   PSL support:  no  (--with-libpsl)
>   HTTP2 support:disabled (--with-nghttp2)
>   Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3
> POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP
>
> make: *** [julia-deps] Error 2
>
>
> Does anyone have any advice for this one?  I didn't find previous
> discussion of this problem.
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/