[julia-users] Re: Moving from 0.3 to 0.4

[Alireza Nejati]

Most things in 0.3 will still work in 0.4 except with a handy depreciation 
error which will tell you exactly what to fix. Here are some tips:

- Use Compat.jl. It makes life a LOT easier. It lets you write a single 
version of your code for 0.4 (or, more generally, the latest version of 
julia) while automagically allowing your code to run in previous versions 
as well.

- Union(...) -> Union{}

- FloatingPoint -> AbstractFloat

- [a; b] -> [a, b]

- [a, b] (if a and b are vectors) -> vcat(a, b)

- float64([...]) -> map(Float64, [...]) or just Float64[...]

These should cover most errors I've seen...

Also a few coding notes: Now that Cartesian.jl is part of the Base library, 
it makes sense to use it whenever you want to. Also, we're gradually moving 
to slices becoming views so you might want to keep that in mind.

[julia-users] Re: alternate LISP integration ...

[Tomas Lycken]

Have you tried julia --lisp from the command line? Works on my machine…

// T

On Monday, October 26, 2015 at 10:36:05 PM UTC+1, cdm wrote:


> somewhat related ...
>
> is it still possible to get
> the femtolisp REPL in the
> post v0.4.0 world ... ?
>
> thanks,
>
> cdm
>
​

Re: [julia-users] A question of Style: Iterators into regular Arrays

[DNF]

I think that the point of the idea was to get rid of the Abstract prefix. 
It can be a bit confusing that some, but not all, abstract types have the 
Abstract prefix, and as seen in this thread it has led to some 
misunderstandings.


On Tuesday, October 27, 2015 at 8:29:21 AM UTC+1, Tomas Lycken wrote:
>
> Better yet, since we already have both AbstractVector, AbstractMatrix, 
> AbstractArray, AbstractString, AbstractFloat and a couple of others (try 
> typing Abstract in the REPL…) it might be time to rename Integer to 
> AbstractInteger. I have a hard time thinking the confusion between Int 
> and Integer would be reduced just because we also had Arr and Array et al 
> - rather, we’d have *several*.
>
> ​
>

Re: [julia-users] How to get first number from Int64

[David Epstein]

A one-liner, with type conversion to get an integer back:

