Am I doing something wrong or is this a bug? It seems like if the 1st
version works, the 2nd and 3rd should, too.
julia> mktemp(println)
/var/folders/jd/1skd5rh11hnc_s19lmx93zywgp/T/tmpf7HaUHIOStream()
julia> mktemp(x->println(x))
ERROR: wrong number of arguments
in anonymous at none:1
Never mind, I figured out it was an escaping issue. This is all fine if you
do Regex("\\d\\d").
On Monday, February 22, 2016 at 5:27:17 PM UTC-8, John Brock wrote:
>
> regex_from_macro = r"\d\d"
> regex_from_function = Regex("\d\d")
>
> ju
regex_from_macro = r"\d\d"
regex_from_function = Regex("\d\d")
julia> regex_from_macro("45")
true
julia> regex_from_function("45")
false
julia> regex_from_macro("5")
false
julia> regex_from_function("5")
false
Why does calling r"\d\d" result in different behavior than Regex("\d\d")? I
To replicate, be sure to start julia with more than one process (e.g.,
`julia -p 2`):
julia> foo = convert(SharedArray, [1,2,3,4]);
julia> @async pmap(i->println(foo), 1:2)
Task (waiting) @0x00010cd8f730
julia> From worker 2: [1,2,3,4]
From worker 3: [1,2,3,4]
julia>
I don't know if this is a feature or a bug. Functions used inside a pmap
call can only see SharedArrays when the pmap call is preceded by @async. To
replicate, be sure to start julia with more than one process (e.g., `julia
-p 2`):
julia> foo = convert(SharedArray, [1,2,3,4]);
julia> @async
s of init and pids will be the ones given in the signature.
>
> // T
>
> On Monday, November 9, 2015 at 9:43:17 PM UTC+1, John Brock wrote:
>
> It looks like SharedArray(filename, T, dims) isn't documented,
>> but SharedArray(T, dims; init=false, pids=Int[]) is. What's the difference?
As of 0.4, when should I choose to use sub versus ArrayViews.jl? The
ArrayViews.jl README mentions that sub uses a less efficient view
representation, but just how much less efficient is it? Is there ever a
good reason to use sub instead of ArrayViews, despite the less efficient
A-ha, I see, thanks. Also, for anyone who comes across this post, I forgot
the -o flag before 'StrictHostKeyChecking no'.
On Thursday, October 8, 2015 at 4:35:07 PM UTC-7, Steven G. Johnson wrote:
>
>
>
> On Thursday, October 8, 2015 at 7:16:34 PM UTC-4, John Brock wrote:
>
I've read through the parallel computing documentation and experimented
with some toy examples, but I still have some questions about the
fundamentals of parallel programming in Julia:
1. It seems that @async performs work in a separate green thread, while
@spawn performs work in a
This seems issue-worthy if the most recent nightly has the same problem. It
looks like Enumerate supports the length property, so the underlying code
for @parallel should be able to check the length of the enumerator and
figure out how many jobs to assign to each worker.
And regardless of
This seems issue-worthy if the most recent nightly have the same problem.
It looks like Enumerate supports the length property, so the underlying
code for @parallel should be able to check the length of the enumerator and
figure out how many jobs to assign to each worker.
And regardless of
Is there an easy way to slice an array using an array of ranges? I'm
looking for something like the following:
foo = [2,6,2,8,4,9]
some_ranges = UnitRange{Int64}[2:3, 5:6]
foo[some_ranges] # gives error; desired output is [6,2,4,9]
I'm seeing inconsistent results when multiple workers write values to a
SharedArray at the same time, presumably because += isn't atomic. Is this
intended behavior, and is there a workaround? Behavior is reproducible in
0.3.8-pre+22 and 0.3.9.
Sample code:
function doStuff()
result_shared
On Monday, July 20, 2015 04:29:04 PM John Brock wrote:
I'm seeing inconsistent results when multiple workers write values to a
SharedArray at the same time, presumably because += isn't atomic. Is
this
intended behavior, and is there a workaround? Behavior is reproducible
in
0.3.8-pre+22
14 matches
Mail list logo