[julia-users] Re: julia on ARM for a drone

[Jeff Waller]

There are 2 things that appear to be direct result of this new OS/processor.

On startup:

WARNING: unable to determine host cpu name

And also, apparently julia sets the git crt path based on the OS, but in 
the case of this and others like it, the OS will not be recognized.

Fails:

*julia> **Pkg.update()*

*INFO: Updating METADATA...*

*WARNING: fetch: GitError(Code:ECERTIFICATE, Class:SSL, The SSL certificate 
is invalid)*


But not if:


*julia> *
*LibGit2.set_ssl_cert_locations("/etc/ssl/certs/ca-certificates.crt")*

*0*



Also, anything that requires JIT is slow.  So having everything 
pre-compiled if possible is desirable.

[julia-users] Re: julia on ARM for a drone

[Jeff Waller]

On Monday, February 15, 2016 at 5:55:19 AM UTC-5, Viral Shah wrote:
>
> Making sure I understand correctly, were you using the distribution on 
> julialang.org/downloads? If you had to do a few things to get it to work, 
> can you file issues? I personally would love to see more such applications 
> and that was the motivation to have an ARM port in the first place.
>

Sure can.  I'll answer some of this now.

The first thing to note is a lot of the workaound was a result of the 
arbitrary nature of this distro rather than ARM per se, however, at the 
same time expect that ARM will more
likely be associated with previously unseen OS since it is likely to be 
tailored to the processor and the processor is tailored to the 
task/device/application.  In this case, the 
processor was likely chosen for its ability to work at low wattage while 
still delivering enough CPU to do the task.  Here it is:


3dr_solo:~$ cat /proc/cpuinfo 

processor   : 0

model name  : ARMv7 Processor rev 10 (v7l)

BogoMIPS: 1988.29

Features: swp half thumb fastmult vfp edsp neon vfpv3 tls 

CPU implementer : 0x41

CPU architecture: 7

CPU variant : 0x2

CPU part: 0xc09

CPU revision: 10
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)

Revision: 

Serial  : 

Re: [julia-users] Weird Hygiene Issue

[Lutfullah Tomak]

>From this issue
https://github.com/JuliaLang/julia/issues/15085
and trying macroexpand in module X itself I come to believe that it is not 
hyiene issue but side effect of -at-eval. Here is macroexpand instead of 
-at-eval -at-f _ex_func in module X
quote 
 # In[13], line 7:
function _ex_func() # In[13], line 8:
println("st")
end # In[13], line 11:
function _1ex_func() # In[13], line 12:
_ex_func() # In[13], line 13:
println("sty")
end # In[13], line 15:
export _ex_func # In[13], line 16:
export _1ex_func
end

Re: [julia-users] Weird Hygiene Issue

[Cedric St-Jean]

Hi Julia, what are you trying to achieve, concretely? 

