Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Stefan Karpinski]

This is a real issue but I don't think that aping the syntax of a very
different paradigm is the right solution.

On Wednesday, October 7, 2015,  wrote:

> I think the auto-completion is a bit of an issue, it makes Julia functions
> not easily discoverable. In other language when you have a string you can
> just type dot and tab and see all the methods that you can apply to your
> string, so you almost never need to go to the doc.
>
> Something similar should be possible to implement in Julia with
> methodswith but I'm not sure any IDE support that yet. methodswith might
> also be too slow for that purpose.
>

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Simon Danisch]

Well that's how assignment usually works.
The *[:]* is something else and is redirecting you to setindex!.
*x[:] = 42* is the same as *setindex(a, 42, :)*, which is the same as 
*setindex(a, 
42, 1:length(a))*

So it's assigning to the indexes of that vector, which means it's reusing 
it.
Maybe have a look at array_indexing 
 ?

Am Mittwoch, 7. Oktober 2015 22:25:00 UTC+2 schrieb Patrick Kofod Mogensen:
>
> So I asked a question over at 
> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
> and it seems that I have got something completely wrong.
>
> It seems that the following
>
> index = rand(8000)
> phat = zeros(8000)
>
> phat = 1./(1+exp(-index))
>
> binds the output of the calculation on the rhs to a _new_ vector phat, not 
> the original vector. This really means I have misunderstood 
> preallocation/re-using memory in Julia completely! @blakejohnson suggests 
> that I use
>
> phat[:] = 1./1+(exp(-index))
>
> instead. As this puts the calculations in the already preallocated vector 
> phat. 
>
> Question 1) Can I learn more about this in the documentation ? I'm having 
> a hard time finding anything, probably because [:] is hard to use as a 
> search phrase, and I'm not sure what concepts to search for.
>
>
>
> I often wrap my variables in a type, but this seems like an extremely bad 
> idea in combination with devec. I have taken Blake Johnsons examples from 
> github, and added a few 
> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>
> Question 2) What is it that makes test4() and test6() run so slowly?  
> test1() and test3() seems to perform equivalently fast. I use this kind of 
> setup all the time, and I am surprised that this method allocates so much 
> memory.
>
> Bad news: I've been doing Julia ALL wrong!
> Good news: Time to learn some more!
>

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Patrick Kofod Mogensen]

Oh, let me answer my own question 2. I did not realize I had not given 
types to phat and vector in type ML. Sanity restored! I still can't find 
the answer to question 1 though.

On Wednesday, October 7, 2015 at 4:25:00 PM UTC-4, Patrick Kofod Mogensen 
wrote:
>
> So I asked a question over at 
> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
> and it seems that I have got something completely wrong.
>
> It seems that the following
>
> index = rand(8000)
> phat = zeros(8000)
>
> phat = 1./(1+exp(-index))
>
> binds the output of the calculation on the rhs to a _new_ vector phat, not 
> the original vector. This really means I have misunderstood 
> preallocation/re-using memory in Julia completely! @blakejohnson suggests 
> that I use
>
> phat[:] = 1./1+(exp(-index))
>
> instead. As this puts the calculations in the already preallocated vector 
> phat. 
>
> Question 1) Can I learn more about this in the documentation ? I'm having 
> a hard time finding anything, probably because [:] is hard to use as a 
> search phrase, and I'm not sure what concepts to search for.
>
>
>
> I often wrap my variables in a type, but this seems like an extremely bad 
> idea in combination with devec. I have taken Blake Johnsons examples from 
> github, and added a few 
> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>
> Question 2) What is it that makes test4() and test6() run so slowly?  
> test1() and test3() seems to perform equivalently fast. I use this kind of 
> setup all the time, and I am surprised that this method allocates so much 
> memory.
>
> Bad news: I've been doing Julia ALL wrong!
> Good news: Time to learn some more!
>

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Hello Stefan,

After thinking your reply and doing more search, I found Julia support 
x.f(y) natively by encapsulating f into the constructor of object x.
So thanks a lot!

Now I have another question:
Since x.f is different for different x, f need to be compiled as many times 
as the number of x ??
Here I suppose f uses x.

On Wednesday, October 7, 2015 at 11:03:13 PM UTC+2, Stefan Karpinski wrote:
>
> In this case, it also obfuscates the meaning of the code. Does x.f(y) mean 
> f(x,y) or is it actually x.f(y)? With this proposal you would need to know 
> something about x in order to decide, currently there's no confusion.
>
> On Wednesday, October 7, 2015, Steven G. Johnson  > wrote:
>
>> On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>>>
>>> I don't see why it is bad to support more styles if there is no harm to 
>>> the original one.
>>>
>>
>> Because code that mixes multiple styles is harder to read (imagine 
>> reading a document that jumps back and forth between different spellings), 
>> harder to share (because other Julia programmers won't know your 
>> idiosyncratic style), and harder to combine with other features of the 
>> language (as others have said, multiple dispatch is central to Julia's 
>> design and central to the design of the standard library).
>>
>> This comes up with every new programming language, which is why it is 
>> useful to learn from history.
>>
>

[julia-users] What does `Base.uncompressed_ast(f.code)` return?

[Andrei Zh]

If `f` is anonymous function:

f = x -> x + 1

what is the format of AST returned by: 

Base.uncompressed_ast(f.code)

? I expected it to be pure AST of a lambda function, but it's quite 
different from quoting lambda directly: 

julia> dump(Base.uncompressed_ast(f.code))
 Expr
   head: Symbol lambda
   args: Array(Any,(3,))
 1: Array(Any,(1,))
   1: Expr
 head: Symbol ::
 args: Array(Any,(2,))
   1: Symbol x
   2: Symbol Any
 typ: Any
 2: Array(Any,(4,))
   1: Array(Any,(1,))
 1: Array(Any,(3,))
   1: Symbol x
   2: Symbol Any
   3: Int64 0
   2: Array(Any,(0,))
   3: Int64 0
   4: Array(Any,(0,))
 3: Expr
   head: Symbol body
   args: Array(Any,(2,))
 1: LineNumberNode
   file: Symbol /home/slipslop/work/jl/Sparta/src/fnserialization.jl
   line: Int64 63
 2: Expr
   head: Symbol return
   args: Array(Any,(1,))
   typ: Any
   typ: Any
   typ: Any

!julia> dump(quote x -> x + 1 end)
 Expr
   head: Symbol block
   args: Array(Any,(2,))
 1: LineNumberNode
   file: Symbol none
   line: Int64 1
 2: Expr
   head: Symbol ->
   args: Array(Any,(2,))
 1: Symbol x
 2: Expr
   head: Symbol block
   args: Array(Any,(2,))
   typ: Any
   typ: Any
   typ: Any

And most important is that it doesn't resulting AST doesn't evaluate back 
to a proper anonymous function: 

 julia> ast = Base.uncompressed_ast(f.code)
 :($(Expr(:lambda, Any[:(x::Any)], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], 
:(begin  # /home/slipslop/work/jl/Sparta/src/fnserialization.jl, line 63:   
 
 return x + 1
 end


 julia> fn = eval(ast)
 (anonymous function)


 julia> fn(1)
 ERROR: wrong number of arguments
  in anonymous at no file

So how do I read the output of `Base.uncompressed_ast` and what is the 
proper way to reconstruct (anonymous) function from AST? 

[julia-users] Re: Ambiguous methods warning method

[cormullion]

Oops, thanks. It's even more "fairly well known" now. :)

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Patrick Kofod Mogensen]

Maybe I'm wrong but I think it's different in Matlab. If a variable exists 
already, it will try to reuse it. I know Julia is not Matlab, and I don't 
want it to be, but all scientific programming experience I have is from 
Matlab, so I just assumed. Which is stupid.

I totally get your explanation, I just hadn't thought about it. I've been 
doing a whle lot of unnecessary assignments instead of setindexing! :)

On Wednesday, October 7, 2015 at 6:16:18 PM UTC-4, Simon Danisch wrote:
>
> Well that's how assignment usually works.
> The *[:]* is something else and is redirecting you to setindex!.
> *x[:] = 42* is the same as *setindex(a, 42, :)*, which is the same as 
> *setindex(a, 
> 42, 1:length(a))*
>
> So it's assigning to the indexes of that vector, which means it's reusing 
> it.
> Maybe have a look at array_indexing 
>  ?
>
> Am Mittwoch, 7. Oktober 2015 22:25:00 UTC+2 schrieb Patrick Kofod Mogensen:
>>
>> So I asked a question over at 
>> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
>> and it seems that I have got something completely wrong.
>>
>> It seems that the following
>>
>> index = rand(8000)
>> phat = zeros(8000)
>>
>> phat = 1./(1+exp(-index))
>>
>> binds the output of the calculation on the rhs to a _new_ vector phat, 
>> not the original vector. This really means I have misunderstood 
>> preallocation/re-using memory in Julia completely! @blakejohnson suggests 
>> that I use
>>
>> phat[:] = 1./1+(exp(-index))
>>
>> instead. As this puts the calculations in the already preallocated vector 
>> phat. 
>>
>> Question 1) Can I learn more about this in the documentation ? I'm having 
>> a hard time finding anything, probably because [:] is hard to use as a 
>> search phrase, and I'm not sure what concepts to search for.
>>
>>
>>
>> I often wrap my variables in a type, but this seems like an extremely bad 
>> idea in combination with devec. I have taken Blake Johnsons examples from 
>> github, and added a few 
>> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>>
>> Question 2) What is it that makes test4() and test6() run so slowly?  
>> test1() and test3() seems to perform equivalently fast. I use this kind of 
>> setup all the time, and I am surprised that this method allocates so much 
>> memory.
>>
>> Bad news: I've been doing Julia ALL wrong!
>> Good news: Time to learn some more!
>>
>

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Hello Steven,

After thinking your reply and doing more search, I found Julia support 
x.f(y) natively by encapsulating f into the constructor of object x.
So thanks a lot!

Now I have another question:
Since x.f is different for different x, f need to be compiled as many times 
as the number of x ??
Here I suppose f uses x.

On Wednesday, October 7, 2015 at 11:03:13 PM UTC+2, Stefan Karpinski wrote:
>
> In this case, it also obfuscates the meaning of the code. Does x.f(y) mean 
> f(x,y) or is it actually x.f(y)? With this proposal you would need to know 
> something about x in order to decide, currently there's no confusion.
>
> On Wednesday, October 7, 2015, Steven G. Johnson  > wrote:
>
>> On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>>>
>>> I don't see why it is bad to support more styles if there is no harm to 
>>> the original one.
>>>
>>
>> Because code that mixes multiple styles is harder to read (imagine 
>> reading a document that jumps back and forth between different spellings), 
>> harder to share (because other Julia programmers won't know your 
>> idiosyncratic style), and harder to combine with other features of the 
>> language (as others have said, multiple dispatch is central to Julia's 
>> design and central to the design of the standard library).
>>
>> This comes up with every new programming language, which is why it is 
>> useful to learn from history.
>>
>

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Kristoffer Carlsson]

Matlab always copy on assignment so Matlab would work the same as Julia. 

[julia-users] a pmap question involving Monte Carlo

[jamesmnason]

Hi All:

Julia is opened for a terminal session using Julia -p 4.

A program test_SI_AR1.jl is run from the julia command line with the return 


exception on exception on exception on 4: exception on 3: 2: 5: ERROR: 
`PF_SI_AR1_inner` has no method matching PF_SI_AR1_inner(::Array{Any,1})
 in anonymous at multi.jl:855
 in run_work_thunk at multi.jl:621
 in anonymous at task.jl:855
ERROR: `PF_SI_AR1_inner` has no method matching 
PF_SI_AR1_inner(::Array{Any,1})
 in anonymous at multi.jl:855
 in run_work_thunk at multi.jl:621
 in anonymous at task.jl:855
ERROR: `PF_SI_AR1_inner` has no method matching 
PF_SI_AR1_inner(::Array{Any,1})
 in anonymous at multi.jl:855
 in run_work_thunk at multi.jl:621
 in anonymous at task.jl:855
ERROR: `PF_SI_AR1_inner` has no method matching 
PF_SI_AR1_inner(::Array{Any,1})
 in anonymous at multi.jl:855
 in run_work_thunk at multi.jl:621
 in anonymous at task.jl:855
ERROR: `exp` has no method matching exp(::Array{MethodError,1})
 in PF_SI_AR1_outer at 
/home/jim_nason/jmn_work/smith/NS4/jl_code_Summer2015/SI_rho/MH_PF_test/PF_outer_example.jl:123
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at loading.jl:152
 in _require at loading.jl:67
 in require at loading.jl:51
while loading 
/home/jim_nason/jmn_work/smith/NS4/jl_code_Summer2015/SI_rho/MH_PF_test/test_SI_AR1.jl,
 
in expression starting on line 88


Note that these error statements keep repeating until Julia is forced to 
shut down.

The code for PF_outer_example.jl is attached.  PF_outer_example.jl calls to 
PF_inner_example.jl, which is also attached.

This code implements a particle filter Markov chain Monte Carlo estimator 
of a state space model.  The particle filter is run in 
PF_inner_example.jl.  

test_SI_AR1.jl loads parameters and coefficients of the model to be 
estimated along with the data, yyy, which is a nvar x obs array and passes 
these PF_outer_example.jl

PF_outer_example.jl runs the particle filter on all the observations of 
yyy, j = 1, 2, ..., obs.  At each j, PF_outer_example.jl does several 
computations and passes these, yyy[:,j], and the parameters and 
coefficients to PF_inner_example.jl

PF_inner_example.jl runs the particle filter on observations yyy[.,j] for m 
= 1, 2, ..., mprt replications.  mprt = the number of particles which be 
anywhere from 500 to 10,000.

I am trying to implement a pmap command in PF_outer_example.jl to run the 
mprt particles in PF_inner_example.jl in parallel.

With no success.

I have tried a couple of variations of the pmap command, but the same error 
message above is always returned by Julia.  The variations of the pmap 
command that I have tried are listed in PF_outer_example.jl.

Obviously, I do not understand something that is fundamental to pmap.  Any 
advice/suggestions are welcome.

Best,

Jim




PF_outer_example.jl
Description: Binary data


PF_inner_example.jl
Description: Binary data

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Stefan Karpinski]

In this case, it also obfuscates the meaning of the code. Does x.f(y) mean
f(x,y) or is it actually x.f(y)? With this proposal you would need to know
something about x in order to decide, currently there's no confusion.

On Wednesday, October 7, 2015, Steven G. Johnson 
wrote:

> On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>>
>> I don't see why it is bad to support more styles if there is no harm to
>> the original one.
>>
>
> Because code that mixes multiple styles is harder to read (imagine reading
> a document that jumps back and forth between different spellings), harder
> to share (because other Julia programmers won't know your idiosyncratic
> style), and harder to combine with other features of the language (as
> others have said, multiple dispatch is central to Julia's design and
> central to the design of the standard library).
>
> This comes up with every new programming language, which is why it is
> useful to learn from history.
>

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Alan Crawford]

 As a Matlab convert who had the same realisation recently  +1 for this 
thread!


