Re: [julia-users] package reproducibility

[Derek Gaston]

A little late to the party... but has there been any thought to using Git
submodules to help with version dependencies between packages?

I know that Git submodules often have a bad reputation... but the project I
run (MOOSE: http://mooseframework.org ) has been using them for exactly
this purpose for a few years now and it's been working very well.

Just tossing it out there ;-)

Derek

On Mon, Oct 31, 2016 at 6:26 PM Milan Bouchet-Valat 
wrote:

> Le vendredi 28 octobre 2016 à 00:24 -0700, Kevin Kunzmann a écrit :
> > Hey,
> >
> > I was just wondering whether Julia has a checkpoint-like
> > functionality (R checkpoint-package) for using a specific checkpoint
> > of the package ecosystem. With quick development happening this would
> > improve reproducibility drastically.
> FWIW, this is one of the main features planned for the next version of
> the package management system (codenamed Pkg3). These would be called
> "environments".
>
>
> Regards
>

[julia-users] Webapp Deployment

[Reuben Brooks]

Context: I love julia, and I've never built any kind of webapp. Most of my 
programming experience is in Mathematica and Julia...hacking things 
together (poorly) in Python when nothing else works.

Problem: I have a script  / notebook in julia that pulls data from sources, 
analyzes it, builds fancy plots, and has lots of nice information. Now I 
want to build a basic webapp that will allow me to access this information 
anywhere, anytime (will be updated regularly). 

Question 1: is there a julia package that suits my needs well, or should I 
look at using some other fronted to create the frontend? Elm intrigues me, 
as much for the learning as for the actual solution. 

Bottom line: I don't know enough about what I'm wading into to choose 
wisely. What does the community suggest?

Re: [julia-users] inconsistent 'unique' in Atom

[Chris Rackauckas]

Just click on the number and it will expand it.

On Sunday, October 30, 2016 at 7:28:47 PM UTC-7, missp...@gmail.com wrote:
>
> Hi Yichao,
>
> thanks a lot, 
> it does display it correctly if I use dump, but it's annoying that Atom is 
> inconsistent while displaying the results
>
> thanks a lot,
>
> On Sunday, October 30, 2016 at 7:14:07 PM UTC-7, Yichao Yu wrote:
>>
>> On Sun, Oct 30, 2016 at 10:05 PM,   wrote: 
>> > Hi folks, 
>> > 
>> > I've noticed that in v5 the expression 
>> > 
>> > 
>> > unique([122 122.5 10 10.3]) 
>> > 
>> > 
>> > gives as result the following vector: 
>> > 
>> > 122 123 10 10.3 
>> > 
>> > 
>> > Any device? Is there any maximum number of characters displayed in the 
>> > console, or something similar? 
>>
>> I'm not sure how Atom display works but maybe you can try 
>> `dump(unique([122 122.5 10 10.3]))`. Also what if you just print `[122 
>> 122.5 10 10.3]` since the unique is supposed to be no op here? 
>>
>> > 
>> > thanks, 
>>
>

[julia-users] Re: Changing label fontsize in Plots.jl

[Chris Rackauckas]

Wonderful to see the learning process in action haha. For future reference, 
to see which commands are available in which packages, you can check the 
supported attributes page of the documentation. 


On Monday, October 31, 2016 at 3:05:30 PM UTC-7, Nitin Arora wrote:
>
> I opened an issue at Plots.jl github as this command is working with 
> pyplots but not pgfplots backend.
>
> On Monday, October 31, 2016 at 2:58:29 PM UTC-7, Nitin Arora wrote:
>>
>> I did try using the "guidefont" and "tickfont" commands but they seem to 
>> make no difference when implemented as below:
>>
>> scatter(Sol_U,:tof,:vinf,xlabel="Time (years)", ylabel="Arrival V(km/s)", 
>> marker = (:c, 2,stroke(0)),xlims = (6,12),tickfont=font(28),guidefont=
>> font(28))
>>
>> where Sol_U is a dataframe.
>>
>> I am using plots 0.9.4+ (master) and my Julia version is 0.5.1-pre+2
>>
>> thanks again !
>>
>> On Monday, October 31, 2016 at 2:48:40 PM UTC-7, Nitin Arora wrote:
>>>
>>> Hi,
>>>  
>>> Does anyone know how to change fontsize for xlabel, ylabel and axis 
>>> tick-labels in Plots.jl ? I am using the pgfplots backend.
>>>
>>> I dont see any examples on the Plots.jl demonstrating that. 
>>>
>>> Documentation I looked up: https://juliaplots.github.io/
>>>
>>> thanks,
>>> Nitin
>>>
>>

[julia-users] Re: What's julia's answer to tapply or accumarray?

[Chris Rackauckas]

For reference I've been gathering these kinds of "vectorized" functions in, 
well, VectorizedRoutines.jl 
. I am just 
trying to get an implementation of all of those vectorized routines you 
know and love since, in some cases, they lead to slick code. You can find 
an accumarray there. Feel free to add a PR that has more.

On Monday, October 31, 2016 at 12:38:06 PM UTC-7, phav...@gene.com wrote:
>
> RLEVectors.jl  now has a 
> tapply function where an RLE is used as the factor.
>
>
> On Thursday, March 20, 2014 at 10:46:33 AM UTC-7, James Johndrow wrote:
>>
>> I cannot seem to find a built-in julia function that performs the 
>> function of tapply in R or accumarray in matlab. Anyone know of one?
>>
>

[julia-users] Re: Stumped by a subtyping issue

[vavasis]

Eric,

Possibly the following paragraph from the Julia manual may be relevant.  
This paragraph is an excerpt from the section on parametric type aliases in 
the chapter "Types."  I am quite familiar with this paragraph because I 
authored it in a PR it after I was burned by a similar issue!

-- Steve Vavasis


"This declaration of Vector creates a subtype relation Vector{Int} <: Vector. 
However, it is not always the case that a parametric typealias statement 
creates such a relation; for example, the statement:

typealias AA{T} Array{Array{T,1},1}
 

does not create the relation AA{Int} <: AA. The reason is that 
Array{Array{T,1},1} is not an abstract type at all; in fact, it is a 
concrete type describing a 1-dimensional array in which each entry is an 
object of type Array{T,1} for some value of T."






On Monday, October 31, 2016 at 7:43:58 PM UTC-4, Eric Davies wrote:
>
> I am getting confusing behaviour with some complex type aliases while 
> using Cxx.jl and I was hoping someone could point out what is going on.
>
> These are the aliases:
>
> typealias CppAWSErrorType{C, I<:Integer} CppTemplate{CppBaseType{Symbol(
> "Aws::Client::AWSError")}, Tuple{CppEnum{C, I}}}
> typealias CppAWSError{C, I<:Integer, Q} CppRef{CppAWSErrorType{C, I}, Q}
>
> ...
> aws_raw_error = @cxx list_buckets_outcome->GetError()
> thetype = AWSCxx.CppAWSError{Symbol("Aws::S3::S3Errors"), Int32, (false, 
> false, false)}
>
> @test typeof(aws_raw_error) <: thetype  # success
> @test typeof(aws_raw_error) == thetype  # success
> @test isa(aws_raw_error, thetype)  # success
> @test typeof(aws_raw_error) <: AWSCxx.CppAWSError  # failure
> @test isa(aws_raw_error, AWSCxx.CppAWSError)  # failure
>
> Can anyone help?
>

