[julia-users] Re: Why is julia interpreting what's inside a string?

[Sean Marshallsay]

Note that if you need the equivalent of Python's raw strings you can just 
use an empty macro

julia> macro raw_str(s) s end

julia> raw"3.2 3.6 z(x,y) = x@~\327@~exp(-x@+2@+-y@+2@+)"
"3.2 3.6 z(x,y) = x@~\\327@~exp(-x@+2@+-y@+2@+)"

julia> raw"grdmath $ DDX"
"grdmath \$ DDX"

julia>



On Monday, 7 September 2015 00:08:30 UTC+1, J Luis wrote:
>
> I need to create these, not to interpret what julia thinks it means.
>
> julia> "3.2 3.6 z(x,y) = x@~\327@~exp(-x@+2@+-y@+2@+)"
> ERROR: syntax: invalid UTF-8 sequence
>
> julia> "grdmath $ DDX"
> ERROR: syntax: invalid interpolation syntax: "$ "
>
> How do I do that?
>
> Thanks
>

Re: [julia-users] Re: The new Dict syntax in 0.4 is very verbose

[Sean Marshallsay]

[1:10;] is simply a consequence of matrix literal syntax (like [1:10; 
11:20]) and gets translated into vcat(1:10). It might be a bit confusing 
but there's no point in making it a special case.

