[julia-users] Re: Help getting started with Julia's Graphs package

2014-02-26 Thread Ed Scheinerman
Thanks. This helps some. Let me illustrate. I just want simple graphs with 
integer-named vertices. This starts off well:

julia using Graphs

julia g = simple_graph(4)
Directed Graph (4 vertices, 0 edges)

julia using Graphs

julia g = simple_graph(4,is_directed=false)
Undirected Graph (4 vertices, 0 edges)

julia add_edge!(g,1,2)
edge [1]: 1 -- 2

But if I want to add an additional vertex, I get trouble:

julia add_vertex!(g,5)
ERROR: no method push!(Range1{Int64},Int64)
 in add_vertex! at /home/ers/.julia/Graphs/src/graph.jl:50

And I can't figure out how to delete vertices!



On Sunday, February 23, 2014 12:50:01 PM UTC-5, Uwe Korn wrote:


 On Saturday, 22 February 2014 22:24:24 UTC, Ed Scheinerman wrote:

 I have looked through the documentation for the Graphs package here:
  http://julialang.org/Graphs.jl/index.html 
 http://julialang.org/Graphs.jl/index.html
 But I'm finding it difficult to get started, even creating simple graphs 
 (undirected, no loops, no multiple edges). Adding vertices doesn't seem to 
 work. 


 For an adjacency list representation, this short snippet may be helpful:

 using Graphs

 # Create new graph
 g = adjlist(KeyVertex{ASCIIString}, is_directed=false)

 # Add 2 vertices
 v = add_vertex!(g, v)
 u = add_vertex!(g, u)

 # Add an edge between them
 add_edge!(g, v, u)

 # This will print:

 #   KeyVertex{ASCIIString}(1,v)

 # which is the neighbour of u
 println(out_neighbors(u, g))

  

 Is there a tutorial somewhere to help me get started? Thanks. 


 I'm not aware of a tutorial (which would be indeed very helpful) but I 
 learnt how to use the Graphs package by looking at its tests like 
 https://github.com/JuliaLang/Graphs.jl/blob/master/test/adjlist.jl which 
 outline quite short how that package works.



Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread David Moon
I am not suggesting any change to :(x+y) so it would continue to be the 
same as quote x+y end.  I think that would return Expr(internal_symbol(+, 
context), internal_symbol(x, context), internal_symbol(y, context)) to 
use a sketchy syntax that might not actually be valid Julia.

I like using the ` character for quasiquote as in Lisp but isn't Julia 
already using ` for something more widely used?

On Tuesday, February 25, 2014 11:00:32 PM UTC-5, Fil Mackay wrote:

 The semantics of :symbol would not change from the *status quo* under my 
 proposal.

 Perhaps :(x) should be the same as :x rather than the same as quote x 
 end.  Thus if the result of the unary : operator is just a symbol, it is 
 always an external symbol, but the *quote* special form is able to 
 produce just an internal symbol.


 What would :(x+y) produce - invalid or quote x + y end? This inline 
 quote format seems to be used quite a lot and handy. I have wondered about 
 using a different character for symbols and quotes to avoid this ambiguity.



[julia-users] Parallel Computing : How to kill a remote reference ?

2014-02-26 Thread KS
Hi, 

I need to start and stop the same process. For example when I start a 
process and I get a RemoteRef(2,1,16) how can i kill it or stop it ? 

Thank you in advance. 

KS 



[julia-users] Re: [ANN] Formatting.jl: a Julia package for python-like formatting

2014-02-26 Thread Ismael VC
But anyway It doesn't seem to be needed?:

julia format_string = {1} + {2} = {3}\n
{1} + {2} = {3}   

julia format_expr = f{1} + {2} = {3}\n   
  
FormatExpr(,,[FormatEntry(ArgSpec(1,false,identity),FormatSpec 
  cls   = s 

  typ = s   
fill  = 
  
  align =  
sign  = -   
  
  width = -1   
  prec  = -1   
 
  ipre  = false
  zpad  = false
  tsep  = false
),FormatEntry(ArgSpec(2,false,identity),FormatSpec
  cls   = s
  typ   = s
  fill  =
  align = 
  sign  = -
  width = -1
  prec  = -1
  ipre  = false
  zpad  = false
  tsep  = false
),FormatEntry(ArgSpec(3,false,identity),FormatSpec
  cls   = s
  typ   = s
  fill  =
  align = 
  sign  = -
  width = -1
  prec  = -1
  ipre  = false
  zpad  = false
  tsep  = false
)],UTF8String[ + , = ])

julia a = 100; b = 200;

julia printfmt(format_string, a, b, a+b)
100 + 200 = 300

julia printfmt(format_expr, a, b, a+b)
100 + 200 = 300


[julia-users] Re: Julia Design Patterns?

2014-02-26 Thread Peter Simon
Actually, this is something I used to do way back in Fortran 77 with COMMON 
blocks and frequently used PARAMETER statements, before modules were 
introduced in Fortran 90.  There may be a better way with Julia, perhaps 
others more proficient in Julia can comment.

--Peter

On Wednesday, February 26, 2014 7:40:43 AM UTC-8, Robert Feldt wrote:

 Wow, that's an interesting idea. Will explore. Is this something that 
 you/people frequently use in Julia? Not something I've seen much in other 
 languages. Is there some downside? I imagine it is hard to directly test 
 the common code or one includes it into a dummy type for testing purposes?

 Cheers,

 Robert

 Den onsdagen den 26:e februari 2014 kl. 14:41:45 UTC+1 skrev Peter Simon:

 How about using 4., but instead of copying redundant data/fields into 
 each variant, put this common material into a small file and include it 
 in each of the variants?  Then only a single version needs to be edited and 
 maintained.

 --Peter

 P.S.  BlackBoxOptim is a great contribution.  I plan to make heavy use of 
 it in the near future in designing hardware.

 On Tuesday, February 25, 2014 10:44:46 PM UTC-8, Robert Feldt wrote:

 I really like Julia's dispatch mechanisms, type system and so on. I have 
 found a number of different ways I use it to design libraries and programs. 
 But it would be great with some patterns/ideas/feedback from more seasoned 
 Julia programmers. What are your Julia Design Patterns?

 A concrete situation that I have struggled somewhat with is how to best 
 design in Julia for the situation where I have one main/default 
 algorithms/set-of-behaviors+data but then with a multitude of small 
 variations. Typically there is a large set of data and methods/functions 
 that are the same for the whole class of things and there are only 1-4 
 functions/methods that need to change for each variation. An example from 
 BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is 
 where there is one type for DifferentialEvolution and then multiple 
 different variants of DE where only 1-2 functions differ from the base DE 
 one. 

 I have found a few different design patterns for this situation but 
 not sure what is the long-term best:

 1. Have a few Function fields in the base (composite) type which are 
 set up at construction time and that implements the variant-specific 
 behaviors. This is simple and direct but feels a bit un-Julia since it 
 does not really use the dispatch system. One also has to predict the 
 variation points (here: function) upfront which might not be flexible 
 enough. Also performance might suffer since the types of the function not 
 known.

 2. Have one XBase type which includes a field of an abstract XStrategy 
 type where specific sub-types to XStrategy implements each variant by 
 implementing variant-specific functionality. This seems fairly efficient, 
 but again one has to predict more or less where the variations should 
 happen since the functions on the XBase type need to call to the XStrategy 
 functions.

 3. Have one XBase type which is then included as a field in specific 
 variants. This seems efficient and flexible but the code is somewhat 
 cluttered in that one has to have one extra indirection when accessing 
 common data/fields (this is a similar problem in 2 above though).

 4. Copy the common data/fields of XBase into each specific variant. 
 This is the most flexible and should have high performance but there seem 
 to be a risk that bugs have to be changed in multile source code locations 
 since it is a kind of copy-paste reuse.

 Would be great to hear your advice/feedback on how you design in/with 
 the Julia type and dispatch system.

 Thanks,

 Robert Feldt



Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread Cristóvão Duarte Sousa
Stefan, I've wondered if command literals couldn't be created with just a 
new non-standard string literal, something like ccommand arg1 arg2.
The only problem I see is that then every double quote mark in the command 
has to escaped (which will confuse the code though).
Even if I use the command syntax a lot, sometimes I think that backticks 
could be used in something else...

