Re: [julia-users] Re: help understanding different ways of wrapping functions

[Mauro]

On Wed, 2016-09-28 at 08:50, Gunnar Farnebäck  wrote:
> It's normal that manually inlined code of this kind is faster than wrapped
> code unless the compiler manages to see the full inlining potential. In
> this case the huge memory allocations for the wrapped solutions indicates
> that it's nowhere near doing that at all. I doubt it will take you all the
> way but start with modifying your inner M_CPS function to only take
> positional arguments or declaring the type of the keyword argument as
> suggested in the performance tips section of the manual.

Even annotated keywords are slower than normal, positional ones (except
when their default value is used, as far as I recall).

> Den onsdag 28 september 2016 kl. 06:29:37 UTC+2 skrev K leo:
>>
>> I tested a few different ways of wrapping functions.  It looks different
>> ways of wrapping has slightly different costs.  But the most confusing to
>> me is that putting everything inline looks much faster than wrapping things
>> up.  I would understand this in other languages, but I thought Julia
>> advocates simple wrapping.  Can anyone help explain what is happening
>> below, and how I can do most efficient wrapping in the demo code?
>>
>> Demo code is included below.
>>
>> julia> versioninfo()
>> Julia Version 0.5.0
>> Commit 3c9d753 (2016-09-19 18:14 UTC)
>> Platform Info:
>>   System: Linux (x86_64-pc-linux-gnu)
>>   CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblas64_
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>>
>> julia> testFunc()
>> calling LoopCP (everything inline)
>>   0.097556 seconds (2.10 k allocations: 290.625 KB)
>> elapsed time (ns): 97555896
>> bytes allocated:   297600
>> pool allocs:   2100
>> [0.0,4200.0,0.0,0.0,4200.0,4200.0,4200.0,4200.0,0.0,4200.0,4200.0]
>>
>> calling LoopCP0 (slightly wrapped)
>>   4.173830 seconds (49.78 M allocations: 2.232 GB, 5.83% gc time)
>> elapsed time (ns): 4173830495
>> gc time (ns):  243516584
>> bytes allocated:   2396838538
>> pool allocs:   49783357
>> GC pauses: 104
>> full collections:  1
>> [4200.0,0.0,4200.0,4200.0,0.0,0.0,0.0,0.0,4200.0,0.0,0.0]
>>
>> calling LoopCP1 (wrapped one way)
>>   5.274723 seconds (59.59 M allocations: 2.378 GB, 3.62% gc time)
>> elapsed time (ns): 5274722983
>> gc time (ns):  191036337
>> bytes allocated:   2553752638
>> pool allocs:   59585834
>> GC pauses: 112
>> [8400.0,0.0,8400.0,8400.0,0.0,0.0,0.0,0.0,8400.0,0.0,0.0]
>>
>> calling LoopCP2 (wrapped another way)
>>   5.212895 seconds (59.58 M allocations: 2.378 GB, 3.60% gc time)
>> elapsed time (ns): 5212894550
>> gc time (ns):  187696529
>> bytes allocated:   2553577600
>> pool allocs:   59582100
>> GC pauses: 111
>> [0.0,8400.0,0.0,0.0,8400.0,8400.0,8400.0,8400.0,0.0,8400.0,8400.0]
>>
>> const dim=1000
>>>
>>>
 type Tech
>>>
>>> a::Array{Float64,1}
>>>
>>> c::Array{Int,1}
>>>
>>>
 function Tech()
>>>
>>> this = new()
>>>
>>> this.a = zeros(Float64, dim)
>>>
>>> this.c = rand([0,1;], dim)
>>>
>>> this
>>>
>>> end
>>>
>>> end
>>>
>>>
 function LoopCP(csign::Int, tech::Tech)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> @inbounds for i = 1:dim
>>>
>>> if csign == tech.c[i]
>>>
>>> tech.a[i] += 2.*xRat
>>>
>>> else
>>>
>>> tech.a[i] = 0.
>>>
>>> end
>>>
>>> end
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function M_CPS(i::Int, csign::Int, tech::Tech; xRat=0.)
>>>
>>> if csign == tech.c[i]
>>>
>>> tech.a[i] += 2.*xRat
>>>
>>> else
>>>
>>> tech.a[i] = 0.
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function LoopCP0(csign::Int, tech::Tech)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> @inbounds for i = 1:dim
>>>
>>> M_CPS(i, csign, tech, xRat=xRat)
>>>
>>> end
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function MoleculeWrapS(csign::Int, tech::Tech, molecule::Function,
 xRat=0.)
>>>
>>> @inbounds for i = 1:dim
>>>
>>> molecule(i, csign, tech; xRat=xRat)
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function LoopRunnerM1(csign::Int, tech::Tech, molecule::Function)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> MoleculeWrapS(csign, tech, molecule, xRat)
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 LoopCP1(csign::Int, tech::Tech) = LoopRunnerM1(csign, tech, M_CPS)
>>>
>>>
 WrapCPS(csign::Int, tech::Tech, xRat=0.) = MoleculeWrapS(csign, tech,
 M_CPS, xRat)
>>>
>>>
 function LoopRunnerM2(csign::Int, tech::Tech, loop::Function)
>>>
>>> for j=1:10
>>>
>>>  

[julia-users] Re: julia-i18n: Translators and reviewer needed!

[Ismael Venegas Castelló]

Julia website i18n

I've made a video of me translating the Julia website, just in case anyone 
is curious of how the workflow is like, you can help us translate the 
website to your native language ...one string at a time:



   - 
   
*https://www.livecoding.tv/ismael-vc/videos/oyvBm-julia-language-website-i18n*
   

Let me know what you guys think! [image: :smiley:]

El jueves, 22 de septiembre de 2016, 1:32:13 (UTC-5), Ismael Venegas 
Castelló escribió:
>
> Looking how to contribute to Julia? Check out the web translation project 
> on Transifex. 
> Help us bring Julia internationalization to your native language one 
> string at a time!
>
>
>- https://www.transifex.com/julialang-i18n/julialang-web
>- https://gitter.im/JuliaLangEs/julia-i18n
>- https://github.com/JuliaLang/julialang.github.com/pull/252
>
>

[julia-users] translating julia

[Henri Girard]

I went to french translation startet to translate but can't see it on 
julialang.org ? 
it's not actualized ?
Regards

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[Daniel Carrera]

Suppressor.jl would suppress everything, right?

So the idea is that one would use `@suppress import("foo.jl")` ?

As heavy as ClobberingReload.jl is, I appreciate that it only suppresses
*one* error -- the annoying "you redefined a method" error that IMO should
never have existed in the first place. If there are other errors, like
syntax errors, in my script, I do want to hear about those. Or have I
misunderstood how Suppressor.jl works?

Cheers,
Daniel.


On 28 September 2016 at 07:36, Chris Rackauckas  wrote:

> You could've just used Suppressor.jl
> ...
>
> On Tuesday, September 27, 2016 at 9:55:53 PM UTC-7, K leo wrote:
>>
>>
>> On Wednesday, September 28, 2016 at 12:53:12 PM UTC+8, K leo wrote:
>>>
>>> This a very heavy install.  It's fetching tons of things that I have not
>>> used.  Not sure what they are, but seems like trashing my system.
>>>
>>
>> julia> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
>> INFO: Cloning ClobberingReload from git://github.com/cstjean/Clobb
>> eringReload.jl.git
>> INFO: Computing changes...
>> INFO: Cloning cache of IJulia from https://github.com/JuliaLang/I
>> Julia.jl.git
>> INFO: Cloning cache of Nettle from https://github.com/staticfloat
>> /Nettle.jl.git
>> INFO: Cloning cache of ZMQ from https://github.com/JuliaLang/ZMQ.jl.git
>> INFO: Installing Conda v0.3.2
>> INFO: Installing IJulia v1.3.2
>> INFO: Installing Nettle v0.2.4
>> INFO: Installing ZMQ v0.3.4
>> INFO: Building Nettle
>> INFO: Building ZMQ
>> INFO: Building IJulia
>> INFO: Installing Jupyter via the Conda package.
>> INFO: Downloading miniconda installer ...
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>> 100 25.9M  100 25.9M0 0  1104k  0  0:00:24  0:00:24 --:--:--
>> 2297k
>> INFO: Installing miniconda ...
>> PREFIX=/home/xxx/.julia/v0.5/Conda/deps/usr
>> installing: _cache-0.0-py27_x0 ...
>> installing: python-2.7.11-0 ...
>> installing: conda-env-2.4.5-py27_0 ...
>> installing: openssl-1.0.2g-0 ...
>> installing: pycosat-0.6.1-py27_0 ...
>> installing: pyyaml-3.11-py27_1 ...
>> installing: readline-6.2-2 ...
>> installing: requests-2.9.1-py27_0 ...
>> installing: sqlite-3.9.2-0 ...
>> installing: tk-8.5.18-0 ...
>> installing: yaml-0.1.6-0 ...
>> installing: zlib-1.2.8-0 ...
>> installing: conda-4.0.5-py27_0 ...
>> installing: pycrypto-2.6.1-py27_0 ...
>> installing: pip-8.1.1-py27_1 ...
>> installing: wheel-0.29.0-py27_0 ...
>> installing: setuptools-20.3-py27_0 ...
>> Python 2.7.11 :: Continuum Analytics, Inc.
>> creating default environment...
>> installation finished.
>> Fetching package metadata: 
>> Solving package specifications: .
>>
>> Package plan for installation in environment
>> /home/xxx/.julia/v0.5/Conda/deps/usr:
>>
>> The following packages will be downloaded:
>>
>> package|build
>> ---|-
>> conda-env-2.6.0|0  502 B
>> expat-2.1.0|0 365 KB
>> icu-54.1   |011.3 MB
>> jpeg-8d|1 806 KB
>> libffi-3.2.1   |0  36 KB
>> libgcc-5.2.0   |0 1.1 MB
>> libsodium-1.0.10   |0 1.2 MB
>> libxcb-1.12|0 1.5 MB
>> sqlite-3.13.0  |0 4.0 MB
>> dbus-1.10.10   |0 2.4 MB
>> glib-2.43.0|1 5.4 MB
>> libpng-1.6.22  |0 214 KB
>> libxml2-2.9.2  |0 4.2 MB
>> python-2.7.12  |112.1 MB
>> zeromq-4.1.4   |0 4.1 MB
>> backports-1.0  |   py27_0   1 KB
>> backports_abc-0.4  |   py27_0   5 KB
>> decorator-4.0.10   |   py27_0  12 KB
>> enum34-1.1.6   |   py27_0  53 KB
>> freetype-2.5.5 |1 2.5 MB
>> functools32-3.2.3.2|   py27_0  15 KB
>> gstreamer-1.8.0|0 2.6 MB
>> ipython_genutils-0.1.0 |   py27_0  32 KB
>> markupsafe-0.23|   py27_2  31 KB
>> mistune-0.7.3  |   py27_0 560 KB
>> path.py-8.2.1  |   py27_0  45 KB
>> ptyprocess-0.5.1   |   py27_0  19 KB
>> pygments-2.1.3 |   py27_0 1.2 MB
>> pytz-2016.6.1  | 

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[Ismael Venegas Castelló]

Daniel indeed Suppressor provides the following macros: @suppress (will 
suppress both STDERR and STDOUT), @suppress_out (just STDOUT) and 
@suppress_err (just STDERR), notice that STDERR suppresses warnings but not 
errors! This can be easily understood reading code in the README:

julia> using Suppressor 

julia> @suppress begin  
   println("This string doesn't get printed!")  
   warn("This warning is ignored.") 
   end  

julia> @suppress_out begin  
   println("This string doesn't get printed!")  
   warn("This warning is important")
   end
WARNING: This warning is important  

julia> @suppress_err begin  
   println("This string gets printed!") 
   warn("This warning is unimportant")  
   end  
This string gets printed!   

julia> @suppress begin
   println("This string doesn't get printed!")
   warn("This warning is ignored.")
   error("Remember that errors are still printed!")
   end
