[julia-users] Re: Peculiarly slow matrix multiplication

[Micah McClimans]

And, as I'm sure you're aware- just as I was immediately after I posted 
this, that second loop is completely superfluous.

On Wednesday, January 21, 2015 at 1:56:19 AM UTC-5, Micah McClimans wrote:
>
> I'm running into trouble with a line of matrix multiplication going very 
> slowly in one of my programs. The line I'm looking into is:
> objectivematrix=shrt*diagm(expr)*(shrt')
> where shrt is 12,000x600 and expr is 600 long. This line takes several 
> HOURS to run, on a computer that can run
>
> k=rand(12000,12000)
> k3=k*k*k
>
> in under a minute. I've tried devectorizing the line into the following 
> loop (shrt is block-diagonal with each block ONevecs and -ONevecs 
> respectively, so I split the loop in half)
>
> objectivematrix=zeros(2*size(ONevecs,1),2*size(ONevecs,1))
> for i in 1:size(ONevecs,1)
> print(i)
> for j in 1:size(ONevecs,1)
> for k in 1:size(ONevecs,2)
> objectivematrix[i,j]+=ONevecs[i,k]*ONevecs[j,k]*expr[k]
> end
> end
> end
> for i in 1:size(ONevecs,1)
> print(i)
> for j in 1:size(ONevecs,1)
> for k in 1:size(ONevecs,2)
> 
> objectivematrix[i+size(ONevecs,1),j+size(ONevecs,1)]+=ONevecs[i,k]*ONevecs[j,k]*expr[k+size(ONevecs,2)]
> end
> end
>
> end
>
> and this give a print out every couple seconds- it's faster than the 
> matrix multiplication version, but not enough. Why is this taking so long? 
> This should not be a hard operation.
>

[julia-users] Peculiarly slow matrix multiplication

[Micah McClimans]

I'm running into trouble with a line of matrix multiplication going very 
slowly in one of my programs. The line I'm looking into is:
objectivematrix=shrt*diagm(expr)*(shrt')
where shrt is 12,000x600 and expr is 600 long. This line takes several 
HOURS to run, on a computer that can run

k=rand(12000,12000)
k3=k*k*k

in under a minute. I've tried devectorizing the line into the following 
loop (shrt is block-diagonal with each block ONevecs and -ONevecs 
respectively, so I split the loop in half)

objectivematrix=zeros(2*size(ONevecs,1),2*size(ONevecs,1))
for i in 1:size(ONevecs,1)
print(i)
for j in 1:size(ONevecs,1)
for k in 1:size(ONevecs,2)
objectivematrix[i,j]+=ONevecs[i,k]*ONevecs[j,k]*expr[k]
end
end
end
for i in 1:size(ONevecs,1)
print(i)
for j in 1:size(ONevecs,1)
for k in 1:size(ONevecs,2)

objectivematrix[i+size(ONevecs,1),j+size(ONevecs,1)]+=ONevecs[i,k]*ONevecs[j,k]*expr[k+size(ONevecs,2)]
end
end

end

and this give a print out every couple seconds- it's faster than the matrix 
multiplication version, but not enough. Why is this taking so long? This 
should not be a hard operation.

Re: [julia-users] ERROR: Cannot horizonatally stack expressions of varying number of rows

[Kevin Squire]

Got it!  A google

 search

suggests
that it should be reported here:
https://github.com/JuliaOpt/Convex.jl/issues.

Cheers! Kevin

On Tue, Jan 20, 2015 at 9:56 PM, Anonymous  wrote:

> horizonatally should be horizontally, it's just a misspelling.
>
> On Tuesday, January 20, 2015 at 9:53:45 PM UTC-8, Kevin Squire wrote:
>>
>> Right place, and a true statement, but without more context, it would be
>> hard to act on or offer suggestions.  Care to give an example of what
>> you're trying to do? :-)
>>
>> Cheers,
>>Kevin
>>
>> On Tue, Jan 20, 2015 at 9:33 PM, Anonymous  wrote:
>>
>>> horizonatally
>>>
>>> I trust y'all will get this to the right people, where it can do some
>>> good.
>>>
>>
>>

Re: [julia-users] ERROR: Cannot horizonatally stack expressions of varying number of rows

[Anonymous]

horizonatally should be horizontally, it's just a misspelling.

On Tuesday, January 20, 2015 at 9:53:45 PM UTC-8, Kevin Squire wrote:
>
> Right place, and a true statement, but without more context, it would be 
> hard to act on or offer suggestions.  Care to give an example of what 
> you're trying to do? :-)
>
> Cheers,
>Kevin
>
> On Tue, Jan 20, 2015 at 9:33 PM, Anonymous 
> > wrote:
>
>> horizonatally 
>>
>> I trust y'all will get this to the right people, where it can do some 
>> good.
>>
>
>

Re: [julia-users] ERROR: Cannot horizonatally stack expressions of varying number of rows

[Kevin Squire]

Right place, and a true statement, but without more context, it would be
hard to act on or offer suggestions.  Care to give an example of what
you're trying to do? :-)

Cheers,
   Kevin

On Tue, Jan 20, 2015 at 9:33 PM, Anonymous  wrote:

> horizonatally
>
> I trust y'all will get this to the right people, where it can do some good.
>

[julia-users] ERROR: Cannot horizonatally stack expressions of varying number of rows

[Anonymous]

horizonatally 

I trust y'all will get this to the right people, where it can do some good.

Re: [julia-users] Re: workflow recommendation/tutorial

[Viral Shah]

Should we capture this in the documentation somewhere? This is generally a 
useful set of hints for newcomers.

-viral

On Wednesday, January 21, 2015 at 5:38:29 AM UTC+5:30, Tim Holy wrote:
>
> Agreed there are advantages in putting ones test script into a module. 
> There 
> is also at least one disadvantage: if you get an error, you don't already 
> have 
> the "state" prepared to examine the variables you'll be passing as 
> arguments, 
> try the call with slightly different arguments, etc., from the REPL. 
>
> But this is a small point, and either strategy can work fine. 
>
> Best, 
> --Tim 
>
> On Tuesday, January 20, 2015 04:01:14 PM Petr Krysl wrote: 
> > I think it would be worthwhile to point out  that enclosing  the code of 
> > one's "scratch" file  in a module  has a number of advantages. 
> > 
> > 1. The  global workspace is not polluted  with too many variables and 
> > conflicts are avoided. 
> > 2. The  variables  defined within that module  are accessible from the 
> REPL 
> > as if the variables were defined at the global level. 
> > 
> > Example: 
> > 
> > module m1 
> > 
> > using JFinEALE 
> > 
> > t0 = time() 
> > 
> > rho=1.21*1e-9;# mass density 
> > c =345.0*1000;# millimeters per second 
> > bulk= c^2*rho; 
> > Lx=1900.0;# length of the box, millimeters 
> > Ly=800.0; # length of the box, millimeters 
> > 
> > fens,fes = Q4block(Lx,Ly,3,2); # Mesh 
> > show(fes.conn) 
> > 
> > end 
> > 
> > julia> include("./module_env.jl") 
> > Warning: replacing module m1 
> > [1 2 6 5 
> >  5 6 10 9 
> >  2 3 7 6 
> >  6 7 11 10 
> >  3 4 8 7 
> >  7 8 12 11] 
> > julia> m1. # I hit the tab key at this point, and I got this list of 
> > variables that I can access 
> > Lx   Lybulk  c eval  fens  fes   rho   t0 
> > 
> > I'm sure this is no news to the Julian  wizards, but to a newbie like me 
> it 
> > is useful information.  (I haven't seen this in the documentation. 
> > Perhaps it is there,  but  if that is not the case I would be all for 
> > adding it in.) 
> > 
> > Petr 
> > 
> > On Tuesday, January 20, 2015 at 1:45:02 PM UTC-8, Jameson wrote: 
> > > My workflow is very similar. I'll add that I'll make a throwaway 
> module 
> > > ("MyModuleTests") so that I can use "using" in the test file. Doing 
> this 
> > > at 
> > > the REPL (defining a new module directly at the prompt) is also a nice 
> way 
> > > of encapsulating a chunk of code to isolate it from existing 
> definitions 
> > > (including old using statements). It's also similar to how I'll use a 
> > > large 
> > > begin/end block to group a large chunk of initialization code so that 
> I 
> > > can 
> > > iterate and rerun it easily. 
> > > On Tue, Jan 20, 2015 at 4:34 PM Tim Holy  > 
> > > 
> > > wrote: 
> > >> My workflow (REPL-based, Juno in particular is probably different): 
> > >> - Open a file ("MyModule.jl") that will consist of a single module, 
> and 
> > >> contains types & code 
> > >> - Open a 2nd file ("mymodule_tests.jl") that will be the tests file 
> for 
> > >> the 
> > >> module. Inside of this file, say `import MyModule` rather than `using 
> > >> MyModule`; you'll have to scope all calls, but that's a small price 
> to 
> > >> pay for 
> > >> the ability to `reload("MyModule")` and re-run your tests. 
> > >> - Open a julia REPL 
> > >> - Start playing with ideas/code in the REPL. Paste the good ones into 
> the 
> > >> files. And sometimes vice-versa, when it's easier to type straight 
> into 
> > >> the 
> > >> files. 
> > >> - When enough code is in place, restart the repl. Cycle through 
> > >> 
> > >> reload("MyModule") 
> > >> include("mymodule_tests.jl") 
> > >>  
> > >> 
> > >> until things actually work. 
> > >> 
> > >> --Tim 
> > >> 
> > >> On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote: 
> > >> > This is pretty much the workflow a lot of people use, with a few 
> julia 
> > >> > restarts to deal with the issues a) and b). I often maintain a 
> script 
> > >> > as 
> > >> > part of my iterative/exploratory work, so that I can easily get to 
> the 
> > >> > desired state when I have to restart. 
> > >> > 
> > >> > -viral 
> > >> > 
> > >> > On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp 
> wrote: 
> > >> > > Hi, 
> > >> > > 
> > >> > > I am wondering what the best workflow is for 
> iterative/exploratory 
> > >> > > programming (as opposed to, say, library development).  I feel 
> that 
> > >> > > my 
> > >> > > questions below all have solutions, it's just that I am not 
> > >> 
> > >> experienced 
> > >> 
> > >> > > enough in Julia to figure them out. 
> > >> > > 
> > >> > > The way I have been doing it so far: 
> > >> > > 1. open a file in the editor, 
> > >> > > 2. start `using` some libraries, 
> > >> > > 3. write a few functions, load data, plot, analyze 
> > >> > > 4. rewrite functions, repeat 2-4 until satisfied. 
> > >> > > 
> > >> > > I usually end up with a bunch of functions, followed by the 
> actual 
> > >> > > runtime code. 
> > >> > > 

