[julia-users] Re: ANN: CloudArray.jl: Easy Big Data programming in the Cloud

[André Lage]

PS: Here it goes a IJulia Notebook with some examples to use at
http://cloudarraybox.cloudapp.net:

https://github.com/gsd-ufal/CloudArray.jl/blob/master/docs/cloudarray.ipynb


André Lage.

On Fri, Oct 30, 2015 at 12:13 AM, André Lage  wrote:

> Dear Julia community,
>
> We are proud to announce the very first release of *CloudArray.jl*
> , a programming support that
> eases big data programming in the cloud. CloudArray loads data from files
> and books the right amount of virtual machines (VMs) able to process it.
> Data loading and VM management are entirely automatic and performed
> on-demand.
>
> CloudArray builds on top of Julia DistributedArrays. Indeed, a CloudArray
> is a DistributedArray whose data and VM managements are automatic: data
> load, resource booking and allocation. Therefore, existent codes that use
> DistributedArrays don't need to be adapted in order to use CloudArray: just
> use CloudArray and configure your cloud authentication settings.
>
> If you are interested in CloudArray, please *try it for free at our Azure
> VMs *. If you need any help, you can
> write to this list or send me an e-mail (prof.alage at gmail.com) that
> we'll be glad to help you in developing your distributed application in the
> cloud with CloudArray.
>
> CloudArray and CloudArrayBox are research prototypes which intend to be a
> contribution to DistributedArrays and JuliaBox, not a replacement of them
> at all. We intend in the future to pull requests to JuliaBox and Julia
> Parallel communities as CloudArray code evolves. We also would like to
> thank Julia developers and community for the great work. It's amazing how
> Julia puts together high-level programming and efficiency, Julia really
> inspired us in designing and implementing CloudArray.
>
> Moreover, we are open to work with Julia community, so please fell free to
> propose any improvements or to pull requests to CloudArray code. CloudArray
> roadmap 
> includes interesting features such as: support for Amazon EC2, OpenStack;
> allow to set a price threshold; provide different QoS (SLA).
>
> We are looking forward to getting feedback from you.
>
> Sincerely,
>
>
> André Lage.
> Ph.D. in Computer Science
> https://sites.google.com/a/ic.ufal.br/andrelage/home/cv
>

[julia-users] Re: no one knows this.....

[Steven G. Johnson]

A direct translation of the Python code works fine for me (with the default 
TkAgg backend on MacOS):

one = figure(1)
plot(1:4)
two = figure(2)
scatter(randn(25),randn(25))
figure(1)
title("Title")

wm = get_current_fig_manager()
wm[:window][:attributes]("-topmost", 1)
wm[:window][:attributes]("-topmost", 0)


Everyone using PyPlot and PyCall should read this sentence from the PyCall 
README five times:

The biggest diffence from Python is that object attributes/members are 
accessed with o[:attribute] rather than o.attribute

[julia-users] ANN: CloudArray.jl: Easy Big Data programming in the Cloud

[André Lage]

Dear Julia community,

We are proud to announce the very first release of *CloudArray.jl*
, a programming support that
eases big data programming in the cloud. CloudArray loads data from files
and books the right amount of virtual machines (VMs) able to process it.
Data loading and VM management are entirely automatic and performed
on-demand.

CloudArray builds on top of Julia DistributedArrays. Indeed, a CloudArray
is a DistributedArray whose data and VM managements are automatic: data
load, resource booking and allocation. Therefore, existent codes that use
DistributedArrays don't need to be adapted in order to use CloudArray: just
use CloudArray and configure your cloud authentication settings.

If you are interested in CloudArray, please *try it for free at our Azure
VMs *. If you need any help, you can
write to this list or send me an e-mail (prof.alage at gmail.com) that
we'll be glad to help you in developing your distributed application in the
cloud with CloudArray.

CloudArray and CloudArrayBox are research prototypes which intend to be a
contribution to DistributedArrays and JuliaBox, not a replacement of them
at all. We intend in the future to pull requests to JuliaBox and Julia
Parallel communities as CloudArray code evolves. We also would like to
thank Julia developers and community for the great work. It's amazing how
Julia puts together high-level programming and efficiency, Julia really
inspired us in designing and implementing CloudArray.

Moreover, we are open to work with Julia community, so please fell free to
propose any improvements or to pull requests to CloudArray code. CloudArray
roadmap 
includes interesting features such as: support for Amazon EC2, OpenStack;
allow to set a price threshold; provide different QoS (SLA).

We are looking forward to getting feedback from you.

Sincerely,


André Lage.
Ph.D. in Computer Science
https://sites.google.com/a/ic.ufal.br/andrelage/home/cv

Re: [julia-users] Re: Order of multiple for-loops

[Steven G. Johnson]

On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>
> Yes, this is an unfortunate consequence of mathematics being column-major 
> – oh how I wish it weren't so. 
>

I'm not sure what you mean by "mathematics being column major".  Fortran is 
column-major, and a lot of the linear-algebra libraries (LAPACK etc.) are 
column-major in consequence, and Matlab is column-major.

However, if Julia had chosen row-major, it would have been possible with a 
little care to call LAPACK and other column-major libraries without making 
a copy of any data, basically because for every linear-algebra operation 
there is an equivalent operation on the transpose of the matrix.

Probably too late to revisit this decision now, in any case.   It wouldn't 
matter much except that people have a natural tendency to write loops in 
row-major order, and Fortran compilers have had to fight against this for 
years.  (Sometimes they can detect and rearrange the loop order.)

[julia-users] Re: A grateful scientist

[Eric Forgy]

Hi Jonathan,

I'm in the same boat as a grateful scientist/entrepreneur and thank all the 
Julia developers, but since we're at it, I want to say a special "Thank 
you" to YOU for all the work you've done on JuliaWeb. Requests.jl, in 
particular, is making my life much easier. It's become an invaluable tool 
for my team for testing our APIs (and I've learned a lot by watching the 
incremental improvements). We are still building up our Julia skills and 
hope we can start contributing back as well.

On Wednesday, October 28, 2015 at 8:26:07 AM UTC+8, Jonathan Malmaud wrote:
>
> As someone who volunteers my free time to developing Julia, it means a lot 
> to hear that. 

[julia-users] Re: parallel and PyCall

[Yakir Gagnon]

@Matthew: did you find a solution? 
 
On Tuesday, October 27, 2015 at 8:44:53 AM UTC+10, Yakir Gagnon wrote:
>
> Yea, right? So what’s the answer? How can we if at all do any PyCalls 
> parallely? 
>
> On Monday, October 26, 2015 at 11:49:35 PM UTC+10, Matthew Pearce wrote:
>
> Thought I had an idea about this, I was wrong:
>>
>> ```julia
>>
>> julia> @everywhere using PyCall
>>
>> julia> @everywhere @pyimport pylab
>>
>> julia> remotecall_fetch(pylab.cumsum, 5, collect(1:10))
>> ERROR: cannot serialize a pointer
>>  [inlined code] from error.jl:21
>>  in serialize at serialize.jl:420
>>  [inlined code] from dict.jl:372
>>  in serialize at serialize.jl:428
>>  in serialize at serialize.jl:310
>>  in serialize at serialize.jl:420 (repeats 2 times)
>>  in serialize at serialize.jl:302
>>  in serialize at serialize.jl:420
>>  [inlined code] from dict.jl:372
>>  in serialize at serialize.jl:428
>>  in serialize at serialize.jl:310
>>  in serialize at serialize.jl:420 (repeats 2 times)
>>  in serialize at serialize.jl:302
>>  in serialize at serialize.jl:420
>>  [inlined code] from dict.jl:372
>>  in send_msg_ at multi.jl:222
>>  [inlined code] from multi.jl:177
>>  in remotecall_fetch at multi.jl:728
>>  [inlined code] from multi.jl:368
>>  in remotecall_fetch at multi.jl:734
>>
>> julia> pylab.cumsum(collect(1:10))
>> 10-element Array{Int64,1}:
>>   1
>>   3
>>   6
>>  10
>>  15
>>  21
>>  28
>>  36
>>  45
>>  55
>>
>> ```
>>
> ​
>

[julia-users] PSA: Images now uses FileIO

[Tim Holy]

Hi all,

A new Images.jl has been tagged and it now uses FileIO for image loading and 
saving. I've introduced FileIO in previous posts to this mailing list; it 
improves the the ability to dynamically choose package(s) for image I/O.

One consequence is that by default, you may not have any installed image 
loaders. If you're using Images interactively, FileIO will likely prompt you 
to install appropriate package(s) as it discovers you need them.

However, this doesn't happen in "non-interactive" usage. So, if you maintain a 
package whose tests depend on loading or saving images, I highly recommend 
adding a test/REQUIRE file that specifies the package(s) you need for image 
I/O. 
For example:

Contents of MyPkg/test/REQUIRE:
ImageMagick

That should do the trick for the large majority of cases.