--
ErrorException  Stacktrace (most recent 
call last)
[#2] — anonymous
   ⌙ at :?

[#1] — macro expansion;
   ⌙ at Suppressor.jl:16 [inlined]

Remember that errors are still printed!

julia>


So in order to ignore the error you would have to explicitly wrap it in a 
try and explicitly silence it. Also notice that:

import("foo.jl")

is a syntax error, you're supposed to do:

@suppress include("foo.jl")

instead. If you find a bug please file an issue, thanks!


El miércoles, 28 de septiembre de 2016, 2:56:04 (UTC-5), Daniel Carrera 
escribió:
>
> Suppressor.jl would suppress everything, right?
>
> So the idea is that one would use `@suppress import("foo.jl")` ?
>
> As heavy as ClobberingReload.jl is, I appreciate that it only suppresses 
> *one* error -- the annoying "you redefined a method" error that IMO should 
> never have existed in the first place. If there are other errors, like 
> syntax errors, in my script, I do want to hear about those. Or have I 
> misunderstood how Suppressor.jl works?
>
> Cheers,
> Daniel.
>
>
> On 28 September 2016 at 07:36, Chris Rackauckas  > wrote:
>
>> You could've just used Suppressor.jl 
>> ...
>>
>> On Tuesday, September 27, 2016 at 9:55:53 PM UTC-7, K leo wrote:
>>>
>>>
>>> On Wednesday, September 28, 2016 at 12:53:12 PM UTC+8, K leo wrote:

 This a very heavy install.  It's fetching tons of things that I have 
 not used.  Not sure what they are, but seems like trashing my system.

>>>
>>> julia> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
>>> INFO: Cloning ClobberingReload from git://
>>> github.com/cstjean/ClobberingReload.jl.git
>>> INFO: Computing changes...
>>> INFO: Cloning cache of IJulia from 
>>> https://github.com/JuliaLang/IJulia.jl.git
>>> INFO: Cloning cache of Nettle from 
>>> https://github.com/staticfloat/Nettle.jl.git
>>> INFO: Cloning cache of ZMQ from https://github.com/JuliaLang/ZMQ.jl.git
>>> INFO: Installing Conda v0.3.2
>>> INFO: Installing IJulia v1.3.2
>>> INFO: Installing Nettle v0.2.4
>>> INFO: Installing ZMQ v0.3.4
>>> INFO: Building Nettle
>>> INFO: Building ZMQ
>>> INFO: Building IJulia
>>> INFO: Installing Jupyter via the Conda package.
>>> INFO: Downloading miniconda installer ...
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time 
>>>  Current
>>>  Dload  Upload   Total   SpentLeft 
>>>  Speed
>>> 100 25.9M  100 25.9M0 0  1104k  0  0:00:24  0:00:24 --:--:-- 
>>> 2297k
>>> INFO: Installing miniconda ...
>>> PREFIX=/home/xxx/.julia/v0.5/Conda/deps/usr
>>> installing: _cache-0.0-py27_x0 ...
>>> installing: python-2.7.11-0 ...
>>> installing: conda-env-2.4.5-py27_0 ...
>>> installing: openssl-1.0.2g-0 ...
>>> installing: pycosat-0.6.1-py27_0 ...
>>> installing: pyyaml-3.11-py27_1 ...
>>> installing: readline-6.2-2 ...
>>> installing: requests-2.9.1-py27_0 ...
>>> installing: sqlite-3.9.2-0 ...
>>> installing: tk-8.5.18-0 ...
>>> installing: yaml-0.1.6-0 ...
>>> installing: zlib-1.2.8-0 ...
>>> installing: conda-4.0.5-py27_0 ...
>>> installing: pycrypto-2.6.1-py27_0 ...
>>> installing: pip-8.1.1-py27_1 ...
>>> installing: wheel-0.29.0-py27_0 ...
>>> installing: setuptools-20.3-py27_0 ...
>>> Python 2.7.11 :: Continuum Analytics, Inc.
>>> creating default environment...
>>> installation finished.
>>> Fetching package metadata: 
>>> Solving package specifications: .
>>>
>>> Pa

[julia-users] Re: translating julia

[Ismael Venegas Castelló]

Hello Henri!

Currently French is about 0% translated, we are adding to production the 
languages that at minimum have the home page translated 90 %, but you can 
see the current progress of all the languages in the staging site here:


   - http://julialanges.github.io
   
You can see here a video I did tonight, were I am translating, in order to 
give a taste of the workflow involved in doing this with Transifex Live.

Please let me know if you have any doubt and I will gladly help you as much 
as I can and thank you very much for your interest and support to this 
project.

Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:
>
> I went to french translation startet to translate but can't see it on 
> julialang.org ? 
> it's not actualized ?
> Regards
>

[julia-users] Re: translating julia

[Ismael Venegas Castelló]

I forgot to link the video I mentioned, oops

here it is: 
*https://www.livecoding.tv/ismael-vc/videos/oyvBm-julia-language-website-i18n 
*

Cheers

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:
>
> I went to french translation startet to translate but can't see it on 
> julialang.org ? 
> it's not actualized ?
> Regards
>

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

thanks...


Le 28/09/2016 à 10:27, Ismael Venegas Castelló a écrit :

I forgot to link the video I mentioned, oops

here it is: 
*https://www.livecoding.tv/ismael-vc/videos/oyvBm-julia-language-website-i18n 
*


Cheers

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:


I went to french translation startet to translate but can't see it
on julialang.org  ?
it's not actualized ?
Regards

[julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Ferran Mazzanti]

Hi,

it seems that PyPlot is still broken in 0.5.0 and OSX, at least 
Mavericks... Anybody else has faced this problem? If yes, how can I solve 
it? If not, what versions of PyCall/PyPlot are you using? The ones I was 
told to use here still work, but spit quite a lot of warnings etc... and it 
is not clean.

Thanks a lot,

Ferran.

On Thursday, August 18, 2016 at 10:47:27 AM UTC+2, Ferran Mazzanti wrote:
>
> Dear all,
>
> looks like lots of messing around with versions had rendered PyPlot 
> unusable in 0.4.6 under OSX (at least).
> Now I need to do some work that requires its use so I need to have it up 
> and working. Could anybody please let me know
> if it is possible to revert to a previous working version, and how this is 
> done? I know it used to work with 0.4.6 as I had it
> installed, but once I did an update and things stopped working since then.
>
> Thanks for your help,
>
> Ferran.
>

[julia-users] ClusterManagers timeout

[Matthew Pearce]

Hello

If I request some nodes using addprocs_slurm, slurm of course enqueues the 
request. However, if the request is not fulfilled within a certain time, I 
get a timeout type message from ClusterManagers.

Is there a way of telling ClusterManagers I'm prepared to wait (a long 
time) for my nodes to become available? Use case is running an analysis 
script unchanged, but not interactively so can tolerate a big pause before 
work starts.

Best 

Matthew

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

Hi Ismael,

Looking at the git julialanges, one older french translation is showing 
(not mine) and above is mine still in english ?


Is there a gap between translation and display ?

Just for information.



Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :

Hello Henri!

Currently French is about 0% translated, we are adding to production 
the languages that at minimum have the home page translated 90 %, but 
you can see the current progress of all the languages in the staging 
site here:


  * http://julialanges.github.io

You can see here a video I did tonight, were I am translating, in 
order to give a taste of the workflow involved in doing this with 
Transifex Live.


Please let me know if you have any doubt and I will gladly help you as 
much as I can and thank you very much for your interest and support to 
this project.


Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:


I went to french translation startet to translate but can't see it
on julialang.org  ?
it's not actualized ?
Regards

[julia-users] Re: "both DataArrays and StatsBase export "rle"; uses of it in module DataFrames must be qualified"

[Patrick Kofod Mogensen]

As the error says, they both export a function called rle, so it is not 
possible to know which one you're trying to call, if you don't qualify 
them. Qualifying means writing "package name dot" and then the function, as 
seen below

module A
export f
f(x::Int64) = x
end

module B
export f
f(x::Int64) = x+1
end

using A, B

f(3) # error
A.f(3) # returns x = 3
B.f(3) # returns x + 1 = 3 + 1



On Sunday, September 25, 2016 at 3:15:57 PM UTC+2, K leo wrote:
>
> I get a few warning messages like this often.  Does it mean that 
> DataFrames package need to be updated, or that I need to do something in my 
> user code?
>

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

I am wondering if one must write the html mark when translating ?


Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :

Hello Henri!

Currently French is about 0% translated, we are adding to production 
the languages that at minimum have the home page translated 90 %, but 
you can see the current progress of all the languages in the staging 
site here:


  * http://julialanges.github.io

You can see here a video I did tonight, were I am translating, in 
order to give a taste of the workflow involved in doing this with 
Transifex Live.


Please let me know if you have any doubt and I will gladly help you as 
much as I can and thank you very much for your interest and support to 
this project.


Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:


I went to french translation startet to translate but can't see it
on julialang.org  ?
it's not actualized ?
Regards

[julia-users] [ANN] UnicodeFun

[Simon Danisch]

Good news everyone!
I've written a small library that offers various transformations of text to 
special Unicode characters.
The most prominent one is the latex-string to latex-unicode:

"\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: \\itA\\bfv 
= \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"


It doesn't support the whole range of latex, but I hope it will be enough 
for simple formulas.
I will obviously use this library for latex label support in GLVisualize 
, but I hope that this library 
can also be usable in other contexts! (REPL latex renderer?) 
Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly registered, 
a Pkg.update() might be needed)

Please feel free to report latex strings that are not working, or help 
adding new transformations! :)

Best,
Simon

Re: [julia-users] [ANN] UnicodeFun

[henri.gir...@gmail.com]

thanks. I wish I could get the \frac symbol is there possible to make it ?

1

___

2


Best
Henri

Le 28/09/2016 à 12:05, Simon Danisch a écrit :

Good news everyone!
I've written a small library that offers various transformations of 
text to special Unicode characters.

The most prominent one is the latex-string to latex-unicode:
"\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
\\itA\\bfv = \\lambda_i\\bfv"

==>  "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"

It doesn't support the whole range of latex, but I hope it will be 
enough for simple formulas.
I will obviously use this library for latex label support in 
GLVisualize , but I hope 
that this library can also be usable in other contexts! (REPL latex 
renderer?)
Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
registered, a Pkg.update() might be needed)


Please feel free to report latex strings that are not working, or help 
adding new transformations! :)


Best,
Simon

[julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

The best adhoc solution I could find looks like this:
1̲2̲ ̲/̲ ̲2̲0̲
200

So not impossible... I'll see how we can integrate this


Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>
> Good news everyone!
> I've written a small library that offers various transformations of text 
> to special Unicode characters.
> The most prominent one is the latex-string to latex-unicode:
>
> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
> \\itA\\bfv = \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"
>
>
> It doesn't support the whole range of latex, but I hope it will be enough 
> for simple formulas.
> I will obviously use this library for latex label support in GLVisualize 
> , but I hope that this library 
> can also be usable in other contexts! (REPL latex renderer?) 
> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
> registered, a Pkg.update() might be needed)
>
> Please feel free to report latex strings that are not working, or help 
> adding new transformations! :)
>
> Best,
> Simon
>

[julia-users] Re: norm() is slow when variables are arguments

[Steven G. Johnson]

On a separate note, norm([u; v]) for scalar u and v is going to be a lot 
slower than hypot(u, v) or sqrt(u*u + v*v) (although the latter does not 
check for overflow the way hypot does).   Allocating little arrays and 
calling "vector" functions for everything, even small computations on a few 
scalars, is a bad habit from Matlab.

[julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

I added the to_fraction function:

to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯") -->

α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
 ℝ: 𝐴𝐯 = λᵢ𝐯

https://github.com/SimonDanisch/UnicodeFun.jl/pull/3

But I won't have time to add this to the *to*_*latex* function, since it's 
a bit more involved with the line break.

Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>
> Good news everyone!
> I've written a small library that offers various transformations of text 
> to special Unicode characters.
> The most prominent one is the latex-string to latex-unicode:
>
> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
> \\itA\\bfv = \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"
>
>
> It doesn't support the whole range of latex, but I hope it will be enough 
> for simple formulas.
> I will obviously use this library for latex label support in GLVisualize 
> , but I hope that this library 
> can also be usable in other contexts! (REPL latex renderer?) 
> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
> registered, a Pkg.update() might be needed)
>
> Please feel free to report latex strings that are not working, or help 
> adding new transformations! :)
>
> Best,
> Simon
>

[julia-users] Re: "both DataArrays and StatsBase export "rle"; uses of it in module DataFrames must be qualified"

[K leo]

Thanks for the reply.  Then this is an issue in DataFrames.