On Wednesday, 7 October 2015 23:49:33 UTC+1, Patrick Kofod Mogensen wrote:
>
> Maybe I'm wrong but I think it's different in Matlab. If a variable exists 
> already, it will try to reuse it. I know Julia is not Matlab, and I don't 
> want it to be, but all scientific programming experience I have is from 
> Matlab, so I just assumed. Which is stupid.
>
> I totally get your explanation, I just hadn't thought about it. I've been 
> doing a whle lot of unnecessary assignments instead of setindexing! :)
>
> On Wednesday, October 7, 2015 at 6:16:18 PM UTC-4, Simon Danisch wrote:
>>
>> Well that's how assignment usually works.
>> The *[:]* is something else and is redirecting you to setindex!.
>> *x[:] = 42* is the same as *setindex(a, 42, :)*, which is the same as 
>> *setindex(a, 
>> 42, 1:length(a))*
>>
>> So it's assigning to the indexes of that vector, which means it's reusing 
>> it.
>> Maybe have a look at array_indexing 
>>  ?
>>
>> Am Mittwoch, 7. Oktober 2015 22:25:00 UTC+2 schrieb Patrick Kofod 
>> Mogensen:
>>>
>>> So I asked a question over at 
>>> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
>>> and it seems that I have got something completely wrong.
>>>
>>> It seems that the following
>>>
>>> index = rand(8000)
>>> phat = zeros(8000)
>>>
>>> phat = 1./(1+exp(-index))
>>>
>>> binds the output of the calculation on the rhs to a _new_ vector phat, 
>>> not the original vector. This really means I have misunderstood 
>>> preallocation/re-using memory in Julia completely! @blakejohnson suggests 
>>> that I use
>>>
>>> phat[:] = 1./1+(exp(-index))
>>>
>>> instead. As this puts the calculations in the already preallocated 
>>> vector phat. 
>>>
>>> Question 1) Can I learn more about this in the documentation ? I'm 
>>> having a hard time finding anything, probably because [:] is hard to use as 
>>> a search phrase, and I'm not sure what concepts to search for.
>>>
>>>
>>>
>>> I often wrap my variables in a type, but this seems like an extremely 
>>> bad idea in combination with devec. I have taken Blake Johnsons examples 
>>> from github, and added a few 
>>> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>>>
>>> Question 2) What is it that makes test4() and test6() run so slowly?  
>>> test1() and test3() seems to perform equivalently fast. I use this kind of 
>>> setup all the time, and I am surprised that this method allocates so much 
>>> memory.
>>>
>>> Bad news: I've been doing Julia ALL wrong!
>>> Good news: Time to learn some more!
>>>
>>

[julia-users] Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Patrick Kofod Mogensen]

So I asked a question over at 
https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
and it seems that I have got something completely wrong.

It seems that the following

index = rand(8000)
phat = zeros(8000)

phat = 1./(1+exp(-index))

binds the output of the calculation on the rhs to a _new_ vector phat, not 
the original vector. This really means I have misunderstood 
preallocation/re-using memory in Julia completely! @blakejohnson suggests 
that I use

phat[:] = 1./1+(exp(-index))

instead. As this puts the calculations in the already preallocated vector 
phat. 

Question 1) Can I learn more about this in the documentation ? I'm having a 
hard time finding anything, probably because [:] is hard to use as a search 
phrase, and I'm not sure what concepts to search for.



I often wrap my variables in a type, but this seems like an extremely bad 
idea in combination with devec. I have taken Blake Johnsons examples from 
github, and added a few https://gist.github.com/pkofod/fb6c4b8ffcca1a056363

Question 2) What is it that makes test4() and test6() run so slowly?  
test1() and test3() seems to perform equivalently fast. I use this kind of 
setup all the time, and I am surprised that this method allocates so much 
memory.

Bad news: I've been doing Julia ALL wrong!
Good news: Time to learn some more!

Re: [julia-users] DataFrames' readtable very slow compared to R's read.csv when loading ~7.6M csv rows

[bernhard]

Is there any update on this? Or maybe a timeline/roadmap?
I would love to see a faster CSV reader. 

I tried to take a look at Jacob's CSV.jl.
But I seem to be missing https://github.com/lindahua/DataStreams.jl 
I have no idea where to find DataStreams package
Does it still exist?

Is there any (experimental) way to make CSV.jl work?



> Am Samstag, 6. Juni 2015 14:41:36 UTC+2 schrieb David Gold:
>
> @Jacob,
>
> Thank you very much for your explanation! I expect having such a blueprint 
> will make delving into the actual code more tractable for me. I'll be 
> curious to see how your solution here and your proposal for string handling 
> end up playing with the current Julia data ecosystem. 
>
> On Saturday, June 6, 2015 at 1:17:34 AM UTC-4, Jacob Quinn wrote:
>>
>> @David,
>>
>> Sorry for the slow response. It's been a busy week :)
>>
>> Here's a quick rundown of the approach:
>>
>> - In the still-yet-to-be-officially-published 
>> https://github.com/quinnj/CSV.jl package, the bulk of the code goes into 
>> creating a `CSV.File` type where the structure/metadata of the file is 
>> parsed/detected/saved in a type (e.g. header, delimiter, newline, # of 
>> columns, detected column types, etc.)
>> - `SQLite.create` and now `CSV.read` both take a `CSV.File` as input and 
>> follow a similar process in parsing:
>>   - The actual file contents are mmapped; i.e. the entire file is loaded 
>> into memory at once
>>   - There are currently three `readfield` methods (Int,Float64,String) 
>> that take an open `CSV.Stream` type (which holds the mmapped data and the 
>> current "position" of parsing), and read a single field according to what 
>> the type of that column is supposed to be
>>   - for example, readfield(io::CSV.Stream, ::Type{Float64}, row, 
>> col), will start reading at the current position of the `CSV.Stream` until 
>> it hits the next delimiter, newline, or end of the file and then interpret 
>> the contents as a Float64, returning `val, isnull`
>>
>> That's pretty much it. One of the most critical performance keys for both 
>> SQLite and CSV.read is non-copying strings once the file has been mmapped. 
>> For SQLite, the sqlite3_bind_text library method actually has a flag to 
>> indicate whether the text should be copied or not, so we're able to pass 
>> the pointer to the position in the mmapped array directly. For the CSV.read 
>> method, which returns a Vector of the columns (as typed arrays), I've 
>> actually rolled a quick and dirty CString type that looks like
>>
>> immutable CString
>>   ptr::Ptr{UInt8}
>>   len::Int
>> end
>>
>> With a few extra method definitions, this type looks very close to a real 
>> string type, but we can construct it by pointing directly to the mmapped 
>> region (which currently isn't possible for native Julia string types). See 
>> https://github.com/quinnj/Strings.jl for more brainstorming around this 
>> alternative string implementation. You can convert a CString to a Julia 
>> string by calling string(x::CString) or map(string,column) for an Array of 
>> CSV.CStrings.
>>
>> As an update on the performance on the Facebook Kaggle competition 
>> bids.csv file:
>>
>> -readcsv: 45 seconds, 33% gc time
>> -CSV.read: 19 seconds, 3% gc time
>> -SQLite.create: 25 seconds, 3.25% gc time
>>
>> Anyway, hopefully I'll get around to cleaning up CSV.jl to be released 
>> officially, but it's that last 10-20% that's always the hardest to finish 
>> up :)
>>
>> -Jacob
>>
>>
>>
>> On Mon, Jun 1, 2015 at 4:25 PM, David Gold  wrote:
>>
>>> @Jacob I'm just developing a working understanding of these issues. 
>>> Would you please help me to get a better handle on your solution?
>>>
>>> My understanding thus far: Reading a (local) .csv file into a DataFrame 
>>> using DataFrames.readtable involves reading the file into an IOStream and 
>>> then parsing that stream into a form amenable to parsing by 
>>> DataFrames.builddf, which builds the DataFrame object returned by 
>>> readtable. The work required to get the contents of the .csv file into 
>>> memory in a form that can be manipulated by Julia functions is 
>>> work-intensive in this manner. However, with SQLite, the entire file can 
>>> just be thrown into memory wholesale, along with some metadata (maybe not 
>>> the right term?) that delineates the tabular properties of the data. 
>>>
>>> What I am curious about, then (if this understanding is not too 
>>> misguided), is how SQLite returns, say, a column of data that doesn't 
>>> include, say, a bunch of delimiters. That is, what sort of parsing *does* 
>>> SQLite do, and when?
>>>
>>> On Monday, June 1, 2015 at 1:48:16 PM UTC-4, Jacob Quinn wrote:

 The biggest single advantage SQLite has is the ability to mmap a file 
 and just tell SQLite which pointer addresses start strings and how long 
 they are, all without copying. The huge, huge bottleneck in most 
 implementations, is not just identifying where a string starts and 

[julia-users] Re: Given a tuple type, can I dynamically instantiate the tuple in a type-stable way?

[Jeffrey Sarnoff]

thx


On Wednesday, October 7, 2015 at 4:55:01 AM UTC-4, Tomas Lycken wrote:
>
> Not sure what you’re asking, but if you want the *why* of this question, 
> the reason is that I have an interface (of Interpolations.jl) that 
> currently takes types (i.e. the argument type is Type{T}) as 
> configuration flags. For flexibility, I want to switch to instances 
>  (i.e. argument 
> type T), but at least for a while I also want existing functionality to 
> be backwards compatible. To do that, I want to create forwards of the type
>
> foo{T}(::Type{T}) = foo(T())
>
> but Tuple{S,T}() isn’t possible for (and the flags can be combined, 
> recursively, in tuples) so I needed a recursive solution to instantiate the 
> tuples. construct_instance solves this problem
>
> julia> construct_instance(Tuple{S,T})
> (S(), T())
> julia> construct_instance(Tuple{S,Tuple{T, U, V}})
> (S(), (T(), U(), V()))
>
> This lets me get away with
>
> foo(::Type{T}) = foo(construct_instance(T))
> function foo(::T)
> # actual implementation
> end
>
> and keep exposing both methods in the API.
>
> // T
>
> On Tuesday, October 6, 2015 at 9:15:32 PM UTC+2, Jeffrey Sarnoff wrote:
>
> Would you show a simple example of the use, and defs for tuple, ntuple 
> below?
>
> On Monday, October 5, 2015 at 5:42:17 AM UTC-4, Tomas Lycken wrote:
>
> Ha! It seems all I needed was a type-assertion at the end. Both of these 
> work the way I want them to:
>
> construct_instance{T<:Tuple}(::Type{T}) = tuple([construct_instance(t) for t 
> in T.parameters]...)::T
> construct_instance{T<:Tuple}(::Type{T}) = ntuple(i -> 
> construct_instance(T.parameters[i]), length(T.parameters))::T
>
> // T
>
> On Monday, October 5, 2015 at 11:33:25 AM UTC+2, Tomas Lycken wrote:
>
> I managed to get rid of the list comprehension by using ntuple:
>
> construct_instance{T<:Tuple}(::Type{T}) = ntuple(i -> 
> construct_instance(T.parameters[i]), length(T.parameters))
>
> However, this suffers from the same instability problem (because of the 
> anonymous function?). I’ll keep trying, but I would gladly accept any 
> advice on how to do this.
>
> // T
>
> On Monday, October 5, 2015 at 10:28:15 AM UTC+2, Tomas Lycken wrote:
>
> I’ve tried to do the following
>
> construct_instance{T}(::Type{T}) = T()
> construct_instance{T<:Tuple}(::Type{T}) = tuple([construct_instance(t) for t 
> in T.parameters]...)
>
> as a way to dynamically and recursively create an instance of a tuple 
> type. The tuple type might be nested, it might be any length > 0, and all 
> (supported) non-tuple types in the hierarchy are leaf-types with an empty 
> constructor defined.
>
> This works insofar as it gives me the tuple I want back, but it’s not type 
> stable; the inferred return type is Tuple rather than T. I also tried 
> wrapping it in convert(T, tuple(...)), but that only gave me e.g. Tuple{Any, 
> Any} for a two-tuple type, which I assume is because type info is lost in 
> the list comprehension.
>
> Is there a way to help type inference realize that it will get a T back, 
> even when T is a tuple type?
>
> // T
> ​
>
> ​
>
> ​
>
> ...

[julia-users] Re: @spawn plot(rand(100))

[Ariel Keselman]

'plot' creates a result in the remote process

you have to fetch this result into the main process, the one which draws to 
screen like this:

result = @spawn plot(randn(100))

# do some stufff...

# when ready to fetch fetch!
fetch(result)

This will display the plot...

Re: [julia-users] Re: Fastest way to get # of bits of an integer value in Julia?

[Kevin Squire]

It should be floor(log2(n))+1 (excluding zero).

On Tue, Oct 6, 2015 at 9:45 AM, Scott Jones 
wrote:

> Also, ceil(log2(n)) doesn't get the correct answer - it gets 31 instead of
> 32.
> (my value of x was 2^31)
>
>
> On Tuesday, October 6, 2015 at 11:50:19 AM UTC-4, Ravi S wrote:
>
>> julia> function nbits(x)
>>  n = 0
>>  while x!=0
>>n += 1
>>x >>= 1
>>  end;
>>  return n
>>end
>> nbits (generic function with 1 method)
>>
>> julia> @time ceil(log2(x))
>> elapsed time: 7.376e-6 seconds (112 bytes allocated)
>> 18.0
>>
>> julia> @time sizeof(x)*8 - leading_zeros(x)
>> elapsed time: 9.781e-6 seconds (80 bytes allocated)
>> 18
>>
>> julia> @time length(bin(x))
>> elapsed time: 6.693e-6 seconds (176 bytes allocated)
>> 18
>>
>> julia> @time nbits(x)
>> elapsed time: 5.425e-6 seconds (80 bytes allocated)
>> 18
>>
>>
>> On Tuesday, October 6, 2015 at 9:14:52 PM UTC+5:30, Scott Jones wrote:
>>>
>>> Well, I asked about how to get it as fast as possible.
>>> Turns out, leading_zeros does just what I want, using the lzcnt*
>>> instruction :-)
>>> If you don't count the unnecessary frame setup (pushq %rbp; movq %rsp,
>>> %rbp) and frame pop/return (popq %rbp ; ret), the whole thing I want boils
>>> down to 4 instructions, nicely parameterized by Julia on the type ;-)
>>>
>>>
>>> On Tuesday, October 6, 2015 at 11:41:03 AM UTC-4, Tim Holy wrote:

 Presumably, iterating over x>>1 until x == 0 should do the trick?

 --Tim

 On Tuesday, October 06, 2015 08:21:35 AM Scott Jones wrote:
 > Sorry!  I should have been more specific.
 > What I want is:
 > 0 -> 0
 > 1 -> 1
 > 0x8 -> 4
 > 0x1f -> 5
 > 13 -> 5
 >
 > i.e. number of bits needed to represent the number.
 > I want to pack 2 or 3 values into a unsigned int, (maybe a UInt16, up
 to a
 > UInt128), that I can then use for sorting purposes efficiently.
 > (much more cache efficient, eliminates a bunch of pointer references,
 etc.)
 >
 > Any idea how? (normally, I'd just use the assembly instructions
 available
 > that do this, but I want to do this in pure Julia [it would be nice
 if the
 > Julia code
 > could actually be smart enough to generate the correct native code
 ;-) )
 >
 > Thanks!
 >
 > On Tuesday, October 6, 2015 at 11:03:03 AM UTC-4, Steven G. Johnson
 wrote:
 > > On Tuesday, October 6, 2015 at 10:59:04 AM UTC-4, Scott Jones
 wrote:
 > >> I couldn't find anything yet - is there a recommended / fastest
 way to
 > >> get the number of bits in a number (I really only need it for
 unsigned
 > >> values).
 > >> Thanks
 > >
 > > sizeof(number)*8 if you want all the bits (though you'd need to
 define a
 > > separate method for BigInt), or count_ones(number) if you want the
 1 bits.

[julia-users] Re: Given a tuple type, can I dynamically instantiate the tuple in a type-stable way?