Re: [julia-users] Re: Almost at 500 packages!

[Viral Shah]

Yes, METADATA packages should be pretty usable when someone downloads them. 
Now that we have the documentation on new documentation, packages can start 
including docs too. I wonder if we can set a minimum code coverage 
requirement, and if we can somehow also measure doc coverage for exported 
functions.

-viral

On Wednesday, January 21, 2015 at 2:57:01 AM UTC+5:30, Stefan Karpinski 
wrote:
>
> Packages registered in METADATA should be pretty usable – they should 
> generally have some tests and those tests should pass. They should also 
> have documentation. We haven't been very strict about enforcing all of 
> this, but I think that going forward we ought to be.
>
> On Tue, Jan 20, 2015 at 4:08 PM, Luthaf  wrote:
>
>> If you do accept unfinished and very alpha package, I can submit one 
>> right now ...
>>
>> It won't be very usable, but I am wondering about how finished should be 
>> a package when submitted to METADATA.
>>
>> Viral Shah a écrit : 
>>
>> I wonder what the 500th package will be.
>>
>> -viral
>>
>> On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote:
>>>
>>> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
>>> registered packages with at least one version tagged that are Julia 0.4-dev 
>>> compatible (493 on Julia 0.3).
>>>
>>> Thanks to all the package developers for their efforts in growing the 
>>> Julia package ecosystem!
>>>
>>>  
>

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Jeff Bezanson]

That's surprising; I get the same speedup in 0.3 with

function test2()
f = CFunction{Float64,Float64}(foo)
for i=1:1
r = call(f, 1.0)
goo(r)
end
end

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Keith Mason]

I tried that, but it was slower than my initial method of calling f().

I even tried called ccall directly, but it also didn't solve the problem of 
type instability (which makes me feel like I'm missing something 
important), and it had an additional problem of not accepting its type 
arguments as variables.

I'm going to try 0.4 tomorrow and see how it goes.

On Tuesday, January 20, 2015 at 10:06:40 PM UTC-6, Jeff Bezanson wrote:
>
> Oops, that's right, `call` only exists in 0.4. Probably the quickest 
> way to make this work in 0.3 is to write `call(f, x)` instead of 
> `f(x)` where needed. 
>
> On Tue, Jan 20, 2015 at 10:14 PM, Keith Mason  > wrote: 
> > When I try this, I get an error: 
> > 
> > ERROR: type: test2: in apply, expected Function, got 
> > CFunction{Float64,Float64} 
> > 
> > 
> > It looks like "call" doesn't exist in version 0.3.  I suppose I need 0.4 
> to 
> > make this work.  It doesn't appear from the docs that call used to be 
> named 
> > something else. 
> > 
> > 
> > On Tuesday, January 20, 2015 at 4:54:08 PM UTC-6, Jeff Bezanson wrote: 
> >> 
> >> Here is a hack that basically works by escaping through the C type 
> system: 
> >> 
> >> ``` 
> >> immutable CFunction{R,A} 
> >> f 
> >> p::Ptr{Void} 
> >> CFunction(f) = new(f, cfunction(f, R, (A,))) 
> >> end 
> >> 
> >> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x) 
> >> 
> >> foo(x::Float64) = 0.0 
> >> goo(x::Float64) = x 
> >> 
> >> function test1() 
> >> for i=1:1 
> >> f = foo 
> >> r = f(1.0) 
> >> goo(r) 
> >> end 
> >> end 
> >> 
> >> function test2() 
> >> f = CFunction{Float64,Float64}(foo) 
> >> for i=1:1 
> >> r = f(1.0) 
> >> goo(r) 
> >> end 
> >> end 
> >> ``` 
> >> 
> >> I added an argument to `foo` to increase the generality somewhat. 
> >> test1() is the original test case. test2() is the new version. The 
> >> CFunction object needs to be constructed outside the loop, but this 
> >> can be stored in a data structure and reused anywhere. 
> >> 
> >> -Jeff 
> >> 
> >> 
> >> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote: 
> >> > Originally posted at https://github.com/JuliaLang/julia/issues/9863 
> > 
> > 
> > 
> > 
> > Please click here for important information regarding this e-mail 
> > communication. 
>

-- 


Please click here 
 for 
important information regarding this e-mail communication.

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Jeff Bezanson]

Oops, that's right, `call` only exists in 0.4. Probably the quickest
way to make this work in 0.3 is to write `call(f, x)` instead of
`f(x)` where needed.

On Tue, Jan 20, 2015 at 10:14 PM, Keith Mason  wrote:
> When I try this, I get an error:
>
> ERROR: type: test2: in apply, expected Function, got
> CFunction{Float64,Float64}
>
>
> It looks like "call" doesn't exist in version 0.3.  I suppose I need 0.4 to
> make this work.  It doesn't appear from the docs that call used to be named
> something else.
>
>
> On Tuesday, January 20, 2015 at 4:54:08 PM UTC-6, Jeff Bezanson wrote:
>>
>> Here is a hack that basically works by escaping through the C type system:
>>
>> ```
>> immutable CFunction{R,A}
>> f
>> p::Ptr{Void}
>> CFunction(f) = new(f, cfunction(f, R, (A,)))
>> end
>>
>> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x)
>>
>> foo(x::Float64) = 0.0
>> goo(x::Float64) = x
>>
>> function test1()
>> for i=1:1
>> f = foo
>> r = f(1.0)
>> goo(r)
>> end
>> end
>>
>> function test2()
>> f = CFunction{Float64,Float64}(foo)
>> for i=1:1
>> r = f(1.0)
>> goo(r)
>> end
>> end
>> ```
>>
>> I added an argument to `foo` to increase the generality somewhat.
>> test1() is the original test case. test2() is the new version. The
>> CFunction object needs to be constructed outside the loop, but this
>> can be stored in a data structure and reused anywhere.
>>
>> -Jeff
>>
>>
>> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote:
>> > Originally posted at https://github.com/JuliaLang/julia/issues/9863
>
>
>
>
> Please click here for important information regarding this e-mail
> communication.

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Keith Mason]

When I try this, I get an error:

ERROR: type: test2: in apply, expected Function, got 
CFunction{Float64,Float64}


It looks like "call" doesn't exist in version 0.3.  I suppose I need 0.4 to 
make this work.  It doesn't appear from the docs that call used to be named 
something else.

On Tuesday, January 20, 2015 at 4:54:08 PM UTC-6, Jeff Bezanson wrote:
>
> Here is a hack that basically works by escaping through the C type system: 
>
> ``` 
> immutable CFunction{R,A} 
> f 
> p::Ptr{Void} 
> CFunction(f) = new(f, cfunction(f, R, (A,))) 
> end 
>
> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x) 
>
> foo(x::Float64) = 0.0 
> goo(x::Float64) = x 
>
> function test1() 
> for i=1:1 
> f = foo 
> r = f(1.0) 
> goo(r) 
> end 
> end 
>
> function test2() 
> f = CFunction{Float64,Float64}(foo) 
> for i=1:1 
> r = f(1.0) 
> goo(r) 
> end 
> end 
> ``` 
>
> I added an argument to `foo` to increase the generality somewhat. 
> test1() is the original test case. test2() is the new version. The 
> CFunction object needs to be constructed outside the loop, but this 
> can be stored in a data structure and reused anywhere. 
>
> -Jeff 
>
>
> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  > wrote: 
> > Originally posted at https://github.com/JuliaLang/julia/issues/9863 
>

-- 


Please click here 
 for 
important information regarding this e-mail communication.

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Keith Mason]

It is, but I created a form that forces it to not be inlined, and that 
still runs in just 30 ms.

On Tuesday, January 20, 2015 at 4:57:00 PM UTC-6, Jeff Bezanson wrote:
>
> Oh, I should also mention that the version that calls goo(foo()) takes 
> so little time because the entire loop is probably optimized out. 
>
> On Tue, Jan 20, 2015 at 5:54 PM, Jeff Bezanson  > wrote: 
> > Here is a hack that basically works by escaping through the C type 
> system: 
> > 
> > ``` 
> > immutable CFunction{R,A} 
> > f 
> > p::Ptr{Void} 
> > CFunction(f) = new(f, cfunction(f, R, (A,))) 
> > end 
> > 
> > call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x) 
> > 
> > foo(x::Float64) = 0.0 
> > goo(x::Float64) = x 
> > 
> > function test1() 
> > for i=1:1 
> > f = foo 
> > r = f(1.0) 
> > goo(r) 
> > end 
> > end 
> > 
> > function test2() 
> > f = CFunction{Float64,Float64}(foo) 
> > for i=1:1 
> > r = f(1.0) 
> > goo(r) 
> > end 
> > end 
> > ``` 
> > 
> > I added an argument to `foo` to increase the generality somewhat. 
> > test1() is the original test case. test2() is the new version. The 
> > CFunction object needs to be constructed outside the loop, but this 
> > can be stored in a data structure and reused anywhere. 
> > 
> > -Jeff 
> > 
> > 
> > On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  > wrote: 
> >> Originally posted at https://github.com/JuliaLang/julia/issues/9863 
>