Re: [julia-users] [ANNOUNCE] TestSetExtensions.jl

[Spencer Russell]

Normally I run my tests from the shell, so I focused on that use-case. I
do think a bit that it would be cool to have a way to run the tests
selectively from the julia REPL, but haven't put much time into thinking
about the best way. Feel free to file an issue with some suggestions (or
even better a PR) ;)

Then from a user's perspective it might be as easy as:

```
julia> using TestSetExtensions
julia> @includetests MyModule Set1
```

Though it would need to set `Base.ARGS` and then include `runtests.jl`so
that any setup gets done, and also would only work if the tests were
written using the `@includetests` macro.

-s


On Mon, Oct 31, 2016, at 08:54 PM, mmus wrote:
> My biggest problem with Base.Test is that you can't individually
> select which  testsets you want to run
> i.e. Pkg.test("MyModule","Set1")
> which makes testing really annoying.
>
> This package addresses this issue (albeit a little differently)
>
> I do believe having a more featured Base.Test with a few more
> batteries included is an overall boon.
>
>
> On Monday, October 31, 2016 at 12:25:47 PM UTC-4, Spencer
> Russell wrote:
>> I'm not planning on merging this functionality into Base.Test. I
>> think it's nice to keep Base.Test pretty minimal but extensible, and
>> then have extra functionality provided via packages so they're easier
>> for the community to iterate on and contribute to.
>>
>> -s
>>
>>
>> On Mon, Oct 31, 2016, at 02:17 AM, mmus wrote:
>>> Will these improvements make into Base.Test ?
>>>
>>> On Monday, October 31, 2016 at 12:53:37 AM UTC-4, Spencer Russell
>>> wrote:
 I think in general the culture in the Julia community is very pro-
 testing, which I really appreciate. I saw your post recently about
 PyTest, but I’m generally pretty happy with the built-in `@testset`
 / `@test` system, and just wanted some lightweight convenience
 functionality that wouldn’t require people to restructure their
 existing tests.

 -s


> On Oct 29, 2016, at 4:30 AM, pdo...@gmail.com wrote:
>
> Hey Spencer,
>
> I like this!
>
> I have recently started a testing-related package as well, maybe
> you've noticed (https://github.com/pdobacz/PyTest.jl). It seems
> that both packages could work together and complement quite
> seamlessly, so I'll definitely give yours a try.
>
> BTW, do you think there is much demand for Julia testing tools?
>>

Re: [julia-users] [ANNOUNCE] TestSetExtensions.jl

[mmus]

My biggest problem with Base.Test is that you can't individually select 
which  testsets you want to run
i.e. Pkg.test("MyModule","Set1")
which makes testing really annoying.

This package addresses this issue (albeit a little differently) 

I do believe having a more featured Base.Test with a few more batteries 
included is an overall boon.


On Monday, October 31, 2016 at 12:25:47 PM UTC-4, Spencer Russell wrote:
>
> I'm not planning on merging this functionality into Base.Test. I think 
> it's nice to keep Base.Test pretty minimal but extensible, and then have 
> extra functionality provided via packages so they're easier for the 
> community to iterate on and contribute to.
>
> -s
>
>
> On Mon, Oct 31, 2016, at 02:17 AM, mmus wrote:
>
> Will these improvements make into Base.Test ?
>
> On Monday, October 31, 2016 at 12:53:37 AM UTC-4, Spencer Russell wrote:
>
> I think in general the culture in the Julia community is very pro-testing, 
> which I really appreciate. I saw your post recently about PyTest, but I’m 
> generally pretty happy with the built-in `@testset` / `@test` system, and 
> just wanted some lightweight convenience functionality that wouldn’t 
> require people to restructure their existing tests.
>
> -s
>
>
> On Oct 29, 2016, at 4:30 AM, pdo...@gmail.com wrote:
>
> Hey Spencer,
>
> I like this! 
>
> I have recently started a testing-related package as well, maybe you've 
> noticed (https://github.com/pdobacz/PyTest.jl). It seems that both 
> packages could work together and complement quite seamlessly, so I'll 
> definitely give yours a try. 
>
> BTW, do you think there is much demand for Julia testing tools?
>
>
>

Re: [julia-users] Indexing a large matrix is MUCH slower (~ 150x) slower in 0.5 (and 0.6) than 0.4.7

[Yichao Yu]

On Mon, Oct 31, 2016 at 7:49 PM, Ian Butterworth
 wrote:
> I don't think so.. It happens on repeat function runs. I also updated to use
> benchmarktools.jl
> Even though, it takes so long (> 10 mins) on 0.5.0 I've only been patient
> enough for it to complete once...

As mentioned in the issue
(https://github.com/JuliaLang/julia/issues/19174#issuecomment-257456875)
I only tested on master since you said it happens there too. The PR
that probably fixed it was merged 7 days ago so you might want to try
a newer nightly. You can also try to apply the patch on the 0.5 branch
yourself although supposedly 0.5.1 should be prepared last weekend.

P.S. please cross link to the issue if you open one.

>
>
> using BenchmarkTools
> function testf(x)
> r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5));
> end
>
> x = rand(10,10,100,4,4,1000)   #Dummy array
> @benchmark testf(x)
>
> In 0.5.0 I get the following (with huge memory usage):
>
> BenchmarkTools.Trial:
>   samples:  1
>   evals/sample: 1
>   time tolerance:   5.00%
>   memory tolerance: 1.00%
>   memory estimate:  23.36 gb
>   allocs estimate:  1043200022
>   minimum time: 177.94 s (1.34% GC)
>   median time:  177.94 s (1.34% GC)
>   mean time:177.94 s (1.34% GC)
>   maximum time: 177.94 s (1.34% GC)
>
> In 0.4.7 I get:
>
> BenchmarkTools.Trial:
>   samples:  11
>   evals/sample: 1
>   time tolerance:   5.00%
>   memory tolerance: 1.00%
>   memory estimate:  727.55 mb
>   allocs estimate:  79
>   minimum time: 425.82 ms (0.06% GC)
>   median time:  485.95 ms (11.31% GC)
>   mean time:482.67 ms (10.37% GC)
>   maximum time: 503.27 ms (11.22% GC)
>
>
>
>
> On Monday, 31 October 2016 19:07:28 UTC-4, Yichao Yu wrote:
>>
>> On Mon, Oct 31, 2016 at 6:34 PM, Ian Butterworth
>>  wrote:
>> > I'm not sure of the etiquette, but I'm cross-posting this from
>> > stackoverflow
>> > as it seems like quite a significant issue...
>> >
>> > As an example:
>> >
>> > x = rand(10,10,100,4,4,1000)   #Dummy array
>> >
>> > tic()
>> > r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5))
>> > toc()
>> >
>> > Julia 0.5.0 -> elapsed time: 176.357068283 seconds
>> >
>> > Julia 0.4.7 -> elapsed time: 1.19991952 seconds
>> >
>> >
>> >
>> > I know this isn't really good practice, and I'm looking into using
>> > `view`
>> > but it's quite a bit performance decrease, so I thought I'd raise it.
>> >
>>
>> AFAICT it's all compilation time.
>>
>> >
>> >
>> > http://stackoverflow.com/questions/40351485/why-is-indexing-a-large-matrix-170x-slower-slower-in-julia-0-5-0-than-0-4-7

