Re: [julia-users] Using ImageView leads to libgobject error

[Colin Beckingham]

Thanks. Tk is loaded, not Gtk.
Resolved the error in Winston with a Pkg.checkout and build.
I did a Pkg.status("Tk") and this responds without error, version Tk 0.3.7
Also did status on Winston, ImageView, Images, Cairo and all respond 
without error.
But still the error, and view() is not available.

On Saturday, 9 April 2016 20:34:46 UTC-4, Tim Holy wrote:
>
> Try "using Winston" and then whos(); see if Gtk is loaded (or if it's Tk). 
>
> --Tim 
>
> On Saturday, April 09, 2016 11:34:43 AM Colin Beckingham wrote: 
> > I tried Pkg.rm("PyPlot") which put PyPlot in the additional packages 
> group, 
> > but the error persists. If there is something else I should do, by all 
> > means give a hint. 
> > 
> > I thought I found an older note which referred to ImageView and Gtk, 
> which 
> > is why I mentioned it. 
> > 
> > Running through the require list for ImageView I have no problems using 
> any 
> > of them except Winston, which produces 
> > "ERROR: LoadError: syntax: space before "(" not allowed in 
> > "AbstractVecOrMat{T} ("" 
> > I mention it in case it might be tangentially relevant. 
> > 
> > On Saturday, 9 April 2016 13:51:17 UTC-4, Tim Holy wrote: 
> > > Not sure what's happening. Is it possible there's a conflict with 
> PyPlot? 
> > > 
> > > When I grep the source of ImageView, I don't find any mention of gtk. 
> > > 
> > > --Tim 
> > > 
> > > On Saturday, April 09, 2016 10:06:52 AM Colin Beckingham wrote: 
> > > > Pkg.status() 
> > > > 
> > > > 31 required packages: 
> > > >  - BinDeps   0.3.21+master 
> > > >  - Cairo 0.2.31 
> > > >  - Clustering0.5.0 
> > > >  - ColorTypes0.2.2 
> > > >  - DSP   0.0.11 
> > > >  - DataArrays0.2.20 
> > > >  - DataFrames0.7.0+ master 
> > > >  - Debug 0.1.6 
> > > >  - DecisionTree  0.3.12 
> > > >  - DimensionalityReduction   0.1.1 
> > > >  - Distances 0.3.0 
> > > >  - Docile0.5.23 
> > > >  - FunctionalDataUtils   0.1.0 
> > > >  - GLM   0.5.0 
> > > >  - GZip  0.2.18 
> > > >  - HttpParser0.1.1 
> > > >  - ImageMagick   0.1.3 
> > > >  - ImageView 0.1.19+master 
> > > >  - Images0.5.3 
> > > >  - IniFile   0.2.5 
> > > >  - JLD   0.5.9 
> > > >  - JSON  0.5.0 
> > > >  - LightXML  0.2.1 
> > > >  - MLBase0.5.2 
> > > >  - PkgDev0.1.0 
> > > >  - PyPlot2.1.1+ master 
> > > >  - RDatasets 0.1.2+ master 
> > > >  - StatsBase 0.8.0 
> > > >  - Tk0.3.7 
> > > >  - WAV   0.6.3 
> > > >  - Winston   0.11.13 
> > > > 
> > > > 29 additional packages: 
> > > >  - ArrayViews0.6.4 
> > > >  - Blosc 0.1.4 
> > > >  - ColorVectorSpace  0.1.2 
> > > >  - Colors0.6.3 
> > > >  - Compat0.7.13 
> > > >  - Conda 0.1.9 
> > > >  - Dates 0.4.4 
> > > >  - Distributions 0.8.10 
> > > >  - FactCheck 0.4.2 
> > > >  - FileIO0.0.4 
> > > >  - FixedPointNumbers 0.1.2  master 
> > > >  - FunctionalData0.1.0 
> > > >  - Graphics  0.1.3 
> > > >  - HDF5  0.5.8 
> > > >  - HttpCommon0.2.4 
> > > >  - Iterators 0.1.9 
> > > >  - LaTeXStrings  0.1.6 
> > > >  - MultivariateStats 0.2.2 
> > > >  - PDMats0.4.1 
> > > >  - Polynomials   0.0.5 
> > > >  - PyCall1.4.0 
> > > >  - Reexport  0.0.3 
> > > >  - SHA   0.1.2 
> > > >  - SIUnits   0.0.6 
> > > >  - SortingAlgorithms 0.0.6 
> > > >  - StatsFuns 0.2.0 
> > > >  - TexExtensions 0.0.3 
> > > >  - URIParser 0.1.3+ master 
> > > >  - Zlib  0.1.12 
> > > > 
> > > > On Saturday, 9 April 2016 12:48:49 UTC-4, Tim Holy wrote: 
> > > > > I can't replicate this, whether with the tagged version of 
> ImageView 
> > > > > (Pkg.free("ImageView")) nor with master. What does Pkg.status() 
> say? 
> > > > > 
> > > > > --Tim 
> > > > > 
> > > > > On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote: 
> > > > > > Using openSUSE Leap 42.1 
> > > > > > I can add the p

Re: [julia-users] Access to gmp from library?

[Tony Kelman]

You called? Also note that libgmp.dll will be in JULIA_HOME on Windows.

[julia-users] Re: Deprecation of `require` and parallel code execution.

[Eduardo Lenz]

Hi.

Yes, exactly the same with pmap()

Silly example:

addprocs(3)

@everywhere Test(i)
 println(myid())
end

i=1:1000;
pmap(Test,i)

if you do not use @everywhere, it will not work.



On Saturday, April 9, 2016 at 5:14:05 PM UTC-3, Jhan Jar wrote:
>
> Would it also work for pmap()? I don't have any @parallel loops.
>
> On Sunday, April 10, 2016 at 12:39:25 AM UTC+5, Eduardo Lenz wrote:
>>
>> Hi.
>>
>> Use include("file.jl")  and add @everywhere in front of the definition of 
>> every function to be used inside the @parallel loop.
>>
>> []´s
>>
>> On Saturday, April 9, 2016 at 12:02:02 PM UTC-3, Jhan Jar wrote:
>>>
>>> Hi, 
>>>
>>> In Julia 0.3.5, the following loaded the data and code/functions on all 
>>> workers:
>>>
>>> addprocs(3)
>>> require("data_loading_script.jl")
>>> require("functions.jl")
>>>
>>> Now, Julia 0.4.5 warns about deprecation of require and suggests 
>>> switching to 'using' or 'import'.
>>>
>>> What is the equivalent in Julia 0.4.5 for the above three lines that 
>>> worked fine in Julia 0.3.x?
>>>
>>>

Re: [julia-users] Using ImageView leads to libgobject error

[Tim Holy]

Try "using Winston" and then whos(); see if Gtk is loaded (or if it's Tk).

--Tim

On Saturday, April 09, 2016 11:34:43 AM Colin Beckingham wrote:
> I tried Pkg.rm("PyPlot") which put PyPlot in the additional packages group,
> but the error persists. If there is something else I should do, by all
> means give a hint.
> 
> I thought I found an older note which referred to ImageView and Gtk, which
> is why I mentioned it.
> 
> Running through the require list for ImageView I have no problems using any
> of them except Winston, which produces
> "ERROR: LoadError: syntax: space before "(" not allowed in
> "AbstractVecOrMat{T} (""
> I mention it in case it might be tangentially relevant.
> 
> On Saturday, 9 April 2016 13:51:17 UTC-4, Tim Holy wrote:
> > Not sure what's happening. Is it possible there's a conflict with PyPlot?
> > 
> > When I grep the source of ImageView, I don't find any mention of gtk.
> > 
> > --Tim
> > 
> > On Saturday, April 09, 2016 10:06:52 AM Colin Beckingham wrote:
> > > Pkg.status()
> > > 
> > > 31 required packages:
> > >  - BinDeps   0.3.21+master
> > >  - Cairo 0.2.31
> > >  - Clustering0.5.0
> > >  - ColorTypes0.2.2
> > >  - DSP   0.0.11
> > >  - DataArrays0.2.20
> > >  - DataFrames0.7.0+ master
> > >  - Debug 0.1.6
> > >  - DecisionTree  0.3.12
> > >  - DimensionalityReduction   0.1.1
> > >  - Distances 0.3.0
> > >  - Docile0.5.23
> > >  - FunctionalDataUtils   0.1.0
> > >  - GLM   0.5.0
> > >  - GZip  0.2.18
> > >  - HttpParser0.1.1
> > >  - ImageMagick   0.1.3
> > >  - ImageView 0.1.19+master
> > >  - Images0.5.3
> > >  - IniFile   0.2.5
> > >  - JLD   0.5.9
> > >  - JSON  0.5.0
> > >  - LightXML  0.2.1
> > >  - MLBase0.5.2
> > >  - PkgDev0.1.0
> > >  - PyPlot2.1.1+ master
> > >  - RDatasets 0.1.2+ master
> > >  - StatsBase 0.8.0
> > >  - Tk0.3.7
> > >  - WAV   0.6.3
> > >  - Winston   0.11.13
> > > 
> > > 29 additional packages:
> > >  - ArrayViews0.6.4
> > >  - Blosc 0.1.4
> > >  - ColorVectorSpace  0.1.2
> > >  - Colors0.6.3
> > >  - Compat0.7.13
> > >  - Conda 0.1.9
> > >  - Dates 0.4.4
> > >  - Distributions 0.8.10
> > >  - FactCheck 0.4.2
> > >  - FileIO0.0.4
> > >  - FixedPointNumbers 0.1.2  master
> > >  - FunctionalData0.1.0
> > >  - Graphics  0.1.3
> > >  - HDF5  0.5.8
> > >  - HttpCommon0.2.4
> > >  - Iterators 0.1.9
> > >  - LaTeXStrings  0.1.6
> > >  - MultivariateStats 0.2.2
> > >  - PDMats0.4.1
> > >  - Polynomials   0.0.5
> > >  - PyCall1.4.0
> > >  - Reexport  0.0.3
> > >  - SHA   0.1.2
> > >  - SIUnits   0.0.6
> > >  - SortingAlgorithms 0.0.6
> > >  - StatsFuns 0.2.0
> > >  - TexExtensions 0.0.3
> > >  - URIParser 0.1.3+ master
> > >  - Zlib  0.1.12
> > > 
> > > On Saturday, 9 April 2016 12:48:49 UTC-4, Tim Holy wrote:
> > > > I can't replicate this, whether with the tagged version of ImageView
> > > > (Pkg.free("ImageView")) nor with master. What does Pkg.status() say?
> > > > 
> > > > --Tim
> > > > 
> > > > On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote:
> > > > > Using openSUSE Leap 42.1
> > > > > I can add the package ImageView and even checkout the latest master
> > 
> > and
> > 
> > > > > build. Then on "using ImageView" the error
> > > > > UndefVarError: _jl_libgobject not defined
> > > > > pops out. I guess this has something to do with my graphic backend,
> > 
> > but
> > 
> > > > not
> > > > 
> > > > > sure what the next step is. I have seen other references to problems
> > > > 
> > > > with
> > > > 
> > > > > libgtobject but nothing that seems to coincide with my situation.
> > 
> > Same
> > 
> > > > > problem on Julia v 4 and 5. I know from loading the image package in
> > > > 
> > > > Octave
> > > > 
> > > > > that a backend GTK graphics engine is available.

[julia-users] Re: Deprecation of `require` and parallel code execution.

['Jhan Jar' via julia-users]

Would it also work for pmap()? I don't have any @parallel loops.

On Sunday, April 10, 2016 at 12:39:25 AM UTC+5, Eduardo Lenz wrote:
>
> Hi.
>
> Use include("file.jl")  and add @everywhere in front of the definition of 
> every function to be used inside the @parallel loop.
>
> []´s
>
> On Saturday, April 9, 2016 at 12:02:02 PM UTC-3, Jhan Jar wrote:
>>
>> Hi, 
>>
>> In Julia 0.3.5, the following loaded the data and code/functions on all 
>> workers:
>>
>> addprocs(3)
>> require("data_loading_script.jl")
>> require("functions.jl")
>>
>> Now, Julia 0.4.5 warns about deprecation of require and suggests 
>> switching to 'using' or 'import'.
>>
>> What is the equivalent in Julia 0.4.5 for the above three lines that 
>> worked fine in Julia 0.3.x?
>>
>>

[julia-users] Re: Deprecation of `require` and parallel code execution.

[Eduardo Lenz]

Hi.

Use include("file.jl")  and add @everywhere in front of the definition of 
every function to be used inside the @parallel loop.

[]´s

On Saturday, April 9, 2016 at 12:02:02 PM UTC-3, Jhan Jar wrote:
>
> Hi, 
>
> In Julia 0.3.5, the following loaded the data and code/functions on all 
> workers:
>
> addprocs(3)
> require("data_loading_script.jl")
> require("functions.jl")
>
> Now, Julia 0.4.5 warns about deprecation of require and suggests switching 
> to 'using' or 'import'.
>
> What is the equivalent in Julia 0.4.5 for the above three lines that 
> worked fine in Julia 0.3.x?
>
>

[julia-users] Re: JuliaCon 2016: Keynote speakers

[Eric Davies]

Holy s**t! I'm very excited!

On Friday, 8 April 2016 20:43:09 UTC-5, Andreas Noack wrote:
>
> JuliaCon 2016
> June 21 - 25, 2016
> Massachusetts Institute of Technology, Cambridge, Massachusetts, USA.
> http://juliacon.org/
>
> On behalf of the JuliaCon 2016 committee, I am happy to announce the 
> following keynote speakers:
>
> *Timothy E. Holy, Thomas J. Sargent, *and* Guy L. Steele Jr.*
>
> *Timothy E. Holy* is Associate Professor of Neuroscience at Washington 
> University in St. Louis. In 2009 he received the NIH Director’s Pioneer 
> award for innovations in optics and microscopy. His research interests 
> include imaging of neuronal activity and his lab was probably one of the 
> first to adopt Julia for scientific research. He is a long time Julia 
> contributor and a lead developer of Julia’s multidimensional array 
> capabilities as well as the author of far too many Julia packages.
>
> *Thomas J. Sargent* is Professor of Economics at New York University and 
> Senior Fellow at the Hoover Institution. In 2011 the Royal Swedish 
> Academy of Sciences awarded him the Nobel Memorial Prize in Economic 
> Sciences for his work on macroeconomics. Together with John Stachurski he 
> founded quant-econ.net, a Julia and Python based learning platform for 
> quantitative economics focusing on algorithms and numerical methods for 
> studying economic problems as well as coding skills.
>
> *Guy L. Steele Jr.* is a Software Architect for Oracle Labs and Principal 
> Investigator of the Programming Language Research project. The Association 
> for Computing Machinery awarded him the 1988 Grace Murray Hopper award. He 
> has co-designed the programming language Scheme, which has greatly 
> influenced the design of Julia, as well as languages such as Fortress and 
> Java.
>
> Andreas Noack
> JuliaCon 2016 Local Chair
> Postdoctoral Associate
> Computer Science and Artificial Intelligence Laboratory
> Massachusetts Institute of Technology
>

Re: [julia-users] Using ImageView leads to libgobject error

[Colin Beckingham]

I tried Pkg.rm("PyPlot") which put PyPlot in the additional packages group, 
but the error persists. If there is something else I should do, by all 
means give a hint.

I thought I found an older note which referred to ImageView and Gtk, which 
is why I mentioned it.

Running through the require list for ImageView I have no problems using any 
of them except Winston, which produces
"ERROR: LoadError: syntax: space before "(" not allowed in 
"AbstractVecOrMat{T} (""
I mention it in case it might be tangentially relevant.

On Saturday, 9 April 2016 13:51:17 UTC-4, Tim Holy wrote:
>
> Not sure what's happening. Is it possible there's a conflict with PyPlot? 
>
> When I grep the source of ImageView, I don't find any mention of gtk. 
>
> --Tim 
>
> On Saturday, April 09, 2016 10:06:52 AM Colin Beckingham wrote: 
> > Pkg.status() 
> > 31 required packages: 
> >  - BinDeps   0.3.21+master 
> >  - Cairo 0.2.31 
> >  - Clustering0.5.0 
> >  - ColorTypes0.2.2 
> >  - DSP   0.0.11 
> >  - DataArrays0.2.20 
> >  - DataFrames0.7.0+ master 
> >  - Debug 0.1.6 
> >  - DecisionTree  0.3.12 
> >  - DimensionalityReduction   0.1.1 
> >  - Distances 0.3.0 
> >  - Docile0.5.23 
> >  - FunctionalDataUtils   0.1.0 
> >  - GLM   0.5.0 
> >  - GZip  0.2.18 
> >  - HttpParser0.1.1 
> >  - ImageMagick   0.1.3 
> >  - ImageView 0.1.19+master 
> >  - Images0.5.3 
> >  - IniFile   0.2.5 
> >  - JLD   0.5.9 
> >  - JSON  0.5.0 
> >  - LightXML  0.2.1 
> >  - MLBase0.5.2 
> >  - PkgDev0.1.0 
> >  - PyPlot2.1.1+ master 
> >  - RDatasets 0.1.2+ master 
> >  - StatsBase 0.8.0 
> >  - Tk0.3.7 
> >  - WAV   0.6.3 
> >  - Winston   0.11.13 
> > 29 additional packages: 
> >  - ArrayViews0.6.4 
> >  - Blosc 0.1.4 
> >  - ColorVectorSpace  0.1.2 
> >  - Colors0.6.3 
> >  - Compat0.7.13 
> >  - Conda 0.1.9 
> >  - Dates 0.4.4 
> >  - Distributions 0.8.10 
> >  - FactCheck 0.4.2 
> >  - FileIO0.0.4 
> >  - FixedPointNumbers 0.1.2  master 
> >  - FunctionalData0.1.0 
> >  - Graphics  0.1.3 
> >  - HDF5  0.5.8 
> >  - HttpCommon0.2.4 
> >  - Iterators 0.1.9 
> >  - LaTeXStrings  0.1.6 
> >  - MultivariateStats 0.2.2 
> >  - PDMats0.4.1 
> >  - Polynomials   0.0.5 
> >  - PyCall1.4.0 
> >  - Reexport  0.0.3 
> >  - SHA   0.1.2 
> >  - SIUnits   0.0.6 
> >  - SortingAlgorithms 0.0.6 
> >  - StatsFuns 0.2.0 
> >  - TexExtensions 0.0.3 
> >  - URIParser 0.1.3+ master 
> >  - Zlib  0.1.12 
> > 
> > On Saturday, 9 April 2016 12:48:49 UTC-4, Tim Holy wrote: 
> > > I can't replicate this, whether with the tagged version of ImageView 
> > > (Pkg.free("ImageView")) nor with master. What does Pkg.status() say? 
> > > 
> > > --Tim 
> > > 
> > > On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote: 
> > > > Using openSUSE Leap 42.1 
> > > > I can add the package ImageView and even checkout the latest master 
> and 
> > > > build. Then on "using ImageView" the error 
> > > > UndefVarError: _jl_libgobject not defined 
> > > > pops out. I guess this has something to do with my graphic backend, 
> but 
> > > 
> > > not 
> > > 
> > > > sure what the next step is. I have seen other references to problems 
> > > 
> > > with 
> > > 
> > > > libgtobject but nothing that seems to coincide with my situation. 
> Same 
> > > > problem on Julia v 4 and 5. I know from loading the image package in 
> > > 
> > > Octave 
> > > 
> > > > that a backend GTK graphics engine is available. A call to Pkg.add() 
> > > > specifying GTK as an option does not seem to align with any version 
> of 
> > > > .add() in an ImageView context. 
>
>

Re: [julia-users] Using ImageView leads to libgobject error

[Tim Holy]

Not sure what's happening. Is it possible there's a conflict with PyPlot?

When I grep the source of ImageView, I don't find any mention of gtk.

--Tim

On Saturday, April 09, 2016 10:06:52 AM Colin Beckingham wrote:
> Pkg.status()
> 31 required packages:
>  - BinDeps   0.3.21+master
>  - Cairo 0.2.31
>  - Clustering0.5.0
>  - ColorTypes0.2.2
>  - DSP   0.0.11
>  - DataArrays0.2.20
>  - DataFrames0.7.0+ master
>  - Debug 0.1.6
>  - DecisionTree  0.3.12
>  - DimensionalityReduction   0.1.1
>  - Distances 0.3.0
>  - Docile0.5.23
>  - FunctionalDataUtils   0.1.0
>  - GLM   0.5.0
>  - GZip  0.2.18
>  - HttpParser0.1.1
>  - ImageMagick   0.1.3
>  - ImageView 0.1.19+master
>  - Images0.5.3
>  - IniFile   0.2.5
>  - JLD   0.5.9
>  - JSON  0.5.0
>  - LightXML  0.2.1
>  - MLBase0.5.2
>  - PkgDev0.1.0
>  - PyPlot2.1.1+ master
>  - RDatasets 0.1.2+ master
>  - StatsBase 0.8.0
>  - Tk0.3.7
>  - WAV   0.6.3
>  - Winston   0.11.13
> 29 additional packages:
>  - ArrayViews0.6.4
>  - Blosc 0.1.4
>  - ColorVectorSpace  0.1.2
>  - Colors0.6.3
>  - Compat0.7.13
>  - Conda 0.1.9
>  - Dates 0.4.4
>  - Distributions 0.8.10
>  - FactCheck 0.4.2
>  - FileIO0.0.4
>  - FixedPointNumbers 0.1.2  master
>  - FunctionalData0.1.0
>  - Graphics  0.1.3
>  - HDF5  0.5.8
>  - HttpCommon0.2.4
>  - Iterators 0.1.9
>  - LaTeXStrings  0.1.6
>  - MultivariateStats 0.2.2
>  - PDMats0.4.1
>  - Polynomials   0.0.5
>  - PyCall1.4.0
>  - Reexport  0.0.3
>  - SHA   0.1.2
>  - SIUnits   0.0.6
>  - SortingAlgorithms 0.0.6
>  - StatsFuns 0.2.0
>  - TexExtensions 0.0.3
>  - URIParser 0.1.3+ master
>  - Zlib  0.1.12
> 
> On Saturday, 9 April 2016 12:48:49 UTC-4, Tim Holy wrote:
> > I can't replicate this, whether with the tagged version of ImageView
> > (Pkg.free("ImageView")) nor with master. What does Pkg.status() say?
> > 
> > --Tim
> > 
> > On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote:
> > > Using openSUSE Leap 42.1
> > > I can add the package ImageView and even checkout the latest master and
> > > build. Then on "using ImageView" the error
> > > UndefVarError: _jl_libgobject not defined
> > > pops out. I guess this has something to do with my graphic backend, but
> > 
> > not
> > 
> > > sure what the next step is. I have seen other references to problems
> > 
> > with
> > 
> > > libgtobject but nothing that seems to coincide with my situation. Same
> > > problem on Julia v 4 and 5. I know from loading the image package in
> > 
> > Octave
> > 
> > > that a backend GTK graphics engine is available. A call to Pkg.add()
> > > specifying GTK as an option does not seem to align with any version of
> > > .add() in an ImageView context.

[julia-users] [ANN] VulkanCore

[Simon Danisch]

Valentin  and I are proud to announce a Julia 
wrapper for the Vulkan API :
VulkanCore.jl 

Vulkan can be called the successor of OpenGL, but it's a lot closer to the 
hardware, which is why it's not a direct replacement of OpenGL.

In short, the main differences to OpenGL are:

   - lower driver overhead
   - better utilization of multi-core setups
   - shader/kernel are consumed in form of a new intermediate format, SPIR-V 
   , which can 
   be targeted by any language (yes, especially Julia+LLVM)
   - better low-level abstraction for GPU-CPU/GPU-GPU synchronization and 
   memory management
   - GPGPU becomes more of a first class citizen
   - supports a large variety of hardware and platforms (NVIDIA, AMD, 
   Intel, ARM, Android, Linux, Windows 
   ...)

One of the more exciting use cases of Vulkan is running Julia kernels over 
GPU-Arrays and then seamlessly visualizing the results.
Enabling this will be a lot of work. Please stay tuned for further posts 
and watch the progress at Vulkan.jl , 
the (not yet finished) higher level abstraction over VulkanCore.jl.

You can find some more information in a blog post 
 I 
recently wrote.

Best,
Simon

Re: [julia-users] Using ImageView leads to libgobject error

[Colin Beckingham]

Pkg.status()
31 required packages:
 - BinDeps   0.3.21+master
 - Cairo 0.2.31
 - Clustering0.5.0
 - ColorTypes0.2.2
 - DSP   0.0.11
 - DataArrays0.2.20
 - DataFrames0.7.0+ master
 - Debug 0.1.6
 - DecisionTree  0.3.12
 - DimensionalityReduction   0.1.1
 - Distances 0.3.0
 - Docile0.5.23
 - FunctionalDataUtils   0.1.0
 - GLM   0.5.0
 - GZip  0.2.18
 - HttpParser0.1.1
 - ImageMagick   0.1.3
 - ImageView 0.1.19+master
 - Images0.5.3
 - IniFile   0.2.5
 - JLD   0.5.9
 - JSON  0.5.0
 - LightXML  0.2.1
 - MLBase0.5.2
 - PkgDev0.1.0
 - PyPlot2.1.1+ master
 - RDatasets 0.1.2+ master
 - StatsBase 0.8.0
 - Tk0.3.7
 - WAV   0.6.3
 - Winston   0.11.13
29 additional packages:
 - ArrayViews0.6.4
 - Blosc 0.1.4
 - ColorVectorSpace  0.1.2
 - Colors0.6.3
 - Compat0.7.13
 - Conda 0.1.9
 - Dates 0.4.4
 - Distributions 0.8.10
 - FactCheck 0.4.2
 - FileIO0.0.4
 - FixedPointNumbers 0.1.2  master
 - FunctionalData0.1.0
 - Graphics  0.1.3
 - HDF5  0.5.8
 - HttpCommon0.2.4
 - Iterators 0.1.9
 - LaTeXStrings  0.1.6
 - MultivariateStats 0.2.2
 - PDMats0.4.1
 - Polynomials   0.0.5
 - PyCall1.4.0
 - Reexport  0.0.3
 - SHA   0.1.2
 - SIUnits   0.0.6
 - SortingAlgorithms 0.0.6
 - StatsFuns 0.2.0
 - TexExtensions 0.0.3
 - URIParser 0.1.3+ master
 - Zlib  0.1.12

On Saturday, 9 April 2016 12:48:49 UTC-4, Tim Holy wrote:
>
> I can't replicate this, whether with the tagged version of ImageView 
> (Pkg.free("ImageView")) nor with master. What does Pkg.status() say? 
>
> --Tim 
>
> On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote: 
> > Using openSUSE Leap 42.1 
> > I can add the package ImageView and even checkout the latest master and 
> > build. Then on "using ImageView" the error 
> > UndefVarError: _jl_libgobject not defined 
> > pops out. I guess this has something to do with my graphic backend, but 
> not 
> > sure what the next step is. I have seen other references to problems 
> with 
> > libgtobject but nothing that seems to coincide with my situation. Same 
> > problem on Julia v 4 and 5. I know from loading the image package in 
> Octave 
> > that a backend GTK graphics engine is available. A call to Pkg.add() 
> > specifying GTK as an option does not seem to align with any version of 
> > .add() in an ImageView context. 
>
>

Re: [julia-users] Using ImageView leads to libgobject error

[Tim Holy]

I can't replicate this, whether with the tagged version of ImageView 
(Pkg.free("ImageView")) nor with master. What does Pkg.status() say?

--Tim

On Saturday, April 09, 2016 07:49:44 AM Colin Beckingham wrote:
> Using openSUSE Leap 42.1
> I can add the package ImageView and even checkout the latest master and
> build. Then on "using ImageView" the error
> UndefVarError: _jl_libgobject not defined
> pops out. I guess this has something to do with my graphic backend, but not
> sure what the next step is. I have seen other references to problems with
> libgtobject but nothing that seems to coincide with my situation. Same
> problem on Julia v 4 and 5. I know from loading the image package in Octave
> that a backend GTK graphics engine is available. A call to Pkg.add()
> specifying GTK as an option does not seem to align with any version of
> .add() in an ImageView context.

Re: [julia-users] Fast multiprecision integers?

[Laurent Bartholdi]

Thanks! Performance, however, would drop too much (Julia will not fit 
FastInts into registers), and memory is more an issue than time.

On Saturday, 9 April 2016 17:49:07 UTC+2, Erik Schnetter wrote:
>
> Laurent 
>
> You can use a construct such as 
>
> ```Julia 
> immutable FastInt 
> isbig::Bool 
> small::Int 
> big::BigInt 
> FastInt(x::Int) = new(false, x) 
> FastInt(x::BigInt) = new(true, 0, x) 
> end 
> getbig(x::FastInt) = x.isbig ? x.big : BigInt(x.small) 
> function add(x::FastInt, y::FastInt) 
> if !isbig(x) & !isbig(y) 
> # add overflow checking 
> return FastInt(x.small + y.small) 
> end 
> FastInt(getbig(x) + getbig(y)) 
> end 
> ``` 
>
> This will be reasonably efficient (apart from memory usage), and since 
> unused `BigInt` objects are never initialized, no memory will be 
> allocated for them. 
>
> You could also fold the `isbig` field into `small` by e.g. choosing to 
> use `typemin(Int)` as a value that indicates that the `BigInt` field 
> should be used. 
>
> -erik 
>
>
>
> On Sat, Apr 9, 2016 at 8:07 AM, Laurent Bartholdi 
> > wrote: 
> > Thanks for the explanations. Am I correct in understanding that objects 
> are 
> > garbage-collected when they're only pointed to, and this causes the 
> problem? 
> > This kills my naive idea of using pointers to BigInts as a 64-bit 
> datatype 
> > compatible with ints, and is suggested by the following experiment: 
> > 
> > julia> l = [pointer_from_objref(BigInt(i)) for i=1:10] 
> > 10-element Array{Ptr{Void},1}: 
> >  Ptr{Void} @0x000118c77150 
> >  Ptr{Void} @0x000118c77170 
> >  Ptr{Void} @0x000118c77190 
> >  Ptr{Void} @0x000118c771b0 
> >  Ptr{Void} @0x000118c771d0 
> >  Ptr{Void} @0x000118c771f0 
> >  Ptr{Void} @0x000118c77210 
> >  Ptr{Void} @0x000118c77230 
> >  Ptr{Void} @0x000118c77250 
> >  Ptr{Void} @0x000118c77270 
> > 
> > 
> > julia> unsafe_pointer_to_objref(l[7]) 
> > 7 
> > 
> > 
> > julia> map(unsafe_pointer_to_objref,l) 
> > Segmentation fault: 11 
> > 
> > 
> > On Friday, 8 April 2016 17:47:34 UTC+2, Stefan Karpinski wrote: 
> >> 
> >> This could help if both parts of the union were plain old data like 
> Int64 
> >> and Float64, but in the case of Int and BigInt, one of them is a more 
> >> complex type, which would currently force the whole thing to be boxed 
> and 
> >> live in the heap anyway. What's needed here is the ability to 
> stack-allocate 
> >> objects that refer to the heap. We cannot do that now, but it is an 
> >> important planned CG improvement. 
> >> 
> >> On Fri, Apr 8, 2016 at 11:28 AM, Scott Jones  
> >> wrote: 
> >>> 
> >>> I like very much the idea of a discriminated union - that would help 
> >>> enormously with some of the stuff I work on. 
> >>> 
> >>> 
> >>> On Friday, April 8, 2016 at 8:47:59 AM UTC-4, Erik Schnetter wrote: 
>  
>  Laurent 
>  
>  I'm afraid you can't use `reinterpret` with a type such as `BigInt`. 
>  
>  I think what you want is an extension of `Nullable`: A nullable type 
>  represents an object of a particular type that might or might not be 
>  there; there's hope that this would be done efficiently, e.g. via an 
>  additional bit. What you want is an efficient representation of a 
>  discriminated union -- a type that can represent either of two types, 
>  but without the overhead from boxing the types as is currently done 
> in 
>  a `Union`. Unfortunately, Julia currently doesn't provide this, but 
> it 
>  would make sense to have a feature request for this. 
>  
>  This might look like this: 
>  ```Julia 
>  immutable FastInt 
>  val::DiscriminatedUnion{Int, BigInt} 
>  end 
>  function (+)(a::FastInt, b::FastInt) 
>  if typeindex(a.val) == 1 & typeindex(b.val) == 1 
>  ov,res = add_with_overflow(a.val[1], b.val[1]) 
>  ov && return FastInt(BigInt(res)) 
>  return FastInt(res) 
>  end 
>  # TODO: handle mixed case 
>  FastInt(a.val[2] + b.val[2]) 
>  end 
>  ``` 
>  
>  This would be the same idea as yours, but the `reinterpret` occurs 
>  within Julia, in a type-safe and type-stable manner, in a way such 
>  that the compiler can optimize better. 
>  
>  You could try defining a type that contains two fields, both an `Int` 
>  and a `BigInt` -- maybe `BigInt` will handle the case of a value that 
>  is never used in a more efficient manner that doesn't require 
>  allocating an object. 
>  
>  -erik 
>  
>  On Fri, Apr 8, 2016 at 2:07 AM, Laurent Bartholdi 
>   wrote: 
>  > Dear all, 
>  > How hard would it be to code arbitrary-precision integers in Julia 
>  > with at 
>  > worst 2x performance loss over native Ints? 
>  > 
>  > This is what I have in mind: have a bitstype structure, say 64 
> bits, 
>  > which 
>  > is either the address o

Re: [julia-users] Access to gmp from library?

[Laurent Bartholdi]

Thanks! In fact, I see now that the latest github version already does this.

(And my email to the list was triggered by a discussion with the Nemo 
people.)

Issue closed.

On Saturday, 9 April 2016 18:16:18 UTC+2, Isaiah wrote:
>
> 1) It seems that Julia includes libgmp.{so,dylib} but not gmp.h, which is 
>> necessary for the C library's compilation
>
>  
> There was some prior discussion about this, for a similar reason [1], but 
> I think they eventually decided to use MPIR.
>
> I don't know of a reason this shouldn't be done, and it likely requires 
> only a few additional lines in the makefile. Please open an issue on 
> JuliaLang/julia.
>
> (ps: Nemo may be of interest, in case you haven't seen it [2])
>
> 2) It seems some black magic will be required to locate the gmp 
>> installation path within the Julia tree
>>
>
> I believe (hopefully Tony will confirm) that you need to check these two 
> paths:
>
> joinpath(JULIA_HOME, "../lib")  # source builds
> joinpath(JULIA_HOME, "../lib/julia")   # binary downloads
>
> Best,
> Isaiah
>
>
> [1] https://groups.google.com/d/msg/julia-users/8emhRgpTN5E/8IouaSnn5xwJ
> [2] http://nemocas.org/ https://github.com/Nemocas/Nemo.jl
>
> On Sat, Apr 9, 2016 at 8:13 AM, Laurent Bartholdi  > wrote:
>
>> Dear all,
>> My package contains a C library that requires gmp. It would be very nice 
>> to be able to use Julia's gmp, so as not to install a duplicate copy of gmp 
>> as by package's library's dependency. However,
>> 1) It seems that Julia includes libgmp.{so,dylib} but not gmp.h, which is 
>> necessary for the C library's compilation
>> 2) It seems some black magic will be required to locate the gmp 
>> installation path within the Julia tree
>>
>> Suggestions are welcome on the best way to proceed!
>>
>
>

Re: [julia-users] Access to gmp from library?

[Isaiah Norton]

>
> 1) It seems that Julia includes libgmp.{so,dylib} but not gmp.h, which is
> necessary for the C library's compilation


There was some prior discussion about this, for a similar reason [1], but I
think they eventually decided to use MPIR.

I don't know of a reason this shouldn't be done, and it likely requires
only a few additional lines in the makefile. Please open an issue on
JuliaLang/julia.

(ps: Nemo may be of interest, in case you haven't seen it [2])

2) It seems some black magic will be required to locate the gmp
> installation path within the Julia tree
>

I believe (hopefully Tony will confirm) that you need to check these two
paths:

joinpath(JULIA_HOME, "../lib")  # source builds
joinpath(JULIA_HOME, "../lib/julia")   # binary downloads

Best,
Isaiah


[1] https://groups.google.com/d/msg/julia-users/8emhRgpTN5E/8IouaSnn5xwJ
[2] http://nemocas.org/ https://github.com/Nemocas/Nemo.jl

On Sat, Apr 9, 2016 at 8:13 AM, Laurent Bartholdi <
laurent.bartho...@gmail.com> wrote:

> Dear all,
> My package contains a C library that requires gmp. It would be very nice
> to be able to use Julia's gmp, so as not to install a duplicate copy of gmp
> as by package's library's dependency. However,
> 1) It seems that Julia includes libgmp.{so,dylib} but not gmp.h, which is
> necessary for the C library's compilation
> 2) It seems some black magic will be required to locate the gmp
> installation path within the Julia tree
>
> Suggestions are welcome on the best way to proceed!
>

