[julia-users] Re: Julia ccall windows

[Tony Kelman]

What do you mean by "doesn't find those libraries" ? Note that you can't 
directly use ccall to call into C++ libraries unless they have an `extern 
"C"` interface. You could try using Cxx.jl if there's not easy way to 
create `extern "C"` entry points, but it's easier to start with plain C at 
first.


On Friday, July 8, 2016 at 4:16:03 PM UTC-7, Karli Kund wrote:
>
>  
>
> I'm new with Julia one(many) problem(s). I'm using c++ libraries 
> (.dll/.lib) to connect my c++ program to company's program (it connects to 
> home 127.0.0.1 through 5111 port by calling function "connect(port,in, out) 
> and it works). Now I have Julia code that has to the same thing. My 
> question is, how can I use this libraries? I try to use ccall function, but 
> it doesn't find those libraries. I haven't found any info on windows how to 
> set different libraries for ccall.
>
> Other option is I translate everything to c++, but...no. Maybe second 
> option is that I open the libraries and re-write them to Julia.
>
> I'm using windows 7 and visual studio for c++. For Julia I use Atom with 
> Juno package. 
>

[julia-users] Re: Symbolic differentiation similar to TensorFlow / Theano

[Chris Rackauckas]

Have you checked out using the wrappers for 
TensorFlow, https://github.com/benmoran/TensorFlow.jl ? Or directly using 
PyCall?

On Friday, July 8, 2016 at 5:02:55 PM UTC-7, Andrei Zh wrote:
>
> In Python, libraries like TensorFlow or Theano provide possibility to 
> perform automatic differentiation over their computational graphs. E.g. in 
> TensorFlow (example from SO 
> 
> ): 
>
> data = tf.placeholder(tf.float32)
> var = tf.Variable(...)  
> loss = some_function_of(var, data)
>
> var_grad = tf.gradients(loss, [var])[0]
>
> What is the closest thing in Julia at the moment? 
>
> Here's what I've checked so far: 
>
>  * ForwardDiff.jl  - it 
> computes derivatives using forward mode automatic differentiation (AD). 
> Although AD has particular advantages, I found this package quite slow. 
> E.g. for a vector of 1000 elements gradient takes ~100x times longer then 
> the function itself. Another potential issues is that ForwardDiff.jl 
> doesn't output symbolic version of gradient and thus is hardly usable for 
> computation on GPU, for example. 
>  * *Calculus.jl*  - among 
> other things, this package provided symbolic differentiation. However, it 
> seems to consider all symbols to be numbers and doesn't support matrices or 
> vectors. 
>
> I have pretty shallow knowledge of both these packages, so please correct 
> me if I'm wrong somewhere in my conclusions. And if not, is there any other 
> package or project that I should consider? 
>

[julia-users] IJCAI

[Tom Breloff]

Will any julians be in NYC for IJCAI or AGI-16 this week (and next)?

Re: [julia-users] Recompile package cloned from github?

[Chris Rackauckas]

Yeah, you need to restart Julia to recompile. If you're in Juno, just co 
Ctrl+j then Ctrl+k, and then run your script (you can also use Ctrl+j then 
Ctrl+c to clear the console). I find this easier than restarting the REPL.

