date:20141217

Maxwell, it would be great if you could submit a pull request to add that 
documentation.

Best,
--Tim

On Wednesday, December 17, 2014 07:23:50 AM Andreas Noack wrote:
 You might be right that it is not documented, but they are supported. Have
 a look in src/univariate/continuous
 
 julia using Distributions
 
 julia d1 = NoncentralF(1.2,2.3,3.4)
 NoncentralF(ndf=1.2, ddf=2.3, ncp=3.4)
 
 julia rand(d)
 33.94546618024409
 
 julia d2 = NoncentralChisq(3, 1.1)
 NoncentralChisq(df=3.0, ncp=1.1)
 
 julia rand(d2)
 4.822266647364242
 
 2014-12-17 2:31 GMT+01:00 Maxwell rsz...@gmail.com:
  Hi all,
  I would like to simulate from a non-central F distribution. I don't think
  the package Distributions supports non-central F or the non-central Chi
  squared. Is there any other package(s) that can help me with that? or does
  anybody have an idea how that can be done?
  
  Thanks,

Re: [julia-users] THANKS to Julia core developers!

2014-12-17 Thread Christoph Ortner


So would I.
   Christoph


On Wednesday, 17 December 2014 04:53:34 UTC, ivo welch wrote:

 I would have a buy 3 year membership paypal button for $50 on the 
 julia front page.  this way, you also will have some running list of 
 people particularly interested in the language.  if this exists, I 
 will join. 

  
 Ivo Welch (ivo@gmail.com javascript:) 
 http://www.ivo-welch.info/ 
 J. Fred Weston Distinguished Professor of Finance 
 Anderson School at UCLA, C519 
 Director, UCLA Anderson Fink Center for Finance and Investments 
 Free Finance Textbook, http://book.ivo-welch.info/ 
 Exec Editor, Critical Finance Review, 
 http://www.critical-finance-review.org/ 
 Editor and Publisher, FAMe, http://www.fame-jagazine.com/ 


 On Wed, Dec 17, 2014 at 12:27 PM, Viral Shah vi...@mayin.org 
 javascript: wrote: 
  Julia is part of the NumFocus foundation. We don't have a concept of 
  membership, but it can accept grants and donations. We haven't done 
 anything 
  along these lines yet, and are certainly open to ideas. 
  
  -viral 
  
  On Wednesday, December 17, 2014 5:20:12 AM UTC+5:30, ivo welch wrote: 
  
  
  my note was partly a joke, partly a warning.  the R community started 
 out 
  very nice, too.  many still are.  but some of the tone has shifted 
 towards 
  the obnoxious.  the weirdest part is that there are some people who 
  seem to 
  enjoy *really* helping users, all the while being somewhat insulting. 
  it is 
  my (incomplete) understanding that internal strife in the core 
 development 
  team has become negative, too.  it will be up to the julia core team to 
 set 
  the community standard and watch themselves and the community to keep 
 it 
  alive. 
  
  this reminds me: for those of us who cannot contribute, is there a 
 julia 
  foundation membership?  it would not be a bad idea to have us using 
 users 
  get used to contributing, too.

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

Do you need one file per docstring, or can you pack the docs for many functions 
in one file? I think you'd need to be able to do the latter if we want there to 
be some kind of automatic correspondence between foo.jl and foo.jldoc.

--Tim

On Wednesday, December 17, 2014 01:23:45 AM Michael Hatherly wrote:
 Hi John,
 
 Another might be to support having docstrings in separate files (e.g.,
 foo.jl and an optional corresponding foo.jldoc for detailed docstrings).
 
 Docile.jl does support this feature already with:
 
 @doc meta(file = foobar-docs.md) -
 foobar(x) = x
 
 Granted the syntax is slightly bulky, but it does allow arbitrary metadata
 to be associated with any Julia objects via keyword arguments. This *isn’t*
 available in the doc system in Base since it was best to start off with a
 smaller feature set and extend it later.
 
 Anecdotally, I’ve found that storing long docs in external files to be much
 more pleasant than wading through them in source files.
 
 — Mike
 
 
 On Wednesday, 17 December 2014 10:38:04 UTC+2, jgabri...@gmail.com wrote:
  On Tuesday, December 16, 2014 4:55:39 PM UTC-5, Ivar Nesje wrote:
* Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used /
  
  incorporated into Julia proper?
  
  Yes.
  
* Will the new syntax be `doc ...`, `@doc ... -`, or something
  
  else?
  
  The - is probably going away, but final syntax is not yet set in stone
  (nor in code).
  
* What is `mdSome *text* here`? Will Julia support and/or require that
  
  for the new docstrings? If so, what is the benefit of `mdthis` over
  `this`?
  
  The benefit is that `mdthis` has an explicit format, so that we can
  have more formats in the future. The value has been discussed and you can
  have different formats by other means. I like the way it makes markdown
  optional, but others want to save two characters to type.
  
* Regarding the docs currently at 
  
  http://docs.julialang.org/en/release-0.3/, does all of that content
  currently come only from the contents of julia/doc and below?
  
  Yes
  
* Will the docstrings in 0.4 be online at, say,
  
  http://docs.julialang.org/en/release-0.4/ , integrated with the rendered
  .rst docs? Or are they intended to be strictly available via the repl?
  Hm... to avoid duplication, are any files in julia/doc slated to be diced
  up, reformatted into markdown, and inserted into source as docstrings?
  
  Maybe, but it's hard to predict the future. Many files in Base are too
  long already, and detailed docs will not make them shorter. For huge
  codebases, I think it makes sense to fit as much code as possible on a
  screen, and search in separate docs if I need to know more about a
  function.
  
  Thanks, Ivar.
  
  Regarding concerns of longish docstrings being cumbersome to edit around,
  one solution might be to use your editor's code-folding to by-default hide
  docstrings. Another might be to support having docstrings in separate
  files
  (e.g., foo.jl and an optional corresponding foo.jldoc for detailed
  docstrings).
  
  -- John

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

2014-12-17 Thread Michael Hatherly



Do you need one file per docstring, or can you pack the docs for many 
functions in one file?

One file per docstring currently. My thinking was that docstrings that are 
short enough to warrant packing
several into a single file are probably short enough that they could go 
directly into the source code. Also,
how would different “subdocstrings” be associated with different methods? 
Syntax such as:

