[julia-users] Re: BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Tony Kelman]

sounds like the library can't handle out of tree builds? you should also use a 
local prefix, not a system-wide one that would require sudo.

[julia-users] Re: Representation of a material conditional (implication)

[Kevin Liu]

Thanks Fengyang

On Saturday, October 8, 2016 at 12:39:42 AM UTC-3, Fengyang Wang wrote:
>
> As Jussi Piitulainen noted, the ^ operator is backwards, so you need to 
> wrap it around a function.
>
> On Friday, October 7, 2016 at 10:05:34 AM UTC-4, Kevin Liu wrote:
>>
>> *julia> **@code_native(b^a)*
>>
>>.section__TEXT,__text,regular,pure_instructions
>>
>> Filename: bool.jl
>>
>> Source line: 39
>>
>>pushq   %rbp
>>
>>movq%rsp, %rbp
>>
>> Source line: 39
>>
>>xorb$1, %sil
>>
>>orb %dil, %sil
>>
>>movb%sil, %al
>>
>>popq%rbp
>>
>>ret
>>
>> *julia> **@code_native(a<=b)*
>>
>>.section__TEXT,__text,regular,pure_instructions
>>
>> Filename: bool.jl
>>
>> Source line: 29
>>
>>pushq   %rbp
>>
>>movq%rsp, %rbp
>>
>> Source line: 29
>>
>>xorb$1, %dil
>>
>>orb %sil, %dil
>>
>>movb%dil, %al
>>
>>popq%rbp
>>
>>ret
>>
>> *julia> **@code_native(ifelse(a,b,true))*
>>
>>.section__TEXT,__text,regular,pure_instructions
>>
>> Filename: operators.jl
>>
>> Source line: 48
>>
>>pushq   %rbp
>>
>>movq%rsp, %rbp
>>
>>testb   $1, %dil
>>
>> Source line: 48
>>
>>jne L17
>>
>>movb%dl, %sil
>>
>> L17:   movb%sil, %al
>>
>>popq%rbp
>>
>>ret
>>
>>
>>
>> On Friday, October 7, 2016 at 10:58:34 AM UTC-3, Kevin Liu wrote:
>>>
>>> *julia> **@code_llvm(b^a)*
>>>
>>>
>>> define i1 @"julia_^_21646"(i1, i1) {
>>>
>>> top:
>>>
>>>   %2 = xor i1 %1, true
>>>
>>>   %3 = or i1 %0, %2
>>>
>>>   ret i1 %3
>>>
>>> }
>>>
>>> On Friday, October 7, 2016 at 10:56:26 AM UTC-3, Kevin Liu wrote:

 Sorry, no need, I got this

 *julia> **@code_llvm(a<=b)*


 define i1 @"julia_<=_21637"(i1, i1) {

 top:

   %2 = xor i1 %0, true

   %3 = or i1 %1, %2

   ret i1 %3

 }


 *julia> **@code_llvm(ifelse(a,b,true))*


 define i1 @julia_ifelse_21636(i1, i1, i1) {

 top:

   %3 = select i1 %0, i1 %1, i1 %2

   ret i1 %3

 }


 How do you read this output?

 On Friday, October 7, 2016 at 10:50:57 AM UTC-3, Kevin Liu wrote:
>
> Jeffrey, can you show the expression you put inside @code_llvm() and 
> @code_native() for evaluation? 
>
> On Friday, October 7, 2016 at 2:26:56 AM UTC-3, Jeffrey Sarnoff wrote:
>>
>> Hi Jussi,
>>
>> Your version compiles down more neatly than the ifelse version. On my 
>> system, BenchmarkTools gives nearly identical results; I don't know why, 
>> but the ifelse version is consistently a smidge faster (~%2, relative 
>> speed). Here is the llvm code and local native code for each, your 
>> version 
>> looks more tidy.  
>>
>>
>> ```
>> implies(p::Bool, q::Bool) = (p <= q)  implies(p::Bool, 
>> q::Bool) = ifelse( p, q, true )
>>
>> # llvm
>>
>>   %2 = xor i8 %0, 1%2 = and i8 %0, 1
>>   %3 = or i8 %2, %1%3 = icmp eq i8 
>> %2, 0
>>   ret i8 %3%4 = select i1 %3, 
>> i8 1, i8 %1
>>ret i8 %3
>>
>> # native with some common code removed
>>
>> xorb   $1, %diltestb  $1, %dil
>> orb%sil, %dil  movb   $1, %al
>> movb   %dil, %al   je L15
>> popq   %rbpmovb   %sil, %al
>> retq L15:  popq   %rbp
>>retq
>> ```
>>
>>
>>
>>
>> On Friday, October 7, 2016 at 12:22:23 AM UTC-4, Jussi Piitulainen 
>> wrote:
>>>
>>>
>>> implies(p::Bool, q::Bool) = p <= q
>>>
>>>
>>>
>>> torstai 6. lokakuuta 2016 19.10.51 UTC+3 Kevin Liu kirjoitti:

 How is an implication represented in Julia? 


 https://en.wikipedia.org/wiki/Material_conditional#Definitions_of_the_material_conditional

>>>

Re: [julia-users] Re: translating julia

[Ismael Venegas Castelló]

I'll leave this references here.

Attract more contributors to i18n #428

https://github.com/JuliaLang/julialang.github.com/issues/428

Julia-i18n dashboard

https://github.com/Julia-i18n/julia-i18n/projects/1

Re: [julia-users] ANN: RawArray.jl

[Páll Haraldsson]

