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

[Michele Zaffalon]

>
> (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.)
>

And the emphasis is on the perverse, I assume.

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

[Ismael VC]

I also thought it was repetitive and over-complicated, which made me try 
using eval the way I did, since that is what I've seen in some Julia code. 
But since that NPR is a public example, It made me think about asking you 
guys, because I wanted it to be good code (which is now!) I'll try to port 
many tasks this vacations, out of the python implementations, since that is 
all I know for know.

Thank you four updating it!

I have been looking at J examples, and Julia beats in readability, which is 
something that matters a lot to me, it's super easy to explain basic syntax 
to my friends. 

El lunes, 15 de diciembre de 2014 02:47:46 UTC-6, Ismael VC escribió:
>
> Hello everyone!
>
>  I would really love to hear any opinions about this code from you guys. I 
> just ported it from a Python version in a `rosettacode.com` task, and 
> made my first question about it at code review, here:
>
>
> http://codereview.stackexchange.com/questions/73685/julia-rpn-calculator-algorithm-ported-from-python-version
>
> Thanks in advance! :D
>
>
>

Re: [julia-users] writedlm deletes leading zeros

[Jameson Nash]

https://github.com/JuliaLang/julia/blob/59b6080e0a75dbe88b4890189ef02f2dbf4164ea/base/datafmt.jl#L489

writecsv dispatches to print_shortest for the numerical formatting:

io=IOBuffer();

julia> print_shortest(io,0.1234);

julia> takebuf_string(io)
".1234"

i'm not sure i would necessarily classify this as incorrect, since it is
printing the correct value. there is a todo note in the code noting that
users might want more control over the output format.


On Thu Dec 18 2014 at 1:13:40 AM Roman Nelson 
wrote:

> The code is standard:
>
> writecsv("C:\\Data\\test.csv", output)
>
> writedlm has the same issue. output is a matrix of type Any with text and
> numeric entries.

[julia-users] writedlm deletes leading zeros

[Roman Nelson]

The code is standard:

writecsv("C:\\Data\\test.csv", output)

writedlm has the same issue. output is a matrix of type Any with text and 
numeric entries.

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

[Eric Forgy]

Sounds good. I'll focus on zeromq first. Thank you :)

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

[Stefan Karpinski]

These are good points, Svaksha. I don't think we should go with one of
these tipping platforms. Julia is part of NumFocus – a 501(c)(3) that can
accept donations. If anyone wants to donate to Julia development, you can
do it right now from this page:

http://numfocus.org/projects/index.html


We can figure out a membership plan too, but it's already possible to take
money directly for Julia development.

On Wed, Dec 17, 2014 at 11:36 PM, SVAKSHA  wrote:

> On Wed, Dec 17, 2014 at 4:52 PM, cdm  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.
> 
> SVAKSHA ॥  http://about.me/svaksha  ॥
>

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

[SVAKSHA]

On Wed, Dec 17, 2014 at 4:52 PM, cdm  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.

SVAKSHA ॥  http://about.me/svaksha  ॥

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

[Stefan Karpinski]

Also note that instead of `for i in [1:1000]` you can do `for i in 1:1000`
for the same effect with no allocation.

On Wed, Dec 17, 2014 at 9:35 PM, Steven G. Johnson 
wrote:

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

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

[Stefan Karpinski]

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  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  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] Package development - best practices

[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  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  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] Best way to minimize memory allocation in iterative method?

[Steven G. Johnson]

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

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

