[julia-users] Re: [ANN] Nemo 0.5 released

[Jeffrey Sarnoff]

Congratulations on the new release.  

On Tuesday, July 26, 2016 at 5:07:44 PM UTC-4, Bill Hart wrote:
>
> Hi all,
>
> We are pleased to release version 0.5 of Nemo, our computer algebra 
> package written in Julia. 
>
> Instructions on how to get Nemo are on our website:
>
> http://nemocas.org/downloads.html
>
> Note that we have moved our repository, so existing users may need to 
> reinstall.
>
> Documentation for Nemo, including example code, how to get started etc., 
> is available online:
>
> http://nemocas.github.io/Nemo.jl/latest/
>
> The new features of Nemo 0.5 include:
>
> * Wrap Arb's arb_mat, acb_mat (matrices over R and C)
> * Wrap Arb's arb_poly, acb_poly (polys over R and C)
> * Completely rewritten, online documentation
> * Wrap Flint's fmpq_mat (matrices over Q)
> * Nullspace over the integers (using HNF)
> * Factorisations now return a Dict
> * Make caching of parent objects optional
> * Add benchmarks
> * Remove a lot of type instability
> * Integrate C libraries with Julia's counted malloc
> * Redesign abstract type hierarchy
> * Appveyor continuous integration for Windows
> * Lots of cleaning up and restructuring of the code base
> * Many bug fixes
>
> We will release a small update in the next few weeks to support Julia 0.5 
> when it comes out, However it should work with nightlies right now with 
> some warnings.
>  
> Enjoy,
>
> The Nemo Developers.
>

Re: [julia-users] Trouble figuring out some AsyncCondition behavior

[Spencer Russell]

OK, I think I’ve figured it out. Sorry for the noise. Feel free to ignore the 
rest unless you’re interested in what went wrong.

When `uv_async_send` gets called the first time it queues up the notifying of 
the `AsyncCondition`, then we queue up the async task. So when we hit the 
`yield()` we have 2 events queued and the behavior will depend on what order 
they’re popped off. I’m guessing that what’s happening is that the async task 
is running first, so that when the queued AsyncCondition notification runs, it 
unblocks the async task.

One fix would be to `yield()` after the `uv_async_send`, and assume that the 
scheduler will handle the async stuff before rescheduling the main task. 
Better, we can `wait(asynccond)` to be sure that it has fired before we move on.

This also highlights an important difference to keep in mind between a normal 
`Condition` and an `AsyncCondition` -

This will block indefinitely, because `notify` only affects tasks that are 
already waiting:
c = Condition()
notify(c)
wait(c)

but this won’t, because the underlying `notify` action doesn’t actually happen 
until the next yield point:
a = Base.AsyncCondition()
ccall(:uv_async_send, Cint, (Ptr{Void}, ), a.handle)
wait(a)


Below is the least race-condition-prone version I can think of. It doesn’t make 
any assumptions about what gets scheduled when we run `yield()`:

begin # wrapped for easy REPL-pasting

asynccond = Base.AsyncCondition()
startcond = Condition()
endcond = Condition()
n = 0
ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle)
wait(asynccond)
@schedule begin
global n
notify(startcond)
n += 1
wait(asynccond)
n += 1
notify(endcond)
end
wait(startcond) # make sure the async task has started
println("waiting, n: $n")
ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle)
wait(endcond) # make sure the async task woke up
# if we get here then the waiter was successfully woken
println("woke, n: $n")

end



maybe this will be helpful to someone (or to future me).

-s

> On Jul 26, 2016, at 3:54 PM, Spencer Russell  wrote:
> 
> Another clue - if I add another `yield()` after the first, I get "waiting, n: 
> 2”, which implies that the async task is waking up even though I haven’t 
> called `uv_async_send`.
> 
> Probably what’s going on below is that the `println` is switching to the 
> async task, so it finishes before we’ve run the 2nd `uv_async_send`, so then 
> when we wait on `waitcond` we wait forever.
> 
> So perhaps the question is - why is the async task being woken up without 
> calling `uv_async_send`?
> 
> -s
> 
>> On Jul 26, 2016, at 3:44 PM, Spencer Russell > > wrote:
>> 
>> I'm seeing some behavior with `AsyncCondition`s (on 0.5) that I don't 
>> understand. I'm not sure if it's a bug or expected behavior.
>> 
>> Here’s a minimal example that doesn’t work the way I expect:
>> 
>> begin # wrapped for easy REPL-pasting
>> 
>> asynccond = Base.AsyncCondition()
>> waitcond = Condition()
>> n = 0
>> ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle) # this seems 
>> like it shouldn't have any effect
>> @async begin
>> global n
>> n += 1
>> wait(asynccond)
>> n += 1
>> notify(waitcond)
>> end
>> yield() # give the async task a chance to run
>> println("waiting, n: $n")
>> ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle)
>> wait(waitcond)
>> # if we get here then the waiter was successfully woken
>> println("woke, n: $n")
>> 
>> end
>> 
>> Here’s what I’d expect to happen:
>> 
>> The first uv_async_send wouldn’t do anything because there are no tasks 
>> waiting on the AsyncCondition.
>> The async task is added to the scheduler
>> the main task hits the first yield(), which switches to the async task
>> the async task blocks waiting on asynccond, which hands control back to the 
>> main task
>> we print out n from the main task
>> this call to uv_async_send should put the async task back in the schedule 
>> queue
>> the main task blocks waiting on waitcond, which hands control back to the 
>> async task
>> the async task notifies waitcond, which should add the main task back to the 
>> schedule queue, then that task is complete
>> the main task prints the “woke” message
>> 
>> Instead it prints "waiting, n: 1”, then hangs.
>> It seems like the async task is never waking up from waiting on asynccond. 
>> If I remove the first `uv_async_send` or add a `yield()` immediately after 
>> it, then it works as expected.
>> 
>> Any ideas what’s going on?
>> 
>> -s
> 

[julia-users] Re: FFT, PSD and Windowing functions

[Islam Badreldin]

Hi Yared,