@doc meta(file = docs.md#foobar) -
foobar(x) = x

with a corresponding # foobar in docs.md to link the two together might 
work.

I’ll probably add this at some point soon.

Some relevant links:

   - https://github.com/MichaelHatherly/Docile.jl/issues/48 
   - https://github.com/MichaelHatherly/Lexicon.jl/issues/18 

— Mike



On Wednesday, 17 December 2014 13:18:57 UTC+2, Tim Holy wrote:

 Do you need one file per docstring, or can you pack the docs for many 
 functions 
 in one file? I think you'd need to be able to do the latter if we want 
 there to 
 be some kind of automatic correspondence between foo.jl and foo.jldoc. 

 --Tim 

 On Wednesday, December 17, 2014 01:23:45 AM Michael Hatherly wrote: 
  Hi John, 
  
  Another might be to support having docstrings in separate files (e.g., 
  foo.jl and an optional corresponding foo.jldoc for detailed docstrings). 
  
  Docile.jl does support this feature already with: 
  
  @doc meta(file = foobar-docs.md) - 
  foobar(x) = x 
  
  Granted the syntax is slightly bulky, but it does allow arbitrary 
 metadata 
  to be associated with any Julia objects via keyword arguments. This 
 *isn’t* 
  available in the doc system in Base since it was best to start off with 
 a 
  smaller feature set and extend it later. 
  
  Anecdotally, I’ve found that storing long docs in external files to be 
 much 
  more pleasant than wading through them in source files. 
  
  — Mike 
   
  
  On Wednesday, 17 December 2014 10:38:04 UTC+2, jgabri...@gmail.com 
 wrote: 
   On Tuesday, December 16, 2014 4:55:39 PM UTC-5, Ivar Nesje wrote: 
 * Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used / 
   
   incorporated into Julia proper? 
   
   Yes. 
   
 * Will the new syntax be `doc ...`, `@doc ... -`, or something 
   
   else? 
   
   The - is probably going away, but final syntax is not yet set in 
 stone 
   (nor in code). 
   
 * What is `mdSome *text* here`? Will Julia support and/or require 
 that 
   
   for the new docstrings? If so, what is the benefit of `mdthis` over 
   `this`? 
   
   The benefit is that `mdthis` has an explicit format, so that we can 
   have more formats in the future. The value has been discussed and you 
 can 
   have different formats by other means. I like the way it makes 
 markdown 
   optional, but others want to save two characters to type. 
   
 * Regarding the docs currently at  
   
   http://docs.julialang.org/en/release-0.3/, does all of that content 
   currently come only from the contents of julia/doc and below? 
   
   Yes 
   
 * Will the docstrings in 0.4 be online at, say, 
   
   http://docs.julialang.org/en/release-0.4/ , integrated with the 
 rendered 
   .rst docs? Or are they intended to be strictly available via the 
 repl? 
   Hm... to avoid duplication, are any files in julia/doc slated to be 
 diced 
   up, reformatted into markdown, and inserted into source as 
 docstrings? 
   
   Maybe, but it's hard to predict the future. Many files in Base are 
 too 
   long already, and detailed docs will not make them shorter. For huge 
   codebases, I think it makes sense to fit as much code as possible on 
 a 
   screen, and search in separate docs if I need to know more about a 
   function. 
   
   Thanks, Ivar. 
   
   Regarding concerns of longish docstrings being cumbersome to edit 
 around, 
   one solution might be to use your editor's code-folding to by-default 
 hide 
   docstrings. Another might be to support having docstrings in separate 
   files 
   (e.g., foo.jl and an optional corresponding foo.jldoc for detailed 
   docstrings). 
   
   -- John

[julia-users] Re: MatrixDepot.jl: A Test Matrix Collection

2014-12-17 Thread Weijian Zhang

Hello, 

Just want to let you know that MatrixDepot v0.0.3 
https://github.com/weijianzhang/MatrixDepot.jl is released.  Now you can 
add more properties using the macro @addproperty. Thanks for Christian's 
suggestions. 

The Documentation is 
here: 
http://nbviewer.ipython.org/github/weijianzhang/MatrixDepot.jl/blob/master/doc/juliadoc.ipynb

Please let me know how you feel about it.

Best wishes,

Weijian

On Saturday, 13 December 2014 00:12:13 UTC, Christian Peel wrote:

 could you discuss the properties?  Can we add more properties?What do 
 the 'inverse' and 'eigen' properties mean?   




 On Friday, December 12, 2014 1:53:09 PM UTC-8, cdm wrote:


 great references, Weijian ...

 it turns out that the UF Sparse collection has a filed issue at:

https://github.com/JuliaSparse/MatrixMarket.jl/issues/1


 i understand that the UF Sparse collection is primarily
 in Rutherford-Boeing format and that a read-in tool for
 this may be in the works ...

 best,

 cdm


 On Friday, December 12, 2014 12:09:41 PM UTC-8, Weijian Zhang wrote:

 Hi cdm,

 Thanks a lot for the comments. 

 Just for reference:
 If you want to read matrices in the Matrix Market format, you can use 
 MatrixMarket.jl (https://github.com/JuliaSparse/MatrixMarket.jl).
 If your matrices are in Harwell Boeing Format, there is HarwellBoeing.jl 
 (https://github.com/dpo/HarwellBoeing.jl)

 Best wishes,

 Weijian

Re: [julia-users] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

2014-12-17 Thread David Smith

I've tried all of the plotting packages.  Winston is a nice start but still 
a little rough around the edges.  I couldn't get a colorbar, for example, 
and the fonts aren't as well rendered as in Matplotlib.

ImageView is nice for peeking at things, but it doesn't produce plot 
annotations, AFAIK.  I use ImageView when developing.

On Tuesday, December 16, 2014 10:36:17 PM UTC-6, Isaiah wrote:

 Tim Holy's ImageView package is another one to look at. Performance is 
 very good with the Gtk backend (streaming video works well).

 On Tue, Dec 16, 2014 at 6:39 PM, Johan Sigfrids johan.s...@gmail.com 
 javascript: wrote:

 Have you tried Winston?
 https://github.com/nolta/Winston.jl


 On Tuesday, December 16, 2014 11:15:42 PM UTC+2, David Smith wrote:

 Thank you.  

 I feel like Julia has matured enough finally to start migrating all of 
 my MRI research over to it.  So far I have found no barriers whatsoever.  I 
 recommend it enthusiastically to all of my colleagues.  They are probably 
 getting tired of hearing about it.  ;-)

 My biggest wish-list item (as a medical imager) would be native Julia 
 plotting that is similar to Matplotlib.  I'd rather not have to require 
 that people have Python alongside Julia.  Makes Julia sound less mature.  I 
 tried Gadfly, but when most of what you plot is images, Gadfly makes less 
 sense.  (Maybe something is missing in the grammar that includes images as 
 something separate from rectbins.) I also got bit pretty hard by the pair 
 borking bug in Color.jl, which was very annoying.

 On Tuesday, December 16, 2014 1:42:16 PM UTC-6, Isaiah wrote:

 This is exciting! Congratulations on the release.

 On Tue, Dec 16, 2014 at 1:50 PM, David Smith david...@gmail.com 
 wrote:

 A few of us around here do medical imaging research, so I'm announcing 
 the release of DCEMRI.jl, a Julia module for processing dynamic contrast 
 enhanced magnetic resonance imaging (MRI) data.  

 http://github.com/davidssmith/DCEMRI.jl

 To install,

 julia Pkg.add(DCEMRI)

 To run a quick demo,

 julia using DCEMRI

 julia demo()

 To rerun the validations,

 julia validate()

 (Validation can take a while, because the phantoms use a ridiculously 
 large number of time points, and the Levenberg-Marquardt fitting scales 
 poorly with number of measurements.)

 When you run these functions, PyPlot will show the resulting images 
 after the run is complete, and pdfs of the images will be saved in the 
 module directory by default, or another place if you specify.

 The models included currently are the standard and extended 
 Tofts-Kety, and both have been validated against the test phantoms 
 provided 
 by the Quantitative Imaging Biomarkers Association. The execution speed 
 is 
 the fastest of any code I've tried, by about an order of magnitude, on a 
 per-processor basis.  You can fit a typical slice of in vivo data in 
 about 
 1-2 seconds on a decent machine. 

 Several modes of operation are supported, including file-based 
 processing and passing data as function arguments and parameters as 
 kwargs. 
 See the demo and the validation functions for examples of usage. Parallel 
 processing is supported, using either function parameters or by starting 
 julia with the '-p n' flag. I also have a command-line script and a 
 (simplistic) Matlab interface function.

 The code currently uses PyPlot for plotting, so you need Matplotlib 
 installed, and that is not handled automatically, but all of the Julia 
 dependencies are.

 A paper on the code is in press at PeerJ (https://peerj.com/preprints/
 670/).

 Let me know what you think.

 Cheers,
 Dave

[julia-users] How do I turn a string into a variable

2014-12-17 Thread Zeta Convex

I want to be able to write:
@makevar(life, 42)
which will expand to
   life = 42
How do I do this?

Why do I want to do it? Because it would be cool to have a feature like in 
Octave where I could load an HDF5 file, and it automatically sets the 
variables from the file.

Re: [julia-users] How do I turn a string into a variable

2014-12-17 Thread John Myles White

It's easy to write a macro that takes a static literal string and makes a 
variable out of it.

It's much harder (maybe impossible) to write a macro that takes in a variable 
that happens to be bound to a string value and to make a variable out of the 
value you happen to have stored in that variable.

Another way to put it: macros don't exist inside of the world of values -- they 
only live in the world of syntax.

Could you get a similar (and cleaner) effect by populating a Dict instead?

 -- John

On Dec 17, 2014, at 5:37 AM, Zeta Convex zeta.con...@gmail.com wrote:

 I want to be able to write:
 @makevar(life, 42)
 which will expand to
life = 42
 How do I do this?
 
 Why do I want to do it? Because it would be cool to have a feature like in 
 Octave where I could load an HDF5 file, and it automatically sets the 
 variables from the file.

Re: [julia-users] How do I turn a string into a variable

2014-12-17 Thread Isaiah Norton

For the usage goal, have you seen HDF5.jl?

https://github.com/timholy/HDF5.jl#quickstart

The @save and @load macros will do this for you (there are some limitations
- but Tim, Simon, et al. have pushed things about as far as they possibly
can at present).

On Wed, Dec 17, 2014 at 5:37 AM, Zeta Convex zeta.con...@gmail.com wrote:

 I want to be able to write:
 @makevar(life, 42)
 which will expand to
life = 42
 How do I do this?

 Why do I want to do it? Because it would be cool to have a feature like in
 Octave where I could load an HDF5 file, and it automatically sets the
 variables from the file.

Re: [julia-users] How do I turn a string into a variable

2014-12-17 Thread Zeta Convex



On Wednesday, 17 December 2014 14:29:27 UTC, Isaiah wrote:

 For the usage goal, have you seen HDF5.jl?

 https://github.com/timholy/HDF5.jl#quickstart

 The @save and @load macros will do this for you 


Cool beans.

Re: [julia-users] THANKS to Julia core developers!

On Tue, Dec 16, 2014 at 6:50 PM, ivo welch ivo...@gmail.com wrote:


 my note was partly a joke, partly a warning.  the R community started out
 very nice, too.  many still are.  but some of the tone has shifted towards
 the obnoxious.  the weirdest part is that there are some people who  seem
 to enjoy *really* helping users, all the while being somewhat insulting.
  it is my (incomplete) understanding that internal strife in the core
 development team has become negative, too.  it will be up to the julia core
 team to set the community standard and watch themselves and the community
 to keep it alive.


This is certainly something to watch out for. I'm willing to bully people
into being nice :-P

Re: [julia-users] THANKS to Julia core developers!

I'm curious what the membership model for other projects is. What is
entailed in a membership? Do you get anything or is it sort of a symbolic
status in return for donation?

On Tue, Dec 16, 2014 at 11:53 PM, ivo welch ivo.we...@anderson.ucla.edu
wrote:

 I would have a buy 3 year membership paypal button for $50 on the
 julia front page.  this way, you also will have some running list of
 people particularly interested in the language.  if this exists, I
 will join.

 
 Ivo Welch (ivo.we...@gmail.com)
 http://www.ivo-welch.info/
 J. Fred Weston Distinguished Professor of Finance
 Anderson School at UCLA, C519
 Director, UCLA Anderson Fink Center for Finance and Investments
 Free Finance Textbook, http://book.ivo-welch.info/
 Exec Editor, Critical Finance Review,
 http://www.critical-finance-review.org/
 Editor and Publisher, FAMe, http://www.fame-jagazine.com/


 On Wed, Dec 17, 2014 at 12:27 PM, Viral Shah vi...@mayin.org wrote:
  Julia is part of the NumFocus foundation. We don't have a concept of
  membership, but it can accept grants and donations. We haven't done
 anything
  along these lines yet, and are certainly open to ideas.
 
  -viral
 
  On Wednesday, December 17, 2014 5:20:12 AM UTC+5:30, ivo welch wrote:
 
 
  my note was partly a joke, partly a warning.  the R community started
 out
  very nice, too.  many still are.  but some of the tone has shifted
 towards
  the obnoxious.  the weirdest part is that there are some people who
 seem to
  enjoy *really* helping users, all the while being somewhat insulting.
 it is
  my (incomplete) understanding that internal strife in the core
 development
  team has become negative, too.  it will be up to the julia core team to
 set
  the community standard and watch themselves and the community to keep it
  alive.
 
  this reminds me: for those of us who cannot contribute, is there a julia
  foundation membership?  it would not be a bad idea to have us using
 users
  get used to contributing, too.

Re: [julia-users] Rust and Julia - Together? Advice

Even though calling Julia through a REST API is certainly a viable
approach, I think that loading the Julia runtime into Rust shouldn't be
hard. See ui/repl.c
https://github.com/JuliaLang/julia/blob/master/ui/repl.c for how the REPL
loads and uses libjulia. This should be basically the same from Rust.

On Tue, Dec 16, 2014 at 8:49 PM, Eric Forgy eric.fo...@gmail.com wrote:

 Hello,

 I am building a web app for enterprise risk management. I've made some
 progress, but considering some significant changes now before I am too
 committed. My current platform is Java/Spring MVC on the back end (C) and
 Jsp, javascript, and d3 for the front end (V) and I was using Java for
 numerical modeling (M). Coming from a 20+ year background using Matlab, my
 experience trying to do any serious numerical modeling in Java is a little
 frustrating so far. While considering alternatives, e.g. Matlab Production
 Server, R, Python, etc, I was naturally led to Julia and am only now
 beginning to research it, but really like what I see so far.

 Despite my ambitious goals, I am ignorant about most of the technologies
 I'm using and learning as I go. Do you have any suggestions about how I
 might be able to fit Julia into my Spring MVC framework? How can I call
 Julia from Java? I don't see anything obvious. How about setting up a Julia
 server and communicating with it via RESTful API from Java? Has anyone
 tried anything like that? I eventually want to run everything on AWS.

 A bigger change would be to ditch Java all together and build everything
 either entirely in Julia or, I had the thought of building the plumbing in
 Rust and do the numerical modeling in Julia. Thus, capturing the best of
 both. Then, I'd be faced with the same question. How to call Julia from
 Rust? Is that crazy?

 A possible solution for both scenarios might be to set up a Julia server
 and design a RESTful API. How does that sound? How about security? Could
 something like this be done if the data in sensitive?

 I appreciate any thoughts and I really admire what you're doing with
 Julia. Reminds me of the glory days before I sold my soul to Wall Street
 (PhD computational electromagnetics, UIUC, 2002, MIT Lincoln Lab,
 2002-2004). I'm considering trying to get back to academics to redeem
 myself before its too late though :)

 Best regards,
 Eric

Re: [julia-users] THANKS to Julia core developers!

2014-12-17 Thread Viral Shah

 On 17-Dec-2014, at 9:00 pm, Stefan Karpinski ste...@karpinski.org wrote:
 
 On Tue, Dec 16, 2014 at 6:50 PM, ivo welch ivo...@gmail.com wrote:
 
 my note was partly a joke, partly a warning.  the R community started out 
 very nice, too.  many still are.  but some of the tone has shifted towards 
 the obnoxious.  the weirdest part is that there are some people who  seem to 
 enjoy *really* helping users, all the while being somewhat insulting.  it is 
 my (incomplete) understanding that internal strife in the core development 
 team has become negative, too.  it will be up to the julia core team to set 
 the community standard and watch themselves and the community to keep it 
 alive.
 
 This is certainly something to watch out for. I'm willing to bully people 
 into being nice :-P

We have done this in the past and will certainly enforce niceness as required. 
:-) The community is one of the reasons people love julia, and why we ourselves 
love it. I am sure all of us would love to keep it that way.