On Monday, September 26, 2016 at 1:59:15 PM UTC, David Smith wrote:
>
> Hi, Isaiah. This is a valid question.
>
> 0. As a preface, I'd like to say I'm not trying to replace anything. I 
> wrote RawArray to solve a problem we have in magnetic resonance imaging 
> (quickly saving and loading large complex float arrays), and then I decided 
> to share it so if other people like it and find it useful, then cool beans.
>
> Now for the mild stumping...
>
> 1. I don't think NRRD is as substantially used as you might think. I've 
> worked in imaging science for years on the data processing/file format end, 
> and I've never seen anyone use it, and I've never even heard of it.  (Pity, 
> because it looks nice enough. :-\)
>
> 2. RawArray is simpler to handle and trivial to understand. I believe all 
> you need from an I/O library is I/O.* I don't want my file I/O library 
> performing transformations on my data. 
>
> I also don't need it to read image formats. Part of the reason behind 
> RawArray is to avoid standard image formats because they are not optimized 
> for large complex-float arrays. I just want to save multi-GB data arrays to 
> disk quickly and read them back quickly on a different machine, five years 
> later. 
>
> I have other implementations (https://github.com/davidssmith/ra), and all 
> are super short and platform agnostic.
>
> 3. RawArray is surely faster. All it does is read. It doesn't perform any 
> transformations or encoding, so it can't possibly be slower than NRRD.
>

Maybe not compared to NRRD, but it can be slower than lossless image 
compression.

I did read (short.. good):
https://github.com/davidssmith/ra/blob/master/doc/ra-sedona-abstract.pdf

https://en.wikipedia.org/wiki/Free_Lossless_Image_Format

FLIF is not a replacement for all uses (multidimensional, would be 
interesting to know if could to be extended to..), but seem to be the best 
option for non-lyssy image compression:

http://flif.info/index.html
"
53% smaller than lossless JPEG 2000 compression,
74% smaller than lossless JPEG XR compression.

Even if the best image format was picked out of PNG, JPEG 2000, WebP or BPG 
for a given image corpus, depending on the type of images (photograph, line 
art, 8 bit or higher bit depth, etc), then FLIF still beats that by 12% on 
a median corpus 
[..]
FLIF does away with knowing what image format performs the best at any 
given task.
[..]
Other lossless formats also support progressive decoding (e.g. PNG with 
Adam7 interlacing), but FLIF is better at it. Here is a simple 
demonstration video, which shows an image as it is slowly being downloaded:
[..]
No patents, Free

Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is 
completely royalty-free and it is not known to be encumbered by software 
patents. At least as far as we know. FLIF is uses arithmetic coding, just 
like FFV1 (which inspired FLIF), but as far as we know, all patents related 
to arithmetic coding are expired. Other than that, we do not think FLIF 
uses any techniques on which patents are claimed. However, we are not 
lawyers. There are a stunning number of software patents, some of which are 
very broad and vague; it is impossible to read them all, let alone 
guarantee that nobody will ever claim part of FLIF to be covered by some 
patent. All we know is that we did not knowingly use any technique which is 
(still) patented, and we did not patent FLIF ourselves either.

The reference implementation of FLIF is Free Software. It is released 
under the terms of the GNU Lesser General Public License (LGPL), version 3 
or any later version.
[..]
The reference FLIF decoder is also available as a shared library, 
released under the more permissive (non-copyleft) terms of the Apache 2.0 
license. Public domain example code is available to illustrate how to use 
the decoder library.

Moreover, the reference implementation is available free of charge 
(gratis) under these terms.
[..]
FLIF currently has the following features:

Lossless compression
Lossy compression (encoder preprocessing option, format itself is 
lossless so no generation loss)
Greyscale, RGB, RGBA (also palette and color-bucket modes)
Color depth: up to 16 bits per channel (high bit depth)"

-- 
Palli.

There is a C library at (https://github.com/davidssmith/ra) if you think a 
> pure Julia implementation isn't fast enough. 
>
> Cheers,
> Dave
>
> [*] That said, I'm not completely ruling out having transformations 
> available in RawArray between the RAM and disk. For example, when I first 
> wrote it, I had included Blosc compression as an option, signaled by a flag 
> in the header. But in general most transformations are best made in RAM 
> after reading or on disk with already existing, battle-proven tools, such 
> as gzip, uunencode, tar, etc. 
>
>
> On Sunday, September 25, 2016 at 9:59:45 PM UTC-5, Isaiah wrote:
>>
>> Is there a reason to use this file format over NRRD [1]? To borrow a 

[julia-users] Re: Warning since 0.5

[Ralph Smith]

By "module file" I just meant a source code file where all definitions are 
enclosed in modules, so if you "include" it, it replaces the whole module. 
Thus

module M
function f(x)
   x^2
end
end


then references to M.f are more likely to be consistent than a bare 
function f defined at the top level (the Main module).

As you surmised, 

g = x -> x^2


binds the mutable variable with symbol :g  to an anonymous function (i.e. 
one with a hidden name and type).  If you bind :g to a different function, 
references to :g should
always use the new association.  Defining a regular function (like M.f 
above) embeds "f" as a name in the function object itself. The function 
object then points into
method tables. You can't assign the name "f" to a different function 
object, just attach different methods to it.  The troubles seem to arise 
from cached references to
orphaned method table entries, which are not completely dissociated from 
the object named "f". 

On Saturday, October 8, 2016 at 5:09:19 PM UTC-4, digxx wrote:
 | what do u mean by "module files"?

 | So what is the difference between
 | f(x)=x^2
 | and 
 | f=x->x^2

is f(x)=x^2 not an anonymous function?!?!
>

[julia-users] Re: How to print an array with the correct shape in 0.5

[Steven G. Johnson]

On Friday, October 7, 2016 at 9:30:00 AM UTC-4, spaceLem wrote:
>
> In Julia 0.4.6 I could print or @show a 2d array, and it would give me a 
> nicely formatted 2d array
> println(reshape(1:4,2,2))
> [1 3
>  2 4]
>
> However in Julia 0.5 I instead get:
> println(reshape(1:4,2,2))
> [1 3; 2 4]
>
> Is it still possible to print 2d arrays without flattening them? And if 
> so, how?
>

Do display(array) or show(STDOUT, "text/plain", ...array...) if you want 
the multiline format.

[julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Steven G. Johnson]

There seems to be some breakage right now in Anaconda from their switch 
from Qt4 to Qt5.   Updating to PyCall and PyPlot master, and forcing the 
Qt4Agg backend (e.g. with ENV["MPLBACKEND"]="Qt4Agg") should work.

[julia-users] Re: Warning since 0.5

[digxx]

is f(x)=x^2 not an anonymous function?!?!

[julia-users] Re: Warning since 0.5

[digxx]

Maybe one sidenote:
So what is the difference between
f(x)=x^2
and 
f=x->x^2
since the last one does not return that warning?

[julia-users] Re: Warning since 0.5

[digxx]

Thanks for ur example
I'm not that familiar with it but what do u mean by "module files"?
Do you have an example and why are they less dangerous?

[julia-users] Re: BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Femto Trader]

I tried

provides(Sources, 
URI("http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz;), 
libta_lib, unpacked_dir="ta-lib")

Thanks Tony, it helps me... but I'm still facing build error with Linux and 
BinDeps (contrary to a simple bash script with
./configure --prefix=/usr
make
sudo make install


See https://travis-ci.org/femtotrader/TALib.jl/jobs/166105482

/home/travis/.julia/v0.5/TALib/deps/src/ta-lib/src/ta_abstract/tables/table_c.c:38:25:
 
fatal error: ta_abstract.h: No such file or directory


Headers are not found.


Le samedi 8 octobre 2016 22:08:49 UTC+2, Tony Kelman a écrit :
>
> Try using the unpacked_dir keyword argument to the Sources provider to 
> tell it the github tarball has a different folder name that it extracts to 
> than its default assumption.

[julia-users] BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Tony Kelman]

Try using the unpacked_dir keyword argument to the Sources provider to tell it 
the github tarball has a different folder name that it extracts to than its 
default assumption.

Re: [julia-users] Must we reinstall all packages after updating to v0.5?

[Yichao Yu]

On Sat, Oct 8, 2016 at 3:43 PM,   wrote:
> It worked. Thanks for your advice. Another thing, I observed the previous
> version v0.4 folder on the disk. Is there a way to delete it and free up
> some space?

Well, just delete it and free up the space? A newer version of julia
will not delete the data for the older version because you can use
multiple versions simultaneously.

>
> On Saturday, 8 October 2016 20:43:57 UTC+2, Yichao Yu wrote:
>>
>> On Sat, Oct 8, 2016 at 2:41 PM, Yichao Yu  wrote:
>> > On Sat, Oct 8, 2016 at 2:39 PM,   wrote:
>> >> Hi, I'm not sure if anyone else has this problem but apparently, after
>> >> updating to v0.5, I can no longer find the packages that I had
>> >> previously
>> >
>> > This is expected since packages might use different code on different
>> > julia versions and simply copying the code can cause subtle breakage.
>> >
>> >> installed in v0.4. The console says, argumenterror: Module Statsbase
>> >> not
>> >> found in current path. I tried Pkg.status in my pwd and it didn't show
>> >> any
>> >> of the previous packages that I had installed. Am I doing something
>> >> wrong
>> >> here? How do I install all the packages I previously had?
>> >
>> > You can copy the old REQUIRE to the new location and run
>> > `Pkg.update()`. The REQUIRE file, which record the packages you
>> > explicitly installed is located in the `Pkg.dir()` of the
>> > corresponding version.
>>
>> Of course this doesn't handle the packages you have locally or
>> packages that are deprecated/removed/not supported anymore in the new
>> version and that has to be handled in a case-by-case basis and you
>> should be able to find instructions for deprecated packages in their
>> readme.

Re: [julia-users] Must we reinstall all packages after updating to v0.5?

[varun7rs]

It worked. Thanks for your advice. Another thing, I observed the previous 
version v0.4 folder on the disk. Is there a way to delete it and free up 
some space?

On Saturday, 8 October 2016 20:43:57 UTC+2, Yichao Yu wrote:
>
> On Sat, Oct 8, 2016 at 2:41 PM, Yichao Yu  
> wrote: 
> > On Sat, Oct 8, 2016 at 2:39 PM,   
> wrote: 
> >> Hi, I'm not sure if anyone else has this problem but apparently, after 
> >> updating to v0.5, I can no longer find the packages that I had 
> previously 
> > 
> > This is expected since packages might use different code on different 
> > julia versions and simply copying the code can cause subtle breakage. 
> > 
> >> installed in v0.4. The console says, argumenterror: Module Statsbase 
> not 
> >> found in current path. I tried Pkg.status in my pwd and it didn't show 
> any 
> >> of the previous packages that I had installed. Am I doing something 
> wrong 
> >> here? How do I install all the packages I previously had? 
> > 
> > You can copy the old REQUIRE to the new location and run 
> > `Pkg.update()`. The REQUIRE file, which record the packages you 
> > explicitly installed is located in the `Pkg.dir()` of the 
> > corresponding version. 
>
> Of course this doesn't handle the packages you have locally or 
> packages that are deprecated/removed/not supported anymore in the new 
> version and that has to be handled in a case-by-case basis and you 
> should be able to find instructions for deprecated packages in their 
> readme. 
>

[julia-users] Re: New SPEC - open to Julia[applications]?

[Chris Rackauckas]

>From your second link:


>- Submissions for the first step in the search program will be 
>accepted by SPEC beginning 11 November 2008 and ending 30 June 2010 (11:59 
>pm, Pacific Standard Time).
>
>
On Saturday, October 8, 2016 at 12:18:53 PM UTC-7, Páll Haraldsson wrote:
>
>
> https://www.spec.org/cpuv6/
>
> It would be cool (and publicity) if Julia would make it into SPEC version 
> 6. Anyway, might be of interest to people here.
>
> SPEC used C or Fortran last I looked, I see only references to 
> "languages", "C/C++" and "portable":
>
>
> https://www.spec.org/cpuv6/
> "SPEC holds to the principle that better benchmarks can be developed from 
> actual applications. With this in mind, SPEC is once again seeking to 
> encourage those outside of SPEC to assist us in locating applications that 
> could be used in the next CPU-intensive benchmark suite, currently under 
> development within SPEC and currently designated as SPEC CPUv6.[..]
>
> Portable or can be ported to multiple hardware architectures and operating 
> systems with reasonable effort 
>
>
> For C/C++ programs:
> [..]
> for the main routine, take one of these two forms
>
>
> [..]
> the programming(s) language used in the program/application and 
> approximate lines of code, 
>
> [..]
> Step 4: Complete Code Testing and Benchmark Infrastructure ($1000 upon 
> successful completion) 
> [..]
> SPEC always prefers to use code that conforms to the relevant language 
> standards.
>
> [..]
> Step 6: Acceptance into the CPU Suite ($2500 if accepted)
>
> If the program/application is recommended to and is accepted by the Open 
> Systems Group, in its sole discretion, then the program/application is 
> included in the suite and the Submitter will receive $2500 and a license 
> for the suite when it is released."
>

[julia-users] New SPEC - open to Julia[applications]?

[Páll Haraldsson]

https://www.spec.org/cpuv6/

It would be cool (and publicity) if Julia would make it into SPEC version 
6. Anyway, might be of interest to people here.

SPEC used C or Fortran last I looked, I see only references to "languages", 
"C/C++" and "portable":


https://www.spec.org/cpuv6/
"SPEC holds to the principle that better benchmarks can be developed from 
actual applications. With this in mind, SPEC is once again seeking to 
encourage those outside of SPEC to assist us in locating applications that 
could be used in the next CPU-intensive benchmark suite, currently under 
development within SPEC and currently designated as SPEC CPUv6.[..]

Portable or can be ported to multiple hardware architectures and operating 
systems with reasonable effort 


For C/C++ programs:
[..]
for the main routine, take one of these two forms


[..]
the programming(s) language used in the program/application and approximate 
lines of code, 

[..]
Step 4: Complete Code Testing and Benchmark Infrastructure ($1000 upon 
successful completion) 
[..]
SPEC always prefers to use code that conforms to the relevant language 
standards.

[..]
Step 6: Acceptance into the CPU Suite ($2500 if accepted)

If the program/application is recommended to and is accepted by the Open 
Systems Group, in its sole discretion, then the program/application is 
included in the suite and the Submitter will receive $2500 and a license 
for the suite when it is released."

[julia-users] BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Femto Trader]

Hello,


I'm new to BinDeps.
I use it in https://github.com/femtotrader/TALib.jl
to be able to download / build / install TA-Lib http://ta-lib.org/

I'm able to install this library using OS X and Homebrew without problem
see https://travis-ci.org/femtotrader/TALib.jl/jobs/166091755

but with Linux, I'm facing a strange issue.
see https://travis-ci.org/femtotrader/TALib.jl/jobs/166091757

It raises

LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src 
was not created successfully (Tried to run `tar xzf 
/home/travis/.julia/v0.5/TALib/deps/downloads/ta-lib-0.4.0-src.tar.gz 
--directory=/home/travis/.julia/v0.5/TALib/deps/src` )
while loading /home/travis/.julia/v0.5/TALib/deps/build.jl, in expression 
starting on line 31


My deps/build.jl looks like


using BinDeps

@BinDeps.setup

libta_lib = library_dependency("libta_lib", aliases=["libta_lib", 
"libta_lib.so"])

if is_apple()

if Pkg.installed("Homebrew") === nothing
error("Homebrew package not installed, please run 
Pkg.add(\"Homebrew\")")
end
using Homebrew
provides(Homebrew.HB, "ta-lib", libta_lib, os = :Darwin )


elseif is_linux()

provides(Sources,
Dict(

URI("http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz;) => 
libta_lib
)
)
provides(BuildProcess, Autotools(libtarget = "libta_lib", 
configure_options=["--prefix=/usr"]), libta_lib, os = :Unix)

else
error("TALib.jl doesn't support this OS")
end

@BinDeps.install Dict(:libta_lib => :libta_lib)





I don't understand why it's failing.


Before following the "BinDeps way" I was installing this dependency using

wget http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz
tar -zxvf ta-lib-0.4.0-src.tar.gz
cd ta-lib
./configure --prefix=/usr
make
sudo make install


Any help will be very nice.



PS: Issue opened on my side 
https://github.com/femtotrader/TALib.jl/issues/16

[julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Ferran Mazzanti]

Dear all,

sorry for not replying before but I've been very busy lately... Still I 
wanted to report back here. While I found some of teh previous solutions to 
work, I finally found out there was a bad interaction between Anaconda's 
Python and julia. SImply got rid of Anaconda and then reinstalled julia 
0.5.0 and PyPlot and that worked out well again :)

Thanks for your kind help,

Ferran.

On Thursday, August 18, 2016 at 10:47:27 AM UTC+2, Ferran Mazzanti wrote:
>
> Dear all,
>
> looks like lots of messing around with versions had rendered PyPlot 
> unusable in 0.4.6 under OSX (at least).
> Now I need to do some work that requires its use so I need to have it up 
> and working. Could anybody please let me know
> if it is possible to revert to a previous working version, and how this is 
> done? I know it used to work with 0.4.6 as I had it
> installed, but once I did an update and things stopped working since then.
>
> Thanks for your help,
>
> Ferran.
>

Re: [julia-users] Must we reinstall all packages after updating to v0.5?

[Yichao Yu]

On Sat, Oct 8, 2016 at 2:41 PM, Yichao Yu  wrote:
> On Sat, Oct 8, 2016 at 2:39 PM,   wrote:
>> Hi, I'm not sure if anyone else has this problem but apparently, after
>> updating to v0.5, I can no longer find the packages that I had previously
>
> This is expected since packages might use different code on different
> julia versions and simply copying the code can cause subtle breakage.
>
>> installed in v0.4. The console says, argumenterror: Module Statsbase not
>> found in current path. I tried Pkg.status in my pwd and it didn't show any
>> of the previous packages that I had installed. Am I doing something wrong
>> here? How do I install all the packages I previously had?
>
> You can copy the old REQUIRE to the new location and run
> `Pkg.update()`. The REQUIRE file, which record the packages you
> explicitly installed is located in the `Pkg.dir()` of the
> corresponding version.

Of course this doesn't handle the packages you have locally or
packages that are deprecated/removed/not supported anymore in the new
version and that has to be handled in a case-by-case basis and you
should be able to find instructions for deprecated packages in their
readme.

Re: [julia-users] Must we reinstall all packages after updating to v0.5?

[Yichao Yu]

On Sat, Oct 8, 2016 at 2:39 PM,   wrote:
> Hi, I'm not sure if anyone else has this problem but apparently, after
> updating to v0.5, I can no longer find the packages that I had previously

This is expected since packages might use different code on different
julia versions and simply copying the code can cause subtle breakage.

> installed in v0.4. The console says, argumenterror: Module Statsbase not
> found in current path. I tried Pkg.status in my pwd and it didn't show any
> of the previous packages that I had installed. Am I doing something wrong
> here? How do I install all the packages I previously had?

You can copy the old REQUIRE to the new location and run
`Pkg.update()`. The REQUIRE file, which record the packages you
explicitly installed is located in the `Pkg.dir()` of the
corresponding version.

[julia-users] Must we reinstall all packages after updating to v0.5?

[varun7rs]

Hi, I'm not sure if anyone else has this problem but apparently, after 
updating to v0.5, I can no longer find the packages that I had previously 
installed in v0.4. The console says, argumenterror: Module Statsbase not 
found in current path. I tried Pkg.status in my pwd and it didn't show any 
of the previous packages that I had installed. Am I doing something wrong 
here? How do I install all the packages I previously had?

[julia-users] Zero indexed arrays

[Brian Rogoff]

Hi,
I saw in the release notes that Julia added support for different array 
indexing methods. I decided to try my hand at implementing zero indexed 
vectors, and started with the instructions 
here http://docs.julialang.org/en/latest/devdocs/offset-arrays/ I found 
this part of the documentation to be unhelpful compared to other parts of 
the Julia docs (is that just me?), but with a bit of hacking I came up with 
this

immutable ZeroIndexedVector{T} <: AbstractArray{T, 1}
data::Array{T,1}
end

Base.linearindices{T}(A::ZeroIndexedVector{T}) = 0:(length(A.data)-1)
Base.getindex{T}(A::ZeroIndexedVector{T}, i::Int) = A.data[i + 1]
Base.setindex!{T}(A::ZeroIndexedVector{T}, v, i::Int) = (A.data[i + 1] = v)
Base.indices{T}(A::ZeroIndexedVector{T}) =
(0:(length(A.data)-1),)

Base.endof{T}(A::ZeroIndexedVector{T}) = length(A.data) - 1
Base.show{T}(A::ZeroIndexedVector{T}) = show(A.data)
function Base.display{T}(A::ZeroIndexedVector{T})
@printf("%d-element ZeroIndexedVector{%s, 1}:\n",
length(A.data),
string(T))
for elt in A.data
   @printf("%s\n", string(elt))
end
end

Apart from some obvious failings (eg, not copying he backing array) it 
seems to work. What's the best way to write this code? How does one extend 
this to multidimensional arrays? IMO, the explanation of how to do these 
two things would have served as good examples on the doc page.

-- Brian

[julia-users] Re: Warning since 0.5

[Ralph Smith]

The problem is that some Julia processing stores references to definitions 
in hidden locations which are not updated consistently, so you get 
inconsistency like this:

julia> f(x)=x^2
f (generic function with 1 method)


julia> map(f,[1,2,3])
3-element Array{Int64,1}:
 1
 4
 9


julia> f(x)=x^2+1
WARNING: Method definition f(Any) in module Main at REPL[7]:1 overwritten 
at REPL[9]:1.
f (generic function with 1 method)


julia> [f(x) for x in [1,2,3]]
3-element Array{Int64,1}:
 1
 4
 9


julia> for x in [1,2,3]; println(f(x)); end
2
5
10


julia> map(f,[1,2,3])
3-element Array{Int64,1}:
 1
 4
 9


(Thanks to fcard for pointing this out.  See this issue 
 for more discussion.) 
 Fixing this and related problems is hard, but there is hope for v0.6.

Anyway, my point was that "function files" are more dangerous than "module 
files", and that's why they generate more warnings.

In the REPL one can also drop *all* old definitions & bindings by using 
workspace(), but I find that more painful than just using modules and 
restarting Julia when
necessary.

If you're convinced that all this doesn't apply to your case, you can 
suppress messages: 
https://github.com/cstjean/ClobberingReload.jl#silencing-warnings 

On Saturday, October 8, 2016 at 9:35:10 AM UTC-4, digxx wrote:
>
> Hey,
> Thx for ur answer. So The first time I call my program which includes a 
> file with function definitions there is no problem. I do this because with 
> 0.4 parallel loops didnt work with functions which are defined in the same 
> file even though an @everywhere is prefixed.
> I still dont understand why this should happen at all. Isnt it totally 
> natural that a function file where things like
> g(x)=x.^2
> are defined and not much more complex it might happen that I want to 
> change it to 
> g(x)=x.^2+1
> without restarting Julia in order to not get the error.
> This also happens in the REPL when I overwrite a simple function. So it is 
> probably not correlated to the @everywhere.
> How can I avoid the warning or is it possible to "free" all allocated 
> function definitions before I redefine them?
>

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

Personally I think it's better to have translated web even if it doesn't 
look professional. I understood that it would be interesting that more 
people participated to translation ?


Milan if you find mistakes of mine (I surely do !) better correcting 
them I wouldn't be angry... But telling me that it would be better not 
to translate them is a bit too much. Maybe in your professional position 
you say what you want but with people who are doing there best to 
improved translation I think it is displaced !


Regards

Henri


Le 08/10/2016 à 16:59, Ismael Venegas Castelló a écrit :
*I got a mail today and I published a response, but I'm not sure why 
it doesn't show up here, so I'll paste it verbatim:*


Hi Milan!

Thank you for stating your concern,

>but I'm worried that we completely destroy the professional aspect of 
the website


I agree with you but, I think that we need a banner in the julia 
website stating that the translations are *not *done by professionals 
but by volunteers and also inviting them to join and improve the 
translations in their own languages.


I'll activate another option that is more strict, in which only 
reviewed translations will be able to be shown in the website (as 
opposed to only translated but un reviewed ones), but anyway, since 
this is a collaborative effort we need to work as a team. For example 
Transifex doesn't prohibit someone of reviewing his/her own 
translations, even when I've tried to make clear that this is not a 
good practice, there is no way to enforce it.


However, please join the French team and un review, comment and 
correct the strings in order to improve the quality, there is no other 
way (other than paying for professional translations).


The team is small but growing, and the project has just started, if we 
state publicly that the translations are crowd sourced by the 
community and an ongoing progress, then I'm sure no one will expect 
them to be of professional grade yet, and no reputation will be affected.


Expecting professional translation from the get go, is unrealistic 
without investing money into the project. And waiting, g for all the 
crowd sourced translations to become of professional grade, would kill 
the motivation of the contributors, as this has already happened, the 
project was stagnant for 1+ year (with the infrastructure already 
being ready and tested). If the project had continued, maybe today we 
would already have much more complete translations of near 
professional grade.


So I think the best way to approach this is not to be conservative, 
but to be open and transparent, so we can get more help and others 
can't be disappointed for the current status, and the reputation of 
all, not only of the Julia project, but also of the contributors that 
are willing to translate for us, remains intact and even become more 
positive.


Think synergy!

Regards,
Ismael Venegas Castelló

2016-10-08 8:46 GMT-05:00 Milan Bouchet-Valat <>:

Hi!

I really appreciate the progress of translations of the website. But
I've just realized the French version of the site contains lots of
mistakes, including incorrect translations, typos, and case issues. In
some cases one cannot understand what the sentence means.

Can I recommend extra care when translating Julia? Typically,
translations shouldn't be done by a single person, and should only be
published after having been reviewed by another contributor. The rule
should be that it's better to have an English sentence than a broken
approximately translated one. Translations can do more harm than good
without a lot of care.

Sorry for sounding too negative, but I'm worried that we completely
destroy the professional aspect of the website by having random people
do weird things in each language no core developer understands. It's
very hard to keep control over that. Do you know whether the French
team is organized yet?

Regards


Le vendredi 30 septembre 2016 à 08:30 +0200,  a
écrit :
>  Hi Ismael
> That's it. I8 I have a little github with forks to put my
examples. I
> read gitter and saw that most of translation was on stating now.
> I found the search field on translation page.
> Thanks
> Best Henri
>
> Le 29/09/2016 à 23:48, Ismael Venegas Castelló a écrit :
> > Hello Henri!
> >
> > Just a question, you are aishenri in GitHub right? Because I
> > answered this same question at julia-i18n chat room at Gitter,
just
> > want to make sure, I don't want to leave any question unanswered.
> >
> >
https://gitter.im/JuliaLangEs/julia-i18n?at=57ed5568be5dec755007a21

> > c
> >
> > Cheers
> > Ismael Venegas Castelló
> >
> >
> > > Hi Ismael,
> > > I would like to translate "home" first,  but I noticed it's
> > > difficult to find all text 

[julia-users] Re: translating julia

[Ismael Venegas Castelló]

*I got a mail today and I published a response, but I'm not sure why it 
doesn't show up here, so I'll paste it verbatim:*

Hi Milan! 

Thank you for stating your concern, 

> but I'm worried that we completely destroy the professional aspect of the 
website

I agree with you but, I think that we need a banner in the julia website 
stating that the translations are *not *done by professionals but by 
volunteers and also inviting them to join and improve the translations in 
their own languages. 

I'll activate another option that is more strict, in which only reviewed 
translations will be able to be shown in the website (as opposed to only 
translated but un reviewed ones), but anyway, since this is a collaborative 
effort we need to work as a team. For example Transifex doesn't prohibit 
someone of reviewing his/her own translations, even when I've tried to make 
clear that this is not a good practice, there is no way to enforce it.

However, please join the French team and un review, comment and correct the 
strings in order to improve the quality, there is no other way (other than 
paying for professional translations).

The team is small but growing, and the project has just started, if we 
state publicly that the translations are crowd sourced by the community and 
an ongoing progress, then I'm sure no one will expect them to be of 
professional grade yet, and no reputation will be affected.

Expecting professional translation from the get go, is unrealistic without 
investing money into the project. And waiting, g for all the crowd sourced 
translations to become of professional grade, would kill the motivation of 
the contributors, as this has already happened, the project was stagnant 
for 1+ year (with the infrastructure already being ready and tested). If 
the project had continued, maybe today we would already have much more 
complete translations of near professional grade.

So I think the best way to approach this is not to be conservative, but to 
be open and transparent, so we can get more help and others can't be 
disappointed for the current status, and the reputation of all, not only of 
the Julia project, but also of the contributors that are willing to 
translate for us, remains intact and even become more positive.

Think synergy!

Regards,
Ismael Venegas Castelló

2016-10-08 8:46 GMT-05:00 Milan Bouchet-Valat <>:

> Hi!
>
> I really appreciate the progress of translations of the website. But
> I've just realized the French version of the site contains lots of
> mistakes, including incorrect translations, typos, and case issues. In
> some cases one cannot understand what the sentence means.
>
> Can I recommend extra care when translating Julia? Typically,
> translations shouldn't be done by a single person, and should only be
> published after having been reviewed by another contributor. The rule
> should be that it's better to have an English sentence than a broken
> approximately translated one. Translations can do more harm than good
> without a lot of care.
>
> Sorry for sounding too negative, but I'm worried that we completely
> destroy the professional aspect of the website by having random people
> do weird things in each language no core developer understands. It's
> very hard to keep control over that. Do you know whether the French
> team is organized yet?
>
> Regards
>
>
> Le vendredi 30 septembre 2016 à 08:30 +0200,  a
> écrit :
> >  Hi Ismael
> > That's it. I8 I have a little github with forks to put my examples. I
> > read gitter and saw that most of translation was on stating now.
> > I found the search field on translation page.
> > Thanks
> > Best Henri
> >
> > Le 29/09/2016 à 23:48, Ismael Venegas Castelló a écrit :
> > > Hello Henri!
> > >
> > > Just a question, you are aishenri in GitHub right? Because I
> > > answered this same question at julia-i18n chat room at Gitter, just
> > > want to make sure, I don't want to leave any question unanswered.
> > >
> > > https://gitter.im/JuliaLangEs/julia-i18n?at=57ed5568be5dec755007a21
> > > c
> > >
> > > Cheers
> > > Ismael Venegas Castelló
> > >
> > >
> > > > Hi Ismael,
> > > > I would like to translate "home" first,  but I noticed it's
> > > > difficult to find all text about it ?
> > > > Is there a way to research a precise text ?
> > > > I already translated a good part of it but I need to see it so
> > > > that I can be sûre of that.
> > > >
> > > > Best
> > > > Henri
> > > > Le 28/09/2016 à 11:54, henri@gmail.com a écrit :
> > > > > I am wondering if one must write the html mark when translating
> > > > > ?
> > > > >
> > > > > Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :
> > > > > > Hello Henri!
> > > > > >
> > > > > > Currently French is about 0% translated, we are adding to
> > > > > > production the languages that at minimum have the home page
> > > > > > translated 90 %, but you can see the current progress of all
> > > > > > the languages in the staging site here:
> > > > > >
> > > > > > 

Re: [julia-users] Re: Julia on Research Computing Podcast RCE

[Stefan Karpinski]

. Looking forward to hearing the episode! Thanks, Brock.

On Wed, Oct 5, 2016 at 6:45 PM, Brock Palen 
wrote:

> Thank you everyone for the support of the podcast.  If you have other
> topics please let me know off list.
>
> The Julia episode is up at: http://www.rce-cast.com/
> Podcast/rce-107-julia.html
>
> Thanks again to:
> Viral Shah
> Stefan Karpinski
> Jeff Bezanson
> Alan Edelman
>
> Brock Palen
>
>
> On Saturday, September 10, 2016 at 11:33:41 PM UTC-4, Brock Palen wrote:
>>
>> I am one half of the HPC/Research Computing podcast
>> http://www.rce-cast.com/
>>
>> We would like to feature Julia on the show.  This takes a developer or
>> two and is a friendly interview, takes about an hour over the phone or
>> skype and aims to educate our community.
>>
>> Feel free to contact me off list.
>>
>> Thank you !
>>
>> Brock Palen
>>
>>

Re: [julia-users] Re: Julia and the Tower of Babel

[Stefan Karpinski]

Good generic API design is one of the hardest problems around. For many
problem areas, we just haven't found the right design yet. JuMP is one of
the prime examples of brilliant work in this area. Mathematica is the best
example of consistent APIs in a language and it's ecosystem because Stephen
Wolfram literally reviews and approves every single function that's added.
We can't do that since this is an open source community and we don't have
dictators, and honestly no one has the time or breadth of expertise to do
this for all the amazing areas people are using Julia in. There are some
things that are helpful, however.

*GitHub orgs.* Having related packages under a single org is weirdly
effective – way more than it seems like it should be. I think this is about
awareness and communication. Not a panacea, but more helpful than you would
imagine.

*Communication.* Long hard conversations like this one
. Get people talking about
what the common API should look like. Once people agree on a good one,
implementation is often easier than one might think.

*Generic functions.* Julia's multiple dispatch is good at this, especially
because it allows you to disentangle nouns and verbs, and different people
can work on different parts of the vocabulary. Have a good set of nouns
like Distributions ? Anyone
can add their own verbs. Have some good consistent verbs? Making them apply
to your own nouns is no problem either. See the esoteric-seeming expression
problem [1 ,2

,3 ] –
which doesn't even occur to Julia programmers as being a problem because
the solution is so natural.

*Persistence.* The more speculative and active a research area is, the less
likely we are to have a consensus on what the generic interfaces and APIs
should look like. Optimization APIs were all over the place until things
like JuMP and Convex came along. Now you can swap out different solvers
easily and keep the expression of your problem the same. Changing deep
learning backends should be just as easy, but it's certainly not – because
people are still trying to figure out how what the interface between how
you program and how you implement these systems is.

*Summary:* keep trying, communicate, create organizations, and use multiple
dispatch effectively.


On Sat, Oct 8, 2016 at 10:12 AM, Tsur Herman  wrote:

> I noticed this also .. and this is why I chose to "rip" some packages for
> some of its functionality.
>
> From what I observed the problem is the "coolness" of the language and the
> highly creative level of the package writers. Just as the first post here
> states the seemingly two advantages , cool language and super-creative
> package writers .. can some time have a "babel tower" effect.
>
> I encountered this with respect to image processing geometry primitive
> manipulation etc .. the problem is: too many types!!
>
> if something can be represented as an array with some convention for
> example MxN array where M is the Descriptor size and N is the number of
> Descriptors  .. then it is better to use and support that
> than to declare more specialized types.
>
> At least for fast paced research and idea validation it is better.
> Probably for implementation and performance specialized types optimized for
> speed will be required..
>
>
>

Re: [julia-users] Re: Julia and the Tower of Babel

[Tom Breloff]

I think sometimes people go overboard with types, but types allow us to
take full advantage of multiple dispatch and abstraction on another level.
For example, a diagonal matrix and a full/dense matrix are both the same
thing, but if you can dispatch on them differently you can massively
improve the effectiveness/performance of the underlying code without much
effort.  A recent thread here was asking about how to do this effectively
in Python, and... well, everyone just kinda laughed at the idea.  Types
allow us flexibility that we can't have otherwise.

On Sat, Oct 8, 2016 at 10:12 AM, Tsur Herman  wrote:

> I noticed this also .. and this is why I chose to "rip" some packages for
> some of its functionality.
>
> From what I observed the problem is the "coolness" of the language and the
> highly creative level of the package writers. Just as the first post here
> states the seemingly two advantages , cool language and super-creative
> package writers .. can some time have a "babel tower" effect.
>
> I encountered this with respect to image processing geometry primitive
> manipulation etc .. the problem is: too many types!!
>
> if something can be represented as an array with some convention for
> example MxN array where M is the Descriptor size and N is the number of
> Descriptors  .. then it is better to use and support that
> than to declare more specialized types.
>
> At least for fast paced research and idea validation it is better.
> Probably for implementation and performance specialized types optimized for
> speed will be required..
>
>
>

Re: [julia-users] How does one read and write a sizeable amount of data (megabytes) from a process?

[Stefan Karpinski]

https://github.com/JuliaLang/julia/issues/18840

On Fri, Oct 7, 2016 at 6:26 PM, Eric Davies  wrote:

> Thanks, I will try both of those. I had tried making smaller pieces before
> but I'll try with `Base.process_events(false)`.
>

[julia-users] Re: Julia and the Tower of Babel

[Tsur Herman]

I noticed this also .. and this is why I chose to "rip" some packages for 
some of its functionality.

>From what I observed the problem is the "coolness" of the language and the 
highly creative level of the package writers. Just as the first post here
states the seemingly two advantages , cool language and super-creative 
package writers .. can some time have a "babel tower" effect.

I encountered this with respect to image processing geometry primitive 
manipulation etc .. the problem is: too many types!!

if something can be represented as an array with some convention for 
example MxN array where M is the Descriptor size and N is the number of 
Descriptors  .. then it is better to use and support that 
than to declare more specialized types.

At least for fast paced research and idea validation it is better. Probably 
for implementation and performance specialized types optimized for speed 
will be required..
 
 

Re: [julia-users] @testset in v0.4 testing?

[Yichao Yu]

On Sat, Oct 8, 2016 at 7:19 AM, Andreas Lobinger  wrote:
> Hello colleagues,
>
> it's quite nice to structure testing with @testset in v0.5 (and higher), but
> it doesn't exist in 0.4. And it's not expected to be backported.
> Could Compat be a place for this? Or just build two blocks (>0.4 and <=
> v0.4) in runtests.jl ?

BaseTestNext

>
>

[julia-users] Re: Warning since 0.5

[digxx]

Hey,
Thx for ur answer. So The first time I call my program which includes a 
file with function definitions there is no problem. I do this because with 
0.4 parallel loops didnt work with functions which are defined in the same 
file even though an @everywhere is prefixed.
I still dont understand why this should happen at all. Isnt it totally 
natural that a function file where things like
g(x)=x.^2
are defined and not much more complex it might happen that I want to change 
it to 
g(x)=x.^2+1
without restarting Julia in order to not get the error.
This also happens in the REPL when I overwrite a simple function. So it is 
probably not correlated to the @everywhere.
How can I avoid the warning or is it possible to "free" all allocated 
function definitions before I redefine them?

[julia-users] Linux distributions with Julia >= 0.5.0

[Ismael Venegas Castelló]

Just do: 

sudo pacman -S julia 

And you are done! :D

[julia-users] Linux distributions with Julia >= 0.5.0

[Ismael Venegas Castelló]

I think you are looking for Arch Linux!

https://www.archlinux.org/packages/community/x86_64/julia

If you need a GUI and easy setup, there are se eral distros that come with a 
desktop and are based on Arch:

https://wiki.archlinux.org/index.php/Arch_based_distributions#Desktop

[julia-users] Trick to use plotlyjs in Atom

[Giuseppe Ragusa]

i think in the last versions of Atom the plot will show in the plot pane 
without the need of tricks.

[julia-users] Re: Julia and the Tower of Babel

[Giuseppe Ragusa]

it seems a good idea JuliaPraxis. I have been struggling with trying to get 
consistent naming and having a guide to follow may at least cut short the 
struggling time.

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

I have created a new Organization on github: *JuliaPraxis.*
Everyone who has added to this thread will get an invitation to join, and 
so contribute.
I will set up the site and let you know how do include your wor(l)d views.

Anyone else is welcome to post to this thread, and I will send an 
invitation.



On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>
> Conventions would have to be arrived at before this is possible.
>
> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>
>> In my opinion the solutions to this are very clear, or would be:
>>
>> 1. make a mandatory linter for all julia code
>> 2. julia IDEs should offer good intellisense
>>
>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>
>>> Something that I have been noticing, as I convert more of my research 
>>> code over to Julia, is how the super easy to use package manager (which I 
>>> love), coupled with the talent base of the Julia community seems to have a 
>>> detrimental effect on the API consistency of the many “micro” packages that 
>>> cover what I would consider the de-facto standard library.
>>>
>>> What I mean is that whereas a commercial package like Matlab/Mathematica 
>>> etc., being written under one large umbrella, will largely (clearly not 
>>> always) choose consistent names for similar API keyword arguments, and have 
>>> similar calling conventions for master function like tools (`optimize` 
>>> versus `lbfgs`, etc), which I am starting to realize is one of the great 
>>> selling points of these packages as an end user. I can usually guess what a 
>>> keyword will be in Mathematica, whereas even after a year of using Julia 
>>> almost exclusively I find I have to look at the documentation (or the 
>>> source code depending on the documentation ...) to figure out the keyword 
>>> names in many common packages.
>>>
>>> Similarly, in my experience with open source tools, due to the 
>>> complexity of the package management, we get large “batteries included” 
>>> distributions that cover a lot of the standard stuff for doing science, 
>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent of 
>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>> NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
>>> these packages are stupid awesome, but they can have dramatically different 
>>> naming conventions and calling behavior, for essential equivalent behavior. 
>>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>>> easy to have a piece of scientific code that will need to use all three 
>>> conventions across different calls to seemingly similar libraries. 
>>>
>>> Having brought this up I find that the community is largely sympathetic 
>>> and, in general, would support a common convention, the issue I have slowly 
>>> realized is that it is rarely that straightforward. In the above example 
>>> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of what 
>>> can be tidied up, but the latter underscored name is consistent with 
>>> similar naming conventions from Optim.jl for other tolerances, so that 
>>> community is reluctant to change the convention. Similarly, I think there 
>>> would be little interest in changing abstol/reltol to the underscored 
>>> version in packages like Base, ODE.jl etc as this feels consistent with 
>>> each of these code bases. Hence I have started to think that the problem is 
>>> the micro-packaging. It is much easier to look for consistency within a 
>>> package then across similar packages, and since Julia seems to distribute 
>>> so many of the essential tools in very narrow boundaries of functionality I 
>>> am not sure that this kind of naming convention will ever be able to reach 
>>> something like a Scipy, or the even higher standard of commercial packages 
>>> like Matlab/Mathematica. (I am sure there are many more examples like using 
>>> maxiter, versus iterations for describing stopping criteria in iterative 
>>> solvers ...)
>>>
>>> Even further I have noticed that even when packages try to find 
>>> consistency across packages, for example Optim.jl <-> Roots.jl <-> 
>>> NLsolve.jl, when one package changes how they do things (Optim.jl moving to 
>>> delegation on types for method choice) then again the consistency fractures 
>>> quickly, where we now have a common divide of using either Typed dispatch 
>>> keywords versus :method symbol names across the previous packages (not to 
>>> mention the whole inplace versus not-inplace for function arguments …)
>>>
>>> Do people, with more experience in scientific packages ecosystems, feel 
>>> this is solvable? Or do micro distributions just lead to many, many varying 
>>> degrees of API conventions that need to be learned by end users? Is this 
>>> common in communities that use 

[julia-users] Re: Linux distributions with Julia >= 0.5.0

[Femto Trader]

Thanks all for your kind answers

Le samedi 8 octobre 2016 12:23:00 UTC+2, Femto Trader a écrit :
>
> Hello,
>
> my main development environment is under Mac OS X
> but I'm looking for a Linux distribution (that I will run under VirtualBox)
> that have Julia 0.5.0 support (out of the box)
>
> Even Debian Sid is 0.4.7 (October 8th, 2016)
> https://packages.debian.org/fr/sid/julia
>
> So what Linux distribution should I use to simply test my packages with 
> Julia >=0.5.0 ?
>
> Kind regards
>

[julia-users] @testset in v0.4 testing?

[Andreas Lobinger]

Hello colleagues,

it's quite nice to structure testing with @testset in v0.5 (and higher), 
but it doesn't exist in 0.4. And it's not expected to be backported. 
Could Compat be a place for this? Or just build two blocks (>0.4 and <= 
v0.4) in runtests.jl ?

[julia-users] Re: Linux distributions with Julia >= 0.5.0

[Páll Haraldsson]

On Saturday, October 8, 2016 at 10:23:00 AM UTC, Femto Trader wrote:
>
> Hello,
>
> my main development environment is under Mac OS X
> but I'm looking for a Linux distribution (that I will run under VirtualBox)
> that have Julia 0.5.0 support (out of the box)
>
> Even Debian Sid is 0.4.7 (October 8th, 2016)
> https://packages.debian.org/fr/sid/julia
>
> So what Linux distribution should I use to simply test my packages with 
> Julia >=0.5.0 ?
>

[I use Ubuntu 16.04, the latest officially supported one, and an LTS one 
(16.10 should be around the corner, but not LTS).]


I believe the Julia binary executables at the download page are recommended 
and the only one they want officially supported.


That said, there are Ubuntu PPAs:

https://launchpad.net/~staticfloat/+archive/ubuntu/juliareleases

[I used this, it's really simple to install]

https://launchpad.net/ubuntu/+ppas?name_filter=Julia


It was great to see Ubuntu binaries maintained, and I see that julia 0.5 
was actually supported with a PPA (I had previously used a PPA with 0.4.x), 
so I installed that.

I *think* that there is really no downside to use the PPA vs. the official 
binaries. They might get updated, let's say the maintainer doesn't (not 
like they are getting paied) then you no worse of than with the official 
download that you would always have to manually download a new minor or 
major version.


I actually have an update waiting..:

Changes for julia versions:
Installed version: 0.5.0-xenial1
Available version: 0.5.0-xenial5

Not sure what it entails.

The download page will have 0.5.1 before the PPA. In my case I'm not 
worried.. and I guess the PPA will follow soon.

Re: [julia-users] Linux distributions with Julia >= 0.5.0

[Milan Bouchet-Valat]

Le samedi 08 octobre 2016 à 03:23 -0700, Femto Trader a écrit :
> Hello,
> 
> my main development environment is under Mac OS X
> but I'm looking for a Linux distribution (that I will run under
> VirtualBox)
> that have Julia 0.5.0 support (out of the box)
> 
> Even Debian Sid is 0.4.7 (October 8th, 2016)
> https://packages.debian.org/fr/sid/julia
> 
> So what Linux distribution should I use to simply test my packages
> with Julia >=0.5.0 ?
Fedora 25 (Beta to be released soon) includes Julia 0.5.0.

But you can also use the Copr repository to install that version on
Fedora 23 and 24, as well as on RHEL/Centos 7. And of course generic
Linux binaries are quite easy to install too.


Regards

[julia-users] Re: Julia and the Tower of Babel

[Chris Rackauckas]

Conventions would have to be arrived at before this is possible.

On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>
> In my opinion the solutions to this are very clear, or would be:
>
> 1. make a mandatory linter for all julia code
> 2. julia IDEs should offer good intellisense
>
> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>
>> Something that I have been noticing, as I convert more of my research 
>> code over to Julia, is how the super easy to use package manager (which I 
>> love), coupled with the talent base of the Julia community seems to have a 
>> detrimental effect on the API consistency of the many “micro” packages that 
>> cover what I would consider the de-facto standard library.
>>
>> What I mean is that whereas a commercial package like Matlab/Mathematica 
>> etc., being written under one large umbrella, will largely (clearly not 
>> always) choose consistent names for similar API keyword arguments, and have 
>> similar calling conventions for master function like tools (`optimize` 
>> versus `lbfgs`, etc), which I am starting to realize is one of the great 
>> selling points of these packages as an end user. I can usually guess what a 
>> keyword will be in Mathematica, whereas even after a year of using Julia 
>> almost exclusively I find I have to look at the documentation (or the 
>> source code depending on the documentation ...) to figure out the keyword 
>> names in many common packages.
>>
>> Similarly, in my experience with open source tools, due to the complexity 
>> of the package management, we get large “batteries included” distributions 
>> that cover a lot of the standard stuff for doing science, like python’s 
>> numpy + scipy combination. Whereas in Julia the equivalent of scipy is 
>> split over many, separately developed packages (Base, Optim.jl, NLopt.jl, 
>> Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of these 
>> packages are stupid awesome, but they can have dramatically different 
>> naming conventions and calling behavior, for essential equivalent behavior. 
>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>> easy to have a piece of scientific code that will need to use all three 
>> conventions across different calls to seemingly similar libraries. 
>>
>> Having brought this up I find that the community is largely sympathetic 
>> and, in general, would support a common convention, the issue I have slowly 
>> realized is that it is rarely that straightforward. In the above example 
>> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of what 
>> can be tidied up, but the latter underscored name is consistent with 
>> similar naming conventions from Optim.jl for other tolerances, so that 
>> community is reluctant to change the convention. Similarly, I think there 
>> would be little interest in changing abstol/reltol to the underscored 
>> version in packages like Base, ODE.jl etc as this feels consistent with 
>> each of these code bases. Hence I have started to think that the problem is 
>> the micro-packaging. It is much easier to look for consistency within a 
>> package then across similar packages, and since Julia seems to distribute 
>> so many of the essential tools in very narrow boundaries of functionality I 
>> am not sure that this kind of naming convention will ever be able to reach 
>> something like a Scipy, or the even higher standard of commercial packages 
>> like Matlab/Mathematica. (I am sure there are many more examples like using 
>> maxiter, versus iterations for describing stopping criteria in iterative 
>> solvers ...)
>>
>> Even further I have noticed that even when packages try to find 
>> consistency across packages, for example Optim.jl <-> Roots.jl <-> 
>> NLsolve.jl, when one package changes how they do things (Optim.jl moving to 
>> delegation on types for method choice) then again the consistency fractures 
>> quickly, where we now have a common divide of using either Typed dispatch 
>> keywords versus :method symbol names across the previous packages (not to 
>> mention the whole inplace versus not-inplace for function arguments …)
>>
>> Do people, with more experience in scientific packages ecosystems, feel 
>> this is solvable? Or do micro distributions just lead to many, many varying 
>> degrees of API conventions that need to be learned by end users? Is this 
>> common in communities that use C++ etc? I ask as I wonder how much this 
>> kind of thing can be worried about when making small packages is so easy.
>>
>

[julia-users] Re: Linux distributions with Julia >= 0.5.0

[Andreas Lobinger]

Hello colleague,

On Saturday, October 8, 2016 at 12:23:00 PM UTC+2, Femto Trader wrote:
>
> my main development environment is under Mac OS X
> but I'm looking for a Linux distribution (that I will run under VirtualBox)
> that have Julia 0.5.0 support (out of the box)
>
> Even Debian Sid is 0.4.7 (October 8th, 2016)
> https://packages.debian.org/fr/sid/julia
>
> So what Linux distribution should I use to simply test my packages with 
> Julia >=0.5.0 ?
>

Have you thought about using the generic linux binaries? I used a 0.5 on 
centos 7.2 and ubuntu 15.04 this week for some testing and it just worked.
 

[julia-users] Re: Julia and the Tower of Babel

[Traktor Toni]

In my opinion the solutions to this are very clear, or would be:

1. make a mandatory linter for all julia code
2. julia IDEs should offer good intellisense

Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>
> Something that I have been noticing, as I convert more of my research code 
> over to Julia, is how the super easy to use package manager (which I love), 
> coupled with the talent base of the Julia community seems to have a 
> detrimental effect on the API consistency of the many “micro” packages that 
> cover what I would consider the de-facto standard library.
>
> What I mean is that whereas a commercial package like Matlab/Mathematica 
> etc., being written under one large umbrella, will largely (clearly not 
> always) choose consistent names for similar API keyword arguments, and have 
> similar calling conventions for master function like tools (`optimize` 
> versus `lbfgs`, etc), which I am starting to realize is one of the great 
> selling points of these packages as an end user. I can usually guess what a 
> keyword will be in Mathematica, whereas even after a year of using Julia 
> almost exclusively I find I have to look at the documentation (or the 
> source code depending on the documentation ...) to figure out the keyword 
> names in many common packages.
>
> Similarly, in my experience with open source tools, due to the complexity 
> of the package management, we get large “batteries included” distributions 
> that cover a lot of the standard stuff for doing science, like python’s 
> numpy + scipy combination. Whereas in Julia the equivalent of scipy is 
> split over many, separately developed packages (Base, Optim.jl, NLopt.jl, 
> Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of these 
> packages are stupid awesome, but they can have dramatically different 
> naming conventions and calling behavior, for essential equivalent behavior. 
> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
> easy to have a piece of scientific code that will need to use all three 
> conventions across different calls to seemingly similar libraries. 
>
> Having brought this up I find that the community is largely sympathetic 
> and, in general, would support a common convention, the issue I have slowly 
> realized is that it is rarely that straightforward. In the above example 
> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of what 
> can be tidied up, but the latter underscored name is consistent with 
> similar naming conventions from Optim.jl for other tolerances, so that 
> community is reluctant to change the convention. Similarly, I think there 
> would be little interest in changing abstol/reltol to the underscored 
> version in packages like Base, ODE.jl etc as this feels consistent with 
> each of these code bases. Hence I have started to think that the problem is 
> the micro-packaging. It is much easier to look for consistency within a 
> package then across similar packages, and since Julia seems to distribute 
> so many of the essential tools in very narrow boundaries of functionality I 
> am not sure that this kind of naming convention will ever be able to reach 
> something like a Scipy, or the even higher standard of commercial packages 
> like Matlab/Mathematica. (I am sure there are many more examples like using 
> maxiter, versus iterations for describing stopping criteria in iterative 
> solvers ...)
>
> Even further I have noticed that even when packages try to find 
> consistency across packages, for example Optim.jl <-> Roots.jl <-> 
> NLsolve.jl, when one package changes how they do things (Optim.jl moving to 
> delegation on types for method choice) then again the consistency fractures 
> quickly, where we now have a common divide of using either Typed dispatch 
> keywords versus :method symbol names across the previous packages (not to 
> mention the whole inplace versus not-inplace for function arguments …)
>
> Do people, with more experience in scientific packages ecosystems, feel 
> this is solvable? Or do micro distributions just lead to many, many varying 
> degrees of API conventions that need to be learned by end users? Is this 
> common in communities that use C++ etc? I ask as I wonder how much this 
> kind of thing can be worried about when making small packages is so easy.
>

[julia-users] Linux distributions with Julia >= 0.5.0

[Femto Trader]

Hello,

my main development environment is under Mac OS X
but I'm looking for a Linux distribution (that I will run under VirtualBox)
that have Julia 0.5.0 support (out of the box)

Even Debian Sid is 0.4.7 (October 8th, 2016)
https://packages.debian.org/fr/sid/julia

So what Linux distribution should I use to simply test my packages with 
Julia >=0.5.0 ?

Kind regards

[julia-users] Re: Julia and the Tower of Babel

[Chris Rackauckas]

Create a repo where we can all bikeshed different names, agree upon some, 
and then standardize. I honestly don't care which conventions are chosen 
and will just find/replace with whatever people want, but there has to be a 
"whatever people want" to do that.

On Saturday, October 8, 2016 at 1:47:07 AM UTC-7, jonatha...@alumni.epfl.ch 
wrote:
>
> Maybe an "easy" first step would be to have a page (a github repo) 
> containing domain specific naming conventions (atol/abstol) that package
> developers can look up. Even though existing packages might not adopt 
> them, at least newly created ones would have a chance
> to be more consistent. You could even do a small tool that parse your 
> files and warn you about improper naming.
>

[julia-users] Getting variable names of function though the AST?

[Jon Norberg]

I should have added that growthV was a function

Function growthV(s,f)
Return s+f+q
End

An i am looking to get a list containing s, f and q

Re: [julia-users] Re: Julia and the Tower of Babel

[Milan Bouchet-Valat]

Le samedi 08 octobre 2016 à 01:47 -0700, jonathan.bie...@alumni.epfl.ch
a écrit :
> Maybe an "easy" first step would be to have a page (a github repo)
> containing domain specific naming conventions (atol/abstol) that
> package
> developers can look up. Even though existing packages might not adopt
> them, at least newly created ones would have a chance
> to be more consistent. You could even do a small tool that parse your
> files and warn you about improper naming.
Creating a web page like this sounds like a good idea.

As regards automatic checking, note that there's already Lint.jl, to
which a list of "nonstandard" names could be added, together with
recommendations.


Regards

[julia-users] Re: Julia and the Tower of Babel

[jonathan . bieler]

Maybe an "easy" first step would be to have a page (a github repo) 
containing domain specific naming conventions (atol/abstol) that package
developers can look up. Even though existing packages might not adopt them, 
at least newly created ones would have a chance
to be more consistent. You could even do a small tool that parse your files 
and warn you about improper naming.

[julia-users] Re: multiple dispatch for operators

[Sisyphuss]

The multiplication maybe is not the best example. Actually, I wanted to say 
"addition".

I wanted that my operator `+` works for:
1) np.ndarray + np.ndarray
2) np.ndarray + LRmatrix
3) LRmatrix + np.ndarray
4) LRmatrix + LRmatrix