On Thursday, 3 September 2015 17:28:27 UTC+1, Scott Jones wrote:
>
> To me, the use of ; within [ ] seems pretty confusing.
> Elsewhere in Julia, it seems to mean, throw away the result, so I would 
> have expected [1:10; ] to be equivalent to [].
> Why is [1:10;] (confusing, ; is not consistent with any other uses in 
> Julia),
> preferred over [1:10...] (easy to understand, consistent with other uses 
> in Julia)?
>
> On Thursday, September 3, 2015 at 11:25:32 AM UTC-4, Jeff Bezanson wrote:
>>
>> For `[1:10]`, I recommend `collect(1:10)` or `[1:10;]`. Splatting 
>> should be avoided where possible. 
>>
>> On Thu, Sep 3, 2015 at 11:22 AM,   wrote: 
>> > Early adopters shouldn't throw stones... :) But in fact I quite like 
>> the new 
>> > Dict syntax, which seems to be more explicit and readable. Curly braces 
>> seem 
>> > to be gainfully employed elsewhere doing type stuff. And experts can 
>> make 
>> > short cuts, either in Julia or in their editors... 
>> > 
>> > I confess I'm a bit puzzled by having to change `[1:10]` to 
>> `[1:10...]`, but 
>> > then again, `collect(1:10)` is more explicit and readable. So I think 
>> it's 
>> > progress. 
>> > 
>> > I suppose, as a former user of The Programming Language Formerly Known 
>> as 
>> > Mathematica", I might be more grateful than others for a  less 
>> > punctuation-heavy language syntax. Mathematica Wizards can fluently 
>> read and 
>> > write code like this: 
>> > 
>> >  lcm = Fold[#/#2/._~_~x_|_:>#x&,1,{##}]& 
>> > 
>> > but I'm happy with a more readable approach. 
>>
>

[julia-users] Re: [ANN] SQLite.jl package update

[Sean Marshallsay]

Hi Chris, see this comment 
(https://github.com/quinnj/SQLite.jl/issues/60#issuecomment-69058463) for 
how to convert to a DataFrame. As for dblistTables(), SQLite.jl exports a 
tables(db::SQLiteDB) method, does this do what you want?

On Monday, 24 August 2015 15:13:33 UTC+1, Christopher Fisher wrote:
>
> Hi Jacob. I was wondering if you (or someone else) would mind answering a 
> few questions? First, can you elaborate more on the method of converting a 
> ResultSet to a DataFrame? Second, is there a way to list all of the tables 
> in a database, something akin to dblistTables() in R? Thank you. 
>

[julia-users] Re: Speed Comparison "Julia vs R vs C++" a question.

[Sean Marshallsay]

Firstly read the following 
thoroughly: http://docs.julialang.org/en/release-0.3/manual/performance-tips/

Secondly I'd try to avoid IO when benchmarking unless IO is a necessary 
part of the operation.

My guess is you'll get a big speedup just by putting everything in a 
function, but there'll be other optimisations to make as well.

On Sunday, 23 August 2015 00:01:30 UTC+1, Michael Wang wrote:
>
> I am new to Julia. I heard that even Julia is a high level language, but 
> it has the speed of C or C++. I have tested an example on my machine. Using 
> the same input and having the same output, R uses around 30 seconds, Julia 
> uses around 15 seconds, while C++ only uses 0.23 seconds. Why this is 
> happening? I have attached my codes and sample dataset.
>
> R codes:
>
> DPY <- 252  ## days per year
> NWINDOW <- 126  ## can be smaller or larger than 252
>
> ds <- read.csv("xri.csv")  ## a sample data set
>
> b.ols <- sd.ols <- rep(NA, nrow(ds))
>
> for (i in 1:nrow(ds)) {
> thisday <- ds$day[i]
> if (thisday %% DPY != 0) next  ## calculate only on year end
> if (thisday < DPY) next  ## start only without NA
> thisfm <- ds$fm[i]
> datasubset <- subset( ds, (ds$fm==thisfm) & 
> (ds$day>=(thisday-NWINDOW)) & (ds$day<=(thisday-1)) )
>  olsreg <- lm(xr ~ xm, data = datasubset)
> b.ols[i] <- coef(olsreg)[2]
> sd.ols[i] <- sqrt(vcov(olsreg)[2, 2])
> cat(i, " ")  ## ping me to see we are not dead for large data sets
> }
>
> ds$b.ols <- b.ols
> ds$sd.ols <- sd.ols
>
> cat("\nOLS Beta Regressions are Done\n")
>
> ds$xsect.sd <- ave(ds$b.ols, ds$day, FUN=function(x) sd(x, na.rm=T))
> ds$xsect.mean <- ave(ds$b.ols, ds$day, FUN=function(x) mean(x, na.rm=T))
>
> cat("Cross-Sectional OLS Statistics are Done\n")
>
> ds <- within(ds, {
>  w.ols <- xsect.sd^2/(sd.ols^2+xsect.sd^2)
>  b.vck <- round(w.ols*b.ols + (1-w.ols)*xsect.mean,4)
>  b.ols <- round(b.ols,4)
>  })
>
> cat("OLS and VCK are Done.  Now Writing Output.\n")
>
>
>
>
> Julia codes:
> # load in the required package
> using DataFrames
> using DataFramesMeta
> using GLM
>
> tic()
> DPY = 252  ## days per year
> NWINDOW = 126  ## can be smaller or larger than 252
>
> ds = readtable("xri.csv")  ## a sample data set
>
> # create two empty arrays to store b_ols and sd_ols value
> b_ols = DataArray(Float64, size(ds)[1])
> sd_ols = DataArray(Float64, size(ds)[1])
>
> for i = 1:size(ds)[1]
> thisDay = ds[i, :day] ## Julia DataFrame way of accessing data, in R: 
> ds$day[i]
> if mod(thisDay, DPY) != 0
> continue
> end
> if thisDay < DPY
> continue
> end
> thisFm = ds[i, :fm]
> dataSubset = @where(ds, (:fm .== thisFm) & (:day .>= (thisDay - NWINDOW)) 
> & (:day .<= (thisDay - 1)))
> ## DataFramesMeta useage. fast subseting a dataframe. the dot operator is 
> the same as Matlab representing
> ## element-wise operation
> olsReg = fit(LinearModel, xr ~ xm, dataSubset) ## OLS from package GLM
> b_ols[i] = coef(olsReg)[2] ## returns the OLS coefficients
> sd_ols[i] = stderr(olsReg)[2] ## returns the OLS coefficients' standard 
> error
> print(i, " ")
> end
>
> # adding new columns to the ds dataframe
> ds[:b_ols] = b_ols
> ds[:sd_ols] = sd_ols
>
> print("\nOLS Beta Regressions are Done\n")
>
> ds = join(ds, by(ds, :day) do ds
> DataFrame(xsect_mean = mean(dropna(ds[:b_ols])), xsect_sd = 
> std(dropna(ds[:b_ols])))
> end, on = [:day], kind = :inner)
> ds = sort!(ds)
>
> print("Cross-Sectional OLS Statistics are Done\n")
>
> # adding new columns and editing columns using DataFrameMeta 
> ds[:w_ols] = @with(ds, :xsect_sd.^2 ./ (:sd_ols.^2 + :xsect_sd.^2))
> ds[:b_vck] = @with(ds, round(:w_ols .* :b_ols + (1 - :w_ols) .* 
> :xsect_mean, 4))
> ds[:b_ols] = @with(ds, round(:b_ols, 4))
>
> print("OLS and VCK are Done.  Now Writing Output.\n")
>
> toc()
>
>
>
>

[julia-users] Re: Julia and VIM - My working setup

[Sean Marshallsay]

Yep, that's a feature of julia-vim.

On Sunday, 3 May 2015 13:11:52 UTC+1, Sisyphuss wrote:
>
> I'd like to know, if you type "\alpha" in vim, will it be replaced by 
> the greek character ?
>
>
> On Saturday, May 2, 2015 at 10:35:38 PM UTC+2, Krishna Subramanian wrote:
>>
>> After a long search, I have finally found a solution for working with the 
>> Julia REPL and vim. I am working in a Windows 7/x64 environment but I 
>> believe my setup can also be used in other situations. I am posting it here 
>> in the hopes of it being useful to some other vimmer getting their hands 
>> dirty with Julia.
>>
>> My earlier setup was a follows - 
>>
>> 1. Manually sync the directories of gvim and julia REPL
>> 2. Open file in gvim, save, in julia, do include("foo.jl") and iterate
>> 3. Keep doing the Alt+Tab to keep going back and forth between the two
>>
>> After a point, it because clear that this setup is not going to fly. My 
>> current setup is as follows-
>>
>> 1. Install Cygwin and in particular bash and GNU/screen
>> 2. Ensure that the bash.exe and screen.exe from cygwin are in your PATH
>> 3. Ensure that julia.exe is in your PATH
>> 4. In vim, install julia-vim , 
>> ervandew/screen  plugins
>> 5. Make some changes to the _vimrc (my setup is below)
>>
>> My current setup helps me work as follows (can be modified using _vimrc 
>> mappings)
>>
>>
>>1. Start gvim
>>2. cd to required directory
>>3. Type  in normal mode
>>4. This starts a julia session that communicates with gvim using 
>>screen. It also automatically changes the directory in the julia REPL to 
>>the directory gvim cwd.
>>5. Open the main script (say run.jl) in gvim
>>6. You can execute commands from this file in two ways 
>>   - Typing  in gvim executes the whole paragraph in 
>>   which the cursor is located, i.e. this paragraph is automatically sent 
>> to 
>>   Julia REPL for execution
>>   - Typing s sends the command 'include("run.jl");' to 
>>   julia, i.e. whatever is the current buffer in gvim
>>7. I have made another modification so that I can designate a file in 
>>gvim as the main file, say, run.jl and then begin editing another script 
>>foo.jl that is including from run.jl. Now typing s sends the 
>>designated main script, i.e. "include("run.jl")" to julia. I can continue 
>>to work on foo.jl and look at the results in the julia REPL
>>8. When I am done with julia, I type x to end the julia 
>>session which automatically closes julia and the screen session
>>
>>
>> This setup has done wonders to my productivity when I am working with 
>> Julia. My demo _vimrc script is here [Gist Link 
>> ].
>>
>> Thanks.
>>
>

Re: [julia-users] replace \$ with $ in string

[Sean Marshallsay]

Tamas, you can define a macro `macro raw_str(s) s end` which does what I 
think you want:

julia> macro raw_str(s) s end

julia> raw"This macro \t escapes \n any $special $(characters) for you."
"This macro \\t escapes \\n any \$special \$(characters) for you."



On Sunday, 26 April 2015 13:44:05 UTC+1, Tamas Papp wrote:
>
> Maybe something like 
>
> julia> s = "my \\ escaped \\\$ \$ string" 
> "my \\ escaped \\\$ \$ string" 
>
> julia> replace(s, "\\\$", "\$") 
> "my \\ escaped \$ \$ string" 
>
> Best, 
>
> Tamas 
>
> PS.: Incidentally, is there a way to enter strings with $ without 
> escaping them? Ie something like a non-standard string literal that just 
> ignores the $'s. 
>
> On Sun, Apr 26 2015, will ship > 
> wrote: 
>
> > Hi 
> > 
> > I am reading in a text file with special characters e.g. : " Blah is 
> $LBP" 
> > when I read it in to a variable the "$" gets replaced with "\$". But I 
> > actually want the $ non-escaped so that when handling the string 
> variable 
> > it prints the $LBP value. 
> > 
> > Is there anyway of doing this, our just to remove the "\" in the string 
> > without removing the "$" as well? 
> > 
> > Thanks in advance. 
> > 
> > Will 
>

Re: [julia-users] Re: General question about composite types

[Sean Marshallsay]

Sorry about that. Is there some work going into making `type` densely 
packed or am I way off base here?

On Tuesday, 3 March 2015 21:39:14 UTC, Mauro wrote:
>
> Cool.  Thanks for clearing this up. 
>
> On Tue, 2015-03-03 at 22:25, Matt Bauman > 
> wrote: 
> > Because it's not true! You were right.  Only "bitstype" immutables can 
> be 
> > densely packed. 
> > 
> > You can see this by unsafely getting Julia to show you the contents as 
> > other types: 
> > 
> > julia> pointer_to_array(Ptr{Float64}(pointer(b)), 4) 
> > 4-element Array{Float64,1}: 
> >  2.17696e-314 
> >  2.17696e-314 
> >  2.17795e-314 
> >  2.17795e-314 
> > 
> > 
> > # That's not right, let's try them as UInt64 memory offsets: 
> > julia> pointer_to_array(Ptr{UInt64}(pointer(b)), 2) 
> > 2-element Array{UInt64,1}: 
> >  0x000106a16fb8 
> >  0x000106a16fd0 
> > 
> > 
> > # Let's try loading one of those as a pointer to type B: 
> > julia> x = unsafe_pointer_to_objref(Ptr{B}(ans[1])) 
> > B(4.0,5.0) 
> > 
> > 
> > # And let's change it: 
> > julia> x.x = 8.0 
> > 8.0 
> > 
> > 
> > # That change propagated to b: 
> > julia> b 
> > 2-element Array{B,1}: 
> >  B(8.0,5.0) 
> >  B(5.0,6.0) 
> > 
> > 
> > On Tuesday, March 3, 2015 at 4:14:37 PM UTC-5, Mauro wrote: 
> >> 
> >> > If you're type has only concrete field then it will be densely packed 
> >> > regardless of wether it's immutable or not. 
> >> 
> >> I see, sorry for the misinformation!  So how comes that in below 
> example 
> >> this happens: 
> >> 
> >> julia> reinterpret(Float64,a) 
> >> 4-element Array{Float64,1}: 
> >>  4.0 
> >>  5.0 
> >>  5.0 
> >>  6.0 
> >> 
> >> julia> reinterpret(Float64,b) 
> >> ERROR: cannot reinterpret Array of type B 
> >>  in reinterpret at array.jl:77 
> >>  in reinterpret at array.jl:62 
> >> 
> >> 
> >> > On Tuesday, 3 March 2015 17:15:20 UTC, Mauro wrote: 
> >> >> 
> >> >> > Mauro, I do not quite understand what you're saying about densely 
> >> packed 
> >> >> > arrays, could you explain a bit more? 
> >> >> 
> >> >> Consider: 
> >> >> 
> >> >> julia> immutable A 
> >> >>x::Float64 
> >> >>y::Float64 
> >> >>end 
> >> >> 
> >> >> julia> type B 
> >> >>x::Float64 
> >> >>y::Float64 
> >> >>end 
> >> >> 
> >> >> julia> a = [A(4,5), A(5,6)] 
> >> >> 2-element Array{A,1}: 
> >> >>  A(4.0,5.0) 
> >> >>  A(5.0,6.0) 
> >> >> 
> >> >> julia> b = [B(4,5), B(5,6)] 
> >> >> 2-element Array{B,1}: 
> >> >>  B(4.0,5.0) 
> >> >>  B(5.0,6.0) 
> >> >> 
> >> >> Then in memory `a` is actually identical to: 
> >> >> 
> >> >> [4., 5., 5., 6.] 
> >> >> 
> >> >> (or 
> >> >> [4. 5.; 5. 6.]  ) 
> >> >> 
> >> >> As Julia knows that the type of `a` is Vector{A}, it knows how to 
> >> >> interpret that junk of memory.  Conversely, `b` is a vector of 
> pointers 
> >> >> which point to the two instances of `B`.  So, working with b is 
> slower 
> >> >> than an Array{Float64,2} whereas a should be just as fast. 
> >> >> 
> >> >> > Thanks, 
> >> >> > Chris 
> >> >> > 
> >> >> > On Tuesday, March 3, 2015 at 11:41:53 AM UTC-5, Mauro wrote: 
> >> >> >> 
> >> >> >> > I believe if all your type fields are concrete (which they are 
> in 
> >> the 
> >> >> >> case 
> >> >> >> > of Float64), the performance should be the same as using 
> >> >> >> Vector{Float64}. 
> >> >> >> > This is really nice since you get to use code that is much more 
> >> >> >> > understandable like state.x instead of state[1] for no penalty. 
> >> >> >> 
> >> >> >> I think to get densely packed array the type needs to be 
> immutable: 
> >> >> >> 
> >> >> >> immutable StateVec 
> >> >> >> x::Float64 
> >> >> >> y::Float64 
> >> >> >> z::Float64 
> >> >> >> end 
> >> >> >> 
> >> >> >> Otherwise it will be an array of pointers. 
> >> >> >> 
> >> >> 
> >> >> 
> >> 
> >> 
>
>

Re: [julia-users] Re: General question about composite types

[Sean Marshallsay]

You've got me doubting myself now, I could well be wrong then.

On Tuesday, 3 March 2015 21:14:37 UTC, Mauro wrote:
>
> > If you're type has only concrete field then it will be densely packed 
> > regardless of wether it's immutable or not. 
>
> I see, sorry for the misinformation!  So how comes that in below example 
> this happens: 
>
> julia> reinterpret(Float64,a) 
> 4-element Array{Float64,1}: 
>  4.0 
>  5.0 
>  5.0 
>  6.0 
>
> julia> reinterpret(Float64,b) 
> ERROR: cannot reinterpret Array of type B 
>  in reinterpret at array.jl:77 
>  in reinterpret at array.jl:62 
>
>
> > On Tuesday, 3 March 2015 17:15:20 UTC, Mauro wrote: 
> >> 
> >> > Mauro, I do not quite understand what you're saying about densely 
> packed 
> >> > arrays, could you explain a bit more? 
> >> 
> >> Consider: 
> >> 
> >> julia> immutable A 
> >>x::Float64 
> >>y::Float64 
> >>end 
> >> 
> >> julia> type B 
> >>x::Float64 
> >>y::Float64 
> >>end 
> >> 
> >> julia> a = [A(4,5), A(5,6)] 
> >> 2-element Array{A,1}: 
> >>  A(4.0,5.0) 
> >>  A(5.0,6.0) 
> >> 
> >> julia> b = [B(4,5), B(5,6)] 
> >> 2-element Array{B,1}: 
> >>  B(4.0,5.0) 
> >>  B(5.0,6.0) 
> >> 
> >> Then in memory `a` is actually identical to: 
> >> 
> >> [4., 5., 5., 6.] 
> >> 
> >> (or 
> >> [4. 5.; 5. 6.]  ) 
> >> 
> >> As Julia knows that the type of `a` is Vector{A}, it knows how to 
> >> interpret that junk of memory.  Conversely, `b` is a vector of pointers 
> >> which point to the two instances of `B`.  So, working with b is slower 
> >> than an Array{Float64,2} whereas a should be just as fast. 
> >> 
> >> > Thanks, 
> >> > Chris 
> >> > 
> >> > On Tuesday, March 3, 2015 at 11:41:53 AM UTC-5, Mauro wrote: 
> >> >> 
> >> >> > I believe if all your type fields are concrete (which they are in 
> the 
> >> >> case 
> >> >> > of Float64), the performance should be the same as using 
> >> >> Vector{Float64}. 
> >> >> > This is really nice since you get to use code that is much more 
> >> >> > understandable like state.x instead of state[1] for no penalty. 
> >> >> 
> >> >> I think to get densely packed array the type needs to be immutable: 
> >> >> 
> >> >> immutable StateVec 
> >> >> x::Float64 
> >> >> y::Float64 
> >> >> z::Float64 
> >> >> end 
> >> >> 
> >> >> Otherwise it will be an array of pointers. 
> >> >> 
> >> 
> >> 
>
>

Re: [julia-users] Re: General question about composite types

[Sean Marshallsay]

If you're type has only concrete field then it will be densely packed 
regardless of wether it's immutable or not.

On Tuesday, 3 March 2015 17:15:20 UTC, Mauro wrote:
>
> > Mauro, I do not quite understand what you're saying about densely packed 
> > arrays, could you explain a bit more? 
>
> Consider: 
>
> julia> immutable A 
>x::Float64 
>y::Float64 
>end 
>
> julia> type B 
>x::Float64 
>y::Float64 
>end 
>
> julia> a = [A(4,5), A(5,6)] 
> 2-element Array{A,1}: 
>  A(4.0,5.0) 
>  A(5.0,6.0) 
>
> julia> b = [B(4,5), B(5,6)] 
> 2-element Array{B,1}: 
>  B(4.0,5.0) 
>  B(5.0,6.0) 
>
> Then in memory `a` is actually identical to: 
>
> [4., 5., 5., 6.] 
>
> (or 
> [4. 5.; 5. 6.]  ) 
>
> As Julia knows that the type of `a` is Vector{A}, it knows how to 
> interpret that junk of memory.  Conversely, `b` is a vector of pointers 
> which point to the two instances of `B`.  So, working with b is slower 
> than an Array{Float64,2} whereas a should be just as fast. 
>
> > Thanks, 
> > Chris 
> > 
> > On Tuesday, March 3, 2015 at 11:41:53 AM UTC-5, Mauro wrote: 
> >> 
> >> > I believe if all your type fields are concrete (which they are in the 
> >> case 
> >> > of Float64), the performance should be the same as using 
> >> Vector{Float64}. 
> >> > This is really nice since you get to use code that is much more 
> >> > understandable like state.x instead of state[1] for no penalty. 
> >> 
> >> I think to get densely packed array the type needs to be immutable: 
> >> 
> >> immutable StateVec 
> >> x::Float64 
> >> y::Float64 
> >> z::Float64 
> >> end 
> >> 
> >> Otherwise it will be an array of pointers. 
> >> 
>
>

[julia-users] Re: linking Julia with C to improve performances

[Sean Marshallsay]

As Milan says, you shouldn't need C unless your program requires something 
like LAPACK or BLAS. Before even thinking about C you should read

http://docs.julialang.org/en/release-0.3/manual/performance-tips/

*very* carefully. If you're still struggling with performance issues feel 
free to ask questions about on here.

On Tuesday, 24 February 2015 09:13:52 UTC, giovan...@gmail.com wrote:
>
> Hello,
>
> I am a beginner to Julia and would like to try out some features. I would 
> like to improve performances of some bottleneck functions by translating 
> them into C.
> A simple example is :
> main.jl
>
> a ::Int64 = 20  
> b ::Int64 = 10
> ccall(:do_sum, Int64, (Int64, Int64), a, b)
>
>
>
> test.c
> #include 
>
> int do_sum (int a,int b)
> {
> int c;
> c = a+b;
> printf("f\n:",c);
> return c;
> }
>
> where should I put the C file ? 
>
> Thanks,
> G.
>
>

Re: [julia-users] Why does my Julia code run so slow?

[Sean Marshallsay]

Kuba, most of the relevant discussion was happening here:

https://github.com/JuliaLang/julia/pull/8699

On Monday, 23 February 2015 07:27:55 UTC, Kuba Roth wrote:
>
> Sorry for a off topic question. 
> @Viral. Is there any discussion going on about new GC you mentioned? Can 
> you point it to me please? I wonder what are the changes? 
> Thnaks. 
>

[julia-users] Re: int({"5","4"}) works float({"5.5","4.4"}) doesn't

[Sean Marshallsay]

map(parsefloat, ["5.5", "4.4"]) is probably the best way unless your array 
is very large. int(), float() and curly brackets will all be depracated in 
v0.4.

On Friday, 20 February 2015 22:51:05 UTC, Stepa Solntsev wrote:
>
> What seems to be the issue here?
>

[julia-users] Re: [ERROR: syntax: invalid assignment location] When trying to overload the `Base.==` method.

[Sean Marshallsay]

I'm not sure whether it's considered a bug or not but it's definitely known 
about. You can do it like this if you want:

julia> Base.(:(==))
== (generic function with 79 methods)



On Thursday, 19 February 2015 15:36:58 UTC, Ismael VC wrote:
>
> Is this a parsing bug? I wanted to use `Base.==` to make it more explicit, 
> as I've seen it's good style. This happens in both v0.3.5 and v0.4-dev
>
> julia> type Foo end
>
> julia> import Base.==
>
> julia> Base.==(x::Foo, y::Foo) = true
> ERROR: syntax: invalid assignment location
>
> julia> Base.(==)(x::Foo, y::Foo) = true
> ERROR: syntax: invalid method name "Base.(==)"
>
> julia> ==(x::Foo, y::Foo) = true
> == (generic function with 80 methods)
>
>
>

[julia-users] Re: Why does my Julia code run so slow?

[Sean Marshallsay]

The two things that jump out at me straight away are keyword arguments and 
nullable fields. Changing those keyword arguments into optional positional 
arguments might give you a bit of a boost.

The thing that will really make a difference though (I expect) is 
`input_gradient::Union(Nothing,Array{Float64})`, that will be a massive 
performance killer and you should probably use an empty array instead (i.e. 
`input_gradient::Array{Float64}=Float64[]`). If that's not possible 
consider splitting the function into two methods, one that has an 
input_gradient argument and one that doesn't, then you can do your nothing 
checking outside the function.

On Thursday, 19 February 2015 14:51:20 UTC, Zhixuan Yang wrote:
>
> Hello everyone, 
>
> Recently I'm working on my first Julia project, a word embedding training 
> program similar to Google's word2vec  
> (the code 
> of word2vec is indeed very high-quality, but I want to add more features, 
> so I decided to write a new one). Thanks to Julia's expressiveness, it cost 
> me less than 2 days to write the entire program. But it runs really slow, 
> about 100x slower than the C code of word2vec (the algorithm is the same). 
>  I've been trying to optimize my code for several days (adding type 
> annotations, using BLAS to do computation, eliminating memory allocations 
> ...), but it is still 30x slower than the C code. 
>
> The critical part of my program is the following function (it also 
> consumes most of the time according to the profiling result):
>
> function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: Int64; 
> α :: Float64 = 0.025, input_gradient :: Union(Nothing, Array{Float64}) = 
> nothing)
> predict!(c, x)
> c.outputs[y] -= 1
>
> if input_gradient != nothing
> # input_gradient = ( c.weights * outputs' )'
> BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
> end
>
> # c.weights -= α * x' * outputs;
> BLAS.ger!(-α, vec(x), c.outputs, c.weights)
> end
>
> function predict!(c :: LinearClassifier, x :: Array{Float64})
> c.outputs = vec(softmax(x * c.weights))
> end
>
> type LinearClassifier
> k :: Int64 # number of outputs
> n :: Int64 # number of inputs
> weights :: Array{Float64, 2} # k * n weight matrix
>
> outputs :: Vector{Float64}
> end
>
> And the entire program can be found here 
> . Could you please check my code 
> and tell me what I can do to get performance comparable to C. 
>
> Regards.
> Yang Zhixuan
>