On Friday, July 8, 2016 at 4:23:44 PM UTC-7, Yichao Yu wrote:
>
> On Thu, Jul 7, 2016 at 10:56 AM, Shyam Upadhyay  > wrote: 
> > I found a package on github that I installed as follows into Julia, 
> > 
> > Pkg.clone("https://github.com/sbos/AdaGram.jl.git;) 
> > Pkg.build("AdaGram") 
> > 
> > 
> > Now I wanted to modify the package and see those changes. So, I cloned 
> the 
> > repo and made my changes in the code. I ran Pkg.build("AdaGram") again, 
> but 
> > my changes did not take effect. 
>
> Restart julia? 
>
> > What am I doing wrong? I am totally new to Julia so it will be a great 
> help. 
>

Re: [julia-users] Ambiguity error when dispatching on Union types

[Darwin Darakananda]

Is there a recommended way to getting around that?  The example above had a 
union of only two types, but in the actual code I'm working on there are a 
couple more.  Would I have to copying the code over and over with just 
small changes to the type signature? I guess you could use a macro to 
splice the types in.

On Friday, July 8, 2016 at 7:58:02 PM UTC-7, Yichao Yu wrote:
>
> On Fri, Jul 8, 2016 at 10:32 PM, Darwin Darakananda 
>  wrote: 
> > Hi everyone, 
> > 
> > I have some code where multiple types share the same implementation of a 
> > method, for example: 
> > 
> > abstract MyType 
> > 
> > 
> > type A <: MyType end 
> > type B <: MyType end 
> > 
> > 
> > f(target::MyType, source::MyType) = "fallback" 
> > 
> > 
> > f(target::Int,source::A) = "from A" 
> > f(target::MyType, source::A) = "from A" 
> > 
> > a = A() 
> > b = B() 
> > 
> > f(b, b) # fallback 
> > f(b, a) # from A 
> > f(a, a) # from A 
> > 
> > I was hoping that I could replace the "from A" function using a union 
> type, 
> > but I'm running into ambiguity errors: 
> > 
> > f(target::Union{Int, MyType}, source::A) = "from A" 
> > 
> > f(b, b) # fallback 
> > f(b, a) # Ambiguity error 
> > f(a, a) # Ambiguity error 
> > 
> > Is this an expected behavior? 
>
> Yes. 
>
> > I thought that (::Union{Int, MyType}, ::A) 
> > would be a more specific match to (::B, ::A) than (::MyType, ::MyType). 
>
> There's basically nothing as a "more specific match". The two methods 
> are ambiguous and anything in their intersection cannot be dispatched 
> to either of them. 
>
> > 
> > Any ideas/suggestions? 
> > 
> > Thanks, 
> > 
> > Darwin 
>

Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

[Isaiah Norton]

Libuv mostly abstracts away the differences, but named pipes are released
automatically when the last handle closes, whereas named sockets are
associated with an inode and must be checked/cleaned-up manually.

On Thu, Jul 7, 2016 at 10:24 PM, David Anthoff  wrote:

> Yes, seems to work.
>
>
>
> You need to use a different naming scheme on Windows, namely ``
> .\\pipe\\yourname``, but then one can just use the normal julia
> socket functions for it. In particular, if one process listens on such a
> named pipe, calling ``listen`` from another process with the same name will
> give an error.
>
>
>
> Actually, are there really different semantics? I haven’t come across any
> when I use such a named pipe on Windows for inter-process communication via
> the julia socket API…
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Isaiah Norton
> *Sent:* Thursday, July 7, 2016 5:34 PM
>
> *To:* julia-users@googlegroups.com
> *Subject:* Re: [julia-users] Pkg "threadsafe" or interprocess mutex
> package
>
>
>
> Does that work on Windows? I briefly tried earlier and it didn't seem to
> work. IIUC Windows doesn't support Unix-style named sockets. (it does have
> named pipes, but the semantics are a bit different)
>
>
>
> On Thu, Jul 7, 2016 at 1:07 PM, David Anthoff 
> wrote:
>
> Ah, I had actually come up with the same solution that Amit suggested in
> #7176 and am using a named socket as a lock, that seems to work for now.
>
>
>
> I’m also running into another race condition with respect to precompile, I
> opened a new issue for that:
>
> https://github.com/JuliaLang/julia/issues/17320
>
>
>
> Cheers,
>
> David
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Isaiah Norton
> *Sent:* Thursday, July 7, 2016 6:52 AM
> *To:* julia-users@googlegroups.com
> *Subject:* Re: [julia-users] Pkg "threadsafe" or interprocess mutex
> package
>
>
>
> See
>
> https://github.com/JuliaLang/julia/issues/5622 and
>
> https://github.com/JuliaLang/julia/issues/7176
>
>
>
> If you are on Windows, LockFileEx is reliable and you could ccall it
> yourself. Probably simpler to handle the problem at a higher level for now
> though (i.e. run one script that checks installation *before* launching
> your analysis jobs).
>
>
>
>
>
> On Wed, Jul 6, 2016 at 5:09 PM, David Anthoff 
> wrote:
>
> Hi,
>
>
>
> I have a script that is using some packages. The script is set up such
> that if the package it is trying to use is not installed, it will do a
> ``Pkg.add`` to add the package before ``using`` it.
>
>
>
> This script is triggered by a third process, and it might be triggered
> multiple times simultaneously, i.e. multiple instances of julia might run
> the same script at the same time. Therefore the second julia instance might
> issue the same ``Pkg.add`` command as the first instance, while the first
> instance is not done with the ``Pkg.add`` yet.
>
>
>
> I assume the package manager per se is not set up to handle that situation
> gracefully?
>
>
>
> If not, is there some package that allows me to have something like a
> mutex/lock between my julia processes, so that I can guard the code section
> that fiddles with packages and make sure only one julia instance at a time
> runs that code?
>
>
>
> Thanks,
>
> David
>
>
>
> --
>
> David Anthoff
>
> University of California, Berkeley
>
>
>
> http://www.david-anthoff.com
>
>
>
>
>
>
>

Re: [julia-users] Ambiguity error when dispatching on Union types

[Yichao Yu]

On Fri, Jul 8, 2016 at 10:32 PM, Darwin Darakananda
 wrote:
> Hi everyone,
>
> I have some code where multiple types share the same implementation of a
> method, for example:
>
> abstract MyType
>
>
> type A <: MyType end
> type B <: MyType end
>
>
> f(target::MyType, source::MyType) = "fallback"
>
>
> f(target::Int,source::A) = "from A"
> f(target::MyType, source::A) = "from A"
>
> a = A()
> b = B()
>
> f(b, b) # fallback
> f(b, a) # from A
> f(a, a) # from A
>
> I was hoping that I could replace the "from A" function using a union type,
> but I'm running into ambiguity errors:
>
> f(target::Union{Int, MyType}, source::A) = "from A"
>
> f(b, b) # fallback
> f(b, a) # Ambiguity error
> f(a, a) # Ambiguity error
>
> Is this an expected behavior?

Yes.

> I thought that (::Union{Int, MyType}, ::A)
> would be a more specific match to (::B, ::A) than (::MyType, ::MyType).

There's basically nothing as a "more specific match". The two methods
are ambiguous and anything in their intersection cannot be dispatched
to either of them.

>
> Any ideas/suggestions?
>
> Thanks,
>
> Darwin

[julia-users] Ambiguity error when dispatching on Union types

[Darwin Darakananda]

Hi everyone,

I have some code where multiple types share the same implementation of a 
method, for example:

abstract MyType


type A <: MyType end
type B <: MyType end


f(target::MyType, source::MyType) = "fallback"


f(target::Int,source::A) = "from A"
f(target::MyType, source::A) = "from A"

a = A()
b = B()

f(b, b) # fallback
f(b, a) # from A
f(a, a) # from A

I was hoping that I could replace the "from A" function using a union type, 
but I'm running into ambiguity errors:

f(target::Union{Int, MyType}, source::A) = "from A"