1) is a part of Numpy. 3) and 4) can be implemented by `LRmatrix.__add__`. 
However, 3) does not work because `np.ndarray.__add__` has higher priority 
than `LRmatrix.__radd__`.

In this case, it will be awkward to use an `add` function to wrap them.
 

On Saturday, October 8, 2016 at 8:35:19 AM UTC+2, Sisyphuss wrote:
>
> You mean:
> def mydot(A,B):
> if isinstance(A, np.ndarray) and isinstance(B, np.ndarray):
> return np.dot(A, B)
> else:
> # mycode
> ?
> Maybe you are right. Since I can't overload `np.dot`, maybe the neater way 
> is to write a higher level function and then delegate the work by 
> inspecting the type.
>
>
> On Friday, October 7, 2016 at 7:56:59 PM UTC+2, Gabriel Gellner wrote:
>>
>> Any reason to not just use a function? (like np.dot etc)
>>
>> My understanding is that in python '*' means elementwise multiplication, 
>> so even if you could monkeypatch numpys __mul__ method to do the right 
>> thing wouldn't you be changing the semantics?
>>
>> Gabriel
>>
>> On Friday, October 7, 2016 at 3:51:11 AM UTC-6, Sisyphuss wrote:
>>
>>> In Julia, we can do multiple dispatch for operators, that is the 
>>> interpreter can identify:
>>> float + integer
>>> integer + integer
>>> integer + float
>>> float + float
>>> as well as *user-defined* data structure.
>>>
>>> Recently, I am working on Python (I have no choice because Spark hasn't 
>>> yet a Julia binding). I intended to do the same thing -- multiplication -- 
>>> between a Numpy matrix and self-defined Low-rank matrix. Of course, I 
>>> defined the `__rmul__ ` method for Low-rank matrix. However, it seems to me 
>>> that the Numpy matrix intercepts the `*` operator as its `__mul__` method, 
>>> which expects the argument on the right side of `*` to be a scalar.
>>>
>>> I would like to know if there is anyway around?
>>>
>>>