On Wednesday, February 26, 2014 3:44:54 PM UTC, Stefan Karpinski wrote:

 Yes, the backtick is used for command 
 syntaxhttp://docs.julialang.org/en/latest/manual/running-external-programs/.
  
 Sometimes I think it would be really nice to have it for expression quoting 
 since markdown has acclimatized us to using backticks for quoting code, but 
 command syntax is way too handy to steal this from – and its interior 
 interpolation rules are far trickier than normal quotations so you can't 
 just use a normal string construct.


 On Wed, Feb 26, 2014 at 8:57 AM, David Moon dave...@alum.mit.edujavascript:
  wrote:

 I am not suggesting any change to :(x+y) so it would continue to be the 
 same as quote x+y end.  I think that would return Expr(internal_symbol(+, 
 context), internal_symbol(x, context), internal_symbol(y, context)) to 
 use a sketchy syntax that might not actually be valid Julia.

 I like using the ` character for quasiquote as in Lisp but isn't Julia 
 already using ` for something more widely used?


 On Tuesday, February 25, 2014 11:00:32 PM UTC-5, Fil Mackay wrote:

 The semantics of :symbol would not change from the *status quo* under 
 my proposal.

 Perhaps :(x) should be the same as :x rather than the same as quote x 
 end.  Thus if the result of the unary : operator is just a symbol, it is 
 always an external symbol, but the *quote* special form is able to 
 produce just an internal symbol.


 What would :(x+y) produce - invalid or quote x + y end? This inline 
 quote format seems to be used quite a lot and handy. I have wondered about 
 using a different character for symbols and quotes to avoid this ambiguity.




Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread Stefan Karpinski
Yeah, that double quote issue is the main problem. It's pretty common to
want to use double quotes in commands, so using double quotes for command
syntax would make things much nastier – and very importantly, no longer
cut-and-paste from the command line. Code quotation and metaprogramming is
a more niche activity than running external commands, so in this showdown,
running external commands still takes precedence.


On Wed, Feb 26, 2014 at 11:06 AM, Cristóvão Duarte Sousa
cris...@gmail.comwrote:

 Stefan, I've wondered if command literals couldn't be created with just a
 new non-standard string literal, something like ccommand arg1 arg2.
 The only problem I see is that then every double quote mark in the command
 has to escaped (which will confuse the code though).
 Even if I use the command syntax a lot, sometimes I think that backticks
 could be used in something else...

 On Wednesday, February 26, 2014 3:44:54 PM UTC, Stefan Karpinski wrote:

 Yes, the backtick is used for command 
 syntaxhttp://docs.julialang.org/en/latest/manual/running-external-programs/.
 Sometimes I think it would be really nice to have it for expression quoting
 since markdown has acclimatized us to using backticks for quoting code, but
 command syntax is way too handy to steal this from – and its interior
 interpolation rules are far trickier than normal quotations so you can't
 just use a normal string construct.


 On Wed, Feb 26, 2014 at 8:57 AM, David Moon dave...@alum.mit.edu wrote:

 I am not suggesting any change to :(x+y) so it would continue to be the
 same as quote x+y end.  I think that would return Expr(internal_symbol(+,
 context), internal_symbol(x, context), internal_symbol(y, context)) to
 use a sketchy syntax that might not actually be valid Julia.

 I like using the ` character for quasiquote as in Lisp but isn't Julia
 already using ` for something more widely used?


 On Tuesday, February 25, 2014 11:00:32 PM UTC-5, Fil Mackay wrote:

 The semantics of :symbol would not change from the *status quo* under
 my proposal.

 Perhaps :(x) should be the same as :x rather than the same as quote x
 end.  Thus if the result of the unary : operator is just a symbol, it is
 always an external symbol, but the *quote* special form is able to
 produce just an internal symbol.


 What would :(x+y) produce - invalid or quote x + y end? This inline
 quote format seems to be used quite a lot and handy. I have wondered about
 using a different character for symbols and quotes to avoid this ambiguity.





Re: [julia-users] Julia Design Patterns?

2014-02-26 Thread Ivar Nesje
How is getters/setters - MethodError(b, (a,)) better than direct field 
access - ErrorException(type a has no field b)?

They seem equivalent to me.