[Tomas Lycken]

Not sure what you’re asking, but if you want the *why* of this question, 
the reason is that I have an interface (of Interpolations.jl) that 
currently takes types (i.e. the argument type is Type{T}) as configuration 
flags. For flexibility, I want to switch to instances 
 (i.e. argument type T), 
but at least for a while I also want existing functionality to be backwards 
compatible. To do that, I want to create forwards of the type

foo{T}(::Type{T}) = foo(T())

but Tuple{S,T}() isn’t possible for (and the flags can be combined, 
recursively, in tuples) so I needed a recursive solution to instantiate the 
tuples. construct_instance solves this problem

julia> construct_instance(Tuple{S,T})
(S(), T())
julia> construct_instance(Tuple{S,Tuple{T, U, V}})
(S(), (T(), U(), V()))

This lets me get away with

foo(::Type{T}) = foo(construct_instance(T))
function foo(::T)
# actual implementation
end

and keep exposing both methods in the API.

// T

On Tuesday, October 6, 2015 at 9:15:32 PM UTC+2, Jeffrey Sarnoff wrote:

Would you show a simple example of the use, and defs for tuple, ntuple 
> below?
>
> On Monday, October 5, 2015 at 5:42:17 AM UTC-4, Tomas Lycken wrote:
>>
>> Ha! It seems all I needed was a type-assertion at the end. Both of these 
>> work the way I want them to:
>>
>> construct_instance{T<:Tuple}(::Type{T}) = tuple([construct_instance(t) for t 
>> in T.parameters]...)::T
>> construct_instance{T<:Tuple}(::Type{T}) = ntuple(i -> 
>> construct_instance(T.parameters[i]), length(T.parameters))::T
>>
>> // T
>>
>> On Monday, October 5, 2015 at 11:33:25 AM UTC+2, Tomas Lycken wrote:
>>
>> I managed to get rid of the list comprehension by using ntuple:
>>>
>>> construct_instance{T<:Tuple}(::Type{T}) = ntuple(i -> 
>>> construct_instance(T.parameters[i]), length(T.parameters))
>>>
>>> However, this suffers from the same instability problem (because of the 
>>> anonymous function?). I’ll keep trying, but I would gladly accept any 
>>> advice on how to do this.
>>>
>>> // T
>>>
>>> On Monday, October 5, 2015 at 10:28:15 AM UTC+2, Tomas Lycken wrote:
>>>
>>> I’ve tried to do the following

 construct_instance{T}(::Type{T}) = T()
 construct_instance{T<:Tuple}(::Type{T}) = tuple([construct_instance(t) for 
 t in T.parameters]...)

 as a way to dynamically and recursively create an instance of a tuple 
 type. The tuple type might be nested, it might be any length > 0, and all 
 (supported) non-tuple types in the hierarchy are leaf-types with an empty 
 constructor defined.

 This works insofar as it gives me the tuple I want back, but it’s not 
 type stable; the inferred return type is Tuple rather than T. I also 
 tried wrapping it in convert(T, tuple(...)), but that only gave me 
 e.g. Tuple{Any, Any} for a two-tuple type, which I assume is because 
 type info is lost in the list comprehension.

 Is there a way to help type inference realize that it will get a T 
 back, even when T is a tuple type?

 // T
 ​

>>> ​
>>>
>> ​
>>
> ​

[julia-users] Re: StackOverflow error while attempting to "lift" Nullables

[Tomas Lycken]

I think you're starting in the wrong end; a better approach would be to ask 
*which functions even need manual lifting*?

If you have unary and binary plus, base has fallbacks that handle 
multiple-argument plus for you (so that e.g. `+(a, b, c) = +(+(a, b), c)` 
if the types of `a`, `b` and `c` in that combo don't have a three-argument 
method). The same thing goes for subtraction, multiplication and a host of 
other operators. Thus, there is no need to implement lifting for *all* 
methods in base - better, implement just the ones you need, and let base 
figure out how to use the methods you define.

I usually find that the best approach is to start working with just one or 
two method additions, and then start coding. Whenever I run on a 
no-method-error, I know of another method I need to define. If I don't get 
any no-method-errors, I'm done :)

// T

On Tuesday, October 6, 2015 at 9:37:01 PM UTC+2, Data Pulverizer wrote:
>
> p.s. I am aware that unary function template would only add one to your 
> collection overall with meta programming but more than two and three 
> parameter and code starts to get large or maybe I'm just lazy.
>
> On Tuesday, October 6, 2015 at 8:30:00 PM UTC+1, data.pu...@gmail.com 
> wrote:
>>
>> Hi Thomas,
>>
>> At first I started by taking this kind of approach but what if you want 
>> to lift all the relevant functions in Julia Base? Some are unary, binary, 
>> and then other have multiple parameters and you also have to think about 
>> all the combinations of parameters that you could have. The current 
>> approach I am taking would allow you to lift all the relevant functions in 
>> Julia Base without having to write all the combinations of functions. And 
>> as you rightly pointed out in a previous email, Julia language can change, 
>> its constantly being developed. Therefore I am trying to use a small code 
>> set that does what we it needs to do but has a minimal maintenance 
>> requirement. In the end I would like to do:
>>
>> Importall Base
>> fun_names = names(Base) #[or a relevant selection of this]
>>
>> # Small lift code goes here ...
>> ...
>> # Then we are done
>>
>>
>>
>> On Tuesday, October 6, 2015 at 8:32:38 AM UTC+1, Tomas Lycken wrote:
>>>
>>> Sorry, do this instead to make sure that the code is type stable:
>>>
>>> +{S,T}(x::Nullable{S}, y::Nullable{T}) = isnull(x) || isnull(y) ? 
>>> Nullable{promote_type(S,T)}() : Nullable(x.value + y.value)
>>> +{S,T}(x::Nullable{S}, y::T) = +(x, Nullable(y))
>>> +{S,T}(x::T, y::Nullable{S}) = +(y, x)
>>>
>>> // T
>>>
>>> On Tuesday, October 6, 2015 at 9:31:15 AM UTC+2, Tomas Lycken wrote:
>>>
>>> It seems that you should be able to do this by defining new methods for 
 the operations you need to support. For addition, you could do

 ```
 +{S,T}(x::Nullable{S}, y::Nullable{T}) = isnull(x) || isnull(y) ? 
 Nullable{promote_type(S,T)}() : x.value + y.value
 +{S,T}(x::Nullable{S}, y::T) = +(x, Nullable(y))
 +{S,T}(x::T, y::Nullable{S}) = +(y, x)
 ```

 For other operations, you would do similar things.

 // T


 On Tuesday, October 6, 2015 at 4:33:05 AM UTC+2, data.pu...@gmail.com 
 wrote:
>
> I'd like to be able to do for example:
>
> Nullable(3.) + 6 = Nullable(9.)
>
> as well as
>
> Nullable(3.) + Nullable(6) = Nullable(9)
>
> All types interacting with Nullables -> Nullable
>
> ​
>>>
>>

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Jonathan Malmaud]

You could also use pipelining: man |> _->eat(_, food). There's been talk of 
having "pronoun" syntactic sugar to let you write that as 
man |> eat(_, food) or perhaps taking it even further and assuming the first 
argument is the pronoun recipient, yielding
man |> eat(food)

I personally favor a solution along these lines since it doesn't hide multiple 
dispatch but still gives you the svo order which many find more natural in 
certain domains. 

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[lewis]

Seems a bad idea even as syntactic sugar, except for the case of using 
PyCall (when the target language is loosely object oriented).

If you prefer object oriented dispatch, many languages offer it.  With 
strong typing, optionally as Julia provides, OO dispatch can off make class 
inheritance very difficult.  I realize the OP has no issue with multiple 
dispatch and wants to preserve it and the syntactic sugar would rarely, if 
ever interfere with it.  Since multiple dispatch is expressed with function 
call syntax, Julia should stick to that.  While I wouldn't want Julia to go 
too wild down the functional programming path, the key benefits of FP that 
Julia provides--namely, multiple dispatch, 1st class functions, and 
closures--are really great and handily fit a language with a more 
imperative style.

In Python (I still love Python), x.f(y) is really just syntactic sugar for 
f(x,y).  It almost seems silly to have it at all.  And since Julia is even 
less OO than Python, which is to say not at all then it seems almost 
misleading to mimic the OO syntax since OO is definitely NOT what is 
happening under the hood.

While I realize the OP is not really asking for it, it is still worth 
pointing out that there seems little benefit to going down the OO path.

[julia-users] Re: IPython keeps giving Kernel error

[ronubi]

I'm having the same problem.

Mac OS 10.11
Julia 0.3.11
Jupyter 4.0.6

Python 2.7.10


Set verbose-debug=true and stderr-capture=false as suggested 
at https://github.com/JuliaLang/IJulia.jl


Error dump follows:

##

$ jupyter-notebook moj-notes.ipynb 

[I 21:37:21.750 NotebookApp] Serving notebooks from local directory: 
/Users/ubi/work/study/julia

[I 21:37:21.750 NotebookApp] 0 active kernels 

[I 21:37:21.750 NotebookApp] The IPython Notebook is running at: 
http://localhost:/

[I 21:37:21.751 NotebookApp] Use Control-C to stop this server and shut 
down all kernels (twice to skip confirmation).

[I 21:37:24.244 NotebookApp] Kernel started: 
8ed88591-0a25-4c1a-9d07-5ba953a4a853

ERROR: type: instantiate_type: expected TypeConstructor, got Function

 in anonymous at no file:236

 in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in include_from_node1 at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in reload_path at loading.jl:152

 in _require at loading.jl:67

 in require at loading.jl:51

 in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in include_from_node1 at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in include_from_node1 at loading.jl:128

 in process_options at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

 in _start at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib

while loading /Users/ubi/.julia/v0.3/ZMQ/src/ZMQ.jl, in expression starting 
on line 234

while loading /Users/ubi/.julia/v0.3/IJulia/src/IJulia.jl, in expression 
starting on line 13

while loading /Users/ubi/.julia/v0.3/IJulia/src/kernel.jl, in expression 
starting on line 4

[I 21:37:27.243 NotebookApp] KernelRestarter: restarting kernel (1/5)

##


Any suggestions?

On Thursday, October 1, 2015 at 11:23:55 AM UTC-7, Steven G. Johnson wrote:
>
>
>
> On Thursday, October 1, 2015 at 9:55:46 AM UTC-4, Shubham Bhushan wrote:
>>
>> I wish I could give you a more helpful message but quite literally, the 
>> Ipython notebook says Failed to restart kernel.
>>
>> ×
>> Dead kernel
>> The kernel has died, and the automatic restart has failed. It is possible 
>> the kernel cannot be restarted. If you are not able to restart the kernel, 
>> you will still be able to save the notebook, but running code will no 
>> longer work until the notebook is reopened.
>>
>> this is the verbatim output
>>
>>>
> Basic information would be your OS, your Julia version, your Jupyter 
> version, what Python distro you are using.   More information could be 
> provided by reading the "debugging IJulia" instructions that I mentioned, 
> which may provide additional error output. 
>

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Jeffrey Sarnoff]

It may be that this cannot be fully resolved until the REPL's internal 
sketch of function dependencies allows rapid reweaving when an intermediate 
function is modified.
With that, pulling function-family specs and offering thematic looks could 
be very efficient.

On Wednesday, October 7, 2015 at 6:03:45 PM UTC-4, Stefan Karpinski wrote:
>
> This is a real issue but I don't think that aping the syntax of a very 
> different paradigm is the right solution.
>
> On Wednesday, October 7, 2015,  
> wrote:
>
>> I think the auto-completion is a bit of an issue, it makes Julia 
>> functions not easily discoverable. In other language when you have a string 
>> you can just type dot and tab and see all the methods that you can apply to 
>> your string, so you almost never need to go to the doc.
>>
>> Something similar should be possible to implement in Julia with 
>> methodswith but I'm not sure any IDE support that yet. methodswith might 
>> also be too slow for that purpose.
>>
>

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Jonathan Malmaud]

A great package actually already implements this concept: 
https://github.com/one-more-minute/Lazy.jl#macros:

julia> eat(x,y) = println("$x ate $y")
julia> @> 7 eat(9)
"7 ate 9'

On Wednesday, October 7, 2015 at 10:06:27 PM UTC-4, Jonathan Malmaud wrote:
>
> You could also use pipelining: man |> _->eat(_, food). There's been talk 
> of having "pronoun" syntactic sugar to let you write that as 
> man |> eat(_, food) or perhaps taking it even further and assuming the 
> first argument is the pronoun recipient, yielding
> man |> eat(food)
>
> I personally favor a solution along these lines since it doesn't hide 
> multiple dispatch but still gives you the svo order which many find more 
> natural in certain domains. 
>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Steven G. Johnson]

Note, however, that this "display" output should probably be a method of 
writemime(io::IO, ::MIME"text/plain", x).  The show(io, x) for ranges 
should continue to be the compact output.

[julia-users] Accessing MSYS2 built dlls from Julia

[Bill Hart]

I understand that under normal circumstances, for least difficulties, one 
wants to build dlls using the mingw-w64 gcc if one wants to use it from 
Julia. This makes a dll which is not dependent on msys-2.0.dll.

My question is: should I expect to be unable to use *any* dlls built using 
the MSYS2 gcc (if I also provide msys-2.0.dll obviously), even in theory? 

If not, does anyone know why this is the case? depends22.exe seems to be 
able to open such dlls and see the symbols therein, so it seems in all 
respects to be a standard dll. What is different about it that makes it 
inaccessible from native applications like Julia?

The question is relevant because of the large amount of software out there 
which absolutely relies on lots of posix stuff, and can't be built with 
mingw-w64. Such software needs msys-2.0.dll for the posix layer.

Basically I just built a dll with MSYS2's gcc and whilst Julia dlopen's it, 
any attempt to call functions in it results in a ReadOnlyMemoryError. 
Somehow I thought I actually had this working in the past, but I must have 
misled myself somehow.

Any help in understanding what's going on would be greatly appreciated.

Bill.

[julia-users] Re: Accessing MSYS2 built dlls from Julia

[Tony Kelman]

When I try to ccall printf from cygwin1.dll (which should be equivalent to 
msys-2.0.dll) from inside a cygwin mintty terminal, I get a longer error 
message "fatal error - cygheap base mismatch detected - This problem is 
probably due to using incompatible versions of the cygwin DLL."

Loading and using 2 different C runtime libraries (the posix cygwin dll, 
and the non-posix msvcrt used by mingw-w64) from inside the same 
application is unlikely to work. If you need to work with libraries that 
can only be built in a posix environment, and you can only work with them 
via loading them into process memory (as opposed to IPC over something like 
ZMQ, or pipes, or the filesystem), then the highest chance of success would 
be to use a hypothetical version of Julia built against the same posix 
environment. If libuv supported building on Cygwin (it doesn't, Cygwin does 
not implement the asyncio posix extensions used in libuv) then there could 
hypothetically be a Cygwin package of Julia that you would be better off 
using for this. For now, either fix the posix-only library you're trying to 
use so it can be built natively on Windows, or find another way to 
communicate with it.


