Re: [julia-users] Re: Conda.jl needs a new maintainer

[Luthaf]

Hi,

Yes, I may try again to use it when the ecoystem and the languages are a 
bit more stable.
I am OK with the JuliaPy organization, but Conda.jl can also be used for 
pure C/C++/Fortran dependencies, without any link to Python.


--
Luthaf


Viral Shah a écrit :

Hi Luthaf,

Sorry to hear that you are not using Julia anymore. Hopefully you will 
come back in the future.


I am wondering if we should create a JuliaPy organization and move 
many important building blocks and python wrapper packages there, if 
the various authors think it is a good idea.


-viral


On Monday, September 5, 2016 at 3:19:54 PM UTC+5:30, Luthaf wrote:

Hi Julians!

I am the author and currently only maintainer of the Conda.jl
package.
This package is a thin wrapper on top of the `conda` package manager,
well known in the Python community.
This package bring to Julia the ability to install native (binary)
and
Python dependencies in a cross-platform way, without any
administrative
rights. It is used by the PyCall.jl package to install Python if no
other installation is found, and a lot of other packages with complex
dependencies. As such, Conda.jl gets around 200 downloads a day,
and is
an important builiding block of the Julia ecosystem, especially on
Windows.

Unfortunatly, as I am not using Julia anymore, I do not have much
time
to continue maintaining this package, and I'd like to someone else to
take over this repository.

I plan to stay around for 6 month helping the new maintainer(s?)
to work
with the code. The code itself is very simple, less than 300 lines of
code. This code do not need specific knowledge, only to read the
documentation of `conda`. A bit of understanding of native
libraries and
dependencies can help, but can be aquired on the fly.

If you want to help, or are just want to get more informations,
please
contact me by email at lut...@luthaf.fr <mailto:lut...@luthaf.fr>.

Best regards,
    -- 
Luthaf

[julia-users] Conda.jl needs a new maintainer

[Luthaf]

Hi Julians!

I am the author and currently only maintainer of the Conda.jl package. 
This package is a thin wrapper on top of the `conda` package manager, 
well known in the Python community.


This package bring to Julia the ability to install native (binary) and 
Python dependencies in a cross-platform way, without any administrative 
rights. It is used by the PyCall.jl package to install Python if no 
other installation is found, and a lot of other packages with complex 
dependencies. As such, Conda.jl gets around 200 downloads a day, and is 
an important builiding block of the Julia ecosystem, especially on Windows.


Unfortunatly, as I am not using Julia anymore, I do not have much time 
to continue maintaining this package, and I'd like to someone else to 
take over this repository.


I plan to stay around for 6 month helping the new maintainer(s?) to work 
with the code. The code itself is very simple, less than 300 lines of 
code. This code do not need specific knowledge, only to read the 
documentation of `conda`. A bit of understanding of native libraries and 
dependencies can help, but can be aquired on the fly.


