[julia-users] HttpServer runtests,jl: req.resource = "http://localhost/hello/travis" instead of "/hello/travis"
Hi,
I'm sure I am just doing something silly, but I'm trying to run
"Pkg.test("HttpServer"), but my tests are failing. I traced the problem
down to
ret = Requests.get("http://localhost:8000/hello/travis";)
The handler is receiving the request, but if I look at the req.resource, it
is the full url, i.e.
req.resource = "http://localhost/hello/travis";
but I think it should just be
req.resource = "/hello/travis"
Any ideas? Why is the req.resource not just "/hello/travis"?
I'm also a little confused why the ":8000" isn't there, but that is
secondary.
I appreciate any help. Thanks.
[julia-users] If a key gets pressed in a keyboard and no one is around to press enter, does it have any side effects?
Sorry for the click-bate title... Is there any way I can bind a keyboard stroke to some event? For example, during the execution of some program, if the user all of a sudden presses, say, the 'a' key then some variable gets assigned with some value. I guess this would require some kind of listener that one can assign to specific keyboard keys? Thanks!
Re: [julia-users] (1.0π) ≠ π
On Nov 26, 2015 9:15 PM, "Sheehan Olver" wrote: > > OK so it's a bit inconsistent then with BigFloat: > > julia> BigFloat(1/3)==(1/3) > > true You are converting a Float64 1/3 to a big float and of course they are equal. One way to get a higher precision, use sth like big(1) / 3 > > > julia> BigFloat(1/3)==(1//3) > > false > > > > > On Friday, November 27, 2015 at 12:40:12 PM UTC+11, Yichao Yu wrote: >> >> >> On Nov 26, 2015 8:27 PM, "Sheehan Olver" wrote: >> > >> > >> > >> > This really surprised me: >> > >> > julia> (1.0π) ≠ π >> > >> > true >> > >> > >> > >> > I guess π is treated as infinite precision until it becomes a float? >> >> Right.
Re: [julia-users] (1.0π) ≠ π
OK so it's a bit inconsistent then with BigFloat: *julia> **BigFloat(1/3)==(1/3)* *true* *julia> **BigFloat(1/3)==(1//3)* *false* On Friday, November 27, 2015 at 12:40:12 PM UTC+11, Yichao Yu wrote: > > > On Nov 26, 2015 8:27 PM, "Sheehan Olver" > > wrote: > > > > > > > > This really surprised me: > > > > julia> (1.0π) ≠ π > > > > true > > > > > > > > I guess π is treated as infinite precision until it becomes a float? > > Right. >
Re: [julia-users] (1.0π) ≠ π
On Nov 26, 2015 8:27 PM, "Sheehan Olver" wrote: > > > > This really surprised me: > > julia> (1.0π) ≠ π > > true > > > > I guess π is treated as infinite precision until it becomes a float? Right.
[julia-users] (1.0π) ≠ π
This really surprised me: *julia> **(1.0π) ≠ π* *true* I guess π is treated as infinite precision until it becomes a float?
[julia-users] Re: pmap - intermingled output from workers on v0.4
OK, I've done a little more digging. It seems that in v0.4, remote workers are started differently. This is my understanding: Only one worker for each host is started directly from the master process. Additional workers on each host are started from the first worker on that host. Thus output from these additional workers is routed via the first worker on the host (rather than directly to master process). Somehow this causes the intermingled output. To overcome this, I can start all workers directly from the master process, and output is orderly again (as for v0.3). Presumably, the new v0.4 indirect method was to speed up adding remote workers. Clearly, I don't really understand much of this. And I'm not sure how connecting all workers directly to master process affects performance or scalability. Intuitively, it doesn't sound good, but for my purpose it does give more readable output. To help speed up the startup of workers, I can start workers on different hosts in parallel (but each worker on host is started serially and directly from master process) @sync begin for each (host, nworkers) in machines @async begin for i = 1:nworkers addprocs([(host,1)]) end end end end
[julia-users] Re: Result changes if I change the number of workers
Do any of your calculations depend on the values of A? If so they will get different values depending in what order A[i] is updated. And the order depends on scheduling of the processes, which is not deterministic. Cheers Lex On Friday, November 27, 2015 at 8:44:42 AM UTC+10, Eduardo Lenz wrote: > > Thanks Seth. > > I have a LOT of floating point calculations inside this loop. So, there > should be it ! > > Now I have to figure it out how to overcome itif it is even possible > :0) > > Thanks a lot !! > > On Thursday, November 26, 2015 at 5:59:56 PM UTC-2, Seth wrote: >> >> Are you doing floating point calculations? Some FP operations aren't >> associative and therefore may appear different on successive runs of a >> parallel operation depending on what's summed first: >> >> julia> (0.1 + 0.2) + 0.3 >> 0.6001 >> >> >> julia> 0.1 + (0.2 + 0.3) >> 0.6 >> >> >> On Thursday, November 26, 2015 at 11:48:25 AM UTC-8, Eduardo Lenz wrote: >>> >>> Hi. >>> >>> I came across a very weird behaviour when using a very simple @parallel >>> loop. The block is quite large and complex, but the idea is the following: >>> >>> >>> A = zeros(some_dimension) >>> A = convert(SharedArray,A) >>> @sync @parallel for i=1:some_dimension >>> >>> Lots of code, but with no function calls >>> >>> A[i] += block_result >>> >>> end >>> >>> some computation with sdata(A). >>> >>> If I use 4 processes, I get one result. With 8 processes, a diferent >>> result. Without parallel processing, another one. >>> >>> I am probably losing something, but I think this is not the intended >>> behaviour. >>> >>> I am using jula 4.11, fedora 23 - 64 bits. >>> >>> Thanks for your help. >>> >>
[julia-users] Re: Result changes if I change the number of workers
Thanks Seth. I have a LOT of floating point calculations inside this loop. So, there should be it ! Now I have to figure it out how to overcome itif it is even possible :0) Thanks a lot !! On Thursday, November 26, 2015 at 5:59:56 PM UTC-2, Seth wrote: > > Are you doing floating point calculations? Some FP operations aren't > associative and therefore may appear different on successive runs of a > parallel operation depending on what's summed first: > > julia> (0.1 + 0.2) + 0.3 > 0.6001 > > > julia> 0.1 + (0.2 + 0.3) > 0.6 > > > On Thursday, November 26, 2015 at 11:48:25 AM UTC-8, Eduardo Lenz wrote: >> >> Hi. >> >> I came across a very weird behaviour when using a very simple @parallel >> loop. The block is quite large and complex, but the idea is the following: >> >> >> A = zeros(some_dimension) >> A = convert(SharedArray,A) >> @sync @parallel for i=1:some_dimension >> >> Lots of code, but with no function calls >> >> A[i] += block_result >> >> end >> >> some computation with sdata(A). >> >> If I use 4 processes, I get one result. With 8 processes, a diferent >> result. Without parallel processing, another one. >> >> I am probably losing something, but I think this is not the intended >> behaviour. >> >> I am using jula 4.11, fedora 23 - 64 bits. >> >> Thanks for your help. >> >
[julia-users] Re: Spliting file in to multiple piecies
On Thursday, November 26, 2015 at 5:34:46 PM UTC+2, Steven G. Johnson wrote: > > Macros are a much more powerful way of including code generation directly > in your source code in Julia. It feels like that this small snippet will solve my future issues :) macro barr() return :(a*2) end bar(a) = @barr
[julia-users] Re: fzero
Hm...Right Thanks...-.-
[julia-users] fzero
try volflow(eta)=vol_flow(eta,0.05)[1]
[julia-users] Re: fzero
fzero(volflow[:,1,1],[0,1]) ?
[julia-users] Re: fzero
Sorry again: This ofc is wrong: volflow(eta,0.05)=2*broadcast(+, eta.^2-eta.^4/2 , sum( broadcast(*, broadcast(/,2*eta,r.^2).*broadcast(-,broadcast(*,2./r,broadcast(/,besselj1(broadcast(*,r,eta)),besselj0(r))),eta) , exp(-broadcast(*,r.^2,x_s))) , 3) ) correct: volflow(eta)=vol_flow(eta,0.05)
Re: [julia-users] Re: Best practice for editing official packages?
Excellent. Thank you guys.
[julia-users] Re: fzero
Almost forgot: r is defined by: g_r(a)=besselj1(a)-a/2*besselj0(a); N=500; rr=zeros(1,1,N); r=zeros(1,1,N); index=zeros(5,N); for i=1:N r[1,1,i]=fzero(g_r,[pi+(2*i-1),2*pi+(2*i-1)]); end eps=0.1; for i=1:N if ~(i in index) ind=find( abs(r-r[1,1,i]) .< eps ); rr[1,1,i]=mean(r[ind]); index[1:length(ind),i]=ind; end end ind=find(rr .!= 0) r=zeros(1,1,length(ind)) r[1,1,:]=rr[ind]
[julia-users] fzero
I have a function defined this way:
vol_flow(eta,x_s)=2*broadcast(+, eta.^2-eta.^4/2 , sum( broadcast(*,
broadcast(/,2*eta,r.^2).*broadcast(-,broadcast(*,2./r,broadcast(/,besselj1(broadcast(*,r,eta)),besselj0(r))),eta)
, exp(-broadcast(*,r.^2,x_s))) , 3) )
Now specifying x_s=0.05 for example
volflow(eta,0.05)=2*broadcast(+, eta.^2-eta.^4/2 , sum( broadcast(*,
broadcast(/,2*eta,r.^2).*broadcast(-,broadcast(*,2./r,broadcast(/,besselj1(broadcast(*,r,eta)),besselj0(r))),eta)
, exp(-broadcast(*,r.^2,x_s))) , 3) )
would give me a function which evaluated for an array eta gives me an
{:,1,1} array...
Now I want to use fzero
fzero(volflow,[0,1])
which tells me
ERROR: MethodError: `*` has no method matching *(::Array{Float64,3},
::Array{Float64,3})
Closest candidates are:
*(::Any, ::Any, ::Any, ::Any...)
*{TA,TQ,N}(::Union{DenseArray{TA,N},SubArray{TA,N,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}},
::Union{Base.LinAlg.QRCompactWYQ{TQ,M<:AbstractArray{T,2}},Base.LinAlg.QRPackedQ{TQ,S<:AbstractArray{T,2}}})
*(::Number, ::AbstractArray{T,N})
...
in find_zero at C:\cygwin64\home\Diger\.julia\v0.4\Roots\src\fzero.jl:64
in fzero at C:\cygwin64\home\Diger\.julia\v0.4\Roots\src\Roots.jl:105
in fzero at C:\cygwin64\home\Diger\.julia\v0.4\Roots\src\Roots.jl:112
It seems that the evaluation of fzero has trouble running since the array
structure of the additional array in dimension 2 and 3 as far as I
understand
How do I get this still running?
[julia-users] Re: Result changes if I change the number of workers
Are you doing floating point calculations? Some FP operations aren't associative and therefore may appear different on successive runs of a parallel operation depending on what's summed first: julia> (0.1 + 0.2) + 0.3 0.6001 julia> 0.1 + (0.2 + 0.3) 0.6 On Thursday, November 26, 2015 at 11:48:25 AM UTC-8, Eduardo Lenz wrote: > > Hi. > > I came across a very weird behaviour when using a very simple @parallel > loop. The block is quite large and complex, but the idea is the following: > > > A = zeros(some_dimension) > A = convert(SharedArray,A) > @sync @parallel for i=1:some_dimension > > Lots of code, but with no function calls > > A[i] += block_result > > end > > some computation with sdata(A). > > If I use 4 processes, I get one result. With 8 processes, a diferent > result. Without parallel processing, another one. > > I am probably losing something, but I think this is not the intended > behaviour. > > I am using jula 4.11, fedora 23 - 64 bits. > > Thanks for your help. >
[julia-users] Result changes if I change the number of workers
Hi. I came across a very weird behaviour when using a very simple @parallel loop. The block is quite large and complex, but the idea is the following: A = zeros(some_dimension) A = convert(SharedArray,A) @sync @parallel for i=1:some_dimension Lots of code, but with no function calls A[i] += block_result end some computation with sdata(A). If I use 4 processes, I get one result. With 8 processes, a diferent result. Without parallel processing, another one. I am probably losing something, but I think this is not the intended behaviour. I am using jula 4.11, fedora 23 - 64 bits. Thanks for your help.
Re: [julia-users] Re: Why does using behave the way it does with regards to remote workers?
On Thursday, November 26, 2015 at 6:43:06 AM UTC-5, Tim Holy wrote: > > At least in the past, I've seen undesired forced module reloading with the > @everywhere using X trick. "import X; @everywhere using X" should always work with Julia 0.4; you shouldn't need to serialize the "using X".
Re: [julia-users] Re: UTF8String string indexing and sizeof endof
PR: https://github.com/JuliaLang/julia/pull/14160 On Thursday, 26 November 2015 19:47:14 UTC+2, JobJob wrote: > > Only saw this after I filed the issue, but will prepare a PR shortly :) >
Re: [julia-users] Re: UTF8String string indexing and sizeof endof
Only saw this after I filed the issue, but will prepare a PR shortly :)
Re: [julia-users] Re: UTF8String string indexing and sizeof endof
Le jeudi 26 novembre 2015 à 09:04 -0800, JobJob a écrit : > Seems like if s[a:b] is intended to index into s.data, then the > indexing should be consistent with arrays and s[end] should give the > last byte, though since s[1] and s[5] return characters, not a single > byte, there's a little bit of conflict. > Ok I've found a lengthy discussion of this and related issues, and > looks like this behaviour is very likely going to change: > https://github.com/JuliaLang/julia/issues/9297 > > In related news, this looks like an actual bug: > > s = "🛀🛀" > s12 = s[1:2] # "🛀" > s56 = s[5:6] # "?" > sizeof(s12) # 4 > sizeof(s56) # 2 > > The issue seems to be that > nextind(s, 2) #5 > nextind(s, 6) #7 (prob should be 9) > > I think the fix is to change https://github.com/JuliaLang/julia/blob/ > master/base/strings/basic.jl#L141 to return sizeof(s)+1 > > Will file an issue. Good catch! Instead of filing an issue, could you directly apply the fix and make a pull request? Adding a test would also be a good idea to be sure we don't regress on this. Thanks! > Good talk. :) > Happy thanksgiving to those in the USA
[julia-users] BinDeps Sources, when a URL doesn't have an appropriate extension
Hi,
I'm trying to wrap a C library I've written. I want to use BinDeps to build
some source. The source is on our internal gitorious git server. A .tar.gz
of the code is available, but the URL to get that from just ends in the
branch name. So in my code I have
provides( Sources,
> URI("https://git0.rd.bbc.co.uk/misc/simpleexr/archive-tarball/master";) ,
> simpleexr)
>
and later
GetSources(simpleexr)
Which throws an error:
> LoadError: I don't know how to unpack
> /home/andrewg/.julia/v0.4/EXRImages/deps/downloads/master
>
Is there a way to insert an intermediate step to change the name of the
downloaded file from master to something.tar.gz? (Or indeed is there a way
to use the filename of the file which is returned from the server, which
does have the correct extension? As I think about, this seems a bit like a
bug.)
I guess a bit more code context will be useful:
provides( Sources,
>> URI("https://git0.rd.bbc.co.uk/misc/simpleexr/archive-tarball/master";) ,
>> simpleexr)
>
>
>> prefix = joinpath(BinDeps.depsdir(simpleexr),"usr")
>
> dldir = joinpath(BinDeps.depsdir(simpleexr),"downloads")
>
> provides(SimpleBuild,
>
> (@build_steps begin
>
> GetSources(simpleexr)
>
> @build_steps begin
>
> FileRule(joinpath(prefix,"lib","libsimpleexr.so"),
>> @build_steps begin
>
> `./build.sh`
>
> `cp libsimpleexr.so $prefix/lib`
>
> `cp libsimpleexr.so.1 $prefix/lib`
>
> `cp libsimpleexr.so.1.0 $prefix/lib`
>
> `cp libsimpleexr.h $prefix/include`
>
> end)
>
> end
>
> end
>
> )
>
> , simpleexr, os = :Linux)
>
>
I guess if Tim Holy sees this he'll suggest I use Images/ImageMagick to
read an exr image. If there's a way to access the pixel values stored in
the image before the gamma correction is applied I would gladly use it. The
last time I looked into it, I couldn't find any mention of this in
ImageMagick, though.
[julia-users] Re: UTF8String string indexing and sizeof endof
Seems like if s[a:b] is intended to index into s.data, then the indexing should be consistent with arrays and s[end] should give the last byte, though since s[1] and s[5] return characters, not a single byte, there's a little bit of conflict. Ok I've found a lengthy discussion of this and related issues, and looks like this behaviour is very likely going to change: https://github.com/JuliaLang/julia/issues/9297 In related news, this looks like an actual bug: s = "🛀🛀" s12 = s[1:2] # "🛀" s56 = s[5:6] # "?" sizeof(s12) # 4 sizeof(s56) # 2 The issue seems to be that nextind(s, 2) #5 nextind(s, 6) #7 (prob should be 9) I think the fix is to change https://github.com/JuliaLang/julia/blob/master/base/strings/basic.jl#L141 to return sizeof(s)+1 Will file an issue. Good talk. :) Happy thanksgiving to those in the USA
[julia-users] Spliting file in to multiple piecies
Macros are a much more powerful way of including code generation directly in your source code in Julia.
[julia-users] Spliting file in to multiple piecies
Some code for my calculation can be generated automatically with different
program. For now I just copy and paste the relevant output in my code which
now looks like
>
> function UnitTriangleIntegration(f::Function,NP=16)
>
>
>> xw = [0., 0., 0.]
>
>
>> if NP==16
>
> xw=[0.330.330.14431560767779
>
> 0.459292588292720.459292588292720.09509163426728
>
> 0.459292588292720.081414823414550.09509163426728
>
> 0.081414823414550.459292588292720.09509163426728
>
> 0.170569307751760.170569307751760.10321737053472
>
> 0.170569307751760.658861384496480.10321737053472
>
> 0.658861384496480.170569307751760.10321737053472
>
> 0.050547228317030.050547228317030.03245849762320
>
> 0.050547228317030.898905543365940.03245849762320
>
> 0.898905543365940.050547228317030.03245849762320
>
> 0.263112829634640.728492392955400.02723031417443
>
> 0.728492392955400.008394777409960.02723031417443
>
> 0.008394777409960.263112829634640.02723031417443
>
> 0.728492392955400.263112829634640.02723031417443
>
> 0.263112829634640.008394777409960.02723031417443
>
> 0.008394777409960.728492392955400.02723031417443]
>
> elseif NP==3
>
> xw = [0.170.170.33
>
> 0.170.670.33
>
> 0.670.170.33]
>
> end
>
>
>> s = 0
>
> for j in 1:NP
>
> xi = xw[j,1]
>
> eta = xw[j,2]
>
> w = xw[j,3]
>
>
>> s += f(xi,eta)*w/2
>
> end
>
> return s
>
> end
>
>
>> function ctrquad(f::Function,x::Array{Float64,2})
>
>
>> alpha1 = 1/(1 + norm(x[:,4]-x[:,2])/norm(x[:,4]-x[:,1]))
>
> beta1 = 1/(1 + norm(x[:,6]-x[:,3])/norm(x[:,6]-x[:,1]))
>
> gamma1 = 1/(1 + norm(x[:,5]-x[:,2])/norm(x[:,5]-x[:,3]))
>
>
>> f_(xi,eta) = begin
>
>
>> x_ = x[:,1]*(-eta - xi + 1 + eta^2/beta1 + eta*xi/beta1 -
>> eta/beta1 + eta*xi/alpha1 + xi^2/alpha1 - xi/alpha1) +
>> x[:,2]*(xi*(eta*(alpha1 - gamma1) + (alpha1 - xi)*(gamma1 - 1))/((alpha1 -
>> 1)*(gamma1 - 1))) + x[:,3]*(eta*(gamma1*(beta1 - eta) - xi*(beta1 + gamma1
>> - 1))/(gamma1*(beta1 - 1))) + x[:,4]*(xi*(eta + xi - 1)/(alpha1*(alpha1 -
>> 1))) + x[:,5]*(-eta*xi/(gamma1*(gamma1 - 1)))
>
> + x[:,6]*(eta*(eta + xi - 1)/(beta1*(beta1 - 1)))
>
>
>> e_xi = x[:,1]*(-1 + eta/beta1 + eta/alpha1 + 2*xi/alpha1 -
>> 1/alpha1) + x[:,2]*((eta*(alpha1 - gamma1) - xi*(gamma1 - 1) - (-alpha1 +
>> xi)*(gamma1 - 1))/((alpha1 - 1)*(gamma1 - 1))) + x[:,3]*(-eta*(beta1 +
>> gamma1 - 1)/(gamma1*(beta1 - 1))) + x[:,4]*((eta + 2*xi -
>> 1)/(alpha1*(alpha1 - 1))) + x[:,5]*(-eta/(gamma1*(gamma1 - 1))) +
>> x[:,6]*(eta/(beta1*(beta1 - 1)))
>
>
>> e_eta = x[:,1]*(-1 + 2*eta/beta1 + xi/beta1 - 1/beta1 +
>> xi/alpha1) + x[:,2]*(xi*(alpha1 - gamma1)/((alpha1 - 1)*(gamma1 - 1))) +
>> x[:,3]*(-(eta*gamma1 - gamma1*(beta1 - eta) + xi*(beta1 + gamma1 -
>> 1))/(gamma1*(beta1 - 1))) + x[:,4]*(xi/(alpha1*(alpha1 - 1))) +
>> x[:,5]*(-xi/(gamma1*(gamma1 - 1))) + x[:,6]*((2*eta + xi - 1)/(beta1*(beta1
>> - 1)))
>
>
>> f(x_,e_xi,e_eta)*norm(cross(e_xi,e_eta))
>
> end
>
>
>> UnitTriangleIntegration(f_,16)
>
> end
>
>
>>
>> ### Here is some testing
>
> x1 = [0.,0.,0.]
>
> x2 = [1.,0.,0.]
>
> x3 = [0.,1.,0.]
>
>
>> y = Array(Float64,3,6)
>
> y[:,1] = x1
>
> y[:,2] = x2
>
> y[:,3] = x3
>
> y[:,4] = (x1+x2)/2
>
> y[:,5] = (x2+x3)/2
>
> y[:,6] = (x1+x3)/2
>
>
>> area = ctrquad((x,exi,eeta) -> 1, y)
>
> I would like to put the code from ` f_(xi,eta) = begin .. end` outside
of this file as it is automaticaly generated. Trying to do it with
`include(...)` failed for me as it checks variables. What sugestions do
have splitting automaticaly generated code from the one which is human
writed? Also are there anything I can do to improve performance?
>
>>
>
Re: [julia-users] Re: Best practice for editing official packages?
Yeah. Come to think of it, that might be a good addition to the summary---it's not that common for PRs to be perfect the first time. Best, --Tim On Thursday, November 26, 2015 04:59:25 AM Cedric St-Jean wrote: > Then for subsequent commits: > > git remote add myfork https://github.com/username/ProjectName.jl.git # > > you only need to do this once > Everytime I want to push new changes to the pull request: > > git push myfork branch-name:pull-request/2c9f2b3f # 2c9... taken from > > the pull request page > ? > > Cédric > > On Thursday, November 26, 2015 at 6:45:39 AM UTC-5, Tim Holy wrote: > > An an executive summary here (will presumably be backported for 0.4.2): > > http://docs.julialang.org/en/latest/manual/packages/#executive-summary > > > > --Tim > > > > On Thursday, November 26, 2015 02:49:49 AM Avik Sengupta wrote: > > > The best practices are documented > > > > > here: > > http://docs.julialang.org/en/release-0.4/manual/packages/#code-changes > > > > > In summary, it is best to use your third approach. Pkg.submit() will > > > > fork > > > > > the github repo into your account. And Pkg.free() will get you back to > > > > the > > > > > released state of the package, which makes it safe to do the changes in > > > place, within .julia. > > > > > > Regards > > > - > > > Avik > > > > > > On Thursday, 26 November 2015 07:04:51 UTC, Eric Forgy wrote: > > > > I'm still learning the ropes. > > > > > > > > When I "Pkg.add" a Julia package, it produces a git repo in .julia. If > > > > I > > > > > > wanted to revise one of the packages, is it unadvised to modify it > > > > directly > > > > in the .julia repo if I ultimately intend to submit a PR? > > > > > > > > My first instinct was to clone the package somewhere other than .julia > > > > and > > > > > > then "Pkg.clone" from there, but that seems a bit roundabout. Hence my > > > > question. > > > > > > > > I tried the following which doesn't seem optimal: > > > >1. Fork the package on GitHub > > > >2. "git clone" the package somewhere other than .julia > > > >3. Pkg.clone from my local cloned repo (had problems with this > > > > because > > > > > >the package was already in .julia so deleted it first) > > > >4. Modify the package, commit and then Pkg.checkout > > > >5. Repeat step 3. until revision does what I want it to do > > > > > > > > - Steps 3. and 4. got me a LONG list of commits, so I introduced > > > > myself to "git rebase" with disastrous results. > > > > 6. Tried deleting the package from .julia so I could start over > > > > > > > >again with "Pkg.add", but Pkg seemed to have gotten confused from > > > > my > > > > > >shenanigans and says the package could not be found. > > > >7. Delete the Julia installation. Delete .julia and start again. > > > > > > > > Disaster :) > > > > > > > > My next attempt will be along these lines: > > > >1. Fork the package on GitHub > > > >2. Pkg.clone from my forked repo > > > >3. Modify the package directly from the .julia folder (hoping this > > > >will avoid a ton of commits) > > > >4. When everything works, commit and push to my forked repo on > > > > GitHub > > > > > >5. Submit a PR from GitHub > > > > > > > > How does that sound? Any better suggestions? > > > > > > > > Just before submitting this question, a possibly better solution > > > > dawned on > > > > > > me. Since I have already "Pkg.add"ed the package, a git repo is > > > > already in > > > > > > .julia so I might try: > > > >1. Fork the package on GitHub > > > >2. Modify the package already inside .julia > > > >3. Add my fork as a remote repo > > > >4. When everything works, commit and push to my forked remote repo > > > > on > > > > > >GitHub > > > >5. Submit a PR from GitHub > > > > > > > > How does that sound? What do others do? > > > > > > > > Note: The package I'm trying to modify is pure Julia so does not > > > > require > > > > > > any compiler.
Re: [julia-users] Re: Best practice for editing official packages?
Then for subsequent commits: > git remote add myfork https://github.com/username/ProjectName.jl.git # you > only need to do this once Everytime I want to push new changes to the pull request: > git push myfork branch-name:pull-request/2c9f2b3f # 2c9... taken from the > pull request page ? Cédric On Thursday, November 26, 2015 at 6:45:39 AM UTC-5, Tim Holy wrote: > > An an executive summary here (will presumably be backported for 0.4.2): > http://docs.julialang.org/en/latest/manual/packages/#executive-summary > > --Tim > > On Thursday, November 26, 2015 02:49:49 AM Avik Sengupta wrote: > > The best practices are documented > > here: > http://docs.julialang.org/en/release-0.4/manual/packages/#code-changes > > > > In summary, it is best to use your third approach. Pkg.submit() will > fork > > the github repo into your account. And Pkg.free() will get you back to > the > > released state of the package, which makes it safe to do the changes in > > place, within .julia. > > > > Regards > > - > > Avik > > > > On Thursday, 26 November 2015 07:04:51 UTC, Eric Forgy wrote: > > > I'm still learning the ropes. > > > > > > When I "Pkg.add" a Julia package, it produces a git repo in .julia. If > I > > > wanted to revise one of the packages, is it unadvised to modify it > > > directly > > > in the .julia repo if I ultimately intend to submit a PR? > > > > > > My first instinct was to clone the package somewhere other than .julia > and > > > then "Pkg.clone" from there, but that seems a bit roundabout. Hence my > > > question. > > > > > > I tried the following which doesn't seem optimal: > > >1. Fork the package on GitHub > > >2. "git clone" the package somewhere other than .julia > > >3. Pkg.clone from my local cloned repo (had problems with this > because > > >the package was already in .julia so deleted it first) > > >4. Modify the package, commit and then Pkg.checkout > > >5. Repeat step 3. until revision does what I want it to do > > > > > > - Steps 3. and 4. got me a LONG list of commits, so I introduced > > > myself to "git rebase" with disastrous results. > > > 6. Tried deleting the package from .julia so I could start over > > > > > >again with "Pkg.add", but Pkg seemed to have gotten confused from > my > > >shenanigans and says the package could not be found. > > >7. Delete the Julia installation. Delete .julia and start again. > > > > > > Disaster :) > > > > > > My next attempt will be along these lines: > > >1. Fork the package on GitHub > > >2. Pkg.clone from my forked repo > > >3. Modify the package directly from the .julia folder (hoping this > > >will avoid a ton of commits) > > >4. When everything works, commit and push to my forked repo on > GitHub > > >5. Submit a PR from GitHub > > > > > > How does that sound? Any better suggestions? > > > > > > Just before submitting this question, a possibly better solution > dawned on > > > me. Since I have already "Pkg.add"ed the package, a git repo is > already in > > > > > > .julia so I might try: > > >1. Fork the package on GitHub > > >2. Modify the package already inside .julia > > >3. Add my fork as a remote repo > > >4. When everything works, commit and push to my forked remote repo > on > > >GitHub > > >5. Submit a PR from GitHub > > > > > > How does that sound? What do others do? > > > > > > Note: The package I'm trying to modify is pure Julia so does not > require > > > any compiler. > >
[julia-users] Re: UTF8String string indexing and sizeof endof
I get that it's the index of the last code point, but mainly I was
surprised that
buf = IOBuffer()
write(buf, 0xf0, 0x9f, 0x9b, 0x80, 0xf0, 0x9f)
s = takebuf_string(buf)
convert(Vector{UInt8},s[chr2ind(s, length(s)):end])
returns [0xf0] not [0xf0, 0x9f]
[julia-users] UTF8String string indexing and sizeof endof
julia> s = "🛀🛀"
"🛀🛀"
julia> for i in 4:8
substr = s[1:i]
subbytes = convert(Vector{UInt8},substr)
@show "- 1:$i -" substr subbytes length(subbytes)
end
"- 1:$(i) -" = "- 1:4 -"
substr = "🛀"
subbytes = UInt8[0xf0,0x9f,0x9b,0x80]
length(subbytes) = 4
"- 1:$(i) -" = "- 1:5 -"
substr = "🛀🛀"
subbytes = UInt8[0xf0,0x9f,0x9b,0x80,0xf0,0x9f,0x9b,0x80]
length(subbytes) = 8
"- 1:$(i) -" = "- 1:6 -"
substr = "🛀?"
subbytes = UInt8[0xf0,0x9f,0x9b,0x80,0xf0,0x9f]
length(subbytes) = 6
"- 1:$(i) -" = "- 1:7 -"
substr = "🛀?"
subbytes = UInt8[0xf0,0x9f,0x9b,0x80,0xf0,0x9f,0x9b]
length(subbytes) = 7
"- 1:$(i) -" = "- 1:8 -"
substr = "🛀🛀"
subbytes = UInt8[0xf0,0x9f,0x9b,0x80,0xf0,0x9f,0x9b,0x80]
length(subbytes) = 8
julia> @show endof(s) sizeof(s);
endof(s) = 5
sizeof(s) = 8
I would've thought s[1:5] would give me [0xf0,0x9f,0x9b,0x80,0xf0] and an
invalid second char, much like s[1:6] and s[1:7].
Also why is endof(s) 5 and not 8?
Re: [julia-users] Re: Best practice for editing official packages?
An an executive summary here (will presumably be backported for 0.4.2): http://docs.julialang.org/en/latest/manual/packages/#executive-summary --Tim On Thursday, November 26, 2015 02:49:49 AM Avik Sengupta wrote: > The best practices are documented > here: http://docs.julialang.org/en/release-0.4/manual/packages/#code-changes > > In summary, it is best to use your third approach. Pkg.submit() will fork > the github repo into your account. And Pkg.free() will get you back to the > released state of the package, which makes it safe to do the changes in > place, within .julia. > > Regards > - > Avik > > On Thursday, 26 November 2015 07:04:51 UTC, Eric Forgy wrote: > > I'm still learning the ropes. > > > > When I "Pkg.add" a Julia package, it produces a git repo in .julia. If I > > wanted to revise one of the packages, is it unadvised to modify it > > directly > > in the .julia repo if I ultimately intend to submit a PR? > > > > My first instinct was to clone the package somewhere other than .julia and > > then "Pkg.clone" from there, but that seems a bit roundabout. Hence my > > question. > > > > I tried the following which doesn't seem optimal: > >1. Fork the package on GitHub > >2. "git clone" the package somewhere other than .julia > >3. Pkg.clone from my local cloned repo (had problems with this because > >the package was already in .julia so deleted it first) > >4. Modify the package, commit and then Pkg.checkout > >5. Repeat step 3. until revision does what I want it to do > > > > - Steps 3. and 4. got me a LONG list of commits, so I introduced > > myself to "git rebase" with disastrous results. > > 6. Tried deleting the package from .julia so I could start over > > > >again with "Pkg.add", but Pkg seemed to have gotten confused from my > >shenanigans and says the package could not be found. > >7. Delete the Julia installation. Delete .julia and start again. > > > > Disaster :) > > > > My next attempt will be along these lines: > >1. Fork the package on GitHub > >2. Pkg.clone from my forked repo > >3. Modify the package directly from the .julia folder (hoping this > >will avoid a ton of commits) > >4. When everything works, commit and push to my forked repo on GitHub > >5. Submit a PR from GitHub > > > > How does that sound? Any better suggestions? > > > > Just before submitting this question, a possibly better solution dawned on > > me. Since I have already "Pkg.add"ed the package, a git repo is already in > > > > .julia so I might try: > >1. Fork the package on GitHub > >2. Modify the package already inside .julia > >3. Add my fork as a remote repo > >4. When everything works, commit and push to my forked remote repo on > >GitHub > >5. Submit a PR from GitHub > > > > How does that sound? What do others do? > > > > Note: The package I'm trying to modify is pure Julia so does not require > > any compiler.
Re: [julia-users] Re: Why does using behave the way it does with regards to remote workers?
More directly: https://github.com/JuliaLang/julia/issues/9245 The other main "gotcha": https://github.com/JuliaLang/julia/issues/3674 At least in the past, I've seen undesired forced module reloading with the @everywhere using X trick. But for me this version works reliably: for p in workers() remotecall_fetch(p, eval, :(using X)) end Finally, I'd call both of these bugs, and if someone finds time to fix them it would be awesome. --Tim On Wednesday, November 25, 2015 05:41:21 PM Steven G. Johnson wrote: > Right now, the best way to bring a module into scope on all workers is > > import FooModule > @everywhere using FooModule > > > the first line loads it globally does not bring FooModule's exported > symbols into the local namespaces, whereas the second line imports the > exported symbols. > > I agree that this is a bit confusing; this is a known issue. > See https://github.com/JuliaLang/julia/issues/12381
Re: [julia-users] Memory-efficient / in-place allocation of array subsets?
Actually, it's possible my test is misleading because of the way finalizers are
currently handled. You might want to experiment with calling gc twice yourself
in your memory-exhaustion scenario and see what happens.
--Tim
On Wednesday, November 25, 2015 04:56:28 PM Gord Stephen wrote:
> Ok, good to know. Thanks!
>
> Gord
>
> On Tuesday, November 24, 2015 at 9:38:18 PM UTC-5, Tim Holy wrote:
> > On Tuesday, November 24, 2015 04:53:11 PM Gord Stephen wrote:
> > > The problem arises when I need to repeat the process more than once -
> >
> > when
> >
> > > the SubArrays become out of scope they're garbage collected but A isn't
> >
> > - a
> >
> > > second call to demo2() then exceeds available memory.
> >
> > That sounds like a bug. Indeed, I can (sort of) reproduce this:
> >
> > julia> function foo()
> >
> >A = rand(3,5)
> >B = sub(A, 1:2, 3:4)
> >finalizer(A, A->@schedule(println("GCed A")))
> >B
> >
> >end
> >
> > foo (generic function with 1 method)
> >
> > julia> B = foo()
> > 2x2
> >
> >
SubArray{Float64,2,Array{Float64,2},Tuple{UnitRange{Int64},UnitRange{Int64}},1}:
> > 0.583567 0.719624
> > 0.60663 0.739911
> >
> > julia> B = 0
> > 0
> >
> > julia> gc()
> >
> >
> > But call gc() immediately again, and it gets cleaned up:
> >
> > julia> gc()
> > GCed A
> >
> > I filed an issue:
> > https://github.com/JuliaLang/julia/issues/14127
> >
> > --Tim
[julia-users] Re: Best practice for editing official packages?
The best practices are documented here: http://docs.julialang.org/en/release-0.4/manual/packages/#code-changes In summary, it is best to use your third approach. Pkg.submit() will fork the github repo into your account. And Pkg.free() will get you back to the released state of the package, which makes it safe to do the changes in place, within .julia. Regards - Avik On Thursday, 26 November 2015 07:04:51 UTC, Eric Forgy wrote: > > I'm still learning the ropes. > > When I "Pkg.add" a Julia package, it produces a git repo in .julia. If I > wanted to revise one of the packages, is it unadvised to modify it directly > in the .julia repo if I ultimately intend to submit a PR? > > My first instinct was to clone the package somewhere other than .julia and > then "Pkg.clone" from there, but that seems a bit roundabout. Hence my > question. > > I tried the following which doesn't seem optimal: > >1. Fork the package on GitHub >2. "git clone" the package somewhere other than .julia >3. Pkg.clone from my local cloned repo (had problems with this because >the package was already in .julia so deleted it first) >4. Modify the package, commit and then Pkg.checkout >5. Repeat step 3. until revision does what I want it to do > - Steps 3. and 4. got me a LONG list of commits, so I introduced > myself to "git rebase" with disastrous results. > 6. Tried deleting the package from .julia so I could start over >again with "Pkg.add", but Pkg seemed to have gotten confused from my >shenanigans and says the package could not be found. >7. Delete the Julia installation. Delete .julia and start again. > > Disaster :) > > My next attempt will be along these lines: > >1. Fork the package on GitHub >2. Pkg.clone from my forked repo >3. Modify the package directly from the .julia folder (hoping this >will avoid a ton of commits) >4. When everything works, commit and push to my forked repo on GitHub >5. Submit a PR from GitHub > > How does that sound? Any better suggestions? > > Just before submitting this question, a possibly better solution dawned on > me. Since I have already "Pkg.add"ed the package, a git repo is already in > .julia so I might try: > >1. Fork the package on GitHub >2. Modify the package already inside .julia >3. Add my fork as a remote repo >4. When everything works, commit and push to my forked remote repo on >GitHub >5. Submit a PR from GitHub > > How does that sound? What do others do? > > Note: The package I'm trying to modify is pure Julia so does not require > any compiler. >