On Wednesday, October 7, 2015 at 9:27:40 PM UTC-7, Bill Hart wrote:
>
> I understand that under normal circumstances, for least difficulties, one 
> wants to build dlls using the mingw-w64 gcc if one wants to use it from 
> Julia. This makes a dll which is not dependent on msys-2.0.dll.
>
> My question is: should I expect to be unable to use *any* dlls built using 
> the MSYS2 gcc (if I also provide msys-2.0.dll obviously), even in theory? 
>
> If not, does anyone know why this is the case? depends22.exe seems to be 
> able to open such dlls and see the symbols therein, so it seems in all 
> respects to be a standard dll. What is different about it that makes it 
> inaccessible from native applications like Julia?
>
> The question is relevant because of the large amount of software out there 
> which absolutely relies on lots of posix stuff, and can't be built with 
> mingw-w64. Such software needs msys-2.0.dll for the posix layer.
>
> Basically I just built a dll with MSYS2's gcc and whilst Julia dlopen's 
> it, any attempt to call functions in it results in a ReadOnlyMemoryError. 
> Somehow I thought I actually had this working in the past, but I must have 
> misled myself somehow.
>
> Any help in understanding what's going on would be greatly appreciated.
>
> Bill.
>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Steven G. Johnson]

On Wednesday, October 7, 2015 at 8:05:19 PM UTC-4, Art Kuo wrote:
>
> I've coded up a simple replacement to the show() function for ranges. The 
> idea is to give the user information more likely to be what they are 
> wondering. Here are some examples of its output:
>

It looks great to me; please consider submitting a pull request. 

Any thoughts on this arrangement? The output differs from collect() in that 
> I've arranged elements in a compact row. Also I've assumed that it's 
> sufficient to print out only the first three elements, and the last two, 
> because the user should be able to figure it out from there. A possible 
> point of confusion is "7-element" which isn't actually true of the Range 
> object. Would it be better to output "7-length" or something else?
>

"7-element" is nice because it mirrors the output for Array objects.  I 
don't see the problem.
 

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

In Julia, when people use x.f(y), what he actual means is f(x, y) (assuming 
f relies on x). So there is no need to define f inside a type, just define 
f(x,y) outside.
So, my first conclusion is: it is not a good practice to put function 
inside a type.

If there is a rule that people can not define function field in a type, 
then set x.f(y) = f(x,y) does not have the confusion you mentioned early.
Also x.f might be good for multi-dispatch. I am not sure how multi-dispatch 
is implemented, but the prefix x seems provide a good heuristic.

Best,
Cheng

On Thursday, October 8, 2015 at 12:03:45 AM UTC+2, Stefan Karpinski wrote:
>
> This is a real issue but I don't think that aping the syntax of a very 
> different paradigm is the right solution.
>
> On Wednesday, October 7, 2015,  
> wrote:
>
>> I think the auto-completion is a bit of an issue, it makes Julia 
>> functions not easily discoverable. In other language when you have a string 
>> you can just type dot and tab and see all the methods that you can apply to 
>> your string, so you almost never need to go to the doc.
>>
>> Something similar should be possible to implement in Julia with 
>> methodswith but I'm not sure any IDE support that yet. methodswith might 
>> also be too slow for that purpose.
>>
>

[julia-users] Re: IPython keeps giving Kernel error

[Tony Kelman]

What does Pkg.installed("ZMQ") say?

On Wednesday, October 7, 2015 at 9:46:43 PM UTC-7, ron...@gmail.com wrote:
>
> I'm having the same problem.
>
> Mac OS 10.11
> Julia 0.3.11
> Jupyter 4.0.6
>
> Python 2.7.10
>
>
> Set verbose-debug=true and stderr-capture=false as suggested at 
> https://github.com/JuliaLang/IJulia.jl
>
>
> Error dump follows:
>
> ##
>
> $ jupyter-notebook moj-notes.ipynb 
>
> [I 21:37:21.750 NotebookApp] Serving notebooks from local directory: 
> /Users/ubi/work/study/julia
>
> [I 21:37:21.750 NotebookApp] 0 active kernels 
>
> [I 21:37:21.750 NotebookApp] The IPython Notebook is running at: 
> http://localhost:/
>
> [I 21:37:21.751 NotebookApp] Use Control-C to stop this server and shut 
> down all kernels (twice to skip confirmation).
>
> [I 21:37:24.244 NotebookApp] Kernel started: 
> 8ed88591-0a25-4c1a-9d07-5ba953a4a853
>
> ERROR: type: instantiate_type: expected TypeConstructor, got Function
>
>  in anonymous at no file:236
>
>  in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in reload_path at loading.jl:152
>
>  in _require at loading.jl:67
>
>  in require at loading.jl:51
>
>  in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in include at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in include_from_node1 at loading.jl:128
>
>  in process_options at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
>  in _start at /usr/local/Cellar/julia/0.3.11/lib/julia/sys.dylib
>
> while loading /Users/ubi/.julia/v0.3/ZMQ/src/ZMQ.jl, in expression 
> starting on line 234
>
> while loading /Users/ubi/.julia/v0.3/IJulia/src/IJulia.jl, in expression 
> starting on line 13
>
> while loading /Users/ubi/.julia/v0.3/IJulia/src/kernel.jl, in expression 
> starting on line 4
>
> [I 21:37:27.243 NotebookApp] KernelRestarter: restarting kernel (1/5)
>
> ##
>
>
> Any suggestions?
>
> On Thursday, October 1, 2015 at 11:23:55 AM UTC-7, Steven G. Johnson wrote:
>>
>>
>>
>> On Thursday, October 1, 2015 at 9:55:46 AM UTC-4, Shubham Bhushan wrote:
>>>
>>> I wish I could give you a more helpful message but quite literally, the 
>>> Ipython notebook says Failed to restart kernel.
>>>
>>> ×
>>> Dead kernel
>>> The kernel has died, and the automatic restart has failed. It is 
>>> possible the kernel cannot be restarted. If you are not able to restart the 
>>> kernel, you will still be able to save the notebook, but running code will 
>>> no longer work until the notebook is reopened.
>>>
>>> this is the verbatim output
>>>

>> Basic information would be your OS, your Julia version, your Jupyter 
>> version, what Python distro you are using.   More information could be 
>> provided by reading the "debugging IJulia" instructions that I mentioned, 
>> which may provide additional error output. 
>>
>

[julia-users] Re: IPython keeps giving Kernel error

[David P. Sanders]

You could try with the latest Julia 0.4 release candidate. Have you tried 
deleting your whole .julia directory and reinstalling IJulia? 

[julia-users] Re: IPython keeps giving Kernel error

[ronubi]

Wow, you guys are fast to reply!

On Wednesday, October 7, 2015 at 10:16:35 PM UTC-7, Tony Kelman wrote:
>
> What does Pkg.installed("ZMQ") say?
>

v"0.3.0"

FYI, I tried to update everything, e.g. 

$ brew update
$ brew upgrade
julia> Pkg.update()
julia> Pkg.build("IJulia")
$ pip list --outdated 
$ pip install -U 

etc.  Not sure why I sometimes need to do a Pkg.build() e.g. with IJulia. 
 Does ZMQ require a build() also?

 

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Art Kuo]

I've coded up a simple replacement to the show() function for ranges. The 
idea is to give the user information more likely to be what they are 
wondering. Here are some examples of its output:

*julia> **0:4*

*5-element UnitRange{Int64}:*

*0,1,2,3,4*


*julia> **0:10*

*11-element UnitRange{Int64}:*

*0,1,2,…,9,10*


*julia> **0:2:20*

*11-element StepRange{Int64,Int64}:*

*0,2,4,…,18,20*


*julia> **linspace(0,4,7)*

*7-element LinSpace{Float64}:*

*0.0,0.67,1.3,…,3.3,4.0*


Any thoughts on this arrangement? The output differs from collect() in that 
I've arranged elements in a compact row. Also I've assumed that it's 
sufficient to print out only the first three elements, and the last two, 
because the user should be able to figure it out from there. A possible 
point of confusion is "7-element" which isn't actually true of the Range 
object. Would it be better to output "7-length" or something else?

Re: [julia-users] DataFrames' readtable very slow compared to R's read.csv when loading ~7.6M csv rows

[bernhard]

Thank you Quinn

Things do not work (for me) though.

is it possible you are missing a comma after "col" in lines 24 and 33 of 
Sink.jl
function writefield(io::Sink, val::AbstractString, col N)



Am Mittwoch, 7. Oktober 2015 16:36:52 UTC+2 schrieb David Gold:
>
> Yaas. Very excited to see this.
>
> On Wednesday, October 7, 2015 at 6:07:44 AM UTC-7, Jacob Quinn wrote:
>>
>> Haha, nice timing. I just pushed a big CSV.jl overhaul for 0.4 yesterday 
>> afternoon. I just pushed the DataStreams.jl package, so you can find that 
>> at https://github.com/quinnj/DataStreams.jl, and you'll have to 
>> Pkg.clone it. Everything should work at that point.
>>
>> I'm still cleaning up some other related packages, so that's why things 
>> aren't documented/registered/tagged quite yet as the interface may evolve 
>> slightly, probably more the low-level machinery. So `stream!(::CSV.Source, 
>> ::DataStream)` should stay the same.
>>
>> I've already got a bit writeup started once everything's done, so if 
>> you'd rather wait another couple days or a week, I should have something 
>> ready by then.
>>
>> -Jacob
>>
>> On Wed, Oct 7, 2015 at 12:33 AM, bernhard  wrote:
>>
>>> Is there any update on this? Or maybe a timeline/roadmap?
>>> I would love to see a faster CSV reader. 
>>>
>>> I tried to take a look at Jacob's CSV.jl.
>>> But I seem to be missing https://github.com/lindahua/DataStreams.jl 
>>> I have no idea where to find DataStreams package
>>> Does it still exist?
>>>
>>> Is there any (experimental) way to make CSV.jl work?
>>>
>>>
>>>
 Am Samstag, 6. Juni 2015 14:41:36 UTC+2 schrieb David Gold:

 @Jacob,

 Thank you very much for your explanation! I expect having such a 
 blueprint will make delving into the actual code more tractable for me. 
 I'll be curious to see how your solution here and your proposal for string 
 handling end up playing with the current Julia data ecosystem. 

 On Saturday, June 6, 2015 at 1:17:34 AM UTC-4, Jacob Quinn wrote:
>
> @David,
>
> Sorry for the slow response. It's been a busy week :)
>
> Here's a quick rundown of the approach:
>
> - In the still-yet-to-be-officially-published 
> https://github.com/quinnj/CSV.jl package, the bulk of the code goes 
> into creating a `CSV.File` type where the structure/metadata of the file 
> is 
> parsed/detected/saved in a type (e.g. header, delimiter, newline, # of 
> columns, detected column types, etc.)
> - `SQLite.create` and now `CSV.read` both take a `CSV.File` as input 
> and follow a similar process in parsing:
>   - The actual file contents are mmapped; i.e. the entire file is 
> loaded into memory at once
>   - There are currently three `readfield` methods (Int,Float64,String) 
> that take an open `CSV.Stream` type (which holds the mmapped data and the 
> current "position" of parsing), and read a single field according to what 
> the type of that column is supposed to be
>   - for example, readfield(io::CSV.Stream, ::Type{Float64}, row, 
> col), will start reading at the current position of the `CSV.Stream` 
> until 
> it hits the next delimiter, newline, or end of the file and then 
> interpret 
> the contents as a Float64, returning `val, isnull`
>
> That's pretty much it. One of the most critical performance keys for 
> both SQLite and CSV.read is non-copying strings once the file has been 
> mmapped. For SQLite, the sqlite3_bind_text library method actually has a 
> flag to indicate whether the text should be copied or not, so we're able 
> to 
> pass the pointer to the position in the mmapped array directly. For the 
> CSV.read method, which returns a Vector of the columns (as typed arrays), 
> I've actually rolled a quick and dirty CString type that looks like
>
> immutable CString
>   ptr::Ptr{UInt8}
>   len::Int
> end
>
> With a few extra method definitions, this type looks very close to a 
> real string type, but we can construct it by pointing directly to the 
> mmapped region (which currently isn't possible for native Julia string 
> types). See https://github.com/quinnj/Strings.jl for more 
> brainstorming around this alternative string implementation. You can 
> convert a CString to a Julia string by calling string(x::CString) or 
> map(string,column) for an Array of CSV.CStrings.
>
> As an update on the performance on the Facebook Kaggle competition 
> bids.csv file:
>
> -readcsv: 45 seconds, 33% gc time
> -CSV.read: 19 seconds, 3% gc time
> -SQLite.create: 25 seconds, 3.25% gc time
>
> Anyway, hopefully I'll get around to cleaning up CSV.jl to be released 
> officially, but it's that last 10-20% that's always the hardest to finish 
> up :)
>
> -Jacob
>
>
>
> On Mon, Jun 1, 2015 at 4:25 PM, David 

Re: [julia-users] adding new method for $ is not allowed, while adding for + is fine

[cheng wang]

Thanks a lot, as well as Matt Bauman.

On Wednesday, October 7, 2015 at 9:11:50 PM UTC+2, Stefan Karpinski wrote:
>
> $ is used for expression interpolation (see metaprogramming in the 
> manual), so you need the parens to make it clear that you're not trying to 
> do interpolation.
>
> On Wednesday, October 7, 2015, cheng wang  
> wrote:
>
>> Thanks. Still, why + and $ are different in this case ?
>>
>> On Wednesday, October 7, 2015 at 9:05:10 PM UTC+2, Seth wrote:
>>>
>>> Surround it by parens:
>>>
>>> julia> ($)(x::Int, y::Int) = x+y+5
>>> ...
>>> julia> ($)(5,7)
>>> 17
>>>
>>> On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:

 Hello everyone,

 I try to do $(x,y)=something, it says: syntax: invalid assignment 
 location
 while +(x,y)=something is ok.

 Is there any speciality of $ operator?

 Best,
 Cheng

>>>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Steven G. Johnson]

On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>
> I don't see why it is bad to support more styles if there is no harm to 
> the original one.
>

Because code that mixes multiple styles is harder to read (imagine reading 
a document that jumps back and forth between different spellings), harder 
to share (because other Julia programmers won't know your idiosyncratic 
style), and harder to combine with other features of the language (as 
others have said, multiple dispatch is central to Julia's design and 
central to the design of the standard library).

This comes up with every new programming language, which is why it is 
useful to learn from history.

[julia-users] Re: StackOverflow error while attempting to "lift" Nullables

[Data Pulverizer]

Great advice. Thanks.

[julia-users] Re: Ambiguous methods warning method

[andy hayden]

see https://github.com/JuliaStats/DataArrays.jl/issues/168