*convert(Int64,floor(x/10^(floor(log10(x)*

On Saturday, October 24, 2015 at 11:40:03 AM UTC-4, Michele Zaffalon wrote:
>
> There is also the builtin 
> http://docs.julialang.org/en/latest/stdlib/numbers/#Base.digits
>
> On Sat, Oct 24, 2015 at 3:51 PM, Tamas Papp  > wrote:
>
>> A trivial (but not necessarily the fastest) solution is
>>
>> function firstdigit(i,base=10)
>> while (i >= base)
>> i = div(i,base)
>> end
>> i
>> end
>>
>> Best,
>>
>> Tamas
>>
>> On Sat, Oct 24 2015, paul analyst  
>> wrote:
>>
>> > How to get first number from Int64
>> >
>> > julia> lista[3]
>> > 464
>> >
>> > julia> eltype(lista[3])
>> > Int64
>> >
>> > julia> length(lista[3])
>> > 1
>> >
>> > julia> lista[3][]
>> > 464
>> >
>> > julia> lista[3][1]
>> >
>> > I need the first "4"
>> > Paul
>>
>>
>

[julia-users] Re: JuliaBox limitations on parallel computing

[Iliyan Zarov]

 

For anyone wishing to run large parallel programs I may be able to help - 
I'm working on a cloud computing platform for Julia that takes care of 
provisioning and managing all resources. More info at https://evoqus.com . 

It's currently in beta, get in touch if interested.


Best,

Iliyan

On Monday, October 26, 2015 at 6:41:57 PM UTC, cdm wrote:
>
>
> perhaps time for an asterisk on the JuliaBox banner:
>
> "The Julia community is doing amazing things. We want you in on it!*"
>
> * ... but not massively in parallel, consuming the resources of the 
> community.
>
>
>
> there are positives and negatives to this sort of problem ...
>
> the fact that the problem can even arise says great things
> about the capabilities of the language and the service.
>
> well done ...
>
>
>
> On Sunday, October 25, 2015 at 2:11:25 AM UTC-7, Tanmay K. Mohapatra wrote:
>>
>> Hi,
>>
>> from the past few days we have had some users run large parallel programs 
>> on JuliaBox sessions. While in some cases they succeed, we see a lot of 
>> failures due to resource constraints. Though we have plans to enable large 
>> programs in future, we do not allocate enough resources for that now.
>>
>> Also, since JuliaBox sessions run on shared infrastructure, this affects 
>> other sessions that are co-located on the same machine.  We will be putting 
>> in place more checks and restrictions soon to prevent co-located sessions 
>> from being impacted.
>>
>> We would request users to refrain from running large parallel programs 
>> for now. If this is being done as part of some university class, please 
>> write to us. Probably a separately provisioned cluster will be more 
>> appropriate for that.
>>
>> - JuliaBox Team
>>
>

[julia-users] Re: JuliaBox limitations on parallel computing

[Christopher Fusting]

Hi!

I believe this is my fault. I've been running some items in parallel for 
class. I believe only one session ran away (1+ hours) while the others were 
< 10 minutes. Sorry for the trouble, I didn't realize there was a negative 
impact on others / the infrastructure. In the future I'll run processor 
intensive items on my local machine.

Incidentally I am unable to login to Juliabox now (is this related?). I 
have not backed up my work to github and as such would respectfully request 
the ability to copy my files over if I have been banned from the service. 
Some of them have due dates :).

Cheers,

_Chris

On Sunday, October 25, 2015 at 5:11:19 AM UTC-4, tanmaykm wrote:
>
> Hi,
>
> from the past few days we have had some users run large parallel programs 
> on JuliaBox sessions. While in some cases they succeed, we see a lot of 
> failures due to resource constraints. Though we have plans to enable large 
> programs in future, we do not allocate enough resources for that now.
>
> Also, since JuliaBox sessions run on shared infrastructure, this affects 
> other sessions that are co-located on the same machine.  We will be putting 
> in place more checks and restrictions soon to prevent co-located sessions 
> from being impacted.
>
> We would request users to refrain from running large parallel programs for 
> now. If this is being done as part of some university class, please write 
> to us. Probably a separately provisioned cluster will be more appropriate 
> for that.
>
> - JuliaBox Team
>

[julia-users] pmap and DataStructures.OrderedDict

[Daniel O'Malley]

I've recently encountered problems using pmap on a function that returns a 
DataStructures.OrderedDict.

import DataStructures
@everywhere function f(x)
return DataStructures.OrderedDict(zip(["x"], [x]))
end
pmap(f, [1, 2])

If the above code is run in a "julia -p 2" environment, it produce a 
cascade of errors that seem to begin with

ERROR: MethodError: `write` has no method matching 
write(::SerializationState{TCPSocket}, ::Int32)

In the original context that this example was trying to replicate, the 
error was

ERROR: MethodError: `read` has no method matching 
read(::SerializationState{TCPSocket}, ::Type{Int32})

Does anyone have advice on how to resolve this? Should these methods exist 
in base julia? Am I doing something wrong?

Thanks for your help!

Dan

[julia-users] Re: missing const qualifier

[Carlo Lucibello]

I found your proposal

https://groups.google.com/forum/#!searchin/julia-users/vavasis/julia-users/Hq00EyeazJM/HgYgDcnbhs4J
https://groups.google.com/forum/#!searchin/julia-users/vavasis$20const/julia-users/FK_29Dj4eDo/nX5QnhfKc40J

but that is a different feature, having cont `in` argument, while I want 
const return types. 

Having const in would be nice, but i understand that its implementation 
would be more difficult.

On the other hand having a const return valure seems easier to my 
(non-expert) eyes




Il giorno martedì 27 ottobre 2015 04:27:44 UTC+1, vav...@uwaterloo.ca ha 
scritto:
>
> In 2014 when I first learned about Julia, I also suggested on this 
> newsgroup that there should be a 'const' keyword as in C++ to annotate 
> function arguments and return variables that are supposed to be read-only. 
>  Possibly you can find the old thread with google.  I received a lot of 
> feedback from experienced Julia users and core developers that convinced me 
> that this is probably not a good idea.  Here are some reasons that I can 
> recall from the earlier discussion that adding 'const' to Julia may not be 
> a good idea.
>
> (1) The 'const' keyword would make the multiple-dispatch system much more 
> confusing because it would entail new rules about how the 'const' keyword 
> affects closeness in the type hierarchy.
>
> not a problem for const return value
 

> (2) You can already get the desired effect in Julia by defining your own 
> subtype of DenseArray in which getindex works as usual but setindex! throws 
> an error.
>
> this solution is not general, it works only on arrays 

> (3) The promise that a routine won't change a 'const' argument could 
> easily be defeated by aliasing (i.e., a function is invoked with a const 
> argument, but another non-const argument refers to the same piece of data), 
> so it may give the user a false sense of security.
>
 not a problem for const return value

-- Steve Vavasis
>
>
>
>
>
>
>
> On Monday, October 26, 2015 at 10:29:34 PM UTC-4, Carlo Lucibello wrote:
>>
>> It would be nice to annotate the return type of methods with a constant 
>> qualifier, in order to have 
>> an efficient and safe behaviour at the same time. 
>>
>> I mean something like this:
>>
>> type A
>>   data::Vector{Int}
>> end
>>
>> # invalid but desiderable julia code
>> const function getdata(a::A)
>>   return a.data
>> end 
>>
>> a = A(ones(10))
>> data = getdata(a)
>>
>> data[1] = 2  # ERROR
>> a.data[1] = 2 # OK
>>   
>>
>

[julia-users] Re: Pkg.add("DecisionTree") getting error, failed pocess: Process(`git ' --worktree = C:\Users.....

[Tomas Lycken]

Is it possible for you to scroll right in the first error message, to show 
the entire message? Easiest is probably if you could copy the *text* of the 
message, and paste it here.

// T

On Monday, October 26, 2015 at 8:26:07 PM UTC+1, aar…@udel.edu wrote:

Hi I am running my Julia code in Juno/LT. I am trying to add the decision 
> tree package but I am getting a major error seen in the screenshot below. 
> Any help would be much appreciated.
>
>
>
> 
>
​

Re: [julia-users] A question of Style: Iterators into regular Arrays

[Tomas Lycken]

Better yet, since we already have both AbstractVector, AbstractMatrix, 
AbstractArray, AbstractString, AbstractFloat and a couple of others (try 
typing Abstract in the REPL…) it might be time to rename Integer to 
AbstractInteger. I have a hard time thinking the confusion between Int and 
Integer would be reduced just because we also had Arr and Array et al - 
rather, we’d have *several* pairs of types where it isn’t entirely obvious 
that one is abstract and one is concrete.

Renaming Integer to AbstractInteger would probably cause massive breakage, 
though, so it’d have to be done with care. The difference between Int, Int32
/Int64 and Integer is well documented (see e.g. here 

 
and here 
), 
but it seems to me that people stumble on this often enough that a naming 
change might be well motivated anyway.
// T

On Monday, October 26, 2015 at 8:26:08 PM UTC+1, Scott Jones wrote:

>One possible naming scheme could be to follow the example of Int and 
> Integer and have Vec, Mat, Arr be the concrete types and Vector, Matrix and 
> Array be the abstract types. I'm really not sure this would be worth the 
> trouble at this point or if we really want the AbstractArray names to be 
> any shorter.
>
> That sounds like a quite good idea, which, if carried out completely, 
> could eliminate some inconsistencies in the naming of abstract vs. concrete 
> types, that have been causing people grief.
>
> So:
>
>> Abstract Concrete
>> Signed (Integer) Int*
>> Unsigned (Integer) UInt*
>> Float Flt*
>> Decimal Dec*
>> Array Arr
>> Vector Vec
>> Matrix Mat
>> String Str (maybe Str{Binary}, Str{ASCII}, Str{UTF8}, Str{UTF16}, 
>> Str{UTF32})
>
>
> ​

[julia-users] Re: [ANN] MXNet.jl - Flexible and Efficient Deep Learning for Julia

[Alireza Nejati]

Nice!

Any plans on merging this functionality with that of Mocha.jl?

[julia-users] Re: How to get first number from Int64

[Alireza Nejati]

Michele's solution is preferred here, but you can also do it like this:

string(lista[3])[1]

[julia-users] Emacs mode for keyword pair matching or highlighting

[Jan Kybic]

Dear all,

in Julia, blocks of code are delimited by pairs of keywords such as 
module/end, function/end, for/end, quote/end etc.  Sometimes I get the 
pairings between the opening and closing keyword wrong, which leads to at 
least syntax errors, but sometimes other hard to catch errors. 
It would be useful to be able to find at a glance very quickly, where each 
block starts and ends. Emacs already seems to understand Julia syntax, 
 when I do 'indent-region', the results are usually correct. However, in 
longer functions, I still need to verify manually, if what I think is the 
beginning of the block is at the same indentation level as the closing 
'end'. What I would like is something like the 'rainbow-mode', which colors 
parentheses (but only parentheses) with matching colors, which is very 
useful for Lisp-like languages. I also liked the idea of the 'smartparens' 
package, which highlights the matching keyword delimiter if you put a 
cursor over the other one - it however seems to be confused by 'end' being 
a universal closing keyword, so it just finds the first 'end', even if it 
is not on the right level.

Would you have any other suggestions, what other Emacs package I could use 
to get the desired effect?

Thanks,

Jan

[julia-users] Re: [ANN] DataStreams.jl, CSV.jl, SQLite.jl New Releases

[bernhard]

Hi Jacob

Thank you.
On my machine (Win7) SQLite is not working though. Either Julia crashes 
after "using SQLite" or I get the error below:


Executing .juliarc.jl... done
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-w64-mingw32

julia> versioninfo()
Julia Version 0.4.0
Commit 0ff703b* (2015-10-08 06:20 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> using SQLite
INFO: Recompiling stale cache file 
C:\Users\workstation\.julia\lib\v0.4\SQLite.j
i for module SQLite.

Please submit a bug report with steps to reproduce this fault, and any 
error mes
sages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x64f749d2 -- 
jl_deserialize_lambdas_fr
om_mod at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
(unknown li
ne)
jl_deserialize_lambdas_from_mod at C:\Program 
Files\Juno\resources\app\julia\bin
\libjulia.dll (unknown line)
jl_deserialize_lambdas_from_mod at C:\Program 
Files\Juno\resources\app\julia\bin
\libjulia.dll (unknown line)
jl_restore_incremental at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia
.dll (unknown line)
_require_from_serialized at loading.jl:84
jlcall__require_from_serialized_3803 at  (unknown line)
jl_apply_generic at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll (
unknown line)
require at loading.jl:225
jlcall_require_3246 at  (unknown line)
jl_apply_generic at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll (
unknown line)
jl_init_serializer at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll
 (unknown line)
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_eval_module_expr at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dl
l (unknown line)
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_eval_module_expr at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dl
l (unknown line)
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_parse_eval_all at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll
(unknown line)
jl_load_ at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
(unknown
line)
include at boot.jl:261
jl_apply_generic at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll (
unknown line)
include_from_node1 at loading.jl:304
jl_apply_generic at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll (
unknown line)
jl_interpret_toplevel_expr at C:\Program 
Files\Juno\resources\app\julia\bin\libj
ulia.dll (unknown line)
jl_interpret_toplevel_thunk_with at C:\Program 
Files\Juno\resources\app\julia\bi
n\libjulia.dll (unknown line)
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
(unknow
n line)
anonymous at none:2
jl_eval_with_compiler_p at C:\Program 
Files\Juno\resources\app\julia\bin\libjuli
a.dll (unknown line)
jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
(unknow
n line)
process_options at client.jl:284
_start at client.jl:411
jlcall__start_1845 at  (unknown line)
jl_apply_generic at C:\Program 
Files\Juno\resources\app\julia\bin\libjulia.dll (
unknown line)
unknown function (ip: 004018D0)
unknown function (ip: 0040282B)
unknown function (ip: 0040140C)
unknown function (ip: 0040153B)
BaseThreadInitThunk at C:\Windows\system32\kernel32.dll (unknown line)
RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
ERROR: LoadError: Failed to precompile DataStreams to 
C:\Users\workstation\.juli
a\lib\v0.4\DataStreams.ji
 in error at error.jl:21
while loading C:\Users\workstation\.julia\SQLite\src\SQLite.jl, in 
expression st
arting on line 1
ERROR: Failed to precompile SQLite to 
C:\Users\workstation\.julia\lib\v0.4\SQLit
e.ji
 in error at error.jl:21

julia>


Am Dienstag, 27. Oktober 2015 06:25:50 UTC+1 schrieb Jacob Quinn:
>
> Hey everyone,
>
> I know it's been mentioned here and there, but now it's official: two new 
> packages have been officially released for 0.4, DataStreams.jl and CSV.jl. 
> SQLite.jl has also gone through a big overhaul to modernize the code and 
> rework the data processing interface.
>
> DataStreams.jl is a 

[julia-users] convert Array{Float,1} to Array{Float,2)?

[michael . creel]

I have a function that expects a Matrix argument, but for the case I'm 
working on, the natural way to construct the argument gives a vector. So, 
suppose I have a vector, e.g., a=rand(10). What is the best way to convert 
this to a 10X1 array? I can do it using a loop, but I thought there might 
be a built-in convertor, which I fail to find.
Thx

[julia-users] ESS and autocompletion for Julia

[Ivan Bocharov]

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] 900mb csv loading in Julia failed: memory comparison vs python pandas and R

[bernhard]

Thanks. I appreciate your efforts.
Looking forward to 0.4.1. in that case.

Am Dienstag, 27. Oktober 2015 06:30:32 UTC+1 schrieb Jacob Quinn:
>
> Just a quick follow-up here: after some benchmarking of my own on a 
> windows machine, the culprit ended up being a deathly slow `strtod` system 
> library function on windows. It takes a few hoops to get the performance 
> right, which I discovered is already done in Base Julia, it just wasn't 
> exported.
>
> My PR to Base Julia  has 
> been accepted and is backport pending, so once Julia 0.4.1 is released, 
> CSV.jl will be updated to use the new code and will require that version of 
> Julia to enable similar great performance cross-platform.
>
> -Jacob
>
> On Wed, Oct 14, 2015 at 3:51 AM, bernhard  > wrote:
>
>> with readtable the julia process goes up to 6.3 GB and stays there. It 
>> takes 95 seconds. (@time shows "373M, allocations: 13GB, 7% GC time")
>> I will try Jacob's approach again.
>>
>>
>> Am Mittwoch, 14. Oktober 2015 10:59:06 UTC+2 schrieb Milan Bouchet-Valat:
>>>
>>> Le mercredi 14 octobre 2015 à 00:15 -0700, Grey Marsh a écrit : 
>>> > Done with the testing in the cloud instance. 
>>> > It works and the timings in my case 
>>> > 
>>> > 58.346345 seconds (694.00 M allocations: 12.775 GB, 2.63% gc time) 
>>> > 
>>> > result of "top" command:  VIRT: 11.651g RES: 3.579g 
>>> > 
>>> > ~13gb memory for a 900mb file! 
>>> > Thanks to Jacob atleast I was able check that the process works. 
>>> As Yichao noted, at no point in the import did Julia use 13GB of RAM. 
>>> That's the total amount of memory that was allocated and freed by 
>>> pieces (694M of them). You'd need to watch the Julia process while 
>>> working to see what's the maximum value of RES when importing. 
>>>
>>>
>>> Regards 
>>>
>>> > On Wednesday, October 14, 2015 at 12:10:02 PM UTC+5:30, bernhard 
>>> > wrote: 
>>> > > Jacob 
>>> > > 
>>> > > I do run into the same issue as Grey. the step 
>>> > > ds = DataStreams.DataTable(f); 
>>> > > gets stuck. 
>>> > > I also tried this with a smaller file (150MB) which I have. This 
>>> > > file is read by readtable in 15s. But the DataTable function 
>>> > > freezes. I use 0.4 on Windows 7. 
>>> > > 
>>> > > I note that your code did work on a tiny file though (40 lines or 
>>> > > so). 
>>> > > I do get a dataframe, but when I show it (by simply typing df, or 
>>> > > dump(df)) Julia crashes... 
>>> > > 
>>> > > Bernhard 
>>> > > 
>>> > > 
>>> > > Am Mittwoch, 14. Oktober 2015 06:54:16 UTC+2 schrieb Grey Marsh: 
>>> > > > I am using Julia 0.4 for this purpose, if that's what is meant by 
>>> > > > "0.4 only". 
>>> > > > 
>>> > > > On Wednesday, October 14, 2015 at 9:53:09 AM UTC+5:30, Jacob 
>>> > > > Quinn wrote: 
>>> > > > > Oh yes, I forgot to mention that the CSV/DataStreams code is 
>>> > > > > 0.4 only. Definitely interested to hear about any 
>>> > > > > results/experiences though. 
>>> > > > > 
>>> > > > > -Jacob 
>>> > > > > 
>>> > > > > On Tue, Oct 13, 2015 at 10:11 PM, Yichao Yu  
>>> > > > > wrote: 
>>> > > > > > On Wed, Oct 14, 2015 at 12:02 AM, Grey Marsh < 
>>> > > > > > kd.k...@gmail.com> wrote: 
>>> > > > > > > @Jacob, I tried your approach. Somehow it got stuck in the 
>>> > > > > > "@time ds = 
>>> > > > > > > DataStreams.DataTable(f)" line. After 15 minutes running, 
>>> > > > > > julia is using 
>>> > > > > > > ~500mb and 1 cpu core with no sign of end. The memory use 
>>> > > > > > has been almost 
>>> > > > > > > same for the whole duration of 15 minutes. I'm letting it 
>>> > > > > > run, hoping that 
>>> > > > > > > it finishes after some time. 
>>> > > > > > > 
>>> > > > > > > From your run, I can see it needs 12gb memory which is 
>>> > > > > > higher than my 
>>> > > > > > > machine memory of 8gb. could it be the problem? 
>>> > > > > > 
>>> > > > > > 12GB is the total number of memory ever allocated during the 
>>> > > > > > timing. A 
>>> > > > > > lot of them might be intermediate results that are freed by 
>>> > > > > > the GC. 
>>> > > > > > Also, from the output of @time, it looks like 0.4. 
>>> > > > > > 
>>> > > > > > > 
>>> > > > > > > On Wednesday, October 14, 2015 at 2:28:09 AM UTC+5:30, 
>>> > > > > > Jacob Quinn wrote: 
>>> > > > > > >> 
>>> > > > > > >> I'm hesitant to suggest, but if you're in a bind, I have 
>>> > > > > > an experimental 
>>> > > > > > >> package for fast CSV reading. The API has stabilized 
>>> > > > > > somewhat over the last 
>>> > > > > > >> week and I'm planning a more broad release soon, but I'd 
>>> > > > > > still consider it 
>>> > > > > > >> alpha mode. That said, if anyone's willing to give it a 
>>> > > > > > drive, you just need 
>>> > > > > > >> to 
>>> > > > > > >> 
>>> > > > > > >> Pkg.add("Libz") 
>>> > > > > > >> Pkg.add("NullableArrays") 
>>> > > > > > >> Pkg.clone("https://github.com/quinnj/DataStreams.jl;) 
>>> > > > > > >> Pkg.clone("https://github.com/quinnj/CSV.jl;) 
>>> > 

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

[FANG Colin]

Thank you. In that case I will happily stick with `in`.

On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>
> There is no difference, as far as I know.
>
> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems to 
> be used more for variables (i in mylist). But using 'in' for everything is 
> ok too.
>
> The '=' is there for familiarity with matlab. Remember that julia's syntax 
> was in part designed to be familiar to matlab users.
>
> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>>
>> Hi All
>>
>> I have got a stupid question:
>>
>> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>>
>> Does the julia community prefer one to the other? I see use of both in 
>> the documentations and source code.
>>
>> Personally I haven't seen much use of "for i = 1:5" in other languages.
>>
>> Thanks.
>>
>

[julia-users] Re: [ANN] MXNet.jl - Flexible and Efficient Deep Learning for Julia

[Jonathan Malmaud]

See https://github.com/pluskid/Mocha.jl/issues/22#issuecomment-150876824 for 
some discussion about that. 

[julia-users] Re: low rank matrix-vector multiplication and order of operations

[Andreas Noack]

The order of operations is from left to right so the parentheses can be 
important here. We have discussed ways of executing more efficiently for 
matrix products, see https://github.com/JuliaLang/julia/issues/12065, but 
so far nothing has been implemented. In that issue, you can also see the 
reason why an explicit transpose is computed in one of your examples.

On Monday, October 26, 2015 at 3:26:12 PM UTC-4, Michael Lindon wrote:
>
> I have a somewhat large matrix-vector product to calculate, where the 
> matrix is not full rank. I can perform a low rank factorization of the nxn 
> Matrix M as M=LL' where L is nxp.  I'd like to use this information to 
> speed up the computation. Here is a minimal example:
>
> x=rand(1,100) 
> 
>  
> v=rand(1) 
> 
>  
> xx=x*x'   
> 
>  
> xt=x' 
> 
>  
> @time xx*v;   
> 
>  
> @time x*x'*v; 
> 
>  
> @time x*(x'*v);   
> 
>  
> @time x*(xt*v);
>
> here are the timings:
>
> julia> @time xx*v;
>   0.038634 seconds (8 allocations: 78.375 KB)
> julia> @time x*x'*v;
>   0.385250 seconds (17 allocations: 770.646 MB, 13.14% gc time)
> julia> @time x*(x'*v);
>   0.000662 seconds (10 allocations: 79.266 KB)
> julia> @time x*(xt*v);
>   0.000819 seconds (10 allocations: 79.266 KB)
>
> I would like to understand why x*(x'*v) is much faster than  x*x'*v, and 
> uses less memory. I would have thought the order of operations would have 
> gone from right to left but it seems the parentheses made a huge 
> difference. I also might have expected that x' would just flick a TRANS='T" 
> switch in the BLAS implementation but by the looks of it there is a very 
> large amount of memory allocation going on in x*x'*v.
>

Re: [julia-users] convert Array{Float,1} to Array{Float,2)?

[Yichao Yu]

On Tue, Oct 27, 2015 at 5:47 AM,   wrote:
> I have a function that expects a Matrix argument, but for the case I'm
> working on, the natural way to construct the argument gives a vector. So,
> suppose I have a vector, e.g., a=rand(10). What is the best way to convert
> this to a 10X1 array? I can do it using a loop, but I thought there might be
> a built-in convertor, which I fail to find.
> Thx

reshape(a, (10, 1)) if you don't mind the two to share the same
storage and you cannot resize the first one anymore.

[julia-users] Re: GUI applications with Julia

[Andreas Lobinger]

Hello,

Take a look at 
https://github.com/JuliaLang/Gtk.jl or 
https://github.com/JuliaLang/Tk.jl

Some people seem to be working on making Qt bindings (which is tied to 
Cxx.jl) but nothing is fully available.
I managed to use the GTK GUI builder (glade) with Gtk.jl, but there is 
still a lot of manual work then needed to get all the bindings (klick to 
button -> call function) working.

I also recommend to look at https://github.com/shashi/Escher.jl
for building GUIs that you use via browser.


On Monday, October 26, 2015 at 8:26:07 PM UTC+1, Piotr W wrote:
>
> Hi,
>
> I consider use of Julia in my project. I have a low experience in 
> programming in the "classical" meaning, but I have some experience in 
> programming in Mathcad. Now I would like to rewrite the algorithm I have 
> developed in Mathcad and create an application with GUI. My question is if 
> Julia is suitable for development of GUI applications? Are there any GUI 
> builders / libraries / frameworks like Qt or WPF, or could adopt I some 
> other such a library? Thanks in advance for help.
>

Re: [julia-users] Figure out how to get pointer to ge

[Yichao Yu]

On Mon, Oct 26, 2015 at 11:58 PM, Taylor Maxwell
 wrote:
> I am moving some of my code to 0.4 and I am having trouble figuring out how
> to get a pointer for beginning of a UInt matrix.  In the past I did:
>
> julia> bpt = convert(Ptr{Uint8},b)  #where b it my Uint8 matrix
>
> Ptr{Uint8} @0x7fdd243fca70
>
>
> in 0.4 I get:
>
> julia> bpt = convert(Ptr{UInt8},b)
>
> ERROR: MethodError: `convert` has no method matching
> convert(::Type{Ptr{UInt8}}, ::Array{UInt8,1})
>
> This may have arisen from a call to the constructor Ptr{UInt8}(...),
>
> since type constructors fall back to convert methods.
>
> Closest candidates are:
>
>   call{T}(::Type{T}, ::Any)
>
>   convert{T<:Union{Int8,UInt8}}(::Type{Ptr{T<:Union{Int8,UInt8}}},
> ::Cstring)
>
>   convert{T}(::Type{Ptr{T}}, ::UInt64)
>
>
> Unfortunately I am not certain any of these options match what I am looking
> for:
>
> The method used in 0.3 is:
> convert{T}(::Type{Ptr{T}},a::Array{T,N}) at pointer.jl:22
> which is:
> convert{T}(::Type{Ptr{T}}, a::Array{T}) = ccall(:jl_array_ptr, Ptr{T},
> (Any,), a)
> this obviously does not exist in 0.4.
>
> My use case is that I read in a Uint8 matrix from a PLINK .bed file format
> which is a Uint8 matrix that is a dense way to pack in genetic locus
> genotypes every two bits and every column represents a new locus.  With the
> pointer at the beginning of the Uint8 matrix, I can easily work my way down
> a column and extract the genotype calls with bit operations across the
> matrix.  This kind of work is at the edge of my understanding (i.e. pointers
> and bit operations) so despite looking at some of the code for the suggested
> convert methods I am not sure how to get back to what I originally use with
> what is available in 0.4.
>
> In 0.4 I can just make my own new convert call with the old code from 0.3
> by:
> import Base.convert
> convert{T}(::Type{Ptr{T}}, a::Array{T}) = ccall(:jl_array_ptr, Ptr{T},
> (Any,), a)
> and it get:
>
> julia> bpt = convert(Ptr{UInt8},b)
>
> Ptr{UInt8} @0x00011253ac00
>

You shouldn't need to do this. This is replaced by
`Base.unsafe_convert` for `ccall`

```
julia> Base.unsafe_convert(Ptr{Int}, Int[])
Ptr{Int64} @0x7f4e032fb700
```

See the doc for why this is changed
http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/#garbage-collection-safety

There's also `pointer(::Array)` that should have the same effect.

However, breifly looking at your use case, I think you should use
SubArray / ArrayView, or reinterpret the array, or Ref of an array
element if you are calling c function to work with it.

>
> But I wanted to know if the was a technical reason for that convert call to
> be removed in 0.4 and if using this "reinstated" convert call will do what
> it originally did in 0.3.
>
>

Re: [julia-users] convert Array{Float,1} to Array{Float,2)?

[michael . creel]

Thanks. I knew there had to be an easy way.

On Tuesday, October 27, 2015 at 12:59:43 PM UTC+1, Yichao Yu wrote:
>
> On Tue, Oct 27, 2015 at 5:47 AM,   
> wrote: 
> > I have a function that expects a Matrix argument, but for the case I'm 
> > working on, the natural way to construct the argument gives a vector. 
> So, 
> > suppose I have a vector, e.g., a=rand(10). What is the best way to 
> convert 
> > this to a 10X1 array? I can do it using a loop, but I thought there 
> might be 
> > a built-in convertor, which I fail to find. 
> > Thx 
>
> reshape(a, (10, 1)) if you don't mind the two to share the same 
> storage and you cannot resize the first one anymore. 
>

Re: [julia-users] deserialize error with closured array of functions

[Isaiah Norton]

Cross-ref StackOverflow:
http://stackoverflow.com/questions/4656/error-on-serialize-lambda-function-with-closured-data


On Sat, Oct 24, 2015 at 11:03 PM, Александр Кольцов 
wrote:

> About my problem. Code:
> ...
> p = _belineInterpolateGrid(map(t -> sin( norm(t) ), grid), grid)
> serialize(open("/data/test.function", "w"), p)
> p0 = deserialize(open("/data/test.function", "r"))
>
> >> ERROR: MethodError: `convert` has no method matching
> convert(::Type{LambdaStaticData}, ::Array{Any,1})
> This may have arisen from a call to the constructor LambdaStaticData(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert{T}(::Type{T}, ::T)
>  [inlined code] from int.jl:187
>  in deserialize at serialize.jl:536
>  [inlined code] from operators.jl:313
>  in handle_deserialize at serialize.jl:475
>  in deserialize_array at serialize.jl:614
>  in handle_deserialize at serialize.jl:463
>  [inlined code] from essentials.jl:116
>  in deserialize at serialize.jl:696
>  [inlined code] from operators.jl:313
>  in handle_deserialize at serialize.jl:475
>  [inlined code] from int.jl:187
>  in deserialize at serialize.jl:482
>  [inlined code] from operators.jl:313
>  in handle_deserialize at serialize.jl:475
>  [inlined code] from int.jl:187
>  in deserialize at serialize.jl:538
>  [inlined code] from operators.jl:313
>  in handle_deserialize at serialize.jl:475
>  [inlined code] from int.jl:187
>  in deserialize at serialize.jl:435
>
> In function "_belineInterpolateGrid" I used closure of Array{Function}:
>
> function _belineInterpolateGrid(PP, Grid)
> ...
> P = Array(Function, N-1, M-1)
> ...
> poly = (x,y) -> begin
>  i_x, i_y =  i(x, y)
>  return P[i_x, i_y](x, y)
> end
> return poly
> end
>
> What's happened and can I fix It? Or this is a bug?
>

[julia-users] Re: low rank matrix-vector multiplication and order of operations

[Michael Lindon]

Thanks for the reply, this is what I was looking for =)

[julia-users] [Gadfly] : Help regarding plotting

[Vishnu Raj]

Hello,

I have a couple of doubts about using Gadfly for plotting
1. How to set a line style ( like "--"/"-.-" etc)?
2. How to put a legend in a figure, inside the figure? ( I came across a 
solution which first converts data to plot to DataFrames, but this puts 
legend outside the figure, effectively reducing my actual plot area )

- vish

Re: [julia-users] Re: alternate LISP integration ...

[Jeff Bezanson]

Then of course there's always
https://github.com/JeffBezanson/femtolisp/blob/master/tiny/lisp.c,
which compiles to a 22k executable (after stripping) on my machine.

On Tue, Oct 27, 2015 at 11:54 AM, Steven G. Johnson
 wrote:
>
>
> On Tuesday, October 27, 2015 at 10:31:52 AM UTC-4, Jeff Bezanson wrote:
>>
>> This looks like a much more serious project than femtolisp, but I
>> would like to dispute the claim that it is "lightweight". From the
>> readme, it depends on python/pypy, libffi, libedit, libuv, and
>> libboost, and is 10MB which makes it literally 100 times larger than
>> femtolisp.
>
>
> There used to be a Scheme implementation called "SILK" for "Scheme in 50
> kilobytes" (L = 50 in Roman numerals), and I remember that the author had a
> comment to the effect: "If a future version of this bloats to over 50k, I
> will have to rename it to SICK" (C = 100).
>
> I can't seem to find it anymore, though.

Re: [julia-users] Re: [ANN] DataStreams.jl, CSV.jl, SQLite.jl New Releases

[Stefan Karpinski]

Please do file an issue on the SQLite.jl repo:
https://github.com/JuliaDB/SQLite.jl/issues.

On Tue, Oct 27, 2015 at 5:47 AM, bernhard  wrote:

> Hi Jacob
>
> Thank you.
> On my machine (Win7) SQLite is not working though. Either Julia crashes
> after "using SQLite" or I get the error below:
>
>
> Executing .juliarc.jl... done
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
>
> julia> versioninfo()
> Julia Version 0.4.0
> Commit 0ff703b* (2015-10-08 06:20 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> using SQLite
> INFO: Recompiling stale cache file
> C:\Users\workstation\.julia\lib\v0.4\SQLite.j
> i for module SQLite.
>
> Please submit a bug report with steps to reproduce this fault, and any
> error mes
> sages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x64f749d2 --
> jl_deserialize_lambdas_fr
> om_mod at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown li
> ne)
> jl_deserialize_lambdas_from_mod at C:\Program
> Files\Juno\resources\app\julia\bin
> \libjulia.dll (unknown line)
> jl_deserialize_lambdas_from_mod at C:\Program
> Files\Juno\resources\app\julia\bin
> \libjulia.dll (unknown line)
> jl_restore_incremental at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia
> .dll (unknown line)
> _require_from_serialized at loading.jl:84
> jlcall__require_from_serialized_3803 at  (unknown line)
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> require at loading.jl:225
> jlcall_require_3246 at  (unknown line)
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> jl_init_serializer at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll
>  (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_module_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dl
> l (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_module_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dl
> l (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_parse_eval_all at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown line)
> jl_load_ at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown
> line)
> include at boot.jl:261
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> include_from_node1 at loading.jl:304
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> jl_interpret_toplevel_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libj
> ulia.dll (unknown line)
> jl_interpret_toplevel_thunk_with at C:\Program
> Files\Juno\resources\app\julia\bi
> n\libjulia.dll (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknow
> n line)
> anonymous at none:2
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknow
> n line)
> process_options at client.jl:284
> _start at client.jl:411
> jlcall__start_1845 at  (unknown line)
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> unknown function (ip: 004018D0)
> unknown function (ip: 0040282B)
> unknown function (ip: 0040140C)
> unknown function (ip: 0040153B)
> BaseThreadInitThunk at C:\Windows\system32\kernel32.dll (unknown line)
> RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
> ERROR: LoadError: Failed to precompile DataStreams to
> C:\Users\workstation\.juli
> a\lib\v0.4\DataStreams.ji
>  in error at error.jl:21
> while loading C:\Users\workstation\.julia\SQLite\src\SQLite.jl, in
> expression st
> arting on line 1
> ERROR: Failed to precompile SQLite to
> C:\Users\workstation\.julia\lib\v0.4\SQLit
> e.ji
>  in error at 

Re: [julia-users] mixed arrays

[Michela Di Lullo]

 #step1: cycle definition
  ciclo=[(0,0,0)]
  for j=1:(size(Cb,2))
if (Cb[i,j]!=0)
  push!(ciclo,(BrancheS[j].line, BrancheS[j].from, BrancheS[j].to))
end
  end
  ciclo=ciclo[2:end]

  #step3: cycle capacity
  y=0
  for f=1:length(ciclo)
  y+=BrancheS[ciclo[f][1]].p_flow_max
  end

  #step2: subcycle definition and preliminary filtering on subcycles
  sottociclo=collect(combinations(ciclo,0))
  for z=1:length(ciclo)
if(2*BrancheS[ciclo[z][1]].p_flow_max>y)
  sottociclo=union(sottociclo,[ciclo[z]])
end
  end
for f=2:length(ciclo)
  sottociclo=union(sottociclo,combinations(ciclo,f))
end
  sottociclo=sottociclo[2:end]

Il giorno martedì 27 ottobre 2015 16:12:51 UTC+1, Tom Breloff ha scritto:
>
> The first row should be a vector of tuples, just like the other elements.  
> Please 
> post the code which generates sottociclo and maybe we can help further. 
>
> On Tuesday, October 27, 2015, Michela Di Lullo  > wrote:
>
>> Hello everyone,
>>
>> I have: 
>>
>> *sottociclo*
>>
>> *5-element Array{Any,1}:*
>>
>> * (1,2,5)  *
>>
>> * [(1,1,2),(2,1,5)]*
>>
>> * [(1,1,2),(5,2,5)]*
>>
>> * [(2,1,5),(5,2,5)]*
>>
>> * [(1,1,2),(2,1,5),(5,2,5)]*
>>
>>
>> *julia> **length(sottociclo[1])*
>>
>> *3*
>>
>>
>> *julia> **length(sottociclo[2])*
>>
>> *2*
>>
>> How might I modify the code such that *length(sottociclo[1])=1? *
>> I need length(sottociclo[*]) be equal to the number of tuple in row *...
>> Thanks in advance for any help,
>>
>> Michela 
>>
>

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

[feza]

+1 @Tom Breloff .  
I was confused about this when starting out. Comparing   `for i in 1:3` vs 
 `for i = 1:3`, even though I regularly use matlab if you think about it 
for `i = 1:10` doesn't really make a lot of sense. It would be nice if it 
was just one way as opposed to the confusion about whether = or in should 
be used.

On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:
>
> It's harmless, sure, but I would prefer that everyone uses "in" 
> exclusively so that there's one less thing to waste brainpower on.  You 
> don't say "for each x equals the range 1 to n", you say "for each x in the 
> range 1 to n".  I don't think "=" has a place here at all except to allow 
> copy/pasting of Matlab code (which creates other performance problems 
> anyways).
>
> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski  > wrote:
>
>> My general approach is to only use = when the RHS is an explicit range, 
>> as in `for i = 1:n`. For everything else I use `for i in v`. I would be ok 
>> with dropping the = syntax at some point, but it seems pretty harmless to 
>> have it.
>>
>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin > > wrote:
>>
>>> Thank you. In that case I will happily stick with `in`.
>>>
>>>
>>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

 There is no difference, as far as I know.

 '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems 
 to be used more for variables (i in mylist). But using 'in' for everything 
 is ok too.

 The '=' is there for familiarity with matlab. Remember that julia's 
 syntax was in part designed to be familiar to matlab users.

 On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>
> Hi All
>
> I have got a stupid question:
>
> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>
> Does the julia community prefer one to the other? I see use of both in 
> the documentations and source code.
>
> Personally I haven't seen much use of "for i = 1:5" in other 
> languages.
>
> Thanks.
>

>>
>

Re: [julia-users] Re: [ANN] DataStreams.jl, CSV.jl, SQLite.jl New Releases

[Jacob Quinn]

Hey bernhard (sorry if that's not remotely close to your name, it's what
shows up in my gmail),

I think you were probably tracking CSV.jl master (i.e. at one point, you
probably did Pkg.checkout("CSV")). I was playing around with some
precompilation stuff last night, so you probably got caught in that snag.
I'm not exactly sure what you need to do, but some combination of:

Pkg.rm("CSV')
Pkg.add("CSV")

or

Pkg.free("CSV")
Pkg.update()

or

Pkg.checkout("CSV","v0.0.2")

that way, you'll get back on the current release of CSV and nothing will
try to precompile. If none of those options seeme to work, you may have to
manually go into ~/.julia/lib/v0.4 and delete any CSV.jl or
NullableArrays.jl files in that directory (those are the attempted compiled
files). Let me know if that helps.

-Jacob


On Tue, Oct 27, 2015 at 3:47 AM, bernhard  wrote:

> Hi Jacob
>
> Thank you.
> On my machine (Win7) SQLite is not working though. Either Julia crashes
> after "using SQLite" or I get the error below:
>
>
> Executing .juliarc.jl... done
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
>
> julia> versioninfo()
> Julia Version 0.4.0
> Commit 0ff703b* (2015-10-08 06:20 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> using SQLite
> INFO: Recompiling stale cache file
> C:\Users\workstation\.julia\lib\v0.4\SQLite.j
> i for module SQLite.
>
> Please submit a bug report with steps to reproduce this fault, and any
> error mes
> sages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x64f749d2 --
> jl_deserialize_lambdas_fr
> om_mod at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown li
> ne)
> jl_deserialize_lambdas_from_mod at C:\Program
> Files\Juno\resources\app\julia\bin
> \libjulia.dll (unknown line)
> jl_deserialize_lambdas_from_mod at C:\Program
> Files\Juno\resources\app\julia\bin
> \libjulia.dll (unknown line)
> jl_restore_incremental at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia
> .dll (unknown line)
> _require_from_serialized at loading.jl:84
> jlcall__require_from_serialized_3803 at  (unknown line)
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> require at loading.jl:225
> jlcall_require_3246 at  (unknown line)
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> jl_init_serializer at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll
>  (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_module_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dl
> l (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_module_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dl
> l (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_parse_eval_all at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown line)
> jl_load_ at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknown
> line)
> include at boot.jl:261
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> include_from_node1 at loading.jl:304
> jl_apply_generic at C:\Program
> Files\Juno\resources\app\julia\bin\libjulia.dll (
> unknown line)
> jl_interpret_toplevel_expr at C:\Program
> Files\Juno\resources\app\julia\bin\libj
> ulia.dll (unknown line)
> jl_interpret_toplevel_thunk_with at C:\Program
> Files\Juno\resources\app\julia\bi
> n\libjulia.dll (unknown line)
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknow
> n line)
> anonymous at none:2
> jl_eval_with_compiler_p at C:\Program
> Files\Juno\resources\app\julia\bin\libjuli
> a.dll (unknown line)
> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll
> (unknow
> n line)
> process_options at client.jl:284
> _start at client.jl:411
> jlcall__start_1845 at  (unknown line)
> jl_apply_generic at C:\Program
> 

Re: [julia-users] [Gadfly] : Help regarding plotting

[Tom Breloff]

I'm not sure about putting a gadfly legend inside the figure.  It's likely
possible but I haven't seen how to do it.

As for plotting generally, you should check out my package:
https://github.com/tbreloff/Plots.jl.  There are examples which show how to
choose line styles, etc.

On Tue, Oct 27, 2015 at 11:29 AM, Vishnu Raj  wrote:

> Hello,
>
> I have a couple of doubts about using Gadfly for plotting
> 1. How to set a line style ( like "--"/"-.-" etc)?
> 2. How to put a legend in a figure, inside the figure? ( I came across a
> solution which first converts data to plot to DataFrames, but this puts
> legend outside the figure, effectively reducing my actual plot area )
>
> - vish
>

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

[Glen O]

An alternative way to read it is "for x equals 1 through 5". It definitely 
makes sense for a range. And I don't think anyone has any difficulty 
intuitively understanding a for loop using =, even if "in" reads slightly 
better.

Incidentally, it's not just Matlab that does it. Most variants of Basic use 
it, as does Delphi, Fortran, Lua, Pascal, and Scilab. One thing you might 
notice about most of the languages on the list is that they're languages 
that were more oriented towards scientific computing, or languages designed 
to teach programming concepts. It's a more intuitive notation when applied 
to basic for loops (that is, where the variable is simply being incremented 
a fixed number of times), with "in" really being of use when you want to 
iterate over a data structure, rather than to iterate with a counting 
variable.

I agree with Stefan's approach of using "=" for explicit ranges (which 
represent the phrasing "for x equals 1 through 5") and "in" for application 
to other structures ("for each x in the vector A"), with the other notation 
being usable but somewhat discouraged. Besides, it's not like there's any 
other natural use for = in that context.

Incidentally, it would be nice if ∈ could be used as another option - it's 
just another way of saying "in", but it would look nicer in certain 
mathematical contexts, and it's not like the symbol would be used in 
another way in that position.

On Wednesday, 28 October 2015 00:26:44 UTC+10, Tom Breloff wrote:
>
> It's harmless, sure, but I would prefer that everyone uses "in" 
> exclusively so that there's one less thing to waste brainpower on.  You 
> don't say "for each x equals the range 1 to n", you say "for each x in the 
> range 1 to n".  I don't think "=" has a place here at all except to allow 
> copy/pasting of Matlab code (which creates other performance problems 
> anyways).
>
> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski  > wrote:
>
>> My general approach is to only use = when the RHS is an explicit range, 
>> as in `for i = 1:n`. For everything else I use `for i in v`. I would be ok 
>> with dropping the = syntax at some point, but it seems pretty harmless to 
>> have it.
>>
>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin > > wrote:
>>
>>> Thank you. In that case I will happily stick with `in`.
>>>
>>>
>>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

 There is no difference, as far as I know.

 '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems 
 to be used more for variables (i in mylist). But using 'in' for everything 
 is ok too.

 The '=' is there for familiarity with matlab. Remember that julia's 
 syntax was in part designed to be familiar to matlab users.

 On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>
> Hi All
>
> I have got a stupid question:
>
> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>
> Does the julia community prefer one to the other? I see use of both in 
> the documentations and source code.
>
> Personally I haven't seen much use of "for i = 1:5" in other 
> languages.
>
> Thanks.
>

>>
>

[julia-users] [ANN] MXNet.jl v0.0.3 - Flexible and Efficient Deep Learning for Julia

[Chiyuan Zhang]

Checkout the examples 
 and the documents 
.

Relation to Mocha.jl: currently I will maintain both packages, but I will 
treat MXNet.jl as a successor to Mocha.jl when the project become more 
mature. dmlc/mxnet is a collaboration from authors of multiple different 
deep learning libraries and we provide support for Python, R, and Julia 
(and maybe more). MXNet.jl introduce an external dependency, but the 
default CPU only dependency is very easy to build automatically, basically 
acting as the CPU Backend of Mocha.jl. For GPUs, the built-in multi-GPU of 
MXNet.jl support is definitely attractive when comparing to Mocha.jl.

v.0.03 (2015.10.27)
   
   - Model prediction API.
   - Model checkpoint loading and saving.
   - IJulia Notebook example of using pre-trained imagenet model as 
   classifier.
   - Symbol saving and loading.
   - NDArray saving and loading.
   - Optimizer gradient clipping.
   - Model training callback APIs, default checkpoint and speedometer 
   callbacks.
   - Julia Array / NDArray data iterator.
   - Sphinx documentation system and documents for dynamically imported 
   libmxnet APIs.


Enjoy,
pluskid

[julia-users] mixed arrays

[Michela Di Lullo]

Hello everyone,

I have: 

*sottociclo*

*5-element Array{Any,1}:*

* (1,2,5)  *

* [(1,1,2),(2,1,5)]*

* [(1,1,2),(5,2,5)]*

* [(2,1,5),(5,2,5)]*

* [(1,1,2),(2,1,5),(5,2,5)]*


*julia> **length(sottociclo[1])*

*3*


*julia> **length(sottociclo[2])*

*2*

How might I modify the code such that *length(sottociclo[1])=1? *
I need length(sottociclo[*]) be equal to the number of tuple in row *...
Thanks in advance for any help,

Michela 

Re: [julia-users] mixed arrays

[Tom Breloff]

The first row should be a vector of tuples, just like the other
elements.  Please
post the code which generates sottociclo and maybe we can help further.

On Tuesday, October 27, 2015, Michela Di Lullo 
wrote:

> Hello everyone,
>
> I have:
>
> *sottociclo*
>
> *5-element Array{Any,1}:*
>
> * (1,2,5)  *
>
> * [(1,1,2),(2,1,5)]*
>
> * [(1,1,2),(5,2,5)]*
>
> * [(2,1,5),(5,2,5)]*
>
> * [(1,1,2),(2,1,5),(5,2,5)]*
>
>
> *julia> **length(sottociclo[1])*
>
> *3*
>
>
> *julia> **length(sottociclo[2])*
>
> *2*
>
> How might I modify the code such that *length(sottociclo[1])=1? *
> I need length(sottociclo[*]) be equal to the number of tuple in row *...
> Thanks in advance for any help,
>
> Michela
>

Re: [julia-users] Re: [ANN] DataStreams.jl, CSV.jl, SQLite.jl New Releases

[bernhard]

Ok. I can open an issue. Thank you for the hint.
Jacob. I will get back to you soon.

Am Dienstag, 27. Oktober 2015 16:02:29 UTC+1 schrieb Stefan Karpinski:
>
> Please do file an issue on the SQLite.jl repo: 
> https://github.com/JuliaDB/SQLite.jl/issues.
>
> On Tue, Oct 27, 2015 at 5:47 AM, bernhard  > wrote:
>
>> Hi Jacob
>>
>> Thank you.
>> On my machine (Win7) SQLite is not working though. Either Julia crashes 
>> after "using SQLite" or I get the error below:
>>
>>
>> Executing .juliarc.jl... done
>>_
>>_   _ _(_)_ |  A fresh approach to technical computing
>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>_ _   _| |_  __ _   |  Type "?help" for help.
>>   | | | | | | |/ _` |  |
>>   | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
>>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
>> |__/   |  x86_64-w64-mingw32
>>
>> julia> versioninfo()
>> Julia Version 0.4.0
>> Commit 0ff703b* (2015-10-08 06:20 UTC)
>> Platform Info:
>>   System: Windows (x86_64-w64-mingw32)
>>   CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
>>   LAPACK: libopenblas64_
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>> julia> using SQLite
>> INFO: Recompiling stale cache file 
>> C:\Users\workstation\.julia\lib\v0.4\SQLite.j
>> i for module SQLite.
>>
>> Please submit a bug report with steps to reproduce this fault, and any 
>> error mes
>> sages that follow (in their entirety). Thanks.
>> Exception: EXCEPTION_ACCESS_VIOLATION at 0x64f749d2 -- 
>> jl_deserialize_lambdas_fr
>> om_mod at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
>> (unknown li
>> ne)
>> jl_deserialize_lambdas_from_mod at C:\Program 
>> Files\Juno\resources\app\julia\bin
>> \libjulia.dll (unknown line)
>> jl_deserialize_lambdas_from_mod at C:\Program 
>> Files\Juno\resources\app\julia\bin
>> \libjulia.dll (unknown line)
>> jl_restore_incremental at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia
>> .dll (unknown line)
>> _require_from_serialized at loading.jl:84
>> jlcall__require_from_serialized_3803 at  (unknown line)
>> jl_apply_generic at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll (
>> unknown line)
>> require at loading.jl:225
>> jlcall_require_3246 at  (unknown line)
>> jl_apply_generic at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll (
>> unknown line)
>> jl_init_serializer at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll
>>  (unknown line)
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_eval_module_expr at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dl
>> l (unknown line)
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_eval_module_expr at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dl
>> l (unknown line)
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_parse_eval_all at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll
>> (unknown line)
>> jl_load_ at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
>> (unknown
>> line)
>> include at boot.jl:261
>> jl_apply_generic at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll (
>> unknown line)
>> include_from_node1 at loading.jl:304
>> jl_apply_generic at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll (
>> unknown line)
>> jl_interpret_toplevel_expr at C:\Program 
>> Files\Juno\resources\app\julia\bin\libj
>> ulia.dll (unknown line)
>> jl_interpret_toplevel_thunk_with at C:\Program 
>> Files\Juno\resources\app\julia\bi
>> n\libjulia.dll (unknown line)
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
>> (unknow
>> n line)
>> anonymous at none:2
>> jl_eval_with_compiler_p at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjuli
>> a.dll (unknown line)
>> jl_f_tuple at C:\Program Files\Juno\resources\app\julia\bin\libjulia.dll 
>> (unknow
>> n line)
>> process_options at client.jl:284
>> _start at client.jl:411
>> jlcall__start_1845 at  (unknown line)
>> jl_apply_generic at C:\Program 
>> Files\Juno\resources\app\julia\bin\libjulia.dll (
>> unknown line)
>> unknown function (ip: 004018D0)
>> unknown function (ip: 0040282B)
>> unknown function (ip: 0040140C)
>> unknown function (ip: 0040153B)
>> BaseThreadInitThunk at C:\Windows\system32\kernel32.dll (unknown line)
>> RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
>> ERROR: LoadError: Failed 

[julia-users] Re: pmap and DataStructures.OrderedDict

[Daniel Arndt]

Hi Dan,

It looks like you're running into the same issue I was, where the 
underlying HashDict cannot be serialized correctly to send to the other 
processes. 

I put up a pull request 
(https://github.com/JuliaLang/DataStructures.jl/pull/138) yesterday to 
hopefully fix this, feedback is appreciated. Apply these changes to your 
DataStructures.jl and see if that works.

Alternatively, as a temporory workaround, you can override the 
Base.(de)serialize methods in your own code.

Cheers,
Another Dan

On Tuesday, 27 October 2015 05:02:40 UTC-3, Daniel O'Malley wrote:
>
> I've recently encountered problems using pmap on a function that returns a 
> DataStructures.OrderedDict.
>
> import DataStructures
> @everywhere function f(x)
> return DataStructures.OrderedDict(zip(["x"], [x]))
> end
> pmap(f, [1, 2])
>
> If the above code is run in a "julia -p 2" environment, it produce a 
> cascade of errors that seem to begin with
>
> ERROR: MethodError: `write` has no method matching 
> write(::SerializationState{TCPSocket}, ::Int32)
>
> In the original context that this example was trying to replicate, the 
> error was
>
> ERROR: MethodError: `read` has no method matching 
> read(::SerializationState{TCPSocket}, ::Type{Int32})
>
> Does anyone have advice on how to resolve this? Should these methods exist 
> in base julia? Am I doing something wrong?
>
> Thanks for your help!
>
> Dan
>

Re: [julia-users] Re: alternate LISP integration ...

[Steven G. Johnson]

On Tuesday, October 27, 2015 at 10:31:52 AM UTC-4, Jeff Bezanson wrote:
>
> This looks like a much more serious project than femtolisp, but I 
> would like to dispute the claim that it is "lightweight". From the 
> readme, it depends on python/pypy, libffi, libedit, libuv, and 
> libboost, and is 10MB which makes it literally 100 times larger than 
> femtolisp. 
>

There used to be a Scheme implementation called "SILK" for "Scheme in 50 
kilobytes" (L = 50 in Roman numerals), and I remember that the author had a 
comment to the effect: "If a future version of this bloats to over 50k, I 
will have to rename it to SICK" (C = 100).

I can't seem to find it anymore, though. 

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

[Glen O]

"When calculating a Fibonacci number, we have to apply F_n=F_(n-1)+F_(n-2) 
repeatedly. So to find F_6, we apply the equation for n equals 3 through 
6". Writing it as "for n in 3 through 6" or "for n in the range 3 through 
6" wouldn't make nearly as much sense.

As I said, for general iterables, like vectors, the "in" keyword makes more 
sense. But when you're talking about a counter variable, equals makes a 
much more natural expression - you're not really constructing the range 
object, you're just telling the program you want the counter to start at 
the first value, and increment until it reaches the second value.

On Wednesday, 28 October 2015 02:23:54 UTC+10, Tom Breloff wrote:
>
> It definitely makes sense for a range.
>
>
> Sorry... gotta disagree... mathematical set notation is more appropriate, 
> especially for scientific computing.  This is coming from a former matlab 
> user, btw, so it's not like I was confused by the syntax.   The "for i = 
> 1:5" syntax is actually more reminiscent of C:  "for (int i=1; i<=5; i++)", 
> and I'm guessing that the syntax originated more from that rather than 
> scientific concepts.
>
> On Tue, Oct 27, 2015 at 11:58 AM, feza  
> wrote:
>
>> +1 @Tom Breloff .  
>> I was confused about this when starting out. Comparing   `for i in 
>> 1:3` vs  `for i = 1:3`, even though I regularly use matlab if you think 
>> about it for `i = 1:10` doesn't really make a lot of sense. It would be 
>> nice if it was just one way as opposed to the confusion about whether = or 
>> in should be used.
>>
>> On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:
>>>
>>> It's harmless, sure, but I would prefer that everyone uses "in" 
>>> exclusively so that there's one less thing to waste brainpower on.  You 
>>> don't say "for each x equals the range 1 to n", you say "for each x in the 
>>> range 1 to n".  I don't think "=" has a place here at all except to allow 
>>> copy/pasting of Matlab code (which creates other performance problems 
>>> anyways).
>>>
>>> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski >> > wrote:
>>>
 My general approach is to only use = when the RHS is an explicit range, 
 as in `for i = 1:n`. For everything else I use `for i in v`. I would be ok 
 with dropping the = syntax at some point, but it seems pretty harmless to 
 have it.

 On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  wrote:

> Thank you. In that case I will happily stick with `in`.
>
>
> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>>
>> There is no difference, as far as I know.
>>
>> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' 
>> seems to be used more for variables (i in mylist). But using 'in' for 
>> everything is ok too.
>>
>> The '=' is there for familiarity with matlab. Remember that julia's 
>> syntax was in part designed to be familiar to matlab users.
>>
>> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>>>
>>> Hi All
>>>
>>> I have got a stupid question:
>>>
>>> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>>>
>>> Does the julia community prefer one to the other? I see use of both 
>>> in the documentations and source code.
>>>
>>> Personally I haven't seen much use of "for i = 1:5" in other 
>>> languages.
>>>
>>> Thanks.
>>>
>>

>>>
>

[julia-users] Help my Row Major brain!

[Gabriel Gellner]

I am trying my to figure out the Julian way to create a table of values 
(matrix) from a function that returns multiple values. As this is really 
thinking about the problem as a function that generates the rows of the 
table it feels super awkward to do this in Julia currently. For example, 
lets say I have a function of the form:

function exact_solution(t)

[julia-users] Re: Help my Row Major brain!

[Gabriel Gellner]

Okay sorry tab seems to send ...

I am trying my to figure out the Julian way to create a table of values 
(matrix) from a function that returns multiple values. As this is really 
thinking about the problem as a function that generates the rows of the 
table it feels super awkward to do this in Julia currently. For example, 
lets say I have a function of the form:

function exact(t)
yout = zeros(2)
yout[1] = 3.0*exp(t) - 2.0*exp(t)
yout[2] = exp(t) + 2.0*exp(t)
yout
end

then what i want is a matrix of these solutions so my first thought is to do

esol = [exact(t) for t in linspace(0, 10, 100)]
hcat(esol...)'

is this the idiomatic solution?

Is there a better way to do this? How do people generally deal with Array 
or Arrays. Feels weird to me currently.

Gabriel


On Tuesday, 27 October 2015 09:31:22 UTC-7, Gabriel Gellner wrote:
>
> I am trying my to figure out the Julian way to create a table of values 
> (matrix) from a function that returns multiple values. As this is really 
> thinking about the problem as a function that generates the rows of the 
> table it feels super awkward to do this in Julia currently. For example, 
> lets say I have a function of the form:
>
> function exact_solution(t)
>
>

Re: [julia-users] Re: Re: are array slices views in 0.4?

[Stefan Karpinski]

Yes, I'm concerned about this as well. I'm sure we'll come up with
something. Maybe allow using the old behavior during a transitional period
with something like `using OldArrays` and then when you've gotten the
chance to double check your code, you can delete that line and move to the
new behavior. We'll have to see.

On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff 
wrote:

> Are there plans to throw deprecation warnings in julia 0.5 whenever one
> slices an array with [], and then reuse the [] syntax to return views in
> julia 0.6? That would be approach that is consistent with previous changes
> of functionality, right?
>
>
>
> I’m very much in favor of the new design, but I’m very worried about the
> transition. There seems an enormous potential for subtle bugs to go
> undetected for a long time… the tuple change was nicely phased in, as were
> any other breaking changes since I’ve used julia (since 0.2), i.e. I always
> had the impression that as long as I just fixed all depreciation warnings
> when a new version came out, I would be good. But my understanding right
> now for the array change is that the behavior of slicing with [] will
> change drastically, with essentially no indicator where in my code I might
> run into trouble, right?
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Stefan Karpinski
> *Sent:* Monday, October 26, 2015 12:05 PM
> *To:* Julia Users 
> *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4?
>
>
>
> On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner <
> christophortn...@gmail.com> wrote:
>
> Fabian - Many thanks for your comments. This was very helpful.
>
>
>
> (c) if I want to write code now that shouldn't break with 0.5, what should
> I do?
>
>
> I think when you need a copy, just surround your getindex with a copy
> function. (e.g. copy(x[:,10]) instead of x[:,10]).
>
>
>
> But this would lead me to make two copies. I was more interested in seeing
> whether there is a guideline on how to write code now so it doesn't have to
> be rewritten for 0.5.
>
>
>
> There will be a solution in the Compat package once this change is made.
> It will probably consist of having a replacement for getindex that creates
> a slice rather than a copy so that calling copy won't result in two copies.
> I.e. it will backport the 0.5 behavior to earlier versions of Julia.
>
>
>
> Regarding this change I am also more on the sceptical side. I would very
> much prefer a copy-on-write like solution like Matlab and R provide, but I
> don't know if and how this would be possible to implement, so I don't raise
> my voice here.
> To me the main benefit of this change is that it drove the main developers
> to make array views much more performant and first class members of julia.
> As Tim Holy mentioned, the actual change seems to be be very small, but it
> needed and still needs a lot of work to make it possible.
>
>
>
> My own scepticism comes from the idea that using immutable objects
> throughout prevents bugs and one should only use mutable objects sparingly
> (primarily for performance - but I thought it shouldn't be the default)
>
>
>
> Copy-on-write is complex and leads to brittle performance properties that
> cannot be reasoned about locally. The semantics of R and Matlab also
> notoriously make it impossible to write efficient mutating functions –
> people generally end up writing C extensions to do that.
>
>
>
> It remains to be seen how this pans out, but keep in mind that C, C++,
> Java, Fortran, Julia, Python, Ruby, etc. all use mutable non-copy-on-write
> arrays everywhere and the world has not ended. Slices are a bit different,
> but NumPy, for example, creates views for slices and that works well in the
> SciPy ecosystem.
>
>
>
> Philosophically, I think that returning views from operations is
> problematic when the object being viewed is conceptually a single value –
> strings being a good example that have gone different ways in different
> languages. In C everyone thinks of strings as arrays of characters and it
> works pretty well since everyone has that in mind. In higher level
> languages, people stop thinking of strings this way, which means that
> making strings mutable or returning slices of them as views becomes
> problematic because it's at odds with how we think of strings. Arrays are
> the prototypical example of a container-like thing, so I don't think that
> this will be that confusing. If you "own" the array, then it's ok to make a
> slice and potentially mutate it – if you don't, then it's not ok. We could
> potentially add tooling to help enforce this since we know by the f! naming
> convention which functions should and shouldn't mutate their arguments.
>

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

[Tom Breloff]

>
> It definitely makes sense for a range.


Sorry... gotta disagree... mathematical set notation is more appropriate,
especially for scientific computing.  This is coming from a former matlab
user, btw, so it's not like I was confused by the syntax.   The "for i =
1:5" syntax is actually more reminiscent of C:  "for (int i=1; i<=5; i++)",
and I'm guessing that the syntax originated more from that rather than
scientific concepts.

On Tue, Oct 27, 2015 at 11:58 AM, feza  wrote:

> +1 @Tom Breloff .
> I was confused about this when starting out. Comparing   `for i in 1:3` vs
>  `for i = 1:3`, even though I regularly use matlab if you think about it
> for `i = 1:10` doesn't really make a lot of sense. It would be nice if it
> was just one way as opposed to the confusion about whether = or in should
> be used.
>
> On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:
>>
>> It's harmless, sure, but I would prefer that everyone uses "in"
>> exclusively so that there's one less thing to waste brainpower on.  You
>> don't say "for each x equals the range 1 to n", you say "for each x in the
>> range 1 to n".  I don't think "=" has a place here at all except to allow
>> copy/pasting of Matlab code (which creates other performance problems
>> anyways).
>>
>> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski 
>> wrote:
>>
>>> My general approach is to only use = when the RHS is an explicit range,
>>> as in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
>>> with dropping the = syntax at some point, but it seems pretty harmless to
>>> have it.
>>>
>>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  wrote:
>>>
 Thank you. In that case I will happily stick with `in`.


 On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>
> There is no difference, as far as I know.
>
> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems
> to be used more for variables (i in mylist). But using 'in' for everything
> is ok too.
>
> The '=' is there for familiarity with matlab. Remember that julia's
> syntax was in part designed to be familiar to matlab users.
>
> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>>
>> Hi All
>>
>> I have got a stupid question:
>>
>> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>>
>> Does the julia community prefer one to the other? I see use of both
>> in the documentations and source code.
>>
>> Personally I haven't seen much use of "for i = 1:5" in other
>> languages.
>>
>> Thanks.
>>
>
>>>
>>

Re: [julia-users] Re: julia style to resize array with initialization?

[Cameron McBride]

Yeah, looks like very similar arguments to 9147. Although not as easy to
circumvent as using zeros() or the like.

One potential "fix" could be a potential third argument to resize with the
"default / fill" value, which doesn't seem like a viable solution to the
constructors discussed in that thread.

Cameron

p.s. Thanks, Josh, but I think that solution would create a temporary array
(from zeros() call) on every resize. Perhaps successive push!(vec, 0.0)
might also be a good way (I know push allocates in chunks, resize might not
-- I haven't looked).


On Tue, Oct 27, 2015 at 10:36 AM, Stefan Karpinski 
wrote:

> I've encountered this too – it might make sense to zero out the grown
> memory. Of course there's the whole "to zero out uninitialized memory or
> not" discussion: https://github.com/JuliaLang/julia/issues/9147. I feel
> like this falls into that same category of questions.
>
> On Mon, Oct 26, 2015 at 3:59 PM, Josh Langsfeld  wrote:
>
>> You could do 'append!(vec, zeros(i-n))'.
>>
>>
>> On Monday, October 26, 2015 at 3:32:56 PM UTC-4, Cameron McBride wrote:
>>>
>>> Hi All,
>>>
>>> What's the best julian way to do the following:
>>>
>>> function vecadd!(vec, i, v)
>>> n = length(vec)
>>> if n < i
>>> resize!(vec, i)
>>> vec[n+1:i] = 0.0
>>> end
>>> vec[i] += v
>>> end
>>>
>>> This seems somewhat typical for a growing array that's not just
>>> incremental (i.e. not just a push!() operation), so I feel like I missed
>>> something. Better suggestions?
>>>
>>> Thanks!
>>>
>>> Cameron
>>>
>>
>

[julia-users] Re: Help my Row Major brain!

[Gabriel Gellner]

Sadly that wants to make a matrix of two long rows ;) like the hcat(...). 
So needs the transpose as well ... maybe this is the way?
Thanks for opening my eyes to mapreduce though!

On Tuesday, 27 October 2015 09:43:59 UTC-7, Glen O wrote:
>
> One relatively neat way to do this is
>
> mapreduce(exact,hcat,linspace(0,10,100))
>
> On Wednesday, 28 October 2015 02:38:56 UTC+10, Gabriel Gellner wrote:
>>
>> Okay sorry tab seems to send ...
>>
>> I am trying my to figure out the Julian way to create a table of values 
>> (matrix) from a function that returns multiple values. As this is really 
>> thinking about the problem as a function that generates the rows of the 
>> table it feels super awkward to do this in Julia currently. For example, 
>> lets say I have a function of the form:
>>
>> function exact(t)
>> yout = zeros(2)
>> yout[1] = 3.0*exp(t) - 2.0*exp(t)
>> yout[2] = exp(t) + 2.0*exp(t)
>> yout
>> end
>>
>> then what i want is a matrix of these solutions so my first thought is to 
>> do
>>
>> esol = [exact(t) for t in linspace(0, 10, 100)]
>> hcat(esol...)'
>>
>> is this the idiomatic solution?
>>
>> Is there a better way to do this? How do people generally deal with Array 
>> or Arrays. Feels weird to me currently.
>>
>> Gabriel
>>
>>
>> On Tuesday, 27 October 2015 09:31:22 UTC-7, Gabriel Gellner wrote:
>>>
>>> I am trying my to figure out the Julian way to create a table of values 
>>> (matrix) from a function that returns multiple values. As this is really 
>>> thinking about the problem as a function that generates the rows of the 
>>> table it feels super awkward to do this in Julia currently. For example, 
>>> lets say I have a function of the form:
>>>
>>> function exact_solution(t)
>>>
>>>

[julia-users] Re: pmap and DataStructures.OrderedDict

[Daniel O'Malley]

That worked for me. Many thanks!

Dan

On Tuesday, October 27, 2015 at 10:16:40 AM UTC-6, Daniel Arndt wrote:
>
> Hi Dan,
>
> It looks like you're running into the same issue I was, where the 
> underlying HashDict cannot be serialized correctly to send to the other 
> processes. 
>
> I put up a pull request (
> https://github.com/JuliaLang/DataStructures.jl/pull/138) yesterday to 
> hopefully fix this, feedback is appreciated. Apply these changes to your 
> DataStructures.jl and see if that works.
>
> Alternatively, as a temporory workaround, you can override the 
> Base.(de)serialize methods in your own code.
>
> Cheers,
> Another Dan
>
> On Tuesday, 27 October 2015 05:02:40 UTC-3, Daniel O'Malley wrote:
>>
>> I've recently encountered problems using pmap on a function that returns 
>> a DataStructures.OrderedDict.
>>
>> import DataStructures
>> @everywhere function f(x)
>> return DataStructures.OrderedDict(zip(["x"], [x]))
>> end
>> pmap(f, [1, 2])
>>
>> If the above code is run in a "julia -p 2" environment, it produce a 
>> cascade of errors that seem to begin with
>>
>> ERROR: MethodError: `write` has no method matching 
>> write(::SerializationState{TCPSocket}, ::Int32)
>>
>> In the original context that this example was trying to replicate, the 
>> error was
>>
>> ERROR: MethodError: `read` has no method matching 
>> read(::SerializationState{TCPSocket}, ::Type{Int32})
>>
>> Does anyone have advice on how to resolve this? Should these methods 
>> exist in base julia? Am I doing something wrong?
>>
>> Thanks for your help!
>>
>> Dan
>>
>

Re: [julia-users] Re: alternate LISP integration ...

[Waldir Pimenta]

On Tuesday, October 27, 2015 at 3:54:33 PM UTC, Steven G. Johnson wrote:

>
> There used to be a Scheme implementation called "SILK" for "Scheme in 50 
> kilobytes" (L = 50 in Roman numerals), and I remember that the author had a 
> comment to the effect: "If a future version of this bloats to over 50k, I 
> will have to rename it to SICK" (C = 100).
>
> I can't seem to find it anymore, though. 
>

It seems to have been renamed JScheme due to a trademark notification: 
http://norvig.com/jscheme-design.html 

More links:
- http://norvig.com/jscheme.html
- 
http://wayback.archive.org/web/20010619082655/http://www.cs.brandeis.edu/silk/silkweb/index.html
- http://www.cs.brandeis.edu/~tim/Papers/silk2000.pdf

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

[J Luis]

Please, leave the '=' alone. It's very well as is.

terça-feira, 27 de Outubro de 2015 às 18:20:19 UTC, FANG Colin escreveu:
>
> Julia tries to attract people from Python & R, which use `in`. As for 
> matlab, it is not a direct competitor.
>
> Anyway, I think we only need 1 of the 2. "There should be one-- and 
> preferably only one --obvious way to do it."
>
> Maybe enhance the documentation for the time being.
>
>
> On 27 October 2015 at 16:38, Glen O  
> wrote:
>
>> "When calculating a Fibonacci number, we have to apply 
>> F_n=F_(n-1)+F_(n-2) repeatedly. So to find F_6, we apply the equation for n 
>> equals 3 through 6". Writing it as "for n in 3 through 6" or "for n in the 
>> range 3 through 6" wouldn't make nearly as much sense.
>>
>> As I said, for general iterables, like vectors, the "in" keyword makes 
>> more sense. But when you're talking about a counter variable, equals makes 
>> a much more natural expression - you're not really constructing the range 
>> object, you're just telling the program you want the counter to start at 
>> the first value, and increment until it reaches the second value.
>>
>> On Wednesday, 28 October 2015 02:23:54 UTC+10, Tom Breloff wrote:
>>>
>>> It definitely makes sense for a range.
>>>
>>>
>>> Sorry... gotta disagree... mathematical set notation is more 
>>> appropriate, especially for scientific computing.  This is coming from a 
>>> former matlab user, btw, so it's not like I was confused by the syntax.   
>>> The "for i = 1:5" syntax is actually more reminiscent of C:  "for (int i=1; 
>>> i<=5; i++)", and I'm guessing that the syntax originated more from that 
>>> rather than scientific concepts.
>>>
>>> On Tue, Oct 27, 2015 at 11:58 AM, feza  wrote:
>>>
 +1 @Tom Breloff .  
 I was confused about this when starting out. Comparing   `for i in 
 1:3` vs  `for i = 1:3`, even though I regularly use matlab if you think 
 about it for `i = 1:10` doesn't really make a lot of sense. It would be 
 nice if it was just one way as opposed to the confusion about whether = or 
 in should be used.

 On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:
>
> It's harmless, sure, but I would prefer that everyone uses "in" 
> exclusively so that there's one less thing to waste brainpower on.  You 
> don't say "for each x equals the range 1 to n", you say "for each x in 
> the 
> range 1 to n".  I don't think "=" has a place here at all except to allow 
> copy/pasting of Matlab code (which creates other performance problems 
> anyways).
>
> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski <
> ste...@karpinski.org> wrote:
>
>> My general approach is to only use = when the RHS is an explicit 
>> range, as in `for i = 1:n`. For everything else I use `for i in v`. I 
>> would 
>> be ok with dropping the = syntax at some point, but it seems pretty 
>> harmless to have it.
>>
>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  
>> wrote:
>>
>>> Thank you. In that case I will happily stick with `in`.
>>>
>>>
>>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

 There is no difference, as far as I know.

 '=' seems to be used more for explicit ranges (i = 1:5) and 'in' 
 seems to be used more for variables (i in mylist). But using 'in' for 
 everything is ok too.

 The '=' is there for familiarity with matlab. Remember that julia's 
 syntax was in part designed to be familiar to matlab users.

 On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>
> Hi All
>
> I have got a stupid question:
>
> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>
> Does the julia community prefer one to the other? I see use of 
> both in the documentations and source code.
>
> Personally I haven't seen much use of "for i = 1:5" in other 
> languages.
>
> Thanks.
>

>>
>
>>>
>

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

[David Anthoff]

If something like this were to change, it would be good to do it sooner rather 
than later -> less code that depends on the syntax that would go would have 
been written. So maybe the right way forward for this is to open an issue 
suggesting to drop the = variant, discuss it, make a decision and then live 
with it, all for the 0.5 cycle.

 

I don’t feel strongly about this, but for what it’s worth, I’m also a fan of 
having only one way to do something like this.

 

Cheers,

David 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of FANG Colin
Sent: Tuesday, October 27, 2015 11:20 AM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Re: For loop = or in?

 

Julia tries to attract people from Python & R, which use `in`. As for matlab, 
it is not a direct competitor.

 

Anyway, I think we only need 1 of the 2. "There should be one-- and preferably 
only one --obvious way to do it."

 

Maybe enhance the documentation for the time being.

 

 

On 27 October 2015 at 16:38, Glen O  > wrote:

"When calculating a Fibonacci number, we have to apply F_n=F_(n-1)+F_(n-2) 
repeatedly. So to find F_6, we apply the equation for n equals 3 through 6". 
Writing it as "for n in 3 through 6" or "for n in the range 3 through 6" 
wouldn't make nearly as much sense.

 

As I said, for general iterables, like vectors, the "in" keyword makes more 
sense. But when you're talking about a counter variable, equals makes a much 
more natural expression - you're not really constructing the range object, 
you're just telling the program you want the counter to start at the first 
value, and increment until it reaches the second value.

On Wednesday, 28 October 2015 02:23:54 UTC+10, Tom Breloff wrote:

It definitely makes sense for a range.

 

Sorry... gotta disagree... mathematical set notation is more appropriate, 
especially for scientific computing.  This is coming from a former matlab user, 
btw, so it's not like I was confused by the syntax.   The "for i = 1:5" syntax 
is actually more reminiscent of C:  "for (int i=1; i<=5; i++)", and I'm 
guessing that the syntax originated more from that rather than scientific 
concepts.

 

On Tue, Oct 27, 2015 at 11:58 AM, feza  > wrote:

+1 @Tom Breloff .  
I was confused about this when starting out. Comparing   `for i in 1:3` vs  
`for i = 1:3`, even though I regularly use matlab if you think about it for `i 
= 1:10` doesn't really make a lot of sense. It would be nice if it was just one 
way as opposed to the confusion about whether = or in should be used.

On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:

It's harmless, sure, but I would prefer that everyone uses "in" exclusively so 
that there's one less thing to waste brainpower on.  You don't say "for each x 
equals the range 1 to n", you say "for each x in the range 1 to n".  I don't 
think "=" has a place here at all except to allow copy/pasting of Matlab code 
(which creates other performance problems anyways).

 

On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski  > wrote:

My general approach is to only use = when the RHS is an explicit range, as in 
`for i = 1:n`. For everything else I use `for i in v`. I would be ok with 
dropping the = syntax at some point, but it seems pretty harmless to have it.

 

On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  > wrote:

Thank you. In that case I will happily stick with `in`.



On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

There is no difference, as far as I know.

 

'=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems to be 
used more for variables (i in mylist). But using 'in' for everything is ok too.

 

The '=' is there for familiarity with matlab. Remember that julia's syntax was 
in part designed to be familiar to matlab users.


On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:

Hi All

 

I have got a stupid question:

 

Are there any difference in "for i in 1:5" and "for i = 1:5"?

 

Does the julia community prefer one to the other? I see use of both in the 
documentations and source code.

 

Personally I haven't seen much use of "for i = 1:5" in other languages.

 

Thanks.

 

 

 

 

[julia-users] Code to calculate a vast matrix product together?

[Arch Robison]

The "greedy" blog  
said "We want to write A*B and launch a thousand computations on a thousand 
machines, calculating a vast matrix product together."  Has someone written 
the code for this yet?  What's the *shortest *way to write it (will it fit 
on a slide :-))?

[julia-users] Re: JuliaBox limitations on parallel computing

[André Lage]

Hi Iliyan,

I just read your message now. 

Evoqus is a great idea! We are also working on a transparent support for 
Julia computing in the cloud, based on DistributedArrays. We intend to 
include pricing features as you did.

Do you intend to share your code (even partially)?

Congratulations for the work!


André.

On Tuesday, October 27, 2015 at 2:23:33 AM UTC-3, Iliyan Zarov wrote:
>
> For anyone wishing to run large parallel programs I may be able to help - 
> I'm working on a cloud computing platform for Julia that takes care of 
> provisioning and managing all resources. More info at https://evoqus.com
>  . 
>
> It's currently in beta, get in touch if interested.
>
>
> Best,
>
> Iliyan
>
> On Monday, October 26, 2015 at 6:41:57 PM UTC, cdm wrote:
>>
>>
>> perhaps time for an asterisk on the JuliaBox banner:
>>
>> "The Julia community is doing amazing things. We want you in on it!*"
>>
>> * ... but not massively in parallel, consuming the resources of the 
>> community.
>>
>>
>>
>> there are positives and negatives to this sort of problem ...
>>
>> the fact that the problem can even arise says great things
>> about the capabilities of the language and the service.
>>
>> well done ...
>>
>>
>>
>> On Sunday, October 25, 2015 at 2:11:25 AM UTC-7, Tanmay K. Mohapatra 
>> wrote:
>>>
>>> Hi,
>>>
>>> from the past few days we have had some users run large parallel 
>>> programs on JuliaBox sessions. While in some cases they succeed, we see a 
>>> lot of failures due to resource constraints. Though we have plans to enable 
>>> large programs in future, we do not allocate enough resources for that now.
>>>
>>> Also, since JuliaBox sessions run on shared infrastructure, this affects 
>>> other sessions that are co-located on the same machine.  We will be putting 
>>> in place more checks and restrictions soon to prevent co-located sessions 
>>> from being impacted.
>>>
>>> We would request users to refrain from running large parallel programs 
>>> for now. If this is being done as part of some university class, please 
>>> write to us. Probably a separately provisioned cluster will be more 
>>> appropriate for that.
>>>
>>> - JuliaBox Team
>>>
>>

[julia-users] Re: JuliaBox limitations on parallel computing

[Iliyan Zarov]

Thanks André!

I'll be very interested to hear more about what you are building on top of 
DistributedArrays.

The API is open and the CLI will be open source in a few weeks. The server 
will likely be partially open sourced in the future.
And any generally applicable changes to the Julia codebase will be 
definitely submitted upstream.

Best,
Iliyan

On Tuesday, October 27, 2015 at 6:07:03 PM UTC, André Lage wrote:
>
> Hi Iliyan,
>
> I just read your message now. 
>
> Evoqus is a great idea! We are also working on a transparent support for 
> Julia computing in the cloud, based on DistributedArrays. We intend to 
> include pricing features as you did.
>
> Do you intend to share your code (even partially)?
>
> Congratulations for the work!
>
>
> André.
>
> On Tuesday, October 27, 2015 at 2:23:33 AM UTC-3, Iliyan Zarov wrote:
>>
>> For anyone wishing to run large parallel programs I may be able to help - 
>> I'm working on a cloud computing platform for Julia that takes care of 
>> provisioning and managing all resources. More info at https://evoqus.com
>>  . 
>>
>> It's currently in beta, get in touch if interested.
>>
>>
>> Best,
>>
>> Iliyan
>>
>> On Monday, October 26, 2015 at 6:41:57 PM UTC, cdm wrote:
>>>
>>>
>>> perhaps time for an asterisk on the JuliaBox banner:
>>>
>>> "The Julia community is doing amazing things. We want you in on it!*"
>>>
>>> * ... but not massively in parallel, consuming the resources of the 
>>> community.
>>>
>>>
>>>
>>> there are positives and negatives to this sort of problem ...
>>>
>>> the fact that the problem can even arise says great things
>>> about the capabilities of the language and the service.
>>>
>>> well done ...
>>>
>>>
>>>
>>> On Sunday, October 25, 2015 at 2:11:25 AM UTC-7, Tanmay K. Mohapatra 
>>> wrote:

 Hi,

 from the past few days we have had some users run large parallel 
 programs on JuliaBox sessions. While in some cases they succeed, we see a 
 lot of failures due to resource constraints. Though we have plans to 
 enable 
 large programs in future, we do not allocate enough resources for that now.

 Also, since JuliaBox sessions run on shared infrastructure, this 
 affects other sessions that are co-located on the same machine.  We will 
 be 
 putting in place more checks and restrictions soon to prevent co-located 
 sessions from being impacted.

 We would request users to refrain from running large parallel programs 
 for now. If this is being done as part of some university class, please 
 write to us. Probably a separately provisioned cluster will be more 
 appropriate for that.

 - JuliaBox Team

>>>

[julia-users] Re: A grateful scientist

[Andre Bieler]

I +1 on the thanks from scientist. 

I changed 90% of my data analysis scripts from Python to Julia and never 
looked back.
For what its worth: I have an upcoming paper in Nature on Thursday that of 
course credits the Julia language! :) (Its the least I could do)

It really made my research easier by being able to go through a lot of data 
in much shorter time than all of my Python scripts
could handle before!

[julia-users] ANN: new version of LightGraphs; discontinuation of Julia 0.3 support

[Seth]

Hi all,

Just a quick note to let you know that we've tagged a new minor version of 
LightGraphs - v0.4.0, available via 
https://github.com/JuliaGraphs/LightGraphs.jl. The reason this is 
significant is that it is the first version that (explicitly and 
intentionally) breaks compatibility with Julia 0.3. Going forward we will 
be ensuring compatibility with release and development branches of Julia.

The last version of LightGraphs that is guaranteed to work on Julia 0.3 is, 
coincidentally, LightGraphs v0.3.5. We will not be adding new functionality 
to LightGraphs v0.3.x, but if there's a critical bug identified we'll do 
our best to fix it.

Thanks,

Seth.

[julia-users] Re: Collection of YAsnippets for Julia

[Jānis Erdmanis]

It looks useful, but I have no experience of configuring Yasnipet. Could 
you post relevant part of .emacs and also give some instructions where 
should I put these files? Also how to call these snippets are unknown to me 
;) 

On Thursday, September 3, 2015 at 4:54:55 PM UTC+3, andreas wrote:
>
>
> I've started a collection of YAsnippets for Julia that may be useful for 
> Emacs user:
>
> https://github.com/scheidan/julia-jasnippets
>
> Docstring support for function is ok (based on the snippets for python), 
> but for type and immutable elisp hacking is needed.
>
> Best,
> Andreas
>

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

[DNF]

On Tuesday, October 27, 2015 at 4:56:12 PM UTC+1, Glen O wrote:
>
> Incidentally, it would be nice if ∈ could be used as another option - it's 
> just another way of saying "in", but it would look nicer in certain 
> mathematical contexts, and it's not like the symbol would be used in 
> another way in that position.
>

I very much like the idea of using for ∈ 1:n. In fact, as ∈ is a direct 
synonym for the function in, would it not make sense to let it be a synonym 
also in this context? Would it be problematic in some way? What is the 
difference in the meanings of in that prevents this from already being the 
case?

[julia-users] Re: WinRPM Download failure

[Achu]

Tried Pkg.update(), exited, and Pkg.build("WinRPM") in a new instance. I 
got this

INFO: Building WinRPM
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() 
to download
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() 
to download
INFO: Downloading 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 1/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 2/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 3/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 4/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 5/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: received error 0 while downloading 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
INFO: Downloading 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 1/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 2/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 3/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 4/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270105
WARNING: Retry 5/5 downloading: 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
WARNING: received error 0 while downloading 
https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml

Tried Pkg.checkout("WinRPM"), exited, Pkg.build("WinRPM"). Same thing.

https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
gives me an untrusted connection warning and then a 400 error when go there 
anyway.

http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
works just fine.




On Monday, 26 October 2015 14:26:07 UTC-5, Achu wrote:
>
> I got this when I ran Pkg.update() and also on WinRPM.update()
>
> INFO: Building WinRPM
> INFO: Downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 1/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 2/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 3/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 4/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 5/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: received error 0 while downloading 
> 

Re: [julia-users] Re: A grateful scientist

[Stefan Karpinski]

Mentioning Julia and any Julia packages used for published work is greatly
appreciated!

On Tue, Oct 27, 2015 at 4:49 PM, Andre Bieler 
wrote:

> I +1 on the thanks from scientist.
>
> I changed 90% of my data analysis scripts from Python to Julia and never
> looked back.
> For what its worth: I have an upcoming paper in Nature on Thursday that of
> course credits the Julia language! :) (Its the least I could do)
>
> It really made my research easier by being able to go through a lot of
> data in much shorter time than all of my Python scripts
> could handle before!
>

[julia-users] Re: Help my Row Major brain!

[Dan]

putting the transpose inside, might look nicer to some:
esol = vcat([exact(t)' for t in linspace(0, 10, 100)]...)


On Tuesday, October 27, 2015 at 6:52:21 PM UTC+2, Gabriel Gellner wrote:
>
> Sadly that wants to make a matrix of two long rows ;) like the hcat(...). 
> So needs the transpose as well ... maybe this is the way?
> Thanks for opening my eyes to mapreduce though!
>
> On Tuesday, 27 October 2015 09:43:59 UTC-7, Glen O wrote:
>>
>> One relatively neat way to do this is
>>
>> mapreduce(exact,hcat,linspace(0,10,100))
>>
>> On Wednesday, 28 October 2015 02:38:56 UTC+10, Gabriel Gellner wrote:
>>>
>>> Okay sorry tab seems to send ...
>>>
>>> I am trying my to figure out the Julian way to create a table of values 
>>> (matrix) from a function that returns multiple values. As this is really 
>>> thinking about the problem as a function that generates the rows of the 
>>> table it feels super awkward to do this in Julia currently. For example, 
>>> lets say I have a function of the form:
>>>
>>> function exact(t)
>>> yout = zeros(2)
>>> yout[1] = 3.0*exp(t) - 2.0*exp(t)
>>> yout[2] = exp(t) + 2.0*exp(t)
>>> yout
>>> end
>>>
>>> then what i want is a matrix of these solutions so my first thought is 
>>> to do
>>>
>>> esol = [exact(t) for t in linspace(0, 10, 100)]
>>> hcat(esol...)'
>>>
>>> is this the idiomatic solution?
>>>
>>> Is there a better way to do this? How do people generally deal with 
>>> Array or Arrays. Feels weird to me currently.
>>>
>>> Gabriel
>>>
>>>
>>> On Tuesday, 27 October 2015 09:31:22 UTC-7, Gabriel Gellner wrote:

 I am trying my to figure out the Julian way to create a table of values 
 (matrix) from a function that returns multiple values. As this is really 
 thinking about the problem as a function that generates the rows of the 
 table it feels super awkward to do this in Julia currently. For example, 
 lets say I have a function of the form:

 function exact_solution(t)

Re: [julia-users] Re: alternate LISP integration ...

[Jeff Bezanson]

I don't think this is intended to be able to replace LLVM. Julia could
be implemented on top of PyPy/RPython, but PyPy itself has an LLVM
backend (one of multiple backends I believe). LLVM is a full toolchain
for handling code --- generation, optimization, linking, analysis, and
debugging. We need all of those capabilities, which go a good deal
beyond just running julia code fast.

On Tue, Oct 27, 2015 at 5:30 PM, cdm  wrote:
>
> but it has its own virtual machine ...
> which could conceivably replace
> the LLVM ties ... ?
>
> ... unless that is inconceivable.
>
>
>
> i am glad that no one has rejected
> the idea out of hand; further proof
> that the Julia community is truly
> remarkable.
>
>
>
> On Tuesday, October 27, 2015 at 7:31:52 AM UTC-7, Jeff Bezanson wrote:
>>
>> Looks very cool! Of course I'd be interested in compiling julia's
>> frontend with something like this. We could badly use the extra speed.
>> I assume it supports macros, in which case I hope somebody makes a
>> library to undo the silly identifier renaming (e.g. defn -> define) so
>> it can run more scheme-like code.
>>
>> This looks like a much more serious project than femtolisp, but I
>> would like to dispute the claim that it is "lightweight". From the
>> readme, it depends on python/pypy, libffi, libedit, libuv, and
>> libboost, and is 10MB which makes it literally 100 times larger than
>> femtolisp.

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

[Hai Nguyen]

On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski 
wrote:

> My general approach is to only use = when the RHS is an explicit range, as
> in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
> with dropping the = syntax at some point, but it seems pretty harmless to
> have it.
>
>
I have 1 vote for removing '='. It is harmless but it introduces confusion.

Hai


> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  wrote:
>
>> Thank you. In that case I will happily stick with `in`.
>>
>>
>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>>>
>>> There is no difference, as far as I know.
>>>
>>> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems
>>> to be used more for variables (i in mylist). But using 'in' for everything
>>> is ok too.
>>>
>>> The '=' is there for familiarity with matlab. Remember that julia's
>>> syntax was in part designed to be familiar to matlab users.
>>>
>>> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:

 Hi All

 I have got a stupid question:

 Are there any difference in "for i in 1:5" and "for i = 1:5"?

 Does the julia community prefer one to the other? I see use of both in
 the documentations and source code.

 Personally I haven't seen much use of "for i = 1:5" in other languages.

 Thanks.

>>>
>

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

[Stefan Karpinski]

If someone wants to make a PR deprecating the syntax, it would certainly be
considered.

On Tuesday, October 27, 2015, Hai Nguyen  wrote:

>
>
> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski  > wrote:
>
>> My general approach is to only use = when the RHS is an explicit range,
>> as in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
>> with dropping the = syntax at some point, but it seems pretty harmless to
>> have it.
>>
>>
> I have 1 vote for removing '='. It is harmless but it introduces confusion.
>
> Hai
>
>
>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin > > wrote:
>>
>>> Thank you. In that case I will happily stick with `in`.
>>>
>>>
>>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

 There is no difference, as far as I know.

 '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems
 to be used more for variables (i in mylist). But using 'in' for everything
 is ok too.

 The '=' is there for familiarity with matlab. Remember that julia's
 syntax was in part designed to be familiar to matlab users.

 On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>
> Hi All
>
> I have got a stupid question:
>
> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>
> Does the julia community prefer one to the other? I see use of both in
> the documentations and source code.
>
> Personally I haven't seen much use of "for i = 1:5" in other
> languages.
>
> Thanks.
>

>>
>

[julia-users] Re: alternate LISP integration ...

[cdm]

right ... that is still working ...

i was thinking that i could get
there from the Julia prompt
without shelling out ...

thanks for the reminder.

best,

cdm




On Tuesday, October 27, 2015 at 12:31:40 AM UTC-7, Tomas Lycken wrote:
>
> Have you tried julia --lisp from the command line? Works on my machine…
>
> // T
>
> On Monday, October 26, 2015 at 10:36:05 PM UTC+1, cdm wrote:
>
>
>> somewhat related ...
>>
>> is it still possible to get
>> the femtolisp REPL in the
>> post v0.4.0 world ... ?
>>
>> thanks,
>>
>> cdm
>>
> ​
>

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

[Ivan Bocharov]

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. 
>

[julia-users] Re: WinRPM Download failure

[Tony Kelman]

Okay, sounds like you might be 
hitting https://github.com/JuliaLang/WinRPM.jl/issues/47 then. If you try 
deleting the https://cache.e.ip.saba.us/ prefix from the entries in 
sources.list (then restart), does that help?


On Tuesday, October 27, 2015 at 1:41:55 PM UTC-7, Achu wrote:
>
> Tried Pkg.update(), exited, and Pkg.build("WinRPM") in a new instance. I 
> got this
>
> INFO: Building WinRPM
> WARNING: skipping repodata/repomd.xml, not in cache -- call 
> WinRPM.update() to download
> WARNING: skipping repodata/repomd.xml, not in cache -- call 
> WinRPM.update() to download
> INFO: Downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 1/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 2/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 3/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 4/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 5/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> WARNING: received error 0 while downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
> INFO: Downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 1/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 2/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 3/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 4/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270105
> WARNING: Retry 5/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> WARNING: received error 0 while downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
>
> Tried Pkg.checkout("WinRPM"), exited, Pkg.build("WinRPM"). Same thing.
>
>
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> gives me an untrusted connection warning and then a 400 error when go 
> there anyway.
>
>
> http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.2/repodata/repomd.xml
> works just fine.
>
>
>
>
> On Monday, 26 October 2015 14:26:07 UTC-5, Achu wrote:
>>
>> I got this when I ran Pkg.update() and also on WinRPM.update()
>>
>> INFO: Building WinRPM
>> INFO: Downloading 
>> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
>> WARNING: Unknown download failure, error code: 2148270086
>> WARNING: Retry 1/5 downloading: 
>> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
>> WARNING: Unknown download failure, error code: 2148270086
>> WARNING: Retry 2/5 downloading: 
>> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
>> WARNING: Unknown download failure, error code: 2148270086
>> WARNING: Retry 3/5 downloading: 
>> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
>> WARNING: Unknown download failure, error code: 2148270086
>> WARNING: Retry 4/5 downloading: 
>> 

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

[Tk]

As far as I can understand, Julia also seems trying to attract people from 
Matlab,
because there are so many similarities in the syntax (.* and ./ etc) and 
the names of functions.

Also I often see questions from Matlab users posted in StackOverflow. Their 
codes are
rather Matlab-like, but it works anyway. I guess this helps people to try a 
new language
with lower barrier. (Though, personally, I don't like ".*" notation very 
much. But I can live with it.)

As for =, I also prefer using = for counters (for i = 1:n) and "in" for 
other containers.
I use Fortran and Python most often for research work, but I feel "=" is 
quite natural for indicating
that the index goes from 1 to n. On the other hand, with "in", I feel like 
the entity is just
somewhere inside the container, with no particular order enforced (even if 
it has a definite order).
My familiarity with "=" is probably coming from old languages (including 
C-like ones),
but that aside, I hope "=" remains a valid symbol for this.

So anyway, +1 for the comments from Glen O.

On Wednesday, October 28, 2015 at 3:20:19 AM UTC+9, FANG Colin wrote:
>
> Julia tries to attract people from Python & R, which use `in`. As for 
> matlab, it is not a direct competitor.
>
> Anyway, I think we only need 1 of the 2. "There should be one-- and 
> preferably only one --obvious way to do it."
>
> Maybe enhance the documentation for the time being.
>
>
> On 27 October 2015 at 16:38, Glen O  
> wrote:
>
>> "When calculating a Fibonacci number, we have to apply 
>> F_n=F_(n-1)+F_(n-2) repeatedly. So to find F_6, we apply the equation for n 
>> equals 3 through 6". Writing it as "for n in 3 through 6" or "for n in the 
>> range 3 through 6" wouldn't make nearly as much sense.
>>
>> As I said, for general iterables, like vectors, the "in" keyword makes 
>> more sense. But when you're talking about a counter variable, equals makes 
>> a much more natural expression - you're not really constructing the range 
>> object, you're just telling the program you want the counter to start at 
>> the first value, and increment until it reaches the second value.
>>
>> On Wednesday, 28 October 2015 02:23:54 UTC+10, Tom Breloff wrote:
>>>
>>> It definitely makes sense for a range.
>>>
>>>
>>> Sorry... gotta disagree... mathematical set notation is more 
>>> appropriate, especially for scientific computing.  This is coming from a 
>>> former matlab user, btw, so it's not like I was confused by the syntax.   
>>> The "for i = 1:5" syntax is actually more reminiscent of C:  "for (int i=1; 
>>> i<=5; i++)", and I'm guessing that the syntax originated more from that 
>>> rather than scientific concepts.
>>>
>>> On Tue, Oct 27, 2015 at 11:58 AM, feza  wrote:
>>>
 +1 @Tom Breloff .  
 I was confused about this when starting out. Comparing   `for i in 
 1:3` vs  `for i = 1:3`, even though I regularly use matlab if you think 
 about it for `i = 1:10` doesn't really make a lot of sense. It would be 
 nice if it was just one way as opposed to the confusion about whether = or 
 in should be used.

 On Tuesday, October 27, 2015 at 10:26:44 AM UTC-4, Tom Breloff wrote:
>
> It's harmless, sure, but I would prefer that everyone uses "in" 
> exclusively so that there's one less thing to waste brainpower on.  You 
> don't say "for each x equals the range 1 to n", you say "for each x in 
> the 
> range 1 to n".  I don't think "=" has a place here at all except to allow 
> copy/pasting of Matlab code (which creates other performance problems 
> anyways).
>
> On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski <
> ste...@karpinski.org> wrote:
>
>> My general approach is to only use = when the RHS is an explicit 
>> range, as in `for i = 1:n`. For everything else I use `for i in v`. I 
>> would 
>> be ok with dropping the = syntax at some point, but it seems pretty 
>> harmless to have it.
>>
>> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  
>> wrote:
>>
>>> Thank you. In that case I will happily stick with `in`.
>>>
>>>
>>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:

 There is no difference, as far as I know.

 '=' seems to be used more for explicit ranges (i = 1:5) and 'in' 
 seems to be used more for variables (i in mylist). But using 'in' for 
 everything is ok too.

 The '=' is there for familiarity with matlab. Remember that julia's 
 syntax was in part designed to be familiar to matlab users.

 On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>
> Hi All
>
> I have got a stupid question:
>
> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>
> Does the julia community prefer one to the other? I see use of 

Re: [julia-users] Re: alternate LISP integration ...

[cdm]

but it has its own virtual machine ...
which could conceivably replace
the LLVM ties ... ?

... unless that is inconceivable.



i am glad that no one has rejected
the idea out of hand; further proof
that the Julia community is truly
remarkable.



On Tuesday, October 27, 2015 at 7:31:52 AM UTC-7, Jeff Bezanson wrote:
>
> Looks very cool! Of course I'd be interested in compiling julia's 
> frontend with something like this. We could badly use the extra speed. 
> I assume it supports macros, in which case I hope somebody makes a 
> library to undo the silly identifier renaming (e.g. defn -> define) so 
> it can run more scheme-like code. 
>
> This looks like a much more serious project than femtolisp, but I 
> would like to dispute the claim that it is "lightweight". From the 
> readme, it depends on python/pypy, libffi, libedit, libuv, and 
> libboost, and is 10MB which makes it literally 100 times larger than 
> femtolisp. 
>

[julia-users] Re: missing const qualifier

[vavasis]

There are two possible ways to implement return values from functions that 
are 'const': either the compiler checks that const-ness is maintained (as 
in C++), or the value has a read-only flag in it that is checked at 
run-time by the setindex! routine.  The latter solution would entail a 
slowdown for setindex! across the board for all users.  Since there already 
thousands of Julia users who would not like to see their existing codes 
slowed in order to support a new feature, I would say that the run-time 
flag approach can be ruled out.

This leaves the compile-time approach to verifying const-ness.  But for 
this to work at compile time, the compiler needs to be able to trace 
const-ness throughout the program.  In other words, if function f returns a 
'const' array A, and then the user invokes function g with A as an 
argument, then the compiler needs to see that g declares A as a const 
argument.

My point is that in order to preserve the const-ness of a returned value, 
it would be necessary to also extend the language with const arguments for 
functions.  I don't see how to have one without the other.

-- Steve Vavasis


On Tuesday, October 27, 2015 at 4:52:21 AM UTC-4, Carlo Lucibello wrote:
>
> I found your proposal
>
>
> https://groups.google.com/forum/#!searchin/julia-users/vavasis/julia-users/Hq00EyeazJM/HgYgDcnbhs4J
>
> https://groups.google.com/forum/#!searchin/julia-users/vavasis$20const/julia-users/FK_29Dj4eDo/nX5QnhfKc40J
>
> but that is a different feature, having cont `in` argument, while I want 
> const return types. 
>
> Having const in would be nice, but i understand that its implementation 
> would be more difficult.
>
> On the other hand having a const return valure seems easier to my 
> (non-expert) eyes
>
>
>
>
> Il giorno martedì 27 ottobre 2015 04:27:44 UTC+1, vav...@uwaterloo.ca ha 
> scritto:
>>
>> In 2014 when I first learned about Julia, I also suggested on this 
>> newsgroup that there should be a 'const' keyword as in C++ to annotate 
>> function arguments and return variables that are supposed to be read-only. 
>>  Possibly you can find the old thread with google.  I received a lot of 
>> feedback from experienced Julia users and core developers that convinced me 
>> that this is probably not a good idea.  Here are some reasons that I can 
>> recall from the earlier discussion that adding 'const' to Julia may not be 
>> a good idea.
>>
>> (1) The 'const' keyword would make the multiple-dispatch system much more 
>> confusing because it would entail new rules about how the 'const' keyword 
>> affects closeness in the type hierarchy.
>>
>> not a problem for const return value
>  
>
>> (2) You can already get the desired effect in Julia by defining your own 
>> subtype of DenseArray in which getindex works as usual but setindex! throws 
>> an error.
>>
>> this solution is not general, it works only on arrays 
>
>> (3) The promise that a routine won't change a 'const' argument could 
>> easily be defeated by aliasing (i.e., a function is invoked with a const 
>> argument, but another non-const argument refers to the same piece of data), 
>> so it may give the user a false sense of security.
>>
>  not a problem for const return value
>
> -- Steve Vavasis
>>
>>
>>
>>
>>
>>
>>
>> On Monday, October 26, 2015 at 10:29:34 PM UTC-4, Carlo Lucibello wrote:
>>>
>>> It would be nice to annotate the return type of methods with a constant 
>>> qualifier, in order to have 
>>> an efficient and safe behaviour at the same time. 
>>>
>>> I mean something like this:
>>>
>>> type A
>>>   data::Vector{Int}
>>> end
>>>
>>> # invalid but desiderable julia code
>>> const function getdata(a::A)
>>>   return a.data
>>> end 
>>>
>>> a = A(ones(10))
>>> data = getdata(a)
>>>
>>> data[1] = 2  # ERROR
>>> a.data[1] = 2 # OK
>>>   
>>>
>>

Re: [julia-users] Re: alternate LISP integration ...

[cdm]

22k ... is there a lighter lisp !?!?


On Tuesday, October 27, 2015 at 9:10:05 AM UTC-7, Jeff Bezanson wrote:
>
> Then of course there's always 
> https://github.com/JeffBezanson/femtolisp/blob/master/tiny/lisp.c, 
> which compiles to a 22k executable (after stripping) on my machine.
>

[julia-users] Re: alternate LISP integration ...

[cdm]

and  ;julia --lisp  is the shell out ...

which also still works.

thanks again ...


On Tuesday, October 27, 2015 at 2:22:43 PM UTC-7, cdm wrote:
>
> right ... that is still working ...
>
> i was thinking that i could get
> there from the Julia prompt
> without shelling out ...
>
>
> On Tuesday, October 27, 2015 at 12:31:40 AM UTC-7, Tomas Lycken wrote:
>>
>> Have you tried julia --lisp from the command line? Works on my machine…
>>
>> // T
>>
>

[julia-users] Re: How to get first number from Int64

[Dan]

If you do a:

 precomp = map(log10,2:10)

Then a oneliner for the first digit is:

 searchsortedfirst(precomp, log10(lista[3])%1.0)

There are many paths in the garden. But this one is not as long (slow) as 
it looks.

On Tuesday, October 27, 2015 at 10:35:18 AM UTC+2, Alireza Nejati wrote:
>
> Michele's solution is preferred here, but you can also do it like this:
>
> string(lista[3])[1]
>

[julia-users] A grateful scientist

[Jonathan Malmaud]

As someone who volunteers my free time to developing Julia, it means a lot to 
hear that. 

[julia-users] Re: A grateful scientist

[Yakir Gagnon]

Wow, I'm glad there's been such a positive response! I meant every word and 
more. I too have a publication coming up soon (albeit not in Nature -- 
which is beyond awesome) and Julia is referenced there. As it 
will probably be in every publication I have from now on.

Thanks again!

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

[julia-users] Re: Inconsistent behaviour of round()

[elextr]

"round to nearest, ties to even" is the default IEEE floating point 
rounding 
mode https://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules

Cheers
Lex

On Wednesday, October 28, 2015 at 11:02:58 AM UTC+10, jock@gmail.com 
wrote:
>
> Hi there,
>
> I'm using Julia 0.4.0.
>
> round(4.5) gives 4.0, i.e. it rounds down.
> round(5.5) gives 6.0, i.e. it rounds up.
>
> Any ideas why this is the case?
>
> Cheers,
> Jock
>
>

[julia-users] Re: Inconsistent behaviour of round()

[jock . lawrie]

Great, thanks Lex.
The documentation for round 
 
is "round x to the nearest integer", which seems to be a mathematical 
definition that isn't quite equivalent to the IEEE spec.
The docs ought to mention rounding to the nearest.


On Wednesday, October 28, 2015 at 12:35:12 PM UTC+11, ele...@gmail.com 
wrote:
>
> "round to nearest, ties to even" is the default IEEE floating point 
> rounding mode 
> https://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules
>
> Cheers
> Lex
>
> On Wednesday, October 28, 2015 at 11:02:58 AM UTC+10, jock@gmail.com 
> wrote:
>>
>> Hi there,
>>
>> I'm using Julia 0.4.0.
>>
>> round(4.5) gives 4.0, i.e. it rounds down.
>> round(5.5) gives 6.0, i.e. it rounds up.
>>
>> Any ideas why this is the case?
>>
>> Cheers,
>> Jock
>>
>>

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

[colintbowers]

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] Re: Deprecation warnings using julia on Atom

[colintbowers]

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] Re: [Gadfly] : Help regarding plotting

[Alireza Nejati]

Also look at: https://github.com/dcjones/Gadfly.jl/blob/master/src/theme.jl 
 (line_style)

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

[Tom Breloff]

"crazy gyrations"?  Can you expand on that and provide code?

On Tue, Oct 27, 2015 at 8:58 PM,  wrote:

> Using pyplot with multiple figures, choose one to display as the topmost
> window. There are crazy gyrations in matplotlib that only work with certain
> backends.
>
> Generally, Julia makes the matplotlib API much nicer.  Once the whole
> thing loads it is quick enough.
>
> But, this very basic thing seems almost impossible.
>
> Things that don't work:
> figure(1)
>
> figure(1)
> plt[:show]()
>
> plt[:show](1)
>
> I am out of things to try.
>

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

[Spencer Russell]

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, colintbow...@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] no one knows this.....