kl. 17:47:32 UTC+1 onsdag 26. februar 2014 skrev Kevin Squire følgende:

 Hello Robert, 

 Thanks for posting this question.  This is something I've struggled with 
 and attempted to address in a couple of different ways.  I'm not totally 
 happy with either of the solutions, but I'll share them in the hope that 
 they're useful.

 1. One method you did not mention was to implement everything against an 
 abstract base class, but override individual functions for different 
 concrete classes.  To avoid depending on the actual type implementation, 
 additional functions are defined on the concrete types which give access to 
 the data.

 A couple of variations on this include the GraphicsDevice interface in 
 Julia (
 https://github.com/JuliaLang/julia/blob/master/base/graphics.jl#L177-L192), 
 and Graphs.jl (
 http://julialang.org/Graphs.jl/interface.html#interface-declaration-and-verification
 ).

 This is a pretty good solution, although how well it works is problem 
 dependent.  I've sometimes found it challenging/annoying to design 
 getters and setters just to make sure that the functions and types are 
 only loosely coupled.

 2. I used your third design pattern when implementing OrderedDicts (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/ordereddict.jl),
  
 and used John Miles White's @delegate macro to simplify the code (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/delegate.jl). 
  

 The @delegate macro makes the code less cluttered, but has the downside in 
 that you don't have access to other/new methods for the wrapped type unless 
 you specify them.

 Hope this is useful.  Cheers!

   Kevin


 On Tue, Feb 25, 2014 at 10:44 PM, Robert Feldt 
 robert...@gmail.comjavascript:
  wrote:

 I really like Julia's dispatch mechanisms, type system and so on. I have 
 found a number of different ways I use it to design libraries and programs. 
 But it would be great with some patterns/ideas/feedback from more seasoned 
 Julia programmers. What are your Julia Design Patterns?

 A concrete situation that I have struggled somewhat with is how to best 
 design in Julia for the situation where I have one main/default 
 algorithms/set-of-behaviors+data but then with a multitude of small 
 variations. Typically there is a large set of data and methods/functions 
 that are the same for the whole class of things and there are only 1-4 
 functions/methods that need to change for each variation. An example from 
 BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is 
 where there is one type for DifferentialEvolution and then multiple 
 different variants of DE where only 1-2 functions differ from the base DE 
 one. 

 I have found a few different design patterns for this situation but not 
 sure what is the long-term best:

 1. Have a few Function fields in the base (composite) type which are 
 set up at construction time and that implements the variant-specific 
 behaviors. This is simple and direct but feels a bit un-Julia since it 
 does not really use the dispatch system. One also has to predict the 
 variation points (here: function) upfront which might not be flexible 
 enough. Also performance might suffer since the types of the function not 
 known.

 2. Have one XBase type which includes a field of an abstract XStrategy 
 type where specific sub-types to XStrategy implements each variant by 
 implementing variant-specific functionality. This seems fairly efficient, 
 but again one has to predict more or less where the variations should 
 happen since the functions on the XBase type need to call to the XStrategy 
 functions.

 3. Have one XBase type which is then included as a field in specific 
 variants. This seems efficient and flexible but the code is somewhat 
 cluttered in that one has to have one extra indirection when accessing 
 common data/fields (this is a similar problem in 2 above though).

 4. Copy the common data/fields of XBase into each specific variant. 
 This is the most flexible and should have high performance but there seem 
 to be a risk that bugs have to be changed in multile source code locations 
 since it is a kind of copy-paste reuse.

 Would be great to hear your advice/feedback on how you design in/with the 
 Julia type and dispatch system.

 Thanks,

 Robert Feldt




Re: [julia-users] Julia Design Patterns?

2014-02-26 Thread Robert Feldt
Hi Kevin,

Thanks for your input. You are right, I did forget about your method 1 
which I've also used at times. It does feel a bit annoying but I can't 
describe why; maybe it's an (unfounded) concern that performance is 
hampered but I guess there will be almost zero effect of that in practice 
given Julia's backend and optimizations in LLVM. Maybe we can address the 
getters and setters issue with a simple macro? Hmm...

There seems to be discussions about the possibility to override the dot 
operator / field access which allow for a lot of flexibility if added:
https://github.com/JuliaLang/julia/issues/1974

Cheers,

/Robert

Den onsdagen den 26:e februari 2014 kl. 17:47:32 UTC+1 skrev Kevin Squire:

 Hello Robert, 

 Thanks for posting this question.  This is something I've struggled with 
 and attempted to address in a couple of different ways.  I'm not totally 
 happy with either of the solutions, but I'll share them in the hope that 
 they're useful.

 1. One method you did not mention was to implement everything against an 
 abstract base class, but override individual functions for different 
 concrete classes.  To avoid depending on the actual type implementation, 
 additional functions are defined on the concrete types which give access to 
 the data.

 A couple of variations on this include the GraphicsDevice interface in 
 Julia (
 https://github.com/JuliaLang/julia/blob/master/base/graphics.jl#L177-L192), 
 and Graphs.jl (
 http://julialang.org/Graphs.jl/interface.html#interface-declaration-and-verification
 ).

 This is a pretty good solution, although how well it works is problem 
 dependent.  I've sometimes found it challenging/annoying to design 
 getters and setters just to make sure that the functions and types are 
 only loosely coupled.

 2. I used your third design pattern when implementing OrderedDicts (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/ordereddict.jl),
  
 and used John Miles White's @delegate macro to simplify the code (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/delegate.jl). 
  

 The @delegate macro makes the code less cluttered, but has the downside in 
 that you don't have access to other/new methods for the wrapped type unless 
 you specify them.

 Hope this is useful.  Cheers!

   Kevin


 On Tue, Feb 25, 2014 at 10:44 PM, Robert Feldt 
 robert...@gmail.comjavascript:
  wrote:

 I really like Julia's dispatch mechanisms, type system and so on. I have 
 found a number of different ways I use it to design libraries and programs. 
 But it would be great with some patterns/ideas/feedback from more seasoned 
 Julia programmers. What are your Julia Design Patterns?

 A concrete situation that I have struggled somewhat with is how to best 
 design in Julia for the situation where I have one main/default 
 algorithms/set-of-behaviors+data but then with a multitude of small 
 variations. Typically there is a large set of data and methods/functions 
 that are the same for the whole class of things and there are only 1-4 
 functions/methods that need to change for each variation. An example from 
 BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is 
 where there is one type for DifferentialEvolution and then multiple 
 different variants of DE where only 1-2 functions differ from the base DE 
 one. 

 I have found a few different design patterns for this situation but not 
 sure what is the long-term best:

 1. Have a few Function fields in the base (composite) type which are 
 set up at construction time and that implements the variant-specific 
 behaviors. This is simple and direct but feels a bit un-Julia since it 
 does not really use the dispatch system. One also has to predict the 
 variation points (here: function) upfront which might not be flexible 
 enough. Also performance might suffer since the types of the function not 
 known.

 2. Have one XBase type which includes a field of an abstract XStrategy 
 type where specific sub-types to XStrategy implements each variant by 
 implementing variant-specific functionality. This seems fairly efficient, 
 but again one has to predict more or less where the variations should 
 happen since the functions on the XBase type need to call to the XStrategy 
 functions.

 3. Have one XBase type which is then included as a field in specific 
 variants. This seems efficient and flexible but the code is somewhat 
 cluttered in that one has to have one extra indirection when accessing 
 common data/fields (this is a similar problem in 2 above though).

 4. Copy the common data/fields of XBase into each specific variant. 
 This is the most flexible and should have high performance but there seem 
 to be a risk that bugs have to be changed in multile source code locations 
 since it is a kind of copy-paste reuse.

 Would be great to hear your advice/feedback on how you design in/with the 
 Julia type and dispatch system.

 Thanks,

 Robert Feldt




Re: [julia-users] Julia Design Patterns?

2014-02-26 Thread Kevin Squire
On Wednesday, February 26, 2014, Ivar Nesje iva...@gmail.com wrote:

 How is getters/setters - MethodError(b, (a,)) better than direct field
 access - ErrorException(type a has no field b)?

 They seem equivalent to me.


I guess calling them getters and setters might be misleading, but generally
it's a good idea to minimize coupling. Using direct field access deeply
couples the function to the implementation. The function interface reduces
that somewhat.

I may, e.g., want to know the width of a GraphicsDevice. In one
implementation, say PDF output, that might just be a field of a concrete
type. In another, say for a screen, it might be C function call. The
function interface lets us handle both.

 Kevin


 kl. 17:47:32 UTC+1 onsdag 26. februar 2014 skrev Kevin Squire følgende:

 Hello Robert,

 Thanks for posting this question.  This is something I've struggled with
 and attempted to address in a couple of different ways.  I'm not totally
 happy with either of the solutions, but I'll share them in the hope that
 they're useful.

 1. One method you did not mention was to implement everything against an
 abstract base class, but override individual functions for different
 concrete classes.  To avoid depending on the actual type implementation,
 additional functions are defined on the concrete types which give access to
 the data.

 A couple of variations on this include the GraphicsDevice interface in
 Julia (https://github.com/JuliaLang/julia/blob/master/base/
 graphics.jl#L177-L192), and Graphs.jl (http://julialang.org/Graphs.
 jl/interface.html#interface-declaration-and-verification).

 This is a pretty good solution, although how well it works is problem
 dependent.  I've sometimes found it challenging/annoying to design
 getters and setters just to make sure that the functions and types are
 only loosely coupled.

 2. I used your third design pattern when implementing OrderedDicts (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/
 src/ordereddict.jl), and used John Miles White's @delegate macro to
 simplify the code (https://github.com/JuliaLang/
 DataStructures.jl/blob/master/src/delegate.jl).

 The @delegate macro makes the code less cluttered, but has the downside
 in that you don't have access to other/new methods for the wrapped type
 unless you specify them.

 Hope this is useful.  Cheers!

   Kevin


 On Tue, Feb 25, 2014 at 10:44 PM, Robert Feldt robert...@gmail.comwrote:

 I really like Julia's dispatch mechanisms, type system and so on. I have
 found a number of different ways I use it to design libraries and programs.
 But it would be great with some patterns/ideas/feedback from more seasoned
 Julia programmers. What are your Julia Design Patterns?

 A concrete situation that I have struggled somewhat with is how to best
 design in Julia for the situation where I have one main/default
 algorithms/set-of-behaviors+data but then with a multitude of small
 variations. Typically there is a large set of data and methods/functions
 that are the same for the whole class of things and there are only 1-4
 functions/methods that need to change for each variation. An example from
 BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is
 where there is one type for DifferentialEvolution and then multiple
 different variants of DE where only 1-2 functions differ from the base DE
 one.

 I have found a few different design patterns for this situation but
 not sure what is the long-term best:

 1. Have a few Function fields in the base (composite) type which are
 set up at construction time and that implements the variant-specific
 behaviors. This is simple and direct but feels a bit un-Julia since it
 does not really use the dispatch system. One also has to predict the
 variation points (here: function) upfront which might not be flexible
 enough. Also performance might suffer since the types of the function not
 known.

 2. Have one XBase type which includes a field of an abstract XStrategy
 type where specific sub-types to XStrategy implements each variant by
 implementing variant-specific functionality. This seems fairly efficient,
 but again one has to predict more or less where the variations should
 happen since the functions on the XBase type need to call to the XStrategy
 functions.

 3. Have one XBase type which is then included as a field in specific
 variants. This seems efficient and flexible but the code is somewhat
 cluttered in that one has to have one extra indirection when accessing
 common data/fields (this is a similar problem in 2 above though).

 4. Copy the common data/fields of XBase into each specific variant.
 This is the most flexible and should have high performance but there seem
 to be a risk that bugs have to be changed in multile source code locations
 since it is a kind of copy-paste reuse.

 Would be great to hear your advice/feedback on how you design in/with
 the Julia type and dispatch system.

 Thanks,

 Robert Feldt





Re: [julia-users] Julia Design Patterns?

2014-02-26 Thread Kevin Squire
 A couple of variations on this include the GraphicsDevice interface in
 Julia (
 https://github.com/JuliaLang/julia/blob/master/base/graphics.jl#L177-L192),
 and Graphs.jl (
 http://julialang.org/Graphs.jl/interface.html#interface-declaration-and-verification
 ).


Just wanted to be clear that although I use this pattern, Jeff Bezanson
wrote the graphics code, and Dahua Lin wrote the Graph code. I just use
those as good examples and for inspiration!

Cheers, Kevin


Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread Ivar Nesje
We could make people use triple double quotes when their command contains 
single `` cmdrm -rf . / , but that would probably often lead to 
#5800 https://github.com/JuliaLang/julia/issues/5800, when the command 
ends in a ``.

Ivar

kl. 17:13:58 UTC+1 onsdag 26. februar 2014 skrev Stefan Karpinski følgende:

 Yeah, that double quote issue is the main problem. It's pretty common to 
 want to use double quotes in commands, so using double quotes for command 
 syntax would make things much nastier – and very importantly, no longer 
 cut-and-paste from the command line. Code quotation and metaprogramming is 
 a more niche activity than running external commands, so in this showdown, 
 running external commands still takes precedence.


 On Wed, Feb 26, 2014 at 11:06 AM, Cristóvão Duarte Sousa 
 cri...@gmail.comjavascript:
  wrote:

 Stefan, I've wondered if command literals couldn't be created with just a 
 new non-standard string literal, something like ccommand arg1 arg2.
 The only problem I see is that then every double quote mark in the 
 command has to escaped (which will confuse the code though).
 Even if I use the command syntax a lot, sometimes I think that backticks 
 could be used in something else...

 On Wednesday, February 26, 2014 3:44:54 PM UTC, Stefan Karpinski wrote:

 Yes, the backtick is used for command 
 syntaxhttp://docs.julialang.org/en/latest/manual/running-external-programs/.
  
 Sometimes I think it would be really nice to have it for expression quoting 
 since markdown has acclimatized us to using backticks for quoting code, but 
 command syntax is way too handy to steal this from – and its interior 
 interpolation rules are far trickier than normal quotations so you can't 
 just use a normal string construct.


 On Wed, Feb 26, 2014 at 8:57 AM, David Moon dave...@alum.mit.eduwrote:

 I am not suggesting any change to :(x+y) so it would continue to be the 
 same as quote x+y end.  I think that would return 
 Expr(internal_symbol(+, 
 context), internal_symbol(x, context), internal_symbol(y, context)) to 
 use a sketchy syntax that might not actually be valid Julia.

 I like using the ` character for quasiquote as in Lisp but isn't Julia 
 already using ` for something more widely used?


 On Tuesday, February 25, 2014 11:00:32 PM UTC-5, Fil Mackay wrote:

 The semantics of :symbol would not change from the *status quo* under 
 my proposal.

 Perhaps :(x) should be the same as :x rather than the same as quote x 
 end.  Thus if the result of the unary : operator is just a symbol, it is 
 always an external symbol, but the *quote* special form is able to 
 produce just an internal symbol.


 What would :(x+y) produce - invalid or quote x + y end? This inline 
 quote format seems to be used quite a lot and handy. I have wondered 
 about 
 using a different character for symbols and quotes to avoid this 
 ambiguity.





[julia-users] Weird Gadfly Problem

2014-02-26 Thread John Myles White
I have a long IJulia notebook that I’m going to use for a talk tomorrow at UC 
Davis.

At the end, I try to use Gadfly. But I hit a bug that seems to be caused by the 
preceding code as it functions in isolation:

Specifically,

julia plot(iris, x = :SepalLength, y = :SepalWidth, color = :Species, 
Geom.point)

produces this error:

no method 
Distinct{ValueIterator{Dict{Symbol,ScaleElement}}}(ValueIterator{Dict{Symbol,ScaleElement}})
 in render at /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:612
 in writemime at /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:738
 in sprint at io.jl:468
 in display_dict at 
/Users/johnmyleswhite/.julia/v0.3/IJulia/src/execute_request.jl:35

Any thoughts on what’s happening?

 — John



Re: [julia-users] Julia Design Patterns?

2014-02-26 Thread andrew cooke
the getters/setters issue will be fixed by 
https://github.com/JuliaLang/julia/issues/4935 which i think makes 1 a nice 
solution in many cases.

unfortunately interest in that issue seemed to die when (i think?) there 
was no consensus on the details.

andrew


On Wednesday, 26 February 2014 14:03:27 UTC-3, Robert Feldt wrote:

 Hi Kevin,

 Thanks for your input. You are right, I did forget about your method 1 
 which I've also used at times. It does feel a bit annoying but I can't 
 describe why; maybe it's an (unfounded) concern that performance is 
 hampered but I guess there will be almost zero effect of that in practice 
 given Julia's backend and optimizations in LLVM. Maybe we can address the 
 getters and setters issue with a simple macro? Hmm...

 There seems to be discussions about the possibility to override the dot 
 operator / field access which allow for a lot of flexibility if added:
 https://github.com/JuliaLang/julia/issues/1974

 Cheers,

 /Robert

 Den onsdagen den 26:e februari 2014 kl. 17:47:32 UTC+1 skrev Kevin Squire:

 Hello Robert, 

 Thanks for posting this question.  This is something I've struggled with 
 and attempted to address in a couple of different ways.  I'm not totally 
 happy with either of the solutions, but I'll share them in the hope that 
 they're useful.

 1. One method you did not mention was to implement everything against an 
 abstract base class, but override individual functions for different 
 concrete classes.  To avoid depending on the actual type implementation, 
 additional functions are defined on the concrete types which give access to 
 the data.

 A couple of variations on this include the GraphicsDevice interface in 
 Julia (
 https://github.com/JuliaLang/julia/blob/master/base/graphics.jl#L177-L192), 
 and Graphs.jl (
 http://julialang.org/Graphs.jl/interface.html#interface-declaration-and-verification
 ).

 This is a pretty good solution, although how well it works is problem 
 dependent.  I've sometimes found it challenging/annoying to design 
 getters and setters just to make sure that the functions and types are 
 only loosely coupled.

 2. I used your third design pattern when implementing OrderedDicts (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/ordereddict.jl),
  
 and used John Miles White's @delegate macro to simplify the code (
 https://github.com/JuliaLang/DataStructures.jl/blob/master/src/delegate.jl). 
  

 The @delegate macro makes the code less cluttered, but has the downside 
 in that you don't have access to other/new methods for the wrapped type 
 unless you specify them.

 Hope this is useful.  Cheers!

   Kevin


 On Tue, Feb 25, 2014 at 10:44 PM, Robert Feldt robert...@gmail.comwrote:

 I really like Julia's dispatch mechanisms, type system and so on. I have 
 found a number of different ways I use it to design libraries and programs. 
 But it would be great with some patterns/ideas/feedback from more seasoned 
 Julia programmers. What are your Julia Design Patterns?

 A concrete situation that I have struggled somewhat with is how to best 
 design in Julia for the situation where I have one main/default 
 algorithms/set-of-behaviors+data but then with a multitude of small 
 variations. Typically there is a large set of data and methods/functions 
 that are the same for the whole class of things and there are only 1-4 
 functions/methods that need to change for each variation. An example from 
 BlackBoxOptim ( https://github.com/robertfeldt/BlackBoxOptim.jl ) is 
 where there is one type for DifferentialEvolution and then multiple 
 different variants of DE where only 1-2 functions differ from the base DE 
 one. 

 I have found a few different design patterns for this situation but 
 not sure what is the long-term best:

 1. Have a few Function fields in the base (composite) type which are 
 set up at construction time and that implements the variant-specific 
 behaviors. This is simple and direct but feels a bit un-Julia since it 
 does not really use the dispatch system. One also has to predict the 
 variation points (here: function) upfront which might not be flexible 
 enough. Also performance might suffer since the types of the function not 
 known.

 2. Have one XBase type which includes a field of an abstract XStrategy 
 type where specific sub-types to XStrategy implements each variant by 
 implementing variant-specific functionality. This seems fairly efficient, 
 but again one has to predict more or less where the variations should 
 happen since the functions on the XBase type need to call to the XStrategy 
 functions.

 3. Have one XBase type which is then included as a field in specific 
 variants. This seems efficient and flexible but the code is somewhat 
 cluttered in that one has to have one extra indirection when accessing 
 common data/fields (this is a similar problem in 2 above though).

 4. Copy the common data/fields of XBase into each specific variant. 
 This is the most flexible 

[julia-users] Re: Weird Gadfly Problem

2014-02-26 Thread Daniel Jones
Could Distinct be defined somewhere interfering with the definition in 
Iterators?

On Wednesday, February 26, 2014 9:28:32 AM UTC-8, John Myles White wrote:

 I have a long IJulia notebook that I’m going to use for a talk tomorrow at 
 UC Davis. 

 At the end, I try to use Gadfly. But I hit a bug that seems to be caused 
 by the preceding code as it functions in isolation: 

 Specifically, 

 julia plot(iris, x = :SepalLength, y = :SepalWidth, color = :Species, 
 Geom.point) 

 produces this error: 

 no method 
 Distinct{ValueIterator{Dict{Symbol,ScaleElement}}}(ValueIterator{Dict{Symbol,ScaleElement}})
  

  in render at /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:612 
  in writemime at 
 /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:738 
  in sprint at io.jl:468 
  in display_dict at 
 /Users/johnmyleswhite/.julia/v0.3/IJulia/src/execute_request.jl:35 

 Any thoughts on what’s happening? 

  — John 



Re: [julia-users] Re: Weird Gadfly Problem

2014-02-26 Thread John Myles White
I suspect so, but I got a no methods error when I tried looking it up. Let me 
try to make a condensed test case that loads all of the packages I’m using.

 — John
 
On Feb 26, 2014, at 9:35 AM, Daniel Jones danielcjo...@gmail.com wrote:

 Could Distinct be defined somewhere interfering with the definition in 
 Iterators?
 
 On Wednesday, February 26, 2014 9:28:32 AM UTC-8, John Myles White wrote:
 I have a long IJulia notebook that I’m going to use for a talk tomorrow at UC 
 Davis. 
 
 At the end, I try to use Gadfly. But I hit a bug that seems to be caused by 
 the preceding code as it functions in isolation: 
 
 Specifically, 
 
 julia plot(iris, x = :SepalLength, y = :SepalWidth, color = :Species, 
 Geom.point) 
 
 produces this error: 
 
 no method 
 Distinct{ValueIterator{Dict{Symbol,ScaleElement}}}(ValueIterator{Dict{Symbol,ScaleElement}})
  
  in render at /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:612 
  in writemime at /Users/johnmyleswhite/.julia/v0.3/Gadfly/src/Gadfly.jl:738 
  in sprint at io.jl:468 
  in display_dict at 
 /Users/johnmyleswhite/.julia/v0.3/IJulia/src/execute_request.jl:35 
 
 Any thoughts on what’s happening? 
 
  — John 
 



Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread Keith Campbell
... and make Julia to  what regex is to /\  

/\/\/.*|\/\*[\w]*\*\/  

Ack

On Wednesday, February 26, 2014 12:27:55 PM UTC-5, Ivar Nesje wrote:

 We could make people use triple double quotes when their command contains 
 single `` cmdrm -rf . / , but that would probably often lead to 
 #5800 https://github.com/JuliaLang/julia/issues/5800, when the command 
 ends in a ``.

 Ivar

 kl. 17:13:58 UTC+1 onsdag 26. februar 2014 skrev Stefan Karpinski følgende:

 Yeah, that double quote issue is the main problem. It's pretty common to 
 want to use double quotes in commands, so using double quotes for command 
 syntax would make things much nastier – and very importantly, no longer 
 cut-and-paste from the command line. Code quotation and metaprogramming is 
 a more niche activity than running external commands, so in this showdown, 
 running external commands still takes precedence.


 On Wed, Feb 26, 2014 at 11:06 AM, Cristóvão Duarte Sousa 
 cri...@gmail.com wrote:

 Stefan, I've wondered if command literals couldn't be created with just 
 a new non-standard string literal, something like ccommand arg1 arg2.
 The only problem I see is that then every double quote mark in the 
 command has to escaped (which will confuse the code though).
 Even if I use the command syntax a lot, sometimes I think that backticks 
 could be used in something else...

 On Wednesday, February 26, 2014 3:44:54 PM UTC, Stefan Karpinski wrote:

 Yes, the backtick is used for command 
 syntaxhttp://docs.julialang.org/en/latest/manual/running-external-programs/.
  
 Sometimes I think it would be really nice to have it for expression 
 quoting 
 since markdown has acclimatized us to using backticks for quoting code, 
 but 
 command syntax is way too handy to steal this from – and its interior 
 interpolation rules are far trickier than normal quotations so you can't 
 just use a normal string construct.


 On Wed, Feb 26, 2014 at 8:57 AM, David Moon dave...@alum.mit.eduwrote:

 I am not suggesting any change to :(x+y) so it would continue to be 
 the same as quote x+y end.  I think that would return 
 Expr(internal_symbol(+, context), internal_symbol(x, context), 
 internal_symbol(y, context)) to use a sketchy syntax that might not 
 actually be valid Julia.

 I like using the ` character for quasiquote as in Lisp but isn't Julia 
 already using ` for something more widely used?


 On Tuesday, February 25, 2014 11:00:32 PM UTC-5, Fil Mackay wrote:

 The semantics of :symbol would not change from the *status quo*under my 
 proposal.

 Perhaps :(x) should be the same as :x rather than the same as quote 
 x end.  Thus if the result of the unary : operator is just a symbol, it 
 is 
 always an external symbol, but the *quote* special form is able to 
 produce just an internal symbol.


 What would :(x+y) produce - invalid or quote x + y end? This inline 
 quote format seems to be used quite a lot and handy. I have wondered 
 about 
 using a different character for symbols and quotes to avoid this 
 ambiguity.





Re: [julia-users] Re: What is a Number?

2014-02-26 Thread Leah Hanson
The % coverage part is done. You can see the documentation at
https://github.com/astrieanna/TypeCheck.jl#methodswithdescendantstdatatypeonlyleavesboolfalselimint10(anchor
in the README). Please try it out and let me know whether it's
helpful. (Note that abstract types are  included by default; using
onlyleaves=true to get your requested behavior.)

Usage statistics are definitely harder, but only because finding uses of a
function in general is harder. I'll think about that a bit more;
check_method_calls might have some of the needed infrastructure of that.

Comparing types could be accomplished with a wrapper on the new
methodswithdescendants function; I can add that.

-- Leah


On Tue, Feb 25, 2014 at 4:26 PM, andrew cooke and...@acooke.org wrote:


 sweet.  i'd like to see something like % coverage. for Number, for
 example, what % of concrete types have abs() defined?

 another useful statistic, which might not be possible, is across how many
 modules is a function used - for example, which operation on Number occurs
 in most modules?  which are used only in one module?

 it would also be nice if you could compare types - what functions does
 Integer (or sub types) have, that my type does not?

 and ponies!

 cheers, andrew

 ps i just looked at TypeCheck.  check_loop_types is going to be sooo
 useful



 On Tuesday, 25 February 2014 20:13:07 UTC-3, Leah Hanson wrote:

 I'm planning to add a which methods are defined for subtypes of this
 type function to TypeCheck.jl this week. If there's any specific behavior
 you want it to have, let me know. :)

 -- Leah


 On Tue, Feb 25, 2014 at 2:52 PM, David Moon dave...@alum.mit.edu wrote:

 On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:


 The advantage of making it an explicit concept in the language, rather
 than just defining a method that signals an error, is that it can be
 checked at compile time.


 In Julia, compile time is load time.  Specifically, after evaluating a
 top-level expression (which may have loaded a whole lot of files) check
 each newly defined datatype or bitstype to see if there are any required
 methods that involve that type or its supertypes.  If so, check if an
 instance of the newly defined type would have all the required methods
 applicable to it in the appropriate argument position.





[julia-users] conversion Vector{Vector{T}} - Matrix{T}

2014-02-26 Thread Alex
Hi together,

It seems to be quite natural to try converting Vector{Vector{T}} into 
Matrix{T} or vice versa. Is this conversion problematic in some way? What 
would be an efficient way to achieve it?

As a first attempt I would do
y = [[i,i] for i=1:3]

mat = Array(eltype(y[1]),length(y),length(y[1]))

for i=1:length(y)
mat[i,:] = y[i]
end

to get the matrix. And

v = vcat(Vector{eltype(mat[1,1])}[mat[i,:][:] for i=1:size(mat,1)])

I am sure there are more elegant ways of doing this.

Thanks!

- Alex.



[julia-users] Re: conversion Vector{Vector{T}} - Matrix{T}

2014-02-26 Thread Ivar Nesje
julia a = [[1:10] for i in 1:5]
5-element Array{Array{Int64,1},1}:
 [1,2,3,4,5,6,7,8,9,10]
 [1,2,3,4,5,6,7,8,9,10]
 [1,2,3,4,5,6,7,8,9,10]
 [1,2,3,4,5,6,7,8,9,10]
 [1,2,3,4,5,6,7,8,9,10]

julia hcat(a...)
10x5 Array{Int64,2}:
  1   1   1   1   1
  2   2   2   2   2
  3   3   3   3   3
  4   4   4   4   4
  5   5   5   5   5
  6   6   6   6   6
  7   7   7   7   7
  8   8   8   8   8
  9   9   9   9   9
 10  10  10  10  10

kl. 20:01:59 UTC+1 onsdag 26. februar 2014 skrev Alex følgende:

 Hi together,

 It seems to be quite natural to try converting Vector{Vector{T}} into 
 Matrix{T} or vice versa. Is this conversion problematic in some way? What 
 would be an efficient way to achieve it?

 As a first attempt I would do
 y = [[i,i] for i=1:3]

 mat = Array(eltype(y[1]),length(y),length(y[1]))

 for i=1:length(y)
 mat[i,:] = y[i]
 end

 to get the matrix. And

 v = vcat(Vector{eltype(mat[1,1])}[mat[i,:][:] for i=1:size(mat,1)])

 I am sure there are more elegant ways of doing this.

 Thanks!

 - Alex.



[julia-users] Re: conversion Vector{Vector{T}} - Matrix{T}

2014-02-26 Thread Alex
Thanks Ivar! I also just found this thread

https://groups.google.com/forum/#!searchin/julia-users/convert$20Matrix/julia-users/wzaJw_FfNlA/HzPWOzcfydkJ

which already covered my questions.

Best,
Alex.


Re: [julia-users] Parallel Computing : How to kill a remote reference ?

2014-02-26 Thread Tim Holy
I'm not sure I understand what you mean by killing a remote reference. A RR 
is a reference to an object (i.e., a variable) in another process, so there 
isn't anything to kill. You can delete the entire process with rmprocs.

If you mean you want to interrupt execution of another process, the only 
approach I know of is to have some variable that gets checked periodically for 
whether the computation should continue. You can use a remote reference so one 
process can check the value of the variable in a different process.

--Tim

On Wednesday, February 26, 2014 05:59:13 AM KS wrote:
 Hi,
 
 I need to start and stop the same process. For example when I start a
 process and I get a RemoteRef(2,1,16) how can i kill it or stop it ?
 
 Thank you in advance.
 
 KS


[julia-users] Re: Help getting started with Julia's Graphs package

2014-02-26 Thread Uwe Korn


On Wednesday, 26 February 2014 13:06:29 UTC, Ed Scheinerman wrote:

 But if I want to add an additional vertex, I get trouble:

 julia add_vertex!(g,5)
 ERROR: no method push!(Range1{Int64},Int64)
  in add_vertex! at /home/ers/.julia/Graphs/src/graph.jl:50


This is because SimpleGraph is using a Range1{Int64} as the container of 
its vertices which cannot be modified using push!.

I opened a pull request that should make SimpleGraph editable: 
https://github.com/JuliaLang/Graphs.jl/pull/59


Re: [julia-users] NoDecodeDelegateForThisImageFormat

2014-02-26 Thread Isaiah Norton
What kind of image are you trying to read? That the error message is
ImageMagick saying I don't know how to read this format. I would guess
that the Homebrew ImageMagick build may include a few basic formats (the
I.M. format support depends on other libraries, each of which needs a
recipe in turn).


On Wed, Feb 26, 2014 at 4:10 PM, Eric Portman eport...@alum.mit.edu wrote:

 Hi all -

 Newbie to Julia.  Running on OS X 10.9.2.  Julia v0.3. (Though had similar
 issue on 0.2).

 Having issues with using Images package.  I am getting the following error
 when attempting to do imread:

 *ERROR: NoDecodeDelegateForThisImageFormat `snipped filename' @
 error/constitute.c/ReadImage/555*

 * in error at error.jl:21*

 * in error at
 /Users/eportman/.julia/v0.3/Images/src/ioformats/libmagickwand.jl:111*

 * in readimage at
 /Users/eportman/.julia/v0.3/Images/src/ioformats/libmagickwand.jl:178*

 * in imread at /Users/eportman/.julia/v0.3/Images/src/io.jl:192*

 * in imread at /Users/eportman/.julia/v0.3/Images/src/io.jl:104*



 I thought it was an issue with ImageMagick installation, but it appears to
 be installing correctly as part of the Images package add.


 Any ideas on what I am doing wrong/need to try next?


 Thanks in advance for any help



Re: [julia-users] NoDecodeDelegateForThisImageFormat

2014-02-26 Thread Tim Holy
Can you email me the image file you're testing, and the exact command you're 
using to read it?

--Tim

On Wednesday, February 26, 2014 01:10:40 PM Eric Portman wrote:
 Hi all -
 
 Newbie to Julia.  Running on OS X 10.9.2.  Julia v0.3. (Though had similar
 issue on 0.2).
 
 Having issues with using Images package.  I am getting the following error
 when attempting to do imread:
 
 *ERROR: NoDecodeDelegateForThisImageFormat `snipped filename' @
 error/constitute.c/ReadImage/555*
 
 * in error at error.jl:21*
 
 * in error at
 /Users/eportman/.julia/v0.3/Images/src/ioformats/libmagickwand.jl:111*
 
 * in readimage at
 /Users/eportman/.julia/v0.3/Images/src/ioformats/libmagickwand.jl:178*
 
 * in imread at /Users/eportman/.julia/v0.3/Images/src/io.jl:192*
 
 * in imread at /Users/eportman/.julia/v0.3/Images/src/io.jl:104*
 
 
 
 I thought it was an issue with ImageMagick installation, but it appears to
 be installing correctly as part of the Images package add.
 
 
 Any ideas on what I am doing wrong/need to try next?
 
 
 Thanks in advance for any help


Re: [julia-users] Re: What is a Number?

2014-02-26 Thread andrew cooke
this is great.  from just looking at the example in the docs i can see i've 
missed a couple of methods!  thanks.

On Wednesday, 26 February 2014 15:54:07 UTC-3, Leah Hanson wrote:

 The % coverage part is done. You can see the documentation at 
 https://github.com/astrieanna/TypeCheck.jl#methodswithdescendantstdatatypeonlyleavesboolfalselimint10(anchor
  in the README). Please try it out and let me know whether it's 
 helpful. (Note that abstract types are  included by default; using 
 onlyleaves=true to get your requested behavior.)

 Usage statistics are definitely harder, but only because finding uses of a 
 function in general is harder. I'll think about that a bit more; 
 check_method_calls might have some of the needed infrastructure of that.

 Comparing types could be accomplished with a wrapper on the new 
 methodswithdescendants function; I can add that.

 -- Leah


 On Tue, Feb 25, 2014 at 4:26 PM, andrew cooke and...@acooke.orgjavascript:
  wrote:


 sweet.  i'd like to see something like % coverage. for Number, for 
 example, what % of concrete types have abs() defined?

 another useful statistic, which might not be possible, is across how many 
 modules is a function used - for example, which operation on Number occurs 
 in most modules?  which are used only in one module?

 it would also be nice if you could compare types - what functions does 
 Integer (or sub types) have, that my type does not?

 and ponies!

 cheers, andrew

 ps i just looked at TypeCheck.  check_loop_types is going to be sooo 
 useful



 On Tuesday, 25 February 2014 20:13:07 UTC-3, Leah Hanson wrote:

 I'm planning to add a which methods are defined for subtypes of this 
 type function to TypeCheck.jl this week. If there's any specific behavior 
 you want it to have, let me know. :)

 -- Leah


 On Tue, Feb 25, 2014 at 2:52 PM, David Moon dave...@alum.mit.eduwrote:

 On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:


 The advantage of making it an explicit concept in the language, rather 
 than just defining a method that signals an error, is that it can be 
 checked at compile time.


 In Julia, compile time is load time.  Specifically, after evaluating a 
 top-level expression (which may have loaded a whole lot of files) check 
 each newly defined datatype or bitstype to see if there are any required 
 methods that involve that type or its supertypes.  If so, check if an 
 instance of the newly defined type would have all the required methods 
 applicable to it in the appropriate argument position.





Re: [julia-users] Re: What is a Number?

2014-02-26 Thread Leah Hanson
If onlyleaves=true, then only results from concrete types are considered.
By default, onlyleaves=false, so all subtypes/descendants are included.
So, onlyleaves=true considers a subset of descendants.

The resulting list of functions would not change if all methods happened to
be implemented only on the concrete types. Also, the list is the lim=10
most popular functions, so onlyleaves=true does not need to be a subset of
onlyleaves=false: the top ten only considering the concrete types might be
entirely different from the top ten considering all descendent types.

Does this make it clearer?

-- Leah


On Wed, Feb 26, 2014 at 4:11 PM, andrew cooke and...@acooke.org wrote:


 hang on...  what does onlyleaves do?  when true should the results be a
 subset of the the results when it's false?  they are not, in the examples
 in the doc.  :o(


 On Wednesday, 26 February 2014 19:25:06 UTC-3, andrew cooke wrote:

 this is great.  from just looking at the example in the docs i can see
 i've missed a couple of methods!  thanks.

 On Wednesday, 26 February 2014 15:54:07 UTC-3, Leah Hanson wrote:

 The % coverage part is done. You can see the documentation at
 https://github.com/astrieanna/TypeCheck.jl#
 methodswithdescendantstdatatypeonlyleavesboolfalselimint10 (anchor in
 the README). Please try it out and let me know whether it's helpful. (Note
 that abstract types are  included by default; using onlyleaves=true to get
 your requested behavior.)

 Usage statistics are definitely harder, but only because finding uses of
 a function in general is harder. I'll think about that a bit more;
 check_method_calls might have some of the needed infrastructure of that.

 Comparing types could be accomplished with a wrapper on the new
 methodswithdescendants function; I can add that.

 -- Leah


 On Tue, Feb 25, 2014 at 4:26 PM, andrew cooke and...@acooke.org wrote:


 sweet.  i'd like to see something like % coverage. for Number, for
 example, what % of concrete types have abs() defined?

 another useful statistic, which might not be possible, is across how
 many modules is a function used - for example, which operation on Number
 occurs in most modules?  which are used only in one module?

 it would also be nice if you could compare types - what functions does
 Integer (or sub types) have, that my type does not?

 and ponies!

 cheers, andrew

 ps i just looked at TypeCheck.  check_loop_types is going to be sooo
 useful



 On Tuesday, 25 February 2014 20:13:07 UTC-3, Leah Hanson wrote:

 I'm planning to add a which methods are defined for subtypes of this
 type function to TypeCheck.jl this week. If there's any specific behavior
 you want it to have, let me know. :)

 -- Leah


 On Tue, Feb 25, 2014 at 2:52 PM, David Moon dave...@alum.mit.eduwrote:

 On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:


 The advantage of making it an explicit concept in the language,
 rather than just defining a method that signals an error, is that it 
 can be
 checked at compile time.


 In Julia, compile time is load time.  Specifically, after evaluating
 a top-level expression (which may have loaded a whole lot of files) check
 each newly defined datatype or bitstype to see if there are any required
 methods that involve that type or its supertypes.  If so, check if an
 instance of the newly defined type would have all the required methods
 applicable to it in the appropriate argument position.






Re: [julia-users] Error: Index not defined issuing simple queries to Amazon Redshift

2014-02-26 Thread John Myles White
ODBC is probably expecting to interact with an older version of DataFrames when 
Index was being exported.

 — John

On Feb 26, 2014, at 4:40 PM, Dan B danbar...@gmail.com wrote:

 Friends,
 
 I'm getting the following when trying to issue simple queries to Redshift 
 over an ODBC connection- 
 
 julia results = query(SELECT details from auditrecord WHERE id='44');
 elapsed time: 3.211e-5 seconds
 ERROR: Index not defined
  in ODBCFetchDataFrame at /home/ubuntu/.julia/v0.3/ODBC/src/backend.jl:185
  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:57
  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:43
 
 Redshift doesn't have indexes by nature... but Im hoping it's not something 
 as obvious as this because I've seen examples of people using Julia with 
 Redshift.  Any thoughts?
 
 Thanks in advance,
 
 - - Dan



Re: [julia-users] Re: What is a Number?

2014-02-26 Thread andrew cooke

yeah, sorry.  i realised i'd missed len=10 just after i posted and tried to 
delete, but apparently wasn't quick enough.  andrew

On Wednesday, 26 February 2014 21:37:24 UTC-3, Leah Hanson wrote:

 If onlyleaves=true, then only results from concrete types are 
 considered. By default, onlyleaves=false, so all subtypes/descendants are 
 included. So, onlyleaves=true considers a subset of descendants.

 The resulting list of functions would not change if all methods happened 
 to be implemented only on the concrete types. Also, the list is the lim=10 
 most popular functions, so onlyleaves=true does not need to be a subset of 
 onlyleaves=false: the top ten only considering the concrete types might be 
 entirely different from the top ten considering all descendent types.

 Does this make it clearer?

 -- Leah


 On Wed, Feb 26, 2014 at 4:11 PM, andrew cooke and...@acooke.orgjavascript:
  wrote:


 hang on...  what does onlyleaves do?  when true should the results be a 
 subset of the the results when it's false?  they are not, in the examples 
 in the doc.  :o(


 On Wednesday, 26 February 2014 19:25:06 UTC-3, andrew cooke wrote:

 this is great.  from just looking at the example in the docs i can see 
 i've missed a couple of methods!  thanks.

 On Wednesday, 26 February 2014 15:54:07 UTC-3, Leah Hanson wrote:

 The % coverage part is done. You can see the documentation at 
 https://github.com/astrieanna/TypeCheck.jl#
 methodswithdescendantstdatatypeonlyleavesboolfalselimint10 (anchor in 
 the README). Please try it out and let me know whether it's helpful. (Note 
 that abstract types are  included by default; using onlyleaves=true to get 
 your requested behavior.)

 Usage statistics are definitely harder, but only because finding uses 
 of a function in general is harder. I'll think about that a bit more; 
 check_method_calls might have some of the needed infrastructure of that.

 Comparing types could be accomplished with a wrapper on the new 
 methodswithdescendants function; I can add that.

 -- Leah


 On Tue, Feb 25, 2014 at 4:26 PM, andrew cooke and...@acooke.orgwrote:


 sweet.  i'd like to see something like % coverage. for Number, for 
 example, what % of concrete types have abs() defined?

 another useful statistic, which might not be possible, is across how 
 many modules is a function used - for example, which operation on Number 
 occurs in most modules?  which are used only in one module?

 it would also be nice if you could compare types - what functions does 
 Integer (or sub types) have, that my type does not?

 and ponies!

 cheers, andrew

 ps i just looked at TypeCheck.  check_loop_types is going to be sooo 
 useful



 On Tuesday, 25 February 2014 20:13:07 UTC-3, Leah Hanson wrote:

 I'm planning to add a which methods are defined for subtypes of this 
 type function to TypeCheck.jl this week. If there's any specific 
 behavior 
 you want it to have, let me know. :)

 -- Leah


 On Tue, Feb 25, 2014 at 2:52 PM, David Moon dave...@alum.mit.eduwrote:

 On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:


 The advantage of making it an explicit concept in the language, 
 rather than just defining a method that signals an error, is that it 
 can be 
 checked at compile time.


 In Julia, compile time is load time.  Specifically, after evaluating 
 a top-level expression (which may have loaded a whole lot of files) 
 check 
 each newly defined datatype or bitstype to see if there are any 
 required 
 methods that involve that type or its supertypes.  If so, check if an 
 instance of the newly defined type would have all the required methods 
 applicable to it in the appropriate argument position.






