Sorry, that was on me: https://github.com/JuliaPy/PyCall.jl/issues/320
Still, since this thread wasn't resolved, it may be a good thing if this
gets exposed to more eyes, since other people may have (or have had) the
same problem, and could comment confirming its resolution, or that it still
I run Julia through repl. The procedure is simple: include("myfile.jl"),
then run myfunction() (I might do a Ctrl-C to interrupt the function), edit
something in myfile.jl, then repeat. Initially, julia processes normally
take less than 10% RAM, then after some time, one main Julia process
On Sun, Sep 18, 2016 at 8:53 AM, K leo wrote:
> I run Julia through repl. The procedure is simple: include("myfile.jl"),
> then run myfunction() (I might do a Ctrl-C to interrupt the function), edit
> something in myfile.jl, then repeat. Initially, julia processes normally
>
Just because you are calling two functions doesn't mean it is slow. Have
you benchmarked?
On Sunday, September 18, 2016 at 11:55:47 AM UTC+2, K leo wrote:
>
> I have been using simply A=[0; A[1:end-1]], but found it to be somehow
> quite expensive. I saw that there is unshift! but it has to
Já existe um grupo/canal do gitter: https://gitter.im/JuliaLangPt/julia ---
eu sugeria não fragmentarmos a comunidade, que é bem pequena, com um novo
canal de comuncação (até porque esse canal no gitter está ligado a uma
organização do github: https://github.com/JuliaLangPt)
On Tuesday,
See ntoh and hton. Perhaps even better, see StrPack.jl.
--Tim
On Sunday, September 18, 2016 1:13:43 AM CDT Femto Trader wrote:
> Hello,
>
> I'd like to read this file
> http://www.dukascopy.com/datafeed/EURUSD/2016/02/14/20h_ticks.bi5
> using Julia.
>
> It's a LZMA compressed file.
>
> I can
I am also wondering what information I should look into.
On Sunday, September 18, 2016 at 9:30:00 PM UTC+8, Yichao Yu wrote:
>
>
> Impossible to tell without any information provided.
>
Hello,
I'd like to read this file
http://www.dukascopy.com/datafeed/EURUSD/2016/02/14/20h_ticks.bi5
using Julia.
It's a LZMA compressed file.
I can decompressed it using
cp 20h_ticks.bi5 20h_ticks.xz
xz --decompress --format=lzma 20h_ticks.xz
Now, I have a 20h_ticks binary file.
It's a
I have been using simply A=[0; A[1:end-1]], but found it to be somehow
quite expensive. I saw that there is unshift! but it has to be followed up
with deleteat! to make the array the same size, i.e. there need to be two
operations. So how can I get a better performance doing the shift?
On Sunday, September 18, 2016 2:55:46 AM CDT K leo wrote:
> I have been using simply A=[0; A[1:end-1]], but found it to be somehow
> quite expensive. I saw that there is unshift! but it has to be followed up
> with deleteat! to make the array the same size, i.e. there need to be two
> operations.
You should also benchmark the simple for loop. Please report back with the
results.
Thanks a lot, Jeffrey! Incredibly, this worked.
Best,
Michael
On Fri, Sep 16, 2016 at 6:48 PM, Jeffrey Sarnoff
wrote:
> I have had this happen, too. My suggestion is grounded in persistence
> rather than deep mastery of Julia's structural and file relationships.
>
I think it's ok now...
https://github.com/femtotrader/DataReaders.jl/issues/14
but I'm still blocked because of LZMA compression
see https://github.com/yuyichao/LibArchive.jl/issues/2
and my
question https://groups.google.com/forum/#!topic/julia-users/G9Pqe5svS3c
Any help will be great.
Le
On Sun, Sep 18, 2016 at 9:36 AM, K leo wrote:
> I am also wondering what information I should look into.
>
> On Sunday, September 18, 2016 at 9:30:00 PM UTC+8, Yichao Yu wrote:
>>
>>
>> Impossible to tell without any information provided.
At least show what your code looks
This sounds like it may have been a download issue or a corrupt repo,
and/or a bug in any fallback code that Pkg might contain to attempt to deal
with problems in cloning. If you can reproduce it reliably, would be
valuable to report the sequence of steps you used to get into the error
state.
OK, ran a test. And the difference is pretty dramatic. Look:
| | |_| | | | (_| | | Version 0.5.0-rc4+0 (2016-09-09 01:43 UTC)
_/ |\__'_|_|_|\__'_| | Official http://julialang.org/ release
|__/ | x86_64-pc-linux-gnu
julia> include("testArray.jl")
julia> testShift()
On Sun, Sep 18, 2016 at 9:50 AM, Femto Trader wrote:
> I'm still blocked
> https://github.com/yuyichao/LibArchive.jl/issues/2
> Any help is welcome.
>
As I said, you shouldn't require a IOStream, it basically means that
you can't support anything other than a raw file
I'm still blocked
https://github.com/yuyichao/LibArchive.jl/issues/2
Any help is welcome.
Le samedi 17 septembre 2016 18:54:48 UTC+2, Femto Trader a écrit :
>
> Thanks I will have a look
>
> Le samedi 17 septembre 2016 16:18:34 UTC+2, Tony Kelman a écrit :
>>
>> Your best bet is probably
Não sabia da existência, tinha criado pois não conhecia nenhum, vou
informar aos que já estão cadastrados no novo para irem para o do gitter. :D
No dia 18 de setembro de 2016 às 08:16, Waldir Pimenta <
waldir.pime...@gmail.com> escreveu:
> Já existe um grupo/canal do gitter:
I'd like to access global variables from the default values of keywords
arguments, e.g.:
x = 3
function f(;x=x) #<- this default value of x here should refer to x in the
global scope which is 3
...
end
Is there any way to do this? I had guessed the following might work but it
doesn't:
On Sunday, September 18, 2016 at 5:31:19 PM UTC-4, Marius Millea wrote:
>
> I'd like to access global variables from the default values of keywords
> arguments, e.g.:
>
> x = 3
> function f(;x=x) #<- this default value of x here should refer to x in
> the global scope which is 3
>
I think
See also https://github.com/JuliaLang/julia/issues/9535
I just updated my codebase to 0.5, and encountered a strange bug. I have
two tests, test 1 and 2, both wrapped in their own modules so as not to
interact. Both tests run fine from a fresh Julia session, but running test
1 before test 2 yields "TypeError: non-boolean (Bool) used in boolean
Hi,
I seem to have run into a problem here. I firstly have a function as
follows:
function gen(type, frame1, frame2)
x = frame1[:type]
z = frame2[:type]
y = []
for i in length(frame1)
push!(y, x[i] * z[i])
end
end
Now, when I call: ans = gen(I, frame1, frame2), I get a
As a work-around, you can define a function `getx() = (global x; x)`, and
use it to access the global variable x.
-erik
On Sun, Sep 18, 2016 at 5:31 PM, Marius Millea
wrote:
> I'd like to access global variables from the default values of keywords
> arguments, e.g.:
>
>
On Sun, Sep 18, 2016 at 6:29 PM, Cedric St-Jean wrote:
> I just updated my codebase to 0.5, and encountered a strange bug. I have two
> tests, test 1 and 2, both wrapped in their own modules so as not to
> interact. Both tests run fine from a fresh Julia session, but
Thank you, loading all the modules up-front solved the problem. I'm
surprised that the compiler can make false assumptions about types without
triggering segfaults left and right.
On Sunday, September 18, 2016 at 6:51:22 PM UTC-4, Yichao Yu wrote:
>
> On Sun, Sep 18, 2016 at 6:29 PM, Cedric
Sorry about that. I was able to fix the error by changing x = frame[:type]
to x = frame[type]
Apologies for the trouble caused
On Sunday, 18 September 2016 22:45:27 UTC+2, varu...@gmail.com wrote:
>
>
> Hi,
>
> I seem to have run into a problem here. I firstly have a function as
> follows:
>
>
28 matches
Mail list logo