-viral

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

2014-12-17 Thread jgabriele382

On Wednesday, December 17, 2014 6:47:03 AM UTC-5, Michael Hatherly wrote:

 Do you need one file per docstring, or can you pack the docs for many 
 functions in one file?

 One file per docstring currently. My thinking was that docstrings that are 
 short enough to warrant packing
 several into a single file are probably short enough that they could go 
 directly into the source code. Also,
 how would different “subdocstrings” be associated with different methods? 
 Syntax such as:

 @doc meta(file = docs.md#foobar) -
 foobar(x) = x

 with a corresponding # foobar in docs.md to link the two together might 
 work.

Perhaps the convention could be: each foo.jl source file may have a 
corresponding foo.md file (alongside it, in the source directory), and each 
thing documented with @doc may have its own H1 in the .md file.

This way, rather than having to explicitly/verbosely say `@doc meta(file = 
foo.md#foobar - foobar(x) = x` (that is, come up with id's and add them 
explicitly to the .md file), the tools would know right where to look for 
external docstrings.

-- John

[julia-users] Re: How do I turn a string into a variable

2014-12-17 Thread Zeta Convex

It looks like the solution proposed related to a storage of Julia variables 
in an HDF5 file; rather than an HDF5 file itself.

However, the referenced jl file did provide some clues as to my original 
problem:

macro makevar(name, val)
return :($(esc(symbol(name)))   = $val)
end

macroexpand(:(@makevar foo 2))

:(foo = 2)


@makevar(foo, 2)
2



foo

2

Very nice.

[julia-users] Which licence to use for tutorial materials

2014-12-17 Thread David P. Sanders

Hi,

I would like to add a licence to my tutorial materials (
https://github.com/dpsanders/scipy_2014_julia) so that people can reuse 
them.

Is the MIT licence suitable for this, or should I be using a Creative 
Commons one or something else instead? 
Somehow a tutorial feels different from code. (And I would not particularly 
want my material to be reused for commercial purposes.)

Thanks,
David.

Re: [julia-users] Calling Julia from Java (Java---Julia)

2014-12-17 Thread cdm


this may be relevant / interesting / inspirational:

   http://www.javarepl.com/console.html


the git repo is on:

   https://github.com/albertlatacz/java-repl



i may try to look into that code some ...

best,

cdm


On Wednesday, December 17, 2014 7:41:19 AM UTC-8, Isaiah wrote:

 I'm not aware of any examples of Java-Julia, but there are basically two 
 options:

 - RESTful API or other messaging-based interop
 - use the Julia C API via JNI (Julia functions can be exposed as C 
 function pointers). The potential advantage here is performance (no-copy 
 data transfer, avoid the network stack).

 A variation of the second would be to extend JavaCall.jl to wrap Julia 
 functions as Java callbacks and do as much of the conversion/bookkeeping as 
 possible via JavaCall. This would still entail using JNI for the actual 
 calls, but might avoid some code duplication and hairiness dealing with the 
 embedding API (see pyjulia for an example).

 On Tue, Dec 16, 2014 at 7:21 AM, Frank fr...@frankjlangel.com 
 javascript: wrote:

 Hi,

 i am trying to find information on how to do the following:

- expose Julia functions within/as Java Interfaces 
- Call Julia from Java

 I find a lot of Julia--Java examples, but i would like to call Julia 
 from Java.

 Any tackers?
 Thanks
 Frank

Re: [julia-users] Calling Julia from Java (Java---Julia)

2014-12-17 Thread cdm


for some additional context on the Java REPL:

  http://www.infoq.com/news/2014/09/repl-for-java


etc.

Re: [julia-users] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

ImageView does have an annotation framework, see 
https://github.com/timholy/ImageView.jl#annotations

But the use case is really aimed at interactivity, not for producing polished 
plots. You can export, though, with `write_to_png`.

--Tim

On Wednesday, December 17, 2014 06:08:59 AM David Smith wrote:
 I've tried all of the plotting packages.  Winston is a nice start but still
 a little rough around the edges.  I couldn't get a colorbar, for example,
 and the fonts aren't as well rendered as in Matplotlib.
 
 ImageView is nice for peeking at things, but it doesn't produce plot
 annotations, AFAIK.  I use ImageView when developing.
 
 On Tuesday, December 16, 2014 10:36:17 PM UTC-6, Isaiah wrote:
  Tim Holy's ImageView package is another one to look at. Performance is
  very good with the Gtk backend (streaming video works well).
  
  On Tue, Dec 16, 2014 at 6:39 PM, Johan Sigfrids johan.s...@gmail.com
  
  javascript: wrote:
  Have you tried Winston?
  https://github.com/nolta/Winston.jl
  
  On Tuesday, December 16, 2014 11:15:42 PM UTC+2, David Smith wrote:
  Thank you.
  
  I feel like Julia has matured enough finally to start migrating all of
  my MRI research over to it.  So far I have found no barriers whatsoever.
   I
  recommend it enthusiastically to all of my colleagues.  They are
  probably
  getting tired of hearing about it.  ;-)
  
  My biggest wish-list item (as a medical imager) would be native Julia
  plotting that is similar to Matplotlib.  I'd rather not have to require
  that people have Python alongside Julia.  Makes Julia sound less mature.
   I
  tried Gadfly, but when most of what you plot is images, Gadfly makes
  less
  sense.  (Maybe something is missing in the grammar that includes images
  as
  something separate from rectbins.) I also got bit pretty hard by the
  pair
  borking bug in Color.jl, which was very annoying.
  
  On Tuesday, December 16, 2014 1:42:16 PM UTC-6, Isaiah wrote:
  This is exciting! Congratulations on the release.
  
  On Tue, Dec 16, 2014 at 1:50 PM, David Smith david...@gmail.com
  
  wrote:
  A few of us around here do medical imaging research, so I'm announcing
  the release of DCEMRI.jl, a Julia module for processing dynamic
  contrast
  enhanced magnetic resonance imaging (MRI) data.
  
  http://github.com/davidssmith/DCEMRI.jl
  
  To install,
  
  julia Pkg.add(DCEMRI)
  
  To run a quick demo,
  
  julia using DCEMRI
  
  julia demo()
  
  To rerun the validations,
  
  julia validate()
  
  (Validation can take a while, because the phantoms use a ridiculously
  large number of time points, and the Levenberg-Marquardt fitting
  scales
  poorly with number of measurements.)
  
  When you run these functions, PyPlot will show the resulting images
  after the run is complete, and pdfs of the images will be saved in the
  module directory by default, or another place if you specify.
  
  The models included currently are the standard and extended
  Tofts-Kety, and both have been validated against the test phantoms
  provided
  by the Quantitative Imaging Biomarkers Association. The execution
  speed is
  the fastest of any code I've tried, by about an order of magnitude, on
  a
  per-processor basis.  You can fit a typical slice of in vivo data in
  about
  1-2 seconds on a decent machine.
  
  Several modes of operation are supported, including file-based
  processing and passing data as function arguments and parameters as
  kwargs.
  See the demo and the validation functions for examples of usage.
  Parallel
  processing is supported, using either function parameters or by
  starting
  julia with the '-p n' flag. I also have a command-line script and a
  (simplistic) Matlab interface function.
  
  The code currently uses PyPlot for plotting, so you need Matplotlib
  installed, and that is not handled automatically, but all of the Julia
  dependencies are.
  
  A paper on the code is in press at PeerJ (https://peerj.com/preprints/
  670/).
  
  Let me know what you think.
  
  Cheers,
  Dave

Re: [julia-users] THANKS to Julia core developers!

2014-12-17 Thread cdm


here, here ...

setting up something on

   https://gittip.com/   |   https://gratipay.com/


may also prove worthwhile.

cdm


On Wednesday, December 17, 2014 3:19:10 AM UTC-8, Christoph Ortner wrote:


 So would I.
Christoph


 On Wednesday, 17 December 2014 04:53:34 UTC, ivo welch wrote:

 I would have a buy 3 year membership paypal button for $50 on the 
 julia front page.  this way, you also will have some running list of 
 people particularly interested in the language.  if this exists, I 
 will join. 

  
 Ivo Welch (ivo@gmail.com) 
 http://www.ivo-welch.info/ 
 J. Fred Weston Distinguished Professor of Finance 
 Anderson School at UCLA, C519 
 Director, UCLA Anderson Fink Center for Finance and Investments 
 Free Finance Textbook, http://book.ivo-welch.info/ 
 Exec Editor, Critical Finance Review, 
 http://www.critical-finance-review.org/ 
 Editor and Publisher, FAMe, http://www.fame-jagazine.com/ 


 On Wed, Dec 17, 2014 at 12:27 PM, Viral Shah vi...@mayin.org wrote: 
  Julia is part of the NumFocus foundation. We don't have a concept of 
  membership, but it can accept grants and donations. We haven't done 
 anything 
  along these lines yet, and are certainly open to ideas. 
  
  -viral 
  
  On Wednesday, December 17, 2014 5:20:12 AM UTC+5:30, ivo welch wrote: 
  
  
  my note was partly a joke, partly a warning.  the R community started 
 out 
  very nice, too.  many still are.  but some of the tone has shifted 
 towards 
  the obnoxious.  the weirdest part is that there are some people who 
  seem to 
  enjoy *really* helping users, all the while being somewhat insulting. 
  it is 
  my (incomplete) understanding that internal strife in the core 
 development 
  team has become negative, too.  it will be up to the julia core team 
 to set 
  the community standard and watch themselves and the community to keep 
 it 
  alive. 
  
  this reminds me: for those of us who cannot contribute, is there a 
 julia 
  foundation membership?  it would not be a bad idea to have us using 
 users 
  get used to contributing, too.

Re: [julia-users] Non-central F distribution

2014-12-17 Thread Maxwell

Thanks Andreas! That's awesome!

On Wednesday, December 17, 2014 12:23:54 AM UTC-6, Andreas Noack wrote:

 You might be right that it is not documented, but they are supported. Have 
 a look in src/univariate/continuous

 julia using Distributions

 julia d1 = NoncentralF(1.2,2.3,3.4)
 NoncentralF(ndf=1.2, ddf=2.3, ncp=3.4)

 julia rand(d)
 33.94546618024409

 julia d2 = NoncentralChisq(3, 1.1)
 NoncentralChisq(df=3.0, ncp=1.1)

 julia rand(d2)
 4.822266647364242

 2014-12-17 2:31 GMT+01:00 Maxwell rsz...@gmail.com javascript::


 Hi all,
 I would like to simulate from a non-central F distribution. I don't think 
 the package Distributions supports non-central F or the non-central Chi 
 squared. Is there any other package(s) that can help me with that? or does 
 anybody have an idea how that can be done?

 Thanks,

Re: [julia-users] Non-central F distribution

2014-12-17 Thread Maxwell

I agree Tim! I will work on that.

On Wednesday, December 17, 2014 5:13:50 AM UTC-6, Tim Holy wrote:

 Maxwell, it would be great if you could submit a pull request to add that 
 documentation. 

 Best, 
 --Tim 

 On Wednesday, December 17, 2014 07:23:50 AM Andreas Noack wrote: 
  You might be right that it is not documented, but they are supported. 
 Have 
  a look in src/univariate/continuous 
  
  julia using Distributions 
  
  julia d1 = NoncentralF(1.2,2.3,3.4) 
  NoncentralF(ndf=1.2, ddf=2.3, ncp=3.4) 
  
  julia rand(d) 
  33.94546618024409 
  
  julia d2 = NoncentralChisq(3, 1.1) 
  NoncentralChisq(df=3.0, ncp=1.1) 
  
  julia rand(d2) 
  4.822266647364242 
  
  2014-12-17 2:31 GMT+01:00 Maxwell rsz...@gmail.com javascript:: 
   Hi all, 
   I would like to simulate from a non-central F distribution. I don't 
 think 
   the package Distributions supports non-central F or the non-central 
 Chi 
   squared. Is there any other package(s) that can help me with that? or 
 does 
   anybody have an idea how that can be done? 
   
   Thanks,

Re: [julia-users] Which licence to use for tutorial materials

I'm not really sure. The Julia manual end up being MIT sort of by accident
just because it's part of the julia repo and the MIT license applies to
everything that doesn't have a different license indicated. Some CC license
may be better.

On Wed, Dec 17, 2014 at 11:39 AM, David P. Sanders dpsand...@gmail.com
wrote:

 Hi,

 I would like to add a licence to my tutorial materials (
 https://github.com/dpsanders/scipy_2014_julia) so that people can reuse
 them.

 Is the MIT licence suitable for this, or should I be using a Creative
 Commons one or something else instead?
 Somehow a tutorial feels different from code. (And I would not
 particularly want my material to be reused for commercial purposes.)

 Thanks,
 David.

[julia-users] Update from Japan: Book, JapanR, Advent Calendar

2014-12-17 Thread Sorami Hisamoto

Hi,

We had a few events in Japan recently;

1. Book

We wrote an article about Julia in Japanese.

The article is in a book about R, データサイエンティスト養成読本 R活用編 (literally
means Data Scientist Training Textbook: R Language edition) .

Here's the link to Amazon Japan;
http://www.amazon.co.jp/dp/4774170577

2. JapanR

JapanR is the biggest R user event in Japan.
https://atnd.org/events/58624

This year we had around 250 attendees (including ustream).

In the event we had a panel discussion on different languages (R,
Python, Excel, SAS, Julia).

I was surprise to see that about half of the attendees didn't know about Julia.

3. Advent Calendar

We are doing Julia Advent Calendar, where someone writes an article
on Julia for the 25 days of December.
http://qiita.com/advent-calendar/2014/julialang

Here's the line up in English;

Dec 01: Learn Julia in X Minutes bicycle1885
Dec 02: Julia v0.4.0-dev yomichi_137
Dec 03: Julia Environment Setup - 2014 ver. chezou
Dec 04: Let's Program in Unicode bicycle1885
Dec 05: Low-level Julia (LLVM IR Native Code) kimrin
Dec 06: Presented 'MaCab.jl' at JapanR chezou
Dec 07: Introduction to The Classic Compiler Theories kimrin
Dec 08: Running Stan.jl on Windows 8.1 berobero11
Dec 09: Common Gotcha around ccall Pointer r9y9
Dec 10: NumericExtensions.jl / NumericFuns.jl yomichi_137
Dec 11: Releasing The Packages via REPL chezou
Dec 12: 100 Julia QAs for Pythonista bicycle1885
Dec 13: Reading 'Introduction to Julia' chezou *referring to the book above
Dec 14: Construction and Evaluation of Prediction Models by Julia sfchaos
Dec 15: On Julia DataFrame - #1 weda_654
Dec 16: Doing What I Usually Do in R with Julia dichika
Dec 17: Building A Spam Classifier with Julia yutajuly
Dec 18: Accelerating randn yomichi_137
Dec 19: (TBA) sorami
Dec 20: (TBA) ysks3n
Dec 21: Adding Julia to The Quine Relay mametter
Dec 22: (something related to build?) iizukak
Dec 23: (language comparisson?) nezuq
Dec 24: Binding the Libraries Written in C chezou
Dec 25: (kimrin) kimrin

Hope these events will make more people in Japan interested in Julia!

- sorami

Re: [julia-users] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia



On Tuesday, December 16, 2014 4:15:42 PM UTC-5, David Smith wrote:

 My biggest wish-list item (as a medical imager) would be native Julia 
 plotting that is similar to Matplotlib.  I'd rather not have to require 
 that people have Python alongside Julia.  Makes Julia sound less mature.  


Julia *is* significantly less mature than Python, and for the next several 
years (at least!) there will undoubtedly be lots of major functionality 
that is available in Python but not in pure Julia.  Fortunately, pretty 
much all of this functionality is accessible via PyCall.

As a result, I pretty much always strongly recommend that people using 
Julia also have a decent Python/SciPy installation (I recommend Anaconda on 
Windows and Mac).   This is also needed if you want to use IJulia.

I don't think we should be any more ashamed of calling Python for things 
like plotting than we are ashamed of calling C and Fortran code for linear 
algebra or Bessel functions.

--SGJ

Re: [julia-users] Julia iPython notebook doesn't display inline graphics

On Tuesday, December 16, 2014 8:33:27 AM UTC-5, RecentConvert wrote:

 In my case the problem turned out to be my .juliarc.jl file. My guess is 
 that loading PyPlot there had caused plots to be plotted in a separate 
 window. The result of the same command are still qt4agg.


Yes, that would cause a problem because using PyPlot in your juliarc would 
initialize PyPlot before IJulia is loaded, and hence PyPlot would think 
that it's not in an IJulia environment.  Hence it wouldn't set up inline 
display.

Re: [julia-users] Which licence to use for tutorial materials

2014-12-17 Thread Craig Schmidt

It seems like a Creative Commons license would be good for this kind of 
material.  There are variants to restrict commercial use, that you wouldn’t get 
with an MIT license.

You can choose your own license terms here:

https://creativecommons.org/choose/

-Craig

On Dec 17, 2014, at 11:39 AM, David P. Sanders dpsand...@gmail.com wrote:

 Hi,
 
 I would like to add a licence to my tutorial materials 
 (https://github.com/dpsanders/scipy_2014_julia) so that people can reuse them.
 
 Is the MIT licence suitable for this, or should I be using a Creative Commons 
 one or something else instead? 
 Somehow a tutorial feels different from code. (And I would not particularly 
 want my material to be reused for commercial purposes.)
 
 Thanks,
 David.

[julia-users] Re: [code review] RPN calculator algorithm

In this particular case, the Python version on RosettaCode seems insanely 
overcomplicated.  I updated the Julia version to a much simpler 
implementation 
(http://rosettacode.org/wiki/Parsing/RPN_calculator_algorithm#Julia).

(As usual, the J version is the one to beat for terseness, at the expense 
of readability.  I have a perverse admiration for the J programmers on 
RosettaCode.)

Re: [julia-users] Which licence to use for tutorial materials

2014-12-17 Thread Jim Garrison

My opinion is that as a matter of policy, official documentation for Julia 
should be under a free/libre license, whether that license is CC or MIT or 
otherwise.  Some of the CC licenses are non-free, for instance those that 
place restrictions on commercial use.  The Software Freedom Law Center (my 
former employer, though I myself am not a lawyer) has a few paragraphs on 
choice of license for software documentation here: 
https://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-120002.4

For documentation outside the official repositories, of course the choice 
of license is up to you.  Nonetheless, I'd highly encourage you, and 
anybody writing documentation, to choose a free license when possible.


On Wednesday, December 17, 2014 10:23:21 AM UTC-8, Craig Schmidt wrote:

 It seems like a Creative Commons license would be good for this kind of 
 material.  There are variants to restrict commercial use, that you wouldn’t 
 get with an MIT license.

 You can choose your own license terms here:

 https://creativecommons.org/choose/

 -Craig

 On Dec 17, 2014, at 11:39 AM, David P. Sanders dpsa...@gmail.com 
 javascript: wrote:

 Hi,

 I would like to add a licence to my tutorial materials (
 https://github.com/dpsanders/scipy_2014_julia) so that people can reuse 
 them.

 Is the MIT licence suitable for this, or should I be using a Creative 
 Commons one or something else instead? 
 Somehow a tutorial feels different from code. (And I would not 
 particularly want my material to be reused for commercial purposes.)

 Thanks,
 David.

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

+1. Please reconsider making a @doc (at least a NOP) for 0.3.x - this way
we can start writing repl-printable docstrings that will be useful in 0.4
but not have our code break in earlier versions.

On Tuesday, December 16, 2014 4:50:56 PM UTC-8, ele...@gmail.com wrote:

So if otherwise unchanged code is documented with @doc (which it will be,
who doesn't want it to show in the repl :) then it won't compile on 0.3?

If it won't compile it makes maintaining backward compatibility harder,
and its hard enough between 0.4 and 0.3 already.

On Wednesday, December 17, 2014 9:04:53 AM UTC+10, Mike Innes wrote:

It is needed if you want the docs to show up in the repl etc. It's just
that the plain string won't break anything (it won't do anything, either,
for now).

On 16 December 2014 at 22:58, ele...@gmail.com wrote:

On Wednesday, December 17, 2014 8:41:00 AM UTC+10, Mike Innes wrote:

It's not really that worthwhile since (a) you can use Docile and (b)
the future syntax

foo

foo() ...

is backwards-compatible already. I just use that.

Oh, ok, I thought an @doc macro was needed in 0.4
https://github.com/JuliaLang/julia/blob/d0a951ccb3a7ebae7909665f4445a019f2ee54a1/base/basedocs.jl
.

Cheers
Lex

On 16 December 2014 at 22:37, ele...@gmail.com wrote:

Since the @doc is 0.4, is it possible to backport a do nothing
version that will allow documented code to still compile in 0.3?

Cheers
Lex

On Wednesday, December 17, 2014 8:04:06 AM UTC+10, Mike Innes wrote:

Actually the @doc macro will still interpret plain strings as
markdown by default. There are some caveats with escaping that make it
good
practice to write doc anyway, but those will go away once the parser
changes are implemented.

I'm in the process of writing documentation documentation, so the
manual should be up to date reasonably soon.

On 16 December 2014 at 21:55, Ivar Nesje iva...@gmail.com wrote:

Hi,

Hello.

Looks like exciting doc changes are afoot with Julia! I'd like to
get some more understanding of what's coming. Had a look at some of the
github issues tagged doc, but I'm still missing some basics (note,
I'm
still quite new to Julia). Questions:

* Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used /
incorporated into Julia proper?

Yes.

* Will the new syntax be `doc ...`, `@doc ... -`, or
something else?

The - is probably going away, but final syntax is not yet set in
stone (nor in code).

* What is `mdSome *text* here`? Will Julia support and/or require
that for the new docstrings? If so, what is the benefit of `mdthis`
over
`this`?

The benefit is that `mdthis` has an explicit format, so that we
can have more formats in the future. The value has been discussed and
you
can have different formats by other means. I like the way it makes
markdown
optional, but others want to save two characters to type.

* Regarding the docs currently at http://docs.julialang.org/en/
release-0.3/, does all of that content currently come only from
the contents of julia/doc and below?

Yes

* Will the docstrings in 0.4 be online at, say,
http://docs.julialang.org/en/release-0.4/ , integrated with the
rendered .rst docs? Or are they intended to be strictly available via
the
repl? Hm... to avoid duplication, are any files in julia/doc slated to
be
diced up, reformatted into markdown, and inserted into source as
docstrings?

Maybe, but it's hard to predict the future. Many files in Base are
too long already, and detailed docs will not make them shorter. For
huge
codebases, I think it makes sense to fit as much code as possible on a
screen, and search in separate docs if I need to know more about a
function.

Thanks,
-- John

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

2014-12-17 Thread John Myles White

This debate seems a little premature to me since the definition of @doc is not
totally finished yet and we need to finalize that before anyone should be
adding documentation to 0.3 packages.

-- John

On Dec 17, 2014, at 3:15 PM, Seth catch...@bromberger.com wrote:

+1. Please reconsider making a @doc (at least a NOP) for 0.3.x - this way we
can start writing repl-printable docstrings that will be useful in 0.4 but
not have our code break in earlier versions.

On Tuesday, December 16, 2014 4:50:56 PM UTC-8, ele...@gmail.com wrote:
So if otherwise unchanged code is documented with @doc (which it will be, who
doesn't want it to show in the repl :) then it won't compile on 0.3?

If it won't compile it makes maintaining backward compatibility harder, and
its hard enough between 0.4 and 0.3 already.

On Wednesday, December 17, 2014 9:04:53 AM UTC+10, Mike Innes wrote:
It is needed if you want the docs to show up in the repl etc. It's just that
the plain string won't break anything (it won't do anything, either, for now).

On 16 December 2014 at 22:58, ele...@gmail.com wrote:

On Wednesday, December 17, 2014 8:41:00 AM UTC+10, Mike Innes wrote:
It's not really that worthwhile since (a) you can use Docile and (b) the
future syntax

foo

foo() ...

is backwards-compatible already. I just use that.

Oh, ok, I thought an @doc macro was needed in 0.4
https://github.com/JuliaLang/julia/blob/d0a951ccb3a7ebae7909665f4445a019f2ee54a1/base/basedocs.jl.

Cheers
Lex

On 16 December 2014 at 22:37, ele...@gmail.com wrote:
Since the @doc is 0.4, is it possible to backport a do nothing version that
will allow documented code to still compile in 0.3?

Cheers
Lex

On Wednesday, December 17, 2014 8:04:06 AM UTC+10, Mike Innes wrote:
Actually the @doc macro will still interpret plain strings as markdown by
default. There are some caveats with escaping that make it good practice to
write doc anyway, but those will go away once the parser changes are
implemented.

I'm in the process of writing documentation documentation, so the manual
should be up to date reasonably soon.

On 16 December 2014 at 21:55, Ivar Nesje iva...@gmail.com wrote:
Hi,

Hello.

Looks like exciting doc changes are afoot with Julia! I'd like to get some
more understanding of what's coming. Had a look at some of the github
issues tagged doc, but I'm still missing some basics (note, I'm still
quite new to Julia). Questions:

* Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used /
incorporated into Julia proper?

Yes.

* Will the new syntax be `doc ...`, `@doc ... -`, or something else?

The - is probably going away, but final syntax is not yet set in stone (nor
in code).

* What is `mdSome *text* here`? Will Julia support and/or require that for
the new docstrings? If so, what is the benefit of `mdthis` over `this`?

The benefit is that `mdthis` has an explicit format, so that we can have
more formats in the future. The value has been discussed and you can have
different formats by other means. I like the way it makes markdown optional,
but others want to save two characters to type.

* Regarding the docs currently at
http://docs.julialang.org/en/release-0.3/, does all of that content
currently come only from the contents of julia/doc and below?

Yes

* Will the docstrings in 0.4 be online at, say,
http://docs.julialang.org/en/release-0.4/ , integrated with the rendered .rst
docs? Or are they intended to be strictly available via the repl? Hm... to
avoid duplication, are any files in julia/doc slated to be diced up,
reformatted into markdown, and inserted into source as docstrings?

Maybe, but it's hard to predict the future. Many files in Base are too long
already, and detailed docs will not make them shorter. For huge codebases, I
think it makes sense to fit as much code as possible on a screen, and search
in separate docs if I need to know more about a function.

Thanks,
-- John

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

Just add this to your modules:

if VERSION  v0.4.0-dev
using Docile
end

and use the subset of @doc common to 0.3 and 0.4.

--Tim


On Wednesday, December 17, 2014 12:15:03 PM Seth wrote:
 +1. Please reconsider making a @doc (at least a NOP) for 0.3.x - this way
 we can start writing repl-printable docstrings that will be useful in 0.4
 but not have our code break in earlier versions.
 
 On Tuesday, December 16, 2014 4:50:56 PM UTC-8, ele...@gmail.com wrote:
  So if otherwise unchanged code is documented with @doc (which it will be,
  who doesn't want it to show in the repl :) then it won't compile on 0.3?
  
  If it won't compile it makes maintaining backward compatibility harder,
  and its hard enough between 0.4 and 0.3 already.
  
  On Wednesday, December 17, 2014 9:04:53 AM UTC+10, Mike Innes wrote:
  It is needed if you want the docs to show up in the repl etc. It's just
  that the plain string won't break anything (it won't do anything, either,
  for now).
  
  On 16 December 2014 at 22:58, ele...@gmail.com wrote:
  On Wednesday, December 17, 2014 8:41:00 AM UTC+10, Mike Innes wrote:
  It's not really that worthwhile since (a) you can use Docile and (b)
  the future syntax
  
  
  foo
  
  foo() ...
  
  is backwards-compatible already. I just use that.
  
  Oh, ok, I thought an @doc macro was needed in 0.4
  https://github.com/JuliaLang/julia/blob/d0a951ccb3a7ebae7909665f4445a019
  f2ee54a1/base/basedocs.jl .
  
  Cheers
  Lex
  
  On 16 December 2014 at 22:37, ele...@gmail.com wrote:
  Since the @doc is 0.4, is it possible to backport a do nothing
  version that will allow documented code to still compile in 0.3?
  
  Cheers
  Lex
  
  On Wednesday, December 17, 2014 8:04:06 AM UTC+10, Mike Innes wrote:
  Actually the @doc macro will still interpret plain strings as
  markdown by default. There are some caveats with escaping that make
  it good
  practice to write doc anyway, but those will go away once the
  parser
  changes are implemented.
  
  I'm in the process of writing documentation documentation, so the
  manual should be up to date reasonably soon.
  
  On 16 December 2014 at 21:55, Ivar Nesje iva...@gmail.com wrote:
   Hi,
  
  Hello.
  
   Looks like exciting doc changes are afoot with Julia! I'd like to
  
  get some more understanding of what's coming. Had a look at some of
  the
  github issues tagged doc, but I'm still missing some basics (note,
  I'm
  
  still quite new to Julia). Questions:
* Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used /
  
  incorporated into Julia proper?
  
  Yes.
  
* Will the new syntax be `doc ...`, `@doc ... -`, or
  
  something else?
  
  The - is probably going away, but final syntax is not yet set in
  stone (nor in code).
  
* What is `mdSome *text* here`? Will Julia support and/or require
  
  that for the new docstrings? If so, what is the benefit of
  `mdthis` over
  `this`?
  
  The benefit is that `mdthis` has an explicit format, so that we
  can have more formats in the future. The value has been discussed
  and you
  can have different formats by other means. I like the way it makes
  markdown
  optional, but others want to save two characters to type.
  
* Regarding the docs currently at http://docs.julialang.org/en/
  
  release-0.3/, does all of that content currently come only from
  the contents of julia/doc and below?
  
  Yes
  
* Will the docstrings in 0.4 be online at, say,
  
  http://docs.julialang.org/en/release-0.4/ , integrated with the
  rendered .rst docs? Or are they intended to be strictly available
  via the
  repl? Hm... to avoid duplication, are any files in julia/doc slated
  to be
  diced up, reformatted into markdown, and inserted into source as
  docstrings?
  
  Maybe, but it's hard to predict the future. Many files in Base are
  too long already, and detailed docs will not make them shorter. For
  huge
  codebases, I think it makes sense to fit as much code as possible on
  a
  screen, and search in separate docs if I need to know more about a
  function.
  
  Thanks,
  -- John

Re: [julia-users] Re: overview questions about new doc changes (coming with v 0.4)

I respectfully disagree. I would agree with you if your statement concluded
before anyone should be adding documentation to ANY packages, but the
thing is, @doc is available for use in 0.4 and, while the definition may
change, it's merely a matter of break-fix if the format changes so much
between now and when it's ready that @docstrings fail to compile
properly. However, RIGHT NOW, any code written with @doc in a 0.4
environment will simply fail in 0.3, Compat or no Compat.

My suggestion would be to create, if possible, a @doc noop in Compat.jl so
that seasoned developers who are using the latest and greatest 0.4 code can
start creating documentation now* while not breaking their packages for
those users who are on the release version, and folks who are developing on
0.3 can include basic @docstrings that will work as intended on 0.4.

*the reality is that documentation is frequently seen as an irritation for
developers, especially once a package is released. Getting them to add @doc
after they've moved on to the next thing requiring their attention, and
getting end users to update their packages just to get new docstrings, is
going to be a bigger challenge than providing the capability at the front
end and encouraging its use.

On Wednesday, December 17, 2014 12:17:33 PM UTC-8, John Myles White wrote:

This debate seems a little premature to me since the definition of @doc is
not totally finished yet and we need to finalize that before anyone should
be adding documentation to 0.3 packages.

-- John

On Dec 17, 2014, at 3:15 PM, Seth catc...@bromberger.com javascript:
wrote:

+1. Please reconsider making a @doc (at least a NOP) for 0.3.x - this way
we can start writing repl-printable docstrings that will be useful in 0.4
but not have our code break in earlier versions.

On Tuesday, December 16, 2014 4:50:56 PM UTC-8, ele...@gmail.com wrote:

So if otherwise unchanged code is documented with @doc (which it will be,
who doesn't want it to show in the repl :) then it won't compile on 0.3?

If it won't compile it makes maintaining backward compatibility harder,
and its hard enough between 0.4 and 0.3 already.

On Wednesday, December 17, 2014 9:04:53 AM UTC+10, Mike Innes wrote:

It is needed if you want the docs to show up in the repl etc. It's just
that the plain string won't break anything (it won't do anything, either,
for now).

On 16 December 2014 at 22:58, ele...@gmail.com wrote:

On Wednesday, December 17, 2014 8:41:00 AM UTC+10, Mike Innes wrote:

It's not really that worthwhile since (a) you can use Docile and (b)
the future syntax

foo

foo() ...

is backwards-compatible already. I just use that.

Oh, ok, I thought an @doc macro was needed in 0.4
https://github.com/JuliaLang/julia/blob/d0a951ccb3a7ebae7909665f4445a019f2ee54a1/base/basedocs.jl
.

Cheers
Lex

On 16 December 2014 at 22:37, ele...@gmail.com wrote:

Since the @doc is 0.4, is it possible to backport a do nothing
version that will allow documented code to still compile in 0.3?

Cheers
Lex

On Wednesday, December 17, 2014 8:04:06 AM UTC+10, Mike Innes wrote:

I'm in the process of writing documentation documentation, so the
manual should be up to date reasonably soon.

On 16 December 2014 at 21:55, Ivar Nesje iva...@gmail.com wrote:

Hi,

Hello.

Looks like exciting doc changes are afoot with Julia! I'd like to
get some more understanding of what's coming. Had a look at some of
the
github issues tagged doc, but I'm still missing some basics (note,
I'm
still quite new to Julia). Questions:

* Is code from Docile.jl, Lexicon.jl, and Markdown.jl being used
/ incorporated into Julia proper?

Yes.

* Will the new syntax be `doc ...`, `@doc ... -`, or
something else?

The - is probably going away, but final syntax is not yet set in
stone (nor in code).

* What is `mdSome *text* here`? Will Julia support and/or
require that for the new docstrings? If so, what is the benefit of
`mdthis` over `this`?

* Regarding the docs currently at http://docs.julialang.org/en/
release-0.3/, does all of that content currently come only from
the contents of julia/doc and below?

Yes

Re: [julia-users] Which licence to use for tutorial materials

2014-12-17 Thread Mauro

Wouldn't it be good if at least the code of tutorials is MIT
licensed. That way it could be used in the mostly MIT licensed packages
without hassle?

On Wed, 2014-12-17 at 09:31, Stefan Karpinski ste...@karpinski.org wrote:
 I'm not really sure. The Julia manual end up being MIT sort of by accident
 just because it's part of the julia repo and the MIT license applies to
 everything that doesn't have a different license indicated. Some CC license
 may be better.

 On Wed, Dec 17, 2014 at 11:39 AM, David P. Sanders dpsand...@gmail.com
 wrote:

 Hi,

 I would like to add a licence to my tutorial materials (
 https://github.com/dpsanders/scipy_2014_julia) so that people can reuse
 them.

 Is the MIT licence suitable for this, or should I be using a Creative
 Commons one or something else instead?
 Somehow a tutorial feels different from code. (And I would not
 particularly want my material to be reused for commercial purposes.)

 Thanks,
 David.

[julia-users] Re: Comparison of FE codes; Julia versus commercial FE solver

2014-12-17 Thread Alex Ames

Hi Petr,

In case you weren't aware, there's a Julia package for computation of 
arbitrary-order Gauss quadrature 
rules: https://github.com/billmclean/GaussQuadrature.jl

-Alex

On Tuesday, December 16, 2014 11:31:01 PM UTC-6, Petr Krysl wrote:

 Hello everybody,

 In case you're interested, here is the implementation so far.  Switch to 
 the top folder, and include one of the examples.
 If you have paraview, you could check the graphics output (enable graphics 
 export in the source).

 As always, I'm keen on getting feedback, so don't hesitate please.

 https://github.com/PetrKryslUCSD/jfineale_for_trying_out

 Petr

Re: [julia-users] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

2014-12-17 Thread David Smith

First off, good point, and thank you for PyPlot and PyCall.  I use these 
packages a ton.

But loading PyPlot is by far the slowest part of my code currently.  Maybe 
that will go away with module caching?  I was, perhaps incorrectly, 
thinking it was slow because it was Python.

Also passing stuff to Python is not always trivial.  I wasn't able to 
successfully plot masked arrays using PyPlot, for example.  I'm sure it can 
be done, but it was too complicated for me to figure out for too little 
gain.

On Wednesday, December 17, 2014 12:00:59 PM UTC-6, Steven G. Johnson wrote:



 On Tuesday, December 16, 2014 4:15:42 PM UTC-5, David Smith wrote:

 My biggest wish-list item (as a medical imager) would be native Julia 
 plotting that is similar to Matplotlib.  I'd rather not have to require 
 that people have Python alongside Julia.  Makes Julia sound less mature.  


 Julia *is* significantly less mature than Python, and for the next several 
 years (at least!) there will undoubtedly be lots of major functionality 
 that is available in Python but not in pure Julia.  Fortunately, pretty 
 much all of this functionality is accessible via PyCall.

 As a result, I pretty much always strongly recommend that people using 
 Julia also have a decent Python/SciPy installation (I recommend Anaconda on 
 Windows and Mac).   This is also needed if you want to use IJulia.

 I don't think we should be any more ashamed of calling Python for things 
 like plotting than we are ashamed of calling C and Fortran code for linear 
 algebra or Bessel functions.

 --SGJ

Re: [julia-users] Which licence to use for tutorial materials

Yes, it seems to me that unless there's a motivation for a different
license, it might well be a good idea to make free documentation available
under the MIT license, including the examples.

On Wed, Dec 17, 2014 at 4:12 PM, Mauro mauro...@runbox.com wrote:

 Wouldn't it be good if at least the code of tutorials is MIT
 licensed. That way it could be used in the mostly MIT licensed packages
 without hassle?

 On Wed, 2014-12-17 at 09:31, Stefan Karpinski ste...@karpinski.org
 wrote:
  I'm not really sure. The Julia manual end up being MIT sort of by
 accident
  just because it's part of the julia repo and the MIT license applies to
  everything that doesn't have a different license indicated. Some CC
 license
  may be better.
 
  On Wed, Dec 17, 2014 at 11:39 AM, David P. Sanders dpsand...@gmail.com
  wrote:
 
  Hi,
 
  I would like to add a licence to my tutorial materials (
  https://github.com/dpsanders/scipy_2014_julia) so that people can reuse
  them.
 
  Is the MIT licence suitable for this, or should I be using a Creative
  Commons one or something else instead?
  Somehow a tutorial feels different from code. (And I would not
  particularly want my material to be reused for commercial purposes.)
 
  Thanks,
  David.

[julia-users] Re: Comparison of FE codes; Julia versus commercial FE solver

2014-12-17 Thread Petr Krysl

Excellent! Missed that one...
P

On Wednesday, December 17, 2014 1:14:37 PM UTC-8, Alex Ames wrote:

 Hi Petr,

 In case you weren't aware, there's a Julia package for computation of 
 arbitrary-order Gauss quadrature rules: 
 https://github.com/billmclean/GaussQuadrature.jl

 -Alex

 On Tuesday, December 16, 2014 11:31:01 PM UTC-6, Petr Krysl wrote:

 Hello everybody,

 In case you're interested, here is the implementation so far.  Switch to 
 the top folder, and include one of the examples.
 If you have paraview, you could check the graphics output (enable 
 graphics export in the source).

 As always, I'm keen on getting feedback, so don't hesitate please.

 https://github.com/PetrKryslUCSD/jfineale_for_trying_out

 Petr

[julia-users] Re: Comparison of FE codes; Julia versus commercial FE solver



On Wednesday, December 17, 2014 4:14:37 PM UTC-5, Alex Ames wrote:

 Hi Petr,

 In case you weren't aware, there's a Julia package for computation of 
 arbitrary-order Gauss quadrature rules: 
 https://github.com/billmclean/GaussQuadrature.jl



And there's a somewhat fancier package at:   
https://github.com/ajt60gaibb/FastGaussQuadrature.jl

And if all you want are the plain gauss quadrature rules (no fancy weight 
functions), you can also use Base.QuadGK.gauss

[julia-users] Re: Comparison of FE codes; Julia versus commercial FE solver

2014-12-17 Thread Petr Krysl

Great. Normally I have no use for Gauss rules beyond order 4 (at most cubic 
finite elements in the library). But it is good to have access to arbitrary 
order.

Thanks!

P

On Wednesday, December 17, 2014 1:35:34 PM UTC-8, Steven G. Johnson wrote:

 In particular, it looks like you just need:

 param_coords, weights = Base.QuadGK.gauss(Float64, order)

 in your GaussRule function.

[julia-users] Re: Community Support for Julia on Travis CI

Has the old Travis technique stopped working?  My old Travis files are now 
giving me:

ErrorException(The dynamically loaded GMP library (version 5.0.2 with 
__gmp_bits_per_limb == 64)

Unfortunately, I'm not sure I can just set language: julia in PyCall.jl 
because it also has to run the tests with multiple versions of Python and 
I'm not sure how to enable that without language: python.

[julia-users] Re: Community Support for Julia on Travis CI

That sounds unrelated. Is that happening on nightlies, releases, or both?


On Wednesday, December 17, 2014 1:52:44 PM UTC-8, Steven G. Johnson wrote:

 Has the old Travis technique stopped working?  My old Travis files are now 
 giving me:

 ErrorException(The dynamically loaded GMP library (version 5.0.2 with 
 __gmp_bits_per_limb == 64)

 Unfortunately, I'm not sure I can just set language: julia in PyCall.jl 
 because it also has to run the tests with multiple versions of Python and 
 I'm not sure how to enable that without language: python.

[julia-users] Re: Community Support for Julia on Travis CI

On Wednesday, December 17, 2014 5:05:37 PM UTC-5, Tony Kelman wrote:

 That sounds unrelated. Is that happening on nightlies, releases, or both?


It was happening with PyCall.jl on nightlies, but I switched over to the 
new language: julia for now (albeit with only a single python version) and 
it has gone away.

[julia-users] Package development - best practices

I'm wondering whether folks are actually basing their repos in ~/.julia and 
doing their development and commits from there, or whether there's some 
other process that allows development to happen in a more standard location 
than a hidden directory off of ~ while still allowing use of Pkg. I'm 
probably overlooking something trivial.

What's a recommended setup/process for creating packages using Pkg to 
manage them?

[julia-users] Re: Community Support for Julia on Travis CI

That indicates a problem with the julianightlies PPA. `language: julia` on 
Travis doesn't use the PPA, in order to be able to install Julia without 
using sudo. We're using the generic Linux tarballs - which I think come 
with our desired version of libgmp bundled?


On Wednesday, December 17, 2014 2:14:34 PM UTC-8, Steven G. Johnson wrote:

 On Wednesday, December 17, 2014 5:05:37 PM UTC-5, Tony Kelman wrote:

 That sounds unrelated. Is that happening on nightlies, releases, or both?


 It was happening with PyCall.jl on nightlies, but I switched over to the 
 new language: julia for now (albeit with only a single python version) and 
 it has gone away.

Re: [julia-users] obscure error in Julia 0.3.3

Might be a good idea to package OpenBLAS for Arch, if you can't find an 
existing PKGBUILD.


On Tuesday, December 16, 2014 2:22:10 PM UTC-8, Milan Bouchet-Valat wrote:

 Le mardi 16 décembre 2014 à 13:27 -0800, Elliot Saba a écrit : 
  I think the problem here is that we might be using something that 
  requires a certain version of BLAS or LAPACK, or possibly a patched 
  LAPACK or something.  We get a patched LAPACK when we build OpenBLAS. 
  I've directly included Andreas in this reply, as he's the kind of guy 
  that would have a good idea as to what's going on here. 
 I don't think Julia needs a patched LAPACK, at least it builds fine on 
 Fedora with the system's LAPACK.  It's the one from OpenBLAS, not the 
 reference LAPACK, but it worked fine too with Julia 0.3.0 when I used 
 the latter (though it was slower). 

 FWIW the Fedora package sets USE_SYSTEM_*=1 for everything, except 
 libuv, Rmath and libm. Additional flags are 
 LIBBLAS=-lopenblasp LIBBLASNAME=libopenblasp.so.0 LIBLAPACK=-lopenblasp 
 LIBLAPACKNAME=libopenblasp.so.0 USE_BLAS64=0 

 Maybe using Julia's version of SuiteSparse together with the system 
 BLAS/LAPACK does not work? 


 Also, do you imply it worked fine with 0.3.2, and started randomly 
 failing only with 0.3.3? 


 Regards 


  On Tue, Dec 16, 2014 at 10:03 AM, Valentin Churavy 
  v.ch...@gmail.com javascript: wrote: 
  So I narrowed it down to combining the system's blas with 
  Julia's suitesparse. In the tests I made laplack has no 
  influence. Should I file an issue against Julia or with the 
  Archlinux package? What are the Fedora packages bundling? 
  
  
  USE_SYSTEM_BLAS=1 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  
  
  On Tuesday, 16 December 2014 18:07:23 UTC+1, Valentin Churavy 
  wrote: 
  Ok setting 
  USE_SYSTEM_BLAS=0 \ 
  USE_SYSTEM_LAPACK=0 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  
  Make the problem go away. So it is the interaction 
  between the system blas/lapack and the built 
  suitesparese. Are there any patches that julia carries 
  over suitesparse 4.4.1? 
  
  
  On Tuesday, 16 December 2014 17:28:28 UTC+1, Valentin 
  Churavy wrote: 
  So using 
  
  
  make  \   
  USE_SYSTEM_LLVM=0 \ 
  USE_SYSTEM_LIBUNWIND=1 \ 
  USE_SYSTEM_READLINE=0 \ 
  USE_SYSTEM_PCRE=1 \ 
  USE_SYSTEM_LIBM=1 \ 
  USE_SYSTEM_OPENLIBM=0 \ 
  USE_SYSTEM_OPENSPECFUN=0 \ 
  USE_SYSTEM_BLAS=1 \ 
  USE_SYSTEM_LAPACK=1 \ 
  USE_SYSTEM_FFTW=1 \ 
  USE_SYSTEM_GMP=1 \ 
  USE_SYSTEM_MPFR=1 \ 
  USE_SYSTEM_ARPACK=1 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  USE_SYSTEM_ZLIB=1 \ 
  USE_SYSTEM_GRISU=0 \ 
  USE_SYSTEM_RMATH=0 \ 
  USE_SYSTEM_LIBUV=0 \ 
  USE_SYSTEM_UTF8PROC=0 \ 
  USE_MKL=0 \ 
  USE_BLAS64=0 \ 
  USE_LLVM_SHLIB=0 
  
  
  leads to the error observed by me and Andrei, 
  can anybody not using Arch try that out? 
  
  On Tuesday, 16 December 2014 17:07:55 UTC+1, 
  Valentin Churavy wrote: 
  So building it from the PKGBUILD leads 
  to the same error. I am now building 
  it with the same make options from the 
  tar.gz on the Julia download page. 
  
  
  Andrei we probably have to build other 
  parts that interact with suitesparse 
  from source instead of using the Arch 
  ones. But if the problem persists 
  while using the tarball, then at least 
  other people on non-Arch distros can 
  try to see if it works for them and 
  which interaction leads to the error.

[julia-users] Re: Package development - best practices

2014-12-17 Thread David Smith

I'm very interested in this too.  

On Wednesday, December 17, 2014 4:21:44 PM UTC-6, Seth wrote:

 I'm wondering whether folks are actually basing their repos in ~/.julia 
 and doing their development and commits from there, or whether there's some 
 other process that allows development to happen in a more standard location 
 than a hidden directory off of ~ while still allowing use of Pkg. I'm 
 probably overlooking something trivial.

 What's a recommended setup/process for creating packages using Pkg to 
 manage them?

[julia-users] Re: Community Support for Julia on Travis CI

It seems to have been a temporary glitch; it's working again.

[julia-users] Re: Examples of integrating Fortran code in Julia

Also you're going to be better off using the MinGW-w64 cross-compilers, 
rather than the Cygwin's own gfortran. Try installing 
mingw64-x86_64-gcc-fortran through Cygwin's setup for 64 bit, or 
mingw64-i686-gcc-fortran for 32 bit. Then instead of calling gfortran to 
compile your Fortran code, call x86_64-w64-mingw32-gfortran (or 
i686-w64-mingw32-gfortran for 32 bit). Everything else should work more or 
less the same.


On Tuesday, December 16, 2014 6:04:43 PM UTC-8, Vathy M. Kamulete wrote:

 I posted this on StackOverflow. It was recommended I post here. See here 
 http://stackoverflow.com/q/27498755/1965432for background.

 Where can I find good examples of integrating (modern) Fortran code with 
 Julia? 

 I am using the GNU gfortran compiler (on Cygwin) for my own module. A good 
 example will hopefully start from the compilation stage, address mangled 
 names and call the subroutine from Julia via ccall. Most examples I've seen 
 skip the first two stages. On the SO post, I refer to Modern Fortran 
 explicitly because what I've seen so far tends to be for legacy code -- 
 think punchcard-style fixed-width formatting Fortran (that goes for GLMNet, 
 which was allegedly written in 2008 but adheres to those conventions).

 So imagine that I have the following module in Fortran90 file named 
 'f90tojl.f90':

 module m
 contains
integer function five()
   five = 5
end function five
 end module m

 This example is from here 
 http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_Fortran. I 
 compile it with gfortan as follows to create a shared library:

  gfortran -shared -O2 f90tojl.f90 -o -fPIC f90tojl.so

 And my, admittedly shaky, understanding from reading the julia docs 
 suggest that I should be able to call the function five like so:

 ccall( (:__m_MOD_five, f90tojl), Int, () )

 It didn't work for me. I get ''error compiling anonymous: could not load 
 module f90tojl... . Anyone cares to enlighten me? I got the sneaky sense 
 I'm doing something silly

 Thanks in advance,

 V.

[julia-users] writedlm deletes leading zeros

2014-12-17 Thread Roman Nelson

When writing a matrix of type Any into a text file with writedlm/wrirecsv 
leading zeros of floats are removed in the process. Julia version 0.3.3 under 
win7.

On screen:
Some text 0.1234

In file:
Some text .1234

This is really strange and I can't figure out why this is happening.

I have tried to change regional setttings, it doesn't help.

[julia-users] julia stable compile from julia-0.3.3_b24213b893.tar.gz

2014-12-17 Thread steven Varga

Hi,

I  compiled the latest git version of julia with MKL on linux Mint 17; most 
function (BLAS,LAPACK,...) worked however didn't stable for production use 
(Winston, Gladfly failed to load).   Then turned to the stable release 
which produces the following error:

 double_conversion_wrapper.cpp:1:31: fatal error: double-conversion.h: No 
such file or directory
 #include double-conversion.h

I tried the git then the tar version; the problem persisted; 
Can someone give me a hint what I am doing wrong?

steve

[julia-users] writedlm deletes leading zeros

2014-12-17 Thread Ivar Nesje

Can you post the exact code you use? There are many ways to print numbers in 
Julia, and they give different representations.

[julia-users] Random Draw from Gaussian Mixture

2014-12-17 Thread Bradley Setzler

Hi,

I wish to work with the Gaussian Mixture distribution (especially rand and 
pdf), exactly as in this example 
https://github.com/johnmyleswhite/MixtureModels.jl: 

mu = [0.0 25.0; 0.0 25.0] 
sigma = Array(Float64, 2, 2, 2) 
sigma[:, :, 1] = [1.0 0.9; 0.9 1.0] 
sigma[:, :, 2] = 7.5 * [1.0 0.0; 0.0 1.0] 
p = [0.9, 0.1] 

distr = MixtureMultivariateNormals(mu, sigma, p) 
X = rand(distr, 10_000)


However, the method MixtureMultivariateNormals(mu, sigma, p) used in that 
example no longer exists. The maintained version of MixtureModels.jl 
https://github.com/lindahua/MixtureModels.jl has no examples or methods 
in the documentation of basic usage, and it is far from obvious how to use 
it for a Gaussian mixture.

Separately, the package GaussianMixtures.jl 
https://github.com/davidavdav/GaussianMixtures.jl, does not successfully 
work in what would seem to be the obvious method:

julia GMM(p,mu,sigma)
ERROR: `GMM{T:FloatingPoint,CT:Union(Array{T,2},Array{T,1})}` has no 
method matching 
GMM{T:FloatingPoint,CT:Union(Array{T,2},Array{T,1})}(::Array{Float64,1}, 
::Array{Float64,2}, ::Array{Float64,2})

Could someone show me a working example analogous to the one above, using 
whichever package you wish?

Thank you,
Bradley

[julia-users] Importing a file with a parameter

2014-12-17 Thread bronstein

Hi. I import a rj file and I need to change a parameter in it from console. 
That is there is an important function which depends on this parameter and 
there are many functions which depend on this important function. I can 
only do this by definin a global variable which is not advised. Is there 
any other way ?

[julia-users] Re: Package development - best practices

2014-12-17 Thread Jason Merrill

I do my development in ~/.julia. I agree that it seemed weird at first, but 
it works fine for me.

If you prefer to organize your packages somewhere else, would a symlink be 
sufficient?

On Wednesday, December 17, 2014 2:21:44 PM UTC-8, Seth wrote:

 I'm wondering whether folks are actually basing their repos in ~/.julia 
 and doing their development and commits from there, or whether there's some 
 other process that allows development to happen in a more standard location 
 than a hidden directory off of ~ while still allowing use of Pkg. I'm 
 probably overlooking something trivial.

 What's a recommended setup/process for creating packages using Pkg to 
 manage them?

[julia-users] Re: Package development - best practices

Thanks for sharing your setup. Symlinks would have to work in a specific 
way, since I develop in my Dropbox shared folder, and thus the links would 
have to be from ~/.julia to DB. That may cause some issues... I don't know 
but will give it a test.

...anyone else do things differently?

On Wednesday, December 17, 2014 4:21:02 PM UTC-8, Jason Merrill wrote:

 I do my development in ~/.julia. I agree that it seemed weird at first, 
 but it works fine for me.

 If you prefer to organize your packages somewhere else, would a symlink be 
 sufficient?

 On Wednesday, December 17, 2014 2:21:44 PM UTC-8, Seth wrote:

 I'm wondering whether folks are actually basing their repos in ~/.julia 
 and doing their development and commits from there, or whether there's some 
 other process that allows development to happen in a more standard location 
 than a hidden directory off of ~ while still allowing use of Pkg. I'm 
 probably overlooking something trivial.

 What's a recommended setup/process for creating packages using Pkg to 
 manage them?

Re: [julia-users] obscure error in Julia 0.3.3

2014-12-17 Thread Valentin Churavy

There is an AUR pkgbuild, but since Julia is in community we can not depend 
on that. But yeah the system BLAS seems to be at fault. I added the Arch 
maintainer of Julia to the conversation.

@Alexander.
There seems to be an issue with the BLAS implementation for Julia. Would it 
be possible to use OpenBLAS either via moving the pkgbuild from the aur to 
community or build Julia with USE_SYSTEM_BLAS=0?


On Wednesday, 17 December 2014 23:26:54 UTC+1, Tony Kelman wrote:

 Might be a good idea to package OpenBLAS for Arch, if you can't find an 
 existing PKGBUILD.


 On Tuesday, December 16, 2014 2:22:10 PM UTC-8, Milan Bouchet-Valat wrote:

 Le mardi 16 décembre 2014 à 13:27 -0800, Elliot Saba a écrit : 
  I think the problem here is that we might be using something that 
  requires a certain version of BLAS or LAPACK, or possibly a patched 
  LAPACK or something.  We get a patched LAPACK when we build OpenBLAS. 
  I've directly included Andreas in this reply, as he's the kind of guy 
  that would have a good idea as to what's going on here. 
 I don't think Julia needs a patched LAPACK, at least it builds fine on 
 Fedora with the system's LAPACK.  It's the one from OpenBLAS, not the 
 reference LAPACK, but it worked fine too with Julia 0.3.0 when I used 
 the latter (though it was slower). 

 FWIW the Fedora package sets USE_SYSTEM_*=1 for everything, except 
 libuv, Rmath and libm. Additional flags are 
 LIBBLAS=-lopenblasp LIBBLASNAME=libopenblasp.so.0 LIBLAPACK=-lopenblasp 
 LIBLAPACKNAME=libopenblasp.so.0 USE_BLAS64=0 

 Maybe using Julia's version of SuiteSparse together with the system 
 BLAS/LAPACK does not work? 


 Also, do you imply it worked fine with 0.3.2, and started randomly 
 failing only with 0.3.3? 


 Regards 


  On Tue, Dec 16, 2014 at 10:03 AM, Valentin Churavy 
  v.ch...@gmail.com wrote: 
  So I narrowed it down to combining the system's blas with 
  Julia's suitesparse. In the tests I made laplack has no 
  influence. Should I file an issue against Julia or with the 
  Archlinux package? What are the Fedora packages bundling? 
  
  
  USE_SYSTEM_BLAS=1 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  
  
  On Tuesday, 16 December 2014 18:07:23 UTC+1, Valentin Churavy 
  wrote: 
  Ok setting 
  USE_SYSTEM_BLAS=0 \ 
  USE_SYSTEM_LAPACK=0 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  
  Make the problem go away. So it is the interaction 
  between the system blas/lapack and the built 
  suitesparese. Are there any patches that julia carries 
  over suitesparse 4.4.1? 
  
  
  On Tuesday, 16 December 2014 17:28:28 UTC+1, Valentin 
  Churavy wrote: 
  So using 
  
  
  make  \   
  USE_SYSTEM_LLVM=0 \ 
  USE_SYSTEM_LIBUNWIND=1 \ 
  USE_SYSTEM_READLINE=0 \ 
  USE_SYSTEM_PCRE=1 \ 
  USE_SYSTEM_LIBM=1 \ 
  USE_SYSTEM_OPENLIBM=0 \ 
  USE_SYSTEM_OPENSPECFUN=0 \ 
  USE_SYSTEM_BLAS=1 \ 
  USE_SYSTEM_LAPACK=1 \ 
  USE_SYSTEM_FFTW=1 \ 
  USE_SYSTEM_GMP=1 \ 
  USE_SYSTEM_MPFR=1 \ 
  USE_SYSTEM_ARPACK=1 \ 
  USE_SYSTEM_SUITESPARSE=0 \ 
  USE_SYSTEM_ZLIB=1 \ 
  USE_SYSTEM_GRISU=0 \ 
  USE_SYSTEM_RMATH=0 \ 
  USE_SYSTEM_LIBUV=0 \ 
  USE_SYSTEM_UTF8PROC=0 \ 
  USE_MKL=0 \ 
  USE_BLAS64=0 \ 
  USE_LLVM_SHLIB=0 
  
  
  leads to the error observed by me and Andrei, 
  can anybody not using Arch try that out? 
  
  On Tuesday, 16 December 2014 17:07:55 UTC+1, 
  Valentin Churavy wrote: 
  So building it from the PKGBUILD leads 
  to the same error. I am now building 
  it with the same make options from the 
  tar.gz on the Julia download page. 
  
  
  Andrei we probably have to build other 
  parts that interact

Re: [julia-users] Rust and Julia - Together? Advice

2014-12-17 Thread Eric Forgy

Thank you Viral and thank you Stefan.

The Rust solution would be an interesting and longer term effort because the 
person I would rely on to do most of the development is not yet ready to take 
the Rust plunge until it matures/stabilizes a bit more.

The other two ideas REST and zeromq look interesting and I'd like to learn 
more. I spent what little available time I had yesterday reading about message 
queueing with zeromq and others. That is very interesting stuff. I had a quick 
look at JuliaBox. That is pretty awesome :) I would love to understand how it 
works. Like I said, I am pretty much a blank slate and learning everything as I 
go, so looking at the JuliaBox code, it wasn't immediately obvious (.t? .lua? 
:)). Does there exist a simple document describing the process flow of how 
JuliaBox works?

In very general terms, could you help sketch out and point me to some reading 
material to help me make progress building a RESTful interface to Julia running 
on a server? Should it be built entirely in Julia? Is it already done in 
JuliaBox or elsewhere? I think initially, I will focus on REST. Another 
platform (OpenGamma) I'm working with also has a RESTful API so any effort I 
make will not be wasted even if I eventually start work with zeromq (which I 
probably will).

Thank you again.

Cheers,
Eric

Re: [julia-users] Package development - best practices

2014-12-17 Thread Keno Fischer

Personally, I do develop my packages inside .julia.
If I need to sync across machines, I'll just use git, which I should be
doing more anyway (admittedly this can get annoying when developing on two
machines at the same time, in which case I tend to add the remote julia
instance as a worker and ship code that way).

On Wed, Dec 17, 2014 at 5:21 PM, Seth catch...@bromberger.com wrote:

 I'm wondering whether folks are actually basing their repos in ~/.julia
 and doing their development and commits from there, or whether there's some
 other process that allows development to happen in a more standard location
 than a hidden directory off of ~ while still allowing use of Pkg. I'm
 probably overlooking something trivial.

 What's a recommended setup/process for creating packages using Pkg to
 manage them?

Re: [julia-users] Rust and Julia - Together? Advice

2014-12-17 Thread Steve Kelly

I am currently building a path planner for 3D printers in Julia. We are
also using a ZeroMQ interface to separate the web interface from the path
planner. This is working very well for us now. We will also be using
JuliaBox for packaging our application.

On Wed, Dec 17, 2014 at 8:05 PM, Eric Forgy eric.fo...@gmail.com wrote:

 Thank you Viral and thank you Stefan.

 The Rust solution would be an interesting and longer term effort because
 the person I would rely on to do most of the development is not yet ready
 to take the Rust plunge until it matures/stabilizes a bit more.

 The other two ideas REST and zeromq look interesting and I'd like to learn
 more. I spent what little available time I had yesterday reading about
 message queueing with zeromq and others. That is very interesting stuff. I
 had a quick look at JuliaBox. That is pretty awesome :) I would love to
 understand how it works. Like I said, I am pretty much a blank slate and
 learning everything as I go, so looking at the JuliaBox code, it wasn't
 immediately obvious (.t? .lua? :)). Does there exist a simple document
 describing the process flow of how JuliaBox works?

 In very general terms, could you help sketch out and point me to some
 reading material to help me make progress building a RESTful interface to
 Julia running on a server? Should it be built entirely in Julia? Is it
 already done in JuliaBox or elsewhere? I think initially, I will focus on
 REST. Another platform (OpenGamma) I'm working with also has a RESTful API
 so any effort I make will not be wasted even if I eventually start work
 with zeromq (which I probably will).

 Thank you again.

 Cheers,
 Eric