Re: [julia-users] Error: Index not defined issuing simple queries to Amazon Redshift

2014-02-26 Thread Jacob Quinn
Indeed. I've been meaning to try and update this soon. For now, doing

Pkg.pin(DataFrames,v0.5)

works for me.

-Jacob


On Wed, Feb 26, 2014 at 7:43 PM, John Myles White
johnmyleswh...@gmail.comwrote:

 ODBC is probably expecting to interact with an older version of DataFrames
 when Index was being exported.

  -- John

 On Feb 26, 2014, at 4:40 PM, Dan B danbar...@gmail.com wrote:

 Friends,

 I'm getting the following when trying to issue simple queries to Redshift
 over an ODBC connection-

 julia results = query(SELECT details from auditrecord WHERE id='44');

 elapsed time: 3.211e-5 seconds

 ERROR: Index not defined

  in ODBCFetchDataFrame at /home/ubuntu/.julia/v0.3/ODBC/src/backend.jl:185

  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:57

  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:43

 Redshift doesn't have indexes by nature... but Im hoping it's not
 something as obvious as this because I've seen examples of people using
 Julia with Redshift.  Any thoughts?

 Thanks in advance,

 - - Dan





Re: [julia-users] Re: Error: Index not defined issuing simple queries to Amazon Redshift