[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?

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

[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  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] Package development - best practices

[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  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

[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] obscure error in Julia 0.3.3

[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 
> >  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. 
> > 
> > 

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

[Seth]

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?
>>
>

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

[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] Importing a file with a parameter

[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] Random Draw from Gaussian Mixture

[Bradley Setzler]

Hi,

I wish to work with the Gaussian Mixture distribution (especially rand and 
pdf), exactly as in this example 
: 

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 
 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 
, 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] writedlm deletes leading zeros

[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] writedlm deletes leading zeros

[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

[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] Re: Examples of integrating Fortran code in Julia

[Tony Kelman]

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 
> for 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 
> . 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] Re: Community Support for Julia on Travis CI

[Steven G. Johnson]

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

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

[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?
>

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

[Tony Kelman]

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 
> > > 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 
> >   

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

[Tony Kelman]

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.
>

[julia-users] Package development - best practices

[Seth]

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

[Steven G. Johnson]

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] Re: Community Support for Julia on Travis CI

[Tony Kelman]

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

[Steven G. Johnson]

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: Comparison of FE codes; Julia versus commercial FE solver

[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: Comparison of FE codes; Julia versus commercial FE solver

[Steven G. Johnson]

In particular, it looks like you just need:

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

in your GaussRule function.

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

[Steven G. Johnson]

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

[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
>>
>>

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

[Stefan Karpinski]

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  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 
> 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 
> > 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] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

[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
>

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

[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] Which licence to use for tutorial materials

[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  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 
> 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)

[Seth]

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 > 
> 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,  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,  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  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 `md"Some *text* here`? Will Julia support and/or 
 require that for the new docstrings? If so, what is the benefit of 
 `md"this"` over `"this"`?

 The benefit is that `md"this"` 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 
>>>

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

[Tim Holy]

Just add this to your modules:

if VERSION < v"0.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,  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,  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  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 `md"Some *text* here`? Will Julia support and/or require
> >>> 
> >>> that for the new docstrings? If so, what is the benefit of
> >>> `md"this"` over
> >>> `"this"`?
> >>> 
> >>> The benefit is that `md"this"` 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  >>> 
> >>> 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)

[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  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,  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,  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  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 `md"Some *text* here`? Will Julia support and/or require that for 
> the new docstrings? If so, what is the benefit of `md"this"` over `"this"`?
> 
> The benefit is that `md"this"` 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 
> , 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)

[Seth]

+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,  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,  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  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 `md"Some *text* here`? Will Julia support and/or require 
>>> that for the new docstrings? If so, what is the benefit of `md"this"` 
>>> over 
>>> `"this"`?
>>>
>>> The benefit is that `md"this"` 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 >> 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] Which licence to use for tutorial materials

[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  > 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] THANKS to Julia core developers!

[Douglas Bates]

On Tuesday, December 16, 2014 5:50:12 PM UTC-6, 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.
>

I''m glad to hear you say that.  I was wondering whether your comment was 
serious or not.
 

>  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.
>

I am quite optimistic that the Julia community will not evolve the way that 
R did.  Two reasons for this are:

1. Stefan, Jeff and Viral are surprisingly well adjusted for such 
technically accomplished people.  :-)

2. I really do think that github and the other tools used for developing 
Julia encourage "social coding".  I believe that over 300 people have 
contributed to github.com/JuliaLang/julia in the few years that the project 
has been on github.  That is incredible.
 

> 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.
>
>
>
>
>

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

[Steven G. Johnson]

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

[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  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] Julia iPython notebook doesn't display inline graphics

[Steven G. Johnson]

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] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

[Steven G. Johnson]

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

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

[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 Q&As 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] Which licence to use for tutorial materials

[Stefan Karpinski]

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 
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] Non-central F distribution

