Re: [julia-users] package reproducibility

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

[julia-users] Webapp Deployment

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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 =

[julia-users] Stumped by a subtyping issue

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

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

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 =

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

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:

Re: [julia-users] package reproducibility

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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)

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

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

[julia-users] 0.5 new generators syntax question

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:

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

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

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

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

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

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

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

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

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

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 >

[julia-users] Unusual amount of storage allocation

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"

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

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

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

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

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

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:

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

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,

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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?

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

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

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