2014-02-26 Thread John Myles White
If you’re up to it, doing a search-replace in ODBC.jl to replace Index with 
DataFrames.Index should be sufficient.

 — John

On Feb 26, 2014, at 4:58 PM, Dan B danbar...@gmail.com wrote:

 John,
 
 Any ideas on a course of action?  If true, I imagine simply downgrading 
 DataFrames isn't going to work, or necessarily be a good idea? :)
 
 On Wednesday, February 26, 2014 4:40:31 PM UTC-8, Dan B wrote:
 Friends,
 
 I'm getting the following when trying to issue simple queries to Redshift 
 over an ODBC connection- 
 
 julia results = query(SELECT details from auditrecord WHERE id='44');
 elapsed time: 3.211e-5 seconds
 ERROR: Index not defined
  in ODBCFetchDataFrame at /home/ubuntu/.julia/v0.3/ODBC/src/backend.jl:185
  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:57
  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:43
 
 Redshift doesn't have indexes by nature... but Im hoping it's not something 
 as obvious as this because I've seen examples of people using Julia with 
 Redshift.  Any thoughts?
 
 Thanks in advance,
 
 - - Dan



[julia-users] Re: Error: Index not defined issuing simple queries to Amazon Redshift

2014-02-26 Thread Dan B
Thanks for the help guys!  Jacob, pinning the package solved the problem 
for me.  