[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 >: 
> > > 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

[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 >:
>>
>>
>> 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!

[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  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] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

[Tim Holy]

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  > 
> > > 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 
>  
>  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 ' 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] Calling Julia from Java (Java--->Julia)

[cdm]

for some additional context on the Java REPL:

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


etc.

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

[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  > 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
>>
>>

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

[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.

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

[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.

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

[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

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

[Viral Shah]

> On 17-Dec-2014, at 9:00 pm, Stefan Karpinski  wrote:
> 
> On Tue, Dec 16, 2014 at 6:50 PM, 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 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] Rust and Julia - Together? Advice

[Stefan Karpinski]

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
 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  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] Calling Julia from Java (Java--->Julia)

[Isaiah Norton]

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  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] THANKS to Julia core developers!

[Stefan Karpinski]

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 
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  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] THANKS to Julia core developers!

[Stefan Karpinski]

On Tue, Dec 16, 2014 at 6:50 PM, 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 is certainly something to watch out for. I'm willing to bully people
into being nice :-P

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

[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] How do I turn a string into a variable

[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  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

[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  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.

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

[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] ANN: DCEMRI.jl - a dynamic contrast enhanced MRI analysis module for Julia

[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  > 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  
 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 ' 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] Re: MatrixDepot.jl: A Test Matrix Collection

[Weijian Zhang]

Hello, 

Just want to let you know that MatrixDepot v0.0.3 
 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] Re: overview questions about new doc changes (coming with v 0.4)

[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 `md"Some *text* here`? Will Julia support and/or require 
> that 
> > >> 
> > >> for the new docstrings? If so, what is the benefit of `md"this"` over 
> > >> `"this"`? 
> > >> 
> > >> The benefit is that `md"this"` 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)

[Tim Holy]

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 `md"Some *text* here`? Will Julia support and/or require that
> >> 
> >> for the new docstrings? If so, what is the benefit of `md"this"` over
> >> `"this"`?
> >> 
> >> The benefit is that `md"this"` 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] THANKS to Julia core developers!

[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 ) 
> 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  > 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

[Tim Holy]

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 :
> > 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,

[julia-users] Re: Documentation in the source code

[Michael Hatherly]

Another option might be to simply have a global variable in Lexicon.jl that 
tell ? how much the user wants to see.

That’s definitely a possibility.

Or maybe using TermWin.jl  to 
expand different sections of a docstring interactively, though I’ve not 
explored that option at all.

 Thanks again for your help

No prob.

— Mike
​


On Wednesday, 17 December 2014 08:24:41 UTC+2, Christoph Ortner wrote:
>
>
> Another option might be to simply have a global variable in Lexicon.jl 
> that tell ? how much the user wants to see.
>
> But will 0.4 completely supersede this? Then probably not worth the effort.
>
> Thanks again for your help,
>Christoph
>
> On Tuesday, 16 December 2014 15:38:31 UTC, Michael Hatherly wrote:
>>
>> I guess, this makes ? behave like @query.
>>
>> Yes, it modifies, here 
>> ,
>>  
>> the Base.active_repl object so that ? mode calls
>> @help followed by @query. This only works in the Julia REPL. None of the
>> editors support this currently.
>>
>> Is there a way to limit how much output is shown? E.g., I may want to 
>> “just” show the docstring, but nothing else?
>>
>> I’ve not been able to come up with a nice clean way to limit what’s shown 
>> on a per-query basis, but I’d also certainly like to resolve this. Perhaps 
>> something like:
>>
>> help?> foobar # show a short summary of “foobar”
>>
>> help?> foobar +   # show all the docs on “foobar”
>>
>> might work nicely, or something similar.
>>
>> — Mike
>>
>> On Tuesday, 16 December 2014 15:57:27 UTC+2, Christoph Ortner wrote:
>>
>>
>>> ah - thank you, I finally got it to work. In the past, I did not call 
>>> "using Lexicon" in the REPL first.
>>>
>>> I guess, this makes ? behave like @query. 
>>>
>>> Is there a way to limit how much output is shown? E.g., I may want to 
>>> "just" show the docstring, but nothing else?
>>>
>>> Thanks for your help. (And also for initialising this documentation 
>>> facility - I am writing a large code in Julia, and this will be extremely 
>>> useful.)
>>> Christoph
>>>
>>>
>>> On Tuesday, 16 December 2014 06:47:46 UTC, Michael Hatherly wrote:

 Hi Christoph,

 The combo of Docile.jl *and* Lexicon.jl 
 
  
 should give you package help when using the REPL’s ? command in 0.3. 
 Let me know if you run into any problems with it. Also, for documenting 
 both version 0.3 and 0.4 you should be able to just wrap the Docile 
 import in an if statement like so:

 if VERSION < v"0.4-"
 using Docile
 end

 Hopefully that should “just work”.

 — Mike
 ​

 On Tuesday, 16 December 2014 08:17:20 UTC+2, Christoph Ortner wrote:
>
>
> Should the Docile @doc strings be displayed in the REPL using `?` ? Or 
> is this only coming with 0.4?
>
> Christoph
>
> ​
>>
>

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

[Michael Hatherly]

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 `md"Some *text* here`? Will Julia support and/or require that 
>> for the new docstrings? If so, what is the benefit of `md"this"` over 
>> `"this"`? 
>>
>> The benefit is that `md"this"` 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: overview questions about new doc changes (coming with v 0.4)

[jgabriele382]

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 `md"Some *text* here`? Will Julia support and/or require that 
> for the new docstrings? If so, what is the benefit of `md"this"` over 
> `"this"`? 
>
> The benefit is that `md"this"` 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