On Tuesday, July 26, 2016 at 10:25:45 AM UTC-4, Yared Melese wrote:
>
> Hi Islam, 
>
> Thanks again for your inputs, 
>
> the first method worked, as  you mentioned it was missing dot to do 
> element wise multiplication. 
>
> Here is what it looks like 
> pow_fs = (((2^(adc_bits-1))-1))^2 / 2
> fb= fb.*hanning(length(fb))
>
> When I tried the weltch function, it actually has two sets of data as 
> shown below, how do you split data to plot and manipulate the array? 
> Here is the command I used,  periodogram(fb*; 
> onesided=eltype(fb)<:Real*, *nfft=nextfastfft(length(fb)*, *fs=150*, 
> *window=hanning*)*¶* 
>  
>
> data collected 
>
>
First, note that you don't have to supply all the keyword arguments if the 
default values work for you. For example, you can get the same result as 
above by using
pdg = periodogram(fb; fs=150, window=hanning)

Second, you can split the data by inspecting the field names of the 
returned result
> fieldnames(pdg)
2-element Array{Symbol,1}:
 :power
 :freq 

> fb_power = pdg.power
> fb_freq = pdg.freq

You can then plot this data, using PyPlot for example

using PyPlot
plot(pdg.freq, pdg.power)



I hope this helps.

  -Islam
 

>
>  Thanks 
> Yared 
>
> On Friday, July 22, 2016 at 10:33:36 AM UTC-5, Islam Badreldin wrote:
>
>> Hi Yared,
>>
>> Please see below,,
>>
>> On Thursday, July 21, 2016 at 11:19:44 AM UTC-4, Yared Melese wrote:
>>
>>> Hi Islam, 
>>>
>>> Thanks for your input 
>>>
>>>  I was able to find all windowing functions; however, there is nothing 
>>> about PSD ( power spectral density). In python and matlab, there is 
>>> function pwelch which does both windowing and FFT and wondering if there is 
>>> the same function in Julia.
>>>
>>
>> Did you take a look at `welch_pgram` function?
>> http://dspjl.readthedocs.io/en/latest/periodograms.html#welch_pgram 
>> 
>>  
>>
>>
>>> Here is simple trial I had but it is complaining about type mismatch
>>>
>>> fb= fb[:]*hamming(length(fb))
>>> fb = fft(fb) # take FFT of signal 
>>>
>>> LoadError: MethodError: `*` has no method matching 
>>> *(::Array{Complex{Float64},1}, ::Array{Float64,1})
>>> Closest candidates are:
>>>   *(::Any, ::Any, !Matched::Any, !Matched::Any...)
>>>   
>>> *{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},S}(!Matched::Union{DenseArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2},SubArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}},
>>>  
>>> ::Union{DenseArray{S,1},SubArray{S,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>>>   
>>> *{TA,TB}(!Matched::Base.LinAlg.AbstractTriangular{TA,S<:AbstractArray{T,2}},
>>>  
>>> ::Union{DenseArray{TB,1},DenseArray{TB,2},SubArray{TB,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD},SubArray{TB,2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>>>   ...
>>> in include_string at loading.jl:282
>>> in include_string at C:\Users\melese\.julia\v0.4\CodeTools\src\eval.jl:32
>>> in anonymous at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:84
>>> in withpath at C:\Users\melese\.julia\v0.4\Requires\src\require.jl:37
>>> in withpath at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:53
>>> [inlined code] from C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:83
>>> in anonymous at task.jl:58
>>> while loading D:\userdata\melese\Desktop\fft.jl, in expression starting 
>>> on line 23
>>>
>>>
>> This particular error seems to be occurring at the `fb= 
>> fb[:]*hamming(length(fb))` line. It looks like you are multiplying an 
>> _vector_ of complex doubles with a _vector_ of doubles, which is not 
>> mathematically defined because of the dimension mismatch, since both 
>> vectors are of dimension Nx1. Instead, my guess is that you meant 
>> element-wise multiplication using `.*`. But again, I think the 
>> `welch_pgram` function should meet your needs.
>>
>>   -Islam
>>  
>>
>>>
>>> On Wednesday, July 20, 2016 at 9:15:40 AM UTC-5, Yared Melese wrote:
>>>
 Hello 

 Would you please let me know the package available to do windowing, FFT 
 and PSD? 

 Currently, I have bin file that I have processed in Julia and need to 
 window it and take preferably PSD but FFT work as well

 Thanks 
 Yared

  

Re: [julia-users] Tasks and STDIN

[Miguel Bazdresch]

This gets close to what you want, and works in a script (on Julia v0.4.6):

exitflag = [false]

@async while true
g = utf8(readavailable(STDIN))
println(g)
if g[1] == 'q'
println("Exiting task...")
exitflag[1] = true
break
end
end

while true
yield()
if exitflag[1]
break
end
end


This code prints what you type, and both the task and main loop exit when
you press 'q'. It's less than ideal, though, because it needs a newline
("enter") before it reads STDIN, and what you type is echoed to the screen
before it's read by `readavailable()`. These issues should be fixable. HTH,

-- mb

On Mon, Jul 25, 2016 at 9:37 PM,  wrote:

> I am trying to write a simple program that prints a message every time the
> user presses a key. The trick is that I would like this to happen
> *regardless* of what the program is doing otherwise. Eventually, I would
> like to use this method to interrupt a long running process, and allow me
> to check it's progress and modify parameters before restarting it, however
> I am struggling to get even this basic example to work. The following code
> snippet works in the REPL:
>
> function myTask()
> wait(STDIN.readnotify)
> println("Key Pressed!")
> end
>
> @async myTask()
>
> However it doesn't work when run as a script (because it exits before
> myTask completes). Adding an @sync begin ... end block around the @async
> call doesn't fix the problem in the script, and actually breaks the REPL
> version as well. How should I check for user input without actually
> stopping to wait if there is none?
>
> Thanks in advance for your help,
> Luke
>

[julia-users] cached iterator type (CachedIterator)

[Sheehan Olver]

I just put together a type that caches the values of a (possibly infinite) 
iterator, that I wanted to through up here in case its useful for others. 
 It assumes that the state of the input iterator is type stable.  Any 
suggestions for improving efficiency are welcome. 



## Cache iterator
type CachedIterator{T,IT,ST}
iterator::IT
storage::Vector{T}
state::ST
length::Int

CachedIterator(it::IT) = new(it,Vector{it}(),start(it),0)
end

CachedIterator(it) = 
CachedIterator{eltype(it),typeof(it),typeof(start(it))}(it)

function Base.resize!(it::CachedIterator,n::Integer)
m = it.length
if n > m
if n > length(it.storage)
resize!(it.storage,2n)
end

for k = m+1:n
if done(it.iterator,it.state)
it.length = k-1
return it
end
val,it.state = next(it.iterator,it.state)
@inbounds it.storage[k] = val
end

it.length = n
end
it
end


Base.eltype{T}(it::CachedIterator{T}) = T
Base.start(it::CachedIterator) = 1
Base.next(it::CachedIterator,st::Int) = (it[st],st+1)
Base.done(it::CachedIterator,st::Int) = st == it.length + 1 &&
done(it.iterator,it.state)


Base.getindex(it::CachedIterator,k::Int) = resize!(it,k).storage[k]

[julia-users] [ANN] Nemo 0.5 released

['Bill Hart' via julia-users]

Hi all,

We are pleased to release version 0.5 of Nemo, our computer algebra package 
written in Julia. 

Instructions on how to get Nemo are on our website:

http://nemocas.org/downloads.html

Note that we have moved our repository, so existing users may need to 
reinstall.

Documentation for Nemo, including example code, how to get started etc., is 
available online:

http://nemocas.github.io/Nemo.jl/latest/

The new features of Nemo 0.5 include:

* Wrap Arb's arb_mat, acb_mat (matrices over R and C)
* Wrap Arb's arb_poly, acb_poly (polys over R and C)
* Completely rewritten, online documentation
* Wrap Flint's fmpq_mat (matrices over Q)
* Nullspace over the integers (using HNF)
* Factorisations now return a Dict
* Make caching of parent objects optional
* Add benchmarks
* Remove a lot of type instability
* Integrate C libraries with Julia's counted malloc
* Redesign abstract type hierarchy
* Appveyor continuous integration for Windows
* Lots of cleaning up and restructuring of the code base
* Many bug fixes

We will release a small update in the next few weeks to support Julia 0.5 
when it comes out, However it should work with nightlies right now with 
some warnings.
 
Enjoy,

The Nemo Developers.

Re: [julia-users] Using Julia with Epsilon (EMACS)

[Isaiah Norton]

>
> The same command in the command prompt works fine.
> Has anyone seen this, or something like it, before?
>

https://github.com/JuliaLang/julia/issues/14776 looks similar. Worth
another thumbs-up at least ...

On Tue, Jul 26, 2016 at 12:31 PM, Gary Mallard 
wrote:

> I am trying to get Julia up and running under my normal editor.  The
> editor (epsilon) is an EMACS for Windows (and other platforms) and normally
> any program that runs as a console application runs under epsilon and
> epsilon captures all output text.  However when I try Julia I get the
> following:
>
> C:\Users\WGM\AppData\Local\Julia-0.4.6\bin>julia-debug.exe
> ERROR: MethodError: `convert` has no method matching
> convert(::Type{Base.TTY}, ::Base.PipeEndpoint)
> This may have arisen from a call to the constructor Base.TTY(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   Base.TTY(::Any)
>   call{T}(::Type{T}, ::Any)
>   convert{T}(::Type{T}, !Matched::T)
>   ...
>  in call at Terminals.jl:116
>  in _start at client.jl:388
>
> The same command in the command prompt works fine.
> Has anyone seen this, or something like it, before?
>
> Thanks,
> Gary
>
>

Re: [julia-users] Trouble figuring out some AsyncCondition behavior

[Spencer Russell]

Another clue - if I add another `yield()` after the first, I get "waiting, n: 
2”, which implies that the async task is waking up even though I haven’t called 
`uv_async_send`.

Probably what’s going on below is that the `println` is switching to the async 
task, so it finishes before we’ve run the 2nd `uv_async_send`, so then when we 
wait on `waitcond` we wait forever.

So perhaps the question is - why is the async task being woken up without 
calling `uv_async_send`?

-s

> On Jul 26, 2016, at 3:44 PM, Spencer Russell  wrote:
> 
> I'm seeing some behavior with `AsyncCondition`s (on 0.5) that I don't 
> understand. I'm not sure if it's a bug or expected behavior.
> 
> Here’s a minimal example that doesn’t work the way I expect:
> 
> begin # wrapped for easy REPL-pasting
> 
> asynccond = Base.AsyncCondition()
> waitcond = Condition()
> n = 0
> ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle) # this seems 
> like it shouldn't have any effect
> @async begin
> global n
> n += 1
> wait(asynccond)
> n += 1
> notify(waitcond)
> end
> yield() # give the async task a chance to run
> println("waiting, n: $n")
> ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle)
> wait(waitcond)
> # if we get here then the waiter was successfully woken
> println("woke, n: $n")
> 
> end
> 
> Here’s what I’d expect to happen:
> 
> The first uv_async_send wouldn’t do anything because there are no tasks 
> waiting on the AsyncCondition.
> The async task is added to the scheduler
> the main task hits the first yield(), which switches to the async task
> the async task blocks waiting on asynccond, which hands control back to the 
> main task
> we print out n from the main task
> this call to uv_async_send should put the async task back in the schedule 
> queue
> the main task blocks waiting on waitcond, which hands control back to the 
> async task
> the async task notifies waitcond, which should add the main task back to the 
> schedule queue, then that task is complete
> the main task prints the “woke” message
> 
> Instead it prints "waiting, n: 1”, then hangs.
> It seems like the async task is never waking up from waiting on asynccond. If 
> I remove the first `uv_async_send` or add a `yield()` immediately after it, 
> then it works as expected.
> 
> Any ideas what’s going on?
> 
> -s

[julia-users] Trouble figuring out some AsyncCondition behavior

[Spencer Russell]

I'm seeing some behavior with `AsyncCondition`s (on 0.5) that I don't 
understand. I'm not sure if it's a bug or expected behavior.

Here’s a minimal example that doesn’t work the way I expect:

begin # wrapped for easy REPL-pasting

asynccond = Base.AsyncCondition()
waitcond = Condition()
n = 0
ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle) # this seems like 
it shouldn't have any effect
@async begin
global n
n += 1
wait(asynccond)
n += 1
notify(waitcond)
end
yield() # give the async task a chance to run
println("waiting, n: $n")
ccall(:uv_async_send, Cint, (Ptr{Void}, ), asynccond.handle)
wait(waitcond)
# if we get here then the waiter was successfully woken
println("woke, n: $n")

end

Here’s what I’d expect to happen:

The first uv_async_send wouldn’t do anything because there are no tasks waiting 
on the AsyncCondition.
The async task is added to the scheduler
the main task hits the first yield(), which switches to the async task
the async task blocks waiting on asynccond, which hands control back to the 
main task
we print out n from the main task
this call to uv_async_send should put the async task back in the schedule queue
the main task blocks waiting on waitcond, which hands control back to the async 
task
the async task notifies waitcond, which should add the main task back to the 
schedule queue, then that task is complete
the main task prints the “woke” message

Instead it prints "waiting, n: 1”, then hangs.
It seems like the async task is never waking up from waiting on asynccond. If I 
remove the first `uv_async_send` or add a `yield()` immediately after it, then 
it works as expected.

Any ideas what’s going on?

-s

Re: [julia-users] Re: accessing an expression's global scope from macro

[Fábio Cardeal]

Alright! Here's a more complete and correct demonstration (And one I can 
fix without sending e-mails to everyone):
  https://gist.github.com/fcard/1bf78e9d4f6ea3be76518f6a0fbe0283

Sorry! Just don't wanna end the thread with wrong information, last one I 
promise!
(I will make sure to have any significant information in some editable 
place and link there from now on)
(eeep)

Also, Marius, can you confirm that the global was in fact the problem and 
it works fine now?
No hurry, just asking since I am here + things got a bit off-topic :P

Re: [julia-users] Effects of globals on dispatch + inlining

[Stefan Karpinski]

I'm a big fan of the "let's try it and see what it does" school of learning
a system.

On Tue, Jul 26, 2016 at 2:40 PM, Fábio Cardeal  wrote:

> Cool! Thanks a lot for the review :)
> I am gonna go ahead and post it on the other thread because I don't want
> wrong/incomplete information lingering there.
>
> Thanks again, and all the best!
>
> Em terça-feira, 26 de julho de 2016 11:50:13 UTC-3, Stefan Karpinski
> escreveu:
>>
>> That's a nice thorough analysis of the problem space and it looks correct
>> to me.
>>
>> On Mon, Jul 25, 2016 at 7:46 PM, Fábio Cardeal  wrote:
>>
>>>
>>> Hello . . .
>>>
>>>
>>>
>>> *BackstoryPreviously on julia-users...*
>>> Recently on another thread I tried to explain to someone how globals
>>> were messing with type dispatch and inlining.
>>> They probably already knew but it was a just a `make-sure` quick
>>> explanation, then I tripped over it and now I want to make sure **I**
>>> know.
>>> I experimented a little and posted a better explanation...
>>> I STILL missed a few things, as I am prone to do, so I made a little
>>> jupyter notebook to link to and revise when needed.
>>>
>>> *---*
>>>
>>> The notebook:
>>> https://gist.github.com/fcard/1bf78e9d4f6ea3be76518f6a0fbe0283
>>> It would be lovely if someone could take a quick look and see if the
>>> information there is correct and if I missed anything.
>>>
>>> Thanks!
>>>
>>
>>