f(b, b) # fallback
f(b, a) # Ambiguity error
f(a, a) # Ambiguity error

Is this an expected behavior?  I thought that (::Union{Int, MyType}, 
::A) would be a more specific match to (::B, ::A) than (::MyType, ::MyType).

Any ideas/suggestions?

Thanks,

Darwin

[julia-users] Symbolic differentiation similar to TensorFlow / Theano

[Andrei Zh]

In Python, libraries like TensorFlow or Theano provide possibility to 
perform automatic differentiation over their computational graphs. E.g. in 
TensorFlow (example from SO 

): 

data = tf.placeholder(tf.float32)
var = tf.Variable(...)  
loss = some_function_of(var, data)

var_grad = tf.gradients(loss, [var])[0]

What is the closest thing in Julia at the moment? 

Here's what I've checked so far: 

 * ForwardDiff.jl  - it 
computes derivatives using forward mode automatic differentiation (AD). 
Although AD has particular advantages, I found this package quite slow. 
E.g. for a vector of 1000 elements gradient takes ~100x times longer then 
the function itself. Another potential issues is that ForwardDiff.jl 
doesn't output symbolic version of gradient and thus is hardly usable for 
computation on GPU, for example. 
 * *Calculus.jl*  - among 
other things, this package provided symbolic differentiation. However, it 
seems to consider all symbols to be numbers and doesn't support matrices or 
vectors. 

I have pretty shallow knowledge of both these packages, so please correct 
me if I'm wrong somewhere in my conclusions. And if not, is there any other 
package or project that I should consider? 

[julia-users] Re: Julia version of Matplotlib griddata?

[Kaj Wiik]

Yes, I tried that but for some reason, couldn't get natgrid recognized by 
matplotlib... One way would try to call natgrid library (libncarg) 
directly...

Thanks,
Kaj

On Saturday, July 9, 2016 at 2:00:29 AM UTC+3, Steven G. Johnson wrote:
>
> (You can always call the Matplotlib function from Julia via PyCall.)
>

Re: [julia-users] Recompile package cloned from github?

[Yichao Yu]

On Thu, Jul 7, 2016 at 10:56 AM, Shyam Upadhyay  wrote:
> I found a package on github that I installed as follows into Julia,
>
> Pkg.clone("https://github.com/sbos/AdaGram.jl.git;)
> Pkg.build("AdaGram")
>
>
> Now I wanted to modify the package and see those changes. So, I cloned the
> repo and made my changes in the code. I ran Pkg.build("AdaGram") again, but
> my changes did not take effect.

Restart julia?

> What am I doing wrong? I am totally new to Julia so it will be a great help.

[julia-users] Julia ccall windows

[Karli Kund]

 

I'm new with Julia one(many) problem(s). I'm using c++ libraries 
(.dll/.lib) to connect my c++ program to company's program (it connects to 
home 127.0.0.1 through 5111 port by calling function "connect(port,in, out) 
and it works). Now I have Julia code that has to the same thing. My 
question is, how can I use this libraries? I try to use ccall function, but 
it doesn't find those libraries. I haven't found any info on windows how to 
set different libraries for ccall.

Other option is I translate everything to c++, but...no. Maybe second 
option is that I open the libraries and re-write them to Julia.

I'm using windows 7 and visual studio for c++. For Julia I use Atom with 
Juno package. 

[julia-users] Enter permanently on a REPL mode

[Iagoba Apellaniz]

I would prefer to enter permanently on a REPL mode like `shell`. See 
RCall.jl packages behavior. Once you are on R you have to hit `backspace` 
to get back to `julia>` which of course should be the default RELP mode. 

*julia*>[;]


*shell*> ls

DesktopDocuments  Downloads 

JuliaProjects  Music  Pictures

*shell*> cd JuliaProjects

...

*shell*> [backspace]


*julia*> 


I have seen also some of issues about REPL modes.

I don't know about the implementation of this but... for accessing any 
available REPL

*ju**lia*> [?]

 

*help?*>

[;] shell [0] julia [1] python [2] R [3]    <- This would be a kind of 
menu to chose from. That it disappears whenever some action is performed. 


Alternatively, still special characters instead of numbers could be 
displayed if that's the trendy option.
 

*help?*>
[;] shell [<-] julia [*] python [$] R [?] help  <- I invented the symbols 
used

 

As more packages are installed more REPLs can be available tho show to the 
user when help mode is chosen.
 

 

[julia-users] Recompile package cloned from github?

[Shyam Upadhyay]

I found a package  on github that I 
installed as follows into Julia,