[julia-users] Re: multiple dispatch for operators

[Sisyphuss]

You mean:
def mydot(A,B):
if isinstance(A, np.ndarray) and isinstance(B, np.ndarray):
return np.dot(A, B)
else:
# mycode
?
Maybe you are right. Since I can't overload `np.dot`, maybe the neater way 
is to write a higher level function and then delegate the work by 
inspecting the type.


On Friday, October 7, 2016 at 7:56:59 PM UTC+2, Gabriel Gellner wrote:
>
> Any reason to not just use a function? (like np.dot etc)
>
> My understanding is that in python '*' means elementwise multiplication, 
> so even if you could monkeypatch numpys __mul__ method to do the right 
> thing wouldn't you be changing the semantics?
>
> Gabriel
>
> On Friday, October 7, 2016 at 3:51:11 AM UTC-6, Sisyphuss wrote:
>
>> In Julia, we can do multiple dispatch for operators, that is the 
>> interpreter can identify:
>> float + integer
>> integer + integer
>> integer + float
>> float + float
>> as well as *user-defined* data structure.
>>
>> Recently, I am working on Python (I have no choice because Spark hasn't 
>> yet a Julia binding). I intended to do the same thing -- multiplication -- 
>> between a Numpy matrix and self-defined Low-rank matrix. Of course, I 
>> defined the `__rmul__ ` method for Low-rank matrix. However, it seems to me 
>> that the Numpy matrix intercepts the `*` operator as its `__mul__` method, 
>> which expects the argument on the right side of `*` to be a scalar.
>>
>> I would like to know if there is anyway around?
>>
>>