-- 


Please click here 
 for 
important information regarding this e-mail communication.

Re: [julia-users] Re: PetSc interface in Julia

[yi lu]

That is great!

On Wed, Jan 21, 2015 at 4:46 AM, Steven G. Johnson 
wrote:

> I'm hoping to have some time to work on this over the next few days.
>

Re: [julia-users] Re: workflow recommendation/tutorial

[Tim Holy]

Agreed there are advantages in putting ones test script into a module. There 
is also at least one disadvantage: if you get an error, you don't already have 
the "state" prepared to examine the variables you'll be passing as arguments, 
try the call with slightly different arguments, etc., from the REPL.

But this is a small point, and either strategy can work fine.

Best,
--Tim

On Tuesday, January 20, 2015 04:01:14 PM Petr Krysl wrote:
> I think it would be worthwhile to point out  that enclosing  the code of
> one's "scratch" file  in a module  has a number of advantages.
> 
> 1. The  global workspace is not polluted  with too many variables and
> conflicts are avoided.
> 2. The  variables  defined within that module  are accessible from the REPL
> as if the variables were defined at the global level.
> 
> Example:
> 
> module m1
> 
> using JFinEALE
> 
> t0 = time()
> 
> rho=1.21*1e-9;# mass density
> c =345.0*1000;# millimeters per second
> bulk= c^2*rho;
> Lx=1900.0;# length of the box, millimeters
> Ly=800.0; # length of the box, millimeters
> 
> fens,fes = Q4block(Lx,Ly,3,2); # Mesh
> show(fes.conn)
> 
> end
> 
> julia> include("./module_env.jl")
> Warning: replacing module m1
> [1 2 6 5
>  5 6 10 9
>  2 3 7 6
>  6 7 11 10
>  3 4 8 7
>  7 8 12 11]
> julia> m1. # I hit the tab key at this point, and I got this list of
> variables that I can access
> Lx   Lybulk  c eval  fens  fes   rho   t0
> 
> I'm sure this is no news to the Julian  wizards, but to a newbie like me it
> is useful information.  (I haven't seen this in the documentation.
> Perhaps it is there,  but  if that is not the case I would be all for
> adding it in.)
> 
> Petr
> 
> On Tuesday, January 20, 2015 at 1:45:02 PM UTC-8, Jameson wrote:
> > My workflow is very similar. I'll add that I'll make a throwaway module
> > ("MyModuleTests") so that I can use "using" in the test file. Doing this
> > at
> > the REPL (defining a new module directly at the prompt) is also a nice way
> > of encapsulating a chunk of code to isolate it from existing definitions
> > (including old using statements). It's also similar to how I'll use a
> > large
> > begin/end block to group a large chunk of initialization code so that I
> > can
> > iterate and rerun it easily.
> > On Tue, Jan 20, 2015 at 4:34 PM Tim Holy >
> > 
> > wrote:
> >> My workflow (REPL-based, Juno in particular is probably different):
> >> - Open a file ("MyModule.jl") that will consist of a single module, and
> >> contains types & code
> >> - Open a 2nd file ("mymodule_tests.jl") that will be the tests file for
> >> the
> >> module. Inside of this file, say `import MyModule` rather than `using
> >> MyModule`; you'll have to scope all calls, but that's a small price to
> >> pay for
> >> the ability to `reload("MyModule")` and re-run your tests.
> >> - Open a julia REPL
> >> - Start playing with ideas/code in the REPL. Paste the good ones into the
> >> files. And sometimes vice-versa, when it's easier to type straight into
> >> the
> >> files.
> >> - When enough code is in place, restart the repl. Cycle through
> >> 
> >> reload("MyModule")
> >> include("mymodule_tests.jl")
> >> 
> >> 
> >> until things actually work.
> >> 
> >> --Tim
> >> 
> >> On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote:
> >> > This is pretty much the workflow a lot of people use, with a few julia
> >> > restarts to deal with the issues a) and b). I often maintain a script
> >> > as
> >> > part of my iterative/exploratory work, so that I can easily get to the
> >> > desired state when I have to restart.
> >> > 
> >> > -viral
> >> > 
> >> > On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
> >> > > Hi,
> >> > > 
> >> > > I am wondering what the best workflow is for iterative/exploratory
> >> > > programming (as opposed to, say, library development).  I feel that
> >> > > my
> >> > > questions below all have solutions, it's just that I am not
> >> 
> >> experienced
> >> 
> >> > > enough in Julia to figure them out.
> >> > > 
> >> > > The way I have been doing it so far:
> >> > > 1. open a file in the editor,
> >> > > 2. start `using` some libraries,
> >> > > 3. write a few functions, load data, plot, analyze
> >> > > 4. rewrite functions, repeat 2-4 until satisfied.
> >> > > 
> >> > > I usually end up with a bunch of functions, followed by the actual
> >> > > runtime code.
> >> > > 
> >> > > However, I run into the following issues (or, rather, inconveniences)
> >> > > with nontrivial code:
> >> > > 
> >> > > a. If I redefine a function, then I have to recompile dependent
> >> > > functions, which is tedious and occasionally a source of bugs
> >> > > (cf. https://github.com/JuliaLang/julia/issues/265 )
> >> > > 
> >> > > b. I can't redefine types.
> >> > > 
> >> > > I can solve both by restarting (`workspace()`), but then I have to
> >> > > reload & recompile everything.
> >> > > 
> >> > > I am wondering if there is a more organized way of doing this --- eg
> >> 
> >> put

Re: [julia-users] Re: workflow recommendation/tutorial

[Petr Krysl]

I think it would be worthwhile to point out  that enclosing  the code of 
one's "scratch" file  in a module  has a number of advantages.

1. The  global workspace is not polluted  with too many variables and  
conflicts are avoided.
2. The  variables  defined within that module  are accessible from the REPL 
as if the variables were defined at the global level.

Example:

module m1

using JFinEALE

t0 = time()

rho=1.21*1e-9;# mass density
c =345.0*1000;# millimeters per second
bulk= c^2*rho;
Lx=1900.0;# length of the box, millimeters
Ly=800.0; # length of the box, millimeters

fens,fes = Q4block(Lx,Ly,3,2); # Mesh
show(fes.conn)

end

julia> include("./module_env.jl")
Warning: replacing module m1
[1 2 6 5
 5 6 10 9
 2 3 7 6
 6 7 11 10
 3 4 8 7
 7 8 12 11]
julia> m1. # I hit the tab key at this point, and I got this list of 
variables that I can access
Lx   Lybulk  c eval  fens  fes   rho   t0

I'm sure this is no news to the Julian  wizards, but to a newbie like me it 
is useful information.  (I haven't seen this in the documentation.   
Perhaps it is there,  but  if that is not the case I would be all for 
adding it in.)

Petr

On Tuesday, January 20, 2015 at 1:45:02 PM UTC-8, Jameson wrote:
>
> My workflow is very similar. I'll add that I'll make a throwaway module 
> ("MyModuleTests") so that I can use "using" in the test file. Doing this at 
> the REPL (defining a new module directly at the prompt) is also a nice way 
> of encapsulating a chunk of code to isolate it from existing definitions 
> (including old using statements). It's also similar to how I'll use a large 
> begin/end block to group a large chunk of initialization code so that I can 
> iterate and rerun it easily. 
> On Tue, Jan 20, 2015 at 4:34 PM Tim Holy > 
> wrote:
>
>> My workflow (REPL-based, Juno in particular is probably different):
>> - Open a file ("MyModule.jl") that will consist of a single module, and
>> contains types & code
>> - Open a 2nd file ("mymodule_tests.jl") that will be the tests file for 
>> the
>> module. Inside of this file, say `import MyModule` rather than `using
>> MyModule`; you'll have to scope all calls, but that's a small price to 
>> pay for
>> the ability to `reload("MyModule")` and re-run your tests.
>> - Open a julia REPL
>> - Start playing with ideas/code in the REPL. Paste the good ones into the
>> files. And sometimes vice-versa, when it's easier to type straight into 
>> the
>> files.
>> - When enough code is in place, restart the repl. Cycle through
>> reload("MyModule")
>> include("mymodule_tests.jl")
>> 
>> until things actually work.
>>
>> --Tim
>>
>> On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote:
>> > This is pretty much the workflow a lot of people use, with a few julia
>> > restarts to deal with the issues a) and b). I often maintain a script as
>> > part of my iterative/exploratory work, so that I can easily get to the
>> > desired state when I have to restart.
>> >
>> > -viral
>> >
>> > On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
>> > > Hi,
>> > >
>> > > I am wondering what the best workflow is for iterative/exploratory
>> > > programming (as opposed to, say, library development).  I feel that my
>> > > questions below all have solutions, it's just that I am not 
>> experienced
>> > > enough in Julia to figure them out.
>> > >
>> > > The way I have been doing it so far:
>> > > 1. open a file in the editor,
>> > > 2. start `using` some libraries,
>> > > 3. write a few functions, load data, plot, analyze
>> > > 4. rewrite functions, repeat 2-4 until satisfied.
>> > >
>> > > I usually end up with a bunch of functions, followed by the actual
>> > > runtime code.
>> > >
>> > > However, I run into the following issues (or, rather, inconveniences)
>> > > with nontrivial code:
>> > >
>> > > a. If I redefine a function, then I have to recompile dependent
>> > > functions, which is tedious and occasionally a source of bugs
>> > > (cf. https://github.com/JuliaLang/julia/issues/265 )
>> > >
>> > > b. I can't redefine types.
>> > >
>> > > I can solve both by restarting (`workspace()`), but then I have to
>> > > reload & recompile everything.
>> > >
>> > > I am wondering if there is a more organized way of doing this --- eg 
>> put
>> > > some stuff in a module in a separate file and just keep reloading 
>> that,
>> > > etc. Any advice, or pointers to tutorials would be appreciated.
>> > >
>> > > I am using Emacs/ESS.
>> > >
>> > > Also, is there a way to unintern symbols (a la CL) that would solve 
>> the
>> > > type redefinition issue?
>> > >
>> > > Best,
>> > >
>> > > Tamas
>>
>>  

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Jeff Bezanson]

