[julia-users] Re: jump ahead in Mersenne Twister

[Joaquim Masset Lacombe Dias Garcia]

 Thanks Dan,

I will try using the dSFMTjump lib!

best,

[julia-users] How to save an object of a defined type

[varun7rs]

I have a module defined as module *Core* within which I have defined 
several types (*Node*, *Edge*, *Res*). Now what I intend to do is that I 
want to save the output of a function which is an object (*res1*) of type 
*Res* onto a JLD file so that I can retrieve it later on. I am calling the 
function iteratively and hence at each iteration, I would like to store the 
object in the JLD file. I'm not sure how the syntax of this snippet is but 
here is my attempt at it

using HDF5, JLD
>> z = jldopen("sample.jld", "w")
>> write(z, "res1", res1)
>>
>>
>>
Can you please correct my code? I tried the code on the terminal but I get 
an error for the very first line saying 

HDF5-DIAG: Error detected in HDF5 (1.8.11) thread 140049981197376:
  #000: ../../../src/H5F.c line 1504 in H5Fcreate(): unable to create file
major: File accessibilty
minor: Unable to open file
  #001: ../../../src/H5F.c line 1307 in H5F_open(): unable to truncate a 
file which is already open
major: File accessibilty
minor: Unable to open file

Re: [julia-users] A "two-languages" problem when embedding Julia

[Cristóvão Duarte Sousa]

Thanks Yichao, and thank you very much for the links.

On Saturday, October 22, 2016 at 5:38:58 PM UTC+1, Yichao Yu wrote:
>
> On Sat, Oct 22, 2016 at 12:26 PM, Cristóvão Duarte Sousa 
>  wrote: 
> > Thanks, Yichao. 
> > 
> > Rereading my first question and reading your second answer I think may 
> have 
> > been not clear in the first one. 
> > In the first question, I wanted to ask not about the current state but 
> > rather about the future goal of the development. 
> > Is your "no" about the current state or are you saying it is not a 
> future 
> > goal at all? 
>
> It's "no" in that I don't think anyone is working on it or planning to 
> work on it so it's not part of "current thread support development". 
> We'll likely add that later but the first "stable" version of 
> threading support will unlikely support that. 
>
> Relevant issues, https://github.com/JuliaLang/julia/issues/16134 and 
> (more accurately) https://github.com/JuliaLang/julia/issues/17573 
>
> > 
> > 
> > On Saturday, October 22, 2016 at 4:37:18 PM UTC+1, Yichao Yu wrote: 
> >> 
> >> 
> >>> Now, let me ask two questions. 
> >>> - Will the current thread support development allow embedding Julia 
> into 
> >>> multiple threads (even if it is as multiple instances)? 
> >> 
> >> 
> >> No. 
> >> 
> >>> 
> >>> - What are my options **today**, if any, to somehow overcome this 
> >>> limitation? 
> >> 
> >> 
> >> You can only call julia runtime/code from a single thread and this is 
> >> unlikely to change until we have non-experimental threading support. 
> How you 
> >> serialize calls to julia code or whether that's feasible is strongly 
> >> application dependent. 
> >> 
> >>> 
> >>> 
> >>> Thanks. 
> >> 
> >> 
> > 
>

Re: [julia-users] A "two-languages" problem when embedding Julia

[Yichao Yu]

On Sat, Oct 22, 2016 at 12:26 PM, Cristóvão Duarte Sousa
 wrote:
> Thanks, Yichao.
>
> Rereading my first question and reading your second answer I think may have
> been not clear in the first one.
> In the first question, I wanted to ask not about the current state but
> rather about the future goal of the development.
> Is your "no" about the current state or are you saying it is not a future
> goal at all?

It's "no" in that I don't think anyone is working on it or planning to
work on it so it's not part of "current thread support development".
We'll likely add that later but the first "stable" version of
threading support will unlikely support that.

Relevant issues, https://github.com/JuliaLang/julia/issues/16134 and
(more accurately) https://github.com/JuliaLang/julia/issues/17573

>
>
> On Saturday, October 22, 2016 at 4:37:18 PM UTC+1, Yichao Yu wrote:
>>
>>
>>> Now, let me ask two questions.
>>> - Will the current thread support development allow embedding Julia into
>>> multiple threads (even if it is as multiple instances)?
>>
>>
>> No.
>>
>>>
>>> - What are my options **today**, if any, to somehow overcome this
>>> limitation?
>>
>>
>> You can only call julia runtime/code from a single thread and this is
>> unlikely to change until we have non-experimental threading support. How you
>> serialize calls to julia code or whether that's feasible is strongly
>> application dependent.
>>
>>>
>>>
>>> Thanks.
>>
>>
>