Re: [julia-users] Re: multiple dispatch for operators

[Sisyphuss]

No, no, no, I am expert of neither language. I sincerely want to learn the 
difference between these 2 languages. This will help me better understand 
both Python and Julia.


On Friday, October 7, 2016 at 9:41:43 PM UTC+2, Stefan Karpinski wrote:
>
> I think you're asking on the wrong list :P
>
> On Fri, Oct 7, 2016 at 1:56 PM, Gabriel Gellner  > wrote:
>
>> Any reason to not just use a function? (like np.dot etc)
>>
>> My understanding is that in python '*' means elementwise multiplication, 
>> so even if you could monkeypatch numpys __mul__ method to do the right 
>> thing wouldn't you be changing the semantics?
>>
>> Gabriel
>>
>> On Friday, October 7, 2016 at 3:51:11 AM UTC-6, Sisyphuss wrote:
>>
>>> In Julia, we can do multiple dispatch for operators, that is the 
>>> interpreter can identify:
>>> float + integer
>>> integer + integer
>>> integer + float
>>> float + float
>>> as well as *user-defined* data structure.
>>>
>>> Recently, I am working on Python (I have no choice because Spark hasn't 
>>> yet a Julia binding). I intended to do the same thing -- multiplication -- 
>>> between a Numpy matrix and self-defined Low-rank matrix. Of course, I 
>>> defined the `__rmul__ ` method for Low-rank matrix. However, it seems to me 
>>> that the Numpy matrix intercepts the `*` operator as its `__mul__` method, 
>>> which expects the argument on the right side of `*` to be a scalar.
>>>
>>> I would like to know if there is anyway around?
>>>
>>>
>