The `cfunction` here has the effect of manually hoisting the method
lookup in the call to `f`, so it is indeed necessary. The
StableFunction only has the effect of automatically changing f() to
f()::Float64 (which Keith already tried above), which is also useful
but not as fast.

On Tue, Jan 20, 2015 at 6:02 PM, Erik Schnetter  wrote:
> I the `cfunction` necessary here? Since you already have the return type `R`, 
> wouldn't it suffice to annotate the call with a `::R` suffix? I am thinking:
>
> immutable StableFunction{R,A}
> f
> StableFunction(f) = new(f)
> end
>
> call{R,A}(f::StableFunction{R,A}, x) = f(x)::R
>
> -erik
>
>> On Jan 20, 2015, at 17:56 , Jeff Bezanson  wrote:
>>
>> Oh, I should also mention that the version that calls goo(foo()) takes
>> so little time because the entire loop is probably optimized out.
>>
>> On Tue, Jan 20, 2015 at 5:54 PM, Jeff Bezanson  
>> wrote:
>>> Here is a hack that basically works by escaping through the C type system:
>>>
>>> ```
>>> immutable CFunction{R,A}
>>>f
>>>p::Ptr{Void}
>>>CFunction(f) = new(f, cfunction(f, R, (A,)))
>>> end
>>>
>>> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x)
>>>
>>> foo(x::Float64) = 0.0
>>> goo(x::Float64) = x
>>>
>>> function test1()
>>>for i=1:1
>>>f = foo
>>>r = f(1.0)
>>>goo(r)
>>>end
>>> end
>>>
>>> function test2()
>>>f = CFunction{Float64,Float64}(foo)
>>>for i=1:1
>>>r = f(1.0)
>>>goo(r)
>>>end
>>> end
>>> ```
>>>
>>> I added an argument to `foo` to increase the generality somewhat.
>>> test1() is the original test case. test2() is the new version. The
>>> CFunction object needs to be constructed outside the loop, but this
>>> can be stored in a data structure and reused anywhere.
>>>
>>> -Jeff
>>>
>>>
>>> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote:
 Originally posted at https://github.com/JuliaLang/julia/issues/9863
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from https://sks-keyservers.net.
>

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Erik Schnetter]

I the `cfunction` necessary here? Since you already have the return type `R`, 
wouldn't it suffice to annotate the call with a `::R` suffix? I am thinking:

immutable StableFunction{R,A}
f
StableFunction(f) = new(f)
end

call{R,A}(f::StableFunction{R,A}, x) = f(x)::R

-erik

> On Jan 20, 2015, at 17:56 , Jeff Bezanson  wrote:
> 
> Oh, I should also mention that the version that calls goo(foo()) takes
> so little time because the entire loop is probably optimized out.
> 
> On Tue, Jan 20, 2015 at 5:54 PM, Jeff Bezanson  
> wrote:
>> Here is a hack that basically works by escaping through the C type system:
>> 
>> ```
>> immutable CFunction{R,A}
>>f
>>p::Ptr{Void}
>>CFunction(f) = new(f, cfunction(f, R, (A,)))
>> end
>> 
>> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x)
>> 
>> foo(x::Float64) = 0.0
>> goo(x::Float64) = x
>> 
>> function test1()
>>for i=1:1
>>f = foo
>>r = f(1.0)
>>goo(r)
>>end
>> end
>> 
>> function test2()
>>f = CFunction{Float64,Float64}(foo)
>>for i=1:1
>>r = f(1.0)
>>goo(r)
>>end
>> end
>> ```
>> 
>> I added an argument to `foo` to increase the generality somewhat.
>> test1() is the original test case. test2() is the new version. The
>> CFunction object needs to be constructed outside the loop, but this
>> can be stored in a data structure and reused anywhere.
>> 
>> -Jeff
>> 
>> 
>> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote:
>>> Originally posted at https://github.com/JuliaLang/julia/issues/9863

--
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Jeff Bezanson]

Oh, I should also mention that the version that calls goo(foo()) takes
so little time because the entire loop is probably optimized out.

On Tue, Jan 20, 2015 at 5:54 PM, Jeff Bezanson  wrote:
> Here is a hack that basically works by escaping through the C type system:
>
> ```
> immutable CFunction{R,A}
> f
> p::Ptr{Void}
> CFunction(f) = new(f, cfunction(f, R, (A,)))
> end
>
> call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x)
>
> foo(x::Float64) = 0.0
> goo(x::Float64) = x
>
> function test1()
> for i=1:1
> f = foo
> r = f(1.0)
> goo(r)
> end
> end
>
> function test2()
> f = CFunction{Float64,Float64}(foo)
> for i=1:1
> r = f(1.0)
> goo(r)
> end
> end
> ```
>
> I added an argument to `foo` to increase the generality somewhat.
> test1() is the original test case. test2() is the new version. The
> CFunction object needs to be constructed outside the loop, but this
> can be stored in a data structure and reused anywhere.
>
> -Jeff
>
>
> On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote:
>> Originally posted at https://github.com/JuliaLang/julia/issues/9863

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Jeff Bezanson]

Here is a hack that basically works by escaping through the C type system:

```
immutable CFunction{R,A}
f
p::Ptr{Void}
CFunction(f) = new(f, cfunction(f, R, (A,)))
end

call{R,A}(f::CFunction{R,A}, x) = ccall(f.p, R, (A,), x)

foo(x::Float64) = 0.0
goo(x::Float64) = x

function test1()
for i=1:1
f = foo
r = f(1.0)
goo(r)
end
end

function test2()
f = CFunction{Float64,Float64}(foo)
for i=1:1
r = f(1.0)
goo(r)
end
end
```

I added an argument to `foo` to increase the generality somewhat.
test1() is the original test case. test2() is the new version. The
CFunction object needs to be constructed outside the loop, but this
can be stored in a data structure and reused anywhere.

-Jeff


On Tue, Jan 20, 2015 at 4:34 PM, Ivar Nesje  wrote:
> Originally posted at https://github.com/JuliaLang/julia/issues/9863

Re: [julia-users] Re: workflow recommendation/tutorial

[Jameson Nash]

My workflow is very similar. I'll add that I'll make a throwaway module
("MyModuleTests") so that I can use "using" in the test file. Doing this at
the REPL (defining a new module directly at the prompt) is also a nice way
of encapsulating a chunk of code to isolate it from existing definitions
(including old using statements). It's also similar to how I'll use a large
begin/end block to group a large chunk of initialization code so that I can
iterate and rerun it easily.
On Tue, Jan 20, 2015 at 4:34 PM Tim Holy  wrote:

> My workflow (REPL-based, Juno in particular is probably different):
> - Open a file ("MyModule.jl") that will consist of a single module, and
> contains types & code
> - Open a 2nd file ("mymodule_tests.jl") that will be the tests file for the
> module. Inside of this file, say `import MyModule` rather than `using
> MyModule`; you'll have to scope all calls, but that's a small price to pay
> for
> the ability to `reload("MyModule")` and re-run your tests.
> - Open a julia REPL
> - Start playing with ideas/code in the REPL. Paste the good ones into the
> files. And sometimes vice-versa, when it's easier to type straight into the
> files.
> - When enough code is in place, restart the repl. Cycle through
> reload("MyModule")
> include("mymodule_tests.jl")
> 
> until things actually work.
>
> --Tim
>
> On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote:
> > This is pretty much the workflow a lot of people use, with a few julia
> > restarts to deal with the issues a) and b). I often maintain a script as
> > part of my iterative/exploratory work, so that I can easily get to the
> > desired state when I have to restart.
> >
> > -viral
> >
> > On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
> > > Hi,
> > >
> > > I am wondering what the best workflow is for iterative/exploratory
> > > programming (as opposed to, say, library development).  I feel that my
> > > questions below all have solutions, it's just that I am not experienced
> > > enough in Julia to figure them out.
> > >
> > > The way I have been doing it so far:
> > > 1. open a file in the editor,
> > > 2. start `using` some libraries,
> > > 3. write a few functions, load data, plot, analyze
> > > 4. rewrite functions, repeat 2-4 until satisfied.
> > >
> > > I usually end up with a bunch of functions, followed by the actual
> > > runtime code.
> > >
> > > However, I run into the following issues (or, rather, inconveniences)
> > > with nontrivial code:
> > >
> > > a. If I redefine a function, then I have to recompile dependent
> > > functions, which is tedious and occasionally a source of bugs
> > > (cf. https://github.com/JuliaLang/julia/issues/265 )
> > >
> > > b. I can't redefine types.
> > >
> > > I can solve both by restarting (`workspace()`), but then I have to
> > > reload & recompile everything.
> > >
> > > I am wondering if there is a more organized way of doing this --- eg
> put
> > > some stuff in a module in a separate file and just keep reloading that,
> > > etc. Any advice, or pointers to tutorials would be appreciated.
> > >
> > > I am using Emacs/ESS.
> > >
> > > Also, is there a way to unintern symbols (a la CL) that would solve the
> > > type redefinition issue?
> > >
> > > Best,
> > >
> > > Tamas
>
>

[julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Ivar Nesje]

Originally posted at https://github.com/JuliaLang/julia/issues/9863

Re: [julia-users] Re: workflow recommendation/tutorial

[Tim Holy]

My workflow (REPL-based, Juno in particular is probably different):
- Open a file ("MyModule.jl") that will consist of a single module, and 
contains types & code
- Open a 2nd file ("mymodule_tests.jl") that will be the tests file for the 
module. Inside of this file, say `import MyModule` rather than `using 
MyModule`; you'll have to scope all calls, but that's a small price to pay for 
the ability to `reload("MyModule")` and re-run your tests.
- Open a julia REPL
- Start playing with ideas/code in the REPL. Paste the good ones into the 
files. And sometimes vice-versa, when it's easier to type straight into the 
files.
- When enough code is in place, restart the repl. Cycle through
reload("MyModule")
include("mymodule_tests.jl")

until things actually work.

--Tim

On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote:
> This is pretty much the workflow a lot of people use, with a few julia
> restarts to deal with the issues a) and b). I often maintain a script as
> part of my iterative/exploratory work, so that I can easily get to the
> desired state when I have to restart.
> 
> -viral
> 
> On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
> > Hi,
> > 
> > I am wondering what the best workflow is for iterative/exploratory
> > programming (as opposed to, say, library development).  I feel that my
> > questions below all have solutions, it's just that I am not experienced
> > enough in Julia to figure them out.
> > 
> > The way I have been doing it so far:
> > 1. open a file in the editor,
> > 2. start `using` some libraries,
> > 3. write a few functions, load data, plot, analyze
> > 4. rewrite functions, repeat 2-4 until satisfied.
> > 
> > I usually end up with a bunch of functions, followed by the actual
> > runtime code.
> > 
> > However, I run into the following issues (or, rather, inconveniences)
> > with nontrivial code:
> > 
> > a. If I redefine a function, then I have to recompile dependent
> > functions, which is tedious and occasionally a source of bugs
> > (cf. https://github.com/JuliaLang/julia/issues/265 )
> > 
> > b. I can't redefine types.
> > 
> > I can solve both by restarting (`workspace()`), but then I have to
> > reload & recompile everything.
> > 
> > I am wondering if there is a more organized way of doing this --- eg put
> > some stuff in a module in a separate file and just keep reloading that,
> > etc. Any advice, or pointers to tutorials would be appreciated.
> > 
> > I am using Emacs/ESS.
> > 
> > Also, is there a way to unintern symbols (a la CL) that would solve the
> > type redefinition issue?
> > 
> > Best,
> > 
> > Tamas

Re: [julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Mauro]

Have a look at
https://groups.google.com/d/msg/julia-dev/JEiH96ofclY/_amm9Cah6YAJ there
are some hack-y solutions mentioned there.  If I recall correctly, using
a constructor instead of a function can solve the problem.

On Tue, 2015-01-20 at 22:16, Keith Mason  wrote:
> I am trying to make use of functions as data, where I store functions in an 
> array and call them in a loop. All of my functions return Float64, but 
> because I am assigning the function to a variable before calling it, Julia 
> can't figure that out.
>
> Here's some example code:
>
> foo() = 0.0
> goo(x::Float64) = x
>
> So if I am to call goo(foo()), this is quite type stable and results in 
> virtually no code. If I call it in a loop 100,000,000 times, it takes about 
> a millisecond.
>
> However, if I do this:
>
> function test1()
>   for i=1:1
> f = foo
> r = f()
> goo(r)
>   end
> end
>
> Now I'm in trouble. Even though Julia knows that foo returns a float, it 
> doesn't know that f returns a float. This code in a loop of 100,000,000 
> takes nearly 8 seconds and allocates 32GB of RAM. (Honestly, this strikes 
> me as an optimization that just doesn't yet exist, but my use case is a 
> little more complicated; in my case, f can be one of multiple functions, 
> selected by a parameter. But let's set that aside for the purposes of this 
> question.)
>
> Declaring the type of the variable doesn't help; in fact, it makes it worse:
>
> function test2()
>   for i=1:1
> f = foo
> r::Float64 = f()
> goo(r)
>   end
> end
>
> But I can improve the situation a bit by casting the result of the function.
>
> function test3()
>   for i=1:1
> f = foo
> r = f()::Float64
> goo(r)
>   end
> end
>
> This cuts run time and memory allocation in half. But it is still taking 
> too long because it has to check if f returns a float before assigning it 
> to t. @code_lowered shows that a call to typeassert is the culprit here. Is 
> there any way I can promise Julia that f returns float so it doesn't have 
> to call typeassert? I tried
>
> f::Function{Float64} = foo
>
> and
>
> f::Function::Float64
>
> but I can't find any syntax that works. I know there is a macro @inbounds 
>  to turn off bounds checking; is there 
> something similar that turns off type checking?

Re: [julia-users] Re: Almost at 500 packages!

[Stefan Karpinski]

Packages registered in METADATA should be pretty usable – they should
generally have some tests and those tests should pass. They should also
have documentation. We haven't been very strict about enforcing all of
this, but I think that going forward we ought to be.

On Tue, Jan 20, 2015 at 4:08 PM, Luthaf  wrote:

> If you do accept unfinished and very alpha package, I can submit one right
> now ...
>
> It won't be very usable, but I am wondering about how finished should be a
> package when submitted to METADATA.
>
> Viral Shah a écrit :
>
> I wonder what the 500th package will be.
>
> -viral
>
> On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote:
>>
>> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499
>> registered packages with at least one version tagged that are Julia 0.4-dev
>> compatible (493 on Julia 0.3).
>>
>> Thanks to all the package developers for their efforts in growing the
>> Julia package ecosystem!
>>
>>

[julia-users] convincing Julia that a function call (via a variable) has a stable return type

[Keith Mason]

I am trying to make use of functions as data, where I store functions in an 
array and call them in a loop. All of my functions return Float64, but 
because I am assigning the function to a variable before calling it, Julia 
can't figure that out.

Here's some example code:

foo() = 0.0
goo(x::Float64) = x

So if I am to call goo(foo()), this is quite type stable and results in 
virtually no code. If I call it in a loop 100,000,000 times, it takes about 
a millisecond.

However, if I do this:

function test1()
  for i=1:1
f = foo
r = f()
goo(r)
  end
end

Now I'm in trouble. Even though Julia knows that foo returns a float, it 
doesn't know that f returns a float. This code in a loop of 100,000,000 
takes nearly 8 seconds and allocates 32GB of RAM. (Honestly, this strikes 
me as an optimization that just doesn't yet exist, but my use case is a 
little more complicated; in my case, f can be one of multiple functions, 
selected by a parameter. But let's set that aside for the purposes of this 
question.)

Declaring the type of the variable doesn't help; in fact, it makes it worse:

function test2()
  for i=1:1
f = foo
r::Float64 = f()
goo(r)
  end
end

But I can improve the situation a bit by casting the result of the function.

function test3()
  for i=1:1
f = foo
r = f()::Float64
goo(r)
  end
end

This cuts run time and memory allocation in half. But it is still taking 
too long because it has to check if f returns a float before assigning it 
to t. @code_lowered shows that a call to typeassert is the culprit here. Is 
there any way I can promise Julia that f returns float so it doesn't have 
to call typeassert? I tried

f::Function{Float64} = foo

and

f::Function::Float64

but I can't find any syntax that works. I know there is a macro @inbounds 
 to turn off bounds checking; is there 
something similar that turns off type checking?

-- 


Please click here 
 for 
important information regarding this e-mail communication.

[julia-users] Re: workflow recommendation/tutorial

[Viral Shah]

This is pretty much the workflow a lot of people use, with a few julia 
restarts to deal with the issues a) and b). I often maintain a script as 
part of my iterative/exploratory work, so that I can easily get to the 
desired state when I have to restart.

-viral