[julia-users] Re: working with immutable arrays

[Sean Marshallsay]

Also see https://github.com/JuliaLang/julia/issues/5333 
and https://github.com/JuliaLang/julia/pull/6122, which would probably make 
the implementation of that macro easier.

On Wednesday, 18 February 2015 11:57:49 UTC, Ariel Keselman wrote:
>
> I'm working with arrays of immutables each containing several fields. Now 
> creating new immutables based on old ones has become a real pain:
>
> old = myarray[i]
> myarray[i].foo = myimmutable(old.foo, bar, old.x, old.y, etc.)
>
> imagine this for 15 fields...!
>
> So I made a macro to ease this, it can be used like this:
>
> @set myarray i bar=newbar x=newx
>
> and the rest of the parameters remain the same. See code below.
>
> The problem is that although I can autogenerate the macro for different 
> types, I cannot use the same function name @set for all types. Each type 
> has to have its own special macro!
>
> The reason is that this macro requires knowledge of the types it is 
> working on, something missing at macro "runtime". While stagedfunctions do 
> have type information, they miss the array symbol name.
>
> Maybe a "stagedmacro" could help ;)
>
> Do you know how could this be solved? 
>
> Thanks!
>
> immutable IM
> aa::Float64
> bb::Float64
> cc::Float64
> dd::Float64
> ee::Float64
> ff::Float64
> gg::Float64
> hh::Float64
> ii::Float64
> jj::Float64
> kk::Float64
> ll::Float64
> end
>
> macro set(ARR, IX, KV...)
> d = [p.args[1]=>p.args[2] for p in KV]
> aa = get(d,:aa,:($ARR[$IX].aa))
> bb = get(d,:bb,:($ARR[$IX].bb))
> cc = get(d,:cc,:($ARR[$IX].cc))
> dd = get(d,:dd,:($ARR[$IX].dd))
> ee = get(d,:ee,:($ARR[$IX].ee))
> ff = get(d,:ff,:($ARR[$IX].ff))
> gg = get(d,:gg,:($ARR[$IX].gg))
> hh = get(d,:hh,:($ARR[$IX].hh))
> ii = get(d,:ii,:($ARR[$IX].ii))
> jj = get(d,:jj,:($ARR[$IX].jj))
> kk = get(d,:kk,:($ARR[$IX].kk))
> ll = get(d,:ll,:($ARR[$IX].ll))
> quote
> @inbounds $ARR[$IX] =
> IM($aa,$bb,$cc,$dd,$ee,$ff,$gg,$hh,$ii,$jj,$kk,$ll)
> end
> end
>
> this is used as follows:
>
> a = [IM(1,1,1,1,1,1,1,1,1,1,1,1),
>  IM(1,1,1,1,1,1,1,1,1,1,1,1),
>  IM(1,1,1,1,1,1,1,1,1,1,1,1),
>  IM(1,1,1,1,1,1,1,1,1,1,1,1),
>  IM(1,1,1,1,1,1,1,1,1,1,1,1)]
>
> @set a 1 aa=9 ll=9
>
> # a is now:
> # [
>
> # IM(1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0)
> # IM(9.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,9.0)
> # IM(1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0)
> # IM(1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0)
> # IM(1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0)]
>
>
>
>
>
>

