[julia-users] calling c functions from dll works in Juno but not Julia REPL

Hi, I have created a c shared library using visual-studio; then I called the c functions in Juno IDE, everything worked as expected. Then I installed the julia command line version, and ran the same script again, and this time it seems that the c functions has not been called properly, no excep

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

en introduced by a > backport or something similar. > > On 3 April 2015 at 05:50, Kevin Squire > > wrote: > >> Hi Siyi, >> >> Can you give a short example of your code? It's generally pretty hard to >> debug these things without that. >> >> Ch

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

Thursday, April 2, 2015 at 9:50:46 PM UTC-7, Kevin Squire wrote: > > Hi Siyi, > > Can you give a short example of your code? It's generally pretty hard to > debug these things without that. > > Cheers! >Kevin > > On Thursday, April 2, 2015, Siyi Deng >

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

file that as an issue on the Julia repo? > > On 3 April 2015 at 15:09, Siyi Deng > > wrote: > >> Hi Mike: >> I followed your suggestion , the Julia version used by Juno was 0.3.4 and >> the standalone REPL was 0.3.7 (all x86_64-w64-mingw32), so indeed it seems &g

[julia-users] Re: calling c functions from dll works in Juno but not Julia REPL

It turns out that julia 0.3.4 didn't enforce immutable in ccalls, and I should be using mutable types to store states. Thanks for the help everybody! On Thursday, April 2, 2015 at 7:28:16 PM UTC-7, Siyi Deng wrote: > > Hi, > I have created a c shared library using visual-studio;

[julia-users] Julia stuck at large floating point number array from source code

Hi, I have a coefficient array which looks like b = [4.67933552111843e-07,-6.32591924726271e-05,-0.000160070579209537, ], with about 320 elements. The entire array in ascii is about 7000 chars. I cannot paste the array directly in REPL, julia simply stuck. I cannot put it in a script and i

Re: [julia-users] Julia stuck at large floating point number array from source code

Mon, Apr 13, 2015 at 10:49 PM, Siyi Deng > wrote: > >> Hi, I have a coefficient array which looks like b = >> [4.67933552111843e-07,-6.32591924726271e-05,-0.000160070579209537, ], >> with about 320 elements. The entire array in ascii is about 7000 chars. >> >

Re: [julia-users] Julia stuck at large floating point number array from source code

without seeing exactly what you're running. > > On Mon, Apr 13, 2015 at 9:37 PM, Siyi Deng > wrote: > >> No, I'm copy and pasting the array, from a text editor to the REPL, and >> it hangs there. >> >> On Monday, April 13, 2015 at 7:53:29 PM UTC-7, Stef

Re: [julia-users] Julia stuck at large floating point number array from source code

; > On Tue, Apr 14, 2015 at 12:36 AM, Siyi Deng > wrote: > >> Hi, my array as follows: >> >> >> b = >> [4.67933552111843e-07,-6.32591924726271e-05,-0.000160070579209537,-0.000332845978767382,-0.000588690359282295, >> >>

[julia-users] I feel that on the syntax level, Julia sacrificed too much elegancy trying to be compatible with textbook math notations

numpy arrays operate element-wise by default, and have broadcasting (binary singleton expansion) behaviors by default. in julia you have to do (.> , .<, .==) all the time.

[julia-users] Re: I feel that on the syntax level, Julia sacrificed too much elegancy trying to be compatible with textbook math notations

I tend to agree that explicit broadcasting is better than numpy's default behavior. However, IMO operations on the n-d arrays is better defaulted to element-wise, and n-d with scalar default to element-wise too. Think about it, a lot of operations are not even commonly defined for 3-d and abov

[julia-users] Re: Why does julia use END for block end?

Well said. +1. On Saturday, May 7, 2016 at 1:49:16 AM UTC-7, DNF wrote: > > I find 'end' to be the best choice of block terminator among the ones I > have seen. > > It is very clear and explicit, there is no doubt as to what it means, > unlike '}' which is way too small and ambiguous (does it m

[julia-users] Uniform syntax

I am neutral about 1 and 2. But I like suggestion 3.