[julia-users] Re: Problem with if else in Julia

[Lytu]

Thank you Jeff Waller, it works

On Friday, 15 May 2015 23:22:33 UTC+2, Jeff Waller wrote:
>
> Well I think the problem here is that though M[:,1]' * M[:,1] has only 1 
> value, it's still a (1x1) matrix, and not a scalar.
> What happens when you change to this?
>
> a=(M[:,1]' * M[:,1])[1]
>
> related.  is automatically converting a 1x1 matrix to a scalar or defining 
> comparison between 1x1 matrices and scalars reasonable?
>
> On Friday, May 15, 2015 at 5:14:43 PM UTC-4, Lytu wrote:
>>
>> When i do:
>> M=rand(5,5)
>> a=M[:,1]' * M[:,1]
>> if a<0
>> println("Less than 0")
>> else
>> println("more")
>> end
>>
>> I have an error: " isless has no method matching 
>> isless(::Array{Float64,2}, ::Int 32) in < at operators.jl:32
>>
>> Can anyone tell me please how to do this? Thank you
>>
>

[julia-users] Re: Defining a function in different modules

[Scott Jones]

On Saturday, May 16, 2015 at 1:08:48 AM UTC-4, ele...@gmail.com wrote:
>
> My mistake for continuing to use the term "ambiguous".  Julia eats 
> ambiguity for breakfast, choosing the most specific method from those 
> defined *for the same function*.  
>
> The problem is not ambiguity, it is that merging unrelated functions 
> automatically can silently change the behaviour of user code, because the 
> merge has changed the definition of "more specific".  When you extend a 
> function with a new method that is what you intend to do, fine, but when 
> modules have unrelated functions you may not intend to do that by just 
> "using" them both.  
>
> That the methods in your module only use types defined in the module does 
> not prevent another module from using a more general type in the same 
> parameter position ("Any", or a parent of your type), so it is necessary to 
> check all methods of all functions of the same name in all modules in scope 
> against each other, before deciding that the merge cannot change which 
> method is dispatched for that type.  To emphasise, the problem is not your 
> module, its "using" your module changing other unrelated user code silently.
>

If Module A has connect(value::Any), and I add a module B with 
connect(value::TypeB), I don't see a problem with calls to connect with 
something of TypeB "changing" the behavior
of Module A by not letting it grab *all* calls to connect().
Maybe it's still too early in the morning, but I still don't see the 
problem here... you go to the most specific type, not the the generic one...
 

> On Saturday, May 16, 2015 at 12:30:59 PM UTC+10, Scott Jones wrote:
>>
>>
>>
>> On Friday, May 15, 2015 at 9:36:01 PM UTC-4, ele...@gmail.com wrote:
>>>
>>>
>>>
>>> On Saturday, May 16, 2015 at 6:58:18 AM UTC+10, Scott Jones wrote:

 About functions that actually take the same types (which means they are 
 operating on types they they didn't define themselves), I think the new 
 approach in 0.4 (give a warning and don't merge in the "new" meaning) is 
 correct.
 I would not like to see that change to have the ambiguity only resolved 
 / warned about at run-time.

 I've said all along, I'm only talking about cases where there is no 
 ambiguity...
 Package A defines TypeA, and all of it's exported functions always have 
 TypeA in their method signature (even if it's only `::Type{TypeA})`.  Say 
 it has a "connect(db::TypeA, ipaddr, port)" method...
 Package B defines TypeB, (same as above),  Why should it not be able to 
 also define a "connect(db::TypeB,datasetname:UTF8String)"?

>>>
>>> Hi Scott,
>>>
>>> I'm not sure you meant it, but the way you wrote that makes it sound 
>>> like a simple fairly local test:
>>>
>>> if module defines *concrete* type and all methods have a parameter of 
>>> that type: merge ok
>>>
>>> But as I understand it, the test would need to be more complex, for 
>>> function 'f' something like:
>>>
>>> for each function named f in the current scope:
>>> for each method of the function:
>>> for each parameter position in the method:
>>>
>>
>> Not so, you stop at the first type that is defined in the same module.
>>
>
> Sure, the loops will shortcut when any "can't merge" situation is 
> encountered.  Can also shortcut if the number of parameters doesn't match, 
> but varargs upsets that.
>  
>   
>
>>if parameter is varargs: can't merge # not sure how else to 
>>> handle varargs, can fill infinite parameter positions
>>>get the type of the parameter
>>>
>>
>> If the varargs is limited to a type, or union of types, you simply check 
>> that (for unions, *all* the types in the union have to be defined in the 
>> same module for it to count)
>>
>
> Not sure I understand you here. Varargs methods are about the *number* of 
> parameters you can pass to a call 
> http://docs.julialang.org/en/release-0.3/manual/functions/#varargs-functions 
> 
> .
>

Maybe this is just in 0.4, but you can specify the type of a Varargs 
parameter, i.e.  x::TypeB...

>  
>
>>  
>>
>>>if the type depends on a generic parameter: can't merge # 
>>> since the types the generic parameter takes depends on the uses, and we 
>>> don't know that until we know if it merges or not
>>>
>>
>> Give an example please of exactly what you mean here... (remember, I'm 
>> still a Julia newbie...)
>>
>
> Sorry, in some other languages "generic" means a parametric method, and I 
> sometimes revert to that usage, oh that computer science would agree on its 
> terminology :).
>
> I mean if the method is a parametric method eg f{T}(a::T) the type of 'a' 
> depends on the parameter T.  IIUC the method f{T} gets re-compiled for all 
> types that it gets as parameters, where there is no existin

[julia-users] Any Julians attending CVPR 2015?

[Tracy Wadleigh]

It turns out my organization will be sending me to CVPR 2015 
. The decision is sort of last minute, and I 
won't be travelling with anyone or presenting anything, and I've made no 
introduction to anyone I've seen in the program, so I'm a little extra 
eager to find excuses to talk to people.

I won't be able to make it to JuliaCon this year (I'll be on a camping trip 
with my son), but I'd still like to try to meet some other Julians in 
Boston in June.

Re: [julia-users] Julia Summer of Code

[Tim Holy]

Worth linking
https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md

(both for mentors to edit and for candidates to peruse).

--Tim

On Friday, May 15, 2015 10:57:24 AM Viral Shah wrote:
> Folks,
> 
> The Moore Foundation is generously funding us to allow for 6-8 Julia Summer
> of Code projects. Details will be published soon, but if you are
> interested, please mark your calendars and plan your projects.
> 
> -viral

[julia-users] Re: Is Julia "ready" for use in an undergraduate mathematical computing course?

[Steven G. Johnson]

I've been using it for a few semesters now for both grad and undergrad 
courses.  Last year it was a bit rough, but this year it seemed to go 
pretty smoothly.  I just have them use PyPlot, and run an installfest at 
the beginning of the term for students to get Julia+IJulia+PyPlot installed 
(basically I tell them to install Julia and the Anaconda Python distro).  
(They can also use JuliaBox, but most students prefer to run things locally 
on their laptops.)

See also: https://github.com/stevengj/julia-mit

For homework assignments, I have them email their notebooks to the TAs, who 
print them out and grade them.  (That way, only the TAs need to have LaTeX, 
Pandoc etc installed to get nice printed output from Jupyter notebooks.)

On Friday, May 15, 2015 at 8:42:35 PM UTC-4, Sheehan Olver wrote:
>
>  I'm moving a Mathematical Computing course from Fortran to another 
> language.  I'd like to do Julia, but after a bad experience with students 
> trying to use Julia box, and the difficulty with plotting packages, I'm a 
> bit wary.  Other options are Matlab (which is really easy for students but 
> teaches bad coding) or Python (I don't like the np.array(...) syntax).  
>

[julia-users] Re: Microsoft and Julia (getting to 1.0)

[Steven G. Johnson]

If you are a Windows developer, it would be great to have your help in 
getting/keeping Julia running smoothly on Windows; only a few of the most 
active developers use Windows regularly right now.   Probably the biggest 
improvement will be the transition to libgit (issue #11196), as the package 
system on Windows is deathly slow at the moment.

Re: [julia-users] Julia Summer of Code

[Scott Jones]

These are particular interesting to me (if I were a student, or not already 
more than full-time working using Julia), I'd jump on one of these two:
https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-simple-persistent-distributed-storage
https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-fast-bignums-in-julia

The second also ties in with my interest in have fast decimal numbers in 
Julia, both fixed size (32,64,128), and arbitrary like bignums.

Re: [julia-users] Re: Is Julia "ready" for use in an undergraduate mathematical computing course?

[Sheehan Olver]

Good information to have, thanks.

Do you think Juno is easier than ijulia? 

Is Julia as much of a "marketable skill" as matlab or Python? (Not that I'm 
saying marketability is necessarily a good thing..I had a comp sci course  in 
Scheme after all)

Sent from my iPhone

> On 16 May 2015, at 10:26 pm, Steven G. Johnson  wrote:
> 
> I've been using it for a few semesters now for both grad and undergrad 
> courses.  Last year it was a bit rough, but this year it seemed to go pretty 
> smoothly.  I just have them use PyPlot, and run an installfest at the 
> beginning of the term for students to get Julia+IJulia+PyPlot installed 
> (basically I tell them to install Julia and the Anaconda Python distro).  
> (They can also use JuliaBox, but most students prefer to run things locally 
> on their laptops.)
> 
> See also: https://github.com/stevengj/julia-mit
> 
> For homework assignments, I have them email their notebooks to the TAs, who 
> print them out and grade them.  (That way, only the TAs need to have LaTeX, 
> Pandoc etc installed to get nice printed output from Jupyter notebooks.)
> 
>> On Friday, May 15, 2015 at 8:42:35 PM UTC-4, Sheehan Olver wrote:
>>  I'm moving a Mathematical Computing course from Fortran to another 
>> language.  I'd like to do Julia, but after a bad experience with students 
>> trying to use Julia box, and the difficulty with plotting packages, I'm a 
>> bit wary.  Other options are Matlab (which is really easy for students but 
>> teaches bad coding) or Python (I don't like the np.array(...) syntax).  

[julia-users] Re: how to create a command with an unquoted backslash in it?

[Steven G. Johnson]

Just put them in quotes?  e.g. `convert image.png "\\(" . "\\)"`

Re: [julia-users] Re: Is Julia "ready" for use in an undergraduate mathematical computing course?

[Felix Schüler]

I'm doing homework assignments in Julia for a machine learning class where 
we're free to choose the language and so far haven't had any problems.
Also using the IJulia notebooks with PyPlot (which can be a bit slow at times, 
but the ease and intuitive use of Julia makes up for that). I think the 
notebooks are great for this, haven't really looked at Juno though...

I did similar work for another class in Python last semester and haven't seen 
any downside yet (same here with the np.array(...) syntax) while finding many 
things much more intuitive!


On Saturday, May 16, 2015 at 2:33:12 PM UTC+2, Sheehan Olver wrote:
>
> Good information to have, thanks.
>
> Do you think Juno is easier than ijulia? 
>
> Is Julia as much of a "marketable skill" as matlab or Python? (Not that 
> I'm saying marketability is necessarily a good thing..I had a comp sci 
> course  in Scheme after all)
>
> Sent from my iPhone
>
> On 16 May 2015, at 10:26 pm, Steven G. Johnson  > wrote:
>
> I've been using it for a few semesters now for both grad and undergrad 
> courses.  Last year it was a bit rough, but this year it seemed to go 
> pretty smoothly.  I just have them use PyPlot, and run an installfest at 
> the beginning of the term for students to get Julia+IJulia+PyPlot installed 
> (basically I tell them to install Julia and the Anaconda Python distro).  
> (They can also use JuliaBox, but most students prefer to run things locally 
> on their laptops.)
>
> See also: https://github.com/stevengj/julia-mit
>
> For homework assignments, I have them email their notebooks to the TAs, 
> who print them out and grade them.  (That way, only the TAs need to have 
> LaTeX, Pandoc etc installed to get nice printed output from Jupyter 
> notebooks.)
>
> On Friday, May 15, 2015 at 8:42:35 PM UTC-4, Sheehan Olver wrote:
>>
>>  I'm moving a Mathematical Computing course from Fortran to another 
>> language.  I'd like to do Julia, but after a bad experience with students 
>> trying to use Julia box, and the difficulty with plotting packages, I'm a 
>> bit wary.  Other options are Matlab (which is really easy for students but 
>> teaches bad coding) or Python (I don't like the np.array(...) syntax).  
>>
>

[julia-users] Re: Defining a function in different modules

[elextr]

>
>
> If Module A has connect(value::Any), and I add a module B with 
> connect(value::TypeB), I don't see a problem with calls to connect with 
> something of TypeB "changing" the behavior
> of Module A by not letting it grab *all* calls to connect().
> Maybe it's still too early in the morning, but I still don't see the 
> problem here... you go to the most specific type, not the the generic one...
>

Example, assume there exists an entity relationship graph module that has a 
"connect" function that connects a relationship between two named nodes and 
attaches a piece of unknown data:

module relationship
connect(data::Any, from::UTF8string, to::UTF8string) = ...
end

And a database module where you connect to the named database with a 
username, note this obeys the rule "must use type defined in same module":

module scotts_database_module
type scotts_database end
connect(db::scotts_database, name::UTF8string, user::UTF8string) = ...
end

In my user code *assuming functions merged* :

using relationships, scotts_database_module # function connect now has two 
methods

#I make lots of relationship connections like
connect(1, "nodea", "nodeb") # connection with an integer data
connect("some text", "nodeb", "nodec") # connection with a string data
# now I want to connect two nodes with one of your excellent databases as 
the data 
sd = scotts_database()
connect(sd, "nodea", "nodeb") # connection with a database data

huh? why is my best customer getting a *runtime* error "no database named 
'nodea'"?

[...]

> Maybe this is just in 0.4, but you can specify the type of a Varargs 
> parameter, i.e.  x::TypeB...
>

Yes, but there can still be any number of parameters of that type in a 
call.   f(x::TypeB...) has to be checked against f(a::TypeA, b::TypeB, 
c::TypeC) because the relationship between TypeA and TypeB and between 
TypeC and TypeB could be such that again merging these functions will 
change the dispatch of f(x::TypeB...).  Its not impossible to do it, but it 
significantly complicates the checking algorithm.

[...]

> I mean if the method is a parametric method eg f{T}(a::T) the type of 'a' 
>> depends on the parameter T.  IIUC the method f{T} gets re-compiled for all 
>> types that it gets as parameters, where there is no existing method, so, 
>> without knowing all *uses* of f(), Julia can't know which methods exist to 
>> merge.
>>
>
> In that case, the module writer would need to have something like f{T <: 
> Union(TypeB, MyOtherBType)} in order for the compiler to use T.
>

Probably its too late (timezones!!), but I don't see what you mean?  
 

>
> However, I'd said that I wouldn't depend on that, I'd want a keyword for 
> function definition, that declares that this function is designed to be 
> unambigous
> (the compiler should still do the checking though).
>

I am all for being explicit, but I'm not sure what you want the keyword 
semantics to be?
 

> [...]
>
> If each module is using functions with different types, how can their 
> behavior change?
>

Indeed, if *each* module is using types that do not overlap it cannot, what 
I was saying was that you need to check that by looking at *both* modules, 
not just locally at one module.
 

> [...]
>
 

> Again, I think with a keyword or syntax to show that the programmer means 
> this to be a new generic function, that the programmer makes the guarantee 
> that it is unambiguous,
> it is.
>

In the scotts_database example above, how could you, as the writer of that 
module make such a guarantee, you have no way of knowing I would use your 
module with the relationship module, in fact you didn't even know it 
existed.  Or "connect" could even just be a function in the users own code, 
not even in a module.

 

>
>  
>>
>>> 3) If it is meant to be only callable via module.name (or 
>>> module.module.name [etc]), outside the module, i.e. it is not allowed 
>>> to make it extend something at the higher level.
>>>
>>
>> "Only callable by qualified name" depends on the situation in the user 
>> code, which modules they "using" into a specific scope.  When a  module is 
>> being compiled this is not known, so it can't affect anything in the module.
>>
>
> No, I am saying that this is a new capability that Julia presently does 
> not have (AFAIK).  How do you say that the user code is not allowed to use 
> "using" on this function?
>

Don't export it?
 

> [...]
> What I'm saying is that ONLY for functions where the module writer has 
> specified that the method(s) are supposed to be unambigous, would it do any 
> tests and try to merge.
>
Otherwise, it should act as it does now for exported functions, and simply 
> not merge if the name conflicts.
>

Again I'm not sure how the module writer can know that?
 

> [...]
>> Agree, you can't extend a function from another module in a way thats 
>> only visible in this module.  Thats why extension needs to be explicit "I 
>> do mean it, and I understand it has global consequences".  But i

[julia-users] Problem with if else in Julia

[Dominique Orban]

It seems you're trying to compute a dot product. Try dot(M[:,1], M[:,1]) or 
norm(M[:,1]). Of course, as a side comment, that quantity can't be negative ;).

[julia-users] Re: Defining a function in different modules

[Scott Jones]

On Saturday, May 16, 2015 at 8:50:12 AM UTC-4, ele...@gmail.com wrote:
>
>
>> If Module A has connect(value::Any), and I add a module B with 
>> connect(value::TypeB), I don't see a problem with calls to connect with 
>> something of TypeB "changing" the behavior
>> of Module A by not letting it grab *all* calls to connect().
>> Maybe it's still too early in the morning, but I still don't see the 
>> problem here... you go to the most specific type, not the the generic one...
>>
>
> Example, assume there exists an entity relationship graph module that has 
> a "connect" function that connects a relationship between two named nodes 
> and attaches a piece of unknown data:
>
> module relationship
> connect(data::Any, from::UTF8string, to::UTF8string) = ...
> end
>
> And a database module where you connect to the named database with a 
> username, note this obeys the rule "must use type defined in same module":
>
> module scotts_database_module
> type scotts_database end
> connect(db::scotts_database, name::UTF8string, user::UTF8string) = ...
> end
>
> In my user code *assuming functions merged* :
>
> using relationships, scotts_database_module # function connect now has two 
> methods
>
> #I make lots of relationship connections like
> connect(1, "nodea", "nodeb") # connection with an integer data
> connect("some text", "nodeb", "nodec") # connection with a string data
> # now I want to connect two nodes with one of your excellent databases as 
> the data 
> sd = scotts_database()
> connect(sd, "nodea", "nodeb") # connection with a database data
>
> huh? why is my best customer getting a *runtime* error "no database named 
> 'nodea'"?
>

OK, I'd say that is something the user will need to solve, and the 
documentation for the relationship "connect", because it is making a 
totally generic function, using types not defined by it,
is the one that should "lose" in this situation.
The user didn't *have* to use "using" for the relationships module... and 
people who write modules like relationships, since they are making a very 
generic function, need to be careful about the
names they chose, or not export those names.
connect() is an obvious very bad choice...
 

>
> [...]
>
>> Maybe this is just in 0.4, but you can specify the type of a Varargs 
>> parameter, i.e.  x::TypeB...
>>
>
> Yes, but there can still be any number of parameters of that type in a 
> call.   f(x::TypeB...) has to be checked against f(a::TypeA, b::TypeB, 
> c::TypeC) because the relationship between TypeA and TypeB and between 
> TypeC and TypeB could be such that again merging these functions will 
> change the dispatch of f(x::TypeB...).  Its not impossible to do it, but it 
> significantly complicates the checking algorithm.
>

Are you saying that this is an issue if TypeA <: TypeB, or TypeC <: TypeB?
Otherwise, I don't see a problem.
 

>
> [...]
>
>> I mean if the method is a parametric method eg f{T}(a::T) the type of 'a' 
>>> depends on the parameter T.  IIUC the method f{T} gets re-compiled for all 
>>> types that it gets as parameters, where there is no existing method, so, 
>>> without knowing all *uses* of f(), Julia can't know which methods exist to 
>>> merge.
>>>
>>
>> In that case, the module writer would need to have something like f{T <: 
>> Union(TypeB, MyOtherBType)} in order for the compiler to use T.
>>
>
> Probably its too late (timezones!!), but I don't see what you mean?  
>

In order to T to act to make the method unambigous, T must be of a type 
defined in that module.   So, if you had something like f(T)(a::T), wihtout 
restricting T as above with the Union, it could not be declared to be 
unambigous,
and the compiler could easily detect that and give an error.
 

>  
>
>>
>> However, I'd said that I wouldn't depend on that, I'd want a keyword for 
>> function definition, that declares that this function is designed to be 
>> unambigous
>> (the compiler should still do the checking though).
>>
>
> I am all for being explicit, but I'm not sure what you want the keyword 
> semantics to be?
>  
>
>> [...]
>>
>> If each module is using functions with different types, how can their 
>> behavior change?
>>
>
> Indeed, if *each* module is using types that do not overlap it cannot, 
> what I was saying was that you need to check that by looking at *both* 
> modules, not just locally at one module.
>  
>
>> [...]
>>
>  
>
>> Again, I think with a keyword or syntax to show that the programmer means 
>> this to be a new generic function, that the programmer makes the guarantee 
>> that it is unambiguous,
>> it is.
>>
>
> In the scotts_database example above, how could you, as the writer of that 
> module make such a guarantee, you have no way of knowing I would use your 
> module with the relationship module, in fact you didn't even know it 
> existed.  Or "connect" could even just be a function in the users own code, 
> not even in a module.
>

I can make that guarantee, because my functions that I (using new

Re: [julia-users] Problem with if else in Julia

[Tim Holy]

If you don't need the square root, sumabs2 is even more efficient and can work 
over dimensions.

--Tim

On Saturday, May 16, 2015 06:05:06 AM Dominique Orban wrote:
> It seems you're trying to compute a dot product. Try dot(M[:,1], M[:,1]) or
> norm(M[:,1]). Of course, as a side comment, that quantity can't be negative
> ;).

[julia-users] Re: Problem with if else in Julia

[David P. Sanders]

El viernes, 15 de mayo de 2015, 16:14:43 (UTC-5), Lytu escribió:
>
> When i do:
> M=rand(5,5)
> a=M[:,1]' * M[:,1]
> if a<0
> println("Less than 0")
> else
> println("more")
> end
>
> I have an error: " isless has no method matching 
> isless(::Array{Float64,2}, ::Int 32) in < at operators.jl:32
>
Perhaps quite not you want this time, but 

a .< 0

returns a matrix of the same size as a, with true or false doing the 
comparison of each entry.

David.

 

> Can anyone tell me please how to do this? Thank you
>

[julia-users] Re: Is Julia "ready" for use in an undergraduate mathematical computing course?

[David P. Sanders]

El viernes, 15 de mayo de 2015, 19:42:35 (UTC-5), Sheehan Olver escribió:
>
>
>
>  I'm moving a Mathematical Computing course from Fortran to another 
> language.  I'd like to do Julia, but after a bad experience with students 
> trying to use Julia box, and the difficulty with plotting packages, I'm a 
> bit wary.  Other options are Matlab (which is really easy for students but 
> teaches bad coding) or Python (I don't like the np.array(...) syntax).  
>
>
I've been teaching with Julia for a couple of semesters, mainly with 
IJulia. The students seem to like it.
Some have been just using JuliaBox, but this starts to be painful once they 
start writing scripts.
I've tried to get them to use Juno too, but that hasn't been so successful.

I have also mainly used PyPlot for graphics, though Gadfly seems like a 
nice option too.

David. 


 

> Thoughts?
>

[julia-users] how to replace , to . in Array{Any,2}:

[paul analyst]

I have file with decimal separator lika ","
x=readdlm("x.txt",'\t')

julia> x=x[2:end,:]
6390x772 Array{Any,2}:

some kolumns looks :
julia> x[:,69]
6390-element Array{Any,1}:
 0.0
  "0,33"
  "0,72"
  "1,09"
  "0,95"
  "3,57"
  "2,27"
  "2,42"



julia> replace(x[:,69],',','.')
ERROR: `replace` has no method matching replace(::Array{Any,1}, ::Char, 
::Char)

julia> replace(string(x[:,69],',','.'))
ERROR: `replace` has no method matching replace(::ASCIIString)


how to replace , to . ?

I can repalce all , to . 

Paul

[julia-users] Re: Defining a function in different modules

[Toivo Henningsson]

On Friday, 15 May 2015 15:13:11 UTC+2, Michael Francis wrote:
>
> @Scott, @Toivo
>
> In my mind this changing the meaning of existing code is happening all the 
> time with the verbs in Base. Each time I use a module it can (and likely 
> does) inject new behavior for verbs defined in Base ( or for verbs defined 
> in any other module)  These silently change the way other modules work. 
> This is actually the beauty of the type system as it allows a module to add 
> features to another module without having to fork the module. The only 
> thing you can't do is add new verbs to an existing module.
>
> Is that not the case ? 
>
 
That really depends on how you look at it.
You are right, of course, that many packages extend functions in Base, and 
need to in order to function properly.
I will argue, however, that most of these do no change how other code works 
(and if they do, they shouldn't).

What a package should not do is to overload a function in another module in 
a way that makes code that does not depend on the package behave 
differently than before. That is bad style and I believe there is more or 
less an implicit consensus that you don't do that. (And, by #265 
, it might not do what you 
want.) If you look at packages that extend functions in other modules, I 
believe that in pretty much all examples you will find, the added methods 
involve a type that is defined in the package itself. Thus, they will never 
affect code that doesn't depend on the package.

I seem to remember that there was talk at some point about introducing a 
limitation that you could not extend a function in another module unless 
you used a type defined in your own module in the signature, but it was not 
implemented. I'm still not sure if it captures all relevant cases.

[julia-users] Re: Which command in julia that permit us to see the implementation of a module/function?

[David P. Sanders]

The @which macro is nice. You need to pass it the whole function call (working 
code) , e.g.

@which sin(10)

It tells you exactly which method is being used, and gives a link to the source 
file. In IJulia this link is clickable and takes you to the correct line in 
GitHub. In Juno, it opens the relevant source file directly in Juno at the 
correct line. 

David 

[julia-users] Re: Problem with if else in Julia

[paul analyst]

You can use [] after a
if a[]<0

works also
Paul

W dniu piątek, 15 maja 2015 23:14:43 UTC+2 użytkownik Lytu napisał:
>
> When i do:
> M=rand(5,5)
> a=M[:,1]' * M[:,1]
> if a<0
> println("Less than 0")
> else
> println("more")
> end
>
> I have an error: " isless has no method matching 
> isless(::Array{Float64,2}, ::Int 32) in < at operators.jl:32
>
> Can anyone tell me please how to do this? Thank you
>

[julia-users] Re: how do we convert an array{Float64,1} in a Float64?

[paul analyst]

Use []

julia> A=rand(1)
1-element Array{Float64,1}:
 0.33519

julia> A[]
0.3351896128863725

julia>


W dniu piątek, 15 maja 2015 23:18:32 UTC+2 użytkownik Lytu napisał:
>
> Someone know how to convert an array{Float64,1} in a Float64?
> Thank you
>

[julia-users] Re: how do we convert an array{Float64,1} in a Float64?

[paul analyst]

Or simply 
julia> A=rand(1)[]
0.5353688036503286

Paul


W dniu sobota, 16 maja 2015 21:19:48 UTC+2 użytkownik paul analyst napisał:
>
> Use []
>
> julia> A=rand(1)
> 1-element Array{Float64,1}:
>  0.33519
>
> julia> A[]
> 0.3351896128863725
>
> julia>
>
>
> W dniu piątek, 15 maja 2015 23:18:32 UTC+2 użytkownik Lytu napisał:
>>
>> Someone know how to convert an array{Float64,1} in a Float64?
>> Thank you
>>
>

[julia-users] Re: Any Julians attending CVPR 2015?

[Sebastian Nowozin]

Hi Tracy,

I am a regular Julia user and will be attending CVPR, feel free to find me 
at the conference.
(Also, I have seen Dahua Lin at previous CVPRs, but I am not sure he will 
attend this year.)

Best,
Sebastian Nowozin


On Saturday, 16 May 2015 12:19:30 UTC+1, Tracy Wadleigh wrote:
>
> It turns out my organization will be sending me to CVPR 2015 
> . The decision is sort of last minute, and 
> I won't be travelling with anyone or presenting anything, and I've made no 
> introduction to anyone I've seen in the program, so I'm a little extra 
> eager to find excuses to talk to people.
>
> I won't be able to make it to JuliaCon this year (I'll be on a camping 
> trip with my son), but I'd still like to try to meet some other Julians in 
> Boston in June.
>
>
>

[julia-users] llvmcall printf

[andrew cooke]

Does anyone have a working example that calls printf via llvmcall?

I realise I'm uncomfortably inbetween llvmdev and julia-users, but I'm 
asking here first because I suspect my limitations are still more 
julia-related.

In particular, 

julia> g() = Base.llvmcall("""
 call i32 (i8*, ...)* @printf(i8* c"hello world\00")
 ret""",
 Void, Tuple{})
g (generic function with 2 methods)

julia> g()
ERROR: error compiling g: Failed to parse LLVM Assembly: 
julia: llvmcall:3:35: error: expected string
call i32 (i8*, ...)* @printf(i8* c"hello world
  ^

seems like it's *almost* there...?

Thanks,
Andrew

(I suspect I also need something other than @printf, like 
IntrinsicsX86.printf or something, but I can't find where I saw an example 
like that...  Related, declare doesn't seem to be accepted, or assignment 
to global vsariables.  But I am completely new to all this...)

Re: [julia-users] Re: how to create a command with an unquoted backslash in it?

[Yakir Gagnon]

Hmm. That doesn't work:
I just get '\\)' which results in an error if I try to run it.
On 16/05/2015 10:34 PM, "Steven G. Johnson"  wrote:

> Just put them in quotes?  e.g. `convert image.png "\\(" . "\\)"`
>

Re: [julia-users] Re: how to create a command with an unquoted backslash in it?

[Yakir Gagnon]

Problem solved. I had a mistake in the imagemagick command and thought it
was the parenthesis. It wasn't. Sorry about the rant. No need for any
special treatment for the parenthesis. It just works.
On 17/05/2015 8:00 AM, "Yakir Gagnon" <12.ya...@gmail.com> wrote:

> Hmm. That doesn't work:
> I just get '\\)' which results in an error if I try to run it.
> On 16/05/2015 10:34 PM, "Steven G. Johnson"  wrote:
>
>> Just put them in quotes?  e.g. `convert image.png "\\(" . "\\)"`
>>
>

[julia-users] Re: how to create a command with an unquoted backslash in it?

[andrew cooke]

just playing around, it seems to me like julia is escaping with slashes.  i 
don't have imagmagick installed, but with echo it woks as expected:

julia> run(`echo \(`)
(

julia> run(`echo \\(`)
\(

julia> ^D
andrew@netbook:~> echo (
bash: syntax error near unexpected token `newline'
andrew@netbook:~> echo \(
(
andrew@netbook:~> echo \\(
bash: syntax error near unexpected token `('
andrew@netbook:~> echo \\\(
\(

the two julia commands give results equivalent to `\(` and `\\\(` in bash.



On Friday, 15 May 2015 00:41:24 UTC-3, Yakir Gagnon wrote:
>
>
>
> I'm trying to run an external imagemagick command. As such, it needs to 
> include some escaped parenthesis. In shell it would look like this:
>
> convert img.png \( -clone 0 -crop 450x+450+0 -dither None -remap 
> colormap1.png \) \( -clone 0 -crop 450x+951+0 -dither None -remap 
> colormap2.png \) -delete 0 z%d.png
>
> But when I build something like this in julia:
>
> cmd = `convert $fname ( -clone 0 -crop wx+$(w+1)+0 -dither None -remap 
> colormap1.png ) ( -clone 0 -crop 450x+$(sz[1]-w+1)+0 -dither None -remap 
> colormap2.png ) -delete 0 z%d.png`
>
> the parenthesis don't get escaped (as they should be).
>
> This is not the first time I've gone crazy over this issue. Any ideas?
>

[julia-users] metaprogramming : modifying function arguments

[Eka Palamadai]

I am trying to write a function f1 that takes a function f2 and arguments 
of f2 as parameters,
modifies some arguments of f2,  and calls f2 with the modified arguments.

function f1(f2::Function, args...)
  #iterate through the args and modify some of the contents of args
  f2(args)
end

Any suggestions on how to do this?

Thanks.





 

[julia-users] Re: how to replace , to . in Array{Any,2}:

[elextr]

I don't think replace broadcasts, you have to write a loop applying replace 
to each string at a time.

On Sunday, May 17, 2015 at 4:40:05 AM UTC+10, paul analyst wrote:
>
> I have file with decimal separator lika ","
> x=readdlm("x.txt",'\t')
>
> julia> x=x[2:end,:]
> 6390x772 Array{Any,2}:
>
> some kolumns looks :
> julia> x[:,69]
> 6390-element Array{Any,1}:
>  0.0
>   "0,33"
>   "0,72"
>   "1,09"
>   "0,95"
>   "3,57"
>   "2,27"
>   "2,42"
>
>
>
> julia> replace(x[:,69],',','.')
> ERROR: `replace` has no method matching replace(::Array{Any,1}, ::Char, 
> ::Char)
>
> julia> replace(string(x[:,69],',','.'))
> ERROR: `replace` has no method matching replace(::ASCIIString)
>
>
> how to replace , to . ?
>
> I can repalce all , to . 
>
> Paul
>
>
>

[julia-users] Re: metaprogramming : modifying function arguments

[David P. Sanders]

El sábado, 16 de mayo de 2015, 18:26:48 (UTC-5), Eka Palamadai escribió:
>
> I am trying to write a function f1 that takes a function f2 and arguments 
> of f2 as parameters,
> modifies some arguments of f2,  and calls f2 with the modified arguments.
>
> function f1(f2::Function, args...)
>   #iterate through the args and modify some of the contents of args
>   f2(args)
> end
>

Depending on what you mean by "modifying", you don't need metaprogramming 
for this. 
For example:

 
modify(x::Int) = 2x
modify(x::Float64) = 3x

function f1(args...)
new_args = [modify(arg) for arg in args]
f2(new_args...)
end

function f2(a, b)
@show a, b
end

f1(2, 3.5)


 

>
> Any suggestions on how to do this?
>
> Thanks.
>
>
>
>
>
>  
>

[julia-users] Re: metaprogramming : modifying function arguments

[David P. Sanders]

El sábado, 16 de mayo de 2015, 18:26:48 (UTC-5), Eka Palamadai escribió:
>
> I am trying to write a function f1 that takes a function f2 and arguments 
> of f2 as parameters,
> modifies some arguments of f2,  and calls f2 with the modified arguments.
>
> function f1(f2::Function, args...)
>   #iterate through the args and modify some of the contents of args
>   f2(args)
> end
>

Depending on what you mean by "modifying", you don't need metaprogramming 
for this. 
For example:

 
modify(x::Int) = 2x
modify(x::Float64) = 3x

function f1(args...)
new_args = [modify(arg) for arg in args]
f2(new_args...)
end

function f2(a, b)
@show a, b
end

f1(2, 3.5)


This gives

(4,10.5)


David.



 

>
> Any suggestions on how to do this?
>
> Thanks.
>
>
>
>
>
>  
>

[julia-users] Re: metaprogramming : modifying function arguments

[elextr]

On Sunday, May 17, 2015 at 9:26:48 AM UTC+10, Eka Palamadai wrote:
>
> I am trying to write a function f1 that takes a function f2 and arguments 
> of f2 as parameters,
> modifies some arguments of f2,  and calls f2 with the modified arguments.
>
> function f1(f2::Function, args...)
>   #iterate through the args and modify some of the contents of args
>   f2(args)
>

f2(args...)
 

> end
>
> Any suggestions on how to do this?
>
> Thanks.
>
>
>
>
>
>  
>

[julia-users] Re: metaprogramming : modifying function arguments

[David P. Sanders]

Apologies for the double (now triple) posting. Passing the function as an 
argument as well, that becomes:

function f1(f, args...)
@show args
new_args = [modify(arg) for arg in args]
f(new_args...)
end

function f2(a, b)
@show a, b
end

f1(f2, 2, 3.5)

El sábado, 16 de mayo de 2015, 18:36:42 (UTC-5), David P. Sanders escribió:
>
>
>
> El sábado, 16 de mayo de 2015, 18:26:48 (UTC-5), Eka Palamadai escribió:
>>
>> I am trying to write a function f1 that takes a function f2 and arguments 
>> of f2 as parameters,
>> modifies some arguments of f2,  and calls f2 with the modified arguments.
>>
>> function f1(f2::Function, args...)
>>   #iterate through the args and modify some of the contents of args
>>   f2(args)
>> end
>>
>
> Depending on what you mean by "modifying", you don't need metaprogramming 
> for this. 
> For example:
>
>  
> modify(x::Int) = 2x
> modify(x::Float64) = 3x
>
> function f1(args...)
> new_args = [modify(arg) for arg in args]
> f2(new_args...)
> end
>
> function f2(a, b)
> @show a, b
> end
>
> f1(2, 3.5)
>
>
> This gives
>
> (4,10.5)
>
>
> David.
>
>
>
>  
>
>>
>> Any suggestions on how to do this?
>>
>> Thanks.
>>
>>
>>
>>
>>
>>  
>>
>

Re: [julia-users] Any Julians attending CVPR 2015?

[Kevin Squire]

Hi Tracy, Sebastian, I'll be there as well (with my company, no talk).
Would be nice to meet up!

Cheers,
   Kevin

On Saturday, May 16, 2015, Sebastian Nowozin  wrote:

>
> Hi Tracy,
>
> I am a regular Julia user and will be attending CVPR, feel free to find me
> at the conference.
> (Also, I have seen Dahua Lin at previous CVPRs, but I am not sure he will
> attend this year.)
>
> Best,
> Sebastian Nowozin
>
>
> On Saturday, 16 May 2015 12:19:30 UTC+1, Tracy Wadleigh wrote:
>>
>> It turns out my organization will be sending me to CVPR 2015
>> . The decision is sort of last minute,
>> and I won't be travelling with anyone or presenting anything, and I've made
>> no introduction to anyone I've seen in the program, so I'm a little extra
>> eager to find excuses to talk to people.
>>
>> I won't be able to make it to JuliaCon this year (I'll be on a camping
>> trip with my son), but I'd still like to try to meet some other Julians in
>> Boston in June.
>>
>>
>>

Re: [julia-users] llvmcall printf

[Yichao Yu]

On Sat, May 16, 2015 at 5:01 PM, andrew cooke  wrote:
>
> Does anyone have a working example that calls printf via llvmcall?
>
> I realise I'm uncomfortably inbetween llvmdev and julia-users, but I'm
> asking here first because I suspect my limitations are still more
> julia-related.
>
> In particular,
>
> julia> g() = Base.llvmcall("""
>  call i32 (i8*, ...)* @printf(i8* c"hello world\00")
>  ret""",
>  Void, Tuple{})
> g (generic function with 2 methods)
>
> julia> g()
> ERROR: error compiling g: Failed to parse LLVM Assembly:
> julia: llvmcall:3:35: error: expected string
> call i32 (i8*, ...)* @printf(i8* c"hello world
>   ^
>
> seems like it's *almost* there...?
>
> Thanks,
> Andrew
>
> (I suspect I also need something other than @printf, like
> IntrinsicsX86.printf or something, but I can't find where I saw an example
> like that...  Related, declare doesn't seem to be accepted, or assignment to
> global vsariables.  But I am completely new to all this...)
>

I was also interested in knowning how to use `llvmcall` in general but
at least for this limited case, (and I guess you probably know
already) it is easier to user `ccall`

```julia
julia> ccall(:printf, Int, (Ptr{Cchar},), "hellow world\n")
hellow world
13
```

[julia-users] Re: Microsoft and Julia (getting to 1.0)

[Eric Forgy]

Very cool reading: https://github.com/JuliaLang/julia/pull/11196

I occasionally write code, but to call myself a "developer" would be an 
insult to you guys who are doing awesome things :)

If Julia apps are ever going to target enterprises in a serious manner, 
there absolutely must be solid support for Windows. I'll keep my eyes open 
for ways to help out.

On Saturday, May 16, 2015 at 8:32:31 PM UTC+8, Steven G. Johnson wrote:
>
> If you are a Windows developer, it would be great to have your help in 
> getting/keeping Julia running smoothly on Windows; only a few of the most 
> active developers use Windows regularly right now.   Probably the biggest 
> improvement will be the transition to libgit (issue #11196), as the package 
> system on Windows is deathly slow at the moment.
>

[julia-users] Re: metaprogramming : modifying function arguments

[Eka Palamadai]

Thanks. That works.

On Saturday, May 16, 2015 at 7:38:49 PM UTC-4, David P. Sanders wrote:
>
> Apologies for the double (now triple) posting. Passing the function as an 
> argument as well, that becomes:
>
> function f1(f, args...)
> @show args
> new_args = [modify(arg) for arg in args]
> f(new_args...)
> end
>
> function f2(a, b)
> @show a, b
> end
>
> f1(f2, 2, 3.5)
>
> El sábado, 16 de mayo de 2015, 18:36:42 (UTC-5), David P. Sanders escribió:
>>
>>
>>
>> El sábado, 16 de mayo de 2015, 18:26:48 (UTC-5), Eka Palamadai escribió:
>>>
>>> I am trying to write a function f1 that takes a function f2 and 
>>> arguments of f2 as parameters,
>>> modifies some arguments of f2,  and calls f2 with the modified arguments.
>>>
>>> function f1(f2::Function, args...)
>>>   #iterate through the args and modify some of the contents of args
>>>   f2(args)
>>> end
>>>
>>
>> Depending on what you mean by "modifying", you don't need metaprogramming 
>> for this. 
>> For example:
>>
>>  
>> modify(x::Int) = 2x
>> modify(x::Float64) = 3x
>>
>> function f1(args...)
>> new_args = [modify(arg) for arg in args]
>> f2(new_args...)
>> end
>>
>> function f2(a, b)
>> @show a, b
>> end
>>
>> f1(2, 3.5)
>>
>>
>> This gives
>>
>> (4,10.5)
>>
>>
>> David.
>>
>>
>>
>>  
>>
>>>
>>> Any suggestions on how to do this?
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>>  
>>>
>>

[julia-users] Re: Defining a function in different modules

[elextr]

On Saturday, May 16, 2015 at 11:30:13 PM UTC+10, Scott Jones wrote:
>
>
>
> On Saturday, May 16, 2015 at 8:50:12 AM UTC-4, ele...@gmail.com wrote:
>>
>>
>>> If Module A has connect(value::Any), and I add a module B with 
>>> connect(value::TypeB), I don't see a problem with calls to connect with 
>>> something of TypeB "changing" the behavior
>>> of Module A by not letting it grab *all* calls to connect().
>>> Maybe it's still too early in the morning, but I still don't see the 
>>> problem here... you go to the most specific type, not the the generic one...
>>>
>>
>> Example, assume there exists an entity relationship graph module that has 
>> a "connect" function that connects a relationship between two named nodes 
>> and attaches a piece of unknown data:
>>
>> module relationship
>> connect(data::Any, from::UTF8string, to::UTF8string) = ...
>> end
>>
>> And a database module where you connect to the named database with a 
>> username, note this obeys the rule "must use type defined in same module":
>>
>> module scotts_database_module
>> type scotts_database end
>> connect(db::scotts_database, name::UTF8string, user::UTF8string) = ...
>> end
>>
>> In my user code *assuming functions merged* :
>>
>> using relationships, scotts_database_module # function connect now has 
>> two methods
>>
>> #I make lots of relationship connections like
>> connect(1, "nodea", "nodeb") # connection with an integer data
>> connect("some text", "nodeb", "nodec") # connection with a string data
>> # now I want to connect two nodes with one of your excellent databases as 
>> the data 
>> sd = scotts_database()
>> connect(sd, "nodea", "nodeb") # connection with a database data
>>
>> huh? why is my best customer getting a *runtime* error "no database named 
>> 'nodea'"?
>>
>
> OK, I'd say that is something the user will need to solve, and the 
> documentation for the relationship "connect", because it is making a 
> totally generic function, using types not defined by it,
> is the one that should "lose" in this situation.
> The user didn't *have* to use "using" for the relationships module... and 
> people who write modules like relationships, since they are making a very 
> generic function, need to be careful about the
> names they chose, or not export those names.
> connect() is an obvious very bad choice...
>

The reality is that in natural language verbs are overloaded between 
domains, and even in the same domain (eg CS has database "connect", network 
"connect", graph "connect" etc).  Programmers are going to use the verbs 
that are natural to their domain in their software, that is natural and 
good since it aids understanding in that domain, but there are going to be 
clashes when domains mix.

Since there *will* be multiple use of verbs, I don't believe that a 
language can, in good conscience, deliberately lay traps for its users like 
that I illustrated above.

Julia 0.4 quite correctly prevents this problem from happening by refusing 
to import names that clash, and only allowing explicit manual extension of 
verbs, which as Toivo points out is a key strength of Julia.

I agree that it would be good to minimise the number of times qualified 
names are needed in user code, and of course qualification does not work at 
all for operators, but naive automatic merging of functions that have the 
same name is not the way to do it.

Automerging functions which *really* cannot cause problems, seems to me, to 
require complex testing. But if "somebody" made a PR where it could be 
trialled, maybe the impact would be found to be acceptable, or at least a 
good trade off for the number of situations it improves.  But it doesn't 
solve all cases, and I don't really have a feel for how much it would solve 
and if it would be worth it.

Otherwise manually instructing function merges when they make sense may 
also assist, this is already being investigated.

Or an aliasing "using" so the name can be changed on import:

  using scotts_database_module.connect as sdconnect

or some such syntax would avoid qualification.

I don't have any other magic solutions to decreasing qualification 
verbosity I'm afraid, suggestions are welcome.
 

> [...] 
>
>>
>> [...]
>>
>>> Maybe this is just in 0.4, but you can specify the type of a Varargs 
>>> parameter, i.e.  x::TypeB...
>>>
>>
>> Yes, but there can still be any number of parameters of that type in a 
>> call.   f(x::TypeB...) has to be checked against f(a::TypeA, b::TypeB, 
>> c::TypeC) because the relationship between TypeA and TypeB and between 
>> TypeC and TypeB could be such that again merging these functions will 
>> change the dispatch of f(x::TypeB...).  Its not impossible to do it, but it 
>> significantly complicates the checking algorithm.
>>
>
> Are you saying that this is an issue if TypeA <: TypeB, or TypeC <: TypeB?
>

Yes
 
[...]

>
> In order to T to act to make the method unambigous, T must be of a type 
> defined in that module.   So, if you had somethin

[julia-users] Re: Julia Summer of Code

[Oscar Blumberg]

I just added (what I think is) a cool project for anyone who would want to 
dive deep into the compiler. It may be on the hard end of the spectrum but 
we all know what happens when you tell a student something is "too hard" ;)

https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-specialized-call-site-method-caching

On Friday, May 15, 2015 at 1:57:24 PM UTC-4, Viral Shah wrote:
>
> Folks,
>
> The Moore Foundation is generously funding us to allow for 6-8 Julia 
> Summer of Code projects. Details will be published soon, but if you are 
> interested, please mark your calendars and plan your projects.
>
> -viral
>

[julia-users] Installing HDF5

[rk]

Hi

I am running Julia in Juno on a Windows 7 machine. I am trying to install 
HDF5 and am noticing that the build time is quite long. In particular it 
seems to be stuck on building Blosc (for many hours). I have tried removing 
and re-installing the package. 
I was just wondering if the long build time was normal for this package?

Thank you very much for your help

[julia-users] Gadfly: Geom.smooth and Scale.x_discrete (labels) conflict

[mbob]

Geom.smooth and Scale.x_discrete (labels) don't seem to play nicely 
together.

Geom.smooth requires  x (and y) to be bound to an array of plain numbers.

So, if the x values are an array of dates, one needs to convert these dates 
to (for example) day of year numbers, and Geom.smooth will be happy.

But, if you don't want to use these day of year numbers as the x labels, 
and would prefer to use date strings for labels, then the Scale.x_discrete 
(labels= dayofyeartostring) option works, where dayofyeartostring is a 
user-supplied function to output a desired string representation of the 
date.

But you can't do both of these things at the same time! (At least I can't.)

Geom.smooth seems to try to use the labels (i.e., strings) that 
Scale.x_discrete (labels) produces -- and then complains that these values 
aren't plain numbers.

Is it possible to use Geom.smooth when the x values are essentially dates, 
and to use string date labels for the x-values at the same time?

Thanks!

(Please forgive me if this topic has been covered somewhere -- I couldn't 
find it addressed.)

[julia-users] Re: Displaying an array of images in an IJulia notebook

[Jingpeng Wu]

I would suggest to try PyPlot, it uses matplotlib of python.
using PyPlot
imshow(randn(10,10))



On Monday, May 26, 2014 at 4:36:45 PM UTC-4, Yuri Vishnevsky wrote:
>
> Hi all,
>
> I'm playing around with some image-related stuff in Julia and am using the 
> method recommended here 
>  
> to 
> get image data to render as an actual image inside of an IJulia notebook.
>
> I'd like to extend Julia's multimedia display functionality to handle 
> arrays of images (here's 
>  how 
> Mathematica does it) and am trying to figure out the best way to do it.
>
> This is what I've written so that individual array elements (of type Png) 
> display as images:
>
> type Png
>  data
> end
> Base.writemime(io::IO, ::MIME"image/png", x::Png) = write(io, x.data)
>
> The only way I've been able to get arrays to render as images at all has 
> been this:
>
> Base.writemime(io::IO, ::MIME"text/plain", x::Vector{Png}) = for i in x 
> display(i) end
>
> which seems very wrong, conceptually, but does have the benefit of 
> actually working.
>
> If anyone has thoughts on the right way to approach this question, I'd 
> love to hear them.
>
> Cheers,
> Yuri
>

Re: [julia-users] Re: Julia Summer of Code

[Yichao Yu]

On Sat, May 16, 2015 at 6:30 PM, Oscar Blumberg  wrote:
> I just added (what I think is) a cool project for anyone who would want to
> dive deep into the compiler. It may be on the hard end of the spectrum but
> we all know what happens when you tell a student something is "too hard" ;)
>
> https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-specialized-call-site-method-caching
>

Is this the same with https://github.com/JuliaLang/julia/issues/10805
and @vtjnash seems to have a partially working version in place
although disabled by default?

>
> On Friday, May 15, 2015 at 1:57:24 PM UTC-4, Viral Shah wrote:
>>
>> Folks,
>>
>> The Moore Foundation is generously funding us to allow for 6-8 Julia
>> Summer of Code projects. Details will be published soon, but if you are
>> interested, please mark your calendars and plan your projects.
>>
>> -viral

[julia-users] Re: Installing HDF5

[Tony Kelman]

No, this isn't normal, but bugs happen. Blosc's binaries are hosted on an 
MIT url that has caused issues with some proxies in the past, I believe. 
You might also try reverting this 
commit 
https://github.com/JuliaLang/BinDeps.jl/commit/94ac0fa54d4ee64f23f1815c1114c9d6d23ead05
 
in your local copy of BinDeps, which you can find  the location of by 
running `Pkg.dir("BinDeps")`


On Saturday, May 16, 2015 at 7:58:43 PM UTC-7, rk wrote:
>
> Hi
>
> I am running Julia in Juno on a Windows 7 machine. I am trying to install 
> HDF5 and am noticing that the build time is quite long. In particular it 
> seems to be stuck on building Blosc (for many hours). I have tried removing 
> and re-installing the package. 
> I was just wondering if the long build time was normal for this package?
>
> Thank you very much for your help
>

[julia-users] Re: Microsoft and Julia (getting to 1.0)

[Tony Kelman]

Julia might get Microsoft's attention at some point. You could go vote 
for 
http://feedback.azure.com/forums/257792-machine-learning/suggestions/7668225-julia-support-in-azureml-studio,
 
for one thing.

The recently-released VS Code editor also looks very nice, and as soon as 
it supports plugins it would be very worthwhile to look at making a Julia 
plugin for it.

I've also recently been in touch with someone from the Microsoft MPI team, 
it might end up being tractable to get some libraries and Julia packages 
that use MPI for parallelism to work on Windows too. We'll have to see.

Regarding getting to Julia 1.0 faster, we also very badly need more 
influence within the LLVM community. Keno has a large number of patches 
open to make LLVM and MCJIT work better for Julia, but they're not getting 
reviewed by enough people. Having Julia Computing get enough resources to 
hire, say, the top few dozen contributors full-time would absolutely help 
things advance faster, but I don't think it should be rushed either.


On Saturday, May 16, 2015 at 6:07:05 PM UTC-7, Eric Forgy wrote:
>
> Very cool reading: https://github.com/JuliaLang/julia/pull/11196
>
> I occasionally write code, but to call myself a "developer" would be an 
> insult to you guys who are doing awesome things :)
>
> If Julia apps are ever going to target enterprises in a serious manner, 
> there absolutely must be solid support for Windows. I'll keep my eyes open 
> for ways to help out.
>
> On Saturday, May 16, 2015 at 8:32:31 PM UTC+8, Steven G. Johnson wrote:
>>
>> If you are a Windows developer, it would be great to have your help in 
>> getting/keeping Julia running smoothly on Windows; only a few of the most 
>> active developers use Windows regularly right now.   Probably the biggest 
>> improvement will be the transition to libgit (issue #11196), as the package 
>> system on Windows is deathly slow at the moment.
>>
>

Re: [julia-users] Re: Julia Summer of Code

[Tim Holy]

+1. That seems almost certain to substantially reduce the cost of type-
instability.

For prototyping purposes, I posted a possible pure-julia hack that gets at the 
same issue:
https://groups.google.com/d/msg/julia-dev/fXJznjwQMF0/tsaw2P7uNTcJ

But I agree it would be far preferable to implement this in the language 
itself.

--Tim

On Saturday, May 16, 2015 03:30:42 PM Oscar Blumberg wrote:
> I just added (what I think is) a cool project for anyone who would want to
> dive deep into the compiler. It may be on the hard end of the spectrum but
> we all know what happens when you tell a student something is "too hard" ;)
> 
> https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/inde
> x.md#project-specialized-call-site-method-caching
> On Friday, May 15, 2015 at 1:57:24 PM UTC-4, Viral Shah wrote:
> > Folks,
> > 
> > The Moore Foundation is generously funding us to allow for 6-8 Julia
> > Summer of Code projects. Details will be published soon, but if you are
> > interested, please mark your calendars and plan your projects.
> > 
> > -viral