Re: [julia-users] Effects of globals on dispatch + inlining

[Fábio Cardeal]

Cool! Thanks a lot for the review :)
I am gonna go ahead and post it on the other thread because I don't want 
wrong/incomplete information lingering there.

Thanks again, and all the best!

Em terça-feira, 26 de julho de 2016 11:50:13 UTC-3, Stefan Karpinski 
escreveu:
>
> That's a nice thorough analysis of the problem space and it looks correct 
> to me.
>
> On Mon, Jul 25, 2016 at 7:46 PM, Fábio Cardeal  > wrote:
>
>>
>> Hello . . .
>>
>>
>>
>> *BackstoryPreviously on julia-users...*
>> Recently on another thread I tried to explain to someone how globals were 
>> messing with type dispatch and inlining.
>> They probably already knew but it was a just a `make-sure` quick 
>> explanation, then I tripped over it and now I want to make sure **I** 
>> know.
>> I experimented a little and posted a better explanation...
>> I STILL missed a few things, as I am prone to do, so I made a little 
>> jupyter notebook to link to and revise when needed.
>>
>> *---*
>>
>> The notebook: 
>> https://gist.github.com/fcard/1bf78e9d4f6ea3be76518f6a0fbe0283
>> It would be lovely if someone could take a quick look and see if the 
>> information there is correct and if I missed anything.
>>
>> Thanks!
>>
>
>