[julia-users] Best way to minimize memory allocation in iterative method?

2014-12-17 Thread DumpsterDoofus

So I have a piece of code with 4 Float arrays (let's call them temp, arr1, 
arr2, arr3), and this is basically what happens:

for i in [1:1000]
# Some code that modifies the entries of temp.
arr1 = 2*arr2 - arr3 + constants*temp
arr3 = arr2
arr2 = arr1
end

As it turns out, the #Some code that... step is actually only 1/3 of the 
execution time, i.e., the majority of the execution time is in the 3 lines 
which juggle arr1, arr2 and arr3. Using the @time macro also shows that 
most of the memory allocation and garbage collection is occurring in those 
3 steps.

What, if anything, is the best way to minimize memory allocation time in 
such a situation?

[julia-users] Best way to minimize memory allocation in iterative method?

Just write a single loop; all do those updates can be done in place.

Re: [julia-users] Package development - best practices

2014-12-17 Thread John Myles White

I also develop in .julia, but it's possible to use any directory as your 
package directory. The manual should have some sections that describe how to 
configure an alternative to .julia.

 -- John

On Dec 17, 2014, at 8:15 PM, Keno Fischer kfisc...@college.harvard.edu wrote:

 Personally, I do develop my packages inside .julia. 
 If I need to sync across machines, I'll just use git, which I should be doing 
 more anyway (admittedly this can get annoying when developing on two machines 
 at the same time, in which case I tend to add the remote julia instance as a 
 worker and ship code that way).
 
 On Wed, Dec 17, 2014 at 5:21 PM, Seth catch...@bromberger.com wrote:
 I'm wondering whether folks are actually basing their repos in ~/.julia and 
 doing their development and commits from there, or whether there's some other 
 process that allows development to happen in a more standard location than a 
 hidden directory off of ~ while still allowing use of Pkg. I'm probably 
 overlooking something trivial.
 
 What's a recommended setup/process for creating packages using Pkg to manage 
 them?