Cheers,
--Tim

Re: [julia-users] Left bit shift operator.

[Tim Holy]

On Thursday, October 29, 2015 06:48:57 PM Yichao Yu wrote:
> Also ref https://github.com/JuliaLang/julia/pull/13809 @timholy

Different issue, though it's certainly playing in the same sandbox.

In general, promote_array_type uses the logic that the eltype of the array 
wins, for example Float64 + Vector{Float32} -> Vector{Float32}. There is a 
certain logic to this choice.

This is probably best handled by a comprehension:

julia> BigInt[BigInt(1) << n for n = 1:70]
70-element Array{BigInt,1}:
  2
  4
  8
 16
 32
 64
128
256
512
   1024
   2048
   4096
   8192
  16384
  32768
  65536
 131072
 262144
 524288
1048576
2097152
4194304
8388608
   16777216
   33554432
   67108864
  134217728
  268435456
  536870912
 1073741824
  ⋮
  4398046511104
  8796093022208
 17592186044416
 35184372088832
 70368744177664
140737488355328
281474976710656
562949953421312
   1125899906842624
   2251799813685248
   4503599627370496
   9007199254740992
  18014398509481984
  36028797018963968
  72057594037927936
 144115188075855872
 288230376151711744
 576460752303423488
1152921504606846976
2305843009213693952
4611686018427387904
9223372036854775808
   18446744073709551616
   36893488147419103232
   73786976294838206464
  147573952589676412928
  295147905179352825856
  590295810358705651712
 1180591620717411303424

Re: [julia-users] Left bit shift operator.

[Yichao Yu]

And it looks like promote_array_type is the function to blame

promote_array_type{S<:Integer, A<:Integer}(F, ::Type{S}, ::Type{A}) = A

looks very wrong for me

This is not BigInt specific either.

```
julia> 1 .+ Int8[127]
ERROR: InexactError()
 [inlined code] from ./operators.jl:313
 in .+ at ./arraymath.jl:120

julia> 1 .<< Int8[8]
ERROR: InexactError()
 [inlined code] from ./operators.jl:313
 in .<< at ./arraymath.jl:120
```

On Thu, Oct 29, 2015 at 6:48 PM, Yichao Yu  wrote:
> Also ref https://github.com/JuliaLang/julia/pull/13809 @timholy
>
> On Thu, Oct 29, 2015 at 6:46 PM, Yichao Yu  wrote:
>> On Thu, Oct 29, 2015 at 2:07 PM, alx  wrote:
>>> This OK
>>>
>>> julia> BigInt(2) .^ [1:6;]
>>> 6-element Array{BigInt,1}:
>>>   2
>>>   4
>>>   8
>>>  16
>>>  32
>>>  64
>>>
>>>
>>> Not if the result is correct, there should be Array Array{BigInt,1}:
>>>
>>> julia> BigInt(1) .<< [1:6;]
>>> 6-element Array{Int64,1}:
>>>   2
>>>   4
>>>   8
>>>  16
>>>  32
>>>  64
>>>
>>> julia> BigInt(1) .<< [1:70;]
>>> ERROR: InexactError()
>>>  in convert at gmp.jl:188
>>>  in .<< at arraymath.jl:120
>>>
>>
>> Sounds like a bug. Please file an issue.

Re: [julia-users] Re: Installing package (Cpp). Could not spawn 'make'.

[Joel Forsmoo]

Cheers, you make me feel welcome! I really appreciate your help!

I have just tried it briefly, but ran into a few bumps in the road which I
will try to wrap my head around (I want to give it a proper try before I
come asking for help). I will get back to you, whether I succeeded or not.

2015-10-25 15:40 GMT+00:00 Tony Kelman :

> Yes, that's about right, and don't worry about asking questions. We all
> had to learn this stuff somehow. The Makefile in question for Cpp.jl is
> here https://github.com/timholy/Cpp.jl/blob/master/deps/Makefile, which
> is relatively simple. It assumes the presence of a compiler, by default set
> to CC=gcc.
>
> When you first add a package, if there is a file deps/build.jl present,
> then the package gets "built" by executing that script. For Cpp.jl, that
> script is just run(`make`). If you want to manually trigger running the
> script again, the Pkg.build function is a shorthand for doing that.
>
>
> On Sunday, October 25, 2015 at 7:38:35 AM UTC-7, Joel wrote:
>>
>> Thank you again, Tony.
>>
>> The packages I am interested in are for wrapping c++ code, so Cpp or Cxx
>> .
>>
>> I am sorry for being slow... but compiling/building libraries is new to
>> me. "Calling 'make' at Pkg.build time", is that something along the lines
>> of what is described here
>>  (chapter
>> 2)? Or I missed the ball?
>>
>> 2015-10-21 23:37 GMT+01:00 Tony Kelman :
>>
>>> Looking at the original example of the Cpp.jl package, it appears to
>>> only be needing to call `make` at Pkg.build time in order to compile a demo
>>> test library. It should be pretty easy to modify it so it would fail
>>> gracefully with a warning rather than an error.
>>>
>>>
>>> On Wednesday, October 21, 2015 at 10:12:09 AM UTC-7, Tony Kelman wrote:

 The answer is a not-particularly-helpful "it depends." Which library
 are you interested in as a starting point? Not everything will be easy to
 build on Windows, there are often posix/unix assumptions in the code or
 build system. Usually the easiest way to get started is by installing MSYS2
 https://msys2.github.io/ and trying to follow the normal ./configure;
 make build instructions for a library, but coming up with an end result
 that will be usable with Julia can be more subtle than that. The steps and
 challenges are a little bit different each time you try to add Windows
 compatibility to a new package, but after a few times it gets easier to
 estimate ahead of time how difficult a particular library will be.


 On Wednesday, October 21, 2015 at 9:12:56 AM UTC-7, Joel wrote:
>
> Thank you Tony for your answer. I have just recently got into Python
> and building/compiling with MinGW-w32 and CMake (a lot of the terminology
> still goes over my head).
>
> Great talk! One main question from it; using Windows, is it possible
> to download a package from GitHub (which currently does not support
> Windows) and compile it using MinGW (creating a windows .dll file)? If 
> not,
> could you point me in the right direction as to where I can read more 
> about
> how to go ahead?
>
> 2015-10-20 14:15 GMT+01:00 Tony Kelman :
>
>> I don't know the Java ecosystem all that well, so I couldn't tell you
>> how many developers and contributors to, say, popular Apache projects do
>> most of their development on Windows. If you need things like
>> high-performance linear algebra you often need to go through JNI and deal
>> with interfacing native and JVM code.
>>
>> Conda.jl should be quite useful for Python dependencies via PyCall,
>> and maybe even R packages now too. But many of the C libraries provided
>> there for Windows are built to work with Python, meaning using the same
>> compiler that CPython was built with on Windows - Visual Studio. Visual
>> Studio has lots of problems with scientific software, we have very
>> experimental hacky support for compiling the core parts of Julia (LLVM,
>> libuv, libjulia, etc) using MSVC but it's not exactly native and far from
>> passing tests or a first-class solution.
>>
>> I also haven't seen many success stories of people from outside of
>> the Python community using Conda as a build platform for scientific
>> libraries in a way that would be usable and compatible with Julia. I
>> personally prefer WinRPM since it has a comparable selection of existing
>> libraries available at
>> https://build.opensuse.org/project/show/windows:mingw:win64, and
>> I've found it entirely doable to add new libraries there. You have an 
>> added
>> complication of cross-compiling, but an advantage there is package
>> developers never have to use Windows themselves if they don't want to.
>> Having a fully automated system to build and distribute binaries 

Re: [julia-users] Left bit shift operator.

[Yichao Yu]

Also ref https://github.com/JuliaLang/julia/pull/13809 @timholy

On Thu, Oct 29, 2015 at 6:46 PM, Yichao Yu  wrote:
> On Thu, Oct 29, 2015 at 2:07 PM, alx  wrote:
>> This OK
>>
>> julia> BigInt(2) .^ [1:6;]
>> 6-element Array{BigInt,1}:
>>   2
>>   4
>>   8
>>  16
>>  32
>>  64
>>
>>
>> Not if the result is correct, there should be Array Array{BigInt,1}:
>>
>> julia> BigInt(1) .<< [1:6;]
>> 6-element Array{Int64,1}:
>>   2
>>   4
>>   8
>>  16
>>  32
>>  64
>>
>> julia> BigInt(1) .<< [1:70;]
>> ERROR: InexactError()
>>  in convert at gmp.jl:188
>>  in .<< at arraymath.jl:120
>>
>
> Sounds like a bug. Please file an issue.

Re: [julia-users] Left bit shift operator.

[Yichao Yu]