[julia-users] Re: Values from Dict assigned to "variables" (symbols?) named as keys?

[Sean Marshallsay]

As Micheal pointed out, think very carefully about why you need this 
behaviour because it will leak variables into the global scope which is 
currently a very bad idea in Julia.

On Sunday, 15 February 2015 22:46:56 UTC, Martin Johansson wrote:
>
> Thanks, the second solution was what I was looking for!
>
> Regards, m
>
> On Sunday, February 15, 2015 at 11:41:02 PM UTC+1, Sean Marshallsay wrote:
>>
>> I'm not too certain what you're asking here.
>>
>> Do you mean something like this:
>>
>> julia> d = Dict()
>> Dict{Any,Any} with 0 entries
>>
>> julia> for i in [:var1, :var2, :var3]
>>d[i] = string(i)
>>end
>>
>> julia> d
>> Dict{Any,Any} with 3 entries:
>>   :var3 => "var3"
>>   :var1 => "var1"
>>   :var2 => "var2"
>>
>> Or something more like this:
>>
>> julia> d = [:a=>1, :b=>2, :c=>3]
>> Dict{Symbol,Int64} with 3 entries:
>>   :b => 2
>>   :c => 3
>>   :a => 1
>>
>> julia> for (k,v) in d
>> @eval $k = $v
>>end
>>
>> julia> a
>> 1
>>
>> julia> b
>> 2
>>
>> julia> c
>> 3
>>
>> Or maybe something else entirely?
>>
>> On Sunday, 15 February 2015 22:17:54 UTC, Martin Johansson wrote:
>>>
>>> Is there a way to "assign" the values of a Dict to the corresponding 
>>> keys such that I get "variables" (symbols?) with names given by the keys? 
>>> Let's assume the keys are for example strings which would work as variables.
>>>
>>> The reason for why I would want to do this is to have functions where 
>>> explicit variables are used rather than Dicts, primarily for readability. 
>>> I'm suspecting that this is not a recommended way of doing things (since I 
>>> couldn't find any info along these lines when searching), and if this is 
>>> the case please set me straight.
>>>
>>> Regards, m
>>>
>>>
>>>

[julia-users] Re: Values from Dict assigned to "variables" (symbols?) named as keys?

[Sean Marshallsay]

I'm not too certain what you're asking here.

Do you mean something like this:

julia> d = Dict()
Dict{Any,Any} with 0 entries

julia> for i in [:var1, :var2, :var3]
   d[i] = string(i)
   end

julia> d
Dict{Any,Any} with 3 entries:
  :var3 => "var3"
  :var1 => "var1"
  :var2 => "var2"

Or something more like this:

julia> d = [:a=>1, :b=>2, :c=>3]
Dict{Symbol,Int64} with 3 entries:
  :b => 2
  :c => 3
  :a => 1

julia> for (k,v) in d
@eval $k = $v
   end

julia> a
1

julia> b
2

julia> c
3

Or maybe something else entirely?

On Sunday, 15 February 2015 22:17:54 UTC, Martin Johansson wrote:
>
> Is there a way to "assign" the values of a Dict to the corresponding keys 
> such that I get "variables" (symbols?) with names given by the keys? Let's 
> assume the keys are for example strings which would work as variables.
>
> The reason for why I would want to do this is to have functions where 
> explicit variables are used rather than Dicts, primarily for readability. 
> I'm suspecting that this is not a recommended way of doing things (since I 
> couldn't find any info along these lines when searching), and if this is 
> the case please set me straight.
>
> Regards, m
>
>
>

Re: [julia-users] string literals split to multilines?

[Sean Marshallsay]

Rene, multiline literals should also work with just a single quote.

julia> d = "aaa 
   bbb
   ccc"
"aaa\nbbb\nccc"



