[julia-users] Re: jump ahead in Mersenne Twister
Thanks Dan, I will try using the dSFMTjump lib! best,
[julia-users] How to save an object of a defined type
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
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
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
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
> 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
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
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
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
Have a look at `JuMOS`, `QuantumLab.jl` and `JuLIP.jl`, it would be nice to coordinate rather than develop multiple molecular simulation packages.