[lewis]

Using pyplot with multiple figures, choose one to display as the topmost 
window. There are crazy gyrations in matplotlib that only work with certain 
backends.

Generally, Julia makes the matplotlib API much nicer.  Once the whole thing 
loads it is quick enough.

But, this very basic thing seems almost impossible.

Things that don't work:
figure(1)

figure(1)
plt[:show]()

plt[:show](1)

I am out of things to try.

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

[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.

[julia-users] Deprecation warnings using julia on Atom

[colintbowers]

Hi all,

I'm using Julia v0.4 with the Atom package, on Atom 1.0 with the packages 
ink, julia-client, and language-julia (and I'm really enjoying this as an 
IDE solution).

I can toggle the Julia console in Atom, and enter code directly into it 
without any errors or warnings. However, as soon as I try to evaluate a 
line of code from the Atom editor, I get a large number of deprecation 
warnings, either of the form:

WARNING: Base.Uint8 is deprecated, use UInt8 instead.
  likely near no file:422

or

WARNING: Base.Uint8 is deprecated, use UInt8 instead.
  likely near no file:422
in skip at /home/colin/.julia/v0.4/LNR/src/LNR.jl:171

Has anyone else encountered this and is there a fix? I had a look through 
the LNR source, and there is nothing in it that should be triggering a 
deprecation warning, nor is there even a line 171 (it only goes up to about 
line 130).

Note, I can just ignore the deprecation warnings, and continue on working 
without a problem, so this isn't an urgent issue. Just wondering if I've 
stuffed up the install process somehow.

Cheers,

Colin

[julia-users] Deprecation warnings using julia on Atom

[Jonathan Malmaud]

You want to be on the master versions:

Pkg.checkout("Atom")
Pkg.checkout("CodeTools")

[julia-users] Re: [Gadfly] : Help regarding plotting

[Alireza Nejati]

The design philosophy of Gadfly seems to be that you should think about the 
data and let the software worry about how to present it.

That said, it is possible to change things like fonts, line thicknesses and 
dash styles, and legend placement through 
themes: http://gadflyjl.org/themes.html

More advanced functionality is possible via the Compose.jl backend.

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

[Spencer Russell]

`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, colintbow...@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] Inconsistent behaviour of round()

[jock . lawrie]

Hi there,

I'm using Julia 0.4.0.

round(4.5) gives 4.0, i.e. it rounds down.
round(5.5) gives 6.0, i.e. it rounds up.

Any ideas why this is the case?

Cheers,
Jock

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

[lewis]

Here are some of the solutions proposed for matplotlib:

with qt4agg backend:

fig = gcf()
fig.canvas.manager.window.raise_()


Here is one that works with tk backend:

import matplotlib.pyplot as plt
wm = plt.get_current_fig_manager() 
wm.window.attributes('-topmost', 1)
wm.window.attributes('-topmost', 0)


So, that is what I meant by gyrations.  I'll put the second on in a code 
fragment and post in a second.

[julia-users] Re: Windows woes

[Tony Kelman]

Watch task manager while this is happening, see which other processes are 
taking cpu. An antivirus or something similar may be interfering. Do you 
have an SSD and he doesn't?


On Tuesday, October 27, 2015 at 8:21:42 PM UTC-7, Eric Forgy wrote:
>
> Hi,
>
> I am at a loss how to proceed, so please forgive a rambling unfocused plea 
> for help and I appreciate any questions to help me focus my search for a 
> solution.
>
> I have Julia 0.4.0 installed on my MacBook running Windows 10 (I know I 
> know :)). My installation is nice and snappy with no issues. I've got Juno 
> set up and am quite happy.
>
> My colleague, on the other hand, is having a miserable time running Julia. 
> I am not sure how to even ask a question because, as far as I can tell, we 
> have identical installations, i.e. the same Julia 0.4.0 from the same 
> branch running on Windows 10, but his laptop is a Lenovo. It's no MacBook, 
> but it is a new machine with 8GB RAM so should be ok.
>
> Symptoms:
>
> *Painfully slow startup if it even manages to startup at all*
>
> When we launch Julia, the window pops up, but we have only about a 50% 
> chance of getting the Julia splash and REPL prompt. We usually give up and 
> close the window after 20 seconds or so and try again. If we let it go, it 
> can take up to 5 minutes.
>
> *Painfully slow package manager*
>
> Pkg.installed() takes in excess of 60 seconds.
>
> Pkg.update() takes in excess of 60 seconds just to tell us nothing needs 
> to update.
>
> Pkg.add("SomePackage") takes in excess of 60 seconds before it takes any 
> action.
>
> Some packages cannot load at all, e.g. Nettle and URIParser, which are 
> required by our code.
>
> *Painfully slow Juno*
>
> I expect this is just due to the above.
>
> My colleague is an experienced Windows sys admin and and back-end web 
> developer. All his other application work fine. Only Julia does not seem to 
> be behaving.
>
> We've tried uninstalling Julia and reinstalling, but it doesn't help. 
> Where do I start? 
>
> Thank you for any help.
>

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

[colintbowers]

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] spurious update

[lewis]

This happens every once in a while:

Oct 27 19:05:21  julia[83314] : void CGSUpdateManager::log() 
const: conn 0x1ff43: spurious update.


This is the result of producing a PyPlot chart figure.  


Any one know why this happens?

[julia-users] Re: Inconsistent behaviour of round()

[Art Kuo]

Good point, the basic math docs should probably be updated. It is explained 
more clearly in the stdlib docs 

.

On Tuesday, October 27, 2015 at 9:43:50 PM UTC-4, jock@gmail.com wrote:
>
> Great, thanks Lex.
> The documentation for round 
>  
> is "round x to the nearest integer", which seems to be a mathematical 
> definition that isn't quite equivalent to the IEEE spec.
> The docs ought to mention rounding to the nearest.
>
>
> On Wednesday, October 28, 2015 at 12:35:12 PM UTC+11, ele...@gmail.com 
> wrote:
>>
>> "round to nearest, ties to even" is the default IEEE floating point 
>> rounding mode 
>> https://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules
>>
>> Cheers
>> Lex
>>
>> On Wednesday, October 28, 2015 at 11:02:58 AM UTC+10, jock@gmail.com 
>> wrote:
>>>
>>> Hi there,
>>>
>>> I'm using Julia 0.4.0.
>>>
>>> round(4.5) gives 4.0, i.e. it rounds down.
>>> round(5.5) gives 6.0, i.e. it rounds up.
>>>
>>> Any ideas why this is the case?
>>>
>>> Cheers,
>>> Jock
>>>
>>>

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

[lewis]

Here is some code:

using PyPlot

function chartplay()
one = figure(1)
plot(1:4)
two = figure(2)
scatter(randn(25),randn(25))
figure(1)
title("Title")
plt[:show]()
wm = get_current_fig_manager() 
dump(wm)
#= python code to get a plot figure window to be topmost.
I could not figure out how to do these calls
wm = plt.get_current_fig_manager() 
wm.window.attributes('-topmost', 1)
wm.window.attributes('-topmost', 0)
=#

#= attempt to use via julia PyPlot -- didn't work
plt[:window](wm, "-topmost", 1)
plt[:window](wm, "-topmost", 0)
# figure 1 should be either the top window of all or at least 
"above" figure 2
=#
end

[julia-users] Windows woes

[Eric Forgy]

Hi,

I am at a loss how to proceed, so please forgive a rambling unfocused plea 
for help and I appreciate any questions to help me focus my search for a 
solution.

I have Julia 0.4.0 installed on my MacBook running Windows 10 (I know I 
know :)). My installation is nice and snappy with no issues. I've got Juno 
set up and am quite happy.

My colleague, on the other hand, is having a miserable time running Julia. 
I am not sure how to even ask a question because, as far as I can tell, we 
have identical installations, i.e. the same Julia 0.4.0 from the same 
branch running on Windows 10, but his laptop is a Lenovo. It's no MacBook, 
but it is a new machine with 8GB RAM so should be ok.

Symptoms:

*Painfully slow startup if it even manages to startup at all*

When we launch Julia, the window pops up, but we have only about a 50% 
chance of getting the Julia splash and REPL prompt. We usually give up and 
close the window after 20 seconds or so and try again. If we let it go, it 
can take up to 5 minutes.

*Painfully slow package manager*

Pkg.installed() takes in excess of 60 seconds.

Pkg.update() takes in excess of 60 seconds just to tell us nothing needs to 
update.

Pkg.add("SomePackage") takes in excess of 60 seconds before it takes any 
action.

Some packages cannot load at all, e.g. Nettle and URIParser, which are 
required by our code.

*Painfully slow Juno*

I expect this is just due to the above.

My colleague is an experienced Windows sys admin and and back-end web 
developer. All his other application work fine. Only Julia does not seem to 
be behaving.

We've tried uninstalling Julia and reinstalling, but it doesn't help. Where 
do I start? 

Thank you for any help.

Re: [julia-users] Re: alternate LISP integration ...

[cdm]

i am grasping at resolving just how "fungible" a Julia required LISP is ...


could any LISP work (in theory) ... ?

what would the optimal LISP be ... ?

could the 22k wonder LISP be the optimal LISP ... ?


other contemplations appreciated !




On Tuesday, October 27, 2015 at 7:31:52 AM UTC-7, Jeff Bezanson wrote:
>
> Looks very cool! Of course I'd be interested in compiling julia's 
> frontend with something like this. We could badly use the extra speed. 
> I assume it supports macros, in which case I hope somebody makes a 
> library to undo the silly identifier renaming (e.g. defn -> define) so 
> it can run more scheme-like code. 
>

[julia-users] Re: Moving from 0.3 to 0.4

[Sheehan Olver]

I think you meant [a,b] -> [a; b]



On Tuesday, October 27, 2015 at 6:36:30 PM UTC+11, Alireza Nejati wrote:
>
> Most things in 0.3 will still work in 0.4 except with a handy depreciation 
> error which will tell you exactly what to fix. Here are some tips:
>
> - Use Compat.jl. It makes life a LOT easier. It lets you write a single 
> version of your code for 0.4 (or, more generally, the latest version of 
> julia) while automagically allowing your code to run in previous versions 
> as well.
>
> - Union(...) -> Union{}
>
> - FloatingPoint -> AbstractFloat
>
> - [a; b] -> [a, b]
>
> - [a, b] (if a and b are vectors) -> vcat(a, b)
>
> - float64([...]) -> map(Float64, [...]) or just Float64[...]
>
> These should cover most errors I've seen...
>
> Also a few coding notes: Now that Cartesian.jl is part of the Base 
> library, it makes sense to use it whenever you want to. Also, we're 
> gradually moving to slices becoming views so you might want to keep that in 
> mind.
>

[julia-users] Avoid type Unions in fields?

[Gnimuc Key]

>
> Avoid type Unions in fields ¶
>
> 
> type MyType
> ...
> x::Union{Void,T}
> end

 
I'm wondering whether it's a good style or not to write something like this:

type MyType
...
x::Union{Int64,Float64}end

what's the side effects of using Union like this?

[julia-users] How to debug the Debug.jl

[juliatylors]

I want to debug the Debug.jl itself?

Is there a special cut of instructions to do it? Because when i use @debug 
and @bp macro on itself. it fails.

Thanks