On Thu, Oct 29, 2015 at 2:07 PM, alx  wrote:
> This OK
>
> julia> BigInt(2) .^ [1:6;]
> 6-element Array{BigInt,1}:
>   2
>   4
>   8
>  16
>  32
>  64
>
>
> Not if the result is correct, there should be Array Array{BigInt,1}:
>
> julia> BigInt(1) .<< [1:6;]
> 6-element Array{Int64,1}:
>   2
>   4
>   8
>  16
>  32
>  64
>
> julia> BigInt(1) .<< [1:70;]
> ERROR: InexactError()
>  in convert at gmp.jl:188
>  in .<< at arraymath.jl:120
>

Sounds like a bug. Please file an issue.

Re: [julia-users] Deprecation warnings using julia on Atom

[Colin Bowers]

I've not heard of lightbox. Do you mean LightTable? I used to use
LightTable with Mike Innes Juno package, but made the switch to Atom
because my understanding is that from v0.4 onwards, Mike will be
concentrating his efforts there. To be honest, I'm really happy with Atom
and the Julia packages. I think Mike has already got it as friendly and
feature-rich as Juno was (as long as you're on the Master branch of the
packages, that is). And the deprecation warnings are not a deal-breaker -
more a minor inconvenience.

Cheers,

Colin

On 29 October 2015 at 03:45, endowdly  wrote:

> Have you tried using lightbox?
>
> I ran into similar problems with atom, which I prefer due to speed. I
> could get lightbox to play well with the repl, however and "using jewel".
>
> On Tuesday, October 27, 2015 at 10:03:15 PM UTC-4, colint...@gmail.com
> wrote:
>>
>> Done. Precompilation occurred at the REPL, and I didn't have to do it
>> within Atom. Verified packages are all on Master. Unfortunately, I'm still
>> getting all of the original deprecation warnings when evaluating from the
>> editor in Atom.
>>
>> I'm happy to pursue this further, but am equally happy to wait it out if
>> you're running short on ideas or time.
>>
>> Cheers and thanks,
>>
>> Colin
>>
>> On Wednesday, 28 October 2015 12:24:38 UTC+11, Spencer Russell wrote:
>>>
>>> You’re running into another known issue:
>>> https://github.com/JuliaLang/julia/issues/12941
>>>
>>> Try opening a normal REPL in the terminal and run “using Atom” to
>>> trigger the precompilation, then it shouldn’t need to happen when you run
>>> from Atom.
>>>
>>> -s
>>>
>>>
>>> On Oct 27, 2015, at 9:09 PM, colint...@gmail.com wrote:
>>>
>>> Ah... understood. Many thanks.
>>>
>>> I'm afraid I'm still not getting the desired result however. After
>>> running checkout on "Atom", "CodeTools" and "JuliaParser" I run
>>> Pkg.status() and can verify I'm on the master branch for all 3. So I fire
>>> up Atom again, try to evaluate in the editor, and get the following error:
>>>
>>> INFO: Recompiling stale cache file
>>> /home/colin/.julia/lib/v0.4/JuliaParser.ji
>>> Julia has stopped: 1, null
>>>
>>> So I close down Atom, open it again, and try to evaluate in the editor
>>> again. This time I get:
>>>
>>> INFO: Recompiling stale cache file
>>> /home/colin/.julia/lib/v0.4/CodeTools.ji
>>> Julia has stopped: 1, null
>>>
>>> Close down Atom one more time, re-open it and try again. Now I get:
>>>
>>> INFO: Recompiling stale cache file /home/colin/.julia/lib/v0.4/Atom.ji
>>>
>>> but everything is now working fine. Problem solved? Unfortunately not. I
>>> restart Atom again and I'm back to all the deprecation warnings, even
>>> though Pkg.status() indicates I'm still on the master branch for Atom,
>>> CodeTools, and JuliaParser.
>>>
>>> Apologies for the long message. Also, if this is one of those things
>>> that will resolve itself over the next couple of weeks as changes from
>>> master are pushed to the more stable branches, then I'm happy to ignore the
>>> warnings for the time being and not waste anyone's time any further with
>>> what is essentially a minor inconvenience.
>>>
>>> Cheers,
>>>
>>> Colin
>>>
>>>
>>>
>>>
>>> On Wednesday, 28 October 2015 11:37:21 UTC+11, Spencer Russell wrote:

 `Pkg.checkout(…)` operates an an already-installed package, so it must
 be run after `Pkg.add(…)`.

 -s

 On Oct 27, 2015, at 8:31 PM, colint...@gmail.com wrote:

 I suppose I could clone the master branch. Is that a bad idea?

 On Wednesday, 28 October 2015 11:30:43 UTC+11, colint...@gmail.com
 wrote:
>
> Thanks for responding.
>
> Pkg.checkout("Atom") gives me the error:
>
> ERROR: Atom is not a git repo
>  in checkout at pkg/entry.jl:203
>  in anonymous at pkg/dir.jl:31
>  in cd at file.jl:22
>  in cd at pkg/dir.jl:31
>  in checkout at pkg.jl:37
>
> (I originally did try using Pkg.checkout as per the instructions, but
> got this error, and so went with Pkg.add instead).
>
> Any thoughts or is this a bug?
>
> Cheers,
>
> Colin
>
>
> On Wednesday, 28 October 2015 11:23:30 UTC+11, Jonathan Malmaud wrote:
>>
>> You want to be on the master versions:
>>
>> Pkg.checkout("Atom")
>> Pkg.checkout("CodeTools")
>>
>

>>>

[julia-users] Left bit shift operator.

[alx]

This OK

julia> BigInt(2) .^ [1:6;]
6-element Array{BigInt,1}:
  2
  4
  8
 16
 32
 64


Not if the result is correct, there should be Array Array{BigInt,1}:

julia> BigInt(1) .<< [1:6;]
6-element Array{Int64,1}:
  2
  4
  8
 16
 32
 64

julia> BigInt(1) .<< [1:70;]
ERROR: InexactError()
 in convert at gmp.jl:188
 in .<< at arraymath.jl:120

Re: [julia-users] WinRPM fails to install for fresh Julia 0.4.0 installation on Windows

[Tony Kelman]

What version of the package are you using, what's the error message, etc? See 
the open issues, there are a few suggested workarounds. To make this more 
robust, someone who is hitting problems will have to speak up in the issues and 
help test a few approaches.

Also Stefan, I've pinged you a few times on a DNS related issue here. We should 
try to move the cache mirror to a julialang address.

Re: [julia-users] Re: Order of multiple for-loops

['Greg Plowman' via julia-users]

I wouldn't say that storage order was irrelevant, but rather that 
mathematics order is different to Julia's storage order.
If Julia had row-major storage, I suspect order of comprehension loops 
would/should be the same as normal for-loops.
(Presumably order of comprehension loops now are so that they are 
constructed column-major order)

In fact it took me a while to write efficient loops for Julia's 
column-major ordering:

for j = 1:3, i = 1:2
  stuff with A[i,j]
end

At first, this seemed "awkward" but I'm used to it now.

Conversely, comprehension loops are written how I "think", but order is 
reversed for column-major efficiency.

Re: [julia-users] Re: For loop = or in?

[Steven G. Johnson]

See https://github.com/JuliaLang/julia/issues/8487

On Wednesday, October 28, 2015 at 10:16:37 AM UTC-4, Stefan Karpinski wrote:
>
> No, it's just a matter of changing the parser to accept that – and 
> convincing people that it's a good idea.
>
> On Wed, Oct 28, 2015 at 9:39 AM, DNF > 
> wrote:
>
>> On Wednesday, October 28, 2015 at 2:29:54 PM UTC+1, Stefan Karpinski 
>> wrote:
>>>
>>> I think we're getting into Parkinson's law territory here. First off, I 
>>> don't think this causes all that much confusion. Second, since this is pure 
>>> syntax involving a keyword no less, this is one of the easiest things to 
>>> mechanically fix should we chose to do so in the future.
>>>
>>
>> Fair enough. Could I just ask a question out of curiosity (not to try to 
>> convince anyone of anything)?
>>
>> Are there any technical problems (or other problems) associated with 
>> getting '∈' to work as a keyword, such as 
>> for i ∈ etc...
>> ?
>>
>
>

Re: [julia-users] List non-empty files in a folder

[Charles Novaes de Santana]

Thank you both! :) These different ways of doing the same thing in Julia
are quite useful (and funny! :))

Best,

Charles

On 29 October 2015 at 18:29, Stefan Karpinski  wrote:

> You can also use do-block syntax to make it a little easer to read:
>
> files = filter!(readdir(folder)) do fname
> splitext(fname)[2] == "txt" && filesize(fname) >= minsize
> end
>
>
> Using the splitext function avoids the somewhat unlikely corner case of
> having a hidden file whose entire name is ".txt" which should probably not
> be considered to have the extension ".txt" even though it does technically
> end with that string.
>
> On Thu, Oct 29, 2015 at 11:53 AM, Yichao Yu  wrote:
>
>> On Thu, Oct 29, 2015 at 11:41 AM, Charles Novaes de Santana
>>  wrote:
>> > Thanks! stat is great!! :)
>> >
>> > My R-biased programming can solve the problem by using the following
>> code:
>> >
>> > minsize=100
>> > folder=".";
>> > files =
>> >
>> filter!(r"\.txt$",readdir(folder))[map(filesize,filter!(r"\.txt$",readdir(folder))).>minsize]
>>
>> I don't think `readdir` necessarily garentee returning the files in
>> the same order every time you call it on all platforms. The simplest
>> improvement is just to call filter twice but you could also just do
>>
>> ```
>> filter!(fname->(endswith(fname, ".txt") && filesize(fname) > minsize),
>> readdir(folder))
>> ```
>>
>> Note that you don't need a regular expression for endswith...
>>
>> >
>> > It solves my problem. But I would appreciate if anyone has any other
>> > suggestion to do it in a Julia-style :)
>> >
>> > Thanks a lot!
>> >
>> > Best,
>> >
>> > Charles
>> >
>> > On 29 October 2015 at 16:25, Yichao Yu  wrote:
>> >>
>> >> stat[1] should have the info you need to write your own filter.
>> >>
>> >> [1]
>> >>
>> http://julia.readthedocs.org/en/latest/stdlib/file/?highlight=stat#Base.stat
>> >>
>> >> On Thu, Oct 29, 2015 at 11:22 AM, Charles Novaes de Santana
>> >>  wrote:
>> >> > Hi julians,
>> >> >
>> >> > I am using readdir() and filter!() to list files in a folder that
>> match
>> >> > a
>> >> > given pattern (lets' say, to list all .txt files).
>> >> >
>> >> > Now I would like to filter the files according to their sizes. I only
>> >> > want
>> >> > to list non-empty files within a folder, so my first shot is to list
>> >> > files
>> >> > which sizes are higher than zero bytes.
>> >> >
>> >> > Some days ago there was a thread about listing the last modified
>> file,
>> >> > that
>> >> > used map() and mtime(). Do you know something similar to list files
>> by
>> >> > size?
>> >> >
>> >> > Thanks for any tip!
>> >> >
>> >> > Best,
>> >> >
>> >> > Charles
>> >> >
>> >> > --
>> >> > Um axé! :)
>> >> >
>> >> > --
>> >> > Charles Novaes de Santana, PhD
>> >> > http://www.imedea.uib-csic.es/~charles
>> >
>> >
>> >
>> >
>> > --
>> > Um axé! :)
>> >
>> > --
>> > Charles Novaes de Santana, PhD
>> > http://www.imedea.uib-csic.es/~charles
>>
>
>


-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

Re: [julia-users] List non-empty files in a folder

[Stefan Karpinski]

You can also use do-block syntax to make it a little easer to read:

files = filter!(readdir(folder)) do fname
splitext(fname)[2] == "txt" && filesize(fname) >= minsize
end


Using the splitext function avoids the somewhat unlikely corner case of
having a hidden file whose entire name is ".txt" which should probably not
be considered to have the extension ".txt" even though it does technically
end with that string.

On Thu, Oct 29, 2015 at 11:53 AM, Yichao Yu  wrote:

> On Thu, Oct 29, 2015 at 11:41 AM, Charles Novaes de Santana
>  wrote:
> > Thanks! stat is great!! :)
> >
> > My R-biased programming can solve the problem by using the following
> code:
> >
> > minsize=100
> > folder=".";
> > files =
> >
> filter!(r"\.txt$",readdir(folder))[map(filesize,filter!(r"\.txt$",readdir(folder))).>minsize]
>
> I don't think `readdir` necessarily garentee returning the files in
> the same order every time you call it on all platforms. The simplest
> improvement is just to call filter twice but you could also just do
>
> ```
> filter!(fname->(endswith(fname, ".txt") && filesize(fname) > minsize),
> readdir(folder))
> ```
>
> Note that you don't need a regular expression for endswith...
>
> >
> > It solves my problem. But I would appreciate if anyone has any other
> > suggestion to do it in a Julia-style :)
> >
> > Thanks a lot!
> >
> > Best,
> >
> > Charles
> >
> > On 29 October 2015 at 16:25, Yichao Yu  wrote:
> >>
> >> stat[1] should have the info you need to write your own filter.
> >>
> >> [1]
> >>
> http://julia.readthedocs.org/en/latest/stdlib/file/?highlight=stat#Base.stat
> >>
> >> On Thu, Oct 29, 2015 at 11:22 AM, Charles Novaes de Santana
> >>  wrote:
> >> > Hi julians,
> >> >
> >> > I am using readdir() and filter!() to list files in a folder that
> match
> >> > a
> >> > given pattern (lets' say, to list all .txt files).
> >> >
> >> > Now I would like to filter the files according to their sizes. I only
> >> > want
> >> > to list non-empty files within a folder, so my first shot is to list
> >> > files
> >> > which sizes are higher than zero bytes.
> >> >
> >> > Some days ago there was a thread about listing the last modified file,
> >> > that
> >> > used map() and mtime(). Do you know something similar to list files by
> >> > size?
> >> >
> >> > Thanks for any tip!
> >> >
> >> > Best,
> >> >
> >> > Charles
> >> >
> >> > --
> >> > Um axé! :)
> >> >
> >> > --
> >> > Charles Novaes de Santana, PhD
> >> > http://www.imedea.uib-csic.es/~charles
> >
> >
> >
> >
> > --
> > Um axé! :)
> >
> > --
> > Charles Novaes de Santana, PhD
> > http://www.imedea.uib-csic.es/~charles
>

Re: [julia-users] Re: Order of multiple for-loops

[Stefan Karpinski]

Yes, this is an unfortunate consequence of mathematics being column-major –
oh how I wish it weren't so. The storage order is actually largely
irrelevant, the whole issue stems from the fact that the element in the ith
row and the jth column of a matrix is indexes as A[i,j]. If it were A[j,i]
then these would agree (and many things would be simpler). I like your
explanation of "an index closer to the expression to be evaluated runs
faster" – that's a really good way to remember/explain it.

On Thu, Oct 29, 2015 at 10:59 AM, Tk  wrote:

> PS. If this is concerned, I know that arrays in Julia are column-major
> order.
>
>
> On Thursday, October 29, 2015 at 11:57:23 PM UTC+9, Tk wrote:
>>
>> Hello,
>>
>> In the following explicit for-loops,
>>
>> for i = 1:2,
>>  j = 1:3,
>>  k = 1:4
>> @show i,j,k
>> end
>>
>> the index "k" runs fastest, as if this is written as three for(...) loops
>> in C etc.
>> On the other hand, in the following array comprehension,
>>
>> a = [ (@show i,j,k; i+j+k) for i=1:2, j=1:3, k=1:4 ]
>>
>> the index "i" runs fastest. To understand this behavior, is it reasonable
>> to think that
>> "an index closer to the expression to be evaluated runs faster"? Or is
>> there any different
>> reason that naturally determines this behavior (in the latter example)?
>>
>> # If we flatten the for-loops as "for i=1:2, j=1:3, k=1:4", both cases
>> look the same.
>> So initially I got a bit confused (though I now got used to it).
>>
>> # I tried to remember this order by analogy to the implied Do-loop syntax
>> in Fortran, such as
>>
>> a = [((( f(i,j,k), i=1,2 ), j=1,3 ), k=1,4 )))]
>>
>> shere "i" runs fastest (obviously).
>>
>

Re: [julia-users] WinRPM fails to install for fresh Julia 0.4.0 installation on Windows

[Stefan Karpinski]

Have you filed an issue?

On Thu, Oct 29, 2015 at 10:38 AM,  wrote:

> Shouldn't this error be fixed by now.  I've been running into this off and
> on for about 4 months now.  I'm trying to use Julia for a computational
> physics class and this is quite annoying.
>

Re: [julia-users] List non-empty files in a folder

[Yichao Yu]

On Thu, Oct 29, 2015 at 11:41 AM, Charles Novaes de Santana
 wrote:
> Thanks! stat is great!! :)
>
> My R-biased programming can solve the problem by using the following code:
>
> minsize=100
> folder=".";
> files =
> filter!(r"\.txt$",readdir(folder))[map(filesize,filter!(r"\.txt$",readdir(folder))).>minsize]

I don't think `readdir` necessarily garentee returning the files in
the same order every time you call it on all platforms. The simplest
improvement is just to call filter twice but you could also just do

```
filter!(fname->(endswith(fname, ".txt") && filesize(fname) > minsize),
readdir(folder))
```

Note that you don't need a regular expression for endswith...