[julia-users] Re: unable to connect to FTP using IP address

[Samuel Massinon]

No worries, can you show me how you get the file with another program?

On Tuesday, July 26, 2016 at 10:09:06 AM UTC-5, Yared Melese wrote:
>
> Hi Samuel, 
>
> Thanks for your inputs 
>
> I am trying to connect to a file server with IP address and get the latest 
> file with certain extension then process the data and save it on local 
> drive, then delete the file from the server. 
>
> Sorry, I don't know how to get files from Curl, it seems it is mainly 
> designed for Http 
>
> Thanks 
> Yared
>
>
>
>
>
>
> On Thursday, July 21, 2016 at 1:56:01 PM UTC-5, Samuel Massinon wrote:
>
>> Hi Yared,
>>
>> The error you are getting is something LibCURL is erring on, as described 
>> here. https://curl.haxx.se/libcurl/c/libcurl-errors.html
>>
>> If I try using curl with your settings, I get
>> ~ $ curl -u anonymous '192.168.251.200/dataOnFTP.bin'
>> Enter host password for user 'anonymous':
>> curl: (7) Failed to connect to 192.168.251.200 port 80: Network is 
>> unreachable
>>
>> The FTPClient.jl uses the same library as curl and if you could post how 
>> to get the file with curl, I might be able to better serve you.
>>
>> On Wednesday, July 20, 2016 at 4:17:29 PM UTC-5, Yared Melese wrote:
>>>
>>>
>>>
>>> Hello 
>>>
>>> Would you please let me know if I missed anything, I am using FTPClient 
>>> and using IP address as a host but not able to connect 
>>> Here are my commands 
>>>
>>> using FTPClient
>>> ftp_init()
>>> ftp = FTP(host="192.168.251.200", implt=true, ssl=true, 
>>> user="anonymous", pswd="")
>>> binary(ftp)
>>> file = download(ftp, "dataOnFTP.bin", "C:\Users\xyz\test.bin")
>>> close(ftp)
>>> ftp_cleanup()
>>>
>>> when sending  " using FTPClient" there are bunch of warnings as shown 
>>> below partially
>>> WARNING: Base.String is deprecated, use AbstractString instead.
>>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:35
>>> WARNING: Base.String is deprecated, use AbstractString instead.
>>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:67
>>> WARNING: Base.Uint8 is deprecated, use UInt8 instead.
>>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:81
>>> ..
>>> .
>>> .and at the end I am getting the following error 
>>>
>>> ERROR: Failed to connect. :: LibCURL error #7
>>>  [inlined code] from 
>>> C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:138
>>>  in ftp_command at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:454
>>>  in ftp_connect at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:493
>>>  in call at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPObject.jl:23
>>>
>>> Thanks 
>>> Yared
>>>
>>

[julia-users] Using Julia with Epsilon (EMACS)

[Gary Mallard]

I am trying to get Julia up and running under my normal editor.  The editor 
(epsilon) is an EMACS for Windows (and other platforms) and normally any 
program that runs as a console application runs under epsilon and epsilon 
captures all output text.  However when I try Julia I get the following:

C:\Users\WGM\AppData\Local\Julia-0.4.6\bin>julia-debug.exe
ERROR: MethodError: `convert` has no method matching 
convert(::Type{Base.TTY}, ::Base.PipeEndpoint)
This may have arisen from a call to the constructor Base.TTY(...),
since type constructors fall back to convert methods.
Closest candidates are:
  Base.TTY(::Any)
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, !Matched::T)
  ...
 in call at Terminals.jl:116
 in _start at client.jl:388

The same command in the command prompt works fine.
Has anyone seen this, or something like it, before?

Thanks,
Gary

[julia-users] Plans for green fairy and Traits.

[datnamer]

Hello everyone.  I have Two questions about the course of Julia.

1. Green Fairy. I don't recall it being mentioned at this year's JuliaCon. 
Are there plans to include it at all, and if so, would this be for the 1.0 
release?

2. Traits were mentioned for 2.0, but there has been some talk and 
development that indicates a potential 1.0 inclusion. This would change the 
way  I structure my code, so it would be helpful to get an update on 
whether the timeline has been moved up? 

Thanks 

Re: [julia-users] Re: Which package downgrades other packages?

[Tony Kelman]

I think some sort of internal hidden uuid appended to module names is going 
to become necessary for dealing with that, which would need compiler 
support.


On Tuesday, July 26, 2016 at 9:20:12 AM UTC-7, Andreas Lobinger wrote:
>
> Hello colleague,
>
> On Tuesday, July 26, 2016 at 5:58:28 PM UTC+2, Stefan Karpinski wrote:
>>
>> On Mon, Jul 25, 2016 at 1:23 PM, Stefan Karpinski  
>> wrote:
>>
>>> Compat.jl does this extensively with respect to Julia itself.
>>
>>
>> Another example, just submitted to BinDeps:
>>
>> https://github.com/JuliaLang/BinDeps.jl/commit/64c591da0cabafc2e319b2ef0dedc18a42d34c95
>> This happens all the time – I don't have a list of all the places off the 
>> top of my head, however.
>>
>
> i agree. Although i'd put Compat and BinDeps as central points for 
> attaching to the julia runtime/JIT rather as standard library and therefore 
> i assume the author(s) to be active on githup...
> You also mention naming conflicts between local and published packages in 
> your 1.0 talk. 
> So from my perspective more fine-grained dependency resolution (different 
> environment for different packages, not only a single METAFILE) will 
> probably show up.
>
>
>

Re: [julia-users] Re: Which package downgrades other packages?

[Andreas Lobinger]

Hello colleague,

On Tuesday, July 26, 2016 at 5:58:28 PM UTC+2, Stefan Karpinski wrote:
>
> On Mon, Jul 25, 2016 at 1:23 PM, Stefan Karpinski  > wrote:
>
>> Compat.jl does this extensively with respect to Julia itself.
>
>
> Another example, just submitted to BinDeps:
>
> https://github.com/JuliaLang/BinDeps.jl/commit/64c591da0cabafc2e319b2ef0dedc18a42d34c95
> This happens all the time – I don't have a list of all the places off the 
> top of my head, however.
>

i agree. Although i'd put Compat and BinDeps as central points for 
attaching to the julia runtime/JIT rather as standard library and therefore 
i assume the author(s) to be active on githup...
You also mention naming conflicts between local and published packages in 
your 1.0 talk. 
So from my perspective more fine-grained dependency resolution (different 
environment for different packages, not only a single METAFILE) will 
probably show up.

Re: [julia-users] Re: Which package downgrades other packages?

[Stefan Karpinski]

On Mon, Jul 25, 2016 at 1:23 PM, Stefan Karpinski 
wrote:

> Compat.jl does this extensively with respect to Julia itself.


Another example, just submitted to BinDeps:

https://github.com/JuliaLang/BinDeps.jl/commit/64c591da0cabafc2e319b2ef0dedc18a42d34c95

This happens all the time – I don't have a list of all the places off the
top of my head, however.

[julia-users] Re: Tasks and STDIN

[ggggg]

You can do wait(@async myTask()) to keep it from exiting before the task 
completes. But it still doesn't work for some reason.

[julia-users] Re: unable to connect to FTP using IP address

[Yared Melese]

Hi Samuel, 

Thanks for your inputs 

I am trying to connect to a file server with IP address and get the latest 
file with certain extension then process the data and save it on local 
drive, then delete the file from the server. 

Sorry, I don't know how to get files from Curl, it seems it is mainly 
designed for Http 

Thanks 
Yared