On Wednesday, September 28, 2016 at 5:47:03 PM UTC+8, Patrick Kofod 
Mogensen wrote:
>
> As the error says, they both export a function called rle, so it is not 
> possible to know which one you're trying to call, if you don't qualify 
> them. Qualifying means writing "package name dot" and then the function, as 
> seen below
>
> module A
> export f
> f(x::Int64) = x
> end
>
> module B
> export f
> f(x::Int64) = x+1
> end
>
> using A, B
>
> f(3) # error
> A.f(3) # returns x = 3
> B.f(3) # returns x + 1 = 3 + 1
>
>
>
> On Sunday, September 25, 2016 at 3:15:57 PM UTC+2, K leo wrote:
>>
>> I get a few warning messages like this often.  Does it mean that 
>> DataFrames package need to be updated, or that I need to do something in my 
>> user code?
>>
>

[julia-users] Re: help understanding different ways of wrapping functions

[K leo]

Thanks so much for the tips.  The culprit is the keyword argument 
(xRat=0.).  Declaring it made the wrapped code twice as fast, but still way 
slower than the inline code.  But making it positional made the wrapped 
code just a little slower than the inline code - big improvement.

On Wednesday, September 28, 2016 at 2:50:40 PM UTC+8, Gunnar Farnebäck 
wrote:
>
> It's normal that manually inlined code of this kind is faster than wrapped 
> code unless the compiler manages to see the full inlining potential. In 
> this case the huge memory allocations for the wrapped solutions indicates 
> that it's nowhere near doing that at all. I doubt it will take you all the 
> way but start with modifying your inner M_CPS function to only take 
> positional arguments or declaring the type of the keyword argument as 
> suggested in the performance tips section of the manual.
>
> Den onsdag 28 september 2016 kl. 06:29:37 UTC+2 skrev K leo:
>>
>> I tested a few different ways of wrapping functions.  It looks different 
>> ways of wrapping has slightly different costs.  But the most confusing to 
>> me is that putting everything inline looks much faster than wrapping things 
>> up.  I would understand this in other languages, but I thought Julia 
>> advocates simple wrapping.  Can anyone help explain what is happening 
>> below, and how I can do most efficient wrapping in the demo code?
>>
>> Demo code is included below.
>>
>> julia> versioninfo()
>> Julia Version 0.5.0
>> Commit 3c9d753 (2016-09-19 18:14 UTC)
>> Platform Info:
>>   System: Linux (x86_64-pc-linux-gnu)
>>   CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblas64_
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>>
>> julia> testFunc()
>> calling LoopCP (everything inline)
>>   0.097556 seconds (2.10 k allocations: 290.625 KB)
>> elapsed time (ns): 97555896
>> bytes allocated:   297600
>> pool allocs:   2100
>> [0.0,4200.0,0.0,0.0,4200.0,4200.0,4200.0,4200.0,0.0,4200.0,4200.0]
>>
>> calling LoopCP0 (slightly wrapped)
>>   4.173830 seconds (49.78 M allocations: 2.232 GB, 5.83% gc time)
>> elapsed time (ns): 4173830495
>> gc time (ns):  243516584
>> bytes allocated:   2396838538
>> pool allocs:   49783357
>> GC pauses: 104
>> full collections:  1
>> [4200.0,0.0,4200.0,4200.0,0.0,0.0,0.0,0.0,4200.0,0.0,0.0]
>>
>> calling LoopCP1 (wrapped one way)
>>   5.274723 seconds (59.59 M allocations: 2.378 GB, 3.62% gc time)
>> elapsed time (ns): 5274722983
>> gc time (ns):  191036337
>> bytes allocated:   2553752638
>> pool allocs:   59585834
>> GC pauses: 112
>> [8400.0,0.0,8400.0,8400.0,0.0,0.0,0.0,0.0,8400.0,0.0,0.0]
>>
>> calling LoopCP2 (wrapped another way)
>>   5.212895 seconds (59.58 M allocations: 2.378 GB, 3.60% gc time)
>> elapsed time (ns): 5212894550
>> gc time (ns):  187696529
>> bytes allocated:   2553577600
>> pool allocs:   59582100
>> GC pauses: 111
>> [0.0,8400.0,0.0,0.0,8400.0,8400.0,8400.0,8400.0,0.0,8400.0,8400.0]
>>
>> const dim=1000
>>>
>>>
 type Tech
>>>
>>> a::Array{Float64,1}
>>>
>>> c::Array{Int,1}
>>>
>>>
 function Tech()
>>>
>>> this = new()
>>>
>>> this.a = zeros(Float64, dim)
>>>
>>> this.c = rand([0,1;], dim)
>>>
>>> this
>>>
>>> end
>>>
>>> end
>>>
>>>
 function LoopCP(csign::Int, tech::Tech)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> @inbounds for i = 1:dim
>>>
>>> if csign == tech.c[i]
>>>
>>> tech.a[i] += 2.*xRat
>>>
>>> else
>>>
>>> tech.a[i] = 0.
>>>
>>> end
>>>
>>> end
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function M_CPS(i::Int, csign::Int, tech::Tech; xRat=0.)
>>>
>>> if csign == tech.c[i]
>>>
>>> tech.a[i] += 2.*xRat
>>>
>>> else
>>>
>>> tech.a[i] = 0.
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function LoopCP0(csign::Int, tech::Tech)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> @inbounds for i = 1:dim
>>>
>>> M_CPS(i, csign, tech, xRat=xRat)
>>>
>>> end
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function MoleculeWrapS(csign::Int, tech::Tech, molecule::Function, 
 xRat=0.)
>>>
>>> @inbounds for i = 1:dim
>>>
>>> molecule(i, csign, tech; xRat=xRat)
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 function LoopRunnerM1(csign::Int, tech::Tech, molecule::Function)
>>>
>>> for j=1:10
>>>
>>> for xRat in [1.:20.;]
>>>
>>> MoleculeWrapS(csign, tech, molecule, xRat)
>>>
>>> end #
>>>
>>> end
>>>
>>> nothing
>>>
>>> end
>>>
>>>
 LoopCP1(csign::Int, tech::Tech) = LoopRunnerM1(csign, tech, M_CPS)
>>>
>>>
 Wra

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[Cedric St-Jean]

I just removed the IJulia dependency from ClobberingReload.jl (made it 
optional - autoreload still works for IJulia users). Thank you for the 
feedback. If you `Pkg.checkout("ClobberingReload")`, it should 
automatically remove IJulia and its dependencies.

BTW, if you haven't tried IJulia/Jupyter notebooks, I would strongly 
recommend giving it a shot. It's the #2 most popular Julia package for a 
reason.

Cédric

On Wednesday, September 28, 2016 at 12:55:53 AM UTC-4, K leo wrote:
>
>
> On Wednesday, September 28, 2016 at 12:53:12 PM UTC+8, K leo wrote:
>>
>> This a very heavy install.  It's fetching tons of things that I have not 
>> used.  Not sure what they are, but seems like trashing my system.
>>
>
> julia> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
> INFO: Cloning ClobberingReload from git://
> github.com/cstjean/ClobberingReload.jl.git
> INFO: Computing changes...
> INFO: Cloning cache of IJulia from 
> https://github.com/JuliaLang/IJulia.jl.git
> INFO: Cloning cache of Nettle from 
> https://github.com/staticfloat/Nettle.jl.git
> INFO: Cloning cache of ZMQ from https://github.com/JuliaLang/ZMQ.jl.git
> INFO: Installing Conda v0.3.2
> INFO: Installing IJulia v1.3.2
> INFO: Installing Nettle v0.2.4
> INFO: Installing ZMQ v0.3.4
> INFO: Building Nettle
> INFO: Building ZMQ
> INFO: Building IJulia
> INFO: Installing Jupyter via the Conda package.
> INFO: Downloading miniconda installer ...
>   % Total% Received % Xferd  Average Speed   TimeTime Time 
>  Current
>  Dload  Upload   Total   SpentLeft 
>  Speed
> 100 25.9M  100 25.9M0 0  1104k  0  0:00:24  0:00:24 --:--:-- 
> 2297k
> INFO: Installing miniconda ...
> PREFIX=/home/xxx/.julia/v0.5/Conda/deps/usr
> installing: _cache-0.0-py27_x0 ...
> installing: python-2.7.11-0 ...
> installing: conda-env-2.4.5-py27_0 ...
> installing: openssl-1.0.2g-0 ...
> installing: pycosat-0.6.1-py27_0 ...
> installing: pyyaml-3.11-py27_1 ...
> installing: readline-6.2-2 ...
> installing: requests-2.9.1-py27_0 ...
> installing: sqlite-3.9.2-0 ...
> installing: tk-8.5.18-0 ...
> installing: yaml-0.1.6-0 ...
> installing: zlib-1.2.8-0 ...
> installing: conda-4.0.5-py27_0 ...
> installing: pycrypto-2.6.1-py27_0 ...
> installing: pip-8.1.1-py27_1 ...
> installing: wheel-0.29.0-py27_0 ...
> installing: setuptools-20.3-py27_0 ...
> Python 2.7.11 :: Continuum Analytics, Inc.
> creating default environment...
> installation finished.
> Fetching package metadata: 
> Solving package specifications: .
>
> Package plan for installation in environment 
> /home/xxx/.julia/v0.5/Conda/deps/usr:
>
> The following packages will be downloaded:
>
> package|build
> ---|-
> conda-env-2.6.0|0  502 B
> expat-2.1.0|0 365 KB
> icu-54.1   |011.3 MB
> jpeg-8d|1 806 KB
> libffi-3.2.1   |0  36 KB
> libgcc-5.2.0   |0 1.1 MB
> libsodium-1.0.10   |0 1.2 MB
> libxcb-1.12|0 1.5 MB
> sqlite-3.13.0  |0 4.0 MB
> dbus-1.10.10   |0 2.4 MB
> glib-2.43.0|1 5.4 MB
> libpng-1.6.22  |0 214 KB
> libxml2-2.9.2  |0 4.2 MB
> python-2.7.12  |112.1 MB
> zeromq-4.1.4   |0 4.1 MB
> backports-1.0  |   py27_0   1 KB
> backports_abc-0.4  |   py27_0   5 KB
> decorator-4.0.10   |   py27_0  12 KB
> enum34-1.1.6   |   py27_0  53 KB
> freetype-2.5.5 |1 2.5 MB
> functools32-3.2.3.2|   py27_0  15 KB
> gstreamer-1.8.0|0 2.6 MB
> ipython_genutils-0.1.0 |   py27_0  32 KB
> markupsafe-0.23|   py27_2  31 KB
> mistune-0.7.3  |   py27_0 560 KB
> path.py-8.2.1  |   py27_0  45 KB
> ptyprocess-0.5.1   |   py27_0  19 KB
> pygments-2.1.3 |   py27_0 1.2 MB
> pytz-2016.6.1  |   py27_0 178 KB
> pyzmq-15.4.0   |   py27_0 705 KB
> ruamel_yaml-0.11.14|   py27_0 352 KB
> simplegeneric-0.8.1|   py27_1   7 KB
> sip-4.18   |   py2

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[K leo]

julia> Pkg.checkout("ClobberingReload")
ERROR: ClobberingReload is not a git repo
 in checkout(::String, ::String, ::Bool, ::Bool) at ./pkg/entry.jl:225
 in 
(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#checkout,Tuple{String,String,Bool,Bool}})()
 
at ./pkg/dir.jl:31
 in 
cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#checkout,Tuple{String,String,Bool,Bool}},
 
::String) at ./file.jl:59
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
::Vararg{Any,N}) at ./pkg/dir.jl:31
 in checkout(::String) at ./pkg/pkg.jl:170

Thanks for the tip on IJulia/Jupyter.  Will try them.