Re: [julia-users] Indexing a large matrix is MUCH slower (~ 150x) slower in 0.5 (and 0.6) than 0.4.7

[Ian Butterworth]

I don't think so.. It happens on repeat function runs. I also updated to 
use benchmarktools.jl 
Even though, it takes so long (> 10 mins) on 0.5.0 I've only been patient 
enough for it to complete once...


using BenchmarkTools
function testf(x)
r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5));
end

x = rand(10,10,100,4,4,1000)   #Dummy array
@benchmark testf(x)

In 0.5.0 I get the following (with huge memory usage):

BenchmarkTools.Trial: 
  samples:  1
  evals/sample: 1
  time tolerance:   5.00%
  memory tolerance: 1.00%
  memory estimate:  23.36 gb
  allocs estimate:  1043200022
  minimum time: 177.94 s (1.34% GC)
  median time:  177.94 s (1.34% GC)
  mean time:177.94 s (1.34% GC)
  maximum time: 177.94 s (1.34% GC)

In 0.4.7 I get:

BenchmarkTools.Trial: 
  samples:  11
  evals/sample: 1
  time tolerance:   5.00%
  memory tolerance: 1.00%
  memory estimate:  727.55 mb
  allocs estimate:  79
  minimum time: 425.82 ms (0.06% GC)
  median time:  485.95 ms (11.31% GC)
  mean time:482.67 ms (10.37% GC)
  maximum time: 503.27 ms (11.22% GC)




On Monday, 31 October 2016 19:07:28 UTC-4, Yichao Yu wrote:
>
> On Mon, Oct 31, 2016 at 6:34 PM, Ian Butterworth 
>  wrote: 
> > I'm not sure of the etiquette, but I'm cross-posting this from 
> stackoverflow 
> > as it seems like quite a significant issue... 
> > 
> > As an example: 
> > 
> > x = rand(10,10,100,4,4,1000)   #Dummy array 
> > 
> > tic() 
> > r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5)) 
> > toc() 
> > 
> > Julia 0.5.0 -> elapsed time: 176.357068283 seconds 
> > 
> > Julia 0.4.7 -> elapsed time: 1.19991952 seconds 
> > 
> > 
> > 
> > I know this isn't really good practice, and I'm looking into using 
> `view` 
> > but it's quite a bit performance decrease, so I thought I'd raise it. 
> > 
>
> AFAICT it's all compilation time. 
>
> > 
> > 
> http://stackoverflow.com/questions/40351485/why-is-indexing-a-large-matrix-170x-slower-slower-in-julia-0-5-0-than-0-4-7
>  
>

[julia-users] Stumped by a subtyping issue

[Eric Davies]

I am getting confusing behaviour with some complex type aliases while using 
Cxx.jl and I was hoping someone could point out what is going on.

These are the aliases:

typealias CppAWSErrorType{C, I<:Integer} CppTemplate{CppBaseType{Symbol(
"Aws::Client::AWSError")}, Tuple{CppEnum{C, I}}}
typealias CppAWSError{C, I<:Integer, Q} CppRef{CppAWSErrorType{C, I}, Q}

...
aws_raw_error = @cxx list_buckets_outcome->GetError()
thetype = AWSCxx.CppAWSError{Symbol("Aws::S3::S3Errors"), Int32, (false, 
false, false)}

@test typeof(aws_raw_error) <: thetype  # success
@test typeof(aws_raw_error) == thetype  # success
@test isa(aws_raw_error, thetype)  # success
@test typeof(aws_raw_error) <: AWSCxx.CppAWSError  # failure
@test isa(aws_raw_error, AWSCxx.CppAWSError)  # failure

Can anyone help?

Re: [julia-users] Indexing a large matrix is MUCH slower (~ 150x) slower in 0.5 (and 0.6) than 0.4.7

[Yichao Yu]

On Mon, Oct 31, 2016 at 6:34 PM, Ian Butterworth
 wrote:
> I'm not sure of the etiquette, but I'm cross-posting this from stackoverflow
> as it seems like quite a significant issue...
>
> As an example:
>
> x = rand(10,10,100,4,4,1000)   #Dummy array
>
> tic()
> r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5))
> toc()
>
> Julia 0.5.0 -> elapsed time: 176.357068283 seconds
>
> Julia 0.4.7 -> elapsed time: 1.19991952 seconds
>
>
>
> I know this isn't really good practice, and I'm looking into using `view`
> but it's quite a bit performance decrease, so I thought I'd raise it.
>

AFAICT it's all compilation time.

>
> http://stackoverflow.com/questions/40351485/why-is-indexing-a-large-matrix-170x-slower-slower-in-julia-0-5-0-than-0-4-7

[julia-users] Indexing a large matrix is MUCH slower (~ 150x) slower in 0.5 (and 0.6) than 0.4.7

[Ian Butterworth]

I'm not sure of the etiquette, but I'm cross-posting this from 
stackoverflow as it seems like quite a significant issue...

As an example:

x = rand(10,10,100,4,4,1000)   #Dummy array

tic()
r = squeeze(mean(x[:,:,1:80,:,:,56:800],(1,2,3,4,5)),(1,2,3,4,5))
toc()

Julia 0.5.0 -> elapsed time: 176.357068283 seconds

Julia 0.4.7 -> elapsed time: 1.19991952 seconds


I know this isn't really good practice, and I'm looking into using `view` 
but it's quite a bit performance decrease, so I thought I'd raise it.


http://stackoverflow.com/questions/40351485/why-is-indexing-a-large-matrix-170x-slower-slower-in-julia-0-5-0-than-0-4-7

Re: [julia-users] package reproducibility

[Milan Bouchet-Valat]

Le vendredi 28 octobre 2016 à 00:24 -0700, Kevin Kunzmann a écrit :
> Hey,
> 
> I was just wondering whether Julia has a checkpoint-like
> functionality (R checkpoint-package) for using a specific checkpoint
> of the package ecosystem. With quick development happening this would
> improve reproducibility drastically.
FWIW, this is one of the main features planned for the next version of
the package management system (codenamed Pkg3). These would be called
"environments".


Regards

Re: [julia-users] [ANNOUNCE] TestSetExtensions.jl

[Iain Dunning]

So happy you made this!