On Thursday, July 21, 2016 at 1:56:01 PM UTC-5, Samuel Massinon wrote:

> Hi Yared,
>
> The error you are getting is something LibCURL is erring on, as described 
> here. https://curl.haxx.se/libcurl/c/libcurl-errors.html
>
> If I try using curl with your settings, I get
> ~ $ curl -u anonymous '192.168.251.200/dataOnFTP.bin'
> Enter host password for user 'anonymous':
> curl: (7) Failed to connect to 192.168.251.200 port 80: Network is 
> unreachable
>
> The FTPClient.jl uses the same library as curl and if you could post how 
> to get the file with curl, I might be able to better serve you.
>
> On Wednesday, July 20, 2016 at 4:17:29 PM UTC-5, Yared Melese wrote:
>>
>>
>>
>> Hello 
>>
>> Would you please let me know if I missed anything, I am using FTPClient 
>> and using IP address as a host but not able to connect 
>> Here are my commands 
>>
>> using FTPClient
>> ftp_init()
>> ftp = FTP(host="192.168.251.200", implt=true, ssl=true, user="anonymous", 
>> pswd="")
>> binary(ftp)
>> file = download(ftp, "dataOnFTP.bin", "C:\Users\xyz\test.bin")
>> close(ftp)
>> ftp_cleanup()
>>
>> when sending  " using FTPClient" there are bunch of warnings as shown 
>> below partially
>> WARNING: Base.String is deprecated, use AbstractString instead.
>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:35
>> WARNING: Base.String is deprecated, use AbstractString instead.
>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:67
>> WARNING: Base.Uint8 is deprecated, use UInt8 instead.
>>   likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:81
>> ..
>> .
>> .and at the end I am getting the following error 
>>
>> ERROR: Failed to connect. :: LibCURL error #7
>>  [inlined code] from C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:138
>>  in ftp_command at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:454
>>  in ftp_connect at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:493
>>  in call at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPObject.jl:23
>>
>> Thanks 
>> Yared
>>
>

Re: [julia-users] Effects of globals on dispatch + inlining

[Stefan Karpinski]

That's a nice thorough analysis of the problem space and it looks correct
to me.

On Mon, Jul 25, 2016 at 7:46 PM, Fábio Cardeal  wrote:

>
> Hello . . .
>
>
>
> *BackstoryPreviously on julia-users...*
> Recently on another thread I tried to explain to someone how globals were
> messing with type dispatch and inlining.
> They probably already knew but it was a just a `make-sure` quick
> explanation, then I tripped over it and now I want to make sure **I**
> know.
> I experimented a little and posted a better explanation...
> I STILL missed a few things, as I am prone to do, so I made a little
> jupyter notebook to link to and revise when needed.
>
> *---*
>
> The notebook:
> https://gist.github.com/fcard/1bf78e9d4f6ea3be76518f6a0fbe0283
> It would be lovely if someone could take a quick look and see if the
> information there is correct and if I missed anything.
>
> Thanks!
>

[julia-users] Tasks and STDIN

[adamslc]

I am trying to write a simple program that prints a message every time the 
user presses a key. The trick is that I would like this to happen 
*regardless* of what the program is doing otherwise. Eventually, I would 
like to use this method to interrupt a long running process, and allow me 
to check it's progress and modify parameters before restarting it, however 
I am struggling to get even this basic example to work. The following code 
snippet works in the REPL:

function myTask()
wait(STDIN.readnotify)
println("Key Pressed!")
end

@async myTask()

However it doesn't work when run as a script (because it exits before 
myTask completes). Adding an @sync begin ... end block around the @async 
call doesn't fix the problem in the script, and actually breaks the REPL 
version as well. How should I check for user input without actually 
stopping to wait if there is none?

Thanks in advance for your help,
Luke

[julia-users] Re: FFT, PSD and Windowing functions

[Yared Melese]

Hi Islam, 

Thanks again for your inputs, 

the first method worked, as  you mentioned it was missing dot to do element 
wise multiplication. 

Here is what it looks like 
pow_fs = (((2^(adc_bits-1))-1))^2 / 2
fb= fb.*hanning(length(fb))