On Wednesday, September 28, 2016 at 8:25:37 PM UTC+8, Cedric St-Jean wrote:
>
> I just removed the IJulia dependency from ClobberingReload.jl (made it 
> optional - autoreload still works for IJulia users). Thank you for the 
> feedback. If you `Pkg.checkout("ClobberingReload")`, it should 
> automatically remove IJulia and its dependencies.
>
> BTW, if you haven't tried IJulia/Jupyter notebooks, I would strongly 
> recommend giving it a shot. It's the #2 most popular Julia package for a 
> reason.
>
> Cédric
>
> On Wednesday, September 28, 2016 at 12:55:53 AM UTC-4, K leo wrote:
>>
>>
>> On Wednesday, September 28, 2016 at 12:53:12 PM UTC+8, K leo wrote:
>>>
>>> This a very heavy install.  It's fetching tons of things that I have not 
>>> used.  Not sure what they are, but seems like trashing my system.
>>>
>>
>> julia> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
>> INFO: Cloning ClobberingReload from git://
>> github.com/cstjean/ClobberingReload.jl.git
>> INFO: Computing changes...
>> INFO: Cloning cache of IJulia from 
>> https://github.com/JuliaLang/IJulia.jl.git
>> INFO: Cloning cache of Nettle from 
>> https://github.com/staticfloat/Nettle.jl.git
>> INFO: Cloning cache of ZMQ from https://github.com/JuliaLang/ZMQ.jl.git
>> INFO: Installing Conda v0.3.2
>> INFO: Installing IJulia v1.3.2
>> INFO: Installing Nettle v0.2.4
>> INFO: Installing ZMQ v0.3.4
>> INFO: Building Nettle
>> INFO: Building ZMQ
>> INFO: Building IJulia
>> INFO: Installing Jupyter via the Conda package.
>> INFO: Downloading miniconda installer ...
>>   % Total% Received % Xferd  Average Speed   TimeTime Time 
>>  Current
>>  Dload  Upload   Total   SpentLeft 
>>  Speed
>> 100 25.9M  100 25.9M0 0  1104k  0  0:00:24  0:00:24 --:--:-- 
>> 2297k
>> INFO: Installing miniconda ...
>> PREFIX=/home/xxx/.julia/v0.5/Conda/deps/usr
>> installing: _cache-0.0-py27_x0 ...
>> installing: python-2.7.11-0 ...
>> installing: conda-env-2.4.5-py27_0 ...
>> installing: openssl-1.0.2g-0 ...
>> installing: pycosat-0.6.1-py27_0 ...
>> installing: pyyaml-3.11-py27_1 ...
>> installing: readline-6.2-2 ...
>> installing: requests-2.9.1-py27_0 ...
>> installing: sqlite-3.9.2-0 ...
>> installing: tk-8.5.18-0 ...
>> installing: yaml-0.1.6-0 ...
>> installing: zlib-1.2.8-0 ...
>> installing: conda-4.0.5-py27_0 ...
>> installing: pycrypto-2.6.1-py27_0 ...
>> installing: pip-8.1.1-py27_1 ...
>> installing: wheel-0.29.0-py27_0 ...
>> installing: setuptools-20.3-py27_0 ...
>> Python 2.7.11 :: Continuum Analytics, Inc.
>> creating default environment...
>> installation finished.
>> Fetching package metadata: 
>> Solving package specifications: .
>>
>> Package plan for installation in environment 
>> /home/xxx/.julia/v0.5/Conda/deps/usr:
>>
>> The following packages will be downloaded:
>>
>> package|build
>> ---|-
>> conda-env-2.6.0|0  502 B
>> expat-2.1.0|0 365 KB
>> icu-54.1   |011.3 MB
>> jpeg-8d|1 806 KB
>> libffi-3.2.1   |0  36 KB
>> libgcc-5.2.0   |0 1.1 MB
>> libsodium-1.0.10   |0 1.2 MB
>> libxcb-1.12|0 1.5 MB
>> sqlite-3.13.0  |0 4.0 MB
>> dbus-1.10.10   |0 2.4 MB
>> glib-2.43.0|1 5.4 MB
>> libpng-1.6.22  |0 214 KB
>> libxml2-2.9.2  |0 4.2 MB
>> python-2.7.12  |112.1 MB
>> zeromq-4.1.4   |0 4.1 MB
>> backports-1.0  |   py27_0   1 KB
>> backports_abc-0.4  |   py27_0   5 KB
>> decorator-4.0.10   |   py27_0  12 KB
>> enum34-1.1.6   |   py27_0  53 KB
>> freetype-2.5.5 |1 2.5 MB
>> functools32-3.2.3.2|   py27_0  15 KB
>> 

Re: [julia-users] Re: [ANN] UnicodeFun

[henri.gir...@gmail.com]

Not bad at all :)

Thanks

Henri


Le 28/09/2016 à 13:20, Simon Danisch a écrit :

The best adhoc solution I could find looks like this:
1̲2̲ ̲/̲ ̲2̲0̲
200

So not impossible... I'll see how we can integrate this


Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:

Good news everyone!
I've written a small library that offers various transformations
of text to special Unicode characters.
The most prominent one is the latex-string to latex-unicode:

"\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in
\\bbR: \\itA\\bfv = \\lambda_i\\bfv"
==>  "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"


It doesn't support the whole range of latex, but I hope it will be
enough for simple formulas.
I will obviously use this library for latex label support in
GLVisualize , but I
hope that this library can also be usable in other contexts! (REPL
latex renderer?)
Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
registered, a Pkg.update() might be needed)

Please feel free to report latex strings that are not working, or
help adding new transformations! :)

Best,
Simon

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[Cedric St-Jean]

That's weird, I'm pretty sure that I've had the same issue when I tried it
just now, but I can't seem to reproduce it. ClobberingReload is still
installed on your system, right? How about this?

Pkg.checkout("ClobberingReload", "master")

If you want to try IJulia, you should Pkg.add("IJulia") before doing this,
because otherwise it'll get uninstalled by the Pkg.checkout, and it's the
package that dragged all of the dependencies you listed above.

On Wed, Sep 28, 2016 at 8:45 AM, K leo  wrote:

> julia> Pkg.checkout("ClobberingReload")
> ERROR: ClobberingReload is not a git repo
>  in checkout(::String, ::String, ::Bool, ::Bool) at ./pkg/entry.jl:225
>  in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#
> checkout,Tuple{String,String,Bool,Bool}})() at ./pkg/dir.jl:31
>  in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#
> checkout,Tuple{String,String,Bool,Bool}}, ::String) at ./file.jl:59
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String,
> ::Vararg{Any,N}) at ./pkg/dir.jl:31
>  in checkout(::String) at ./pkg/pkg.jl:170
>
> Thanks for the tip on IJulia/Jupyter.  Will try them.
>
> On Wednesday, September 28, 2016 at 8:25:37 PM UTC+8, Cedric St-Jean wrote:
>>
>> I just removed the IJulia dependency from ClobberingReload.jl (made it
>> optional - autoreload still works for IJulia users). Thank you for the
>> feedback. If you `Pkg.checkout("ClobberingReload")`, it should
>> automatically remove IJulia and its dependencies.
>>
>> BTW, if you haven't tried IJulia/Jupyter notebooks, I would strongly
>> recommend giving it a shot. It's the #2 most popular Julia package for a
>> reason.
>>
>> Cédric
>>
>> On Wednesday, September 28, 2016 at 12:55:53 AM UTC-4, K leo wrote:
>>>
>>>
>>> On Wednesday, September 28, 2016 at 12:53:12 PM UTC+8, K leo wrote:

 This a very heavy install.  It's fetching tons of things that I have
 not used.  Not sure what they are, but seems like trashing my system.

>>>
>>> julia> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
>>> INFO: Cloning ClobberingReload from git://github.com/cstjean/Clobb
>>> eringReload.jl.git
>>> INFO: Computing changes...
>>> INFO: Cloning cache of IJulia from https://github.com/JuliaLang/I
>>> Julia.jl.git
>>> INFO: Cloning cache of Nettle from https://github.com/staticfloat
>>> /Nettle.jl.git
>>> INFO: Cloning cache of ZMQ from https://github.com/JuliaLang/ZMQ.jl.git
>>> INFO: Installing Conda v0.3.2
>>> INFO: Installing IJulia v1.3.2
>>> INFO: Installing Nettle v0.2.4
>>> INFO: Installing ZMQ v0.3.4
>>> INFO: Building Nettle
>>> INFO: Building ZMQ
>>> INFO: Building IJulia
>>> INFO: Installing Jupyter via the Conda package.
>>> INFO: Downloading miniconda installer ...
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>>  Current
>>>  Dload  Upload   Total   SpentLeft
>>>  Speed
>>> 100 25.9M  100 25.9M0 0  1104k  0  0:00:24  0:00:24 --:--:--
>>> 2297k
>>> INFO: Installing miniconda ...
>>> PREFIX=/home/xxx/.julia/v0.5/Conda/deps/usr
>>> installing: _cache-0.0-py27_x0 ...
>>> installing: python-2.7.11-0 ...
>>> installing: conda-env-2.4.5-py27_0 ...
>>> installing: openssl-1.0.2g-0 ...
>>> installing: pycosat-0.6.1-py27_0 ...
>>> installing: pyyaml-3.11-py27_1 ...
>>> installing: readline-6.2-2 ...
>>> installing: requests-2.9.1-py27_0 ...
>>> installing: sqlite-3.9.2-0 ...
>>> installing: tk-8.5.18-0 ...
>>> installing: yaml-0.1.6-0 ...
>>> installing: zlib-1.2.8-0 ...
>>> installing: conda-4.0.5-py27_0 ...
>>> installing: pycrypto-2.6.1-py27_0 ...
>>> installing: pip-8.1.1-py27_1 ...
>>> installing: wheel-0.29.0-py27_0 ...
>>> installing: setuptools-20.3-py27_0 ...
>>> Python 2.7.11 :: Continuum Analytics, Inc.
>>> creating default environment...
>>> installation finished.
>>> Fetching package metadata: 
>>> Solving package specifications: .
>>>
>>> Package plan for installation in environment
>>> /home/xxx/.julia/v0.5/Conda/deps/usr:
>>>
>>> The following packages will be downloaded:
>>>
>>> package|build
>>> ---|-
>>> conda-env-2.6.0|0  502 B
>>> expat-2.1.0|0 365 KB
>>> icu-54.1   |011.3 MB
>>> jpeg-8d|1 806 KB
>>> libffi-3.2.1   |0  36 KB
>>> libgcc-5.2.0   |0 1.1 MB
>>> libsodium-1.0.10   |0 1.2 MB
>>> libxcb-1.12|0 1.5 MB
>>> sqlite-3.13.0  |0 4.0 MB
>>> dbus-1.10.10   |0 2.4 MB
>>> glib-2.43.0|1 5.4 MB
>>> libpng-1.6.22  |0 214 KB
>>> libxml2

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[J Luis]

> This a very heavy install.  It's fetching tons of things that I have not 
> used.  Not sure what they are, but seems like trashing my system.
>

Yes, unfortunately Conda is an unbearably big dependency (over 1.xxx Gb) 
that sneaks in via un-suspicious packages. A dependency this big should 
never install without a strict user consent. Docs explain how to avoid it 
but don't find the explanation clear. I had to declare this

ENV["JUPYTER"]="C:/programs/WinPython-3.5.2.2_64/python-3.5.2.amd64/Scripts/jupyter"

to really prevent a Conda installation 
 

>
> On Wednesday, September 28, 2016 at 4:30:32 AM UTC+8, Cedric St-Jean wrote:
>>
>> Yeah, it's because of IJulia, sorry about that. I need it to support 
>> autoreloading. I could split the package in two, but it's small enough 
>> already that it doesn't feel like the right call. 
>>
>> One day we'll get conditional imports...
>>
>> On Tue, Sep 27, 2016 at 4:14 PM, Daniel Carrera  
>> wrote:
>>
>>> Thanks! You are a savior!
>>>
>>> Here is something odd: when I installed it with Pkg.clone(...) my Julia 
>>> decided that it also had to update Conda and install Jupyter. Is this some 
>>> weird quirk of my setup. I notice that you import IJulia, so I guess that 
>>> has something to do with it. It's not a big deal; I just thought it was 
>>> weird to see the package manager installing stuff like Qt, fontconfig, SSL, 
>>> and libxml just to clobber include().
>>>
>>> But other than that, it works fabulously. Thank you so much!
>>>
>>> Cheers,
>>> Daniel.
>>>
>>>
>>>
>>> On 27 September 2016 at 21:45, Cedric St-Jean  
>>> wrote:
>>>
 I wrote a work-around earlier today:

 Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")

 using ClobberingReload: sinclude # silent include
 sinclude("foo.jl")   # no redefinition warnings


 It's fresh off the press, so please file an issue if you encounter a 
 problem. It calls `include` under the hood; there's no magic involved. I 
 just intercept STDERR and remove the redefinition warnings.

 On Tuesday, September 27, 2016 at 3:13:00 PM UTC-4, Andrew wrote:
>
> It seems like a lot of people are complaining about this. Is there 
> some way to suppress method overwritten warnings for an include() 
> statement? Perhaps a keyword like include("foo.jl", quietly = true)?
>
> On Tuesday, September 27, 2016 at 1:56:27 PM UTC-4, Daniel Carrera 
> wrote:
>>
>> Hello,
>>
>> I'm not sure when I upgraded, but I am using Julia 0.5 and now it 
>> complains every time I redefine a method, which is basically all the 
>> time. 
>> When I'm developing ideas I usually have a file with a script that I 
>> modify 
>> and reload all the time:
>>
>> julia> include("foo.jl");
>>
>> ... see the results, edit file ...
>>
>> julia> include("foo.jl");
>>
>> ... see the results, edit file ...
>> julia> include("foo.jl");
>>
>> ... see the results, edit file ...
>>
>>
>> And so on. This is what I do most of the time. But now every time I 
>> `include("foo.jl")` I get warnings for every method that has been 
>> redefined 
>> (which is all of them):
>>
>> julia> include("foo.jl");
>>
>> WARNING: Method definition (::Type{Main.Line})(Float64, Float64) in 
>> module Main at /home/daniel/Data/Science/Thesis/SI.jl:4 overwritten at 
>> /home/daniel/Data/Science/Thesis/SI.jl:4.
>> WARNING: Method definition (::Type{Main.Line})(Any, Any) in module 
>> Main at /home/daniel/Data/Science/Thesis/SI.jl:4 overwritten at 
>> /home/daniel/Data/Science/Thesis/SI.jl:4.
>> WARNING: Method definition new_line(Any, Any, Any) in module Main at 
>> /home/daniel/Data/Science/Thesis/SI.jl:8 overwritten at 
>> /home/daniel/Data/Science/Thesis/SI.jl:8.
>>
>>
>> Is there a way that this can be fixed? How can I recover Julia's 
>> earlier behaviour? This is very irritating, and I don't think it makes 
>> sense for a functional language like Julia. If I wrote a method as a 
>> variable assignment (e.g. "foo = x -> 2*x") Julia wouldn't complain.
>>
>>
>> Thanks for the help,
>> Daniel.
>>
>
>>>
>>

Re: [julia-users] Re: [ANN] UnicodeFun

[henri.gir...@gmail.com]

I probably misused it but that what I get (before I add it and checkout)

Sorry

Henri


julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
ERROR: Char ² doesn't have a unicode superscript
 in to_superscript(::Char) at 
/home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:156
 in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String) 
at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
 in to_fraction at 
/home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178 [inlined]
 in 
(::UnicodeFun.##5#6{String,String})(::Base.AbstractIOBuffer{Array{UInt8,1}}) 
at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:173
 in #sprint#304(::Void, ::Function, ::Int64, ::Function) at 
./strings/io.jl:37
 in to_fraction(::String, ::String) at 
/home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:172


julia>


Le 28/09/2016 à 13:40, Simon Danisch a écrit :

I added the to_fraction function:

to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯") -->

α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
 ℝ: 𝐴𝐯 = λᵢ𝐯

https://github.com/SimonDanisch/UnicodeFun.jl/pull/3

But I won't have time to add this to the *to*_*latex* function, since 
it's a bit more involved with the line break.


Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:

Good news everyone!
I've written a small library that offers various transformations
of text to special Unicode characters.
The most prominent one is the latex-string to latex-unicode:

"\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in
\\bbR: \\itA\\bfv = \\lambda_i\\bfv"
==>  "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"


It doesn't support the whole range of latex, but I hope it will be
enough for simple formulas.
I will obviously use this library for latex label support in
GLVisualize , but I
hope that this library can also be usable in other contexts! (REPL
latex renderer?)
Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
registered, a Pkg.update() might be needed)

Please feel free to report latex strings that are not working, or
help adding new transformations! :)

Best,
Simon

Re: [julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

That's the short form which works with sub/superscript and will create
something like:
to_fraction("a-123", 392) == "ᵃ⁻¹²³⁄₃₉₂"

For the newline version try:
to_fraction_nl("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")

I really need to rework the names and documentation ;)

2016-09-28 15:22 GMT+02:00 henri.gir...@gmail.com :

> I probably misused it but that what I get (before I add it and checkout)
>
> Sorry
>
> Henri
>
>
> julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
> ERROR: Char ² doesn't have a unicode superscript
>  in to_superscript(::Char) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:156
>  in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String) at
> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
>  in to_fraction at 
> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178
> [inlined]
>  in (::UnicodeFun.##5#6{String,String})(::Base.
> AbstractIOBuffer{Array{UInt8,1}}) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:173
>  in #sprint#304(::Void, ::Function, ::Int64, ::Function) at
> ./strings/io.jl:37
>  in to_fraction(::String, ::String) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:172
>
> julia>
>
>
> Le 28/09/2016 à 13:40, Simon Danisch a écrit :
>
> I added the to_fraction function:
>
> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯") -->
>
> α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
>  ℝ: 𝐴𝐯 = λᵢ𝐯
>
> https://github.com/SimonDanisch/UnicodeFun.jl/pull/3
>
> But I won't have time to add this to the *to*_*latex* function, since
> it's a bit more involved with the line break.
>
> Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>>
>> Good news everyone!
>> I've written a small library that offers various transformations of text
>> to special Unicode characters.
>> The most prominent one is the latex-string to latex-unicode:
>>
>> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
>> \\itA\\bfv = \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"
>>
>>
>> It doesn't support the whole range of latex, but I hope it will be enough
>> for simple formulas.
>> I will obviously use this library for latex label support in GLVisualize
>> , but I hope that this
>> library can also be usable in other contexts! (REPL latex renderer?)
>> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
>> registered, a Pkg.update() might be needed)
>>
>> Please feel free to report latex strings that are not working, or help
>> adding new transformations! :)
>>
>> Best,
>> Simon
>>
>
>

Re: [julia-users] Re: [ANN] UnicodeFun

[Chris Rackauckas]

what about the other direction? It would be a sick to write symbolic code 
for SymEngine or SymPy in that unicode form, and have it convert to the 
appropriate code.

On Wednesday, September 28, 2016 at 6:43:48 AM UTC-7, Simon Danisch wrote:
>
> That's the short form which works with sub/superscript and will create 
> something like: 
> to_fraction("a-123", 392) == "ᵃ⁻¹²³⁄₃₉₂"
>
> For the newline version try:
> to_fraction_nl("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
>
> I really need to rework the names and documentation ;)
>
> 2016-09-28 15:22 GMT+02:00 henri@gmail.com  <
> henri@gmail.com >:
>
>> I probably misused it but that what I get (before I add it and checkout)
>>
>> Sorry
>>
>> Henri
>>
>>
>> julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
>> ERROR: Char ² doesn't have a unicode superscript
>>  in to_superscript(::Char) at 
>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:156
>>  in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String) at 
>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
>>  in to_fraction at 
>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178 [inlined]
>>  in 
>> (::UnicodeFun.##5#6{String,String})(::Base.AbstractIOBuffer{Array{UInt8,1}}) 
>> at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:173
>>  in #sprint#304(::Void, ::Function, ::Int64, ::Function) at 
>> ./strings/io.jl:37
>>  in to_fraction(::String, ::String) at 
>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:172
>>
>> julia> 
>>
>>
>> Le 28/09/2016 à 13:40, Simon Danisch a écrit :
>>
>> I added the to_fraction function:
>>
>> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯") -->
>>
>> α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
>>  ℝ: 𝐴𝐯 = λᵢ𝐯
>>
>> https://github.com/SimonDanisch/UnicodeFun.jl/pull/3
>>
>> But I won't have time to add this to the *to*_*latex* function, since 
>> it's a bit more involved with the line break.
>>
>> Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch: 
>>>
>>> Good news everyone!
>>> I've written a small library that offers various transformations of text 
>>> to special Unicode characters.
>>> The most prominent one is the latex-string to latex-unicode:
>>>
>>> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
>>> \\itA\\bfv = \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"
>>>
>>>
>>> It doesn't support the whole range of latex, but I hope it will be 
>>> enough for simple formulas.
>>> I will obviously use this library for latex label support in GLVisualize 
>>> , but I hope that this 
>>> library can also be usable in other contexts! (REPL latex renderer?) 
>>> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
>>> registered, a Pkg.update() might be needed)
>>>
>>> Please feel free to report latex strings that are not working, or help 
>>> adding new transformations! :)
>>>
>>> Best,
>>> Simon
>>>
>>
>>
>

[julia-users] Re: ClusterManagers timeout

[Ben Arthur]

you could custom modify your copy of ClusterManagers.jl to wait longer by 
changing the hard-coded "60" on this line:

https://github.com/JuliaParallel/ClusterManagers.jl/blob/master/src/slurm.jl#L52

[julia-users] LinearMaps and eigs() in 5.0

[Ivan Slapnicar]

The following code gives expected output in Julia 4.+, but errors in Julia 
5.0

using LinearMaps
n=10
A=rand(n,n)
function f(x::Vector)
A*x
end
B=LinearMap(f,n)
eigs(B)


ERROR: LoadError: MethodError: no method matching 
issymmetric(::LinearMaps.FunctionMap{Float64})
Closest candidates are:
  issymmetric(!Matched::BitArray{2}) at linalg/bitarray.jl:137
  issymmetric{T<:Real,S}(!Matched::Hermitian{T<:Real,S}) at 
linalg/symmetric.jl:101
  issymmetric{T<:Complex{T<:Real},S}(!Matched::Hermitian{T<:Complex,S}) at 
linalg/symmetric.jl:102
  ...
 in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
::LinearMaps.FunctionMap{Float64}, ::UniformScaling{Int64}) at 
./linalg/arnoldi.jl:163
 in _eigs(::LinearMaps.FunctionMap{Float64}, ::UniformScaling{Int64}) at 
./linalg/arnoldi.jl:158
 in #eigs#61(::Array{Any,1}, ::Function, ::LinearMaps.FunctionMap{Float64}, 
::UniformScaling{Int64}) at ./linalg/arnoldi.jl:152
 in #eigs#54(::Array{Any,1}, ::Function, ::LinearMaps.FunctionMap{Float64}) 
at ./linalg/arnoldi.jl:77
 in eigs(::LinearMaps.FunctionMap{Float64}) at ./linalg/arnoldi.jl:77
 in include_from_node1(::String) at ./loading.jl:488
 in process_options(::Base.JLOptions) at ./client.jl:262
 in _start() at ./client.jl:318

[julia-users] Southern California Julia Users Kickoff Meeting - October 7th

[Chris Rackauckas]

Hello,
  We are excited to announce a kickoff meeting for the Southern California 
Julia Users on October 7th at 6PM at UCLA (Engineering 4). There will be 
presentations by local Julia users showcasing their work. If you are 
interested in presenting, please let us know through email, Gitter, or this 
thread. We hope this will spark some interest for further events like HPC 
workshops and hackatons. For more information, see the meetup page 
.

Re: [julia-users] Re: translating julia

[Ismael Venegas Castelló]

Hi Henri!

In order to watch your content updated in the staging site, one of the 
project administrators have to push your changes to staging. I usually do 
this several times a day or at least once a day. The Transifex Live feature 
uses the WYSIWYG (What You See Is What You Get) approach, so you will see 
your changes reflected in staging (after pushing them) and it will be 
exactly the same output.