Re: [julia-users] Rust and Julia - Together? Advice

I can also attest that connecting a Julia process to other processes with
ZeroMQ is a very good way to go – it's reliable and easy and quite
efficient. ZMQ gives many side benefits too. Probably easier than
developing a full-blown REST interface, imo.

On Wed, Dec 17, 2014 at 8:43 PM, Steve Kelly kd2...@gmail.com wrote:

 I am currently building a path planner for 3D printers in Julia. We are
 also using a ZeroMQ interface to separate the web interface from the path
 planner. This is working very well for us now. We will also be using
 JuliaBox for packaging our application.

 On Wed, Dec 17, 2014 at 8:05 PM, Eric Forgy eric.fo...@gmail.com wrote:

 Thank you Viral and thank you Stefan.

 The Rust solution would be an interesting and longer term effort because
 the person I would rely on to do most of the development is not yet ready
 to take the Rust plunge until it matures/stabilizes a bit more.

 The other two ideas REST and zeromq look interesting and I'd like to
 learn more. I spent what little available time I had yesterday reading
 about message queueing with zeromq and others. That is very interesting
 stuff. I had a quick look at JuliaBox. That is pretty awesome :) I would
 love to understand how it works. Like I said, I am pretty much a blank
 slate and learning everything as I go, so looking at the JuliaBox code, it
 wasn't immediately obvious (.t? .lua? :)). Does there exist a simple
 document describing the process flow of how JuliaBox works?

 In very general terms, could you help sketch out and point me to some
 reading material to help me make progress building a RESTful interface to
 Julia running on a server? Should it be built entirely in Julia? Is it
 already done in JuliaBox or elsewhere? I think initially, I will focus on
 REST. Another platform (OpenGamma) I'm working with also has a RESTful API
 so any effort I make will not be wasted even if I eventually start work
 with zeromq (which I probably will).

 Thank you again.

 Cheers,
 Eric

Re: [julia-users] THANKS to Julia core developers!

2014-12-17 Thread SVAKSHA

On Wed, Dec 17, 2014 at 4:52 PM, cdm cdmclean@gmail.com wrote:
 setting up something on

https://gittip.com/   |   https://gratipay.com/

Don't these have a limit on the donations received per week? IIRC, it
was USD25/week. Not sure.
Also its mostly a platform for individual foss volunteers to get
tipped regularly on a weekly basis, and if you live outside the US
(like Viral) there is no way of cashing out - fwiw, the local bank/tax
charges would be higher than the tips you receive weekly, not to
mention how you'd explain that in your tax returns.
Something to think about before finalizing the donation platform.
/thinking out loud
SVAKSHA ॥  http://about.me/svaksha  ॥

Re: [julia-users] THANKS to Julia core developers!