On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
>
> Hi, 
>
> I am wondering what the best workflow is for iterative/exploratory 
> programming (as opposed to, say, library development).  I feel that my 
> questions below all have solutions, it's just that I am not experienced 
> enough in Julia to figure them out. 
>
> The way I have been doing it so far: 
> 1. open a file in the editor, 
> 2. start `using` some libraries, 
> 3. write a few functions, load data, plot, analyze 
> 4. rewrite functions, repeat 2-4 until satisfied. 
>
> I usually end up with a bunch of functions, followed by the actual 
> runtime code. 
>
> However, I run into the following issues (or, rather, inconveniences) 
> with nontrivial code: 
>
> a. If I redefine a function, then I have to recompile dependent 
> functions, which is tedious and occasionally a source of bugs 
> (cf. https://github.com/JuliaLang/julia/issues/265 ) 
>
> b. I can't redefine types. 
>
> I can solve both by restarting (`workspace()`), but then I have to 
> reload & recompile everything. 
>
> I am wondering if there is a more organized way of doing this --- eg put 
> some stuff in a module in a separate file and just keep reloading that, 
> etc. Any advice, or pointers to tutorials would be appreciated. 
>
> I am using Emacs/ESS. 
>
> Also, is there a way to unintern symbols (a la CL) that would solve the 
> type redefinition issue? 
>
> Best, 
>
> Tamas 
>

Re: [julia-users] Re: Almost at 500 packages!

[Luthaf]

If you do accept unfinished and very alpha package, I can submit one 
right now ...


It won't be very usable, but I am wondering about how finished should be 
a package when submitted to METADATA.


Viral Shah a écrit :

I wonder what the 500th package will be.

-viral

On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote:

Just noticed on http://pkg.julialang.org/pulse.html
 that we are at 499
registered packages with at least one version tagged that are
Julia 0.4-dev compatible (493 on Julia 0.3).

Thanks to all the package developers for their efforts in growing
the Julia package ecosystem!

[julia-users] Re: comparing compilation times for matlab and julia

[Viral Shah]

With Jameson's work on static compilation and very early work towards 
interpreting Julia code, this will get addressed, but not in the near 
future.

-viral

On Tuesday, January 20, 2015 at 12:11:45 AM UTC+5:30, Gray Calhoun wrote:
>
> Hi Christian, you can certainly make the code-writing process
> much faster by splitting large functions into many distinct
> smaller functions. In your example (which I've only skimmed),
> `mimosimu` looks like it directly implements and annotates
> several similar but different algorithms which could all be
> separate functions. Compilation happens at the function level,
> not the file level, and shorter functions compile (and usually
> run) much faster.
>
> Also, loading part of a file is something that editors can handle
> as well, so if there aren't satisfactory packages (I haven't
> tried the Autoreload.jl package recommended in the last thread,
> but it looks promising), using an editor like Emacs (with ESS) or
> Light Table (with Juno) could help. I'm sure there are lots of
> other editors that do this too, but those are the two I'm
> familiar with.
>
> On Sunday, January 18, 2015 at 10:04:58 PM UTC-6, Christian Peel wrote:
>>
>> I'm enjoying learning Julia.
>>
>> I have the same toy script written in Matlab and Julia at the following 
>> URL: 
>>  https://github.com/ChristianPeel/toySims/tree/master/mimoToys
>> Running the following in matlab
>>  tic; mimoUPtoy(200,4,4,4,0,12,12,[-10:5:30]); toc
>> takes about 0.82 seconds on a specific machine.  In contrast, with Julia 
>> I first need to 'include' it, then the first time through the compiler 
>> takes around 7 seconds to compile the code and execute it. Subsequent 
>> executions of the code have speed similar to Matlab.  
>>  julia> tic(); include("mimoUPtoy.jl"); toc()
>>  elapsed time: 0.348886314 seconds
>>  0.348886314
>>  julia> tic(); mimoUPtoy(200,4,4,4,0,12,12,[-10.0:5:30]); toq()
>> ...output...
>> 7.002885787
>> julia> tic(); mimoUPtoy(200,4,4,4,0,12,12,[-10.0:5:30]); toq()
>> ...output...
>> 0.860070365
>> Some questions are (1) is there is some improvement in 0.4 or otherwise 
>> which would improve the initial JIT time?  (2) is there any way to only 
>> recompile the parts of a file that have changed? Say by using a hash on a 
>> function to see if it has changed?  (3) I'm used to the Matlab development 
>> cycle in which I don't need to 'include' anything (it's done automatically) 
>> and also any JIT compilation that Matlab does is very fast and is 
>> essentially not noticable.   So even though Matlab may be slower for code 
>> execution, it feels faster for code development.  Is there anything that 
>> can be done to Julia to make the code writing process quicker?  Is there a 
>> way to automate the 'include' process?
>>
>> I acknowledge that one option to speed compilation time is to break 
>> mimoUPtoy.jl into separate files. I'm also sure that there are things that 
>> can be improved in both my Matlab and Julia code.   Finally; this function 
>> is similar to that which I refered to in a previous post (I was busy at the 
>> time and didn't get the code posted)
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/peel/julia-users/thR_80jtE2Q/ymV5i-AXmKkJ
>>
>>

[julia-users] Re: PetSc interface in Julia

[Steven G. Johnson]

I'm hoping to have some time to work on this over the next few days.

[julia-users] Re: Almost at 500 packages!

[Viral Shah]

I wonder what the 500th package will be.

-viral

On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote:
>
> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
> registered packages with at least one version tagged that are Julia 0.4-dev 
> compatible (493 on Julia 0.3).
>
> Thanks to all the package developers for their efforts in growing the 
> Julia package ecosystem!
>
>

[julia-users] Re: PetSc interface in Julia

[Viral Shah]

I replied in the GSoC thread, but this is a better thread to have this 
discussion in. Here's what I said:

Thanks to Amit's recent work on MPI.jl and ClusterManager.jl, we now have 
the ability to run MPI libraries and Julia's parallel libraries in the same 
program. Until recently, one could only have one of them, but not both 
simultaneously. 

I think this is important for the development of parallel libraries in 
Julia, where we can use existing MPI libraries where they exist and write 
new ones as needed. PetSc is huge - but we can start chipping away at it 
now.

-viral

On Tuesday, January 20, 2015 at 5:15:46 AM UTC+5:30, Eka Palamadai wrote:
>
> Just wanted to check if any work has been done on integrating PetSc into 
> Julia?
> I notice Stevenj has done some work on this, and there was some discussion 
> about a student working on this last year as part of the google project.
> Would appreciate any updates.
>
> Thanks,
> Eka
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Viral Shah]

Thanks to Amit's recent work on MPI.jl and ClusterManager.jl, we now have 
the ability to run MPI libraries and Julia's parallel libraries in the same 
program. Until recently, one could only have one of them, but not both 
simultaneously. 

I think this is important for the development of parallel libraries in 
Julia, where we can use existing MPI libraries where they exist and write 
new ones as needed. PetSc is huge - but we can start chipping away at it 
now.

-viral

On Tuesday, January 20, 2015 at 5:18:29 AM UTC+5:30, Eka Palamadai wrote:
>
> Chris,
>
> Just wanted to check about the progress you made about integrating PetSc 
> in Julia.
> Could you pls let me know the status of this project?
>
> Thanks,
> Eka
>
>
>
> On Thursday, February 20, 2014 at 8:54:33 PM UTC-5, Christopher Fusting 
> wrote:
>>
>> Great.  I'm going to start poking around PETSc.  Any guidance you have is 
>> welcome :)
>>
>> _Chris
>>
>> On Wednesday, February 19, 2014 7:01:51 PM UTC-5, Jiahao Chen wrote:
>>>
>>> If no one else volunteers, it's quite likely that that responsibility 
>>> will devolve to me. There's certainly plenty of work to do to improve 
>>> the base numerical library, so any interest there is much welcomed. 
>>>
>>> Thanks, 
>>>
>>> Jiahao Chen, PhD 
>>> Staff Research Scientist 
>>> MIT Computer Science and Artificial Intelligence Laboratory 
>>>
>>>
>>> On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting  
>>> wrote: 
>>> > I may be interested in filling the student role of a project under 
>>> > scalability of big data applications, specifically PETSc integration 
>>> and 
>>> > solvers for numerical linear alegbra.  Has anyone expressed interest 
>>> in 
>>> > mentoring these projects?  I've been developing software for years but 
>>> have 
>>> > recently returned to school to study mathematics.  Could be lots of 
>>> fun :) 
>>>
>>

[julia-users] Re: 0.4 Documentation System

[andy hayden]

Thanks for that answer, that makes sense, I'll PR a mention of that on the 
documentation page. :)


Did you see my comment here: 
https://github.com/JuliaLang/julia/issues/8966#issuecomment-70600813

I couldn't get a MetaDoc type working, but had a crack at it here: 
https://gist.github.com/hayd/bdddb51dc7df89b9a24e would be great to know 
what I'm missing - would be very interesting to get something like that 
working.

p.s. Fab to see Documentation in Julia - looking forward to it spreading 
through base.


On Tuesday, 20 January 2015 09:43:32 UTC-8, Michael Hatherly wrote:
>
> At the moment it’s main purpose is so that you can write literal $ 
> characters in your docstrings without
> worrying about inadvertent string interpolation. Quite handy if you’re 
> writing latex in your docstrings.
>
> — Mike
> ​
>
>
> On Tuesday, 20 January 2015 19:11:26 UTC+2, andy hayden wrote:
>>
>> One thing that seems unclear, at least to me, is the distinction (if any) 
>> between doc"...", md"..." (md isn't exported in Base) and "..." (just a 
>> string).
>>
>> It doesn't seem that it matters which we use e.g. the following are 
>> equivalent:
>>
>> @doc "foo `bar` baz" -> function foo() end
>> @doc doc"foo `bar` baz" -> function foo() end
>>
>> On Tuesday, 20 January 2015 09:02:31 UTC-8, Michael Hatherly wrote:
>>>
>>> No problem, glad that part’s working now.
>>>
>>> To view Docile-generated help you need to call using Lexicon, which 
>>> hooks into Julia’s help system and adds the help entries generated by 
>>> Docile. If you’ve not got Lexicon installed you can call 
>>> Pkg.add("Lexicon") to install it.
>>>
>>> — Mike
>>> On Tuesday, 20 January 2015 18:35:20 UTC+2, Yuuki Soho wrote:

 I had a problem with my packages (it was even crashing on update...), I 
 reinstalled the packages from scratch and the error is gone. I should have 
 checked that first, sorry.

 That said I'm not sure it's working properly, that's what I get (I 
 renamed the test function above test1):

 help?> test1
 INFO: Loading help data...
 test1 (generic function with 1 method)

[julia-users] RFC Display of markdown sections in terminal

[andy hayden]

I posted a PR about this, but would like to gauge thoughts on what 
formatting for headings (purely in the REPL e.g. in help messages 
- elsewhere e.g. in html, they are rendered differently).

I tentatively put:

julia> Base.Markdown.parse("#Title")
   Title
  -=-

julia> Base.Markdown.parse("##Section")
  Section
 -–––-

julia> Base.Markdown.parse("###Subsection")
Subsection
––

Though, as I comment in the PR, personally I dislike centered headings (I 
find them difficult to read) and prefer left-aligned. Do others feel the 
same/have other/better ideas for this?

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

Re: [julia-users] Re: 0.4 Documentation System

[Tim Holy]

Better yet would be to put such information into the documentation page
http://docs.julialang.org/en/latest/manual/documentation/

--Tim

On Tuesday, January 20, 2015 09:43:32 AM Michael Hatherly wrote:
> At the moment it’s main purpose is so that you can write literal $
> characters in your docstrings without
> worrying about inadvertent string interpolation. Quite handy if you’re
> writing latex in your docstrings.
> 
> — Mike
> ​
> 
> On Tuesday, 20 January 2015 19:11:26 UTC+2, andy hayden wrote:
> > One thing that seems unclear, at least to me, is the distinction (if any)
> > between doc"...", md"..." (md isn't exported in Base) and "..." (just a
> > string).
> > 
> > It doesn't seem that it matters which we use e.g. the following are
> > equivalent:
> > 
> > @doc "foo `bar` baz" -> function foo() end
> > @doc doc"foo `bar` baz" -> function foo() end
> > 
> > On Tuesday, 20 January 2015 09:02:31 UTC-8, Michael Hatherly wrote:
> >> No problem, glad that part’s working now.
> >> 
> >> To view Docile-generated help you need to call using Lexicon, which
> >> hooks into Julia’s help system and adds the help entries generated by
> >> Docile. If you’ve not got Lexicon installed you can call
> >> Pkg.add("Lexicon") to install it.
> >> 
> >> — Mike
> >> 
> >> On Tuesday, 20 January 2015 18:35:20 UTC+2, Yuuki Soho wrote:
> >>> I had a problem with my packages (it was even crashing on update...), I
> >>> reinstalled the packages from scratch and the error is gone. I should
> >>> have
> >>> checked that first, sorry.
> >>> 
> >>> That said I'm not sure it's working properly, that's what I get (I
> >>> renamed the test function above test1):
> >>> 
> >>> help?> test1
> >>> INFO: Loading help data...
> >>> test1 (generic function with 1 method)