If you'd like to show and share your current language status in staging to 
other friends, you could ping me at the current julia-i18n chat room 
@Ismael-VC (https://gitter.im/JuliaLangEs/julia-i18n) and I will try to 
update the staging site ASAP and send you a notification once it's done. 
Please focus your efforts at the beginning in translating 100% the Julia 
home page, so your language translations can be added to the production 
site, don't forget to notify me when this is done, so I can push your 
translations to production ASAP.

I am wondering if one must write the html mark when translating ?
>

Yes, please check out the following images:

The first one show a "copy" button used to copy the current string in it's 
original language to the translation text box, this will copy the HTML 
portions too as is!


 
In the standard editor (not the live one!) you can select the option to 
show this extended HTML



If you do not format the string translation correctly, Transifex won't 
allow you to save the string!

Note: I have pushed to staging just now!

As always if you have any other doubt, please do not hesitate to contact me 
and I'll try to help you ASAP, thanks for your support in this project.

Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 4:54:51 (UTC-5), Henri Girard 
escribió:
>
> I am wondering if one must write the html mark when translating ?
>
> Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :
>
> Hello Henri! 
>
> Currently French is about 0% translated, we are adding to production the 
> languages that at minimum have the home page translated 90 %, but you can 
> see the current progress of all the languages in the staging site here:
>
>
>- http://julialanges.github.io
>
> You can see here a video I did tonight, were I am translating, in order to 
> give a taste of the workflow involved in doing this with Transifex Live.
>
> Please let me know if you have any doubt and I will gladly help you as 
> much as I can and thank you very much for your interest and support to this 
> project.
>
> Cheers,
> Ismael Venegas Castelló
>
> El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
> escribió: 
>>
>> I went to french translation startet to translate but can't see it on 
>> julialang.org ? 
>> it's not actualized ?
>> Regards
>>
>
>

[julia-users] Re: an error with DataFrames on Ubuntu 16.04 64bits

[kilgore trout]

K Leo:  thank you so much.  I am on a fresh 16.04.2 with Julia 0.4.5 from 
"$ sudo apt-get install julia" and had exactly your error:  your fix worked 
for me too.

On Sunday, 17 April 2016 13:15:35 UTC+1, K leo wrote:
>
> Run my julia code for the first time after setting julia up on Ubuntu 
> 16.04, I got the following errors:
>
> INFO: Precompiling module DataFrames...
> ERROR: LoadError: LoadError: error compiling anonymous: could not load 
> library "libz"
> libz: cannot open shared object file: No such file or directory
> while loading /home/xxx/.julia/v0.4/GZip/src/zlib_h.jl, in expression 
> starting on line 8
> while loading /home/xxx/.julia/v0.4/GZip/src/GZip.jl, in expression 
> starting on line 75
> ERROR: LoadError: Failed to precompile GZip to 
> /home/xxx/.julia/lib/v0.4/GZip.ji
> while loading /home/xxx/.julia/v0.4/DataFrames/src/DataFrames.jl, in 
> expression starting on line 15
> ERROR: LoadError: LoadError: LoadError: Failed to precompile DataFrames to 
> /home/xxx/.julia/lib/v0.4/DataFrames.ji
>  in compilecache at ./loading.jl:400
>
>
> After some searching, I found that I had to install lib32z1 and 
> lib32z1-dev on Ubuntu.  Not sure why these are missing with the new Ubuntu.
>

[julia-users] Controlling all Julia outputs upto four decimal points display

[parthasarathy ganguly]

I would like to set all my Julia outputs unto 4 decimals point display. How 
can I do it?

[julia-users] cfunction result garbage collected

[Christian Rorvik]

I'm not yet a 100% sure what is happening in my application, but I'm 
embedding Julia and using cfunction() to generate C-callable functions that 
at a later time invoke the registered julia code. I use a fairly standard 
pattern I think, of passing a pointer to a julia object that is retain in C 
and later passed down to the callback created by cfunction, and from there 
resolved to the original real Julia reference type, invoking a closure. The 
closure itself is retained in some global state to prevent garbage 
collection. What appears to be happening however, is the code at the 
landing site for the cfunction returned pointer is at some point garbage 
collection (or at least corrupted), as my program, after a while of 
running, will segfault upon invoking the callback (after many previously 
successful callbacks). It segfaults because it hits invalid code, and it's 
not that some state is missing when running the code.

Is this to be be expected, and what's the right way to ensure the code 
isn't GC'd?

Re: [julia-users] Re: "both DataArrays and StatsBase export "rle"; uses of it in module DataFrames must be qualified"

[Stefan Karpinski]

It's not an issue with either package: when there are two things with the
same name, you need to be explicit about which one you want to use, either
by qualify how you refer to is or by explicitly importing one of the two
things with that name.

On Wed, Sep 28, 2016 at 7:44 AM, K leo  wrote:

> Thanks for the reply.  Then this is an issue in DataFrames.
>
>
> On Wednesday, September 28, 2016 at 5:47:03 PM UTC+8, Patrick Kofod
> Mogensen wrote:
>>
>> As the error says, they both export a function called rle, so it is not
>> possible to know which one you're trying to call, if you don't qualify
>> them. Qualifying means writing "package name dot" and then the function, as
>> seen below
>>
>> module A
>> export f
>> f(x::Int64) = x
>> end
>>
>> module B
>> export f
>> f(x::Int64) = x+1
>> end
>>
>> using A, B
>>
>> f(3) # error
>> A.f(3) # returns x = 3
>> B.f(3) # returns x + 1 = 3 + 1
>>
>>
>>
>> On Sunday, September 25, 2016 at 3:15:57 PM UTC+2, K leo wrote:
>>>
>>> I get a few warning messages like this often.  Does it mean that
>>> DataFrames package need to be updated, or that I need to do something in my
>>> user code?
>>>
>>

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

Thank you... It's displaying and I noticed already some syntax errors.

Best

Henri


Le 28/09/2016 à 18:08, Ismael Venegas Castelló a écrit :

Hi Henri!

In order to watch your content updated in the staging site, one of the 
project administrators have to push your changes to staging. I usually 
do this several times a day or at least once a day. The Transifex Live 
feature uses the WYSIWYG (What You See Is What You Get) approach, so 
you will see your changes reflected in staging (after pushing them) 
and it will be exactly the same output.


If you'd like to show and share your current language status in 
staging to other friends, you could ping me at the current julia-i18n 
chat room @Ismael-VC (https://gitter.im/JuliaLangEs/julia-i18n) and I 
will try to update the staging site ASAP and send you a notification 
once it's done. Please focus your efforts at the beginning in 
translating 100% the Julia home page, so your language translations 
can be added to the production site, don't forget to notify me when 
this is done, so I can push your translations to production ASAP.


I am wondering if one must write the html mark when translating ?


Yes, please check out the following images:

The first one show a "copy" button used to copy the current string in 
it's original language to the translation text box, this will copy the 
HTML portions too as is!




In the standard editor (not the live one!) you can select the option 
to show this extended HTML





If you do not format the string translation correctly, Transifex won't 
allow you to save the string!


Note: I have pushed to staging just now!

As always if you have any other doubt, please do not hesitate to 
contact me and I'll try to help you ASAP, thanks for your support in 
this project.


Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 4:54:51 (UTC-5), Henri Girard 
escribió:


I am wondering if one must write the html mark when translating ?


Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :

Hello Henri!

Currently French is about 0% translated, we are adding to
production the languages that at minimum have the home page
translated 90 %, but you can see the current progress of all the
languages in the staging site here:

  * http://julialanges.github.io

You can see here a video I did tonight, were I am translating, in
order to give a taste of the workflow involved in doing this with
Transifex Live.

Please let me know if you have any doubt and I will gladly help
you as much as I can and thank you very much for your interest
and support to this project.

Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri
Girard escribió:

I went to french translation startet to translate but can't
see it on julialang.org  ?
it's not actualized ?
Regards

Re: [julia-users] Re: "both DataArrays and StatsBase export "rle"; uses of it in module DataFrames must be qualified"

[Milan Bouchet-Valat]

Le mercredi 28 septembre 2016 à 04:44 -0700, K leo a écrit :
> Thanks for the reply.  Then this is an issue in DataFrames.
Yes, but one that is already fixed in master by removing the dependency
on DataArrays.


Regards

> > As the error says, they both export a function called rle, so it is
> > not possible to know which one you're trying to call, if you don't
> > qualify them. Qualifying means writing "package name dot" and then
> > the function, as seen below
> > 
> > module A
> > export f
> > f(x::Int64) = x
> > end
> > 
> > module B
> > export f
> > f(x::Int64) = x+1
> > end
> > 
> > using A, B
> > 
> > f(3) # error
> > A.f(3) # returns x = 3
> > B.f(3) # returns x + 1 = 3 + 1
> > 
> > 
> > 
> > > I get a few warning messages like this often.  Does it mean that
> > > DataFrames package need to be updated, or that I need to do
> > > something in my user code?
> > > 
> > 

Re: [julia-users] Controlling all Julia outputs upto four decimal points display

[Bart Janssens]

I have no idea if it's still the correct way, but I add this at the top of
most notebooks:

Base.show(io::IO, x::Float64) = @printf io "%0.4f" x;



On Wed, Sep 28, 2016 at 6:22 PM parthasarathy ganguly <
parthasarathygang...@gmail.com> wrote:

> I would like to set all my Julia outputs unto 4 decimals point display.
> How can I do it?
>

Re: [julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

Sounds fun! Since I won't use this, this would need to wait until the next
procrastination attack.
But feel free to submit a PR. Should be relatively straight forward :)

2016-09-28 17:30 GMT+02:00 Chris Rackauckas :

> what about the other direction? It would be a sick to write symbolic code
> for SymEngine or SymPy in that unicode form, and have it convert to the
> appropriate code.
>
> On Wednesday, September 28, 2016 at 6:43:48 AM UTC-7, Simon Danisch wrote:
>>
>> That's the short form which works with sub/superscript and will create
>> something like:
>> to_fraction("a-123", 392) == "ᵃ⁻¹²³⁄₃₉₂"
>>
>> For the newline version try:
>> to_fraction_nl("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
>>
>> I really need to rework the names and documentation ;)
>>
>> 2016-09-28 15:22 GMT+02:00 henri@gmail.com :
>>
>>> I probably misused it but that what I get (before I add it and checkout)
>>>
>>> Sorry
>>>
>>> Henri
>>>
>>>
>>> julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯")
>>> ERROR: Char ² doesn't have a unicode superscript
>>>  in to_superscript(::Char) at /home/pi/.julia/v0.5/UnicodeFu
>>> n/src/sub_super_scripts.jl:156
>>>  in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String)
>>> at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
>>>  in to_fraction at 
>>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178
>>> [inlined]
>>>  in 
>>> (::UnicodeFun.##5#6{String,String})(::Base.AbstractIOBuffer{Array{UInt8,1}})
>>> at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:173
>>>  in #sprint#304(::Void, ::Function, ::Int64, ::Function) at
>>> ./strings/io.jl:37
>>>  in to_fraction(::String, ::String) at /home/pi/.julia/v0.5/UnicodeFu
>>> n/src/sub_super_scripts.jl:172
>>>
>>> julia>
>>>
>>>
>>> Le 28/09/2016 à 13:40, Simon Danisch a écrit :
>>>
>>> I added the to_fraction function:
>>>
>>> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 𝐴𝐯 = λᵢ𝐯") -->
>>>
>>> α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
>>>  ℝ: 𝐴𝐯 = λᵢ𝐯
>>>
>>> https://github.com/SimonDanisch/UnicodeFun.jl/pull/3
>>>
>>> But I won't have time to add this to the *to*_*latex* function, since
>>> it's a bit more involved with the line break.
>>>
>>> Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:

 Good news everyone!
 I've written a small library that offers various transformations of
 text to special Unicode characters.
 The most prominent one is the latex-string to latex-unicode:

 "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
 \\itA\\bfv = \\lambda_i\\bfv"==> "𝐴 ∈ ℝⁿˣⁿ, 𝐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 𝐴𝐯 = λᵢ𝐯"


 It doesn't support the whole range of latex, but I hope it will be
 enough for simple formulas.
 I will obviously use this library for latex label support in
 GLVisualize , but I hope
 that this library can also be usable in other contexts! (REPL latex
 renderer?)
 Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
 registered, a Pkg.update() might be needed)

 Please feel free to report latex strings that are not working, or help
 adding new transformations! :)

 Best,
 Simon

>>>
>>>
>>

[julia-users] Re: cfunction result garbage collected

[Christian Rorvik]

GC of code turned out to be a red herring. After isolating the instance of 
a call that was crashing, and getting right up to it, GDB was kind enough 
to get its knickers in a twist and segfault itself every time I stepped 
instruction by instruction to find the precise point of failure (backtrace 
after segfault looked pretty meaningless).

What it tunred out to be a was a Ref vs Ptr problem, where in Julia I have 
a callback wrapper that receives a pointer to the closure. I was taking 
this as Ref{T} and invoking it with a pointer from the C code. This worked 
all fine and dandy, but somehow caused the object to be collected (I'm 
guessing). I can see how what I did was wrong, but I can't see how it would 
lead to something being collected when there still exists roots pointing to 
it. If anything I would possibly expect a leak. Nonetheless, bit of a wild 
goose chase.