Please contact me here or on Github (https://github.com/Luthaf/Conda.jl) 
if you want to help or just to get more informations.


Best regards,
--
Luthaf

[julia-users] Conda.jl needs a new maintainer

[Luthaf]

Hi Julians!

I am the author and currently only maintainer of the Conda.jl package. 
This package is a thin wrapper on top of the `conda` package manager, 
well known in the Python community.
This package bring to Julia the ability to install native (binary) and 
Python dependencies in a cross-platform way, without any administrative 
rights. It is used by the PyCall.jl package to install Python if no 
other installation is found, and a lot of other packages with complex 
dependencies. As such, Conda.jl gets around 200 downloads a day, and is 
an important builiding block of the Julia ecosystem, especially on Windows.


Unfortunatly, as I am not using Julia anymore, I do not have much time 
to continue maintaining this package, and I'd like to someone else to 
take over this repository.


I plan to stay around for 6 month helping the new maintainer(s?) to work 
with the code. The code itself is very simple, less than 300 lines of 
code. This code do not need specific knowledge, only to read the 
documentation of `conda`. A bit of understanding of native libraries and 
dependencies can help, but can be aquired on the fly.


If you want to help, or are just want to get more informations, please 
contact me by email at lut...@luthaf.fr.


Best regards,
--
Luthaf

Re: [julia-users] Re: Conda

[Luthaf]

> When I do not have Conda installed but install PyCall in Julia does 
Pkg.add("PyCall") still installs its own small PYthon distribution?


As far as I know, if there is no PYTHON environnement variable and no 
`python` in path, then the automatic MiniConda Python installation is used.


> Small? Mine (that I didn't ask for) has 320 Mb.

Yes, it is small for a scientific Python distribution. The fulll 
Anaconda installer is 1.2G. The standard Python installation is 78M, 
which is smaller, and you can install it first if you want to use it 
instead of Conda installation. But the standard Python do not have 
numpy/scipy/... and they are a pain to install on Windows.


--
Luthaf

Re: [julia-users] Re: a good IDE for Julia ? (Julia Studio does not work with Julia v 0.3.0)

[Luthaf]

Atom is a pretty good editor, and there is an ongoing work to rewrite 
Juno in it.


See https://github.com/JunoLab/atom-ink for a screencast of the editor.

--
Luthaf

PattiMichelle Sheaffer a écrit:


Eclipse isn't terribly user-friendly for noobs like me - has anyone
been able to get liclipse to point to their Juila install? If so, can
you share?

Thanks!!

Re: [julia-users] Re: More conda troubles

[Luthaf]

Is this error the same as https://github.com/JuliaGeo/NetCDF.jl/issues/6 ?

-- 
Luthaf

Le 19 novembre 2015 à 23:12:50, J Luis (jmfl...@gmail.com) a écrit:

Nope. The trouble is that after installing 295 MB of Condas (I mean a full 
python when I already had one and did not ask for another), there was some 
problem and libnetcdf was not installed.


quinta-feira, 19 de Novembro de 2015 às 21:12:15 UTC, Tony Kelman escreveu:
Looks like that's probably a dlopen failure? Or check the libnetcdf in 
dependency walker?


On Thursday, November 19, 2015 at 12:35:10 PM UTC-8, J Luis wrote:
oops, I obviously meant 'cache' not 'cash'

quinta-feira, 19 de Novembro de 2015 às 20:33:28 UTC, J Luis escreveu:
It's so annoying that Pkg.rm() does not rm. So I manually cleaned the cash and 
.trash after Pkg.rm("Conda") but it still doesn't install netCDF.
I wish I could use what I already have in my computer (netcdf and all of its 
dependencies) and not duplicating them (if it worked).

julia> Pkg.build("NetCDF")
INFO: Building NetCDF
Fetching package metadata: 
Solving package specifications: 
# All requested packages already installed.
# packages in environment at C:\j\.julia\v0.4\Conda\deps\usr:
#
libnetcdf 4.3.3.1   vc9_4  [vc9]
===[ ERROR: NetCDF ]

LoadError: Provider BinDeps.PackageManager failed to satisfy dependency 
libnetcdf
while loading C:\j\.julia\v0.4\NetCDF\deps\build.jl, in expression starting on 
line 12


quinta-feira, 19 de Novembro de 2015 às 20:18:47 UTC, J Luis escreveu:
In fact I had. I always call julia from a bat file that I use to set paths of 
interest and calls my WinPython portable installation. Now changed that but I'm 
again in a broken state

julia> Pkg.rm("NetCDF")
INFO: Installing Conda v0.1.8
INFO: Removing Formatting v0.1.4
INFO: Removing NetCDF v0.3.0
INFO: Package database updated

julia> Pkg.add("NetCDF")
INFO: Installing Formatting v0.1.4
INFO: Installing NetCDF v0.3.0
INFO: Building NetCDF
Error: This installation of conda is not initialized. Use 'conda create -n
envname' to create a conda environment and 'source activate envname' to
activate it.

# Note that pip installing conda is not the recommended way for setting up your
# system.  The recommended way for setting up a conda system is by installing
# Miniconda, see: http://repo.continuum.io/miniconda/index.html
===[ ERROR: NetCDF ]==

quinta-feira, 19 de Novembro de 2015 às 19:53:39 UTC, Steven G. Johnson 
escreveu:
Have you set up some environment variables that could affect Python?  e.g. is 
PYTHONPATH or similar set in your environment?  Maybe Conda should unset these 
before running the conda scripts.

[julia-users] [ANN] Chemfiles: chemistry files reading/writing

[Luthaf]

Hi Julians!

My C++ library chemfiles just hit 0.4.0, and won a Julia interface!

Chemfiles is a library providing a consistent interface on the top of 
computational chemistry file formats. These format are the way we store 
data about a molecular simulation (positions, velocities, forces on the 
atoms, ...), and a lot of different formats have been invented to store 
these data. Some are simple text-based formats, other are more complexe, 
or binary format. Chemfiles provide an unique API to deal with all the 
complexity in the chemistry file formats landscape. Chemfiles is written 
in C++, and exposes a stable C interface. On the top of this C interface 
are built the Python, Fortran, Julia and Rust interfaces to chemfiles.


I am aware of a few other attempt at reading/writting trajectory files 
using Julia, specifically :

- https://github.com/christophfeinauer/PdbTool.jl
- https://github.com/wesbarnett/MolecularDynamics.jl
But both of them focus on one format only.

The documentation for the Julia interface is available here: 
http://chemfiles.readthedocs.org/projects/julia/en/latest/, and the main 
C++ lib is documented here : http://chemfiles.readthedocs.org/


I'd love to have some input about the API, because I want to stabilize 
it within the next months.


Cheers,
Luthaf

Re: [julia-users] Re: The growth of Julia userbase

[Luthaf]

These graphs are not available for people who are not (Github) 
collaborator for the julia repository.


Tony Kelman a écrit :
There are some interesting numbers 
at https://github.com/JuliaLang/julia/graphs/traffic


Elliot Saba also did some scraping of the AWS download logs for 
binaries and shared the aggregate numbers (broken down by platform) 
privately with a few people, it may be worth sharing those publicly.



On Wednesday, November 4, 2015 at 8:26:19 AM UTC-8, Ben Ward wrote:

Hi all,

I was wondering are there any metrics or stats available that show
how the user-base of Julia has grown over the last few years, and
what it's size is now?

Many Thanks,
Ben W.

Re: [julia-users] Does the Windows Binary include Python?

[Luthaf]

I guess that is a bug in PyCall, so you should do your bug report there 
: https://github.com/stevengj/PyCall.jl/issues/new. Please ping me 
(@Luthaf) on the issue, because this might be related with Conda.jl


Cheers,
Luthaf

Alex Dowling a écrit:


Hello,

I am helping a colleague debug some errors with the PyPlot in the
Windows binary [Version 0.4.0-rc1 (2015-09-09 16:07 UTC)]. Here are
the error messages:

julia> using Pyplot

INFO: Precompiling module Pyplot...

ERROR: LoadError: PyCall not properly installed. Please run
Pkg.build("PyCall") in error at error.jl:21

while loading C:\Users\Tian\.julia\v0.4\PyCall\src\PyCall.jl, in
expression starting on line 36

ERROR: LoadError: Failed to precompile PyCall to
C:\Users\Tian\.julia\lib\v0.4\PyCall.ji in error at error.jl:21

while loading C:\Users\Tian\.julia\v0.4\Pyplot\src\Pyplot.jl, in
expression starting on line 5

ERROR: Failed to precompile Pyplot to
C:\Users\Tian\.julia\lib\v0.4\Pyplot.ji in error at error.jl:21


julia> Pkg.build("PyCall")

INFO: Building PyCall

INFO: No system-wide Python was found; got the following error:

ErrorException("failed process: Process(`python -c \"import
distutils.sysconfig;

print(distutils.sysconfig.get_config_var('VERSION'))\"`,
ProcessExited(3221225781)) [3221225781]")

using the Python distribution in the Conda package

===[ ERROR: PyCall
]

LoadError: UndefVarError: PYTHONDIR not defined

while loading C:\Users\Tian\.julia\v0.4\PyCall\deps\build.jl, in
expression starting on line 17

 




[ BUILD ERRORS
]

WARNING: PyCall had build errors.

- packages with build errors remain installed in
C:\Users\Tian\.julia\v0.4

- build the package(s) and all dependencies with `Pkg.build("PyCall")`

- build a single package by running its `deps/build.jl` script

 





Shouldn't the Windows binary package include Python, and thus a system
wide install wouldn't be required? The documentation for PyCall (
https://github.com/stevengj/PyCall.jl) suggests it should install
Conda if it can't find Python automatically. If this is a bug, I'd
appreciate advise on whether I should report it in the Julia or PyCall
repositories.


Thanks,

Alex

Re: [julia-users] Re: [ANN] Conda.jl: using conda package manager for Julia

[Luthaf]

I do not want to replace the Base.Pkg package manager. Pkg does install 
binary dependencies in a cross-platform way, but only by the mean of 
BinDeps. And BinDeps uses for that the concept of provider. Some example 
of providers are Hombrew.jl on OSX, Pacman on arch-linux, Yum on 
centos/fedora distro, AptGet on debian distro, WinRPM.jl for windows. 
But all these providers are not cross-platform, and you even need root 
access for using some of the Linux providers (Pacman, Yum, AptGet).


Conda.jl is an other BinDeps provider, which can be used for all 
platforms, effectively replacing any other provider. It can also be used 
without administrator rights on Linux.
So it is not a Base.Pkg replacement, but an other way to get binary 
dependencies installed with it.


I now realize that this was not clear on my initial message, sorry about 
that. I will also improve the README.


Uwe Fechner a écrit :
Julia does have a very good internal package manager, that can also 
install binary dependencies cross-platform.

Why would you want to add another package manager?

Am Dienstag, 1. September 2015 14:42:31 UTC+2 schrieb Luthaf:

Hi Julians!

I am happy to present you the Conda.jl
<https://github.com/Luthaf/Conda.jl> package, a binary
dependencies manager for Julia based on the open-source conda
<http://conda.pydata.org/> package manager.

Some interesting features of the Conda package manager:
 - You can easily add your own software and use your own channel
for software distribution;
 - You can install packages as non root on Linux;
 - Conda is cross-plateforme, and you can use it for all your
binary dependencies, provided the binaries have been uploaded.

I'll love to have your input on the code or the functionalities.

Cheers
Guillaume

Re: [julia-users] Re: [ANN] Conda.jl: using conda package manager for Julia

[Luthaf]

I don't get what you mean. By package, you mean binary package ? In this 
case, there is no Julia central channel (a channel is a package source 
in conda), and you can use your very own by pushing the URL to 
`Conda.CHANNELS` before anything else.


Or if you mean Julia package, Conda is not a Julia package manager. It 
is a binary package provider, for use with BinDeps. It allow to 
distribute C/C++/Fortran libraries with the Julia package.
This is only useful when building a Julia Package which one is calling 
an external C library.


Jeffrey Sarnoff a écrit :
It would help to have explicit examples for adding a package from 
Julia package central (I assume this the default) and adding one from 
some other github location.


On Tuesday, September 1, 2015 at 8:42:31 AM UTC-4, Luthaf wrote:

Hi Julians!

I am happy to present you the Conda.jl
<https://github.com/Luthaf/Conda.jl> package, a binary
dependencies manager for Julia based on the open-source conda
<http://conda.pydata.org/> package manager.

Some interesting features of the Conda package manager:
 - You can easily add your own software and use your own channel
for software distribution;
 - You can install packages as non root on Linux;
 - Conda is cross-plateforme, and you can use it for all your
binary dependencies, provided the binaries have been uploaded.

I'll love to have your input on the code or the functionalities.

Cheers
Guillaume

[julia-users] [ANN] Conda.jl: using conda package manager for Julia

[Luthaf]

Hi Julians!

I am happy to present you the Conda.jl 
<https://github.com/Luthaf/Conda.jl> package, a binary dependencies 
manager for Julia based on the open-source conda 
<http://conda.pydata.org/> package manager.


Some interesting features of the Conda package manager:
 - You can easily add your own software and use your own channel for 
software distribution;

 - You can install packages as non root on Linux;
 - Conda is cross-plateforme, and you can use it for all your binary 
dependencies, provided the binaries have been uploaded.


I'll love to have your input on the code or the functionalities.

Cheers
Guillaume

Re: [julia-users] Type promotion bug?

[Luthaf]

By doing

promote_rule() = 1

And then

Base.promote_rule{T}(::Type{A{T}},::Type{C{T}}) = C{T}

You are defining two different functions. Only the second one is used by 
the promotion system.


The valid code is

abstract B
type A<:B
end

type C<:B
end

Base.promote_rule(::Type{A},::Type{ C}) = C

@assert promote_type(A,C) == C

Sisyphuss a écrit :

In other words, it "won't fix"?

On Wednesday, August 26, 2015 at 6:41:36 AM UTC+2, Stefan Karpinski wrote:

Don't do the first non-base definition.

On Wed, Aug 26, 2015 at 12:27 AM, Sisyphuss 
wrote:

This modification works, but it fails sometimes:

||
abstract B{T}

type A{T}<:B{T}
end

type C{T}<:B{T}
end

promote_rule() = 1
promote_rule()
@assert promote_type(A{Real},C{Real}) == B{Real}

Base.promote_rule{T}(::Type{A{ T}},::Type{C{T}}) = C{T}
@assert promote_type(A{Real},C{Real}) == B{Real}
@assert promote_type(A{Int},C{Int}) == C{Int}

The behavior of `promote_rule` for the abstract parametric
type is disrupted by the earlier weird non-Base
`promote_rule`. (Environment: JuliaBox)

By the way, why I can define `promote_rule`, but when I try to
define `promote_type`, it raises an error?




On Wednesday, August 26, 2015 at 5:25:50 AM UTC+2, Tim Holy wrote:

Add `Base.` in front of `promote_rule`.

--Tim

On Tuesday, August 25, 2015 08:23:40 PM Sisyphuss wrote:
> abstract B
>
> type A<:B
> end
>
> type C<:B
> end
>
> promote_rule(::Type{A},::Type{ C}) = C
>
> @assert promote_type(A,C) == B
>
> Whether I define the promotion_rule or not, the
promote_type is always B.

Re: [julia-users] I need some advise about File IO in Julia

[Luthaf]

I have found this, which is not an official package :
https://github.com/christophfeinauer/PdbTool.jl

Also, I am currently writing a cross-language chemistry files reader 
library (https://github.com/Luthaf/Chemharp/), and I should wrap it to 
Julia soon (this means 2-3 months maximum). It will support PDB file 
through the VMD molfile plugins, but it will not be native Julia.


Regards,
Guillaume

jonny brooks a écrit:


Hey Diego,

Did anything ever come of this? I would like to parse a pdb file with 
julia but there are a real lack of crystallographic/structural biology 
libraries for julia.


Have you written something to read pdb files in native julia?

Re: [julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

That's already way better than the simple and naive version ! On my 
computer, this gives me something 4x slower than serial LAMMPS code.


I'll try to integrate this into the package. It will need changes in the 
data structures, but this is worth it !
I'll have to think a bit about how I can organise the data for 
parallelism. The basic idea is to have every cell on a different 
processor, isn't it ?


Bests,
Guillaume


Amuthan a écrit :
Hi Guillaume: I've added the serial version of the linked-cell MD code 
here: https://gist.github.com/Amuthan


The code is pretty basic and needless to say, a lot more functionality 
needs to be added (though I should admit that I'm more interested in 
extending this code to a parallel version than to develop it as a 
full-fledged MD package). I've made a few changes to make it work for 
your benchmark; I didn't spend too much time optimizing it, but the 
current version is just 7 times slower than the LAMMPS code. I guess 
someone with a better understanding of Julia can optimize it further.


Let me know if you have any comments or questions or suggestions for 
improvement.


Cheers,
Amuthan

On Wed, Jan 28, 2015 at 7:48 AM, Luthaf <mailto:lut...@luthaf.fr>> wrote:


Hi Amuthan,

The current code uses the direct sum because this was the easiest
algorithm to implement, and your understanding is totally correct.

Adding other algorithms is a piece of cake: it is as easy as
subtyping `BaseForceComputer` (I could not came with a better
name), and providing a `call` method.
So I am planning to add at least (serial) Verlet neighbor lists
for the forces computations, and maybe some parallel code.

But I don't know a lot about parallel methods in MD, and I still
have a lot to learn about it. It would definitively be very nice
to have it !
I think that only a few changes are needed to use julia parallel
framework in the package. All the data are stored in objects of
type Array3D, which could be modified to use DArray instead.
I am open to change the internal data structure if this can
improve the performances.

Is your neighbor list code available somewhere ? I am interested
in reading it.

Cheers,
Guillaume

Amuthan A. Ramabathiran a écrit :

Hi Guillaume:

This looks good -- thanks for the package! I have a basic
question regarding the force computation: I had a quick look at
the code and it appears to me that the current code uses an
O(N^2) algorithm (direct sum) for this. Is my understanding
correct? Software like LAMMPS use very efficient algorithms for
short and long range potentials and this might possibly account
for the fact that the benchmark is 80x slower.

I had developed a serial MD code using neighbor lists last year
and I'm currently in the process of parallelizing it to study the
suitability of Julia for developing (reasonably) parallel
research codes. Is parallelization something you're looking into?
I would be very interested in hearing about this. Thanks!

Cheers,
    Amuthan

On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:

Hi julians !

I am very happy to announce the release of Jumos, a Julia
package for molecular simulations.

    You can find the code here:
https://github.com/Luthaf/Jumos.jl, and the documentation is
hosted by readthedocs : http://jumos.readthedocs.org/en/latest/.

This package aims at being as extensible as possible. Every
algorithm is a type that can be subtyped and changed at
runtime, during the simulation.
This makesit easy to write new algorithms, experiment with
them, and combine algorithms in all the fancy waysyou can
imagine.

Presently, only molecular dynamic is implemented, but I am
planning to add energy minimisation, and trajectory replay
from files (maybe monte-carlo simulations if I find some
time). A handful of tools are alreadyimplemented :
- Velocity-Verlet and Verlet integrator;
- Lennard-Jones and Harmonic potential;
- User-defined potentials;
- RDF and density profile analysis;
- Berendsen thermostat;
- Velocity-rescale thermostat;
- Temperature and energy computations.

    And a lot more are planned:
https://github.com/Luthaf/Jumos.jl/issues.
If you want to help, contributions are very welcome ! Just
pick up an issue or create a new one as a feature request.
The first benchmark (against LAMMPS) givesme a speed 80 times
slower than LAMMPS. This is already great for a dynamic
language, but there is still room for improvement !

Any feedback on the implementation is also very welcome.

Regards
Guillaum

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

Hi Amuthan,

The current code uses the direct sum because this was the easiest 
algorithm to implement, and your understanding is totally correct.


Adding other algorithms is a piece of cake: it is as easy as subtyping 
`BaseForceComputer` (I could not came with a better name), and providing 
a `call` method.
So I am planning to add at least (serial) Verlet neighbor lists for the 
forces computations, and maybe some parallel code.


But I don't know a lot about parallel methods in MD, and I still have a 
lot to learn about it. It would definitively be very nice to have it !
I think that only a few changes are needed to use julia parallel 
framework in the package. All the data are stored in objects of type 
Array3D, which could be modified to use DArray instead.
I am open to change the internal data structure if this can improve the 
performances.


Is your neighbor list code available somewhere ? I am interested in 
reading it.


Cheers,
Guillaume

Amuthan A. Ramabathiran a écrit :

Hi Guillaume:

This looks good -- thanks for the package! I have a basic question 
regarding the force computation: I had a quick look at the code and it 
appears to me that the current code uses an O(N^2) algorithm (direct 
sum) for this. Is my understanding correct? Software like LAMMPS use 
very efficient algorithms for short and long range potentials and this 
might possibly account for the fact that the benchmark is 80x slower.


I had developed a serial MD code using neighbor lists last year and 
I'm currently in the process of parallelizing it to study the 
suitability of Julia for developing (reasonably) parallel research 
codes. Is parallelization something you're looking into? I would be 
very interested in hearing about this. Thanks!


Cheers,
Amuthan

On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:

Hi julians !

I am very happy to announce the release of Jumos, a Julia package
for molecular simulations.

You can find the code here: https://github.com/Luthaf/Jumos.jl
<https://github.com/Luthaf/Jumos.jl>, and the documentation is
hosted by readthedocs : http://jumos.readthedocs.org/en/latest/
<http://jumos.readthedocs.org/en/latest/>.

This package aims at being as extensible as possible. Every
algorithm is a type that can be subtyped and changed at runtime,
during the simulation.
This makesit easy to write new algorithms, experiment with them,
and combine algorithms in all the fancy waysyou can imagine.

Presently, only molecular dynamic is implemented, but I am
planning to add energy minimisation, and trajectory replay from
files (maybe monte-carlo simulations if I find some time). A
handful of tools are alreadyimplemented :
- Velocity-Verlet and Verlet integrator;
- Lennard-Jones and Harmonic potential;
- User-defined potentials;
- RDF and density profile analysis;
- Berendsen thermostat;
- Velocity-rescale thermostat;
- Temperature and energy computations.

And a lot more are planned:
    https://github.com/Luthaf/Jumos.jl/issues
    <https://github.com/Luthaf/Jumos.jl/issues>.
If you want to help, contributions are very welcome ! Just pick up
an issue or create a new one as a feature request.
The first benchmark (against LAMMPS) givesme a speed 80 times
slower than LAMMPS. This is already great for a dynamic language,
but there is still room for improvement !

Any feedback on the implementation is also very welcome.

Regards
Guillaume

PS: Whatdoes the ANNin the titlemean ? It seems to be everywhere,
but I don't have any clue about its meaning

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

The two main area of use for this code are
- Teaching molecular simulation, as one have to give the set of 
algorithm they want to use, and can run MD from the REPL.

- Research code, for development of new molecular simulation methods.

It is also fast enough to run post-processing analysis, but not to run 
big simulations on HPC clusters. It would needs parallelisation for this.


Guillaume

Christoph Ortner a écrit :


What are your short-term and long-term aims with this package? A user 
code, teaching code or research code? Do you have specific 
applications in mind?


Christoph

[julia-users] [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

Hi julians !

I am very happy to announce the release of Jumos, a Julia package for 
molecular simulations.


You can find the code here: https://github.com/Luthaf/Jumos.jl, and the 
documentation is hosted by readthedocs : 
http://jumos.readthedocs.org/en/latest/.


This package aims at being as extensible as possible. Every algorithm is 
a type that can be subtyped and changed at runtime, during the simulation.
This makesit easy to write new algorithms, experiment with them, and 
combine algorithms in all the fancy waysyou can imagine.


Presently, only molecular dynamic is implemented, but I am planning to 
add energy minimisation, and trajectory replay from files (maybe 
monte-carlo simulations if I find some time). A handful of tools are 
alreadyimplemented :

- Velocity-Verlet and Verlet integrator;
- Lennard-Jones and Harmonic potential;
- User-defined potentials;
- RDF and density profile analysis;
- Berendsen thermostat;
- Velocity-rescale thermostat;
- Temperature and energy computations.

And a lot more are planned: https://github.com/Luthaf/Jumos.jl/issues.
If you want to help, contributions are very welcome ! Just pick up an 
issue or create a new one as a feature request.
The first benchmark (against LAMMPS) givesme a speed 80 times slower 
than LAMMPS. This is already great for a dynamic language, but there is 
still room for improvement !


Any feedback on the implementation is also very welcome.

Regards
Guillaume

PS: Whatdoes the ANNin the titlemean ? It seems to be everywhere, but I 
don't have any clue about its meaning

Re: [julia-users] Call overloading and @code_... macros

[Luthaf]

I don't know ... Should I try to rebuild julia with LLVM 3.3 ?

Jameson Nash a écrit :
Maybe llvm has now turned on code relocation on MachO? If so, I just 
need to flip a switch in the code to fix this.
On Mon, Jan 26, 2015 at 3:30 AM Luthaf <mailto:lut...@luthaf.fr>> wrote:


I am using the latest master, on OS X 10.9, with LLVM svn

julia> versioninfo()
Julia Version 0.4.0-dev+2914
Commit 4c3e03b (2015-01-26 06:17 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-svn

Jameson Nash a écrit :

what's your julia version and OS? code_native shouldn't be doing
that anymore (https://github.com/JuliaLang/julia/issues/7910)

On Sun Jan 25 2015 at 6:00:49 PM Luthaf mailto:lut...@luthaf.fr>> wrote:

The @code_llvm, @code_native and @code_lowered macros (but
not the @code_typed) macro behavior does not feels right with
the call overloading syntax:

julia> type Foo end

julia> Base.call(::Foo, x) = x + 4
call (generic function with 891 methods)

julia> f = Foo()
Foo()

julia> @code_llvm f(3)
ERROR: MethodError: `code_llvm` has no method matching
code_llvm(::Foo, ::Type{(Int64,)})
Closest candidates are:
  code_llvm(::Function, ::(Type{T<:Top}...,))

 in __text at no file (repeats 3 times)

I know I can use the call(::Foo, x) form, but this fails with
the @code_native macro :

julia> @code_llvm call(f, 3)

define i64 @julia_call_43695(%jl_value_t*, i64) {
top:
  %2 = add i64 %1, 4, !dbg !8
  ret i64 %2, !dbg !8
}

julia> @code_native call(f, 3)
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
.section__TEXT,__text,regular,pure_instructions
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp

Is this an issue, or is this the intended behavior ?

Regards,
Guillaume

Re: [julia-users] Call overloading and @code_... macros

[Luthaf]

I am using the latest master, on OS X 10.9, with LLVM svn

julia> versioninfo()
Julia Version 0.4.0-dev+2914
Commit 4c3e03b (2015-01-26 06:17 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-svn

Jameson Nash a écrit :
what's your julia version and OS? code_native shouldn't be doing that 
anymore (https://github.com/JuliaLang/julia/issues/7910)


On Sun Jan 25 2015 at 6:00:49 PM Luthaf <mailto:lut...@luthaf.fr>> wrote:


The @code_llvm, @code_native and @code_lowered macros (but not the
@code_typed) macro behavior does not feels right with the call
overloading syntax:

julia> type Foo end

julia> Base.call(::Foo, x) = x + 4
call (generic function with 891 methods)

julia> f = Foo()
Foo()

julia> @code_llvm f(3)
ERROR: MethodError: `code_llvm` has no method matching
code_llvm(::Foo, ::Type{(Int64,)})
Closest candidates are:
  code_llvm(::Function, ::(Type{T<:Top}...,))

 in __text at no file (repeats 3 times)

I know I can use the call(::Foo, x) form, but this fails with the
@code_native macro :

julia> @code_llvm call(f, 3)

define i64 @julia_call_43695(%jl_value_t*, i64) {
top:
  %2 = add i64 %1, 4, !dbg !8
  ret i64 %2, !dbg !8
}

julia> @code_native call(f, 3)
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
.section__TEXT,__text,regular,pure_instructions
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp

Is this an issue, or is this the intended behavior ?

Regards,
Guillaume

[julia-users] Call overloading and @code_... macros

[Luthaf]

The @code_llvm, @code_native and @code_lowered macros (but not the 
@code_typed) macro behavior does not feels right with the call 
overloading syntax:


julia> type Foo end

julia> Base.call(::Foo, x) = x + 4
call (generic function with 891 methods)

julia> f = Foo()
Foo()

julia> @code_llvm f(3)
ERROR: MethodError: `code_llvm` has no method matching code_llvm(::Foo, 
::Type{(Int64,)})

Closest candidates are:
  code_llvm(::Function, ::(Type{T<:Top}...,))

 in __text at no file (repeats 3 times)

I know I can use the call(::Foo, x) form, but this fails with the 
@code_native macro :


julia> @code_llvm call(f, 3)

define i64 @julia_call_43695(%jl_value_t*, i64) {
top:
  %2 = add i64 %1, 4, !dbg !8
  ret i64 %2, !dbg !8
}

julia> @code_native call(f, 3)
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
error: failed to compute relocation: X86_64_RELOC_UNSIGNED
.section__TEXT,__text,regular,pure_instructions
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp
pushrbp

Is this an issue, or is this the intended behavior ?

Regards,
Guillaume

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

[Luthaf]

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


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


Viral Shah a écrit :

I wonder what the 500th package will be.

-viral

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

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

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

Re: [julia-users] Re: Community Support for Julia on Travis CI

[Luthaf]

Can it be possible to add some kind of support for code coverage ?

I use this package (https://github.com/IainNZ/Coverage.jl) which seems 
to be a standard one in Julia.


For now I use a custom script in my .tramis.yml file, but the only 
modification in the build script is

|julia -e 'Pkg.test("MyPkg", coverage=true)'|
vs the official
|julia -e 'Pkg.test("MyPkg")'|
so why not make this coverage=true the default ? To enable the 
coverall.io output, one would then only have to add


after_success:
-julia -e 'cd(Pkg.dir("MyPkg")); Pkg.add("Coverage"); using Coverage; 
Coveralls.submit(Coveralls.process_folder())'

In their .tramis.yml file. Or there can be a special syntax for that if 
needed.


Guillaume

Pontus Stenetorp a écrit :

On 12 December 2014 at 00:28, Stefan Karpinski  wrote:

Btw, can I be added to the JuliaCI org?


No idea who, but someone has taken care of it.  If someone else wants
to join, just give us a poke.

On 12 December 2014 at 00:49, Nils Gudat  wrote:

Excuse the ignorant question, but what exactly does this mean? I haven't
seen Travis CI before and clicking on the home page is slightly confusing...


Ignorance is fine, at least in academia you need some of it in order
to accomplish anything.  I agree that the homepage is a mess,
essentially they have a bunch of virtual servers that check if you
have a pending pull request or made a push to your repository.  Once
this happens they will pull the code from GitHub and build/run tests
on their machines to check that everything is all right.  If something
is wrong, you will get an e-mail/notification on GitHub.  This enables
you to test against multiple versions of Julia and saves you the time
to pull code from other people to test locally on your machine before
accepting pull requests.  It is worth pointing out that I am by no
means a testing fanatic, but I still really enjoy the service that
Travis provide.

 Pontus

[julia-users] error initializing module LinAlg

[Luthaf]

Hello !

I get a strange error on the latest Julia Master. After launching the 
make install command, I get a warning on startup :


$ julia
Warning: error initializing module LinAlg:
ErrorException("symbol could not be found openblas_get_config64_: 
dlsym(0x7f9ae3769890, openblas_get_config64_): symbol not found

")
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+1971 (2014-12-06 22:54 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit b83e4bb (0 days old master)
|__/   |  x86_64-apple-darwin13.4.0

julia> versioninfo()
Julia Version 0.4.0-dev+1971
Commit b83e4bb (2014-12-06 22:54 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
  WORD_SIZE: 64
ERROR: symbol could not be found openblas_get_config64_: 
dlsym(0x7f9ae3769890, openblas_get_config64_): symbol not found


 in openblas_get_config at ./util.jl:120
 in versioninfo at interactiveutil.jl:176
 in versioninfo at interactiveutil.jl:146

My Make.user file only contains PREFIX=/usr/local/. This warning/error 
goes out if I start julia directly from the build folder :


julia> versioninfo()
Julia Version 0.4.0-dev+1971
Commit b83e4bb (2014-12-06 22:54 UTC)
DEBUG build
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Should I fill an issue about this, or have I messed something while 
building Julia ?


Regards,
Guillaume

Re: [julia-users] try/catch by exception type

[Luthaf]

Ok, thank you !

So the way to go is "better ask for permission than for forgiveness" !

John Myles White a écrit :

I don't believe this is possible in Julia right now.

Which is ok in this case, since working with a KeyError is a very un-Julian way 
to check for key existence. You'll want to use haskey instead.

  -- John

On Nov 17, 2014, at 2:49 PM, Luthaf  wrote:


Hello !

Is there a way to catch an exception by type in Julia ? Coming from python, I 
am very tempted to do this kind of things:
```
try
# Access a dict here
catch e
if isa(KeyError, e)
# Handle the KeyError, as I know what to do in that case
else
# Re-throw to upper level
throw(e)
end
```
But that is a lot of boilerplate when used many times.

Maybe it is not the Julia way to express this kind of problem (handling one 
type of exception, while letting the others go up), but I could not find 
something about it.
I can not just remove all the exceptions as some of them are thrown by Base.


Thank for yours answers !
Guillaume

[julia-users] try/catch by exception type

[Luthaf]

Hello !

Is there a way to catch an exception by type in Julia ? Coming from 
python, I am very tempted to do this kind of things:

```
try
# Access a dict here
catch e
if isa(KeyError, e)
# Handle the KeyError, as I know what to do in that case
else
# Re-throw to upper level
throw(e)
end
```
But that is a lot of boilerplate when used many times.

Maybe it is not the Julia way to express this kind of problem (handling 
one type of exception, while letting the others go up), but I could not 
find something about it.

I can not just remove all the exceptions as some of them are thrown by Base.


Thank for yours answers !
Guillaume

Re: [julia-users] example for ccall use and fortran

[Luthaf]

The first way to compile is the good one, but gfortran is slightly 
changing the names of the function. You can see it by running the `nm` 
command :

```
$ nm simplemodule.so
0f98 T ___simplemodule_MOD_foo
```

So you have to call `__simplemodule_MOD_foo`  from Julia side (yes, with 
one underscore less. I don't know why ...)


```
julia> ccall((:__simplemodule_MOD_foo, "simplemodule.so"), Int32, 
(Int32,), 3)

```

This will also lead to a segfault, as Fortran except values to be passed 
by reference, and not by value. So the final call is


```
julia>ccall((:__simplemodule_MOD_foo, "simplemodule.so"), Int32, 
(Ptr{Int32},), &3)

   6
```

Regards,
Guillaume

Andre Bieler a écrit :

tried calling a simple fortran function from julia but did not succeed:
this is the fortran code:

||
!fileName =simplemodule.f95
modulesimpleModule

contains
functionfoo(x)
  integer ::foo,x
  foo =x *2
endfunctionfoo


endmodulesimplemodule


which is then compiled with:

*gfortran simplemodule.f95 -o simplemodule.so -shared -fPIC*

and finally the julia call is:

||

ccall((:foo,"/fullPathTo/simpleMod.so"),Int32,(Int32,),3)


which then leads to the following error:

ERROR: ccall: could not find function foo in library 
/fullPathTo/simpleMod.so

 in anonymous at no file



when compiling with:

gfortran -c simplemodule.f95 -o simplemodule.so -shared -fPIC

i get a different error:

*ERROR: error compiling anonymous: could not load module 
/fullPathTo/simplemodule.so: /fullPathTo/simplemodule.so:*

*only ET_DYN and ET_EXEC can be loaded*



Can anyone tell me what I am missing?
I do realize I would not need to call fortran to multiply a variable 
by 2, but its a starting point..



Thanks!
Andre