>
> It solves my problem. But I would appreciate if anyone has any other
> suggestion to do it in a Julia-style :)
>
> Thanks a lot!
>
> Best,
>
> Charles
>
> On 29 October 2015 at 16:25, Yichao Yu  wrote:
>>
>> stat[1] should have the info you need to write your own filter.
>>
>> [1]
>> http://julia.readthedocs.org/en/latest/stdlib/file/?highlight=stat#Base.stat
>>
>> On Thu, Oct 29, 2015 at 11:22 AM, Charles Novaes de Santana
>>  wrote:
>> > Hi julians,
>> >
>> > I am using readdir() and filter!() to list files in a folder that match
>> > a
>> > given pattern (lets' say, to list all .txt files).
>> >
>> > Now I would like to filter the files according to their sizes. I only
>> > want
>> > to list non-empty files within a folder, so my first shot is to list
>> > files
>> > which sizes are higher than zero bytes.
>> >
>> > Some days ago there was a thread about listing the last modified file,
>> > that
>> > used map() and mtime(). Do you know something similar to list files by
>> > size?
>> >
>> > Thanks for any tip!
>> >
>> > Best,
>> >
>> > Charles
>> >
>> > --
>> > Um axé! :)
>> >
>> > --
>> > Charles Novaes de Santana, PhD
>> > http://www.imedea.uib-csic.es/~charles
>
>
>
>
> --
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles

Re: [julia-users] List non-empty files in a folder

[Charles Novaes de Santana]

Thanks! stat is great!! :)

My R-biased programming can solve the problem by using the following code:

minsize=100
folder=".";
files =
filter!(r"\.txt$",readdir(folder))[map(filesize,filter!(r"\.txt$",readdir(folder))).>minsize]

It solves my problem. But I would appreciate if anyone has any other
suggestion to do it in a Julia-style :)

Thanks a lot!

Best,

Charles

On 29 October 2015 at 16:25, Yichao Yu  wrote:

> stat[1] should have the info you need to write your own filter.
>
> [1]
> http://julia.readthedocs.org/en/latest/stdlib/file/?highlight=stat#Base.stat
>
> On Thu, Oct 29, 2015 at 11:22 AM, Charles Novaes de Santana
>  wrote:
> > Hi julians,
> >
> > I am using readdir() and filter!() to list files in a folder that match a
> > given pattern (lets' say, to list all .txt files).
> >
> > Now I would like to filter the files according to their sizes. I only
> want
> > to list non-empty files within a folder, so my first shot is to list
> files
> > which sizes are higher than zero bytes.
> >
> > Some days ago there was a thread about listing the last modified file,
> that
> > used map() and mtime(). Do you know something similar to list files by
> size?
> >
> > Thanks for any tip!
> >
> > Best,
> >
> > Charles
> >
> > --
> > Um axé! :)
> >
> > --
> > Charles Novaes de Santana, PhD
> > http://www.imedea.uib-csic.es/~charles
>



-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

[julia-users] List non-empty files in a folder

[Charles Novaes de Santana]

Hi julians,

I am using readdir() and filter!() to list files in a folder that match a
given pattern (lets' say, to list all .txt files).

Now I would like to filter the files according to their sizes. I only want
to list non-empty files within a folder, so my first shot is to list files
which sizes are higher than zero bytes.

Some days ago there was a thread about listing the last modified file, that
used map() and mtime(). Do you know something similar to list files by
size?

Thanks for any tip!

Best,

Charles

-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

[julia-users] Re: List non-empty files in a folder

[Charles Novaes de Santana]

Just to give a code to work. My code now is:

folder=".";
files = filter!(r"\.txt$",readdir(folder));

Thanks!

Charles

On 29 October 2015 at 16:22, Charles Novaes de Santana <
charles.sant...@gmail.com> wrote:

> Hi julians,
>
> I am using readdir() and filter!() to list files in a folder that match a
> given pattern (lets' say, to list all .txt files).
>
> Now I would like to filter the files according to their sizes. I only want
> to list non-empty files within a folder, so my first shot is to list files
> which sizes are higher than zero bytes.
>
> Some days ago there was a thread about listing the last modified file,
> that used map() and mtime(). Do you know something similar to list files by
> size?
>
> Thanks for any tip!
>
> Best,
>
> Charles
>
> --
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles
>



-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

Re: [julia-users] List non-empty files in a folder

[Yichao Yu]

stat[1] should have the info you need to write your own filter.

[1] http://julia.readthedocs.org/en/latest/stdlib/file/?highlight=stat#Base.stat

On Thu, Oct 29, 2015 at 11:22 AM, Charles Novaes de Santana
 wrote:
> Hi julians,
>
> I am using readdir() and filter!() to list files in a folder that match a
> given pattern (lets' say, to list all .txt files).
>
> Now I would like to filter the files according to their sizes. I only want
> to list non-empty files within a folder, so my first shot is to list files
> which sizes are higher than zero bytes.
>
> Some days ago there was a thread about listing the last modified file, that
> used map() and mtime(). Do you know something similar to list files by size?
>
> Thanks for any tip!
>
> Best,
>
> Charles
>
> --
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles

[julia-users] Re: Order of multiple for-loops

[Tk]

PS. If this is concerned, I know that arrays in Julia are column-major 
order.

On Thursday, October 29, 2015 at 11:57:23 PM UTC+9, Tk wrote:
>
> Hello,
>
> In the following explicit for-loops,
>
> for i = 1:2,
>  j = 1:3,
>  k = 1:4
> @show i,j,k
> end
>
> the index "k" runs fastest, as if this is written as three for(...) loops 
> in C etc.
> On the other hand, in the following array comprehension,
>
> a = [ (@show i,j,k; i+j+k) for i=1:2, j=1:3, k=1:4 ]
>
> the index "i" runs fastest. To understand this behavior, is it reasonable 
> to think that
> "an index closer to the expression to be evaluated runs faster"? Or is 
> there any different
> reason that naturally determines this behavior (in the latter example)?
>
> # If we flatten the for-loops as "for i=1:2, j=1:3, k=1:4", both cases 
> look the same.
> So initially I got a bit confused (though I now got used to it).
>
> # I tried to remember this order by analogy to the implied Do-loop syntax 
> in Fortran, such as
>
> a = [((( f(i,j,k), i=1,2 ), j=1,3 ), k=1,4 )))]
>
> shere "i" runs fastest (obviously).
>

[julia-users] Order of multiple for-loops

[Tk]

Hello,

In the following explicit for-loops,

for i = 1:2,
 j = 1:3,
 k = 1:4
@show i,j,k
end

the index "k" runs fastest, as if this is written as three for(...) loops 
in C etc.
On the other hand, in the following array comprehension,

a = [ (@show i,j,k; i+j+k) for i=1:2, j=1:3, k=1:4 ]

the index "i" runs fastest. To understand this behavior, is it reasonable 
to think that
"an index closer to the expression to be evaluated runs faster"? Or is 
there any different
reason that naturally determines this behavior (in the latter example)?

# If we flatten the for-loops as "for i=1:2, j=1:3, k=1:4", both cases look 
the same.
So initially I got a bit confused (though I now got used to it).

# I tried to remember this order by analogy to the implied Do-loop syntax 
in Fortran, such as

a = [((( f(i,j,k), i=1,2 ), j=1,3 ), k=1,4 )))]

shere "i" runs fastest (obviously).

Re: [julia-users] Re: For loop = or in?

[Tk]

> `=` better than `in`: `a = [ f(i,j,k) for i=1:p, j=1:q, k=1:r ]`

Please note that I am not trying to claim "=" is better universally (i.e. 
for everyone) based on this example,
because some people prefer more English like syntax for clarity of meaning 
(even when a bit longer).

So anyway, it would be nice if the official document will be updated to 
emphasize that there is no distinction
between in and = (used with for-loops, as of v0.4), and that if one 
prefers, one could use "in" everywhere (this is
a great point). Then we can just cite that explanation when a question 
arises for a while :)


On Thursday, October 29, 2015 at 10:41:19 PM UTC+9, Tom Breloff wrote:
>
> Agreed with Tony.  Having lots of ways to do the same thing is fine, as 
> long as we had no other syntactical use for the `=`.  Anyone want to 
> support notation like: `for y = sin(_) in 1:10 ... end`?  Probably not, so 
> no big deal to keep both around.
>
> Also I just saw Tk's post with this great example of `=` better than `in`: 
> `a = [ f(i,j,k) for i=1:p, j=1:q, k=1:r ]`
>
> On Thu, Oct 29, 2015 at 9:10 AM, Tony Kelman  > wrote:
>
>> How is having multiple syntaxes for something automatically bad? I don't 
>> hear people complaining that for loops are redundant when you could just do 
>> while with a counter, or that enumerate is equivalent. Having style 
>> guidelines for base to say when one choice makes more sense than another is 
>> fine, but this thread's overblown.
>
>
>

[julia-users] WinRPM fails to install for fresh Julia 0.4.0 installation on Windows

[jpclemens0]

Shouldn't this error be fixed by now.  I've been running into this off and 
on for about 4 months now.  I'm trying to use Julia for a computational 
physics class and this is quite annoying.

Re: [julia-users] Re: For loop = or in?

[Glen O]