When I tried the weltch function, it actually has two sets of data as shown 
below, how do you split data to plot and manipulate the array? 
Here is the command I used,  periodogram(fb*; onesided=eltype(fb)<:Real*, 
*nfft=nextfastfft(length(fb)*, *fs=150*, *window=hanning*)*¶* 
 

data collected 


 Thanks 
Yared 

On Friday, July 22, 2016 at 10:33:36 AM UTC-5, Islam Badreldin wrote:

> Hi Yared,
>
> Please see below,,
>
> On Thursday, July 21, 2016 at 11:19:44 AM UTC-4, Yared Melese wrote:
>
>> Hi Islam, 
>>
>> Thanks for your input 
>>
>>  I was able to find all windowing functions; however, there is nothing 
>> about PSD ( power spectral density). In python and matlab, there is 
>> function pwelch which does both windowing and FFT and wondering if there is 
>> the same function in Julia.
>>
>
> Did you take a look at `welch_pgram` function?
> http://dspjl.readthedocs.io/en/latest/periodograms.html#welch_pgram 
> 
>  
>
>
>> Here is simple trial I had but it is complaining about type mismatch
>>
>> fb= fb[:]*hamming(length(fb))
>> fb = fft(fb) # take FFT of signal 
>>
>> LoadError: MethodError: `*` has no method matching 
>> *(::Array{Complex{Float64},1}, ::Array{Float64,1})
>> Closest candidates are:
>>   *(::Any, ::Any, !Matched::Any, !Matched::Any...)
>>   
>> *{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},S}(!Matched::Union{DenseArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2},SubArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}},
>>  
>> ::Union{DenseArray{S,1},SubArray{S,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>>   
>> *{TA,TB}(!Matched::Base.LinAlg.AbstractTriangular{TA,S<:AbstractArray{T,2}}, 
>> ::Union{DenseArray{TB,1},DenseArray{TB,2},SubArray{TB,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD},SubArray{TB,2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>>   ...
>> in include_string at loading.jl:282
>> in include_string at C:\Users\melese\.julia\v0.4\CodeTools\src\eval.jl:32
>> in anonymous at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:84
>> in withpath at C:\Users\melese\.julia\v0.4\Requires\src\require.jl:37
>> in withpath at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:53
>> [inlined code] from C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:83
>> in anonymous at task.jl:58
>> while loading D:\userdata\melese\Desktop\fft.jl, in expression starting 
>> on line 23
>>
>>
> This particular error seems to be occurring at the `fb= 
> fb[:]*hamming(length(fb))` line. It looks like you are multiplying an 
> _vector_ of complex doubles with a _vector_ of doubles, which is not 
> mathematically defined because of the dimension mismatch, since both 
> vectors are of dimension Nx1. Instead, my guess is that you meant 
> element-wise multiplication using `.*`. But again, I think the 
> `welch_pgram` function should meet your needs.
>
>   -Islam
>  
>
>>
>> On Wednesday, July 20, 2016 at 9:15:40 AM UTC-5, Yared Melese wrote:
>>
>>> Hello 
>>>
>>> Would you please let me know the package available to do windowing, FFT 
>>> and PSD? 
>>>
>>> Currently, I have bin file that I have processed in Julia and need to 
>>> window it and take preferably PSD but FFT work as well
>>>
>>> Thanks 
>>> Yared
>>>
>>>  
>>>
>>>

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

[Oliver Schulz]

Thanks, I did: https://github.com/JuliaLang/julia/issues/17631

On Tuesday, July 26, 2016 at 3:32:58 PM UTC+2, Tim Holy wrote:
>
> My only goal is to provide a smooth path for catching likely bugs in 
> "legacy" 
> code; if people start abusing `len`, that's their own *#!$ fault. This is 
> about protecting the innocent (people who wrote code that was perfectly 
> fine in 
> an earlier era), not about trying to prevent abuse. 
>
> So, I'm not against giving _length a better name and exporting it. Could 
> you 
> please file these concerns as an issue? It might get more attention from 
> the 
> right parties that way. 
>
> Best, 
> --Tim 
>
> On Tuesday, July 26, 2016 5:03:31 AM CDT Oliver Schulz wrote: 
> > > Are you saying we should export what is currently _length? 
> > 
> > Well, maybe not exactly length, but I believe Base should export some 
> short 
> > equivalent length(linearindices(A)), to encourage people to write code 
> that 
> > will work with both standard and custom-indexed arrays. 
> > 
> > In a sense (at least according to 
> > http://docs.julialang.org/en/latest/devdocs/offset-arrays/), we're 
> kinda 
> > deprecating Base.length. Not explicitly, but as the recommendation is to 
> > not support it for custom-indexed arrays, I can't use Base.length any 
> more 
> > if I want to write generic code. After all, I don't know if someone else 
> > may want to use my function with a custom-indexed array. But I find that 
> I 
> > often do need the length of the input (e.g. for normalization), 
> > and length(linearindices(A)) is just soo unwieldy. Of course every 
> package 
> > can define it's own shortcut for it - but isn't that a bit un-Julianic? 
> Or 
> > are you worried that people will then start using (e.g.) 1:len(A) 
> instead 
> > of 1:length(A), resulting in an even bigger mess? 
> > 
> > On Tuesday, July 26, 2016 at 1:47:57 PM UTC+2, Tim Holy wrote: 
> > > On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote: 
> > > > I should have known you already have a (very elegant) solution in 
> your 
> > > > pocket. :-) I really like your proposed first:last syntax! 
> > > 
> > > As discussed in that issue, the problem is that it may not be workable 
> > > (it's 
> > > also very unlikely to be merged for julia 0.5). The "safe" alternative 
> is 
> > > to 
> > > modify the parser, although that has the disadvantage that you can't 
> pass 
> > > constructs with `start` or `end` as arguments to functions---it only 
> works 
> > > inside of [] brackets, which was what motivated addition of the 
> `@view` 
> > > macro. 
> > > Bottom line is that we don't have a good solution to this problem at 
> the 
> > > moment. 
> > > 
> > > Interestingly, it seems likely that one could experiment with https:// 
> > > github.com/JuliaLang/julia/pull/15750 in a package. If it becomes 
> popular 
> > > then 
> > > it might help clarify whether one should move it into base. 
> > > 
> > > > Concerning Base._length, I was rather thinking about something for 
> the 
> > > > average user to use instead of length. For everyday 
> > > > use, length(linearindices(A)) is just too unwieldy, IMHO. 
> > > 
> > > Are you saying we should export what is currently _length? Keep in 
> mind 
> > > that 
> > > folks who want to add support for unconventional indices to their own 
> > > packages 
> > > can of course make this one-line definition themselves, and then they 
> > > don't 
> > > have to worry about whether Base will eliminate or rename it. 
> > > 
> > > Best, 
> > > --Tim 
>
>
>

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

[Tim Holy]

My only goal is to provide a smooth path for catching likely bugs in "legacy" 
code; if people start abusing `len`, that's their own *#!$ fault. This is 
about protecting the innocent (people who wrote code that was perfectly fine in 
an earlier era), not about trying to prevent abuse.

So, I'm not against giving _length a better name and exporting it. Could you 
please file these concerns as an issue? It might get more attention from the 
right parties that way.

Best,
--Tim

On Tuesday, July 26, 2016 5:03:31 AM CDT Oliver Schulz wrote:
> > Are you saying we should export what is currently _length?
> 
> Well, maybe not exactly length, but I believe Base should export some short
> equivalent length(linearindices(A)), to encourage people to write code that
> will work with both standard and custom-indexed arrays.
> 
> In a sense (at least according to
> http://docs.julialang.org/en/latest/devdocs/offset-arrays/), we're kinda
> deprecating Base.length. Not explicitly, but as the recommendation is to
> not support it for custom-indexed arrays, I can't use Base.length any more
> if I want to write generic code. After all, I don't know if someone else
> may want to use my function with a custom-indexed array. But I find that I
> often do need the length of the input (e.g. for normalization),
> and length(linearindices(A)) is just soo unwieldy. Of course every package
> can define it's own shortcut for it - but isn't that a bit un-Julianic? Or
> are you worried that people will then start using (e.g.) 1:len(A) instead
> of 1:length(A), resulting in an even bigger mess?
> 
> On Tuesday, July 26, 2016 at 1:47:57 PM UTC+2, Tim Holy wrote:
> > On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote:
> > > I should have known you already have a (very elegant) solution in your
> > > pocket. :-) I really like your proposed first:last syntax!
> > 
> > As discussed in that issue, the problem is that it may not be workable
> > (it's
> > also very unlikely to be merged for julia 0.5). The "safe" alternative is
> > to
> > modify the parser, although that has the disadvantage that you can't pass
> > constructs with `start` or `end` as arguments to functions---it only works
> > inside of [] brackets, which was what motivated addition of the `@view`
> > macro.
> > Bottom line is that we don't have a good solution to this problem at the
> > moment.
> > 
> > Interestingly, it seems likely that one could experiment with https://
> > github.com/JuliaLang/julia/pull/15750 in a package. If it becomes popular
> > then
> > it might help clarify whether one should move it into base.
> > 
> > > Concerning Base._length, I was rather thinking about something for the
> > > average user to use instead of length. For everyday
> > > use, length(linearindices(A)) is just too unwieldy, IMHO.
> > 
> > Are you saying we should export what is currently _length? Keep in mind
> > that
> > folks who want to add support for unconventional indices to their own
> > packages
> > can of course make this one-line definition themselves, and then they
> > don't
> > have to worry about whether Base will eliminate or rename it.
> > 
> > Best,
> > --Tim

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

[Tim Holy]

OK, new package here:

https://github.com/timholy/EndpointRanges.jl

It might make life easier even for folks who aren't using custom-indexed 
arrays. Give it a whirl and see what breaks!

Best,
--Tim

On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote:
> Hi Tim,
> 
> I should have known you already have a (very elegant) solution in your
> pocket. :-) I really like your proposed first:last syntax!
> 
> Concerning Base._length, I was rather thinking about something for the
> average user to use instead of length. For everyday
> use, length(linearindices(A)) is just too unwieldy, IMHO.
> 
> 
> Cheers,
> 
> Oliver
> 
> On Tuesday, July 26, 2016 at 9:21:27 AM UTC+2, Oliver Schulz wrote:
> > I was reading up on the new arrays with custom indices in 0.5. Now that
> > array indices do not implicitly start with one, what's the generic
> > replacement for index ranges like
> > 
> > A[2:end-1]
> > 
> > Will there by something like
> > 
> > A[start+1:end-1]
> > 
> > or so?
> > 
> > Also, since for safety reasons length(A) is now supposed to throw an error
> > for custom-indexed Arrays (for safety, to prevent 1:length[A]), the
> > current
> > recommendation
> > (http://docs.julialang.org/en/latest/devdocs/offset-arrays/)
> > is to use
> > 
> > length(linearindices(A))
> > 
> > instead of length() in generic code. This strikes me as very lengthy
> > indeed (pardon the pun) and will make code less readable - how about a new
> > length function like
> > 
> > Base.len(A) = length(linearindices(A))
> > 
> > or similar? If there's no "official" replacement for length in Base, I
> > suspect that packages will add their own internal version of it at some
> > point. Also, people might get tempted to continue using length() out of
> > laziness (if there's no short replacement) - resulting in code that fails
> > for the new arrays.

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

[Oliver Schulz]

> Are you saying we should export what is currently _length?

Well, maybe not exactly length, but I believe Base should export some short 
equivalent length(linearindices(A)), to encourage people to write code that 
will work with both standard and custom-indexed arrays.

In a sense (at least according to 
http://docs.julialang.org/en/latest/devdocs/offset-arrays/), we're kinda 
deprecating Base.length. Not explicitly, but as the recommendation is to 
not support it for custom-indexed arrays, I can't use Base.length any more 
if I want to write generic code. After all, I don't know if someone else 
may want to use my function with a custom-indexed array. But I find that I 
often do need the length of the input (e.g. for normalization), 
and length(linearindices(A)) is just soo unwieldy. Of course every package 
can define it's own shortcut for it - but isn't that a bit un-Julianic? Or 
are you worried that people will then start using (e.g.) 1:len(A) instead 
of 1:length(A), resulting in an even bigger mess?

On Tuesday, July 26, 2016 at 1:47:57 PM UTC+2, Tim Holy wrote:
>
> On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote: 
> > I should have known you already have a (very elegant) solution in your 
> > pocket. :-) I really like your proposed first:last syntax! 
>
> As discussed in that issue, the problem is that it may not be workable 
> (it's 
> also very unlikely to be merged for julia 0.5). The "safe" alternative is 
> to 
> modify the parser, although that has the disadvantage that you can't pass 
> constructs with `start` or `end` as arguments to functions---it only works 
> inside of [] brackets, which was what motivated addition of the `@view` 
> macro. 
> Bottom line is that we don't have a good solution to this problem at the 
> moment. 
>
> Interestingly, it seems likely that one could experiment with https:// 
> github.com/JuliaLang/julia/pull/15750 in a package. If it becomes popular 
> then 
> it might help clarify whether one should move it into base. 
>
> > Concerning Base._length, I was rather thinking about something for the 
> > average user to use instead of length. For everyday 
> > use, length(linearindices(A)) is just too unwieldy, IMHO. 
>
> Are you saying we should export what is currently _length? Keep in mind 
> that 
> folks who want to add support for unconventional indices to their own 
> packages 
> can of course make this one-line definition themselves, and then they 
> don't 
> have to worry about whether Base will eliminate or rename it. 
>
> Best, 
> --Tim 
>
>

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

[Tim Holy]

On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote:
> I should have known you already have a (very elegant) solution in your
> pocket. :-) I really like your proposed first:last syntax!

As discussed in that issue, the problem is that it may not be workable (it's 
also very unlikely to be merged for julia 0.5). The "safe" alternative is to 
modify the parser, although that has the disadvantage that you can't pass 
constructs with `start` or `end` as arguments to functions---it only works 
inside of [] brackets, which was what motivated addition of the `@view` macro. 
Bottom line is that we don't have a good solution to this problem at the 
moment.

Interestingly, it seems likely that one could experiment with https://
github.com/JuliaLang/julia/pull/15750 in a package. If it becomes popular then 
it might help clarify whether one should move it into base.

> Concerning Base._length, I was rather thinking about something for the
> average user to use instead of length. For everyday
> use, length(linearindices(A)) is just too unwieldy, IMHO.

Are you saying we should export what is currently _length? Keep in mind that 
folks who want to add support for unconventional indices to their own packages 
can of course make this one-line definition themselves, and then they don't 
have to worry about whether Base will eliminate or rename it.

Best,
--Tim

Re: [julia-users] Re: A Very Simple Benchmark for Brutal-force Loops in Several Languages: revised, Julia is fast!

[dextorious]

Since I contributed the Numba JIT timing earlier in the thread, it seems 
only fair to note that the modified Julia version with the properly 
preallocated data is now 17% faster than the Numba version on my computer. 
Overall, this seems to support my thesis that good Julia code is on par or 
slightly faster than the Python code using the JIT libraries (Numba, Hope, 
Parakeet, etc.) with the added benefit of not requiring external libraries. 
I've also seen some cases where the difference is even more pronounced in 
the favor of Julia because of the ability to use @simd to prod the LLVM 
vectorizer along and the ability to exert precise control over memory 
allocations, but this is highly use case specific.

On Tuesday, July 26, 2016 at 12:47:53 AM UTC+3, Tim Holy wrote:
>
> Given the apparent interest in the topic and the decisions that people 
> seem to 
> be making, it seems worth pointing out that folks are still using 
> apples-to- 
> oranges comparisons on this benchmark. 
>
> There are at least two important differences: 
> - in the other languages, `linspace` allocates a vector, but in Julia it 
> (currently) creates a compact object from which values are computed 
> on-the-fly. 
> That computation involves a division, and division is slow. 
> - The languages like C aren't doing bounds-checking. You might imagine 
> adding 
> `@inbounds` to the Julia version. But `@inbounds` has no impact on 
> LinSpace 
> objects in julia 0.4. In julia 0.5, it does work like you'd expect 
> (thanks, 
> Blake Johnson). 
>
> Combining these observations, we can `collect` the values into a `Vector` 
> and 
> then use `@inbounds`. For me the version below is nearly twice as fast as 
> the 
> original: 
>
> function benchmark() 
> nsamples = 100 
> x = collect(linspace(0, 5, nsamples)) 
> y = zeros(nsamples) 
> # attempt to trigger JIT to compile all functions needed in the loops 
> # before profiling 
> a = cos(0.0); a = 1.5*2.5; a = 1.5+2.5; 
> println("\nBrutal-force loops, 100 times:") 
> @time begin 
> for m = 1:100 
> @inbounds for n = 1:nsamples 
> y[n] = cos(2*x[n]+5); 
> end 
> end 
> end 
> end 
> benchmark(); 
>
> Best, 
> --Tim 
>
> On Monday, July 25, 2016 2:02:41 PM CDT Zhong Pan wrote: 
> > Agree that while raw speed is important, in most situations it wouldn't 
> be 
> > the most important reason to choose one programming language over 
> another. 
> > 
> > I came from the angle of an engineer in a small company. For myself, the 
> > main attraction of Julia was the easiness to achieve decent speed 
> without 
> > making much explicit effort: that means what feels more natural 
> vectorized 
> > will be vectorized, while what feels more natural in a loop will be in a 
> > loop; that means I don't need to resort to another language or a library 
> > only for improving speed; and that means apart from sticking to a couple 
> > good habits, I can use objects, functions etc. the same way inside a 
> loop 
> > vs. outside. None of these is critical by itself, but they add up to an 
> > uninterrupted flow of thoughts while writing code to explore, try, fail, 
> > and retry, for many iterations. 
> > 
> > During this "less careful" prototyping, 1-2x slow down is fine, but with 
> > Julia I know I won't sit there for tens of minutes waiting for a result 
> > while debating myself whether I should rewrite it in C++ or rehaul the 
> code 
> > with Cython etc.; instead I can rest assured that as long as my algo and 
> > coding have no mistakes or major flaws, the speed is close to what I 
> will 
> > get even if I make several times more effort to rewrite it in C++. 
> > 
> > Another big deal for me is the resulted removal of the barrier between 
> > prototype and production code. For production I can review and improve 
> my 
> > code carefully, but rewriting it in a less expressive language is too 
> much. 
> > 
> > I was a huge fan of Python (heck I even persuaded my previous boss, a 
> VP, 
> > to pick up Python - though I don't know if he really had time to finish 
> it. 
> > 
> > :-)). However, the slow raw speed and the over-freedom to change class 
> > 
> > definition anywhere always gave me the itch to find something better. My 
> > brother at JPL who worked on Python projects also complained about 
> having 
> > to think really hard to vectorize almost everything and then couldn't 
> > easily understand what he was doing a few months later because the code 
> was 
> > too unnatural for the problem; the indentation was also a big headache 
> as 
> > collaborators use different editors with different tab definitions. 
> > 
> > So I'm really happy to have found Julia, which gave me the same joy as 
> > coding in Python and removed the main itches. 
> > 
> > -Zhong 
>
>
>

Re: [julia-users] Re: What packages, features, other strengths would you recommend when showing Julia to molecular neurobiologists?

[Job van der Zwan]

@Chris: thanks for the tips!

@Tamas: oh I know what you mean, and don't worry, I'm definitely not 
planning on telling these people how they should do their research! But as 
a counterpoint: they also are so focused and busy dealing with their 
research problems that they don't really have the time to leisurely explore 
what Julia has to offer them (like in that cartoon with square wheels[0], 
although I find that one a bit condescending). Surely it wont hurt doing 
some prep-work for them by finding relevant examples, like Stefan suggests, 
and let them evaluate if it's worth their time.

@Stefan: one example of programming-related struggle within the group is 
that one of them works best in matlab, and he created new clustering 
algorithm called BackSPIN. Then another member of the group ported it to 
Python to make it more widely accessible[1]. But now the first guy has come 
up with an improvement for his algorithm, but the resulting matlab code is 
so complex that the second guy is struggling with porting it. Meanwhile, my 
sole contribution to the whole thing is making sure NumPy's in-place 
methods are used everywhere, and replacing a scalar matrix division with a 
one-over-scalar multiplication in the innermost loop, speeding it up by 
40%. All of which required no understanding of the algorithm.

Anyway, the professor pushed for the whole group to switch to Python to 
prevent exactly this this problem. So now a new member of the team has to 
learn Python because his main language so far is R.

I was thinking that perhaps Julia as a language (plus PyCall, RCall and 
MATLAB.jl) would provide a more appealing compromise for them. What's 
appealing about it to me is that would be easier for me to contribute 
dumb-but-effective low-level optimisations while they work out better 
high-level algorithms.

[0] 
https://hakanforss.files.wordpress.com/2014/03/are-you-too-busy-to-improve2.png
[1] https://github.com/linnarsson-lab/BackSPIN

[julia-users] Re: Writing code compatible with custom-indexed arrays

[Oliver Schulz]

Hi Tim,

I should have known you already have a (very elegant) solution in your 
pocket. :-) I really like your proposed first:last syntax!

Concerning Base._length, I was rather thinking about something for the 
average user to use instead of length. For everyday 
use, length(linearindices(A)) is just too unwieldy, IMHO.


Cheers,

Oliver


On Tuesday, July 26, 2016 at 9:21:27 AM UTC+2, Oliver Schulz wrote:
>
> I was reading up on the new arrays with custom indices in 0.5. Now that 
> array indices do not implicitly start with one, what's the generic 
> replacement for index ranges like
>
> A[2:end-1]
>
> Will there by something like
>
> A[start+1:end-1]
>
> or so?
>
> Also, since for safety reasons length(A) is now supposed to throw an error 
> for custom-indexed Arrays (for safety, to prevent 1:length[A]), the current 
> recommendation (http://docs.julialang.org/en/latest/devdocs/offset-arrays/) 
> is to use
>
> length(linearindices(A))
>
> instead of length() in generic code. This strikes me as very lengthy 
> indeed (pardon the pun) and will make code less readable - how about a new 
> length function like
>
> Base.len(A) = length(linearindices(A))
>
> or similar? If there's no "official" replacement for length in Base, I 
> suspect that packages will add their own internal version of it at some 
> point. Also, people might get tempted to continue using length() out of 
> laziness (if there's no short replacement) - resulting in code that fails 
> for the new arrays.
>
>
>

Re: [julia-users] Writing code compatible with custom-indexed arrays

[Tim Holy]

Hi Oliver,

On Tuesday, July 26, 2016 12:21:27 AM CDT Oliver Schulz wrote:
> Will there by something like
> 
> A[start+1:end-1]

That would be lovely. See discussion in https://github.com/JuliaLang/julia/
pull/15750.

> length(linearindices(A))
> 
> instead of length() in generic code. This strikes me as very lengthy indeed
> (pardon the pun) and will make code less readable - how about a new length
> function like
> 
> Base.len(A) = length(linearindices(A))
> 
> or similar?

There's Base._length(A), though of course keep in mind that it's not exported 
and thus subject to change more than most.

Best,
--Tim

[julia-users] Re: Tuple type to tuple of types

[jw3126]

Thanks!

On Sunday, July 24, 2016 at 1:52:47 PM UTC+2, jw3126 wrote:
>
> I need a function, which accepts an arbitrary tuple type and returns the 
> types of the components of the tuple. For example
> ```
> f(Tuple{Int64, Float64})--> (Int64, Float64)
> f(Tuple{Int64, MyType, Float32}) --> (Int64, MyType, Float32)
> f(NTuple{3})  --> (Any, Any, Any)
> f(Tuple) --> Some error since 
> length is unknown
> ```
>
> How to accomplish this?
>

[julia-users] Writing code compatible with custom-indexed arrays

[Oliver Schulz]

I was reading up on the new arrays with custom indices in 0.5. Now that 
array indices do not implicitly start with one, what's the generic 
replacement for index ranges like

A[2:end-1]

Will there by something like

A[start+1:end-1]

or so?

Also, since for safety reasons length(A) is now supposed to throw an error 
for custom-indexed Arrays (for safety, to prevent 1:length[A]), the current 
recommendation (http://docs.julialang.org/en/latest/devdocs/offset-arrays/) 
is to use

length(linearindices(A))

instead of length() in generic code. This strikes me as very lengthy indeed 
(pardon the pun) and will make code less readable - how about a new length 
function like

Base.len(A) = length(linearindices(A))

or similar? If there's no "official" replacement for length in Base, I 
suspect that packages will add their own internal version of it at some 
point. Also, people might get tempted to continue using length() out of 
laziness (if there's no short replacement) - resulting in code that fails 
for the new arrays.

[julia-users] Re: Setting socket options in ZMQ.jl

[Jeffrey Sarnoff]

>
> How are ZMQ socket options specified in Julia?

 
the attached file may help you


On Monday, July 18, 2016 at 6:15:52 PM UTC-4, Salman Haider wrote:
>
>
> ZeroMQ has an option where the subscribe socket only keeps the last 
> message. I was wondering if there is a way to specify that.
> Something like the following:
>
> using ZMQ
> ctx = Context()
> s = Socket(ctx, SUB)
> ZMQ.subscribe(s)
> ZMQ.set_subscribe(ZMQ.CONFLATE, 1)   # ERROR: LoadError: UndefVarError: 
> CONFLATE not defined
> ZMQ.connect(s, "tcp://127.0.0.1:5001")
>
>
> while true
>  msg = bytestring(ZMQ.recv(s))
>  println(msg)
> end
>
>
>
> The C++ analog would go something like this:
>   zmq::context_t context (1);
>   zmq::socket_t subscriber (context, ZMQ_SUB);
>
>   int conflate = 1;
>
>   *subscriber**.setsockopt(ZMQ_CONFLATE, , sizeof(conflate) );   
> // need this in julia*
>   subscriber.connect("tcp://localhost:5556");
>   subscriber.setsockopt(ZMQ_SUBSCRIBE, "", 0); 
>
>
> More generally, how are socket options specified in Julia?
> http://api.zeromq.org/4-0:zmq-setsockopt
>
> Thanks.
>


ZMQ_sockets.jl
Description: Binary data