Thanks for the solution, and the ultra-fast response.

Best Regards,

- - Dan

On Wednesday, February 26, 2014 4:40:31 PM UTC-8, Dan B wrote:

 Friends,

 I'm getting the following when trying to issue simple queries to Redshift 
 over an ODBC connection- 

 julia results = query(SELECT details from auditrecord WHERE id='44');

 elapsed time: 3.211e-5 seconds

 ERROR: Index not defined

  in ODBCFetchDataFrame at /home/ubuntu/.julia/v0.3/ODBC/src/backend.jl:185

  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:57

  in query at /home/ubuntu/.julia/v0.3/ODBC/src/userfacing.jl:43

 Redshift doesn't have indexes by nature... but Im hoping it's not 
 something as obvious as this because I've seen examples of people using 
 Julia with Redshift.  Any thoughts?

 Thanks in advance,

 - - Dan



Re: [julia-users] Re: Seeing Segmentation Fault

2014-02-26 Thread Michael Schnall-Levin
so, this behavior is incredibly strange.  it happens inconsistently in
code.  e.g. if i run the same code twice, one time it may seg fault and the
next it will complete successfully w/o any environmental changes in
between.  i will try to make clean and see if it stops happneing, but it's
a little hard to say definitively right after i do that b/c the behavior is
non-deterministic.