On Tuesday, 6 January 2015 10:19:37 UTC, René Donner wrote:
>
> hi, 
>
> this should work: 
>
> d = """aaa 
> bbb 
> ccc""" 
>
> Rene 
>
>
> Am 06.01.2015 um 11:15 schrieb Andreas Lobinger  >: 
>
> > Hello colleagues, 
> > 
> > is there a counterpart for the string literal split to multiple lines 
> like in python? 
> > 
> > d = '09ab\ 
> > eff1\ 
> > a2a4' 
> > 
> > Wishing a happy day, 
> >Andreas 
> > 
>
>

[julia-users] Re: Suggestion for "tuple types" explanation in manual

[Sean Marshallsay]

I suppose I should add that Julia doesn't really have a named tuple, the 
closest is an immutable constant type which is covered later in the manual.

On Monday, 5 January 2015 10:35:28 UTC, Sean Marshallsay wrote:
>
> Hi Ivo
>
> You're more than welcome to contribute to the documentation yourself 
> <https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md#improving-documentation>
>  to 
> help clarify anything you found confusing.
>
> Regarding your second point, open() does not return a named type it 
> returns a tuple containing some kind of stream and some kind of process, 
> Pipe is some kind of stream and Process is some kind of process. Hopefully 
> the following code snippet will help clear things up.
>
> julia> x = open(`less`)
> (Pipe(closed, 0 bytes waiting),Process(`less`, ProcessExited(0)))
>
> julia> y = typeof(x)
> (Pipe,Process)
>
> julia> typeof(y)
> (DataType,DataType)
>
> help?> issubtype
> INFO: Loading help data...
> Base.issubtype(type1, type2)
>
>True if and only if all values of "type1" are also of "type2".
>Can also be written using the "<:" infix operator as "type1 <:
>type2".
>
> julia> issubtype((Base.Pipe, Base.Process), (Base.AsyncStream, 
> Base.Process))
> true
>
> help?> super
> Base.super(T::DataType)
>
>Return the supertype of DataType T
>
> julia> super(Base.Pipe)
> AsyncStream
>
> julia> super(Base.Process)
> Any
>
> So what we can see is that open() does return a (stream, process) tuple 
> but stream should actually be called AsyncStream and process should 
> actually be called Process.
>
> Hope this helps
> Sean
>
> On Monday, 5 January 2015 06:59:31 UTC, ivo welch wrote:
>>
>>
>> I am reading again about the type system, esp in 
>> http://julia.readthedocs.org/en/latest/manual/types/ .  I am a good 
>> guinea pig for a manual, because I don't know too much.
>>
>> a tuple is like function arguments without the functions.  so,
>>
>> mytuple=(1,"ab",(3,4),"5")
>>
>> is a tuple.  good.
>>
>> what can I do with a typle?  the manual tells me right upfront that I can 
>> do a typeof(mytuple) function call to see its types.  good.
>>
>> alas, then it goes into intricacies of how types "sort-of" inherit.  I 
>> need a few more basics first.
>>
>> I would suggest adding to the docs right after the typeof function that, 
>> e.g., mytuple[2] shows the contents of the second parameter.  the julia cli 
>> prints the contents.  the examples would be a little clearer, perhaps, if 
>> one used a nested tuple, like (1,2,("foo",3),"bar").
>>
>> before getting into type relations, I would also add how one creates a 
>> named tuple.  since open() does exactly this.  well, maybe I am wrong. 
>>  the docs say it returns a (stream,process), but typeof( open(`gzcat 
>> d.csv.gz`) tells me I have a (Pipe,Process).
>>
>> I know how to extract the n-th component of the open() returned tuple 
>> (with the [] index operator), but I don't know how to get its name.  x.Pipe 
>> does not work for open().
>>
>> well, my point is that it would be useful to add a few more examples and 
>> explanations here.
>>
>> regards,
>>
>> /iaw
>>
>>

[julia-users] Re: Suggestion for "tuple types" explanation in manual

[Sean Marshallsay]

Hi Ivo

You're more than welcome to contribute to the documentation yourself 

 to 
help clarify anything you found confusing.

Regarding your second point, open() does not return a named type it returns 
a tuple containing some kind of stream and some kind of process, Pipe is 
some kind of stream and Process is some kind of process. Hopefully the 
following code snippet will help clear things up.

julia> x = open(`less`)
(Pipe(closed, 0 bytes waiting),Process(`less`, ProcessExited(0)))

julia> y = typeof(x)
(Pipe,Process)

julia> typeof(y)
(DataType,DataType)

help?> issubtype
INFO: Loading help data...
Base.issubtype(type1, type2)

   True if and only if all values of "type1" are also of "type2".
   Can also be written using the "<:" infix operator as "type1 <:
   type2".

julia> issubtype((Base.Pipe, Base.Process), (Base.AsyncStream, 
Base.Process))
true

help?> super
Base.super(T::DataType)

   Return the supertype of DataType T

julia> super(Base.Pipe)
AsyncStream

julia> super(Base.Process)
Any

So what we can see is that open() does return a (stream, process) tuple but 
stream should actually be called AsyncStream and process should actually be 
called Process.

Hope this helps
Sean

On Monday, 5 January 2015 06:59:31 UTC, ivo welch wrote:
>
>
> I am reading again about the type system, esp in 
> http://julia.readthedocs.org/en/latest/manual/types/ .  I am a good 
> guinea pig for a manual, because I don't know too much.
>
> a tuple is like function arguments without the functions.  so,
>
> mytuple=(1,"ab",(3,4),"5")
>
> is a tuple.  good.
>
> what can I do with a typle?  the manual tells me right upfront that I can 
> do a typeof(mytuple) function call to see its types.  good.
>
> alas, then it goes into intricacies of how types "sort-of" inherit.  I 
> need a few more basics first.
>
> I would suggest adding to the docs right after the typeof function that, 
> e.g., mytuple[2] shows the contents of the second parameter.  the julia cli 
> prints the contents.  the examples would be a little clearer, perhaps, if 
> one used a nested tuple, like (1,2,("foo",3),"bar").
>
> before getting into type relations, I would also add how one creates a 
> named tuple.  since open() does exactly this.  well, maybe I am wrong. 
>  the docs say it returns a (stream,process), but typeof( open(`gzcat 
> d.csv.gz`) tells me I have a (Pipe,Process).
>
> I know how to extract the n-th component of the open() returned tuple 
> (with the [] index operator), but I don't know how to get its name.  x.Pipe 
> does not work for open().
>
> well, my point is that it would be useful to add a few more examples and 
> explanations here.
>
> regards,
>
> /iaw
>
>

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

[Sean Marshallsay]

Ismael,

I think you're over-compliacating Julia's workflow slightly, in that first 
image you posted (
http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows 
)
 
just replace the word "master" with "stable/release" and the word "develop" 
with "master" and that's pretty much it.

On Thursday, 1 January 2015 09:14:29 UTC, Ismael VC wrote:
>
> Tobias: I don't think that Julia is more frequently broken, but Dann 
> experienced this (his blog post started this discussion), I have also 
> experienced it several times (but I'm an inexpert noob) and of course I'm 
> sure other have also experienced this.
>
> I just wanted to know the advantages of Julia's approach compared to 
> following things by the "book".
>
> I know the correct thing it to check if there is an open issue or else 
> open an issue (I've spent last year studying git and a lot of stuff), and 
> all I know comes from whatever I have available to study from, like the git 
> book, and since I clearly don't understand, I just want to understand the 
> issue.
>
> Keno: I certainly want to provide feedback and learn, you'll be having me 
> around a lot starting from this year. :D
>
> Obviously I didn't follow the 0.3 dev cycle, but now I have configured 
> gmail, to recieve absolutely every notification from the Julia project.
>
> As a mater of fact I'll start building Julia from master again tonight and 
> report any issues I might encounter, something I stopped doing because of 
> my lack of knowledge and the availability of binaries.
>
> Thanks you both for taking the time to answer my concerns.
>
> On Thu, Jan 1, 2015 at 2:45 AM, Tobias Knopp  > wrote:
>
>> Hi Ismael,
>>
>> why do you think that master is more frequently broken in Julia than in 
>> other projects?
>> This really does not happen often. People develop in branches and after 
>> serious review they are merged to master.
>>
>> This discussion further is to isolated and does not take into account 
>> that Julia is a programming language and that it is very important to 
>> testbed language changes during a development period.
>>
>> The discussion is, by the way, very funny because we had during the 0.3 
>> dev period effectively a "rolling release", i.e. development snapshots were 
>> regularly made and these were kept stable.
>>
>> Cheers,
>>
>> Tobi
>>
>>
>>
>> Am Donnerstag, 1. Januar 2015 09:12:59 UTC+1 schrieb Ismael VC:
>>>
>>> Perhaps we could add a diagram of the Julia work flow because I think we 
>>> are using neither one of those models, we don't have lieutenants, nor a 
>>> dictator do we?
>>>  
>>>
>>> ​I'm sorry for the ugly diagram, I just want to really understand the 
>>> current work flow, so correct me if I'm wrong.
>>>
>>> I don't know about Linux, but I wonder how frequently do they happen to 
>>> have a broken master? I this also common situation among distributed open 
>>> source projects? (I'm going to study Rust's approach too.) 
>>>
>>> I just thought that the master had to be as stable as possible 
>>> (reference) and by using the dictator/lieutenant/public_dev approach I 
>>> assume one gets way more testing but also that one needs way more 
>>> resources. 
>>>
>>> After all Linus has to really trust his lieutenants, as the key in this 
>>> model is delegation and trust.
>>>
>>> Since Julia uses neither (a mix?), whats the advantage of the current 
>>> approach?
>>>
>>>
>>> On Thu, Jan 1, 2015 at 1:27 AM, Viral Shah  wrote:
>>>
 While the basic assert based tests are good enough for me, I do wish 
 that the test framework could be more flexible. Some of this is historic - 
 we started out not wanting a separate set of unit vs. comprehensive test 
 suites. The goal with the unit tests was to have something that could be 
 easily tested rapidly during development and catch regressions in the 
 basic 
 system. This evolved into something more than what it was intended to do. 
 We even added some very basic perf tests to this framework.

 I find myself wanting a few more things from it as I have worked on the 
 ARM port on and off. Some thoughts follow.

 I'd love to be able to run the entire test suite, knowing how many 
 tests there are in all, how many pass and how many fail. Over time, it is 
 nice to know how the total number of tests has increased along with the 
 code in base. Currently, on ARM, tons of stuff fails and I run all the 
 tests by looping over all the test files, and they all give up after the 
 first failure.

 If I had, say, the serial number of the failing cases, I can keep 
 repeatedly testing just those as I try to fix a particular issue. 
 Currently, the level of granularity is a whole test file.

 Documentation of the test framework in the manual has been on my mind. 
 We 

Re: [julia-users] Spawning (or running) an external program with given environment variables.

[Sean Marshallsay]

Thanks Stefan but I ideally wanted something that would leave ENV intact 
(which setenv does). On an unrelated note, how on earth do you find the 
time to answer all these questions so quickly? However you do it, thanks 
for being so dedicated.

On Wednesday, 31 December 2014 20:55:51 UTC, Stefan Karpinski wrote:
>
> Also:
>
> julia> ENV["FOO"] = "BAR"
> "BAR"
>
> julia> run(`env` |> `grep FOO`)
> FOO=BAR
>
>
> On Wed, Dec 31, 2014 at 3:35 PM, Sean Marshallsay  > wrote:
>
>> Awesome, thank you!
>>
>> On Wednesday, 31 December 2014 19:27:26 UTC, Isaiah wrote:
>>>
>>> julia> c = setenv(`env`, ["FOO=>bar"])
>>> setenv(`env`,Union(ASCIIString,UTF8String)["FOO=>bar"])
>>>
>>> julia> run(c)
>>> FOO=>bar
>>>
>>> On Wed, Dec 31, 2014 at 2:16 PM, Sean Marshallsay  
>>> wrote:
>>>
>>>> In Bash I can do something like this
>>>>
>>>> $ echo $RANDOM_VAR
>>>>
>>>> $ RANDOM_VAR='heya' env
>>>> RANDOM_VAR='heya'
>>>> OTHER_ENV_VAR=whatever_it_was_before
>>>> ...
>>>> $ echo $RANDOM_VAR
>>>>
>>>> $
>>>>
>>>> In Julia, however,
>>>>
>>>> julia> run(`env`)
>>>> OTHER_ENV_VAR=whatever_it_was_before
>>>> ...
>>>>
>>>> julia> run(`RANDOM_VAR='heya' env`)
>>>> ERROR: could not spawn `RANDOM_VAR=heya env`: no such file or directory 
>>>> (ENOENT)
>>>>  in _jl_spawn at process.jl:217
>>>>  in spawn at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib 
>>>> (repeats 2 times)
>>>>  in run at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib
>>>>
>>>> julia>
>>>>
>>>> Is there a way to emulate this behaviour in Julia?
>>>>
>>>
>>>
>

Re: [julia-users] Spawning (or running) an external program with given environment variables.

[Sean Marshallsay]

Awesome, thank you!

On Wednesday, 31 December 2014 19:27:26 UTC, Isaiah wrote:
>
> julia> c = setenv(`env`, ["FOO=>bar"])
> setenv(`env`,Union(ASCIIString,UTF8String)["FOO=>bar"])
>
> julia> run(c)
> FOO=>bar
>
> On Wed, Dec 31, 2014 at 2:16 PM, Sean Marshallsay  > wrote:
>
>> In Bash I can do something like this
>>
>> $ echo $RANDOM_VAR
>>
>> $ RANDOM_VAR='heya' env
>> RANDOM_VAR='heya'
>> OTHER_ENV_VAR=whatever_it_was_before
>> ...
>> $ echo $RANDOM_VAR
>>
>> $
>>
>> In Julia, however,
>>
>> julia> run(`env`)
>> OTHER_ENV_VAR=whatever_it_was_before
>> ...
>>
>> julia> run(`RANDOM_VAR='heya' env`)
>> ERROR: could not spawn `RANDOM_VAR=heya env`: no such file or directory 
>> (ENOENT)
>>  in _jl_spawn at process.jl:217
>>  in spawn at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib (repeats 2 
>> times)
>>  in run at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib
>>
>> julia>
>>
>> Is there a way to emulate this behaviour in Julia?
>>
>
>

[julia-users] Spawning (or running) an external program with given environment variables.

[Sean Marshallsay]

In Bash I can do something like this

$ echo $RANDOM_VAR

$ RANDOM_VAR='heya' env
RANDOM_VAR='heya'
OTHER_ENV_VAR=whatever_it_was_before
...
$ echo $RANDOM_VAR

$

In Julia, however,

julia> run(`env`)
OTHER_ENV_VAR=whatever_it_was_before
...

julia> run(`RANDOM_VAR='heya' env`)
ERROR: could not spawn `RANDOM_VAR=heya env`: no such file or directory 
(ENOENT)
 in _jl_spawn at process.jl:217
 in spawn at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib (repeats 2 
times)
 in run at /usr/local/Cellar/julia/0.3.3/lib/julia/sys.dylib

julia>

Is there a way to emulate this behaviour in Julia?

[julia-users] Re: Using Julia with other (GC) languages

[Sean Marshallsay]

You can interact with GCed languages by writing "C like" Julia, i.e. 
working with c_malloc and c_free directly. It's not exactly the nicest way 
of working but doing that will avoid the garbage collector.

On Friday, 26 December 2014 22:54:28 UTC, Páll Haraldsson wrote:
>
> I know you can call C from Julia and therefore most other (non-GC) 
> languages. And with embedding, vice versa.
>
> Of course you always can call other languages, say with RPC etc. but 
> wander what the limitations are to call directly.
>
> It seems to me you can call C because it is not a garbage-controlled 
> language. And when embedding Julia in C then you get the whole runtime and 
> it is similar to embedding Prolog in C. I've just not looked to much into 
> embedding. Would you say calling in that direction is more difficult 
> because of it or some other reason?
>
> It seems to me you would want Julia to be the "master language" on top 
> because it has GC (and is the more "powerful language").
>
> In theory, calling other GC languages such as Java or C# should be 
> possible but not in practice (without copying/RPC) because you can have 
> only on GC, right? Still calling Python is possible, because it uses 
> reference counting, not true GC? But it also has GC for cycles. So maybe 
> there is no difficulty with GC or is that part just disabled?
>
>
> And:
> I know about the current situation with calling C++. For old Python code 
> (even on Windows) and numpy (or whatever) that calls C++ (Microsoft's 
> Visual Studio), since Julia can call Python, should there really be any 
> reason for it be difficult to call C++ if it is only indirectly?
>
> Best regards,
> Palli.
>
>

[julia-users] Re: [ANN] SQLite.jl package update

[Sean Marshallsay]

>
> Do you think it would make sense to extract some common functionality and 
> function names in a DB package?
>

There was some discussion about that here 
<https://github.com/JuliaDB/DBDSQLite.jl/issues/1> but the problem is 
SQLite.jl is currently slightly too SQLite-specific for this to be an easy 
task and I don't think any of us really have the impetus to do it. No harm 
opening an issue though if it's something you're interested in. Heck you 
could even give it a go yourself if you want.

Great work!


Thanks! 

On Monday, 29 December 2014 16:39:01 UTC, Valentin Churavy wrote:
>
> Great work! 
>
> Do you think it would make sense to extract some common functionality and 
> function names in a DB package? There is https://github.com/JuliaDB/DBI.jl
> . 
> I like the interface you provided and would like to use parts of it for 
> the Postgres driver I am working on.
>
> - Valentin
>
>
> On Monday, 29 December 2014 07:57:20 UTC+1, Jacob Quinn wrote:
>>
>> Hey all,
>>
>> We've been working on a fairly major upgrade of the SQLite.jl package 
>> over the last few months and are happy to announce a new release. This is a 
>> breaking change with the most recent tagged version in METADATA, so if you 
>> wish to stay on the old API version, just run `Pkg.pin("SQLite")`. 
>> Otherwise, to see the updates, you can simply run `Pkg.update()` if the 
>> `SQLite.jl` package is already installed, or run `Pkg.add("SQLite")` to 
>> install the package for the first time.
>>
>> The newer package boasts some great updates including a more Julian 
>> interface (the older package was modeled after the sqldf R package), the 
>> removal of DataFrames dependency making the package much more lightweight, 
>> but still easy to feed the new `SQLite.ResultSet` type into a DataFrame; 
>> there are also some awesome features allowing the use of custom julia 
>> scalar and aggregate functions in SQL statements by registering the julia 
>> function. Usage of custom Julia types is also supported for storing and 
>> loading in SQL tables (using the serialization interface). 
>>
>> We've tried to put in many more tests and push the docs further along, 
>> but are of course always looking to improve.
>>
>> For those unfamiliar, SQLite is a lightweight, relational database system 
>> easy to run on a local machine. It's extremely handy for working with 
>> medium to large datasets that still fit on a single machine (MBs to GBs). 
>> It supports SQL statements to create, update, and delete relational tables, 
>> as well as select statements to perform calculations, or subset specific 
>> datasets. 
>>
>> -Jacob Quinn and Sean Marshallsay
>>
>

Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.

[Sean Marshallsay]

Just my two cents here Jim but I've been using v0.4 (usually updated daily) 
extensively since the summer and have only run into one segfault (which sat 
very firmly in "I'm doing something stupidly unsafe here" territory).

I would argue that if you run into a segfault Julia is definitely not 
behaving and you should file an issue.

On Tuesday, 30 December 2014 22:02:00 UTC, Jim Garrison wrote:
>
> On Monday, December 29, 2014 9:27:41 PM UTC-5, Stefan Karpinski wrote:
>>
>> On Mon, Dec 29, 2014 at 9:07 PM,  wrote:
>>
>>>
>>> I would really like if I could throw and catch an exception without 
>>> needing to consider that my program might panic as a result of doing so.  I 
>>> just looked through the entire corpus of Julia code I have written so far, 
>>> and the only places I catch exceptions are when the exception is actually 
>>> due to calling a Python API via PyCall.  I am willing to accept that using 
>>> exceptions is not a very Julian way of doing things, but I still want them 
>>> to work when they are needed.
>>>
>>
>> "Panic" is the Go term for "throw". Your Julia program will not panic if 
>> you throw an exception – throw/catch works just fine.
>>
>
> Stefan, I misunderstood so thank you for the clarification.
>
> Part of the reason I was inclined to think that exceptions are unsupported 
> is that I often see my code segfault if I create an exception e.g. by 
> pressing Ctrl+C.  For instance, if I open the REPL, and type
>
> julia> x = rand(4000,4000)
> julia> x * x
>
> and press Ctrl+C during execution, I nearly always get a segfault.  In 
> Python I almost never see a segfault as an exception unwinds (and when I 
> do, I file a bug).  But in Julia it seems to be the norm for me.
>
> Somewhat related, I also experience intermittent segfaults on exit on a 
> cluster I use at UCSB unless I set OPENBLAS_NUM_THREADS=1.  (I'd like to 
> get a stack trace on this and file a real bug, but I've been unable so far 
> to find where the core dumps disappear to even with sysadmin help, and the 
> problem goes away when I run julia under gdb).
>
> And when I run the release-0.3 branch under valgrind (even something as 
> simple as the empty script `julia -e ""`), the results can be somewhat 
> scary (at least that is my interpretation).
>
> Together these things imply to me that not enough effort/testing is being 
> put into ensuring that resources are cleaned up correctly as julia 
> terminates, but I'm curious if others have different takes on this.
>
> I've been using Julia since September and overall I feel like I am hitting 
> real bugs at a much higher rate than a few per year (and can in that sense 
> relate to Dan's post).  But for me Julia has made me so much more 
> productive that even dealing with these issues is more fun (and productive) 
> than my former days of using C++.  As such, I'd really like to do what I 
> can to ensure overall trend is heading in the direction of increased 
> stability over time.  I have a few ideas for things to do, but am curious 
> to know first what people think of my above assessment.
>

Re: [julia-users] Re: How fast reduce the Vector range of values? (Recode for smaler numbers)

[Sean Marshallsay]

Vector{T} is just a typealias for Array{T, 1} so it's still an array but 
limited to one dimension. Your problem can be solved with

convert(Array{Int, 2}, Jcodes)

or equivalently

convert(Matrix{Int}, Jcodes)


On Wednesday, 10 December 2014 11:09:55 UTC, paul analyst wrote:
>
>  And how to do it if the "J" is an array rather than a vector? So that was 
> also Jcodes array of the same size as J?
> julia> J
> 1557211x2 Array{Int64,2}:
>   930070   930070
>  1475172  1475172
> ....
>  21474836496  21474836496
>   4296445417   4296445417
>
> Paul
>
> W dniu 2014-12-04 o 19:03, Steven G. Johnson pisze:
>  
>  It sounds like you have an array J and you want to map each element of J 
> to a unique integer in 1:N for N as small as possible?  This will do it:
>
>   d = (Int=>eltype(J))[j => i for (i,j) in enumerate(unique(J))]
>  
> Jcodes = [d[j] for j in J]
>  
>   Here, d is a dictionary mapping integers in 1:N to the corresponding 
> values in J, and Jcodes is the "re-coded" array.
>  
>
>  

[julia-users] Re: serialize a dictionary gives an error

[Sean Marshallsay]

>
> Yes it works when I remove the 0.4 syntax:) 
>

Sorry it's just too natural for me nowadays :P
 
On Wednesday, 10 December 2014 16:23:02 UTC, Daniel Høegh wrote:
>
> Yes it works when I remove the 0.4 syntax:) 
> But when you put using PyPlot in the top it does not work:( It's the 
> "convertalypse." at https://github.com/JuliaLang/julia/issues/8631

[julia-users] Re: serialize a dictionary gives an error

[Sean Marshallsay]

Sorry, it's just too natural nowadays :P

On Wednesday, 10 December 2014 16:23:02 UTC, Daniel Høegh wrote:
>
> Yes it works when I remove the 0.4 syntax:) 
> But when you put using PyPlot in the top it does not work:( It's the 
> "convertalypse." at https://github.com/JuliaLang/julia/issues/8631

[julia-users] Re: serialize a dictionary gives an error

[Sean Marshallsay]

H seems to work fine for me. Does the program in this gist 
 work for you?

On Wednesday, 10 December 2014 13:30:38 UTC, Daniel Høegh wrote:
>
> I have a dictionary that like: 
> Dict{ASCIIString,Array{Array{Float64,2},1}} with 83 entries: 
> It is generated by reading 350 mb of dlm files. I would like to save so it 
> is faster reloadable, currently it takes 60s to load from the dlm files. I 
> have tried to serialize to save the data. 
>
> open("test.bin","w") do file 
> serialize(file,data_bolt) 
> end 
> data_new = deserialize(open("test.bin")) 
>
> `convert` has no method matching convert(::Type{Int64...}, ::Int64) 
> while loading In[22], in expression starting on line 2 
>
>  in convert at base.jl:13 
>  in convert at base.jl:21 
>  in deserialize at serialize.jl:447 
> But when I try to deserialize I get an error. Do I do something wrong? 
> I have tried both MAT and HDF5 and they do not seem to have a convenient 
> way of saving my data structure. I hope some of you guys can help, thanks 
> in advance. 
>
> Best regards Daniel Høegh 
>

Re: [julia-users] Behaviour of expanduser is inconsistent between platforms.

[Sean Marshallsay]

>
> I would argue that homedir should handle a user argument and provide all 
> of this functionality. Thus, expanduser should just deal with parsing the 
> path and calling homedir and homedir should do all the heavy lifting.
>

Was my thinking exactly. I've made a start at this, I'll create a WIP 
tomorrow when I've made a couple of other changes.
 
On Sunday, 12 October 2014 01:59:08 UTC+1, Stefan Karpinski wrote:
>
> I would argue that homedir should handle a user argument and provide all 
> of this functionality. Thus, expanduser should just deal with parsing the 
> path and calling homedir and homedir should do all the heavy lifting. I'm 
> not sure if homedir should take a positional or keyword argument – it would 
> often be convenient to have something like `homedir(user="name", "Library", 
> "path", "file")` to avoid the additional call to joinpath.
>
> On Oct 11, 2014, at 5:58 PM, Jameson Nash > 
> wrote:
>
> For the current user (for any platform), `~` should expand to 
> `Base.homedir()`
>
> to find the value for another user on windows (for users that are logged 
> in?) it is apparently best to do an ldap query: 
> http://www.geekshangout.com/node/27
>
> On Sat, Oct 11, 2014 at 4:59 PM, Sean Marshallsay  > wrote:
>
>> The variable is %HOMEPATH% but I don't know what the equivalent to the 
>> password database is. I think for now it might be best just expanding to 
>> %HOMEPATH% and someone who is more experienced with Windows can weigh in 
>> later.
>>
>> On Saturday, 11 October 2014 18:54:03 UTC+1, Stefan Karpinski wrote:
>>>
>>> That seems like a reasonable strategy. I guess the question for Windows 
>>> is what the equivalents to the HOME environment variable and the password 
>>> database are.
>>>
>>> On Sat, Oct 11, 2014 at 5:54 AM, Sean Marshallsay  
>>> wrote:
>>>
>>>> I've only had a quick look but basically for just a tilde it looks for 
>>>> $HOME, if there is no $HOME or there was a username appended it looks in 
>>>> the password database otherwise it returns the string unchanged.
>>>>
>>>> On Friday, 10 October 2014 20:23:45 UTC+1, Stefan Karpinski wrote:
>>>>>
>>>>> How does bash handle it?
>>>>>
>>>>> On Fri, Oct 10, 2014 at 3:22 PM, Sean Marshallsay  
>>>>> wrote:
>>>>>
>>>>>> Hmmm... looking at how bash handles this it doesn't seem too 
>>>>>> difficult, I might give it a go over the weekend. I have no idea how to 
>>>>>> handle it on Windows though.
>>>>>>
>>>>>> On Thursday, 9 October 2014 18:06:07 UTC+1, Stefan Karpinski wrote:
>>>>>>>
>>>>>>> This is definitely a bug. The implementation on both platforms seems 
>>>>>>> to be a hack – a more correct implementation would be a great 
>>>>>>> contribution. 
>>>>>>> It should also be possible to map arbitrary user names to user IDs and 
>>>>>>> user 
>>>>>>> IDs to user metadata.
>>>>>>>
>>>>>>> On Thu, Oct 9, 2014 at 1:00 PM, Sean Marshallsay  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I noticed the other day that calling expanduser on an empty string 
>>>>>>>> throws a BoundsError when using a UNIX platform. Whether this is a bug 
>>>>>>>> or a 
>>>>>>>> feature will probably depend entirely on who you ask. More 
>>>>>>>> importantly though, in my eyes, doing the same thing on Windows 
>>>>>>>> returns an 
>>>>>>>> empty string instead. This inconsistency definitely seems like a bug 
>>>>>>>> to me.
>>>>>>>>
>>>>>>>> In my eyes the UNIX implementation should be changed to check for a 
>>>>>>>> empty string and return it but I was wondering what other people 
>>>>>>>> thought of 
>>>>>>>> this?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

Re: [julia-users] Behaviour of expanduser is inconsistent between platforms.

[Sean Marshallsay]

The variable is %HOMEPATH% but I don't know what the equivalent to the 
password database is. I think for now it might be best just expanding to 
%HOMEPATH% and someone who is more experienced with Windows can weigh in 
later.

On Saturday, 11 October 2014 18:54:03 UTC+1, Stefan Karpinski wrote:
>
> That seems like a reasonable strategy. I guess the question for Windows is 
> what the equivalents to the HOME environment variable and the password 
> database are.
>
> On Sat, Oct 11, 2014 at 5:54 AM, Sean Marshallsay  > wrote:
>
>> I've only had a quick look but basically for just a tilde it looks for 
>> $HOME, if there is no $HOME or there was a username appended it looks in 
>> the password database otherwise it returns the string unchanged.
>>
>> On Friday, 10 October 2014 20:23:45 UTC+1, Stefan Karpinski wrote:
>>>
>>> How does bash handle it?
>>>
>>> On Fri, Oct 10, 2014 at 3:22 PM, Sean Marshallsay  
>>> wrote:
>>>
>>>> Hmmm... looking at how bash handles this it doesn't seem too difficult, 
>>>> I might give it a go over the weekend. I have no idea how to handle it on 
>>>> Windows though.
>>>>
>>>> On Thursday, 9 October 2014 18:06:07 UTC+1, Stefan Karpinski wrote:
>>>>>
>>>>> This is definitely a bug. The implementation on both platforms seems 
>>>>> to be a hack – a more correct implementation would be a great 
>>>>> contribution. 
>>>>> It should also be possible to map arbitrary user names to user IDs and 
>>>>> user 
>>>>> IDs to user metadata.
>>>>>
>>>>> On Thu, Oct 9, 2014 at 1:00 PM, Sean Marshallsay  
>>>>> wrote:
>>>>>
>>>>>> I noticed the other day that calling expanduser on an empty string 
>>>>>> throws a BoundsError when using a UNIX platform. Whether this is a bug 
>>>>>> or a 
>>>>>> feature will probably depend entirely on who you ask. More 
>>>>>> importantly though, in my eyes, doing the same thing on Windows returns 
>>>>>> an 
>>>>>> empty string instead. This inconsistency definitely seems like a bug to 
>>>>>> me.
>>>>>>
>>>>>> In my eyes the UNIX implementation should be changed to check for a 
>>>>>> empty string and return it but I was wondering what other people thought 
>>>>>> of 
>>>>>> this?
>>>>>>
>>>>>
>>>>>
>>>
>

Re: [julia-users] Behaviour of expanduser is inconsistent between platforms.

[Sean Marshallsay]

I've only had a quick look but basically for just a tilde it looks for 
$HOME, if there is no $HOME or there was a username appended it looks in 
the password database otherwise it returns the string unchanged.

On Friday, 10 October 2014 20:23:45 UTC+1, Stefan Karpinski wrote:
>
> How does bash handle it?
>
> On Fri, Oct 10, 2014 at 3:22 PM, Sean Marshallsay  > wrote:
>
>> Hmmm... looking at how bash handles this it doesn't seem too difficult, I 
>> might give it a go over the weekend. I have no idea how to handle it on 
>> Windows though.
>>
>> On Thursday, 9 October 2014 18:06:07 UTC+1, Stefan Karpinski wrote:
>>>
>>> This is definitely a bug. The implementation on both platforms seems to 
>>> be a hack – a more correct implementation would be a great contribution. It 
>>> should also be possible to map arbitrary user names to user IDs and user 
>>> IDs to user metadata.
>>>
>>> On Thu, Oct 9, 2014 at 1:00 PM, Sean Marshallsay  
>>> wrote:
>>>
>>>> I noticed the other day that calling expanduser on an empty string 
>>>> throws a BoundsError when using a UNIX platform. Whether this is a bug or 
>>>> a 
>>>> feature will probably depend entirely on who you ask. More importantly 
>>>> though, in my eyes, doing the same thing on Windows returns an empty 
>>>> string 
>>>> instead. This inconsistency definitely seems like a bug to me.
>>>>
>>>> In my eyes the UNIX implementation should be changed to check for a 
>>>> empty string and return it but I was wondering what other people thought 
>>>> of 
>>>> this?
>>>>
>>>
>>>
>

Re: [julia-users] Behaviour of expanduser is inconsistent between platforms.

[Sean Marshallsay]

Hmmm... looking at how bash handles this it doesn't seem too difficult, I 
might give it a go over the weekend. I have no idea how to handle it on 
Windows though.

On Thursday, 9 October 2014 18:06:07 UTC+1, Stefan Karpinski wrote:
>
> This is definitely a bug. The implementation on both platforms seems to be 
> a hack – a more correct implementation would be a great contribution. It 
> should also be possible to map arbitrary user names to user IDs and user 
> IDs to user metadata.
>
> On Thu, Oct 9, 2014 at 1:00 PM, Sean Marshallsay  > wrote:
>
>> I noticed the other day that calling expanduser on an empty string throws 
>> a BoundsError when using a UNIX platform. Whether this is a bug or a 
>> feature will probably depend entirely on who you ask. More importantly 
>> though, in my eyes, doing the same thing on Windows returns an empty string 
>> instead. This inconsistency definitely seems like a bug to me.
>>
>> In my eyes the UNIX implementation should be changed to check for a empty 
>> string and return it but I was wondering what other people thought of this?
>>
>
>

[julia-users] Behaviour of expanduser is inconsistent between platforms.

[Sean Marshallsay]

I noticed the other day that calling expanduser on an empty string throws a 
BoundsError when using a UNIX platform. Whether this is a bug or a feature 
will probably depend entirely on who you ask. More importantly though, in 
my eyes, doing the same thing on Windows returns an empty string instead. 
This inconsistency definitely seems like a bug to me.

In my eyes the UNIX implementation should be changed to check for a empty 
string and return it but I was wondering what other people thought of this?