On Wednesday, 7 October 2015 08:03:12 UTC-7, cormu...@mac.com wrote:
>
> Assuming this is the correct behavior, is there a way to get a better user 
> experience:
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.0-rc4 (2015-10-04 03:14 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-apple-darwin13.4.0
>
> julia> using Colors, Images, Gadfly
> WARNING: New definition
> -(DataArrays.DataArray, AbstractArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
> is ambiguous with:
> -(AbstractArray, Images.AbstractImageDirect) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:37.
> To fix, define
> -(DataArrays.DataArray, Images.AbstractImageDirect)
> before the new definition.
> WARNING: New definition
> -(AbstractArray, DataArrays.DataArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
> is ambiguous with:
> -(Images.AbstractImageDirect, AbstractArray) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:35.
> To fix, define
> -(Images.AbstractImageDirect, DataArrays.DataArray)
> before the new definition.
> WARNING: New definition
> -(DataArrays.AbstractDataArray, AbstractArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
> is ambiguous with:
> -(AbstractArray, Images.AbstractImageDirect) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:37.
> To fix, define
> -(DataArrays.AbstractDataArray, Images.AbstractImageDirect)
> before the new definition.
> WARNING: New definition
> -(AbstractArray, DataArrays.AbstractDataArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
> is ambiguous with:
> -(Images.AbstractImageDirect, AbstractArray) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:35.
> To fix, define
> -(Images.AbstractImageDirect, DataArrays.AbstractDataArray)
> before the new definition.
> WARNING: New definition
> .==(AbstractArray{Bool, N<:Any}, Union{DataArrays.DataArray{Bool, 
> N<:Any}, DataArrays.PooledDataArray{Bool, R<:Integer, N<:Any}}) at 
> /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:317
> is ambiguous with:
> .==(Images.AbstractImageDirect{Bool, N<:Any}, AbstractArray{Bool, 
> N<:Any}) at /Users/me/.julia/v0.4/Images/src/algorithms.jl:133.
> To fix, define
> .==(Images.AbstractImageDirect{Bool, N<:Any}, 
> Union{DataArrays.DataArray{Bool, N<:Any}, DataArrays.PooledDataArray{Bool, 
> R<:Integer, N<:Any}})
> before the new definition.
> WARNING: New definition
> .==(AbstractArray, Union{DataArrays.DataArray, 
> DataArrays.PooledDataArray}) at 
> /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:272
> is ambiguous with:
> .==(Images.AbstractImageDirect{Bool, N<:Any}, AbstractArray{Bool, 
> N<:Any}) at /Users/me/.julia/v0.4/Images/src/algorithms.jl:133.
> To fix, define
> .==(Images.AbstractImageDirect{Bool, N<:Any}, 
> Union{DataArrays.DataArray{Bool, N<:Any}, DataArrays.PooledDataArray{Bool, 
> R<:Integer, N<:Any}})
> before the new definition.
> WARNING: New definition
> .==(AbstractArray, Union{DataArrays.DataArray, 
> DataArrays.PooledDataArray}) at 
> /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:272
> is ambiguous with:
> .==(Images.AbstractImageDirect, AbstractArray) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:134.
> To fix, define
> .==(Images.AbstractImageDirect, Union{DataArrays.DataArray, 
> DataArrays.PooledDataArray})
> before the new definition.
> WARNING: New definition
> +(AbstractArray, DataArrays.DataArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
> is ambiguous with:
> +(Images.AbstractImageDirect, AbstractArray) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:18.
> To fix, define
> +(Images.AbstractImageDirect, DataArrays.DataArray)
> before the new definition.
> WARNING: New definition
> +(AbstractArray, DataArrays.AbstractDataArray) at 
> /Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
> is ambiguous with:
> +(Images.AbstractImageDirect, AbstractArray) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:18.
> To fix, define
> +(Images.AbstractImageDirect, DataArrays.AbstractDataArray)
> before the new definition.
> WARNING: New definition
> .*(Union{DataArrays.DataArray, DataArrays.PooledDataArray}, 
> AbstractArray...) at /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:282
> is ambiguous with:
> .*(AbstractArray, Images.AbstractImageDirect) at 
> /Users/me/.julia/v0.4/Images/src/algorithms.jl:52.
> To fix, define
>   

Re: [julia-users] Re: Implementing mapreduce parallel model (not general multi-threading) ? easy and enough ?

[Steven Sagaert]

I think what is meant is that in HPC typically this is done via MPI which 
is just a low level approach where you explicitely have to specify all the 
data communication (compared to Hadoop & Spark where it is implicit).

>
>
>  The only codes that really nail it are carefully handcrafted HPC codes.
>
>
> Could you please elaborate on this? I think I know Spark code quite well, 
> but can't connect it to the notion of handcrafted HPC code. 
>
>
>
>
>>

[julia-users] Re: The status of Julia's Webstack

[Randy Zwitch]

I'm sure if you submitted a pull request to any of the packages mentioned 
to fix the holes, it would be accepted with open arms.

On Tuesday, October 6, 2015 at 5:05:10 PM UTC-4, Mohammed El-Beltagy wrote:
>
> It seems that Morsel.jl and Meddle.jl are quietly dieing away. I noticed 
> that after I did Pkg.update and found that my previously working code is is 
> now failing. Looking that the repositories on github, I noticed that both 
> have been failing their tests. I had to pin down Morsel, Meddle, 
> HttpCommon, HttpServer, and HttpParser to earlier versions to keep my 
> server running. 
>
> There claimed replacement "Mux.jl" is morel like Meddle and can to be 
> regarded as a micro framework. This leaves a significant hole in Julia's 
> package echo system. I wonder if there are any attempts to fill that hole. 
>

[julia-users] Re: Implementing mapreduce parallel model (not general multi-threading) ? easy and enough ?

[cheng wang]

Thx a lot. You saved my life :)

On Wednesday, October 7, 2015 at 3:00:25 PM UTC+2, Jonathan Malmaud wrote:
>
> Within the next few days, support for native threads will be merged into 
> to the development version of Julia (
> https://github.com/JuliaLang/julia/pull/13410 
> 
> ).
>
> You can also used the SharedArray type which Julia already has, which lets 
> multiple Julia processes running on the same machine share memory. You 
> would use the standard Julia task-parallel tools (like @parfor, etc.) in 
> that model. 
>
> On Wednesday, October 7, 2015 at 8:34:02 AM UTC-4, cheng wang wrote:
>>
>> Thanks all for replying.
>>
>> I have read th parallel computing document before I post this.
>> Actually, what I mean is a shared memory model not a distributed model.
>>
>> My daily research involves extensively using of blas and parallel 
>> for-loop.
>> Julia has a perfect support for blas, as well parallel for-loop could be 
>> solved by multi-process.
>>
>> However, if I want to have a shared array that could do efficient blast 
>> and parallel for-loop in the same time,
>> what is the best solution ??
>>
>>
>> On Tuesday, October 6, 2015 at 4:24:51 PM UTC+2, Andrei Zh wrote:
>>>
>>> Julia supports multiprocessing pretty well, including map-reduce-like 
>>> jobs. E.g. in the next example I add 3 processes to a "workgroup", 
>>> distribute simulation between them and then reduce results via (+) operator:
>>>
>>>
>>> julia> addprocs(3)
>>> 3-element Array{Int64,1}:
>>>  2
>>>  3
>>>  4
>>>
>>>
>>> julia> nheads = @parallel (+) for i=1:2
>>>  Int(rand(Bool))
>>>end
>>> 18845
>>>
>>> You can find full example and a lot of other fun in official 
>>> documentation on parallel computing: 
>>>
>>> http://julia.readthedocs.org/en/latest/manual/parallel-computing/
>>>
>>> Note, though, that it's not real (i.e. Hadoop/Spark-like) map-reduce, 
>>> since original idea of MR concerns distributed systems and data-local 
>>> computations, while here we do everything on the same machine. If you are 
>>> looking for big data solution, search this forum for some (dead or alive) 
>>> projects for it. 
>>>
>>>
>>>
>>> On Monday, October 5, 2015 at 11:52:21 PM UTC+3, cheng wang wrote:

 Hello everyone,

 I am a Julia newbie. I am thrilled by Julia recently. It's an amazing 
 language!

 I notice that julia currently does not have good support for 
 multi-threading programming.
 So I am thinking that a spark-like mapreduce parallel model + 
 multi-process maybe enough.
 It is easy to be thread-safe and It could solve most vector-based 
 computation.

 This idea might be too naive. However, I am happy to see your opinions.

 Thanks in advance,
 Cheng

>>>

[julia-users] Re: Implementing mapreduce parallel model (not general multi-threading) ? easy and enough ?

[cheng wang]

Thanks all for replying.

I have read th parallel computing document before I post this.
Actually, what I mean is a shared memory model not a distributed model.

My daily research involves extensively using of blas and parallel for-loop.
Julia has a perfect support for blas, as well parallel for-loop could be 
solved by multi-process.

However, if I want to have a shared array that could do efficient blast and 
parallel for-loop in the same time,
what is the best solution ??


On Tuesday, October 6, 2015 at 4:24:51 PM UTC+2, Andrei Zh wrote:
>
> Julia supports multiprocessing pretty well, including map-reduce-like 
> jobs. E.g. in the next example I add 3 processes to a "workgroup", 
> distribute simulation between them and then reduce results via (+) operator:
>
>
> julia> addprocs(3)
> 3-element Array{Int64,1}:
>  2
>  3
>  4
>
>
> julia> nheads = @parallel (+) for i=1:2
>  Int(rand(Bool))
>end
> 18845
>
> You can find full example and a lot of other fun in official documentation 
> on parallel computing: 
>
> http://julia.readthedocs.org/en/latest/manual/parallel-computing/
>
> Note, though, that it's not real (i.e. Hadoop/Spark-like) map-reduce, 
> since original idea of MR concerns distributed systems and data-local 
> computations, while here we do everything on the same machine. If you are 
> looking for big data solution, search this forum for some (dead or alive) 
> projects for it. 
>
>
>
> On Monday, October 5, 2015 at 11:52:21 PM UTC+3, cheng wang wrote:
>>
>> Hello everyone,
>>
>> I am a Julia newbie. I am thrilled by Julia recently. It's an amazing 
>> language!
>>
>> I notice that julia currently does not have good support for 
>> multi-threading programming.
>> So I am thinking that a spark-like mapreduce parallel model + 
>> multi-process maybe enough.
>> It is easy to be thread-safe and It could solve most vector-based 
>> computation.
>>
>> This idea might be too naive. However, I am happy to see your opinions.
>>
>> Thanks in advance,
>> Cheng
>>
>

Re: [julia-users] DataFrames' readtable very slow compared to R's read.csv when loading ~7.6M csv rows

[Jonathan Malmaud]

Independent of Jacob's (excellent) work, I've begun wrapping the SFrames 
library (https://github.com/dato-code/SFrame), which is used internally by 
Graphlab Create (https://dato.com/products/create/). One of its features is 
a fast and robust CSV reader. I think I'll have something to preview in the 
next week or so.

On Wednesday, October 7, 2015 at 2:33:41 AM UTC-4, bernhard wrote:
>
> Is there any update on this? Or maybe a timeline/roadmap?
> I would love to see a faster CSV reader. 
>
> I tried to take a look at Jacob's CSV.jl.
> But I seem to be missing https://github.com/lindahua/DataStreams.jl 
> I have no idea where to find DataStreams package
> Does it still exist?
>
> Is there any (experimental) way to make CSV.jl work?
>
>
>
>> Am Samstag, 6. Juni 2015 14:41:36 UTC+2 schrieb David Gold:
>>
>> @Jacob,
>>
>> Thank you very much for your explanation! I expect having such a 
>> blueprint will make delving into the actual code more tractable for me. 
>> I'll be curious to see how your solution here and your proposal for string 
>> handling end up playing with the current Julia data ecosystem. 
>>
>> On Saturday, June 6, 2015 at 1:17:34 AM UTC-4, Jacob Quinn wrote:
>>>
>>> @David,
>>>
>>> Sorry for the slow response. It's been a busy week :)
>>>
>>> Here's a quick rundown of the approach:
>>>
>>> - In the still-yet-to-be-officially-published 
>>> https://github.com/quinnj/CSV.jl package, the bulk of the code goes 
>>> into creating a `CSV.File` type where the structure/metadata of the file is 
>>> parsed/detected/saved in a type (e.g. header, delimiter, newline, # of 
>>> columns, detected column types, etc.)
>>> - `SQLite.create` and now `CSV.read` both take a `CSV.File` as input and 
>>> follow a similar process in parsing:
>>>   - The actual file contents are mmapped; i.e. the entire file is loaded 
>>> into memory at once
>>>   - There are currently three `readfield` methods (Int,Float64,String) 
>>> that take an open `CSV.Stream` type (which holds the mmapped data and the 
>>> current "position" of parsing), and read a single field according to what 
>>> the type of that column is supposed to be
>>>   - for example, readfield(io::CSV.Stream, ::Type{Float64}, row, 
>>> col), will start reading at the current position of the `CSV.Stream` until 
>>> it hits the next delimiter, newline, or end of the file and then interpret 
>>> the contents as a Float64, returning `val, isnull`
>>>
>>> That's pretty much it. One of the most critical performance keys for 
>>> both SQLite and CSV.read is non-copying strings once the file has been 
>>> mmapped. For SQLite, the sqlite3_bind_text library method actually has a 
>>> flag to indicate whether the text should be copied or not, so we're able to 
>>> pass the pointer to the position in the mmapped array directly. For the 
>>> CSV.read method, which returns a Vector of the columns (as typed arrays), 
>>> I've actually rolled a quick and dirty CString type that looks like
>>>
>>> immutable CString
>>>   ptr::Ptr{UInt8}
>>>   len::Int
>>> end
>>>
>>> With a few extra method definitions, this type looks very close to a 
>>> real string type, but we can construct it by pointing directly to the 
>>> mmapped region (which currently isn't possible for native Julia string 
>>> types). See https://github.com/quinnj/Strings.jl for more brainstorming 
>>> around this alternative string implementation. You can convert a CString to 
>>> a Julia string by calling string(x::CString) or map(string,column) for an 
>>> Array of CSV.CStrings.
>>>
>>> As an update on the performance on the Facebook Kaggle competition 
>>> bids.csv file:
>>>
>>> -readcsv: 45 seconds, 33% gc time
>>> -CSV.read: 19 seconds, 3% gc time
>>> -SQLite.create: 25 seconds, 3.25% gc time
>>>
>>> Anyway, hopefully I'll get around to cleaning up CSV.jl to be released 
>>> officially, but it's that last 10-20% that's always the hardest to finish 
>>> up :)
>>>
>>> -Jacob
>>>
>>>
>>>
>>> On Mon, Jun 1, 2015 at 4:25 PM, David Gold  wrote:
>>>
 @Jacob I'm just developing a working understanding of these issues. 
 Would you please help me to get a better handle on your solution?

 My understanding thus far: Reading a (local) .csv file into a DataFrame 
 using DataFrames.readtable involves reading the file into an IOStream and 
 then parsing that stream into a form amenable to parsing by 
 DataFrames.builddf, which builds the DataFrame object returned by 
 readtable. The work required to get the contents of the .csv file into 
 memory in a form that can be manipulated by Julia functions is 
 work-intensive in this manner. However, with SQLite, the entire file can 
 just be thrown into memory wholesale, along with some metadata (maybe not 
 the right term?) that delineates the tabular properties of the data. 

 What I am curious about, then (if this understanding is not too 
 misguided), is how SQLite returns, say, a column of 

Re: [julia-users] DataFrames' readtable very slow compared to R's read.csv when loading ~7.6M csv rows

[Jacob Quinn]

Haha, nice timing. I just pushed a big CSV.jl overhaul for 0.4 yesterday
afternoon. I just pushed the DataStreams.jl package, so you can find that
at https://github.com/quinnj/DataStreams.jl, and you'll have to Pkg.clone
it. Everything should work at that point.

I'm still cleaning up some other related packages, so that's why things
aren't documented/registered/tagged quite yet as the interface may evolve
slightly, probably more the low-level machinery. So `stream!(::CSV.Source,
::DataStream)` should stay the same.

I've already got a bit writeup started once everything's done, so if you'd
rather wait another couple days or a week, I should have something ready by
then.

-Jacob

On Wed, Oct 7, 2015 at 12:33 AM, bernhard  wrote:

> Is there any update on this? Or maybe a timeline/roadmap?
> I would love to see a faster CSV reader.
>
> I tried to take a look at Jacob's CSV.jl.
> But I seem to be missing https://github.com/lindahua/DataStreams.jl
> I have no idea where to find DataStreams package
> Does it still exist?
>
> Is there any (experimental) way to make CSV.jl work?
>
>
>
>> Am Samstag, 6. Juni 2015 14:41:36 UTC+2 schrieb David Gold:
>>
>> @Jacob,
>>
>> Thank you very much for your explanation! I expect having such a
>> blueprint will make delving into the actual code more tractable for me.
>> I'll be curious to see how your solution here and your proposal for string
>> handling end up playing with the current Julia data ecosystem.
>>
>> On Saturday, June 6, 2015 at 1:17:34 AM UTC-4, Jacob Quinn wrote:
>>>
>>> @David,
>>>
>>> Sorry for the slow response. It's been a busy week :)
>>>
>>> Here's a quick rundown of the approach:
>>>
>>> - In the still-yet-to-be-officially-published
>>> https://github.com/quinnj/CSV.jl package, the bulk of the code goes
>>> into creating a `CSV.File` type where the structure/metadata of the file is
>>> parsed/detected/saved in a type (e.g. header, delimiter, newline, # of
>>> columns, detected column types, etc.)
>>> - `SQLite.create` and now `CSV.read` both take a `CSV.File` as input and
>>> follow a similar process in parsing:
>>>   - The actual file contents are mmapped; i.e. the entire file is loaded
>>> into memory at once
>>>   - There are currently three `readfield` methods (Int,Float64,String)
>>> that take an open `CSV.Stream` type (which holds the mmapped data and the
>>> current "position" of parsing), and read a single field according to what
>>> the type of that column is supposed to be
>>>   - for example, readfield(io::CSV.Stream, ::Type{Float64}, row,
>>> col), will start reading at the current position of the `CSV.Stream` until
>>> it hits the next delimiter, newline, or end of the file and then interpret
>>> the contents as a Float64, returning `val, isnull`
>>>
>>> That's pretty much it. One of the most critical performance keys for
>>> both SQLite and CSV.read is non-copying strings once the file has been
>>> mmapped. For SQLite, the sqlite3_bind_text library method actually has a
>>> flag to indicate whether the text should be copied or not, so we're able to
>>> pass the pointer to the position in the mmapped array directly. For the
>>> CSV.read method, which returns a Vector of the columns (as typed arrays),
>>> I've actually rolled a quick and dirty CString type that looks like
>>>
>>> immutable CString
>>>   ptr::Ptr{UInt8}
>>>   len::Int
>>> end
>>>
>>> With a few extra method definitions, this type looks very close to a
>>> real string type, but we can construct it by pointing directly to the
>>> mmapped region (which currently isn't possible for native Julia string
>>> types). See https://github.com/quinnj/Strings.jl for more brainstorming
>>> around this alternative string implementation. You can convert a CString to
>>> a Julia string by calling string(x::CString) or map(string,column) for an
>>> Array of CSV.CStrings.
>>>
>>> As an update on the performance on the Facebook Kaggle competition
>>> bids.csv file:
>>>
>>> -readcsv: 45 seconds, 33% gc time
>>> -CSV.read: 19 seconds, 3% gc time
>>> -SQLite.create: 25 seconds, 3.25% gc time
>>>
>>> Anyway, hopefully I'll get around to cleaning up CSV.jl to be released
>>> officially, but it's that last 10-20% that's always the hardest to finish
>>> up :)
>>>
>>> -Jacob
>>>
>>>
>>>
>>> On Mon, Jun 1, 2015 at 4:25 PM, David Gold  wrote:
>>>
 @Jacob I'm just developing a working understanding of these issues.
 Would you please help me to get a better handle on your solution?

 My understanding thus far: Reading a (local) .csv file into a DataFrame
 using DataFrames.readtable involves reading the file into an IOStream and
 then parsing that stream into a form amenable to parsing by
 DataFrames.builddf, which builds the DataFrame object returned by
 readtable. The work required to get the contents of the .csv file into
 memory in a form that can be manipulated by Julia functions is
 work-intensive in this manner. 

Re: [julia-users] Convert ASCIIString to Cmd and use run()

[Yichao Yu]

On Wed, Oct 7, 2015 at 8:20 AM, Matej Krejci  wrote:
> Hello,

I don't see the error you get

>
> I am trying to build a string and run it by standard function run().
> args=AbstractString[]

The line above is useless

> args=["arg1","arg2"]
> jargs=join(args," ")

You don't join all the arguments with " "

> path="/grass_trunk/general/g.parser"
> run(`$path $jargs`)
>

instead, try `run(`$path $(args...)`)`

>
> ERROR: LoadError: TypeError: anonymous: in new, expected Function, got
> ASCIIString
>  [inlined code] from test.jl:59
>  in anonymous at no file:58
>  in include at ./boot.jl:261
>  in include_from_node1 at ./loading.jl:304
>  in process_options at ./client.jl:275
>  in _start at ./client.jl:375
> I cannot figure out how to convert ASCIIString to Cmd and execute it by
> run() standard function.
>
> thanks for any idea
> best
> Matej

[julia-users] Re: Implementing mapreduce parallel model (not general multi-threading) ? easy and enough ?

[Jonathan Malmaud]

Within the next few days, support for native threads will be merged into to 
the development version of Julia 
(https://github.com/JuliaLang/julia/pull/13410).

You can also used the SharedArray type which Julia already has, which lets 
multiple Julia processes running on the same machine share memory. You 
would use the standard Julia task-parallel tools (like @parfor, etc.) in 
that model. 

On Wednesday, October 7, 2015 at 8:34:02 AM UTC-4, cheng wang wrote:
>
> Thanks all for replying.
>
> I have read th parallel computing document before I post this.
> Actually, what I mean is a shared memory model not a distributed model.
>
> My daily research involves extensively using of blas and parallel for-loop.
> Julia has a perfect support for blas, as well parallel for-loop could be 
> solved by multi-process.
>
> However, if I want to have a shared array that could do efficient blast 
> and parallel for-loop in the same time,
> what is the best solution ??
>
>
> On Tuesday, October 6, 2015 at 4:24:51 PM UTC+2, Andrei Zh wrote:
>>
>> Julia supports multiprocessing pretty well, including map-reduce-like 
>> jobs. E.g. in the next example I add 3 processes to a "workgroup", 
>> distribute simulation between them and then reduce results via (+) operator:
>>
>>
>> julia> addprocs(3)
>> 3-element Array{Int64,1}:
>>  2
>>  3
>>  4
>>
>>
>> julia> nheads = @parallel (+) for i=1:2
>>  Int(rand(Bool))
>>end
>> 18845
>>
>> You can find full example and a lot of other fun in official 
>> documentation on parallel computing: 
>>
>> http://julia.readthedocs.org/en/latest/manual/parallel-computing/
>>
>> Note, though, that it's not real (i.e. Hadoop/Spark-like) map-reduce, 
>> since original idea of MR concerns distributed systems and data-local 
>> computations, while here we do everything on the same machine. If you are 
>> looking for big data solution, search this forum for some (dead or alive) 
>> projects for it. 
>>
>>
>>
>> On Monday, October 5, 2015 at 11:52:21 PM UTC+3, cheng wang wrote:
>>>
>>> Hello everyone,
>>>
>>> I am a Julia newbie. I am thrilled by Julia recently. It's an amazing 
>>> language!
>>>
>>> I notice that julia currently does not have good support for 
>>> multi-threading programming.
>>> So I am thinking that a spark-like mapreduce parallel model + 
>>> multi-process maybe enough.
>>> It is easy to be thread-safe and It could solve most vector-based 
>>> computation.
>>>
>>> This idea might be too naive. However, I am happy to see your opinions.
>>>
>>> Thanks in advance,
>>> Cheng
>>>
>>

[julia-users] Re: The status of Julia's Webstack

[Jonathan Malmaud]

Mux and Morsel are formally deprecated at this point and have no 
maintainers. They were designed early on in Julia's life and don't have a 
design that is particularly suited for modern Julia, so the maintainers of 
JuliaWeb made a decision to not invest time in keeping them operational.

That said, Randy is right that I would still merge PRs for them.  

On Tuesday, October 6, 2015 at 5:05:10 PM UTC-4, Mohammed El-Beltagy wrote:
>
> It seems that Morsel.jl and Meddle.jl are quietly dieing away. I noticed 
> that after I did Pkg.update and found that my previously working code is is 
> now failing. Looking that the repositories on github, I noticed that both 
> have been failing their tests. I had to pin down Morsel, Meddle, 
> HttpCommon, HttpServer, and HttpParser to earlier versions to keep my 
> server running. 
>
> There claimed replacement "Mux.jl" is morel like Meddle and can to be 
> regarded as a micro framework. This leaves a significant hole in Julia's 
> package echo system. I wonder if there are any attempts to fill that hole. 
>

[julia-users] Re: Light table can't connect to Julia

[Oscar Neciosup]

Hello friend, For that case, you need to edit , update or download some 
packages from Julia REPL . 
Check whether the versions are installed, use  
Pkg.status ():

Jewel v1.0.5 
Compat v 0.7.0 
Requires v0.1.3 .

I'm working well with these versions of packages.

[julia-users] Convert ASCIIString to Cmd and use run()

[Matej Krejci]

Hello,

I am trying to build a string and run it by standard function run(). 
args=AbstractString[]
args=["arg1","arg2"]
jargs=join(args," ")
path="/grass_trunk/general/g.parser"
run(`$path $jargs`)


ERROR: LoadError: TypeError: anonymous: in new, expected Function, got 
ASCIIString
 [inlined code] from test.jl:59
 in anonymous at no file:58
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in process_options at ./client.jl:275
 in _start at ./client.jl:375
I cannot figure out how to convert ASCIIString to Cmd and execute it by 
run() standard function.

thanks for any idea
best 
Matej

Re: [julia-users] Re: The status of Julia's Webstack

[Jonathan Malmaud]

Yes, thanks for the correction.
On Wed, Oct 7, 2015 at 10:37 AM Jacob Quinn  wrote:

> Jon,
>
> I think you mean Morsel and Meddle are deprecated? While Mux is actually
> maintained?
>
> On Wed, Oct 7, 2015 at 7:04 AM, Jonathan Malmaud 
> wrote:
>
>> Mux and Morsel are formally deprecated at this point and have no
>> maintainers. They were designed early on in Julia's life and don't have a
>> design that is particularly suited for modern Julia, so the maintainers of
>> JuliaWeb made a decision to not invest time in keeping them operational.
>>
>> That said, Randy is right that I would still merge PRs for them.
>>
>> On Tuesday, October 6, 2015 at 5:05:10 PM UTC-4, Mohammed El-Beltagy
>> wrote:
>>>
>>> It seems that Morsel.jl and Meddle.jl are quietly dieing away. I noticed
>>> that after I did Pkg.update and found that my previously working code is is
>>> now failing. Looking that the repositories on github, I noticed that both
>>> have been failing their tests. I had to pin down Morsel, Meddle,
>>> HttpCommon, HttpServer, and HttpParser to earlier versions to keep my
>>> server running.
>>>
>>> There claimed replacement "Mux.jl" is morel like Meddle and can to be
>>> regarded as a micro framework. This leaves a significant hole in Julia's
>>> package echo system. I wonder if there are any attempts to fill that hole.
>>>
>>
>

[julia-users] Ambiguous methods warning method

[cormullion]

Assuming this is the correct behavior, is there a way to get a better user 
experience:

   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-rc4 (2015-10-04 03:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-apple-darwin13.4.0

julia> using Colors, Images, Gadfly
WARNING: New definition
-(DataArrays.DataArray, AbstractArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
is ambiguous with:
-(AbstractArray, Images.AbstractImageDirect) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:37.
To fix, define
-(DataArrays.DataArray, Images.AbstractImageDirect)
before the new definition.
WARNING: New definition
-(AbstractArray, DataArrays.DataArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
is ambiguous with:
-(Images.AbstractImageDirect, AbstractArray) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:35.
To fix, define
-(Images.AbstractImageDirect, DataArrays.DataArray)
before the new definition.
WARNING: New definition
-(DataArrays.AbstractDataArray, AbstractArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
is ambiguous with:
-(AbstractArray, Images.AbstractImageDirect) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:37.
To fix, define
-(DataArrays.AbstractDataArray, Images.AbstractImageDirect)
before the new definition.
WARNING: New definition
-(AbstractArray, DataArrays.AbstractDataArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
is ambiguous with:
-(Images.AbstractImageDirect, AbstractArray) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:35.
To fix, define
-(Images.AbstractImageDirect, DataArrays.AbstractDataArray)
before the new definition.
WARNING: New definition
.==(AbstractArray{Bool, N<:Any}, Union{DataArrays.DataArray{Bool, 
N<:Any}, DataArrays.PooledDataArray{Bool, R<:Integer, N<:Any}}) at 
/Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:317
is ambiguous with:
.==(Images.AbstractImageDirect{Bool, N<:Any}, AbstractArray{Bool, 
N<:Any}) at /Users/me/.julia/v0.4/Images/src/algorithms.jl:133.
To fix, define
.==(Images.AbstractImageDirect{Bool, N<:Any}, 
Union{DataArrays.DataArray{Bool, N<:Any}, DataArrays.PooledDataArray{Bool, 
R<:Integer, N<:Any}})
before the new definition.
WARNING: New definition
.==(AbstractArray, Union{DataArrays.DataArray, 
DataArrays.PooledDataArray}) at 
/Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:272
is ambiguous with:
.==(Images.AbstractImageDirect{Bool, N<:Any}, AbstractArray{Bool, 
N<:Any}) at /Users/me/.julia/v0.4/Images/src/algorithms.jl:133.
To fix, define
.==(Images.AbstractImageDirect{Bool, N<:Any}, 
Union{DataArrays.DataArray{Bool, N<:Any}, DataArrays.PooledDataArray{Bool, 
R<:Integer, N<:Any}})
before the new definition.
WARNING: New definition
.==(AbstractArray, Union{DataArrays.DataArray, 
DataArrays.PooledDataArray}) at 
/Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:272
is ambiguous with:
.==(Images.AbstractImageDirect, AbstractArray) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:134.
To fix, define
.==(Images.AbstractImageDirect, Union{DataArrays.DataArray, 
DataArrays.PooledDataArray})
before the new definition.
WARNING: New definition
+(AbstractArray, DataArrays.DataArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:326
is ambiguous with:
+(Images.AbstractImageDirect, AbstractArray) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:18.
To fix, define
+(Images.AbstractImageDirect, DataArrays.DataArray)
before the new definition.
WARNING: New definition
+(AbstractArray, DataArrays.AbstractDataArray) at 
/Users/me/.julia/v0.4/DataArrays/src/operators.jl:349
is ambiguous with:
+(Images.AbstractImageDirect, AbstractArray) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:18.
To fix, define
+(Images.AbstractImageDirect, DataArrays.AbstractDataArray)
before the new definition.
WARNING: New definition
.*(Union{DataArrays.DataArray, DataArrays.PooledDataArray}, 
AbstractArray...) at /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:282
is ambiguous with:
.*(AbstractArray, Images.AbstractImageDirect) at 
/Users/me/.julia/v0.4/Images/src/algorithms.jl:52.
To fix, define
.*(Union{DataArrays.DataArray, DataArrays.PooledDataArray}, 
Images.AbstractImageDirect)
before the new definition.
WARNING: New definition
.*(AbstractArray, Union{DataArrays.DataArray, 
DataArrays.PooledDataArray}, AbstractArray...) at 
/Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:282
is ambiguous with:

[julia-users] Re: Convert ASCIIString to Cmd and use run()

[Steven G. Johnson]

On Wednesday, October 7, 2015 at 9:04:44 AM UTC-4, Matej Krejci wrote:
>
> Hello,
>
> I am trying to build a string and run it by standard function run(). 
> args=["arg1","arg2"]
> jargs=join(args," ")
> path="/grass_trunk/general/g.parser"
> run(`$path $jargs`)
>

Don't join the args.  Just do run(`$path $args`).   

(Yichao suggested run(`ls $(args...)`), but this is unnecessary and 
somewhat redundant.)

(Julia's run function does invoke the shell at all, so it doesn't uses 
spaces to separate arguments. Instead, it passes each argument as a 
separate string.  This allows it to be robust for e.g. filenames containing 
spaces.) 

Re: [julia-users] Re: The status of Julia's Webstack

[Jacob Quinn]

Jon,

I think you mean Morsel and Meddle are deprecated? While Mux is actually
maintained?

On Wed, Oct 7, 2015 at 7:04 AM, Jonathan Malmaud  wrote:

> Mux and Morsel are formally deprecated at this point and have no
> maintainers. They were designed early on in Julia's life and don't have a
> design that is particularly suited for modern Julia, so the maintainers of
> JuliaWeb made a decision to not invest time in keeping them operational.
>
> That said, Randy is right that I would still merge PRs for them.
>
> On Tuesday, October 6, 2015 at 5:05:10 PM UTC-4, Mohammed El-Beltagy wrote:
>>
>> It seems that Morsel.jl and Meddle.jl are quietly dieing away. I noticed
>> that after I did Pkg.update and found that my previously working code is is
>> now failing. Looking that the repositories on github, I noticed that both
>> have been failing their tests. I had to pin down Morsel, Meddle,
>> HttpCommon, HttpServer, and HttpParser to earlier versions to keep my
>> server running.
>>
>> There claimed replacement "Mux.jl" is morel like Meddle and can to be
>> regarded as a micro framework. This leaves a significant hole in Julia's
>> package echo system. I wonder if there are any attempts to fill that hole.
>>
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Just looks natural in some cases.

For example: Man.eat(food) looks better than eat(Man, food).

A similar situation is arithmetic expression. 2 + 3 might look more natural 
than (+ 2 3).

On Wednesday, October 7, 2015 at 5:23:23 PM UTC+2, Simon Danisch wrote:
>
> There are a lot of things "one could do" ;) Can you give some appealing 
> reasons, why someone should invest his/her time into this?
>
> Best,
> Simon
>
>
> Am Mittwoch, 7. Oktober 2015 17:13:33 UTC+2 schrieb cheng wang:
>>
>> Hello everyone,
>>
>> In some cases, I would like to make a function belongs to an object.
>> In classical OO, we do something like object.f(args...).
>> In Julia, we could do it like this: f(object, args...).
>>
>> So I was wandering if there is some way to do following:
>> I write object.f(args...), while julia could know it actual means 
>> f(object, args...).
>>
>> One naive way to implement this is in two steps:
>> first, the compiler search for a field of object equal to f, if it's not 
>> found,
>> then, compiler search for a function like f, and the invoke it.
>>
>> Looking forward for your opinions!
>>
>

[julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Hello everyone,

In some cases, I would like to make a function belongs to an object.
In classical OO, we do something like object.f(args...).
In Julia, we could do it like this: f(object, args...).

So I was wandering if there is some way to do following:
I write object.f(args...), while julia could know it actual means f(object, 
args...).

One naive way to implement this is in two steps:
first, the compiler search for a field of object equal to f, if it's not 
found,
then, compiler search for a function like f, and the invoke it.

Looking forward for your opinions!

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Simon Danisch]

There are a lot of things "one could do" ;) Can you give some appealing 
reasons, why someone should invest his/her time into this?

Best,
Simon


Am Mittwoch, 7. Oktober 2015 17:13:33 UTC+2 schrieb cheng wang:
>
> Hello everyone,
>
> In some cases, I would like to make a function belongs to an object.
> In classical OO, we do something like object.f(args...).
> In Julia, we could do it like this: f(object, args...).
>
> So I was wandering if there is some way to do following:
> I write object.f(args...), while julia could know it actual means 
> f(object, args...).
>
> One naive way to implement this is in two steps:
> first, the compiler search for a field of object equal to f, if it's not 
> found,
> then, compiler search for a function like f, and the invoke it.
>
> Looking forward for your opinions!
>

Re: [julia-users] DataFrames' readtable very slow compared to R's read.csv when loading ~7.6M csv rows

[David Gold]

Yaas. Very excited to see this.

On Wednesday, October 7, 2015 at 6:07:44 AM UTC-7, Jacob Quinn wrote:
>
> Haha, nice timing. I just pushed a big CSV.jl overhaul for 0.4 yesterday 
> afternoon. I just pushed the DataStreams.jl package, so you can find that 
> at https://github.com/quinnj/DataStreams.jl, and you'll have to Pkg.clone 
> it. Everything should work at that point.
>
> I'm still cleaning up some other related packages, so that's why things 
> aren't documented/registered/tagged quite yet as the interface may evolve 
> slightly, probably more the low-level machinery. So `stream!(::CSV.Source, 
> ::DataStream)` should stay the same.
>
> I've already got a bit writeup started once everything's done, so if you'd 
> rather wait another couple days or a week, I should have something ready by 
> then.
>
> -Jacob
>
> On Wed, Oct 7, 2015 at 12:33 AM, bernhard  > wrote:
>
>> Is there any update on this? Or maybe a timeline/roadmap?
>> I would love to see a faster CSV reader. 
>>
>> I tried to take a look at Jacob's CSV.jl.
>> But I seem to be missing https://github.com/lindahua/DataStreams.jl 
>> I have no idea where to find DataStreams package
>> Does it still exist?
>>
>> Is there any (experimental) way to make CSV.jl work?
>>
>>
>>
>>> Am Samstag, 6. Juni 2015 14:41:36 UTC+2 schrieb David Gold:
>>>
>>> @Jacob,
>>>
>>> Thank you very much for your explanation! I expect having such a 
>>> blueprint will make delving into the actual code more tractable for me. 
>>> I'll be curious to see how your solution here and your proposal for string 
>>> handling end up playing with the current Julia data ecosystem. 
>>>
>>> On Saturday, June 6, 2015 at 1:17:34 AM UTC-4, Jacob Quinn wrote:

 @David,

 Sorry for the slow response. It's been a busy week :)

 Here's a quick rundown of the approach:

 - In the still-yet-to-be-officially-published 
 https://github.com/quinnj/CSV.jl package, the bulk of the code goes 
 into creating a `CSV.File` type where the structure/metadata of the file 
 is 
 parsed/detected/saved in a type (e.g. header, delimiter, newline, # of 
 columns, detected column types, etc.)
 - `SQLite.create` and now `CSV.read` both take a `CSV.File` as input 
 and follow a similar process in parsing:
   - The actual file contents are mmapped; i.e. the entire file is 
 loaded into memory at once
   - There are currently three `readfield` methods (Int,Float64,String) 
 that take an open `CSV.Stream` type (which holds the mmapped data and the 
 current "position" of parsing), and read a single field according to what 
 the type of that column is supposed to be
   - for example, readfield(io::CSV.Stream, ::Type{Float64}, row, 
 col), will start reading at the current position of the `CSV.Stream` until 
 it hits the next delimiter, newline, or end of the file and then interpret 
 the contents as a Float64, returning `val, isnull`

 That's pretty much it. One of the most critical performance keys for 
 both SQLite and CSV.read is non-copying strings once the file has been 
 mmapped. For SQLite, the sqlite3_bind_text library method actually has a 
 flag to indicate whether the text should be copied or not, so we're able 
 to 
 pass the pointer to the position in the mmapped array directly. For the 
 CSV.read method, which returns a Vector of the columns (as typed arrays), 
 I've actually rolled a quick and dirty CString type that looks like

 immutable CString
   ptr::Ptr{UInt8}
   len::Int
 end

 With a few extra method definitions, this type looks very close to a 
 real string type, but we can construct it by pointing directly to the 
 mmapped region (which currently isn't possible for native Julia string 
 types). See https://github.com/quinnj/Strings.jl for more 
 brainstorming around this alternative string implementation. You can 
 convert a CString to a Julia string by calling string(x::CString) or 
 map(string,column) for an Array of CSV.CStrings.

 As an update on the performance on the Facebook Kaggle competition 
 bids.csv file:

 -readcsv: 45 seconds, 33% gc time
 -CSV.read: 19 seconds, 3% gc time
 -SQLite.create: 25 seconds, 3.25% gc time

 Anyway, hopefully I'll get around to cleaning up CSV.jl to be released 
 officially, but it's that last 10-20% that's always the hardest to finish 
 up :)

 -Jacob



 On Mon, Jun 1, 2015 at 4:25 PM, David Gold  wrote:

> @Jacob I'm just developing a working understanding of these issues. 
> Would you please help me to get a better handle on your solution?
>
> My understanding thus far: Reading a (local) .csv file into a 
> DataFrame using DataFrames.readtable involves reading the file into an 
> IOStream and then parsing that stream 

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

On Wednesday, October 7, 2015 at 6:47:40 PM UTC+2, Steven G. Johnson wrote:
>
> It's a bad idea.   You shouldn't try to write C programs that look like 
> Fortran programs, you shouldn't speak French with English pronunciation, 
> and you shouldn't try to write Julia programs that look like Python 
> programs.   Part of programming is learning to adapt to the local style, 
> both the style of a programming language and also the style of a project 
> that you are contributing to.
>
I don't see why it is bad to support more styles if there is no harm to the 
original one.
So actually I was also asking if this new style will bring evil things to 
local style.
 

>
> The only difference between object.verb(args...) and verb(object, args...) 
> is spelling.  Since there is no practical need for the former, you should 
> just get used to the Julia spelling when writing Julia code.
>
 
Since dot already means access fields of an object. It slightly affects, 
maybe?
 

>
> Steven
>
> PS. In olden times, many people learned programming in Pascal. When they 
> switched to C, their first instinct was often to define macros that made C 
> look more like Pascal, and this was universally considered to be a mistake 
> by experienced programmers. See: http://c-faq.com/cpp/slm.html 
> 
>
Thanks for sharing this story, it is interesting.
However I always like to reason about thing in details, not just you should 
don't do this.

 
 

[julia-users] For systems that have it, does Julia set the Intel FPU round-to-double flag on startup?

[Jeffrey Sarnoff]

For systems that have it, does Julia set the Intel FPUs to round-to-double 
on startup? If not, how is this done in a portable way?

Re: [julia-users] Is there a way to replace f(object, args...) with object.f(args...)?

[Kevin Squire]

Hi Cheng,

Just so you know, this type of call has been discussed a number of times in
the past (on my phone, so searching julia-users and julia-dev is hard right
now).

The general response has been that, while this may be more familiar to
programmers coming from some languages, Julia's focus on multiple dispatch
is a key component of the language, and there isn't much desire to
complicate the implementation or use of the language with multiple calling
conventions.

That said, you could almost certainly fake this calling convention with a
macro.

Cheers,
   Kevin


On Wednesday, October 7, 2015, Simon Danisch  wrote:

> There are a lot of things "one could do" ;) Can you give some appealing
> reasons, why someone should invest his/her time into this?
>
> Best,
> Simon
>
>
> Am Mittwoch, 7. Oktober 2015 17:13:33 UTC+2 schrieb cheng wang:
>>
>> Hello everyone,
>>
>> In some cases, I would like to make a function belongs to an object.
>> In classical OO, we do something like object.f(args...).
>> In Julia, we could do it like this: f(object, args...).
>>
>> So I was wandering if there is some way to do following:
>> I write object.f(args...), while julia could know it actual means
>> f(object, args...).
>>
>> One naive way to implement this is in two steps:
>> first, the compiler search for a field of object equal to f, if it's not
>> found,
>> then, compiler search for a function like f, and the invoke it.
>>
>> Looking forward for your opinions!
>>
>

Re: [julia-users] For systems that have it, does Julia set the Intel FPU round-to-double flag on startup?

[Jameson Nash]

Julia avoids running on such systems by requiring SSE2 (pentium4) as a
minimum.

see https://github.com/JuliaLang/julia/issues/7185#issuecomment-51562133

On Wed, Oct 7, 2015 at 2:58 AM Jeffrey Sarnoff 
wrote:

> For systems that have it, does Julia set the Intel FPUs to round-to-double
> on startup? If not, how is this done in a portable way?
>
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Eric Forgy]

I'm still a Julia newbie, but have been lurking around long enough to know 
that a common answer for questions like this is... 

*You can have the behavior you want via a fairly straightforward macro.*


In this case, the macro would simply take object.f(args) and replace it 
with f(object,args), which is pretty much what Matlab does. This may be a 
bad idea for reasons I'm not yet aware of (but would like to learn), but 
hope it helps a little.

Re: [julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Milan Bouchet-Valat]

Le mercredi 07 octobre 2015 à 08:31 -0700, cheng wang a écrit :
> Just looks natural in some cases.
> 
> For example: Man.eat(food) looks better than eat(Man, food).
> 
> A similar situation is arithmetic expression. 2 + 3 might look more
> natural than (+ 2 3).
Looks like you'd rather want to write
Man `eat` food
or something similar instead of Man.eat(food).

For previous discussions about this, search for "infix operator" in the
list archives and on GitHub.


Regards

> On Wednesday, October 7, 2015 at 5:23:23 PM UTC+2, Simon Danisch
> wrote:
> > There are a lot of things "one could do" ;) Can you give some
> > appealing reasons, why someone should invest his/her time into
> > this?
> > 
> > Best,
> > Simon
> > 
> > 
> > Am Mittwoch, 7. Oktober 2015 17:13:33 UTC+2 schrieb cheng wang:
> > > Hello everyone,
> > > 
> > > In some cases, I would like to make a function belongs to an
> > > object.
> > > In classical OO, we do something like object.f(args...).
> > > In Julia, we could do it like this: f(object, args...).
> > > 
> > > So I was wandering if there is some way to do following:
> > > I write object.f(args...), while julia could know it actual means
> > > f(object, args...).
> > > 
> > > One naive way to implement this is in two steps:
> > > first, the compiler search for a field of object equal to f, if
> > > it's not found,
> > > then, compiler search for a function like f, and the invoke it.
> > > 
> > > Looking forward for your opinions!
> > > 

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[David Gold]

See perhaps 
https://groups.google.com/forum/?hl=en#!topic/julia-dev/V1HJcHQz4JE

On Wednesday, October 7, 2015 at 8:13:33 AM UTC-7, cheng wang wrote:
>
> Hello everyone,
>
> In some cases, I would like to make a function belongs to an object.
> In classical OO, we do something like object.f(args...).
> In Julia, we could do it like this: f(object, args...).
>
> So I was wandering if there is some way to do following:
> I write object.f(args...), while julia could know it actual means 
> f(object, args...).
>
> One naive way to implement this is in two steps:
> first, the compiler search for a field of object equal to f, if it's not 
> found,
> then, compiler search for a function like f, and the invoke it.
>
> Looking forward for your opinions!
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Thanks everyone!

I also find this helpful: https://github.com/JuliaLang/julia/issues/1974
A very related issue that the authors of Julia discussed.

In scala, object.f(args) is implemented as f(object, args).
For Julia, maybe this implementation would harm the performance.
Anyway, It's fine to use f(object, args) :)

On Wednesday, October 7, 2015 at 5:46:56 PM UTC+2, David Gold wrote:
>
> See perhaps 
> https://groups.google.com/forum/?hl=en#!topic/julia-dev/V1HJcHQz4JE
>
> On Wednesday, October 7, 2015 at 8:13:33 AM UTC-7, cheng wang wrote:
>>
>> Hello everyone,
>>
>> In some cases, I would like to make a function belongs to an object.
>> In classical OO, we do something like object.f(args...).
>> In Julia, we could do it like this: f(object, args...).
>>
>> So I was wandering if there is some way to do following:
>> I write object.f(args...), while julia could know it actual means 
>> f(object, args...).
>>
>> One naive way to implement this is in two steps:
>> first, the compiler search for a field of object equal to f, if it's not 
>> found,
>> then, compiler search for a function like f, and the invoke it.
>>
>> Looking forward for your opinions!
>>
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

Newbie here too :)

For me, the problem is having to write @mymacro everytime I use this style.

On Wednesday, October 7, 2015 at 5:44:30 PM UTC+2, Eric Forgy wrote:
>
> I'm still a Julia newbie, but have been lurking around long enough to know 
> that a common answer for questions like this is... 
>
> *You can have the behavior you want via a fairly straightforward macro.*
>
>
> In this case, the macro would simply take object.f(args) and replace it 
> with f(object,args), which is pretty much what Matlab does. This may be a 
> bad idea for reasons I'm not yet aware of (but would like to learn), but 
> hope it helps a little.
>

[julia-users] Re: Convert ASCIIString to Cmd and use run()

[Matej Krejci]

Hi Yu, Steven
 

> Don't join the args.  Just do run(`$path $args`).   
>
> (Yichao suggested run(`ls $(args...)`), but this is unnecessary and 
> somewhat redundant.)
>
> (Julia's run function does invoke the shell at all, so it doesn't uses 
> spaces to separate arguments. Instead, it passes each argument as a 
> separate string.  This allows it to be robust for e.g. filenames containing 
> spaces.) 
>

Great, with using arrays it works.(bellow is working example for others)
path="/grass_trunk/general/g.parser"
args=["arg1","arg2"]
unshift!(args,path)
run(`$args`)

Thanks! Matej 

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Glen O]

Perhaps you could include the function amongst the elements of the type?

immutable MyArray
array::Array
fill::Function

MyArray(array)=new(array,i->fill!(array,i))
end

B=MyArray(zeros(5,2));

B.array
5x2 Array{Float64,2}:
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0

B.fill(1);

B.array
5x2 Array{Float64,2}:
 1.0  1.0
 1.0  1.0
 1.0  1.0
 1.0  1.0
 1.0  1.0

Does that help? Note that I have no idea how well it would perform in terms 
of optimisation.

On Thursday, 8 October 2015 01:13:33 UTC+10, cheng wang wrote:
>
> Hello everyone,
>
> In some cases, I would like to make a function belongs to an object.
> In classical OO, we do something like object.f(args...).
> In Julia, we could do it like this: f(object, args...).
>
> So I was wandering if there is some way to do following:
> I write object.f(args...), while julia could know it actual means 
> f(object, args...).
>
> One naive way to implement this is in two steps:
> first, the compiler search for a field of object equal to f, if it's not 
> found,
> then, compiler search for a function like f, and the invoke it.
>
> Looking forward for your opinions!
>

[julia-users] Re: adding new method for $ is not allowed, while adding for + is fine

[Seth]

Surround it by parens:

julia> ($)(x::Int, y::Int) = x+y+5
...
julia> ($)(5,7)
17

On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:
>
> Hello everyone,
>
> I try to do $(x,y)=something, it says: syntax: invalid assignment location
> while +(x,y)=something is ok.
>
> Is there any speciality of $ operator?
>
> Best,
> Cheng
>

[julia-users] Re: adding new method for $ is not allowed, while adding for + is fine

[Seth]

Oops, hit post too quickly. Can also be called infix:

julia> 5 $ 7
17


On Wednesday, October 7, 2015 at 12:05:10 PM UTC-7, Seth wrote:
>
> Surround it by parens:
>
> julia> ($)(x::Int, y::Int) = x+y+5
> ...
> julia> ($)(5,7)
> 17
>
> On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:
>>
>> Hello everyone,
>>
>> I try to do $(x,y)=something, it says: syntax: invalid assignment 
>> location
>> while +(x,y)=something is ok.
>>
>> Is there any speciality of $ operator?
>>
>> Best,
>> Cheng
>>
>

[julia-users] Re: adding new method for $ is not allowed, while adding for + is fine

[cheng wang]

Thanks. Still, why + and $ are different in this case ?

On Wednesday, October 7, 2015 at 9:05:10 PM UTC+2, Seth wrote:
>
> Surround it by parens:
>
> julia> ($)(x::Int, y::Int) = x+y+5
> ...
> julia> ($)(5,7)
> 17
>
> On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:
>>
>> Hello everyone,
>>
>> I try to do $(x,y)=something, it says: syntax: invalid assignment 
>> location
>> while +(x,y)=something is ok.
>>
>> Is there any speciality of $ operator?
>>
>> Best,
>> Cheng
>>
>

Re: [julia-users] adding new method for $ is not allowed, while adding for + is fine

[Stefan Karpinski]

$ is used for expression interpolation (see metaprogramming in the manual),
so you need the parens to make it clear that you're not trying to do
interpolation.

On Wednesday, October 7, 2015, cheng wang  wrote:

> Thanks. Still, why + and $ are different in this case ?
>
> On Wednesday, October 7, 2015 at 9:05:10 PM UTC+2, Seth wrote:
>>
>> Surround it by parens:
>>
>> julia> ($)(x::Int, y::Int) = x+y+5
>> ...
>> julia> ($)(5,7)
>> 17
>>
>> On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:
>>>
>>> Hello everyone,
>>>
>>> I try to do $(x,y)=something, it says: syntax: invalid assignment
>>> location
>>> while +(x,y)=something is ok.
>>>
>>> Is there any speciality of $ operator?
>>>
>>> Best,
>>> Cheng
>>>
>>

[julia-users] Re: adding new method for $ is not allowed, while adding for + is fine

[Matt Bauman]

$ is also used for interpolation, so it must be disambiguated between the 
two cases.  & is similar, if I remember correctly.

On Wednesday, October 7, 2015 at 3:09:08 PM UTC-4, cheng wang wrote:
>
> Thanks. Still, why + and $ are different in this case ?
>
> On Wednesday, October 7, 2015 at 9:05:10 PM UTC+2, Seth wrote:
>>
>> Surround it by parens:
>>
>> julia> ($)(x::Int, y::Int) = x+y+5
>> ...
>> julia> ($)(5,7)
>> 17
>>
>> On Wednesday, October 7, 2015 at 11:39:03 AM UTC-7, cheng wang wrote:
>>>
>>> Hello everyone,
>>>
>>> I try to do $(x,y)=something, it says: syntax: invalid assignment 
>>> location
>>> while +(x,y)=something is ok.
>>>
>>> Is there any speciality of $ operator?
>>>
>>> Best,
>>> Cheng
>>>
>>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Maxim Grechkin]

>
> The only difference between object.verb(args...) and verb(object, args...) 
> is spelling.  Since there is no practical need for the former, you should 
> just get used to the Julia spelling when writing Julia code.
>
What about auto-complete? object.verb provides better opportunities to 
auto-complete on dot compared to verb(object, args). If you have an object 
and you want to figure out what you can do with it, all you can do in Julia 
is try using `methodswith`, but that's not that straightforward or easy to 
use.

I've seen some proposals to do an auto-complete on "object, " 
(auto-complete putting verbs before object), but I don't have a sense of 
how awkward will that look in an editor.

>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

On Wednesday, October 7, 2015 at 8:10:45 PM UTC+2, Pablo Zubieta wrote:
>
> As others mentioned, it is better to use multiple dispatch as the Julia 
> language was developed with it as one of its central features.
>
Totally agree with this. using verb(object, args) to implement 
object.verb(args) actually still relies on multiple dispatch.
 

>
> You could easily change the name of the function to make it look natural 
> (in the english grammar sense). E.g. you can define feed(Man, food) or 
> feed(Man, with=food) if that seems more natural to you.
>
This is a GREAT trick. Thanks 

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[cheng wang]

I absolutely like multiple dispatch. Just want to make syntax sugars based 
on this.

On Wednesday, October 7, 2015 at 7:59:22 PM UTC+2, Scott Jones wrote:
>
> I think the important take away is that Julia's *multiple* dispatch can be 
> much more powerful than traditional "object oriented" single dispatch.
> Once you get your head wrapped around that, I don't think you really would 
> want to go back to the Python/Java/JS/C++ single dispatch way of doing 
> things.
>
> On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>>
>>
>>
>> On Wednesday, October 7, 2015 at 6:47:40 PM UTC+2, Steven G. Johnson 
>> wrote:
>>>
>>> It's a bad idea.   You shouldn't try to write C programs that look like 
>>> Fortran programs, you shouldn't speak French with English pronunciation, 
>>> and you shouldn't try to write Julia programs that look like Python 
>>> programs.   Part of programming is learning to adapt to the local style, 
>>> both the style of a programming language and also the style of a project 
>>> that you are contributing to.
>>>
>> I don't see why it is bad to support more styles if there is no harm to 
>> the original one.
>> So actually I was also asking if this new style will bring evil things to 
>> local style.
>>  
>>
>>>
>>> The only difference between object.verb(args...) and verb(object, 
>>> args...) is spelling.  Since there is no practical need for the former, you 
>>> should just get used to the Julia spelling when writing Julia code.
>>>
>>  
>> Since dot already means access fields of an object. It slightly affects, 
>> maybe?
>>  
>>
>>>
>>> Steven
>>>
>>> PS. In olden times, many people learned programming in Pascal. When they 
>>> switched to C, their first instinct was often to define macros that made C 
>>> look more like Pascal, and this was universally considered to be a mistake 
>>> by experienced programmers. See: http://c-faq.com/cpp/slm.html 
>>> 
>>>
>> Thanks for sharing this story, it is interesting.
>> However I always like to reason about thing in details, not just you 
>> should don't do this.
>>
>>  
>>  
>>
>

[julia-users] adding new method for $ is not allowed, while adding for + is fine

[cheng wang]

Hello everyone,

I try to do $(x,y)=something, it says: syntax: invalid assignment location
while +(x,y)=something is ok.

Is there any speciality of $ operator?

Best,
Cheng

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Scott Jones]

I think the important take away is that Julia's *multiple* dispatch can be 
much more powerful than traditional "object oriented" single dispatch.
Once you get your head wrapped around that, I don't think you really would 
want to go back to the Python/Java/JS/C++ single dispatch way of doing 
things.

On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote:
>
>
>
> On Wednesday, October 7, 2015 at 6:47:40 PM UTC+2, Steven G. Johnson wrote:
>>
>> It's a bad idea.   You shouldn't try to write C programs that look like 
>> Fortran programs, you shouldn't speak French with English pronunciation, 
>> and you shouldn't try to write Julia programs that look like Python 
>> programs.   Part of programming is learning to adapt to the local style, 
>> both the style of a programming language and also the style of a project 
>> that you are contributing to.
>>
> I don't see why it is bad to support more styles if there is no harm to 
> the original one.
> So actually I was also asking if this new style will bring evil things to 
> local style.
>  
>
>>
>> The only difference between object.verb(args...) and verb(object, 
>> args...) is spelling.  Since there is no practical need for the former, you 
>> should just get used to the Julia spelling when writing Julia code.
>>
>  
> Since dot already means access fields of an object. It slightly affects, 
> maybe?
>  
>
>>
>> Steven
>>
>> PS. In olden times, many people learned programming in Pascal. When they 
>> switched to C, their first instinct was often to define macros that made C 
>> look more like Pascal, and this was universally considered to be a mistake 
>> by experienced programmers. See: http://c-faq.com/cpp/slm.html 
>> 
>>
> Thanks for sharing this story, it is interesting.
> However I always like to reason about thing in details, not just you 
> should don't do this.
>
>  
>  
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Steven G. Johnson]

It's a bad idea.   You shouldn't try to write C programs that look like 
Fortran programs, you shouldn't speak French with English pronunciation, 
and you shouldn't try to write Julia programs that look like Python 
programs.   Part of programming is learning to adapt to the local style, 
both the style of a programming language and also the style of a project 
that you are contributing to.

The only difference between object.verb(args...) and verb(object, args...) 
is spelling.  Since there is no practical need for the former, you should 
just get used to the Julia spelling when writing Julia code.

Steven

PS. In olden times, many people learned programming in Pascal. When they 
switched to C, their first instinct was often to define macros that made C 
look more like Pascal, and this was universally considered to be a mistake 
by experienced programmers. See: http://c-faq.com/cpp/slm.html

[julia-users] Julia compile to/ calling Javascript? (for single page reports/apps)

[Lampkld]

Hi everyone,

I'm trying, among other things, to create single page client side apps 
/reports in Julia like knitr.

Is there any package working on Julia to JS compilation? Anyone know how I 
can call JS from Julia?

Thanks 

[julia-users] Re: Julia compile to/ calling Javascript? (for single page reports/apps)

[Eric Forgy]

We were looking into this a while ago. 
See https://github.com/JuliaLang/julia/issues/9430

I'm not sure where things stand now, but Stefan's comments here are 
interesting and I think progress has been made generating binaries

https://groups.google.com/d/msg/julia-users/EPzWdFwCGFU/OklaINvOlZIJ

Until this works, I'm just communicating with a Julia server over http. By 
the way, this is also how the Atom/Juno editor works, so you can get some 
ideas there.

https://github.com/JunoLab/atom-julia-client/blob/master/docs/communication.md

On Thursday, October 8, 2015 at 1:02:36 AM UTC+8, Lampkld wrote:
>
> Hi everyone,
>
> I'm trying, among other things, to create single page client side apps 
> /reports in Julia like knitr.
>
> Is there any package working on Julia to JS compilation? Anyone know how I 
> can call JS from Julia?
>
> Thanks 
>
>
>
>
>

Re: [julia-users] For systems that have it, does Julia set the Intel FPU round-to-double flag on startup?

[Jeffrey Sarnoff]

I am good with that!

On Wednesday, October 7, 2015 at 12:26:54 PM UTC-4, Jameson wrote:
>
> Julia avoids running on such systems by requiring SSE2 (pentium4) as a 
> minimum.
>
> see https://github.com/JuliaLang/julia/issues/7185#issuecomment-51562133
>
> On Wed, Oct 7, 2015 at 2:58 AM Jeffrey Sarnoff  > wrote:
>
>> For systems that have it, does Julia set the Intel FPUs to 
>> round-to-double on startup? If not, how is this done in a portable way?
>>
>>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Eric Forgy]

Well said! :D

On Thursday, October 8, 2015 at 12:47:40 AM UTC+8, Steven G. Johnson wrote:
>
> It's a bad idea.   You shouldn't try to write C programs that look like 
> Fortran programs, you shouldn't speak French with English pronunciation, 
> and you shouldn't try to write Julia programs that look like Python 
> programs.   Part of programming is learning to adapt to the local style, 
> both the style of a programming language and also the style of a project 
> that you are contributing to.
>
> The only difference between object.verb(args...) and verb(object, args...) 
> is spelling.  Since there is no practical need for the former, you should 
> just get used to the Julia spelling when writing Julia code.
>
> Steven
>
> PS. In olden times, many people learned programming in Pascal. When they 
> switched to C, their first instinct was often to define macros that made C 
> look more like Pascal, and this was universally considered to be a mistake 
> by experienced programmers. See: http://c-faq.com/cpp/slm.html
>