Re: [julia-users] Fast multiprecision integers?

[Erik Schnetter]

Laurent

You can use a construct such as

```Julia
immutable FastInt
isbig::Bool
small::Int
big::BigInt
FastInt(x::Int) = new(false, x)
FastInt(x::BigInt) = new(true, 0, x)
end
getbig(x::FastInt) = x.isbig ? x.big : BigInt(x.small)
function add(x::FastInt, y::FastInt)
if !isbig(x) & !isbig(y)
# add overflow checking
return FastInt(x.small + y.small)
end
FastInt(getbig(x) + getbig(y))
end
```

This will be reasonably efficient (apart from memory usage), and since
unused `BigInt` objects are never initialized, no memory will be
allocated for them.

You could also fold the `isbig` field into `small` by e.g. choosing to
use `typemin(Int)` as a value that indicates that the `BigInt` field
should be used.

-erik



On Sat, Apr 9, 2016 at 8:07 AM, Laurent Bartholdi
 wrote:
> Thanks for the explanations. Am I correct in understanding that objects are
> garbage-collected when they're only pointed to, and this causes the problem?
> This kills my naive idea of using pointers to BigInts as a 64-bit datatype
> compatible with ints, and is suggested by the following experiment:
>
> julia> l = [pointer_from_objref(BigInt(i)) for i=1:10]
> 10-element Array{Ptr{Void},1}:
>  Ptr{Void} @0x000118c77150
>  Ptr{Void} @0x000118c77170
>  Ptr{Void} @0x000118c77190
>  Ptr{Void} @0x000118c771b0
>  Ptr{Void} @0x000118c771d0
>  Ptr{Void} @0x000118c771f0
>  Ptr{Void} @0x000118c77210
>  Ptr{Void} @0x000118c77230
>  Ptr{Void} @0x000118c77250
>  Ptr{Void} @0x000118c77270
>
>
> julia> unsafe_pointer_to_objref(l[7])
> 7
>
>
> julia> map(unsafe_pointer_to_objref,l)
> Segmentation fault: 11
>
>
> On Friday, 8 April 2016 17:47:34 UTC+2, Stefan Karpinski wrote:
>>
>> This could help if both parts of the union were plain old data like Int64
>> and Float64, but in the case of Int and BigInt, one of them is a more
>> complex type, which would currently force the whole thing to be boxed and
>> live in the heap anyway. What's needed here is the ability to stack-allocate
>> objects that refer to the heap. We cannot do that now, but it is an
>> important planned CG improvement.
>>
>> On Fri, Apr 8, 2016 at 11:28 AM, Scott Jones 
>> wrote:
>>>
>>> I like very much the idea of a discriminated union - that would help
>>> enormously with some of the stuff I work on.
>>>
>>>
>>> On Friday, April 8, 2016 at 8:47:59 AM UTC-4, Erik Schnetter wrote:

 Laurent

 I'm afraid you can't use `reinterpret` with a type such as `BigInt`.

 I think what you want is an extension of `Nullable`: A nullable type
 represents an object of a particular type that might or might not be
 there; there's hope that this would be done efficiently, e.g. via an
 additional bit. What you want is an efficient representation of a
 discriminated union -- a type that can represent either of two types,
 but without the overhead from boxing the types as is currently done in
 a `Union`. Unfortunately, Julia currently doesn't provide this, but it
 would make sense to have a feature request for this.

 This might look like this:
 ```Julia
 immutable FastInt
 val::DiscriminatedUnion{Int, BigInt}
 end
 function (+)(a::FastInt, b::FastInt)
 if typeindex(a.val) == 1 & typeindex(b.val) == 1
 ov,res = add_with_overflow(a.val[1], b.val[1])
 ov && return FastInt(BigInt(res))
 return FastInt(res)
 end
 # TODO: handle mixed case
 FastInt(a.val[2] + b.val[2])
 end
 ```

 This would be the same idea as yours, but the `reinterpret` occurs
 within Julia, in a type-safe and type-stable manner, in a way such
 that the compiler can optimize better.

 You could try defining a type that contains two fields, both an `Int`
 and a `BigInt` -- maybe `BigInt` will handle the case of a value that
 is never used in a more efficient manner that doesn't require
 allocating an object.

 -erik

 On Fri, Apr 8, 2016 at 2:07 AM, Laurent Bartholdi
  wrote:
 > Dear all,
 > How hard would it be to code arbitrary-precision integers in Julia
 > with at
 > worst 2x performance loss over native Ints?
 >
 > This is what I have in mind: have a bitstype structure, say 64 bits,
 > which
 > is either the address of a BigInt (if even), or an Int64 (if odd).
 > Addition
 > would be something like:
 >
 > function +(a::FastInt,b::FastInt)
 > if a&b&1
 > (result,obit) = @llvm.sadd.with.overflow.i64(a,b&~1)
 > obit ? reinterpret(FastInt,BigInt(a>>1)+(b>>1)) : result
 > elseif a&1
 > reinterpret(FastInt,(a>>1) + reinterpret(BigInt,b))
 > elseif b&1
 > reinterpret(FastInt,reinterpret(BigInt,a) + b>>1)
 > else
 > reinterpret(FastInt,reinterpret(BigInt,a) +
 > reinterpret(BigInt,b))
 > end
 > end