[julia-users] Re: event based simulation / protocol simulator (in julia)

[Yee Sian Ng]

I'm not familiar with protocol simulators, but might SimJulia 
 (a package for discrete events 
simulation, inspired by SimPy) suit your needs? We've just had a class on 
it (slides here 
),
 
and Iain has a blogpost 
 on it 
too.

On Tuesday, 20 January 2015 04:02:41 UTC-5, Andreas Lobinger wrote:
>
> Hello colleagues,
>
> i scanned the usual sources, but didn't find a clear answer.
> Is there any project looking at using julia to build a protocol simulator?
>
> Wishing a happy day,
>Andreas
>
> P.S. I'm not a protocol expert ...
>
>

[julia-users] Re: workflow recommendation/tutorial

[Gray Calhoun]

Seconded. If anyone has time to just record a 5 minute screencast
of "working productively in Julia" I think he or she would have a
moderately sized but very appreciative audience.

On Tuesday, January 20, 2015 at 4:45:13 AM UTC-6, Tamas Papp wrote:
>
> Hi, 
>
> I am wondering what the best workflow is for iterative/exploratory 
> programming (as opposed to, say, library development).  I feel that my 
> questions below all have solutions, it's just that I am not experienced 
> enough in Julia to figure them out. 
>
> The way I have been doing it so far: 
> 1. open a file in the editor, 
> 2. start `using` some libraries, 
> 3. write a few functions, load data, plot, analyze 
> 4. rewrite functions, repeat 2-4 until satisfied. 
>
> I usually end up with a bunch of functions, followed by the actual 
> runtime code. 
>
> However, I run into the following issues (or, rather, inconveniences) 
> with nontrivial code: 
>
> a. If I redefine a function, then I have to recompile dependent 
> functions, which is tedious and occasionally a source of bugs 
> (cf. https://github.com/JuliaLang/julia/issues/265 ) 
>
> b. I can't redefine types. 
>
> I can solve both by restarting (`workspace()`), but then I have to 
> reload & recompile everything. 
>
> I am wondering if there is a more organized way of doing this --- eg put 
> some stuff in a module in a separate file and just keep reloading that, 
> etc. Any advice, or pointers to tutorials would be appreciated. 
>
> I am using Emacs/ESS. 
>
> Also, is there a way to unintern symbols (a la CL) that would solve the 
> type redefinition issue? 
>
> Best, 
>
> Tamas 
>

[julia-users] Re: 0.4 Documentation System

[Michael Hatherly]

At the moment it’s main purpose is so that you can write literal $ 
characters in your docstrings without
worrying about inadvertent string interpolation. Quite handy if you’re 
writing latex in your docstrings.

— Mike
​


On Tuesday, 20 January 2015 19:11:26 UTC+2, andy hayden wrote:
>
> One thing that seems unclear, at least to me, is the distinction (if any) 
> between doc"...", md"..." (md isn't exported in Base) and "..." (just a 
> string).
>
> It doesn't seem that it matters which we use e.g. the following are 
> equivalent:
>
> @doc "foo `bar` baz" -> function foo() end
> @doc doc"foo `bar` baz" -> function foo() end
>
> On Tuesday, 20 January 2015 09:02:31 UTC-8, Michael Hatherly wrote:
>>
>> No problem, glad that part’s working now.
>>
>> To view Docile-generated help you need to call using Lexicon, which 
>> hooks into Julia’s help system and adds the help entries generated by 
>> Docile. If you’ve not got Lexicon installed you can call 
>> Pkg.add("Lexicon") to install it.
>>
>> — Mike
>> On Tuesday, 20 January 2015 18:35:20 UTC+2, Yuuki Soho wrote:
>>>
>>> I had a problem with my packages (it was even crashing on update...), I 
>>> reinstalled the packages from scratch and the error is gone. I should have 
>>> checked that first, sorry.
>>>
>>> That said I'm not sure it's working properly, that's what I get (I 
>>> renamed the test function above test1):
>>>
>>> help?> test1
>>> INFO: Loading help data...
>>> test1 (generic function with 1 method)
>>>
>>>

Re: [julia-users] Usage of @inbounds

[Erik Schnetter]

`@inbounds` applies to everything that follows. You should even be able to 
apply it to a module at once, or to use `begin`...`end` to apply it to several 
statements at once. `@fastmath` behaves in a similar manner.

`@simd`, however, needs to be applied directly to a single loop.

-erik

> On Jan 20, 2015, at 11:37 , Jacob Quinn  wrote:
> 
> That all seems correct to me.
> 
> -Jacob
> 
> On Tue, Jan 20, 2015 at 9:36 AM, Nils Gudat  wrote:
> Just a quick clarification on the @inbounds macro: I've seen it used both 
> before and inside loops, like:
> 
> @inbounds for i = 1:1000
>   a = x[i]
>   b = z[i]
> end
> 
> inbounds for i = 1:1000
>   @inbounds a = x[i]
>   @inbounds b = z[i]
> end
> 
> Would I be correct in assuming that both usages are valid and working and 
> that the choice between the two basically boils down to whether I want to 
> turn off bounds checking inside the entire loop (first case) or only for 
> certain lines within the loop (second case)?

--
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[julia-users] Re: 0.4 Documentation System

[andy hayden]

One thing that seems unclear, at least to me, is the distinction (if any) 
between doc"...", md"..." (md isn't exported in Base) and "..." (just a 
string).

It doesn't seem that it matters which we use e.g. the following are 
equivalent:

@doc "foo `bar` baz" -> function foo() end
@doc doc"foo `bar` baz" -> function foo() end

On Tuesday, 20 January 2015 09:02:31 UTC-8, Michael Hatherly wrote:
>
> No problem, glad that part’s working now.
>
> To view Docile-generated help you need to call using Lexicon, which hooks 
> into Julia’s help system and adds the help entries generated by Docile. If 
> you’ve not got Lexicon installed you can call Pkg.add("Lexicon") to 
> install it.
>
> — Mike
> On Tuesday, 20 January 2015 18:35:20 UTC+2, Yuuki Soho wrote:
>>
>> I had a problem with my packages (it was even crashing on update...), I 
>> reinstalled the packages from scratch and the error is gone. I should have 
>> checked that first, sorry.
>>
>> That said I'm not sure it's working properly, that's what I get (I 
>> renamed the test function above test1):
>>
>> help?> test1
>> INFO: Loading help data...
>> test1 (generic function with 1 method)
>>
>>

Re: [julia-users] Vectorized operation inside a function doesn't change a passed variable?

[Jameson Nash]

> norm_df = input_df

This line gives a new name (or label) to the DataFrame instance. It has no
impact on the contents of said DataFrame.
On Tue, Jan 20, 2015 at 11:19 AM AVF  wrote:

> Thanks, Milan. Is there a way to predict a priori when the passed
> variable/object will be mutated? E.g., earlier last night I was surprised
> that my function below was mutating the passed data frame, not just the
> copy created inside the function.
>
> function normalize(input_df::DataFrame, cols::Array{Int})
> norm_df = input_df
> for i in cols
> norm_df[i] = (input_df[i] - minimum(input_df[i])) /
> (maximum(input_df[i]) - minimum(input_df[i]))
> end
> norm_df
> end

[julia-users] Re: 0.4 Documentation System

[Michael Hatherly]

No problem, glad that part’s working now.

To view Docile-generated help you need to call using Lexicon, which hooks 
into Julia’s help system and adds the help entries generated by Docile. If 
you’ve not got Lexicon installed you can call Pkg.add("Lexicon") to install 
it.

— Mike
On Tuesday, 20 January 2015 18:35:20 UTC+2, Yuuki Soho wrote:
>
> I had a problem with my packages (it was even crashing on update...), I 
> reinstalled the packages from scratch and the error is gone. I should have 
> checked that first, sorry.
>
> That said I'm not sure it's working properly, that's what I get (I renamed 
> the test function above test1):
>
> help?> test1
> INFO: Loading help data...
> test1 (generic function with 1 method)
>
>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[cormullion]

JuliaGraphics ,  Geometry2D 
, etc. would be attractive to 
graphics-oriented programmers...

Re: [julia-users] Usage of @inbounds

[Jacob Quinn]

That all seems correct to me.

-Jacob

On Tue, Jan 20, 2015 at 9:36 AM, Nils Gudat  wrote:

> Just a quick clarification on the @inbounds macro: I've seen it used both
> before and inside loops, like:
>
> @inbounds for i = 1:1000
>   a = x[i]
>   b = z[i]
> end
>
> inbounds for i = 1:1000
>   @inbounds a = x[i]
>   @inbounds b = z[i]
> end
>
> Would I be correct in assuming that both usages are valid and working and
> that the choice between the two basically boils down to whether I want to
> turn off bounds checking inside the entire loop (first case) or only for
> certain lines within the loop (second case)?
>
>
>

[julia-users] Usage of @inbounds

[Nils Gudat]

Just a quick clarification on the @inbounds macro: I've seen it used both 
before and inside loops, like:

@inbounds for i = 1:1000
  a = x[i]
  b = z[i]
end

inbounds for i = 1:1000
  @inbounds a = x[i]
  @inbounds b = z[i]