On Monday, October 31, 2016 at 4:25:47 PM UTC, Spencer Russell wrote:
>
> I'm not planning on merging this functionality into Base.Test. I think 
> it's nice to keep Base.Test pretty minimal but extensible, and then have 
> extra functionality provided via packages so they're easier for the 
> community to iterate on and contribute to.
>
> -s
>
>
> On Mon, Oct 31, 2016, at 02:17 AM, mmus wrote:
>
> Will these improvements make into Base.Test ?
>
> On Monday, October 31, 2016 at 12:53:37 AM UTC-4, Spencer Russell wrote:
>
> I think in general the culture in the Julia community is very pro-testing, 
> which I really appreciate. I saw your post recently about PyTest, but I’m 
> generally pretty happy with the built-in `@testset` / `@test` system, and 
> just wanted some lightweight convenience functionality that wouldn’t 
> require people to restructure their existing tests.
>
> -s
>
>
> On Oct 29, 2016, at 4:30 AM, pdo...@gmail.com wrote:
>
> Hey Spencer,
>
> I like this! 
>
> I have recently started a testing-related package as well, maybe you've 
> noticed (https://github.com/pdobacz/PyTest.jl). It seems that both 
> packages could work together and complement quite seamlessly, so I'll 
> definitely give yours a try. 
>
> BTW, do you think there is much demand for Julia testing tools?
>
>
>

[julia-users] Re: Changing label fontsize in Plots.jl

[Nitin Arora]

I opened an issue at Plots.jl github as this command is working with 
pyplots but not pgfplots backend.

On Monday, October 31, 2016 at 2:58:29 PM UTC-7, Nitin Arora wrote:
>
> I did try using the "guidefont" and "tickfont" commands but they seem to 
> make no difference when implemented as below:
>
> scatter(Sol_U,:tof,:vinf,xlabel="Time (years)", ylabel="Arrival V(km/s)", 
> marker = (:c, 2,stroke(0)),xlims = (6,12),tickfont=font(28),guidefont=font
> (28))
>
> where Sol_U is a dataframe.
>
> I am using plots 0.9.4+ (master) and my Julia version is 0.5.1-pre+2
>
> thanks again !
>
> On Monday, October 31, 2016 at 2:48:40 PM UTC-7, Nitin Arora wrote:
>>
>> Hi,
>>  
>> Does anyone know how to change fontsize for xlabel, ylabel and axis 
>> tick-labels in Plots.jl ? I am using the pgfplots backend.
>>
>> I dont see any examples on the Plots.jl demonstrating that. 
>>
>> Documentation I looked up: https://juliaplots.github.io/
>>
>> thanks,
>> Nitin
>>
>

[julia-users] Re: Changing label fontsize in Plots.jl

[Nitin Arora]

One more thing I found is that it works if I use pyplot as the backend so 
maybe its a pgfplots issue ?

On Monday, October 31, 2016 at 2:48:40 PM UTC-7, Nitin Arora wrote:
>
> Hi,
>  
> Does anyone know how to change fontsize for xlabel, ylabel and axis 
> tick-labels in Plots.jl ? I am using the pgfplots backend.
>
> I dont see any examples on the Plots.jl demonstrating that. 
>
> Documentation I looked up: https://juliaplots.github.io/
>
> thanks,
> Nitin
>

[julia-users] Re: Changing label fontsize in Plots.jl

[Nitin Arora]

I did try using the "guidefont" and "tickfont" commands but they seem to 
make no difference when implemented as below:

scatter(Sol_U,:tof,:vinf,xlabel="Time (years)", ylabel="Arrival V(km/s)", 
marker = (:c, 2,stroke(0)),xlims = (6,12),tickfont=font(28),guidefont=font(
28))

where Sol_U is a dataframe.

I am using plots 0.9.4+ (master) and my Julia version is 0.5.1-pre+2

thanks again !

On Monday, October 31, 2016 at 2:48:40 PM UTC-7, Nitin Arora wrote:
>
> Hi,
>  
> Does anyone know how to change fontsize for xlabel, ylabel and axis 
> tick-labels in Plots.jl ? I am using the pgfplots backend.
>
> I dont see any examples on the Plots.jl demonstrating that. 
>
> Documentation I looked up: https://juliaplots.github.io/
>
> thanks,
> Nitin
>

[julia-users] Changing label fontsize in Plots.jl

[Nitin Arora]

Hi,
 
Does anyone know how to change fontsize for xlabel, ylabel and axis 
tick-labels in Plots.jl ? I am using the pgfplots backend.

I dont see any examples on the Plots.jl demonstrating that. 

Documentation I looked up: https://juliaplots.github.io/

thanks,
Nitin

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

That looks better. So now the git stash and git stash apply trick should
work.

Bill.

On 31 October 2016 at 21:25, digxx  wrote:

> Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
> $ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   windows_build.txt
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
>

Re: [julia-users] [ANN] JuliaBerry org: Julia on the Raspberry Pi

[Simon Byrne]

And in the spirit of halloween:

https://youtu.be/MWz3YT8wJ9U

powered using Julia via this script:

https://gist.github.com/simonbyrne/4e476bcfb79216c3220b877c6d2bbe32

On Monday, 31 October 2016 16:26:43 UTC, Spencer Russell wrote:
>
> I love the logo!
>
> -s
>
>
> On Mon, Oct 31, 2016, at 08:39 AM, Simon Byrne wrote:
>
> Avik and myself have put together an organisation for those interested on 
> using Julia on the Raspberry Pi:
>
> https://juliaberry.github.io/
>
> (the name was chosen to avoid confusing with JuliaPy).
>
> Contributions are welcome!
>
> -Simon
>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   windows_build.txt

no changes added to commit (use "git add" and/or "git commit -a")

Re: [julia-users] 0.5 new generators syntax question

[Yichao Yu]

On Mon, Oct 31, 2016 at 3:42 PM, Jesse Jaanila  wrote:
> Hi,
>
> I was experimenting with the new 0.5 features and they are great! But to my
> surprise,
> the generator syntax doesn't work as I'm expecting. Let's say I want to
> calculate
> some summation. With the old syntax I could do
>
> @time sum([2*t for t in 1:2:100])
>   0.015104 seconds (13.80 k allocations: 660.366 KB)
>
> that allocates the array within the summation. Now I thought this would a
> prime example
> where the memory overhead could be decreased by using the new notation i.e.
>
> @time sum(2*t for t in 1:2:100)
>   0.019215 seconds (18.98 k allocations: 785.777 KB)
>
> ,but generator syntax performs slightly worse. Also if we want find the
> maximum we would do
>
> julia> @time maximum([2*t for t in 1:2:100])
>   0.015182 seconds (12.90 k allocations: 606.166 KB)
> 198
>
> julia> @time maximum(2*t for t in 1:2:100)
>   0.019935 seconds (18.74 k allocations: 772.180 KB)
> 198
>
> Have I understood the new generator syntax incorrectly or should the new
> syntax perform
> better in these code snippet examples?

Put it in a function since each syntactically different
generator/anonymous functions has their own type and you are
benchmarking the compiler only. It doesn't make sense for adding 50
numbers to take 15 ms.

>
>
>
>
>
>

[julia-users] 0.5 new generators syntax question

[Jesse Jaanila]

Hi,

I was experimenting with the new 0.5 features and they are great! But to my 
surprise,
the generator syntax doesn't work as I'm expecting. Let's say I want to 
calculate
some summation. With the old syntax I could do

@time sum([2*t for t in 1:2:100])
  0.015104 seconds (13.80 k allocations: 660.366 KB)

that allocates the array within the summation. Now I thought this would a 
prime example
where the memory overhead could be decreased by using the new notation i.e.

@time sum(2*t for t in 1:2:100)
  0.019215 seconds (18.98 k allocations: 785.777 KB)

,but generator syntax performs slightly worse. Also if we want find the 
maximum we would do

julia> @time maximum([2*t for t in 1:2:100])
  0.015182 seconds (12.90 k allocations: 606.166 KB)
198

julia> @time maximum(2*t for t in 1:2:100)
  0.019935 seconds (18.74 k allocations: 772.180 KB)
198

Have I understood the new generator syntax incorrectly or should the new 
syntax perform
better in these code snippet examples?

[julia-users] Re: What's julia's answer to tapply or accumarray?

[phaverty]

RLEVectors.jl  now has a 
tapply function where an RLE is used as the factor.


On Thursday, March 20, 2014 at 10:46:33 AM UTC-7, James Johndrow wrote:
>
> I cannot seem to find a built-in julia function that performs the function 
> of tapply in R or accumarray in matlab. Anyone know of one?
>

Re: [julia-users] Question: Forcing readtable to create string type on import

[Jacob Quinn]

You could use CSV.jl: http://juliadata.github.io/CSV.jl/stable/

In this case, you'd do:

df1 = CSV.read(file1; types=Dict(1=>String)) # assuming your account number
is column # 1
df2 = CSV.read(file2; types=Dict(1=>String))

-Jacob


On Mon, Oct 31, 2016 at 12:50 PM, LeAnthony Mathews 
wrote:

> Using v0.5.0
> I have two different 10,000 line CSV files that I am reading into two
> different dataframe variables using the readtable function.
> Each table has in common a ten digit account_number that I would like to
> use as an index and join into one master file.
>
> Here is the account number example in the original CSV from file1:
> 8018884596
> 8018893530
> 8018909633
>
> When I do a readtable of this CSV into file1 then do a*
> typeof(file1[:account_number])* I get:
> *DataArrays.DataArray(Int32,1)*
>  -571049996
>  -571041062
>  -571024959
>
> when I do a
> *typeof(file2[:account_number])*
> *DataArrays.DataArray(String,1)*
>
>
> *Question:  *
> My CSV files give no guidance that account_number should be Int32 or
> string type.  How do I force it to make both account_number elements type
> String?
>
> I would like this join command to work:
> *new_account_join = join(file1, file2, on =:account_number,kind = :left)*
>
> But I am getting this error:
> *ERROR: TypeError: typeassert: expected Union{Array{Symbol,1},Symbol}, got
> Array{*
> *Array{Symbol,1},1}*
> * in (::Base.#kw##join)(::Array{Any,1}, ::Base.#join,
> ::DataFrames.DataFrame, ::D*
> *ataFrames.DataFrame) at .\:0*
>
>
> Any help would be appreciated.
>
>
>

[julia-users] Question: Forcing readtable to create string type on import

[LeAnthony Mathews]

Using v0.5.0
I have two different 10,000 line CSV files that I am reading into two 
different dataframe variables using the readtable function.
Each table has in common a ten digit account_number that I would like to 
use as an index and join into one master file.

Here is the account number example in the original CSV from file1:
8018884596
8018893530
8018909633

When I do a readtable of this CSV into file1 then do a* 
typeof(file1[:account_number])* I get:
*DataArrays.DataArray(Int32,1)*
 -571049996
 -571041062
 -571024959

when I do a 
*typeof(file2[:account_number])*
*DataArrays.DataArray(String,1)*


*Question:  *
My CSV files give no guidance that account_number should be Int32 or string 
type.  How do I force it to make both account_number elements type String?

I would like this join command to work:
*new_account_join = join(file1, file2, on =:account_number,kind = :left)*

But I am getting this error:
*ERROR: TypeError: typeassert: expected Union{Array{Symbol,1},Symbol}, got 
Array{*
*Array{Symbol,1},1}*
* in (::Base.#kw##join)(::Array{Any,1}, ::Base.#join, 
::DataFrames.DataFrame, ::D*
*ataFrames.DataFrame) at .\:0*


Any help would be appreciated.  

Re: [julia-users] Preventing Bool<->Number conversion/promotion

[Stefan Karpinski]

See #18367  and #19168
.

On Mon, Oct 31, 2016 at 3:06 PM, Stefan Karpinski 
wrote:

> At the moment no, although there's been discussion of making Bool not a
> subtype of Number.
>
> On Mon, Oct 31, 2016 at 2:29 PM, Penn Taylor  wrote:
>
>> Is there a way to prevent automatic conversion/promotion between Bool and
>> Number types?
>>
>> Motivating examples:
>>
>> type Bools
>>   a::Bool
>>   b::Bool
>> end
>>
>> Bools(1, 0) #=> Bools(true,false)
>>
>> type Ints
>>   a::Int64
>>   b::Int64
>> end
>>
>> Ints(true, false) #=> Ints(1,0)
>>
>> In both of the above cases, I want the construction to fail.
>>
>> I'm aware that I could write constructors for these types to explicitly
>> reject Bool<->Number mismatch, but that gets tedious when there are more
>> than a few Number or Bool fields in a type. Wondering if there's an easier
>> way.
>>
>
>

Re: [julia-users] Preventing Bool<->Number conversion/promotion

[Stefan Karpinski]

At the moment no, although there's been discussion of making Bool not a
subtype of Number.

On Mon, Oct 31, 2016 at 2:29 PM, Penn Taylor  wrote:

> Is there a way to prevent automatic conversion/promotion between Bool and
> Number types?
>
> Motivating examples:
>
> type Bools
>   a::Bool
>   b::Bool
> end
>
> Bools(1, 0) #=> Bools(true,false)
>
> type Ints
>   a::Int64
>   b::Int64
> end
>
> Ints(true, false) #=> Ints(1,0)
>
> In both of the above cases, I want the construction to fail.
>
> I'm aware that I could write constructors for these types to explicitly
> reject Bool<->Number mismatch, but that gets tedious when there are more
> than a few Number or Bool fields in a type. Wondering if there's an easier
> way.
>

[julia-users] Unusual amount of storage allocation

[Douglas Bates]

I am encountering an unexpected amount of storage allocation in the 
cfactor!{A::HBlkDiag) method in the MixedModels package.  See
https://github.com/dmbates/MixedModels.jl/blob/master/src/cfactor.jl  for 
the code.

An HBlkDiag matrix is a homogeneous block diagonal matrix where 
"homogeneous" refers to the fact that all the diagonal blocks are square 
and of the same size.  Because of this homogeneity the blocks can be stored 
in an r by r by k array where r is the size of each of the square block and 
k is the number of such blocks.

On entry to this method the blocks are symmetric, positive semi-definite. 
 I want to overwrite the upper triangle of each of these blocks with its 
Cholesky factor.  I call LAPACK.potrf! directly because I don't want 
cholfact! to throw a non-positive-definite error.  The strange thing to me 
is that when I monitor the storage allocation, I get a huge amount of 
storage being allocated in the line with that call.  This may be because 
LAPACK.potrf! returns a tuple of the original matrix and an Int (the info 
code) but I'm not sure.

To see an example of this unusual amount of allocation try the following 
code with julia --track-allocation=user

using Feather, MixedModels
cd(Pkg.dir("MixedModels", "test", "data"))
sleepstudy = Feather.read("sleepstudy.feather", nullable=false)
fm1 = fit!(lmm(Reaction ~ 1 + Days + (1 + Days | Subject), sleepstudy))
Profile.clear_malloc_data()
devs, vars, betas, thetas = bootstrap(10_000, fm1)

I get

- function cfactor!{T}(A::HBlkDiag{T})
- Aa = A.arr
0 r, s, t = size(Aa)
0 if r ≠ s
0 throw(ArgumentError("HBlkDiag matrix A must be square"))
- end
 94428000 scm = Array(T, (r, r))
0 for k in 1 : t  # FIXME: Lots of allocations in this loop
0 for j in 1 : r, i in 1 : j
0 scm[i, j] = Aa[i, j, k]
- end
566568000 LAPACK.potrf!('U', scm)
0 for j in 1 : r, i in 1 : j
0 Aa[i, j, k] = scm[i, j]
- end
- end
 10492000 UpperTriangular(A)
- end

In this case the HBlkDiag matrix being decomposed has is 36 by 36 
consisting of 18 2 by 2 diagonal blocks.  scm is a scratch 2 by 2 
matrixthat is overwritten in sequence by the upper triangle of each of the 
original 2 by 2 blocks and passed to LAPACK.potrf!

[julia-users] Preventing Bool<->Number conversion/promotion

[Penn Taylor]

Is there a way to prevent automatic conversion/promotion between Bool and 
Number types?

Motivating examples:

type Bools
  a::Bool
  b::Bool
end

Bools(1, 0) #=> Bools(true,false)

type Ints
  a::Int64
  b::Int64
end

Ints(true, false) #=> Ints(1,0)

In both of the above cases, I want the construction to fail.

I'm aware that I could write constructors for these types to explicitly 
reject Bool<->Number mismatch, but that gets tedious when there are more 
than a few Number or Bool fields in a type. Wondering if there's an easier 
way.

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

Oh yeah, if you use Cygwin Git it screws up all the line endings in the
files, causing the Git repository to think every file needs committing.

Use native Windows Git instead.

Bill.

On 31 October 2016 at 17:35, digxx  wrote:

> Diger@Diger-PC /cygdrive/d/julia/v0.5/nemo
> $ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   .gitignore
> modified:   .travis.yml
> modified:   LICENSE.md
> modified:   README.md
> modified:   REQUIRE
> modified:   appveyor.yml
> modified:   benchmarks/bernoulli_polynomials.jl
> modified:   benchmarks/charpoly_integers.jl
> modified:   benchmarks/det_commutative_ring.jl
> modified:   benchmarks/det_field.jl
> modified:   benchmarks/det_polynomials.jl
> modified:   benchmarks/fateman.jl
> modified:   benchmarks/minpoly_finite_field.jl
> modified:   benchmarks/minpoly_gcd_domain.jl
> modified:   benchmarks/minpoly_integers.jl
> modified:   benchmarks/pearce.jl
> modified:   benchmarks/polynomials_number_field.jl
> modified:   benchmarks/resultant.jl
> modified:   benchmarks/runbenchmarks.jl
> modified:   benchmarks/solve_polynomials.jl
> modified:   deps/build.jl
> modified:   deps/patch-alloc-2.7.4
> modified:   doc/about.md
> modified:   doc/build.jl
> modified:   doc/build/acb.md
> modified:   doc/build/arb.md
> modified:   doc/build/classgroup.md
> modified:   doc/build/finitefield.md
> modified:   doc/build/fraction.md
> modified:   doc/build/integer.md
> modified:   doc/build/matrix.md
> modified:   doc/build/maximalorder.md
> modified:   doc/build/numberfield.md
> modified:   doc/build/padic.md
> modified:   doc/build/perm.md
> modified:   doc/build/polynomial.md
> modified:   doc/build/rational.md
> modified:   doc/build/residue.md
> modified:   doc/build/series.md
> modified:   doc/constructors.md
> modified:   doc/index.md
> modified:   doc/mathjaxhelper.js
> modified:   doc/mkdocs.yml
> modified:   doc/src/acb.md
> modified:   doc/src/arb.md
> modified:   doc/src/classgroup.md
> modified:   doc/src/finitefield.md
> modified:   doc/src/fraction.md
> modified:   doc/src/integer.md
> modified:   doc/src/matrix.md
> modified:   doc/src/maximalorder.md
> modified:   doc/src/numberfield.md
> modified:   doc/src/padic.md
> modified:   doc/src/perm.md
> modified:   doc/src/polynomial.md
> modified:   doc/src/rational.md
> modified:   doc/src/residue.md
> modified:   doc/src/series.md
> modified:   doc/types.md
> modified:   src/AbstractTypes.jl
> modified:   src/Factor.jl
> modified:   src/Groups.jl
> modified:   src/Nemo.jl
> modified:   src/Rings.jl
> modified:   src/ambiguities.jl
> modified:   src/antic/AnticTypes.jl
> modified:   src/antic/nf_elem.jl
> modified:   src/arb/ArbTypes.jl
> modified:   src/arb/acb.jl
> modified:   src/arb/acb_mat.jl
> modified:   src/arb/acb_poly.jl
> modified:   src/arb/arb.jl
> modified:   src/arb/arb_mat.jl
> modified:   src/arb/arb_poly.jl
> modified:   src/flint/FlintTypes.jl
> modified:   src/flint/fmpq.jl
> modified:   src/flint/fmpq_mat.jl
> modified:   src/flint/fmpq_poly.jl
> modified:   src/flint/fmpq_rel_series.jl
> modified:   src/flint/fmpz.jl
> modified:   src/flint/fmpz_mat.jl
> modified:   src/flint/fmpz_mod_poly.jl
> modified:   src/flint/fmpz_mod_rel_series.jl
> modified:   src/flint/fmpz_poly.jl
> modified:   src/flint/fmpz_rel_series.jl
> modified:   src/flint/fq.jl
> modified:   src/flint/fq_nmod.jl
> modified:   src/flint/fq_nmod_poly.jl
> modified:   src/flint/fq_nmod_rel_series.jl
> modified:   src/flint/fq_poly.jl
> modified:   src/flint/fq_rel_series.jl
> modified:   src/flint/nmod_mat.jl
> modified:   src/flint/nmod_poly.jl
> modified:   src/flint/padic.jl
> modified:   src/flint/perm.jl
> modified:   src/generic/Fraction.jl
> modified:   src/generic/GenericTypes.jl
> modified:   src/generic/Matrix.jl
> modified:   src/generic/Poly.jl
> modified:   src/generic/RelSeries.jl
> modified:   src/generic/Residue.jl
> modified:   src/pari/PariFactor.jl
> modified:   

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Diger@Diger-PC /cygdrive/d/julia/v0.5/nemo
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   .gitignore
modified:   .travis.yml
modified:   LICENSE.md
modified:   README.md
modified:   REQUIRE
modified:   appveyor.yml
modified:   benchmarks/bernoulli_polynomials.jl
modified:   benchmarks/charpoly_integers.jl
modified:   benchmarks/det_commutative_ring.jl
modified:   benchmarks/det_field.jl
modified:   benchmarks/det_polynomials.jl
modified:   benchmarks/fateman.jl
modified:   benchmarks/minpoly_finite_field.jl
modified:   benchmarks/minpoly_gcd_domain.jl
modified:   benchmarks/minpoly_integers.jl
modified:   benchmarks/pearce.jl
modified:   benchmarks/polynomials_number_field.jl
modified:   benchmarks/resultant.jl
modified:   benchmarks/runbenchmarks.jl
modified:   benchmarks/solve_polynomials.jl
modified:   deps/build.jl
modified:   deps/patch-alloc-2.7.4
modified:   doc/about.md
modified:   doc/build.jl
modified:   doc/build/acb.md
modified:   doc/build/arb.md
modified:   doc/build/classgroup.md
modified:   doc/build/finitefield.md
modified:   doc/build/fraction.md
modified:   doc/build/integer.md
modified:   doc/build/matrix.md
modified:   doc/build/maximalorder.md
modified:   doc/build/numberfield.md
modified:   doc/build/padic.md
modified:   doc/build/perm.md
modified:   doc/build/polynomial.md
modified:   doc/build/rational.md
modified:   doc/build/residue.md
modified:   doc/build/series.md
modified:   doc/constructors.md
modified:   doc/index.md
modified:   doc/mathjaxhelper.js
modified:   doc/mkdocs.yml
modified:   doc/src/acb.md
modified:   doc/src/arb.md
modified:   doc/src/classgroup.md
modified:   doc/src/finitefield.md
modified:   doc/src/fraction.md
modified:   doc/src/integer.md
modified:   doc/src/matrix.md
modified:   doc/src/maximalorder.md
modified:   doc/src/numberfield.md
modified:   doc/src/padic.md
modified:   doc/src/perm.md
modified:   doc/src/polynomial.md
modified:   doc/src/rational.md
modified:   doc/src/residue.md
modified:   doc/src/series.md
modified:   doc/types.md
modified:   src/AbstractTypes.jl
modified:   src/Factor.jl
modified:   src/Groups.jl
modified:   src/Nemo.jl
modified:   src/Rings.jl
modified:   src/ambiguities.jl
modified:   src/antic/AnticTypes.jl
modified:   src/antic/nf_elem.jl
modified:   src/arb/ArbTypes.jl
modified:   src/arb/acb.jl
modified:   src/arb/acb_mat.jl
modified:   src/arb/acb_poly.jl
modified:   src/arb/arb.jl
modified:   src/arb/arb_mat.jl
modified:   src/arb/arb_poly.jl
modified:   src/flint/FlintTypes.jl
modified:   src/flint/fmpq.jl
modified:   src/flint/fmpq_mat.jl
modified:   src/flint/fmpq_poly.jl
modified:   src/flint/fmpq_rel_series.jl
modified:   src/flint/fmpz.jl
modified:   src/flint/fmpz_mat.jl
modified:   src/flint/fmpz_mod_poly.jl
modified:   src/flint/fmpz_mod_rel_series.jl
modified:   src/flint/fmpz_poly.jl
modified:   src/flint/fmpz_rel_series.jl
modified:   src/flint/fq.jl
modified:   src/flint/fq_nmod.jl
modified:   src/flint/fq_nmod_poly.jl
modified:   src/flint/fq_nmod_rel_series.jl
modified:   src/flint/fq_poly.jl
modified:   src/flint/fq_rel_series.jl
modified:   src/flint/nmod_mat.jl
modified:   src/flint/nmod_poly.jl
modified:   src/flint/padic.jl
modified:   src/flint/perm.jl
modified:   src/generic/Fraction.jl
modified:   src/generic/GenericTypes.jl
modified:   src/generic/Matrix.jl
modified:   src/generic/Poly.jl
modified:   src/generic/RelSeries.jl
modified:   src/generic/Residue.jl
modified:   src/pari/PariFactor.jl
modified:   src/pari/PariIdeal.jl
modified:   src/pari/PariTypes.jl
modified:   src/pari/code_words.jl
modified:   src/pari/pari_frac.jl
modified:   src/pari/pari_int.jl
modified:   src/pari/pari_maximal_order_elem.jl
modified:   src/pari/pari_nf.jl
modified:   src/pari/pari_polmod.jl
modified:   src/pari/pari_poly.jl
modified:   src/pari/pari_poly2.jl
modified:   src/pari/pari_vec.jl
modified:   src/polysubst.jl

Re: [julia-users] [ANNOUNCE] TestSetExtensions.jl

[Spencer Russell]

I'm not planning on merging this functionality into Base.Test. I think
it's nice to keep Base.Test pretty minimal but extensible, and then have
extra functionality provided via packages so they're easier for the
community to iterate on and contribute to.

-s


On Mon, Oct 31, 2016, at 02:17 AM, mmus wrote:
> Will these improvements make into Base.Test ?
>
> On Monday, October 31, 2016 at 12:53:37 AM UTC-4, Spencer
> Russell wrote:
>> I think in general the culture in the Julia community is very pro-
>> testing, which I really appreciate. I saw your post recently about
>> PyTest, but I’m generally pretty happy with the built-in `@testset` /
>> `@test` system, and just wanted some lightweight convenience
>> functionality that wouldn’t require people to restructure their
>> existing tests.
>>
>> -s
>>
>>
>>> On Oct 29, 2016, at 4:30 AM, pdo...@gmail.com wrote:
>>>
>>> Hey Spencer,
>>>
>>> I like this!
>>>
>>> I have recently started a testing-related package as well, maybe
>>> you've noticed (https://github.com/pdobacz/PyTest.jl). It seems that
>>> both packages could work together and complement quite seamlessly,
>>> so I'll definitely give yours a try.
>>>
>>> BTW, do you think there is much demand for Julia testing tools?

Re: [julia-users] [ANN] JuliaBerry org: Julia on the Raspberry Pi

[Spencer Russell]

I love the logo!

-s


On Mon, Oct 31, 2016, at 08:39 AM, Simon Byrne wrote:
> Avik and myself have put together an organisation for those interested
> on using Julia on the Raspberry Pi:
>
> https://juliaberry.github.io/
>
> (the name was chosen to avoid confusing with JuliaPy).
>
> Contributions are welcome!
>
> -Simon

Re: [julia-users] Quote-friendly way to express keyword Expr?

[Penn Taylor]

I'm manipulating keyword args inside a macro. Just wanted to check whether 
I was missing a syntax option for building those expressions.

On Sunday, October 30, 2016 at 8:55:32 PM UTC-5, Isaiah wrote:
>
> Not really clear what you are trying to do. These are inserted by the 
> parser whenever keyword arguments are used in (function) call syntax. So:
>
> julia> quote f(x= 10) end |> dump
> Expr
>   head: Symbol block
>   args: Array{Any}((2,))
> 1: Expr
>   head: Symbol line
>   args: Array{Any}((2,))
> 1: Int64 1
> 2: Symbol REPL[6]
>   typ: Any
> 2: Expr
>   head: Symbol call
>   args: Array{Any}((2,))
> 1: Symbol f
> 2: Expr
>   head: Symbol kw
>   args: Array{Any}((2,))
> 1: Symbol x
> 2: Int64 10
>   typ: Any
>   typ: Any
>   typ: Any
>
>
>
> On Sun, Oct 30, 2016 at 12:47 AM, Penn Taylor  > wrote:
>
>> Is there a quote-friendly way to write the following keyword Expr, or 
>> must I directly manipulate raw Expr's to get this?
>>
>> Expr(:kw, :foo, 2)
>>
>>
>> By "quote-friendly", I mean a form such as
>>
>> :(stuff)
>>
>> # or
>>
>> quote
>>  stuff
>> end
>>
>
>

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

Ok, it was just a guess.

At least do git status in .julia/v0.5/Nemo to see what isn't clean.

Bill.

On 31 October 2016 at 15:07, digxx  wrote:

>
>
> Am Montag, 31. Oktober 2016 14:27:26 UTC+1 schrieb Bill Hart:
>>
>> It's probably due to the fact that you've made some changes in the git
>> repository. You can do git stash to temporarily store the changes you made,
>> then do Pkg.update() and then if you still need the changes, do git stash
>> apply.
>>
>> Bill.
>>
>
> hm...what?
> If I do git stash in cygwin I get:
>
>  Diger@Diger-PC ~
> $ git stash
> fatal: Not a git repository (or any of the parent directories): .git
>
> What specific changes are u refering to ?
>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Montag, 31. Oktober 2016 14:27:26 UTC+1 schrieb Bill Hart:
>
> It's probably due to the fact that you've made some changes in the git 
> repository. You can do git stash to temporarily store the changes you made, 
> then do Pkg.update() and then if you still need the changes, do git stash 
> apply.
>
> Bill.
>

hm...what?
If I do git stash in cygwin I get:

 Diger@Diger-PC ~
$ git stash
fatal: Not a git repository (or any of the parent directories): .git

What specific changes are u refering to ?

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

It's probably due to the fact that you've made some changes in the git
repository. You can do git stash to temporarily store the changes you made,
then do Pkg.update() and then if you still need the changes, do git stash
apply.

Bill.

On 31 October 2016 at 13:58, digxx  wrote:

>
>
> Am Freitag, 28. Oktober 2016 13:31:13 UTC+2 schrieb Bill Hart:
>>
>> We'll consider changing it. It's mainly supposed to be for us developers
>> so we can build the binaries, but if people want to actually use it, I
>> guess we should maintain it a bit more carefully.
>>
>> Bill.
>>
>
> BTW, when trying to Pkg.update() it now tells me:
> julia> Pkg.update()
> INFO: Updating METADATA...
> WARNING: Package Nemo: skipping update (dirty)...
> INFO: Computing changes...
> INFO: No packages to install, update or remove
>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Freitag, 28. Oktober 2016 13:31:13 UTC+2 schrieb Bill Hart:
>
> We'll consider changing it. It's mainly supposed to be for us developers 
> so we can build the binaries, but if people want to actually use it, I 
> guess we should maintain it a bit more carefully.
>
> Bill.
>

BTW, when trying to Pkg.update() it now tells me:
julia> Pkg.update()
INFO: Updating METADATA...
WARNING: Package Nemo: skipping update (dirty)...
INFO: Computing changes...
INFO: No packages to install, update or remove
 

[julia-users] [ANN] JuliaBerry org: Julia on the Raspberry Pi

[Simon Byrne]

Avik and myself have put together an organisation for those interested on 
using Julia on the Raspberry Pi:

https://juliaberry.github.io/

(the name was chosen to avoid confusing with JuliaPy).

Contributions are welcome!

-Simon

Re: [julia-users] Unit Testing: should I use Base.Test instead of FactCheck?

[Florian Oswald]

Awesome. Thanks!


On Monday, 31 October 2016, Spencer Russell  wrote:

> I generally have pretty granular `@testset`s, which can have messages
> attached that are printed on failure. That way I still get a description of
> what failed.
>
> I think the lack of indentation for nested testsets is a regression that
> hit 0.5 (BaseTestNext on 0.4 indents nested testsets), and there’s
> currently an issue filed: https://github.com/JuliaLang/julia/issues/18611
>
> so they should get re-prettified soon enough.
>
> -s
>
>
> On Fri, Oct 28, 2016, at 10:30 AM, Florian Oswald wrote:
>
> I know there are many testing packages out there. I have been using
> FactCheck, but have seen it's been relegated to the JuliaArchive. I take
> that as a sign it's a good moment to use something else.
>
> There is 1 thing I sorely miss from Base.Test coming from FactCheck, and
> that is the ability to say
>
> @fact false --> true "your test failed: false is not true"
>
> i.e. i can print a custom error message to be shown upon failure only.
>
> I also think the display of test results (indentation of lower level
> "contexts" (@testsets in Base.Test)) is nicer in FactCheck, but that's not
> that important.
>
> Thanks for any advice.
>
>
>
>

Re: [julia-users] [ANNOUNCE] TestSetExtensions.jl

[mmus]

Will these improvements make into Base.Test ?

On Monday, October 31, 2016 at 12:53:37 AM UTC-4, Spencer Russell wrote:
>
> I think in general the culture in the Julia community is very pro-testing, 
> which I really appreciate. I saw your post recently about PyTest, but I’m 
> generally pretty happy with the built-in `@testset` / `@test` system, and 
> just wanted some lightweight convenience functionality that wouldn’t 
> require people to restructure their existing tests.
>
> -s
>
>
> On Oct 29, 2016, at 4:30 AM, pdo...@gmail.com  wrote:
>
> Hey Spencer,
>
> I like this! 
>
> I have recently started a testing-related package as well, maybe you've 
> noticed (https://github.com/pdobacz/PyTest.jl). It seems that both 
> packages could work together and complement quite seamlessly, so I'll 
> definitely give yours a try. 
>
> BTW, do you think there is much demand for Julia testing tools?
>
>
>