Re: [julia-users] Re: custom ctags for Julia

[El suisse]

Cool!!!, thanks for sharing your experience :D

2016-04-09 3:02 GMT-03:00 Christof Stocker :

> To be blunt I never really bothered to investigate the "right way" to use
> ctags. I simply looked for a way that works for my use case. That being
> said, I can tell you how I use ctags.
>
> Some page somewhere (I found it again, see the end of my post) suggested
> to use the .git directory of a project to store the tags file, which I
> thought was the best solution, given that then the tags would always be
> project specific. I use the Tags to move between files with CtrlP, so I
> liked this approach. Basically it uses local githooks to produce the tag
> file on every major git operation like commit etc.
>
> This is the website that I followed the instructions of:
> http://tbaggery.com/2011/08/08/effortless-ctags-with-git.html
> It also addresses your question about one way to call ctags (which works
> for me at least).
>
>
> On 2016-04-09 04:33, El suisse wrote:
>
> Sorry for the noise, which it is the right way to generate the file tags?
> in .julia/ ?
> with the command:
>
> `ctags -R .`
>
> 2016-03-16 10:38 GMT-03:00 Christof Stocker :
>
>> Makes sense. I don't use C-], I use the CtrlP plugin to jump around in a
>> project. I included the first parameter, so that CtrlP has an easier time
>> finding the unique match
>>
>>
>> On 2016-03-15 20:41, Daniel Arndt wrote:
>>
>> I gave this ago and my experience was:
>>
>> TagBar worked and looked great!
>>
>> jump to tag (C-] in vim) did not work. This seemed to be a result of
>> including the parameters in the tag. If I manually removed them from the
>> tags file, tag jumping would start working again. I won't pretend to know
>> the internals of what VIM and TagBar are doing differently here. I haven't
>> had time to dig any deeper.
>>
>> Cheers,
>> Dan
>>
>> On Monday, 14 March 2016 15:34:16 UTC-3, Daniel Arndt wrote:
>>>
>>> Thanks Christof,
>>>
>>> I've been meaning to get around to doing this myself, so you've saved me
>>> some time. I'm testing it out right now.
>>>
>>> Cheers,
>>> Dan
>>>
>>> On Sunday, 13 March 2016 13:50:00 UTC-3, Christof Stocker wrote:

 I made myself a custom one based on the one from the julia repo.
 Basically I seperated the big one into multiple categories and also allow
 functions to be marked inline

 I posted a gist of it for those interested

 https://gist.github.com/Evizero/e1595c35611c15ebf8f9

 Am Freitag, 12. Februar 2016 14:38:42 UTC+1 schrieb Christof Stocker:
>
> Hi!
>
> Are there any VIM users here who have a nice
> [tagbar](https://github.com/majutsushi/tagbar) going?
>
> For the tagbar to work properly one needs to have a Julia language
> definition for [ctags]( 
> http://ctags.sourceforge.net/). I have found one
> [here](https://github.com/JuliaLang/julia/blob/master/contrib/ctags)
> that nicely lists all the functions, which is great, but I wonder if
> anyone has already put in the additional effort and created a custom
> one
> that also lists types, and macros etc. Would be much appreciated.
>

>>
>
>

[julia-users] Deprecation of `require` and parallel code execution.

['Jhan Jar' via julia-users]

Hi, 

In Julia 0.3.5, the following loaded the data and code/functions on all 
workers:

addprocs(3)
require("data_loading_script.jl")
require("functions.jl")

Now, Julia 0.4.5 warns about deprecation of require and suggests switching 
to 'using' or 'import'.

What is the equivalent in Julia 0.4.5 for the above three lines that worked 
fine in Julia 0.3.x?

[julia-users] Using ImageView leads to libgobject error

[Colin Beckingham]

Using openSUSE Leap 42.1
I can add the package ImageView and even checkout the latest master and 
build. Then on "using ImageView" the error
UndefVarError: _jl_libgobject not defined
pops out. I guess this has something to do with my graphic backend, but not 
sure what the next step is. I have seen other references to problems with 
libgtobject but nothing that seems to coincide with my situation. Same 
problem on Julia v 4 and 5. I know from loading the image package in Octave 
that a backend GTK graphics engine is available. A call to Pkg.add() 
specifying GTK as an option does not seem to align with any version of 
.add() in an ImageView context. 

Re: [julia-users] Fast multiprecision integers?

[Yichao Yu]

On Sat, Apr 9, 2016 at 8:07 AM, Laurent Bartholdi
 wrote:
> Thanks for the explanations. Am I correct in understanding that objects are
> garbage-collected when they're only pointed to, and this causes the problem?
> This kills my naive idea of using pointers to BigInts as a 64-bit datatype
> compatible with ints, and is suggested by the following experiment:

Correct. Don't do that. In fact, never ever use
`unsafe_pointer_to_objref` unless you are getting a julia object
pointer as a pointer in a cfunction callback.

>
> julia> l = [pointer_from_objref(BigInt(i)) for i=1:10]
> 10-element Array{Ptr{Void},1}:
>  Ptr{Void} @0x000118c77150
>  Ptr{Void} @0x000118c77170
>  Ptr{Void} @0x000118c77190
>  Ptr{Void} @0x000118c771b0
>  Ptr{Void} @0x000118c771d0
>  Ptr{Void} @0x000118c771f0
>  Ptr{Void} @0x000118c77210
>  Ptr{Void} @0x000118c77230
>  Ptr{Void} @0x000118c77250
>  Ptr{Void} @0x000118c77270
>
>
> julia> unsafe_pointer_to_objref(l[7])
> 7
>
>
> julia> map(unsafe_pointer_to_objref,l)
> Segmentation fault: 11
>
>
> On Friday, 8 April 2016 17:47:34 UTC+2, Stefan Karpinski wrote:
>>
>> This could help if both parts of the union were plain old data like Int64
>> and Float64, but in the case of Int and BigInt, one of them is a more
>> complex type, which would currently force the whole thing to be boxed and
>> live in the heap anyway. What's needed here is the ability to stack-allocate
>> objects that refer to the heap. We cannot do that now, but it is an
>> important planned CG improvement.
>>
>> On Fri, Apr 8, 2016 at 11:28 AM, Scott Jones 
>> wrote:
>>>
>>> I like very much the idea of a discriminated union - that would help
>>> enormously with some of the stuff I work on.
>>>
>>>
>>> On Friday, April 8, 2016 at 8:47:59 AM UTC-4, Erik Schnetter wrote:

 Laurent

 I'm afraid you can't use `reinterpret` with a type such as `BigInt`.

 I think what you want is an extension of `Nullable`: A nullable type
 represents an object of a particular type that might or might not be
 there; there's hope that this would be done efficiently, e.g. via an
 additional bit. What you want is an efficient representation of a
 discriminated union -- a type that can represent either of two types,
 but without the overhead from boxing the types as is currently done in
 a `Union`. Unfortunately, Julia currently doesn't provide this, but it
 would make sense to have a feature request for this.

 This might look like this:
 ```Julia
 immutable FastInt
 val::DiscriminatedUnion{Int, BigInt}
 end
 function (+)(a::FastInt, b::FastInt)
 if typeindex(a.val) == 1 & typeindex(b.val) == 1
 ov,res = add_with_overflow(a.val[1], b.val[1])
 ov && return FastInt(BigInt(res))
 return FastInt(res)
 end
 # TODO: handle mixed case
 FastInt(a.val[2] + b.val[2])
 end
 ```

 This would be the same idea as yours, but the `reinterpret` occurs
 within Julia, in a type-safe and type-stable manner, in a way such
 that the compiler can optimize better.

 You could try defining a type that contains two fields, both an `Int`
 and a `BigInt` -- maybe `BigInt` will handle the case of a value that
 is never used in a more efficient manner that doesn't require
 allocating an object.

 -erik

 On Fri, Apr 8, 2016 at 2:07 AM, Laurent Bartholdi
  wrote:
 > Dear all,
 > How hard would it be to code arbitrary-precision integers in Julia
 > with at
 > worst 2x performance loss over native Ints?
 >
 > This is what I have in mind: have a bitstype structure, say 64 bits,
 > which
 > is either the address of a BigInt (if even), or an Int64 (if odd).
 > Addition
 > would be something like:
 >
 > function +(a::FastInt,b::FastInt)
 > if a&b&1
 > (result,obit) = @llvm.sadd.with.overflow.i64(a,b&~1)
 > obit ? reinterpret(FastInt,BigInt(a>>1)+(b>>1)) : result
 > elseif a&1
 > reinterpret(FastInt,(a>>1) + reinterpret(BigInt,b))
 > elseif b&1
 > reinterpret(FastInt,reinterpret(BigInt,a) + b>>1)
 > else
 > reinterpret(FastInt,reinterpret(BigInt,a) +
 > reinterpret(BigInt,b))
 > end
 > end
 >
 > (code not meant to be run, just a skeleton)
 >
 > This would be very useful in the development of computer algebra
 > systems, in
 > which BigInts are too slow and eat up too much memory, but one is
 > ready to
 > pay a small price for guard against arithmetic overflows.
 >
 > If this is too complicated, then perhaps at least a type of integers
 > that
 > would raise an error in case of over/underflows? Those could be caught
 > in
 > throw/catch enclosures, so the user could restart the operation with
 > BigInts.
 >
 > TIA, La

[julia-users] Access to gmp from library?

[Laurent Bartholdi]

Dear all,
My package contains a C library that requires gmp. It would be very nice to 
be able to use Julia's gmp, so as not to install a duplicate copy of gmp as 
by package's library's dependency. However,
1) It seems that Julia includes libgmp.{so,dylib} but not gmp.h, which is 
necessary for the C library's compilation
2) It seems some black magic will be required to locate the gmp 
installation path within the Julia tree

Suggestions are welcome on the best way to proceed!

Re: [julia-users] Fast multiprecision integers?

[Laurent Bartholdi]

Thanks for the explanations. Am I correct in understanding that objects are 
garbage-collected when they're only pointed to, and this causes the 
problem? This kills my naive idea of using pointers to BigInts as a 64-bit 
datatype compatible with ints, and is suggested by the following experiment:

julia> l = [pointer_from_objref(BigInt(i)) for i=1:10]
10-element Array{Ptr{Void},1}:
 Ptr{Void} @0x000118c77150
 Ptr{Void} @0x000118c77170
 Ptr{Void} @0x000118c77190
 Ptr{Void} @0x000118c771b0
 Ptr{Void} @0x000118c771d0
 Ptr{Void} @0x000118c771f0
 Ptr{Void} @0x000118c77210
 Ptr{Void} @0x000118c77230
 Ptr{Void} @0x000118c77250
 Ptr{Void} @0x000118c77270


julia> unsafe_pointer_to_objref(l[7])
7


julia> map(unsafe_pointer_to_objref,l)
Segmentation fault: 11


On Friday, 8 April 2016 17:47:34 UTC+2, Stefan Karpinski wrote:
>
> This could help if both parts of the union were plain old data like Int64 
> and Float64, but in the case of Int and BigInt, one of them is a more 
> complex type, which would currently force the whole thing to be boxed and 
> live in the heap anyway. What's needed here is the ability to 
> stack-allocate objects that refer to the heap. We cannot do that now, but 
> it is an important planned CG improvement.
>
> On Fri, Apr 8, 2016 at 11:28 AM, Scott Jones  > wrote:
>
>> I like very much the idea of a discriminated union - that would help 
>> enormously with some of the stuff I work on.
>>
>>
>> On Friday, April 8, 2016 at 8:47:59 AM UTC-4, Erik Schnetter wrote:
>>
>>> Laurent 
>>>
>>> I'm afraid you can't use `reinterpret` with a type such as `BigInt`. 
>>>
>>> I think what you want is an extension of `Nullable`: A nullable type 
>>> represents an object of a particular type that might or might not be 
>>> there; there's hope that this would be done efficiently, e.g. via an 
>>> additional bit. What you want is an efficient representation of a 
>>> discriminated union -- a type that can represent either of two types, 
>>> but without the overhead from boxing the types as is currently done in 
>>> a `Union`. Unfortunately, Julia currently doesn't provide this, but it 
>>> would make sense to have a feature request for this. 
>>>
>>> This might look like this: 
>>> ```Julia 
>>> immutable FastInt 
>>> val::DiscriminatedUnion{Int, BigInt} 
>>> end 
>>> function (+)(a::FastInt, b::FastInt) 
>>> if typeindex(a.val) == 1 & typeindex(b.val) == 1 
>>> ov,res = add_with_overflow(a.val[1], b.val[1]) 
>>> ov && return FastInt(BigInt(res)) 
>>> return FastInt(res) 
>>> end 
>>> # TODO: handle mixed case 
>>> FastInt(a.val[2] + b.val[2]) 
>>> end 
>>> ``` 
>>>
>>> This would be the same idea as yours, but the `reinterpret` occurs 
>>> within Julia, in a type-safe and type-stable manner, in a way such 
>>> that the compiler can optimize better. 
>>>
>>> You could try defining a type that contains two fields, both an `Int` 
>>> and a `BigInt` -- maybe `BigInt` will handle the case of a value that 
>>> is never used in a more efficient manner that doesn't require 
>>> allocating an object. 
>>>
>>> -erik 
>>>
>>> On Fri, Apr 8, 2016 at 2:07 AM, Laurent Bartholdi 
>>>  wrote: 
>>> > Dear all, 
>>> > How hard would it be to code arbitrary-precision integers in Julia 
>>> with at 
>>> > worst 2x performance loss over native Ints? 
>>> > 
>>> > This is what I have in mind: have a bitstype structure, say 64 bits, 
>>> which 
>>> > is either the address of a BigInt (if even), or an Int64 (if odd). 
>>> Addition 
>>> > would be something like: 
>>> > 
>>> > function +(a::FastInt,b::FastInt) 
>>> > if a&b&1 
>>> > (result,obit) = @llvm.sadd.with.overflow.i64(a,b&~1) 
>>> > obit ? reinterpret(FastInt,BigInt(a>>1)+(b>>1)) : result 
>>> > elseif a&1 
>>> > reinterpret(FastInt,(a>>1) + reinterpret(BigInt,b)) 
>>> > elseif b&1 
>>> > reinterpret(FastInt,reinterpret(BigInt,a) + b>>1) 
>>> > else 
>>> > reinterpret(FastInt,reinterpret(BigInt,a) + 
>>> reinterpret(BigInt,b)) 
>>> > end 
>>> > end 
>>> > 
>>> > (code not meant to be run, just a skeleton) 
>>> > 
>>> > This would be very useful in the development of computer algebra 
>>> systems, in 
>>> > which BigInts are too slow and eat up too much memory, but one is 
>>> ready to 
>>> > pay a small price for guard against arithmetic overflows. 
>>> > 
>>> > If this is too complicated, then perhaps at least a type of integers 
>>> that 
>>> > would raise an error in case of over/underflows? Those could be caught 
>>> in 
>>> > throw/catch enclosures, so the user could restart the operation with 
>>> > BigInts. 
>>> > 
>>> > TIA, Laurent 
>>>
>>>
>>>
>>> -- 
>>> Erik Schnetter  
>>> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>>>
>>
>

Re: [julia-users] Maximum variable name length

[Mauro]

524247

julia> s= symbol(randstring(524247));

julia> s= symbol(randstring(524248));
ERROR: ArgumentError: Symbol length exceeds maximum length
 in symbol(::ASCIIString) at ./expr.jl:8
 in eval(::Module, ::Any) at ./boot.jl:243

On Sat, 2016-04-09 at 10:52, nael...@ic.ufal.br wrote:
> Hello,
>
> Is there a maximum length for variable names in Julia?
> I searched for that in the docummentation
>  and here in
> the group, but I didn't find an answer.
>
> Thanks

[julia-users] Maximum variable name length

[naelson]

Hello,

Is there a maximum length for variable names in Julia? 
I searched for that in the docummentation 
 and here in 
the group, but I didn't find an answer.

Thanks

Re: [julia-users] Opinion on Plots.jl -- exclamation marks

[Patrick Kofod Mogensen]

+1 for !

On Saturday, April 9, 2016 at 8:09:23 AM UTC+2, Christof Stocker wrote:
>
> I also prefer the ! so I know it modifies an existing plot. If I don't use 
> a ! then I expect to create a new one
>
> On 2016-04-09 02:52, Daniel Carrera wrote:
>
> Ok. Thanks for the explanation. 
>
> Cheers,
> Daniel.
>
> On 9 April 2016 at 02:30, Tom Breloff > 
> wrote:
>
>> I understand that to you this seems intuitive, but to me it is completely 
>>> counter-intuitive. The function that I'm calling is not changing any of its 
>>> inputs. Telling me that behind the scenes it calls "plots!" is describing 
>>> an implementation detail that can change and should have no bearing on the 
>>> exposed API.
>>>
>>
>> It's not behind the scenes or an implementation detail. The "proper, 
>> exposed" API looks like:
>>
>> plt = plot(rand(10))
>> plot!(plt, xlim = (0,20))
>>
>> Here plt is a julia object.  It's constructed during the first call, and 
>> changed in the second call.  This is the only form that should be used for 
>> "serious" work, as you shouldn't depend on global state in general.  For 
>> your original example, you were on the right track:
>>
>> plt = plot(title = "...", xaxis = (...), ...)
>> for dir in directories
>> ... do some work ...
>> plot!(plt, result, ...)
>> end
>>
>> You can set up the plot attributes in the first call, and then add series 
>> (data) with your results.
>>
>> In your original code, what if there's something in that "do some work" 
>> that calls a plotting command?  (answer... your code breaks)  So the 
>> mutating plot call without an AbstractPlot as the first argument is really 
>> only meant for quick, one-off, analytic work.  It's not meant to be the 
>> primary usage pattern.
>>
>> I would argue that "plots(plt, ...)" is like "write(stream, ...)"
>>>
>>
>> In this example, plt is a julia object that is mutated, whereas stream is 
>> effectively unchanged (it still points to the same file descriptor, or 
>> whatever it wraps).  
>>
>> The better analogies (IMO) are:
>>
>> plt = plot()
>> x = rand(10)
>>
>> # these are similar
>> push!(x, rand())
>> plot!(plt, x)
>>
>> # these are similar
>> show(io, x)
>> display(plt) 
>>
>>
>>
>
>