But that's true of just about every instance where there are multiple ways 
of doing things. vcat vs [;], for instance. In some cases, there are 
distinct reasons; in others, there's no functional difference, and it only 
exists for the purposes of making it easier to read, for instance. Like 
f(x) and x |> f. I'm sure there will be people who ask if there's any 
benefit to x|>f over f(x). And the answer, as in this case, is 
"readability".

If the question really comes up over and over again, a FAQ should be 
created to answer it. Changing the way the language works because some 
people will ask questions is, in my opinion, a bad reason to change it.

On Thursday, 29 October 2015 23:44:07 UTC+10, Tamas Papp wrote:
>
> Maybe I was not clear: having multiple syntaxes per se is not 
> necessarily bad. 
>
> What is somewhat inconvenient is that since there is no good reason for 
> having multiple syntaxes, some newcomers to the language will be 
> confused, and will ask about this from time to time. Eg this is how this 
> thread got started; this is not the first one and of course not the 
> last. And of course then existing users will join in, and reason for =, 
> in, both, or a third syntax. 
>
> This is one of those tricky situations where it is hard to argue that 
> the status quo is significantly inferior to other options, but since 
> there is not a compelling reason for it either, the issue will be 
> discussed from time to time. Which is of course OK, but if both = and in 
> remain then the FAQ and the manual could clarify that neither is 
> preferred, both are fine, and there is no semantic difference. 
>
> Best, 
>
> Tamas 
>

Re: [julia-users] Re: Communicate thru COM Ports (Serial)

[Isaiah Norton]

Also: https://github.com/sjkelly/SerialPorts.jl

On Thu, Oct 29, 2015 at 9:29 AM, Uwe Fechner 
wrote:

> Did you try:
> https://github.com/rennis250/Arduino.jl
>
>
> On Thursday, October 29, 2015 at 1:49:32 PM UTC+1, endowdly wrote:
>>
>> I'd like to read and write text and strings (STDIN and STDOUT) via COM1
>> or COM2 (standard baud rates).
>>
>> Short story short, I'd like to control one or two systems with one
>> script. I need to do shell scripting, read and write, data analysis, and
>> simple math operations--preferably from one master script or control
>> program. Julia seems to be perfect for this, so I have started implementing
>> this idea with some julia code. The hangup is getting Julia to talk thru
>> the serial port. So far, all I can come up with is doing some ccalls and
>> using c to open the ports and read any incoming data.
>>
>> It doesn't seem to be in the documentation, and I've just started to
>> scratch through the registered packages, but can julia be used to network
>> through the COM interfaces? Thx.
>>
>

Re: [julia-users] Re: For loop = or in?

[Seth]

+1