On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik 
wrote:
>
> I'm not yet a 100% sure what is happening in my application, but I'm 
> embedding Julia and using cfunction() to generate C-callable functions that 
> at a later time invoke the registered julia code. I use a fairly standard 
> pattern I think, of passing a pointer to a julia object that is retain in C 
> and later passed down to the callback created by cfunction, and from there 
> resolved to the original real Julia reference type, invoking a closure. The 
> closure itself is retained in some global state to prevent garbage 
> collection. What appears to be happening however, is the code at the 
> landing site for the cfunction returned pointer is at some point garbage 
> collection (or at least corrupted), as my program, after a while of 
> running, will segfault upon invoking the callback (after many previously 
> successful callbacks). It segfaults because it hits invalid code, and it's 
> not that some state is missing when running the code.
>
> Is this to be be expected, and what's the right way to ensure the code 
> isn't GC'd?
>

Re: [julia-users] Re: cfunction result garbage collected

[Yichao Yu]

On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik
 wrote:
> GC of code turned out to be a red herring. After isolating the instance of a
> call that was crashing, and getting right up to it, GDB was kind enough to
> get its knickers in a twist and segfault itself every time I stepped
> instruction by instruction to find the precise point of failure (backtrace
> after segfault looked pretty meaningless).
>
> What it tunred out to be a was a Ref vs Ptr problem, where in Julia I have a
> callback wrapper that receives a pointer to the closure. I was taking this
> as Ref{T} and invoking it with a pointer from the C code. This worked all
> fine and dandy, but somehow caused the object to be collected (I'm
> guessing). I can see how what I did was wrong, but I can't see how it would
> lead to something being collected when there still exists roots pointing to
> it. If anything I would possibly expect a leak. Nonetheless, bit of a wild
> goose chase.

It's unclear what exactly you mean but just to be clear `cfunction(f,
Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that is
rooted somewhere during the execution of the julia callback function.
It is illegal to pass it a bare C `intptr_t*` (that doesn't point to
julia memory of a boxed Int) and it is illegal to generates it with
`ccall(..., (Ptr{Int},), &i)`.

>
>
> On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik
> wrote:
>>
>> I'm not yet a 100% sure what is happening in my application, but I'm
>> embedding Julia and using cfunction() to generate C-callable functions that
>> at a later time invoke the registered julia code. I use a fairly standard
>> pattern I think, of passing a pointer to a julia object that is retain in C
>> and later passed down to the callback created by cfunction, and from there
>> resolved to the original real Julia reference type, invoking a closure. The
>> closure itself is retained in some global state to prevent garbage
>> collection. What appears to be happening however, is the code at the landing
>> site for the cfunction returned pointer is at some point garbage collection
>> (or at least corrupted), as my program, after a while of running, will
>> segfault upon invoking the callback (after many previously successful
>> callbacks). It segfaults because it hits invalid code, and it's not that
>> some state is missing when running the code.
>>
>> Is this to be be expected, and what's the right way to ensure the code
>> isn't GC'd?

[julia-users] Re: cfunction result garbage collected

[Cristóvão Duarte Sousa]

I can't help you at all, but I would like to ask if you pass 
the cfunction() result to the C side.
I've been playing with embedding Julia and discovered I could call 
a cfunction() directly  from C, although I'm not sure that's a good 
practice.

https://github.com/cdsousa/embedding_julia/blob/master/embedding.cpp#L40

On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik 
wrote:
>
> I'm not yet a 100% sure what is happening in my application, but I'm 
> embedding Julia and using cfunction() to generate C-callable functions that 
> at a later time invoke the registered julia code. I use a fairly standard 
> pattern I think, of passing a pointer to a julia object that is retain in C 
> and later passed down to the callback created by cfunction, and from there 
> resolved to the original real Julia reference type, invoking a closure. The 
> closure itself is retained in some global state to prevent garbage 
> collection. What appears to be happening however, is the code at the 
> landing site for the cfunction returned pointer is at some point garbage 
> collection (or at least corrupted), as my program, after a while of 
> running, will segfault upon invoking the callback (after many previously 
> successful callbacks). It segfaults because it hits invalid code, and it's 
> not that some state is missing when running the code.
>
> Is this to be be expected, and what's the right way to ensure the code 
> isn't GC'd?
>

Re: [julia-users] Re: cfunction result garbage collected

[Christian Rorvik]

I don't have the code at hand right now (it's at work), but what I was 
doing was something like

type Wrapper{Arg}
cfun::Ptr{Void}
cobj::Ptr{Void}
obj

function Wrapper{T}(f::T)
return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)), 
pointer_from_objref(f), f)
end
end

Where call_wrapper would invoke the closure. I had to change call_wrapper 
to receive the closure as Ptr{T} and call unsafe_pointer_to_objref and then 
call it.


On Wednesday, September 28, 2016 at 9:50:47 PM UTC+1, Yichao Yu wrote:
>
> On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik 
> > wrote: 
> > GC of code turned out to be a red herring. After isolating the instance 
> of a 
> > call that was crashing, and getting right up to it, GDB was kind enough 
> to 
> > get its knickers in a twist and segfault itself every time I stepped 
> > instruction by instruction to find the precise point of failure 
> (backtrace 
> > after segfault looked pretty meaningless). 
> > 
> > What it tunred out to be a was a Ref vs Ptr problem, where in Julia I 
> have a 
> > callback wrapper that receives a pointer to the closure. I was taking 
> this 
> > as Ref{T} and invoking it with a pointer from the C code. This worked 
> all 
> > fine and dandy, but somehow caused the object to be collected (I'm 
> > guessing). I can see how what I did was wrong, but I can't see how it 
> would 
> > lead to something being collected when there still exists roots pointing 
> to 
> > it. If anything I would possibly expect a leak. Nonetheless, bit of a 
> wild 
> > goose chase. 
>
> It's unclear what exactly you mean but just to be clear `cfunction(f, 
> Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that is 
> rooted somewhere during the execution of the julia callback function. 
> It is illegal to pass it a bare C `intptr_t*` (that doesn't point to 
> julia memory of a boxed Int) and it is illegal to generates it with 
> `ccall(..., (Ptr{Int},), &i)`. 
>
> > 
> > 
> > On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik 
> > wrote: 
> >> 
> >> I'm not yet a 100% sure what is happening in my application, but I'm 
> >> embedding Julia and using cfunction() to generate C-callable functions 
> that 
> >> at a later time invoke the registered julia code. I use a fairly 
> standard 
> >> pattern I think, of passing a pointer to a julia object that is retain 
> in C 
> >> and later passed down to the callback created by cfunction, and from 
> there 
> >> resolved to the original real Julia reference type, invoking a closure. 
> The 
> >> closure itself is retained in some global state to prevent garbage 
> >> collection. What appears to be happening however, is the code at the 
> landing 
> >> site for the cfunction returned pointer is at some point garbage 
> collection 
> >> (or at least corrupted), as my program, after a while of running, will 
> >> segfault upon invoking the callback (after many previously successful 
> >> callbacks). It segfaults because it hits invalid code, and it's not 
> that 
> >> some state is missing when running the code. 
> >> 
> >> Is this to be be expected, and what's the right way to ensure the code 
> >> isn't GC'd? 
>

[julia-users] Re: cfunction result garbage collected

[Christian Rorvik]

Yeah that's what I do. I think that's kind of the point of it, although I 
think most people use it perhaps as in-scope callbacks, whereas I persist 
the callbacks and invoke them later, so additionally I have to retain the 
wrapped closures to prevent them being collected.

On Wednesday, September 28, 2016 at 9:58:13 PM UTC+1, Cristóvão Duarte 
Sousa wrote:
>
> I can't help you at all, but I would like to ask if you pass 
> the cfunction() result to the C side.
> I've been playing with embedding Julia and discovered I could call 
> a cfunction() directly  from C, although I'm not sure that's a good 
> practice.
>
> https://github.com/cdsousa/embedding_julia/blob/master/embedding.cpp#L40
>
> On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik 
> wrote:
>>
>> I'm not yet a 100% sure what is happening in my application, but I'm 
>> embedding Julia and using cfunction() to generate C-callable functions that 
>> at a later time invoke the registered julia code. I use a fairly standard 
>> pattern I think, of passing a pointer to a julia object that is retain in C 
>> and later passed down to the callback created by cfunction, and from there 
>> resolved to the original real Julia reference type, invoking a closure. The 
>> closure itself is retained in some global state to prevent garbage 
>> collection. What appears to be happening however, is the code at the 
>> landing site for the cfunction returned pointer is at some point garbage 
>> collection (or at least corrupted), as my program, after a while of 
>> running, will segfault upon invoking the callback (after many previously 
>> successful callbacks). It segfaults because it hits invalid code, and it's 
>> not that some state is missing when running the code.
>>
>> Is this to be be expected, and what's the right way to ensure the code 
>> isn't GC'd?
>>
>

Re: [julia-users] Re: cfunction result garbage collected

[Yichao Yu]

On Wed, Sep 28, 2016 at 5:00 PM, Christian Rorvik
 wrote:
> I don't have the code at hand right now (it's at work), but what I was doing
> was something like
>
> type Wrapper{Arg}
> cfun::Ptr{Void}
> cobj::Ptr{Void}
> obj
>
> function Wrapper{T}(f::T)
> return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)),
> pointer_from_objref(f), f)
> end
> end

This is wrong, You shouldn't ever call `pointer_from_objref` for
unknown object. The right way to handl this is

type Wrapper{Arg}
cfun::Ptr{Void}
cobj::Ptr{Void}
obj
function Wrapper{T}(f::T)
to_root = Base.cconvert(Ref{T}, f)
ptr = Base.unsafe_convert(Ref{T}, to_root)
return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)),
Ptr{Void}(ptr), to_root)
end
end


>
> Where call_wrapper would invoke the closure. I had to change call_wrapper to
> receive the closure as Ptr{T} and call unsafe_pointer_to_objref and then
> call it.
>
>
> On Wednesday, September 28, 2016 at 9:50:47 PM UTC+1, Yichao Yu wrote:
>>
>> On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik
>>  wrote:
>> > GC of code turned out to be a red herring. After isolating the instance
>> > of a
>> > call that was crashing, and getting right up to it, GDB was kind enough
>> > to
>> > get its knickers in a twist and segfault itself every time I stepped
>> > instruction by instruction to find the precise point of failure
>> > (backtrace
>> > after segfault looked pretty meaningless).
>> >
>> > What it tunred out to be a was a Ref vs Ptr problem, where in Julia I
>> > have a
>> > callback wrapper that receives a pointer to the closure. I was taking
>> > this
>> > as Ref{T} and invoking it with a pointer from the C code. This worked
>> > all
>> > fine and dandy, but somehow caused the object to be collected (I'm
>> > guessing). I can see how what I did was wrong, but I can't see how it
>> > would
>> > lead to something being collected when there still exists roots pointing
>> > to
>> > it. If anything I would possibly expect a leak. Nonetheless, bit of a
>> > wild
>> > goose chase.
>>
>> It's unclear what exactly you mean but just to be clear `cfunction(f,
>> Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that is
>> rooted somewhere during the execution of the julia callback function.
>> It is illegal to pass it a bare C `intptr_t*` (that doesn't point to
>> julia memory of a boxed Int) and it is illegal to generates it with
>> `ccall(..., (Ptr{Int},), &i)`.
>>
>> >
>> >
>> > On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian Rorvik
>> > wrote:
>> >>
>> >> I'm not yet a 100% sure what is happening in my application, but I'm
>> >> embedding Julia and using cfunction() to generate C-callable functions
>> >> that
>> >> at a later time invoke the registered julia code. I use a fairly
>> >> standard
>> >> pattern I think, of passing a pointer to a julia object that is retain
>> >> in C
>> >> and later passed down to the callback created by cfunction, and from
>> >> there
>> >> resolved to the original real Julia reference type, invoking a closure.
>> >> The
>> >> closure itself is retained in some global state to prevent garbage
>> >> collection. What appears to be happening however, is the code at the
>> >> landing
>> >> site for the cfunction returned pointer is at some point garbage
>> >> collection
>> >> (or at least corrupted), as my program, after a while of running, will
>> >> segfault upon invoking the callback (after many previously successful
>> >> callbacks). It segfaults because it hits invalid code, and it's not
>> >> that
>> >> some state is missing when running the code.
>> >>
>> >> Is this to be be expected, and what's the right way to ensure the code
>> >> isn't GC'd?