end

Would I be correct in assuming that both usages are valid and working and 
that the choice between the two basically boils down to whether I want to 
turn off bounds checking inside the entire loop (first case) or only for 
certain lines within the loop (second case)?

[julia-users] Re: 0.4 Documentation System

[Yuuki Soho]

I had a problem with my packages (it was even crashing on update...), I 
reinstalled the packages from scratch and the error is gone. I should have 
checked that first, sorry.

That said I'm not sure it's working properly, that's what I get (I renamed 
the test function above test1):

help?> test1
INFO: Loading help data...
test1 (generic function with 1 method)

Re: [julia-users] Vectorized operation inside a function doesn't change a passed variable?

[AVF]

Thanks, Milan. Is there a way to predict a priori when the passed 
variable/object will be mutated? E.g., earlier last night I was surprised that 
my function below was mutating the passed data frame, not just the copy created 
inside the function.

function normalize(input_df::DataFrame, cols::Array{Int})
norm_df = input_df
for i in cols
norm_df[i] = (input_df[i] - minimum(input_df[i])) / 
(maximum(input_df[i]) - minimum(input_df[i]))
end
norm_df
end

[julia-users] Almost at 500 packages!

[Iain Dunning]

Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
registered packages with at least one version tagged that are Julia 0.4-dev 
compatible (493 on Julia 0.3).

Thanks to all the package developers for their efforts in growing the Julia 
package ecosystem!

[julia-users] Re: 0.4 Documentation System

[Michael Hatherly]

What version of Docile are you using? You can check with `Pkg.status()`.
The current stable version is 0.3.2. Try doing `Pkg.update()` and then 
rerunning
your file if you're not on that version.

On Tuesday, 20 January 2015 16:17:07 UTC+2, Yuuki Soho wrote:
>
> My file was huge, but I did a minimal one:
>
> if VERSION < v"0.4-"
>
> using Docile
>
> macro doc_mstr(text)
>
> Base.triplequoted(text)
>
> end
>
> macro doc_str(text)
>
> text
>
> end
>
> end
>
>  
>
> @doc doc"Tells you if there are too foo items in the array." ->
>
> function test(x)
>
>  
>
> return 1
>
> end
>
> julia> reload("testDocile.jl")
>
> ERROR: No metadata defined in module Main.
>
>  in error at error.jl:21
>
>  in getdoc at /Users/laupin/.julia/Docile/src/types.jl:110
>
>  in Entry at /Users/laupin/.julia/Docile/src/types.jl:35
>
>  in Entry at /Users/laupin/.julia/Docile/src/types.jl:34
>
>  in setmeta! at /Users/laupin/.julia/Docile/src/types.jl:101
>
>  in include at 
> /Applications/Julia-0.3.2.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in include_from_node1 at 
> /Applications/Julia-0.3.2.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>  in reload_path at loading.jl:152
>
>  in reload at loading.jl:85
>
> while loading /Users/laupin/Desktop/julia/testDocile.jl, in expression 
> starting on line 11
>
>
>
>
>

[julia-users] Re: 0.4 Documentation System

[Yuuki Soho]

My file was huge, but I did a minimal one:

if VERSION < v"0.4-"

using Docile

macro doc_mstr(text)

Base.triplequoted(text)

end

macro doc_str(text)

text

end

end

 

@doc doc"Tells you if there are too foo items in the array." ->

function test(x)

 

return 1

end

julia> reload("testDocile.jl")

ERROR: No metadata defined in module Main.

 in error at error.jl:21

 in getdoc at /Users/laupin/.julia/Docile/src/types.jl:110

 in Entry at /Users/laupin/.julia/Docile/src/types.jl:35

 in Entry at /Users/laupin/.julia/Docile/src/types.jl:34

 in setmeta! at /Users/laupin/.julia/Docile/src/types.jl:101

 in include at 
/Applications/Julia-0.3.2.app/Contents/Resources/julia/lib/julia/sys.dylib

 in include_from_node1 at 
/Applications/Julia-0.3.2.app/Contents/Resources/julia/lib/julia/sys.dylib

 in reload_path at loading.jl:152

 in reload at loading.jl:85

while loading /Users/laupin/Desktop/julia/testDocile.jl, in expression 
starting on line 11

[julia-users] Re: 0.4 Documentation System

[Michael Hatherly]

Hi Yuuki,

could you provide me with the complete example you tried?

— Mike
​
On Tuesday, 20 January 2015 16:00:53 UTC+2, Yuuki Soho wrote:
>
> I just used the workaround but now I get another error:
>
> ERROR: No metadata defined in module Main.
>
>
> I just copy-pasted one of the example from the doc before one of my 
> functions. v"0.3.2"
>
> On Tuesday, January 20, 2015 at 8:19:50 AM UTC+1, Michael Hatherly wrote:
>>
>> If anyone happens to run into a
>>
>> ERROR: @doc_mstr not defined
>>
>> message when using Docile and the 0.4 doc system please have a look at 
>> this  issue for 
>> the workaround.
>>
>> — Mike
>> ​
>> On Tuesday, 20 January 2015 00:26:36 UTC+2, Mike Innes wrote:
>>>
>>> Hey Julians,
>>>
>>> Just wanted to drop a note to say that the new documentation system now 
>>> has some of its own documentation in the manual 
>>> . This will 
>>> be relevant even if you're not using 0.4, since you can use the excellent 
>>> Docile.jl package to create and access documentation in 0.3.
>>>
>>> It'd be great to see people kicking the tires on this, and with any luck 
>>> the state of package docs will look much better by the time 0.4 is released.
>>>
>>> – Mike
>>>
>>

[julia-users] Re: 0.4 Documentation System

[Yuuki Soho]

I just used the workaround but now I get another error:

ERROR: No metadata defined in module Main.


I just copy-pasted one of the example from the doc before one of my 
functions. v"0.3.2"

On Tuesday, January 20, 2015 at 8:19:50 AM UTC+1, Michael Hatherly wrote:
>
> If anyone happens to run into a
>
> ERROR: @doc_mstr not defined
>
> message when using Docile and the 0.4 doc system please have a look at 
> this  issue for 
> the workaround.
>
> — Mike
> ​
> On Tuesday, 20 January 2015 00:26:36 UTC+2, Mike Innes wrote:
>>
>> Hey Julians,
>>
>> Just wanted to drop a note to say that the new documentation system now 
>> has some of its own documentation in the manual 
>> . This will 
>> be relevant even if you're not using 0.4, since you can use the excellent 
>> Docile.jl package to create and access documentation in 0.3.
>>
>> It'd be great to see people kicking the tires on this, and with any luck 
>> the state of package docs will look much better by the time 0.4 is released.
>>
>> – Mike
>>
>

[julia-users] Re: simple IO question

[tuguldur . s]

perfect!

[julia-users] workflow recommendation/tutorial

[Tamas Papp]

Hi,

I am wondering what the best workflow is for iterative/exploratory
programming (as opposed to, say, library development).  I feel that my
questions below all have solutions, it's just that I am not experienced
enough in Julia to figure them out.

The way I have been doing it so far:
1. open a file in the editor,
2. start `using` some libraries,
3. write a few functions, load data, plot, analyze
4. rewrite functions, repeat 2-4 until satisfied.

I usually end up with a bunch of functions, followed by the actual
runtime code.

However, I run into the following issues (or, rather, inconveniences)
with nontrivial code:

a. If I redefine a function, then I have to recompile dependent
functions, which is tedious and occasionally a source of bugs
(cf. https://github.com/JuliaLang/julia/issues/265 )

b. I can't redefine types.

I can solve both by restarting (`workspace()`), but then I have to
reload & recompile everything.

I am wondering if there is a more organized way of doing this --- eg put
some stuff in a module in a separate file and just keep reloading that,
etc. Any advice, or pointers to tutorials would be appreciated.

I am using Emacs/ESS.

Also, is there a way to unintern symbols (a la CL) that would solve the
type redefinition issue?

Best,

Tamas

Re: [julia-users] Vectorized operation inside a function doesn't change a passed variable?

[Milan Bouchet-Valat]

Le lundi 19 janvier 2015 à 21:34 -0800, AVF a écrit :
> I just wanted to double-check that I understand it correctly: doing a
> vectorized operation to a passed variable inside a function will not
> change the variable on the outside?
More or less. `x += 10` is just syntactic sugar for `x = x + 10`: it
allocates a new array, and binds it to x. The original x is not mutated.

> Does one have to resort to a `for` loop, or is there another way?
You can do something like this:

function foo!(x)
x[:] += 10
end


Regards


> function foo!(x)
> x += 10
> end
>  
> function bar!(x) 
> [ x[i] += 10 for i in 1:size(x,1) ] 
> end
>  
> y = [1:3]
>  
> foo!(y)
> println(y)
>  
> bar!(y)
> println(y)
> 
> 
> Output:
> 
> 
> [1,2,3]
> [1,2,3]
> [11,12,13]
> 
> 
> Thanks. 

Re: [julia-users] julia array type?

[Milan Bouchet-Valat]

Le lundi 19 janvier 2015 à 14:20 -0800, Ivar Nesje a écrit :
> The problem here is a parsing ambiguity, because tuples support
> indexing. I believe there is an issue on github for this, but I can't
> figure out what to search for.
That's https://github.com/JuliaLang/julia/issues/9445

> It might be more obvious that (Float64, Int)[2] is ambiguous. 
Looks like the ambiguity is only partial, as the posted code is more
like (Float64, Int)[(2, 2)], which does not work when indexing a tuple.
The parse doesn't know that, but maybe it could be made to detect this
special case (indexing tuple with tuple).


Regards

[julia-users] event based simulation / protocol simulator (in julia)

[Andreas Lobinger]

Hello colleagues,

i scanned the usual sources, but didn't find a clear answer.
Is there any project looking at using julia to build a protocol simulator?

Wishing a happy day,
   Andreas

P.S. I'm not a protocol expert ...