Pkg.clone("https://github.com/sbos/AdaGram.jl.git;)
Pkg.build("AdaGram")


Now I wanted to modify the package and see those changes. So, I cloned the 
repo and made my changes in the code. I ran Pkg.build("AdaGram") again, but 
my changes did not take effect. 
What am I doing wrong? I am totally new to Julia so it will be a great 
help. 

[julia-users] Re: Julia version of Matplotlib griddata?

[Steven G. Johnson]

(You can always call the Matplotlib function from Julia via PyCall.)

[julia-users] Julia version of Matplotlib griddata?

[Kaj Wiik]

Is there a Julia version of irregularly spaced data gridding that does
zi = griddata(x,y,z,xi,yi), i.e. all arguments are 1d vectors? It seems 
that Julia interp and contour packages require x, y, z[x,y].

https://scipy.github.io/old-wiki/pages/Cookbook/Matplotlib/Gridding_irregularly_spaced_data.html

Thanks,
Kaj

[julia-users] string interpolation for memory object name

[Min-Woong Sohn]

I am trying to run logistic regressions on a bunch of dependent variables 
like so:

using GLM

outcomes = [:mort30d, :readmit, :reoper, :sar]

for i in 1:length(outcomes)
logit_$(outcomes[i])_unadjusted = glm($(outcomes[i]) ~ race, puf, 
Binomial(),LogitLink())
dump(coef(logit_$(outcomes[i])_unadjusted))
end

Here I want to run the logistic regression four times, once for each 
outcome, and save the return values into four different memory objects:

logit_mort30d_unadjusted
logit_readmit_unadjusted
etc

The glm... part works fine with the interpolation, $(outcomes[i]), but I 
cannot create the memory objects in this way. Is there any way I can use 
some method of string interpolation to this end?


 

Re: [julia-users] Release memory GC

[Joaquim Masset Lacombe Dias Garcia]

So the recommendation for clearing memory is calling GC after some function 
so that no references exist anymore?

Em quinta-feira, 7 de julho de 2016 17:17:03 UTC-3, Yichao Yu escreveu:
>
> On Thu, Jul 7, 2016 at 4:10 PM, Thuener Silva  > wrote: 
> > I have a code that uses a lot of memory and I'm trying to release some 
> of it 
> > but without success. I made up an examples to illustrate the problem: 
> > 
> > function memuse() 
> >   return string(round(Int,parse(Int,readall(`ps -p 29563 -o 
> > rss=`))/1024),"M") 
> > end 
> > 
> > function test() 
> >   for i = 1:2 
> >println("\ni=$i") 
> >a = rand(1,1) 
> >println("Created a $(memuse())") 
> >a = 0 
> >gc() 
> >println("Release a $(memuse())\n") 
> > 
> >b = rand(1,1) 
> >println("Created b $(memuse())") 
> >b = 0 
> >gc() 
> >println("Release b $(memuse())\n") 
> > 
> >c = rand(1,1) 
> >println("Created c $(memuse())") 
> >c =0 
> >gc() 
> >println("Release c $(memuse())\n") 
> >   end 
> > end 
> > 
> > test() 
> > 
> > 
> > Output: 
> > 
> > i=1 
> > Created a 918M 
> > Release a 918M 
> > 
> > Created b 1681M 
> > Release b 1681M 
> > 
> > Created c 2444M 
> > Release c 2444M 
> > 
> > 
> > i=2 
> > Created a 3207M 
> > Release a 2444M 
> > 
> > Created b 3207M 
> > Release b 2444M 
> > 
> > Created c 3207M 
> > Release c 2444M 
> > 
> > 
> > 
> > 
> > This code only needs 918M to run but uses 3207M. 
> > 
> > Questions: 
> > Why gc() is not releasing unused memory? 
> > There is some way to force garbage collector to release? 
> > Why garbage collector releases some memory only on the second iteration? 
>
> There's no guarantee that the a/b/c = 0 clears the reference. 
>
> > 
> > 
> > Thanks, 
> > Thuener 
> > 
>

[julia-users] Re: caching the pivot ordering for a sparse cholesky factorization?

[Patrick Belliveau]

Hi,
  I'm not sure whether it's possible to access the reordering using the 
builtin julia interface to the suitesparse library. If you have access to 
the Pardiso solver (or MKL, which includes a version of Pardiso) you can do 
so using the Pardiso.jl package. At some point there was an interface to 
the MUMPS package that was aiming to expose the full MUMPS API (thus 
allowing access to reordering/analysis phase of the solver) but I couldn't 
find it using a quick google search. The two MUMPS julia interfaces I know 
of off hand (https://github.com/JuliaSparse/MUMPS.jl and 
https://github.com/JuliaSmoothOptimizers/MUMPS.jl) don't allow you to save 
the results of the analysis phase but if you know a little Fortran (for the 
JuliaSparse interface) or C (for the JuliaSmoothOptimizers version) you 
could add that functionality and make a pr.

Also, fwiw, in my experience with both MUMPS and Pardiso on moderate 
problem sizes (10^5, maybe 5 X 10^5 unknowns) the analysis phase is quite 
quick and for some reason there's significant overhead associated with 
calling the analysis and factorization phases of the solvers separately. 
Enough overhead that it's been faster to make a new combined 
analyze/factorize call for each new matrix rather than performing the 
analysis once and then just calling factorize a bunch of times. That 
experience comes from symmetric indefinite matrices. 

Patrick

On Friday, July 8, 2016 at 1:40:45 AM UTC-7, Gabriel Goh wrote:
>
> Hey,
>
> I have a sequence of sparse matrix factorizations I need to do, each one a 
> different matrix but with the same sparsity structure. Is there a way I can 
> save the AMD (or any other) ordering that sparsesuite returns, it does not 
> need to be recomputed each time?
>
> Thanks a lot for the help!
>
> Gabe
>

Re: [julia-users] When Julia v1.0 will be released?

[Tim Holy]

On Friday, July 8, 2016 6:43:36 PM CDT Daniel Carrera wrote:
> For that matter, will there be upper case functions for every
> concrete type? ... I'm just curious. I wouldn't actually use that feature.

Yes, it's just the constructor. In most cases you don't have to define them 
manually, they are created automatically.

--Tim

Re: [julia-users] When Julia v1.0 will be released?

[Daniel Carrera]

On 8 July 2016 at 17:20, Tim Holy  wrote:

> The string unification is already in julia-0.5.
>


I don't think I know what "string unification" means, but I guess part of
it is that Base.String will become ok to use again?




> There are functions called String(), Int(), and Float64(). In some cases
> there
> are lowercase variants, and these often "do more" (e.g., `float` will
> parse a
> string and return an AbstractFloat). The uppercase versions are the
> minimalist
> type-conversion forms.
>
> Int isn't an alias for Int64: it's an alias for either Int32 or Int64,
> depending on whether you have a 32-bit or 64-bit computer. There's no
> analogous issue for Float32/Float64 (these are not CPU-dependent types),
> which
> is why Float won't become an alias for one of them.
>


Great. And thanks for explaining. Will there also be Int32() and Int64()
then? For that matter, will there be upper case functions for every
concrete type? ... I'm just curious. I wouldn't actually use that feature.


So I think your list is as done as it's going to get :-).
>
> --Tim
>

Ok. I'm happy with String(), Int(), and Float64(). They are consistent
which is the most important thing.


Cheers,
Daniel.

Re: [julia-users] Re: testing intrument Automation

[Yared Melese]

Thanks for your quick response 

I have different commands that I want to control instruments via GPIB 
commands, It will be okay if I can import NI visa and build different logic 
in automating instruments. 

Here is a simple Python command I send to setup spectrum analyzer. I am a 
beginner and I would like to learn and stick with one language and Julia 
seems to be interesting to me

import visa
import numpy as np
class MXA_ACP:
def __init__(self,gpib_address="GPIB0::18",hw = 1, route = "A"):

rm = visa.ResourceManager()
self.handle = rm.open_resource('{}::INSTR'.format(gpib_address))
#self.handle= 
visa.instrument('TCPIP0::{}::INSTR'.format(TCPIP_Address))

  
def ACP_set(self,BW,freq,numCarr,spacing):
   self.handle.write('system:preset')
   self.handle.write('CONFigure:ACPower')
   self.handle.write('CONFigure:ACPower:NDEFault')
   self.handle.write('INST:SEL LTE')
   # set standard based on BW 
   if BW ==5:
  self.handle.write('SENSe:RADio:STANdard:PRESet B5M')
   elif BW == 10:
 self.handle.write('SENSe:RADio:STANdard:PRESet B10M')
   elif BW == 20: 
self.handle.write('SENSe:RADio:STANdard:PRESet B20M')

   self.handle.write('ACP:carr:coun {}'.format(numCarr)) #set number of 
carriers 
   self.handle.write('ACP:carrier:RCFR {} MHz'.format(freq))#set Freq
   self.handle.write('ACP:carr1:list:width {} MHz'.format(spacing)) # 
set carrier spacing 
   self.handle.write('Corr:nois:flo ON') # noise floor extention
   self.handle.write(':power:RF:range:optimize immediate')
   self.handle.write('ACP:aver:coun 50') # averaging 
   self.handle.write('*WAI')   # wait for averaging to finish   
   acp = np.fromstring(self.handle.ask('read:ACP?'), sep=',')
   acp_3rd_upper = acp[4]
   acp_3rd_lower= acp[6]
   acp_5th_upper= acp[8]
   acp_5th_lower= acp[10]
   print acp_3rd_upper
   print acp_3rd_lower
   print acp_5th_upper
   print acp_5th_lower
   return  acp_3rd_upper, acp_3rd_lower,acp_5th_upper

On Monday, July 4, 2016 at 1:29:50 PM UTC-5, Keno Fischer wrote:

> You may want to look at Instruments.jl: 
> https://github.com/BBN-Q/Instruments.jl 
>
> On Mon, Jul 4, 2016 at 2:00 PM, Alex Mellnik  > wrote: 
> > Hi Yared, 
> > 
> > This should be possible, but it could be less than ideal in some 
> instances. 
> > What exactly are you hoping to automate? 
> > 
> > Like Isaiah, I don't know of a specific GPIB library for Julia, but if 
> you 
> > are using the NI drivers you can call them directly from Julia (see 
> > 
> http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code/ 
> > and there's a bit of specific information about the GPIB libraries here: 
> > 
> http://alex.mellnik.net/application-notes/application-notesusing-nis-gpib-drivers-in-qt/).
>  
>
> > 
> > -A 
> > 
> > 
> > On Saturday, July 2, 2016 at 5:39:07 PM UTC-7, Yared Melese wrote: 
> >> 
> >> Can Julia be used as instrument test Automation? Send commands via GPIB 
> to 
> >> different instruments 
> >> 
> >> If so is there Visa library for it? 
> >> 
> >> Thanks 
> >> Yared 
>

Re: [julia-users] how to tell if a jld file contains a dataset?

[Davide Lasagna]

Thanks!

On Friday, July 8, 2016 at 4:21:22 PM UTC+1, Tim Holy wrote:
>
> `has` or `exists` 
>
> --Tim 
>
> On Friday, July 8, 2016 8:01:40 AM CDT Davide Lasagna wrote: 
> > I have read the available documentation but I cannot seem to get it. 
> > 
> > How do I test whether an existing .jld file, opened  as 
> > 
> > jldopen(filename, "r") do handle 
> > # test whether handle contains the dataset "foo" 
> > end 
> > 
> > contains a dataset, given its name as a string, e.g. "foo"? 
> > 
> > Thanks! 
> > 
> > Davide 
>
>
>

Re: [julia-users] how to tell if a jld file contains a dataset?

[Tim Holy]

`has` or `exists`

--Tim

On Friday, July 8, 2016 8:01:40 AM CDT Davide Lasagna wrote:
> I have read the available documentation but I cannot seem to get it.
> 
> How do I test whether an existing .jld file, opened  as
> 
> jldopen(filename, "r") do handle
> # test whether handle contains the dataset "foo"
> end
> 
> contains a dataset, given its name as a string, e.g. "foo"?
> 
> Thanks!
> 
> Davide

Re: [julia-users] When Julia v1.0 will be released?

[Tim Holy]

The string unification is already in julia-0.5.

There are functions called String(), Int(), and Float64(). In some cases there 
are lowercase variants, and these often "do more" (e.g., `float` will parse a 
string and return an AbstractFloat). The uppercase versions are the minimalist 
type-conversion forms.

Int isn't an alias for Int64: it's an alias for either Int32 or Int64, 
depending on whether you have a 32-bit or 64-bit computer. There's no 
analogous issue for Float32/Float64 (these are not CPU-dependent types), which 
is why Float won't become an alias for one of them.

So I think your list is as done as it's going to get :-).

--Tim

On Friday, July 8, 2016 7:02:19 AM CDT Daniel Carrera wrote:
> This is just me, but I prefer to wait a bit longer than to get mistakes
> frozen into the language. One bit that I care about is the names of some
> types and functions. For example, right now we have
> 
> - Base.String
> - Base.ASCIIString
> - Base.UTF8String
> - Base.AbstractString
> 
> So, I want to use "String" in my code but right now it's deprecated, and
> the others look horrible. My understanding is that this is still in flux
> and in the future there will be a sane "String" type that people can
> default to without getting errors... I would very much like to see that
> implemented and working before Julia is frozen.
> 
> I also think that the type-related functions in Julia are inconsistent. I
> think there should be functions called string(), int(), and float() that
> return a String, Int64, and Float64. I don't think that the Julia
> developers agree with me.
> 
> Oh, and I think that Float should be an alias for Float64 just like Int is
> an alias for Int64.
> 
> So... there are some inconsistencies in Julia and I prefer to wait in the
> hope that some of these might be ironed out before they become hard-coded
> into the language.
> 
> Cheers,
> Daniel.
> 
> On Thursday, 7 July 2016 16:47:28 UTC+2, Isaiah wrote:
> > I knew that.
> > 
> > 
> > The goal is 2017, if development community considers it to be ready.
> > 
> > I don't mean to be too glib, but I fail to see how any answer is
> > particularly actionable; it is certainly not binding.
> > 
> > On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote:
> >>> When it is ready.
> >>> 
> >>> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi  wrote:
>  I really like Julia (I am using it for my publications & thesis), but I
>  noticed that the versions are not really backward compatible. I am
>  still ok
>  with that, but  many other people are waiting for the mature, stable
>  version  (1.0) to start using Julia. So, when Julia v1.0 will be
>  released?

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

I've now added a chat for Genie.jl :) 

vineri, 8 iulie 2016, 17:03:35 UTC+2, Adrian Salceanu a scris:
>
> Thanks Eric! 
>
> Yeah, the Rust package is pretty cool, I've stumbled onto it myself 
> earlier :-O
>
> Genie.jl, thanks! It's still early but I'm super hyped by the way it comes 
> out! 
>
> Yeah, I'm on Gitter, on JuliaLang and JuliaLangEs. 
>
> A
>
> vineri, 8 iulie 2016, 16:49:03 UTC+2, Eric Forgy a scris:
>>
>> Btw, Genie.jl also looks super cool +1. Are you on Gitter or?
>>
>> On Friday, July 8, 2016 at 10:37:59 PM UTC+8, Eric Forgy wrote:
>>>
>>> This looks pretty awesome. Thanks!
>>>
>>> I found a bunch of awesome looking new packages too with this, e.g. 
>>> Rust.jl :heart_eyes:
>>>
>>

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

Thanks Eric! 

Yeah, the Rust package is pretty cool, I've stumbled onto it myself earlier 
:-O

Genie.jl, thanks! It's still early but I'm super hyped by the way it comes 
out! 

Yeah, I'm on Gitter, on JuliaLang and JuliaLangEs. 

A

vineri, 8 iulie 2016, 16:49:03 UTC+2, Eric Forgy a scris:
>
> Btw, Genie.jl also looks super cool +1. Are you on Gitter or?
>
> On Friday, July 8, 2016 at 10:37:59 PM UTC+8, Eric Forgy wrote:
>>
>> This looks pretty awesome. Thanks!
>>
>> I found a bunch of awesome looking new packages too with this, e.g. 
>> Rust.jl :heart_eyes:
>>
>

[julia-users] how to tell if a jld file contains a dataset?

[Davide Lasagna]

I have read the available documentation but I cannot seem to get it.

How do I test whether an existing .jld file, opened  as

jldopen(filename, "r") do handle
# test whether handle contains the dataset "foo"
end

contains a dataset, given its name as a string, e.g. "foo"?

Thanks!

Davide

[julia-users] Re: ANN: New Julia Packages website

[Eric Forgy]

Btw, Genie.jl also looks super cool +1. Are you on Gitter or?

On Friday, July 8, 2016 at 10:37:59 PM UTC+8, Eric Forgy wrote:
>
> This looks pretty awesome. Thanks!
>
> I found a bunch of awesome looking new packages too with this, e.g. 
> Rust.jl :heart_eyes:
>

[julia-users] Re: ANN: New Julia Packages website

[Eric Forgy]

This looks pretty awesome. Thanks!

I found a bunch of awesome looking new packages too with this, e.g. Rust.jl 
:heart_eyes:

[julia-users] Re: When Julia v1.0 will be released?

[Sisyphuss]

You should really double (if not triple) the time when estimating. This is 
a rule of thumb.

The technologies keep moving, and it is hard to tell whether Julia1.0 
milestone will include new features.

Even when Julia1.0 comes out, there are still issues on ecosystem and the 
documentation. 

BTW, the GSoC overlaps with the release of the new version. Won't it cause 
any problem?

Re: [julia-users] When Julia v1.0 will be released?

[Daniel Carrera]

On Friday, 8 July 2016 16:01:25 UTC+2, Scott Jones wrote:
>
> We are looking forward to being able to use v0.5, with fast anonymous 
> functions, cleaner array syntax, Gallium debugger and C++, and many many 
> other improvements
>

Cleaner array syntax? Tell me more?

 

> (although the string changes mean we need to be careful not to use Julia's 
> base String type - currently we use ASCIIString/UTF16String for performance 
> reasons), but we aren't at all dependent on it (or v1.0, for that matter).
>

Yeah.

Re: [julia-users] When Julia v1.0 will be released?

[Scott Jones]

It used to be that [[1,2],[3,4]] would try to concatenate the two vectors 
into [1,2,3,4], which was inconsistent with Vector{Int}[[1,2],[3,4]] (which 
returns a vector of vectors).
That syntax was deprecated in v0.4.x, and in v0.5 now means the same thing 
(and the same as in any other language I've dealt with, a vector of 
vectors).

That makes life a lot easier for people coming from JavaScript, Python, etc.

There is now also the possibility of using arbitrarily based arrays (and 
even "permuted index" arrays, which means you can handle row-major arrays 
now much easier), thanks to Tim Holy's wonderful (as always) contributions.
Great stuff, that will cut down a lot of complaints about only having 
1-based, column major arrays in Julia.

On Friday, July 8, 2016 at 10:10:52 AM UTC-4, Daniel Carrera wrote:
>
>
> On Friday, 8 July 2016 16:01:25 UTC+2, Scott Jones wrote:
>>
>> We are looking forward to being able to use v0.5, with fast anonymous 
>> functions, cleaner array syntax, Gallium debugger and C++, and many many 
>> other improvements
>>
>
> Cleaner array syntax? Tell me more?
>
>  
>
>> (although the string changes mean we need to be careful not to use 
>> Julia's base String type - currently we use ASCIIString/UTF16String for 
>> performance reasons), but we aren't at all dependent on it (or v1.0, for 
>> that matter).
>>
>
> Yeah.
>
>

Re: [julia-users] When Julia v1.0 will be released?

[Daniel Carrera]

This is just me, but I prefer to wait a bit longer than to get mistakes 
frozen into the language. One bit that I care about is the names of some 
types and functions. For example, right now we have

- Base.String
- Base.ASCIIString
- Base.UTF8String
- Base.AbstractString

So, I want to use "String" in my code but right now it's deprecated, and 
the others look horrible. My understanding is that this is still in flux 
and in the future there will be a sane "String" type that people can 
default to without getting errors... I would very much like to see that 
implemented and working before Julia is frozen.

I also think that the type-related functions in Julia are inconsistent. I 
think there should be functions called string(), int(), and float() that 
return a String, Int64, and Float64. I don't think that the Julia 
developers agree with me.

Oh, and I think that Float should be an alias for Float64 just like Int is 
an alias for Int64.

So... there are some inconsistencies in Julia and I prefer to wait in the 
hope that some of these might be ironed out before they become hard-coded 
into the language.

Cheers,
Daniel.



On Thursday, 7 July 2016 16:47:28 UTC+2, Isaiah wrote:
>
> I knew that.
>>
>
> The goal is 2017, if development community considers it to be ready.
>
> I don't mean to be too glib, but I fail to see how any answer is 
> particularly actionable; it is certainly not binding.
>  
>
> On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote:
>>>
>>> When it is ready.
>>>
>>> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi  wrote:
>>>
 I really like Julia (I am using it for my publications & thesis), but I 
 noticed that the versions are not really backward compatible. I am still 
 ok 
 with that, but  many other people are waiting for the mature, stable 
 version  (1.0) to start using Julia. So, when Julia v1.0 will be 
 released?

>>>
>>>
>
>

Re: [julia-users] When Julia v1.0 will be released?

[Scott Jones]

Actually, the blog post from StaffJoy (
https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341#.35atllel3)
 
never said that it turned out to be a mistake, in the conclusion they said:

> The Julia language helped to create Staffjoy and turn it into a business, 
> and for that I am grateful

It seemed clear to me that their reason for moving away from Julia was more 
an issue of Julia not being ready *yet* for the scaling and reliability 
they needed to provide for their business. 

People (like the company I consult for) who are using Julia in industry are 
well aware both of the pros and cons of using Julia in it's current state, 
we started a good deal later than StaffJoy, and things have been stable 
enough for us with v0.4.x that the pros have far outweighed the cons up til 
now (we had needed a number of critical fixes for string performance / 
correctness, but were able to get those in just before v0.4 was frozen).
We are looking forward to being able to use v0.5, with fast anonymous 
functions, cleaner array syntax, Gallium debugger and C++, and many many 
other improvements (although the string changes mean we need to be careful 
not to use Julia's base String type - currently we use 
ASCIIString/UTF16String for performance reasons), but we aren't at all 
dependent on it (or v1.0, for that matter).

Julia can be great for a small startup, in the case where the features in 
the current release version are enough for the application (and where you 
wouldn't be able to simply use some already existing library available in 
some other language),
since you can quickly prototype things, and then turn those prototypes into 
production code.
In our particular case, if we had continued with our original plan of 
developing in Python, C++, and some C, I really don't think we'd have 
things nearly so far along.
 

On Thursday, July 7, 2016 at 11:23:34 AM UTC-4, John Myles White wrote:
>
> For industry, it probably means something similar.
>
>
> I really hope people in industry won't act on this date, as it is not 
> nearly firm enough to bet a business on. We already have people writing 
> blog posts about how using Julia for their startup turned out to be a 
> mistake; we really don't need to encourage a new group of people to bet on 
> something that's not 100% guaranteed.
>
> Or to use industry language: that date isn't an SLA.
>
>  -- John
>
> On Thursday, July 7, 2016 at 7:55:34 AM UTC-7, Chris Rackauckas wrote:
>>
>> This information is hugely beneficial in science/mathematics, especially 
>> for a PhD. It means that if you start a project in Julia now, although 
>> there will be some bumps for when versions change, the project will likely 
>> end after v1.0 is released (say 2 years?) and so your code should be stable 
>> when complete. It could have been 3-5 years for v1.0 (that's actually what 
>> I thought before reading it), in which case you know your code will be 
>> broken soon after publication, and so you should think about either not 
>> publishing the code or putting it to a Github repo with tests and be ready 
>> for the extra work of updating it.
>>
>> For industry, it probably means something similar.
>>
>> It's by no means a guarantee, but as a ballpark it's still extremely 
>> useful just to know what they have in mind. Since it's so soon, it also 
>> tells us that the "put the extra stuff in a package" instead of growing 
>> base mentality is how they are continuing forward (it's the leaner version 
>> of Julia that they have been pushing with at least v0.5 which gives them 
>> more mobility), which I think is good and it means I should plan to really 
>> plug into the package ecosystem, which may not be stable at the v1.0 
>> release.
>>
>> On Thursday, July 7, 2016 at 7:47:28 AM UTC-7, Isaiah wrote:
>>>
>>> I knew that.

>>>
>>> The goal is 2017, if development community considers it to be ready.
>>>
>>> I don't mean to be too glib, but I fail to see how any answer is 
>>> particularly actionable; it is certainly not binding.
>>>  
>>>
>>> On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote:
>
> When it is ready.
>
> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi  
> wrote:
>
>> I really like Julia (I am using it for my publications & thesis), but 
>> I noticed that the versions are not really backward compatible. I am 
>> still 
>> ok with that, but  many other people are waiting for the mature, stable 
>> version  (1.0) to start using Julia. So, when Julia v1.0 will be 
>> released?
>>
>
>
>>>

[julia-users] ANN: New Julia Packages website

[Adrian Salceanu]

I've setup an early version of a Julia packages website, for your package 
discovery pleasure: http://genieframework.com/packages 

Fair warning, this is a test case website for Genie.jl, the full stack web 
framework I'm working on - and 90% of my focus was on building the actual 
framework and the app, rather than the accuracy of the data. 

That being said, the app works quite well as far as I can tell (feedback 
welcome!) and compared to pkg.julialang.org it has a few extra features:  
* full text search in README 
* it includes both METADATA registered packages and extra packages crawled 
from GitHub (not all Julia packages on GitHub are included, this is a know 
bug and I'm working on fixing it - but all the official packages are 
there). 
* lots of info at a glance, to help spot the best packages
* modern UI

If the core contributors (of whoever's maintaining pkg.julialang.org) think 
this can be a useful replacement for pkg.julialang.org I'm happy to donate 
it and contribute by extending it to add the missing features (license, 
tests status, etc) and maintain it. Let me know. 

Adrian

[julia-users] Why two (qualified) macro invocation forms?

[Hans-Peter]

Acc. to the manual [1] either `Mod.@mac` or `@Mod.mac` can be used. What is 
the reason for the second form? Is it necessary to make me (other people?) 
think which form should be used preferably? Maybe there is a reason (didn't 
find something in issues/maillist) but with my current knowledge I'd 
propose to 'push' the first form and deprecate the second.

Both forms are not used often (in Julia source and my v0.4 packages). The 
first (Mod.@mac) form is more frequent.

~~~
find ~/.julia/v0.4/ -name "*.jl" | xargs ack " \w+\.@\w+"
find ~/.julia/v0.4/ -name "*.jl" | xargs ack " @\w+\."
~~~

Sometimes both forms are being used, e.g.:

... v0.4/DataArrays/src/DataArrays.jl
78:Base.@deprecate removeNA dropna
... v0.4/DataArrays/test/reducedim.jl
12:Base.Test.@test DataArrays._any(bits, i, j) == v

vs.

... v0.4/Calculus/src/Calculus.jl
62:@Base.deprecate integrate(f,a,b) quadgk(f,a,b)[1]
... v0.4/Distributions/test/truncate.jl
70:@Base.Test.test_approx_eq_eps(logpdf(d, x), lp, sqrt(eps()))


[1] 
http://docs.julialang.org/en/latest/manual/modules/#namespace-miscellanea

[julia-users] caching the pivot ordering for a sparse cholesky factorization?

[Gabriel Goh]

Hey,

I have a sequence of sparse matrix factorizations I need to do, each one a 
different matrix but with the same sparsity structure. Is there a way I can 
save the AMD (or any other) ordering that sparsesuite returns, it does not 
need to be recomputed each time?

Thanks a lot for the help!

Gabe

[julia-users] Re: How do I plot into an ITerm2 window?

[Josef Heinen]

GR.jl works fine with Julia 0.5-dev:




On Friday, July 8, 2016 at 5:10:31 AM UTC+2, Randy Lai wrote:
>
> In case anyone needs it (Julia 0.5-dev).
>
> julia> using TerminalExtensions
>
> julia> f = open("/Users/Randy/Pictures/116.png");
> julia> d = read(f);
>
> julia> Base.show(b::Base64EncodePipe, ::MIME"image/png", x) = write(b, x)
>
> julia> display(TerminalExtensions.iTerm2.InlineDisplay(), 
> MIME("image/png"),d)
>