Re: [julia-users] Re: cfunction result garbage collected

[Christian Rorvik]

Thanks! I'll try this tomorrow. So similar to what you've done here? 
https://github.com/yuyichao/FunctionWrappers.jl/blob/master/src/FunctionWrappers.jl#L40

I can't remember if I actually called that explicitly, but I believe what I 
ended up with was similar to 
here: http://julialang.org/blog/2013/05/callback, where they use 
unsafe_pointer_to_objref to recover the function object.

On Wednesday, September 28, 2016 at 10:06:51 PM UTC+1, Yichao Yu wrote:
>
> On Wed, Sep 28, 2016 at 5:00 PM, Christian Rorvik 
> > wrote: 
> > I don't have the code at hand right now (it's at work), but what I was 
> doing 
> > was something like 
> > 
> > type Wrapper{Arg} 
> > cfun::Ptr{Void} 
> > cobj::Ptr{Void} 
> > obj 
> > 
> > function Wrapper{T}(f::T) 
> > return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)), 
> > pointer_from_objref(f), f) 
> > end 
> > end 
>
> This is wrong, You shouldn't ever call `pointer_from_objref` for 
> unknown object. The right way to handl this is 
>
> type Wrapper{Arg} 
> cfun::Ptr{Void} 
> cobj::Ptr{Void} 
> obj 
> function Wrapper{T}(f::T) 
> to_root = Base.cconvert(Ref{T}, f) 
> ptr = Base.unsafe_convert(Ref{T}, to_root) 
> return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)), 
> Ptr{Void}(ptr), to_root) 
> end 
> end 
>
>
> > 
> > Where call_wrapper would invoke the closure. I had to change 
> call_wrapper to 
> > receive the closure as Ptr{T} and call unsafe_pointer_to_objref and then 
> > call it. 
> > 
> > 
> > On Wednesday, September 28, 2016 at 9:50:47 PM UTC+1, Yichao Yu wrote: 
> >> 
> >> On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik 
> >>  wrote: 
> >> > GC of code turned out to be a red herring. After isolating the 
> instance 
> >> > of a 
> >> > call that was crashing, and getting right up to it, GDB was kind 
> enough 
> >> > to 
> >> > get its knickers in a twist and segfault itself every time I stepped 
> >> > instruction by instruction to find the precise point of failure 
> >> > (backtrace 
> >> > after segfault looked pretty meaningless). 
> >> > 
> >> > What it tunred out to be a was a Ref vs Ptr problem, where in Julia I 
> >> > have a 
> >> > callback wrapper that receives a pointer to the closure. I was taking 
> >> > this 
> >> > as Ref{T} and invoking it with a pointer from the C code. This worked 
> >> > all 
> >> > fine and dandy, but somehow caused the object to be collected (I'm 
> >> > guessing). I can see how what I did was wrong, but I can't see how it 
> >> > would 
> >> > lead to something being collected when there still exists roots 
> pointing 
> >> > to 
> >> > it. If anything I would possibly expect a leak. Nonetheless, bit of a 
> >> > wild 
> >> > goose chase. 
> >> 
> >> It's unclear what exactly you mean but just to be clear `cfunction(f, 
> >> Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that is 
> >> rooted somewhere during the execution of the julia callback function. 
> >> It is illegal to pass it a bare C `intptr_t*` (that doesn't point to 
> >> julia memory of a boxed Int) and it is illegal to generates it with 
> >> `ccall(..., (Ptr{Int},), &i)`. 
> >> 
> >> > 
> >> > 
> >> > On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian 
> Rorvik 
> >> > wrote: 
> >> >> 
> >> >> I'm not yet a 100% sure what is happening in my application, but I'm 
> >> >> embedding Julia and using cfunction() to generate C-callable 
> functions 
> >> >> that 
> >> >> at a later time invoke the registered julia code. I use a fairly 
> >> >> standard 
> >> >> pattern I think, of passing a pointer to a julia object that is 
> retain 
> >> >> in C 
> >> >> and later passed down to the callback created by cfunction, and from 
> >> >> there 
> >> >> resolved to the original real Julia reference type, invoking a 
> closure. 
> >> >> The 
> >> >> closure itself is retained in some global state to prevent garbage 
> >> >> collection. What appears to be happening however, is the code at the 
> >> >> landing 
> >> >> site for the cfunction returned pointer is at some point garbage 
> >> >> collection 
> >> >> (or at least corrupted), as my program, after a while of running, 
> will 
> >> >> segfault upon invoking the callback (after many previously 
> successful 
> >> >> callbacks). It segfaults because it hits invalid code, and it's not 
> >> >> that 
> >> >> some state is missing when running the code. 
> >> >> 
> >> >> Is this to be be expected, and what's the right way to ensure the 
> code 
> >> >> isn't GC'd? 
>

Re: [julia-users] Re: cfunction result garbage collected

[Yichao Yu]

On Wed, Sep 28, 2016 at 5:16 PM, Christian Rorvik
 wrote:
> Thanks! I'll try this tomorrow. So similar to what you've done here?
> https://github.com/yuyichao/FunctionWrappers.jl/blob/master/src/FunctionWrappers.jl#L40

Correct. Also https://github.com/JuliaPy/PyCall.jl/pull/267

>
> I can't remember if I actually called that explicitly, but I believe what I
> ended up with was similar to here:
> http://julialang.org/blog/2013/05/callback, where they use
> unsafe_pointer_to_objref to recover the function object.

unsafe_pointer_to_objref is ok. It's unsafe in the sense that you
almost guarantee a segfault if it is not used correctly.
pointer_from_objref is less unsafe in that you might not get a
segfault if the GC is nice to you today.

Ref https://github.com/JuliaLang/julia/issues/15857 for why
pointer_from_objref is bad if you call it on arbitrary object (mostly
immutables). Essentially the compiler is free to give you garbage if
you call it on immutables or the pointer you get back might not be the
pointer that you stored somewhere else since the pointer value is
supposed to be insignificant, only the content is, for immutables.

>
> On Wednesday, September 28, 2016 at 10:06:51 PM UTC+1, Yichao Yu wrote:
>>
>> On Wed, Sep 28, 2016 at 5:00 PM, Christian Rorvik
>>  wrote:
>> > I don't have the code at hand right now (it's at work), but what I was
>> > doing
>> > was something like
>> >
>> > type Wrapper{Arg}
>> > cfun::Ptr{Void}
>> > cobj::Ptr{Void}
>> > obj
>> >
>> > function Wrapper{T}(f::T)
>> > return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)),
>> > pointer_from_objref(f), f)
>> > end
>> > end
>>
>> This is wrong, You shouldn't ever call `pointer_from_objref` for
>> unknown object. The right way to handl this is
>>
>> type Wrapper{Arg}
>> cfun::Ptr{Void}
>> cobj::Ptr{Void}
>> obj
>> function Wrapper{T}(f::T)
>> to_root = Base.cconvert(Ref{T}, f)
>> ptr = Base.unsafe_convert(Ref{T}, to_root)
>> return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)),
>> Ptr{Void}(ptr), to_root)
>> end
>> end
>>
>>
>> >
>> > Where call_wrapper would invoke the closure. I had to change
>> > call_wrapper to
>> > receive the closure as Ptr{T} and call unsafe_pointer_to_objref and then
>> > call it.
>> >
>> >
>> > On Wednesday, September 28, 2016 at 9:50:47 PM UTC+1, Yichao Yu wrote:
>> >>
>> >> On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik
>> >>  wrote:
>> >> > GC of code turned out to be a red herring. After isolating the
>> >> > instance
>> >> > of a
>> >> > call that was crashing, and getting right up to it, GDB was kind
>> >> > enough
>> >> > to
>> >> > get its knickers in a twist and segfault itself every time I stepped
>> >> > instruction by instruction to find the precise point of failure
>> >> > (backtrace
>> >> > after segfault looked pretty meaningless).
>> >> >
>> >> > What it tunred out to be a was a Ref vs Ptr problem, where in Julia I
>> >> > have a
>> >> > callback wrapper that receives a pointer to the closure. I was taking
>> >> > this
>> >> > as Ref{T} and invoking it with a pointer from the C code. This worked
>> >> > all
>> >> > fine and dandy, but somehow caused the object to be collected (I'm
>> >> > guessing). I can see how what I did was wrong, but I can't see how it
>> >> > would
>> >> > lead to something being collected when there still exists roots
>> >> > pointing
>> >> > to
>> >> > it. If anything I would possibly expect a leak. Nonetheless, bit of a
>> >> > wild
>> >> > goose chase.
>> >>
>> >> It's unclear what exactly you mean but just to be clear `cfunction(f,
>> >> Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that is
>> >> rooted somewhere during the execution of the julia callback function.
>> >> It is illegal to pass it a bare C `intptr_t*` (that doesn't point to
>> >> julia memory of a boxed Int) and it is illegal to generates it with
>> >> `ccall(..., (Ptr{Int},), &i)`.
>> >>
>> >> >
>> >> >
>> >> > On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian
>> >> > Rorvik
>> >> > wrote:
>> >> >>
>> >> >> I'm not yet a 100% sure what is happening in my application, but I'm
>> >> >> embedding Julia and using cfunction() to generate C-callable
>> >> >> functions
>> >> >> that
>> >> >> at a later time invoke the registered julia code. I use a fairly
>> >> >> standard
>> >> >> pattern I think, of passing a pointer to a julia object that is
>> >> >> retain
>> >> >> in C
>> >> >> and later passed down to the callback created by cfunction, and from
>> >> >> there
>> >> >> resolved to the original real Julia reference type, invoking a
>> >> >> closure.
>> >> >> The
>> >> >> closure itself is retained in some global state to prevent garbage
>> >> >> collection. What appears to be happening however, is the code at the
>> >> >> landing
>> >> >> site for the cfunction returned pointer is at some point garbage
>> >> >> collection
>> >> >> (or at least corrupted), as my program, after a while of r

[julia-users] Any 0.5 performance tips?

[Andrew]

My large project is much (3-4x?) slower under 0.5. I know there are a 
variety of open issues about this to be hopefully fixed in the 0.5.x 
timeframe, but are there any general workarounds at the moment?

My project includes the following in case it's relevant:

   - Many nested functions forming closures, which I pass to optimization 
   and equation solving functions. In 0.4 I used the Base.call trick on custom 
   types to make performant closures. I rewrote the code for 0.5 to just use 
   regular anonymous functions since they are fast now.
   - ForwardDiff, splines (Dierckx mostly)
   - Large custom immutable types which carry parameters. These get passed 
   around. I have been considering just making all my parameters global 
   constants rather than passing them around. It seems that this could get 
   them inlined into my functions and save time. However, all my simple tests 
   show global constants perform exactly the same as explicitly passing the 
   parameters, so as long as this still holds in big codes this shouldn't 
   matter.
   - A lot of nested function calls. I prefer to write lots of small 
   functions instead of one big one

[julia-users] Re: Any 0.5 performance tips?

[K leo]

Just discovered a few days ago that keyword arguments in functions are very 
slow, but I guess they are not slower in 0.5.

On Thursday, September 29, 2016 at 10:15:20 AM UTC+8, Andrew wrote:
>
> My large project is much (3-4x?) slower under 0.5. I know there are a 
> variety of open issues about this to be hopefully fixed in the 0.5.x 
> timeframe, but are there any general workarounds at the moment?
>
> My project includes the following in case it's relevant:
>
>- Many nested functions forming closures, which I pass to optimization 
>and equation solving functions. In 0.4 I used the Base.call trick on 
> custom 
>types to make performant closures. I rewrote the code for 0.5 to just use 
>regular anonymous functions since they are fast now.
>- ForwardDiff, splines (Dierckx mostly)
>- Large custom immutable types which carry parameters. These get 
>passed around. I have been considering just making all my parameters 
> global 
>constants rather than passing them around. It seems that this could get 
>them inlined into my functions and save time. However, all my simple tests 
>show global constants perform exactly the same as explicitly passing the 
>parameters, so as long as this still holds in big codes this shouldn't 
>matter.
>- A lot of nested function calls. I prefer to write lots of small 
>functions instead of one big one
>
>

[julia-users] Any 0.5 performance tips?

[Kristoffer Carlsson]

Look for Core.Box in @code_warntype. See 
https://github.com/JuliaLang/julia/issues/15276