i'd really like to provide the code that produces this error, but there's
some proprietary information in there, so i cannot share it right now.

the only other information i can give is that the code is not particularly
long-running (~10-20 minutes).


On Tue, Feb 25, 2014 at 7:02 PM, Tim Holy tim.h...@gmail.com wrote:

 Try a make clean; make first, and if that doesn't fix it, please submit
 your
 test script to #5106; we could really use a reproducible test case for
 this!

 --Tim

 On Tuesday, February 25, 2014 04:24:07 PM Joey Huchette wrote:
  Looks superficially similar
  to https://github.com/JuliaLang/julia/issues/5106
 
  On Tuesday, February 25, 2014 6:02:55 PM UTC-5, Michael Schnall-Levin
 wrote:
   Hello,
  
   I'm seeing a segmentation fault while running julia code.  I got it to
   reproduce multiple times on a small script that I'm running.
  
   The only error message I got was below.
  
   I'm running julia 0.3.0-prerelease+1564 on Ubuntu 12.04.
  
   Any help is very appreciated.
  
   Thanks, Mike
  
  
   -- Errror Messsage 
  
   fatal: error thrown and no exception handler available.
  
   Base.MethodError(f=Base.Enumerate{I},
  
  

 args=((?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?:
  
 :?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::
  
 :?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?
  
 :::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?:
   ::?::?::?::?:
   :
   :
  
 :?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::
  
 :?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?
  
 :::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?:
   ::?::?::?::?:
  

 :?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?::?:
   .. (this continues for more lines) ..
  
   :?::?::?::?::?::?::?::?::?::?::?::?::?::?::Segmentation
  
   fault (core dumped)



Re: [julia-users] obtaining what used to be returned by showcompact(fp::Float64)

2014-02-26 Thread Jeff Bezanson
Sorry about that; the function is back to normal now. `round` is also
useful for showing specific numbers of digits.


On Tue, Feb 25, 2014 at 4:51 PM, Douglas Bates dmba...@gmail.com wrote:
 With the addition of _output_limit in base/show.jl ,showcompact(float(pi))
 in the REPL has reverted to showing 3.141592653589793.  Until recently it
 would display 3.14159

 I have been using `showcompact` when printing out verbose information on the
 iteration progress in optimization algorithms.  Any suggestions on how to
 display a Float64 to, say, 6 significant digits?



[julia-users] Function matching

2014-02-26 Thread Fil Mackay
type A{T}
end

function f{T}(a::A{T}, v::T)
end

a = A{Number}()
f(a, 3)

#no method f(A{Number}, Int64)
#while loading In[4], in expression starting on line 7


Is there a reason why the Int64 parameter does not get accepted as a Number in 
the above? Especially when this method is accepted by the match:


function f(a::A{Number}, v::Number)
println($a $v)
end


f(a,3)

# no errors




Re: [julia-users] Function matching

2014-02-26 Thread John Myles White
I think this doesn’t work because matching gets done by exact types, not 
subtypes.

 — John

On Feb 26, 2014, at 9:39 PM, Fil Mackay f...@vertigotechnology.com wrote:

 type A{T}
 end
 
 function f{T}(a::A{T}, v::T)
 end
 
 a = A{Number}()
 f(a, 3)
 #no method f(A{Number}, Int64)
 #while loading In[4], in expression starting on line 7
 
 Is there a reason why the Int64 parameter does not get accepted as a Number 
 in the above? Especially when this method is accepted by the match:
 
 function f(a::A{Number}, v::Number)
 println($a $v)
 end
 
 f(a,3)
 # no errors
 



Re: [julia-users] Function matching

2014-02-26 Thread Fil Mackay
On Thursday, February 27, 2014 4:44:26 PM UTC+11, John Myles White wrote:

 I think this doesn’t work because matching gets done by exact types, not 
 subtypes.


But it does work via subtypes on the non-parametric version. Seems to be a 
difference between that and the parametric?



[julia-users] Default instance of intrinsic type

2014-02-26 Thread Fil Mackay
Is there an easy way, given a particular intrinsic Type, to create a 
default (zero) instance? eg.

z(Int64)
# 0::Int64

z(ASCIIString)
# ::ASCIIString

Akin to the C# default 
keywordhttp://msdn.microsoft.com/en-us/library/xwth0h0d.aspx, 
that returns the default initialised value of any type.



Re: [julia-users] Function matching

2014-02-26 Thread John Myles White
Yeah, the non-parametric version doesn’t introduce implicit type parameters. 
Once you introduce explicit type parameters, you’re effectively imposing a 
constraint about exact matching of types.

I think something like this might work, but am not totally sure:

function f{S : Number, T : S}(a::A{S}, v::T)
...
end

 — John

On Feb 26, 2014, at 10:22 PM, Fil Mackay f...@vertigotechnology.com wrote:

 On Thursday, February 27, 2014 4:44:26 PM UTC+11, John Myles White wrote:
 I think this doesn’t work because matching gets done by exact types, not 
 subtypes.
 
 But it does work via subtypes on the non-parametric version. Seems to be a 
 difference between that and the parametric?
 



Re: [julia-users] Hygienic macros could be both better and simpler

2014-02-26 Thread Fil Mackay
Yep - was wondering if we could move command syntax :)

We need some more pair sets ()  {} [] in the charset that allow nesting. 
The problem with `  ' is that they're unpaired and require escaping on 
nesting.. is the keyboard layout on github?

What about using triple back-tick for quoting: ```a+b``` (just like 
markdown).



Re: [julia-users] Function matching

2014-02-26 Thread Fil Mackay
On Thursday, February 27, 2014 5:26:31 PM UTC+11, John Myles White wrote:

 Yeah, the non-parametric version doesn’t introduce implicit type 
 parameters. Once you introduce explicit type parameters, you’re effectively 
 imposing a constraint about exact matching of types.

 I think something like this might work, but am not totally sure:

 function f{S : Number, T : S}(a::A{S}, v::T)
 ...
 end


This is triangular dispatch.. as I recently 
learnedhttps://groups.google.com/forum/#!msg/julia-users/n0GZi0lBryE/usRZ771cwl4J.
 
Not supported yet, and the thing I was trying to avoid :)

Unfortunately I'm used to doing a lot of this in static compile contexts..



[julia-users] Re: Default instance of intrinsic type

2014-02-26 Thread Avik Sengupta
Well, there is zero(..) but that is defined only for numeric types

julia zero(Int64)
0

julia zero(ASCIIString)
ERROR: no method convert(Type{ASCIIString}, Int64)
 in zero at operators.jl:146

julia zero(Float64)
0.0

On Thursday, 27 February 2014 06:25:39 UTC, Fil Mackay wrote:

 Is there an easy way, given a particular intrinsic Type, to create a 
 default (zero) instance? eg.

 z(Int64)
 # 0::Int64

 z(ASCIIString)
 # ::ASCIIString

 Akin to the C# default 
 keywordhttp://msdn.microsoft.com/en-us/library/xwth0h0d.aspx, 
 that returns the default initialised value of any type.