On Thursday, October 29, 2015 at 5:56:46 AM UTC-7, Tom Breloff wrote:
>
> Lets close the topic.  Keep them both.
>
> On Thu, Oct 29, 2015 at 8:47 AM, feza > 
> wrote:
>
>> My only problem with `=` vs `in`
>> is that even the base julia code is inconsistent! Looking at one file ( I 
>> can't remember which now)
>> it had both
>> i = 1:nr
>> and
>> i in 1:n
>> Again this was in the same file! Please tell me I am not being pedantic 
>> when I saw this and thought this must be fixed if even the base is being 
>> inconsistent.
>>
>> On Thursday, October 29, 2015 at 8:44:03 AM UTC-4, mschauer wrote:
>>>
>>> Do we want to give up on this topic? Then we should do so in an earnest 
>>> way and close the case with a clear message, ideally after 
>>> establishing if we want to add a style recommendation about the use of 
>>> ``=`` and ``in`` to 
>>> http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently 
>>> the manual states in the control-flow chapter "In general, the for loop 
>>> construct can iterate over any container. In these cases, the alternative 
>>> (but fully equivalent) keyword in is typically used instead of =, since 
>>> it makes the code read more clearly."
>>>
>>
>

Re: [julia-users] Re: For loop = or in?

[Tamas Papp]

Maybe I was not clear: having multiple syntaxes per se is not
necessarily bad.

What is somewhat inconvenient is that since there is no good reason for
having multiple syntaxes, some newcomers to the language will be
confused, and will ask about this from time to time. Eg this is how this
thread got started; this is not the first one and of course not the
last. And of course then existing users will join in, and reason for =,
in, both, or a third syntax.

This is one of those tricky situations where it is hard to argue that
the status quo is significantly inferior to other options, but since
there is not a compelling reason for it either, the issue will be
discussed from time to time. Which is of course OK, but if both = and in
remain then the FAQ and the manual could clarify that neither is
preferred, both are fine, and there is no semantic difference. 

Best,

Tamas

On Thu, Oct 29 2015, Tony Kelman  wrote:

> How is having multiple syntaxes for something automatically bad? I don't hear 
> people complaining that for loops are redundant when you could just do while 
> with a counter, or that enumerate is equivalent. Having style guidelines for 
> base to say when one choice makes more sense than another is fine, but this 
> thread's overblown.

Re: [julia-users] Re: For loop = or in?

[Tom Breloff]

Agreed with Tony.  Having lots of ways to do the same thing is fine, as
long as we had no other syntactical use for the `=`.  Anyone want to
support notation like: `for y = sin(_) in 1:10 ... end`?  Probably not, so
no big deal to keep both around.

Also I just saw Tk's post with this great example of `=` better than `in`: `a
= [ f(i,j,k) for i=1:p, j=1:q, k=1:r ]`

On Thu, Oct 29, 2015 at 9:10 AM, Tony Kelman  wrote:

> How is having multiple syntaxes for something automatically bad? I don't
> hear people complaining that for loops are redundant when you could just do
> while with a counter, or that enumerate is equivalent. Having style
> guidelines for base to say when one choice makes more sense than another is
> fine, but this thread's overblown.

[julia-users] Re: For loop = or in?

[Tk]

Hi,

Before closing (this thread?), I would like to write one more thing. First, 
because I am not a native English speaker, it doesn't
actually matter how 1:n etc "reads" (simply because I don't pronounce them 
in mind :) Second, when I started
learning Julia half a year ago (sorry for a slow starter...), I also felt 
awkward that I have two kinds of syntax for the same
thing. So I tried to use "in" only for the time being (to mimic Python). 
But after a while I got back to "=", because it is gives  more concise (and 
IMO more readable) expressions, particularly in array comprehension. For 
example,

a = [ f(i,j,k) for i=1:p, j=1:q, k=1:r ]

a = [ f(i,j,k) for i in 1:p, j in 1:q, k in 1:r ]

# In this sense \in (greek letter) is as concise as =, but typing in the 
greek character takes a bit more time... (though I may be
able to customize Emacs if necessary).

As for Python-like, "there should be only one syntax for one purpose 
(semantic?)" policy (sorry if my English is strange), there seem to be many 
counter examples in Julia. For example, vcat() and [ a; b ] seem 
essentially the same, while the latter is probably there for brevity. I 
think it is not bad to have a shorter way to write it unless there are 
serious problems.

Btw, apart from the = vs in stuff, I really like this language because it 
allows multiple for-loops to be written concisely as

for i = 1:p,
 j = 1:q,
 k = 1:r
 (do something)
end

Indeed, I used to use a macro like this in C++ before that allows to write

For( i, 1, p,
   j, 1, p,
   k, 1, r ) {
 (do something)
}

so Julia has become one of my most favorite languages :)
Sorry for a long post...

[julia-users] Re: Communicate thru COM Ports (Serial)

[Uwe Fechner]

Did you try:
https://github.com/rennis250/Arduino.jl

On Thursday, October 29, 2015 at 1:49:32 PM UTC+1, endowdly wrote:
>
> I'd like to read and write text and strings (STDIN and STDOUT) via COM1 or 
> COM2 (standard baud rates). 
>
> Short story short, I'd like to control one or two systems with one script. 
> I need to do shell scripting, read and write, data analysis, and simple 
> math operations--preferably from one master script or control program. 
> Julia seems to be perfect for this, so I have started implementing this 
> idea with some julia code. The hangup is getting Julia to talk thru the 
> serial port. So far, all I can come up with is doing some ccalls and using 
> c to open the ports and read any incoming data. 
>
> It doesn't seem to be in the documentation, and I've just started to 
> scratch through the registered packages, but can julia be used to network 
> through the COM interfaces? Thx.
>

Re: [julia-users] [OT] Assembly language position

['Bill Hart' via julia-users]

Thanks, I wasn't aware of it. I'll see to it that something gets posted
there.

Bill.

On 29 October 2015 at 14:09, Yichao Yu  wrote:

> On Thu, Oct 29, 2015 at 9:06 AM, Bill Hart 
> wrote:
> > Hi all,
> >
> > If anyone would be interested in writing an x86_64 assembly
> superoptimiser
> > in Julia, we have a year of (academic) grant funding here in Germany that
> > could pay someone to do it.
> >
> > If you are interested in the details, please contact me off list. I
> > recognise that this is not exactly on topic for Julia users, so apologies
> > for that.
>
> I think there's a julia-jobs[1] list for this.
>
> [1] https://groups.google.com/forum/#!forum/julia-jobs
>
> >
> > Bill.
>

Re: [julia-users] [OT] Assembly language position

[Yichao Yu]

On Thu, Oct 29, 2015 at 9:06 AM, Bill Hart  wrote:
> Hi all,
>
> If anyone would be interested in writing an x86_64 assembly superoptimiser
> in Julia, we have a year of (academic) grant funding here in Germany that
> could pay someone to do it.
>
> If you are interested in the details, please contact me off list. I
> recognise that this is not exactly on topic for Julia users, so apologies
> for that.

I think there's a julia-jobs[1] list for this.

[1] https://groups.google.com/forum/#!forum/julia-jobs

>
> Bill.

Re: [julia-users] Re: For loop = or in?

[Tony Kelman]

How is having multiple syntaxes for something automatically bad? I don't hear 
people complaining that for loops are redundant when you could just do while 
with a counter, or that enumerate is equivalent. Having style guidelines for 
base to say when one choice makes more sense than another is fine, but this 
thread's overblown.

[julia-users] [OT] Assembly language position

[Bill Hart]

Hi all,

If anyone would be interested in writing an x86_64 assembly superoptimiser 
in Julia, we have a year of (academic) grant funding here in Germany that 
could pay someone to do it.

If you are interested in the details, please contact me off list. I 
recognise that this is not exactly on topic for Julia users, so apologies 
for that.

Bill. 

Re: [julia-users] Re: For loop = or in?

[Tamas Papp]

1. Unless there is a single syntax, the topic will inevitably come up
again and again. This does not necessarily mean that we need a single
syntax, but this is a cost of the status quo (ie having both = and in)
that has to be considered.

2. I think everyone said what they wanted to say. IMO it would be great
if the key people in Julia could make a decision about this, either
deprecate =, or in, or keep both, anything is fine, just have a clear
indication of what is going to happen so that people could submit a PR
for the documentation and the FAQ (if both are kept), or the base code
(or one is dropped).

Best,

Tamas

On Thu, Oct 29 2015, feza  wrote:

> My only problem with `=` vs `in`
> is that even the base julia code is inconsistent! Looking at one file ( I 
> can't remember which now)
> it had both
> i = 1:nr
> and
> i in 1:n
> Again this was in the same file! Please tell me I am not being pedantic 
> when I saw this and thought this must be fixed if even the base is being 
> inconsistent.
>
> On Thursday, October 29, 2015 at 8:44:03 AM UTC-4, mschauer wrote:
>>
>> Do we want to give up on this topic? Then we should do so in an earnest 
>> way and close the case with a clear message, ideally after 
>> establishing if we want to add a style recommendation about the use of 
>> ``=`` and ``in`` to 
>> http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently 
>> the manual states in the control-flow chapter "In general, the for loop 
>> construct can iterate over any container. In these cases, the alternative 
>> (but fully equivalent) keyword in is typically used instead of =, since 
>> it makes the code read more clearly."
>>

Re: [julia-users] Re: For loop = or in?

[Tom Breloff]

Lets close the topic.  Keep them both.

On Thu, Oct 29, 2015 at 8:47 AM, feza  wrote:

> My only problem with `=` vs `in`
> is that even the base julia code is inconsistent! Looking at one file ( I
> can't remember which now)
> it had both
> i = 1:nr
> and
> i in 1:n
> Again this was in the same file! Please tell me I am not being pedantic
> when I saw this and thought this must be fixed if even the base is being
> inconsistent.
>
> On Thursday, October 29, 2015 at 8:44:03 AM UTC-4, mschauer wrote:
>>
>> Do we want to give up on this topic? Then we should do so in an earnest
>> way and close the case with a clear message, ideally after
>> establishing if we want to add a style recommendation about the use of
>> ``=`` and ``in`` to
>> http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently
>> the manual states in the control-flow chapter "In general, the for loop
>> construct can iterate over any container. In these cases, the alternative
>> (but fully equivalent) keyword in is typically used instead of =, since
>> it makes the code read more clearly."
>>
>

[julia-users] Communicate thru COM Ports (Serial)

[endowdly]

I'd like to read and write text and strings (STDIN and STDOUT) via COM1 or 
COM2 (standard baud rates). 

Short story short, I'd like to control one or two systems with one script. 
I need to do shell scripting, read and write, data analysis, and simple 
math operations--preferably from one master script or control program. 
Julia seems to be perfect for this, so I have started implementing this 
idea with some julia code. The hangup is getting Julia to talk thru the 
serial port. So far, all I can come up with is doing some ccalls and using 
c to open the ports and read any incoming data. 

It doesn't seem to be in the documentation, and I've just started to 
scratch through the registered packages, but can julia be used to network 
through the COM interfaces? Thx.

Re: [julia-users] Deprecation warnings using julia on Atom

[endowdly]

Have you tried using lightbox? 

I ran into similar problems with atom, which I prefer due to speed. I could 
get lightbox to play well with the repl, however and "using jewel". 

On Tuesday, October 27, 2015 at 10:03:15 PM UTC-4, colint...@gmail.com 
wrote:
>
> Done. Precompilation occurred at the REPL, and I didn't have to do it 
> within Atom. Verified packages are all on Master. Unfortunately, I'm still 
> getting all of the original deprecation warnings when evaluating from the 
> editor in Atom.
>
> I'm happy to pursue this further, but am equally happy to wait it out if 
> you're running short on ideas or time.
>
> Cheers and thanks,
>
> Colin
>
> On Wednesday, 28 October 2015 12:24:38 UTC+11, Spencer Russell wrote:
>>
>> You’re running into another known issue: 
>> https://github.com/JuliaLang/julia/issues/12941
>>
>> Try opening a normal REPL in the terminal and run “using Atom” to trigger 
>> the precompilation, then it shouldn’t need to happen when you run from Atom.
>>
>> -s
>>
>>
>> On Oct 27, 2015, at 9:09 PM, colint...@gmail.com wrote:
>>
>> Ah... understood. Many thanks.
>>
>> I'm afraid I'm still not getting the desired result however. After 
>> running checkout on "Atom", "CodeTools" and "JuliaParser" I run 
>> Pkg.status() and can verify I'm on the master branch for all 3. So I fire 
>> up Atom again, try to evaluate in the editor, and get the following error:
>>
>> INFO: Recompiling stale cache file 
>> /home/colin/.julia/lib/v0.4/JuliaParser.ji
>> Julia has stopped: 1, null
>>
>> So I close down Atom, open it again, and try to evaluate in the editor 
>> again. This time I get:
>>
>> INFO: Recompiling stale cache file 
>> /home/colin/.julia/lib/v0.4/CodeTools.ji
>> Julia has stopped: 1, null
>>
>> Close down Atom one more time, re-open it and try again. Now I get:
>>
>> INFO: Recompiling stale cache file /home/colin/.julia/lib/v0.4/Atom.ji
>>
>> but everything is now working fine. Problem solved? Unfortunately not. I 
>> restart Atom again and I'm back to all the deprecation warnings, even 
>> though Pkg.status() indicates I'm still on the master branch for Atom, 
>> CodeTools, and JuliaParser.
>>
>> Apologies for the long message. Also, if this is one of those things that 
>> will resolve itself over the next couple of weeks as changes from master 
>> are pushed to the more stable branches, then I'm happy to ignore the 
>> warnings for the time being and not waste anyone's time any further with 
>> what is essentially a minor inconvenience.
>>
>> Cheers,
>>
>> Colin
>>
>>
>>
>>
>> On Wednesday, 28 October 2015 11:37:21 UTC+11, Spencer Russell wrote:
>>>
>>> `Pkg.checkout(…)` operates an an already-installed package, so it must 
>>> be run after `Pkg.add(…)`.
>>>
>>> -s
>>>
>>> On Oct 27, 2015, at 8:31 PM, colint...@gmail.com wrote:
>>>
>>> I suppose I could clone the master branch. Is that a bad idea?
>>>
>>> On Wednesday, 28 October 2015 11:30:43 UTC+11, colint...@gmail.com 
>>> wrote:

 Thanks for responding.

 Pkg.checkout("Atom") gives me the error:

 ERROR: Atom is not a git repo
  in checkout at pkg/entry.jl:203
  in anonymous at pkg/dir.jl:31
  in cd at file.jl:22
  in cd at pkg/dir.jl:31
  in checkout at pkg.jl:37

 (I originally did try using Pkg.checkout as per the instructions, but 
 got this error, and so went with Pkg.add instead).

 Any thoughts or is this a bug?

 Cheers,

 Colin


 On Wednesday, 28 October 2015 11:23:30 UTC+11, Jonathan Malmaud wrote:
>
> You want to be on the master versions:
>
> Pkg.checkout("Atom")
> Pkg.checkout("CodeTools")
>

>>>
>>

Re: [julia-users] Re: For loop = or in?

[feza]

My only problem with `=` vs `in`
is that even the base julia code is inconsistent! Looking at one file ( I 
can't remember which now)
it had both
i = 1:nr
and
i in 1:n
Again this was in the same file! Please tell me I am not being pedantic 
when I saw this and thought this must be fixed if even the base is being 
inconsistent.

On Thursday, October 29, 2015 at 8:44:03 AM UTC-4, mschauer wrote:
>
> Do we want to give up on this topic? Then we should do so in an earnest 
> way and close the case with a clear message, ideally after 
> establishing if we want to add a style recommendation about the use of 
> ``=`` and ``in`` to 
> http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently 
> the manual states in the control-flow chapter "In general, the for loop 
> construct can iterate over any container. In these cases, the alternative 
> (but fully equivalent) keyword in is typically used instead of =, since 
> it makes the code read more clearly."
>

Re: [julia-users] Re: For loop = or in?

[mschauer]

Do we want to give up on this topic? Then we should do so in an earnest way 
and close the case with a clear message, ideally after 
establishing if we want to add a style recommendation about the use of 
``=`` and ``in`` to 
http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently the 
manual states in the control-flow chapter "In general, the for loop 
construct can iterate over any container. In these cases, the alternative 
(but fully equivalent) keyword in is typically used instead of =, since it 
makes the code read more clearly."

Re: [julia-users] Re: For loop = or in?

[Kristoffer Carlsson]

Well then it's settled. Someone prepare a PR ;)

Re: [julia-users] Re: For loop = or in?

[Tony Kelman]

Pontus, you're awesome. Technically the first commit here was merged 4 
minutes before your post, but funny anyway:

julia> mod(big"0xdfe0cc00e3ae91cd981d0b4243498f8321992fbc",10)
0

julia> mod(big"0xf8a4340548e7d6be31fede13cdc4e0f5f434f33f",10)
7

My opinion would be to leave it since Julia isn't Python and we're not too 
militaristic about "one way to do it" zen nonsense when things aren't 
actively harmful or confusing, but Pontus just about wins me over with that.


On Thursday, October 29, 2015 at 2:38:33 AM UTC-7, Pontus Stenetorp wrote:
>
> I have to agree with Stefan that this is turning into 
> bikeshedding [1].  My personal bias is towards `in`, probably due to 
> my many years of Python, but I am convinced that both keeping the 
> current duality or picking one of them will not lead to a mental 
> overload.  In fact, in order for us to stop spending brain cycles on 
> this, it would even seem sane to me to take the hash of the next 
> commit after this e-mail has been sent, apply modulo 10, if the number 
> is 1-3, preserve the status quo, for 4-6, switch to using `=`, for 
> 7-9, switch to using `in`, for 0, discard the number and use the next 
> commit instead. 
>
> Pontus 
>
> [1]: https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality 
>

Re: [julia-users] ESS and autocompletion for Julia

[Ivan Bocharov]

Thanks for pointing out that the Julia process should be running in the 
background.

It turned out that the problem for Julia autocompletion was caused by 
"non-global" global autocomplete mode. I've managed to find a function that 
defined behaviour that I was looking for here:

http://emacswiki.org/emacs/AutoComplete#toc6

Once again, thank you for your help!

Best, Ivan



среда, 28 октября 2015 г., 2:21:47 UTC+1 пользователь Ista Zahn написал:
>
> Does tab completion work in other languages supported by ESS? If it 
> doesn't then there would appear to be something missing from your ESS 
> settings (I don't bind completion to TAB myself, there is too much 
> already happening on the TAB key). If it works for (e.g.) R but not 
> Julia I would report a bug to ESS. 
>
> For me completion of my own functions and objects works fine. You do 
> have to evaluate them in the REPL though. ESS completion works be 
> asking the running REPL for completions, so if the object hasn't been 
> defined there it won't show up in the completion list. 
>
> As for 'fun' completing to 'functionloc', yeah, that's what I see too. 
> I think it doesn't work for the same reason '@doc function' doesn't 
> work. I'm sure ESS bug reports and pull requests would be appreciated. 
>
> Best, 
> Ista 
>
> On Tue, Oct 27, 2015 at 5:12 PM, Ivan Bocharov  > wrote: 
> > Thank you very much for your reply! 
> > 
> > I have Compat package installed, julia process running and tried both 
> > autocomplete and company. TAB-completion still doesn't work, though, 
> > invoking C-M-i produces some results. The thing is that i can complete 
> only 
> > the contents from the Base (some types and functions) and can't complete 
> my 
> > own functions and objects. Also, for example, 'func' completes to 
> > 'functionloc'. Is this the desired behaviour? 
> > 
> > Best, 
> > Ivan 
> > 
> > вторник, 27 октября 2015 г., 15:38:13 UTC+1 пользователь Ista Zahn 
> написал: 
> >> 
> >> It works for me with the company backend. Haven't tried the 
> >> autocomplete backend recently. I think ESS prefers the company 
> >> backend, so just installing and loading the company package may be 
> >> enough. 
> >> 
> >> Note that for completions to work you need to have an inferior julia 
> >> process running, and the Julia Compat package must be installed. 
> >> 
> >> Best, 
> >> Ista 
> >> 
> >> On Tue, Oct 27, 2015 at 4:44 AM, Ivan Bocharov  
> wrote: 
> >> > Hello All, 
> >> > 
> >> > I am a newbie Emacs user and I really want to write my Julia code in 
> >> > Emacs. 
> >> > I've installed Emacs using brew and ESS from MELPA. 
> >> > 
> >> > I can get TAB-autocompletion in Julia shell, but the autocompletion 
> >> > doesn't 
> >> > work in my own scripts. Is it supposed to be this way or am I missing 
> >> > something? 
> >> > 
> >> > My current setup is: Emacs from brew (GNU Emacs 24.5.1), Julia 
> v.0.4.0 
> >> > and 
> >> > ESS v. 15.09-1 (output from M-x ess-version). 
> >> > 
> >> > My init.el file looks this way: 
> >> > 
> >> > (when (>= emacs-major-version 24) 
> >> >   (require 'package) 
> >> >   (add-to-list 
> >> >'package-archives 
> >> >'("melpa" . "http://melpa.org/packages/";) 
> >> >t) 
> >> >   (package-initialize)) 
> >> > 
> >> > (require 'ess-site) 
> >> > (setq inferior-julia-program-name "julia") 
> >> > (setq ess-use-auto-complete t) 
> >> > (setq ess-tab-complete-in-script t) 
> >> > 
> >> > (require 'auto-complete-config) 
> >> > (add-to-list 'ac-dictionary-directories 
> >> > "~/.emacs.d/elpa/auto-complete/dict") 
> >> > 
> >> > (set-default 'ac-sources 
> >> > '(ac-source-abbrev 
> >> >   ac-source-dictionary 
> >> >   ac-source-yasnippet 
> >> >   ac-source-words-in-buffer 
> >> >   ac-source-words-in-same-mode-buffers 
> >> >   ac-source-semantic)) 
> >> > 
> >> > (ac-config-default) 
> >> > 
> >> > As a side note I wanted to thank all the contributors and the 
> community 
> >> > for 
> >> > their work! 
> >> > 
> >> > Best, Ivan. 
>

Re: [julia-users] Re: For loop = or in?

[Pontus Stenetorp]

I have to agree with Stefan that this is turning into
bikeshedding [1].  My personal bias is towards `in`, probably due to
my many years of Python, but I am convinced that both keeping the
current duality or picking one of them will not lead to a mental
overload.  In fact, in order for us to stop spending brain cycles on
this, it would even seem sane to me to take the hash of the next
commit after this e-mail has been sent, apply modulo 10, if the number
is 1-3, preserve the status quo, for 4-6, switch to using `=`, for
7-9, switch to using `in`, for 0, discard the number and use the next
commit instead.

Pontus

[1]: https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

[julia-users] Re: For loop = or in?

[Alireza Nejati]

I'm with Tomas here - if anything this thread is testimony to the fact that 
both '=' and 'in' should be left in.

Re: [julia-users] Re: For loop = or in?

[Tomas Lycken]

I read 1:n that way. And even if I didn't, I prefer to think about a looping 
construct as "do this for each element in that collection" - and regardless of 
how I pronounce 1:n, I see it as a collection since it inherits AbstractArray. 

But I can also see how other mental models work for you. There's a lot of talk 
in this thread along the lines of "my mental model of this construct is better 
than yours, and therefore my syntax preference is better than yours." I find 
this ridiculously inconstructive - bordering on children arguing in the 
sandbox... To me, this just indicates that both mental models are valid that 
both syntaxes should, at least for the time being, stay. The fact that no clear 
winner can be found by counting usages in base further supports this. 

There is a suggestion in this thread worth keeping, though - supporting unicode 
\in would be a nice addition for those of us who embrace supersets of ascii.

// Tomas