Re: [julia-users] A "two-languages" problem when embedding Julia

[Cristóvão Duarte Sousa]

Thanks, Yichao.

Rereading my first question and reading your second answer I think may have 
been not clear in the first one.
In the first question, I wanted to ask not about the current state but 
rather about the future goal of the development.
Is your "no" about the current state or are you saying it is not a future 
goal at all?

On Saturday, October 22, 2016 at 4:37:18 PM UTC+1, Yichao Yu wrote:
>
>
> Now, let me ask two questions.
>> - Will the current thread support development allow embedding Julia into 
>> multiple threads (even if it is as multiple instances)?
>>
>
> No.
>  
>
>> - What are my options **today**, if any, to somehow overcome this 
>> limitation?
>>
>
> You can only call julia runtime/code from a single thread and this is 
> unlikely to change until we have non-experimental threading support. How 
> you serialize calls to julia code or whether that's feasible is strongly 
> application dependent.
>  
>
>>
>> Thanks.
>>
>
>

Re: [julia-users] A "two-languages" problem when embedding Julia

[Yichao Yu]

> Now, let me ask two questions.
> - Will the current thread support development allow embedding Julia into
> multiple threads (even if it is as multiple instances)?
>

No.


> - What are my options **today**, if any, to somehow overcome this
> limitation?
>

You can only call julia runtime/code from a single thread and this is
unlikely to change until we have non-experimental threading support. How
you serialize calls to julia code or whether that's feasible is strongly
application dependent.


>
> Thanks.
>

[julia-users] A "two-languages" problem when embedding Julia

[Cristóvão Duarte Sousa]

I would like to get some advice on how to integrate Julia into an existing 
application written in C++.
I mainly work in image processing and computer vision applications.

May traditional way of working is to do the exploratory prototyping in a 
high-level language, and then, when algorithms stabilize, rewrite them in 
C++ (using a lot of OpenCV, Eigen, etc.). Then the algorithms would be 
easily integrated into the main C++ application.

One of the main aspects that attracted me to Julia was the possibility of 
conduction exploratory research in a language and then evolve to a final 
high-performance code without having to rewrite in another language. Thus 
solving what I may call the "standard" two-languages problem.

But now, after starting to develop algorithms in Julia, I'm facing an 
unexpected problem.
I really need to have my applications written in C++: heavy use of OpenGL, 
CUDA, real-time, multi-thread, low-level stuff, etc.; besides the 
application having a well-established source code base.
The problem arises when I tried to embed Julia into these C++ applications.
For example, in a certain application, I would like to run a small fast 
piece of Julia code in a "quasi-real-time" fashion within one thread, and 
at the same time, in another thread, run a heavy Julia algorithm in a 
sporadic fashion.
This has shown to be impossible due to Julia threading limitations (which I 
understand that come from code generation, GC, and Julia dependency 
libraries).

This is what I may call the other face of the two-languages problem. With 
the traditional approach, the rewriting can solve the two faces of the 
problem, improve performance and at the same enable a better integration 
into a library or an application.

Now, let me ask two questions.
- Will the current thread support development allow embedding Julia into 
multiple threads (even if it is as multiple instances)?
- What are my options **today**, if any, to somehow overcome this 
limitation?

Thanks.

[julia-users] Re: Does Julia support Integer literal suffix like 1234L or 1234U

[Scott T]

You could take advantage of implicit multiplication to define this yourself:

julia> type ShortLiteral end; const S = ShortLiteral();

julia> type LongLiteral end; const L = LongLiteral();

julia> Base.:*(x::Integer, ::ShortLiteral) = Int32(x)

julia> Base.:*(x::Integer, ::LongLiteral) = Int64(x)

julia> 1234S
1234

julia> 1234L
1234

julia> typeof(1234S)
Int32

julia> typeof(1234L)
Int64



On Saturday, 22 October 2016 12:23:29 UTC+1, FANG Colin wrote:
>
> Just wondering if Julia has any integer literal suffix support?
>
> So we don't have to write Int64(1234) or Int32(1234) in a long expression 
> containing constants, but use 1234L or 1234S instead.
>

[julia-users] Does Julia support Integer literal suffix like 1234L or 1234U

[FANG Colin]

Just wondering if Julia has any integer literal suffix support?

So we don't have to write Int64(1234) or Int32(1234) in a long expression 
containing constants, but use 1234L or 1234S instead.

[julia-users] Re: Benchmarking workflow

[Christoph Ortner]

Have a look at `JuMOS`, `QuantumLab.jl` and `JuLIP.jl`, it would be nice to 
coordinate rather than develop multiple molecular simulation packages.