On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>
> I started to think, this may be normal working of julia.
>
> import X:_ex_func
> using X
> _ex_func() = println("DDD")
> _1ex_func()
> julia> _1ex_func()
> DDD
> sty
>
> julia> module Y
>   using X
>   _
> _1ex_func  __precompile__  _ex_func
> julia> module Y
>   using X
>   _1ex_func()
>   end
> DDD
> sty
> Y
>
> However, it seems once a function is overridden, it stays overridden in 
> every module.
> That is a very weird idea. why is there such a design decision? Can 
> someone care to explain it?
>
> Thanks
>
> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>>
>> Guys, this is no solution to my problem, 
>>
>> escaping basically tells the the quoted expr to be resolved outside the 
>> macro as Lutfullah did. However in my case, escaping a function call 
>> doesn't work for some reason.
>> And for that matter, esc should be recursive though...
>>
>>
>> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:
>>>
>>> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
>>> (mailto:juliatyl...@gmail.com)) wrote: 
>>>
>>> > Hi fellows,   
>>> >   
>>> >   
>>> > I was coding a macro, and I am having a prefix issue with functions.   
>>> >   
>>> > basically the problem is: Every single one of available functions 
>>> (_ex_func) which i want to be globally accessible are prefixed with the 
>>> name of the module(X) in which the macro f is defined   
>>> >   
>>> >   
>>> > Here is the code example:   
>>> >   
>>> > julia> module X   
>>> > export @f 
>>> > macro f(x) 
>>> > st = string("_",x) 
>>> > sy = symbol(st) 
>>> > esc(quote 
>>> > function ($sy)() 
>>> > println("st") 
>>> > end 
>>> >   
>>> > function ($(symbol(string("_1",x()   
>>> > ($sy)() 
>>> > println("sty") 
>>> > end 
>>> > export $sy 
>>> > export $(symbol(string("_1",x))) 
>>> > end 
>>> > ) 
>>> > end 
>>> > @eval @f ex_func 
>>> > end 
>>> > X 
>>> >   
>>> > julia> using X   
>>> >   
>>> > julia> _   
>>> >   
>>> > _1ex_func __precompile__ _ex_func   
>>> > julia> _1ex_func.env.defs.func.code 
>>> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # none, 
>>> line 12: 
>>> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by X 
>>> > return (X.println)("sty") 
>>> > end) 
>>> >   
>>> > julia> macroexpand(:(@f ex_func))   
>>> > quote # none, line 7: 
>>> > function _ex_func() # none, line 8: 
>>> > println("st") 
>>> > end # none, line 11: 
>>> > function _1ex_func() # none, line 12: 
>>> > _ex_func() # none, line 13: # it seems OK, here!!! 
>>> > println("sty") 
>>> > end # none, line 15: 
>>> > export _ex_func # none, line 16: 
>>> > export _1ex_func 
>>> > end 
>>> >   
>>> >   
>>> >   
>>> > as you may see , I may well define _ex_func in other modules and use 
>>> it from the function X._1ex_func().   
>>> > But this prevents me doing it. 
>>> >   
>>> > How can i solve this problem?   
>>> >   
>>> > Thanks 
>>>
>>> OH! I know this! 
>>>
>>> Actually, I do believe this is a bug in macro hygiene and have been 
>>> meaning to file it. In the mean time, double-escaping should work for you: 
>>>
>>> julia> module X 
>>>macro p(y) 
>>>  quote 
>>>println($y) 
>>>  end 
>>>end 
>>>macro q(y) 
>>>  quote 
>>>println(:($($y))) 
>>>  end 
>>>end 
>>>end 
>>> X 
>>>  
>>> julia> using X 
>>>  
>>> julia> test = "Hello, world" 
>>> "Hello, world" 
>>>  
>>> julia> @X.p(test) 
>>> ERROR: UndefVarError: test not defined 
>>>  
>>> julia> @X.q(test) 
>>> Hello, world 
>>>
>>

Re: [julia-users] Weird Hygiene Issue

[elextr]

I don't think that the `using X` inside module Y here re-runs the eval, 
there is only one instance of modules, it doesn't create a new instance 
inside module Y.  So your replacement of X._ex_func() at top level still 
holds.

On Tuesday, February 16, 2016 at 5:36:15 AM UTC+10, Julia Tylors wrote:
>
> I started to think, this may be normal working of julia.
>
> import X:_ex_func
> using X
> _ex_func() = println("DDD")
> _1ex_func()
> julia> _1ex_func()
> DDD
> sty
>
> julia> module Y
>   using X
>   _
> _1ex_func  __precompile__  _ex_func
> julia> module Y
>   using X
>   _1ex_func()
>   end
> DDD
> sty
> Y
>
> However, it seems once a function is overridden, it stays overridden in 
> every module.
> That is a very weird idea. why is there such a design decision? Can 
> someone care to explain it?
>
> Thanks
>
> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>>
>> Guys, this is no solution to my problem, 
>>
>> escaping basically tells the the quoted expr to be resolved outside the 
>> macro as Lutfullah did. However in my case, escaping a function call 
>> doesn't work for some reason.
>> And for that matter, esc should be recursive though...
>>
>>
>> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:
>>>
>>> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
>>> (mailto:juliatyl...@gmail.com)) wrote: 
>>>
>>> > Hi fellows,   
>>> >   
>>> >   
>>> > I was coding a macro, and I am having a prefix issue with functions.   
>>> >   
>>> > basically the problem is: Every single one of available functions 
>>> (_ex_func) which i want to be globally accessible are prefixed with the 
>>> name of the module(X) in which the macro f is defined   
>>> >   
>>> >   
>>> > Here is the code example:   
>>> >   
>>> > julia> module X   
>>> > export @f 
>>> > macro f(x) 
>>> > st = string("_",x) 
>>> > sy = symbol(st) 
>>> > esc(quote 
>>> > function ($sy)() 
>>> > println("st") 
>>> > end 
>>> >   
>>> > function ($(symbol(string("_1",x()   
>>> > ($sy)() 
>>> > println("sty") 
>>> > end 
>>> > export $sy 
>>> > export $(symbol(string("_1",x))) 
>>> > end 
>>> > ) 
>>> > end 
>>> > @eval @f ex_func 
>>> > end 
>>> > X 
>>> >   
>>> > julia> using X   
>>> >   
>>> > julia> _   
>>> >   
>>> > _1ex_func __precompile__ _ex_func   
>>> > julia> _1ex_func.env.defs.func.code 
>>> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # none, 
>>> line 12: 
>>> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by X 
>>> > return (X.println)("sty") 
>>> > end) 
>>> >   
>>> > julia> macroexpand(:(@f ex_func))   
>>> > quote # none, line 7: 
>>> > function _ex_func() # none, line 8: 
>>> > println("st") 
>>> > end # none, line 11: 
>>> > function _1ex_func() # none, line 12: 
>>> > _ex_func() # none, line 13: # it seems OK, here!!! 
>>> > println("sty") 
>>> > end # none, line 15: 
>>> > export _ex_func # none, line 16: 
>>> > export _1ex_func 
>>> > end 
>>> >   
>>> >   
>>> >   
>>> > as you may see , I may well define _ex_func in other modules and use 
>>> it from the function X._1ex_func().   
>>> > But this prevents me doing it. 
>>> >   
>>> > How can i solve this problem?   
>>> >   
>>> > Thanks 
>>>
>>> OH! I know this! 
>>>
>>> Actually, I do believe this is a bug in macro hygiene and have been 
>>> meaning to file it. In the mean time, double-escaping should work for you: 
>>>
>>> julia> module X 
>>>macro p(y) 
>>>  quote 
>>>println($y) 
>>>  end 
>>>end 
>>>macro q(y) 
>>>  quote 
>>>println(:($($y))) 
>>>  end 
>>>end 
>>>end 
>>> X 
>>>  
>>> julia> using X 
>>>  
>>> julia> test = "Hello, world" 
>>> "Hello, world" 
>>>  
>>> julia> @X.p(test) 
>>> ERROR: UndefVarError: test not defined 
>>>  
>>> julia> @X.q(test) 
>>> Hello, world 
>>>
>>

[julia-users] Re: Simultaneous audio playback / recording.

[CrocoDuck O'Ducks]

Sorry for the late reply, I am taking quite a lot of time to properly 
understand Julia while I learn it. Sir, your module is very nice! It seems 
to be working fine and I was able to get started pretty soon. JACK support! 
YUM!!! I already see how to design my script: make it write the .jackdrc 
file, make it launch jack, find the correct device ID and unleash the 
measurement process.

Thanks for your module, I think it will be very useful for me. Keep on the 
good work!

On Sunday, 7 February 2016 16:31:57 UTC, Sebastian Kraft wrote:
>
> Am Sonntag, 7. Februar 2016 16:51:35 UTC+1 schrieb CrocoDuck O'Ducks:
>>
>> I am starting looking into your module and... ehm... what is the proper 
>> way to install it?
>>
>
> It's not a registered package, yet. Therefore, it requires the following 
> steps:
>
> Pkg.clone("https://github.com/seebk/PortAudio.jl.git;)
> Pkg.build("PortAudio")
>
>  
>

Re: [julia-users] Strange failure running test/unicode/utf8code.jl

[Steven G. Johnson]

I think it's just one of those bugs that only shows up under an odd 
combination of circumstances.   Now that we have a way to reliably 
reproduce it, it will be tracked down and fixed before long.

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

I started to think, this may be normal working of julia.

import X:_ex_func
using X
_ex_func() = println("DDD")
_1ex_func()
julia> _1ex_func()
DDD
sty

julia> module Y
  using X
  _
_1ex_func  __precompile__  _ex_func
julia> module Y
  using X
  _1ex_func()
  end
DDD
sty
Y

However, it seems once a function is overridden, it stays overridden in 
every module.
That is a very weird idea. why is there such a design decision? Can someone 
care to explain it?

Thanks

On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>
> Guys, this is no solution to my problem, 
>
> escaping basically tells the the quoted expr to be resolved outside the 
> macro as Lutfullah did. However in my case, escaping a function call 
> doesn't work for some reason.
> And for that matter, esc should be recursive though...
>
>
> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:
>>
>> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
>> (mailto:juliatyl...@gmail.com)) wrote: 
>>
>> > Hi fellows,   
>> >   
>> >   
>> > I was coding a macro, and I am having a prefix issue with functions.   
>> >   
>> > basically the problem is: Every single one of available functions 
>> (_ex_func) which i want to be globally accessible are prefixed with the 
>> name of the module(X) in which the macro f is defined   
>> >   
>> >   
>> > Here is the code example:   
>> >   
>> > julia> module X   
>> > export @f 
>> > macro f(x) 
>> > st = string("_",x) 
>> > sy = symbol(st) 
>> > esc(quote 
>> > function ($sy)() 
>> > println("st") 
>> > end 
>> >   
>> > function ($(symbol(string("_1",x()   
>> > ($sy)() 
>> > println("sty") 
>> > end 
>> > export $sy 
>> > export $(symbol(string("_1",x))) 
>> > end 
>> > ) 
>> > end 
>> > @eval @f ex_func 
>> > end 
>> > X 
>> >   
>> > julia> using X   
>> >   
>> > julia> _   
>> >   
>> > _1ex_func __precompile__ _ex_func   
>> > julia> _1ex_func.env.defs.func.code 
>> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # none, 
>> line 12: 
>> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by X 
>> > return (X.println)("sty") 
>> > end) 
>> >   
>> > julia> macroexpand(:(@f ex_func))   
>> > quote # none, line 7: 
>> > function _ex_func() # none, line 8: 
>> > println("st") 
>> > end # none, line 11: 
>> > function _1ex_func() # none, line 12: 
>> > _ex_func() # none, line 13: # it seems OK, here!!! 
>> > println("sty") 
>> > end # none, line 15: 
>> > export _ex_func # none, line 16: 
>> > export _1ex_func 
>> > end 
>> >   
>> >   
>> >   
>> > as you may see , I may well define _ex_func in other modules and use it 
>> from the function X._1ex_func().   
>> > But this prevents me doing it. 
>> >   
>> > How can i solve this problem?   
>> >   
>> > Thanks 
>>
>> OH! I know this! 
>>
>> Actually, I do believe this is a bug in macro hygiene and have been 
>> meaning to file it. In the mean time, double-escaping should work for you: 
>>
>> julia> module X 
>>macro p(y) 
>>  quote 
>>println($y) 
>>  end 
>>end 
>>macro q(y) 
>>  quote 
>>println(:($($y))) 
>>  end 
>>end 
>>end 
>> X 
>>  
>> julia> using X 
>>  
>> julia> test = "Hello, world" 
>> "Hello, world" 
>>  
>> julia> @X.p(test) 
>> ERROR: UndefVarError: test not defined 
>>  
>> julia> @X.q(test) 
>> Hello, world 
>>
>

Re: [julia-users] Re: ANN: CppWrapper C++ wrapping package

[Andreas Noack]

Thanks for the explanation. I think it is useful to have a short section in
the docs that explains how and why a package is different from similar
packages.

On Mon, Feb 15, 2016 at 2:06 PM, Bart Janssens  wrote:

> Hi Andreas,
>
> Yes, I'm aware of (and impressed by :) Cxx.jl. The reason I went ahead
> with CppWrapper anyway is that I wanted something like Boost.Python does
> for Python: allow writing the interface completely in C++.
>
> If I understand Cxx.jl correctly, the idea is that it becomes possible to
> directly access C++ using the @cxx macro from Julia. So when facing the
> task of wrapping a C++ library in a Julia package, authors now have 2
> options:
> - Use Cxx.jl to write the wrapper package in Julia code
> - Use CppWrapper to write the wrapper completely in C++ (and one line of
> Julia code to load the .so)
>
> We currently have a C++ project with Python bindings done using
> Boost.Python, which also uses the latter approach, so translating this is
> more natural using CppWrapper.
>
> Maybe I should clarify this in the docs?
>
> Cheers,
>
> Bart
>
> On Monday, February 15, 2016 at 7:35:52 PM UTC+1, Andreas Noack wrote:
>>
>> Hi Bart,
>>
>> Are you aware of https://github.com/Keno/Cxx.jl? What are the reasons
>> for a separate package?
>>
>>

[julia-users] Re: ANN: CppWrapper C++ wrapping package

[Bart Janssens]

Hi Andreas,

Yes, I'm aware of (and impressed by :) Cxx.jl. The reason I went ahead with 
CppWrapper anyway is that I wanted something like Boost.Python does for 
Python: allow writing the interface completely in C++.

If I understand Cxx.jl correctly, the idea is that it becomes possible to 
directly access C++ using the @cxx macro from Julia. So when facing the 
task of wrapping a C++ library in a Julia package, authors now have 2 
options:
- Use Cxx.jl to write the wrapper package in Julia code
- Use CppWrapper to write the wrapper completely in C++ (and one line of 
Julia code to load the .so)

We currently have a C++ project with Python bindings done using 
Boost.Python, which also uses the latter approach, so translating this is 
more natural using CppWrapper.

Maybe I should clarify this in the docs?

Cheers,

Bart

On Monday, February 15, 2016 at 7:35:52 PM UTC+1, Andreas Noack wrote:
>
> Hi Bart,
>
> Are you aware of https://github.com/Keno/Cxx.jl? What are the reasons for 
> a separate package?
>
>

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

Guys, this is no solution to my problem, 

escaping basically tells the the quoted expr to be resolved outside the 
macro as Lutfullah did. However in my case, escaping a function call 
doesn't work for some reason.
And for that matter, esc should be recursive though...


On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:
>
> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com 
> (mailto:juliatyl...@gmail.com )) wrote: 
>
> > Hi fellows,   
> >   
> >   
> > I was coding a macro, and I am having a prefix issue with functions.   
> >   
> > basically the problem is: Every single one of available functions 
> (_ex_func) which i want to be globally accessible are prefixed with the 
> name of the module(X) in which the macro f is defined   
> >   
> >   
> > Here is the code example:   
> >   
> > julia> module X   
> > export @f 
> > macro f(x) 
> > st = string("_",x) 
> > sy = symbol(st) 
> > esc(quote 
> > function ($sy)() 
> > println("st") 
> > end 
> >   
> > function ($(symbol(string("_1",x()   
> > ($sy)() 
> > println("sty") 
> > end 
> > export $sy 
> > export $(symbol(string("_1",x))) 
> > end 
> > ) 
> > end 
> > @eval @f ex_func 
> > end 
> > X 
> >   
> > julia> using X   
> >   
> > julia> _   
> >   
> > _1ex_func __precompile__ _ex_func   
> > julia> _1ex_func.env.defs.func.code 
> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # none, 
> line 12: 
> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by X 
> > return (X.println)("sty") 
> > end) 
> >   
> > julia> macroexpand(:(@f ex_func))   
> > quote # none, line 7: 
> > function _ex_func() # none, line 8: 
> > println("st") 
> > end # none, line 11: 
> > function _1ex_func() # none, line 12: 
> > _ex_func() # none, line 13: # it seems OK, here!!! 
> > println("sty") 
> > end # none, line 15: 
> > export _ex_func # none, line 16: 
> > export _1ex_func 
> > end 
> >   
> >   
> >   
> > as you may see , I may well define _ex_func in other modules and use it 
> from the function X._1ex_func().   
> > But this prevents me doing it. 
> >   
> > How can i solve this problem?   
> >   
> > Thanks 
>
> OH! I know this! 
>
> Actually, I do believe this is a bug in macro hygiene and have been 
> meaning to file it. In the mean time, double-escaping should work for you: 
>
> julia> module X 
>macro p(y) 
>  quote 
>println($y) 
>  end 
>end 
>macro q(y) 
>  quote 
>println(:($($y))) 
>  end 
>end 
>end 
> X 
>  
> julia> using X 
>  
> julia> test = "Hello, world" 
> "Hello, world" 
>  
> julia> @X.p(test) 
> ERROR: UndefVarError: test not defined 
>  
> julia> @X.q(test) 
> Hello, world 
>

[julia-users] Re: ANN: CppWrapper C++ wrapping package

[Andreas Noack]

Hi Bart,

Are you aware of https://github.com/Keno/Cxx.jl? What are the reasons for a 
separate package?

Best
Andreas

On Sunday, February 14, 2016 at 6:11:07 PM UTC-5, Bart Janssens wrote:
>
> Hi all,
>
> The CppWrapper package is meant to facilitate exposing C++ libraries to 
> Julia, allowing library authors to write the wrapping code in C++ and 
> import to Julia using a one-liner. I think I have now added most of the 
> basic features needed to produce simple type wrappings. The detailed 
> description can be found at:
> https://github.com/barche/CppWrapper
>
> For demonstration and performance-checking purposes, I have also wrapped a 
> very limited part of the Eigen matrix library for some given fixed-size 
> matrices:
> https://github.com/barche/EigenCpp.jl
>
> I'm thinking of submitting a presentation proposal for CppWrapper to 
> JuliaCon, so comments and suggestions are most welcome.
>
> Cheers,
>
> Bart
>

Re: [julia-users] GIF 3D plot

[Tom Breloff]

Animated or static?  Either way there are examples for both on the main
documentation page  of Plots.jl
, and plenty other examples scattered
in the example notebooks
 as well
as the issues .  Let me know
if you have any questions.

On Mon, Feb 15, 2016 at 10:28 AM,  wrote:

> Does anyone know how can I have a 3D plot as a GIF?
> I'm not sure if I can use PyPlot or Gaston to do that. If someone has an
> example I appreciate if you could share.
>
> Thanks!
>

[julia-users] GIF 3D plot

[mauriciomunaro]

Does anyone know how can I have a 3D plot as a GIF? 
I'm not sure if I can use PyPlot or Gaston to do that. If someone has an 
example I appreciate if you could share. 

Thanks!

Re: [julia-users] Re-loading edited scripts into REPL

[Tom Breloff]

Usually the solution is the wrap your code in a module, so your file would
look like:

module A

end

Then at the REPL you do include("bin/myscript.jl") and it will replace the
module.  Keep the name short so when you call your methods you only have to
do "A.mymethod()", or throw in an "export mymethod" after the "module A"
line.

You'll get used to the workflow, and of course for some scripts it's fine
to just restart the REPL if you're too lazy to wrap it as a module.

On Sun, Feb 14, 2016 at 9:51 PM, Wilton Basse 
wrote:

> So I write a script in text editor, save into ~/bin/myscript.jl.  Then in
> REPL use include("bin/myscript.jl") to run and test in REPL.
> Hmmm, see some changes to make, go back to text editor and edit and save
> changes.
>
> Here's the question: When I go back to REPL to test, how do I make sure I
> have *only* the most recent edit loaded?  If I do include() again is the
> old version replaced?  Do I need to "un-include" the old version somehow?
>
> I have been closing and re-opening the REPL and re-doing include(), but
> that's really unwieldy, especially using multiple scripts, plus I end up
> losing previous work within REPL.
>
> Thanks!
>

Re: [julia-users] Weird Hygiene Issue

[Joshua Ballanco]

On February 15, 2016 at 17:15:26, Lutfullah Tomak 
(tomaklu...@gmail.com(mailto:tomaklu...@gmail.com)) wrote:

> Shouldn't it be if you escaped
>  
> julia> module X
> macro p(y)
> esc(quote
> println($y)
> end)
> end
> macro q(y)
> quote
> println(:($($y)))
> end
> end
> end
> X
>  
> julia> using X
>  
> julia> test = "Hello, world"
> "Hello, world"
>  
> julia> @X.p(test)
> "Hello, world"
>  
> julia> @X.q(test)
> Hello, world

Hmm…interesting.

BTW, I finally went ahead and filed this: 
https://github.com/JuliaLang/julia/issues/15085

Re: [julia-users] Weird Hygiene Issue

[Lutfullah Tomak]

Shouldn't it be if you escaped

julia> module X 
   macro p(y) 
 esc(quote 
   println($y) 
 end) 
   end 
   macro q(y) 
 quote 
   println(:($($y))) 
 end 
   end 
   end 
X 
 
julia> using X 
 
julia> test = "Hello, world" 
"Hello, world" 
 
julia> @X.p(test) 
"Hello, world" 
 
julia> @X.q(test) 
Hello, world 

Re: [julia-users] Weird Hygiene Issue

[Joshua Ballanco]

On February 14, 2016 at 21:49:30, Julia Tylors 
(juliatyl...@gmail.com(mailto:juliatyl...@gmail.com)) wrote:

> Hi fellows,  
>  
>  
> I was coding a macro, and I am having a prefix issue with functions.  
>  
> basically the problem is: Every single one of available functions (_ex_func) 
> which i want to be globally accessible are prefixed with the name of the 
> module(X) in which the macro f is defined  
>  
>  
> Here is the code example:  
>  
> julia> module X  
> export @f
> macro f(x)
> st = string("_",x)
> sy = symbol(st)
> esc(quote
> function ($sy)()
> println("st")
> end
>  
> function ($(symbol(string("_1",x()  
> ($sy)()
> println("sty")
> end
> export $sy
> export $(symbol(string("_1",x)))
> end
> )
> end
> @eval @f ex_func
> end
> X
>  
> julia> using X  
>  
> julia> _  
>  
> _1ex_func __precompile__ _ex_func  
> julia> _1ex_func.env.defs.func.code
> AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # none, line 
> 12:
> (X._ex_func)() # none, line 13: # i want this to be not prefixed by X
> return (X.println)("sty")
> end)
>  
> julia> macroexpand(:(@f ex_func))  
> quote # none, line 7:
> function _ex_func() # none, line 8:
> println("st")
> end # none, line 11:
> function _1ex_func() # none, line 12:
> _ex_func() # none, line 13: # it seems OK, here!!!
> println("sty")
> end # none, line 15:
> export _ex_func # none, line 16:
> export _1ex_func
> end
>  
>  
>  
> as you may see , I may well define _ex_func in other modules and use it from 
> the function X._1ex_func().  
> But this prevents me doing it.
>  
> How can i solve this problem?  
>  
> Thanks

OH! I know this!

Actually, I do believe this is a bug in macro hygiene and have been meaning to 
file it. In the mean time, double-escaping should work for you:

    julia> module X
               macro p(y)
                 quote
                   println($y)
                 end
               end
               macro q(y)
                 quote
                   println(:($($y)))
                 end
               end
           end
    X
    
    julia> using X
    
    julia> test = "Hello, world"
    "Hello, world"
    
    julia> @X.p(test)
    ERROR: UndefVarError: test not defined
    
    julia> @X.q(test)
    Hello, world

Re: [julia-users] Investigating instances of parametric types

[Mauro]

> I have an instance of a parametric type, is there a canonical way to get
> the parameter values?
> For example I could have some Array{T, d} and want to know whether T is
> Float64 and what its dimension is.
> The only way of doing this I am aware of is writing code like:
>
> dimension{T, dim}(arr::Array{T, dim}) = dim
> numbertype{T, dim}(arr::Array{T, dim}) = T
>
> Is there a built-in function to do this? And maybe a way to get parameter
> values for arbitrary types?
> E.g. I have some instance of MyType{S, T, U, n} is and want to know U. Do I
> have to repeat code like the above each time I define a new parametric type?

Yes, this is the correct and Julian way to do this.  One of the reason
why there is no built-in function for this is that it doesn't make much
sense to ask for the, say, second parameter of an arbitrary type, as
that does not tell you much: you need to know the type to make sense of
the parameters.  However, if you need to do it generically, then Bart's
solution is the way to go.  Note however that type inference fails on
it, thus it shouldn't be used in performance critical code-paths:

julia> dimension{T, dim}(arr::Array{T, dim}) = dim
dimension (generic function with 1 method)

julia> @code_warntype dimension(rand(2))
Variables:
  arr::Array{Float64,1}

Body:
  begin  # none, line 1:
  return 1
  end::Int64

julia> dimension2{T}(arr::T) = T.parameters[2]
dimension2 (generic function with 1 method)

julia> @code_warntype dimension2(rand(2))
Variables:
  arr::Array{Float64,1}

Body:
  begin  # none, line 1:
  return 
(Main.getindex)((top(getfield))(T,:parameters)::SimpleVector,2)::Any
  end::Any

[julia-users] Re: Investigating instances of parametric types

[jw3126]

Thanks!

On Monday, February 15, 2016 at 2:28:19 PM UTC+1, Bart Janssens wrote:
>
> There is the parameters field of the types, but I'm not sure if that's 
> considered private. You can do
> Array{Float64, 1}.parameters[2]
> to get 1, for example.
>
> On Monday, February 15, 2016 at 2:14:35 PM UTC+1, jw3126 wrote:
>>
>> I have an instance of a parametric type, is there a canonical way to get 
>> the parameter values?
>> For example I could have some Array{T, d} and want to know whether T is 
>> Float64 and what its dimension is.
>> The only way of doing this I am aware of is writing code like:
>>
>> dimension{T, dim}(arr::Array{T, dim}) = dim
>> numbertype{T, dim}(arr::Array{T, dim}) = T
>>
>> Is there a built-in function to do this? And maybe a way to get parameter 
>> values for arbitrary types? 
>> E.g. I have some instance of MyType{S, T, U, n} is and want to know U. Do 
>> I have to repeat code like the above each time I define a new parametric 
>> type?
>>
>

Re: [julia-users] Re: Investigating instances of parametric types

[jw3126]

Thanks for those useful hints!

On Monday, February 15, 2016 at 2:49:04 PM UTC+1, Tim Holy wrote:
>
> True, but when you care about performance it's much better to write the 
> wrapper functions---the results will be inferrable, unlike manipulations 
> of 
> the parameters vector. 
>
> For Arrays, you already have the defined function `eltype` and `ndims`. If 
> your 
> types fall into some kind of hierarchy, then you may be able to use 
> subtyping. 
> For example: 
>
> julia> immutable MyWeirdArray{Sym,Len,T,N} <: AbstractArray{T,N} 
>data::NTuple{Len,T} 
>end 
>
> julia> ndims(MyWeirdArray{:zero_offset, 15, Float64, 1}) 
> 1 
>
> julia> eltype(MyWeirdArray{:zero_offset, 15, Float64, 1}) 
> Float64 
>
> Both base/ julia and the ColorTypes package contain good examples of how 
> to go 
> about this kind of manipulation. 
>
> Best, 
> --Tim 
>
> On Monday, February 15, 2016 05:28:19 AM Bart Janssens wrote: 
> > There is the parameters field of the types, but I'm not sure if that's 
> > considered private. You can do 
> > Array{Float64, 1}.parameters[2] 
> > to get 1, for example. 
> > 
> > On Monday, February 15, 2016 at 2:14:35 PM UTC+1, jw3126 wrote: 
> > > I have an instance of a parametric type, is there a canonical way to 
> get 
> > > the parameter values? 
> > > For example I could have some Array{T, d} and want to know whether T 
> is 
> > > Float64 and what its dimension is. 
> > > The only way of doing this I am aware of is writing code like: 
> > > 
> > > dimension{T, dim}(arr::Array{T, dim}) = dim 
> > > numbertype{T, dim}(arr::Array{T, dim}) = T 
> > > 
> > > Is there a built-in function to do this? And maybe a way to get 
> parameter 
> > > values for arbitrary types? 
> > > E.g. I have some instance of MyType{S, T, U, n} is and want to know U. 
> Do 
> > > I have to repeat code like the above each time I define a new 
> parametric 
> > > type? 
>
>

Re: [julia-users] Re: Investigating instances of parametric types

[Tim Holy]

True, but when you care about performance it's much better to write the 
wrapper functions---the results will be inferrable, unlike manipulations of 
the parameters vector.

For Arrays, you already have the defined function `eltype` and `ndims`. If your 
types fall into some kind of hierarchy, then you may be able to use subtyping. 
For example:

julia> immutable MyWeirdArray{Sym,Len,T,N} <: AbstractArray{T,N}
   data::NTuple{Len,T}
   end

julia> ndims(MyWeirdArray{:zero_offset, 15, Float64, 1})
1

julia> eltype(MyWeirdArray{:zero_offset, 15, Float64, 1})
Float64

Both base/ julia and the ColorTypes package contain good examples of how to go 
about this kind of manipulation.

Best,
--Tim

On Monday, February 15, 2016 05:28:19 AM Bart Janssens wrote:
> There is the parameters field of the types, but I'm not sure if that's
> considered private. You can do
> Array{Float64, 1}.parameters[2]
> to get 1, for example.
> 
> On Monday, February 15, 2016 at 2:14:35 PM UTC+1, jw3126 wrote:
> > I have an instance of a parametric type, is there a canonical way to get
> > the parameter values?
> > For example I could have some Array{T, d} and want to know whether T is
> > Float64 and what its dimension is.
> > The only way of doing this I am aware of is writing code like:
> > 
> > dimension{T, dim}(arr::Array{T, dim}) = dim
> > numbertype{T, dim}(arr::Array{T, dim}) = T
> > 
> > Is there a built-in function to do this? And maybe a way to get parameter
> > values for arbitrary types?
> > E.g. I have some instance of MyType{S, T, U, n} is and want to know U. Do
> > I have to repeat code like the above each time I define a new parametric
> > type?

[julia-users] Re: Investigating instances of parametric types

[Bart Janssens]

There is the parameters field of the types, but I'm not sure if that's 
considered private. You can do
Array{Float64, 1}.parameters[2]
to get 1, for example.

On Monday, February 15, 2016 at 2:14:35 PM UTC+1, jw3126 wrote:
>
> I have an instance of a parametric type, is there a canonical way to get 
> the parameter values?
> For example I could have some Array{T, d} and want to know whether T is 
> Float64 and what its dimension is.
> The only way of doing this I am aware of is writing code like:
>
> dimension{T, dim}(arr::Array{T, dim}) = dim
> numbertype{T, dim}(arr::Array{T, dim}) = T
>
> Is there a built-in function to do this? And maybe a way to get parameter 
> values for arbitrary types? 
> E.g. I have some instance of MyType{S, T, U, n} is and want to know U. Do 
> I have to repeat code like the above each time I define a new parametric 
> type?
>

[julia-users] Investigating instances of parametric types

[jw3126]

I have an instance of a parametric type, is there a canonical way to get 
the parameter values?
For example I could have some Array{T, d} and want to know whether T is 
Float64 and what its dimension is.
The only way of doing this I am aware of is writing code like:

dimension{T, dim}(arr::Array{T, dim}) = dim
numbertype{T, dim}(arr::Array{T, dim}) = T

Is there a built-in function to do this? And maybe a way to get parameter 
values for arbitrary types? 
E.g. I have some instance of MyType{S, T, U, n} is and want to know U. Do I 
have to repeat code like the above each time I define a new parametric type?

[julia-users] Re: Error with Julia + Juno IDE bundle installation on Windows 10

[Lutfullah Tomak]

Hi Mike,

You did not answer my question. Assuming julia version from Juno is 0.3 then 
you need required packages. For that, julia needs to set up a fresh package 
directory. Pkg.init() sets up this directory. After that, Pkg.add("Jewel") 
should install required packages. If julia version is 0.4 then Juno should 
already have required packages. 
Best,

[julia-users] Re: julia on ARM for a drone

[Viral Shah]

Making sure I understand correctly, were you using the distribution on 
julialang.org/downloads? If you had to do a few things to get it to work, 
can you file issues? I personally would love to see more such applications 
and that was the motivation to have an ARM port in the first place.

Compile time is a huge issue currently on master, and more so on arm - but 
is not arm specific. This will get chipped away with all the work that 
Jeff, Keno, Jameson, Yichao, and Oscar are doing.

-viral

On Sunday, February 7, 2016 at 12:20:55 PM UTC+5:30, Jeff Waller wrote:
>
> An update:
>
> It turns out that the default linux client compiled for ARM does work 
> with a few modifications 
> .  It is indeed
> slow to JIT-compile, (on the order of seconds), but is fast after that. 
>  See randomMatrix.txt in the gist, for
> exact measures, but for example rand(100,100) takes 1 second the first 
> time and then 0.0005 seconds subsequently --
> that's quite a speedup.  Likewise, svd of that 100x100 random matrix is 3 
> seconds and then 0.05 seconds
> afterwards. 
>
> Also, of course, I tried using node-julia and that was difficult, but I 
> managed to get that working too.  Firstly, I had
> to add -march=armv7-a to the compile step to allow use of C++ std::thread 
> to be successful; apparently this
> is a known  bug of 
> openembedded , and 
> not an issue with Julia. However, I also had to add -lgfortran and 
> -lopenblas
> to the link step to satisfy the loader which is reminiscent of the error 
> I had 
> 
>  
> when I first tried to get thigs working on 
> linux in 2014.  This is not the same thing but feels possibly related.  I 
> also had to create a symbolic link for gfortran
> as only the specialized version (libgfortran.so.3) existed; ln -s 
> libgfortran.so.3 libgfortran.so; that should probably
> be fixed.
>
> All but 3 of the node-julia regressions worked once I increased the 
> default timeout time.  You can see the relative
> speed differences between an OS/X labtop and the drone in the gist as 
> well.  Some of the timings are comparable,
> some are not.
>
> I believe the large difference in time is due to not only the processor 
> being slower, but the (flash) filesystem as well.
> Exec-ing processes on this drone takes a very large amount of time 
> (relative to normal laptops/desktops).  The memory
> is limited too (512 MB), so you really have to be careful about resources.
>
>

[julia-users] Re: Google Summer of Code 2016 - Ideas Page

[Zheng]

I would like to propose a Julia optimization package for *Generic 
Frank-Wolfe* algorithm.

This is an algorithm regaining popularity with this ICML article 2013 

And there is future research on this direction since.

This algorithm has a beautiful property when applied to the constrained 
optimization with the atom norm constrain, such as L1-norm, nuclear norm 
etc.. It embeds the sparsity into the solution searching process, and 
guarantees a linear convergence rate, and is optimal within the same 
sparsity.

There exist currently some code in Matlab, Python and C. But they work all 
on specific problems such as Lasso, Matrix Completion, and not ready for 
deployment.

It will be nice if we can realize a fast, generic Julia implementation. It 
will benefit both the academy and the industry, and probably bring a lot of 
citation to Julia.

I would like to apply to this proposal as a *student*. I met this algorithm 
last summer and am interested in its development. I have also some idea 
about the multiple-level APIs to implement it. And I happen to have some 
interaction with the paper authors, which will be a plus to this project. 

I like Julia, and I have used it for one year. I have learned a lot from 
it, and am prepared to learn more. I hope to find a mentor who could help 
me (mainly) on the Julia side, which is the key of a fast and generic 
algorithm package. And if possible, it will be nice to have it be 
integrated into the JuliaOpt.

Zheng
 

On Thursday, February 11, 2016 at 4:49:19 AM UTC+1, Shashi Gowda wrote:
>
> Hi all,
>
> I have merged the previous ideas pages (2015, 2014) into a canonical one 
> https://julialang.org/soc/ideas-page (and set up the appropriate 
> redirects)
>
> Please add your Summer of Code ideas and edit previous ones here 
> https://github.com/JuliaLang/julialang.github.com/edit/master/soc/ideas-page.md
>
> Let us also try and keep this page updated all year round so that ideas 
> get carried over to the next summer.
>
> Julia will be applying for GSoC 2016. The organization application 
> deadline is on 19th, it will be nice to have a high quality ideas page by 
> then.
>
> Thank you
>

Re: [julia-users] Strange failure running test/unicode/utf8code.jl

[Scott Jones]

Thanks for reporting this! (I see that Steven also ran into this bug).

I do think it needs another issue, for whatever changes in the test harness 
(which I know has been also changed recently) that
hid this bug from the unit testing.
Your running all the tests individually makes me feel a bit more 
comfortable with working on v0.5 master, however, until the problem with
the test harness is fixed, we can't tell what sorts of bugs might slip in 
unnoticed.

Any thoughts as to what exactly is masking the error in the unicode test?
(I just noticed it, because for some strange reason, the error is not 
masked on my "julia-lite" branch, and it showed up after
I merged in the last couple days of changes from JuliaLang/julia and ran 
the unit tests before pushing it to GitHub for people to play with)

Scott

On Sunday, February 14, 2016 at 5:16:17 AM UTC-5, Mauro wrote:
>
> Reported here https://github.com/JuliaLang/julia/issues/15072 
>
> On Sat, 2016-02-13 at 22:33, Scott Jones  > wrote: 
> > I'm seeing a very strange failure recently (within the last week), where 
> > running "test/runtests.jl" seems to pass, but running the individual 
> test shows 
> > a very different result. 
> > I've reduced it to this, it seems to be a problem with the scope used 
> for s in 
> > the third line. 
> > 
> > let s = "b\u0300lahβlahb\u0302láh", 
> >   g = ["b\u0300","l","a","h","β","l","a","h","b\u0302","l","á","h"] 
> >   g_ = map(s -> normalize_string(s, :NFC), g) 
> >   g0 = map(x -> normalize_string(x, :NFC), g) 
> >   println(g_) 
> >   println(g0) 
> > end 
> > 
> > 
> > I'm rather concerned, because this failure when running test/unicode.jl 
> is 
> > masked when running test/runtests.jl - could other failures on master be 
> > getting masked? 
>

[julia-users] Re: Error with Julia + Juno IDE bundle installation on Windows 10

[Mike Kipling]

Hi Lutfullah,

I was able to use Juno to open a DOS command window with a Julia command 
prompt.  However, after entering the Pkg.update() command I get the 
following error message.

INFO: Updating METADATA...
ERROR: chdir METADATA: no such file or directory (ENOENT)
 in cd at file.jl:11 (repeats 2 times)

Here is the contents of line 11 in the 
file C:\Juno\resources\app\julia\share\julia\base\file.jl
uv_error("chdir $dir", ccall(:uv_chdir, Cint, (Ptr{Uint8},), dir))

Mike

On Saturday, February 13, 2016 at 8:53:36 PM UTC-6, Lutfullah Tomak wrote:
>
> Hi, welcome Julia.
> You don't need to install julia separately. Juno has one in it with all 
> the required packages. Somehow, your installation  of Juno is missing 
> Requires package. 
> First, in Juno press Ctrl+Space, enter `Julia: open a new terminal repl` 
> and click to what shows up to open julia in console mode. 
> Second, in julia repl, try `Pkg.update()` .
> Third, when it finishes with success close everything and reopen Juno. 
> Fourth, if it still fails, then open up the julia repl again and do 
> `Pkg.add("Requires")` .  
> Last, when it finishes,close everything and reopen Juno, see if it starts 
> correctly.
> If it still shows error please ask again.
> Note:Omit quotation(`) while writing.

[julia-users] Re-loading edited scripts into REPL

[Wilton Basse]

So I write a script in text editor, save into ~/bin/myscript.jl.  Then in 
REPL use include("bin/myscript.jl") to run and test in REPL.
Hmmm, see some changes to make, go back to text editor and edit and save 
changes.

Here's the question: When I go back to REPL to test, how do I make sure I 
have *only* the most recent edit loaded?  If I do include() again is the 
old version replaced?  Do I need to "un-include" the old version somehow?

I have been closing and re-opening the REPL and re-doing include(), but 
that's really unwieldy, especially using multiple scripts, plus I end up 
losing previous work within REPL.

Thanks!